[00:11] <RainCT> wth is ftp://ftp.gnome.org/conspiracy/index.html? XDDD
[00:12] <jpds> Anyone know who uploaded: https://edge.launchpad.net/ubuntu/+source/emelfm2 ?
[00:13] <Laney> jpds: As in who sponsored it?
[00:13] <jpds> Laney: Yeah.
[00:14] <Hobbsee> oh dera.
[00:15]  * Hobbsee looks it up
[00:16] <jpds> Hobbsee: It was definiatly sponsored, cos the guy doesn't have upload rights.
[00:17] <Laney> jpds: dholbach
[00:17] <Hobbsee> the key was 059DD5EB
[00:17] <Hobbsee> actually, it doesn't look to be that bad.
[00:17] <Hobbsee> https://lists.ubuntu.com/archives/hardy-changes/2007-November/002095.html
[00:18] <Hobbsee> who knows why dholbach decided to allow him to use 3 changelog entries for the one entry, i've no idea
[00:18] <jpds> Ahh, right. bobbo ^
[00:18] <bobbo> ah, I bet it was from changes in REVU
[00:18] <Hobbsee> bobbo: ppa, most likely
[00:18] <bobbo> Hobbsee: yeah, something like, that
[00:19] <bobbo> rofl, I almost cried when I saw it :)
[00:19] <Hobbsee> based on the second changelog entry, anyway
[00:19] <Laney> It looks to be alright apart from the changelog though
[00:19] <Laney> from a scan of the diff
[00:19] <marnold> looks like all changelog entries were included in the .changes
[00:20] <marnold> but lp doesn't recognize it
[00:22] <marnold> which is odd
[00:36] <badzero> hallo ubuntu package-devs pleas merge this packet to newer version 4.0.0.4 http://packages.ubuntu.com/intrepid/vuze
[00:37] <marnold> oh and Laney ant changes are related to the multiuser patch so I'm not going to touch that and dh_links is ui selector
[00:38] <marnold> sorry
[00:38] <Laney> marnold: It's often good to list which files are touched by each change
[00:38] <Laney> debian/rules, debian/control: Do foo because bar
[00:41] <marnold> and badzero Ubuntu has patches against 3.1 so i don't think anybody is going to touch that until the person who made said patches merges them with 4.x
[00:42] <badzero> aha ok thx
[00:42] <marnold> thats not to say a new vuze4 package is out of the question
[00:43] <marnold> but motu-p2p should do that
[00:43] <marnold> he left :/
[00:44] <marnold> hate it when people leave when i'm talking
[00:45] <directhex> it's how the kids use irc these days
[00:45] <directhex> you;re lucky he stuck around long enough for you to actually be able to get an answer in
[00:48] <marnold> directhex, i know i run an IRC network thats only populated for 1hr/day, because of that
[00:49] <marnold> :(
[00:49] <directhex> evidently you're just not hip enough for the web 2.0 generation
[00:49] <directhex> they use their tweeters and friendfaces and yourspaces, not this irc nonsense!
[00:50] <marnold> I am supposedly a part of it so :( again
[00:51] <marnold> even my CS class is like that
[00:51] <marnold> i was explaining why somebody's for loop didn't work
[00:52] <marnold> and when i asked if he understood
[00:53] <marnold> he says "No, because you were talking to much"
[00:55] <directhex> they don't need to understand things, that's wikipedia's job!
[00:56] <directhex> well i never, a genuine NCommander!
[00:56] <marnold> and then he says "So whats the code to correct this?"
[00:56]  * NCommander fails to validate
[00:56] <NCommander> I'm not genuine at all :-P
[00:56] <Hobbsee> marnold: i thought that was where you gave them the wikipedia link, and said "read this first, then come back with questions"
[00:57] <directhex> Hobbsee, give a man a fire, he's warm for a day. set him on fire, and he's warm for the rest of his life!
[00:57]  * Hobbsee actually found wikipedia quite helpful this yera for one of her subjects - although perhaps that was because the lecturers, and hte lecture notes, weren't great.
[00:57] <Hobbsee> directhex: indeed!
[00:57] <marnold> no the Professor came in
[00:57]  * Hobbsee sets directhex on fire
[00:57] <directhex> or, erm, woman. i'm an equal-opportunity immolator.
[00:57] <Hobbsee> directhex: did I see you say you'd sent a mail to ubuntu-devel@?
[00:58] <marnold> gave him an earfull
[00:58] <directhex> Hobbsee, not recently. why?
[00:58] <Hobbsee> oh, good ;)
[00:58] <marnold> and then almost kicked him from the lab for swearing
[00:59] <marnold> he changed his major after that
[00:59] <marnold> :P
[01:08] <serialorder> Question that has been confusing me lately. How should one choose among: iceape-dev, seamonkey-dev, libxul-dev, xulrunner-1.9-dev ?
[01:09] <directhex> serialorder, 'ubuntu-mozillateam
[01:09] <serialorder> directhex, thanks
[01:09] <directhex> serialorder, generally speaking, is your package browser specific, or does it apply to all moz-based browsers?do you want to use your package on debian?
[01:11] <serialorder> it was a merge i was working on last week. It FTBFS because it depended on iceape-dev but when I changed it to depend on libxul-dev it built fine. Then as I investigated the various packages there seemed to be those four and each one recommended using another one rather than itself.
[01:12] <serialorder> but i will now go pester ubuntu-mozillateam
[01:14] <directhex> IIRC it should be xulrunner-dev (>= 1.9) | xulrunner-1.9-dev
[01:14] <directhex> for debian AND ubuntu joy
[01:15] <directhex> but don't quote me on that
[01:35] <vorian> ScottK: I've been in contact with the kdenlive folks.  It seems our FFmpeg is missing a few things, and there is also some libs missing from our MLT.
[03:37] <crimsun> does motu have an lp liaison again?
[03:38] <crimsun> if not, i'd like to propose someone =)
[03:38] <crimsun> oh wait, this was answered at uds. nevermind.
[03:39] <Hobbsee> crimsun: I believe it does, but i'm not sure if it's by name only
[03:39] <Hobbsee> or if he's still interested in doing it
[04:28] <hyperair> does anyone have time to revu? http://revu.ubuntuwire.com/details.py?package=codelite
[04:36] <nhandler> hyperair: I'll review it again tomorrow
[04:53] <hyperair> nhandler: okay thanks
[05:33] <ScottK> vorian: OK.  For ffmpeg, siretart is the one to talk to.
[08:30] <AnAnt> Hello, how do I know the list of motus ? or UUS ?
[08:33] <iulian> AnAnt: launchpad.net/~motu/+members and ~/universe-contributors/+members.
[08:38] <AnAnt> thanks
[09:04] <huats> Silly question, but I have installed a jaunty alpha  to test my packages in a vm, and I notice that there is an empty xorg.conf... is it normal ?
[09:08] <persia> huats, Yes, and intentional.  Everything you need should be autodetected.
[09:08] <huats> persia: yeah I assumed :)
[09:09] <huats> persia: hello btw
[09:09] <huats>  :)
[09:09] <huats> I was just wondering since the resolution is very low
[09:09] <huats> and I'd like to have a bigger one...
[09:13] <_ruben> huats: you might need an extra/3rd-party driver, depending the virtualization product you use
[09:13] <huats> _ruben: hum
[09:13] <huats> _ruben: may be indeed
[09:13] <didrocks> huats: for virtualbox, you need to add some extra values (it set it up when needed)
[09:13] <didrocks> hi btw too ;)
[09:14] <huats> but it was working fine as it (I use kvm)
[09:14] <huats> _ruben: but I'll have a look in that direction :)
[09:15] <_ruben> no experience with kvm myself, but i dont expect it to require additional drivers, could be wrong though .. might be a (k)vm setting as well
[09:17] <persia> huats, For some virtualisation solutions, you can just use xrandr to change the resolution.
[09:36] <AnAnt> Hello, can someone please bug 311763 ?
[13:42] <AnAnt> Hello, can someone review bug 311763 ?
[15:33] <AdamDH> if I am unpacking my source inside the rules file, do I have to move the source any where after that? it would just be in a packagename.version directory
[15:34] <pmjdebruijn> AdamDH: that's bad practise...
[15:35] <AdamDH> i am unpacking upstream source then applying a patch
[15:35] <pmjdebruijn> AdamDH: I think the fontforge package does that as well, you might want to look at that... if you _must_...
[15:35] <AdamDH> this is my second package so any advice would be welcomed
[15:35] <pmjdebruijn> AdamDH: yeah, then you don't need to unpack the sources in the rules file
[15:35] <pmjdebruijn> AdamDH: why do you need to unpack in the rules file?
[15:36] <AdamDH> dont you need to unpack so you can apply a patch? I am just shipping the upstream .ta.gz for binutils
[15:36] <pmjdebruijn> huh
[15:36] <pmjdebruijn> no?
[15:36] <pmjdebruijn> AdamDH: have you read up on dpatch?
[15:36] <pmjdebruijn> AdamDH: why are you packaging binutils? it is already packaged...
[15:37] <AdamDH> because I am packaging a cross compiler, so I apply a patch to the binutils source to add msp430 support like the AVR project does
[15:37] <pmjdebruijn> uh
[15:38] <pmjdebruijn> AdamDH: why not take the current package, and modify that. instead of starting from scratch?
[15:38] <pmjdebruijn> AdamDH: http://packages.ubuntu.com/jaunty/binutils-avr
[15:39] <pmjdebruijn> AdamDH: there are several binutils-XXXX already package... take of one those... and modify to your liking
[15:39] <AdamDH> i have been playing about with packing on and off for two days and every example package I look at does something diffrent in rules, even if its the same package
[15:40] <AdamDH> the binutils-avr package does:
[15:40] <AdamDH> binutils-2.18.tar.bz2:
[15:40] <AdamDH>         ln -s /usr/src/binutils/binutils-*.tar.bz2 binutils-2.18.tar.bz2
[15:40] <AdamDH> so there is a symbolic link to the upstream source, is this the correct way to do this/
[15:40] <AdamDH> ?
[15:43] <mgdm> AdamDH: is that for 8-bit AVRs or AVR32?
[15:43] <pmjdebruijn> AdamDH: you're not particularly starting with the easier thing to package
[15:43] <pmjdebruijn> AdamDH: I have no clue on how to "best" handle this
[15:43] <AdamDH> the cross compiler I am working on is for the MSP430 microcontrollers
[15:43]  * pmjdebruijn is not familiar with building crosscompilers
[15:43]  * mgdm has been swearing at them recently
[15:44] <mgdm> but I didn't try to package it
[15:44] <AdamDH> well I know how it all works from a source install
[15:45] <AdamDH> mgdm: you have worked with the MSP430s?
[15:45] <mgdm> AdamDH: I haven't, I've been fiddling with an AVR32 device lately
[15:47] <mgdm> an NGW100
[15:49] <AdamDH> pmjdebruijn: the cross compiler is easy to get working from source, just wanted to stop doing a source install on my systems and package it, basically you have a set of configure arguments, thats easy to run in  a package, and a patch I have, you apply the patch to the upstream source, confiure make make install thats all there is to it, oh and some cleaning about
[15:50] <AdamDH> so my package was going to have the upstream binytils-2.18.tar.gz I was going to unpack that inside rules and apply the patch, simular to the udev package, is this not the best way to do it?
[15:53] <AdamDH> mgdm, running embedded linux on that?
[15:53] <mgdm> AdamDH: yep
[15:57] <loic-m> Is there anything else to do for a backport request, after filing the bug and ensuring the packages build fine and run ok (in the case of a package that didn't exist in previous versions)?
[15:58] <Laney> I think you should set the bug to confirmed, but IANAbackport
[15:58] <Laney> er
[15:59] <Laney> grr, I can't repro this rcbug
[16:05] <AnAnt_> Hello, can someone review bug 311763 ?
[16:05] <loic-m> For backport, the Ubuntu wiki says that for anyone wanting to help, the 3rd step is "Helping to build test packages, or feed package requests to the PPA "
[16:06] <AnAnt_> I have already uploaded the new source package to the bug report
[16:06] <loic-m> How does one feeds "package requests to the PPA"? Is it personnal PPA or a special PPA?
[16:08] <loic-m> in other words, is "Backports Tester Team PPA" already done?
[16:10] <AdamDH> mgdm, done some embeded work, looking at getting a beagleboard next
[16:10] <AdamDH> did you homebrew your dev board?
[16:11] <mgdm> AdamDH: Nah, it's an Atmel NGW100 reference design
[16:11] <mgdm> I fancy a Beagleboard too, but i wanted something with Ethernet first
[16:11] <AdamDH> same thats what is putting me off
[16:11] <AdamDH> been looking at the gumstixs
[16:13] <mgdm> I've seen a real Beagleboard decoding Big Buck Bunny at big resolution, it was cool :)
[16:19] <AdamDH> the beagle boards have alot of potential, if they added ethernet on board it would be ideal
[16:20] <mgdm> I was slightly confused that they don't have it on board - otherwise it'd be (theoretically) great for a cheap MythTV front-end or some such, I'd imagine
[16:20] <mgdm> Disclaimer: I might be talking rubbish
[16:21] <AdamDH> myth would run fine on it I think
[16:24] <DRebellion> DktrKranz, hey! Didn't get a chance to thank you on the ACK for cifer, so thanks :D
[16:25] <DktrKranz> DRebellion, you're welcome ;)
[16:25]  * sebner feels ignored :P
[16:25] <AdamDH> my next myth front end would probally be a cheap mac mini self upgraded
[16:26] <DktrKranz> sebner, you feel ignored, me feels unpaid ;)
[16:26] <AdamDH> what does dh_testdir actully do?
[16:26] <sebner> DktrKranz: ahahahaha
[16:26] <AnAnt_> DktrKranz: are you a UUS ?
[16:27] <DktrKranz> AnAnt_, yep
[16:28] <AnAnt_> DktrKranz: can you upload the package in this bug 311763
[16:28] <DRebellion> sebner, Dec 19 21:55:23 <DRebellion>	sebner, thanks for the advocation :D
[16:28] <DRebellion> :P
[16:28]  * DktrKranz looks
[16:28] <sebner> DRebellion: xD
[16:29] <DktrKranz> sebner, you always want greets twice... bad boy
[16:29] <sebner> DktrKranz: better than money :P
[16:29] <DktrKranz> I can't go supermarket with "greets"
[16:32] <sebner> DktrKranz: you can greet the supermarket employees :P
[16:33] <AdamDH> does any one know to any packages where patches are applied without dpatch?
[16:33] <DktrKranz> AdamDH, do you look for a specific patch system, or just a "custom" one?
[16:33] <nhandler> AdamDH: https://wiki.ubuntu.com/PackagingGuide/PatchSystems lists a few
[16:34] <AdamDH> just playing around at the moment seeing whats the best way to package this
[16:35] <AdamDH> thanks for the link
[16:35] <nhandler> You're welcome
[16:35] <DktrKranz> quilt *cough*
[16:35] <sebner> AdamDH: of course quilt :P
[16:37] <AdamDH> i am looking at the rules inside binutils-avr as this is exactley the same way the binutils-msp package should work the one I am creating, can any one just explain a few lines to me? binutils-2.18.tar.bz2 $(patched) what is $(patched)?
[16:37] <AdamDH> its in the configure section:
[16:39] <DktrKranz> AdamDH, I played with it a bit
[16:39] <AdamDH> ah its part of debhelper I think
[16:39] <DktrKranz> binutils-avr uses vanilla binutils source package, taken from binutils-src
[16:40] <DktrKranz> it unpacks it in a directory and applies patches using a custom routine
[16:41] <DktrKranz> probably because it was too complex to let quilt/dpatch/whatever to work properly that way
[16:41] <AdamDH> i played with the patch systems nothing seemed to work so I decided to apply them by hand
[16:42] <AdamDH> seems to work better
[16:42] <DktrKranz> AdamDH, are you interested in binutils-msp?
[16:42] <DktrKranz> I thougth it was OK, probably I was wrong
[16:43] <AdamDH> is there a binutils-msp?
[16:44] <AdamDH> i am packaging the whole mspgcc tool chain at present
[16:44] <DktrKranz> mh... it was probably a different name, then
[16:52] <AdamDH> i understand whats going on and whats required its just the paths, does the source have to be in the root or can it be in a directory so inside rulles I do cd ../package && ./configure etc?
[16:53] <DktrKranz> IIRC, there's a given directory for that
[16:54] <AdamDH> given directory?
[16:55]  * DktrKranz looks at http://package-import.ubuntu.com/b/binutils-avr/jaunty/files
[16:55] <DktrKranz> 505 error...
[16:56] <AdamDH> seems to be harder to create a debian package 2 days compared to 3 hours for gentoo
[16:56] <AdamDH> so much conflicting information
[17:06] <bbs> http://dpaste.com/103409/
[17:06] <bbs> can someone please help me with this?
[17:06] <bbs> my deb is perfect except for this
[17:08] <iulian> DktrKranz: That's odd. When I browse package-import.u.c, I get a "502 Proxy Error" message.
[17:08] <DktrKranz> iulian, typo ;)
[17:08] <Laney> bbs: When you do gpg --list-secret-keys, do you see exactly the same name and email as that?
[17:10]  * bbs checks
[17:11] <iulian> DktrKranz: Did you get that error when you were browsing it?
[17:11] <DktrKranz> iulian, sometimes. I usually get it only for "jaunty"
[17:11] <bbs> Laney: uid                  james toy (www.dexrex.com) <jt@dexrex.com>
[17:11] <Laney> bbs: That's not the same
[17:12] <bbs> oO
[17:12] <bbs> why since there is a comment?
[17:12] <Laney> yep
[17:12] <AdamDH> I might leave off Debain support for a while I just cannot get my head around it all or find anything that works
[17:12] <iulian> DktrKranz: Ah-ha, OK. Then it's not just me.
[17:13] <bbs> Laney: thanks a lot
[17:15] <AdamDH> does any one know to a clean example where a patch is applied without a patch system confiure arguments are run and then make make install without any crap in the rules files? just a clean example that just does it from scratch without debhelp cdbs etc?
[17:18] <AdamDH> Why is debian packaging so complicated?
[17:25] <directhex> AdamDH, because debian packages cover a variety of scenarios
[17:26] <directhex> AdamDH, for simple packages, the hard part (debian/rules) needs to be 3 lines max
[17:26] <sebner> directhex: 2 if you delete the comment :P
[17:29] <AdamDH> directhex can you pastebin me a generic rules file please?
[17:29] <AdamDH> just something so I can see how far back it can be stripped back
[17:30] <directhex> %:
[17:30] <directhex>         dh $@
[17:31] <directhex> well, with "#!/usr/bin/make -f" on the first line, of course
[17:32] <directhex> and since it's a makefi;e, that's a tab, not 8 spaces
[17:32] <AdamDH> yup but there is nothing past to configure no make no make install no make clean so nothing is going to get built?
[17:33] <AdamDH> *passed
[17:33] <james_w> Laney: thanks a lot for forwarding all of the mono patches
[17:33] <directhex> AdamDH, you asked for minimal!
[17:33] <AdamDH> i meant minimal that would actually be used to build something minimal
[17:33] <AdamDH> *ment
[17:33] <directhex> AdamDH, that runs configure with appropriate prefix, make, make install, make clean, etc.
[17:33] <directhex> AdamDH, that's enough debian/rules to make a package
[17:34] <AdamDH> this is what confuses me coming from another system where it uses basically just shell scripts and you can see cleanly how it works, I have written make files for c / cxx projects
[17:34] <Laney> james_w: you're quite welcome
[17:35] <AdamDH> with debain I don't see the flow and everyone does something diffrent there is no standard as such, everything seems to just build
[17:35] <directhex> AdamDH, so you don't want minimal, you want full.
[17:35] <jmarsden|work> AdamDH: man dh may help, look at the examples?
[17:36] <AdamDH> i just want to work without a system just a rules file, something blank to start with, I packaged some really basic stuff yesterday to play around but was not 100% sure how things worked
[17:36] <directhex> AdamDH, a rules file is a makefile. nothing more, nothing less.
[17:37] <james_w> directhex: do you want a sponsor for a merge of gnome-subtitles?
[17:37] <directhex> try http://svn.debian.org/wsvn/pkg-mono/mono-basic/trunk/debian/rules?op=file&rev=0&sc=0 as a less automated example.
[17:37] <directhex> james_w, need sublib first, and ftpmaster just rejected it
[17:37] <james_w> ah
[17:38] <AdamDH> thanks directhex that looks clean, I can follow that I will have another play
[17:38] <Laney> how did it build in debian?
[17:38] <directhex> Laney, debian is the land of binary uploads :)
[17:38]  * Laney pukes
[17:39] <Laney> there's no policy that it has to be buildable from the archive?
[17:39] <directhex> Laney, technically. but with binary uploads, it often isn't the case :)
[17:39] <james_w> Laney: yeah, it's an RC bug if it doesn't (and it's in main/contrib)
[17:40]  * directhex is fighting ikvm. currently, ikvm is winning
[17:40] <Laney> I guess experimental is more relaxed about these things
[17:40] <james_w> indeed
[17:40] <james_w> directhex: what makes it tricky?
[17:41] <directhex> james_w, generally speaking? it requires its own modified source snapshots of openjdk and gnu classpath, and uses nant to build. those are a good start on the pile of suck
[17:41] <directhex> james_w, so for one thing it takes 1.5 gig of ram to compile
[17:42] <directhex> thanks to javac bloat
[17:42] <james_w> urgh
[17:42] <james_w> my sympathies
[17:42] <directhex> in this specific case, i'm working on test builds of the new upstream release, to update the neolithic package we have
[17:42] <directhex> a test build i now have working! except if i enable assembly signing, it ftbfs with some bollocks reason
[17:43] <Laney> talked to upstream?
[17:43] <directhex> not yet. hanska did, and the aswer generally was "don't build from source", which is hardly acceptable
[17:43] <Laney> hahaha
[17:43] <directhex> but i've made more progress than he did
[17:44]  * directhex gets out the decompiler, starts decompiling & diffing
[17:45] <Laney> inline changes--
[18:00] <james_w> Laney: genpo uploaded with a few minor tweaks. Thanks for your contribution to Ubuntu :-)
[18:04] <Laney> james_w: Heh, I did wonder about that bzr repo
[18:04] <Laney> but that guy seemed to keep up with it and I thought he might complain if I took it out
[18:04] <Laney> :P
[18:39] <jpds> What's the python code is output a list (["x", "y", "z"]) as: "x, y, z"?
[18:41] <Laney> >>> ",".join(["a","b","c"])
[18:41] <Laney> 'a,b,c'
[18:41] <Laney> jpds: That close enough?
[18:41] <Laney> I guess ", ".join(... would work
[18:42] <jpds> Laney: Yay, that's works.
[19:20] <hyperair> anyone got time for revu? http://revu.ubuntuwire.com/details.py?package=codelite
[19:25] <AdamDH> does someone mind taking a look at this and telling me where I have gone wrong? http://pastebin.com/m3c210057
[19:27] <james_w> AdamDH: what's the problem you are having?
[19:28] <AdamDH> make: *** [build] Error 2
[19:28] <AdamDH> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[19:28] <AdamDH> oh this was before it make: *** [build] Error 2
[19:28] <AdamDH> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[19:28] <AdamDH> sorry:
[19:28] <AdamDH> make[1]: *** No targets specified and no makefile found.  Stop
[19:29] <james_w> ah
[19:30] <james_w> you have "$(MAKE)", but you probably want "cd src && $(MAKE)", or similar
[19:30] <james_w> because you want to build what you unpacked in to "src"
[19:30] <james_w> "$(MAKE) -C src" might do it as well
[19:32] <AdamDH> a thanks james_w did not notice that
[19:33] <AdamDH> i got some better code for the patch just hard coded it for the moment to see if it will work
[19:35] <AdamDH> cd src && /usr/bin/make
[19:35] <AdamDH> cd: 1: can't cd to src
[19:36] <AdamDH> so its not extracting the source then?
[19:43] <james_w> AdamDH: ah, because build doesn't depend on configure, configure doesn't depend on patch, and patch doesn't depend on unpack
[19:43] <AdamDH> right I follow
[19:44] <AdamDH> i will fix that
[19:51] <AdamDH> thanks James seem to be getting some where now
[19:52] <AdamDH> what path do I use for the patch? patches/patch.patch?
[19:59] <AdamDH> it cant find the files to patch No file to patch.  Skipping patch.  patch -stuN -p1 < patches/msp430-binutils-2.18-msp430-cvs.0.0.20081229.patch, should the patch be in the source dir and applied?
[19:59] <james_w> nope
[19:59] <james_w> it's the same problem as before
[19:59] <james_w> you need to cd to src first
[20:01] <AdamDH> ah thanks I fought dh_testdir moved into the src, added a cd into it
[20:25] <AdamDH> how do I pass arguments to gcc?
[20:30] <jmarsden|work> AdamDH: Traditionally, in the Makefile you can do something like CCFLAGS="-ggdb"  and make sure the compiler invocation uses $(CFLAGS)
[21:00] <AdamDH> here is a good one: checking for C compiler default output file name... configure: error: C compiler cannot create executables not had that error for a while, what would cause that?
[21:01] <james_w> AdamDH: check config.log
[21:02] <james_w> there will be some error in the test compilation
[21:03] <AdamDH> where would the log be? had a quick look around cant see it
[21:04] <james_w> find . -name "config.log"
[21:05] <james_w> it's usually in the same place as the configure script, but it can end up elsewhere in some situations
[21:07] <AdamDH> ah solved it, passed Wall as part of the CCFLAGS
[21:07] <AdamDH> just getting make problems now to look at
[21:07] <AdamDH> is there a document documenting what is required of a package to get it submitted into Ubuntu?
[21:08] <Laney> AdamDH: see /topic
[21:26] <AdamDH> im getting cc1: warnings being treated as errors, never had this before while compiling the code from source on other systems. I noticed -Werror is part of the defualt CCFLAGS
[21:31] <AdamDH> not to sure if passing -Wno-error is a good idea, its not good practice to do that
[21:40] <AdamDH> are patches in /patches automatically applied?
[21:41] <james_w> ./debian/patches?
[21:41] <james_w> not by default
[21:41] <james_w> you can enable a patch system, some of which will do it
[21:41] <AdamDH> its applying my patch twice once before configure then once after configure and before make
[21:43] <Laney> AdamDH: are you using a patch system?
[23:05] <AdamDH> configure and make seem to work well but I get make[1]: *** No rule to make target `install'.  Stop.
[23:05] <AdamDH>  any ideas? I have a $(MAKE) install
[23:11] <jmarsden|work> AdamDH: Does that need to be cd src && $(MAKE) install perhaps?
[23:11] <AdamDH> crap yes!
[23:18] <AdamDH> right its done configure make and make install and I have a feeling for how things should be done now, but I get mkdir: cannot create directory `/opt/msp430': Permission denied right at the end. Any ideas?
[23:26] <jmarsden|work> Does the src/Makefile correctly use $(DESTDIR) in its install target?
[23:29] <AdamDH> the src/Makefile is from upstream bin-utils with a patch applied, I am guessing it should do
[23:29] <jmarsden|work> That'snot good enough... read it and understand it :)
[23:30] <jmarsden|work> It sounds like your "make install" is installing into the real /opt/msp430/ instead of into ~you/package/debian/whatever/opt/msp430
[23:30] <jmarsden|work> Which is probably because there is a $(DESTDIR) missing in the Makefile.
[23:32] <AdamDH> ah because we are using a chroot to build the package
[23:32] <AdamDH> so we install inside that chroot
[23:34] <jmarsden|work> Not really a chroot, during the build we install under the package-x.y/debian because we have permission to do that, we don't have full root privs or we'd potentially break our development box...
[23:36] <AdamDH> I was doing everything inside a VM as I don't have access to my dev server here
[23:36] <jmarsden|work> OK, but you still don't want a packaging attempt to break your VM...
[23:37] <jmarsden|work> Imagine packaging gcc if the install during a packaging attempt overwrote /usr/bin/gcc :)
[23:44] <AdamDH> yer exp as the gcc cross compiler I am working with is for a diffrent arch!
[23:44] <AdamDH> i am packing binutils gcc libc for the msp430 microcontrollers
[23:45] <AdamDH> learning allot more about the inner workings of ubuntu / debian by packaging this project
[23:45] <AdamDH> we usally do source installs but as I am working on more than one system now that can be time consuming exp if you need to patch in another processor
[23:46] <jmarsden|work> OK... so now you know why the install needs to go somewhere other than the "real" install location :)  And yes, you'll learn a lot.  As the packaging guide says "It is also a good way to learn how Ubuntu and the applications you have installed work."
[23:47] <AdamDH> its a bit stress full as I am also new to ubuntu been a gentoo user for a while, but as new people use this project mspgcc its nice to have the packages there for ubuntu as this is what most people favour using now
[23:47] <AdamDH> last error I get is dpkg-gencontrol: error: current host architecture 'amd64' does not appear in package's architecture list (i386) but I set in control i386 so does this need to be set as amd64?
[23:48] <AdamDH> or set as any?
[23:49] <jmarsden|work> You're jumping into the deep end somewhat packaging a crosscompiler...
[23:50] <jmarsden|work> Wait, you are building i386 binaries of a embedded microcontroller compiler on amd64??
[23:50] <jmarsden|work> Sort of cross-cross-compiling?
[23:51] <AdamDH> my dev system is amd64
[23:51] <AdamDH> but its an i386 binary thats required
[23:52] <jpds> bigon: Thanks for that bug report. Fix commited to Bazaar now
[23:52] <jmarsden|work> AdamDH: I think you can't really do that, can you?  Maybe you should have made the VM be a 32bit VM???  You need more of a cross compiling/multiple architecture expert than I am to answer that one, I think.
[23:53] <bigon> jpds: np :)
[23:53] <AdamDH> ah ok should have used a 32bit vm
[23:53] <AdamDH> not a problem as If the rules work and I get an amd64 binary then I am allmost there
[23:54] <jpds> bigon: Could bzr branch lp:ubuntu-dev-tools and test it out for me?
[23:55] <Laney> jpds: The requestsync man page says -ns at the top, but -n in the body
[23:56] <jpds> Laney: -s is forced sponsorship-required
[23:56] <AdamDH> got my .deb now but when I check with dpkg there are no files included inside the deb just ./ ? why is this?
[23:56] <Laney> oh, two separate options/
[23:56] <Laney> ?
[23:56] <bigon> jpds: seems to work now
[23:56] <jpds> Laney: Yeah.
[23:57] <jpds> bigon: \o/ Brilliant.
[23:57] <bigon> :)
[23:58]  * jpds => bed. G'night all.
[23:58] <bigon> gn
[23:58] <AdamDH> so I created a deb that has nothing inside it at least I created a deb package!