[00:00]  * porthose makes mental note not to work on any packages until he has had at least one cup of coffee
[00:00] <porthose> bdrung hopefully
[00:01] <bdrung> porthose: your name pops up to often. ;)
[00:05] <porthose> bdrung, is that good or bad?
[00:06] <bdrung> porthose: it's a good sign and an indicator
[00:32] <bdrung> debfx: i have responded to bug #500310
[00:35] <debfx> bdrung: I haven't found a way to make the watch file work as the download links don't contain the filename (e.g. http://plugins.guifications.org/trac/downloads/34)
[00:44] <bdrung> debfx: did you try something like this: http://git.debian.org/?p=pkg-xmms2/abraca.git;a=blob;f=debian/watch;h=facbcba11ff9acd233d6df5f17ac74dd73f3b74d;hb=0ec9073e012fe96e580a98d6ad1fb7a7a3ba737e
[00:48] <debfx> bdrung: that won't work as the URLs don't contain the version number
[00:50] <debfx> afaik uscan can only match URLs but not the link text
[00:54] <bdrung> debfx: yes, you are right. after reading the uscan manpage twice, there is probably no way to check it. can you mention the download page and the reason in the watch file (as comment)?
[00:57] <debfx> bdrung: is it still a valid watch file if it just contains comments or should I keep the old one?
[00:58] <bdrung> debfx: it only contains comments then (you do not have to keep the old one)
[00:58] <debfx> okay
[00:59] <bdrung> debfx: http://lintian.debian.org/tags/debian-watch-file-is-missing.html
[00:59] <bdrung> debfx: "If the package is not maintained upstream or if upstream uses a distribution mechanism that cannot be meaningfully monitored by uscan and the Debian External Health Status project, please consider adding a debian/watch file containing only comments documenting the situation. "
[01:08] <RoAkSoAx> ScottK, Hey! I sent you and email. I gotta go know. Please take a look at it.
[09:53] <thopiekar> hi
[09:54] <fabrice_sp> hi thopiekar
[09:54] <thopiekar> could you please help me getting navit packaged for ubuntu? I'm a launchpad user and I created packages for navit on my karmic x64, but got this on launchpad..
[09:54] <thopiekar> http://launchpadlibrarian.net/37287651/buildlog_ubuntu-karmic-amd64.navit_0.1.1-1ubuntu0karmic3_FAILEDTOBUILD.txt.gz
[09:55]  * fabrice_sp looking
[09:55] <thopiekar> somehow it doesn't work but the i386 build, which give no error message like the x64 build .. where is the difference building in x64 and i386?
[09:57] <evfire> could someone give a look to this? https://bugs.launchpad.net/debian/+source/openrpg/+bug/177560
[09:57] <fabrice_sp> thopiekar, is it a arch=all package?
[09:57] <evfire> there are two patches, I don't know if they're good
[09:57] <fabrice_sp> thopiekar, or arch=any?
[09:58] <thopiekar> fabrice_sp: it is at all a "multi - source - package"
[09:59] <thopiekar> it has 4 binary packages and more than 6 arch independent packages..
[09:59] <thopiekar> mom. i will pastebin the debian/* files..
[09:59] <fabrice_sp> thopiekar, it's not building anything in adm64. Only cleaning. Are you sure the package builds fine in amd64?
[10:00] <thopiekar> for sure.. it's working well on my x64 computer.
[10:00] <fabrice_sp> evfire, in the changelog, the bug number should be lp: #?????
[10:00] <evfire> and how is it?
[10:01] <thopiekar> control: http://pastebin.com/d62ea06f4
[10:01] <thopiekar> rules: http://pastebin.com/d6cbdd9ad
[10:01] <evfire> oh, damn... I've seen it
[10:01] <evfire> should I fix it locally and re-upload?
[10:01] <fabrice_sp> evfire, other than that, seems good
[10:01] <fabrice_sp> yes, please
[10:02] <evfire> okay :)
[10:02] <fabrice_sp> ;-)
[10:02] <evfire> fabrice_sp, is debdiff really useful?
[10:02] <evfire> it's 7mbytes...
[10:03] <fabrice_sp> nop :-)
[10:03] <evfire> better :D
[10:03] <fabrice_sp> thopiekar, why is binary-arch emplty?
[10:05] <thopiekar> fabrice_sp: at the beginning I wasn't using something like "binary-arch" but the launchpad builders said that they can'T find "binary-arch" in the rules file so I added this "dummy"..
[10:05] <evfire> fabrice_sp, updated
[10:08] <thopiekar> I'm building 4 different versions of navit .. so but I'm think it should be possible to get the opengl and sdl versions together, but I will have to talk with the devs of navit about it first..
[10:08] <thopiekar> have you found the problem?
[10:14] <evfire> fabrice_sp, is it ok for uploading now?
[10:15] <fabrice_sp> evfire, I need to have a deeper look before uploading it, but a quick look does not show anything big
[10:15] <fabrice_sp> thopiekar, you should build your package in binary-arch target
[10:15] <evfire> okay :)
[10:16] <fabrice_sp> and use -install files instead of all that cp commands
[10:16] <fabrice_sp> evfire, I have to attend my family now, but will have a deeper look later :-)
[10:16] <evfire> :D
[10:17] <evfire> good new year, anyway
[10:17] <thopiekar> fabrice_sp: so the line 208 should be called "binary-arch: binary", right?
[10:19] <fabrice_sp> thopiekar, please, have alook at http://www.debian.org/doc/debian-policy/ch-source.html, debian/rules part to understand what you should do
[10:20] <fabrice_sp> binary, binary-arch and build target is explained
[10:29] <geser> thopiekar: the i386 buildd uses the "binary" target while the others (like amd64) use the "binary-arch" target
[10:30] <thopiekar> and after "binary-arch" "binary-indep", right?
[10:31] <geser> you need to arrange that the arch:any package are created in binary-arch while the arch:all packages are in binarry-indep and binary depends on both (so both arch:all and arch:any are build on i386)
[10:32] <thopiekar> good - seems that I catched what the debian-policy-page says.. on i386 "binary" will be call which all was points to "binary-arch" and "binary-indep", but on other targets it calls "binary-arch" and "binary-indep" seperatly.
[10:34] <geser> yes (but as the architecture-independent (arch:all) packages got already build, binary-indep is not called once again)
[10:37] <thopiekar> so if there are arch:all and arch:any packages listed in [debain/control] it should run "binary-indep" after "binary-arch", right?
[10:38] <thopiekar> your message, geser, is confusing me :P
[10:41] <geser> the i386 buildds calls always the "binary" target which is often "binary: binary-arch binary-indep" in debian/rules. And "binary-arch" and "binary-indep" do the real work. On the other architectures the buildd uses always only "binary-arch"
[10:42] <thopiekar> ok got that but what about "binary-indep" in other archs?
[10:43] <geser> it's not called as the i386 buildd already build the arch:all packages
[10:44] <thopiekar> aha!
[10:45] <thopiekar> makes sense..
[10:45] <geser> binary-arch <=> build arch:any packages, binary-indep <=> build arch:all packages
[10:45] <thopiekar> otherwise it would create the same files again..
[10:45] <geser> yes
[10:46] <thopiekar> thanks geser, fabrice_sp
[10:47] <geser> if you have pbuilder, you can use "pbuilder build" for n build like on the i386 buildd and "pbuilder build --binary-arch" for a build like on amd64 to test if your package will build in both cases successfully
[11:21] <thopiekar> is it possible to crossbuild with it, too?
[11:22] <thopiekar> maybe to armel? I would like to build into armel for Nokia Internet Tablets...
[11:24] <thopiekar> :/ fixed my problem with binary-arch and -indep but I get the same problem like before..
[11:24] <thopiekar> http://launchpadlibrarian.net/37323660/buildlog_ubuntu-karmic-amd64.navit_0.1.1-1ubuntu0karmic5_FAILEDTOBUILD.txt.gz
[11:29] <geser> can you pastebin your current debian/rules?
[11:30] <geser> I've the suspicion that you missed -a (and -i) to some dh_* calls
[11:36] <thopiekar> geser: for sure - mom
[11:37] <thopiekar> http://pastebin.com/d489fbce4
[11:38] <thopiekar> I just see now that I haven't corrected .PHONY ..
[11:39] <thopiekar> btw. I taked with users at #ubuntu.de about .PHONY but we haven't come to an end what .PHONY really is for.. so could you please tell me what .PHONY is for?
[11:40] <geser> thopiekar: as I'm very familiar with Makefiles, I'd have to read it up myself and hope to understand it
[11:41] <geser> if you look at your binary-arch target it depends on your install.* targets but it doesn't build any debs
[11:42] <geser> have you tried taking a look at an existing package to see how they do it?
[11:42] <thopiekar> no
[11:43] <thopiekar> I think binary.pkg would package everything for me..
[11:44] <geser> yes, but you depend only in your binary target on it
[11:44] <geser> binary-arch has no dependency on it
[11:44] <geser> and if you don't specify anything dh_ operates on *all* packages in debian/control
[11:45] <thopiekar> so I should make deb-files after a install.* has finished?
[11:45] <geser> but as you don't build arch:all packages on the amd64 buildd you need to tell it to operate only on arch:any packages (-a)
[11:47] <geser> let me find an example
[11:47] <thopiekar> btw. do you know a package that builds debs like I need to do? I could take a look at the rules file of that pkg how they build it...
[11:47] <thopiekar> yeah, thanks
[11:51] <geser> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/tea/lucid/annotate/head%3A/debian/rules
[11:51] <geser> look at the binary, binary-arch and binary-indep targets
[11:52] <thopiekar> aah!
[11:52] <geser> the binary-arch targets calls the dh_ scripts to work on arch:any packages (-a), and the binary-indep targets specifies to work in arch:all packages (-i)
[11:53] <geser> the binary target makes sure that both (binary-arch and binary-indep) are called (e.g. for the i386 build)
[11:54] <thopiekar> but it doesn't matter that they use first of all binary-indep then binary-arch, right? I'm asking that because we said that it should be called binary: binary-arch binary-indep
[11:54] <geser> the order shouldn't matter
[11:55] <thopiekar> great! thanks again geser!
[11:55] <thopiekar> I will try that out on my debian/rules
[12:29] <geser> thopiekar: is your navit the same navit as in Debian? (http://packages.qa.debian.org/n/navit.html)
[12:30] <thopiekar> In Debian it's the current svn version and navit in Debian isn't even providing the osd-layouts..
[12:30] <thopiekar> I've added them in may package build..
[12:31] <geser> ok
[12:53] <thopiekar> geser it's working! thanks again! ppa:thopiekar/navit
[12:55] <sebner> geser: bahh, how is the correct usage of --logfile? I use sudo puilder --logfile /home/sebner/log build foo.dsc and it's not working (starting even)
[12:56] <geser> sebner: exchange the order of build and --logfile: pbuilder build --logfile ... your.dsc
[12:57] <sebner> geser: uhh, you are my hero \o/
[13:21] <randomaction> hey, I'm applying for MOTU, so if anyone wants to leave a comment you can do so at https://wiki.ubuntu.com/IlyaBarygin/MOTUApplication
[14:36] <LinuxAdmin> hi guys
[14:36] <LinuxAdmin> I'm getting troubles with "pbuilder update" command, I get "/home/nuno/.pbuilderrc: line 1: restricted: command not found"
[14:37] <LinuxAdmin> can someone help me?
[14:37] <LinuxAdmin> I'm starting with ubuntu development community, I'm following the manuals but I can't find a solution for this
[14:39] <LinuxAdmin> can someone help me?
[14:39] <LinuxAdmin> is there anybody out there?
[14:40] <Pici> LinuxAdmin: You'll have to wait longer for an answer here, but these are the folks who are best suited to answer your question :)
[14:48] <randomaction> LinuxAdmin: first line of your .pbuilderrc is malformed
[14:49] <LinuxAdmin> it is like the manual (https://wiki.ubuntu.com/PackagingGuide/GettingStarted)
[14:50] <LinuxAdmin> COMPONENTS=”main restricted universe multiverse”
[14:50] <LinuxAdmin> is there any problem with that line?
[14:50] <randomaction> use straight quotes: "
[14:52] <LinuxAdmin> thanks, copy-paste get this things
[14:52] <LinuxAdmin> it's that
[17:18] <wrapster1> how do i force install a pkg?
[17:30] <dabaR> wrapster1: why force (-f)
[21:19] <randomaction> Happy New UTC+3 Year :)
[21:25] <geser> still 96 min till 2010 for me
[22:00] <mrooney> okay, I think this is a question that has been answered many times probably, but do I need to do something special to dch -D lucid on karmic?
[22:01] <sebner> geser: nahh, don't stick to the pc like me, go outside and enjoy it! ;)
[22:12] <mrooney> is there a devscripts ppa or backport I need to install?
[22:32] <geser> sebner: it's cold outside !
[22:34] <sebner> geser: ĥahaha! no excuses! :P
[22:45] <davromaniak> hi
[22:46] <davromaniak> I would like to know if anybody bought a Landscape licence, and the cost, to have a speedy estimation
[22:47] <davromaniak> (dedicated server edition)
[22:48] <jbicha1> prob $150 per "node" http://www.canonical.com/projects/landscape/dedicated-server
[22:50] <davromaniak> jbicha1: what is a "node"
[22:50] <davromaniak> is it a "master machine", which hosts the landscape server, or a "client machine" which is monitored using landscape
[22:50] <jbicha1> each client I thought
[22:50] <davromaniak> argh
[22:53] <davromaniak> I think I will contact the sales service to have an estimated cost which can be announced and dislayed to my chief
[22:53] <jbicha1> good idea
[22:54] <davromaniak> landscape covers the features we need in our company network as all the computers (except for 3 persons) are running under linux, and will be migrated to ubuntu this year
[22:55] <davromaniak> especially when we have to deploy some security upgrades
[22:56] <davromaniak> cssh with a generic account on every machine can do the trick, but we need something "official"
[22:58] <davromaniak> and userfriendly enough to be able to give this task to a newcomer in the sysadmin service, :)
[22:58] <xnox> davromaniak: unattended upgrades for security?
[22:58] <xnox> using apt?
[22:58] <davromaniak> yes
[22:58] <davromaniak> or any package deployment
[23:00] <xnox> well set up apt repository
[23:00] <xnox> and authenticate it for unattended upgrades
[23:01] <xnox> you can do it for free now and very user friendly
[23:01] <xnox> apt in ubuntu supports this
[23:01] <davromaniak> do you have any howto I can rely on it to do a presentation to my chief ?
[23:01] <xnox> are you running ubuntu now?
[23:02] <MTecknology> If you guys want to have a little fun for newyears; there's ##ubuntu-newyears
[23:02] <xnox> /etc/apt/apt.conf.d/50unattended-upgrades
[23:02] <davromaniak> xnox: me, yes, at home and at work
[23:02] <xnox> in that file
[23:02] <xnox> you define "safe" repositories and/or block some packages
[23:02] <davromaniak> ok
[23:03] <davromaniak> for example, we can block kernel upgrade which will require a reboot
[23:03] <xnox> than at each boot they are refreshed and upgrade from those destinations are performed
[23:03] <xnox> and the root user is sent unix mail
[23:03] <xnox> I have it forwarded to my gmail
[23:03] <xnox> So sometimes I get emails that this and that packages have been upgraded
[23:03] <davromaniak> :)
[23:04] <xnox> try it out on your machine
[23:04] <davromaniak> I will try it monday, when I'll be back at the office, :)
[23:04] <xnox> davromaniak: kernel doesn't requite update
[23:04] <xnox> if unattended upgrade happens
[23:05] <xnox> next time machine is booted it is booted with new kernel
[23:05] <davromaniak> I also have to "reconstruct" the backup system, and it takes a large amount of time
[23:05] <davromaniak> xnox: the problem is the machines don't have to be shutdown
[23:05] <xnox> unless you are running custom kernels....
[23:05] <xnox> davromaniak: good luck ;-)
[23:05] <davromaniak> (developers and admins are allowed to access it using a VPN connection)
[23:06] <xnox> davromaniak: landscape imho is good when you have more than 100 computers with different configurations
[23:06] <xnox> and different physical locations
[23:07] <davromaniak> :)
[23:07] <xnox> if you are in one building and it's less than 100 you can easily set it up to be managable
[23:07] <davromaniak> we have offices is Paris and New York
[23:07] <xnox> I do suggest having /home mounted on NFS and pulled from server that you back up
[23:08] <xnox> that way you can nuke any machine and get anyone back to their "computer" with any harddrive ;-)
[23:08] <davromaniak> not exactly /home, but the home directory is in a NFS file server, which he's backuped every night, :)
[23:09] <davromaniak> so somebody can crush his system, we "only" need to reinstall it (using PXE of course, ^^)
[23:21] <geser> sebner: my was similar. "waiting" with my parents for the new year
[23:21] <geser> and currently watching the fireworks at the street and the tv transmission from berlin
[23:21] <sebner> heh
[23:22] <sebner> geser: Are you also thinking about doing some packaging work? ^^
[23:22] <geser> right now?
[23:22] <sebner> geser: sure :)
[23:23] <micahg> is it common to have the minimum debhelper version as a package dep on the -dev package with it's own debhelper script?
[23:23] <geser> hmm, doing the first european upload in 2010 would be nice :) (if nobody was faster)
[23:24] <micahg> sebner: ^^
[23:24] <xnox> micahg: yeap and merge if you can sponsor it
[23:24]  * xnox got disconnected for a sec
[23:25]  * micahg can't sponsor it, but I have a few comments that I'm adding to the merge
[23:26] <micahg> geser: could you answer the question I posted above?
[23:27] <sebner> geser: go go go
[23:28] <geser> you have a -dev package shipping a dh_ scrip?
[23:28] <micahg> geser: xnox wants to add dh_xulrunner to xulrunner-dev
[23:28] <micahg> so I'm wondering what standard procedure is for depends/suggest/recommends debhelper
[23:28] <xnox> geser: yes that's the standard way to extend dh
[23:29] <xnox> eg. quilt package ships dh --with quilt
[23:29] <xnox> and the dh_patch dh_unpatch
[23:29] <xnox> and the updated sequence where/when to plug those it
[23:29] <xnox> dh_xulrunner acts in a similar way
[23:30] <xnox> it is run after shlibdeps, it scans all binaries, tries to identify whether xulrunner was used and adds correct xulrunner package as dependency
[23:30] <xnox> such that manual NMU are not required anymore.....
[23:30] <geser> I'm not familiar with "extending" debhelper, sorry
[23:31] <xnox> which is new in the latest xulrunner-dev in debian they did it with xulrunner-1.9.1 transition
[23:31]  * xnox will shut up now
[23:31]  * xnox noticed that 2010 is not up on irclogs.ubuntu.com
[23:31] <micahg> it's not 2010 yet
[23:32] <geser> here is :)
[23:32]  * micahg will research a little
[23:32] <jmarsden> Research whether it is 2010 yet? :)
[23:33] <xnox> micahg: there shouldn't be any d/s/r on debhelper
[23:33] <micahg> xnox: don't you need it to use dh_xulrunner?
[23:33] <xnox> it's an optional plugin which debhelper will pick up at runtime (that is buildtime of other packages)
[23:33] <xnox> eg. I can develop using xulrunner-dev and just use tha
[23:33] <xnox> that
[23:34] <xnox> but when I'm building a debian package and if I'm using debhelper (I will depend on it already) I will be able to do dh --with xulrunner
[23:34] <xnox> if I want to
[23:34] <xnox> look at quilt package ;-)
[23:34] <xnox> and python-support / python-central
[23:34] <micahg> xnox: yes, but I'm wondering if dh_xulrunner uses any fancy features of debhelper
[23:34] <xnox> they add the python stuff
[23:35] <xnox> plus this is not something I created
[23:35] <micahg> xnox: since we backport xulrunner all the way to hardy, we should mention is there is a minimum version of debhelper necessary to use it
[23:35] <xnox> it's "merge from Debian"
[23:35] <micahg> *if there is
[23:36] <xnox> althought we do our xulrunner from scratch
[23:37] <micahg> xnox: ok, I commented on teh merge
[23:41] <micahg> xnox: with the changes I commented in the merge, +1 from me, but I'll let asac do the actual merge and push in case I missed something, he should be available tomorrow
[23:42] <crimsun> I'd do the merge myself, but I'm rather busy with ALSA fixes
[23:51] <dhillon-v10> hi all, I was working on this merge here: https://bugs.edge.launchpad.net/ubuntu/+source/goldendict/+bug/499335 using bzr and this is the debdiff in pastebin: http://paste.ubuntu.com/349716/ does it look right
[23:53] <jmarsden> crimsun: Re FTBFS fixes... I just fixed the FTBFS for freeradius from the list, I have a debdiff (just adds a Build-Depends: quilt).  How do I get this uploaded somewhere useful to the team (I am not a MOTU)... I'm used to attaching debdiffs to bug reports... is there one for every FTBFS, or how should I proceed?
[23:55] <xnox> jmarsden: if I were you I would create a FTBFS bug in lp, attached debdiff, subscribe ubuntu-motu-sponsors....
[23:55] <xnox> jmarsden: Happy New Year ;-)
[23:55] <crimsun> jmarsden: it is nowhere as straightforward, unfortunately
[23:56] <jmarsden> That's what I was thinking, but I wondered if there was some new approach based on bzr now... and thanks, Happy New Year :)
[23:56] <crimsun> jmarsden: it really needs a merge from Debian unstable
[23:56] <crimsun> jmarsden: see the bug that I filed
[23:56] <jmarsden> crimsun: OK, will do.
[23:56] <crimsun> i.e., you also need to fix the linking against openssl, which is where the build really dies
[23:57] <dhillon-v10> crimsun: to merge from debian testing, will something like this work (if I am using bzr) bzr branch lp:debian/sid/package_name
[23:57] <dhillon-v10> * lp:debian
[23:57] <crimsun> dhillon-v10: sid? [unstable?]
[23:58] <dhillon-v10> crimsun: oh sorry, I was trying to merge from testing
[23:58] <crimsun> dhillon-v10: I'm not the person to ask, unfortunately. I still merge by hand.
[23:58] <jmarsden> crimsun: OK.  Bug Bug #501360  said it was bitesize ...
[23:58] <crimsun> jmarsden: it is a fairly straightforward merge, just requires methodical application of Ubuntu-specific patches to the existing Debian source package
[23:59] <crimsun> dhillon-v10: I believe the DistributedDevelopment wiki page may have pointers
[23:59] <jmarsden> crimsum: Oh, so the Debian package has the OpenSSL stuff fixed already?  I'll take a look.