[00:02] <lifeless> Laney: I'm trying to determine whats going on at the moment
[00:02] <lifeless> I can't see a dup bug; I don't get a trace back
[00:05] <lifeless> this is what I see: http://paste.ubuntu.com/274940/
[00:05] <lifeless> I've hit Enter at the prompt
[00:06] <lifeless> no browser windows start up, nor $EDITOR
[00:09] <Laney> oh
[00:09] <Laney> this looks like a regression
[00:09] <lifeless> I'm on karmic, I have 0.78
[00:16] <Laney> getDebianChangelog is breaking it
[00:16] <Laney> returning nothing
[00:18] <lifeless> I uploaded 0.0.2-1 to Debian last night
[00:18] <lifeless> its what I want to sync :)
[00:20] <Laney> it hasn't appeared on http://packages.debian.org/changelogs/pool/main/s/subunit/ yet
[00:21] <lifeless> latency ><
[00:21] <lifeless> it was in binary NEW until 2 hours ago
[00:22] <Laney> we should give a better error though
[00:23] <lifeless> *an error*
[00:23] <lifeless> :)
[00:25] <Laney> no sync is an error ;)
[00:25] <lifeless> actually, I didn't know what it was. I had to go and check the bug reports etc to be convinced it had gone wrong
[00:41] <Laney> lifeless: pushed a fix to show an error in that situation
[00:42] <lifeless> thanks!
[00:42] <Laney> might look into the others tomorrow
[00:43] <captivus> Does anyone know if Launchy has been packaged for Ubuntu yet?  If it hasn't I would like to package it myself.
[02:35] <jmarsden> captivus: If apt-cache search launchy doesn't see it, and you have looked on REVU and can't see it there, then it probably isn't packaged for Ubuntu yet.
[06:34] <hyperair> Zhenech: i don't think there's a way.
[06:40] <Zhenech> hyperair, hmm, ok
[07:21] <dholbach> good morning
[07:22] <hyperair> could someone from motu-release look into bug #432900 please?
[07:35] <micahg1> if one package replaces another, do you add conflicts as well
[08:27] <Zhenech> hyperair, can you count my question as a feature request? :)
[08:27] <Zhenech> I really dislike the GPL :)
[08:28] <hyperair> Zhenech: well i'm not a geany developer. you should file a bug (preferably in the upstream tracker, i.e. the sf.net one)
[08:29] <Zhenech> meh, ok :)
[08:36] <Zhenech> hyperair, https://sourceforge.net/tracker/?func=detail&aid=2863311&group_id=153444&atid=787794
[08:38] <hyperair> O_o
[11:41] <sistpoty|work> hi folks
[11:43] <highvoltage> sistpoty | work > #ubuntu-motu :)
[11:43] <highvoltage> hi sistpoty|work
[11:43] <sistpoty|work> hi highvoltage
[12:00] <sebner> ahoi sistpoty|work :)
[12:00] <sistpoty|work> hi sebner
[12:07] <sebner> sistpoty|work: would you mind helping me with a FTBFS?  https://edge.launchpad.net/ubuntu/+source/jesd/0.0.7-2/+build/1249011/+files/buildlog_ubuntu-karmic-i386.jesd_0.0.7-2_FAILEDTOBUILD.txt.gz
[12:08] <sistpoty|work> sebner: hm... let me take a look
[12:09] <sebner> sistpoty|work: initially it FTBFS because of missing b-d on gjdoc, so I synced new debian version but it fails. It seems to be: javahelper pulls in gcj which pulls in gcj-jdk which conflicts with gjdoc. This might be the problem
[12:09] <sebner> sistpoty|work: builds locally though so I thought it's a temporaray build problem
[12:14] <sistpoty|work> sebner: you could try replacing gjdoc with gcj-jdk (which also seems to provide it)
[12:14] <sistpoty|work> sebner: ideally in the form gcj-jdk | gjdoc
[12:15] <sebner> sistpoty|work: sounds great. I'll give it a try. thx!
[12:15] <sistpoty|work> no guarantee that it'll work though :P
[12:16] <sebner> sistpoty|work: better than nothing for now ;)
[12:16] <sistpoty|work> heh
[12:26] <wgrant> ~ubuntu-dev can now retry all builds in the rebuild test.
[12:29] <sistpoty|work> \o/
[12:29] <slytherin> wgrant: Does that mean there is no restriction on MOTU members? They can retry rebuilds for core packages as well?
[12:29] <wgrant> Hm.
[12:29] <wgrant> Apparently not.
[12:29] <wgrant> There is a bug.
[12:29] <wgrant> slytherin: That's the intention.
[12:29] <wgrant> But it won't actually work.
[12:29] <wgrant> Damn.
[12:30] <slytherin> Well, we are one step closer. :-)
[12:30] <slytherin> At least you intended the behaviour to be that way.
[12:38] <sebner> sistpoty|work: it actually built in my ppa. not calling dh_javadoc -i though
[12:39] <sistpoty|work> sebner: hm... I must admit that I've tried to avoid java packages in the past :P
[12:50] <sebner> sistpoty|work: dito :P
[13:09] <slytherin> sebner: do you still need help with that FTBFS?
[13:18] <bdrung> persia, TheMuso: ping
[13:21] <sebner> slytherin: sure :) any ideas?
[13:21] <slytherin> sebner: first is that you should request for javatools sync. :-)
[13:21] <sebner> sistpoty|work: things might change. Even "Einführung in die Programmierung" uses Java :D (better than C in any chase)
[13:22] <slytherin> sebner: second is more detailed. Someone will need to look at the package and make use of standard binaries (javadoc instead of gjdoc) so you can build using any JDK/JRE combo.
[13:23] <sebner> slytherin: at least I can start with the sync request ^^ thx for your help
[13:27] <RainCT> sebner: /me is doing C++ :)
[13:27] <slytherin> sebner: Do you have any idea why is there a build dep on gjdoc?
[13:27] <sebner> slytherin: where? javatools or jesp?
[13:28] <sebner> RainCT: hahaha! poor you
[13:28] <slytherin> sebner: jesd
[13:28] <RainCT> (and the teacher rocks, he uses every change he has to laugh at MS/Bill Gates :P)
[13:28] <sebner> slytherin: to fix FTBFS in debian:   * Add dependency on gjdoc; dh_javadoc is no longer in default-java
[13:29] <slytherin> sebner: well, dh_javadoc is not part of jdk. I am checking if javahelper uses a specific javadoc alternative for dh_javadoc.
[13:29] <sebner> slytherin: kk
[13:36] <RainCT> lifeless: so what's the problem with bug 433706?
[13:37] <Laney> you have to report bugs on the ubuntu packages
[13:37] <Laney> and not on lp/u-d-t
[13:37] <Laney> s/packages/package/
[13:40] <lifeless> RainCT: so there is an upstream product
[13:40] <lifeless> RainCT: which has bugs, code hosting etc
[13:40] <lifeless> its using LP for hosting, it should accept bugs in LP
[13:41] <lifeless> this is separate from bugs in the distro
[13:41] <lifeless> e.g.
[13:41] <RainCT> Yeah, the project is used for code hosting, but bugs are disabled because we do everything in /ubuntu/+source/u-d-t
[13:41] <Laney> I don't know if it makes sense for native packages to have separate bugs
[13:41] <lifeless> it does
[13:41] <lifeless> if someone packages it in Debian, or RedHat
[13:41] <lifeless> bugs there are not Ubuntu bugs but they are still ubuntu-dev-tools bugs :)
[13:42] <Laney> they still work on ubuntu/u-d-t
[13:42] <Laney> just seems like it would introduce more bookkeeping
[13:42] <lifeless> Laney: no, they don't
[13:43]  * RainCT agrees with Iain
[13:43] <lifeless> if they're packaging it somewhere else [so that folk collaborating with ubuntu can do ubuntu tasks on their favourite os]
[13:43] <lifeless> then the bugs they run into may not exist on Ubuntu at all
[13:43] <RainCT> then they can fix it and file a merge request
[13:43] <lifeless> I'm not suggesting 'every bug you get should be in the upstream product'
[13:43] <lifeless> RainCT: but _where_ would they record the bug?
[13:44] <slytherin> sebner: looks more complicated than that. javahelper from Debian uses dh_javadoc which is only present in gjdoc.
[13:46] <Laney> lifeless: is there any precedent?
[13:46] <Laney> what does (e.g.) devscripts doO?
[13:46] <Laney> do*
[13:46] <lifeless> devscripts is debian native
[13:46] <Laney> exactly
[13:46] <RainCT> lifeless: and ubuntu-dev-tools is Ubuntu native :)
[13:46] <lifeless> so this problem exists there
[13:47] <lifeless> there is nowhere that a bug in devscripts can be discussed that is 'in the upstream bugtracker' *if the bug doesn't also display on Debian native*
[13:47] <Laney> I don't think people would reject such bugs
[13:48] <Laney> we can put a link on the upstream product to the place to file bugs
[13:48] <lifeless> shrug, I don't particularly care. I don't see having an upstream face as adding any daily bookkeeping - its not as if you'd need to shuffle every bug around
[13:48] <lifeless> or any for that matter
[13:48] <Laney> I suspect we'd just get bugs appearing randomly in both places
[13:48] <lifeless> I think its extremely weird to have an upstream presence in launchpad, host code, and *not* use the bug tracker
[13:49] <sebner> slytherin: yep, pretty annoying. We'll have to wait for our java expert geser ;)
[13:49] <Laney> if I were doing it I'd probably have the branch under ~ubuntu-dev tbh
[13:49] <lifeless> I suggest you move your branches to lp:~group/ubuntu/karmic/ubuntu-dev-tools
[13:49] <slytherin> sebner: you can meanwhile file a bug against javahelper in Debian.
[13:49] <lifeless> if all you want is codehosting
[13:49] <lifeless> That said, i think it would be a mistake, upstream products are useful things to have; they let you separate out packaging issues and developmental issues, etc etc etc
[13:50] <lifeless> if you want precedent, see upstart
[13:50] <geser> sebner: hu? since when I'm a java expert? I try to avoid java when possible
[13:50] <lifeless> gnight
[13:50] <sebner> geser: really? I see so many java uploads from you
[13:50] <Laney> geser: do you have time to look at bug 433715
[13:50] <sebner> Seems that everyone tends to avoid java *haha*
[13:50] <Laney> ?
[13:51] <geser> sebner: I justed fixed some java FTBFS
[13:51] <RainCT> (As a side note, when I first looked at ubuntu-dev-tools I was also suprised that the upstream project didn't accept bugs, but as you can see I'm now pretty happy with how it's working, and not having two places to look at and subscribe to)
[13:51] <geser> sebner: on that count you should be now a C++ expert :)
[13:51] <sebner> geser: hahaha
[13:51] <Laney> RainCT: Do you want to wontfix it?
[13:51] <Laney> I think it's an interesting point, and we can reconsider if we run into problems
[13:51] <Laney> but for now I'm happy with how it is
[13:52] <RainCT> Laney: ihmo it's invalid because it isn't a bug in the software :P
[13:52] <RainCT> and if sb isn't happy with it, the right place is the ML
[13:52] <Laney> maybe edit the project description to point to bugs.lp/u-d-t
[13:52] <lifeless> I would have filed it upstream... but I couldn't.
[13:52] <Laney> lifeless: thanks for your report though
[13:52] <lifeless> https://edge.launchpad.net/upstart <- precedent page :P
[13:53] <RainCT> lifeless: that is actively used by other distributions, though :)
[13:53] <lifeless> another really annoying thing about not having an upstream tracker is that you can't [easily] file bugs of a wishlist etc nature through the web now
[13:53] <Laney> all bugs which you would file against an upstream product are suitable against the package
[13:54] <slytherin> sebner: have you already tried simply removing gjdoc dependency?
[13:54] <lifeless> Laney: you'll need to educate folk about that; its not going to fit the mental model folk have, I suspect ;) - see RainCT's comment about his first encounter.
[13:54] <lifeless> You should at least disable all the bug tasks open upstream
[13:54] <sebner> slytherin: it'll FTBFS since dh_javadoc is called
[13:55] <Laney> Yeah this is why I've spoken for adding some explanatory text
[13:55] <RainCT> I've added a line to the description pointing to the bugs page.
[13:55] <lifeless> I really must go; tired - sorry.
[13:55] <slytherin> sebner: jesd doesn't even build a -doc package, I am not sure why javadoc will be called.
[13:55] <Laney> bye, and thanks for your input
[13:55] <Laney> RainCT: You typoed ;)
[13:55] <lifeless> my pleasure
[13:55] <RainCT> cya lifeless
[13:55] <Laney> urgh, weird
[13:55] <ScottK> lifeless: If something in ubuntu-dev-tools is useful in Red Hat, then it shouldn't be in ubuntu-dev-tools.
[13:56] <Laney> why are only some of the fields editable inline?
[13:56] <lifeless> ScottK: requestsync is useful to an upstream that develops on red hat
[13:56]  * lifeless is really really really gone
[13:56]  * ScottK doesn't understand that a bit.  See you later.
[13:56] <sebner> slytherin: ACK, but the resulting binary is half the size as with dh_javadoc (It builds with gcj-jdk | gcjdoc but doesn't call dh_javadoc)
[13:57] <RainCT> uhm.. LP has "Bugs are tracked:" and "Remote project:" options
[13:57] <Laney> it would be cool if it supported redirecting
[13:57] <RainCT> why doesn't writing launchpad.net/ ubuntu/+source/ubuntu-dev-tools there work :/
[13:59] <slytherin> sebner: Debian package looks faulty. Check this - http://packages.debian.org/sid/all/libesd-java/filelist There are no javadocs.
[14:00] <sebner> slytherin: I'll check my binaries which one is the right one
[14:02] <sebner> slytherin: http://paste.ubuntu.com/275236/
[14:05] <sebner> slytherin: is your link the really really actual version one?
[14:07] <sebner> slytherin: seems -2 is also b0rken in Debian. -1 version is http://paste.ubuntu.com/275238/
[14:13] <slytherin> sebner: he he, so file bug against jesd. :-P
[14:14]  * RainCT glances at sebner 
[14:14] <sebner> slytherin: yep but for now I upload a jesd version that (at least) builds and the file content is still the same as Debian ;)
[14:14] <moldy> hi
[14:14] <sebner> RainCT: ~~~
[14:14] <slytherin> sebner: That is find.
[14:14] <slytherin> fine
[14:14] <moldy> if my package requires a dbus configuration file in /etc/dbus-1/system.d in order to work, what is the correct way to install this file=
[14:14] <moldy> ?
[14:15] <sebner> slytherin: :), also thx for your help =)
[14:15] <slytherin> sebner: welcome
[14:15] <slytherin> moldy: is the file part of your package?
[14:15] <moldy> slytherin: yes
[14:15] <RainCT> moldy: if autotools/distutils/whatever doesn't install it, dh_install is probably the best/easiest option
[14:15] <slytherin> moldy: dh_install
[14:16] <moldy> RainCT: i don't if/how distutils can install stuff to /etc
[14:16] <RainCT> I think it has an option to install stuff wherever you want
[14:17] <RainCT> moldy: data_files
[14:17] <RainCT> moldy: there you've got an example http://paste.ubuntu.com/275249/
[14:18] <moldy> RainCT: does that work for /etc? how?
[14:18] <moldy> RainCT: as far as i see, it uses some "prefix" which is usually /usr
[14:18] <RainCT> moldy: look at the 3th item there, ('../etc/firefox-3.0/pref/',
[14:18] <moldy> RainCT: ok, i see that, but is this really the right way of handling this?
[14:20] <hyperair> 3rd!
[14:20] <RainCT> hyperair: of course, sorry :)
[14:20] <hyperair> ;-)
[14:22] <sebner> RainCT: Am I still needed? xD
[14:22] <RainCT> sebner: nah, I was just glancing *g*
[14:22]  * sebner hides
[14:23] <sebner> RainCT: git push :P
[14:24] <RainCT> sebner: patches from you are also welcome, btw! :P
[14:24] <sebner> RainCT: I'm sorry but the use of C and js doesn't really invite me :P
[14:26] <RainCT> sebner: oh well, just JavaScript should be enough for most UI stuff
[14:26] <sebner> RainCT: we need core stuff aka zeitgeist :P
[14:34] <moldy> RainCT: i fear that this will break when installing the package in setups that don't follow the usual filesystem layout
[14:35] <moldy> RainCT: e.g. buildout, to name just one example
[14:35] <james_w> stochastic: hey, around?
[14:37] <RainCT> moldy: Maybe ask in #python, I don't really use distutils much myself
[14:41] <moldy> RainCT: ok, thank you
[15:38] <moldy> slytherin: i'm sorry, but i don't quite understand how to use dh_install to install a single line into place -- can you give me a pointer?
[15:43] <hyperair> moldy: man dh_install
[15:44] <moldy> hyperair: i have read that, but i fear that i havn't quite understood it :(
[15:44] <moldy> hyperair: the text says that each line should list a file and a destination directory, but the example seems to contradict that
[15:44] <hyperair> ?
[15:44] <sebner> moldy: what's the error message?
[15:45] <moldy> hyperair: from the example: "usr/include"
[15:45] <hyperair> moldy: the destination is optional
[15:45] <hyperair> moldy: if the destination is unspecified, it means just copy the said path into debian/package/path
[15:46] <moldy> hyperair: umm, so the example package actually installs the directory usr/include?
[15:46] <hyperair> yes
[15:46] <moldy> sebner: none yet, havn't run anything yet
[15:46] <hyperair> and everything inside
[15:46] <moldy> hyperair: hmm, ok.
[15:46] <sebner> moldy: well, try it out and we'll help you then ;)
[15:47] <hyperair> moldy: dh_install basically copies stuff $(CURDIR)/<path from .install> or $(CURDIR)/debian/tmp/<path from .install> into debian/package/<destination path, if specified or original path>
[15:47] <bddebian> Heya gang
[15:47] <moldy> ok, it seems to actually work, i was just confused by the documentation. thank you.
[15:48] <hyperair> np
[15:48] <hyperair> the documentation does seem a little vague
[15:49] <moldy> it should maybe give a trivial example first before assuming stuff :)
[15:52] <hyperair> hmm no.. the description is just vague
[15:53] <hyperair> rather, it didn't mention that the destination is optional
[15:53] <moldy> yep. still, an example like "some.file /some/dir" would have made it easier for me
[15:56] <hyperair> well manpages usually have examples stuck at the bottom
[15:57] <zookos> Morning folks! (UTC-6)
[15:58] <hyperair> good night zookos (UTC+8)
[15:58] <hyperair> ;-)
[15:58] <zookos> :-)
[16:23]  * hyperair wonders if any motu-release member is around
[16:24] <sistpoty|work> hyperair: what's up?
[16:24] <hyperair> sistpoty|work: bug #432900
[16:24] <sebner> sistpoty|work: we still need another one for mupen64plus btw
[16:25] <sistpoty|work> sebner: yes, saw it ;)
[16:25] <hyperair> sistpoty|work: and the bug #433813
[16:29] <sistpoty|work> hyperair: remuco: see commenbt
[16:29] <sistpoty|work> -b
[16:30] <sistpoty|work> hyperair: regarding tangerine, can you ask seb128 for a statement? (this looks gnomeish to me ;))
[16:31] <hyperair> okay
[16:32] <sebner> sistpoty|work: I've read upstream that tangerine 3.0 is really pretty b0rken, so I'd give motu ack
[16:33]  * sistpoty|work prefers to delegate what can be delegated *g*
[16:33] <sebner> sistpoty|work: heh, I'm wondering where the java stuff moves. *HRHR*
[16:34] <hyperair> sistpoty|work: i'll admit i haven't tested remuco intensively yet. nor reproduced said bug. however, remuco 0.9.0 has been removed from archive. i think you can't really get worse than not being present at all, acn you? =p
[16:34] <hyperair> sebner: seb128 acked it. could you upload it then? =)
[16:34] <sistpoty|work> hyperair: it could wipe all files when you install it? :P
[16:34] <hyperair> sistpoty|work: okay, i'll guarantee it won't do that =)
[16:34] <sebner> hyperair: nah, I can give MOTU ACK, second  -release ack is necessary and then sync
[16:34] <Laney> no it's not
[16:34] <hyperair> ?
[16:35] <sistpoty|work> sebner: delegates have full authority to ack/rej the entire FFe
[16:35] <Laney> seb128 can ack desktop FFes
[16:35] <sebner> ah !
[16:35] <hyperair> meaning?
[16:35] <sebner> sistpoty|work: nice delegate ;)
[16:35] <Laney> meaning go ahead
[16:35] <hyperair> ah
[16:36]  * hyperair updates pbuilder
[16:36] <Laney> btw there was a package which could rm -rf / in its postinst recently ;)
[16:36] <Laney> i'd say that is worse than nothing
[16:36] <hyperair> heh. that *is* bad
[16:36] <sistpoty|work> oh, nice
[16:36] <hyperair> which package was that?
[16:36] <Laney> dunno
[16:36] <hyperair> and was anyone affected?
[16:36] <Laney> DktrKranz dealt with the SRU
[16:38]  * hyperair really needs to get round to switching to cowbuilder instead of pbuilder
[16:38] <hyperair> the tarballing will drive me nuts someday =.=
[16:39] <Laney> sbuild on lvm is pretty sexy
[16:40] <hyperair> hmm
[16:40] <hyperair> maybe i should look into that sometime
[16:40] <hyperair> it looks quite hard to set up though
[16:41] <Laney> nope, it's easy with mk-sbuild-lv
[16:41] <Laney> you should use an apt-cacher though as it doesn't do that
[16:41] <hyperair> meh damnit
[17:01] <loic-m> Would a MOTU-release member ba able to ACK bug #434078 ?
[17:01] <loic-m> s/ba/be
[17:02] <RoAkSoAx> ScottK, Heya!! Any news on the nginx issue?
[17:03] <loic-m> (There's at least two things worth having since it will be Ubuntu users first contact with the package)
[17:09] <v0lksman> can I ask general packaging questions here or is there a better channel?
[17:09] <Laney> here's good
[17:11] <v0lksman> cool...I'm using debuild -i -us -uc to build a package upgrade.  I set DEBEMAIL and DEBFULLNAME but lintian complains that changed-by-name-missing or is malformed...Did I miss something?
[17:13] <stochastic> james_w I am now, what's up?
[17:14] <sebner> v0lksman: post your changelog somewhere
[17:14] <james_w> stochastic: I was slightly confused, so my question is no longer needed.
[17:14] <sebner> v0lksman: pastbin even
[17:15] <stochastic> james_w okay.
[17:15] <james_w> stochastic: however, I'm still interested if you made any progress on getting jack in to main
[17:15] <stochastic> james_w nothing recently, I've had my hands full with work, but the required steps are being made slowly
[17:16] <james_w> cool
[17:16] <DktrKranz> Laney: yup, it was "slack", funny :)
[17:16] <v0lksman> sebner: ah ha!  http://dpaste.com/96360/
[17:16] <sebner> v0lksman: problem found: <user@localhost>   ;)
[17:17] <sebner> Laney: http://launchpadlibrarian.net/16624004/slack_0.14.1-2_0.14.1-2ubuntu1.diff.gz
[17:18] <v0lksman> sebner: yep...so I changed my DEBEMAIL env var after running uupdate....would uupdate have used the DEBEMAIL value instead when updating the changelog or is there another step I need?
[17:19] <sebner> v0lksman: either do a fresh uupdate or change it manually in your changelog
[17:19] <v0lksman> sebner: cool..thanks for the help!
[17:19] <sebner> welcome
[17:22] <loic-m> Thanks a lot sistpoty|work!
[17:22] <sistpoty|work> loic-m: you're welcome
[17:23] <sebner> sistpoty|work: uhuhuhuhu, another gamy gamy to test :D
[17:24] <sistpoty|work> heh
[17:24] <loic-m> btw, for another bug (mupen64plus), if a sync from Debian is also a NEW, do I have to file a n-p or some other bug in addition to the sync FFE?
[17:24] <v0lksman> hrm...tried a fresh uupdate with DEBEMAIL var set correctly and it still wants to put my localuser@localhost in changelog...
[17:25] <sebner> v0lksman: where did you set DEBEMAIL?
[17:25] <v0lksman> .bashrc then opened a new shell
[17:25] <v0lksman> when I echo it it is set correctly
[17:25] <sebner> v0lksman: did you do a source .bashrc?
[17:25] <sebner> v0lksman: "source .bashrc"
[17:26] <sistpoty|work> loic-m: no, the sync/FFe is all that's needed
[17:26] <v0lksman> sebner: yep...still no go
[17:27] <v0lksman> uupdate --upstream-version 0.15.7 ../tomboy-0.15.7.tar.gz
[17:27] <v0lksman> that's the command I issue
[17:28] <loic-m> sistpoty|work: thanks. So I just need to stalk an archive admin?
[17:28] <sistpoty|work> loic-m: yes, and get another +1 ;)
[17:28] <sebner> v0lksman: post your bashrc somewhere
[17:28] <Laney> echo $DEBEMAIL
[17:28] <v0lksman> $ echo $DEBEMAIL  $ v0lksman69@gmail.com
[17:29] <v0lksman> http://dpaste.com/96367/  these lines are present in .bashrc
[17:30] <sebner> v0lksman: write "export" before them
[17:30] <Laney> you can also set them in ~/.devscripts
[17:31] <v0lksman> uhg...palm to face...
[17:33] <hyperair> sistpoty|work: remuco-rhythmbox works fine (doesn't crash rhythmbox) here.
[17:34] <sistpoty|work> hyperair: that's good!
[17:34] <v0lksman> that works a bit better... :)
[17:34] <hyperair> sistpoty|work: also the banshee one looks fine.
[17:35] <hyperair> sistpoty|work: could you ack it then? =)
[17:35] <sistpoty|work> hyperair: already on it
[17:35] <sebner> v0lksman: did you forgot the "export" and does it work now?
[17:36] <v0lksman> sebner: yep...silly mistake...works like a charm now... thanks again!
[17:36] <sebner> v0lksman: heh, glad to hear it's working now :)
[17:37] <hyperair> sistpoty|work: thanks =)
[17:37] <hyperair> sistpoty|work: do i need another ack after that?
[17:37] <sistpoty|work> hyperair: yes
[17:37] <hyperair> okay
[17:47]  * sistpoty|work heads home now... cya
[17:48] <loic-m> Thanks a lot sebner
[17:48] <sebner> loic-m: welcome
[17:49] <sebner> loic-m: you stell need another -release ACK though
[17:50] <loic-m> sebner: you're not?
[17:51] <loic-m> right, m-r is only 5 ppl
[17:51] <sebner> loic-m: you normally need 2 -realease ACKs and a MOTU which sponsors it
[17:52] <loic-m> ok, I understand now
[18:03] <\sh> ScottK: we are going the way of opensuse buildservice....more packages, less quality and drive by uploader...
[18:04] <\sh> and why the hell does mr. schily has it's own getline method...
[18:07] <ScottK> \sh: I agree.
[18:11] <\sh> anyways going home
[18:17]  * hyperair wonders if anyone from motu-release is around
[18:18] <fabrice_sp> Hey, I'm just looking for a MOTU to ack bug #416262 :-)
[18:22] <fabrice_sp> this sync would solve bug #272509
[19:47] <dhillon-v10> andv: hi how are you
[19:47] <nicklas_> hello, are there any reposes you can add except philip5 s that has cutting edge software?
[19:48] <bipolar> Whats the best way to request a package sync with sid? Specificly, sid has version 1.0.0 of KMyMoney2 vs karmic's 0.9.3
[19:53] <JontheEchidna> bipolar: I'm working on 1.0.1. We can't sync the package since we no longer have aRts (we have to disable that in debian/rules) and KMyMoney has asked us to skip directly to 1.0.1 since 1.0.0 had a bad bug
[19:53] <JontheEchidna> I'll finish up the feature freeze exception later today
[19:53] <bipolar> JontheEchidna: ah! good to know! thanks!
[19:53] <JontheEchidna> yup, no problem :)
[20:03] <bdrung> persia, TheMuso: ping
[20:12] <hyperair> fta: xulrunner-1.9.3 has been consistently segfaulting firefox-3.7 from all versions 0918 onwards
[20:12] <fta> works for me
[20:13] <hyperair> hmm =\
[20:13] <fta> do you have a proper stack trace?
[20:13] <hyperair> no i don't
[20:13] <hyperair> what arch are you on?
[20:13] <fta> please install ff/xul -dbg and try to get one
[20:13] <fta> both 32 and 64
[20:13] <hyperair> okay
[20:14]  * hyperair will do that tomorrow
[20:27] <funkyHat> I'm looking for a page about updating a package to a newer version (new version is not in debian)
[20:27] <funkyHat> (I know the package probably won't get accepted for Karmic at this stage, this is for my own use/practice)
[20:29] <micahg> funkyHat: https://wiki.ubuntu.com/PackagingGuide/Complete#Creating%20and%20Using%20a%20debian/watch%20File
[20:30] <funkyHat> micahg: thanks :)
[20:39] <funkyHat> How do I remove a patch (this package is using quilt)?
[20:39] <funkyHat> Can I just remove the patch from debian/patches?
[20:40] <funkyHat> Or even just remove the line from debian/patches/series
[20:40] <sebner> funkyHat: you can comment it out with "#"
[20:40] <sebner> funkyHat: but if the patch is not needed anymore remove it
[20:41] <funkyHat> sebner: not needed, as far as I can tell. Can I just remove debian/patches altogether?
[20:41] <sebner> funkyHat: if this is the only patch, yes. mind also remove the stuff from control and rules file
[21:10] <c_korn> how can I fix those warning with g++ ? passing -Wl,--as-needed to it did not help: http://pastebin.com/d59158253
[23:40] <Davedan> is there a tutorial on how to write init script for daemon?