[00:38] <tumbleweed> ari-tczew: yeah, I plan to do some sponsorship
[00:39] <ari-tczew> tumbleweed: I'm glad for hearing this
[00:40] <tumbleweed> ari-tczew: hard to know until one gets there, though
[07:23] <dholbach> good morning
[07:25] <iulian> Morning dholbach.
[07:27] <dholbach> hiya iulian
[08:30] <jdong> imbrandon: Yeah my buddies and I were talking about it at work too! Congrats on the publicity!
[11:05] <bilalakhtar> Hey there, I need immediate help. Please see comment 4 of bug #595450
[11:05] <bilalakhtar> Do I need to do what is said in point 1?
[11:06] <bilalakhtar> I don't think so
[11:07] <slytherin> bilalakhtar: What command did you use to build source package?
[11:08] <bilalakhtar> slytherin: I used grab-merge
[11:08] <bilalakhtar> slytherin: for building, I used debuild
[11:08] <slytherin> bilalakhtar: yes, tell me exact debuild command you used.
[11:08] <bilalakhtar> slytherin: debuild -S -sa
[11:10] <bilalakhtar> slytherin: why should one care about that?
[11:11] <slytherin> bilalakhtar: I now got what the reviewer meant. You need to add details of the Ubuntu changes being retained in debian/changelog. Just saying 'merge form debian' is not sufficient.
[11:12] <bilalakhtar> slytherin: So isn't that mentioned in earlier entries?
[11:12] <bilalakhtar> It is, right?
[11:13] <bilalakhtar> I have done no change. I have reverted standards-version now as well. I am uploading the new debdiff
[11:13] <slytherin> bilalakhtar: You need to carryover that in latest changelog entry.
[11:13] <bilalakhtar> slytherin: but... See bug #595398
[11:13] <bilalakhtar> slytherin: and no one, AFAIK, does that
[11:14] <geser> bilalakhtar: one should be able to know what changes are left by reading only your merge changelog entry (without the need to look at the previous ones)
[11:14] <bilalakhtar> geser: you see http://launchpadlibrarian.net/50498114/debian-ubuntu.debdiff
[11:15] <bilalakhtar> this is realted to bug #595566
[11:19] <slytherin> bilalakhtar: The usual practice is to include the changes in latest entry. It might have been missed in some merges but that is not a norm.
[11:20] <bilalakhtar> slytherin: See, after the mom has done its work, it says
[11:20] <bilalakhtar> Merge from debian (). Remaining changes:
[11:21] <bilalakhtar> - SUMMARIZE HERE
[11:21] <bilalakhtar> remaining word is there
[11:21] <slytherin> bilalakhtar: Right. But you didn't summarize the changes in your changelog.
[11:21] <bilalakhtar> slytherin: REMAINING changes
[11:21] <bilalakhtar> slytherin: chanhges apart from merge
[11:22] <slytherin> bilalakhtar: Which means the ubuntu specific changes that are still relevant and hence carried over. You have to specify them.
[11:22] <bilalakhtar> slytherin: MERGE
[11:25] <bilalakhtar> slytherin: ok, I am doing that change as well.
[11:31] <bilalakhtar> ok?
[14:33] <dobey> cjwatson: hey. sorry. i am an idiot. i just uploaded a fixed ubuntuone-client to lucid-proposed though. :)
[14:52] <cjwatson> dobey: ok
[15:07] <ari-tczew> is DebianImport working?
[15:29] <fabrice_sp> !away > nobawk|away
[15:34] <dobey> fabrice_sp: hi
[15:35] <dobey> fabrice_sp: i uploaded a new mocker package to revu to make the description longer, and changed it to just use pysupport
[15:38] <fabrice_sp> dobey, ok. I'll have a look in a few minutes (I'm sponsoring debdiff right now)
[15:38] <dobey> fabrice_sp: great, thanks :)
[15:39] <fabrice_sp> by the way, revu is not like the archive: you don't have (and shouldn't) increase the version number at each upload:-)
[15:39] <fabrice_sp> dobey, ^
[15:41] <dobey> fabrice_sp: right. oh i guess it did, because dch -i does it automatically
[15:41] <dobey> :-/
[15:41] <fabrice_sp> don't worry: it's not a big deal
[15:41] <dobey> yeah i know
[15:43] <fabrice_sp> also no history: only one changelog entry
[15:43] <fabrice_sp> (so dch only, without -i ;-) )
[15:44] <dobey> yeah
[15:54] <fabrice_sp> dobey, no get-orig-source?
[15:56] <dobey> fabrice_sp: no. i thought we agreed on the compromise that uscan would fail now, given that it's a snapshot release, and there will be future tarball releases soon (which will make uscan work again)
[15:57] <fabrice_sp> for future, yes, but I really would like to have a way to generate the actual tarball by my own ;-)
[15:58] <fabrice_sp> it's really the only thing I can find, anyway, so i'll advocate it (I won't be the one that will upload it anyway)
[15:59]  * dobey wonders how that argument fits with gnome-keyring :)
[16:00] <fabrice_sp> ?
[16:02] <fabrice_sp> sorry, I don't understand your point
[16:12] <EricBa> Hello, is there a motu who has some time to review my package? It's already reviewed by one motu. My programm is a wallpaper changer for gnome. - http://revu.ubuntuwire.com/p/cortina
[16:15] <EricBa> It was already advocated by one reviewer.. so this won't take much time to review.
[16:24] <dobey> fabrice_sp: oh sorry. uscan is currently failing in gnome-keyring because the versioning is all messed up for some reason, and it was shipping snapshots from git for a period during the lucid cycle
[18:40] <ripps> FFMpeg is being held back by a bunch of packages, is this being worked on?
[18:41] <ari-tczew> hmmm... what-patch script seems to be broken
[18:43] <NorthernLights> Hi there
[19:01] <arand> ari-tczew: In what way? (Works on 10.10 here)
[19:01] <ari-tczew> arand: maverick
[19:02] <NorthernLights> I've got 2 packages on REVU. They are killrogues and synergy-plus. Could someone check them? I'm eager to get them in the repos.
[19:02] <NorthernLights> (especially synergy-plus)
[19:04] <arand> ari-tczew: My vm is on v0.99 here and is seems to work fine, fails in which way?
[19:05] <ari-tczew> arand: use in console: what-patch
[19:05] <ari-tczew> heh
[19:07] <ari-tczew> arand: http://ubuntu.pastebin.com/4HyhnMjb
[19:09] <arand> ari-tczew: A package using cdbs?
[19:09] <ari-tczew> arand: seems such as cdbs
[19:09] <ari-tczew> very lack in debian/rules :/
[19:10] <arand> ari-tczew: ~$ apt-file search /usr/share/cdbs/1/class/pear.mk -> dh-make-php: /usr/share/cdbs/1/class/pear.mk
[19:10] <ari-tczew> arand: have I to B-D on dh-make-php ?
[19:11] <arand> Why what-patch would need I don't really know though... Is that part of a possible patching scheme?
[19:12] <arand> Well, just installing it might do. I would assume this issue is isolated to this one weird package source though, if someone uses a standard patching scheme, it *should* work
[19:13] <arand> ari-tczew: The rather unhelpful error message there might very well be considered a bug in what-patch though... (ubuntu-dev-tools is the one to report against, I guess)
[19:14] <ari-tczew> arand: I'm preparing a security fix and package current now is FTBFS. first step I have to fix FTBFS
[19:16] <arand> Which one?
[19:17] <ari-tczew> arand: php-htmlpurifier
[19:17] <ari-tczew> arand: install dh-make-php fixes the warnings in what-patch. I see that package is just B-D on dh-make-php, so I need to continue investigating...
[19:18] <arand> Hmm, when I run what-patch on that I just get "patchless?"
[19:18] <arand> And I do know that I do not have the file it complains about for you
[19:19] <ari-tczew> arand: which file?
[19:19] <ari-tczew> pear.mk?
[19:19] <ari-tczew> possibly you've got installed dh-make-php
[19:19] <arand> Yup
[19:19] <arand> No I have not
[19:20] <ari-tczew> heh, interesting
[19:20] <ari-tczew> arand: ok, could you help me fix FTBFS?
[19:20] <arand> Well I could try, be warned I'm just a happy amateur .
[19:22] <arand> ari-tczew: It did build fine in my pbuilder... Is this arch-specific? Got a bug report?
[19:22] <ari-tczew> arand: I forgotten talk you: I'm working on php-htmlpurifier from karmic
[19:23] <arand> Ah, Karmic, I though it was Maverick ^_^
[19:23] <ari-tczew> arand: I'm working on maverick, but I'm going to patch php-htmlpurifier from karmic
[19:24] <arand> ari-tczew: So the ftbfs is on karmic? It does build for you on maverick?
[19:24] <ari-tczew> arand: I use: sudo pbuilder-dist karmic *.dsc
[19:30] <arand> ari-tczew: I Got some pbuilder setup to do..
[19:31] <ari-tczew> arand: sudo pbuilder-dist karmic create
[19:32] <arand> ari-tczew: Nah, I just fired up my karmic vm, but still need to add universe support etc.
[19:33] <arand> *to the pbuilder I had setup there already..
[19:35] <arand> ari-tczew: Hmm, so it tries to download something in the install process..?
[19:35] <ari-tczew> arand: maybe
[19:35] <arand> Err, the build process, rather..
[19:37] <kklimonda> but it built succesfully on lp before - can you paste the log somewhere?
[19:39] <ari-tczew> kklimonda: https://launchpad.net/ubuntu/+source/php-htmlpurifier/3.3.0-1/+build/1035152
[19:40] <arand> http://pastebin.org/339482 Is the relevant bit.
[19:40] <kklimonda> hmm..
[19:41] <ari-tczew> have got the same error
[19:42] <kklimonda> /build/buildd/php5-5.2.10.dfsg.1/pear-build-download - it looks like something leaked from the build done on the ubuntu buildd and now it's breaking this build..
[19:43] <ari-tczew> dunno, I'm upset
[19:43] <kklimonda> bug 513765 and debian bug 546164 seem to be related
[19:43] <ari-tczew> security fix done, and at the end FTBFS
[19:43] <kklimonda> ari-tczew: that's why fixing FTBFS is just as important as doing SRU and security work :)
[19:45] <arand> Hehe, if you do run the build with sudo, it works >_<
[19:45] <arand> "sudo debuild -b" that is :/
[19:45] <kklimonda> arand: it probably creates /build/buildd/ itself?
[19:46] <Laney> that's an rcbug in Debian
[19:46] <Laney> haven't read the context, fyi
[19:48] <ari-tczew> huh, lucid is build fine
[19:49] <arand> Yup, it created /build on my machine.
[19:49] <kklimonda> arand: it got fixed (or rather worked around) in 5.2.11.dsfg.1-1
[19:49] <kklimonda> eh
[19:49] <kklimonda> ari-tczew: ^
[19:50] <ari-tczew> kklimonda: php-pear?
[19:50] <kklimonda> yes (it's part of the php5 source package)
[19:50] <arand> So, that patch needs to go in first I guess ...
[19:51] <ari-tczew> arand: first we need to dig the patch
[19:52] <ari-tczew> kklimonda: where did you see that it;s fixed in 5.2.11.dsfg.1-1?
[19:53] <kklimonda> ari-tczew: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546164#44
[19:54] <ari-tczew> kklimonda: 44 comment says "Nah, it was not fixed."
[19:55] <kklimonda> ari-tczew: "It stopped being an RC issue because the tmpdir path is
[19:55] <kklimonda> now set to something under /tmp, which an unprivileged user can create."
[19:56] <kklimonda> which is why I've called it a work-around
[19:56] <ari-tczew> heh, but where is the patch?
[19:56] <ari-tczew> maybe it's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546164#15
[19:57] <kklimonda> nope, it doesn't seem to be this one (see the following comment)
[19:58] <kklimonda> you'll probably have to do a debdiff between our version and 5.2.11.dsfg.1-1 and look for /tmp - maybe it's something obvious
[19:58] <ari-tczew> f**king ftbfs...
[19:59] <kklimonda> funny thing is it probably builds just fine in ppa and official builders because they use /build/buildd/ path..
[20:00] <arand> I've been scanning the debian changelog, seems to be no mention there :(
[20:02] <ari-tczew> +1 ^^
[20:06] <ari-tczew> dunno, feel free to investigating the issue. today is friday, going out. have a nice weekend!
[20:19] <philsf> hi, I'm trying to recompile evolution, to test a new patch from upstream, but the patches are not being included. I'm just using 'dpkg-buildpackage' from the source tree, should I be using another program, or some specific parameters instead?
[20:19] <philsf> I don't see any mention to patches in the man
[20:24] <arand> philsf: run "what-patch" in the source dir.
[20:24] <arand> Should tell you which patch system is used
[20:24] <philsf> arand, I'm getting this from dpkg-buildpackage:  Trying patch debian/patches/94_trash_folder_eds.patch at level 1 ... 0 ... 2 ... failure.
[20:25] <philsf> (which is the name I chose for the upstream patch)
[20:26] <arand> Ah, right then it finds it, but fails to apply it, then I tend to try patching manually and see which bits break..
[20:26] <arand> SO which patch system does it use?
[20:26] <philsf> cdbs
[20:27] <philsf> it's probably made for a newer version that what's in lucid
[20:28] <arand> Then it should be a simple matter of "cdbs-edit-patch 94_trash_folder_eds.patch" And then you 'll get a temporary patch editing directory.
[20:29] <arand> Try to "patch p# < ~/yourpatch.patch" in there, which should result in rejects which you'll need to look at and resolve.
[20:30] <arand> ( -p# matching your specific patch)
[20:30] <philsf> arand, it already tried the patch in there, but the rejects seem to be the same as the diff itself
[20:31] <philsf> also, all chunks failed :/ how am I supposed to know what are the correct lines?
[20:31] <arand> philsf: Then start looking at the diff and the file it wants to patch, and figure out why it fails.
[20:32] <philsf> hmm, upstream says it's commited to 2.31.4+, lucid evolution is 2.28*
[20:32] <philsf> starting to look like a lot of effort for newbie me
[20:32] <arand> Is the context in the diff correct, does it try to add on top of things that don't exist in the old version, etc...?
[20:34] <arand> Solving a diff conflict could be everything from a walk in the park to impossible, since the things it changes aren't there in the first place and you'd need to add several patches in series to get it all working nicely...
[20:34] <arand> Or, it's simply a missplaced whitespace :)
[20:36] <philsf> oh boy
[20:36] <philsf> oh, nevermind
[20:36]  * philsf blushes
[20:36]  * philsf was trying the e-d-s patch to the evo tree
[21:31] <ripps> A couple packages (vlc, picard, gstreamer-ffmpeg, transcode) are holding back the ffmpeg upgrade. Do the packages just need to be rebuilt? or is it more complicated than that?
[21:31] <ripps> In Maverick
[21:32] <micahg> ripps: probably depends if the package itself needs adjustment for the new version of ffmpeg
[21:33] <ripps> Is there anyway I can help?
[21:33] <ripps> I can test builds in pbuilder if it will help
[21:34]  * micahg would think local rebuilds and testing would help
[21:35] <micahg> along with bugs filed with comments about what was done for the rebuilds (I know vlc already has a bug filed)
[21:35] <ripps> I need to push a rebuild of mpd in mpd-trunk. That's also holding it back
[21:43] <ripps> Hmm... it seems all the ffmpeg-0.6 packages aren't out yet. libavcodec-dev is still the svn snapshot from may
[21:45] <ripps> actually, the more I look at it, it seems that only ffmpeg-extra is out. I wonder what's holding ffmpeg
[21:47] <ripps> hmm... couldn't find libvpx... but it looks like it's in the repos.
[21:47] <micahg> ripps: libvpx-dev is holding it back
[21:47] <micahg> ripps: libvpx needs an MIR
[21:48]  * micahg should look harder next time :)
[21:48] <ripps> MIR?
[21:48] <micahg> !mir | ripps
[21:48] <ripps> ah
[21:48] <ripps> So we're waiting on Canonical?
[21:48] <micahg> ripps: no, anyone can file it
[21:49] <micahg> ripps: I don't see one filed against the package
[21:50]  * micahg looks harder for one
[21:50] <micahg> ripps: you can file the MIR if you wish
[21:53] <ripps> micahg: it's in the component-mismatch list
[21:54] <micahg> ripps: the package?
[21:54] <ripps> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[21:54] <ripps> It seems it's automatically added when a main package fails to build from a missing dependency
[21:55] <ripps> I suppose a MIR bug report might get people to hussle though
[21:55] <micahg> ripps: ah, ok, but I think an MIR is still needed
[22:01] <ripps> micahg: there, bug filed. let's hope it gets fixed soon
[22:04] <micahg> ripps: did you actually go through the checklist?
[22:05] <ripps> yeah, ubuntu-mir is subscribed to it
[22:06] <micahg> ripps: I meant this checklist: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[22:07] <ripps> micahg: yeah, libvpx looks like it would be fine...
[22:10] <ripps> I know the copyright in libvpx is complicated, but from what I've read, the latest revision of it from google should be gpl compatible
[22:11] <ripps> meaning it should be able to be packaged in debian and debian-based distros
[22:25] <ripps> Can someone who has an amd64 cpu pleas file an MIR for ia32-libs. It's dependency blocking libvdpau in maverick, which in turn is screwing with a bunch of media packages, like mplayer, from building correctly.
[22:30] <shadeslayer> ripps: what does ia32-libs have to do with a amd64 CPU and bug filing?
[22:30] <geser> it's pretty unlikely that ia32-libs gets moved to main
[22:31] <ripps> geser: okay, than a better question is why does libvdpau require it?
[22:31] <shadeslayer> well that too.. but what does it have to do with a amd64 cpu ? :P
[22:32] <geser> ripps: don't know, didn't look at the packaging
[22:33] <ripps> I have packages in one one of my ppa's failing because it can't pull the libvdpau dependency, because it ftbfs for amd64. Apparently because ia32-libs wasn't in main with it.
[22:34] <shadeslayer> ripps: for maverick libvdpau1 is built... i just installed it
[22:35] <ripps> shadeslayer: https://edge.launchpad.net/ubuntu/+source/libvdpau/0.4-5/+build/1790677
[22:35] <shadeslayer> hmm.. i have 0.4-3
[22:35] <ripps> yeah, that's the problem, it should be 0.4-5
[22:36] <ripps> The package pulls the -dev for 0.4-5, but finds only 0.4-3 and fails
[22:36] <shadeslayer> that means who ever packaged the vdpau library and/or filed a MIR for vdpau ignored the fact that ia32-libs was not in main...
[22:37] <geser> ripps: check how the package has changed between the version in lucid and maverick and if it can be undone
[22:37] <shadeslayer> geser: its a sync :P
[22:38] <shadeslayer> ripps: try #ubuntu-x too
[22:38] <geser> I see that Ubuntu-X is the bug contact for it, perhaps also ask in #ubuntu-x for input how to resolve this
[22:38] <shadeslayer> geser: slow :P
[22:39] <shadeslayer> ripps: is ia32-libs in debian main?
[22:39] <geser> yes, but better don't look at the packaging
[22:40] <shadeslayer> geser: hehe :)
[22:40] <shadeslayer> geser: ok well theres the problem
[22:40] <ripps> shadeslayer: well, it seems libvdpau changed alot since lucid. It used to depend on nvidia driver packages, now it's more independent
[22:40] <ripps> Also, ia32-libs is in amd64/ia64 on debian stable/unstable/testing
[22:40] <shadeslayer> geser: libvdpau is packaged for debian amd64 keeping in mind that ia32-libs is in main...
[22:41] <shadeslayer> ripps: http://packages.debian.org/sid/ia32-libs
[22:41] <geser> Debian main = Ubuntu main + Ubuntu universe
[22:41] <shadeslayer> geser: yep...
[22:41] <ripps> kinda complicated
[22:41] <shadeslayer> geser: but ia32-libs is in universe in ubuntu :P
[22:41] <shadeslayer> the sync should have been a merge :D
[22:42] <shadeslayer> but then it wouldnt compile without ia32-libs....
[22:42] <shadeslayer> geser: would it?
[22:42] <ripps> is ia32-libs only needed for ia64?
[22:43] <shadeslayer> ripps: just amd64
[22:43] <shadeslayer> ripps: see the build deps.. its written ia32-libs [amd64]
[22:44] <ripps> so... can ia32-libs be flagged for MIR?
[22:44] <ScottK> No
[22:44] <shadeslayer> ripps: it can,but like geser said... it wont get into main
[22:44] <ripps> so, how to fix libvdpau?
[22:45] <geser> unless the packaging of ia32-libs changed, it repackages the i386 debs for amd64, which isn't very liked by the security team
[22:45] <shadeslayer> no idea here... might want to try to build without ia32-libs,but im not sure that it will compile
[22:48] <ripps> Someone with a amd64 cpu should check whether ia32-libs can be worked around.
[22:48] <shadeslayer> ripps: sure thing ...
[22:49] <ripps> :0
[22:49] <ripps> :)
[22:55] <shadeslayer> ripps: its getting the deps...
[22:56] <shadeslayer> maybe i should disable universe...
[22:56] <ripps> lol
[22:56] <shadeslayer> ripps: :P
[23:17] <shadeslayer> ripps: build started
[23:18] <shadeslayer> bah.. fails after 2 secs
[23:24] <BlackZ> shadeslayer: what's the error?
[23:24] <shadeslayer> BlackZ: http://pastebin.com/tALj4g76
[23:25] <shadeslayer> BlackZ: come into #ubuntu-x
[23:26] <BlackZ> shadeslayer: why? what's going there?
[23:26] <shadeslayer> BlackZ: discussing the error with Sarvatt
[23:27] <shadeslayer> BlackZ: basically libvdpau has a dep on ia32-libs which is in universe
[23:27] <shadeslayer> which cannot be satisfied...