=== medberry is now known as med_ou
=== med_ou is now known as med_out
=== slicer_ is now known as slicer
=== FlannelKing is now known as Flannel
=== zopa is now known as azop
=== astralja1a is now known as astraljava
[08:00] <dholbach> good morning
[08:29] <ajmitch> morning dholbach
[08:29] <dholbach> hey ajmitch
[08:31] <nigelb> hello ajmitch
[08:31] <ajmitch> hi nigelb
[08:32] <nigelb> ajmitch: You haven't been around for some time or is it just my feeling? :-)
[08:34] <ajmitch> I've been around, but mostly lurking
[08:34] <nigelb> Ah, that explains that.
[08:36] <ajmitch> what have you been up to?
[08:38] <nigelb> oh this and that :)
[08:43] <ajmitch> in other words, plenty of secret stuff? :)
[08:45] <nigelb> ajmitch: Not entirely, working on the web projects last cycle, picking up ftbfs this cycle.
[08:47]  * ajmitch ought to find one thing to try & do & stick with :)
=== ximion2 is now known as ximion
=== ximion2 is now known as ximion
[11:45] <DorianJaminais> Hello
[11:45] <DorianJaminais> I am trying to package NetGameTrack
[11:45] <DorianJaminais> but I have an error using pbuilder
[11:46] <DorianJaminais> the makefile try to create a new folder : /usr/local/include/NetGameTrack
[11:47] <DorianJaminais> but I get an error message saying that it doesn't have the permission
[11:47] <Laney> ajmitch: do get libappindicator into debian :) :) :) :)
[11:47] <DorianJaminais> What is the correct way to do this ?
[11:47] <Laney> the makefile shouldn't be doing that
[11:48] <DorianJaminais> arf fail
[11:48] <DorianJaminais> so it is impossible to create new folder in /usr/local/include ?
[11:48] <DorianJaminais> or it has to be done an other way ?
[11:48] <tumbleweed> DorianJaminais: first of all, packages shouldn't put anything into /usr/local
[11:49] <DorianJaminais> so in /usr/include ?
[11:50] <tumbleweed> second, during the build, you mustn't install to the system, but to the build directory, your Makefil should understand DESTDIR (which is probably going to be ./debian/$packagename ) and install there
[11:51] <DorianJaminais> in my makefile, I got a variable PREFIX, if I change it's value to DESTDIR, should it be okay ?
[11:51] <tumbleweed> that may work as a hack, but PREFIX is something different
[11:52] <tumbleweed> PREFIX is something that could ended up in built files (i.e. if PREFIX was /usr, it should look in /usr for data). DESTDIR tells the build system to install to a staging directory rather than the host
[11:52] <DorianJaminais> alright
[11:53] <DorianJaminais> so I will rather try to replace PREFIX by DESTIR in the install target
[11:53] <nigelb> tumbleweed: were you able to put my list to good use?
[11:53] <nigelb> tumbleweed: I wonder if we should now announce a hackathon-type event for ftbfs now that we have a list.
[11:53] <tumbleweed> nigelb: nope, I'm just graphing all FTBFSs
[11:56] <tumbleweed> nigelb: so, I can easily annonate your list by finding all the ftbfs bugs filed against those packages (more than 50% have bugs), but haven't done anything else with it
[11:56] <tumbleweed> yes, announcing the hackathon is good
[11:57] <nigelb> cool, pick a date when most people can devote a few hours to it, and I can announce
[11:57] <tumbleweed> any time works for me
[11:59] <nigelb> tumbleweed: next wednesday? That way we have time to get the word out.
[12:00] <tumbleweed> sounds good to me. Anyone else?
[12:01] <nigelb> Laney, dholbach: thoughts ^
[12:01] <dholbach> nigelb, next wednesday = tomorrow?
[12:02] <nigelb> dholbach: no the week after
[12:02] <dholbach> ok, super
[12:02] <nigelb> 28th
[12:02] <dholbach> because barry wanted to run a dh_python2 porting jam on this thursday (23rd)
[12:02] <nigelb> Yeah, I remember that :-)
[12:02] <nigelb> when is the platform rally?
[12:03] <cjwatson> next week
[12:03] <nigelb> Would it affect negatively if we ran it the week of the rally?
[12:03] <Laney> what's the proposal?
[12:04] <nigelb> Laney: A hackathon like event to fix the ftbfs.
[12:04] <tumbleweed> mostly linker-related issues
[12:04] <nigelb> Ah, that too. FTBFS caused by linker issues.
[12:04] <Laney> sounds good if you can find people to do the work
[12:05] <cjwatson> I don't think there'd be a particular problem having that in parallel with the rally
[12:05] <nigelb> I intend to do the work. about finding others, well, I gotta try.
[12:05]  * tumbleweed has some local mentorees that I'll try and throw at it
[12:05] <cjwatson> unless you think there might be a problem with Canonical people mostly on the same timezone so there being less coverage to help people in different timezones
[12:05] <cjwatson> but I shouldn't think that would be a big problem
[12:06] <nigelb> In which case, I'll start blogging and writing to the mailing lists.
[12:06] <Laney> is there a status page or similar?
[12:06]  * tumbleweed can set one up
[12:07] <Laney> I wonder if an IRC bot which you can ask for a new task would be fun
[12:07] <nigelb> I thought of a wiki or etherpad. bUt a bot sounds fun too :-)
[12:07] <tumbleweed> harvestbot :)
[12:07] <Laney> ChallengeBot: !next
[12:08] <nigelb> as long as folks don't think we're spamming the channel ;)
[12:08] <tumbleweed> etherpad sounds good for something like that
[12:08] <Laney> <ChallengeBot> Laney: Fix "FTBFS: blah blah" http://some.site
[12:08] <Laney> well, could be done in PM or another channel or whateer
[12:08] <Laney> I just thought it might be a fun way to organise it
[12:09] <Laney> league table for completing challenges and so on
[12:09] <Laney> off-the-cuff thoughts :-)
[12:10] <cjwatson> when I joined the Debian release team, ajt set the prospective RAs a bunch of challenges, which were basically of the form "get these release-critical bugs fixed or the packages removed or whatever's appropriate, using your best judgement"
[12:10] <cjwatson> naturally we tended to get the intractable ones that had been sitting around for ages with people too scared to touch them
[12:10] <cjwatson> it was rather fun
[12:11] <Laney> having a list that you're emptying is quite motivating I think, indeed
[12:11] <nigelb> I suspect we can have an etherpad list with hints on how to fix, claiming and marking as fixed.
[12:12] <nigelb> I would use the wiki, but its been fairly unusable after the upgrade
[12:13] <Laney> LP bugs would be the best way to claim probably
[12:13] <Laney> just need a way to link them into the status page (harvest or whatever it is)
[12:13] <nigelb> I could hack something up tonight. Let me see.
[12:14] <tumbleweed> well that's easy, we have a list of bugs to poll, and can re-generate a status page
[12:14] <nigelb> yup
[12:14] <nigelb> tumbleweed: if you can get me bugs for each package, I can get a status page up tonight.
[12:14] <lifeless> tags?
[12:15] <Laney> quite
[12:15] <tumbleweed> nigelb: http://pastebin.com/9mGhvSBx
[12:15] <Laney> just use the API to grab bugs with a tag and make some kind of table
[12:15]  * tumbleweed prefers the tag approach, yes
[12:15] <nigelb> Right, so we needed to file bugs for all the packages first.
[12:16] <nigelb> (If they don't exist already)
[12:16] <tumbleweed> poke doko for his ftbfs-filing script, or write one
[12:16] <nigelb> ah, ok
[12:18] <Laney> are you going to use the normal sponsoring process for this or something else?
[12:19] <nigelb> normal sponsoring process
[12:19] <nigelb> Is there something else?
[12:19] <tumbleweed> i think it would be preferable to try and review those faster, though
[12:19] <tumbleweed> it's lots of similar bugs, so you want feedback before people make the same mistakes
[12:19] <Laney> I just thought that some pre-vetting / mentoring / whatever might be good
[12:19] <nigelb> Oh, that way. I hope there are mentors around who can sponsor stuff.
[12:20] <Laney> otherwise low quality fixes might make it through
[12:20] <nigelb> Yes, indeed, it would be.
=== ximion1 is now known as ximion
=== ximion2 is now known as ximion
=== highvolt1ge is now known as highvoltage
[14:25] <DorianJaminais> Sorry to disturb you again :D
[14:25] <DorianJaminais> What is the proper way in the makefile to install a file to /etc/init.d ?
[14:27] <DorianJaminais> I tried with install -m 744 root -o root file /etc/init.d
[14:27] <geser> use "dh_installinit" in the binary target in your debian/rules
[14:27] <DorianJaminais> but i get an error saying that I don't have the permission
[14:27] <DorianJaminais> @geser : thanks, I will look at it
[14:28] <geser> DorianJaminais: the whole packaging building happens in a "staging" directory, you have to install everything relativ to it
[14:29] <geser> the contents of that staging directory end in the build deb (and the deb gets unpacked to / during package installation)
[14:29] <DorianJaminais> actually at first I though doing : install -m 744 root -o root file ${DESTDIR}/../etc/init.d
[14:30] <cjwatson> if your DESTDIR requires .. after it, then you have DESTDIR set unconventionally
[14:31] <cjwatson> but aside from that, that is a perfectly normal way to write makefiles
[14:31] <cjwatson> installation locations should generally have $(DESTDIR) in front of them
[14:32] <DorianJaminais> okay so I will try with the ${DESTDIR}
[14:32] <DorianJaminais> thanks
=== med_out is now known as med
=== med is now known as medberry
[16:20] <nigelb> What's the old-fashioned way of getting the source if I'm not running oneiric?
[16:20] <nigelb> I remember it had something to do wwith the dsc file. Otherwise my memory is drawing a blank
[16:20] <micahg> nigelb: pull-lp-source in ubuntu-dev-tools works
[16:21] <nigelb> micahg: ah. Thanks.
[16:22] <Ampelbein> nigelb: or 'dget <URL_TO_DSC>
[16:22] <nigelb> dget!
[16:22] <nigelb> Ampelbein: definitely the one my memory drew a blank on :-)
[16:23] <tumbleweed> pull-lp-source saves you finding <URL_TO_DSC> :)
[16:23] <Ampelbein> nigelb: I know the problem. garlic helps ;-)
[16:25] <nigelb> tumbleweed: I did find pull-lp-source, but I had to refresh my memory on what I used to do.
[16:29] <nigelb> In a Makefile, is there a global significance for the P in $(P)INSTALL
[16:52] <nigelb> Okay, for linking changes, is there a hint on how to find where in the Makefile(s) the linking is happening?
[16:52] <nigelb> I can't find a line yet
[16:53] <tumbleweed> with a fair number of packages, the makefile is auto-generated, so you want to make sure the right makefile is generated
[16:54] <nigelb> I think this one isn't autogenerated
[16:54] <nigelb> and wherever  look, I see $(LIBS) at the eend
[16:55] <tumbleweed> nigelb: which package are you looking at?
[16:55] <Ampelbein> nigelb: the problem with link failures often is that libraries are added to $(LDFLAGS), which is wrong.
[16:55] <nigelb> tumbleweed: scratchbox2
[16:56] <nigelb> Ampelbein: Right. True here.
[16:56] <tumbleweed> this package also helpfully hides its gcc arguments :/
[16:57] <nigelb> I have a talent to pick the hard ones ;)
[16:57] <nigelb> I guess adding the libraries to CFLAGS is wrong too?
[16:58] <Ampelbein> nigelb: even more so, yes ;-)
[16:58] <Ampelbein> nigelb: libraries should go to LIBS
[16:59] <nigelb> Ampelbein: Isn't line 4 here doing that? http://paste.ubuntu.com/630444/
[16:59] <nigelb> (the wrong thing I mean)
[17:00] <Ampelbein> yes, that's wrong and is likely the cause of --as-needed issues
[17:01] <nigelb> This is going to be painful.
[17:01] <nigelb> Since they're doign the Wrong THing(TM)
[17:02] <tumbleweed> yes
[17:02] <tumbleweed> but we fixed a fair bunch of packages in the last cycle, and a few more already this cycle
[17:03] <nigelb> I'm up for fixing. Just my lack of knowledge/experience playing against me.
[17:03] <tumbleweed> Yeah, some are really easy, some nasty :)
[17:04] <nigelb> tumbleweed: suggestions on fixing this one?
[17:05] <nigelb> Can I do a LIBS declration just like the CFLAGS and then change the entry to put LIBS at the end?
[17:06] <dholbach> who would like to help me with Ubuntu Developer Week? we still have some open slots available: https://wiki.ubuntu.com/UbuntuDeveloperWeek
[17:07] <dholbach> anything you'd like to talk about or would like somebody to talk about?
[17:09] <Laney> "Who are MOTU and what do they do?" [not volunteering ;)]
[17:09] <nigelb> There's also volun-TOLD. ;)
[17:18] <nigelb> Is http://paste.ubuntu.com/630451/ the right way to modify http://paste.ubuntu.com/630444 so that the linking problems are solved?
[17:20] <nigelb> Also, if there isn't a patch system in the package, what's the suggested course of action?
[17:20] <dholbach> Laney, yeah, it'd be nice to have a session like that
[17:20] <tumbleweed> nigelb: err yes a LIBS sounds good (sorry I've got to run). Suggested course of action is a patch applied directly, and possibly stored in debian/applied-patches too
[17:22] <nigelb> tumbleweed: thanks :-)
=== Quintasan_ is now known as Quintasan
=== Guest5054 is now known as JackyAlcine
[17:46] <maco> dholbach: so nigelb is looking at scratchbox2
[17:47] <maco> when you dget it, there's scratchbox2_2.2.2-2.dsc and scratchbox2_2.2.2-2.tar.gz
[17:47] <maco> but there's no orig
[17:48] <maco> from the changelog, it looks like it started out native (no debian revision in the version string) but then transitioned to non-native and the tarball was changed to match the non-native version number
[17:49] <maco> which leaves me wondering if the maintainer has been using a flag to make debuild shut up about the lack of orig
[17:50] <Laney> it's usually mostly warnings which are rather easy to ignore
[17:50] <Laney> (by mistake)
[17:52] <micahg> well, the maintainer is treating it as native when it should be non-native since everything is being kept upstream
[17:52] <dholbach> maco, it looks like there's no tarball releases, but only stuff tagged in git (I didn't look for very long I must admit)
[17:53] <frafu_> Hi, I will package a python application (named Onboard) with distutils-extra. The package requires version 2.10 of dist-utils-extra. However, version 2.27 of distutils-extra has a bug that breaks the package building of Onboard. That bug has been fixed in version 2.28 of distutils-extra. My question: should I keep 2.10 as the required version of distutils-extra for the package, or raise it to 2.28? Thanks in advance for any advic
[17:54] <maco> dholbach: is that the usual thing to do for "stuff tagged in git"? i wouldve done a pristine-tar on it...
[17:54] <maco> (relevant to me as spim upstream has stopped releasing tarballs, just has svn, and i need to package a new tag)
[17:54] <dholbach> maco, no, I probably would do it differently
[17:55] <dholbach> if you need to make changes in Ubuntu for it now, I'd be pragmatic and just change whatever fixes the problem you're after :)
[17:55] <Laney> there's nothing really wrong with it, but arguably he should use non-native version numbers
[17:56] <micahg> Laney: there is something wrong with it, it's not a Debian native project
[17:56] <highvoltage> 2/win 6
[17:56] <Laney> why must it be to be a native package?
[17:57] <cjwatson> maco: it sometimes happens by mistake when maintainers move their source trees around or whatever and forget to ensure that the .orig.tar.gz is in the parent directory
[17:57] <cjwatson> if it's in Debian, I'd suggest poking the Debian maintainere
[17:57] <cjwatson> they probably didn't mean to do it that way
[17:57] <Laney> I almost uploaded tomboy as a native package just now, because I forgot to convert to 3.0 (quilt) when switching to bz2 origs :-)
[17:57] <maco> nigelb: you're the one fixing the ftbfs... you do the poking :P
[17:57] <Laney> the warnings are all too easy to miss
[17:58] <cjwatson> once you're in 3.0 format, dpkg-source stops you getting it wrong - that's one of the reasons 3.0 (native) and 3.0 (quilt) exist as explicitly separate formats
[17:58] <Laney> indeed
[17:59] <nigelb> maco: heh
[17:59] <maco> dholbach: well, when i make changes to spim, itll be in debian and ubuntu, as i'm one of the maintainers for it in debian, and it now ftbfs
[17:59] <Laney> But personally I'd be happy with 1.0 erroring out based on the version
[17:59] <dholbach> maco, hm?
[18:00] <cjwatson> Laney: there are too many cases of people doing it deliberately for that, I think
[18:00] <maco> dholbach: the "if you need to make changes in ubuntu for it now, just change whatever fixes the problem" bit... we're nowhere near feature freeze. i'll be mking the changes in debian and requesting a sync
[18:00] <Laney> cjwatson: Sure, as a preference or something.
[18:01] <Laney> defaults are hard to change
[18:01] <cjwatson> I suspect buxy feels that doing much further work on 1.0 is a waste of time at this point ...
[18:01] <Laney> oh yes, I don't expect it to happen …
[18:03] <micahg> Laney: ugh, I thought there was a policy, but can't find it, so I guess I was wrong, apparently there was a heated discussion about this 2 years ago: debian 544981
[18:03] <ubottu> Debian bug 544981 in developers-reference "Discourage native packages that are not tightly specific to Debian" [Wishlist,Open] http://bugs.debian.org/544981
[18:05] <Laney> micahg: Right, I think it's another one of Those Things really.
[18:05] <Laney> i.e. a best practice issue that you're encouraged to consider, but can go against if you decide it's right
[18:06] <micahg> yep, as confusing as it may be for everyone else :-/
[18:06] <Laney> 'mr' is a recent one I've come across
[18:07] <Laney> but I guess you could consider releasing to Debian as making a new upstream release and debian/changelog as your changelog ...
[18:08] <cjwatson> that's a bit different from the case where the project *does* have a separate upstream existence but is released in native format anyway
[18:10]  * maco looks at planet and snorts at "an automated version of cking"
[18:10] <Laney> I don't know anything about this particular package, but I do note a debian/ directory in git
[18:11] <Laney> anyway I'd moved to speaking more generally, and see that all the arguments have been had in that bug already so there's no need to go over them again :-)
[18:12] <nigelb> I think i hit bigger bugs in this package with my changes
[18:19] <nigelb> Now I get http://paste.ubuntu.com/630480/ while building scractchbox2, and the file doesn't eexit. It seems to be autogenerated.
[18:19] <frafu__> Sorry, I had a crash. So I am repositing my question again: I will package a python application (named Onboard) with distutils-extra. The package requires version 2.10 of dist-utils-extra. However, version 2.27 of distutils-extra has a bug that breaks the package building of Onboard. That bug has been fixed in version 2.28 of distutils-extra. My question: should I keep 2.10 as the required version of distutils-extra for the pack
=== ogra_ is now known as IIll
=== IIll is now known as ogra_
=== Guest7372 is now known as JackyAlcine
[20:01] <tumbleweed> nigelb: still stuck? If so, can I see your current debdiff
[20:11] <pcpratts> hi! is there a standard way to support both a gui and command line installer?  I need to collect some settings from the user
[20:19] <directhex> pcpratts, at package install time?
[20:19] <pcpratts> directhex: yes
[20:20] <pcpratts> directhex: I could make two build scripts and make 2 different deps, but I don't know if that is generally desired
[20:20] <directhex> pcpratts, yes, this is how debconf works - it supports multiple "frontends", and uses the configured one by default (which is the gnome one on ubuntu, the kde one on kde, the text one in a console)
[20:20] <pcpratts> directhex: deps = debs
[20:20] <pcpratts> okay
[20:21] <pcpratts> directhex: are there any debconf bindings for java that you know of?
[20:21] <directhex> er, no. you'd write a bash script for your package's post-install, which invokes debconf at the correct places. you can make it so the result of that is to run something with given parameters, though
[20:22] <directhex> you wouldn't query the debconf database from inside your app, but you'd use it to craft a config file
[20:22] <directhex> http://www.fifi.org/doc/debconf-doc/tutorial.html
[20:22] <pcpratts> directhex: okay.  thanks so much.  I can see how I can put something together.  thanks also for the tutorial link
=== webjadmin is now known as JackyAlcine
[20:25] <directhex> pcpratts, i wouldn't say it's particularly intuitive, but it's powerful and does exactly what it needs to
[20:26] <pcpratts> directhex: haha, just like most of the things you need to do to make a deb
[20:26] <pcpratts> directhex: I'm not bashing, debian and ubuntu rules.  but I never cared for make or shell scripts
[20:27] <directhex> debhelper is pretty easy, for many build systems
[20:27] <directhex> some build systems it's more difficult
[20:27] <pcpratts> directhex: yeah, all my code is in Java, so debhelper is kinda weird to use with anty
[20:27] <pcpratts> ant*
[20:27] <directhex> i don't doubt it
[20:28] <maco> pcpratts: i think you want to talk to jamespage
[20:28] <maco> he's apparently pretty masterful with java/ant stuff
[20:28] <pcpratts> maco: I've got most everything working except now someone wants a console installer
[20:29] <pcpratts> marco: we'll just have to see if my package gets accepted though
=== Quintasan_ is now known as Quintasan
=== yofel_ is now known as yofel
=== medberry is now known as med_out
[21:33] <blackmoon-105> hi, i'm try to package bt drivers with dkms, but i receive an error: http://pastebin.com/Yq7gDpUP my dkms.conf is here: http://pastebin.com/99Wp7ukb
=== jdstrand_ is now known as jdstrand
[21:55] <pcpratts> I am trying to use debconf.  I am doing most of the packaging by hand because I use java alot.  my config file is not getting put into the .deb.  any suggestions?
[21:56] <pcpratts> I don't see any relevant debhelper commands
=== med_out is now known as med
=== med is now known as medberry
[22:08] <pcpratts> I think I found it: dh_installdebconf
=== apachelogger is now known as rohansgoogle
=== rohansgoogle is now known as apachelogger