[00:00] directhex: Can I borrow it? [00:00] jms@orac:~> grep -c ^processor /proc/cpuinfo [00:00] 256 [00:00] ! [00:00] I like [00:00] But I don't know why you'd deliberately introduce a known broken hashing algorithm [00:00] kolby: If you want an educational tool then make a nice GUI for learning with it [00:01] * kolby runs "grep -c ^processor /proc/cpuinfo" returning 4. [00:01] jms@orac:~> free -g | grep Mem [00:01] Mem: 985 30 955 0 0 19 [00:01] 4<256... except today. It's opposite day [00:02] Laney: what would possibly be the benefit of adding a GUI to a hashing algorithm program? [00:02] to make it an educational tool [00:02] which is the use you want it for [00:03] example use: gdb md4sum *.avi hashy [00:03] thing is, the day md4sum hits the archive, the security team launches a tactical nuke at your house [00:03] education is therefor born. [00:03] this is most unconvincing [00:04] It's a great package! [00:05] md4sum is faster. [00:05] most people don't know how to break it. [00:05] most people have _no_idea_ what it is. [00:05] who cares about most people? [00:05] so it's fine to include in the repos [00:06] most people don't want to break your software [00:06] Yes, further justifying our point. [00:06] but the fact is you cannot trust md4 because it is *so easily broken by anyone who takes two seconds to find out how* === perlluver is now known as brandon_p [00:07] directhex has a super-computer. He doesn't count. [00:07] 7 seconds was on my laptop. [00:07] i don't feel like vexing the itaniums this evening. [00:08] directhex: laptop with 256 processors... [00:08] directhex: try breaking md4sum's daughter: md5sum with your mighty processing power. [00:09] no, laptop with a core 2 duo. office machine with 256 cores. [00:09] If PS3s can do it, your set up should work. [00:09] and i think you underestimate the cost of electricity [00:09] directhex: I don't have to pay it actually. [00:09] directhex: I'm living on a military base. [00:09] directhex: good luck with your bomb [00:10] ask them about using md4 [00:10] they should know a thing or two [00:10] why bother the IT dep. over something so abviously simple? [00:10] md4sum is a great experience. [00:11] like swimming. [00:11] how are you not convinced? [00:11] We are not about to deliberately introduce a program with security flaws [00:11] * Laney -> shower [00:11] lol. [00:12] fine... md4sum breaker-ers [00:12] I'll go bother debian. [00:12] haha [00:13] good luck! [00:13] it's not like I packaged a virus. [00:13] just a great historical application. [00:13] who will know of md4sum and it's wonderful eDonkey powers now? [00:14] ...debian... [00:14] lol [00:14] alright that was my last try. Thanks for participating. Sincerely. [00:15] I was packaging this program to learn how to make Ubuntu packages. [00:16] I realized it could be part of Jaunty and it made feel a great sense of pride in my labor. [00:17] I'm pretty sure the packaging is flawless by now, though. [00:17] kolby: You do realize the arguments against it have nothing to do with the quality of your packaging, right? [00:18] ScottK, *sigh* yes. I just want someone to review it. [00:18] kolby: I'll look at it to give you feedback on your learning experience, but I won't advocate it goes in the archive. [00:19] ScottK thanks. ^^ [00:19] ScottK, where will it go? Bad-package heaven? [00:20] it will more than likely stay on my hard-drive. [00:20] I should probably uninstall it. [00:21] weak-hashing-algorithm-haters... [00:21] thank you all. [00:22] all the cool kids use quadruple rot13 these days [00:23] directhex: thanks for your feedback, btw [00:48] kolby: Reviewed. Generally technically good, but licensing is a disaster. [00:48] * ScottK needs to run. [00:48] thank you === rofl is now known as Kalidarn [03:25] Greetings room. [03:28] Hello Dante_J [03:29] I have a question regarding patches. I'm using 8.04.2 and wondering why are the patches so delayed? None a all or February so far. [03:29] Under Fedora there has been the security patch for Firefox, sudo & Nss. For Ubuntu so far nothing. Is there a problem? Here's an example: [03:29] https://lists.ubuntu.com/archives/ubuntu-security-announce/2009-January/date.html [03:29] https://www.redhat.com/archives/fedora-package-announce/2009-February/date.html [03:30] I'm just curious and a little concerned, not attempting to apportion blame. [03:33] Please do let me know if this question should be addressed elsewhere. I was thinking of preparing a Digg story about this situation, but wanted to understand it first before posting anything. [03:41] I really hate being the whiner, seriously. I'd just like to get a handle on the current status. [03:42] nhandler: Thank you for your greeting. [03:42] I guess I should leave you all in peace. Cheers. :/ [03:43] * RAOF has obviously missed the start of this. [03:43] Dante_J: I would suggest coming back here at a different time. Most developers are gone right now [03:43] thanks nhandler [03:43] RAOF: He is wondering why fedora got a security update for sudo and we haven't [03:43] * nhandler doesn't know enough about the update [03:43] that was my question [03:46] * RAOF doesn't know _anything_ about the update. [03:46] But sudo's firmly in main; #ubuntu-devel should contain more people who know about it; there might even be an #ubuntu-security. [03:47] Also under Ubuntu is Firefox is unpatched at 3.0.5 [03:47] among other packages. [03:47] It's _actually_ unpatched, or just doesn't have a version bump? [03:47] Not patched. [03:47] Dante_J: firefox 3.0.6 is actually in jaunty [03:47] Insecure. [03:47] http://secunia.com/advisories/33799/ [03:48] not patched in Hardy [03:48] which is often used in labs, & by corporates. [03:48] Dante_J: I would talk to some of the people on the security team. They would have more knowledge about this stuff [03:49] thank you nhandler [03:49] Both firefox & sudo are in main; #ubuntu-devel is where you'll have people who deal with main. [03:49] thanks RAOF :) [03:50] hi [03:50] Hello afner [03:50] Hi afner [03:50] Have a great day. [03:50] * Dante_J waves [03:50] how are you? [03:51] you too have a grat day [03:51] great [03:51] nhandler hi [03:53] Anyone able to review webgui for me please? http://revu.ubuntuwire.com/p/webgui [03:54] jmarsden: I'll take a look [03:54] Thanks! [04:03] If someone has a chance to look at pyproj (http://revu.ubuntuwire.com/p/pyproj) I'd appreciate it - I believe I resolved issues that fabrice_sp identified this afternoon. [05:28] good morning [05:31] Good morning. [05:32] hi scottK [05:50] Good morning dholbach. Morning ScottK [05:50] hiya fabrice_sp [05:53] o/ [06:21] * nixternal hugs dholbach [06:22] * dholbach hugs nixternal back :) === bluesmoke is now known as Amaranth [07:08] good morning :) [08:38] hello. is it likely that scilab-5 makes it into jaunty? https://bugs.launchpad.net/debian/+source/scilab/+bug/272264 [08:38] Ubuntu bug 272264 in scilab "Please sync scilab-5.0.3 (multiverse) from PPA" [Wishlist,Confirmed] [08:38] there are a few missing dependencies which have to be synced before (jeuclid for example which is not in debian, yet) [08:40] c_korn, NEW joy? that one rings a bell [08:40] yeah. 7th in NEW === bastiao_ is now known as k0p [08:42] jeuclid, xmlgraphics-common, fop and java-wrappers would need to be synced before scilab-5 can be used. [08:42] FF is not far off. that is why I ask [08:50] NEW is also going to kick my ass r.e. FF [08:50] yay for NEW [08:52] hanska, shouldn't you be in class, learning about teeth? [08:52] directhex: no, I'm home to study -- and am studying really :) [08:52] You can fakesync from NEW, right? :) [08:53] human teeth or animal? :P [08:53] RAOF, depends on whether those happy slappy MOTUs will let a little thing like "not going through REVU" happen [08:54] What's in NEW that needs revu? [08:54] * RAOF notes that _he_ is a slap-happy motu, should push come to shove. [08:55] RAOF, the main items stuck in limbo are moon and sublib. [08:55] sublib is needed to finish the mono 2.0 transition [08:56] savvas: human ;) [09:07] hanska: I really hope it's not histology or anatomy and doesn't involve innervations and their pathway/origin (been there :P) Good luck, I won't disturb anymore! :) [09:09] savvas: well, I already gave those two :)... and yes, I know what you're talking about :P. No, I'm doing gastroenterology, internal medicine, haematology, odontostomatologic pathology. [09:09] savvas: exam is on Thu :/ [09:09] * hanska goes to study Scleroderma. [09:11] scleroderma, medical stuff. let's call dr. house (tm) [09:12] DktrKranz: /me is House. :P [09:12] cool, dr. house is a Debian Maintainer! \o/ [09:13] \o/ [09:13] DktrKranz: if you happen to come in Palermo, come to Policlinico and I'll see your teeth :P [09:16] quite far away for a dentist's checkup :) [09:17] DktrKranz: we could sign each other's GPG keys. ;) [09:18] * iulian looks around. [09:36] hanska: ping me if you come near reggio em., mantua, bologna or thelike :) === cassidy` is now known as cassidy [10:18] hanska: I'm studying medicine as well, 3rd year.. and still hating the long hours I have to sacrifice :p [10:19] on the other hand, it really pays back in more ways than one === elmargol is now known as quassel94 [10:29] A question about libmtp merge bug #315679 - debian/control file says "Breaks: udev (<< 136-1)" which makes libmtp work only for 9.04 jaunty or later releases. In libmtp postinst and preinst scripts there are some checks for older libmtp versions, which are for ubuntu hardy or older. Should those libmtp older version checks be removed? [10:29] Launchpad bug 315679 in libmtp "Please merge libmtp 0.3.0-1ubuntu3 (main) to 0.3.6-1 from Debian (experimental)" [Wishlist,Confirmed] https://launchpad.net/bugs/315679 [10:40] savvas: sounds like you could remove them [10:42] savvas: what does the package history say about the reasons for adding these checks? [10:58] mok0: I'll have all the points you noticed with skrooge fixed today, fyi [10:59] Tonio_: super === ziroday` is now known as ziroday [11:23] Can anybody who is free now review my package? (gnome-quod) http://revu.ubuntuwire.com/details.py?package=gnome-quod [11:37] mok0: http://revu.ubuntuwire.com/p/skrooge <- should be okay now [11:38] and if anyone has a couple of minutes for a very quick revu -> http://revu.ubuntuwire.com/p/kcometen4 [11:38] just a screensaver, so that's very basic kde packaging === quassel94 is now known as elmargol [12:04] Tonio_: I'm busy atm, will look later [12:06] mok0: thanks :) [12:16] could someone take a look at http://revu.ubuntuwire.com/p/nfoview ? [12:25] hi all [12:31] hello [12:34] i want to fix a bug in QtParted, for it i am goingo to make a patch, qtparted has seven patches in debian/patches in dpatch format, i dont know if I must make a dpatch patch or a debdiff patch [12:36] make a dpatch first & foremost. then consider making a debdiff of your new package which contains the dpatch [12:37] okay, I need to learn how to apply and make dpatch patched then, any guide? [12:39] EagleScreen: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#dpatch [12:41] if I want to upgrade a package, do I need to prepare a Freeze Exception? [12:41] mruiz: we're not in Feature Freeze yet [12:41] https://wiki.ubuntu.com/JauntyReleaseSchedule [12:41] dholbach, hi ! [12:42] hiya [13:04] I have a package to review : https://bugs.launchpad.net/ubuntu/+source/gtranslator/+bug/292253 . It would be great if someone could give me a comment [13:04] Ubuntu bug 292253 in gtranslator "Gtranslator is too old in Ubuntu, please upgrade it" [Undecided,In progress] [13:56] * surfaz is away: Estoy comiendo, escribir mi nombre para que el Xchat me avise [13:57] !away > surfaz [13:57] surfaz, please see my private message [14:31] I just need one more advocate for my package - would a MOTU be so kind as to review it? Thanks in advance! http://revu.ubuntuwire.com/details.py?package=lmalinux [14:40] hi guys! anyone on this? http://revu.ubuntuwire.com/p/nfoview === ssweeny_ is now known as ssweeny [14:46] I have a dude. I am going to do a change in package qtparted, it uses dpatch patches in debian/patches, so I fisrtly will make a dpatch patch with my changes, and later a debdiff with the difference between old and new package, my question is if the changes in the changelog file must go in the dpatch patch, or only in the debdiff patch === quadrispro1 is now known as quadrispro [14:52] EagleScreen: only in debdiff [14:52] EagleScreen: Ideally nothing under debian/ will go in the dpatch [14:53] thanks === bluesmoke_ is now known as Amaranth [15:06] Heya gang [15:10] Hi MOTUs, thank you for spending your time making Ubuntu better! It would be great if someone could help me with updating netbeans package to a new upstream version - 6.5: https://bugs.launchpad.net/ubuntu/+source/netbeans/+bug/251173 . I've got many requests for this update from Ubuntu users and now all needed diff files (for netbeans and corresponding libs) are ready. Please, have a... [15:10] ...look. Thanks in advance! [15:10] Ubuntu bug 251173 in netbeans-ide "Update NetBeans to 6.5" [Undecided,Confirmed] [15:16] Is there a way to get debuild to fork multiple compile processes, like "make -j 2"? === Juli___ is now known as Juli_ [15:30] postalchris: I believe there is some environmental variable you can set [15:34] postalchris: ah, no it's a switch: dpkg_buildpackage -j2 [15:35] postalchris: or use parallel=jobs in DEB_BUILD_OPTIONS ... my memory is not completely off === Juli___ is now known as Juli_ [15:45] hey guys, I am packaging ldtp1.5 to be included in jaunty, and I have some questions about the process. I hope that you will be able to help. [15:45] the changes include a new upstream version (jaunty now contains ldtp 1.4) and some basic changes in the control file: new dependency and original-maintainer field [15:46] the package builds correctly and it has been successfully tested [15:46] I will file now a bug in LP requestion the upgrade [15:46] my question is: [15:46] what should I add as attachment to the bug? the debdiff with the former version? [15:47] ara: diff.gz [15:47] ara: Debdiff, .diff.gz, and .dsc. [15:47] jpds: eh? the other day someone told me all i needed was a diff.gz [15:47] hyperair: Today someone told me I needed those three. [15:48] bah [15:48] well my debdiff is miles long, including a few unrepresentable changes [15:48] hyperair: debdiff makes viewing upstream changes easier to see if it's worth the update. [15:48] .png stuff [15:48] jpds, hyperair: the .diff.gz between 1.4 and 1.5 upstream? and what about the packaging changes? [15:49] ara: No, the .diff.gz for the 1.5 source package. [15:49] jpds: are sponsors really going to stare at a mile-long debdiff? [15:49] hyperair: Possibly. [15:49] jpds: good grief. [15:49] jpds: ah, ok, thanks :) [15:49] hyperair: thank you too [15:49] ara: np [15:50] hyperair: bug #319182 was where I was asked. [15:50] Launchpad bug 319182 in python-gdata "Package Update Request: python-gdata" [Wishlist,In progress] https://launchpad.net/bugs/319182 [15:50] ara: De nada. [15:51] bug #327216 -- a package update request. i didn't attach a debdiff [15:51] Launchpad bug 327216 in codelite "[needs-upgrade] CodeLite 1.0.2759" [Undecided,Confirmed] https://launchpad.net/bugs/327216 [15:51] I find it hard to believe that anyone is going to review that debdiff [15:51] the NEWS file would be more useful [15:51] Laney: lol yeah [15:51] eventhough launchpad is being a bitch over here so i can't see it [15:51] I didn't want to upload the debdiff really. [15:51] .diff.gz allows us to sponsor the update [15:52] anything else that makes it easy to review is more likely to get your package sponsored sooner [15:52] a mile long debdiff doesn't really fall in to that category, but the NEWS file might [15:55] possibly wanted to diffstat it or something. === frostburn2 is now known as frostburn [15:57] well bug is now there: https://bugs.launchpad.net/ubuntu/+source/ldtp/+bug/327666 [15:57] Ubuntu bug 327666 in ldtp "Please upgrade to LDTP 1.5" [Undecided,New] [15:57] I guess next step would be to subscribe to sporsors, isn't it? [15:58] Yes; ubuntu-main-sponsors. === _neversfelde is now known as neversfelde [16:00] jpds: well, universe, in this case ;-) [16:00] ara: Oh, I thought it was in main... [16:01] That would be ltsp confusing me. [16:41] need a MOTU to look at libmirage. [16:50] Laney: I am handling the bakery update [16:50] (just so that you know= [16:50] ) [16:50] :) [16:50] what update?! [16:50] in debian? [16:53] Laney: a new release has been done today by the upstream [16:53] oh cool [16:53] cannot do it in debian because of the freeze... [16:54] habtool: You can upload to experimental. [16:55] huats: You can upload to experimental. [16:55] only a few days left [16:55] broonie: I know [16:55] but I 'd rather wait... [16:55] Laney: yep [16:56] Laney: be sure I'll put the bakery2.6 in debian too (so that you can put glom) [16:56] :) [16:56] \o/ [16:56] * broonie uploaded some stuff anyway, it'd never have time to migrate and the chances of a RC bug that needed fixing in testing were minimal. [16:58] directhex: man I'm getting itchy enough that I want to fix monodevelop-boo upstream :) [16:58] oh guys, if you could have a look to include boo 0.9 before feature freeze too that would be awesome!! :) [17:00] cedricv: doesn't it require Mono 2.x? [17:00] no 1.9 is ok [17:01] ah ok, well the only other concern I'd have is about all the apps that use Boo scripting [17:01] Banshee I believe is one of em [17:01] whether or not this change breaks anything [17:03] yeah, well 0.9 broke not much (the main potential issue would be the enforcement of the earlier only-recommended syntax for generic definitions..) [17:03] but then of course i'm not even sure banshee plugins use generics in the first place, even less defined them with the 'not-recommended' syntax [17:04] right [17:04] directhex would probably be the mono wrangler to speak with on this matter [17:04] but yes, it would be nice to get 0.9 in safely :) [17:04] indeed! well actually we could even release in time a 0.9.1 with the latest bugfixes [17:05] as a maintenance release [17:07] what is the problem you have witn monodevelop-boo btw? [17:07] cedricv: mainly code completion support / stetic support [17:07] and in the process I understand there's some nastiness in how Boo loads assemblies into the MD process [17:08] hmm so in the end is it crashing? or having incorrect behavior? [17:09] cedricv: incorrect behavior; see monodevelop-list archives today, I seem to have started a dirty laundry list about the Boo binding [17:09] btw I just recently started playing with Boo and I absolutely love it. Keep up the great work [17:11] great! welcome then :) [17:13] jdong: have read the thread on the list, not sure i get the prb though, is it boo that is loading the assemblies? or the md addin itself that is? [17:19] cedricv: oh sorry for the unclear explanation; it's the implementation of the MD addin, not anything wrong with Boo itself : [17:20] jdong: yeah I think Luiss pointed out the issue correctly (addin using BooCompiler API directly instead of forking another process (or AppDomain maybe)) [17:21] cedricv: yeah the compiler part looks simple to solve, though I'm not so sure aout the parser side for codecompletion. [17:21] I don't understand enough about Boo's interactive abilities to know the best approach for this :) [17:22] I understand the interactive interpreter has a suggest code complete API call but that probably needs to load referenced assemblies to know what it's talking about? [17:24] yeah, so it would have to be done out-of-MD-process too (maybe you can have a look at the [something]Messenger.boo that Monolipse [the boo plugin for eclipse] is using) [17:24] k, I'll look at that [17:24] speaking of Monolipse, does it have code completion for Boo right now? I was playing with it and couldn't find that ability [17:27] jdong: yeah it has a *very limited* one.. you have to press alt+/ monolipse is really in pre-pre-alpha stage ;) === asac_ is now known as asac [17:52] cedricv: yeah it was playing mind tricks on me, sometimes alt/ does something, other times it just sits there :) === thekorn_ is now known as tthkorn === tthkorn is now known as thekorn === surfaz is now known as surfaz[24h] === surfaz[24h] is now known as surfaz[24 === surfaz[24 is now known as surfaz [18:41] * hyperair has just noticed the shiny new revu graph [18:42] pretty cool [18:42] Laney: "Stage"? [18:42] place [18:42] install them into debian/package/ [18:43] Oh right I'll give it a shot [18:43] Laney: So apply a quilt patch I'm guessing? [18:45] Anybody able to review pyproj for me? I've made revisions suggested by fabrice_sp_, and hoping for more feedback. http://revu.ubuntuwire.com/p/pyproj [18:58] Hi chrismurf, did you succeed in getting the correct diff file? [18:59] about the point 2, the warning is because you have to change the content of the compat file to match the required debhelper version [19:01] I have seen your comments. Trying to build the package (and crossing the finger :-) ) [19:01] fabrice_sp_, I believe I did [19:01] Thanks :-) [19:01] s/finger/fingers/ [19:02] fabrice_sp_, so I guess the question is whether or not I should need a specific compat level [19:04] you should lower it, anyway [19:04] okay - to what? 6? 5? [19:05] chrismurf, to 6, at least (last package I did, I put 5, because of dh_icons) [19:05] the lowest you can, the better [19:05] okay -- I'm doing nothing special, so I shouldn't need particularly advanced versions [19:05] looks like python-support requires debhelper >=5 [19:05] so I'll switch to that [19:07] great [19:10] so -- education question; is this because I'm making a source DEB which ideally will be usable with as old a version of debian as possible -- ie, this has little to do with targetting Jaunty specifically [19:11] It's just good practice to not require things that aren't required [19:12] both :-) It's good to package something that can be more 'easily' backported and also, it's good practice to use the minimum [19:13] required [19:13] noted [19:18] fabrice_sp_, dputting version with new compat / debhelper version. [19:19] and... fantastic - .diff.gz is getting creamed by dput again [19:19] what is with that? [19:19] has anybody else ever had their .gz get corrupted to binary junk during upload? [19:22] Chris`: You have mail. [19:27] jpds, my .diff.gz is fairly consistently being corrupted upon upload. If I look at a diff of the binary streams, it's actually only in a few places. I have the actual copyright sign in the file -- is it possible that either dput or revu is not handling utf-8 characters well? [19:28] does REVU unpack/repack the .gz at all, or would any bug have to be in dput? [19:31] chrismurf, the same old problem with matching size... [19:31] fabrice_sp_, fixed now [19:31] I think I figured out what it is [19:32] I switched the UTF-8 copyright signs in 'copyright' to be (C) [19:32] problem now gone [19:32] so... maybe dput or REVU has unicode issues? ASCII only? [19:32] the one up there now should be good [19:35] G'evening mrooney [19:35] jpds: allo! [19:35] it is morning for me :) [19:36] mrooney: You're in SF now, right? [19:38] fabrice_sp_, better? [19:39] jpds: Thanks for the mail btw, how do I patch without using cdbs (There is no configure) ? [19:40] Chris`: Use quilt, see: pidgin-facebookchat for example. [19:40] jpds: Heh you always refer to facebookchat, thanks again [19:41] jpds: I am indeed! [19:41] mrooney: Nice. [19:41] * fabrice_sp_ try again to build pyproj [19:42] Chris`: Because it has an example rules file with patching, no configure and example patches in debian/patches :) [19:43] can anyone tell me why spim mysteriously disappeared after Hardy? [19:44] hi guys, could someone review this? http://revu.ubuntuwire.com/p/nfoview [19:44] maco: It was removed from Debian [19:44] Laney: any idea why *that* happened? [19:44] The maintainer orphaned it [19:44] and can we get it back? [19:44] and nobody wanted to maintain [19:44] :( [19:45] sure, if you want to maintain it [19:45] maco: https://edge.launchpad.net/ubuntu/+source/spim [19:45] jpds: oh i installed from hardy's binary [19:45] maco, http://wiki.debian.org/NonFreeTrackingSystem/SourcePackage/spim [19:45] but it used to be that if your school made you learn mips it was a nice apt-get away...now it's a hunt [19:46] maco, sounds like gxemul may do what you want [19:46] oooh ok [19:46] is gxemul by any chance Free (with a big F) too? [19:47] maco, yes, see http://www.linux-mips.org/wiki/Emulators === Juli___ is now known as Juli_ [19:50] ok so i guess i ought to figure out how to use this thing, then tell the TA [19:50] thanks [19:51] Do someone else have a problem with building a package with 404 error on autoconf ? (Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/a/autoconf/autoconf_2.63-2ubuntu1_all.deb 404 Not Found [IP: 91.189.88.31 80]) [19:52] fabrice_sp_: Try to update your pbuilder. [19:52] jpds: "debian/rules:12: /usr/share/quilt/quilt.make: No such file or directory" yet quilt is in the build-deps :-/ [19:53] actually it doesnt look like gxemul does what spim does at all... [19:53] gxemul seems to be more like a vm [19:53] spim is for running or stepping through assembly files [19:53] gxemul's docs say you need to cross-compile code to run it, and you're supposed to install a guest OS [19:54] iulian, it's with sbuild, and I autoupdate before building. I've checked, and in packages.ubutnu.com, I have 2.63-2ubuntu1, but in archive.ubuntu.com, it's not greater than 2.61-7 [19:54] Chris`: Weird. [19:54] jpds: I've debuilded several times just to make sure, shall I upload to see if you can spot anything? [19:55] Chris`, if you get this error when building the source package, it's because you miss quilt in your computer [19:55] fabrice_sp_: It is installed both locally and via pbuilder [19:55] Using control for pbuilder ofc ^ [19:55] Chris`: Sure. [19:56] fabrice_sp_: That's odd. I've also got some 404s when building packages with pbuilder. After updating, it worked. [19:56] iulian, yeah. The same for me. In this case, it seems that archive is not in sync [19:57] or some chacing with my internet provider [19:57] caching [19:58] http://revu.ubuntuwire.com/details.py?upid=4981 -- Uploaded jpds [19:59] Oh snap [19:59] I see what I did wrong! [19:59] I put in depends not build-depends [19:59] Chris`: http://tinyurl.com/ao8q5b [20:00] jpds: What am I looking for in that link? [20:00] Chris`: It's $(DESTDIR). Not: {DESTDIR}. [20:00] Oh OK [20:01] Chris`: And you've modified the source: +++ star-merchant-1.1/Makefile [20:01] I haven't touched that dir :-/ [20:02] Is that an effect of quilt? [20:02] chrismurf, still having the same pb with sizes [20:02] seriously?! [20:03] jpds: Locally .orig.tar.gz is the same as upstream [20:03] yeah. I'm closing my browser, just to avoid caching problems [20:03] fabrice_sp_, with which file [20:03] chrismurf, diff file [20:03] if I wget the latest .diff.gz, it's the correct size [20:04] whoah... but if I download it through firefox it's wrong [20:04] Chris`: Oh, yeah, you have to add to rules: "clean: unpatch" and "build-stamp: patch". [20:05] * Chris` will look into it :) [20:05] Chris`: You might want to remove th configure: and configure-stamp: rules cos they're not doing anything. [20:05] chrismurf, i'm downloading through firefox :-/ [20:05] fabrice_sp_, yeah - clicking on the link in the browser ensures that it's the wrong size. wget gets the right size. [20:05] ok [20:05] this is bad magic [20:05]