[00:00] <mok0> leonel: I patched it according to the bugreport
[00:11] <leonel> mok0:   Great ..
[00:12] <leonel> mok0: that means that it will be or  is merged to hardy ?
[00:12] <leonel> mok0:  that change don't affect  other DBs ?
[00:12] <mok0> leonel: it shouldnt
[00:12] <mok0> leonel: we'll have to test it
[00:13] <leonel> mok0: paul said that  the table  dbmail_aliases needed a change  ..
[00:22] <ScottK> leonel: I'm looking at hardy.  Please look at Dapper/Feisty/Gutsy.
[00:22] <leonel> scottK i'm on it
[00:22] <leonel> scottK do you have the LP bug # ?
[00:23] <mok0> leonel: I changed it
[00:23] <mok0> leonel: I mean the code, not the table itself
[00:24] <mok0> leonel:  I just uploaded the patch, it hasn't been merged yet
[00:25] <leonel> mok0: do you need help to test it ?
[00:25] <mok0> leonel: please
[00:26] <leonel> mok0:  let me finish with clamav  ..  and i'll test that diff
[00:26] <mok0> leonel: cool thx
[00:31] <kdub> can i license the packaging under the GPL if the software is licensed under apache?
[00:52] <blueyed> hexmode: I've commented php-xdebug, only minor issues left.
[01:03] <TheMuso> Nice. New nautilus shoudl see new windows for sbuild mounts no longer popping up.
[01:03] <soren> \o/
[01:03] <superm1> TheMuso, how'd that get resolved?
[01:04] <TheMuso> superm1: In the new upstream version. I'm not 100% sure that it is, but from the changelog, it looks to be.
[01:04] <TheMuso> We'll see once it arrives on my local mirror.
[01:05] <superm1> ah
[01:08] <protonchris> quick question:  I have a bug that I am about finished with.  After I attach the debdiff to the bug, what should the bug status be and should it still be assigned to me?
[01:10] <superm1> TheMuso, can you look at this FTBFS: http://launchpadlibrarian.net/11878063/buildlog_ubuntu-hardy-i386.gmyth_0.7%7Esvn915-0ubuntu1_FAILEDTOBUILD.txt.gz
[01:10] <superm1> i'm frazzled at why it failed
[01:10] <TheMuso> superm1: dpkg?
[01:10] <mok0> protonchris: status: confirmed, unassign yourself, subscribe u-u-s
[01:10] <protonchris> mok0: Thanks.
[01:10]  * TheMuso referrs superm1 to -devel.
[01:11] <slangasek> superm1: because soren broke the world, we should see a mass-giveback soon
[01:11] <superm1> slangasek, ah, someone should set that in /t
[01:12] <TheMuso> Theres always one dpkg issue per cycle. :p
[01:12] <jdong> superm1: the entire world is broken
[01:12] <jdong> superm1: sit still and wait for the deities to debootstrap you :)
[01:12] <jdong> (wait that sounded questionable)
[01:13] <mok0> wait... if dpkg is broken, how can he create a new dpkg package to upload :-P
[01:13] <TheMuso> jdong: ROFL! )
[01:14] <slangasek> mok0: because it's only the interaction with pkg-create-dbgsyms which was broken, and it's possible to bypass that in the source package
[01:14] <mok0> slangasek: phew
[01:14] <crimsun> soren: nice!  That's as nice as when I broke the toolchain and the archive with alsa-lib.
[01:14] <jdong> slangasek: I'm pretty sure it's possible enough to break dpkg enough to cause some interesting problems when trying to fix it? :)
[01:14]  * mok0 is not upgrading for a while...
[01:15] <TheMuso> crimsun: Howd you do that?
[01:15] <jdong> mok0: nonsense, as long as they didn't break dash, ar, and tar, you'll be fine ;-)
[01:16] <crimsun> TheMuso: oh, the gory details are somewhere in the ubuntu-devel IRC logs from a few releases ago.  Basically, broken path for 32-bit libs on 64-bit that screwed gcc.  Cue broken toolchain and archive for 64-bit arches.
[01:22] <TheMuso> crimsun: oh lovely
[01:23] <crimsun> heh, not precisely one of my brighter moments  :=)
[01:23] <TheMuso> heh
[01:25] <zul> crimsun: not as bad as breaking ata_piix at one point
[01:26] <crimsun> zul: :=)
[01:26] <zul> those were the days
[01:27] <TheMuso> I don't know whts worse. Broken IDe drivers, broken toolchain, or broken dpkg that affects users.
[01:28] <crimsun> it's fun and games until any one of them, and then it's just no fun and lots of beer.
[01:28] <zul> you just go whoops and move on
[01:31] <zul> and hopefully someone wont cane your ass :)
[01:33]  * Hobbsee gets out the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™
[01:33] <zul> hi Hobbsee
[01:34]  * Hobbsee pokes zul with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™ in greeting
[01:34] <emgent> argh
[01:34] <zul> ouch i already got beaten up today stop it..
[01:38] <pochu> What's wrong with this? http://revu.ubuntuwire.com/details.py?package=obex-data-server
[01:45] <leonel> scottK MANY differences  in  libclamav/pe.c   from  clamav.0.92.1 and  0.91.2   I guess the  patch should be  de diff between  0.92  and 0.92.1  right ??
[01:46] <slangasek> jdong: possible yes, but this community has lots of clever folks with plenty of experience recovering from self-induced disasters ;)
[01:46] <jdong> slangasek: that's always good :)
[01:46] <jdong> "This one time, at Debian camp..."
[01:52] <ScottK> leonel: 0.92 to 0.92.1 at most.  Even less if you can isolate the fixt.
[01:52] <ScottK> Fix
[01:53]  * asantoni is looking for an advocate for LP #190589
[01:53] <ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Wishlist,New] https://launchpad.net/bugs/190589
[01:54] <leonel> that's what I thought
[02:01] <nixternal> superm1: what's up?
[02:08] <ScottK> leonel: clamav 0.92.1 is about to be uploaded to Debian, I'll sync it from there once it is for Hardy.
[02:09] <leonel> scottK: Great   already have the gutsy patch  making the package to test it
[02:09] <leonel> scottK do you have the LP # ?
[02:12] <ScottK> leonel: I haven't filed a bug.  Feel free to file it and I'll accept your release nominations.
[02:12] <leonel> scottK ok
[02:15] <superm1> nixternal, okay take a look at atomic parsley
[02:15] <superm1> and blueproximity
[02:15] <superm1> those both looked good
[02:16] <nixternal> k
[02:26] <emgent> malone 189459
[02:26] <ubotu> Launchpad bug 189459 in meta-gnome2 "Please merge meta-gnome <IP_ADDRESS> (universe) from Debian unstable (main)" [Low,New] https://launchpad.net/bugs/189459
[02:27] <RAOF> What was that piece of CDBS magic to make dh_install list missing files again?
[02:28] <ember> --list-missing?
[02:28] <nixternal> superm1: blueproximity...has version 1.2.4, which hasn't been released yet, so he is using a SVN checkout, which makes his versioning wrong
[02:28] <superm1> nixternal, he is releasing it this weekend provided it is accepted
[02:28] <superm1> nixternal, he is the upstream
[02:28] <RAOF> ember: That'd be for dh_install.  There's some black magic to make cdbs add that to the dh_install calls.
[02:29] <superm1> he adjusted some thing i had asked him to regarding what needed to be in the .orig.tar.gz
[02:29] <superm1> and in case anything else cropped up he didnt want to make the upstream release until things got in here
[02:30] <nixternal> well, I will approve it, but will note not to upload until 1.2.4 is released, or he fixes the version so we can upload it..how does that sound?
[02:30] <nixternal> other than that, it looks good
[02:30] <superm1> yeah that sounds good
[02:30] <nixternal> groovy
[02:31] <superm1> just tell him to ping me or you to upload it once he "does" release 1.2.4 this weekend
[02:31] <superm1> in your revu comments
[02:32] <nixternal> superm1: umm...aren't we like a day or 2 away from freeze?
[02:32] <superm1> yeah...
[02:32] <superm1> lets see if he's on right now :)
[02:32] <superm1> HighNo, you here?
[02:33] <nixternal> FF on Valentines day, how romantic :)
[02:33] <superm1> look at the comments above ^
[02:33] <nixternal> ahh, HighNo, I am adding the comments to REVU as well...so when you are ready to release the final, get it into revu so we can double check it and upload it...looks good
[02:34] <leonel> scottK bug 191150
[02:34] <ubotu> Launchpad bug 191150 in clamav "possible integer overflow" [Undecided,In progress] https://launchpad.net/bugs/191150
[02:37] <TheMuso> superm1: Have your seeds been poked at?
[02:37] <TheMuso> superm1: By Colin?
[02:37] <superm1> TheMuso, no should they have been?
[02:37] <superm1> you mean regarding the alternate disk building?
[02:38] <TheMuso> superm1: No, re making seeds more modular.
[02:38] <TheMuso> Take a look at the Ubuntu seeds, and pull the latest bzr. You can work it out by looking at the STRUCTURE file.
[02:38] <superm1> TheMuso, i started to this weekend
[02:38] <superm1> and got rather confused by what should be put where
[02:38] <TheMuso> Right, perhaps the latest ubuntu.hardy bzr may help some./
[02:39] <superm1> as in some stuff has changed since the weekend?
[02:39] <superm1> or as in read the docs more, i likely overlooked things?
[02:39] <TheMuso> superm1: As in stuff has changed... a lot.
[02:40] <superm1> TheMuso, okay then i'll pull after revu party 08 is done tonight :)
[02:40] <superm1> TheMuso, you want to join?
[02:40] <superm1> its just me and nixternal right now
[02:40] <RAOF> Oh, dear.  CDBS was a mistake, it seems.  How do I fix the new "symlink all the docs" behaviour so that copyright will always be installed?
[02:40] <TheMuso> superm1: Unfrotunately, I have some higher priority work that needs doing, but I'll do what I can if I have time once I'm done with that.
[02:40] <superm1> TheMuso, sounds good :)
[02:42] <nixternal> hrmm, is it recommended to use * as an unordered list starter in debian/control?
[02:42] <nixternal> I thought it was recommended to use -
[02:42] <superm1> its because the pdf has a space i think
[02:42] <superm1> rhpot1991, ^?
[02:43] <rhpot1991> for that darn rtf?
[02:43] <rhpot1991> I couldn't get it to take by name cause of the space
[02:43] <nixternal> no no, in the debian/control file
[02:43] <nixternal> *iTunes-style metadata into .mp4, .m4a, .m4p, .m4v, .m4b files
[02:43] <nixternal>   *3gp-style assets (3GPP TS 26.444 version 6.4.0 Release 6 specification
[02:43] <nixternal>     conforming) in 3GPP, 3GPP2, MobileMP4 & derivatives
[02:43] <nixternal> that stuff
[02:44] <nixternal> I think it should be
[02:44] <rhpot1991> ah ok
[02:44] <nixternal>   - blah blah blah blah
[02:44] <superm1> oh is there a spec for that ?
[02:44] <nixternal> 2 spaces and then -
[02:44] <rhpot1991> I'll hit that up in a sec, let me get my laptop up
[02:44] <nixternal> superm1: not that I know of, but I remember getting a package shot back at me a couple of years ago in Debian because of it
[02:44] <superm1> nixternal, ah i see.
[02:44] <nixternal> just s/*/- /
[02:44] <superm1> well
[02:44] <nixternal> put a space after the -
[02:45] <superm1> s/*/\-/g
[02:45] <nixternal> TheMuso: can you second that?
[02:45] <nixternal> ie. not using * but - instead when listing out features in the control file
[02:45] <superm1> and if you need space than s/*/\-\ /g
[02:45] <TheMuso> nixternal: Sorry I haven't been paying attention.
[02:45] <nixternal> sleeping on the job :p
[02:47] <ion_> \s\u\p\e\r\m\1\:\ Why is everything in the substitution part escaped?
[02:48] <superm1> ion_, need to escape spaces and the - do you not?
[02:48] <nixternal> superm1: haha, I just noticed something, you don't want to s/*/\-\ /g
[02:49] <nixternal> more like s/\*/\-\ /g
[02:49] <superm1> haha
[02:49] <superm1> yeah
[02:49] <nixternal> oops, there went the control file :)
[02:49] <ion_> nixternal: Depends on the regexp dialect/.
[02:49] <nixternal> ion_: true
[02:49] <ion_> In any case, you don’t need to escape the chars in the substitution parameter.
[02:50] <nixternal> with that, you would get a pattern not found more than likely anyways
[02:53] <ScottK> leonel: Does the bug not apply to clamav 0.88?
[02:54] <rhpot1991_laptop> should I s/*/-/g in my manpage too?
[02:54] <leonel> scottK don't know yet   still fighting with gutsy
[02:54] <ScottK> OK.
[02:54] <ScottK> leonel: Did you look at Feisty yet?
[02:55] <leonel> scottK not yet
[02:57] <ScottK> leonel: I'm getting the 0.90.1 patch from etch-security for us.  That should work for Feisty (or very close).
[02:58] <ScottK> leonel: I'll take care of Feisty.  I get the Debian patch.
[02:58] <leonel> scottK Great
[02:59] <leonel> scottK the bug is in the function  cli_scanpe   does that is too on  0.90.1 ?
[03:00] <ScottK> looking
[03:01] <rhpot1991_laptop> nixternal: should I s/\*/- /g the manpage too?
[03:02] <nixternal> I was trying to look, but silly Konqi 4.0.1 decided to crash...looking now
[03:03] <rhpot1991_laptop> has the same *'s in the list there, I copied them over from the website
[03:03] <rhpot1991_laptop> its easy to do, so I can just do it as a precaution
[03:03] <nixternal> the manpages file looks good to me
[03:03] <rhpot1991_laptop> alright
[03:03] <nixternal> oh
[03:03] <nixternal> ummm
[03:03] <nixternal> I was looking at the wrong file
[03:04] <rhpot1991_laptop> AtomicParsley.1
[03:04] <rhpot1991_laptop> also for the record you need to escape in the match section, and not in the replace section, in perl at least
[03:09] <nixternal> I don't think you need the * or the - in a manpage when you use the .TP, as that indents it and brightens its color I believe...
[03:10] <rhpot1991_laptop> alright, uploaded the fixes
[03:11] <nixternal> groovilicious
[03:11] <nixternal> mmm, fergilicious!
[03:16] <ScottK> leonel: clamav 0.92.1 uploaded to Hardy.  I'm taking feisty now.
[03:17] <avoine> How a package can succefully build but not be in the archive?
[03:18] <ScottK> If it's removed?
[03:18] <avoine> how can I see if this append?
[03:18] <Hobbsee> avoine: failed to upload?
[03:18] <ScottK> Is it a new package that was recently uploaded for the first time?
[03:18] <ScottK> Still in New is another possibility
[03:18] <avoine> it's this one: https://edge.launchpad.net/ubuntu/+source/sugar-calculate-activity/16-0ubuntu2/+build/507905
[03:19] <avoine> no it's a update
[03:19] <avoine> the source are there: http://archive.ubuntu.com/ubuntu/pool/universe/s/sugar-calculate-activity/
[03:20] <avoine> but not the .deb
[03:21] <avoine> It could be that they not pass linda and litian test?
[03:25] <RAOF> Dear CDBS: please don't link to files in packages that need not be installed together.
[03:26] <Hobbsee> avoine: i've bugged cprov in #launchpad.  he'll be asleep, but hopefully he'll find out
[03:27] <avoine> thanks Hobbsee
[03:28] <cprov> avoine: what's the problem with that build ?
[03:28] <Hobbsee> apparently he isn't asleep
[03:29] <avoine> for some reason the packages have build successfully but the .deb are not in the archive
[03:30] <StevenK> avoine: It's in ACCEPTED. It will hit the archive soon.
[03:31] <StevenK> avoine: Check when it says (DONE), as opposed to (ACCEPTED)
[03:31] <cprov> avoine: https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=2&queue_text=sugar
[03:32] <avoine> ok
[03:33] <avoine> I understand know, thanks and sorry for the noise
[03:35] <avoine> Usually, how long does It for a package to get into universe after been build?
[03:36] <avoine> Ok I see, It's because of the translation process
[03:37] <StevenK> avoine: Roughly an hour, but could be more.
[03:39] <avoine> ok, this one have been build february 6
[03:39] <avoine> but It's the first time the po file are add I think
[03:39] <avoine> *files
[03:43] <cprov> avoine: it was probably waiting in the NEW queue since them. New binaries require manual approval from archive-admins
[03:43] <cprov> avoine: it's very unlikely that it would be related to the translations.
[03:43] <avoine> ok
[03:52] <ScottK> Doing all these updates for Feisty on a slow computer is a definite reminder of how nice triggers are.
[03:54] <kdub> so, i made a package (to resolve bug 116147) using pbuilder. i'm a little confused about how to upload to revu though
[03:54] <ubotu> Launchpad bug 116147 in ubuntu "[needs-packaging] tv_grab_dvb" [Wishlist,Confirmed] https://launchpad.net/bugs/116147
[03:57] <rhpot1991_laptop> nixternal: should I be worried that its taking a while, or did you get sidetracked with something else(which is OK, if thats the case)?
[03:58] <ScottK> rhpot1991_laptop: Bugging the reviewer isn't generally encouraged.
[03:58] <ScottK> If he found a problem, he'd have likely quit, so I'd guess no news is good news.
[03:59] <rhpot1991_laptop> ScottK: thats why I said its OK, trying not to be buggy and wasn't sure if I should keep paying attention or not
[04:00] <rhpot1991_laptop> just trying to figure out if I should keep checking back here or not, nothing more
[04:01] <ScottK> K
[04:04] <rhpot1991_laptop> whats the deal with the po folder in debian, I see an example with templates in debian and in debian/po
[04:47] <jcastro> mgunes: around?
[04:47] <mgunes> jcastro, hi, yep
[04:49] <ScottK> persia: Are you around?
[04:49] <ScottK> persia: Did your java goals get met already?
[05:08] <ScottK> keescook or jdstrand: Fixes for Bug #191150 for Gutsy/Feisty are in the bug.  Dapper will be along shortly.
[05:08] <ubotu> Launchpad bug 191150 in clamav "possible integer overflow" [Undecided,In progress] https://launchpad.net/bugs/191150
[05:10] <apetrescu> Hey, guys
[05:11] <apetrescu> I have a patch that I wrote for a package in Universe
[05:11] <apetrescu> I had two modify two files (a .h file and a .c file)
[05:11] <apetrescu> How do I properly create a patch file for these?
[05:15] <apetrescu> Anybody? :(
[05:20] <ScottK> apetrescu: File a bug in LP.
[05:21] <apetrescu> ScottK, file a bug for what?
[05:21] <ScottK> apetrescu: Make an updated package with a new revision number in debian/changelog
[05:21] <ScottK> The problem your patch solves
[05:21] <apetrescu> There's already a bug report for the problem my patch solves
[05:21] <ScottK> OK
[05:21] <ScottK> That step is done then
[05:21] <apetrescu> It's why I wrote it :)
[05:21] <ScottK> Makes sense
[05:22] <ScottK> Make the new package then with a new revision number in debian/changelog
[05:22] <ScottK> Then use debdiff to make a difference between the old and new packages.
[05:22] <ScottK> Attach that debdiff to the bus and subscribe ubuntu-universe-sponsors.
[05:22] <apetrescu> "Make the new package"? :( I am not actually a MOTU, I just asked here because it seemed the right place for it, I don't know much about Debian packaging.
[05:23] <\sh> grmpf
[05:23] <\sh> looks like level3 has problems to reach canonical...
[05:23] <apetrescu> level3?
[05:23] <ScottK> apetrescu: I thought you'd made the package you were updating.  My mistake.
[05:24] <apetrescu> ScottK, no, sorry, I just have the modified source code that I wrote, and I'm trying to create a patch that I can presumably add to the bug report
[05:24] <apetrescu> That's the usual process, right?
[05:24] <ScottK> Yes
[05:24] <StevenK> \sh: My route goes through level3 and reaches Canonical
[05:24] <apetrescu> If it's just one file I know I can use diff -u, but it's two files, so I'm not sure how to create one patch file for two files
[05:24] <ScottK> If you don't want to go to the trouble of packaging the patch, you can diff the old and new files with diff -ruN and attach tat
[05:25] <ScottK> tat/that
[05:25] <ScottK> Then add the tag 'patch' to the bug.
[05:25] <\sh> StevenK, 15:  ae-1-100.ebr1.London1.Level3.net (<IP_ADDRESS>)       41.144ms asymm 12
[05:25] <\sh> 16:  no reply
[05:25] <\sh> StevenK, and then it ends...
[05:25] <\sh> StevenK, while pipex, datahop it works
[05:25] <\sh>  5:  canonical-gw.datahop.net (<IP_ADDRESS>)            asymm  8  18.089ms
[05:25] <\sh>  6:  gw0-0-gr.canonical.com (<IP_ADDRESS>)                asymm 12  21.002ms
[05:26] <StevenK> 20. ae-1-100.ebr1.London1.Level3.net  0.0%    13  318.9 310.1 306.3 318.9   4.1
[05:26] <StevenK> 21. ae-2.ebr2.London2.Level3.net      0.0%    13  306.9 310.1 305.0 318.7   4.6
[05:26] <\sh> -ESTRANGE
[05:27] <ScottK> StevenK: Up for a requestsync feature request?
[05:27] <apetrescu> ScottK, how do I pass it if there's MULTIPLE files that need to be diffed?
[05:27] <apetrescu> Say file1.c and file1.h
[05:27] <StevenK> ScottK: I could be tempted to consider it
[05:27] <ScottK> apetrescu: Diff the dir
[05:27] <apetrescu> Oh, okay
[05:27] <apetrescu> So:
[05:27] <apetrescu> diff -ruN dir1 dir2 > my.patch
[05:27] <apetrescu> ?
[05:28] <\sh> StevenK, there could be 2 reasons: 1. my upstream ISP (with the level3 way) just fcked up it's BGP4 routing...OR...2. Dr. Who exists
[05:28] <ScottK> StevenK: If one has gone to the trouble of specifying the -k option, could requestsync perhaps not complain about the lack of the DEBEMAIL environment variable and just use the address from the GPG key?
[05:29] <StevenK> \sh: I'm guessing ae-1-100.ebr1.London1.Level3.net can't find it's way back, or the router next down the chain can't
[05:30] <\sh> StevenK, yeah some kind of broken BGP4 table...
[05:30] <StevenK> \sh: In other words, probably not level3's problem :-)
[05:31] <StevenK> ScottK: And how do you suggest we get the address, I'd rather not parse gpg's --list-key output
[05:31] <\sh> StevenK, do you know how to deal with public accessible core routers?
[05:31] <ScottK> StevenK: Implementation detail?
[05:31] <StevenK> \sh: I try not to :-)
[05:32] <ScottK> If it's hard, it's not worth the trouble.
[05:32] <StevenK> \sh: I prefer core routers to not be publically accessible
[05:32] <\sh> StevenK, well, public bgp4 query router ;)
[05:33] <StevenK> \sh: My BGP4 skills have since leaked out of my ears
[05:33] <\sh> I'm doomed
[05:34] <\sh> it's a level 3 problem
[05:34] <StevenK> With your netblock?
[05:37] <\sh> StevenK, looks like
[05:37] <\sh> inetnum:        <IP_ADDRESS> - <IP_ADDRESS>
[05:38] <\sh> StevenK, could you try to reach buildserver.homelinux.net?
[05:40] <StevenK> 22. <IP_ADDRESS>                       0.0%    10  392.8 379.3 323.3 490.7  54.7
[05:40] <apetrescu> ScottK, I went ahead and created the patch and attached it to the bug report :)
[05:40] <StevenK> 23. ???
[05:40] <StevenK> \sh: ^
[05:40] <apetrescu> Would you mind taking a quick look to make sure I did everything right? (It's my first time)
[05:41] <ScottK> apetrescu: Did you add a bug tag 'patch'?  That will get it noticed more quickly.
[05:41] <apetrescu> ScottK, yes
[05:41] <apetrescu> https://bugs.launchpad.net/ubuntu/+source/gnushogi/+bug/131017
[05:41] <ubotu> Launchpad bug 131017 in gnushogi "xshogi leaves gnushogi running after exit" [Undecided,New]
[05:41] <apetrescu> Tags:  patch
[05:41] <\sh> StevenK, so it's broken in bgp4 on isp site...
[05:42] <\sh> StevenK, or a router injects wrong routing informations (most propably the 172.30.21.xx site)
[05:42] <StevenK> Mmmm, right
[05:42] <ScottK> apetrescu: The next step would be to learn how to package the fix and make a debdiff.  It's past time for me to go to bed, so someone else would need to help you with that.
[05:43] <apetrescu> ScottK, say I learn how to make a debdiff on my own -- then what
[05:43] <apetrescu> >
[05:43] <apetrescu> *?
[05:44] <ScottK> Then attach the debdiff to the bug and subscribe ubuntu-universe-sponsors to the bug and someone will get to it and upload it.
[05:45] <apetrescu> Beautiful
[05:45] <apetrescu> Thanks, ScottK!
[05:45] <apetrescu> (This will happen even though i am not a maintainer for this package?)
[05:46] <\sh> StevenK, i'll talk to my upstream provider...needs to rush to the office now
[05:46] <ScottK> Yes.  We do team maintenance here, so it's all the same.
[05:47] <apetrescu> Excellent, thank you :)
[05:48] <apetrescu> Then I'll try to figure out the debdiff stuff on my own using documentation, and hopefully by tomorrow my very first patch will be up :D
[05:48] <apetrescu> Unless the package maintainer beats me to it with the .patch I already attached to the bug report, hehe
[05:57] <q_a_z_steve> Can someone help me fix my screen res? It used to be able to handle my 21" monitor, now not so much.
[05:57] <q_a_z_steve> *used to be able to handle... was under dapper, I've just installed gutsy
[05:59] <q_a_z_steve> help?
[06:00] <TheMuso> q_a_z_steve: #ubuntu for support.
[06:05] <warp10> Good morning!
[06:12] <TheMuso> damn kvm
[06:13] <RAOF> TheMuso: What's it not doing?
[06:13] <TheMuso> RAOF: Its locking a key occasionally when switching between machines.
[06:13] <RAOF> Oh.  You're probably thinking of kvm-the-not-virtualisation technology :)
[06:13] <TheMuso> No, a keyboard video mouse switch
[06:14] <TheMuso> i.e between physical machines.
[06:14] <RAOF> Yeah.
[06:15]  * TheMuso grumbles at KVM the virtualization stuff. What an annoying conflict.
[06:15] <TheMuso> namespace wise.
[06:15] <RAOF> Absolutely.
[06:18] <jscinoz> Evening everyone.
[06:21] <jscinoz> I'm working on two packages, urbanterror and urbanterror-data, both are on revu, and currently there is a problem with urbanterror requiring its own embedded libjpeg62 (attempts to patch it to use the system library cause the game to render incorrectly), emmet.hikory recommended bringing the topic up for discussion here and to see if we can get any additional motu's to accept the use of the embedded library, the package in question
[06:21] <jscinoz>  is located at http://revu.ubuntuwire.com/details.py?package=urbanterror
[06:27] <rhpot1991_laptop> if I have a note in a template I am trying to display to a user after they install a deb, how should I call that to display in postinst?
[06:28] <rhpot1991_laptop> like you call a string with db_get, what do I use to call my note
[06:33] <HighNo> rhpot1991_laptop: hi again. just for my understanding - the installation can be localized too?
[06:33] <rhpot1991_laptop> huh, not sure what you are asking about, might be thinking of something you talked to someone else about?
[06:40] <HighNo> rhpot1991_laptop: you were mentioning a po folder within debian dir - po is not for translations there?
[06:40] <rhpot1991_laptop> ya I think it is, though I'm a little confused about it, trying to copy an example to get a notice to show up
[06:41] <HighNo> btw, as you mention 'example' - I've heard there is a packaging example 'hello world' available somewhere?
[06:44] <rhpot1991_laptop> there is, though I don't think it does any debhelper
[06:44] <rhpot1991_laptop> superm1 pointed me at one of his that I am trying to copy off of
[06:44] <rhpot1991_laptop> s/debhelper/debconf/
[06:45] <vemon> hmh. how should i call the get-orig-source target in debian/rules? like this?: debian/rules get-orig-source
[06:46] <RAOF> Exactly.
[06:46] <RAOF> Or ./rules get-orig-source, or my-package-dir/debian/rules get-orig-source (get-orig-source should be callable from any directory)
[06:57] <jscinoz> I'm working on two packages, urbanterror and urbanterror-data, both are on revu, and currently there is a problem with urbanterror requiring its own embedded libjpeg62 (attempts to patch it to use the system library cause the game to render incorrectly), emmet.hikory recommended bringing the topic up for discussion here and to see if we can get any additional motu's to accept the use of the embedded library, the package in question
[06:57] <jscinoz>  is located at http://revu.ubuntuwire.com/details.py?package=urbanterror
[07:02] <RAOF> If anyone is interested in useful, keyboard-driven desktop-navigation bling I'd encourage you to revu gnome-do and do-plugins (http://revu.ubuntuwire.com/details.py?package=gnome-do)
[07:04] <RAOF> The main package should be good to go; I've addressed persia's concerns, and the plugins should be easy.
[07:06] <HighNo> If upstream has created an AUTHORS file or something alike, do I still need to create a debian/copyright file or can I link somehow to the upstream version?
[07:06] <RAOF> HighNo: You *always* need a debian/copyright.
[07:07] <RAOF> The AUTHORS file can be a useful reference, but they're often out of date.
[07:08] <emgent> heya
[07:09] <HighNo> RAOF: that's interesting and good to know. I was just reading the new UpsteamGuide and thought about howto improve my upstream package.
[07:11] <AnAnt> persia: thanks
[07:11] <RAOF> HighNo: Right.  The single biggest thing you can do is to make sure *every* file has a license header, preferably one of the GPLs.  It takes a lot of other craziness to use up the goodwill generated by easy licensing.
[07:11] <RAOF> NOTE: my priorites may be skewed by having to fight licensing issues with every package I've recently touched.
[07:35] <jonnymind> Hello
[07:35] <jonnymind> I receive this log from launchpad:
[07:35] <jonnymind> http://launchpadlibrarian.net/11878791/buildlog_ubuntu-hardy-ia64.falconpl_0.8.8-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:36] <jonnymind> where a new error suddenly appeared:
[07:36] <jonnymind> Error: parsed ddeb section or priority is empty
[07:36] <emgent> debian #434725
[07:36] <ubotu> Debian bug 434725 in xsupplicant "xsupplicant - FTBFS: error: header file <iwlib.h> is required for Xsupplicant" [Serious,Fixed] http://bugs.debian.org/434725
[07:37] <AnAnt> I need to discuss the matter of native packages, what's the problem with them ?
[07:37] <Hobbsee> jonnymind: known problem.  it'll get given back
[07:37] <jonnymind> Hobbsee: thnx; in other words, I have not to worry?
[07:37] <Hobbsee> yeah
[07:38] <jonnymind> Hobbsee: Ok, thanks. Anyhow, I'll stick around in case you need me.
[07:38] <AnAnt> I am making packages for UbuntuME (a derivative distro) artwork, why is it not liked that the packages be native in that case ?
[07:39] <RAOF> AnAnt: Is that artwork only ever interesting for a Debian system?  It seems the answer would be "no", so it shouldn't be a native package.
[07:41] <AnAnt> RAOF: ubuntu's artwork is native
[07:43] <LaserJock> most artwork packages are native
[07:44] <HighNo> hm, offtopic: does anyone know how to link to a certain heading/section or how to set an anchor in the wiki?
[07:44] <AnAnt> RAOF: besides, it maybe only interesting for  a Ubuntu system, for example, the GDM theme has the word "ubuntume", would that be of interest for a non-Ubuntu (or actualy non-UbuntuME) system ?
[07:46] <HighNo> never mind - reading helps... *lalala* ;-)
[07:52] <goobsoft> Is there more documentation for python-support other than "man dh_pysupport"?
[07:55] <slomo__> ScottK: saw you uploaded poppler-data to revu... you know that it's not possible to redistribute it (ugly adobe license)?
[07:56] <Hobbsee> oh, ewww, not more poppler?
[07:59] <AstralJava> Anyone of the launchpad-buildd-admins present? I've got an issue with buildd on a package (gigedit) that builds fine on my Hardy setup.
[08:04] <dholbach> good morning
[08:04] <LaserJock> morning
[08:04] <dholbach> hey LaserJock
[08:07] <rhpot1991_laptop> if anyone can look at http://revu.tauware.de/details.py?package=mythexport and leave me a comment about why I never get my debconf note that would be great.  Thanks.
[08:15] <\sh> dholbach, moins...could you fix the sentence: "where we could dial in using Kernel" with "where we could dial in using Kermit", pls? :)
[08:16] <dholbach> \sh: done
[08:16] <\sh> dholbach, thx a lot :)
[08:19] <HighNo> \sh: now that would be killer feature or not?
[08:19] <HighNo> dial-in kernels :-) hehe, Kernel panic? no prob, Linus' gonna call in :-)
[08:20] <\sh> HighNo, in the beginning there was only the kernel...even with kermit, you needed to advice the kernel to recognize your serial interfaces correctly ,-)
[08:21] <HighNo> I even guess it would be possible to create something like a hardend mini-environment containing a tcp/ip subset and network drivers. just for remote debugging purpose :-)
[08:22] <HighNo> \sh: I know although I didn't use linux back at those days
[08:23] <\sh> HighNo, these days there was a software, running as client and server, which could tunnel an ip session over a normal plain dial in line (without having ppp or something like that)
[08:24] <emgent> heya people :P
[08:24] <HighNo> \sh: you mean slip, right?
[08:24] <\sh> HighNo, no slip ...:)
[08:25] <HighNo> \sh: more like rawIP as it has been later on with isdn lines?
[08:25] <\sh> HighNo, slip you used when you had non-pap/chap auth for ppp...you logged in via normal unix login and started ppp on the other side..
[08:26] <\sh> HighNo, I need to get the name of the software...a cool technology these days
[08:27] <HighNo> \sh: just checked slip - it does exactly that - putting the raw packets on the line. the only change is that there is a packet end marker being included which has to be escaped if it would be in the packet. Other than that it is just raw IP
[08:27] <\sh> HighNo, yes..but it wasn't slip :)
[08:28] <HighNo> \sh: btw, putting raw packets on the line - would one call that still a tunnel?  :-)
[08:28] <\sh> HighNo, this didn't work..we had to call in via kermit, on a terminal server which was connected via serial to the sun
[08:30] <\sh> HighNo, so there was no tcp/ip or raw packets over this line...I think it used mosaic or something on the remote server and was pushing the data as plain ascii back to the client where a mosaic was started and received the data via lo0 ... you had to map some local ports actually...
[08:30] <HighNo> \sh: yeah, that's the usual way. All it misses is a way to reboot that thing - wait, rebooting it was just impossible for pc's. One can reboot a hanging sun via the serial interface, right?
[08:31] <HighNo> \sh: ahh, so you are talking plain terminal transfer then
[08:31] <\sh> HighNo, you can jump into the bootloader of a hanging sun, yes
[08:31] <\sh> HighNo, yepp
[08:31] <HighNo> \sh: that is such a cool feature. I miss it on my pc every time I see a sun :-)
[08:32] <\sh> HighNo, well, difference between good and bad hw/bios design ;)
[08:34] <HighNo> \sh: I know. I am wondering if linuxbios would change things. I never had a machine to try that. It would remind me of old c64 times. Turn it on, wait 2 secs, there you go :-) (I know that linuxbios is no complete linux system...)
[08:35] <\sh> ok...meeting
[08:55] <Laibsch> good morning
[08:56] <Laibsch> I wonder how to include original source for the upload to my ppa.  I am sure it must be a switch to debuild, but the man page says nothing about it
[09:00] <CarlFK> how do I find what is causing this: $ debchange --nmu updeb.carl
[09:00] <CarlFK> utf8 "\xF6" does not map to Unicode at /usr/bin/debchange line 963, <S> chunk 1.
[09:04] <CarlFK>   * Add a patch from J�rn Reder to fix an issue with filters that have long
[09:04] <HighNo> Laibsch: Include the source where? in the .deb file?
[09:05] <Laibsch> in the upload
[09:05] <Laibsch> I think it is the -sa switch
[09:05] <Laibsch> Unfortunately, not mentioned in "man debuild"
[09:06] <HighNo> Laibsch: hm, could be, cause creating a signed .changes file is debuild -S -sa
[09:06] <HighNo> Laibsch: that would include the source
[09:07] <HighNo> Laibsch: man  dpkg-buildpackage  - the debuild options go there
[09:08] <Laibsch> well, the man page should mention that for complete reference you should also look into $foo
[09:10] <HighNo> Laibsch: it does - hidden somewhere somehow: line 4 of description: "passed on).  Parameters can be passed to dpkg-buildpackage, li..."
[09:28] <geser> good morning
[09:28] <dholbach> hey geser
[09:28] <geser> Hi dholbach
[09:32] <psavva> hi all
[09:32] <psavva> got a question if anybody knows anything about ffmpeg ???
[09:32] <crevette> hello people
[09:33] <crevette> http://revu.tauware.de/details.py?package=obex-data-server is broken
[09:33] <psavva> hey crevette
[09:33] <crevette> can someone solve this
[09:33] <crevette> hello psavva
[09:33] <goobsoft> I've used ffmpeg before
[09:34] <psavva> getting a error message
[09:34] <psavva> Unknown encoder 'h264'
[09:34] <psavva> got ffmpeg from mediabuntu repo
[09:34] <goobsoft> What command are you issueing?
[09:35] <goobsoft> ./configure --enable-libmp3lame --enable-liba52 --enable-libgsm --enable-libogg --enable-libtheora --enable-libvorbis --enable-libfaac --enable-gpl --enable-libx264 --enable-pthreads
[09:36] <goobsoft> use that before making
[09:36] <psavva> ffmpeg -i INPUT -s 176x144 -vcodec h264  -ar 48000 -ac 2 -acodec aac -r 25 OUTPUT
[09:36] <goobsoft> sudo apt-get install liba52-dev libdts-dev libgsm1-dev libvorbis-dev libxvidcore4-dev libdc1394-dev libfaac-dev liblame-dev libx264-dev libfaad2-dev libtheora-dev libsdl1.2-dev
[09:36] <psavva> from src
[09:36] <goobsoft> need to get the dependencies first though.
[09:37] <psavva> recompile then?
[09:37] <goobsoft> yes, get the library dependancies, then get src, then configure, then make
[09:37] <psavva> cool
[09:37] <psavva> thanks
[09:37] <goobsoft> np
[09:37] <psavva> libogg not recognised
[09:39] <goobsoft> sudo apt-get install libogg-dev
[09:39] <goobsoft> liba52-0.7.4-dev
[09:39] <psavva> all ready newest version
[09:40] <goobsoft> maybe this one too x264-bin
[09:40] <CarlFK> https://help.ubuntu.com/community/UpdatingADeb  sudo apt-get build-dep <package> will take care of all that
[09:40] <psavva> all deps are all ready installed
[09:40] <goobsoft> That's all I know.
[09:40] <psavva> 0 upgraded, 0 newly installed, 0 to remove
[09:41] <psavva> i think i need to see if a new version of ffmpeg has been released
[09:41] <CarlFK> psavva: do the steps on that page
[09:41] <goobsoft> oh, I got my ffmpeg from subversion
[09:42] <psavva> ok CarlFK
[09:43] <psavva> all ready got the builds working, got the installs working... just not the encoding
[09:44] <psavva> going to try and find the subversion of mmpeg
[09:44] <psavva> ffmpeg
[09:44] <CarlFK> psavva: did dpkg-buildpackage build?
[09:45] <psavva> there's no source for ffmpeg in the repos
[09:46] <CarlFK> "got ffmpeg from mediabuntu repo"
[09:46] <CarlFK> i would be surprised if the source isn't there
[09:46] <psavva> yip, only the binary available from there
[09:47] <psavva> I'm getting the source from svn
[09:47] <psavva> then i'll try the build that goobsoft suggested
[09:50] <psavva> got subversion, gonna try build now :D
[09:50] <psavva> still got the problem of --enable-libogg...
[09:50] <psavva> should i just remove it?
[09:50] <goobsoft> It's worth a shot
[09:51] <psavva> configured ok
[09:52] <crevette> whi can I contact for my problem on http://revu.tauware.de/details.py?package=obex-data-server;
[09:53] <HighNo> crevette: hi again - so it still is broken?
[09:53] <crevette> HighNo yes
[09:55] <Highno_phone> Crevette that is bad. I saw the broken upload - it looks strange
[09:55] <crevette> the problem is I fixed all the reamaining problem of my package
[09:55] <crevette> and I found people to advocate it
[09:55] <crevette> we need it in hardy
[09:55] <slytherin> psavva: you don't have headers installed probably
[09:55] <Highno_phone> Did you file a bug already?
[09:56] <slytherin> oops, wrong channel
[09:56] <crevette> no, were ?
[09:56] <crevette> where
[09:56] <geser> crevette: try ask siretart for help
[09:56] <Highno_phone> Launchpad
[09:56] <crevette> siretart, around ?
[09:57] <HighNo> crevette:  https://launchpad.net/revu/+filebug
[09:59] <tbutter> anyone would like to give http://revu.tauware.de/details.py?package=jodviewer a review?
[10:00] <psavva> looks cool tbutter... i'm just a visitor here :D
[10:04] <psavva> so is anyone here from South Africa?
[10:10] <HighNo> psavva: there is #ubuntu-za
[10:10] <psavva> just curious :D  I'm a Ex-South african....
[10:10] <psavva> well still at heart :D
[10:10] <HighNo> :-)
[10:16] <Hobbsee> bug #188130
[10:16] <ubotu> Launchpad bug 188130 in moblin-image-creator "Update moblin-image-creator to 0.39" [Wishlist,Incomplete] https://launchpad.net/bugs/188130
[10:19] <HighNo> crevette: I've applied to become a REVU hacker - let's see who wins the race :-) Anyway, can't you just put them somewhere else like in your ppa or such? So reviewers could download it from there
[10:21] <HighNo> I don't know the complete revu infrastructure but I guess motu's can manually upload your package once two of them agreed on advocating.
[10:25] <DaveMorris> HighNo: congraz on getting your package accepted
[10:27] <psavva> well done :D
[10:38] <HighNo> DaveMorris: I did?
[10:38] <sistpoty|work> hi folks
[10:39] <HighNo> DaveMorris: Whooooohoooo
[10:39] <psavva> no ide
[10:39] <sistpoty|work> sparky's disk is full :( (still need to find out why, because there was quite some space left yesterday, unless I completely misread the numbers there)
[10:39] <sistpoty|work> -> REVU won't accept new uploads atm.
[10:40] <RAOF> iwl3945 is spewing hundreds of megabytes worth of kernel log for me, but that's unlikely to be affecting sparkey :)
[10:40] <HighNo> sistpoty|work: I am willing to join REVU hackers to help if I can. Do you need help? I applied via Launchpad...
[10:41] <frafu> Hello, I am looking at the build log of a package for universe and there are a lot of warnings (and a few errors) concerning the schemas; could anybody please have a look at it and tell me whether it is normal or if I have to do anything to fix it?
[10:41] <sistpoty|work> HighNo: for improving the codebase of REVU? (that's what revu-hackers is about)
[10:41] <frafu> http://paste.ubuntu.com/4489/
[10:41] <sistpoty|work> HighNo: of course, I'm always interested in revu improvements :)
[10:42] <frafu> And here is the complete log.  http://launchpadlibrarian.net/11886840/buildlog_ubuntu-hardy-i386.mousetweaks_2.21.91-0ubuntu1_FULLYBUILT.txt.gz
[10:43] <HighNo> I'd like to help out wherever possible. I got so much help around here. I feel the need to do something :-)
[10:45] <frafu> HighNo: you might have a look at the log that I pasted above ;-)
[10:46] <frafu> or anybody else, of course :)
[10:47] <Hobbsee> sistpoty|work: erk!  need a bigger hard drive
[10:48] <sistpoty|work> Hobbsee: or clean up more often (currently 30Gb only used by revu uploads)
[10:48] <Hobbsee> ouch
[10:53] <HighNo> frafu: I am still too unexperienced to check for a problem - sadly I never used gconf (on my list...)
[10:53] <sistpoty|work> crevette: please reupload obex-data-server
[10:54] <frafu> HighNo: thanks nevertheless
[10:54] <HighNo> sistpoty|work: how can I see revu's code?
[10:55] <sistpoty|work> HighNo: the currently codebase of revu1 is at https://code.launchpad.net/~revu-hackers/revu/trunk
[10:55]  * sistpoty|work has just free'd a tiny amount of space on sparky... still need to clean up later after lunch break
[10:56] <HighNo> DaveMorris: hey, thanks to the fast releases and the audience BlueProximity made it on rank 127 of sourceforge today. That's my best rank so far :-)
[10:56] <HighNo> sistpoty|work: I'll have a look
[10:59] <Hobbsee> persia: FYI, MIC is crack.  let them have it as native if they want - just make sure it doesn't point a maintainer address to MOTU
[11:01] <HighNo> sistpoty|work: do we still have that directory with the broken obex-data-server upload? I would dive into that problem then as I seems to happen more than once. Or maybe - was it a problem of low disk space? I saw the problem arrises in clusters.
[11:02] <sistpoty|work> HighNo: it was a problem with low disk space (of course revu could handle out of space problems more gracefully, but currently the entire upload processing is only some ugly shell scripts)
[11:05] <HighNo> sistpoty|work: ok, well I'll still have a look at it, maybe I can add some graceful error message there and at least an unbroken old package...
[11:06] <HighNo> superm1: I have done the file release. Will it be uploaded automatically now?
[11:07] <persia> ScottK: Not quite.  Still two packages to go.  libini4j-java and netbeans itself.  lashwrap would be nice, but the rest of my new packages lust is satisfied.
[11:13] <crevette> sistpoty|work, okay I'll do tonight
[11:13] <crevette> I'm at work now
[11:14] <emgent> heya
[11:20] <HighNo> sistpoty|work: you probably know it too - after two advocates, the next step is what exactly?
[11:20] <persia> HighNo: Someone uploads it.  THe packager may relax in confidence.
[11:22] <HighNo> persia: then I'll relax in confidence :-)
[11:23]  * HighNo is enjoying an interesting, learningful but successful week, and even passed the exam he couldn't learn for because he was constantly debugging his package...
[11:35] <persia> Does anyone have a working mdt installation running?  I'd like to catch up on my syncs :)
[11:37] <geser> persia: I've one setup, let me run the update
[11:37] <persia> geser: That would be great.  Thanks.
[11:40] <persia> slomo__: Can we not distribute poppler-data even in multiverse?
[11:42] <geser> persia: http://members.ping.de/~mb/universe-versionslist.html
[11:43] <persia> geser: Excellent.  Only 2130 packages to investigate tonight :)
[11:43] <slomo__> persia: imho no... (and if i remember the license correctly)
[11:44] <persia> slomo__: http://revu.ubuntuwire.com/revu1-incoming/poppler-data-0802101530/poppler-data-0.2.0/debian/copyright seems to indicate we can distribute as long as we don't modify, patch, or support it.  Am I reading it incorrectly?
[11:48] <jdstrand> ScottK: ack bug #191150
[11:48] <ubotu> Launchpad bug 191150 in clamav "possible integer overflow" [Undecided,In progress] https://launchpad.net/bugs/191150
[11:49] <HighNo> how's not supporting it possible? do they have blacklists in #ubuntu which packages they can answer?
[11:52] <Hobbsee> HighNo: it should be "no making changes to the code, at all, even if there are bugs"
[11:54] <HighNo> Hobbsee: ah, I see - although that's not a nice license is it? It seems even more strange as someone else might be able to fix your bugs for zero bucks - I can't understand some people
[11:55] <Hobbsee> HighNo: it's adobe.  enough said.
[11:57] <jcfp> Anyone in for reviewing http://revu.tauware.de/details.py?package=sabnzbdplus? (latest revision of the package is based on a new, improved upstream release)
[12:08] <persia> blueyed: jedit FTBFS for me!  I'll comment when I can fix REVU not telling me my password, but if you want to fix and reupload in the meantime, that might be good...
[12:12] <sistpoty|work> persia: more revu probs?
[12:13] <persia> sistpoty|work: no output from recover.  Waiting for a keyring sync to fix it :(
[12:13] <persia> Currently up through 'j', so shouldn't be too much longer...
[12:14] <sistpoty|work> persia: ah... k (you could have also done a revu-key import <keyid> for the fast way)
[12:14] <persia> sistpoty|work: My thought was that if it was broken for me, it was likely broken for others.  I can certainly do a lot of pre-review work prior to getting comment access.
[12:15]  * persia seeks a second advocate for http://revu.ubuntuwire.com/details.py?package=libini4j-java and http://revu.ubuntuwire.com/details.py?package=lashwrap
[12:15] <sistpoty|work> persia: heh, good point
[12:17] <persia> The first is a build-dep for netbeans 6, which would be a really nice upgrade from netbeans 5.5: now with support for more languages.  The second allows any package to use LASH to maintain session for audio work.
[12:25] <HighNo> sistpoty|work: I setup my revu here - it seems to work though I did not try an upload there yet. upated the readme a bit, but it pointed my always in the right direction
[12:25] <geser> oh, a third REVU now :)
[12:25] <HighNo> sistpoty|work: I'll try uploads and afterwards I need to know what processes should be in the crontab
[12:26] <HighNo> geser: yepp, and I can advocate everything I want to :-)
[12:27] <JonReagan> do any of you folks know who the REVU admins are?  I just joined the universe contributors group, and was hoping to get my GPG added to the keyring
[12:27] <HighNo> JonReagan: I think a keyring update is in process right now
[12:27] <JonReagan> ah
[12:27] <JonReagan> well, that takes care of my question!  Thx
[12:27] <HighNo> If I understood persia right
[12:28] <persia> JonReagan: Asking for a keyring sync in this channel is your best chance.  How long ago did you join the team?
[12:28] <JonReagan> a couple of min. ago
[12:29] <HighNo> sistpoty|work: I didn't search too far but is there some kind of admin-page or maintainance page?
[12:29] <persia> Then the last sync likely missed you :)  I'll run again in a few minutes.
[12:29] <JonReagan> thank you so much!
[12:29] <HighNo> persia: a running keyring sync does not influence the normal processes, right?
[12:30] <persia> sistpoty|work: running a sync didn't fix my lack of a password.  Help!
[12:30] <persia> JonReagan: Umm, please wait a bit: I don't want to collide with sistpoty sorting my password before I sync.  Soon...
[12:30] <persia> HighNo: Slows them down a bit, but LP is so slow that it's not significant impact.
[12:31] <JonReagan> no problem... I wont be attempting to upload stuff until this afternoon anyways.
[12:31] <HighNo> persia: hehe
[12:31] <persia> JonReagan: Depending on your local time of day, it should be fine then :)
[12:31] <JonReagan> thanks!  yeah, its 7:30 am where I'm at
[12:32] <JonReagan> well, I better get back to work.  Thanks, guys!
[12:34] <ScottK> slomo__: Urgh.  I guess I misread the license.  I thought it'd work for multiverse.  I actually uploaded it to the archive, not to REVU.
[12:35] <ScottK> persia: Did your java goals get met already or do you need me to look at something still?
[12:36] <slytherin> ScottK: If you are one of the build admins, I still have a request pending. :-D
[12:36] <ScottK> No, I'm a MOTU, but not a build admin
[12:37] <sistpoty|work> persia: sorry, was afk for a moment
[12:37] <sistpoty|work> persia: /me looks
[12:37] <geser> slytherin: you mean the jbossas4 package?
[12:38] <slytherin> geser: Completely forgot that. I was actually only thinking about batik
[12:38] <persia> ScottK: If you have time to look at libini4j-java, that would be great.  My goal is upgrading netbeans from 5.5 to 6, but I still need to review the netbeans package myself (although I'd be happy to be the second advocate if you feel like manually installing all the build-deps).  If libini4j can get in within a few hours, I believe netbeans will be able to build without manual arrangements tomorrow, making it less hard to review.
[12:38] <persia> sistpoty|work: Thanks.
[12:38] <geser> slytherin: for jbossas4 you will need to manage to reach infinity and ask him about the status of the bug
[12:38] <sistpoty|work> persia: hm... your key (0x00FD4057) is in the keyring
[12:39] <dcordero> h
[12:39] <dcordero> hi
[12:40] <persia> sistpoty|work: Unfortunately, both<EMAIL_ADDRESS>and<EMAIL_ADDRESS>have somewhat limited output :(
[12:41]  * persia preferrs the first address for REVU, but may well have both registered
[12:41] <sistpoty|work> persia: both are registered... /me looks what lostpw actually does
[12:43] <sistpoty|work> persia: trying to encrypt a message on sparky with the first email, gpg says "gpg: [stdin]: encryption failed: unusable public key"
[12:44] <persia> My key hasn't changed recently.  Did sparky?
[12:45] <sistpoty|work> persia: hm... actually I get the same gpg problem here as well, so this is probably not a sparky problem
[12:46]  * persia is confused, and wonders if gpg had an incompatible upgrade recently.  Worked locally just 13 hours ago
[12:46] <ScottK> Not that I've seen.
[12:47] <persia> ScottK: Be especially strange for sparky: it'S feisty
[12:47]  * sistpoty|work is at a debian/stable box btw.
[12:47] <geser> persia: sub  4096g/41AF13DC  created: 2007-01-15  expired: 2008-01-14  usage: E
[12:47] <ScottK> Which would also be strange to have suddenly break.
[12:48]  * persia checks again, and updates :(
[12:48] <sistpoty|work> persia: heh, oh... what geser wrote: your encryption key has expired
[12:48]  * persia is fixing
[12:49] <persia> geser: Thank you very much.  I completely missed it.
[12:49] <sistpoty|work> persia: as a workaround, you could lookup in the sql database (/srv/revu-production/revu.cfg should be readable for you, which contains the credentials)
[12:49] <sistpoty|work> persia: then it's just psql -Urevu revubase
[12:49] <sistpoty|work> persia: and there
[12:49] <slytherin> Can anyone confirm bug 189953
[12:49] <ubotu> Launchpad bug 189953 in icedtea-java7 "Inconsistent 'Provides' for different java compilers/runtimes" [Undecided,New] https://launchpad.net/bugs/189953
[12:50] <sistpoty|work> persia: select * from users where email='youremail';
[12:53] <persia> sistpoty|work: Thanks.
[12:53] <sistpoty|work> np
[12:53] <persia> geser: updated key pushed.  Would you mind checking to make sure that it stops showing expired in about 10 minutes?
[12:54] <persia> jonReagan: Running another sync, you should be sorted in about 20 minutes.
[12:59] <vorian> heya sistpoty|work, can you please remove http://revu.tauware.de/details.py?package=kdiamond-kde4
[12:59] <vorian> :)
[13:05] <slytherin> persia: geser: Can anyone of you please mail buildd admins for this preseeding? 'j2re1.4/license: true' and 'j2sdk1.4/license: true' I don't have access to my gmail account. :-( (damn these security policies in office) Thanks in advance.
[13:06] <HighNo> slytherin: security policies are always getting worse - next thing they do is actually try to make you work - eek :-)
[13:09] <_ruben> thats the good thing about being an sysadmin, you dont get to set them policies, but do get to implement them, with all 'benefits' of that ;-)
[13:10] <slytherin> HighNo: gmail pop was working till yesterday now they have blocked even that. What is worse we don't have access to blogs which are many a times source of technical troubleshooting tips
[13:10] <persia> RAOF: gnome-do advocated, but not uploaded.  Needs at least a one-line patch, but otherwise looks good.
[13:11] <geser> slytherin: they block gmail but let you still use IRC?
[13:11] <Hobbsee> geser: you can tunnel irc.
[13:12] <_ruben> and pop as well ;)
[13:12]  * persia thinks one can tunnel http more easily than irc: request/response and all...
[13:12] <_ruben> irc is actually easier to tunnel
[13:12] <slytherin> geser: fortunately I am on client ip tunnel and I can bypass proxy. But this is true only for non standard ports. :-P
[13:13] <persia> slytherin: If you can get through on non-standard ports, just hit a web proxy somewhere.  There are lots around on the internet.
[13:13] <geser> slytherin: or if you have a shell account somewhere use ssh for tunneling
[13:14] <slytherin> Proxy seems nice idea. :-D No shell account.
[13:14]  * persia tends to think of 22 as a "standard port", but that's another issue :)
[13:14] <_ruben> proxy the ssh session? ;-)
[13:15]  * slytherin thinks the security policy is perfect example of 'security by obscurity' attitude.
[13:15] <norsetto> peace everybody
[13:15] <persia> _ruben: Depending on the intelligence of the filter, may be easier to proxy http than ssh.  synchronicity can raise alarms.
[13:15] <persia> Hey norsetto.
[13:15] <norsetto> heya persia
[13:16] <HighNo> slytherin: if you have a root server I would install ssh to listen on port 80 :-)
[13:16] <HighNo> slytherin: I can even give help on installing gnu http-tunnel - that way everything gets out somehow
[13:16] <_ruben> HighNo: i'd use 443 instead .. when going through a proxy 443 uses CONNECT .. port 80 standard GET ;)
[13:17] <HighNo> _ruben: depends on what you want to do :-)
[13:17] <_ruben> HighNo: true ;)
[13:17] <slytherin> nah, I don't want to try too many things and risk loosing my job over 'tried to bypass security measures' blame.
[13:18] <_ruben> slytherin: just bribe a sysadmin then .. or steal neighbour company's wifi ;)
[13:18] <HighNo> _ruben: the most working setup I usually do is a) have a gnu httptunnel running with it's end connected to a ssh server and b) always having a working setup of dnstunnel going
[13:18] <_ruben> HighNo: sounds good
[13:18] <slytherin> Ok. I think that now the discussion is an off-topic for this channel. :-)
[13:19] <HighNo> _ruben: dnstunnel is very cool as many hotspots are installed in a stupid way, I can surf on almost any hotspot for free if I wanted to
[13:19]  * _ruben expected a similar comment much earlier to be honest
[13:19] <HighNo> slytherin: true - back to work now
[13:21] <mok0> _ruben: thy neighbors wifi is a honeypot... waiting to rip off your creditcard...
[13:24] <_ruben> ;)
[13:25] <Hobbsee> dnstunnel...i've not herad of that one
[13:27] <HighNo> Hobbsee: very cool - sets up a fake dns server, tunneling is not too slow
[13:29] <geser> persia: did you already updated your key? http://pgpkeys.pca.dfn.de/pks/lookup?search=0x00fd4057&op=vindex still lists the subkey as expired
[13:32] <HighNo> Hobbsee: apt-get install nstx
[13:33] <persia> geser: Yes, but I only pushed to MIT and LP.  Thanks for pointing out that page: I'll watch it.
[13:33]  * persia may need a new key, and a better expiry notification system
[13:34] <Hobbsee> HighNo: later :)
[13:34] <geser> persia: http://keyserver.ubuntu.com:11371/pks/lookup?search=0x00FD4057&op=vindex looks the same
[13:34] <sistpoty|work> vorian: done
[13:34] <vorian> thanks sistpoty|work :)
[13:34] <vorian> you are awesome
[13:35]  * persia checks again, and tries to sync harder
[13:35] <sistpoty|work> np
[13:38]  * geser goes now writing an exam
[13:38] <sistpoty|work> good luck geser!
[13:38] <dholbach> geser: we have our fingers crossed!
[13:38]  * Hobbsee waves goodbye to all
[13:39] <slytherin> geser: I just confirmed that libxstream-java builds and marked bug 187606 as confirmed.
[13:39] <ubotu> Launchpad bug 187606 in ubuntu "Please sync libxstream-java 1.2.2-1 (multiverse) from Debian unstable (contrib)" [Wishlist,Confirmed] https://launchpad.net/bugs/187606
[13:41] <Hobbsee> don't have too much fun without me!
[13:42] <sistpoty|work> HighNo: can you actually read what I wrote in the query?
[13:43] <HighNo> yes
[13:43] <HighNo> ehm
[13:43] <HighNo> no
[13:44] <HighNo> i was all into the source - thought of sql :-)
[13:44] <HighNo> no, can't read your messages sistpoty|work
[13:45] <sistpoty|work> HighNo: hm... seems like freenode won't let me privmsg (since I'm not registered user here at work... and always forget to bring my pw from home *g*)
[13:45] <HighNo> i think i could switch it off if i wouldn't have forgotten how :-)
[13:45] <sistpoty|work> HighNo: let's move to #ubuntuwire then
[13:47] <lar2> Hi - wondered if anyone would care to give http://revu.tauware.de/details.py?package=sun-javadb a review?  Hoping to have it in hardy :)  Cheers, and thanks.
[13:53] <mruiz> hi all
[13:58] <Iulian> Hey
[13:59] <leonel> scottK good morning ...
[13:59] <ScottK> Heya leonel.
[13:59] <vorian> sistpoty|work: it seems I am doomed with this one, still shows up stale http://revu.tauware.de/details.py?package=kdiamond-kde4
[14:00] <sistpoty|work> vorian: /me looks
[14:00] <vorian> thanks :)
[14:00] <leonel> scottK I can't get a complete debdiff      http://paste.ubuntu-nl.org/55724/
[14:00]  * ScottK looks
[14:01] <leonel> scottK this is what I got  when I run  debuild -S -sa : http://paste.ubuntu-nl.org/55725/
[14:02] <ScottK> leonel: Pastebin me your other changes and I'll look at it.
[14:02] <effie_jayx> hey mruiz
[14:02] <mruiz> hola effie_jayx :-)
[14:03] <leonel> but the patches are  in  :   http://paste.ubuntu-nl.org/55726/
[14:03] <theseinfeld> question for builders
[14:03] <leonel> scottK Ok paste the 2 patches
[14:03] <theseinfeld> I get this error when building for HARDY
[14:03] <theseinfeld> kpathsea: Running mktexmf ptmr8t
[14:03] <theseinfeld> ! I can't find file `ptmr8t'.
[14:04] <theseinfeld> any idea why is it doing this? It used to work :((
[14:04] <ScottK> leonel: Are you going to paste the actual patches?
[14:04] <leonel> scottKyes
[14:05] <leonel> scottK yes  http://paste.ubuntu-nl.org/55727/   first
[14:05] <theseinfeld> I guess I need to add also texlife-fonts-recommend?
[14:05] <leonel> scottK http://paste.ubuntu-nl.org/55728/   second
[14:06] <ScottK> Thanks
[14:10] <sistpoty|work> vorian: I've hand extracted the package for now... /me will need to free yet more space
[14:10] <vorian> sistpoty|work: thanks, I'll wait a bit before re-uploading it
[14:11] <sistpoty|work> thanks
[14:11] <vorian> :)
[14:15] <ScottK> leonel: I get the same error.  I think it's a problem in the dapper toolchain.  I think I know how to work around it.
[14:15] <leonel> ScottK any thing I can do ??
[14:16] <ScottK> Try the debdiff I'm about to give you.
[14:16] <ScottK> leonel:  http://paste.ubuntu-nl.org/55733/
[14:19] <ScottK> leonel: I get the same .po file errors when I build the source package, but I'm not worrying about it.
[14:21] <ScottK> keescook or jdstrand: I think we are about ready with fixes for Bug #191150 (just testing the Dapper fix now).
[14:21] <ubotu> Launchpad bug 191150 in clamav "possible integer overflow" [Undecided,In progress] https://launchpad.net/bugs/191150
[14:21]  * jdstrand nods
[14:23] <ScottK> jdstrand: I'd appreciate it if you would get started on Gutsy, because once that's published, I need to backport it to feisty-backports
[14:23] <norsetto> sistpoty|work: Long-time MOTU Stefan Potyra will talk about the bread and butter !?
[14:23] <jdstrand> ScottK: it's going to be a few minutes
[14:23] <leonel> scottK Great  Thank YOU !
[14:23] <ScottK> jdstrand: OK.  Understand.
[14:24] <norsetto> sistpoty|work: ahhh, there was a following: of almost all packages: libraries and how to package them right
[14:25] <dcordero> hi
[14:27] <sistpoty|work> norsetto: heh... the bread and butter session, right *g*
[14:31]  * persia notes for anyone else using date-based expiry for GPG keys that each subkey needs to be signed with a new expiry date to say alive, and that changing the expiry for only one subkey doesn't help.
[14:32]  * persia syncs the keyring again, just for fun
[14:34] <ScottK> leonel: Dapper debdiff works.
[14:35] <ScottK> jdstrand: Dapper tests out so Dapper/Feisty/Gutsy fixes are ready when you are.
[14:35] <jdstrand> ScottK: thanks!
[14:36] <ScottK> Nothing like dist-upgrading to Hardy and having that be your 30th reboot and now waiting for the fsck to see if the upgrade actually succeeded...
[14:41] <persia> ScottK: Consider it an enforced break :)
[14:41] <ScottK> It's not the stopping (I've got other boxes), it's the not knowing.
[14:42]  * persia advocates running fsck before dist-upgrade
[14:42] <lar2> Re: my review request for http://revu.tauware.de/details.py?package=sun-javadb: Java DB is a brilliant - of course - full-featured 100% java database for both embedded and client/server application.  It is used and supported by other splendid players like NetBeans, the GlassFish application server and Sun's JDK.  With both NB and GF in Hardy, Java DB should be there, too, so I hope some kind person(s) would review/advocate the package... :)
[14:42] <CarlFK> Marillat says " 1.0.6rc1 is the latest package on my repository." - but I can't find the url for sources.  did it become .debian-multimedia?
[14:43]  * persia notes that the NetBeans currently in hardy is outdated, crufty, and non-free
[14:44] <leonel> scottK great  yesterday i tested too the debs     and worked fine
[14:45] <ScottK> persia: I've got a package won't build twice in a row problem with a patch.  I was wondering if you'd have time/be willing to have a look at it?
[14:45] <slytherin> persia: what do you mean by non-free?
[14:45] <persia> ScottK: Do you need it done pre-FF?  I've a list.
[14:45] <persia> slytherin: Look at the licensing for the netbeans5.5 source.  Compare to netbeans on REVU.
[14:45] <ScottK> persia: No.  It's for Debian, so it can wait.  I'll ping you after FF if I don't have it sorted.
[14:46] <persia> ScottK: Thanks.  Given FF, I'm expecting to have some time this weekend, as RCbugs is still down...
[14:48] <dcordero> DktrKranz, did you check kannel warnings on hardy?
[14:48] <persia> pochu: emesene commented.  Minor packaging, and yet more licensing
[14:50] <DktrKranz> dcordero: I had a test build and I got the same results you did, let's see if it can be fixed somehow, but I don't think it's blocking
[14:50] <dcordero> DktrKranz, i was searching about similar bugs, but i can't found anything :/
[14:51] <rhpot1991_laptop> anyone have some time to help me figure out why debconf isn't working with my package?
[14:56] <DktrKranz> dcordero: in the meantime, you should adjust your debdiff in order to have Homepage field in Source stanza only, you should not repeat if for each binary packages.
[14:58] <dcordero> yep i read it on pdebuild but i dont know what is souce stanza :/
[14:59] <persia> dcordero: The stanzas in control are separated by a blank line.  The "source stanza" is the one that begins with "Source:"
[15:00] <DktrKranz> dcordero: it's a paragraph in debian/control which begins with Source:
[15:00] <dcordero> i see thanks
[15:00]  * DktrKranz is slow, persia is quick
[15:01] <mruiz> DktrKranz, !
[15:01] <persia> Nah.  Just not distracted at that moment :)  Anyway, it's not a "paragraph": each line in control is a "paragraph".  "stanza" is a better word.
[15:01] <DktrKranz> mruiz! :D
[15:01] <mruiz> DktrKranz, how are you today?
[15:02] <DktrKranz> mruiz: good, Milan is far away in my memory. Could you please point me to that bug?
[15:03] <mruiz> DktrKranz, bug 180625
[15:03] <ubotu> Launchpad bug 180625 in mnemosyne "Request Mnemosyne package upgrade to version 1.0" [Wishlist,Confirmed] https://launchpad.net/bugs/180625
[15:03] <DktrKranz> ok, as promised a century ago, I'll have a look :)
[15:05] <mruiz> thanks DktrKranz
[15:10] <DktrKranz> mruiz: I like complex things (so I like interdiffs...), but we recently switch to .diff.gz to review new upstream candidates. You may want to use it in future revisions or in outstanding bugs to attract sponsors.
[15:11] <pochu> persia: thanks for the emesene review. I'll get that sorted out (the copyright issues with upstream).
[15:11] <persia> pochu: Good luck on a fast turnaround.
[15:12] <persia> pochu: Any chance you'd like to look at lashwrap or libini4j?
[15:12] <mruiz> DktrKranz, I prepared an interdiff too :-)
[15:13] <pochu> persia: what are those? :)
[15:13] <mruiz> DktrKranz, Do you need the diff.gz ? I can upload it right now
[15:14] <DktrKranz> mruiz: no, I like interdiffs
[15:14] <mruiz> :)
[15:14] <rhpot1991_laptop> I could use some debconf help if anyone is available
[15:14] <persia> pochu: lashwrap is a little wrapper that allows one to add (limited) Linux Audio Session Handler support to any application, and libini4j is a java library for reading ini files that is the last dependency for updating netbeans for hardy.
[15:15] <ScottK> If anyone wants practice with security fixes or working with python packages, Bug #191198 is available ...
[15:15] <ubotu> Launchpad bug 191198 in python-cherrypy "[python-cherrypy] [CVE-2008-0252] missing input sanitising, remote vulnerability" [Undecided,Confirmed] https://launchpad.net/bugs/191198
[15:15] <jdong> DktrKranz: where is it documented on the wiki our current sponsorship preferences?
[15:16] <pochu> persia: I can have a look, but I've never looked at a java package, and I don't know much regarding sound :-)
[15:16] <DktrKranz> jdong: it was decided in latest MOTU meeting, IIRC
[15:16] <pochu> persia: looking into them
[15:16] <persia> jdong: It's not.  Please feel free to update the docs before I get to them :)
[15:16] <persia> pochu: Thank you.
[15:16] <jdong> DktrKranz: ah ok. A good decision IMO, because we reviewers can still interdiff it ourselves...
[15:16] <pochu> Oh they are even advocate :-)
[15:16] <pochu> +d
[15:17] <jdong> no loss of information
[15:17] <DktrKranz> jdong: there's a wiki page where we discussed review methods, probably under UbuntuDevelopment/CodeReviews
[15:17] <DktrKranz> or Interdiff itself
[15:17] <persia> jdong: I think the original idea of interdiffs (way back) was that they were supposed to be smaller than diff.gz.  During my effort to automate the production of packages from interdiffs, I was advised that this was not the case.
[15:18] <persia> Places needing updates are the package update recipie, the Interdiff page, MOTU/Contributing, and there likely needs to be a new page describing the process for generating a source package from a diff.gz
[15:18] <DktrKranz> persia: it depends on .diff.gz size, I guess. With small .diff.gz's, .interdiffs usually get bigger
[15:19] <jdong> persia: oh, ok
[15:20] <persia> DktrKranz: Actually, due to the lack of hunking support in combinediff, an interdiff is always the size of the old diff.gz plus the size of the new diff.gz, and possibly uncompressed.  gzip helps a little with the duplication for interdiff.gz, but I'd be surprised to find a case where interdiff.gz was smaller than diff.gz and the package could be reconstructed from the interdiff.
[15:20] <HighNo> ScottK: Is tells us a fix is already released for hardy?! What would there be to be done?
[15:20] <ScottK> HighNo: Dapper/Edgy/Feisty/Gutsy fixes
[15:21] <HighNo> ScottK: ok, so I would have to 'backport' the patch, right?
[15:21] <DktrKranz> persia: no hunks? I wasn't aware of that (probably because I never read an interdiff directly), so you are right.
[15:22] <persia> DktrKranz: Yep.  interdiff -z -p1 would be smaller, but it often doesn't work to reconstruct, which is why moving to diff.gz makes sense.
[15:22] <ScottK> HighNo: Yes.  You'd get the fix and then package it with a security changelog entry, test it, and attach a debiff to the bug.
[15:22] <persia> DktrKranz: Also, I'd recommend reading the output of interdiff -z -p1 in a pager.  It's a good indication of the packaging changes for a new upstream.
[15:23] <HighNo> ScottK: sounds interesting though I would need a lot of guidance in that
[15:23] <persia> (but not actually a valid patch)
[15:23] <\sh> hmm...
[15:24] <\sh> is there anywhere a policy how to name perl module packages?
[15:24] <ScottK> HighNo: I can probably coach you through at least parts of the first one.  After that you'll have it.
[15:24] <ScottK> \sh: Yes.  AFAIK it's in perl policy
[15:24] <persia> RAOF: I can't get the build-deps for do-plugins installed in a clean chroot today (even manually).  I'll take another look tomorrow, in the hopes that something will change.  Sorry.
[15:24] <ScottK> But it may just be debian-perl team policy.  Not sure
[15:25] <\sh> ScottK got it :)
[15:25] <\sh> http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names
[15:26] <DktrKranz> mruiz: I don't know if this is one of the cases persia referred to, but:
[15:26] <DktrKranz> Reversed (or previously applied) patch detected!  Assume -R? [n]
[15:26] <DktrKranz> Apply anyway? [n]
[15:26] <DktrKranz> 1 out of 1 hunk ignored -- saving rejects to file /tmp/interdiff-1.Drt1l0.rej
[15:26] <DktrKranz> interdiff: Error applying patch1 to reconstructed file
[15:26] <mruiz> ups
[15:27] <DktrKranz> mruiz: erm... my fault. I got mnemosyne_0.9.9-1.dsc instead of mnemosyne_0.9.9-1.diff.gz :)
[15:27] <mruiz> :)
[15:27] <persia> heh
[15:27]  * DktrKranz hates TAB key
[15:30] <HighNo> ScottK: I got the source, now I would like to get the patch for hardy but I can't see a way in launchpad to download that as I don't see a link to that file there
[15:30] <HighNo> ScottK (I'd start with a feisty fix as I have it installed)
[15:32] <DktrKranz> mruiz: looks good, but I have not X to test it ATM, so I'll have to delay detailed review for a couple of hours
[15:32] <ScottK> HighNo: Go to the Debian Security Notice linked in the bug and you'll see packages for etch linked.  Diff those against the released etch package and you'll know the fix. http://ftp.debian.org/debian/pool/main/p/python-cherrypy/
[15:32] <ScottK> HighNo: http://packages.qa.debian.org/p/python-cherrypy.html may also be useful.
[15:33] <HighNo> ScottK: thanks
[15:33] <mruiz> DktrKranz : thanks... we're improving ;-)
[15:35] <DktrKranz> mruiz: you implemented debian/patches/01_python_shebang_fix.dpatch, did you use dpatch?
[15:38] <linux__alien> Hi LucidFox
[15:38] <mruiz> DktrKranz, no . Do I need to rename the patch ?
[15:39] <DktrKranz> mruiz: also, watch file isn't accurate. Try with http://sf.net/mnemosyne-proj/mnemosyne-(.*)\.tgz
[15:39] <LucidFox> hi linux__alien
[15:40] <DktrKranz> mruiz: It seems you forgot to implement a patch system, so your patch won't be applieed, no matter which name you choose
[15:40] <linux__alien> i ve started working on the bug LucidFox
[15:40] <LucidFox> great!
[15:41] <mruiz> DktrKranz, any suggestion about patching ?
[15:43] <bddebian> Heya gang
[15:43] <DktrKranz> mruiz: if you have to setup a packaging system from scratch, dpatch is the simplest one, I prefer quilt just because it's more difficult :)
[15:43] <DktrKranz> s/packaging/patch/
[15:44] <mruiz> :)
[15:44] <linux__alien> LucidFox, i am sorry again i am struggling i made a mistake
[15:44] <linux__alien> LucidFox, i need your help
[15:45] <linux__alien> LucidFox, I am not able to download the package . The link in launchpad does not have the package where should i download it from
[15:46] <LucidFox> linux__alien> what do you mean? There is a link
[15:46] <DktrKranz> mruiz: this page is very simple, but it tells you everything you need to know about dpatch: http://matrixhasu.altervista.org/index.php?view=use_dpatch (point No. 4), unless you want to use quilt :)
[15:46] <sistpoty|work> hi bddebian
[15:47] <linux__alien> LucidFox, this is the link i am looking at
[15:47] <linux__alien> https://bugs.launchpad.net/ubuntu/+source/avidemux/+bug/189584
[15:47] <ubotu> Launchpad bug 189584 in ddtp-ubuntu "Typo" [Undecided,Confirmed]
[15:47] <mruiz> thanks DktrKranz ... I'll read it
[15:47] <bddebian> Heya sistpoty|work
[15:47] <LucidFox> linux__alien> yes, then click the overview link
[15:47] <LucidFox> which will bring you here: https://launchpad.net/ubuntu/+source/avidemux
[15:47] <\sh> hopefully I'm lucky to push some new packages to hardy today
[15:47] <LucidFox> linux__alien> and then click the latest version number
[15:48] <sistpoty|work> \sh: why did you join ubuntu-universe-contributors?
[15:48] <linux__alien> ok there you have development,current,supported etc
[15:48] <linux__alien> i should select hardy
[15:48] <linux__alien> right?
[15:49] <linux__alien> but here i ve a doubt where does the bug actually prevail does it exist in all versions of ubuntu or only in hardy?
[15:49] <\sh> sistpoty|work, just because I saw too late, that I was an indirect member :)
[15:49] <sistpoty|work> \sh: heh
[15:50] <\sh> ok my first upload to revu after a long long time :)
[15:50]  * ScottK2 cheers.
[15:51]  * \sh needs some packages to rollout ubuntu servers in his new company ,-) nice sideeffect building new packages ;)
[15:53]  * sistpoty|work hopes that the packages will be small *g*
[15:53] <LucidFox> linux__alien> you should select the last version in hardy - that is, 2.4.0-0.3ubuntu1
[15:53] <linux__alien> yes ve selected that but what does ubuntu1 and ubuntu3 stand for ?
[15:54] <LucidFox> linux__alien> let me explain
[15:54] <\sh> sistpoty|work, the first is just 16k with all debian stuff I think
[15:54] <linux__alien> ya thanks :)
[15:54] <LucidFox> the Ubuntu package version is (upstream-version)-X if the package was synced verbatim from Debian
[15:54] <LucidFox> where X is a number
[15:54] <HighNo> ScottK: OK, now I have the diff
[15:54] <\sh> sistpoty|work, when does the frontend updates its list?
[15:55] <sistpoty|work> \sh: as soon as the package got accepted by the cron job (*/10 iirc)
[15:55] <LucidFox> for example, f-spot 0.4.1-4 means that the upstream version is 0.4.1 and this is the fourth revision of the Debian package
[15:55] <\sh> sistpoty|work, cool thx :)
[15:55] <LucidFox> if there are Ubuntu modifications, it gets an additional "ubuntuY" qualifier: -XubuntuY
[15:56] <LucidFox> for example, the current Hardy version of F-Spot is 0.4.1-4ubuntu3; it means that the package is based on Debian version 0.4.1-4 with 3 Ubuntu modifications
[15:56] <HighNo> ScottK: and the apt-get source for the ubuntu version. I guess I now have to change the source and have to run debdiff afterwards?
[15:56] <ScottK2> HighNo: If the package already has a patch system, use that.
[15:57] <ScottK2> Then make your debdiff.
[15:57] <LucidFox> linux__alien> so, for avidemux, if you create a debdiff, you will bump the Ubuntu version number from 1:2.4.0-0.3ubuntu1 to ubuntu2
[15:57] <linux__alien> LucidFox, i understood it but does that mean as far as the author of the software is concerned its 0.4.1-4 but in Ubuntu its got 3 modifications and hence ubuntu3 is it?
[15:57] <sistpoty|work> \sh: there now..., I just triggered the upload queue manually
[15:57] <ScottK2> HighNo: When you make your debian/changelog entry, use dch -S (I think it's a big S).
[15:57] <\sh> sistpoty|work, http://revu.ubuntuwire.com/details.py?package=libdaemon-generic-perl => directory (/var/revu/revu1-incoming/libdaemon-generic-perl-0802121656/) of upload (1963) not found
[15:57] <sistpoty|work> grml
[15:57] <\sh> sistpoty|work, you broke it ;)
[15:57] <LucidFox> linux__alien> as far as the author of the software is concerned, the version is everything before the dash - that is, 0.4.1
[15:58] <linux__alien> yes
[15:58] <linux__alien> got it
[15:58] <linux__alien> then ?
[15:58] <LucidFox> but the package may be modified in Debian and Ubuntu
[15:58]  * ScottK2 will be back in a bit.  If someone else could help HighNo with his security fix, I'd appreciate it.
[15:58] <linux__alien> Ok got it but does it include the modifications done in K/X/buntu families too?
[15:58] <LucidFox> so in -XubuntuY, X is the number of Debian uploads before the package was synced/merged into Ubuntu, and Y is the number of Ubuntu uploads since then
[15:59] <LucidFox> no, all Ubuntu variations are maintained in the same repository
[15:59] <\sh> sistpoty|work, reupload?
[15:59] <sistpoty|work> \sh: if you don't mind, I'd rather like to see why this happened (again) today... this time it is not the free space
[15:59] <linux__alien> ok so if its incremented in Ubuntu it would be same across the other families too so how does it get incremented more than once in the same release? is it possible?
[16:00] <LucidFox> linux__alien> the Ubuntu increment is global for all of its subprojects
[16:00] <\sh> sistpoty|work, done
[16:00] <linux__alien> got it
[16:00] <LucidFox> linux__alien> for example, Dolphin is part of Kubuntu, but the version number is  	0.9.2-0ubuntu4, not kubuntu4
[16:00] <linux__alien> oh ok
[16:01] <LucidFox> the 0 before ubuntu4 means that the package is not based on a Debian upload, and instead packaged directly for Ubuntu
[16:01] <sistpoty|work> \sh: same problem as before
[16:01] <DktrKranz> HighNo: I'm more comfortable with SRUs, but I prepared a couple of security updates, if you have questions, feel free to ask :)
[16:01] <sistpoty|work> \sh: /me takes a look at the strange process_uploads script
[16:02] <linux__alien> LucidFox, thats interesting :)
[16:02] <\sh> sistpoty|work, take your time...you'll revu later anyhow ,)
[16:02] <sistpoty|work> heh
[16:03] <LucidFox> linux__alien> and avidemux was merged from debian-multimedia.org, which uses a dotted versioning notation. The original package was 1:2.4.0-0.3, and it was modified for Ubuntu once, hence 0.3ubuntu1
[16:03] <HighNo> DktrKranz: great. I know there is a command for creating a patch in a package which will setup everything, i can do my changes, and on exit it created the patch. Now how on earth was that beast called... ?
[16:03] <linux__alien> Oh thanks i was searching for 0 in a package as an example :)
[16:04] <DktrKranz> HighNo: could you please point me to the bug? My backlog filled up and I missed it
[16:04] <HighNo> https://launchpad.net/bugs/191198
[16:04] <ubotu> Launchpad bug 191198 in python-cherrypy "[python-cherrypy] [CVE-2008-0252] missing input sanitising, remote vulnerability" [Undecided,Confirmed]
[16:04]  * persia wonders if anyone uses Rails, and whether they feel like investigating about an upgrade from 1.2.6 to 2.0.2 (and the associated libraries, etc.) in the next couple days.
[16:05] <\sh> persia, you'll break all apps using rails 1.2.6
[16:05] <HighNo> DktrKranz: I just need that patch create command right now
[16:05] <\sh> persia, you need to update all config files when doing an update...(that happened to me last time in my last company)
[16:05] <sistpoty|work> while still unsure of what exactly is going wrong, I guess it won't hurt blaming StevenK, as linda's rfc822 parser produces backtraces *g*
[16:05] <\sh> s/update/upgrade/
[16:05] <LucidFox> persia, could you please readvocate tovid?
[16:06] <DktrKranz> HighNo: I'm getting the sources to see what patch system is implemented
[16:06] <persia> \sh: Yep.  I'm not interested enough to do that, but was just reviewing upstream variance with Debian, and thought I'd mention it in case anyone really wanted Rails 2.0 for hardy.
[16:06] <persia> LucidFox: I'll take a look once I get through the mdt list.  Maybe you can find another advocate?
[16:06] <\sh> persia, how did debian solved the problem? introducing a rails2 package?
[16:06] <LucidFox> persia> All right.
[16:07] <persia> \sh: Etch didn't have rails.  Lenny will have 2.x.  There is no problem :)
[16:07] <\sh> persia, ok...so I think we are good with rails1 and for hardy+1 we can inject rails2 and blow up youtube ,->
[16:07] <\sh> or whatever will use ruby+rails *harhar*
[16:08] <\sh> oh no..youtube is using python ;)
[16:08] <LucidFox> linux__alien> So, if the number before ubuntuN is something other than 0, it means that this upstream version got into Ubuntu from elsewhere (generally Debian). And if there's no ubuntuN, it means the package wasn't modified within Ubuntu.
[16:08] <persia> \sh: I'm happy with that.  Like I said, I don't really have an opinion, just know that there's some buzz about it, and significant version skew
[16:08]  * persia is rather happy to no longer be a rails programmer
[16:08] <linux__alien> oh ok thanks
[16:08] <DktrKranz> HighNo: you may want to use cdbs-edit-patch patchname
[16:08] <linux__alien> i am looking in the bug . The bug says there is a typo the version has to be version
[16:09] <sistpoty|work> \sh: how did you generate your changes-file?
[16:09] <linux__alien> and it affects cli, qt and GTK
[16:09] <LucidFox> linux__alien> right
[16:09] <sistpoty|work> \sh: because it doesn't contain a "Description" field
[16:09] <\sh> sistpoty|work, debuild -S -sa -k'0xC098EFA8!' because my gpg cardreader is in the company :)
[16:09] <\sh> what
[16:09] <LucidFox> linux__alien> so you'll have to edit debian/control and correct the typo
[16:09] <\sh> ?
[16:10] <linux__alien> ok i found it by grepping for it ;)
[16:10] <sistpoty|work> \sh: I guess someone broke dpkg-source... that's why revu is bailing out
[16:10] <linux__alien> but what version shoud i put in for qt and gtk
[16:10] <\sh> sistpoty|work, wtf?
[16:11] <linux__alien> where do i find the version numbers for it
[16:11] <DktrKranz> crimsun: around?
[16:11] <joejaxx> :\
[16:11] <HighNo> DktrKranz: Yepp, that was it
[16:11] <joejaxx> \sh: did i hear cardreader? :D
[16:11]  * joejaxx wants to play with smartcards on linux
[16:11] <\sh> sistpoty|work, that's serious
[16:11] <sistpoty|work> \sh: 5.5 of the policy says, there needs to be a description field in a .changes file. linda's rfc822 parser produces backtraces, if there isn't and that's because revu won't do the right thing with your upload
[16:12] <\sh> new dpkg package is coming
[16:12] <\sh> grmpf
[16:12] <\sh> who the heck did that
[16:12] <sistpoty|work> \sh: so since you used debuild, I assume that it calls dpkg-genchanges (or whatever it is called) which does the changes file wrong
[16:12] <\sh> joejaxx, aeh yes, I have an usb smartcard reader
[16:13] <\sh> joejaxx, but never inserted a different card then my gpg card :)
[16:13] <joejaxx> \sh: :D would you be able to point me to a specific model? :)
[16:13] <joejaxx> \sh: oh
[16:13] <joejaxx> lol
[16:14] <AnAnt> Hello, I've uploaded ubuntume-themes & ubuntume-gdm-themes to revu about 2 hours ago, yet when I access their page on revu I get something like: directory (/var/revu/revu1-incoming/ubuntume-gdm-themes-0802121510/) of upload (1955) not found
[16:14] <\sh> joejaxx, I can send you an email tonight when I'm at home :) looks like that I left it at home and not in my rucksack :)
[16:14] <sistpoty|work> AnAnt: /me checks
[16:15] <joejaxx> \sh: ok sure :D
[16:15] <linux__alien> LucidFox, you there?
[16:16] <sistpoty|work> AnAnt: same problem as \sh... I'll try to find the real problem (which is from a broken dpkg-dev package, I believe)
[16:16] <LucidFox> linux__alien> yes
[16:16] <\sh> sistpoty|work, just installed the update...no change
[16:17] <linux__alien> how do i get to know the exact version of the qt, GTK and CLI
[16:17] <\sh> sistpoty|work, it's been wished
[16:17] <\sh>   * Some code refactoring on dpkg-genchanges and bug fixes in the generation
[16:17] <\sh>     of the Description: field. As a result, source only uploads will no more
[16:17] <\sh>     have Description fields.
[16:17] <linux__alien> which version numbers should i place it in control file
[16:17] <\sh> sistpoty|work, says changelog dpkg (1.14.16) unstable; urgency=low
[16:17] <LucidFox> linux__alien> The version is the same for the entire source package, and it is managed via debian/changelog, not debian/control.
[16:17] <sistpoty|work> \sh: that's against the policy! and there is a reason why... it breaks revu!
[16:18] <LucidFox> linux__alien> The bug is in a typo: the word "version" is spelled "verison"
[16:18] <linux__alien> :-o
[16:18] <\sh> sistpoty|work, tell raphael herzog that
[16:18] <linux__alien> i thought i ve to put the version numbers there :(
[16:18] <sistpoty|work> buxy: you broke revu >P
[16:18] <sistpoty|work> :P
[16:19] <linux__alien> LucidFox, the spelling is right in the control file
[16:19] <buxy> sistpoty|work: 1.14.17 will have it back
[16:19] <sistpoty|work> buxy: wohoo, thanks!
[16:19]  * vorian was afraid he broke revu
[16:19] <linux__alien> ok got it
[16:19] <buxy> it's still impressive to see how many people are using fields which are not really normed
[16:19] <linux__alien> in the control file
[16:20] <buxy> and how removing it can break lots of stuff
[16:20] <buxy> (in unexpected ways)
[16:20] <sistpoty|work> buxy: erm... it's in policy (which told me linda, which is the real reason for the breakage *g*)
[16:20] <LucidFox> linux__alien> Since you're into it, please also change QT and GTK to Qt and GTK+ respectively
[16:20] <linux__alien> grepped for verison and changed it in all necessary places
[16:21] <linux__alien> :)
[16:21] <linux__alien> now i ve to build it right
[16:21] <linux__alien> debuild -S
[16:21] <LucidFox> wait
[16:21] <linux__alien> right?
[16:21] <linux__alien> ok
[16:21] <LucidFox> linux__alien> in the control file, please also replace the text "QT4" with "Qt 4" and "GTK" with "GTK+"
[16:23] <linux__alien> done
[16:23] <LucidFox> linux__alien> excellent, now create a debian/changelog entry for your changes
[16:23] <spiekey> Hello!
[16:23] <LucidFox> linux__alien> what is your favorite text editor?
[16:23] <linux__alien> vim
[16:23] <linux__alien> dch -i
[16:23] <linux__alien> right?
[16:23] <LucidFox> hello spiekey
[16:24] <LucidFox> linux__alien> you can use EDITOR=vim dch -i
[16:24] <LucidFox> this will open debian/changelog in vim instead of nano
[16:24] <spiekey> any idea how i could get a recent nss_ldap onto my dapper box?
[16:24] <linux__alien> ok so if its just dch -i it uses nano is it?
[16:24] <jpatrick> LucidFox: EDITOR=vim should be enough (works here)
[16:25] <LucidFox> linux__alien> by default, yes; you can also add the line "export EDITOR=vim" to your ~/.bashrc file to avoid typing it in the future
[16:25] <LucidFox> (this change will apply after you reopen the terminal)
[16:26] <linux__alien> ok thanks
[16:26] <linux__alien> i ve edited the file and saved it
[16:26] <linux__alien> with dch -i and saved it also
[16:26] <HighNo> DktrKranz: how exactly should the dch call look like and what to put in the entry so the launchpad bug is registered?
[16:26] <linux__alien> now debuild _S right?
[16:26] <linux__alien> sorry debuild -S
[16:26] <LucidFox> linux__alien> please make sure that you set the distribution to "hardy" and referenced the LP bug number using (LP: #xxx)
[16:27] <AnAnt> sistpoty|work: so are the packages on revu (ie. can they be reviewed somehow) or not ?
[16:29] <rhpot1991_laptop> can anyone tell me if they see any reason why my debconf note in here isn't launching: http://revu.tauware.de/details.py?package=mythexport
[16:30] <DktrKranz> HighNo: dch -s -D release-security (where release is the one you want to propose your security fix for)
[16:30] <linux__alien> LucidFox, have one doubt is it ok if i make 2 entries in the changelog file
[16:31] <linux__alien> i by mistake saved it without updating the BUG ID in the changeLog
[16:31] <sistpoty|work> AnAnt: revu's codebase needs to be fixed first... I hope to have it accept the new changes files soon
[16:31] <LucidFox> linux__alien> no, there should be only one; don't use dch -i for the second change
[16:31] <DktrKranz> HighNo: gutsy, for instance, would have dch -s -D gutsy-security
[16:31] <LucidFox> linux__alien> for the second change, just open debian/changelog directly
[16:31] <linux__alien> ve done it now :(
[16:31] <linux__alien> what do i do delete it manually by opening the changelog file ?
[16:32] <LucidFox> linux__alien> yes
[16:32] <linux__alien> ok
[16:32] <LucidFox> delete one of the entries and correct the other
[16:32] <linux__alien> ok
[16:33] <\sh> sistpoty|work, buxy : so we need it fast ;) before the 14th...and someone needs to merge it properly or re-introduce the description field in source.changes again
[16:33] <DktrKranz> HighNo: for good changelog templates, you can find useful examples here: https://wiki.ubuntu.com/SecurityUpdateProcedures
[16:33] <linux__alien> LucidFox, ok got the package but again fails in the signing part
[16:33] <buxy> \sh: it's rather unlikely that dpkg will be released in two days
[16:34] <sistpoty|work> \sh: I'll do a hotfix on linda's parser for now (locally only on sparky), so that it can cope with a changes file w.o. description
[16:34] <buxy> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=15fa75bd7143d6ec54f0a77c482ff0cfb72bf440
[16:34] <buxy> ^that's the commit to cherry-pick if you want to make a special upload in Ubuntu
[16:34] <LucidFox> linux__alien> correct the signing part in debian/changelog as well
[16:34] <\sh> buxy, I think this is necessary, regarding the time
[16:35] <linux__alien> LucidFox, how do i do that i ve given the proper entries in that file but it fails
[16:35] <linux__alien> i ve given my email address and my name
[16:35] <linux__alien> is there anything else should i give
[16:35] <LucidFox> linux__alien> no; just verify that it matches the output of gpg -K
[16:37] <linux__alien> LucidFox, should i give the comment also in the file ie when i do gpg -K it says MyName (Comment) <Email>
[16:37] <linux__alien> should i give it in the same order in the changelog file ?
[16:38] <buxy> \sh: necessary or not, I'm not an Ubuntu developer... :)
[16:38] <\sh> buxy, I'm taking care of it :)
[16:40] <LucidFox> linux__alien> leave the comment out
[16:41] <linux__alien> but other than that everything else is the same but it still fails
[16:41] <linux__alien> the changelog has the date in the same line
[16:41] <linux__alien> apart from that
[16:41] <\sh> buxy, and you should become one ;)
[16:41] <joejaxx> \sh: did you get your gpg smartcard from fsfe?
[16:41] <\sh> joejaxx, nope
[16:41] <\sh> joejaxx, as a present from a former colleague :)
[16:42] <joejaxx> is there a general place you can get them?
[16:42] <LucidFox> linux__alien> Okay, try adding the comment...
[16:42] <joejaxx> ah
[16:42] <\sh> joejaxx, looks like it.
[16:42] <LucidFox> (I have no idea why it would fail, though)
[16:42] <buxy> \sh: thanks but my work on the debian side benefits both :)
[16:43] <\sh> buxy, hehe...so you are able to sponsor some perl packages which I wanted to post to revu now ,)
[16:44] <buxy> \sh: come in #debian-perl @ OTFC, lots of nice people to sponsor perl packages :)
[16:44] <\sh> buxy, will do when I'm home :)
[16:44] <\sh> and now I'm going home :) bbl
[16:45] <LucidFox> linux__alien> Or you can ignore the whole signing part for now; the dsc was created, so you can generate the debdiff anyway
[16:45] <linux__alien> now it works its asking for the PassPhrase is it possible to find out the pass phrase ?
[16:45] <linux__alien> i forgot it i believe
[16:45] <linux__alien> :(
[16:46] <mruiz> DktrKranz, dpatch rules :-)
[16:46] <DktrKranz> mruiz: quilt more :)
[16:47] <jeromeg> DktrKranz: hello, I upload the debdiff for klavaro feisty, and gpocentek will test it too, thanks to you both :)
[16:47] <DktrKranz> jeromeg: GOOD!
[16:47] <jeromeg> DktrKranz: I thought this SRU would never be accepted ;)
[16:48] <DktrKranz> jeromeg: recently we had a policy change, so even minor patches have a chance to be SRU worthy. But this is not the case since it isn't a minor bug :)
[16:48] <DktrKranz> jeromeg: I tested it both for italian and english locale, two segfaults
[16:49] <DktrKranz> so it is definitely SRU-worthy
[16:49] <jeromeg> DktrKranz: after the patch or before ? (i'm worried :) )
[16:49] <DktrKranz> jeromeg: of course before
[16:49] <jeromeg> oh ok ! :)
[16:49] <linux__alien> Ok done
[16:49] <linux__alien> LucidFox, its signed
[16:49] <linux__alien> now whats to be done
[16:49] <linux__alien> the debdiff right?
[16:49] <DktrKranz> after your patch, a nice recap showing me I was not fluid :)
[16:49] <jeromeg> DktrKranz: i might try to proceed other SRUs
[16:49] <jeromeg> DktrKranz: lol :)
[16:50] <LucidFox> linux__alien> right
[16:50] <jeromeg> DktrKranz: i've a few patches for gnumeric but there's one important missing and upstream doesn't want to provide it, and I can't find it on the svn
[16:50] <DktrKranz> jeromeg: since I typed "little test." in less than a second, I guess what the heck mean "fluid" for it
[16:50] <linux__alien> avidemux_2.4.0-0.3ubuntu3.dsc
[16:50] <linux__alien> is this right?
[16:51] <jeromeg> DktrKranz: :)
[16:51] <LucidFox> linux__alien> no, should be ubuntu2
[16:51] <DktrKranz> jeromeg: if those are well-defined and it is easy to isolate single test cases for each, they are good
[16:51] <LucidFox> linux__alien> look at debian/changelog again
[16:52] <jeromeg> DktrKranz: ok
[16:52] <linux__alien> i ve only one entry
[16:52] <linux__alien> +--  6 lines: avidemux (1:2.4.0-0.3ubuntu3) hardy; urgency=low -- Balaji (My Key)  -------------------------------
[16:52] <linux__alien> +-- 16 lines: avidemux (1:2.4.0-0.3ubuntu1) hardy; urgency=low -- Matvey Kozhev  --
[16:52] <linux__alien> this is what i ve
[16:53] <mruiz> DktrKranz, is correct this line as unpatch target: rm -rf patch-stamp debian/patches ?
[16:54] <linux__alien> should i do it again from scratch ?
[16:54] <pochu> persia: emesene has been accepted (I uploaded it to the archive instead of to revu by mistake) but I'll get your points sored out for the next svn revision
[16:55] <LucidFox> linux__alien> no, just change the version of the most recent entry from ubuntu3 to ubuntu2
[16:55] <hexmode> anyone else want to be my second on http://revu.tauware.de/details.py?package=php-xdebug ?
[16:55] <persia> pochu: If an archive admin accepts it like that, please correct their interpretation of licensing (and fix it).
[16:55] <DktrKranz> mruiz: usually unpatch lies near clean:
[16:55] <tuxmaniac> can somone please review http://revu.tauware.de/details.py?package=alliance
[16:56] <persia> pochu: For extra points, fix it quick, and reupload before the archive-admin gets to it.  superceded uploads are almost never reviewed :)
[16:58] <pochu> persia: err, the archive-admin *already* got to it, and accepted it
[16:58] <persia> pochu: Err.  Point them at the REVU comment: we need less of that :(
[17:00] <linux__alien> LucidFox, ok now i ve done the debdiff too
[17:00] <linux__alien> what do i do now
[17:00] <LucidFox> linux__alien> upload it to the LP bug
[17:00] <linux__alien> last time i stopped here :)
[17:01] <linux__alien> ve to click on add attachment  is it?
[17:01] <linux__alien> and comment should be the corrected the typo errors in the file something like that right?
[17:01] <linux__alien> and attachment should be the diff file right?
[17:02] <linux__alien> is this all i need to do ?
[17:03] <jdstrand> ScottK2: fyi looking at clamav now
[17:07] <linux__alien> LucidFox, is this fine ?
[17:07] <linux__alien> whatever i ve mentioned above
[17:07] <linux__alien> can i upload it ?
[17:09] <LucidFox> linux__alien> wait
[17:09] <linux__alien> am sorry i had by mistake clicked on Save what do i do ? :-o
[17:10] <LucidFox> linux__alien> yes, now you can subscribe ubuntu-universe-sponsors to that bug
[17:10] <LucidFox> the sponsors will review your debdiff and upload it
[17:10] <linux__alien> i ve uploaded it in LP thats ok right?
[17:11] <LucidFox> linux__alien> yes
[17:11] <linux__alien> how do i subscribe that sponsors
[17:11] <linux__alien> where is that option
[17:11] <linux__alien> is it in LP?
[17:11] <sistpoty|work> launchpad
[17:11] <pochu> persia: I have a patch/request for emesene upstreams to fix the licnese issues. I'll upload a new tarball as soon as they commit it (which should happen in one/two days hopefully). Is that OK with you?
[17:11]  * persia decides to test requestsync again
[17:11] <pochu> persia: http://emesene.org/trac/ticket/373
[17:12] <linux__alien> i ve clicked on subscribe someone else option its asking for a name
[17:12] <linux__alien> so i ve to give ubuntu-universe-sponsors as the name of the person is it?
[17:12] <persia> pochu: Sure.  I can't test it (no MSN account), and I'm not motivated enough to file a removal request for emesene when there are so many more deserving applications to remove :)  Thanks for working to fix it.
[17:12] <DktrKranz> jeromeg: got mail for klavaro SRU, I'm test building and in a couple of hours I'll be able to test it on Feisty box
[17:12] <jeromeg> DktrKranz: thank you very much
[17:12] <pochu> persia: my pleasure. Thanks for your review ;-)
[17:13] <persia> pochu: Now about libini4j or lashwrap :)
[17:13] <Riddell> superm1: do you know why liberation font is in multiverse?
[17:13] <LucidFox> linux__alien> yes
[17:14] <RainCT> linux__alien: yes
[17:14] <DktrKranz> jeromeg: if gauvain has feisty too, mind asking him to check bug 124896 ?
[17:14] <ubotu> Launchpad bug 124896 in spe "spe 0.8.2a+repack-1 fails with python-wxgtk2.8" [Medium,In progress] https://launchpad.net/bugs/124896
[17:14] <sistpoty|work> \sh_away: revu can cope with the new changes files now
[17:14] <persia> RainCT: Are you swamped for FeatureFreeze?
[17:14] <sistpoty|work> \sh_away: I've put back your upload
[17:14] <sistpoty|work> \sh_away: and removed the stale ones
[17:14] <linux__alien> LucidFox, done
[17:15] <linux__alien> thats it ?
[17:15] <RainCT> Riddell: if it helps, on Debian they rejected the liberation fonts because they don't like some of the clauses added by RedHat.. there's a discussion about it somewhere on the mailinglist
[17:15] <mruiz> hi all... I got this lintian error: no-description-in-changes-file ...how can I fix it ?
[17:15] <HighNo> DktrKranz: hm, the changes in debian/changelog should not be part of the patch, right?
[17:15] <LucidFox> linux__alien> good work, now wait until a sponsor reviews and uploads your changes
[17:15] <Riddell> RainCT: how strange, it's gpl
[17:15] <DktrKranz> HighNo: do you refer to DebianMaintainerField?
[17:16] <HighNo> DktrKranz: and waht's about the maintainerfield change?
[17:16] <LucidFox> Any idea what could cause this FTBFS? http://launchpadlibrarian.net/11876047/buildlog_ubuntu-hardy-i386.subtitleeditor_0.20.0-1_FAILEDTOBUILD.txt.gz
[17:16] <HighNo> DktrKranz: no, i was referring to the changelog entry
[17:16] <LucidFox> dpkg-gencontrol: failure: cannot read -: No such file or directory
[17:16] <DktrKranz> HighNo: oh... I misunderstood. No, changelog entry has to be done *outside* of the patch
[17:17] <LucidFox> Error: parsed ddeb section or priority is empty
[17:17] <linux__alien> Thanks LucidFox for your help and advice
[17:17] <linux__alien> what next :)
[17:17] <linux__alien> ?
[17:17] <LucidFox> linux__alien> now wait :)
[17:17] <Riddell> RainCT: hmm, I see, the "exception" is actually a limiting trademark clause
[17:18] <RainCT> persia: swamped?
[17:18] <HighNo> DktrKranz: came to my mind a little too late. I have to patch my patch...
[17:18] <persia> RainCT: Do you expect to have some free development time?
[17:18] <linux__alien> i ll have to wait until this is closed is it ? is it something like that in Ubuntu ie a bug fixer fixes a bug and only when its uploaded he can start working on the other bug is it?
[17:18] <linux__alien> just to know the process
[17:19] <LucidFox> linux__alien> no, you can work on multiple bugs at once
[17:19] <linux__alien> so can i ?
[17:19] <linux__alien> :)
[17:19] <linux__alien> very eager to start an other one :)
[17:19] <LucidFox> of course!
[17:19] <linux__alien> something in the code as such ?
[17:19] <linux__alien> ie in a small gnome application or stuff like that
[17:19] <RainCT> persia: hm.. depending for what
[17:19] <linux__alien> so that i can download it compile it try fixing it and then do the same :)
[17:19] <DktrKranz> HighNo: no big trouble... cdbs-edit-patch patchname
[17:20] <persia> RainCT: Adding a script to ubuntu-dev-tools to turn a diff.gz file into a Debian-format source package.
[17:20] <LucidFox> linux__alien> When I find an easy bug, I'll let you know; you can also try looking yourself
[17:20] <LucidFox> which will probably be faster :)
[17:20] <linux__alien> ok sure :)
[17:21] <linux__alien> so now i ve fixed one bug in Ubuntu is it
[17:21] <linux__alien> ?
[17:21] <linux__alien> :)
[17:21] <RainCT> persia: do you have such a script or does it need to be written?
[17:24] <HighNo> DktrKranz: now again - the maintainer field - which one should I change to what value?
[17:25] <linux__alien> Hey LucidFox Thanks for your help and time i am ready for the next bug but now a little bit tired and really happy that i ve contributed in a very small manner to this wonderful project and want do more to this
[17:25] <linux__alien> so will log in back tomorrow :)
[17:25] <linux__alien> my first patch to this MOTU happened today :)
[17:25] <persia> RainCT: I have a non-robust script for interdiffs.  Dropping the combinediff bits ought reduce to the diff.gz case.  Something like filterdiff -z -i '*/debian/*' diff.gz | patch -p1 && (debian/rules get-orig-source || uscan --force-download) && rm -r debian && $(insert nifty .dsc file creation code here)
[17:26] <DktrKranz> HighNo: now it is Maintainer: Gustavo Noronha Silva<EMAIL_ADDRESS>[17:26] <DktrKranz> HighNo: your change must replace it with:
[17:26] <DktrKranz> Maintainer: Ubuntu MOTU Developers<EMAIL_ADDRESS>[17:26] <DktrKranz> XSBC-Original-Maintainer: Gustavo Noronha Silva<EMAIL_ADDRESS>[17:27] <HighNo> DktrKranz: it already has been before
[17:27] <linux__alien> Ok cya all
[17:27] <linux__alien> cya LucidFox
[17:28] <persia> RainCT: It7s the last part that stumps me.  One needs to create the target directory, enter it, run tar --strip -1 -xzf ../orig.tar.gz && zcat ../diff.gz | patch -p1 or something.
[17:28] <persia> Then dpkg-source -b ought do it.
[17:28] <DktrKranz> HighNo: you don't have to change it, then
[17:28] <persia> On the other hand, there ought be a way to do it directly, perhaps based on the dpkg-source source
[17:28] <HighNo> DktrKranz: ok, so now I do the debdiff ?
[17:28] <mruiz>  no-description-in-changes-file is a lintian bug ?
[17:29] <persia> mruiz: Or a dpkg bug, depending on your viewpoint
[17:30] <mruiz> persia, I was reading about it on debian ML... It seems that lintian 1.2.43 will fix this issue
[17:31] <mruiz> ups, 1.23.43
[17:31] <persia> mruiz: Yes, for Debian, a new lintian will fix it.  I don't remember the outcome of the discussion for hardy.
[17:32] <DktrKranz> HighNo: sure
[17:32] <mruiz> DktrKranz, I'm finishing with mnemosyne fixes ;-)
[17:33] <DktrKranz> mruiz: good
[17:33] <RainCT> persia: so what's the problem? that you don't know the name of the files or what?
[17:33] <RainCT> *the name the files will have
[17:34] <persia> RainCT: That, and having smart orig.tar.gz handling to cover the case where the directory name doesn't match what is desired, or there is no top level directory.
[17:35] <persia> Also, having some nice robust error handling, so the user knows what to tell the diff.gz submitter if it doesn't work.
[17:35] <persia> And lastly, having time to write & test it in the next 43 hours :)
[17:37] <persia> RainCT: For the file names, that ought be somewhat discoverable from the output of lsdiff -z diff.gz.
[17:41] <RainCT> persia: I don't think I can be of much help with that (I never used many of those commands you listed), sorry :(
[17:48] <AnAnt_> Stefan Potyra: thanks
[17:49] <jpatrick> AnAnt_: that'll be sistpoty|work :)
[17:49] <AnAnt_> sistpoty|work: thanks
[17:49] <DktrKranz> gpocentek: I saw you update debdiff in bug 41491. If you want, please go ahead and upload.
[17:50] <ubotu> Launchpad bug 41491 in wzdftpd "Dapper: Broken dependencies for some wzdftpd modules" [Medium,In progress] https://launchpad.net/bugs/41491
[17:50] <sistpoty|work> AnAnt_: no problem, and again sorry for the inconvenience
[17:50] <AnAnt_> sistpoty|work: no probs
[17:50] <persia> AnAnt_: You asked about native packages earlier.
[17:50] <crevette> hello
[17:51] <tbutter> anyone would like to give http://revu.tauware.de/details.py?package=jodviewer a review?
[17:51] <crevette> thanks to the person who have fix my upload on revu
[17:51] <AnAnt_> persia: yeah
[17:51] <AnAnt_> persia: btw, I re-uploaded GDM themes package
[17:51] <persia> The reason I don't like them for derivatives is that typically the derivative team wants to maintain the branding, etc, in some external VCS, which is then packaged for the distribution.
[17:51] <AnAnt_> persia: and uploading ubuntume-themes now
[17:51] <crevette> superm1: hello, If you can review my package (as you have already started), I would be thanksfull
[17:52] <persia> I think the mythbuntu team is a good example of how this can be done well.
[17:52] <mruiz> DktrKranz, do you prefer an interdiff?
[17:54] <DktrKranz> mruiz: this time a .diff.gz would be advisable
[17:54] <mruiz> :)
[17:54] <DktrKranz> so anyone can review it following our new procedures
[17:57] <RainCT> am I the only one having problems with launchpad.net and *ubuntu.com?
[17:57] <jpatrick> anyone else unable to get a experimental pbuild with: "pbuilder-dist experimental nolog create" ?
[17:57] <jpatrick> RainCT: it's your modem, yes
[17:58] <geser> jpatrick: could it be that experimental isn't self-hosted?
[17:58] <persia> RainCT: Yes
[17:58] <jpatrick> geser: well, I kinda need a experimental pbuild for KDE 4 packages :-)
[17:58] <persia> jpatrick: Create an unstable chroot, and dist-upgrade to a combination of unstable and experimental
[17:59]  * RainCT gets "Connection to 91.189.90.* Failed" :S
[17:59] <crevette> if someone can review http://revu.tauware.de/details.py?package=obex-data-server
[17:59] <crevette> thanks for your time
[17:59] <jpatrick> persia: ok, but will that work for pbuild?
[17:59] <mruiz> DktrKranz, mnemosyne is ready for another review
[18:00] <persia> jpatrick: Maybe.  experimental+unstable is expected to be broken regularly.
[18:00] <gpocentek> DktrKranz: ok thanks, I was just wondering if dapper-proposed is the correct target?
[18:00] <persia> pochu: You're uploading libini4j-java, or you're fine with an upload with a couple tweaks?
[18:00] <DktrKranz> gpocentek: it is.
[18:01] <jpatrick> persia: hmm, so no way to check if a kde4 may/may not build?
[18:01] <persia> jpatrick: empirically?
[18:01] <jpatrick> s/kde4/kde4 package/
[18:01] <DktrKranz> gpocentek: you'll receive a "waiting for distro manager" mail, so you will have to wait an archive-admin to approve it before it begins to build and to be spread to the world.
[18:02] <DktrKranz> mruiz: good
[18:02] <DktrKranz> mruiz: I'll have a look in a couple of hours, now let's get out of the office :)
[18:02] <gpocentek> DktrKranz: ok
[18:02] <jpatrick> persia: I know it works on Ubuntu, however all kde4 packages in Debian live in experimental
[18:03] <mruiz> thanks DktrKranz ... I learned how to patch with dpatch ;-)
[18:03] <DktrKranz> mruiz: and now, you'll have to learn yada :D
[18:04] <DktrKranz> and please, teach me once you have learned it :)
[18:04] <persia> jpatrick: Right.  experimental doesn't live by itself, it lives in combination with unstable.  The names should give some indication of how likely it is that any given combination of build-dependencies will work.  You might seek a debian KDE channel for better guidance.
[18:04] <mruiz> DktrKranz, hahaha
[18:04]  * persia notes that yada packages are an exception to the minimal diff rule, and may be repackaged at will
[18:04] <lakin> Maybe this is the wrong place to ask, but I'll ask anyways.  A friend of mine need to compile a new PHP package for Ubuntu due to a known bug with using different gd versions or some such, is there a good tutorial or howto for something like that?
[18:05] <AnAnt> persia: sorry I got disconnected
[18:05] <persia> AnAnt: No worries.  You didn't miss much.
[18:06] <pochu> persia: I prefer someone else to do the upload, as I'm not very confident with java packaging. Feel free to do those changes, as long as they aren't very intrusive
[18:06] <jpatrick> persia: http://paste.ubuntu-nl.org/55768/ - but I haven't... yet :)
[18:06] <tbutter> lakin: https://help.ubuntu.com/community/UpdatingADeb
[18:07] <persia> pochu: I'll check with Marek, but likely use my watch file and get-orig-source rule from an earlier comment.  If you're happy excepting that, I'll upload once I get confirmation from Marek.
[18:08] <pochu> persia: of course. Did you seem my comment? ;-)
[18:08] <RainCT> RAOF: do-plugins has a typo in debian/control :P
[18:08] <AnAnt> persia: so what mythbuntu did is that they hosted their packages in LP ?
[18:08] <persia> jpatrick: Create a sid chroot.  Add the experimental repos (not replace, add). with pbuilder --login or something.  pdebuild
[18:09] <persia> pochu: Yep, just asking to be sure, as typically changes after the second advocation are frowned upon :)
[18:09] <RainCT> RAOF: line 45, s/albumb/album ;)
[18:09] <jpatrick> persia: gotcha, thanks
[18:09] <persia> AnAnt: Rather that mythbuntu made non-native packages for everything.
[18:10] <AnAnt> persia: problem is that the repository has both the work & the packaging
[18:10] <geser> jpatrick: check also with the Debian Qt/KDE Team which pachage from experimental they use for building as normally not everything available from experimental is used during build
[18:10] <persia> AnAnt: One can work around that with a suitable process to generate the tarball.
[18:11] <persia> geser: jpatrick@freenode is davies@OFTC (see pastebin above)
[18:12] <geser> jpatrick: you probably need also to use /usr/lib/pbuilder/pbuilder-satisfydepends-experimental for PBUILDERSATISFYDEPENDSCMD
[18:12]  * persia gains deeper appreciation for the relative simplicity of sbuild
[18:14] <geser> persia: how does sbuild do it to prefer unstable over experimental and use only packages from experimental when really needed (not in unstable or wrong version)?
[18:14] <persia> geser: versioned build-dependencies
[18:15] <persia> Err.  versioned build-dependencies + setting apt-policy to prefer unstable over experimental.
[18:16] <Riddell> DktrKranz: about?
[18:17] <Riddell> DktrKranz: you uploaded dspam (3.6.8-4ubuntu1.1) to feisty-proposed, but there is already a package with that version in the archive
[18:18] <jpatrick> persia: wow, that pbuilder --login's useful
[18:19] <AnAnt> sistpoty|work: can you remove ubuntume-themes_1.1.dsc, as I am not able to upload
[18:19] <geser> persia: that works? then jpatrick should be able to use the same trick in pbuilder
[18:19] <DktrKranz> Riddell: was it the same upload?
[18:19] <sistpoty|work> AnAnt: done (btw. the next cron run would have moved it out of place anyways ;)
[18:20] <AnAnt> sistpoty|work: what's the time between cron runs ?
[18:20] <sistpoty|work> AnAnt: every 10 minutes
[18:21] <sistpoty|work> (and yes: it's moved in a way so that an upload taking longer than 10 minutes won't break)
[18:21] <persia> geser: It works, but only if you have a dedicated "experimental" chroot.  The pbuilder stuff you mentioned might allow a single "unstable/experimental" chroot to be used for multiple purposes (but I really have no idea, not being a pbuilder person).  sbuild just calls out to apt, which uses the system apt-policy.
[18:22] <Riddell> DktrKranz: yes but you still shouldn't use the same version number
[18:23] <DktrKranz> Riddell: curious. I uploaded it once and there was no other 3.6.8-4ubuntu1.1. Could we look at it later? I'm leaving now.
[18:24] <RainCT> does Feature Freeze affect syncs that were ACK'd before it started?
[18:25] <persia> RainCT: Quite likely, although that ends up being an archive-admin decision.
[18:25] <Riddell> I'd expect archive admin to be lenient on that since the sync script is currently broken
[18:26] <persia> Bah.  The script is usually broken.  syncs should be filed manually.
[18:28] <\sh> re
[18:29] <cody-somerville> tard
[18:29] <cody-somerville> :]
[18:29] <Riddell> gpocentek: ping
[18:29] <gpocentek> Riddell: pong
[18:30] <geser> persia: I guess Riddell means the sync-source script used by the archive admins, see bug #191230
[18:30] <ubotu> Launchpad bug 191230 in soyuz "sync-source broken by recent cherry-pick" [High,In progress] https://launchpad.net/bugs/191230
[18:30] <persia> Ah.  I thought it was the other script.  Thanks.
[18:30] <Riddell> gpocentek: your upload of wzdftpd to dapper-proposed is not minimal, it includes updates to config.sub and .guess
[18:30] <Riddell> gpocentek: could you upload one that's just the debdiff?
[18:31] <webwolf_27> I'm planning (engineering) a graphical alternative for pppoeconfig, are there any other connection methods that use pppoe besides DSL
[18:31] <gpocentek> Riddell: yep I will, sorry for this upload
[18:31] <cody-somerville> webwolf_27: Hardy already has a graphical alternative to pppoeconfig
[18:31] <Riddell> gpocentek: ping me when you do that
[18:32] <webwolf_27> cody-somerville, someone beat me to it :-( then I'll have to work on something else
[18:32] <persia> webwolf_27: pppoe over fiber
[18:32] <RainCT> persia: thanks
[18:32] <sistpoty|work> woooohooo... REVU survived my bzr activities, so now the description hotfix is merged from trunk, instead of the local hack :)
[18:32] <cody-somerville> webwolf_27: Why not work on something that already exists to make it better? :)
[18:33] <sistpoty|work> and pochu's comment's patch is now also on production, thanks!
[18:33] <LaserJock> RainCT: you around?
[18:33] <RainCT> LaserJock: pong
[18:33] <webwolf_27> cody-somerville, also a point, but then I'm already working with a few others in adding support for more brother printers in hardy
[18:33] <LaserJock> RainCT: ok, I just have nothing but problems with pbuilder-dist
[18:34] <RainCT> \sh: ^
[18:34] <LaserJock> RainCT: how do I do a i386 pbuilder on a amd64 machine?
[18:34] <RainCT> LaserJock: latest version from Hardy?
[18:34] <LaserJock> yeah, I grabbed it from bzr
[18:34] <geser> sistpoty|work: REVU only waits till you go home before it breaks :)
[18:34] <RainCT> LaserJock: ok, it's broken :P
[18:35] <\sh> LaserJock, pbuilder --debootstrapopts --arch --debootstrapopts i386 ;)
[18:35] <LaserJock> hmmpf
[18:35] <\sh> LaserJock, and yes it's my fault that pbuilder-dist is broken ;)
[18:35] <tuxmaniac> can somone please review http://revu.tauware.de/details.py?package=alliance
[18:35] <LaserJock> what's the point of having this script if it's constantly broken :/
[18:35] <sistpoty|work> geser: heh, *crossing fingers*
[18:36] <persia> tuxmaniac: What is it, how is it good, and why should it be in hardy?
[18:36] <LaserJock> sorry, just venting a little as it seems like I always use pbuilder-dist when it's not working
[18:36] <\sh> LaserJock,  it's broken by design ;)
[18:36] <persia> LaserJock: sbuild is nice...
[18:36] <RainCT> \sh: btw, any progress with the rewrite you started?
[18:37] <LaserJock> persia: does it work without LVM?
[18:37] <\sh> RainCT, I'm missing my time, catching up with the new job etc. :( and I think we are thinking to complex
[18:37] <geser> persia: can you reproduce the FTBFS of mediatomb in your sbuild? (http://launchpadlibrarian.net/11884727/buildlog_ubuntu-hardy-i386.mediatomb_0.10.0.dfsg1-1_FAILEDTOBUILD.txt.gz)
[18:38] <tuxmaniac> persia, its a VLSI CAD Tool used by several hundred students.
[18:38] <persia> LaserJock: Sure, if you have some chroots around, but it doesn't clean up after itself without LVM
[18:38] <LaserJock> hmm, it can't just untar a clean chroot?
[18:39] <persia> geser: I don't have any i386 chroots.  Should it be reproducible on amd64?
[18:39] <AnAnt> persia: I re-uploaded ubuntume-gdm-themes to http://revu.tauware.de/details.py?package=ubuntume-gdm-themes
[18:39] <geser> persia: the same error happens on amd64
[18:39] <pochu> sistpoty|work: cool :)
[18:39] <tuxmaniac> persia, Fedora already has them in the repos and it would be nice if Ubuntu also get it through. Till date there is no .deb available for it. (rpm package is already available)
[18:40] <persia> AnAnt: Now you need reviewers.  I don't have any build resources available just now, and a bit of a queue.  Try seeking someone else first.
[18:40] <AnAnt> persia: ok
[18:40] <persia> tuxmaniac: That's a better advertisement than "please review this URL" :)
[18:40] <sistpoty|work> AnAnt: there still seems to be a stale upload of ubuntume-themes... did you interrupt an upload of this?
[18:40] <tuxmaniac> persia, debian is also very much interested in getting this package through
[18:40] <AnAnt> sistpoty|work: dunno what's the problem here
[18:40] <AnAnt> sistpoty|work: I may re-upload later from a faster link
[18:41] <geser> persia: see als Debian bug 465177
[18:41] <ubotu> Debian bug 465177 in mediatomb "FTBFS: configure: error: unable to configure inotify support" [Serious,Open] http://bugs.debian.org/465177
[18:41] <sistpoty|work> AnAnt: ok, then I'll clean up the stale files now (looks just like an incomplete upload though)
[18:42] <geser> persia: the interesting thing is that mediatomb builds on i386 and amd64 in Debian but fails on powerpc while in Ubuntu is reversed
[18:42] <tuxmaniac> persia, I know I have spammed this channel. But I dont want to disappoint so many people who are eager to see this pakcage in Hardy
[18:42] <RainCT> AnAnt: wasn't it uploaded already by superm1?
[18:43] <thekorn> hi, I've got a small packaging question,
[18:43] <RainCT> (or at least that's what he says on his last comment..)
[18:43] <AnAnt> RainCT: the gdm theme ? yes
[18:43] <thekorn> I would like to add examples to the python-launchpad-bugs package,
[18:43] <persia> geser: Hmm.  Sounds like it needs attention of the buildd admins who might understand how our buildds work better than you or I.  They may have special kernels or use interesting virtualisation or something.
[18:43] <thekorn> this packages is using cdbs, I added a debian/python-launchpad-bugs.examples,
[18:43] <thekorn> with the path to the example scripts,
[18:43] <AnAnt> RainCT: I just fixed some issues the reviewers weren't so happy about
[18:44] <thekorn> When I install the package, all samples are created in /usr/share/doc/py-lp-bugs/examples,
[18:44] <AnAnt> RainCT: 1 issue actually
[18:44] <persia> thekorn: CDBS calls dh_installexamples by default.  `man dh_installexamples` for information about how to indicate what should be installed.
[18:44] <geser> persia: aren't the builds done inside a xen instance?
[18:44] <thekorn> persia, but they are all gzip'ed, is this common policy or did I miss a switch or something
[18:44] <persia> thekorn: In short, you need debian/python-launchpad-bugs.examples to have the right contents.
[18:45] <RainCT> AnAnt: Oh ok. The right way to get this into Ubuntu then would be posting a debdiff on Launchpad and subscribing ubuntu-universe-sponsors
[18:45] <RainCT> AnAnt: but as LP isn't working right now for me I think I'll have a look at it ;P
[18:45] <persia> thekorn: That's policy.  If you have a good reason, you can pass -X to dh_compress.
[18:45] <AnAnt> RainCT: after the package passes out of the Queue or while it is still in the queue ?
[18:45] <persia> geser: I remember something like that, but don't really know.
[18:46] <thekorn> persia, ok thanks, I thought I did something wrong
[18:46] <AnAnt> RainCT: can I do a debdiff against a native package ?
[18:46] <persia> thekorn: No, just that CDBS gets extra confusing when you want to violate policy for some reason.  It's designed to make that hard :)
[18:46] <thekorn> heh
[18:47] <persia> thekorn: For CDBS, set DEB_COMPRESS_EXCLUDE := .py or something.
[18:48] <RainCT> AnAnt: dunno..
[18:48] <RainCT> Can I upload a new revision for a package that's still in the NEW queue?
[18:49] <thekorn> persia, ah,ok, thanks, I'm personally fine with having them gzip'ed, but good to know
[18:49] <sistpoty|work> RainCT: iirc yes
[18:49] <sistpoty|work> AnAnt: looks, like you've got some ftp troubles (at least from what the logs say)
[18:49] <persia> AnAnt: You can do a debdiff against a native package, sometimes, as long as there were only certain sorts of changes (another of the reasons I don't like native packages, especially ones containing graphic or sound files)
[18:50] <AnAnt> sistpoty|work: yeah
[18:50] <sistpoty|work> AnAnt: test-wise, you can try to upload the files with a different ftp-client, just make sure to get the .changes file uploaded last
[18:51] <sistpoty|work> AnAnt: however you cannot resume on a file (because it will get mv'ed every 10 minutes, but since the inode doesn't change, the upload can continue, as long as you don't close the ftp-client)
[18:51] <AnAnt> k
[18:52] <sistpoty|work> AnAnt: if it weren't a native package, I could simply put the old orig.tar.gz back into the incoming directory, but this won't work here of course :/
[18:52] <AnAnt> nope
[18:52] <AnAnt> freezed @ 0%
[18:53] <AnAnt> sistpoty|work: bah, I'll just do it from a fast connection tomorrow
[18:54] <sistpoty|work> AnAnt: or you could post a debdiff somewhere and have it uploaded from someone else
[18:55] <webwolf_27> Night folks I need to put the kids in bed
[18:57]  * sistpoty|work is now heading home
[18:57] <sistpoty|work> everyone cross fingers that murphy-geser is wrong *g*
[18:57] <\sh> sistpoty|work, would you like to remove the source.changes file, just because it's annoying if someone can't access it ;)
[18:57]  * persia would like to retain the source.changes file for reference by REVU Admins
[18:58] <sistpoty|work> \sh: no .changes file is accessible (that's the upload ticket)
[18:58] <\sh> sistpoty|work, yeah that's what I meant, can't we get rid of it after the package occurs on the list?
[18:58] <sistpoty|work> \sh: and what persia said, sometimes it's good to have these still around (e.g. like for your upload)
[18:58] <\sh> sistpoty|work, hmm..ok, just don't print it then ;)
[18:58] <persia> \sh: The issue is that one can sponsor uploads to REVU, and only examination of the .changes file can determine the sponsor.
[18:58] <pochu> persia: will you upload lashwrap if I advocate it? My only concern is copyright not listing the years and the upstream email. If you are going to fix&upload, I'll advocate. Otherwise I won't until the packager fixes that.
[18:59] <persia> vemon: You around?
[18:59] <\sh> if someone wants to do me a favour: http://revu.tauware.de/details.py?package=libdaemon-generic-perl ;)
[18:59] <vemon> persia, i'm here
[18:59] <sistpoty|work> \sh: well, not too sure... if I could easily find the point where the files are definitely safe on the list, yes. (but the whole incoming-processing is a crude, crude hack, so it's quite tough to say that everything went fine(
[19:00] <persia> vemon: Can you fix the issues pochu found please?
[19:00] <sistpoty|work> <- now really afk
[19:00] <sistpoty|work> cya
[19:00] <\sh> sistpoty|work, interessted in changing revu into a django app? ;)
[19:00] <pochu> vemon: commented.
[19:00] <vemon> persia, yes i can. what's the problem with the email?
[19:00] <vemon> ok i'll check
[19:01] <sistpoty|work> \sh: why not... but that would probably mean a complete rewrite (actually siretart started with some django stuff already for revu2ng, but maybe this will also be vaporware for quite some time)
[19:01] <persia> pochu: Thanks a lot for looking at those.
[19:01] <stani> ScottK: can I debug pychecker on gutsy or do I need a hardy machine for it?
[19:02] <pochu> persia: anytime
[19:02] <pochu> hey stani
[19:02] <ScottK> Gutsy should be fine AFAIK.  The real issue is Pyhton 2.5.
[19:02] <\sh> sistpoty|work, I was working on an app for doing some autobuilds with separated sbuild daemons ;) well, just a rewrite of dak actually but understandable for the human being ;)
[19:02] <stani> ha pochu!
[19:02] <sistpoty|work> \sh: heh :)
[19:03] <\sh> sistpoty|work, I'm just worked  on the archive management system...
[19:03] <stani> pochu: did you receive my spe tarball?
[19:03] <persia> smagoun: We were discussing bug #188130 earlier.  If you could respond to lool's question, I'd be willing to upload...
[19:03] <ubotu> Launchpad bug 188130 in moblin-image-creator "Update moblin-image-creator to 0.39" [Wishlist,Incomplete] https://launchpad.net/bugs/188130
[19:04] <vemon> pochu & persia, made the changes to lashwrap and re-uploaded to revu
[19:04] <pochu> stani: heh, I didn't see it was attached to the mail :) I was going to ask you where was the tarball, or just to repackage it myself ;)
[19:05]  * persia seeks another willing volunteer to review http://revu.ubuntuwire.com/details.py?package=lashwrap in 7 minutes
[19:05] <pochu> stani: I'll see if it still happens with that tonight. Thanks for it.
[19:05] <pochu> persia: with your +1 and mine, isn't that done?
[19:05] <\sh> persia, I can do, if you review libdaemon-generic-perl, pls :)
[19:05] <persia> pochu: New upload trumps advocations.
[19:05] <ScottK> persia: What is lashwrap?
[19:06]  * asantoni is looking for an advocate for LP #190589 (fixed version tag)
[19:06] <ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Wishlist,New] https://launchpad.net/bugs/190589
[19:06] <pochu> persia: does that mean you won't re-advocate it?
[19:06] <pochu> persia: (I know)
[19:06] <persia> ScottK: A small wrapper program that enables Linux Audio Session Handling for non-compliant applications.
[19:06] <afflux> a package I requested a sync for FTBFS on all architectures with 'dpkg-gencontrol: failure: cannot read -: No such file or directory'. It builds fine in my hardy pbuilder. Is that a known issue?
[19:06] <sistpoty|work> cya folks
[19:07] <persia> pochu: I'll re-advocate if the changes aren't insane, but my queue is currently full enough that if someone else went first, it would simplify things :)
[19:07] <ScottK> afflux: When did it FTBFS?
[19:07] <AstralJava> afflux: I got a notification from one of the admins that a new dpkg got in recently, and things should work now again.
[19:08] <geser> afflux: pkgname?
[19:08] <ScottK> afflux: ^^^ If it happened ~18 hours + or - a few, then it's  likely the dpkg issue
[19:08] <pochu> persia: ah, ok. I was thinking on a one-line-change on debian/copyright, so it would be pretty straightforward. :)
[19:08] <geser> afflux: there was a bug in dpkg which broke packages during dh_strip
[19:08] <afflux> geser, ScottK: it's libotr, one build was: https://edge.launchpad.net/ubuntu/+source/libotr/3.1.0-2/+build/511614 - it says "15 hours ago"
[19:08] <persia> pochu: If that's the debdiff, certainly.
[19:09] <smagoun> persia: I can repack moblin-image-creator and fix the maintainer. I've already added the ubuntu-specific changes to the package. Is that what you mean?
[19:09] <ScottK> It should get retried automatically as there is supposed to be a mass giveback.
[19:09] <persia> afflux: That would be during the broken time.  It likely got rebuilt since.
[19:09] <\sh> pochu, i'm on it :)