[13:44] <abin> hello everyone
[13:45] <abin> I am new here.
[13:49] <mariuz> anyone here expert with stack protection ?
[13:49] <mariuz> hello
[13:50] <mariuz> how do i know if a c++ package is compiled with stack protection ? or is on for all packages :mysql , firebird ...
[13:52] <jpds> mariuz: kees ^^
[13:54] <jpds> mariuz: Or you can: objdump -CR /usr/bin/program | grep chk
[13:54] <mariuz> ok , i try to find if is stack protection on firebird2.1 related packages
[13:55] <mariuz> for flamerobin is on objdump -CR /usr/bin/flamerobin | grep chk
[13:56] <jpds> There should be something like: "__stack_chk_fai" I think
[13:57] <mariuz> objdump -CR /usr/lib/firebird/2.1/bin/fbserver | grep chk , I got it 083da28c R_386_JUMP_SLOT   __stack_chk_fail
[13:57] <mariuz> thanks so it's on
[13:58] <abin> can someone show me how to join motu in launchpad
[13:58] <jpds> mariuz: https://wiki.ubuntu.com/CompilerFlags#-fstack-protector
[13:59] <jpds> abin: You can't just join, see: https://wiki.ubuntu.com/MOTU/GettingStarted
[14:00] <DktrKranz> #!/usr/bin/make -f
[14:05] <abin> who can introduce  me a easy-use IRC client. i am using chatzilla
[14:05] <directhex> smuxi?
[14:05] <abin> ??
[14:06] <highvoltage> irssi
[14:06] <artfwo> pidgin
[14:06] <abin> in windows?
[14:06] <directhex> irc clients for windows are a little off-topic
[14:07] <abin> sorry but i install ubuntu in vmware, ok i stop
[14:08] <Pici> abin: If you just want to chat about Ubuntu you can join #ubuntu-offtopic
[14:09] <abin> no i am in MOTU i use vmware because i cannot get touch to US internet without windows. I a Chinese
[14:11] <lidaobing> abin, you can try #ubuntu-cn
[14:12] <abin> ok thanks
[14:12] <abin> you chinese?'
[14:12] <lidaobing> abin, yes
[14:13] <abin> You now in Chinese?
[14:14] <lidaobing> abin, if you want talk, go to #ubuntu-cn, not here
[14:15] <abin> 恩
[14:31] <directhex> why is "dpkg-buildpackage" using a different GPG key to "debsign"?
[14:31] <directhex> or to "gpg" as it happens
[14:41] <james_w> directhex: do you have DEBSIGN_KEYID set in your devscripts.conf?
[14:42] <directhex> james_w, yeah. everything behaves as it shuold except dpkg-buildpackage
[14:43] <bddebian> Heya gang
[14:43] <james_w> well dpkg-buildpackage doesn't use that file
[14:43] <james_w> hey bddebian
[14:43] <bddebian> Hi james_w
[14:43] <directhex> i think i see the problem
[15:05] <porthose> james_w directhex: congrats ! ;-)
[15:06] <james_w> thanks porthose
[15:06] <directhex> porthose, thanks
[15:07] <bddebian> What'd I miss, have james_w and directhex taken over the world? :)
[15:08] <savvas> any motu to review http://revu.ubuntuwire.com/p/gnote ?
[15:08] <directhex> bddebian, yes
[15:08] <bddebian> w00t
[15:08] <directhex> free ice cream for everyone
[15:08] <savvas> cool, congratulations! :)
[15:08] <directhex> except microsoft employees. they only get bread & water
[15:13] <james_w> time bzr branch lp:~james-w/ubuntu/karmic/ssss/karmic
[15:13] <james_w> 4.681 total
[15:13] <james_w> time apt-get source ssss
[15:13] <james_w> 4.627 total
[15:14] <bddebian> w00t congrats guys :)
[15:14] <james_w> almost there...
[15:15] <lamothe> pkern: Given up on Me TV?
[15:21] <lifeless> james_w: format?
[15:22] <hyperair> jpds: you around?
[15:24] <james_w> lifeless: development-rich-root
[15:24] <lifeless> scchweeet
[15:25] <james_w> lifeless: a few more runs show that bzr doesn't get much quicker than that, but apt can get down to 1.5 seconds on some runs
[15:25] <lifeless> james_w: run with -Dhpss
[15:25] <james_w> there's ~0.5s ssh overhead there
[15:25] <lifeless> I wager a fair chunk of that is ssh connections
[15:25] <lifeless> be interesting to toss a master ssh connection up to b.l.n
[15:26] <james_w> just did that
[15:26] <james_w> ~3.8s
[15:30] <jpds> hyperair: Hello.
[15:32] <hyperair> jpds: well hello there.
[15:32] <hyperair> jpds: may i make my changes to your package directly in svn?
[15:32] <jpds> hyperair: Yes.
[15:32] <hyperair> okay
[15:32] <hyperair> another thing..
[15:32] <hyperair> did you have anything dh7 specific?
[15:32] <hyperair> i don't see anything, but you've used a dh >= 7 b-d and compat leel 7
[15:32] <hyperair> level*
[15:33] <jpds> No, but I like latest stuff.
[15:33] <pkern> lamothe: Did I miss something?  Currently, yes.  Had some slowness trouble with it again and used kaffeine in the meantime.  (Which doesn't deactivate gnome-screensaver in jaunty, bah.)
[15:33] <hyperair> jpds: may i lower it? or would you prefer to keep it at 7?
[15:33] <pkern> lamothe: And I'm also incredibly busy.  If I missed some sponsoring request please resend it.
[15:33] <hyperair> jpds: it doesn't look like you use anything above 5.
[15:33] <jpds> hyperair: Don't mind really.
[15:34] <hyperair> alright
[15:34] <hyperair> and... i should shift everything into debian/
[15:34] <artfwo> is there some kind of checklist for the differences between debhelper 5, 6 and 7?
[15:35] <jpds> artfwo: man debhelper
[15:35] <jpds> artfwo: Look for "Debhelper compatibility levels".
[15:35] <artfwo> jpds: it's not complete, it does not mention dh_lintian for instance
[15:35] <jpds> hyperair: Whatever makes it work.
[15:35] <lamothe> pkern: Yeah, I sent it 1 month ago ... but figured you were busy.
[15:35] <lamothe> pkern: Of course I've had a few updates since then.  So I'll package those up and send them onto you.
[15:36] <lamothe> pkern: "slowness" ... like the UI not responding?
[15:36]  * hyperair feels a little awkward reviewing a MOTU's package
[15:36] <jpds> hyperair: It worked fine when I packaged it, so *shrug*
[15:36] <hyperair> hmm
[15:37] <artfwo> by the way, if anyone feels like reviewing a package, please check http://revu.ubuntuwire.com/p/scantailor :) thanks!
[15:39] <lamothe> pkern: There's an issue with the sqlite3 version in Jaunty, it's very slow.  I have put in a Jaunty specific fix where I use a separate thread to persist data.
[15:48] <hyperair> jpds: W: tomboy-latex source: timewarp-standards-version (2009-01-11 < 2009-03-12)
[15:48] <hyperair> jpds: i hope you don't mind me changing the timestamp of your changelog entry
[15:48] <jpds> hyperair: Yeah, update it for today, didn't see that when I packaged it..
[15:49] <hyperair> course you didn't. the Standards-Version was still 3.8.0.1 at that time
[15:55] <kees> mariuz: sounds like your question got answered, but yes, everything in Ubuntu is compiled with stack protection.  objdump -CR works, though I tend to use readelf -s
[16:01] <mariuz> kees : thanks good to know , i check now every binary to see if is enabled
[16:05] <kees> mariuz: what are you trying to determine?
[16:07] <mariuz> There are some issues with udf functions with firebird2.1 classic , i try to solve this bug https://bugs.edge.launchpad.net/ubuntu/+source/firebird2.1/+bug/363694
[16:10] <mariuz> i checked the supper server and seems to be compiled with stack protector enabled by default , now i'm at the firebird-classic part
[16:10] <kees> mariuz: it's not clear to me what the actual bug is -- what doesn't actually work?
[16:12] <mariuz> i think in the end both firebird and user defined functions should be compiled with stack protector
[16:13] <mariuz> for this user it seems that his udf works only if he compiles with no-stack-protector , and he says firebird classic is compiled without stack protection
[16:14] <mariuz> so i thnk all binaries should be compiled with that enabled right ?
[16:16] <mariuz> in the end i want to clarify for all users if they want to create their own UDF libraries
[16:20] <jeki> Can anyone look at this report? https://bugs.launchpad.net/ubuntu/+source/app-install-data-ubuntu/+bug/368580
[16:21] <kees> mariuz: it shouldn't matter since __stack_chk_fail is defined by glibc.
[16:22] <jpds> jeki: Please don't message different channels with the same thing.
[16:22] <mariuz> ok i will close it then
[16:22] <kees> mariuz: since I am unfamiliar with firebird, can you adjust the bug report with specific steps to take to see the problem?
[16:22] <jpds> jeki: If you need general bug help, #ubuntu-bugs would be the place to start.
[16:23] <directhex> so... how do i ack a sync request then?
[16:23] <maco> directhex: upstream says "not gnote's bug if tomboy crashes" even though gnote's the one writing incompatible files
[16:24] <directhex> maco, okay. so it's official, gnote is not compatible with tomboy, is that what i'm to infer?
[16:24] <mariuz> kees: i will try to create one udf and then I will check if it works
[16:26] <directhex> maco, adding a try{}catch{} to tomboy to not crash is easy (but may impact performance). how much work should go into tomboy to work around idiotic flaws in an aggressive fork?
[16:26] <directhex> savvas, drop any mention of tomboy compatibility, by the looks of it
[16:28] <savvas> it just mentions it's a port of Tomboy in C++
[16:29] <maco> directhex: take a look at the bug http://bugzilla.gnome.org/show_bug.cgi?id=581844
[16:29] <directhex> maco, so i see. WONTFIX.
[16:29] <maco> i'm going to attempt to argue that interoperability = good
[16:29] <maco> and so at least be a *compatible* fork
[16:36] <maco> directhex: i dont think i like that guy's attitude
[16:36] <directhex> maco, don't get me started, i might upset someone
[16:37] <maco> heh
[16:37] <jdong> directhex: meh if someone gets upset then you are not the one with the problem ;-)
[16:38] <jdong> would it really kill them to output a compatible timestamp?
[16:38] <directhex> jdong, with great MOTU hat comes great responsibility
[16:38] <maco> being told "hey, you're breaking this already-well-established-format" and replying with essentially "too bad. i don't care"?  that's the part where you're supposed to go "oh? really? crud...uh....*hack*"
[16:38] <directhex> jdong, yes. doing that would enable people switching to tomboy
[16:38] <jdong> directhex: *gasp* the horror.
[16:38] <jdong> but mo*NO*!
[16:38]  * jdong dies a little inside
[16:40] <maco> heh i had a question on one of my finals that was "explain why service-oriented architectures should be based on standards" and i put down that from the customer/user who wants options' perspective they should be, but from the perspective of the provider who doesn't want to lose marketshare, standards are evil
[16:40] <jdong> exactly
[16:41] <directhex> standards prevent lock-in. that's the *point* of standards
[16:41] <directhex> you know, ECMA 335 is a standard.....
[16:42] <maco> i also put down "and sometimes a company will come along and realise that there are people who really really want standards and are willing to pay if you are committed to standards, and then they can market to that niche and hope that recommendations will give them popularity"
[16:42] <directhex> and fancy hats
[16:42] <savvas> well the author of gnote says in the readme file "as close as possible to the original"
[16:42] <maco> i'm thinking of things like how all us silly fossy people switched from twitter to identi.ca, where we can then export *all* our data as xml
[16:42] <savvas> no promise of compatibility :P
[16:43] <maco> well seeing as it's 100% possible for them to be exactly the same on timestamps...
[16:43] <maco> he's missing "as close as possible" by a bit
[16:43] <directhex> "as close to possible... in one direction"
[16:44] <savvas> perhaps he'll implement an import function heh
[16:44] <savvas> actually I don't know, I'm not arguing something I don't know :P
[16:44] <maco> also, the excuse that "well this is how glib did iso8601" doesn't stand up to the "how many available formats are there for iso8601? OH YEAH there's a localtime version!"
[16:45] <maco> (i wikipedia'd it. gnote's using iso8601 UTC and tomboy's using iso8601 local)
[16:47] <maco> and then the tomboy dev popped up and said he'd edit tomboy to be able to handle gnote's notes without crashing
[17:02] <pkern> lamothe: Sorry, looks like I missed it then.  I thought I synced everything you needed.  Yes, UI slowness, mainly.  I can retest on jaunty next week (that said, I don't want to make promises on that).
[17:29] <artfwo> hello! is anybody interested in reviewing http://revu.ubuntuwire.com/p/scantailor on this REVU day? thanks!
[17:30] <artfwo> (and sorry for spamming the channel, if that's not okay to do)
[17:35] <ivoks> RoAkSoAx: hello
[17:35] <RoAkSoAx> ivoks, heya :) how's it going?
[17:36] <ivoks> RoAkSoAx: good, and you?
[17:36] <RoAkSoAx> ivoks, tired but good...:)
[17:36] <ivoks> RoAkSoAx: now remove your patches from drbd merges :)
[17:37] <ivoks> so that main sponsors don't take yours, which aren't good :/
[17:37] <ivoks> RoAkSoAx: the main issue there is changelog
[17:38] <ivoks> RoAkSoAx: it's not your fault, but you should notice the problem
[17:38] <RoAkSoAx> ivoks, i've already pdated the drbd changelog btw...
[17:38] <ivoks> RoAkSoAx: take a look at http://launchpadlibrarian.net/26467890/drbd8_8.3.1-1ubuntu1.debdiff
[17:38] <RoAkSoAx> ivoks, so I should remove this patch: ubuntu-cn-idx.dpatch ??
[17:38] <ivoks> RoAkSoAx: that's the last debdiff there
[17:38] <RoAkSoAx> yes
[17:39] <ivoks> RoAkSoAx: in this debdiff everything is fine except debian/changelog changes
[17:39] <ivoks> RoAkSoAx: in this patch there are lots of changes (removal) on debian's changelog part
[17:39] <ivoks> RoAkSoAx: we can not remove debian entries in changelog
[17:40] <ivoks> RoAkSoAx: make that we should never remove something from changelog or add changes that we didn't do
[17:40] <ivoks> RoAkSoAx: so, while there was some errors in creating debdiff, they weren't your fault
[17:41] <ivoks> RoAkSoAx: but once you know that developer cannot remove entries from changelog, you will see that this debdiff does that - and then you would fix it
[17:41] <RoAkSoAx> ivoks, those entries where removed becuase mathiaz recommended so: could you remove all the changelog entries related to unstable that appear in the diff ( <0.6.12-5)? Only entries relevant to the ubuntu packages should be appear in the debdiff.
[17:41] <ivoks> i'm not sure if you understand me :)
[17:41] <ivoks> cause my english sucks at the momment
[17:42] <ivoks> RoAkSoAx: right, mathiaz said that only ubuntu related changes should be in debdiff
[17:42] <ivoks> RoAkSoAx: but this debdiff removes debian's changes :)
[17:42] <ivoks> RoAkSoAx: so, all changes in changelog, but only ubuntu related changes in debdiff
[17:43] <ivoks> bottom line; this wasn't your fault... it could be some mistake in previous merge (probably by me) or debian changed something in changelog
[17:43] <RoAkSoAx> ivoks, but i did what mathiaz said: Remove all unstable entries < 0.6.15-5
[17:43] <ivoks> RoAkSoAx: in *debdiff*
[17:43] <ivoks> RoAkSoAx: not in debian/changelog
[17:43] <mathiaz> RoAkSoAx: what I was saying was to remove the entries from the diff, not the changelog
[17:44] <mathiaz> RoAkSoAx: which means adding them back to the changelog
[17:44] <ivoks> RoAkSoAx: take a look at my patch
[17:44] <ivoks> http://launchpadlibrarian.net/26462721/drbd8_8.3.1-2ubuntun1.debdiff
[17:44] <mathiaz> RoAkSoAx: so that they don't appear in the debdiff
[17:44] <RoAkSoAx> mathiaz, ohhh know i get it .. lol
[17:44] <RoAkSoAx> dumb me
[17:44] <RoAkSoAx> ok will do
[17:44] <ivoks> don't be so hard on your self
[17:45] <ivoks> that's why you are here - to learn
[17:45] <ivoks> and we will help you
[17:45] <ivoks> RoAkSoAx: once i did merge, i got the same debdiff as you did
[17:46] <RoAkSoAx> haha yeah well i just misunderstood
[17:46] <ivoks> RoAkSoAx: but i manualy removed the changes we shouldn't introduce
[17:46] <ivoks> RoAkSoAx: as i said, this was a result from some error which wasn't caused by you
[17:47] <RoAkSoAx> ok :)
[17:47] <ivoks> i'd say you did a good job with merges
[17:48] <ivoks> i haven't seen others
[17:49] <RoAkSoAx> ivoks, thanks!! :) btw i am having trouble with paraview.. it won't build  and i don't know why :)
[17:49] <ivoks> RoAkSoAx: consider that one as one of FTBS you have to solve :)
[17:49] <ivoks> RoAkSoAx: how does it fail?
[17:49] <RoAkSoAx> ivoks, yes, I've suggested it as FTBS :) and just a sec
[17:50] <ivoks> RoAkSoAx: i've put qemu as FTBS you should also look at
[17:51] <RoAkSoAx> ivoks, ok. do you think we should start working with FTBS after the merges?
[17:51] <ivoks> RoAkSoAx: yes
[17:51] <ivoks> RoAkSoAx: during that cycle, you'll learn a bit about patching
[17:51] <ivoks> you already worked with dpatch
[17:52] <ivoks> RoAkSoAx: i'm looking at irssi merge request
[17:52] <ivoks> RoAkSoAx: did you do any changes to irssi or you just merged previous changes?
[17:52] <RoAkSoAx> ivoks, nxvl said it was ok :)
[17:53] <ivoks> RoAkSoAx: that's ok, but answer my question, please :)
[17:53] <RoAkSoAx> ivoks, i merged previous changes, but fixed the patch: 90irc-ubuntu-com
[17:53] <ivoks> ok
[17:54] <RoAkSoAx> since the previous patch wasn't working
[17:54] <RoAkSoAx> ivoks, btw.. I've worked with dpatch and quilt
[17:54] <ivoks> RoAkSoAx: have you contacted debian about drbd's control file and double 'dpatch' dependecy?
[17:54] <RoAkSoAx> ivoks, i've also worked with cdbs before
[17:55] <RoAkSoAx> ivoks, not yet :)
[17:55] <ivoks> great
[17:55] <RoAkSoAx> i was planning to do that this weekend
[17:56] <ivoks> ok
[17:56] <ivoks> i see ttx and mathiaz helped you with openvpn...
[17:58] <RoAkSoAx> ivoks, yes
[17:59] <RoAkSoAx> ttx last night said it was ok, so I suscribed it
[18:03] <RoAkSoAx> ivoks, i uploaded the new debdiff, is it ok?
[18:05] <ivoks> debdiff for...?
[18:05] <RoAkSoAx> ivoks, drbd
[18:06] <ivoks> you didn't have to, but let me check it
[18:06] <ivoks> lol, which one? :D
[18:07] <ivoks> RoAkSoAx: again...
[18:07] <RoAkSoAx> ivoks, hahaha what's wrong know?
[18:07] <ivoks>  drbd (0.7_pre10-1) unstable; urgency=low
[18:07] <ivoks> you are deleting some lines in debian's changelog entry
[18:08] <ivoks> don't add any debdiff anymore
[18:08] <ivoks> remove all yours and leave mine
[18:09] <RoAkSoAx> ivoks, i think that was done automatically
[18:10] <ivoks> RoAkSoAx: of course it was; as i said before, you should look at debdiff and notice errors like that
[18:10] <ivoks> RoAkSoAx: you should *never* change debian's changelog entries
[18:10] <RoAkSoAx> ok
[18:11] <RoAkSoAx> but yes. I don't know why, but that deletion of those two lines was done automatically i didn't even noticed
[18:13] <ivoks> well, you should always check debdiff and notice things like that
[18:13] <ivoks> otherwise, everything else was good
[18:14] <ivoks> RoAkSoAx: you've seen the comments i added on other bugs?
[18:14] <RoAkSoAx> ivoks, yes
[18:15] <ivoks> ok
[18:18] <RoAkSoAx> ivoks, btw.. I guess that you already fixed the things you've commented about in the other bugs
[18:19] <ivoks> RoAkSoAx: of course
[18:22] <RoAkSoAx> ivoks, ok awesome... btw.. did you get to write to the fedora guy regarding on ha?
[18:22] <ivoks> not yet
[18:30] <RoAkSoAx> ivoks, ok, when we have some time we should discuss the goals and roadmap for the time, so that you can also talk about it on the UDS
[18:33] <ivoks> yep
[18:37] <RoAkSoAx> RoAkSoAx, just let me know when can we talk about it :)... meanwhile I'm gonna work on another merge
[18:39] <RoAkSoAx> ivoks,  just let me know when can we talk about it :)... meanwhile I'm gonna work on another merge
[18:39] <ivoks> RoAkSoAx: it would be much easier with email
[18:40] <ivoks> since we aren't in the same parts of the world
[18:40] <ivoks> and now my brain isn't in optimum state :)
[18:41] <RoAkSoAx> ivoks, tell me... i just slept like 4 hours
[18:41] <RoAkSoAx> ivoks, and ok, i'll bring up the issue in the ubuntu-ha ML
[18:46] <RoAkSoAx> ivoks, what would be the difference between: libgstreamer0.10-ruby and libgstreamer0.10-ruby1.8
[18:47] <ivoks> libgstreamer0.10-ruby depends on libgstreamer0.10-ruby1.8
[18:49] <RoAkSoAx> ivoks, what would be the difference in using them in Build-Depends
[18:49] <ivoks> i really don't know
[18:49] <ivoks> a, i know
[18:50] <ivoks> 0.10-ruby is a dummy package
[18:50] <ivoks> it allways depends on latest libgstreamer0.10-rubyx.y
[18:50] <RoAkSoAx> ivoks, so we should not use dummy packages in BUild-Depends?
[18:50] <ivoks> i would use dummy package
[18:51] <ivoks> that way i wouldn't have to change debian/control when new version of packages comes out
[18:51] <RoAkSoAx> ivoks, yes, but why would someone would do that change, use libgstreamer0.10-ruby1.8 instead of libgstreamer0.10-ruby ?
[18:52] <ivoks> if package builds only with libgstreamer0.10-ruby1.8, but not with libgstreamer0.10-ruby1.7 or libgstreamer0.10-ruby1.9
[18:52] <RoAkSoAx> ivoks, on how do I determine that?
[18:53] <RoAkSoAx> ivoks, and it is not in Build-Depends, it is in Depends
[18:53] <ivoks> build it and test it, check changelog
[18:53] <ivoks> there should be some info about that in changelog
[18:54] <RoAkSoAx> ivoks, It just says this: debian/control{,.in}:   + Replace libgstreamer0.10-ruby with libgstreamer0.10-ruby1.8 in Depends for geekast-binary.
[18:55] <ivoks> RoAkSoAx: then you know it wasn't an accident or mistake
[18:55] <ivoks> RoAkSoAx: someone did it on purpose
[18:55] <ivoks> RoAkSoAx: don't change that
[18:56] <RoAkSoAx> ivoks, ok because debian added, a knew package that is a dummy package and i wanted to know if it could do the same kind of change, or just use the dummy one
[18:56] <ivoks> leave the change debian did
[18:58] <RoAkSoAx> ivoks, ok, now, when there's a debian/control.in and debian/control and both have conflicts in the same part, but debian/control also has conflicts in other part... we should resolve the conflicts in both files, but doesnt control.in overwrite control?
[18:58] <ivoks> RoAkSoAx: you should resolve all conflicts
[18:59] <RoAkSoAx> ok :)
[19:03] <ivoks> well, take care
[19:04] <RoAkSoAx> ivoks, you too thansk for the help :)
[19:04] <ivoks> np
[19:06] <directhex>    hnjml
[19:06] <directhex> =-u7y6r fewdaMNIL#]
[19:06] <directhex> *COUGH*
[19:15] <fabrice_sp> Hi. Anyone in a REVU mood willing to have a look at gmerlin (http://revu.ubuntuwire.com/p/gmerlin). It's for a merge from Debian Multimedia, and is a mandatory dependency for new openmovieeditor
[19:16] <fabrice_sp> it's linked to https://bugs.edge.launchpad.net/ubuntu/+bug/283208
[19:48] <pace_t_zulu> directhex: you here?
[19:49] <directhex> yes, but not for long
[19:49] <pace_t_zulu> directhex: congratulations on MOTU
[19:50] <directhex> thank you
[19:51] <pace_t_zulu> directhex: didn't want to trouble the list with that
[19:52] <directhex> pace_t_zulu, i had a few thanks via email, but didn't want to flood the list either
[19:52] <pace_t_zulu> directhex: maybe one day I can join you in MOTU
[19:54] <pace_t_zulu> directhex: i suppose i need to accumulate much more karma... perhaps on Karmic Koala
[19:54] <directhex> pace_t_zulu, it's not too hard - just contribute on something you enjoy, and don't suck at it for more than a few months. easy peasy!
[19:55] <pace_t_zulu> directhex: that's what i must do
[19:58] <directhex> back later. beer festival!
[19:59] <geser> you celebrating your MOTUship there?
[19:59] <pace_t_zulu> directhex: lucky you
[20:00] <kklimonda> directhex: gratz :)
[20:00] <kklimonda> directhex: so, does it mean that banshee will be default media player for KK? ;}
[20:01] <directhex> kklimonda, not my decision. entirely up to the desktop team at UDS
[20:02] <kklimonda> any MOTU would like to sponsor a sync: bug 373845 ?
[20:17] <pochu> kklimonda: I hope it doesn't ;-)
[20:18] <maco> any of you know your way around piuparts?
[20:24] <kklimonda> pochu: i guess that whatever the decission would be some people will complain :)
[20:27] <\sh> moins world :)
[20:35] <\sh> dear MOTUs and Hopefulls and all others, if anyone wants to do something, please take care of all packages my name tag is on....I won't have much time to work on them this time (much more important things to do ;)) things like zend-framework will uploaded in time for this release cycle....thanks :)
[20:47] <ScottK> \sh: Congratulations.
[20:49] <kklimonda> ScottK: what happens now with bug 367214 when it spent some time in -proposed and there was no negative feedback? Also the same fix was used by Debian Maintainer and upstream developers aren't responding to my mails.
[20:50] <ScottK> kklimonda: Someone other than you needs to verify it works.
[20:51] <ScottK> Once that happens the tag ccan get changed to verification-done and it'll get copied to -updates
[20:51] <ScottK> Also you need to get Karmic fixed too.
[20:51] <kklimonda> I've already filled sync request (bug 373845)
[20:53] <ScottK> Excellent.
[21:54] <Laibsch> hi, why is there no libarts1-dev package in jaunty anymore?  Debian still has it
[21:54] <directhex> yay beer
[21:54] <directhex> Laibsch, aRts is dead, no?
[21:55] <Laibsch> is it?
[21:55] <Laibsch> I don't know, I want it to recompile the latest twinkle
[21:55] <directhex> "On December 2, 2004 aRts' creator and primary developer Stefan Westerfeld announced he was leaving the project due to a variety of fundamental development and technical issues with aRts.
[21:55] <directhex> In KDE 4 developers choose to replace aRts with a new multimedia API known as Phonon"
[21:56] <Laibsch> OK
[21:56] <Laibsch> but debian seems to still make releases for the package
[21:56] <Laibsch> unstable has a more recent version than squeeze
[21:56] <Laibsch> and I don't see where else to get the mcopidl binary which is being called during compilation of twinkle
[21:58] <james_w> directhex: hey
[21:58] <james_w> I presume you can sponsor your own requests from the queue now
[21:59] <james_w> Laibsch: ubuntu decided to kill the package for jaunty, so you'll have to find some way around it, or get consensus to resurrect the package
[22:00] <directhex> james_w, i don't have an unsubscribe other button, so presumably i need to join u-u-s by hand?
[22:00] <Laibsch> I'll just recompile libarts1-dev in my PPA which is where I recompile twinkle as well
[22:00] <james_w> directhex: you need to ask one of the admins I think
[22:00] <Laibsch> I wonder what Ubuntu will do with the later releases of twinkle, though, which apparently need that binary
[22:00] <Laibsch> for compilation
[22:00] <james_w> directhex: if they are sync requests then just move them on to archive and leave the sponsors subscribed for now
[22:01] <james_w> Laibsch: prodding twinkle upstream about porting away from arts would be appreciated
[22:01] <Laney> don't drink and subscribe
[22:01] <james_w> Laney: my glass of wine disagrees
[22:02] <Laney> WON'T SOMEBODY THINK OF THE CHILDREN?!
[22:02] <Laibsch> :-(
[22:02] <Laibsch> Rejected: File arts_1.5.9.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors. Files specified in DSC are broken or missing, skipping package unpack verification.
[22:02] <Laibsch> Can't even upload it to my PPA
[22:03] <james_w> Laibsch: you can if you use the same tarball
[22:03] <james_w> you probably can't get that tarball by apt-get source unfortunately
[22:03] <Laibsch> I was using the Debian orig tarball
[22:04] <Laibsch> It is not good if the Debian orig tarball and the Ubuntu one differed
[22:04] <james_w> it happens unfortunately
[22:04] <Laibsch> upstream problem?
[22:04] <james_w> try with the Ubuntu one, and if it fails then it's probably a launchpad bug
[22:04] <Laibsch> I'm not even sure where to get it
[22:04] <Laibsch> I'll try a few usual suspects
[22:06] <kklimonda> Laibsch: https://edge.launchpad.net/ubuntu/+source/arts/1.5.9-0ubuntu1 ?
[22:35] <RainCT> Someone from MOTU SRU please approve bug #206280, thanks :)
[22:46] <Laney> motu-sru seems under strength
[22:46] <Laney> shouldn't it have 5 members?
[23:18] <binarymutant> I received and email from the archive team and it has an acronym I've never heard of. What is DIF? ie. "If it hasn't happened by DIF then we should act on it"
[23:19] <geser> Debian Import Freeze
[23:20] <iulian> binarymutant: Debian Import Freeze - https://wiki.ubuntu.com/DebianImportFreeze
[23:20] <binarymutant> iulian, ah thank you
[23:20] <savvas> you should add these in wtf :)
[23:21] <savvas> $ wtf DIF
[23:21] <savvas> Gee...  I don't know what DIF means...
[23:21] <james_w> binarymutant: ah, that was you :-)
[23:22] <james_w> that package will be imported semi-automatically until Debian Import Freeze, so asking for it to be done manually at this stage just creates more work
[23:22] <james_w> I left the bug open so that we can check later if the package got missed for some reason, and do it manually then
[23:22] <binarymutant> thanks james_w :)
[23:22] <directhex> james_w, my list o' syncs is moatly stuff i intend to update but haven't yet - but are currently unsyncable
[23:23] <directhex> james_w, so just write "ack", change to wishlist/confirmed, and subscribe archive admin?
[23:23] <james_w> directhex: I was referring to e.g. sublib, giver, moon
[23:23] <james_w> ah
[23:23] <james_w> yeah that works
[23:23] <james_w> I can ubsub sponsors for you until you are a member
[23:23] <directhex> who do i poke for that?
[23:23] <james_w> I'm not sure why ~ubuntu-dev isn't a member to be honest
[23:24] <james_w> Emmet added me I think
[23:24] <james_w> or Luke or Luca according to lp
[23:25] <directhex> DktrKranz?
[23:25] <james_w> yeah
[23:25] <james_w> ah, Luke's up
[23:25] <james_w> TheMuso: would you add directhex to ~u-u-s please?
[23:26] <TheMuso> sure
[23:27] <Laney> bah, sponsorship detection in requestsync is broken
[23:27] <Laney> james_w: can you unsub the archive from bug 373906?
[23:27] <TheMuso> james_w: the LP username is directhex?
[23:27] <james_w> directhex: I assume that's correct?
[23:27] <directhex> aye
[23:27] <TheMuso> thanks
[23:28] <directhex> ta!
[23:28] <TheMuso> done
[23:30] <savvas> any motu with some spare time, please review http://revu.ubuntuwire.com/p/gnote
[23:30] <directhex> yay, thanks TheMuso
[23:31] <TheMuso> directhex: np
[23:32] <savvas> goodnight!
[23:33] <savvas> or good-what-ever-time-you-have :P
[23:51] <james_w> Laney: why am I unsubscribing archive from f-spot?
[23:51] <james_w> I *wan't* f-spot to be synced :-)
[23:52] <Laney> it's in main
[23:52] <james_w> oh, yeah
[23:52] <james_w> silly me
[23:52] <james_w> nice work anyway
[23:53] <Laney> thanks
[23:53] <james_w> I presume you want to subscribe u-m-s?
[23:53] <Laney> just did!
[23:54] <james_w> I see it now :-)
[23:56] <binarymutant> If anyone has the time to review my package for lxsplit, I would greatly be appreciate it. It can be found here http://revu.ubuntuwire.com/p/lxsplit thanks you :)