[00:03] * Laney battles lplib [00:11] directhex, yay, welcome to the MOTU club! [00:12] NCommander, do i get to ride around on some kind of sabretoothed tiger and chop up bad guys? [00:12] directhex, nope [00:12] aw man, wrong MOTU :( [00:12] you get to learn the secret handshake and have plumbers do work for you in half the time [00:13] see: the stonecutters [00:13] i can't join a secret society which is against the metric system [00:14] oh, you can now get a free LWN subscription [00:15] how about a hat? something dapper? [00:15] at a jaunty angle [00:16] man, ubuntu releases could totally be about hats instead of animals [00:16] redhat have the hat thing going on already :( [00:17] ^ too much like fedora [01:09] james_w, The reason for sponsor membership is historical and related to bugmail. Feel free to raise for discussion. [01:09] directhex, I'lll add you to the team. Welcome! [01:09] persia, hello [01:10] persia: I'll bring it up sometime, thanks [01:10] persia, it was suggested by Laney that karma demands i do some sponsoring given how much sponsoring i've expected in the past [01:10] heh [01:11] * james_w notes that the sponsorship queue is quickly ballooning [01:11] Ooh. Someone else already added you. Nifty. [01:11] i think it was TheMuso [01:12] Yeah. I just received the membership addition mail between saying I'd add you, and the error. No idea why it was delayed. [01:14] clearly you ran out of internet, so it was held up === funkyHat is now known as fun === fun is now known as funkyHat [01:39] If anyone has the time to review my package for lxsplit, I would greatly be appreciate it. It can be found here http://revu.ubuntuwire.com/p/lxsplit thank you for the time :) [02:17] did I miss revu day :( === jcastro_ is now known as jcastro [03:29] So who wants to REVU a package? [03:31] So who wants to REVU a package? [03:34] Anybody want to review a new package? [03:34] just post the link [03:34] whoever's dropping by will look at it [03:35] Great, thanks [03:35] I was beginning to think my client was borked. [03:35] heh [03:35] * hyperair still doesn't see a link [03:36] Gimme a minute [03:36] <_stochastic_> http://revu.ubuntuwire.com/p/a2jmidid [03:36] http://revu.ubuntuwire.com/p/veusz [03:37] now then.. let's apt-get source both of them.. [03:38] * hyperair will look at a2jmidid first (it's simpler) [03:38] OK [03:38] * _stochastic_ is happy! [03:39] disclaimer: i'm not a MOTU, i'm just helping out because i'm bored. [03:39] and i've got one hell of a block trying to figure out how to write my nautilus-share patch [03:39] Thanks anyway [03:39] np [03:39] hmm waf eh.. [03:39] what's the problem you're working on? [03:39] brywilharris: segfault. [03:40] bug #258570 [03:40] Launchpad bug 258570 in nautilus-share "nautilus crashed with SIGSEGV in strlen()" [Medium,In progress] https://launchpad.net/bugs/258570 [03:42] _stochastic_: alright, first step.. bump up your Standards-Version [03:42] W: a2jmidid source: out-of-date-standards-version 3.8.0 (current is 3.8.1) [03:42] <_stochastic_> when did that happen? [03:43] <_stochastic_> 3.8.0 was the standards version when I uploaded it [03:43] debian sid. [03:43] i mean 3.8.1 is the new Standards-Version in debian sid, and karmic. [03:43] <_stochastic_> okay [03:44] hell 3.7.3 was the standards version when I uploaded... [03:45] heheh [03:45] that's not even jaunty. that's intrepid i believe. [03:46] It was [03:46] at the time [03:47] * hyperair facepalms. [03:47] waf. [03:47] good god [03:47] what's with the huge amount of obfuscated code there? [03:48] or is that base64'd stuff? [03:48] in a2jmidid? [03:48] yes. [03:49] i've personally never used waf before so i can't comment on whether those strange looking symbols are suupposed to be there or not [03:49] wtf is waf? [03:50] its a build tool [03:50] another ridiculous python-based build system [03:50] similar in many ways to scons [03:50] indeed [03:50] Ah [03:50] it was inspired by scons, which in my opinion, is THE most ridiculous build system i've seen. [03:51] the base64 code is equivalent to configure - it allows a waf project to be fully selfcontained [03:51] * hyperair needs to take note not to make statements like this after becoming UCD. [03:51] so where are you seeing base 64? [03:51] hyperair: scons has some issues, its true. [03:51] brywilharris: look at the bottom of the waf file [03:51] lifeless: what exactly is in this base64'd code? [03:52] wafs library [03:52] _stochastic_: ping. [03:52] compressed [03:53] lifeless: good god. how ridiculous. [03:53] which is morally equivalent to configure [03:53] which is the autoconf library compiled for a specific project [03:53] its no better or worse [03:53] i don't remember seeing base64 code in autofoo [03:53] the base64ness is irrelevant [03:53] it is. [03:53] configure isn't the preferred form of modification [03:54] that's true. [03:54] but it looks goddamn obfuscated. [03:54] configure is the output of a compiler; so is that code blob [03:54] have you read a configure recently? [03:54] sure i have. [03:54] not exactly the shining light of small and simple sh code [03:54] in fact, i've patched it [03:54] *not* a configure.ac. [03:54] ...yes sir, i know the difference between configure and configure.ac [03:55] good, just checking. [03:55] anyhow, I'm not here to defend waf per se; but I think the self-hostingness (which is optional btw) is fairly well done [03:55] So what's the difference [03:55] and i think it's ridiculous. [03:55] I mostly write python code now [03:55] so let's leave it as that. [03:56] either way, i'm supposed to be reviewing a package, not commenting on the idiocy of upstream's build system of choice. [03:56] _stochastic_: you there? [03:56] When I was writing code you still had a separate build and link step... [03:56] meh he disappeared. [03:57] i think make's awesome enough not to require crazy python hacks. [04:00] <_stochastic_> hyperair, sorry I ran away for a second [04:01] ah he's back! [04:01] so anyway [04:01] where was i [04:01] waf? [04:01] nevermind waf. [04:01] right. debian/rules. [04:01] i'm not very familiar with the old debian/rules way [04:01] it's too easy to accidentally leave something out [04:02] i'd instead suggest the minimal dh7 rules way =D [04:03] <_stochastic_> care to show a template/example/spec? [04:03] hmm [04:03] where can i find an example.. [04:03] /usr/share/doc/debhelper/examples/simple [04:03] or something like that [04:03] _stochastic_: you can take a look at geanygdb in revu [04:04] /usr/share/doc/debhelper/examples/rules.tiny | rules.simple [04:04] "man dh" for more information [04:04] it's awesome stuff. [04:05] you could also use cdbs, but many people say it's black magic. [04:05] Yo got that right [04:05] mostly because it's that much harder to trace through a million and one .mk includes [04:05] <_stochastic_> is there anything wrong with the way its packaged? [04:05] as opposed to a mass of perl that calls a long arbitrary list of programs and hides errors? [04:05] :) [04:05] _stochastic_: you might like to ask upstream to include the GPL license. [04:05] _stochastic_: seems they forgot. [04:05] <_stochastic_> it is included [04:05] _stochastic_: i don't see a LICENSE or COPYING file anywhere [04:06] <_stochastic_> look again, it's titled gpl.txt [04:06] ooh it is [04:06] gpl2.txt [04:06] <_stochastic_> yes [04:06] alright then [04:06] <_stochastic_> that's a new warning in REVU, it wasn't there a couple days ago [04:06] _stochastic_: your debian/watch isn't working. [04:07] <_stochastic_> oh? okay, I'll look into that [04:07] Unknown verb pattern '' in regex; marked by <-- HERE in m/^(?:(?:http://download.gna.org)?\/a2jmidid\/)?a2jmidid-(*) <-- HERE .tar.bz2$/ at /usr/bin/uscan line 897, line 2. [04:07] very strange. [04:07] ah [04:07] right [04:07] .*, not * [04:07] <_stochastic_> ah [04:07] http://download.gna.org/a2jmidid/a2jmidid-(*).tar.bz2 [04:07] see the * there [04:08] <_stochastic_> yes [04:09] they don't release .tar.gz's do they? [04:09] <_stochastic_> nope [04:09] hmm i see. [04:09] <_stochastic_> are you sure it should be .* the filename looks like a2jmidid-4.tar.bz2 [04:10] yes i'm sure [04:10] this is regex. [04:10] man 7 regex for more information [04:10] test it with uscan [04:10] <_stochastic_> okay [04:10] <_stochastic_> done. [04:11] uscan --verbose [04:11] alright, onto your copyright file [04:11] sorry go ahead [04:11] haha no problem [04:11] you're missing a few copyrights [04:12] <_stochastic_> ? which files? [04:12] NCommander, I noticed that grendal has been maintaining the debian packaging in the pike CVS [04:13] NCommander, so I'm attempting to rebase all the changes in Debian onto the debian packaging in the CVS [04:13] eh um nevermind [04:13] whoops [04:13] http://revu.ubuntuwire.com/report.py/legal?upid=5644 [04:13] ./.waf-1.4.3-4cc0bec64a165ffe5dd3eed60cd2e01b/wafadmin/pproc.py <-- this [04:13] heheh [04:13] but i suppose this is one of the autogenerated files [04:13] * cody-somerville hopes what he is doing is sane. :) [04:13] so nevermind [04:14] hyperair, In that case, the clean rule should delete that [04:14] cody-somerville: no i was messing around with waf earlier. [04:14] cody-somerville: i'll unpack it again to check later [04:15] ok [04:15] i remember hearing some mention about needing to use the copyright symbol instead of (C)/(c) [04:16] © [04:16] this one [04:16] <_stochastic_> previous REVU uploads I've had accepted just used (c) [04:16] _stochastic_: i think you can actually merge all the Nedko Arnaudov entries. i noticed you have three of those. [04:16] _stochastic_: it's a very recent change. [04:17] alias ©='echo GPLv3' [04:17] ._. [04:18] _stochastic_: also, i'd actually suggest that you document which copyrights go to which files [04:18] <_stochastic_> hyperair, which of Nedko's entries? where? [04:18] in debian/copyright [04:18] Copyright (c) 2008 Nedko Arnaudov [04:18] Copyright (c) 2008 Nedko Arnaudov [04:18] Copyright (c) 2007,2008 Nedko Arnaudov [04:18] three. [04:18] <_stochastic_> ahh [04:19] well actually two, but you repeated one of them [04:19] of course, if it's not too much trouble, you should actually document which copyrights go to which files [04:19] <_stochastic_> in the machine-readable format? or is there another way? [04:20] well you don't necessarily have to use machine readable format, but if you were to use it, there's http://wiki.debian.org/Proposals/CopyrightFormat [04:21] <_stochastic_> so can Copyright (c) 2007,2008 Nedko Arnaudov be used for all of Nedko's or does another need to explicitly list 2008 only? [04:22] i'd actually merge the files that belong to Nedko [04:22] in one single listing [04:23] <_stochastic_> okay [04:25] you're also missing one of the brackets in Copyright C) 2009, Eric Hedekar [04:25] and now the customary test-build. [04:27] for foo in `grep -ir '(c)' .|cut -d ':' -f 1|uniq`; do sed -e 's/(c)/©/' $foo >temp; mv temp $foo; done [04:28] just make sure you don't have any variables named 'C'... [04:30] i think you meant sed -i -e $foo [04:31] -i means edit in place [04:31] that would work too [04:31] however, this breaks python files as I just discovered... [04:31] also, the © was supposed to be in the debian/copyright file i think [04:31] or something like that [04:32] python complains about the character encoding [04:32] i think it's permitted to be (c) in tbe actual sources [04:32] It has to be [04:32] yeah [04:32] haha [04:36] <_stochastic_> hyperair, any other issues you can spot? [04:37] _stochastic_: gimme a moment to build [04:37] i was updating my karmic pbuilder earlier [04:41] meanwhile, i'll take a look at veusz i guess. [04:42] kk [04:43] brywilharris: regarding your rules file... why don't you use a .install file instead of manually running install -d -m644 bla [04:43] OK [04:47] W: a2jmidid: binary-without-manpage usr/bin/a2j_control [04:47] W: a2jmidid: binary-without-manpage usr/bin/a2jmidi_bridge [04:47] W: a2jmidid: binary-without-manpage usr/bin/a2jmidid [04:47] W: a2jmidid: binary-without-manpage usr/bin/j2amidi_bridge [04:47] _stochastic_: ^ [04:47] you're gonna have to write manpages for all of those =) [04:47] and then add them to debian/manpages [04:47] man dh_installmanpages for more information [05:08] I gotta go to bed [05:08] hyperair: Thanks for the help [05:30] If someone has the time to review my package http://revu.ubuntuwire.com/p/lxsplit I would greatly appreciate it :) [05:30] can someone explain the basic process of repackaging an unstable debian package to the latest and greatest Ubuntu distro? [05:31] abuDawud: generally its just a sync [05:31] https://wiki.ubuntu.com/MOTU has docs [05:31] abuDawud, you pretty much just change the changelog and control file [05:32] binarymutant: unless it needs patching you should sync it not change changelog [05:32] does it involve the apt pinning process if I wanted to use apt source for requisitioning the files? [05:32] or is that over complicating things? [05:33] lifeless, I understand :) [05:34] essentially I am looking for an easy intro project into packaging after reviewing all of the documentation. I figured that would be pretty simple [05:34] abuDawud, a sync is pretty much just a bug report [05:34] binarymutant, I will look at the link lifeless posted and read up about it. [05:34] is there somewhere simpler to start? [05:35] should we archive blankon-extra-backgrounds in revu, 6 months and the poster hasn't updated [05:35] abuDawud: the simplest place to start is to fix a bug in a package that is in Ubuntu [05:36] abuDawud: that way you're working with existing code and package, only making a small change, and don't need to know all the ins and outs [05:36] lifeless, I have been trying to find one that is not patched using harvest and looking through launchpad and I can't seem to find one [05:37] abuDawud: what do you mean? [05:37] well I can't seem to find where to watch for simple bugs that just need repackaging etc [05:38] all of the bugs I find seem to either be complicated code issues or they are fixed [05:39] abcmidi is an example of package which has been synced, rather than patched by ubuntu [05:39] abuDawud: are you interested/experienced with any particular programming languages/environments? [05:39] lifeless, a bit of perl but its all intro stuff [05:40] lifeless, I was trying to find a way to help out with my limited code knowledge [05:40] lifeless, packaging seemed to be the way to go [05:41] packaging is useful, but to package code properly you need to understand that particular language [05:41] when packaging you will run into compile problems/link errors/dependencies/language issues [05:42] the more you understand the particular language[s] the thing you are packaging is written in, the easier it is for you [05:43] abuDawud, if you use the advanced search in launchpad you can find new bugs that need to be triaged or for packaging you can look through this listhttp://www.debian.org/devel/wnpp/orphaned [05:44] binarymutant, thanks, I think I have some more reading to do :) [05:54] whats with licencing pacaking data (often under the (C) threshold anyway) as GPL [05:54] surely same-licence-as-package would be better [05:55] I <3 gpl [05:56] so do I [05:56] for software [05:57] how about for a Makefile? It scare me to see the nvidia license in a Makefile [06:28] Hi. Anyone with access to a powerpc computer? I'd like to know what is the return value of dpkg --print-installation-architecture [06:32] how come after making a package from a single script and then installing it the script will not go to /usr/sbin? what could of cause this? [06:36] blacknred0, inside your deb package, is it in /usr/sbin? [06:38] fabrice_sp, no [06:38] so i figure that it will never execute [06:39] how i could make the package and placing my script on /usr/sbin whenever any user executes the command? [06:39] blacknred0, during the building of your package, you need to 'move' the files in the correct temporary directory? [06:39] this temporary directory is debian//usr/bin [06:40] If someone has the time to review my package http://revu.ubuntuwire.com/p/lxsplit I would greatly appreciate it :) [06:40] fabrice_sp, nope... currently is mypackage/tmp not mypackage/debian/... [06:41] thnx... facbrice_sp.... i would do that then... [06:41] ;-) [06:43] fabrice_sp, so one last question.... so should i call form rules that package? or should i have a tmp for that same script? [06:45] blacknred0, just put your script in the right place, in the install target in debian/rules, and it should be ok [06:45] ok, thnx :P [06:45] binarymutant, I'm trying to build your package in amd64, but it's not possible [06:45] is it normal? [06:46] I'm getting: lxsplit_0.2.4-0ubuntu1.dsc: amd64 not in arch list: i386 -- skipping [06:46] fabrice_sp, arch i386 [06:47] binarymutant, why? It's not compatible with amd64? [06:49] fabrice_sp, the site didn't say it wasn't, I should change to arch all [06:49] binarymutant, yes [06:50] as amd64 is a growing arch, it would be a pity not to have it :-D (and I won't review the package :-) ) [06:54] fabrice_sp, should be able to build on your architecture now, srry :) [06:55] binarymutant, uploaded to revu? [06:55] yes [06:56] ok (trying to build again) [06:58] binarymutant, all no. It's for arch independant packages. This one in compiled, so it should be any [06:59] fabrice_sp, oh okay, thank you, I get those two mixed up sometimes [06:59] so do I :-) But when building, and you see a *_all.deb, it clarify things :-) [07:00] is there anything else that is noticeable to you fabrice_sp, it's my first C package so I'm very concerned about it [07:01] binarymutant, I'll have a look at the packaging now (as arch is not correct, I'm getting errors in lintian) [07:02] you miss ${shlibs:Depends} in depends for the binary package [07:03] you should drop the A in the description (the short description extend the phrase this package is a ...) [07:03] for the long description, don't repeat the short description [07:06] for man page installation: I generally prefer to have it in a manpages file, but the way you do it is correct [07:07] the same for docs [07:07] otherwise, looks good (and simple ;-) ) [07:08] thank you for your time I'll correct these :) [07:09] you're welcome. Did you uploaded a 'any' package? [07:09] (just to check the resulting package) [07:09] the last two issues about the manpage and the docs, could you elaborate? [07:09] yes :-) [07:10] instead of putting the name of the file you will install (for doc or for manpage) in the debian/rules file, you can put that in dedicated files in debian directory [07:10] manpages for man file [07:10] docs for doc files [07:10] this way, you could even have a more simple rules file, using cdbs :-) [07:10] (a 2 lines rules file :-) ) [07:11] oh instead of using dh_ I get you [07:11] you still nee the dh_ stuff, but this way, it's easier to add a file [07:11] s/nee/need/ [07:12] since its my first C package I wanted to try it with debhelper instead, it feels more in depth to me. But i've done a cdbs package and it definitely was simpler [07:12] I mean, you will have dh_installman instead of dh_installman debian/lxsplit.1 [07:12] it's a good approach to learn ;-) [07:15] if you still have any time to spare the updated package been cached into revu [07:16] ok. I'll download it again [07:16] ty :) [07:34] Hello! I am having a hard time resolving FTBFS of my REVU upload (on karmic). Does anyone have a little time to help? [07:34] artfwo: what's wrong? [07:35] well, here's the upload in question http://revu.ubuntuwire.com/p/scantailor [07:35] and it fails to build in the PPA [07:35] https://edge.launchpad.net/~artfwo/+archive/ppa/+build/987616 [07:36] there're lots of cryptic preprocess messages in the build logs, which have led me to debian bug 505109 [07:36] Debian bug 505109 in boost1.35 "FTBFS with GCC 4.4 and breaks other apps" [Important,Closed] http://bugs.debian.org/505109 [07:36] it's fixed in the latest debian, yep [07:37] so [07:37] I have merged boost1.35 from debian and also uploaded it to the PPA [07:37] have you tried building with a sid pbuilder? [07:37] nope, didn't think of it [07:37] but anyways [07:37] i'm giong to try building [07:38] boost1.35 also fails to build in the PPA/Karmic after the merge [07:38] due to the following error: [07:38] ../boost/test/impl/debug.ipp:280: error: 'sscanf' is not a member of 'std' [07:38] which again led me to upstream [07:38] https://svn.boost.org/trac/boost/ticket/1542 [07:38] (comment:1) [07:39] it does not seem to be fixed upstream, but I wonder if I can replace with in my merge to fix it [07:40] ah! [07:40] right! [07:40] i had an issue with that as well [07:40] cstdlib [07:40] you need to include cstdlib to each and every one of those files using sscanf [07:40] it's not included by default any more [07:40] zomg [07:40] hahah [07:41] artfwo, why using an old boost version? [07:41] fabrice_sp: mainly chose it because it's in main [07:41] there isn't a boost1.37? [07:42] in main also :-) [07:42] there is, but boost1.35 is in main, so it's better supported and all, right? [07:42] huh? [07:42] my bad: 1.37 is in universe [07:43] but I remember ScottK trying to get rid of boost1.35 [07:43] so try with 1.37 [07:43] Actually it was boost, which is 1.34 [07:43] We need to pick a target boost for Karmic. [07:43] right you are, 1.37 is in main as well: http://packages.ubuntu.com/source/karmic/boost1.37 [07:43] 1.37 or 8 not sure. [07:43] 1.38 is universe [07:44] ohh: i'm bad at numbers :-) [07:44] Doesn't mean it will stay that way. [07:44] damn, I have already opened a merge bug for 1.35 [07:44] anyway, a new package should use the latest version of a lib, right? [07:44] 1.38 is the version Debian is aiming to use for Squeeze, so the faster we can line up on that the better. Might be Karmic + 1 though. [07:45] okay, I shall try 1.37 for now [07:45] ScottK, this kind of things will be decided at UDS? [07:45] I hope so. [07:45] ok [07:46] but then again - is 1.35 going to sink away from karmic at all? [07:50] artfwo, until UDS, we don't know. But it could be [07:50] okay [07:52] so the new boost is built? [07:53] I'll have to proceed with cgal then :) [07:59] good morning btw :P [08:00] well, it fails to build with boost 1.37 as well, but I think it's a matter of another bug - debian bug 525752 [08:00] Debian bug 525752 in kmldonkey "FTBFS with GCC 4.4: missing #include" [Unknown,Open] http://bugs.debian.org/525752 [08:00] <_stochastic_> Do any MOTUs want to take a look at this upgrade request that's ready for upload Bug #367735 [08:00] Launchpad bug 367735 in calf "upgrade to newer upstream version" [Wishlist,In progress] https://launchpad.net/bugs/367735 [08:02] everything has worked so nice on jaunty :( [08:05] artfwo, we are so early in the cycle, that it's normal to have this kind of things [08:06] yep, but this GCC cleanups in Karmic have just uncovered an upstream bug, which I've got to fix and forward to the author [08:07] the only thing that frustrates me, is that I don't currently have enough bandwidth for pbuilder [08:10] _stochastic_: 1) you need to follow sponsorship process: https://wiki.ubuntu.com/SponsorshipProcess 2) did you test-build your new package? [08:12] <_stochastic_> savvas, yes I've tested it and the upstream version fixes some bugs [08:12] <_stochastic_> the bug is already attached to the universe sponsors, should I just sit and wait? [08:13] oh ok, I think what's left now is to subscribe ubuntu-universe-sponsors [08:14] <_stochastic_> they're already subscribed [08:15] hm.. [08:15] it's in the activity log but not in the subscribers list [08:15] weird [08:16] _stochastic_: oh by the way, you changed the status of the bug after subscribing the sponsors, please set it back to confirmed :) [08:18] <_stochastic_> savvas, is there anywhere that the status policy is outlined? I constantly am adjusting things to what I think should be the right status, but then am told to change it etc.. (it was set to triaged not confirmed) [08:19] it shouldn't matter what the status is, but I think "in progress" means you would take care of the sponsorship yourself [08:19] <_stochastic_> should it go back to triaged or be switched to confirmed? [08:19] <_stochastic_> to me, in progress was referring to the fact that progress has been made on the bug [08:20] if you have bug control permissions, make it triaged, if not then confirmed :) [08:21] <_stochastic_> savvas, that sponsorship link you sent me claims that all bugs ready for sponsorship shouldn't be assigned to anyone, should I remove myself from that position now? [08:21] I didn't see any outline or policy about the status, but that's what I was advised to follow hehe. you shouldn't change the status after subscribing the bug to the sponsors [08:22] yes, that's true forgot that :) [08:26] _stochastic_: do you see ubuntu-universe-sponsors on the right subscribers list? [08:26] <_stochastic_> savvas, yes I do. don't you? refresh? [08:26] I have :\ [08:27] let me check with the normal launchpad server [08:27] <_stochastic_> I also see it here: https://bugs.launchpad.net/~ubuntu-universe-sponsors [08:27] well launchpad bug I guess :) [08:30] config.sub config.guess [08:30] these are files right? [08:31] not that important but if you require to make any new changes to the debian package, instead of "rm -f config.sub config.guess" use "dh_clean config.sub config.guess [08:33] I mean something like this: http://paste.ubuntu.com/167576/ [08:38] any motu to review http://revu.ubuntuwire.com/p/gnote ? [08:39]