=== webjadmin_ is now known as JackyAlcine
[03:02] <nigelb> ajmitch: heh, the world is tiny. I didn't know you lived in Dunedin :)
[03:04] <lifeless> nigelb: you don't live in Dunedin do you?
[03:04] <nigelb> lifeless: No, but someone I'm good friends with does!
[03:05] <lifeless> ah :)
[03:05] <lifeless> thumper does too
[03:05] <lifeless> I used to
[03:05] <nigelb> Yeah, that was the other small world dunedin story.
[03:08] <ajmitch> nigelb: yeah :)
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== vibhav is now known as Guest95375
[06:57] <vibhav> good morning
=== tsimpson_ is now known as tsimpson
[07:43] <ESphynx> vibhav how are you :)
[07:44] <vibhav> ESphynx: i HAVE STARTED WORKING
[07:45] <ESphynx> you have? :) congratulations hehe
[07:45] <ESphynx> You finished your exams yet?
[07:46] <vibhav> yes
[07:47] <ESphynx> ah nice :)
[07:47] <ESphynx> Will you still have some time to get Ecere into Debian with your new job? :P
[07:54] <vibhav> ESphynx: By work, I meant the work to bring ecere into debian
[07:56] <ESphynx> Oh! you did :) hehe
[07:56] <ESphynx> I thought you were saying you started a job or something :P
[07:57] <vibhav> no
[07:57] <ESphynx> how's that going? What did you have to do? :)
[07:57] <vibhav> currently I am downloading the source
[07:57] <ESphynx> Did you see the debian folders we have on the Github branches?
[07:57] <vibhav> You have debian folders?
[07:57] <ESphynx> yes the debian/
[07:58] <ESphynx> https://github.com/ecere/sdk/tree/debian
[07:58] <dholbach> good morning
[07:58] <ESphynx> 'morning dholbach :)
[07:59] <vibhav> hi dholbach
[07:59] <ESphynx> vibhav: I think it all already works... it's just a matter of testing it and then adding it to sid :)
[07:59] <dholbach> hi ESphynx, vibhav
[07:59] <vibhav> ESphynx: I will still check it for any mistakes
[07:59] <ESphynx> vibhav ok :) thanks
[08:06] <ESphynx> well good night guys :)
[08:11] <vibhav> ESphynx: Have you filed any ITP or RFP bug for ecere?
=== almaisan-away is now known as al-maisan
=== tobin is now known as Guest24410
[09:56] <erbo> I'm trying to package a daemon that comes with a manpage. The manpage gets (well, should get) installed as /usr/share/man/man1/daemon-name.1.gz but when I install the .deb it doesn't get installed.. If I do dpkg --contents pkg.deb it's listed as part of the package
[09:56] <erbo> what am I missing :)
[09:58] <vibhav> the debian/install file might not be listing the manpage
[09:58] <vibhav> You can move the page to the debian directry
[09:58] <Zhenech> erbo, could you paste dpkg --contents blah.deb and dpkg -L blah?
[09:58] <tumbleweed> vibhav: one generally installs manpages with dh_installman not dh_install
[09:59] <vibhav> ok
[10:00] <tumbleweed> it's easier :)
[10:00] <erbo> Zhenech: http://pastebin.com/d3Rx51d7 (dpkg --contents)
[10:01] <tumbleweed> erbo: the manpages are there. What's the problem?
[10:01] <erbo> tumbleweed: that ls /usr/share/man/man1/ shows nothing right after installing the deb
[10:02] <erbo> Zhenech: http://pastebin.com/qPGJvgTF (that's from dpkg -L)
[10:02] <Zhenech> well, dpkg thinks it did everything right
[10:02] <tumbleweed> you sure you haven't disabled the manpage installation?
[10:02] <tumbleweed> dpkg coa be told to skip directories
[10:02] <tumbleweed> can
[10:02] <Zhenech> is your fs not loving you today? or do you have something like "localepurge" installs
[10:03] <erbo> tumbleweed: that might be it, where's is that controlled?
[10:03] <tumbleweed> erbo: http://raphaelhertzog.com/2010/11/15/save-disk-space-by-excluding-useless-files-with-dpkg/
[10:04] <erbo> Ah, that's it
[10:04] <erbo> thanks a bunch, I thought I was going crazy
=== al-maisan is now known as almaisan-away
[12:47] <vibhav> I have fixed around 68 typos in a program, how do I submit these to Ubuntu\Debian?
[12:49] <sagaci> what program is it
[12:50] <vibhav> adunn.app
[12:51] <vibhav> http://lintian.ubuntuwire.org/tags/spelling-error-in-binary.html
=== medberry is now known as med_
[12:52] <tumbleweed> vibhav: send them upstream, not to Ubuntu/Debian
[12:53] <tumbleweed> typos in documentation are worth fixing in Debian/Ubuntu, sometimes. But typos in code are not really
[12:53] <vibhav> thanks tumbleweed
=== bulldog98_ is now known as bulldog98
[13:00] <vibhav> I cannot see any thingy for contribution
[13:00] <vibhav> It just has a link to join the developer mailing list
[13:00] <tumbleweed> if they don't have a bugtracker, mail th emaintainer
[13:02] <vibhav> What if I dont get a reply?
[13:03] <tumbleweed> unfortunately, you've then probably wasted your time
[13:03] <tumbleweed> we do have things in the archives that have dead upstreams
[13:09] <vibhav> Then can I submit them to Debian or upstream??
[13:11] <tumbleweed> then we should consider whether the package should be in Debian
=== bulldog98_ is now known as bulldog98
=== wcchandl1r is now known as wcchandler
[14:36] <shadeslayer> question, if I have a arch all package that fails to build on armel because some of the icons were not built, will it fail to buildd's as well? ( The arch all package will only be built on x86 right? )
[14:36] <shadeslayer> The arch all package builds fine on x86
=== almaisan-away is now known as al-maisan
[14:48] <tumbleweed> shadeslayer: correct re arch-all on i386
[14:49] <shadeslayer> tumbleweed: okay, then for some reason kipi-plugins-common fails to build on my armel pbuilder
[14:49] <shadeslayer> I've worked around it for the moment by making the package arch any and having .install.armel
[14:52] <tumbleweed> shadeslayer: err I meant it'll only build the arch-all packages on i386
[14:52] <tumbleweed> so that shouldn't result in a failure
[14:52] <shadeslayer> exactly, I have no idea why debhelper is trying to build a arch all package in a armel pbuilder
[14:53] <tumbleweed> because pbuilder builds arch-all packages unless you tell it not to
[14:53] <shadeslayer> so how do I tell it not to build arch all packages?
=== Guest24410 is now known as otbin
=== otbin is now known as tobin
[14:53] <tumbleweed> --binary-arch
=== tobin is now known as Guest10799
[14:55] <shadeslayer> tumbleweed: do I have to pass that when creating the tarball or when calling pbuilder-dist build ?
[14:55] <geser> shadeslayer, tumbleweed: pbuilder behaves by default like a i386 buildd (not caring on which arch it is run)
[14:55] <geser> shadeslayer: you pass it when test-building
[14:55] <shadeslayer> hmm
[14:56] <geser> pbuilder-dist precise build --binary-arch ... (or something like that, don't remember the exact pbuilder-dist syntax)
[15:00] <geser> the buildd will only build the arch:all package on i386 but you should be able to build them on armel too
[15:00] <tumbleweed> that's not critical, though
[15:01] <geser> no, but it would be nice to fix it anyways as it probable shows a bug somewhere
[15:02] <tumbleweed> there are arch-all packages in the archive which only build on certain archs. Some of those only build on non-x86, unfortunatly for us (although, that could be worked around with multiarch, these days)
[15:03] <tumbleweed> when debian eventually gets around to implementing building arch-all packages on the buildds, debian will probably implement a way to say which arch the arch-all package should build on
[15:04] <ogra_> it will definitely break if someone tries to rebvuild the package locally on an arm machine
[15:04] <geser> but those are very special
[15:04]  * ogra_ agrees with geser 
[15:04] <ogra_> (that it should be fixed)
[15:04] <tumbleweed> fair enough, but there are more important FTBFSs to deal with
[15:04] <geser> I doubt shadeslayer is working on such a package
[15:05]  * shadeslayer reads backlog
[15:05]  * tumbleweed doubts so too
[15:05] <shadeslayer> my main gripe is that pbuilder is not smart enough
[15:05] <shadeslayer> building on armel takes time
[15:05] <shadeslayer> and when you get FTBFS's .... more time is lost
[15:06] <shadeslayer> so by default, pbuilder should not build arch all pacakges unless the pbuilder is a i386 pbuilder
[15:06] <shadeslayer> \end gripe
[15:07] <tumbleweed> shadeslayer: you can achive that with 3 lines of pbuilderrc
[15:07] <geser> not in general, as it is useful to check if the arch:all package builds too before uploading even if test building on amd64
[15:07] <tumbleweed> geser: totally agreed
[15:08] <shadeslayer> ok, if the pbuilder is amd64 or i386, build arch all
[15:08] <shadeslayer> else don't build arch all
[15:08] <shadeslayer> tumbleweed: I'm talking about defaults here :)
[15:08] <shadeslayer> it just doesn't make sense to me personally
[15:08] <tumbleweed> shadeslayer: I think it's fairly sensible for pbuilder to build arch-all packages by default
[15:08] <tumbleweed> I don't see why one wouldn't want to do that
[15:09] <shadeslayer> tumbleweed: because it takes time to build pacakges on arm?
[15:09] <tumbleweed> sbuild doesn't build them by default, but that's because it aims to be like a buildd
[15:09] <geser> shadeslayer: and then you test-build a package you want to try which has an strict version check on e.g. -common which is arch:all and you can't install it without --force-deps
[15:09] <tumbleweed> shadeslayer: right, but then you've got less confidence that your package still builds
[15:10] <shadeslayer> also, this brings in a interesting question, kipi-plugins-common ftbfs on armel because of missing files, should it be made arch any?
[15:11] <geser> no
[15:11] <tumbleweed> I see absolutely no reason to do anything like that
[15:11] <geser> why are those files missing when build on armel but there if build on i386?
[15:11] <tumbleweed> all vs any is strictly about the arch-independant nature of the package content
[15:12] <shadeslayer> because I've disabled libqt4-opengl-dev on armel
[15:12] <shadeslayer> tumbleweed: what if the content is not built on armel ( as proven by my current build )
[15:13] <tumbleweed> which is a fairly intrusive change, affecting a lot of armel/armhf. But clearly worth the pain
[15:13] <geser> in this case build your package with --binary-arch
[15:13] <geser> *test-build
[15:13] <tumbleweed> shadeslayer: as long as the arch-all package you are generating on x86 works on armel, I think we are fine here.
[15:13] <shadeslayer> ok
[15:13] <tumbleweed> the difference in content isn't because of a bug, just different environment
[15:14] <shadeslayer> yep
[15:14] <tumbleweed> if it concerns you, make the build abort on arm :)
[15:14] <shadeslayer> well, I'm trying to fix that, so that's not a viable solution :P
[15:15] <tumbleweed> but it sounsd like any builds on arm of this package wouldn't behave correctly on other archs?
[15:16] <geser> tumbleweed: wouldn't that be a problem only for Debian?
[15:16] <tumbleweed> geser: what?
[15:17] <geser> that the arch:all package build on arm would cause problems for other archs?
[15:18] <geser> as for Debian the arch:all package would be part of the upload while in Ubuntu it gets build by the i386 buildd
[15:18] <tumbleweed> practically, yes
[15:19] <tumbleweed> but generally speaking, if we know that a deb we've built is bad, we should do something to taint it
=== tubadaz_ is now known as tubadaz
=== imbrando1 is now known as imbrandon
=== al-maisan is now known as almaisan-away
[16:46] <Corey> Not entirely sure why this is failing: + git-dch --verbose --auto --debian-branch=master --snapshot --id-length=8 --snapshot-number=53
[16:46] <Corey> You are not on branch 'master' but on '(no branch)'
[16:46] <Corey> Then it urges me to: Use --debian-branch to set the branch to pick changes from
[16:46] <Corey> (This is being done within Jenkins)
=== lifeless_ is now known as lifeless
[17:00] <pabelanger> Afternoon, I'm looking for help with a FeatureFreezeException for a SyncRequest for rebuildd (bug 956188).  Included in the output from syncrequest plus the build.log from pbuilder
[17:00] <ubottu> Launchpad bug 956188 in rebuildd (Ubuntu) "Sync rebuildd 0.4.1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/956188
[17:02] <micahg> pabelanger: normally, you just use -e when requesting a sync and fill in the blank
[17:04] <pabelanger> micahg: Okay, should I redo the request using it?
[17:04] <micahg> pabelanger: you can just do it locally without submitting and edit the request on launchpad
[17:05] <pabelanger> ack'd
[17:05] <micahg> pabelanger: I'll unsubscribe sponsors for you, just subscribe ubuntu-release when you're done
=== medberry is now known as Guest35857
[17:07] <pabelanger> roger
[17:09] <pabelanger> micahg: thanks for the tip
=== webjadmin_ is now known as JackyAlcine_
=== Guest35857 is now known as med12345
=== med12345 is now known as med___
[18:18] <psusi> when a process is blocked in a system call, is there a way to get gdb to show what all and its args?
[18:18] <jtaylor> strace can do that
[18:19] <jtaylor> though probably youi can't attach it to a running process :/
[18:19] <psusi> you can... just was wondering if gdb can too
[18:20] <jtaylor> doesn't setting a breakpoint work?
[18:20] <sbeattie> both gdb and strace can attach to a running process;
[18:22] <psusi> yea, I can attach,  but is there a way once attached to have gdb show what system call and arguments the process is in, similar to strace?
[18:22] <jtaylor> ^C and look at the frame
[18:23] <psusi> that just tries to show the user mode stack frames
[18:23] <psusi> ( which are all unknown when you don't have debug syms )
=== med___ is now known as med__
=== med__ is now known as med_
=== yofel_ is now known as yofel
[19:09] <PaoloRotolo> Hi all!
=== JackyAlcine_ is now known as jalcine
[19:39] <mfisch> Following up on the Ubuntu fix I made last week, I'm sending it to debian.  Do I just attach the patch to an email to the bug?
[19:39] <mfisch> I assume there might be some magic phrase that tells everyone I added a patch
[19:40] <mfisch> actually I just found TFM, I'll read
[19:41] <jtaylor> reportbug -B debian will do everything correctly
[19:44] <micahg> alternatively, if you have the new source that was uploaded and the old source package, you can use submittodebian
[19:57] <mfisch> I did not know about either of those tools
[19:57] <mfisch> and I misspoke, I didn't mean sending the bug, I meant sending the fix
[20:02] <arand> mfisch: Yeah, you send the patch as an email attachment to the debian bug, if you are able to confirm that the patch works *on Debian* then you can CC the control server with "tag [bugnumber] + patch"
[20:02] <arand> reportbug with automatically do the patch sending correctly.
[20:03] <arand> (as already mentioned)
[20:03] <mfisch> arand: I harassed a local colleague/debian dev to confirm that after reading the manual
[20:04] <mfisch> arand: trying to avoid looking like an idiot today...  but anyway the patch is attached and the bug is tagged
[20:04] <arand> Nice :)
[20:05] <mfisch> when debian accepts the fix, we can nuke the ubuntu one
[20:05] <mfisch> which is our goal I think
[20:11] <arand> mfisch: Usually is, yeah, is it a native package then?
[20:11] <mfisch> arand: yeah, live-manual
[20:11] <arand> Ah, right (since otherwise the patch wouldn't be nuked, per se)
[20:12] <mfisch> if debian re-did a fix and their patch also worked for ubuntu, we'd just switch to theirs right?
[20:13] <arand> Yeah, but we'd still carry the patch in the package, it would just be synced in from debian.
[20:13] <arand> (hence not nuked, per se)
[20:14] <arand> Isn't live-manual-* non-native? or is live-manual something else than live-manual-all?
[20:42] <cormiert> Hi!
=== JackyAlcine is now known as jalcine
[21:27] <ESphynx> Are Unity developers left-handed?
=== chrisccoulson_ is now known as chrisccoulson