[00:00] <frenchy> Greetings MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV.  I'm still awaiting my first advocate.  See http://revu.tauware.de/details.py?upid=712.
[00:00] <superm1> jdong, interesting bug
[00:01] <StevenK> jdong: It doesn't seem to stop, no.
[00:01] <superm1> i'm not really sure.  i can't think of anything that we are doing that would affect said behavior
[00:01] <jdong> StevenK: strace look similar?
[00:01] <jdong> StevenK: can you get me an strace without any uploads/downloads going?
[00:01] <jdong> superm1: can you confirm his bug though?
[00:01] <superm1> jdong, not right now.  i'll subscribe to it and try to take a look when i get to a machine with xvmc
[00:02] <StevenK> jdong: Sure
[00:02] <ssh_rdp> Hi, how can I tell pbuilder to fetch build dependencies from universe too? ( I have added Section: universe/python ...)
[00:03] <StevenK> jdong: Mailed
[00:05] <ssh_rdp> and COMPONENTS="main restricted universe multiverse" in .pbuilderrc
[00:10] <frenchy> Any MOTU with a DVB card, I'd especially appreciate!
[00:10] <jdong> StevenK: hmm and you say these strace items keep CPU at what percentage?
[00:11] <StevenK> jdong: ~20%
[00:11] <jdong> StevenK: no difference between whether window is open or closed?
[00:11] <StevenK> jdong: I usually keep it minimised
[00:11] <RAOF> frenchy: I've got me a dvb card, and reception to rubbish to use it :(
[00:12] <StevenK> RAOF: Send it here, I have great reception. :-P
[00:12]  * jdong compares with his strace
[00:14] <jdong> StevenK: hmm my strace looks almost identical but no CPU usage :-/
[00:14] <jdong> StevenK: and the cpu usage is coming out of KTorrent's process?
[00:15] <StevenK> jdong: At the moment it's coming from cc1 :-)
[00:15] <StevenK> jdong: When this build finishes, I'll double check with top
[00:15] <jdong> StevenK: LOL :)
[00:15] <jdong> StevenK: you don't have an indexing daemon crawling either .kde/share/ or your torrent download dir, do you?
[00:15] <frenchy> RAOF: Sorry to hear that, I've built myself a DVB application for GNOME and I was trying to get some feedback on it.
[00:16] <StevenK> jdong: Probably. I haven't disabled tracker, because it hasn't gotten in my way
[00:16] <frenchy> RAOF: I was talking to a guy in Germany who got it to work with a spoon.
[00:17] <jdong> StevenK: :-/ well see if tracker is the root cause
[00:17] <frenchy> RAOF: So your DVB-T also ... excellent ... Germany/Spain/Australia?
[00:17] <frenchy> s/your/you're/
[00:18] <RAOF> frenchy: Australia.  And I have *some* reception.  Just not enough to replace my analog TV with a mythbox.
[00:18] <frenchy> RAOF: I'm in Canberra.
[00:19] <StevenK> RAOF: Get a better antenna?
[00:19] <StevenK> jdong: top still points to ktorrent
[00:19] <jdong> In Soviet Russia, better antenna gets YOU
[00:19] <StevenK> Boo, hiss
[00:19] <jdong> lol
[00:19] <jdong> StevenK: :-/ ktorrent is using 20% CPU idling? :(
[00:19] <StevenK> jdong: Right
[00:19] <jdong> StevenK: what kind of CPU are we talking about?
[00:20] <StevenK> 12214 steven    15   0  306m  46m  20m S 13.9  3.1   5:15.76 ktorrent
[00:20] <RAOF> StevenK: I'm using the flat's external aerial.  All my internal antennae haven't done any better.
[00:20] <StevenK> jdong: A 3GHz Celeron
[00:20] <StevenK> (in long mode)
[00:20] <jdong> StevenK: hmm I'm pretty stumped then; your strace looks identical to mine...
[00:21] <StevenK> Okay, so it's because ktorrent sucks. :-)
[00:21] <RAOF> jdong: Maybe x86-64 has a worse futex implementation?
[00:21] <frenchy> RAOF: Anyway, I'd appreciate your feed back sometime.
[00:21] <jdong> RAOF: that is possible
[00:21] <jdong> can anyone reproduce on x86-64 too? :D
[00:25] <RAOF> frenchy: I'd be happy to give it.  URL?
[00:27] <effie_jayx> hey all
[00:27] <effie_jayx> how many packages are there in ubuntu?
[00:28] <effie_jayx> nevermind
[00:28] <effie_jayx> 23518 packages
[00:30] <leonel> effie_jayx: and those are not enough :-P
[00:35] <LaserJock> effie_jayx: depends on release, if you're counting just source packages, and what arch if not :-)
[00:37] <effie_jayx> ahhh cool
[00:37] <frenchy> Sorry, I sent it out a request for review a while ago.  Here it is again in case you missed it.
[00:37] <frenchy> Greetings MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV.  I'm still awaiting my first advocate.  See http://revu.tauware.de/details.py?upid=712.
[00:38] <frenchy> If you're not a MOTU then maybe you just ignored it.  I'd still really appreciate your feedback.
[00:41] <RAOF> frenchy: Oooh, it's a request for review, rather than a "try out my cool stuff" :)
[00:41] <frenchy> RAOF: I've gotta go but flick me an email with any comments, I'd really appreciate them.
[00:42] <RAOF> frenchy: I'll see if I can get around to it.
[00:42] <frenchy> RAOF: Is there something that I need to say?
[00:43] <frenchy> RAOF: I'll be back on later.
[00:44] <frenchy> RAOF: Sorry, gotta go ... life gets in the way sometimes.
[00:48] <jdong> StevenK: ok, upstream in several places typedefs Int32 to int and uses that to perform intense calculations like SHA1sums
[00:49] <jdong> StevenK: Heh I'll test kt more extensively on 64-bit but I wouldn't be surprised if its performance is much worse than on 32-bit
[00:50] <StevenK> jdong: Yay
[00:50] <StevenK> Isn't a short int 32 bits on 64 bit arches?
[00:51] <jdong> StevenK: I'm not too familiar with x86-64
[00:51] <jdong> StevenK: but I'm suspecting an int to not be 32-bits
[00:52] <StevenK> steven@liquified:~% ./size
[00:52] <StevenK> sizeof(int) = 4
[00:52] <StevenK> sizeof(short int) = 2
[00:52] <StevenK> So it is.
[00:52] <RAOF> Yup
[00:53] <jdong> hmm so int is 32-bits on x86-64?
[00:54] <RAOF> Assuming sizeof(char) = 8 bytes, yes.
[00:54] <RAOF> (A perfectly reasonable assumption, but not officially standard).
[00:54] <jdong> thanks
[00:55] <jdong> is long 64 in lm and 32 in regular?
[00:55] <StevenK> RAOF: 8 bytes?! 8 bits, maybe?
[00:55] <jdong> StevenK: he uses galactic unicode :D
[00:55] <StevenK> Muaha
[00:55] <persia> jdong: Yes, long int is full word size
[00:55]  * RAOF is on x86-512 :P
[00:55] <jdong> lurn sumthin new every day :)
[00:56] <StevenK> jdong: long int is 8 bytes
[00:56] <persia> StevenK: Even for ia32?  I've seen long int pointers work in ia32...
[00:56] <RAOF>  /me wonders why people don't use the standard int types.
[00:56] <StevenK> persia: This is on amd64
[00:57] <persia> StevenK: Right.  "long int" = 1 word (32/64/128/256)
[00:59] <StevenK> sizeof(long int) == sizeof(int) on ia32
[00:59] <StevenK> (So, as persia says :-)
[00:59] <persia> Actually, I've never tested that on a 256-bit machine.  Long int might only be 128 bits there
[01:00] <StevenK> Which machine has a word size of 128 bits?
[01:00] <StevenK> Aside from RAOF imaginary one.
[01:00] <persia> StevenK: A few in the HPC zone.  NEC has a couple, crusoe used to be one.  Nothing standard.
[01:00] <StevenK> Ah. Nothing 'regular people' can get their hands on
[01:01]  * persia notes really old Honnywells used to have a word size of 60 bits
[01:01] <persia> StevenK: crusoes were in consumer devices for a couple years, untili transmeta got out of the HW business.  NEC stuff is trickier to get.
[01:03] <StevenK> Why would crusoes have a word size of 128 bit, though?
[01:04] <persia> StevenK: It's a VLIW chip that runs ia32 in software emulation.  I don't know why they chose 128 bits, but apparently it almost worked for them.
[01:05] <StevenK> Oh, that's right. I forgot Crusoes were really special
[01:05] <RAOF> They just didn't quite have the money to go after the market they really were suited for, which was high-performance stuff IIRC.
[01:06] <persia> Actually, I really liked them for low-power stuff, but everyone was focused on HMDs, which are just clunky.  Now that we have small 200DPI screens, the handhelds are interesting again (and there are no crusoes)
[01:07] <slangasek> to ensure available space for both their transness and their metaness
[01:30] <bddebian> Heya gang
[01:31] <RAOF> Hawdy bddebian
[01:31] <bddebian> Hi RAOF
[01:42] <ScottK2> persia: I saw you set the gaphor won't start bug to triaged and unassigned yourself.  Does it still not start?
[01:43]  * ScottK2 tries it.
[01:43] <persia> ScottK2: It still doesn't start.  Last I looked (~6 weeks back), upstream was releasing about once a week, and I couldn't get the snapshots available working.  I'm planning to try again in the future, but don't want to block anyone else's effort if they are motivated.
[01:44] <persia> More critically, the problem is well understood: it just needs some work: I don't think "new" is correct.
[01:45] <persia> Cédric was working on gaphas a bit more since I looked last, and I'm planning on pushing a 10x or 11x into the repos for hardy even it doesn't work, as the current version is just too old.
[01:46] <bddebian> persia: I have a new game for ya to debug for me ;-P
[01:46] <ScottK2> persia: OK.  Makes sense.
[01:46] <persia> bddebian: Which one this time (and do I get to forget conquest and scorched3d) ? :)
[01:47] <bddebian> SilverTree.  New package
[01:47] <bddebian> And of course not ;-P
[01:47] <persia> ScottK2: Most of the Ubuntu changes are in Debian, so we should be able to sync, although I won't want to wait for Debian after DIF.
[01:48] <persia> bddebian: OK.  What does it need?  (I am blind at this time of day)
[01:48] <bddebian> To work :-)  I finally got it building but now I get an error about an empty wml file on startup
[01:49] <persia> bddebian: What is a wml file?  Some internal xml?
[01:49] <bddebian> Seems so.
[01:50] <persia> Does it give a filename for the missing file, or just say "Can't load WML" or something similarly unhelpful?
[01:50] <bddebian> Pretty much that unhelpful :-)
[01:50] <bddebian> wml parse error: 'empty wml file'
[01:51] <ScottK2> persia: Does it still not work if built for python2.4?
[01:52] <persia> ScottK2: 9.4 or so works fine with python2.4, but it doesn't use gaphas, which is the current model.  9.x is also not supported upstream.  8.x doesn't work with modern python-gtk.
[01:52] <persia> bddebian: Yep: there's no scenarios in the upstream SVN.  Write a plot :0
[01:52] <ScottK2> persia: What about the 10.4 we have in the repos?
[01:52]  * persia looks
[01:53] <bddebian> Oh, scenarios, wtf
[01:53] <ScottK2> Since it depends on Zope and Zope only works with 2.4 (IIRC), I think any hope of getting with working wtih 2.5 is forlorn at this point.
[01:54]  * ScottK2 needs to go put kids to bed.  See you later.
[01:54] <persia> ScottK2: Right.  I forgot about that.  That doesn't work either: it has a zope problem, and uses gaphas 0.2.x (I just asked for the gaphas 0.3.x sync recently, so it needs a bump, if nothing else).
[01:54] <ScottK2> persia: ^^^
[01:54] <ScottK2> OK
[01:55] <ScottK2> Well I'd stick with Python 2.4 until Zope gets fixed for 2.5 (don't hold your breath).
[01:55] <persia> ScottK2: It doesn't need to depend on zope, but that's a different issue.  I'm putting it off until DIF, and will examine it again then.
[01:55] <ScottK2> Ah.    Read that again: I remember saying "Don't do that - it's stupid.  Also, fix gutsy now, and then do something else", but in a polite way.
[02:00] <jdong> persia: yeah, upon close read I detected "not gonna happen"
[02:00] <jdong> I'll comment on the bug too
[02:01] <persia> jdong: You've already rejected the backports task: let's keep it trim for the SRU.
[02:01] <bddebian> persia: Where do you see that there are no scenarios?
[02:01] <jdong> persia: ok, agreed
[02:01] <persia> bddebian: I can't find any?  (only looking with svn web gateway for a few minutes).
[02:02] <persia> bddebian: I suspect they'll be packaged alongside, as with wesnoth, and so might be hidden somewhere.
[02:02] <bddebian> I'll be damned if I can find them
[02:03] <persia> bddebian: Right.  didn't Baby say something about upstream not being ready yet?  Did that get sorted?
[02:04] <bddebian> Well according to the site and Forum it's supposed to be playable
[02:04] <bddebian> Of course the upstream tarball is b0rked
[02:04] <persia> bddebian: Hmmm.  The wiki has some guidelines and examples for wml files, and apparently it's format compatible with wesnoth.  I wonder...
[02:05] <bddebian> persia: yeah, it's the same devs as Battle for Wesnoth
[02:06]  * StevenK kicks autoconf
[02:07]  * bddebian kicks StevenK
[02:07]  * persia  watches two more versions climb out of the hedges...
[02:07] <bddebian> ?
[02:07] <StevenK> bddebian: So you're an old, buggy evil shell script?
[02:08] <StevenK> Although, persia has a point.
[02:08] <bddebian> Well I'm old and American so some might call me evil
[02:09]  * persia thinks bddebian is sufficiently unpredictable to be hard to write in shell: likely requires something more expressive.
[02:09] <bddebian> brainfuck? :)
[02:09] <StevenK> I can replace bddebian with a shell script
[02:09] <StevenK> #!/bin/sh
[02:09] <StevenK> echo "Complain about $SOMETHING"
[02:10] <StevenK> exit 0
[02:10] <bddebian> hahahahaha
[02:10]  * StevenK ducks
[02:10] <bddebian> You got me there
[02:10] <persia> StevenK: The art is defining $SOMETHING, and having the alioth and REVU plugins
[02:11] <StevenK> Okay, so I add a second line, ". /lib/persia/bddebian-funcs"
[02:12] <persia> Right.  I can't implement that in /bin/sh, but that's mostly a matter of not knowing higher curl syntax.
[02:12] <StevenK> persia: Dare I say ruby? :-)
[02:13] <persia> Probably could do it in Ruby: I don't know the http client syntax there either, but the interface is cleaner than pulling curl output into buffers in shell.
[02:14] <bddebian> Actually I think StevenK nailed me in one line :-(
[02:14]  * persia defers to the voice of experience
[02:15] <bddebian> Hmm, maybe this sucker just isnt ready for prime time
[02:16] <persia> bddebian: If you're feeling especially motivated you could ping them, but I doubt they'll get it clean enough in the next month.  Let's check again in mid-Jan: perhaps it'll be easier then (and we should still have time to get a sync in before FF).
[02:17] <bddebian> persia: I already pinged the guy about the shitty tarball release ;-)
[02:17] <persia> bddebian: Right.  That works then.  Maybe we'll get it sooner :)
[02:29] <jdong> Dear Anonymous Upstream Author:
[02:29] <jdong> Curse and screw you, with all respect, for packaging your sources as a tarbomb.
[02:29] <jdong> Love, jdong.
[02:30]  * jdong goes purge like 200 new files from his /tmp
[02:31]  * persia wants a tar switch which applies dpkg-style mangling to the extraction location automagically based on the tarfile name
[02:32] <jdong> persia: yes, or at least a "bomb defuser" switch to tar that refuses to extract when more than one entry is in the top-level-directory
[02:33] <persia> jdong: I was reading the docs recently, and -C might help, but I can't figure out how to get it to extract so that one level up from $(CWD) is guaranteed to be the start of the branching tree.
[02:33] <jdong> persia: -C sets a new root directory to extract into, same as navigating PWD to one level higher
[02:34] <persia> jdong: Still, gives some bomb protection :)
[02:34] <jdong> persia: I think I might hack up something for myself that just parses a tar -t type output to perform that sanity check
[02:34] <persia> jdong: Pass me the wrapper if you get one that's reasonably robust.
[02:36] <bddebian> jdong: Forward that to silvertree too will ya? ;-P
[02:36] <jdong> haha
[02:36] <jdong> you were bitten too?
[02:38] <jdong> persia: I'm thinking of something like "bombsquad tar xzvf foobar.tar.gz", (1) create new dir with temporary name (2) extract to that dir (3) Check # of 1st level entries, if more than one rename tempdir to tarball_name, if one then move that entry into ../
[02:39] <jdong> persia: should be reasonably robust
[02:40]  * Hobbsee waves
[02:40] <persia> jdong: Maybe: my worry in that case would be user error or assignment of tmp directories (/tmp may be on a different filesystem).  Take a look at dpkg - it's really smart about it, and can handle lots of different formats if asked nicely.
[02:41] <jdong> hmm I'll have to look into that
[02:42] <RAOF> Heya Hobbsee.
[02:42] <persia> jdong: Also, dpkg gets hit with 15,000 different kinds of wrapped tarballs, from every imaginable source: even if you do go with bombsquad, it might contain some pointers for corner cases.
[02:43] <jdong> persia: yeah, I'll have to look into some of its heuristics
[02:56] <LaserJock> we darn it, my printer still doesn't work
[02:56] <LaserJock> *well
[02:57] <LaserJock> I wonder if an update killed it somehow
[03:01] <RAOF> Dear deluge.  Please *release* the libtorrent you're based on, so I don't have to watch g++ grind through boost's mega
[03:01] <RAOF> -templates
[03:02] <persia> RAOF: Don't they use a specific alternate libtorrent?  I thought I saw something about some other software using the same variant in the last couple days.
[03:02] <jdong> persia: yeah, we talked yesterday about that
[03:02] <RAOF> Yeah, there are apparently 2 libtorrents.
[03:02] <jdong> they use libTorrent, while rtorrent uses Libtorrent
[03:02] <RAOF> However, I *think* the libtorrent in universe is the one they use.
[03:03] <RAOF> Except that they don't.
[03:03] <RAOF> Alternatively, they could stop using boost/templates/c++.   I don't see why y'all need these NAT things. ;-)
[03:07] <jdong> StevenK: I'm supposed to be unbiased and love and feed all the torrent clients ;-)
[03:07] <persia> jdong: Ah.  NAT != router, but  I now understand.
[03:07] <jdong> persia: pfft mr. technical. I can play that game too
[03:07] <jdong> *finds his compiz bug report*
[03:07] <StevenK> persia: Exactly, NAT and routing are very different.
[03:08] <StevenK> jdong: Then get Transmission 0.93 into Hardy
[03:08] <StevenK> (And then backport it)
[03:08] <jdong> StevenK: http://jdong.mit.edu/~jdong/motu/transmission_0.93.dfsg-1.dsc <--- authentic jdong crack ready for Debian :)
[03:08] <jdong> StevenK: silly you for not suspecting jdong has fresh crack for everything ;-)
[03:08] <StevenK> jdong: Do you need a sponsor for that? What's left?
[03:09] <jdong> StevenK: I don't know how transmission manages themselves in Debian. I think they have a VCS... dunno who to contact
[03:09] <jdong> I'm pretty sure just uploading that will piss off the maintainers
[03:09] <StevenK> Right
[03:09] <bddebian> What else is new? :-)
[03:09] <minghua> http://packages.qa.debian.org/t/transmission.html says they use collab-maint SVN.
[03:09] <jdong> bug 155666
[03:10] <ubotu> Launchpad bug 155666 in compiz ""Desktop Cube" is geometrically inaccurate" [Undecided,Invalid] https://launchpad.net/bugs/155666
[03:10] <jdong> *grin*
[03:10] <minghua> So there is actually good chance you can just upload it (through correct procedures, of course).
[03:10] <StevenK> jdong: The Maintainer is Philipp Benner, you could mail him
[03:10] <Amaranth> jdong: Can you do an avant-window-navigator backport as soon as it gets in hardy? :)
[03:11] <jdong> Amaranth: I'd love to
[03:11] <Amaranth> jdong: I need one less reason for people to use broken crap from trevinho's repo
[03:11] <persia> jdong: That's a good bug, but upstream.  You've complained there as well?
[03:11]  * StevenK cackles at jdong's compiz bug
[03:11] <jdong> persia: haha , nah, a few grins is enough ;-)
[03:11] <jdong> StevenK: I'll poke him
[03:12] <persia> jdong: No, you've a valid point: it's worth following up: miseducation rarely is properly disabused.
[03:12] <jdong> hehe
[03:12] <jdong> if you're serious then I guess I could pursue it upstream :)
[03:12] <jdong> much to Amaranth's disbelief :)
[03:12] <bddebian> persia: Actually I think silvertree might actually "work"
[03:13] <persia> bddebian: Do you just stuff it with the base WML from the wiki?
[03:13] <bddebian> Gah kids, bbiam
[03:14] <StevenK> persia: Would you consider 'find $(CURIDR) -name 'Makefile' | xargs $(RM)' as makey enough?
[03:14]  * StevenK adds -print0
[03:15]  * persia doesn't understand why nobody seems to like "-exec $(RM) {} +".  It does the same thing in less memory.
[03:15]  * minghua wonders what are the translations for compiz's "cube"...
[03:15] <jdong> persia: people like one tool per job, and xargs is familiar, I guess
[03:16] <persia> StevenK: No: it's shell.  On the other hand, it's nearly a nice clean one-line shell call, and not worth complaining about.  There's a make function that generates that list, so you can do $(RM) $(function args) which is even cleaner, but I'd have to test the syntax.
[03:16] <StevenK> persia: Ah, but xargs will bundle up arguments, -exec {} \; doesn't
[03:16] <jdong> minimizing forking vs memory consumption... which is more important...
[03:17] <persia> jdong: Perhaps.  I think it's also that "-exec {} +" has only been around for a few years, and most people are still trying to avoid "-exec {} ;" which is ugly.
[03:17] <StevenK> Hum. Bugger.
[03:17] <StevenK> I need it to ignore ./Makefile, but delete every other
[03:17]  * minghua doesn't know about "-exec {} +".
[03:17] <jdong> I think StevenK needs to monitor free memory and forking speed in realtime and decide which one to use on the fly :)
[03:17] <jdong> *hides*
[03:17] <persia> jdong: That's the "-exec {} ;" vs. xargs argument.  "-exec {} +" wins, by being the best of both.
[03:17] <jdong> persia: what's the difference between + and ;?
[03:18] <jdong> persia: does + string the arguments together?
[03:18] <persia> jdong: + acts like xargs, inside find.  ; iterates.
[03:18] <StevenK> persia: I only know '-exec {} \;' is it '-exec {} \+' ?
[03:18] <jdong> persia: fascinating. Why didn't I get the memo on this sooner? :)
[03:18]  * persia wanders away, suggesting man pages.
[03:18] <persia> StevenK: Yes.
[03:18] <StevenK> persia: Danke, I shall use that
[03:20]  * minghua blames find(1) man page for putting "-exec {} ;" above "-exec {} +". :-P
[03:21] <StevenK> OH! -execdir!
[03:22]  * jdong looks at violating xserver-xgl's sanctity.
[03:24] <jdong> oh wait.
[03:24] <jdong> ## 01-compalloc-faster.dpatch by John Dong<EMAIL_ADDRESS>[03:24] <jdong> looks like I already did it earlier
[03:24] <jdong> when did I do that? :D
[03:24] <StevenK> Muahaha
[03:25] <jdong> look at me thinking one step ahead of myself.
[03:25] <jdong> just unfortunate it's my past self from 2 release cycles ago doing the foresight.
[03:25] <RAOF> jdong: *Ages* ago.  You were touching xgl well before me :)
[03:26] <RAOF> For Feisty, IIRC.
[03:26] <jdong>  -- John Dong<EMAIL_ADDRESS>Tue, 13 Mar 2007 10:35:24 -0400
[03:26] <jdong> yeah, while back
[03:27]  * jdong wonders what to violate next....
[03:28]  * LaserJock backs away slowly
[03:28] <StevenK> jdong: There's your answer. Violate LaserJock until he posts Ponies!
[03:29] <jdong> LaserJock: oh yeah speaking of d and f orbital hybridization....
[03:29] <jdong> (haha kidding. I'll do it myself this time :D)
[03:29] <LaserJock> jdong: phew, I thought you were going to start asking about HOMOs and LUMOs
[03:30] <jdong> LaserJock: fortunately this assignment is due on Wed, so disappear come 24 hours from now :)
[03:30] <LaserJock> np
[03:31]  * jdong goes stare at that avidemux package on REVU
[03:32] <jdong>  -- Matvey Kozhev<EMAIL_ADDRESS>Sat, 17 Nov 2007 10:49:54 +0600
[03:32] <jdong> LucidFox... sounds very familiar
[03:32] <jdong> I'll assume he's workin hard on it
[03:34]  * RAOF crosses deluge-torrent off his todo list.
[03:37] <jdong> RAOF: ooh shiny new deluge crack?
[03:42] <bddebian> @#$$%^ stupid piece of shit
[03:42] <jdong> ok, the PPA documentation is not very explicit....
[03:42] <RAOF> jdong: Shiny new deluge *sync*
[03:42] <jdong> so what distros can I target via PPA?
[03:42]  * jdong wants to move backports testing onto PPA
[03:42] <Hobbsee> jdong: anything supported.
[03:43] <jdong> is there any way to associate a bug to an upload to track build status?
[03:43] <jdong> without closing it, a la LP: #foo?
[03:44] <jdong> and thirdly, can PPA packages be removed?
[03:45] <RAOF> Not really
[03:47]  * jdong tries a PPA "backport" for fun and games :)
[03:47] <StevenK> jdong: You need to file an Answers request and then wait, if I recall
[03:47] <jdong> StevenK: heh well if it's a pain for them to do it on their end, I'd rather not make it a regular part of the process
[03:50] <jdong> do I always have to use -sa for the .changes or will it pick from even Hardy orig.tar.gz's for an upload at Gutsy?
[03:50] <RAOF> jdong: You mean to PPA?
[03:51] <jdong> right
[03:51] <RAOF> It won't pick up anything from the standard archives.    After that, python will feel good again.
[04:16] <imbrandon> heh
[04:17] <persia> Does anyone know what happened to the vague murmurings of syncing into the archive from PPAs?  Is that considered a bug that it doesn't work?  A feature because such syncs should never happen?
[04:18] <Hobbsee> er....i think that they might be able to do it now.
[04:18] <Hobbsee> unsure.
[04:18] <Hobbsee> the bug was solved, or almost solved.
[04:18] <persia> Hobbsee: So it's considered a bug if it doesn't work?
[04:19] <imbrandon> persia: yea they SHOULD be able to sync from any apt repo, from what they told me
[04:19] <imbrandon> last time i asked
[04:19] <imbrandon> now if they choose to sync from particular repo is diffrent
[04:19] <Hobbsee> persia: i think so.  it also affects partner
[04:20] <persia> Right.  Sounds like there is a mix of a couple bugs an unclear policy.  That's somewhat what I remembered, only in more detail.  Thanks.
[04:21] <Hobbsee> persia: you shouldnt expect better from soyuz :)
[04:22] <persia> Hobbsee: I expect soyuz to work perfectly, do everything I want, give me all the information I find interesting, and have eight nines uptime.  I may be disappointed once in a while, but if I expect less, it's just not fair to what it could be.
[04:22] <Hobbsee> heh
[04:22] <Hobbsee> well, this is true
[04:23] <StevenK> Eight nines? What's that, 5 seconds per year downtime?
[04:23] <Hobbsee> persia: in a few weeks, i'll probably be very interested to find otu what sort of info you'd find useful,e tc.
[04:23] <persia> StevenK: About that.  I've only heard of two shops reaching nine nines, and that was expensive, (mostly about geodistributing redundant servers), so I can't expect everything :)
[04:24] <persia> Hobbsee: My current wishlist is mostly in the QA list.  I could make some more, but I'lll have to stick that lower in the queue.  That timeframe sounds around right.
[04:24] <StevenK> I would have thought anything past six nines would be acceptable
[04:24] <Hobbsee> persia: mmm kay.  i'll poke you about it in a few weeks
[04:25] <persia> StevenK: Two 5 minute maintenance windows?  If the app can do that, no reason not to rotate things out live and go for higher numbers, but sure.
[04:28] <TheMuso> persia: Ok.
[04:58] <gnomefreak> anyone know a way to avoid the following error while taring up a dir tar: Error exit delayed from previous errors   im using tar -cvzf tarball dir, it worked for nss but fails on nspr and ff3.0
[05:00] <persia> gnomefreak: That just means tar is stuck from something else, try without the "v", and see if the errors are more informative.
[05:00] <Hobbsee> gnomefreak: have a look at what the previous errors were
[05:00] <gnomefreak> also worked for xulrunner
[05:00] <gnomefreak> Hobbsee: i didnt see them
[05:01] <gnomefreak> wait maybe i did because i used tar -cvvf to start with but failed to build because it complained it wasnt a gzip tarball
[05:02] <gnomefreak> tar: nspr-4.7.0~cvs20071106t1834/.pc/30_pkgconfig.patch/mozilla/nsprpub/config/nspr.pc.in: Cannot open: Permission denied
[05:02] <gnomefreak> without v
[05:02] <gnomefreak> maybe removing .pc dir will help?
[05:03] <persia> gnomefreak: There you go.  "v" is sometimes interesting, but it usually spews so much you can't tell what's going on.  If you really want to look, I'd suggest only using "v" with "t".
[05:03] <persia> or changing the permissions thereof.
[05:03] <gnomefreak> should .pc be in top level dir?
[05:05] <gnomefreak> ---------- 1 gnomefreak gnomefreak 0 Nov 19 20:02 nspr.pc.in
[05:05] <gnomefreak> it has no permissions how does that happen?
[05:06] <minghua> nice file.
[05:06] <minghua> :-)
[05:06] <gnomefreak> lol
[05:06] <gnomefreak> i guess removing .pc will help than building with -S -sa will add it if needed
[05:09] <nand`> dear MOTUs, I'm looking for a second advocate for the ike package please. Thanks! ( http://revu.ubuntuwire.com/details.py?package=ike )
[05:21] <jdong> LucidFox: ah thought that name was familiar, thanks for taking on the avidemux merge :)
[05:22] <jdong> LucidFox: one favor, I recently merged a new x264 into Hardy, can you version your libx264-dev build-dep (>= 1:0.svn20070930) so we make sure to build against that new version?
[05:40] <LucidFox> jdong> sure
[05:43] <Fujitsu> keescook: Thanks for that rather large number of security uploads!
[05:44] <Fujitsu> emgent: That gallery2/reupload diff you attached isn't particularly useful - the WebDAV CVEs also need to be fixed, and it includes a lot of extra changes.
[05:52] <LucidFox> jdong> uploaded
[05:52] <LucidFox> I can't test-build avidemux right now with the new x264, though, so I can't guarantee if the new upload will build
[05:52] <LucidFox> http://revu.tauware.de/details.py?package=avidemux
[05:54] <persia> LucidFox: Is that a new upstream pull?  If so would you mind knocking out the lintian messages?
[05:55] <LucidFox> persia> I knocked out all lintian messages I could find
[05:56] <LucidFox> the only one remaining is "no manpage for binary avidemux" in the transitional package avidemux, but it depends on avidemux-common, which provides the manpage
[05:57] <persia> LucidFox: There are a couple more in the URL you just posted: outdated autotools hint files which can cause FTBFS, and broken releationships (which don't really matter in Ubuntu anyway).
[05:57] <LucidFox> Autotools aren't used
[05:57] <LucidFox> In 2.4, upstream provides a choice between autotools and CMake, and my packages use the latter
[05:57] <persia> LucidFox: OK.  Strange to see config.{sub,guess} if they aren't used.  Nevermind.
[05:58] <persia> Right.  That explains it.  Nevermind :)
[06:04] <jdong> LucidFox: if you are otherwise ready and not gonna make major packaging changes, I'd be glad to test locally whether they FTBFS or not for you :)
[06:04] <jdong> LucidFox: thanks for your work on avidemux :)
[06:05] <LucidFox> Why does the new x264 build-depend on GTK?
[06:06] <jdong> LucidFox: there is some graphical x264 frontend thingie that's now in the x264 binary package
[06:06] <jdong> christian marillat's decision :)
[06:06] <LucidFox> ah
[06:12] <LucidFox> okay, I'm now building Avidemux with the new x264
[06:13] <jdong> LucidFox: fantastic, good luck ;-)
[06:13] <jdong> LucidFox: I provide no guarantees they are API compatible; if you have more than trivial struggles with it poke me and I'll take a look
[06:15] <frenchy> Hi RAOF ... Sorry back now.
[06:17] <RAOF> frenchy: That's OK.
[06:20] <frenchy> RAOF: So, are you a MOTU?  It's really hard finding a MOTU with a DVB card.
[06:21] <RAOF> Yeah, I am.
[06:22] <frenchy> RAOF: Woo-Hoo!
[06:22] <RAOF> Although for most of the review process you won't need a MOTU with a dvb card.
[06:22] <RAOF> Much of the packaging stuff can be done without testing the app itself.
[06:23] <StevenK> jdong: So does an amd64 .deb of transmission 0.93 exist anywhere? :-)
[06:24] <frenchy> RAOF: but you really can't run the application without a DVB card.  Also, from a previous question I asked, MOTUs are actually meant to test the application as well.
[06:24] <jdong> StevenK: build it in a pbuilder, you're a developer :)
[06:24] <StevenK> jdong: I'd rather someone else did the work. :-P
[06:24] <jdong> haha
[06:24] <frenchy> RAOF: I doubt that I'm going to get many advocates when people can't start the application.
[06:24] <jdong> oh look at StevenK with his fancy fast 64-bit computer making others build for him ;-)
[06:25] <StevenK> I can't build, ktorrent takes all of my CPU. :-P
[06:25] <RAOF> frenchy: Yeah.
[06:25] <persia> frenchy: No, but you'll get packaging comments, and when the packaging is perfect, then you need advocates.  If you get your DVB people now, you may have trouble getting them again later.
[06:25] <persia> (although it is REVU day, so people should REVU)
[06:25] <RAOF> jdong: You can throw a source package at me if you like.
[06:26] <jdong> RAOF: I've already thrown one at StevenK ; http://jdong.mit.edu/~jdong/motu/transmission_0.93.dfsg-1.dsc
[06:26] <frenchy> persia: Hi again, I think that I'm all shibby with the packaging now.
[06:27]  * persia prepares a pastebin...
[06:27] <frenchy> persia: what TZ are you in?  You're on 24/7/
[06:28] <persia> frenchy: No, actually, I'm on at random times: you just get lucky (UTC+9)
[06:29] <persia> !info liibxine-ffmpeg
[06:29] <ubotu> Package liibxine-ffmpeg does not exist in gutsy
[06:29] <persia> !info libxine1-ffmpeg
[06:29] <ubotu> libxine1-ffmpeg: mpeg related plugins for libxine1. In component universe, is optional. Version 1.1.7-1ubuntu1 (gutsy), package size 435 kB, installed size 908 kB
[06:29] <frenchy> persia: After googling pastbin ... was that comment meant for me?
[06:29] <LucidFox> jdong> the new Avidemux successfully built with the new x264
[06:30] <persia> frenchy: Not yet: let me build a list first...
[06:30] <jdong> LucidFox: fantastic.
[06:30] <frenchy> persia: Sorry .. a list of what? ... issues?
[06:31] <persia> Yep.
[06:31] <frenchy> persia: Let me grab the hammer and duct tape.
[06:31] <frenchy> Frenchy likes to fix.
[06:32]  * Fujitsu wonders what the release policy for ubuntu-dev-tools is.
[06:33] <StevenK> There's a policy?
[06:34] <RAOF> jdong: Does the transmission deb want to contain something more than the changelog?
[06:35] <jdong> RAOF: huh?
[06:35] <RAOF> jdong: I've just built transmission, and the arch-all package contains just /usr/share/doc/transmission/{changelog, README, etc}
[06:35] <jdong> RAOF: transmission-{gtk,curses}
[06:36] <jdong> trnamission is metapackage
[06:36] <RAOF> Aaaah.
[06:36] <frenchy> persia: What I don't understand is that I've seen other packages in universe that are in a lot worst state than mine.  klear doesn't even have GPL headers.    If you want to clean one, nobody will complain.  We just don't want more ugly ones :)
[06:41] <LaserJock> hi highvoltage
[06:41] <frenchy> persia: Can I respond to your comments here?
[06:41] <persia> frenchy: Sure.
[06:42]  * jdong resyncs gtkpod-aac with latest debian release :)
[06:42] <frenchy> Why xine frontend?
[06:42] <Fujitsu> jdong: Shouldn't it be in sync with our gtkpod?
[06:43] <jdong> Fujitsu: it was 2 debian versions behind, debian separated out their patches into dpatches too like us, and added one bugfix patch
[06:43] <jdong> StevenK last resynced against -2 in Debian, I brought it up to -4
[06:43] <RAOF> StevenK: amd64, hardy.
[06:44] <StevenK> RAOF: Gah.  My father is always complaining about it.
[06:48] <LaserJock> turns out I was averaging 9 data points instead of 10
[06:48] <frenchy> persia: debian/copyright ... just the last two lines?  Are they the only extraneous parts?
[06:49] <LaserJock> Fujitsu: it works really well if you know how to use it well
[06:49] <LaserJock> I'm just not that great with it
[06:49] <jdong> http://paste.ubuntu-nl.org/45201/
[06:49] <persia> frenchy: I think so: check http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[06:49] <jdong> can someone look at that diff for me?
[06:50] <jdong> debian made some changes to the .desktop file and I'm not sure which ones to keep
[06:50] <jdong> "  * Adapted .desktop file to current freedesktop standards.
[06:50] <Fujitsu> jdong: Those changes are both correct.
[06:50] <LaserJock> jdong: yeah, that's ok
[06:50] <jdong> Fujitsu: ok, will apply
[06:50] <jdong> thanks :)
[06:50] <persia> jdong: Encoding and Application are deprecated.  I don't see much value for GTK as a caegory: that's more an OnlyShowin thing
[06:51] <persia> jdong: Also, drop the .png on the icon
[06:51] <jdong> persia: ah, ok
[06:51] <jdong> persia: drop the .png extension?
[06:51] <jdong> persia: will the icon be found correctly?
[06:51] <LaserJock> jdong: it's smart :-)
[06:51] <persia> unless you could otherwise sync (and yes, if it is in the icon cache)
[06:51] <jdong> LaserJock: haha, ok :)
[06:53] <RAOF> StevenK: www.cooperteam.net/transmission-gtk_0.93.dfsg-1_amd64.deb and stuff?
[06:53] <persia> jdong: Don't forget dh_desktop and dh_icons
[06:54] <minghua> Does Ubuntu's dh_desktop do anything special other than updating MIME database these days?
[06:54] <StevenK> RAOF: Yay!
[06:54] <jdong> persia: is removing Homepage: from the description field and replacing it by a Homepage: tag correct for Hardy?
[06:55] <Fujitsu> jdong: Sorta. We don't have the right dpkg yet, IIRC>
[06:55] <persia> minghua: No, and it's not likely to diverge from Debian.  The only Ubuntu developer hacking it is pushing things in Debian first.
[06:55] <persia> jdong: Yes.
[06:55] <persia> Fujitsu: A merge is planned RSN :)
[06:56] <persia> (plus we need to schedule an update to packages.ubuntu.com, etc.)
[06:56] <StevenK> RAOF: $beers_owed++;
[06:57] <RAOF> StevenK: Surely $beers_owed--; :)
[06:58] <StevenK> RAOF: It's a note that I owe you another :-)
[06:59] <minghua> Don't we need the correct dpkg first before using Homepage: field?
[07:00] <persia> minghua: We're already syncing heaps of packages that use the Homepage field.  Trying to manage that is just too painful.  We'll get a few warnings, and then it gets fixed.
[07:01] <Fujitsu> Thankyou Launchpad:
[07:01] <Fujitsu> Accepted: mplayer, mplayer, mplayer, mplayer, mplayer, mplayer
[07:01] <Fujitsu> How understandable.
[07:01] <persia> heh
[07:01] <jdong> Fujitsu: haha
[07:01] <TheMuso> heh
[07:01] <jdong> persia: is dh_icons + dropping .png applicable to Debian too? shall I push that upstream?
[07:02] <StevenK> jdong: dh_icons is
[07:02] <minghua> persia: I was thinking that without the new dpkg, the generated control files may be lacking fields or something, but probably that's not the case, or it doesn't matter.
[07:02] <LaserJock> jdong: you should be able to push the drop of .png as well I think
[07:02] <persia> jdong: dh_icons is, but Debian supports more window managers, and I'm not sure they are all freedesktop compliant.  I usually push it, and it gets adopted > 50%.
[07:03] <jdong> persia: ok, thanks, I'll give it a shot
[07:03] <persia> minghua: It would be too much work to matter, and it shouldn't break anyway: Debian can't expect to rebuild everything for lenny.
[07:04] <minghua> persia: Huh?  How is rebuilding lenny relevant to the topic at hand?
[07:06] <persia> minghua: The dpkg transition will have been started in such a way as not to break.  This is especially true as > 5% of Debian was using Homepage: as a full header before there was dpkg support.  This is partly because of how Debian operates.  Because they are so good, we don't need to be quite as careful to manage these things (usually).
[07:06]  * jdong figures out how StevenK did this gtkpod-aac.diff thing without self-recursing :D
[07:06] <persia> If the dpkg / Homepage transition was hard, every "complaint" package would need a rebuild for Lenny, which would make someone very happy with mass-bug.
[07:07] <persia> s/complaint/compliant/
[07:09] <minghua> persia: Hmm.  I didn't know people started using Homepage field before dpkg supported it.
[07:09] <LucidFox> by the way, jdong, since you seem to be interested with iPod videos
[07:09] <persia> minghua: Yep.  Read debian-policy@ archives or policy / dpkg bugs sometimes.  It's always entertaining.
[07:10] <jdong> LucidFox: owner of one, trying to make things easier for fellow owners
[07:10] <LucidFox> I just converted a video with Avidemux's iPod profile, processed with MP4Box -ipod and uploaded with gtkpod, and it played perfectly
[07:10] <jdong> LucidFox: the types of video formats that they take is not trivially obvious to deduce or produce
[07:10] <jdong> LucidFox: that's great to hear
[07:10] <jdong> LucidFox: what video codec do they use?
[07:14] <minghua> persia: Err... I think I'll pass.  I have better ways to kill time. :-)
[07:14] <frenchy> persia: my code is on LP, not a browse-able FS ... I don't think that the watch file will work.
[07:15] <persia> frenchy: Read about uscan's screen-scraping functionality (man uscan)
[07:16] <persia> frenchy: As long as you can identify a stable page, and a regex to match the link, you're all set.
[07:22] <LucidFox> jdong> Avidemux uses Xvid
[07:23] <jdong> LucidFox: oh that's disappointing
[07:23] <LucidFox> by default, 320*240, 400 kbps, no B-frames
[07:23] <LucidFox> but I changed the resize filter to 640*480 and it still played
[07:23] <jdong> LucidFox: meh xvid profiles are boring, I want to see them vindicate their manhood by doing an H.264 baseline no-complexity profile
[07:24] <jdong> LucidFox: the iPod will accept XVid 640x480@~2000kbit with no or 1 B-frame
[07:24] <jdong> (don't ask. trial and error.)
[07:25] <frenchy> persia: Where can I find info on the current file formats?  I'm using http://www.debian.org/doc/maint-guide and I think that its version of the menu file might be old, I think.
[07:25] <RAOF> Anyone want to be a second advocate of avant-window-naviator?
[07:25] <persia> frenchy: /usr/share/doc/menu/menu.txt.gz on a gutsy, hardy, lenny, or sid system ought have it.
[07:28] <jdong> whee gtkpod-aac resynced & uploaded; thanks persia Fujitsu LaserRock_70s for your guidance :D
[07:28] <persia> frenchy: You might also want to run linda and lintian (preferably hardy versions) on your binary changes file.
[07:31] <frenchy> persia: I didn't even have menu, linda or lintian installed.  Shows how much I know about this whole process.
[07:32] <jdong>   xmms-dev: Depends: xmms (= 1:1.2.10+20070601-1) but it is not going to be installed
[07:32] <jdong> hmm that's an odd failure in hardy, *investigates*
[07:33] <persia> jdong: buildd skew?  NBS change?
[07:34] <jdong> persia: yeah gonna look in a hardy pbuilder to see if I can reproduce
[07:34] <persia> jdong: You might find it faster to check the buildd queue and NBS list.
[07:35] <jdong> persia: what's a NBS list?
[07:36] <persia> jdong: Top canonical link on http://qa.ubuntuwire.com/ : packages that oughtn't exist anymore as the source builds something else now.
[07:36] <persia> (but, since they have rdepends, the rdepends need porting to remove the package)
[07:38] <jdong> persia: yeah it's libglib1.2 on that list, xmms depends on it but it's changed names
[07:38] <TheMuso> jdong: Do you ever sleep?
[07:39] <Nafallo> :-)
[07:39] <jdong> persia: is uploading a rebuild of xmms enough?
[07:39] <Nafallo> morning
[07:39] <jdong> TheMuso: hehe I should be asleep right now!
[07:39] <TheMuso> jdong: I thought as much.
[07:39] <TheMuso> I honestly don't know how you people manage to stay up so late.
[07:40] <jdong> TheMuso: simple. we suck at waking up the next day.
[07:40] <TheMuso> heh
[07:40] <persia> jdong: No idea: I haven't looked at the issue.  You'll want to check https://launchpad.net/ubuntu/hardy/+queue, and the buildds, and the NBS list, and rdepends of things.  Sometimes a rebuild fixes it, but usually changing something else lets them all fall together.
[07:40] <TheMuso> I'm quite the opposite. I'm a morning person.
[07:41] <lifeless> which TZ though
[07:41] <TheMuso> Morning Australia/Sydney.
[07:44] <LaserRock_70s> TheMuso: I'm a morning in Australia/Sydney person too
[07:45] <TheMuso> Heh if you want to put it that way. :p
[07:46] <jdong> persia: hmm gonna try a rebuild locally to see if it does any good
[07:46] <jdong> and go to bed while that builds
[07:46] <persia> jdong: OK.  I suspect it's because of a conflict related to xmms-crossfade, rather than xmms itself, but that might work.
[07:48] <jdong> persia: no, it's xmms I'm fairly certain. It tries to install libglib1, which is a transition package, which tries to install the new pkgname, which conflicts with libglib1
[07:48] <frenchy> persia: how do I supply source for graphics?
[07:48] <jdong> I'm pretty sure if we build again we'll hit the correct libglib package name and break the cycle
[07:48] <persia> jdong: In that case, it's not xmms, it's all the other reverse dependencies of libglib1 :)
[07:49] <jdong> persia: I think it's supposed to happen though because the ABI of the glib changed
[07:50] <persia> frenchy: .fig, .svg, .xpm, and I'm sure there are others.  That's one of the least important items, as most people don't really mind editing .pngs.  If you have a large format you're shinking to make the icon, that's a nice target as well.
[07:50] <persia> jdong: Yep.  If you're feeling motivated tomorrow, and want to push a rebuild of them all the problem would go away :)
[07:50] <jdong> persia: O_O :D
[07:51] <pkern> What's up with r-core-*?
[07:51] <persia> pkern: A little more info might be helpful...
[07:51] <pkern> Apart from a missing newer ocaml I had quite some rebuild failures with r-core-* and old glib stuff...
[07:51] <jdong> persia: are rebuilds automated/scripted or done by hand?
[07:51] <pkern>
[07:51] <pkern>   r-base-core: Depends: tk8.4 (>= 8.4.16-2) but it is not installable
[07:52] <persia> jdong: By hand.  We upload new revs (-Xbuild1 if no other changes) with a changelog entry explaining why.  If we can hit another couple bugs along the way, it looks nicer.
[07:52] <jdong> persia: ah, ok :)
[07:52] <persia> pkern: Might have something to do with tk8.5?
[07:53] <pkern> Hm.
[07:53] <codemaste1> hi
[07:53] <codemaste1> how can I remove a package that I submitted?
[07:54] <persia> codemaste1: To where did you submit it?
[07:54] <minghua> persia: Shouldn't be.  Surely tk8.3, tk8.4, tk8.5 are parallel installable?
[07:54] <jdong> persia: ok, I'll push thru xmms tonight so it stops blocking faad2 and the entire new media stack, and tomorrow I'll look at the other million packages on the list :D
[07:55] <pkern> persia: Missing merge of new tk8.4?
[07:55] <persia> minghua: Right, but perhaps the R maintainers are using the latest tk, and only half the suite has been rebuilt.
[07:55] <persia> pkern: That might do it as well.
[07:55] <TheMuso> jdong: I've been meaning to join the MOTU media team. Where is help needed?
[07:55] <TheMuso> As I'll probably be able to knock some stuff over tonight.
[07:55] <persia> jdong: I thought there were only about 300.    Who cares about xmms. :p
[07:56] <persia> TheMuso: There's a bit of the xine-lib transition outstanding, if you like.
[07:56] <TheMuso> persia: Is that just rebuilds?
[07:57] <persia> TheMuso: and adding a front-end dependency.
[07:57] <TheMuso> Which front-end?
[07:57] <Fujitsu> TheMuso: Upstream's not dead!
[07:57] <Fujitsu> It still releases once every 1112 days.
[07:57] <TheMuso> Fujitsu: I know.
[07:57] <jdong> ok *now* seriously, bed for me!
[07:57] <Fujitsu> jdong: Famous last words.
[07:57] <Fujitsu> jdong: Night.
[07:57] <jdong> night!
[07:57] <persia> TheMuso: https://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002617.html
[07:58] <TheMuso> persia: ok thanks. Will have a look a little later.
[07:58] <persia> TheMuso: No rush, just the only MOTUmedia think I had in mind :)
[07:58] <TheMuso> persia: Ok.
[07:59]  * TheMuso is still undecided as to what to do re the query I raised in -devel last night.
[07:59] <Fujitsu> TheMuso: Which?
[07:59] <TheMuso> Fujitsu: Fun with .la files, and a package build not seeing that a .la file was moved from /lib to /usr/lib
[07:59] <Fujitsu> Ah.
[08:00] <TheMuso> And the incorrect location is listed in the dependency_libs field, which causes a frontend package for the main package in question to FTBFS.
[08:00] <Fujitsu> Fun.
[08:00]  * pkern hopes that his lappy arrives today... or tomorrow... or the day after...
[08:00] <TheMuso> Fujitsu: Oh yeah. Just what I'd call fun. :p
[08:01] <LaserRock_70s> dang it I hate OO Impress
[08:01] <Fujitsu> LaserRock_70s: What's with the nick?
[08:01] <StevenK> Fujitsu: Read Planet
[08:01] <LaserRock_70s> Fujitsu: see Planet
[08:01]  * Fujitsu does so.
[08:01] <StevenK> Hah
[08:01] <Fujitsu> Aha.
[08:01] <geser> Fujitsu: have you seen that WP has a new security hole?
[08:02] <Fujitsu> It was read for some reason - Liferea doesn't like vanishing regularly.
[08:02] <Fujitsu> geser: Really? That makes 43.
[08:02] <siretart> TheMuso: you're interested in MOTUmedia?
[08:02] <geser> Fujitsu: http://www.securityfocus.com/archive/1/483927
[08:02] <Fujitsu> geser: I'll start rolling up updates for Feisty/Gutsy tonight, and the others at some point.
[08:02] <TheMuso> siretart: I think we talked about it at UDS, yes I am, and I have been meaning to join.
[08:03] <siretart> TheMuso: aah, then you've heared the discussions crimsun and I had about the team, did you?
[08:03] <Fujitsu> geser: Thanks, I'll add that to The Bug.
[08:03] <TheMuso> siretart: I think so, but if I did, I can't remember them. :p
[08:04] <Fujitsu> Ah, not even a CVE yet, which is why I haven't seen it.
[08:04] <siretart> TheMuso: we were wondering if the team was worth to have, since there isn't too much action going on there
[08:04] <TheMuso> siretart: Thats right, I remember now.
[08:04] <siretart> TheMuso: we decided to keep it for 2 reasons: grouping bug reports of multimedia related packages and PPAs
[08:04] <LaserRock_70s> Fujitsu: LWN.net had it in the RSS today
[08:04] <minghua> Is patch available for the wordpress bug now?
[08:04] <dholbach> good morning
[08:04]  * minghua checks.
[08:04] <dholbach> LaserRock_70s: ROCK!
[08:04] <LaserRock_70s> morning dholbach
[08:05] <dholbach> how are you guys doing? :-)
[08:05]  * Fujitsu checks how many WordPress CVEs affect Gutsy.
[08:05] <TheMuso> dholbach: Greetings.
[08:05] <Fujitsu> Hi dholbach.
[08:05] <siretart> TheMuso: well, I assume that you want to use the PPA, right?
[08:05] <TheMuso> siretart: Right.
[08:05] <siretart> TheMuso: welcome on board then! :)
[08:05] <TheMuso> siretart: The PPA was the last thing on my mind actually.
[08:05] <minghua> Still no patch in sight.
[08:06] <siretart> k
[08:06] <Fujitsu> minghua: Great...
[08:06] <minghua> I wonder how Fujitsu is going to roll up updates...
[08:06] <geser> Fujitsu: it will become CVE-2007-6013
[08:07] <Fujitsu> geser: Where did you get the reference?
[08:07] <Fujitsu> minghua: Well, I'll prepare the other 9 CVEs for Feisty and 1 for Hardy, and throw the new one in when I see a patch.
[08:08] <geser> Fujitsu: from http://www.cl.cam.ac.uk/~sjm217/advisories/wordpress-cookie-auth.txt
[08:08] <LaserRock_70s> it'd be nice if we had a good way of letting users see that we've got these kinds of fixes in
[08:08] <minghua> Fujitsu: Nice.  I am just happy I have nothing to do with wordpress.
[08:08] <LaserRock_70s> I think they tend to just look at the version
[08:08] <Fujitsu> geser: Right, I see it on Mitre now too.
[08:09] <persia> Don't we have a security notification feed?
[08:09] <Fujitsu> persia: Only for amin.
[08:09] <Fujitsu> s/amin/main/
[08:09] <Fujitsu> We need universe-security-announce or so once we actually have some reasonable support.
[08:09] <persia> Right.  What does it take to add an RSS feed somewhere and populate it for universe?
[08:10] <Fujitsu> persia: We'd need a somewhere.
[08:10] <persia> Ah.  "reasonable support".  That goes back to needing a security / updates team, no?
[08:10] <TheMuso> siretart: Thanks.
[08:10] <persia> Fujitsu: Maybe we could ask ubuntuwire
[08:10] <Fujitsu> persia: Perhaps.
[08:10] <Fujitsu> persia: We have a security team, but it seems to only consist of \sh and myself...
[08:11] <persia> Fujitsu: I thought there was going to be marketing & announcements & stuff.  How many people do you want?
[08:11] <Fujitsu> And we have literally a thousand CVEs to go through.
[08:11] <Fujitsu> persia: I might actually get around to writing an announcement to -motu tonight.
[08:12] <persia> Fujitsu: OK.  If you've 1000 issues, I'm guessing you need 6-10 relatively active people?
[08:12] <Fujitsu> persia: Right, but that's not going to happen.
[08:12] <LaserRock> Fujitsu: it's not?
[08:12] <LaserRock> you might be surprised if you market it
[08:13] <frenchy> persia: With the funny libxine thing, does that mean that I'll have to maintain 2 versions of the control file now?
[08:13] <Fujitsu> We can't pull much of several people's time out of the dev. release.
[08:13] <persia> Fujitsu: I think 4 should be easy, and maybe 5.  Clearing the backlog will be painful, but maybe keeping up will be possible.  Due to the excitement of announcements, you might even have 7 or so for a few weeks.
[08:13] <persia> frenchy: How do you mean?
[08:13] <Fujitsu> persia: Keeping up should be practical eventually
[08:14] <frenchy> persia: Well there's no libxine1-x in Gutsy.
[08:14] <LaserRock> Fujitsu: well, I think many people care about security, they just don't know what exactly needs to be done and how to do it
[08:14] <LaserRock> a nice task list and some documentation would probably go a long ways
[08:14] <frenchy> persia: So I need a control file for gutsy and a control file for Hardy with libxine1-x.
[08:14] <persia> frenchy: Ah, yes.  You'll want a slightly different package for gutsy than for hardy.  Alternately, use a versioned OR for stability (see the Debian bug).
[08:14] <Fujitsu> LaserRock: True. It looks like ubuntu-cve will be developed further soon, which will help.
[08:41] <gaspa> persia: bip. ;)
[08:41] <gaspa> do you know exactly what doesn't work with clive and python2.5?
[08:42] <persia> gaspa: I think it just didn't run.  I don't remember why.  Let me check if I left a useful note.
[08:42] <gaspa> persia: the bug report tells simply that "it doesnt' work"
[08:42] <gaspa> because the new version seems to work, at a first sight
[08:43] <gaspa> (python2.5, of course)
[08:43] <SWAT> when I build a package named package_0.08-0 the source gets included. If I use package_0.08-0ubuntu1 instead, I get: "dpkg-genchanges: not including original source code in upload". Since I build this package from scratch for Ubuntu, I would like to include the source. Any tips?
[08:44] <persia> gaspa: Excellent.  I don't appear to have left any good notes, but the upstream changelog looks promising.  If it runs for you in hardy, and can play YouTube and GoogleVideo, you can request a sync.
[08:45] <persia> SWAT: debuild -S -sa
[08:46] <gaspa> persia: great. I test it a little more...
[08:46] <persia> gaspa: Thanks for looking into that.
[08:46] <gaspa> persia: ;)
[08:46] <SWAT> persia, thanks again.
[08:47] <soren> nealmcb: I've not yet reached a verdict :)
[08:51] <dholbach> http://wiki.ubuntu.com/MOTU/ReportingPage looks awesome this month
[08:51] <dholbach> lots of activity
[09:27] <huats> morning dear MOTUs and wanabees :)
[09:27] <dholbach> heya huats
[09:28] <huats> hey dholbach
[09:28] <huats> dholbach: I was looking at dad yesterday. Do you min if I look at the jokosher merge ?
[09:29] <dholbach> huats: not at all, not even if you replace my name in the maintainer field - the only problem is that the tarballs differ
[09:29] <dholbach> huats: let me know once you've done something, I'll review it for you
[09:30] <huats> dholbach: I didn't went inside to have a look. I just saw that you were the last uploaders
[09:30] <huats> dholbach: I'll have a look tonight
[09:30] <huats> and I let you know
[09:30] <dholbach> rock and roll
[09:31] <huats> :)
[09:36] <gaspa> persia: do you think it's enough? (bug #164021)
[09:36] <ubotu> Launchpad bug 164021 in clive "sync version 0.3.1-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/164021
[09:37] <gaspa> also with a build log.
[09:38] <persia> gaspa: You'll want to change the title to note that clive is going into (universe) from (main).  Take a look at some of the bugs in https://bugs.launchpad.net/~ubuntu-archive for an example
[09:39] <persia> gaspa: You'll want to mention which version of clive didn't work with python2.5 in gutsy.
[09:39] <gaspa> ah, ok
[09:39] <persia> gaspa: And you'll want to include the Debian changelog since the last sync in the description as well.
[09:41] <persia> gaspa: Other than that, it looks good.  Please push to the sponsors queue when you make those changes: I won't sponsor (as it's mine), but I doubt it'll take more than a few hours.
[09:45] <Fujitsu> Has anybody else seen any security uploads announced to -changes since 2007/10/23 (ie. just before LP 1.1.10)?
[09:48] <geser> I don't remember seeing any
[09:48] <Fujitsu> I can't see any on any of them, in the past month, when there are normally lots... Oh dear.
[09:48] <gaspa> persia: thanks. :D
[09:51] <s1024kb> \sh_away: hi
[09:55] <s1024kb> luisbg_: hi
[09:55] <geser> Hi s1024kb
[09:57] <s1024kb> geser: hi. do you use jabber?
[09:58] <luisbg_> hey s1024kb, how are you?
[09:58] <luisbg_> and hello to the rest of the room also ;)
[09:59] <s1024kb> luisbg_: hey, fine, thanks. i uploaded my first package "yappy" today finally...
[10:00] <luisbg_> s1024kb, cool! my congrats
[10:01] <geser> s1024kb: yes, why?
[10:02] <s1024kb> geser: it was the first time i use jabber (\sh suggested yesterday), and i added you guys... :-)
[10:02] <s1024kb> luisbg_: thanks.
[10:04] <effie_jayx> Quick question guys... I am currentlyworkning on a real update... all updates should be hardy obviously right?
[10:04] <geser> s1024kb: I have seen your authorization request now, and acked it
[10:04] <effie_jayx> dch -i creates an entry with gutsy in the new version... but hardy is the next release
[10:05] <effie_jayx> but would it build ?
[10:05] <Fujitsu> effie_jayx: That's because you're using Gutsy's dch.
[10:05] <Fujitsu> hardy is correct.
[10:05] <geser> effie_jayx: yes, all updates (except SRU obviously) should target hardy
[10:05] <effie_jayx> now
[10:05] <effie_jayx> would it build ?
[10:06] <geser> effie_jayx: either install devscripts from hardy, update the distribution by hand or set an alias
[10:06] <pwnguin> effie_jayx: is your pbuilder hardy or gutsy?
[10:07] <effie_jayx> pwnguin,  gutsy
[10:07] <geser> effie_jayx: for a pbuilder the distribution in the changelog doesn't matter
[10:07] <s1024kb> geser: haha, sorry, i changed to a new account... and added you again. :-)
[10:07] <effie_jayx> I remember downloading pbuilder for gusty before...
[10:08] <effie_jayx> I can't quite remember
[10:08] <pwnguin> effie_jayx: apparently it doesnt matter
[10:08] <effie_jayx> ok
[10:08] <effie_jayx> I shall try it
[10:09] <pwnguin> it should build and test fine, but MOTU is now at the stage where only stable release updates are accepted into gutsy. ideally you'd be setting up a hardy pbuilder and testing on a hardy install
[10:10] <effie_jayx> pwnguin,  any leads as into how to build my hardy pbuilder
[10:10] <pwnguin> the wiki has a section on keeping multiple chroots around, ive not set it up
[10:10] <effie_jayx> ok
[10:11] <pwnguin> i just upgraded to hardy like an hour ago
[10:11] <geser> pwnguin: how much is broken currently?
[10:11] <pwnguin> nvidia's totally busted
[10:11] <pwnguin> i havent looked into it yet
[10:11] <geser> effie_jayx: look at the pbuilder-dist script from ubuntu-dev-tools
[10:11] <pwnguin> otherwise, it basically is a lot like gutsy
[10:12] <pwnguin> not much happened during the freeze i guess
[10:13] <effie_jayx> geser,  I will check it know ... I am at that very step now...
[10:13] <pwnguin> oh, i guess i do tend to throw things into my ppa when they wont make it into official relases on time
[10:13] <pwnguin> so theres a few new toys like CellWriter.
[10:13] <geser> effie_jayx: you need to debootstrap from gutsy-backports or hardy to create a hardy pbuilder
[10:13] <geser> need to install *
[10:13] <pwnguin> geser: apparently the gdm failsafe is not quite ready
[10:15] <s1024kb> luisbg_: do you have a jabber account?
[10:15] <luisbg_> s1024kb, yes<EMAIL_ADDRESS>[10:16] <s1024kb> luisbg_: add you too. :-)
[10:17] <luisbg_> s1024kb, ok!
[10:23] <pwnguin> geser: i take that back. gdm just decided to go nuts on reboot
[10:29] <effie_jayx> another question... if this is a new upstreeam version
[10:29] <effie_jayx> the name  is 3ubuntu1
[10:30] <effie_jayx> what would the new name be?
[10:32] <geser> effie_jayx: -EPARSE, do you want to upgrade an existing package to the next upstream version?
[10:32] <effie_jayx> geser,  yes, that's right
[10:33] <geser> -0ubuntu1 as there isn't a Debian release for this version yet
[10:34] <effie_jayx> ok
[10:34] <effie_jayx> thanks geser
[10:39] <effie_jayx> heh
[10:39] <effie_jayx> package doesn't build
[10:39] <effie_jayx> lot's of warnings and the there is an error
[10:45] <geser> Hi norsetto
[10:46] <norsetto> heya geser, how is it?
[10:46] <dholbach> hey norsetto!
[10:46] <norsetto> dholbach: morning master!
[10:46] <geser> norsetto: good, but I got a cold :(
[10:46]  * dholbach hugs norsetto
[10:46]  * dholbach hugs geser too
[10:46]  * dholbach makes some tea
[10:46]  * geser hugs dholbach back
[10:46]  * norsetto hugs dholbach and geser (and get a cold in so doing :-))
[10:47] <effie_jayx> so if I get an error building and it seems to be a code problem
[10:47] <effie_jayx> a variable not declared it seems
[10:47] <geser> fix it :)
[10:48] <norsetto> geser: fix id ;-)
[10:48] <effie_jayx> geser,  ok
[10:51] <effie_jayx> geser,  the error is this ... 'ctx' undeclared (first use in this function)
[10:52] <effie_jayx> could it be that I am missing some dependency?
[10:53]  * effie_jayx check the depends line
[10:56] <effie_jayx> geser,  build depends on libclamav-dev
[10:56]  * effie_jayx has found the glitch
[10:59]  * proppy hugs dholbach
[10:59]  * dholbach hugs proppy back
[10:59]  * proppy hugs the big N
[10:59] <proppy> (norsetto)
[11:01] <s1024kb> norsetto: hello my teacher. i had uploaded the package... will be concentrate to the next one.
[11:01] <norsetto> heya proppy!
[11:01] <s1024kb> proppy: hi, nice to meet you again.
[11:01] <norsetto> s1024kb: ok good, you have subscribed the sponsors?
[11:02] <effie_jayx> nope that eas not it
[11:02] <s1024kb> norsetto: yes.
[11:02] <effie_jayx> http://pastebin.ubuntu-nl.org/45215/ <---- here is the output if anyone can help me identify
[11:03] <effie_jayx> there must be a problem with a library and vairables not being read
[11:03] <norsetto> s1024kb: hmmmm, can you give me the bug number?
[11:03] <s1024kb> norsetto: maybe there will be errors inside it, but i wish to learn from the errors... Wish to work better next time.
[11:03] <s1024kb> norsetto: ...
[11:05] <s1024kb> norsetto: the bug number? (sorry, i know that my English is really bad, after thinking for quite a while...)
[11:05] <persia> effie_jayx: The only problem worth looking at for a start is the one on line 145.  If you can track down why it's not finding those libraries (missing build-dependency?, source structural changes?), I suspect a lot of the getline_ssl stuff will make more sense.
[11:05] <norsetto> s1024kb: yes, you have written a bug report requesting the merge?
[11:05] <effie_jayx> persia,  ok I'll see what I can do
[11:07] <s1024kb> norsetto: sorry...
[11:07] <norsetto> s1024kb: well, how did you upload it then?
[11:09] <s1024kb> norsetto: dput revu *_source.changes ...
[11:10] <norsetto> s1024kb: oh right, but revu is not for merges, its only for new packages, or updates
[11:11] <norsetto> s1024kb: you should open a bug report, and attach the debdiff to it
[11:11] <s1024kb> norsetto: i will try to. :)
[11:11] <norsetto> s1024kb: do you know how to open a bug report?
[11:12] <s1024kb> norsetto: not yet. i will read the documentations later at home...
[11:12] <proppy> hi s1024kb
[11:13] <norsetto> s1024kb: can you use a web browser now?
[11:13] <s1024kb> norsetto: yes.
[11:14] <norsetto> hmmmm, revu nuking seems to be out of order
[11:15] <norsetto> s1024kb: https://launchpad.net/ubuntu/+filebug
[11:15] <norsetto> s1024kb: you have the debdiff already?
[11:15] <persia> norsetto: Just archive it gently with a comment: no need to nuke :)
[11:16] <effie_jayx> persia,  I am a bit lost ... to find structure changes, what do I use.. .a debdiff between .dsc's?
[11:16] <s1024kb> norsetto: yes.
[11:17] <persia> effie_jayx: I'd need more context: what are you trying to accomplish?
[11:17] <norsetto> s1024kb: good, you may want to look to some other merge request to see how it is done
[11:17] <norsetto> s1024kb: let me fetch one for you
[11:17] <effie_jayx> persia,  an update of this p3scan... from 2.1 to 2.3.2
[11:17] <s1024kb> norsetto: finally got the web page open... this evening the speed is very low here in my office.
[11:18] <s1024kb> norsetto: thanks.
[11:18] <norsetto> s1024kb: well, take it easy, no need to hurry up
[11:19] <s1024kb> norsetto: :)
[11:19] <effie_jayx> persia,  i followed this update bug https://bugs.edge.launchpad.net/ubuntu/+source/p3scan/+bug/133802
[11:19] <ubotu> Launchpad bug 133802 in p3scan "Please update to newer stable version for SSL support" [Wishlist,New]
[11:20] <norsetto> s1024kb: this should be a good example (I hope): bug 163271
[11:20] <ubotu> Launchpad bug 163271 in xulrunner "Please merge xulrunner <IP_ADDRESS>-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/163271
[11:20] <persia> effie_jayx: To examine the differences in the packaging, take a look with `interdiff -p1 -z old.diff.gz new.diff.gz`.  To examine the differences upstream, extract each of the orig.tar.gz files with `tar xzf`, and use `diff -urN old.orig new.orig`.
[11:21] <s1024kb> norsetto: sorry, can't see it on the page?
[11:21] <norsetto> s1024kb: let me know once you have done it and we will look at it together
[11:21]  * persia thought there was a better command to diff tarballs, but cannot remember it just now
[11:21] <s1024kb> norsetto: okay, found it. sorry.
[11:22] <s1024kb> norsetto: okay, many many thanks. :)
[11:23]  * Fujitsu attempts to write an email eliciting help with security.
[11:24]  * persia offers proofreading and editing if desired
[11:25] <frenchy> persia: Should I sym-link the config.{guess,sub}?
[11:26] <persia> frenchy: I usually just copy it in from autotools-dev in configure: or makebuilddir/packagename::
[11:27] <Fujitsu> persia: Thanks, I'll pastebin it in a sec.
[11:27] <persia> frenchy: More generally, those are the porting scripts: if the application is to be compiled on a new platform, it likely wants new hints, so it's nice to have that happen automatically, rather than requiring a manual refresh.
[11:28] <persia> (the counterargument is that it's more difficult to guarantee a repeatable build with changing hints, but I believe that we rebuild often enough not to hit this too much).
[11:30] <Fujitsu> persia: http://pastebin.com/d586748f0
[11:31] <persia> Fujitsu: Mind if I try for something a little more upbeat?
[11:31] <Fujitsu> persia: Sure, I'm not good at writing announcements, or much, really.
[11:32] <persia> Fujitsu: No worries.  I suck at actually generating meaning
[11:33] <persia> Fujitsu: Is there a team name that will be used for this?  motu-swat?
[11:33] <Fujitsu> persia: That would be the universe security team, yes.
[11:33] <Fujitsu> Not that it actually does anything...
[11:34] <persia> Fujitsu: Of the active security chasers, one is a motu-swat admin, and the rest aren't MOTU yet, so I'd say the team's doing OK, but has a few inactive members :)
[11:36] <Fujitsu> persia: I guess.
[11:36]  * persia attempts to inject yet more upbeat cheer, but suspects people would be more useful
[11:39] <effie_jayx> persia,  shall give that a wack after I drop my daughter off school...
[11:39] <persia> effie_jayx: No rush: SSL is nice, but daughters are nicer :)
[11:39] <Fujitsu> persia: Haha.
[11:40]  * Hobbsee waves
[11:40] <Fujitsu> Evening, Hobbsee.
[11:47] <persia> Fujitsu: Just to confirm, there's no ML at this point, right?
[11:47] <Fujitsu> persia: Correct.
[11:48] <\sh> moins
[11:49] <Hobbsee> hey \sh
[11:49] <Fujitsu> Hi \sh.
[11:51]  * persia declares paste.ubuntu.com annoying for this sort of thing
[11:53] <Fujitsu> persia: Lack of linewrapping?
[11:53] <persia> Fujitsu: http://pastebin.com/d4445b8a0 is a first draft.  Takes away the "dire situation" bits, and tries to be inviting.  I think it needs more in the third paragraph, but I'm not sure of the workflow: giving a little instruction to help get people started would be good.
[11:53] <Fujitsu> persia: That looks much better!
[11:54] <persia> Fujitsu: I have the advantage of not actually being under that weight of CVEs :)
[11:55] <Fujitsu> I note that the CVE tracker has been around for 2.5 years, but I'm not sure how old the new incarnation is, nor where its existence has previously been documented.
[11:55] <persia> Fujitsu: Shhhh!
[11:55] <persia> (although maybe "recently" could be dropped)
[11:55] <Fujitsu> Right.
[11:57] <persia> \sh: You seem to be an expert on these things: would you be up for running a class on patching CVEs sometime this week or next?
[11:58] <\sh> Fujitsu, what's up with the cve tracker?
[11:58] <\sh> persia, I'm far away from an expert...I'm just using my skills and read a lot of source ,-)
[11:59] <Fujitsu> \sh: What about it?
[11:59] <persia> \sh: Umm..  rather you seem to have a good grasp of the related workflow.  I'm not sure everyone does :)
 I note that the CVE tracker has been around for 2.5 years, but I'm not sure how old the new incarnation is, nor where its existence has previously been documented.
 Fujitsu: Shhhh!
[11:59] <Fujitsu> \sh: You mean you didn't know of its existence either?
[12:00] <\sh> Fujitsu, you mean people.ubuntu.com/~kees/ubuntu-cve ?
[12:00] <Fujitsu> \sh: Right.
[12:00] <Fujitsu> Er, except the real one ~pitti/bzr/ubuntu-cve.
[12:00]  * persia thought pitti's was now the authoritative tree
[12:00] <\sh> Fujitsu, pitti was running it in former times, since kees and jdstrand were taking over, kees had it on his account
[12:00] <Fujitsu> \sh: The proper branch is in ~pitti.
[12:01] <\sh> Fujitsu, the "real" one is not uptodate...regarding the output..but the source is on pittis account
[12:01] <\sh> Fujitsu, I'm talking about the result of the cve tracker, I think you speak about the source ,-)
[12:01] <Fujitsu> \sh: Right, Kees said he'll have the output fixed soon.
[12:01] <persia> Ah, so pitti has the source, and kees has the output?
[12:02] <Fujitsu> \sh: I speak of the source, right, which is the only valid thing at the moment.
[12:02] <\sh> persia, well, pitti was adding some code I think...the original code comes from debian afaik...but better to ask pitti
[12:02] <proppy> where should I report a bug regarding compiz and blender, on compiz bts, or on launchpad ?
[12:02] <persia> proppy: Both
[12:02] <Fujitsu> Most of what needs to be done at the moment is triage, anyway.
[12:03] <proppy> persia: ok :)
[12:03] <\sh> Fujitsu, do you want to run a self cve tracker? which is quite complicated when I read the documentation of pitti .)
[12:04] <persia> proppy: Be sure to tell LP about the upstream bug, to help with tracking.
[12:04] <proppy> I will check if it is already reported
[12:04] <proppy> blender with compiz enable start without borders
[12:04] <\sh> persia, I'll try to prepare some docs for this workflow...
[12:05] <persia> proppy: Also, #ubuntu-bugs is the better place to ask that sort of question next time :)
[12:05] <Fujitsu> \sh: I have a local branch and am going through triaging various CVEs. Apparently the main branch will be moved to Launchpad in the near future, so more people can commit.
[12:05] <proppy> persia: o k
[12:05] <SWAT> how do I add a .desktop file to a package so it will be entered in a menu? Just drop the file in the debian/ dir? Or create a separte directory and create a rule to move the files (.desktop file and icons) to the correct dir upon installation?
[12:05] <persia> \sh: That'd be great.  An announcement is planned to get some more people involved, but they'll need something to do when they get all excited and want to join.
[12:06] <\sh> persia, well, it's a hell of a lot "real" upstream svn searching ,-)
[12:06] <\sh> persia, most people hate this, like i'm hating it ;)
[12:06] <Fujitsu> \sh: I find that in most cases I can retrieve the patch from another distro or diff between their releases, though with some you're right.
[12:06] <persia> SWAT: If you're packaging someone else's upstream, it's best to use the debian/ directory.  If you're doing your own, put it somewhere in the tarball, and install with $(MAKE) install.
[12:06] <Fujitsu> And it is very much hate inducing.
[12:07] <\sh> Fujitsu, yeah, when other distros are faster then us...
[12:07] <Fujitsu> \sh: Which is 99.9999999% of the time, or so.
[12:07] <persia> \sh: That's about what I thought, and why I thought a class might be good: lead a mix of developers and contributors through the workflow, and generate a bunch more bugs for a while.
[12:07] <SWAT> persia, thanks again
[12:07] <\sh> Fujitsu, but sometimes you see a fix from another distro and it just doesn't fit for our version, whysoever
[12:07] <Fujitsu> \sh: That's also true.
[12:07] <Fujitsu> \sh: A class would be great.
[12:08] <Fujitsu> We could do with more people.
[12:08] <\sh> Fujitsu, yeah, I would like to see more security involvement for universe....
[12:09] <\sh> Fujitsu, I would also propose a separate security archive for universe, so we can inject our security fixes more easily and don't disturb our main security team with this
[12:09] <\sh> Fujitsu, but I think that's just me ,-)
[12:09] <Fujitsu> \sh: I think most would agree, but that won't happen. I can see why they would want to keep control over it all.
[12:09] <\sh> cprov, ping...question about why sometimes I can see -security uploads in -changes and most of the time not. why is that? :)
[12:10] <Fujitsu> \sh: I filed that earlier.
[12:10] <Fujitsu> \sh: Since 1.1.10, there have been no notifications from -security.
[12:10] <Fujitsu> \sh: Bug #164027
[12:10] <ubotu> Launchpad bug 164027 in soyuz "As of 1.1.10, security uploads no longer generate announcements to <distroseries>-changes" [Medium,Confirmed] https://launchpad.net/bugs/164027
[12:11] <Fujitsu> Hey, I didn't get that email.
[12:11] <\sh> Fujitsu, oh...I thought it's just me about this...I work most of the time with the -changes MLs so I don't rely on p.u.c...and when I'm missing an upload, like yesterday the emacs22 fix from the 13th, i'm doomed
[12:12] <cprov> \sh: well, bigjools and colin are discussing this right now, expect the bug to be updated in a minute.
[12:12] <Fujitsu> Yay, only a month to wait...
[12:13] <Fujitsu> cprov: Why does this all have to be private? That's silly.
[12:14] <cprov> Fujitsu: I don't see anything being treated as *private* in this subject. I just don't want to discuss it twice, which is quite different.
[12:15] <Fujitsu> cprov: It is private if the discussion is hidden away in #soyuz or #canonical.
[12:17] <cprov> Fujitsu: no, the bug is public and that is the place for discussion and argumentation (which is quite unnecessary, since you are right) it doesn't depend on anything happen in #soyuz
[12:18] <Fujitsu> cprov: So the only discussion occuring between Julian and Colin is on the bug?
[12:19] <cprov> Fujitsu: well, it's about "how to sort the problem in the right way".
[12:20] <Fujitsu> Right, which should surely be best discussed in a place where the people who are more affected by it (ie. those who don't deal with components with USNs), or those who reported it.
[12:20]  * norsetto -> food
[12:20] <Hobbsee> Fujitsu: es ist sekrit.  you should leave it alone, before you learn more about soyuz and such than you ever wanted to :)
[12:21] <Fujitsu> Er, a `can participate or watch' should have been in their somewhere.
[12:22] <Fujitsu> This brings up another issue: why the $*#($*@#($@# isn't there a damn changelog?
[12:22] <Hobbsee> Fujitsu: of?
[12:23] <Fujitsu> Hobbsee: Launchpad.
[12:23] <Fujitsu> Other than bzr log.
[12:23] <Fujitsu> Which we obviously don't have access to.
[12:23] <Hobbsee> Fujitsu: apart from the release notes?
[12:23] <Hobbsee> Fujitsu: i thought all the stuff was documented in the release notes
[12:23] <Fujitsu> If there are features disappearing, or bugs that aren't milestoned being fixed, we should at least have some notification.
[12:24] <Fujitsu> Hobbsee: It's not listed.
[12:24] <Hobbsee> useful.
[12:25]  * persia wonders if motu-swat could commit to offering peer review of SRUs as well
[12:25] <Fujitsu> The first reference to it I've seen is Colin's comment on the bug. And I read LP material fairly thoroughly.
[12:25] <effie_jayx> ok
[12:25] <effie_jayx> I'm back at it persia ... let me see what I can pull off
[12:25] <persia> effie_jayx: Good luck.
[12:25] <effie_jayx> thanks
[12:30] <zul> morning
[12:30] <fernando> moin all
[12:32] <Hobbsee> LaserRock: poniez plz.
[12:34] <effie_jayx> persia, +#include "getline.h"  -#include "getline_ssl.h" <--- I found it... it got changed
[12:35] <persia> effie_jayx: Good work.  That's one of the tricky things about new upstreams: upstream changes things, and the packaging has to be adjusted.
[12:41] <effie_jayx> persia, so I have to fix source now?
[12:42] <persia> effie_jayx: I'm actually completely unfamiliar with the specifics of what you are doing, so am not sure.  If you've something that changed, and now it doesn't build, that's something to fix.
[12:43] <persia> effie_jayx: On a wider note, I must admit I was a little surprised at your choice of order in which to try things, as it appears to be that you're trying some of the harder things first :)  I don't suppose you have time to take a quick look and maybe alter the order?
[12:44] <Fujitsu> cprov: Are security uploads logged to any other publically visible place?
[12:45] <effie_jayx> persia,  I actually was hoping someone would help me shape it up... any suggestions? I can surely add those
[12:45] <cprov> Fujitsu: no
[12:45]  * Fujitsu blinks.
[12:46] <Hobbsee> cprov: what would the reason for that be?
[12:50] <cprov> Hobbsee: I didn't understand your question. I clearly see a reason to provide a package/upload search page where users could select a specific pocket. It would be even better if it was provided as a rss-like feed. it's just not done yet.
[12:51] <Hobbsee> cprov: what would be the reason that the security uploads are not logged to any publically visible place?
[12:51] <Fujitsu> It would be better if functionality was replaced before the original was removed, preferably with some kind of notification.
[12:52] <Hobbsee> unless i'm misreading
[12:52] <\sh> Hobbsee, sometimes you do security uploads which are still not opened to the public (hint on embargo)
[12:52] <Hobbsee> \sh: sure, but when the embargo is over?
[12:52] <Fujitsu> Colin's comment in the bug about embargoes seems invalid; things published to -security are published to the public. Embargoes have already expired.
[12:52] <\sh> Hobbsee, it's public
[12:53] <Fujitsu> I would presume this has been rebutted in [insert private channel here], but I really can't tell.
[12:53] <\sh> Fujitsu, right...embargoed CVEs are still set to private...as pitti mentiones it in his CVE tracker howto
[12:53] <Fujitsu> \sh: Right, but once they're published by Soyuz, they're surely going to be public.
[12:54] <cprov> Hobbsee: they are presented, https://edge.launchpad.net/ubuntu/gutsy/+queue?queue_state=3&queue_text=, just not in the ideal way.
[12:54] <Hobbsee> oh, right, i see
[12:54] <\sh> cprov, it would just been nice to see -security uploads again on -changes ML...
[12:54] <Fujitsu> Ah, so there is a list, just fairly randomly sorted and only via the web UI.
[12:55] <Fujitsu> What was the result of the secret discussion?
[12:56] <cprov> Fujitsu: DESC uploadtime, doesn't seem random to me.
[12:56] <Fujitsu> cprov: Right, but uploadtime is mildly randomised.
[12:57] <Fujitsu> (and all the binaries are separate)
[12:57] <Fujitsu> It is a workaround, however.
[12:57] <cprov> Fujitsu: there was secret discussion and if you continue to insist in this point I'm afraid you won't be listened anymore.
[12:57] <Fujitsu> I presumed as much.
[12:58] <cprov> err, I meant that "there was *no* secret discussion"
[12:59] <ScottK> So it's safe to have them on a web page, but a ML is dangerous?
[13:00] <\sh> stop stop stop
[13:00] <\sh> I think some things are mixed up now
[13:00] <Fujitsu> cprov: I'm afraid that I am confused. Your comment some 48 minutes ago to \sh seems to contradict your statement.
[13:01] <\sh> 1. there are embargoed CVEs standing for source X...which is normal and should be respected
[13:01] <\sh> 2. there are security fixes which are fixing even those embargoed CVEs...which is quite common, and everybody is doing that
[13:02] <\sh> 3. even when there is an embargoed CVE listed in the changelog a link to the CVE is included, but no description what the fix does or what the error was (which is also quite common in distro security uploads)
[13:02] <\sh> 4. everything else is commonly available...
[13:02] <\sh> 5. all uploads (it doesn't matter which pocket) should be announced on *-changes.
[13:04] <\sh> there is, agreed, a definition how to deal with embargoed CVEs, and this is still valid, but has nothing to do with the upload message on an ML for informational reasons which package was updated/uploaded...this is only important for people dealing with the distro, not for sysadmins, they are using most of the times the USN or other informations from other sources
[13:07] <persia> (and sysadmins can see the same changelogs by downloading things in any case)
[13:07] <ScottK> I'd just like to see an explanation of the change that makes sense.
[13:09] <cprov> I see this whole thing as something quite simple to solve, we can announce every upload that is about to be published in the primary archive and we will do that ASAP.
[13:09] <cprov> and you can treat what happen in 1.1.10 as a regression if you like.
[13:10] <ScottK> cprov: Was it an accident or by design?
[13:11]  * persia thinks the cause of the regression doesn't matter, so long as there is a near-term plan for a solution
[13:12] <ScottK> persia: If it was by design, it's not a regression.
[13:12] <cprov> ScottK: well, I see it as a lack of pre-requisites documentation, but I'm not strong on this, from this point it will be treated  as a new feature.
[13:12] <ScottK> cprov: What does that mean?
[13:13] <cprov> ScottK: it means that "It will be fixed in the next milestone."
[13:13] <ScottK> cprov: That doesn't answer my question then.
[13:13] <Hobbsee> ScottK: go easy on him, me might just escape the channel otherwise.
[13:13] <ScottK> cprov: To me, regression is an accident.  It sounds like this was not by accident.
[13:16] <persia> ScottK: Think viewpoints.  If a change closes a bug, it is good.  If the bug was a bad bug, that's hard to see from some viewpoints.
[13:16] <cprov> ScottK: well, you can call it whatever you want, but it doesn't change the fact that code will have to be fixed to provide the "feature" you are asking for.
[13:16] <ScottK> cprov: I'm trying to understand what's going on.
[13:17] <Fujitsu> persia: There was no bug.
[13:17] <Fujitsu> Bug report, that is.
[13:17] <\sh> I think we all have to calm down ... cprov says now, it will be included again, so we wait
[13:17] <persia> Fujitsu: That's a different problem than the accident / design issue, but yes.
[13:17] <highvoltage> jono: *hugh*
[13:18] <ScottK> \sh: That misses the entire point of this discussion.
[13:18] <highvoltage> jono: oops, ment *hug*
[13:18] <highvoltage> (for that blog post, I needed it)
[13:19] <cprov> ScottK: it's simple, you relied in a broken code side-effect (announcements of -security uploads) when the code got fixed this *problem* was gone. Now if you consider that a *feature* it will be added and documented as such.
[13:19] <jdstrand> \sh, Fujitsu: ubuntu-cve was originally written by pitti.  It was later modified by keescook.  A couple of months ago it was rewritten by keescook (and I wrote some of the helper scripts) to be more like Debian's kernel-sec.  There was not much documentation before the rewrite, and the documentation that exists now is a work in progress.
[13:19] <jono> highvoltage: no worries, glad it helped :)
[13:20] <ScottK> cprov: Is there any documentation that I, as a user, could have looked at that would have allowed me to know I was relying on a side effect and not design behavior?
[13:20] <\sh> ScottK, what is the point? that is was intentional, that this feature was "removed, deleted" or whatever? fact is, it's missing, so there is a bug, cprov now stated, hopefully official, that this will be fixed in the next release.
[13:21] <persia> Also, IRC isn't the best medium for policy statements.  If the lack of a public set of specs is an issue, that out be raised somewhere less transient.
[13:22] <persia> s/out/ought/
[13:22] <cprov> ScottK: no there is no public documentation about what do we expect to be announced and this is a general problem in Soyuz
[13:22] <\sh> ScottK, regarding LP, please have in mind, it's a commercial project, which has some other needs as other projects. and I don't want to be involved in any decision of the LP project, I just want to work with this tool, because it's the heart of our workflow
[13:22] <ScottK> cprov: So your statement that it was a side effect and not design behavior is completely opaque to me.
[13:23] <\sh> jdstrand, thx for the explanation :)
[13:23] <persia> \sh: Commercial / Free doesn't matter.  It's user communication (as cprov just said)
[13:23] <ScottK> \sh: Agreed.  I'd like it to actually support the work flow.
[13:23] <jdstrand> \sh: np
[13:23] <ScottK> persia: It matters for the visibility into what's going on.
[13:24] <cprov> ScottK: right, what can I do to clarify this to you ? What are expecting me to say ?
[13:24] <persia> ScottK: I'd be willing to argue that at some point: consider nethack vs. some of the smaller feature-auction driven programs for Macs, but I've been up to long to do it justice now.
[13:25] <Hobbsee> cprov: i think it's clear now, but the question is how to make it work better in future - as in, with stuff that we're using that migiht not be intentional
[13:25] <ScottK> cprov: You clarified it.  There is no documentation about what I can expect Soyuz to do.  You will change $STUFF that's not by design without notification.  So I can't actually rely on it continuing to do anything that's not documented.
[13:26] <cprov> ScottK: I've already said: 1) It was gone because it wasn't listed as a feature 2) We will fix it 3) to avoid it to happen again we have to provide public documentation (additionally to a  up-to-date test-suite) ... What else ?
[13:26] <persia> ScottK: that sounds reasonable.  I suspect if you documented it (or convinced someone else to so do), it would be easier to rely upon (not that I know what I take for granted either)
[13:27] <ScottK> persia: Now we get to the other reason Free/not-Free matters.  I have a consulting rate for design work on commercial projects.
[13:27] <dholbach> ScottK: come on now... you make it sound as if soyuz only worked by chance, that's completely unfair
[13:27] <persia> ScottK: That's separate, but valid.
[13:27] <\sh> ScottK, sure, so this feature was implemented, now it's missing, for what reason ever, and we have one coder here, cprov, who explained to us, that it will come back...this is all we need to know...I know all these things from my actual company...
[13:28] <ScottK> dholbach: No, I'm saying I've been told that I can't rely on it continuing to do anything that's not documented and there is no public documentation.
[13:29] <\sh> lack of documentation or lack of documented features is a problem in most companies around the world :)
[13:29] <Hobbsee> ScottK: and the tin foil is in the kitchen.
[13:29] <SWAT> persia, because I added icons to the debian dir, I get a "dpkg-source: unrepresentable changes to source". How should this be resolved?
[13:29] <\sh> cprov, so it will be seen again on wednesday?
[13:29] <cprov> after all, it was nice to have this conversation and identify and we are missing a *contract* between users and developers, i.e., user-documentation.
[13:30] <persia> SWAT: uuencode.  Look at flobopuyo
[13:30] <ScottK> cprov: That sounds reasonable to me.
[13:30] <cprov> \sh: no, LP is frozen. It will have to be cherrypicked (if we are lucky) next week.
[13:30] <persia> SWAT: Also, don't ask me: ask the channel.  I'm just ask likely to answer, and won't complain to you about it.
[13:30] <\sh> cprov, cool :)
[13:31] <\sh> cprov, btw, I like the CVE parser on edge now :) I was a bit surprised to not have added any CVEs manually during my reports :)
[13:31] <cprov> ScottK: right, now I ask, how can we collaborate to produce Soyuz user-documentation ?
[13:31] <SWAT> persia, I just highlighted you, because you gave me the suggestion. Normally I would ask the channel.
[13:32] <\sh> SWAT, what do you want to do ? deliver a binary blob inside the debian package for installing it?
[13:32] <persia> SWAT: OK.  Maybe I'm oversensitive because I tend to answer a lot of questions, and so get a lot of unnecessary highlights :)
[13:32] <SWAT> you are very active indeed
[13:33] <ScottK> cprov: I don't know.  That's a tough one for me.  I am often stuck in my mind between knowing that if I want LP to meet my needs I need to participate and being unwilling to be a volunteer for proprietary development.  I don't have a good resolution of those two things in my mind.
[13:33] <SWAT> \sh, add an icon, to the application I'm packaging (for the menu)
[13:33] <\sh> SWAT, add sharutils to build-deps and uuencode all binary files before in the debian/ dir....add in debian/rules some tasks to uudecode them during build time and push them into the right directory
[13:34] <\sh> SWAT, take a look at spkg "ipe" I did that there
[13:34] <SWAT> I'll go and take a look, thanks
[13:35] <\sh> dholbach, I jsut had a look at launchpad-bugs...you are scraping the html via xpath, right? :)
[13:35] <persia> \sh: Do you install directly in debian/rules?  I usually uudecode into debian/ and use dh_install to push them where they go.
[13:35] <\sh> persia, no...I uudecode in debian/ dir and install them in the right location...
[13:35] <dholbach> \sh: you can also use the method="text" connector, which will make use of pages like:
[13:35] <\sh> persia, uudecoding is done in the debian/rules file
[13:35] <dholbach> *let me find the link*
[13:36] <dholbach> https://launchpad.net/bugs/61030/+text
[13:36] <ubotu> Launchpad bug 61030 in ssed "Mistake in ssed string (dapper)" [Undecided,In progress]
[13:36] <\sh> persia, depends on the source package actually
[13:36] <persia> \sh: Right.  From your first explanation I thought you were doing one less step than I, and just wanted to check.
[13:36] <dholbach> \sh: but the text connector is not fully implemented yet, bdmurray will work on that
[13:36] <dholbach> \sh: so yes, up until now we use xpath
[13:37] <cprov> ScottK: so, w/o offending your principles, would you be happy to help us to write  help.launchpad.net/Soyuz/UploadSystem describing how to do an upload and what to expect from it ?
[13:37] <\sh> dholbach, hmm...we really need something like a xmlrpc interface, or REST or soap...but in the meantime I have to use some of this logic for the UI
[13:38] <ScottK> cprov: I would be willing to help some.  Given my current work/family commitments, about all I can promise is to review/validate and maybe fill in some holes.  I do not have a lot of time for Ubuntu work right now.
[13:38] <dholbach> \sh: readonly will work nicely with the next LP release
[13:38] <persia> Wasn't someone talking about REST/JSON at some point recently?
[13:38] <dholbach> \sh: it just needs some bits in py-lp-bugs to get fixed (comments, tags, links to attachments)
[13:39] <dholbach> \sh: xmlrpc/rest/soap/.../... needs fixing in LP first
[13:39] <Fujitsu> persia: And at most points over the past 2 years, but I should shut up.
[13:39] <\sh> dholbach, but readonly functions are much more then we have now :)
[13:39] <dholbach> \sh: hm? I don't understand
[13:40] <persia> Fujitsu: Ah.  Right.  I'll push it into that filing bin then.  As always, thanks for tracking that so closely.
[13:40] <cprov> ScottK: ta, that's fine. It wasn't suppose to sound as a personal question, it's fine if you, as the other active MOTU, simply support the general idea.
[13:40] <\sh> dholbach, some readonly xmlrpc/rest/soap functionality ;;()
[13:40] <\sh> dholbach, or I misunderstood you now
[13:40] <dholbach> \sh: look at https://edge.launchpad.net/bugs/61030/+text
[13:40] <ubotu> Launchpad bug 61030 in ssed "Mistake in ssed string (dapper)" [Undecided,In progress]
[13:40] <ScottK> cprov: I definitely support the idea of documentation.
[13:40] <dholbach> \sh: oh sorry: we have read/write using html
[13:41] <dholbach> \sh: we have partial read-only in the 'text connector' (with the next lp release and some pylpbugs fixing, we will have full read-only)
[13:41] <Fujitsu> dholbach: The LP change being +bugs-text searching working in 1.1.11?
[13:42] <dholbach> Fujitsu: and comments/tags/links-to-attachments added
[13:42] <Fujitsu> Oh, good.
[13:42] <\sh> dholbach, cool...so I can push this underlaying functionality with a nice GUI into public :)
[13:42] <dholbach> I think there are some other bits, but yeah, that'll make pylpbugs more reliable and bughelper much quicker
[13:43] <\sh> something like kbugbuster for LP :)
[13:43] <dholbach> \sh: great - once the 'text connector' works OK, the only necessary change for you will probably to use "method='text'" somewhere :)
[13:43] <\sh> dholbach, for generating new bugs, I'll rely on mail with gpg...this will also help people to come to terms with gnupg and keymanaging
[13:44] <dholbach> \sh: if you use Bug.New() you will get the bug number bug, etc
[13:44] <dholbach> \sh: and you don't need a configured MTA
[13:44] <cprov> dholbach: based in what we have discussed, do you approve https://wiki.ubuntu.com/MOTU/SoyuzUserDocumentationDraft page as a place to we can collaborate ?
[13:44] <dholbach> just your lp cookie somewhere
[13:44]  * gnomefreak has a stupid question, i added export LANG=C to ~/.bashrc and i dont see all chars correctly seems like it turns off UTF support but g-term still shows using UTF-8
[13:45] <dholbach> cprov: not sure if it should live in the MOTU namespace, as it affects all areas of Ubuntu
[13:45] <gnomefreak> i added export LANG=C for chroot lang. warnings and it got rid of them
[13:45] <ScottK> cprov: dholbach has a good point I think.
[13:45] <dholbach> cprov: but I guess it's going to live on help.launchpad.net in the future anyway, right?
[13:45] <\sh> dholbach, well, TBH, everyone has a SMTP server somewhere, with TLS etc. and this is a simple adjustment in our perl code :)
[13:45] <ScottK> It should probably relate under the Ubuntu Development pages that dholbach has been doing.
[13:46] <\sh> dholbach, lpbugs.py (the old version) had this functionality already :)
[13:46] <cprov> dholbach: exactly, MOTU would host a draft.
[13:46] <dholbach> a sub section in https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive ?
[13:46] <ScottK> Sounds reasonable to me.
[13:46] <dholbach> \sh: your choice, I prefer to not have a local smtp or configure apps to use an SMTP I might have somewhere
[13:46] <cprov> yup
[13:46] <gnomefreak> can i replace the C with ALL maybe?
[13:49] <ScottK> cprov: Please give us a link here when you've started the page (I'll subscribe to it).
[13:55] <cprov> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive/SoyuzUserDocumentationDraft
[13:57]  * ScottK subscribes.
[13:58] <Hobbsee> ich auch.
[13:58] <persia> Moi aussi
[14:00] <norsetto> persia: are u working on bug 163727 ?
[14:00] <ubotu> Launchpad bug 163727 in timidity "soundfont does not seem to get automatically installed" [Low,Triaged] https://launchpad.net/bugs/163727
[14:01] <persia> norsetto: Not actively: do you know someone who wants it?  It's in large part a search effort, as most soundfonts aren't DFSG-free, and freepats isn't quite good enough.  On the other hand, I am correctly assigned to that bug.
[14:02] <persia> Ideally, someone would generate a full XG soundfont & publish under a permissive license, but as even getting the XG spec costs, that's not likely soon :(
[14:03] <\sh> Hobbsee, are you learning german? ,-)
[14:04] <Hobbsee> \sh: no, i learnt parts of it a few years ago.  however, i've always come up with that phrase before the english equivalent.  unsure why.
[14:05] <persia> Because "I also" sounds funny and "Me too" is ungrammatical?
[14:05] <\sh> me too is aol slang ,-)
[14:06] <persia> \sh: It was common inappropriate use for decades before AOL :)
[14:06] <txwikinger2> Hehe.. the only words my son knows in German are "Finger weg"
[14:06] <\sh> ><EMAIL_ADDRESS>wrote: >> I need pr0n<EMAIL_ADDRESS>wrote: > me too ! ,->
[14:06] <persia> (sufficiently so that most native speakers of English don't immediately understand "I also")
[14:07] <Hobbsee> \sh: also, when iv'e been greeting people too much, i tend to automatically switch to german.
[14:08] <Hobbsee> persia: yeah, i come up with i also, and then go "um, huh?
[14:08]  * \sh needs a pause
[14:09] <txwikinger2> :D
[14:13] <txwikinger2> Did dholbach already announce when the motu question time will be this week?
[14:13] <persia> txwikinger2: There's a post on planet (although I must admit I don't remember)
[14:13] <dholbach> txwikinger2: Friday, 12:00 UTC
[14:14] <dholbach> txwikinger2: still need to send a mail out
[14:14] <persia> dholbach: That's the same time as the MOTU Meeting...
[14:14] <dholbach> ngh, not again
[14:14] <Hobbsee> persia: people have learned to clone themselves.
[14:15]  * dholbach pedals back and makes it 13:00 UTC
[14:15] <persia> dholbach: MOTU Meeting has been bouncing between 12:00 and 20:00 for a while.  Do you want a change maybe so there's not a conflict next month?
[14:15] <dholbach> persia: maybe I'll move it to 13:00 generally
[14:16] <persia> dholbach: Thanks: 13:00 gets pretty late in Australia in the Summer.
[14:16] <dholbach> persia: I hope that we'll find people who are willing to run it at another time
[14:16] <dholbach> we had it at 0:00 and 12:00 UTC for a while
[14:16] <persia> dholbach: Q&A sessions?
[14:16] <dholbach> yes
[14:17] <dholbach> I'm happy to do the the ones that are good for european folks
[14:18] <persia> Do we have any demographics on interested parties?  I'm a big fan of asking questions here whenever, but do agree that sessions sometimes help.  On the other hand, I don't know how many interested parties we have from APAC.
[14:18] <dholbach> now that we have more people joining the Q&A sessions and broad announcements
[14:19] <dholbach> we also have announcements in the packaging section on the forums
[14:19] <dholbach> but I can't tell you how many APAC people we'd have there, if Q&A sessions were later
[14:19] <persia> I think the promotion is working well, I just don't know from where they come, and times convenient over here aren't typically useful for North or South America.
[14:20] <dholbach> do you think other times than 0:00 and 13:00 UTC would work better? it was just my initial idea
[14:20] <\sh> grmpf....what do I do? I don't have any sponsors  to cheer for MOTUship ,-) I'm stucked now with my application for motuship
[14:20] <persia> I'm also not convinced we've that many non-Australians from APAC, as the localisation over here is significantly weaker than for Europe / Americas.
[14:22] <txwikinger2> Thanks dholbach
[14:22] <persia> \sh: I'll cheer you.  I've seen acceptable work from you for quite a while, and seem to have your address in my sponsored patch archives (you'll still need more)
[14:22] <ScottK> \sh: Did you apply again?  If you didn't, please do.
[14:23] <\sh> persia, I'll add kees to my sponsors ,-)
[14:23] <\sh> ScottK, no I didn't apply again..not yet
[14:23] <ScottK> \sh: OK.  When you do, please CC me on the application so I can be sure to endorse it.
[14:26] <\sh> ScottK, will do...
[14:26] <\sh> persia, thx
[14:43] <persia> dholbach: The dual nature of w.u.c/MOTU/GettingStarted and w.u.c/MOTU/Contributing was just pointed out to me.  Any thoughts on merging the two?  If left to my own devices, I'd be tempted to push the content from Getting Started into Contributing, and use the GettingStarted path (with a redirect from Contributing due to external links).
[14:44] <dholbach> persia: what I like about GettingStarted is that it's a relatively short guide that links to all necessary steps along the way
[14:44] <dholbach> persia: do you think we can conserve that idea somehow?
[14:46] <mok0> dholbach: too much information might turn people off
[14:46] <dholbach> mok0: exactly
[14:46] <persia> dholbach: Hmm.  I'm not a fan of short pages, but I agree that a lot of that is "right now" information.  Perhaps keeping a lot of that on the top, and tailing it with MOTU/Contributing content (with some wording changes (and yes, I don't mind processing: you're busy))
[14:46] <ScottK> dholbach and persia: Please, if you can, make it even more clear that the mentors program is totally and completely optional.  I still (as recently as the last week) get e-mail about "What can I do if I don't have a mentor yet".
[14:46] <\sh> cacti CVE-2007-6035
[14:47] <persia> Ah.  There's that.  I guess I'm mostly not happy with the fragmentation.
[14:47] <ScottK> mok0: Hello.
[14:47] <\sh> and fixed for gutsy now
[14:47] <mok0> ScottK: hi
[14:47] <dholbach> ScottK: that page only contains<EMAIL_ADDRESS>[14:48] <ScottK> dholbach: I'm just saying.  I made some wiki page changes after the last mail I got to try and make it even clearer.
[14:48] <ScottK> I think people don't feel sufficiently free to just contribute as they are able.
[14:48] <persia> dholbach: I guess the other reason I'm not happy about GettingStarted is that there appears to be a lot of focus on new packaging, and we've heaps of maintenance to get done: I'd much rather channel people into fixing existing bugs and helping bugsquad whilst they learn, rather than encourage new packaging (which is rarely done will without seeing the work of others).
[14:48] <mok0> dholbach: clear is good. And not having to look many places for info is good. But I think a Quick-Start version should be retained.
[14:48] <DaveMorri1> In the following debian\rules file what do I need to make config.status depend on for the patches to be applied before the configure command? http://pastebin.ca/790632
[14:49] <dholbach> ScottK: right, I do that already, when I come across it; for example I copied your FAQ bit from UbuntuDevelopment/FAQ to MOTU/FAQ or the other way around yesterday
[14:49] <dholbach> persia: that's why I referred to both Bugs and NewPackages
[14:50] <persia> DaveMorri1: You really don't want to mix CDBS and raw debhelper.  The answer is likely "patch", but you really want to do it differently.
[14:50] <dholbach> persia: also I added that packaging a new piece of software might not be the easiest thing to start with
[14:50] <dholbach> persia: if you have ideas on how to make that more prominent, I'm happy to add that
[14:50] <Kmos> CVE-2007-6035
[14:50] <Kmos> \sh: !cve 2007-6035
[14:50] <ScottK> DaveMorri1: What persia said.  If you look at man dpatch it's got a decent example of how to integrate dpatch into debian/rules
[14:50] <Kmos> !cve 2007-6035
[14:50] <ubotu> Sorry, I don't know anything about cve 2007-6035 - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[14:51] <persia> dholbach: I see those, but I'm also seeing a lot of people packaging new software who have trouble generating a patch, which worries me because 1) I'm not confident of maintenance, and 2) it adds to the REVU burden.  I'll go think some more, and see if I can come up with something useful.
[14:52] <dholbach> persia: I'll change the sentence mentioning new packages.
[14:52] <persia> dholbach: Part of it is that I don't want to create a page that has all the links, and big warning labels everywhere: gets into a "boy who cried wolf" thing.
[14:52] <\sh> Kmos, it's not listed on mitre...but on NVD :)
[14:53] <persia> No need to change the sentence: it's not important enough right away, and won't fix my issue.
[14:53] <Riddell> norsetto: ping
[14:53] <Kmos> \sh, ah ok :)
[14:53] <norsetto> riddell: pong
[14:53] <Riddell> pyelemental depends on libelemental-dev, is that in hardy?
[14:53] <dholbach> persia: I'll think about what we can do with /Contributing
[14:53] <\sh> Kmos, debian security tracker looks also for nvd it seems ;)
[14:54] <norsetto> riddell: yes, but is not yet built, is part of the gelemental package that you (or somebody else) took out of NEW this morning
[14:54] <DaveMorri1> hmmm, I liked they way it was easy to do patches in cdbs
[14:55] <persia> ScottK: Just as an aside, I think of the mentors mailing list as possibly distinct from the Mentoring program: they aren't sufficiently staffed to distinguish well today, but consider the first as a slower version of what we do here, and the second as one-on-one guidance (although I hope the new process is adopted).
[14:55] <persia> DaveMorri1: Then just do it all in CDBS :)
[14:55] <norsetto> Riddell: thank you for taking care of that :-)
[14:56] <DaveMorri1> yep I guess.  I still need to use that custom configure command so how can I tell that to depend on the patches or if I do it the cdbs way will it automatically happen?
[14:57] <ScottK> DaveMorri1: If you do it with traditional debhelper it'll be more complicated to set up, but much clearer what's actually happening.
[14:58] <ScottK> DaveMorri1: IMO, CDBS is good for straightforward things that just work.  Once you start wondering "How do I get CDBS to ..." you don't have to go far down that road before you're better off with debhelper.
[14:59] <DaveMorri1> how come you can't use the cdbs patch system with debhelper then?
[14:59] <ScottK> DaveMorri1: Integrating dpatch into a debhelper debian/rules takes a bit of thinking, but actually using it is easy (dpatch-edit-patch).
[14:59] <mok0> DaveMorri1: use dpatch
[14:59] <ScottK> That's like saying how come Perl code doesn't work in a Python program.
[14:59] <mok0> :-)
[14:59] <Riddell> norsetto: all looks fine, accepted
[14:59] <persia> DaveMorri1: You can, but you'd need to learn heaps of the CDBS internals, which even most CDBS packagers hide from.
[15:00] <StevenK> ScottK: The other way around can work ...
[15:00] <DaveMorri1> no, because my package builds
[15:00] <ScottK> It's kind of orthogonal, but possible if you work at it.
[15:00] <norsetto> riddell: thanks, appreciate it
[15:00] <elkbuntu> ScottK, yeah.. when are you going to fix that bug? :Þ
[15:01] <DaveMorri1> I'll check out using dpatch and going all cdbs and see which I perfer
[15:01] <DaveMorri1> thanks for the tips
[15:02] <dholbach> norsetto: congratulations to pyelemental in the archive! :)
[15:02] <mok0> I added quite a bit of CDBS info on the wiki some days ago
[15:02] <norsetto> dholbach: yuppy :-D
[15:04] <mok0> Any package that uses GNU autotools should be built with CDBS IMHO
[15:05] <azeem> other people think differently ITHO
[15:05] <persia> mok0: Erm.  I can show you some counterexamples.  How about "Any package that uses GNU autotools properly should be built with CDBS"?
[15:06] <norsetto> cdbs shall die <insert satanic laugh here>
[15:06] <mok0> persia: granted
[15:06]  * persia also especially likes the 1-line debian/rules for CDBS using artwork, settings, and meta-packages
[15:06] <Hobbsee> norsetto: and yada will become the new overlord?
[15:06] <persia> Umm..  Why don't we just repackage those?
[15:07] <norsetto> Hobbsee: overlady ....
[15:07] <mok0> I've used cdbs quite a bit lately and it works fine. For newbies it hides all the gory makefile details, and makes sure it works correctly
[15:07] <persia> (and for experts it offers more hooks and goodies than you might imagine)
[15:08] <mok0> AND, it can apply patches to autotools files, which is otherwise a pain to bring about
[15:09] <frenchy> persia: Hi again, can you please tell me where I can find some information on the debian/*.install file?  It's not working for me and I can't find any info on what it actually does.
[15:09] <persia> frenchy: man dh_install
[15:10] <frenchy> persia: ta
[15:15] <frenchy> Anyone got a sec to chat over a dh_install problem?
[15:15] <mok0> frenchy: go ahead
[15:16]  * persia cheers mok0
[15:18] <frenchy> The first line in the me-tv.install is "usr/bin/me-tv"
[15:18] <mok0> frenchy: ... and?
[15:19] <frenchy> when I run dh_install from the top directory I get "cp: cannot stat `./usr/bin/me-tv': No such file or directory"
[15:19] <mok0> frenchy: the path in *.install should be relative to the top-level source dir
[15:19] <frenchy> the file is a debian/usr/bin/me-tv
[15:20] <frenchy> persia: Ok, that make sense but ...
[15:20] <frenchy> persia: gxine.install has usr/bin/gxine?
[15:20] <mok0> frenchy: your'e talking to me, not persia.
[15:20] <frenchy> Ooops.
[15:20]  * persia suggests listening to mok0, who has done much more recent packaging with dh_install than I.
[15:21] <frenchy> mok0: Sorry.
[15:21] <mok0> You can invoke dh_install with an option --sourcedir=debian/tmp , then that will be prepended to what's in the *install file
[15:22] <mok0> frenchy: but I suggest that you just put the correct path in the .install file, it's clearer
[15:22] <frenchy> mok0: So is it ok for me to put the debian/ at the start .... got it.
[15:22] <Riddell> norsetto: what's this "Xb-Npp-Applications:" line in gecko-mediaplayer?
[15:23] <mok0> frenchy: yes.
[15:23] <norsetto> riddell: those are for the new plugin policy with firefox
[15:23] <mok0> frenchy: it's usually debian/tmp, though...
[15:23] <norsetto> riddell: I should have a spec reference somewhere
[15:26] <frenchy> mok0: I just realised that.  For me it seems to be debian/me-tv.
[15:27] <mok0> frenchy: It depends on what exactly goes on when debian/rules does "make install"
[15:28] <norsetto> riddell: here: https://blueprints.launchpad.net/ubuntu/+spec/firefox-distro-addon-support
[15:28] <broonie> Normally things are set up so that the upstream stuff stages into debian/tmp and then files are picked out of there into the debian/final-package dirs.
[15:28] <Riddell> norsetto: interesting thanks. looks fine, accepted into multiverse
[15:29] <mok0> frenchy: you need to understand: the install process goes on in 2 stages. First, make installs everything in some temporary place, then, dh_install moves files to debian/<pacakgename>
[15:29] <norsetto> riddell: thanks again!
[15:29] <frenchy> mok0: That would've been anjuta.  Is debian/me-tv ok?
[15:29] <mok0> frenchy: is that the name of one package being built?
[15:30] <frenchy> mok0: Yes.
[15:30] <mok0> frenchy: .... how many subpackages?
[15:30] <frenchy> mok0: None ... I think.
[15:31] <mok0> frenchy: look in controls file
[15:32] <jdong> whoa awn in Hardy :)
[15:32] <frenchy> mok0: I should see 2 parts right, one for the source and one for the binary.
[15:33] <jdong> wait does hardy-changes show packages that are stuck in New?
[15:33] <mok0> frenchy: it "make install" installs the files in debian/<packagename>, then you do not need to call dh_install
[15:34] <jdong> persia: btw, do you have any links to FDO documentation that the .png suffix should be dropped on icons?
[15:35] <persia> jdong: Not handy.
[15:35] <jdong> persia: okay, never mind then
[15:35] <frenchy> mok0: Ok ... the light bulb just went on.  "dh_install moves files to debian/<pacakgename>"
[15:35] <persia> There was something on the wiki, but the last remnant is now written by me and deprecated, so not something for you to trust :)
[15:36] <mok0> frenchy: yes
[15:36] <mok0> frenchy: that's the only purpose of dh_install, but it is only needed if you want to separate the install tree into different binary packages
[15:37] <frenchy> mok0: So me-tv.install is really only for debian specific files (i.e. menu) ... because everything else can go in the make install?
[15:38] <frenchy> mok0: And your point ... of course.
[15:38] <mok0> frenchy: yes
[15:39] <frenchy> mok0: Thanks.  I'll give that a go.
[15:39] <mok0> frenchy: glad to help!
[15:40] <nealmcb> ahh - daylight savings....  damn
[15:43] <persia> nealmcb: Move: not everywhere has that silly thing about changing clocks :)
[15:43] <nealmcb> persia: :-)
[15:51] <frenchy> mok0: Yet another question, me-tv.install tells dh_install where to copy the files to, am I right?  Then how does dh_install know where to copy the files from?
[15:52] <mok0> frenchy: no, me-tv.install tells dh_install where to copy the files FROM
[15:53] <\sh> Fujitsu, did you see wordpress CVE-2007-6013? ;)
[15:55] <frenchy> mok0: I do not doubt your greatness for a second ... but I read this from `man dh_install`  "Files named debian/package.install list the files to install into each package and the directory they should be installed to"
[15:55] <frenchy> mok0: And I assumed the opposite.
[15:57] <mok0> frenchy: yeah, that manpage is hard to interpret
[15:58] <mok0> frenchy: I don't think you need to use dh_install
[15:58] <persia> Erm.  Just a note, an install file may contain lines with two whitespace separated values, and both define from and to
[15:58] <frenchy> persia: That where I was heading ... thanks.
[15:59] <mok0> frenchy: you should use the specialized dh_install* funcitons, like dh_installmenu
[16:00] <frenchy> mok0: ohhhh ... I'm using cdbs ... so a lot of that is auto-magically.  But I don't see a dh_install_* for a desktop file.
[16:01] <frenchy> s/auto/done auto/
[16:02] <persia> There isn't one.  .desktop files currently require an entry in debian/install.  It's on the feature wishlist, but isn't likely to get deployed in Ubuntu until hardy+1
[16:02] <mok0> frenchy: create a file called <package>.menu with the name of the desktop file
[16:02] <mok0> frenchy: cdbs will then put it in the right place in the package build tree
[16:03] <frenchy> mok0: awesome.
[16:04] <mok0> frenchy: yeah pretty cool
[16:04] <persia> Um.  No.  debian/package.menu is supposed to be a debian menu file, and gets installed in /usr/share/menu.  The ,desktop file belongs in /usr/share/applications
[16:05] <mok0> persia: you're right. My bad.
[16:07] <mok0> frenchy: I stand corrected. You _do_ need the .install file, with a space separated FROM TO line placing the desktop file ./usr/share/applications
[16:08] <persia> (please also create debian/package.menu in menu format for users of desktop environments that aren't 100% freedesktop compliant
[16:10] <frenchy> Thanks, I'll give that a go, now.
[16:15] <DaveMorri1> how can I tell cdbs to use make instead of make -c?
[16:17] <persia> DaveMorri1: MAKE:=make
[16:18]  * jdong smacks himself for setting the wrong From: on his mails
[16:18] <jdong> heh I really need to have procmail handle my outgoing too
[16:19] <DaveMorri1> persia: didn't work
[16:20] <DaveMorri1> the autotools.mk file has this
[16:20] <persia> DaveMorri1: Ought.  I can't troubleshoot now, but $(MAKE) is likely getting set somewhere, and there's likely an override mechanism.
[16:20] <DaveMorri1> DEB_MAKE_INVOKE = $(DEB_MAKE_ENVVARS) $(MAKE) -C $(DEB_BUILDDIR)
[16:20] <DaveMorri1> so it doesn't look like it can be overridden
[16:20] <mok0> DaveMorri1: ...and probably shouldn't be...
[16:20] <persia> DaveMorri1: Why don't you want to run make in the base package directory?
[16:20] <DaveMorri1> yeah, the package I have doesn't build with make -C but does with make
[16:21] <frenchy> Here's the thing, right, I put the .desktop file in the top directory because it's not really debian specific ... is that right?
[16:21] <DaveMorri1> persia: not my build system
[16:21] <persia> DaveMorri1: That's why debian/patches exists :)
[16:22] <DaveMorri1> persia: I don't really wanna patch the whole build system.  It runs configure, creates a build dir, then calls make which moves into the build dir and builds it there
[16:22] <persia> Depends on how you're shipping it.  If you're shipping it as upstream, you should put it near your icons, and install it with your build system (not with debian/install).  If you're shipping it as the packager, it7s considered good form to try to keep everything inside debian/
[16:23] <DaveMorri1> build dir changes depending on arch and compiler :(
[16:23] <persia> DaveMorri1: Then just override $(DEB_BUILDDIR)
[16:25] <DaveMorri1> k
[16:25] <DaveMorri1> thnaks
[16:31] <siretart> superm1: the license of libdvdcss2 was never an issue. it's rather what it does.
[16:34] <mok0> frenchy: some MOTUs don't like you putting stuff outside of debian/
[16:34] <Hobbsee> because it's a pain, yes.
[16:36] <mok0> Hobbsee: a pain to review, perhaps
[16:36] <Hobbsee> pain to upgrade
[16:36] <Hobbsee> you cant just nuke the debian dir.
[16:36] <Hobbsee> and i'll bet it also does nasty things with patches back to debian
[16:37] <mok0> Hobbsee: Why would you want to nuke the debian dir?
[16:37] <Hobbsee> to put it into the new source package?
[16:37] <Hobbsee> for the newer version?
[16:38] <mok0> Hobbsee: You could just apply the diff to the new dir
[16:38] <\sh> siretart, I tried to explain it on the ML :)
[16:38] <Hobbsee> mok0: it's kinda hard to *find*, in with all the new upstream changes.
[16:39] <\sh> siretart, btw...do you have time for mentoring me for debian maintainership? ,-)
[16:39] <Hobbsee> but yes, if you wanted to diff out the old lot, then apply it to the new package, you probably could
[16:39] <Hobbsee> just harder
[16:39] <\sh> moins bddebian
[16:40] <\sh> hmm...if everything works fine, one cve fix for debian will just arrive in debian-security...
[16:40] <mok0> Hobbsee: In general, your diff would just contain the debian/ dir, right? Plus a few files you've placed in the source
[16:40] <bddebian> Heya gang
[16:40] <bddebian> Hi \sh
[16:40] <mok0> Hobbsee: As long as the new version doesnt clash with that , you should be fien
[16:40] <Hobbsee> mok0: yes, should do.
[16:40] <norsetto> bddebian: salutations
[16:41] <persia> Hobbsee: THat's a very broken way to handle new upstreams.  You want to zcat ../foo.diff.gz | patch -p1 in that case.
[16:41] <Hobbsee> persia: was thinking of uupdate
[16:41] <mok0> Hobbsee: If you're authoring a completely new autobuilds system, it's kinda akward to put it in as dpatches
[16:41] <bddebian> Heya norsetto
[16:41] <frenchy> I don't understand, what does a GNOME desktop file have to do with upgrading?
[16:41] <persia> Hobbsee: Yep.  Then too :)
[16:41] <persia> You get a little fuzz, which you should fix, and debian/
[16:42] <Hobbsee> persia: sorry, which was is broken?  moving the debian dir, or patching the source direct/
[16:42] <\sh> I don't know..but pushing files into upstream source tree is not what a package maintainer want...
[16:42] <mok0> frenchy: when a new upstream version appears, you want to move your desktop file along with your debian dir
[16:42] <\sh> that's why debian and redhat are maintaining the additions and patches inside their build system
[16:43] <persia> Hobbsee: expecting to move or nuke debian/ and have it do the right thing.  Because debian/rules clean gets called when building a package, it's not infrequent to have unexpected variation in diff.gz
[16:43] <persia> mok0: frenchy is upstream :)
[16:43] <\sh> and inline patching a .desktop file...well, I don't find it a really cool location..most likely it's even more distro specific
[16:43] <frenchy> mok0: Ohhh ... yeah when upstream isn't maintaining the desktop file.
[16:43] <Hobbsee> persia: granted.
[16:44] <frenchy> If the maintainers are "maintaining" the desktop file then it's a diff right?
[16:44]  * persia finally sends the email with the review procedures for doing it the right way and plans to update the recipes & instructions later
[16:44] <Hobbsee> persia: so can i skip to reading your mail, and delete the rest?
[16:45] <\sh> frenchy, package maintainers who are adding a .desktop file, this will be represented in the .diff.gz, yes. upstream maintainers have to do it in their source tree
[16:45] <persia> Hobbsee: Err..  "Doing new upstream reviews properly".  Other email may be useful for other values of it.
[16:45] <frenchy> \sh: I'm the latter,right?
[16:45]  * persia notes that when the package maintainer is the upstream maintainer, it's vastly preferred that the .desktop file be an upstream file.
[16:46] <frenchy> \sh: so you are saying that it should go in the top directory?
[16:47] <\sh> frenchy, when you are upstream maintainer, you should maintain the .desktop file in your source tree, yes...and put it into your normal make dist resulting tar.gz
[16:48]  * persia sleeps
[16:50] <frenchy> \sh: mok0: mok0 said "some MOTUs don't like you putting stuff outside of debian/".  We now agree that this is a unnecessary restriction for a MOTU to place on me?
[16:50] <mok0> brb
[16:50] <frenchy> Damn, just missed him.
[16:51] <frenchy> \sh: I think we see eye-to-eye here.  I was really just trying to get a confirmation out of mok0.
[16:52] <\sh> frenchy, if you want to be sure, that you want to have a .desktop file with your stuff in, provide it in the upstream tarball...no package maintainer will touch your upstream tarball...they are only patching stuff in and out which will be represented in a patch file
[16:53] <\sh> frenchy, most package maintainer are so kind and sending bugreports with their changes to you (reading upstream developer) and you can decide which patches you want to apply and which not.
[16:54] <\sh> frenchy, so, when you want to have a .desktop file distributed with your source tarball, include it in your VCS (aka cvs, svn, bzr whatever) , but
[16:54] <\sh> frenchy, if you want a .desktop file only for ubuntu or debian, put it into the debian/ dir and install it manually in debian/rules...
[16:54] <frenchy> \sh: all makes perfect sense to me.
[16:58] <\sh> frenchy, normally, an upstream developer shouldn't deal with distro packaging...so no upstream developer should ship debian, redhat or <insert your favorite distro here> build specific sources with their source tarball...but that's just me
[16:58] <\sh> ok....time to go home
[16:58] <\sh> cu later
[17:17]  * RainCT waves
[17:19] <bddebian> Heya RainCT
[17:25] <mok0> frenchy: I didn't realize you were upstream.
[17:25] <geser> Hi bddebian
[17:25] <huats> hey bddebian
[17:26] <huats> bddebian: I was looking for you
[17:26] <huats> :)
[17:28] <bddebian> Heya geser, huats
[17:28] <bddebian> huats: Uh oh, what'd I do now? :-)
[17:28] <huats> bddebian: no big deal
[17:29] <huats> I was wondering if you were taking care of the merge of balsa, or can I have a look
[17:29] <bddebian> huats: Ah, go for it, thanks
[17:29] <huats> (I am asking you since you are marked as the last uploaders....)
[17:29] <huats> bddebian: ok
[17:29] <huats> great
[17:30] <huats> I might ask you a few stuffs may be...
[17:30] <huats> but I'll try to do my best by myself :)
[17:30] <bddebian> Cool
[17:30] <huats> bddebian: thanks
[17:33] <bddebian> Heh, I like LaserRock better ;-P
[18:03] <norsetto> huats: ping. Available for some more testing?
[18:05] <jariq> hi
[18:05] <LaserJock> bddebian: you liked him better?
[18:07] <jariq> Let say i am developer of network application and would like to get it into universe. I am little confused what should I do.
[18:07] <SWAT> jariq, is it opensource?
[18:07] <jariq> yes
[18:07] <jariq> gpl
[18:08] <bddebian> LaserJock: Yeah, bring him back will ya? ;-P
[18:09] <warp10> Hi all!
[18:10] <SWAT> jariq, you'll need to package it etc. (and follow the instructions on the wiki). Do you have a url to the website?
[18:11] <imbrandon> LaserJock: http://stompbox.typepad.com/blog/2007/11/mantha-on-the-m.html
[18:12] <imbrandon> jariq: well you can go two routes, you can just publish a source tarbal and rope a current MOTU or MOTU hopefull into packaging it for you ( the quickest ) or learn to make debian packages yourself and go that way ( the best long term )
[18:13] <imbrandon> if you choose the latter then !packageguide will help you
[18:13] <imbrandon> !packageguide
[18:13] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports
[18:13] <imbrandon> if the former, then get to know your fellow MOTU :)
[18:14] <jariq> if i create a package myself
[18:14] <jariq> what will happen then
[18:14] <imbrandon> then it should be submitted to REVU and current MOTU will review it for QA and upload it
[18:15] <imbrandon> REVU == http://revu.ubuntuwire.com
[18:15] <jariq> so the first route is quicker
[18:15] <imbrandon> right
[18:15] <jariq> because motu does the package
[18:15] <imbrandon> first is quicker, but the second is better longer term
[18:15] <jdong> how long after a build succeeds in Hardy before the buildd's will pick up the new package?
[18:15] <jariq> and the second
[18:16] <jariq> if i make a package upload it to revu
[18:16] <imbrandon> jdong: you mean publish the new package? umm 1 hour 2 minutes iirc start to finish
[18:16] <jariq> someone will approve it
[18:16] <jdong> imbrandon: I mean for build-depends: foo-dev to pick up the new foo-dev for future builds
[18:16] <jariq> then it will get to universe?
[18:16] <imbrandon> if you upload a package to revu it largely depends on the time of day and time of week, early on mondays normaly goes within minutes, other times can be daysw
[18:17] <norsetto> warp10: do you have an italian desktop?
[18:17] <imbrandon> jdong: whenever its published it should
[18:17] <jdong> imbrandon: ok, thanks
[18:17] <warp10> norsetto: I do! How can I help you?
[18:18] <imbrandon> jariq: the "best" way if you go the revu route is once uploaded , copy and paste the url to the upload in here asn kindly ask for MOTU review
[18:18] <imbrandon> alot of times you can get soem feedback realtime that way
[18:18] <jariq> imbrandon> great
[18:18] <norsetto> warp10: could you check bug 160152? You just need to install tagtool from gutsy-proposed and see if it is in italian
[18:18] <ubotu> Launchpad bug 160152 in tagtool "[Gutsy] Tagtool without icon and in english only" [Medium,Fix committed] https://launchpad.net/bugs/160152
[18:18] <jariq> imbrandon> and what about updates
[18:19] <imbrandon> jariq: updates to the package once pubished in the archive can be made with a simple diff file attached to a bug by you oor someone else
[18:19] <norsetto> warp10: don't start tagging your<PHONE_NUMBER> illegal mp3 though ....
[18:20] <warp10> norsetto: I just read your email on MOTU ML, I was yet thinking to check your tool. :)
[18:20] <warp10> norsetto: sorry, I only have illegal .ogg :P
[18:20] <norsetto> warp10: jokes aside, if you can test it it would be cool
[18:21] <jariq> imbrandon> so any other updates will be done by submiting diff on launchpad? then some motu will apply the patch on package?
[18:21] <imbrandon> correct
[18:21] <warp10> norsetto: I'll do. Just the time to request a sync and I'll take a look
[18:21] <imbrandon> jariq: or you yourself could become a motu at somepoint, totaly upto you
[18:21] <imbrandon> but yea
[18:21] <jariq> imbrandon> but i dont have to
[18:21] <imbrandon> correct, you dont need to
[18:21] <imbrandon> by anymeans
[18:22] <norsetto> warp10: take your time,just report your results to the bug report. thanks!
[18:22] <warp10> norsetto: you are welcome! :)
[18:23] <jariq> imbrandon> so i can be a maintainer of packege but do not have to be motu. Just need to get first package approved by motu and then just put patches to launchpad