[00:08] grr I cannot build a source package but I can build a working debian package? [00:09] the orig source is in the correct format but I get: dpkg-source: unrepresentable changes to source when running debbuild -S -sa [00:10] AdamDH, which either means your clean rule doesn't work, or you have binary bits & pieces in your diff [00:11] directhex, in my package folder I have a tar.gz file of the upstream source, would this be the issue? [00:11] I am also getting allot of dpkg-source: warning: ignoring deletion of file [00:12] I could remove that upstream source and create a symlink to the source in /usr/src that might be a better option? [00:25] * sistpoty goes to bed... gn8 [01:20] directhex: I think as a mono person you might find this interesting: http://scripts.mit.edu/~jdong/wiki/moin.cgi/LangShootout [01:20] a bit of a high-level-language shootout that stemmed from a project I was working on the last few days [01:21] not that any of the results are surprising IMO [01:21] jdong_: I'm sure it's completely biased ;) [01:22] interesting to see how much slower ironpython is [01:23] ajmitch: yeah I was kinda shocked by that [01:23] when building a jaunty package using pbuilder why would it say binutils-source is a virtual package? I have a dev machine and I can do an apt-get install binutils-source fine, pbuilder is having a little trouble, have I missed something? [01:24] do you have universe enabled in pbuilder, in case it can't find that package? [01:26] I think universe was enabeled, how can I check? [01:27] pbuilder login and the look in /etc/apt/sources.list [01:27] quickest way is to use pbuilder login, try & install binutils-source in the chroot [01:27] or that [01:28] ajmitch: heh irony. it is biased. [01:28] jdong_: in what way? [01:28] ajmitch: list.append() in python is a LOT more expensive than I would've thought. [01:29] I am just updating the chroot again just in case something went wrong, will check when that has finished getting a release [01:29] ajmitch: repalcing list.append() with indexing a preallocated list brings it down from 80s to 25s [01:29] does it affect ironpython at all? [01:29] ajmitch: still IMO (1) slower than the alternatives (2) a ridiculous difference for what seems to be a trivial change. [01:30] oh crap [01:30] wait [01:30] I still leeft psyco in there [01:30] *smacks himself* [01:30] OK, retesting python and ironpython :) [01:30] skillz [01:31] I wouldn't expect 4 * (list.append(foo) to be THAT much slower than list=[0,0,0,0], x[0]= ... [01:31] depends on how many times you're running it [01:31] maybe a chance to play with the python profiler [01:32] 81.9s [01:32] uhh. [01:32] slower than before? [01:32] y.. yeah [01:32] awesome [01:32] * jdong_ attempts to reproduce. [01:33] * ajmitch sees that the RC bugs list thing has grown recently [01:35] ajmitch: 77.8, 81.9 vs 77.5, 78.1 ("optimized" vs original) [01:35] no significant difference. [01:35] now to revisit ipy [01:36] still unbearably slow [01:36] indeed [01:37] thanks for the help guys, did not know pbuilder login exsisted, really help full to chroot into the chroot to find out what is happening [01:39] AdamDH: even more useful, you can pass the --save-after-login option to pbuilder if you need to make changes in the base tarball for future builds [01:43] ajmitch: brought ironpython from 400+s to 361s. [01:43] still ridiculous though. [01:43] the magical "-O" optimize flag shaves a whopping... FOUR SECONDS off :) [01:43] * sistpoty prefers ebony-python, makes +4 *g* === asac_ is now known as asac [01:48] ajmitch: oddly, Jython was penalized by the change; 97 -> 112 [01:50] thanks ajmitch, that's going to come in handy [02:00] why would I get dpkg-source: warning: ignoring deletion of file? then is no clean rule that affects the files in question? [02:00] its doing it for all the source in my orig.tar.gz file === freeflyi1g is now known as freeflying === azeem_ is now known as azeem [02:24] if I am running a shell script inside my chroot from my rules files, does it preserve permissions set inside the package folder? eg chmod +x apply_patch? as I get make: execvp: /tmp/buildd/msp430-binutils-2.19-msp430-cvs.0.0.20090228/scripts/apply_patch: Permission denied [02:25] I am running pbuilder as root as well [02:29] is the script a part of orig.tar.gz or created in the diff.gz? [02:30] created in the diff.gz [02:33] remember that .diff's do NOT represent permissions. [02:33] they only represent file content or lack thereof. [02:34] in your case you'd want to use your rules file to chmod +x the script before executing it. [02:34] thanks, I will add that to my rules [02:35] I can just do chmod +x inside rules? [02:44] ah yes I can just do that! === JanC_ is now known as JanC === Andre_Gondim is now known as Andre_Gondim-afk [05:07] hey y'all, what is the ubuntu network installation / configuration app thats used during install process? I have a single function kiosk (it boots into 1 function @ a time) and would like to offer the ability to manage the nework. I have X but only xserver & twm, any suggestions? [08:01] jdong_, interesting. i suspect Ipy 2.0 would do much better - but I don't think it's on the cards for Jaunty, sadly, due to needing Mono 2.2 [08:08] jdong_, i'm mostly impressed by ikvm being usably fast (perhaps the packaging nightmare was worth it ^_^) [08:08] jdong_, feel like testing another metric, though? look at RAM consumption. java will likely use an order of magnitude more than mono [09:28] hi, if someone has free time, can please review http://revu.ubuntuwire.com/p/dsss ? thanks [09:40] goshawk: I just skimmed over the .diff.gz and on a first look it looks ok. Just a small question about the first patch: it replaces several occurances of "rebuild" with "drebuild" but why not for "rebuild.conf" (2nd change in this patch)? [09:53] any one know a package that uses get-orig-source? [09:54] AdamDH: maximus, in jaunty [09:55] thankyou StevenK [10:42] geser: you are right, it's an error === smarter is now known as smarter_ === smarter_ is now known as smarter [10:58] does any one mind taking a look at this please? http://revu.ubuntuwire.com/p/msp430-binutils I have the package in my PPA as well, just want some feedback as its my first package [10:59] thanks [11:15] any ideas how I use my ppa in pbuilder? I did a sudo pbuilder login set the sources.list but its not preserved on exit === bastiao__ is now known as k0p [11:16] AdamDH: --save-after-login [11:16] thanks RainCT [11:23] i am getting allot of dpkg-source: warning: ignoring deletion of file for all the files in my orig.tar.gz, what would cause this? I am buidling a source package with -S -sa [11:26] AdamDH: and do the files actually exist? [11:26] inside the tar ball yes [11:27] does the .orig.tar.gz perhaps contain files which are removed after a make (dist)clean? [11:27] I have not extracted the upstream tar ball just left it as .orig.tar.gz [11:27] geser not sure [11:28] the package is up on revu [11:28] AdamDH: that's the problem, the .orig.tar.gz is supposed to be extracted [11:29] thanks RainCT I will extract it and try again [11:29] Iou can most likely ignore that error, though. If you didn't touch anything outside debian/, the debuild should have worked fine [11:30] it builds the package fine [11:30] I am really starting to enjoy packaging [11:30] my first package took me a few days, the second one a few hours [11:31] :) [11:33] I probally took the wrong type of package to start with, a cross compiler, but at least I have a working tool chain, even if there are some fudge factors in the rules ;) [11:43] AdamDH: Cross-compilers are hard enough to *build* let alone package [11:44] well I could compile it from source with ease and done it on a few distros, just wanted to package it as there are no packages in debian or ubuntu yet for the msp430 tool chain [11:47] hello, I need a freeze exception for bug 335796 [11:47] Launchpad bug 335796 in qterm "Please sync qterm 1:0.5.4-2 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/335796 [11:47] with out this sync, qterm will always crash under QT 4.5 [11:48] I am all ready getting feedback and the packages have only been in my ppa for approx 12 hours [12:18] ScottK: looks like the bmpx powerpc builds fine on debian unstable: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517373 [12:18] Debian bug 517373 in bmpx "FTBFS(powerpc): configure: error: libsidplay 1.x not found!" [Normal,Open] [12:21] what's Pete Savage's IRC nick these days? (or is he just not online as cbx33) [12:25] launchpad is really slow just dputed a package and had no email or anything appear in my ppa for like 30 mins [12:54] so my orig.tar.gz should be extracted into my package dir with the debian folder etc? so all the source is in that folder with a orig.tar.gz outside so a diff can take place? === elmargol is now known as bekkrgol === korn_ is now known as c_korn === bekkrgol is now known as elmargol [14:04] wow there are some messy packages out there === RainCT_ is now known as RainCT [14:17] AdamDH: hi, if you have free time, please have a look to my package at revu http://revu.ubuntuwire.com/details.py?upid=5296 :) thanks. [14:20] goshawk, I am a new packager, not a MOTU, I can offer some tips from what I have learnt from packaging over the last few weeks, but that's about it, sorry [14:20] AdamDH: any tip is appreciated :) [14:21] well... don't do it now, i'm fixing one more thing :) [14:21] i submitted my packages to revu today but I just found about 4 bugs! [14:22] goshawk: use http://revu.ubuntuwire.org from now on :) [14:23] savvas: ah yes, sorry, it's the link pointed me out from [revu] New upload for package dsss mail, i think it should be updated to .org too [14:33] goshawk: do you know which parts are under artistic license? [14:33] savvas: no, i should read the whole code to find it :( [14:34] but if it's necessary i'll do [14:34] (I'm not a MOTU either btw) :) [14:34] :) [14:34] let me check [14:35] Actually, I think the author should've stated clearly about each bit of code under which license is used [14:37] for some reason I cannot view your license file from revu but this might help http://wiki.debian.org/Proposals/CopyrightFormat if your not all ready using that system [14:38] AdamDH: I have the same problem, some encoding error, right? [14:39] AdamDH: thanks i'm reading [14:40] AdamDH: but be careful: it's a proposal, i don't read that the policy is changed as described in that wiki [14:40] that format allows you to say what files belong to what packages looks like its ideal for your package [14:41] i have seen a few packages using it, and I asked in here and no one seemed to have a problem using it [14:41] ah perfect [14:41] but then I am waiting for some one to look at my packages in revu ;) [14:41] so i'll switch to this one [14:41] did you adopt this format too? [14:41] inyour packages i mean [14:42] if you look at msp430-binutils in revu you will see that I adpoted that format [14:42] example: http://paste.ubuntu.com/124262/ [14:44] goshawk: rebuild/readme.txt has the license covered, it says it's either GPL (version 1) or Artistic License. Most of the files in rebuild have a header saying to read that readme.txt, except for "rebuild/whereami.c" (MIT/X11 (BSD like) as you mentioned) - And unless I'm wrong, Unknown/No copyrights for files: rebuild/nprocs.c rebuild/gnuc.c test/test.sh [14:45] it's for rebuild [14:45] uhm... [14:47] goshawk: yes, it's for most files in rebuild :) [14:49] here's a dirty way to look at file headers/comments: head rebuild/*.c [14:49] ah... head i didn't know this program [14:49] head for first lines, tail for last lines :) [14:49] and that rebuild.txt don't really belong to rebuild [14:50] but to dmd [14:50] This is the source code to the front end Digital Mars D compiler. [14:50] well... you should know that rebuild is a code upon the DMD frontend (which is bot gpl 1 or artistic) [14:51] so that readme says that the DMD part in rebuild are gpl or artistic [14:51] not rebuild itself [14:54] i'm contacting upstream to have a better explanation of this licence issue [14:55] is the project under GPL-2 by the way? [14:58] the next problem I have on a simular issue is I have a binary blob to package with pre compiler modules, and that has no license at all as its closed source and propartery [14:58] *compiled [14:58] "DSSS, the D Shared Software System, builds upon rebuild and intends to create a standardized system for building, installing, configuring, acquiring and using D software, licensed as Free and Open Source Software under the MIT license: http://www.opensource.org/licenses/mit-license.php " [14:58] http://www.dsource.org/projects/dsss [14:59] yes i was looking for the same page [14:59] mit with some parts under gpl v1 or artistic then... isn't it? [15:02] i think the best solution is then to say that it's MIT licensed and some parts under rebuild are gpl v1 [15:02] isn't it? [15:03] I think so, give me a sec I'll show you an example [15:04] you can take also two of them :) thx for what you are doing :) [15:08] Laney: yo, around? [15:08] goshawk: something like this: http://paste.ubuntu.com/124272/plain/ [15:09] It's not like the proposal at debian which AdamDH pointed out, but it's humanly readable :) [15:10] :) [15:10] it's perfect [15:10] :) [15:10] thx [15:11] goshawk: Now if you want to be 100% sure about the MIT license, it should've been in the root folder, not in the docs/ - you could ask the authors to put the the LICENSE file in the root folder :) [15:11] already mailed :) [15:11] great! [15:12] does anyone know why python-clutter is not in intrepid? [15:12] i am still waiting for launchpad to build my deb so I can go back to work on the 3rd package in the tool chain [15:13] AdamDH, savvas, thanks too much for the help you gave me :) [15:14] no worries, I am happy to put back into the open source community [15:15] RainCT: revu encoding problem - Using firefox, clicking on "dsss_0.78-0ubuntu1.diff.gz" at http://revu.ubuntuwire.org/p/dsss - there's an encoding problem with the diff file inside that archive [15:16] goshawk: anytime :) [15:17] * RainCT shots at Firefox [15:18] If someone figures out what the problem is, patches are welcome. I only support wget myself :P [15:19] I use dget :p [15:19] which works heh [15:19] with revu how do I upload a revisied package? [15:20] dget actually uses wget (or curl) :P [15:20] *revised [15:20] AdamDH: just like the first upload (and without changing the version number, REVU doesn't need that) :) [15:20] great I had to change that for launchpad [15:20] RainCT: it seems to be encoded twice in gzip [15:21] savvas: Yes, but I don't know why. [15:21] http://paste.ubuntu.com/124282/ [15:21] who wrote rvu ;) [15:21] *revu [15:21] AdamDH: that's Apache madness :P [15:22] if there are options for depends, is the preference given in order of listing? In other words if a package depends on "procps | hurd", and neither are installed, will procps be installed? Is that a rule? [15:22] dantalizing: I think so [15:22] yeah [15:23] thx [15:28] i think revu ate my package [15:29] as nothing has shown up after I ran dput revu msp430-gcc_3.2.3-msp430-cvs.0.0.20090228-0ubuntu1~ppa2_source.changes [15:31] ignore that! its just a tad slow does any one mind having a look at this please http://revu.ubuntuwire.com/p/msp430-gcc? thanks [15:34] directhex: are the rules the same for the library transition as for the apps? [15:34] directhex: is there an ordering requirement? === smarter_ is now known as smarter [15:36] james_w: I like your approach to update notification better than what I read Ubuntu has now. [15:36] ScottK: that wasn't my approach [15:37] ScottK: is was just fixing the bug with the existing approach. [15:37] and it doesn't work with the new notifications [15:37] james_w: I understand, but I think fixing the existing approach would have been better. I read laserjock's problem about not being notified of updates and I find that pretty problematic. [15:38] with the new notifications we can't fix the existing approach in that manner [15:38] I think that limitation with the new notifications is unfortunate. [15:38] I think it is good [15:39] * Nafallo is with james_w [15:39] notifications wasn't notifications before. [15:39] I see it not so much as a limitation, but as a feature [15:39] So it's good to hide updates from the user? [15:39] ScottK: that's not what I said at all [15:39] please don't put words in my mouth [15:39] If I understand it correctly the way it works now until the popup opens up there is no indication at all you have updates? [15:39] OK. Sorry. [15:40] correct [15:40] I find that conceptually flawed. [15:40] I'm unsure about that change [15:40] however the new notification are a vast improvement in my opinion === a|wen- is now known as a|wen [15:41] that does require us to change the way we do some things, but I am willing to make those changes to get a better system [15:41] It'll be interesting to se how it works out. [15:41] for me, I don't need an indicator that I have pending updates [15:42] How do you know? [15:42] I *always* have pending updates [15:42] Heh. [15:43] talking about updates... [15:43] * Nafallo starts his jaunty running eeepc ;-) [15:43] Nafallo: with intel atom? [15:44] a|wen: no. 701 [15:44] then no point in asking if you were testing the lpia port... [15:45] Do we have any documentation about how to file Internal Compiler Error bugs? [15:45] NCommander: ^^^? Do you know [15:46] a minimal test case is usually desired, but that's the hard part [15:46] Yeah. [15:46] a|wen: nope [15:47] The one I'm looking at now is Qt4-x11 on powerpc. It's a huge package and I don't have the hardware. [15:49] are simple-ccsm/compizconfig-settings-manager working in Jaunty? [15:50] RainCT: as in running? yes [15:51] savvas: can you please tell me what shabang they have? [15:51] The following packages have unmet dependencies: python-urwid python-compizconfig python-cheetah python-libtorrent python-libtorrent python-launchpad-integration python-pysqlite2 [15:51] python-compizconfig: Depends: python (< 2.6) but 2.6.1-0ubuntu1 is to be installed. [15:51] Yeah, I have an update ready for that [15:51] what's a shabang? :P [15:52] but it will loose 2.5 support, and I don't know if that will break simple-ccsm and compizconfig-s-m [15:52] savvas: the first line in the file, starting with #! [15:52] oh [15:52] cat /usr/bin/simple-ccsm | head -n1 [15:52] hold a sec [15:53] $ cat /usr/bin/ccsm | head -n 1 [15:53] #!/usr/bin/python [15:53] I'll try simple if you want to [15:54] savvas: What does this say? ls -l /usr/bin/python [15:54] $ ls -l /usr/bin/python [15:54] lrwxrwxrwx 1 root root 9 2009-02-27 10:59 /usr/bin/python -> python2.5 [15:54] OK, so you haven't python2.6 by default yet [15:54] RainCT: about #292923 [15:55] * RainCT looks at ubottu [15:55] RainCT: should I? :\ [15:55] the https://wiki.ubuntu.com/SecurityUpdateProcedures says me to do tests using the QA regression testing [15:55] but... i don't have any thought in how to use it with a php library :) [15:56] savvas: Nvm, I don't want to be responsible for breaking your system :). Thanks! [15:58] RainCT: http://paste.ubuntu.com/124306/plain/ [15:58] If I want to update a package to build with Python 2.6 (which Build-Depends on python-dev), is it another to adjust the version to "..build1" (instead of e.g. "..ubuntu1") and upload? [15:59] savvas: I think there's some PPA with updates packages, check ubuntu-devel (or some other list) [15:59] nah, I'll wait for aptitude safe-upgrade :P [16:00] so the shabang makes a problem? [16:01] savvas: no, it's what I hoped for :) [16:01] ah ok :) [16:01] if it was python2.5 we'd have a problem [16:02] * RainCT uploads [16:03] RainCT: 292923 ready :P [16:04] savvas: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-February/000541.html ... expect python havvoc the next short while [16:05] and also if you wanted the link for the ppa [16:05] woohoo! [16:05] I'll try it on a virtual machine probably === cprov is now known as cprov-out [16:29] hi james_w, am now [16:29] hey Laney [16:29] how you doing? [16:29] excellent, got a frappucino therefore life is good [16:29] you? [16:30] meh [16:30] damnit [16:30] good thanks, feeling a bit fragile today though :-) [16:30] are you up for some mono today? [16:30] * Nafallo knows where he'll be working from tomorrow now ;-) [16:30] I love a bit of mono [16:30] where's that? [16:31] I was hoping to prioritise the 1.0 libs (which will ftbfs) [16:31] james_w: Cafe Brera, Jubilee Place, Canary Wharf :-) [16:31] heh [16:31] Laney: sounds sensible [16:32] Laney: was it you that already did a bunch of the libraries? [16:32] nop, slangasek did [16:33] cool [16:33] Laney: there's no dependency ordering requirement is there? [16:33] I don't think so [16:34] I'll start uploading then :-) [16:34] if you're doing pkg-cli-libs ones it would be cool if you could commit to svn too [16:34] hmm [16:35] I was going to suggest you take those ones, as you can commit, and I'll do the others [16:35] sure [16:35] libavahi1.0-cil <- should that be renamed? [16:35] don't think so [16:35] but... not suer [16:35] sure* [16:36] directhex: ^? [16:42] maxb, because msp430-binutils sounded better? [16:45] There's a mix of foo-binutils and binutils-foo packages in the archive, but there seem to be more binutils-foo than the other [16:47] Is there any MOTU around who'd have a more official opinion on whether cross-build binutils packages should standardize on -binutils or binutils- for package name? :-) [16:49] maxb, in my binutils I have a build dep on binutils source then do a symlink into my package folder and extract this, is this the best way to do this or just extract the source into my package folder and forget the symlink [16:49] ? [16:51] I followed the avr-binutils package there [16:51] Laney: when I forward these to Debian, should I add a note that they shouldn't apply the changes yet? [16:51] the transition has started [16:51] I know meebey has uploaded some libs already [16:52] ok [16:57] james_w, any chance you can re-approve evolution-mapi? I've fixed some issues mentioned by didrocks [16:57] jelmer: sure [16:58] james_w, I just uploaded the wrong version [16:58] james_w, Sorry, will upload the proper one now [16:58] james_w, Clumsy me :_/ [17:00] AdamDH: As I mentioned in my REVU comment, I don't think you should use binutils-source at all [17:00] Here's a really odd FTBFS if someone is looking for a puzzle: https://launchpad.net/ubuntu/+source/qbittorrent/1.3.1-1/+build/861020/+files/buildlog_ubuntu-jaunty-sparc.qbittorrent_1.3.1-1_FAILEDTOBUILD.txt.gz [17:00] james_w: Fixed [17:01] hmm... need the config.log from that FTBFS really [17:01] right maxb I know what to do now to get the versioning correct on that, I will fix that now and reupload to revu [17:01] thanks again for the help [17:03] AdamDH: when you're doing a new upload, have a look at the autodetected problems that REVU has flagged [17:04] I think they were moaning about the werid version I was using [17:04] o [17:04] * no [17:07] http://revu.ubuntuwire.com/p/msp430-binutils, See the big red !. Btw, if you change the versioning as I suggested, you can probably copy the debian/watch from binutils. Though update it to version 3. [17:08] I don't think it needs any changes other than just bumping the version number [17:11] jelmer: done [17:11] didrocks: care to re-review evolution-mapi? [17:11] why do I need a watch file maxb? [17:13] james_w, thanks! [17:21] james_w: yep. I posted some comments :) [17:21] jelmer: if you can have a look at them [17:26] let me review the new version :) [17:29] jelmer: why didn't you take my advice concerning debian/watch? [17:31] jelmer: I think I might have a cache issue because I don't see any change when downloading the source package :/ [17:34] didrocks, I did fix that issue [17:35] jelmer: can you paste somewhere the debian/watch file so that I can check if I have a cache issue, please? [17:36] didrocks, http://samba.org/~jelmer/tmp/evolution-mapi_0.25.91-0ubuntu1.diff.gz [17:38] jelmer: much better. I think there is something with my ISP :) [17:38] jelmer: but I think I would have done:http://ftp.gnome.org/pub/GNOME/sources/evolution-mapi/([\d\.]+)/ \ [17:38] instead of: [17:38] http://ftp.gnome.org/pub/GNOME/sources/evolution-mapi/([\d\.]+)[0-9]/ \ [17:43] jelmer: let me check before uploading new changes [17:45] jelmer: appart from that all seems ok. I can change debian/watch directly if you wish :) [17:46] I am just interest in the lintian warning, let me experiment ^^ [17:46] interested* [17:49] maxb: I have addressed your issues of the source and have corrected this http://revu.ubuntuwire.com/p/msp430-binutils do you mind having another look over it please? Are there any other motus with some free time to look over the package please? === jcastro_ is now known as jcastro [18:38] how do you correctly add a version to something that comes from CVS and has no upstream version? [18:39] jelmer: just tell me if you want that I do the change myself or you do it. I will then advocate it and upload it [18:40] didrocks, I'm happy with you making the change [18:42] ok :) [18:57] jelmer: new package uploaded congrats :) [18:58] didrocks, thanks [18:58] didrocks, no need for a FFE? [18:58] jelmer: seb128 gave it [18:59] didrocks, ah, cool [18:59] jelmer: hum, he didn't write it on the bug. I will ask him on Monday [19:03] didrocks: he doesn't usually write those ;) [19:03] "paperwork" :) [19:03] pochu: yeah, I'm getting used to know him ;) [19:09] Amarok will use MySQL by default in Jaunty, or? [19:09] It does [19:09] mysqle [19:09] There are not choices. [19:12] ScottK: OK, thanks. [19:12] * RainCT closes a Brainstorm idea about having MySQL by default [19:12] You're welcome. [19:13] TheMuso: did the bmpx package work on powerpc? :) [19:21] any one know an example of a meta package? [19:22] had a look through packages.ubuntu.com could not find one [19:23] savvas: If you're looking for a package to work on keysafe needs some work for Python transition. [19:23] AdamDH: ubuntu-meta [19:25] thanks ScottK [19:25] * savvas takes a peek :) [19:25] AdamDH: what do you want to do? [19:26] RainCT just playing around, got my 3 packages working and on revu so just wanted to see what else could be done [19:27] AdamDH: Ah. Because iirc ubuntu-meta is rather weird; you can get a simple meta-package just by creating a normal, but empty, package [19:28] RainCT do you mind taking a look at my packages here please: http://revu.ubuntuwire.com/p/msp430-binutils and http://revu.ubuntuwire.com/p/msp430-gcc ? thanks [19:28] ubuntu meta does look a little weird [19:30] AdamDH: we are in FF [19:30] * RainCT doesn't revu packages anymore unless they have a FFe [19:31] I know we are in FF, just after some feedback as they are my first packages, we are going to use them from my PPA, then when the next cycles comes around I will build them for that [19:31] *cycle [19:32] AdamDH: if that mega-long FSF copyright line is for autotools, it isn't necessary [19:33] (additionally, I think it's fine to group copyright years.. 2001, 2002, 2003, 2004 -> 2001-2004) [19:33] ah just noticed that, the file was created from a script, I will modify that [19:33] AdamDH: Maintainer should be MOTU, not Core Dev. Also, if you upload to your PPA please use something else [19:33] short description is missing [19:34] directhex: interesting (regarding RAM usage); since this app doesn't really remember more than a 1MB text file and a couple KB fragments I don't think it'd be a great candidate, but from anecdotal experience I'm inclined to agree [19:34] AdamDH: changelog should close a needs-packaging bug (with "LP: #xxx"), I see no point for the X-Description in copyright, and looks fine otherwise on a very quick look [19:34] so if its in my ppa I can use myself as the maintainer? just that when I ran dpkg-buildpackage -S -sa it said I did not have an @ubuntu email address so I changed it [19:35] directhex: btw the testing with Mono was done with a 2.2 build but I was too lazy to bring up a later IPY release [19:35] thanks RainCT [19:35] jdong_, IMHO it's worth testing ipy2, if you find time [19:35] jdong_, if anything i'm curious [19:35] jdong_, since you have mono 2.2, ipy2 should work fine [19:35] directhex: the production version of this code was running with stock Hardy Mono and it was nonetheless WAY faster than the python version [19:36] but yeah I'll try to get ipy 2.2 here [19:36] jdong_, well, yes. despite what some people think on the interwebnets, python's a fatass compared to mono ;) [19:37] directhex: heh without a doubt I knew from before Python for tightly arithmetic loops could be a factor of 600 to 1000 slower than plain C [19:37] I just never expected myself to write a program where that would hurt me [19:37] and I thought in that case I'd have to resort to Java or C [19:37]