[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 2.20.2.1 (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 (4.69.132.117)       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 (195.72.130.230)            asymm  8  18.089ms
[05:25] <\sh>  6:  gw0-0-gr.canonical.com (91.189.88.10)                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:        91.89.0.0 - 91.89.127.255
[05:38] <\sh> StevenK, could you try to reach buildserver.homelinux.net?
[05:40] <StevenK> 22. 172.30.22.2                       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 http://revu.ubuntuwire.com/lostpw.py?email=emmet.hikory@gmail.com and http://revu.ubuntuwire.com/lostpw.py?email=persia@ubuntu.com 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 <kov@debian.org>
[17:26] <DktrKranz> HighNo: your change must replace it with:
[17:26] <DktrKranz> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[17:26] <DktrKranz> XSBC-Original-Maintainer: Gustavo Noronha Silva <kov@debian.org>
[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 :)
[19:09] <persia> smagoun: Yes, assuming the Ubuntu-specific changes include the changelog changes.
[19:10] <mruiz> hi all
[19:10] <afflux> persia: ah, didn't check that. It's been successfully built (again, 15 hours ago according to launchpad)
[19:10] <geser> afflux: there was a massive give-back today night or morning and it build now successfully
[19:10] <pochu> \sh: on what? :)
[19:10] <afflux> thank you
[19:10] <smagoun> persia: I think the Ubuntu-specific changelog entries made it in, but I don't remember. I'll be sure to check. I need a day or so to fix it, I have some deadlines today
[19:10] <vemon> persia, it actually is a one-line-change to copyright + linebreak arrange to fit control to 80 chars width :)
[19:10] <\sh> pochu, lashwrap
[19:11] <smagoun> persia: thanks, by the way!
[19:11] <pochu> \sh: I guess you want to wait for the update then ;)
[19:11] <pochu> \sh: thanks anyway :-)
[19:11] <\sh> pochu, yes...
[19:11] <\sh> pochu, what else? I would need some reviewers too ;)
[19:11] <persia> smagoun: OK.  I'm just worried about FeatureFreeze, which would then require a freeze exception making it more difficult.  I think you have about 29 hours, but I can't promise to be able to upload that whole time :)
[19:12] <smagoun> persia: Understood. thanks.
[19:13] <mruiz> I got a lintian error: http://pastebin.ubuntu.com/4510
[19:13] <vemon> is it ok to use wget instead of uscan in get-orig-source? i'm having a hard time extracting the version number from the uscan download :/
[19:13] <\sh> mruiz, https://bugs.edge.launchpad.net/ubuntu/+source/dpkg/+bug/191324
[19:13] <ubotu> Launchpad bug 191324 in dpkg "dpkg-genchanges.pl missing the "Description" field in *_source.changes files" [Undecided,New]
[19:13] <\sh> mruiz, fix is in the report :)
[19:14] <mruiz> thanks \sh
[19:14] <\sh> mruiz, just waiting for the upload...so it'll resolve by itself in time :)
[19:14] <mruiz> hehehe
[19:15]  * mruiz hugs \sh 
[19:15] <\sh> if slangasek would be cool, he could do it ;) because he has main powers ;)
[19:15]  * persia hopes someone remembers the uscan --dehs | sed ... trick and can provide vemon a pointer
[19:16] <vemon> well i'm trying to use it :) but it doesn't work for some reason
[19:17] <vemon> haven't fooled around with makefiles that much so i'm not really sure about the notation/syntax
[19:17] <jdong> persia: is sed supposed to be used to parse XML? :D
[19:17] <persia> vemon: Look through some of the recent archived double-advocated packages on REVU.  I've seen it often in the past couple days, but don't remember
[19:17] <vemon> jdong, yes.. "parse" :)
[19:17] <persia> jdong: Why not.  XML is text, isn't it?
[19:17] <jdong> persia: are there not better tools for this, though?
[19:17] <jdong> persia: seems a bit low-level to me
[19:17] <vemon> it works ok when executed from the shell but not in the makefile
[19:18] <ScottK> jdong: The best tool is the one you have in hand and know how to use.
[19:18] <vemon> ScottK, agree :)
[19:18] <vemon> though now always
[19:18] <persia> jdong: The advantage of sed over all other XML processors is that it is installed on every developer's workstation.
[19:18] <jdong> persia: true :)
[19:18] <vemon> it's also installed on every non-developers linux desktop'
[19:19] <persia> That means that any given developer is more likely to be able to get the newest upstream with debian/rules get-orig-source, which helps us work as a team.
[19:19] <persia> vemon: Yes, but non-developers aren't expected to use get-orig-source :)
[19:19] <\sh> persia, what is wrong with <url> \ debian uupdate?
[19:20] <persia> \sh: Fails for non tar.gz.  --repack helps for .tar.bz2, but .zip or stripping files for DFSG, etc. requires get-orig-source.
[19:21] <\sh> persia, phew...good to know that many perl packages are in tar.gz format ;)
[19:22] <\sh> bah...this IS BAD
[19:22] <jdong> https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
[19:22] <\sh> Copyright (C) 2003 Uri Guttman <uri@stemsystems.com> but according to cpan the actual author is someone else...what to write in debian/copyright now...
[19:22] <jdong> it's the 2nd example listing there, vemon
[19:23] <vemon> jdong, that's the one i've been trying to use
[19:23] <HighNo> can debdiff compare a .deb file with a file structure or do I have to generate the package via debuild first and afterwards do a debdiff between both deb's ?
[19:23] <vemon> jdong, i think i just (finally!) got it working. still can figure out what was wrong in the first place :)
[19:23] <vemon> can't
[19:25] <mruiz> bye guys
[19:25] <crevette> persia have you some time today to look at http://revu.tauware.de/details.py?package=obex-data-server ?
[19:25] <vemon> persia, what was the directory i was supposed to put the whysynth licensing patch?'
[19:26] <pochu> vemon: advocated
[19:27] <persia> vemon: I think I suggested debian/upstream-patches because the patch was from upstream, and you were applying it to the orig.tar.gz (upstreams should actually release code rather then sending patches).  Different directory names might also work: there's no guideline for this.  Be sure to write about it in README.Debian-source
[19:27] <persia> crevette: Unlikely, but I'll take a look if I do.
[19:27] <vemon> persia, ok. thanks! i think i'll have a new upload soon
[19:27] <vemon> pochu, thanks to you too! :)
[19:28] <crevette> persia: at least, thanks
[19:29] <stani> ScottK: pychecker in hardy seems still at -3, which is incompatible with spe. Is it possible to sync it to -7? I'll see if I can fix the FTBS of -3 for now, but it would be better to have -7 in the repos.
[19:30] <ScottK> stani: -7 still FTBFS.  Figure the fix for that.  Give me a patch, and I'll upload it.
[19:30] <ScottK> stani: Don't worry about -3
[19:31] <geser> RainCT: your scrapbook FTBFS on !i386 is because iceweasel-scrapbook is arch:any instead of arch:all
[19:32] <ScottK> bddebian: How come your testresources fix FTBFS in Ubuntu?
[19:33] <RainCT> geser: Oops. And why does it fail because of that? :/
[19:33] <bddebian> ScottK: I didn't know it didn't.  I'll try to look at it
[19:34] <DktrKranz> Riddell, have you a couple of minutes to look at dspam upload?
[19:34] <ScottK> bddebian: I'm building it again now (it built when I asked for the sync).  It may have gotten caught in yesterday's dpkg mess.
[19:35] <bddebian> Aye, I know my lordsawar sync did :-(
[19:35] <geser> RainCT: on !i386 the binary-arch target is used which doesn't do anything useful
[19:36] <ScottK> bddebian: It builds for me.  I'm gonna ask for a give back.
[19:36] <bddebian> OK, thanks man
[19:36] <geser> stani: pychecker fails to build with python2.5 so syncing doesn't improve the situation
[19:38] <RainCT> geser: ok, thanks!
[19:39] <Riddell> DktrKranz: where?
[19:39] <paas> Hi, can someone have a look at http://revu.tauware.de/details.py?package=libtuxcap, It's ready for advocation, thanks
[19:39] <DktrKranz> Riddell, feisty-proposed, the one you rejected some minutes ago
[19:39] <\sh> guys, again, I'm not sure I understand our advocating system now, even when a motu uploads to revu, he shouldn't be able to advocate itself for the package, right or wrong?
[19:40] <Riddell> DktrKranz: nothing in there currently
[19:41] <DRebellion> Hardy feature freeze is on the 14th. Does this mean packages can still be submitted on this day (14th)?
[19:42] <DktrKranz> Riddell, I know. It has been rejected (https://bugs.edge.launchpad.net/ubuntu/+source/dspam/+bug/158252/comments/29). You stated gutsy already has 3.6.8-4ubuntu1.1, but I'm unable to see it on LP.
[19:42] <ubotu> Launchpad bug 158252 in dspam "dspam won't start:  /var/run/dspam missing in tmpfs" [Medium,Confirmed]
[19:42] <ScottK> DRebellion: They can be uploaded on that day, but they have to be approved first.  They are rarely approved on the first try.
[19:42] <Riddell> DktrKranz: ah, looks like I'm entirely wrong
[19:43] <DRebellion> ScottK, its just that i have one in revu that ftbs and i'm waiting on upstream for a fix.
[19:43] <ScottK> Well you'll need to ask them to get moving then ...
[19:43] <persia> DRebellion: Not really.  That's the deadline for packages to be pushed to the archives.  My my count, there are about 28 hours left, which is a very tight timeframe to get two advocates from the already very busy MOTU.
[19:43] <\sh> DktrKranz, gutsy  	current  	release  	3.6.8-5ubuntu1   	 None defined
[19:43] <\sh> 		updates 	3.6.8-5ubuntu1.1 	
[19:43] <\sh> DktrKranz, in updates it is
[19:43] <Riddell> DktrKranz: accepted
[19:44] <DktrKranz> \sh, feisty-proposed would have 4ubuntu1.1
[19:44] <\sh> DktrKranz, ah feisty :)
[19:44]  * DktrKranz hugs Riddell
[19:45] <\sh> I wonder why we can't go with -4ubuntu07.04.1 or something like this for updates
[19:45] <DktrKranz> \sh, it is often used when base versions are the same
[19:45] <ScottK> \sh: You can, but I personally find it unattractive.
[19:46] <\sh> ScottK, well, yes it looks strange, I agree...
[19:46] <HighNo> DktrKranz: I think I have done it now - could you have a look at it?
[19:47] <DktrKranz> \sh, basically you can use ubuntu1, as a normal upload. The rule is "don't clash with past, present or future versions"
[19:47] <HighNo> DktrKranz: Please tell me where to put the debdiff generated file
[19:47] <DktrKranz> !paste | HighNo
[19:47] <ubotu> HighNo: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[19:47] <cbx33> hey all anyone know if deskbar can run in openbox?
[19:47] <cbx33> in pypanel?
[19:48] <\sh> DktrKranz, na I always think when I see "ubuntuX.Y" as of "security fix update" and not "normal update"
[19:49] <DktrKranz> \sh, I think there are issues when releasing a security update after a SRU or viceversa
[19:49] <DktrKranz> having a "common" versioning is simpler
[19:49] <ScottK> I find it helpful when they use the same numbering scheme to keep things straight.
[19:51] <keescook> DktrKranz: -update and -security need to not clash their version numbers
[19:51] <keescook> the way it is supposed to work is that -security builds on top of -updates
[19:51] <keescook> this allows people that only want the -security pocket to still get sane updates.
[19:52] <geser> \sh: xmds depwaits on octave2.1-headers. Will it build/work without it? (it b-d also on octave3.0-headers)
[19:52] <keescook> and -updates must include -security, so the latest release of any given package should always have all security updates applied.
[19:52] <\sh> geser, what? I tested the xmds sync and it build cleanly...I wonder what's that now...
[19:53] <ScottK> \sh: I think you typoe'd the build-depends and left the old one.
[19:53] <\sh> ScottK, it was a sync...
[19:53] <\sh> ScottK, and changelog said explicitly: * debian/control:
[19:53] <\sh>     + Build-depends on octave3.0-headers instead of 2.9
[19:53] <\sh>     + Use ${octave-3-0:Depends} in Suggests field
[19:54] <ScottK> OK.  Then the Debian maintainer did.
[19:54] <DktrKranz> keescook, is it why there are some XubuntuY.5 uploads in -security?
[19:54] <\sh> fixing
[19:54] <\sh> ScottK, could you do me a favour and review two small perl packages? :)
[19:54] <keescook> DktrKranz: for which package?
[19:55] <DktrKranz> keescook, don't remember right now, let me check
[19:55] <ScottK> \sh: sure. I know more about perl packaging than I really want to.
[19:55] <\sh> ScottK, libdaemon-generic-perl and libfile-flock-perl on revu :)
[19:55] <HighNo> DktrKranz: http://paste.ubuntu-nl.org/55786/ - I don't feel god about it as it seems too long and has many filenames in there whereas I only changes the debian/changelog and filters/sessionfilter.py
[19:55] <ScottK> \sh: Link me.  I'll look at them while I wait my tern in the tech board meeting.
[19:55] <ScottK> K
[19:55] <ScottK> tern/turn
[19:55] <\sh> ScottK, http://revu.tauware.de/details.py?package=libdaemon-generic-perl
[19:55] <\sh> ScottK, http://revu.tauware.de/details.py?package=libfile-flock-perl
[19:55] <ScottK> Thanks
[19:56] <\sh> ScottK, oh big day tonight? :)
[19:56] <ScottK2> Yes
[19:56] <rhpot1991_laptop> can anyone translate this for me "* open a needs packaging bug and close it in the changelog "
[19:56] <rhpot1991_laptop> I opened a bug, assigned it to myself
[19:56] <rhpot1991_laptop> do I change the status now too?
[19:57] <DktrKranz> HighNo, that is probably due because you used debuild in a gutsy (or hardy) environment while preparing a revision for feisty
[19:57] <persia> rhpot1991: If you are working on it, change the status to "In-Progress".  Unfortuantely, do to weak support for sponsoring workflow, when you are done, set the status to "Confirmed", and subscribe the sponsors.
[19:57] <DktrKranz> HighNo, if you didn't touch these files, you can omit from your debdiff
[19:58] <HighNo> DktrKranz: the strange thing is - I only used feisty :-)
[19:58] <rhpot1991_laptop> persia ok thanks
[19:58] <rhpot1991_laptop> was just dputing stuff up and not opening any bugs
[19:58] <HighNo> DktrKranz: or does setting up a pbuilder environment for hardy involve changes for the normal debuild ?
[19:59] <geser> \sh: see http://launchpadlibrarian.net/11885637/buildlog_ubuntu-hardy-amd64.xmds_1.6.4-1_MANUALDEPWAIT.txt.gz
[19:59] <DktrKranz> HighNo, no, if you executed debuild outside of the pbuilder environment.
[19:59] <\sh> geser, yeah saw it...I know now why it build these days...because octave2.1 was still in the archives :(U
[19:59] <\sh> geser, just fixing it and uploading
[19:59] <AstralJava> packages.ubuntu.com inaccessible to anyone else?
[19:59] <geser> \sh: thanks
[19:59]  * persia wants an LP Preference "Yes, I always want the complicated bug filing form: it's less complicated".
[20:00] <ScottK2> \sh: As a rule, I think it's nice when you just use the same licensing for the packaging that the package uses.  It simplifies things.  Just kvetching.
[20:00] <persia> AstralJava: rmadison -u ubuntu packagename and apt-cache search packagename are likely more useful anyway.
[20:00] <persia> ScottK: Sometimes people use packaging from samples that complicates that.
[20:01] <\sh> ScottK, actually the upstream source can use both...on cpan it says "the same as perl" and perl is dual licensed, when I understood it correctly
[20:01]  * persia advocates writing all packaging files from scratch
[20:01] <HighNo> DktrKranz: then I don't understand the difference but at least the debdiff is done. I am to put it somewhere with the bug in LP and is there a naming convention for these patches?
[20:01] <ScottK2> \sh: True.  Interestingly enough Perl is still GPL V1+
[20:01] <AstralJava> persia: Thanks, I'll look into them. In this particular case I was worried the mirror I used was out-of-date. Turns out it wasn't, though.
[20:02] <persia> AstralJava: packages.ubuntu.com is often out of date :(
[20:02] <AstralJava> Ahh... gotcha.
[20:03] <AstralJava> So it's been a while since I last setup pbuilder, if my base system is gutsy, didn't its pbuilder have scripts for hardy?
[20:03] <rhpot1991_laptop> persia: you don't have a second to poke at a package and see why debconf isn't working how it should, do you?
[20:03] <\sh> ScottK, when you are on it...I wasn't quite sure about the copyright in libfile-flock* because the version I packaged was uploaded to cpan by dave rolsky, but the original author is someone else...I put both authors in copyright but the next line in copyright I wasn't sure if this is write...if you have a clue about this, please enlighten me :)
[20:03] <\sh> s/write/right/
[20:04] <ScottK2> \sh: I think what's in the code matters.
[20:04] <geser> AstralJava: you need the debootstrap from gutsy-backports to be able to debootstrap hardy
[20:04] <persia> rhpot1991: Not really.  Best to describe the issue and paste the error to a pastebin.
[20:04]  * ScottK2 is mostly paying attention to the tech board meeting right now.
[20:04] <\sh> ScottK, well, I put both in...just to be sure...
[20:04] <ScottK2> \sh: Right.  I'll look at it.
[20:04] <AstralJava> geser: Okay, thanks. I have no recollection of doing that before, but like I said, it's been very long from the last setup. Thanks for the help!
[20:05] <rhpot1991_laptop> persia: thats the problem, no errors, just the note never shows up on install
[20:05] <DktrKranz> HighNo, attach it to the bug in LP and subscribe ubuntu-security
[20:07] <RainCT> \sh: about your review question before, the wiki says «MOTUs can upload new packages directly to the archive. However they are greatly encouraged to have a new package reviewed prior to uploading. (cf. MOTU/Council/Meetings/2007-02-23)».
[20:07] <\sh> RainCT, well, but it doesn't answer the question :)
[20:08] <ScottK2> jdstrand: You mentioned that you might be able to show up for my core-dev application at the tech board meeting.  It's just started (I should be up 2nd).
[20:08] <LaserJock> \sh: what's your question?
[20:08] <\sh> RainCT, even motus are making mistakes, and regarding revu it should be a standard to have another or better 2 more pair of eyes looking over the package
[20:08] <\sh> LaserJock, if motus should advocate their own packages...
[20:09] <LaserJock> oh, I probably shouldn't say anything then :-)
[20:09] <LaserJock> I've usually just poke another MOTU to give an IRC ack and then upload
[20:10] <LaserJock> but I usually don't upload "high risk" stuff
[20:10] <ScottK2> LaserJock: If you have the time/interest, I should be up for core-dev shortly in #ubuntu-meeting.
[20:10] <LaserJock> ScottK2: how shortly?
[20:10] <ScottK2> LaserJock: As soon as they get done torturing TheMuso.
[20:10] <ScottK2> Dunno
[20:10] <LaserJock> ah
[20:10] <\sh> lol
[20:10] <HighNo> DktrKranz: attached, bug status set to "fix comitted" but I am to assign the bug to me or ubuntu-security?
[20:11] <LaserJock> I've gotta teach in 30min or so
[20:11] <LaserJock> I'll hang out as long as I can
[20:11] <persia> \sh: I typically advocate my package if I think it's all set, and don't advocate if I'm just looking for a review and I'm not sure.  Depends how many packages of that type I've touched before.
[20:11] <DktrKranz> HighNo, mark it as Confirmed, do not subscribe anyone and subscribe ubuntu-security
[20:11] <\sh> ScottK, you'll make it...it only looks painful :)
[20:12]  * persia notes the inherent conflict, and notes s/subscribe/assign/1
[20:12] <HighNo> DktrKranz: ehm, "do not subscribe anyone and subscribe ubuntu-security" ?
[20:12] <HighNo> persia: ahh, thanks
[20:12] <HighNo> persia: ubuntu-security = "Ubuntu Security Team"?
[20:13] <DktrKranz> HighNo, my fault, sorry
[20:13] <persia> HighNo: Quite possibly.  I'm not really a good person to ask about security processes.
[20:13] <\sh> HighNo, just add "it's a security bug" checkbox under the very first entry point and remove the "private" flag afterwards when the CVE already be known for the public
[20:14] <\sh> HighNo, and yes, it's ubuntu-security and motu-swat (if it's a universe package) please :)
[20:15] <HighNo> ok, that was already set
[20:15] <\sh> geser, xmds uploaded
[20:15] <rhpot1991_laptop> I wait till I get 2 sponsors before I set the bug to confirmed, correct?
[20:15] <HighNo> so that was it then - I submitted my first security fix ?! :-)
[20:16] <rhpot1991_laptop> learning the week before a feature freeze sure is stressful
[20:16] <\sh> oh wow...they cook TheMuso ;)
[20:18] <leonel> how do I test this  DIFF https://bugs.edge.launchpad.net/ubuntu/+source/dbmail/+bug/191096  ??
[20:18] <ubotu> Launchpad bug 191096 in dbmail "[needs-merge] dbmail_2.2.9-1" [Undecided,Confirmed]
[20:19] <RainCT> \sh: heh. good that I don't want to become core dev, they are scaring me :)
[20:20] <\sh> RainCT, ah come on..it's fun :)
[20:20] <paas> RainCT: Thanks for advocating!
[20:20] <geser> leonel: dget -x http://ftp.debian.org/debian/pool/main/d/dbmail/dbmail_2.2.9-1.dsc; wget http://launchpadlibrarian.net/11877122/dbmail_2.2.9-1ubuntu1.debdiff; cd dbmail-2.2.9; patch -p1 < ../dbmail_2.2.9-1ubuntu1.debdiff
[20:21] <persia> leonel: Run dbmail with postgres 8.3 before and after application.
[20:21] <RainCT> \sh: hehehe
[20:21] <leonel> geser: Thanks
[20:21] <leonel> persia: before it's done there are bugfixes that need  from upstream  and that diff appears to fix them
[20:21] <RainCT> paas: np, thanks for contributing to ubuntu :)
[20:22] <leonel> thank you
[20:24] <paas> your welcome :-)
[20:24] <rhpot1991_laptop> RainCT: I have an easy package that could use a 2nd sponsor
[20:24] <\sh> RainCT, and spending more time with ubuntu, and fixing more packages even for main, you have to become a core-dev someday...because the sponsors don't have the time anymore to sponsor your package fixes ;)
[20:25] <geser> RainCT: you missed the old times where you have to go to a CC meeting to become a MOTU (which included some grilling there)
[20:25] <HighNo> CC meeting?
[20:26]  * persia wonders if being a member shouldn't still be a requirement for being MOTU, but is distracted by FeatureFreeze prep
[20:26] <LaserJock> TB meeting
[20:26] <LaserJock> persia: it's not a requirement?
[20:26] <RainCT> \sh: Yes, sure. I meant I don't want to become one soon, we will see what I do long term.. :)
[20:26] <persia> LaserJock: Not since me
[20:26] <leonel> geser: after patched  just rebuild the package  right ?
[20:26] <LaserJock> persia: ummm, that's not cool
[20:27] <persia> LaserJock: Please raise it at a MOTU Meeting.  I won't make this weeks, but I'll back you up on the 29th if you are available then.
[20:27] <RainCT> LaserJock: no, if you are accepted as MOTU you also become a member, I think
[20:27] <RainCT> geser: :D
[20:27] <LaserJock> hmm
[20:27] <geser> HighNo: Communit Counsil
[20:27] <LaserJock> with the new structure I don't know how it would work
[20:28] <HighNo> geser: ahh, thx
[20:28] <persia> RainCT: That is the current process.  Previously, you had to be a member to apply (which I thought was good).  There was a timing mixup with the new process, and a non-member was accepted.  Since then, the requirement has been waived.
[20:28] <RainCT> LaserJock: and LoCo Council will also be able to appoint members soon
[20:28] <LaserJock> it used to be you could get simultaneous membership in some cases, but certainly not the normal
[20:28] <geser> leonel: yes, as usual
[20:28] <leonel> geser: thanks
[20:28] <DktrKranz> keescook, I'm unable to find any example of XubuntuY.5, probably I am wrong.
[20:28] <LaserJock> well, but many teams require Ubuntu membership prior to team membership
[20:28] <persia> RainCT: Not LoCo Council: Regional Membership Councils.
[20:29] <keescook> DktrKranz: well keep an eye out -- you never know if something went goofy.  :)
[20:29] <LaserJock> so MOTU could actually be less strict, which doesn't make sense in terms of the importance of MOTU
[20:29] <persia> LaserJock: Raise it at a meeting.  Discussion here can't change anything.
[20:29] <LaserJock> sure, but that seems to be a TB/CC issue, IMO
[20:30] <TheMuso> ScottK2: I would call it challenging me. I'm enjoying this.
[20:31] <persia> LaserJock: Not really.  Delegated to MC.  MC takes guidance on policy from MOTU.  A MOTU Meeting discussion followed by mailing list discussion would likely result in MC comment.
[20:31] <LaserJock> but the TB is ultimately in charge of MOTU membership and CC of Ubuntu membership
[20:32] <persia> LaserJock: Yes, and both groups have delegated to MC.  MC is able to take the decision.  I suspect MC would listen to MOTU Consensus about it.
[20:32] <\sh> LaserJock, the MC can now approve motus themselves, when I'm not wrong...and you can only become a core-dev after having some cheering from MC and other core-devs
[20:33] <persia> \sh: Yes and no.  MC doesn't cheer, so much as administer the core-dev application process.
[20:33] <persia> (although some members of MC are core, and may also be sponsors)
[20:33] <LaserJock> persia: yes, I realize they have delegated, but they have not delegated requirements for MOTUship, as far as I know
[20:33] <geser> LaserJock: dholbach adds the new MOTUs to ~motu if there are enough +1 from the MC members
[20:33] <LaserJock> uggg
[20:33] <LaserJock> I *know* how MOTUship is granted
[20:33] <persia> LaserJock: Any MC member can add members to MOTU at will.
[20:34] <persia> The MC follows the MC process to grant MOTU based on TB and CC direction.
[20:34] <LaserJock> I'm saying that MC acts only upon delegation from TB/CC and are subject to their requirements
[20:34] <\sh> persia, yeah, cheering wasn't meant like "uh his good..why not" more that they give the advice or much better a councelor for the TB
[20:35] <LaserJock> I believe that the TB/CC set MOTUship requirements, MC is supposed to be "executive" branch instead of a "legislative" branch when it comes to MOTUship, as I understand it
[20:35] <persia> \sh: MC only compiles the application for core-dev, but makes the decision for MOTU applications.  There are cases of MC turning down core applications, but more because it was incomplete than because of MC decision.
[20:35] <persia> MC is not executive.
[20:35] <persia> If anything, MC is judicial.
[20:36] <LaserJock> hmm, yeah, judicial is better
[20:36] <LaserJock> in any case, my understanding was that MC was to figure out how to apply the requirements, not necessarily make them up
[20:36] <persia> MOTU as a body propose/discuss/plan/initiate and individual developers (MOTU+Contributors) execute.
[20:37] <RainCT> rhpot1991_laptop: oops, oversaw your message. URL?
[20:37] <\sh> oh ... when I
[20:37] <rhpot1991_laptop> RainCT: http://revu.tauware.de/details.py?package=atomicparsley should be good to go
[20:38] <LaserJock> anyway, I don't really care so much
[20:38] <\sh> I'm reading the discussion now on -meeting, I wonder how people actually would want to package software at all ;)
[20:38] <persia> LaserJock: Not even enough to raise it at a meeting?
[20:38] <LaserJock> I'm just surprised that Ubuntu membership is not a requirement for MOTUship
[20:38] <LaserJock> I might enough for an email
[20:39] <LaserJock> hopefully I can make the MOTU meeting, but I can't guarantee it
[20:39] <crevette> rhpot1991_laptop: are you a motu ?
[20:39] <crevette> and are you available for a review
[20:39] <rhpot1991_laptop> nope :(
[20:39] <rhpot1991_laptop> its questionable as to if I even know what I am doing :P
[20:40] <persia> LaserJock: Understood.  Mail would be a step.
[20:40] <RainCT> superm1: you might want to advocate atomicparlsey again, since your last advocation the only change was in debian/control formatting (http://revu.tauware.de/diff.py?upid1=1917&upid2=1945)
[20:41] <rhpot1991_laptop> RainCT: he knows whats going on, but is at work now
[20:41] <\sh> LaserJock, I wonder if it makes a change...
[20:41] <LaserJock> persia: hmm, MC granting membership could provide a "we think your on your way to MOTUship" step that might be helpful
[20:42] <\sh> LaserJock, the former method of becoming a member first then a motu and hopefully then a core was a hard way...and frightend some people to stay away from ubuntu at all...
[20:42] <LaserJock> well
[20:42] <rhpot1991_laptop> LaserJock: I have this one too (http://revu.tauware.de/details.py?package=mythexport) but it has a debconf issue that is driving me crazy
[20:42] <LaserJock> frankly if you can't do "significant and sustained contribution to Ubuntu" then you shouldn't be a MOTU
[20:42] <vemon> hi! the whysynth pkg with modified get-orig-source & Readme.debian-source is now in revu: http://revu.tauware.de/details.py?package=whysynth
[20:42] <persia> LaserJock: I very much agree with that.  I've been thinking about ways to better organise the Contributors into a team with some identity, and think that is part of the solution, but don't have a good plan yet.
[20:42] <\sh> LaserJock, which doesn't mean it's bad in the first place...but people come people go noone can say what's the best for the project at all...
[20:43] <vemon> could someone also check out my package which already has one advocation: http://revu.tauware.de/details.py?package=lashwrap
[20:43] <LaserJock> so the basic technical requirements for MOTUship should be 1) signed CoC 2) signed gpg key 3) Ubuntu memebership (needs 1. for this but it's a useful separation)
[20:43] <\sh> vemon I'm on it
[20:43] <persia> \sh: Or just ignore the process.  I wasn't a member for two years because it was too much trouble (despite pushing patches).
[20:44] <LaserJock> alrighty, I gotta run to lab
[20:44] <persia> \sh: The issue is that now MOTU is sometimes seen as the first step, and it can be frustrating to take 6-12 months to become MOTU.
[20:44] <geser> persia: do you believe you would have applied earlier with the current process?
[20:44] <\sh> persia, the problem I see actually is that people stay focused ...
[20:45] <\sh> persia, which is one of the difficult problems...
[20:45] <persia> geser: Yes.  I had three MOTU advocates in Dapper.
[20:45] <\sh> persia, and a simple process or a difficult process doesn't really solve this
[20:46] <persia> \sh: Yes.  That's a separate problem.  I just think giving out Membership earlier to those who are showing sustained effort and ask would help keep more of the Contributors active.  Keeping people longer-term is harder.
[20:46] <\sh> vemon, uploading now :)
[20:47] <RainCT> rhpot1991_laptop: please convert the binary and manpage names to all lowercase
[20:47] <\sh> persia, and that's the problem actually...what is "sustained efford"
[20:47] <zul> TheMuso: congrats..
[20:47] <vemon> \sh, great! :) this was my first uploaded package
[20:47] <TheMuso> zul: THanks.
[20:47] <rhpot1991_laptop> RainCT: its ok to do that when thats how the author has it happening?
[20:48] <\sh> vemon, good work :) thx :)
[20:48] <HighNo> hm, how long does it take from upload to being available via apt-get ? [universe is enabled]
[20:49] <goobsoft> Are menus best implemented with the freedesktop's Desktop Entry Specification rather than menufile(s) now?
[20:49] <persia> \sh: Used to be two months of solid work.  Last I heard it was getting closer to six.  Not really well defined.
[20:49] <\sh> HighNo, depending on the time your build needs, depending on the syncs of the mirrors you use, between 15 mins and 8 hours ,->
[20:52] <slangasek> TheMuso: congrats :)
[20:52] <jpatrick> TheMuso: congrats :)
[20:52] <sboden> \sh: or longer...  1 package that was uploaded yesterday doesn't even show up now
[20:52] <\sh> persia, well until this isn't resolved and until we don't have any clean standards on this, I think right now, it's for many contributors much easier to become a vital part of ubuntu (actually for the software part) ... others are doing different work, but this I don't see actually...
[20:53] <\sh> sboden, a new one? so it's in the new queue most likely
[20:53] <persia> \sh: For development types, yes.
[20:53] <geser> TheMuso: congrats :)
[20:54] <sboden> \sh: no an update, "kmess" from v1.4.3 to 1.5 ... but 1.5 is not yet available it seems
[20:54] <geser> sboden: if the package has to pass source (and/or binary) NEW it takes longer
[20:54] <RainCT> rhpot1991_laptop: I think so, unless you have a good reason to don't change it
[20:54] <rhpot1991_laptop> I wasn't cause thats how the author did it
[20:55] <rhpot1991_laptop> I suppose I can change it as long as I get the install file to copy the file like I say
[20:55] <rhpot1991_laptop> already working on it
[20:55] <\sh> sboden, https://edge.launchpad.net/ubuntu/hardy/+source/kmess/1.5-0ubuntu1
[20:55] <\sh> sboden, https://launchpad.net/ubuntu/hardy/+source/kmess/1.5-0ubuntu1
[20:56] <sboden> \sh: cool... doesn't show in apt-get though? Or am I missing something?
[20:56] <TheMuso> thanks folks
[20:56] <RainCT> rhpot1991_laptop: ok. you'll need to do something in debian/rules to rename them as install only copies files (doesn't rename)
[20:56] <RainCT> s/install/dh_install
[20:56] <rhpot1991_laptop> is it really a big deal to keep it with the caps?
[20:57] <\sh> sboden: it's there. https://edge.launchpad.net/ubuntu/hardy/+source/kmess/1.5-0ubuntu1
[20:57] <\sh> argl
[20:57] <\sh> Inst kmess (1.5-0ubuntu1 Ubuntu:8.04/hardy)
[20:57] <\sh> Conf kmess (1.5-0ubuntu1 Ubuntu:8.04/hardy)
[20:57] <rhpot1991_laptop> I would think that would be better for cross platform results, say my script calls AtomicParsley, now it breaks on ubuntu cause we have ours as atomicparsley
[20:57] <vemon> how much time until the feature freeze now?
[20:57] <RainCT> hm.. what do you other guys think about this (is it ok for a binary to have capital letters)?
[20:57] <rhpot1991_laptop> which mythexport does
[20:57] <\sh> sboden: which mirror and did you do an apt-get update? ,-)
[20:57] <rhpot1991_laptop> and the manpage just matched the binary
[20:58] <persia> RainCT: There are a few that do, although it is not preferred.  Depends on why.
[20:58] <rhpot1991_laptop> persia: thats what the source did, and I didn't want to change it
[20:59] <persia> rhpot1991: It would be your responsibility as the packager to convince upstream that mixed-case is namespace-confusing, but it's not an absolute block to archive inclusion.  On the other hand, mixed-case package names are an absolute block.
[20:59] <HighNo> RainCT:from the users point of view it is quite annoying. If I were to decide I'd vote against it. My original package name is mixed case - but the executable has to be all lower case
[21:00] <sboden> \sh: deb http://be.archive.ubuntu.com/ubuntu/ hardy-updates multiverse ?
[21:00] <RainCT> TheMuso: congrats :)
[21:00] <TheMuso> RainCT: Thanks.
[21:01] <rhpot1991_laptop> I'll change it then, seems to be the consensus
[21:01] <\sh> sboden, it's there: http://be.archive.ubuntu.com/ubuntu/pool/universe/k/kmess/ but only the amd64 one
[21:02] <persia> rhpot1991: If you change it, and upstream doesn't, you'll be incompatible with all other installations, which is not preferred.
[21:02] <sboden> \sh: ok... I have time, I already have kmess 1.5 on my kubuntu :D
[21:02] <rhpot1991_laptop> ok, so don't change it then?
[21:03] <persia> rhpot1991: Convince upstream to change it.  Once they do, apply a debdiff flattening the name to hardy (it will be after FeatureFreeze)
[21:03] <\sh> sboden, well it's the mirror...de/be doesn't have the i386 package actually..but archive.ubuntu.com has it
[21:04] <rhpot1991_laptop> ok, I'll try that, that good RainCT?
[21:04] <sboden> \sh: ok, I'll try uninstalling and restalling from the main one
[21:05] <sboden> Does this group also apply the patches in launchpad for ubuntu fixes, or is that another group?
[21:05] <RainCT> rhpot1991_laptop: if you'll try to convince upstream, yes
[21:07] <TheMuso> ScottK2: Congrats!
[21:07] <geser> ScottK2: congrats
[21:07] <slangasek> ScottK: muhahaha, sucker
[21:07] <slangasek> oh, er
[21:07] <slangasek> ScottK: congrats!
[21:07] <TheMuso> lol
[21:07] <zul> ScottK: congrats...no sweat
[21:07] <ScottK> geser and slangasek: Thanks.
[21:07] <ScottK> zul too
[21:08] <RainCT> ScottK: congrats
[21:08] <vemon> persia, going to bed now. check out whysynth if you still have an empty time slot somewhere :)
[21:08] <\sh> ScottK, you did it :) nicely done :)
[21:09] <ScottK> Thanks
[21:09] <RainCT> rhpot1991_laptop: Section: unknown
[21:09] <persia> vemon: Sleep well.
[21:10] <RainCT> rhpot1991_laptop: choose a section for it (you can find a list of all sections with their description on http://packages.ubuntu.com/hardy), and also let the short description in debian/control start with lowercase
[21:10] <RainCT> rhpot1991_laptop: and close a LP bug in the changelog
[21:11] <\sh> ScottK, now break kde4 ,-)
[21:11] <TheMuso> \sh: lol
[21:11] <\sh> well, I meant: break gnome and fix kde4....this way
[21:12]  * ScottK is more worried about kde4 not breaking KDE3.
[21:13] <sboden> I have another small (ubuntu specific) bugfix ready, this time for amarok mp3 : https://bugs.launchpad.net/ubuntu/+source/amarok/+bug/187406
[21:14] <ubotu> Launchpad bug 187406 in amarok "[hardy] Amarok install-mp3 fails silently" [Undecided,New]
[21:16] <Nightrose> apachelogger__: ^
[21:16] <Nightrose> sboden: nice :)
[21:17]  * apachelogger__ should adopt sboden
[21:17] <sboden> lol :D... Is this the right group to get such a bug fix applied, or is there another one?
[21:17] <\sh> Apachelogger to Sboden: "I'm your father" ,->
[21:18] <Nightrose> *lol*
[21:18] <apachelogger__> sboden: technically it would be kubuntu-devel since amarok isn't part of universe, but main
[21:18] <apachelogger__> sboden: is adept_batch installed?
[21:19] <sboden> apachelogger_: on kubuntu yes... the line before the fix checks whether it's installed executable
[21:20] <sboden> apachelogger_: it's in fact an ugly script to do all kinds of update managers, but right now the kubuntu bits are broken
[21:21] <apachelogger__> yeah, the script is not what I would like to see on a sunny day
[21:21] <apachelogger__> sboden: why is the patch so big?
[21:23] <sboden> apachelogger: don't know... I took original dget -x ...dsc; change script; dch -i; debuild -S -sa
[21:23] <crimsun> DktrKranz: pong
[21:24] <apachelogger__> sboden: oh, for such a change, please only attach a patch for the file
[21:24] <DktrKranz> crimsun, do you plan to have a look at bug 55706 soon?
[21:24] <ubotu> Launchpad bug 55706 in python-uncertainities "python-uncertainities python2.3/2.4 breakage." [Medium,Confirmed] https://launchpad.net/bugs/55706
[21:24] <apachelogger__> sboden: or create a debdiff in case you also add an changelog entry etc.
[21:24] <persia> So...  There's a netbeans on REVU.  It now builds with stuff in the archive or in NEW.  It's a lot cleaner than the netbeans we have.  Anyone object to me just uploading?  It won't pass REVU easily, as it still isn't 100% packaging clean (although this can be fixed post-feature freeze).
[21:24] <crimsun> DktrKranz: I can look now
[21:24] <persia> I think the licensing is good, but there are 3000 source files, and I have to admit I've not read them all carefully.
[21:25] <persia> If anyone has time now to give it a look, and make any suggestions for things to fix before I might upload, I'm more than willing to listen.
[21:26] <crimsun> DktrKranz: oh, that's just missing administrivia; feel free to "hijack" it from me as necessary
[21:27] <crimsun> DktrKranz: i.e., no, I don't plan to do anything further with it presently.
[21:27] <frafu> RainCT: thanks for reviewing, correcting and uploading the upgrade of mousetweaks yesterday :-)
[21:27] <DktrKranz> crimsun, debdiff seems good, I need to check if it is still valid and eventually "sponsor" you (I know, it sound weird)
[21:28] <RainCT> frafu: yw :)
[21:31] <rhpot1991_laptop> RainCT: just uploaded those changes, gotta drive home through the snow now, hit up rhpot1991 if you see anything else and I'll respond when I get home, thanks
[21:33] <crimsun> DktrKranz: still valid, yes.
[21:33] <DktrKranz> crimsun, ok. I'll go for the upload, then
[21:34] <slangasek> lool: congrats
[21:36]  * persia wants an Apache Derby package to replace sunwderby and sun-java6-javadb and the sun-javadb on REVU.
[21:36] <lool> slangasek: Thanks!
[21:41] <TheMuso> lool: Congrats!
[21:41] <sboden> apachelogger_: debdiff now also attached to LP #187406 (+ additional change to use absolute path for adept_batch)
[21:41] <ubotu> Launchpad bug 187406 in amarok "[hardy] Amarok install-mp3 fails silently" [Undecided,New] https://launchpad.net/bugs/187406
[21:41] <lool> TheMuso: Thanks again!
[21:46] <persia> pochu: I can't get the get-orig-source for libini4j to work.  Would you mind if I upload with just a watch file?  While uscan seems to talk to sourceforge just fine to check the version, it won't download the zip file.
[21:56]  * persia , rapidly running out of functional attention, uploads libini4j-java and netbeans, expecting to address any complaints post-NEW.
[21:57] <warp10> MOTUs, please review my package gbemol (a graphical frontend for MPD). http://revu.ubuntuwire.com/details.py?package=gbemol
[22:02] <mr_pouit> mmh, I forgot the "REVU:", too bad ;/
[22:02] <persia> mr_pouit: No issues.  At least the package got in :)
[22:02] <mr_pouit> ^^
[22:06] <ScottK> \sh_away: I'd prefer to see your packages with less restrictive licensing (i.e. put all the possible options in debian/copyright and not just Artistic).
[22:07] <persia> AnAnt: My apologies, but I've run out of time.  I won't be able to review ubuntume-gdm-themes for at least another 14 hours, which may well be far too late.
[22:11] <RainCT> lool: gratz
[22:14] <RAOF> persia: Thanks very much for your review.
[22:15] <persia> RAOF: Sorry I couldn't get anywhere with do-plugins, but you've other fans :)
[22:15] <RAOF> persia: That's fine.  It needs gnome-do to build, so it's harder.
[22:17] <persia> RAOF: If also needs some combination of things that cannot be satisfied by the current archives.  I was getting snakeoil related errors trying to manually install the build-deps in a clean chroot.
[22:17] <persia> I'm sure it's fine for an already installed system, but the buildds might choke.
[22:17] <RAOF> I built it in a schroot yesterday.
[22:18] <RAOF> So it can work.  Maybe the archives are a little bit churned this close to FF :)
[22:20] <persia> Very likely.  We need more freeze deadlines to spread out the load :)
[22:21] <RAOF> Hm.  The new FSF address is 51 Franklin st, yes?
[22:22] <persia> RAOF: less /usr/share/lintian/checks/copyright-file.desc
[22:22] <RAOF> Ah.  Cool.
[22:22]  * RAOF was using common-licenses/LGPL-2.1
[22:22]  * persia notes that the world will break between when the FSF moves and that file is updated.
[22:23] <crimsun> RAOF: for GPLv2, yes.
[22:24] <RAOF> crimsun: Thanks.  Found time to test the multiarch alsa? :)
[22:24] <DktrKranz> does anybody know if python-support is able to substitute ${python:Depends} with "python2.4" instead of "python (<< 2.5)" ?
[22:24] <crimsun> RAOF: no, sorry, not yet.
[22:25] <crimsun> RAOF: between work and commuting, getting a reliable update is rather difficult
[22:25] <RAOF> That's fine.  Just curious.
[22:25] <POX__> DktrKranz: use hardcoded python version in hashbang
[22:25] <RainCT> rhpot1991: only a little detail and you have my advocation :); see my comment on REVU.
[22:25] <POX__> or try dh_pysupport's "-V" option
[22:26] <POX__> (dunno if the second one will work)
[22:26] <DktrKranz> POX__, I wanted to avoid hardcoded dependencies
[22:26] <POX__> DktrKranz: so why do you want python2.4 in Depends ?
[22:27] <RAOF> pysupport -V should give depends of python >> 2.3 and python << 2.5, right?
[22:28] <DktrKranz> POX__, because package is compatible with python2.4 only, and it won't install because Ubuntu ships python >= 2.5
[22:29] <RainCT> DktrKranz: well, so you need to hardcode the shabang to python2.4 anyways, as else it would execute it with 2.5 even if 2.4 is installed
[22:29] <persia> DktrKranz: Depending on what the package does during build, you may need to hardcode python2.4 in debian/rules anyway, or end up with #!/usr/bin/python in your script files.
[22:30] <DktrKranz> IIRC, shebangs are already OK, but I'll have a look.
[22:30] <persia> RainCT: Even hardcoding in the source doesn't always help if you use distutils and build on a system with python2.5 installed (like the Ubuntu buildds)
[22:30] <DktrKranz> FYI, package is python-wsgiref
[22:30] <POX__> python2.4 setup.py
[22:31] <POX__> and you have hardcoded hashbangs
[22:31] <POX__> oh, wsgiref :)
[22:31]  * POX__ sponsored this one
[22:32] <POX__> DktrKranz: replace "python (<<2.5) | python2.4" with "python2.4" (or fix sbuild)
[22:32] <POX__> in build depends
[22:33] <DktrKranz> POX__, yes. I already did it since it FTBFS
[22:33] <POX__> and do some cdbs magic to force python2.4
[22:33]  * DktrKranz needs to study cdbs...
[22:34] <POX__> DEB_PYTHON_COMPILE_VERSION=2.4 or something like that
[22:34] <POX__> dont remember exactly
[22:34] <DktrKranz> me too
[22:34] <RAOF> DktrKranz: Check out Miro, I'm pretty sure that does what you want.
[22:35] <DktrKranz> RAOF, thanks for the pointer, I'll have a look at it
[22:35] <RAOF> Well, not quite.  It hardcodes for the version of python that boost-python is built against.  Still, it uses CDBS and does that sort of magic.
[22:36] <RainCT> good night
[22:36] <DktrKranz> night RainCT
[22:36] <DktrKranz> POX__, do you plan to switch to 2.5 soon?
[22:37] <DktrKranz> or is it too late for Lenny?
[22:37] <POX__> Lenny will have 2.5 as default
[22:38] <DktrKranz> so, wsgiref has to be adjusted in Debian too soon. I'll contact Debian maint about it to coordinate efforts
[22:39] <POX__> no need, we already know what's wrong
[22:39] <POX__> (sbuild mainly)
[22:54] <DktrKranz> mh... "Depends: python (>= 2.3) | python2.3, python (<< 2.5), python-support (>= 0.7.1)"
[22:57] <RAOF> "Albumb.  It's like plumb"
[23:00] <dcordero> hi
[23:00] <blueyed> persia: regarding the jedit package, you've said that debian/rules is no shell script and I should use make vars and syntax there.. I'm not entirely sure, what you mean.. as far as I can see it would make the whole target more ugly.
[23:34] <RAOF> Can anyone cast their eyes over gnome-do (http://revu.ubuntuwire.com/details.py?package=gnome-do) for (what should be, really really) the final time?  It should only need a brief check; it's had 2 advocates in the past.
[23:36] <RAOF> I'm prepared to offer reciprocal review/advocation at this point :)
[23:38] <blueyed> RAOF: the Homepage field should have a trailing slash.. ;)
[23:40] <HighNo> hm, my package blueproximity is accepted and according to REVU it has been uploaded already about 12h ago. It does not show up in the repository though. It can't be found on the webpage http://packages.ubuntu.com/hardy/allpackages and it can't be found by apt-get. The bug for inclusion LP# 137339 is also 'in Progress'
[23:40] <RAOF> blueyed: Really?  OK.
[23:40] <blueyed> you may clean the head of debian/rules
[23:40] <RAOF> HighNo: It'll take some time to build/negotiate NEW.
[23:40] <RAOF> blueyed: The dh-make boilerplate comments?
[23:40] <blueyed> RAOF: at least I think so. hostname+path.
[23:40] <Nafallo> Fujitsu: ping
[23:40] <blueyed> yes
[23:41] <RAOF> HighNo: Basically, your work here is done.  For the moment :)
[23:42] <blueyed> RAOF: you should use cdbs, too, for the future. at's a less more verbose in debian/rules!
[23:42] <RAOF> blueyed: At the expense of being totally impenetrable :P
[23:43] <RAOF> blueyed: You'll notice do-plugins uses CDBS, because I presumed it'd be a simpler package.
[23:43] <RAOF> I quite like having all the steps laid out in front of me ;)
[23:43] <blueyed> omg.. s/less more/lot less/
[23:44] <blueyed> yes, but most are all the same, e.g. patch/unpatch.. just depends on what you include.
[23:44] <RAOF> Yeah.  CLI packages have quite a lot of non-CDBS-magic in them.
[23:44] <blueyed> changelog should only list "Initial Package"?
[23:45]  * blueyed does not know cli (just command line interface for that)
[23:45] <emet> hello
[23:46] <RAOF> Common Language Infrastructure, aka CIL aka mono/.NET/gnudotnet/etc.
[23:46] <geser> HighNo: it's still in source NEW: https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=blue
[23:46] <blueyed> ah.. heard about mono quite a bit.. ;)
[23:47] <emet> I read the Ubuntu packaging guide, and I am confused, how can I have a shell script execute on package install and a different one on package remove?
[23:47] <RAOF> emet: You'd be after the postinst/postrm maintainer scripts.
[23:47] <geser> emet: it's done in the postinst and prerm scripts
[23:47] <emet> does the flashplayer-nonfree use those?
[23:48] <emet> it seems to download flash when you install the package
[23:48] <emet> flash is not actually in the package
[23:48] <RAOF> Yes; flashplugin-nonfree is almost entirely postinst/prerm scripts.
[23:49] <blueyed> RAOF: a comment in the desktop file would be nice. gets displayed nicely in kde4
[23:49] <emet> nice
[23:49] <emet> I'll take a look at that package then
[23:50] <geser> emet: if you interested in the "documentation" for those scripts see http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[23:51] <RAOF> blueyed: There already *is* a comment in the desktop file?
[23:52] <emet> speaking of the flashplayer-nonfree package
[23:52] <emet> it seems adobe changed their installer slightly, causing flashplayer-nonfree to fail because of MD5 mismatch
[23:52] <emet> this was about a week ago
[23:52] <geser> emet: gutsy?
[23:53] <emet> yes
[23:53] <RAOF> blueyed: Anything else?
[23:54] <blueyed> RAOF: yes, sorry. I've only looked at the patch and thought you added a desktop file..
[23:55] <geser> does someone remember the status of the flashplugin-nonfree for gutsy?
[23:55] <RAOF> blueyed: Ok.  I'll add a comment to the patch then.  I thought it would have been obvious by the name, but it clearly isn't.
[23:56] <geser> emet: there should be a new flashplugin-nonfree in gutsy-updates (9.0.48.0.2+really0ubuntu12.2). Does it still have a problem with the md5sum?
[23:56] <blueyed> RAOF: I've only looked at the patch chunk, without realizing that it's not just added. the name is clear I think.
[23:57] <emet> geser, no, this was last week, I havn't checked again
[23:57] <emet> geser, I figured you guys would find it very fast
[23:57] <emet> :o
[23:58] <emet> reboot
[23:58] <RAOF> blueyed: I'll add a comment anyway.  It's simple to do and uncommented patches annoy me sometimes.
[23:58] <blueyed> RAOF: your copyright file is sweet. /me obviously has not fully read the proposal. I've only used Files, Copyright, License fields.
[23:59] <RAOF> Heh.  Yes, I think that proposal actually makes writing copyright files easier, too.