[00:00] <kolby> directhex: Can I borrow it?
[00:00] <directhex> jms@orac:~> grep -c ^processor /proc/cpuinfo
[00:00] <directhex> 256
[00:00] <maxb> !
[00:00] <kolby> I like
[00:00] <Laney> But I don't know why you'd deliberately introduce a known broken hashing algorithm
[00:00] <Laney> 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] <directhex> jms@orac:~> free -g | grep Mem
[00:01] <directhex> Mem:           985         30        955          0          0         19
[00:01] <kolby> 4<256... except today. It's opposite day
[00:02] <kolby> Laney: what would possibly be the benefit of adding a GUI to a hashing algorithm program?
[00:02] <Laney> to make it an educational tool
[00:02] <Laney> which is the use you want it for
[00:03] <kolby> example use:  gdb md4sum *.avi hashy
[00:03] <directhex> thing is, the day md4sum hits the archive, the security team launches a tactical nuke at your house
[00:03] <kolby> education is therefor born.
[00:03] <Laney> this is most unconvincing
[00:04] <kolby> It's a great package!
[00:05] <kolby> md4sum is faster.
[00:05] <kolby> most people don't know how to break it.
[00:05] <kolby> most people have _no_idea_ what it is.
[00:05] <Laney> who cares about most people?
[00:05] <kolby> so it's fine to include in the repos
[00:06] <Laney> most people don't want to break your software
[00:06] <kolby> Yes, further justifying our point.
[00:06] <Laney> but the fact is you cannot trust md4 because it is *so easily broken by anyone who takes two seconds to find out how*
[00:07] <kolby> directhex has a super-computer.  He doesn't count.
[00:07] <directhex> 7 seconds was on my laptop.
[00:07] <directhex> i don't feel like vexing the itaniums this evening.
[00:08] <kolby> directhex: laptop with 256 processors...
[00:08] <kolby> directhex: try breaking md4sum's daughter: md5sum with your mighty processing power.
[00:09] <directhex> no, laptop with a core 2 duo. office machine with 256 cores.
[00:09] <kolby> If PS3s can do it, your set up should work.
[00:09] <directhex> and i think you underestimate the cost of electricity
[00:09] <kolby> directhex: I don't have to pay it actually.
[00:09] <kolby> directhex: I'm living on a military base.
[00:09] <kolby> directhex: good luck with your bomb
[00:10] <Laney> ask them about using md4
[00:10] <Laney> they should know a thing or two
[00:10] <kolby> why bother the IT dep. over something so abviously simple?
[00:10] <kolby> md4sum is a great experience.
[00:11] <kolby> like swimming.
[00:11] <kolby> how are you not convinced?
[00:11] <Laney> We are not about to deliberately introduce a program with security flaws
[00:11]  * Laney -> shower
[00:11] <kolby> lol.
[00:12] <kolby> fine...  md4sum breaker-ers
[00:12] <kolby> I'll go bother debian.
[00:12] <Laney> haha
[00:13] <Laney> good luck!
[00:13] <kolby> it's not like I packaged a virus.
[00:13] <kolby> just a great historical application.
[00:13] <kolby> who will know of md4sum and it's wonderful eDonkey powers now?
[00:14] <kolby> ...debian...
[00:14] <kolby> lol
[00:14] <kolby> alright that was my last try.  Thanks for participating.  Sincerely.
[00:15] <kolby> I was packaging this program to learn how to make Ubuntu packages.
[00:16] <kolby> I realized it could be part of Jaunty and it made feel a great sense of pride in my labor.
[00:17] <kolby> I'm pretty sure the packaging is flawless by now, though.
[00:17] <ScottK> kolby: You do realize the arguments against it have nothing to do with the quality of your packaging, right?
[00:18] <kolby> ScottK, *sigh* yes.  I just want someone to review it.
[00:18] <ScottK> 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] <kolby> ScottK thanks. ^^
[00:19] <kolby> ScottK, where will it go?  Bad-package heaven?
[00:20] <kolby> it will more than likely stay on my hard-drive.
[00:20] <kolby> I should probably uninstall it.
[00:21] <kolby> weak-hashing-algorithm-haters...
[00:21] <kolby> thank you all.
[00:22] <directhex> all the cool kids use quadruple rot13 these days
[00:23] <kolby> directhex: thanks for your feedback, btw
[00:48] <ScottK> kolby: Reviewed.  Generally technically good, but licensing is a disaster.
[00:48]  * ScottK needs to run.
[00:48] <kolby> thank you
[03:25] <Dante_J> Greetings room.
[03:28] <nhandler> Hello Dante_J
[03:29] <Dante_J> 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] <Dante_J> 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] <Dante_J> https://lists.ubuntu.com/archives/ubuntu-security-announce/2009-January/date.html
[03:29] <Dante_J> https://www.redhat.com/archives/fedora-package-announce/2009-February/date.html
[03:30] <Dante_J> I'm just curious and a little concerned, not attempting to apportion blame.
[03:33] <Dante_J> 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] <Dante_J> I really hate being the whiner, seriously. I'd just like to get a handle on the current status.
[03:42] <Dante_J> nhandler: Thank you for your greeting.
[03:42] <Dante_J> I guess I should leave you all in peace. Cheers. :/
[03:43]  * RAOF has obviously missed the start of this.
[03:43] <nhandler> Dante_J: I would suggest coming back here at a different time. Most developers are gone right now
[03:43] <Dante_J> thanks nhandler
[03:43] <nhandler> 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] <Dante_J> that was my question
[03:46]  * RAOF doesn't know _anything_ about the update.
[03:46] <RAOF> 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] <Dante_J> Also under Ubuntu is Firefox is unpatched at 3.0.5
[03:47] <Dante_J> among other packages.
[03:47] <RAOF> It's _actually_ unpatched, or just doesn't have a version bump?
[03:47] <Dante_J> Not patched.
[03:47] <nhandler> Dante_J: firefox 3.0.6 is actually in jaunty
[03:47] <Dante_J> Insecure.
[03:47] <Dante_J> http://secunia.com/advisories/33799/
[03:48] <Dante_J> not patched in Hardy
[03:48] <Dante_J> which is often used in labs, & by corporates.
[03:48] <nhandler> Dante_J: I would talk to some of the people on the security team. They would have more knowledge about this stuff
[03:49] <Dante_J> thank you nhandler
[03:49] <RAOF> Both firefox & sudo are in main; #ubuntu-devel is where you'll have people who deal with main.
[03:49] <Dante_J> thanks RAOF :)
[03:50] <afner> hi
[03:50] <Dante_J> Hello afner
[03:50] <nhandler> Hi afner
[03:50] <Dante_J> Have a great day.
[03:50]  * Dante_J waves
[03:50] <afner> how are you?
[03:51] <afner> you too have a grat day
[03:51] <afner> great
[03:51] <afner> nhandler hi
[03:53] <jmarsden> Anyone able to review webgui for me please?  http://revu.ubuntuwire.com/p/webgui
[03:54] <nhandler> jmarsden: I'll take a look
[03:54] <jmarsden> Thanks!
[04:03] <chrismurf> 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] <dholbach> good morning
[05:31] <ScottK> Good morning.
[05:32] <dholbach> hi scottK
[05:50] <fabrice_sp> Good morning dholbach. Morning ScottK
[05:50] <dholbach> hiya fabrice_sp
[05:53] <ScottK> o/
[06:21]  * nixternal hugs dholbach 
[06:22]  * dholbach hugs nixternal back :)
[07:08] <didrocks> good morning :)
[08:38] <c_korn> hello. is it likely that scilab-5 makes it into jaunty? https://bugs.launchpad.net/debian/+source/scilab/+bug/272264
[08:38] <c_korn> there are a few missing dependencies which have to be synced before (jeuclid for example which is not in debian, yet)
[08:40] <directhex> c_korn, NEW joy? that one rings a bell
[08:40] <directhex> yeah. 7th in NEW
[08:42] <c_korn> jeuclid, xmlgraphics-common, fop and java-wrappers would need to be synced before scilab-5 can be used.
[08:42] <c_korn> FF is not far off. that is why I ask
[08:50] <directhex> NEW is also going to kick my ass r.e. FF
[08:50] <directhex> yay for NEW
[08:52] <directhex> hanska, shouldn't you be in class, learning about teeth?
[08:52] <hanska> directhex: no, I'm home to study -- and am studying really :)
[08:52] <RAOF> You can fakesync from NEW, right? :)
[08:53] <savvas> human teeth or animal? :P
[08:53] <directhex> RAOF, depends on whether those happy slappy MOTUs will let a little thing like "not going through REVU" happen
[08:54] <RAOF> 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] <directhex> RAOF, the main items stuck in limbo are moon and sublib.
[08:55] <directhex> sublib is needed to finish the mono 2.0 transition
[08:56] <hanska> savvas: human ;)
[09:07] <savvas> 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] <hanska> 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] <hanska> savvas: exam is on Thu :/
[09:09]  * hanska goes to study Scleroderma.
[09:11] <DktrKranz> scleroderma, medical stuff. let's call dr. house (tm)
[09:12] <hanska> DktrKranz: /me is House. :P
[09:12] <DktrKranz> cool, dr. house is a Debian Maintainer! \o/
[09:13] <hanska> \o/
[09:13] <hanska> DktrKranz: if you happen to come in Palermo, come to Policlinico and I'll see your teeth :P
[09:16] <DktrKranz> quite far away for a dentist's checkup :)
[09:17] <hanska> DktrKranz: we could sign each other's GPG keys. ;)
[09:18]  * iulian looks around.
[09:36] <DktrKranz> hanska: ping me if you come near reggio em., mantua, bologna or thelike :)
[10:18] <savvas> hanska: I'm studying medicine as well, 3rd year.. and still hating the long hours I have to sacrifice :p
[10:19] <savvas> on the other hand, it really pays back in more ways than one
[10:29] <savvas> 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:40] <mok0> savvas: sounds like you could remove them
[10:42] <mok0> savvas: what does the package history say about the reasons for adding these checks?
[10:58] <Tonio_> mok0: I'll have all the points you noticed with skrooge fixed today, fyi
[10:59] <mok0> Tonio_: super
[11:23] <Vest84> Can anybody who is free now review my package? (gnome-quod) http://revu.ubuntuwire.com/details.py?package=gnome-quod
[11:37] <Tonio_> mok0: http://revu.ubuntuwire.com/p/skrooge <- should be okay now
[11:38] <Tonio_> and if anyone has a couple of minutes for a very quick revu -> http://revu.ubuntuwire.com/p/kcometen4
[11:38] <Tonio_> just a screensaver, so that's very basic kde packaging
[12:04] <mok0> Tonio_: I'm busy atm, will look later
[12:06] <Tonio_> mok0: thanks :)
[12:16] <quadrispro> could someone take a look at http://revu.ubuntuwire.com/p/nfoview ?
[12:25] <mruiz> hi all
[12:31] <EagleScreen> hello
[12:34] <EagleScreen> 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] <directhex> make a dpatch first & foremost. then consider making a debdiff of your new package which contains the dpatch
[12:37] <EagleScreen> okay, I need to learn how to apply and make dpatch patched then, any guide?
[12:39] <dholbach> EagleScreen: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#dpatch
[12:41] <mruiz> if I want to upgrade a package, do I need to prepare a Freeze Exception?
[12:41] <dholbach> mruiz: we're not in Feature Freeze yet
[12:41] <dholbach> https://wiki.ubuntu.com/JauntyReleaseSchedule
[12:41] <mruiz> dholbach, hi !
[12:42] <dholbach> hiya
[13:04] <mruiz> 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:56]  * surfaz is away: Estoy comiendo, escribir mi nombre para que el Xchat me avise
[13:57] <Pici> !away > surfaz
[14:31] <sven777> 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] <quadrispro> hi guys! anyone on this? http://revu.ubuntuwire.com/p/nfoview
[14:46] <EagleScreen> 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
[14:52] <mterry> EagleScreen: only in debdiff
[14:52] <mterry> EagleScreen: Ideally nothing under debian/ will go in the dpatch
[14:53] <EagleScreen> thanks
[15:06] <bddebian> Heya gang
[15:10] <Juli__> 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] <Juli__> ...look. Thanks in advance!
[15:16] <postalchris> Is there a way to get debuild to fork multiple compile processes, like "make -j 2"?
[15:30] <mok0> postalchris: I believe there is some environmental variable you can set
[15:34] <mok0> postalchris: ah, no it's a switch: dpkg_buildpackage -j2
[15:35] <mok0> postalchris: or use parallel=jobs in DEB_BUILD_OPTIONS ... my memory is not completely off
[15:45] <ara> 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] <ara> 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] <ara> the package builds correctly and it has been successfully tested
[15:46] <ara> I will file now a bug in LP requestion the upgrade
[15:46] <ara> my question is:
[15:46] <ara> what should I add as attachment to the bug? the debdiff with the former version?
[15:47] <hyperair> ara: diff.gz
[15:47] <jpds> ara: Debdiff, .diff.gz, and .dsc.
[15:47] <hyperair> jpds: eh? the other day someone told me all i needed was a diff.gz
[15:47] <jpds> hyperair: Today someone told me I needed those three.
[15:48] <hyperair> bah
[15:48] <hyperair> well my debdiff is miles long, including a few unrepresentable changes
[15:48] <jpds> hyperair: debdiff makes viewing upstream changes easier to see if it's worth the update.
[15:48] <hyperair> .png stuff
[15:48] <ara> jpds, hyperair: the .diff.gz between 1.4 and 1.5 upstream? and what about the packaging changes?
[15:49] <jpds> ara: No, the .diff.gz for the 1.5 source package.
[15:49] <hyperair> jpds: are sponsors really going to stare at a mile-long debdiff?
[15:49] <jpds> hyperair: Possibly.
[15:49] <hyperair> jpds: good grief.
[15:49] <ara> jpds: ah, ok, thanks :)
[15:49] <ara> hyperair: thank you too
[15:49] <hyperair> ara: np
[15:50] <jpds> hyperair: bug #319182 was where I was asked.
[15:50] <jpds> ara: De nada.
[15:51] <hyperair> bug #327216 -- a package update request. i didn't attach a debdiff
[15:51] <Laney> I find it hard to believe that anyone is going to review that debdiff
[15:51] <Laney> the NEWS file would be more useful
[15:51] <hyperair> Laney: lol yeah
[15:51] <hyperair> eventhough launchpad is being a bitch over here so i can't see it
[15:51] <jpds> I didn't want to upload the debdiff really.
[15:51] <james_w> .diff.gz allows us to sponsor the update
[15:52] <james_w> anything else that makes it easy to review is more likely to get your package sponsored sooner
[15:52] <james_w> a mile long debdiff doesn't really fall in to that category, but the NEWS file might
[15:55] <jpds> possibly wanted to diffstat it or something.
[15:57] <ara> well bug is now there: https://bugs.launchpad.net/ubuntu/+source/ldtp/+bug/327666
[15:57] <ara> I guess next step would be to subscribe to sporsors, isn't it?
[15:58] <jpds> Yes; ubuntu-main-sponsors.
[16:00] <ara> jpds: well, universe, in this case ;-)
[16:00] <jpds> ara: Oh, I thought it was in main...
[16:01] <jpds> That would be ltsp confusing me.
[16:41] <henrik-hw0> need a MOTU to look at libmirage.
[16:50] <huats> Laney: I am handling the bakery update
[16:50] <huats> (just so that you know=
[16:50] <huats> )
[16:50] <huats> :)
[16:50] <Laney> what update?!
[16:50] <Laney> in debian?
[16:53] <huats> Laney: a new release has been done today by the upstream
[16:53] <Laney> oh cool
[16:53] <huats> cannot do it in debian because of the freeze...
[16:54] <broonie> habtool: You can upload to experimental.
[16:55] <broonie> huats: You can upload to experimental.
[16:55] <Laney> only a few days left
[16:55] <huats> broonie: I know
[16:55] <huats> but I 'd rather wait...
[16:55] <huats> Laney: yep
[16:56] <huats> Laney: be sure I'll put the bakery2.6 in debian too (so that you can put glom)
[16:56] <huats> :)
[16:56] <Laney> \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] <jdong> directhex: man I'm getting itchy enough that I want to fix monodevelop-boo upstream :)
[16:58] <cedricv> oh guys, if you could have a look to include boo 0.9 before feature freeze too that would be awesome!! :)
[17:00] <jdong> cedricv: doesn't it require Mono 2.x?
[17:00] <cedricv> no 1.9 is ok
[17:01] <jdong> ah ok, well the only other concern I'd have is about all the apps that use Boo scripting
[17:01] <jdong> Banshee I believe is one of em
[17:01] <jdong> whether or not this change breaks anything
[17:03] <cedricv> 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] <cedricv> 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] <jdong> right
[17:04] <jdong> directhex would probably be the mono wrangler to speak with on this matter
[17:04] <jdong> but yes, it would be nice to get 0.9 in safely :)
[17:04] <cedricv> indeed! well actually we could even release in time a 0.9.1 with the latest bugfixes
[17:05] <cedricv> as a maintenance release
[17:07] <cedricv> what is the problem you have witn monodevelop-boo btw?
[17:07] <jdong> cedricv: mainly code completion support / stetic support
[17:07] <jdong> and in the process I understand there's some nastiness in how Boo loads assemblies into the MD process
[17:08] <cedricv> hmm so in the end is it crashing? or having incorrect behavior?
[17:09] <jdong> cedricv: incorrect behavior; see monodevelop-list archives today, I seem to have started a dirty laundry list about the Boo binding
[17:09] <jdong> btw I just recently started playing with Boo and I absolutely love it. Keep up the great work
[17:11] <cedricv> great! welcome then :)
[17:13] <cedricv> 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] <jdong> cedricv: oh sorry for the unclear explanation; it's the implementation of the MD addin, not anything wrong with Boo itself :
[17:20] <cedricv> 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] <jdong> cedricv: yeah the compiler part looks simple to solve, though I'm not so sure aout the parser side for codecompletion.
[17:21] <jdong> I don't understand enough about Boo's interactive abilities to know the best approach for this :)
[17:22] <jdong> 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] <cedricv> 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] <jdong> k, I'll look at that
[17:24] <jdong> 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] <cedricv> jdong: yeah it has a *very limited* one.. you have to press alt+/            monolipse is really in pre-pre-alpha stage ;)
[17:52] <jdong> cedricv: yeah it was playing mind tricks on me, sometimes alt/ does something, other times it just sits there :)
[18:41]  * hyperair has just noticed the shiny new revu graph
[18:42] <hyperair> pretty cool
[18:42] <Chris`> Laney: "Stage"?
[18:42] <Laney> place
[18:42] <Laney> install them into debian/package/
[18:43] <Chris`> Oh right I'll give it a shot
[18:43] <Chris`> Laney: So apply a quilt patch I'm guessing?
[18:45] <chrismurf> 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] <fabrice_sp_> Hi chrismurf, did you succeed in getting the correct diff file?
[18:59] <fabrice_sp_> 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] <fabrice_sp_> I have seen your comments. Trying to build the package (and crossing the finger :-) )
[19:01] <chrismurf> fabrice_sp_, I believe I did
[19:01] <chrismurf> Thanks :-)
[19:01] <fabrice_sp_> s/finger/fingers/
[19:02] <chrismurf> fabrice_sp_, so I guess the question is whether or not I should need a specific compat level
[19:04] <fabrice_sp_> you should lower it, anyway
[19:04] <chrismurf> okay - to what? 6? 5?
[19:05] <fabrice_sp_> chrismurf, to 6, at least (last package I did, I put 5, because of dh_icons)
[19:05] <fabrice_sp_> the lowest you can, the better
[19:05] <chrismurf> okay -- I'm doing nothing special, so I shouldn't need particularly advanced versions
[19:05] <chrismurf> looks like python-support requires debhelper >=5
[19:05] <chrismurf> so I'll switch to that
[19:07] <fabrice_sp_> great
[19:10] <chrismurf> 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] <chrismurf> It's just good practice to not require things that aren't required
[19:12] <fabrice_sp_> 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] <fabrice_sp_> required
[19:13] <chrismurf> noted
[19:18] <chrismurf> fabrice_sp_, dputting version with new compat / debhelper version.
[19:19] <chrismurf> and... fantastic - .diff.gz is getting creamed by dput again
[19:19] <chrismurf> what is with that?
[19:19] <chrismurf> has anybody else ever had their .gz get corrupted to binary junk during upload?
[19:22] <jpds> Chris`: You have mail.
[19:27] <chrismurf> 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] <chrismurf> does REVU unpack/repack the .gz at all, or would any bug have to be in dput?
[19:31] <fabrice_sp_> chrismurf, the same old problem with matching size...
[19:31] <chrismurf> fabrice_sp_, fixed now
[19:31] <chrismurf> I think I figured out what it is
[19:32] <chrismurf> I switched the UTF-8 copyright signs in 'copyright' to be (C)
[19:32] <chrismurf> problem now gone
[19:32] <chrismurf> so... maybe dput or REVU has unicode issues? ASCII only?
[19:32] <chrismurf> the one up there  now should be good
[19:35] <jpds> G'evening mrooney
[19:35] <mrooney> jpds: allo!
[19:35] <mrooney> it is morning for me :)
[19:36] <jpds> mrooney: You're in SF now, right?
[19:38] <chrismurf> fabrice_sp_, better?
[19:39] <Chris`> jpds: Thanks for the mail btw, how do I patch without using cdbs (There is no  configure) ?
[19:40] <jpds> Chris`: Use quilt, see: pidgin-facebookchat for example.
[19:40] <Chris`> jpds: Heh you always refer to facebookchat, thanks again
[19:41] <mrooney> jpds: I am indeed!
[19:41] <jpds> mrooney: Nice.
[19:41]  * fabrice_sp_ try again to build pyproj
[19:42] <jpds> Chris`: Because it has an example rules file with patching, no configure and example patches in debian/patches :)
[19:43] <maco> can anyone tell me why spim mysteriously disappeared after Hardy?
[19:44] <quadrispro> hi guys, could someone review this? http://revu.ubuntuwire.com/p/nfoview
[19:44] <Laney> maco: It was removed from Debian
[19:44] <maco> Laney: any idea why *that* happened?
[19:44] <Laney> The maintainer orphaned it
[19:44] <maco> and can we get it back?
[19:44] <Laney> and nobody wanted to maintain
[19:44] <maco> :(
[19:45] <Laney> sure, if you want to maintain it
[19:45] <jpds> maco: https://edge.launchpad.net/ubuntu/+source/spim
[19:45] <maco> jpds: oh i installed from hardy's binary
[19:45] <chrismurf> maco, http://wiki.debian.org/NonFreeTrackingSystem/SourcePackage/spim
[19:45] <maco> 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] <chrismurf> maco, sounds like gxemul may do what you want
[19:46] <maco> oooh ok
[19:46] <maco> is gxemul by any chance Free (with a big F) too?
[19:47] <chrismurf> maco, yes, see http://www.linux-mips.org/wiki/Emulators
[19:50] <maco> ok so i guess i ought to figure out how to use this thing, then tell the TA
[19:50] <maco> thanks
[19:51] <fabrice_sp_> 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] <iulian> fabrice_sp_: Try to update your pbuilder.
[19:52] <Chris`> jpds: "debian/rules:12: /usr/share/quilt/quilt.make: No such file or directory" yet quilt is in the build-deps :-/
[19:53] <maco> actually it doesnt look like gxemul does what spim does at all...
[19:53] <maco> gxemul seems to be more like a vm
[19:53] <maco> spim is for running or stepping through assembly files
[19:53] <maco> gxemul's docs say you need to cross-compile code to run it, and you're supposed to install a guest OS
[19:54] <fabrice_sp_> 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] <jpds> Chris`: Weird.
[19:54] <Chris`> jpds: I've debuilded several times just to make sure, shall I upload to see if you can spot anything?
[19:55] <fabrice_sp_> Chris`, if you get this error when building the source package, it's because you miss quilt in your computer
[19:55] <Chris`> fabrice_sp_: It is installed both locally and via pbuilder
[19:55] <Chris`> Using control for pbuilder ofc ^
[19:55] <jpds> Chris`: Sure.
[19:56] <iulian> fabrice_sp_: That's odd.  I've also got some 404s when building packages with pbuilder.  After updating, it worked.
[19:56] <fabrice_sp_> iulian, yeah. The same for me. In this case, it seems that archive is not in sync
[19:57] <fabrice_sp_> or some chacing with my internet provider
[19:57] <fabrice_sp_> caching
[19:58] <Chris`> http://revu.ubuntuwire.com/details.py?upid=4981 -- Uploaded jpds
[19:59] <Chris`> Oh snap
[19:59] <Chris`> I see what I did wrong!
[19:59] <Chris`> I put in depends not build-depends
[19:59] <jpds> Chris`: http://tinyurl.com/ao8q5b
[20:00] <Chris`> jpds: What am I looking for in that link?
[20:00] <jpds> Chris`: It's $(DESTDIR). Not: {DESTDIR}.
[20:00] <Chris`> Oh OK
[20:01] <jpds> Chris`: And you've modified the source: +++ star-merchant-1.1/Makefile
[20:01] <Chris`> I haven't touched that dir :-/
[20:02] <Chris`> Is that an effect of quilt?
[20:02] <fabrice_sp_> chrismurf, still having the same pb with sizes
[20:02] <chrismurf> seriously?!
[20:03] <Chris`> jpds: Locally .orig.tar.gz is the same as upstream
[20:03] <fabrice_sp_> yeah. I'm closing my browser, just to avoid caching problems
[20:03] <chrismurf> fabrice_sp_, with which file
[20:03] <fabrice_sp_> chrismurf, diff file
[20:03] <chrismurf> if I wget the latest .diff.gz, it's the correct size
[20:04] <chrismurf> whoah... but if I download it through firefox it's wrong
[20:04] <jpds> Chris`: Oh, yeah, you have to add to rules: "clean: unpatch" and "build-stamp: patch".
[20:05]  * Chris` will look into it :)
[20:05] <jpds> Chris`: You might want to remove th configure: and configure-stamp: rules cos they're not doing anything.
[20:05] <fabrice_sp_> chrismurf, i'm downloading through firefox :-/
[20:05] <chrismurf> fabrice_sp_, yeah - clicking on the link in the browser ensures that it's the wrong size.  wget gets the right size.
[20:05] <fabrice_sp_> ok
[20:05] <chrismurf> this is bad magic
[20:05] <fabrice_sp_> strange, isn't it?
[20:06] <chrismurf> REVU admin, help?
[20:06] <jpds> Again? :)
[20:06] <fabrice_sp_> yeah. I think RainCT was updating REVU some time ago
[20:06] <chrismurf> jpds, yeah, I'm hopeless
[20:06] <chrismurf> jpds,  the .diff.gz file from http://revu.ubuntuwire.com/p/pyproj downloads incorrectly through firefox for both fabrice_sp_ and I, but correctly with wget
[20:07] <chrismurf> any ideas?  headers / content-type badness?
[20:07] <chrismurf> it gets corrupted during transfer
[20:07] <jpds> Hmm, odd.
[20:08] <chrismurf> fabrice_sp_, it does work with wget for you, correct?
[20:09] <fabrice_sp_> I'm trying with another package :-)
[20:10] <fabrice_sp_> but yes: sze is correct with wget
[20:10] <fabrice_sp_> size
[20:10] <fabrice_sp_> and I'm having also that problem with another package (Chris`'s one)
[20:11] <chrismurf> works through links too.  So... yeah.  ;-)
[20:11] <chrismurf> fabrice_sp_, firefox 3?
[20:11] <chrismurf> 3.0.5
[20:11] <jpds> Hmm, maybe it's something with mod_deflate.
[20:11] <fabrice_sp_> 3.0.5, yes
[20:11]  * Chris` is trying to fight the errors like a good detective
[20:11] <chrismurf> jpds, that seems not unreasonable
[20:11] <fabrice_sp_> jpds, is it something RainCT changed few tiem ago?
[20:12] <jpds> fabrice_sp_: Yes.
[20:12] <RainCT> chrismurf,fabrice_sp_: What's up?
[20:12] <Chris`> make[1]: Entering directory `/tmp/buildd/star-merchant-1.1'
[20:12] <Chris`> cp starmerch /tmp/buildd/star-merchant-1.1/debian/star-merchant/usr/bin/starmerch
[20:12] <Chris`> cp: cannot create regular file `/tmp/buildd/star-merchant-1.1/debian/star-merchant/usr/bin/starmerch': No such file or directory
[20:12] <Chris`> jpds: Same error diff dir
[20:12] <fabrice_sp> Hey RainCT!
[20:12] <chrismurf> RainCT, wget on http://revu.ubuntuwire.com/revu1-incoming/pyproj-0902102030/pyproj_1.8.5-0ubuntu1.diff.gz is the correct size, downloading through firefox is not.
[20:13] <chrismurf> Hi :-)
[20:13] <jpds> chrismurf: Hmm, freaky.
[20:13] <Chris`> I've been having lots of Firefox errors lately when downloading
[20:13] <Chris`> Sometimes the download does not even start
[20:13] <Chris`> and refuses to
[20:13] <chrismurf> Been kicking myself for incompetence with creating .diff.gz
[20:14] <chrismurf> I feel slightly better now :-)
[20:14] <fabrice_sp> lol
[20:14] <RainCT> Weird.. Now that I think about it, it can't be mod_deflate as it doesn't touch .gz files
[20:14] <chrismurf> RainCT, we're both running FF 3.0.5
[20:14] <fabrice_sp> it only affect diff file
[20:14] <chrismurf> but I can't imagine what the bug would be
[20:15] <RainCT> yeah, I can reproduce it
[20:15] <chrismurf> wget or links works fine
[20:15] <chrismurf> kk
[20:15] <fabrice_sp> and was working fine one week ago, I think
[20:15] <RainCT> must be some Firefox weirdness..
[20:15] <RainCT> uhm
[20:16] <RainCT> (to be sure, I've just tried disabling deflate - still doesn't work)
[20:16] <chrismurf> kk
[20:17] <fabrice_sp> is there a way to compare to binary files?
[20:18] <chrismurf> fabrice_sp, I did using diff
[20:18] <chrismurf> it's only a couple of places it gets mangled
[20:18] <chrismurf> RainCT, I thin it's on the server
[20:18] <chrismurf> because I'm getting sent a Content-Encoding of gzip
[20:18] <chrismurf> looking at the header
[20:19] <RainCT> chrismurf: .diff.gz is a gzip encoded file
[20:19] <RainCT> :P
[20:20] <chrismurf> but wouldn't that be content-type, not content-encoding?
[20:21] <RainCT> Uhm.. Right :P
[20:21] <chrismurf> http://pastebin.ca/1333005
[20:22] <chrismurf> Firefox Live HTTP Headers for the download
[20:22] <chrismurf> so - the server is listing the content-length as 2691 for firefox
[20:25] <chrismurf> RainCT, http://pastebin.ca/1333006
[20:25] <porthose> iulian: the requested diff.gz has been posted for Bug #300445, if you have some spare time would you please have a look , thanks ;-)
[20:25] <chrismurf> RainCT, fabrice_sp, wget has different headers sent to it than Firefox does
[20:27] <fabrice_sp> chrismurf, I'm trying to build with the wget version of diff file
[20:27] <chrismurf> fabrice_sp, I'll leave you alone then ;-)
[20:28] <Chris`> Before I cry -- Can someone have a look at this for me? -- http://revu.ubuntuwire.com/details.py?upid=4991
[20:29] <RainCT> with epiphany it also fails..
[20:30]  * Laney gets gnome-shell
[20:31] <Laney> I spied your name there RainCT
[20:31] <RainCT> Laney: :)
[20:31] <Laney> is it usable?
[20:31] <alex_muntada> james_w: I was asking RainCT about bug #280381 and he suggested that I should better ask you
[20:32] <fabrice_sp> Chris`, what do you want others to look at?
[20:32] <alex_muntada> james_w: how can i bzr import-dsc a debian .dsc on a previous ubuntu branch (no upstream-debian tag exists)
[20:33] <chrismurf> RainCT, only difference I can see (besides length) is the ETag + Content-Encoding are .gzip
[20:33] <chrismurf> which seems like mod_deflate (?)
[20:34] <RainCT> Laney: Depending on the graphics card, perhaps (although I wouldn't recommend you to replace compiz/metacity with it :)). Here it runs rather slow.. :(
[20:34] <Laney> :<
[20:35] <RainCT> Laney: according to the developers it works best with Intel 9xxx cards
[20:35]  * Laney has ATI
[20:37] <RainCT> chrismurf: About point 2 on REVU, you have to specify a minimum debhelper version, but it can be >= 5.x, 6 or 7
[20:38] <chrismurf> RainCT, thanks :-) It's now 5
[20:38] <chrismurf> RainCT, Also, I just realized that if I gzip -d the downloaded file, I get the correct file
[20:38] <chrismurf> so - it's getting gzipped twice
[20:38] <chrismurf> and not ungzipped once by the browser
[20:49] <hyperair> is it me or is revu down?
[20:49] <hyperair> no wait, it's up again
[20:50] <Laney> RainCT: Oh my god it's ruined my desktop!
[20:50]  * Laney wonders how to get back to metacity
[20:50] <RainCT> Laney: LOL. Just Ctrl+C
[20:50] <Laney> haha
[20:51] <RainCT> hyperair: I'm restarting Apache ^^
[20:51] <Laney> I could barely even read the text
[20:51] <Laney> that was fun
[20:51] <hyperair> RainCT: lol
[20:51] <hyperair> RainCT: why?
[20:51] <hyperair> RainCT: should be force-reload
[20:51] <hyperair> also i'm curious to know where jpds got my surname from =O
[20:52] <chrismurf> hyperair, https://wiki.edubuntu.org/hyperair? ;-)
[20:52] <RainCT> hyperair: https://wiki.edubuntu.org/hyperair
[20:53] <RainCT> heh
[20:53] <hyperair> huh why edubuntu O_o
[20:53] <Laney> google
[20:53] <hyperair> lol
[20:55] <hyperair> huh there's a hyperair on lenovo forums
[20:55] <hyperair> identity theft!
[20:56] <EagleScreen> i want to submit a bug to Universe Sponsors Queue
[20:58] <RainCT> EagleScreen: just subscribe ubuntu-{universe,main}-sponsors to it
[21:00] <quadrispro> hi RainCT, could you take a look at http://revu.ubuntuwire.com/p/nfoview ? :)
[21:03] <soren> hyperair: It's in your GPG key.
[21:07] <chrismurf> RainCT, any luck?
[21:07] <alex_muntada> james_w: i figured it out... "bzr tags" shows upstream-1.32 so i copy it to the expected tag "bzr tag upstream-debian-1.32 -r tag:upstream-1.32" and then the "bzr import-dsc --distribution debian ...." runs smoothly
[21:15] <Laney> omg sabnzbd got in
[21:16] <Laney> nice one jcfp!
[21:17] <jcfp> wow it actually did happen
[21:24] <maco> what's the maintainer supposed to be on packages in multiverse which are not in debian?
[21:24] <RainCT> maco: MOTU
[21:24] <maco> but i mean whats the actual line supposed to say then?
[21:25] <Laney> Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[21:25] <maco> and where can i find info about Standards-Version?
[21:26] <mok0> maco:  google
[21:26] <maco> heh ok
[21:26] <mok0> :-)
[21:27] <mok0> maco: current version is 3.8.0.1
[21:27] <mok0> maco: specified as 3.8.0
[21:27] <maco> so thats the one in use for jaunty?
[21:27] <mok0> maco: yep
[21:28] <maco> since im not sure how this works...if i set it to 3.8.0 and it turns out the package im working on *doesn't* comply properly, does lintian tell me that?
[21:29] <chrismurf> RainCT, any luck on the gzip bug, or should I file something in LP for Revu(?)
[21:29] <RainCT> chrismurf: I'm trying, but no luck so far :/
[21:30] <chrismurf> RainCT, anything I can do to help?  Happy to peek at the apache.conf site if that's shareable information.
[21:30] <RainCT> chrismurf: http://revu.ubuntuwire.com/revu1-incoming/pyproj-0902102030/pyproj_1.8.5-0ubuntu1.diff.gz
[21:30] <RainCT> err
[21:31] <RainCT> chrismurf: http://revu.ubuntuwire.com/~rainct/revu  :)
[21:31] <chrismurf> heh
[21:31] <mok0> chrismurf:  what bug is that?
[21:32] <RainCT> mok0: .diff.gz is compressed twice (once because it already is, and apparently a second time by Apache)
[21:32] <chrismurf> a wget downloaded version is fine
[21:32] <chrismurf> but a firefox downloaded version is too big and compressed twice.
[21:32] <chrismurf> (as a result)
[21:32] <mok0> weird
[21:33] <mok0> is it some apache plugin?
[21:33] <mok0> Well as long as dget works I don't care :-)
[21:37] <chrismurf> mok0, how do you use dget with REVU?
[21:38] <RainCT> chrismurf: dget <url of the .dsc>
[21:38] <RainCT> chrismurf: and there's even a deb-src repository :)
[21:39] <mok0> chrismurf: dget -u -x http://.... path to .dsc file
[21:39] <chrismurf> RainCT, I see :-)  I'm very new to all of this.
[21:39] <chrismurf> and the current documentation is no replacement for experience ;-)
[21:39] <mok0> chrismurf: I just copy-paste the URL from the browser to the terminal
[21:39] <chrismurf> kk
[21:40] <mok0> The person that writes a plugin for firefox to do it will be a hero
[21:44] <chrismurf> RainCT, what's in /etc/apache2/mods-available/deflate.conf ?
[21:44] <RainCT> chrismurf: AddOutputFilterByType DEFLATE text/html text/plain text/xml
[21:44] <chrismurf> do you know offhand how apache determines MIME type?
[21:45] <RainCT> nope
[21:45] <chrismurf> wonder if it sees the .diff.gz as text/plain or something
[21:45] <mok0> AFAIK the new strategy is to snoop the first bytes of the file
[21:46] <chrismurf> is lp:revu trunk the version that's running atm?
[21:46] <RainCT> chrismurf: yes
[21:46] <RainCT> chrismurf: but there isn't anything related to this there
[21:46] <chrismurf> ok - not familiar with revu, so I wasn't sure if these files were static or not
[21:47] <chrismurf> I take it they are
[21:47] <chrismurf> no headers being sent by revu
[21:47] <RainCT> chrismurf: yes, they are put into revu1-incoming when the upload is processed
[21:47] <chrismurf> k
[21:54] <RainCT> quadrispro: looking
[21:55] <quadrispro> RainCT: thanks, I'm going away now, if you will finding some issue, please add a comment :)
[21:55] <quadrispro> bye!
[21:56] <RainCT> see you
[22:08] <maco> haha
[22:38] <postalchris> Anybody free to look at http://revu.ubuntuwire.com/p/cvc3 ?
[22:40] <maxb> postalchris: There are lintian warnings....
[22:41] <postalchris> It's just the short description of 2 binary packages. Fixed in my wd
[22:43] <RainCT> kirkland: Hey. I've just installed screen-profiles from your PPA :)
[22:43] <maxb> yeah, but an upload to revu is cheap (unless you're particularly bandwidth restricted) and the first thing a potential reviewer is going to notice is that big red !
[22:46]  * RainCT notices that kirkland is away and saves his complaints for another day :P
[23:01] <postalchris> maxb: OK, I fixed that one. I still have a warning about not closing a LP bug
[23:04] <maxb> I'm uncertain whether people really care about that one
[23:09] <postalchris> I fixed that and reuploaded, but now I get "This package could not be extracted"
[23:10] <maxb> did you forget to include the orig.tar.gz in the upload?
[23:11] <postalchris> maxb: No, it got uploaded.
[23:12] <postalchris> maxb: I'm doing a version bump and re-upload.
[23:12] <maxb> MOTUs, where is it documented that a REVU package should contain only a single debian/changelog entry and not document its history in REVU? I'm sure I've read that somewhere but can't find the reference to back it up.
[23:13] <pochu> maxb: not sure if it's documented, but that's indeed pretty much a requirement for it to be uploaded
[23:13] <pochu> for the REVU history, you can look at the debdiffs REVU offers
[23:13] <postalchris> OK, now it's clean, no lintian warnings... Anybody free? http://revu.ubuntuwire.com/p/cvc3 (CVC automated theorem prover)
[23:21] <maxb> There's absolutely no difference between ${source:Version} and ${binary:Version} except in the case of Debian automatic binary rebuilds, right?
[23:45] <maxb> REVU seems to be down?
[23:48] <maxb> postalchris: I wrote you some comments but REVU seems to have broken
[23:48] <maxb> So they're here instead: http://rafb.net/p/cyfdDd76.html
[23:49] <maxb> Oh, it's back
[23:49] <maxb> comments posted
[23:51] <porthose> would a kind motu have a look at http://revu.ubuntuwire.com/p/quickplay :)
[23:55] <Caesar> Hi
[23:56] <Caesar> We've got three backport requests for Hardy that we're interested in getting some movement on
[23:56] <Caesar> We're happy to do as much of the labour as possible
[23:56] <maxb> Are they filed yet?
[23:56] <Caesar> Yes
[23:57] <Caesar> #320220 #320656 #320660
[23:57] <pochu> ScottK: ^
[23:57] <maxb> bug 320220 bug 320656 bug 320660
[23:58] <pochu> Caesar: the work basically involves building/installing/testing the package in the requested release, but I'm not a backporter...
[23:58] <maxb> Caesar: Have you seen https://help.ubuntu.com/community/UbuntuBackports ?
[23:58] <Caesar> maxb: yep
[23:59] <pochu> and I'm off to bed... good night all!
[23:59] <Caesar> We're currently running the packages
[23:59] <Caesar> We'll rebuilding them in pbuilder just to follow the steps as documented
[23:59] <Laney> huh
[23:59] <maxb> Looking at the trousers one - a sourceful backport is not required for that. hardy-backports has debhelper 7