[00:08] <AdamDH> grr I cannot build a source package but I can build a working debian package?
[00:09] <AdamDH> the orig source is in the correct format but I get: dpkg-source: unrepresentable changes to source when running debbuild -S -sa
[00:10] <directhex> AdamDH, which either means your clean rule doesn't work, or you have binary bits & pieces in your diff
[00:11] <AdamDH> directhex, in my package folder I have a tar.gz file of the upstream source, would this be the issue?
[00:11] <AdamDH> I am also getting allot of dpkg-source: warning: ignoring deletion of file
[00:12] <AdamDH> 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] <jdong_> directhex: I think as a mono person you might find this interesting: http://scripts.mit.edu/~jdong/wiki/moin.cgi/LangShootout
[01:20] <jdong_> a bit of a high-level-language shootout that stemmed from a project I was working on the last few days
[01:21] <jdong_> not that any of the results are surprising IMO
[01:21] <ajmitch> jdong_: I'm sure it's completely biased ;)
[01:22] <ajmitch> interesting to see how much slower ironpython is
[01:23] <jdong_> ajmitch: yeah I was kinda shocked by that
[01:23] <AdamDH> 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] <ajmitch> do you have universe enabled in pbuilder, in case it can't find that package?
[01:26] <AdamDH> I think universe was enabeled, how can I check?
[01:27] <ScottK> pbuilder login and the look in /etc/apt/sources.list
[01:27] <ajmitch> quickest way is to use pbuilder login, try & install binutils-source in the chroot
[01:27] <ajmitch> or that
[01:28] <jdong_> ajmitch: heh irony. it is biased.
[01:28] <ajmitch> jdong_: in what way?
[01:28] <jdong_> ajmitch: list.append() in python is a LOT more expensive than I would've thought.
[01:29] <AdamDH> I am just updating the chroot again just in case something went wrong, will check when that has finished getting a release
[01:29] <jdong_> ajmitch: repalcing list.append() with indexing a preallocated list brings it down from 80s to 25s
[01:29] <ajmitch> does it affect ironpython at all?
[01:29] <jdong_> ajmitch: still IMO (1) slower than the alternatives (2) a ridiculous difference for what seems to be a trivial change.
[01:30] <jdong_> oh crap
[01:30] <jdong_> wait
[01:30] <jdong_> I still leeft psyco in there
[01:30] <jdong_> *smacks himself*
[01:30] <jdong_> OK, retesting python and ironpython :)
[01:30] <ajmitch> skillz
[01:31] <jdong_> I wouldn't expect 4 * (list.append(foo) to be THAT much slower than list=[0,0,0,0], x[0]= ...
[01:31] <ajmitch> depends on how many times you're running it
[01:31] <ajmitch> maybe a chance to play with the python profiler
[01:32] <jdong_> 81.9s
[01:32] <jdong_> uhh.
[01:32] <ajmitch> slower than before?
[01:32] <jdong_> y.. yeah
[01:32] <ajmitch> awesome
[01:32]  * jdong_ attempts to reproduce.
[01:33]  * ajmitch sees that the RC bugs list thing has grown recently
[01:35] <jdong_> ajmitch: 77.8, 81.9 vs 77.5, 78.1 ("optimized" vs original)
[01:35] <jdong_> no significant difference.
[01:35] <jdong_> now to revisit ipy
[01:36] <ajmitch> still unbearably slow
[01:36] <jdong_> indeed
[01:37] <AdamDH> 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] <ajmitch> 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] <jdong_> ajmitch: brought ironpython from 400+s to 361s.
[01:43] <jdong_> still ridiculous though.
[01:43] <jdong_> the magical "-O" optimize flag shaves a whopping... FOUR SECONDS off :)
[01:43]  * sistpoty prefers ebony-python, makes +4 *g*
[01:48] <jdong_> ajmitch: oddly, Jython was penalized by the change; 97 -> 112
[01:50] <AdamDH> thanks ajmitch, that's going to come in handy
[02:00] <AdamDH> why would I get dpkg-source: warning: ignoring deletion of file? then is no clean rule that affects the files in question?
[02:00] <AdamDH> its doing it for all the source in my orig.tar.gz file
[02:24] <AdamDH> 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] <AdamDH> I am running pbuilder as root as well
[02:29] <jdong_> is the script a part of orig.tar.gz or created in the diff.gz?
[02:30] <AdamDH> created in the diff.gz
[02:33] <jdong_> remember that .diff's do NOT represent permissions.
[02:33] <jdong_> they only represent file content or lack thereof.
[02:34] <jdong_> in your case you'd want to use your rules file to chmod +x the script before executing it.
[02:34] <AdamDH> thanks, I will add that to my rules
[02:35] <AdamDH> I can just do chmod +x inside rules?
[02:44] <AdamDH> ah yes I can just do that!
[05:07] <dmz> 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] <directhex> 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] <directhex> jdong_, i'm mostly impressed by ikvm being usably fast (perhaps the packaging nightmare was worth it ^_^)
[08:08] <directhex> jdong_, feel like testing another metric, though? look at RAM consumption. java will likely use an order of magnitude more than mono
[09:28] <goshawk> hi, if someone has free time, can please review http://revu.ubuntuwire.com/p/dsss ? thanks
[09:40] <geser> 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] <AdamDH> any one know a package that uses get-orig-source?
[09:54] <StevenK> AdamDH: maximus, in jaunty
[09:55] <AdamDH> thankyou StevenK
[10:42] <goshawk> geser: you are right, it's an error
[10:58] <AdamDH> 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] <AdamDH> thanks
[11:15] <AdamDH> 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
[11:16] <RainCT> AdamDH:  --save-after-login
[11:16] <AdamDH> thanks RainCT
[11:23] <AdamDH> 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] <RainCT> AdamDH: and do the files actually exist?
[11:26] <AdamDH> inside the tar ball yes
[11:27] <geser> does the .orig.tar.gz perhaps contain files which are removed after a make (dist)clean?
[11:27] <AdamDH> I have not extracted the upstream tar ball just left it as .orig.tar.gz
[11:27] <AdamDH> geser not sure
[11:28] <AdamDH> the package is up on revu
[11:28] <RainCT> AdamDH: that's the problem, the .orig.tar.gz is supposed to be extracted
[11:29] <AdamDH> thanks RainCT I will extract it and try again
[11:29] <RainCT> Iou can most likely ignore that error, though. If you didn't touch anything outside debian/, the debuild should have worked fine
[11:30] <AdamDH> it builds the package fine
[11:30] <AdamDH> I am really starting to enjoy packaging
[11:30] <AdamDH> my first package took me a few days, the second one a few hours
[11:31] <RainCT> :)
[11:33] <AdamDH> 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] <StevenK> AdamDH: Cross-compilers are hard enough to *build* let alone package
[11:44] <AdamDH> 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] <lidaobing>  hello, I need a freeze exception for bug 335796
[11:47] <lidaobing> with out this sync, qterm will always crash under QT 4.5
[11:48] <AdamDH> I am all ready getting feedback and the packages have only been in my ppa for approx 12 hours
[12:18] <savvas> ScottK: looks like the bmpx powerpc builds fine on debian unstable: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517373
[12:21] <sladen> what's Pete Savage's IRC nick these days?  (or is he just not online as cbx33)
[12:25] <AdamDH> launchpad is really slow just dputed a package and had no email or anything appear in my ppa for like 30 mins
[12:54] <AdamDH> 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?
[14:04] <AdamDH> wow there are some messy packages out there
[14:17] <goshawk> 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] <AdamDH> 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] <goshawk> AdamDH: any tip is appreciated :)
[14:21] <goshawk> well... don't do it now, i'm fixing one more thing :)
[14:21] <AdamDH> i submitted my packages to revu today but I just found about 4 bugs!
[14:22] <savvas> goshawk: use http://revu.ubuntuwire.org from now on :)
[14:23] <goshawk> 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] <savvas> goshawk: do you know which parts are under artistic license?
[14:33] <goshawk> savvas: no, i should read the whole code to find it :(
[14:34] <goshawk> but if it's necessary i'll do
[14:34] <savvas> (I'm not a MOTU either btw) :)
[14:34] <goshawk> :)
[14:34] <savvas> let me check
[14:35] <savvas> Actually, I think the author should've stated clearly about each bit of code under which license is used
[14:37] <AdamDH> 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] <savvas> AdamDH: I have the same problem, some encoding error, right?
[14:39] <goshawk> AdamDH: thanks i'm reading
[14:40] <goshawk> AdamDH: but be careful: it's a proposal, i don't read that the policy is changed as described in that wiki
[14:40] <AdamDH> that format allows you to say what files belong to what packages looks like its ideal for your package
[14:41] <AdamDH> 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] <goshawk> ah perfect
[14:41] <AdamDH> but then I am waiting for some one to look at my packages in revu ;)
[14:41] <goshawk> so i'll switch to this one
[14:41] <goshawk> did you adopt this format too?
[14:41] <goshawk> inyour packages i mean
[14:42] <AdamDH> if you look at msp430-binutils in revu you will see that I adpoted that format
[14:42] <AdamDH> example: http://paste.ubuntu.com/124262/
[14:44] <savvas> 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] <goshawk> it's for rebuild
[14:45] <goshawk> uhm...
[14:47] <savvas> goshawk: yes, it's for most files in rebuild :)
[14:49] <savvas> here's a dirty way to look at file headers/comments: head rebuild/*.c
[14:49] <goshawk> ah... head i didn't know this program
[14:49] <savvas> head for first lines, tail for last lines :)
[14:49] <goshawk> and that rebuild.txt don't really belong to rebuild
[14:50] <goshawk> but to dmd
[14:50] <goshawk> This is the source code to the front end Digital Mars D compiler.
[14:50] <goshawk> well... you should know that rebuild is a code upon the DMD frontend (which is bot gpl 1 or artistic)
[14:51] <goshawk> so that readme says that the DMD part in rebuild are gpl or artistic
[14:51] <goshawk> not rebuild itself
[14:54] <goshawk> i'm contacting upstream to have a better explanation of this licence issue
[14:55] <savvas> is the project under GPL-2 by the way?
[14:58] <AdamDH> 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] <AdamDH> *compiled
[14:58] <savvas> "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] <savvas> http://www.dsource.org/projects/dsss
[14:59] <goshawk> yes i was looking for the same page
[14:59] <goshawk> mit with some parts under gpl v1 or artistic then... isn't it?
[15:02] <goshawk> i think the best solution is then to say that it's MIT licensed and some parts under rebuild are gpl v1
[15:02] <goshawk> isn't it?
[15:03] <savvas> I think so, give me a sec I'll show you an example
[15:04] <goshawk> you can take also two of them :) thx for what you are doing :)
[15:08] <james_w> Laney: yo, around?
[15:08] <savvas> goshawk: something like this: http://paste.ubuntu.com/124272/plain/
[15:09] <savvas> It's not like the proposal at debian which AdamDH pointed out, but it's humanly readable :)
[15:10] <goshawk> :)
[15:10] <goshawk> it's perfect
[15:10] <goshawk> :)
[15:10] <goshawk> thx
[15:11] <savvas> 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] <goshawk> already mailed :)
[15:11] <savvas> great!
[15:12] <c_korn> does anyone know why python-clutter is not in intrepid?
[15:12] <AdamDH> 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] <goshawk> AdamDH, savvas, thanks too much for the help you gave me :)
[15:14] <AdamDH> no worries, I am happy to put back into the open source community
[15:15] <savvas> 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] <savvas> goshawk: anytime :)
[15:17]  * RainCT shots at Firefox
[15:18] <RainCT> If someone figures out what the problem is, patches are welcome. I only support wget myself :P
[15:19] <savvas> I use dget :p
[15:19] <savvas> which works heh
[15:19] <AdamDH> with revu how do I upload a revisied package?
[15:20] <RainCT> dget actually uses wget (or curl) :P
[15:20] <AdamDH> *revised
[15:20] <RainCT> AdamDH: just like the first upload (and without changing the version number, REVU doesn't need that) :)
[15:20] <AdamDH> great I had to change that for launchpad
[15:20] <savvas> RainCT: it seems to be encoded twice in gzip
[15:21] <RainCT> savvas: Yes, but I don't know why.
[15:21] <savvas> http://paste.ubuntu.com/124282/
[15:21] <AdamDH> who wrote rvu ;)
[15:21] <AdamDH> *revu
[15:21] <RainCT> AdamDH: that's Apache madness :P
[15:22] <dantalizing> 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] <RainCT> dantalizing: I think so
[15:22] <james_w> yeah
[15:23] <dantalizing> thx
[15:28] <AdamDH> i think revu ate my package
[15:29] <AdamDH> 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] <AdamDH> 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] <james_w> directhex: are the rules the same for the library transition as for the apps?
[15:34] <james_w> directhex: is there an ordering requirement?
[15:36] <ScottK> james_w: I like your approach to update notification better than what I read Ubuntu has now.
[15:36] <james_w> ScottK: that wasn't my approach
[15:37] <james_w> ScottK: is was just fixing the bug with the existing approach.
[15:37] <james_w> and it doesn't work with the new notifications
[15:37] <ScottK> 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] <james_w> with the new notifications we can't fix the existing approach in that manner
[15:38] <ScottK> I think that limitation with the new notifications is unfortunate.
[15:38] <james_w> I think it is good
[15:39]  * Nafallo is with james_w
[15:39] <Nafallo> notifications wasn't notifications before.
[15:39] <james_w> I see it not so much as a limitation, but as a feature
[15:39] <ScottK> So it's good to hide updates from the user?
[15:39] <james_w> ScottK: that's not what I said at all
[15:39] <james_w> please don't put words in my mouth
[15:39] <ScottK> 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] <ScottK> OK.  Sorry.
[15:40] <james_w> correct
[15:40] <ScottK> I find that conceptually flawed.
[15:40] <james_w> I'm unsure about that change
[15:40] <james_w> however the new notification are a vast improvement in my opinion
[15:41] <james_w> 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] <ScottK> It'll be interesting to se how it works out.
[15:41] <james_w> for me, I don't need an indicator that I have pending updates
[15:42] <ScottK> How do you know?
[15:42] <james_w> I *always* have pending updates
[15:42] <ScottK> Heh.
[15:43] <Nafallo> talking about updates...
[15:43]  * Nafallo starts his jaunty running eeepc ;-)
[15:43] <a|wen> Nafallo: with intel atom?
[15:44] <Nafallo> a|wen: no. 701
[15:44] <a|wen> then no point in asking if you were testing the lpia port...
[15:45] <ScottK> Do we have any documentation about how to file Internal Compiler Error bugs?
[15:45] <ScottK> NCommander: ^^^? Do you know
[15:46] <james_w> a minimal test case is usually desired, but that's the hard part
[15:46] <ScottK> Yeah.
[15:46] <Nafallo> a|wen: nope
[15:47] <ScottK> 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] <RainCT> are simple-ccsm/compizconfig-settings-manager working in Jaunty?
[15:50] <savvas> RainCT: as in running? yes
[15:51] <RainCT> savvas: can you please tell me what shabang they have?
[15:51] <savvas> The following packages have unmet dependencies: python-urwid python-compizconfig python-cheetah python-libtorrent python-libtorrent python-launchpad-integration python-pysqlite2
[15:51] <savvas> python-compizconfig: Depends: python (< 2.6) but 2.6.1-0ubuntu1 is to be installed.
[15:51] <RainCT> Yeah, I have an update ready for that
[15:51] <savvas> what's a shabang? :P
[15:52] <RainCT> but it will loose 2.5 support, and I don't know if that will break simple-ccsm and compizconfig-s-m
[15:52] <RainCT> savvas: the first line in the file, starting with #!
[15:52] <savvas> oh
[15:52] <RainCT> cat /usr/bin/simple-ccsm | head -n1
[15:52] <savvas> hold a sec
[15:53] <savvas> $ cat /usr/bin/ccsm | head -n 1
[15:53] <savvas> #!/usr/bin/python
[15:53] <savvas> I'll try simple if you want to
[15:54] <RainCT> savvas: What does this say?   ls -l /usr/bin/python
[15:54] <savvas> $ ls -l /usr/bin/python
[15:54] <savvas> lrwxrwxrwx 1 root root 9 2009-02-27 10:59 /usr/bin/python -> python2.5
[15:54] <RainCT> OK, so you haven't python2.6 by default yet
[15:54] <goshawk> RainCT: about #292923
[15:55]  * RainCT looks at ubottu 
[15:55] <savvas> RainCT: should I? :\
[15:55] <goshawk> the https://wiki.ubuntu.com/SecurityUpdateProcedures says me to do tests using the QA regression testing
[15:55] <goshawk> but... i don't have any thought in how to use it with a php library :)
[15:56] <RainCT> savvas: Nvm, I don't want to be responsible for breaking your system :). Thanks!
[15:58] <savvas> RainCT: http://paste.ubuntu.com/124306/plain/
[15:58] <blueyed> 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] <RainCT> savvas: I think there's some PPA with updates packages, check ubuntu-devel (or some other list)
[15:59] <savvas> nah, I'll wait for aptitude safe-upgrade :P
[16:00] <savvas> so the shabang makes a problem?
[16:01] <RainCT> savvas: no, it's what I hoped for :)
[16:01] <savvas> ah ok :)
[16:01] <RainCT> if it was python2.5 we'd have a problem
[16:02]  * RainCT uploads
[16:03] <goshawk> RainCT: 292923 ready :P
[16:04] <a|wen> savvas: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-February/000541.html ... expect python havvoc the next short while
[16:05] <a|wen> and also if you wanted the link for the ppa
[16:05] <savvas> woohoo!
[16:05] <savvas> I'll try it on a virtual machine probably
[16:29] <Laney> hi james_w, am now
[16:29] <james_w> hey Laney
[16:29] <james_w> how you doing?
[16:29] <Laney> excellent, got a frappucino therefore life is good
[16:29] <Laney> you?
[16:30] <Nafallo> meh
[16:30] <Nafallo> damnit
[16:30] <james_w> good thanks, feeling a bit fragile today though :-)
[16:30] <james_w> are you up for some mono today?
[16:30]  * Nafallo knows where he'll be working from tomorrow now ;-)
[16:30] <Laney> I love a bit of mono
[16:30] <james_w> where's that?
[16:31] <Laney> I was hoping to prioritise the 1.0 libs (which will ftbfs)
[16:31] <Nafallo> james_w: Cafe Brera, Jubilee Place, Canary Wharf :-)
[16:31] <james_w> heh
[16:31] <james_w> Laney: sounds sensible
[16:32] <james_w> Laney: was it you that already did a bunch of the libraries?
[16:32] <Laney> nop, slangasek did
[16:33] <james_w> cool
[16:33] <james_w> Laney: there's no dependency ordering requirement is there?
[16:33] <Laney> I don't think so
[16:34] <james_w> I'll start uploading then :-)
[16:34] <Laney> if you're doing pkg-cli-libs ones it would be cool if you could commit to svn too
[16:34] <james_w> hmm
[16:35] <james_w> I was going to suggest you take those ones, as you can commit, and I'll do the others
[16:35] <Laney> sure
[16:35] <james_w> libavahi1.0-cil <- should that be renamed?
[16:35] <Laney> don't think so
[16:35] <Laney> but... not suer
[16:35] <Laney> sure*
[16:36] <Laney> directhex: ^?
[16:42] <AdamDH> maxb, because msp430-binutils sounded better?
[16:45] <maxb> 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] <maxb> Is there any MOTU around who'd have a more official opinion on whether cross-build binutils packages should standardize on <target>-binutils or binutils-<target> for package name? :-)
[16:49] <AdamDH> 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] <AdamDH> ?
[16:51] <AdamDH> I followed the avr-binutils package there
[16:51] <james_w> Laney: when I forward these to Debian, should I add a note that they shouldn't apply the changes yet?
[16:51] <Laney> the transition has started
[16:51] <Laney> I know meebey has uploaded some libs already
[16:52] <james_w> ok
[16:57] <jelmer> james_w, any chance you can re-approve evolution-mapi? I've fixed some issues mentioned by didrocks
[16:57] <james_w> jelmer: sure
[16:58] <jelmer> james_w, I just uploaded the wrong version
[16:58] <jelmer> james_w, Sorry, will upload the proper one now
[16:58] <jelmer> james_w, Clumsy me :_/
[17:00] <maxb> AdamDH: As I mentioned in my REVU comment, I don't think you should use binutils-source at all
[17:00] <ScottK> 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] <jelmer> james_w: Fixed
[17:01] <maxb> hmm... need the config.log from that FTBFS really
[17:01] <AdamDH> 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] <AdamDH> thanks again for the help
[17:03] <maxb> AdamDH: when you're doing a new upload, have a look at the autodetected problems that REVU has flagged
[17:04] <AdamDH> I think they were moaning about the werid version I was using
[17:04] <maxb> o
[17:04] <maxb> * no
[17:07] <maxb> 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] <maxb> I don't think it needs any changes other than just bumping the version number
[17:11] <james_w> jelmer: done
[17:11] <james_w> didrocks: care to re-review evolution-mapi?
[17:11] <AdamDH> why do I need a watch file maxb?
[17:13] <jelmer> james_w, thanks!
[17:21] <didrocks> james_w: yep. I posted some comments :)
[17:21] <didrocks> jelmer: if you can have a look at them
[17:26] <didrocks> let me review the new version :)
[17:29] <didrocks> jelmer: why didn't you take my advice concerning debian/watch?
[17:31] <didrocks> jelmer: I think I might have a cache issue because I don't see any change when downloading the source package :/
[17:34] <jelmer> didrocks, I did fix that issue
[17:35] <didrocks> jelmer: can you paste somewhere the debian/watch file so that I can check if I have a cache issue, please?
[17:36] <jelmer> didrocks, http://samba.org/~jelmer/tmp/evolution-mapi_0.25.91-0ubuntu1.diff.gz
[17:38] <didrocks> jelmer: much better. I think there is something with my ISP :)
[17:38] <didrocks> jelmer: but I think I would have done:http://ftp.gnome.org/pub/GNOME/sources/evolution-mapi/([\d\.]+)/ \
[17:38] <didrocks> instead of:
[17:38] <didrocks> http://ftp.gnome.org/pub/GNOME/sources/evolution-mapi/([\d\.]+)[0-9]/ \
[17:43] <didrocks> jelmer: let me check before uploading new changes
[17:45] <didrocks> jelmer: appart from that all seems ok. I can change debian/watch directly if you wish :)
[17:46] <didrocks> I am just interest in the lintian warning, let me experiment ^^
[17:46] <didrocks> interested*
[17:49] <AdamDH> 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?
[18:38] <AdamDH> how do you correctly add a version to something that comes from CVS and has no upstream version?
[18:39] <didrocks> 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] <jelmer> didrocks, I'm happy with you making the change
[18:42] <didrocks> ok :)
[18:57] <didrocks> jelmer: new package uploaded congrats :)
[18:58] <jelmer> didrocks, thanks
[18:58] <jelmer> didrocks, no need for a FFE?
[18:58] <didrocks> jelmer: seb128 gave it
[18:59] <jelmer> didrocks, ah, cool
[18:59] <didrocks> jelmer: hum, he didn't write it on the bug. I will ask him on Monday
[19:03] <pochu> didrocks: he doesn't usually write those ;)
[19:03] <pochu> "paperwork" :)
[19:03] <didrocks> pochu: yeah, I'm getting used to know him ;)
[19:09] <RainCT> Amarok will use MySQL by default in Jaunty, or?
[19:09] <ScottK> It does
[19:09] <ScottK> mysqle
[19:09] <ScottK> There are not choices.
[19:12] <RainCT> ScottK: OK, thanks.
[19:12]  * RainCT closes a Brainstorm idea about having MySQL by default
[19:12] <ScottK> You're welcome.
[19:13] <savvas> TheMuso: did the bmpx package work on powerpc? :)
[19:21] <AdamDH> any one know an example of a meta package?
[19:22] <AdamDH> had a look through packages.ubuntu.com could not find one
[19:23] <ScottK> savvas: If you're looking for a package to work on keysafe needs some work for Python transition.
[19:23] <ScottK> AdamDH: ubuntu-meta
[19:25] <AdamDH> thanks ScottK
[19:25]  * savvas takes a peek :)
[19:25] <RainCT> AdamDH: what do you want to do?
[19:26] <AdamDH> RainCT just playing around, got my 3 packages working and on revu so just wanted to see what else could be done
[19:27] <RainCT> 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] <AdamDH> 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] <AdamDH> ubuntu meta does look a little weird
[19:30] <RainCT> AdamDH: we are in FF
[19:30]  * RainCT doesn't revu packages anymore unless they have a FFe
[19:31] <AdamDH> 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] <AdamDH> *cycle
[19:32] <RainCT> AdamDH: if that mega-long FSF copyright line is for autotools, it isn't necessary
[19:33] <RainCT> (additionally, I think it's fine to group copyright years..  2001, 2002, 2003, 2004 -> 2001-2004)
[19:33] <AdamDH> ah just noticed that, the file was created from a script, I will modify that
[19:33] <RainCT> AdamDH: Maintainer should be MOTU, not Core Dev. Also, if you upload to your PPA please use something else
[19:33] <RainCT> short description is missing
[19:34] <jdong_> 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] <RainCT> 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] <AdamDH> 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] <jdong_> 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] <AdamDH> thanks RainCT
[19:35] <directhex> jdong_, IMHO it's worth testing ipy2, if you find time
[19:35] <directhex> jdong_, if anything i'm curious
[19:35] <directhex> jdong_, since you have mono 2.2, ipy2 should work fine
[19:35] <jdong_> 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] <jdong_> but yeah I'll try to get ipy 2.2 here
[19:36] <directhex> jdong_, well, yes. despite what some people think on the interwebnets, python's a fatass compared to mono ;)
[19:37] <jdong_> 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] <jdong_> I just never expected myself to write a program where that would hurt me
[19:37] <jdong_> and I thought in that case I'd have to resort to Java or C
[19:37] <jdong_> but Mono pleasantly surprised me here
[19:38] <directhex> jdong_, so when are canonical going to drop python for the superior c#? :p
[19:38] <jdong_> directhex: IMO when Boo gets a bit more mature :)
[19:38] <jdong_> directhex: C# is great but doesn't replace Python as a quick and dirty prototyping language
[19:38] <directhex> jdong_, your figures are largely what i expected, except for ironpython which i didn't expect to be incredible suck
[19:38] <ScottK> I suspect when they get a different set of developers.
[19:40] <directhex> jdong_, anyway, good for you on making those figures - i trust them a lot more than i trust the shootout on alioth
[19:41] <RainCT> anyone looking at
[19:41] <RainCT> python-wxgtk2.6?
[19:42] <jdong_> directhex: ok ipy 2.0.1 running
[19:42] <savvas> ScottK: there's version 0.4-1 at debian - the maintainer removed the 2.4 dependencies :) http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=keysafe
[19:42] <directhex> NCommander, installing jaunty in armel qemu... how long exactly is it meant to hang on "configuring makedev"?
[19:42] <ScottK> Is it uploaded yet?
[19:43] <directhex> oh, bollocking hell..... the screen stops updating. that's it. gah!
[19:43] <savvas> ScottK: no, not yet unfortunately - should I proceed and remove these? There was supposed to be a "0.3.5-4.1" version where they remove the 2.4 dependencies, but can't find it
[19:44] <ScottK> savvas: I'd look at the proposed package and update ours similarly.
[19:46] <savvas> ScottK: ok, I'll try :)
[19:48] <jdong_> directhex: unfortunately ipy2 doesn't seem to perform any better
[19:48] <jdong_> it has been running for almost 5 minutes now
[19:48] <directhex> jdong_, hm, shame
[19:48] <jdong_> directhex: indeed; there's something about this workload that trips it up
[19:58] <jdong_> directhex: heh I was really surprised how close ikvm got to C# and Java; I expected it to be a second-class .NET citizen
[19:58] <blueyed> For a rebuild of 0-ubuntu1, should I use 0-ubuntu2 or 0-ubuntu1build1 for the version? (I cannot find a wiki page about it)
[19:58] <directhex> jdong_, i'm pondering goals for karmic. i wonder whether packaging things like ironruby has any value
[19:59] <jdong_> directhex: well I'd definitely like to see our Mono stack up to date with upstream again for Karmic...
[19:59] <jdong_> I'm not sure how mature IronRuby itself is
[20:01] <directhex> jdong_, 2.2 introduces issues for a bunch of apps, we decided to skip straight to 2.4
[20:01] <directhex> maybe 2.6 depending on release schedules
[20:01] <jdong_> directhex: ah, interesting
[20:01]  * asomething wonders if there's any grunt work for a contributer, maybe with universe python rebuilds?
[20:01] <Laney> directhex: ^ POUNCE!
[20:02] <Laney> brb
[20:02] <directhex> asomething, pfft, python sucks. jdong_ proved it. how about some mono work? :p
[20:02] <jdong_> haha
[20:02] <asomething> directhex: what do you got? =)
[20:02]  * jdong_ has started yet another language war :)
[20:02] <directhex> asomething, see http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO ?
[20:03] <jdong_> the last time I did a shootout was in a Java class, I thought the code was running unreasonably slow so I rewrote it in C
[20:03] <jdong_> to my surprise the C version was even slower.
[20:03] <directhex> asomething, every red item in the jaunty column needs to be green, following the guide on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669
[20:04] <directhex> asomething, if the maintainer is "pkg-cli-libs" then your work can go directly to debian & be synced
[20:05] <asomething> directhex: cool, I'll look through it and garb a package or two
[20:12] <directhex> jdong_, could always discuss the matter at UDS :p
[20:19] <RainCT> blueyed: ubuntu2
[20:20]  * RainCT adds jdong_ to his blacklist, right behind directhex :D
[20:22] <savvas> ScottK: should I make it look like a merge? I can't find the debian packages for keysafe versions 0.3.5-4.1 and 0.3.5-3, so I don't know what are the actual changes
[20:22]  * directhex uses his pkg-cli-apps powers to purge RainCT's packages
[20:22] <savvas> package wars, heh
[20:23] <savvas> better than throwing shoes :p
[20:23] <RainCT> lol
[20:23] <directhex> savvas, xchat lacks a /shoe
[20:23] <ScottK> savvas: I'd just look at their changes and make the appropriate ones to our package to solve the python problem.
[20:23] <RainCT> directhex: and I'll soon get another package in there.. :(
[20:23] <directhex> RainCT, which one?
[20:23] <jdong_> directhex: (0, 241363, 'jackpot is ', 'here!\n\n\n\n\n\n\n\n\n\nafwefj\nwejf\nawejp\nfjaew\nj') 2122.07945251
[20:23] <jdong_> *YEA BABY*
[20:24] <directhex> jdong_, ouch :|
[20:24] <jdong_> obviously ipy2 isn't the end all solution to slow python apps ;-0
[20:24] <RainCT> directhex: mistelix, it's a video editor from the same author as gbrainy
[20:24] <directhex> jdong_, worth discussing with #ironpython ?
[20:24] <savvas> ScottK: oh, the python problem is solved, I just removed '2.4' from the name of the dependencies: http://launchpadlibrarian.net/23231836/keysafe_0.3.5-2_0.3.5-2ubuntu1.diff.gz
[20:24]  * RainCT raises eyebrows at jdong_ :P
[20:25] <savvas> ScottK: I thought you also wanted to improve the copyright as the maintainer did :)
[20:25] <jdong_> directhex: Idon't have the time to follow up on it but if you feel like it, sure
[20:25] <RainCT> jdong_: what is that supposed to be? :P
[20:25] <jdong_> RainCT: it's a fuzzy substring matcher
[20:25] <ScottK> savvas: I didn't look.  If there are other worthwhile packaging improvements, I'd grab those too.
[20:25]  * ScottK is on the way out the door
[20:25] <savvas> ScottK: ok, thanks! :)
[20:25] <jdong_> RainCT: for example, needle="this is a botched song lyric" vs haystack "blah blah this is the real song's lyrics" would match the "this is the real ... " with some positive "edit distance" score.
[20:26] <directhex> jdong_, i wonder if the slowness is due to the DLR on mono, or ipy in general
[20:26] <RainCT> jdong_: uhmmmmmm... okay :P
[20:26] <jdong_> directhex: would be interesting to know, and also interesting to find out which operation in the python code is causing the regression
[20:26] <jdong_> directhex: but the code for it is on my langshootout page linked earlier
[20:27] <jdong_> RainCT: it's for a random bot that I wrote which can pick up the next line of a song if you give it the one before
[20:27] <jdong_> to allow for spelling and memory inaccuracies it uses this fuzzy substring matcher
[20:28] <jdong_> the python version took 40-50 secs to return a match when the C# version takes 2 or 3 :)
[20:28] <RainCT> ah, nice
[20:28] <directhex> jdong_, which version are you deploying then? java?
[20:28] <RainCT> make a python library :P
[20:28] <jdong_> directhex: C#
[20:28] <jdong_> directhex: it's fast enough and in a language I enjoy maintaining.
[20:29] <jdong_> it also uses Xapian as a top-level filter to weed out 200 candidate songs out of 2000 or so in its library, so the chances of hitting its worst-case runtime are relatively low.
[20:34] <directhex> "generating locales" on arm in qemu is HELLISH
[20:38] <AdamDH> I have a full working msp430 toolchain, took a while, but it works
[20:55] <savvas> wow, launchpad ppa is quick today
[21:04] <dmz> howdy y'all, i just got my base system live cd running great, now i need to be able to install it onto a local disk. i have install ubiquity but do not know what to run when it boots to get it to install, any suggestions?
[21:06] <savvas> dmz: I think you should ask that question in #ubuntu :)
[21:06] <dmz> ok, sorry it was mentioned to me that motu was for people building custom installs
[21:07] <savvas> dmz: oh, I don't know about that, motu manage the packages in the ubuntu universe repository - but stick around, maybe someone else knows
[21:08] <a|wen> dmz: you might want to look at uck (ubuntu customization kit) if you are making a custom cd?
[21:08] <savvas> RainCT: do I have to open a bug number for package keysafe python transition?
[21:09] <savvas> or anyone else :)
[21:09] <dmz> thanks i'll check that; too many different references :)
[21:11] <a|wen> dmz: afaik it has been uploaded to jaunty/universe ... before that they have a deb at their site http://uck.sourceforge.net/
[21:15] <RainCT> savvas: Do you need sponsorship?
[21:15] <RainCT> if so, yes
[21:16] <savvas> RainCT: ah, yes - ok :)
[21:16] <AdamDH> how do I stop stripping inside my packages? if the package strips the libraries then the result is that nothing will compile with the cross compiler, I have stopped dh_strip but that has not seemed to help
[21:21] <asomething> directhex: taking a shot at notify-sharp, it builds in pbuilder, how's this look: http://paste.ubuntu.com/124443/
[21:21] <Laney> asomething: It should be /usr/bin/csc
[21:21] <directhex> asomething, set GMCS to /usr/bin/csc, and check your build log to make sure it's being used
[21:22] <Laney> hax
[21:22] <asomething> ok
[21:22] <ian_brasil> i just packaged gypsy and out it in my ppa..if someone can take a look
[21:24] <ian_brasil> https://edge.launchpad.net/~ianlawrence/+archive/ppa
[21:29] <asomething> alright, changed it to csc and it still builds. and I see "checking for gmcs... /usr/bin/csc" in the log
[21:30] <Laney> look at the actual build
[21:30] <Laney> sometimes it's ignored :(
[21:32] <asomething> how about "/usr/bin/csc -out:notify-sharp.dll"
[21:32] <directhex> asomething, then it's fine :)
[21:33] <asomething> should I format the patch for debian and just submit it there?
[21:33] <directhex> yes
[21:34] <asomething> will do
[21:34] <directhex> or just shove it on pastebin & laney or i can add it to svn right away
[21:34] <Laney> I am too busy eating a home made pork pie
[21:34] <Laney> nomnomnom
[21:35] <directhex> home-made? does it still contain 48% aspic jelly?
[21:36] <Laney> erm
[21:36] <Laney> the jelly is made from boiled up pig bits
[21:40] <Laney> mok0: Are you going to patch requestsync to remove the please? ;)
[21:41] <asomething> here it is formatted for debian: http://paste.ubuntu.com/124456/
[21:45] <rgreening> ScottK: my MOTU application is completed. Just needs sponsor input. I;ve added myself for March 13th meeting as well.https://wiki.ubuntu.com/rgreening/DeveloperApplicationMOTU
[21:45] <rgreening> Thanks for all your help ScottK
[21:50] <rgreening> hey didrocks
[21:52] <directhex> asomething, seems fine to me, let me test it quicksharp
[21:55] <didrocks> rgreening: yep? :)
[21:56] <rgreening> didrocks: I decided to take the next step and apply for motu. finally :)
[21:56] <didrocks> rgreening: congrats \o/ hope everything will be ok :)
[21:56] <rgreening> :)
[21:57] <didrocks> Laney: this is a mandatory, patch requestsync :)
[22:10] <directhex> dpkg-deb: building package `libnotify0.4-cil' in `../libnotify0.4-cil_0.4.0~r2998-2_all.deb'.
[22:34] <wgrant> Are we meant to rebuilding everything we run into for Python 2.6, or is there going to be some massive scripted upload eventually?
[22:35] <james_w> if it needs rebuilding it should be I believe
[22:36] <wgrant> That's what I thought. Thanks.
[22:37] <Nafallo> wgrant: if you're going to rebuild stuff, feel free to add revelation to your list :-)
[22:42] <AdamDH> grr cannot get my package to not strip all libraries are ruined because they are currently been stripped, I am using arch amd64, any ideas how I can stop stripping or suggest a package where stripping has been stopped so libarys can be built correctly?
[22:42] <AdamDH> dh-strip has been removed from my rules but I can still watch the files been stripped
[22:52] <geser> AdamDH: have you a build log? pbuilder or buildd?
[22:54] <AdamDH> there are no errors is only when you come to use the package with test code you get: msp430/bin/ld: skipping incompatible /usr/lib/gcc-lib/msp430/3.2.3/libgcc.a when searching for -lgcc
[22:54] <AdamDH> so I think the libc is been compiled wrong somewhere
[22:59] <geser> AdamDH: what does file tell on the contents of that libgcc.a?
[23:00] <AdamDH> looks like its been compile for my native host instead of the msp430 host
[23:01] <AdamDH> *compiled
[23:01] <AdamDH> so its an issue with there Makefile
[23:01] <geser> cross-compiling is not easy (as far as I can tell). Please check if the upstream Makefile uses the correct compiler
[23:03] <savvas> mplayer has an easy config for cross compilation hehe
[23:05] <AdamDH> i might take a look at the mplayer source
[23:05] <AdamDH> i think there makefile is the problem here as the arguments are not passed
[23:19] <RainCT> Arr.. wxwidgets is placing the Python 2.6 stuff in /usr/*local*/lib and FTBFS.. :S
[23:21] <RainCT> pochu: any clue?
[23:26] <blueyed> Is there a known problem that rebuilds of Python apps land in /usr/local now? (using python-central). Bug 335941 has more details and the build log.
[23:26] <RainCT> blueyed: just happened to me
[23:27] <blueyed> Have you found the reason for it yet?
[23:27] <RainCT> No :(
[23:28] <pochu> RainCT, blueyed: try with to add --install-layout=deb to the setup.py call
[23:29] <pochu> s/with//
[23:29] <RainCT> oh, right
[23:29] <pochu> RainCT, blueyed: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027439.html
[23:31] <RainCT> damn.. site-packages is hardcoded like 10 times in the rules file
[23:32] <RainCT> Does {site-packages,dist-packages} work in debian/rules?
[23:33] <blueyed> Why would you need both?
[23:33] <RainCT> blueyed: module for all python versions
[23:33] <blueyed> ok. I'm not sure, if the expansion works. I'd say no.. but don't remember..
[23:36] <RainCT> well, I'll try with wildcards
[23:37] <pochu> RainCT: {,} is a bashism, so not sure
[23:38] <RainCT> oh, didn't know this
[23:38] <wgrant> It must have been done in some other package already.
[23:38] <pochu> but wildcards will be fine :)
[23:38] <blueyed> pochu: thanks for the hint, it works for me/duplicity.
[23:38] <pochu> I believe doko is using *-packages
[23:39] <pochu> blueyed: cool
[23:39] <RainCT> yeah, that's what I've done too
[23:39] <RainCT> and now I can wait 30 minutes for the package to build..
[23:40] <RainCT> perhaps I should just update and see if LP fails again, as I'm going to bed soon :P
[23:41] <wgrant> Hmmm, see http://launchpadlibrarian.net/23118516/smart_1.1.1~bzr20081010-0ubuntu0.8.10.1_1.1.1~bzr20081010-0ubuntu0.8.10.2~ppa1.diff.gz.
[23:41] <wgrant> *-packages is used, but not everywhere.
[23:43] <wgrant> I wonder why python.mk wasn't advertised anywhere...
[23:46] <wgrant> doko: Are we meant to be using python.mk to solve this problem?
[23:48] <phil_ps> how do I change /etc/apt/sources.list to get the latest?
[23:48] <wgrant> phil_ps: "the latest"?
[23:48] <phil_ps> sorry, jaunty
[23:48] <phil_ps> I want to test my patch in jaunty but I am running intrepid
[23:49] <wgrant> You probably do not want to upgrade to Jaunty.
[23:49] <wgrant> Consider using a chroot (perhaps using pbuilder or schroot) to test instead.
[23:49] <phil_ps> okay thanks
[23:56] <RainCT> phil_ps: see http://bloc.eurion.net/archives/2009/test-build-debian-packages/ :)
[23:57] <phil_ps> thanks RainCT
[23:57] <RainCT> (it's used to build packages but you can also login -«pbuilder-jaunty login»- to try out stuff in the terminal; if you want to test GUI stuff you'll need a VM, though)