=== webjadmin_ is now known as JackyAlcine | ||
nigelb | ajmitch: heh, the world is tiny. I didn't know you lived in Dunedin :) | 03:02 |
---|---|---|
lifeless | nigelb: you don't live in Dunedin do you? | 03:04 |
nigelb | lifeless: No, but someone I'm good friends with does! | 03:04 |
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:05 |
ajmitch | nigelb: yeah :) | 03:08 |
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
=== vibhav is now known as Guest95375 | ||
vibhav | good morning | 06:57 |
=== tsimpson_ is now known as tsimpson | ||
ESphynx | vibhav how are you :) | 07:43 |
vibhav | ESphynx: i HAVE STARTED WORKING | 07:44 |
ESphynx | you have? :) congratulations hehe | 07:45 |
ESphynx | You finished your exams yet? | 07:45 |
vibhav | yes | 07:46 |
ESphynx | ah nice :) | 07:47 |
ESphynx | Will you still have some time to get Ecere into Debian with your new job? :P | 07:47 |
vibhav | ESphynx: By work, I meant the work to bring ecere into debian | 07:54 |
ESphynx | Oh! you did :) hehe | 07:56 |
ESphynx | I thought you were saying you started a job or something :P | 07:56 |
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:57 |
ESphynx | https://github.com/ecere/sdk/tree/debian | 07:58 |
dholbach | good morning | 07:58 |
ESphynx | 'morning dholbach :) | 07:58 |
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 | 07:59 |
ESphynx | well good night guys :) | 08:06 |
vibhav | ESphynx: Have you filed any ITP or RFP bug for ecere? | 08:11 |
=== almaisan-away is now known as al-maisan | ||
=== tobin is now known as Guest24410 | ||
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:56 |
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:58 |
vibhav | ok | 09:59 |
tumbleweed | it's easier :) | 10:00 |
erbo | Zhenech: http://pastebin.com/d3Rx51d7 (dpkg --contents) | 10:00 |
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:01 |
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:02 |
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:03 |
erbo | Ah, that's it | 10:04 |
erbo | thanks a bunch, I thought I was going crazy | 10:04 |
=== al-maisan is now known as almaisan-away | ||
vibhav | I have fixed around 68 typos in a program, how do I submit these to Ubuntu\Debian? | 12:47 |
sagaci | what program is it | 12:49 |
vibhav | adunn.app | 12:50 |
vibhav | http://lintian.ubuntuwire.org/tags/spelling-error-in-binary.html | 12:51 |
=== medberry is now known as med_ | ||
tumbleweed | vibhav: send them upstream, not to Ubuntu/Debian | 12:52 |
tumbleweed | typos in documentation are worth fixing in Debian/Ubuntu, sometimes. But typos in code are not really | 12:53 |
vibhav | thanks tumbleweed | 12:53 |
=== bulldog98_ is now known as bulldog98 | ||
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:00 |
vibhav | What if I dont get a reply? | 13:02 |
tumbleweed | unfortunately, you've then probably wasted your time | 13:03 |
tumbleweed | we do have things in the archives that have dead upstreams | 13:03 |
vibhav | Then can I submit them to Debian or upstream?? | 13:09 |
tumbleweed | then we should consider whether the package should be in Debian | 13:11 |
=== bulldog98_ is now known as bulldog98 | ||
=== wcchandl1r is now known as wcchandler | ||
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 | 14:36 |
=== almaisan-away is now known as al-maisan | ||
tumbleweed | shadeslayer: correct re arch-all on i386 | 14:48 |
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:49 |
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:52 |
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? | 14:53 |
=== Guest24410 is now known as otbin | ||
=== otbin is now known as tobin | ||
tumbleweed | --binary-arch | 14:53 |
=== tobin is now known as Guest10799 | ||
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:55 |
geser | pbuilder-dist precise build --binary-arch ... (or something like that, don't remember the exact pbuilder-dist syntax) | 14:56 |
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:00 |
geser | no, but it would be nice to fix it anyways as it probable shows a bug somewhere | 15:01 |
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:02 |
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:03 |
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:04 |
* 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:05 |
shadeslayer | so by default, pbuilder should not build arch all pacakges unless the pbuilder is a i386 pbuilder | 15:06 |
shadeslayer | \end gripe | 15:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
tumbleweed | but it sounsd like any builds on arm of this package wouldn't behave correctly on other archs? | 15:15 |
geser | tumbleweed: wouldn't that be a problem only for Debian? | 15:16 |
tumbleweed | geser: what? | 15:16 |
geser | that the arch:all package build on arm would cause problems for other archs? | 15:17 |
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:18 |
tumbleweed | but generally speaking, if we know that a deb we've built is bad, we should do something to taint it | 15:19 |
=== tubadaz_ is now known as tubadaz | ||
=== imbrando1 is now known as imbrandon | ||
=== al-maisan is now known as almaisan-away | ||
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) | 16:46 |
=== lifeless_ is now known as lifeless | ||
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:00 |
micahg | pabelanger: normally, you just use -e when requesting a sync and fill in the blank | 17:02 |
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:04 |
pabelanger | ack'd | 17:05 |
micahg | pabelanger: I'll unsubscribe sponsors for you, just subscribe ubuntu-release when you're done | 17:05 |
=== medberry is now known as Guest35857 | ||
pabelanger | roger | 17:07 |
pabelanger | micahg: thanks for the tip | 17:09 |
=== webjadmin_ is now known as JackyAlcine_ | ||
=== Guest35857 is now known as med12345 | ||
=== med12345 is now known as med___ | ||
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:18 |
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:19 |
jtaylor | doesn't setting a breakpoint work? | 18:20 |
sbeattie | both gdb and strace can attach to a running process; | 18:20 |
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:22 |
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 ) | 18:23 |
=== med___ is now known as med__ | ||
=== med__ is now known as med_ | ||
=== yofel_ is now known as yofel | ||
PaoloRotolo | Hi all! | 19:09 |
=== JackyAlcine_ is now known as jalcine | ||
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:39 |
mfisch | actually I just found TFM, I'll read | 19:40 |
jtaylor | reportbug -B debian will do everything correctly | 19:41 |
micahg | alternatively, if you have the new source that was uploaded and the old source package, you can use submittodebian | 19:44 |
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 | 19:57 |
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:02 |
arand | (as already mentioned) | 20:03 |
mfisch | arand: I harassed a local colleague/debian dev to confirm that after reading the manual | 20:03 |
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:04 |
mfisch | when debian accepts the fix, we can nuke the ubuntu one | 20:05 |
mfisch | which is our goal I think | 20:05 |
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:11 |
mfisch | if debian re-did a fix and their patch also worked for ubuntu, we'd just switch to theirs right? | 20:12 |
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:13 |
arand | Isn't live-manual-* non-native? or is live-manual something else than live-manual-all? | 20:14 |
cormiert | Hi! | 20:42 |
=== JackyAlcine is now known as jalcine | ||
ESphynx | Are Unity developers left-handed? | 21:27 |
=== chrisccoulson_ is now known as chrisccoulson |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!