[00:05] <SWAT> configure: creating ./config.status \ cd  && /bin/bash ./config.status Makefile \ /bin/bash: ./config.status: No such file or directory || It happens when I build a package. Any tips?
[02:15] <Stemp> Hi all
[02:15] <nxvl_work> hi folks!
[02:16] <Stemp> I have a problem with my pbuilder, it doesnt seem to recognize universe repo
[02:16] <nxvl_work> Stemp: you need to add it
[02:17] <Hobbsee> !pbuilder
[02:17] <ubotu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
[02:17] <Hobbsee> did you follow all the required steps in ^, particualrly the part about universe?
[02:17] <nxvl_work> ash pbuilder creates a clean system it only uses main and restricted repos
[02:18] <Stemp> I I have the COMPONENTS="main restricted universe multiverse" line in my ~/.pbuilderrc
[02:19] <nxvl_work> Stemp: did u update --override-config?
[02:20] <Stemp> yep
[02:20] <Stemp> s$ sudo pbuilder update --override-config
[02:20] <Hobbsee> remove /etc/pbuilderrc, i suspect.
[02:24] <Stemp> no :(
[02:24] <Stemp>    -> Trying libwebkitgtk-dev
[02:24] <Stemp>        -> Cannot install libwebkitgtk-dev; apt errors follow:
[02:24] <Stemp> Reading package lists... Done
[02:24] <Stemp> Building dependency tree
[02:24] <Stemp> Reading state information... Done
[02:24] <Stemp> E: Couldn't find package libwebkitgtk-dev
[02:24] <StevenK> Stemp: Run 'sudo pbuilder login' and 'cat /etc/apt/sources.list' in the shell pbuilder gives you
[02:25] <Stemp> ok
[02:25] <Hobbsee> remove it, and /etc/pbuilder/pbuilderrc, then run the --override-config again.
[02:25] <Stemp> ^^ gutsy !!
[02:26] <jdong> umm what repos have libwebkitgtk-dev?
[02:26] <StevenK> Then missing universe isn't your problem
[02:26] <StevenK> Hardy only
[02:26] <jdong> Hardy.
[02:26] <Stemp> universe jdong
[02:27] <jdong> yeah, like StevenK said
[02:27] <jdong> Stemp: is that a hardy pbuilder?
[02:27] <Stemp> yes jdong
[02:27] <StevenK> Stemp: Yes, universe for hardy. You need to change the DISTRIBUTION to hardy and update --override-config
[02:28] <StevenK> It so isn't, given what you said after I asked you to cat /etc/apt/sources.list
[02:28] <Stemp> humm you're right
[02:29] <Stemp> i made a mistake somewhere, it was an hardy pbuilder
[02:29] <Stemp> pbuilder update give me gutsy repo :(
[02:30] <StevenK> Stemp: pbuilder update ---distribution hardy --override-config
[02:30] <StevenK> Sprinkle sudo to taste
[02:30] <nxvl_work> or download the distribution-specific pbuilder scripts
[02:30] <nxvl_work> i use them and i fine, despide the fact that execute doesn't work fine
[02:31] <StevenK> Execute uses a script, not command line arguments
[02:32] <nxvl_work> oh!
[02:32] <nxvl_work> maybe thats the why, trying
[02:33] <Stemp> ok i'm so sorry, pbuilder was on gutsy.... sorry again :(
[02:33] <StevenK> Does it work now?
[02:34] <Stemp> It is downloading and updating packages
[02:34] <StevenK> Oh right, it's upgrading to hardy
[02:35] <Stemp> I'm sure I created pbuilder for hardy, I probably messed things up after that
[02:35] <jdong> StevenK: actually, duh, looking at Stemp's buildlog output it's using pbuilder-satisfydepends.pl
[02:35] <jdong> StevenK: which means it can't be Hardy :)
[02:35] <StevenK> jdong: Why not?
[02:35] <jdong> StevenK: hardy uses pbuilder-satisfydepends-dummy by default
[02:36] <jdong> which uses a fake package + aptitude
[02:36] <jdong> no Trying. ... type output
[02:36] <StevenK> I'm guessing the hardy pbuilder package does that, I suspect Stemp isn't running Hardy
[02:36] <Stemp> I'm running gutsy
[02:37] <jdong> err, it should be whatever pbuilder is inside the build env that does that
[02:37] <jdong> like I'm on a Gutsy host and my Hardy pbuilder environment does that
[02:37] <jdong> it did it so well I locally backported pbuilder from hardy to gutsy so that my gutsy pbuilders would instantly resolve deps too
[02:39] <nxvl_work> highvoltage: ping
[02:40] <Stemp> ok pbuilder worked thanks a lot
[02:41] <Stemp> I still have a thousands questions, but that's a big step
[02:46] <Stemp> I have an even more stupid question, do you think it's a good way for learning to try to package a new ubuntu package ? It already exist in Debian experimental. I tried to upload it on REVU but i'm not sure if I've done the things right
[02:50] <jdong> if it already is in debian experimental then it's already packaged, right?
[02:50] <Stemp> yes
[02:51] <Stemp> but.. there is a patch... changing the homepage from google.com to debian.org
[02:54] <jdong> I don't know what the preferred policy on that would be, but tossing it onto revu would not be a bad idea
[02:54] <Hobbsee> contributing the patch to debian would be a decent idea.
[02:55] <Hobbsee> although i'm not sure why debian.org is a homepage  for a particular package
[02:55] <Stemp> it's a browser
[02:55] <Stemp> midori
[03:00] <soothsayer> HOw do I translate a gitweb url to one I can pass to git-clone
[03:00] <soothsayer> ?
[03:05] <Hobbsee> soothsayer: #ubuntu?
[03:05] <soothsayer> Hobbsee: Seemed development-ish
[03:06] <Hobbsee> sure, but most of us dont use git
[03:06] <Hobbsee> and you also got no answer
[03:06] <jdong> soothsayer: my only guess is to add .git/ to the end of the base URL
[03:07] <jdong> soothsayer: if that doesn't work then find the real git:// repo URL
[03:07] <jdong> because branching git over HTTP is painfully slow too :(
[03:07] <Hobbsee> if it exists, #git would also be a good one
[03:09] <LordKow> if there is a conflicting package included in the dapper repositories but no longer included in the latest repos (hardy) can it safely be removed as a conflict/replacement in debian/control?
[03:09] <Hobbsee> LordKow: yes
[03:10] <LordKow> okay :) danke
[03:10] <Hobbsee> (and you can drop the change in hardy+1)
[03:13] <LordKow> bug 163701
[03:13] <ubotu> Launchpad bug 163701 in alps-light1 "[hardy] Please sync alps-light1 with debian 1.2.2-2.1" [Undecided,New] https://launchpad.net/bugs/163701
[03:14] <jdong> Hobbsee: wait a second is it safe to drop the Conflicts: in Hardy on a Dapper package?
[03:14] <jdong> Dapper->Hardy upgrades are going to be supported right?
[03:14] <Hobbsee> jdong: no.
[03:14] <Hobbsee> jdong: exactly
[03:14] <jdong> Hobbsee: ok good, just checking :)
[03:14] <Hobbsee> jdong: but you can drop in hardy+1, as we dont support dapper --> hardy+1
[03:15] <jdong> right
[03:15] <Hobbsee> and the hardy users will have the new package anyway.
[03:15] <Hobbsee> so their upgrade is fine
[03:15] <jdong> yep
[03:15]  * TheMuso hates libtool at times...
[03:15] <Hobbsee> (thank goodness we dont do more than two LTS releases at once)
[03:15] <LordKow> i dont see any problem with leaving in no-longer included packages in control (for conflicts/replaces, etc) but over time it will turn into a mess
[03:15] <Hobbsee> well, excluding server, anyway
[03:15] <StevenK> TheMuso: s/\(at\)/\1 all/
[03:16] <Hobbsee> LordKow: you only need it for upgrades
[03:16] <Stemp> bye all and thanks again
[03:16] <Hobbsee> LordKow: and people only dist-upgrade certain versions
[03:16] <StevenK> Hobbsee: We won't even have three LTSes even with server, I don't think.
[03:16] <Hobbsee> LordKow: so you only end up with a couple
[03:16] <Hobbsee> StevenK: no?  5 years, LTS released every 2?
[03:16] <TheMuso> StevenK: lol. The actual thing thats causing me grief is packages creating .la files that aren't recognising that libgcrypt.la is now in /usr/lib.
[03:16] <Hobbsee> dapper wills till be supported with hardy+4 coming out
[03:17] <StevenK> Hobbsee: Which means the 3rd is released in year 6?
[03:17] <Hobbsee> although we wont support dapper --> hardy+4, of course
[03:17] <Hobbsee> StevenK: unless i've got my maths wrong, that would be the *4*th released in year 6.
[03:17] <StevenK> Dh
[03:17] <LordKow> Hobbsee, yea exactly, but if the specific version of the package (say the one in the bug report) will never make it to the dapper repositories then they might as well be removed now (versus later)
[03:17] <StevenK> Doh, even
[03:17] <Hobbsee> you're missing the one released at year 0 :)
[03:17] <LordKow> and it allows ubuntu to sync the package with debian rather than merge :)
[03:18] <StevenK> Hobbsee: Yeah, okay, my maths is broken, not yours. :-)
[03:18] <TheMuso> StevenK: Is there any docs about why doing such things as what clean-la.mk in cdbs is important?
[03:18] <TheMuso> s/clean-la.mk/clean-la.mk does/
[03:18] <Hobbsee> LordKow: why would we want to remove it?
[03:19] <StevenK> TheMuso: A bunch of the distro team is convinced .la are broken. clean-la clears the dependancy line in them
[03:19] <TheMuso> StevenK: SO I see.
[03:19] <LordKow> the way i see it. if we dont remove ANY obsolete (no longer included) packages from the control file then it will fill up massively over time and become a giant mess
[03:20] <StevenK> TheMuso: This means that libtool won't put extra depends in when linking, causing us more work for transistions
[03:20] <Hobbsee> LordKow: are you talking about removing a package, or removing a line from debian/control?
[03:20] <Hobbsee> LordKow: indeed, which is why we dont do that.
[03:20] <LordKow> +Conflicts: libalps-light1c2a +Replaces: libalps-light1c2a
[03:20] <LordKow> for instance
[03:20] <Hobbsee> LordKow: we only preserve the upload path from LTS -->NextLTS, and version-->next version.
[03:20] <LordKow> those are in dapper but i do not think they are in any of ubuntu's repos since dapper
[03:20] <TheMuso> StevenK: Causing us more work for transitions when the dependcy-libs stuff is filled in, or when its cleared?
[03:20] <Hobbsee> so after that transition is done, we drop.
[03:21] <StevenK> TheMuso: When it's filled in
[03:21] <Hobbsee> LordKow: which bug?
[03:21] <TheMuso> StevenK: gotcha.
[03:21] <LordKow> Hobbsee, bug 163701
[03:21] <ubotu> Launchpad bug 163701 in alps-light1 "[hardy] Please sync alps-light1 with debian 1.2.2-2.1" [Undecided,New] https://launchpad.net/bugs/163701
[03:22] <LordKow> if we need to keep those conflicts/replacements then it will be a simple merge, otherwise it can be synced
[03:22] <LordKow> i guess the only problem i see is if someone does a dapper->hardy w/ those c2a packages installed. that would be problematic
[03:22]  * Hobbsee looks at it
[03:23] <Hobbsee> LordKow: you're right.
[03:24] <Hobbsee> LordKow: so you need to keep them for hardy, and then drop tehm for hardy+1
[03:24] <LordKow> oh by hardy+1 you mean 8.04.1?
[03:25] <Hobbsee> no, 8.10
[03:25] <LordKow> ahh
[03:25] <LordKow> yes, that makes sense
[03:25] <LordKow> we know for a fact that anyone upgrading from hardy to the next release will not have those c2a variants (unless they get re-added in the future for whatever reason)
[03:26] <Hobbsee> LordKow: correct.
[03:26]  * Hobbsee comments on the bug
[03:26] <LordKow> so the end result is I shall merge with debian by maintaining our conflicts/replacements.
[03:26] <Hobbsee> correct!
[03:27] <Hobbsee> LordKow: if you do that, add a patch, and poke me, and i'll sponsor it for you.
[03:27] <TheMuso> StevenK: Do you know if the clean-la.mk code is likely to be broken out into something else so that packages that don't use cdbs can make use of it more easily?
[03:27] <LordKow> okay i'll do this right now, shouldn't take long
[03:29] <Hobbsee> cool
[03:45] <griffinc> hi, can anyone answer a few questions on merge warnings?
[03:49] <griffinc> A Debian control file has 'Depends: ${shlibs:Depends}, ${misc:Depends}
[03:50] <griffinc> in the package section but pbuilder gives an 'unknown substitution' error on this.
[03:50] <griffinc> warning, actually, not an error
[03:51] <griffinc> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
[03:51] <griffinc> not sure what to do w/ that warning
[03:51] <ajmitch> that's generally ignored, as it's common to have packages created from dh-make with that in place
[03:52] <ajmitch> and many people don't remove it, perhaps in case they need it later
[03:52] <griffinc> ok, cool.  thanks ajmitch.  one or two more questions...
[03:54] <griffinc> In the debian source, the menu file uses section="Applications/Tools" but the gutsy menu file has section="Apps/Tools".  I read the Debian menu policy and I think they now use Applications instead of Apps.  Anyway, pbuilder does not like Applications.  :-)
[03:56]  * ajmitch isn't up to date on the latest policies
[03:56] <ajmitch> but at least the debian menu file isn't really much use :)
[03:57] <griffinc> true enough :-)
[03:57] <griffinc> ok just 1 more question
[03:59] <griffinc> pbuilder also gives me a warning about the user-defined field 'Original-Maintainer'.  I have in my control file XSBC-Original-Maintainer underneath Maintainer.  Ok to ignore this warning too?
[04:00] <ajmitch> yes
[04:00] <griffinc> I thought so, but wanted to make sure.  :-) thank you, ajmitch!
[04:02] <RAOF> Oh, dear.  Look at bug #163707
[04:02] <ubotu> Launchpad bug 163707 in gstreamer0.10-ffmpeg "gstreamer0.10-ffmpeg should link with system ffmpeg libraries (libavcodec, etc)" [Undecided,New] https://launchpad.net/bugs/163707
[04:03] <jdong> RAOF: I thought we had a reason to do that, namely the API of ffmpeg is unpredictably shifting
[04:03] <jdong> anyway I'm curious, I'll take a close look
[04:05] <RAOF> jdong: Yes, indeed.
[04:06] <RAOF> But it seems that the Debian security team are sick of having a multitude of statically linked copies of different versions of ffmpeg in a half a dozen packages in the archives.
[04:06] <RAOF> And who can blame them.
[04:07]  * RAOF gets back to marking before he starts this week's "rag on ffmpeg developers" session.
[04:07] <jdong> RAOF: targetted against gstreamer-ffmpeg 0.10.3 upstream...
[04:07] <jdong> I don't see if that release even exists
[04:07] <jdong> nonetheless, let's apply that patch for laughs
[04:09] <RAOF> You won't see me touching that with a 10" pole.  I predict huge, ungainly patches for the universe multimedia stuff to build them against !$THEIR_FFMPEG_VERSION.
[04:09] <jdong> RAOF: I tend to be the guy who plays with stuff like that ;-)
[04:10] <RAOF> Just as long as you don't play with any packages I have to touch :P
[04:10]  * ajmitch puts in a -1
[04:11] <RAOF> Only -1?
[04:11] <ajmitch> any more would be mean
[04:11] <LaserJock> oh, nice
[04:12] <LaserJock> my laptop is running way better
[04:12] <LaserJock> and so quiet
[04:12] <ajmitch> good
[04:12] <ajmitch> what did you do to it?
[04:12] <LaserJock> took the fan off
[04:12] <RAOF> Heh
[04:12] <LaserJock> put new thermal paste on
[04:12] <LaserJock> and cleaned out the fan and cooling fins
[04:13] <LaserJock> doesn't sound like an airplane
[04:13] <LaserJock> and is running about 20C cooler
[04:13] <ajmitch> not bad
[04:13] <LaserJock> took me over an hour to get it back together though
[04:14]  * jdong puts on evil "let's see if it compiles" grin
[04:15]  * pwnguin wishes there were a smarter Tee
[04:15] <ajmitch> jdong: if it compiles, upload it?
[04:15] <jdong> ajmitch: haha, no :)
[04:16]  * pwnguin finds multitee
[04:16] <jdong> I've got marginally better sense of paranoia than that :)
[04:16] <ajmitch> if it doesn't compile, upload it? :)
[04:16] <jdong> ajmitch: well that couldn't do any harm ;-)
[04:16] <jdong> :D
[04:16]  * ajmitch cuts & paste quote for MC list
[04:17] <jdong> haha
[04:18] <LordKow> does ubuntu's packages need to be lintian clean?
[04:19] <LaserJock> it's nice
[04:19] <LaserJock> but most of the time we won't reject it out of hand
[04:19] <LaserJock> it depends on the warning/error
[04:19] <LordKow> what about in regards to simply updating/merging packages?
[04:22] <LaserJock> oh, usually that's fine
[04:22] <LaserJock> as  long as you aren't creating new lintain output :-)
[04:22] <RAOF> Don't feel bad about fixing lintian/linda errors while merging, though :)
[04:22] <LordKow> why would i do that?
[04:22] <RAOF> Particularly if you then send that back up to Debian.
[04:22] <LaserJock> LordKow: if you mess something up and it creates a lintian error
[04:23] <LordKow> LaserJock, yes then i should fix that.
[04:23] <LaserJock> LordKow: the key to merging is to keep the changes as few as possible
[04:23] <LordKow> but its not the case here
[04:23] <LordKow> ah well then im doing pretty good. 1 change required for dapper->hardy
[04:25] <jdong> *grumble* stupid autoreconf
[04:26] <LaserJock> lol, my father-in-law just emailed that he saw an article on Linux in Popular Science and it mentioned something about Ubuntu 6.06 and wondered if he should get it
[04:27] <jdong> :)
[04:28] <RAOF> The only thing worse than autotools seems to be almost every other build system. :)
[04:29] <StevenK> RAOF: cmake looks to be sensible
[04:29] <jdong> RAOF: I just don't want 34,000 line debdiffs from forgeting to remove the cache
[04:29] <LaserJock> StevenK: cmake has some cool stuff but I recently ran into a big limitation
[04:29] <LaserJock> StevenK: I wanted to make a convenience library for a package and cmake doesn't support that
[04:30] <RAOF> jdong: I'm sure you could write a strip-autofoo.mk for cdbs :)
[04:30] <LaserJock> but it sure looks nice and I love the build progress output
[04:30] <jdong> RAOF: :)
[04:30] <RAOF> LaserJock: That seems like a pretty big limitation!
[04:30] <jdong> RAOF: well wrestling with system ffmpeg first, automake uncrufter later ;-)
[04:30] <RAOF> Surely they have some way of doing that?
[04:30] <jdong> checking for FFMPEG... yes
[04:30] <jdong> checking for POSTPROC... yes
[04:30] <LaserJock> not within cmake itself
[04:30] <jdong> whoo
[04:31] <LaserJock> RAOF: it's in there FAQ
[04:31] <LaserJock> *their
[04:31] <jdong> /usr/include/ffmpeg/avformat.h:282: warning: 'AVFrac' is deprecated
[04:31] <jdong> pffft
[04:31] <RAOF> LaserJock: As I can well imagine.  What's their answer?  (Or just link to the faq)
[04:32] <RAOF> jdong: Be thankful they haven't removed AVFrac yet :P
[04:32] <LaserJock> RAOF: http://www.cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F
[04:33] <jdong> RAOF: urgh quite a number of API chagnes chasing after
[04:33] <jdong> RAOF: this reminds me of my morning with avidemux
[04:34] <RAOF> LaserJock: Oh, and the FAQ answer immediately below seems awkward from a packaging point of view, too :(
[04:34]  * RAOF told jdong so :P
[04:35] <Yagisan> LaserJock, I find cmake works rather well - I have used and abused it quite at lot - doesn't support some evil windows linking tricks though
[04:37] <jdong> RAOF: meh I figure I'll give it a few hours of patience to vindicate myself from an "it's a  lot of work" copout :)
[04:37] <LaserJock> RAOF: yeah, some good things and bad things I guess
[04:38] <jdong> besides, I'm only on my 11th round of FTBFS
[04:38] <RAOF> jdong: What are you patching gst-ffmpeg each time?
[04:40] <jdong> RAOF: yeah, I'm pushing up to a compile error, adjusting my ffmpeg-api-migration patch, then rinse and repeat
[04:40] <jdong> RAOF: I don't exactly have a comprehensive list of ffmpeg API changes since whenever this ffmpeg was packaged
[04:41]  * RAOF wonders if such a list even exists.
[04:41] <jdong> RAOF: their svn changelog... :-/
[04:41] <RAOF> Assuming they document each API change in the changelog :P
[04:42] <RAOF> They probably do, they're not actively evil.  Just annoyingly misguided.
[04:42] <jdong> RAOF: they do, but IMO their API changes are often for extremely frivolous reasons
[04:42] <jdong> and are extremely frustrating to keep track of
[04:43] <jdong> I wish they'd stabilize an API
[04:43] <RAOF> And wouldn't be so bad if they actually *released*.  Ever.
[04:43] <jdong> well I've got it to the point where it makes it 15 seconds into a compile now
[04:43] <jdong> so I'm making progress
[04:43] <jdong> so far the patches have been quite trivial
[04:43] <jdong> just tedious
[04:43] <StevenK> jdong: 15 seconds? What's that, one .cpp file?
[04:44] <jdong> StevenK: core 2 duo 2.16, like haflway thru
[04:44] <RAOF> StevenK: As long as there aren't too many templates in there :P
[04:44] <StevenK> Haha
[04:44] <jdong> OH DEAR LORD
[04:44] <jdong> DEAR EFFING LOARD
[04:44] <jdong> IT BUILT!!!!!11111
[04:44]  * jdong proceeds to look at outputted deb
[04:44] <StevenK> Don't sound so shocked :-P
[04:44] <RAOF> Which means it obviously works :P
[04:44] <jdong> RAOF: lol testing that next
[04:45] <jdong> Version: 0.10.2-4ubuntu2~7.10prevu1
[04:45] <jdong> Depends: libavcodec1d (>= 0.cvs20070307), libavformat1d (>= 0.cvs20070307), libavutil1d (>= 0.cvs20070307),
[04:45] <jdong> ^^ good sign #1 :)
[04:45] <RAOF> jdong: Surely not.  C is statically typed!  That means you don't have to test it - the compiler guarantees it's correct :P
[04:45] <jdong> RAOF: haha
[04:45] <jdong> RAOF: and plus it's written with the goodness of GNOME
[04:46] <jdong> any genius ideas how to test gstreamer-ffmpeg, other than playing some DivX in totem?
[04:46] <jdong> HOLY CRAP IT PLAYS
[04:47] <jdong> even H.264 works
[04:47] <Hobbsee> see, this is why we dont want jdong as a MOTU :P
[04:47] <Hobbsee> however, i wonder if blender works.
[04:47] <jdong> who's yo daddy?
[04:47] <jdong> *ducks*
[04:48] <Hobbsee> he's gone to NZ :P
[04:50] <jdong>  5 files changed, 16690 insertions(+), 1 deletion(-)
[04:50] <jdong> stupid autoreconf cruft.... deal with that later
[04:51] <LaserJock> Hobbsee: lol
[04:54] <crimsun> jdong: filterdiff(1)
[04:54]  * StevenK kicks autotools
[04:54] <StevenK> Don't tell me pkg-config doesn't exist, it does, you're just not looking at all!
[04:57] <jdong> can someone provide advice to https://bugs.edge.launchpad.net/ubuntu/+source/gstreamer0.10-ffmpeg/+bug/163707
[04:57] <ubotu> Launchpad bug 163707 in gstreamer0.10-ffmpeg "gstreamer0.10-ffmpeg should link with system ffmpeg libraries (libavcodec, etc)" [Undecided,New]
[04:57] <jdong> the last comment
[04:57] <LordKow> Hobbsee, 2 debdiffs for bug 163701
[04:57] <ubotu> Launchpad bug 163701 in alps-light1 "[hardy] Please merge alps-light1 1.2.2-2.1 (universe) from Debian unstable (science)" [Undecided,Confirmed] https://launchpad.net/bugs/163701
[04:59] <crimsun> ah, ffmpeg madness.
[05:01] <RAOF> Indeed.
[05:01] <RAOF> jdong: Actually, you might want to ask slomo about this - he's one of the Debian maintainers, AFAIK
[05:02] <jdong> RAOF: yeah I have a number of things to ask slomo, just need to pounce on him the next time he signs on
[05:02] <RAOF> :)
[05:04] <jdong> but so far I think it looks promising as to the original bug -- I'd rather spend a bit of effort to build against system ffmpeg than use some old bundled one
[05:04] <RAOF> jdong: As far as versioning goes, you should probably be able to get away with not too strict versioning - it's libavcodec0d's responsibility to be ABI compatible, really.
[05:04] <jdong> I've been wondering why gstreamer plays various media formats poorer than VLC, and this is definitely a contributing factor
[05:05] <jdong> RAOF: yeah I think unversioned is fine for now, it'll definitely build on Hardy, but it'll probably FTBFS on, say, a feisty attempted backport during compile phase, and probably do the same sometime in the future when we update ffmpeg again
[05:05] <jdong> RAOF: I was just wondering if it was unholy for packages to do that
[05:05] <jdong> i.e. passing a build-dep but failling to build due to API change
[05:06] <RAOF> Oh, the *build* depend will undoubtedly require stricter versioning.
[05:06] <jdong> RAOF: any suggestions on how on earth to figure out what the valid range would be? :D
[05:06] <RAOF> Since they break API more frequently than ABI.
[05:07] <RAOF> jdong: I'd be tempted to do >= $CURRENT, << $CURRENT+1
[05:07] <jdong> RAOF: with +1 being one day's increment on the svn snapshot date?
[05:07] <RAOF> Ah, that's how it's versioned?  Yeah.
[05:07] <crimsun> jdong: vlc does the same thing that gstreamer0.10-ffmpeg does.
[05:08] <RAOF> (Of course that's how it's versioned.  FFmpeg don't release!)
[05:08] <jdong> crimsun: it has a newer snapshot doesn't it?
[05:08] <RAOF> As does *anything* using ffmpeg!
[05:08] <crimsun> jdong: it used to
[05:08] <jdong> RAOF: mplayer seems to use system ffmpeg currently
[05:08] <crimsun> it was cleaned up
[05:09] <RAOF> jdong: Only because Debian patched that in.
[05:09] <jdong> RAOF: ah
[05:09] <RAOF> See point "Debian security team" :)
[05:09] <crimsun> hardy's mplayer doesn't b-d on system ffmpeg; vlc does.  Interesting.
[05:10] <saivann> Hi everyone, I'm working on the bug 77080 which require gnucash to recommend "gnucash-docs". I've made a debdiff to fix this issue in hardy but I would need someone to approve and upload
[05:10] <ubotu> Launchpad bug 77080 in gnucash "Gnucash-docs isn't installed with gnucash" [Wishlist,Confirmed] https://launchpad.net/bugs/77080
[05:10] <pwnguin> jdong: if you're looking for more test cases, ive got a ton ;)
[05:11] <crimsun> saivann: have you attached said debdiff?
[05:12] <jdong> RAOF: do you think >=$CURRENT_SNAP_DATE would be strict enough? Predicting the other bound of the date is like voodoo, isn't it? :)
[05:12] <saivann> crimsun : I do it right now
[05:12] <saivann> crimsun : The debdiff is now attached
[05:13] <pwnguin> jdong: if you've got a few .mkv's handy that'd also make a good test case ^_^
[05:13] <jdong> pwnguin: I probably do, and I can probably just shove a few things into mkv's
[05:13] <jdong> pwnguin: but you're of course more than welcome to test too ;-)
[05:13] <pwnguin> jdong: repo handy?
[05:14] <RAOF> jdong: Yes, it is voodoo.  I'm not sure which is worse, FTBFS because of API changes, or FTBFS because of unnecessarily strict b-d's.
[05:14] <StevenK> Oh, you stupid configure test
[05:14] <jdong> pwnguin: gutsy or hardy?
[05:14] <RAOF> It's a non-stop autotools hate fest!
[05:14] <pwnguin> gutsy
[05:14] <jdong> pwnguin: one sec :)
[05:15] <jdong> pwnguin: http://jdong.mit.edu/~jdong/motu/gstreamer0.10-ffmpeg_0.10.2-4ubuntu2~7.10prevu1_i386.deb
[05:15] <StevenK> RAOF: Right on
[05:16] <pwnguin> jdong: excellent. the other question is, what all does ffmpeg handle?
[05:17] <pwnguin> isn't h264 its own lib?
[05:17] <jdong> pwnguin: no, ffmpeg decodes h264 itself
[05:17] <jdong> pwnguin: x264 provides an encoder but only an experimental decoder that's not used
[05:17] <RAOF> pwnguin: gst-inspect | grep ff
[05:18] <pwnguin> excellent
[05:18] <jdong> pwnguin: I'm pretty sure almost all video formats you throw at totem-gstreamer are gonna be handled by ffmpeg
[05:18] <pwnguin> flv
[05:18] <jdong> definitely ffmpeg
[05:18] <pwnguin> mp4
[05:18] <jdong> I've already verified mp4 containers
[05:19] <RAOF> A mere 230 different elements to test :P
[05:19] <pwnguin> ive got this unreproduceable bug regarding mp4
[05:19] <pwnguin> about half of the mp4s i download from google and play later don't work
[05:19] <pwnguin> "no playable streams"
[05:19] <jdong> pwnguin: are you sure they are not DRM'ed mp4's?
[05:20] <pwnguin> everyone else claims they work =(
[05:20] <pwnguin> reasonably
[05:20] <jdong> my media collection is almost completely in MPEG4 containers
[05:20] <jdong> and apart from gst-ffmpeg's distortion/corruption on some H.264's, no major problems
[05:21] <pwnguin> qtdemux.c(1444): gst_qtdemux_loop (): /play/decodebin0/qtdemux0:
[05:21] <pwnguin> no known streams found
[05:22] <jdong> pwnguin: umm....
[05:22] <jdong> pwnguin: is that a real mp4 container or is that mov?
[05:22] <pwnguin> i have no idea =
[05:23] <jdong> pwnguin: output of file on it?
[05:23] <jdong> also output of ffmpeg -i on it
[05:25] <pwnguin> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '473b133e31b77e47.avi.mp4': Duration: N/A, bitrate: N/A
[05:25] <jdong> pwnguin: err.... where *are* the streams?
[05:26] <jdong> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Family Guy - 1x01 - Death Has A Shadow.m4v.m4v': Duration: 00:22:32.2, start: 0.000000, bitrate: 598 kb/s Stream #0.0(und): Video: h264, yuv420p, 640x480, 23.98 fps(r) Stream #0.1(und): Audio: aac, 48000 Hz, stereo
[05:26] <jdong> that's what it's supposed to look like
[05:27] <jdong> you should at least have an audio and video stream in there
[05:27] <jdong> :-/ if ffmpeg can't parse the MP4 then I don't know what the problem is
[05:27] <saivann> crimsun : did you look at the debdiff?
[05:27] <pwnguin> well, at 112Mb there should be some streams in it
[05:27] <crimsun> saivann: I'm checking out from bzr
[05:27] <saivann> crimsun : Thanks
[05:28] <Hobbsee> LordKow: http://launchpadlibrarian.net/10464329/prev_ubuntu-new_ubuntu.debdiff is wrong.
[05:28] <Hobbsee> LordKow: it doesnt have the debian change in it
[05:28] <jdong> pwnguin: can mplayer parse it?
[05:29] <crimsun> saivann: I've modified your debdiff
[05:30] <pwnguin> "cannot find codec for audio format 0x56444152"
[05:30] <pwnguin> then it plays a bunch of random data on the video
[05:30] <saivann> crimsun : You changed the uploader and the description?
[05:30] <pwnguin> maybe i should disable medibuntu =/
[05:31] <jdong> pwnguin: 0x56444152 is raw DV
[05:31] <jdong> pwnguin: which can't be right for a mp4... can it?
[05:32] <pwnguin> im gonna redownload this and make sure the file isnt corrupt
[05:32] <LordKow> Hobbsee, which debian change?
[05:32] <Hobbsee> LordKow: the one listed in the changelog
[05:32] <Hobbsee> oh, hang on.
[05:32] <RAOF> jdong: You can stick any sort of codec into any sort of container if you try hard enough :P.  Doesn't mean it'll play, though.
[05:32] <LordKow> the rc bug fix?
[05:33] <jdong> RAOF: true, but I wouldn't expect to find one of those in the wild!
[05:33] <Hobbsee> LordKow: forgot it was already in ubuntu :)
[05:33] <pwnguin> jdong: the file's already named something wierd like <random hash>.avi.mp4
[05:33] <jdong> pwnguin: I'm pretty sure the file that you have is corrupt, DRM'ed, or otherwise tainted
[05:33] <pwnguin> that seems unlikely that they'd drm a tech talk
[05:33] <Hobbsee> LordKow: uploaded, thanks
[05:33] <pwnguin> esp when other people claim it works for em.
[05:34] <jdong> pwnguin: then probably download related problem :)
[05:34] <LordKow> np
[05:34] <pwnguin> bug #156826
[05:34] <ubotu> Launchpad bug 156826 in gstreamer "some mp4s fail to play" [Undecided,New] https://launchpad.net/bugs/156826
[05:35] <jdong> pwnguin: lemme take a look
[05:35] <RAOF> pwnguin: You could possibly try gst-launching it through ffdemux_mov_mp4
[05:35] <pwnguin> jdong: judging by the filesize, im thinking incopmplete downloads =(
[05:35] <jdong> pwnguin: an incomplete mp4 will show up like that
[05:35] <RAOF> pwnguin: (There's a whole bunch of extra stuff on the end of that element name, incidentally)
[05:35] <pwnguin> ?
[05:36] <jdong> pwnguin: i.e. a truncated mp4 will show up as having no streams
[05:36] <crimsun> way to leave me wringing my hands, bzr.
[05:36] <LaserJock> hmm, the ubuntu.com download page doesn't  link to any documentation on burning an .iso :/
[05:36]  * crimsun hopes this bzr push is actually doing something, as there's no indication of progress
[05:37] <jdong> pwnguin: I'm 90% through, lemme see how it turns out
[05:37] <jdong> internet's slow tonight
[05:37] <LaserJock> crimsun: yeah, showing progress is not one of bzr's strong suites
[05:37] <jdong> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '473b133e31b77e47.avi.mp4': Duration: 01:01:21.5, start: 0.000000, bitrate: 445 kb/s Stream #0.0(und): Video: h264, yuv420p, 320x240, 29.97 fps(r) Stream #0.1(und): Audio: aac, 44100 Hz, stereo
[05:37] <jdong> pwnguin: ^^
[05:37] <crimsun> hah.
[05:38] <jdong> pwnguin: 4578ac613eaf177012a396453910b8a8  473b133e31b77e47.avi.mp4
[05:38] <crimsun> well, good thing I forgot to use bazaar.lp instead of code.lp
[05:38] <pwnguin> jdong: cool. im almost done grabbing it myself, and its much larger than last time =(
[05:38] <RAOF> crimsun: Timeout error?
[05:38] <crimsun> code.launchpad.net has address 91.189.90.244
[05:38] <crimsun> bazaar.launchpad.net has address 91.189.94.254
[05:38] <pwnguin> good signs, nautilus preview shows things
[05:38] <RAOF> crimsun: Complete with huge uncaught backtrace?
[05:38] <crimsun> I forgot that one can't push via sftp to code.lp
[05:39] <jdong> RAOF: bzr+ssh:// is the infamous one for frightening errors for simple problems
[05:39] <crimsun> RAOF: nah, "just a two-liner"
[05:39] <jdong> I got a page-long traceback for when shared repo was locked.
[05:40] <crimsun> saivann: http://codebrowse.launchpad.net/~ubuntu-dev/gnucash/ubuntu/revision/crimsun%40ubuntu.com-20071119053212-hqog7l26mbmilcnc?start_revid=crimsun%40ubuntu.com-20071119053212-hqog7l26mbmilcnc
[05:40] <crimsun> mm tasty URL
[05:41] <jdong> indeed
[05:41] <jdong> why is the same revision ID in the URL twice, loggerhead? :)
[05:41] <saivann> crimsun : I don't know a lot about package uploading into ubuntu repositories, but since my debdiff only changes a value in debian/control, is it alright to use bazaar?
[05:41] <crimsun> saivann: it's preferable to maintain the source packaging in bzr
[05:42] <saivann> crimsun : Ok right, thanks for your help on this. Should I do something else or everything is finished?
[05:43] <pwnguin> jdong: well, thanks for the attention. sorry i wasnt smarter at debugging it on my own
[05:44] <pwnguin> jdong: as far as the new ffmpeg, what should i be looking at? working? working better?
[05:44] <jdong> pwnguin: hehe, no problem, I've been guilty of that far more times
[05:44] <jdong> pwnguin: first, just flat out working
[05:44] <jdong> pwnguin: I'd also expect CPU usage while playing high-res H.264 to be significiantly lower
[05:44] <pwnguin> not so much
[05:44] <jdong> pwnguin: but right now I am mostly concerned about just no regressions as far as functionality
[05:44] <pwnguin> darker than black def still runs like crap
[05:45] <pwnguin> does gst-ffmpeg have priority on codec picking?
[05:45] <jdong> pwnguin: I have no idea how gstreamer works... :(
[05:45] <pwnguin> excellent :)
[05:46] <jdong> pwnguin: I have a "if it is currently working, don't ask it questions or it'll anger the ffmpeg gods and stop working" mentality towrads the media stack
[05:46] <crimsun> saivann: https://lists.ubuntu.com/archives/hardy-changes/2007-November/001751.html
[05:46] <jdong> pwnguin: it has kept me alive so far
[05:46] <crimsun> saivann: thanks!
[05:47] <saivann> crimsun : Ha! Thank you very much for your help :)
[05:47] <crimsun> np :)
[05:47] <pwnguin> heh. im working on fixing liferea's mime type stuff myself. it will handle torrent subscriptions, or I'll die trying
[05:48] <crimsun> saivann: to note, the syntax is defined at https://wiki.ubuntu.com/ClosingBugsFromChangelog
[05:48] <superm1> jdong, you still messing around with x264 stuff tonight?
[05:48] <jdong> superm1: I've uploaded all that is needed to be done into the ~motumedia PPA
[05:49] <jdong> superm1: I just mangled gstreamer0.10-ffmpeg to use system ffmpeg and I think I'm gonna take a vacation from the media stack for a bit :D
[05:49] <superm1> jdong, well i was just going to ask what role the x264 package plays with all these other ones
[05:49] <superm1> i had thought that ffmpeg itself had some h264 handling already, and wasn't entirely sure what x264 was for then
[05:50] <saivann> crimsun : Oh thanks, this type of information is always welcome :)
[05:50] <jdong> superm1: x264 provides H.264 encoding services to mplayer (mencoder), avidemux, ffmpeg, and a few others
[05:50] <superm1> oh encoding :)
[05:50] <jdong> superm1: ffmpeg provides all H.264 *de*coding services to our media stack
[05:51] <jdong> superm1: x264 has made a lot of progress since our last import to faster threading, faster encoding, and better quality output while threading since our last snapshot
[05:51] <superm1> that explains it then, neat
[05:51] <jdong> superm1: and since it's a very slow encoder to begin with any help is greatly appreciated :D
[05:51] <superm1> at this point does it take advantage of multiple cores then?
[05:51] <saivann> crimsun : I just want to make sure of one thing, this package has been uploaded to Hardy but not Gutsy, right?
[05:52] <pwnguin> yea, mkvs are still unwatchable in totem =(
[05:52] <jdong> superm1: yes, threading slices your video into $thread strips and encodes them independently
[05:52] <pwnguin> donno if its the mkv or the high definition though
[05:52] <jdong> superm1: since our snapshot they've improved on threading performance and sharing basic data with other threads to reduce noise on output
[05:52] <superm1> jdong, yeah that's what i was assuming would have needed to be done
[05:53] <jdong> superm1: not to mention retuned a bunch of calculation routines to be faster when using aggressive quality options
[05:53] <jdong> superm1: so far it *seems* like they managed not to break any API's so we just need a rebuild
[05:53] <superm1> hehe
[05:53] <jdong> superm1: except avidemux which is in such a horribly abandoned state :-/
[05:54] <superm1> jdong, that's really unfortunate to hear
[05:54] <superm1> jdong, that was about the only GUI i knew about for encoding itmes
[05:54] <superm1> items
[05:54] <superm1> er GUI wrapper that is
[05:54] <jdong> superm1: indeed it is. We need to get a new upstream release in, our current one can't be mangled for much longer
[05:54] <jdong> superm1: there is a LP bug open and a REVU package sitting there of a new upstream version though
[05:55] <jdong> bug #163287
[05:55] <ubotu> Launchpad bug 163287 in avidemux "avidemux 2.4 preview 3 (RC1)" [Undecided,In progress] https://launchpad.net/bugs/163287
[05:55] <crimsun> well, since we have the somewhat-dubious precedent of windows binaries in multiverse, one could punch some windows encoder
[05:55]  * crimsun ducks
[05:55] <jdong> superm1: I don't know the origin of his packaging but it looks like he chose to start from scratch rather than basing on marillat
[05:55] <jdong> *shrugs*
[05:56] <superm1> or even get say virtualdub into multiverse........
[05:56] <jdong> superm1: how about we first get an ffmpeg that actually *encodes* into Ubuntu :-/
[05:56] <superm1> jdong, well its good to see the effort has at least been started on avidemux this early
[05:56] <superm1> jdong, so its not a UVF time second though
[05:56] <jdong> right now we need to run over to medibuntu to have any chance of encoding stuff
[05:56] <superm1> thought
[05:56] <pwnguin> what windows binary got into multiverse?
[05:56] <jdong> superm1: right, I'm happy to see his progress
[05:57] <jdong> superm1: so I'm gonna ignore the x264 FTBFS with avidemux in hardy for now pending his work.
[05:57] <jdong> a new version will solve everything
[05:57] <jdong> no point in mangling a 2-year-old package for hours just to have it replaced in a few weeks
[05:57] <superm1> yeah good point
[05:58] <jdong> superm1: I'd love our LTS to go out with a fresh multimedia stack... currently I'm looking at how well ffmpeg builds against the new x264
[05:59] <jdong> superm1: though we don't build it that way ourselves, medibuntu does and I'd like to do them the courtesy of dealing with any API migrations so we don't have delayed ffmpeg unlocked packages in Hardy :)
[05:59] <superm1> jdong, what does medibuntu build differently about ffmpeg?
[06:00] <jdong> superm1: a bunch more --enable-foo flags
[06:00] <jdong> superm1: namely all the encoders that we're too chicken to ship
[06:00] <superm1> jdong, i've always wondered why we can't enable more of that foo and put it in multiverse
[06:00] <superm1> directly
[06:00] <jdong> which is basically all the encoders
[06:00] <jdong> superm1: I think the reason is that we want to promote ffmpeg to main
[06:00] <superm1> or maybe instead have more binaries churned out the ffmpeg source package
[06:00] <pwnguin> superm1: patents?
[06:00] <jdong> and encoders would send us into multiverse
[06:00] <superm1> and some end up in multiverse
[06:00] <superm1> pwnguin, there is lame in multiverse
[06:00] <superm1> pwnguin, and all apps linking against it
[06:01] <jdong> pwnguin: patents aren't the issues....
[06:01] <pwnguin> ok then
[06:01] <jdong> pwnguin: all the stuff we are linking ffmpeg to is already in multiverse
[06:01] <jdong> pwnguin: the problem is there's an agenda to promote ffmpeg to main
[06:01] <jdong> and that's why we go with a no-encoders setup
[06:01] <jdong> at least that's the last explanation I heard
[06:01] <superm1> jdong, having the source in main and binaries in main/multiverse seems sensible enough though
[06:01] <pwnguin> interesting question
[06:01] <superm1> there are already source packages that do similar with main/universe at least
[06:01] <pwnguin> are binary packages in pools, or are source packages?
[06:02] <pwnguin> ie, can you split a source package into main and multiverse?
[06:02] <jdong> superm1: true, but how the heck do you split out ffmpeg like that?
[06:02] <jdong> superm1: it seems like massive surgical work that'll fork us from upstream too
[06:02] <crimsun> pwnguin: source package must line in one component.  binary packages generated from said source package can straddle components.
[06:02] <crimsun> s/line/lie/
[06:03] <superm1> jdong, well you do two builds
[06:03] <superm1> one with a bunch of --disable-foo
[06:03] <superm1> and one with a bunch of --enable-foo
[06:03] <superm1> and then you have a virtual package
[06:03] <superm1> that depends on either the main or the multiverse variant
[06:03] <jdong> superm1: dear lord that sounds like gtkpod vs gtkpod-aac
[06:03] <superm1> jdong, but it would keep away from the necessity of having to use a third party repository
[06:04] <superm1> which i would think there is a general push to do anyhow
[06:04] <jdong> superm1: well we could just have an ffmpeg-multiverse type package
[06:04] <jdong> superm1: that would be generated by a script that mangles ffmpeg with no source changes but ./configure flags
[06:05] <jdong> superm1: that way we can probably convince archive managers it's not any harder to maintain security-wise
[06:05] <superm1> well that is basically what it would be, but i think it'd be better to have a common source package
[06:05] <jdong> superm1: are you allowed to have a source pacakge output things to different sections?
[06:05] <superm1> jdong, yeah lirc does that
[06:05] <superm1> and so does ubiquity
[06:05] <superm1> archive admins make the call on where different binaries end up
[06:05] <pwnguin> tons of things have different sections
[06:05] <jdong> superm1: ok, I mean that'll work too
[06:06] <saivann> crimsun : Is it normal that the bug report automatically set itself to fix released after the patch upload ?
[06:06] <superm1> jdong, i just think it would become more of a mangement nightmare to have two source packages for the same thing
[06:06] <superm1> when you are really just mangling stuff in the debian/ directory
[06:06] <jdong> superm1: but yeah I don't think we should be relying on medibuntu for ffmpeg and k3b-mp3 both of which are just different buildflags with our source packages
[06:06] <jdong> superm1: same with mp4 extensions to amarok...
[06:07] <superm1> jdong, perhaps this proposition should be brought up on the motu mailing list
[06:07] <jdong> superm1: would you like to do the honnors as my brain's already sleeping? :)
[06:07] <superm1> jdong, and we can see what people think of doing things like the double build and different binaries in debian/rules and debian/control
[06:07] <pwnguin> jdong: well, everything works that I've tried, but I did notice something weird. totem doesn't handle 7.1 audio correctly
[06:08] <jdong> superm1: ffmpeg already fsckingb builds twice today AFAIK
[06:08] <pwnguin> jdong: all the front channels go to the right it seems =(
[06:08] <jdong> superm1: building it another time shouldn't be too bad
[06:08] <superm1> jdong, sure, probably won't be for a few hours though.  i've got a paper that i should have started about 5 hours ago :)
[06:08] <jdong> pwnguin: regression from bundled ffmpeg?
[06:08] <pwnguin> jdong: lemme check.
[06:08] <pwnguin> jdong: i doubt it though
[06:08] <pwnguin> just general gst wtf-ness
[06:09] <jdong> pwnguin: *whew* :)
[06:09] <pwnguin> i usualyl just use mplayer for the HQ stuff
[06:09] <pwnguin> i donno if its w32codecs or what but it seems to be a much smoother ride
[06:09] <jdong> pwnguin: I just use mplayer. end of sentence ;-)
[06:10] <pwnguin> mplayer's GUI is terrible
[06:10] <pwnguin> and it doesnt stream from smb
[06:10] <jdong> pwnguin: I'm CLI oriented anyway, I like invoking my media player from the terminal
[06:10] <jdong> pwnguin: and smbfs/cifs mountpoints
[06:10] <jdong> pwnguin: gnomevfs-cat | mplayer - works too
[06:10] <jdong> pwnguin: player with its own SMB library is wrong abstraction level IMO
[06:10] <pwnguin> totem's made pretty good progress, as has gst itself
[06:11] <jdong> pwnguin: yeah GST is definitely a lot better than the first time I used it
[06:11] <pwnguin> i imagine totem is just using the gnome vfs
[06:11] <jdong> pwnguin: yeah, you're probably right
[06:11] <jdong> pwnguin: we just need gvfs to be a fusefs too :)
[06:11] <jdong> which I believe was discussed here a few days ago
[06:11] <pwnguin> is that on the way to hardy?
[06:12] <jdong> pwnguin: meh sounds like one of my crazy ideas
[06:12] <jdong> so probably not ;-)
[06:12] <pwnguin> yea, the audio is definately a ffmpeg problem
[06:13] <pwnguin> i wonder if someone wanted to test this stuff without spending hardware
[06:17] <crimsun> saivann: yes
[06:17] <crimsun> saivann: that is part of the semantics for closing lp bugs from debian/changelog and why one must use that precise syntax for the header to be generated
[06:18] <saivann> crimsun : That's great!
[06:18] <saivann> crimsun : From now on, all fix that I've provided were modified and the uploader name was changed
[06:20]  * crimsun -> bed
[06:20] <saivann> crimsun : Good night
[06:31] <SiCuTDeUx> Jai!
[06:31] <SiCuTDeUx> i'm trying to build a package for linkage, a bittorrent client
[06:32] <SiCuTDeUx> but it uses a libtorrent lib diferent from the one rtorrent uses...
[06:32] <SiCuTDeUx> they are called the same...
[06:32] <SiCuTDeUx> the libtorrent package exists on repos but its not the same that linkage uses
[06:33] <SiCuTDeUx> what should i do>
[06:33] <SiCuTDeUx> ?
[06:35] <jdong> deluge uses the "other" libtorrent too AFAIK
[06:35] <jdong> but deluge bundles an internal copy of this
[06:35] <jdong> (gee bundling internal libs, this sounds familiar)
[06:35] <LaserJock> jdong: heh
[06:35] <SiCuTDeUx> jdong, familiar like... windows familiar?
[06:36] <jdong> SiCuTDeUx: nah I was just working on a bug a few minutes ago with an ffmpeg bundling issue :)
[06:36] <SiCuTDeUx> oh, ok.
[06:36] <jdong> SiCuTDeUx: is your libtorrent the same thing as what Deluge uses?
[06:37] <SiCuTDeUx> let me see
[06:37] <SiCuTDeUx> yup
[06:37] <jdong> rasterbar's?
[06:37] <SiCuTDeUx> http://www.rasterbar.com/products/libtorrent/projects.html
[06:37] <jdong> yep
[06:38] <jdong> this is beyond my scope of expertise but probably you and the deluge maintainer can work out some way to share the library
[06:38] <jdong> it's currently bundled inside deluge
[06:38] <SiCuTDeUx> hm...
[06:38] <SiCuTDeUx> i´m new building packages so...
[06:39] <SiCuTDeUx> i was trying to build striim
[06:39] <jdong> this is a case where it's better to coordinate to avoid duplication
[06:39] <SiCuTDeUx> it's an internet radio client for gnome
[06:39] <RAOF> jdong: But there's already a libtorrent in the archives, right?  And libtorrent is meant to (in the not too distant futrue) be capable of supporting deluge.
[06:39] <jdong> I'm personally not comfortable with the idea of two clients shipping the same library with themselves, unless they need special modifications or some other extenuating circumstance
[06:40] <warp10> Hi all!
[06:40] <jdong> RAOF: Rakshasa is merging with rasterbar?
[06:40] <SiCuTDeUx> jdong, me neither... better talk to him
[06:41] <RAOF> jdong: ??  I'm obviously mistaken.  I thought that deluge shipped it's own libtorrent because it required features that'd be in trunk real-soon-now(tm).
[06:41] <jdong> RAOF: lol this is really confusing, let's see if I can state what I understand...
[06:42] <pwnguin> hey, where are the example media files stored?
[06:42] <jdong> RAOF: there is Libtorrent (rasterbar) and libTorrent (rakshasa). rtorrent uses the former, Deluge and his torrent client use the latter
[06:42] <jdong> RAOF: I've understood them as completely different API's only sharing a similar name
[06:42] <RAOF> Oh, great.
[06:42] <jdong> RAOF: yeah, talk about confusing
[06:43] <LaserJock> well they *are* capitalized differently ... shesh ;-)
[06:43] <RAOF> Bittorrent *really* isn't that complicated.  Why can't they just implement it in python and be done with it.
[06:43] <pwnguin> it is implemented in python...
[06:43] <jdong> pwnguin: not anymore
[06:44] <jdong> pwnguin: Bram chose to adopt uTorrent's codebase as the mainline client now
[06:44] <pwnguin> oh?
[06:44] <RAOF> And not DFSG-compliant, right?
[06:44] <jdong> pwnguin: it is the end of python based bittorrent mainline
[06:44] <StevenK> jdong: Twitch
[06:44] <jdong> pwnguin: it's replaced with a closed source client now
[06:44] <pwnguin> hurray
[06:44] <jdong> with agreements iwth the MPAA/RIAA announced everywhere
[06:44] <pwnguin> there's still bittornado?
[06:44] <jdong> pwnguin: it's based off the obsolete and poor performing Bittorrent 3.x.x codebase
[06:45]  * pwnguin usually uses azureus
[06:45] <pwnguin> its a bit overkill
[06:45] <jdong> bram now holds the power to fragment the torrent community by implementing some extension to Bittorrent.
[06:45]  * RAOF sighs at the existance of "escape-string.cpp".
[06:45] <jdong> now there won't even be a python souced program we can reverse-engineer
[06:45] <pwnguin> jdong: and if he tries, the pirate bay declares war ;)
[06:45] <jdong> DHT was implemented mostly by reverse engineering. Bram has demonstrated he sucks at writing specsheets
[06:46] <jdong> the DHT "specs" were some of the vaguest protocol summaries I've ever read
[06:46] <pwnguin> does transmission handle dht?
[06:46] <jdong> pwnguin: yeah
[06:46] <jdong> mainline-compatible DHT
[06:46] <pwnguin> ive been meaning to try transmission out now that the desktop's running gutsy
[06:47] <jdong> pwnguin: yeah 0.91 was just backported to gutsy and it's pretty slick
[06:47]  * RAOF gapes.  Obviously no one has really read deluge-torrent's LICENSE file.
[06:48] <jdong> RAOF: it's imported from debian so $theirfault right? :D
[06:48] <RAOF> It's *upstream*'s, so it's Debian's and deluge's fault.
[06:48] <jdong> what's wrong with their LICENSE?
[06:51] <RAOF> Oh, it seemed to have boilerplate at the end.  Now that I read it more closely, it makes more sense.
[06:51] <pwnguin> uh
[06:51] <pwnguin> gplv2?
[06:52] <RAOF> Yeah.  I obviously haven't read the last part of the full gplv2 license recently :)
[06:52] <pwnguin> it doesnt diff cleanly with /usr/share/common-licenses/GPL-2, but thats mostly spacing and an openssl exception
[06:52] <pwnguin> it's probably not smart to put the openSSL exception at the end
[06:58] <pwnguin> whats the difference between h264 and h264 / avc?
[06:59] <RAOF>  Marketing.
[06:59] <jdong> pwnguin: terminology
[06:59] <RAOF> Just like there's no difference between mpeg4 avc and h264.
[06:59] <jdong> pwnguin: H.264 is MPEG-4 AVC
[06:59] <jdong> pwnguin: just like "divx" is MPEG-4 ASP
[06:59] <pwnguin> ok
[07:00] <pwnguin> then its a bit wierd that totem reports them differently ;)
[07:00] <jdong> pwnguin: urgh that's the predefined strings in the gst-ffmpeg package
[07:00] <jdong> comes out of libavformat
[07:00] <RAOF> They've probably got different 4CCs in the avi?
[07:00] <jdong> so take it $upstream :)
[07:01] <jdong> RAOF: no it depends on what container it's put in AFAIK what libavformat string it trips?
[07:01] <RAOF> jdong: Fun.
[07:01] <jdong> I just looked at this code like an hour ago, I'm ashamed I don't remember
[07:02] <RAOF> I love ffmpeg: the hyper-fast, unusable multimedia library :P
[07:02] <jdong> RAOF: meh you just have to keep up with svn and mailing lists ;-)
[07:03] <jdong> RAOF: humorously while maintaining the SVN branch of my pypodconv script, I've often just used bzr to back out previous API changes to match current API in ffmpeg SVN
[07:03] <jdong> they go back and forth between symbol names too
[07:03] <dholbach> good morning
[07:03] <jdong> morning :)
[07:04] <jdong> actually 02:00 here, eep I have school tomorrow
[07:04] <dholbach> hey jdong
[07:05] <pwnguin> jdong: so far, nothing hasn't worked
[07:05] <pwnguin> unfortunately, i appear to have lost my old GITS:SAC stuff that wouldn't play
[07:05] <jdong> pwnguin: odd :-/
[07:05] <jdong> pwnguin: did you remember to pay royalties to Apple?
[07:05] <jdong> *ducks*
[07:05] <pwnguin> ?
[07:06] <jdong> for your playback of H.264 ;-)
[07:06] <jdong> is it still free for personal use?
[07:06] <pwnguin> no clue
[07:06] <pwnguin> dont care ;)
[07:06] <jdong> I think up to 2010
[07:06] <jdong> technically
[07:06] <pwnguin> besides, you're the one who said h264 :P
[07:07] <pwnguin> oh, i guess i did mention asking what the difference between things was
[07:07] <jdong> it's the crack I'm addicted to
[07:07] <jdong> and I'm outta here before Hobbsee starts with that ;-)
[07:07] <pwnguin> that gits stuff was h264 though. first one id ever seen
[07:41] <nand`> hi!
[07:41] <nand`> I have a question about the rules files : is there a way to know which version we are currently packaging? A variable?
[07:42] <jdong> I think ${Source:Version}?
[07:42] <jdong> don't quote me on that
[07:43] <nand`> jdong: I try...
[07:44] <nand`> jdong: nup
[07:44] <nand`> jdong: it is for the control file IIRC
[07:45] <nenolod> pidgin-mpris can now be archived. it's in debian. ;)
[07:45] <jdong> oh the rules file
[07:45] <jdong> oops sorry
[07:45] <jdong> I'm an idiot. It's a good sign that I'm sleep deprived
[07:45] <nenolod> (on revu)
[07:45] <nand`> jdong: ;)
[07:46] <LaserJock> jdong: go to bed!
[07:46] <jdong> LaserJock: yes master!
[07:48] <\sh> Fujitsu, thx for adding the hugin patch to hardy :)
[07:53] <Hobbsee> jdong: i think it's s/S/s/ or s/Source/binary/.  check the new policy
[07:59] <nand`> jdong: found a regex on the changelog for that.
[07:59] <jdong> nand`: eep
[07:59] <jdong> nand`: I was going to suggest that then shut myself up
[07:59] <nand`> jdong: ;)
[08:00] <nand`> jdong: you may check the aleph source pkg for it
[08:00] <jdong> nand`: you should use dpkg-parsechangelog though IMO
[08:00] <nand`> jdong: whoah. Another utility!
[08:00] <jdong> nand`: dpkg-parsechangelog | grep '^Version' | sed 's/Version: //'
[08:01] <jdong> nand`: dpkg-parsechangelog is a frontend to manually sedding the changelog file, which apparently is not recommended
[08:01] <nand`> jdong: Ok thanks!
[08:02] <nand`> jdong: We get the debian version, I'd like the upstream version. An idea for that?
[08:02] <nand`> (apart from manually seding that)
[08:02] <jdong> nand`: | awk -F- '{print $1}'
[08:03] <jdong> do I get a hackjob trophy yet?
[08:03] <nand`> jdong: nice :)
[08:03]  * nenolod is working on first step of killing notification-daemon. Release plan for libaosd is set, and i've claimed ITP on the package in Debian. ;)
[08:04] <nenolod> i like to call my in-progress spec "notification-daemon-sucks-lets-replace-it-with-something-better-in-hardy-plus-one"
[08:06] <jdong> nand`: if you want to see some ugly changelog deforming go look at the source to prevu ;-)
[08:07] <nand`> jdong: arrh. I'll fight and kick down mine first!
[08:09] <nand`> and second question : should the get-orig-source target triggered automatically? Mine is not launched, and I don't see references to a call on other rules files.
[08:18] <highvoltage> nxvl: pong
[08:29] <superm1> congrats jdong
[08:37] <nand`> or do you have to manually call make -f debian/rules get-orig-source before debuild ?
[08:45] <LaserJock> jdong: congrats!
[08:46]  * Hobbsee gives jdong a beaver.
[08:46]  * nand` senses a MOTU nomination in the air...
[08:55] <siretart> jdong: w0000t! you finally made it! congrats!
[08:56] <\sh> jdong, at last :) congrats :)
[08:56] <siretart> jdong: this effektively means you can do the x264 update in hardy yourself now :)
[08:56] <StevenK> jdong: Congrats
[08:56]  * Nafallo thinks jdong just got promoted :-)
[08:57] <\sh> siretart, good to see you...where did you hide the old motu-tools bzr archive? :) I need our old lpbugs.py source
[08:57] <Nafallo> jdong: congrats!
[08:57] <siretart> \sh: good morning!
[08:57] <siretart> \sh: errr, huh? - isn't it on launchpad somewhere?
[08:57] <\sh> siretart, nope couldn't find it in the usual places...
[08:58] <\sh> siretart, you know the really old script we used to file merges etc. via email
[08:58] <siretart> \sh: I have it in my home directory here... hmm
[08:59] <siretart> pushing it to lp now
[08:59] <siretart> \sh: https://code.edge.launchpad.net/~siretart/+junk/motu-tools is what I have
[09:00] <siretart> it seems we managed it on tiber only. hm
[09:00] <dholbach> filing a bug with py-lp-bugs is easy too
[09:01] <siretart> \sh: we should really see what of that can be merged to ubuntu-dev-tools, however
[09:01] <\sh> hmmm...I can't browse the source of this archive
[09:01] <dholbach> https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug?highlight=%28BugHelper%2FDev%29#head-27dc45b0392cc14364bd08fc4484df026122c91f
[09:01] <siretart> \sh: give lp a few minutes
[09:01] <dholbach> (or check out ppaput in ubuntu-dev-tools for an example)
[09:02] <dholbach> or massfile
[09:02] <siretart> dholbach: is that the page with the API of python-launchpad-bugs that you promised me?
[09:02] <siretart> ;)
[09:02] <\sh> oh damn...I would like to see our sources we sec-fix for old releases in a bzr branch...
[09:02] <dholbach> siretart: that's examples of how to use py-lp-bugs API
[09:07] <\sh> launchpad is silly...LP should know, that openldap2.2 is not in gutsy so therefore it should know that feisty/gutsy are not to be mentioned in the nominated click field
[09:08] <\sh> and it should copy nominations when telling LP that it also affects different source packages from different releases...*grmpf*
[09:08] <Hobbsee> \sh: --> bug.
[09:08] <Hobbsee> \sh: sounds like a good one.
[09:08] <\sh> s/should/shouldn't/
[09:10] <\sh> Hobbsee, yeah...when I won the fight with openldap in 3 flavours (openldap2, 2.2 and 2.3) in 4 different releases (2,2.2 in dapper, edgy, 2.3 in feisty, gutsy) and uploaded all diffs..I'll file bugs against LP a lot
[09:10] <Hobbsee> \sh: good man :)
[09:20] <nenolod> what is needed for autosync to occur on a package in sid?
[09:20] <nenolod> does it need to be in debian-testing if it's a new package?
[09:21] <LaserJock> nenolod: what do you mean?
[09:21] <LaserJock> autosyncs should occur up until Debian Import Freeze
[09:21] <nenolod> well for instance, libprojectm entered debian unstable last week, and had never been in unstable before, will the sync pick it up?
[09:22] <nenolod> :P
[09:22] <LaserJock> sure
[09:22] <nenolod> ah, so the sync just hasn't run yet
[09:22] <nenolod> ok ;)
[09:22] <LaserJock> I'm not sure how long it will take, but it'll show up somewhere
[09:22] <LaserJock> if it's new to Debian then I think it goes to a different list than just updates of an existing package
[09:22] <nenolod> yuck :P
[09:23] <LaserJock> I imagine the archive admins like to take a look first before putting it in the archives
[09:23] <nenolod> is there a page which highlights ubuntu's NEW queue?
[09:24] <LaserJock> https://launchpad.net/ubuntu/hardy/+queue
[09:24] <LaserJock> but I don't think that shows autosync
[09:26] <nenolod> it does show autosync
[09:27] <LaserJock> nenolod: yeah?
[09:27] <nenolod> yeah, there's a few packages that lack the ubuntu tag at the end
[09:28] <nenolod> http://launchpadlibrarian.net/10329451/jakarta-log4j_1.2.15-1_source.changes
[09:28] <nenolod> Changed-By: Ubuntu Archive Auto-Sync <archive@ubuntu.com>
[09:28] <nenolod> ;)
[09:29] <nenolod> i think the fact that i went through that means i fail at life tbh ;)
[09:33] <huats> morning everyone
[09:34] <\sh> phew....
[09:34] <\sh> feisty and gutsy done....2x dapper, 2x edgy to go...*gnarf*
[09:35] <nenolod> LaserJock, if my package in debian goes into ubuntu NEW, do you think it will email me about it? :P
[09:35] <LaserJock> nenolod: no
[09:35] <nenolod> rats
[09:36] <\sh> do we have something like #debian-security for ubuntu?
[09:36] <LaserJock> \sh: sure, it's called keescook
[09:36] <LaserJock> ;-)
[09:37] <\sh> LaserJock, lol /join #keescook ,-)
[09:37] <\sh> oh well, I wonder if kees is this kees cook which is in mplayers about box for credits...
[09:38] <ajmitch> hi
[09:38] <\sh> moins ajmitch
[09:40] <Hobbsee> damn it, pkern.
[09:40] <Fujitsu> \sh: That tasks existing where they shouldn't bug is filed.
[09:40]  * Hobbsee wishes people post to the list *before* they flood the buglist.
[09:41] <Fujitsu> It's because LP is braindead, and applies nominations to all distro tasks.
[09:41]  * Fujitsu looks for the number.
[09:41] <Hobbsee> was going to get him to tag it all as bitesize.
[09:41] <Hobbsee> dholbach: ^
[09:41] <Hobbsee> dholbach: i presume you can do a bughelper query for that
[09:41] <Fujitsu> Bug #110195
[09:41] <ajmitch> the ftbfs bugs?
[09:41] <ubotu> Launchpad bug 110195 in malone "Nomination for a release on one source package shouldn't affect any others" [Undecided,New] https://launchpad.net/bugs/110195
[09:41] <Hobbsee> ajmitch: yes
[09:42] <\sh> Fujitsu, cool...one bug less to file against LP
[09:42]  * Fujitsu wonders why they would be bitesize.
[09:42] <Hobbsee> ajmitch: it's a dh_iconcache --> dh_icons switch only
[09:44] <dholbach> Hobbsee: bughelper query for what?
[09:44] <Hobbsee> dholbach: all these bugs pkern is filing.
[09:45] <dholbach> Hobbsee: which bugs?
[09:45] <Hobbsee> dholbach: see -bugs
[09:45]  * Hobbsee --> dinner
[09:50] <s1024kb> luisbg: hi, i am selene, nice to meet you!
[09:52] <proppy> hi
[09:53] <s1024kb> hi...
[09:54] <proppy> s1024kb: I've seen your mail on the list: welcome !
[09:56] <s1024kb> proppy: thanks!
[09:57] <s1024kb> proppy: only me today, my friend maia will come thursday. :-)
[09:58] <luisbg_> hello s1024kb =)
[09:58] <s1024kb> luisbg_: hello! :-)
[09:58] <luisbg_> how is all?
[10:00] <s1024kb> i am still working on the first simple task given by my teacher - merging the package "yappy". only "gram-merge" it, not yet finish...
[10:01] <DaveMorris> since it's revu day I've got 2 new packages on revu.  http://revu.tauware.de/details.py?package=libserial and a slightly one which different people tell me different things - http://revu.tauware.de/details.py?package=cpptest
[10:03] <TheMuso> Does anybody have any comments about my questions in -devel?
[10:03] <luisbg_> s1024kb, cool
[10:05] <s1024kb> luisbg_: but... could you please tell me how to find out the changes which i should write them on the changelog file?
[10:06] <dholbach> StevenK: can you put your desktop file script from MOTU/Packages/DesktopFiles into ubuntu-dev-tools?
[10:06] <dholbach> StevenK: I'd like to merge that page into the packaging guide
[10:07] <luisbg_> hello dholbach =)
[10:07] <dholbach> heya luisbg
[10:07] <luisbg_> s1024kb, are you using mom or dad?
[10:07] <dholbach> how's it going?
[10:07] <luisbg_> dholbach, very good... catch up with work and now I'm back to ubuntu contributing =)
[10:07] <luisbg_> dholbach, how are you?
[10:07] <dholbach> NICE
[10:08] <dholbach> all's good - I'm working on http://wiki.ubuntu.com/Spec/PackagingGuideMerge
[10:08] <s1024kb> luisbg_: dad.
[10:09] <luisbg_> dholbach, awesome!
[10:09] <luisbg_> dholbach, when you need people to read and review the document, let me know
[10:09] <luisbg_> s1024kb, never used dad but let me check
[10:10] <LaserJock> anybody know of a fast way in Python to make a list be all 0s?
[10:10] <Fujitsu> LaserJock: You want to create a list of 0s of arbitrary length?
[10:10] <LaserJock> I know the lenght of the list
[10:10] <LaserJock> I'm trying to "blank" the list
[10:10] <s1024kb> luisbg_: what's the difference between mom and dad?
[10:11] <dholbach> LaserJock:    a = [1,2,3,4,5,6]; print map(lambda b: 0, a)     ?
[10:11] <luisbg_> s1024kb, different ways to "semi-automatize" merges
[10:11] <luisbg_> s1024kb, anyway... do you know debdiff?
[10:11] <\sh> s1024kb, dad has a nicer webpage then mom ;)
[10:11] <s1024kb> luisbg_: yes. but never did it.
[10:11] <luisbg_> \sh, are you familiar with dad?
[10:11] <s1024kb> \sh: that's why i downloaded things there, :-)
[10:12] <luisbg_> s1024kb, do a debdiff between ubuntu and debian versions
[10:12] <\sh> luisbg, tbh I use dad only for add bug reports to it
[10:12] <luisbg_> \sh, can you help s1024kb with here changes question?
[10:12] <\sh> luisbg, it works like mom, different grab-merge script of course
[10:12] <s1024kb> luisbg_: did the script "grab-merge" did that for me already?
[10:13] <luisbg_> s1024kb, it should =)
[10:13] <\sh> s1024kb, sometimes yes, sometimes no...you have to manually review the changes between debian and ubuntu
[10:13] <luisbg_> LaserJock, hey Jordan!
[10:14] <s1024kb> \sh: i know, but i just want to know HOW to review them? I must compare 2 files then i can find out the difference, right? but which files?
[10:14] <LaserJock> luisbg_: hello
[10:15] <luisbg_> s1024kb, debian/changelog should be a good start
[10:15] <luisbg_> check for debian changes after the previous ubuntu merge
[10:16] <s1024kb> luisbg_: i had read it already. but... seems that the script had written all the changes on the changelog, that's why i don't know how to do.
[10:17] <\sh> s1024kb, 1. if debian applied some patches from ubuntu, or fixed bugs, which ubuntu fixed separatly, forget the ubuntu change...
[10:17] <\sh> 2. if there are other things fixed, or changed because of distro specific stuff, please merge the changes into actual debian package..and merge the complete changelog...
[10:19] <s1024kb> \sh: okay. could you please tell me an example "what to do"? after doing "grab-merge" with the script, i can see that a lot of files in my folder, but don't know what to do next.
[10:19] <\sh> 3. if there are only bugfixes, which are already fixed through a new upstream version of debian, or the debian maintainer fixed them in a new upload to debian, and there are no other changes left from ubuntu, it more likely that we have a sync
[10:20] <\sh> s1024kb, check debian/changelog...
[10:20] <\sh> s1024kb, check the REPORT file
[10:20] <s1024kb> \sh: yes, i had checked them both.
[10:20] <\sh> s1024kb, so you see the changes from ubuntu in the changelog and the newly fixed stuff from debian
[10:22] <\sh> s1024kb, now compare the two and decide if it's more a sync or a merge, if a merge, use the changes the last ubuntu uploader made, and check them in the merged mom/dad sourcetree (mostly, packagename-<version>-<debianrevision>ubuntu<ubunturevision>)
[10:22] <s1024kb> \sh: yes, i can see them both in the changelog.
[10:23] <\sh> s1024kb, on which package you are working and are you working with mom or dad?
[10:23] <s1024kb> \sh: not very understand "a sync", my bad English...
[10:24] <s1024kb> \sh: dad, because i downloaded the things there. i see a package list there and then i can download the one i want.
[10:25] <\sh> s1024kb, a sync is, when ubuntu uploaded a package with ubuntu changes, so it won't catched by our autosync bot, which means, we have to decide, if we merge (means uploading the new upstream version with ubuntu changes) , or sync (means giving the archive maintainers a hint, that they push this package manually to their sync script and grabbing the new package from debian, without any ubuntu changes, and all ubuntu changes dropped)
[10:25] <\sh> s1024kb, which packages?
[10:26] <\sh> s1024kb, let's try to do it together
[10:26] <s1024kb> \sh: thank you very much!!
[10:26] <s1024kb> \sh: yappy
[10:27] <luisbg_> thanks \sh
[10:27] <luisbg_> =)
[10:27] <\sh> s1024kb, ok...first, there are no conflicts in the REPORT...which means mostly that debian upstream applied all changes we made...which is a good thing
[10:28] <s1024kb> \sh: yes
[10:28] <dholbach> LaserJock: did you have luck with your python bits?
[10:29] <s1024kb> luisbg_: thank you too. i will record all the things i learn from here and send them to my friend maia too...
[10:29] <\sh> s1024kb, ok...now we check the debian/changelog in the source tree (cd yappy-1.8)
[10:29] <s1024kb> \sh: okay, open it already
[10:29] <luisbg_> s1024kb, you can be her teacher too
[10:30] <\sh> s1024kb, ok..now you see for the ubuntu upload the following:
[10:30] <\sh>     - Remove pycompat file
[10:30] <\sh>     - Add pyversions file
[10:30] <\sh>     - Remove dh_python from debian/rules
[10:30] <\sh>     - debian/control:
[10:30] <\sh>       + Bump python-support version to >= 0.5.3
[10:30] <\sh>       + Update maintainer per spec
[10:30] <s1024kb>  luisbg_: yes, i wish that more and more new packagers become stronger...
[10:31] <s1024kb> \sh: yes, see it.
[10:31] <\sh> s1024kb, ok, let's go for the removed pycompat...
[10:31] <LaserJock> dholbach: yes thanks, that did the trick
[10:31] <dholbach> LaserJock: ok super
[10:32] <\sh> s1024kb, you check debian/ dir, and you see, pycompat is there again...which means, right now, it's not a sync, it's a merge, because bddebian removed it, and had a reason for it
[10:32] <s1024kb> \sh: okay
[10:32] <\sh> s1024kb, which means, remove debian/pycompat
[10:33] <luisbg_> s1024kb, we wish the same (more new and strong packagers in ubuntu)
[10:33] <\sh> s1024kb, now bddebian added debian/pyversions, which gladly dad added to debian/ dir, again
[10:34] <\sh> s1024kb, this file you leave in the debian/ dir
[10:34] <s1024kb> luisbg_: thanks for your understanding, :-)
[10:35] <luisbg_> LOL
[10:36] <s1024kb> \sh: okay. (after thinking for quite a while...)
[10:36] <\sh> s1024kb, now...barry added the following line to debian/changelog: - Remove dh_python from debian/rules
[10:36] <\sh> this is a bit tricky
[10:37] <\sh> s1024kb, when dad was working correctly you can see the change, in this type, that you don't see dh_python anymore in debian/rules
[10:37] <\sh> s1024kb, so, we have to check the following file: yappy_1.8-3ubuntu1.patch
[10:37] <POX_> if you remove dh_python from debian/rules, debian/pycompat is not needed
[10:37] <POX_> CDBS is still calling it
[10:37] <\sh> s1024kb, in this file you can see the diffs between 1.8-3 version of debian and the merge of dad to 1.8-3ubuntu1
[10:38] <\sh> POX_, yepp
[10:38] <\sh> s1024kb, so, in this patch file you can see this diff:
[10:38] <\sh> --- yappy-1.8/debian/rules
[10:38] <\sh> +++ yappy-1.8/debian/rules
[10:38] <\sh> @@ -51,7 +51,6 @@
[10:38] <\sh>         dh_compress -X.py -X.pdf
[10:38] <\sh>         dh_fixperms
[10:38] <\sh>         dh_pysupport
[10:38] <\sh> -       dh_python
[10:38] <\sh>         dh_installdeb
[10:38] <\sh>         dh_shlibdeps
[10:38] <\sh>         dh_gencontrol
[10:39] <\sh> which means, debian upstream has still dh_python in its debian/rule file, but we don't have it...so it's automagically removed from the actual source tree...which means, the change is still valid
[10:39] <\sh> (for the others...sorry to flood the channel....)
[10:41] <\sh> s1024kb, till here...any questions?
[10:42] <s1024kb> \sh: ... still thinking and following...
[10:43] <s1024kb> \sh: by the way, can we talk sometimes via e-mail? especially for those questions which could bother others on the channel...
[10:45] <dholbach> effie_jayx: I love your MOTU diary on the wiki - you should blog each of those posts!
[10:45] <effie_jayx> dholbach,  I though I could do that after four lessons... but I don't know how much spam that would mean to people
[10:46] <effie_jayx> I just finished debdiffs
[10:46] <effie_jayx> and I love the tools
[10:46] <s1024kb> \sh: understand so far.
[10:46] <dholbach> effie_jayx: great work!
[10:46] <dholbach> effie_jayx: it wouldn't spam people, but if you want to just blog about every n-th 'lesson', that's cool too :)
[10:46] <effie_jayx> dholbach, meh ... nah.. I am just foloing the leader
[10:47] <effie_jayx> I was kinda hoping people would also tell me of more stuff  I might be missing
[10:47] <\sh> s1024kb, jabber is my favorite :)
[10:47] <effie_jayx> dholbach,  I shall blog more about it then
[10:47] <dholbach> effie_jayx: take your time, it's just great to see what you're doing
[10:48] <s1024kb> \sh: may i send you e-mails?
[10:48] <\sh> s1024kb, sure...
[10:48] <effie_jayx> dholbach,  thanks for the support
[10:48] <dholbach> effie_jayx: thank YOU :)
[10:48] <\sh> s1024kb, but we are through :)
[10:48] <\sh> s1024kb, the other change:     - debian/control:
[10:48] <\sh>       + Bump python-support version to >= 0.5.3
[10:48] <\sh>       + Update maintainer per spec
[10:49] <s1024kb> \sh: jabber? something like MSN? not having one... okay, so this time let's do it here
[10:49] <\sh> s1024kb, is also still valid...so you can see in debian/control the updated python-support version, and the Maintainer: and XSBC-Original-Maintainer line
[10:49] <\sh> s1024kb, jabber is the best IM on earth :) yes...jabber.org, google talk or what every jabber server you want :)
[10:50] <\sh> s1024kb, so, summary: all changes from ubuntu are still valid..if dad is working correctly, all changes are applied in the actual sourcetree
[10:50] <s1024kb> \sh: i have only MSN at the moment, i will apply one if necessary. :-) my MSN: selene-lee@hotmail.com
[10:51] <\sh> s1024kb, which means, you dch -a now and add all remaining ubuntu changes (which you can c & p from the last ubuntu upload) to the last changelog entry generated by dad...
[10:52] <s1024kb> \sh: okay, i will copy the chat record and do it at home, after read them carefully. is it convenient to tell my your e-mail address?
[10:53] <\sh> s1024kb, when you added the remaining ubuntu changes to the last dad generated changelog entry, you save the debian/changelog, and debuild -S -v1.8-2ubuntu1
[10:53] <\sh> s1024kb, with this you generated a new .dsc and .diff.gz file
[10:53] <\sh> s1024kb, go one dir up, and pbuilder build yappy_1.8-3ubuntu1.dsc
[10:54] <\sh> s1024kb, if everything is ok, no ftbfs or whatever will happen, you just call debdiff yappy_1.8-3.dsc yappy_1.8-3ubuntu1.dsc > yappy_1.8-3ubuntu1.debdiff
[10:55] <\sh> s1024kb, which will generate a debian diff file between the new debian upstream version (1.8-3) and the newly merged ubuntu version (1.8-3ubuntu1)
[10:55] <s1024kb> \sh: okay, understand so far...
[10:55] <\sh> s1024kb, this debdiff you attach to the bug report for the merge, which you have to create
[10:55] <\sh> s1024kb, subscribe ubuntu-universe-sponsors to the bug
[10:55] <\sh> s1024kb, and add the bug report to the yappy package on the DAD page
[10:56] <\sh> (bug report == lp bug number)
[10:56] <\sh> s1024kb, then you have to wait for a sponsor and if everything is ok, you'll see your name on hardy-changes later on
[10:57] <s1024kb> \sh: okay.
[10:57] <\sh> s1024kb, and add those stuff to your list of work on your wiki page...which is important to document what you did for the motu group...so in no time you are a motu and don't have to rely on any sponsor ;)
[10:58] <s1024kb> \sh: yes, just waiting for that day comes... ;-)
[10:59] <s1024kb> \sh: by the way, how can i send you e-mails?
[10:59] <\sh> s1024kb, check my lp page: https://launchpad.net/~shermann/
[11:00] <\sh> s1024kb, sh at sourcecode dot de
[11:01] <\sh> s1024kb, but you can also redirect your questions to ubuntu-motu@lists.ubuntu.com so everyone even the hopefuls can learn from all the questions :)
[11:01] <s1024kb> \sh: thank you very much! and i have to say thank you for my friend too - who is a beginner also and studying together with me... :-)
[11:02] <\sh> s1024kb, and get a jabber account ;) the most easy one is to apply for a gmail account which is also a jabber account :)
[11:04] <s1024kb> \sh: okay, i will! what a happy day! thank you!:-D
[11:05] <\sh> s1024kb, no thank you for working on ubuntu :)
[11:09] <s1024kb> \sh: oh... your words made me feel kind of guilty - i am learning too slow, and i am too busy with my work in office and having too little time for the Ubuntu work... but i will work hard and never give up. My friend also! Thank you for your help and encouragement!
[11:09] <bigon> dholbach: any objection in syncing empathy?
[11:10] <dholbach> bigon: um - I'd need to look at the diff
[11:11] <dholbach> bigon: we seem to have different conflicts/replaces than they do?
[11:13] <dholbach> bigon: you did the merge last time, so you should know best :)
[11:13] <bigon> dholbach: two thing would be lost, telepathy-core in suggests and telepathy-gabble in depends (not so important since recommends are now installed by default)
[11:14] <bigon> dholbach: the conflict thing are now the same in debian
[11:14] <dholbach> bigon: are they in Ubuntu?
[11:15] <bigon> they should be in hardy
[11:15] <s1024kb> \sh, luisbg_: bye my friends, thank you very much!
[11:15] <dholbach> bigon: if that's all the case, we can sync it from debian
[11:16] <bigon> ok
[11:19] <nand`> Hi! I'd like a review of my package ike please http://revu.ubuntuwire.com/details.py?package=ike  (Everything should be ok now)
[11:22] <soren> nand`: You don't need to b-d on sed and grep. They're considered essential (they have Essential: yes), so they'll always be present.
[11:23] <nand`> soren: Ah ok, I was not sure...
[11:23] <soren> nand`: np :)
[11:23] <nand`> didn't know about the Essential field
[11:36] <persia> nand`: It's best practice to have a version number like 2.3.3+dfsg when repacking.  I don't know if it's a blocking issue for everyone, but I prefer warning when there is a repack.
[11:37] <nand`> persia: Yeah I have read about that, but was not sure where to put this. I will correct that too.
[11:37] <persia> nand`: When you make the orig.tar.gz, call it ike_2.0.3+dfsg.orig.tar.gz, and use the version in your changelog.  Then everything works.
[11:38] <nand`> persia: you mean I keep the current version in changelog, only change the orig file version?
[11:38] <persia> nand`: Change it both places.
[11:38] <nand`> persia: ok
[11:40] <frenchy> Greeting MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV?  I'm still awaiting my first advocate.  See http://revu.tauware.de/details.py?upid=707.
[11:40] <persia> frenchy: That's a lovely advertisement :)
[11:43] <frenchy> persia: Thanks, I got a few pointers from a friend.
[11:43] <frenchy> ;)
[11:49] <Hobbsee> uh oh, revu day
[11:51] <persia> frenchy: I'd suggest you clean up the posted lintian and linda warnings before seeking formal review.  It should be as easy as deleting some files in your clean:: rule, and copying /usr/share/misc/config.sub and config.guess in makebuilddir/me-tv::
[11:54] <persia> Hobbsee: You're exempt from REVU day: don't complain :)
[11:54] <Hobbsee> persia: woot!
[11:54] <Hobbsee> excellent!
[12:01] <frenchy> persia: I think that they are legitimate errors.  I wasn't previously running ./autogen.sh before making the orig.tar.gz.  Doing so obviously has changed a few things.  Thanks for spotting that.
[12:02] <Hobbsee> hi joejaxx
[12:02] <Hobbsee> er, hi jono
[12:02] <jono> hey Hobbsee
[12:02] <persia> frenchy: No problem.  I'd suggest always checking the upload page once you make an upload, just in case.  The latest linda and lintian are usually backported to REVU in short order, just to make sure that they are providing the best feedback.
[12:11] <frenchy> persia: I have a confession to make ... I cheated and let anjuta do everything for me.  Hopefully, 1) I can get anjuta to do what you're asking, or 2) Fix all the issues so I don't get errors/warnings.
[12:12] <persia> frenchy: Are you upstream also?
[12:12] <frenchy> persia: I guess I am.
[12:13] <frenchy> ha, I've never thought of myself as upstream.
[12:13] <persia> frenchy: Just delete config.sub, config,guess, and config.log in your clean: rule in Makefile.in (if I remember correctly), and add the ones you need in the packaging.
[12:13] <superm1> frenchy, its king a cool feeling eh? :)
[12:13] <superm1> s/king/kind/
[12:14] <frenchy> superm1: I don't know ... the pressure man, the pressure.
[12:14] <frenchy> !
[12:15] <persia> DktrKranz: How do you feel about bug #158252?  Should it be uploaded, or do you also want to wait until the other releases get investigated so we don't forget about it?
[12:15] <ubotu> Launchpad bug 158252 in dspam "dspam won't start:  /var/run/dspam missing in tmpfs" [Undecided,Confirmed] https://launchpad.net/bugs/158252
[12:17] <DktrKranz> persia, I looked at it briefly and I noticed a bad behaviour only when running /etc/init,d/dspam stop ("dspam is not started", while it is). If I haven't overlooked the real main issue, it should be ready for upload.
[12:18] <DktrKranz> anyway, a TEST CASE should be listed since there are some easy operation to do to test it
[12:18] <persia> DktrKranz: OK.  I was holding off mostly based on your last comment requesting investigation for dapper, edgy and feisty.  If you're not worried we'll lose it, I'll take another test, and reupload.
[12:18] <persia> (and that too :) )
[12:19] <DktrKranz> I ran a quick test on Feisty (work prevented me to test on Edgy and Dapper), but it seems affected too
[12:20] <persia> DktrKranz: Makes sense.  I'll open a feisty task so we don't lose it, and take care of gutsy.  That way the bug is still open, and one of us might catch blueyed later.
[12:20] <frenchy> persia: It uses automake ... doh.
[12:21] <DktrKranz> persia, Thanks. I'll do some more tests in Edgy and Dapper, I'll ping blueyed to make sure we're aware of the real matter
[12:21] <persia> DktrKranz: Thanks.
[12:22] <nand`> Little things corrected! I'd like a review of ike please : http://revu.ubuntuwire.com/details.py?package=ike
[12:42] <persia> nand`: Just an aside: you might want to look at sed s/foo/bar/p to save on grep next time :)  Not important at all, and no need to fix it unless you are doing something else.
[12:43] <nand`> persia: I admit, I was quite lazy here to open my sed book and merge the two seds ;)
[12:43] <nand`> and the grep too
[12:44] <persia> nand`: Next time (I still need to look in more detail).
[12:44] <nand`> persia: Ok thanks.
[12:44]  * DktrKranz looks at the u-u-s queue and cheers at the only one outstanding bug \o/
[12:45] <persia> DktrKranz: I'm waiting to hear back from asac on that one: I don't really understand the commend without an upload.
[12:45] <DktrKranz> additionally, there is some configure cruft I think can be omitted
[12:47] <french> Am I still connected?
[12:49] <frenchy> Did that work?
[12:49] <frenchy> Hooray, I'm frenchy again!
[12:49] <persia> frenchy: It worked before, and you are now (to some subset)
[12:50] <frenchy> persia: Was that just me or did things go funny here?
[12:51] <persia> frenchy: There was a interruption in interserver communication, which has now been resolved.
[12:51] <rexbron> hey persia
[12:51] <persia> hey rexbron
[12:51] <rexbron> persia: I have uploaded a fixed version of genpo to revu. The get-orig-source rule should work now
[12:52] <frenchy> Reposting my question, apologies if you already got it ...
[12:52] <frenchy> On http://revu.tauware.de/details.py?upid=707, jpatrick mentioned 'You may want to put a "Homepage: " after SV in control'.  But there's no mention of the field at http://www.debian.org/doc/debian-policy/ch-controlfields.html.  Can someone please explain?
[12:52] <persia> rexbron: Great, I'll take a look when I've finished my current worklist, but if you've not in a while, you may get a better response with a general advertisement.
[12:52] <rexbron> frenchy: Homepage is a new addition to the spec from discussion of the debian ml
[12:53] <persia> frenchy: That's a bug in policy, which should be resolved soon.
[12:53] <rexbron> frenchy: the documentation will be updated to reflect those changes
[12:53] <rexbron> persia: Will do
[12:53] <frenchy> Is this a bug to? dpkg-source: warning: unknown information field 'Homepage' in input data in general section of control info file.  Use of uninitialized value in pattern match (m//) at /usr/bin/dpkg-source line 342.
[12:54] <rexbron> frenchy: yes, dpkg-source and linda/lintian need to be updated. You can ignore that
[12:54] <persia> frenchy: You might want to build in a hardy chroot.  I'm not sure if the gutsy tools expect that.
[12:54] <frenchy> Yeah, thought that might be the case ... thanks.
[12:55] <rexbron> Hey everyone! Looking for a review, I have just the ticket: http://revu.tauware.de/details.py?package=genpo
[12:55] <frenchy> Is it a big issue if I just don't put it in.  I don't really have a proper homepage yet.
[12:56] <rexbron> frenchy: it is the homepage for the project
[12:56] <rexbron> That url used to be included in the description
[12:56] <persia> frenchy: If you don't have a homepage yet, it's not a big deal, but you should have a homepage, if only somewhere people can download the tarball.  Have you selected a code host yet?
[12:57] <frenchy> That'd be LP.
[12:57] <rexbron> persia: Am I mistaken as to the purpose of the Homepage: field?
[12:57] <persia> frenchy: Then it might be the LP project page :)
[12:57] <persia> rexbron: Not at all, frenchy is special, because frenchy is also upstream.
[12:57] <frenchy> persia: It is currently.
[12:57] <rexbron> oh lol
[12:59] <frenchy> rexbron: Don't listen to me I'm a real noob.
[12:59] <frenchy>  ... at packaging
[13:01] <zul> morning
[13:04] <frenchy> I've written this crazy script that svn export, make dist, mv tar.gz to .. orig.tar.gz, copied debian/ in then dpkg-buildpackage -S -sa -rfakeroot ... surely there's a better way to do this.  Anyone?
[13:09] <frenchy> I'll take that as a no?
[13:11] <persia> frenchy: I'd suggest not hosting debian/ in anjuta.  Maintain your upstream package cleanly for adoption by any distro, and keep debian/ separate (stored in the diff.gz).
[13:13] <persia> frenchy: Once you have a sane diff.gz, you can usually apply it to an updated upstream (if there are no patches) with `zcat ../mypackage_version-revision.diff.gz | patch -p1`
[13:13] <\sh> siretart, which license did you took for lpbugs.py? should we explicitly say it's gplv2 or bsd lic?
[13:13] <persia> Then, if you update the changelog, and make any other required adjustments, `debuild -S -sa` will generate the right updated diff.gz and .dsc files.
[13:14] <siretart> \sh: I'm happy to duallicense it GPL+bsd, at the user's option. read: I don't care
[13:15] <\sh> siretart, ok...I just wanted to be sure, that the lic statement on top wasn't  subject to be changed ;)
[13:21]  * Hobbsee wishes people *wouldnt* do crackful things.
[13:21] <frenchy> persia: That's what I do.  Even though it is in svn, I actually move it out when I do the make dist.  Then put it back in for the dpkg-buil...
[13:22] <persia> frenchy: You might want to look at svn-buildpackage, which may help you.
[13:22] <frenchy> persia: Apart from that are you telling me that there's about 7 manual steps that everyone is doing  ... svn-buildpackage ... I'll look at that thanks.
[13:25] <persia> frenchy: mostly, yes.
[13:52] <\sh> what is the irc tag of our envy developer?
[13:53] <norsetto> \sh You mean Milone?
[13:53] <persia> I'd like a second opinion on licensing.  I'm looking at a package, and it contains lots of notes "Copyright $copyright_holder, All Rights Reserved" directly prior to the preamble of a permissive GPL-compatible free license.  Is this OK?
[13:53] <\sh> norsetto, yepp
[13:54] <norsetto> \sh tseliot
[13:54] <StevenK> persia: Linda is licensed the same way
[13:54] <persia> StevenK: Good enough for me.  Thanks.
[13:54] <\sh> norsetto, thx
[13:55] <proppy> hi
[14:00] <persia> nand`: Are you expecting upstream to release 2.0.3 soon?
[14:00] <nand`> persia: Well, upstream is waiting for the packaging go to release it :)
[14:01] <nand`> persia: I think a few repackages of its 2.0.2 version had made him more cautious...
[14:02] <persia> nand`: OK.  Just wanted to make sure, as otherwise I'd complain about your watch file.  Advocating now.
[14:02] <nand`> persia: yeah!
[14:02] <nand`> nand`: thanks again for your help!
[14:02] <nand`> uh
[14:03] <nand`> persia: I have two more questions if you don't mind :
[14:03] <persia> nand`: Which are they?
[14:04] <nand`> persia: what is the procedure if upstream release a new version? Do I have to re go through REVU, or is there another process?
[14:05] <nxvl> hi folks!
[14:05] <nxvl> norsetto: did you recieve my mail?
[14:05] <norsetto> nxvl: yes, its being worked on
[14:05] <nxvl> norsetto: thnx :D
[14:06] <persia> nand`: Writing a clean one is currently on my todo list :)  Currently, there are three ways that it works: you can package the new version, and submit to REVU, you can package the new version, and submit an interdiff to the sponsors queue, or you can package the new version in a dget'able location and request a sponsor.  I prefer reviewing interdiffs.
[14:06] <nand`> persia: Well, I'm also planning to follow the packaging to debian, so it would simplify. I just wonder how if works with ubuntu-only  packages.
[14:06] <nand`> persia: interdiff : a diff of two diffs? nice!
[14:07] <persia> nand`: There's not a big difference between the processes for Ubuntu-local packages and packages merged from an external source, except that we can't take advantage of the new upstreams somewhere else for local packages, and have to do them ourselves.
[14:08] <nxvl> norsetto: what i think i need is someone who helps me find bugs to work on, not so how working on them, i can read an learn that :D
[14:09] <dfiloni> hi!
[14:09] <persia> nxvl: What kind of bugs do you like?
[14:10] <dfiloni> persia: yesterday I've updated wxwidgets2.8 package
[14:11] <persia> dfiloni: I saw that, but haven't had a chance to look in depth.  At first glance it looked good: unless I find something major, I'll upload it.
[14:11] <dfiloni> thanks persia
[14:11] <nxvl> persia: i like python and networking a lot, but since most of the services are on main, i think python :D i have already as for a mentor, that's why i'm giving norsetto a little more info about what i'm looking :P
[14:11] <nxvl> s/looking/looking for/
[14:12] <persia> nxvl: I'd recommend subscribing to the bug listings for a few python packages: that way you get an email when someone opens a bug.
[14:13] <nxvl> persia: yes, i've think on that but the hard think is to find those packages
[14:13] <persia> nxvl: For python, you can get a decent list of packages that might be interesting with `apt-cache rdepends python-central` or `apt-cache rdepends python-support`
[14:14] <nxvl> oh! i wil try that when i have a ubuntu on hands, now i'm on the university :P
[14:19] <persia> rexbron: genpo advocated.
[14:57] <rrittenhouse> Are there any major memory leaks in Trackerd or evolution ? For some reason my friends Gutsy machine here at work is responding to mouse movement but its consuming all 7.7GB of ram and the swap file
[14:58] <rrittenhouse> He did his updates yesterday - he also noticed trackerd is running when this happens and evolution was updated
[14:58] <persia> rrittenhouse: You might find more people likely to be familiar with current bugs reported in #ubuntu-bugs.  I remember seeing something about tracker, but I don't remember the details.
[14:59] <rrittenhouse> ty
[15:20] <Alfonsodg> dholbach: ping
[15:20] <dholbach> Alfonsodg: pong
[15:20] <Alfonsodg> dholbach: can we use priv please?
[15:20] <dholbach> Alfonsodg: sure
[15:29] <rexbron> persia: thanks :)
[15:32] <rexbron> Hey everyone! Genpo now has one ack and I looking for another: http://revu.tauware.de/details.py?package=genpo
[15:32] <bddebian> Heya gang
[15:32] <rexbron> hey bddebian
[15:33] <bddebian> Hi rexbron
[15:34] <geser> Hi bddebian
[15:42] <bddebian> Heya geser
[15:57] <nand`> This little package has also got his first ack and is waiting to take off! Could someone check at it please? Thanks! http://revu.ubuntuwire.com/details.py?package=ike
[15:58] <nand`> bddebian: Sorry, I don't remember, was it you who tried to package scorched3d?
[15:59] <mathiaz> soren: I've uploaded on new squid package.
[15:59] <mathiaz> soren: http://people.ubuntu.com/~mathiaz/packages/
[15:59] <bddebian> nand`: I am working with Fuddl on the Debian Games team on it yes
[16:00] <bddebian> Is Applications/Sound valid in a Debian menu?
[16:00] <nand`> bddebian: So did you find what was wrong last time?
[16:00] <bddebian> nand`: It works on i386 but he is still having issues on amd64 :(
[16:01] <nand`> bddebian: ah :/
[16:01] <persia> bddebian: Applications/Sound is good.  lintian in sid or hardy and linda in hardy understand the new menu structure.
[16:02]  * persia accepts a poke about a game, and has it *really* close to the top of the list now
[16:02] <bddebian> persia: Ah, OK, thx
[16:02] <bddebian> persia: Did you see that about scorched3d?
[16:02] <persia> bddebian: Wasn't that the poke?
[16:04] <bddebian> Oh, heh, no I was just answering nand` 's questions :)
[16:05] <persia> bddebian: Maybe, but I feel guilty enough to have put you off so long that I feel poked anyway: I just want to finish interdiffs and libopenal first :)
[16:09] <persia> dfiloni: I'm having trouble test-building.  I won't get it up tonight, but it looks good.
[16:09] <dfiloni> pesia: please send me a message when you upload the package or if you find a problem
[16:10] <persia> dfiloni: OK.
[16:17] <gnomefreak> can someone ack/comment on http://revu.tauware.de/details.py?package=iceape and http://revu.tauware.de/details.py?package=lightning-sunbird  On the iceape package i was told to ignore it by 2 people in here over the weekend (cant remember who) but source has right name ect.
[16:19] <jdong> whooooo!! Just checked my e-mail! thanks everyone!
[16:23] <gnomefreak> jdong: you can unsubscibe to bug i subscribed to you
[16:23] <gnomefreak> you to
[16:24]  * gnomefreak was having a stuck on stupid few minutes during replying on that bug
[16:25] <jdong> gnomefreak: I'm guessing once I start checking my bugmail I'll know what you're talking about :)
[16:25] <gnomefreak> yep :)
[16:25] <gnomefreak> sorry cant rmemeber bug number
[16:29] <bddebian> jdong: Congrats!
[16:29] <zul> jdong: congrats about freaking time ;)
[16:30] <geser> jdong: congrats!
[16:30] <bddebian> rexbron: genpo uploaded
[16:30] <jdong> bddebian, zul, geser, thanks so much!
[16:33] <Zelut> anyone have suggestions on where I can find tips on the preinst, prerm etc?
[16:43] <rexbron> bddebian: Thanks!
[16:45] <jdong> slomo: poke, sorry if I tripped one of your annoyance bones with gst-ffmpeg; you're the expert on it and I'll back off :)
[16:47] <DktrKranz> Zelut: you can try on www.debian.org/devel
[16:49] <rexbron> bddebian: Should I set the bug report to fix commited or wait until it leaves the NEW queue?
[17:09] <james_w> Hi, when doing a sync of a package that has a -0ubuntu1 version, is it important to check that the .orig.tar.gz matches the one for the -1 in Debian?
[17:12] <bddebian> rexbron: Fix committed should be OK, then Fix Released when/if it gets through ;-)
[17:12] <bddebian> james_w: Yes
[17:13] <jdong> how do you pass the -v required for merges into debuild -S?
[17:14] <jdong> I've tried shoving -v into a lot of places but debuild seems to happily ignore
[17:14] <james_w> jdong: doesn't it just work to pass it, i.e. debuild -S -v01?
[17:14] <jdong> james_w: ok maybe I'm just being retarded, lemme try again :)
[17:14] <james_w> bddebian: guess I got lucky then, thanks. I'll update the wiki page.
[17:16] <jdong> james_w: ok, PEBKAC, thanks :D
[17:30] <jdong> slomo: poke #2: Do you have intentions to import mpeg4ip from debian-multimedia to provide libmp4v2 in Hardy after the faad2 merge?
[17:50] <CyberMatt> hello
[17:50] <emgent> norsetto, !!!
[17:51] <norsetto> emgent: hi there
[17:51] <CyberMatt> i have a rather odd situation here
[17:52] <jdong> CyberMatt: try talking to her honestly and I'm sure you two can work it out
[17:52] <jdong> oh wait this insn't #relationship-therapy
[17:53] <CyberMatt> see i have this package i rather foolishly sent to debian mentors instend of revu
[17:53] <CyberMatt> and i've had enough of debian
[17:54] <CyberMatt> they don't seem to understand that i have a visual imparement so i need help with Makefiles
[17:55] <CyberMatt> so can i get it off mentors and on revu without pissing people off
[17:56] <jdong> hmm I wonder who here does work on debian mentors
[17:56] <jdong> for now I'd say just stick it on revu
[17:56] <jdong> and deal with removing from debian mentors separately
[17:56] <CyberMatt> ok
[17:56] <CyberMatt> thanks
[17:56] <james_w> if you just ignore it there it will be removed eventually.
[17:56] <jdong> no, thank you for contributing :)
[17:57] <CyberMatt> and another will anybody here snark at me for using cdbs
[17:58] <CyberMatt> all i said was it looked like it would be easier to do with my vision and ...
[17:59] <CyberMatt> big issue
[18:00] <james_w> CyberMatt: did you get the original problem fixed?
[18:01] <james_w> CyberMatt: is it libpam-paperauth?
[18:01] <CyberMatt> yes
[18:01] <CyberMatt> doesn't build
[18:02] <james_w> CyberMatt: the error looks odd to me. I can't immediately see what is causing it.
[18:03] <CyberMatt> i know that the problem is because it doesn't have the directorys to cp into
[18:03] <james_w> CyberMatt: yes, but I can't see that there is a 'cp' in the command that is failing.
[18:04] <CyberMatt> or somthing odd like that but when i create the dirs in Makefile it fails with a premission error
[18:04] <james_w> CyberMatt: it looks like it is just printing the intended destination file, meaning that it would try and execute it.
[18:05] <CyberMatt> odd as heck lets see what we can *see*
[18:06] <james_w> CyberMatt: do you have your work in progress source package that I poke at myself?
[18:07] <CyberMatt> i do
[18:07] <CyberMatt> should i just revu it
[18:09] <james_w> CyberMatt: I guess that would work.
[18:16] <\sh> re
[18:17] <persia> dfiloni: You're (perhaps) lucky.  I didn't get to sleep, and took another look.  I'm concerned about WX_CONFIG="/opt/wx/current/bin/wx-config --toolkit=gtk2 --unicode=yes --version=2.8 2>/dev/null ", as we don't usually install it in /opt.  (reference is in wxPython/wx/build/build_options.py).
[18:19] <CyberMatt> hang on problem with gpg
[18:30] <CyberMatt> ok its up
[18:31] <CyberMatt> should probably report a bug against seahorse as well
[18:33] <CyberMatt> because not letting me paste my 32 char passphrase and then crashing gpg is a bug
[18:34] <jdong> err.. having your passphrase on a clipboard is a not wise idea....
[18:35] <jdong> even Java applets in a web browser can obtain clipboard contents
[18:35] <CyberMatt> i clear when i am done
[18:35] <jdong> the point of an agent like seahorse is to act as a secure clipboard for your passphrase though
[18:36]  * persia agrees that pasting passphrases should be prohibited, although GPG crashing is definitely a bug.
[18:37] <jdong> yeah, do file the GPG bug
[18:39] <CyberMatt> it didn't crash exactly but when i disabled seahorse it would fail with an Unknowan error
[18:41] <dfiloni> persia: now I'm here
[18:41] <CyberMatt> i should change my passphrase though rightnow its my cats name fallowed by a random 32 characters that are stored on i flashdrive dedicated to this purpose
[18:42] <CyberMatt> something i know and something i have
[18:43] <persia> CyberMatt: Something you know and something you have is good.  Explaining what those are in a publically logged channel is less so :)
[18:45] <dfiloni> persia: do you think I should edit wxPython/wx/build/build_options.py file?
[18:45] <CyberMatt> changeing it now so if anyone could ever guess the 32 chars
[18:46] <persia> dfiloni: It looks like it was changed in 2.8.4.0-0ubuntu3.  If you want to do a patch system instead, I won't complain.  You might also want to look at wxPython/src/wx.pth.  I think the gtk stuff is all upstream, but it might be worth another check.
[18:47] <jdong> persia: +1 :D
[18:47] <dfiloni> persia: I'm looking current version of the package
[18:48] <persia> CyberMatt: I suspect the characters are limited to the lower 7 ascii bits, and I could likely even find 6 bits if careful.  32^64 isn't that big, and my computer counts fast :)
[18:48] <james_w> CyberMatt: on line 917 of 'Makefile' is the problem.
[18:48] <persia> dfiloni: lsdiff -z wxwidgets2.8_2.8.4.0-0ubuntu3.diff.gz might help point out places to check.
[18:49] <james_w> CyberMatt: I'm going to eat, but I'll work out where that comes from after.
[18:49] <jdong> persia: they keys are strengthened though ;-)
[18:50] <dfiloni> persia: thanks
[18:51] <CyberMatt> ill salt it
[18:51] <persia> jdong: ?  I have the code, it's just brute force, if I have the secret.  The model is typically that the secret key is the something you have, and the e.e. cummings poem transliterated into 31337 is the something you know.
[18:53] <jdong> persia: the passphrase is hashed then the hash is hashed, etc recursively like ~2000 times. It makes brute forcing by passphrase search take significantly longer than a traditional one-hash-cycle passphrase
[18:54] <CyberMatt> persia, you could break into my house and steal the flashdrive look at my cats id tag
[18:54] <jdong> persia: AFAIK it's easier/faster to search through the length of the hashed key than to iterate through passwords, unless the password is extremely trivial
[18:55] <persia> jdong: True.  Still dangerous to be a pronounceable word followed by the contents of electronic storage (especially pasted electronic storage)
[18:55] <jdong> persia: agreed :)
[18:56] <jdong> persia: it's far more dangerous that the data is at one part on the X clipboard, which is fairly accessible data by any application that happens to be running at the time
[18:56] <persia> CyberMatt: Right.  That's what I'm saying: I don't need to excise the information out of your brain to pretend to be you.
[18:56] <CyberMatt> oh an you'd  need to find the backup of my secret key or elese break into my computer
[18:56] <persia> jdong: True.  The clipboard is available to the entire net, whereas the flash drive is only available to local users.
[18:57] <jdong> CyberMatt: unfortunately until Apparmor/SELinux protects the system more it's probably a trivial exploit to read anything the local user has access to. the passphrase is a very important part of the security of your private key
[18:57] <jdong> </paranoid side>
[18:58] <CyberMatt> oh and there is the smalll matter of my revoke license
[19:00] <CyberMatt> which is soon to be printed out and stored in a secure place as soon as i get the darn printer to work
[19:01] <CyberMatt> might need to ask santa for a new printer
[19:02] <pwnguin> jdong: apparently mplayer now has samba support?
[19:02]  * pwnguin did not realize this last night when he said it was missing samba support
[19:02] <jdong> pwnguin: not surprising... mplayer seems to hack in support for everything imaginable
[19:02] <jdong> pwnguin: i.e. blinkenlights output modules :D
[19:02] <pwnguin> heh
[19:03] <jdong> pwnguin: my buddies loved -vo aa
[19:03] <pwnguin> yea
[19:03] <pwnguin> K-SLUG liked to put star wars on display with aalib
[19:05] <persia> blueyed: Would you mind checking dspam for the older releases as well?  I don't think it hits dapper, but Luca thought it might hit at least feisty.
[19:06] <SWAT> I'm getting a "dpkg-source: unrepresentable changes to source" when I "debuild -S". I have extracted the original files, added a debian dir etc. and edited the configure, makefiles and aclocal files. Any tips?
[19:07] <blueyed> persia: assigned it to myself. Will look into it later.
[19:07] <persia> SWAT: Did you intentionally touch a binary file?
[19:07] <persia> blueyed: Great,  Thanks.
[19:08] <Ubulette> is there a spec describing the recommended way(s) to install mime types and icons in ubuntu (something not obsolete)
[19:08] <SWAT> persia, no. I did use automake though
[19:09] <persia> Ubulette: Ubnutu follows the freedesktop XDG standards
[19:09] <persia> SWAT: Hmm..  Which file is it choking on?
[19:11] <SWAT> persia, ow wait, could it be, because depcomp is symlinked instead of copied into the directory? (automake installed the missing depcomp)
[19:12] <persia> SWAT: That might be it: symlinks don't diff well.
[19:13] <SWAT> is it ok to copy the debcomp file?
[19:14] <persia> SWAT: From where are you copying it, and to where?
[19:15] <Ubulette> persia, anything more dh_helper oriented ?
[19:15] <SWAT> from /usr/share/automake-1.10/depcomp to my package directory (top dir)
[19:16] <persia> SWAT: Check the licenses for that file and your program, but probably.
[19:18] <persia> Ubulette: Well, you need to generate some .desktop files, install them in the right directories (often /usr/share/applications), and call dh_desktop.
[19:19] <SWAT> persia, thanks for the info
[19:20] <Ubulette> persia, I've done that but result is weird. nautilus and firefox don't show the same launchers and icons are missed. I have to call gtk-update-icon-cache to fix nautilus, but i guess it's bad. I feel i'm not doing this the right way.. so I asked for specs ;)
[19:21] <persia> Ubulette: You likely need dh_icons then, if you're adding icons to the icon cache directories.
[19:21] <Ubulette> hmm, let's try that :)
[19:28] <jdong> persia: are syncs with debian automated or require poking (pkg with no ubuntu changes)
[19:29] <geser> jdong: till DIF semi-automatically
[19:29] <pochu> jdong: if they have no ubuntuX in the version number, then they are automated unless they are blacklisted
[19:29] <pochu> geser: semi?
[19:30] <persia> jdong: semi-automated: don't poke before DIF, but don't be surprised if there is a delay.  On the other hand, I don't think contrib and non-free are brought in by default, so syncs are accepted for those.
[19:30] <geser> pochu: an archive-admin needs to start a script
[19:30] <pochu> oh, right
[19:30] <jdong> debian recently adopted my gtkpod fix and also switched their packaging to use dpatch like our gtkpod-aac and I'd like to pull it into Hardy and merge two of its patches to gtkpod-aac
[19:30] <persia> (but the archive-admins will run the script every couple days, so don't bother them)
[19:30] <jdong> persia: ok thanks that's what I wanted to know
[19:30] <jdong> rough timeline
[19:31] <persia> jdong: That's non-free / multiverse, right?  If so, then requesting a sync likely won't annoy anyone.
[19:31] <jdong> persia: no, gtkpod is Free
[19:31] <persia> \o/
[19:31] <jdong> -aac is a Ubuntu specific package in multiverse
[19:32] <Ubulette> persia, so I need to put my icons only in /usr/share/icons ? not in /usr/share/icons/gnome/$${size}x$${size}/mimetypes ?
[19:32] <ScottK> jdong: Congratulations.
[19:32] <jdong> ScottK: thanks!
[19:32] <jpatrick> jdong: congrats! (even if I thought you already were motu)
[19:32] <persia> Ubulette: It depends on the level of integration you seek.  Some apps just drop them in /usr/share/pixmaps, but those don't tend to look as nice when DPI != 100
[19:34] <Ubulette> persia, upstream ships png icons in size 32 and 48 for file association (no svg). I want to associate a mimetype with an extension, those icons and all this working in firefox and nautilus
[19:36] <persia> Ubulette: OK.  I don't know anything about firefox associations.  For nautilus, it doesn't matter where the icons go, as long as they are in the icon cache and have unique basenames (or if non-unique, represent a unique icon, just different representations).  If you put them in the special icon directories for different sizes, nautilus will pick the appropriate size depending on context.  If you only drop one icon in pixmaps, that always gets use
[19:38] <Ubulette> persia, I did many things to make this work. 1/ foo.mime + foo.sharedmimeinfo + dh_mime 2/ .desktop files (1 main with a MimeType entry and several others without) + dh_desktop and 3/ icons manually + now dh_icons
[19:39] <imbrandon> moins all
[19:39] <geser> Hi imbrandon
[19:39] <imbrandon> heya geser
[19:39] <persia> Ubulette: All of those together sounds about right.  It's still not working?
[19:39] <zul> afternoon imbrandon
[19:39] <imbrandon> ello
[19:40] <jdong> persia: do I need to poke an archive admin about accepting something into -proposed or is that handled on a regular basis too?
[19:40] <Ubulette> persia, I have more apps proposed for my extension than the expected main one (in nautilus)
[19:40] <imbrandon> looks like i have successfully converted my step-father to ubuntu , today he asked abaout audacity
[19:40] <imbrandon> heh
[19:41] <persia> jdong: I think each archive-admin processes those on a certain day of the week, so it should happen on most days.  It sometimes takes a little longer if their workload is high.
[19:41] <jdong> persia: ok, cool, I'll let them do their thing then; just wanted to make sure I didn't need to do anything special on my end :D
[19:42] <persia> jdong: If it takes a really long time (> 1 week), you might subscribe the team to the bug, but it usually doesn't take that long.
[19:43] <persia> Ubulette: Hrm.  I seem to remember something funny about multiple MIME handling, but don't know enough to give you a good pointer.  Sorry.
[19:44] <Ubulette> persia, hmm, maybe left overs from my previous attempts not removed from the cache ?
[19:44] <Adri2000> RainCT: sorry, didn't have time to test it, but I'm doing it right now
[19:44] <persia> jdong: Oh, and the "really long time" never counts conferences on the release schedule: if anything happens during those times it's a bonus.
[19:44] <RainCT> Adri2000: ok :)
[19:44] <imbrandon> jdong: iirc its done 2 times a week , btw congrats
[19:44] <persia> Ubulette: Could be: sometimes the cache needs a couple manual whacks.
[19:44] <jdong> imbrandon: thanks :)
[19:46] <DktrKranz> blueyed, thanks for investigating on dspam. I think both Edgy and Dapper are affected. Mind looking at them too?
[19:46] <persia> Dapper too?  I thought /var/run didn't move to tmpfs until Edgy, but I may well misremember.
[19:47] <DktrKranz> That's why I'm not sure
[19:49] <Adri2000> RainCT: I hade to make a few changes, but looks like it works: http://dad.dunnewind.net/universe.beta.php
[19:49] <Adri2000> s/hade/had/
[19:50]  * ScottK recalls the same as persia (/var/run as tempfs in Edgy)
[19:50] <persia> Anyone like python, and want a fairly easy merge?
[19:51]  * ajmitch likes python
[19:51]  * RainCT also likes Python, but is working on a new package right now
[19:51] <persia> ajmitch: You can have clive if you want - I'd prefer to be the last uploader for fewer python packages, as I don't really know python.
[19:51] <DktrKranz> persia, Thanks for adding TEST CASE to that bug
[19:51]  * ScottK likes Python, but is not looking for new merges to do.
[19:51] <RainCT> Adri2000: great :). what was wrong?
[19:52] <persia> DktrKranz: Really, the order should have been "add test case", "upload", but at least it's there now :)
[19:52] <DktrKranz> hehe, at least get it before archive-admins notice them :)
[19:54] <Adri2000> -+      $comment = '';
[19:54] <Adri2000> -+      if(isset($comments[$package[0]]) $comment = $comments[$package[0]]
[19:54] <Adri2000> ++      $comment = \'\';
[19:54] <Adri2000> ++      if(isset($comments[\''.$package[0].'\'])) $comment = $comments[\''.$package[0].'\']
[19:54] <Adri2000> RainCT: ^
[19:55] <RainCT> Adri2000: ah ok. inside the echo I guess
[19:55] <Adri2000> yes, not always easy to figure out :s
[19:56] <blueyed> re: dspam. Does somebody has a dapper box at hands? (to see what "mount | grep /var/run" says)? For Feisty, I'll setup a virtualbox.
[19:56] <ScottK> blueyed: I have one.
[19:57] <ScottK> blueyed: varrun on /var/run type tmpfs (rw)
[19:57] <DktrKranz> persia, "varrun on /var/run type tmpfs" on Dapper too
[19:57] <ScottK> So I was wrong.
[19:57] <DktrKranz> blueyed, ^
[19:57]  * persia defers to actual tests
[19:57] <DktrKranz> :)
[19:58] <blueyed> Thanks. So I'll create additional patches for dapper and feisty then.
[20:16] <slomo> jdong: do it if you want
[20:16] <jdong> slomo: ok it's on my todo list, thanks :)
[20:17] <jdong> slomo: and sorry about the gst-ffmpeg thing
[20:18] <slomo> jdong: np :) it's just that ffmpeg is insane and gst-ffmpeg has the problem to use too much of it to allow easy updating to new APIs ;)
[20:18] <RainCT> can there be two homepages in debian/control? :P
[20:18] <jdong> slomo: yeah, I've worked with ffmpeg enough to understand how unreasonably impulsively they break the API
[20:18] <slomo> jdong: upstream probably will release the next releases without a ffmpeg snapshot but instead with the svn revision of ffmpeg one should use and a guide on how to update to another ffmpeg version (with the most common cases)
[20:18] <imbrandon> RainCT: i dont see why not , but the question begs as to "why?"
[20:19] <jdong> slomo: then again aging ffmpeg is annoying at cripping gstreamer-ffmpeg's abilities...
[20:19] <nixternal> dh_iconcache...what is it now?
[20:19] <slomo> dh_icons
[20:19] <nixternal> slomo: thanks
[20:19] <jdong> slomo: meh I don't have any major reason to prefer one or the other; if we want to do system ffmpeg for cleanness I'd be happy to provide the manpower to fudge with the API to get it to build though
[20:20] <slomo> jdong: i plan to get it build against the system ffmpeg in debian after next gst-ffmpeg release
[20:20] <slomo> ...and let's hope that this improves thing in one or another way ;)
[20:21] <jdong> slomo: mmmkay; from my tinkering with it yesterday it seemed pretty trivial, just tedious, to get it to build
[20:22] <slomo> jdong: you will get runtime issues
[20:22] <RainCT> imbrandon: just comma separated or what?   well, because it has a page on launchpad (with the bug tracker and such) and a .org website that's still under construction but might contain interesting information soon (and I don't want to link only that one since it might have downtimes). if it's a problem having just the launchpad page isn't a problem, but i'd prefer both :)
[20:23] <persia> RainCT: I don't think the tools support that currently.  Go for the .org site, and push upstream to finish for Hardy :)
[20:23] <jdong> slomo: is there a test suite somewhere for gst-ffmpeg? I could only think of making it decode my collection of sample movies in totem-gstreamer... of course it's an incomplete look at the abilities of gst-ffmpeg
[20:23] <jdong> slomo: but anyway, I'll leave that package in your caring hands ;-)
[20:24] <slomo> jdong: afaik no
[20:24] <ScottK> jdong: That would make it too easy.
[20:24] <RainCT> persia: ok, will use launchpad's one then.  I (and a LoCo mate) am upstream, btw :P
[20:24] <jdong> ScottK: :)
[20:25] <slomo> jdong: there's a minimal one in the tarball but i doubt it's very useful
[20:26] <jdong> logistics question, when I import mpeg4ip from debian-multimedia I'll almost certainly need to edit debian/control to get it to build... Do I upload it as a new package or are archive managers involved in the process?
[20:26] <slomo> jdong: at least not as useful as the testsuite of all other gstreamer modules ;)
[20:26] <persia> RainCT: Are you sure you can't be up a fair bit?  Homepage is widely user-visible :)
[20:26] <LaserJock> jdong: you upload anything yet?
[20:26] <slomo> jdong: you can get it synced i guess... and it will go through NEW if it's not there yset
[20:26] <persia> jdong: merges just get uploaded.  Only syncs require admins.
[20:26] <jdong> LaserJock: yeah, x264, gpac into hardy, gtkpod-aac into gutsy-proposed
[20:26] <jdong> persia: so what happens to new packages? they go to a queue right?
[20:27] <jdong> do I have to make contact with an archive manager?
[20:27] <persia> jdong: https://launchpad.net/ubuntu/hardy/+queue
[20:27] <ScottK> No.
[20:27] <persia> jdong: No.  Don't poke the archive admins :)
[20:28] <persia> (well, maybe the day before release freeze for a critical sync closing a massive security hole or something, but only then)
[20:28] <LaserJock> jdong: cool
[20:28] <RainCT> persia: well.. right now the site is down :S (it's hosted on a personal server at home of the other developer).  I'll ask him to move it to my hosting account, then it shouldn't be a problem
[20:28] <jdong> jpatrick / ScottK : Btw, seb128 asked us for backports to be explicit in the ack messages of the precise version of packages we approve :)
[20:28] <jdong> something like a rmadison line to go along with an ack
[20:28] <persia> RainCT: Most people won't see it until February or so, and only a few thousand before April.  No big rush.
[20:28] <ScottK> jdong: Makes sense.  Wilco.
[20:29] <jpatrick> jdong: ok
[20:29] <ScottK> jdong: So there are three of us processing backports now?
[20:29] <jdong> ScottK: yep, jpatrick joined backporters :)
[20:29] <jdong>   ktorrent | 2.2.3-0ubuntu3 |         hardy | source, amd64, i386, powerpc
[20:29] <jdong> oops
[20:29] <jdong> wrong screen
[20:29] <ScottK> jpatrick: Welcome.
[20:30] <jpatrick> ScottK: thanks
[20:30] <dfiloni> persia: you don't go to sleep tonight?
[20:30] <jpatrick> jdong: just filed my first request a few moments ago
[20:30] <persia> dfiloni: I failed :(
[20:30] <dfiloni> persia: I'm sorry
[20:30] <jdong> persia: for merging, how much of the changelog should be included in .changes? Full history? or since the previous ubuntu revision? What about for mpeg4ip which will be a new package in Ubuntu, the full changelog?
[20:31] <persia> jdong: -v since last version in Ubuntu
[20:31] <jdong> persia: ok, thanks :)
[20:31] <persia> jdong: Let me check on a new one: hold on...
[20:31]  * ajmitch waits for jdong to upload crack
[20:32] <persia> ajmitch: It's already happened :)
[20:32] <jdong> lol
[20:32] <ajmitch> that's what I was worried about
[20:32] <persia> jdong: Looking at a couple of the non-free new syncs it looks like for new packages, it's usually just the most recent changelog.
[20:33] <zul> jdong: did you use a pipe?
[20:33] <jdong> persia: mmkay
[20:33] <jdong> zul: was I supposed to? I thought injecting was preferred ;-)
[20:33] <zul> heh
[20:35] <james_w> CyberMatt: back. Did you use automake to create the Makefile.in from the Makefile.am?
[20:39] <gaspa> persia: i'm here.
[20:40] <persia> gaspa: If you like, you can have the clive merge: the patch was a quick adjustment to force python2.4 (as it didn't work with 2.5).  There's a new upstream, so it might be a sync.
[20:40] <TheMuso_> Hey folks.
[20:41] <LaserJock> man, chemists and their love for Java: "Wouldn't it be great to be able to compile code written in languages like FORTRAN, C, and C++ to Java bytecode?"
[20:41] <zul> LaserJock: no that would be evil..
[20:41] <gaspa> persia: oh, fine...
[20:41] <zul> and give me nightmares..
[20:41] <geser> LaserJock: answer with a big NO
[20:41] <persia> LaserJock: Isn't that the mono runtime?
[20:41] <zul> LaserJock: in fact fortran gives me nightmares
[20:41] <LaserJock> zul: oh come now ;-)
[20:42] <persia> gaspa: You want something harder?
[20:42] <gaspa> not for now.
[20:42] <gaspa> it could be fine, for my full-timetable
[20:42] <gaspa> :D
[20:42] <persia> gaspa: OK.  Good luck with clive :)
[20:42] <zul> LaserJock: im serious...im not going to be able to sleep tonight thanks..
[20:42] <gaspa> persia: thanks. i'll ping you if I need some infos.
[20:43]  * ScottK ponders jfortran, just to give zul the willies even more.
[20:43] <LaserJock> zul: so you wouldn't be impressed about the Ruby code the guy does that's uses a Java implementation of Ruby and Java wrappers around C++ code?
[20:43] <persia> gaspa: OK.  I may not be around much for a while, but feel free to send me email if you get stuck.
[20:43] <gaspa> persia: ok.
[20:43] <LaserJock> ScottK: isn't that like Fortress?
[20:43] <zul> LaserJock: i would...but fortran just scares me
[20:43] <gaspa> :d
[20:44] <LaserJock> zul: Fortran scares you?
[20:44] <LaserJock> it's not bad at all
[20:44] <zul> LaserJock: its just the fortran course i took, doesnt bring back happy memories
[20:44] <LaserJock> it's nice and fast
[20:44] <ScottK> LaserJock: I really try hard to stay far away from anything Java related, so I've no idea at all.
[20:44] <zul> interesting http://www.popularmechanics.com/technology/upgrade/4230945.html
[20:44] <LaserJock> ScottK: I know, but these chemists are crazy over it.
[20:45] <LaserJock> everything has to be Java
[20:45] <LaserJock> I think they are primarily concerned about portability
[20:46] <jdong> LaserJock: youv'e seen the unclean bash.org quote about that right?
[20:46] <persia> zul: Think of it as an opportunity to support a whole new class of users :)
[20:46] <ScottK> Then they should use Python.  Even more portable.
[20:46] <jdong> LaserJock: http://www.bash.org/?338364
[20:46] <persia> ScottK: Can I run python in my browser?
[20:46] <zul> persia: no thats ok...
[20:47] <LaserJock> ScottK: but but Python isn't Java
[20:47] <imbrandon> vb6 ftw /me hides
[20:47] <LaserJock> but they'll use Jython maybe
[20:47] <persia> imbrandon: I can't even get that to run on the intended target platform !
[20:47] <ajmitch> imbrandon: just leave
[20:47] <jdong> vb6 in multiverse!!11
[20:48] <LaserJock> somebody needs ops!
[20:48] <LaserJock> burn 'em!
[20:48] <bddebian> heh
[20:48] <imbrandon> vb6 code can be compiled with gambas ( mostly , only a very few translations ) hehe
[20:49] <ajmitch> jdong: careful
[20:49] <imbrandon> jdong: watch what you wish for , teh under the current rules i bet vb6runtimes can be packaged for multiverse ;)
[20:50] <jdong> imbrandon: uh oh :)
[20:50]  * zul stomps on imbrandon's head
[20:50] <imbrandon> lol
[20:50] <griffinc> I want to test a merge I am working on against the current package source in guty.  If I do apt-get source <packagename>, how can I use the *.dsc or the two debdiffs from my merge to test?  I have already tested in pbuilder but I want to test against the current source package.
[20:50] <LaserJock> hmm, hardy will look interesting: http://www.arsgeek.com/wp-content/uploads/2007/11/ubuntu-mockup1.jpg
[20:50] <imbrandon> i dident say i wanted or would or even encouraged it, but it *could* happen :)
[20:50] <griffinc> s/guty/gusty
[20:51] <imbrandon> eww where is that from LaserJock
[20:51] <LaserJock> imbrandon: ArsGeek is saying it's the first mockup
[20:51] <LaserJock> http://www.arsgeek.com/?p=2923
[20:51] <imbrandon> nasty
[20:51] <LaserJock> I dont know where they got it though
[20:52] <LaserJock> I know they were gonna try for orange/black
[20:52] <LaserJock> but the grey looks kinda nasty, IMO
[20:52] <imbrandon> if its not on the -art ML with a wiki its probably fake
[20:52] <imbrandon> ora wannabe
[20:57] <LaserJock> *sigh*
[20:57]  * LaserJock gets back to fixing his Fortran program
[20:58] <norsetto> imbrandon: hi ... did you get my emails?
[20:58] <nixternal> LaserJock: *)*#)@**!*! hola homeskillet!
[20:59] <LaserJock> nixternal: hiya!
[20:59] <imbrandon> norsetto: about the mentors ?
[20:59] <norsetto> imbrandon: indeed
[20:59] <imbrandon> norsetto: yea i just havent taken the time to reply yet today, but yes on all counts, the other 2 dropped off the planet and i can take the new one on
[21:00] <norsetto> imbrandon: good! thank you very much
[21:00] <imbrandon> np
[21:00] <CyberMatt> james_w, i used the upstream Makefiles from upstream and i assume there automake
[21:00] <ajmitch> hi norsetto, nixternal
[21:00] <norsetto> imbrandon: I will let him know that he can contact you
[21:00] <nixternal> howdy ajmitch
[21:00] <norsetto> hi ajmitch
[21:00] <nixternal> my merges are done for the month now :)
[21:00] <ajmitch> ScottK: do you want to add something about the debian python modules team to the MOTU python page?
[21:01] <ajmitch> you're involved in the team, so you're better to comment on it
[21:01] <imbrandon> norsetto: great
[21:01]  * ajmitch had someone asking him about packaging python stuff for ubuntu
[21:02] <ajmitch> I can bounce you his email if you want, too :)
[21:04] <james_w> CyberMatt: ok, you edited the Makefile.am file. This is the source for the Makefile.in file, which is then turned in to the Makefile by  the configure script.
[21:05] <CyberMatt> yes
[21:05] <james_w> CyberMatt: so you need to run automake (either during the build, or before creating the source package) to regenerate Makefile.in. Or you could just patch that file and send the better fix upstream.
[21:06] <james_w> CyberMatt: however the configure.in specifies automake1.6, which is not in a package, which makes things more tricky.
[21:07]  * persia suggests a port to a newer version of automake, in the interests of having fewer automaken around
[21:08] <dothebart> hy...
[21:09] <dothebart> is there a configured default recipient in ubuntu for cron mails?
[21:11] <persia> dothebart: I suspect you seek #ubuntu or https://answers.launchpad.net/ubuntu/
[21:13] <ScottK> ajmitch: Sure.
[21:14] <ajmitch> hello nealmcb
[21:14] <dothebart> persia: no, you're right. i want to add the default behaviours to the citadel debs, thats why i started asking here.
[21:14] <CyberMatt> is there a doc on how to port automake 1.6 to 1.8
[21:14] <ScottK> ajmitch: You mean on https://wiki.ubuntu.com/MOTU/Teams/Python
[21:15] <persia> dothebart: Citadel the BBS?
[21:15] <dothebart> the bbs and groupware.
[21:15] <dothebart> citadel.org
[21:15] <dothebart> it knows imap, pop3, webmail, groupdav...
[21:15] <ajmitch> ScottK: yes
[21:16] <persia> dothebart: Ah, so it schedules various jobs, and you want to forward the logs, or it requires scheduled jobs and you want to get the logs?
[21:17] <james_w> CyberMatt: I don't know of one, it's as much a case of run it and see.
[21:17] <dothebart> no. i do the debs. it acts as MTA. and i would like to add the aliases so these mails don't bounce.
[21:18] <dothebart> so if s.b. installs citadel on its ubuntu it is integrated into the system.
[21:18] <persia> dothebart: Ah.  The rules for how cron sends updates are sometimes frustratingly complex, but in almost every case it should end up being pushed to the local MTA addressed to a local user.
[21:18] <dothebart> as it may replace postfix.
[21:18] <dothebart> i just know the debian behaviour to ask for the recipient ;-)
[21:19] <persia> dothebart: so if you do the delivery to the local mbox or forward based on aliases, you should be fine.
[21:19] <dothebart> hm, which aliases file will the system operate?
[21:20] <dothebart> just the postfix ones?
[21:20] <persia> dothebart: That's usually up to the MTA, as far as I know.
[21:21] <persia> You can probably generate test cases for cron mail by using mailx as a MUA from a non-user account
[21:21] <dothebart> hm... the /etc/mail.aliases has a different syntax...
[21:22] <persia> dothebart: I seem to remember a big drive in Debian to coordinate the MTA handling several years ago: you might find leftovers on wiki.debian.org that may help.
[21:24] <ScottK> ajmitch: How's that?
[21:26] <ScottK> RainCT: stdin has done a simple script for 'dget'ing packages from Launchpad.  Please have a look and see about adding it to ubuntu-dev-tools. http://pastebin.ubuntu-uk.org/522
[21:27] <nxvl_work> imbrandon: ping
[21:27] <RainCT> ScottK: ok :)
[21:27] <ScottK> RainCT: Thanks.
[21:27] <imbrandon> nxvl_work: pong
[21:28] <nxvl_work> imbrandon: i have just receive the notice that you will be my mentor
[21:28] <imbrandon> ahh great :) welcome to the club
[21:28] <nxvl_work> thnx, i'm ready to start :D
[21:29] <imbrandon> shoot me an email and i'll give ya all my contact info and normal times i'm online etc
[21:29] <imbrandon> ( i'm on a bit early for me today )
[21:29] <pwnguin> 3pm is early?
[21:29] <imbrandon> and today my daughter turns 10 year old , man i feel old sometimes :)
[21:29] <imbrandon> pwnguin: for me yea
[21:30] <imbrandon> heh
[21:30] <pwnguin> man, even im not that far off ^_^
[21:30] <LaserJock> ScottK: you sure that works?
[21:30] <ScottK> LaserJock: No.  Just going by what stdin said.
[21:30] <LaserJock> ScottK: I wouldn't think it would in every case because you're just relying on LP Librarian having sequential numbers for the files
[21:30] <ajmitch> imbrandon: you can mentor me as well
[21:31] <imbrandon> LOL
[21:31] <LaserJock> ScottK: and having a certain order
[21:31]  * ScottK really has no idea, just saw a discussion about it on kubuntu-devel and thought it'd be a useful capability.
[21:31] <stdin> LaserJock: I checked several sources, and the ones I've seen do work like that
[21:31] <imbrandon> ajmitch: only if you can be my NM sponsor ? :)
[21:31] <imbrandon> hehe
[21:31] <ajmitch> ScottK: thanks for that
[21:31] <ScottK> ajmitch: No problem.
[21:31] <LaserJock> stdin: it might work in many cases, but we can't be sure
[21:31] <LaserJock> it's a decent workaround for now I gues
[21:32] <LaserJock> *guess
[21:32] <nxvl_work> imbrandon: congratulations!
[21:32]  * ajmitch will remove the team leader section there :)
[21:32] <ScottK> ajmitch: Please don't.
[21:32] <stdin> LaserJock: well that's what I was going for really, I just mad it because I needed a workaround for what I was doing just now
[21:32] <ajmitch> ScottK: why?
[21:32] <ajmitch> it links to my ancient wiki page
[21:33] <ajmitch> which I stripped most of the info from
[21:33] <ScottK> ajmitch: Well don't take out the bit about you being the leader.
[21:33] <nealmcb> soren: so what are you thinking about ubuntu-jeos-builder vs virt-install et al?
[21:33] <LaserJock> stdin: sure, I've got a bug for actually having dgettable URLs in LP, but I have no idea when that will get done
[21:33] <ajmitch> ScottK: but that requires me to actually lead :)
[21:34] <ajmitch> and I haven't exactly been doing that
[21:34] <jdong> LaserJock: aww no timeframe on that yet?
[21:34] <nxvl_work> imbrandon: mail sent
[21:34] <jdong> LaserJock: guess in the meantime I'll continue using my lpget scraper ;-)
[21:34]  * ScottK is on strike from leading right now, so you're better than me.  You just asked me to do something and I did it.  That's leadership.
[21:34] <ScottK> ajmitch: ^^^
[21:34] <ajmitch> fine
[21:35] <LaserJock> jdong: https://bugs.edge.launchpad.net/soyuz/+bug/130158
[21:35] <ubotu> Launchpad bug 130158 in soyuz "Launchpad should provide dgettable URLs" [Medium,Incomplete]
[21:36] <LaserJock> jdong: and it looks like some info is needed, mind providing it? :-)
[21:37] <imbrandon> nxvl_work: thanks
[21:38] <jdong> LaserJock: yeah I see that; don't have the time currently to set up such a testing env but I'll subscribe to the report
[21:41] <jdong> siretart: talked to slomo about importing mpeg4ip from deb-multimedia and he said go for it; did the initial tweaking to match control against Ubuntu, but because (1) x264 & faad2 had recent uploads that have yet to build (2) I don't know the impact the new libmp4v2-0 binary will have on its reverse-deps; I definitely don't wanna upload it to hardy. I'm thinking about uploading it to the motumedia PPA for now and waiting for the dust to settle to i
[21:46] <pochu> jdong: your message was cut ;)
[21:46] <pochu> Night folks
[21:47] <jdong> pochu: really?
[21:47] <jdong> stoopid irc :P
[21:47] <jdong> what word did it cut at?
[21:51] <geser> jdong: settle to i
[21:51] <proppy> jdong: waiting for the dust to settle to i...
[21:51] <jdong> "to iron out any kinks. Is that  ok with you?
[21:51] <jdong> "
[21:51] <proppy> geser: damn you're fast
[21:51] <jdong> siretart: ^^
[21:51] <jdong> *sigh* I blame irssi for that
[21:52] <geser> proppy: I wouldn't consider 3 minutes fast
[21:52] <proppy> geser: faster than me is fast !
[21:53] <jdong> 3 minutes is... never mind
[21:54] <proppy> jdong: :)
[21:54] <proppy> jdong: congratulations btw
[21:54] <jdong> proppy: thanks!
[21:55] <LaserJock> jdong: I just tested so don't worray about it
[21:55] <jdong> LaserJock: thanks
[21:56] <persia> Could somewith more proficient in bash than I please suggest how to make http://people.ubuntuwire.com/~persia/process-interdiff more robust?
[21:56] <persia> s/proficient/proficiency/
[21:57] <TheMuso_> persia: I'll take a look.
[21:57] <persia> TheMuso_: Thanks.
[22:00] <RainCT> ScottK: nice script, I'm making some additions to it and will commit then to my branch :)
[22:00] <ScottK> RainCT: Thanks stdin.  I didn't write it.
[22:01] <stdin> :)
[22:02] <siretart> jdong: sounds reasonable. that's btw what the PPA is intended for
[22:03] <jdong> siretart: okie :)
[22:04] <TheMuso> persia: For a start, I think it would make things safer if you put all your variables in double quotes, as well as everything you echo to stdout. I'd also be checking that valid data was entered on the command line. You do at the moment, but this could be further checked, in terms of number of arguments given to the script, as well as rudimentary checking of the given files validity.
[22:04] <TheMuso> I'd also provide a --help switch to display usage.
[22:05] <TheMuso> persia: If time/knowledge of how to do so is an issue, I'd be happy to help you make the changes.
[22:06] <persia> TheMuso: I'd agree with all of that.  I'd also like to check to make sure OLD_VERSION != NEW_VERSION, as that should be a debdiff, but I'm already stretching :)
[22:06] <persia> If you could, that'd be great.  This was mostly a proof of concept for the documentation I'm writing, but if it was made robust, it might be reasonable for ubuntu-dev-tools.
[22:07] <TheMuso> Ok, I'll take a poke at it.
[22:07] <persia> (don't forget to add your name if you make changes :) )
[22:07] <persia> TheMuso: Thank you.
[22:07] <TheMuso> Ok will do.
[22:08] <persia> TheMuso: I also am lousy at catching exceptions in bash: if you can figure out a way to call uscan --force-download if get-orig-source fails, that'd be a significant improvement in terms of scope.
[22:09] <TheMuso> persia: Ok.
[22:18] <griffinc> after working on a merge and creating the two debdiffs, as described in https://wiki.ubuntu.com/MOTU/Merging, what final tests can I do with these debdiffs before attaching to the bug report in LP?
[22:18] <griffinc> patch against the source package?
[22:19] <RainCT> ScottK: yeh, I've already told him by pm
[22:20] <geser> griffinc: look at them if they are sane (e.g. if all wanted changes are really listed in the changelog and if the listed changes are really in the debdiff)
[22:20] <ScottK> RainCT: OK.  Good.  Just making sure credit went where it's due.
[22:24] <griffinc> geser: ok, thanks.  can you apply them like a regular patch?  if so, in which order?
[22:31] <TheMuso> persia: Have you checked this script against packages with epoqs?
[22:31] <imbrandon> TheMuso: you forgot G3 too ( thats what I use )
[22:32] <TheMuso> imbrandon: I know, but I suspect not many people have them...
[22:32] <TheMuso> But I could be wrong...
[22:32] <imbrandon> you would be suprised :)
[22:32] <TheMuso> Well, I'll ed it it.
[22:32] <persia> TheMuso: No, and it will fail - It likely needs to have another match run to clean up 1: from the changelog.
[22:33] <TheMuso> persia: Yeah I thought as much.
[22:33] <persia> (unless I'm mistaken, and the epoch is also shown in the source package filenames)
[22:33] <TheMuso> No its not.
[22:34] <persia> Right.  In the first iteration I was depending on the well-formattedness of the interdiff filename, but decided that was just too broken to use.
[22:35] <TheMuso> Its also interesting in how there is more than one way to get info from a string. I tend to use cut a lot myself, for things like package names/versions, etc.
[22:35] <TheMuso> As I can't understand regular expressions to save my life at times.
[22:36] <persia> TheMuso: Ah.  I'm a big fan of sed/awk, but find bash easier for simple stuff: no call & pipe overhead.
[22:36] <persia> Well, if you can make the control syntax work, I'm more than happy to play with regexes :)
[22:38] <imbrandon> uh how would i regex match "# -start-" i'm totaly blanking ( no quotes )
[22:38] <TheMuso> persia: control syntax? What are you referring to exactly?
[22:38] <persia> imbrandon: '/#\ -start-/' or /\#\ -start-/
[22:39] <persia> TheMuso: program flow: break on error, check sane conditions, don't allow hijacking by overloading variables with control syntax, etc.
[22:39] <TheMuso> persia: ah
[22:40] <LaserJock> TheMuso: I'm a huge fan of cut :-)
[22:41] <TheMuso> LaserJock: Yeah so am I. If there are clear boundaries for the data you are trying to extract, IMO it can often make the code easier to read, as it then takes less time to work out just what you are trying to extract.
[22:42]  * persia admits regexes can be opaque
[22:42] <TheMuso> And while persia has a point re call overhead etc, when its a script, its not like its going to churn away on stuff for ages, for the most part at least.
[22:42] <SWAT> When I compile, it seems it can not find my config.status file, although everything seems fine (srcdir=. top_builddir=../ builddir=.) http://paste.ubuntu-nl.org/45167/  Any tips?
[22:42] <persia> TheMuso: Well, it depends, awk is fairly big, and not worth it for little things.  cut is probably not an issue: I'm just not familiar with the syntax.
[22:43] <TheMuso> persia: To each their own.
[22:43] <TheMuso> Believe it or not, I have actually written shell script code to do checking on .changes and .dsc files. Grep and cut are probably the two biggest tools used.
[22:44] <persia> SWAT: It's the cd && /bin/bash ./config.status Makefile.  You probably wanted to switch to a known directory, rather than the home directory of whichever user is executing the makefile.
[22:45] <jdong> persia: oh but regexes are the test of manhood ;-)
[22:45] <persia> TheMuso: awk has '/regex/ {transform}' syntax, which does both at once, but it's a bit of an odd language.
[22:45] <jdong> persia: awk and sed for tribal council
[22:45] <jdong> persia: and I guess cut is for the rebel force ;-)
[22:45] <persia> jdong: Maybe, but that was said about sendmail.cf, and nobody uses that anymore either.
[22:46] <jdong> persia: pfft sendmail.cf is just a legend used by UNIX old farts to scare young ones. Just like tar.gz software packages and compiling kernels.
[22:46] <TheMuso> I can certainly understand the power of regexes, but for me personally, when I read code, even though I have a vision impairement, I have to read it visually, and regexes simply don't easily translate to understanding where in the data stream a match is being attempted.
[22:47] <TheMuso> With pipes and cut, I can work out how the data is being extracted. It does help that I know cut's syntax as well.
[22:47] <jdong> TheMuso: regex aren't easy to master and look frightening at first glance indeed
[22:47] <jdong> TheMuso: they are also damn near impossible to debug
[22:47] <TheMuso> jdong: Yeah. I have known about them for ages, even the simple stuff, but if I can avoid them, I do.
[22:47] <jdong> TheMuso: if you ever want to have a stroke look at some of the regexes acidrip uses to get progress out of mencoder output
[22:47] <persia> TheMuso: It's not just a visual thing: regexes may recurse, and aren't necessarily related to data flow.  I tend to think in blocks, rather than streams, which helps.
[22:48] <SWAT> persia, I was planning to, but I just found it strange. I'll go fiddle some more
[22:48] <jdong> TheMuso: I recall back in Edgy or maybe Dapper mencoder *changed output format* and I had to patch acidrip's perl foo to match the new progress output
[22:48] <jdong> *shudder*
[22:48] <SWAT> if a package contains a autogen.sh, is it wise to run it, then create a source package and then package it? (SVN checkout)
[22:48] <TheMuso> jdong: heh
[22:49] <persia> SWAT: In your makefile you likely have cd $(SOMEWHERE); $(MAKE)..., but $(SOMEWHERE) isn't defined, which is confusing make.
[22:50] <TheMuso> persia: With awk, what does $NF represent?
[22:50] <SWAT> persia, thanks for time (I also concluded that). I just wanted to check that I wasn't making any basic beginner mistakes.
[22:50] <persia> TheMuso: The contents of the last field, where the field separator is denoted by the -F argument.
[22:51] <TheMuso> hm ok
[22:51] <jdong> persia: err $NF is number of fields
[22:51] <jdong> on the current line processed
[22:51] <jdong> I think.
[22:51] <persia> SWAT: You are, but that's the one :)
[22:51] <jdong> err wait does $NF dereference it?
[22:51] <persia> jdong: No, "NF" is number of fields.  This gets replaced by the actual number of fields before $ is referenced, so $NF ends up being the last field.
[22:52] <jdong> persia: ah, ok, makes sense :)
[22:52] <TheMuso> persia: What exactly is NEW_PKG_STR supposed to contain?
[22:52]  * persia admits awk is more opaque than regexes
[22:52] <TheMuso> oh... the package name and version...
[22:53] <persia> TheMuso: it contains a string that matches the directory name for the target version.
[22:53] <TheMuso> yep just worked it out.
[22:53] <LaserJock> PS3 is a PPC chip?
[22:53] <Burgundavia> power, yes
[22:54] <Burgundavia> not quite the same, but almost
[22:54] <LaserJock> huh, never knew that
[22:54] <Burgundavia> so is the xbox 360 and the wii
[22:55] <TheMuso> Yeah, most of the PowerPC instruction set anyway.
[22:55] <LaserJock> who makes the chips?
[22:55] <persia> IBM
[22:55] <Burgundavia> http://en.wikipedia.org/wiki/History_of_video_game_consoles_%28seventh_generation%29
[22:56] <blueyed> How would I create a hardy pbuilder? By backporting debootstrap and then "DIST=hardy sudo pbuilder create"?
[22:56] <jdong> pbuilder takes DIST=?
[22:56] <persia> blueyed: Either that, or dist-upgrade a gutsy one
[22:56]  * jdong sues for environment variable infringement :D
[22:56] <TheMuso> Ugh. Something breaks planet ubuntu at times.
[22:57] <TheMuso> At least in how my RSS reader shows some posts.
[22:57] <blueyed> jdong: in my .pbuilderrc, it uses DIST (taken from the samples)
[22:57] <tonyyarusso> I've noticed that
[22:57] <tonyyarusso> TheMuso: the feed disappears entirely from time to time
[22:57] <jdong> blueyed: cool.
[22:57] <jdong> blueyed: I thought I just invented a prevuism but guess there's prior art :)
[22:57] <bddebian> Later folks
[22:58] <TheMuso> persia: Well, I've made the script a little more robust, in quoting strings etc, but I need to run the script with -x enabled to see just how some parts of it shoudlw rok, but for that I need a package with an interdiff, so it'll have to wait for a bit.
[22:58] <blueyed> jdong: at the end of .pbuilderrc I have http://pastebin.com/m48eb23fd
[22:59] <TheMuso> s/shouldw rok/should work/
[23:00] <persia> TheMuso: You can generate an interdiff with the command on w.u.c/MOTU/Contributing.  Looking for a version difference for a -1 upload between gutsy & hardy should be not too hard.
[23:00] <LaserJock> blueyed: you can get backported debootstrap from -backports in case you were going to do it manually
[23:01] <TheMuso> persia: Ok, I'll look at it more later.
[23:01] <jpatrick> norsetto: ping
[23:01] <blueyed> LaserJock: oh.. I've thought I would have enabled -backports..
[23:01] <persia> TheMuso: Thanks a lot for helping with that.  My docs are almost done, but it'd be great to have an automated tool to help.
[23:01] <norsetto> jpatrick: yes sir?
[23:01] <mok0> re: pbuilder, I've seen references to cowdancer. Anyone using it?
[23:02] <jpatrick> norsetto: I have a new contributor (friend of mine) interested in me being his mentor, could you add to the mentor's file, his nickname: "outime"
[23:03] <norsetto> jpatrick: of course
[23:04] <TheMuso> persia: np
[23:05] <LaserJock> hmm, chopping up 9million lines of data isn't as easy as I'd like :/
[23:17] <jdong> superm1: opinions on bug 163928? upstream? Ubuntu?
[23:17] <ubotu> Launchpad bug 163928 in mplayer "mplayer rc2 (gutsy-backposrts) does not go down -vo list properly" [Undecided,New] https://launchpad.net/bugs/163928
[23:22] <StevenK> jdong: straceing ktorrent shows it doing a whole heap of futex stuff
[23:22] <StevenK> jdong: Like, constantly
[23:22] <jdong> StevenK: what version is this?
[23:22] <StevenK> jdong: 2.2.1-0ubuntu3
[23:22] <RainCT> ScottK, TheMuso: added stdin's script, please merge ~rainct/ubuntu-dev-tools/dev into ~ubuntu-dev/ubuntu-dev-tools/trunk :)
[23:23] <jdong> StevenK: can you mail me a copy of sample strace output?
[23:23] <StevenK> jdong: Sure. Give me a few so this build finishes
[23:23] <RainCT> good night all
[23:23] <jdong> StevenK: certainly
[23:27] <huats> good evening everyone
[23:28] <SWAT> what could be a soluation to a "/bin/bash: AMDEP_TRUE@: command not found" error when I try to compile? What am I doing wrong? (it also couldn't find am_fastdepCC)
[23:29] <huats> does anybody can explain me, how a package that I have been working on for merging (and signaled as so on dad) can be right now in hardy before I publish anything ? and most of all with some stuffs missing ?
[23:29] <LaserJock> huats: which package?
[23:29] <huats> alleyoop
[23:29] <slangasek> SWAT: buggy, hand-edited Makefile.in, or a configure script that was regenerated on a system without the requisite automake dependencies available
[23:29] <huats> it does not appear anymore in dad...
[23:31] <SWAT> slangasek, thanks. Should I manually edit the Makefile.in or regenerate it using 'automake'?
[23:31] <LaserJock> huats: it was a sync request
[23:31] <huats> a sync request ?
[23:31] <norsetto> huats: hehe, next time you should be quicker
[23:32] <StevenK> jdong: jdong@u.c?
[23:32] <LaserJock> huats: james_w requested a sync
[23:32] <huats> but some stuffs are missing in the debian package... like by instance (I know it is a detail) the maintener filed is wrong....
[23:32] <jdong> StevenK: yep
[23:32] <slangasek> SWAT: presumably, regenerate it using automake
[23:32] <LaserJock> huats: see bug #163613
[23:32] <ubotu> Launchpad bug 163613 in alleyoop "Please sync alleyoop 0.9.3-1  (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/163613
[23:33] <LaserJock> huats: why is the maintainer field wrong?
[23:33] <huats> LaserJock: not according the policy...
[23:33] <LaserJock> huats: it's not changed by Ubuntu
[23:33] <LaserJock> huats: so it doesn't need to have the Maintainer field changed
[23:33] <TheMuso> /c
[23:34] <huats> LaserJock: ok
[23:34] <TheMuso> If nobody else is merging RainCT's changes, I'll do them
[23:34] <huats> LaserJock: since it is a sync there is no need to change it ?
[23:34] <norsetto> huats: james_w is also the debian maintainer, so, probably he knows what he is doing
[23:34] <huats> norsetto: yeah I guess
[23:34] <LaserJock> huats: right. If we don't change the package then we don't change the package :-)
[23:35] <huats> norsetto: I was just surprised :)
[23:35] <huats> LaserJock: ok... first time that I face that :) Thanks
[23:35] <LaserJock> np
[23:36] <huats> LaserJock: let's say that as norsetto said I should have been quicker.. and the next time I'll check that before spending 1/2 h for nothing :)
[23:36] <norsetto> huats: forget what I said ....
[23:36] <huats> norsetto: never
[23:37] <huats> norsetto: I'll always remember that, and do I'll remind it to you before getting you a pizza in Toulouse
[23:37] <huats> :P
[23:38] <norsetto> :-S
[23:39] <norsetto> huats: I mean, about the maintainer, its wrong ....
[23:39] <huats> ok
[23:40] <norsetto> huats: was it correct that it was a sync?
[23:40] <huats> norsetto: so far yes
[23:40] <norsetto> huats: oh well, find another one then
[23:41] <huats> norsetto: I am doing that right now :)
[23:41] <StevenK> jdong: You Got Mail.
[23:41] <StevenK> jdong: Well, soon. :-)
[23:41] <norsetto> huats: what about balsa?
[23:41] <jdong>  StevenK thanks :) I'll investigate
[23:42]  * jdong stares at ktorrent svn/branches in disbelief
[23:42] <jdong> they slated a 2.2.4 for tomorrow.
[23:42] <huats> norsetto: oh there is my name on it already :)
[23:42] <jdong> sheesh they are racing with Gentoo Kernel Team on fastest revision cycle
[23:43] <StevenK> Like the Gentoo kernel team can release that fast.
[23:43] <StevenK> It takes time to apply racing stripes.
[23:43] <jdong> StevenK: have you been a gentoo user before?
[23:43] <s1024kb> norsetto: good morning my teacher. yesterday i had learned a lot here from a friend.
[23:43] <StevenK> jdong: Nope. Don't plan on, either. :-)
[23:43] <jdong> StevenK: there were times that gentoo-sources went through 3-4 revisions in a single day
[23:43] <StevenK> Hah
[23:43] <norsetto> s1024kb: hey selene
[23:44] <jdong> StevenK: some people had the build-all-updates command run recursively till empty outdated list :D
[23:44] <StevenK> Hah
[23:45] <jdong> StevenK: err regarding your strace, holy crap
[23:45] <StevenK> jdong: Hrm?
[23:45] <jdong> StevenK: can you disable DHT in the configuration if it is enabled?
[23:45] <StevenK> jdong: Lemme check
[23:45] <jdong> StevenK: it looks like something on a UDP socket is bombarding KTorrent with trash information
[23:46] <norsetto> s1024kb: I'll be gone soon, is there something you need to ask?
[23:46] <StevenK> jdong: Where do I disable DHT?
[23:47] <jdong> StevenK: settings->config->general
[23:47] <StevenK> jdong: Ah. DHT is disabled.
[23:47] <norsetto> huats: what did you do on that backport?
[23:47] <jdong> StevenK: hmm and you say no torrents are running?
[23:48] <StevenK> jdong: No torrents are downloading.
[23:48] <huats> norsetto: nothing yet
[23:48] <huats> norsetto: I wanted to finish the alleyoop before
[23:48] <jdong> StevenK: hmm odd. Could run like a wireshark while this is happening and see whats the source/destination/port of the network traffic?
[23:48] <norsetto> huats: ok, so you have done that ......
[23:48] <StevenK> jdong: Is the port 100002?
[23:49] <huats> norsetto: I will look at the backport tomorrow
[23:49] <jdong> StevenK: can't tell from strace
[23:49] <StevenK> Oh duh, of course you can't
[23:49] <norsetto> huats: well, nobody should take you that
[23:49] <jdong> StevenK: when you say no torrents are downloading, do you mean all torrents are stopped?
[23:49] <huats> norsetto: :)
[23:49] <jdong> StevenK: or are there things seeding ?
[23:49] <StevenK> jdong: Nope, about 20 are uploading
[23:50] <StevenK> Er, seeding. Right. :-)
[23:50] <jdong> StevenK: if you stop the uploads does traffic stop?
[23:50] <jdong> StevenK: wait bad sentence
[23:50] <jdong> StevenK: if you stop the uploads does the *cpu usage* stop?
[23:50] <StevenK> I figured that's what you meant.
[23:50] <StevenK> That'll take me a few, I've got to wait for a build to finish.
[23:51] <s1024kb> norsetto: no problem my teacher, i try to work with it myself. hope to see you in the afternoon if possible. Thanks. :-)
[23:51] <norsetto> s1024kb: good, I'm off to bed then
[23:51] <norsetto> g'night everybody
[23:52] <s1024kb> norsetto: have a good dream. :-)
[23:52] <huats> norsetto: good night