[00:01] <sistpoty> doko: thanks a lot for your comments on bug #192887 !
[00:01] <ubotu> Launchpad bug 192887 in ubuntu "FeatureFreeze exception request for sun-javadb" [Wishlist,New] https://launchpad.net/bugs/192887
[00:46]  * sistpoty is off to bed
[00:46] <sistpoty> gn8 everyone
[01:22] <bddebian> Heya gang
[01:23] <protonchris> hey bddebian
[01:23] <bddebian> Hello protonchris
[02:08] <Hobbsee> sistpoty: done, and yes i can give back
[02:09] <Hobbsee> slytherin: (done)
[02:09] <Hobbsee> geser: i have backscroll and highlights.  it's OK
[02:09] <RAOF> Hobbsee: Howdie :)
[02:12] <Hobbsee> RAOF: good luck!  hope you find that before release!
[02:12] <Hobbsee> hey RAOF
[02:12] <Hobbsee> annoying that most people have left before i got to respond to them, though
[02:13] <RAOF> git bisect: 10 revisions to go.
[02:13] <Fujitsu> RAOF: Out of how many?
[02:14] <RAOF> 20 :)
[02:14] <RAOF> It seems to have been introduced pretty quickly after 1.4 was released.
[02:15] <RAOF> I would have liked to test git head first, but that seems to be a real pain to build.
[02:25] <Hobbsee> RAOF: woot!  keep going :)
[02:33] <RAOF> git bisect: 5 to go.
[02:34] <protonchris> RAOF: you're an animal :)
[02:34] <RAOF> Well, not really.  That's a single data point (yay binary search!)
[02:53] <RAOF> git bisect: 2 to go.  I hope these results aren't invalidated by another bug I'm running into while testing :/
[02:57]  * Czessi-m is away: Gone away for now.
[02:57] <RAOF> Czessi-m: Thanks very much for that: very useful :(
[02:57]  * Czessi-m is away: Gone away for now.
[02:57] <RAOF> !away > Czessi-m
[02:57]  * Czessi-m is back.
[02:57] <RAOF> ...and Ubutu can get an automated reply message :)
[02:58] <Czessi-m> sorry, wrong checkbox select in konversation
[02:59] <RAOF> :)
[03:00] <Fujitsu> Why don't we remove that feature from our Konversation builds? It's useless.
[03:05] <Hobbsee> because people occasionallyl like it?
[03:05] <RAOF> But those people are wrong, and should be shunned.
[03:05] <ScottK2> There are non-Ubuntu IRC channels.
[03:06]  * RAOF wills this git revision to build.  Build, damnit!
[03:11]  * RAOF hates on X developers commiting code that doesn't build.
[03:12] <Hobbsee> haha
[03:13] <Hobbsee> you mean you want *building* code?  sheesh, you're asking a lot!
[03:13] <RAOF> It would make it easier for me to help them, yes :P
[03:16] <emgent> :P
[03:16] <emgent> heya gang
[03:41] <RAOF> Woo.  One more good build.
[03:43] <Fujitsu> RAOF: How many revisions could it be in now?
[03:44] <RAOF> 2, apparently.
[03:44] <RAOF> 2 to check, at least.  Having to skip a bunch of revisions that didn't build hasn't helped.
[03:44] <RAOF> Hah!  Actually, _none_.
[03:45] <RAOF> Right.  Time to update that bug.
[03:46] <RAOF> Between a working revision and a known bad revision there are 4 revisions that fail to build.
[03:46] <Hobbsee> RAOF: try harder, then.
[06:24] <slytherin> Anyone willing to sponsor FTBFS fix for sugar-pippy-activity?
[08:09] <RAOF> Aww, curses.  The binary blob doesn't work with xserver git.
[08:26] <slytherin> any universe sponsors here?
[08:27] <RAOF> slytherin: You're after sugar-pippy-activity?
[08:27] <slytherin> RAOF: :-)
[08:28] <RAOF> Want to give me a URL?
[08:28] <slytherin> RAOF: bug 204363
[08:28] <ubotu> Launchpad bug 204363 in sugar-pippy-activity "[patch] Fix for FTBFS" [Undecided,Confirmed] https://launchpad.net/bugs/204363
[08:29]  * RAOF 's system is now decidedly non-Hardy.  But, man, xorg 1.5 is fast.
[08:31] <StevenK> RAOF: How did the bisecting go?
[08:32] <RAOF> StevenK: Not bad, not well.  There are 4 git revisions which fail to build between the last known-good revision and the first known-bad revision.
[08:32] <RAOF> Also, I can't reproduce that bug on my system with the git xserver, because the binary blob doesn't work on the git xserver.
[08:34] <Fujitsu> RAOF: Got an Intel machine you can test on?
[08:35] <RAOF> Fujitsu: Umm, not really.
[08:35] <RAOF> It suddenly occurs to me that there's a macbook sitting opposite me...
[08:36] <RAOF> So, technically, I *could* fire up a livecd on there, build xorg git, and give it a whirl.
[08:36] <RAOF> Hm, I could try DRM2 at the same time :)
[08:36] <Fujitsu> If not, I can test it.
[08:37] <RAOF> That'd probably be easier.
[08:37] <Fujitsu> Do you have an i386 deb?
[08:37] <RAOF> Building the stack on a livecd doesn't sound like a barrel of monkeys.
[08:37] <Fujitsu> Not really, no.
[08:38] <RAOF> I've got an i386 deb of libdrm git, but I've been doing all this on the bare filesystem (on an LVM snapshot, to preserve my root).
[08:38] <sebner> morning folks :)
[08:38] <sebner> persia: around?
[08:39] <RAOF> Fujitsu: To build xserver git you need to check out a new x11proto-input, you'll need libdrm git, and mesa git.
[08:40] <RAOF> I *could* build you packages of all this for you, if you want, but it's probably easier for you to do so?
[08:41] <Fujitsu> RAOF: Right, I can build all that myself, and am on LVM.
[08:42] <Fujitsu> If you tell me where to get the stuff, and and craziness needed to build.
[08:43] <RAOF> Fujitsu: You'll need: git://anongit.freedesktop.org/git/mesa/mesa (to pass to the --with-mesa-source configure option of xserver)
[08:44]  * Fujitsu snapshots and modifies fstab.
[08:44] <RAOF> You may well need to build a newer intel driver: git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
[08:44] <RAOF> ...which will need: git://anongit.freedesktop.org/git/xorg/lib/libpciaccess
[08:44] <Fujitsu> Oh dear, OK.
[08:45] <RAOF> You'll need git://anongit.freedesktop.org/git/xorg/proto/inputproto to build the xserver
[08:45] <RAOF> And git://anongit.freedesktop.org/git/mesa/drm also, both to build the xserver and to get the new intel drm module.
[08:46] <Fujitsu> Do I just git clone those?
[08:46] <RAOF> Yup.
[08:46] <RAOF> You might want to use my PPA package of libdrm, though.  You'll need to grab the source to build the intel DRM module (I don't build that), but the rest should be easier.
[08:47] <RAOF> Oh, and then you'll actually need xserver git: git://anongit.freedesktop.org/git/xorg/xserver
[08:48] <Fujitsu> So... that's 6, or did I miss one?
[08:48] <RAOF> No, that's it.
[08:50] <RAOF> You _may_ have to copy xserver/hw/xfree86/common/xf86cvt.c from a different xserver source package in order to build properly; I'm not sure if that was something wrong on my end or if it's a problem with git.
[08:51] <RAOF> It's really very easy to build xserver git</sarcasm>.
[08:52] <Fujitsu> Heh.
[08:53] <RAOF> On the plus side, you'll get to try out DRM2, TTM, and all that goodness :)
[08:53] <Fujitsu> No insane (ie. non ./configure; make; make install) build systems?
[08:54] <RAOF> No.  It's all autotools.    Maybe I just want to pastebin that :)
[08:57] <RAOF> http://www.paste2.org/p/16797
[09:00]  * Fujitsu waits for xserver to clone, then reboots and hopes he snapshotted things properly.
[09:01] <RAOF> Heh.
[09:01] <RAOF> I plan to blow away this install at some point anyway, so I'm not so totally concerned there :)
[09:04] <RAOF> slytherin: Any tests I could perform on that package?
[09:06] <pkern> Do I need FreezeExceptions atm for bug fix syncs from Debian?
[09:13] <RAOF> pkern: Not unless they introduce new features.
[09:14] <pkern> RAOF: ok
[09:18] <Fujitsu> RAOF: Do I actually build mesa, or just point xserver at it?
[09:18] <RAOF> Fujitsu: Just point xserver at it...
[09:18] <RAOF> Fujitsu: Actually, no.  You'll need to build it, won't you.
[09:19] <RAOF> Because you'll actually be _using_ mesa for your 3d.
[09:19] <Fujitsu> Aha, indeed.
[09:20] <RAOF> Hm... I'm not sure precisely which branch you'll want.  ./autogen.sh --disable-glut should apparently work to build it, though.
[09:20] <Fujitsu> I was just trying to find out what I needed for GLUT.
[09:20] <RAOF> GLUT only builds you the xdemos, you probably don't care about it too much.
[09:21] <Fujitsu> Ah. Right.
[09:34] <lool> Hi folks; I am about to request syncs for elisa* packages in version 0.3.5 which were completely broken a couple of weeks ago and for which I got green light to push 0.3.4; 0.3.5 is just a followup release with some bug fixes from upstream and only affects some modules
[09:34] <lool> If you think I need a formal exception, please ack #204555 :)
[09:35] <Fujitsu> lool: If it's only a bugfix release, no approval is required.
[09:36] <lool> Ok; /me carries on to ubuntu-archive
[09:38] <Fujitsu> RAOF: Is xserver meant to take ages to configure, with no output?
[09:38] <lool> (And thanks:)
[09:38] <lool> s/:/!
[09:54] <slytherin> RAOF: Sorry I was away. You can only try it if you have sugar environment installed.
[10:54] <wolfger> good morning, MOTUs
[10:55] <wolfger> I've got a question on the PackageUpdate wiki page...
[10:55] <wolfger> step 4 instructs me to copy the packaging into the new source, but I don't have those files at this point... just the dsc I've downloaded
[10:57] <wolfger> can somebody point me the right direction on this? I assume it's because I didn't dget the source?
[10:57] <man-di> wolfger: yes
[10:57] <man-di> dget downloads all files
[10:58] <man-di> dsc, orig.tar.gz, diff.gz
[10:58] <man-di> and with dget -x ... it will also unpack the sources
[10:59] <wolfger> ok, thanks
[11:03] <RAOF> Fujitsu: Sorry.  No, xserver too a while to configure for me, but it spewed the usual copious autotools verbiage at me.
[11:04] <Fujitsu> RAOF: I ended up having the wrong automake, I believe.
[11:04] <RAOF> Oh.  Right.
[11:04] <Fujitsu> RAOF: It's building now.
[11:04] <RAOF> Yay!
[11:04] <RAOF> I thought I filed a bug against it for 1.10 support, and it was fixed?
[11:04] <Fujitsu> 1.10 worked.
[11:04] <Fujitsu> I had 1.7, I think.
[11:04] <RAOF> Ah.  Crazy old versions :)
[11:04] <Fujitsu> Indeed.
[11:06] <RAOF> Fujitsu: Good luck.  I'm off to sleep.
[11:07] <Fujitsu> Night RAOF.
[11:07] <Fujitsu> Thanks for trying to get rid of that bug.
[11:07] <RAOF> Enlightened self-interest.  Yay open source!
[11:08] <Fujitsu> Indeed.
[11:58] <Iulian> Hey
[11:59] <\sh> moins
[11:59] <\sh> hmm..ports.ubuntu.com is slow today :(
[12:00] <Iulian> Hi \sh
[12:00] <sebner> \sh: I need you :)
[12:00] <\sh> sebner: well I needed my sleep first ;) so I just woke up ;)
[12:00] <\sh> just working down my todo
[12:01] <sebner> \sh: ^^. nvm. if you have time bug #196878
[12:01] <ubotu> Launchpad bug 196878 in xmoto "Modified .desktop for easier use with submenus" [Undecided,Fix released] https://launchpad.net/bugs/196878
[12:02] <\sh> sebner: what's up with that?
[12:03] <sebner> \sh: you introduced a xmoto-edit.desktop -> 1) it doesn't show up in the applications menu 2) upstream doesn't have plans for it. sispoty told me ...
[12:03] <Hobbsee> RAOF: any more luck?
[12:04] <\sh> sebner: hmmm..no..there was another package named xmoto-edit at some time, could be a left over
[12:04] <\sh> sebner: xmoto-edit but was removed
[12:05] <sebner> \sh: fine. than I can sync new xmoto version from debian :)
[12:05] <\sh> sebner: just make sure that the .desktop files are valide....test them before with desktop-file-validate
[12:06] <sebner> \sh: already done ;)
[12:06] <\sh> sebner: cool
[12:06] <\sh> oh that's I word we are not able to say anymore since we have a nick named cool ,->
[12:06] <\sh> s/I/a
[12:06] <sebner> hrhr
[12:06] <sebner> \sh: I would have asked you yesterday if you were online ^^
[12:07] <\sh> sebner: I wanted to do some things after work but I was so tired, that I slept away when I came home and layed down
[12:07] <sebner> \sh: np ;)
[12:09] <Fujitsu> Hobbsee, RAOF: After building and installing all the bits, I have no DRI. :(
[12:11] <sebner> hoi RainCT
[12:13]  * jdong has seeded 85GiB worth of beta desktop ISOs :)
[12:13] <jdong> that's the first time I've went over 100 for a seeding ratio :)
[12:14] <slytherin> Can anyone please tell me how can I use rsync to update ISO?
[12:14] <sebner> jdong: ah you reminded me on seeding the hardy final. thx :)
[12:51] <elmargol> Hi I try to create a vlc pakage using the --enable-mediacontrol-python-bindings setting... and i get a permission problem for /usr/lib/python2.5/site-packages/vlc.so
[12:51] <elmargol> any ideas?
[12:52] <bddebian> HEya gang
[12:52] <sebner> heya bddebian
[12:53] <bddebian> Hello sebner
[12:54] <ScottK> Hobbsee: Are you still around?
[12:54] <elmargol> noone?
[12:55] <ScottK> elmargol: vlc is in Main.  You might have more luck in #ubuntu-devel.
[12:55] <elmargol> thx
[12:57] <Hobbsee> ScottK: ish
[12:57] <ScottK> Hobbsee: Would you please ack Bug #204597
[12:57] <ubotu> Launchpad bug 204597 in dkim-milter "FFe for dkim-milter 2.5.1" [Undecided,New] https://launchpad.net/bugs/204597
[12:58] <geser> Hi bddebian!
[12:58] <bddebian> Heya geser
[13:06] <sebner> ScottK: would you ack bug #202518 and bug #203919 for me?
[13:06] <ubotu> Launchpad bug 202518 in audacious "[FFe] Please sync audacious 1.5.0-1 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/202518
[13:06] <ubotu> Launchpad bug 203919 in audacious-plugins "[FFe] Please sync audacious-plugins 1.5.0-1 from Debian(Unstable)" [Wishlist,New] https://launchpad.net/bugs/203919
[13:06] <ScottK> Give me a few minutes and I'll have a look.
[13:07] <sebner> ScottK: thx :)
[13:10] <sebner> \sh: already testing nexuiz debian packages? :P
[13:11] <\sh> sebner: It's on my todo list on point 6 :) and I worked down to point 3 :)
[13:13] <sebner> \sh: fine. fine :)
[13:20] <ScottK> sebner: "Pulseaudio-by-default is broken so we should sync it" isn't really a good reason.
[13:21] <ScottK> sebner: I think you need to go look at the impact of dropping the Ubuntu changes and explain it better.  I'd also like to see a description of the testing you've done.
[13:23] <ScottK> sebner: From reading the bug, all I know is "Someone said pulse-audio-by-default is broken."
[13:23] <sebner> ScottK: oh. sry if it's not clear. I tested it. Do you also want to see screenshots?
[13:24] <ScottK> sebner: I don't see anywhere in the bug where it says you tested it.
[13:24] <persia> sebner: Good text is always better than screenshots.  While a picture is worth 1000 words, that does make it 1000 times more complicated to understand.
[13:24] <ScottK> sebner: Also did you test if pulse-audio-by-default is broken?
[13:25] <sebner> ScottK: yes. both. all. :) Otherwise I wouldn't have changed it to a sync. Sry for not documenting it
[13:25] <ScottK> sebner: I noticed a whole stack of FFes in my inbox from you that I haven't had time to digest yet.  I'd encourage you to go back on all of them and make sure you describe the testing that was done.
[13:26] <ScottK> sebner: Now that we're past beta and moving toward RC, we will get pickier about testing and verification.
[13:27] <ScottK> sebner: Also, with the FFe's you're filing for RC bug fixes, it's probably worth a look (if you didn't) to see if the bug fix can be extracted and applied to our current package rather than jumping to the new upstream.
[13:27] <sebner> ScottK: yeah sure. audacious is an exception. Most of the other FFe never had remaining ubuntu changes and does have RC bugs
[13:27] <ScottK> Even the ones with RC bug fixes need testing.
[13:28] <sebner> ScottK: understood. I will (again) go through all FFe's I filed. Do I attach some words to audacious now?
[13:32] <ScottK> sebner: Only if you want me to ack it.
[13:32] <sebner> ScottK: ^^
[13:32]  * sebner in on the way
[13:36] <jdstrand> emgent: uploaded #202422
[13:36] <jdstrand> bug #202422
[13:36] <ubotu> Launchpad bug 202422 in smarty "CVE-2008-1066 smarty allows attackers to call arbitrary PHP functions via templates" [Medium,Fix committed] https://launchpad.net/bugs/202422
[13:36] <sebner> ScottK: f5, please
[13:37] <jdstrand> emgent: I am not going to push to soyuz until monday though
[13:37] <sebner> ScottK: may I also copy this text to the plugins?
[13:37] <jdstrand> emgent: thanks!
[13:38] <ScottK> sebner: If you tested them the same.
[13:39] <sebner> ScottK: ok
[13:44] <ScottK> sebner: Audacious and plugins approved.
[13:45] <sebner> ScottK: thank you and sry again. :( Will keep that in mind for the future
[13:46] <sebner> hoi siretart
[13:46] <sebner> hoi sistpoty
[13:46] <sistpoty> hi folks
[13:47] <sistpoty> hi sebner
[13:47] <sistpoty> sebner: so you're spamming motu-release again :P
[13:47] <sebner> sistpoty: sry. ScottK already told me. Won't do in future
[13:47] <sebner> Just after intensive checks
[13:47] <sistpoty> sebner: heh, if the there are good fixes we should pick up, there's nothing wrong ;)
[13:48] <ScottK> sistpoty: Would you please ack Bug #204597
[13:48] <ubotu> Launchpad bug 204597 in dkim-milter "FFe for dkim-milter 2.5.1" [Undecided,New] https://launchpad.net/bugs/204597
[13:48] <sebner> sistpoty: yeah but maybe we can extract that fix instead of always jumping to new upstream
[13:48]  * sebner is now doing intensive investigations
[13:49] <persia> sebner: Now that Beta is out, reverse merging is generally preferred, as it is often safer (although jumping may be appropriate sometimes)
[13:49] <sebner> persia:  :) it's my first beta phase ^^
[13:50] <ScottK> sebner: What you're doing is very good.  We're just doing some education along the way.  Keep it up.
[13:50] <sebner> ScottK: btw, for graphicsmagick. Just attach the links. like http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4985
[13:50] <ubotu> ImageMagick before 6.3.5-9 allows context-dependent attackers to cause a denial of service via a crafted image file that triggers (1) an infinite loop in the ReadDCMImage function, related to ReadBlobByte function calls; or (2) an infinite loop in the ReadXCFImage function, related to ReadBlobMSBLong function calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4985)
[13:50] <persia> sebner: Understood.  That's why you get pointers rather than complaints :)  Thanks a lot for chasing the RC bugs.
[13:51] <sistpoty> ScottK: acked
[13:51] <ScottK> sebner: If you look, you'll see there's a specific place for cve links on the right where you just input the cve number.
[13:51] <ScottK> sistpoty: Thanks
[13:51] <sebner> ScottK: ah. great thank you. never used that before :)
[13:52] <sebner> sistpoty: and also sry to you for such a bad documentation on audacious. Though we talked about it. Nevertheless. sry.
[13:52] <sistpoty> sebner: heh, no need to apologize
[13:54] <sebner> Well, a clear style and documentation is always important :)
[13:54]  * sistpoty just switched to kde4 and seriously considers switching back to kde3 *g*
[13:55] <sebner> sistpoty: or even better. to gnome :P
[13:55] <sistpoty> :P
[13:56] <sebner> persia: np. I also want a *better* ubuntu though I'm not using any software which is on ubuntuwire and has RC bugs :)
[13:57] <ScottK> sebner: Gnome is better only if you happen to like Gnome.  Not all of us feel that way.
[13:57] <Hobbsee> sistpoty: yeah, it's a bit like that...
[13:57] <ScottK> sistpoty: kde4 is for enthusiasts at this point IMO, not actual use.
[13:58] <sebner> ScottK: yeah. because of that I used ":P" which means that's only a joke :)
[13:58] <sistpoty> Hobbsee: well, it's nice and everything and I don't have real big problems, but it feels somehow unorganized (maybe I'm just too used to kde3 *g*)
[13:59] <ScottK> sebner: Understood.  If I thought you were serious you'd have got a much grumpier reply.
[14:01] <sebner> ScottK: ^^. Nevertheless I should avoid to joking in english. It's simple not working
[14:04] <StevenHarperUK> Hi I have new candidate https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/203145 that has got an ack for its release freeze bug   https://bugs.edge.launchpad.net/bugs/204073 does it need any more action from me please
[14:04] <ubotu> Launchpad bug 204073 in easycrypt "FeatureFreeze Exceptions for easycrypt-<IP_ADDRESS>" [Undecided,Confirmed]
[14:05] <ScottK2> StevenHarperUK: You have an approved Feature Freeze exception.  It's still up to you to get an upload sponsored.
[14:05] <sistpoty> Hobbsee: please give back haskell-edison on sparc, thanks!
[14:05] <StevenHarperUK> Its already in hardy - is an upload sponsored a different thing
[14:06] <StevenHarperUK> it new candidate
[14:06] <StevenHarperUK> *its a
[14:06] <ScottK2> siretart: Ping.  I'd like to discuss SE Linux packages when you have a moment.
[14:07] <ScottK2> StevenHarperUK: I'm confused.  It's already uploaded?
[14:07] <siretart> ScottK2: what's up?
[14:07] <StevenHarperUK> <IP_ADDRESS> is already in hardy - I need to get <IP_ADDRESS> up during the freeze
[14:07] <ScottK2> siretart: Did you see manoj being upset that we forked the SE Linux packages yesterday?
[14:07] <Hobbsee> sistpoty: done
[14:07] <sistpoty> Hobbsee: thanks!
[14:08] <StevenHarperUK> as TrueCrypt 5.1 has Finally been released, so it actaully works on Hardy
[14:08] <ScottK2> siretart: I thought when we talked about SE Linux at UDS there was consensus not to do that, but we seem to have.
[14:08] <StevenHarperUK> <IP_ADDRESS> doesnt work on Hardy at all
[14:08] <StevenHarperUK> <IP_ADDRESS> does perfectly
[14:08] <StevenHarperUK> I thought I had to get a Feature Freeze exception to get it updated
[14:08] <StevenHarperUK> I have done that
[14:08] <StevenHarperUK> Is there now another step?
[14:09] <ScottK2> StevenHarperUK: Yes.  It has to be uploaded.  For that you need sponsorship since IIRC you aren't a MOTU.
[14:09] <siretart> ScottK2: well, I *think* it went like this: Manoj updated his packages pretty late, and was pretty unresponsive when the tresys guys worked on selinux in ubuntu
[14:10] <ScottK2> Right.  He was practically MIA for a while.
[14:10] <siretart> ScottK2: OTOH, manoj was offered help in packaging, which he rejected
[14:10] <persia> StevenHarperUK: The sponsor queue has been unfortunately lagging the past few weeks.  If you've an approved FFe, it's very likely to get uploaded, but it may take a bit more time.
[14:10] <StevenHarperUK> ScottK2:how do I get sponsorship?
[14:10] <StevenHarperUK> persia: does it require an action from me?
[14:10] <ScottK2> StevenHarperUK: Put a .diff.gz in the bug if it's not there already and subscribe ubuntu-universe-sponsors if it's not done already.
[14:11] <StevenHarperUK> Thats all done
[14:11] <ScottK2> siretart: I think he just got really busy with work and was not paying attention to Debian for a while.
[14:11] <ScottK2> StevenHarperUK: Then no.  Nothing more you need to do
[14:11] <ScottK2> siretart: So now he's back and about to upload current packages to Debian.
[14:11] <siretart> he already did
[14:12] <siretart> debian is ATM more uptodate than ubuntu
[14:12] <ScottK2> siretart: In setools we did a wholesale renaming of binary packages (he hasn't uploaded that one yet).
[14:13] <\sh> StevenHarperUK: can you add a debdiff to bug #203145 ? I don't like this interdiff stuff ;)
[14:13] <ubotu> Launchpad bug 203145 in easycrypt "Candidate revision easycrypt_<IP_ADDRESS>-0ubuntu1" [Wishlist,In progress] https://launchpad.net/bugs/203145
[14:13] <siretart> ScottK2: and IIUC, he doesn't intend to pick up that change
[14:13] <\sh> StevenHarperUK: and assign the bug to me...I'll take care about it
[14:13] <ScottK2> siretart: I'm concerned in setools because with the package renaming we have either a forked package and an upset DD or we rebase on Manoj work once he uploads it.
[14:13] <persia> \sh: You really want a debdiff for a new upstream?  Why not the diff.gz?
[14:13] <ScottK2> siretart: That's my understanding.
[14:13] <\sh> persia: or this...but I don't see a diff.gz
[14:14] <ScottK2> siretart: So I think maintaining a permanent diff is not a good plan.
[14:14] <siretart> ScottK2: well, you guys also replaced his packaging with cdbs, right?
[14:14] <StevenHarperUK> \sh:  its an interdiff
[14:14] <\sh> StevenHarperUK: then please add a diff.gz
[14:14] <ScottK2> siretart: You guys doesn't include me.
[14:14] <ScottK2> But yes.
[14:14] <persia> StevenHarperUK: Do note that the process has changed, and diff.gz files are now requested (and yes, the documentation is out of date)
[14:14] <siretart> ScottK2: ah, sorry. ok
[14:14] <StevenHarperUK> persia: whats the command to generate that please
[14:14] <\sh> StevenHarperUK: debuild -S -sa ? ;)
[14:14] <ScottK2> siretart: My thought is to go through and merge from Debian and rip out the gratuitous changes.
[14:14] <persia> StevenHarperUK: I typically use `debuild -S -sa`
[14:15] <ScottK2> siretart: But I'm concerned about doing it late.  Since you were involved in the UDS discussion, I wanted your perspective.
[14:15] <\sh> persia: I thought there was already a debian pkg available ;)
[14:16] <StevenHarperUK> persia: I do this >debuild -S -sa -kD330E9E8BEE08F9E -I\.svn -tc already
[14:16] <persia> \sh: Not for that upstream.  It's Ubuntu local.
[14:16] <siretart> ScottK2: well, it was done just around FeatureFreeze. IIRC, the packages have been tested even FF in the ubuntu-hardened PPA, and got uploaded in time
[14:16] <StevenHarperUK> persia: how does that make a diff againsta previous version?
[14:16] <persia> StevenHarperUK: Then you should have an updated -0ubuntu1.diff.gz in the parent directory.
[14:16] <siretart> so I don't have the impression that this change was unreasonably late
[14:16] <\sh> StevenHarperUK: so upload the .diff.gz from the package you created
[14:16] <ScottK2> siretart: If not for all the package renaming, I'd just wait and do it at the start of Intrepid.
[14:16] <StevenHarperUK> k
[14:17] <ScottK2> siretart: It'd be late to revert the cdbs stuff now it my concern
[14:17] <siretart> ScottK2: FWIW, the energy spent on the iscsi-related as far too late in the release cycle
[14:17] <ScottK2> Agreed.
[14:17] <siretart> ScottK2: and not really an option, IMO
[14:18] <siretart> his packaging does heavily rely on his way of using tla. it is totally unreasonable to get familiar with that way of packaging just for the selinux packages
[14:18] <ScottK2> siretart: For this cycle on selinux I'm a lot less concerned about package content alignment with Debian than I am package naming.
[14:18] <ScottK2> Yes, but this was already considered at UDS.
[14:18] <ScottK2> I remember you showing me some of his packages.
[14:19] <siretart> TBH, the way the ubuntu selinux packages are maintained really scares me
[14:20] <siretart> I mean the bzr branch. that's really scary
[14:20] <siretart> but as long the guys keep on working on that, I won't tell them how to use bzr
[14:20] <ScottK2> I don't see a lot of other packages by the guy whose name is in the changelog, so I don't know about that either.
[14:22] <ScottK2> siretart: The big concern I have is keeping relations good between Debian and Ubuntu.  I know manoj packages are hard to deal with, but I think that's the price of being downstream.
[14:22] <StevenHarperUK> \sh: its done now diff.gz uploaded - LP#203145
[14:23] <siretart> ScottK2: I do hope that the tresys guys are again at UDS in Prague. We should discuss this in person there
[14:23] <StevenHarperUK> \sh: Is that ok
[14:23] <ScottK2> siretart: So you'd be against changing packages for Hardy to realign with Debian?
[14:24] <siretart> depends on what you mean with 'realign'ing
[14:25] <ScottK2> siretart: At a minimum, I'd like to get the package namespace aligned so we don't end up carrying transitional packages for multiple releases.
[14:25] <siretart> ScottK2: that sounds indeed reasonable
[14:25] <ScottK2> With the idea that we'd rebase to a mimimal diff from Debian in Intrepid.
[14:26] <StevenHarperUK> \sh: do you have everything for the easycrypt package now?
[14:26] <ScottK2> As soon as manoj uploads setools then, I'll look at that difference and mail ubuntu-devel.  We can pick it up there.
[14:26] <ScottK2> siretart: ^^^
[14:27] <siretart> yes, sounds like a plan
[14:27] <StevenHarperUK> \sh: I cannot assign the bug to you : I dont know what your LP name is
[14:27] <StevenHarperUK> persia: does bug 203145look complete enough now please
[14:27] <ubotu> Launchpad bug 203145 in easycrypt "Candidate revision easycrypt_<IP_ADDRESS>-0ubuntu1" [Wishlist,In progress] https://launchpad.net/bugs/203145
[14:29] <persia> StevenHarperUK: I'd encourage more detail in the description, but all the necessary bits are there, and the right teams are subscribed.
[14:29] <StevenHarperUK> persia: So more of an explanation : add another comment??
[14:30] <persia> No.  Edit the description to explain about the update, etc.
[14:30] <persia> Too many comments tend to get lost after a while.
[14:30] <StevenHarperUK> ok
[14:32] <StevenHarperUK> persia: Thanks I have done that - I didn't realise you could edit the description
[14:32] <persia> StevenHarperUK: Ah.  That explains it :)
[14:32] <StevenHarperUK> persia: it all makes sense!
[14:33] <StevenHarperUK> persia: thanks for telling me more - I have to go now the wife want me to tidy up the house
[14:34] <persia> StevenHarperUK: Thanks for working with us to get your updates in, so we don't have to poll upstream so much.
[14:53] <cody-somerville> gpocentek, ping
[14:56] <sistpoty> ScottK | Hobbsee: bug #196073 needs another ack
[14:56] <ubotu> Launchpad bug 196073 in libpciaccess "Please sync from libpciaccess from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/196073
[14:58]  * ScottK2 looks
[15:00] <ScottK2> sistpoty: I asked for test results.
[15:01] <gpocentek> cody-somerville: pong
[15:02] <sistpoty> ScottK2: ok, thanks
[15:02] <sistpoty> tjaalton: ^^
[15:02] <hefe_bia> In a debdiff for main: Shouldn't Original-Maintainer be the Debian developer and Maintainer be Ubuntu Core Developers?
[15:02] <ScottK2> sistpoty: Now that we're past beta, I think we need that for all FFe's.
[15:03] <ScottK2> hefe_bia: Yes.  See https://wiki.ubuntu.com/DebianMaintainerField
[15:04] <sistpoty> ScottK2: well, I assume from everyone filing an FFe to have the package tested actually, but having something written to the bug report would make some sense, yes
[15:05] <ScottK2> Well I guess it depends on who it is to some extent, but I think they ought to say it.  It's actually listed in the FFe page as a required element.
[15:05] <hefe_bia> ScottK2: thanks
[15:06] <sistpoty> ScottK2: *nod*
[15:06]  * persia believes everyone should provide test results, even if they have a strong track record for perfect updates
[15:06] <ScottK2> sistpoty: Is there an easy way to find if there's been a soname change without building a package?
[15:07] <sistpoty> ScottK2: looking at debian/control... but of course no SONAME change doesn't always guarantee that there shouldn't be a SONAME change ;)
[15:07] <ScottK2> sistpoty: I'm packaging a new upstream and I need to tell if there should be.
[15:08] <broonie> ScottK2: You need to review the ABI manually, pretty much.
[15:08] <ScottK2> I'm doing clamav 0.93 RC1 so I can be ready if they release before we do.
[15:08] <persia> ScottK2: If the upstream is well behaved, the SONAME is defined in the build system, but few upstreams should be trusted implicitly.
[15:08] <sistpoty> ScottK2: well, you'll need to build the new shared object, but of course grab the shared object from the old deb for diffing
[15:08] <ScottK2> sistpoty, persia, and broonie: Thanks.  No shortcuts then.  Of I go ....
[15:09] <broonie> For ClamAV sgran may already know the answer.
[15:09] <persia> ScottK2: Depending on the code, you might be able to write a script that examines the code for public objects and their formats, but it's typically easier to build :)
[15:09] <sistpoty> oh, persia: you know some bits about java in ubuntu, don't you? I'm pretty clueless about bug #193386
[15:09] <ubotu> Launchpad bug 193386 in ubuntu "Feature Freeze Exception for glassfishv2" [Undecided,New] https://launchpad.net/bugs/193386
[15:09] <ScottK2> broonie: He told me that since Lenny is getting it's first touch of frost, he wasn't touching release candidates anymore.  Hopefully I get this right and he can just use it when the time comes (we cooperate pretty closely).
[15:10] <persia> Err.  I've been hiding from that bug for weeks :)
[15:10] <sistpoty> heh
[15:10] <ScottK2> persia: They're playing nice with it.  I would appreciate it if you'd give them a good review.
[15:10] <persia> I don't have a quick answer, although I have a fair backlog of email from upstream about it.  I'm going to bed soon, but will be sure to comment in the morning.
[15:11] <sistpoty> ScottK2, persia: actually I'm not really asking for a review right now, but rather if the package would fit in the archive (of course then, if the FFe is granted, we'd need to review the package)
[15:12] <persia> ScottK2: I'd agree.  I'm fairly happy with Nitya.  My objection was mostly that I didn't see the point of Sun-branded derby vs. vanilla upstream.  That seems to have been resolved in favor of JavaDB for Hardy, so at this point I don't have specific objections, and just need to review it.
[15:12] <persia> For intrepid, I'm hoping someone packages Apache derby so we can drop JavaDB (as I have had several people report that there are no functional patches, just branding and licensing changes).
[15:13] <persia> (unfortunately, my Java Packaging is not yet at a point where my first package is acceptable enough to submit, so it likely needs to be someone else)
[15:15] <persia> sistpoty: Ah.  In that case, the main issue is whether we want to have both GlassFish 1 and GlassFish 2 in the archive.  It is a new upstream version, but the transition isn't easy, and applications need to be ported.  We don't have any reverse dependencies, but Sun doesn't think users should have to switch if they don't feel like it (or at least that was the state before I fell behind in my email, and I'm still not caught up).
[15:16] <sistpoty> persia: ok, so it's not really completely overlapping with s.th. in the archive, right?
[15:16] <persia> From what I understand, the packages have been arranged to work in parallel, and there has been testing on hardy by Sun Quality Engineering, so it should be safe.
[15:16] <ScottK2> Right now the choice is glassfish 1.  The decision would be do we offer the glassfish2 choice or not, right?
[15:16] <persia> No.  There ought be no overlap except in mindshare.
[15:16] <persia> RIght.  It's a matter of whether we offer the choice.
[15:17] <sistpoty> ok, I guess I don't have a problem granting the FFe itself
[15:17] <persia> The alternative I was hoping for (although my unplanned absence made this hard) was to have only glassfish 2, and an entry in the release notes.
[15:17] <sistpoty> however the hard part will be to get the package reviewed then
[15:17] <ScottK2> I think it's very late for that.
[15:17] <ScottK2> (galssfish 2 only)
[15:17] <persia> Yes.  Far too late for that.
[15:17] <ScottK2> gal/gla
[15:18] <persia> A month ago, it might have been possible, but my activity has been insufficient for about that period of time :(
[15:19] <sistpoty> hm... so what do we do with this FFe? *shrug*
[15:19]  * jdong kneels down before confessions.
[15:19] <jdong> I just wrote the most evil python script in the history of mankind.
[15:20] <ScottK2> sistpoty: I say approve it.
[15:20] <jdong> an automatic sysv to upstart converter
[15:20] <sistpoty> ScottK2: ok
[15:21] <ScottK2> sistpoty: I acked first, so you have to approve ;-)
[15:21] <sistpoty> heh
[15:21] <ScottK2> jdong: Automatix was largely done in Python, so you don't qualify.
[15:22] <jdong> ScottK2: oh believe me this has the potential to break a lot more than automatix!
[15:22] <jdong> ScottK2: though the types of breakages caused will be fairly obvious.
[15:22] <jdong> i.e. cannot boot.
[15:23] <ScottK> jdong: The evil part of Automatix wasn't that it broke stuff, but that the breakage wasn't obvious until the next upgrade so it looked to the user like Ubuntu was AFU, when it was really Automatix.
[15:23] <ScottK> jdong: They win by a lot on evil points.
[15:23] <jdong> ScottK: indeed -- hard to detect breakageas like that are the most evil
[15:27] <sistpoty> ScottK2 | Hobbsee: bug 204038 needs another ack (I've personally tested it, and I'm so bad at playing *g*)
[15:27] <ubotu> Launchpad bug 204038 in xmoto "[FFe] Please sync xmoto 0.4.2-1 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/204038
[15:32] <ScottK> sistpoty: Done and approved
[15:32] <sebner> ScottK: thx
[15:34] <avoine> If a package that I need in Ubuntu just get into the debian's sid repository, I will see it soon in ubuntu?
[15:34] <jdong> no
[15:34] <sebner> avoine: we are past beta release. unlikely if it's not super important and super urgent
[15:34] <jdong> what sebner just said
[15:34] <avoine> ok but after the release it will be?
[15:35] <jdong> in Hardy+1 yes
[15:35] <persia> avoine: after release, it will be automatically added to intrepid, and a backport may be requested.
[15:36] <avoine> ok
[15:38] <avoine> Debian also sync with Ubuntu sometime?
[15:40] <sebner> avoine: http://wiki.debian.org/Utnubu
[15:40] <avoine> oh great!
[15:40] <ScottK> avoine: Not automatically.  People work at it.
[15:47] <cody-somerville> Will someone be kind enough to upload the xubuntu-docs? (bug #204501)
[15:47] <ubotu> Launchpad bug 204501 in xubuntu-docs "Please update Xubuntu docs from bzr" [Undecided,Confirmed] https://launchpad.net/bugs/204501
[15:48] <sistpoty> cody-somerville: if you walk me through the steps, I'll upload it ;)
[15:48] <sistpoty> cody-somerville: do I need bzr-buildpackage or s.th.?
[15:48] <ScottK> cody-somerville: By asking for sponsorship from bzr, you've limited your chances of sponsorship.  I'd suggest using actual Debian packaging tools and following the sponsorship process.
[15:48] <cody-somerville> ScottK, Is it not Ubuntu policy to manage packages in bzr?
[15:49] <persia> Not at all.
[15:49] <ScottK> cody-somerville: It is not
[15:49] <cody-somerville> I thought I remember Scott starting something a few releases back
[15:49] <ScottK> Many people do it, but there is no overall policy
[15:49] <persia> While many of the core packages are managed in BZR, and packages maintained by groups are encouraged to use a VCS, the majority of packages are handled directly.
[15:50]  * RainCT can look at it if nobody does
[15:50] <persia> When asking for sponsorship for a VCS managed package, the best practice is to update the VCS to match the candidate, and submit the candidate via the standard sponsor processes.
[15:51] <ScottK> For me, it's in bzr translates as "I don't want ScottK to look at it".
[15:51] <persia> Some sponsors will want to pull from the VCS, and some from the debdiff/diff.gz.  Many will complain if the two are not in sync, but simply using a VCS doesn't mean one can circumvent other processes.
[15:51] <cody-somerville> I'm almost positive that keybuck was encouraging people to manage packages in bzr a release or two ago
[15:51] <persia> Note that if the NoMoreSourcePackages spec is ever implemented, the "standard sponsoring process" will change, and this would be widely announced.
[15:52] <ScottK> Encouraging yes, but there is no policy
[15:52] <persia> Yes.  Encouraging.  Further, that the packages be maintained in a VCS, but not necessarily that it was standard practice.
[15:52] <cody-somerville> The plan was to move everything over at the time IIRC
[15:52] <cody-somerville> or to start in that direction
[15:52] <cody-somerville> But anyhow
[15:52] <ScottK> For those of us that like the fact the Ubuntu is a Debian derivative, it'd be time to move on
[15:52] <persia> That's the NoMoreSourcePackages spec, which has yet to be anywhere near implementation.
[15:53] <ScottK> cody-somerville: Until bzr can scale to deal with the entire archive, it's pointless
[15:53] <persia> ScottK: Maybe.  See the latest dpkg-source in Debian :)
[15:53] <persia> (not that git is bzr, but...)
[15:53] <ScottK> persia: I think git's a lot more scalable than bzr.
[15:53]  * sistpoty thought he'd read a patch to add bzr as well
[15:53]  * persia refuses to argue the relative merits of VCS solutions
[15:53] <sistpoty> on debian-dpkg, which I recently read for amusement *g*
[15:53] <ScottK> It took minutes yesterday for me to check out a single package yesterday (it was in Main).
[15:54] <jdong> ScottK: probably because the branch has not been updated to the packs format
[15:54] <siretart> does somone know who https://edge.launchpad.net/~aizul75 is?
[15:54] <persia> sistpoty: tar'd local bzr repos as a supported source package format?
[15:54] <jdong> ScottK: the newest bzr format should have similar network performance characteristics to git.
[15:54] <cody-somerville> RainCT, So you're able to sponsor from bzr?
[15:54] <ScottK> It was on Launchdad.  What do they use?
[15:54] <persia> jdong: From a dpkg-source perspective, the network performance isn't the important bit.
[15:54] <RainCT> cody-somerville: I think so
[15:54] <sistpoty> persia: not too sure, I didn't look at the patch
[15:55] <jdong> persia: agreed
[15:55] <sistpoty> persia: http://lists.debian.org/debian-dpkg/2008/03/msg00156.html
[15:56] <persia> Yes.  compressed local bzr repos.  Interesting.
[15:57] <persia> On reflection, adding such support to Debian is the right way to meet the derivative objection.
[15:57] <persia> developers can use their preferred package format, dpkg-source can do the right thing, etc.
[15:57] <persia> Of course, it becomes annoying from a sponsor perspective, but that's more an Ubuntu issue than a Debian issue.
[15:58] <persia> Anyway, it still doesn't mean "please pull from some random VCS branch and upload" is the right solution.
[15:59] <persia> And if done cleanly, dpkg-source, debdiff, and debuild would still do the right things.
[15:59] <ScottK> If you're a member of a team and asking for a team sponsor and that team has a VCS policy, then it may be reasonable, but not generally.
[16:00] <persia> Maybe.  I've seen the argument that producing evidence of a locally built package is important to demonstrate that the VCS is indeed as clean as is implied.
[16:00] <ScottK> From my perspective bzr is an Ubuntu unique tool.  I know it's used elsewhere, but I've never run into it.
[16:01] <persia> Does it matter if it is Ubuntu unique?  I think it only matters if it is supported cleanly by the standard tools.
[16:02] <ScottK> persia: It works well in the Debian Python teams (dpmt/papt).
[16:02] <ScottK> persia: It matters if I care to expend brain cells on n+1 VCS.
[16:05] <persia> ScottK: I think we are having different arguments.  I don't care about the implementation as long as I can download and apply a patch easily, and continue to use dpkg-source, patch, debuild, and debdiff.  I suspect you don't want to learn a new VCS.
[16:05] <ScottK> Right.
[16:05] <persia> So for me, having the tools I use support BZR means that I'd be happy to work with BZR packages.
[16:06] <ScottK> Having the tools make it so I don't have to know it's a bzr package is fine with me.
[16:06] <persia> Well, it's listed in debian/control, so maybe hard to miss :)
[16:06] <ScottK> That would require a level of abstraction in interaction with the source format that we are a long way from, however.
[16:07] <ScottK> know/work differently with.
[16:07] <persia> ScottK: See the dpkg-devel discussions: we're getting much closer than the hassles of foo-buildpackage
[16:07] <persia> Err.  debian-dpkg
[16:07] <ScottK> I've seen the bits that leaked out onto debian-devel
[16:08] <ScottK> As long as Ubuntu follows Debian on fundamental packaging tools, I'll manage it.
[16:08] <ScottK> If Ubuntu gets out front, I see danger.
[16:09] <persia> I think the number of installation failures from the dh_iconcache issue in Hardy should demonstrate the risk of that.  I'm bemusedly awaiting the flood of bug reports.
[16:10] <ScottK> I worry about stuff like "We're going to port all the main init scripts to be upstart native in Intrepid".
[16:10]  * ScottK will be afk for a bit now.
[16:11] <jdong> ScottK: I don't think it'll be that bad
[16:11]  * persia will go to bed, but encourages anyone who wants to get a lot of last-minute uploads to grab a hardy source mirror, and grep all the debian/rules files for dh_iconcache, or just submit rebuilds for anything not updated in hardy that relies on CDBS.
[16:13] <ScottK> jdong: It's a permanent fork unless Debian somehow adopts Upstart
[16:13]  * ScottK really afk now.
[16:15] <siretart> sistpoty: btw, bug #194919 is about including a new package, and not really replacing openal in main
[16:15] <ubotu> Launchpad bug 194919 in openal "libopenal needs replacement" [Undecided,New] https://launchpad.net/bugs/194919
[16:16] <RainCT> uh.. why does debuild still say "bad-distribution-in-changes-file hardy" after I upgraded to Hardy?
[16:16] <cody-somerville> RainCT, it does that sometimes ;p
[16:16] <sistpoty> siretart: oh, I see
[16:16] <persia> RainCT: No "ubuntu" in the revision?
[16:17] <RainCT> persia: ah, thanks :)
[16:18] <siretart> sistpoty: from what I understand from the openal mailing list is that openalsoft is more or less a port from the windows version of openal
[16:19] <cody-somerville> RainCT, we don't we want ubuntu in the version btw
[16:19] <cody-somerville> RainCT, it is a native package
[16:19] <sistpoty> siretart: how does this relate to the openal lib in main? different codebase or a fork?
[16:19] <siretart> completely different codebase
[16:19] <siretart> the SI is defacto dead upstream, from what I see
[16:20] <siretart> however, I think we really should replace openal with openalsoft in debian
[16:20] <RainCT> cody-somerville: yes, figured so. ubuntu-docs hasn't ubuntu in the version, neither
[16:20] <siretart> unfortunately, nobody is currently working on that :(
[16:21] <RainCT> cody-somerville: why don't you add overrides?
[16:21] <persia> siretart: Is there a deadline soon?  I'd like to be working on it, but keep running into other things.  I can raise the priority if it needs doing sooner (and there is really nobody else, I've seen a couple hints that someone would do something)
[16:21] <cody-somerville> RainCT, They're only warnings
[16:22] <cody-somerville> IIRC
[16:22] <sistpoty> siretart: I'll take a look at it
[16:22] <siretart> persia: actually, we are already past the first deadline for the soft freeze for lenny
[16:23] <siretart> but I think if we are really quick, we can do it
[16:23] <siretart> persia: see http://thread.gmane.org/gmane.linux.debian.devel.announce/1179
[16:24]  * persia needs to pay better attention to Debian mail, and will prioritise a transition test (unless sistpoty is planning a quick upload to experimental)
[16:24] <RainCT> cody-somerville: actually that one is an error, but it can be ignored anyways
[16:24] <cody-somerville> okay
[16:28] <siretart> the package from the launchpad bug does not provide any development headers, though.
[16:46] <sistpoty> siretart: I just commented on the bug, and I'm not really in favour of adding openal-soft to hardy
[16:47] <RainCT> cody-somerville: http://paste.ubuntu.com/5974/
[16:48] <cody-somerville> I'll add a call to dh_fixperms
[16:49] <cody-somerville> RainCT, did you upload yet?
[16:49] <huats> pochu: are you around ?
[16:50] <cody-somerville> RainCT, oh wait, it is CDBS
[16:50] <\sh> buh....wine 0.9.58 released
[16:51] <RainCT> cody-somerville: just "chmod -x" should do it
[16:52] <ScottK2> \sh: Why isn't it uploaded then?
[16:52] <ScottK2> ;-)
[16:52] <\sh> ScottK2: lol...yokozar needs some uploads?? :)
[16:53] <cody-somerville> RainCT, Okay. Thanks for pointing that out.
[16:53] <ScottK2> He needs some non-WINE uploads.
[16:53] <cody-somerville> RainCT, Let me know when you upload so that I can notify the appropriate people.
[16:53] <\sh> ScottK2: also :)
[16:54] <\sh> well...point 10 on my todo for tonight
[16:54] <RainCT> cody-somerville: have you fixed it in bzr?
[16:55] <cody-somerville> RainCT, Oh. I can fix that now for you, sure.
[16:55]  * sistpoty is afk... later
[17:04] <siretart> siretart: thanks
[17:06] <james_w> :-)
[17:13] <milli>  \sh:  I tested out lighttpd 1.4.19, round-robin still doesn't work.  It cycles thru the back-ends once, then sticks on the first back-end.  :(
[17:14] <elmargol> someone knows how many users use popcon?
[17:15] <cody-somerville> RainCT, Test build is almost done
[17:15] <sebner> RainCT: Sry. I totally forgot to add the missing changelog entry. Are you reviewing it now or can I subscribe u-u-s?
[17:16] <james_w> elmargol: check the popcon installed count for base-files, that should be close.
[17:16] <james_w> well, that would be how many machines have submitted at least once, but it would give you an idea.
[17:17] <\sh> milli: bah...upstream issue :9
[17:17] <RainCT> sebner: ubuntu-archive is already subscribed iirc
[17:17] <RainCT> sebner: so just wait for them to sync it :)
[17:18] <ScottK2> \sh: Upstream apparently over promising in their changelog
[17:19] <sebner> RainCT: through motu-release? because I confirm that they are subscribed
[17:19] <elmargol> james_w: I',m looking for a percentage... like 10% of the userbase has popcon enabled or something
[17:19] <sebner> RainCT: * can't confirm
[17:19] <james_w> elmargol: tell me what the userbase is and I'll give you a percentage based on the number that have installed base-files.
[17:20] <RainCT> sebner: oh, it seems like I looked to fast at the subscribers :)
[17:20] <slomo> LucidFox: hi, see #ubuntu-devel... we'll have gtkhtml-sharp-3.14 soonish, would be nice if you could not drop that patch from debian when merging :)
[17:20] <sebner> RainCT: np ^^. I'll subscribe. But you may want to ACK first (sponsors ACK) ?
[17:20] <LucidFox> slomo> yes, I answered your mail :)
[17:20] <elmargol> james_w: your are right I'm looking for the userbase D
[17:21] <slomo> LucidFox: when will it be ready? :)
[17:21] <LucidFox> merging has other benefits as well
[17:21] <LucidFox> slomo> after gtkhtml is
[17:21] <james_w> elmargol: it looks like maybe as much as 10%.
[17:21] <RainCT> sebner: yeh, just ack'd and subscribed ubuntu-release
[17:21] <slomo> LucidFox: ok, ping me then please :)
[17:21] <sebner> RainCT: you mean archive-admins
[17:21] <ScottK2> RainCT: ubuntu-release or ubuntu-archvie?
[17:21] <ScottK2> archive even
[17:22] <RainCT> argh
[17:22] <RainCT> :P
[17:22] <sebner> RainCT: np and thx :)
[17:27] <cody-somerville> RainCT, I'm having some problems with my branch
[17:27] <cody-somerville> RainCT, Weird permission issues :(
[17:28] <cody-somerville> RainCT, If you could just make the change and push the branch to launchpad under your own username and request a merge, I'll be sure to take care of it
[17:35] <RainCT> cody-somerville: ok
[17:36]  * ScottK2 makes notes about how simple using bzr makes everything ... ;-)
[17:37] <RainCT> cody-somerville: about those weird permission issues, how did you do the chmod -x?
[17:40] <cody-somerville> I dunno, for some weird reason it wouldn't even let me access the xubuntu/ directory
[17:41]  * cody-somerville is still waiting for the branch to download again.
[17:41] <RainCT> cody-somerville: then you've -x'd the directory itself :P
[17:41] <cody-somerville> doh.
[17:42] <slangasek> bzr: 1, coreutils: 0
[17:45]  * RainCT is waiting for the package to build to check if he got the permission thing right before uploading
[17:48] <RainCT> is it possible to commit into a new branch from a lightweight checkout?
[17:50] <cody-somerville> yes but I think you need write access on the server
[17:50] <RainCT> and how can I do that?
[17:50] <james_w> RainCT: you can use switch to switch your checkout to another branch, but that branch must exist first.
[17:51] <james_w> so I think if you push first, and then switch you should get what you want.
[17:57]  * cody-somerville still checking out the heavy branch
[18:01] <RainCT> cody-somerville: it's clean now, uploading :)
[18:02] <cody-somerville> RainCT, thank you.
[18:03] <RainCT> np :)
[18:04] <RainCT> james_w: seems like it even works. didn't know that you can push from a lightweight checkout.. thanks :)
[18:05] <james_w> RainCT: no problem, push still works, it would just be slower as it sucks all the data down to your machine, and then pushes it to the other location.
[18:07]  * RainCT is hoping that the LP guys will get server-side branching ready soon :P
[18:14] <Festor> Would it be possible to add transmission 1.10 to 8.04 Ubuntu repositories?
[18:14] <Festor> It launched the first beta
[18:14] <Festor> http://forum.transmissionbt.com/viewtopic.php?t=4365
[18:15] <cody-somerville> Probably not
[18:16] <Festor> :( ... 1.06 is a bit buggy
[18:16] <cody-somerville> Is 1.10 just a bug fix release?
[18:16] <Festor> not
[18:16] <Festor> added libnotify support
[18:17] <Festor> more translations
[18:17] <ScottK2> Is transmission Main or Universe?
[18:17] <ScottK2> jdong: ^^^
[18:17] <cody-somerville> !transmission
[18:17] <ubotu> Sorry, I don't know anything about transmission - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[18:17] <Festor> and bugfix
[18:17] <cody-somerville> !info transmission
[18:17] <ubotu> transmission (source: transmission): free, lightweight BitTorrent client. In component universe, is optional. Version 0.72.dfsg-1 (gutsy), package size 7 kB, installed size 56 kB
[18:17] <ScottK2> I think it may be Main in Hardy
[18:17] <cody-somerville> I agree.
[18:17] <cody-somerville> Yes
[18:17] <cody-somerville> It is in main.
[18:18] <Festor> this
[18:18] <Festor> http://trac.transmissionbt.com/query?status=closed&milestone=1.10
[18:18] <Festor> are all changes
[18:19] <cody-somerville> Festor, Transmission is in Main.
[18:19] <ScottK2> Festor: Since it's in Main, you need to discuss on #ubuntu-devel, not here.
[18:19] <Festor> ok. thanks :d
[18:23] <xtknight> it isn't at all possible to upload a full new version of a program for Gutsy, is it?  e.g., gnome-schedule 1.0.0 is in gutsy, and repacking 2.0 for it instead of fixing the bug in 1.0.. it just seems logical in this situation  https://bugs.launchpad.net/ubuntu/+source/gnome-schedule/+bug/204496
[18:23] <ubotu> Launchpad bug 204496 in gnome-schedule "gnome-schedule GTK About Box frozen and help nonfunctional" [Undecided,New]
[18:24] <cody-somerville> xtknight, You can backport from Hardy
[18:24] <ScottK2> It is possible, but it's a last resort.  It seems extreme for an about/help problem.
[18:25] <ScottK2> cody-somerville: Backports are for feature upgrades, not for bug fixing
[18:25] <xtknight> ah ok i guess i was thinking more alone the lines of since the program is so small, 2.0 prolly contains updates that are worthwhile and would also fix the problems
[18:26] <slytherin> xtknight: why not backport the fix for the particular problem?
[18:26] <ScottK2> xtknight: Right, but that's not generally how stable release updates work
[18:26] <cody-somerville> ScottK2, I'm well aware. However, SRU only permit specific bug fixes where xtknight was suggesting uploading an entire new version instead of putting the effort to patch the old version. Hence, I suggested backporting.
[18:26] <xtknight> slytherin, well that's my other choice ya
[18:27] <xtknight> i don't mind i was just wondering what you guys thought
[18:27] <ScottK2> cody-somerville: Thereby avoiding the SRU and preventing people who do not have backports enabled (the default configuration) from getting the benifit of the fix.
[18:27] <cody-somerville> ScottK2, indeed.
[18:27] <slytherin> wow, elisa is in main. :-)
[18:27] <ScottK2> xtknight: I'd suggest try to figure a bug specific patch
[18:27] <xtknight> will do
[18:29] <cody-somerville> xtknight, if you need help, feel free to ask
[18:29] <xtknight> thanks
[18:29] <cody-somerville> xtknight, You might refer to https://wiki.ubuntu.com/StableReleaseUpdates
[18:34] <xtknight> i do "sudo apt-get build-dep gnome-schedule" and then "sudo apt-get -b source gnome-schedule" fails with missing dep during ./configure
[18:37] <cody-somerville> xtknight, the new version must have a new dependency :)
[18:37] <cody-somerville> xtknight, Maybe something to do with the new inotify feature?
[18:37] <xtknight> cody-somerville, well i am trying to build the old gnome-schedule-1.0.0 from repositories
[18:37] <cody-somerville> Ah.
[18:38] <xtknight> (gutsy amd64 that is)
[18:38] <xtknight> can you reproduce the problem ?
[18:38] <cody-somerville> xtknight, Why not try building it in a chroot using pbuilder?
[18:38] <xtknight> if you have a gutsy machine and dont mind
[18:38] <xtknight> cody-somerville, oh i am trying a chroot next, but should build-dep not install dependencies on an actual machine/
[18:39] <cody-somerville> xtknight, Yes.
[18:47] <fbond> Does ${misc:Depends} ever have a value?  Under what circumstances?
[18:52] <slytherin> fbond: Good question. Even I am looking for an answer. :-)
[18:53] <fbond> slytherin: I don't see it in the manual pages anywhere...
[18:54] <slangasek> it's populated by various debhelper scripts that need to set extra dependencies
[18:54] <slangasek> e.g., dh_installdebconf
[18:56] <fbond> slangasek: Should every binary package have `Depends: ${misc:Depends}'?
[18:56] <pochu> huats: I'm now
[18:57] <slangasek> fbond: if you're using debhelper (or cdbs), it's good practice
[18:57] <\sh> bah..ports.ubuntu.com ha hickups today
[18:57] <\sh> timeouts, forbidden etc.
[18:57] <emgent> heya people :P
[18:57] <huats> hey pocu
[18:57] <fbond> slangasek: thanks!
[18:58] <huats> hey pochu
[18:58] <\sh> trying to mirror lpia now since yesterdays evening
[19:00] <calamari> hi
[19:00] <sebner> \sh: already at uploading stage for nexuiz? :P
[19:02] <calamari> I'm trying to get a binary rpm working (with the goal of creating a debian package out of it).  What are the equivalents of libssl.so.6 and libcrypto.so.6.  I'm seeing versions like 0.9.7 which is hard to relate with "6"
[19:03] <slytherin> calamari: Why don't you instead try to created debian package from original source
[19:03] <\sh> sebner: I don't upload anything...it will be a sync..
[19:03] <calamari> slytherin: I'd love yto, but the source is not available
[19:04] <slytherin> calamari: what do you mean by source is not available?
[19:04] <calamari> slytherin: binary only
[19:04] <\sh> sebner: I'll file the sync reqs just in a few mins
[19:04] <sebner> \sh: hmm what about uploading your mind to do the nexuiz sync?
[19:04] <\sh> sebner: I can't do any syncs...those will be worked on after the easter holiday I think :)
[19:05] <sebner> \sh: however. great. :D
[19:05] <slytherin> calamari: Do you mean to say it is not a open source software? By the way, people usually recommend using alien to convert rpm to deb
[19:06] <calamari> slytherin: correct.. not open source.  alien is certainly a first step, however I'm past that now and need to do some internal tweaking
[19:07] <calamari> slytherin: so my main question is what are the Ubuntu equivalents of libssl.so.6 and libcrypto.so.6?
[19:07] <slytherin> calamari: I can not find one at least on hardy. Looks like it is very old version
[19:08] <slangasek> calamari: what does the ELF binary actually depend on?
[19:09] <slangasek> calamari: I have *never* seen a libssl.so.6 library on Linux; I would want to confirm that this is the library name that the binary is looking for, as opposed to just the virtual package name that the package is looking for
[19:09] <calamari> aha.. I think it's 0.9.8b
[19:10] <ScottK2> I doubt it.
[19:10] <james_w> hey, jdong, could you sponsor that bzr-svn fix I was talking about please?
[19:10] <calamari> http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/libssl.so.6
[19:11] <\sh> sebner: https://bugs.edge.launchpad.net/ubuntu/+source/nexuiz-data/+bug/204771
[19:11] <ubotu> Launchpad bug 204771 in nexuiz-data "[FFe SYNC Req] nexuiz nexuiz-data fteqcc" [Undecided,New]
[19:11] <slangasek> calamari: then the answer should be libssl0.9.8
[19:11] <RainCT> cody-somerville: damn is that slow :/
[19:11] <cody-somerville> RainCT, bzr?
[19:11] <RainCT> cody-somerville: yes, and my connection :P
[19:12] <calamari> slangasek: thanks
[19:12]  * RainCT aborts the pushing
[19:12] <sebner> \sh: why making a new one. why not attaching to bug #203210
[19:12] <ubotu> Launchpad bug 203210 in nexuiz-data "Please upgrade nexuiz/nexuiz data to 2.4" [Undecided,Confirmed] https://launchpad.net/bugs/203210
[19:12]  * cody-somerville wishes bzr was faster.
[19:12] <RainCT> cody-somerville: just get the clean source from bzr (if you haven't it yet) and run this:
[19:12] <RainCT> cody-somerville: find common -type f | xorg chmod -x
[19:12] <\sh> sebner: because it's easier for me and hopefully the archive admins to find the necessary bits :)
[19:12] <RainCT> cody-somerville: find xubuntu -type f | xorg chmod -x
[19:12] <calamari> here was the ldd http://rafb.net/p/on9jNH68.txt
[19:12] <RainCT> cody-somerville: that should do it
[19:12] <sebner> \sh: k, great then :D
[19:13] <sebner> \sh: what about setting the importance to Critical? :P
[19:13] <cody-somerville> xorg cmd isn't found
[19:13] <calamari> (just to prove I'm not crazy.. hehe)
[19:13] <slangasek> s/xorg/xargs/
[19:13] <slangasek> nice typo though :)
[19:14] <\sh> sebner: think you need to learn more about the ways of workflow for ubuntu ;)
[19:14] <RainCT> cody-somerville: oops, I mean xargs :P
[19:14] <RainCT> slangasek: heh
[19:16]  * cody-somerville pushes.
[19:20] <calamari> thanks for everyones help, you guys are great
[19:27] <\sh> bah...how do I unsubscribe a team?
[19:29] <slangasek> by being part of it?
[19:29] <\sh> correct
[19:29] <slangasek> and clicking Subscribe/Unsubscribe
[19:30] <\sh> grmpf...can someone add me to sponsors pls :)
[19:30] <\sh> universe-sponsors
[19:30] <\sh> persia: ?? ;:)
[19:34] <xtknight> hmm can anyone get a PPA?
[19:34] <xtknight> or just special members
[19:35] <pochu> you need to sign the CoC
[19:35] <pochu> then you can
[19:35] <xtknight> ah cool
[19:36] <emgent> xtknight: you can also read https://help.launchpad.net/PPAQuickStart
[19:37] <cody-somerville> RainCT, Would you be able to upload xubuntu-docs again?
[19:41]  * RainCT knew that he shouldn't have deleted the checkout :P

[20:03] <Bruno_> hello, i need some help with patchin...
[20:03] <RainCT> Hi Bruno_, just ask
[20:03] <xtknight> um so compiling anything you find on sourceforge and then debianizing it is fair game for uploading to PPA right?
[20:04] <xtknight> if you provide source packages should there be modifications..
[20:04] <Bruno_> RainCT: well, im trying to fix this bug (it my first try at fising bugs) https://bugs.edge.launchpad.net/ubuntu/+source/typo3-src/+bug/132703/ and i dont know how to make the patch
[20:04] <ubotu> Launchpad bug 132703 in typo3-src "Suggests: ooo_extract, which is an illegal package name" [High,Confirmed]
[20:04] <\sh> xtknight: no...you provide source packages for everything you are going to distribute...
[20:05] <\sh> xtknight: and you need to read the license before..if it's possible to redistribute
[20:05] <\sh> not everything on sf.net is redistributable
[20:06] <RainCT> Bruno_: you don't need a patch there; you can just change the debian/control file directly
[20:06] <xtknight> \sh, anything open source in the ubuntu repositories is redistributable isn't it?
[20:06] <xtknight> or not necessarily?
[20:07] <\sh> xtknight: seems so :)
[20:07] <xtknight> and btw i did read the agreement for ppa but that's why i'm paranoid ;)
[20:08] <\sh> xtknight: I meant the license of the stuff laying around on sf.net :)
[20:09] <xtknight> ah ya
[20:09] <RainCT> Bruno_: but this is already fixed in Hardy
[20:09] <RainCT> Bruno_: "Suggests: catdoc, httrack, ppthtml, unrtf, webhttrack, xpdf-utils, xlhtml"
[20:09] <Bruno_> RainCT: so there is nothing left to do?
[20:10] <RainCT> Bruno_: no, just close the bug and say that it's fixed in Hardy
[20:11] <RainCT> (close = Fix Released)
[20:12] <Bruno_> RainCT: ok, done. Where can i find bugs that i can fix?
[20:12] <Bruno_> RainCT: or at least attempt to fi
[20:12] <Bruno_> x
[20:12] <RainCT> Bruno_: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[20:13] <RainCT> Bruno_: for example bug #164181 doesn't seem too difficult to fix
[20:13] <ubotu> Launchpad bug 164181 in cryptsetup "Manual page typos" [Low,New] https://launchpad.net/bugs/164181
[20:15] <Bruno_> RainCT: ok i'll try to fix it
[20:16] <RainCT> cody-somerville: you owe me a hug ;)
[20:16]  * cody-somerville gives RainCT a bear hug.
[20:19] <RainCT> Bruno_: for this one you'll need a patch, using the "dpatch" system (you can check what patch system a package is using running "what-patch" inside the source directory, if you have ubuntu-dev-tools installed)
[20:20] <RainCT> Bruno_: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#head-5f4642a5564760bd8aae0fd2cbd70e6cd78c1260
[20:21] <Bruno_> RainCT: thanks
[20:27] <Bruno_> RainCT: ok i ran dpatch-edit-patch to apply all the patched, but how do i create mine
[20:33] <RainCT> Bruno_: dpatch-edit-patch will leave you in a subshell. just do all the changes you want there and then exit with "exit 0" and it will create a patch in debian/patches
[20:33] <Bruno_> RainCT: ok
[20:34] <RainCT> Bruno_: note that with dpatch you have to add the name of the patch to the debian/patches/00list file (in a new line) to enable it
[20:34]  * RainCT is away now
[20:35] <\sh> guys, do you think it would be a good idea to package drupal6 for hardy? :)
[20:37] <ScottK2> \sh: Maybe two months ago.
[20:39] <\sh> ScottK2: yeah..sad story
[20:41] <\sh> ScottK2: I just checked the svn repo of the drupal maintainer...but it looks like, that they didn't even start with packaging
[20:46] <ScottK2> \sh: I think we need to let it pass for Hardy.
[20:46] <\sh> ScottK2: yepp...well...backport is always an alternative
[20:47] <sebner> slomo: around?
[20:47] <slomo> yes
[20:47] <ScottK2> \sh: Yes.  That'd be the way to do it.
[20:47] <sebner> slomo: gtk-sharp2 2.12 is now in hardy. But it seems you/they ignored my merge?
[20:49] <slomo> sebner: oh... sorry :/ i didn't notice that you also did a merge, i thought you just took the data from the debian package
[20:49] <slomo> sebner: did i miss something when merging?
[20:50] <sebner> slomo: now I'm sad. I asked you how I could help and you told me that it would be nice if I merge gtk-sharp and gnome-sharp and I said ok
[20:50] <sebner> slomo: bug #203298
[20:50] <ubotu> Launchpad bug 203298 in gtk-sharp2 "[FFe] Merge gtk-sharp2 2.12.0-2 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/203298
[20:51] <sebner> slomo: and. bug #203314
[20:51] <ubotu> Launchpad bug 203314 in gnome-sharp2 "[FFe] Merge gnome-sharp2 2.20.0-2 from Debian(Unstable)" [Undecided,New] https://launchpad.net/bugs/203314
[20:51] <slomo> sebner: damn, sorry again :/ would've saved me some time too if i'd known that you've merged it already... wasn't my intention to ignore your merge
[20:51] <sebner> slomo: well you asked me to do it and I accepted. Wired :(
[20:52] <ScottK2> Stuff happens
[20:52] <\sh> all the time :)
[20:53] <sebner> Maybe I should have asked you after 2-3 days if there is an update
[20:53] <sebner> update/news/progress
[20:54] <ScottK2> sebner: When you want to get sponsored there's a fine line between asking for updates and being a pest.  Once you're a developer it's easy to forget to check what others have already done.
[20:55] <sebner> ScottK: well, he wanted it to get sponsored. I just made it because I wanted to help him ^^. nvm. S*** happens. And you are right. I don't want to annoy you everytime
[20:55]  * \sh should not forget to call his wife after 00:00am ... it's her birthday
[20:55] <sebner> xD
[20:55] <Bruno_> i made a patch for Bug #164181 how do i apply it?
[20:56] <ubotu> Launchpad bug 164181 in cryptsetup "Manual page typos" [Low,New] https://launchpad.net/bugs/164181
[20:56] <sebner> It seems that I have now the pleasure the set the status to "Fix Released" I suppose
[20:56] <\sh> Bruno_: make a debdiff with your patch applied or just attach the patch to this bug...and tag it with "patch"
[20:57] <Bruno_> \sh: ok
[20:57] <\sh> Bruno_: a debdiff is appreciated...subscribe ubuntu-universe-sponsors then
[20:58] <slangasek> slomo: er, you merged mono-tools but didn't fix the FTBFS?
[21:00] <slomo> slangasek: hrm, you mean the dep-wait on libxul-dev? well, will fix later, don't worry :)
[21:01] <sebner> slomo: just interested. what did you think what I was doing?
[21:01] <\sh> tomboy needs to be rewritten in python or c just because mono stinks ;)
[21:01] <slomo> sebner: i thought you had just collected the changelog diff, etc to file a FF exception bug
[21:02] <slomo> \sh: that was already tried by a few people... and they all disappeared before anything was released ;)
[21:02] <sebner> slomo: Well, true I filed the bug. ^^
[21:02] <\sh> slomo: did you see basket? the kde app ?
[21:02] <sebner> \sh: mono is cool :P
[21:03] <slomo> \sh: nope, why?
[21:03] <\sh> slomo: something like this but without the window, so directly positioning notes on the desktop...that would be cool for gnome, too :)
[21:03] <\sh> slomo: http://basket.kde.org/
[21:05] <\sh> sebner: read stephen kings "The Dark Tower", then you know why "mono" stinks ;)
[21:06] <slomo> \sh: where's the connection between the dark tower and mono? i've read the books some years ago
[21:06] <slangasek> yes, all the best insights into software design come from Stephen King books
[21:06] <\sh> slomo: the monorail train
[21:06] <slomo> ah... hehe :)
[21:11] <\sh> slangasek: and some abbreviations are cudos to arthur C. clarke ;)
[21:11] <ScottK2> c/k
[21:23]  * \sh goes a bit in the background....watching futurama :)
[21:31] <Bruno_> when i run debuild, it doesnt find my gpg key
[21:31] <Bruno_> how can i fix that
[21:32] <ScottK2> Bruno_: man dpkg-buildpackage and look at the -k option.
[21:32] <Bruno_> thanks
[21:43] <Bruno1> ok, so now i have a .diff.gz , how do i upload it?
[21:55] <RainCT> Bruno1: create a debdiff against the version which is currently in Hardy
[21:56] <RainCT> Bruno1: see https://wiki.ubuntu.com/PackagingGuide/Howtos/Debdiff
[22:01] <gouki> Can anyone help me out? When running dh_make I can't set the maintainers name.
[22:04] <RainCT> gouki: export it in a DEBFULLNAME variables (and the mail in DEBEMAIL)
[22:04] <RainCT> s/variables/variable
[22:06] <gouki> RainCT: Thank you.
[22:13]  * gouki may have built his first package
[22:16] <Bruno1> RainCT: when i run the las debdiff command i get "cant check signature"
[22:22] <Bruno1> RainCT:  never mind, i got it signed
[22:23] <Bruno1> RainCT: do i upload the debdiff to the bug page?
[22:25] <RainCT> Bruno1: yes
[22:26] <Bruno1> RainCT: ok
[22:26] <RainCT> Bruno1: and subscribe ubuntu-universe-sponsors to it
[22:26] <Bruno1> RainCT:  ok
[22:27] <Bruno1> RainCT: do i change status or anything?
[22:41] <sebner> gn8 folks
[22:58] <\sh> Bruno1: ubuntu-main-sponsors is better for cryptsetup
[23:01] <Bruno1> \sh: ok, and umm i dont know if my patch worked... i mean it there, but when i built a the cryptsetup .deb it didnt have the changes in the man page.
[23:03] <\sh> Bruno1: if you patch doesn't work..why did you upload it then?
[23:03] <\sh> Bruno1: make sure it works :)
[23:04] <\sh> Bruno1: think about this: it's a main package :)
[23:04] <Bruno1> im not sure if its not working
[23:04] <ScottK2> Then don't subscrive ubuntu-main-sponsors until it's figured out.
[23:04] <\sh> Bruno1: test it :) install the package and man <bla>
[23:05] <\sh> ScottK2: can you remove u-u-s from the bug?
[23:05] <Bruno1> i did dpatch-edit-patch and added my patch, but i dont know if it was also applied since my patch is not appearing in the patched folder
[23:06] <ScottK2> What bug #?
[23:06] <Bruno1> Bug #164181
[23:06] <ubotu> Launchpad bug 164181 in cryptsetup "Manual page typos" [Low,In progress] https://launchpad.net/bugs/164181
[23:06] <\sh> 164181
[23:07] <ScottK2> Bruno1: For dpatch you also have to add the patch to debian/patches/00list
[23:07]  * ScottK2 does
[23:07] <\sh> persia: needs to add me somehow to sponsors
[23:08] <Bruno1> ScottK2: ok i added it to the list
[23:08] <ScottK2> uus removed
[23:09] <ScottK2> \sh: I don't know about that.  You're a pretty new motu....
[23:09] <ScottK2> ;-)
[23:09] <\sh> lol
[23:10] <Bruno1> ScottK2: so if it wasnt on the list when i made the .debdiff its not going to work?
[23:10] <ScottK2> No.
[23:10] <ScottK2> It means the patch wouldn't be applied.
[23:10] <Bruno1> so i make a enw debdiff
[23:11] <ScottK2> Some patching systems patch what you tell them to (dpatch) others essentially use everything in /patches.
[23:12] <Bruno1> ok. is there a way to remove the patch i uploaded?
[23:13] <\sh> Bruno1: bug attachements -> edit attachment -> delete
[23:13] <Bruno1> ok
[23:13] <\sh> it's on the left portlet
[23:14] <\sh> or is it "zopelet" ? dunno
[23:15] <\sh> ok...time to hit the bed
[23:16] <\sh> good night folks...
[23:17] <Bruno1> bye, thanks for the help
[23:29] <Bruno1> ScottK2: i downloaded the source to start again and after doing dpatch-edit-patch and doing the patch and editing the 00list, i couldnt find my patch on the debian/patches folder, it is, however, listed in 00list
[23:33] <ScottK2> Odd
[23:35] <ScottK2> I have had occasional trouble like that.  I don't know why.  I've found that if I create the patch file manually (touch debian/patches/patchname.dpatch) and then use dpatch-edit-patch it works.
[23:37] <Bruno1> ScottK2: you mean for example i create manpage_typo_fix.dpatch and then use dpatch-edit-patch to make the changes?
[23:37] <ScottK2> yes
[23:44] <RainCT> good night
[23:44] <Bruno1> ScottK2: i tried doing what you said and it got some errors about the patch not existing. Im doing the whole thing again, i just have this question, do i edit the 00list while in the shell dpatch-edit-patch gives you, or afterwards.
[23:44] <Bruno1> RainCT: bye, thanks for your help
[23:44] <RainCT> Bruno1: afterwards
[23:44] <RainCT> no problem, good luck :)
[23:44] <Bruno1> RainCT ok thanks
[23:47] <ScottK2> afterwards
[23:47] <Bruno1> ok
[23:48] <ScottK2> Bruno1: Don't change anything inside the debian/dir while you're in the dpatch-edit-patch shell.
[23:48] <Bruno1> ok
[23:53] <Bruno1> ok now i have the new patch and the debian/patches folder and its also listed in 00list
[23:53] <Bruno1> now do i run debuild ?
[23:54] <ScottK2> did you make a debian/changelog entry describing what you are changing, why, and making a new version?
[23:54] <Bruno1> i ran dch -i and added
[23:54] <ScottK2> Good
[23:55] <Bruno1> Fixed man page typos (LP: #164181)
[23:55] <ScottK2> Then run debuild -S to make your source package.
[23:55] <Bruno1> ok
[23:56] <Bruno1> done
[23:57] <Bruno1> should i make a .deb before the debdiff to test the patch?
[23:59] <ScottK2> Yes
[23:59] <ScottK2> My recommendation is you use pbuilder or sbuild to build in a clean environment.


[07:32] <ailo> persia: We will use puredata for the system load, so we should quite easily be able to scale the system load for any specific machine. I'm sure we could use our own program for that, but puredata makes things easier at least at this early stage.
[07:33] <ailo> My first idea was just to have two system loads, one low and one high. We can turn that into a latter.
[07:34] <ailo> ScottL: I made this hierarchy for the test results, device - kernel - test, and for each device, test all kernels
[07:36] <ailo> When we post the results of our tests, we just need to post for the same device, but different kernels.
[18:20] <persia> ailo, Does puredata support arbitrary numbers of threads/processes?  The key load issue isn't usually raw CPU cycles, but context switches.
[18:39] <ailo> persia: I need to find out more about that. I know you can have some sort of separation of processes, but I need to find out how exactly.
[18:41] <ailo> persia: Could you give me an example of what would be desirable.
[19:02] <persia> ailo, Basically, the goal would be to mimic someone running multiple JACK clients simultaneously.  Consider a recording session with lots of effects, or a polyphonic synthesizer (using different engines), or similar.
[19:03] <persia> Unfortunately, context switches are expensive, and are one of the major causes of missing scheduling deadlines.  Hard RT forces deadlines to be met, but may drop processes to achieve this.  Soft RT maintains all the processes, but may drop deadlines to achieve this.
[19:03] <persia> So it would be interesting to find the failure points for both soft- and hard- strategies on a variety of hardware.
[19:04] <persia> Similarly, it becomes interesting to compare soft RT handling of failures from -generic, -server, and -lowlatency
[19:07] <persia> Forcing the failure is a matter of increasing the demand for scheduled events under processor load/context switch pressure.
[19:07] <persia> This can be because you have a lot of different things happening at the same time, or something happening exceedingly often.
[19:08] <persia> So, latency measurement affects this: lower latency requires more demand events, which then limits the system's ability to handle multiple simultaneous event generators within the scheudle (considering the cost of context switches)
[19:10] <ailo> persia: Puredata can have subprocesses, which are created manually. I guess that is what we need.
[19:12] <persia> That works fine then, and gains the benefits of scriptability.
[19:15] <ailo> I don't know how that compares with having different actual programs running, since they may have different jack coding too.
[19:16] <ailo> And what about multiple cores, won't that affect how many processes need to be started?
[19:20] <ailo> persia: thanks for the info. I will look it over and try to put all that into the puredata patch
[19:55] <persia> Multiple cores do affect it, but in a complex way.  You can run more threads on more cores simultanseously, which helps scheduling, but if you're running the kernel, JACK, and a few generators/effects, you can run out of cores quickly.
[19:55] <persia> For that matter, the kernel ends up being something like 25 threads these days.
[22:56] <rlameiro> hey evryone
[22:57] <rlameiro> the last iso build isnt installing....
[22:58] <ailo> rlameiro: http://irclogs.ubuntu.com/2011/01/30/%23ubuntustudio-devel.html
[23:00] <rlameiro> ailo: well, you could open diferent instances of pd...
[23:01] <ailo> rlameiro: That's true. Don't know which is better, but that would work.
[23:01] <rlameiro> also if you use [pd~] you open a pd grapher inside other, making another process
[23:01] <rlameiro> mutlithread sort of speak
[23:02] <ailo> Yes, that is what I was thinking about
[23:03] <rlameiro> but i think persia was talking about switching of diferent process
[23:03] <rlameiro> even connectin in jack etc
[23:03] <persia> rlameiro, Precisely.  Mind you, this could be several pd instances
[23:03] <rlameiro> like that, we could make some internal midi latency test also between pd instances
[23:05] <ailo> I don't understand, switching between processes?
[23:05] <persia> Yes.  This is an expensive operation for most hardware, which makes it prone to causing issues with meeting timing contracts.
[23:07] <ailo> Opening pd will likely cause xruns. Don't think we have that problem when switching between different pd~ objects (pd~being an object that creates a new sub-process)
[23:07] <rlameiro> ailo, in a nutshell, each pprocess or PID has a schedulling timer on the kernel
[23:08] <rlameiro> The more demanding process are active the more is the CPU / RAM and system buses are pushed
[23:08] <persia> ailo, Precisely.  Opening processes causes xruns for low-latency environments.  Switching between processes causes xruns.  The key is that if we discover that if we're only running one process in some environment and can get latencies of 2ms at sampling rates of 192kHz, it doesn't apply well to real-world usage.
[23:09] <rlameiro> if you have less demanding process the scheduler simply gives more time to that process
[23:11] <persia> Well, not always.  If all current contracts are met, and all current non-RT processes have no pending processing, and all buffers are populated, the processor will idle.
[23:12] <persia> (a frequent cause of "no pending processing" is waiting on I/O, which can be dealing with a slow 44100 input feed, or reading off disk, or slowest, waiting for network content)
[23:12] <ailo> I didn't realize pd~ opened a new instance of pd.
[23:12] <rlameiro> persia: or even Firewire overhead...
[23:12] <persia> rlameiro, Or USB :)  Indeed, any sort of I/O.
[23:12] <rlameiro> ailo: yes on the back
[23:12] <ailo> btw, I'm not believing the performance I'm getting from the latest -generic.
[23:13] <ailo> Interesting to find out in more detail
[23:13] <rlameiro> I remebr having to change my bluetooth dongle because it was messing with my audio interface
[23:13] <rlameiro> same hub channe;l
[23:14] <rlameiro> persia: thats aanother problem people seem to disregard
[23:14] <rlameiro> we focuss to much on CPU.... i think its a legacy thing
[23:15] <persia> Yeah, IO optimisation is mostly considered a "server thing", sadly.
[23:15] <rlameiro> for composing on a DAW and lot of synts /sampler the most needed stuff is Memory and Fast I/o
[23:15] <rlameiro> for instance using RAID 0
[23:15] <rlameiro> for data
[23:15] <persia> How does the -server kernel compete?
[23:15] <rlameiro> and having the OS on a SSD
[23:16] <rlameiro> in audio persia ?
[23:16] <persia> Yes.
[23:16] <rlameiro> good question
[23:16] <rlameiro> never tried it out...
[23:16] <persia> OS on SSD doesn't always help: the path of the SSD is important, and the speed of the SSD (some aren't actually that fast)
[23:17] <rlameiro> welll, The RAID0 disk i mentioned werent 5400 rpm either :D
[23:17] <rlameiro> i was talking 10krpm
[23:17] <persia> -server is supposed to be optimised for IO and fair scheduling under resource constraint, as opposed to the "Ooh, shiny, the user moved the mouse, let's update the screen!!!!!" focus of the -generic kernels
[23:17] <rlameiro> at least 7200rpm
[23:18] <rlameiro> persia: I wonder how is that diferentiated...
[23:18] <rlameiro> audio could be considered shiny...
[23:20] <persia> I don't know the details.  My limited understanding is that it's something like the -generic kernel giving priority to new processes, redraws, and similar, whereas the -server kernel gives priority to ensuring that IO isn't waiting on the processor.
[23:20] <rlameiro> hummm
[23:20] <persia> So for -generic, foreground vs, background is more important, etc.
[23:21] <rlameiro> RT kernels were made for that stuff....
[23:21] <persia> But I don't understand the details.
[23:21] <rlameiro> stock market and stuff
[23:21] <persia> RT kernels are about ensuring the scheduling contracts are met, not about optimising performance one way or another.
[23:22] <rlameiro> yeap, on the stock market they need big I/o and Strict scheduling
[23:22] <persia> This ends up looking like optimised performance, but it's kinda by accident, because the RT-using applications are meeting their contracts, although the rest of the system may be resource-starved.
[23:22] <persia> 22 seconds :)
[23:23] <rlameiro> well, a wrong app with RT permission can make a computer unusable for some time :D
[23:23] <persia> Any app with RT permission can, it's just a matter of the contract requirements vs. the capacity of the system.
[23:24] <persia> Personally, I'm of the view that RT is only required when either pushing the system beyond normal limits *OR* dealing with a system that has unpredictable resource requirements due to non-essential processes.
[23:24] <persia> That said, it's not very hard to push a current-tech system beyond it's limits, if one tries :)
[23:25] <rlameiro> yeap
[23:25] <rlameiro> on my case Firewire with a suboptimal FW chipset from ricoh
[23:26] <persia> The driver is so bad you need RT constraints to be able to stream audio?
[23:32] <rlameiro> at low latencies
[23:33] <rlameiro> its a chipset problem too