#ubuntu-motu 2006-01-16
<mr-russ> bug day... oh exicitng.
<Nafallo> baah
<Kyral> mmm
<Kyral> chinese buffet
<Nafallo> good thing I have to be away 8:15-15:45 tomorrow :-P
<Nafallo> (traveltime included)
<mr-russ> do devs really hate bugday?
<ajmitch> no
<ajmitch> we loves it
<tseng> we do?
<ajmitch> sure
<ajmitch> don't you love all those beagle bugs?
<tseng> nope.
<tseng> i like them even less when i dont have much chance of fixing
<tseng> like evo-sharp not supporting eds 1.5
<tseng> it builds fine, it just explodes at runtime
<tseng> haha there is a huge thread on mono on ubuntu-dev
<tseng> funny
<Riddell> aren't bug days on thursdays?
<psusi> why is there no man page for ulimit?
<psusi> what was the flag to enable core dumps?
<ajmitch> tseng: yes, why don't we have beagle in the desktop seed for dapper then?
<ajmitch> support 0.1.4 for the next 3 years
<tseng> yes brilliant
<tseng> we wanted to build stuff with libbeagle
<tseng> and leave the daemon in universe
<ajmitch> hm
<chninkel> psusi: ulimit is a bash builtin I think
<ajmitch> amazing questions in #mono
<chninkel> psusi: you'll find it with man bash
* tseng suspends disbelief for a few moments
<psusi> ohh
<psusi> there we go... ulimit -c
<ajmitch> I wonder if the debian mirror I'm using is only half-updated
<cyberix> http://www.inari.fi/kunta/sosterv/itsehoito/31.unettomuus.gif
<cyberix> This is a brilliant picture
<ajmitch> please don't randomly spam urls in channel
<cyberix> Well, Ubuntu is UNIX based, and I've started to feel a sosial relation to this channel.
* ajmitch sighs
<cyberix> But I do admit that the image is not very important for universe to expand
<tseng> https://launchpad.net/malone/bugs/3768
<tseng> ajmitch: is this a 500 for you?
<Ubugtu> Error: Could not parse data returned by Malone: Connection to Malone bugtracker failed: The read operation timed out
<tseng> ajmitch: ( i cant believe we are pretending to switch to malone again )
<ajmitch> I think it's the DB server that's down
<tseng> i give it a week
<mr-russ> a week, what sort of project is this!
<ajmitch> ETA was 'at least 5-10 minutes' about 15 minutes ago
<ajmitch> mr-russ: excuse me?
<mr-russ> you get eta's cool.
* mr-russ just responding to tseng's comment.
<Nafallo> elmo is on it :-)
<thierry_> am I the only one that has problem getting on the ubuntu wiki?
<ajmitch> responses like 'what sort of project is this?' can really be taken the wrong way
<ajmitch> thierry_: see above
<Nafallo> thierry_: the DB server is down
<raphink> hello motus :)
<LaserJock> hi raphink
<raphink> hi LaserJock
<raphink> :)
<raphink> how are you doing ?
<LaserJock> good, busy
* Nafallo finds himself working on main-packages again ;-)
<LaserJock> raphink: I am trying to get my first package into Debian and I have been working on some MOTUScience stuff and I need to work on the Ubuntu Packaging Guide a bit too
<Nafallo> woohoo! xserver-xorg-input-synaptics builds on amd64 :-)
<raphink> ok
<raphink> I'll think I'll go to bed pretty soon :)
<raphink> full day ;)
<ajmitch_> joy
<lifeless> lp is back
<\sh> lifeless: what is changed?
<Nafallo> \sh: the database lives again ;-)
<\sh> oh a crash?
<lifeless> hardware issue - rectified.
<Nafallo> kewl :-)
<LaserJock> sweet LP works again
<psusi> hrm... the bins in this package are being built with -g, and I set the -k flag to dh_strip, but the package still doesn't contain the debug symbol files... is there another step needed to get them to be included?
<womble> psusi: Use --dbg-package instead.  Much easier.
<ajmitch_> morning womble
<womble> Hey ajmitch_
<psusi> womble: how do you use that?  don't you have to specify another binary target in the control file and give the name of that target to that option?
<psusi> sounded like -k would just add the symbol files to the main package when installed
<womble> psusi: See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315240 for an example of a patch to add a -dbg package
<Ubugtu> Debian bug 315240: "build a -dbg package" Package: libneon24, Version: 0.24.7.dfsg-2., Severity: wishlist, Maintainer: Laszlo Boszormenyi  http://bugs.debian.org/315240
<psusi> ty
<womble> Holy crap, I can't believe other people are using that bug as an example now  <grin>
<womble> psusi: Is -k not putting the symbols in /usr/lib/debug/wherever?
<psusi> looks like a very nice example
<psusi> and no, they aren't appearing in the package when I build it with pbuilder and dpkg -c it
<womble> psusi: fakeroot debian/rules binary in your source tree, and have a look in debian/$PKG/usr/lib/debug
<womble> and debian/tmp/usr/lib/debug
<womble> It's entirely possible that dh_strip is making the symbol files, but your build process isn't including the files in the final built package
<psusi> womble: that's what I'm thinking... what else needs to be in the build process to include them in the built package?
<womble> a dh_install or dh_movefiles to make sure they end up in debian/$PKG/usr/lib/debug/foo/bar/baz
<womble> This is the reason why we all use --dbg-package
<psusi> any special flags to those needed to get them to move the debug syms?
<womble> As the manpage says about -k: "--dbg-package is
<womble>  easier to use than this option, but this option is more flexible."
* psusi is converting to --dbg-package now
<psusi> isn't sig #32 used for posix aio?
<psusi> womble: damnit... the symbols aren't in the -dbg package either
<womble> psusi: Where are they?  stuck in debian/tmp somewhere?
<psusi> I dunno... I usually build with pbuilder... tyring the debian/rules binary ow
<psusi> now
<womble> I got hooked on pbuilder for a while, and had lots of the same sorts of problems -- "where the hell are my files?" so I've re-learnt the value of debian/rules binary (or debian/rules install in some cases, even)
<womble> Still rebuild using pbuilder for uploads, though.
<womble> And build-dep spec testing
<psusi> aye
* Kyral stretches
<Kyral> whee...my first CDBS package
<raphink> reverse compatibility with ifup/ifdown would have been a nice feature
<raphink> :s
<psusi> is there an easy way to create a temp file or other area you can store output in a bash script?  I've got a rather verbose script I'd like to modify so it stores teh output and discards it if no errors happened
<psusi> but dump it to stdout if something goes wrong
<psusi> womble: no debug syms in debian/$pkg
<womble> psusi: anything laying around in debian/tmp/usr/lib/debug?
<psusi> there is no debian/tmp
<womble> or in debian/$pkg-dbg?
<womble> Perhaps something is stripping your binaries before dh_strip gets at them?
<psusi> unless it's some other dh_ I don't see what... all the gcc lines have the -g
<womble> You can set CFLAGS=-g, but if the Makefile has a strip target in it's install or something, you're still toast
<psusi> how about dh_clean?
<psusi> don't see any strip commands
<womble> psusi: dh_clean isn't related
<psusi> last g++ -o -g is followed by the dh_ stuff
<womble> Comment out the dh_strip call in rules, rerun debian/rules binary, and see if the binary in the final location is stripped or not with file
<psusi> ok
<psusi> does dh_installdirs need any arguments for the syms?
<psusi> son of a bitch... they are stripped
<psusi> unless... it didn't appear to rebuild them when I re ran rules binary
<psusi> just did the dh stuff over
<Kyral> hmm....
<Kyral> which section...
<psusi> eh?
<Kyral> this
<Kyral> http://www.gnomefiles.org/app.php?soft_id=1235
<womble> psusi: You didn't run debian/rules clean before rebuilding?
<psusi> no.. just did that... wish I could just rebuild the binaries though... the objects all had syms
<psusi> waiting for the full rebuild now
<psusi> where exactly does dh_strip put the symbols?  is another step required to put them in the installed dir?
<Kyral> whats the package for pyGTK 2.6?
<crimsun> I don't know of one for 2.6, but there's python2.4-gtk2, which is for 2.8.2
<Kyral> yah
<Kyral> I meant >= 2.6
* Kyral <3 CDBS
<Kyral> ...*STAB!&
<Kyral> I put python2.4-gtk as a build dep are you blind...grr
<Kyral> its failing because it says it needs PyGTK 2.6
<Kyral> or greater
<crimsun> you b-d on the -dev, package.
<crimsun> python-gtk2-dev
<ajmitch> crimsun: is that really needed?
<crimsun> I don't know what prog he's trying, so I don't know :)
<ajmitch> I guess it could have the .pc file..
<ajmitch> /usr/lib/pkgconfig/pygtk-2.0.pc
<ajmitch> might be the only thing worth using
<ajmitch> hm, probably not
<Kyral> wait...in Depends if its Python don't I need to include soething else?
<ajmitch> that looks like something for linking with pygtk headers
<ajmitch> Kyral: depends on how badly you're mangling this
<Kyral> I'm not
<ajmitch> sure
<Kyral> I just hit it with dh_make as cdbs and used the python-distutils thing
<Kyral> BTW its this
<Kyral> http://www.gnomefiles.org/app.php?soft_id=1235
<cyberix> Kyral: I wonder how you pipe commands with such.
<Kyral> huh?
<cyberix> ls | grep `echo music`
<Kyral> such what?
<cyberix> How do you tell everygui to do that
<cyberix> :-)
<Kyral> I dunno
<Kyral> I can't even get the damn thing to build
<cyberix> Oh
<Kyral> Today is the first I saw of it lol
<cyberix> But the idea is good
<Kyral> I loaded my Google Home with the GnomeFiles.org RSS feed and it looked interesting
<Kyral> I'm wondering why it doesn't like me
<cyberix> Enought preconfiguration for commands and it could be really usefull
<Kyral> yah
<Kyral> if it would build...
<Kyral> *Stab*
<Kyral> should I just pastebin the control file?
<ajmitch> or you could get it working ;)
<Kyral> I would if I knew how
<Kyral> I have the right deps
<Kyral> that I can see
<thierry_> what is the package for  X11 headers files ?
<crimsun> anything more specific?
<crimsun> there are a slew of them...
<crimsun> (e.g., x11proto*)
<thierry_> crimsun : well that's what the speeX apps says it's needed... http://www.gnu.org/software/speedx/speedx.html
<thierry_> speedX*
<hub> anyone packaging gnash?
<bmonty> hub: does it make sense to package gnash?
<bmonty> according to their website it is still in development
<hub> does it make sense to not package it?
<crimsun> it certainly doesn't make any sense for Dapper.
<crimsun> Perhaps feasible for Dapper+1, though.
<bmonty> I don't think it is ready to be packaged
<hub> but I was just asking
<hub> because dholbach bet me for two packages recently
<hub> so I was wondering if I should
<bmonty> hub: in my opinion, I would say no
<bmonty> but that is my opinion
<crimsun> (and I've already stated my stance)
<\sh> hey zakame
<thierry_> if a app is free but not opensource, is it packageable?
<crimsun> generally, no.
<thierry_> k
<crimsun> and if it's not open-source it really isn't DFSG-free at all, which precludes it being in universe at all.
<thierry_> k
<zakame> gaah, non-free
<hub> multiverse?
<zakame> hm I do believe we try to minimize uploads to multiverse, right?
<crimsun> it might be able to go into multiverse depending on the licensing.
<zakame> ah
<poningru> thierry_: what do you mean free but not open source?
<poningru> thats not possible
<poningru> if its free by definition it has to be open source
<zakame> poningru : free as in free beer
<poningru> oh
<poningru> OH
<poningru> my mistake
<\sh> zakame: what about njam...there is one guy who wanted to package it
<zakame> \sh : it's already in Debian's NEW queue
<\sh> zakame: i didn't see it in incoming :)
<thierry_> crimsun : Can I package if the compilation is only made with gcc and a .c file
<zakame> \sh : http://ftp-master.debian.org/new.html
<crimsun> thierry_: sure, you can package it for yourself. Whether it can be distributed in multiverse is another decision altogether. I will cite precedence, however, that more than likely it's acceptable: see eagle.
<crimsun> thierry_: it really depends on the license.
<\sh> zakame: oh well..not build right now..do you actually know if he took our package?
<zakame> \sh : if nothing happens by next week I'll ping him and ask politely ;)
<minghua> \sh: since you've been uploading qt3...  do you know what those "src/.moc/debug-shared-mt/*.moc" files in qt3's .diff.gz are for?
<\sh> minghua: yes...shit from me....I'm cleaning it up somehow...
<zakame> bbl
<minghua> zakame: any words on the octave2.1 sync?  maybe time to ask again? ;-)
<minghua> crap, I missed zakame
<zakame> minghua : none yet
<crimsun> minghua: I asked yesterday
<minghua> \sh: thanks :-)  I was just reading the diff (curious about the immodule patch) and found that out accidentally
<zakame> gaah, elmo's gonna be mad
<crimsun> minghua: I presume it's in elmo's queue; otherwise I'll refresh when I send him my next batch of syncs
<zakame> anyhow, bbl :)
<crimsun> 8 days til UVF.
<minghua> crimsun: thanks, I hope one inquiry per week won't make elmo mad :-)
<martinex> hello - anyone?
<crimsun> martinex: hi
<martinex> crimsun, hi... I got a problem
<martinex> crimsun, and sorry to bother 'cause it should be #ubuntu thing...
<martinex> crimsun, but... I just would like to ask if is there any known issue with new dapper kernel?
<martinex> crimsun, and/or bind/dns libraries?
<\sh> martinex: what exactly? every bug about kernel and/or bind you will find in our bugzilla
<martinex> crimsun, I apt-getted my dapper yesterday and now it seems to work... but partially - it hangs on "detecting hardware"
<martinex> and if I hit Ctrl-C than I can boot
<martinex> but then network connections doesn't work
<martinex> and I downloaded current install/live DVD from 20060110
<martinex> then installed fresh breezy... network started
<martinex> but I just wanted to use breezy as a base for dapper
<martinex> so I changed repositories in sources.list - and apt-get dist-upgrade - it installed packages mainly from current DVD
<martinex> and few from network (kernel image)
<martinex> then after reboot - kernel hangs on "detecting hardware"
<martinex> propably related to #21752
<\sh> ok...i'm off to bed...
<ajmitch> looks like it - doing the same on the laptop
<ajmitch> except if I wait it does proceed
<LaserJock> hi minghua
<minghua> Hi LaserJock
<ajmitch> minghua: reboot worked for you? ;)
<LaserJock> I sent a Request For Sponsor today
<hub> for sponsor for what?
<minghua> ajmitch: yeah, :-)  didn't know which upgrade asked for the reboot, though, perhaps udev
<psusi> I'm trying to make sure that if any part of this shell script fails, it exits immediately rather than try to continue... I do set -e, but it looks like foo | bar is considered not to fail if foo fails but bar does not..
<ajmitch> minghua: latest udev/initramfs/kernel is causing issues for me & others, so it's an older kernel for me still
<psusi> any way to fix that?
<minghua> hub: I think some gtk frontend of gnuplot
<martinex> ajmitch, so you can confirm that there is some kind of problem with new kernel?
<ajmitch> martinex: no
<LaserJock> hub: plotdrop
<ajmitch> martinex: I cannot say that it is the kernel
<martinex> ajmitch, btw - how long do you need to wait?
<ajmitch> I waited less than 30 seconds
<minghua> ajmitch: kernels after -9 seems to have been serving me well :-)
<ajmitch> minghua: I suspect udev in this case anyway
<martinex> ajmitch, and network interfaces are ok?
<ajmitch> martinex: no
<psusi> oh wait... it isn't becaus eof the pipe... hrm..
<ajmitch> this isn't really the place for it
<ajmitch> since it's not universe
<psusi> FOO=`foo`... foo fails and returns non zero... set -e is in effect, yet the script continues...
<psusi> hrm...
<martinex> ajmitch, so.. #ubuntu-devel?
<ajmitch> psusi: probably because the assignment still works
<psusi> ajmitch, but the `foo` fails?  any failure should fail the whole script with set -e no?
<minghua> ajmitch: yeah, my feeling is that udev is more error prone, too.  although I've never digged deep, if it doesn't boot, I go back to the old kernel :-P
<ajmitch> psusi: I would have thought so, but probably not
<ajmitch> psusi: test with FOO=`/bin/false`
<psusi> ohh my... it seems that `foo` was returning 0.. even though it failed... hrm... yet another patch for pktsetup it seems
<ajmitch> heh
<ajmitch> bad program
<martinex> ajmitch, anyway just please tell me - your laptop can boot if you will wait about 30 sec.. on "detecting hardware" and then everything is ok? ( are network interfaces up and running correctly?)
<ajmitch> martinex: I said, no
<martinex> ajmitch, heh then I got the same problem...
<ajmitch> I can see that
<martinex> ajmitch, although I waited about 4-5 minutes and nothing happens
<martinex> ajmitch, I had to hit Ctrl-C to boot (but without network.. it doesn't make any sense)
<bmonty> hi LaserJock, ajmitch
<martinex> ajmitch, anyway - thanks for info
<martinex> off to bed
<bmonty> a simple reboot solves most of my problems after a kernel upgrade....except for blutetooth which hasn't worked since a couple upgrades back
<ajmitch> hey bmonty
<ajmitch> I'd *love* it it people on the forums used malone instead of just reporting bugs solely on the forums
<bmonty> ajmitch: I fear that is a symptom of how people are used to using the internet
<ajmitch> sadly
<bmonty> they understand forums and not the bug tracking systems
<ajmitch> yep
<ajmitch> and they expect everyone else to see their feature requests, bug reports & general whining
<bmonty> it would be nice if there was a "Report a bug in this application..." option on the help menu
<ajmitch> umm
<ajmitch> there isn't? :)
<bmonty> the isn't on my dapper install
<ajmitch> there should be for apps built with the launchpad integration
<LaserJock> hi bmonty
<bmonty> hey LaserJock
<ajmitch> the 'how to file bugs' topic on the forums is amazingly complex
<ajmitch> including rebuilding the packages with debugging symbols
<ajmitch> and using gdb
<bmonty> yeah getting a non-devel type to rebuild a package with debug symbols is realistic :)
<bmonty> I haven't looked at the forums in a long time
<ajmitch> I do when I'm feeling particularly masochistic
<bmonty> though I noticed that typing "ubuntu" in google will almost always get you a forum link on the first page
<ajmitch> the forums are incredibly popular
<ajmitch> and full of lots of bad info at times
<bmonty> the forums are not run by canonical, right?
<ajmitch> no, they're not
<ajmitch> they are 'official' though
<bmonty> irc is definately not as sexy as the forums though :)
<ajmitch> no, it's not
<bmonty> ok, the "Get help online..." option links to launchpad (I tried from xchat), but it definately isn't what I would call user friendly
<bmonty> oh well...time for bed, good night everyone
<LaserJock> what app would I use to see what ports are open on a remote computer?
<Kyral> nmap?
<Yagisan> LaserJock: nmap definitely. Worls on i386 - amd64 version seems flakey
<LaserJock> k, I'll try that. It seems that every time I try to do something my university network has the ports blocked
<Yagisan> s/Worls/Works
<Kyral> but ehh
<Kyral> be careful lol
<LaserJock> so I wan't to know which ones are and which ones aren't
<Yagisan> LaserJock: nmapfe for graphical. BTW - We can detect you scanning with it
<LaserJock> hmm, we maybe I could just talk to our admin and see if he can tell me
<Yagisan> LaserJock: I use it for work :) so I'm familiar with it
<Yagisan> LaserJock: when I get back soon, feel free to ask me questions about it - like how to be stealthy about it
<Yagisan> be back soon
<LaserJock> well, right now I just want to be able to download a .torrent
<LaserJock> it used to work but now it looks like it is blocked
<Kyral> a lot of colleges block Torrents
<Kyral> Most use an adaptive thing
<Kyral> believe me I know
<crimsun> many universities use packeteer
<crimsun> ours was one of the first, unfortunately
<LaserJock> I hate that. I have to use a different port for chat, I can't get .torrents of linux isos
<LaserJock> at least I can still ssh in
<crimsun> do you have an external shell?
<crimsun> I have ssh tunnels running everywhere. Yay for holes in the 'wall.
<Kyral> anyone ever have Irssi not backspacing when run in Screen?
<LaserJock> what do you mean by external shell?
<LaserJock> Kyral: I don't think so
<Kyral> hmm
<Kyral> its odd
<Kyral> if I run Irssi normally I can backspace
<Kyral> but if I run it in Screen I cannot
<ajmitch> Kyral: sounds like a question for #ubuntu ;)
<crimsun> sounds like your termcap is screwed, echo $TERM
<Kyral> yah I was just field it here before I go into the maelstrom
<ajmitch> as is probably safe
<crimsun> LaserJock: a host accessible via ssh outside your uni's firewall
<ajmitch> Kyral: you could always ask on the forums
<Kyral> crimsun: its set to xterm
<LaserJock> crimsun: don't know, I only have windows on the outside. I was able to do vnc over ssh though.
<Yagisan> re
<Yagisan> LaserJock: use port 443, for your torrent
<veganpops> https://launchpad.net/distros/ubuntu/+source/cernlib/+bug/6588
<Ubugtu> Malone bug 6588: "PAW - Segmentation violation - Traceq lun = 0, level = 99" Fix req. for: gcc (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6588
* Kyral hmms
<Yagisan> LaserJock: Azureus works - and 1) it's not blocked on most networks, 2) its not throttled
<Kyral> crimsun: should my $TERM be xterm?
<veganpops> Following the guidance of the original Debian package maintainer I fixed a serious bug in the cernlib [universe]  packages.
<veganpops> How do I go about getting this fix propagated into the official versions?
<Kyral> file a bug
<Kyral> attach debdiff?
<veganpops> I did, see above.
<veganpops> debdiff?
<crimsun> Kyral: xterm should suffice. Are you doing anything odd in screen?
<Kyral> crimsun: nope
<Kyral> I just do screen irssi
<veganpops> All of the fixed Breezy packages are in http://renfield.physics.utah.edu/cernlib.tar.bz2 (44 MB)
<Kyral> brb, gonna restart in screen
<crimsun> gcc-3.3?
<crimsun> ugh. doko ain't gonna like that.
<Kyral> Gak I see it
<veganpops> crimsun: I know, the bug affects all gcc up to and include 4.0.1
<Kyral> somehow Backspace isn't sending ^H
<Kyral> while in screen
<crimsun> Kyral: hmm, it works here?
<Kyral> crimsun I set Backspace to send ^H in xterm prefs
<crimsun> Kyral: try ``TERM=vt100 screen irssi''
<veganpops> crimsun: The original maintainer says it is fixed in 4.0.2??
<Kyral> okay brb
<crimsun> gcc version 4.0.3 20060104 (prerelease) (Ubuntu 4.0.2-6ubuntu1)
<crimsun> root@mika:/#
<Ubugtu> Error: Could not parse XML returned by Ubuntu: not well-formed (invalid token): line 189, column 1
<crimsun> not an issue in Dapper
<veganpops> crimsun: True - it should be OK in Dapper.
<Kyral> nope
<crimsun> Kyral: as in "still doesn't work"?
<Kyral> crimsun: doesn't work
<crimsun> sounds like an xterm boog
<Kyral> I had to set XTerm to interpret Backspace as ^H
<crimsun> (I use rxvt-unicode-lite myself)
<Kyral> but why would it only take effect when Screen runs?
<crimsun> no idea
<crimsun> are you using Dapper's xterm?
<Kyral> yah
<Kyral> hmm
<Kyral> lemme see what $TERM is in screen
<Kyral> ...its echoed as "screen"
<LaserJock> Yagisan: you sure about port 443 ?
* Kyral isn't sure to file a bug on XTerm or on Screen
<Yagisan> LaserJock: should be https port IIRC
<Yagisan> LaserJock: it's like running it out port 80
<LaserJock> oh, ok
<Yagisan> LaserJock: my isp seems to throttle torrents, so I run them over other ports
<Yagisan> Yagisan: they need to do layer7 filtering to stop your torrent, if you run over a standard port
* Yagisan really needs to type better. LaserJock ^^^^^
<Kyral> hmm
* Kyral thinks about writing a GUI for PBuilder....
<LaserJock> why?
<Kyral> Dunno
<Kyral> for those GUI oriented developers?
<Kyral> (Yes they exist)
<Yagisan> Kyral: would that support multiple pbuilders ?
<Kyral> Yagisan: yup yup
<Kyral> I just need to learn PyGTK first lol
<crimsun> Kyral: screen, if xterm -e irssi  works fine
<Kyral> xterm -e?
<Yagisan> ooh, I feel silly now. How do I filter out [ and ]  with sed ? It thinks they are special characters, and I want them to be treated literally
<Kyral> \[?
<Kyral> what does xterm -e do?
<LaserJock> arghhh, stupid torrents :(
<Yagisan> Kyral: nope. Didn't work. s/[[] //g got rid of the first one though
<Yagisan> Kyral: fixed it with a two pass sed
<Yagisan> LaserJock: still not going ?
<LaserJock> no, I get NAT error
<LaserJock> I think I will just give up and use windows at home even though it's a DSL connection
<Yagisan> LaserJock: you can't get incoming connections ?
<LaserJock> oh, maybe it is
<Yagisan> LaserJock: the little yellow face is ok. not ideal, but ok. eg right now on 3 torrents I'm doing, I have yellow faces, but I know there no nat error, as sometimes they turn green (assuming you use azureus)
<Yagisan> G'day zakame
<zakame> heya Yagisan :)
<psusi> well.... this is a shitload of fun
<psusi> I blew up my dvd/rw drive tonight
<LaserJock> Yagisan: I just have a black face
<Yagisan> psusi: how ?
<psusi> I was working on the packet cdrw stuff, trying to get it all plug and play with hal and everything
<Yagisan> LaserJock: that means you have not started the torrent
<psusi> and it started getting a bunch of IO errors
<Yagisan> psusi: power off, let it cool down, try again
<psusi> so I shutdown and reboot, and now the drive is toast... put in any cd media... cdrom, cd-r, cd-rw, and it pukes
<psusi> tried that
<psusi> it makes funny noises and finally reports no media
<psusi> though.. and this is the really fucked up part...
<psusi> it plays dvds fine
<Yagisan> psusi: oh - reflash firmware - see if that helps
<psusi> did that... no dice
<psusi> even had to boot into windows for that one
* psusi shivers
<Yagisan> psusi: how old is the drive ?
<psusi> my windows install is all kinds of fucked up
<psusi> made in oct 2004
<psusi> I already sent in the request for an RMA
<psusi> we'll see what happens
<Yagisan> psusi: is it under warrenty ? put on a sweet face and say - "I won't read cd's"
<Yagisan> *It
<psusi> I don't get how it plays dvds fine, but when you put in a cd, it starts making "oh-no" sounds
<psusi> Yagisan, yep... I did that... hopefully will find out tomorrow if it is under warrenty
<Yagisan> psusi: laser may be stuffed. drive should two lasers, 1 for cd, 1 for dvd
<psusi> I thought so...
<psusi> seems the cd one burned up
<LaserJock> Yagisan: hmm, well somehow the iso got downloaded from something I did
<LaserJock> Yagisan: maybe it wasn't azureus though, I have tried a bunch of things
<psusi> I need to build a new machine soon... this one is 2 years old now... blew out the dvd/rw... keyboard randomly craps out and I have to unplug and replug it... windows install is 9 kinds of fucked
<Yagisan> psusi: many years ago, I was a hardware tech. It wasn't uncommon for a laser to die
<Yagisan> LaserJock: as long as it works, it's fine ;)
<LaserJock> Yagisan: yeah, I just wish I knew what worked :-)
<psusi> Yagisan, I've never seen a cd drive go bad before... I've not seen it in some time now, but back around 1994 I got oen fo the first 4x cdrom drives on the market... mitumi...
<Yagisan> psusi: I still use pentium 2's here
<psusi> in 1996 I used it in an old machine to setup up a bbs
<psusi> the pc speaker had been torn off, and the wires accidently brushed up against that drive
<psusi> made a nice light show and a burn on the drive
<psusi> it was still working in 2000
<Yagisan> psusi: heat and humidity tend to break cd/dvd drives most often. I've had quite a few die like that
<psusi> I live in Florida.... heat and humidity are my breakfast and lunch ;)
<psusi> I wish I could debug the firmware in the damn drive... I hate firmware... allways screws the pooch as soon as something unusual happens
<psusi> in my last computer I had a plextor plexwriter 4x cd-r... scsi... once I tried to overburn a cd by a wee bit too much and it just freaked out
<psusi> kept seeking the head and wouldn't respond to commands from the os
<psusi> or the eject button
<psusi> finally I just reached into the case and pulled out the power cord from the drive
<psusi> holy shit
<psusi> it isn't even worth it to repair this thing... newegg has an even nicer drive for only $42!
* Yagisan wonders if one of my p2 systems would be better then my standalone mpeg4 player, as a htpc
<cyle> anybody out there?
<lucas> yes
<ajmitch> barely
<cyle> * hears crickets *
<cyle> i was on here last weekend
<cyle> i got my pgp key, started my wiki page
<cyle> joined ubuntu-devel mailing list
<cyle> but was never able to pick a package to start working on
<lucas> ah
<lucas> what do you want to do ? merges/syncs ? packaging ?
* ajmitch will bbiab, cannot look at screen any longer :)
<cyle> merges are bringing over debian packages right? i wouldn't really wanna do that
<cyle> preferably packaging
<lucas> you want to start reading http://wiki.ubuntu.com/MOTU
<lucas> and ask questions if you don't understand something, so we/I can improve the wiki
<cyle> i looked at that quite a bit last weekend
<cyle> i've been over the debian developer guides too
<lucas> ok
<lucas> if you want to start packaging, pick up a package on the UniverseCandidates page
<lucas> package it
<lucas> upload it to REVU
<lucas> but I personally feel that the most noble part of MOTU work is merging, not packaging (we should fix the existing before considering the new)
<cyle> what types of problems get fixed in merging?
<lucas> read https://wiki.ubuntu.com/MOTUMerging
<cyle> i understand what it's saying
<cyle> but there's a lot that seems like you would have to know some history about what's going on to understand
<cyle> like regarding gcc4 patches
<cyle> gl/glut patches
<cyle> doesn't say what the glut patches are
<lucas> ok
<lucas> usually, you just pick a package from the merge lsits
<lucas> and see if the ubuntu patches are still necessary
<lucas> so knowing exactly how to fix gcc4 problems isnt mandatory
<cyle> what kinds of reasons do we do ubuntu specific patches
<lucas> read "Some reasons for divergence between Debian and Ubuntu"
<lucas> on MOTUMerging
<lucas> and follow the "this thread" link
<cyle> duh
<cyle> i skipped right over that link
<lucas> edit the page to make it more visible ;)
* Hobbsee pictures the page with that section in massive font, aka backports forum style
<cyle> so the gcc4 thing
<cyle> is it a dapper requirement that all packages compile with gcc4?
<lucas> yes
<cyle> so if for some reason debian's package can't do so we will make a patch/apply a patch for it?
<lucas> exactly
<cyle> one thing i noticed
<cyle> in dapper, there's no stable 1.5 firefox, is this because debian hasn't put out a 1.5 stable package?
<lucas> I dunno
<lucas> firefox is main, not universe
<cyle> i know that
<cyle> it was more of a question about how that works
<lucas> there was a thread about a firefox/epiphany debate on ubuntu-devel
<lucas> but I haven't read it
<cyle> will we ever package a newer version of an app than debian does?
<lucas> since it went into the usual vi/emacs stuff
<lucas> sometimes
<siretart> WAAAAH. whats going on with tiber?!
<lucas> there are several packages in this case
<siretart> morning folks
<cyle> i saw that, they basically told the guy he's an idiot and firefox will continue to be the main browser
<lucas> hi siretart
<lucas> siretart: dunno, it has been down for ~30 minutes I think
<siretart> lucas: lets hope it is 'just' a broken router
<cyle> and my understanding is that right now breezy packages will not be updated right?
<cyle> so like if dapper ships with firefox 1.5, it will never be updated with firefox 1.6
<siretart> cyle: well, the main reason why we don't is lack of ressources
<siretart> cyle: and we want 'stable' releases, so we are very very carefully when updating releases
<cyle> i understand that, most users don't care about having the latest and greatest, as long as what they have works
<siretart> for newer crack, we have ubuntu-backports
<lucas> somebody has an example of a wiki page with an image ?
<siretart> lucas: the tracelog output makes me think this is a router misconfiguration (I see a packet loop)
<cyle>  is there a guide to making a source package on the wiki
<cyle> i've packaged binaries before
<cyle> but never had to do a source package
<lucas> siretart and others: can you comment on https://wiki.ubuntu.com/MOTUMeetingTeamReorg
<siretart> lucas: I don't quite get the arrow directions. what do the arrows say?
<siretart> ah
<siretart> lucas: hm. I have some concerns about it, but I need to think about that.
<lucas> ok, np
<siretart> my biggest concern is this: what happens with administrative emails to the 'leaf' teams, e.g. MOTUReviewers. if someone tries to join MOTUReviewers ALL but MOTUMergers get spammed with the request to join
<lucas> no, only the admins of MOTUReviewers
<lucas> (who can be ogra + dholbach for example)
<siretart> lucas: ok, in this case, could you please be more verbose in the diagramm not only on membership but also on maintainership? (e.g. which group administers whom and which group is maintained by whom)?
<lucas> also the teams can be set as 'Restricted teams'
<lucas> ok
<siretart> thanks
<lucas> siretart: I added a note about maintainership
* ..[topic/#ubuntu-motu:irc.freenode.net] : Ubuntu Masters of the Universe: Ubuntu Universe Repository Maintainers | http://wiki.ubuntu.com/MOTU | http://wiki.ubuntu.com/MOTUTodo | How To Track Merge Status -> https://wiki.ubuntu.com/MOTUToMerge | Grab your merge here: http://tiber.tauware.de/~sistpoty/MoM/index.py?state=new | sign up for ubuntu-motu@lists.ubuntu.com now!
<lucas> cool
<crimsun> gah, merging never ends!
<lucas> crimsun: nice job on flashplugin-nonfree
<dholbach> hello MOTUs!
<siretart> huhu dholbach
<lucas> hello dholbach
<crimsun> siretart: please remove ax25-tools from the merge list; I merged it yesterday before looking at the page today
<dholbach> hey siretart, lucas!
<dholbach> it's the HUG DAY! :)
<lucas> dholbach: when you'll have had breakfast, you can read and comment on https://wiki.ubuntu.com/MOTUMeetingTeamReorg ;)
<dholbach> lucas: what will effectively change?
<dholbach> lucas: apart from organisational launchpad representation
<dholbach> lucas: i mean, it *looks* nice :)
<lucas> dholbach: lots of people removed from some teams and added to others
<siretart> lucas: great job on the MergeNOTES wiki page. I assume you update your scripts from that wiki page via cron?
<lucas> it would mean that, for example, motureviewers would have no direct members
<lucas> same for motu
<siretart> I slowly recover from my vacation and operation :)
<lucas> siretart: yes (it is MOTUNotes)
<dholbach> siretart: operation? what happened? how are you?
<siretart> dholbach: it was an incarnated nail in the foot, nothing serious (but painful)
<siretart> I'm fine and back now :)
<StevenK> An ingrown toenail? I've had that operation done to both my feet.
<Treenaks> "Legacy code"
<StevenK> When you said nail, I thought nail, like the one you hammer. :-)
<dholbach> siretart: i'm glad to hear you're fine
<siretart> StevenK: oh. yes, its a toenail. we don't differ that much in german. :)
<StevenK> Well, I thought a nail in the foot, like you stood on one.
<dholbach> lucas: i'll have to review it in-depth - because it's not just "membership", it's also "assigned bugs, ..." - maybe we should talk to the launchpad guys about this
<dholbach> lucas: it's also about polls on launchpad and so on
<lucas> yup I know
<lucas> should I raise the issue on ubuntu-motu ?
<siretart> and support requests
<lucas> and cc launchpad-something ?
<siretart> lucas: I think that would be best
<dholbach> yes
<Yagisan> ajmitch: around ?
<dholbach> so who will be involved in today's BUG DAY? :)
<Yagisan> I can find bugs
* Yagisan looks at linguaplone right now
* Yagisan wonders why it isn't in plones Add/Remove Products like the readme says
<lucas> dholbach: I really have to do some real life work today
<dholbach> lucas: good luck and 'Bon courage!' with that :-)
<dholbach> about the bug day: it'd be great if we could make an effort to go through 'motu' bugs and see if new upstream versions fix the bugs, because as you might know: UpstreamVersionFreeze is in 8 days already
<dholbach> so i think this is a great time to get started on this
<Gloubiboulga> dholbach, I'd like to help on this, could you tell what to do, or give an url where I could find explainations
<dholbach> http://launchpad.net/people/motu/+assignedbugs has the motu bugs
<dholbach> for some of them we could investigate, if a new upstream version of the package fixes the issues mentioned by the reporters
<dholbach> if you have trouble doing this, just ask here
<Gloubiboulga> ok
<Gloubiboulga> 'new upstream version' means already packaged version I guess ?
<dholbach> the debian/copyright of the package in question should have the place it was downloaded from
<dholbach> no, upstream version
<dholbach> (version from the authors)
<Gloubiboulga> oh, ok
<martinex> hi all
<martinex> is there any way to track changes in dapper repository without apt?
<dholbach> read the dapper-changes mailing list
<martinex> my dapper is currently unworkable ... I can boot but it hangs on 'detecting hardware' part and can boot after Ctrl-C but unfortunately without network interfaces configured at all
<martinex> so it is pretty hard to fix it without network...
<dholbach> do you have "auto eth0" in /etc/network/interfaces=
<dholbach> ?
<dholbach> or whatever device it is?
<martinex> dholbach, everything is configured properly
<dholbach> does the network driver not get loaded automatically?
<martinex> dholbach, as I said before - it doesn't want to work because dapper hangs on "detecting hardware" and I got to skip it with Ctrl-C
<dholbach> you tried a different kernel?
<martinex> dholbach, well kind of
<martinex> dholbach, I tried breezy
<dholbach> did that work?
<martinex> dholbach, I just installed fresh breezy on /
<martinex> dholbach, then changed repos in apt and dist-upgraded to dapper
<dholbach> and then?
<martinex> dholbach, same thing again - hangs and no network
<dholbach> *Strange*
<dholbach> can you modprobe the driver and ifconfig eth0 up?
<martinex> dholbach, and I'm not alone with this problem .... ( I think so) take a look at #21752
<dholbach> you maybe should follow up on the bug in #ubuntu-kernel
<martinex> dholbach, ok... but I'm not sure if it's kernel bug
<dholbach> yeah, might be udev/... too
<martinex> dholbach, anyway I'll reboot (I'm on my favourite 'windows' now) and try again
<dholbach> ok
<martinex> dholbach, but I just would like to find some info if something changed in packages that could be cause of this problem
<martinex> dholbach, since yesterday...
<dholbach> dapper-changes mailing list might be helpful
<martinex> dholbach, reading now
<martinex> hmm no changes in kernel and udev...
<martinex> reboot and'll see
<Gloubiboulga> dholbach, if a new upstream release fixes the bug, what do I need to add/change on the malone page ?
<dholbach> Gloubiboulga: best thing would be to package the new version and add the revu link to it, maybe subscribe motureviewers team as well
<dholbach> well done, which packages is it?
<Gloubiboulga> eagle-usb, malone 3314
<Ubugtu> Malone bug 3314: "usb (Ubuntu) - no connection to internet" Fix req. for: eagle-usb (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Unconfirmed http://launchpad.net/bugs/3314
<dholbach> great
<martinex> dholbach, unfortunately it doesn't want to work
<martinex> dholbach, but it propably isn't kernel bug
<martinex> dholbach, because I got breezy kernel on this machine too, and this kernel hangs just like this from dapper
<dholbach> martinex: unfortunately i'm not a kernel/hardware/udev/... guru - you'd better ask the #ubuntu-kernel guys, they might know about the bug, if you ask them
<martinex> dholbach, unfortunately modprobe didn't work too
<ogra_ibook> its a known and announced udev regression
<martinex> dholbach, I had to modprobe [myNICmodule]  right?
<ogra_ibook> but modprobing the driver and ifupping the interface should works
<ogra_ibook> -s
<martinex> ogra, I did it
<martinex> ogra, modprobe 8139too
<ogra_ibook> whats the eroor if you do this ?
<ogra_ibook> *error
<martinex> ogra_ibook, there is no error....
<martinex> ogra_ibook, but then
<ogra_ibook> so it gets loaded fine
<martinex> ogra_ibook, I did mii-tool
<ogra_ibook> does it show up in lsmod ?
<dholbach> dmesg | tail
<ogra_ibook> why ?
<martinex> ogra_ibook, yes it was in lsmod
<ogra_ibook> fine
<martinex> ogra_ibook, but mii-tool said that: SIOCGMIIPHY on eth0 failed
<ogra_ibook> so if you ifup it, it doesnt come up (without playing with the physical layer with mii-tool) ?
<martinex> ogra_ibook, no MII interfaces found
<ogra_ibook> does it come up with: sudo ifup eth0 (forget about mii-tool for now)
<martinex> ogra_ibook, ehhh I got to reboot again to test it ;)
<ogra_ibook> try it
<ogra_ibook> it should work
<martinex> ogra_ibook, could you tell me what should I do to make it workable before reboot?
<martinex> ogra_ibook, modprobe [module]  ?
<martinex> ogra_ibook, and then ifup eth0 ?
<ogra_ibook> the module should be loaded on boot already, check with lsmod
<martinex> ogra_ibook, (forget sudo part because I'm lazy and I always do sudo -H -s ;) )
<ogra_ibook> its only the upping of the iface that fails afaik
<martinex> ogra_ibook, it wasn't
<martinex> ogra_ibook, I verified this with lsmod and dmesg | grep eth or dmesg | grep rtl
<martinex> ogra_ibook, maybe it's because I have to hit Ctrl-C to boot
<ogra_ibook> might be ...
<martinex> ogra_ibook, boot procedure hangs on "detecting and configuring hardware" (or something like this) and I got to Ctrl-C to boot
<ogra_ibook> how long did you wait before ctrl-c ing ?
<martinex> uuuh long
<ogra_ibook> and do you have any scsi adapter in this machine ?
<martinex> about 4-5 min
<martinex> ogra_ibook, well no, I don't
<ogra_ibook> scsi is set to wait up to 2 min for the devices to initialize
<martinex> ogra_ibook, only card reader connected via USB
<martinex> ogra_ibook, but I disconnected this when trying to find what is the problem
<ogra_ibook> anyway, if you dont get the iface up with modprobe and ifup, please file a bug, assigned to udev
<martinex> ogra_ibook, this card reader mounts 4 "drives" as sd....something I don't remember...
<ogra_ibook> yu can also try to get hold of Keybuk in #ubuntu-devel to debug this further if he has the time ...
<martinex> ok I'll try to reboot now and we'll see then
<martinex> thanks for help
<Gloubiboulga> dholbach, I've sent the package on REVU: http://revu.tauware.de/details.py?upid=1469
<dholbach> cool
<raphink> hi
<Gloubiboulga> salut raphink
<raphink> a roule?
<Gloubiboulga> yep :)
<raphink> cool :)
<raphink> hmmm
<raphink> grrr usbview has no MoM report
<raphink> :s
<StevenK> crimsun: Bah, you win again!
<raphink> hmm anyone with a PPC here?
<raphink> dholbach: you have a ppc ?
<raphink> ;)
<martinex> ogra_ibook, ping
<crimsun> martinex: he's in an Edubuntu meeting atm
<martinex> crimsun, ok...
<martinex> crimsun, thanks
<dholbach> raphink: no, sorry
<raphink> dholbach: ok ;)
<dholbach> i'm out for getting food - bbl
<raphink> hi btw dholbach :)
<raphink> ok
<Czessi_away> raphink: You can try to ask Amu (is in #kubuntu-devel) for ppc. he build kde 3.5 packages for ppc
<raphink> no it's fine
<raphink> :)
<raphink> thanks Czessi_away
<Gloubiboulga> hello thierry_
<thierry_> hi Gloubiboulga
<zakame> evening MOTUs :)
<Gloubiboulga> hi zakame
<zakame> heya Gloubiboulga
<thierry_> zakame : could you review my package, you already advocated it before but I had some changes to add, I changed the name, now it's libfxscintilla
<zakame> thierry_: link? :)
<thierry_> zakame : http://revu.tauware.de/details.py?upid=1459
* zakame checks
<thierry_> zakame : and the one you advocated http://revu.tauware.de/details.py?upid=1298
<zakame> thierry_: I think you don't need to have a versioned libfxscintilla17-dev, a libfxscintilla-dev should be fine
<zakame> wb Kaloz
<zakame> er Kyral
<Kyral> morning
<Kyral> well, this is interresting
<Kyral> gkrellm runs...but doesn't show up in X
<zakame> huh?
<thierry_> zakame : well the debiand librairy packaging guide says it's better and sistpoty toot
<thierry_> too*
<Kyral> I dunno
<zakame> thierry_: well, that would be so if you're willing to keep multiple versions of the same lib
<Kyral> X seems borked...wierdly
<zakame> in dapper/dapper+1
<thierry_> zakame : well I do, when the new version of the lib will be released, I'll add it
<thierry_> and anyway it had to follow the the SONAME no?
<zakame> thierry_: I presume you'll also notify persons building on your lib to chase transitions as well ;)
<zakame> for libfoo-dev not really
<zakame> thierry_: in debian/rules, isn't the lib built as shared?
<thierry_> yes
<zakame> then why the explicit --enable-shared?
<zakame> I think you can turn that off
<thierry_> zakame : I had big problems with .so files and the upstream author told me to do that anyway
<zakame> wb \sh :)
<zakame> thierry_: ah, k
<thierry_> zakame : so, if I change for libfxscintilla-dev, you advocate?
<zakame> thierry_: I could go on any way actually :) looks nice
<thierry_> k then I'll leave it this way to follow sistpoty tips
<\sh> re
<Kyral> Now there is a wierd hiccup
<thierry_> zakame : k then I'll leave it this way to follow sistpoty tips
<zakame> ok
<thierry_> zakame : so feel free to advocate anytime you want
<\sh> Czessi: ping
<thierry_> zakame : so I should only change Package: libfxscintilla17-dev to Package: libfxscintilla-dev and take off provides and conflicts
<thierry_> ?
<zakame> yes
<thierry_> k
<thierry_> zakame : rebuilding and I'll reupload
<Yagisan> \sh: ping
<\sh> Yagisan: pong
<Yagisan> \sh: you most likely have noticed wine FTBFS as 64bit native by now
<\sh> Yagisan: no i didn't because I never build it..but will do later this day
<Yagisan> \sh: oh - just a sec then
<\sh> I'm just coming home and had to sort out some more important stuff :)
<Yagisan> \sh: http://bugs.winehq.org/show_bug.cgi?id=4281
<Ubugtu> Error: Unknown bugtracker
<Yagisan> \sh: reported it yesterday. I spoke with #winehq
<zakame> bad Ubugtu
<\sh> Yagisan: glibc issue?
<\sh> in thread management?
<Yagisan> \sh: and they think wine64 would be ok if you just mv * *-64 all the binaries for the 64bit native build
<Yagisan> \sh: actually - they haven't written part of it - that's why it FTBFS
<\sh> Yagisan: hum? what they didn't write?
<\sh> glibc.c:56: warning: cast to pointer from integer of different size
<\sh> this is a nice one :)
<\sh> this would cause a nice segfault somehow...
<Yagisan> \sh: anyway - as 64bit native is currently a no-go, I was going to just finish off the wine32 package, and set normal wine to [!amd64] 
<Yagisan> \sh: unless you have other changes you'd like to do
<\sh> Yagisan: getting wine64 running
<\sh> if we go on with the amd64 adventure we should provide all possibilities...even 64bit wine for running non-existent win64 apps
<Yagisan> \sh: yes - but as that dosen't work, I was just going to comment that out in the rules file, until the next upstream release before trying again
<Yagisan> personally, I'd like to see all apps that can run on amd64, running on it, even if it is a 32bit compatibility app  - otherwise amd64 as an arch is a waste of time
<\sh> Yagisan: ok...move the 32bit stuff then into a wine64-compat package and create an empty wine64 package, with amd64 only so we have at least all preparations done for the ongoing project
<Yagisan> \sh: I have the package set up as wine = native compile, wine32 = 32bit compile. the rules are there, and just need a quick toss through pbuilder to make sure they work
<Yagisan> \sh: 1 issue is I need to work out what version wine is from inside debian/rules
<Yagisan> \sh: so I can correctly sed debian/files at build time
* Yagisan waits for pbuilder to finish
<\sh> Yagisan: check debian/changelog :)
<thierry_> zakame : could you readvocate? I uploaded the last change... this will probably be the last time you have to advocate it
<zakame> thierry_: yeah, just got the mail
<crimsun> would someone with main upload privs please request a sync from Sid of ttf-dejavu?
<crimsun> it's preventing me from diagnosing a bug report on cacti, because rrdtool is uninstallable due to the dependency on ttf-dejavu
<\sh> crimsun: did u test the fontpackage?
<\sh> I wonder why there is a ubuntu version of this
<crimsun> it's a -0ubuntu1 because of new upstream version
<thierry_> I need one more advocate to have my package accepted anyone who would like to review it? ajmitch maybe? http://revu.tauware.de/details.py?upid=1470
<\sh> and which version is the new sid package?
<thierry_> zakame : could you delete libfxscintilla1.6 and libfxscintilla17 entries please in REVY ?
<\sh> hehe...2.1-1
<\sh> crimsun: you have to merge it manually
<\sh> crimsun: i think we have a different orig.tar.gz for this version....as always with 0ubuntu1 versions
<zakame> thierry_: hm they're already archived, and I don't know how to delete ;)
<\sh> thierry_: just upload again :)
<crimsun> d'oh, it is a different tar.gz
<\sh> crimsun: as I said :)
<thierry_> \sh : upload what gain?
<\sh> crimsun: you don't mean the mail on ubuntu-users about "[Dapper-i386]  Package "cacti" error messages on install/uninstall & won't uninstall."
<\sh> thierry_: libfxscintilla*
<\sh> thierry_: if you need to
<crimsun> \sh: yes, that one
<thierry_> \sh : no no it just that I changed two times of package name so want that someone delete the old ones
<\sh> thierry_: will look into it...
<\sh> terminate called after throwing an instance of 'std::logic_error'
<\sh>  what(): basic_string::_S_construct NULL not valid
<\sh> Aborted
<\sh> crimsun: but this looks more like an dpkg or debconf problem
<crimsun> \sh: that's my impression, too, but I need to ensure it's not in my merge
<\sh> crimsun: what is the build error because of ttf-dejavu?
<crimsun> \sh: not a build error, an uninstallable rrdtool
<crimsun> \sh: which is another issue that puzzles me: the user _somehow_ got cacti to attempt to upgrade despite the unmet dependency in rrdtool
<crimsun> the whole thing just stinks of --force-depends and such
<\sh> crimsun: yepp
<\sh> let me fix librrd2 first
<crimsun> \sh: great, thanks
<\sh> crimsun: I move the build-dep towards our version, which should be the same somehow as debians, but 0ubuntu1
<crimsun> \sh: yep, that's sufficient
* Yagisan curses at firefox crashing while submitting website registration
<Nafallo> hehe, "to reproduce, try register some domains".
<Nafallo> :-)
<\sh> lol
* Yagisan counts his blessings that it died before actually transmitting the data, and not mid way through
<thierry_> is sunbird a too big package for cdbs?
<dholbach> thierry_: why should it be?
<thierry_> don't know... I tough cdbs was for small package only, anyway forget it, sunbird is far too complex for me
<thierry_> dholbach : but I have a package be reviewed, would like to do it? I need one more advocate and it's ok to upload
<thierry_> to be reviewed*
<dholbach> no, cdbs should not be the issue
<dholbach> about the review, not
<dholbach> about the review, please ask somebody else - i was just about to leave
<dholbach> sorry
<thierry_> k no problem
<thierry_> raphink : are you a MOTU?
<raphink> not yet ;)
<thierry_> slomo : could you review my package?
<raphink> ;)
<thierry_> siretart : could you review my package?
<psusi> what is this buisness about compatibility levels I read about in the man pages for the dh_ scripts?  how do you check/set which level a package is using?
<psusi> nevermind.... looks like compat contains a 4... that explains why dh_strip --dbg-package isn't doing what it should...
<Yagisan> \sh: I'm about to head to bed, hopefully only thing left to do with wine is my changelog sed foo. I'll finish testing tommorow. Do I send you a debdiff, post a debdiff to malone, or upload to revu for comments ?
<\sh> send me the debdiff
<LaserJock> when is the MOTU meeting?
<\sh> tomorrow?
<siretart> boah, finally my laptop is running dapper, after near endless struggle with 2.6.15
<siretart> only oops is broken like hell :/
<siretart> hi Fuddl
<Fuddl> hi siretart!
<Fuddl> siretart: how's your foot?
<siretart> Fuddl: better, thanks
<mgalvin> hi all, non-package question... i started working on DapperFlight3 and would like to mention some high level notes about some of the more significant *verse improvements, is there anything you guys would like to see mentioned? I looked through the various reports and such but thought i would just ask anyway
<Fuddl> siretart: that's good to year, hope you'll be as fast as usual, soon again ;)
<Fuddl> siretart: btw. /me bought some cheap but f**cking loud party-speakers. first try-out will be on schloss-lan *smiiiile*
<segfault> mgalvin: can you please ping me at segfault@ubuntu.com when its done? i'd like to translate it to pt_BR.
<mgalvin> segfault: sure
<segfault> thanks
<mgalvin> np
<Czessi> \sh: ping
<dholbach> hey Fuddl
<Fuddl> hi dholbach
<Fuddl> dholbach: wasn't it you, who had a quake3 loki cd?
<dholbach> Fuddl: no, i shouldn't think so :)
<Fuddl> ah ok.... but somebody spoke to me in this channel, he/she had problems with quake3-data, installing from the loki quake3 cd...
<Fuddl> who was it?!? HANDS UP! ;)
<Gloubiboulga> Riddell, could you have a look at http://revu.tauware.de/details.py?upid=1468 again when you hot time? Thanks
<\sh> Czessi: pong
<Riddell> Gloubiboulga: yes, but not just now so poke me again if I forget
<Gloubiboulga> Riddell, np
<Czessi> \sh: hi \sh
<\sh> Czessi: did you read the remarks on kiso?
<Czessi> \sh: in revu? yes i did
<\sh> Czessi: can u fix it? I have the ok from sistpoty to upload...he will advocate later :)
<Czessi> \sh: what must i fix? http://revu.tauware.de/details.py?upid=1464 the lintian overwrites?
<\sh> Czessi: 1. the orig.tar.gz is changed...
<\sh> Czessi: you changed the contents of the original upstream source tarball and repackaged it...in this case it shouldn't happen :)
<\sh> Czessi: try to fix the issues in the orig source tree with patches or directly modify the debianized source tree and move the changes into diff.gz
<Czessi> \sh: i build a completd new package and upload it the last night
<\sh> Czessi: oh shit...I just didn't see it...damn blindness
<Czessi> \sh: hehe, i will contact the author of kiso, that he fix the source problems in the next release
<\sh> Czessi: why is this happening? what causes those broken files?
<\sh> Czessi: could you remove them directly from source and move the removals into diff.gz...
<\sh> grmpf
<siretart> chninkel_away: I just uploaded your ifplugd patch, please check the buildlogs and close the bug afterwards
<\sh> grampf..currently kdelibs4 is broken
<\sh> Czessi: anyways..advocated..we can have a look later when kdelibs is installable again :)
<Czessi> \sh: I wanted to delete the files, at the end of the build i became an error. cause debuild try to delete this files a second time
<Kyral> Screen...mmm
<Kyral> lol
<\sh> Czessi: but what causes the creation of those files? the "autoreconfigure" call?
<\sh> Czessi: are you whitelisted for dapper-changes?
<\sh> Czessi: because you should get a "katie" mail when elmo moves your package out of NEW...and your name will be announced on dapper-changes..please document your work as well on your personal wiki page on wiki.ubuntu.com :)
<Czessi> \sh: whitelisted?
<\sh> Czessi: and congratulation for your first package in the official archives of ubuntu :)
<\sh> Czessi: I just uploaded your package
<Czessi> \sh: thanl
<Gloubiboulga> bbl
<Czessi> \sh: thanks and i update my Wiki page :)
<\sh> Czessi: kewl...then we can go "The Way Of The MOTU" :)
<crimsun> bed time after 84 hours
<crimsun> *z
<\sh> crimsun: good night sleep tight :)
<markuman> crimsun: 84 hours ....what are you doing? good night ;-)
<dholbach> poor crimsun - you rock!
<\sh> crimsun: which list are you working on for the merges?
<LaserJock> can I get somebody to look at a Makefile (http://paste.ubuntu-nl.org/6971) for me? I am trying to figure out if DESTDIR and PREFIX are used correctly
<azeem> LaserJock: PREFIX should be configurable, if possible
<azeem> is that program using autoconf?
<LaserJock> no
<LaserJock> it is just a make make install
<azeem> then maybe it should default to /usr/local, and Ubuntu should patch that to say /usr
<azeem> but that might be cosmetic
<LaserJock> that is what I am doing ;-)
<LaserJock> I pasted the patched Makefile
<azeem> ah :)
<azeem> I don't have time to look at the rest, but from a first glance, it looked OK
<azeem> off to a party now, laters
<LaserJock> cy azeem
<\sh> Czessi: did you get a katie mail? kiso is just approved for NEW :)
<\sh> someone, please tell seth that md5deep is uploaded
<lfittl> \sh: Do you have some time to review a package?
<\sh> lfittl: when I'm getting up again :) I wanted to sleep a couple of hours now....
<lfittl> \sh: k, gn8 then ;)
<\sh> lfittl: but I'm doing in the moment some more reviewing stuff :) while others are working on merges :) (normally it's the opposite :))
<lfittl> \sh: well, the REVU list is long, so that's a good thing to do :)
<raphink> \sh_away: :)
<azeem> LaserJock: install -s strips the program while installing, it might be better to install unstripped and then let dh_strip handle it based on DEB_BUILD_OPTIONS
<LaserJock> azeem: would that be something that I should patch or should upstream change that?
<psusi> you should patch
<azeem> you can ask upstream whether that change is acceptable
<psusi> upstream wants it to strip when you build and install directly from source, which is generally correct
<azeem> opinions probably vary on that, but I think normal automake/autoconf programs do not get installed stripped by default
<psusi> they usually do, though sometimes there's a makefile variable that controls stripping
<LaserJock> ok, I will patch it since I will already patch to change the PREFIX
<LaserJock> anything else needing tweaking? Upstream is nice enough that he will include the changes I need into the next release.
<Kyral> hmm
<Kyral> is this worth packagaing?
<Kyral> http://www.gnomefiles.org/app.php?soft_id=1065
<Kyral> the deb he has listed isn't in the repos
* Kyral shrugs and goes to mail Upstream
<Kyral> Can't hurt
<raphink> bugs in LP about merges are confusin
<raphink> hmm well actually no
<raphink> it's just lucas' interface that lists bugs that have been fixed for previous merges
<raphink> so this is confusing
<Kyral> Always nice to ask Upstream before packaging something
<Kyral> just in case
<LaserJock> in case what?
<raphink> anyone to sync packages?
<raphink> yop Tonio_
<Gloubiboulga> bye
<Tonio_> raphink: re ;)
<Kyral> LaserJock: In case they were gonna do it
<raphink> I need someone to sync packages please :s
<LaserJock> Kyral: that makes sense I guess
<Kyral> I just randomly go through GNOMEFiles and look for things now lol
<LaserJock> Kyral: me too although I am going through kde-apps.org as well since I installed kubuntu-desktop a while back
<Kyral> Actually I have to email the upstream for Yamysqlfront and ask him when his next version is coming out...
<hub> ajmitch: while you are here, why dotGNU when there is Mono? just curious
<spacey_ki> argh, how does one get the latest source tree from a bazaar/arch ?
<lifeless> moin
<ogra_ibook> bzr get  ?
<spacey_ki> ogra, baz
<ogra_ibook> oh, bazaar
* ogra_ibook is happy he has forgotten everything about bazaar :)
<ogra_ibook> but baz get should work as well
<spacey_ki> yeah just tried
<spacey_ki> seems to do something
<spacey_ki> yup
<spacey_ki> great, thnx
<tseng> ogra_ibook: hm did we switch to gnome-screensaver?
<tseng> ogra_ibook: i see that xss is removed
<ogra_ibook> we are about to, yes
<tseng> coo
<tseng> l
<tseng> ive been using it for awhile
<tseng> and g-p-m
<tseng> gpm seems to suspend alot slower than just acpi-support
<ogra_ibook> might be d-bus in the way
<ogra_ibook> hmm, no, actually not
<ogra_ibook> currently it uses gdm directly for suspend and hibernate ... shouldnt differ from the logout dialog
<LaserJock> what would be the Debian versioning for a small change in packaging?
<LaserJock> -X to -X+1 ?
<slomo> LaserJock: yes... even for big changes in packaging :)
<LaserJock> slomo: but not -X to -X.1 or something like that?
<slomo> that's for NMU
<LaserJock> oh, ok
<slomo> why do you ask? :)
<LaserJock> well, I just got my first package in Debian and I found a small mistake in debian/rules
<LaserJock> I'm not sure if I should bother fixing it now or wait for a new upstream release
<slomo> which package? ;) and how critical is the bug?
<LaserJock> plotdrop and the bug is tiny (I think). I set up the makefile to use DESTDIR and for some reason my corresponding change to debian/rules didn't make it in.
<LaserJock> It doesn't change anything as far as the binary package is concerned
<slomo> then i would wait for the next upstream version
<slomo> is it already out of NEW?
<LaserJock> no, I don't think so
<LaserJock> I just got an email from katie
<slomo> hehe
<siretart> huhu slomo, hi LaserJock
<slomo> hi siretart :)
<LaserJock> hi siretart
<siretart> slomo: did you catch siggi?
<slomo> damn... i forgot to write the mail :( sorry...
<siretart> no problem
<slomo> i hate my memory... i need a memory upgrade ;) i'll try to write it tomorrow... or do you want to do it now?
<siretart> I'm currently busy, I'll do it tomorrow aswell..
<siretart> I'd do it tomorrow..
<slomo> siretart: hmm, then you better do it... i could do it only in the evening :/
<lucas> hi all
<LaserJock> hi lucas
<thierry_> anyone who could review my package for a second advocate? http://revu.tauware.de/details.py?upid=1470
<lfittl> dholbach: ping
<LaserJock> I am interested in if/how people use revision control for packaging
<siretart> LaserJock: I like svn and svn-buildpackage
<LaserJock> ok, that sounds about like what I want to do. I've just never set up a svn repo before :(
<siretart> thierry_: done
<LaserJock> siretart: what about bzr, would that work well for packages do you think?
<siretart> LaserJock: I'd still love to see a 'bzr-buildpackage' and it already has some very promising aspects. But imo, it lacks some more features which I'd really love to see for packaging issues
<LaserJock> ok, so do you make a svn repo that holds all your packages and then checkout a local copy when you want to work on something?
<dholbach> lfittl: pong
<thierry_> siretart : with 2 advocate I get commited to universe no? what else could I need?
<lfittl> siretart: do you have some time to review http://revu.tauware.de/details.py?upid=1467 ?
<siretart> thierry_: I just uploaded it for you. if you have been whitelisted, you should get an email from katie
<ajmitch> morning all
<poimen> ?
<siretart> lfittl: nautilus svn scripts? what that?
<siretart> huhu ajmitch
<hub> hey ajmitch
<ajmitch> hey siretart, hub, how's it going?
<lfittl> siretart: as the name says, nautilus scripts to manage a subversion working copy
<hub> ajmitch: fine
<siretart> huhu hub!
<ajmitch> LaserJock: I've started using bzr for nearly all my packages
<siretart> lfittl: something like tortoise for windows?
<tseng> ajmitch++
<lfittl> siretart: exactly
<siretart> ajmitch: do you use nested debian/ dir?
<ajmitch> siretart: yes
<ajmitch> sometimes that's the only branch I have
<ajmitch> eek, why did jane attach a large pdf to her mail? :)
<siretart> to some list?
<ajmitch> to ubuntu-devel-announce
<ogra_ibook> ajmitch, because evince starts faster than ooo2 ;)
<ajmitch> obviously
<LaserJock> ajmitch: do you know of any documentation on using bzr for packaging?
<ajmitch> I think vista on an old pentium would start quicker than ooo2
<ogra_ibook> lol
<ajmitch> LaserJock: nope, there's very little to it
<lucas> who is usually doing the FTBFS checks ?
<LaserJock> ajmitch: ok, well I feel totally lost, should I maybe try svn until I know what I'm doing?
<ajmitch> LaserJock: if you want, but bzr it stuff like bzr init; bzr add; bzr commit -m 'Importing that debian packaging stuff'
<ajmitch> in the debian/ dir
<lfittl> siretart: just noticed a small debian/copyright bug and uploaded the package again
<raphink> lucas: hi
<raphink> lucas: the LP column on your merges table is pretty nice, but it lists the bugs reported and already fixed on previous merges, which is confusing.
<LaserJock> ajmitch: so do you have a bzr repo for each upstream version? or just one for each package
<lucas> raphink: I just use the info sistpoty gave me ;)
<raphink> lucas: hehe ok ;)
<siretart> ajmitch: how do you share your nested bzr archives?
<raphink> lucas: well just lettin gyou know I find this confusing
<raphink> because it doesn't help finding out whether a package is already being merged or not
<siretart> ajmitch: I find it very annoying that bzr get $url doesn't fetch nested archives :(
<LaserJock> btw, I found a good svn-buildpackage wiki at http://workaround.org/moin/SvnBuildpackage
<siretart> yes, that one is quite nice
<lucas> raphink: can you give an example of bug where it is a problem ?
<lucas> err of package
<raphink> lucas: example: pstoedit
<raphink> the 3rd in the list of merges to do
<raphink> https://launchpad.net/distros/ubuntu/+source/pstoedit/+bug/5034
<Ubugtu> Malone bug 5034: "pstoedit: libstdc++ new allocator build" Fix req. for: pstoedit (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Fix Committed http://launchpad.net/bugs/5034
<raphink> this bug is months old
<raphink> and fixed
<lucas> it's a problem with sistpoty's database
<raphink> oki
<lucas> it also shows as Accepted on http://tiber.tauware.de/~sistpoty/MoM/index.py?state=accepted
<ajmitch> LaserJock: I branch off a new debian/ branch for a new upstream version at the moment
<ajmitch> siretart: sharing is something I'm not too concerned about at the moment :)
<ajmitch> since it's mostly for me to keep track of things
<siretart> yes. for local use, bzr is indeed nice. but for shareing and collaborating I think svn-buildpackage is best
<ajmitch> hm
<ajmitch> short notice for motu meeting
<siretart> perhaps darcs-buildpackage, but I'm not that used to darcs
<LaserJock> so will there be a bzr-buildpackage?
<ajmitch> yes, some day
* ajmitch wonders what will break in today's dist-upgrade round
<lucas> raphink: please report the problem to sistpoty
<raphink> hmm ok
<lucas> I can't do any filtering for this
<raphink> when he's here
<siretart> lfittl: I read you wanted to change the name of the motutools package? whats the new name?
<LaserJock> I think I hit a new personal record of 21 firefox tabs open at the same time ;-)
<lfittl> siretart: where did you read that?
<siretart> argl
<LaserJock> siretart: I think you mean lucas
<siretart> s/lfittl/lucas/
<siretart> yes
<lfittl> k :)
<thierry_> siretart : how do I get whitelisted?
<lfittl> thierry_: https://wiki.ubuntu.com/Uploads
<lucas> ah
<siretart> thierry_: ask elmo, better via email
<lucas> multidistrotools
<lucas> (alias mdt)
<lucas> but it's not uploaded to REVU
<lfittl> thierry_: send a request to get whitelisted to keyring@ubuntu.com
<siretart> lucas: do I assume right, you are motu but not added yet to the keyring?
* ajmitch hadn't heard that
<lucas> I'm a member, not a ubuntu-dev memeber
<siretart> ah, ok
<poimen> hi all
<poimen> how can be xdvdshrink added to the multiverse rep?
<poimen> i meant universe
<thierry_> lfittl : if I already sent my gpg key to keyring@ubuntu.com before, I am whitelisted?
<lfittl> thierry: you should get a notification that tells you your RT ticket number (if I remember correctly), and that ticket will be processed by elmo
<LaserJock> don't you need to email upload@ubuntu.com to get whitelisted?
<thierry_> siretart : what is the elmo e-mail?
<siretart> I'd guess elmo gets the email anyway
<lucas> james.troup@u.c
<lfittl> LaserJock: you are right, that was upload@ubuntu.com and not keyring@ubuntu.com :)
<LaserJock> lucas: I don't know that your just added Meeting item is relevent for MOTU since it is community maintained
<lfittl> siretart: did you found some time to review my package, or should I ask you tomorrow?
<LaserJock> or did you have something else in minde?
<lucas> LaserJock: I think uploaders should understand that they cannot just upload a package and then go away
<lucas> it's dangerous
<siretart> lfittl: just a sek
<lucas> we already have >300 packages in universe which are not in debian
<lfittl> siretart: k :)
<lucas> and we don't have any orphaning process, or way to determine which packages are important
<LaserJock> I am more concerned with what happens when we want to get those >300 packages into debian, who is going to be the maintainer?
<lucas> we don't do security support, but it doesn't mean universe packages should just be big black holes
<lucas> some might need to be dropped in the process
<LaserJock> I wouldn't think it would be a problem so much for us since somebody will come along to take care of orphaned packages I suppose
<LaserJock> but I think having teams would help
<LaserJock> I started looking at this issue yesterday (thanks to mdt) for the MOTUScience team
<chninkel> siretart: thanks for the ifplugd upload, where can I check the build logs ?
<LaserJock> I got a package that hadn't built in over a year working again (actually Riddell did it)
<LaserJock> but it came in through apt-get.org so there it wasn't being maintained
<chninkel> pending upload bug status doesn't exist anymore ? replaced by fix commited ?
<lucas> I think so
<siretart> chninkel: http://people.ubuntu.com/~lamont/buildLogs
<chninkel> siretart: thks
<siretart> lfittl: did you see this one? http://revu.tauware.de/revu1-incoming/nautilus-svn-scripts-0601101710/lintian
<lfittl> siretart: I was told by several people that cdbs and debhelper should be build-depends because of debian/rules clean
<lfittl> and that lintian is wrong in this case
<siretart> ah, ok
<siretart> ok, I'm happy. will advocat
<siretart> e
<lfittl> thanks :)
<ajmitch> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344609
<Ubugtu> Debian bug 344609: "better build-depends-indep check" Package: lintian, Version: lintian/1.23.14., Maintainer: Debian Lintian Maintainers  http://bugs.debian.org/344609
<ajmitch> marked as pending upload change for lintian
<dholbach> hope we get this in before uvf ;)
<ajmitch> why, it's only a check :)
<lfittl> siretart: make sure you upload the newer package, as you commented on the old one
<siretart> lfittl: oh, thanks for noticing
<lucas> who is Yann on the wiki ?
<lucas> raphink: ?
<raphink> yes lucas ?
<chninkel> it's me
<siretart> lfittl: just uploaded
<lfittl> siretart: thanks :)
<lucas> ah
<lucas> chninkel: is it motureviewers
<lucas> on MOTUMerging
<lucas> fixing it, but wanting to make sure you knew your spelling was wrong
<chninkel> lucas: I just changed PendingUpload to Fix Commited
<lucas> I saw one of your bugs which was Fix Committed but not assigned to motureviewers
<lucas> ah ok
<lucas> no pb
<chninkel> lucas: didn't change anything else... or did I make a mistake ?
<chninkel> lucas: which bug ?
<lucas> it's no big deal anyway :-)
<lucas> I dunno
* lucas looking for it
<chninkel> lucas: oups I forgot a t in committed
<lucas> ah
<lucas> fix it ;)
<chninkel> lucas: will fix the motureviewers mispelling also
<lucas> I did it I think
<lucas> https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bug/6684
<Ubugtu> Malone bug 6684: "backgrounds (Ubuntu) - gnome-backgrounds: merge new debian version" Fix req. for: gnome-backgrounds (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Unconfirmed http://launchpad.net/bugs/6684
<lucas> I think you certified it was a sync, but forgot to fix the status/Assignment
<lucas> raphink: same for you here: https://launchpad.net/distros/ubuntu/+source/usbview/+bug/6661
<Ubugtu> Malone bug 6661: "usbview: merge new debian version" Fix req. for: usbview (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Unconfirmed http://launchpad.net/bugs/6661
<raphink> oh thanks lucas I will
<raphink> I thought lpbugs would do it
#ubuntu-motu 2006-01-17
<lfittl> night all
<lucas> it doesn't :(
<lucas> launchpad sometimes look sooo broken
<lucas> https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bugs <= no bugs
<lucas> https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bug/6684 <= bug
<Ubugtu> Malone bug 6684: "backgrounds (Ubuntu) - gnome-backgrounds: merge new debian version" Fix req. for: gnome-backgrounds (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: Fix Committed http://launchpad.net/bugs/6684
<dholbach> Committed Fix?
<chninkel> lucas: the default filter maybe doesn't show "Fix Committed" bugs
<chninkel> but where is the advanced button ?
<chninkel> there usually is a advanced button next to the search button: https://launchpad.net/people/motureviewers/+assignedbugs
<raphink> lucas: pour un sync il faut assigner  motumergers aussi?
<lucas> reviewers oui
<lucas> motureviewers
<lucas> motumergers c'est la team dont je comprends pas trop l'intret (voir ma proposition pour le MOTUMeeting de demain)
<thierry_> siretart : would you like to also review my other package? http://revu.tauware.de/details.py?upid=1414
<raphink> ah oki
<raphink> donc reviewers
<raphink> bon a roule
<raphink> je change tus mes bugs
<raphink> ;)
<raphink> vala
<dholbach> good night guys :)
<lifeless> ajmitch: hey, is python-bazaar from sid pullable to dapper ?
<ajmitch> it's in sid now?
<ajmitch> I guess I won't file that ITP then ;)
<lifeless> I think so ;)
<ajmitch> hm, it doesn't show up here
<lifeless> as 'pybaz'
<ajmitch> ah right
<lifeless> bah
<ajmitch> whoever did that needs hurt
<lifeless> silly man,
<ajmitch> that's on your local install?
<ajmitch> no, I see it
<lifeless> no, dchroot apt-cache search pybaz
<lifeless> ;0
<lifeless> probably python2.4-pybaz is what it should be
<lifeless> as the python module is 'pybaz'
<ajmitch> right
<ajmitch> I see python-bazaar that I have installed isn't actually in dapper, I think
<sladen> how come  bluez-bcm203x  disappeared from universe?
* sladen wonders
<poimen> how can be xdvdshrink added to the universe rep?
<lifeless> why does half of dapper conflict with dbus?
<Kyral> hal?
<Kyral> or the lackthereof?
<ogra_ibook> because you dont upgrade often enough ?
<Kyral> heheh
<lifeless> ogra_ibook: I'm trying to, but it wont let me!
<ogra_ibook> ouch
<lifeless> ogra_ibook: I cant seem to find a solution that keeps evo *and* gnome installed.
<lifeless> which is, needless to say, painful.
<ogra_ibook> just let it remove evo and install ubuntu-desktop in the end
<lifeless> hmm, let me check the ubuntu-desktop depends
<ogra_ibook> evo is among them :)
<lifeless> I'm checking for postfix
<ogra_ibook> nope
<lifeless> its why I never had ubuntu-desktop, because I use exim
<ogra_ibook> MTA is gone since breezy
<ogra_ibook> we dont ship any ...
<lifeless> and the silly thing depended rather than postfix|mail-transfer-agent
<lifeless> looks good, I'll try that.
<ajmitch> sigh, the screensaver prefs window is obnoxiously slow
<ogra_ibook> not here
<ogra_ibook> gnome or xscreensaver ?
<ajmitch> probably xscreensaver
<ajmitch> and it's probably because I was previewing GL screensavers
<ogra_ibook> ah, havent got that since ubz
<ajmitch> and then electricsheep
<ogra_ibook> electricsheep is darn slow
<ogra_ibook> but looks great :)
<ajmitch> yeah :)
<ajmitch> is gnome-screensaver looking nice & usable for dapper?
<ogra_ibook> yup
<ogra_ibook> we just switched the seeds
<tseng> how about g-p-m?
<tseng> and n-m
<ogra_ibook> g-p-m very likely
<ajmitch> n-m is looking shaky still
<ogra_ibook> n-m very unlikely
<tseng> nm actually works for me these days
<ajmitch> especially as atheros cards do stupid things with the madwifi drivers
<tseng> the atheros cards cant scan and be connected at the same time
<tseng> is what im hearing
<Kyral> huhwha about Athereos?
<tseng> if it only scanned when not connected, less problem
<ajmitch> apparantly it takes a 'scan for networks' command as 'disconnect & look for somewhere else to go'
<ajmitch> I can't recall what other crack is lined up for dapper
<Kyral> hmmm
<Kyral> stupid question but any reason why GAIM2 hasn't hit Dapper?
<tseng> because its not released?
<Kyral> oh...
<ajmitch> you sound as bad as those forum users..
<Kyral> Actually I only asked because I tried to use Gaim Encryption to one of my friends and he said he was using 2, so I was just wondering
<Kyral> I heard the UI stinks, so...
<ajmitch> so far beta 1 has been released
* Kyral shrugs
<Kyral> I was just wondering :P
<LaserJock> hi Kyral
<Kyral> hey
<LaserJock> hi minghua
<minghua> hello LaserJock
<LaserJock> how's it going?
<psusi> good... how's it hanging?
<LaserJock> psusi: good
<minghua> quite good, too busy to work much on ubuntu though
<LaserJock> hmm, yes. I don't know if I will finish my PhD at the rate I'm going. Ubuntu is much more fun ;-)
<Kyral> lol
<LaserJock> Sometimes I think I maybe shouldn't have switched from CS to Chemistry
<Kyral> lol
<LaserJock> Kyral: did I tell you I got my package uploaded to Debian today?
<psusi> lol
<Kyral> LaserJock: nice
<Kyral> I need to file ITPs for EasyChem
<Kyral> but I forgot lol
<Kyral> what did you do? File a RFS and ITP?
<LaserJock> ITP since I already had a package ready to go
<Kyral> ah
<Kyral> what pack?
<LaserJock> then I sent a RFS to debian-mentors
<LaserJock> plotdrop
<LaserJock> Debian has sooo many acronyms
<Kyral> so I just gotta file an ITP for EasyChem
<Kyral> and then a RFS for it
<Kyral> Do I gotta rebuild the pack for Sid?
<Kyral> or Etch/Sarge?
<LaserJock> Sid and I don't know if it is necessary but It probably wouldn't hurt
<LaserJock> cause you want to get rid of the 0ubuntu1
<Kyral> like do I just gotta make sure it builds? Or actually make a changelog change?
<hub> I need a review: http://revu.tauware.de/details.py?upid=1472
<hub> I clarified the license with upstream
<LaserJock> Kyral: hmm, not sure. I had a couple of change I wanted to make so I repackaged
<Kyral> LJ maybe you should send this out over the MOTU-Science
<LaserJock> Kyral: what?
<Kyral> the fact that Plotdrop is in Debian
<LaserJock> oh, sure
<Kyral> I gotta find someplace to upload mine to..
<LaserJock> Kyral: check out http://lists.debian.org/debian-mentors/2006/01/msg00096.html
<LaserJock> that is my RFS
<Kyral> ah
<Kyral> I was thinking of rebuilding EasyChem with CDBS
<Kyral> If it works I may send that version into Debian
<LaserJock> Kyral: what section did you put EasyChem under?
<Kyral> universe/science
<LaserJock> hmm, it didn't show up on my list at http://tiber.tauware.de/~laserjock/science_list.html
<LaserJock> hmm, odd. It should be there
<Kyral> okay I'll file an ITP and RFS tomorrow
<Kyral> actually...I wanna get Fetchmail and a MTA setup...
<LaserJock> yeah, I had to do that too to get reportbug running
<LaserJock> I install exim4
<Kyral> how do I setup Fetchmail anyway?
<LaserJock> oh, don't ask me. I'm clueless when it comes to that kinda stuff.
<Kyral> lol
<LaserJock> I just use thunderbird ;-)
<Kyral> heh
<LaserJock> what I am really concerned about right now is how we are going to handle the rest of the packages that aren't in Debian
<Kyral> reverse merge?
<ajmitch> LaserJock: why is that?
<ajmitch> LaserJock: it's something that only debian developers can upload anyway
<LaserJock> well, I've been talking with debian-science and they would like to see ITPs or RFPs on them (8 right now, maybe more)
<LaserJock> but since we maintain as a team in Ubuntu I don't know how to handle maintainership when we try to get them in Debian
<ajmitch> have the team maintain them
<ajmitch> same as ubuntu
<LaserJock> How do we do that?
<ajmitch> set the Maintainer: field as the team name & contact email
<ajmitch> and the team members in Uploaders:
<minghua> LaserJock: look at vim for example
<minghua> Debian developers have been discussing if it's a good practice though
<ajmitch> debian developers will discuss anything to death if they can
<Kyral> Like Congress!
<LaserJock> do you think DDs would sponsor packages if they were maintained like that?
<ajmitch> yes
<ajmitch> we do it often
<jamessan> well, having the team name in the maintainer field is fine. the part being discussed is what to put as the name for the person that last made the change
<Kyral> changelog
<ajmitch> jamessan: team name, and person name in the changelog entry itself
<ajmitch> is what is commonly done
<LaserJock> maybe I can ask debian-science but I'm kind of afraid after the last thing I brought up ;-)
<Kyral> Actually
* Kyral goes to subscribe to debian-science
<minghua> jamessan: oh I see.  thanks for the clarification
<LaserJock> well, it is easy enough to do RFPs at least
<Kyral> Where is the Debian-Sponsors ML?
<LaserJock> debian-mentors ?
<Kyral> oh
* Kyral smacks himself
<LaserJock> well, lucas's scripts are sure coming in handy for MOTUScience
<LaserJock> I think debian-science was fairly impressed
<Kyral> scripts?
<LaserJock> multidistrotools or something like that
<Kyral> Subscribed to debian-science and debian-mentors
<LaserJock> Kyral: https://wiki.ubuntu.com/MultiDistroTools
<Kyral> Whoa...
<Kyral> Package..it...NOW :D
* ajmitch sighs
<Kyral> eh?
<ejofee> [this is a quick PATCH] : tightvncserver won't work (won't find the font's path) unless one runs "sudo ln -s /usr/share/X11/fonts /usr/lib/X11". what do you think it should be done: create the symlink or change the path tightvncserver is expecting?
<ejofee_> sorry, i've been disconnected. has anybody answered in the meantime?
<lifeless> no
<lifeless> but fix tightvncserver
<lifeless> its probably hardcoded rather than using whatever header setting it should use
<lifeless> ask daniels
<ejofee_> when do i find daniels?
<ejofee_> lifeless: ^
<LaserJock> Kyral: did you know easychem was backported?
<Kyral> LaserJock: yah I got the AutoBackport thingy
<LaserJock> Kyral: the what?
<Kyral> I dunno
<Kyral> some kinda script
<Kyral> I think
<Kyral> But a binary pack hasn't been built yet has it?
<LaserJock> nope
<Kyral> yah thats kinda odd
<LaserJock> well now I have a bash script to generate the lists on MOTUScience using mdt :-)
<Kyral> lol
<Kyral> What is libregexx
<ptlo> sounds like a c++ regular expression library
<Kyral> yah
<Kyral> yamysqlfront depends on its -dev but I cannot find it in Dapper
<Kyral> and the Debian package search is down
<LaserJock> Kyral: apt-cache search in sid chroot?
<Kyral> ...I didn't think of that...
<Kyral> lol
* Kyral logs into his Sid Pbuilder
<Kyral> ..not showing up
<Kyral> nor in Etch
<Kyral> I'll just email upstream
<Kyral> oh whoops, he emailed me the new version
<Kyral> okaaay...I tihink I need to seperate this package...
<ajmitch> hammer, please
<Kyral> huh?
<ajmitch> #ubuntu
<Kyral> who?
<ajmitch> petoix
<Kyral> ajmitch...was there ever a package called libregexx-dev in Debian?
<ajmitch> and others with short patience
<ajmitch> let's see.. there are ~15-10K packages in debian
<Kyral> sorry
<LaserJock> Kyral: google?
<ajmitch> and you ask if I know of a specific -dev package?
<Kyral> I'm asking because this control has qa@debian as maintainer..
<ajmitch> hello jaldhar
<Kyral> err. packages@qa.debian.org
<ajmitch> probably orphaned then
<Kyral> ah
<ajmitch> or it's been removed from debian
<Kyral> Seeing as its not in Sid or Etch...
<ajmitch> http://packages.qa.debian.org/r/regexx.html
<ajmitch> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=263873
<Ubugtu> Debian bug 263873: "regexx -- RoQA; orphaned, RC bug, no upstream" Package: RM, Maintainer: James Troup and others  http://bugs.debian.org/263873
<Kyral> ah
<ajmitch> hm
<ajmitch> I know that upstream..
<Kyral> anyway to get it into Dapper....
<ajmitch> did you talk to upstream of this package?
<ajmitch> or of the other one?
<Kyral> yamysqlfront?
<ajmitch> regexx
<Kyral> no
<Kyral> I'm only asking about it because something else I'm packaging depends on it
<ajmitch> it shouldn't be hard to track down niemeyer & see if he has a new upstream version to get back into sid
* ajmitch met him at UBZ
<Kyral> and I discovered its package dir in the yamysqlfront sourceball
<ajmitch> hm
<ajmitch> I'll try & hunt down a newer regexx
<Kyral> ty
<ajmitch> the author works for canonical now, btw
<Kyral> heh
<Kyral> thats a nice job lol
<ajmitch> what is?
<Kyral> Working for Canonical
<ajmitch> last I heard he was on the launchpad team
<Kyral> cool
<Kyral> Niemeyer you say?
<ajmitch> yes
<Kyral> I'll look him up on Launchpad tomorrow and email him about the package
<ajmitch> why?
<Kyral> Wouldn't he know about new versions? Or am I confused...
<ajmitch> gustavo at niemeyer.net will do
<ajmitch> no need to lookup on LP
<Kyral> ah
<Kyral> see I didn't know his email :P
<ajmitch> it's on the bazaar-ng list :)
<Kyral> the wha?
<ajmitch> bzr, bazaar-ng, bazaar 2.0...
<Kyral> ah
<ajmitch> mailing lists,  you know?
<Kyral> yah
<Kyral> I'm not on the Bazaar ones
<Kyral> ty ajmitch
<Kyral> the only reason I'm interested in this is because upstream for yamysqlfront is very responsive
<psusi> hrm.. is there any way to speed up the way X renders fonts?  seems to be rather cpu intensive
<Kyral> Hardware accel?
<psusi> I think it's on...
<Kyral> I mean let it render the desktop
<psusi> dragging a full window around the desktop is plenty fast and doesn't cause cpufreq to speed up the cpu... scrolling a terminal window or dragging the window over top of xchat pegs the cpu from all the text drawing
<Kyral> ick
<psusi> and it's X that is going nuts
<Kyral> what kind of video card do you have?
<psusi> so my guess is it's font rendering
<psusi> radeon 9800 pro
<Kyral> *shudder* ATI
<ajmitch> psusi: invest in shares in the power company
<Kyral> lol
<psusi> ajmitch, why do you say that?
<psusi> that reminds me for at least the 80th time.. I need to order a Kill-a-watt
<LaserJock> ajmitch: do you have a minute to run through using bzr for packages? If not that is ok.
<ajmitch> I thought I ran through it in 1 line earlier? :)
* ajmitch is not doing anything complex
<LaserJock> yes, but I'm not sure what directories to repo, etc.
<LaserJock> it sounded like you just did /debian
<ajmitch> often, yes
<ajmitch> depends how you want to handle patches
<Kyral> Is there anything wrong with using Simple Patchsys?
<ajmitch> not specifically
<ajmitch> although it can probably have problems
<Kyral> ah
<LaserJock> ajmitch: so what do you do with the .bzr when you build a package? do you exclude it?
<Kyral> so for easy things like EasyChem its alright?>
<ajmitch> you can
<ajmitch> lately I've left it in, thought I suppose I should remove it
* Kyral doesn't even fully understand what Bazaar is aside from something like CVS
<ajmitch> Kyral: it's several steps beyond cvs :)
<Kyral> okaaay
<ajmitch> and with packaging I'm using it in its simplest way possible
<LaserJock> Kyral: http://bazaar.canonical.com/IntroductionToBzr
<ajmitch> Kyral: it will revolutionise your life
<psusi> oh yea, it is definately the font rendering engine... turning down all the subpixel smoothing and all that makes a huge difference in cpu usage
<LaserJock> I'm still trying to figure out how to use any kind of RCS :(
<Kyral> Yanno...this would prolly be more useful when I start cranking out my own software
<ajmitch> LaserJock: all I really do is commit the changes I make in debian/
<ajmitch> and then branch for a new version
<LaserJock> but do you have a directory where you keep all the repos and then checkout the /debian into the source directory?
<ajmitch> just my normal packaging arrangement
<ajmitch> which is something like ~/debian/mono
<ajmitch> ~/debian/gnu
<ajmitch> ~/debian/phpgroupware
<ajmitch> etc
<ajmitch> nothing particularly ordered about what I do
* Kyral wonders if it would be worth it to redo EasyChem with CDBS
<ajmitch> since bzr doesn't have a separate repository like cvs & svn do
<LaserJock> ajmitch: oh, ok
<ajmitch> I *could* push my branches to a location, if I wanted
<ajmitch> but that would be a waste of time for me
* ajmitch really needs that smart battery support for this laptop
<LaserJock> hi Hobbsee
<ajmitch> I'd hate for it to suddenly turn off
<Hobbsee> hi LaserJock
<ajmitch> afternoon Hobbsee
<Hobbsee> afternoon ajmitch :)
<LaserJock> ok, so I was going through the science related packages that are in Ubuntu but not in Debian and I have noticed a couple that apparently came from apt-get.org
<LaserJock> how does that work?
<ajmitch> they got imported, what other info do you want? :)
<LaserJock> well, so they are just left around I suppose?
<LaserJock> I guess it takes a MOTUs attention for anything to be updated
<ajmitch> sadly, yes
<LaserJock> because I was just looking at ruby-gnuplot and the package is from 2001 but they released a new version in November
<LaserJock> so obviously nobody was keeping track of it
<LaserJock> anybody know japanese?
<minghua> Yagisan, I suppose.  but he is not here
<LaserJock> so would it be bad to drop packages that are only in Ubuntu that aren't being maintained anymore?
<minghua> LaserJock: I think it depends on how we want make people see universe
<minghua> I always look universe as "packages without (guaranteed) support, some may work, some may not"
<minghua> so it's fine for me if there are unmaintained packages
<minghua> others may not share the same opinion, though
<LaserJock> yeah, I guess I view it as universe is "packages maintained my MOTU and wannabes" which means that if we aren't maintaining it maybe we shouldn't be sending it out
<LaserJock> but I see your point
<LaserJock> I guess it would just "look" better (especially to Debian, if we care) iif we didn't have this stuff just hanging out there
<zakame> hi MOTUs :)
<LaserJock> hi zakame
<ajmitch> hello zakame
<Kyral> Goodnight MOTU
<ajmitch> no way we can maintain all of universe
<ajmitch> night Kyral
<zakame> heya ajmitch :) what's up?
<ajmitch> just playing around with the laptop
<zakame> the new one?
<ajmitch> yes
<zakame> w00t :)
<ajmitch> wireless works ok with hwcrypto disable
<ajmitch> now I just need sound & battery
<zakame> hehe, good for you :)
<LaserJock> cya Kyral
<wadeb> hello, I've got a piece of GTK educational software I'm trying to package to ubuntu.  is there a howto / reference available for doing this?  most of my questions are simple things like setting an application icon in gnome and properly registering the mime file type.  thanks in advance.
<Burgundavia> wadeb, siretart does some wxwidgets stuff
<Burgundavia> wadeb, and yes, there are not many channels I am not on
<wadeb> burgindavia: lol...thx, I'll msg him
<Treenaks> Burgundavia: there are?!
<Treenaks> Burgundavia: +'nt?
<Treenaks> Burgundavia: I always knew you were just an IRC bot ;)
<Burgundavia> Treenaks, I am not a bot but I think Seveas is ;)
<ajmitch> hi viviersf
<ajmitch> Mez: what did you mean in -devel?
<Mez> ajmitch - the whole "Need for launchpad/Canonical Business Model" stuff
<ajmitch> oh right
<ajmitch> that's still going?
<Mez> yeah
<ajmitch> fun
<Mez> It really gets to me though that some people seem to take such a slanted view on things.
* ajmitch goes to watch the car crash
<Mez> Ubuntu cant do all the work - nor can debian
<Mez> they both need to do woek
<ajmitch> no kidding
<Mez> and yeah - some bad eggs are spoiling it by not working with each other (both in Debian AND ubuntu)
<Mez> but - for the most part - we try and work together
<Mez> I've come up against a couple of DD's who arent willing to try and work with me on packages I work on
<Mez> and I've come across DD's who are MORE than willing to - and even go beyond the "call of duty" and do extra stuff
<Mez> It's not really an "ubuntu vs debian" thing
<Mez> it's really - just those people who're spoiling it
<Mez> I mean - I would post this to the list
<Mez> but I know I'd get flamed
<ajmitch> go ahead
<ajmitch> wear your asbestos underwear
<jsgotangco> nahh don't spread it further
<jsgotangco> there will always be a dissenting opinion no matter the explanation
<ajmitch> hehe >:)
<ajmitch> which is why I've refrained from it
<ajmitch> some ubuntu people & plenty of debian people annoy me ;)
<Mez> ajmitch - I will post - I'm just going to be nice and stuff
<Mithrandir> jsgotangco: also, some posts I've seen from ubuntu people, like the "Debian should move to launchpad" is more trolling than anything else.
<ajmitch> Mithrandir: agreed, and it's quite understandable why debian will not move
<Mez> Mithrandir, i dont see personally how ti could move to launchpad really ...
<Mez> I can see how they could use it as a very useful tool - but not as their primary ... thing
<ajmitch> some debian teams are using launchpad
<Mithrandir> sure, and they're free to do that, but it's not like it should become an essential part of the debian infrastructure.
<ajmitch> however the debian team I know of is lead by a launchpad developer/admin :)
<Mithrandir> they're free to use alioth or sf.net or groups.yahoo.com or whatever other services they feel like, but that's something else.
* Mez sends
<viviersf> elo ajmitch
<ajmitch> argh, just recalled there's a MOTU meeting in about 12h
<dholbach> good morning motu universe
<Mez> can someone please express my apologies in the meeting? i have work - os won't be able to make it
<ajmitch> Mez: MOTU meeting?
<Mez> yeah
<ajmitch> ok, will keep note
<ajmitch> reminds me, I need to install tomboy on this laptop
<Mez> o_O
<Mez> The following packages will be REMOVED
<Mez>   kdebase-dev kdelibs4-dev
* ajmitch would love to have all the hardware working on this laptop
<ajmitch> yay!
<ajmitch> Mez: find out which lib or -dev package is installing that they depend on
<Mez> i'm guessing it's cause it'sinstalling the updated kdelibs
<Mez> but - i woulda guesse d they'd be upgraded too - not removed
<ajmitch> do it package by package if you can
<Mez> *shrugs*
<ajmitch> go through the suspects
<Mez> I can reinstlal :D
<ajmitch> or just wait :)
<Mez> packages to be upgrade:  foomatic-db-gimp-print ijsgimpprint kdelibs-bin kdelibs4c2a moodle
<Mez>   python2.4-gtk2
<ajmitch> upgrading from what?
<dholbach> slomo_, siretart, crimsun: I added the link to http://gstreamer.freedesktop.org/media/ to Media/Testing - we should pick some of them to let Media/Testing take off
<dholbach> slomo_, siretart, crimsun: I added Media/Testing on Testing as well
<jsgotangco> its this just about testing what's avaiable (files that is)
<ajmitch> sigh, someone on the debian pkg-zope list has done a zope 2.9 'upgrade', but it looks like all they've done is uupdate
<ajmitch> and a fair bit of other mangling..
* ajmitch hopes an official package is uploaded in the next few days
<dholbach> jsgotangco: no, not all of them, that's why we need to select some
<jsgotangco> ahh
* ajmitch can't believe we only have a week until UVF
<StevenK> dpkg-source: cannot represent change to debian/rules: binary file contents changed
<StevenK> Grrrrrrrrrrrrrrrr
<StevenK> This package so hates me.
<StevenK> Every time I try to fix it, it does something else fucked up.
<ajmitch> uh, that's fairly screwy
<ajmitch> why is it detecting debian/rules as binary?
<ajmitch> screwed up encoding?
* ajmitch had better do another f-spot upload
* StevenK gives up on moin after screaming at it in frustration.
<StevenK> Now, onto why albatross wants root privs to actually build.
<StevenK> Bugger that, off to watch some TV.
<dholbach> StevenK: enjoy :)
<siretart> dholbach: rock!
<dholbach> siretart: now we need to pick
<siretart> dholbach: I will have a look at them this evening when I'm back from uni
<ajmitch> hey siretart
<siretart> huhu ajmitch
<ajmitch> evening Hobbsee
<Hobbsee> evening ajmitch - how many hours till dapper devel meeting?  seems my calculations keep getting different answers as to when it is
<ajmitch> 2hrs & 20min ago
<ajmitch> MOTU meeting in 9 hrs & 40min
<ajmitch> so if you wanted to watch the devel status meeting, sorry
<Hobbsee> ajmitch: hehe, right - told you my calculations were screwed!  oh well, i'll go read a transcript of it when one is uploaded
<ajmitch> it should be online now
<Hobbsee> ah, so it is :)
<ajmitch> http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-current.html
<Hobbsee> yeah, got the link, thanks anyway :)
<ajmitch> morning \sh
<\sh> hey aj
<ajmitch> how are you?
<\sh> i'm feeling like a swine
<ajmitch> oh?
<\sh> Recently, a certain member of the MOTU team in ubuntu posted a blog post basically saying (from the
<\sh> way it came across to me) that contributing back up to debian was a waste of our meagre resources.
<\sh> quote of one of the mails in debian-devel...well...sometimes I wish I would have a bablefish to share
<ajmitch> btw pending upload of njam is in debian NEW
<\sh> Mez: you should read properly...I never said "it's a waste.." I said, "Sometimes we don't have the time to think about it..." and "it's my personal opinion and my decision to do so"
<\sh> ajmitch: actually I never saw a package in incoming
<ajmitch> that's because incoming is once it's passed NEW
<\sh> I thought it's the other way..no possibilty to see new NEW queue?
<\sh> or better to check the packages in the NEW queue?
<Mez> \sh: It's how it came across to me - I believe I did say that
<ajmitch> \sh: http://ftp-master.debian.org/new.html
<ajmitch> Mez: and stating your view of someone else's blog entry without talking to them, on a public mailing list?
<ajmitch> 'feel free to target those people'.. just not fair
<Mez> o_O
<\sh> Mez: yes...but it's interpretated the wrong way...I do contribute back...but when and why, it's my decision.
<Mez> I seriously didnt mean it to come across as a personal attack on you \sh - I'm sorry if it did
<\sh> Mez: so don't put all MOTUs in one boat, because of my blog post...it's my opinion
<Mez> \sh: I never did put all MOTU's in one boat.
<Mez> gah
<\sh> Mez: well..that is the problem, that those people discussing right there and now are understanding everything wrong, because the most of them don't know
<\sh> Mez: but it can be read like that
<ajmitch> this whole sorry episode hasn't been good for anyone
<\sh> Mez: it's a matter of fact, that it doesn't matter what we do, if or if not contributing back, it's always wrong...but only for a small ammount of package maintainers. but those are discussion right now with matt and others...that's why it's dangerous to put peoples own opinions into this discussion
<\sh> s/discussion/discussing/
<\sh> and that's why i'm refusing to reply publicly again on this debian-devel ML...nevertheless, i'm in discussion with some people via privat mail.
<\sh> to show them that they're actually telling not the truth when they say "ubuntu is not contributing back or not sending patches in"
<\sh> ok..end of story for this...
<Mez> \sh - again - sorry if it seemed like a personal attack at you - it really wasnt meant like that
<Mez> I've sent another email to try and clarify
<Mez> lol - though knowing me it'll make it worse
<ajmitch> as long as you don't use lol, :D, o_O or anything else like that, it should be fine
<\sh> Mez: i'm not taking it personal...but to put things straight, I can discuss it with you here :) so, forget about it :)
<Mez> \sh :d no problems :D glad you dont see it like that (seriously till it was mentioned here - I didnt realise it could have been taken that way!)
<azeem> what is remarkable is that Joey Hess and Steve Langasek joined the ranks of those not buying the "Ubuntu is contributing back to Debian" line
<ajmitch> it's a thread that should die soon
<ajmitch> I hope
<\sh> actually, if joey wasn't ranting about how "dirty and difficult it is to merge back ubuntus patches into debian" I would think, he's right, but after reading some blogpost of him and some ranting on debian-devel, i think there are alot of patches flewing back to him directly...
<ogra> azeem, havent they always been in that line ?
<\sh> ok...it's enough of this stupid and childish topic...I took the bait once, I will never do it again. full stop.
<Mez> \sh: you emailed ?
<Nafallo> the flamewars of debian is why I'm here instead ;-)
<Mez> Nafallo, yes - this is why we have a CoC
<ajmitch> Mez: no, we'll let it die, please
<\sh> Mez: it's because somehow of me why this topic started to be stupid
<Mez> ajmitch, I thought by him saying "he took the bait" he emailed back
<ajmitch> Mez: no
<\sh> Mez: but reading the other replies I decided to stop mailing to d-d ever again
<\sh> Mez: read the whole thread
<Mez> \sh: yeah - the replies in it are like ... wank
<Mez> \sh: I have
<ajmitch> argh
<ajmitch> just drop it :P
<Mez> I'd hate to see the d-p mailing list atm
<Mez> but yeah
<ajmitch> everyone go upload packages or something
* Mez drops and picks up a cigarette instead
* \sh has to work on sunday and monday for a friends service...
<\sh> earning some money...which is actually nice
<Mez> \sh: at least you get to see daylight :d lol - this is the first time I've seen daylight in ... 3 months
<Mez> and thats only cause like - I cant sleep
<Nafallo> :-O
<sivang> \sh: nice to hear that, what kind of service? online?
<\sh> a mobile entertainment service..a la jamba..
<\sh> but only for 2 days..
<\sh> it means 48h duty service...which means some money :)
<Gloubiboulga> someone could review this: http://revu.tauware.de/details.py?upid=1473 ?
<sivang> \sh: cool, are you going to give RF fix services, service radio lines etc?
<\sh> sivang: nono..only the normal "too much traffic on the machines, machine is crashing, please watch, take care and restart services"
<sivang> \sh: ah , that's should be easy enough and allow you to work on packages while in there then ;-) ?
<\sh> sivang: sure
<\sh> trying to fix again python-kde3
<sivang> \sh: I've started looking again at KDE, I'm telling you, X-Composite is so sweet there plus Kuake :)
<\sh> sivang: both desktop enviroments have advantages and disadvantages...mixing them gives you a lot more fun :)
<sivang> \sh: I can imagine, I will try install kuake and work with it for a bit.
<ajmitch> kuake? sounds interesting
* ajmitch wants composite working nicely on this laptop soon :)
<sivang> ajmitch: KDE has it :)
<ajmitch> has what?
<sivang> ajmitch: sorry, I mean, X-Composite works and is utilized nicely in KDE, a co-worker is uing it on a debian sid box
<ajmitch> right..
<ajmitch> I'm meaning xserver support
<ajmitch> which apparantly is still lacking a bit on i810
<sivang> ajmitch: well, he did disable some of the feature which made his display slow , but things like shadows and smooth edges etc..
<\sh> ajmitch: can you do me a big big favour
<ajmitch> \sh: what?
<\sh> ajmitch: sponsoring a package into debian? pykdeextensions? it's already in kubuntu...
<\sh> ajmitch: http://mentors.debian.net/debian/pool/main/p/pykdeextensions/
<\sh> http://sponsors.debian.net/viewpkg.php?id=139
<\sh> http://svn.debian.org/wsvn/pkg-kde/kde-extras/pykdeextensions/trunk/debian/?rev=0&sc=0
<ajmitch> that is a big big favour
<\sh> ajmitch: I know..but it would help the maintainer of pykdeextensions for kubuntu and debian (it's the same person) :)
<ajmitch> how much will that person pay me?
<\sh> ajmitch: and actually it would help to decrease the diff between debian and ubuntu/kubuntu
<viviersf> lol
<\sh> ajmitch: I'll take some of your packages to merge?
<viviersf> ajmitch, everything must be free ;p
<ajmitch> hah
<ajmitch> \sh: I think I've only got zope packages left
<\sh> ajmitch: the maintainer doesn't know anything of my sos to you :)
<ajmitch> the others are still open due to FTBFS on an arch or similar
<\sh> ajmitch: ok...so you have time :)
<ajmitch> yes, I have time to do about 50 uploads in 5 days
<\sh> ajmitch: thank you soooo much :)
<sivang> ajmitch: rather try yakuake, it's sweet
<ajmitch> \sh: it's after midnight right now, so it mightbe something for the morning :)
<\sh> ajmitch: would be nice if you could help somehow :)
<\sh> Fathi Boudra <fboudra@free.fr> is the guy who needs your attention :)
<ajmitch> yes, I saw
<ajmitch> I'm looking at it now
<ajmitch> and wondering why it's libpythonize0-dev
<\sh> ajmitch: you rock :)
<\sh> ajmitch: because it makes kcontrol modules possible :)
<ajmitch> why the 0?
<\sh> because it can change to 1 or 2 in the future :)
<ajmitch> hm, it's ok
<\sh> depending on the lib version
<ajmitch> I see it's better to not name it libpythonize-dev
* sivang is now irssi'ing from yakuake.
<\sh> ajmitch: riddell helped to develop the package i think so it's more then sane imho
<ajmitch> the -dev package doesn't depend on python2.4-dev?
<ajmitch> should it?
<ajmitch> what headers are needed to use the -dev package here?
* ajmitch builds it in a sid pbuilder for extra check
<\sh> everything it's in...python-kde3 is a build-dep and a requirement for the package...so everything will be included what it needs
<\sh> python-kde3 is the meta package depending on the default python version
<ajmitch> but this requires python2.4
<ajmitch> not the default
<Riddell> is ajmitch a DD?
<ajmitch> yes
<Riddell> interesting... :)
<ajmitch> uh oh :)
<\sh> ajmitch: on ubuntu it requires python2.4 which is included in python-kde3
<\sh> and python-sip4-dev
* ajmitch is just watching pbuilder pollute the apt cache with kde packages :)
<\sh> Riddell: the good thing about it, we know who to ask for help :)(regarding bringing in packages from ubuntu to debian)
<ajmitch> oh, you mean StevenK? ;)
<\sh> and I'm patching again kconfigskeleton issues of python-kde3...as I saw yesterday, upstream never fixed it correctly..he fixed the segfault, but not the error at all
<\sh> ajmitch: it will alternate between you and stevenk
<ajmitch> there are at least 3 other DDs who are around here
<Riddell> \sh: what's needed to get the KDE 3.5 API in pykde?
<\sh> Riddell: well...at least updates from upstream for bringing in kde 3.4.2/4.3/3.5
<\sh> support
<\sh> Riddell: the problem is, pykde is no revenue project of upstream, only pyqt
* ajmitch waits for kde crack to build
<ajmitch> \sh: to think that I used to be a kde crack-of-the-day junkie
<ajmitch> my 400MHz box used to run hot compiling kde crack every night ;)
<\sh> ajmitch: *g*
<dholbach> poor box
<ajmitch> that box still runs
<dholbach> i threatened my 350 box with xubuntu but it coped nicely
<ajmitch> it has an uptime of > 1 year on a pre-hoary kernel ;)
<\sh> woohooo...python-kde3 works now correctly..
<\sh> after I applied a patch from 2004 again *gnarf*
<ajmitch> heh
<ajmitch> ok, sleep time
<ajmitch> will try & get many uploads done tomorrow ;)
* ajmitch has a few ready for debian as well as ubuntu
<\sh> ajmitch: if it's ok, then please sponsor pykdeextensions :) thx :)
<\sh> ajmitch: and have a good night :)
<Gloubiboulga> Riddell, sistpoty has advocated my package, could you have a look at it once again ? http://revu.tauware.de/details.py?upid=1468
<Tonio_> siretart: ping ?
<\sh> Gloubiboulga: looks good :)
<Gloubiboulga> thanks \sh :)
<\sh> Gloubiboulga: uploading it now :)
<Gloubiboulga> cool :D
<segfault> Are you guys advocating now?
<raphink> hey I had an idea for an emblem for the motumergers team
<raphink> very simple idea
<raphink> http://raphink.free.fr/motumergers/
<raphink> I'm very bad with graphic stuff though :(
<raphink> \sh: what do you think ?
<raphink> ;)
<\sh> what?
<raphink> http://raphink.free.fr/motumergers/
<raphink> just had fun working on an emblem for the motumergers team on lp ;)
<raphink> very simple idea : merging the debian and ubuntu log ;)
<raphink> logos
<raphink> not sure it looks nice :s
<azeem> raphink: it's pretty hard to figure out at that size
<azeem> an animated .gif would be nice :P
<raphink> azeem: well I did them at that size because that's how they are on LP
<raphink> LP emblems are 16x16 PNGs
<azeem> yeah ok, but still :)
<raphink> haha
<raphink> ;)
<raphink> well
<raphink> what's the use of making a bigger one if only the small one will be used ?
<raphink> azeem: you get the idea though ;)
<\sh> what is it?
<raphink> \sh: the idea?
<\sh> raphink: is it a debian symbol on top of the ubuntu logo?
<raphink> well the idea is to merge both logos
<raphink> so my first attempt is to try to put them one on the other :s
<raphink> I'm very bad at graphic stuff
<\sh> I hope there will be no problems with it
<raphink> hmm
<raphink> well
<raphink> the utnubu team uses both logos aswell
<raphink> http://raphink.free.fr/motumergers/
<raphink> oops
<raphink> http://www.pro-linux.de/NB2/images/indiv/utnubu.png
<raphink> there
<\sh> is it really the official logo of utnubu?
<azeem> I think that was pro-linux who did that
<\sh> or is it from pro-linux self made
<raphink> oh ok
* StevenK growls at albatross.
<raphink> Bildmontage, kein offizielles Logo  Ren van Bevern
<raphink> right
<StevenK> Not only can't it build if you aren't root, the packaging is complete and utter crap too.
<StevenK> I'm suprised the fricken Build-Depends are right.
<\sh> StevenK: albatross?
<StevenK> Some useless python module.
<\sh> doesn't it work with fakeroot ?
<StevenK> \sh: The FTBFS is due to a packaging error.
<raphink> so ok I guess merging the logos is no good idea ;)
<raphink> forget it ;)
<StevenK> It tries to create a file in /var/log
<\sh> StevenK: bah...
<StevenK> Which, duh, fails.
<\sh> StevenK: who is the package maintainer/
<\sh> ?
<StevenK> Fabian Fagerholm <fabbe@debian.org>
<\sh> StevenK: well...good to know :)
<\sh> at least no bug we invented :)
<StevenK> Right. :-)
<StevenK> Now I get to ram the fixes down his throat.
<StevenK> I wish my @u.c address so I could wave that in his face.
<StevenK> s/\(address\)/\1 worked/
<StevenK> \sh: If this thing builds and installs, can I get you to upload it?
<\sh> StevenK: sure
<StevenK> Thanks.
<\sh> StevenK: don't do this...it would only raise more violent rants...and I'm tired of it...
<StevenK> I've been ignoring it, it works for me.
<StevenK> I'm > < close to unsub'ing from -devel anyway
<StevenK> Right. Fixed.
<\sh> StevenK: debdiff ?
<StevenK> \sh: http://wedontsleep.org/~steven/albatross_1.33-1ubuntu1.debdiff
<StevenK> I was preparing it.
<\sh> done
<StevenK> Danke
<StevenK> With that, I go to bed.
<\sh> good night StevenK
<ogra> pfft, so the domain name is only a fake ?
<\sh> which domain name?
<\sh> oh wedontsleep
<ogra> :)
<sistpoty> hi folks
<Gloubiboulga> hey sistpoty
<\sh> what a joke
<\sh> an NMU in ubuntu ;) at least a type of :
<\sh> Maintainer: Fabian Fagerholm <fabbe@debian.org>
<\sh> Changed-By: Steve Kowalik <stevenk@debian.org>
<sistpoty> hehe
<Riddell> someone care to update swfdec? http://www.schleef.org/swfdec/download/
<Kyral> Morning MOTU
<raphink> hmmf
<raphink> hi Kyral
<Kyral> sup?
<raphink> hmm
<raphink> trying to find out how I can send an html page by email
<raphink> that has a link to an image
<raphink> so you can open the page and see the image
<raphink> without having to make a tarball
<raphink> ;)
<raphink> lol
<raphink> nothing to do with motu work as you see ;)
<Kyral> lol
<Kyral> multipart MIME?
<raphink> hmm
<raphink> what do you mean?
<Kyral> I dunno I just heard that in my Linux Cookbook
<Kyral> gimme a sec to pull it out
<raphink> haha
<raphink> ;)
<raphink> ok
<Kyral> hmm
<Kyral> it uses the Mail command
<raphink> :s
<raphink> well it doesn't matter much actually I'm sending to it to clever people ;)
<Kyral> You could always download the page and edit the markup to use the absolute link to the image
<raphink> yes
<raphink> well uploading the image somewhere and using an absolute link that is
<raphink> that's an option :)
<Kyral> yah
<\sh> Riddell: doing it
<Kyral> or an absolute link to the image itself (the original location)
<raphink> yes
* sistpoty is off again... cya tonight
<thierry_> what's elmo e-mail?
<\sh> james at ubuntu.com
<thierry_> anyone who could review my package? http://revu.tauware.de/details.py?upid=1414
<Yagisan> G'day All
<thierry_> hi
<thierry_> when is the final date for package to ge in for dapper?
<Yagisan> thierry_: new or merge ?
<thierry_> new
<raphink> thierry_: the 19th
<raphink> next week that is ;)
<thierry_> mmm that's soon
<raphink> yes indeed
<thierry_> I have a package waiting only REVU
<Yagisan> raphink: hmm, that means I should be whipping motu's to advocate my packages then. Care to revu anything I posted (ia32-lib-universe perhaps ;) )
<raphink> yep ;)
<thierry_> ogra, ogra_ibook : could you review my package? http://revu.tauware.de/details.py?upid=1414
* Yagisan thinks wine just likes to mock me
* Yagisan finally gets it to install on amd64, without chroot to be greeted with
<Yagisan> wine: failed to initialize: /usr/lib/wine/ntdll.dll.so: cannot open shared object file: No such file or directory
<Yagisan> :( damm hardcoded libary paths
<Yagisan> G'day all. I have a packaging question that I hope you can help me with. I need to build multiple copies of a package with different configure options, for a debhelperised rules file. The package currently builds 1 binary package from source, but this will need to change.
<Yagisan> I looked at glibcs rules file, as I know it makes multiple binaries from 1 source, but that was a bit too advanced for me to understand
<Yagisan> Can anyone suggest a package that already builds it's source with one set of config flags, the cleans, and builds again with another ?
<azeem> most packages do that by having two build trees
<buxy> Yagisan: check another simpler package, maybe "dia"
<azeem> like, "mkdir build-foo && cd build-foo && ../configure --enable-foo"
<azeem> same for bar
<Yagisan> ahh
<azeem> it helps if the build system supports out-of-tree builds, which some do not
<Yagisan> buxy: grabbing dia now.
<Yagisan> azeem: well I'll find out soon ;)
<Yagisan> buxy, azeem thanks for your advice
<Yagisan> buxy: dia seems very instructive, thank you. now to nuke my mistakes, and try again
<lucas> hi universe :)
<hub> hi multiverse
* hub boot multivac
<Kyral> yo
<thierry_> Kyral : hi, could you review my package http://revu.tauware.de/details.py?upid=1414 ?
<raphink> no he can't thierry_ ;)
<Kyral> I'm not a reviewer
<thierry_> :(
<raphink> thierry_: I could review it, but not advocate
<thierry_> raphink : that's better than nothing, that would show me if something is wrong or not
<raphink> sure
<Kyral> hmm
<Kyral> if the program includes Python..
<Kyral> should I call dh_python
<tseng> if y ou want to use ${python:Depends}
<Kyral> yah I changed it up
<Kyral> whee uploaded to REVU
<raphink> thierry_: I'm reviewing
<lucas> thierry_: good! after spamming this channel for several days now, somebody gave up and is reviewing your package. You should be happy. Can we move to more important stuff now ?
<raphink> lol
<raphink> lucas: mdr ;)
<raphink> I'm afraid I'm gonna give him work though lucas ;)
<raphink> these libs take hours to build
<lucas> also, maybe we should ask somebody from MOTURuby to review the package. I don't really want to have thierry's package in the archive, since he said himself that he wasn't interested in it, he just wanted it in because it's a dependency of another package
<raphink> ic
<raphink> thierry_: comments sent
<thierry_> lucas : sorry for spamming, I just want to get my package in before dapper
<lucas> how many merges/syncs have you done so far ?
<LaserJock> dholbach: ping?
<dholbach> LaserJock: pong
<Kyral> yo
<Yagisan> \sh: wine patch not yet ready. It ran into a snag when I installed it on amd64, and I need to redo my packaging strategy for it. I'm moving to a multiple build system, with different configure flags
<\sh> what snag?
<Yagisan> \sh: libwine.so looks for it's libs in the wrong spot
<\sh> wonderful :)
<Yagisan> \sh: yeah, not.
<Yagisan> night all
<Riddell> why has my pbuilder suddently started going wonky?
<Riddell>     -> copying [chroot/dapper32/root/kdelibs/kdelibs_3.5.0-0ubuntu9_source.changes] 
<Riddell>     -> copying [chroot/dapper32/root/kdelibs/libs] 
<Riddell> cp: cannot stat `chroot/dapper32/root/kdelibs/libs': No such file or directory
<Kyral> I'm wondering when Emacs got a Sources.list mode
<Kyral> oh it was in debian-el
<tseng> koke: woo!
<Kyral> MOTU Meeting today?
<dholbach> when do we start? 2 hours?
<Kyral> yah
<Kyral> 20:00 UTC
<Kyral> what does diff return if the files are the same?
<Kyral> like if I wanted to make an if condition on it
<azeem> try? :)
<Kyral> lol
<Kyral> I did, in bash its nothing
<Kyral> so assume 0 lol
<azeem> nothing?
<Kyral> like <command> then just newlines to the prompt
<azeem> castor~$ diff /dev/null /dev/null
<azeem> castor~$ echo $?
<azeem> 0
<Kyral> lol
<Kyral> okay
<Kyral> Didn't know that trick
<Kyral> ty
<sivang> Kyral: what are you writing ? :)
<Kyral> maintenance script for the lab
<Kyral> or rather the postinst
<Kyral> I basically wanna say if then files related to AFS are different (ie, new versions from the package) then stop AFS, else don't
<Kyral> so I avoid knocking people off when the update cronjob hits
<Kyral> hey LJ
<LaserJock> hi Kyral
<lucas> MOTU meeting is one hour from now right ?
* lucas always has issues with UTC ;)
<Kyral> yah
* LaserJock does too
<Kyral> Oh I <3 responsive upstream!
<LaserJock> Kyral: me too, I also like responsive Debian
<Kyral> lol
<Kyral> That reminds me that I need to file a RFS for Easychem
<LaserJock> It took me 2 days to get plotdrop uploaded to Sid
<Kyral> Did you file a ITP for Plotdrop?
<LaserJock> sure
<Kyral> mind linking so I can use it as a Template? :P
<LaserJock> sure, just a sec
<\sh> cheers guys
<LaserJock> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347330 is the ITP and http://lists.debian.org/debian-mentors/2006/01/msg00096.html is the RFS
<Ubugtu> Debian bug 347330: "plotdrop -- A minimal GNOME frontend to GNUPlot" Package: ITP, Severity: wishlist, Maintainer: wnpp@debian.org</a http://bugs.debian.org/347330
<Kyral> so an ITP is a bugreport?
<LaserJock> yes
* Kyral blinks
<Kyral> stupid question but where is the bug report for Debian?
<\sh> Kyral: bugs.debian.org/wnpp
<Kyral> nm...
<LaserJock> Kyral: I have links on MOTUScience
<Kyral> ah
<Kyral> Feel free to smack me
<LaserJock> I used reportbug and it worked really well
<LaserJock> once I installed exim :(
<Kyral> lol
<Kyral> I have debian-el installed for Emacs so :D
<LaserJock> does debian-el do bug reports too?
<Kyral> According to the page
<LaserJock> dang it, I think debian-el might be the only reason I would use emacs anymore
<Kyral> lol
<Kyral> It even has a debian-bug-intent-to-package
<phanatic> hi people
<LaserJock> hi phanatic
<astronut> I'm a debian package maintainer, and i noticed my packages made it into universe...if there is any diff, it should be in people.u.c/~scott/patches right?
<astronut> and if it's not, there've been no changes?
<phanatic> i've packaged a small gnome applet. could somebody review it?
<Kyral> Should I cc the bug report to debian-devel?
<LaserJock> astronut: if there isn't an -ubuntuX version on your package in Ubuntu then we haven't touched it
<siretart> Kyral: the itp? no, that goes automatically to debian-devel
<astronut> LaserJock: ah, ok
* astronut also isn't so sure you want graphmonkey
<astronut> that package's upstream isn't in great shape
<astronut> there's a new version, but someone expressed interest in adopting, so they were going to package it
<astronut> and i haven't updated my packages because of this
<LaserJock> astronut: but if we were to touch it then it would be in p.u.c/~scott/patches/
<astronut> LaserJock: thanks
<phanatic> i should upload to revu, right? (sorry for being lame, but my first package for ubuntu)
<Gloubiboulga> phanatic, yep
<phanatic> Gloubiboulga: thx
<Kyral> siretart: Emacs asked :P
<LaserJock> is it Bug Day today?
<Kyral> now how do I send the report...
<Gloubiboulga> LaserJock, it was yesterday
<Kyral> in emacs lol
<LaserJock> dohhh
<LaserJock> Kyral: emacs is only the solution when you know how to use it ;-)
<chninkel> Kyral: why can't you use reportbug ? It can't be configured to use a smtp server
<chninkel> Kyral: s/can't/can/
<Kyral> chninkel: Because I <3 Emacs :P
<LaserJock> oppps, /me forgot to include links on the MOTUScience lists
<chninkel> Kyral: :) oh ok
<Kyral> I should install a MTA
<Kyral> how should I config exim for POP3?
<Treenaks> exim doesn't do pop3
<Treenaks> exim does SMTP
<Kyral> oh
* Kyral blinks
<Kyral> this whole Fetchmail MTA thing is new to me lol
<Kyral> So I setup Fetchmail to get the stuff from my POP3 servers, then setup exim to use Fetchmail?
<Treenaks> Kyral: no
<Treenaks> you configure fetchmail to get mail from a pop3 account, and poke it into your exim :)
<Kyral> and sending mail?
<Treenaks> through your local exim, or a smarthost ('your provider's SMTP server')
<Kyral> so I need Sendmail for sending it to the SMTP server
<Treenaks> exim does that part
<Treenaks> it's basically a sendmail replacement
* Kyral falls down
<Kyral> all I want to do is read my email with my console lol
<Treenaks> Kyral: get it on an IMAP server and use mutt ;)
<Kyral> lol
<Kyral> Gmail doesn't do IMAP
<Treenaks> don't use that then
<Kyral> and Fetchmail runs as a daemon then?
<Treenaks> it could
<Treenaks> it can also run from cron
<Kyral> okay...so I am in fetchmailconf
<Kyral> Local Names is the username whose mailbox I want it to be dropped to right?
<Kyral> I have it setup, but both my accoutns are giving me SMTP errors
<chninkel> Kyral: you're talking about fetchmail or exim ?
<Kyral> Fetchmail
<Kyral> at the end it says "fetchmail: Query Status=10 (SMTP)"
<sistpoty> hi folks
<chninkel> Kyral: is exim working ?
<\sh> 10 mins to meeting :)
<Kyral> not yet lol
<LaserJock> hi sistpoty
<Kyral> didn't set it up
<chninkel> Kyral: so that's the reason of the SMTP error
<Kyral> setting up exim
<Gloubiboulga> \sh, meeting is public ?
<sistpoty> Gloubiboulga: yes
<\sh> Gloubiboulga: all meetings are public
<Gloubiboulga> cool
<\sh> we don't have any secrets
<Kyral> how do I find out the "visible" mail name of my computer?
<Gloubiboulga> what is the chan ?
<\sh> #ubuntu-meeting
<Gloubiboulga> thanks
<raphink> #ubuntu-meeting
<raphink> for all meetings
<raphink> well most actually
* Kyral suddenly realizes this is better asked in #ubuntu
<LaserJock> Kyral: i didn't get very far in #ubuntu when I tried :(
<Kyral> LaserJock: what did you set as the visible mail name for your system?
<Gloubiboulga> sistpoty, thanks for advocating my package btw
<sistpoty> np... I guess the french homepage confused me a little bit with the right tar.gz ;)
<sistpoty> (I don't speak french)
<Gloubiboulga> sistpoty, np
<chninkel> Kyral: not really important unless you receive directly mail from outside I think
<LaserJock> Kyral: I honestly can't remember
<Kyral> chninkel: so just set it to local host or whatever?
<chninkel> Kyral: put your computer name
<Kyral> okay..
<Kyral> what machine will act as a smart host..?
<LaserJock> your SMTP server
<Kyral> so mail.gmail.com?
<LaserJock> probably
<Kyral> I can have multiple SMTP servers right?
<LaserJock> not sure, I would imagine. One is enough for me ;-)
<Kyral> College + GMail
<LaserJock> well, I only send out using 1
<lucas> *** MOTU meeting on #ubuntu-meeting NOW! ***
<Kyral> ...
<Kyral> okay...it never asked for the Username +Pass for smtp.gmail.com
<chninkel> Kyral: it will not work
<Kyral> okaaay
* Kyral falls down
<chninkel> Kyral: you'll have to manually modify the exim config file
<chninkel> Kyral: can't you use your provider smtp server ?
<Kyral> chninkel: I have my college SMTP server
<Kyral> but I send GMail stuff through them
<Kyral> because they are nasty, blocking a lot of email addresses
<chninkel> Kyral: configure a smtp server which doesn't need auth
* Kyral falls down
<Kyral> both need auth
<chninkel> Kyral: so you'll have to study exim doc or find a howto
<Kyral> or use a different MTA...
<LaserJock> Kyral: do you just want to send emails out?
<Kyral> yah to the servers
<LaserJock> http://packages.ubuntu.com/dapper/virtual/mail-transport-agent
<Kyral> yah I'm thinking sendmail
<LaserJock> what about esmtp or masqmail?
<Kyral> I dunno
<chninkel> Kyral: sendmail is not really simple toc configure
<LaserJock> esmtp was really easy, if you want to just send mail to your SMTP server
<chninkel> LaserJock: he also wants to receive mail locally
<Kyral> I have Fetchmail
<chninkel> Kyral: but I think fetchmail needs a local smtp server which will deliver to the mail spool
<Mithrandir> chninkel: no, it doesn't, it can deliver to maildrop or procmail directly.
<Kyral> how do you configure estmp?
<LaserJock> http://cvs.sourceforge.net/viewcvs.py/*checkout*/esmtp/esmtp/sample.esmtprc?rev=HEAD&content-type=text/plain
<chninkel> Mithrandir: ok so no problem with a relay only smtp
<Kyral> mda is fetchmail?
<LaserJock> not sure, they use procmail
<Kyral> whee I have it grabbing mail from Fetchmail
<Kyral> exim that is
<Kyral> now I need to have them both running as Daemons
<Kyral> ..which I don't know how to lol
<LaserJock> don't they have /etc/init.d scripts?
<Kyral> ..envermind
<Kyral> now I have to get exim configured fully
<Kyral> hmm
<Kyral> so mail marked read in mutt is moved to mbox?
<dholbach> Vorbereiten zum Ersetzen von mplayer-skins 2-3 (durch .../mplayer-skins_2-4_all.deb) ...
<dholbach> Removing obsolete /usr/share/mplayer/Skin/default
<dholbach> rmdir: /usr/share/mplayer/Skin/default: Not a directory
<dholbach> dpkg: Fehler beim Bearbeiten von /var/cache/apt/archives/mplayer-skins_2-4_all.deb (--unpack):
<dholbach> :)
* Kyral is still figuring out this Fetchmail + Exim stuff
<Kyral> Fetchmail runs as a daemon as my user....and exim runs from init.d...
<Kyral> hmm
<crimsun> 'night, daniel
<dholbach> night daniel
<siretart> buxy: we are currently discussing collaborative maintenance on #ubuntu-meeting, perhaps you'd like to join?
<buxy> siretart: thanks for the notice I'm joining
<crimsun> siretart: mplayer-skins 2-4 (and newer) need to handle the case where /usr/share/mplayer/Skin/default is a symlink
<crimsun> siretart: as in http://paste.ubuntu-nl.org/7031
<siretart> crimsun: gnarf, there must something have gone wrong with my test for directories. Will check that.
<sistpoty> crimsun: are you working only on mythtv or also on the plugins?
<crimsun> sistpoty: just mythtv
<sistpoty> crimsun: ok, I've got a fix for mythplugins here... will obsolete mythgame, mythphone... and other isolated packages
<sistpoty> crimsun: then I'll upload it later on... ok?
<crimsun> sistpoty: sure
<sistpoty> :)
<ajmitch> sigh
<ajmitch> looks like I missed most of the meeting
<ogra_ibook> \sh, are you still working on wine ?
* ajmitch might as well head back to bed or go off & do something else then
<\sh> ogra_ibook: I uploaded 0.9.5 including wmf security patch and uploaded security fixes for wine in hoary and breezy so yes
<Kyral> Yea! I got Exim behaving!
<ogra_ibook> it doesnt work on ltsp it seems
<tseng> oh this again @ #u-m
<ajmitch> tseng: yep
<\sh> ogra_ibook: hmmm...? it works via ssh -X in a i386 chroot on my amd64 :)
<\sh> (notepad actually)
<ogra_ibook> i just have a guy in #edubuntu
<ogra_ibook> #he only sees a black box
<ogra_ibook> but with breezy wine it works
<\sh> breezy wine is a different version...0.9.4 and 0.9.5 changed a lot
<\sh> with 0.9.4 ajmitch had problems with diablo 2 but with 0.9.5 it worked again
<ajmitch> that was a known problem with direct3d support
<ajmitch> because they don't do proper regression testing
<\sh> ogra_ibook: which application?
<ogra_ibook> \sh, if you want someone to help debugging, ask platos in #edubuntu
<\sh> ogra_ibook: thx :)
<siretart> crimsun: whats wrong with this: http://paste.ubuntu-nl.org/7034
<crimsun> siretart: rmdir fails on symlinks. I'd first test -L DEFAULTDIR
<siretart> argl. and test -d follows symlinks.. argl. right
<siretart> I need to exit 0 if DEFAULTDIR is already a symlink
<crimsun> right
<crimsun> I guess it's -h for bash
<crimsun> or -L
<thierry_> what's the difference between the menu file and the app.desktop file?
<crimsun> menu -> Debian menu; .desktop = fd.o desktop file
<thierry_> k
<phanatic> is a menu file needed, if there's a .desktop available?
<tseng> menu as in debian/menu?
<phanatic> yeah
<tseng> thats pretty much different
<tseng> its for the old debian menu system
<phanatic> does ubuntu need that?
<tseng> we dont really require you have one
<phanatic> okay :)
<tseng> some weird people probably still use it
<phanatic> is a man page needed for a gnome app?
<phanatic> (that's the only lintian message left)
<rbelem> g'evening all
<rbelem> i have a software license question
<rbelem> There is 3 liceses LGPL, GPL and "do whatever you want"
<rbelem> in the package, but different files
<rbelem> which license is closer to "do whatever you want"?
<rbelem> and how to put 3 licenses in debian/copyright? some thing like this http://paste.ubuntu-nl.org/7036?
<siretart> crimsun: I just uploaded mplayer-skins_2-5 featuring a check for symlinks. works for me, but feel free to upload over it if you find another problem with it
<siretart> I'll be in bed soon [tm] 
* rbelem need to rest...
<rbelem> g'night all
<siretart> rbelem:
<siretart> rbelem: 'do whatever you want' does not sound dfsg free to me
<rbelem> siretart: :)
<siretart> :)
<rbelem> siretart: may i sugest to upstream author bsd license?
<thierry_> does autotools.mk install the .desktop file, or is it only gnome.mk who does it?
<rbelem> siretart: or is there other that descibe better?
#ubuntu-motu 2006-01-18
<siretart> rbelem: bsd and mit sound fine to me
<siretart> gn8 folks
<tseng> mit is the loosest ive read
<rbelem> g'night siretart and thanks for you help ;-)
<rbelem> tseng: is mit closer to 'do whatever you want'?
<tseng> yes
<rbelem> hum... nice!
<rbelem> tseng: can i put these 3 licenses in debian/copyright?
<tseng> hrm why all 3
<\sh> good night gentlemen...
<rbelem> there are many files. many with gpl and lgpl and just one with "do whatever you want"
<tseng> hm yeah
<tseng> if those files become mit you can put the three in copyright
<rbelem> nice... like this? http://paste.ubuntu-nl.org/7036
<tseng> sure
<tseng> the format isnt that strict as long as you have all the valid info
<tseng> nothing to sweat over
<rbelem> tseng: nice ;-)
<rbelem> thanks so much tseng ;-)
<tseng> yep
* Kyral kills exim
<tseng> rbelem: esp if the files dont have proper headings
<tseng> rbelem: you may want to list files under either license
<tseng> respectively
<LaserJock> Kyral: it isn't nice to kill
<rbelem> tseng: there are many files without headers :/
<tseng> yeah thats not good news
* Kyral replaces with postfix
<rbelem> tseng: I have ask then to put headers in all files
<tseng> does the COPYING file reference what part is what
<tseng> ambiguity is pretty useless
<rbelem> there is not COPYING :/
<rbelem> tseng: http://revu.tauware.de/details.py?upid=1484
<rbelem> i just uploaded, but need many changes
<Kyral> gah
<punkrockguy318> Hello! How can I become a motu?  I'm an experianced UNIX user with knowledge in C, Python, Bash, and BASIC.  I've done a lot of packaging for Arch Linux, and a little debian packaging.  Where do I start?  I actually have a package I've made that I would like to contribute but I don't know what to do.
<Kyral> I keep getting smtp "Space Shortage"
<rbelem> punkrockguy318: wiki.ubuntu.com/MOTUDocumentationDraft
<chninkel> Kyral: what is your problem ?
<Kyral> chninkel: I have exim4 setup to email to GMail
<lamont> Kyral: and is it a _large_ file?
<Kyral> the email?
<rbelem> punkrockguy318: sounds nice?
<Kyral> its just mailing list stuff
<chninkel> Kyral: you set up smtp auth with exim ?
<punkrockguy318> rbelem: yes
<chninkel> Kyral: with the smarthost I mean
<Kyral> chninkel: yah
<Kyral> it sends fine..
<rbelem> punkrockguy318: cool ;-)
<Kyral> but lemme pastebin the fetchmail stuff
<punkrockguy318> i think i'd be interesting in contributing more to ubuntu then just bug reports/mailing list opinions and the ocassional patch
<Kyral> http://paste.ubuntu-nl.org/7039
<lucas> gnight
<chninkel> Kyral: what do you have in /var/log/exim4/mainlog ?
<chninkel> good night lucas
<lucas> punkrockguy318: https://wiki.ubuntu.com/MOTU
<lucas> (better entry point)
<LaserJock> wow, the LP teams converstation is hard to follow ;-)
<Kyral> http://paste.ubuntu-nl.org/7040
<chninkel> Kyral: ?? Didn't you launched exim twice ? or as an unprivileged user ?
<Kyral> maybe
<Kyral> lol
<Kyral> I should reboot
<Kyral> clear the system a bit
<chninkel> Kyral: linux is not windows, you shouldn't have to reboot
<Kyral> yah but just to make sure
<Kyral> I have been putting daemons up and down like nuts
<chninkel> Kyral: netstat -taupe
<chninkel> Kyral: and find the process listening on smtp port (25)
<Kyral> nothing is...
<Kyral> okay I had to sudo
<Kyral> exim is
<Kyral> http://paste.ubuntu-nl.org/7041
<LaserJock> darn, I wish I hadn't had to leave the meeting >:(
<Kyral> ooops
<Kyral> I started exim as user
* Kyral smacks himself
<Kyral> bbiab
<Kyral> okay that worked lol
* Kyral feels stupid now
<Kyral> okay before I make another idiot mistake, should I start fetchmail as my user or using init.d?
<lifeless> depends on how you have configured it
* Kyral falls down
<Kyral> lets put it this way, I can run fetchmailconf as a user and the tests go fine :D
<Kyral> I'll just throw it to the background...
<phanatic> goodnite
<Kyral> ITP for EasyChem sent
<LaserJock> good
<Kyral> got fetchmail and exim going too
<LaserJock> that's funny I got exim working to do my ITP too
<Kyral> lol
<Kyral> but I did it with Emacs
<Kyral> now I'm trying to figure out how to filter all the email..like into folders lol
<LaserJock> well, I have thunderbird for that
<Kyral> lol
<Kyral> I got tired of having to SSH -x when I wanted to check mail
<Kyral> now I just C-a C-C in Screen :D
<Kyral> and I don't know if it got sent lol
<Kyral> Emacs said it did
<LaserJock> well, now you get to wait, it took a long time to get a response from BTS
<Kyral> meh
<Kyral> I need to know how to turn off the headers for Mutt
<womble> Kyral: Farting in bed always does it for me
<crimsun_> 'h'
<Kyral> ..
<ajmitch> Kyral: and if that's not good enough, you can tell mutt what headers to ignore by default
* ajmitch has about 15 header items that are ignored in ~/.mutt/muttrc
<LaserJock> apple.just started shipping iMacs with an Intel Core Duo chip, anybody know what that is all about? is it PPC?
<LaserJock> I don't think it is, but what is it then?
<jamessan> nope. you can tri-boot OS X, Linux, Windows
<LaserJock> so what is the arch ia64?
<jamessan> ia32, afaik. this one isn't 64-bit
<jamessan> just dual core
<LaserJock> oh
<LaserJock> well sweet
<psusi> you just answered your own question... Intel != PPC ;)
<jamessan> I'm surprised you hadn't heard about them making this decision months ago
<LaserJock> I'm glad I waited a couple days to submitt the PO
<Kyral> mutt is nice though
<Kyral> quick and efficient
<Kyral> and I got the email back from BTS
<psusi> ia64 = Intel's Itanium processor
<LaserJock> jamessan: I heard about the decision I just thought it was in a year or so
<jamessan> ah
<LaserJock> They say it is 2-3 faster than the G5s they were shipping
<raphink> that's what they say
<jamessan> too bad they didn't go with AMD. AMD's dual core chips are much faster than Intel's
<raphink> when they released the G5 they said it was much faster yet it was shown the statistics were not exact
<LaserJock> so if I were to install Ubuntu what would I install, the i386 cd?
<raphink> not that I don't like macs, I do ;)
<lifeless> if you have an ix86 yes
<raphink> lifeless: the question in on intel macs
<raphink> I guess
<psusi> I don't think it will just work... it's using an intel chip, but I think the mac bios still boots differently
<raphink> s/in/is/
<lifeless> raphink: oh, in which case dont both
<lifeless> *bother*
<lifeless> unless you are ready to write an x1600 driver
<psusi> I've seen a few messages going around talking about a special lilo required to boot from the mac bios
<raphink> LaserJock: did you read the thread on ubuntu-dev ML ?
<jamessan> it's not actually a bios, iirc. something called EMI
<raphink> psusi: yes, elilo
<raphink> EFI
<LaserJock> raphink: about what?
<jamessan> ah, EFI
<raphink> about that LaserJock ;)
<psusi> I believe that is just what they call the different partition arrangement and how the bios boots it
<raphink> Plans for Ubuntu on new Intel Macs?
<raphink> thats' in ubuntu-devel
<raphink> sent yesterday
<LaserJock> oh
<raphink> LaserJock: http://archives.free.net.ph/thread/20060112.193136.f8f7dc00.en.html
<raphink> there
<Kyral> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347849
<Ubugtu> Debian bug 347849: "easychem -- Draw high-quality molecules and chemical 2D formulas" Package: ITP, Severity: wishlist, Maintainer: wnpp@debian.org</a http://bugs.debian.org/347849
<raphink> ;)
<ajmitch> sigh, so many zope merges to get through this week
<ajmitch> so many debian bugs to file
<ajmitch> 215 open merge bugs, 1 week till UVF
<ajmitch> we're in for a fun week alright
<raphink> :s
<raphink> yes
* raphink won't be there this week
* Kyral grumbles about the MuttWiki being frozen
* ajmitch wonders what he should do with the 2 zope packages removed from unstable & dapper :)
* raphink will try to get ubuntu computers around and an internet acess to work
<ajmitch> since one of them still has users, at least
<raphink> :s
<raphink> what is zope?
<LaserJock> I think that we should go through see what merge bugs should be marked as fixed
<ajmitch> web application server
<ajmitch> a rather major python work :)
<raphink> ok
<raphink> LaserJock: +1
<raphink> LaserJock: did you read the url I sent you?
<LaserJock> yeah, I just got that in my last ubuntu-devel digest
<raphink> ajmitch: what is wrong with it ?
<ajmitch> raphink: eh?
<raphink> hehe
<raphink> ajmitch:  2 zope packages removed from unstable & dapper <--- why were they removed?
<Kyral> Now that the ITP is filed should I file a RFS?
<ajmitch> because they were orphaned & unmaintained?
<LaserJock> maybe I will have to be a guinea pig for this ubuntu on intel macs thing
<raphink> hmm that's a reason to remove them from Debian ajmitch
<LaserJock> Kyral: if you have a package ready to go
<raphink> but is it a reason to remove them from ubuntu?
<ajmitch> raphink: I am aware of that :P
<raphink> ;)
<Kyral> LaserJock: I should run a test in my SidPbuilder first...
<ajmitch> there are 72 zope packages in universe sources
<LaserJock> wow
<raphink> ouch
<ajmitch> 29 on my list to merge
<LaserJock> anbody on the MOTURuby team here?
<raphink> LaserJock: you want to buy a new mac?
<LaserJock> I am buying 2 for the lab
<raphink> nice
<ajmitch> although I have 39 zope merge bugs open
<raphink> they're a bit expensive for me
<LaserJock> I was going to send the PO today
<LaserJock> raphink: that is what government money is fore
<raphink> otherwise mabye I'd go for a new mac laptop
<raphink> LaserJock: hehe
<ajmitch> which indicates that a few have been done somehow, whether by being removed or not
<raphink> I'd like to be sure it can boot on ubuntu though :s
<LaserJock> well, I'm going to take my Ubuntu box home so I will be able to ssh to it at least
<raphink> these look nice http://store.apple.com/Apple/WebObjects/francestore.woa/91501/wo/8U2ippnIOxgu2uQGK4z1kieujyh/0.SLID?nclm=MacBook&mco=32B42242
<Kyral> I <3 SSH
<raphink> :)
<ajmitch> looks like another zope package to sync
<psusi> ahhh, nice... spinning down my hard disks DOES make it quieter in here
* ajmitch throws it on the pile
<Kyral> lol
<psusi> now if only I could get my case fans under the control of the OS
<Kyral> I cannot sleep without my case fans doing :D
<psusi> the CPU fan is spun down but not the case fans
<raphink> Kyral: I got used to it
<raphink> my comp is VERY noisy
<raphink> but you get used to it realy ;)
* ajmitch is very very glad that most of these zope merges are in fact syncs
<psusi> hehe... I used to leave my old computer on all the time, had dual 10,000 rpm first generation scsi seagate cheetahs
<LaserJock> we've got an iMac in the lab that is very noisy sometimes
<psusi> my friends came over one day and said what the fuck is that jet engine sound?
<raphink> ajmitch: :D :D
<LaserJock> It then overheats and shuts down
<raphink> ajmitch: you still need to get elmo ;)
<psusi> I didn't even notice because I was so used to it, but one of the drives had bad bearings and made a LOT of noise
* psusi wonders WTF woke up his disks
<psusi> back to sleep you bastards!
<ajmitch> raphink: so?
<raphink> hmm so nothing;)
<psusi> ahh, must have been thunderbird... it must be sync()ing...
<raphink> I did several syncs lately
* psusi slaps thunderbird silly
<raphink> assigned the bug to motureviewers
<raphink> tried to ping elmo
<raphink> and they are still waiting :s
<raphink> maybe I should ask a MOTU to ping elmo for me
<ajmitch> elmo is only meant to pay attention to MOTUs
<ajmitch> not random others
<raphink> oh ok
<raphink> ajmitch: then could you have his attention on 3 syncs please?
<ajmitch> maybe
<raphink> https://launchpad.net/malone/bugs/6663
<Ubugtu> Malone bug 6663: "freeciv: merge new debian version" Fix req. for: freeciv (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: Fix Committed http://launchpad.net/bugs/6663
<raphink> https://launchpad.net/malone/bugs/6664
<Ubugtu> Malone bug 6664: "nonfree (Ubuntu) - unrar-nonfree: merge new debian version" Fix req. for: unrar-nonfree (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: Fix Committed http://launchpad.net/bugs/6664
<raphink> and https://launchpad.net/malone/bugs/6682
<bmonty> elmo will do syncs for non-MOTUs if he knows who you are.
<Ubugtu> Malone bug 6682: "eagle: merge new debian version" Fix req. for: eagle (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: Fix Committed http://launchpad.net/bugs/6682
<LaserJock> bmonty: hi!
<ajmitch> raphink: I said maybe
<Kyral> LJ when you submitted Plotdrop did you build with the Ubuntu Revision?
<bmonty> hey LaserJock
<raphink> bmonty: ok
<LaserJock> Kyral: no, I made an unstable package because I needed to fix something anyway
<raphink> ajmitch: I know you said maybe, but I still send the urls
<Kyral> okay
<LaserJock> bmonty: how's the little guy?
<raphink> but I'm going to be right now and it's not a maybe
<bmonty> pretty good from what I hear, but I haven't seen him in a week :(
<LaserJock> bmonty: oh yeah, last I saw you were doing merges in the airport
<bmonty> yup :)
<bmonty> I'm going home tomorrow though
<psusi> hrm... what besides fsync and fdatasync can cause dirty buffers to be flushed?
* bmonty hopes the new thunderbird gets packaged soon
* psusi too
* ajmitch is collecting a good pile of packages to sync
<ajmitch> all of my zope merges belong to only 3 DDs
<ajmitch> wonderful
<tseng> woo
<tseng> good afternoon new zealand
<ajmitch> hello tseng
<tseng> so mjg59 talked me out of a macbook
<ajmitch> nice
<tseng> his last post says the video is highly unlikely to work
<LaserJock> x1600
<LaserJock> yeah, could one use vesa or something?
<LaserJock> opps, should have read farther
<LaserJock> darn, that really sucks
<bmonty> I just realized I didn't eat lunch and that is why I'm so freaking hungry....be back in a few after I get some food
<Kyral> yup
<Kyral> EasyChem builds in Sid
<LaserJock> so did you make a Debian versioned package?
<Kyral> no
<Kyral> this was just to check to see if it built ;P
<psusi> anyone know what /proc/sys/vm/laptop_mode does?
<tseng> yes
<psusi> care to 'splain me? ;)
<Kyral> it monitors things about laptops, mainly battery state
<tseng> combined with hdparm tuning it optimizes battery by queing up writes into big blocks
<Kyral> that too
<tseng> and leaves the disk spun down in the mean time
<tseng> Kyral: it has nothing to do with monitoring anything
<tseng> its a sysctl
<Kyral> tseng: oh
<Kyral> lol
<Kyral> I must have been thinking Laptop-Mode
<Kyral> the package
<tseng> (which *monitors* what?)
<psusi> hrm... maybe I shuld try enabling it... I tweeked dirty_expire_centisecs and dirty_writeback_centisecs to allow dirty buffers for a long time
<psusi> but something is still spinning up the disks
<Kyral> if the thing is plugged in ;P
<tseng> Kyral: acpi-support does that
<Kyral> oh
* Kyral feels stupid
<tseng> acpi-support calls laptop-mode, blanks the screen, and various other things
<psusi> let's see how long they stay spun down for now...
<Kyral> LJ you think I should build a Debian Revision?
<tseng> psusi: eh i have a feeling you put a 1 in laptop mode
<psusi> damnit... they came back up
<tseng> psusi: you should use the user space tools and read the manpage
<psusi> tseng, yea, I just did
<tseng> hdparm is half the battle
<psusi> I got hdparm to spin them down with -y... but they come back up after 30-60 seconds
<LaserJock> Kyral: ask ajmitch, but I would think so
<LaserJock> so I wonder if it would be possible to set up a chroot or pbuilder in OSX
<ajmitch> Kyral: yes, you must
<ajmitch> Kyral: the package has to have unstable or experimental as distribution
<ajmitch> and a proper debian version number for a good reason
<Kyral> so -1 ;P
<psusi> aha, reading this script is splaining some things better
<ajmitch> what's the ubuntu version?
<Kyral> 0ubuntu1
<ajmitch> then yes, -1
* psusi thinks it is syslog that is syncing
<psusi> hehe... this is like a game of clue
<ajmitch> yay, 25 packages to sync out of the 29 I had on my list
* sistpoty should have never tried to fix mythplugins
<LaserJock> so are we using the revu.tauware.de list for merges/sync anymore?
<sistpoty> LaserJock: yes, I update them every 2-3 days
<ajmitch> LaserJock: yes, we are
<ajmitch> sistpoty: I've got packaged removed in dapper & unstable on that list
<ajmitch> and I've got 10 more zope merges than my script tells me I should ;)
<ajmitch> I'll track down which ones they are in a minute
<sistpoty> ajmitch: it cannot handle removals...
<tseng> that post is months old
<tseng> er
<LaserJock> so there are only 19 pacakges left to sync/merge?
<ajmitch> LaserJock: hah!
<ajmitch> LaserJock: see the number of accepted packages
<LaserJock> yeah, that is what I don't understand
<sistpoty> LaserJock: left to sync/merge without anybody caring for it yet ;)
<psusi> hrm... I think I need to do some more hacking on my fixed acpi dsdt to get the case fan to spin down now... hehe
* ajmitch takes pydb
<LaserJock> why is accepted so large? I was doing each one as I went, maybe other's aren't?
<sistpoty> hm... crimsuns list is huge
<LaserJock> well, I think we might want to clean up accepted
<sistpoty> would be a good idea...
<LaserJock> I think there are quite a few merge bugs not closed
<ajmitch> sure
<LaserJock> maybe
<ajmitch> nearly all of mine that I've done are closed
<ajmitch> I only have 3 non-zope merges on that lsit
<ajmitch> 2 of which are merged, the other one was FTBFS
<LaserJock> so what is the best/easiest way of determining if a merge bug should be closed
<ajmitch> seeing if the package is built on all archs, and the merge is done
<sistpoty> well, not all arches... ia64 has quite some probs right now
<sistpoty> po-debconf  *cough*
<LaserJock> ok, so I am looking a zsi and the bug report status has "Fix released" so isn't that closed?
<sistpoty> LaserJock: if it's fix commited, just tell me or s.o. with tiber access to update it
<ajmitch> maybe some evil malone changes have done something as well
<sistpoty> ajmitch: you bet... I only figured that 2 days ago (and adjusted the mail-parser)
<ajmitch> sistpoty: yeah..
<ajmitch> ok, got 10 zope-* merge bugs that are packages removed from unstable & dapper
<ajmitch> yay for diff & madison-lite
<sistpoty> ajmitch: want to delete them yourselves, or should I do it?
<ajmitch> you can
<ajmitch> ~ajmitch/zope-not-on-list
<ajmitch> on tiber
<ajmitch> sistpoty: and then I've only got 4 remaining zope packages that actually need merging ;)
<sistpoty> ajmitch: ok, will be gone in a minute ;)
<ajmitch> thanks
<sistpoty> np... done
<LaserJock> ok, so I will try to go through the accepted list and look for stuff that is already "fixed"
* ajmitch quickly merges pydb
<sistpoty> LaserJock++
<ajmitch> LaserJock: nautilus-python is 'fixed', but I want to get the version from experimental done instead
<LaserJock> k
<Kyral> hmm
<Kyral> in Mutt
<Kyral> when I read something
<Kyral> its transferred from /var/mail to $mbox?
<LaserJock> ok, so what about Malone bug #6643
<Ubugtu> Malone bug 6643: "xzoom: merge new debian version" Fix req. for: xzoom (Ubuntu), Severity: Normal, Assigned to: MOTU Merge Team, Status: Confirmed http://launchpad.net/bugs/6643
<crimsun_> LaserJock: http://lists.ubuntu.com/archives/dapper-changes/2006-January/004538.html
<LaserJock> crimsun_: so it should be "fix released", correct?
<crimsun_> I haven't checked ia64, but it builds on our 3 release arches, yes.
<LaserJock> ia64 is failed
<ajmitch> we can ignore ia64 for now
<LaserJock> so I am changing status to "fix released"
<crimsun_> it ftbfs on ia64 due to issues unrelated to xzoom
<crimsun_>   debhelper: Depends: po-debconf but it is not going to be installed
<crimsun_> E: Broken packages
<sistpoty> hm... libghemical ftbfs on ia64 but due to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224.
<Ubugtu> Error: Unknown bugtracker
<sistpoty> but I guess I'll mark that fixed as well
<LaserJock> not sure, azeem was talking to upstream about that I thought
<Amaranth> Ubugtu needs to be less spammy
* ajmitch uploads
<sistpoty> LaserJock: oh, k. I will mark it as fixed on the list, but leave the bug from me open then
<ajmitch> sistpoty: down to 203 accepted! :)
<sistpoty> wohoo
<ajmitch> I'll send off this list of syncs to elmo somehow
<ajmitch> might be best to email
<crimsun_> yes, it's better to e-mail
<ajmitch> 25 at once will be a lot to type out on irc
<LaserJock> sistpoty: actually I can't rember what azeem said specifically he might have said that about another ghemical bug
<sistpoty> LaserJock: don't remember that as well... but the bug is still there, so you have an excuse to break uvf for bug-fixing ;)
<LaserJock> lol
<LaserJock> ok for xwit there are two different merge bugs filed
<ajmitch> LaserJock: that can happen
<ajmitch> LaserJock: either 2 people at once, or it needed merged twice
<sistpoty> seems more like needed merge twice
<ajmitch> like pydb just did
<ajmitch> and qemu might
<ajmitch> since qemu only built on i386, I think
<ajmitch> (debian's fault :) )
<sistpoty> file a bug :P
<ajmitch> it's known in debian, I meant
<LaserJock> of course it's always debian's fault ;-)
<psusi> ohh, badass... lm-profiler... how does THAT work?!
<ajmitch> once these syncs are through I'll have very few merge bugs still open ;)
<ajmitch> crimsun_: are most of yours still open ?
<psusi> hrm.... blast... reiserfs kernel thread is what keeps syncing.... guess I'll have to start looking at that beast...
<crimsun_> ajmitch: probably, I've been way too tired to close them. I'll do that tonight when I get off work.
<ajmitch> crimsun_: ok, so they're done but not closed? that's not too bad :)
<crimsun_> right, done but not closed
<ajmitch> excellent
<LaserJock> so given-back is not good in buildLogs, right?
<sistpoty> oh, dholbach is listed for eclipse... but not a merge bug
<sistpoty> LaserJock: no
<sistpoty> is eclipse handled separately in ubuntu, or a normal merge?
* ajmitch shrugs
<LaserJock> so xtalk has i386 succesful and amd64 given back, so should I halfway close it?
<sistpoty> LaserJock: what do you mean with "halfway"?
<sistpoty> LaserJock: amd64 is rc, so this shouldn't be closed
<LaserJock> well, I was mostly kidding
<sistpoty> fix halfway commited :)
<LaserJock> but it would be kinda nice to be able to track arch's better
<ajmitch> yes
<ajmitch> I think I might whip up something quick for the lists
<ajmitch> have something that shows the build status of each package per arch
<sistpoty> cool
<ajmitch> it shouldn't be hard, we know the version number of each package
<ajmitch> just parse filenames
<LaserJock> crimsun_: xsidplay was a sync, correct?
* sistpoty is out for a cigarette
<crimsun_> LaserJock: xsidplay |  1.6.5.2-2 | http://archive.ubuntu.com dapper/universe Sources
<LaserJock> k, I'll close the bug
<LaserJock> btw, how did you get that output
<crimsun_> ``apt-cache madison xsidplay''
<LaserJock> ah, thanks. I've been trying to figure out where that comes from for a few days
<Kyral> okay time to file an RFS for EasyChem
<psusi> any amd64 users care to test/comment on my fixed defrag package up on revu?
<ajmitch> Kyral: good luck
<Kyral> ty
<LaserJock> Kyral: azeem should sponsor you
<LaserJock> you might ask him directly before you email debian-mentors
* ajmitch wonders why people speak of 'filing' an RFS
<Kyral> dunno
<LaserJock> cause you file ITPs
<Kyral> sending?
<ajmitch> LaserJock: sure, but that's putting them in a BTS
<LaserJock> well, sure but to us beginners sometimes the acronyms got all mixed up ;-)
<ajmitch> kids these days..
<LaserJock> now if it was MOTUItp or UniverseRFS I would have it down ;p
<LaserJock> you just have to have the right prefix
<LaserJock> do we care about sparc and hppa failures?
<ajmitch> not really
<ajmitch> noone actually uses them :)
<LaserJock> hmm, this is odd, according to the buildLogs xonix has been merged sinc March 2005 for everything but sparc and hppa
<ajmitch> 1.4-21 vs 1.4-21.1
<ajmitch> http://people.ubuntu.com/~lamont/buildLogs/x/xonix/1.4-21.1ubuntu1/
<LaserJock> doh
<lamont> universe/games/xonix_1.4-21.1ubuntu1: Installed by buildd-hppa+bld-3 [optional:uncompiled] 
<ajmitch> apache sorts differently
<lamont> ajmitch: if someone wants to provide me a hack to make it sort better.... :-)
<ajmitch> heh
<ajmitch> evening lamont  :)
<sistpoty> hi lamont
<lamont> howdy.
<lamont> about to head home, actually
<ajmitch> working late tonight?
<sistpoty> lamont: time left to clear dep-wait from boson-base?
<lamont> all things are relative...
<sistpoty> he, thx :)
<lamont> sistpoty: done
<sistpoty> thx lamont
<Kyral> LJ you want me to CC the ubuntu science list?
<LaserJock> Kyral: for you RFS?
<Kyral> yah
<LaserJock> umm, why don't you just email azeem and ask him to take a look at it
<lamont> sistpoty: actually, I just pretended that automake1.6 was available everywhere...
<Kyral> lol
<Kyral> is azeem here?
<LaserJock> not presently
* Kyral shrugs
<Kyral> I'll just send it off
<sistpoty> lamont: it doesn't b-d on automake1.6 any longer (if I did it right)
<lamont> right
<lamont> but anything else that b-d: automake1.6, well, it'll get retried too
<LaserJock> Kyral: he offered to sponsor chemistry related packages in debian-science(and ubuntu-science) ML
<sistpoty> oh, cool
<Kyral> oh lol
<lamont> universe/games/boson-base_0.11-0ubuntu1: Dep-Wait by buildd-hppa+bld-4 [optional:uncompiled] 
<lamont>   Dependencies: xlibmesa-gl-dev
<lamont> what about that one?
* lamont bets he can clear that too
<sistpoty> would be good, but I guess I should fix it first?
<lamont> nah - that's hppa, I figure
<lamont> unless it has that build-dep and shouldn't...
<sistpoty> it should actually :)
<LaserJock> Kyral: lol, that was a very informative email you just sent debian-mentors ;p
<Kyral> haha
<Kyral> I am quite to the point
<Kyral> unless Mutt screwed up and its blank :D
<LaserJock> well, since DDs are psychic you should be ok ;-)
<Kyral> Fetchmail hasn't hit another cycle lol
<ajmitch> yes, wonderfully informative
<Kyral> what is it lol
<Kyral> it hasn't come back to me
<ajmitch> I'd be jumping up & down to sponsor this package
<ajmitch> 'Greetings'
<Kyral> thats it?
<ajmitch> but of course it's a gpg-signed greetings
* Kyral stabs mutt
<Kyral> WTFmate?
<ajmitch> that, and a gpg sig
<Kyral> mutt broke lol
<ajmitch> PEBKAC
<Kyral> yah yah
<Kyral> I feel like an idiot
<Kyral> okay okay I fix
<Kyral> this time using Evolution
<LaserJock> hmm, has anybody gotten any emails of me closing bugs?
<ajmitch> yes
<LaserJock> I haven't
<minghua> LaserJock: I do
<LaserJock> to universe-bugs@u.c ?
<ajmitch> yes
<LaserJock> well that's odd
<ajmitch> why?
<LaserJock> I didn't get any of them
<Kyral> Better?
<LaserJock> lol, http://raw-output.org/20060113/solutions
<LaserJock> yeah, except you really didn't need to do that I don't think
<Kyral> huh?
* ajmitch waits for mail to trickle in
<LaserJock> like I said, you could have just emailed azeem
<Kyral> Yah well lol
<ajmitch> you didn't need to grab a shovel & start digging
<Kyral> I knew that addy off the top of my head :D
<LaserJock> Kyral: I could have given you his addy
* Kyral shrugs
<Kyral> I'm gonna get snackage
<LaserJock> well, regardless it is good to get the RFS out there
<LaserJock> ajmitch: when did you send the "merge/sync compiled on all arches" email for pydb?
<ajmitch> LaserJock: about 2-3 minutes ago
<LaserJock> hmm, I got that but nothing from me
<ajmitch> LaserJock: mailman might be set not to send email from you, to you
<LaserJock> bummer
<LaserJock> I can see them on the archive though so at least I can see what I did
<ajmitch> sigh
<ajmitch> I need to update my lpbugs.py obviously
<LaserJock> why?
<ajmitch> because it send an email saying it's fixed
<ajmitch> launchpad rejects that now
<ajmitch> The 'status' command expects any of the following arguments:
<ajmitch> unconfirmed, needsinfo, rejected, confirmed, inprogress, fixcommitted, fixreleased
<LaserJock> oh, yeah. that would be a problem
* ajmitch closes manually for now
<LaserJock> does \sh's lpbugs.py work? or is that what you are using?
<ajmitch> that's what I'm using
<LaserJock> so will the revu merge update if the Assigned To is MOTU as well as MOTU Merge Team?
<ajmitch> not sure
<ajmitch> probably not
<ajmitch> actually they both have bug mail going to the same place
<ajmitch> so it'll depend on the email parser
<LaserJock> I don't think they do
<ajmitch> ah well
<LaserJock> so should I reassign them or just fix them manually?
* ajmitch shrugs
<ajmitch> I can probably close merges on tiber
<psusi> I swear I just want to beat the everliving shit out of synaptic when I click upgrade and it goes... duh... ok, removing xxxxx
<LaserJock> I can too, I just wondered if it was better to reassign them
<psusi> WHY do you want to remove xxxx?  sheesh...
<ajmitch> LaserJock: ah, you have tiber account now?
<LaserJock> yeah
<LaserJock> got it the other day for MOTUScience but sistpoty showed me how to close bugs a little bit ago
<minghua> I suppose the "upgrade" button in synaptic is actually the "dist-upgrade" command in apt/aptitude?
<ajmitch> LaserJock: right, using update_status.py there
<ajmitch> minghua: it's an option in synaptic
<LaserJock> ajmitch: right
<minghua> ajmitch: I see.  pusi: you probably want to tinker that option, then
<psusi> I don't think it's doing a dist-upgrade
<ajmitch> psusi: upgrade alone will not remove packages
<sistpoty> ok, I'm off to bed... gn8 everyone
<ajmitch> night sistpoty
<psusi> it just decides to remove packages either bacuse they are obsolete and that was intended, or because the ones I said to upgrade depend on packages that conflict or things
<LaserJock> cya sistpoty
<ajmitch> psusi: which is what dist-upgrade is..
<ajmitch> unless you're marking some to install & then telling it to do it
<psusi> hrm..... well, I mean half the time it is SUPPOSED to remove things... so it should... I don't want it not to... or it wouldn't let you upgrade
<ajmitch> which is neither upgrade nor dist-upgrade
<psusi> I just wish it would explain how it arrived at the conclusion that it should remove things... and let me tell it NO do not remove that one!
<minghua> psusi: try aptitude :-)
<psusi> it's whatever happens when you click upgrade
<minghua> it tells you the reasons, and it lets you specify packages not to be removed
<minghua> actually I think apt-get can do the latter too
<psusi> aptitude does?
<psusi> hrm... I like the gui though ;)
<psusi> but I should try aptitude... heard it tracks deps and can remove unused deps... I don't see why all the apt tools don't do that...
<minghua> because apt doesn't keep that information (installed as a dependency or not) in its database?
<psusi> yea... I know... why doesn't it/
<psusi> heh
<ajmitch> psusi: because you haven't written the code to do so
<psusi> hehe... I'm working on 12 other things right now ;)
<ajmitch> and so are the apt maintainers
<LaserJock> argghh, I keep renaming the stupid bugs
<ajmitch> LaserJock: that's a silly thing to do
<ajmitch> LaserJock: it could also affect the merge pages
* ajmitch hasn't seen it crash & burn with a traceback yet
<LaserJock> for some reason the search page and status page look alike to me and then I go to do a new bug search and end up renaming the package name
<LaserJock> looks like it just reappered on the merge page, I can manually fix it
* ajmitch closes a few non-ajmitch merges
<LaserJock> darn it, I hate it when I screw stuff up like that
<ajmitch> LaserJock: are you using madison-lite, or looking at build logs?
<LaserJock> build-logs and madison
<ajmitch> right
<ajmitch> madison-lite shows what archs a binary is built on
<ajmitch> if you know the binary package name
<LaserJock> ok
<ajmitch> apt-cache showsrc will show you binary packages
<LaserJock> right
<ajmitch> I should throw those 2 together
<ajmitch> slowly getting down towards 190 or so assigned :)
* ajmitch should have 25 syncs to close once elmo processes them
<LaserJock> hmm, I get "/usr/bin/madison-lite: can't open mirror directory './dists' " when I try to run it
<ajmitch> on tiber/
<ajmitch> ?
<LaserJock> no, on my local machine
<ajmitch> it needs to be configured & the files put in place
<LaserJock> ok, I'll just use tiber
<ajmitch> and an update script run every few hours :)
<LaserJock> cool
<LaserJock> oh wow, it has unstable and all the Ubuntu releases
<ajmitch> yes
<ajmitch> we got it working nicely :)
<LaserJock> i'll say
<ajmitch> I'll have to fix it properly for experimental now
<ajmitch> ok, fixing..
* ajmitch waits for lists to update
<ajmitch> this is taking awhile to update todat
<ajmitch> s/todat/today/
<LaserJock> maybe you need to manually change it
<LaserJock> I've had to do ~5 that way so far
<ajmitch> manually change what?
<LaserJock> the status
<LaserJock> or is that not what you are talking about
<ajmitch> I was talking about madison-lite :)
<LaserJock> ohh
<LaserJock> sorry
<ajmitch> but yes, I've had to do manual changes as well
<ajmitch> at least the list is looking a bit better now :)
<LaserJock> yeah
<LaserJock> I thought that we had more done but then I realized that I hadn't always remembed to close the bugs since I waited for the buildLogs
<ajmitch> I've gone through a couple of times & closed mine that should have been closed
<LaserJock> so do you think I could assume that if a ubuntu2 version got through and there were two merge bugs that they both should be closed?
<LaserJock> or should I just let crimsun handle that?
<ajmitch> close them both
<ajmitch> we'll go through all the open bugs sometime later, to do a proper cleanup
<ajmitch> in case we miss some
<LaserJock> k
* ajmitch wonders what triggers the MoM email parsing on tiber
<LaserJock> parseMoMFile.py?
<ajmitch> no, parseEMail.py
<ajmitch> but I'm looking for what calls that
<Kyral> hmm
<Kyral> has anyone replied to my email?
<ajmitch> ah, sistpoty's .forward
<ajmitch> Kyral: what email?
<ajmitch> LaserJock: be thankful that my list stands at about 113 merges for main & universe, based solely on source package versions
<LaserJock> wow, that's a lot
<LaserJock> how many for main?
<ajmitch> LaserJock: no idea
<ajmitch> btw, xmakemol?
<ajmitch> closed or not?
<ajmitch> hm, not closed
<ajmitch> but the bug points elsewhere at the moment
<LaserJock> oh, crap
<LaserJock> what?
<LaserJock> that is one I (of 2) that I accidentally renamed
<ajmitch> yeah
<ajmitch> whoops ;)
<LaserJock> I think it is ok now though
<ajmitch> 178
<LaserJock> sistpoty said that he would blame me for anything going wrong with revu since he gave me an account, I guess I might be earning that ;p
<ajmitch> coming down slowly
<ajmitch> haha
<LaserJock> ok, so if it hasn't built on AMD64...?
<ajmitch> don't close yet, move on
<LaserJock> doh, it hadn't built on sid but it did on dapper, I wonder why?
<ajmitch> no idea
<LaserJock> dang it ajmitch, I was working on xdb
<ajmitch> that's debian's problem :)
<ajmitch> oh?
<LaserJock> ;-)
<ajmitch> you mean it hadn't built on sid amd64?
<ajmitch> if so, it didn't matter at all
<ajmitch> we only care about dapper :)
<LaserJock> don't let any DDs hear that, oh wait, you are a DD :)
<ajmitch> :P
<ajmitch> yay, soqt is ftbfs on dapper
<LaserJock> ok, I'm starting from the top of the list now, you keep taking all of mine
<ajmitch> haha
<ajmitch> sorry
<LaserJock> so amd64 we keep, ia64 we close?
<ajmitch> hm?
<ajmitch> ia64 is not a release arch, so I think we're fine ignoring it for now
<LaserJock> so only i386 amd64 and ppc are release archs, correct?
<ajmitch> yep
<LaserJock> I wish Malone tracked the package version that the bug was reported against
<ajmitch> it's amazing that it doesn't really
<ajmitch> when you consider that this is meant to be for distributions to use
<LaserJock> yeah
<LaserJock> who works on Malone?
<ajmitch> bradb & bjornt are the two I know of
<LaserJock> doesn't seem like very many but I suppose they are canonical employees?
<ajmitch> yes
<ajmitch> 165, making progress ;)
<Kyral> can anyone reccommend a good appointment/calandar program? Preferably console based?
<LaserJock> emacs
* Kyral falls down
<Kyral> What mode
<LaserJock> calendar
<LaserJock> I don't know exactly
<LaserJock> it is what my advisor uses
<LaserJock> he uses emacs for virtually everything
<Kyral> ah I see
<ajmitch> 154..
<ajmitch> not bad, that's at least 60 down from earlier ;)
<LaserJock> yeah
<ajmitch> sigh
<ajmitch> the email parser needs a little work
<ajmitch> I end up getting some assigned to me
<ajmitch> and those are bugs I closed
<LaserJock> how often is madison-lite updated?
<ajmitch> on tiber?
<LaserJock> yeah
<ajmitch> wait until I find the cron job :)
<ajmitch> daily
<ajmitch> though I updated it when I fixed it an hour or two ago
<Kyral> I'm begining to get scared
<ajmitch> why?
<Kyral> and all that Emacs can do...
<ajmitch> it's a full OS
<LaserJock> for gnustep-back buildLogs said it built but madison-lite has just source
<Kyral> haha
<ajmitch> LaserJock: when was that?
<LaserJock> 10th
<ajmitch> interesting
<ajmitch> what's the binary name though?
<ajmitch> gnustep-back0.10 | 0.10.2-1ubuntu1 |        dapper | amd64, i386, powerpc
<LaserJock> gnustep-back
<ajmitch> no, that's the source name :)
<ajmitch> madison-lite won't map source->binary
<LaserJock> is what I got from apt-get showsrc gnustep-back
<ajmitch> LaserJock: look in the Binary: field
<LaserJock> gnustep-back
<ajmitch> not here
<ajmitch> Binary: gnustep-back-doc, gnustep-gpbs, gnustep-back-common, gnustep-back0.10
<LaserJock> apt-cache showsrc gnustep-back
<LaserJock> oh, wait
<LaserJock> that is for the previous version
<LaserJock> how is apt-cache different between us
<ajmitch> apt-cache might be showing 2 src records for you
<LaserJock> ajmitch: http://paste.ubuntu-nl.org/7052
<ajmitch> LaserJock: apt-cache is showing me a much newer version here, which matches what is in dapper
<LaserJock> and your on tiber too?
<ajmitch> nope
<ajmitch> ah, you're using apt-cache on tiber..
<ajmitch> no wonder
<ajmitch> tiber runs breezy
<LaserJock> yeah, ok. well at least I know what is going on
<LaserJock> guess it makes sense that tiber wouldn't be running dapper :-)
<ajmitch> :)
<ajmitch> ok, I'm done up to r now :)
<ajmitch> working up from the bottom
<ajmitch> 142 remaining
<crimsun> yes, apparently the 's's have ceased
<ajmitch> crimsun lives!
<crimsun> just returned from our LUG meeting (it's an hour drive)
<ajmitch> crimsun: I hope you don't mind us closing all your bugs ;)
<crimsun> ajmitch: oh not at all. I've redirected the mail to another folder anyhow. :)
<ajmitch> good :)
<LaserJock> crimsun: yeah, I sure hope I didn't close anything you wanted left open
<ajmitch> some of your open bugs need revisited
<ajmitch> quickplot is 0.8.6-1.1+b1 in unstable, which looks like a bin NMU
<ajmitch> the source is the same, so I'll close the bug
<ajmitch> http://lists.debian.org/debian-devel-announce/2005/11/msg00018.html for binNMU fun if anyone wants to read it :)
<crimsun> LaserJock: puzzled by a few in which you renamed then reverted the source name, though
<LaserJock> crimsun: yeah, for some reason LP pages were confusing me
<LaserJock> and I ended up typing in the name of the next bug search I wanted to do
<LaserJock> and once you hit enter ...
<crimsun> ah
<LaserJock> but I'm sure if revu dies sistpoty will blame me :-)
<minghua> Riddell: ping
<ajmitch> very strange, I wonder why pygame is not autosyncing..
<ajmitch> blacklisted?
<LaserJock> ajmitch: I gotta go now, but I got through the i's . I didn't have enough strength to start k ;-)
<ajmitch> alright ;)
<ajmitch> I'm going through p at the moment, so I'll try & clean up the rest
<LaserJock> cool
<LaserJock> we got rid of close to 100 I think
<ajmitch> :)
<LaserJock> ajmitch: thanks for helping me out an letting me work on it
<ajmitch> it was good to have someone else doing it ;)
<LaserJock> yes
<LaserJock> goodnight MOTU world!
<ajmitch> night LaserJock
<Burgundavia> ajmitch, is there a reason azereus is not in ubuntu repos?
<crimsun> at the time it didn't work with gcj; dunno if its status has changed
<Burgundavia> crimsun, can it not be stuffed into multiverse?
<ajmitch> alright, I think I've managed to get through the whole list
<ajmitch> down to 117 merges
<Burgundavia> ajmitch, you have to finish 117 by UVF?
<ajmitch> Burgundavia: the MOTUs do, yes
<crimsun> Burgundavia: because it's GPLed, it should be universe-ready if it works with gcj
<Burgundavia> crimsun, but even if it only works with sun java, we can treat multiverse like contrib and put it there
<ajmitch> Burgundavia: I can get another 29 off that list easily
<Burgundavia> crimsun, it would prevent a lot of people from adding random repos just to get it
<whiprush> hi guys
<ajmitch> hey whiprush
<ajmitch> what's up?
<Burgundavia> whiprush, great dialog
<whiprush> ajmitch: are you an emacs guy?
<ajmitch> whiprush: depends what you mean - I use it
<whiprush> Burgundavia: it's my second favorite one. :)
<crimsun> Burgundavia: afaik, if an app requires sun/ibm/blackdown jre/jdk, it can't enter even multiverse
<Burgundavia> whiprush, and your first?
<Yagisan> Burgundavia: crimsun: which app ?
<Burgundavia> crimsun, damn
<whiprush> ajmitch: I've been trudging through the debian bts and bugzirra, can you help me with some insight into this: http://episteme.arstechnica.com/groupee/forums/a/tpc/f/96509133/m/247007327731
<crimsun> Burgundavia: though I may be incorrect regarding blackdown, since I think it's in multiverse
<Burgundavia> Yagisan, azereus
<whiprush> Burgundavia: oh, one sec
<Burgundavia> crimsun, yes it is
<crimsun> does azureus work with blackdown's jre?
<Yagisan> Burgundavia: thanks. love that app, need java 1.5 runtime
<ajmitch> whiprush: I've seen that on my box, but only when displaying from a chroot into an nested x server
<ajmitch> and it confused me then too
<Burgundavia> Yagisan, yes. I am trying to keep the number of non-Ubuntu repos among our users down
<whiprush> Burgundavia: http://www.flickr.com/photos/whiprush/8008240/
<whiprush> behold.
<Burgundavia> 1.5 excludes blackdown
<whiprush> ajmitch: yeah, it seems to be some rare thing, I find a few mentions on debian lists, but no reply. tsk.
<Burgundavia> whiprush, that is brilliant
<whiprush> ajmitch: thanks though
<Yagisan> Burgundavia: I run one of those non-ubuntu repos. afaik only ibm and sun are 1.5, haven't tested an opensource java though
<whiprush> Burgundavia: I showed it to mpt at UDU, I think he nearly had a heart attack
<ajmitch> whiprush: awesome gconf dialog
<crimsun> holy mother of ...
<whiprush> the best part is "all further errors shown only on terminal."
<whiprush> like "oh, thanks, how considerate of you ..."
<crimsun> for great justice the terminal would be blank
<Burgundavia> ajmitch, does your list include https://bugzilla.ubuntu.com/show_bug.cgi?id=22291
<Ubugtu> Ubuntu bug 22291: "scribus: new changes from Debian require merging" Product: Ubuntu, Component: scribus, Severity: normal, Assigned to: debzilla@ubuntu.com, Status: NEW http://bugzilla.ubuntu.com/show_bug.cgi?id=22291
<Yagisan> Burgundavia: seems kaffe is making some progess wrt azureus http://www.kaffe.org/pipermail/kaffe/2005-March/101885.html
<Burgundavia> Yagisan, I am baffled by the free javas. How does kaffe compare to gcj?
<Yagisan> Burgundavia: kaffe, gcj, and sablevm all seem to run java apps with various degrees of success. gcj goes to native code iirc, I usually use kaffe
<Burgundavia> Yagisan, why do they all exist then?
<Yagisan> Burgundavia: GPL, LGPL type reasons - most use gnu classpath so are rather compatible
<Burgundavia> Yagisan, what is gnu classpath then?
<Yagisan> Burgundavia: like libc but for java
<Yagisan> Burgundavia: seems some of them target embedded systems too eg jamvm
<ajmitch> Burgundavia: our list includes nothing of main
<ajmitch> Burgundavia: and scribus is main
<Burgundavia> Yagisan, how does any of this get us a drag and drop replacement for sun's java?
<Burgundavia> ajmitch, who would I talk to about scribus so it doesn't just get dropped?
<Yagisan> Burgundavia: no.
<Yagisan> Burgundavia: none is 1.5 complete
<ajmitch> Burgundavia: someone who works on that stuff in main ;)
<ajmitch> Burgundavia: I could do it, but I've never used scribus
<Burgundavia> Yagisan, what about project harmony?
<Yagisan> Burgundavia: for most apps, most are drop-in compatible - not for azureus however
<Yagisan> Burgundavia: never heard of it
<Burgundavia> Yagisan, apache licensed java, based on gnu classpath
<Yagisan> Burgundavia: do we have it packaged ?
<Burgundavia> Yagisan, doesn't exist yet
<Burgundavia> http://mail-archives.apache.org/mod_mbox/incubator-general/200505.mbox/%3CCA4BEB82-3D84-457D-9531-1477DD749919@apache.org%3E
<Kyral> goodnight MOTU
<LaserJock> so will lpbugs.py not work anymore with the LP status changes?
<ajmitch> not without a little hacking
<ajmitch> LaserJock: I got through the list, 117 remaining
<LaserJock> sweet
<ajmitch> 32 of which are mine
<LaserJock> and I just saw a sync
<ajmitch> so I expect to have it below 90 soon
<Yagisan> Burgundavia: It's going really *really* slow on my amd64 box, but kaffe (breezy) seems to be loading azureus
* ajmitch reruns fetchmail
<ajmitch> LaserJock: I see no syncs
<Yagisan> Burgundavia: dumping a lot of java.lang.NullPointerException at the console though
<LaserJock> could you ask elmo to sync aewm?
<LaserJock> ajmitch: its on the new list
<ajmitch> I sent him an email of my syncs only a couple of hours ago
<ajmitch> LaserJock: what do you think of me emailing all merge assignees on the list, warning them they have a week until UVF?
<crimsun> LaserJock: I already asked elmo for a bunch of syncs; that was one of them
<LaserJock> ajmitch: yes, and make sure that we know that MOTUWannabes need to get their merges reviewed
<LaserJock> crimsun: oh, ok
<ajmitch> LaserJock: yes, that's one reason for cleaning up finished merges
<LaserJock> just so I am clear, UVF means no new Debian versions correct? only -ubuntuX versions
<ajmitch> no
<ajmitch> it means no new upstream versions
<ajmitch> where upstream = 1.2.3
<ajmitch> the automatic sync is turned off though
<LaserJock> hmm,  I thought upstream meant debian
<Yagisan> Burgundavia: gcj failed with "GC Warning: Out of Memory!  Returning NIL!"
<Burgundavia> Yagisan, fun. I hate java
<LaserJock> Yagisan: do you read japanese?
<Yagisan> Burgundavia: that was on my breezy box. I need to build a dapper vm to see if it changed
<Yagisan> LaserJock: a little bit
<LaserJock> Yagisan: could you tell me what the version of ewb is from http://www.ascii.co.jp/EWB/
<Yagisan> LaserJock: speak a bit more - why ?
<LaserJock> the characters don't even show up for me right now so the website is a mess
<Yagisan> LaserJock: current version appears to be 3.3
<Yagisan> brb
<Yagisan> LaserJock: current source links http://www.ascii.co.jp/EWB/archives/ewb-3.3-R8.tar.gz http://www.ascii.co.jp/EWB/archives/ewbpatch-3.3-R9.tar.gz
<ajmitch> ok, got a list by assignee
<Yagisan> bbl - customer time :)
<ajmitch> now I can get emailing ;)
<LaserJock> Yagisan: thanks
<LaserJock> is it possible to get a list of bugs for a package from LP?
<ajmitch> yes
<ajmitch> https://launchpad.net/distros/ubuntu/+source/f-spot/+bugs
<ajmitch> for example
<ajmitch> mantha@chem.unr.edu : xmakemol
<LaserJock> but can you get a list of bug numbers
<ajmitch> you only have 1 open merge against your name
<LaserJock> it's not even mine
<ajmitch> I thought you had xmakemol?
<LaserJock> I messed the name on that one so it assigned it to me
<ajmitch> then I'd better reassign it
<ajmitch> sigh
<ajmitch> the bug renaming makes it impossible to tell
<LaserJock> yann is who you want
<ajmitch> but I have to get the right bug again
<ajmitch> ok, 6535
<ajmitch> fixed
<LaserJock> k, thanks
<LaserJock> sorry about that
<ajmitch> ajmitch@ihug.co.nz has 37 packages left as assigned merges
<ajmitch> wonderful!
<ajmitch> there's a few there that are *not* mine
<ajmitch> ok, we're down to 111 merges
<Mez> kyral: ping
<ajmitch> crimsun: you think an email reminder to those with assigned merges is ok?
<crimsun> ajmitch: now? certainly.
<crimsun> we're what, one week out?
<ajmitch> I've just written up a quick script to do so
<ajmitch> you've got 31 assigned merges
* ajmitch has 32 :)
<ajmitch> so between us we've got over half the assigned merges left
<crimsun> that's fine, I'm going through mine anyhow
<ajmitch> yep
<ajmitch> http://paste.ubuntu-nl.org/7057
<ajmitch> for the email I'm sending
<crimsun> looks good :)
* crimsun leaves work(again)
<ajmitch> yay, getting feedback on the mail I sent out
<StevenK> Anyone feel like doing an upload for me?
<ajmitch> for how much?
<ajmitch> StevenK: moin upload?
<StevenK> ajmitch: Yup.
<StevenK> ajmitch: How does my undying love and devotion sound?
* StevenK chuckles evilly.
<ajmitch> coming to LCA? ;)
<StevenK> No, actually.
<ajmitch> a shame
* StevenK is aiming for brownie points with work.
<ajmitch> otherwise I'd accept beer in lieu of love & devotion
<StevenK> I want them to pay for me to go to Debconf 7 in Edinburgh.
<ajmitch> oh that would be nic
<ajmitch> nice
<StevenK> And hopefully, I can take my wife.
<ajmitch> how scary is this moin upload?
<ajmitch> will I be banished from ubuntu for uploading it?
<StevenK> I have no idea how scary.
<StevenK> I can point you at the source
<ajmitch> the source would be a good start
<StevenK> http://wedontsleep.org/~steven/moin
<ajmitch> fetching
<StevenK> I noticed - I was tail -f the apache logs. :-)
<ajmitch> :)
<ajmitch> StevenK: you include your own cdbs still?
<StevenK> What do you mean, my own cdbs?
<ajmitch> I see that debian has rc1 anyway
<ajmitch> moin-1.5.0/debian/cdbs/1/rules/buildinfo.mk
<ajmitch> plus a number of other cdbs files
<StevenK> Oh, blah.
<StevenK> I suspect they can be binned.
* ajmitch ran the diff.g through lsdiff for sanity
<StevenK> I can regenerate the diff.gz if you like.
<ajmitch> ok
<ajmitch> does debian still carry those in 1.5.0rc1?
<StevenK> Yes.
<StevenK> It uses them, too.
<ajmitch> lovely
<StevenK> New d{sc,iff.gz} copied to the webserver.
<ajmitch> how far do you wish to stray from debian packaging?
<StevenK> In terms of the rules file, I've had to do *evil* things.
<ajmitch> oh yay
<StevenK> I've come to the conclusion Jonas can't write Makefiles, so I've basically hacked my own up.
<ajmitch> heh
<StevenK> ajmitch: Did you see my upload of albatross?
<ajmitch> it even has compatibility code for backporting to woody
<ajmitch> no, I don't think I did
<StevenK> http://lists.ubuntu.com/archives/dapper-changes/2006-January/004602.html
<StevenK> Read that, and weep.
<ajmitch> heh
<StevenK> ajmitch: Still looking over my diff?
<ajmitch> sigh, yet more mail from .au waiting for me downstairs
<StevenK> An entire country is mailing you? :-P
<ajmitch> no, just some people in melbourne
<ajmitch> StevenK: besides, you're an experienced DD, I shouldn't need to read the diff much :)
<StevenK> Heh
* ajmitch wonders where control is generated
<ajmitch> StevenK: I see control.in.ubuntu, but where is that used?
* ajmitch hopes it wasn't the cdbs crack that was removed :)
<StevenK> I read through the debian/rules file for the Debian three times, and I had less idea then when I started as to how control stuff was generated.
<ajmitch> that worries me
<ajmitch> I even resorted to grep & found nothing
<StevenK> ajmitch: http://wedontsleep.org/~steven/moin/rules
<StevenK> That's the Debian debian/rules.
<ajmitch> ah, the auto-update loveliness
<StevenK> I think I get it now. You need to call the target ubuntu, and then the update target.
<ajmitch> you're right, this is scary
<StevenK> Hence why I dropped most of it.
<viviersf> elo ajmitch
<ajmitch> hi
* StevenK wonders if he has broken ajmitch.
<ajmitch> I'm still alive
<StevenK> Barely? :-)
<ajmitch> I'm just wondering if you want to have that tiny debian/control file or not
<StevenK> It's what's in breezy.
<ajmitch> since the control.in.* files have a few more binary packages in them
<ajmitch> how will we go when it's time to resync with debian & an upgrade path is needed?
* vurdak is away: I'm currently away, please leave a message
<StevenK> Most of the packages will need Conflict and Replace moin
<ajmitch> can we beat that into the debian maintainer?
<StevenK> I have no idea.
<StevenK> I have some other things I'd like to beat him with first.
<StevenK> Er, beat into him. *grins shiftly*
<ajmitch> :)
* StevenK buggers off to grab stuff for dinner.
<ajmitch> mm, food sounds really good actually
<dholbach> good morning
<ajmitch> morning dholbach :)
<dholbach> hello ajmitch
<ajmitch> hope you don't mine the merge spam ;)
<dholbach> :)
<dholbach> it's not exactly "spam"
<ajmitch> no, I thought it was needed
<ajmitch> I already had one reply from someone giving back their assigned merges
<ajmitch> are the merges you're assigned to really yours?
<siretart> morning folks!
<ajmitch> morning siretart :)
* siretart looks through the list
<ajmitch> :)
<ajmitch> siretart: we're down to ~115 assigned merges now
<ajmitch> after going through & closing those bugs that are merged & built on all archs
<siretart> ajmitch: did sistpoty state somewhere what stat 0,1 and 2 is?
<ajmitch> siretart: in the source
<siretart> I'd like to get helix-player removed, we are already at debian level
<siretart> ok
<ajmitch> 0 = new, 1 = accepted, 2 = done
<ajmitch> you received my nagging about merges also? :)
<ajmitch> siretart: helix-player only works on i386?
<siretart> BUGNEW=0
<siretart> BUGACCEPTED=1
<siretart> BUGFIXED=2
<ajmitch> yep
<siretart> ajmitch: yes, it FTBFS on ppc
<ajmitch> in the source, as I said ;)
<siretart> :)
* ajmitch has had to use it a few times today
<ajmitch> since closing bugs *sometimes* caused them to not close on the merge page, and they became assigned to me
<zakame> hello all :D
<ajmitch> hey zakame
<zakame> hi ajmitch, just arrived in Manila now :)
<ajmitch> cool :)
<jsgotangco> zakame, you're way too eary for Ubuntu Asia Tour
<jsgotangco> :D
<zakame> jsgotangco, perhaps, but not for Ubuntu UPOU Tour ;)
<cain_> oh goodie
<cain_> xorg no work on our new hp proliant
<cain_> :(
<zakame> hey mez_ :)
<mez_> hi zakame
<ajmitch> evening womble
<womble> hi ajmitch
<StevenK> ajmitch: Any news/flames?
<ajmitch> on moin?
<StevenK> Yah.
<ajmitch> no, I've been too busy flaming/getting flamed by an upstream with their sheer idiocy :)
<StevenK> Ah. Debian work. :-)
<ajmitch> yeah
<StevenK> Which reminds me, I need to kill Rocco about POE.
<ajmitch> dotgnu pnet, the 'alternative' to mono
<StevenK> Oh. Sounds positively ghastly.
<ajmitch> horribly broken in debian & ubuntu at the moment
<ajmitch> but I need to get a working snapshot or release in order to close those RC bugs
<ajmitch> it is, trust me :)
<ajmitch> one of the new upstream guys is trying to convince me to ship a copy of gtk#, because novell is evil
<ajmitch> never mind that novell has copyright for both mono & gtk#
<ajmitch> anyway
<ajmitch> </rant>
* StevenK grins.
<ajmitch> moin is ugly & nasty
<ajmitch> and I really don't like it
<ajmitch> therefore I'll probable upload it ASAP to get it off my drive
<StevenK> Hah
<ajmitch> sounds like a reasonable deal?
<Mez> hmm
<ajmitch> hello Mez
<Mez> ajmitch, are you pretty savvy on the whole - DFSG stuff?
<StevenK> ajmitch: Works for me.
<ajmitch> Mez: I can roughly argue my way out of a paper bag, why?
<ajmitch> if not we have StevenK & womble to help out
<Mez> ajmitch - say i'm working with a company - but they want me to sign a copyright transfer for any code they include in the main source
<Mez> does that copyright transfer also mean that 1) the copyright of the packaging gets transferred to them and 2) that it isnt DFSG compatible (debian-specific stuff)
<ajmitch> why would it not be DFSG compatible?
<ajmitch> the copyright holder determines the licensing
<Mez> licencing and copyright is differnt
<Mez> lol
<Mez> nvm
* Mez just figured that bit out
<ajmitch> well it doesn't matter who holds the copyright
<ajmitch> MS could have it, for all it matters
<Mez> ajmitch - I'm a lil confused about it all though - I think I really need to find out whether if i transfer it over to them - whether the copyright for the package (as a whole not the bits i wrote) transfer over to them
<Mez> because if as a whole it transfers to them - then noone else can work on the package and then let me be able to work on it again ...
<ajmitch> that depends on what you sign
<Mez> without getting that person to sign the copyright over
<Mez> lol
<ajmitch> why?
<Mez> because then I wouldnt "own" the copyright of the whole package
<ajmitch> I fail to see how that would stop someone contributing
<Mez> so therefore - by me then modifying it - it would make it so that the package isnt copyrighted by them
<Mez> lol
<Mez> it's confusing
<Mez> I know what I mean in my head
<Mez> ajmitch: basically
<spacey_ki> is it GPL?
<Mez> will this: http://www.ifolder.com/files/1/1a/IFolder_Copyright_Assignment_Agreement_20060106.pdf cause any problems to letting it get in debian archives
<Mez> yes
<spacey_ki> then it doesn't matter right
<ajmitch> if it's GPL, why would it matter?
<spacey_ki> only if they have the copyright, they can also use it differently
<spacey_ki> with another license
<spacey_ki> the same code
<ajmitch> that's like saying that anyone who packages a work that is (C) FSF must sign over to the FSF as well
<Mez> ajmitch: not really - this is me signing a specific agreement for my patches to go into ifolder
<Mez> ] but by signing that - all my work on ifolder (in any way) gets the copyright assigned to novell
<ajmitch> Mez: just like most contributors to GNU projects do
<ajmitch> I assumed that you meant it was some company hiring you to work on some non-free software
<Mez> ajmitch: nope... i wish
<StevenK> steven@broken:~% sudo du -sh /var/cache/pbuilder
<StevenK> 3.7G    /var/cache/pbuilder
<ajmitch> StevenK: small
<StevenK> Hrm. I suspect I may need to clean up.
<Mez> ajmitch: nvm - I just read the following
<ajmitch> probably stray build dirs
* ajmitch did a cleanup as well, now it's only 3GB
<StevenK> Only 9.
<Mez> "Novell grants back to you a non-exclusive - royalty-free, and right to use, modify, and distribute the assigned contributions as you wish
<ajmitch> Mez: stop worrying
<StevenK> One of which is currently chroot()'d into.
<Mez> ajmitch :D nvm - I'm just being an idiot
<ajmitch> it's a fairly standard copyright assignment for a free software project
<ajmitch> yes
<ajmitch> 4645 N   Jan 13 Steve Kowalik   (  52) Accepted moin 1.5.0-0ubuntu1 (source)
<StevenK> Whee
<StevenK> Thanks!
<ajmitch> np
<Yagisan> re
<ajmitch> hi
<Yagisan> evening ajmitch
<ajmitch> how's it going?
<Yagisan> ajmitch: I've had the fun of a user bashing his head against ubuntu's plone
<Yagisan> ajmitch: no matter how hard I try, I just can get plone + linguaplone to work out of the box with the .debs
<ajmitch> really?
<ajmitch> I can get plone going in a couple of minutes
<ajmitch> and linguaplone is meant to just drop in with plone 2.1
<Yagisan> ajmitch: I know the debs are installed, but I'll be buggered if I can find the translate into button
<ajmitch> ah, is linguaplone installed properly then?
<Yagisan> ajmitch: it doesn't show up on add/remove products
<ajmitch> right
<ajmitch> it probably isn't in the zope instance
<Yagisan> ajmitch: ?? then where did it go ?
<Yagisan> ajmitch: upstreams docs don't seem to cover .deb installation
<ajmitch> you install the package, but zope instances need to have the products
<ajmitch> depends how you setup the instance, also
<Yagisan> ajmitch: out of the box sudo aptitude install plone plone-site
<ajmitch> right
<ajmitch> and then you installed linguaplone?
<Yagisan> ajmitch: it's a recommend, so yes
* ajmitch checks plone-site source
<ajmitch> this could be better documented, really
<ajmitch> Addon-Mode: manual
<ajmitch> right
<Yagisan> ajmitch: #plone told me to not use the debs, then ignored me :(
<ajmitch> they can be like that
<ajmitch> zope 2.8?
<Yagisan> ajmitch: yes. test server was a breezy box
<ajmitch> dzhandle -z 2.8 add-product plone-site linguaplone
<ajmitch> and restart your zope instance
<Yagisan> ajmitch: :( unknown product /me feels real dumb right now
<ajmitch> uh
<ajmitch> try : dzhandle -z 2.8 add-product plone-site zope-linguaplone
<ajmitch> or LinguaPlone
<ajmitch> I can't recall which field it uses
<ajmitch> probably LinguaPlone :)
<Yagisan> ajmitch: it was LinguaPlone. Lots of terminal output, now to restart
<Gloubiboulga> hello
<ajmitch> Yagisan: great
<ajmitch> Yagisan: zope does have some confusing concepts :)
<ajmitch> since you don't just install it & run
<Yagisan> ajmitch: restarted now. please let it be working now
<ajmitch> :)
<ajmitch> you will probably need to go into the plone site's add/remove products
<Yagisan> ajmitch: :( still not there
<ajmitch> oh?
<ajmitch> that's interesting
<ajmitch> the zope instance was restarted?
<Yagisan> ajmitch: that sucks - it actually looked perfect for my needs. Yes, I restarted it
<ajmitch> it's usually so easy to get going..
* ajmitch is doing a quick setup now
<ajmitch> Yagisan: I don't think it'll be anything major :)
<Yagisan> ajmitch: no, it's the feeling one gets when the manual and the software don't match up. This is outside my area of expertise though, so it's frustrating
<ajmitch> sigh, of course my zope instance is set to automatic
<ajmitch> so linguaplone is linked in as soon as I installed it
<ajmitch> very useful for me, sure
* tseng wonders at forcing moinmoin to use textile
<Yagisan> ajmitch: breezy, dapper ?
<ajmitch> dapper
<ajmitch> I don't have a breezy box around
<ajmitch> but you can setup a zope instance to be automatic or manual
<ajmitch> lotw                 2.8    addon-mode=all addon-technique=tree-linked userfile=inituser
<ajmitch> plone-site           2.8    addon-mode=manual addon-technique=tree-linked userfile=inituser
<ajmitch> it was automatically linked into lotw
<Yagisan> ajmitch: how about plone-site ?
<Yagisan> ajmitch: thanks for helping me
<ajmitch> ok, it's linked in properly
<ajmitch> for plone-site
<ajmitch> ls -la /var/lib/zope2.8/instance/plone-site/Products/LinguaPlone
<ajmitch> you should see a lot of symlinks
<siretart> ok, wifi-radar injected to collab-maint.
<siretart> http://svn.debian.org/wsvn/collab-maint/ext-maint/wifi-radar/trunk/ - now lets see who is willing to upload it to debian :)
<Yagisan> ajmitch: I don't have that directory
<ajmitch> Yagisan: dzhandle should have added that in
<ajmitch> can you see what the text was when you ran dzhandle earlier? it was completely silent for me
<Yagisan> ajmitch: I'll be back in just a bit - I've got to read the baby - I'll grab the output when I get back
<Yagisan> s/read/feed
<ajmitch> alright :)
<ajmitch> hm, this isn't being helpful to me
<ajmitch> Yagisan: it's installed fairly cleanly now
<ajmitch> with minimal fuss
* ajmitch can translate his homepage into latin now
<mario> hello
<mario> why are postgresql packages so broken? :/
<tseng> they work fine for me. if you have a specific reproducable issue you could please file a bug
<raphink> siretart: could you upload a new version of knmap for me?
<siretart> raphink: where is the package?
<raphink> siretart: shall I put it on REVU?
<dholbach> mario: you should ask in #ubuntu-devel - this is the channel for universe/multiverse maintenance
<mario> k
<siretart> raphink: if the debdiff is small enough, I'd prefer that
<raphink> sure :)
<raphink> uploading :)
<siretart> uploading where?
<raphink> REVU
<siretart> I'd prefer the debdiff itself, I meant
<raphink> I'll give you the rul
<raphink> url
<raphink> http://revu.tauware.de/details.py?upid=1486 siretart
<raphink> :)
<raphink> siretart: and I'll archive it immediatly so it doesn't stay in the queue :)
* StevenK wonders where xfonts-cjk is.
<siretart> oh, its a new upstream. I see
<raphink> yep :)
<raphink> siretart: the changes between beta1 and stable are minor
<siretart> raphink: they are non existent
<raphink> I used the occasion to bump automake1.6 to automake1.9 and checked it builds fine though
<raphink> yes there is one line of code changed siretart ;)
<siretart> raphink: he only changed the year of copyright
<raphink> lol
<raphink> and copyrights updated
<siretart> and the version number
<raphink> no, there is 1 line changed
<raphink> ;)
<raphink> siretart:
<raphink> -{      QString version = QString( "Version 2.0 Beta-1, %1 %2" ).arg( __TIME__ ).arg( __DATE__ );
<raphink> +{      QString version = QString( "Version 2.0, %1 %2" ).arg( __TIME__ ).arg( __DATE__ );
<raphink> hmm actually
<siretart> 12:45:18 < siretart> and the version number
<raphink> well it's the still the version
<raphink> lol
<raphink> yes
<raphink> siretart: well that proves beta1 was stable ;)
<raphink> yet people will rather install 2.0 than 1.99+2.0beta1
<raphink> and 1.99+2.0beta1 is FTBFS since it uses automake1.6 which was removed from dapper ;)
<siretart> thats a valid reason :)
<raphink> hehe
<raphink> :)
* vurdak is back (gone 03:01:02)
<Tonio_> siretart: hi ! can you look at http://revu.tauware.de/details.py?upid=776
<Tonio_> you uploaded it but I cannot find it in the archives.........
<rbelem> good morning people
<siretart> Tonio_: sorry, now I'm a bit too busy ;)
<Tonio_> no pb siretart :) it was just to know if I have to see that with you or elmo in fact ;)
<Tonio_> don't mind, that's not very imporant anyway ;)
<raphink> siretart: it seems you uploaded 1.99+2.0beta1 again instead of 2.0
<raphink> according to what I got from Katie
<Yagisan> re
<ajmitch> wb Yagisan
<Yagisan> ajmitch: it worked for you ?
<ajmitch> yes
<ajmitch> I've got a translation screen open
<Yagisan> hmm
<ajmitch> except my latin is a bit poor
<raphink> siretart: I can ask someone else if you're too busy
<ajmitch> so I can't translate very well
<ajmitch> Yagisan: it turned out that I just had to use dzhandle, and plone's add/remove products
<ajmitch> since it did link in properly
<ajmitch> can you repeat that dzhandle -z 2.8 add-product plone-site LinguaPlone
<ajmitch> and tell me if it gives any output?
<Yagisan> ajmitch: ok
<ajmitch> also the output of dzhandle list-instances
<Yagisan> ajmitch: http://eyagi.bpa.nu/~jamie/addproduct.png
<ajmitch> nice, I get a png
<ajmitch> very verbose
<ajmitch> have you tried this with sudo?
<ajmitch> since one thing I forgot to mention was that I'm doing all this as root on my box
<Yagisan> ajmitch: yep, sudo produced that output
<ajmitch>  ls -la /var/lib/zope2.8/instance/plone-site/Products/
<ajmitch> pastebin it if you can
<Yagisan> ajmitch: might be hard to pastebin, no vmtools in that server
<ajmitch> ah, you're doing all this in vmware?
<Yagisan> ajmitch: yes, before deploying on a real box
<ajmitch> right
<ajmitch> makes life difficult for me ;)
<ajmitch> do you have LinguaPlone in there or not?
<ajmitch> your screenshot didn't help much because it was so limited
<Yagisan> ajmitch: no, not there at all
<ajmitch> any error was probably off the top of the screen
<Yagisan> ajmitch: just a sec then
<ajmitch> it'll probably end up being a zope-common bug that's fixed in dapper or something :)
<Yagisan> ajmitch: the output is all the same as the screenshot, but just a different package name each time
<ajmitch> and is LinguaPlone ever mentioned?
<ajmitch> or anything about addon?
<Kyral> Morning
<Yagisan> ajmitch: never
<Kyral> Mez: very lagged Pong ;P
<ajmitch> since  dzhandle list-products plone-site
<ajmitch> is meant to list LinguaPlone
<ajmitch> but I guess it won't
<ajmitch> do the workaround hack
<ajmitch> cd /var/lib/zope2.8/instance/plone-site/Products/ ; ln -s /usr/share/zope/Products/LinguaPlone/
<ajmitch> see if that works when you restart that instance
<Yagisan> ajmitch: your right it doesn't list it - tryink the hack now
<Hobbsee> filing a dapper bug - are we using bugzilla or launchpad now?
<ajmitch> depends on what way the wind blows today
<ajmitch> probably launchpad by now
<ajmitch> except they're most likely mid-transition
<Hobbsee> right
<Hobbsee> hehe - i thought they were changing!  so i dont seem like a total idiot!
<ajmitch> nah
<ajmitch> Yagisan: I should get a breezy box to test this on
<Yagisan> ajmitch: vm restarting now - you just need a decent vm system
<ajmitch> nah
<ajmitch> I use chroots
<ajmitch> I might play with xen if there are kernels around
<Yagisan> ajmitch: xen isn't a vm system ?
<ajmitch> xen still requires some guest modifications
<Yagisan> ajmitch: the hack works - I have it on the install menu
<ajmitch> good
<ajmitch> probably the bug fixed in zope-common 0.5.16
<ajmitch> Yagisan: disappointing that it didn't work out of the box though
<Yagisan> ajmitch: :( I thought I fucked up rather bad.
<ajmitch> nah
<ajmitch> it'd be hard to screw up something with so few commands
<Yagisan> ajmitch: rm * is a small command too
<ajmitch> sure :)
<ajmitch> oh good, I remembered my alioth password :)
<Yagisan> ajmitch: thank you. /me starts creating a dapper vm to check it is fixed
<segfault> \sh_away: why #6213 was forced to php5 only?
<Gloubiboulga> someone could review http://revu.tauware.de/details.py?upid=1469 ?
<Gloubiboulga> it's a new upstream version of eagle-usb
<ajmitch> have you asked the debian maintainer for a new version?
<Gloubiboulga> ajmitch, no
<ajmitch> because if the debian maintainer updates, as I expect he will, we'd have to merge the changes in
<Gloubiboulga> ok, I'll mail and ask him if he plans to package the new release
<ajmitch> or you could put a wishlist bug in the debian BTS, and point to your package
<Gloubiboulga> ajmitch, ok
<ajmitch> also the Recommends lines in debian/control don't match, since debian & ubuntu have moved to linux-image-* instead of kernel-image-*
<Gloubiboulga> ajmitch, wishlist bugs have to be reported using the wnpp pseudo package?
<ajmitch> no
<ajmitch> they are filed against the package in question (eagle-usb)
<Gloubiboulga> ok
<ajmitch> Severity: wishlist
<Yagisan> ajmitch: in the breezy vm, I just actually selected install of linguaplone form the menu, and got this http://paste.ubuntu-nl.org/7079 :(
<ajmitch> yeah, makes sense
<ajmitch> because I forgot to tell you to symlink the other zope products it needs
<Yagisan> ajmitch: oh, then no need to tell you there is no translate button either ;)
<ajmitch> you need to symlink PloneLanguageTool & PlacelessTranslationService as well
<ajmitch> and Archetypes:1.3/ in the unlikely case it's not there
<ajmitch> 1 or more of those may already exist, of course :)
<Yagisan> ajmitch: done, just needed PloneLanguageTool
<ajmitch> right
<Yagisan> ajmitch: restarting, and will ping you if it's still broken
<ajmitch> it should work :)
* ajmitch is going to go & sleep soon anyway
<Yagisan> ajmitch: thank you it is working now. Hope it works in dapper too
<ajmitch> it works here ;)
<raphink> Gloubiboulga: /!\ eagle-usb est dans main
<ajmitch> raphink: ah you're right
* ajmitch forgets to check such things
<raphink> ;)
<ajmitch> night all
<raphink> night ajmitch
<Yagisan> Goodnight and thanks ajmitch
<Gloubiboulga> arf
<raphink> Gloubiboulga: tu peux demander  ce que ce soit mis  jour
<Gloubiboulga> I forgot to check too
<raphink> Gloubiboulga: j'archive sur REVU, a n'a rien  y faire :(
<Gloubiboulga> raphink, ok
<raphink> essaie de pinger elmo savoir ce qu'il en pense
<raphink> ok?
<Gloubiboulga> yep
<LaserJock> morning everybody
<raphink> hi LaserJock <>< :)
<LaserJock> how's it going raphink ?
<raphink> fine
<raphink> getting prepared to leave :)
<LaserJock> I'm just stuggleing to get awake, early morning docteam meeting
<raphink> oo ;)
<azeem> hi
<azeem> Kyral: where you looking for me?
<LaserJock> azeem: he was doing a RFS but I see on debian-mentors that somebody might have already picked it up
<azeem> cool
<LaserJock> azeem: I suggested he contact you but I guess debian-mentors was easier for him ;-)
<LaserJock> azeem: EasyChem is the app
<azeem> yeah, just read it in the web archives
<azeem> wow, that guy has a list of suggestions :)
<LaserJock> yeah, kyral is going to have fun ;-)
<azeem> I don't think it is bad to patch the Makefile to properly install stuff, as long as he sends it upstream
<azeem> the prefix thing might indeed be more elegantly solved with a flag in debian/rules, if that is honored
<LaserJock> dholbach: btw, did you see the number of merge bugs left on the revu list?
<dholbach> LaserJock: No, not yet - I just saw two merges assigned to me. :-)
<LaserJock> ajmitch and I went through the list last night and closed all the ones that were done so we nocked off ~100 :-)
<phanatic> hi people
<dholbach> WOW
<LaserJock> also when ajmitch's zope syncs go through another 30 some will be done
<xerxas> Hi
<LaserJock> hi xerxas
<xerxas> what's the way of asking for root rights in hoary in gnome ?
<xerxas> gksudo ?
<xerxas> (I want to do a bug report, because of a friend using ubuntu, but I have no ubuntu right now )
<xerxas> The bug is quite simple: gksudo / gksu / gnome-sudo  doesn't warn the user that he has caps lock on
<Kyral> azeem: ping
<azeem> heya
<Kyral> azeem LJ suggested I email my RFS for EasyChem to you before sending it to Debian-Mentors..but I was bored last night and sent the RFS anyway ;P
<azeem> yeah, I saw
<LaserJock> xerxas: I would assume gksudo would be correct but I don't know for sure
<LaserJock> Kyral: did you see the reply?
<Kyral> yah a couple of them
<Kyral> I'm running through my mail list now
<xerxas> LaserJock: seems to me to
<xerxas> LaserJock: btw , gksu , have the same problem probably
<xerxas> and gnome-sudo also
<Kyral> now I need to find a way to automatically strip HTML from mails in Mutt
<LaserJock> xerxas: I think you want to file the bug against gksu
<Kyral> It looks like I should refine my package
<Kyral> I was thinking about rebuilding it with CDBS anyway
<LaserJock> yeah, CDBS will make all your problems disapper ;p
<xerxas> LaserJock: sure
<xerxas> $ dpkg -S /usr/bin/gksudo
<xerxas> gksu: /usr/bin/gksudo
<Kyral> Is that sarcasm?
<LaserJock> Kyral: yes it is
<LaserJock> hi tritium
<tritium> hi LaserJock
<\sh> hehe
<\sh> moins
<LaserJock> hi
<Kyral> I'm not good at detecting sarcasm ;P
* LaserJock hands Kyral his patented (non-DFSG) sarcasm detector
<LaserJock> tritium: are you subscribed to the ubuntu-science or debian-science MLs?
<\sh> fixing boson-base
<tritium> LaserJock: I doubt it.  I'll subscribe
<LaserJock> tritium: I'm using ubuntu-science for the MOTUScience ML you can subscribe at http://tauware.de/cgi-bin/mailman/listinfo/ubuntu-science
<tritium> thanks, LaserJock
<LaserJock> has anybody hacked lpbugs.py to work with the new Malone status naming scheme?
<Kyral> Actually does ReportBug now fully use Malone?
<LaserJock> hmm, not sure
<\sh> Kyral: I don't think so
<\sh> Kyral: for reportbug to work with malone, we need to do more
<Kyral> hmm
<Kyral> ah
<\sh> i'm working on a {g,k}lpreportbugs because of this :)
<LaserJock> how do you get reportbug to spit out the bts's that it knows about?
<Kyral> Okay I most definately love Emacs Apt-Utils
<\sh> reportbug --bts help?
<allee> Hi, is someone working on the FTBFS due to libXft.la is gone?
<\sh> allee: in which package?
<allee> quite a few: grep -l libXft.la /usr/lib/*.la
<\sh> shermann@amd64-home:/usr/lib$ grep -l "libXft.la" *.la
<\sh> libgwenviewcore.la
<\sh> libkdeinit_gwenview.la
<\sh> libkmediapart.la
<allee> ah and some more here: grep -l libXft.la /usr/lib/*/*.la
<\sh> allee: it's all kde
<allee> \sh eh, no libkexif libkipi digikam?  shame on you :)
<allee> \sh can be.  no gnome here.
<\sh> to be honest, i don't have those apps installed or those libs somehow
<allee> \sh np ;)
<\sh> since when is it gone?
<allee> \sh don't know got the first report ~ a week ago
<\sh> most of the kde stuff is rebuild with the latest uploads of riddell...
<\sh> hmmm..dist-upgrading
<\sh> 155mb to fetch....
<allee> \sh yes, but at least gwenview, digikam (0.8.1 soon), libkipi, libkexif are not in KDE 3.5
<\sh> sure..but most matches I had for kcm modules
<allee> + kipi-plugins I assume
<\sh> so I have to check if they're gone just now after dist-upgrade
<\sh> and then we need to rebuild the stuff which is missing :)
<allee> \sh fwiw: in alioth pkg-kde there are libkipi, libkexif and kipi-plugins that are relibtoolized. Depends on ~ 6 instead ~ 27 pkgs
<\sh> well..lets seee
<\sh> oh boson-base fixed and uploaded...will build now as well on amd64 :)
<sivang> hi all
<sivang> are we maloned yet? :)
<\sh> still ongoing :)
<Kyral> dunno
<sivang> \sh: ah still ? :-)
<\sh> sure official ending time i think was 18utc?
<sivang> ah right, something like that
<\sh> but some bugs are already imported :) on of my xterm bugs e.g.
<sivang> \sh: ah, I wonder if my bugs are also imported already :)
<sivang> that is, bugs I filed
<sivang> bugzilla is frozen already?
<\sh> should be
<sivang> I see they're fighting with having the -bugs mls accept the bugmails from malone
<LaserJock> I wish there were more (any?) Debian/Ubuntu meetings in the US, I would really like to go to some
<spacey_ki> LaserJock, organize one with your LoCo team?
<LaserJock> what LoCo team :(
<LaserJock> my problem is that all the meetings I would like to go to are in Europe, which is great for the Europeans but I don't know if I would ever be able to make one.
<LaserJock> I'm not much of a traveler (never really been outside of the US) so maybe it is my own fault
<spacey_ki> There is no LoCo team in US?
<LaserJock> well, a couple are pending but they are far from me
<LaserJock> are LoCo teams supposed to be able to meet in person? or are they just online?
<spacey_ki> We'll not sure how USA LoCo
<spacey_ki> work
<spacey_ki> but in Dutch Loco team, we have ubuntu-nl channel, and meetings once in a while
<spacey_ki> depends on interest
<LaserJock> I would really like to make an Extremadura meeting but they seem to be European only (for the most part at least)
<LaserJock> maybe if the US was as generous at hosting as Extremadura we would get something like that ;-)
<spacey_ki> whats extremadura?
<spacey_ki> LaserJock, you just live on the wrong continent;)
<LaserJock> apparently
<LaserJock> spacey_ki: http://wiki.debian.org/WorkSessionsExtremadura
<spacey_ki> and usa is not so friendly to foreign visitors :p
<LaserJock> well, it's easier if your american ;-)
<spacey_ki> LaserJock, yeah, but good reason not to have meetings in usa ;p
<\sh> no it's easier to have an immigration officer at the airport who was a GI in germany :)
<LaserJock> seems to me there are enough Americans that we would have our own meetings but you Europeans seem to be a little more friendly that way
<\sh> are we?
<LaserJock> seems like it to me
<LaserJock> must be the drinking problem you guys have ;-)
<\sh> lol
<\sh> yeah..european people are drinking and smoking ... and we have the pope :)
<LaserJock> hmm, that must be it, no pope
<\sh> well...amerika has michael jackson, mr. bush, and michael moore .. what do you need a pope for ;)
<\sh> oops..that was the cia...
<Gloubiboulga> :)
<\sh> leaving for a bit...bbl
<raphink> any MOTU here?
<raphink> Riddell: could you upload a package for me please?
<Riddell> raphink: if it's sane
<raphink> sure
<raphink> http://revu.tauware.de/details.py?upid=1486
<raphink> it's a new upstream of knmap
<raphink> there hmm no changes in it lol
<raphink> except it's called 2.0 instead of 2.0beta1
<raphink> _but_
<raphink> it gave me the opportunity to review the package
<raphink> and since automake1.6 was removed from dapper, 2.0beta1 FTBFS
<raphink> so I switch to automake1.9
<raphink> so I'd say while this package is supposed to bring a new upstream of knmap, it mostly makes the package buildable again
<raphink> is that fine for you Riddell ? ;)
<Riddell> raphink: groovy, let me look
<raphink> k ;)
<raphink> MrRio: just out of curiosity : where is your vhost from?
<MrRio> raphink, hey, i donate money to freenode
<raphink> oh ic :)
<raphink> nice
<Kyral> hmm
<Kyral> have I gone too far?
<Kyral> Using Emacs for IRC?
<raphink> lol
<MrRio> Kyral, lol, yup
<raphink> something I hope I never have to do ;)
<Kyral> Well it would be more productive with Screen
<psusi> roflmfao
<Riddell> raphink: looks good, I'll upload
<psusi> who needs ubuntu?  I use emacs for my OS ;)
<Kyral> hahahah
<raphink> thanks Riddell
<raphink> psusi: you should use multideskos ;)
<hub> raphink: are you jayce?
<raphink> hub: do you think jayce could ever become an ubuntu member ? ;)
<raphink> he'd have to study quite a bit ;)
<hub> raphink: he wrote an OS, so why not?
<raphink> je serais meme pas capable de faire des phrases comme les siennes
<raphink> ;)
<raphink> wrote an OS lol
<raphink> hub: tu l'as essay multideskos?
<hub> raphink: c'est pourtant facile:-)
<raphink> ;)
<hub> raphink: non, j'avais pas de PC a l'epoque
<raphink> vas y montre mon hub :)
<psusi> anyone know of a good burn in stress test for ubuntu?  under windows I'd  use prime95
<raphink> lol
<raphink> hub: Tonio_ et moi on a russi  trouver une vieille version de multideskos qui trainait sur un site et  l'installer avec wine
<raphink> lol
<hub> bah. I don't even have wine atm
<raphink> ok
* hub is still trying to get a refund of the Windows
<raphink> argh
<raphink> je te souhaite du courage :)
<raphink> quelle marque?
<hub> I'm fighting with IBM Lenovo
<raphink> ok
<hub> raphink: given that I'm not in France, I don;t have the DGCCRF
<hub> and Competition Bureau Canada seems to be a useless tax money waste
<raphink> ah, not in France ... that's even harder
<Tonio_> there is an OS in dev whose purposeis to be NT compatible.........
<hub> raphink: BBB in the US makes it efficient
<Tonio_> don't remember the name, but that doesn't go quick
<raphink> Tonio_: pff multideskos is already NT compatible
<Tonio_> raphink: that's true ;)
<psusi> ReactOS?  I worked on that for a while
<Tonio_> psusi: that's ist :)
<Tonio_> reactos
<hub> AbiWord runs on it
<raphink> ah ou
<raphink> :)
<hub> we asked for the patch and they said
<raphink> reactos
<hub> "we use your Windows build"
<Tonio_> last time I had a look was at least one and a half years ago
<hub> ....
<raphink> interesting project
<raphink> very ugly but interesting
<hub> not opensource AFAIK
<Tonio_> lol
<Tonio_> I prefere haikuos :)
<raphink> yep I know ;)
<Tonio_> that's the project I love tosee growing
<raphink> hehe
<raphink> and multideskos too ;)
<Tonio_> i learned informatics with beos
<raphink> the project we like to see dying
<Tonio_> so seeing it redevlopped entirely opensource is, well, more than a pleasure !
<Tonio_> raphink: lol
<hub> Tonio_: BeOS you mean?
<hub> Tonio_: I still have a BeBox :-)
<Tonio_> hub: absolutly
<Tonio_> hub: heard about haikuos ?
<Tonio_> very nice project
<Tonio_> raphink: blended uploaded, if you can have a look;)
<raphink> Tonio_: well they're all wrong, cause they compile. A true OS should be crossplatfrom like JavaScript, that you can run in DOS with Windows.
<raphink> ;)
<Tonio_> it takes only 3 minute to revu this
<raphink> hehe
* raphink trains to speak like Jayce
<Tonio_> raphink:  lol
<raphink> Tonio_: well I have to prepare my luggage and go teach a math course in 5 mins so later
<hub> Tonio_: heard of it but I'm no longer interested
<Tonio_> can you imagine this guy has 3 fortunes dedicated to him....
<raphink> Tonio_: lol
<raphink> you don't know anything Tonio_
<raphink> if you managed the memory well, you could just switch from an OS to another with Alt+Tab
<hub> can someone review/ comment http://revu.tauware.de/details.py?upid=1472
<raphink> you all go wrong :p
<hub> it should be good now
<raphink> ok guys I'm leaving
<raphink> ++
<raphink> hub: you're applying for MOTU on next tuesday?
<hub> raphink: yep
<raphink> good :)
<hub> so I can do it tuesday ? :-)
<raphink> ok I'm gone :)
<raphink> bye
<raphink> haha hub  ;)
<raphink> hopefuly on tuesday I can avocate and upload packages :)
<raphink> and lucas and you too ;)
<Tonio_> raphink: you wanted a package : http://revu.tauware.de/details.py?upid=1491
<Tonio_> let go packaging mice themes now !!!!!!!!!
<raphink> lol
<LaserJock> hi Gloubiboulga
<Gloubiboulga> hello LaserJock :)
<LaserJock> Gloubiboulga: do you think you would be interested in maintaning texmaker in Debian?
<Gloubiboulga> LaserJock, I'm thinking about it...
<pef> hello
<Gloubiboulga> salut pef
<pef> Gloubiboulga: salut :)
<Gloubiboulga> LaserJock, are you a DD who wants to sponsor me ? :)
<LaserJock> Gloubiboulga: no, I 'm the MOTUSciene leader who wants to get tex packages in Debian :-)
<Gloubiboulga> ok :)
<LaserJock> Gloubiboulga: not even anywhere close to a DD but I just got a package of my own uploaded to Debian so I thought I would ask
<LaserJock> Gloubiboulga: but I see that there are already 2 ITPs filed for texmaker
<LaserJock> the latest ITP references your package
<Gloubiboulga> could you give me an url?
<LaserJock> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345806
<Ubugtu> Debian bug 345806: "texmaker -- Free LaTeX editor" Package: ITP, Severity: wishlist, Maintainer: wnpp@debian.org</a http://bugs.debian.org/345806
<Gloubiboulga> I'm not really familiar with debian, but I could be a good way to start
<Gloubiboulga> it could be*
<LaserJock> Gloubiboulga: you might want to email the bug reporter and ask him if you could help or something
<Gloubiboulga> yep
<Gloubiboulga> LaserJock, is there any wiki page where I could find informations about the 'ubuntu to debian' stuff?
<LaserJock> hmm, I don't really know of any but if you have simple questions I might be able to help
<lucas> Gloubiboulga: read ContributingToDebian
<Gloubiboulga> Just reading the MOTUScience wiki page at the moment
<Gloubiboulga> thanks lucas
<LaserJock> lucas: oh yeah, thanks
<LaserJock> Gloubiboulga: do you have questions on the process of getting it into Debian or on how to adjust your package for Debian?
<Gloubiboulga> LaserJock, the most difficult part seems to find a sponsor
<LaserJock> Gloubiboulga: it only took me 2 days to get my package uploaded
<Gloubiboulga> (is that a real english sentence?)
<LaserJock> Gloubiboulga: I think if the package is well done and wanted it shouldn't be a problem
<Gloubiboulga> cool
<LaserJock> Gloubiboulga: but you probably should talk to the people who have already filed an ITP since that means they were intentending to work on it
<Gloubiboulga> LaserJock, yep, I will send emails to them
<LaserJock> anybody from the MOTURuby team around?
<lucas> yes
<lucas> I am
<LaserJock> oh, hi lucas
<stratus> Gloubiboulga, problems to find a debian sponsor? try sponsors.debian.net
<LaserJock> I was wondering if the MOTURuby team would be interested in ruby-gnuplot
<lucas> url ?
<Gloubiboulga> thanks stratus
<lucas> LaserJock: it's on REVU ?
<LaserJock> lucas: sorry, it is in Ubuntu but not in Debian, the Ubuntu url is at http://packages.ubuntu.com/dapper/source/ruby-gnuplot
<LaserJock> but it is quite outdated
<LaserJock> and I was wondering if you wanted to get it into Debian
<stratus> Gloubiboulga, np and if you want web space to host the source packages you can check mentors.debian.net
<lucas> it looks broken (unmet dep) and totally outdated
<lucas> so no, it should be removed
<LaserJock> lucas: no, it's just that nobody has been maintaning it
<stratus> is there a project to run piuparts in each package sitting at universe?
<Gloubiboulga> stratus, thanks a lot, I'm just discovering the debian process
<LaserJock> lucas: upstream is active
<Gloubiboulga> REVU is *great* ;)
<stratus> Gloubiboulga, you're welcome.
<lucas> it doesn't even recursively depend on libruby1.8, since libnarray-ruby doesn't exist in ubuntu
<lucas> LaserJock: I'm personally not interested. Somebody from the MOTUScience is ?
<lucas> stratus: just asked somebody by mail about piuparts. I dunno
<LaserJock> lucas: well, I would probably be the one to do it but I don't know ruby so I though that I should try you first
<lucas> I raised the issue during yesterday's meeting but there was no clear answer
<stratus> oh, i see
<stratus> i can run it and put out the logs
<stratus> what's the wiki url pointing to others with these kind of stuff?
<lucas> stratus: mail ubuntu-devel@ about this
<LaserJock> what would the point of running piuparts on universe be? just curious
<lucas> stratus: no need to do it if somebody else is doing this already
<lucas> LaserJock: detect lots of broken packages
<lucas> like ruby-gnuplot ;)
<stratus> lucas, sure that's why i asked here first
<lucas> LaserJock: what's upstream URL ?
<LaserJock> well, I think ajmitch does that anyway
<LaserJock> but maybe I'm wrong
<lucas> LaserJock: he doesn't
<lucas> LaserJock: I found http://rgnuplot.sourceforge.net/, but 2003 doesn't look like active :-)
<LaserJock> lucas: yeah, I think they turned into http://rubyforge.org/projects/rgplot/
<lucas> found that too ( http://rgplot.rubyforge.org ) but the changelog link is broken
<lucas> ok, it seems active
<lucas> do you have a user requesting this ?
<LaserJock> so what will puiparts give us that unmetdeps and FTBFS don't , or is it just an easier way of getting that info?
<LaserJock> lucas: no, I'm just trying to clean up science packages
<lucas> it also checks whether packages install/uninstall correctly
<lucas> LaserJock: ok, I think you can safely request the removal of ruby-gnuplot
<LaserJock> seems like somebody would like to have ruby bindings, there are python and perl bindings
<lucas> (it isn't installable anyway)
<LaserJock> lucas: I don't think it will get removed, I don't think that is the way it works in Universe
<lucas> can you file an RFP and mail debian-ruby@lists.debian.org about this ?
<LaserJock> I suppose
<LaserJock> I just wondered if there was any interest on the Ruby side, it is more of a science thing but I thought I would ask anyway
<lucas> yeah I know universe is about getting as many packages as possible, no matter whether they work or are security risks
<lucas> wait, I'm reviewing the upstream source
<LaserJock> but if it is 4 years old and upstream is still active it seems like we could do something about it
<ogra_ibook> lucas, stop being ironic ;)
<lucas> I'm not ironic, this is true
<LaserJock> I am still unclear about how apt-get.org stuff gets in, is there a wiki or spec on that?
<lucas> dholbach reviews the packages and ask elmo to do the import
<LaserJock> only dholbach?
<ogra_ibook> yup
<LaserJock> ok, well at least I know who to grumble at ;-)
<ogra_ibook> lucas, we wouldnt put this amount of manhours into it if we wouldnt care about the quality
<ogra_ibook> elmo reviews all licenses though
<lucas> I don't critizise the general quality of MOTU work
<lucas> I only disagree about the policy regarding packages which nobody know of
<ogra_ibook> "no matter whether they work or are security risks" isnt a critic comment ?
<dholbach> lucas: we had a *HOT* discussion about this already
<lucas> it is, about packages like ruby-gnuplot which should have been removed a long time ago
<lucas> but are still in ubuntu
<dholbach> then take care of it, tell elmo to remove it, if you are sure about it
<lucas> (ok, ruby-gnuplot is not really a problem, it just is uninstallable)
<ogra_ibook> lucas, note that both, dholbach and me opposed the idea totally in the beginning
<lucas> and you are now thinking it was a good idea ?
<ogra_ibook> yes
<dholbach> believe me: i take this seriously and just to put this into perspective: i imported 40 packages last time
<dholbach> i gave you my view on this already
<ogra_ibook> the target is to get *everything* into universe to gain usability
<dholbach> not "everything"
<ogra_ibook> but not loose quality
<lucas> I'm curious about ruby-gnuplot
<LaserJock> lucas: well, for MOTUScience it isn't to bad because I only came up with 5 packages out of 462 that were a problem
<dholbach> i see this as an effort to reach out to developers who put work into packages
<ogra_ibook> dholbach, everything like in 40 packages that match our quality expectations ;)
<dholbach> It was on Mark's request and I personally think it's a good idea.
<ogra_ibook> me too ...
<ogra_ibook> but out of other reasons :)
<dholbach> A much better one than leave users with an apt/sources.list that is as long as my syslog. :-)
<lucas> do you know where ruby-gnuplot come from ? I'm just curious
<ogra_ibook> dholbach, exactly  :)
<LaserJock> lucas: apt-get.org
<lucas> LaserJock: how did you determine this ?
<dholbach> maybe it was removed from debian and not removed from ubuntu yet
<ogra_ibook> lucas, have you looked at apt-get.org ?
<LaserJock> lucas: I searched for it there
<lucas> ah ok :-)
<LaserJock> lucas: I used your scripts to find science packages in Ubuntu but not in Debian
<lucas> I was wondering wether there was a automatic way of finding out :)
<dholbach> kiwamu@debian.or.jp - I wrote him
<LaserJock> lucas: then I went and tried to track down the 8 that weren't in debian
<LaserJock> lucas: and now I'm trying to figure out which ones should be updated or removed, etc.
<lucas> LaserJock: and 5 of them were broken ?
<lucas> or the broken 5 weren't in this case ?
<LaserJock> lucas: no, 5 were from apt-get.org
<lucas> ah ok
<LaserJock> lucas: probably most were broken
<dholbach> most what?
<lucas> topic change: any MOTU has something against notifying DDs that UVF is on the 19th, and that they should really hurry if they want the latest version of your package in ?
<LaserJock> dholbach: most of the 5 packages from apt-get.org that are science related
<LaserJock> but I already got 1 fixed
<dholbach> cool
<LaserJock> and I don't think ruby-gnuplot should be that hard either
<lucas> we haven't received any bug report about it.
<lucas> users don't care about it
<LaserJock> there is only 1 package that I don't know about and that is mascyma, I can't find upstream anymore
<lucas> I'll see what I can do inside the debian ruby team, but there's really no point in including it in dapper
<dholbach> why not?
<LaserJock> why not
<LaserJock> just because it doesn't have a bug doesn't mean it isn't used
<lucas> The following packages have unmet dependencies:
<lucas>   ruby-gnuplot: Depends: libnarray-ruby but it is not installable
<lucas> E: Broken packages
<LaserJock> your talking about a pretty small amount of people using it and if they don't know any better the won't file a bug
<lucas> if people are using it, I'm curious about how they installed it :-)
<LaserJock> maybe the are using the src
<lucas> LaserJock: ruby-gnuplot's version is 200101xx.
<lucas> 5 years ago !
<lucas> probably ruby 1.6 or 1.4 code
<LaserJock> right, but they maybe using upstreams 2005 version
<lucas> that's why I'll see what I can do inside debian's ruby team
<dholbach> thanks
<LaserJock> honestly, if I am not asking you to do it I just wondered if there is any interest
<lucas> if I have time next week, I'll package it
<lucas> (before UVF)
<lucas> but the current version should be removed from dapper
<LaserJock> s/if//
<lucas> good reason: version is 20010125-1
<lucas> if we upload 2.2-1 to debian, it won't get synced
<LaserJock> lucas: I agree since it should be renamed anyway
<LaserJock> it should be rgplot
<lucas> probably libgplot-ruby, following debian's ruby policy
<lucas> anyway
<LaserJock> but if you guys don't want to do it that's fine
<Q-FUNK> hi! I'd like to know, which lines do I need to put in pbuilderrc to add security and updates?
<dholbach> http://wiki.ubuntu.com/PbuilderHowto
<dholbach> should be pretty straight-forward
<Q-FUNK> dholbach: is not, actually.
<Q-FUNK> dholbach: adding "deb http://archive.ubuntu.com/ubuntu dapper-security main universe" to OTHERMIRROR reports an error.
<LaserJock> I think you can add more with a | perhaps
<LaserJock> I did it once but I can't remember exactly
<dholbach> ah yeah, right
<sistpoty> hi folks
<LaserJock> hi sistpoty
<sistpoty> hey LaserJock
<LaserJock> sistpoty: well, you can blame me for any merge list breakage, I had a little booboo last night
<sistpoty> hm? is it gone? *G*
<LaserJock> I accidentally renamed 2-3 bugs
<LaserJock> I think it is all taken care of though
<sistpoty> you renamed them? or reassigned them?
<LaserJock> renamed
<sistpoty> did you do some sql-hacking for that?
<sistpoty> or did you rename bugs in lp?
<LaserJock> well, not so much renamed but I accidentally put a different name in LP when I was trying to search
<LaserJock> for the source package
<LaserJock> so then it reassigned the bug to me
<LaserJock> when I renamed it back
<sistpoty> ah, i c
<sistpoty> well, then you should care for that merges :P
<LaserJock> but ajmitch and I took care of it
<sistpoty> yeah, I got the mail(s)... that rocks!
<LaserJock> so I actually had the problem with LP not revu.tauware.de I guess, so that means you can't blame me. sweet :-)
<sistpoty> hehe, but you can reassign them with update_status (-a iirc)
<LaserJock> sistpoty: but I did have to move a few to "fixed" with update_status.py so the account did come in handy
<sistpoty> :)
<LaserJock> and my MOTUScience lists are rocking too
<LaserJock> I think the DDs in debian-science are reading them now too
<sistpoty> nice
<LaserJock> so now I should probably try to work on the Ubuntu Packaging Guide so we will have something before string freeze ( I think that is the docteam version of UVF or FF)
<stratus> ubuntu 1
<lucas> LaserJock: which version of multidistrotools are you using ?
<lucas> the one from bzr ?
<lucas> I just did a big commit, you might want to be careful when updating
<LaserJock> bzr but I haven't updated for a while
<lucas> ok
<LaserJock> thanks for the heads up though
<lucas> where do the "Not in Ubuntu" packages come from ?
<lucas> Debian, really ?
<LaserJock> I don't know, I was going to ask that
<LaserJock> I wonder if name changes would do that
<lucas> they really are in debian
<lucas> strange, I don't see them on my listing
<lucas> s
<LaserJock> are you exluding them?
<lucas> yes I am
<LaserJock> on purpose?
<lucas> should be ok now
<lucas> no, wrong copy/paste :-)
<Hieronymus> Where can I find information about "install -m" in debian/rules?
<LaserJock> man install?
<LaserJock> lucas: what is the URL for your list?
<lucas> http://tiber.tauware.de/~lucas/versions/all-packages.html#notinB
<lucas> (but that's for all of debian & ubuntu, so it includes kernel-*
<LaserJock> 178 is quite a few
<LaserJock> but yeah, lots of kernel related stuff
<lucas> they should be hand-examined
<LaserJock> so how does Ubuntu know which ones to include, I thought that new Debian packages were automatically included? Maybe a blacklist or something?
<lucas> probably
<lucas> I'm leaving for the week-end soon. Can you investigate this and keep me updated ? not having octave 2.9 is quite a shame :/
<LaserJock> I thought there might have been some discussion about it but yes it is a shame
<LaserJock> dholbach: do you know why some packages aren't in Ubuntu that are in Debian?
<dholbach> LaserJock: haven't synced them yet? we blacklisted them?
<dholbach> LaserJock: like what?
<LaserJock> dholbach: how can I find out
<LaserJock> dholbach: octave2.9
<dholbach> ask in #ubuntu-devel
<dholbach> elmo will mostly know
<dholbach> or somebody else
<Hieronymus> LaserJock: but can you give me an example package where this is used?
* Hieronymus wants to install a pixmap from /debian
<LaserJock> Hieronymus: where what is used?
<LaserJock> oh, install -m
<Hieronymus> LaserJock: yes, but what should the destination be?
<LaserJock> I have : install -m 0644 plotdrop.png $(PREFIX)/share/pixmaps in a Makefile
<Ubugtu> Malone bug 644: "sharp libgecko-cil (Ubuntu) - Dependencies problem in libgecko-cil" Fix req. for: gecko-sharp libgecko-cil (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Fix Released http://launchpad.net/bugs/644
<LaserJock> lol, I wasn't talking to you Ubugtu
<LaserJock> Hieronymus: but for debian/rules you probably want something like: http://tiber.tauware.de/~lucas/versions/all-packages.html#notinB
<LaserJock> opps, wrong paste
<LaserJock> install -m 0644 debian/plotdrop.xpm $(CURDIR)/debian/plotdrop/usr/share/pixmaps/
<Ubugtu> Malone bug 644: "sharp libgecko-cil (Ubuntu) - Dependencies problem in libgecko-cil" Fix req. for: gecko-sharp libgecko-cil (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Fix Released http://launchpad.net/bugs/644
<Hieronymus> LaserJock: thanks. That seems to be the samen amsn uses - but without the $(CURDIR)
<dholbach> have a nice evening
<LaserJock> cya dholbach
<crimsun> guh, it's difficult to use cvs once I've used git
<Kyral> I don't suppose anyone knows how to get ERC working nicely?
<LaserJock> install irssi ;-)
<Kyral> yah yah
<Kyral> I'm lazy so I don't wanna check Irssi lol
<LaserJock> and using emacs is lazy?
<Kyral> bah
<ajmitch> morning all
<crimsun> moin
<LaserJock> hi ajmitch crimsun
<crimsun> hi LaserJock
<ajmitch> not below 100 merges yet? :)
<LaserJock> as soon as your zope syncs go through it well be ;-)
<ajmitch> sure
<ajmitch> but the open bugs is not going down fast enough
<LaserJock> yeah, less than a week now
<LaserJock> ajmitch: did you send out emails?
<ajmitch> yes
<ajmitch> a nice personalised email to everyone with outstanding merges ;)
<LaserJock> oh how thoughtful of you
<ajmitch> listing what packages they had outstanding
<ajmitch> asking them to hand them back if they didn't have time, or if they were wrongly assigned
<ajmitch> I got 2 handed back already
<ajmitch> also asking them to bug motus for reviews
<LaserJock> how would they be handed back? manually changing them?
<ajmitch>  http://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000051.html
<ajmitch> oops
<ajmitch> sorry
<ajmitch> http://paste.ubuntu-nl.org/7057
<ajmitch> I asked them to send an email tol admin@tiber
<LaserJock> so who's admin@tiber?
<ajmitch> it's an alias of a few of us (siretart, sistpoty, \sh, myself)
<ajmitch> a convenient address for people to contact to get it changed
<LaserJock> oh, ok, so more than one. I was just wondering if was going to only one person who might be very busy ;-)
<ajmitch> no, I'd just get the email & reset the status to unaccepted :)
<ajmitch> doesn't take much work
<chillywilly> hi ajmitch
<ajmitch> hello
<chillywilly> how goes it?
<ajmitch> alright
<chillywilly> cool
* ajmitch was rudely woken up early by a phone call
<chillywilly> did you graduate yet? ;)
<ajmitch> graduate? what's that?
<chillywilly> hehe
* ajmitch is too lazy to do such things
<chillywilly> :)
<chillywilly> I love wiki
<ajmitch> I've been too busy with this ubuntu crack
<ogra_> finished degrees are overrated ...
<ogra_> totally
<chillywilly> you're not just saying that because you haven't finished? ;)
<LaserJock> lol, I'm sooo close, but this Ubuntu stuff is making it hard to want to work
<ogra_ibook> chillywilly, i have never started ;)
<chillywilly> bah ;)
<ajmitch> morning ogra :)
<ogra> heh
* ajmitch feels like doing some debian bug filinf
<ajmitch> filing
<ajmitch> but alas, it seems that I might be going away & offline for the weekend
<crimsun> A degree can never replace experience.
<ajmitch> hopefully I'll be back before UVF :)
<crimsun> ajmitch: have a good weekend, then :)
<ogra> chillywilly, i havent even learned a job ...
<ajmitch> ogra: you just blindly hit the keyboard?
<crimsun> he's got good aim
<ogra> chillywilly, the fun is, that none of my firends who studied actually works in the job he/she learned
<chillywilly> not surprising
<ogra> since i know its not different with my older sisters friends, the logical conclusion is that it must be overrated :)
<ajmitch> yep
<chillywilly> man this day is dragging on
<chillywilly> I think ajmitch is on the 6 year plan ;)
<LaserJock> well, darn it this PhD better be worth something
<ajmitch> 6 year? is that all?
* ajmitch should go for a PhD or something
<ogra> and i obviously had quite good jobs the last 18 years, so it cant be such a wrong assumption ;)
<ajmitch> ogra: except for your current job
<ajmitch> where they work you like a slave
* chillywilly took the 5 year plan ;)
<ogra> thats my own choice ;)
<ajmitch> hehe
<ogra> nobody with a  whip in my living room ;)
* ajmitch would love a job, really :)
<chillywilly> *thwack*
<chillywilly> ajmitch: you're hired ;)
<ogra> ajmitch, we still search for an experienced QA guy :)
<ajmitch> ogra: the problem is 'experience'
<ajmitch> I have experience introducing bugs
<ogra> thats a start :)
<chillywilly> it's funny when you're just sitting in the office and hear somehow burst out laughing real loud down the hall....
<chillywilly> TGIF
<ajmitch> sigh
<ajmitch> 'not a branch', bzr says
* ajmitch updates from 0.6.2
<ajmitch> hey sistpoty
<ajmitch> ran into some issues with the merge pages yesterday
<LaserJock> so if the link to ~scott is 404 what does that mean?
<sistpoty> ajmitch: email-sending rocks!
<ajmitch> manually closing in malone, sometimes didn't show as closed in the merge page
<ajmitch> sistpoty: heh
<crimsun> LaserJock: one or more of the ubuntu/debian base versions couldn't be located at the time MoM ran
<sistpoty> ajmitch: did you tag them as fix released or fix commited?
<ajmitch> sistpoty: fix released
<sistpoty> hm...
<ajmitch> and they got reassigned to me
<ajmitch> so it saw the email
<sistpoty> yep... I'll need to look over the mail-parser again
<ajmitch> I reassigned them all to their rightful owner before sending out the email
<ajmitch> which was a quick hack of a script
<ajmitch> but it seems to have gotten some response, which is great
<ajmitch> thanks to LaserJock we got the list of assigned merges down close to 100
<sistpoty> :)
<LaserJock> ok, so here is a weird one: pessulus is on the "new" list but it has a newer version than sid
<ajmitch> looks like elmo is back & getting into some syncs
<ajmitch> newer than experimental, too
* ajmitch blames seb128
<LaserJock> so should I get rid of it?
<ajmitch> yes
<LaserJock> hmm, is there a way to do it other than sending it to "fixed"?
<sistpoty> LaserJock: I can delete it directly in the database
<LaserJock> oh, cool
<ajmitch> sistpoty has super-admin powers
<Burgwork> https://wiki.ubuntu.com/TeamWiFi <-- should that be renamed MOTUWifi or MOTUNetworking?
<sistpoty> no, only some sql knowledge ;)
<ajmitch> Burgwork: it doesn't have anything to do with MOTUs though
<ajmitch> it's a doc page, not a packaging page
<sistpoty> LaserJock: pessulus is gone
<LaserJock> muahhaha
<Burgwork> ajmitch, true
<sistpoty> ajmitch: found the problem: Fix Committed => Fix Released... "Fix Committed" is more than one word
<ajmitch> hehe
<ajmitch> nice
<ajmitch> thanks for fixing
<sistpoty> np
<sistpoty> I guess I'll do another update of the merge-db
<ajmitch> :)
* ajmitch will try & do his remaining syncs offline on the laptop
<ajmitch> 11:17 < elmo> "allegro4.2", "kde-icons-nuvola", "kde-style-lipstik", "octave2.9",
<ajmitch> 11:17 < elmo> ^-- MOTUs, that's the list of "BROKEN" packages in josie atm
<ajmitch> </flood>
<ajmitch> ;)
<ajmitch> 11:17 < ajmitch> ok, thanks
<ajmitch> 11:17 < elmo> if someone would like to examine them, see if they should be synced or merged, that'd be nice, kthx
<sistpoty> what's josie?
<ajmitch> not sure
<Amaranth> all the buildd tools have women's names :P
<ajmitch> probably a sync script or something :)
<sistpoty> hehe
* sistpoty will care for kde-icons-nuvola and kde-style-lipstik
* ajmitch won't have time to care for any of them
<ajmitch> they might be currently blacklisted
<LaserJock> sweet, I asked about octave1.9
<LaserJock> 2.9 rather
<ajmitch> as these are packages in debian but not in ubuntu
<LaserJock> yes
<LaserJock> well, at least some of them
<ajmitch> octave2.9 & allegro4.2 are
<LaserJock> well, http://revu.tauware.de/~lucas/versions/all-packages.html has the complete list (178 packages)
<LaserJock> of not in Ubuntu but in Debian
<ajmitch> so all 4 of the packages listed are as I said
<sistpoty> hm... kde-icons-nuvola has different sourcepackages in debian and ubuntu... and it's newer in ubuntu
<ajmitch> blame Riddell
<Riddell> hmm?
<sistpoty> I doubt it's your fault, Riddell ;)
<ajmitch> it's kde-* :)
<ajmitch> yeah, amu did the ubuntu revision
<ajmitch> not sure where he got the original package from
<sistpoty> these packages seem to be packaged differently
<sistpoty> (debian and ubuntu one)
<sistpoty> what should we do with it?
<ajmitch> the ubuntu one is probably packaged from some random hacker, or upstream
<sistpoty> should I rename the (ubuntu) package?
<ajmitch> even a rename wouldn't solve upgrade issues
<sistpoty> I'll ask elmo about it
<LaserJock> darn, the "new" list got bigger
<LaserJock> Riddell said to leave kdeaccessibility
<LaserJock> could we remove it from the "new" list for now?
<Riddell> new list?
<LaserJock> the revu.tauware.de merge list
<ajmitch> the list of merges that noone is working on
<ajmitch> for universe
<Riddell> where's that?
<LaserJock> there are a few more k* packages listed there, I wonder if they will be similar
<ajmitch> http://revu.tauware.de/~sistpoty/MoM/index.py?state=new
<LaserJock> Riddell: would kdeaccessibility be the only one that would come in with a new KDE release?
<LaserJock> I would think the others would be released independently but I don't know
<chillywilly> lalala
<Riddell> LaserJock: they'd all come in
<LaserJock> Riddell: oh, ok. I would've thought they were seperate. Is that because kdelibs will be different?
<Riddell> well the whole of KDE is released at the same time
<Riddell> so I'll update them all at that time
<LaserJock> ok, sweet
<ajmitch> see you all later
<LaserJock> cya ajmitch
* ajmitch is away for a couple of days
#ubuntu-motu 2006-01-19
<sistpoty> cya ajmitch
<LaserJock> so sistpoty should we remove the k* packages from "new" so people won't try to merge them?
<sistpoty> LaserJock: yes
<sistpoty> LaserJock: I will do that
<LaserJock> sistpoty: cool
<Riddell> LaserJock: out of http://revu.tauware.de/~sistpoty/MoM/index.py?state=new though only kdeaccessiblity is part of KDE
<Riddell> the rest are independent and won't be updated with a KDE release
<Riddell> sorry, I only just looked at that URL
<sistpoty> Riddell: phew... I only deleted kdeaccessibility right now *g*
<LaserJock> oh, ok. that is what I thought I asked you but I guess you misunderstood
<LaserJock> or I guess I didn't ask the question very well :(
<LaserJock> so kguitar kmatplot kmess and knetfilter will need to be synced/merged, correct?
<Riddell> my fault I'm sure :)
<Riddell> yes
<LaserJock> whew, glad we caught that one :-)
<womble> Note for anyone interested: remove the 'irm' package from Dapper.  It's not release-ready, and I won't have time to make it so before UVF.
<crimsun> womble: if you can fix it, please do. We do have exceptions to UVF.
<womble> crimsun: If I could fix it in time, I would.
<crimsun> womble: not within the next two months?
<womble> You think I'd be saying "rip it out" if I had a real expectation of getting it done in time?
<crimsun> well, it's your call.
<crimsun> your package, you know best.
<womble> If I get laid off or something, and I suddenly get time, you can use the exceptions to put it back in.  As it stands, I do not have the slightest expectation of having the time required to make IRM release worthy in the next couple of months.
<crimsun> fair enough
<sistpoty> oh, come on... there is s.th. wrong again with mails for merge list :(
<sistpoty> hm... seems fixed now :)
* sistpoty is off to bed
<sistpoty> gn8 everyone
<psusi> woohoo!  new dvd/cd-rw drive arrived today!
<psusi> anyone else notice the last day or two's updates broke bash tab completion?
<psusi> it allways adds a / as if everything is a directory ( it's a normal file though )
<\sh> moins
<crimsun> moins
<LaserJock> ajmitch: do you have a minute or are you already gone for the weekend?
<LaserJock> anybody smarter than me around? :-)
<LaserJock> hmm, this can't be good.
<minghua> LaserJock: why is that?  it's bad to be the smartest man in the channel? ;-)
<LaserJock> yeah, when I need help :-)
<LaserJock> I'm trying to get octave2.9 in Ubuntu
<minghua> Hmm, I am interested in that
<minghua> (being the merger of octave2.1 myself)
<LaserJock> yeah, I just remembered that
<LaserJock> elmo's problem was that the octave virtual package in 2.9 clobbers octave2.1
<LaserJock> or something like that
<LaserJock> here is his error:
<LaserJock> [Updating]   octave2.9 (0 [Ubuntu]   < 2.9.4-8 [Debian]  )
<LaserJock> E: octave2.9 is trying to override octave_2.1.71-2ubuntu3 without -f/--force.
<LaserJock> and then the Debian changelog says:
<LaserJock>   * debian/in/control: The octave virtual package is now only generated
<LaserJock>     for the 2.9 branch, but depends on octave2.1, which is the recommended
<LaserJock>     version for end-users.  This is counter-intuitive, but is necessary
<LaserJock>     due to a mistake in uploading the octave virtual package with version
<LaserJock>     2.9.4-1, which is still stuck in unstable.
<LaserJock> so I'm not sure what exactly is going on
<minghua> LaserJock: I think he needs to sync octave2.1 first
<minghua> no, that won't work...  octave2.1 2.1.72-6 still builds octave
<minghua> I probably can patch that
<minghua> but I don't know why octave2.1 is still not sync'ed yet
<LaserJock> hmm, then how does it work in Debian?
<LaserJock> minghua: the changelog indicates that 2.1 should no longer build octave
<LaserJock> or am I reading that wrong
<minghua> LaserJock: let me check
<minghua> LaserJock: the most recent version in sid, octave2.1 2.1.72-8, still builds a arch:all octave binary package
<minghua> LaserJock: I don't know how that's supposed to work either
<minghua> well, if octave2.1 got sync'ed, I'll have more motivation to work on it
<minghua> now I am afraid there is something wrong
<minghua> s/am afraid/worry/
<LaserJock> well, would the sync of octave2.1 take care of it
<minghua> no, it won't
<minghua> but now it doesn't get sync'ed even two MOTUs have requested it, I don't know what I should do
<minghua> maybe I can ask elmo myself, but I don't care octave enough
<LaserJock> when did the MOTUs request the sync?
<LaserJock> ok so here is the octave2.1 changelog entry:
<LaserJock> octave2.1 (1:2.1.72-7) unstable; urgency=low
<LaserJock>    +++ Changes by Rafael Laboissiere
<LaserJock>   * This version use an epoch in his number.  This is necessary due to the
<LaserJock>     mistake I did in uploading the octave_2.9.4-1 virtual package to
<LaserJock>     unstable.  The 2.9.4-1 version replaced the 2.1.72-* version and this
<LaserJock>     is wrong because the 2.1 (testing) branch should take precedence over
<LaserJock>     the 2.9 (unstable) branch.
<LaserJock> I don't quite now what ^^ means
<LaserJock> minghua: maybe we should consult the debian octave group?
<minghua> LaserJock: there?
<LaserJock> yeah
<minghua> I think I'm hit by the server rotation
<minghua> the last thing I see is <LaserJock> minghua: maybe we should consult the debian octave group?
<LaserJock> that's the last I said
<LaserJock> you didn't miss anything ;-)
<minghua> okay, now reading the octave2.1 changelog, it seems octave2.9 should drop the octave binary package
<LaserJock> so maybe we should sync octave2.1 and merge 2.9 taking out the building of octave virtual package?
<minghua> I'm completed confused.  octave2.9 2.9.4-8 still builds octave binary package, but it's not in debian archive
<minghua> I think there is a RC bug here
<LaserJock> yeah, that is what I'm trying to figure out. It seems as if we aren't using the same source or something
<minghua> LaserJock: I _think_ what happened is that octave2.1 and octave2.9 was having a war with the octave binary package
<minghua> first octave2.9 2.9.4-8 was uploaded building octave 2.9.4-8
<LaserJock> and they just let octave2.1 win :-)
<minghua> then octave2.1 2.1.72-7/8 is uploaded building octave 2:2.1.72-7/8
<minghua> LaserJock: exactly.  and with the epoch octave2.1's package win, since binary package must belong to a single source package (this is the part I am not sure), octave 2.9.4-8 is removed
<LaserJock> ahh, I am starting to see
<minghua> someone know how Debian archive works need to confirm this :-)
<Yagisan> G'day All
<minghua> LaserJock: so I think the right way is stop building octave in octave2.9, which we can fix in universe
<minghua> hello Yagisan
<LaserJock> minghua: right
<Yagisan> ajmitch: thanks for the help last night. Now all I need to do is figure out how to replace my apache server with that, and not break my ubuntu/debian repos at the same time.
<minghua> LaserJock: but a debian bug should be filed even we fix them ourselves
<Yagisan> minghua: so how are things going ?
<minghua> Yagisan: quite good, busy though
<minghua> trying to squeeze some time for the new scim packages
<minghua> s/packages/releases/
<LaserJock> minghua: ok, so report a bug that octave2.9 builds octave but only octave2.1 should be doing that ?
<Yagisan> minghua: I understand - I have  a time squeeze myself. I don't have any free time left atm to work on my wine for amd64 patches.
<Yagisan> minghua: looking forward to your new scim stuff though
<minghua> LaserJock: yeah, something like "octave2.9 should stop building octave binary package now that octave2.1 is building it instead"
<LaserJock> ok, and we should merge it in the meantime?
<minghua> Yagisan: freeflying uploaded 1.4.4-0ubuntu1 in dapper, so the code is there, I am mainly working on documentations
<minghua> LaserJock: I would like to see octave2.1 sync'ed first
<minghua> LaserJock: but if we remove octave from octave2.9, it's probably safe
<LaserJock> I'm just thinking about UVF, would octave2.9 be effected?
<minghua> LaserJock: I think so.  But octave2.1 needs to go before UVF too IMO
<minghua> and octave stuff isn't really my priority
<LaserJock> no, I don't know what more we can do with 2.1, I mean you ask elmo and wait
<LaserJock> in the mean time perhaps I will merge 2.9 to take out the building of the virtual package
<minghua> LaserJock: If you really want to do it, merge octave2.9 and drop octave from octave2.9's debian/control, make sure it can coexist with the current octave2.1 in dapper
<minghua> then I think it's safe to upload
<LaserJock> minghua: I already built it in a pbuilder and installed it on my machine
<LaserJock> everything was good
<minghua> LaserJock: without octave binary package?
<LaserJock> but I don't know that I had octave already installed
<LaserJock> but right now I have octave from 2.9
<LaserJock> so I think if I take it out of 2.9 we will be in business
<minghua> install everything from octave2.1 and everything from octave2.9, if nothing bad happens, it's safe enough for me
<LaserJock> hmm, if I go to install something from 2.1 it wants to remove the corresponding 2.9 package
<minghua> (making sure there are no packages with same name, of course)
<LaserJock> in all reality if the DDs don't think 2.9 should be used by users then maybe we shouldn't worry about it for now
<LaserJock> until Debian gets things straightened out
<minghua> yeah, I would think octave2.1 is more important then octave2.9 too
<minghua> s/then/than/
<LaserJock> ok, I am comfortable with just letting Debian sort it out and getting on to other, more important things
<LaserJock> just so I know what is going on though
* Yagisan leaves to take daughter to the park. bbl
<persia> I'm bored and would like to post some useful patches to Malone, rather than just comments suggesting the packages.  Could someone point me a to a good resource for instructions?
<\sh> for attaching bugs, or how to patch sources?
<persia> Specifically, I have a few local compiles for uninstallable packages, and there are clear descriptions to make a patch for bugs #3650 and #3663 (I'm sure I could find more).  I'd like to make a package patch so that the appropriate MOTU would have an easier time making a package for upload.
<\sh> persia: is this issue still there?
<\sh> persia: in dapper i mean
<persia> I've not investigated the bugs I listed yet, but libjackasyn0, brutefir, freewheeling, iripdb, jackeq, kluppe, and seq24 are all unionstallable, although I have local working packages.
<persia> Yes, all in dapper.
<\sh> give me a sec...I need to finish some stuff
<persia> No worries.
<minghua> persia: when you say locak working packages, you mean .deb packages built from dpkg-buildpackage, debuild etc.?
<minghua> persia: in that case debdiff is probably all you need to know
<persia> minghua: Yes.  I just don't know what diff to run before posting a patch to Malone.
<persia> minghua: So, just debdiff repository-package mypackage, and upload that?
<minghua> persia: something like "debdiff <package_old-version.dsc> <package_new-version.dsc>" should be good
<persia> minghua: Thanks.  That sorts it.
<minghua> persia: yes, paste the debdiff to malone
<minghua> handy, huh? :-)
<persia> minghua: Absolutely.  Thanks again.
<\sh> the problem is...with this, there is a conflict
<\sh> with python-elementree...which should be only a meta package with a depends on python2.4-elementtree
<\sh> strange that this happens
<persia> \sh: I'm guessing that there was a transition between a single package and versioned packages, although I've not looked at the history yet.  Are you looking at this now?  Shall I skip it?
<\sh> persia: no..please have a look :)
<\sh> persia: if you need some help, please jell :)
<\sh> yell even
<persia> \sh: OK.  If I fix it today, I'll post a patch.  Thanks.
<\sh> persia: thx...i subscribed to this bug now...so I receive it directly in my inbox instead of my malone bugs folder :)
<\sh> persia: and thx for working on it :) your work is appreciated :)
<minghua> persia: you are very welcome.  as \sh said, thanks for helping :-)
<\sh> trying to solve the qt bugs now'
<\sh> the last comment is quite right :)
<\sh> minghua: you saw the last comment of malone #6606
<Ubugtu> Malone bug 6606: "x11-free (Ubuntu) - qt-x11-free 3:3.3.5-1ubuntu11 causes xim failure" Fix req. for: qt-x11-free (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6606
<minghua> \sh: just saw it.  It makes so much sense now.
<\sh> just fakeroot make -f debian/rules build it now :) to see what is really installed
<minghua> \sh: in GTK the XIM mode is provided by /usr/lib/gtk-2.0/2.4.0/immodules/im-xim.so, so that's very likely the source of the problem
<\sh> minghua: looks like, because I don't have any inputmethod plugins at all installed
<\sh> just libqscim.so
<minghua> \sh: that should belong to scim-qtimm, I suppose?
<\sh> just searching for it...but seems so
<\sh> if this is the case, that files are missing, this should be easily resolvable
<minghua> somebody need to look at what patch SuSE is using, it seems :-)
<\sh> minghua: they are using the same...but installation is included..looks like that we are missing that :)
<minghua> weird.  let me read some build log, then
<\sh> they are not installed when I'm searching for usr/lib/qt3/plugins/inputmethods
<minghua> \sh are they built at all?
<\sh> yes
<\sh>   for /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/imsw-multi/imsw-multi.pro (fast)
<\sh>   for /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/imsw-none/imsw-none.pro (fast)
<\sh>   for /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/simple/simple.pro (fast)
<\sh>   for /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/xim/xim.pro (fast)
<\sh> oh no
<\sh> the makefiles are generated
<\sh> but looks like that building is complety missing
<minghua> I saw those too, with "mv -f libqxim.so ../../../inputmethods/" later
<\sh> cd imsw-none && make -f Makefile
<\sh> make[4] : Entering directory `/build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/imsw-none'
<\sh> /build/buildd/qt-x11-free-3.3.5/bin/qmake  -spec /build/buildd/qt-x11-free-3.3.5/mkspecs/linux-g++ -o /build/buildd/qt-x11-free-3.3.5/./plugins/src/inputmethods/imsw-none /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/imsw-none/imsw-none.pro
<\sh> cd /build/buildd/qt-x11-free-3.3.5/./plugins/src/inputmethods/imsw-none
<\sh> oh it's build ... bah..I hate this build system of qt
<\sh> cp -f "../../../inputmethods/libqimsw-multi.so" "/build/buildd/qt-x11-free-3.3.5/debian/tmp-install/usr/lib/qt3/plugins/inputmethods/libqimsw-multi.so"
<minghua> I saw two identical lines of this cp thing
<\sh> and there it's going to be installed into the correct directory...but there is no such directory for including it into the package
<minghua> so we are just missing a .dirs or mkdir in debian/rules?
<\sh> I think we should create a libqt3-inputmethods package
<minghua> why do they use "cp -f"?  why?
<\sh> to move it from the source dir into the install dir
<\sh> which means: debian/tmp-install/usr/lib/qt3/plugins/inputmethods/* but to package it, it needs a line in one of the .install files in debian/dir but I think it's much better to have a separate package
<minghua> hmm, "cp -f" does give a error message if the target doesn't exist
<minghua> so it's not "cp -f"'s fault, sorry :-P
<minghua> \sh: if separate package, is libqt3-mt going to depend on it?
<\sh> minghua: that's what I have to find out with riddell
<minghua> \sh: at least the problem is clear now, good
<\sh> rational: libqt3-mt doesn't need the plugins to be running and working properly.
<\sh> solution: it could be a recommend or suggest
* minghua doesn't like that solution
<\sh> finally fixing it would be: any installation locale != latin must install it
<minghua> with out this qt-immodule patch, XIM mode works fine in KDE;  now with this patch, XIM users need to install an extra package manually
<\sh> minghua: i don't want to decide it :) I'm fixing somehow now the problem with installing and then we need to find a way to install it directly as dependency of libqt3-mt or something else
<minghua> \sh: no problem, I'm just expressing my concerns
<\sh> is xim installed by default, btw
<\sh> ?
<minghua> well, the protocol is, but you need specific XIM servers to really use it
<minghua> XIM protocol comes with X
<\sh> yes, but scim e.g. is this installed by default?
<minghua> different servers are provided by other programs
<\sh> if not, then the user need to install it somehow manually to get it to work...
<minghua> \sh: not in breezy, and I don't think it's going to be in dapper either
<minghua> \sh: my point is, this works different than Debian (and probably every other distros)
<\sh> ok...so manual intervention of the user is necessary
<minghua> \sh: users don't expect to install extra packges besides XIM servers to get XIM work
<\sh> to be honest, I think it's not installed by default for suse or redhat...they think first, that everybody is using latin inputs
<minghua> and in GTK such stuff comes with libgtk2.0-0
<\sh> ok..so let me discuss this issue with riddell..he is responsible for this ;)
<minghua> libqxim.so is in qt3-3.3.4-28.i586.rpm just for the reference
<\sh> or actually I'll make him responsible :)
<\sh> mandriva?
<minghua> suse
<Gloubiboulga> hello
<persia> A question about debdiff: it there a handy way to exclude config.sub, config.guess, and config.log?  Otherwise the changes are fairly difficult to see [I only intentionally modified the changelog and control file - dpkg-buildpackage did the rest] .
<minghua> in suse linux 10.0, according to http://www.novell.com/products/linuxpackages/professional/qt3.html
<\sh> persia: well..depends how the debian/rules file replaced those files
<\sh> persia: config.{guess,sub} are normally copied during clean target, which is somehow a bit bad :)
<\sh> moins StevenK
<persia> \sh: Yes, these are copied (from /usr/share/misc)  Is there a better way?
<\sh> persia: somehow I'm moving this piece of code ( I think it's starting with if in the rules file, as shell if) into the configure target
<minghua> persia: I think the preferred way is to rm them in clean target, and copy them in configure/build target
<\sh> and removing it in the clean target
<\sh> persia: the default dh_make behaviour is somehow outdated (IMPOV)
* minghua agrees with \sh
<\sh> minghua: ok...the inputmethods are installed in the tmp-install dir...so it's a matter of including them in the package itself...
<\sh> fixing it now
<persia> grumble.  Perhaps I'll go back to posting solutions, as I doubt anyone wants to read these (last update of the package I was looking at was October).
<\sh> persia: I fix libqt3 :) not this elementtree :)
<minghua> so qt-x11-free doesn't use dh_install --sourcedir= ?
<\sh> minghua: to be honest..I don't know..I'll have a look now..it uses .install files
<\sh> to move it into the correct position
<minghua> \sh: add --list-missing if it uses that :-)
<\sh> it uses it..but I'll do it now in the libqt3 package :)
<persia> \sh: Actually, I'm currently working on libjackasyn (for which you happen to have been the last uploader) :).  No worries, I'll just post some bugs with comments about fixes.  Thanks for the advice anyway.
<\sh> persia: oops...what's wrong with this package?
<persia> \sh: Still depends on libjack0.80.0.  debian/control should have build-dep adjusted to libjack-dev instead of a versioned value, as multiple jack libraries won't work on a system.  Don't worry about it now: I'm creating a bug for your later enjoyment.
<\sh> persia: oh...was it for dapper, or breezy?
<\sh> I think we changed this package in dapper or breezy, when libhack0.100.0 wasn't available for ubuntu
<persia> \sh: Dapper.  BTW, thanks for the cleaner patch for solfege earlier.
<persia> \sh:  Yes, at last change, 0.100 wasn't available yet.  Given the extremely large number of vocal users of the package, I doubt anyone but me noticed.
<\sh> persia: well...I don't know if it's cleaner, but doesn't implement new bugs in a not written python script :) and avoids the awk sed dep
<\sh> minghua: i included now the inputmethods in the libqt3-mt package...just building it and checking if the files are in the package...if yes, could you test it when it hits the archive?
<minghua> \sh: Sure, would love to
<minghua> wonder when it would hit archive though, hopefull before I go to sleep
<\sh> minghua: I would say, let it be 2-3 hours :) so when you wake up, and do a dist-upgrade you will have it :)
<minghua> \sh: will test it tomorrow morning then :-)
<\sh> minghua: cool:)
<minghua> it's lucky tomorrow is Saturday
<\sh> no today is saturday ;)
<minghua> \sh: since Riddell is not around - does the qt-immodule patch change the ABI?
<\sh> minghua: it shouldn't and it's written on the homepage for this patch
<minghua> \sh: I am asking because someone in Chinese channel mentioned that he tried using the scim-qtimm ubuntu package in debian, and it "behaves strangely" (his words), so I am curious
<\sh> minghua: well...without the patches in debian, it should not work as expected..
<\sh> minghua: but abi should not be changed
<minghua> \sh: oh good then, I know scim-qtimm is not supposed to work without this patch for qt, so that guy perhaps was just not clear
<\sh> well..mixing binary packages between debian and ubuntu is not good at all :)
<minghua> \sh: where does it say ABI is not changed on the homepage?  I only found "binary compatible"
<minghua> \sh: I was on your side in that thread ;-)
<\sh> minghua: that is "binary compatible"...API is changed yes, but not abi...
<\sh> well..actually you would see abi breackage of kde or something else:)
<minghua> \sh: so no new functions added?  I am talking about shlib bump
<\sh> minghua: no
<minghua> \sh: KDE won't break in such case
<minghua> \sh: okay good, I know nothing about Qt/KDE so I'll trust you guys
<\sh> minghua: if shlibs would be bumped even kde is crashing..because ABI is quite important for the shared linking :)
<minghua> \sh: even if only new functions are added?  that's not how I heard (although I admit I don't really know such stuff)
<minghua> \sh: at least for C ABIs, you can add new functions without breaking old packages, no?
<minghua> otherwise for each shlib bump there need to be mass rebuildings
<\sh> minghua: that is always the case for new functions...but shlibs bump means really: that I increase e.g. for qt the libqt-mt 3 libqt3-mt to libqt-mt 4 libqt3-mt
<\sh> minghua: therefore all dependencies are stalled and we have to rebuild...for abi changes it means (library vise) that all addresses and symbols are somehow relocated, which makes each app which links against this lib going mad :)
<\sh> and uploaded the new version :)
<minghua> \sh: but you still need to change the shlib version if new functions are added, right?
<minghua> like from libgtk-x11-2.0 0 libgtk2.0-0 (>= 2.6.0) to libgtk-x11-2.0 0 libgtk2.0-0 (>= 2.8.0)
<\sh> minghua: yes, but not for this patch, because it's not "adding functions to the core lib" it's adding new "plugins" :)
<minghua> \sh: and I don't really understand your example of "libqt-mt 3 libqt3-mt" to "libqt-mt 4 libqt3-mt"
<\sh> minghua: no....the major version didn't change of the lib
<\sh> well...if the source of qt3 is building libqt-mt.so.4 then shlibs have to be changed. so long as libqt-mt.so.3 is actual, no shlibs bump
<\sh> (that's for debian)
<minghua> \sh: great, that's all I want to know ("only adding new plugins")
<minghua> \sh: well that's going to be a SONAME change and library package renaming, not just a shlibs bump, I suppose
<minghua> unless libqt-mt.so.4 is binary backward compatible with libqt-mt.so.3, in which case they should just keep calling it .3
<\sh> minghua: not at all :) .4 is a new lib, which means the abi is different, but the API can still be compatible
<josesanch> Hello
<\sh> minghua: so to let old packages which are linked against .3 run, it has to be recompiled with the new lib..but it would work
<\sh> but not without recompiling :)
<josesanch> what can i do to include a package in universe?
<minghua> \sh: that part I understand, I don't understand the part of "but shlibs bump means really: that I increase e.g. for qt the libqt-mt 3 libqt3-mt to libqt-mt 4 libqt3-mt"
<josesanch> i have packages of the software.
<\sh> josesanch: first you can upload it to revu
<\sh> a how to is on wiki.ubuntu.com/REVU
<minghua> \sh: shouldn't that be "libqt-mt 4 libqt4-mt" (library renaming) if the ABI is different?
<josesanch> Ok i'm going to read it
<\sh> josesanch: or if there is no debian package you can put it on wiki.ubuntu.com/UniverseCandidates
<\sh> minghua: in this very special case, yes :)
<minghua> \sh: I always assumed that a shlibs bump means you don't have to rebuild binary packages
<josesanch> It's a software that i have develop. http://gnomecatalog.sf.net
<minghua> s/binary packages/packages that are linked to this library/
<josesanch> There is only the packages that i do. It's not included in debian. I had put in universecandidades
<\sh> josesanch: well...If I take a guess, you included the debian/dir into your upstream source, right?
<\sh> minghua: if the major lib version changes, you normally have to
<josesanch> yes
<minghua> \sh: now I am all clear.  I'll talk about "shlib bump without SONAME change" next time.  :-)
<\sh> josesanch: ok..one advice: 1. never include debian/ dir in your upstream source... 2. if you want to be the packager of this software, please put the debian dir separated from the upstream source
<josesanch> Ok i'll do it
<josesanch> how a patch. it isnt?
<\sh> josesanch: no...you have to repackage your upstream tarball..
<josesanch> ok
<\sh> josesanch: remove the debian dir completly from the tarball...and this tarball u will use as orig.tar.gz, and you debianize the source afterwards..so you have always a clean tarball without any distro specific changes
<josesanch> aha.. ok
<\sh> josesanch: which is good for distros like redhat or suse or mandriva
<\sh> persia: fixing this elementtree thing
<josesanch> \sh: Thanks. I'll clean debian dir and will upload the package to revu
<\sh> josesanch: you have to do a source package upload :) so you have to prepare a debian package at all :) but with a orig.tar.gz (without debian/ dir) and a debianzied source tree, which will give you a .dsc, a .diff.gz and an .orig.tar.gz
<\sh> josesanch: a source upload you can prepare with debuild -S -sa e.g.
<persia> \sh: OK.  I'm just cruising through Malone looking for things that need a little investigation.  Any suggestions?  (BTW, I have never used python-elementtree).
<\sh> persia: but you were right :)
<\sh> persia: the bug was invented by ogra in breezy :)
<persia> \sh: Changelogs are a wonderful thing ;)
<\sh> buxy: it's not worth it to fight windmills :)
<Yagisan> re
<StevenK> \sh: You said orig tarball twice. :-P
* StevenK wonders where xfonts-cjk went.
<\sh> StevenK: damn :)
<minghua> StevenK: but xfonts-cjk doesn't really exist in Debian either?
<josesanch> \sh: i do a debuild -S -sa and i get a gpg: skipped "Jose Sanchez Moreno <jose@oxigenow.com>": secret key not available, fatal error
<\sh> josesanch: do you have a gpg key ?
<josesanch> i had generated
<josesanch> \sh: gpg --gen-key
<\sh> without it's not possible to upload :) we are allowing signed packages
<\sh> josesanch: and the real name and your email address is the same as in the key?>
<josesanch> ummm..
<josesanch> well. the problem is "'"  jos snchez
<josesanch> i'm going  to check it
<buxy> \sh: I won't loose X days fighting, but it's certainly worth saying that many people are trying to collaborate between Ubuntu and Debian
<StevenK> minghua: I noticed. I'd just to know *what* to use instead of xfonts-cjk
* StevenK checks a Potato CD.
<\sh> buxy: well...so I give them what they (some DDs/PMs) want :) I will just file any changes towards the BTS...even it's not possible for debian yet, to use those changes...well...I wonder when I'm catched in their spam filters :)
<StevenK> -r--r--r--  14 root root 2.2M 2000-07-06 01:39 /media/cdrom/dists/potato/main/binary-all/x11/xfonts-cjk_3.3.6-2.deb
<\sh> buxy: seeing that some troublesome bug reports were never touched by some maintainers..I'm just curious what will happen to them
<StevenK> Whee
<minghua> StevenK: xfonts-base since it provides xfonts-cjk?
<buxy> \sh: please don't play their stupid game, send only changes worth integration into Debian, or inform about a patch that may be useful in the future but try to be smarter than the dumbass who are flaming on the d-d list
<StevenK> minghua: xfonts-base doesn't mention CJK
<Yagisan> \sh: buxy: I just read the list, but to me it seems that those that want to help already do, the others seem to have a bug up their arse, possibly because they didn't get a job at canonical.
<\sh> buxy: if you query my submitter email address (sh@sourcecode.de) you'll see most of the time sourcecode patches..which are as well interesting for debian. How many do you see fixed?
<Yagisan> \sh: buxy: why waste time on them ?
<josesanch> \sh: i had do it a debuild -S -sa.  generates a tar.gz, but debian dir is included.
<\sh> josesanch: well..then is something wrong
<minghua> StevenK: I know for sure three chinese fonts are there, try "xfd -fn hanzigb16fs" for example
<\sh> josesanch: ok..your source dir is app-0.2 as an example
<josesanch> debian dir is still in the gnomecatalog dir.
<StevenK> josesanch: You don't have a .orig.tar.gz or a .orig in ..
<minghua> StevenK: that's actually a very nice font
<\sh> so your contents of the orig.tar.gz (upstream tarball without debian/ dir) should include app-0.2/ directory
<StevenK> minghua: Doesn't look so good for me on Breezy.
<josesanch> no
<\sh> josesanch: no?
<josesanch> i have a gnomecatalog dir i have gnomecatalog/debian . In gnomecatalog/ i do a debuild -S -sa. I only get a tar.gz with de debian dir included
<minghua> StevenK: why?  the latin letters may be not so good, but did you look at the Chinese chars?
<StevenK> minghua: I didn't see any Chinese chars.
<minghua> StevenK: press the "Next" button several times, please (or the "+16" button)
<StevenK> Ah.
<\sh> josesanch: wrong
<StevenK> So I should just depend on xfonts-base instead of xfonts-cjk? (Since I can't see the Provides)
<\sh> josesanch: your package has a version..so if your tarball is named gnomecatalog-0.2.tar.gz you should have a gnomecatalog-0.2 directory created after unpacking
<StevenK> \sh: He can just cp the tarball to be an orig
<minghua> StevenK: I suppose so (as xfonts-base conflicts, replaces, and provides xfonts-cjk), but I wonder which package is this?
<\sh> StevenK: well...let's make it clean :)
<StevenK> root@broken:/# apt-cache show xfonts-base | grep '(Prov|Conf|Repl)'
<StevenK> root@broken:/#
<minghua> I mean on debian
<\sh> josesanch: now you insert your debian/ dir in the created directory, edit changelog e.g. like this: gnomecatalog (0.2-0ubuntu1) dapper; urgency=low
<\sh> josesanch: you can do this with the "dch" util
<StevenK> minghua: Ah. Now I see.
<josesanch> ok
<josesanch> \sh: ready
<josesanch> and now?
<\sh> josesanch: make a ln -s gnomecatalog-0.2.tar.gz to gnomecatalog_0.2.orig.tar.fz
<\sh> josesanch: make a ln -s gnomecatalog-0.2.tar.gz to gnomecatalog_0.2.orig.tar.gz
<\sh> cd into gnomecatalog-0.2
<\sh> debuild -S -sa
<\sh> it should not change the orig.tar.gz or repackage it somehow
<StevenK> \sh: Bah! cp!
<\sh> josesanch: did you read the debian new maintainers guide?
<minghua> StevenK: why ln -s is not good?
<josesanch> not complete.
<\sh> StevenK: Buh! mv! :)
<StevenK> I prefer cp or mv
<\sh> hehe..choice is what we want :) choice is what we get :)
<josesanch> \sh: I going to read debian new mantainer guide. I'll be back later.
<josesanch> bye.. thanks a lot
<siretart> morning
<siretart> wow. lots of discussion about debian<->ubuntu taking on the last days.. I love it! :)
<Burgundavia> siretart, indeed
<Gloubiboulga> \sh, do you have time to look at libtranslate ? http://revu.tauware.de/details.py?upid=1473
<\sh> Gloubiboulga: just looking
<Gloubiboulga> \sh, thanks :)
<\sh> Gloubiboulga: why is the tarball different from upstream?
<Gloubiboulga> good question...
<\sh> -rw-r--r--  1 shermann shermann 542705 2006-01-12 08:16 libtranslate_0.99.orig.tar.gz
<\sh> -rw-r--r--  1 shermann shermann 532516 2005-01-28 15:55 libtranslate-0.99.tar.gz
<\sh> and the md5sums are different :)
<Gloubiboulga> \sh, I had trouble with config.{sub,guess}
<Gloubiboulga> maybe I didn't do things the right way
<\sh> Gloubiboulga: copy config.{sub,guess} from /usr/share/misc (build-dep on autotools-dev) in the configure target
<\sh> and remove them in clean target
<Gloubiboulga> ok
<\sh> Gloubiboulga: you can use the skeleton provided by dh_make but move it away from clean :)
<minghua> yay, new libqt3-mt is in archive now, let me test before going to sleep
<Gloubiboulga> \sh, ok, i can do that :)
<\sh> minghua: cool :)
<Gloubiboulga> \sh, iirc upstream tarball provides this 2 files
<Gloubiboulga> remove them will produce a big diff.gz, is this ok ?
<\sh> Gloubiboulga: yes can be, but it won't change the upstream tarball :)
<Gloubiboulga> ok :)
<\sh> Gloubiboulga: if it's provided, leave them untouched
<\sh> Gloubiboulga: or copy the ones from the buildsystem in configure target
<Gloubiboulga> \sh, is it the only problem with the package?
<\sh> yes
<Gloubiboulga> ok
<\sh> minghua: any result?
<Gloubiboulga> \sh, the new package is on review: http://revu.tauware.de/details.py?upid=1493
<Gloubiboulga> the debdiff is empty... but the orig.tar.gz is correct :)
<minghua> \sh: just finished upgrading, now my aptitude in gnome-terminal freezes :-(
<minghua> trying to figure out a non-violent way to exit
<\sh> kill -9 ?
<minghua> ok, killed
<minghua> \sh: okay, I have XIM mode working
<minghua> \sh: although scim doesn't work well in XIM mode
<minghua> \sh: but that's a different issue and it's not specific to KDE (I've seen it in GNOME too)
<minghua> \sh: so your fix to libqt3 works
<\sh> minghua: thx :)
<minghua> \sh: I'll follow the malone bug, then go to sleep
<minghua> \sh: thanks for the quick fix
<\sh> minghua: thanks for testing it :)
<Gloubiboulga> \sh, thanks again :)
<minghua> Qt's IM module is really chatty, no wonder \sh prepared a patch to silent it :-)
<\sh> minghua: it wasn't me, it was redhat :) i just stole it from them :)
<minghua> \sh: ah.  then you are really good at stealing patches :-P
<\sh> minghua: sometimes :)
<\sh> minghua: actually I know how to read the different source package systems :)
<\sh> .oO(and I'm not "lazy" to do so :))
* minghua smiles at \sh's status explanation for 6606
<\sh> oh I wrote your name wrong...missed on character :*(
<\sh> sorry
<minghua> \sh: oh I didn't even notice that, no problem at all
* minghua goes to bed
<minghua> see you all
<StevenK> grep -E '(Prov|Conf|Repl)'
<StevenK> Oops.
<Yagisan> ajmitch: ping
<Yagisan> ajmitch: depending on what order you install the plone packages in on breezy, and if you run a certain command between them, plone + addons work out of the box in breezy
<xerxas> Hi
<xerxas> I'm trying to fix a bug
<xerxas> to add some comments
<xerxas> can someone help me ?
<xerxas> the bug is sound-juicer doesn't re-read cd
<xerxas> when cd is inserted
<xerxas> is this a sound-juicer thing ?
<xerxas> or gnome-volume-manager ?
<crimsun> sound-juicer is a main package, no/
<xerxas> sorry  ?
<xerxas> is sound-juicer hal aware ?
<crimsun> seems so
<siretart> buxy: I just wanted to tell you that I found your message to d-d-a very appropriate. really!
<\sh> siretart: link?
<siretart> \sh: http://lists.debian.org/debian-devel-announce/2006/01/msg00008.html
<\sh> is nice
<\sh> phew..I think I only have two or three packages left for cleaning up the libXft.la mess in kdes .la files
<Kyral> Morning
<\sh> hey kyral
<Kyral> `/away Breakfast!
<Kyral> ..oops
<siretart> Kyral: morning :)
<\sh> siretart: who can I generate a list of packages, which I don't have installed, but to find out what the contents of a special, let's say .la file is
<siretart> \sh: apt-file?
<\sh> no
<\sh> i can see only via apt-file which package has a .la file
<\sh> but I need to check as well the contents of this .la file :)
<siretart> ah, you need the contents of the .la file, no?
<siretart> ok
<\sh> siretart: correct :)
<siretart> \sh: I think you would have to make first a list of packages containing the files and their position, and then download all of those packages to extract and grep the affected files
<\sh> siretart: ok...need to think about something like this...
<buxy> siretart: but I started yet another flame war apparently and assufield should be killed really (if you was his mail as well)
<crimsun> the lesbians one?
<buxy> yeah
<crimsun> I was wondering where that originated
<\sh> well...as I said, it isn't worth fighting windmills.
<\sh> and those people are chasing away the people who wants to help in some areas...
<crimsun> eh, I wouldn't really worry about him. He has always been brusque, so I generally ignore his pendantry if it's not code-related.
<siretart> buxy: thats sad. :(
<buxy> crimsun: yeah that's the only way to handle assufield
<buxy> siretart: yeah but it's difficult to avoid when you have the size that Debian has
<siretart> buxy: I'm following debian-devel a really long time now. This was one of the reason why I only recently applied for NM
<siretart> buxy: btw, what I wanted to ask you: what is the correct maintainer field for ext-maintained packages in the collab-maint svn?
<siretart> buxy: and how do you intend to coordinate the sponsoring itself?
<buxy> siretart: if the Debian packages already exists, there's a name in the maintainer field, why can't you keep it ? :)
<siretart> buxy: I'm talking currently about wifi-radar
<buxy> siretart: for the coordination part of the uploads, that was the role of the web interface vaguely specified in the wiki page
<buxy> but obviously this page doesn't exist yet
<siretart> buxy: the package does not exist in debian yet (as well as min12xxw from sistpoty), but I think it is a worthwile addition to debian
<siretart> buxy: I see. So I (we) have to search for sponsors ourselves for now, right?
<buxy> mostly yes, but I can start the sponsoring process and I should really ask utnubu people to help in this area
<siretart> ok
<buxy> siretart: who is Ante Karamatic ? he's he interested in maintaining the package or what that a one shot work ?
<\sh> buxy: Ante aka ivoks :)
<siretart> buxy: thats ivoks. He made wifi-radar for ubuntu initially. he used to be quite active in this channel, but I havn't seen him for quite a long time
<\sh> siretart: he is busy with his real life work I think
<buxy> siretart: should I create a mailing list in the collab-maint project coordinating the work ?
<siretart> buxy: I think that would be the right place for questions like I just made
<siretart> buxy: so, yes, IMO a good idea
<buxy> siretart: unless we use the utnubu list ... I'll ask opinions on the utnubu list.
<siretart> ok
<siretart> boah, boson-base takes fucking much time to get compiled
<\sh> siretart: hehe....
* StevenK notes #debian-devel at the moment is currently encompassing why he doesn't want to work on Debian neatly.
<\sh> StevenK: well...Gustavo wrote me a mail today...that he is going the MOTU way as well...
<jsgotangco> planet jdub heh
<\sh> hehehe this time it's not me :) so now you can believe me when I'm telling you all: Planet is broken, not my blog :)
<sivang> jsgotangco: LOL
<\sh> damn...I have to write the motu meeting minutes..well..tomorrow is time enough
<Kyral> Anyone know what the "suite" is for setting up a breezy repo
<Gloubiboulga> \sh, do you know how I can my email adress white-listed?
<Gloubiboulga> pef has uploaded my package, but Katie doesn't want to email me
<\sh> Gloubiboulga: write email a mail to upload@ubuntu.com or use the ubuntu.com mail address when you have one
<Gloubiboulga> and elmo doesn't answer me...
<\sh> oh my...my sentence
<Gloubiboulga> \sh, ok
<\sh> Gloubiboulga: write an email to upload@ubuntu.com or use the ubuntu.com mail address when you have one...or try to put your email address into your launchpad account
<pef> \sh: can you try to run ida or motv (on Dapper, of course :)
<\sh> what is it?
<pef> \sh: programs not finding libXm.so.3 (openmotif), and openmotif FTBFS
<pef> ida: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
<\sh> tried to build it with lesstif?
<pef> \sh: it's another implementation of motif, am I right ?
<\sh> pef: yepp
<\sh> why is openmotif ftbfsing?
<pef> \sh: http://pastebin.com/505668
<pef> but that's seems to be another problem, I can't find libXm.so in libmotif3.deb
<\sh> hmmm..I would say there is a build dep missing
<\sh> but I can be wrong without looking at the source code
<pef> \sh: it's worse than missing bdeps :/ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194466
* Kyral scratches his head
<Ubugtu> Debian bug 194466: "uses Xlib private functions" Package: openmotif, Severity: important, Maintainer: Gerd Knorr
<Kyral> Okay..I have a problem..
<Kyral> I made this metapack for my labbuild...I have a load of depends in Depends...but when I go to apt-cache depends in a local repo...its showing no deps
<pef> \sh: seems to be fixed in Debian http://packages.qa.debian.org/o/openmotif/news/2.html
<pef> \sh: should we ask for a sync ?
<pef> or just get the patch ?
<\sh> pef: you can rebuild ida with lesstif2-dev :)
<\sh> let me rebuild it on i386 and let me test it :
<\sh> )
<pef> \sh: there are no side effects, like something not implemented in lesstiff ?
<\sh> pef: it compiled like a charm :)
<\sh> but I didn't test it for running...give me 5 mins :)
<pef> \sh: latest libmotif's version also correct a FTBFS on sparc
<pef> mm
<\sh> well...check it :) and request a sync
<\sh> I'm testing with lesstif2 meanwhile :)
<pef> oops
<pef> we already have latest version
<pef> with the patch
<pef> hum
<\sh> moment...
<\sh> well..it's running
<\sh> but I can't see any text :)
<\sh> but picture rotating is working :)
<\sh> but what you can do is to rewrite the broken source code and use public functions and not private ones
<Kyral> what call is responsible for generating the Control file for the binary deb?
<crimsun> Kyral: dh_gencontrol
<Kyral> thanks
<Kyral> I'm wondering why the heck this Meta isn't passing its Depends to the Binary
* Kyral smacks himself
<Kyral> I made a typo... a . instead of a ,
* Kyral learning a lot by creating his own repo
<josesanch> \sh: Are you there?
<tommy_> good evening, all
<tommy_> or hi for some far away
<stratus> hi, i maintain a package in debian that is outdated in ubuntu; i can prepare the package for merge...
<stratus> it's just strange that it wasn't merged automagically
<crimsun> stratus: which?
<stratus> crimsun: gnome-sudoku
<crimsun> stratus: it has synced.
<crimsun> it ftbfs
<stratus> weird
<stratus> url?
<crimsun> http://people.ubuntu.com/~lamont/buildLogs/g/gnome-sudoku/0.4.0-1/gnome-sudoku_0.4.0-1_20060104-1738-i386-failed.gz  for example
<crimsun> it's a pretty simple failure
<stratus> *sigh*
<stratus> python2.4-dev(inst 2.4.2-1ubuntu1 ! >= wanted 2.4.2-2)
<crimsun> yep, I can merge it easily
<stratus> it's up to you, i can downgrade it on Debian package and wait MoM
<crimsun> granted I don't know if doko_ is going to merge python2.4 2.4.2-2
<stratus> oh, i prefer change it in Debian so you won't need a ubuntu revision, ok?
<crimsun> stratus: whatever works best for you as the maintainer
<stratus> crimsun: good, i'll take care of that thanks
<stratus> let me ask some more things...
<stratus> i see some merge related bugs in malone, what's up there? e.g: 4393
<stratus> err 4394
<crimsun> stratus: that's part of our merge management
<crimsun> stratus: up until upstream version freeze (UVF, which is on Jan 19th), MoM runs, and we file bugs to track who's doing what
<stratus> MoM see a failure and open a bug to Motu for manual merge?
<crimsun> stratus: no, we open/close them manually
<stratus> oh, ok
<stratus> i'm really interested in universe QA, so i'm asking
<crimsun> for #4394 in particular, we can drop Ubuntu changes, so we ask elmo for a sync
<crimsun> (hence why I've left it in Confirmed state)
<crimsun> (waiting for elmo to sync from Sid)
<stratus> what's the procedure to ask elmo for a sync? sometimes i see people just writing a request at #ubuntu-devel
<crimsun> stratus: generally MOTUs ask elmo for syncs, but of course if he knows who you are in Debian, then he'll sync them
<crimsun> case in point being StevenK, who isn't a MOTU but is a DD
<stratus> crimsun: np, but i think i'm a MOTU hopeful already :)
<crimsun> we either e-mail him or just accumulate them in his away log :)
<crimsun> stratus: great :)
<stratus> crimsun: yes
<stratus> rebuilding gnome-sudoku...
<LaserJock> hmm, I wonder how hard (or if it would be even possible) to file ITPs and RFPs in Malone and then make a list like the merge list on tiber. It seems like UniverseCandidates is a little unwieldy
<crimsun> I think that's part of the plan for Malone, yes
<LaserJock> k
<crimsun> you'll probably get a more concrete answer in #launchpad
<LaserJock> oh, ok. I'll see what's going on over there
<Gloubiboulga> evening LaserJock
<LaserJock> hi Gloubiboulga
<raphink> hi LaserJock
<LaserJock> hi raphink
<raphink> :)
<raphink> just here for a short time
<raphink> I'm not home but I'll try to have a dapper chroot running soon enough to help with the merges
<raphink> :)
<Gloubiboulga> salut raphink :)
<raphink> salut Gloubiboulga
<LaserJock> chroots are a wonderful thing
<raphink> yes
<LaserJock> I used to just have partitions for each distro
<raphink> i'm gonna switch somes comps to ubuntu here
<raphink> and then make myself a dapper chroot
<raphink> if I can't do it, then I'll just use my own box with ssh ;)
* attroja is away: I am away from IRC at the moment.
<Mithrandir> attroja: please turn off public away
<LaserJock> hi Hobbsee
<Hobbsee> morning LaserJock
<lfittl> Everybody who has time: Please comment on my layout change for http://wiki.ubuntu.com/UniverseCandidates
<LaserJock> lfittl: I like it, but at the top MOTUNewPackage doesn't exist
<lfittl> LaserJock: I did not change that
<LaserJock> lfittl: I know, but could you?
<lfittl> sure, what should be written on the top? :)
<LaserJock> I don't know
<Hobbsee> lfittl: looks much more readable
<LaserJock> I'm not sure quite what was intended
<lfittl> LaserJock: I will try to find out who changed that
<LaserJock> lfittl: it could be HowtoCreateNewPackages or MOTUNewPackagesPolicy
<lfittl> LaserJock: that change has been done by lucas, I could simple revert it
<LaserJock> lfittl: oh, he might of had a plan for that, just a sec
<LaserJock> I think perhaps MOTUNewSoftware is what should be there
<lfittl> I will change it to MOTUNewSoftware and ask lucas what he intended to do
#ubuntu-motu 2006-01-20
<lfittl> LaserJock: I am thinking about moving all comments from Requests to the Comments section, what do you think?
<LaserJock> lfittl: well, I don't know. I haven't quite figured out what the Comments section is for
<lfittl> LaserJock: It is for additional packaging information to speed up the packaging process
<LaserJock> lfittl: but why wouldn't that be in the comments in the Requests section?
<LaserJock> lfittl: but we really need to get UniverseCandidates off the wiki I think, that would make it much simpler
<lfittl> LaserJock: that would be the best thing, I simply wanted to make it easier to find software that could be packaged before UVF
<LaserJock> lfittl: well, I think you definately made it better looking
<lfittl> :)
<Kyral> Anyone know when this "E Gnome" thing got added to the GDM (I didn't do it)
<Kyral> ooo I love upstreams who email me patches :D
<ajmitch> Kyral: even better, I like upstream that I can sit down & have a beer with
<Kyral> lol
<Kyral> I cannot drink yet :P
* Kyral goes to apply the patch and upload to REVU
<ajmitch> yeah, you can do anything but drink..
* Kyral blinks
<ajmitch> vote, enlist in the army, drive.. but not drink even a light beer ;#0
* ajmitch thinks putty has some encoding issues
<Kyral> lol
<ajmitch> but in a week or so I should be sitting down with the main upstream developer of 1 of my packages for a beer
<Kyral> nice
<Kyral> Is it normal for Python based programs to be called Debian Native?
<Kyral> oh wait I saw what happened...
<Kyral> I patched the source with the diff that upstream gave me
<Kyral> and the orig.tgz is off
* Kyral gives himself a lession with uscan
<Kyral> I forgot I set a watchfile for this one X_X
<Kyral> yah...lintain is complaing about the no orig..
<LaserJock> Kyral: so are you using uscan?
<Kyral> LaserJock: Yah I was, but I rememebered that a split second after I did dpkg-buildpackage :P
<LaserJock> I don't quite understand what it is used for
<Kyral> Uscan?
<LaserJock> yeah
<Kyral> It checks (using debian/watch) for new upstream versions, downloads them, patches them, etc
<LaserJock> ok, I guess I can see where that might be useful, I would probably just screw my computer up with it ;-)
<Kyral> lol
<LaserJock> I'm trying to start using bzr/svn so I can recover when I screw up
<Kyral> lol
<Kyral> I just setup an Apt Repo for my Linux lab's Build for our custom packages
<Kyral> with the ability to upload with dput :D
<LaserJock> Kyral: cool
<Kyral> Now if I could only get it setup to build source packages...
<Kyral> hey slomo_
<tseng> it is 3 am in germany
<tseng> nice try
* Kyral blinks
<tseng> his client is rejoining probably
<Kyral> oh he lives in Germany?
<tseng> yes.
<Kyral> cool, didn't know that :P
<LaserJock> Maybe he just needed a late night Ubuntu snack ;-)
<Kyral> lol
<LaserJock> ya know, some of us have to have Ubuntu IVs to keep going
<psusi> why is it that revu denies access to all .changes files?
<Kyral> Actually I was wondering that myself...
<LaserJock> yeah, the .changes are -rw-------
<psusi> why is this?
<LaserJock> you'd probably have to ask siretart or sistpoty
<LaserJock> I really don't know, would there be any reason for it?
<tseng> there is
<tseng> if a MOTU uploaded a signed changes to revu
<tseng> anyone could ftp it to ubuntu ftp-master and get it in
<tseng> when it wasnt meant to be uploaded yet
<LaserJock> tseng: oh, thanks
<psusi> the only thing the ftp master checks is that the .changes is signed?
<psusi> it doesn't need a username/password or something?
<tseng> psusi: signed by a key in its keyright
<tseng> keyring
<psusi> hrm....
<tseng> ie, a MOTU
<psusi> well that kind of sucks... I want to see what they changed ;)
<tseng> see the debdiff..
<psusi> ahhh
<tseng> .changes is just some md5 and a changelog
<tseng> not a diff
<psusi> is there a way to make bash's history behave sanely?  i.e. when i scroll up 8 commands and execute it again, next I want to hit down and get the command after that, and so on
<tseng> er
<Lathiat> psusi: thats not sanely imho :)
<tseng> yeah
<tseng> Lathiat++
<psusi> how is anything else remotely sane?
<psusi> the whole reason for scrolling back is to rexecute commands
<tseng> back = up
<tseng> down = forward
<psusi> usually you want to do several... and you don't want to have to keep hitting up n-1 times
<tseng> you cant get commands from the future
<Lathiat> psusi: ^R helps :)
<tseng> or mapping to PgUp in inputrc...
<psusi> Lathiat, to find the first command sure, but when I already know I want the next dozen after that as well?
<tseng> which is way less suck than ^R
* psusi is used to ^R from emacs
<Lathiat> mapping to pageup?
<Lathiat> psusi: type history get hem all and paste?
<tseng> # alternate mappings for "page up" and "page down" to search the history
<tseng> "\e[5~": history-search-backward
<tseng> "\e[6~": history-search-forward
<tseng> sudo <pgup> = backward history search like ^R
<tseng> with less wanking
* psusi just wishes it would work like 4dos
<minghua> what psusi needs probably is Ctrl-O (instead of enter)
<tseng> because dos is how i want my command line to act
<LaserJock> does anybody know what a .mo file is" I keep getting "Linda: Unable to find a suitable .mo file!"
<tseng> LaserJock: thats bogus afaict
<minghua> LaserJock, yes, .mo files containes the translations
<psusi> ctrl-0?
<minghua> the binary counterpart of .po files
<LaserJock> minghua: translations of what?
<tseng> LaserJock: strings
<tseng> LaserJock: in the program to other languages..
<minghua> no, ctrl-Oh, not ctrl-zero
<sladen> LaserJock: it's caused by the install on the revu server
<psusi> AHA!
<psusi> ctrl-O is exactly what I want, thank you!
<LaserJock> ok thanks, I just wondered if I was doing something wrong
<psusi> thank god that was driving me nuts
<sladen> I was even looking whether I could do a workaround to get rid of it :)
<tseng> sladen: it does it on my local box, too
<Lathiat> psusi, minghua: hey cool
<LaserJock> sladen: me too
<LaserJock> but why would it be a problem for me to not have a .mo ?
<LaserJock> other than being not very internationally friendly
<psusi> my sweetest friend... everyone I know, goes away, in the end.... if you could have it all.... my empire of dirt.... I will let you down... I will make you hurt.
<LaserJock> anybody know of a way to get a list of bug #s for a particular source package from Malone in an automatic way?
<Kyral> oh LJ
<Kyral> take a look at this
<Kyral> http://www.gnomefiles.org/app.php?soft_id=401
<zakame> hi MOTUs :)
<Kyral> hey zakame
<LaserJock> Kyral: and it's not in Debian?
<LaserJock> hi zakame
<persia> LaserJock: A URL of the form https://launchpad.net/distros/ubuntu/+source/packagename/+bugs
<zakame> heya Kyral and LaserJock :)
<Kyral> LaserJock: I don't know, the package search is down right now
<LaserJock> persia: yeah, but I am looking for a way to get a list of the bug #s automatically so I can link to all the bugs of a package individually
<LaserJock> Kyral: apt-cache or madison-lite
<Kyral> LaserJock: that would....damn I almost forgot about chroots :P
<LaserJock> Kyral: I don't see anything
<Kyral> in Debian?
<LaserJock> yea
<Kyral> cool
<Kyral> I'll get on it soon
<LaserJock> Kyral: what about FlowDesigner ?
<Kyral> LaserJock: eh...I still gotta fix the LIBSOName problem
<LaserJock> Kyral: also make sure to check Debian for ITPs or RFPs before diving in
<Kyral> LaserJock: oh
<LaserJock> Kyral: I found 3 ITPs for apps I put on MOTUScience, none for flowdesigner though
<Kyral> ah
<Kyral> anything for GAMGI?
<LaserJock> no
<janm> hi! What package is gtk.dsextras in now? I have the pygtk dev packages installed (gnome, gtk, and glib) but can't seem to find dsextras. tnx
<minghua> python-gnome-extras?  just a wild guess
<LaserJock> Kyral: so your going to go for gamgi then?
<Kyral> yah
<LaserJock> k, I'll add it to MOTUScience
<janm> minghua, nope. dsextras used to be in the pygtk devel packages. It was used to build extensions like the trayicon when p.g.e wasn't still around. tnx anyway
<LaserJock> is the BSD license ok for Debian/Ubuntu?
<womble> LaserJock: It's perfectly fine.
<LaserJock> womble: ok, thanks
<womble> As long as it's the current BSD, and the ol' 4 clause
<zakame> yep
<sladen> wonder if it's to do with Ubuntu striping langpacks
<sladen> if I build linda then the .mo's are there for English
<zakame> hm, the `can't find a suitable .mo file' thang?
<sladen> you need  language-pack-en-base  installed
<sladen> and it's actually in  /usr/share/locale-langpack/en/LC_MESSAGES/linda.mo
<LaserJock> so is it that linda can't find a .mo for itself?
<zakame> that's needed for REVU too :)
<sladen> yes.
<LaserJock> sladen: I have  language-pack-en-base installed but I still get the linda message
<sladen> def find(domain):
<sladen>     localedir = '/usr/share/locale'
<sladen> it's hard-coded...  wonder who we can make it inteligent
<zakame> StevenK: ping
<zakame> (but I think he's prolly out)
<psusi> anyone have a sata hardware fakeraid and feel like testing the dmraid support package for it up on revu? ;)
<psusi> did flight3 come out yet?
<Burgundavia> psusi, monday
<psusi> great... I'll have to test... do a clean install of flight3 and hopefully be able to apt-get install dmraid and have that all work out automagically too
<sladen> what the recommended practice regarding updating maintainer: and changed-by: ?
<sladen> when reving a Debian package?
<zakame> hm I don't understand... can you elaborate? :)
<zakame> iirc updating those are in debian/control (for maintainer) and debian/changelog (for changed-by)
<psusi> if you are updating a package maintained by someone at debian, should you become the maintainer in the ubuntu version?
<psusi> I think that's what he meant... I've been wondering that too
<LaserJock> I wouldn't think so
<LaserJock> maintainer doesn't mean much in Ubuntu, for Universe anyway
<Kyral> ping azeem
<zakame> psusi: nope
<zakame> psusi: basically, what we do here is what Debian calls as NMU (non-maintainer upload)
<zakame> except, of course, for NEW packages in REVU
<LaserJock> Kyral: azeem is in Germany I believe, you probably won't get a reply for a while
<Kyral> lol okay
<zakame> ah, psusi, sladen, are you concerned with what's going on at the n4lp thread at d-devel?
<zakame> just got around to reading it
<psusi> no idea what you're talking about... what's d-devel?
<womble> psusi: debian-devel@lists.debian.org, most likely
<Burgundavia> psusi, not to be confused with d-d-l *grint*
<psusi> ahh... no, I'm not on the debian lists
<psusi> what's n4lp?
<zakame> heya \sh
<\sh> hmm...
<\sh> I just had a look on lucas' unimultiverse list
<\sh> and I wonder why I don't find python-profiler on a dapper system
<zakame> psusi: need for launchpad, (perhaps) highest-grossing thread for january
<\sh> because I wrote it wrong..it's too early in the morning
<psusi> I don't like it so far
<zakame> er who does?
<psusi> lol
<\sh> zakame: to be honest, the thread is now totally crap
<zakame> \sh: heh, it was well before you got into it ;)
<\sh> zakame: ;) no it wasn't
<\sh> actually, it was a "ready to die" thread, when the initiator wrote "launchpad"
<zakame> \sh: well yeah, the OP had a point, but it quickly... yeah, die
<zakame> he should have said launchpad/alioth integration then ;P
<\sh> zakame: he should have said nothing, at least not on d-d
<zakame> hehe, indeed
<\sh> zakame: and you shouldn't have press "r" for reply :) they will hunt you down :)
<minghua> any universe-bugs@l.u.c admins here?  I am starting to get "non-subscriber's mail waiting for moderation" mails recently
<sladen> for those wondering.  It's probably:  http://lists.debian.org/debian-devel/2006/01/msg00349.html
<\sh> minghua: that belongs to launchpad and the main switch
<sladen> minghua: it's because launchpad is spamming it
<psusi> yea... email sent to the bugs list by malone is bouncing
<zakame> \sh: eh?
<minghua> \sh, sladen: I see.  Is there anyway I can get my address whitelisted?
<\sh> minghua: it's not your address :)
<minghua> Hmm...
<\sh> or actually it's your address :)
<\sh> somehow...ask on #launchpad for me and lpbugs it's working :)
<\sh> minghua: think more ubuntu-bugs@ problem
<zakame> bbl :)
<minghua> I think it is my address (it's the about the comment for the qt-immodule bugs yesterday), I'll ask on #launchpad
<psusi> I changed a bug in malone earlier and got a bounced email from ubuntu-bugs that was sent by malone
<psusi> says I'm not a subscriber
<\sh> psusi: did you subscribe to this mailing list?
<psusi> of course not
<minghua> psusi: with the subject "Your message to ubuntu-bugs awaits moderator approval"
<minghua> ?
<psusi> minghua, yes
<minghua> yeah, then we are talking about the same problem
<\sh> subscribe to the mailing list and see if this changes :)
<minghua> okay, this seems to be two problems:
<minghua> 1. my mail didn't go to universe-bugs@ although the bug is assigned to MOTU
<minghua> 2. malone send bugs to ubuntu-bugs@ but the list doesn't want it
<psusi> shouldn't have to subscribe... malone should be allowed to post to the list... and since I did not originate the message, it certainly should not bounce back to me
<minghua> \sh: that's not an option, I don't want that address spammed by bug mails
<minghua> I am perhaps going to change my main address on launchpad
<\sh> minghua: the latter is a better plan :)
<psusi> where do you report bugs in malone itself?
* psusi bonks Yagisan 
* Yagisan ouch
<Yagisan> psusi: what's up ?
<psusi> Yagisan, you ever build the defragger? ;)
<\sh> psusi: launchpad malone product malone i think
<psusi> ahh... heh
<psusi> so what's a guy got to do to get upload rights for universe? ;)
<Yagisan> psusi: I saw that your changes to e2fsprogs had issues with ia64 ?? was waiting for an update on it
<Yagisan> psusi: cc meeting + sexual favours :-P
<psusi> Yagisan, Yea... still not heard any updates from Mithrandir about upstream fixing it
<\sh> psusi: become a member
<psusi> also... I'm not sure why, but defrag now works on ext3 ;)
<psusi> \sh, what's that entail?
<\sh> psusi: for that you have to document your work for ubuntu (in general) on your personal wiki page on w.u.c
<psusi> Yagisan, I was going to reverse the patch that made it refuse to work on ext3... but I never did, and as far as I can tell, it still should refuse to operate on ext3... but it doesn't... works fine on it too...
<\sh> psusi: after some contributions which are documented you propose yourself as ubuntu member and go straight to the CommunityCouncil...there will be a decision if you become a member or not.
<\sh> psusi: after that, you will do more work for MOTU, and propose yourself as ubuntu-dev ... after a couple of weeks and finding motus who will speak up for you, you go to the TechnicalBoard...the TB decides if your contributions to MOTU and ubuntu are good and worthy, and they will give you your upload rights to universe
<psusi> \sh, I see.... so what should I do before then?  so far I've fixed/improved a few packages and uploaded to revu
<Yagisan> psusi: well the ext3 journal is just a regular file when mounted as ext2
<psusi> Yagisan, actually I believe it doesn't show up... it's a reserved inode number... defrag treats it as bad clusters
<\sh> psusi: first you go the ubuntu member way..and for that, document everything you did for ubuntu (documentation, packages, fixes , bug triage etc.) on your wiki page :)
<Yagisan> \sh: so, you think I'd get member status by now then (assume I write down what I do) ?
<psusi> ok... so I should start a wiki page...
<psusi> how about specs?  I've written a spec or two... how do I get them looked at?
<\sh> Yagisan: well..what I think is irrelevant, I can give my statement that I'm happy with you and that your contribution is worth it, to welcome you as member, but the final decision is made by the Community Council
<\sh> psusi: are they in launchpad?
<psusi> \sh, yes...
<psusi> https://wiki.ubuntu.com/PacketCD is registered in launchpad
<psusi> I need to take https://wiki.ubuntu.com/FakeRaidHowto and convert it into a spec too
<Yagisan> \sh: thanks, you answered my question perfectly.
<\sh> Yagisan: the decision is finally made by several points: 1. the CC will see, that your contributions are a continous afford...2. are they worth for Ubuntu 3. are other members, who know you, worked with you, happy with you :)
<Ubugtu> Ubuntu bug 3: "doc-debian: copyright status of some documents unclear" Product: Ubuntu, Component: doc-debian, Severity: normal, Assigned to: debzilla@ubuntu.com, Status: RESOLVED, Resolution: NOTWARTY http://bugzilla.ubuntu.com/show_bug.cgi?id=3
<\sh> Ubugtu: your parser is broken :)
<\sh> Yagisan: if everything is positiv to be answered, the CC will say "welcome on board" or if not, they decide, work more on your contributions, eventually with on of the other people, or, and this can happen every time for every decision: Sabdfl stands up and vetos all decisions by CC or TB and what he decides after his veto, that'll be it :)
<psusi> \sh, so what else can I do besides registering it on malone to get my spec noticed?
<\sh> Yagisan: and the most important part is: You signed the CoC. Without that, you can forget all steps :)
<\sh> psusi: what about request feedback?
<psusi> request feedback?
<minghua> \sh: I have more qt-immodule fun/pain for you ;-)  bug #28590
<Ubugtu> Malone bug 28590: "x11-free (Ubuntu) - qtconfig can't start in GNOME with XMODIFIERS="@im=SCIM" and scim running" Fix req. for: qt-x11-free (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/28590
<\sh> minghua: can you strace qtconfig on gnome?
<\sh> psusi: when you go to the lp page of spec there is a link request feedback...
<minghua> \sh: sure
<\sh> psusi: i honestly don't know what this link is doing, but it's worth a try
<psusi> rofl
<\sh> psusi: you asked :)
<minghua> \sh: strace posted
<Yagisan> \sh: thanks. I actually have signed the CoC, so that's the first step done.
<\sh> write(2, "Failed to create XIM input conte"..., 36Failed to create XIM input context!
<\sh> ) = 36
<\sh> hmm..could it be, that this is byting with the gnome xim support?
<minghua> \sh: I don't really know
<minghua> that's why I proposed to try dropping said patch
<minghua> for comparison, I mean
<\sh> well..what happens if you set the qtconfig settings in kde....and then change to gnome and start any qt / kde application?
<minghua> \sh: which setting?
<minghua> \sh: with the same environment most KDE apps plainly crash
<minghua> if that's what you want to know
<\sh> minghua: yes :)
<psusi> silly wiki... it doesn't know Aspiring is a word
<psusi> and it isn't linkifying "PacketCD" for some reason... how do you force a reference to another wiki page?
<psusi> ahh, there we go.. changed its status to pending review
<\sh> minghua: http://lists.freedesktop.org/archives/immodule-qt/2004-November/000587.html
<\sh> minghua: are you sure, scim is running?
<\sh> minghua: and please try to use skim instead of scim :)
<minghua> \sh: yes, I can input Chinese in the same terminal
<minghua> \sh: Err... I'm the scim maintainer, you know
<\sh> okok..I only want to be sure :)
<minghua> I'll test skim later
<minghua> although 1. I have no experience on skim; 2. I doubt skim works in gnome
<\sh> and please test uim as well :)
<minghua> I can't be the "one-man-for-all-input-methods" guy, can I? :-)
<minghua> Gah, my qt-x11-free build fails
<minghua> \sh: okay, fair enough
<\sh> minghua: nobody should do those nasty things :)
<minghua> \sh: I'll prepare a debdiff to disable the immodule patch then, I think
<\sh> minghua: wrong way...
<\sh> minghua: right way is using coditionals :)
<\sh> conditionals even
<minghua> yeah, if I know how to speak make...
<\sh> minghua: which we can try to achieve and we can do this as well in 00list :)
<minghua> \sh: my fail is because of debian/rules
<minghua> \sh: yeah, doing so
<minghua> \sh: do we plan to merge the recent qt-x11-free changes in Debian packages?
<\sh> I have to see what they are...
<\sh> will have a look later
<minghua> I've just looked, some things seem to be nice to have
<minghua> for example:
<minghua> * Move all .desktop files from /usr/share/applnk to /usr/share/applications, and ensure that they have Categories set. This cleanup also fixes the Qt3 Assistant menu entry, which should now appear next to other Qt3 tools in the menu. (Closes: #335465)
<minghua> but I understand this is low priority
<\sh> minghua: I'll check later...right now I'm trying to fix something else...
<minghua> \sh: sure
<pef> hello
<sivang> hey pef
<sivang> pef: 'sup?
<pef> sivang: tracking bugs and trying to get better support for my brand new T43 laptop :)
<pef> sivang: and you ?
<sivang> pef: ohh, I had one like that that I returned for a dead pixel chronic problem, but everything was supported there out of the box :)
<sivang> it's sweet having Ubuntu on this baby
<sivang> pef: I'm trying to get soem more work done on my spec, pitying I do not have time to work on some merges..
<pef> sivang: everything working ? I have problem with suspend to disk and bluetooth/wifi toggle button
<sivang> pef: eh, almost then - I didn't use the bluetooth, but wifi worked hassle free
<sivang> pef: and I played with the switch button, didn't seem to have any troubles.
<sivang> (it did have 6 dead pixels though, so I returned it)
<pef> sivang: under Dapper ?
<pef> arg, bad luck
<sivang> pef: breezy
<pef> sivang: yeah, nearly all is working on Breezy, but on Dapper several things are broken
<pef> sivang: it looks like some wireless drivers drop /sys/class/net/xx/wireless entry
<pef> in dapper kernel
<josesanch> hello
<josesanch> I uploaded a package to revu, but don't appears in http://revu.tauware.de/
<siretart> morning
<siretart> josesanch: because your key wasn't it the revu keyring
<siretart> josesanch: I added your key and reprocessed your upload
<josesanch> ahh..
<josesanch> ok.. thanks
<siretart> \sh_away: boson-base got NMU'ed yesterday, based on the ubuntu package
<Gloubiboulga> morning
<siretart> hi Fuddl
<vurdak> good morning to all
<pef> vurdak: good morning to you ;)
<vurdak> :)
<Gloubiboulga> could a MOTU remove libflu2.14 from REVU (http://revu.tauware.de/details.py?upid=1363)
<Gloubiboulga> This lib is old and not maintained, it shouldn't be accepted in Universe
<siretart> Gloubiboulga: done
<Gloubiboulga> siretart, thanks
<Kyral> Morning MOTU
<Gloubiboulga> hi Kyral
<Kyral> hmm
* Kyral fires up Mega Man Anniversary Collection 
<Yagisan> G'day Kyral
<siretart> slomo_: around?
<slomo_> siretart: yes, partially
<siretart> slomo_: did you read siggis answer? cool news, I'd say :)
<slomo_> siretart: yes... although i never used sourceforge before ;) what was it all that we wanted to change with xine-lib? first priority is faad/ffmpeg removal, yes? let's ask him about that ;)
<ogra> slomo_, any plans for gstreamer0.10-mad in the near future ?
<siretart> slomo_: that was my next question/suggestion: you are going to answer him on the xine-lib split, yes?
<slomo_> ogra: gstreamer0.10-plugins-ugly has the mad plugin
<ogra> ah, because its not searchable anymore by apt-cache ...
<slomo_> siretart: yes... that's what i planned to do next :)
<slomo_> hm i guess we should add all included plugins in the description...
<\sh> moins#
<slomo_> hi \sh :)
<\sh> moins slomo
<\sh> oh well...d-d is better then the local newspaper reporting about the war in whereever
<\sh> I should unsubscribe
<siretart> huhu \sh
<siretart> \sh: I like gmail for mailing lists like d-d ;)
<\sh> oh well...12h disconnect
<\sh> siretart: tell me, do we have x11forwarding enabled on tiber?
<\sh> ogra: the ssh -X problem occured as well on tiber...it refuses to set the $DISPLAY env
<ogra> strange, i have no problems anywhere
<\sh> ogra: hmmm
<siretart> \sh: >> grep X11 /etc/ssh/sshd_config
<siretart> X11Forwarding yes
<\sh> siretart: ok..you are running dapper with latest updates? if so, please ssh -X to tiber and check if the $DISPLAY is set :)
<\sh> siretart: because I have problems since yesterday or so.
<slomo_> hm, isn't set for me
<\sh> hmmmm..
<\sh> i can't have a $DISPLAY set when I ssh -X from my laptop to the amd64 build box..neither it's set on tiber when I ssh -X there
<ogra> siretart, thats not enough ...
<\sh> but form dapper to hoary it works :)
<\sh> I just ssh -X to my hoary box...no problem
<ogra> siretart, grep AddressFamily /etc/ssh/sshd_config
<\sh> and it worked before
<siretart> \sh: I just installed the package 'xauth' on tiber, should work now
<ogra> AddressFamily inet
<siretart> \sh: what do you want to do with X11 forwarding on tiber?
<slomo_> siretart: jep, works :)
<ogra> sshd has a bug that doesnt release the DISPLAY variable if ipv6 is enabled ...
<\sh> siretart: ok...works now...
<\sh> ogra: I enabled AddressFamily inet
<ogra> \sh, on tiber ???
<\sh> ogra: on the dapper amd64 box
<siretart> ogra: I never encountered that bug, and use ipv6 on a regular basis. do you have a bugno handy?
<\sh> ogra: no..tiber works now
<ogra> siretart, not here, wait, i'll dig for it ... its a longstanding bug since breezy development began
<\sh> ogra: http://www.bitreactor.to/download.php?id=58716
<\sh> umhf
<\sh> hehe.
<\sh> *shame*
<\sh> AddressFamily inet
<ogra> \sh, whats that ?
<\sh> ogra: nothing...wrong pastbuffer
<ogra> (i wont start a download now)
<ogra> ah
<Yagisan> \sh: I find d-d interesting. The more I read it, the less comfortable I feel running debian on commercial systems. I'm sure I will be asked questions tomorrow from some customers why they received  email regarding lesbians on the list I said would advise them of important changes.
<siretart> \sh: what do you want to do with x11 on tiber?
<\sh> siretart: nothing...I have problems on my amd64 server
<\sh> siretart: ssh -X doesn't work anymore
<\sh> well it worked the day before yesterday still..
<ogra> siretart, https://launchpad.net/distros/ubuntu/+source/openssh/+bug/25528
<Ubugtu> Malone bug 25528: "server (Ubuntu) - X11 forwarding via ssh not releasing ports in timely manner with IPv4 and IPv6 enabled" Fix req. for: openssh openssh-server (Ubuntu), Severity: Normal, Assigned to: Colin Watson, Status: Needs Info
<ogra> siretart, sorry, wasnt DISPLAY...
<ogra> but doesnt work either without the option ...
<\sh> looks like I have to reboot the machine somehow
<\sh> this is not normal
<siretart> ogra: interesting. thanks for pointer
<ogra> if you have an idea, feel free to follow up on the bug...
<ogra> it would be odd if we had to release a ipv4 limited sshd in dapper
<Yagisan> ogra: new upstream doesn't fix it ?
<ogra> not to my knowledge
<\sh> siretart: btw...the debian/ dir inside a package, is it under a separate license then the upstream source, or could be under a separate license?
<siretart> \sh: the debian/ is under the same license as the software itself, unless otherwise stated in debian/copyright
<\sh> siretart: ok..and where can I find the copyright holder of the debian/ dir?
<siretart> \sh: but I'd strongly recommend to stay with the original licence
<siretart> \sh: in debian/copyright
<siretart> if not I'd consider it as bug
<\sh> ok...so there is normally no rational to have the Maintainer field filled in with the debian maintainer
<siretart> \sh: I don't think so.
<Yagisan> \sh: careful - don't play into the trolls hands on d-d by changing the maintainer
<siretart> \sh: but if you want to change the maintainer field, it should not be in the source package, but in the appearance of the corresponding tools. this should be rather fixed in our infrastructure than in the source package
<\sh> k..so it could be possible during syncs to change the maintainer field of the source package on the fly
<Yagisan> \sh: If they can add a sed script, it should be
<\sh> minghua: can you come to kubuntu-devel?
<siretart> \sh: I think it would be better to adapt the output of 'apt-cache' and co
<siretart> \sh: e.g. I would not want my packages to be mangled!
<\sh> siretart: yes I know, and I don't want to change the Maintainer field in the source...I'm only searching for a rational not to do it :)
<\sh> siretart: neither in source nor in any other file :)
<siretart> \sh: the rationale up to now was because some DDs could be pissed off because of it
<siretart> \sh: mdz tried to start a discussion about it but nobody cared.
<\sh> siretart: well..the majority don't rant and flame about it..it's only a small ammount of people
<Yagisan> siretart: after watching the stunts pulled in d-d, and the fact that very few dd's have vocally disagreed (thereby implicitly agreeing), personally I think they can get stuffed, but that's just my opinion as a user
<Yagisan> siretart: actually the fact that d-d-a can be so easily abused makes me wonder about if the rest of their infrastructure can be abused
<ogra> \sh, changing the Maintainer field is pointless because we dont use it anywhere in ubuntu ...
<ogra> very simple argument ...
<\sh> ogra: we all know that :)
<ogra> you were looking for arguments
<Yagisan> ogra: very true, but it doesn't seem to be understood, does it.
<ogra> explain them the "who touched it last is responsible" policy we have ...
<ogra> then they'll understand why we dont need it
<\sh> ogra: this argument is technical, so it can't solve the social aspect of "I'm the maintainer, and if someone is changing my package, I don't want to be responsible anymore for this"
<ogra> he isnt ...
<ogra> ubuntu bugs get filed in the ubuntu bugtracker that should prevent him being esponsible
<\sh> ogra: in their eyes, he is still responsible, because his name and email address is written in the maintainer field
<Yagisan> ogra: they don't (want to) understand. people seem to be trying that already. actually, I wonder if the ones complaining would pass the current n-m process
<siretart> ogra: we still don't have an easy means to answer the question 'who touched the package Y last?'
<siretart> ogra: grepping through 'dapper-changes@lists..' is NOT easy
<ogra> changelogs.ubuntu.com
<\sh> ogra: if the bug reporter is using reportbugs patched by ubuntu :)
<minghua> well, there are always clueless users that will pester them about the ubuntu packages, so they have a point there
<phanatic> hi people
<\sh> minghua: no...if the user are not able to use reportbugs or read manuals, how are they able to apt-cache showsrc package?
<\sh> the whole discussion makes no sense, only technical people who are familiar with debian are looking on the maintainer field. others don't.
<minghua> \sh: I have no idea.  I receive emails begin with "I see you are listed as the maintainer of this ubuntu package, so..." myself
<Yagisan> minghua: most debian-derived distros use their debs unchanged - it's no different - except canonical didn't hire the people complaining it seems. maybe that's the real problem ...
<\sh> minghua: which is sometimes not bad...
<minghua> I am not really annoyed by this, I just tell them I am not responsable, but I can see why someone don't want to see such mails
<minghua> \sh: well, if you remember the outcry about scim not working in breezy in ubuntu-devel, you can imagine such mails are not really friendly
<Yagisan> minghua: I understand, it's an annoyance, but is it any worse if eg it is a mepis, nextena?? kantonix user etc ?
<\sh> minghua: well...my solution is "delete"...if someone is not polite and rational, I can refuse to read his mail :)
<minghua> granted it's a small portion of users, but I rarely receive encouraging mails when the package works, either
<Yagisan> \sh: I thought everyone has asuffield in their kill file ;)
<minghua> Yagisan: I don't know how they customize their packages, but no, I've never received mails from their users
<Yagisan> minghua: the point is they don't. I got emails from them asking about my packages
<ogra> probably their users dont debug stuff :)
<minghua> maybe they don't have CJK users then, which is quite possible :-)
<spike> hi there
<\sh> ogra: what you meant to say is: they don't have a large userbase, is it? ;)
<minghua> I am just trying to say it's a valid complain
<minghua> although I would say it's not a big deal at all
<spike> can anybody enlighten me on connections between launchpad and wiki.u.c ?
<\sh> minghua: comparable with all the mails you get via Dbts...how many mails from ubuntu users are you receiving?
<Yagisan> minghua: true. but to be honest, even when people bitch about my work - at least I know they are using it
<spike> I was registering on the wiki to join the ubuntu-server project, and noticed it says "use ur launchpad account"
<ogra> we should probably move Maintainer to Originator and just prefill Maintainer with "ubuntu"
<spike> does it mean they're shared or that u're just suggested to use the same name for simplicity?
<\sh> spike: create an account on launchpad, and use this account for the wiki...the authentication methods are connected
<spike> ah, cool
<spike> tnx
<Yagisan> ogra: just do what other (but not all) distros do. Dump the debian credits and list ubuntu only.
<minghua> Yagisan: I have a mixed feeling on this, in my case the problem is real, and nonexistent in debian, which makes it a little more annoying
<\sh> minghua: but we're trying to do something...how long you have to wait for a patch in qt in debian?
<\sh> (ok, that was ironic)
<Yagisan> minghua: honestly - I'd rather leave the maintainer field alone - but if upstream has such a big issue, I understand why other distros give them the finger wrt credits
<minghua> \sh:I definitely consider the ubuntu mode better, and I don't mind my name listed as maintainer in ubuntu packages
<minghua> \sh:  but I can't require everybody see it the same way as I do
<Yagisan> \sh: I gave up on reporting bugs to debian. nearly a year and still not done
<\sh> Yagisan: which is not the spirit of Ubuntu. Most of the work is done by debian, and that is more then ok, to credit them in any way we have...but there are things, we can't solve without having a white witch
<minghua> \sh:  which is why I say their complaint is valid
<minghua> I am not saying we should fix this problem right now
<minghua> All I want to say is we can't claim "all those Debian maintainers are just whiners and we don't need to listen to them"
<minghua> that's not the correct attitude IMHO
<\sh> well..we can solve it right here, right now...take the debian source package, repackage them into rpm and using apt4rpm...
<\sh> because the RPM based distros, who were all "forking" or "derivating" from RedHat don't have those problems. to be honest
<Yagisan> \sh: minghua: I just want them to make up their mind - do they want credit or not - and to treat all derivatives the same. they don't do that. they don't even treat internal custom distros the same.
<\sh> siretart: btw..I adjusted lpbugs.py to use the new "In Progress" and "Fix Released" status codes.
<minghua> Yagisan: that's the problem with Debian: anything not in socila contract, different DDs can have different opinions :-)
<minghua> Yagisan: there is simply no "they" that can make their mind ;-)
<stratus> ogra, about your idea to move Maintainer to Originator, why not just show the Uploaders field?
<\sh> stratus: because then someone can complain about "Uploaders means normally co-maintainers...and ubuntu devs are not co-maintainers"
<ogra> we should add a Ubuntu-Maintainer field ...
<minghua> besides I don't think the ubuntu uploader is listed in Uploaders field?
<spike> is there a time delay before u can use ur account on the wiki once registered to launchpad?
<ogra> thats distinct enough from debian
<minghua> I like ogra's idea better
<spike> I cant login on the wiki, it says wrong password, but I'm pretty sure I'm typing it right.. can login to launchpad
<Yagisan> ogra: what's the point - it will usually say motu anyway.
<ogra> Yagisan, for universe, yes
<\sh> Yagisan: not for main...only for universe
<ogra> Yagisan, it could even just carry the link to malone
<ogra> (then we shold call it Ubuntu Bugs indeed, not Maintainer)
<siretart> \sh: great. I think i can remove my motutools branch, then, no?
<\sh> siretart: I just merged from you again...and fixed it after...merge from me again :)
<Yagisan> ogra: I'm in favour of calling it "The field formally known as Maintainer:"
<ogra> ++
<ogra> :)
<minghua> that's a long field name :-)
<ogra> but i wouldnt touch the existing Maintainer field... leave that intact and add up stuff
<spike> ok, done, sorry for the fuss
<stratus> \sh, i see.
<stratus> maintainer isn't a good field name, IMHO.
<\sh> siretart: https://launchpad.net/malone/bugs/5973 possible to replace openssl against gnutls?
<Ubugtu> Malone bug 5973: "GnuCash doesn't support HBCI" Fix req. for: gnucash (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Unconfirmed
<spike> is there any CLI interface to the forum?
<spike> like xml-rpc based
<\sh> spike: wrong channel for this to ask :)
<spike> or email based... using the browser is a pain :/
<spike> sorry
<\sh> spike: I don't think many people here using the forums :)
<\sh> spike: email based is named "ubuntu-users@lists.ubuntu.com" :)
<spike> eheh
* Yagisan spots a bad word
<siretart> \sh: didn't check, but I assume it would need porting to gnutls, depending on what parts of openssl it needs
<\sh> k
<ogra> slomo_, any news on mono on ppc ?
<ogra> we only have 4 days left
<\sh> ok...going back to my studies....bbl
<slomo_> ogra: nope... sadly not :/ but why do we only have 4 days left? for UVF, yes... but we will stay at 1.1.13 anyway as novell plans to backport all bugfixes to 1.1.13 for their distribution... 1.1.13.1 is already the first bugfix release, 1.1.13.2 will come in about a week and i guess mdz will accept these bugfix releases as exceptions from UVF for some time, at least when the fix for ppc is finally there...
<ogra> yes, i didnt know they backport the fixes, great news then :)
* ogra wants f-spot on his ibook 
<slomo_> compile it yourself ;) works fine for me
<ogra> the whole of mono ...
<ogra> send me some hours i can attach to my day to do that please :)
<slomo_> hm i could upload my packages tomorrow or the day after... i was only too lazy for that in the past ;)
<Gloubiboulga> libmotif3 installs .so files in usr/X11R6/lib/
<Gloubiboulga> is this ok to do so ? lintian doesn't agree with it  :)
<ogra> heh, no hurry ... as long as we have mono in the release
* irvin is away: I'm busy
<slomo_> ogra: you could send infinity your ibook to use it as a mono buildd until it is fixed ;P
<ogra> i can give him ssh access to it ;)
<ogra> but he would have to live in the deep depths of the lowest nice value with his buildd, so i can still do my work
<ogra> Gloubiboulga, nothing should install anything to /usr/X11R6 anymore
<Yagisan> heh - someone has thrown out a pc. I'm off to see if it's still usable
<LaserJock> azeem: ping?
<Yagisan> cool - a fully working pentium. Just needs a net card and I have a new ltsp client
<ogra> hehe
* ogra just got a wyse terminal, a compaq t20 and a simens futro b100
<Yagisan> nice
<ogra> the wyse box has a spare pcmcia slot ;)
<Yagisan> ogra: so, when do all the edubuntu terminals come with distcc preinstalled
<Yagisan> ?
<Yagisan> and a sample pbuilder config would be nice :)
<ogra> if i find a cheap pcmcia tv card for it, i'll create a ltsp-mythtv-netboot package, the most silent pc is a thin client ;)
* Yagisan has no reception :( my tv tuner is useless - I can't even watch iron chef japan on tv :'(
<ogra> kill me if i ever think about it even ... the 300MHz gedoe CPUs all these things have will rather slow the build down than speed it up :)
<Yagisan> ogra: well, if they are building package foo, and you are building package bar - you just got foo for free
<Gloubiboulga> ogra, I'm looking at bug #28549
<Gloubiboulga> libmotif3 is the problem
<ogra> Yagisan, and foo takes 3h instead of 10 min for bar on my amd64 ...
<Yagisan> ogra: but as you had 2.6G of packages you called pbuilder on, (think my repo), by the time bar and co are finished, foo is ready
<Yagisan> ogra: enjoy the academic challenge
<Yagisan> ogra: I get 1 fps from each client when I'm ripping dvds
<ogra> heh
<Yagisan> ogra: 20 more clients and it is realtime
<ogra> feel free to make a ltsp-thin-client distcc package for universe that sets it up for you ;)
<Yagisan> ogra: when I have time. I can't finish my wine for amd64 due to lack of time at the moment
<ogra> i didnt say for dapper ;)
<bmonty> hey LaserJock
<LaserJock> hi bmonty
<dholbach> siretart: does piuparts always run debootsrap before?
<siretart> dholbach: you can use piuparts with option --pbuilder
<siretart> dholbach: then it uses your pbuilder base.tgz instead of creating a new chroot over and over
<minghua> dholbach: not if you specify --basetgz
<dholbach> ROCKing
<dholbach> i'll use it in the apt-get.org script then
<siretart> yes
<minghua> I am having the same problem with linda as Kyral does
<minghua> "Linda: Unable to find a suitable .mo file!"
<dholbach> yeah, I got those warnings too
<minghua> apparently linda in dapper is not happy and doesn't want to work
<minghua> dholbach: I don't think that's a warning, I think linda just doesn't work
<minghua> let me make sure...
<dholbach> minghua: StevenK should know :)
<minghua> yeah, maybe I should just ask him instead of trying to figure it out myself :-)
<LaserJock> somebody was working on the linda issue last night
<LaserJock> it can't find its .mo file or something, I think
<siretart> this has been for a while
<siretart> StevenK: do you know about this?
<siretart> psusi: I'm just looking at your dmraid package
<siretart> psusi: -       dh_installinit -p dmraid -- start 03 S . start 51 0 6 .
<siretart> I assume you removed that because you integrated it in initramfs, no
<siretart> ?
<psusi> siretart, correct
<siretart> psusi: why do you choose the utnubu team to be the maintainer of the package?
<psusi> siretart, I didn't... that's what it was set to already
<siretart> psusi: I see no point in having it set to utnubu. if you don't want to maintain it, then rather point it to our mailinglist
<ogra> siretart, its one of the early adopted utnubu packages
<psusi> I think what happened is that fabione originally packaged it, then the utnubu team merged it over to debian, and it got synced back with them as the maintainer
<siretart> ogra: thats cool, but still pointless
<psusi> if you think it is appropriate, I suppose I can be the maintainer
<ogra> siretart, but its been set in debian
<siretart> indeed: here it is: http://svn.debian.org/wsvn/utnubu/packages/dmraid/trunk/?rev=0&sc=0
<ogra> Source: dmraid
<ogra> Version: 0.9.9+1.0.0.rc9-0ubuntu1
<ogra> Binary: dmraid
<ogra> Maintainer: Fabio M. Di Nitto <fabbione@ubuntu.com>
<siretart> I see
<ogra> thats the initial package
<ogra> utnubu took it during breezy ...
<siretart> psusi: do you have an debian/sid system to test the package there?
<psusi> nope
<siretart> ah, I see.
<psusi> but I suppose I could install it if I needed to
<siretart> I'm just thinking about the best way to maintain it
<ogra> if its using initramfs, its likely that it needs to differ
<siretart> ogra: debian has initramfs, too
<ogra> the two initramfs implementations are different
<siretart> oh. interesting
<siretart> psusi: in any case: this is not correct: +dmraid (0.9.9+1.0.0.rc9-3) unstable; urgency=low
<ogra> afaik ...
<siretart> psusi: with this version number and upload target, you are targeting another upload in debian/unstable
<psusi> they are?  hrm...
<siretart> psusi: do you want to work on the package so that it is expected to work in debian or do you want to maintain it in ubuntu only?
<psusi> I want it to work in ubuntu... if it also works on debian, great
<siretart> ok
<psusi> and yea, I was wondering why it has the 0.9.9+1.0.0.rc9 version
<psusi> instead of just being 1.0.0.rc9
<siretart> in that case, I'd suggest you upload another version to revu, set your name in the maintainer field (or the motu mailinglist, if you don't want the resposibility), and fix the version number and upload target
<siretart> psusi: thats on purpose
<siretart> psusi: because 1.0.0 < 1.0.0.rc9
<psusi> ahhhh
<ogra> siretart, why do you take it away from utnubu again ? #
<psusi> and what exactly do you mean by fix the version number?
<psusi> I just did a dch -i to bumb the minior version number
<psusi> bump even
<ogra> psusi, if you add ubuntu changes, you have to add ubuntuX
<psusi> ahhh
<ogra> and set it to dapper, not unstable
<siretart> ogra: the maintainer field has to be the correct contact address for the package
<psusi> ahh.... ok
<ogra> siretart, which was by agreement the utnubu people for this package ...
<siretart> ogra: I haven't heard anyone from the utnubu team activly caring for them. they would need another 'upstream', and that would be ubuntu
<ogra> i fear they are upset if you take it away from them
<siretart> ogra: I would agree if the maintainer field would sound something like 'Debian utnubu collaborative maintenance team'
<psusi> well if the changes are going to be ubuntu specific because debian uses a different initramfs system, then it wouldn't hurt to change the maintainer for the -ubuntu version
<ogra> the purpose of utnubu is to grab packages from ubuntu and actively maintain them
<siretart> hm
<ogra> so whats wrong with them being the package upstream then and grabbing our changes
<psusi> see, that's what I was thinking
<siretart> ogra: I see the point, but I have another impression from the utnubu team
<psusi> that my new modified package would just go to debian under utnubu, and be synced back to ubuntu
<ogra> siretart, read the announcement
<ogra> its pretty clear
<ogra> thats why i wonder all the time what you guys are working on...
<siretart> hm, ok, then let it point to utnubu them, even though I'm not that convinced
<ogra> since the project already exists
<psusi> where can I find more info on the utnubu team?  I should probably discuss this with them
<siretart> psusi: http://utnubu.alioth.debian.org/
<ogra> we'd just all need to join utnubu and already have the collaboration you all want
<siretart> ogra: I think this would be an appropriate idea
<ogra> siretart, why ?
<ogra> i only see duplication in the other efforts
<psusi> ogra, he agreed with you ;)
<ogra> oops
<ogra> thanks
<psusi> ;)
<siretart> :)
<ogra> i read (in) appropriate :)
<psusi> why wasn't the target already set to dapper not unstable?
<psusi> isn't that supposed to get translated when packages are synced from debian?
<siretart> psusi: because the last upload was targeted for unstable
<psusi> but unstable:debian as dapper:ubuntu
<siretart> psusi: if I understand you correctly, you are targetting now an upload to dapper
<psusi> siretart, aye...
<siretart> syncs takes the sourcepackage. it does not mangle with changelogs
<psusi> then how does it get built for the right distro in ubuntu?
<siretart> psusi: elmo has an magic script, which generates a correct .changes file, so it can get build in ubuntu
<psusi> ahhh
<siretart> psusi: if you look at what gets uploaded, the .changes file is the interesting part
<siretart> psusi: dpkg-buildpackage generates the .changesfile parsing the changelog.
<psusi> aye...
<siretart> psusi: but thats really implementation detail. don't make yourself too many headaches about it :)
<psusi> I understand it now
<psusi> so I guess the question is, will my changes break on debian unstable?
<psusi> if not, then it should stay targeted at debian unstable, and just get pulled back down in the sync
<ogra> siretart, the announcement is on http://www.joachim-breitner.de/blog/archives/59-Linux-Ball-Utnubu.html btw
<siretart> psusi: if you upload to dapper, it will break further syncs from unstable anyway
<psusi> siretart, right... but if the changes do work on debian unstable, then I'd just upload there and let it sync back instead of uploading to dapper
<siretart> psusi: so if you want the package update to be in debian, I'd suggest working directly in the utnubu svn
<psusi> unless that might take a while, in which case I'd upload to dapper, then once debian gets it, clear the resync
<siretart> yes
<psusi> I'll discuss it on the untubu list to see if the changes are correct for debian... if not, I'll have to fork a dapper -ubuntu version
<siretart> ogra: I don't read that they want to take over responsibility over packages, which have no clear maintainer in ubuntu
<ogra> "If this is not possible or feasable, take Ubuntu-only packages, adjust them to Debian and upload them ourselves."
<siretart> ogra: but that perhaps interpretation of the announcement. we should really talk to them what that line means
<ogra> hmm, how else do you read that sentence then ?
<ogra> they wanted to be the hub that brings our patches into debian ...
<siretart> thats right
<siretart> m
<siretart> hm
<siretart> how to explain
<ogra> where there are new packages, they wanted to care for them
<ogra> thats why i'm confused that we have this big collaboration discussion going on ...
<siretart> I find it rather confusing to have a package in ubuntu, which has as maintainer the 'utnubu team', which brings packages from ubuntu to debian
<siretart> this seems to me to be a hickhack in resposibility
<siretart> wb dholbach
<psusi> seems to me it is no different than having the maintainer be the motu list
<dholbach> just testing new xchat
<psusi> just instead of a ubuntu only group, it's the ubuntu-debian group
<dholbach> (j
<dholbach> oops
<siretart> hm
<siretart> anyway
<siretart> psusi: have you talked to fabbione about the future of dmraid?
<siretart> psusi: because I don't see much point of it having it elsewhere than main. but in main it would need integration into initramfs and the installer. this means great coordination efford with the appropriate people, like fabbione and Kamion
<psusi> siretart, fabbione seems to not have any time or interest for it since breezy was released...
<siretart> hm i see
<psusi> in any case, it is now fully integrated with the initramfs
<siretart> and so I'm willing to upload it for you
<psusi> I think it just might need to be udebified, then moved to main, and integrated with the installer and added to the base seed
<siretart> but I want to make sure that this is really what you want
<psusi> ok... let me discuss with utnubu first... if it needs to go -ubuntu then I'll upload a new version with that and you can upload that to universe
<psusi> then hopefully my spec for getting it into main and the installer will be approved
<siretart> I'm not sure that this really warranted a spec. it seems to me rather a feature enhancement to the installer, e.g. ubuntu express, on which kamion is currently
<siretart> working
<psusi> well... yea... there's a spec for that ;)
<odal> i'm just curious...when is flight #3 slated to be released?
<dholbach> odal: ogra should know :)
<odal> could someone tell me the version number of slypheed-claws-gtk2 in dapper right now?  i'm thinking of moving over from debian
<odal> btw, i know this isn't the general ubuntu channel
<dholbach> packages.ubuntu.com/sylpheed-claws-gtk2 should know
<siretart> sylpheed-claws-gtk2 |  1.9.100-2 |        dapper | source, amd64, i386, powerpc
<odal> dholbach, thanks!
<siretart> madison-lite, too ;)
<blue-frog> hi guys/gals, have done a bash script (operating with menus) which automates (as much as I could do it with my meager knowledge of bash). I am looking for a real programmer who could translate that in metapackages/debconf... everything needed to make it clean.
<blue-frog> which automates the install of a samba-ldap server abd other things...
<odal> siretart, great!
<siretart> blue-frog: do you have a website describing your project?
<ogra> odal, flight3 -> asap
<ogra> i think beginning of next week ... between tomorrow and wednesday
<odal> ogra, oh...great
<blue-frog> no not yet but I can provide what I have done so far anyone interested. A quick explanation of what the script is for can be found inside the menus of my script
<blue-frog> and I would explain in a mail as well what are my ideas of course.
<dholbach> have a nice evening.
* odal eagerly downloads flight #2 to check it out
<odal> is there a new maintainers guide for ubuntu similar to the mew maintainers guide for debian that i could read?
<Hieronymus> odal: no, just read maint-guide
<odal> glad to seem emelfm is in dapper ;)
#ubuntu-motu 2006-01-21
<Kyral> I think I need to get more work done for this...
<azeem> hey Kyral
<Kyral> hey
<Kyral> Man the Debian guys ripped me a new one on the RFS lol
<Kyral> I think I should make a new revision to EasyChem
<Kyral> azeem: Wanna sponsor it?
<ogra> 8-O
<womble> Kyral: You mean they told you what was wrong with it and asked you to fix it before upload?
<Kyral> I dunno if it was personal opinion or like fix it
<Kyral> Most of it was all about using dh_install instead of install -d
<Kyral> Yah the emails were like "You could have saved some work if you did foo instead of bar"
<Kyral> http://lists.debian.org/debian-mentors/2006/01/msg00136.html
<womble> Those criminals, telling you how to package better.  <grin>
<Kyral> yah yah
<Kyral> I'm a beginner sheesh :P
<\sh> Kyral: be gratefull to get those opinions
<azeem> Kyral: did you get feedback from other people besides Florian Ernst?
<Kyral> \sh: I know :P
<Kyral> azeem: yah
<azeem> and the description argument by jdthood
<Kyral> description argument?
<azeem> in reply to the ITP
* Kyral blinks
<Kyral> I didn't recieve that, I don't think
<azeem> http://lists.debian.org/debian-devel/2006/01/msg00815.html
<azeem> ah, it was Frank Kuester not jdthood
<Kyral> Actually there is a long one
<Kyral> I was just too tired to type it in lol
* azeem initiates Kyral to the magic of copy&paste
<Kyral> yah yah
<azeem> ;)
<Kyral> apt-cache show easychem if you really wanna see it
* Kyral shrugs
<Kyral> This is what I get for being lazy
<azeem> Kyral: did you consider some of the suggestions you got on -mentors?
<Kyral> about install and stuff?
<azeem> Kyral: I think the prefix thing might be reasonable to do, but if you want to patch the Makefile to behave properly, that sounds fine
<azeem> yeah
<Kyral> Makefile is already patched in Universe :P
<azeem> yeah, I meant fine continueing to do so
<Kyral> ah
<azeem> Kyral: if you make a new revision, I can upload it to Debian, sure
<Kyral> change prefix?
<azeem> 00:13 < Kyral> I think I should make a new revision to EasyChem
<Kyral> Actually the next revision I wanted to make I would use CDBS ;P
<Kyral> I mean, IMO its fine right now
<Kyral> If upstream releases a new version, then I would make the changes along with the new upstream ver
<Kyral> "Ubuntu Padder"?
<azeem> Kyral: ok, just tell me when I should upload something.  However, during daytime (until around 8PM CET), I am usually at the Uni and unable to upload things, just fyi
<Kyral> http://netswitch.tuxfamily.org/en/downloads.html
<Kyral> well, the package in Universe builds fine in Sid...
<Kyral> Just a matter of changing the revision from -0ubuntu1 to -1
<azeem> ok
<azeem> btw, Daniel Leidert packaged easychem for Debian/Ubuntu as well
<Kyral> Oh he did?
* Kyral blinks
<Kyral> First I've heard lol
<azeem> http://debian.wgdd.de/debian/dists/unstable/main/source/science/ , if you want to have a look
* Kyral blinks
<Kyral> when did this happen?
* Kyral blinks
<Kyral> okay I see it
<azeem> yesterday
<azeem> :)
<azeem> * Initial release from Ubuntu package.
<Kyral> yah
<azeem> ok, so no work duplicated, yay
<Kyral> well at least gimme credit for the XPM :P
* Kyral looks for the changelog
<azeem> so, should I make this look like an NMU, or can you provide a -1 package I should build/upload?
<Kyral> if he already did it then its null ;P
<azeem> well, he's no DD either, it's his personal site
* Kyral blinks
<Kyral> Now I'm confused
<azeem> I was just pointing it out for informational purposes :)
<Kyral> so he just made it for his own use?
<azeem> well, he probably has some users, there are some other packages there already
<azeem> I'm trying to get them into Debian, but I've been slacking
<Kyral> yah I have the package in my little webspace
<Kyral> http://people.clarkson.edu/~petermcv/debian/
<Kyral> I should upload the orig.tar.gz shouldn't I
<azeem> I have that already
<Kyral> yah thats the revision I made switching it to Sid
<Kyral> that one okay?
<azeem> yeah, works fine
<Kyral> kk
<azeem> Kyral: hrm, you might want to close the ITP bug in the changelog
<azeem> but you can also do it manually afterwards if you want
<Kyral> That was made before the ITP bug lol
<azeem> heh, I thought so
<Kyral> and I'd have to redownload that pack...I kinda nuked my /workspace dir...
<azeem> ok, no worry then, I'll upload it?
<Kyral> eh I can close the bug
<Kyral> just gotta remember how to apply the diff.gz to the orig
<azeem> dpkg-source -x foo.dsc
<Kyral> ah
<Kyral> ty
<Kyral> It would be "Closes ITP <num>"?
<Kyral> Debian 347849
<Ubugtu> Debian bug 347849: "easychem -- Draw high-quality molecules and chemical 2D formulas" Package: ITP, Severity: wishlist, Maintainer: wnpp@debian.org</a http://bugs.debian.org/347849
<Kyral> or that...
<azeem> Closes: #347849
<Kyral> want me to just send up the diff.gz?
<lucas> crimsun: you are around ?
<azeem> Kyral: .diff.gz and .dsc is enough, yes
<Kyral> okay
<Kyral> gimem a sec
<Kyral> okay it should be where the others are
<azeem> Kyral: oh, I'd like to spare you from Debian flames :)  If possible, just add the Closes: #347849 to the -1 changelog entry, no need for -2
* Kyral falls down
<azeem> there are some people around who do nothing but check new uploads for bug-closing errors :)
<azeem> "* Packaged for Debian Unstable (Closes: #347849)" should be perfect as changelog
<azeem> sorry for the trouble
<Kyral> done and uploaded
<azeem> perfect
<azeem> Kyral: uploaded
<Kyral> coool.....
<Kyral> too bad packages.debian.org is down...
<azeem> packages.debian.net/easychem
<azeem> well, but it won't be there until the day after tomorrow I guess
<azeem> Debian only puts new .debs into the archive once a day, in about 19 hours
<Kyral> So why doesn't the Debian Package Search use that?
<azeem> I think there is work underway to reinstate packages.debian.org
<Kyral> ah
<azeem> btw, packages.debian.org/unstable/science/easychem will work, as well
<azeem> just not the searching stuff
<Kyral> yah because I found a thing for Firefox that adds the Debian Package Search to the Searchbar :D
<lifeless> google searches just fine ;0
<Kyral> yah, but its nice to have it right on the searchbar ;P
<azeem> ok, good night y'all
<Kyral> ty azeem
<Kyral> Is the MIT License valid for packages?
<lifeless> what do you mean ?
<Kyral> http://www.gnomefiles.org/app.php?soft_id=1253
<lifeless> sorry, that does not tell me what you mean
<Kyral> I mean is it alright to package something that uses that License
<lifeless> yes
<Kyral> okay
<lifeless> MIT licence is open source
<Kyral> hmm
<Kyral> I don't think I saw an ITP for that
* Kyral thinks he sometimes just packages things for packaging sake
<azeem> it probably got kicked out of every distro, considering it is GTK-1.2
<Kyral> lol
* Kyral shrugs
<Kyral> the Screenshot doesn't really look it
<Kyral> http://gtkedit1.sourceforge.net/#screenshot
<Kyral> and it does what he targetted it for...
<Kyral> More software in the Repos is good no?
<Kyral> well, got the emails from the Debian Archive
<Susana> hello
<Susana> clisp has unmet dependencies in dapper
<Susana> is this normal because it is under construction, or should i report it?
<lucas> you should report it
<Susana> ok
<Susana> thanks
<Susana> :)
<Kyral> damnit
<Kyral> what package do I need if a cpp file has #include "Python.h"
<Lathiat> python-dev ?
<Kyral> ain't wokring
<Lathiat> capital P is sus
<Lathiat> and " "
<Lathiat> its probably a custom header ?
<Kyral> which isn't included
<Kyral> it has "PyObject"
<Kyral> I'm thinking python2.4-cxx-dev might work
<Kyral> screw this I'm emailing the dev with the diff,gz :P
* lamont-away notes that meanwhile is older in dapper than it is in sid... needs to be merged.
<lamont-away> and the cool part is that debian actually has the right build-deps. :-)
<Kyral> lol
<Kyral> The cool part is that I got my first package into Debian :P
<lamont-away> meanwhile?
<mr-russ> Kyral: what package?
<Kyral> EasyChem
<Kyral> Azeem uploaded for me
<mr-russ> Kyral: cool, now you can update your website to say it's in debian :)
<Kyral> mr-russ: hehe
<Kyral> I'll wait until the thing is actually added by the script thingy
<mr-russ> I know very little about how debian actually works.
<mr-russ> I have a package that was forked by me and a different fork was done by a debian user.
<mr-russ> I'm now trying to merge the forks back together, but it's hard work contacting the dev and making things happen.
<Kyral> Hey LJ
<LaserJock> hi Kyral, just read the backlog, good going getting EasyChem into Debian
<Kyral> yup
<Kyral> now I'm going BOFH on someone
<LaserJock> ?
<Kyral> on the Undernet
<LaserJock> well, I asked somebody how their ITP was going and they want me to take it over
<Kyral> Damnit
<Kyral> I cannot go into full BOFH mode
<marcin> hello MOTU
<Kyral> hello
<marcin> got a question
<marcin> I'm emacs user and would like to make some packages with emacs libraries
<marcin> but unfortunately there is already a lot of emacs related packages in debian/ubuntu
<Kyral> emacs++
<marcin> unfortunately they usually aren't up to date
<Kyral> in either Sid or Dapper?
<marcin> and sometimes they are broken or they don't work like they should
<marcin> well I cannot say nothing about dapper
<marcin> because dapper doesn't want to boot on my second machine since last apt-get upgrade
<marcin> anyway in my humble opinion debian packages are propably "best on market"
<marcin> but they sucks...
<Kyral> what packages?
<marcin> and their naming convention sucks pretty much
<marcin> Kyral: I really don't want to report bugs here... lot's of them
<Kyral> no I meant packages ;P
<marcin> hmm afair jde is broken
<marcin> not sure about dapper but propably is not installable
<marcin> (if you really want examples)
<Kyral> ICK Java
<marcin> lua-mode in debian is broken will not byte-compile
* Kyral points to Malone
<marcin> anyway it's not bugzilla here
<marcin> I just would like to ask about ubuntu
<marcin> is ubuntu going to keep all these debian packages?
<marcin> or are there any plans to create ubuntu-specific emacs packages?
<marcin> because currently emacs related packages in ubuntu are 100% "compatible" with debian packages
<marcin> and another thing: is there any naming convention for emacs packages?
<LaserJock> I would think there would only be Ubuntu specific packages if they are needed, usually it works better for us is to get the fix in Debian and sync
<marcin> because in my opinion currently it's pretty hard to find emacs packages because they all got weird names
<marcin> and it's hard to sort/filter emacs packages in ubuntu and debian too
<LaserJock> marcin: if a package doesn't work for you try searching Malone and if you can't find an already opened bug about your problem file a new one
<LaserJock> marcin: the naming comes from Debian and I don't see any conventions right off hand but you might be able to ask debian-devel or something
<marcin> LaserJock: well debian-devel... nnno I don't think so ;)
<marcin> LaserJock: and about bugs... ok I'll try to file some bug reports
<marcin> LaserJock: but in fact I went other way - I just already created about 60 emacs related packages
<marcin> LaserJock: with different and more logical naming convention, with cdbs and lot of other improvements
<marcin> LaserJock: and I got my own apt repository on localhost with these packages
<LaserJock> well, if you want to get your packages into Ubuntu you should look at https://wiki.ubuntu.com/REVU and get them on REVU
<marcin> LaserJock: and they work really great but they got different names, different rules etc.
<LaserJock> I really don't know about the naming conventions though
<marcin> LaserJock: than these from debian
<marcin> LaserJock: well my naming convention is pretty simple
<marcin> LaserJock: I just use 'emacs' as prefix for all my packages
<marcin> LaserJock: so it's easy to find them in synaptic etc.
<marcin> LaserJock: just like python or perl packages
<LaserJock> so did you just take the debian packages and rename/fix them? or are they original?
<marcin> they use debian emacs policy
<marcin> with all these emacsen install/remove etc.
<marcin> emacsen-common stuff
<marcin> but their 'rules' are original
<marcin> because I started to use 'cdbs' in my packages
<LaserJock> marcin: hmm, have you talked to the Debian maintainers at all?
<marcin> I've been trying on #debian-devel or something... few months ago
<marcin> and.. I don't want to start this again
<LaserJock> well, I can imagine the response :-)
<marcin> so, you propably understand :)
<marcin> anyway..
<LaserJock> yeah, but maybe you could file a BTS bug or something and talk to the actual maintainers if you feel a change is really needed
<marcin> well but you know... I don't want to talk to Debian maintainers...
<marcin> and this is why I ask here - about Ubuntu plans etc.
<LaserJock> right, but I don't think messing with that many packages in Ubuntu is the solution
<marcin> right but Ubuntu is known as something 'revolutionary' and innovative
<Kyral> eh
<marcin> so I just wonder if this is only related to gnome or maybe emacs packages could change too
<Kyral> I sometimes call it Debian For Beginners
<LaserJock> I mean the basic idea is that we really don't have the manpower to create a lot of changes, we have to maintain every change we make and for Universe there are only ~ 35 MOTU for >1500 packages
<LaserJock> Kyral: I don't see it that way at all but whatever ;-)
<marcin> LaserJock: well I agree but there are two things
<marcin> 1. emacs packages doesn;t change very often
<marcin> (in fact there is a lot of packages that are almost unmaintained)
<Kyral> hey Amaranth
<marcin> 2. if we'll use cdbs in these packages they will be clean and simple and easy to maintain
<marcin> and well it's point 3 - I already maintain about 60 packages for myself and I propably could do this for ubuntu
<LaserJock> marcin: I can see 1 but I don't know that 2 is necissarily true and with 3 you are welcome to submit your packages to REVU
<marcin> LaserJock: well are you sure that I can put them in REVU ?
<LaserJock> sure, they may not get in but you can at least get them reviewed
<marcin> LaserJock: they will conflict with almost evry debian package...
<marcin> LaserJock: (because they got different names...)
<LaserJock> that is why I am saying that you are better off probably getting the changes you want in Debian rather than Ubuntu
<marcin> LaserJock: well but it's _really_ hard to talk with them...
<LaserJock> I can understand that
<marcin> anyway it's 5 am and I really should go to sleep for a while
<marcin> so, propably tomorrow I'll just try to upload some packages to REVU
<LaserJock> marcin: I am really glad you care about these packages and that you are taking time to try to fix them
<marcin> I'll select packages that are not available in ubuntu now
<marcin> and we will see
<LaserJock> marcin: I just don't know if Ubuntu is able to make that dramatic of a change right now
<marcin> anyway.. can I upload breezy packages to REVU?
<Kyral> no...
<Kyral> Dapper
<marcin> (emacs packages are in fact 'platform' 'compiler' etc independent... )
<marcin> welll then I need to wait for flight 3
<marcin> because currently my dapper is just broken
<LaserJock> marcin: you can alway use a dapper pbuilder
<marcin> I cannot boot... and got no idea why
<marcin> hmmm
<marcin> ok I'm too tired now
<marcin> I'll be back tomorrow
<marcin> thanks and night to all
<LaserJock> good night marcin
<LaserJock> hi ogra
<dholbach> GOOD MORNING!
<zakame> hi MOTUs :)
<mr-russ> If two repositories have the same package, which one will be chosen?
<mr-russ> of what is the smart way to apply custom changes to a package that you want distributed?
<mr-russ> s/of/or
<lucas> hi motus
<siretart> morning!
<mr-russ> hi
<dholbach> hello mr-russ, siretart, lucas
<lucas> dholbach: there are lots of merges/syncs waiting for review on malone
<lucas> the problem is LP considers "fix commited" bugs as "fixed", so they are hidden from the default listing
<lucas> https://launchpad.net/people/motureviewers/+assignedbugs?field.searchtext=&search=Search&orderby=datecreated&advanced=1&field.include_dupes.used=&field.statusexplanation=&field.status%3Alist=Unconfirmed&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.status-empty-marker=1&field.severity-empty-marker=1&field.attachmenttype-empty-marker=1
<lifeless> echannel jaldhar ? ;)
<lucas> (35 results)
<lifeless> bah
<lifeless> I meant jamesh
<lifeless> except tab complete is borking
<lucas> lifeless: yeah, it should really do some mind-reading to know which nick you wanted to talk to ;)
<lifeless> nah
<lifeless> if I type james and hit tab
<lifeless> it wont bring up jamesh in this channel
<lucas> yeah, that's because jamesh is not here
<lifeless> oh, irssi got confused
<lifeless> it had jamesh in the scrollback
<lifeless> until I paged up and down enough
<dholbach> lucas: yeah, that occured to me too
<slomo> shawarma: ping?
<KriS83> Hi
<Yagisan> KriS83: G'day
<KriS83> I have a probably not to often asked question
<KriS83> I am looking for a Howto of how to build a dummy deb which contains only a single file and after installing this file I want to run a postinst script
<KriS83> Lets say this file is a single precompiled binary
<KriS83> Any ideas for some good Howto?
<marcin`> KriS83: maint-guide?
<KriS83> marcin`, this explains on how to do all of this when wanting to compile during package creation
<KriS83> Which I do not want to do
<marcin`> KriS83: so.. just skip these parts
<KriS83> I have a fnished file not having to be compiled anymore
<marcin`> KriS83: and implement only postinst
<marcin`> KriS83: you could use cdbs
<marcin`> KriS83: and include only debhelper.mk
<marcin`> KriS83: and then postinst/yourpackage
<marcin`> KriS83: just copy this precompiled library and run your postints script
<KriS83> right, I'll give that a try
<marcin`> KriS83: take a look at cdbs documentation
<KriS83> sure, thx
<marcin`> KriS83: np, your 'rules' file propably could have just few lines
<marcin`> KriS83: include /usr/share/cdbs/1/rules/debhelper.mk
<marcin`> and then install/your package with copy (to put your precompiled lib where you need)
<marcin`> and postinst/your_package.... that's all
<KriS83> building a deb file is way more complicated than rpms :-/
<StevenK> KriS83: Not really.
<StevenK> KriS83: There is just a lot of tools to help.
<KriS83> I think so :)
<StevenK> Which means learning those tools.
<marcin`> KriS83: well I also thought so, but in fact the only difference is
<KriS83> well with a rpm I have one single file *.spec edit it to my need running rpmbuild finished :)
<marcin`> KriS83: that rpm use shell script while deb uses makefile
<marcin`> KriS83: use dh_make to generate files you need automagically
<marcin`> KriS83: and then just edit them
<siretart> StevenK: around?
<siretart> StevenK: do you have an idea why linda is bugging me about not able to find a suitable .mo file?
<StevenK> What's the error?
* StevenK giggles at dvd::rip
<JRe> anyone else than me have trouble running Java SWT programs with dapper (eg. Azureus)
<JRe> (seems to be coming of the way libgtk get compiled)
<StevenK> Ripping - title #1: 13130000.00%, 135 fps, elapsed 00:01:50, ETA 00:-1:04
* StevenK is taking it to be 13%, at 10^6
<Yagisan> StevenK: dvd::rip is cool, but how are you getting 135fps ????
<StevenK> Yagisan: Um, I have a dual Athlon? :-)
<StevenK> Yagisan: What do you usually get?
<Yagisan> StevenK: I have a dvd::rip cluster here, with amd64 (15-25fps) + duron (8-15fps)+ several p2s (1-5fps each)
<Yagisan> StevenK: you are much quicker
<StevenK> Both processors got smashed.
<StevenK> I have no idea, actually.
<StevenK> Yagisan: That was a direct rip to disk, mind you.
<StevenK> Now I'm doing a transcode, and it's 15
<Kyral> Morning
<StevenK> Dual pass encoding gets me 45
<buxy> siretart: did you see utnubu-discuss ? it looks like amaya will sponsor your package and the one of sistpoty in Debian :)
<siretart> buxy: I just answered! :)
<eazel7> hi
<Yagisan> StevenK: sorry - bub woke up. I noticed when using transcode the system is less responsive, then when using mencoder on the same source
<eazel7> I'm needing some help about building dapper packages on breezy
<eazel7> could you help me?
<Kyral> PBuilder?
<Yagisan> eazel7: please be specific
<eazel7> works for an amd64?
<Kyral> I'm sorry I wish I could help more but I have to run to class
<Yagisan> eazel7: I'm also on amd64 - what are you trying to backport ?
<eazel7> I'll try, I want to build an amd64 breezy package for the mono
<eazel7> kinda
<eazel7> for the latest monodevelop too (much more stable than the others, if you've seen it)
<eazel7> I used to use a binary repository for that, but now that I've switched to amd64 it's useless
<eazel7> so I want to backport form dapper to breezy
<eazel7> what do you suggest me to do?
<Yagisan> eazel7: simplest way is to ask backports to backport mono and monodevelop
<Yagisan> eazel7: otherwise start by building a pbuilder
<Yagisan> eazel7: for breezy
<siretart_> darn, router to tauware.de died
<Yagisan> eazel7: then download the source packages for mono and monodevelop from dapper
<eazel7> ok, I'll do
<eazel7> what 'Invalid Release file, no entry for main/binary-amd64/Packages' means? (after pbuilder create)
<Yagisan> eazel7: ubuntu-backports@lists.ubuntu.com
<Yagisan> eazel7: try pbuilder create again
<siretart> \sh: why do you say that we motus don't maintain packages?
<\sh> siretart: because we don't...not in the sense of Debian (IMHO(
<siretart> \sh: I think differently. We DO maintain the packages in ubuntu
<Q-FUNK> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348281
<Ubugtu> Debian bug 348281: "please add these Debian and Ubuntu floater variants" Package: gnome-screensaver, Version: gnome-screensaver/0.0.23-1., Severity: wishlist, Maintainer: guilherme.pastore@terra.com.br (Guilherme de S. Pastore)</a
<\sh> siretart: well...we change them, fix bugs, yes. and it happens that the next time we see the package again, all bugs are fixed by debian or upstream and we sync. so no work for this package anymore
<Q-FUNK> includess goodies for Dapper.
<siretart> and I also think there are some MOTUs, who are indeed willing to work on the package at the debian side. since this decreases divergence, its a win-win situation
<Q-FUNK> siretart: thanks for your reply to my comment on debian-devel.
<lucas> siretart: the problem is: do we have time for this ?
<lucas> and the answer is probably: no
<\sh> siretart: that's what I said, yes. But by default "MOTU Team" as maintainer ... I would say no
<lucas> it would piss off some MOTUs to see ubuntu-motu in the 'Maintainer:' field
<\sh> siretart: if a maintainer, then the utnubu team, because they will push the packages into debian, as global team for taking care about the collab work
<siretart> Q-FUNK: I'm very happy that you gave me the chance to write my lines in that context. so I'd have to thank you! :)
<\sh> lucas: "not pissing off" but if it's appropriate...I don't know
<siretart> lucas: In that case, I wouldn't care. I mean, why should they be annoyed when MOTUs are working on packages in debian.. *shrug*
<lucas> siretart: do you already have some packages in Debian ?
<Q-FUNK> siretart: I have to run now, but I'll be back in about 2 hours. let's see how I can help motu.
<siretart> \sh: whats the rationale for not using the MOTU Team?
<lucas> the number of mails you receive is quite important
<lucas> (for each package)
<siretart> lucas: yes, I currently maintain 4 packages in debian
<lucas> I'm not sure those mails are of interest for ubuntu-motu
<siretart> Q-FUNK: :) - cu later!
<\sh> siretart: because some motus don't want have direct bindings towards debian
<siretart> \sh: debian is our upstream. so there is no point in denying 'direct bindings towards debian'
<\sh> siretart: and when the official MOTU Team is in the maintainer field, the official MOTU team is responsible. I wouldn't want that.
<\sh> siretart: regarding the debian politics
<Yagisan> \sh: if it is in universe/multiverse, we (MOTU) *are* responsible for it, no matter whose name is there.
<lucas> another problem with ubuntu-motu in Maintainer: is that the sponsoring DD will have to be subscribed to ubuntu-motu
<Yagisan> \sh: otherwise - don't sync those packages
<lucas> Yagisan: we are talking about getting some packages into debian
<lucas> with the collab-maint and utnubu projects
<siretart> \sh: debian politics? huh?
<Yagisan> lucas: I must be missing part of the log then. Don't mind me
<eazel7> ttya
<\sh> Yagisan: you don't understand...the official motu team can't (in my POV) be a maintainer for packages in debian. But we can create a subteam, which can handle those things. And everybody who wants to work on this, can subscribe to the team
<lucas> Yagisan: not of the log, of some mails to utnubu-discuss@lists.alioth.d.o ;)
<\sh> siretart: see my comment to Yagisan
<siretart> aha, so a subteam would be okay for you..
<azeem> that subteam could be named... "Utnubu"
<ogra> heh
<azeem> or maybe renamed to something else if the name is inappropriate
<Mithrandir> debubu.
<lucas> \sh: it's not really a subteam, since DDs will join the team too, as well as (maybe) developers from other CDDs
<\sh> siretart: yes, because I could concentrate on my normal universe work, but don't have to deal with problems of packages inside debian, because i don't use it and can't fix bugs in debian.
<ogra> Mithrandir, debuntu rather :)
<siretart> Mithrandir: this one sounds truely funny :)
<azeem> ubuntian
<\sh> lucas: but you get my point :)
<Mithrandir> ogra: doesn't sound so cool
<ogra> true :)
<lucas> \sh: I agreed with you from the start ;)
<Mithrandir> ububian would also work.
<lucas> collab-maint seems OK to me
<\sh> siretart: so the core motu team can't be responsible for packages in debian, as well thinking about new members of motu...
<siretart> well, if the alioth utnubu team won't object, I'd be happy to join the utnubu team to maintain packages there
<siretart> \sh: I don't quite get why this is prohibited
<lucas> I'd like to have utnubu be about general collaboration between ubuntu and debian
<lucas> collab-maint should do the collaborative maintenance
<ogra> lucas, in their initial announcement they said they wanted to take over maintenance
<ogra> (utnubu)
<Yagisan> Can someone tell me why having Ubuntu MOTU as the maintainer is wrong, when that is where the packages come from - I really don't understand why we can't be credited, but Debian maintainers must
<\sh> siretart: volunteers are entering the MOTU team now and then...and I don't want to tell them, that they need to be responsible for packages which are coming now from debian. That they have to install somehow a working debian distro and fix bugs there as well.
<ogra> so just leave them do what they defined once ;)
<\sh> siretart: this is not the work of MOTU...
<ogra> Mithrandir, no widescreen detection in my liveCDs ...
<Mithrandir> ogra: it just does dpkg-reconfigure xserver-xorg
<ogra> Mithrandir, but else they work wondeful, the speedup you built in is impressing
<ogra> yup
<\sh> siretart: the difference is: we are working on Ubuntu, but fixing bugs in debian, I can't and I don't want. Because I don't have the infrastructure for correct testing for debian. And it bytes with the description of the MOTU team.
<ogra> i wonder how daniels solved it in breezy, i have a similar prob with ltsp
<Mithrandir> ogra: sweet. :-)
<Yagisan> \sh: If WE are the upstream for those packages - they can sync with US to fix it.
<Yagisan> \sh: what is good for the goose, is good for the gander
<\sh> siretart: free will work for debian, next to the normal MOTU work, is quite ok..and a special formed team can do that, without anyone to be forced to do things, he/she doesn't want
<siretart> \sh: I see things a bit different
<siretart> \sh: first of all, we are talking about packages which are in ubuntu only. if there is someone who is willing to maintain it in debian properly on his own, he is free to file an ITP
<siretart> \sh: those ubuntu only packages are currently maintained by the MOTU team
<siretart> \sh: I'm thinking about nearly all packages imported through revu e.g. I don't expect their submitters to care for their packages properly
<Yagisan> siretart: hey - I care for my packages
<Yagisan> siretart: I've never had one accepted, but still ..
<siretart> \sh: lucas tried to raise this discussion the last motu meeting, but everyone agrees that in the end the submittors cannot be obliged to care for them
<siretart> Yagisan: yes, I also care for my own packages, right. but there are also quite a lot of packages, which are submitted once and then more or less orphaned, I assume
<\sh> siretart: well, I would respect the will of the original creator. If he is ok with it, that his package goes into debian, ok. The decision to be made for this situation: does the creator wants to be maintaining the package in debian, or the collab team.
<\sh> siretart: if the package maintainer doesn't want to include his package into debian, we should respect that
<siretart> \sh: for these specific packages, I think it is reasonable to maintain it in debian, too, under the assumption that there are debian users, you care about their integration into debian. we care for the integration into ubuntu
<Mithrandir> \sh: Debian is free to include any free software as they see fit, I don't see any reason to ask for permission.  Notifying the author is nice, though.
<\sh> siretart: those "orphaned" packages should be removed then completly. if there is no action in about let's say 2 release cycles
<siretart> \sh: if the creator of the package would care seeing them in debian, he would have filed an ITP, no?
<lucas> \sh: I think the general opinion about this is "we don't"
<\sh> Mithrandir: when someone is there to take over the reponsibilty, ok :)
<lucas> the policy is currently that we prefer having a broken package than no package at all
<Yagisan> siretart: no - I won't - debian is far too unwelcoming at this stage
<siretart> \sh: we don't have any means or statistics to track those 'orphaned' packages in ubuntu. we don't even have enough ressources and motivation to find them
<lucas> siretart: I added the status of popcon.u.c to tomorrow's TB meeting. Be there to say that popcon.u.c is important ;)
<\sh> siretart: to find this out, is quite an easy thing...I use my search function for -changes :)
<siretart> Yagisan: and thats the actual problem: debian has a much higher expectation from maintainers caring for their packages
<siretart> lucas: uff, at what time is the TB meeting?
<lucas> 20 utc
<lucas> (I think)
<siretart> \sh: I hope you agree thats a really poor metric
<Yagisan> siretart: I'm not a programming guru, so I'd never be good enough for them. That doesn't mean I'm dumb, or can't maintain packages, but they just discourage users from joining in
<\sh> siretart: but again, I don't agree that the core motu team should be mentioned as debian maintainer for the package. I, and this is IMHO, can't work on bugs in debian, because I don't use plain debian
<siretart> lucas: 2000utc is very unconvinient for me. I can attend not before 2100utc
<siretart> Yagisan: you don't need to be a programming guru to be a DD
<lucas> try to join at 2100 utc, maybe popcon won't be discussed before
<siretart> I'll try
<\sh> siretart: it's the best metric we have, for universe. If there was a package upload in hoary, and no package upload in breezy and dapper, and the package itself is ftbfs (which we can find out), I'm glad to remove/morgue it.
<siretart> \sh: I wouldn't want to remove working and functionally great packages, just because nobody uploaded them for 2 years
<Yagisan> siretart: after following the lists for *years*, I am aware I won't meet the criteria. Not for a while anyway.
<siretart> \sh: neither would I like to see bogous upload just to save packages from your metric :/
<\sh> siretart: anyways...I would like to see a different team which want to work on packages which are in ubuntu, but not in debian yet, and if those packages are reaching debian, I see it as upstream. Seeing the core MOTU team as debian maintainer, I don't
<Yagisan> \sh: If they go from us to debian, we are upstream
<\sh> a clean separation is much better, then to force people doing work they don't want to do
<siretart> \sh: why do you think anyone is forced to do anything?
<\sh> Yagisan: no..someone is upstream, the core MOTU team as it exists now, can't be upstream, in my eyes. but to stop the discussion now, we should put this on the TB agenda, and let us find a solution.
<\sh> siretart: "forced" is wrong, I would say, the responsibilities are changing then...the core motu team is then responsible for bugs in debian, which is not possible for an Ubuntu team, where not everybody is using a plain debian install.
<\sh> .oO(despite the fact, that ubuntu is a debian derivative...)
<sivang> what the ..... http://www.flickr.com/photos/86444323@N00/81971182/ :)
<Yagisan> sivang: needs more ethnic groups
<sivang> Yagisan: I'll say ! :)
<marcin`> hello MOTU
<marcin`> got a question
<marcin`> could someone tell me what should I put into 'editors' category?
<marcin`> and what in 'devel'?
<marcin`> I got this question because in universe there are emacs related packages
<marcin`> and I wonder why css-mode is in editors while tiger-mode is in devel
<marcin`> could someone point me to some policy document where is defined what goes to editors category?
<marcin`> it's so quiet here...
<Yagisan> marcin`: I'd say most people are busy at the moment
<Yagisan> marcin`: myself included
<marcin`> Yagisan: no problem
<lucas> marcin`: sections are not very useful
<lucas> debian has a replacement called "debtags"
* siretart uni - cu
<dholbach> marcin`: but you can check which other packages are in those sections in synaptic/dselect/aptitude/.. - i think this is the best way to figure out
<Gloubiboulga> hello
<Q-FUNK> siretart: re
<Kyral> if anyone has a second to review LaptopTemp http://revu.tauware.de/details.py?upid=1510 would be great. It works fine (running it right now on my laptop :D)
<lapo> hi
<Kyral> hello
<lapo> is there an ubuntu art channel?
<Kyral> uh....dunno
<Q-FUNK> lapo: #ubuntu-artwork if I recall
<lapo> Q-FUNK, tnx
* Kyral wonders if he should post the REVU link to #debian-mentors so they can take it apart
<Kyral> when is the UVF anyway
<nlindblad> are you guys really the masters of the universe?
<Yagisan> nlindblad: you forgot multiverse too.
<nlindblad> right
<Yagisan> nlindblad: actually, I don't know if we are all guys here
<nlindblad> I though 'guys' could be used no matter the sex
<Yagisan> nlindblad: what's on your mind ?
<nlindblad> you mean why I'm here?
<Yagisan> nlindblad: exactly
<nlindblad> well, I love (K)Ubuntu
<nlindblad> and I'd love to commit back
<Yagisan> nlindblad: excellent
<nlindblad> it is?
<Yagisan> nlindblad: how would you like to help ?
<Yagisan> nlindblad: I should probably disclaim now, that I'm not actually a MOTU
<nlindblad> Yagisan: I'd love to discuss the different ways to help
<nlindblad> are you here later on?
<nlindblad> because I'll be away for an hour or two
<Yagisan> nlindblad: It's 3:10am here - I should have been in bed a long time ago. The others are very helpful though, if I'm not here, or don
<Yagisan> 'don't seem to answer
<nlindblad> right
<nlindblad> :D
<nlindblad> nice to speak to you anyway
* Yagisan can't type anymore
<siretart> hi folks
<LaserJock_away> azeem: ping?
<azeem> heya
<LaserJock_away> azeem: I inherited a ITP yesterday for Gausssum, have you heard of it?
<azeem> nope
<azeem> is that a frontend for gaussian?
<azeem> hrm
<LaserJock_away> it is a python program for looking at gaussian and GAMESS output
<azeem> Thottbot World of Warcraft: Character Profiles
<azeem> Gaussum, 60, Druid
<azeem> not that :)
<LaserJock_away> it uses Gnuplot and can give you Density of States, IR spectra, etc.
<azeem> that sounds nice
<LaserJock_away> azeem: http://gausssum.sourceforge.net/ is the URL
<azeem> does it look nice as well? =)
<azeem> thanks
<LaserJock_away> I came across it about a year ago when I was doing a lot of Gaussian calculations.
<LaserJock_away> Gaussian in very hard to get the data out of
<azeem> they are running pymol there in the background
<LaserJock_away> you basically have to make a perl script to find what you want
<azeem> yeah
<azeem> the plots don't look publication-ready and the GUI seems a bit strange, but it sure sounds useful
<LaserJock_away> anyway, I saw and ITP and emailed the guy about it and he said he didn't want it anymore (no faith in debian-mentors I think he said)
<LaserJock_away> well, there is a Gausssum2 being worked on in CVS
<azeem> heh
<LaserJock_away> I think it might be significantly better when it is released
<LaserJock_away> anyway, I think I will try to fix this guys package and email you when it is done. Does that sound OK?
<LaserJock_away> I wish I had something like Gausssum when I was taking a computational chemistry class ;-)
<azeem> LaserJock_away: sure, sounds fine
<LaserJock_away> azeem: ok, just wanted to give you a heads up
<LaserJock_away> azeem: btw, I don't suppose you could make one of the Extramadura meetings they have been talking about on debian-science?
<azeem> I haven't followed closely, but probably not
<LaserJock_away> they were talking about having a session on MOTUSciece collaboration but I don't know that anybody from Ubuntu will be there :(
<hyperactivecrond> where does one actually download the coc?
<hyperactivecrond> probably wrong channel.. sorry
<hyperactivecrond> never mind. found it
<thierry> does dh_ruby exist?
<LaserJock> thierry: I don't see one
<thierry> k
<thierry> LaserJock : do you know how I could clean a specific file in the rules file?
<LaserJock> thierry: I think you can use rm
<thierry> LaserJock : rm wasn't for deleting file??
<LaserJock> thierry: what are you trying to do?
<_nlindblad> hello again
<LaserJock> hi _nlindblad
<nlindblad> is Yagisan not with us any more?
<LaserJock> nlindblad: check his away message ;-)
<nlindblad> how?
<LaserJock> nlindblad: depends on your client but I get : I'm not available because I am attending to her royal highness, the revered and exulted baby.
<nlindblad> okey
<nlindblad> what different ways are there to commit back to (K)Ubuntu?
<LaserJock> nlindblad: like ways to help out?
<nlindblad> yeah
<LaserJock> nlindblad: well, basically in any way you want
<LaserJock> nlindblad: you can work on documentation, or fixing bugs, or maintaining packages
<nlindblad> okey
<nlindblad> any more ways?
<LaserJock> nlindblad: testing, reporting bugs, advocacy
<nlindblad> okey
<LaserJock> nlindblad: take a look at https://wiki.ubuntu.com/HelpingUbuntu
<nlindblad> I'll do that, thanks
<LaserJock> nlindblad: np, hopefully that helps
<Q-FUNK> siretart: back?
<siretart> Q-FUNK: I'm currently in the pub, with wifi access :)
<siretart> we are having our regulars table on monday
<Q-FUNK> oh :)
<Kyral> yo
<LaserJock> hi Kyral
<LaserJock> has any MOTUs been keeping track of all the merge work Yann has been doing?
<LaserJock> lucas: ping?
<greenpenguin13> LaserJock, pong
<lucas> LaserJock: pong
<LaserJock> lucas: is there a way to put a time stamp in the versions2html output?
<lucas> you mean sthing like "generated ..... " at the bottom ?
<LaserJock> lucas: I was thinking more like at the top
<LaserJock> lucas: I think it is pretty important to know when the list was created when packages change so fast
<LaserJock> anyway, just a though
<LaserJock> t
<lucas> the problem is it depends on when the archive is updated, for example
<lucas> but I can add a timestamp, yes
<LaserJock> hmm, so maybe you can read when the archive has last been updated
<LaserJock> lucas: btw, is the mdt bzr repo ok to update from, you said to wait a while but that was a while ago ;-)
<lucas> well it is
<lucas> but make a backup first
<lucas> I don't know what you changed exactly
<lucas> merging might break stuff
<LaserJock> lucas: I haven't changed anything
<lucas> ok
<lucas> you can update now. I added a footer with a link to the wiki page and the generation time
<LaserJock> lucas: cool, thanks
<Kyral> hgmm
* Kyral plays with debuild for the first time
<LaserJock> Kyral: how is that going for you?
<Kyral> eh
<Kyral> convienent
<Kyral> but I dunno how to make it sign automagically
<LaserJock> man debuild
<phanatic> hi people
<Kyral> yo
<LaserJock> Kyral: have you tried pdebuild?
<Kyral> nope
<LaserJock> Kyral: pbuilder + debuild
<Kyral> niiice
<Kyral> where is it?
<Kyral> I can't find it in Dapper
<phanatic> Kyral: in the pbuilder package
<phanatic> it's part of it as i see
<Kyral> oh lol
<Evaso> hi guys any plan to sync Spe package... seems that many upstream releases was missed on debian?
<lucas> Evaso: some urls would be nice
<lucas> (just because I'm lazy)
<Evaso> lucas: http://www.stani.be/python/spe/blog/
<lucas> and what's the ubuntu package ?
<Evaso> upstream : SPE 0.8.1.d ubuntu: 0.7.5c
<Evaso> lucas: http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=spe
<slomo> debian is 0.7.5c too
<Evaso> yes
<Evaso> i think that debian maintainer is not packaging anymore the upstream packages but the debian package is not orphaned
<lucas> the debian maintainer is an ubuntu developer
<lucas> doko: ping ?
<lucas> doko: Evaso here is wondering whether you plan to package the new upstream version of 'spe' (see debian bug 341192 too)
<Ubugtu> Debian bug 341192: "New upstream release" Package: spe, Version: spe/0.7.5c-1., Severity: wishlist, Maintainer: Matthias Klose  http://bugs.debian.org/341192
<doko> lucas: sorry, currently no time. please go ahead
<Evaso> lucas: i had alread seen this bug
<slomo> lucas: just do it yourself ;)
<Evaso> debian has skipped 0.7.5.d 0.7.5.f 0.8.0.a 0.8.0.b 0.8.0.c 0.8.1.b 0.8.1.c 0.8.1.d
<lucas> ah ah I wasn't planning to do it myself :-)
<slomo> lucas: why? ;)
<Kyral> doko do you have a watchfile on that pack?
<Evaso> Kyral: seems that spe doesnt has watch file http://dehs.alioth.debian.org/maintainer.php?name=spe&Find=Find
* Kyral shrugs
<Kyral> I'll do it
<Kyral> should be easy
<slomo> Kyral: well... not necessarily...
<slomo> Kyral: doko asked me to do some patches... maybe you have to port them to the new version :P
<Evaso> Kyral: it have http://dehs.alioth.debian.org/wwiz_detail.php?id=3818680&type=watch
<slomo> Kyral: but when you're done i can take a look at it and upload it...
<Evaso> but has not any active url all are commented as u can see in the link
<Kyral> slomo: right now I'm planning to Diff the two ;P
<Evaso> Kyral: the actual watch file is here http://dehs.alioth.debian.org/wwiz_detail.php?id=3818680&type=watch
<Gervystar> is it already known that the latest beagle package is actually broken? (dist-upgraded to dapper yesterday and ready to file bugs :-) )
<slomo> Kyral: http://people.ubuntu.com/~scott/patches/spe/
<slomo> Gervystar: yes, it's known
<Kyral> eez
<Kyral> it was easy to make a watchfile
<Kyral> I'll just let uscan handle it :D
<slomo> ?
<slomo> why do you need a watchfile to make it easier now? just get the tarball and use uupdate
<Evaso> here if you need there are upstream info of all the debian packages: http://dehs.alioth.debian.org/dehs_debianqa.txt
<Kyral> slomo: One I'd make a watchfile for it
<Evaso> and here there is a list of packages (with watch file) that seems not in sync with upstream version http://dehs.alioth.debian.org/no_updated.html
<Evaso> clicking ond the upstream version you could view upstream NEWS/Changelog for see bug fixed and new features not included in debian/ubuntu
<slomo> Kyral: well, i'll get to bed :) upload to revu and give me the url in a query... and i'll upload it tomorrow ;)
<slomo> gn8 everybody
<LaserJock> Evaso: it would be interesting to see how the no_updated.html list compares to the list of orphaned packages
<Kyral> doko: You mind me putting myself as Maintainer for this?
<Evaso> LaserJock: i think i quite trivial to compare simply parse this semplified version http://dehs.alioth.debian.org/no_updated.txt
<Kyral> ping doko
<Kyral> meh I dunno if I should just make the changelog entry or change the Maintainer as well
<Kyral> Evaso: what was the Ubuntu bug?
<Evaso> Kyral: what Ubuntu bug?
* Kyral sighs
<Kyral> I really wanna know if Doko wants to give up Maintainership of the Package
<Evaso> Kyral: do u mean in the watch file?
<Kyral> I mean if he has no time I can take it over
<lucas> Kyral: you should start preparing an upgraded package that maybe doko can quickly review
<Kyral> its already upgraded :P
<lucas> it would be better to upload it to debian first, so it would be synced into ubuntu
<Kyral> yah...and lintian is throwing warnings
<Kyral> I have to clean up the package...
<Kyral> not to mention make it build..
<Kyral> meh..
<Kyral> I'll reapply stuff
<Kyral> I need DINNER
<chninkel> would be nice if some MOTU could have a look at the merge I've done before UVF
<chninkel> the list is merge/sync is almost this one:
<chninkel> https://launchpad.net/people/yann-pleiades/+reportedbugs?field.searchtext=&search=Search&orderby=-priority%2C-severity&advanced=1&field.assignee=&field.unassigned.used=&field.include_dupes.used=&field.statusexplanation=&field.status%3Alist=Fix+Committed&field.status-empty-marker=1&field.severity-empty-marker=1&field.attachmenttype-empty-marker=1
<chninkel> can I directly request sync ?
<LaserJock> chninkel: you need to get a MOTU to request a sync for you
<chninkel> it's what I just asked
<chninkel> but there so not so much people around at this time
<LaserJock> but if you do it directly elmo will probably ignore you ;-)
<chninkel> LaserJock: ok
<chninkel> so I can't do anything
<chninkel> :(
<LaserJock> chninkel: you might try to email dholbach or \sh or ajmitch
<LaserJock> with a list of your requests
<LaserJock> if they aren't around
<chninkel> maybe on ubuntu-motu@lists.ubuntu.com ?
<LaserJock> chninkel: I see you've been doing lots of merge work, you just need to bug people here or by email to review your merges or request syncs
<chninkel> LaserJock: yes I see that
<chninkel> I thought motu regularly look at bugs assigned to reviewers
<LaserJock> chninkel: yeah, if you get a list together it would be good to email ubuntu-motu
<chninkel> and indeed some of my merges were taken in account
<LaserJock> chninkel: well, when they are busy they need a little poking
#ubuntu-motu 2006-01-22
<chninkel> LaserJock: sure, I will send a mail
<chninkel> LaserJock: 2 days before UVF
<LaserJock> chninkel: the best thing would be indeed to send a list of bug #s that are ready to go to the ML
<chninkel> LaserJock: hope it will be enough
<LaserJock> if I was a MOTU I would do it myself, but ...
<chninkel> LaserJock: yes would be nice to be a MOTU
<chninkel> LaserJock: for now I am glad my debdiff are examined
<chninkel> LaserJock: but for easy debdiff or sync would be nice to directly put the package
<LaserJock> yeah, but somebody has to check it out
<Kyral> yo
<LaserJock> I think right now it is not so easy to seperate out the reviewing that needs to be done for merges and what needs to be review for new packages
<Kyral> and HOLY COW its COLD
<LaserJock> Kyral: like how cold?
<Kyral> hovering around 0
<Kyral> Only 2 days before UVF?
<LaserJock> depends on TZ
* Kyral wonders if there is going to be a Revuing frenzy..
<LaserJock> I don't know
<LaserJock> chninkel's work needs to get reviewed anyway. I think new packages have until Feature Freeze. Maybe, I'm still confused about it
<Kyral> I have a new package in REVU
<chninkel> chninkel: I also don't  understand everything myself
<chninkel> LaserJock: in fact how many active MOTU is there ?
<lucas> LaserJock: I'm working on libgnuplot-ruby right now
<lucas> so it will be in before feature freeze
<LaserJock> lucas: sweet, thanks
<LaserJock> chninkel: there are probably 25 active MOTUs
<Kyral> Actually
<Kyral> Jeez
<Kyral> okay time to repatch..
<LaserJock> chninkel: actually I might say there is a core group of about 20 MOTUs that you will see around here
<Kyral> dangit
<Kyral> the uupdate for Spe failed
<LaserJock> hi Hobbsee
<Hobbsee> hi LaserJock
<LaserJock> how's it going?
<Hobbsee> not so good - a lot of the kde programs seem to be crashing on me, whenever i try to start them!
<chninkel> LaserJock: I've sent the mail
<LaserJock> Hobbsee: not good, but you realize you opened yourself up for a "just use gnome" ;-)
<LaserJock> chninkel: good, looks great
<chninkel> LaserJock: after UVF, we go in bugfix only mode ?
<lucas> depends on the kind of bugfix ;)
<dholbach> good night everybody.
<chninkel> lucas: well bugfix is bugfix ! ;)
<Kyral> Holy cow...
<Kyral> Spe needs WORK
<LaserJock> chninkel: I guess it might also depend on whether a bugfix would need a new upstream version
<lucas> chances are high that, at least in the beginning, syncs could be requested when the new debian version is not a major change
<LaserJock> cya dholbach
<chninkel> good night dholbach
<Kyral> hey LJ wanna look over this and see if I made any obvious mistakes?
<Kyral> http://revu.tauware.de/details.py?upid=1510
<Hobbsee> LaserJock, hehe - cant stand gnome!
<LaserJock> Kyral: well, I can see
<LaserJock> Hobbsee: sorry, I use KDE too but I had to say something ;-)
<Hobbsee> hehe
* Kyral blinks
<Kyral> SMall tarball...
<Kyral> fittiing a VERY small editor...
<chninkel> good night everyone
<LaserJock> Kyral: you might want to think about switching to debhelper 5 and put a year in debian/copyright
<LaserJock> cya chninkel
<Kyral> LaserJock: yah okay
<Kyral> LJ call up GNOMEFiles and lookup GTKEdit
<LaserJock> hmm, it is small, but look at the screenshots :-)
<Kyral> Yah
<Kyral> Perfect for LowMem systems no?
<LaserJock> yeah
<Kyral> the tarball is LITERALLY 4 files
* Kyral goes to package it
<Kyral> something this small I can just hit it with CDBS...
<LaserJock> Kyral: config.sub and config.guess take up a major part of your diff.gz
<Kyral> LaserJock: yah its AutoConf
<LaserJock> I wonder if there is a way to get rid of that, it is annoying
* Kyral shrugs
<LaserJock> or if it is ok to get rid of it even
<Kyral> Its the standard diff generated by dpkg
<LaserJock> I know
<LaserJock> it just annoys me >:|
* Kyral goes to email upstream about GTKEdit
<Kyral> there is only one Lintian warning in LaptopTemp Monitor..
<Kyral> about one of the Python files having #!/usr/bin/env python
<Kyral> but that command just invokes Python
* Kyral shrugs
<Kyral> I'll create a lintian Overrides file
<Kyral> LJ didja try GTKEdit?
<LaserJock> Kyral: no
* Kyral shrugs
<Kyral> I'll email upstream
<Kyral> Sometimes I think I'm overdoing it lol
<Kyral> Its like I jump on everything lol
<LaserJock> Kyral: yeah, you need to step back and look at the big picture sometimes
<Kyral> well, this time this does fit ;P
<LaserJock> lol, I'll bet you say that about every app you run across in gnomefiles
<Kyral> LowMem systems ;P
<LaserJock> that's what nano, and emacs and vim are for ;-)
<Kyral> and IMHO, you can never have enough free software :P
<Kyral> What about the people who are terrified of the Terminal ;P
<LaserJock> IMHO, you can have to much free software if it's all crap
* Kyral shrugs
<Hobbsee> LaserJock: easy solution - i'd tried removing skim, not realising it was crucial - all works fine now
<LaserJock> Hobbsee: interesting
<Kyral> Personally I think every piece of software will be good for someone :P
<Hobbsee> very
<LaserJock> Kyral: but if I have to choose between getting every app know to man into Ubuntu and making sure that the ones that are already there work to the best of there ability ...
<LaserJock> Kyral: btw, I think it is great to have guys like you around
<Kyral> well of course make sure they WORK
<lucas> gnight all
<Kyral> who are hopelessly optimistic?
<LaserJock> cya lucas
<lucas> LaserJock: I finished libgnuplot-ruby, awaiting review from somebody from pkg-ruby-extras
<LaserJock> Kyral: but have you seen the number of bug reports? Obviously there is a difference between works and works well
<Kyral> but seriously, I saw this and was like...this would be great in Damn Small Linux
<LaserJock> lucas: thanks so much
<LaserJock> Kyral: I agree that it is cool
<lucas> np
* Kyral goes to email the Upstream
<Kyral> hey sistpoty
<sistpoty> hey Kyral
<LaserJock> Kyral: are you going to try to get it into Ubuntu first or go directly to Debian?
<Kyral> LaserJock: I know how Ubuntu works better than Debian ;P
<Kyral> and with the UVF only a couple days away...
<Kyral> but I suppose I could also file an ITP...
<LaserJock> Kyral: I think from now on I'm going to try to go straight to Debian
* sistpoty is just going through sync list from Yann
<LaserJock> sistpoty: great, I told him to email the list. He couldn't get any MOTUs here.
<sistpoty> oh, no other motu here? :(
<Kyral> LJ: I plan to become a MOTU before going fully into Debian
<LaserJock> Kyral: makes sense
<Kyral> sistpoty: *evil grin* You are the only one to handle annoying Review requests ;P
<sistpoty> Kyral: he, but these will be my only reviews for tonight... /me is a little bit ill :(
* Kyral sighs
<LaserJock> sistpoty: well, Yann isn't here too often and I saw that he had done a lot of merge work
<Kyral> I really wanna get LaptopTemp in before the UVF
<sistpoty> LaserJock: sending the request to the list was a very good idea
<sistpoty> Kyral: new package?
<Kyral> sistpoty: yah
<Kyral> Works nicely on my laptop
<sistpoty> Kyral: we have more time until featurefreeze for new packages :)
<Kyral> oh
<Kyral> whens that?
* sistpoty looks
<LaserJock> sistpoty: well, I hope we don't get a bunch of other request flooding the list but he had so many that I thought an email might help
<LaserJock> Kyral: it's about a month from UVF, I think
<Kyral> oh
<sistpoty> Kyral: it's feb 23 (wiki:DapperReleaseSchedule)
<Kyral> oh
<LaserJock> ok, bbl
<psusi> is there a channel for the utnubu team?
<sistpoty> no idea really
<azeem> I don't think so
<sistpoty> psusi: you might ask nomeata in ubuntu-devel, but whois says he is afk atm
<sistpoty> wow, sentence w. lots of acronyms *g*
<azeem> sistpoty: s/ubuntu-devel/#u-d/
<sistpoty> ;)
<Kyral> hmm
<Kyral> back on GNOME
<Kyral> Because I got bored ;P
<psusi> heh
<psusi> darn... who was it that was willing to upload my dmraid package to universe?
<Kyral> and I just moved the Trash to the Trash
<psusi> lol
<psusi> DON'T DO THAT!  YOU'LL CREATE A RIP IN THE SPACE TIME CONTINUM AND DESROY THE UNIVERSE~#!#!#
<psusi> ;)
<sistpoty> cat /dev/zero | /dev/null
<Kyral> hhaha
<psusi> lol
<psusi> come on... that's totally inefficient... you'll use far less cpu time if you dd if=/dev/zero iflag=direct of=/dev/null oflag=direct bs=64KiB
<Hobbsee> hehe
<sistpoty> next lesson in motu-school: how to destroy space time continuum most efficiently ;)
<Kyral> he
<psusi> heheh
<Kyral> okay back on Flux
<crimsun> heh, I requested those syncs last week
* crimsun shrugs
<sistpoty> crimsun: what syncs? the ones I said to elmo?
<crimsun> sistpoty: yes, but it doesn't matter now. They'll get processed, and that's what matters.
<sistpoty> crimsun: yep... I also requested my 2 syncs a while ago, but they didn't make it to the archives
<sistpoty> crimsun: but I'll write a reply to the mail on -motu list, before s.o. else also requests these syncs again ;)
<Kyral> hmm
<Kyral> how do I start something in the background and make it immune to SIGHUP?
<hub> Kyral: man nohup
<Kyral> ty
<Kyral> this will stop the slitapps from dying when the console dies :D
<crimsun> oh boy, spam in -devel
<Kyral> hey slomo_
<LaserJock> so if I get a new program packaged in Debian before feature freeze can I get it into dapper?
<crimsun> if you get it into Debian Sid prior to Jan 19th
<crimsun> oh wait, you said NEW
<crimsun> yeah, FF is the date
<LaserJock> crimsun: ok, thanks
<LaserJock> crimsun: do you use svn-buildpackage?
<crimsun> LaserJock: no
<Yagisan> someone looking for me ?
<LaserJock> crimsun: do you use any kind of revision control for your packaging? I'm just curious what people are doing
<crimsun> I used monotone previously, but I use git now
<crimsun> it was a fairly natural conversion since git essentially is a monotone snapshot
<lifeless> eh?
<lifeless> they have no code in common last I heard
<crimsun> lifeless: yeah, a lot of hand-waving on my part
<lifeless> handwaving? that was a freaking renaissance masterpiece
<crimsun> it's more precise to say git is based on monotone in concept
<lifeless> crimsun: uhhhh
<lifeless> crimsun: news to me.
<crimsun> lifeless: hey, I've been wrong before.
<crimsun> from a user perspective, it doesn't seem _too_ far apart
<lifeless> I can believe it was an easy conversion, as modern VCSs have quite a bit in common
<lifeless> but I would not call git a derivative of monotone in any sense
<crimsun> fair enough
<crimsun> I leave the VCS/es to you guys; I just use it/them
<LaserJock> well, I didn't even know there was a revision control system other the CVS and RCS (in emacs) until I started using Ubuntu
<crimsun> there are dozens
<LaserJock> now I just got to figure out how to use them
<crimsun> that's usually the easier part
<LaserJock> oh no, what's the hard part then?
<crimsun> picking the one(s) you use
<LaserJock> oh, well yes I've been fighting that for a while now. I'm going between svn and bzr
<LaserJock> but I need to learn svn for the docteam repo anyway so I am trying to learn it
<LaserJock> however, a lot of MOTU related stuff seems to be in bzr so I am learning that to
<Kyral> brb
<LaserJock> but I really just need to get the basic concepts of revision control down
<Yagisan> LaserJock: isn't the basics RCS :-P
<psusi> lol... RCS isn't hardly any better than diff ;)
<LaserJock> Yagisan: I suppose but basically the only thing I've ever done is use CVS/svn for getting source and RCS for a program my boss and I use in the lab
<LaserJock> RCS wasn't to hard to use from inside emacs but I always ended up forgeting and changing permissions on files ("why are these read only?") and doing stupid things like that
<Kyral> Okay I <3 Dockapps
<LaserJock> can you use relative icon paths in debian/menu files?
<bddebian> Hey folks
<whiprush> bddebian: !!!
<whiprush> how long has it been?
<LaserJock> hi bddebian!!!
<bddebian> Hi whiprush, LaserJock !
<bddebian> Too long :-(
<whiprush> welcome back!
<LaserJock> just in time to do some merging ;-)
<Kyral> yo bddebian
<bddebian> Yeah if I can get my fscking ThinkPad wireless working.. :-(
<bddebian> Heya Kyral
<Kyral> lol
<bddebian> Why's it so quiet in here?  Everyone working hard? ;-)
<LaserJock> well, actually since you were here last Kyral and I took over MOTU ;-)
<Kyral> heheh
<LaserJock> kicked ogra and dholbach and told elmo to take a hike
<LaserJock> *just kidding*
<bddebian> w00t
<bddebian> Awww :-)
<LaserJock> I think people are either asleep or working like crazy before UVF
<Kyral> while LJ and I try to get as many packages as we can in :P
<bddebian> UVF ALREADY??? WTF?
<Kyral> I think bddebian just had a heart attack
<Yagisan> almost
<bddebian> Damn, have I really been away that long?
<LaserJock> yep, UVF is 19th
<Kyral> Yes now get back here
<Yagisan> bddebian: yep, the new kids don't even know who you are. The old timers tell stories of what it was like when you were here
<bddebian> Yagisan: Haha, yeah right :-)
<Yagisan> :) wb, hope you have a good break
<LaserJock> bddebian: and you need to get your LP karma back in shape
* minghua waves to bddebian (being a new kid :-)
* bddebian waves at minghua 
<bddebian> LaserJock: Aye, no shit :-)
<bddebian> Yagisan: No, RL work is kicking my arse :-(
<LaserJock> bddebian: yeah \sh is >3300
<bddebian> eeks
<Yagisan> bddebian: I get to kick my own arse for RL work. Hey, need a security audit ??
<bddebian> Any of you have stinkpads?
<bddebian> Yagisan: Badly but with me as the only viable resource I don't know how much good it would do ;-P
<whiprush> bddebian: X40 here.
* Yagisan tries desperately to pimp his services
<Yagisan> bddebian: where are you ?
<Yagisan> whiprush: don't worry, I'll get to you next ;)
<bddebian> Yagisan: Philly, USA
<whiprush> heh
<bddebian> whiprush: Built-in wireless?
<whiprush> yeah
<whiprush> madwifi
<bddebian> Hmm, never tried madwifi
<Yagisan> bddebian: well, I guess that rules out onsite work, but still if anything here sounds useful http://eyagi.bpa.nu:8081/eyagi let me know
<bddebian> Hmm, I see the PBuilderHowto still says breezy
<bddebian> Yagisan: OK, cool
<whiprush> bddebian: the workload never gets better. heh.
<bddebian> Yeah no kidding
<bddebian> Especially when you are admin/developer/SQL DBA/applications support/web........
<Yagisan> bddebian: I feel your pain
<bddebian> I had to laugh when I start at this place though
<bddebian> The network was a mess
<ajmitch> afternoon
<Yagisan> ajmitch: afternoon
<whiprush> hi aj
<bddebian> They said they had a DMZ because they had some machines at 192.168.0.x and some at 192.168.10.x.  Of course the idiots were using a class B subnet mask!! ;-P
<whiprush> look, it's bddebian!
<Yagisan> whiprush: you also in the USA ?
<bddebian> ajmitch: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<whiprush> Yagisan: yeah, detroit.
<Yagisan> bddebian: that is laughably funny
<ajmitch> bddebian: hello
<bddebian> Yagisan: Oh yea and DNS was a wreck
* ajmitch wonders what he's missed over the last few days
<Yagisan> whiprush: well, I can do external testing for you
* ajmitch checks merge list
<bddebian> ajmitch: I finished up Dapper for ya ;-P
<ajmitch> bddebian: good
<ajmitch> bddebian: now get to work on dapper+1 kthx
<bddebian> Heh
<ajmitch> ouch
<bddebian> ajmitch: Got a lappy yet?
<ajmitch> UVF in < 1 week
<ajmitch> 118 merges
<Yagisan> ajmitch: dapper was released early yesterday - they decided it was good enough ;)
<bddebian> ajmitch: 118 to go?
<ajmitch> bddebian: maybe
<LaserJock> seems like the syncs are taking a while
<ajmitch> LaserJock: still not done?
<ajmitch> hm
<LaserJock> ajmitch: well, I don't know but have your zope syncs gone through?
<Yagisan> ajmitch: will plone break when I dist-upgrade to dapper
<Yagisan> ajmitch: oh - I figured out what the plone error was
<ajmitch> LaserJock: I got back from my parent's place only a few minutes ago
<ajmitch> Yagisan: it shouldn't break\
<Yagisan> ajmitch: first install only plone-site
<ajmitch> no zope syncs done :(
<Yagisan> ajmitch: then as root run dzhandle and change addon mode to all
<Yagisan> ajmitch: then install plone
<Yagisan> ajmitch: suddenly everything works perfectly
<ajmitch> right
<ajmitch> makes sense
* ajmitch waits patiently for the sid chroot to dist-upgrade
<LaserJock> is there any general rule of thumb as to how long a long description in debian/control can be?
<bddebian> No more than two pages. ;-P
<tritium> bddebian: hey old friend
<bddebian> tritium!!  How ya been?
<LaserJock> I'm taking over this debian ITP an the guy put every feature the program has in the long description
<tritium> bddebian: not bad.  Yourself?
<bddebian> Busy :-(
<ajmitch> hi tritium
<tritium> hi ajmitch :)
<LaserJock> it's like a family reunion in here ;-)
<bddebian> ACK, WTF happened to /etc/pbuilder??
<tritium> bddebian: since we talked last I've moved twice, bought a new house, put my old one on the market, moved myself from one house to the other, had my in-laws move in with us, and bought a truck
<bddebian> tritium: Yikes :-)
<tritium> heh, and work has me busy as hell.  Turns out I had more time in grad school, which I never would have believed going through it.
<bddebian> tritium: Heh, I know that feeling
<tritium> glad to see you again
<bddebian> Shit.  Do I need to do breezy --> dapper pbuilder like I did for warty->breezy of can I just build a straight dapper one?
<bddebian> tritium: Aye, me too
<whiprush> ajmitch: happen to know david nusinow's irc nick? (the debian X guy)
<minghua> whiprush: David's nick is gravity
<whiprush> minghua: thanks
<bddebian> OK, debootstrap is complaining about dapper??
<LaserJock> bddebian: I thought that was fixed but I think I upgraded my breezy pbuilder
<bddebian> Hmm, it doesn't like breezy either
* ajmitch mutters
<bddebian> Failes getting the Release file
<bddebian> Fails even
<bddebian> Hmm, ajmitch doesn't love me anymore :'-(
<ajmitch> I won't if you say silly things like that
* Kyral loves bddebian ;P
<ajmitch> see, someone loves you
<bddebian> Thanks Kyral :-)
<Kyral> in a purely friendship way of course
<bddebian> Oh damn.. ;-P
<bddebian> Bah, what a dope
<LaserJock> ok, so if I am installing a python program I put everything in binary-indep and not binary-arch right?
<bddebian> Helps when you have the right MIRRORSITE
<LaserJock> bddebian: doh! ;-)
<Kyral> lol
<bddebian> Damn, I forgot that's why I ran away.. My stupidity.. :-)
<Kyral> lol
<ajmitch> right
<bddebian> Oh yeah, and ajmitch's hatred of me..
* bddebian ducks
<ajmitch> of course, since it's clearly evident that I just despise bddebian
<bddebian> :-*
<Kyral> You know you use Emacs too much when you use aways like mine
<bddebian> Tell me of this Emacs of which you speak? ;-)
<Kyral> www.gnu.org ;P
<ajmitch> bddebian: if you're bored, could you fix https://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=1517 for me please?
<bddebian> No because I can't login to that page :-)
<ajmitch> guest login should be available
<bddebian> ajmitch: Bah, who cares about Acer laptops? :-)
<LaserJock> hmm, should a python app have its .py removed when it is intalled into /usr/bin/ ?
<bddebian> Gawd, I feel like I have forgotten everything :'-(
<LaserJock> what's the best way to move files around from within debian/rules? does mv suffice?
<Kyral> LaserJock: you mean like to usr/share?
<bddebian> LaserJock: Depends on how it's build I think.  You can use dh_movefiles iirc
<ajmitch> bddebian: don't use that one
<bddebian> Hmm
<bddebian> Guess I should have attended your MOTU class eh? :-)
<ajmitch> why? I didn't say anything important
<bddebian> I doubt that.  EVERYTHING you say is important :-)
<LaserJock> ok so I want to strip the .py off the apps excecutable in /usr/bin/
<LaserJock> and rename it a bit otherwise, i.e. GaussSum.py to gausssum
<ajmitch> so use mv in the appropriate place
<ajmitch> dh_install will not rename files or dirs
* ajmitch sighs
<LaserJock> ajmitch: are you sighing at me?
<bddebian> poor ajmitch
<ajmitch> no, I'm sighing at one of my packages just not building
* LaserJock feels better ;-)
<ajmitch> mono changes, it seems
<bddebian> Well gang, good to chat with you again.  Time for this old fool to head to bed.
<ajmitch> bye bddebian
<Yagisan> goodnight bddebian
<crimsun> cya bddebian
<LaserJock> cya bddebian
<ajmitch> hi crimsun
<bddebian> Hi crimsun, bye crimsun :-)
<bddebian> WIth luck I'll see you gents tomorrow :-)
<crimsun> heya ajmitch
* ajmitch uploads the first of the packages to update in debian
<ajmitch> 1 down, 4 to go
<Kyral> Goodnight MOTU
<ajmitch> & 3 for NEW, eventually
<ajmitch> night Kyral
<LaserJock> hmm, I'm not understanding dh_install. If I just use cp I have to cp to $(CURDIR)/debian/gausssum/usr/share/doc/ but with dh_install I just install to /usr/share/doc
<LaserJock> cya Kyral
<womble> LaserJock: dh_install does the path prepending for you.
<LaserJock> womble: oh, well that's nice
<LaserJock> is there any preference between dh_install, install, and cp ?
<womble> for moving things from debian/tmp to debian/pkg, people usually use dh_install, although for getting things from your source tree to debian/tmp, either make install or cp is usually preferred.
<womble> One thing that irritates me about dh_install, though, is that it doesn't give a clear indication of when you've left something out
<LaserJock> what's the difference between debian/tmp and debian/pkg ?
<womble> I've never gotten --list-missing to work for me
<womble> debian/tmp is the usual location for everything to go into, then you move stuff to debian/<pkg>, where <pkg> is all of your binary packages
<womble> For single-binary source packages, you can usually get away with sticking everything straight into debian/<pkg>
<minghua> womble: why? --list-missing and -fail-missing have been working greatly for me
<minghua> I use a simple <package>.install system, of course
<LaserJock> hmm, is there a way to watch the build process. I get really confused because I don't know what it is going on when I build the packages?
<LaserJock> so how would you install everything in a directory using install?
<Mithrandir> install /wherever/* /somewhere/else ?
<LaserJock> Mithrandir: ok, thanks
<womble> minghua: If I know why it didn't work, I'd fix it.  <grin>
<\sh> moins
<ajmitch> hi \sh
<\sh> hey ajmitch
<ajmitch> how's it going?
<\sh> well...I have an appointment tomorrow with the federal employment office
<ajmitch> oh?
<\sh> it's normall when you are jobless to go there:)
<\sh> s/normall/normal/
<ajmitch> right :)
<\sh> ajmitch: what should we do to remove joey hess name from all his packages which are not bit identical to his debian packages?
<crimsun> TB issue for later this morning
<\sh> oh when is tb meeting?
<\sh> 20ytc
<\sh> utc even
<crimsun> yep
<\sh> hmm..it's missing on the agenda :)
<ajmitch> it'll be every package, of course
<crimsun> heh
<\sh> I wrote him, that he has to inform ubuntu-devel and/or matt as well
<crimsun> I don't know why he's being polemic
<crimsun> I can understand being irritated at some set of changes
<\sh> as I wrote in my other mail: animal farm syndrome
<\sh> and that is no insult..it's quite my view about all this
<crimsun> I mean obviously his code is 100% bug-free, so he has the right to dictate what others can do with his code?
<\sh> crimsun: then he should not release it under gpl
<\sh> (regarding his sourcecodes.......not his packages)
<Yagisan> \sh: crimsun: are you still reading that horseshit on d-d ?
<\sh> Yagisan: I was reading joeys mail to ubuntu-motu...which is no horseshit, but quite serious
<Yagisan> \sh: that was also sent to d-d
<\sh> Yagisan: yes.. I know, I'm reading as well the mail headers :)
<Yagisan> \sh: it is horseshit, I'd expect him to know his choice of license by now, but it's people like him, why I lost interest in debian
<minghua> well, Joey Hess is a very reasonable person from my experience
<\sh> Yagisan: well...the gpl doesn't forbid that. If I release one source under the GPL license, I have the right to relicense it for a special distributor and implement something like "This distributor is not allowed to distribute my work"
<\sh> distribute means: shipping it on cd or have it in the repositories...
<crimsun> even reasonable people fly off the handle/deep end at times
<crimsun> I'm willing to ignore his polemics for the sake of the distributions
<Yagisan> \sh: that is no longer gpl then
<\sh> but anyways, it's a serious threat and we need a solution.
<Yagisan> minghua: are you sure ???
<\sh> Yagisan: then it's not GPL for the distributor anymore, for the rest it's still gpl
<Yagisan> \sh: Is he really dumb enough to make his work fail his own DFSG tests ?
<minghua> Yagisan: yes, his words are sometimes quite harsh, but in my opinion he is quite resonable
<minghua> Yagisan: and I don't see anything wrong with his request this time
<\sh> Yagisan: I don't know and I don't care. I care about ubuntu, and that's all. He is quite serious about it, and we should discuss his wish. Despite the fact that it's immature.
<\sh> bbl
<slomo_> siretart: ping?
<dholbach> good morning
<Yagisan> dholbach: I see you haven't read you email yet ;)
<dholbach> Yagisan: what are you referring to?
<Yagisan> dholbach: Mr hess give \sh some stress on ubuntu-motu or d-d
<Yagisan> s/give/giving
<dholbach> He's giving everybody stress and not the first time. :(
<Yagisan> I really don't understand why they hate ubuntu so much
<Yagisan> they don't do it for other distros
<dholbach> Yes, they don't.
<dholbach> Or not in that way.
<dholbach> Thanks for bringing my attention to it. I'll look through the posts again.
<dholbach> I'm just too busy to get myself into a flamewar for nothing.
<crimsun> whether "they" hate "us" or not is irrelevant, though. I personally lack the time and the energy to bother responding to such inflammatory stuff.
<dholbach> So if there's anything valid to answer to, I will do that.
<dholbach> dapper-changes@ and gnome-ftp-list@ might give you an idea, what's to do for me :)
<Yagisan> crimsun: I have the time, and energy, but I just vote with my feet. They seem far less professional now to me.
<pef> good morning !
<pef> what's can makes a package present in Debian not present in Ubuntu ?
<pef> like feedparser
<pef> http://packages.qa.debian.org/f/feedparser.html
<crimsun> it's in Ubuntu
<crimsun> it just has ftbfs
<pef> so all ftbfs packages aren't show on http://packages.ubuntu.com ? the only way to find them is to inspect buildd logs ?
<crimsun> that's correct
<crimsun> note that's one of the cited changes for 4.1-1
<crimsun> #348211
<crimsun> when it's synced, it'll be available as a binary in dapper
<pef> ok, does the sync will be made before uvf ? because it brokes a package
<crimsun> I don't know if autosync will be triggered RSN
<pef> ok, so I have to keep an eye on it :)
<pef> thanks for the info
<pef> another question on launchpad, about bugs assignements
<pef> if I will correct the bug right now assignee to me, if not, assignee to correct team (motu, kubuntu, ...), is it correct ?
<crimsun> sure
<slomo_> Yagisan: what happened to the x264 package?
<Yagisan> slomo_: where ? Is it missing ??
<slomo_> Yagisan: was it already uploaded? :)
<Yagisan> slomo_: http://revu.tauware.de/details.py?upid=1429
<Yagisan> slomo_: I did a new upstream
<Yagisan> slomo_: been to busy to fix it to become shared libs
<Yagisan> slomo_: but I found instructions somewhere
<slomo_> Yagisan: is it ok now?
<Yagisan> slomo_: well I use it often
<Yagisan> slomo_: I rebuild mplayer in breezy to use it
<slomo_> but it's still static library only?
<Yagisan> slomo_: in that package yes. I was looking in the avidemux forums and the had some notes on how to make it shared, but sorry -ENOTIME :(
<slomo_> Yagisan: hm ok :/ then let's do it for dapper+1
<Yagisan> slomo_: might be better actually - the new x264 package worked better then my first one
<Yagisan> slomo_: is the a list of what is synced from apt-get.org ?
<Yagisan> s/the/their
<slomo_> hm ask dholbach :)
<dholbach> not yet.
<dholbach> I'll work on it for Feature Freeze.
<Yagisan> thanks.
* Yagisan wonders if anything of mine will slip through this time, or if my repo will be passed over again ...
<pef> .nick pef_aw
<pef_aw> oops :)
<dholbach> Yagisan: you want your repo to be include by the apt-get.org import rather than the REVU way?
<Yagisan> dholbach: I send stuff to revu, to help me make a better package
<dholbach> yeah, that's the way.
<dholbach> cool.
* Yagisan needs to go shopping now. catch you later
<dholbach> see you
<viviersf> ajmitch, ping
<viviersf> why would a package say this : cp: cannot stat `./debian/tmp/etc/': No such file or directory
<viviersf> when you try to build it
<crimsun> viviersf: because it doesn't exist? Make sure the directory is created first
<viviersf> crimsun,
<viviersf> when i make that dir
<viviersf> and build
<viviersf> it gets removed
<crimsun> viviersf: no, you'd create the directory immediately before you cp something there
<crimsun> viviersf: otherwise, look at install(1)
<viviersf> i dont use that directory
<viviersf> its not even in the makefile
<viviersf> wait look here
<viviersf> if test -x /usr/bin/dh_installlogcheck; then dh_installlogcheck -pimpi-default-settings ; fi
<viviersf> dh_installchangelogs -pimpi-default-settings
<viviersf> dh_install -pimpi-default-settings
<viviersf> cp: cannot stat `./debian/tmp/etc/': No such file or directory
<viviersf> dh_install: command returned error code 256
<viviersf> 
<viviersf> its after the files and stuff
<minghua> viviersf: is there a debian/impi-default-settings.install file?
<minghua> or debian/impi-default-settings.dirs?
<viviersf> hold
<viviersf> this is there -> debian/impi-default-settings.install
<minghua> is there anything like etc/... in it?
<viviersf> yep
<ajmitch> viviersf: hello
<viviersf> tmp/etc
<viviersf> /tmp/usr
<viviersf> etc etc
<viviersf> - the /
<viviersf> ajmitch, trying to get this package compiled
<minghua> it has tmp/etc in it?
<viviersf> lemme paste
<viviersf> its 3 lines
<minghua> and you don't have debian/tmp/etc after build?
<viviersf> debian/tmp/etc/
<viviersf> debian/tmp/usr/bin
<viviersf> debian/tmp/usr/share
<viviersf> nope
<viviersf> i dont think it reads the .install file
<crimsun> that's install? Each line should have 2 fields, then.
<viviersf> that file
<viviersf> come strait out of kubuntu-default-settings
<minghua> well, looks to me a pretty broken .install file
<minghua> crimsun: it's okay to have only one file in .install file
<viviersf> minghua,
* minghua does it all the way :-)
<viviersf> it all worked until
<viviersf> i renamed the dir to impi-default-settings
<viviersf> see
<viviersf> i rename it
<viviersf> to kubuntu-default-settings
<viviersf> and it compiles
<viviersf> like wth
<viviersf> what file specifies which .install to use
<crimsun> do you have any references to kubuntu-default-settings in debian/* ?
<minghua> you have dh_install -pimpi-default-settings
<minghua> which means it will use impi-default-settings.install
<viviersf> no crimsun
<viviersf> minghua, i know that
<viviersf> but i wants to use kubuntu one
<crimsun> viviersf: is the diff.gz posted anywhere?
<crimsun> (link to orig.tar.gz would be helpful, too)
<viviersf> nope crimsun
<viviersf> there is no diff
<viviersf> im just using stuff from his package to make a new one
<ajmitch> it's probably a native package (for a good reason, too)
<ajmitch> can you put this source package somewhere that we can look at it?
<viviersf> erm
<viviersf> lemme try
<viviersf> our server aint up yet
<ajmitch> ah
<viviersf> ajmitch, can i email it to you ?
<ajmitch> sure
<ajmitch> ubuntu.com email address
<viviersf> ajmitch@ubuntu.com ?
<ajmitch> yes
<viviersf> k
<viviersf> err no
<viviersf> that not gonna work
<viviersf> its 20 mb big
<viviersf> omw
<viviersf> ah wait
<viviersf> ajmitch, its on its way
<viviersf> internet is just slow
<ajmitch> heh
<ajmitch> don't worry, I'm busy uploading packages at the moment, so I'm heavily lagged
<viviersf> kk
<viviersf> me to
<viviersf> line has contention :(
<viviersf> i gonna go get food quick
<viviersf> brb
<ajmitch> ok
<siretart> slomo_: pong
<siretart> morning, folks
<ajmitch> hi siretart
<siretart> huhu ajmitch
<\sh> hey siretart
<\sh> btw...I added joeys request to the TB Agenda with a link to ubuntu-motu archives of his post
<crimsun> that entire thread on d-d is just useless
<siretart> huhu \sh
<siretart> \sh: joeys request?
<crimsun> 'morn', siretart
<siretart> hey daniel!
<\sh> siretart: didn't you read his mail (cc to ubuntu-motu?)
<\sh> http://lists.ubuntu.com/archives/ubuntu-motu/2006-January/000139.html
<siretart> \sh: I was at 'our' regulars table, and am currently catching up with the emails
<\sh> siretart: hehe :)
<ajmitch> siretart: yes, I was away for only 4 days & suddenly have this massive flood of emails when I returned
<siretart> ah, I see
<ajmitch> ah, stupid me
<siretart> ajmitch: yes, there was really a lot of really exiting discussion about collaboration wrt ubuntu on the debian side
<siretart> and on the ubuntu side as well, of course
<ajmitch> yes, maybe something will come of it
<StevenK> ajmitch: So, I added myself to the Ubuntu dev list - do I get accepted, and then ask to be made a MOTU?
<\sh> StevenK: are you already a member?
<siretart> StevenK: ubuntu-dev and motu is basically the same
<ajmitch> StevenK: no, they're one & the same
<StevenK> Right.
* ajmitch looks up dcut semantics
<StevenK> dcut ftp-master rm \*
* StevenK grins.
<ajmitch> dcut ftp-master rm pnet*
<ajmitch> was what I wanted :)
<ajmitch> now I go back & re-sign these packages with the *non-revoked* key
<ajmitch> oh well
<ajmitch> maybe I'll retry tomorrow :)
<\sh> to be honest, I think it's time for a global solution, how this is all handled. those trench warfares is no good for both sides, and if we find a clear and for all good solution. Otherwise, speaking of myself, I'll step back from all duties. I'm really sick and tired of this whole sh*t. Collabrotion is good, but the animal farm syndrome of some people is not good.
<siretart> \sh: please. don't threaten with stepping down. lets search for a solution instead
<siretart> \sh: others are equally frustrated with this discussion
* StevenK is pondering creating a new key for Ubuntu.
<siretart> StevenK: what do you gain with that?
<StevenK> Which is a moot point at the moment, considering my @u.c address doesn't work yet.
<\sh> siretart: i'm not threatening. It has nothing to do with ubuntu or motu at all. It's my thinking of how I can do work without being careful.
<StevenK> siretart: I might lose a death threat, since I'm not advertising I'm a Ubuntu member.
<siretart> \sh: you are. and the problem is not new.
<lucas> hi motus
<StevenK> And does anyone need any help with merges?
<siretart> StevenK: are the flamewars on debian-private really that bad?
<\sh> siretart: then it's time to make it real.
<ajmitch> siretart: we cannot confirm nor deny anything about debian-private :)
<siretart> ajmitch: I know ;)
* ajmitch never remembers to read it
<dholbach> \sh: Don't get yourself depressed with this. It's 'some' people, a lot of others work with us quite nicely.
<StevenK> siretart: Yup.
<siretart> StevenK: :(
<lucas> \sh: siretart: let's write documents about Ubuntu and Debian so DDs understand us better
* ajmitch goes to read the gossip
<StevenK> It's the loud-mouthed three that make it suck for the rest of us.
<lucas> I really think *communication* is the way to go
<StevenK> Thomas Bushnell just can't keep his mouth shut.
<ajmitch> StevenK: oh I just give up on reading those threads, or those lists at times
<crimsun> I hate to put it this way, but the only thing that matters with regard to that flamewar is that the collaboration is way more important than any flaming by any upstanding member of either community. Sometimes I thank $somePower that /everyone/ dies.
<ajmitch> the collaboration will go ahead, even with the flames
<\sh> dholbach: I'm not depressing myself with this.
<\sh> dholbach: lets find a solution for that, this evening during TB..let's discuss joeys request, and see how we can deal with this.
<dholbach> \sh: You're pondering stepping back. That's a sign of depression to me. Don't let it get that far, please.
<crimsun> \sh: think of it this way: Ubuntu users are important, and we're all (including "those" DDs) doing something positive toward that end
<\sh> dholbach: it's a sign that i'm too old for this kind of early ninties distro wars. and it can't be vital for us all, that those problems arise every now and then.
<siretart> \sh: stepping back is not the right answer to that, imo
<dholbach> I think crimsun has some valid points and it's all about the view you have on it: if you look at Debian and Ubuntu and it's just "flamewar, spite and trouble" for you (not only you, \sh), there's a problem. :)
<ajmitch> times like this I feel like just ignoring the lists altogether & just doing some work
<crimsun> yep
<\sh> dholbach: so let's discuss a solution where we find a way to solve all this once and for all. It's dangerous as well for the reputation of Ubuntu (IMHO)
<dholbach> But let's not do this now. Let's all think about it and do it in a meeting.
<dholbach> Maybe even a meeting where we invite Debian folks to.
<dholbach> Maybe we should have a meeting beforehand, I don't know.
<dholbach> Let's make this all public on the mailing list.
<\sh> dholbach: we have to discuss joeys request during the TB...I think it's more then fair. he made a claim, and we should respect this.
<\sh> well...I think there are more people coming then and request their name removal anyways.
<lucas> I think we should calm down and communicate, for example in a wiki article
<lucas> so the average opinion of ubuntu for DDs improves
<lucas> the main problem is the official claim that Ubuntu contributes back to Debian
<lucas> we know it's not as true as we would like it to be
<lucas> other CDDs don't contribute at all (think of Linspire)
<lucas> and no DD complain
<lucas> (and I don't think they changed the Maintainer field at all)
<lifeless> thats not quite true
<lifeless> linspire was mentioned in the d-d thread
<lifeless> so, IMO the right thing to do is to ask for 'debian' to make a freaking decision
<lifeless> right now there is no consensus on the maintainer field
<lifeless> some want it changed
<lifeless> some dont
<lucas> before asking them to make a decision, we have to *explain* our position
<lifeless> ask debian to take a vote and make it policy what derivate distros should do
<viviersf> ajmitch,  you get the file ?
<ajmitch> viviersf: yes
<lifeless> our position is irrelevant
<lifeless> yes we are prominent
<lifeless> and yes we are trying to do the Right Thing
<viviersf> ajmitch, found the problem ?
<\sh> lucas: contributing back doesn't mean giving back. it means, we create something, and everybody (with a special preference to debian) is invited to take it. I don't see "contributing back" as "giving back something on a silver plate". But it should be possible to do it in a way, where everyone is agreeing.
<lifeless> but debian has -no- policy on this at the moment, so the Right Thing is purely a judgement call
<lucas> lifeless: most DDs don't understand how Ubuntu works, currently
<lifeless> if 'debian' wants to tear a strip of ubuntu, it has to stop it being a judgement call and make it policy
<lucas> \sh: some DDs understand it as giving back, that's the problem
<ajmitch> viviersf: trying something..
<lifeless> \sh: contributing to the commons is 'create something and whoever wants takes it'
<lifeless> \sh: we do create stuff *and* feed it into debian - such as the gcc4 transition etc etc etc
<lifeless> \sh: but we dont 'push' in everything we do
<ajmitch> and many DDs don't consider it a contribution unless it's filed as an attached patch in the BTS, nicely commented & split out
<Treenaks> lifeless: transitions we do in a week take 1.5 years in debian
<lifeless> ajmitch: which is their blindness IMO.
<lifeless> Treenaks: yes, but we have different constraints.
<\sh> lifeless: yes. the problem is not where DDs and Ubuntu Core Devs are the same person (like doko :)) The problem I see is, that we can't talk to any maintainer, especially not when one MOTU or somebody else is touching 100, 200 packages
<lifeless> \sh: note that I dont *think we should push everything*
<Treenaks> lifeless: sure, but it does tell you how interested DDs are in their own packages and/or Debian as a whole
<\sh> lifeless: I read it the correct way :)
<lifeless> some things - like gcc4 are appropriate to take leadership on, others - like individual package patches, well its a interpersonal thing not a project wide thing
<Treenaks> lifeless: if every DD cared, the transition would be done in a few months at most
<ajmitch> \sh: but that's because the debian model is what they expect - that a single person touches a small number of packages
<lifeless> Treenaks: no, thats not it
<lifeless> Treenaks: its simply people to talk too
<\sh> ajmitch: yes, but we are not touching the packages because of debian, we are touching the packages because of ubuntu, and not all patches and changes are important for debian (right now)
<lifeless> Treenaks: when we organise a 4 person sprint, it takes - oh 1 day to setup
<lifeless> when we organise a 100 person sprint it takes about 6 months
<lifeless> debian has 800 people to organise for any transition
<Treenaks> lifeless: yes. every one of them is subscribed to an -announce mailinglist. You send an email stating the transition is due in 2 months, and NMU if they don't upload
<Treenaks> lifeless: problem solved
<lucas> https://wiki.ubuntu.com/UbuntuDemystification
<Treenaks> but no, NMUs are taboo and the developer is holy
<dholbach> see the recent "patch to fix ftbfs, but no action taken for 300 days" thread. That's not a snide remark, but it shows a problem in there.
<lucas> can we brainstorm about what need to be in there ?
<Treenaks> uh developer/package connection is sacred
<lucas> also I wrote https://wiki.ubuntu.com/DebianCollaboration as a frontend to debian-related stuff on the wiki
<ajmitch> Treenaks: not necessarily
<\sh> dholbach: where is this thread?
<dholbach> debian-devel@
<Treenaks> dholbach: http://lists.debian.org/debian-devel/2006/01/msg00349.html and on?
<\sh> Treenaks: that's the holy war right now :)
<dholbach> http://lists.debian.org/debian-devel/2006/01/msg01079.html
<ajmitch> lucas: why did you link to https://launchpad.net/distros/ubuntu/+spec/motu-debian ?
<lucas> because it's related to the topic ?
<dholbach> motu-debian? what's that?
<lucas> I found it during my related-works search ;)
<ajmitch> dholbach: it was a proposed discussion for UBZ
<dholbach> Ah, yes.
<ajmitch> which is an empty spec
<ajmitch> Treenaks: seen http://wiki.debian.org/LowThresholdNmu ?
<Treenaks> ajmitch: that's voluntary
<Treenaks> ajmitch: it should be policy
<ajmitch> why?
<viviersf> k thx ajmitch
<Treenaks> ajmitch: because the current package ownership model hasn't scaled well
<ajmitch> Treenaks: I don't think that open-season on NMUs for everyone will necessarily work well either
<\sh> ajmitch: do you think the reports I filed into dbts are worth for the packagemaintainers? http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=sh@sourcecode.de
<Treenaks> ajmitch: I just gave up on Debian personally... so I don't care either way..
<Treenaks> ajmitch: As long as Ubuntu rocks (which, I know, depends: Debian)
<ajmitch> \sh: attached debdiffs are good, saying that something will be available in a couple of hours from archive.ubuntu.com not so much :)
<ajmitch> looks like most of them are patches, which is far better than I usually manage
<lifeless> Treenaks: well it has scaled well
<Treenaks> lifeless: 4-year release cycles prove that
<lifeless> Treenaks: debian is slow moving, but the relative man power per package is much larger than our
<lifeless> s
<ajmitch> Treenaks: MOTUs can work well because we're a small team
<\sh> ajmitch: libvisual has debdiffs python-qt3 has patches to upstream source qt-x11-free the immodule patch to fix the immodule patch is in the bugreport
<ajmitch> Treenaks: the chaotic activity that we do doesn't scale as well to 1000+ developers
<lifeless> ubuntu is geared towards small teams working with a range of skills, mentors + helpers in high intensity, short duration bursts
<\sh> ajmitch: and the python-qt3-gl hint, is a simple fix for the maintainer :) so I think it's only good to give him a clue :)
<lifeless> that means we *can* do 'break and fix' cycles
<lifeless> debian is geared towards continuously having a good release ready
<lifeless> more or less
<lifeless> the individual maintainer there works well because - they dont need global coordination to do anything
<lifeless> but the price is long cycles
<lifeless> myself, I think debian is fine as is, because - I think debian should never really bother to release.
<Mithrandir> lifeless: it's also a choice.  Debian doesn't want to have six month cycles.
<lifeless> having sid, a cared for repo of the latest and greatest code, maintained on an ongoing basis is rad.
<lifeless> Mithrandir: yup.
<lifeless> Mithrandir: although, have we gr'd that ?
<lifeless> ubuntus development versions are nowhere near as stable as sid IME.
<ajmitch> "f-spot 0.1.7 - Dec 16 2006 - Boston"
<ajmitch> hm
<ajmitch> I must have got a really future release here :)
<Mithrandir> lifeless: it's not been decided as such, no.  Except that the release team has posted a timeline which means ~18 months from sarge to etch.  I think that's fine.
<\sh> ajmitch: when did you came back from your time-journey? :)
<lifeless> Mithrandir: so do I
<ajmitch> \sh: I am in NZ, far ahead of anyone else ;)
<siretart> oops. wrong chan befer.. let's hope I didn't make the situation not even worse, with my post to -project..
<\sh> siretart: you can't make it worse...it's worse enough.
<lifeless> siretart: I think its a fine email
<lucas> siretart: I really think we should start communicate instead of playing flamewars
<lifeless> maybe a touch blunt
<lifeless> but it raises the key point
* ajmitch isn't subscribed to -project, probably a good thing
<siretart> ajmitch: it got CC'ed to -devel and ubuntu-motu
<lucas> https://wiki.ubuntu.com/UbuntuDemystification <= could we collaboratively write something like that before going on with the mail discussions ?
<siretart> lucas: nice start
* StevenK has just written a start for section 2 and 4.
* ajmitch still has > 30 merge bugs open
<StevenK> ajmitch: Wanna hand?
<ajmitch> StevenK: 25 of them are waiting on elmo to sync
<StevenK> Ahhh.
<ajmitch> the other 4 zope merges are simple
<ajmitch> and I'll be kindly filing bugs in debian for those
* StevenK needs to debug a mkfontdir SEGV for jnethack.
<ajmitch> since it's crucial that there be no divergence between debian & ubuntu there
<ajmitch> qemu is FTBFS on anything but i386, in debian & ubuntu :)
<siretart> great :/
<siretart> well, I'm off for lunch. cu
<ajmitch> bye siretart
<ajmitch> 4 packages updated to latest upstream, 1 to go
<ajmitch> it's great to see these RC bugs in debian being closed
<viviersf> erm
<viviersf> can one use a bash for loop in a Makefile ?
<lifeless> yes
<viviersf> :/
<viviersf> as soon as i put it in the makefile
<viviersf> it refuses to compile
<viviersf> for x in `find artwork/CrystalClearImpi/ -type d`; do echo moo;done
<ajmitch> heh, bzr viz shows a nice series of merges as I switched back & forth from desktop to laptop
<viviersf> :/
<ajmitch> lifeless: opensync still stuck in NEW, I see?
<lifeless> ajmitch: yup
<ajmitch> gar, bad build-deps on f-spot
<lifeless> ajmitch: lol
<ajmitch> it's a problem, since it needs a gtk# newer than sid has
<viviersf> i wonder why it doesnt want to work with the bash loops :/
<slomo_> siretart: i've updated mplayer to a new cvs snapshot... do you want to test it before i upload?
<crimsun> slomo_: I can if R isn't readily available
<siretart> slomo_: I don't have time to test it right now, if crimsum wants to test, great, if not, go on with upload, we can fix afterwards
<slomo_> siretart: ok, fine :) crimsun do you have amd64?
<crimsun> slomo_: not as a desktop
<siretart> slomo_: did you check in your changes in the motumedia svn?
<siretart> slomo_: so that I can see the diff?
<slomo_> siretart: not yet... will do after my final test ;) but i haven't changed anything except updating the patches and improving the "ubuntu branding" :) you'll see it in the diff later
<StevenK> crimsun: Can you see if mkfontdir from Dapper SEGVs on it?
<siretart> slomo_: just use it, even for testing purposes. Its really convinient..
<crimsun> StevenK: sec
<crimsun> StevenK: not here with this test case (copied /usr/share/X11/fonts/misc/*, gunzipped and ran mkfontdir)
<StevenK> crimsun: Check out jnethack's latest build logs for amd64.
<crimsun> k
<crimsun> oh, amd64? Hmm, I tested with ia32 (686)
<crimsun> sec, running test case
<slomo_> siretart: committed
<crimsun> ok, that test case succeeds (no segv)
<siretart> slomo_: I answered to that email
<siretart> ++ao=also,oss,sdl,esd,arts
<siretart> ?
<slomo_> siretart: which mail?
<siretart> to the commit mail, it went to tiber
<slomo_> siretart: hehe, nice typo :) already fixed now ;)
<siretart> as said, I find svn very convinient ;)
<slomo_> siretart: oh no... you already had a ubuntu8 version there? damn...
<slomo_> siretart: sorry, i only copied the files over there :/
<slomo_> siretart: what did you change in ubuntu8?
<siretart> err huh?
<slomo_> siretart: look at the diff of the changelog ;)
<siretart> slomo_: the archive has just ubuntu7, the ubuntu8 is work in progress
<slomo_> siretart: ok... hmm, the svn->mail thingie doesn't work properly with my name ;)
<siretart> slomo_: my changes should be documented in the svn log
<crimsun> StevenK: hmm, is bdftopcf doing sane stuff?
<siretart> slomo_: no, I just edited debian/changelog
<slomo_> siretart: ok :) next time i'll be more carefull ;)
<StevenK> crimsun: I'm not sure. :-)
<StevenK> crimsun: It's only a problem on ia64 or amd64.
<StevenK> crimsun: If you can give me a shell, I can debug. Or you can. :-)
<crimsun> StevenK: well, I ran mkfontdir in win/X11, and mkfontdir generated a valid fonts.dir
<crimsun> hmph. You're hitting #347842
<StevenK> I see that.
<StevenK> crimsun: So, which of us shall debug?
<crimsun> StevenK: I don't control the amd64 host, unfortunately, else I'd give a shell
<Mithrandir> StevenK: mail maswan@acc.umu.se asking for access to ravel, include ssh key and preferred username.  Please sign the mail.
<crimsun> StevenK: however, when I removed the bdftopcf lines in debian/rules, it does build
<crimsun> mkfontdir parses bdf files, so I'm not sure why bdftopcf is even called
<StevenK> crimsun: Right, so noted.
<StevenK> crimsun: If I prepare a ubuntu2 will you upload?
<crimsun> StevenK:
<crimsun> ack, sure
<crimsun> StevenK: in sys/unix/Makefile.top, you can just kill the bdftopcf calls
<StevenK> I was also killing the bdftopcf calls in debian/rules.
<StevenK> crimsun: Can I just point to the .d{sc,iff.gz} ?
<crimsun> StevenK: yep
<StevenK> crimsun: http://wedontsleep.org/~steven/jnethack
<StevenK> crimsun: Please try building it on your amd64 first.
<crimsun> StevenK: will do.
<crimsun> StevenK: mkfontdir still segfaults (fixed up debian/rules), so #347842 still seems valid. Something more ominous is present, since it didn't appear last build.
<crimsun> -> coffee
<Yagisan> Seveas: ping
<Treenaks> Does anyone know a CDBS python package?
<dholbach> Treenaks: what are you looking for?
<dholbach> Treenaks: a module or something that just 'uses' python?
<Treenaks> dholbach: a python module packaged using CDBS
<dholbach> Treenaks: kiwi
<Treenaks> dholbach: so I can easily hack it into shape for my own python stuff ;)
<Treenaks> dholbach: no package 'kiwi'
<slomo_> Treenaks: paramiko
<dholbach> Treenaks: it's at least in dapper
<Treenaks> dholbach: ah.. this is my breezy server :)
<Treenaks> isn't there something like dh-make-perl for python?
<Treenaks> (dh-make-python?)
<lucas> can somebody review https://wiki.ubuntu.com/UbuntuDemystification ?
<ogra> lucas, 8400 packages in universe ?
<lucas> $ mdt dist-grep-dctrl-sources dapper -F Section -s Package -n universe | wc -l
<lucas> 8397
<ogra> then we'd have 9000 in main
<lucas> *source*
<ogra> ah, yes, sorry
<lucas> I'll fix it
<lucas> thanks for seeing this
<ogra> i dont understand what you mean with "tools"
<lucas> during the last MOTU meeting, we quickly discussed a "database of divergence"
<lucas> to be able to quickly determine the kind of divergence each package has
<lucas> this would also help debian maintainers a lot
<Yagisan> lucas: our way of contributing "sucks" because upstream hasn't yet worked out how it would like the patches (and if it wants them at all)
<ogra> make: (Debian, of course, but also apt-get.org or  REVU)
<Lathiat> lucas: hey that page is cool
<ogra> (Debian, of course, but also apt-get.org or  REVU and others)
<Lathiat> im going to be yakking to the debian miniconf about ubuntu/motu/interactions and stuff, bit of usefull info there altho largely what i had in mind
<ogra> we might pull other sources on demand ...
* lucas phone
<ogra> in the third part i'm missing unresponsive DDs .... we often made changes to packages in the past because the DD didnt respond or stuff that users wanted wasnt accepted in debian ... (might be because of different policys or because the DD just didnt like)
<Yagisan> lucas: might want to mention that non-motus help too
<ogra> Yagisan++
<Yagisan> G'day ogra
<ogra> hey
<Yagisan> ogra: I've been beating plone on breezy into shape http://eyagi.bpa.nu:8081/eyagi
<Yagisan> ogra: going well so far
* lucas </phone>
<ogra> Yagisan, yeah, getting better :)#
<Yagisan> ogra: doesn't ubuntu.com use plone ?
<ogra> FOR THE WEBSITE STUFF, YES
<ogra> oops
* ogra kicks his capslock 
<Yagisan> ogra: my ears are ringing
<Yagisan> ogra: and of course, it runs on ubuntu right ?
<ogra> Yagisan, indeed
<StevenK> Yagisan: And that some upstreams want to be fed patches on a platter.
<Yagisan> ogra: so, we'll be getting plone/zope sec updates quickly right ;)
<ogra> Yagisan, quickly ?
<Yagisan> StevenK: no, they are just being arses because they can
<ogra> only security updates for released stuff ;)
<Yagisan> ogra: you don't use your own packages :(
<ogra> Yagisan, sure we do
<StevenK> Yagisan: Potato, potatoe.
<ogra> but we dont upgrade packages in releases if there isnt a dataloss bug/security reason
<Yagisan> ogra: sure - but I'm not going to wait 3 days between USN and .deb arriving, right ?
<ogra> unlikely
<ogra> join the security team to make sure they appear in time ;)
* Yagisan thinks of recent kernel update that took that long
<ogra> pitti will be happy for every helper
<Yagisan> ogra: Is that a job offer ;)
<ogra> Yagisan, i dont give away jobs ... i'm not canonical HR ;)
<Yagisan> ogra: I give pitti advance notice when I find something + patch if I can
<lucas> ok, I integrated all your changes into https://wiki.ubuntu.com/UbuntuDemystification
<slomo_> siretart: wonderfull... mplayer compiled fine everywhere :)
<siretart> slomo_: cool :)
<Yagisan> lucas: seems better now. BTW any of our other upstreams upset like debian ?
<Yagisan> slomo_: with x264 ?
<slomo_> siretart: and works fine at least for me, better than the previous version... h264 decoding works now as expected :)
<Yagisan> slomo_: and libdts ?
<slomo_> Yagisan: nope... we need to get your package approved before and i wanted to wait until we have a shared library of it... i hate static libraries ;)
<slomo_> Yagisan: libdts support was there forever iirc
<Yagisan> slomo_: never saw it in control
<lucas> Yagisan: we don't really have other upstreams currently
<siretart> slomo_: w00h00
<lucas> apt-get.org can't really be considered an upstream
<ogra> Yagisan, according to dholbach's feedback for the apt-get.org stuff, other upstreams are more than happy with use
<ogra> lucas, why ?
<slomo_> Yagisan: it's in control now ;P and "Checking for libdts support ... yes"
<lucas> well, it's not a distribution
<lucas> it's just a repository of repositories
<Yagisan> lucas: irerelavent
<ogra> lucas, is sourceforge a distribution ?
<dholbach> lucas: It's people.
<ogra> imho upstream == software developer ...
<lucas> dholbach: did you contact maintainers on a package per package basis for apt-get.org ?
<ogra> lucas, yes, he did
<dholbach> lucas: yeah.
<lucas> ok
<Yagisan> ogra: that rules me out ...
<lucas> ah
<lucas> can somebody request the removal of ruby-gnuplot from universe ?
<ogra> and there will be others in the future
<lucas> I packaged it inside debian
<lucas> so I'll be synced in 1 or 2 weeks
<ogra> then you should just sync it
<ogra> to late
<lucas> the source pkg name changed
<lucas> it's a new package
<ogra> UVF is in two days
<lucas> not an update
<ogra> make sure to get it in *now*
<lucas> it still has to go through NEW in debian
<Yagisan> yes, sometimes kantonix ?? etc have intresting .debs
<ogra> sivang, wannabe half a seb ?
<sivang> ogra:  for starters yes :0
<sivang> :-)
<ogra> sivang, you'd have to cope with dholbach, he's already seb96 (and rising) ;)
<dholbach> haha
<sivang> ogra: yes I Know, he's exp'ing by the minute :)
<Nafallo> we had seb{64,128,256,512,1024} on #ubuntu-desktop some minutes ago :-P
<slomo_> siretart: i'm writing the mail to siggi now finally ;)
<siretart> :)
<ogra> lucas, you probably should also point out the "whi changed it last is responsible" rule, so DDs know whom to poke
<ogra> s/whi/who
<lucas> I'll add it to the short crash course at the bottom, ok ?
<ogra> we should advertaise this a lot more, then the Maintainer/Uploaders discussion is pointless
<ogra> yup
<slomo_> ogra: does this rule also count if someone only uploads a rebuild against some new library or adjusts build-dependencies to fix compilation?
<ogra> lets just try to make that rule more public ... it should clearify the discussion
<ogra> slomo_, in the past it always counted
<ogra> the changelong is the relevant part for ubuntu ... as the control file is it in debian
<slomo_> ogra: ok :) and what about mass-rebuilds like for... say... cairo in the past? seb128 would be responsible for millions of packages back then
<ogra> yup
<tseng> doko would own all the c++ :)
<ogra> he rebuilds only stuff in main ... and might know who will take care ...
<ogra> yes, doko is an evil child ;)
<ogra> he rebuilds the world for fun :)#
<Kyral> Morning MOTU
<slomo_> or infinity who fixes stupid packaging bugs everywhere ;)
<lucas> ogra/dholbach: I added a note about team-maintenance and changelog
<ogra> great
<ogra> we should probablky have a wikipage explaining the changelog rule a bit deeper, so we can link to it ...
* Kyral sighs
<Yagisan> Kyral: there there, it'll be ok. While debian is still arguing, and we keep releasing, they will be our downstream in no time ;)
* ogra kicks xscreensaver 
<Kyral> nah
<ogra> you evil evil package !
<Kyral> Another "VLC uses GTK 1" bug
* Kyral goes to reject
<Kyral> Malone 28753
<Ubugtu> Error: Could not parse data returned by Malone: 'NoneType' object has no attribute 'group'
<Kyral> ...
<slomo_> siretart: LP finally works for connecting packages and people/groups :) https://launchpad.net/people/motumedia/+packages
* Yagisan wonders - how long do we need to keep debian arguing, before we have released enough to be upstream ...
<ogra> Kyral, why reject ?
<Kyral> Because there is a reason
<ogra> Kyral, isnt that fixed in dapper ?
<Kyral> Yah
<Kyral> but this is a breezy thing
<ogra> so set it to fix released ;)
<Kyral> https://launchpad.net/distros/ubuntu/+source/vlc/+bug/28753
<Ubugtu> Error: Could not parse data returned by Malone: 'NoneType' object has no attribute 'group'
<ogra> and point out the version that fixed it
<slomo_> hmm, what happened to Ubugtu?
<Kyral> hmm
<Kyral> he said the Backport is usign GTK1
<ogra> ah, backports ...
<Mez> ... ?
<Mez> backports?
<Kyral> Personally I haven't used VLC since it got removed in a Dist-Upgrade
<Kyral> nothing Mez, was just mentioning that the Bug Report mentioned VLC from Backports
<Mez> ah - if it's a problem in bacports - poke it over to me
<Kyral> I'm making sure it isn't a problem in Dapper first :P
<slomo_> Kyral: what happened to spe?
<Kyral> Mez you may want to backport the latest VLC...
<Kyral> slomo_: Its very buggy?
<Kyral> I mean it builds fine
<Mez> kyral - we'll see what you get first - then post to the backports mailing list and we can take it from there
<Kyral> but Lintian throws errors all over the place
<Mez> what linitan errors?
<slomo_> Kyral: hmm, can you upload it to revu?
<slomo_> Kyral: i'll take a look then...
<Kyral> Mez: that was to slomo ;P
<Kyral> slomo_: yah, along with another package I have to do
<Kyral> So if the Fix is in Dapper, set it to Fixed Release?
<Kyral> https://launchpad.net/distros/ubuntu/+source/vlc/+bug/28753
<Ubugtu> Error: Could not parse data returned by Malone: 'NoneType' object has no attribute 'group'
<Seveas> Yagisan, ping
<Seveas> urgh.. ubugtu is broken again - they must have changed the layout
<Seveas> @quit
<Kyral> if the report looks wrong to anyone...feel free to change it
<Yagisan> Seveas: pong
<Seveas> Yagisan, you called a few hours ago :)
<Seveas> well, an hour ago probably
<Yagisan> Seveas: quite. pitti said you had an rss feed of the USN ?
<Seveas> Yagisan, ubuntulinux.nl/files/usn.xml
<Kyral> slomo_: Spe going into REVU
<Kyral> Ignore the NMU stuff, I want to talk to doko about it
<Yagisan> Seveas: thanks. perhaps it should be more prominent (I wonder why it's not from canonical though)
<Yagisan> Seveas: google only gave me dead links earlier
<Seveas> Yagisan, I suggested that a few times :)
<Yagisan> Seveas: would you mind if I pull that feed on my website too ?
<slomo_> Kyral: thanks
<Kyral> thats streight from applying uupgrade to the old package
<slomo_> Kyral: the patches applied without problems?
<Kyral> no
<slomo_> did you update them?
<Kyral> I had to delete two from the debian/patches
<Kyral> I have no idea what they were doing
<slomo_> *sigh*
<slomo_> then forget it :P i'll do it when i find some time ;)
<Kyral> lol
<slomo_> it's in the changelog what these patches do ;)
<tepsipakki> anibal: ping
<Kyral> 0.8.1d didn't even uupdate cleanly
<Kyral> Oh I have an upstream who wants to know what the best way to apply internationalization is
<ogra_> just make spe a metapackage that depends on pida ;)
<Kyral> lol
<Kyral> Oh if any MOTU would review laptoptemp it would be awesome :P
<tepsipakki> kyral: where?
<tepsipakki> oh
* Kyral blinks
<tepsipakki> sorry, you asked for a review, not test
<Kyral> lol
<tepsipakki> :)
<Kyral> I'm running it on my laptop
<Kyral> it works :D
<Kyral> mmm, I hate having to rename a dir...
<Kyral> then again this package didn't even have a directory lol
<Kyral> hmm to use dh_install I just make a <packagename>.install file and call dh_install?
<lucas> basically yes
<lucas> but if your files are doc, examples, etc ...
<lucas> use dh_installsthing instead
<Kyral> nah
<Kyral> this package is literally a .c + Makefile ;P
<Kyral> I just put the <executable> /usr/bin in the installfile ;P
<tepsipakki> ok, I'm now trying to make gtkpod-aac as promised.. but dpkg-gencontrol fails: error: source package has two conflicting values - gtkpod-aac and gtkpod
<slomo_> you have to change the source package name in the changelog and control
<tepsipakki> ah, the changelog too..
<tepsipakki> I thought it was as easy as to only diff against control and rules ;)
<tepsipakki> hmm what version should I use, the same as the gtkpod (-1ubuntu1) or -0ubuntu1, since debian doesn't have this?
<slomo_> -0ubuntu1
<slomo_> but be carefull with the replaces/conflicts/provides fields :)
<tepsipakki> i only added a conflicts: gtkpod
<tepsipakki> so far..
<tepsipakki> there aren't any packages that depend on gtkpod, at least yet
<slomo_> ok, fine then :)
* Kyral yawns
<Kyral> yo
<tepsipakki> ok, it's ready
<Kyral> slomo_: Mind looking at laptoptemp?
<tepsipakki> hmm, could the gtkpod-aac source package use the same orig.tar.gz as gtkpod?
<slomo_> sure
<slomo_> with another filename but everything else can and should stay the same
<tepsipakki> yes
<tepsipakki> I get some errors when building the dsc
<tepsipakki> dpkg-source: cannot represent change to ...
<azeem> tepsipakki: to ... what?
<tepsipakki> dpkg-source: cannot represent change to po/de.gmo: binary file contents changed
<tepsipakki> etc
<jamessan> tepsipakki: sounds like your clean target isn't cleaning everything
<tepsipakki> oh crud, true
<tepsipakki> it's the debian/gtkpod-aac/*
<tepsipakki> I'll continue tomorrow :) ->
<\sh> siretart: ping
<\sh> ajmitch: ping
<ajmitch> \sh: pong
<\sh> ajmitch: I have to go out for a while...I don't know if I'm able to be back when the meetings starts. I wrote some points for discussion on the agenda page...if they need some things. More information can be found easily on d-d :)
<\sh> ajmitch: only that you know :_
<ajmitch> ok
<\sh> ok...laters
<StevenK> Waaah. Six hours of sleep.
<Hobbsee> StevenK: sleep?  what's that?
<raphink> lol
<ajmitch> morning StevenK ;)
<ajmitch> why are these australians up so early?
* StevenK blearily eyed waves to people.
<StevenK> TB meeting.
<StevenK> Well, that's why I'm up.
<raphink> yep
<raphink> in 7 minutes
* StevenK nods.
<raphink> hehe
* Kyral sits in on the TB Meeting
<dholbach> hey StevenK, raphink
<raphink> hi dholbach
<raphink> :)
<Hobbsee> ajmitch: they didnt sleep :P
<raphink> coming to the TB dholbach ?
* Hobbsee is actually going to be there at the right time for the meeting!  woo!
<dholbach> I should think so (while debugging some other stuff)
<raphink> great Hobbsee :)
<Hobbsee> hehe
* raphink cools down before the meeting...
<sistpoty> hi folks
<ajmitch> morning sistpoty
<Hobbsee> morning sistpoty
* StevenK waves to sistpoty.
<sistpoty> erm... didn't we want to discuss UVF handling for universe (proxies etc.) this tb-meeting?
<ajmitch> yes, quickly add it :)
* ajmitch doesn't know who's been volunteered, ogra & dholbach will know
* sistpoty doesn't remember as well
* ajmitch pings ogra :)
* ogra pongs ajmitch 
<ajmitch> ogra: UVF exceptions, are we ratifying that at TB?
<ajmitch> the people who can ask
<ogra> nope, we did that in the motu meeting, but we need contacts, thats what we wanted to ask ...
<ajmitch> ok, who was chosen?
<sistpoty> ogra: could you please check the TBAgenda (just added the point)?
<ogra> oh, a long list iirc ...
<ogra> sistpoty, mdz will ask for other stuff at the end ...
<ogra> #we can bring it up there
<sistpoty> ogra: oh, should I remove it then?
<ogra> no, if you have put it there already, leave it
<sistpoty> :)
<ogra> just dont assume the people reload the page and see it ;)
<sistpoty> hehe
* Kyral watches Ubuntu-Meeting taking notes for when he goes for MOTU
<crimsun> congrats, lucas
<tseng> lotusleaf: yay
<lucas> :-)
<Kyral> Congratz dude
<tseng> ermm
<lucas> thank you all for the support
<tseng> lucas
<Kyral> now you get pestered with REVU requests ;P
<lotusleaf> tseng: darn, I was hoping I would get the 'yay' :P
<LaserJock> was lucas first?
<lucas> LaserJock: yes
<LaserJock> lucas: congrats
<lucas> :-)
* Kyral thinks it will be a while until he is MOTU
* Hobbsee knows it will be a long time before she even thinks about being MOTU
<lucas> think about membership first
<lucas> (if you haven't already)
<LaserJock> it is suprising how fast you can learn though, especially when we have 6 month release cycles
<Kyral> yah
<dholbach> guys, you'll make it in no time. We'll have so much stuff to fix for Dapper, so you'll all get some uploads under your belts.
<Kyral> lol
<Kyral> Yah
<sistpoty> lucas: for rev: "Altering lucas@lucas-nussbaum.net to level reviewer"
<Mithrandir> dholbach: haha :-)
<dholbach> :)
<Kyral> I'm always looking at GNOMEFiles for new rthings :D
<ajmitch> dholbach: I hope I can
<Kyral> Actually I have 3 things under my belt...right now
* ajmitch hasn't uploaded to ubuntu for nearly a week
<Kyral> laptoptemp, GTKEdit, yamysqlfront
<Hobbsee> lucas: give me time to fix some of the packaging errors first lol - i'd only intended to watch the process for dapper anyway - i'd never dreamed of uploading anything :P
<dholbach> ajmitch: ha, I wish I could say that, I'd be on vacation or something.
<Kyral> lucas you can look at laptoptemp ;P
<ajmitch> dholbach: I did some debian uploads though :)
<Mithrandir> Hobbsee: why not?
<dholbach> Hobbsee: We can surely find you something :)
<ajmitch> and I was offline for ~4 days
<Kyral> actually...*switches terms and runs uscan on laptoptemp*
<ajmitch> the grilling for MOTU seems to have been turned up now
<Hobbsee> Mithrandir: and dholbach...i'm sure you can - but i'm supposed to leave to go on holidays in a couple of hours, and i'll only be back after UVF
<Kyral> yah
<dholbach> ajmitch: moderate grilling :)
* Kyral is scared
<ajmitch> dholbach: not like the core-dev grilling :)
<Hobbsee> oh dear...sounds very scary....
<ajmitch> 'what colour was keybuk's hair?'
<dholbach> Hobbsee: we'll have enough to do then - if you want to join us, we're happy to have you here :)
<lucas> sistpoty: thanks, even tho I must admit that REVU isn't one of my priorities. my next TODO item is summarizing the status of the ~300 packages in universe which aren't in Debian
<Mithrandir> Hobbsee: bugs won't stop piling up because of UVF. :-)
<Kyral> Is there a Low Mem spec?
<dholbach> Hobbsee: Where are you going on VAC?
<Hobbsee> true, but whether i have the expertise to fix them is an interesting question - i guess there's always help around
* Kyral sighs
<Hobbsee> dholbach: i'm in sydney now, going over to adelaide till the 28th, supposedly
<Kyral> azeem uploaded EasyChem, but it hasn't appeared in the repos
<azeem> dinstall was just a few minutes ago
<azeem> it should hit the mirrors in a couple of hours
<Kyral> oh lol
<Kyral> I didn't get an email
<azeem> ah, right
<azeem> it is NEW
* Kyral wonders if there is a formal spec for Low Performance systems
<azeem> Kyral: http://ftp-master.debian.org/new.html
<Kyral> hmm
<crimsun> congrats, hub
<ajmitch> well done :)
<Kyral> congratz dude
<Kyral> hmm is there a way to convert a Readme.html to a manpage?
<LaserJock> congrats hub
<sistpoty> hub: congrats :)
<hub> thanks guys
<LaserJock> azeem, how long do items usually stay in NEW ?
<StevenK> Kyral: Not easily.
<StevenK> HTML -> DocBook -> man?
<StevenK> However, that is likely to look like arse.
<azeem> LaserJock: not sure about new packages these days, but things which are only there due to transitions are usually processed fast, i.e. at most a couple days and usually the same day
<azeem> LaserJock: it used to be very bad in the past, when packages lingered there for months
<LaserJock> azeem: ok, I've been on ther 5 days so far, I just wondered
<ajmitch> sometimes it's less than a week, othertimes it's closer to 2 weeks
<Kyral> StevenK: yah I'll just install is as readme
<Kyral> meh..I keep getting any and all messed up
<Kyral> C programs are "any" right?
<azeem> yes
<LaserJock> what's with xvidcap being in NEW for a year?
<Kyral> okay
<azeem> LaserJock: there are probably hairy patent or licensing issues on that one
<DoeRayMe> hey i was told to ask here, if a package i need can be added to the repo, http://gift-fasttrack.berlios.de/ which a network plugin for giFT, they have a debian package availible, but would prefer if it was in the Ubuntu Repo ;)
<dholbach> DoeRayMe: http://wiki.ubuntu.com/UniverseCandidates might be what you want.
<hub> dholbach: how will I get upload rights?
<dholbach> hub: http://wiki.ubuntu.com/Uploads
<hub> ah ok
<ajmitch> follow instructions there & wait for elmo
<hub> ok
<LaserJock> whay to go raphink
<crimsun> congrats raphink
<raphink> yeah :)
<lucas> raphink: congrats :-)
<dholbach> NEW MOTUS!
<raphink> thanks
<ajmitch> now, StevenK...
<ogra> #yay
<dholbach> NEWS FOR THE MOTU REPORT!
<dholbach> :-p
<hub> congrats to the new motus
<raphink> yeah :)
<ajmitch> StevenK: ready for the interrogation?
<Hobbsee> hehe
<raphink> hehe
<Hobbsee> well done raphink :)
<raphink> thanks Hobbsee :)
<raphink> :) :)
<Kyral> lol
<Kyral> Now for you guys to Revu things for us :P
<raphink> Kyral: I review things already :p
<raphink> ;)
<raphink> but now i can advocate :)
* ajmitch thinks the TB should just skip to voting
<raphink> hehe
<Kyral> oaky dh_installexamples
<Hobbsee> hehe!
<raphink> huhu
<raphink> let switch to signing the package ;)
<Kyral> I just make a file called "package.examples" and list the files I want installed into /usr/share/doc/package/examples?
<raphink> never used examplse but I think that's it
<raphink> and if you have only one binary created by the source
<raphink> then naming the file "examples" should be good
<raphink> package.{examples,postinst,etc.} is only useful for multiple-binary packages
<Kyral> ahh
<Kyral> raphink: review laptoptemp please?
<buxy> StevenK: what about joining Utnubu ? :)
<raphink> after the TB Kyral ok?
<ajmitch> buxy: always trying to draw people in.. ;)
<raphink> hmm actually I'm with friends now so after TB I might enjoy a bit my time with them ... later in the evening
<hub> I have to recoved my REVU password
<Kyral> lol
<hub> it is on the desktop at home
<raphink> hub: really?
<raphink> haha
<ajmitch> buxy: I've been meaning to help out, once I get around to it ;)
<buxy> ajmitch: yeah, it was in response to what he said in -meeting ("ignore debian and work on ubuntu")
<raphink> oh hi buxy
<ajmitch> buxy: sadly my debian packages don't manage themselves so well
<buxy> hehe
* ajmitch did manage to close 4 RC bugs in yesterday's uploads
* buxy also congrats all the new MOTU
<ajmitch> the bad part is that they were there at all :)
<raphink> thanks buxy :)
<LaserJock> buxy: what does it take to work with Utnubu? Do you have to be a DD?
<raphink> I guess it helps to get things in debian LaserJock
<buxy> LaserJock: it's not necessarily required ... but Utnubu certainly needs people familiar with bith distributions :)
<stratus> LaserJock, no
<stratus> buxy, not exactly
<LaserJock> I've been trying to work on the debian-science and motu-science relationship
<stratus> buxy, btw nice nickname Raphael. :)
<buxy> thanks stratus
<stratus> buxy, please review it after: https://wiki.ubuntu.com/DebianDemystification
<crimsun> congrats, StevenK
<dholbach> EXCELLENT :)
<ajmitch> LaserJock: ubuntu-mono & debian-mono have a good working relationship now
<dholbach> I'm so happy to have you guys in here!
<StevenK> Heh
<ajmitch> well done stratus
<ajmitch> sigh
<ajmitch> well done StevenK
<LaserJock> but the maintainership in Debian makes it hard for me to want to contribute to Debian unless I can make a commitment to maintain packages in the Debian sense
<ajmitch> stratus: you need to change your nick or something :)
<StevenK> Thanks, guys.
<stratus> ajmitch, never :)
<ajmitch> stratus: you're basically just taking packages that are in universe at the moment, and maintaining some of them yourself?
<stratus> ajmitch, yes and no. Yes because i did some 'back merging' but no, since i'm a utnubu member too and i informed the team about that.
* Kyral goes to work on writting a manpage in nroff
<ajmitch> so it's NMU by anyone on the team, or others
<stratus> ajmitch, basically i decided not to keep those packages under utnubu svn repository using a baz or bzr one.
<ajmitch> right, I use bzr for most of mine now
<stratus> ajmitch, at this point in time yes but the deal is that we don't have decided about the uploaders field yet.
<ajmitch> I should probably pickup a few that are in ubuntu as well
<stratus> ajmitch, pkg-gnome and pkg-perl projects have different policies about uploaders field, utnubu should pick one.
<ajmitch> and pkg-mono probably has a different one again
<stratus> ajmitch, so we can setup a bzr repository for utnubu if you want.
<ajmitch> stratus: but bzr doesn't work quite as well like that
<stratus> ajmitch, i think that pkg-mono is using the same policy as pkg-perl. The difference with pkg-gnome is that they use cdbs for almost everything.
<ajmitch> I end up having a separate bzr branch for each debian dir of my packages
<stratus> ajmitch, i know, i miss 'tags' in bzr.
<ajmitch> it will come
<stratus> ajmitch, i see.
<ajmitch> ah yes, you're the gnome-sudoku maintainer ;)
<stratus> atm yes, but as i said the plan is move everything that i 'back merged' from ubuntu to utnubu group
<ajmitch> right
<stratus> we're talking about 5 packages, gdebi is special since i'm contributing to it as upstream too. I've my own bzr branch but mvo is authoritative.
<LaserJock> anybody familiar with svn-buildpackage here?
<ajmitch> I've used it
<sistpoty> LaserJock: little bit
<stratus> me too
<LaserJock> well, I'm trying to run dch -i and it says that the package name in changelog isn't the same as the parent directory (cause it is trunk)
<buxy> LaserJock: use "svn co svn://..../trunk packagename" when you checkout the package
<buxy> and then the directory has a good name
<LaserJock> oh, that makes sense
<buxy> (or rename directly "trunk" if that's the directory that you checked out)
<stratus> yes, but now it will be safe run "mv trunk packagename"
<stratus> since you already did some changes, right?
<LaserJock> umm, I don't have any uncommited changes right now
<LaserJock> is there any good resources on svn-buildpakcage, I just can't get anything to work
* buxy can't login in Ubuntu's wiki, despite having correctly configured his LP account ... what can I do ?
<ajmitch> ask #launchpad
<stratus> buxy, i've a LP account and i can login into wiki, but my LP account was configured days before my first login attempt into the wiki - maybe wiki needs sync, it isn't authenticating in the same db.
<buxy> stratus: I configured my LP account several days ago already ...
<sistpoty> LaserJock: there is a rough guide at the usual /usr/share/doc/ place
<stratus> LaserJock, svn-buildpackage is just "dpkg-buildpackage for svn maintained packages", there's nothing much more than that. I use it  with pbuilder too anyway.
<Kyral> whee
<stratus> buxy, so it looks like a bug.
<Kyral> my first manpage written in nroff
<LaserJock> stratus: I'm just not getting things to build and the error always seems to be with something with the svn part, I guess I just need to read more docs
<hub> how to I recover my password for REVU?
<sistpoty> hub: enter any password ... then you'll get a link to "recover password"
<hub> ah yeah
<hub> I re-missed that part
<stratus> LaserJock, maybe a pratical short tutorial can help you, try at: pkg-perl.alioth.debian.org/subversion.html
<LaserJock> stratus: ah, thanks. that should help
<stratus> LaserJock, you're welcome
<hub> works now
<hub> thanks
<sistpoty> np
<sivang> anyway, I saw that MOTU admissions are getting harder from TB meeting to another :) I have a lib I want to package, how do I Start?
<raphink> sivang: by reading NDMG if you havent' yet?
<sistpoty> sivang: did you read the library packaging guide yet? (http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html)
* sivang starts reading.
<hub> so do I still need to upload new packages to REVU?
<sivang> raphink, sistpoty : I could have swore I bookmarked that already, no idea where that went.
<sistpoty> hub: yes... every new package needs two advocates, doesn't matter wether packaged by a motu or not
<hub> ok
<siretart> hi folks
<Kyral> GTKEdit ready for REVU
<JohnnyMast> hi
<JohnnyMast> vacatiom is over :)
<JohnnyMast> -m +n
<sistpoty> hi siretart
<siretart> ah, i see that I didn't miss the exiting part of the meeting yet :)
<ajmitch> JohnnyMast: good, you've got outstanding merges to get done in the next 2 days :)
<raphink> hi siretart
<JohnnyMast> i know that .. my vacation is over now so lets get rocking :)
<stratus> see you in some hours
<sistpoty> siretart: do you remember who was proposed for uvf exemption proxies? (topic is still on the list)
<ajmitch> bye stratus
<siretart> sistpoty: that was you, me, ajmitch and crimsun, irrc
<siretart> iirc
<siretart> sistpoty: are you tomorrow at the uni?
<siretart> I think we should finally meet somewhere :)
<sistpoty> siretart: I didn't intend to go there... I'm still a little bit ill :(
<ajmitch> siretart: LCA is next week, meet up in NZ
<siretart> oh. bless you!
<siretart> ajmitch: good idea :)
<sistpoty> he, well, I am much better already (even smoked some cigarettes again today :)
<sistpoty> siretart: what about thursday?
<siretart> sistpoty: I have an excercise from 1200 to 1400, so before or after that would be great
<sistpoty> siretart: 14.00h at the cafeteria?
<siretart> sistpoty: I will be there! :)
<sistpoty> ok :)
<Kyral> someone want to reviw this for me?
<Kyral> http://revu.tauware.de/details.py?upid=1522
<ajmitch> ugly debian/rules, full of dh_make junk
<ajmitch> +	# Add here commands to install the package into debian/gtkedit.
<ajmitch> +
<ajmitch> where does it do make install?
<Kyral> okay okay
<Kyral> I call dh_install :P
* Kyral points to the build
<Kyral> I wasn't sure if I should call dh_install there
<Kyral> or leave it
<ajmitch> evil & ugly
<ajmitch> why do you have usr/sbin in debian/dirs?
<Kyral> because I forgot to take it out
<ajmitch> you have a gtkedit.menu file, no gtkedit.desktop
<Kyral> yah yah yah okay I get it
<ajmitch> ok, I'll stop reviewing then
<Kyral> Clean DH junk out
<Kyral> make .desktop file
<Kyral> I wasn't sure if I should leave dh_install where it is or call it up there
<Kyral> mitch?
<Kyral> I'll write the desktop after dinner...
<crimsun> ugh. 1h 56m
<crimsun> next meeting!
<ajmitch> yay
* ajmitch bails on meetings
<ajmitch> hi \sh
<ajmitch> your topic was deferred
<\sh> one hour late...is the meeting still going on?
<\sh> ajmitch: ah ok
<sistpoty> \sh: meeting just ended
<sistpoty> and /me is now off to bed... gn8 everyone
<ajmitch> night
<\sh> cu sistpoty
<siretart> same here, gn8 folks
<ajmitch> night siretart
<\sh> I'll patch kmail, so that the reply button is not available anymore
<marcin`> hello MOTU's
<marcin`> got two questions...
<lifeless> hola
<hub> hola
<marcin`> 1. are there any plans to 'ubuntuize' maintainer scripts - and for example change "This package was debianized by ..." in copyright file and other stuff like this?
<hub> I'm not sure that make sense
<crimsun> marcin`: issue deferred until Debian makes a decision
<marcin`> 2. how could I build dapper packages on hoary?
<hub> as package are still .deb
<hub> marcin`: pbbuilder
<hub> marcin`: wiki has instructions on pbuilder
<hub> it is a chrooted build environnement
<marcin`> ok got it - thanks
<raphink> very helpful :)
<raphink> dchroot is great, too
<raphink> esp. to test these packages
<raphink> marcin`: once you build your packages for dapper, you can test them in a dapper env. with dchroot
<raphink> see DebootstrapHowTo iirc
<Riddell> what's frozen on thursday for universe?
<crimsun> just any newer versions of already existing packages in the repo
<crimsun> any new packages [not in the repo]  are still game until Feature Freeze, and any newer packaging revisions of already existing packages in the repo are game, too
<crimsun> (and of course there's UVF exception)
* Kyral goes to write a Desktop file for GTKEdit
<LaserJock> anybody having any memory leak problems with the lates dapper kernel?
<Kyral> Where do .desktop files install to anyway?
<LaserJock> /usr/share/applications/
<Kyral> so in gtkedit.install put debian/gtkedit.desktop /usr/share/applications/
<LaserJock> I think dh_desktop takes care of it
<Kyral> not according to the manpage
<LaserJock> oh, yeah. I was wrong. My upstream Makefile already installed the .desktop
<Kyral> heheh
<LaserJock> but dh_desktop is still good to use
<Kyral> I know
<Kyral> the upstream Makefile for GTKEdit is like 4 lines ;P
<LaserJock> I bet
<Kyral> yah and no Icon
<Kyral> and I don't feel like making one lol
<Kyral> can I just use the icon for mime/text?
<Kyral> actually how would I do that....
#ubuntu-motu 2007-01-15
<tsmithe> bddebian, about my lintian error on alsa-firmware, it is indeed to be expected
<tsmithe> and thanks for the revu
<tsmithe> :)
<tsmithe> and as i said about the man pages on alsa-tools; i don't think that's valid either
<tsmithe> i'll look into the script
<tsmithe> but i don't recall modifying it - so it should be identical to the current feisty version
<bddebian> Could be
<tsmithe> thing is - it's autogenerated...
<persia> Adri2000: I was away.  Now filing bugs on gaphor, flpsed.
<TerminX> hm, is this channel where I would mention a bug in a package in universe?
<shawarma> TerminX: Kind of. You really should file it on launchpad..
<fowlduck> launchpad mcQuack
<TerminX> I searched for the package on launchpad and didn't find it, and it's only a dependency problem anyway
<shawarma> TerminX: That said, if you need some sort of clarification, then yes, this is it.
<shawarma> TerminX: Which package is it?
<TerminX> package slidentd seems to depend on specific inetd packages, which means I can't use it with xinetd
<TerminX> they look to be added dependencies that the original debian package doesn't have (in other words, the debian package works with no issues)
<shawarma> I suppose the most corretct fix would be to make xinetd provide inet-superserver.
<TerminX> should I file a bug against xinetd on launchpad then?
<shawarma> Right.
<shawarma> It's in main, so we can't really help you directly.
<TerminX> it, uh, won't let me file a bug on xinetd
<shawarma> TerminX: How so?
<TerminX> it tells me to use its official bug tracker, but that isn't exactly going to be useful when it's something that just needs to be corrected in the package
<shawarma> TerminX: Ah.
<shawarma> TerminX: The thing to remember is that launchpad is not only for Ubuntu.
<shawarma> TerminX: And since this is a ubuntu specific issue, you need to go to the frontpage and select Ubuntu.
<shawarma> TerminX: ...and *then* find xinetd and file a bug on it.
<shawarma> TerminX: Makes sense?
<TerminX> heh, oops
<shawarma> TerminX: https://launchpad.net/ubuntu/+source/xinetd/+filebug
<LaserJock> sweet, bugmail!
<bddebian> LaserJock: ??
<ajmitch> lies
<ajmitch> we have no bugs
<bddebian> heh
<bddebian> ajmitch: You finally fixed them all? :)
<somerville32> ajmitch, Only 2 open bug reports over last week ;] 
<ajmitch> bddebian: no, that's up to you
* ajmitch is no developer
<bddebian> Bah, I can't fix nuttin' :-(
<Burgundavia> hey ajmitch, somerville32, bddebian
<ajmitch> hello Burgundavia 
<bddebian> Hi Burgundavia
<ajmitch> how's it going?
<somerville32> Hiya Burgundavia 
<Burgundavia> not bad
<Burgundavia> "enjoying" alberta
<Burgundavia> is bloody cold here
<ajmitch> exciting
<LaserJock> bddebian: I subscribed to ubuntu-universe-sponsors list
<LaserJock> I was trying to the other night but it didn't work
<LaserJock> but now I got it
<bddebian> Ahh
<bddebian> How did someone get a foo.tar.gz to upload to REVU?
<LaserJock> bddebian: how far did you get through the science bug list?
<bddebian> All the way, though I didn't get many fixed yet :'-(
* ajmitch hasn't fixed a bug or uploaded a package for weeks
* ajmitch is so slack
<LaserJock> bddebian: rockin' dude, thanks
<LaserJock> ajmitch: I thought I saw some zope stuff float by, was that Klose or you?
<ajmitch> old sync requests
<ajmitch> really old :)
<ajmitch> or maybe not
* ajmitch shrugs
<ajmitch> doesn't look like it was me that requested those, so that's ok
<ScottK> Laserjock: are you available for REVU?
* ajmitch can retire in peace
<somerville32> ScottK: Which package?
<ScottK> I have http://revu.tauware.de/details.py?upid=4070 and http://revu.tauware.de/details.py?upid=4071 that are looking for a 2nd sponsor.
<ScottK> somerville32: I think you've looked at these already.
<ScottK> I know you looked at 4070, not sure about 4071.
<crimsun> persia: beware of subscribing u-a prior w/o an ACK
<persia> crimsun: Ah.  That's an error in my understanding.  I'll avoid that in future.  Thanks for the note.
<crimsun> persia: were you following a wiki page?
<persia> crimsun: My memory, but I'll check the wiki page I loaded from in a couple minutes.
<bddebian> do be do be doo
<ScottK> crimsun: Would you be up for a little REVU?
<ScottK> http://revu.tauware.de/details.py?upid=4070 and http://revu.tauware.de/details.py?upid=4071 that are looking for a 2nd sponsor
<persia> crimsun: The procedure is described in https://wiki.ubuntu.com/DeveloperResources.  I started adding u-u-s as well after Tollef advised me about ACKs for bug 78751.
<Ubugtu> Malone bug 78751 in survex "Please sync survex 1.0.39.1-1 from Debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78751
<LaserJock> crimsun: we should have MOTU page outlining procedures for that, IMO
<LaserJock> what "procedures" or "processes" do we need a writeup on?
<crimsun> probably the material I'd cover in a -school session
<LaserJock> mhm
<crimsun> how to request a sync
<crimsun> how to request processing of a merge
<LaserJock> do you want something written up beforehad?
<persia> LaserJock: For a list, I'd start from https://wiki.ubuntu.com/MOTU/School/.  Some of these age, and the procedures are not necessarily entirely clear (even from the Q&A logs).
<LaserJock> sync, merge, SRU, UVF, new package
<persia> LaserJock: non-MOTU bugfix updates
<LaserJock> k
<crimsun> persia: bug 79349 will depwait on the new uqm being synced (which means it needs an accompanying sync request)
<Ubugtu> Malone bug 79349 in uqm-content "Please sync uqm-content 0.6.0.1 (multiverse) frrom Debian sid (non-free)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79349
<persia> crimsun: See bug 79350
<crimsun> (yes, it's ok to override Ubuntu changes for uqm)
<Ubugtu> Malone bug 79350 in uqm "merge uqm 0.6.1-2 from Debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79350
<persia> crimsun: uqm FTBFS on feisty.  I'll let Joey know as soon as I can replicate in a sid environment.
<crimsun> why does it ftbfs?
<persia> crimsun: libmikmod2-dev is not in B-D
<crimsun> yes it is
<crimsun> http://ftp.debian.org/debian/pool/contrib/u/uqm/uqm_0.6.1-2.dsc
<crimsun> it's the last b-d
<crimsun> I'm speaking specifically of the sync ; I saw the merge request
<crimsun> a merge is unnecessary; a sync is sufficient
<persia> crimsun: It wasn't locally for some reason.  I'm off to reject 79750 :)
<crimsun> persia: you pbuilt uqm from sid and it ftbfs?
<persia> crimsun: Yes, but I appear to have made a mistake.  Retrying...
<LaserJock> crimsun: do you want policy wiki docs worked on before or after your session?
<ajmitch> ooh, crimsun is doing a session?
<LaserJock> as soon as he gives me a date/time ;-)
<crimsun> LaserJock: I see no reason for work to block on the session
<LaserJock> crimsun: k, I might make some stubs tonight
<crimsun> great
<LaserJock> once we get those nailed down  little bit I'd like to put those in the packaging guide
<persia> crimsun: Thanks for the check: It was my mistake.  I'm not sure how the B-D line was damaged.  merge bug killed, raising sync bug.
<bddebian> Gah, compiz has too big of build-deps..
<Lutin> hi there
<bddebian> Heya Lutin
<LaserJock> has anybody be using Daniel's bughelper script?
<Lutin> not yet
<Lutin> LaserJock: btw, could you have a look at kayali on revu when you'll have some time ?
<crimsun> geser rocked gnome 396477
<Ubugtu> Gnome bug 396477 in linux "stack overflow in sysdeps/linux/procmap.c: glibtop_get_proc_map_s()" [Major,Resolved: fixed]  http://bugzilla.gnome.org/show_bug.cgi?id=396477
<bddebian> Whew, I think I finally have a comment on every package on REVU that I can comment on..
<ajmitch> well done
<bddebian> Well my reviews are shit apparently but I'm trying :)
<ajmitch> better than mine
<bddebian> ajmitch: Only when you don't do them :)
<ajmitch> exactly
* ajmitch cannot hope to compare, so doesn't bother
<bddebian> Bah
<unix_infidel> will LTS ever have a zimbra packaged for the repos?
<Burgundavia> no
<joejaxx> hello Burgundavia 
<unix_infidel> http://www.zimbra.com/index.html
<Burgundavia> hey joejaxx
<Burgundavia> unix_infidel: yep, aware what zimbra is. Unless it gets backported, no
<unix_infidel> Burgundavia: is it expected for the next LTS?
<unix_infidel> fawn iirc
<Burgundavia> if somebody packages it
<Burgundavia> and 7.04 will not be an LTS
<bddebian> Backport a NEW package?  Is that ever done?
<Burgundavia> yes
<bddebian> Sounds dangerous to me :)
<joejaxx> bddebian: :)
<Burgundavia> the world is dangerous
<Burgundavia> leaf apps have little bearing on the general order of the world
<bddebian> leaf apps?
<Burgundavia> apps which have nothing depending on them
<bddebian> Ahh
<bddebian> Ah well, gnight gang
<Ash-Fox> I have a announcement, pbuilder rocks! -- that is all.
<Lutin> heya freeflying
<LaserJock> I don't suppose anybody in here is good with w3m?
<nixternal> can't say that i am
<nixternal> but i did just build a new kubuntu-docs package from the ground up (and it is 99% functional at this time)
<nixternal> i am hoping it will generate the bug reports now before final release, unlike the edgy release
<Hobbsee> LaserJock: lynx is easier, why?
<nixternal> Hobbsee: i think i tried to tell him that the other day :)
<LaserJock> whatever
<LaserJock> I just want the best CLI browser
<LaserJock> I was using w3m but I couldn't select text that was a URL
<lupine_85> links2 ?
<Hobbsee> LaserJock: links2 is good
<Hobbsee> so's elinks
<Hobbsee> w3m is difficult
<Hobbsee> anyway, try the right arrow, over the link
<LaserJock> hmm, lynx lets me select the text
<LaserJock> links2 doesn't
<persia> LaserJock: w3m -no-mouse let's you select text, but you can't click links.
<LaserJock> ah
<LaserJock> Hobbsee: what's your favorite CLI browser? lynx?
<LaserJock> persia: how about you?
<lupine_85> links2 does javascript, which I need for some sites
<Hobbsee> LaserJock: lynx, mostly
<Hobbsee> LaserJock: ask TheMuso 
<crimsun> yuck dude, just use nc.
<lupine_85> like my router's config page =)
<persia> LaserJock: I forget why I stopped using lynx, but I've mostly migrated from w3m to GUI browsers :(
<LaserJock> crimsun: nc?
<lupine_85> netcat?
<crimsun> yep
<nixternal> heh
<nixternal> only the hardcore crimsun ;p
<crimsun> nah, that's bddebian. He thinks, and It Is.
* lupine_85 is so hardcore he uses netcat for remotely upgrading his firewall
<LaserJock> crimsun: hmm, that's a little too minimal for me I think
<lupine_85> not recommended over the wider internet though ;)
<LaserJock> I'm just tired of using GUI browsers for LP/Debian
<nixternal> haha, LaserJock needs something more hardcore
<crimsun> links2 was pretty nice when I used it
<LaserJock> crimsun: what do you usually use, FF?
<crimsun> w3m and FF
<crimsun> I don't have administrative access on most of the Ubuntu machines here
<LaserJock> bummer
<LaserJock> hmm, I don't use many machines that I don't have admin access to
<crimsun> nah, saves me headaches. Then I can just whine at the admin.
<LaserJock> yeah, that's what I was just thinking
<LaserJock> I should make one of the new grad students admin ;-)
<crimsun> we pretty much converted an entire engineering college to use nexenta and ubuntu
<LaserJock> sweet
<LaserJock> my school seems very anti-linux
* lupine_85 lurves konqueror
<Hobbsee> hey deitys?
<Hobbsee> one of you figure out how to work the home phone here please...
<LaserJock> wow, links2 in graphical mode is pretty sweet
<LaserJock> crimsun: did you take care of the icewm merge request on u-u-s?
<crimsun> LaserJock: no
<LaserJock> crimsun: ok, I've got it
<crimsun> LaserJock: there was a period yesterday where I was unsubbed from u-u-s and awaiting moderator approval for resub during which I didn't receive any 
<Hobbsee> crimsun: really?
<LaserJock> crimsun: ok, I wondered
<LaserJock> crimsun: well, according to times I got them before I got my sub confirmation
<LaserJock> maybe I stole them from you ;-)
<crimsun> Hobbsee: yes, due to the receiving doubles of every post
<crimsun> so I unsubbed and resubbed to take care of that
<Hobbsee> crimsun: ahh
<Hobbsee> crimsun: has that stopped?
<crimsun> yes, it's fine now
<Hobbsee> cool :
<Hobbsee> )
<LaserJock> uh oh, dholbach's on
<dholbach> good morning
<LaserJock> that's my cue to go to bed ;-)
<dholbach> hey LaserJock
<LaserJock> hi dholbach 
<TheMuso> Hobbsee: What did Laser_away want?
<Hobbsee> TheMuso: to know what the best cli browser was
<TheMuso> Laser_away: Whenever you return, elinks is the best atm.
<Hobbsee> TheMuso: did you go to lowenbrau last night?  i didnt see you there...
<TheMuso> Hobbsee: No.
<Hobbsee> TheMuso: :(
<TheMuso> Hobbsee: Mainly not knowing the public transport system in that area, and not wanting to get stuck out somewhere that I didn't know.
<Hobbsee> TheMuso: :(
<Hobbsee> TheMuso: there were plenty of us around, we could have found you
<TheMuso> Hobbsee: Ah well.
<TheMuso> I will be seeing people all of this week anyway.
<Hobbsee> TheMuso: :)
<TheMuso> Hobbsee: You coming on Thursday
<Hobbsee> TheMuso: yes
<Hobbsee> TheMuso: have you seen elky today?
<TheMuso> Hobbsee: Not yet. I know she was around, but didn't get a chance to meet her.
<Hobbsee> TheMuso: right.  guess it's a bit silly asking you to look for her, and ask if she's got those cd's yet...
<Hobbsee> TheMuso: you're all otu of sessions nwo?
<TheMuso> Hobbsee: Yeah. I'm actually at home
<Hobbsee> ah!  so it's silly on two counts then!
<StevenK> Hobbsee: She does. I know this because I handed them to her about an hour ago.
<Hobbsee> StevenK: cool :)
* StevenK went from Burwood to Kensignton, then to Ashfield and then home.
<Hobbsee> fun
<StevenK> Nuh uh
<Ash-Fox> Would anyone happen to know or have any idea why apt-build is behaving strangely with my packages/repository -- It refuses to download the sources? http://ash-fox.theden.ws/temp/apt-build-weirdness.txt
<\sh> moins
<Ash-Fox> Morning
<Ash-Fox> Gah, the package builds perfectly if I apt-get source and pbuilder/debuild/dpkg-buildpackage -rfakeroot it... And apt-build won't even download it.
<Adri2000> persia: file a bug in debian for linpopup's .desktop file? ;)
<persia> Adri2000: Hey!  I just uploaded the diff.  I need a couple minutes to file a debian bug as well :)
<persia> Adri2000: 
<Adri2000> eheh, ok :p
<persia> Adri2000: I hope don't mind about bitpim: I had just been looking at it before I fell asleep, and was certain that a sync wouldn't work.
<Adri2000> persia: and you are still certain?
<persia> Adri2000: Yes.  debian/control in the sid source sets a binary dependency on python-ctypes, which is no longer a separate package for python2.5.
<crimsun> (because python 2.5 includes ctypes internally)
<Adri2000> ok, then no problem, I don't mind :)
<persia> I'm sure it seemed like a good idea to process .desktop files for the gnome file manager, but it's confusing when you actually want to select the .desktop file instead of the target :(
<TheMuso> c
<Hobbsee> ALL.  FLASH.  SUCKS.  AND.  WEBSITES. USING. IT. DESERVE. TO. DIE!!!
<Hobbsee> gah!
<white> Hobbsee: doesn't gnash work?
<Hobbsee> white: mplayer plugin works, i got to where i wanted.  just it wont actually let you enter the site without flash 8
<white> bah
<persia> Hobbsee: That's evil website designers, not evil flash.  Kill the guilty, leave the innocent to offend later.
<Hobbsee> persia: flash.  is.  not.  innocent.
<Hobbsee> persia: linux version is still at 7.*
<Hobbsee> persia: well, it is sony.  they're a known evil
<persia> Hobbsee: OK.  There are several evils.
<Nafallo> !info cfv
<ubotu> cfv: versatile file checksum creator and verifier. In component universe, is optional. Version 1.18.1-0ubuntu1 (edgy), package size 36 kB, installed size 172 kB
<crimsun> oh christ
<crimsun> yay for uploading without adding to debian/patches/series
<ajmitch> I've done worse
<crimsun> well, I know 11-xv_lockup.patch's not a regression at least
* crimsun steps through the debuild-test procedure with 13-i915_bios_fails_on_xserver_restart.patch
<crimsun> siretart: +0.7, eh? :)
<StevenK> Oh no, not decimal SRU votes
<StevenK> Don't make me vote +1.3 :-P
<xzu> Hi folks, i have  question: there is a small bug in a package I use. The package does not have an official Ubuntu maintainer, but the Debian package has. Now the same issue occurs in Debian testing/unstable. The fix just a very simple dependency issue, but what is the "correct" soluction? Contact Debian maintainer, wait untill she fixes it and import that or try to get it fixed in Ubunty Edgy/other releases ?
<crimsun> which package?
<xzu> https://launchpad.net/ubuntu/+source/libpam-ssh
<crimsun> ok, so there's no existing Ubuntu delta. In that case, it's probably preferable to push the fix directly to Debian, and then Ubuntu will sync from Sid.
<crimsun> now depending how "small" this bug is...
<xzu> what does "existing Ubuntu delta" mean?
<xzu> ok, its in Debians bugtracker, so I guess the maintainer will pick it up
<crimsun> the current source version is 1.91.0-9.1, which is a direct sync from Debian
<xzu> check
<siretart> crimsun: yay! (well, count that as +1)
<persia> I'm working on libjsw.  I would like to make a single upload of a new upstream version with packaging changes to close all open Ubuntu bugs and an additional Debian bug.  How should I upload the new package?
<Hobbsee> persia: uh...REVU...bug with the debdiff of debian/* would be good
<Hobbsee> persia: seeing as just a debdiff would suck.  and so would just REVU.  although that would suck less.  just.  
<persia> Hobbsee: Thanks.  Now I have yet more motivation to fix GPG.  I don't suppose you know how I hunt down and kill old keys floating around on the keyservers?
<Hobbsee> persia: do you have the revocations for them?
<Hobbsee> ie, the rev... certificates?
<Hobbsee> to do with revoking
<persia> Hobbsee: If I spend a day or so, I might be able to find the disks on which the secrets lie (they are very old).
<Hobbsee> ah
<Hobbsee> persia: dunno if you can just ignore them....
<Hobbsee> you'd have to use your private key to revoke
<Hobbsee> there's no other way to prove that you are the owner of that key, without hte private one
<Hobbsee> however, people will tend to use the key on LP
<persia> Hobbsee: That's my fear as well - duplicates lead to confusion.  Perhaps I'll raise a bug on libjsw saying "don't fix this", and go hunt through my old disks.
<Hobbsee> persia: well, they'll use the signed one...and the one that's being used, and the one you're signing mail with
<persia> Hobbsee: You're suggesting just to ignore the old one for purposes of REVU & LP?
<Hobbsee> persia: for the moment, yeah...
<persia> Hobbsee: Well, if that's acceptable to Ubuntu, I'm happy.  I can procrastinate for even longer :)
<Hobbsee> persia: heh
<Hobbsee> persia: it's better to get rid of them - and generate a revoking certificate for this key, if you ever have to use it
<Lutin> heya freeflying :)
<persia> Hobbsee: Yep.  With new disk sizes, I become more and more likely to clean up my stack of <10GB disks, and will surely find the keys in the process.
<Hobbsee> persia: cool
<freeflying> Lutin: hi
<Lutin> how are you ?
<persia> Processes are fun!  Could a REVU admin please sync my key to the REVU keyring?
<Hobbsee> siretart: ^ 
<Whoopie_> crimsun: hi, is the acroread package in feisty intended for a security update in edgy? any plans?
<siretart> sec
<persia> siretart: No hurry.  libjsw still needs a couple hours work.
<siretart> persia: done
<persia> siretart: Thanks.
<\sh> re
<_Enchained> Hi everybody
<\sh> http://cgi.ebay.com/Windows-XP-Home-Edition-License-Key_W0QQitemZ150080733165QQihZ005QQcategoryZ41887
<Lutin> lol
<_Enchained> Hi bddebian :)
<bddebian> Heya gang
<bddebian> Hi _Enchained
<\sh> hey bddebian
<_Enchained> bddebian: dvd95 is updated on revu ;)
<bddebian> Hi \sh
<bddebian> _Enchained: OK
<_Enchained> and waiting for you loll
<_Enchained> I've added a manpage and corrected some little things
<proppy> hi
<proppy> pygame broken in edgy ?
<proppy> for python2.5
* proppy hugs dholbach
<dholbach> heya proppy
* dholbach hugs proppy back :)
<Lutin> hay bddebian :)
<Lutin> bddebian: sorry, I updated kayali again, could you have a look at it ?
<proppy> will check against the source package, cause it only install in python2.4/site-packages, but not in python2.5
<bddebian> Lutin: Yeah, probably in a bit
<Lutin> ok bddebian, thanks :)
* bddebian wonders how he became the REVU "guy" :-)
<persia> bddebian: You're responsive :)
<proppy> XS-Python-Version: 2.4 in pygame
<proppy> a not >= 2.4
<Lutin> bddebian: cause you do a grat job on revu :-)
<Lutin> great*
<bddebian> Lutin: Not hardly, but thanks
<persia> proppy: File a bug, being sure to mark is as an 6.10 bug.  It's fixed in Debian and Feisty.
<proppy> persia: i just checked again the file list of packages.ubuntu.com for feisty
<proppy> persia: it's seems to have the same pb
<proppy> persia: but i must double check on a real feisty
<proppy> persia: are you sure this a edgy only issue ?
<persia> proppy: Yes.
<proppy> persia: +XS-Python-Version: >= 2.3
<proppy> persia: yep its corrected in current unstable
<proppy> persia: thanks
<proppy> persia: https://bugs.launchpad.net/ubuntu/+source/pygame/+bug/79409
<Ubugtu> Malone bug 79409 in pygame "[6.10 only]  pygame doesn't install in python2.5 on edgy" [Undecided,Unconfirmed]  
<crimsun> Whoopie_: 7.04 no longer contains acroread
<crimsun> Whoopie_: in light of its removal (both source and binary), it's questionable whether any effort should be expended on a security update
<Whoopie_> crimsun: looking at bug 78339, you updated it. But why did you remove it?
<Ubugtu> Malone bug 78339 in acroread "Universal XSS" [High,Confirmed]  https://launchpad.net/bugs/78339
<crimsun> Whoopie_: the issue is of course that we are not, according to the EULA, allowed to redistribute it without an agreement with Adobe.
<crimsun> Whoopie_: no, the issue is covered in bug 43780
<Ubugtu> Malone bug 43780 in acroread "Acroread: Redistribution may not be allowed" [Low,Fix released]  https://launchpad.net/bugs/43780
<Whoopie_> crimsun: ok, so you fixed both. ;)
<crimsun> Whoopie_: I am solely responsible for the update. The removal from the archive is not my decision.
<crimsun> Nor am I an archive admin.
<Whoopie_> np at all. I have a problem with password protected pdfs with evince. so acroread was the workaround.
<Whoopie_> but as you shiped it with edgy, a security update would be wise.
<asabil> hi all
<asabil> how can I request a software to be added to feisty ?
<geser> asabil: see https://wiki.ubuntu.com/MOTU/Packages/Candidates
<asabil> unfortunately the last time I submitted something there it just remained there :/
<geser> asabil: the other solution is to create the package yourself and get it on revu reviewed
<asabil> okey thanks
<ScottK> Is there another REVU sprint planned for Feisty?  The last one got me started here and I think another would be of benifit.
<Lutin> ScottK: maybe it's a bit late now, uvf in on feb. 8th iirc
<ScottK> I know.
<ScottK> I've got two packages with one sponsor right now and another that's waiting for one of those before it can be REVUed.
<ScottK> I'm starting to wonder if I'm doing to get stuff in by then...
<ScottK> I was sort of hoping for another push before Feb 8.
<crimsun> which upids?
<ScottK> http://revu.tauware.de/details.py?upid=4070 and http://revu.tauware.de/details.py?upid=4071
<ScottK> crimsun: Real life called me AFK for a few minutes.
<crimsun> ok, I'll look now
<crimsun> (sorry, phone conf)
<ScottK> Understand and thanks.
<crimsun> ScottK: for postfix-policyd-spf-perl, it'd be a good idea to include the preamble for GPL2 in debian/copyright. Otherwise it looks good.
<ScottK> Hmm, I tried to follow the example in the new maintainer's guide as closely as I could: http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html#s-copyright - Is this a case where the documentation needs to be updated?
<palski> hmmm gtetrinet is now in edgy-proposed but not for i386
<crimsun> palski: it hasn't built yet. [https://launchpad.net/+builds/+build/292817 ] 
<crimsun> as noted in the builds status box on [https://launchpad.net/ubuntu/+source/gtetrinet/0.7.10-1ubuntu0.1 ] 
<crimsun> (left side)
<palski> ok, thanks
<bddebian> Someone please kill me :-(
<crimsun> ScottK: it's preferable (as I noted above) to include it. It wouldn't be strictly rejectable by omitting it.
<crimsun> bddebian: 12:33 [freenode]  -!- This command is for network staff only
<ScottK> OK. Thanks.  I'll add it when I update my packages.
<ScottK> Is the license summary an issue just for GPL or for other licenses too (e.g. Perl Artistic license)?
<bddebian> crimsun: I meant that literally :)
<crimsun> it's not an issue; it's just viewed as good citizenship
<ScottK> OK.  Thanks.
<crimsun> bddebian: your daughters wouldn't appreciate that
<ScottK> Neither would we.
<ScottK> bddebian:  ^^^^
<crimsun> we can't have 1/4 of our trinity running off
<crimsun> 1/3, even
<crimsun> ScottK: shall I wait on 4071, then?
<ScottK> I'd appreciate a look as I had to rebuild orig.tar.gz for that one and am not as confident that the packaging is correct.
<ScottK> So for 4070 if I add the GPL preamble, you'd advocate?
* ScottK boots up the laptop with all the files on it...
<crimsun> ScottK: yes
<ScottK> OK.  Working on it now.
<crimsun> ScottK: for libnet-dns-resolver-programmable-perl, you have a debian/README.Debian-source, but it's not installed via debhelper files or via debian/rules
<crimsun> ScottK: as far as the rerolling of the source package is concerned, it's fine otherwise
<ScottK> OK.  Thanks.
<ScottK> The revision to 4070 is uploaded, but I don't have the new ID yet.  crimsum and bddebian I would really appreciate it if you would advocate/re-advocate.
<ScottK> Real life is calling somewhate urgently or I'd stay and give you the new ID.
<ScottK> Thanks again.
<Adri2000> hey crimsun! I have some merges/sync requests waiting on malone, I don't know if you have seen them :p
<crimsun> Adri2000: I've been in a phone conf most of the morning
<crimsun> (so no, I have not)
<luisbg> Laser_away, ping
<Adri2000> crimsun: ok, you can see them at +reportedbugs :)
<crimsun> that "sound" highlight is driving me batty
<jamesbrose> Hello
<jamesbrose> How would I add my own ubuntu deb to apt-mirror?
<pianoboy3333> What are provides?
<imbrandon> jamesbrose, just one deb ?
<jamesbrose> Yes
<LaserJock> luisbg: pong
<imbrandon> jamesbrose, it wasent made to just add / remove one deb, you would have to make a repo just for that one deb then mirror it
<imbrandon> heya LaserJock 
<ajmitch> morning
<Lutin> 'morning ajmitch
<LaserJock> hi imbrandon and ajmitch 
<ajmitch> imbrandon is here, a rare sight these days
<imbrandon> hehe ajmitch yea i lurk alot more
<ajmitch> almost as much as I do
<imbrandon> i'm actualy here alot durring work i just read backscrolls
<imbrandon> hehe
* ajmitch too
<imbrandon> but today ( and the next two ) are mine off
<imbrandon> :)
<ajmitch> ah
<ajmitch> I don't have that luck
<imbrandon> mon tue wed seem to be my "normal" days off now
<imbrandon> leaste this month
<ajmitch> ugh
<ajmitch> I prefer having a normal week, and having weekends
<ajmitch> since my friends tend to have weekends off as well :)
<imbrandon> me too, but i'm still training some new people for the weekends
<imbrandon> sooo
<ajmitch> ah
<ajmitch> yes, I do actually have friends outside of irc ;)
<imbrandon> hahah ;)
<LaserJock> ajmitch: really?!?
<LaserJock> I don't
<imbrandon> i met this nice little gurl the other night, took some ubuntu time from me ( not that i was complaining though )
<ajmitch> LaserJock: yeah, we had a great night last night at a friend's place :)
<fernando> "outside of irc" this makes no sense to me
<ajmitch> imbrandon: heh
<imbrandon> fact i'm supose to call her today sometime .......... hum
<pianoboy3333> What are provides in relation to a package/packaging system?
<ajmitch> pianoboy3333: virtual packages
<ajmitch> eg apache2 can provide httpd
<LaserJock> pianoboy3333: there's also some good info in the Debian Policy
<ajmitch> exim & postfix can provide mail-transport-agent
<pianoboy3333> ajmitch: but what does that mean if apache2 provides httpd, isn't httpd already another package?
<imbrandon> or X for xfree86 and xorg 
<pianoboy3333> Is it just explaining what's in the package?
<ajmitch> imbrandon: a little harder, they're too many packages now
<ajmitch> pianoboy3333: it's for dependencies
<imbrandon> ajmitch, true
<ajmitch> so you can have something depend on apache2 | httpd
<pianoboy3333> I see...
<ajmitch> if you have another webserver installed, the package will use that
<ajmitch> otherwise it goes with what the package maintainer suggests
<imbrandon> or soemthing depend on a mta but dosent care if its postfix or exim
<pianoboy3333> so it's like
<pianoboy3333> package X also contains what's in package Y, so if something depends on package Y, it could depend on package Y, or X
<ajmitch> pretty much
<ajmitch> equivalent functionality
<imbrandon> mostly yes
<pianoboy3333> ok
<imbrandon> hum food
<ajmitch> mmmm, food
* ajmitch would like to have some breakfast
<imbrandon> noodles sounds good right now
<ajmitch> heh
* imbrandon nukes some
<ajmitch> noodles & mt dew
<ajmitch> what a mix
<imbrandon> hehe
<imbrandon> i finaly got CS:SOURCE to install under kubuntu too
<imbrandon> w00t
<LaserJock> I haven't tried Ramen+Dew, it could be interesting
<imbrandon> ;)
<ajmitch> classic student food
<LaserJock> I know a guy who always ate his cereal with Dew instead of milk
<ajmitch> sick
<LaserJock> yeah, that's what I thought
<LaserJock> but he was in the army
<imbrandon> fruity pebbles and dew is nice
<LaserJock> and apparently that was a good way to get food fast
<LaserJock> plus some caffeine
<imbrandon> heh
<imbrandon> hum
<imbrandon> i'm trying to install debian via plip,very annoying
<ajmitch> how slow is it?
<imbrandon> very , special since its on a p133
<ajmitch> ouch
<imbrandon> with 16mb ram
<imbrandon> i just want to run a c64 emu on it
<imbrandon> hehe
<ajmitch> it'll probably be too slow for that :)
<imbrandon> this old lappy with no cdrom or nic
<ajmitch> no floppy drive either?
<imbrandon> so plip or 100000 floppys was the only choice
<ajmitch> nah
<ajmitch> I've done a floppy-only install
<imbrandon> how many floppys ?
<imbrandon> with no nic ?
<ajmitch> though that was in the days of potato or earlier
<ajmitch> ah, it had a nic, so we just got the bare installer on 
<imbrandon> yea
<ajmitch> with a stack of floppies
<imbrandon> see i booted from a floppy and started the plip install
<ajmitch> about 3 that we constantly recycled :)
<imbrandon> haha yea
<imbrandon> i had to find a floppy drive
<imbrandon> i dident have one in any of my computers
<ScottK> bddebian and crimsun: The revised postfix-policyd-spf-perl is at http://revu.tauware.de/details.py?upid=4078 - I'd appreciate it if you would look at it/advocate again.  
<zul> hey ajmitch 
<ajmitch> hello
<bddebian> ScottK: I'm trying, I'm just buried at work atm :-(
<LaserJock> hi zul 
<ScottK> Understand.  I really appreciate your persistence on helping me.  The only change is to add the GPL preamble that crimsun suggested.
<Adri2000> bddebian: are you going to merge gwget2?
<bddebian> Adri2000: Go ahead and try it :)
<Adri2000> I already *tried* :)
<tsmithe> bddebian, could you advocate alsa-firmware? :P
<bddebian> tsmithe: Did you fix it? :)
<tsmithe> well
<tsmithe> which?
<bddebian> All of them ;-P
<tsmithe> huh?? /me confuzzled
<Adri2000> LaserJock: in http://tiber.tauware.de/~laserjock/motutodo/universe.html wouldn't it be possible to have a link to the last debian changelog?
<ScottK> bddebian: While tsmithe is confused, http://revu.tauware.de/details.py?upid=4079 is updated to resolve crimsun's comments in addition to http://revu.tauware.de/details.py?upid=4078 that I mentioned earlier...
<Nafallo> bddebian: vare to look at wave-look @ REVU?
<bddebian> tsmithe: I want to talk to crimsun about it since it's alsa and firmware packages aren't my specialty
<tsmithe> oh ok
* bddebian really has no specialty :_(
<tsmithe> awh
<tsmithe> bddebian, i dunno how to fix the alsa-tools script problem, and i don't know how to do man pages for apps i don't know what they do, and am only updating to fix an issue with the new alsa-firmware
<tsmithe> plus
<ScottK> Nafallo: http://revu.tauware.de/details.py?upid=3570
<tsmithe> the lintian errors on alsa-firmware *are* to de expected
<geser> Adri2000: isn't the link to the PTS enough?
<Nafallo> ScottK: indeed :-)
<bddebian> I've never heard of an "expected" lintian error :)
<tsmithe> bddebian, well they are firmware
<tsmithe> *s
<tsmithe> so they are to expect that error
<ScottK> tsmithe: If they are expected, you might want to create over-rides for them and document why.  Then it'll be clearer to people what's going on. http://lintian.debian.org/manual/ch2.html#s2.4
<tsmithe> hmm
<tsmithe> ok
<tsmithe> thanks
<LaserJock> Adri2000: it's possible, I just don't want to crowd it too much
<Nafallo> hmm
<Nafallo> that LDAP thing in the Ubuntu Classroom? when was that again?
<tsmithe> open week?
<LaserJock> Nafallo: ask imbrandon 
<Nafallo> imbrandon: at LDAP thing in the Ubuntu Classroom? when was that again?
<Nafallo> :-)
<LaserJock> hmm, any schroot users around?
<Adri2000> LaserJock: it'd be useful to see if changes in debian are enough important to request a sync
<geser> I use it for preparing uploads
<LaserJock> Adri2000: yes, but you can also get that from the PTS link
<LaserJock> Adri2000: just with a few more clicks
<LaserJock> geser: do you have a feisty one?
<LaserJock> I assume so
<geser> LaserJock: yes
<Adri2000> LaserJock: ok :)
<geser> Adri2000: sometimes you need more than the last changelog
<LaserJock> geser: would you mind pastebining your config for me?
<joejaxx> Hello Everyone
<imbrandon> Nafallo, tomarrow
<bddebian> Heya joejaxx
<Nafallo> imbrandon: ah. any time set yet? :-)
<imbrandon> ummm, i dont rember to be honest, i would have to check my email
<joejaxx> bddebian: :)
<LaserJock> Nafallo: right after he's stocked is frig with Mt. Dew
<bddebian> heh
<imbrandon> hehe
<Nafallo> haha
<bddebian> Nafallo: Go fix wave-look :-)
<imbrandon> man its snowy and icey outside, but i dont wanna stay home
<tsmithe> imbrandon, lucky devil
<Nafallo> bddebian: what's wrong with it? :-P
<Nafallo> aha
<Nafallo> comments maybe :-)
<imbrandon> tsmithe, lucky?
<tsmithe> for snow, yeah!
<imbrandon> i hate the snow
<imbrandon> lol
* white waves to siretart and invites all to the utnubu-discuss@lists.alioth.debian.org list :)
<imbrandon> ugh another mailing list 
<white> hehe
<imbrandon> i already ignore the 50 i'm on
<white> well then one more does not make a difference ;)
<bddebian> heh
<nixternal> haha
<bddebian> What's utnubu?
* siretart updates his procmail recipe for utbubu
<imbrandon> typo i hope
<siretart> nope
<white> the "merging things from ubuntu into debian" project
<nixternal> i have always wondered the same. probably some drunk coder did a typo and it stuck
<bddebian> Heya siretart
<shawarma> No, it's ubuntu backwards.
<bddebian> Oh, I thought that died? ;-P
<nixternal> or that
<nixternal> hahahaha
<siretart> bddebian: utnubu is an debian initiative to merge ubuntu work back to debian!
<bddebian> siretart: Yeah, I recall that now :)
<ajmitch> hi siretart 
<bddebian> Heya ajmitch
<siretart> bddebian: white (and some other crazy guys like me) want to revive it
<imbrandon> ohh, i just work with my dd sponsors for the packages i look after heh
<siretart> huhu ajmitch, hi imbrandon 
<imbrandon> heya siretart 
<bddebian> siretart: Are you a DD?
<siretart> bddebian: since about a wekk, yes ;)
<bddebian> Ah, nice, congrats
<LaserJock> \o/
<imbrandon> congrats siretart 
<ajmitch> siretart: well done
<siretart> bddebian: slomo as well, btw :)
<bddebian> whoa
<imbrandon> i have another DD to bug then ;)
<bddebian> heh
* ajmitch can retire now :)
<white> imbrandon: that's what utnubu is about as well ;)
<imbrandon> heh, i'll need an advocate soon i guess ( soon == next 6 months )
<siretart> the channel here seems to be pretty crouded with DDs.. which is great
<imbrandon> white, i have 2 or 3 that i bug now and then ( and 2 or 3 that bug me about stuff in ubuntu ;P )
<bddebian> ScottK: What changed in libnet-dns-foo-bar-baz?
<ajmitch> people know not to bug me
* imbrandon bugs ajmitch 
* bddebian pokes ajmitch
* siretart hugs ajmitch
<imbrandon> :)
<imbrandon> hum , time for a clean install, i think i've messed this one up enough
<Nafallo> ajmitch: I'm not people ;-)
<ScottK> bddebian: I added the license preambles crimsun wanted and added README.Debian-source to the docs file to it gets installed.
<LaserJock> well, I hope utnubu gets revived. I'm a little skeptical of projects like that but it'd be nice if they worked well ;-)
<white> LaserJock: feel free to join in, you are welcome :)
* imbrandon ponders reinstalling or fixing bugs in apt-mirror from debian's BTS
<white> some manpower for writing the wnpp bugs and asking the ubuntu developers if they want to take care of the package in debian as well is needed
<white> and then of course reviewing, or giving advices if needed and stuff
<bddebian> ScottK: Oh, I thought that was the other one.. Hmm
<imbrandon> where is the ML signup page, i guess one more procmail rule wont kill me
<Nafallo> hehe
<ajmitch> over 1000 rules yet? :)
<imbrandon> close
<imbrandon> heh
<ScottK> bddebian: They both needed the license change.
<white> http://lists.alioth.debian.org/mailman/listinfo/utnubu-discuss
<ScottK> That was the only change in the other one.
<LaserJock> imbrandon: seriously?!?
<imbrandon> can we get a naibed-discuss@lists.ubuntu.com ? heheh just tesin
<LaserJock> when I used procmail I had ~ 20 rules
<ajmitch> imbrandon: no
<bddebian> ScottK: OK, got it
<ScottK> Thanks.
<imbrandon> heh
<imbrandon> LaserJock, did you see http://developers.slashdot.org/article.pl?sid=07/01/15/198212&from=rss
<imbrandon> that might intrest you
<ScottK> bddebian: Thanks for the re-review/advocacy. Any other MOTUs up for looking at  http://revu.tauware.de/details.py?upid=4079 and http://revu.tauware.de/details.py?upid=4078 - They are both in need of a 2nd advocate.
<LaserJock> imbrandon: wow, that is interesting
<Lutin> LaserJock: could you have a look at kayali on revu ? computer algebra system, might interest you :)
<bddebian> Lutin: I'm uploading it now :-)
<Lutin> bddebian: ohhh great :)
<Lutin> thanks :)
<LaserJock> phew, got out of that one ;-)
<Lutin> hehe
<ajmitch> LaserJock: you just have to learn how to duck fast
<imbrandon> haha
<imbrandon> wow , ok this laptop is going in the trash
<imbrandon> 12+ munites to load a c64 emulator
<imbrandon> i mean damn its only a 6510 1mhz proc
<imbrandon> i wonder if i could rip the lcd out of it for anything usefull
<imbrandon> s/usefull/geek worthy
* ScottK remembers 1mhz processors, most especially an S100 development box with a super-turbo switch that would make the CPU go 2 mhz.
<Nafallo> lol
<imbrandon> yea the c64 ran at something like 1.04 mhz
<imbrandon> dont rember exactly but something close to that
<ScottK> Of course it way only a 6502, not the advanced 6510.
<ScottK> way/was
<imbrandon> the 6510 was justa 6502 with more busses iirc
<imbrandon> ahh yea
<imbrandon> 6510 @ 1.02 MHz (NTSC version) / 0.99MHz (PAL version)
<imbrandon> peeks and pokes from my childhood
<imbrandon> heh
<ScottK> Didn't know that.  I went from 6502 to Z80 and nevery did anything with 6510.
* ScottK can't type tonight.
<imbrandon> yea , infact the c64 had an add on cart that added a z80 proc
<imbrandon> so you could do cb/m stuff
<ScottK> Yep.  I had an add-on card for my Apple ] [+ that did Z80.
* LaserJock starts singing "White and Nerdy"
* tsmithe weeps
<bddebian> Sing it LaserJock
<tsmithe> @lart lintian-overrides! why do you hate me, lintian???
<imbrandon> MOS Technology 6510/8500 (the 6510/8500 being a modified 6502 with an integrated 6-bit I/O port)
<imbrandon> ScottK, ^^
<ScottK> Hrrm.  This brings back memories.
<imbrandon> heh i even though about getting one of those c64 DTV things and modding it the other day
<ScottK> It was a Z80 project on the Apple ] [+ that was the first time I stayed awake so long programming that I started hallucinating.
<imbrandon> hahaha
<ScottK> When the guy over your shoulder starts making suggestions and you're the only one in the room, it's time to go to bed.
<imbrandon> or when you feel something cold on your shoulder and look up to see its the floor , it might be time to stay there
<ScottK> Yeah, althougth that's never happened to me because of programming.
<LaserJock> hmm
<imbrandon> hahaha
<crimsun> bddebian: hi
<ScottK> crimsun: Hi.
<crimsun> ScottK: hi
<imbrandon> hi, *
<crimsun> hi, motu trinity member
<bddebian> crimsun: Heya
<LaserJock> bah
<ScottK> I updated my packages to fix the licensing question and install the README.Debian-packaging problems http://revu.tauware.de/details.py?upid=4078 and http://revu.tauware.de/details.py?upid=4079 I'd appreciate another look when you have a moment.
<crimsun> wow, all three of the trinity present
<crimsun> we are blessed!
* bddebian runs away
<imbrandon> lol
<LaserJock> hmm, I saw s/blessed/cursed/ 
<bddebian> heh
<bddebian> crimsun: If you get a minute could you possibly check out alsa-tools and alsa-firmware on REVU?
<crimsun> I've been attempting to get revu work done, but wifi has not been cooperating, so I took a break to swim
<LaserJock> birrrr, too cold to swim here
<bddebian> crimsun: No worries
<tsmithe> crimsun, so are you possibly able to do some now? /me asks
<crimsun> tsmithe: you're queued behind ScottK 
<ScottK> Cool.
<tsmithe> crimsun, cool
<tsmithe> k
<Adri2000> crimsun: and where am I? :p
<crimsun> sheesh
<LaserJock> hmm, schroot is creeping me out. I'm not sure what it's doing :-)
<tsmithe> bddebian, thanks greatly for asking for me :D
* tsmithe appreciates it
* ScottK hopes his package isn't that bad.
<bddebian> Adri2000: What's your package?
<Adri2000> bddebian: it's merges and syncs on malone
<bddebian> Ah, pfft :)
<Adri2000> https://launchpad.net/~adri2000/+reportedbugs :)
<crimsun>   postfix-policyd-spf-perl_1.08.1-0ubuntu1_source.changes: done.
<crimsun> Successfully uploaded packages.
<crimsun> thanks for your work!
<ScottK> Thank you!
<bddebian> w00t, finally! :-)
* ScottK shudders at the thought of getting a complex package accepted.
<crimsun> ScottK: sorry, I should have been clearer: the section that's normally quoted in debian/copyright is the section at the end of /usr/share/common-licenses/GPL
<ScottK> Argh.
<crimsun> ScottK: the part following "To do so, attach the following notices to the program"
<ScottK> OK.
<ScottK> How about the artistic license quote?
<crimsun> that's fine
<ScottK> OK.
<ScottK> I'll be right back.
<bddebian> Gah, gotta head home, later gang
<crimsun> cya
<ScottK> Arghhh
<ScottK> crimsun: The new ID is http://revu.tauware.de/details.py?upid=4081.  I'd appreciate getting another look...
<crimsun>   libnet-dns-resolver-programmable-perl_0.002.2-0ubuntu1_source.changes: done.
<crimsun> thank yo!
<crimsun> you, even
<crimsun> Successfully uploaded packages.
<Hello58>  hi all
<ScottK> Thanks for reviewing.  The one remaining package I have pending needs that one in the archives before it will build, so in the meantime I'll review that package for lessons learned from these two.
<ScottK> HI Hello58
<Hello58>  hi scott
<Hello58>  can you help me out with installation of murrine?
<crimsun> ...
<crimsun> ok, there's conspiracy afoot
<crimsun> that random drive-by corresponded with a panhandler just accosting me in the coffee shop
<LaserJock> crimsun: hmm, see anybody in a suit and black glasses around?
<LaserJock> if somebody comes up to you and says their name is Jack Bauer, run
<geser> LaserJock: did you got schroot running?
<LaserJock> geser: yes, although I'm not really sure how to use it or what it's doing
<LaserJock> I did schroot -c feisty and I get a chroot
<LaserJock> it must mount my /home though
<geser> schroot does it for me (mounting /home)
#ubuntu-motu 2007-01-16
<geser> /etc/schroot/setup.d/10mount does it if run-setup-scripts is set to true for this schroot
<crimsun> tsmithe: versioning would be 1.0.14~rc1-0ubuntu1
<tsmithe> hmm
<tsmithe> ok
* tsmithe fixes
<crimsun> tsmithe: jaroslav just tagged 1.0.14rc2, so I'd wait a day or so til those tarballs are available
<tsmithe> hmmok
<tsmithe> *ok
<tsmithe> thanks
<tsmithe> anything to say about alsa-tools?
<tsmithe> cos i'm off to do an english essay - leave me a pm if there is
<crimsun> tsmithe: nothing conspicuous; remember to regenerate against 1.0.14rc2
<tsmithe> sure thing
<tsmithe> thanks
<imbrandon> ...
<zul> hey imbrandon 
<imbrandon> heya zul
<imbrandon> hrm, irssi shows mirc colors ? wow
<LaserJock> you're surprised?
<ajmitch> hello magnon 
<imbrandon> well kinda, been using it a few months now and this seems to be the first time i have seen it
<luisbg> LaserJock, hey!
<LaserJock> hi luisbg 
<superm1> hi imbrandon, did you ever get around to finishing looking through the mythtv packaging?
<luisbg> LaserJock, can you check something for me?
<imbrandon> ahh yea , matter of fact i need to install that compile i made and test it
<imbrandon> i made one or two small cahnges
<LaserJock> luisbg: what is it?
<imbrandon> i think i pusghed them back to bzr
<imbrandon> if not i will in a few
<superm1> ill update my local copy and see the changes then
<imbrandon> k
<luisbg> if the bzr for ubuntu studio is correct now... https://launchpad.net/ubuntustudio
<superm1> imbrandon, it looks like its at revision 13 still which is the last one i left it at on bzr
<superm1> (at least for mythtv) (mythplugins is at revision 4)
<imbrandon> k i'll push now
<superm1> k
<LaserJock> luisbg: it looks ok, if bzr will let me branch I'll tell you more
<imbrandon> hrm
<luisbg> will let you branch?
<LaserJock> luisbg: looks good to me
<LaserJock> luisbg: bzr kills my DSL router
<luisbg> ouch
<LaserJock> yeah
<LaserJock> I have a hard time using bzr from home
<LaserJock> a branch works about every 1 in 5 times
<luisbg> btw... seen the bug you can't delete registered series?
<LaserJock> yes, that's always been there
<LaserJock> you can get an LP admin to get rid of it though, I think
<imbrandon> iirc not a bug, you cant delete anything from LP
<luisbg> your "looks good to me?" is with one of those 5 times it worked or should I wait for a more detailed look?
<LaserJock> luisbg: I got it
<luisbg> cool
<imbrandon> more dew, brb
<luisbg> thanks man!
<luisbg> know any LP admin? would like to ask him to delete that for me
<imbrandon> #launchpad ;)
<LaserJock> luisbg: I think you guys could put a file in the root of the branch with the URL of the tarball
<luisbg> LaserJock, ok
<luisbg> will tell the owners 
<luisbg> of the stuff in the bzr
<LaserJock> lifeless: do you know if bzr > 0.11 makes less DNS lookups?
<persia> crimsun: For bitpim, no Ubuntu changes are preserved.  The changelog should still be preserved?
<tsmithe> LaserJock, thanks for the go-ahead :)
<LaserJock> well, you guys certianly don't need my permission ;-)
<LaserJock> I just thought it would help you out later on
<luisbg> LaserJock, thanks again
<luisbg> before making all upload just wanted to check they have a good basis to do so
<luisbg> if not... would be double the work later on
<crimsun> persia: it has to be a merge, because there's an existing Ubuntu delta, and you attest there are necessary changes
<lifeless> LaserJock: should
<persia> crimsun: The necessary changes are all mine, for this update.  I started with a pristine Debian source, as I agree with Adri2000 that a sync would work, but for the ctypes change.
<LaserJock> lifeless: ok cool, my DSL router still seems to not like bzr. I'll grab the latest bzr
<crimsun> persia: I'm not sure what your question is. There's an existing delta, and there will be an existing delta. You don't simply drop previous changelog entries when that's the case.
<persia> crimsun: OK.  I'll update, with the old changelog entries.  I'll note that I'm dropping all previous Ubuntu changes there.
<crimsun> persia: you don't need to note that, but you do need to retain the changelog entries
<persia> crimsun: I thought best practice was to list remaining Ubuntu changes during a merge.  Now I'm confused.
<crimsun> persia: oh I see. Yes, that's correct.
<persia> crimsun: Which is correct?
<crimsun> listing changes
<persia> crimsun: OK.  Thanks for the clarification.
<crimsun> ugh, this is ridiculous
<crimsun> everytime I go to clear the u-u-s queue, there's yet another bug
<LaserJock> mhm
<lionel> crimsun: you're too fast !
<crimsun> no, you're too fast
<crimsun> this bug queue is ridiculous
<crimsun> it's keeping me from dinner, darn it.
<crimsun> (and sleep, but whatever)
<LaserJock> crimsun: how do you do them? do you go down the line in email?
<lionel> not sure to understand...
<crimsun> LaserJock: I poll +reportedbugs
<crimsun> LaserJock: it's essentially watch -n2 wget ...
<LaserJock> lifeless: holy cow!!! bzr 0.13 is way faster than 0.11
<crimsun> there, u-u-s queue cleared.
<LaserJock> crimsun: +reportedbugs?
<crimsun> LaserJock: for the three most active reporters currently
<Burgundavia> u-u-s?
<imbrandon> ubuntu-universe-sponsors
<crimsun> ubuntu-universe-sponsors
<LaserJock> crimsun: ah
<LaserJock> I wondered how you could keep track very well, I'm stuggling
<Hobbsee> crimsun: WOOT!!!
<persia> crimsun: Thank you so ever much.  It's much more satisfying to contribute when the changes are adopted so amazingly quickly.
<crimsun> LaserJock: email's far too slow
<imbrandon> crimsun, poll +reportbugs ?
<imbrandon> hum
<Hobbsee> heya imbrandon 
<LaserJock> crimsun: surely we've got to have a better system than that :/
* Hobbsee pokes imbrandon over konversation debs a bit more
* imbrandon runs
<imbrandon> hehe
<LaserJock> crimsun: we need more than the "one man sponsor" show ;-)
* LongPointyStick attacks imbrandon 
<imbrandon> heh
<Hobbsee> LaserJock: true.  but he does such a good job
<LaserJock> Hobbsee: sure, but it's entirely unfair
<Hobbsee> LaserJock: yeah, i know.  i try to do stuff on it too
<Hobbsee> so does bddebian
<crimsun> LaserJock: it's hardly one-man; at least four other people are knee-deep in it
<Hobbsee> crimsun's just the one who does most of it
<imbrandon> oh there is a god ( other than crimsun ) http://arstechnica.com/journals/thumbs.ars/2007/1/15/6629
* imbrandon weeps
* crimsun pokes lionel about the merge and immediate sync of suphp
<crimsun> imbrandon: I'm no god; that's you, Jordan and Barry
<crimsun> I'm a mere peon
<imbrandon> phsaw
<LaserJock> +1 to that
<imbrandon> man that thing is a work of art though, backlit nintendo wording, full game cart slot on the back, extra controller port, etc etc etc
<crimsun> see, even LaserJock agrees that I'm a peon :-)
<LaserJock> no
<LaserJock> I didn't
<LaserJock> I agreed to imbrandon's phsaw
<LaserJock> I seriously don't know how you can do them that fast though
* LaserJock is slow
<crimsun> it's bug crack
<somerville32> Oh nifty
<somerville32> Linux bypasses the security features on my mp3 player by mounting it as a usb disk
<imbrandon> heh
* enyc waiting for the archive administratiors still...
<crimsun> for which?
<somerville32> The archives were pretty much cleaned out this morning
<somerville32> lol
<somerville32> s/archives/queue
<persia> Does anyone know the executable for the replacement of gnome-help-browser?
<LaserJock> yelp
<LaserJock> I would think
<persia> LaserJock: Thanks.  That even seems to have roughly the same behaviour.  (Packages should be updated at least once each year).
<LaserJock> heh, and gnome wants to replace yelp sometime too
<LaserJock> Project Mallard
<persia> LaserJock: Oooh!  Of course, I'll have to learn all new things, but I hope for fewer annoying errors.
<LaserJock> crimsun: so how come there are 109 subscribed bugs for u-u-s?
<LaserJock> are we just waiting on ubuntu-archive?
<Hobbsee> LaserJock: a lot that are for debian?
<LaserJock> some for sure
<LaserJock> but there are quite a few "Unconfirmed" there for Ubuntu
<crimsun> LaserJock: there are more; I've unsubbed some
<LaserJock> I just wondered if I was missing something
<crimsun> some are blocked on procedure
<crimsun> for instance, 47663 needs a correct debdiff and a clearer explanation of testing
<LaserJock> ok, but any Ubuntu bug that's set to "Unconfirmed" should be up for grabs, right?
<crimsun> some like 45852 just seem to be targetted to the wrong source package
<crimsun> some like 53826 are missubscribed period
<crimsun> (git-core is main, not universe)
<crimsun> so the Unconfirmed marker is actually misleading
<crimsun> you have to drill down and read each bug
<LaserJock> ok, what about 79308 and 78150
<crimsun> bug 79308
<Ubugtu> Malone bug 79308 in enigma "[Merge Request]  Please merge enigma from Debian Unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79308
<crimsun> bug 78150
<Ubugtu> Malone bug 78150 in kchmviewer "[Fesity MoM]  Merge Kcmhviewer_2.7-1ubuntu1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78150
<crimsun> the former's processable, though I've not tested it
<crimsun> the latter should be reworked
<crimsun> ^^ nixternal 
<crimsun> as for 77009, I'm not at all convinced it's correct
* ajmitch mutters
<ajmitch> I wonder why there's no cron job that alerted me to a degraded RAID array
<bddebian> Heya troop
<LaserJock> crimsun: yeah, I'm not really sure of those ice*
<persia> We've been promoted!  We're no longer only a gang!
<ajmitch> I guess it wasn't added in sarge
<persia> bddebian: Hi
<LaserJock> crimsun: what's wrong with kchmviewer debdiff, if you have time?
<crimsun> LaserJock: well, most of them are feasible, but a few make me twist my eyebrows, like the ->mozilla-browser bit
<bddebian> Heya persia
<LaserJock> crimsun: yeah
<crimsun> LaserJock: a few of the changes are pretty superfluous (does debian/compat really need to be bumped?)
<LaserJock> ok, yeah
<imbrandon> zomg
<LaserJock> imbrandon: what?
<imbrandon> my little brother ( 26 years old , but still "little brother" ) just im'd me that he made a myspace
<LaserJock> hmm
* imbrandon looks at it
<LaserJock> I still haven't figure out what exactly myspace does
<Hobbsee> imbrandon: mine's better :P
<imbrandon> http://www.myspace.com/selfdestruct0420
<imbrandon> ^^ just as bad as the other peoples
<LaserJock> wow, awesome crimsun and bddebian. We had 6 packages uploaded from REVU today
<bddebian> w00t
* ajmitch gets hating on computers again
<bddebian> Heh
<Hobbsee> crimsun: LaserJock anyone doing bug 79308?  the enigma one?
<Ubugtu> Malone bug 79308 in enigma "[Merge Request]  Please merge enigma from Debian Unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79308
<ajmitch> bddebian: ever want to be doing a random check of the system & notice that the RAID array with some data on it is in degraded mode, and has been for awhile?
<LaserJock> Hobbsee: I was thinking of doing enigma, but if you want it fine. I'm got some other things I'm working on too
<ajmitch> should be simple enough to readd the faulty device to the array & get it to start reconstructing, but still...
<bddebian> ajmitch: yep :-)
<LaserJock> now, is it right that a _source.changes file is not good to leave around with public access but a binary .changes is ok?
<ajmitch> since you can't do binary uploads to ubuntu, and debian will reject it if it's the wrong distro, it wouldn't affect quite as much
<Hobbsee> LaserJock: okay
<bddebian> Hmm, anyone think I should upload bug #54287
<Ubugtu> Malone bug 54287 in libcm "version too old" [Wishlist,Needs info]  https://launchpad.net/bugs/54287
<bddebian> And why is u-u-s assigned Main bugs? :)
<bddebian> Gah NM, I'm a crackhead
<somerville32> Eww
<crimsun> SURE, go ahead
<crimsun> :-)
<Hobbsee> bddebian: because people are silly :P
<bddebian> crimsun: ?
<crimsun> bddebian: being facetious
<bddebian> crimsun: Ah. 
<ajmitch> how could you, crimsun?
<bddebian> I am getting ready to upload this sucker so speak now or forever hold your peace :-)
* ajmitch speaks
<bddebian> And?
<ajmitch> it's crap
<bddebian> What's crap?
<ajmitch> you were talking about libcm
<ajmitch> unless it's been updated properly since I last looked?
<bddebian> Yeah.  It's already in the archive so how much more crap can a newer version be? :-)
<ajmitch> on your head :)
<bddebian> fuck it then
<somerville32> !ohmy
<ubotu> Please watch your language and keep this channel family friendly.
<ajmitch> feel free to ignore me, I'm not a developer
* crimsun dips a toe in the ubuntuforum
<bddebian> ajmitch: Neither am I so what's your point?
<ajmitch> oh you are
* ajmitch will avoid commenting on any more packages
<crimsun> 79196 is simply baffling
<bddebian> ajmitch: I am?
<LaserJock> crimsun: radeon driver with Intel graphics cards?
<LaserJock> bddebian: last time I checked you were, as is ajmitch 
<LaserJock> bddebian: you asked and ajmitch gave a reply. If you feel OK with uploading it go for it
<LaserJock> if not, don't ;-)
<crimsun> LaserJock: no, the bug stack is just baffling
<crimsun> I gotta deduce whether beryl/compiz, x11proto-render, or xorg-server is to blame
<Hobbsee> crimsun: stay away from the forums. they're bad!
<ajmitch> crimsun: blame compiz
<bddebian> git-core is main right?
<crimsun> bddebian: ja
<bddebian> So why are we subscribed to: bug #53826 ?
<Ubugtu> Malone bug 53826 in git-core "contains a redundant copy of subprocess.py" [Unknown,Unconfirmed]  https://launchpad.net/bugs/53826
<crimsun> bddebian: see above ;)
<somerville32> crimsun: Did you upload catfish?
<bddebian> See above what?
<crimsun> no, Toadstool did
<somerville32> crimsun: I just got an e-mail saying Jrmie Corbier uploaded it
<somerville32> Is that Toadstool?
<crimsun> bddebian: 
<crimsun> 20:41 < crimsun> some like 53826 are missubscribed period
<crimsun> 20:41 < crimsun> (git-core is main, not universe)
<bddebian> Oh, missed that, sorry
<somerville32> yes
* somerville32 loves whois.
<ajmitch> that 'redundant copy' is probably there so that git-core could have stuff working on python2.3
<ajmitch> something inherited from debian, I'd assume
<persia> I've finally gotten a new version of libjsw to work (although there is still one Debian bug, and an error if the envionment is funny).  Following Hobbsee's guidance, I've uploaded to REVU, but I have yet to file a bug.  What sort of bug should I file for a new upstream and some packaging fixes to address multiple other outstanding bugs?  Do I need one at all?
<Hobbsee> just say that in the bug?
<Hobbsee> for reference, yes.  include the link ot the revu package in the bug report
<persia> Hobbsee: Thanks.  I'll file a "new upstream version" bug with the comments, link to REVU, and diff -Nur debian/.
<Hobbsee> persia: nice :)
<Hobbsee> persia: if you could attach the diff -Nur debian/. as a file, that'd be great.  launchpad sucks for reading a diff
* Hobbsee glares at tepsipakki 
<persia> Hobbsee: Of course (persia has had enough fun with LP diffs).
<Hobbsee> hehe
* Hobbsee hugs tepsipakki 
<bddebian> crimsun: I guess I should give up trying to keep up with you eh?
<bddebian> ajmitch: Well Debian has 1.4.4.4 now anyhow
* bddebian crawls back to gnumach
<LaserJock> hmm, this might be a silly question, does /etc/hosts.{deny,allow} apply to incoming HTTP requests?
<ajmitch> no
<ajmitch> they are used by tcp wrappers (used by inetd)
<ajmitch> or by any program that may wish to make use of them, like nfs
<ajmitch> I don't think there's an apache module that uses them, though I may be wrong
<LaserJock> k, thanks
<Toadstool> hmm? someone said my nick? :)
<Toadstool> heya everybody
<ajmitch> hi Toadstool 
<Toadstool> hi ajmitch 
<bddebian> Heya Toadstool
* persia needs a new task.  Any suggestions?
<Hobbsee> persia: there are still more bugs in malone
<Toadstool> hey bddebian 
<persia> Hobbsee: Yes, but most of them aren't organised into tasks yet.  Oh well, I'll go back to reviewing bugs in packages I've touched and .desktop fixes.
<Hobbsee> :)
<Hobbsee> persia: i'm sure you can fix them
<Hobbsee> persia: you could do the unmet deps...
<persia> Hobbsee: Unmet deps.  That'll work.  Thanks :)
<Hobbsee> persia: you know how to generate them?
<Toadstool> cool... no need to report the update-manager crasher :)
<persia> Hobbsee: LaserJock told me about 6 months back, but I don't remember offhand.
<ScottK> bddebian: Thanks again for all your help getting my packages in.  They got approved and uploaded while you were on the way home.
<bddebian> ScottK: NP, thanks
<persia> Hobbsee: I've got it now.  No worries.
<Hobbsee> persia: apt-cache unmet.  apt-cache unmet | grep Package tends to work better though
* persia works on a script to auto-madison and extract universe
<Hobbsee> hehe
<Hobbsee> apt-cache unmet works way nicer than that :P
<persia> Hobbsee: Huh?  Is there an option to apt-cache I'm not seeing that only shows unmet deps for universe?
<Hobbsee> persia: not only in universe.  most are in universe, of course.  you can fix the main ones too
<persia> Hobbsee: Last time I tried to fix main, it was pushed upstream, and took four months to deploy (Categories checking for desktop-file-validate).  I'll stick to universe: instant satisfaction.
<Hobbsee> persia: well, unmet deps are kinda different.  but fair enough
* ajmitch hates broken packages
* bddebian too
<ajmitch> python-wxgtk2.6 ftbfs on amd64, broken packages for build-deps
<bddebian> So fix it :)
<ajmitch> read what I wrote, and the build log
<LaserJock> Hobbsee: did you do enigma?
<Hobbsee> LaserJock: no.  i've assigned it to myself.  the patch is fine, i just havent grabbed the debian source and uploaded it yet
<LaserJock> Hobbsee: ok, just wanted to make sure somebody was doing something ;-)
<Hobbsee> LaserJock:  :)
<persia> Does anyone have a good example of a bug to remove a binary package from the archive (no longer built by a retained source), or know of documentation to create such a bug?
<tepsipakki> could some MOTU ack a couple of sync-requests?
<tepsipakki> https://bugs.launchpad.net/ubuntu/+source/farsight/+bug/79392
<Ubugtu> Malone bug 79392 in farsight "Please sync farsight (universe) from Debian unstable (main)" [Undecided,Unconfirmed]  
<tepsipakki> https://bugs.launchpad.net/ubuntu/+source/gmail-notify/+bug/76752
<Ubugtu> Malone bug 76752 in gmail-notify "Please sync gmail-notify (universe) from unstable (main)" [Undecided,Confirmed]  
<persia> tepsipakki: Did you subscribe ubuntu-universe-sponsors?  The queue is being tracked fairly closely these days.
<tepsipakki> oh
<tepsipakki> I'll do that
<persia> tepsipakki: I understand that guidance documentation is under development, but the advised workflow is to only subscribe u-u-s to start, and they will subscribe u-a-a when they acknowledge the bug.
<tepsipakki> yep, I was advised about it a minute ago ;)
<\sh> moins
<\sh> packages with unmet deps, can we still force an rebuild with XbuildY as version ?
<persia> \sh: skencil was last rebuilt as XbuildY 12th January, so there is precedent.
<dholbach> good morning
<ajmitch> morning dholbach 
<dholbach> heya ajmitch
<dholbach> hey LongPointyStick
<LongPointyStick> hey dholbach, ajmitch 
<LongPointyStick> :)
<ajmitch> uh oh
<\sh> ajmitch: would you do me a favour? please package PloneOOoTransform ,-)
<\sh> ugly piece of plone crap
<ajmitch> heh
<\sh> how can someone run openoffice with xvfb on a server...
<ajmitch> nasty
<\sh> ajmitch: check this http://plone.org/products/ploneoootransforms
<\sh> ajmitch:especially read the install.txt inside the source tar ball ,)
* ajmitch goes off to be sick
<white> lucas: regarding utnubu, can you configure your scripts in a way so that they send a mail about new packages once a day to utnubu-discuss?
* ajmitch would think that daily is a bit much
<\sh> ajmitch: get well asap :)
<\sh> siretart: ping.boson-base ftbfs because of missing UTS_RELEASE (i thought setting linux-libc-dev will help, but it doesn't)
<persia> \sh: boson-base is gone in debian, and upstream is two versions ahead.
<persia> siretart: Is there a reason boson is out, or may I do a 0.13 package?
<\sh> persia: that's why I asked siretart as debian upstream maintainer ;)
<\sh> persia: but boson-data is 0.12 (just like debian) but boson-base is not ;)
<\sh> and upstream has 0.13 fright
<\sh> s/f//
<tepsipakki> themuso: ping
<siretart> puh, I don't really maintain boson, I removed myself from uploaders field already
<siretart> \sh: there is an updated boson package in experimental, I think we should go with that one for feisty
<siretart> IIRC that is a new upstream version, with many fixed bugs, but not suitable for the etch release
<\sh> I'll give it a try...need to find now a server...which doesn't have a location in our database *sigh*
<\sh> brb
<\sh> re
<\sh> siretart: you are still in the uploaders field even in the experimental package ;)
<siretart> \sh: grrr. need to change that soon
<siretart>      boson |     0.13-1 |  experimental | source, amd64, hppa, i386, ia64, powerpc, sparc
<siretart> I think that one should be fine for feisty, I think
<\sh> siretart: it's building ;)
<persia> 0.13-1 FTBFS for me (AMD64).  Shall I try to fix that?
<\sh> persia: for edgy we didn't build amd64 packages at all...so as a work around we can remove amd64 ;)
<siretart> hm. works in debian
<siretart> perhaps again toolchain foo?
* persia grumbles about not having games
<\sh> siretart: -fstack-protection? ,-)
<persia> siretart: Perhaps python change?
<palski> crimsun: ping
<siretart> persia: btw, I need to remove the rwlock patch from oops
<persia> Error is cannot convert int* to Py_ssize_t*
<siretart> persia: it makes oops aborting after 30 minutes, already got a bug report about that
<persia> siretart: Ah.  No worries.
<siretart> \sh: for oops it was worse. it uses an private rwlock implementation, which doesn't build with glibc2.5 :/
<siretart> which we have in feisty, of course :(
<\sh> siretart: nasty
<siretart> yeah :/
<persia> siretart: I'll start running oops all day here, and see if I can reproduce.  If not, perhaps Ubuntu just shouldn't sync with -5?
<\sh> siretart: we had problems with kernels < 2.6.19
<\sh> siretart:mysql was bugging because of a futex_wait problem...and in 2.6.19.2 is just gone
<siretart> persia: or just add the patch from -4, yes
<\sh> siretart: we did some very nice load test with sles and ubuntu..and both are failing ... now ubuntu with a 2.6.19.2 performs very good
<persia> siretart: I'll grab the patch from -4 and test for a while then.
<\sh> siretart: btw...are you going to fosdem?
<siretart> \sh: I was asked by a collegue, I'm still considering it
<\sh> persia: after fixing the problem with the int typecast, I get the "error: UTS_RELEASE was not declared in this scobe
<\sh> persia: but even build-dep on linux-libc-dev doesn't help
<\sh> persia: boson 0.13-1 ,-)
<persia> \sh: Sorry.  Was distracted by oops.  I'll add it to my list and try to make a patch so it can compile this evening or tomorrow (unless you are really excited about it).
<persia> \sh: If I can get it to compile, shall I just post a patch, or should I also try to un-native the package for full package submission?
<crimsun> palski: pong
<persia> crimsun: You're too fast!  I'm still testing...
<palski> crimsun: nothing anymore, I already added my comment to bug #79059
<Ubugtu> Malone bug 79059 in gnome-hearts "[SRU]  gnome-hearts crashes on startup (edgy)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79059
<StevenK> persia: Ping.
<persia> StevenK: Is now a good time to fix the menu?
<StevenK> persia: Yup
<persia> StevenK: OK.  How can I help?  Do you need docs, or a patch?  If a patch, where can I get that to be patched?
<\sh> persia: un-nativy it ,-)
<crimsun> palski: personally I feel mor
<crimsun> arg
<crimsun> palski: I feel more comfortable with a simpler debdiff (RE: 79059)
<StevenK> persia: I'd prefer a patch, and an explanation
<persia> \sh: queued.  Depending on difficulty, I'll submit something tomorrow or the next day.
<persia> StevenK: That sounds good to me.  What exactly are we looking at?
<crimsun> palski: please test the suggested change
<\sh> persia: the typecast errors you can get along with changing int to long...but UTS_RELEASE is set in /usr/include/linux/version.h and it's included in this piece of source..so I don't see the problem...
<palski> crimsun: I'll do that later today
<StevenK> persia: Okay, so I'd like this package to provide a menu entry under System called "About Ubuntu" that launches about-window
<crimsun> palski: ok, thanks.
<StevenK> (A menu entry called that already exists too, just to make it harder)
<StevenK> persia: You can use bzr to grab http://bazaar.launchpad.net/~stevenk/about-window/dev
<persia> StevenK: Grabbing.  Do you want two items that say "About Ubuntu", or do you want to replace the current item?
<persia> \sh: At least for me, /usr/include/linux/version.h doesn't include any definition of UTS_RELEASE.
<\sh> persia: ah yes, I was using dapper and not my feisty chroot :(
<\sh> that's as well a problem during my vmware install on edgy and feisty
<\sh> wonder why
<persia> \sh: I need to head off for a bit, but I'll chase the code when I return.
<\sh> it's not set anymore
<\sh> persia: I'm poking #ubuntu-kernel..so if there is a workaround, I'll prepare a patch for 0.13-1
<persia> StevenK: The simple answer is to start with the /usr/share/applications/ubuntu-about.desktop provided by gnome-panel-data, and change the Exec clause.  I'll make a patch when I return.
<StevenK> persia: I did that, which didn't work.
<crimsun> \sh: upstream kernel change
<crimsun> it's apparently supposed to be in linux/utsrelease.h, and it's not exported by `make headers_install'
<\sh> argl...how can we solve this problem ?
<persia> StevenK: I've replicated that locally now, and I'm not seeing what I expect in /etc/xdg/menus.  Let me get back to you on this (and thanks for the interesting .desktop question: most are trivial).
<persia> \sh: That appears to be a compile-time value only.  If you don't find something else, I think we can get it from a local include generated by debian/rules from uname-a.
<\sh> persia: ok..trying a workaround...give me a sec ;)
<StevenK> persia: Heh, any time. :-)
<persia> StevenK: I found it.  The issue is that the System menu is not being generated by the xdg trees, but is hardcoded in gnome-panel/panel-menu-items.c.  If you want to replace the "About Ubuntu", you either need to alter the path used by this code, Replaces gnome-panel for /usr/share/applications/ubuntu-about.desktop, or have gnome-panel drop the .desktop file and depend on about-window.
<persia> StevenK: You might also try something with dpkg-divert, but I'm not really familiar enough with that to feel comfortable suggesting specifics.
<\sh> did I say that I hate quilt?
<\sh> and I hate cmake
<azeem> what's wrong with quilt?
<\sh> quilt new, quilt edit, quilt refresh, quilt pop ... too difficult for me...
<persia> \sh: I hope your desire for RTS makes up for that :)
<\sh> and cmake...why is -D not -D like in make...no -D as in make you have to add to CMakeLists.txt as add_definitions(-Dfoo=bar) ugh
<siretart> \sh: something you love? ;)
<\sh> siretart: pure diffing and patching is my love ,)
<StevenK> persia: Right. What I might do is talk to seb128 about it.
<persia> StevenK: Unless you want to do something dark and secret with dpkg-divert, that's your best route to success :)
<crimsun> imbrandon: n/m regarding rebuilding beryl 0.1.2-0ubuntu1, already fixed the cause (mesa)
<segfault> when fixing universe packages, can i upload it directly to revu?
<crimsun> existing source packages in universe should use launchpad
<crimsun> file a bug against the source package, and attach a debdiff
<crimsun> then subscribe ubuntu-universe-sponsors
<segfault> humm, ok
<segfault> even if i uploaded it before?
<crimsun> revu is reserved for new source packages
<raphink> is it ?
<raphink> I'm fine with updates and merges going through revu personally
<raphink> they too need to be reviewed
<white> siretart: thanks for the mail, great idea, what do you think about adding those information to REVU or strongly recommend it there as well for new packages?
<siretart> white: I need to check this with a MOTU Meeting, but in general, I think that would be the correct place
<siretart> white: but first, that wiki-list-app needs to designed and actually written ;)
<crimsun> I don't have a problem with revu being used as such, either, but I understood lp to be the "correct" place.
<siretart> yeah, we decided to abandon REVU in favor of launchpad anyway.
<siretart> at least that what I understood
<white> siretart: great, because if the people directly get pointed to that on places like REVU the chance of getting things back is higher :)
<siretart> white: the space is quite limited there. I'm happy to link to some wiki page from there
<white> i am going on vacation soon and the relocate to .au anyway, so there is time to code :P
<siretart> wow :)
<siretart> I'm starting my new job on february - I hoped that I would have way more time in january, though
<siretart> long story short: it was big luck that I got that job anyway :)
<white> siretart: you should have come to us :)
<siretart> white: who are 'you'?
<siretart> credativ?
<white> yes
<siretart> ah. Well, I was considering writing my master thesis there ;)
<siretart> now I'll stay at university
<white> i heard about that, but the topic was not compatible with current stuff here :(
<siretart> yes, I imagined
<siretart> white: are you coming to CLT?
<white> siretart: i will relocate to melb in february and when i come back in summer for 3 weeks i will probably spend most of the time with family stuff
<siretart> white: ah, I see
<siretart> white: you are leaving germany completely?
<white> well i am studying in melbourne, so i am just here at home and working during the vacations :)
<siretart> oh, nice!
<siretart> :)
<bddebian> Heya gang
<siretart> hey bddebian 
<bddebian> Hi siretart
<siretart> bddebian: I tweaked the sudo configuration on tiber a bit, now all users on tiber should be able to resync the revu keyring, see /etc/motd
<bddebian> Ah cool
<tepsipakki> Hi all.. I'm looking for advocates for the TB meeting this evening :)
<tepsipakki> hoping that my application for ubuntu-dev would be ack'd..
<tepsipakki> now where did everyone go?-)
<proppy> bou
* proppy hugs dholbach
<dholbach> hey proppy
* dholbach hugs proppy
<proppy> hey hey
<proppy> we fall in many python - version packaging hole today at work
<proppy> when we install a new python version (i.e 2.5), we had to --reinstall all the dependent python-* packages, to allow us to rebuild another
<proppy> is there sort of virtual package that provide this facility, or should i spec it ?
<\sh> hooray...boson works ;)
<\sh> fixed
<\sh> now for boson-data etc.
<palski> siretart and crimsun what about bug #79059, which way is better? you decide =)
<Ubugtu> Malone bug 79059 in gnome-hearts "[SRU]  gnome-hearts crashes on startup (edgy)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79059
<siretart> \sh: the one from experimental?
<siretart> palski: I'd say you have +3
<siretart> (green light for uploading)
<\sh> siretart: yepp, patched it to compile smoothly ;)
<\sh> siretart: we can sync boson-data and boson-music without any harm, and I'll upload boson 0.13-1ubuntu1
<\sh> package names were changed from boson-base to boson
<palski> siretart: yes, but crimsun said that I should test the other way too
<\sh> siretart: and it compiles on amd64, too
<LaserJock> so etch still isn't out?
<zul> LaserJock: surprised?
<LaserJock> it's like waiting for a baby to be born
<LaserJock> or alternatively, riding in a car in a cross-country road trip
<LaserJock> zul: well, tbh, I expected a little more solid timeline this far into it
<bddebian> heh
<LaserJock> I mean, I know the whole "when it's ready" thing
<LaserJock> but I would think they would know "when it's ready" more than like a day ahead of time ;-)
<siretart> \sh: cool
<siretart> LaserJock: I think etch is currently block by d-i, which is in turn blocked by the kernel
<\sh> siretart: just uploaded..think it will lay a bit in NEW because of the new packagename
<siretart> LaserJock: wait for d-i RC2, and then + 2-4 weeks for the etch release
<siretart> \sh: you can check the NEW queue nowadays in launchpad
<zul> LaserJock: LaserJock: and pigs fly
<\sh> siretart: i know...but I can't pull the trigger to "un"-new ,)
<LaserJock> siretart: ah
<LaserJock> thanks
<siretart> \sh: poke Mithrandir ;)
<\sh> siretart: fck lp...what was the url to NEW queue?
<geser> \sh: https://launchpad.net/ubuntu/feisty/+queue
<\sh> thx...and it isn't in the new queue...looks good :)
<siretart> https://launchpad.net/ubuntu/feisty/+queue
<siretart> ah, too late
<siretart> \sh: https://launchpad.net/ubuntu/feisty/+queue?queue_state=2&queue_text=boson
<siretart> it is in the ACCEPTED queue
<siretart> anyway, I'm afk shopping, bbl
<ajmitch> morning
<bddebian> Heya ajmitch
<LaserJock> hi ajmitch, bddebian 
<bddebian> Heya LaserJock
<ajmitch> will there be a TB meeting today or not, I wonder?
<LaserJock> ohhh
<LaserJock> I sure hope so
<LaserJock> we need our Council Grayskull
<_Enchained> Hi all
<zul> i wanna know who is on the council :)
<_Enchained> bddebian: can you archive the cryopid upload on revu ?
<_Enchained> I've asked a sync from debian
<bddebian> Sure
<_Enchained> or delete it?
<_Enchained> ...I don't know
<_Enchained> thanks
<\sh> core++ fixed for amd64
<ajmitch> zul: it's a Mystery
<\sh> and for others too ;)
<bddebian> _Enchained: archived
<_Enchained> ok thx
<zul> ajmitch: i know
<LaserJock> zul: yeah, I don't know why the nominations aren't on -motu
<zul> maybe dholbach is too busy
<ajmitch> maybe the positions are getting auctioned off to whoever can bribe dholbach the most :)
<LaserJock> hmm
<LaserJock> I'm on the losing end of that I'm pretty sure
<ajmitch> broke student?
<LaserJock> broke married grad student
<ajmitch> even worse
<LaserJock> unless your spouse is loaded ;-)
<LaserJock> mine is not, so yeah
<_Enchained> bddebian: do you have a few minutes ?
<bddebian> Not currently sorry.  Possibly in a little bit.
<Adri2000> does anyone understand "What does this do to your desktop?" ?
<Adri2000> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407042
<Ubugtu> Debian bug 407042 in debian-reference "Please add a .desktop file" [Wishlist,Open]  
<LaserJock> Adri2000: well, it adds a menu item for debian-reference to they System menu in Gnome and KDE
<Adri2000> LaserJock: 
<Adri2000> oops
<Adri2000> LaserJock: *I* filed this bug report :)
<LaserJock> I know
<LaserJock> but I was replying to your question
<LaserJock> although I don't really understand why debian-reference needs a .desktop
<Adri2000> I've actually never installed this package, I filed a bug report in debian to reduce the ubuntu/debian diff
<LaserJock> well, we should consider whether we should keep the diff
<\sh> fck..boson needs a conditional compile flag...
<Adri2000> LaserJock: but I still don't understand this question from the maintainer, doesn't he know what a .desktop file is?
<LaserJock> Adri2000: perhaps not
<LaserJock> Adri2000: debian has their own menu system
<LaserJock> Adri2000: but it does look like it actually would do something
<Adri2000> answering him with a freedesktop.org url...
<LaserJock> Adri2000: just say it adds menu items to Gnome and KDE menus
<Adri2000> A .desktop file adds a menu entry in the GNOME/KDE/whatever menu.
<Adri2000> See http://freedesktop.org/wiki/Standards_2fdesktop_2dentry_2dspec
<LaserJock> oh man, I hate Windows
<LaserJock> I'm trying to admin a Windows 2000 box for a labmate
<LaserJock> turned it on today and it's got some virus
<LaserJock> tried to updated virus scanner (got a Code Red email from uni IT)
<LaserJock> but it wouldn't install until I closed the old virus scanner
<LaserJock> but I couldn't do that without using the Task thingy
<LaserJock> but then the installer wouldn't work
<LaserJock> so I decided to reboot
<LaserJock> and now it's hung  "Saving your settings ..."
<imbrandon> darn winderz
<LaserJock> I guess I'll have to hard reboot
<geser> LaserJock: replace it with Ubuntu :)
<LaserJock> geser: well, the problem is the new grad student doesn't want anything but Windows
<LaserJock> I offered
<LaserJock> I've got a feisty machine kvm'd to his keyboard and monitor
<LaserJock> the rest of us have imacs
<zul> not much of a grad student then ;)
<Adri2000> zakame: ping
<LaserJock> zul: I'll get him, don't worry ;-)
<ajmitch> LaserJock: he's new
<ajmitch> he doesn't get a choice
<LaserJock> well, my boss gave him the choice, not me
<LaserJock> besides, that's the other machine is my work pbuilder machine
<geser> LaserJock: do you think it's ok to ask the TB how the Maintainer mangling in source packages is supposed to happen? (if time permits)
<ajmitch> daniel_!
<LaserJock> geser: it might
<LaserJock> geser: you might ask a TB memeber real quick
<LaserJock> geser: it could be we just need Matt to make a decision
<Adri2000> zakame: do you still maintain opendchub?
<Gwaihir> Hi all...
<Gwaihir> I'm an Ubuntu Itlian trnslator...
<dholbach> ajmitch: haha
<Gwaihir> and I have a problem!
<dholbach> ajmitch: we'll have the TB meeting quite soon :)
* ajmitch starts the bidding at $0.10
<Gwaihir> me and another guy have set up a new translation for a package...
<dholbach> ajmitch: *snort*
<Gwaihir> and we would like to have it in Feisty
<l3on_> hi all
<Gwaihir> the problem is... if we upload the translation in gnome SVN it's not going to make it
<Gwaihir> in feisty...
<Gwaihir> is it possible to include the new PO for this package?
<Gwaihir> the package in question is firestarter
<DktrKranz> we planned to generate a debdiff with .po file included and open a new bug report
* ajmitch wonders if rosetta would be a better option
<ajmitch> except I don't know how rosetta works with universe packages
<Gwaihir> the package in question is in universe
<ajmitch> yes, I know firestarter
<Gwaihir> rosetta doesn't handle universe's packages
<\sh> hmm?
<ajmitch> hi \sh 
<imbrandon> sure it does now, last i heard
<imbrandon> ( rosetta and uni packages )
<\sh> moins ajmitch, feeling better?
<Gwaihir> imbrandon: really?
<imbrandon> Gwaihir, yes, for some months now
<\sh> imbrandon: did rosetta make a diff between main and universe?
<imbrandon> \sh, before it did, now it dosent
<DktrKranz> if so, it sounds great
<Gwaihir> imbrandon: I didn't know...
<imbrandon> Gwaihir, it was in the ubuntu news letter a few months ago as one of the main topics
<imbrandon> like 1 month before edgy was released iirc
<ajmitch> \sh: the difference being whether the packages were imported into rosetta for translation, I think
<ajmitch> imbrandon: #launchpad is reporting no
<ajmitch> so I think kiko probably knows fairly well
<imbrandon> hrm , i could have swore it is/was because we had a big todo about it
* imbrandon looks
<Gwaihir> I asked kiko right now...
<enyc> imbrandon: hrrm intiresting my patch for qpsmtpdd init has been merged with never debian upstream source zersion...   is this called a 'delta' now?
<enyc> imbrandon: (in qpsmtpd 0.32-5ubuntu1)
<Gwaihir> he says Rosetta doesn't handle universe...
<Gwaihir> anyway... firestarter is not a product registered in launchapd...
<imbrandon> enyc, what are you asking ? heh
<imbrandon> you have a patch to that package and it was adopted upstream ?
<siretart> \sh: you needed to patch boson for amd64? what was it?
<imbrandon> a "delta" is any diffrece between a debian and ubuntu package
<enyc> imbrandon: Im asking ef the 3-line patch used-in-ubuntu is now called a 'delta' -- it has NOT been taken upstream (debian or source)
<imbrandon> enyc, correct
<enyc> imbrandon: its been merged with a more recent  debian version... i.e. the 'delta has been carried' if I understand this correctly
<\sh> siretart: 1. int <=> long (I had to fix the patch again, because 32bit archs are complaining about long int typecast)...2. sed -i /UTS_RELEASE/\"`uname -r`\"/ boson/info/boinfo_linux.cpp ,-)
<\sh> siretart: give me 5 mins and I upload new version of the patch
<enyc> imbrandon: the funny thing is the archive administrators still have not uploaded the 2 ~proposed versions which have all had 3 +1 's by universe-sponsors !
<siretart> \sh: any idea why it did build in debian?
<enyc> imbrandon: (SRU fix)
<\sh> siretart: the sed command I start in debian/rules of course...a patch to CMakeLists.txt: add_definition(-DUTS_RELEASE=`uname -r`) didn't help and resulted in an error
<ajmitch> enyc: MOTUs upload, archive admins let them into -proposed
<ajmitch> have they been uploaded by a MOTU?
<\sh> siretart: different tool-chain...more strict type checking with our toolchain..that's what I would say
<DktrKranz> suppose rosetta doesn't manage Universe packages
<DktrKranz> what should be the best way to implement a translation?
<\sh> siretart: like the wine problem with -fstack-protector ,-)
<DktrKranz> in Universe packages, of course
<siretart> \sh: do you think we should include that patch in debian as well?
<enyc> ajmitch: err... see 77485 and 78005 .. i think they both have been uploaded as required
<enyc> ajmitch: unless I misunderstand something
<\sh> siretart: could be an idea to not reinvent the wheel again...and it's definitly a problem of upstream, because of missing 64bit programming knowledge
<siretart> \sh: care to send the patch upstream?
<siretart> thats maybe even better that than via debian games team
<\sh> siretart: do you have an bugzilla account there?
<ajmitch> enyc: right, it does look like it was uploaded, so we just wait :)
<siretart> nope. but isn't that the kde bugzilla?
<ajmitch> hi raphink 
<siretart> hi ajmitch, hi raphink 
<enyc> ajmitch: ok fine... been quite some time now s-o I was wondering if something is wrong
<ajmitch> 10 days isn't long, sadly
<ajmitch> especially with things like holidays, herd 2 freeze, etc
<raphink> hi ajmitch
<raphink> hi siretart
<ajmitch> universe SRU slips down the priority list
<enyc> ajmitch: fair enought... it seems like its been there for ages to me... but i havent counted the days you see
<enyc> ajmitch: [ok]  ;-)
<enyc> ajmitch: thanks ;-)
<gpocentek> evening
<Adri2000> hi gpocentek 
<gpocentek> hello Adri2000 ;)
<somerville32> gpocentek, Did you get my ping last night?
<\sh> siretart: I'll attach it upstream
<\sh> siretart: you can take the patch for debian upstream ;)
<siretart> \sh: thanks
<gpocentek> somerville32: I don't think so, what was it about?
<siretart> btw, bzr-builddeb uploaded
<somerville32> gpocentek, The tentative release date for Xfce4 4.4 Stable
<\sh> siretart: np...just uploaded
<gpocentek> somerville32: has it been decided already?
<somerville32> The tentative release date is set for the 21st of January.
<somerville32> Oh wait
<somerville32> It is already released
<somerville32> oh wait
<somerville32> haha
* somerville32 continues to read.
<somerville32> 4.2.4 (a bug release) is released
<somerville32> 4.4 is the 21st
<sistpoty> hi folks
<ajmitch> hey sistpoty 
<sistpoty> hi ajmitch
<gpocentek> hello sistpoty 
<DarkSun88> Hi
<sistpoty> hi gpocentek
<ajmitch> half the TB is probably recovering from a night out at LCA
<ajmitch> 7AM in sydney at the moment :)
<LaserJock> :(
<ajmitch> another 2 weeks..
<LaserJock> noooooo
<ajmitch> hopefully before release day, at least 
<Adri2000> :-/
<\sh> siretart: bugs.kde.org #140169
* ajmitch wonders when they'll get new TB/CC members
<LaserJock> ajmitch: yeah, considering Mark said "I'll have them in a week or two" at Mt. View ;-)
<ajmitch> rather long weeks he goes by
<somerville32> indeed
<ajmitch> I think it's been about 3-4 weeks since the last TB meeting
<ajmitch> unsure, but the next one may be during a distro team sprint
<ajmitch> yeah, developer sprint in Oslo is on the release schedule
<dholbach> wouldn't the next TB be in two weeks then?
<ajmitch> hm right, sprint is next week?
<ajmitch> LaserJock: ok, you've got another 2 weeks to raise bribes :)
<\sh> ok..going to my hotel
<\sh> good night everybody
<sistpoty> cya \sh
<LaserJock> stink!!
<somerville32> LaserJock, What are you applying for?
<LaserJock> dholbach: can the TB approve MOTU Council by email?
<LaserJock> somerville32: nothing
<dholbach> LaserJock: we have some unresolved issues we need to talk about
<LaserJock> ah
<dholbach> I added them to the agenda
<dholbach> LaserJock: and that's not my decision - you can mail technical-board@lists.ubuntu.com if you want to voice a strong opinion
<LaserJock> dholbach: I haven't seen anything on -motu about it. Is that for a reason?
<dholbach> we talked about that in the last meeting, added it to the spec
<dholbach> and it was in the meeting minutes
<dholbach> iirc
<siretart> \sh_away: ROCK!
<LaserJock> dholbach: ok
<siretart> hey sistpoty! hi dholbach!
<sistpoty> hi siretart
<LaserJock> dholbach: I don't have any issues, I just want it over with so the Council can get moving.
<dholbach> LaserJock: you're not alone... trust me
<dholbach> hi siretart, hi sistpoty
<sistpoty> hi dholbach
* dholbach hugs siretart and sistpoty
<dholbach> how's it going?
* siretart hugs sistpoty and dholbach back :)
<dholbach> :-)
<siretart> dholbach: finally decided where I'm going to work next month! /me is happy :)
<dholbach> siretart: WOW - nice! What is it going to be?
<ajmitch> siretart: excellent!
<siretart> dholbach: back at university, same place as my master thesis :)
<ajmitch> hah
<LaserJock> siretart: teaching?
<ajmitch> plenty of ubuntu time?
<dholbach> siretart: nice - so no hassle moving around
<sistpoty> hehe
<siretart> LaserJock: teaching and PhD in paralell
<siretart> dholbach: yepp :)
<LaserJock> siretart: cool
<ajmitch> great, what's the PhD on?
<LaserJock> siretart: that's what I'm doing this semester ;-)
<ajmitch> it'll be great to have dr. laserjock & dr. siretart :)
<dholbach> siretart: congratulations :)
<sistpoty> yay, congrats siretart!
<shawarma> ajmitch: I don't know about the rest of this part of the world, but at least in Europe, you don't get to be called dr. if you "only" have a Ph.d.
<shawarma> ajmitch: Er.. i mean Denmark.
<siretart> ajmitch: I don't have a topic yet, ask in 6 months ;) - but it will be related to/about system security
<ajmitch> shawarma: that's strange, since it's a doctorate, so you get the title
<LaserJock> shawarma: really, that stinks?
<shawarma> ajmitch: We have doctoral degrees higher than ph.d. and only if you hold one of those, you get to be Dr. Shawarma.
<ajmitch> NZ at least follows british custom in that regard
<ajmitch> what are the higher degrees?
<LaserJock> shawarma: that's weird ;-)
<ajmitch> quite
<LaserJock> a doctorate is a doctorate
* LaserJock write a memo not to go to Sweden with his PhD
<shawarma> ajmitch: I'm not sure what they're called in English. When you graduate from university, you're a cand. scient. (if it's comp. sci. or math or something). The "real" doctoral degree is a dr. scient. In between, you have ph.d.
<ajmitch> how odd
<shawarma> ajmitch: What does it take to get a Ph.d?
<ajmitch> we'd have a bachelors degree, masters & then phd
<LaserJock> or some of us skip masters
<shawarma> ajmitch: I know that those dr. scient. things are evaluated by an international board of experts and stuff. It's serious shit. :-)
<ajmitch> yeah
<ajmitch> masters is skipped at times
<shawarma> LaserJock: We can't do that.
<LaserJock> shawarma: it's still the same amount of work
<LaserJock> kinda
<siretart> in germany, the traditional degree you make is 'dipl. inf', (corresponds to master degree) then 'Dr. ing' (at least here in Erlangen)
<shawarma> LaserJock: Probably.
<LaserJock> I've been doing my PhD for 5 years
<shawarma> siretart: And dr. ing is a ph.d?
<ajmitch> LaserJock: another 2 or so to go, perhaps?
<siretart> shawarma: we actually don't call it 'ph.d'. I thought that would be equivalent to the german 'Promotion'
<LaserJock> ajmitch: 1, just 1
<ajmitch> hehe
<ajmitch> LaserJock: so you need to get all the research & the thesis done in this next year?
<ajmitch> good luck
<shawarma> siretart: I see. It's a bit of mess figuring out what degrees correspond to what degrees in other countries.
<ajmitch> though I think married phd candidates have a bit more motivation than the average grad student
<sistpoty> dholbach: quick question: do you know when motu-sru has been subscribed to bug #66355?
<Ubugtu> Malone bug 66355 in gnome-pilot "gpilotd locks up my Palm Z22" [Unknown,Fix released]  https://launchpad.net/bugs/66355
<LaserJock> ajmitch: well, I've done almost 5 years of research, it's mostly about finishing it off and writing it up
<ajmitch> ok
<ajmitch> since we're all here, who wants another MOTU meeting soon?
<sistpoty> ajmitch: +1
<siretart> sponti meeting? ;)
* LaserJock raises his hand
<ajmitch> siretart: sure, why not? :)
<somerville32> +1
<sistpoty> let's take over ubuntu-meeting and play tb for an evening *g*
<siretart> oh, there is currently a TB meeting
<dholbach> sistpoty: no idea
<LaserJock> have we even confirmed the Universe release schedule? I don't see anything on the wiki page
<Toadstool> heya everybody
<sistpoty> dholbach: ok... just strange because I didn't get a mail from that bug
<siretart> oh, it was cancelled. interesting.
<dholbach> 5 Jan 07 10:30  	 Borden Rhodes  	bug  	 	 	added subscriber MOTU Stable Release Updates
<dholbach>     * Edit Description/Tags
<dholbach>     * Mark as Duplicate
<dholbach>     * Visibility/Security
<dholbach>     * Also Affects Upstream
<dholbach>     * Also Affects Distribution
<dholbach>     * Unsubscribe
<dholbach>     * Subscribe Someone Else
<dholbach>     * Comment/Attach File
<dholbach>     * Target to Release
<dholbach>     * Add Branch
<dholbach>     * Link to CVE
<dholbach>     * Report a Bug in gnome-pilot in ubuntu
<dholbach>     * Activity Log
<dholbach> Search gnome-pilot (Ubuntu) bugs
<dholbach> Enter bug ID or keywords:
<dholbach> Show all open bugs
<siretart> dholbach?
<dholbach> Remote bug watches
<dholbach>     * gnome-bugs #362565 [RESOLVED FIXED]  (edit)
<Toadstool> uhuh
<LaserJock> argg, daniel spam
<dholbach> Bug watches keep track of this bug in other bug trackers.
<dholbach> Bug details
<dholbach> Bug #66355
<Ubugtu> Malone bug 66355 in gnome-pilot "gpilotd locks up my Palm Z22" [Unknown,Fix released]  https://launchpad.net/bugs/66355
<dholbach> Initial Reporter:
<dholbach> Fridtjof Busse
* ajmitch ducks the spam
<dholbach> Reported on:
<dholbach> 2006-10-16
<dholbach> Subscribers to bug 66355
<dholbach>     * Borden Rhodes
<siretart> yay, daniel spamming the channel ;)
<dholbach>     * Daniel Holbach
<dholbach>     * Fridtjof Busse
<dholbach>     * KenSentMe
<dholbach>     * Kolja Glogowski
<dholbach>     * MOTU Stable Release Updates
<dholbach>     * Matt Davey
<dholbach>     * Olivier Guerrier
<dholbach>     * Paul Roberts
<LaserJock> somebody should kick him ;-)
<dholbach>     * Phil
<somerville32> Someone should mute him, lol
<dholbach>     * Ubuntu Stable Release Updates Team
<dholbach> Also notified:
<dholbach>     * PDA Testers
<dholbach>     * Registry Administrators
<dholbach>     * Ubuntu Bugs
<dholbach>     * Ubuntu Desktop Bugs
<dholbach> oooooops
<dholbach> SORRY
<dholbach> lalalalalalala
<dholbach> https://launchpad.net/ubuntu/+source/gnome-pilot/+bug/66355/+activity <- bottom
<LaserJock> hahaha
<Toadstool> :)
<sistpoty> dholbach: ah, nice
<somerville32> Is it... over?
<somerville32> lol
<ajmitch> LaserJock: so what do we need to argue about/discuss at a meeting?
<ajmitch> schedule, revu progress, sru, what else?
<LaserJock> task lists
<siretart> dholbach: the last meeting, we decided to abandon REVU in favor of launchpad's bzr branch hosting, is that correct?
* ajmitch can't find the most recent minuts
<LaserJock> well, I don't know about abandon exactly
<ajmitch> s/minuts/minutes/
<dholbach> siretart: to give it a spin and see where issues are
<dholbach> siretart: today I thought that we could add the tarballs to a tarball/ dir in the branch - that'd solve a bunch of problems
<somerville32> revu isn't that bad
<ajmitch> some people have been burning through REVU
<ajmitch> having each package uploaded being announced on -motu has been good
<siretart> dholbach: I uploaded bzr-builddeb a couple of minutes ago. that might faciliate managing the packages
<dholbach> i really think the bzr aspect will help a lot
<dholbach> ah nice
* dholbach hugs siretart
* siretart agrees to ajmitch. it is really nice to see those mails
<ajmitch> oh, I see someone updated the murrine package I did on revu
<LaserJock> yeah, I think the email to -motu thing has been pretty cool
<dholbach> yeah we should stick to that - whatever we do :)
<ajmitch> good, since it was a rushed package anyway :)
<ajmitch> knowing what other people are doing & seeing some activity is always a good thing
<LaserJock> I think Ubuntu Studio is using it for their default engine or something
<siretart> dholbach: did we already process some NEW package via bzr?
<bddebian> ajmitch: You've been REVU'ing again? W00t :)
<siretart> dholbach: I'd like to know what to do with revu. shall we shut it down?
<LaserJock> no, please don't do that
<bddebian> siretart: Why shut it down?
<LaserJock> we need to get the contributors to move to bzr before we shut REVU down
<ajmitch> bddebian: no
<bddebian> If you move to bzr I quit :)
<somerville32> lol
<Lutin> heh
<LaserJock> dholbach: I'm a little concerned about the size of a tarballs bzr branch
<somerville32> I think revu is good myself too. Maybe encourage motu-hopefuls to help do unofficial reviews I find is very helpful.
<LaserJock> dholbach: I've been working with the Ubuntu Studio guys a bit on using bzr
<somerville32> It gets the package to a point where the real motus just need to take a look, check, and upload
<LaserJock> I suggested the put a file in the root of the bzr branch that has the URL to the tarball
<dholbach> LaserJock: nice
<LaserJock> somerville32: we are thinking that perhaps bzr would be faster for that
<dholbach> LaserJock: I'm sure it'll work out
<somerville32> I guess I'm not really sure how this whole bzr thing is suppose to work or how it is better then revu.
<LaserJock> somerville32: contributors would just push a bzr branch of debian/
<LaserJock> somerville32: potentially other contributors could help out
<somerville32> debian/ is only a part of the checklist
<ajmitch> run a script to grab the package, run some simple checks on it like revu-report
<somerville32> And the rules script, a lot of the time, depends on what is provided in the source for configuring, installing, etc.
<LaserJock> the only thing I could see if more than one "contributor" being able to commit is if people "disagree" and we have bzr wars
<somerville32> What about patches to the source?
<Lutin> one good thing with revu is that it's way easier to review a whole diff than all the files in debian/ independantly
<somerville32> right
<siretart> bddebian: in order to urge contributors to get used to bzr?
<dholbach> Lutin: you have   bzr diff    too
<LaserJock> Lutin: bzr diff
<siretart> no, I'm happy with revu running, actually
<Toadstool> hmm, what about storing tarball information in a bzr "field" and have a MOTU bzr plugin? :)
<Lutin> LaserJock: he, thanks :)
<somerville32> I thought we wanted to encourage people to contribute to Ubuntu. I think adding to the stack of things they need to learn to get started would be detrimental to that effort.
<LaserJock> somerville32: we are trying to make it *easier* for both contributor and reviewer
<ajmitch> somerville32: if it's that hard, you could have revu create bzr branches on upload
<ajmitch> which I don't think would be very clean, but anyway
<LaserJock> anyway ... it's worth exploring
<LaserJock> other teams have used bzr/LP pretty sucessfully
<dholbach> yeah
<dholbach> it ROCKs :)
<LaserJock> the problem I see is getting people to try it
<dholbach> we need good tutorials :)
<LaserJock> and announcements that it's available :-)
<ajmitch> bzr is fairly easy to manage for most people
* LaserJock wants to add the Candidates list to the meeting agenda
<ajmitch> ooh, that page is a mess
<ajmitch> frequently ignored, it's a way for people to think they're being listened to, TBH
<LaserJock> I don't think it would be hard to make a product (ubuntu-candidates) or something that people can file bugs against
<ajmitch> how many people do you know pick packages from there?
<ajmitch> agreed
<somerville32> +1
<LaserJock> s/ubuntu-candidates/universe-candidates/ or something
<Lutin> LaserJock++
<LaserJock> dholbach: what do you think?
<ajmitch> it's not the best solution, but it could work
<somerville32> What about helping more people become motus? More man power the better, haha
<ajmitch> it allows comments on bugs
<ajmitch> somerville32: yes, but help them out in what way?
<LaserJock> ajmitch: what would be better?
<ajmitch> LaserJock: I don't know :)
<somerville32> ajmitch: The same way loco teams help their members become Ubuntu Members
<LaserJock> somerville32: we also need quality as well as quantity
<LaserJock> somerville32: we do a rather large amount of helping people, perhaps we need to be more efficient
<ajmitch> somerville32: that's incredibly vague
<somerville32> ajmitch: On purpose, lol
<bddebian> We need more drugs! :)
<LaserJock> ajmitch: wnpp seems to kinda work for Debian
<somerville32> Indeed.
<LaserJock> bddebian: bugs? ;-)
<dholbach> LaserJock: sure, add it
<LaserJock> dholbach: to agenda or just do it :-)
<ajmitch> LaserJock: Just Do It!
<ajmitch> ubuntu-universe-candidates, or is that too long for people?
<dholbach> :)
<ajmitch> add a note to the top of the wiki page, tell them where to add stuff
<somerville32> LaserJock, ajmitch: Maybe we could create a page or a team that motu-hopefuls could join so that MOTUs could take specific interest in them (ie. delegating work, giving advice, etc.)
<LaserJock> ajmitch: sounds good
<ajmitch> a team may be nice, but it doesn't have the personal contact that is often needed to help people
<LaserJock> somerville32: I think task lists in general are a good thing
<ajmitch> part of what the council is meant to do is task lists
<ajmitch> since the rest of us have been too slack to write some up in the meantime :)
<LaserJock> I tend to think that there shouldn't be so much a seperate between Hopefuls of MOTU in what they work on
<LaserJock> only that Hopefuls need sponsorship
<LaserJock> we should have "Junior Jobs" for new people, but if you want to be a MOTU you should be doing MOTU things
<ajmitch> "junior jobs" == writing LaserJock's thesis as he hacks on ubuntu :)
<LaserJock> heck yeah!!
<somerville32> LaserJock: I think it had to do with the obligation of being a member of an official team or what not
<somerville32> I dunno
<somerville32> lol
<LaserJock> hmm, well the revu team would be sort of like that
<somerville32> for me, I want to become a MOTU but I have no idea when I should apply
<Toadstool> yet another team? we have ubuntu-universe-contributors don't we?
<LaserJock> somerville32: usually MOTUs will start telling you should go for it
<ajmitch> part of what we discussed at UDS - telling people that they should apply, rather than them guessing
<somerville32> and I think it is safe to say that MOTUs would be interested in assisting motu-hopefuls become quality contributors.
<somerville32> LaserJock, But are MOTUs actively thinking "who should we tell to apply today?"
<LaserJock> yes
<LaserJock> I'm daily evaluating everyone in here :-)
<ajmitch> somerville32: they'd be working with someone & telling them to apply
* ajmitch hopes he passes
<LaserJock> it's iffy some days ;-)
* ajmitch hangs up his keys
<LaserJock> hehe
<LaserJock> Toadstool: I agree, we have a rather large amount of MOTU related teams
<LaserJock> I think our bzr review team could be considered MOTU Hopefuls
<LaserJock> somerville32: I'm just a bit hesitent at adding more layers
<LaserJock> if we have an "official" MOTU Hopeful level then we need to have an evaluation of whether a person is a MOTU Hopeful or not
<ajmitch> yay bureaucracy
<LaserJock> we really need to keep our processes trim
<somerville32> Maybe just a process of mentorship? I think it would be easier to identify individuals ready to apply for MOTU status if there was someone specifically working with an individual.
<somerville32> I think that the wiki already mentions this
<somerville32> but it doesn't actually occur
<LaserJock> somerville32: no offense, but how do you know? We regularly encourage people to go for MOTU
<Toadstool> motu-{uvf,sru,council,hopeful-whatever-team} that becomes heck a lot of different teams and processes ;)
<LaserJock> the whole idea is that we are a team, and so the MOTU team mentors MOTU Hopefuls
<LaserJock> with the daily workload we have it can be a bit overwhelming if you have 5 Hopefuls relying on *only* you
<somerville32> LaserJock: I know it occurs because I've already been encouraged.
<LaserJock> it also give a broader range of opinion if you have the team's input rather than just one person
<somerville32> I'm just saying I think documentation on the wiki needs to be a bit more clear
<ajmitch> somerville32: if you know it happens, why did you say it doesn't occur?
<LaserJock> it's confusing at first, but the reality of packaging is that it's much more art than science
<LaserJock> somerville32: for sure, we do need better documentation
<LaserJock> and you are more then welcome to help with that
<ajmitch> somerville32: if we need better documentation, it's a hint for you to start writing :)
<somerville32> lol
<LaserJock> have we done any sort of review of various MOTU related LP teams?
<LaserJock> I guess the Council could do that
<sistpoty> LaserJock: I'm quite sure I asked you this almost 2 weeks ago already... but I forget: did you already upload rpy to edgy-proposed?
<LaserJock> sistpoty: yes
<sistpoty> LaserJock: ah, great... thx... I'll make a note to the bug ;)
<ajmitch> LaserJock: or we could just do it :)
<LaserJock> sistpoty: as far as I know it's either waiting for approval or in -proposed
<LaserJock> well, from my standpoint it seems like we have some bottlenecks
<sistpoty> LaserJock: not yet in proposed... I checked the whole contents of -proposed already
<LaserJock> sistpoty: grrr, it's been a couple weeks since I uploaded. Oh well
<LaserJock> one of our bottlenecks is approvals
<bddebian> and resources
<sistpoty> LaserJock: I'm just writing the sru-report... I'll try to find out where the bottleneck is ;)
<crimsun> as in u-a approvals?
<LaserJock> we can only process as fast as we get approvals
<LaserJock> crimsun: mostly right now
<crimsun> I'd like to think u-u-s and motu-sru are flying as smoothly as possible
<crimsun> then again I'm biased
<LaserJock> I think so to
<ajmitch> due to the superb efforts of certain people (thanks crimsun!)
<sistpoty> crimsun: iirc we had some downtime during the holidays... but in another half an hour, I'll have prove where the bottleneck in sru is 
<LaserJock> the other "bottleneck" in a sense is process documentation/ beauracracy
<LaserJock> people need to easy find the process to go through
<sistpoty> s/prove/proof/
<sistpoty> sheesh, I can't spell any longer... looking at bug number and dates makes me dumb *g*
<crimsun> Ubuntu clippy1
<geser> btw: is someone interested in doing a sru for bug #57951? it has already 13 dupes
<Ubugtu> Malone bug 57951 in xchat "xchat crashes frequently on quit" [Medium,In progress]  https://launchpad.net/bugs/57951
<LaserJock> it should be fairly obvious what a person is supposed to do for UVF, SRU, NEW packages, etc.
<LaserJock> along with that is having the status of these processes readily available
<LaserJock> SRU for instance is currently a bit troublesome
<crimsun> that's because we've managed to its hurdle higher than main's, surprisingly
<LaserJock> having to look through Sources files to find if a package is in -proposed yet is annoying
<crimsun> to make ^
<LaserJock> yep
<Adri2000> LaserJock: Seveas's edgy-changes rss feed is for you
<LaserJock> we should have status pages for UVF, SRU, merges/syncs
<Adri2000> s/'s/'/
<LaserJock> Adri2000: that doesn't help
<Adri2000> why?
<LaserJock> we need to see what's going on in -proposed
<Seveas> Adri2000, do they contain -proposed?
<Seveas> I don't think so :)
<Adri2000> I see for example k3d (0.5.12.0-1ubuntu2.1~proposed1)
<LaserJock> both what's yet to be accepted and what's in currently
<LaserJock> Adri2000: that's probably been uploaded to -updates that way or something, i don't know
<somerville32> The UWN is attempting to help with UVF, SRU, MIR, and all the TLA and ETLA processes we have by featuring them in the community spotlight, process of the week feature.
<LaserJock> we need something better than UWN
<LaserJock> UWN should be getting data from us
<Adri2000> LaserJock: no: https://lists.ubuntu.com/archives/edgy-changes/2006-December/008122.html "Distribution: edgy-proposed"
<somerville32> LaserJock, Such as?
<Adri2000> and afaik the rss feed uses edgy-changes mailing list
<LaserJock> somerville32: SRU, UVF, etc.
<Seveas> Adri2000, interesting. That should be made more clear in the feed
<LaserJock> Seveas: I'm still not sure that that is right
<Seveas> LaserJock, regardless of what you're looking for, it still should be made clear in the feed ;)
<LaserJock> true :-)
<Seveas> somerville32, process of the week sounds cool
<somerville32> :)
<somerville32> Mark's idea
<LaserJock> anyway, I somehow feel like we got offtrack (mostly likely by me)
<crimsun> (where are we in the TB agenda?)
<LaserJock> I don't know that we were going on the TB agenda
<LaserJock> more impromptu MOTU agenda
<somerville32> hehe
<LaserJock> I'm sort of interested in what people see as areas MOTU could improve on or streamline
<LaserJock> other than figuring out how to clone crimsun 
<LaserJock> ;-)
<Toadstool> which would solve a lot of our issues
<crimsun> that won't work at all (mythical man-month)
<Adri2000> LaserJock: improve merge-o-matic
<crimsun> .oO( heck, is anyone saying anything in -meeting? )
<somerville32> Maybe we could do a little walk through of how bzr will improve the work flow?
<Adri2000> crimsun: there is no TB today
<Adri2000> crimsun: mdz was the only one present
<crimsun> gah.
<LaserJock> Adri2000: well, we can certianly beg Keybuk for new features :-)
<Adri2000> I think assignee and comment fields would be really useful
<LaserJock> somerville32: well basically, people push their packages to the revu team on LP
<LaserJock> somerville32: then other contributors or MOTUs can comment on them or commit fixes, etc.
<somerville32> How exactly do they comment?
<LaserJock> hmm, can't remember how exactly that was proposed to be done
<crimsun> whiteboard, no?
<LaserJock> yeah
<LaserJock> somerville32: the spec is https://wiki.ubuntu.com/CodeReviewSLA
<somerville32> Isn't it possible to link a branch to a bug?
<somerville32> and bugs have better commenting facilities
<somerville32> Plus e-mail notification
<LaserJock> so is the general feeling that MOTU is running smoothly during Feisty?
<ajmitch> no
<LaserJock> ajmitch: do you see any particular problems?
* bddebian is sucking for feisty, that's 1 :)
<LaserJock> ok, burn out/lack of time for some MOTUs :-)
<ajmitch> apart from that
<ajmitch> part of the problem is identifying the problems :)
<LaserJock> well, that's what I'm trying to get down to
<ajmitch> things I'd like to see, like packages with RC bugs fixed in debian, that aren't fixed in ubuntu
<LaserJock> if we can identify specific problems we can come up with solutions
<ajmitch> since we always seem to suck at QA
<ajmitch> I have an idea of how to do that
<ajmitch> using the ldap bts interface
<ajmitch> but I need time/motivation, which I always lack :)
<LaserJock> ok, so the problem seems to be a lack of information about our packages and debian's, correct?
<ajmitch> that's part of it
<ajmitch> also bug triage, somethign for the bugsquad
<ajmitch> since we don't know what is _really_ broken until post-release
<Adri2000> bddebian: I've merged the last msttcorefonts, can you upload it?
<LaserJock> ajmitch: ok, so better testing and triaging
<bddebian> Adri2000: Did you break it? :)
<ajmitch> there was talk of automated testing being distro wide
<LaserJock> although I think that having a good idea of what bugs are in Debian would help
<ajmitch> dholbach knows a little more than I do about that
<Adri2000> bddebian: why? I never break anything :)
<ajmitch> knowing what's been fixed in debian is ever better :)
<LaserJock> done by Canonical people or us?
<LaserJock> of course ;-)
<dholbach> ajmitch: aha?
<dholbach> ajmitch: what is the question exactly?
<ajmitch> dholbach: you know much about the automated testing?
<dholbach> no
<dholbach> but iwj and pitti do
<dholbach> and lifeless probably too
<ajmitch> ah, I thought you talked about it a bit with them
<LaserJock> there seems, to me anyway, less priortization with bugs in Universe than in Debian
<Adri2000> bddebian: http://adrishost.homeip.net/~adri2000/ubuntu/toupload/msttcorefonts_1.7ubuntu1.debdiff
<ajmitch> mvo was doing some stuff with upgrade testing as well
<LaserJock> we don't really have an idea of, "OK, here are a set of RC bugs for Feisty"
<TheMuso> tepsipakki: You were looking for me?
<sistpoty> damn, motu-sru queue is *not* empty... still two packages that need reviewing
<crimsun> which?
<sistpoty> crimsun: bug #42269 and bug #76861
<Ubugtu> Malone bug 42269 in azureus "[SRU]  Does not create a tray icon" [Undecided,In progress]  https://launchpad.net/bugs/42269
<Ubugtu> Malone bug 76861 in spampd "[SRU]  spampd 2.30" [Undecided,In progress]  https://launchpad.net/bugs/76861
<Adri2000> crimsun: can I merge mplayerplug-in?
<crimsun> Adri2000: yes
<Adri2000> crimsun: ok, you wrote in the changelog "Does not install mplayerplug-in-gmp symlinks", but I don't see any gmp related change in mplayerplug-in_3.31-6ubuntu1.patch
<bddebian> Adri2000: Is that a diff against the Debian package?
<Adri2000> bddebian: yes, the last version in debian
<crimsun> sistpoty: 76861 uploaded, u-a subbed
<Adri2000> bddebian: debdiff 1.7 1.7ubuntu1
<sistpoty> crimsun: damn, I was almost done with sru-report :P
<sistpoty> crimsun: thx
<crimsun> Adri2000: that's correct. Debian's never did, so our merge obviously wouldn't.
<Adri2000> crimsun: actually you didn't change anything except s/iceweasel/firefox/ ?
<crimsun> Adri2000: correct. I always note a justification for closing a bug, however.
<Adri2000> ok :)
<ScottK> Is there a definitive answer yet about then name of the field to put the Debian maintainer in when I update a package with MOTU for maintainer?  One of my packages did a new release yesterday and I'd like to get it right for the update.
<Adri2000> not yet
<ScottK> Thanks.  Is X-Original-Maintainer: OK in the meantime?
<dholbach> ?
<Adri2000> it's better to don't change this field until we are sure of what we should do
<dholbach> just leave it as it is
<dholbach> it doesn't make to change it
<LaserJock> I think XBS-Original-Maintainer is what sounded like we might do
<dholbach> the fields are changed automatically - so ubuntu users don't mail the debian maintainers but our mailing lists
<Adri2000> dholbach: only for binary packages
<LaserJock> dholbach: mdz told me that we are supposed to change source packages manual
<dholbach> aha?
<LaserJock> dholbach: I sent out an email to -announce
<dholbach> i'll take a look at it
<LaserJock> although I don't know what exactly the field should be now
<bddebian> Uhm, that's a new one for me??
<bddebian> Rejected:
<bddebian> Upload is binaryful, but policy refuses binaryful uploads.
<bddebian> Upload is source/binary but policy refuses mixed uploads.
<bddebian> Oh, it uploaded the damn deb, wtf
<LaserJock> :-)
<white> does ubuntu policy say "source-only uploads only"?
<ajmitch> white: yes
<white> ah, wasn't aware of that
<Adri2000> crimsun: mplayerplug-in merge at bug 79648
<Ubugtu> Malone bug 79648 in mplayerplug-in "[Merge]  mplayerplug-in 3.31+main-1ubuntu1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79648
<persia> Toadstool: Regarding bug 32460.  It doesn't seem to have had much attention in the past while: what do you think about applying your patch and waiting for a bug about overflows to move towards a real solution?
<Ubugtu> Malone bug 32460 in supercollider "Uninstallable in dapper AMD64" [Medium,Confirmed]  https://launchpad.net/bugs/32460
<Toadstool> persia: the patch won't work anyway, remember? :)
<persia> Toadstool: At least with the patch, it compiles, and the only problem is communication.  I'm just thinking about trying to clean out the very old broken version, and wondered if a new broken version wouldn't be better.
<Toadstool> I don't know...
<Toadstool> nothing happened upstream about this issue?
<chillywilly> hi
<persia> Toadstool: Not that I have seen.
<chillywilly> anyone ever get xen to work in edgy?
<chillywilly> via the packaged kernels and utils
<ajmitch> no, it's just there to look nice
<zul> heh
* chillywilly slaps ajmitch around with a large halibut
<chillywilly> you deserved that one
<chillywilly> I was getting some error on my laptop about the kernel not being a proper executable or some whacky crap like that
<ajmitch> maybe you weren't doing it right
<ajmitch> followed the wiki page?
<ScottK> Another question: I believe that if I had read this: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html before I uploaded my first package, I'd have had less trouble with debian/copyright.  I think it should be referenced off of one of the MOTU wiki pages.  If someone would suggest which page would be best, I'll add it...
<ajmitch> ScottK: https://wiki.ubuntu.com/MOTU/Packages/Packaging/Tips
<ajmitch> there's a section on debian/copyright in there
<ScottK> Thanks.
<Toadstool> persia: can you prepare a debdiff so that I can review it and upload? I am at work right now, kinda busy
<persia> Toadstool: Sure.  Just wanted your input when changing my mind to use your code.
<LaserJock> ScottK: I think I also put some of that in the Packaging Guide
<Toadstool> persia: ok great! thanks :)
<sistpoty> upcoming sru-report, brand new with delay number...: http://paste.ubuntu-nl.org/1878/
<sistpoty> is it clear, what the numbers are about?
<sistpoty> <- can't write english tonight *g*
<ScottK> ajmitch: Thanks again.  Added.
<bddebian> Adri2000: msttcorefonts uploaded
<Adri2000> great!
<bddebian> Later gang
<persia> Toadstool: You already built a debdiff.  BTW, it looks like someone is trying to prepare a patch that upstream will accept (previous patches have been rejected as degrading performance for 32bit).
<Toadstool> trying to prepare or there is patch pending approval by upstream?
<Toadstool> +a
<persia> Toadstool: There's a couple newer mailing list threads about it, but nothing conclusive (and some months pending).
<Toadstool> hmm...
<persia> Toadstool: I think I found the problem.  Author reports "I don't really see a big need to run the language in a 64 bit address space, though." (http://www.create.ucsb.edu/pipermail/sc-dev/2005-November/009371.html)
<Toadstool> persia: http://www.create.ucsb.edu/pipermail/sc-users/2006-April/024798.html <-- there may be hope...
<persia> Toadstool: Yep.  That's one of the newer threads
<tsmithe> i've got a .bzr directory (for my bzr branch in ubuntustudio) in my package... how can i get it to not be represented in the diff?
<LaserJock> either remove it or use filterdiff, I think
<tsmithe> hmm
<LaserJock> s/remove/move/
<tsmithe> filterdiff?
<LaserJock> yep
<LaserJock> it's in patchutils
<tsmithe> cheers
<tsmithe> i'm going to sleep now - so night
<persia> Toadstool: I'm updating your patch to s/uint64/unsigned long/, which should reduce the impact.
<Toadstool> persia: ok, have fun :)
<LaserJock> yikes we're actually averaging around 1 month to get a -proposed upload accepted?
<ajmitch> hm, if there are packages that *should* be uploaded to -proposed, why haven't they, if the debdiff is there?
* tsmithe has quit ("Sleep")
* ajmitch heads off for lunch
<LaserJock> ajmitch: well, there is only 1 or 2 of those and I guess they are waiting for a MOTU to upload them
<sistpoty> ajmitch, LaserJock: one is waiting for a motu and the other one is from lamont (who should be able to upload for himself ;)
#ubuntu-motu 2007-01-17
<Lutin> siretart: could you have a look at http://revu.tauware.de/details.py?upid=4085 if you have some time ? It might be interesting for you, motumedia guys :)
* sistpoty is off to bed
<sistpoty> gn8 everyone
<LaserJock> cya sistpoty 
* somerville32 waves.
<imbrandon> 
<imbrandon> bzr branch imbrandons_brain
<LaserJock> ewww, I don't want to merge that one
<imbrandon> heh
<ajmitch> LaserJock: scary though
<chillywilly> ajmitch: when attempting to boot this Xen kernel I get: 'Error 13: Invalid or unsupportable executable format' (for the record)
<chillywilly> google tells me that the kernel image may not be compressed
* chillywilly uses file
<chillywilly> much different output with the xen image and one of the stock kernels
<imbrandon> ajmitch, have you installed any unmodified domains ( read: windows ) on xen yet ?
<ajmitch> I can't
<imbrandon> hum
<ajmitch> no cpu support for it
<imbrandon> ohh
<imbrandon> cruft
<imbrandon> i might be on ym own then
<imbrandon> my*
* ajmitch only has a slow old box, remember
<ajmitch> not one of these fancy new ones
<imbrandon> i figured that am2 had it
<ajmitch> it does
<ajmitch> mine isn't am2
<imbrandon> ohhh 
<imbrandon> man i'm just wrong all arround tonight
<ajmitch> I got my box a few months before am2 was out
<imbrandon> ahh
<imbrandon> mine has it and enabled in the bios
<ajmitch> have fun then
<imbrandon> i'm debating weather to do a fresh xen minimal install and a few domu's
<jdong> is it just me or is XFS in Edgy a lot more flaky?
<jdong> I had one bad shutdown today on a XFS box and it ended up sending 10,000 files into /lost+found
<jdong> fortunately it was a newly imaged system with no items of sentimental value
<ajmitch> sigh
<ajmitch>    * Merge from Debian unstable. Ubuntu changes:
<ajmitch>       - See 1.5ubuntu1
<ajmitch> that's *not* how it should be done
<somerville32> lol
<somerville32> Who did that?
<ajmitch> I'm not going to point fingers
<ajmitch> since it's someone in here
<somerville32> lol
<imbrandon> wow
<imbrandon> thats special
<imbrandon> ajmitch, did you atleaste poke them in private ( so they are aware )
<imbrandon> heh
* LaserJock goes to check his changelogs ;-)
<ajmitch> no
<crimsun> it was me!!
<somerville32> So thats how crimsun does it so fast :
<somerville32> He cheats :P
<imbrandon> heh
<ajmitch> as if crimsun would
<imbrandon> hum this is gonna take a while
<persia> cd ..
<imbrandon> hum whats the s bit on rwxrwxrwx ?
<imbrandon> e.g. drwxr-sr-x 6 brandon brandon 160 2007-01-16 18:42 feisty-security
<persia> imbrandon: 0 (0777)
<persia> imbrandon: rewxr-s-r-x is 2777
<imbrandon> hum ok
<imbrandon> i have a feeling this rsync is gonna take a while
<ajmitch> I thought you were on a super-fast connection & all
<imbrandon> yea but even on a superfast connection 110GB is alot
<ajmitch> is this an initial rsync?
<imbrandon> yea
<imbrandon> i was using apt-mirror , now i'm converting to a full rsync
<somerville32> Are you creating a mirror?
<imbrandon> somerville32, i've had a mirror for quite some time
<somerville32> imbrandon, Do you have an Xubuntu mirror?
<imbrandon> i have one on ym local lan and i have a public one
<ajmitch> right, I was going to say that it'd cause a large load to do the whole thing by rsync
<ajmitch> these people, always trying to push xubuntu
<imbrandon> somerville32, i will after this rsyc finishes 
<LaserJock> somerville32: xubuntu is in Main, if he has Main he's got xubuntu
<imbrandon> right
<somerville32> Oh, you're syncing the repository
<imbrandon> i have edgy feisty currently
<imbrandon> somerville32, yes
<ajmitch> that is the most useful thing to sync
<somerville32> imbrandon, Did you ever finish setting up the build machines?
<ajmitch> it's not like there's 110GB of cd images
<imbrandon> somerville32, this is the last step
<crimsun> imbrandon: do you have my ponies?
<imbrandon> crimsun, hehe
<ajmitch> crimsun: sent to the knackers
<crimsun> gah
<imbrandon> glue ?
<ajmitch> yep
<imbrandon> ouch
<ajmitch> glue & dogfood
<LaserJock> hmm, so I have 3 Ubuntu machines using Edgy and Feisty, and on 2 networks. What's the best way to reduce redundant downloads
<ajmitch> don't dist-upgrade often
<Toadstool> aptoncd :)
<ajmitch> I use apt-proxy, which is adequate
<LaserJock> well, it's usually the pbuilders
<imbrandon> LaserJock, local mirror ;)
<ajmitch> but not great
<imbrandon> if you have 40gb of space you can run a edgy + feisty + source mirror 
<imbrandon> with apt-mirror
<imbrandon> for one arch
<ajmitch> I should consider doing that at home
<LaserJock> hmm, that's not bad
<ajmitch> except that I don't have many machines
<ajmitch> and 2 archs
<imbrandon> ajmitch, its about 12gb for each extra arch
<LaserJock> I've only got 1 arch and I'd probably don't need source
<persia> uqm has two packages.  uqm-content is under CCA-NC-SA, and uqm is under GPL.  uqm depends on uqm-content.  Is it safe for the .desktop and menu files in uqm to point to files provided by uqm-content (this will cause a lintian error)?
<LaserJock> the .desktop and menu files point to stuff in -content?
<imbrandon> why isnt the .dsktop in -content then ?
<persia> LaserJock: Not currently, but there is a bug that uqm doesn't appear in the menu, and I'm fixing it.  I'd rather use icons, but all the content is under the other license.
<persia> imbrandon: I can put the .desktop there, but the menu file is provided by debian in uqm, and I'd rather not move it.
<LaserJock> persia: but it shouldn't point to the specific icon should it
<imbrandon> hrm
<imbrandon> xen or no xen
<ajmitch> whatever you feel like
<persia> LaserJock: The menu file needs to point to a specific icon.  The .desktop file uses a basename, and the icon is selected by the xdg magic.
<imbrandon> hrm can i run a 32bit xen dom0 and a 64bit domU ?
<ajmitch> not afaik
<imbrandon> hrm
<ajmitch> it may be different with hardware virt, who knows?
<imbrandon> true
* imbrandon just found a cf to ide reader in his desk drawer
<imbrandon> s/reader/converter
<imbrandon> uptime
<ajmitch> seems like you'd need 64-bit dom0, and hardware virt for 32-bit domU
<imbrandon> err
<ajmitch>  14:01:45 up 9 days, 15:24,  4 users,  load average: 0.17, 0.18, 0.11
<imbrandon> 19:02:42 up 36 days,  9:45,  4 users,  load average: 0.08, 0.10, 0.07
<ajmitch> yeah, I rebooted it at about 200 days :)
<imbrandon> heh that sucks
<somerville32>  21:03:37 up  7:52,  3 users,  load average: 1.03, 0.97, 0.95
<imbrandon> we had one at work at 470+ days
<imbrandon> that had to be rebooted like a week ago
<imbrandon> it sucked
<ajmitch> it was just the box with the dsl modem at home
<ajmitch> so nothing big
<ajmitch> lucky I could fix up my RAID problems yesterday on the work server without taking anything down
<imbrandon> ;)
<imbrandon> if i could get the nic1000 working on this mb i would be happy
<imbrandon> then i coudl put a sata raid card in and have more hdd's
<ajmitch> sigh, looks like it's time to plug in this mp3 player
<ajmitch> battery running down again
<imbrandon> as it is the only slot i have free to do it has the pci nic replacement
<ajmitch> s/down/flat/ :)
<imbrandon> i broke my ipod the other day
<imbrandon> no more ipod for brandon , not for a few weeks
<imbrandon> i'm gonna wait to see how these new iphones look
<imbrandon> and possibly get one of those instead of a new ipod
<ajmitch> waste of money
<imbrandon> well $250+ on ipod, $200 on a phone , thats only $50 more dollars for a iphone
<imbrandon> so really about the same price
<imbrandon> plus pda and video stuff
<LaserJock> $200 for a phone?!?
<LaserJock> I only get the free kinda ;-)
<LaserJock> -a
<imbrandon> heh my last one ( about 3 weeks ago ) was about $179 + taxes etc
<LaserJock> ouch
<chillywilly> so you guys that have used xen before, did you build it from source or what?
<imbrandon> just get it from the repo
<imbrandon> most of the time
<chillywilly> can't boot the kernel
* persia proceeds to make an ugly .desktop file pointing at specific icons in -content.
<imbrandon> heh then file a bug ;)
<chillywilly> gives me grub error 13
<chillywilly> ok, I could do that but that doesn't help with actually getting it to work...I am forced to build it from source now
<ajmitch> you haven't given terribly much info
<ajmitch> build it from source if you wish
<imbrandon> and fwiw grub error 13 normaly is just an error in the grub menu entry
<ajmitch> oh look
<ajmitch> Linux ephraim 2.6.17-6-generic-xen0 #3 SMP Mon Oct 16 06:15:23 UTC 2006 i686 GNU/Linux
<ajmitch> I do have my laptop running xen
<imbrandon> hehe
<imbrandon> x86 xen
<imbrandon> ;)
<ajmitch> I think that's because all the other kernels were failing badly
<ajmitch> sure
<ajmitch> the laptop is old & decrepit
<imbrandon> ahh ;)
<ajmitch> only a pentium M
<imbrandon> thats still nice
<imbrandon> anything above 1ghz is OK to me
<ajmitch> 1GB RAM, enough to run 1 or 2 domUs
<ajmitch> this one is 2GHz
<imbrandon> ;)
<imbrandon> i was on that 2.9 celeron for a LONG time
* imbrandon likes his new box
* ajmitch has to make do with slow old boxes
<Mez> how long does soyuz take to process new uploads nowadays?
<ajmitch> define 'new'
<imbrandon> as in NEW queue or just an normal upload ?
<LaserJock> NEW new or just new new ? ;-)
<Mez> not NEW
<LaserJock> heh
<ajmitch> or NEW NEW new
<imbrandon> lol
<Mez> just a "until I get some sort of email back"
<imbrandon> depends on the upload i think it does it at 3 and 33 
<ajmitch> aha, I knew it! ;)
<Mez> I noticed kxmame had no depends on xmame
<ajmitch> depends on if you stuff up the upload as well
<LaserJock> "I've got a new upstream upstream release that I'd like to get uploaded to NEW new"
<ajmitch> don't confuse the poor chap
* Mez cries
<Mez> lol
<Mez> never mind
<imbrandon> heh
<Mez> I got the email
<Mez> I thought that with my mail server being stuffed up and now delivering me stuff from november,
<Mez> I might have to wait till april
<ajmitch> ok
<ajmitch> & it'll hopefully build & maybe even be published within an hour
<Mez> ajmitch, tis cool - just wanted to get an email back to make sure I hadnt stuffed the upload ;)
<ajmitch> immortalised on feisty-changes
* Mez growls
<Mez> I cant rememebr my mailing list password to re-subscribe
<Mez> (aka turn off vacation mode)
<imbrandon> heh
<imbrandon> vacation mode == procmail to /dev/null
<imbrandon> ;)
<LaserJock> ah man, I got screwed on TA assignments
<Mez> imbrandon - or nomail on to the mailing list request thing
<imbrandon> hum food , bbiab
<LaserJock> I've got grading/proctoring/ and the stupid computer lab :(
<ajmitch> lucky LaserJock!
<ajmitch> no ubuntu time for you
<Mez> and the "request password" doesnt work
<LaserJock> ajmitch: maybe I'll sepnd my computer lab hours building an Edubuntu lab :-)
<ajmitch> heh
<LaserJock> think of the pbuilder cluster I could have :-)
<LaserJock> I think there are ~10 p4s in there
* Mez bangs head
<Mez> I just found an old welcome email
<Mez> and the bloody thing doesnt work
<LaserJock> Mez: have you changed addresses?
<Mez> no
<Mez> Welcome to the Ubuntu-burning@lists.ubuntu.com mailing list!
<ajmitch> blame the circus midgets
<Mez> You must know your password to change your options (including changing
<Mez> the password, itself) or to unsubscribe.  It is:
<Mez> and the password it gives ther e(and in the 5 copies i have of it)
<Mez> doesnt work
<Mez> A reminder of your password has been emailed to you.
<Mez> no it hasnt1
<ajmitch> oh well, you'll live, resubscribe
<Mez> I need ym p/w to unsubscribe dont it ?
<shawarma> Mez: No. Just ask to unsubscribe and click the link in an e-mail you get.
<Mez> yeah - but abive it says I need it
<shawarma> abive?
<Mez> above
<Mez> hmm
<Mez> seems fiordland is avoiding me
<shawarma> Ah.. I'm a bit slow right now. :-)
<shawarma> I'm having trouble with mailman these days, too.
<Mez> ubuntu mailman /
<shawarma> Yes.
<Mez> ah kk
<ajmitch> complain to canonical people
<shawarma> It's discarding my mail to a particular list.
<Mez> it seems that mail isnt getting to fiordland.
<Mez> as it's sending it fine from gmail to my ubuntu accounty
<bddebian> Heya gang
<imbrandon> heya
<bddebian> Hi imbrandon
<ajmitch> hm
<bddebian> hmm
* bddebian hugs ajmitch
<Toadstool> re
<bddebian> wb Toadstool
<Toadstool> hey bddebian 
<ajmitch> yeah..
<Toadstool> great... received my plane ticket for September... I don't want to go back to France :/
<zul> because they speak french?
<imbrandon> heh
<Toadstool> nope, because i love California :)
<bddebian> Ugh
<zul> i rather be in france then california
<Toadstool> that's because you're not french
<imbrandon> i'd rather be in spain than anywhere ;)
<zul> yeah but my father speaks french
<Toadstool> yay! barcelona :)
<bddebian> Well I'd pick California over France but Cali still sucks :-)
<Toadstool> argh
<Amaranth> i wanna go to live in canada
<bddebian> Canukistan?  Why? :)
<imbrandon> canada ? people live there?
<Amaranth> http://en.wikipedia.org/wiki/Vancouver_Island <--i wanna go there
<zul> Amaranth: there is a lot of snow on vancouver island this year
<Amaranth> really?
<zul> yeah el nino
<Amaranth> oh
<ajmitch> NZ > *
<Amaranth> well it was 70F here right before the end of the year
<Amaranth> so i guess i can see that
<bddebian> El Nino?  hah, I thought Global Warming was causing everything? :)
<imbrandon> lol
<zul> heh its suppose to get -24C tonight
<Toadstool> ajmitch: well my next trip will most probably be to NZ and/or Australia
<imbrandon> jesus
<Amaranth> bddebian: you can blame everything on either el nino or global warming
<Amaranth> zul: here too
<bddebian> Amaranth: Bah, I just blame ajmitch :-)
<ajmitch> it's never got down that cold in NZ
<ajmitch> bddebian: that's ok, give me more excuses
<Amaranth> current temp is -14C
<Amaranth> windchill is -22C
<Amaranth> and it's only 8p
<bddebian> ajmitch: excuses for what man?
<ajmitch> bddebian: whatever I feel like doing
<bddebian> ajmitch: Ah ;)
<Amaranth> zul: my cold weather scared you away? :)
<ajmitch> bddebian: I've still got a list of things to harass you about
<bddebian> haha
<zul> er...yeah
<bddebian> ajmitch: Uh oh, what'd I do now?
<ajmitch> breaking stuff
<bddebian> Now what did I break?
<ajmitch> sponsoring stuff that should have been looked at first, too
<bddebian> Are you going to be more specific?
<ajmitch> maybe
<persia> My keyboard doesn't work in yet a different way today.  Anyone have any pointers to where I should add the definition for this keyboard to prevent this recurring? (it's Logitech jp106).
<zul> yeah #ubuntu
<persia> zul: Noone has ever had an answer to that question there in the past two years.  Oh well, I'll go play with keytouch and xkb, and see if I can find it.
<bddebian> ajmitch: Well?
* bddebian stops doing anything until ajmitch explains himself
<chillywilly> yay
* chillywilly has xen running on this laptop
<imbrandon> bbiab, time for a clean install
<GreenD> Hey
<GreenD> Anyone willing to lend me a hand creating a package right quick?
<sladen> GreenD: how far did you get? :)
<GreenD> Haha, not too far right now. Want a run down of what I'm trying to do?
<sladen> https://wiki.ubuntu.com/MOTU/Documentation  has lots of ideas from the basics upwards
<sladen> basically, (if it's not already packaged in Debian), we grab the source as a tarball
<sladen> unpackage it, add a 'debian/' directory containing several special files (debian/control, debian/rules)
<GreenD> Well, basically I just want help to where it will install from source on ubuntu, then I'll deb it. :)
<sladen> 'rules' is normally an executable make file that would then call 'make' and put binaries in the right place
<TheMuso> tepsipakki: Please PM me if you need to contact me, that way I can be sure I get your message even when I am online. Thanks.
<GreenD> Eh, let me explain my problems so far...
<sladen> 'control' lists information such as the package name, version, who uploaded it.
<GreenD> I'm wanting to make a debian package for scatterchat for Hacktivismo, but whenever I try to configure from source its not liking my GTK version even though its up to date. (What do I do there?) Theres too much stuff that overrides gaim, should I make everything separate and how? Mind you Scatterchat may be based off of gaim but it is not just a plugin.
<GreenD> Joseph Salvatore isn't able to give me much help on it because he did this on Fedora, so I came here.
<GreenD> Any ideas?
<GreenD> Also, scatterchat comes in two pieces. The main piece (Like gaim.) and the scatterchat module, can we make those two into one package?
<Marsmensch> hmmm, something's wrong with my ubuntu... by using firefox for surfing the cpu frequency steps up to max, and i can't work with other applications ... since 1 or 2 month i think
<GreenD> Change the nice values for it then.
<GreenD> Might help.
<Marsmensch> ok i try :) thx
<GreenD> No problem man, hope it works. Sometimes certain 'flashy' things I might have running in or as part of firefox make my pent 4 schiz out.
<GreenD> Well, this is gay. I'm out.
<ScottK> Any MOTUs available?  I have an updstream update to which I've added additional documentation (including man pages)?  bddebian?
<Mez> ScottK, sup ?
<Mez> ScottK, simple 2 questions
<Mez> 1) what package
<Mez> 2) is it in REVU
<bddebian> ScottK: Sorry, I'm not supposed to work on stuff 
<ScottK> OK.  No problem.
<ScottK> Mez - Sorry - bran dump.  It's in REVU - http://revu.tauware.de/details.py?upid=4086
<Mez> bddebian, what have you done now /
<ScottK> bran/brain - can't type either tonight..
<bddebian> Heya Mez.  Dunno, ajmitch won't tell me
<Mez> lol
<Mez> was it that currant bun you left lying on the buildd the other day ?
<bddebian> currant bun?
<Mez> nvm
<Mez> ScottK, couple of things i've noticed straight off
<Mez> 1) pyspf source: newer-standards-version 3.7.2
<Mez> oh, nvm 
<Mez> i read that wrong
<Mez> and what the hell
<Mez> where did that lintian error come from
<ScottK> Dunnu.  I always see that when I look at lintian on REVU, but not when I run it locally.
<Mez> that one is fine
<Mez> revu needs updating
<Mez> but the
<Mez> W: pyspf source: build-depends-without-arch-dep
<Mez> is very confusing
<ScottK> Hmmm.  I didn't get that one when I built it here.
<Mez> I guess it's just a glitch on REVU
<ScottK> I suspect that may be a function of revu not being updated for the new python policy.  That's unchanged from the previous upate I got approved.
<Mez> probably not worht adding a lintian override for it
<Mez> siretart, can you update revu ?
* ScottK goes to update another package and fix a packaging bug.
<chillywilly> there's no pygrub in edgy?
<Mez> thats a PITA
<chillywilly> how else can I boot this domU then? I was just following some instructions on a wiki
* ScottK waits on REVU...
<LaserJock> persia: got a sec for bug 79498
<Ubugtu> Malone bug 79498 in libjsw "new upstream version 1.5.6" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79498
* ScottK rebuilds the package again...
<LaserJock> oh my gosh, that xchat crash bug is insane
<ScottK> OK.  I think it's good now.  I fixed Debian bug #306875 by implementing the patch supplied with the bug.  I'd appreciate a revu: http://revu.tauware.de/details.py?upid=4088 and 4086 is waiting too if anyone is feeling ambitious...
<Ubugtu> Debian bug 306875 in spfquery "spfquery: conflict with libmail-spf-query-perl (spamassassin)" [Normal,Open]  http://bugs.debian.org/306875
<LaserJock> ScottK: that's a bug fix?
<persia> LaserJock: Sure.  What about it?
<ScottK> Yes.
<ScottK> Updated the package to support the alternative implementations of spfquery.  The other two in the archives already support it.  This was the last one left.
<LaserJock> persia: there's a lot going on there
<ScottK> Not that I added.
<persia> LaserJock: Yes, indeed.  libjsw doesn't get a lot of maintenance in Debian :(
<LaserJock> ScottK: usually bugs are done as a debdiff attached to a bug report
<ScottK> Oh.
<persia> ScottK: cf bug 60290
<Ubugtu> Malone bug 60290 in battleball "shows only on debian menu, not games menu" [Undecided,Unconfirmed]  https://launchpad.net/bugs/60290
<ScottK> I thought that got a bug reported.  I was trying to go straight to fixed.
<ScottK> So I should take the debdiff from this and attach it to a new bug referencing the Debian bug?
<ScottK> I did fix one small lintian warning that's not part of the bug (added Section to the control file)?
<chillywilly> bah
<ScottK> LaserJock: I've reported bug #79683.  Is that right?
<Ubugtu> Malone bug 79683 in libspf2 "spfquery: conflict with libmail-spf-query-perl Debian bug#306875" [Unknown,Unknown]  https://launchpad.net/bugs/79683
<LaserJock> ScottK: why did you change libspf2-1.2.5/src/libspf2/spf_lib_version.h >
<LaserJock> s/>/?/
<ScottK> I didn't.
<ScottK> I didn't even open the file.
<LaserJock> ScottK: generally you provide a little more descriptive description for the bug, but yeah
<ScottK> OK.
<ScottK> I didn't touch anything outside /debian.
<LaserJock> ScottK: check that debdiff
<LaserJock> unless I've suddenly lost the ability to read a diff (which is possible)
<ScottK> As I read it, it's a diff against orig and we are already on -4 from Debian.  I think that's a previous patch...
<ScottK> --- libspf2-1.2.5.orig/src/libspf2/spf_lib_version.h
<ScottK> +++ libspf2-1.2.5/src/libspf2/spf_lib_version.h
<LaserJock> ScottK: debdiff against the base Debian version
* ScottK goes to read man debdiff again.
<LaserJock> when I go to apply a patch I grab the Debian version then add the sponsoree's debdiff
<LaserJock> it's much smaller for new upstreams, etc.
<LaserJock> and keeps our divergence as low as possible
<persia> LaserJock: Just to confirm, doesn't that only apply for source that has yet to have an Ubuntu delta, with debdiff against latest Ubuntu generally preferred?
<LaserJock> if you are going from one ubuntu version to the next, yeah
<LaserJock> just think about the least diff
<LaserJock> and what version you are basing you're work on
<LaserJock> if you're going from ubuntu1 to ubuntu2, then debdiff between those
<LaserJock> if you're going from Xubuntu1 to Yubuntu1 then debdiff between Y and Yubuntu1
<ScottK> From reading man debdiff, I debdiffed the two dsc files, debdiff libspf2_1.2.5-4.dsc libspf2_1.2.5-4ubuntu1.dsc - I'm guessing that's wrong.  Which to files should I be debdiffing?
* ScottK reads again.
<LaserJock> no, that should be right
<ScottK> Part of the patch I was applying from the Debian bug included adding a compat file: http://bugs.debian.org/cgi-bin/bugreport.cgi/libspf2-1.2.5-spfquery-update-alternatives.patch?bug=306875;msg=12;att=1 
<ScottK> I looked and the date stamp on spf_lib_version.h is consistent with me having added it.
<ScottK> Could debhelper have done me the favor of putting in there?
<persia> LaserJock: I must run off.  Catch me later about libjsw (or comment on the bug, or email me).
<LaserJock> ScottK: I really don't know
<LaserJock> I would try to redo it in a seperate dir to see if it's the Debian patch or you
<ScottK> It looks to me on further inspection like it was added by debuild or dh or ... something else in the toolchain.  File ownership is consistent with that.
<ScottK> It's not there in the 1.2.5-4 debian source package.
<ScottK> It was definitely added when I built the package and I didn't do it manually.
* ScottK looks to the tools...
<ScottK> I need to go to bed.  I'll look into it again when I have time.
<ScottK> Assuming that this diff is good, how would the process go from here?
<LaserJock> ScottK: subscribe it to ubuntu-universe-sponsors
<LaserJock> and some MOTU will upload it
<ScottK> OK.  Thanks.  I'll look at it again and if I think it's OK, I'll do that.
<ScottK> Appreciate the help/training.
<imbrandon> gnight all
<LaserJock> cya imbrandon 
<LaserJock> crimsun: you around? I have a question on bug #79555
<Ubugtu> Malone bug 79555 in Ubuntu "please sync pychess 0.6.0.beta5-1 from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/79555
<tepsipakki> adri2000: please put all the changes in the merge-changelog, not just a pointer to a previous version :)
* Starting logfile irclogs/ubuntu-motu.log
<Mez> what's the sync request process nowadays ?
<Lutin> file a bug tu ask a sync, mentioning in what component it is in debian
<Lutin> if possible check if the package builds fine
<Lutin> and subscibe ubuntu-universe-sponsors or main-sponsors depending on the component
<Mez> Lutin, It's cool - it's a package I maintain in debian 
<Mez> so it's easier just to sync from debian
<Mez> rather than having entries like
<Mez>   * Fix Maintainer Field to currect maintainer (1:3.5.4-1 was not synced from debian)
<Mez> in the changelog
<palski> SRU needing sponsorship Bug #79059, please
<Ubugtu> Malone bug 79059 in gnome-hearts "[SRU]  gnome-hearts crashes on startup (edgy)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79059
<Lutin> Mez: if it's a sync you don't have to do anything - just file a bug and ask it
<Mez> Lutin, already done #80202
<Mez> bug 80202
<Ubugtu> Malone bug 80202 in rar "Please sync rar 3.6.0-1 from debian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80202
<Lutin> hehe, cool :)
* Mez wubs it when he gets mail from katie
<siretart> Mez: update revu?
<siretart> morning
<Mez> siretart: well... lintian is out of dat
<Mez> e
<Mez> I'm guessing revu-build builds against edgy still
<Mez> etc etc
<siretart> ah, the system in the outside.
<siretart> hm, well, currently tiber is running dapper with breezy kernel, because dapper kernel is not able to bring up the network interfaces
<siretart> which is.. hmm. bad
<Mez> siretart: but ... still... surely you can update some stuff...
<Mez> or at least make the scripts run in a chroot or something
<Mez> so that it doesnt give dodgy lintian errors
<siretart> hm, need to think about it how to integrate it with the rest of the revu toolchain
<Mez> true, but something needs to be done...
<Mez> it's not pretty (imho)
<raphink> Mez: revu-build should build against feisty
<raphink> there is  feisty pbuilder
<raphink> on tiber
<raphink> I confirm that revu-tools is set to build for feisty Mez, just checked
<Mez> ah yes it does
<Mez> (same here)
<raphink> the lintian errors don't come from the pbuilder
<raphink> they come from the version of lintian (and linda of course) on the system
<raphink> the solution to get rid of them is simply to backport lintian/linda on the machine
<raphink> which should be fairly quick to do
<Mez> raphink, specially with prevu
<Mez> ;)
<raphink> prevu?
<Mez> hehe
<raphink> what is that?
<Mez> meuahaha :D
<Mez> it's an auto-backporter
<raphink> ah
<raphink> well for lintian, I'm guessing pbuilding with an edgy pbuilder the fesity package should do
<raphink> an dsame for linda
<raphink> lintian and linda are fairly simple packages
<raphink> so it's a matter of 2 commands
<raphink> mdt dist-apt-get feisty source lintian
<raphink> pbuilder-edgy build lintian*dsc
<raphink> and that's it
<Mez> backport to dapper ;)
<raphink> ah yes, dapper
<Mez> or
<Mez> I can build backport debs
<raphink> if you want
<raphink> but I can build them directly on tiber
<Mez> already am ;)
<raphink> that might be faster
<Mez> technically so can I :D
<raphink> good
<raphink> so you're making the debs
<Mez> yep
<raphink> ok good
<Mez> but on my local machine
<Mez> it's easier that way
<raphink> are you admin on tiber?
<Mez> admin no
<raphink> ok
<Mez> i was
<raphink> put the debs in /tmp then
<raphink> I'll install them
<Mez> but I got de-adminned for some reason
* Mez cries
<Mez> I'm still part of the pbuilder group though
<raphink> I don't remember ever seeing you as an admin on tiber
<Mez> this was a LONG time ago
<raphink> ok
<Mez> before sistpoty came along ;)
<Mez> just before the pbuilder system got put in
<raphink> ok
<Mez> prevu's great though
<Mez> it'll do everything
<Mez> including wgetting the packages
<raphink> seems good
<Mez> it is :D
<Mez> thats what the ingenuity of the backports team does
<raphink> how are the packages doing?
<Mez> lintian's building
<Mez> http://archive.ubuntu.com/ubuntu/pool/main/l/linda/linda_0.3.24.dsc
<Mez> grr
<Mez> ** Success!. You can find source packages and .debs at /var/cache/prevu/dapper-debs **
<Mez> make: dh_pysupport: Command not found
<Mez> this is linda
<raphink> ah, new python
<raphink> well lintian will already be pretty good to have
<raphink> can you upload the deb to /tmp on tiber please?
<Mez> raphink: it's cool
<raphink> what is?
<Mez> python_support is in universe in dapper
<Mez> lemme just enable it in the prevu-chroot
<Mez> ;)
<Mez> it doesnt enable universe usually (I think)
<raphink> python-support doesn't contain dh_pysupport
<Mez> oh
<Mez> ok I was wrong
<Mez> it does in edgy! :P
<Mez> make: dh_pysupport: Command not found
<raphink> yes, but not in dapper
<raphink> and backporting python-support to dapper would mean backporting the whole python
<raphink> since it depends on >=2.4.3
<Mez> indeed
<raphink> so it's easier to change it to dh_python in linda
<Mez> /tmp/dapper_debs/lintian_1.23.27ubuntu1~6.06prevu1_all.deb
<raphink> or to just take the feisty package and install it
<raphink> since it's an 'all' package that only depends on python >=2.4 from what I can see
<raphink> argh
<Mez> argh ?
<raphink> lintian depends on gettext >= 0.16
<Mez> in-security I believe ?
<Mez> or not
<Mez> weird
<raphink> another option might be to call lintin and linda from whithin the chrooted environment in revu-build
<raphink> if possible
<Mez> that's gotta be a manual Depend
<raphink> that is, before the chroot gets removed
<raphink> this way, we would always be sure to call the right version
<Mez> raphink - or have a non-tgz chroot...
<Mez> and then use hooks/whatever to get it to run lintian and send it back through a bind-mount
<raphink> pbuilder accepts hooks, too
<raphink> I use them already in revu-build
<Mez> raphink, yes, tahts waht I meant
<Mez> however, it would take time to unzip the tarball
<raphink> I don't think there's a need to switch to non tgz chroots
<Mez> so if you have one extracted...
<Mez> time really
<raphink> well I guess we could switch to sbuild
<raphink> but then the best idea imo
<raphink> would be to have a source repository on the local machine
<raphink> that gathers the latest uploaded versions of each package on REVU
<raphink> and have sbuild use this local repo as deb-src
<Mez> raphink, pbuilder --no-targz --buildplace /path/to/unzipped/chroot
<raphink> and since sbuild supports multiple distros in chroots, it could be nice this way, too :)
<StevenK> pbuilder doesn't need to use tarballs.
<Mez> StevenK, my point exactly ... :D
<raphink> I don't see the use of pbuilder if there's no tgz
<raphink> I'd use sbuild instead in that case
<StevenK> Use cowbuilder, which will copy-on-write.
<raphink> StevenK: in this case, i'd rather use sbuild though
<raphink> for a simple reason
<raphink> if we can automate the creation of a source repository on REVU
<raphink> sbuild could just build from there
<raphink> whereas pbuilder/cowbuilder need a dsc
<StevenK> pbuilder does not need a dsc
<raphink> ah
<raphink> I guess the manual would have to be updated then
<raphink> pbuilder build [options]  .dsc-file
<Mez> pbuilder doesnt :P
<Mez> it's confusing
<StevenK> raphink: pdebuild :-)
<Mez> StevenK, exactly what i was thinking
<raphink> does pdebuild provide a script for multiple builders?
<StevenK> I have a wrapper I use.
<Hobbsee> !pbuilder | raphink 
<ubotu> raphink: pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<Hobbsee> bottom section
<Mez> raphink, pbuilder -- --basetgz /path/to/tarball
<Mez> raphink, pdebuild -- --basetgz /path/to/tarball
<raphink> Hobbsee: I wrote this section ;)
<Hobbsee> raphink: ah.  oh, you were asking about pdebuild...
<raphink> yep
<raphink> thanks though :)
<Mez> raphink, yeah - you can use any pbuilder options after -- 
<Mez> I use normally
<raphink> anyway
<raphink> back to setting this build farm :)
<raphink> buildd is still far from easy to set
<Mez> pdebuild -- --basetgz /scratch/pbuilds/feisty.tgz
<Mez> raphink install dak and katie ;)
<Mez> or
<Mez> poke infinity 
<Mez> and he can help you set up a buildd
<raphink> I've got enough to do with buildd/sbuild already
<raphink> and I got help from quite a few buildd admins
<raphink> ;)
<StevenK> dak and katie are nothing to do with sbuild
<Mez> raphink, :P
<raphink> as of the mirror, I chose reprepro
<Mez> StevenK, I know - I was taking the michael
<raphink> it's far easier to deal with than dak
<Mez> raphink, what about falcon ?
<raphink> and powerful enough for my needs :)
<StevenK> reprepro? Oh geez, that thing
<raphink> does falcon support signed uploads and incoming queue?
<raphink> StevenK: reprepro is so far the best repository builder I've found
<raphink> in terms of usability vs. functionalities
<raphink> although I reckon the configuration could be a bit better
<raphink> just added a few scripts to it and it works great
<Mez> raphink, oh... It just creates the repo ;)
<StevenK> I found it a pain in the neck.
<raphink> what do you use StevenK?
<StevenK> For a personal mirror?
<raphink> for a big one
<StevenK> My personal mirrors are all temporary, so dpkg-scanpackages
<StevenK> My local mirror, debmirror
<raphink> debmirror is not powerful enough for my needs
<raphink> I think I honestly studied all the possibilities I could find in Debian
<raphink> and chose reprepro because it fits my needs
<StevenK> I was using reprepro as a personal mirror, and it sucked.
<raphink> which are to build a master that mirrors the Debian repositories partially, gather several mirrors, signs them again, and adds personal mirrors with an incoming queue checking for signed packages
<raphink> and slaves mirroring the master with the same tool
<raphink> apart from dak, which is not recommended unless you have to build a whole distribution
<raphink> I found reprepro was the only one that was easy enough and powerful enough
<dholbach> good morning
<StevenK> siretart: I was plotting on dealing with the osgal-cvs merge.
<raphink> hi dholbach
<dholbach> hey raphink!
<raphink> :)
<raphink> what's up?
<dholbach> i'm just waking up :)
<siretart> StevenK: go for it! :)
<raphink> hehe :)
<raphink> just waking up at 10AM ? :)
<raphink> lucky you :)
<freeflying> hi all
<raphink> hi freeflying
<freeflying> raphink: haven't seen you quite a while  :)
* dholbach hugs raphink
<raphink> well i've been around
<raphink> just not very active 
<raphink> :)
<raphink> work work work :)
<phanatic> morning raphink :)
<raphink> hi phanatic
<freeflying> StevenK: how about the problem I talked with weeks ago? 
<Mez> hmm
<phanatic> raphink: have you seen the videos?
<raphink> some
<Mez> how many people do you think will want a package for a driver for a games pad
<StevenK> freeflying: Hrm? Weeks ago is a long time ago. :-)
<freeflying> StevenK: heh, the mis-match version number of scim-m17n and m17n-lib-bin
<StevenK> Ah ha.
<freeflying> I'm not sure the right two packages nowtoo :)
<StevenK> I'd forgotten all about that, sorry
<freeflying> After I talked with you, we lose the internet connection :)
<\sh> moins
<dholbach> hey proppy
* proppy hugs dholbach
<proppy> ohhh
* dholbach hugs proppy :)
<dholbach> ;-)
<proppy> you were fast :)
<dholbach> ;-)
<proppy> dh_olbach
<proppy> i wonder if anybody already does this joke :)
<StevenK> freeflying: You'll need to remind me completly, I'm sorry.
<proppy> s/does/did
* Mez drools at his new controller
<Mez> qwerasdfzxc
<Mez> (sorry)
<StevenK> Mez: Is that how good it is? :-P
<Mez> StevenK, that was me typing on it ;)
<Mez> seeing what the keys did
<Mez> one of them was enter ;)
<ajmitch> hi StevenK 
<Mez> StevenK, should I package the linux drivers up for ubuntu ?
* StevenK waves
<StevenK> Mez: Someone will probably find them useful.
<\sh> changing the maintainer field and adding original-maintainer field in debian/control is mandantory now, right?
<Mez> if I modify something in /dev/input (chmod) will it stay over a reboot
<StevenK> Mez: No
<Mez> StevenK, I worked that out
<Mez> StevenK now I need to work out how to use udev rules
<Mez> hmm
<Mez> I got it
<fernando> hey Hobbsee 
<Hobbsee> hey fernando 
<Mez> hmm
<Mez> this will be the first package I've made in ages ;)
<Mez> not the first one I've modified
<Mez> but the first NEW
<\sh> dholbach: src package bidiui, results in icedove-bidiui binary...should we rename this package to thunderbird-bidiui?
<dholbach> not sure
<\sh> more a question for -devel?
<dholbach> \sh: there's a new 'mozillateam' - it'd probably help to subscribe them to a bug report discussing this
<\sh> is there an irc channel for the mozillateam?
<Mez> hmm... 
<Mez> whats the best way of creating .desktop files ?
<Hobbsee> Mez: ask persia to do you one :)
<Amaranth> gnome-desktop-item-edit
<persia> Mez, if there is a menu file included with the package, try using the scripts from https://wiki.ubuntu.com/MOTU/Packages/NoDesktopFile
<Amaranth> oh, you mean for packages
<Mez> yes
<Mez> persia, no menu file either :D and it's a new package
<persia> Mez: I haven't updated the scripts in a while, you probably have some editing to do thereafter (check with desktop-file-validate foo.desktop)
<Mez> that's kind of scary ....
<Mez> http://rafb.net/p/B4Gx4R82.html
<Amaranth> copy someone else's file
<Mez> anyone come accross that before ?
<Amaranth> wtf is fluid and why does it need to talk to X?
<Amaranth> oh, fltk version of glade
<Mez> Amaranth, why does it need to talk to X ?
<Amaranth> not sure
<Amaranth> i would think it'd just be doing some C generation using an XML file
<Amaranth> apparently the converter and the actual GUI are the same app
<Amaranth> the designer GUI, i mean
<Amaranth> scary
<Mez> indeed
<Mez> is it worth running it before and just making it a patch ?
<Amaranth> if that's possible
* Mez tries
<persia> Mez: Looking at fluid.cxx, it appears that the processing is displayed to the user during the -c execution.
<Mez> it seems it is possible
<Hobbsee> tepsipakki: meeting is at 3am.  there's no way i'll make that, sorry
<persia> Mez: Are you packaging the speedpad driver, or something else?  If something else, give me a URL so I can fill in the fields correctly.
<Mez> nostromo n52 speedpad driver
* persia gets excited about easier hardware configuration
<StevenK> persia: You need to get out more. :-P
<Mez> grr
<Mez> with debhelper... the easiest system for patches ?
<StevenK> dpatch
<persia> StevenK: Nah - it's vacation.  I like .desktop and menu files.
<persia> Mez: Are you masquerading the device name, or keeping /dev/input/event#?  If the latter, I'll need to start without a device argument, which doesn't seem to match the documentation from the homepage.
<Mez> persia - the documentation from the homepage is completely wrong for this version
* persia reads the source
<Mez> nostromo_daemon works out the right thing and attaches to it
<Mez> (I'm working from experience)
<Mez> I've had to create udev rules for it though ;)
<Mez> nostromo_daemon runs as a panel applet 
<Mez> if the events (whatever they be) are readable, then it runs
<Mez> if not it just... does nothing
<Mez> but with the udev rules... it works
<Mez> (the docs on the site suck ass)
<persia> Mez: There is still a requirement for a type argument.  Do you want just gnostromo nostromo, or do you also want support for aftershock/firestorm?
<Mez> persia.... gnostromo doesnt exist anymore
<Mez> it's just nostromo_daemon
<Mez> persia, trust me, I'm using it
<persia> Mez: I'm looking at the tarfile for 0.1.3.  Should I be looking at something different?
<Mez> what are you looking at in that ?
<persia> Mez: Makefile, nostromo.c
<Mez> mez@apathy:/scratch/pkg/nostromo/nostromo_n50-1.3$ find . -name nostromo.c
<Mez> mez@apathy:/scratch/pkg/nostromo/nostromo_n50-1.3$  
<Mez> 1.3
<Mez> not 0..1.3
<Mez> http://sourceforge.net/project/showfiles.php?group_id=61608&package_id=91299
<persia> Mez: My mistake 1.3 is *much* larger than 0.1.3.  Returning to google :)
<Mez> ;)
<Mez> persia, use the link above
<persia> Mez: Got it.  Thanks.  Same site, just the home page hasn't been updated in four or five years.
<Mez> indeed
<Mez> no idea how it'll work on a mac ;)
<Mez> 01dofluidstuff.dpatch: script expects -patch|-unpatch as argument
<persia> Mez: http://rafb.net/p/6wiOiT95.html
<persia> Mez: include /usr/share/dpatch/dpatch.make
<Mez> persia, and the one to run the daemon ?
<Mez> persia: I did it manually
<Mez> http://rafb.net/p/caLMH370.html
<persia> Mez: I'm not sure about dpatch.  Investigating more to update the .desktop.
<Mez> persia, just needs another aswell ;)(
<Mez> for _daemon
<Mez> oh sorry
<Mez> persia, there's two things
<Mez> the config utiltity
<persia> Mez: Yep.  I'm building makefiles now, so as to better understand.  Updated paste to come soon.
<Mez> /exec -o locate nostromo_ | grep bin
<Mez> /usr/local/bin/nostromo_config
<Mez> /usr/local/bin/nostromo_daemon
<Mez> /usr/local/bin/nostromo_remote
<persia> Mez: Do any of those need arguments?  Also, is the user supposed to start all of them from the menu, or would some be embedded in the session?
<Mez> daemon should really be in the session
<Mez> config from the menu
<Mez> nostromo_remote is a daemon too
<Mez> but it's rare it'll be used
<persia> Mez: It looks to me like only nostromo_config should be in the menu.  Updating...
<_Enchained> Hi
<_Enchained> a gimp plugin in REVU, if someone wants to take a look at : http://revu.tauware.de/details.py?upid=4089
<_Enchained> :)
<Lutin> ajmitch: what do you think of https://bugs.launchpad.net/ubuntu/+source/lablgtk/+bug/65894 ? drop the package or fix the bug ?
<Ubugtu> Malone bug 65894 in lablgtk "FTBFS in edgy" [Undecided,Confirmed]  
<persia> Mez: http://rafb.net/p/SRH3yP66.html should be all you need for the .desktop.  I'm not sure how to add something into the user's session.  Perhaps the .desktop file and menu file should trigger a wrapper (/usr/bin/nostromo) that checks to make sure the applet is running prior to opening the configuration tool?
* Mez growls
<persia> Mez: http://rafb.net/p/VhzpBQ16.html
<Mez> [n] ostromo_daemon ??
<Mez> and shouldnt that be | grep -v grep ?
<persia> Mez: Yes, and have logic to start the daemon: http://rafb.net/p/3vFaPe12.html
<Mez> persia, nearly ;)
<persia> Mez: The n is wrapped to ensure it doesn't match `grep nostromo`
<crimsun> more Flash 9 crack for the masses.
<Mez> that says "if the daemons not running, start the daemon, if not, then run the config"
<Mez> shouldnt it be
<Mez> http://rafb.net/p/UEnOHG58.html
<Mez> http://rafb.net/p/q8bW5962.html
<persia> Mez: Maybe.  That starts the configurator whether the daemon started successfully or not.  I think it should be grep || daemon && config.
<Mez> which means you have to run it twice if the daemon isnt running
<persia> Mez: how about `start-stop-daemon --start nostromo_daemon && nostromo_config`?
<persia> Mez: Rather s/&&/;/
<Mez> hmm
<Mez> but start stop daemon returns false if it's already running
<daya> raphink, hi
<raphink> hi daya
<daya> raphink, what is going on
<raphink> busy at work
<raphink> fighting a bit with reprepro
<daya> hey
<persia> Mez: OK.  How about a two line script.  The first is start-stop-daemon (the return code can be ignored: the daemon is always running at this point), and the second is config.
<Mez> nvm
<Mez> ;)
<Mez> start-stop-daemon -o --start --exec /usr/bin/nostromo_daemon && nostromo_config
<Amaranth> -o means leave me alone?
<daya> raphink, ok
<Amaranth> oh
<Amaranth> oknodo
<Mez> -o means ok if no action
<Amaranth> i always use it explicitly
<Amaranth> none of this shorthand business
<Mez> lol
<persia> Mez: Nevermind.  start-stop-daemon doesn't exit after starting the daemon.  You might just have to use s-s-d & sleep 5 & config, or manage it manually.
<Mez> s-s-d does exit!
<Mez> start-stop-daemon -o --start --exec /usr/bin/nostromo_daemon && nostromo_config works perfectly for me
<persia> Mez: I just ran start-stop-daemon -o --start --exec /usr/bin/eog, and it didn't exit until eog did.  If it works with nostromo_daemon, then no worries :)
<Mez> persia, it does, cause it runs as a daemon :D
<Mez> whereas i presume eog doesnt ?
* persia should compile things before pretending to test them.
<Mez> persia, you'd need a nostromo though
<persia> Mez: Sitting behind my chair, unplugged because the F key repeats on boot and causes a nasty beeping noise during BIOS load.
<Mez> persia, sweet :D didnt know you had one :D
* Mez is writing a nice long email to upstream
<Mez> persia, what games you use it for ?
<persia> Mez: AlephONE.  Feel like grabbing from debian-montors?
<Mez> montors ?
<StevenK> mentors.debian.net
* Mez has never heard of it
<persia> Mez: mentors (oops)
<Mez> lol :D
<Mez> so I guess you use it without the driver?
<persia> Mez: It just has the left side of the keyboard without the driver.  Works fine.
<Mez> yeah, but you cant use the shift modes ;)
<Mez> with the driver it's quite good ;)
<Mez> without it's ok
<persia> Mez: I'm waiting for you to package it ;)
<tepsipakki> crimsun: that was fast :) (flash9)
<Mez> persia, lol
<Mez> ok, well I've got something that builds
<Mez> persia, you got the makefiles and stuff ?
<persia> Mez: Yes, but I haven't tried Make, I just read Makefiles more easily tham Makefile.am or Makefile.in.
<Mez> persia: scary
<Mez> persia: it's all fun
* Hobbsee cheers for sistpoty!
<\sh> so no more uploads from me today...need to install and deploy around 200 servers :(
<\sh> bbl
<Mez> er... if I need a package installed to run the postinst... do I list it under B-D or something else
<persia> Mez: Depends: should do it.  I think Pre-Depends is only for preinst.
<Mez> persia: Pre-Depends: udebv
<Mez> persia: Pre-Depends: udev
<persia> Isn't it safe to assume udev?
<Mez> *shrugs*
<Mez> devfs ?
<Mez> pre - 2.4. kernels ;)
<Mez> persia, I just need the stuff to install that desktop file ;)
<incorrect> hello, i am trying to backport subversion,  im just at the last hurdle,  apache and all the other libs compiled fine
<Mez> incorrect, ubuntu-backports@lists.ubuntu.com
<Mez> (you need to subscribe firsT)
<incorrect> oh right
<Mez> https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
<incorrect> is it a busy mailing list?
<Mez> fair to middling
<Mez> have alook at the archives
<persia> Mez: http://rafb.net/p/T2Tfpn74.html
<incorrect> ah figured it out, its a problem with debhelper
<Mez> persia ;d cheers
<incorrect> if at first you don't succeed, change the dependencies and hope nothing brakes :)
<Mez> persia- I assume dh_desktop will take a nostromo.desktop in the debian dir ?
<Mez> nvm
<incorrect> is the backports mailing list high volume?
<Mez> incorrect - I've had 6 emails in the past day
<incorrect> oh is that all
<persia> Mez: No actually, dh_desktop only does postinst magic to update the menus.  I also missed dh_installmenu.  See http://rafb.net/p/JDhJGF20.html.  Please test to make sure it appears in both the main menu and the Debian menu.
<Mez> it sometimes gets huge
<Amaranth> it's normally very quiet then explodes
<Amaranth> because all the backports launchpad bugs are subscribed to it
<incorrect> i really should setup my old nat box at home and run cyrus or something on there, 
<incorrect> i don't want my work email address to get spammed :(
<Amaranth> @lart ubotu
<Amaranth> wrong channel :)
<Mez> incorrect, gmail for the win
<Mez> persia, what package is "convert" in
<Amaranth> imagemagick
<persia> Mez: imagemagick.  Make the xpm manually: it is considered bad form to B-D on imagemagick.
<incorrect> i've never used gmail
<Mez> persia I know
<Amaranth> incorrect: want an invite?
<incorrect> for some reason webmail services aren't my biggest...
<Mez> I just dont have imagemagick installed
<incorrect> sure why not can't hurt
<Amaranth> incorrect: i need your current email address
<incorrect> golgotha1138@hotmail.com
<incorrect> yes yes i know
* Amaranth signs you up for a bunch of spam
<Amaranth> invite sent
<incorrect> thats fine :) i have it set to mark all as spam
<incorrect> thanking you
<Amaranth> gmail is great for managing mailing lists
<Mez> persia, I thnk I'm done
<Jozo-> Amaranth: Does they support List-Id header and others nowadays?
<Amaranth> Jozo-: with hacks, maybe
<Amaranth> i've never used List-Id and all my lists get sorted fine
<Mez> persia - damnit
<persia> Mez: When you install the .deb, does it show in both menus?  Also, do both launchers work?  If so, congratulations!
<Mez> it's easier to B-D on imagemahich
<Mez> dpkg-source: unrepresentable changes to source
<persia> Mez: The xpm is ASCII, the problem is caused by the PNG.  Since you are doing a name change, put a copy command in your debian/rules to change the name (dh_install cannot rename).  Some rules files copy the PNG directly to the target location, but I think it is cleaner to copy to debian first.  You could also use install directly, although this leads to long and ugly lines.
<Mez> I was just uuencoding it
<persia> Mez: That works too :)
<persia> Mez: I just like to use the copy or install commands because it reduces the size of the diff and makes the source of the icon clear.
* Mez has used install directly anyways for a rename
<incorrect> does apt keep an install history?
<Mez> persia - wanna try it out ?
<persia> Mez: Sure.  Where can I get it?
<Mez> I'll put it in revu in a mo
<Mez> just doing a final test build
<Mez> Selecting previously deselected package nostromo.
<Mez> shit lol
<Mez> it's built for feisty
* Mez backportsd
<Mez> lol
<Mez> backporting and it isnt even uploaded yet
<Mez> gotta love prevu
<_Enchained> someone to review a small pkg ?...
<Mez> _Enchained, is it in REVU ?
<_Enchained> yeah
<_Enchained> http://revu.tauware.de/details.py?upid=4089
<Mez> linky linky link link
<_Enchained> it's a gimp plugin
<_Enchained> no problem making the source pkg... I think it's near ok
<Mez> raphink, did you break linitan
<raphink> no
<Mez> lintian reported no errors for that
<Mez> weird
<Mez> _Enchained, see
<raphink> I didn't touch lintian
<Mez> http://revu.tauware.de/revu1-incoming/greycstoration-0701170615/linda
<_Enchained> thx Mez
<_Enchained> hum ok it's a ""
<_Enchained> I should remove it from the description ?
<Mez> yes ... 
<_Enchained> (it's a french name with a "" in it)
<_Enchained> ok
<Mez> use an e :P
<_Enchained> yes
<raphink> a ne devrait pas poser de problme _Enchained
<raphink> si c'est bien encod
<_Enchained> I look at it..
<_Enchained> (lintian didn't said anything about this)
<raphink> if lintian said everything linda says, there would be no point in developping both
<_Enchained> ? not understood
<Mez> raphink, pourquoi la rponse en franais ?
<raphink> pourquoi pas ;)
<_Enchained> english here ;)
<raphink> _Enchained: si lintian disait la mme chose que linda, il n'y aurait pas d'intrt  dvelopper les deux
<raphink> bah ;)
<_Enchained> meanwhile I'm french too ^
<Mez> persia, it's not installing the menu files
<_Enchained> ok raphink
<persia> raphink: 
<raphink> oh good news
<persia> Mez: The menu file, or the .desktop file?
<Mez> both
<Mez> actually where does the "menu" goe?
<persia> Mez: Could you put the .diff.gz and .dsc somewhere?  I'll take a closer look as to why you see that behaviour.
<persia> Mez: /usr/share/menu/nostromo.menu.  Don't manually install this, just put the contents in debian/menu, and dh_installmenu takes care of it.
<_Enchained> Mez: http://revu.tauware.de/details.py?upid=4091 updated
<Mez> the menu is installing
<Mez> but not the .desktop
<persia> Mez: The .desktop should be being installed by the combination of debian/install and dh_install.  Could you paste these files?  I'll take a look.
<persia> Mez: (rules, install)
<Mez> one sec
<Mez> http://rafb.net/paste/
<Mez> http://rafb.net/p/vm2UPg77.html
<Mez> http://rafb.net/p/yYr7eX30.html
* Mez slaps his head
<Mez> debian/nostromo.desktop usr/share/applciations
<Mez> I cant type
<persia> Mez: One of us mispelled applications :)
<persia> Mez: You might also try moving nostromo_container_script to nostromo, and using install to drop it in usr/bin.
<Mez> persia, the reason I did it that way was because when it builds - it installs to debian/nostromo/*
<Mez> ;)
<persia> Mez: Ah.  In that case, nevermind (some packages use debian/tmp, etc.).
<Mez> persia: other than that- looks good :D
* Mez uploads to revu
<persia> Mez: Personally, I'd move the config.sub and config.guess copy stanza to configure and delete in clean to make for cleaner debdiffs, but that's just me.
<Mez> *shrugs*
<Mez> add it as a comment in the revu upload
<Mez> http://revu.tauware.de/details.py?upid=4092
<Mez> actually I see what you mean
<_Enchained> Mez: (greystoration updated)
<_Enchained> greycstoration*
<Mez> why the B-D on autotools-dev ?
<persia> Mez: Without that, config.sub and config.guess don't exist, so they cannot be copied.
<_Enchained> Mez: doesn't needed ? (it was by default)
<Mez> shouldnt have been by default
<Mez> nothing should do it by default
<_Enchained> ok ^^
<Mez> persia, was that about a-d ?
<_Enchained> well, by default > with dh_make
<Mez> _Enchained, ignore me
<persia> Mez: Yes.  autotools-dev provides config.sub and config.guess.
<_Enchained> :x ok
<Mez> my fault
<Mez> "touch $@" ?
<persia> Mez: nostromo: /usr/doc -> /usr/share/doc
<Mez> grr
<Mez> anythings else ?
<_Enchained> Mez: sometimes, autotools-dev is not needed ?
<_Enchained> (I think it's the case for mine)
<Mez> It depends on whats done
<_Enchained> it seems to build without...
<Mez> _Enchained, then probably doesnt need it
<_Enchained> ok
<Mez> persia, http://revu.tauware.de/details.py?upid=4094
<Mez> persia, just pinged off an email to upstread
<_Enchained> updated : http://revu.tauware.de/details.py?upid=4095
<Mez> upstream *
<Mez> _Enchained, does it build against main or does it need to be universe?
<_Enchained> what's the difference ?
<Mez> not much
<Mez> just means I use a different pbuild ;)
<persia> Mez: nostromo: invoke-rc.d (policy 9.3.3.2).  Also, it doesn't work for me.
<_Enchained> I don't know...
<_Enchained> I thinked for universe
<Mez> persia: doesnt work for you how?
<_Enchained> (main are packaged by ubuntu dev no?)
<Adri2000> main/restricted -> ubuntu-core-dev
<Adri2000> universe/multiverse -> ubuntu-dev
<_Enchained> Adri2000: but I'm not an ubuntu-dev ...
<Adri2000> _Enchained: you meant ubuntu developers maybe?
<persia> Mez: No applet loads, and all the configuration options are grey.  I have a nostromo_n50.pid file in the directory I happened to be in when I installed it, and the contents are not a number (l).
<Mez> _Enchained, dont worry
<Mez> persia, ... out of curiosyt
<Mez> can you paste the output of ls -la /dev/input
<_Enchained> Mez: maybe I should fix the "" in copyright too ?...
<Mez> _Enchained, sure, why not ;)
<Mez> copyright is ok
<Mez> control is more important
<_Enchained> and add email addresses I've forgotten :x
<persia> Mez: http://rafb.net/p/KtWcBG79.html
<Mez> and does running
<Mez> nostromo_daemon 
<Mez> from the command line work?
<Mez> persia, you should see something in your notification area
<persia> Mez: no output.  No icon in the panel, no change in control-center behaviour.
<Mez> persia:  cat /proc/bus/input/devices    
<persia> Mez: http://rafb.net/p/Q9sF6g98.html
<Mez> persia... very very very strange
<Mez> persia, lsmod evdev
<Mez> sorry
<Mez> lsmod | grep evdev
<persia> Mez: installed.  Nothing depends on it.
<Mez> hmm
<Mez> grr
<Mez> your setup should work
<Mez> it works for me!
<Mez> and your setup mirrors mind
<Mez> mine *
<sdfgsdfgsgf> hi all
<bddebian> Hey
<crimsun> the deity himself.
<bddebian> Not me man
<bddebian> I've removed myself for now
<crimsun> going to bask in paradise?
<bddebian> crimsun: Nah, waiting until I can meet ajmitch's standards
<Lutin> hi bddebian 
<bddebian> Hi Lutin
<Lutin> bddebian: thanks for your comment on mlt :) I fixed it
<Lutin> if you have some time to look at it again :)
<bddebian> Lutin: I've been demoted, ajmitch will look at it for you
<Lutin> bddebian: oh :o
<Lutin> why ?
<chillywilly> bddebian: your revu privileges have been hereby revoked ;)
<crimsun> ugh, 79665 has an ugly Icon location in the .desktop
<crimsun> I'll poke persia about that 
<Mez> lmao
<Mez> poor persia
<bddebian> ?
<Mez> the ".desktop" guru it seems
<Enverex> hmm, I uploaded uade and ccd2iso to REVU absoloutely ages ago, waited a few months and gave up after no comments, now they don't seem to be on there at all...
<Enverex> Oh, and e-uae
<Enverex> ah, e-uae is there, the other two arn't
<bddebian> Enverex: If they were old and not updated, they were probably archived
<Adri2000> bddebian: have you found out what you did wrong according to ajmitch?
<bddebian> Adri2000: Nope
<Adri2000> :-/
<crimsun> bddebian: you failed to enumerate the Ubuntu delta
<bddebian> crimsun: On which package?
<crimsun> some merge
<Adri2000> argh
<Adri2000> crimsun: then it's me
<bddebian> crimsun: Was it msttcorefonts?
<crimsun> bddebian: yes
<crimsun> (so it wasn't your fault)
<crimsun> you can poke Adri2000 with a dead pony
<bddebian> crimsun: No it, was my fault.  I checked the changelog. Not sure how I missed that.
<crimsun> well, at least you weren't scolded by infinity for a merge or broke the toolchain for edgy
<crimsun> (both of which I've awesomely done)
<bddebian> Wait a minute, what's wrong with it?  That's how they have been getting brought in?
<crimsun> wrong with what?
<bddebian> Incorrectly I agree but it's consistent
<bddebian>  1.7ubuntu1
<crimsun> no
<crimsun> 1.7ubuntu1 and 1.6ubuntu1 should list your changes from 1.5ubuntu1
<crimsun> it takes up more space, yes, but that's proper
* LaserJock sends a big email to -motu and -devel
<LaserJock> you guys better watch out if I ever learn to like email
<sharms> ha
<bddebian> crimsun: Ahh, OK, I gotcha
* LaserJock taps "LaserJock's 95 MOTU Theses" to the list door ;-)
<crimsun> LaserJock: we have killfiles.
<crimsun> which, well, work amazingly for ubuntu-users
<LaserJock> crimsun: but of course everything I say is so worthwile and full of wisdom ;-)
<LaserJock> how could you miss out on that? ;-)
<crimsun> duh, you're 1/3 of the trinity
<LaserJock> bah
<crimsun> you Think and It Is
<LaserJock> unfortunately that is not so
<LaserJock> or there would be some big changes around here :-)
<crimsun> gotta be careful not to mold us after your own image, eh?
<bddebian> heh
<LaserJock> crimsun: something like that :-)
<LaserJock> bah, I'm still not getting my own emails from lists I don't think :(
* LaserJock kicks mailman
<Toadstool> g'morning everybody
<fernando> Toadstool: moin
<bddebian> Heya Toadstool
<Toadstool> hi bddebian, fernando 
<Adri2000> crimsun: I didn't paste the ubuntu changes for these two changelogs, because the changes were specified a few lines above and debian only did translation changes (so it was clear that it had nothing to do with the ubuntu changes). Now I know I have to do it *always*, so I will.
<LaserJock> hmm, if uploads gave karma I think doko would be near the top
<LaserJock> between OO.o and "lets rebuild the world" sprints :-)
<Toadstool> heh
<imbrandon> LaserJock, hehe
<imbrandon> LaserJock, and Riddell with rebuildign kde*
<imbrandon> ;)
<LaserJock> imbrandon: yeah, for sure
<sharms> LaserJock: I didn't see the mail yet either
<LaserJock> sharms: mine?
<sharms> yup
<sharms> oh nvm it was in a thread
<chillywilly> been googling for a while but does anyone know how to enable the lm-sensors MIB when running snmpd?
<chillywilly> under edgy
<bddebian> Gah, Feisty install can't mount my USB CD-ROM.. :-(
<Toadstool> fix it! :)
<bddebian> Toadstool: I freakin' hate USB :-(
<Toadstool> heh
<bddebian> I don't even know how a USB devices shows up in /dev :-(
<imbrandon> bddebian, mostly /dev/sd*
<Toadstool> some kind of kernel/udev magic?
<Toadstool> that's all I know :p
<bddebian> Well I have sda1 and sda2
<Laser_away> anybody noticed not being able to login with gdm?
<Laser_away> in feisty
<Q-FUNK> yup
<Laser_away> hmm, I can't find a bug report
<Laser_away> surely there is one
<Q-FUNK> and in edgy too, since some components were recently updated.  automated login suddenyl fails
<fowlduck-> no one could log in to file it ;)
<Laser_away> Q-FUNK: well, mine isn't automated login
<Laser_away> well, maybe it's just me
<bigon> Hi, I have added myself on the ubuntu contributor team, could you resync the keyring? thanks :)
<bddebian> OK afaict dmesg shows the CD on /dev/sg1 but I can't mount it
<lasindi> Hi all, I was wondering, are there any plans to include VirtualBox in Feisty, as it's now open source?
<afflux> I'm not shure if this is the right place to ask, but: is there any special reason why there is no "truecrypt"-package?
<imbrandon> lasindi, if someone takes the time to package it and have it reviewed then possibly
<imbrandon> afflux, see whgat i said about virtualbox
<somerville32> LaserJock, link?
<somerville32> err...
<somerville32> lasindi, link?
<lasindi> imbrandon: The Truecrypt project has already produced packages for Dapper and Edgy, so the packaging part is done. Who needs to review it?
<lasindi> somerville32: http://www.virtualbox.org
<afflux> alright. Am I allowed to package this on my own using the wiki?
<imbrandon> afflux, yes
<imbrandon> lasindi, REVU 
<afflux> alright. I'm gonna try.
<zul> ajmitch: ping
<somerville32> lasindi, They only provide binary packages so we'll have to create our own
<zul> somerville32: umm...no they have a svn
<imbrandon> zul, but the packageing isnt included in the svn
<imbrandon> ;)
<imbrandon> e.g. the debian/
<zul> meh..
* somerville32 coughs.
<somerville32> lasindi, They only provide binary packages so we'll have to create our own
<somerville32> Also, I'm not so sure about uploading an svn snapshot - could be interesting, lol
<lasindi> somerville32: well, they do have source code releases, so why would we need an svn snapshot?
<somerville32> Where are they?
<lasindi> http://www.truecrypt.org/downloads.php
<lasindi> Select "Other (source code)" from the drop down menu
<imbrandon> he is refering to vbox
<lasindi> Ohh
<imbrandon> somerville32, i have it debianized, i'll upload something for tseting in a few
<imbrandon> testing*
<somerville32> imbrandon, cool :)
<lasindi> Are you talking about vbox or truecrypt?
<imbrandon> lasindi, vbox, truecrypt you or other interested parties will have to debianize it , put it on revu and go from there
<lasindi> Okay, I've only done one Debian package in the past, but I'll give it a try with vbox.
<bigon> is there any revu.tauware.de admin here?
<imbrandon> lasindi, as i said i have vbox debianized already , just test compiling it 
<lasindi> Ah
<lasindi> In that case, I'll try Truecrypt
<imbrandon> bigon, there are a few ;) what do you need ?
<bigon> imbrandon: syncing the keyring (I have added myself to the revu group) and remove some files in incoming
<lasindi> imbrandon: I am running Edgy, by the way; should I be doing this on Feisty or is there a possibility of it going into Edgy?
<imbrandon> lasindi, you shoudl be doing it in a feisty pbuilder, the host env dosent matter much
<imbrandon> bigon, ajmitch or siretart will have to do that when they are arround ( not atm afaik )
<bigon> imbrandon: thx
<trappist> I've got a fixy patch on bug #78993 - could somebody take a look?
<Ubugtu> Malone bug 78993 in mrxvt "transparency setting/option not respected" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78993
<ajmitch> bigon: tell us what files, and we can do it
<bigon> ajmitch: libcm_0.1.1-0ubuntu1.*
<ajmitch> ok..
<ajmitch> bigon: done
<imbrandon> heya ajmitch 
<ajmitch> hello imbrandon 
<bigon> ajmitch: thx
<zul> ajmitch: ping same place as before
<bddebian> Jeff!
<jbailey> Heya Barry. =)
<jbailey> siretart: Around? =)
<LaserJock> goodness, *the* Jeff Bailey in #ubuntu-motu? ;-)
<jbailey> LaserJock: I've been known to visit here occasionally.  Just not recently ;)
<ajmitch> LaserJock: apparantly so
<ajmitch> hello jeff
<LaserJock> has your wife had her baby yet? I can't remember this things
<jbailey> IIRC, I hung out here a little longer than I hung out on #ubuntu-devel ;)
<zul> hi jeff
<jbailey> LaserJock: Nope, not yet.
<jbailey> LaserJock: We're still a month off.
<LaserJock> ah
<jbailey> Heya Chuck
<jbailey> (et. all)
<zul> how is everything
<joejaxx> well flash 9 has been released
<joejaxx> for linux
<ajmitch> queue the bug reports
<crimsun> Adri2000: thanks.
<crimsun> ajmitch: yeah, I've my pointy stick on hand
<mdke> hi chaps
<mdke> I wanted to talk about dvds
<mdke> you probably know that debian have removed the install-css script from libdvdread3
<mdke> we need to find a solution to this
<mdke> either by replacing it, or shipping another package, I'd like to talk this over with someone, who's good?
<crimsun> well, all of us for some subset of the possible resolutions.
<mdke> crimsun: what do you think is a good solution?
<crimsun> ideally we'd chunk libdvdcss source into multiverse
<mdke> in a separate package?
<crimsun> import the source from debian-multimedia
<crimsun> an alternative would be to see if we can use whatever Fluendo provides (if they have licensed the tech)
<mdke> what do you mean by source?
<crimsun> http://debian-multimedia.org/pool/main/libd/libdvdcss/libdvdcss_1.2.9.orig.tar.gz http://debian-multimedia.org/pool/main/libd/libdvdcss/libdvdcss_1.2.9-0.0.diff.gz http://debian-multimedia.org/pool/main/libd/libdvdcss/libdvdcss_1.2.9-0.0.dsc
<mdke> not shipping a binary package?
<Sp4rKy> please, in {pre,post}{inst,rm} script, does the shebang must be #!/bin/sh or can it be bash ?
<crimsun> we need the source to build the binaries.
<mdke> crimsun: ok, misunderstood you.
<Sp4rKy> to avoid bashism ?
<crimsun> Sp4rKy: if it needs to be /bin/bash, then it needs to be /bin/bash.
<Sp4rKy> ok
<mdke> crimsun: I agree that shipping a libdvdcss package in multiverse is a good solution
<Sp4rKy> thx crimsun 
<mdke> are there any reasons not to just do it?
<crimsun> mdke: the existing ones include "we don't know if we can"
<mdke> crimsun: right. I have some suggestions on that.
<crimsun> mdke: see the relatively recent removal of acroread 7.0.9 from feisty for an example
<siretart> jbailey: right now, yes 
<mdke> they essentially involve ignoring the issue
<jbailey> siretart: Heya!  Daniel mentioned that you might have a bzr-buildpackage type of thing and suggented that I ask you about it.
<siretart> jbailey: yes, I uploaded it yesterday to ubuntu
<siretart> jbailey: it is described here: http://wiki.debian.org/BzrBuildpackage/ and discussed here: http://wiki.debian.org/BzrBuildpackage/DesignIdeas
<jbailey> Nice!
* jbailey looks
<siretart> implemented as bzr plugin, with a small shell wrapper called 'bzr-buildpackage', which just does 'exec bzr bd $*'
<jbailey> We have a bunch of the toolchain stuff in bzr.
<jbailey> So it would be nice to have this tool for that.
<siretart> jbailey: feel free to contribute a branch here: https://code.launchpad.net/bzr-builddeb/
<siretart> :)
<siretart> jelmer said yesterday, that he could package things like charm with his bzr-svn plugin, where the upstream branch is actually in svn, and his debian/ dir with packaging in bzr
<jbailey> Ahah, nice.
<jbailey> Cool, so I'll play with this a bug, then.
<jbailey> Thanks!
<doko> hmm, are MOTUs allowed to approve packages for multiverse?
<LaserJock> doko: yes
<crimsun> well, do you mean ACCEPT in soyuz?
<LaserJock> oh, wait. I missread approve as upload
<ausimage> Hello I was wondering what might be the status of packaging flash-nonfree 9,0,31. I am still experiencing issues with 9,0,28...
<ajmitch> ausimage: it's already been uploaded
<ausimage> good.... thanks
<ajmitch> bah
* ajmitch was going to tell him to thank crimsun 
<ajmitch> such a shame it's still only for x86 :)
<jbailey> ajmitch: I'm having good luck with gnash.
<jbailey> The development rate on it is *quite* high.
<jbailey> Lat update I did, I couldn't do youtube, but I could do some video things, and I could work my way around some websites.
<ajmitch> that's good, we really do need a free flash player
<ajmitch> and now we're much closer to having free java browser plugins as well
<jbailey> gcjwebplugin also works remarkably well.
<jbailey> i don't have enough time to test gnash updates and upload them, but it would be nice to upload snapshots occasionally to Ubuntu.
<jbailey> I'd rather put work into a nightly snapshot package for it.
<jbailey> I'm not sure how much use a ppc gnash package would be to other people, though ;)
<ajmitch> I'm sure a few people would use it :)
<jbailey> What's the right way to request package removal?  bzrk and olive are now cruft.
<siretart> jbailey: file a bug and subscribe 'ubuntu-archive'
<ajmitch> siretart can type faster than I..
<siretart> ;)
<jbailey> Cool, thanks. =)
* ajmitch waves to siretart 
* siretart waves back to ajmitch 
<siretart> python django or python turbo gears?
<ajmitch> I haven't used either :)
<ajmitch> so I've only heard the hype about both
<ajmitch> I've heard django is fairly good
<siretart> turbogears seems to be longer in debian, though
<sharms> Guido endorces django
<sharms> although both look nice, I trust the creator of python :)
<ajmitch> or you could go with zope ;)
<_Enchained> good night all
<ajmitch> night _Enchained 
<_Enchained> (for those who are near)
<bddebian> Why is Mithrandir the only archive guy atm?
<ajmitch> because the others are busy/away
<bddebian> Hmm
<bddebian> This oughta be interesting.  Dapper Edubuntu -> Edgy Ubuntu -> Feisty :-)
<joejaxx> interesting
<joejaxx> flash9 does not support Opera
<crimsun> ...?
<rexbron> bddebian: I addressed crimsun's conserns. Could you look at murrine, upid 4099
<bddebian> No way man, I'm scared of crimsun and ajmitch now
* ajmitch sighs
<ajmitch> I'll leave, then you won't need to be scared of me
<bddebian> ajmitch: No, sounds like I need to leave since I make so many mistakes apparently
<Kyral> bddebian is GOD :P
<bddebian> not hardly man
<Kyral> *shrug* What do I know I'm just a washed up former Maintainter :P
<allee> hi MOTUs.  Digikam*-doc did not make it into dapper (they are in edgy, feist).  Is this important enough to request a backport (no changes needed).  Bug 57833
<Ubugtu> Malone bug 57833 in digikam "digikam has missing documentation" [Undecided,Confirmed]  https://launchpad.net/bugs/57833
<ScottK> bddebian: OK, not God, but still very good to have around.
<allee> hi Tonio
<allee> Tonio_: have you seen the reminder for bug 73617
<Ubugtu> Malone bug 73617 in digikam "SRU proposal" [Undecided,Unconfirmed]  https://launchpad.net/bugs/73617
<Tonio_> allee: I tried to ping mdz on that point without success.....
<Tonio_> I'll probably retry tomorrow, thanks for the tip
<allee> k, thx
<Tonio_> allee: although I'll have to sync with debian first :)
<Tonio_> allee: aware of debtags or not ?
<Tonio_> I need to rebuild the package but I have a problem to reapply autogen.sh
<allee> Tonio_: I know, but never used them
<Tonio_> requires svn access
<allee> Tonio_: which pkg?
<bddebian> ScottK: Bah, you're just saying that so I'll review your stuff ;-P
<Tonio_> allee: debtags
<Tonio_> allee: autogen.sh performs this :
<Tonio_> svn cat svn+ssh://svn.debian.org/svn/debtags/tagdb/tags | tagcoll copy | gzip -9 > tags-current.gz
<Tonio_> asking for a password here.....
<allee> Tonio_: a there anonymous access afaik. checking ...
<Tonio_> I tried anonymous but without success
<allee> Tonio_: try svn://svn.debian.org/...   this does not ask a pasword
<ScottK> bddebian: No, I'm saying it because you DO review my stuff.  I feel like I'm making good progress here and you help is a very significant part of that.
<Tonio_> allee: looks like working indeed......... strange
<ScottK> you/your...
<allee> Tonio_: the ssh+svn mean loging via ssh and start an svn client  (like rsync does)
<allee> Tonio_: I assume you need some SVN_* or ~/.subversion config to set you default user
<allee> ... to get svn+ssh url working 
<Tonio_> allee: well I should be fine fixing debtags with just svn:/
<allee> Tonio_: I strip also the first svn from path. that works here: svn cat svn://svn.debian.org/svn/debtags/tagdb/tags
<Tonio_> allee: yeah that's what I did
<allee> as well as svn cat svn://svn.debian.org/debtags/tagdb/tags  
#ubuntu-motu 2007-01-18
<bddebian> Later gang
<sistpoty> hi folks
<Lutin> hi sistpoty 
<sistpoty> hi Lutin
<LaserJock> siretart: sweet news on revu keyring updates :-)
<sistpoty> hi LaserJock
<LaserJock> hi sistpoty
<sistpoty> LaserJock: I really like that proposal of -proposed as a DMZ ;)
<LaserJock> I would think as long as we enforce ~propX versioning we would be ok
<LaserJock> but I could be wrong
<sistpoty> LaserJock: that's the problem if we don't review at all before an upload to -proposed... but still it might give us some benefits that way
<sistpoty> s/some/major/ ;)
<LaserJock> well, do you know what ubuntu-archive looks for now?
<sistpoty> no, not really
<LaserJock> if it needs 3 MOTU SRU acks before it goes in surely the motu-sru team could enforce versioning
<crimsun> I'm a bit displeased here.
<LaserJock> uh oh
* LaserJock runs
<sistpoty> LaserJock: that's true... but I'm even thinking a little further like "no reviewing before -proposed", just fire off
<crimsun> We failed -utterly- to define what constitutes a serious regression.
<sistpoty> crimsun: right...
<LaserJock> crimsun: do you think we are doing too many SRUs?
<crimsun> Essentially, I feel we've been wasting time processing SRUs that are -not- serious.
<crimsun> Does bug X make your program erase your data?
<crimsun> Does bug X hard-freeze your machine?
<crimsun> Does bug kill your mother?
<LaserJock> well, do you think that uninstallable, completely unusable (segfault, etc.) count?
<sistpoty> crimsun: OTOH most of the bugs we taggled were broken packages... so if s.o. wants to fix it, we should encourage that imho
<crimsun> No, I don't, LaserJock.
<LaserJock> so it's not a regression that a package worked in Dapper, but doesn't in Edgy?
<crimsun> Of course it's a regression
<LaserJock> and by worked I mean installs or even starts?
<sistpoty> also it's quite hard to tell which package is being used by really many people and thus would warrant an SRU
<crimsun> is it a -serious- (as in grave, RC-worthy) regression?
<LaserJock> I think it's -serious- if you can't even install the thing, or it doesn't even start
<crimsun> obviously every bug can be rated grave/RC-worthy by some subset of users
<crimsun> I think it's a candidate for a serious bug if there's no available fix in the current development version.
<LaserJock> to be honest, I'd love to just say "screw it, what's released is released. let's moved on"
<sistpoty> and to focus on getting ubuntu+1 in better shape?
<LaserJock> crimsun: that seem a little twisted though. "Fix your stable release by upgrading to the unstable release"
<crimsun> LaserJock: how many of these bugs are reported against 6.06 LTS?
<crimsun> I've seen a handful hit SRU
<LaserJock> mostly Edgy
<crimsun> the vast majority are for 6.10
<sistpoty> yes
<LaserJock> that's a stable release
<LaserJock> I mean, I know what you're saying
<sistpoty> well, imo universe was in quite suboptimal state for edgy :/
<crimsun> I'm convinced we, as a community maintaining universe, have to seriously reconsider what "support" means.
<LaserJock> crimsun: k, that makes sense
<crimsun> for LTS to mean anything, 6.10 isn't as high a priority as 6.06
<LaserJock> sure
<LaserJock> but if people want to contribute fixes for 6.10 should we deny them just because it's not LTS?
<crimsun> no, not at all
<LaserJock> I agree that we should prioritize on Feisty, as it's better to produce a good release then fixing it after the fact
<crimsun> discouraging SRUs is not a resolution
<crimsun> clarifying what SRUs must fulfill is a start
<sistpoty> we just need *many* more motu's :)
<allee> heh, nice timing.  I too was pondering the last minutes how to handle the dapper bug(let) and if there's a policy.
<crimsun> up to a point that may help
<LaserJock> is SRU really taking up a lot of time?
<crimsun> we have a HUGE number of MOTU
<crimsun> how many are really active?
<crimsun> it's the mythical man-month all over again
<LaserJock> but are MOTU having to do a lot for SRU is my point
<sistpoty> hehe, I just wanted to write "active" ;)
<LaserJock> it seems like our bottleneck is mostly ubuntu-archive
<LaserJock> granted, I'm not disagreeing with you crimsun 
<LaserJock> I'm just not sure what we are supposed to do exactly
* allee too
<sistpoty> LaserJock: merges! merges! merges!  ;)
<LaserJock> heh, which ones?
<crimsun> allee: there's policy, and there are at least two motu-sru active right this moment, so if have an unprocessed one, give the url, please
<sistpoty> all, preferable these with grave bugs in unstable fixed ;)
<allee> sistpoty:[23:45]  <allee> Tonio_: have you seen the reminder for bug 73617
<Ubugtu> Malone bug 73617 in digikam "SRU proposal" [Undecided,Unconfirmed]  https://launchpad.net/bugs/73617
<crimsun> [this is sounding like I need three or four sets of "office hours"] 
<sistpoty> allee: digikam is in main... 
<crimsun> allee: that's not motu-sru's realm
<sistpoty> *g*
<allee> crimsun: [23:39]  <allee> hi MOTUs.  Digikam*-doc did not make it into dapper (they are in edgy, feist).  Is this important enough to request a backport (no changes needed).  Bug 57833
<Ubugtu> Malone bug 57833 in digikam "digikam has missing documentation" [Undecided,Confirmed]  https://launchpad.net/bugs/57833
<allee> sistpoty: ah right, it moved to main for edgy
<LaserJock> crimsun: so are you thinking we should be tighter on accepting SRUs?
<Tonio_> allee: yeah that's main purpose.... I have to ping cjwatson, has mdz nerver responded me on that point
<crimsun> allee: yes, backport-worthy
<crimsun> LaserJock: we first need to be -very- explicit about what constitutes a serious regression.
<LaserJock> crimsun: I agree with that
<allee> crimsun: okay, thx.  I lookup the bp procedure ...
<LaserJock> although I think it has to remain a call of motu-sru mostly
<crimsun> correct, there won't be a blanket "serious"
<crimsun> but right now that point is too vague
<sistpoty> btw.: what about a motu meeting? is s.o. already working to organize one?
<crimsun> no, but I will need to comb the motu-verification-needed tags to send something to UWN/fridge
<sistpoty> cool
<LaserJock> oh, btw
<sistpoty> should I write a mail about motu meeting to -motu?
<LaserJock> I asked #launchpad about creating a product for people to file bugs for new package requests
<LaserJock> but kiko didn't want us to use a product that way
<sistpoty> :(
<LaserJock> instead he suggested using a tag
<LaserJock> and I said that that could get messy
<crimsun> sistpoty: call for votes on meeting time & date? yes, please
<crimsun> ewww
<crimsun> running build_ext
<crimsun> *** glibc detected *** python2.5: free(): invalid pointer: 0x401da0e0 ***
<sistpoty> crimsun: ok will do
<LaserJock> so I ended up filing a bug against Malone to so that we can preload +filebug with tags
<LaserJock> so we could give https://launchpad.net/ubuntu/+filebug?tag=universe-request to people
<sistpoty> LaserJock: nice
<LaserJock> we could also use that for other things
<jbailey> How are snapshots of things usually handled?  I'm building an updated gnash, and it seems to want a newer snapshot of ffmpeg.
<jbailey> I'm curious what the criteria for uploading an SVN snap would be - ffmpeg is currently one, and doesn't seem headed towards a release anytime soon.
<slomo> jbailey: i bet you don't want to update ffmpeg :) if you do so you probably need to fix all rdepends, bump soname, etc as they like to change API/ABI each day or something ;)
<jbailey> Joy.
<sistpoty> jbailey: FWIW there isn't really a criteria for svn snapshots... however for ffmpeg siretart has plans IIRC... 
<jbailey> Why are the most critical pieces of infrastructure always crap?
<jbailey> =)
<ajmitch> because people are 'creative'
<jbailey> Heh
<sistpoty> hehe
<sistpoty> hi ajmitch
<crimsun> it makes me chuckle that the soname for debian-multimedia's ffmpeg is _51_
<jbailey> soname or soversion?
<crimsun> the latter, sorry
<jbailey> Oh good. =)
<jbailey> WEll not *good*
<jbailey> but you know...
<jbailey> =)
<Burgwork> is it really that hard to maintain API and ABI stability?
<ajmitch> hi sistpoty 
<crimsun> to whom are you posing that question? O:-)
<Burgwork> the world
<Burgwork> in general frustration with ffmpeg
<ajmitch> a cry of despair 
<sistpoty> Burgwork: it's not that hard... but it's way more easy and entertaining to just not care about api stability
<Burgwork> failure to see the world beyond your own set of blinders is a common afliction, apparently
<ajmitch> LaserJock: what were you saying before about keyring updates?
<sistpoty> Burgwork: as you'll always end up dragging old interfaces for api-stability around, and need to care for these as well
<Burgwork> true, but there is a difference between breaking them deliberately (ala gstreamer) and just not caring
<LaserJock> ajmitch: yeah, tiber's MOTD says that anybody with a tiber account can sync the keyring
<ajmitch> LaserJock: oh right
<ajmitch> so I don't need to be bugged about it again :)
<LaserJock> yeah
<LaserJock> :-)
<ajmitch> I wondered why sudo didn't ask me for the password this morning
<sistpoty> sheesh, I never did the -u revu1 *g*
<crimsun> mmm yeah, I'm making python2.5 explode
<sistpoty> fridge displays "f_ie_sty" developer sprint *g*
<ajmitch> still?
<sistpoty> ok, current candidates for meeting:
<sistpoty> * Sunday, January 21st, 14.00h UTC
<sistpoty> * Monday, January 22nd, 20.00h UTC
<sistpoty> * Tuesday, January 23rd, 12.00h UTC
<sistpoty> anything I should change right away?
<sistpoty> (before sending the mail)
<ajmitch> hm
<ajmitch> how long do we have to decide?
<ajmitch> about 2 days?
<ajmitch> don't drag it out :)
<LaserJock> It'd be real tough for me to do 14:00 or 12:00 UTC
<ajmitch> 14:00 would be 3AM for me, lots of fun
<ajmitch> but it's up to everyone else
* ajmitch has nothing important to bring up at a meeting
<sistpoty> ajmitch: decisions until Saturday, 12.00UTC?
* crimsun sees a flash 9.0.31.0.2ubuntu2+3v1ubuntu0 deb
<crimsun> I LOVE personal repos.
<ajmitch> sistpoty: whatever works, just give people enough warning time for the meeting itself
<crimsun> wait, let me stress that. I LOVE. personal repos.
<sistpoty> ok
* ajmitch hands crimsun a pony
<crimsun> whew, good thing I didn't have a shotgun or that pony would be toast
<sistpoty> ajmitch, LaserJock: how about 10.00 and 8.00 UTC then?
<ajmitch> sistpoty: works for me
<LaserJock> sistpoty: lets see that's 0:00 and 02:00 for me
<ajmitch> sistpoty: I'm about the only one in this timezone though
<LaserJock> me too
<crimsun> Sun or Mon are feasible for me
<ajmitch> most people seem to be europe or the US
<sistpoty> for europe this would be early morning, so only the sleepy ones (like me) would need to get up early *g*
<ajmitch> do we have a meeting agenda?
* ajmitch needs to see if it's worth staying up late for a meeting ;)
<Nafallo> sistpoty: what time?
<LaserJock> ajmitch: well, we have SRU revisited
<sistpoty> Nafallo: 8.00 UTC, 10.00 UTC and 20.00 UTC would be my current proposals
<Nafallo> sistpoty: that's not CET hon' ;-)
<sistpoty> *g*
<sistpoty> Nafallo: you'd either need to stay up long for 8.00 UTC or to go to bed really early :P
<Nafallo> still not CET ;-)
<sistpoty> Nafallo: +1 then you're at CET 
<LaserJock> isn't that like 10:00 CET?
<LaserJock> oh +1, I was thinking +2
<sistpoty> LaserJock: that would be CE_S_T  (daylight saving)
<Nafallo> sistpoty: I'm lazy ;-)
<LaserJock> sistpoty: ah
<sistpoty> mail sent, time to vote :)
<ScottK> sistpoty: Are you up for a REVU?  It's an upstream update (plus I added more documentation like man pages) of a package you've reviewed before - http://revu.tauware.de/details.py?upid=4086
<LaserJock> oh bugger, what's the way to test mtime in bash?
<sistpoty> ScottK: ok, one review... but then I'll need to debug my parser *g*
<ScottK> Thanks.
<ajmitch> LaserJock: hm?
<sistpoty> LaserJock: what's the situation about the maintainer field again? should we fiddle with it or just leave it as is?
<LaserJock> sistpoty: we are supposed to fiddle with it but we're not sure what field to put the original mainatiner in
<LaserJock> ajmitch: I need to test if a file has been modified since a certain time
<sistpoty> LaserJock: ok. so that means basically don't fiddle with until we know more *g*
<LaserJock> sistpoty: I guess :/
<LaserJock> mdz hasn't really given us much
<sistpoty> yes :/
<ajmitch> LaserJock: hm, if I'm looking for a file, I generally use find for that
<ajmitch> LaserJock: maybe stat?
<LaserJock> as sladen emailed, it's variously Original-Maintainer:, Debian-Maintainer:, X-Original-Maintainer
<LaserJock> and XBS-Original-Maintainer: was also suggested
<LaserJock> ajmitch: I don't need to find a file, just using it like a timestamp
<persia> LaserJock: Try a test between stat -c%Y filename and date +%s
<rexbron> What is the URL for the uploads awaiting acceptance?
<Nafallo> zZzZ
<LaserJock> rexbron: acceptance in the NEW queue?
<sistpoty> ScottK: IANAL, but imo you'll need to remove debian/rfc4408, as I couldn't find any rights that we may distribute it
<ScottK> Good point.  Let me research that and I'll pull it if I can't find something.
<ScottK> Urgh.
<ScottK> Anthing else?
<sistpoty> ScottK: if you find s.th. please update debian/copyright
<sistpoty> ScottK: apart from that it doesn't build atm. (most probably the fault of python2.5 *g*)
<ScottK> Weird.  It runs find in my Feisty chroot that I'm pretty sure is running 2.5.
* ScottK goes to check.
<ScottK> Thanks.
<sistpoty> ScottK: IIRC my pbuilder is always late a day, since I'm using a german mirror
<sistpoty> ScottK: apart from that it looks really good, though it's like seeing only half of the package if I can't build it ;)
<rexbron> LaserJock: crimsun uploaded a package for me
<rexbron> I am just wondering where I can check its status\
<persia> rexbron: https://launchpad.net/ubuntu/+source/<pkgname> is often a good start.
<rexbron> it lists no builds
<rexbron> crimsun mentioned that tollef had to accept it
<crimsun> rexbron: which source package?
<rexbron> murrine
<crimsun> err
<crimsun> when did I upload murrine? :D
<crimsun> I have not dput anything with murrine in its string
<rexbron> crimsun: [17:32]  <crimsun> ok, queued (ETA: 2 hr)
<crimsun> rexbron: that means I'll -look- at revu in 2 hrs
<rexbron> (from US-dev
<rexbron> ok 
<rexbron> crimsun: got the wrong impression
<bronson> I'm using dpkg-buildpackage to build my packages right now.  Works great.
<bronson> Problem is, since I want to use pbuilder, I need to use debuild.
<zul> hey
<bronson> And debuild makes it very difficult to specify "-sa" (include source in upload).
<bronson> right?  Am I missing something?
<crimsun> debuild -S -sa
<crimsun> dpkg-buildpackage -S -sa
<bronson> crimsun: you sure?  Because the debuild manpage says: DEBUILD_DPKG_BUILDPACKAGE_OPTS="-kJulian Gilbey <jdg@debian.org> -sa"
<bronson> (as an example)
<crimsun> am I sure of what?
<bronson> And doesn't list -S or -sa as debuild arguments...
<bronson> That debuild takes -S and -sa.
<bronson> I guess debuild's manpage needs updating...
<crimsun> of course it takes -S and -sa
<crimsun> those are dpkg-buildpackage options
<crimsun> it's fairly explicit in the debuild man page
<crimsun> (See the Examples section)
<bronson> But if it just takes dpkg-buildpackage arguments, what's the purpose of DEBUILD_DPKG_BUILDPACKAGE_OPTS?
<bronson> Nevermind, you're right.
<bronson> The synopsys says it takes dpkg-buildpackage options
<bronson> awesome.  Sorry for my confusion.
<bronson> crimsun: thanks.
<crimsun> np
<bronson> There's no need to pass -pgpg to debuild because it will do this automatically, right?
<bronson> It's hard to tell from the manpage.
<bronson> Actually, I think that's wrong: I still need to pass -pgpg?  sigh.
<crimsun> debuild will sign unless told otherwise, yes.
<rexbron> hey Hobbsee, would you be able to review murrine again? upid 4099
<Hobbsee> crimsun: did you want to review it?
<rexbron> Hobbsee: crimsun did
<rexbron> check out the latest upload
<Hobbsee> ah right
<rexbron> Hobbsee: are you still going to examine it?
<Hobbsee> rexbron: i'm going out, to LCA today sorry
<rexbron> no problem
<rexbron> have fun
<rexbron> so any motu's up for a review, see upid 4099
<rexbron> it already has one approval
<rexbron> LaserJock: got the time for a review? upid 4099
<Hobbsee> bha
<Hobbsee> *bah
* Hobbsee goes to look it up
<rexbron> lol ty
<rexbron> just trying my darndest to get this thing approved
<Hobbsee> crimsun: rexbron: why are there a whole lot of files in the diff outside debian/?
<Hobbsee> not just the .bzr stuff
<Hobbsee> http://revu.tauware.de/revu1-incoming/murrine-0701171715/murrine_0.41-0ubuntu1.diff
<rexbron> because upstream updated the source files with licences (at crimsun's request)
<rexbron> but just updated the tarball
<Hobbsee> ah
<crimsun> Hobbsee: traditionally the pedigree of murrine has been a thorn, so I wanted to ensure that wasn't the case upon submission.
<rexbron> might be an issue with multiple tarballs being named the same with .# extentions
<Hobbsee> crimsun: gotcha.  this builds and runs fine?
<crimsun> it builds and appears to provide a functional gtk engine
<crimsun> themes are not bundled with it
<Hobbsee> cool
* Hobbsee acks
<Hobbsee> yeah
<Hobbsee> crimsun: can you upload that please - i need to head out asap so i get to LCA on time
<crimsun> sure.
<Hobbsee> thanks
<rexbron> yay
* sistpoty is off to bed
<sistpoty> gn8 everyone
<persia> I was adding an icon and .desktop to brutalchess, and noticed a new Debian version (new upstream version),  Should this be processed as a merge, or only a bugfix to the previous version?  There is no prior Ubuntu delta.
<crimsun> merge it.
<persia> crimsun: Thanks.
<crimsun> we're not in UVF or FF yet, so new upstreams are still game
<persia> crimsun: There seem to be about 500 packages in universe with newer versions in Debian that have no Ubuntu delta.  Are all of these targets for SYNC, assuming they build cleanly and fix useful bugs or provide useful features?
<LaserJock> I think so
<LaserJock> but generally if is useful as you say
* persia adds SYNC investigation to the todo list, after remaining LP .desktop bugs
<LaserJock> merges are priority though
<persia> LaserJock: Merges seem to be in pretty good shape, with most of the packages I've looked at recently either having a bug filed or < 1 week in Debian.  I'll look again.
<bddebian> Heya gang
<persia> Hi bddebian
<Hobbsee> persia: make sure you grab the request sync script
<persia> Hobbsee: Where?
<bddebian> Heya persia, Hobbsee
<Hobbsee> persia: w.u.c/DeveloperResources
<Hobbsee> hey bddebian 
<LaserJock> Hobbsee: what does that script do?
<LaserJock> it seems kinda weird to use a script for a sync request
<persia> Hobbsee: My local mail is a mess.  May I continue following the format in bug 79338 (excepting the -XubuntuY explanantion if there is none)?
<Ubugtu> Malone bug 79338 in omniorb4 "Please sync omniorb4 4.0.6-2.3 (universe) from Debian Sid (main)" [Wishlist,Fix released]  https://launchpad.net/bugs/79338
<persia> LaserJock: It collects all the right information and sends mail to launchpad: saves entry on LP directly.
<StevenK> And requires a deb-src entry for the release name.
<StevenK> Other than that, requestsync is Good[tm] .
<LaserJock> why does it require a deb-src line?
<persia> LaserJock: apt-cache madison
<LaserJock> does that actually work?
<LaserJock> that seems odd
<StevenK> steven@liquified:~% apt-cache madison libc6 libc6 | 2.4-1ubuntu12 | http://au.archive.ubuntu.com edgy/main Packages glibc | 2.5-0ubuntu8 | http://archive.ubuntu.com feisty/main Sources
<StevenK> Of course it doesn't.
<StevenK> (Insert linefeeds to taste)
<LaserJock> well, I mean. I've never been able to get multible deb-src lines to work well
<StevenK> How do they not work?
<LaserJock> apt-get source doesn't work
<StevenK> I need a little more information than that to debug it.
<LaserJock> it's a know bug
<LaserJock> known
<StevenK> Personally, I have one deb-src line for feisty.
<persia> StevenK: I also had trouble with apt-get -t <distribution> source <package>
<LaserJock> yep
<ajmitch> LaserJock: putting the exact version in works
<LaserJock> heh, well if I'm going to do that I might as well dget it
<LaserJock> I'm actually writing a script tonight for a wrapper around dget
<persia> LaserJock: I thought dget didn't work for LP?
<LaserJock> it doesn't
<LaserJock> for debian though
<Hobbsee> LaserJock: requests a sync, shows the debian changes, subscribes the correct people, etc
<LaserJock> for Ubuntu I'm going to have to screen scrap I guess
<Hobbsee> persia: i'd expect so
<persia> Hobbsee: Thanks.  That's easier for me (as then I don't have to fix mail first).
<Hobbsee> persia: do you need to fix local mail anyway to use it?  it's got the ubuntu smtp server, so you dont need a MTA
<StevenK> persia: Set DEBEMAIL, and it will send directly to the Ubuntu LP SMTP server.
<persia> Hobbsee: I missed that.  I'll give it a try.
<persia> StevenK: Thanks for the details.
<LaserJock> that's cool
<LaserJock> I don't have mail set up either
<persia> LaserJock: apt-get -c works fine for LP :)
<LaserJock> can you give it alternate sources.list that way?
<persia> LaserJock: Didn't I send you my src-get script?  You just need an alternate apt.conf that points to an alternate sources.list.
<LaserJock> doh
<LaserJock> I have it on my work computer. I forgot about it
<persia> LaserJock: It's linked from my wiki page, if you want another copy.
<LaserJock> I still have it
<LaserJock> well, that solves part of my problem :-)
<LaserJock> I wrote a script to create lists of -proposed
<LaserJock> so I can check on what's in there
* StevenK waves madison-lite at LaserJock
<bddebian> StevenK: Better watch it or LaserJock might wave his lasers at you :-)
<StevenK> And if you pipe up and say it requires a local mirror, I will hit you. :-P
<StevenK> bddebian: "lasers" </austin powers>
<LaserJock> StevenK: well, I don't see how madison-lite would help me much
<LaserJock> I agree it's a cool tool
<StevenK> LaserJock: You can see what's in proposed with wget and zgrep anyway
<LaserJock> StevenK: that's what I wrote
<LaserJock> wget, zgrep, create HTML, for each release
<StevenK> Heh. I wouldn't even bother scripting it.
<StevenK> for i in dapper edgy .... ; do wget ... ; done
<LaserJock> hmm, maybe. I just want it daily
* bddebian wants it daily
* StevenK belts bddebian
<bddebian> ouch
<StevenK> Serves you right. :-P
<LaserJock> hmm
<LaserJock> well, I guess I wasted a couple hours this afternoon 
<Mez> if anyones bored - can they have a loko @ http://revu.tauware.de/details.py?upid=4094
* somerville32 would love to.
<persia> Mez: Do you think it works now?
* bddebian pounces on Mez
<Mez> persia: I dont know why it doesnt work for you
* Mez slaps bddebian 
<Mez> you're not meant ot be doing work
* persia prepares to file a bug if the upload is accepted
<bddebian> Yeah I know, but I'm gonna anyhow :-)
<Mez> persia: can you compile it with debugs syms and see if the stacktrace or similar shows anything
<persia> Mez: It doesn't crash - it just doesn't do anything I other than look pretty, and doesn't seem to provide any explanatory output. I cannot manipulate any of the controls.
<Mez> does it not put the lil tray icon in your notification area?
<persia> Mez: It doesn't.
<StevenK> "lil tray icon"
<StevenK> Hah
<StevenK> It sounds like a Fisher-Price toy. :-P
<Mez> StevenK, I'm half asleep
<Mez> persia: quick question - is your user in the plugdev group ?
<Mez> StevenK, no then it'd have to be the "lil whirly tray icon"
* StevenK grins
<persia> Mez: persia@frigga:~/src/scratch$ groups persia [LF]  persia : persia adm dialout cdrom floppy sudo audio dip src video plugdev lpadmin scanner data-dev pulse-rt sbuild
<Mez> hmm
<StevenK> frigga? What sort of machine name is that? :-P
<bddebian> hmm
<Mez> StevenK, persian's a pornstar really
<StevenK> Bwaha
<persia> StevenK: My phone is hnoss.
<bddebian> Oh sure Mez says pornstar and doesn't get belted
<StevenK> Poor bddebian!
<bddebian> heh
<Mez> persia.... I dont know...
<Mez> try a cat /dev/input/evetX
<Mez> (whatever the event is)
<Mez> see if you get an error
<bddebian> StevenK: No more reviews for you man :-)
<Mez> and see if it does anythign when you hit keys etc
<persia> Mez: If you purge all nostromo related things from your workstation, and install your package, does it work for you?  Also, does perhaps nostromo_control need to be run with elevated rights?
<StevenK> bddebian: I don't recall ever needing you to review anything that I've done? :-)
<bddebian> Gah, my old age is getting to me, I was thinking scottk.. Sheesh
<Mez> persis: yes - I'm using my package
* StevenK smirks.
<Mez> and no - it runs with user roghts (hence the udev rules)
<ScottK> bddebian: For some reason if someone gets my name wrong it is almost always Steve that they pick. 
<persia> Mez: Could you remind me how to determine which event device is the SpeedPad?
<Mez> ls -l /dev/input/event*
<Mez> it's the ones assigned to the "plugdev" group
<bddebian> ScottK: That's funny.  People always call me Brian when my name is Barry.  What is especially quirky is that my brothers name is Brian and even people that don't know of him call me Brian at times
<Mez> bddebian, so what you think (packaging wise)
<Mez> bddebian, so, you're brian and so's your brother ?
<bddebian> Mez: Had to update pbuilder quick so I'm just now checking it
<persia> Mez: I seem to have two /dev/input/event? files that correspond to the device.  Both output entered characters and garbage for the wheel when I cat them.
<Mez> lol
<LaserJock> persia: do I need to replace USER in your script?
<persia> LaserJock: No.  That should be taken from the environment when you run src-get new..  It's designed for central installation for local user caches on a multiuser system.
* Mez wonders where revu-build went
<LaserJock> persia: hmm, ok. I just expected $USER
<persia> LaserJock: That's the apt.conf skel.  USER is replaced by $USER in the new directive when the new configuration is initialised.
<jdong> ok, a bit of a packaging policy question....
<jdong> do the version constraints in debian/control have to refer to existing Ubuntu packages?
<jdong> i.e. I am preparing a 20070117 snapshot of x264
<jdong> and in the process need to patch mplayer and friends
<jdong> the new mplayer will now only build against x264 >= 20061216 (when the API change was inflicted)
<jdong> should build-dep request x264 >= 20061216 or 20070117?
<jdong> given that currently a 20061216 snapshot does not exist :)
<LaserJock> I don't think that's a problem
<Mez> jdong they dont have to refer to an actual version number
<Mez> that should work fine
<jdong> Mez: ok, cool :)
<Mez> it's just a dpkg --compare-versions
<Mez> or whatever it is
<jdong> Mez: I wasn't sure if we had any silly packaging policies in place :)
<Mez> jdong: if thats the clause that means you get the right version
<Mez> then thats the clause you should use
<Mez> persia - so- any luck with playing with the events ?
<persia> Mez: The event queues output entered characters according to the default map in response to cat.  The wheel forces a terminal reset.  I haven't tried anything further.
<Mez> persia... hmm
<Mez> persia, what ubuntu are you using ?
<persia> Mez: Tested with today's feisty.
<Mez> persia: I did notice that you didnt have
<Mez> /dev/input/by-id
<Mez> or
<Mez> /dev/input/by-path
<Mez> one or the other
<persia> Mez: I have by-path
<Mez> so theres something different in your system than mine
<Mez> persia: grep by-id /etc/udev/rules.d/65-persistent-input.rules
<bddebian> Ho hum, what to do ..
<jdong> what is the most effective method of replacing a string throughout a directory recursively?
<persia> Mez: Is the nostromo package intended to change these values?  If so, I'll need to reinstall.
<jdong> like a massive sed job :)
<Mez> persia:?
<persia> bddebian: You could take a look at bug 79498.  It's lonely.
<Ubugtu> Malone bug 79498 in libjsw "new upstream version 1.5.6" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79498
<Mez> jdong, I had to read that twice
<persia> Mez: the udev persistent rules.
<Mez> persia, no - they should be part of udev
<persia> Mez: OK.  In that case, I have three lines.  A comment about links, a symlink for mouse* and a symlink for event*.
<Mez> persia: can you pastebin me /proc/bus/input/devices and /proc/bus/input/handlers
<persia> Mez: http://rafb.net/p/5ynYpl40.html
<Mez> persia: try
<Mez> sudo modprobe -r joydev
* persia plugs in a joystick and prepares to reinstall nostromo
<Mez> ... 
<Mez> persia: aha!
<Mez> install it
<persia> Mez: building it still creates nostomo_n50.pid in the parent directory.  I think there may be an issue with make install vs. user installation.
<Mez> persia, well - thats a tiny issue
<Mez> persia, 
<Mez> run the daemo
<Mez> and then tail /var/log/messages
<persia> Mez: nostromo_daemon reports "No configs to use, exiting.".
<Mez> aha
<Mez> run nostromo_config
<Mez> then just create and save a config
<Mez> and then try nostromo_daemon
<Mez> persia, that might be it
<Mez> that just means we need to make a default config and copy it on start
<persia> Mez: It's working.  Either a default config, or a note in README.Debian about the grey screen on first starting.  Also, as the configuration is set during the first run of nostromo_config, /usr/bin/nostromo should probably trigger the daemon to reload the config after nostromo_config exits.  No bug from me.
<Mez> persia, noostromo_config auto-reloads the config
<Mez> but...
<Mez> it's just a default config file to make
<Mez> though
<Mez> eep
<Mez> I gotta change a copuple of things
* jdong watches mplayer and avidemux build happily against shiny new x264 :)
<Mez> and I also gotta find out whats the best way of finding if they have an n50 or an n52
<Mez> hmm - anyone have any experience with presenting the users with options on configure ?
<Mez> actualyl nvm
<Mez> that dont matter
<Mez> persia: at least we know the problem now and it's an easy one to fix
<Mez> persia: what was the issue with the pid file
<persia> Mez: Building the package from source generates a pidfile in the directory in which the .deb is created.  Installation does not appear to generate a pid file.  I'm guessing that the Makefile does something in install that should really be in postinst.
<Mez> kk
<Mez> you mean my rules?
<Mez> or the nostrmoo Makefile
<persia> Mez: upstream Makefile.  Your rules look OK to me.
<Mez> persia: is it a hugs issue?
<persia> Mez: I'd consider it larger than the lack of manpages.  Looking for details now.
<Mez> lol
<bddebian> w00t, got feisty on this POS Dell laptop finally
<Mez> persia - can you email me details - I';ma gonna go have alie down
<persia> Mez: Sure.  Sleep well.
<Mez> <mynick>@ubuntu.com
<Mez> ;)
<jdong> Can a MOTU evaluate bug 80387 and consider sponsoring to Feisty?
<Ubugtu> Malone bug 80387 in x264 "Import 20070116 snapshot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80387
<jdong> Nafallo: you promised to look ;-)
<bddebian> jdong: That looks like waay to much work :-)
<jdong> bddebian: but I've already done all the work :)
<jdong> bddebian: someone just has to push the red shiny upload button for me :D
<bddebian> Damn, network-admin segfaults when I try to configure my wireless :-(
<jdong> bddebian: feisty oopses when loading madwifi, you shouldn't complain :)
<bddebian> jdong: Does slomo know about these?
<bddebian> jdong: And why not update to debhelper 5+ ?
<persia> If both lintian and linda are quiet, is that sufficient indication that the package complies with the Standards-Version: specified in debian/control?
<bddebian> Depends on what "version" of linda/lintian you are running, but generally yes
<persia> bddebian: Something recent.  I also thought lintian would complain if it didn't know about the provided Standards-Version.
<LaserJock> persia: if you are switching standards versions you can read the relevent changelog entries to see what has changed
<bddebian> persia: It should
<persia> LaserJock: OK.  I didn't really want to switch version numbers, but I'll investigate the changelog (for libjsw).
<bddebian> jdong: Did you disappear? :)
<LaserJock> persia: no, I meant the changelog for debian-policy
<persia> LaserJock: Sorry.  Poor grammar compliance in my last statmement.  It should be, I'll investigate the debian-policy changelog in support of a possible standards-version bump for libjsw.
<LaserJock> well, don't bump it unless you need to
<persia> LaserJock: A bump was suggested on REVU and the package was not advocated.
<LaserJock> this is a new package?
<persia> LaserJock: No.  Just a new upstream due to > 1 year since last Debian upload.
<bddebian> Nope but a leap of Debian's version
<LaserJock> ah, ok
* persia thinks updating standards is probably good for this anyway
<bddebian> OK damnit, iwconfig says my wireless is eth1.  But ifconfig eth1 up gives "No such file or directory" and iwlist eth1 scanning doesn't find squat :-(
<bddebian> Ah, it's a stupid broadcom :-(
<ScottK> I'm trying to fix a bug and the unmodified package won't build because there's a non-ascii character in the file (one of the author's names).  I remember reading something about how to deal with this, but can't find it.  Google has failed me so far.  The exact error starts: Non-ASCII character '\xf6'...  I'd appreciate it if someone could give a hint about where in the documentation I find the rule for dealing with this.
<bddebian> ScottK: I can't help ya with that one man, sorry :-(
<ScottK> Thanks anyway.
<ScottK> Are you OK for reviewing packages again?
<bddebian> Hehe, yeah.  Whatcha need?
<Toadstool> ScottK: a python file?
<ajmitch> bddebian is addicted to reviewing
<bddebian> I just wish I was a little better at it :-(
<bddebian> Heya Toadstool
<Toadstool> hey bddebian 
<ScottK> Toadstool: A python package, yes http://revu.tauware.de/details.py?upid=4106
<Toadstool> ScottK: you have to put an encoding header in the first two lines of a python file if it is encoded in something else than ascii
<Toadstool> if it's lets say utf-8, then you would use "# -*- encoding: utf-8 -*-"
<ScottK> Does it go before or after the shebang?
<ScottK> BTW, I got mixed up about which thing you were talking about (both are Python).  What I'm working on is bug #80360
<Ubugtu> Malone bug 80360 in python-dns "Crash - Fails to trap socket.error when network is not available" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80360
<Toadstool> ScottK: after the shebang if there's one
<ScottK> Thanks.
<ScottK> Toadstool: That was exactly what I needed.  Thanks.
<Toadstool> ScottK: you may want to include the patch available at http://bugs.debian.org/378991 too
<ScottK> Hmmm.  I may have had the bug on a BSD system before.
<ScottK> Do I make one debdiff, attached it to bug 80360 and mention in the comments if fixes the other one too?
<Ubugtu> Malone bug 80360 in python-dns "Crash - Fails to trap socket.error when network is not available" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80360
* ScottK goes and looks through the wiki.
<persia> ScottK: When I do that, I mention all the bugs it closes in the changelog.  If there are more than two Ubuntu bugs closed, I usually file a new bug ("improvements to <package>".  Debian bugs get closed for fun.
<ScottK> Thanks.
<persia> libjsw updated.
<jdong> bddebian: sorry, went to sleep for a while; I tried to make my changes minimally invasive....
<jdong> bddebian: much of it derived from the de-facto Ubuntu and debian-multimedia packaging
<bddebian> jdong: NP.  I'll take another look tomorrow I have to get to bed :-(
<bddebian> Gnight folks
<jdong> bddebian: as you can see from the debdiffs I only made the minimum modifications necessary to ge the job done :)
<jdong> bddebian: good night :)
<ScottK> I just attached a fix for bug #80360 to the bug in LP (and subscribed ubuntu-universe-sponsors).  This is the first time I've done this and I'd appreciate it if someone who is experienced would take a look and see if I did it correctly.
<Ubugtu> Malone bug 80360 in python-dns "Crash - Fails to trap socket.error when network is not available" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80360
<persia> ScottK: In your changelog, you should have (closes: 378991) and (closes Ubuntu: #80360) at the end of the lines, rather than at the beginning.  Other than that, it looks good to me.
<ScottK> Thanks.  I'll go fix that.  What's the next step in the process after I fix it?
<persia> ScottK: I'm not sure you need to fix it this time.  Just for the next bug.  After uploading a debdiff, I usually wait between 2 minutes and a week before someone uploads it (depending on complexity).
<ScottK> OK, then I won't redo it.  I guess I'll wait (and finish fixing one more before bed).
<LaserJock> anybody know if falcon has a website?
<ScottK> Falcon the UPS manufacturer?
<LaserJock> no
<LaserJock> falcon the archive manager
<ScottK> No, sorry can't help you then.  
<LaserJock> s/archive/repo/
<LaserJock> ok, any apache people around?
<LaserJock> I wanted to know if I set the allow/deby for <Directory /> if that will apply to all the directories underneath it
<persia> LaserJock: What are you trying to do?  I haven't played with apache in ~5 years, but I may know.
<persia> LaserJock: It used to do so.
<LaserJock> well, I just want to be able to limit what IPs can see my server
<persia> LaserJock: Do any of the child directories under your definition have separate definitions in your congfiguration files?
<LaserJock> hmm, what's the difference between <Directory /> and <Directory /var/www/> ?
<LaserJock> is / really /? I was thinking it was /var/www/
<persia> LaserJock: My memory is that / is /, but that most of it is inaccessible by default.
<LaserJock> hmm
<persia> LaserJock: The interesting effect being that directives applied to / also apply to user directories, whereas directives applying to /var/www don't.
<persia> If I ask for a package to be removed, and it remains in Debian, will it be restored for 7.10?
<LaserJock> persia: no
<LaserJock> not automatically
<persia> LaserJock: I'm considering requesting a drop of freecraft.  It has been replaced by stratagus, but has been maintained by NMU in Debian for the past couple years.  What do you think.
<LaserJock> persia: well, if there is a reason to get rid of it otherwise
<LaserJock> like if it conflicts with stratagus in a way that makes it hard to maintain stratagus
<LaserJock> but otherwise I don't think it really hurts as long as Debian still has it
<persia> LaserJock: The only reason I would use is the cease-and-desist Blizzard sent to the original developers about the name.
<persia> Also, people who want to play something like WarCraft or StarCraft might choose the older engine because of the name.
<LaserJock> oh, well that a cease-and-desist sound a bit serious :-)
<persia> LaserJock: Usually Debian Legal seems on top of these things, but I'm not sure if this is a special case.
<dholbach> good morning everybody
<persia> good morning dholbach
<dholbach> hiya persia
<persia> LaserJock: I can't find a copy online, but http://happypenguin.org/newsitem?id=3801 mentions it.  I'll file a bug.  Thanks for your input.
<LaserJock> hi dholbach 
<dholbach> hey LaserJock
<persia> Why does apropos screenshot tell me nothing?  What package am I missing?
<persia> I just encountered a comment on bug 60305 that the Desktop menu is not supposed to list everything like the Debian menu.  Does anyone know of a resource containing the guidelines as to what should be shown and what not?
<Ubugtu> Malone bug 60305 in xpenguins "shows only on debian menu, not games menu" [Undecided,Unconfirmed]  https://launchpad.net/bugs/60305
<incorrect> can anyone tell me how to download falcon?
<Adri2000> persia: your debdiff for brutalchess is not a merge, a merge is when there are changes in ubuntu. If debian version > ubuntu version (but with no change), you just apply your changes to the debian version and generate a .changes file with -v<current_version_in_ubuntu> (although it's important only if you actually do the upload, otherwise your sponsor will do it when generating the .changes file signed with his gpg key)
<persia> Adri2000: crimsun told me to process that as a merge.  Othewise, I agree.
<persia> Adri2000: My Sponsor?  Do you mean whoever uploads the patch?
<Adri2000> yes
<Nafallo> !info gnome-build
<ubotu> Package gnome-build does not exist in any distro I know
<incorrect> i've registered with launchpad.net and i still can't figure out how to download falcon,  sigh
<jenda> Hello.
<jenda> Anyone here moderating the ubuntu-devel list?
<cypherbios> incorrect: ask Seveas about falcon
<incorrect> seveas is a person?
<jenda> yep
<Seveas> nope
<incorrect> sorry i r blindeded
<incorrect> so how do i get this falcon system of yours?
<imbrandon> incorrect, http://seveas.imbrandon.com/dists/edgy-seveas/extras/
<imbrandon> second package on that page
<incorrect> why thank you
<imbrandon> np
<incorrect> ill have to repackage for dapper
<imbrandon> http://seveas.imbrandon.com/dists/dapper-seveas/extras/
<imbrandon> incorrect, ^^
<incorrect> i wonder for how long its going to be easy to backport to..
<incorrect> :D
<incorrect> well isn't he the coolest
<incorrect> perfect :) i can make distributing my backports to my machines sooo much easier
<zul> whats on the agenda for the motu-meeting?
<gnomefreak> zul: from what i can see there isnt one. the meetings page is empty
<Nafallo> dooh
<Nafallo> I forgot LDAP :-(
<segfault> hallo
<bddebian> Heya gang
<persia> bddebian: hi
<Nafallo> hi bddebian 
<bddebian> Hi persia, Nafallo
<white> bad irssi :(
<danilo_> Hi Every One!!! Someone can tell me how is the mantainer of Anjuta?
<Nafallo> danilo_: we don't have maintainers in Ubuntu :-)
<Nafallo> danilo_: looks like a direct sync from Debian
<danilo_> But who decides what package will be in edgy?
<danilo_> All the packages??
<Nafallo> ehm. I don't quite follow. if a package is in the archive at releasetime it will be included in the actual release.
<danilo_> And if a package had a important update? Packages will be updated?
<danilo_> I'm saying about anjuta... Ubuntu edgy have anjuta2.0.2 package, but is not ready for production because is a alpha version. Now (14st) we have a new 2.1 (beta)....
<Nafallo> we have edgy-{proposed,update} for grave bugs
<Nafallo> new releases probably won't go in if they are not plain bugfix releases. but that's up to folks like sistpoty to ack or nack :-)
<Jozo-> danilo_: And in feisty anjuta is downgraded to 1.x version.
<gnomefreak> yeah :(
<danilo_> Jozo-, Its a good new... =)
<danilo_> Jozo-, But I think that anjuta 2.1 is Ok... But I dont know, I dont had tested yet.
<slomo> anjuta 2.1 is explicitely a development version
* gnomefreak thinks throw it in feisty for testing and when it seems to be "stable" enough throw it in backports or -proposed maybe
<zul> xenman kind of sucks
<jdong> hello, world
<Laser_away> zul: ?
<bddebian> Heya jdong
<jdong> hi, bddebian :)
<jdong> good morning :)
<zul> Laser_away: program i dont know how to use yet
<somerville32> dholbach, You program in LPC too! :)
<dholbach> somerville32: how do you know?
<somerville32> Your wiki page
<dholbach> ah :-)
<dholbach> somerville32: you're playing in a mud too?
<somerville32> Well, I've played a few muds but I do mostly development.
<somerville32> I was working on my own mudlib from scratch before devoted my life to Ubuntu, lol
<dholbach> somerville32: which muds were those?
<somerville32> Turning Point Mud, SWMud, Imperial Expansion, RotM, and few other ones
<dholbach> somerville32: ahhhh, so you know elkbuntu from RoM?
<somerville32> elkbuntu played on RotM? I didn't know that, lol
<dholbach> you mean Realm of Magic?
<somerville32> No, Realm of the Magi
<dholbach> ah ok
<dholbach> then that's something else
<somerville32> ah
<jdong> grr, is there any simple way to launch an application without network access?
<jdong> without disabling network for the rest of the system
<jdong> I have a leaky app that I'd like not to talk to a network
<somerville32> I'd say my favourite mud of all time was Turning Point Mud. It was role play intensive and a ton of fun. I was a druid a part of a cult religion that believe that industrialized cities were killing the forests. So we'd go pillage villages - one time we even destroyed an entire village. Lots of drama... good time, good times.
* somerville32 can't type. : (
<gpocentek> welcome here devilsadvocate ;)
<devilsadvocate> hello gpocentek 
<devilsadvocate> i've been trying to make a .deb of something. It refuses to accept my changelog file. Nothing i found online helped
<gpocentek> what is the exact error?
<devilsadvocate> paste here?
<devilsadvocate> its 2 lines
<gpocentek> ok
<devilsadvocate> parsechangelog/debian: error: unrecognised line, at file debian/changelog line 3
<devilsadvocate> dpkg-buildpackage: unable to determine source package is
<gpocentek> devilsadvocate: now could you pastebin the changelog?
<devilsadvocate> one sec
<devilsadvocate> gpocentek, http://paste.ubuntu-nl.org/2066/
<Mez> devilsadvocate, space before -- :P
<gpocentek> devilsadvocate: you need 2 spaces before the '*', and 1 before the '--'
<Mez> double space before *
<Mez> http://paste.ubuntu-nl.org/2067/
<devilsadvocate> will try now
<devilsadvocate> ok.. now its changed to a badly formatted trailer line (line 5)
<gpocentek> you need 2 spaces between "Thu," and "18" in this line
<devilsadvocate> no comma?
<gpocentek> keep the coma
<gpocentek> comma*
<devilsadvocate> no good
<gpocentek> hm, what's the error?
<gpocentek> still the same?
<devilsadvocate> parsechangelog/debian: error: badly formatted trailer line, at file debian/changelog line 5
<devilsadvocate> yes, the same
<gpocentek> it try with this line:
<gpocentek>  -- Chintalagiri Shashank <chintal@iitk.ac.in> Thu,  18 Jan 2007 21:52:02 +0530
<gpocentek> don't drop the space at the beginning of the line
<devilsadvocate> the error changed now
<devilsadvocate> found eof where expected more change data or trailer at .. 
<devilsadvocate> maybe i missed the newline character
<gpocentek> I think so
<devilsadvocate> no. this time it gave the error on line 6 instead of 5
<devilsadvocate> but otherwise the same
<devilsadvocate> http://paste.ubuntu-nl.org/2069/ - the new changelog as well as the error
<gpocentek> let's try a 'dch -e'
<gpocentek> it might fix it
<gpocentek> ah, only *1* space at the beginning of the 5th line
<devilsadvocate> just typing dch -e in the source folder gives the same error
<gpocentek> you have 2 spaces
<devilsadvocate> ok
<devilsadvocate> changed back to one
<devilsadvocate> error is identical as before
<devilsadvocate> badly formatted trailer line :|
<Mez> devilsadvocate, delete the changelog then try dch -e
<devilsadvocate> dch -e --create ?
<devilsadvocate> ok it worked
<devilsadvocate> any idea what was wrong?
<gpocentek> Mez: congrats ;)
<gpocentek> devilsadvocate: no idea
<devilsadvocate> gpocentek, thanks :)
<Mez> gpocentek, congrats on what ?
<gpocentek> Mez: you found a solution
<Mez> devilsadvocate, did yhou try and create it yourself or something /
<Mez> gpocentek, if all eslse faisl delete and use the proper tools to make
<devilsadvocate> Mez, no i did not, but i must have accidentaly removed one of the many essential spaces :P
<devilsadvocate> where are the tags used for the ./configure stored? for some reason its trying with host=i486-linux-gnu
<devilsadvocate> (i have i386)
<Mez> devilsadvocate, o_O thats surely old... i386's havent been seen in about 2 years
<devilsadvocate> Mez, my laptop is a P3 800 mhz thing
<Mez> thats still i486 :P
<devilsadvocate> i suppose it can run i686, but i didnt bother changing
<Mez> or even 686 :P
<slomo> even i686
<devilsadvocate> hm
<slomo> but every package is compiled for i486
<devilsadvocate> then why does ubuntu  ship with i386?
<devilsadvocate> hmm
<devilsadvocate> ok
<devilsadvocate> i know this migh tbe the wrong place, but what do i do if it says
<devilsadvocate> invalid host type ?
<slomo> broken configure script
<devilsadvocate> http://paste.ubuntu-nl.org/2070/
<devilsadvocate> i was able to configure and make the same package normally earlier
<devilsadvocate> ./configure && make work perfectly even now :(
<Toadstool> heya here
<bddebian> Hi Toadstool
<Toadstool> hey bddebian 
<bddebian> slomo: Have you seen / heard about jdong's ffmpeg stuff?
<slomo> bddebian: no... wha did he do?
<bddebian> ANd update to x264 from SVN that has better thread support I guess
<slomo> what did he do to ffmpeg? :)
<slomo> x264 is probably fine
<bddebian> Damn, now I can't find the bug#
<crimsun> slomo: bug 80387
<Ubugtu> Malone bug 80387 in x264 "Import 20070116 snapshot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80387
<bddebian> That's it
<bddebian> thx crimsun
<crimsun> note that jbailey mentioned some hours ago a possible ffmpeg snap update
<crimsun> (rather, he was wondering if it were feasible)
<slomo> yeah, i told him that it might become a nightmare
<crimsun> s/might// , but yeah :)
<crimsun> api? abi? wots dat?
<jdong> slomo: well, I've been messing around with it for about a month now; ffmpeg of course is unaffected
<jdong> (since in Ubuntu it doesn't build against x264)
<jdong> but either way I patched ffmpeg so IF someone wanted to build it against x264, it'd function
<jdong> slomo: btw, mplayer doesn't build against feisty's caca anymore
<slomo> yeah, one has to include headers for a compat api
<slomo> should be easy to fix
<jdong> crimsun: I've messed around with a ffmpeg cvs build... it works, if you don't call ffmpeg to do any encoding
<jdong> crimsun: the whole encoder API/ABI has changed somewhat
* crimsun collapses in laughter
<crimsun> "somewhat"...yeah.
<slomo> :)
<jdong> :)
<slomo> i'll just won't touch that insanity anymore unless necessary ;)
<jdong> slomo: so.. do you think the new x264 looks ok?
<Mez> bddebian, I'm not very good at building man pages
<slomo> jdong: from a short look... yes. i don't have time for a deeper review and uploading now though :/
<jdong> ok
<bddebian> Mez: Who is? :)  help2man
<nixternal> Mez: man pages are easy :)
<slomo> bddebian: so if you want to upload... :)
<Mez> it doesnt have a help either
<bddebian> slomo: OK I'll take a look in a bit
<nixternal> Mez: docbook2x-man
<nixternal> is this for katapult?
<Mez> nixternal, I'm no good at docbook either
<Mez> nixternal, no 
<Mez> http://revu.tauware.de/details.py?upid=4094
<nixternal> Mez: i can help you out with it, or convert what you have to docbook
<Mez> nixternal, katapult has a man page
<nixternal> good :)
<nixternal> also has one hell of a handbook as well :)
<Mez> oh, actuallym no it doesnt
<nixternal> nostromo, is that for the gaming controlers?
<Mez> nixternal, if it installed the hand book properly
<Mez> nixternal yeah it is
<nixternal> Mez: it will have a man page then if there isn't one yet
<nixternal> i sold that thing on ebay years ago :)
<Mez> nixternal: they're awesome thoguh
<nixternal> Mez: i will find out from Phil Rodriguez how to get the handbook to build when using cmake
<nixternal> i could never get used to it
<Mez> I shuld go buy some food at some point
<nixternal> ya same here. im at school starving right now
<nixternal> i would goto a restaurant, but parking is nuts right about now
<nixternal> took me 30 minutes to get my spot
* Mez sighs
<Mez> I need someone to go out with
* bddebian volunteers ;-P
<Mez> bddebian, in birmingham ? :P
<bddebian> Nah, I'm in Philly
<somerville32> Fly me and I'll go
<Mez> too far away :P
<Mez> bddebian, oxford is closer to go poke the emo horse (resiak)
<nixternal> hahahahahahahahahahaha
<Mez> though poking the emo horse sounds wrong
<nixternal> bddebian: little did Mez not let you know, is you have to do more than first base on the first date :)
<nixternal> Mez: poking the emo horse sounds better than bddebian wanting to go on a date with ya :)
<nixternal> that would be the emo ponie
<bddebian> hmm
<nixternal> pony as well
<Mez> nixternal, true :P shame that it's not last thrusday
<nixternal> bddebian: i didn't know you were in icky philly
<Mez> i coulda gone to the local LUG meeting
<Mez> and annoyed Keybuk
<bddebian> nixternal: I don't live in Philly, I just work here :-(
<Mez> ooh
<Mez> whens the next wolvesLUG meeting
<nixternal> heh
<nixternal> bddebian: even being close enough to work in philly is bad enough
<Mez> well it aint today - jono's at LCA :P
<nixternal> i almost moved to York to be a cop at one point, but someone decided to offer me a computer job out of the military paying more than a cop could ever steal :)
<Mez> hmm
* Mez needs to learn bash scripting
<nixternal> Mez: i have been trying to teach myself, and little by little...ahh who am i kidding, i still suck!
<Mez> i just need to do a 
<Mez> if this file exists - run this - if not - check whether this or this is plugged in and copy the config file to the home directory
<Mez> THEN run that
<nixternal> i need to do the same that when i boot up my computer and it sees i have an external mouse connected, to then run 'synclient TouchpadOff=1'
<Mez> lol
<Mez> nixternal, this is for the nice shiny nostromo driver
<somerville32> Bash scripting is easy
<somerville32> :] 
<Mez> somerville32, wanna write a script for me then ? :P
<somerville32> lol
<somerville32> Send me the details
<somerville32> and sure
<Mez> email ?#
<somerville32> cody-somerville@ubuntu.com
<nixternal> somerville32: while you are at it, either 1) write a script to shut off synaptics w/ external mouse present, or 2) just make it work in *buntu :)
<somerville32> lol
<nixternal> im not laughing :)
<somerville32> I imagine that would be possible with dbus and hal
<nixternal> ok, maybe i am a little bit
<nixternal> well, neither one of them are on IRC :)
<nixternal> hahahaha
<nixternal> in other words, if I knew how to talk to them correctly, then I would do it
<somerville32> send me an e-mail and I'll look into it
<nixternal> that's it! i have to do a silly c++ project for school, i will get that to work :)
<somerville32> : )
<nixternal> ok, off to my next class
* somerville32 waves.
<Mez> somerville32, sent
<somerville32> Ok, it is added to my queue : )
<Mez> nixternal nixternal ....
<Mez> er
<Mez> cat /proc/bus/input/devices | grep mouse | grep Handlers | wc -l
<Mez> ;)
<Mez> should tell you how many mice you have connected
<somerville32> 1
<Mez> so if >1 then turn off synaptics ;)
<somerville32> Mez: So you want him to create a script that sits in a loop checking or what?
<Mez> somerville32, he just wanted on boot right ?
<Mez> <nixternal> i need to do the same that when i boot up my computer and it sees i have an external mouse connected, to then run 'synclient TouchpadOff=1'
<somerville32> "1) write a script to shut off synaptics w/ external mouse present"
<somerville32> The latter, I'm sure, would be optimal.
* somerville32 huggles event-based programming.
<Mez> somerville32, yeah i was thinking poke hal or maybe even upstart
<somerville32> So, hal will notify his script via dbus when a mouse is plugged in or removed and enable synaptics accordingly.
<Mez> somerville32, indeed
<Mez> but that needs a script first
<somerville32> And thats where I come in ;] 
<Mez> somerville32, well my oone's a lot easier :P
<somerville32> Yes but less versatile
<Mez> lol
<Mez> it's just something i need to make for this fdriver
<somerville32> I think the goal was to make the process seamless 
<Mez> we on about ym script of nixternal's ?
<somerville32> I haven't reviewed your e-mail yet
<ajmitch> hi
<bddebian> Heya ajmitch
<jesper> Is universe freezed after a release.. or is it possible to get fixes into edgy -universe now? 
<Nafallo> jesper: frozen
<jesper> So no fixes for "broken stuff". 
<jesper> $ pymol
<jesper> /usr/bin/pymol: 8: python2.4.4: not found
<jesper> :-/
<LaserJock> jesper: it's possible to get things updated
<Nafallo> !info clutter
<ubotu> Package clutter does not exist in any distro I know
<LaserJock> jesper: but it's not trivial by any means
<LaserJock> jesper: have you checked pymol bugs? I think I saw somebody already requesting a fix for that
<jesper> Yes.. it has been reportet.. but not fixed in edgy/universe. 
<LaserJock> jesper: there is now SRU comments, or bugs?
<LaserJock> *no
<jesper> SRU ? 
<Adri2000> Stable Release Update
<ajmitch> LaserJock: don't confuse people with TLAs
<Adri2000> eheh
<jdong> SRU? TLA? WTF? g2g gg gl hf nr20 tvb go!
<jesper> https://bugs.launchpad.net/ubuntu/+source/pymol/+bug/65964
<Ubugtu> Malone bug 65964 in pymol "Pymol does not start because of wrong python interpreter name in start script" [Undecided,Fix released]  
* ajmitch looks for some way to kick jdong 
<jdong> good to see you too, ajmitch  :(
<jdong> ;-)
<jesper> I don't know what more to do.. 
<jdong> btw where's the SRU for Azureus?
<jdong> ;-)
<ajmitch> why haven't you done one?
<jdong> ajmitch, I did prepare the initial packaging; fujitsu made an upload into feisty for it
<jdong> and nothing has happened in Edgy yet
<ajmitch> then why complain? :)
<jdong> because nothing has happened in Edgy yet
<jdong> bug 42269
<Ubugtu> Malone bug 42269 in azureus "[SRU]  Does not create a tray icon" [Undecided,In progress]  https://launchpad.net/bugs/42269
<jdong> that's the one
<jdong> a debdiff for SRU is posted, crimsun +1'ed it... so what comes next?
<ScottK> I have a question about the Python transition ...  I have two Feisty chroots, both with Python2.5.  One the first usr/bin/python is dated Jan 16 and my package builds fine.  I made a new one this morning after a MOTU reported my package FTBFSed for him and now I have the same error in my new chroot.  Package still builds fine in the old chroot.  The package is here - http://revu.tauware.de/details.py?upid=4106 and the err
<ajmitch> jdong: it needs more people to approve it
<ScottK> cd . && python setup.py install --root=/tmp/buildd/pyspf-2.0.3/debian/python-spf/ --no-compile -O0
<ScottK> running install
<ScottK> error: invalid Python installation: unable to open /usr/include/python2.5/pyconfig.h (No such file or directory)
<ScottK> make: *** [python-install-py]  Error 1 
<ScottK> Oops - sorry about the high speed paste.
<ajmitch> ScottK: python-all-dev or similar
<ScottK> Thanks.  Will try that.
<jdong> ajmitch, what can be done to make that happen? It seems like leaving it alone, it's faster to wait for Feisty :)
<ajmitch> there should be a page on the debian wiki about the new python policy, it should give info about build depends
<ajmitch> jdong: be patient
<allee> !sync
<ubotu> Sorry, I don't know anything about sync - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<ScottK> ajmitch: There is some info on one of the pages, I think it may need updating though.  Once I figure this out, I will try to update it.
<LaserJock> hmm, this person on -motu wanting MMS packaged
<ajmitch> LaserJock: did you decide on wiki vs bugs for candidates?
<LaserJock> he's also got debian-mentors working on a Debian package
<LaserJock> ajmitch: we're going to do bugs, but it's going to take a little bit. I need an LP bug fixed first
<LaserJock> ajmitch: because we're going to use a tag to do it
<ScottK> ajmitch: Thanks.  That worked.  I added some words in the Python packages section here: https://wiki.ubuntu.com/MOTU/Packages/Packaging/Tips.  I'm sure it could be more elegent and more correct, but it's a start...
<tsmithe> LaserJock, are you free to revu?
<LaserJock> tsmithe: what package?
<tsmithe> alsa-firmware/alsa-tools pleases
<tsmithe> :)
<slomo> LaserJock: MMS?
<LaserJock> slomo: that thread on -motu
<crimsun> slomo: (RE: uploads) it's bug 44147 if you'd like to sub
<tsmithe> the lintian errors on alsa-firmware about the linking of some firmware are due to the firmwarey nature of the package
<Ubugtu> Malone bug 44147 in soyuz "GPG public key verification failure resulting in UploadError" [High,In progress]  https://launchpad.net/bugs/44147
<slomo> crimsun: thanks
<LaserJock> slomo: My Media System I guess
<LaserJock> tsmithe: I don't think I have time for them anytime today, sorry.
<tsmithe> ok that's cool
<tsmithe> anyone else?
* Hobbsee waves
<ajmitch> hello Hobbsee 
<tsmithe> Hobbsee, free to do reviewage? :P
<tsmithe> ajmitch, ?
<LaserJock> Hobbsee!! waht are you doing up?
<ajmitch> no
<tsmithe> ok
<Hobbsee> hey ajmitch, LaserJock, and tsmithe :)
<tsmithe> hi Hobbsee
<tsmithe> how's it going?
<Hobbsee> LaserJock: work soon.  and steve had to go to work (and that's where i went last night)
<Hobbsee> good.  went to LCA open day and the dinner after :)
<Hobbsee> tsmithe: i'll be right...
<tsmithe> Hobbsee, right...?
<Hobbsee> tsmithe: in not doing revuage :P
<tsmithe> :)
<Hobbsee> ajmitch: LaserJock tsmithe didnt see jono doing the bottle dance though...
<tsmithe> i don't believe i did
<tsmithe> thought i sure heard of it
<LaserJock> Hobbsee: I missed it :(
<Hobbsee> LaserJock: :(
<Hobbsee> tsmithe: yes.  saw pictures of the last bottle dance - but he wasnt bottle dancing last night
<LaserJock> I was probably in bed being responsible at the time
<Hobbsee> probably as his beer was in a glass...
<tsmithe> what happened last night?
<LaserJock> no late-night carousing for this chemist ;-)
<LaserJock> hmm, do they call chemists chemists in AU, Hobbsee?
<Hobbsee> LaserJock: or pharmacist, maybe.  chemist as in chem student?  that's more just a scientist
<Hobbsee> tsmithe: ubuntu dinner after LCA open day
<Mez> hub, can I have rob's donuts ?
<LaserJock> Hobbsee: but a scientist could be anything ... a biologist even ;-)
<LaserJock> Hobbsee: horrible
<hub> Mez: no they are for me :-)
<Mez> hub :(
<Hobbsee> LaserJock: true
<hub> Mez: I unbroke the build
<Mez> hub but still... :( donuts :P
<hub> mmm beer :-)
<tsmithe> Hobbsee, aahh
* crimsun pokes LaserJock 
<crimsun> don't crack on biologists ;)
#ubuntu-motu 2007-01-19
<ajmitch> crimsun: do you know some biologists? :)
<LaserJock> crimsun: but ... but ... they're hardly scientists at all
<LaserJock> just a shade above social scientists :/
<ajmitch> now be careful, LaserJock 
<LaserJock> ;-)
* ajmitch has some good friends who are microbiologists
* LaserJock resists starting on engineers
<LaserJock> well, as an undergrad I was a jack-of-all-trades
<ajmitch> we'll forgive you
<LaserJock> my senior research project was chasing rare hawks around the woods
<ajmitch> such a shame you had to throw your life away on chemistry though
<LaserJock> ajmitch: bah, whatever
<LaserJock> I'd much rather be figuring out how the fundamental elements of the universe work together to produce everything
<ajmitch> LaserJock: admit it, you'd rather be up to your eyeballs maintaining someone else's bitrotten code
<LaserJock> ...
<tezem> hi, I just found out about REVU and because I am an Arch Linux user I would like to see that this REVU system works as easy as aur.archlinux.org . Is it planned to make the upload process of new packages easier for everybody? It's hard if you have to be approved to be able to upload something.
<LaserJock> tezem: in the future it will probably be a little bit easier
<LaserJock> tezem: but we can't have random people/bots uploading stuff
<ajmitch> not that the barrier or any checking is particularly robust
<tezem> LaserJock: Why not just making it like Archlinux? Registering is all you need to do and you can put your packages into a database. People can use them for their own risk and if enough votes come together the package will be taken into a community repo.
<LaserJock> tezem: well, to be honest, I'm not sure that we'd be very enthusaiatic about the idea
<LaserJock> we have a pretty low barrier for somebody wanting to have their work in an official repo
<LaserJock> all you need is to register and have a gpg key
<tezem> yeah the gpg key idea is good but I read that I have to wait for approval to be added to some keyring or something. Thats not good
<LaserJock> tezem: that's more or less not an issue anymore
<LaserJock> and was just there because of some technical issues with using Launchpad for authentication
<tezem> Ah ok then it's already the same idea as the AUR in Arch with the addition of using gpg signing, if i understood right.
<LaserJock> tezem: probably
<LaserJock> it's not perfect
<LaserJock> and will probably be integrated more into Launchpad in the future
<crimsun> LaserJock: yeah, I'm kinda partial to biology, since it was my first undergraduate major.
<persia> crimsun: You wanted to ask me about the icon location for uqm?
<crimsun> persia: is there a reason it's hardcoded as such? Does it reside in that same package?
<persia> crimsun: The icon belongs to uqm-content, which is CCA-NC-SA.  I'm not convinced I have the right to copy it, convert it, and add it to uqm, which is GPL.
<crimsun> so the Icon location is broken?
<persia> crimsun: That seemed the best solution.  The other would be to also change uqm-content, which allows modification for distribution as part of uqm.
<crimsun> http://creativecommons.org/licenses/by-nc-sa/2.5/  <-- ?
<persia> crimsun: Yes.
<crimsun> what would prevent you from copying it?
<crimsun> the commercial clause?
<crimsun> or rather, the noncommercial clause
<persia> crimsun: SA requires that it be distributed under the same license.  uqm is GPL, which is a different license, and the icon ideally belongs in the same package as the menu file and .desktop.  I could also modify uqm-content to put it in /usr/share/pixmaps, if you think that is better.
<crimsun> persia: where on http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode is it stated that non-derivative works must be distributed under the same license?
<persia> crimsun: I believe 4a applies.
<persia> crimsun: It's not non-derivative.  I was using an icon from uqm-content.
<crimsun> right, and since uqm-content is not a derivative work of uqm, there's no restriction on the license of the collective.
<LaserJock> persia: why can't you put the icon from uqm-content into uqm?
<crimsun> "The above applies to the Work as incorporated in a Collective Work, but this does not require the Collective Work apart from the Work itself to be made subject to the terms of this License."
<LaserJock> just put it there
<persia> LaserJock: Are you sure Ubuntu can distribute a CCA-NC-SA icon under GPL?
<LaserJock> why would be it be under GPL?
<crimsun> it's not under GPL.
<persia> LaserJock: uqm is GPL
<LaserJock> so what?
<LaserJock> that doesn't matter
<crimsun> see the above section I just quoted, persia 
<LaserJock> we put mixed licensed material together all the time
<LaserJock> you just need to say in debian/copyright what the license is for that file, etc.
<persia> crimsun: Thanks.  I misunderstood that bit.  I'll update.
<LaserJock> persia: are you sure that it's NC ?
<persia> LaserJock: I thought GPL was considered OK for universe inclusion, and CC-NC-SA required multiverse (certainly debian non-free), and that a mix across those lines what not ideal.
<LaserJock> I think that would make it undistributable in Ubuntu
<persia> LaserJock: It says so in debian/copyright.  uqm-content is multiverse.
<LaserJock> well, if CC-NC-SA is indeed distributable in multiverse it would just mean that uqm and uqm-content would go in Multiverse
<LaserJock> does uqm depend on uqm-content?
<persia> LaserJock: Yes, (and is also in multiverse).  I'll go update the licenses...
<LaserJock> I'm suspicious that CC-NC-SA is not distributable
<LaserJock> you might want to ask somebody like mdz about that
<persia> LaserJock: Why?  As long as it is downloaded for free (and multiverse isn't supposed to be on CD), and not resold by downstream distributors (who should check debian/copyright before planning a CD), it should be fine.
<LaserJock> well, that second part would be the problem
<LaserJock> although I think I recall mdz saying that the "must be usable by all" thing didn't apply to Multiverse
<persia> LaserJock: Do you really think Ubuntu can get in trouble if some third party downloads something from the repositories, clearly marked as Non-Commercial, and then attempts to sell it?
<LaserJock> although I think that doesn't make much sense
<LaserJock> persia: well, it does have ramifications
<LaserJock> for instance, you are supposed to be able to freely distribute Ubuntu
<LaserJock> so a commercial organization should be allowed to sell and Ubuntu derivative
<LaserJock> but if I remember correctly mdz said that didn't apply to Multiverse, although I don't know why it shouldn't
<lifeless> multiverse has differently licencesed software in it
<persia> LaserJock: My understanding is that multiverse contains lots of random unsupported stuff which users might like, but which may not fit with the general licensing guidelines of Ubuntu (yet may stil be distributed).
<LaserJock> persia: yes, so it can be closed source
<LaserJock> but it needs to be distributable
<LaserJock> and that's the point
<LaserJock> is how far you take distributable
<LaserJock> whether it just means distributable by us
<persia> LaserJock: Distributable by the Ubuntu mirrors, not necessarily distributable by others, I think.
<LaserJock> or distributable by any derivative
<LaserJock> persia: well that's not the case for other components, that's what I'm saying
<LaserJock> but I think multiverse is the lone exception
<persia> LaserJock: That matches my understanding.
<LaserJock> although, I don't think it's very nice to have that exception
<LaserJock> persia: I guess that is consistent with "The onus is on you to verify your rights to use this software and comply with the licensing terms of the copyright holder."
<LaserJock> although my understanding of Multiverse has been more "closed source by freely distributable"
<persia> LaserJock: That's the clause.  From what I've seen, much of multiverse is non-commercial, or non-military, or, licensed under a strange license (You can do anything you want with this code, but don't bug me!), or something else.
<LaserJock> well, I put some rather funky stuff in there myself
<LaserJock> what I don't like about the idea of "this may or may not be redistributable" is that derivates have a hard time checking *every* package to see if they are ok in distributing it
<LaserJock> but Multiverse is so weird anyway, and that clause is fairly clear, I can't see much of a problem
<LaserJock> if Universe had such a clause I'd be very worried
<persia> LaserJock: Derivatives only have to check in Multiverse, and only if they have a different distribution policy than Ubuntu.  There aren't that many packages anyway.
<persia> It appears that Joey went to some trouble to repack to avoid CC in uqm.  I think I'll just install uqm.xpm in uqm-content, so as to avoid rewriting debian/copyright.
<LaserJock> well, as my dad would say, "Shoot yourself"
<LaserJock> hmm, that really doesn't come across as well on IRC ;-)
<jdong> that's what my priest said to...... never mind
* jdong getting hell tickets for that one
* persia grumbles about "canonical" meaning something different in LP bugs than in other contexts.
<shawarma> I forget: What's the procedure for adding new packages to universe? Upload to revu and get approval from two other MOTU's?
<Nafallo> yes
<ajmitch> that's the procedure some motus follow 
<bronson> Is there an easy way to run build-dep inside a pbuilder environment?
<bronson> I'm building Ubuntu kernels and just installing all the deps takes a long time.
<bronson> It would be nice if they were already inside the tarball...
<ajmitch> you could stuff them in the base tarball with pbuilder login --save-after-login
<ajmitch> ie, login, install, logout
<bronson> ajmitch: that makes sense.  I'll try it.
<bronson> Thanks.
<shawarma> ajmitch: ...and the one we all *ought* to be following, yes?
<shawarma> sorry for going away after asking a question, by the way. 
<ajmitch> shawarma: considering that a large number of MOTUs are core devs as well, working on various things
<ajmitch> so pushing *everything* through REVU becomes a bottleneck
<ScottK> Speaking of REVU, I have two Python packages (one upstream update of an exisiting package - http://revu.tauware.de/details.py?upid=4114 and one new package -http://revu.tauware.de/details.py?upid=4115) if any MOTUs are available.
<bddebian> Heya gang
<persia> hi bddebian
<bddebian> Hi persia
<ScottK> heya bddebian!
<bddebian> Hi ScottK
<bddebian> Anyone ever gotten a broadcom wireless adapter to work without ndiswrapper?
<wasabi_> Anybody planning on packaging gimmie?
<ScottK> Heya bddebian: I see you are revuing...  I uploaded a new package today that I'd appreaciate a look at http://revu.tauware.de/details.py?upid=4115 and on the broadcom thing - I've never actually managed to get ndiswrapper or madwifi to work, I just have to find wireless cards that are supported in the kernel.
<bddebian> I refuse to use ndiswrapper but I can't find my damn Orinico card :-(
<ScottK> I'm currently stuck at my desktop because we are down one laptop and my wife needs to take one to work tonight.
<ScottK> I had to swap out the hard drive so she could dual boot into Windows :-(
<bddebian> Heh
<bddebian> I don't have that problem since I have 10 machines in my house now :-)
<ScottK> I'm just short functioning laptops.  Got lots of others...
<ScottK> bddebian: Thanks.  I've another clean one for you if you're up for it: http://revu.tauware.de/details.py?upid=4114
<bronson> ajmitch, Here's how to automate adding build-deps to a pbuild environment: http://wiki.u32.net/Dpkg/pbuilder/deps
<bronson> You put me on the right track.
<jdong> bddebian: thanks for your help on the x264 stuff.... I just noticed PPC failed while other arches are ok.... drats :)
<jdong> anyone have a PPC and some time to spare?
<bddebian> I wish I had a PPC :-(
<jdong> googling seems to indicate it has something to do with altivec....
<bddebian> w00t, I have wireless with this POS broadcom
<ajmitch> congrats
* jdong needs to test some ppc code :(
<jdong> bddebian: wrt the FTBFS, I think adding -faltivec to PPC CFLAGS will fix it
<jdong> bddebian: that's line 166 of configure
<jdong> apparently -maltivec is not sufficient :)
<jdong> bddebian: actually, one sec, I'll prepare you a debdiff with a more sane fix
<jdong> bddebian: http://paste.ubuntu-nl.org/2120/
<jdong> voila, debdiff 
<bddebian> jdong: It's up
<jdong> bddebian: cool, cross our fingers :D
<jdong> and curse PPC @ the same time :D
<bddebian> heh
<Mez> how do i use rsync through ssh
<jdong> Mez: rsync -av -e ssh host1:/path host2:/path
<Mez> worked it out
<jdong> actually you don't even need -e ssh; it's assumed nowadays
<Mez> jdong: whee :D now I have my apt-repo
<bddebian> w00t Mez :)
* Hobbsee waves
<bddebian> Heya Hobbsee
<persia> hi Hobbsee
<Hobbsee> heya bddebian, persia 
<persia> For iceweasel/icedove dependencies, do these just get updated to firefox/thunderbird (same versions)?
<Mez> ffs 
<Mez> I dont think my oven works
<ScottK> Good night - bddebian: Thanks again for the REVU.
<Mez> anyone good at bash scripting want to help me convert this http://rafb.net/p/3E1f1116.html into a proper bash script
<bddebian> GNight ScottK, NP
<bddebian> Ack, me too.. Gnight gang
<Lutin> Mez: what's the 'exists' function ? Is it just a test 'file exists' ?
<Mez> yeah
<Mez> I got it anyways
<jdong> night, bddebian
<Mez> Lutin, http://rafb.net/p/qBwLWl29.html
<persia> Mez: http://rafb.net/p/qMlyNI65.html
<jdong> Mez: see, exactly what I told you ;-)
<Mez> ;)
<jdong> only persia did it all for you ;-)
<persia> jdong: Mez did it himself about 13 seconds before I could :)
<Mez> jdong: as I did myself just before
* Mez sighs
<Mez> now I just need man pages
<jdong> oh dear lord, man pages
<Mez> jdong: my thoughts exactly
<Mez> jdong: it's better than trying to backport gstreamer anyways
<Lutin> Mez: seems to be some weird logic in your script
<Mez> Lutin... how so ?
<jdong> Mez: yikes :)
<Lutin> Mez: you do if [ -f ~/.nostromorc ]  ; then; else ....
<Mez> jdong: backportingn gstreamer works
<Lutin> if you have something esle than [ -f ~/.nostromorc ] 
<Mez> just the thing i was backporting it for doesnt
<Lutin> the works would already have been true
<Lutin> erek.
<Lutin> the first test
<Mez> Lutin ...
<Mez> exactly
<Mez> BUT ...
<Mez> the code in the else will copy the file to where it should be
<Mez> if it doesnt exist
<Mez> if there is nothing plugged in that matches the hardware
<Mez> it wont copy it
<jdong> Mez: gstreamer is still on 0.10, just point-releases right?
<Mez> meaning it wont exist
<jdong> Fedora backports all the point-releases as official updates
<Mez> jdong, yeah 0.10.10 -> 0.10.11
<jdong> yeah, I'd expect that to work
<Mez> jdong it does
<Mez> cept
<Mez> <Mez> Argh! Something went wrong and a serious error occurred:
<Mez> <Mez> Your GStreamer installation is missing a plug-in.
<Mez> <Mez> gstdecodebin.c(1668): gst_decode_bin_change_state (): /timeline/playbackbin/Instrument_0/gnlcomposition0/Event_1/internal-decodebin
<Mez> <Mez> It is recommended that you report this to the Jokosher developers or get help at http://www.jokosher.org/forums/
<Mez> Lutin, check the script again ;)
* Mez pries off his backspace key and sees what's under there
<Mez> 
<jdong> Mez: lovely :)
<Mez> ] =
<Mez> ] 0000000000000
<jdong> Mez: and on TLTS near new year's IIRC there was a informal mention of a backport request for jokosher too :D
<Mez> ] 0000000000000
<jdong> I was listening to the podcast and just grinned
<Mez> TLTS?
<Mez> apologies about the spam there
<jdong> linux link tech show
<jdong> missing an L because it's midnight
<Mez> never heard of it 
<Mez> there hasnt been one on LR and they're the developers of it
<Mez> lol
* Mez is syncing his jokosher backport to his personal apt repo
<jdong> jono and a bunch of british/australian/non-american accented people do it
<jdong> lmao
<jdong> excuse the offensive remark :)
<LaserJock> so jokosher isn't in Main yet?
<Mez> jdong: you sure you dont mean http://www.lugradio.org/
<Mez> LaserJock, nope
<Lutin> Mez: ok, I understand now ;)
<LaserJock> anybody want to write up a MIR for jokosher?
<jdong> Mez: yeah, that's the one
* jdong gets all his podcasts mixed up :)
<Mez> jdong: I didnt hear that one :P
<Mez> I remember them saying "oh, it might get backported"
<Mez> but thats what prompted me to do it
<jdong> Mez: :)
<jdong> if I was less lazy at the time I would've started messing with it too
<Mez> lol
<jdong> that's about as subtle as a backport request could be for me :D
<jdong> but audio editing wasn't an itch I had to scratch
<Mez> ooh
<Mez> pizza
<Mez> bugger
<Mez> put my poven in wrong mode
<Mez> gotta wait another 25 mins
<jdong> GOD FSCK IT
<jdong> http://librarian.launchpad.net/5788159/buildlog_ubuntu-feisty-powerpc.x264_1%3A0.cvs20070117-0ubuntu2_FAILEDTOBUILD.txt.gz
<jdong> GRR
<jdong> any altivec genies around here?
<jdong> possible solutions: (1) nobody cares about PPC. screw it and move on blessing i386/x86_64/ia64/sparc with x264 good ness
<jdong> (2) Reverse svn changeset that added altivec optimizations
<jdong> which is worse?
<Lutin> gotta leave, bye
<ajmitch> pango is so messed up right now
* ajmitch looks for bug reports
<LaserJock> so we're supposed to put down the time we voted on the wiki page?
<ajmitch> & the mailing list
<Hobbsee> LaserJock: yes
<ajmitch> which I haven't done
<ajmitch> since I'm slack & lazy
* Hobbsee only did the wiki page
* jdong reverts upstream altivec optimizations in a last-ditch effort to make it compile under ppc
<LaserJock> why do we need it on the mailing list too?
<ajmitch> sunday is winning
<LaserJock> hmm, I'm not sure what to say. Maybe I shouldn't vote
<ajmitch> voting is your duty!
<ajmitch> if you don't vote, the terrorists win
<LaserJock> well, but I'm not sure I can make any of the times
<LaserJock> hmm, I guess Monday could work though
<ajmitch> the 1 day it won't work for me :)
<LaserJock> what the heck is that time format?
<Hobbsee> dunno
* Hobbsee fudged it
<ajmitch> just stick in @SIG@
<ajmitch> it's hardly necessary
<ajmitch> & I think it's slightly silly
<LaserJock> mhm
<LaserJock> but /me doesn't want to be the one rocking the boat
<LaserJock> oh wow
<LaserJock> I put in UTC, and it spits it out in local time
<LaserJock> but I think if you vote you have to add an agenda item
<ajmitch> I did
<LaserJock> well, I added two just to be safe
<LaserJock> probably not interesting though
<ajmitch> they don't have to be interesting
<ajmitch> the meeting's not there for general entertainment
<LaserJock> what?!?!
<LaserJock> and here I was going to bring my tap shoes
<persia> Tonio_: Hey.  I was looking at a merge of yakuake earlier, and heard you didn't think it should be merged.  Could you share your thoughts on that?
<LaserJock> persia: it's a bit confusing when you confirm a sync request for u-u-s, usually that means we've acked it
<persia> LaserJock: Sorry.  That was me trying requestsync.  Given the results, I don't think this is a good tool for non-members of ubuntu-dev.
<LaserJock> ah, can you get it to not set that?
<persia> LaserJock: I can, but the default is to confirm (and sub ubuntu-archive).  I changed the subscriber in my first try, but I don't like the output, as it doesn't include any rationale.  I may edit it to be useful for me, but I may also stick with hand creation.
<LaserJock> persia: yeah, that makes sense
<persia> LaserJock: I'm guessing that if u-u-s members don't know why it should be sync'd, it's more difficult to make an ACK decision.
<Tonio_> persia: there is no difference on the package, no patches etc....
<Tonio_> the only thing to what I know is packaging, but as debian one isn't cdbs based.....
<persia> Tonio_: OK.  I understand.  Thanks for the explanation.
<Tonio_> persia: you're welcome
<Laser_away> ajmitch: do you think it would be possible to add the Debian apt gpg keys to tiber?
<ajmitch> why?
<Laser_away> well, my scripts use apt to grab Debin sources
<Laser_away> and so my cron log and mail on tiber get full of gpg warnings
<Laser_away> it's not a big deal, just slightly annoying
<ajmitch> I'll see what I can do
* ajmitch needs dinner
<dholbach> good morning
<ajmitch> hey daniel
<dholbach> hey andrew
<lucas> Laser_away: if you use mdt, you probably have to add the key to your account
<lucas> not to the root account
<Laser_away> lucas: can I do that? I tried generic directions but they didn't work, how do I tell it what to use?
<lucas> well, doesn't gpg --recv-key keynumber works ?
<Laser_away> that get's the key
<lucas> and then, mdt still complains ?
<Laser_away> hmm, I didn't check actually
<Laser_away> I thought I'd need apt-key add
<lucas> ah maybe
<\sh> moins
<persia> \sh: Good morning.  Did you ever get boson to compile, or should I be working on something?
<imbrandon> moins all
<imbrandon> off to work see yall in a bit
<Mez> anyone wanna review http://revu.tauware.de/details.py?upid=4120
<Mez> I know theres no man pages
<persia> Mez: You might want to add #!/bin/bash at the top of nostromo_container_script.
<Mez> thought i had
<persia> ls
<fernando> moin all
<persia> Mez: It works for me now.  I'm leaving this one installed.  Thanks.
<Mez> persia, woo!
<persia> Mez: http://rafb.net/p/7E8xEx51.html
<Mez> persia - lol
* Mez hugs persia for making life so easy
<persia> Mez: No worries.  I'm excited about this app, and prefer not to maintain local changes :)
<Mez> ;)
<Mez> persia, then you wont mind writing man pages ? :P
<persia> Mez: Umm..  Well...  Perhaps not that excited.
<Mez> darn
<StevenK> help2man, maybe?
<Mez> StevenK, no --help output
<StevenK> Useful.
<Mez> StevenK, it has a html file ;)
<Mez> but that gives nothing away
<Mez> and one of the scripts we wrote ourselves.
<Mez> and a lot of it I had to hack on :(
<Mez> persia, you'll be happy to know - upstream are happy to take on my changes
<persia> Mez: Good.  Everyone will get a nice icon in the control centre, even other distributions.
* StevenK runs svnadmin load on a 2.9Gb SVN dumpfile.
<StevenK> Mez: :-)
<Mez> StevenK, ... ? what did i do now ?
<StevenK> Mez: You stumbling into the mess in -devel. :-)
<Mez> lol
<Mez> persia: even more fun 
<Mez> seems we have most of it done now
<persia> Mez: ?
<Mez> well we're now using dh_installudev
<Mez> ;)
<Amaranth> yay
<Amaranth> instead of doing hacky things you can just call out to scripts that do hacky things in a somewhat standard way ;)
<Mez> Amaranth, I didnt know about dh_installudev
<Amaranth> sorry, was supposed to be funny
<Amaranth> dh_<tab> in a terminal might be useful though :)
<persia> Mez: man debhelper provides a nice list.  I can never remember them all, but it's a good place to check when you want to do something.
<Mez> ssh
<Mez> leave me alone
<Mez> I blame Tonio_ 
<Mez> he gave me roms
<Mez> my heads stuck in super mario world
<Amaranth> "Tea, back with Heather, set too trying to repair the machine, reluctantly used a floating Kubuntu CD to do the rsyncing magic & rescued mail, home-dir & dollops of data; halleluja. Call with Kay Ramme: very switched on guy."
<Amaranth> michael meeks :)
<Tonio_> Mez: giving roms is my internet mission ^^
<Mez> Tonio_, ssh
<Mez> if I could get them to work in linux would even be better
<Mez> jdong, can you check out bug 80579
<Ubugtu> Malone bug 80579 in edgy-backports "backport kxmame" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80579
<Amaranth> crimsun: holy crap the light on my mute button works!!! dude, you're so awesome
<crimsun> excellent.
<giskard> ciao *
<Kano> hi siretart
<Kano> siretart: i am missing h264 support in kaffeine, vlc can playback it
<Kano> best would be multithreaded...
<ScottK> Is there a MOTU available who would be willing to review a new Perl library - http://revu.tauware.de/details.py?upid=4113 - I've been waiting for a dependency and it hit the archives last night...
<white> ScottK: may i friendly suggest to consider bringing them into debian (in case you want to maintain them, but it seems you are very active with perl modules) ?
<white> ScottK: i know that the debian-perl packaging team warmly welcomes every newcomer :)
<white> (this would of course help ubuntu as well)
<ScottK> white: Someone else is working on getting them into Debian who is already in the Perl group. 
<ScottK> I'm actually more of a Python person.  
<ScottK> The two of us are working together.  He's the Perl/Debian guy and I'm the Python/Ubuntu guy.
<ScottK> white: You wouldn't happend to know if there is an equivalent Python group in Debian would you?
<Hobbsee> how does one force a package on which version of python to use at runtime?
<shawarma> Hobbsee: Set #!/usr/bin/python2.4
<Hobbsee> shawarma: where?
<shawarma> Hobbsee: Top of the file.
* ScottK types to slowly...
<Hobbsee> shawarma: for every file within it?
<Hobbsee> (seeing as there are multiple .py files)
<shawarma> Hobbsee: No, just the one you execute.
<shawarma> Hobbsee: Ie. not all the dependant modules and such.
<white> ScottK: http://people.debian.org/~terpstra/list/debian-python.en.html
<Hobbsee> shawarma: hrm.  thought that was __init__.py
<shawarma> Hobbsee: No, you're probably looking for a file in /usr/bin/
<Hobbsee> shawarma: oh right, point
<white> ScottK: http://alioth.debian.org/projects/python-modules/ http://alioth.debian.org/projects/pkg-python/ http://alioth.debian.org/projects/pkg-python-debian/
<white> ScottK: these ones might be of some interest as well :)
<ScottK> Thanks.  Looking.
<Hobbsee> shawarma: doesnt seem to work.  oh well
* Hobbsee --> bed
<shawarma> If anyone's in a revuing mood, please take a peek at http://revu.tauware.de/details.py?upid=4125 and http://revu.tauware.de/details.py?upid=4126
<bddebian> Heya gang
<crimsun> hello deity.
<bddebian> Hi crimsun
<ScottK> If anyone is up for REVUing, I made a list... http://spf.pastecode.com/12053
<bddebian> ScottK: A list?? :)
<ScottK> bddebian: I've got three packages waiting for REVU (you've already advocated one, thanks).  Rather than explain the status of the packages every time I beg for REVU here, I just made a short list.
<bddebian> ScottK: Well my advocations are useless ;-P
<Mez> bddebian, http://revu.tauware.de/details.py?upid=4122
<ScottK> bddebian: I don't think so.  I do know that your not advocating comments have been helpful for me - I ended up having to make a new Feisty chroot to reproduce the build failure you got on pyspf.
<bddebian> :-)
<ScottK> bddebian: BTW, the charset issue you found in one of my man pages turned out to be a nul char buried in the original text I copied the information from.  I had to retype a few lines of the document to fix it....
<bddebian> Ugh
<ScottK> So, as I say, your reviews have been very helpful.
<ScottK> Dunno exactly what you're in the doghouse for, but I have certainly appreciated your work.
<bddebian> ScottK: I'm not in the doghouse, I just seem to miss a lot of nuance stuff on my reviews that others pick up :-(
<Mez> well bddebian I'd be happy for you to look over my thing for me
<Mez> ScottK, you a MOTU ?
<ScottK> Mez: No, not even close.
<Mez> ScottK, you have a lot of knowledge for a n00b
<Mez> to be honest, I've found you very helpful quite often
<ScottK> bddebian: Then I guess I haven't managed to hit that level of nuance in my mistakes yet.
<Mez> when you're up for motu, poke me, I'll happily cheerlead
<ScottK> Mez: Thanks.
<Mez> ScottK, no probelm
<Mez> ScottK, member yet ?>
<ScottK> Actually, I'm not sure.  IIRC what that means, I think not.
* ScottK is https://launchpad.net/~ubuntu-kitterman
<Mez> ScottK, with libspf whats the huge diff with changes to libspf2-1.2.5.orig/src/libspf2/spf_dns_windns.c for ?
<ScottK> I have no idea.  The only changes that I made for my bug fixes were in packaging.
<Mez> ScottK, thats something that should be looked at
<ScottK> I think I need to go back and rebuild the package for Feisty in my chroot without changing anything and see diff that with what I got.
<ScottK> Mez: Thanks.  I have some work work I need to do now, but I'll try and attend to it later today.
<Mez> ;)
<Mez> just a quick poke was like
<Mez> "wtf ??"
<ScottK> Mez: I decided to ignore work work and look at libspf2.  I downloaded fresh libspf2 source into a new folder in my Feisty chroot, added an entry to changelog, and made no other changes.  Then I built the package with debuild -us -uc and got that same huge diff.
<ScottK> Mez: I decided to ignore work work and look at libspf2.  I downloaded fresh libspf2 source into a new folder in my Feisty chroot, added an entry to changelog, and made no other changes.  Then I built the package with debuild -us -uc and got that same huge diff.
<ScottK> It looks like it's been a long time since the package was built for Feisty: https://launchpad.net/+builds/+build/276787 - I wonder if some has changed in the build environment?
<bddebian> ScottK: Are pyspf, libspf2 ready to be looked at or are you working on something?
<ScottK> pyspf is ready.
<ScottK> libspf2 has some weirdness.
<ScottK> mail-spf-perl is also ready.
<rexbron> hey
<ScottK> hi
<rexbron> how can I get debuild to ignore .bzr
<rexbron> (it complains that it can not represent changes_)
<geser> it shouldn't be there in the first place
<rexbron> geser: could you explain more?
<geser> you shouldn't have .bzr (or .svn) in the debian dir
<rexbron> ok, removed it from the debian dir
<rexbron> geser: there is .bzr in the main source dir
<rexbron> and it still does not like that
<geser> dpkg-source knows the option -i / -I to ignore files for the diff
<geser> debuild uses dpkg-source so you need to figure out how to pass it
<geser> you could also use dpkg-buildpackage instead of debuild
<geser> how comes that you changed .bzr?
<ScottK> bddebian: Thanks.  Since it's an existing package, is that (1 advocate) good enough to get it uploaded?
<bddebian> ScottK: Is libnet-dns-foo-bar-baz in the archives now so mail-spf-perl will build?
<ScottK> Yes.
<ScottK> It built last night.
<bddebian> OK
<bddebian> Did I advocate something? :)
<rexbron> geser: example line
<ScottK> bddebian: Darn.  I missed that point.  
<rexbron> it complains ther there is no final newline
<ScottK> rexbron: Then add the final newline.
<shawarma> bddebian: Hi. You've already reviewed this once: http://revu.tauware.de/details.py?upid=4126   <-- Would you mind taking a look at it again?
<\sh> trying to fix xulrunner :)
<bddebian> shawarma: Sure, give me a bix
<\sh> bbl
<bddebian> err bit
<ScottK> Mez: I figured out the libspf2-1.2.5.orig/src/libspf2/spf_dns_windns diff with libspf2 - The original file has windows line endings.  They get converted to unix line endings and so the entire file shows up in the diff even though there are NO code changes.
<bddebian> Egads
<rexbron> ScottK: not sure if you are interested but debuild -i'dir' works
<ScottK> rexbron: Thanks.  Will look into it.
<shawarma> bddebian: Cool. There's also http://revu.tauware.de/details.py?upid=4125 
<ScottK> rexbron: That looks like what I need.  Thanks again.
<shawarma> bddebian: They are *very* similar.
<ScottK> bddebian: Thanks.  On the 
<ScottK> urgh... more typing...
<ScottK> "W: libmail-spf-perl; Package does not have a great enough dependancy on perl." warning, I think that's because the package is written to depend on Perl 5.6 and 5.6 is ancient.
<bddebian> Does it build with newer perl?
<ScottK> Yes.
<ScottK> It's 5.6 and newer.
<bddebian> Ahh, OK
<rexbron> this is weird
<rexbron> the compiled binaries are not being placed in debian/tmp
<rexbron> and they were before
<ScottK> I imagine I could lie and say 5.8+ and get rid of the warning, but that doesn't seem right.
<bddebian> It should be fine the way it is, I just hadn't seen that before
<ScottK> bddebian: Thanks.
<bddebian> ScottK: I took it back off :-(
<ScottK> Ah, but for a good reason.
<ScottK> I'll fix...
* proppy hugs dholbach
* dholbach hugs proppy back
<ScottK> bddebian: Fixed, thanks - http://revu.tauware.de/details.py?upid=4127 - It was a relatively pleasant escape from trying to figure out how to convince debdiff to exclude the line ending changes...
<ScottK> bddebian: Thanks.  Any other MOTUs for http://revu.tauware.de/details.py?upid=4127
<bronson_> Is there any way to get rid of "warning: no utmp entry available and LOGNAME not defined; using uid of process" in my pbuilds?
<bronson_> It generates so much noise it's hard to see what else is going on in there...
<bddebian> bronson_: Not that I've ever seen
<bronson_> Boo.  grep -V it is then.  :)
<bronson_> er, -v.
<geser> shouldn't motu be set as maintainer ony for modified packages from debian?
<LaserJock> geser: I think we don't need to worry about that right now
<bddebian> Heya geser, LaserJock
<LaserJock> I looks to me like they are going to automate that
<LaserJock> at least for Main
<geser> LaserJock: it's because ScottK set it for his package on revu
<LaserJock> well, I think it's ok if he does it, but he certainly doesn't have to
<LaserJock> hmm, perhaps we should put that on our agenda
<LaserJock> the reason we are changing Maintainer is because Debian asked us to
<LaserJock> but we should decide whether we want it in packages that are non-Debian
* ScottK expects his stuff to be in Debian eventually...
<LaserJock> then put it in Debian to start with :-)
<ScottK> I suspect that you may want to differentiate between non-Debian packages that aren't in Debian yet and ones that never will be.
<ScottK> Sure and get it into Feisty how?
<LaserJock> sync it
<LaserJock> granted, right now is not the best time with the etch freeze
<bddebian> How do we have gnumeric 1.7.6 when gnome.org says:  gnumeric-1.2.13 is the latest stable release ?
<LaserJock> bddebian: it's unstable
<ScottK> My current lack of a DD to work with to do that presents a problem (in addition to the whole Etch freeze problem).
<LaserJock> bddebian: hence all my fuss over us having and unstable version of goffice
<bddebian> LaserJock: gnome.org says latest development branch is: gnumeric-1.3.92
<ScottK> I'm guessing I'm 6 months to a year away from Debian...
<LaserJock> ScottK: ?
<LaserJock> it took me 2 days
<ScottK> LaserJock: Are you a DD or did you have a working relationship with one before?
<LaserJock> no
<LaserJock> neither
* bddebian is confused
* ScottK too.
<LaserJock> uh oh
<ScottK> but that's normal for me.
<bddebian> ScottK: Well I meant about gnumeric :)
<zul> LaserJock has a horshoe up his tuckus
<LaserJock> zul: I don't think so
<ScottK> LaserJock: Thanks for the info.  Once the Etch freeze gets done, I'll work on it.
<LaserJock> seriously though. My package was pretty simple
<LaserJock> I had already had the "ajmitch" test
<LaserJock> and it was approved for Universe
<LaserJock> so I emailed debian-mentors with a RFS and a couple days later I got a reply with "looks fine, uploading"
<LaserJock> so I think REVU is really good for getting feedback and getting your package going
<ScottK> Cool.  Once I get things settled for Feisty here, I'll do that.
<LaserJock> but it's not really that hard to get things into Debian so don't be afraid
<LaserJock> ScottK: yeah, right now it could get uploaded and sit in NEW for a long time
<bddebian> LaserJock: Do you know where the gnumeric source is coming from?
<LaserJock> bddebian: ummm, the gnumeric site has this in the NEWS section: "December 2006: Gnumeric 1.7.6 is out. "
<LaserJock> bddebian: I'm not sure what site you are looking at
<LaserJock> bddebian: http://www.gnome.org/projects/gnumeric/downloads.shtml
<LaserJock> but I really think people shouldn't be so afraid of getting their packages into Debian
<bddebian> http://www.gnome.org/projects/gnumeric/download.shtml
<LaserJock> bddebian: hehe, that darn "s"
<ScottK> LaserJock: Before last month I'd never packaged anything before in my life, so this was, I think, definitely the place to start.  I've learned a lot here.
<bddebian> LaserJock: Well that's what google came up with and it's a valid page :)
<LaserJock> ScottK: yeah, I think it's definately better for Ubuntu users to start here and then once there packages are "cleaned up" head over to Debian
<LaserJock> bddebian: well, Gnumeric's site doesn't link there. odd
<ScottK> LaserJock: Speaking of which, I have stuff ready for REVU if you are available/willing? http://spf.pastecode.com/12063
<LaserJock> hehe
<LaserJock> I probably don't have time today
<LaserJock> unfortunately life and work need to come before Ubuntu
<bddebian> Since when? :)
<LaserJock> as much as I like working with everybody here I'm trying to lower the amount of time I spend working in Ubuntu stuff
<LaserJock> bddebian: hmm, since the boss and wife both give me a look like "What have you been doing all day then?" ;-)
<bddebian> heh
<fernando> hi all
<bddebian> Hello fernando
<fernando> hey bddebian 
<shawarma> bddebian: You mentioned I should add the project homepage url to the control file. The closest thing to a project homepage there is is GNOME's viewsvn.. Should I add that?
<bddebian> shawarma: It came from gnome?
<shawarma> bddebian: Sure.
<shawarma> bddebian: Both of them did.
<bddebian> shawarma: From gnome.org?
<shawarma> bddebian: Er... svn.gnome.org, yes.
<shawarma> bddebian: It says so loud and clear in the copyright file.
<shawarma> bddebian: Is that a problem?
<ajmitch> morning
<bddebian> Heya ajmitch
<bddebian> shawarma: No, I'm just looking for a projects page on gnome.org
<bddebian> shawarma: Maybe just use the NetworkManager project link?  http://www.gnome.org/projects/NetworkManager/ ?
<bddebian> Or just leave it, what the hell do I know? :)
<Nafallo> bddebian: not much ;-)
* Nafallo smiles
<bddebian> Amen Nafallo :)
<shawarma> bddebian: I'll leave it out. :-)
<shawarma> bddebian: Sorry that I didn't check for lintian errors first. I actually thought linda was more thorough, but she didn't say anything.
<Nafallo> shawarma: _totally_ StevenKs fault :-)
<ajmitch> always is
<Nafallo> :-)
<bddebian> heh
<ademan_> anyone packaging code::blocks?
<Adri2000> ademan: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304570 http://revu.tauware.de/details.py?upid=2101
<Ubugtu> Debian bug 304570 in wnpp "ITP: codeblocks -- Code::Blocks is a free C/C++ IDE built" [Wishlist,Open]  
<ademan_> Adri2000: so i should file a sync request?
<LaserJock> ademan_: check if it's actually *in* Debian first
<Adri2000> it is not
<ademan_> oh, i thought that link suggested it was
<Adri2000> ITP = Intend To Package
<ademan_> well then i think, i have my first package then
<LaserJock> ademan_: don't package it if Debian is working on it
<ademan_> you think they are?
<LaserJock> that's what an ITP is
<LaserJock> although sometimes they go stale
<Nafallo> LaserJock: baah. Ubuntu was more fun :-P
<bddebian> Gah, I have to build all the damn tilp libraries before I could do tilp2 :-(
<LaserJock> Nafallo: it's a pain in the butt if we duplicate packages
<Nafallo> LaserJock: I was more one of those who filed ITPs that got stale ;-)
<Nafallo> LaserJock: Ubuntu had those in the kernel anyway ;-)
<LaserJock> :-)
<ademan_> LaserJock: it seems to have gone stale
<ademan_> last post in the first link
<ademan_> huh, but its in revu...
<LaserJock> ademan_: then perhaps you sould ask the Debian person if they are still working on it
<ademan_> already sent an email :-)
<jdong> bddebian: did you see the new x264 patch I posted last night?
<jdong> and Nafallo, I'm beginning to understand why you guys don't like touching this media stuff :D
* LaserJock runs away
<jdong> lol
<jdong> don't we ALL love PPC and altivec?
<Nafallo> jdong: ;-). I have been at my parents, with sucky connection and gajim to translate. sorry. will look at it as soon as I have time to spare :-).
<jdong> Nafallo: bddebian is being my buddy with the stuff :)
<jdong> Nafallo: the new PPC altivec optimizations seem to only compile on OSX GCC, so after a bit of frustration last night I reverted those revisions :D
<Nafallo> jdong: ah, but he have told you he don't know anything and is a loser, right? ;-)
<jdong> Nafallo: all I need is someone with that shiny upload button :D
<Nafallo> hehe
<jdong> x264 ain't too bad of a beast to deal with
<jdong> ffmpeg.... *shudder*
<Nafallo> jdong: anyway. what he says is very seldom true :-)
* Nafallo should update mplayer :-/
<Nafallo> what do we have Universe Freeze?
<jdong> Nafallo: yeah, it doesn't built in Feisty anymore
<jdong> Nafallo: libcaca api changed :)
<Nafallo> wee!
* Nafallo goes to find a rope :-P
<jdong> but the good news is it did compile my x264 patch portion correctly before bombing out on caca
<jdong> so I'm in the clear :D
<bddebian> jdong: After the one I uploaded?
<jdong> bddebian: yeah
<bddebian> No havent seen that yet
<jdong> bddebian: that one failed too; it got farther but then the altivec was incompatible with linux GCC :)
<bddebian> Nice
<jdong> bddebian: so I just reverted the two upstream revs that added all this altivec junk :)
<jdong> bddebian: the ppc optimizations didn't build in marillat on ppc either :)
<bddebian> surprise surprise :)
<jdong> but apparently fresh blood (me) has more patience :D
<ademan_> wait when's the universe freeze?
<ScottK> UVF is Feb 8
<LaserJock> ademan_: it's at least the same as the ones for Main
<ademan_> ok, so i could squeeze code::blocks in if it hasn't been already?
<Nafallo> thanks ScottK 
<ScottK> No problem.  There are some questions so easy that even I can answer them.
<Nafallo> ScottK: :-)
<ScottK> Today was, however, a cool day for me.  When I did apt-get upgrade on my Feisty chroot I got two packages and I did them both...
<LaserJock> coolness
<LaserJock> ademan_: for code::blocks the more important date is Feature Freeze
<ademan_> LaserJock: when might tht be?
<LaserJock> ademan_: https://wiki.ubuntu.com/FeistyReleaseSchedule
<ademan_> thanks
<ademan_> now i gotta go, class is over
<ademan_> but i'll figure out code::blocks when i get home
<ademan_> hopefully i'll finally get a chance to package something
<ademan_> i've got till the 8th, sweet
<ademan_> anyways, i'm off
<LaserJock> oh weird, I didn't know UVF and FF were on the same day
<Nafallo> LaserJock: that's not a coincidence IIRC :-)
* ScottK thought LaserJock knew and was just being obtuse.
<LaserJock> nah, I swear it was early March last I looked
<ScottK> It would've been funnier if just stuck with knowing.
<shawarma> I have a package which is a subversion checkout. configure.in in the file has already been changed to show the next release number (current is 0.6.4, next i 0.7.0). I'd like to name it 0.7.0
<shawarma> whoops
<shawarma> I have a package which is a subversion checkout. configure.in in the file has already been changed to show the next release number (current is 0.6.4, next i 0.7.0). I'd like to name it 0.7.0~svn1234-0ubuntu1, but lintian says I can't do that. I've looked in the archive and e.g. lighttpd seems to use the same scheme.. How do you guys feel about it?
<shawarma> and before you ask (or try yourself) lintian also makes a fuss about it when run on the lighttpd package.
<bddebian> lintian will complain about the ~, I think.  I have seen some packages use +svnXXXX but I'm not sure if that is correct either?
<shawarma> It's not the same.
<bddebian> ?
<bddebian> Not the same as what?
<shawarma> dpkg --compare-versions 1234~svn123 le 1234+svn123 && echo true
<shawarma> No, stupid example.
<shawarma> Try this:
<shawarma> dpkg --compare-versions 1234~svn123-1 le 1234-1 && echo true
<shawarma> and then this:
<shawarma> dpkg --compare-versions 1234+svn123-1 le 1234-1 && echo true
<shawarma> The first yields true, the other is silent.
<bddebian>  So -1+svn-0ubuntu1 ;-P
<shawarma> So if the base version is older than the checkout, you use +.
<shawarma> but this is the other way around. The base versio (0.7.0) is not released yet, but upstream has chosen to codename it as such.
<bddebian> Have you checked Debian Policy?
<shawarma> bddebian: It doesn't mention either.
<shawarma> bddebian: it's section 5.6.12.
<bddebian> gawd I hate libraries
<shawarma> sorry, it *does* mention +.
<shawarma> But that doesn't really help me. Should I just stick with the old base version?
<geser> I guess the policy doesn't mention ~ because it can only be used after the release of etch (iirc)
<shawarma> geser: Interesting.
<geser> a new feature like ~ can only be used if dpkg from debian stable nows about it
<shawarma> Well, it does know about. It can compare it other things.
<shawarma> No change is needed in dpkg. It's only policy.
<geser> but if the dpkg from debian stable doesn't understand ~ you get problems when upgrading packages with the old dpkg
<geser> therefore dpkg in stable must support the feature before you can use in in unstable
<geser> due to the long stable cycles in debian this takes a little bit longer
<geser> ubuntu with its shorter devel cycles can start to use it sooner
<shawarma> It *does* understand it. It treats it just like an alphanumeric character which accomplishes just what I want.
<shawarma> So nothing will have to be changed in dpkg for it to be legal.
<shawarma> It's only a policy change away.
<shawarma> I'm not comfortable using it before it's allowed by policy, though.
<geser> yes, the current dpkg understand it but not the dpkg in debian stable
<shawarma> What does it do?
<geser> I looked up the versions and dpkg in debian stable understands it already
<geser> so forget what I said
<shawarma> done.
<shawarma> :-)
<shawarma> I suppose it's still a violation of the policy. 
<somerville32> gpocentek, Have you packaged thunar-volman yet?
<_Enchained> Hi all
<_Enchained> I've a little problem on a package
<pochu> _Enchained: which one?
<_Enchained> it install 2 "binaries"
<_Enchained> and one is a sort of link to the other
<bddebian> Anyone ever heard of tfdocgen?
<_Enchained> a dpkg -c on the deb file returns :  -rwxr-xr-x root/root     55904 2007-01-19 23:20 ./usr/bin/OOodi AND  hrwxr-xr-x root/root         0 2007-01-19 23:20 ./usr/bin/ooodi link to ./usr/bin/OOodi
<_Enchained> so pochu what do you think about it ?
<_Enchained> (lintian ask me for a manpage for each binary)
<geser> shawarma: not directly, see Debian bug #382612
<_Enchained> but one is a link to the other...
<pochu> _Enchained: don't know
<geser> shawarma: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382612
<pochu> i'm newer within packages
<_Enchained> bddebian: what do you think about this ?
<LaserJock> _Enchained: hmm, you could create one manpage and then maybe link the manpages in the same way
<LaserJock> it's nice to be able to do manpage <binary name>
<geser> shawarma: see also http://lists.debian.org/debian-devel-announce/2006/08/msg00006.html
<_Enchained> ok and what means the "h" on the "chmod"
<_Enchained> I know - d and l
<_Enchained> but never seen h
<_Enchained> (for the "file" type)
<geser> _Enchained: have you checked the fs?
<_Enchained> fs of what ?
<_Enchained> the installed files ?
<geser> yes
<_Enchained> I don't know.. it seems to be fine
<geser> I've never seen h as the first letter (at least I don't remember)
<geser> but I've seen on corrupted fs to display garbage as the first letter
<_Enchained> :/
<jdong> bddebian: at your next convenient time, if you could apply & upload that x264 debdiff I was talking about earlier, that'd be great (https://launchpad.net/ubuntu/+source/x264/+bug/80387/comments/5)
<Ubugtu> Malone bug 80387 in x264 "Import 20070116 snapshot" [Undecided,In progress]  
<bddebian> jdong: I'll do it when I get home
<bddebian> Later gang
<jdong> bddebian: ok, enjoy :)
<_Enchained> maybe I should upload the package as it is actually and let reviewers see how to fix that ?
<_Enchained> I've uplaoded on revu and descripted the problem : http://revu.tauware.de/details.py?upid=4135
#ubuntu-motu 2007-01-20
<pochu> hello
<pochu> do you know if we will see thunderbird 2.0 in Feisty?
<crimsun> not a universe source package.
<pochu> yes I know
<pochu> it is in main
<pochu> isn't it?
<pochu> so where should I ask?
<crimsun> you've already joined the proper channel
<crimsun> (-devel)
<pochu> crimsun: as the topic for -devel is not support i didn't want to ask there
<pochu> :-)
<pochu> crimsun: thanks
<Hobbsee> morning all
<Nafallo> indeed
* Nafallo sneaks up behind and hugs Hobbsee 
<bddebian> Heya gang
<crimsun> hi.
<bddebian> Hi crimsun 
<crimsun> I'll be reducing my Ubuntu involvement given job commitments in the coming months, but I feel confident with the teams in place that people will keep universe running smoothly.
<bddebian> Noooo
<Nafallo> first LaserJock and now crimsun :-P
<Nafallo> wow
* bddebian runs away fast
<crimsun> I won't step down completely until there's a capable team triaging audio bugs.
<bddebian> Well that will be like never :-)
<ajmitch> well there's bddebian to help out
<ajmitch> so he can do everything you've been doing
<bddebian> Not me, I suck remember :-)
<crimsun> sweet
<ajmitch> then stop sucking, *quickly*
* bddebian starts blowing
<ajmitch> yeah, not appropriate
<bddebian> Man, I haven't run xchat in GNU/Linux in ages
<Nafallo> bddebian: oh! anyone willing to suck my dick is a good one :-)
<ajmitch> uh..
* jdong|laptop realizes 3 hours into the project that he is two cables short of a wireless network
<jdong|laptop> the irony....
<jdong|laptop> and Nafallo.... whoa....
<Nafallo> hihi
<jdong|laptop> Nafallo: we use innuendos in release codenames and artwork to express those feelins
* jdong|laptop is so losing karma for that :)
<Nafallo> jdong|laptop: ROTFLMGAO ;-)
* jdong|laptop dist-upgradering to feisty on test box
* bddebian is running feisty on this laptop
* ajmitch is stepping away from this disturbing channel
<bddebian> Any of you ever heard of tfdocgen?
* jdong|laptop is not as reckless as bddebian with his primary machine :)
* jdong|laptop has messy network of chroots for his uglier setups
<bddebian> Oh this ain't my primary machine :)
<jdong|laptop> bddebian: that's an ancient city ruins uncovered in Greece. it was on Dateline last week
<bddebian> heh
<jdong|laptop> :)
<bddebian> Well this damn libticonv package does make docs and it tries to run tfdocgen :-(
<jdong|laptop> http://svn.tilp.info/
<jdong|laptop> that's where the aforementioned script is.
<bddebian> lame
<jdong|laptop> the wonderful smell of additional build-deps in the morning :)
<ScottK2> Perhaps ajmitch would be up for a little REVU while he's away from the channel - http://revu.tauware.de/details.py?upid=4127
<bddebian> hehe
* ScottK2 had to ask
* Nafallo will be doing evil things now...
<ScottK2> Do these evil things include REVUing packages?
<jdong|laptop> Nafallo: I've done my share of evil for the day :)
<LaserJock> have we firmed up our meeting time?
<Nafallo> jdong|laptop: installed firstclass? ;-)
<jdong|laptop> heh :)
<jdong|laptop> Nafallo: no, but I am toying with ffmpeg-cvs :)
<Nafallo> I win!
<Nafallo> :-P
<jdong|laptop> Nafallo: contest me and the patches will fly YOUR way :P
<jdong|laptop> lol
<Nafallo> haha
<LaserJock> ajmitch: contentless ping?
<jdong|laptop> USB atheros is still taboo, right?
<ajmitch> LaserJock: similarly contentless & worthless pong
<LaserJock> ajmitch: excellent thank you
<bddebian> heh
<zul> mmmm...UHF
<bddebian> stupid package
<shawarma> If there's a package that's about to enter the archive for the first time, but there's a community-provided package known to be in wide use with a wrongful higher version number, would you guys think it was alright if an epoch was set on this first official version in order to let the users of the community provided version upgrade smoothly?
<shawarma> Theoretically, of course.. :-)
<crimsun> no, I think that's bogus.
<crimsun> we're not responsible for screwed external versioning
<crimsun> and I keep telling the folks who build beryl packages to stop using that crackful versioning, but of course it's in one ear and out the other
<jdong> bddebian: upload time? I'm dying of Altivec anxiety :D
<jdong> (not really, but I'm about 5 minutes from opening up doom3 and wasting a good working night)
<bddebian> jdong: Sure since I seem to suck at getting this libticonv built :-(
<shawarma> crimsun: I see your point. However, setting the epoch wouldn't break anything, but it *would* fix the upgrades for quite a few users.
<shawarma> crimsun: It think that's also a valid point.
<crimsun> if maintaining compatibility with external repositories is a concern, then do what it takes to keep it
<jdong> is there any trivial python or gdialog/zenity-like way of triggering libnotify popup balloons?
<crimsun> before you trigger those popups, talk to mpt and see if what you want to do is sane UI-wise.
<shawarma> crimsun: I happen to know that the external repository will seize to exist the very second this package enters the archive, so it's a one-off thing.
<jdong> crimsun: it's more for personal use and not gonna see the public light of day
<shawarma> crimsun: I happen to know this as I'm the sucker who made the packages. :-)
<ajmitch> poor sucker
* ajmitch wonders if either beryl or compiz will get shipped on the cd - beryl is looking awfully unlikely, what a shame ;)
<crimsun> it almost explodes gracefully when I switch Modes :-)
<bddebian> jdong: It's uploading
<ajmitch> such hype about it at UDS
<ajmitch> & the concern over binary drivers
<shawarma> I actually have better experience with beryl than compiz.
<jdong> bddebian: yay :)
<bddebian> jdong: Now, build libticonv for me :)
* jdong is perfecting his backup scripts :D
<Nafallo> backuppc ftw
<bddebian> So, who's gonna review MY new package? :)
<crimsun> upid?
<bddebian> Dunno yet but it's libticonv2
<crimsun> do you want a review pass or compilation assistance?
<bddebian> review pass
<bddebian> It compiles
<bddebian> What's weird though is the orig source dir is libticonv-1.0.1 but it complained about SONAME until I made it libiconv2-foo
<crimsun> ok. COPYING needs to be updated for the FSF address
<bddebian> OK
<crimsun> heh
<crimsun> README has:
<crimsun> Copying is allowed under the terms of GNU General Public
<crimsun> License (LGPL). See the file COPYING for more details.
<crimsun> that's not what COPYING is
<bddebian> Damn, libparagui did the same shit to me :-(
<crimsun> so either that 'L' is a typo, or someone forgot to use the correct license
<crimsun> s/someone/upstream/
<crimsun> docs/ , tests/ look good
<crimsun> the FSF addresses in the headers are still the old ones
<crimsun> src/ looks good (same caveat RE: old FSF addresses in source files)
<crimsun> [note that src/charset.h actually has the correct updated FSF address] 
<crimsun> debian/changelog: "Intitial" -> "Initial"
<crimsun> debian/copyright says LGPL.
<crimsun> so something needs to be clarified w/ upstream
<crimsun> if it in fact is to be distributed under LGPL, you'd need to include a full copy of the LGPL
<ScottK> crimsun: If you are up for another package... http://revu.tauware.de/details.py?upid=4127
<crimsun> I'm not finished.
<ScottK> Ah.  Sorry.
* ScottK goes back in his hole..
<crimsun> (np, just wanted to let you know I'm not ignoring you)
<ScottK> Thanks.  I appreciate not being ignored.  If you get ambitious, I have a list...  http://spf.pastecode.com/12063 - the one above is the first on the list.
<somerville32> ScottK: Are you going for developer?
<bddebian> crimsun: Well some of the files in debian/ still need work.  The description isn't even the one for that package ;-P
<crimsun> bddebian: I presumed they were WIP
<ScottK> somerville32: No.  I just have some stuff I'm trying to get done.  I need software packaged to do it.
<ScottK> I have to go AFK and deal with children and bed times...
<crimsun> bddebian: what do you plan to do about the binary package names?
<Mez> 402 upgraded, 0 newly installed, 0 to remove and 114 not upgraded.
<Mez> 406 not fully installed or removed.
<Mez> Need to get 341MB of archives.
<Mez> hmm
<somerville32> gpocentek, Did you package thunar-volman already?
<Mez> i may have to have fun and remove everything
<gpocentek> somerville32: yes, but I need to fi some copyright issues
<gpocentek> fix*
<somerville32> gpocentek, ok.
<bddebian> crimsun: Probably gonna have to get upstream to straighten it out I suppose
<somerville32> gpocentek, Do you know C/C++?
<gpocentek> somerville32: C, but I'm really far from being an expert
<somerville32> sfflaw rejected my SRU for dubious modifications
<somerville32> And I need a second opinion since I don't know C/C++
<gpocentek> the mousepad one?
<somerville32> Yes.
<somerville32> I already removed the comment style change
<somerville32> so I dunno what he means there
<somerville32> but the function rename might be a valid point
<somerville32> but the svn commit log doesn't mention anything else
<gpocentek> I'll have a look this weekend
<gpocentek> but apparently there's also an UI change in this patch
* ScottK is back and the 3 year old that would not stop is in bed...
<somerville32> gpocentek, I can modify the patch as he suggests.
<somerville32> I just don't want to waste effort removing changes that are required.
<gpocentek> somerville32: switching from a xfce file chooser to a gtk file chooser is a big change, I don't think that we need this to fix the bug
<bddebian> crimsun: Thanks btw
<crimsun> np
<gpocentek> somerville32: the xfce filechooser works everywhere, so that's not the problem
<gpocentek> bbl
<somerville32> gpocentek, ok. I can fix that up then.
<somerville32> 0.2.2-2ubuntu5.1~proposed -> 0.2.2-2ubuntu5.1~proposed2 ?
<jdong> bddebian: party hat! new x264 built successfully on all arches :)
<somerville32> Yea!!!
<jdong> which goes to show... the best altivec is no altivec ;-)
<bddebian> jdong: :-)
<jdong> bddebian: now the other patches shouldn't give you any grief. I expect mplayer to FTBFS but for an unrelated reason :)
* jdong thinks red badges of courage shall be awarded to anyone who deals with media codecs?
<Toadstool> agreed :)
<Toadstool> 'evening everybody
<bddebian> Heya Toadstool 
<Toadstool> hey bddebian 
<LaserJock> anybody tried bzr-builddeb yet?
<somerville32> Whats the command to filter files out of a diff?
<LaserJock> filterdiff
<somerville32> How intuitive :)
<somerville32> Who do I get it to remove two files?
<jdong> pipe one to another!
<somerville32> lol
<somerville32> How do I get it to remove on file? :P
<somerville32> *one
<jdong> somerville32: give it a regex that only matches one file?
<jdong> -x '^filename$' should do it?
* jdong is no regex guy by any measure
<jdong> *sigh* I'm bored.... is Feisty released yet?
<LaserJock> yes
<jdong> yay!
<LaserJock> I just *Herd* about it *2* days ago
<LaserJock> lame
<Toadstool> :)
<jdong> Hurd 2 is out already? What? hell froze over twice already?
<jdong> and LaserJock, I thought only I made lame herd/knot jokes?
<ScottK> Good night all.  I've had enough fun for one day.  
<LaserJock> jdong: you certainly aren't the only one
<LaserJock> hmm, anybody know vincent untz?
<somerville32> Name sounds familiar
<somerville32> A gnome developer?
<LaserJock> yeah
<LaserJock> I wondered if anybody knew where I can find him
<somerville32> His... website?
<somerville32> lol
<somerville32> vuntz.com
<somerville32> *.net
<LaserJock> seems french, I might try gimpnet during regular French hours
<LaserJock> I want a gnome bug fixed
<LaserJock> and I feel like poking somebody about it :-)
<somerville32> He might be a good person to poke
<somerville32> I see his name in the changelogs all the time
<LaserJock> yeah, it's a gnome-panel "issue" and he seems to be the guy for that
<Toadstool> LaserJock: maybe vuntz on #u-devel ;)
<LaserJock> oh wait, maybe I found the solution
<LaserJock> well, it sort works
<LaserJock> oh geeze
<Amaranth> kbuildsyscoa or whatever is the little hack that makes loading KDE apps fast, right?
<LaserJock> hi Hobbsee 
<crimsun> Amaranth: what are you referring to?
<LaserJock> crack, utter crack :-)
<Amaranth> crimsun: the little daemon or whatever that makes a KDE app load faster
<Amaranth> maybe it's kde-init or something
<Hobbsee> hey LaserJock 
<Mez> Amaranth, kbuildsycoca rebuilds the KDE system cache
<Amaranth> i'm not trying to use it, just an academic question
<Hobbsee> isnt that just prelink?
<Amaranth> nah, there is some extra magic
<Mez> Amaranth, kdeinit will load up dcop server etc etc
<Amaranth> because when you login to a KDE session apps start fast, when you use GNOME they take forever
<Amaranth> but if you start them again they're just as fast as under KDE
<Mez> Amaranth, kdeinit is what you're looking for
<Amaranth> alright
<Mez> loads kio slaves, kded, scop server etc etc
<Mez> s/scop/dcop/
<Mez> Amaranth, or just run KDE :D
<Mez> :-"
<luckyone> hello all - can anyone tell me if there is a bug associated with xsane for edgy? I don't know who to ask about this
<luckyone> sorry, not sure if this made it - can anyone tell me if there is a bug associated with xsane for edgy? I don't know who to ask about this
<crimsun> https://launchpad.net/ubuntu/+source/xsane/+bugs
<owh> Hi folks, I posted an email to ubuntu-devel and after a week to ubuntu-devel-discuss. The message to ubuntu-devel was moderated after about 10 days and came through in a whole bunch of messages. 
<owh> The message to ubuntu-devel-discuss was distributed, since it made it to the archives: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-January/000167.html but I have not received any replies. I'm not here to whinge about it, but can anyone point out why it was ignored?
<owh> Did I author a completely obtuse message, or was it something else?
<somerville32> I read it
<owh> Did I break any rules I should be aware of?
<somerville32> I don't think so
<somerville32> Try bringing it up in #ubuntu-devel during EU business hours
<owh> That's an excellent suggestion.
<owh> I'm glad that you read it, at least someone did :-)
* owh felt a little unloved ;-)
<owh> somerville32: When you read the message, did you think I should have put more time into it perhaps?
<somerville32> owh, I thought it should have gone to ubuntu-devel instead of -discuss
<owh> That's why I sent it there in the first place.
<somerville32> Try to find a core-dev to sponsor it
<owh> But it didn't get moderated, and after it did, it was buried.
<owh> somerville32: I thought that including sistpoty would have assisted.
* owh has just been called to dinner.
* somerville32 waves.
<owh> somerville32: Thank you for your suggestion on #ubuntu-devel. I will follow that up next week.
<somerville32> Awesome :)
<somerville32> Thanks for your work!
<owh> Pleasure.
<owh> Thanks
<tsmithe> siretart, you here?
<ademan> dumb question, when there's no ./configure in a source tarball but there is configure.in  what do i run?  I tried autoconf but it tripped up on some real basic macros
<StevenK> ademan: ./autogen.sh
<ademan> :-/ doesnt have one
<StevenK> Although, autoconf ought to deal.
<ademan> it errors like heck, config.guess and config.sub missing
<StevenK> config.guess and config.sub can be copied in
<ademan> from any other source tarball?
<StevenK> From /usr/share/misc
<somerville32> Isn't there a script to autogenerate it?
<ademan> ah, thanks
<ademan> somerville32: nope
<ademan> i guess cause it's cross platform
<somerville32> ifneq "$(wildcard /usr/share/misc/config.sub)" ""
<somerville32>         cp -f /usr/share/misc/config.sub config.sub
<somerville32> endif
<somerville32> ifneq "$(wildcard /usr/share/misc/config.guess)" ""
<somerville32>         cp -f /usr/share/misc/config.guess config.guess
<somerville32> endif
<somerville32> You can add that to your clean rule
<somerville32> after  -$(MAKE) distclean
<somerville32> and before dh_clean
<ademan> somerville32: honestly i didn't write the makefile
<somerville32> No
<somerville32> The debian rules file
<somerville32> :)
<ademan> oh, haha, well i'm not to the point of packaging it yet, i gotta make sure that the person who submitted for revu didn't get it through (nearly a year ago)
<ademan> now automake wants ./INSTALL, ugh, this is EXACLTY why i'm writing a new build system... 
<persia> It doesn't belong in clean.  The config{sub,guess} copy should be done in configure, and the files should be deleted in clean.  Otherwise they end up in .diff.gz (and are not required).
<geser> _Enchained: hello
<_Enchained> hi
<geser> that 'h' in the dpkg output stands for a hardlink
<_Enchained> ok
<_Enchained> What should I do with that ?
<_Enchained> for the package
<geser> is it really needed that the binary is installed as OOodi and ooodi?
<geser> the easiest would be to install only ooodi
<_Enchained> yes it's what I think
<_Enchained> but it maybe could causes problems in execution
<_Enchained> ?
<_Enchained> I don't know... maybe if the program call OOodi...
<_Enchained> or something like that
<_Enchained> I think I'll rename OOodi binary in ooodi and delete the old oodi (link)
<_Enchained> Do you know how to fix the linda warning (with config.guess) ?
<geser> see the README for autotools-dev
<_Enchained> ok
<palski> is so that initrd-tools should not be merged?
<geser> palski: are the initrd-tools still in use?
<palski> well, they are not anymore in debian repos but in feisty repos they seems to be
<palski> and by debian repos I mean debian unstable repos =)
<geser> ask the kernel people if they have any objections and file a request for removal
<palski> bug #79168
<Ubugtu> Malone bug 79168 in initrd-tools "initrd-tools: merge new debian version" [Undecided,Rejected]  https://launchpad.net/bugs/79168
<geser> oh, we have a "MOTU Merge Team"?
<_Enchained> geser: http://revu.tauware.de/details.py?upid=4142 updated
<_Enchained> still the problem on cvs files
<_Enchained> I think the rest is ok.
<afflux> when packaging a java class, do I need to create the -dev package?
<afflux> ah, sry for stupid question :/
<afflux> problem: I wanna build a package using pbuilder with sun-java5-jdk in the dependencies. while setting up the build-dependendies it fails cause he "couldn't present the license" (we are in non-interactive mode of course). any way to avoid this? (is this even the right place to ask?)
<geser> afflux: do you really need the sun-java5-jdk package? doesn't it build with gcj or the other java compilers?
<afflux> the original author of the code said it :) i gonna try.
<afflux> can i compile a library with gcj and a program that depends on this library with the javac?
<afflux> geser: is there any way to do it with the sun packages if I find no other solution?
<geser> sorry, I don't know
<persia> afflux: pbuilder login --save-after-exec allows you to make manual changes, but I don't know if it works for the buildds.
<geser> afflux: just a side note: if your package build-depends on sun-java5-jdk it would have to go to multiverse
<afflux> alright, i gonna look.
<afflux> thank you two.
<afflux> yeah, I have feared this.
<davromaniak> any reviewer can take a look at youtranslate please ? : http://revu.tauware.de/details.py?upid=4119
<muzzol> hi, i have a dumb question, where do i specify the package name if is diferent from source package?
<muzzol> im playing with control file
<muzzol> but im not sure
<pochu> muzzol: I think you can do that with "dh_make -p <packagename>
<persia> muzzol: Does your source package provide more than one binary package?  If not, it is best to have the same name.  If so, you will need to alter both control and rules.
<muzzol> well im not sure if i've explained correctly
<muzzol> i want to change the original name
<muzzol> if i have a source package name a.tgz
<muzzol> and want to generate a bin package named b.deb
<muzzol> where must i look?
<persia> muzzol: The easiest way is `tar xzf a.tgz; mv a b-x.y.z`, and build your package in b-x.y.z.
<muzzol> ah! ok, i though i had to edit control file
<muzzol> that's really easy
<muzzol> :)
<persia> muzzol: For single-binary packages, your source and binary package names should match, and the directory be called <pkgname>-<version>.  You will need to put b in your control file to generate b_x.y.z-r_<arch>.deb.
<ScottK> persia: Are you familiar with packaging/building C programs in the Ubuntu environment?  I have a question if you are and have a moment...
<persia> ScottK: I'm more familiar with C than python or perl.  What's the question?
<ScottK> Typing ....
<ScottK> I did a packaging fix and rebuilt libspf2.  Here's the debdiff http://librarian.launchpad.net/5800752/Debdiff_rev1.  The trick is that libspf2-1.2.5/src/libspf2/spf_lib_version got added somehow.
<ScottK> I guess the question is how do I avoid that?  I think it's not necessary and I don't want to complicate review of the patch.
<persia> ScottK: If you really didn't add spf_lib_version.h, then it looks to me like the clean rule doesn't do all it might.  Did you maybe build the package in the tree at least once prior to generating the final source version?
<ScottK> No.
<ScottK> I actually tried making a new directory, downloading the source package, and rebuilding an unmodified package.  Got the same issue.
<persia> ScottK: Hrm.  I'll take a closer look, and see if I can figure out what happened.
<ScottK> I'd appreciate it.
* imbrandon yawns
<ScottK> persia: The other issue that I manually edited out of that particular debdiff is that there are a bunch of windows files in there and rebuilding the package causes all the line endings to get converted to Unix line endings...
<ScottK> This makes for a particularly ugly diff.
<imbrandon> ScottK, make the post inst run unix2dos or dos2unix ( dependsing ont he need ) 
<imbrandon> simple hack to get arround that
<imbrandon> ( of course that will add another build dep )
* ScottK just wanted to fix one little packaging bug, not redesign the package...
<ScottK> But, of course, I don't always get what I want.
<persia> ScottK: First pass runs with no diff (output of debuild -S -us -uc on unmodified source).
<ScottK> OK.  Well then I think I understand at least a little better.
* ScottK built a binary first to make sure it would install.
<ScottK> I think I should not do that.
<ScottK> Thanks for looking at it.  I'll go try it again....
<persia> ScottK: Yep.  It's a bug in the clean rule.  It's a good idea to verify uild first, but afterwards, delete the directory, and rerun dpkg-source -x, as otherwise these bugs can hit you.
<ScottK> Thanks again.  I learn something new here every day.
<ScottK> persia: Should I write a bug for that (I'm not up to fixing myself - just learning)?
<persia> ScottK: It's probably not worth it.  If it is a debian package, it is worth sending a debian bug (wishlist).  If it is in an Ubuntu-only package, just fix it.  To fix it, you only need to add the logic to delete the file either in the debian/rules clean rule, or in the upstream Makefile clean rule.  If it's not obvious, leave it alone: I find bugs like this in about 60% of the packages I touch.
<ScottK> It's orphaned in Debian, so writing a Debian bug is of little use in the short term.  Someone is planning on picking it up once they are a DD (hopefully later this year).  Sounds like it's not worth messing with.
<ScottK> Appreciate the help.
<persia> ScottK: Probably not.  As long as the package builds correctly after downloading, and anyone preparing an NMU or Ubuntu revision is careful to avoid extra material in the changelog, most people should be happy.
<persia> s/changelog/debdiff/
<ScottK> Good morning Mez.
<ScottK> persia: That worked. https://bugs.launchpad.net/ubuntu/+source/libspf2/+bug/79683 - now I've got a fix that's actually correct.
<Ubugtu> Malone bug 79683 in libspf2 "spfquery: conflict with libmail-spf-query-perl Debian bug#306875" [Unknown,Unknown]  
* jdong is pretty slow this morning....
<persia> ScottK: Glad to hear it.  I'll recommend that you change the bug status to "Confirmed", and the assignee to "Nobody", as the U-U-S member who uploads it will want to be assigned for tracking purposes, and may want to set in-progress if they have other changes to make to the package prior to upload.
<jdong> hey jdong, know why udffsck isn't repairing your udf disc?
<jdong> because it says int main(){return 0;}
<ScottK> persia: Done.  Thanks more.
<persia> ScottK: No worries.
<crimsun> ScottK: http://librarian.launchpad.net/5805334/corrected_debdiff does not apply against the latest Debian source
<crimsun> patching file debian/control
<crimsun> Hunk #2 FAILED at 38.
<crimsun> 1 out of 2 hunks FAILED -- saving rejects to file debian/control.rej
<ScottK> Urgh.
<ScottK> It builds here in my Feisty chroot (I just went and built it again).  I'll go look at it some more...
<ScottK> After building the binary I get a lintian error on the source package I didn't get before I built the binary: E: libspf2_1.2.5-4ubuntu1_source.changes: md5sum-mismatch-in-changes-file libspf2_1.2.5-4ubuntu1.dsc
* ScottK will have to look at it later.  Urgh.
<Adri2000> crimsun: I have the last guifications version which work with gaim 2.0.0beta6 packaged, can you upload it? or do you prefer to wait for debian (which has not even gaim 2.0.0beta6 yet) ?
<crimsun> debdiff.
<Adri2000> crimsun: it's a new upstream release, no change except the changelog entry
<Adri2000> crimsun: http://adrishost.homeip.net/~adri2000/ubuntu/toupload/
<crimsun> Adri2000: tested?
<Adri2000> crimsun: yes, works
<Adri2000> thanks crimsun 
<tsmithe> siretart, here?
<tsmithe> hmm
<tsmithe> seems to be /away
<tsmithe> ah well
<jdong> crimsun: can you sponsor all the debdiffs (except the first one; x264 already uploaded) on https://launchpad.net/ubuntu/+source/x264/+bug/80387/comments/1?
<Ubugtu> Malone bug 80387 in x264 "Import 20070116 snapshot" [Undecided,In progress]  
<jdong> crimsun: they are to rebuild affected multiverse packages against new x264
<jdong> crimsun: and the ffmpeg one also closes the wishlist thing about DEB_BUILD_OPTIONS=risky I was nagging you about last month :)
<ademan> in a source tarball what does the ./INSTALL file contain?
<mr_pouit> usually, instructions to install the program
<ademan> so its just human readable stuff?
<ademan> ie non-essential?  automake is complaining about a lack of ./INSTALL file, can i just make an empty one?
<Adri2000> yes
<Adri2000> ademan: there is a generic INSTALL (with ./configure, make, ... instructions) file available somewhere
<ademan> hrm ok, now i'm going to be packaging Code::Blocks in the near future assuming that the original package never made it through revu, but i wanted to try just building it first, there's no autogen.sh or anything, so i need to run autotools by hand, i did it in this order: aclocal, autoconf, automake, and autoconf is giving me trouble
<ademan> actually, autoconf ran without even this time, automake, however, errored like heck
<crimsun> jdong: that's not exactly a "no source change necessary" for avidemux in 80387
<tsmithe> since siretart's recently never here... does anyone here have any experience in using bzr whilst packaging?
<LaserJock> tsmithe: what do you need?
<LaserJock> tsmithe: you guys should lookinto bzr-builddeb that just got into Feisty
<crimsun> reinhard blogged about it as well.
<tsmithe> LaserJock, yeah
<tsmithe> that's why i wanted siretart partly
<LaserJock> I might try it out today
<tsmithe> thing is; it seems so unclean to have to hack about with the diff or move the .bzr directory when using bzr and debuild
<crimsun> some people don't remove .bzr
<crimsun> and there's always filterdiff
<LaserJock> well, that's why bzr-builddeb does an export
<tsmithe> that's what i mean by hacking about with the diff
<tsmithe> filterdiff
<crimsun> that's moot with 'export'
<LaserJock> the thing about using version control is that often times you don't want the meta info in there
<tsmithe> hmm
<tsmithe> i'll look into it
<tsmithe> i don't really know what you mean
<LaserJock> tsmithe: just grab bzr-builddeb and try it out
<tsmithe> kk
<LaserJock> an export is when you take a version control repo and just copy the files to a different dir
<tsmithe> ah ok
<LaserJock> and by "you" I mean the version control app
<tsmithe> i know
<tsmithe> :)
<crimsun> so, toby, do you want to maintain alsa?
<tsmithe> err ok
<tsmithe> i could try
<tsmithe> would be good experience
<crimsun> this is not an off-the-cuff question, btw. It will eat your time alive, and you need to be willing to dedicate approximate 40 hours a week to it.
<crimsun> +ly
<tsmithe> hmm
<tsmithe> lemme work this out
<ScottK-laptop> crimsun: When my libspf2 patch failed earlier today....  What tools/commands do you use to apply the patch?  I'm trying to understand what went wrong and would like to try and replicate what went wrong when you did it before I muck with the patch...
<crimsun> on the upside, you'll learn git, mercurial, mantis, and much more
<tsmithe> yeah
<tsmithe> what kind of things are the most time consuming, then?
<crimsun> ScottK-laptop: I grabbed the latest Debian source package and applied your debdiff
<crimsun> tsmithe: triaging and testing
<tsmithe> ok
<crimsun> tsmithe: if you're interested, join the ubuntu-audio team
<tsmithe> ok
<tsmithe> i think i am
<tsmithe> testing as in what, however?
<crimsun> good question.
<LaserJock> crimsun: gathering volunteers *cough* victims *cough*
<LaserJock> ?
<crimsun> writing fixes, testing them; integrating upstream fixes, testing them
<crimsun> LaserJock: it would be discourteous to leave without some infrastructure in place.
<tsmithe> crimsun, i love this: "If you are filing a bug pertaining to ALSA, please first read the following URL:"
<crimsun> yes, and people _don't_ read it
<tsmithe> as if most bug-filers are going to read that! :)
<tsmithe> yeah!
<tsmithe> :P
<crimsun> if they'll read a wiki page, they _might_ read an LP comment
<crimsun> it just goes to show that most people simply don't read
<tsmithe> yeah
<tsmithe> show me an example of a poor bug report then
<crimsun> look at the one that that comment is attached to
<crimsun> but really, you can look at virtually _any_ bug reported using LP
<ajmitch> hello peoples & others
<crimsun> hello
<tsmithe> hi ajmitch
<LaserJock> hi ajmitch 
<fernando> hey ajmitch 
<crimsun> ScottK-laptop: specifically, dpkg-source -x, then patch -p1 --dry-run
<ScottK> Thanks.
* ScottK is working on a server in another room and running back and forth between rooms...
<enyc> Hrrrm.... does anybody understand why some things in /usr/share/fonts/X11/misc/ but xorg looking in /usr/share/X11/fonts/misc/  ?
<enyc> im confused!
<enyc> noting this system has been upgraded dapper>edgy i think...
<enyc> so might have old xorg conf or other problem
<crimsun> it is part of the transition, yes
<tsmithe> crimsun, how do you maintain support for dapper, edgy? i assume you run feisty
<crimsun> for the most part, because fontconfig is used (see /etc/fonts/fonts.conf ), it didn't matter which dir was used for 6.10
<crimsun> tsmithe: I support 5.10, 6.06, 6.10, and 7.04
<crimsun> tsmithe: I actually run 5.10
* tsmithe doesn't believe you!
<enyc> crimsun: l
<enyc> crimsun: erm i didnt seem to get fontconfig until I installed it, I thought
<ajmitch> crimsun: still looking for poor suckers for alsa?
<tsmithe> ajmitch, yeah ...
<crimsun> ajmitch: I'm getting 'em, too.
<tsmithe> crimsun, them? anyone else?
<tsmithe> he says, hopefully :P
<crimsun> of course
<crimsun> I wouldn't leave you with people who don't do very much audio triaging 
<tsmithe> oh good
<tsmithe> that makes me feel better
* ajmitch thinks it'd be a large job for one person
<enyc> hrrm no... i must have had fontconfig
<enyc> anyway
<enyc> so...
<enyc> where do fonts work? which dir is new and old?
<enyc> and how do i list which fonts the x-server is actually seeing ?
<crimsun> xlsfonts
<crimsun> they're both used; see the aforementioned file
<crimsun> xorg.conf may list /usr/share/X11/fonts[/...] 
<enyc> xlsfonts  cooo! thanks
<enyc> right... but it actually reads fonts.conf instead (or in addition) ?
<crimsun> fontconfig uses /etc/fonts/fonts.conf
<enyc> but what 'uses' fontconfig ?
<tsmithe> crimsun, tell me... how should i get started? what's the first thing you do every day in relation to alsa?
<tsmithe> i just don't think i have 7 hours every day spare, that's all... but i quite see the opportunity
<tsmithe> hmm
* enyc wonders if you can configure 'all' the xterm fonts (unreadable tiny small medium large huge) rather than just 'default' ... hrrm...
<crimsun> tsmithe: my workflow is essentially: triage bug mail, update my local git repos against BenC's, trawl upstream bug tracker (mantis), trawl upstream mercurial (hg) alsa-{kernel,driver,utils,lib}, read upstream alsa-devel, read pkg-alsa-devel (on alioth), create/pull any patches in, build+test, solicit testing, etc.
<crimsun> tsmithe: if you'd like to ease into it, you could begin by generating a git patch to send to kernel-team@lists.uc containing ac97 quirks that were lost between 6.10 and 7.04
<crimsun> (obviously I'll assist)
<tsmithe> hehe "ease"...
<crimsun> enyc: that would be all GTK+-2 and Qt3+ apps
<crimsun> enyc: so for all practical purposes in {Ed,K,X,}ubuntu, just about everything in the shipped CD(s)
<tsmithe> quirks? in what sense?
<crimsun> tsmithe: now the more interesting side is in userspace, like what will happen with pulseaudio and alsa-{libs,utils}
<tsmithe> yeah
<tsmithe> that's what i'm interested in :)
<enyc> crimsun: i seee but not the x-server itself ?
<tsmithe> (of course)
<crimsun> tsmithe: most manufacturers never follow the specification
<tsmithe> ah
<tsmithe> so how do you mean, "lost"?
<crimsun> between 5.10, 6.06, and 6.10, we collected a ton of AC'97 quirks
<tsmithe> mmhmm
<crimsun> various computers need certain quirks to allow binding of volume keys to certain mixer elements
<tsmithe> oh right
<enyc> the odd thing i noticed (not ubuntu specific) is that OSS sb16 works fine but ALSA sb16 will only work with a pnp sb16/32/64 card............
<crimsun> enyc: i.e., "true" PnP cards.
<enyc> even if told to use specific settings and everything -- not sure i have tried softconfig'ing the card then loading linux without reboot
<enyc> where OSS just works fine on them... bah
<crimsun> there are bugs about that; Scott and Matthew have discussed it unceasingly. Blame broken MODALIAS.
<crimsun> tsmithe: if you don't have an appreciation for the strong hand that Microsoft forces on developers of hardware to be given driver certification, you'll see its positive sides very quickly
<crimsun> there're essentially _zero_ audio chipsets that don't need quirks of some sort
<crimsun> hence we have AC'97 quirks, HDA quirks, USB quirks, ...
<enyc> crimsun: hrrm what about recent requirments to apparently keep much hardware spec secret to get tilt-bit-support "securty-by-obscurity" drivers-locked-to-hardware-quirks for aacs certification  mess ?
<enyc> crimsun: is this going to cause problems in linux-driver-land ?
<crimsun> enyc: thankfully not very much has touched audio chipsets
<tsmithe> hmm
<enyc> crimsun: hrrm bit i wonder where this mess is going
<crimsun> that I don't know, else I'd have gotten out of this business a long time ago
<enyc> crimsun: ;-)
<enyc> crimsun: erm... so why are these font dirs changing? is this changed in debian etch too?
<crimsun> yes, we inherited the change from Debian
<enyc> crimsun: dapper uses old dirs, edgy usually supports both (fontconfig programs....), feisty only puts files in new location?
<tsmithe> so wait... there are quirks even though Microsoft enforces driver certification... i don't quite understand... surely certification should mean conformance to specs, right?
<crimsun> tsmithe: it does for "them", yes
<tsmithe> ooohhh
<tsmithe> right.
<crimsun> for the most part, FLOSS doesn't get the benefit of the doubt; there's a lot of poking, proding, trial by error, etc.
<crimsun> prodding
<tsmithe> that's sad
<enyc> well this means FLOSS that is looked-at/used tends to get well-fixed hence reliable ?
<crimsun> more reliable, generally
<enyc> crimsun: I would like to know if feisty is _supposed_ to only be using /usr/share/fonts/X11 for x11-fonts and no-longer us /usr/share/fonts/X11/
<crimsun> enyc: I don't have a fresh 7.04 env; check the Herd-2 desktop CD
<tsmithe> hang on...
<tsmithe> so you really do run breezy?
<crimsun> did you think I was joking?
<tsmithe> yes
<tsmithe> hence, "/me doesn't believe you!"
<crimsun> chroots are good things.
<tsmithe> so you run breezy and have a chroot for everything else
<enyc> crimsun: fair-enough... thanks for comments ;-)
<crimsun> tsmithe: across most computers, either 5.10 or 6.06 is the base; all have 6.10 dist-upgraded to 7.04
<tsmithe> but why?
<crimsun> ever tried troubleshooting/debugging/testing a fix for a release that you're not running?
<tsmithe> ah
<crimsun> In any case, I don't plan to leave Ubuntu in the lurch; there's definitely a need for a stronger ubuntu-audio team (essentially it has been me for one year)
<tsmithe> yeah
<tsmithe> i can see
<tsmithe> i'd definitely like to learn how to help out
<tsmithe> no...
<tsmithe> i definitely will learn how to help out
<enyc> crimsun: initial reading file-lists seems to suggest all is in /usr/share/fonts/X11/ -- most likely all put there in debian ...
<crimsun> I learned just about everything from watching Thomas Hood, who previously single-handedly maintained ALSA in Debian
<tsmithe> ok
<tsmithe> i'll watch you
<tsmithe> follow you to your meetings
<tsmithe> to hong kong
<crimsun> nope, don't watch me; track all those resources I've mentioned
<tsmithe> ok
<tsmithe> right
* tsmithe gets subscribed
<jdong> crimsun: hmm? what do you mean,  that's not exactly a "no source change necessary" for avidemux?
<jdong> crimsun: I'm sitting here puzzled about the FTBFS'es recorded for ffmpeg and avidemux....
<jdong> pkgmaintainermangler: Error: /build/buildd/ffmpeg-0.cvs20060823/debian/ffmpeg-dbgsym/DEBIAN/control already contains an Original-Maintainer field; aborting
<jdong> and avidemux complains about a translation file missing
<jdong> both of which didn't happen in my pbuilders.... :(
<geser> jdong: install pkgbinarymangler in your pbuilder and enable it
<geser> if you rebuild the package now you should get these messages also
<rexbron> any revu admins here?
<tsmithe> this file - soma_2.3.1-0ubuntu1.dsc - i take it :P
#ubuntu-motu 2007-01-21
<rexbron> any revu admins that read this, please remove soma_2.3.1.dsc 
<rexbron> the latest version
<LaserJock> rexbron: you can also email them
<rexbron> revu@?
<rexbron> tauware.de?
<LaserJock> I don't think so
<LaserJock> check the REVU wiki page
<rexbron> kk
<rexbron> hmm, the address listed is for keyring
<LaserJock> further down the page
* rexbron feels silly
<rexbron> thanks LaserJock
<tenshu> anyone could recommand me a package build with CDBS containing a php app?
<jdong> geser: is this pkgbinarymangler thing new in Feisty, as far as the buildds are concerned?
<LaserJock> jdong: since Edgy I think
<geser> pkgbinarymangler exists already in edgy
<jdong> hmm
<jdong> then why did the build fail?
<jdong> I'm still not understanding what the error message means
<geser> it contains the two programs that do the maintainer mangling in the binary debs on the buildds and pkgstriptranslations
<jdong> the package definitely built in Edgy buildd's fine
<jdong> no new ffmpeg has been released since feisty's open
<geser> which package?
<jdong> geser: ffmpeg: http://librarian.launchpad.net/5805778/buildlog_ubuntu-feisty-i386.ffmpeg_3%3A0.cvs20060823-3.1ubuntu2_FAILEDTOBUILD.txt.gz
<geser> the normal pbuilder doesn't have pkgbinarymangler installed (but the buildds have)
<jdong> geser: I did a 1-line patch to x264.c, and also a unrelated debian/rules change to unlock more cheatcodes in 'risky mode'
<jdong> geser: as I said, this package has been unchanged basically since its late-Edgy upload and that built just fine...
<LaserJock> jdong: ouch that is a not-so-nice error
<jdong> LaserJock: I know... never seen anything like it before
<jdong> and can a more experience eye look at this one for me, too? : http://librarian.launchpad.net/5805779/buildlog_ubuntu-feisty-amd64.avidemux_1%3A2.3.0-0.0ubuntu2_FAILEDTOBUILD.txt.gz
<jdong> it complains about a translation file missing
<jdong> but I just built the same source pkg again in my pbuilder
<jdong> and could not cause that error to show up
<jdong> at this point I'm beginning to question my sanity :)
<geser> ha, we are supposed to change the Maintainer (and set Original-Maintainer) but the buildds don't like it
<LaserJock> yep
<geser> jdong: it's not pkgstriptranslations erroring but pkgmaintainermangler
<LaserJock> jdong: the problem is that Original-Maintiner is set in debian/control
<jdong> LaserJock: it is?
<LaserJock> yep
* jdong regrabs source package
<jdong> I swear I didn't see it before :)
<geser> jdong: "[...]  already contains an Original-Maintainer field"
<LaserJock> Maintainer: MOTU Media Team <motumedia@tauware.de>
<LaserJock> Original-Maintainer: Sam Hocevar (Debian packages) <sam+deb@zoy.org>
<jdong> LaserJock: yeah, I see that now
<jdong> LaserJock: it wasn't in the debdiff I gave crimsun....
<jdong> crimsun: contentless ping....
<jdong> ha! I defeated his ping checker!
<LaserJock> jdong: cruel
<jdong> lol
<jdong> LaserJock: so do humans put in that field or could it have been done automagically during the upload?
<LaserJock> well, at this moment I'm not exactly sure
<LaserJock> it's currently being discussed
<LaserJock> I think it has to be human because I don't think they've implemented the automagic stuff yet
<jdong> ok
<LaserJock> we were told that we should be doing it
<LaserJock> but there's debate as to what field it should be exactly
<LaserJock> so nobody has been doing it yet I don't think
<LaserJock> but maybe crimsun added it
<jdong> well, this is the first then :)
<jdong> crimsun: ok, serious ping, ffmpeg's Original-Maintainer field upsets buildd; apologies about the previous contentless ping
<geser> as the mail to feisty-changes already has motu media as maintainer I'd guess crimsun did it
<geser> \sh also uploaded some packages with modified maintainer
<jdong> any takers on the avidemux FTBFS I posted?
<geser> jdong: the build failed because MOTU Media isn't in the exception list for pkgbinarymangler
<geser> for ffmpeg
<jdong> geser: ok... who do I go to for fixing that?
<geser> ask infinity or pitti as they maintain pkgbinarymangler
<LaserJock> darn, I hate it when all the good stuff is in the devel release
<jdong> any ideas on http://librarian.launchpad.net/5805779/buildlog_ubuntu-feisty-amd64.avidemux_1%3A2.3.0-0.0ubuntu2_FAILEDTOBUILD.txt.gz?
<jdong> mv: cannot stat `t-es.gmo': No such file or directory
<jdong> it built fine twice in my pbuilder
<LaserJock> I want to try bzr-builddeb :/
<geser> I don't understand either why it succeeded on powerpc and sparc and failed on the other archs
<jdong> geser: nor do I; hence me questioning my sanity :)
<gnomefreak> is there a reason why pbuilder never makes ~/.pbuilderrc
<owh> gnomefreak: It's having a bad hair day perhaps?
* owh apologises for the lame joke.
<gnomefreak> it never has from dapper to feisty :(
<owh> gnomefreak: Sorry, my joke was an attempt at levity. I've just had my first coffee after a crap night sleep with a sore tooth. I'll try to be more helpful next time :-)
<somerville32> gnomefreak, You don't want it to
<gnomefreak> somerville32: sure i do
<somerville32> gnomefreak, The just create it.
<somerville32> *Then
<gnomefreak> somerville32: why wouldnt i?
<LaserJock> gnomefreak: why do you want one?
<LaserJock> ~/.pbuilderrc will override /etc/pbuilderrc
<gnomefreak> path is ~/pbuilder/pbuilderrc   and for the config file
<gnomefreak> i typoed the path sorry
<gnomefreak> oh crap
<gnomefreak> its /etc/
<LaserJock> gnomefreak: heh, what exactly is your question/problem?
<gnomefreak> i was looking at the warning and it didnt create ~/pbuilder/pbuilderrc but if the config is /etc/pbuilder/pbuilderrc than i ignore it
<gnomefreak> now that im done traveling im setting my system up for building again :(
<owh> gnomefreak: Done travelling already. After four years of it, I haven't even scratched the surface :)
<gnomefreak> lol :)
<LaserJock> gnomefreak: don't use either /etc/pbuilder/pbuilderrc or ~/.pbuilderrc
* gnomefreak thinks packaging and drinking isnt gonna work too well after a while
<gnomefreak> LaserJock: so i dont need to follow guide in that much detail?
* owh agrees with gnomefreak - of course only if the drink has toxic side effects.
<LaserJock> gnomefreak: which guide?
<gnomefreak> https://wiki.ubuntu.com/PbuilderHowto?highlight=%28pbuilder%29
<LaserJock> no, don't bother with that one
<gnomefreak> i lost the good guide i had
<LaserJock> gnomefreak: use http://tiber.tauware.de/~laserjock/pbuilder-feisty
<gnomefreak> a new one ;)
<gnomefreak> oh script
<LaserJock> just drop it into your PATH (I use ~/bin) and run pbuilder-feisty create
<LaserJock> and then if you need a pbuilder for edgy say, just cp pbuilder-feisty to pbuilder-edgy and modify DISTRIBUTION in there
<LaserJock> gnomefreak: that's a script that actually comes with pbuilder, I just modified it to work with Ubuntu
<gnomefreak> put the script in ~/bin?
<LaserJock> if ~/bin is in your path
<LaserJock> also mkdir -p ~/pbuilder/feisty_result
<LaserJock> ^^ is where your .debs will end up
<enyc> meepmoop
* enyc had problem calculating upgrade problem  with update-manager -d  to fiesty!!  well try again later... may post bugreport as requested!
* gnomefreak hasnt set a path anywhere 
<enyc> (on experimental-machine) ;-)
<LaserJock> gnomefreak: just add export PATH=~/bin:$PATH in .bashrc
<gnomefreak> enyc: post it please. and attach the three files in /var/log/dist-upgrade ;)
<gnomefreak> easy enough :)
<enyc> gnomefreak: the funny thing is  apt-get --download-only dist-upgrade is happy (when ran with the new sources still set)
<enyc> gnomefreak: will do if i get the message again when look at machine next (soon!)
<enyc> why might there be a problem anyway?
<gnomefreak> LaserJock: using sudo is ok right?
<gnomefreak> for pbuilder-feisty create
<LaserJock> you just have to do pbuilder-feisty create
<gnomefreak> its telling me permissions denied
<gnomefreak> saved the script in /bin
<gnomefreak> oops /bin/pbuilder-fesity
<gnomefreak> when i run pbuilder-feisty create it wants sudo
<gnomefreak> maybe chmod 755 it?
<LaserJock> gnomefreak: no
<LaserJock> you put it in ~/bin/ ?
<LaserJock> and you run pbuilder-feisty create
<owh> gnomefreak: Well, the script that LaserJock showed you has a sudo command in it, so that's not too surprising.
<gnomefreak> yes im cded into bin atm and i see pbuilder-feisty there
<LaserJock> and it asks you for your password, right
<gnomefreak> yep
<LaserJock> that's right
<gnomefreak> bash: /bin/pbuilder-feisty: Permission denied
<LaserJock> pbuilder needs root privileges
<gnomefreak> so sudo pbuilder-feisty create
<LaserJock> no
<owh> gnomefreak: Do you have a $HOME set?
<LaserJock> that script already has sudo in it
<gnomefreak> ofcourse not
<LaserJock> ?
<gnomefreak> nope not in bashrc i dont
<LaserJock> gnomefreak: echo $HOME
<owh> Indeed :)
<gnomefreak> ok
<gnomefreak> now it should work i hope
<gnomefreak> nope and echo $HOME repeats my /gnomefreask/homne
<gnomefreak> only spelled right
<LaserJock> and you have sudo rights on that computer?
<owh> So, just to make sure, you are a sudo-er?
<gnomefreak> yes
<gnomefreak> im the only user
* owh cannot recall the command for trace in bash.
<gnomefreak> should i replace $HOME with my home dir?
<geser> LaserJock: about your pbuilder script: have you see bug #57284 ?
<Ubugtu> Malone bug 57284 in pbuilder "examples/pbuilder-distribution.sh: Funny shell error" [Undecided,Fix released]  https://launchpad.net/bugs/57284
<owh> I thought you just said that it was set to that.
<LaserJock> gnomefreak: hmm, maybe you should 755 it
<gnomefreak> in terminal when ran it gives me my home
<owh> LaserJock: Would this work: HOME=~ pbuilder-feisty create
<gnomefreak> oh crap
<gnomefreak> nvm
<gnomefreak> that wasnt it either
<gnomefreak> ok ill try chmoding it
<LaserJock> geser: interesting
<gnomefreak> ok its building :)
<gnomefreak> ty
<LaserJock> hmm, it'd dawn on me the first time you said it wasn't +x
<LaserJock> *it didn't
<owh> Heh
<gnomefreak> ah
<owh> LaserJock: That's old age setting in early :-)
<LaserJock> must be
<LaserJock> grad school must be burning my brain out
<owh> LaserJock: No, just all the chemicals :)
<LaserJock> doh
<geser> LaserJock: if I'm not mistaken this "bug" is still in the script from the last pbuilder
<gnomefreak> it hit me while i was smoking from when i was writing bash scrtipts you chmod a+x it :(
<owh> Also, the "new" script looks a whole lot less readable than your version does.
<owh> I like the change for the DISTRIBUTION definition, but really it should be a parameter, or use the name of the script.
<geser> I use DISTRIBUTION=`basename $0 | cut -f2 -d '-'`
<owh> geser: Yeah, but that means that if you want to change what you're building, you still need to change the script.
<owh> geser: If you use the name of the script itself, then it will just work.
<owh> Doh.
* owh smacks self around.
<owh> geser: I'm an idiot.
* LaserJock headdesks
<geser> I've pbuilder-feisty and pbuilder-edgy (which is a symlink to the former)
<owh> geser: Yes, I read basename and thought uname.
<siretart> tsmithe: I am around from time to time! :)
<owh> geser: It already does what I was espousing :)
<LaserJock> owh: yeah, when you said that I suddenly realized that too
* owh is obviously not properly awake yet and blames it on my toothache.
<LaserJock> siretart: well, I installed bzr-builddeb on my edgy machine, hopefully it works ok
<owh> So, the script that LaserJock showed us should be modified with the DISTRIBUTION=`basename $0 | cut -f2 -d '-'`, *and* a fix for the ( $PROCEED == true ) bit. I'm not sure what it should be though.
<siretart> LaserJock: does edgy have bzr 0.13? then it should work
<siretart> LaserJock: otherwise, there is also an 0.11 branch, which we need for debian ATM
<LaserJock> I get bzr from bazaar-vcs.org so I have 0.14
<LaserJock> I grabed the Feisty debs of python-central, python-debian, and python-deb288 and they installed without complaint
<owh> Hey, anyone know a little/lot about OO.o builds around here?
<geser> owh: the ( $PROCEED == true) part works but not for the reason you would imagine at first
<geser> export PROCEED=true; if ( $PROCEED == false ); then echo "true"; fi
<geser> gives also "true"
<owh> Indeed :-)
<geser> a simple "if $PROCEED then" should also work
<siretart> LaserJock: oh, if you use bzr 0.14, you might be interested in directly using james' 0.14 branch
<siretart> LaserJock: the differences aren't that big, the bzr guys changed the API of the optionsparser, which needed to be adapted
<owh> geser: Well, PROCEED=true, makes $PROCEED contain a text string "true". But the compare, tests it against the command true, which is not the same thing. You could also do if ($PROCEED == "true").
<siretart> however, james is using his 0.14 tree as trunk for further development
<geser> owh: export PROCEED=true; if ( $PROCEED == "nottrue" ); then echo "true"; fi gives still true
<owh> Hmm, that didn't work as expected.
<owh> geser: Indeed.
<geser> its the true from $PROCEED that gets executed
<owh> geser: So, I'm guessing that bash is getting in the way.
<geser> ( != [
<owh> geser: You are correct.
<owh> geser: That is about the $PROCEED being executed.
<geser> if you set $PROCEED to something other you get "Command not found"
<owh> geser, This works: if [ $PROCEED == "true" ] 
* owh has no idea why :0)
<geser> because here it's a string
* owh does not know about the difference between []  and () in bash.
<geser> man [
<geser> though bash has a built-in [
<owh> Well then would if [$PROCEED]  work?
<owh> Nop
<owh> +e
<geser> ($PROCEED) would work, [$PROCEED]  not
<geser> in the [ case $PROCEED is used as text
<owh> geser: Yes, because that would be executed as true. Simple :-)
<owh> So, the patch is remove '== "true"' from the script.
* owh goes and gets a pain killer.
<geser> for the toothache or the headache? :P
<owh> geser: Funnily enough a headache brought on by the toothache :0)
<owh> Anyway. I've just had a client with a crashing OO install, using Dapper's v2.0.2, Edgy is running 2.0.4 and current stable from OO.o is 2.1. I noticed after rutting through the source that some functionality I see is actually missing from the source-code. Which leads me to ask. Where does Debian/Ubuntu get its source from?
<LaserJock> a mythical code fairy
<owh> I Debianised the RPM installer from OO.o's site, but of course that doesn't include the stuff that is in 2.0.2 and 2.0.4.
<owh> LaserJock: Feels like it :)
<geser> LaserJock: aka doko?
<LaserJock> owh: there isn't a Readme.Debian or anything?
<owh> Hmm, oo.o-scribblers is a big hint.
<owh> LaserJock: Not with anything like that. It starts with "This is not up to date."
<LaserJock> ever so helpful
<owh> Just for fun, this is what it says: [Note: This document didn't see yet a complete review for OpenOffice.org 2.0] 
<owh> LaserJock: Someone in #dev.openoffice.org pointed to the idea that there is a Novell release, but I'm not sure if Debian would use that. The only source I found in the testing distribution points to v1.0.1 downloaded from OO.o
<owh> LaserJock: It appears as if OO.o is a little like the kernel. Each distro adds its own patch set.
<owh> LaserJock: Nothing like standardisation around here :)
<snikker> i'm unable to make a .deb package from source. i've got an error: "dh_install: command returned error code 256"
<LaserJock> snikker: can you pastebin the whole build log for us?
<snikker> yes, just a moment...
<ajmitch> darn, the meeting time has been chosen, and it's the one I can't really attend so well
<snikker> LaserJock: http://pastebin.com/863940
<snikker> LaserJock: i've compiled it under edgy
<somerville32> ajmitch, Thats so sad :(
<somerville32> ajmitch, It's ok. I'll be there.
<ajmitch> that just makes me feel so much better
* somerville32 knew it would.
<somerville32> Besides, who said you were invited anyhow? :P
<LaserJock> ajmitch: how did Monday get choosen? It's split 3 to 3 on the wiki page
<ajmitch> yeah, I don't know, thinking I'm a MOTU & all when I'm obviously not worthy of the title
* ajmitch goes off to remove his name from LP
* somerville32 comforts ajmitch in his time of need.
<LaserJock> somerville32: being one of the senior MOTUs and a core-dev usually  warrants an invite
* somerville32 would tend to think so.
<ajmitch> LaserJock: but I'm obviously not one, somerville32 has decreed it
<somerville32> For sure
<LaserJock> snikker: can you translate "cp: impossibile fare stat di" for me?
<LaserJock> I'm guessing something like maybe "can't find file" or something
<snikker> LaserJock: "cp: unable to make stat of"
<snikker> LaserJock: "Nessun file o directory" ---> "not such file or directory"
<LaserJock> snikker: well, lua-curl-0.2.0/debian/tmp///-e is definately an odd directory name
<snikker> LaserJock: there is a way for fix it?
<LaserJock> snikker: is this a source package from Ubuntu repos?
<snikker> LaserJock: yes, it's source (.gz, .diff, .dsc) from ubuntu feisty repos, compiled under edgy
<LaserJock> snikker: ok, I'm building it real quick to see if I can replicate that
<LaserJock> it really seems odd that it would have a problem like that
<LaserJock> it's a CDBS package with no install file
<LaserJock> it shouldn't have a problem I don't think
<snikker> LaserJock: ok, tell me if you can build it...
<LaserJock> hmm, well first problem is a missing build dependency
<LaserJock> snikker: did you know it needed lua5.1-policy-dev ?
<snikker> LaserJock: yes, i've build it from source and i've instelled it
<LaserJock> snikker: well, I gotta go
<LaserJock> I haven't figured it out yet
<LaserJock> it could be something obvious but I don't see what
<LaserJock> maybe ajmitch could tell
<snikker> LaserJock: ok, thanks
<snikker> ajmitch: hi, can i ask to you?
<snikker> ajmitch: i'm unable to make a .deb package from source. i've got an error: "dh_install: command returned error code 256"
<rexbron> hey, can anyone help with a licening problem?
<rexbron> if the COPYING file says that the project is GPL
<somerville32> rexbron, Yes...
<pianoboy3333> How does dpkg actually build a package? I'm just wondering... because you have the rules file, which makes the file, but then what "make install"s it, and keeps track of where the files are?
<crimsun> see dpkg-buildpackage.
<pianoboy3333> does that tell m e of the internal workings? I'm talking about the actual way in the source code that dpkg-buildpackage builds a package
<crimsun> the internal workings of what, dpkg-buildpackage? That's a pretty silly question.
<pianoboy3333> crimsun: how come?
<crimsun> of course dpkg-buildpackage will tell you of the internal workings of dpkg-buildpackage.
<crimsun> if you're itching, read the actual Perl script.
<crimsun> sorry, shell script
<crimsun> [meaning if you're intent, read dpkg-source, which is a Perl script] 
<imbrandon> ello all
<Laser_away> imbrandon!
<imbrandon> heya Laser_away ;)
<imbrandon> LaserJock, hehe i've been giving archive.ubuntu.com a run for its money, i've had a 9.xx MB/s connection to it for 7+ hours now
<imbrandon> ( rsync )
<imbrandon> i was suprised when i looked at the graphs today
<imbrandon> http://www.imbrandon.com/misc/bandwidth/current.png
<imbrandon> w00t for fast connections, i'll be glad when i finaly get these build boxes all finished
<imbrandon> hehe
<ademan> hey the system docs for packaging has a typo, is there any easy way for me to fix that?
<persia> ademan: Which document?
<ademan> patch Systems -> Patching without a patch system
<ademan> might have already been fixed, it's a totally nothing typo,  "but" instead of "put"
<tsmithe> why do people on the forums say, "First, I suggest above all else installing Automatix so you can use files like .mp3 and other nifty programs to have, like Java and bittorrent programs.", to new users!!!
<ademan> it's easy i guess?
<ademan> easyubuntu is better imho though
<persia> ademan: Do you mean on the Wiki?
<tsmithe> ademan, but it breaks systems!
<ademan> persia: if you go to System->Help->System documentation   then click on packaging applications for ubuntu, then go to "Patch Systems->Patching Without a Patch System"
<persia> ademan: I don't seem to have that option.  In any case, if you want to fix it, you can find the filename from the link address, and then submit a bug including the patch to LP.
<ademan> well right now i'm tryin to package code::blocks, which is a bit more important to me, but i'll get around to it hopefully
<vil> ademan, you seem to abandon eclipse-cdt :)
<ademan> vil: :-( yeah, my comp just can't handle it
<ademan> plus it got dropped, to make matters way way worse
<vil> ademan, what do you mean by dropped?
<ademan> fell off a table
<ademan> my 3d card is borked now, God knows what else
<vil> hopefully, it the 3d was not fault of eclipse-cdt :)
<ademan> hahah, i would think not
<snikker> i'm unable to make a .deb package from source. i've got an error: "dh_install: command returned error code 256"
<Hobbsee> snikker: not enough information.  please pastebin all of the buildlog
<snikker> Hobbsee: http://pastebin.com/863976
<StevenK> Does the package have any .install files in debian/ ?
<Hobbsee> #
<Hobbsee> cp: unable to make stat of `/home/snikker/misc/install-packages/amd64/deb-packages/application/beta/add_pkg/src_feisty/lua-curl-0.2.0/debian/tmp///-e': Not such file or directory
<snikker> Hobbsee:yes, i've got: "liblua5.1-curl-dev.install" and "liblua5.1-curl0.install"
<Hobbsee> snikker: what command did you use to build this?
<snikker> Hobbsee:yes, i've applied the diff file, then "dpkg-source -x *.dsc" the "debuild -us -uc" in the source folder
<Hobbsee> ah right
<snikker> Hobbsee: i've take the source from ubuntu feisty repository and i've compiled it under edgy, if this can help
<snikker> Hobbsee: i go to dinner... see you later
<Amaranth> \sh_away: congrats
* pochu is back (gone 00:01:06)
* pochu is away: Estoy ocupado
<Hobbsee> pochu: please remove that away message
<snikker> Hobbsee: i'm come back
<Hobbsee> snikker: yay.  dont know the answer though
<snikker> Hobbsee: ah, ok.
* StevenK could be convinced to look.
<StevenK> snikker: Which package and version are you trying to build on Edgy?
<snikker> StevenK:  i've tried to compile "lua-curl-0.2.0" (source from feisty) on edgy
<snikker> StevenK: my build log is here: http://pastebin.com/863976
<StevenK> I saw that, thanks
<snikker> StevenK: ok  :)
<StevenK> I've been asked to do something else, so I'll look in a sec.
<snikker> StevenK: ok, thanks
* StevenK wonders if building lua-curl and burning a DVD at the same time is a clever thing to be doing.
<Hobbsee> nope
<StevenK> My machine seems to coping, so nyah. :-)
<StevenK> snikker: I note lua5.1-policy-dev is a build dependancy which doesn't exist in Edgy.
<snikker> StevenK: yes, i've saw. i've already build and installed this package.
<StevenK> Right.
<StevenK> Could I be lazy and grab that?
<snikker> StevenK: yes, just a moment...
<imbrandon> moins Hobbsee and StevenK 
<Hobbsee> hey imbrandon 
<Hobbsee> imbrandon: feel like making gnome-applets build again?
<Hobbsee> er, install again?
* StevenK waves to imbrandon 
<StevenK> imbrandon: Long time, etc etc
<imbrandon> Hobbsee, i can give it a go in a few
<Hobbsee> imbrandon: thanks.  http://buntudot.org/people/~hobbsee/gnome-applets.debdiff
<imbrandon> StevenK, heh yea , i've been on diffrent hours than i was 
<imbrandon> ;)
<imbrandon> Hobbsee, kk
<StevenK> Oh, liboobs
<StevenK> Trust Hobbsee to touch that package
* StevenK ducks
* Hobbsee smacks StevenK 
<StevenK> Ow!
* Hobbsee waves her Long Pointy Stick of DOOM!!!!!!!!!!!!!!!  around in warning
<imbrandon> heh
<snikker> StevenK: i'm tring to send it through dcc
<AnAnt> ?
<Hobbsee> snikker: StevenK doesnt take dcc.  most people dont
<snikker> Hobbsee: how can i send it?
<AnAnt> Hello, I have a question
<StevenK> snikker: Are you able to put it up on the web?
<AnAnt> http://revu.tauware.de/details.py?upid=4110
<Hobbsee> AnAnt: that's not a question.  that's a URL.
<StevenK> AnAnt: That's a URL, not a question.
<AnAnt> what's meant by "unnecessary dh_make comment lines" in the comment there
* StevenK high fives Hobbsee
<Hobbsee> StevenK: :D
<snikker> StevenK: no at this moment :(
<StevenK> snikker: e-mail?
<Hobbsee> snikker: hyperupload.com usually works
<AnAnt> ^-- that 's my question
<StevenK> hyperupload.com? Don't know that one
<imbrandon> AnAnt, it means in your debian/rules there are unnneeded comment lines 
<snikker> StevenK: yes
<snikker> StevenK: or i can try through hyperupload
<AnAnt> what are unneeded comment lines ? are all comment lines unneeded or what ?
<Adri2000> AnAnt: it means you can remove in debian/rules all the lines #dh_*
<AnAnt> Adri2000: oh, ok, thanks !
<StevenK> snikker: Let's listen to Hobbsee and try this hyperupload thing
<nuke13> Hi all
<Hobbsee> it's got a limiter on it - but i used to use it all the time before getting imbrandon's shell
<snikker> StevenK: ok i've do it. look here: "http://hyperupload.com/download/02d1679559/lua5.1-policy-dev_6_all.deb.html" 
<StevenK> Length: 10,878 (11K) [application/force-download] 
<StevenK> Nice MIME type, you bozos.
<Hobbsee> StevenK: click on the html page.  duh
<Hobbsee> or just take otu the .html
<StevenK> I did, it's the actual .deb downloading, but the MIME type is wrong
<AnAnt> btw, anyone here from france ? esp. Paris ?
<StevenK> So my bitching is justified, so nyah.
<Hobbsee> ah
<StevenK> snikker: Right, trying this whole building thing again
<AnAnt> ping lionel 
<StevenK> snikker: Reproduced, so way cool
<snikker> StevenK: do you have my same error?
<StevenK> Yup
<snikker> StevenK: there is a way for fix it?
<StevenK> To be honest, I'm suprised this thing built on feisty.
<Hobbsee> hah
<nuke13> c ya laters
<StevenK> snikker: However, the way to fix it to remove the '-e' from the start of the lines in the two .install files
<StevenK> s/fix it/fix it is/
<snikker> StevenK: ok, now i try :)
<lionel> pong AnAnt
<lionel> too late :)
<AnAnt> if I am going to patch a file in the orig tarball, is it better to use dpatch system ?
<lionel> AnAnt: you were looking for me ?
<AnAnt> lionel: yeah
<persia> AnAnt: If it is a new package, yes.  If it is an existing package, follow the format in debian/patches (or patch directly if it does not exist).
<AnAnt> persia: thanks
<snikker> StevenK: i've tried to do what you said, but don't work :(
<Hobbsee> persia: and it depends on how big the patch is
<persia> Hobbsee: How big?  How?
<Hobbsee> as in, if you're making major changes, then using dpatch is probably a good idea.  for a 2x line fix or something...then you probably woudltn bother
<StevenK> snikker: Same error?
<persia> Hobbsee: What do you recommend for simple fixes in new packages?  I like simple-patchsys for CDBS, but most new packages don't seem to be CDBS.
<Hobbsee> persia: dpatch.  or manually patch it.  whichever
<Hobbsee> it's rather personal preference
<persia> Hobbsee: I understand.  I like debian/ changes only, but I've quite a few patches the other way :)
<snikker> StevenK: no another error. i've run "debuild -us -uc" in source dir without clean, i past the log, if it can help... 
<StevenK> snikker: Please do
<Hobbsee> persia: yeah :) use dpatch, manual patching, or simple patchsys.  they're the common ones.  or if it's a 2 line fix or something, change the file
<snikker> StevenK: http://pastebin.com/864204
<StevenK> #
<StevenK> dpkg-source: cannot represent change to lua-curl_0.2.0-3.diff.gz: binary file contents changed
<StevenK> #
<StevenK> dpkg-source: cannot represent change to lua-curl_0.2.0.orig.tar.gz: binary file contents changed
<StevenK> That is probably the issue
<StevenK> Oh, I know exactly why it doesn't work
<snikker> StevenK: http://pastebin.com/86
<StevenK> snikker: If you sort out the above problem, add 'SHELL=/bin/bash' to debian/rules
<snikker> StevenK: sorry
<snikker> StevenK: just a moment
<StevenK> To be honest, the excuse this package uses for a build system is *insane*
<StevenK> It adds files to debian/ at *build time*
<snikker> StevenK: same error... :(
<\sh> moins
<Enverex> I thought I'd ask in here as you're all a little more bright. What does the "Supported?" column on the HardwareSupport Wiki mean? (there's also a Working column so I'm wondering it's it's official related)
<tsmithe> crimsun, did you get my pm?
<crimsun> tsmithe: yes, I'm busy writing an abstract atm.
<tsmithe> ok
<tsmithe> that's cool
<crimsun> should take me about 30 more minutes.
<tsmithe> it's ok. take your time :)
<Adri2000> Laser_away: ping (about genesis bugs)
<Adri2000> crimsun: please open an edgy task for bug #59138 (amule)
<Ubugtu> Malone bug 59138 in wxwidgets "[SRU: EDGY]  amule crashes when I close a tab" [Unknown,Unknown]  https://launchpad.net/bugs/59138
<crimsun> Adri2000: you mean wxwidgets2.6, btw.
<Adri2000> yes :)
<tsmithe> crimsun, i'll be away for a bit, should you want me. i'll be back in about half an hour
<tsmithe> hmm
<Adri2000> any core-dev (crimsun? :)): can you approve the edgy task for bug #65457 please
<Ubugtu> Malone bug 65457 in cinepaint "[UNMETDEPS]  cinepaint has unmet dependencies" [Undecided,Fix released]  https://launchpad.net/bugs/65457
<crimsun> done.
<Adri2000> thanks
<Adri2000> crimsun: I have a question about the SRU for cinepaint... I took the version in edgy and changed the dependency to fix the bug... the problem is that it FTBFS. why? because png.c:60:48: error: png.h: No such file or directory (and we can see during the configure that he doesn't find it either). why this dependency is missing? probably because it was not needed in dapper (a B-D already depended on it maybe) and because this package has not
<Adri2000>  been actually built in edgy (no upload or sync during edgy). If I look at the package in feisty, libpng12-dev is a B-D. So, for the SRU, I have to add this B-D, is it ok?
<Adri2000> ouch
<crimsun> Adri2000: if it compiles, yes.
<Adri2000> ok :p
<ScottK-laptop> If any MOTU is up for REVUing, I have http://revu.tauware.de/details.py?upid=4115 if you feel like some Python and http://revu.tauware.de/details.py?upid=4127 if you feel more like Perl.  Both are looking for a second advocate.
<tsmithe> crimsun, are you free to assist me in my task?
<crimsun> tsmithe: I'll ping you, shouldn't be much longer.
<tsmithe> ok
<tsmithe> cool
<asantoni> Ok guys, I have a couple of questions
<asantoni> I'm a developer for Mixxx, and we're trying to push out a new release really soon. We'd like to try to get the new version in Ubuntu.
<asantoni> The old version is already packaged in Debian and Ubuntu... What's the best course of action for getting the package updated? (hopefully before the UVF)
<crimsun> release it.
<crimsun> then file a wishlist bug against the mixxx source package using Launchpad.
<asantoni> ok
<asantoni> what's the usual timeline for that sort of thing?
<crimsun> depends who does the lifting.
<asantoni> hmmm
<asantoni> should I contact the maintainer for the package?
<crimsun> if you guys can verify that an updated source package builds, upgrades/installs successfully, then it can be extremely fast, a matter of hours.
<crimsun> the maintainer is "MOTU", or "us".
<asantoni> hmmm, cool
<crimsun> or if you'd like to get it into Debian first, you could try that route, but Etch freeze is in effect.
<asantoni> ok, so do I have to update the source package, then upload to REVU or sometihng?
<asantoni> (ie. update the source package myself?)
<crimsun> that would be one approach.
<asantoni> hmmm, ok, thanks
<muzzol> warning: source directory `./cinelerra-cv_2.1.0+svn20070109' is not <sourcepackage>-<upstreamversion> `cinelerra-cv-2.1.0+svn20070109'
<muzzol> anyone?
<crimsun> why not cinelerra-cv_2.1.0.svn20070109 ?
<crimsun> (for the source package)
<sladen> has that had the MPEG2 stuff removed?
<sladen> I was having problems getting it to build 6 months ago with the MPEG2 code
<sladen> (Ogg only)
<geser> muzzol: shouldn't the _ between cv and 2 be a - ? ( _ is correct for the orig.tar.gz)
<muzzol> not sure
<muzzol> this naming is a little bit confusing
<crimsun> the directory is probably better named cinelerra-cv-2.1.0+svn20070109 or cinelerra-cv-2.1.0.svn20070109
<muzzol> the directory containing debian subdir?
<muzzol> crimsun
<crimsun> yes
<muzzol> ok, thanks
<muzzol> still a bit confused
<muzzol> :D
<Adri2000> motu-sru needed: https://launchpad.net/ubuntu/edgy/+source/cinepaint/+bug/65457
<Ubugtu> Malone bug 65457 in cinepaint "[SRU]  cinepaint has unmet dependencies" [Medium,In progress]  
<muzzol> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
<muzzol> any hints?
<siretart> tsmithe: you tried to contact me on irc lateley?
<tsmithe> ah yes
<siretart> I do still irc :)
<tsmithe> i was wondering about bzr and debs...
<siretart> it's fun :)
<tsmithe> following your bzr-debuild post
<tsmithe> i think i'll check it out
<siretart> development is still in flow, james_w asked me about missing features we ubuntu devs could need in there
<tsmithe> i think crimsun and Laser_away answered my questions
<tsmithe> cool
<siretart> just try it out and write/blog about stuff that you like or dislike
<tsmithe> yeah
<crimsun> tsmithe: completed, going to grab coffee, back in 20 mins.
<tsmithe> okey
<tsmithe> cool
* tsmithe gets coffee too
<slomo_> siretart: ping? :)
<siretart> slomo_: pong!
<slomo_> siretart: there's a new faac release... unfortunately same soname but very useless ABI changes (5 constants were increased by one)... would you revert that single change (that was done for no reason), Breaks the new lib on the very few users of the lib or use a custom soname?
<siretart> slomo_: how does upstream think about that?
<slomo_> siretart: you know the story about faad2 with the ugly license change and no response upstream... they're the same people ;)
<siretart> omg :/
<siretart> slomo_: I think we'd have least pain if we go with the reverted changes, and notifying upstream about that fact
<siretart> slomo_: I assume you maintain faac/faad  in debian as well, right?
<slomo_> siretart: no, debian has only faad and there it has even greater problems ;) 
<siretart> fun :/
<slomo_> really bad that those are the only "free" implementations of a aac encoder and decoder...
<slomo_> i would even prefer somethnig by the ffmpeg people
<siretart> is there evidence about patent enforcement for faac/faad? I think I remember something, but I'm not sure
<siretart> I've noticed x264 in the debian NEW queue
<slomo_> heh, i doubt this will go through
<slomo_> and for aac... i heard rumours
<siretart> hm. ffmpeg and mplayer got through NEW at last, so why not x264 as well?
<siretart> just curious, what's the difference between faac and faad?
<slomo_> anyway, aac plays in the same league as h264 
<slomo_> well, we had to drop all encoders from gst-ffmpeg to make the ftpmasters happy
<slomo_> and x264 is only an encoder for a format that is patented
<siretart> mom, phon
<siretart> hm, I see
<siretart> after rethinking about it, you're probably right, and ftp-master will reject both aac and x264. which is sad :(
<siretart> hm. there are currently 5 packages using faac: avidemux, gst-plugins-bad-multiverse0.10, gst-plugins-multiverse0.8, mplayer and mythplugins
<siretart> slomo_: does this mean that ffmpeg does not have any means to play aac material?
<slomo_> siretart: yep... exactly that... because ffmpeg is in universe while faac is in multiverse
<slomo_> siretart: and it has no own decoder for it
<siretart> ffmpeg is as good as in main now
<slomo_> hm, and linking newer faad which ffmpeg violates the gpl so maybe someone of the ffmpeg team wants to do it
<slomo_> oh?
<siretart> there is an inclusion request for it pending, and xine ships the internal ffmpeg copy now in main
<slomo_> do you have a list of everything in the ffmpeg versions?
<siretart> sorry?
<slomo_> a list of encoder and decoders for which formats :)
<siretart> puh, I don't think so, no
<slomo_> hm :/ i have a feeling that we might get multiverse much smaller if we can get ffmpeg even in main ;)
<muzzol> how can add universe on pbuilder?
<muzzol> Considering  libavcodec-dev
<muzzol>    -> Trying libavcodec-dev
<muzzol>        -> Cannot install libavcodec-dev; apt errors follow:
<muzzol> Reading package lists... Done
<muzzol> Building dependency tree       
<muzzol> Reading state information... Done
<muzzol> E: Couldn't find package libavcodec-dev
<muzzol> W: Unable to locate package libavcodec-dev
<muzzol> E: Could not satisfy build-dependency.
<muzzol> E: pbuilder-satisfydepends failed.
<muzzol> :(
<enyc> hrrrm
<jdong> muzzol: yeah sure, add it via --othermirror or login --save-after-login and edit sources.list
<muzzol> i've added to OTHERMIRROR variable with no success
<fernando> muzzol: https://wiki.ubuntu.com/PbuilderHowto
<muzzol> thanks!
<geser> muzzol: sudo pbuilder update --override-config --othermirror "deb http://archive.ubuntu.com/ubuntu feisty universe multiverse"
<muzzol> ok, what i've missed is --override-config
<muzzol> thanks
<crimsun> tsmithe: ping?
<crimsun> tsmithe: sorry, ping, ready for git?
<tsmithe> hi hi
<tsmithe> pm?
<crimsun> sure
<gnomefreak> crimsun: is ther eany way we can upgrade the backported flashplugin-nonfree package to 9.0 r31. right now from what i can tell on p.u.c dapper and edgy backports have 9.0 d78. this is to fix bug 79384
<Ubugtu> Malone bug 79384 in flashplugin-nonfree "chinese firefox crash with flash 9 after a single page" [Undecided,Needs info]  https://launchpad.net/bugs/79384
<crimsun> gnomefreak: see jdong :-)
<gnomefreak> ty
<jdong> gnomefreak: I have approved the backport on Edgy
<jdong> gnomefreak: if someone (crimsun?) can testify that it works on Dapper I will approve that too
<gnomefreak> ok skip dapper?
<gnomefreak> ok i just subcribed you to the bug ill add my comments there for you. if i get around to it ill test it on dapper sometime this week
<jdong> gnomefreak: definitely for edgy, feel free to ping cjwatson or an archive admin to let the backport through
* jdong finds bug ticket
<jdong> https://launchpad.net/edgy-backports/+bug/80642
<Ubugtu> Malone bug 80642 in edgy-backports "please backport  flashplugin-nonfree_9.0.31" [Undecided,In progress]  
<gnomefreak> ack
<jdong> gnomefreak: ^^ use that as a reference for talking to archive admins
<gnomefreak> k
<gnomefreak> so its just waiting for a push?
<muzzol> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
<muzzol> anyone?
<ScottK-laptop> muzzol: Dunno about shlibs, but with ${python:Depends} the same error occurs and it can be safely ignored.
<ScottK-laptop> AFAIK..
<AstralJava> Err... how do I get the pbuilder chroot install a local .deb file as build-dependency? I can't make it notice this anyhow.
<muzzol> ok
<muzzol> thanks ScottK-laptop 
<AstralJava> I've tried dbuilderrc to include a HOOKDIR, to no avail. Straight duild-depends in control file won't go either.
<bluefoxicy> If I want a universe package upgraded or something is it correct to file a bug?
<bluefoxicy> (memprof and alleyoop... alleyoop 0.9.0 doesn't work with our version of valgrind, and memprof 0.6 just finally came out)
<Adri2000> yes
* bluefoxicy filed 2 bugs then.
<elliotjhug> Hi all, I am just packaging something for Ubuntu Studio, but one of the dependencies is neither in Ubuntu and a search on the internet reveals very little. Looking for libdivxencore0.
<crimsun> !memprof
<ubotu> memprof: Memory profiler and leak detector. In component main, is optional. Version 0.5.1-12ubuntu1 (edgy), package size 337 kB, installed size 1308 kB (Only available for i386)
<crimsun> !memprof feisty
<ubotu> Sorry, I don't know anything about memprof feisty - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<crimsun> bluefoxicy: did you check the removal criteria for memprof?
<crimsun> bug 324607
<crimsun> debian 324607
<Ubugtu> Debian bug 324607 in wnpp "O: memprof -- Memory profiler and leak detector" [Normal,Closed]  http://bugs.debian.org/324607
<crimsun> i.e., does 0.6.0 address the RC bugs?
<ScottK> Good afternoon bddebian.
<bddebian> Heya ScottK
* ScottK notices the bddebian has already REVUed all his pending packages.  Thanks.
<bddebian> :-)
<crimsun> oh good, no revu work for me
<bddebian> crimsun: The libticonv folks are argueing with me about the dir naming :)
<crimsun> haw
<ScottK> crimsun: Actually I need a second REVU if you're available?
<bluefoxicy> crimsun:  huh?
<crimsun> bluefoxicy: memprof does not exist in 7.04 because it was removed in March '06 from Debian unstable (and thus testing)
<bluefoxicy> crimsun: 0.6 was just released in 2006
<crimsun> right, but is the separate maintenance burden justified?
<bluefoxicy> I don't know if it's "quite dead" still, it may have just woke up to mention that it works still
* bluefoxicy shrugs.
<bluefoxicy> I don't know.
<crimsun> ...well if you're so nonchalant about it, how do you expect fellow busy volunteers to help maintain it?
<bluefoxicy> the past 4 years have been memprof 0.5.1, which didn't work
<bluefoxicy> "The main attraction of 0.6 is that memprof now works again,"  -- http://www.gnome.org/projects/memprof/
<bluefoxicy> crimsun:  I hadn't noticed it was removed, just that it hadn't been updated.
<Adri2000> \sh_away: are you going to fix the FTBFS of xulrunner on ia64?
* bluefoxicy still has it installed
<ScottK> bluefoxicy: Perhaps you should package 0.6 and upload it?
<bluefoxicy> also I am not twisting anyone's arm :P
<bluefoxicy> scottK:  perhaps, perhaps.  I don't deal with Debian though, so it'd be 0.6-0ubuntu1 or something.
<ScottK> Sounds about right.
<bddebian> OMG this tilibs crap is driving me nuts
<ScottK> bddebian: Would you mind archiving http://revu.tauware.de/details.py?upid=4088 - It's a bug fix that I never should have uploaded to REVU?
<bddebian> ScottK: Done
<ScottK-laptop> Thanks.
<ScottK-laptop> bddebian: Any chance you'd have second thoughts and advocate for http://revu.tauware.de/details.py?upid=4114 ...?  I think it's a good package (not that my opinion counts).
<bddebian> ScottK-laptop: What do you mean by second thoughts?
<ScottK-laptop> You reviewed, but didn't advocate, so maybe you change you mind and advocate....
<ScottK-laptop> you/your
<bddebian> ScottK-laptop: Did you fix that warning? :-)
<ScottK-laptop> No, I understood it to be a common one that one needn't worry about.  The predecessor packages that have been uploaded have the same warning.
<ScottK-laptop> If I really need to fix it, I will, of course.
<bddebian> Well it's not really a biggie for me but I never know :-(
* ScottK-laptop is researching...
* ScottK-laptop finds people moaning that it's a stupid warning, but nothing definitive.  Still looking.
<bddebian> crimsun: You have a minute?
<crimsun> slomo_: has bug 80626 been reported upstream?
<Ubugtu> Malone bug 80626 in gstreamer0.10 "Musepack stopped working (The stream is of a different type...)" [Undecided,Confirmed]  https://launchpad.net/bugs/80626
<slomo_> crimsun: it's already fixed upstream
<slomo_> crimsun: see my latest comment there ;)
<crimsun> ah, was it a playbin issue?
<slomo_> no
<slomo_> basetransform and pad issue
<crimsun> oh bah, I loaded the page two minutes before you commented
<crimsun> :-)
<slomo_> heh
<slomo_> i'll let seb decide, i don't have the time to make a new cvs snapshot now or get the n+1 patches to get it right ;) reverting that single change would be fine though... 
<crimsun> ok, left until seb chimes in, then :)
<crimsun> thanks
<ScottK-laptop> bddebian: The solution appears to be removing the shebang.  New upload shortly.
<bddebian> Well I'm hosed.  tilp2 depends on libticables2 which is currently libticables3-3.9.6 in the archives because of sonames but what is supposed to be the "newer" version based on libticables2 is version 1.0.3. How the hell am I gonna fix that?
<ScottK> bddebian: Dunno, but the package is uploaded again with the warning fixed...
<ScottK> http://revu.tauware.de/details.py?upid=4158
<ScottK> bddebian: IIRC persia was discussing a similar versioning problem yesterday.  Don't recall what the solution was.
<geser> bddebian: are libticables3 and libticables2 the same source package?
<bddebian> geser: No, supposedly the libticables2 stuff is "new".  What is currently libticables3 is supposed to be from the "libticables" branch.  But they seem to struggle with soname issues.  I'm having another problem with libticonv.
<geser> can't you introduce a new source package for libticables2?
<bddebian> geser: Yes but there was already a libticables2 package, plus libticables2 < libticables3 even though the code is "newer"
<geser> packages.ubuntu.com know no libticables2 only 3
<bddebian> Apt-cache dump shows a libticables2
<geser> libticables3 conflicts libticables2
<geser> libticables2 seems to be really old
<geser> even Debian doesn't know libticables2
<bddebian> Aye because it was supposed to be based on the "libticables" source..  There never should have been libticables2 and 3
<geser> I'd say it's safe to use libticables2
<geser> you dont have a problem with 2 < 3 as it's in the package name
<bddebian> Well the version is much lower also
<bddebian>  3.9.6 -> 1.0.3
<geser> no problem as long as you don't build it from the libticables3 source package
<geser> and even then exists a solution: add a epoch
<geser> it's for such cases
<bddebian> stupid damn upstream
<geser> the version is only compared for the same source (or binary) packages
<geser> dpkg has no problems if the version of libticables2 is lower than the version of libticables3 as they are different packages
<bddebian> I realize all of this, it just adds mass confusion in my mind
<bddebian> Say I'm packaging some new package that needs libticables.  I look and say "hey" libticables3 must be newer / better than libticables2
<geser> that's the user interpretation but must meet the reality
<geser> see e.g. libgoffice-1 -> libgoffice-0
<bddebian> Well I still think it's just stupid :-)
<muzzol> hi
<muzzol> i get lots of "warning: no utmp entry available and..."
<muzzol> how can i get rid of?
<geser> ignore them
* lupine_85 has a couple of cdbs/debhelper questions if anyone is feeling kind..? :)
<geser> lupine_85: ask, someone will hopefully answer them :)
<lupine_85> :) ok. I've got a debian/ that uses cdbs & debhelper to build multiple packages; I want to add a postinst to just one of those packages
<lupine_85> I tried calling the postinst file debian/<package name>.postinst but that didn't work...
<lupine_85> and my google-fu is low :(
<rexbron> bddebian: would you have time to review murrine, fixed the licening issues upstream, and soma again? upid 4149 and 4150
<muzzol> strange problem here
<muzzol> i'm trying to compile cinelerra package
<muzzol> in control i have: Package: cinelerra
<muzzol> if i change to: Package: cinelerra-cv
<muzzol> the final deb is just a 17k file
<muzzol> containing some doc files
<muzzol> instead of 16M package with binaries
<muzzol> any hints
<muzzol> ?
<jdong> crimsun: thanks for fixing ffmpeg ftbfs :)
<crimsun> np
<jdong> crimsun: ya got any idea why avidemux half-ftbfs'ed?
<jdong> https://launchpad.net/ubuntu/+source/avidemux/1:2.3.0-0.0ubuntu2
<jdong> I'm utterly confused :)
<crimsun> haven't looked
<crimsun> fighting 7.04's kubuntu-desktop
<jdong> it built fine on 2 of 5 archs, the others failing because they couldn't touch some translation file before build
<jdong> and I can't reproduce any of the error messages
<jdong> I think it's either my sanity or the buildd's :D
<Adri2000> crimsun: you can upload cinepaint :)
<crimsun> sorry, I need to smack myself first
<Adri2000> why?
#ubuntu-motu 2008-01-14
<crimsun> much better.  No more menu clutter!
<wolfger> OK, I'm closer to done with my first packaging attempt... but I've got a bug. Anybody care to help me figure it out?
<crimsun> go ahead
<wolfger> I'm packaging a python app, following a tutorial posted here: http://wiki.showmedo.com/index.php/LinuxJensMakingDeb
<somerville32> wolfger, Upload it to revu so that we can review it with you
<wolfger> the problem I have is after I alter paths in the python files (to match where they will be installed by the deb), the end product produces an error:
<wolfger> k. How do I do that, somerville32
<somerville32> wolfger, Were you able to generate a source package?
<persia> mok0: RFC822 is obsoleted by RFC 2822.  I stopped reading all the RFCs around 3000, so there may also be a newer one.
<persia> RainCT: Let's wait a bit more.  If interdiffs are permitted to go away, we won't need it.  On the other hand, if Interdiffs are here to stay, it should reduce the number of people who ask me how to process them.
 * persia notes that while both falcons were reviewed, both parties were advised of the other effort, and both candidate packages had other problems in the last review.
<wolfger> somerville32: yes I get the .dsc and the .deb and the .deb installs the program
<wolfger> but it doesn't run
<somerville32> Using the command dput
<somerville32> passing revu and then the filename of your dsc file
<somerville32> ie.
<somerville32> dput revu package.dsc
<Kmos> somerville32: should be package*.changes
<pochu> persia: so you didn't acked it? :(
<somerville32> kmos, right
<somerville32> wolfger, Sorry, you'll want to upload the changes file and not the dsc file
<persia> pochu: I avoid ACKing any NEW packages if I can find any excuse to not do so :)
<Seveas> persia, 2822 has indeed been superseded
<pochu> heh
<persia> Seveas: What's the new one?
<wolfger> somerville32: right. I just got that message...
<wolfger> ls
<Seveas> forgot :)
<Seveas> persia, hmm, looks like I'm mixing a few things I recently needed
<Seveas> 2822 wasn't superseded
<wolfger> somerville32: it finished. The package is "memaker"
<somerville32> wolfger, What is the link to your launchpad page?
<wolfger> somerville32: https://launchpad.net/~wolfger
<somerville32> wolfger, You're not a member of the universe-contributors group meaning that your upload to revu was rejected.
<wolfger> oh, ok
<somerville32> https:/launchpad.net/~ubuntu-universe-contributors
<wolfger> dput said "successfully uploaded", so I believed it...
<somerville32> It was silently rejected
<wolfger> somerville32: followed the link and joined. I need to dput again, I take it?
<somerville32> wolfger, Unfortunately, the keyring for revu needs to be synced before you can do so
<wolfger> alright. When will that be?
 * persia syncs the keyring
<wolfger> like magic :-D
<wolfger> could not dput again. "already uploaded" and "doing nothing"
<Kmos> wolfger: try dput -f
<persia> Kmos: It won't work yet.  The keyring sync has not completed
<Kmos> ah ok =)
 * wolfger waits
<pochu> g'night
<persia> wolfger: Done.  Please try again.
<ScottK2> persia: RFC 821/822 are still technically the "Standard" for email.  Updates for RFC 2821/2822 to advance them to be the standard are close.  RFC 2821bis just finished IETF last call and RFC 2822update is expected soon.
<StevenK> ... why wouldn't they give it a new RFC number?
 * persia grumbles about the use of the Obsoletes: header when the appropriate STD (11) has not been adjusted, and stands corrected.
<ScottK2> StevenK: RFC editor will do that before they get published.  Those are "working titles"
<StevenK> Ah, right.
<wolfger> persia, Kmos, somerville32: thanks. dput has finished again.
<persia> wolfger: Should get posted around 01:20 UTC then.
<wolfger> persia: where will I see it/how will I know?
<persia> wolfger: It should show in the index of packages needing review from http://revu.ubuntuwire.com/
<somerville32> persia, How often does http://qa.ubuntuwire.com/uehs/no_watch.php get regenerated?
<persia> somerville32: No idea, and the person who administers it is on holiday.
<somerville32> I don't see memaker
<wolfger> No REVU account for wolfger@gmail.com exists yet.
<persia> wolfger: You need to upload source.changes, not i386.changes.
<persia> Who has libopengl-ruby?  How about vamp-plugin-sdk?
<wolfger> persia: where would I find that?
<crimsun> RAOF: thanks for duping debian 436201 :)
<ubotu> Debian bug 436201 in libasound2-plugins "libasound2-plugins: Could we get an ia32 package for amd64?" [Wishlist,Open] http://bugs.debian.org/436201
<persia> wolfger: If you build a source package (-S -sa), it should appear in the parent directory of the package directory.
<persia> !revu | wolfger
<ubotu> wolfger: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<RAOF> crimsun: Ok, ok :).  I'll attach a bug watch.  Maybe I'll even find time for a debdiff.
 * Hobbsee waves
 * ion_ emits a reverse-phase replica wave.
<ion_> thus attenuating Hobbseeâs wave.
<bddebian> heh
<bddebian> Heya Hobbsee, persia, ion_
<Hobbsee> :)
<persia> Hi bddebian
<ion_> Freenode.find_by_chan('#ubuntu-motu').each {|nick| nick.send 'Hello' }
 * RAOF is influenced by the interacting wavefronts to wave himself
<bddebian> Heh, hello RAOF
<cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
<ion_> Iâd appreciate getting a second advocation for http://revu.tauware.de/details.py?package=hardware-connected
 * persia wonders if packaging malbolge is doing a disservice to users, given that it is especially constructed to be difficult.  It may even not be in line with the malbolge philosophy to be able to `aptitude install malbolge`
<somerville32> What is the CDBS option to specify the manpage?
<somerville32> It isn't in the CDBS docs
<cyberix> :-D
<ion_> persia: Well, thereâs a precedent: PHP.
<bddebian> somerville32: Just add a <package>.manpages file
<persia> ubotu: !cdbs is <REPLY> CDBS is a tool to share common debian/rules fragments by including them in the makefile.  Some documentation, including debhelper hint variables and custom rules is available from http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
<somerville32> bddebian, thats too easy :P
<cyberix> persia: Compiling and running malbolge is so much easier than coding with it. So compiling and installing it is actually rather fun compared to coding. I'm taking away the part which is not that hard. Thus the user will feel even weaker.
<persia> cyberix: You might consider that a bug, and try redoing the upstream build process in malbolge itself, with a bootstrap based on m4 macros.
<ion_> :-D
<persia> cyberix: Anyway, aside from the philosophical issues, there are only a couple of packaging issues; commented.
<ion_> m4 â¥
 * RAOF backs away from the crazy man
<cyberix> persia: dh_makeshlibs doesn't do the trick?
<StevenK> Oh yes.
<StevenK> ion_: We have a lovely padded room and a comfy jacket for you to wear.
<persia> cyberix: dh_makeshlibs creates a shlibs file for packages that depend upon the package being built, rather than setting the dependencies directly.  The manual is a good place to start.
<ion_> In one of my more evil systems, thereâs a m4 script that is converted to XML by m4, and the XML is converted to a Makefile by XSLT, and the Makefile handles the actual build process (which consists of a pipeline of filtering stuff with XSLT). ;-)
<persia> ion_: Consider adding a port from Makefile to malbolge, and get malbolge entirely self-hosting, and submit upstream.  Four passes sounds like too few, but more might make the dependencies awkward.
<ion_> http://gitweb.heh.fi/?p=ion/heroes-scrape.git;a=blob;f=pipeline.m4;hb=HEAD is the file converted to a Makefile (and also a graph, http://heh.fi/heroes/heroes-scrape/pipeline.html) :-)
<cyberix> persia: The copyright years are missing as some of them are quite hard to find. I could add some of them. How ever they do not have any legal meaning. They are just hints for people who want to contact the copyright holder. And in this case there aren't really any copyright holders as the stuff has been placed into the public domain.
<cyberix> I'm not sure I fully understand what you think I should do.
<cyberix> My new copyright file has lots of information.
<cyberix> Sure you were reading the correct one?
<persia> cyberix: http://revu.tauware.de/revu1-incoming/malbolge-0801081640/malbolge-0.1.1/debian/copyright
<cyberix> Yes. That onw.
<cyberix> one
<persia> First, I'm presuming you're not following the new RFC822 format, as it doesn't match that.
<persia> So, if you're following the current format, http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html is the appropriate guideline.
<persia> Looking at your copyright as compared to the good example: it doesn't have "This package was...", "It was downloaded from: ...", and the structure differs significantly.  The remainder of the content indicates good reasearch, and would be correct.
<persia> s/a//
<cyberix> I should avoid listing email addresses of upstream authors?
<cyberix> upstream authors should be ordered by age?
<cyberix> Reverse-engineering examples doesn't often work as you'd expect.
<cyberix> Gotta get some sleep now.
<persia> cyberix: Both the Authors: and Copyright: sections are fine.  it's the rest I'm complaining about.
<persia> jonnymind: Good call on the ubuntu-motu email.  While I'm not sure you'll have more luck there, it is the appropriate place to raise the dispute.
<persia> Who wants a review?
<snoutmate> i do :) http://revu.tauware.de/details.py?package=libopengl-ruby
<bddebian> go persia, go persia :-)
<persia> snoutmate: The very name of your package makes me shiver.  Is that really worthwhile prior to ruby 1.9?
<persia> bddebian: Feel like looking at hardware-connected, mscore, or livemix?
<snoutmate> snoutmate: any reason why not ?
<snoutmate> err
<snoutmate> persia: any reason why not ?
<bddebian> persia: Look at, as in review?
<persia> snoutmate: relative speed of interpreter and GL calls, but maybe it's just me (and this won't influence my review).
<persia> bddebian: Yep :)
<persia> bddebian: I failed to find any reason to reject any of them, and need some help.
<bddebian> persia: They were rejected?
<persia> bddebian: Not yet.  Perhaps you can find a reason.
<bddebian> Oh, you want them rejected? ;-P
<persia> bddebian: Unless you can't find anything, yes :)
<ToyKeeper> Off topic...  If I package my own program, is it better to put debian/* into orig.tar.gz or into diff.gz?
<bddebian> The debian/ dir should never be in orig.tar.gz
<persia> ToyKeeper: diff.gz
<snoutmate> persia: well it builds both against 1.8 and 1.9 if that's what you mean. I don't see the relevance of speed (yeah with 1.9 it's about 3x faster then with 1.8 and actually outperforms perl-opengl), as it is simple an update ..
<persia> snoutmate: We already have libopengl-ruby in the repos.  Please submit an interdiff to the sponsors queue.
<persia> snoutmate: Also, you want "(LP: #182449)" to close the upgrde bug, rather than "- closes: #182449".
<snoutmate> persia: yeah, but as this is large update (new project team, new build system, different installed files) i thought uploading to revu was appropriate (sorry i'm new to ubuntu packaging)
<ToyKeeper> Okay, good.  I guess I'm doing it right so far.  :)
<persia> snoutmate: No problem.  Based on the small debian/, I'm guessing the diff.gz is fairly small, and the main updates are upstream.  Best to push to the sponsor queue so you're not waiting for Mondays, and to make sure the right people see it.
<snoutmate> persia: ah, ok
<persia> Who else wants a review?
<snoutmate> thanks
<ion_> Could you please define pushing to the sponsor queue? Does that mean subscribing universe-sponsors (or whatever it was) to a new bug report with the interdiff attached?
<persia> ion_: Yes.  See https://wiki.ubuntu.com/MOTU/Contributing, https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue, and https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff for more information.
<ion_> Thanks for the pointers.
<ToyKeeper> Is bazaar still recommended for ubuntu packaging?  I'm more familiar with hg, svn, and git, but could switch to be consistent.
<ion_> I quite like git because itâs insanely faster than bzr and you can have the upstream stuff *and* the packaging in different branches under the same repository.
<imbrandon> it dosent NEED to be in a svn
<imbrandon> err RCS
<ion_> That, too.
<lifeless> ion_: you can do the latter in bzr too
<persia> ToyKeeper: Last I checked, there were over 10,000 packages in the archive.  While many people recommend bzr, there are also packages using cvs, svn, hg, git, etc.  The vast majority don't use any VCS at all.
<StevenK> lifeless: In other news, I hit level 61 in WoW. :-)
<ion_> lifeless: Yes, but bzr switch is more hassle than what git does.
<lifeless> StevenK: grats
<persia> imbrandon: VCS.  rcs is a cvs precursor
<imbrandon> StevenK: in oter news i hit lvl 14 :)
<StevenK> lifeless: Thanks :-)
<StevenK> imbrandon: You're playing?
<imbrandon> StevenK: yea
<lifeless> StevenK: I've hit 70, and 1/3 attuned for kara
<StevenK> imbrandon: Which realm?
 * StevenK is trying to sort out his Dreadsteed
<imbrandon> Eldre'Thalas
<ToyKeeper> I've been playing a bit with mercurial patch queues...  seems good for packaging.  But I got the impression that new packages use bazaar when possible.
<somerville32> WoW runs in Ubuntu?
<StevenK> somerville32: Runs very nicely on my amd64
<imbrandon> and i386 :)
<StevenK> imbrandon: I've got a level 61 warlock on Dath'Remar
<somerville32> Would it run on 1.6Ghz w/ 512mb of ram and a gForce 6 series?
<RAOF> Mine too.  Although either something was screwy last night or there've been some recent wine regressions.
<bddebian> persia: Well there isn't much too hardware-connected :-)
<StevenK> I'm using the wine package from Gutsy directly.
<imbrandon> StevenK: ME --> http://www.wowarmory.com/character-sheet.xml?r=Eldre%27Thalas&n=Cabaal
<imbrandon> me also
<imbrandon> ( wine from gutsy )
<StevenK> somerville32: I would suggest more RAM.
<persia> ion_: Quick: defend your package against bddebian's accusation of uselessness
<StevenK> Bwahaha
<bddebian> heh
<imbrandon> StevenK: it hasent updated yet, i'm 14 now
<bddebian> 14?? WTF?
<somerville32> Are there any free, MMORPGs that you guys play that I could play too? :P
<imbrandon> bddebian: i just started playing friday :)
<ajmitch> sigh, more WoW discussion :)
<ion_> persia: Did someone claim itâs supposed to be useful? ;-)
<bddebian> Oh, level 14
<bddebian> ajmitch: !!!!
<imbrandon> ajmitch: !
<ajmitch> bddebian: what?
<somerville32> lol
 * persia thought adding packages known to be useless to the archive was not preferred.
<bddebian> ajmitch: Haven't "seen" you in a while
<bddebian> persia: Not preferred by me
<persia> ajmitch: Welcome back
<ajmitch> bddebian: that's because I haven't been around for awhile
<ajmitch> persia: I'm not back
<bddebian> ajmitch: I know :-)
<ajmitch> I have no internet connection at home still
<imbrandon> nasty
<ion_> Anyway, when you have a list of modaliases for some hardware (say, /usr/share/linux-restricted-modules/$(uname -r)/modules.alias.override/nvidia) and you want to check whether any supported hardware exists in the system, hardware-connected is useful.
<persia> Urk
<ajmitch> still waiting for phone & DSL to be connected
<imbrandon> StevenK: i play on that server because some people at work do too
<imbrandon> ( namely most of the DawnBringers Guild )
<ajmitch> imbrandon: http://www.wowarmory.com/character-sheet.xml?r=Khaz%27goroth&n=Iosephus <-- me
 * imbrandon looks
<imbrandon> ajmitch: wow
<somerville32> Crusader of the Flame, eh?
<bddebian> Lamers
 * StevenK digs his up
 * somerville32 doesn't have one :(
<ajmitch> imbrandon: that's nothing special
<StevenK> http://www.wowarmory.com/character-sheet.xml?r=Dath%27Remar&n=Kelleigh
<imbrandon> ajmitch: better than my 3 day old lvl 14 :)
<ion_> I havenât retrieved the Amulet of Yendor and ascended yet.
<ajmitch> imbrandon: 3 days? you must be addicted already :P
<StevenK> Haha
<imbrandon> ascended ? heh , sounds like SG-1
<StevenK> imbrandon: That's a nethack reference
<imbrandon> ahh
<StevenK> ajmitch: Have you dug around Un'Goro Crater?
<StevenK> (Crappy zone that it is)
<ajmitch> StevenK: of course
<StevenK> ajmitch: One of my friends was killing gorillas there and one of the loot items was an Empty Barrel
<ajmitch> there's plenty of interesting loot that drops
 * ajmitch wonders if people will put their names forward for the MC
<StevenK> I just love it due to the Donkey Kong reference.
<ion_> Since i have a screen full of offtopicness already, perhaps pasting this to the channel doesnât hurt. :-P http://johan.kiviniemi.name/blag/2008/01/10/svn-diff-git-diff-speed/
<StevenK> imbrandon: You need to learn some professions.
<lifeless> http://www.wowarmory.com/character-sheet.xml?r=Jubei'Thos&n=Canid
<imbrandon> StevenK: yea i havent left the starting area yet
<imbrandon> StevenK: i probably will later tonight
<ajmitch> lifeless: good luck on those last 10 points in tailoring, they'll be expensive :)
<StevenK> Haha
<imbrandon> jez, does eveyone play WoW :) heh
 * bddebian doesn't
<ajmitch> imbrandon: yes
<StevenK> I need to level my tailoring up
<lifeless> ajmitch: I have the next 5 lined up already
<imbrandon> bddebian: buy the crack
<StevenK> I have 221 pieces of Runecloth that I can't turn into bolts.
<lifeless> ion_: yes, but svn is slow.
<imbrandon> heh, they FINALY talked me into it at work
<bddebian> imbrandon: I'll stick to my single-player NWN thanks :)
<StevenK> A mage that skins. Interesting
<ajmitch> StevenK: more monies
<lifeless> StevenK: money while levelling, and mats for higher level tailor items
 * ajmitch had mining & skinning until not long ago
 * imbrandon isnt sure what profession to takeup
<lifeless> imbrandon: what class are you ?
 * somerville32 nominates persia for MC
<imbrandon> hunter
<imbrandon> lifeless: lvl 14 atm
<lifeless> skinning for sure
<StevenK> Except the Armory says level 12
<lifeless> armory updates fail sometimes ;)
<imbrandon> StevenK: it hasent updated today yet, i leveld 2 times earlier
<StevenK> Mmmm
 * persia tasks each of imbrandon, StevenK, and lifeless with one review for filling backscroll with WoW
<ion_> :-)
<imbrandon> heh
<StevenK> I wish my Armory page would update - I'm the Lords of War now, not The Dark Tabards
<StevenK> s/the/in/
<lifeless> imbrandon: also I'd probably suggest leather (makes mail uniques at high levels) or blacksmithing (also can make mail), or engineering (guns and shit)
<imbrandon> yea i thought about mining and engneering
<lifeless> but definately skinning cause you are going to be killing SO MANY BEASTS as you level
<imbrandon> yea most of the time i just let them lay
<imbrandon> heh
 * StevenK is pondering starting a Rogue after Kelleigh hits level 70
<imbrandon> i dont even loot anymore atm
<lifeless> also, three hints
<guest22> Anyone willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable.
<lifeless> 6 skill levels per character level
<imbrandon> StevenK: if you roll a new char we should start a Ubuntu People Guild
<lifeless> loot everything
<imbrandon> heh
<lifeless> buy the biggest bags you can, and upgrade every chance you get
<ajmitch> StevenK: I've started a mage, anyway
 * StevenK has a level 24 mage
 * ajmitch needs to get into the 25-man raiding a bit more though
<somerville32> Is there any free MMORPGs that are like WoW? :P
<somerville32> It sounds like fun
<StevenK> lifeless: By that count, you'd hit skill level 375 during 62->63
<somerville32> And I was just wondering. How many of you guys complain about using restricted drivers but rely on them to pay WoW? :P
<Pici> WoW is too addicting.
<somerville32> *play
<StevenK> I don't complain about them. :-)
<jml> heh heh
<imbrandon> i dont complain about them
<ajmitch> neither do I, though I'd really like some free drivers :)
<ajmitch> hello jml
<jml> ajmitch: hi
<imbrandon> flash == much more evil than drivers
<LaserJock> jdong: ping
<imbrandon> persia: i would but it takes a certain mindset for me to review, and $time-of-day isnt now
<imbrandon> heh
 * RAOF occasionally bitches about restricted drivers, and does something about it by building nouveau drivers.
<ajmitch> RAOF: I imagine that WoW wouldn't overly tax nouveau drivers once the various pieces are in place
<RAOF> ajmitch: Such as any form of textured 3d.
<somerville32> We should get a #ubuntu-gaming or #ubuntu-game channel going :P
<lifeless> StevenK: 375/60
<imbrandon> -wow :)
<imbrandon> join #ubuntu-wow
<StevenK> lifeless: That's 6.25, though
<lifeless> StevenK: yes, a little down is tolerable; its about matching the mats you gather to your skill
<ion_> persia, bddebian: I posted a use case to http://revu.tauware.de/details.py?package=hardware-connected
<StevenK> lifeless: Mmmm.
<StevenK> lifeless: I need more Mageweave. About 50 bolts, by my count. :-(
<StevenK> I suspect I will be running ZF again for it.
<lifeless> StevenK: right; and you are not gathering it any more, because you let your skill get too far behind your level
<StevenK> lifeless: No, because I ran out of Mageweave.
<persia> ion_: Do you need this for the updated nvidia drivers you're working on?
<lifeless> StevenK: yes, I know you did:) if you'd been trying to keep things synced you could have run areas you'd still get yellow xp for ;)
<ion_> persia: Iâm not currently working on nvidia drivers, but iâve considered implementing exactly that change in linux-restricted-modules.
<StevenK> Ah
<ion_> persia: That was my inspiration for writing hardware-connected in the first place, since i implemented that as a sh function and noticed it was unbearably slow.
<persia> ion_: Well, it's been advocated all it needs for universe, but that would require migration to main.  I suspect you could get one of your l-r-m sponsors to upload if there's a good chance that an MIR would be approved.
<ion_> Iâm not sure how soon the nvidia-glx thing could be implemented, and others might find hardware-connected useful for other things, so i was thinking it should go to universe for now.
<persia> ion_: If you're just striving for universe, advertise for an uploader.
<ion_> Will do.
 * persia wonders about the difference between "speed" and "speed-game"
 * persia archives "speed"
<saivann> Hi everyone, I created the ubuntu package from the actual debian package for gnucash 2.2.3 and I wish to upload it to repositories, so I would need a MOTU to review my work and accept it for Hardy.
<saivann> This package includes the upstream fix for a high priority bug with scheduled transaction, use the recently changed libgif ( bug #174252 ) in build-depends and fix bug #179104
<ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252
<ubotu> Launchpad bug 179104 in gnucash "[hardy] Please sync 2.2.2 from debian" [Wishlist,New] https://launchpad.net/bugs/179104
<saivann> also bug #155059
<ubotu> Launchpad bug 155059 in grisbi "Description does not contain the word money" [Wishlist,New] https://launchpad.net/bugs/155059
<saivann> the new gnucash source package is here
<saivann> http://upload.leservicetechnique.com/bugs/gnucash_2.2.3.tar.gz
<persia> saivann: This is a merge from debian?
<saivann> persia : right
<persia> saivann: Is there a merge bug?
<rick_h_> anyone got a sec to help me with an error building something with pbuilder?
<rick_h_> I'm getting the error here with intltool: http://ubuntuforums.org/showthread.php?t=525284
<rick_h_> but since I'm using pbuilder I can't just make a ln -s for getting around the intltool searching only current dir
<saivann> persia : Actual debian unstable package + ubuntu bug fix that I mentionned and a fix for the missing icon for ubuntu which is already applied to the current ubuntu gnucash version
<saivann> persia : A merge bug?
<persia> rick_h_: What environment are you running in?  Dapper has intltool 0.35.0-0ubuntu1.  Is there maybe a missing build-dependency?
<persia> !merging | saivann
<ubotu> saivann: Merging is the process of including changes from other distributions (most commonly Debian) into Ubuntu packages, and is typically a major focus at the beginning of each Ubuntu development cycle.  Please see https://wiki.ubuntu.com/UbuntuDevelopment/Merging for more information.
<rick_h_> persia: I'm in gutsy with a gutsy pbuilder install
<saivann> persia : https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/179104
<ubotu> Launchpad bug 179104 in gnucash "[hardy] Please sync 2.2.2 from debian" [Wishlist,New]
<rick_h_> intltool is in the control as a build requirement and when pbuilder runs it shows it getting intltool
<rick_h_> so it seems that it just isn't looking in the right spot
<persia> saivann: Since you need to add an additional patch, retitle the bug as a merge, attach your debdiff against Debian, and subscribe ubuntu-universe-sponsors
<rick_h_> persia: paste of pbuilder here: http://paste.avwsystems.com/paste/79
<saivann> persia : Sorry I didn't know that procedure, do you want me to provide needed debdiffs between the debian version and my actual ubuntu version?
<saivann> persia : Ok I'll do it in the next minutes, thanks
<persia> saivann: Yes.  Please provide a debdiff with all proposed Ubuntu variation from debian, and subscribe the sponsors.  Someone will review, and either upload or reject with an explanantion.
<saivann> persia : Thanks
<bddebian> persia: What's speed-game like?
<persia> bddebian: Haven't tried it.  channel traffic included a couple good reviews (nice game, fun).
<bddebian> Hmm
<persia> rick_h_: Looks to me like there might be a missing file for the intltool check in the upstream tarball.
<bddebian> Not that I can get jack shit done on the Games Team anyway
<rick_h_> ok, maybe I'll see about trying a bug report in intltool and see what happens then
<LaserJock> bddebian: I thought you just played WoW
<bddebian> I never play WoW :-)
<persia> rick_h_: I'm not convinced it is a problem with intltool.  The error message says "awk: cannot open ./intltool-update.in (No such file or directory)", so I'm guessing that either the script calling awk is being given the wrong path, or that the tarball is missing a file.
<persia> s/being given/giving/
<bddebian> Damn, sdlmame is still not in Ubuntu?
<ScottK> LaserJock: Thanks for the Golden Pony
<ToyKeeper> Heh, xmame is usually lagging...  and I doubt there's as much demand for sdlmame.
<rick_h_> persia: yea, it might be something with the autotools stuff this app is using
<rick_h_> So I'm going to start with the original app mailing list and see what anyone else says
<persia> bddebian: it's really close...
<LaserJock> ScottK: np
<ScottK> If I knew all it took was being grumpy and argumentative ....
<ajmitch> if all it took was being grumpy, I'd have received a truckload of them
<ScottK> ajmitch: Must have needed more argumentative then.
<ajmitch> probably
<LaserJock> ScottK: well, even though I don't always agree, I do appreciate somebody taking a firm philosophical stand. Helps keep us honest ;-)
<ajmitch> I prefer to leave the arguing to others, helps with my stress
 * persia thinks if more people agreed with ScottK, we'd have a poor forum for discussion
<ScottK> LaserJock: Thanks.  It takes extremists on both sides to keep to a happy middle.
 * ScottK disagrees with persia.
<ScottK> Wanna argue? ;-)
<bddebian> hehe
<persia> ScottK: No value.  Your offer demonstrates the value of contrarianism :p
 * ScottK disagrees.
<ScottK> It demonstrates the value of humor.
<LaserJock> well, I'm afraid this was most likely the last of the Golden Ponies, at least from me
<ajmitch> why the last?
<persia> LaserJock: Why?
<LaserJock> a few reasons
<LaserJock> I'll be graduating/looking for a job/moving when Hardy is finished
<LaserJock> I'm really not very creative
<persia> LaserJock: You just need to add more judges to the Aurean Equine Academy
<LaserJock> that would work
<LaserJock> I would love nominations or something
<LaserJock> but I just don't want people to get upset if they don't get one
<LaserJock> and I don't know as many people as I used to :/
 * ajmitch isn't completely upset for missing out
<ajmitch> I know that it's not because you hate me (or at least I hope it's not) :)
<LaserJock> heh
<persia> So, pick two or four more judges (odd numbers are good), get their acceptance, and put out a call for nominations around Beta Freeze.  That ought produce something useful for just after release :)
<ScottK> LaserJock: Congratulations on the graduating bit.
<LaserJock> ScottK: heh, well it hasn't happened yet
<LaserJock> but it's supposed to
 * ajmitch wonders if he could collect some 'MOTU emeritus' title
<LaserJock> ohhhh, nice
<ScottK> We can call \sh_away motu-reloaded.
<LaserJock> haha
<persia> ajmitch: That's not a bad idea.  How would you imagine "MOTU emeritus" status to be granted?
<LaserJock> retirement in good-standing?
<bddebian> hehe
<ajmitch> LaserJock: I'm not exactly in good standing though
<LaserJock> well, you aren't in bad standing :p
<ajmitch> dunno about that
<LaserJock> maybe you're just lucky to be standing ...
<ajmitch> I haven't been lynched yet
 * bddebian gets the ropes
 * persia files some removal bugs
<ajmitch> see
<persia> ajmitch: Actually, should all of gnue-* go, or just the ones that will break when bddebian finishes excising wx2.4?
<bddebian> persia: Already being done it appears
 * persia checks bugs again
<bddebian> I mean excising wx2.4
 * ajmitch shrugs, probably all
<persia> ajmitch: Thanks.
<LaserJock> hmm, this looks nifty/useful: http://www.chris-lamb.co.uk/2008/01/14/gnome-applet-for-monitoring-debian-bugs/
<Burgundavia> LaserJock: be nice if it was a deskbar plugin
<LaserJock> pffft, deskbar ... ;-)
<LaserJock> do people actually use deskbar?
<persia> LaserJock: Some do.  Quicksilver addicts mostly
<LaserJock> bah
<LaserJock> I'm a quicksilver addict and it's the reason I dislike deskbar
<LaserJock> if you're gonna clone the best at least do it right ;p
<persia> bddebian: I see all the same problems re: WX2.4 as I did for hardy release, and Debian still hasn't fixed trustedsql either.
<persia> s/hardy/gutsy/
<bddebian> persia: I have to upload jugglemaster yet and post the newpki-client patch on BTS (I've already sent it to the maintainer).  They aren't going to wait for ctsim
<persia> Did anyone ever fix survex, or do I need to stop being lazy about that?
<persia> guest22: photoml commented.  Needs more licensing clarity.  Especially needs preambles in the source files.
 * persia seeks nominations for a candidate upload to review
<guest22> persia: Thanks for the comments. Do I understand correctly that your concerns are with the upstream source rather than the packaging itself?
<persia> guest22: Entirely.  The packaging is clean.  I'm just not sure the upstream source is licensed in a way that the archive admins wouldn't reject.
<guest22> Would you mind expanding on those problems? The license is very clearly spelled out in the README file. Is it really necessary that it also be mentioned in every other file in the distribution?
<persia> guest22: Not the entire license, just the header.  See /usr/share/common-licenses/GPL-2 under the "How to Apply These Terms to Your New Programs" section, where it mentions the notice to attach to the start of each source file.
<ScottK> persia: If there's a full copy of the license in the upstream tarball, it's been my experience that they won't reject for lack of license headers in files (although upstream should definitely be asked to add them).
<persia> I'm not sure the GPL actually requires this, but I've seen packages rejected by the archive admins for not having those four paragraphs in the source files.
<persia> ScottK: I've seen both behaviours.
<ScottK> It may depend on which archive admin is doing the reviewing.
<ScottK> Not having the full text of the license is a guaranteed reject
<persia> photoml doesn't suffer from that: only the missing source headers on some files.
<persia> (and no copyright assertion for the manpages)
<ScottK> If he made the man pages, then that can be fixed
<guest22> ScottK: Fixed how? By a new upstream source release, or via some packaging mechanism?
<persia> ScottK: upstream manpages, and yes.  Looks like about 3-4 hours work to me to fix everything, and about 30 minutes for the manpages alone (considering the overhead of a new upstream release with release notes, etc.)
<ToyKeeper> Hmm, in python, is it preferable to put the license info in a docstring or a comment?
<persia> guest22: All the issues are with upstream: best fixed by a new upstream.
<ScottK> ToyKeeper: Comment is fine
<guest22> persia: Could we try to agree now on which files need the copyright, to avoid another iteration later?
<ScottK> guest22: Best way is a new upstream release.  If you can't get that, you can patch the man pages
<guest22> ScottK: A new upstream release is fine, but I'd like to make sure I catch all of the remaining problems in that release.
<ToyKeeper> ScottK: Oh, good.  I was hoping I wouldn't need to change it.  :)
<persia> guest22: I generally run `less $(suspicious-source)` from the package directory to select which files to inspect.  I don't know what the archive admins use.  The general rule is that anything not trivial should be licensed.
<guest22> persia: What is and isn't trivial is a rather subjective judgement.
<persia> Or rather, anything that falls under copyright should be licensed.  This avoids confusion about the meaning of "trivial"
<guest22> persia: Surely everything in the package falls under the blanket copyright asserted in the README?
<persia> (and yes, it's still subjective until argued, but nobody here is giving you legal advice)
<persia> guest22: Maybe.  I've seen too many rejections for that to feel comfortable advocating or uploading when there are lots of missing headers.  You might get other reviewers to advocate and upload the current candidate: as I said, the packaging is fine.
<guest22> persia: If there's a potential problem, I'm quite prepared to fix it. (Although hopefully doing another upload won't push photoml so far down the queue as to not have any chance of making it into hardy.)
<persia> guest22: From the current location, a new upload will move it up in queue.  On the other hand, being active about advertising your package (as you've been doing) helps a lot towards getting it in.
<guest22> persia: It seems to be that I need to add copyright statements to all scripts, man pages, docs, dtd, and xslt. Do you think that covers it?
<guest22> For example, some of the makefiles are non-trivial, but surely they don't also need a copyright header?
<persia> guest22: Only the stuff you want to copyright.  You may wish to specifically release the DTD or some of the examples into the public domain for reuse for any purpose.  If all the perl scripts had it, and most of the stuff with the specific copyright notice, it wouldn't have been sufficient volume to cause a reject from me, only a warning note.
<guest22> persia: Any constraints on the form of the header? Will something like "This file made available under the terms of version 2 of the GPL" do?
<persia> guest22: The GPL itself contains information on the recommended header, in the "How to Apply These Terms to Your New Programs" section.
 * persia notes that the GPL should be read carefully and in full by anyone considering the GPL as a license for their software.
<ToyKeeper> 4 paragraphs seems a bit much sometimes, but it's fairly clear on the issue.
<guest22> persia: The full verbiage recommended in the GPL is quite verbose for some of the simpler source files. My question is not what is recommended, but what is the minimum length statement that would be considered acceptable to clearly indicate the licensing? (I presume there is a difference.)
<persia> guest22: I'm not someone who makes the determination as to what is acceptable for inclusion in the archive.  From my reading of the GPL, it is a choice between those four paragraphs and nothing, with the GPL indicating that "It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty, and each file should have at least the "copyright" line and a pointer to where the full notice is found.".
<guest22> persia: But as you point out, the GPL states "each file should have at least the "copyright" line and a pointer to where the full notice is found.". This seems to imply that including only the copyright line and an explicit pointer to the copyright file in the distribution is sufficient.
<guest22> Would you have problems with that approach?
<persia> guest22: It may be.  If you disagree with me, feel free to push another candidate to REVU addressing the manpage bit, and leave a comment with your opinion.  You may find others who agree with you, and the archive admins may accept it.  I don't see any issues with your reasoning, but have seen similar packages be rejected for missing the header in one source file.
<persia> guest22: As ScottK said, it depends on the specific archive admin doing the review.  Some will  ignore that, and just let it in.
<guest22> persia: You clearly have more experience in licensing issues than I do, which is why I want to make sure I understand your advice. Since the GPL itself explictly allows for the copyright-and-license-pointer approach, do you still feel this is potentially problematic? (Your response seems to suggest yes, but I'd like to understand why.)
<ToyKeeper> guest22: If at all possible, get the full notice into each source file.  Then there are no potential issues.
<persia> guest22: I don't know why it would be problematic.  I've just seen it be cause for rejection from the NEW queue, and so use that as a guideline when reviewing the packaging.
<guest22> ToyKeeper: No potential issues, but as you mentioned above, the full 4 paragraphs are a bit much for some source code.
<persia> guest22: My philosophy is that if I reject for every reason I can imagine, the package will be perfect when it reaches the archive admins.  This is not necessarily the best philosophy, and my comments may be too strict.
<guest22> persia: You've seen packages rejected because the source had a copyright statement and pointer to the license, but not the full 4 paragraphs?
<persia> guest22: I believe so, yes.  I may be wrong.  I have also seen packages accepted that didn't meet the licensing guidelines I follow, so I may be too strict.
 * persia complains about the lack of orig.tar.gz for alliance, and encourages speedy reupload
 * ToyKeeper wonders why an extra 600 bytes per source file would be worth increasing the risk of legal confusion
<guest22> persia: Questions about the other issues you raised. I assume 1. (patching) is just a suggestion, and not an impediment to advocation. As for 2., what is the file definition file to which you refer? In 3., do trivial example XML files really need a GPL header?
<guest22> ToyKeeper: I don't think a clear statement of copyright and pointer to the full license does leave any legal confusion, and prefer to look as little like a lawyer as possible.
<guest22> But yes, if that's really required, one might as well suck it up.
<persia> guest22: 1) Yes, just a suggestion.  2) I meant "film" not "file" :)  ./xml/definitions.mod, and this was just the first I encountered.  3) I don't think that trivial example files need copyright assertion, let alone licensing.  I encourage you to treat these as public domain, for reuse by users for any purpose.
<guest22> persia: And what do I need to do to treat those as public domain?
<persia> Depends on how explicit you want to be.  A common method is to not assert copyright, describe them as public domain and free for any use in README, and list this in debian/copyright.
<persia> If you want to be extra explicit, you can include something like that on the top of the dh-make debhelper example file, but I think that's overkill.
<persia> For some programs, the examples just fail to assert copyright, and the author doesn't plan on suing anyone (but doesn't indicate that).  The risk here is that the author's heirs may not be so considerate.
<guest22> persia: Can one make a statement such as "all files not including copyright information are in the public domain" in README, or do these need to be explicitly listed. Is there a required format to the corresponding statement in debian/copyright?
<guest22> (This is starting to be more painful than debugging XSLT.)
<persia> guest22: I'd probably put everything in an examples/ folder, and just add a note saying that the examples in the examples folder are public domain.  The examples folder would be installed with dh_installexamples.  In debian/copyright, you would add a section that the files under the examples directory are public domain.
<persia> Note that "public domain" doesn't mean anything in some jurisdictions, so be sure to also indicate that they are free for any use.
<guest22> persia: OK, thanks again for the advice. I'll attempt to implement your suggestions and re-upload. I hope you won't mind taking a look again once I've done that.
<persia> guest22: I generally try to avoid reviewing the same package twice, as I believe the best packages are created when lots of different viewpoints are included.  If I've still time when I've finished reviewing all the packages for which I'm not the last reviewer, I'll take a look.
<persia> s/twice/twice-in-a-row/
<guest22> persia: Understood.
<jdong>  /lastlog jdong
<jdong> grr
<jdong> and contentless ping loses over sleep :)
<dholbach> good morning
<superm1_> jdong, i had pung if you are around still before sleep
<superm1_> jdong, it was regarding faac
<superm1_> since you had touched it last
<superm1_> mornin dholbach
<dholbach> hey superm1_
<superm1_> how's your new year treating you thus far?
<dholbach> very good - very busy too, but I'm happy
<dholbach> how 'bout you?
<superm1_> well i've been on vacation the last week, and just got back this weekend
<superm1_> finally very relaxing :)
<superm1_> i was quite scared to see my inbox when i returned
<dholbach> and how's it looking?
<superm1_> well it was pretty bad, but its fine now
<dholbach> vacation sounds great - I have some (long) weekend trips planned in the next months and I look forward to that :)
 * dholbach hugs superm1_
<superm1_> additionally i'm moving Tuesday, but don't start work until early February, so i'll have more free time until then which i look forward too as well
 * superm1_ hugs dholbach back
<dholbach> I wish you all the best with that!
<superm1_> thanks :)
<ScottK> Good night all.
<dholbach> night ScottK
<dholbach> hey slomo
<superm1_> hey slomo
<Tonio_> hi everyone
 * persia seeks an alternate reviewer for libserial, qdevelop, and qtsmbstatus.  None of these packages have had a review in 2008, and would be happy to get one.
<desrt> 2008 has only been 13 days.
<StevenK> 14, here.
<desrt> i've had packages awaiting review when you were still in diapers!
<persia> desrt: Which means that these packages have been waiting two weeks for a review.  With a REVU day every week, that shouldn't happen.
 * persia hunts down DOB references for Mr. Lortie
<StevenK> persia: I suspect qevelop and qtsmbstatus have had no reviewer since people are allergic to QT?
 * desrt /whois persia
<persia> StevenK: Maybe, but I don't like to see things just sitting there this close to FF, and don't want to be the only reviewer for a package I will never use.
<persia> LucidFox: smplayer-themes advocated
<LucidFox> persia> Thanks!
<persia> bobbo: ckkern commented
<persia> rulus: gtkvd commented
<SWAT> does libslab0 contain the "SLAB menu"? From the description, one would think so. Yet nowhere is mentioned, how it can be used/started/integrated.
<rulus> thanks persia!
<persia> rulus: Did you ever get anywhere with gnuvd also?  I know it's older, and may be deprecated, but getting a patch might be good.
<StevenK> SWAT: libslab0 contains the shared libraries for that. The package you want is gnome-main-menu
<rulus> persia: the bug is filed at Debian and forwarded to the author of gnuvd. Gnuvd is written in C, which I hardly understand.
<persia> rulus: Understood.
<rulus> I'll look into the comments later, preparing for an exam now. Thanks again ã
<ion_> tsu
 * persia notes that ã and ã· have specific pronunciations, and are rarely used as smilies in their country of origin
 * rulus knows, but it looks cool
<persia> ãã¡ãã
<ion_> ã¯ããã¡ã¯
<persia> ion_: That's terrible
<persia> s/ble/ble :)/
<SWAT> StevenK, thanks.
<persia> amarillion: speed-game commented
<geser> good morning
<TheMuso> Good morning geser.
<geser> Hi TheMuso
<persia> rzr: jaaa advocated
<rzr> great
<rzr> persia: thx again for all your support
<persia> rzr: There were a few minor notes, if you want to clean them up.  I'm also surprised that $(MAINPACKAGE) didn't work.  You might ask around to see if there is another variable to avoid you setting it manually.
<rzr> yes will to this evening
<rzr> i have to go
<rzr> later
<persia> geser: Thanks for helping with reviews.  It is very nice to see another name in the comments.
<wallyweek> g'morning!
<wallyweek> anyone please review http://revu.tauware.de/details.py?package=sdlmame
<wallyweek> I know I already have some trivial fix to commit, but I'm at work now
<persia> wallyweek: Last review (today) was pretty positive, but until you've applied the fix, I doubt you'll see an advocation.
<persia> James Lee: 1) Please add your IRC nick to your LP page.  2) fuppes commented.
<wallyweek> persia: good, but I would like to know if there's something more to fix to avoid more time waste. Could you have a look at it, please? :)
<persia> wallyweek: You've hit most of what I found already.  I suspect you'll get it in faster if I wait to review until you've had a chance to upload again, as I won't want to review it twice this REVU day.
<wallyweek> persia: ok, I'll fix it at lunch time
<wallyweek> persia: do you think section "games" is good?
<persia> wallyweek: I think sdlmame belongs in section games and sdlmame-tools belongs in section misc.  Some people might argue that both belong in otherosfs.
<wallyweek> persia: I agree with you. Perhaps I could have a look at other emulators and see how they've been managed?
<persia> wallyweek: That sounds like a good plan.  xmame might be a place to start.
<wallyweek> persia: ok, thanks!
 * persia points at http://revu.ubuntuwire.com/revu1-incoming/gnomecatalog-0801132110/gnomecatalog-0.3.3/debian/gnomecatalog.1 as a reference for why automated manpage checkers are not always sufficient.
<Yagisan> thats one short manpage :P
<ion_> Hehe
<wallyweek> persia: looks like newer packages for emulators are in otherosfs (stella, dosbox, vice, spectemu) and older ones (xmame, visualboyadvance) are in games
<persia> josesanch: gnomecatalog commented
<persia> wallyweek: To me that indicates that the previous practice was to separate by section, and the current practice is to use otherosfs, but I'm not really that familiar with emulator packaging.
<ion_> Iâd s/Cd/CD as well.
<ion_> +/
<persia> ion_: If you wanted to provide a manpage patch via email, I'm sure josesanch would appreciate the help.
<wallyweek> persia: that makes sense. I think I should use otherosfs then, xmame and visualboyadvance are no longer maintained upstream afaik
<wallyweek> i bet packagers are didn't look at them for quite a lonk
<wallyweek> time
<wallyweek> whoops! keyboard mess! :)
<persia> norsetto: gimp-normalmap commented
<geser> Hi Fujitsu
<LucidFox> A comment from debian-multimedia.org:
<LucidFox> 'I see two bugs in your package : 1) in the menu files the icon should be the full path with the file extension : icon="/usr/share/pixmaps/qdvdauthor.xpm" instead of icon="qdvdauthor""
<LucidFox> Is this true?
<persia> LucidFox: Maybe.  I was sure I'd seen a number of cases where the icon wasn't absolute, and I know the executable isn't supposed to be absolute, but I can't find evidence either way from the documentation.  You might check the source of one or another backend, or use the absolute path for now.
<persia> I typically use the menu-xdg backend, so bare icon names get passed to the icon cache from the generated .desktop, masking whether this would be a bug for other backends.
<persia> wolfger: memaker commented, overflowing the comment space.
<persia> LucidFox: What was #2?
<LucidFox> dh_desktop call should be immediately after dh_installmenu.
<LucidFox> He fixed both when merging the changes.
<persia> LucidFox: I can't imagine it matters where dh_desktop call is placed, as it only adds a clause to postinst and postrm, but I also don't think moving it hurts anything.
<LucidFox> In any case, DMO has merged all Ubuntu changes except for the source-contains-cvs-control-dir Lintian override, and there is also the libxine1-x issue which is Ubuntu specific. This will be a small debdiff.
<persia> LucidFox: libxine1-x is Ubuntu-specific?  I thought that transition was underway (or intended to be so) in Debian as well.
<LucidFox> Reply from DMO:
<LucidFox> 'Also libxine1 is badly packaged on Debian, the qdvdauthor package
<LucidFox> still debpends on libxine1 instead of like you, on "libxine1-x | libxine1"'
<persia> Ah, so DMO doesn't want to be compatible with either Debian or Ubuntu :)  I understand.
<LucidFox> Heh.
<persia> Are there any other improvements in DMO other than merging the Ubuntu changes?
<LucidFox> New upstream release.
<persia> Ah.  Well then, small debdiff it is :)
<LucidFox> Maybe he doesn't yet know that Debian accepted xine-lib with libxine1-x three days ago.
<persia> Maybe worth pointing that out, and waiting for -2?
<broonie> geser: SCons upstream believes aqsis is going to need a bug fix - the error handling in scons is obviously crap but aqsis only ever worked through luck.
<LucidFox> Well, it will probably take a while before he uploads the new libxine and rebuilds everything depending on it.
<persia> aqsis ever worked?  I remember that package having persistant failures.
<LucidFox> Should I re-add Ubuntu entries to debian/changelog?
<LucidFox> past ones, that is
<persia> LucidFox: If there was never a sync, yes.  Once there was a sync, you only need to restore those since the last sync.
<LucidFox> There was a sync of 0.1.2-0.0 in Feisty, so I'll only add entries since then.
<LucidFox> In Edgy, even... Feisty had the same version
<persia> amarillion: alex4 commented
 * Yagisan cries. he just built llvm 2.1 (because the ubuntu packages too old), and that took hours - and he now needs to download and build a 52MB llvm-gcc source package :'(
<ion_> A new LLVM would be nice indeed.
<Yagisan> ion_, make sure you CFLAGS/CXXFLAGS has no , in it, or it will FTBFS half way
<Yagisan> ion_, I need it for lostsoul here -> http://dengng.bpa.nu:8010/
<StevenK> Yagisan!
<Yagisan> StevenK, !
<StevenK> Yagisan: Long time, no see.
<Yagisan> long time no see
 * StevenK grins
<Yagisan> almost finished uni - got about 8 months left
<Yagisan> been abusing my poor ubuntu boxen here
<Yagisan> how have you been StevenK ?
<StevenK> Yagisan: I've been great!
<DaveMorris> my package is complete and requires a revu - http://revu.tauware.de/details.py?package=libserial
<Yagisan> no more jumping on Hobbsee StevenK ?
<persia> Could someone else look at libserial?  I've been the last two commenters, and think the package would benefit from another viewpoint.
<StevenK> Yagisan: She's not here to jump on.
<StevenK> Yagisan: But, no.
<StevenK> Yagisan: Check out my Launchpad page and see if you can guess my new employer.
<Yagisan> StevenK, hmm - I wonder
 * StevenK grins
<Yagisan> :'( I understand now why no one updates llvm - I hope I understand these gcc build instructions right
<LucidFox> StevenK> Canonical?
<Yagisan> StevenK, you still down Burwood way ?
<StevenK> LucidFox: Yup
<StevenK> Yagisan: Nope. I worked in Burwood, now I work at home.
<Yagisan> StevenK, I'm stuck out in Merrylands
<LucidFox> I'd like one more reviewer for http://revu.ubuntuwire.com/details.py?package=smplayer-themes
<Yagisan> StevenK, I'll take a moment to pimp my ubuntu powered www site -> http://dengng.bpa.nu/wiki
 * Yagisan -> washing bub
 * persia grumbles about REVU day participation, and reviews libserial yet again
<StevenK> Yagisan: Merrylands is fairly closeish to me
<josesanch> Hello
<josesanch> I have a question about a coment about my package
<persia> josesanch: Just ask
<josesanch> The reviewer says Please don't use an absolute path for the executable in the menu file
<josesanch> but i don't know how to to that.
<josesanch> all menu files that i have seen uses absolute path
<Ng> persia: thanks for the reminder about that. I've pushed out 0.7 and uploaded to revu again, but as discussed someone else should review it :)
<persia> josesanch: In your menu file, you reference /usr/bin/something.  Change that to "something".
<josesanch> in the manual i don't see anything
<persia> Ng: You'll want to advertise the URL :)
<josesanch> will work in that way?
<Ng> persia: will do once I see the new upload, thanks :)
<persia> josesanch: As long as the executable is in the default path, yes.  Further the executable should be in the default path, and there should be no name conflicts for executables in the default path.
<josesanch> persia: Ahh.. thanks..
<josesanch> persia: I have another question is the last thing that i have to address "1) python-support might want to be Build-Depends-Indep:"
<persia> josesanch: I'm not the right person to ask about that, as I'm not an expert in python packaging.  Generally, only the packages required to run debian/rules clean belong in Build-Depends: if there are no architecture-specific binary packages built, and python-support in Build-Depends: generated some automated output from one of linda or lintian (probably lintian: linda tends to be less wordy).
<persia> DaveMorris: typo in debian/copyright.  Refresh the upload to fix that, and I'll advocate libserial.
<persia> (if it's fairly quick: I'm stopping reviewing soon)
<Ng> ok here we go... I have a fresh upload of Terminator in REVU that should resolve all previous comments. Reviewers who aren't persia (because he's given me enough of his time already) would be most welcome: http://revu.tauware.de/details.py?upid=1242 :)
<StevenK> Ng: Is that because persia threatened to bill you? :-P
<persia> LucidFox: How much does wxsvg differ from DMO?  Is there a reason to push this through REVU rather than a merge?
<Ng> StevenK: haha, no. fresh eyes and all that :)
<persia> StevenK: I was the last three reviewers, which I try to keep as a limit
<mok0> http://revu.ubuntuwire.com/details.py?package=gpp4 is ready for another round of reviewing as well
<LucidFox> persia> It's not in Ubuntu yet
<LucidFox> I assumed that all new packages went to REVU, unless they were synced/merged from Debian
<persia> LucidFox: Let me ask that differently then.  Firstly, do you plan to maintain this, or just keep merging from DMO?  Secondly, are you pushing to REVU to get a second opinion on your changes, or just because that's how we handle new packages?  Thirdly, do we really need such an ugly version string?
<persia> LucidFox: We can have other sync/merge sources, as long as those sources are well maintained, and someone watches them.  We just only automatically sync from Debian.
<LucidFox> 1. Keep merging, and advocate serious changes to DMO. 2. Just because that's how new packages are handled. 3. I don't know, but it has been the de facto practice for packages from DMO, even long before I started contributing
<Yagisan> StevenK, how closeish ?
 * Hobbsee glances at the MOTU ML, and sighs.
<persia> LucidFox: I think it's a merge, but will put it through a review if you want.  On the other hand, I didn't find much in the last couple of your packages I checked, so I'm presuming you've already checked most of it./
<persia> s/\/$//g
<LucidFox> I'll change the bug to a merge request, then.
<persia> LucidFox: OK.  I'll archive the REVU entry.
<DaveMorris> persia: I've uploaded it, just waiting for the refresh
<persia> DaveMorris: OK.  I encourage you to hunt someone else for opensg, as it's not yet been so long that I think it wouldn't benefit from another reviewer.
<DaveMorris> sure, it seems best if different people review them etc.
<persia> DaveMorris: libserial is now back between jaaa and qdevelop in queue, as it was earlier :)
<persia> josesanch: Please collapse your changelog.  You might look at some of the packages that were advocated for examples.
<persia> Ng: Not a proper review, but the REVU server has some meaningful output from the automated lintian and linda runs that it would be worth addressing.
<Ng> persia: k
<josesanch> persia: yes, i did
<josesanch> it's about 100 lines now
<persia> josesanch: I was looking for about 10
<persia> josesanch: I was looking for about 10
<josesanch> 10 lines?
<josesanch> ok
<persia> josesanch: Most packages go in with a 5-line changelog.  Sometimes you need a couple extra for notes like a repack or significant patching.  None of the revisions that aren't going into the repositories are interesting.  Also, none of the packaging arrangements other than repacks or big patches are interesting for the initial release, as users are encountering this for the first time.  For any updates after the first release, entries like in your
<josesanch> persia: ok.. i'll put a changelog with initial upload to motu. it isn't?
<persia> josesanch: Compare http://revu.ubuntuwire.com/revu1-incoming/gnomecatalog-0801141310/gnomecatalog-0.3.3/debian/changelog and http://revu.ubuntuwire.com/revu1-incoming/terminator-0801141240/terminator-0.7/debian/changelog
<josesanch> persia: I have got it :)
<persia> You don't need to track changes in REVU with changelog.  These are just a way for you to get the package in good shape to start.  Once it goes in the repositories, then you want to track all the changes.
<josesanch> persia: i have to put the launchpad bug? like terminator
<persia> josesanch: Yes.
<persia> Actually, even terminator is wordy.  http://revu.ubuntuwire.com/revu1-incoming/smplayer-themes-0801101520/smplayer-themes-0.1.14+svn618/debian/changelog is the standard format.
<josesanch> persia: I will use smplayer format
<persia> josesanch: Thanks
<pochu> persia, Ng: empty /usr/lib/ is a python-central bug. I'd just ignore it, as it's not a policy violation. Debian bug #452227
<ubotu> Debian bug 452227 in python-central "Leaves empty /usr/lib in package" [Normal,Open] http://bugs.debian.org/452227
<Ng> pochu: ok
<persia> pochu: Thanks for digging that up.  I still think shipping empty directories by accident is bad, but now I know where to blame
<pochu> persia: it could be probably workarounded in binary-install, but I think waiting for a fix in pycentral is fine.
<persia> pochu: I'd agree with that.  I thought it was a distutils issue.
<pochu> persia: what user and passwd should I use to login in REVU? I'd like to make my first comments :)
<pochu> nevermind, found it
<persia> pochu: Have you never used REVU?
<persia> pochu: OK.  Let me know if you have issues, and I'll bump your access permissions.
<pochu> persia: I think I once uploaded a package, but I'm not sure and if I did it was before the other server was compromised.
<pochu> persia: No REVU account for pochu@ubuntu.com exists yet.
<pochu> persia: I can't find how to create a new one...
<emgent> uhm
<emgent> try to ping siretart
<pochu> ping siretart :)
<persia> pochu: Sorry.  Momentarily distracted.  I'll set you up.
<emgent> :)
<pochu> Alright, I didn't know you could :)
<siretart> pochu: use the email adress you used the last time you uploaded a package to revu
<pochu> siretart: unping
<emgent> pochu, haahahaha
<pochu> siretart: that was a long time ago, and it was probably removed when the database was restarted
<persia> siretart: Will that work even for people who last used REVU prior to the compromise?
<pochu> Didn't work.
<pochu> (I used either @ubuntu or @gmail and none of them work)
<Ng> fwiw, after I uploaded first I didn't get an email, so I did the password recovery thing and decrypted it fine
<persia> Ng: That's normal.  pochu is different as he seeks reviewer access without an upload.
<Ng> persia: oh
<Ng> well ignore me then ;)
 * siretart at work, sorry
<siretart> pochu: no, the database was reset
 * persia stops adding a user, and starts looking at other options.
<persia> pochu: No REVU account for any of the addresses on your key.  Creating one for pochu@ubuntu
<pochu> +.com
<DaveMorris> is the revu server sending out emails for you guys, since I'm not getting any more now
<persia> DaveMorris: http://lists.tauware.de/pipermail/motu-reviewers/2008-January/019458.html shows my last REVU comment.  Are you subscribed to that list?
<DaveMorris> yeah I was, but the last mail I got was on Fri
<persia> DaveMorris: Odd.  I'm not sure why the archives would be updating, and not your inbox.
<DaveMorris> yeah, my mail server gets other mail fine.
<DaveMorris> I'll have to look into it after work
<amarillion> Hello, could somebody please review my package: http://revu.tauware.de/details.py?package=speed-game ?
<amarillion> Oh hey, whattaya know :)
<jussi01> ok, im blank today, someone please give me the address or the new queue?
<Hobbsee> jussi01: https://edge.launchpad.net/ubuntu/hardy/+queue?batch=500
<rzr> persia: I dont understand where MAINPACKAGE can be defined , since there is nt any file included in jaaa/debian/rules
<jussi01> thanks Hobbsee
<Hobbsee> you're welcome
<persia> rzr: I thought it came from the environment, but I may well be mistaken.  Sorry for the confusion.
<rzr> then let's user define it
<persia> rzr: Works for me.
<rzr> erm, let the user to define it ..
<rzr> maybe the to can me omited too :)
<rzr> any native english speakers around to correct me ?
 * Hobbsee ponders reviewing.
<persia> rzr: dpkg-parsechangelog | sed -n 's/Source: \(.*\)/\1/p' will also generate the source package name, if you like.
<rzr> neat
<Hobbsee> rzr: s/to//
<rzr> Hobbsee: thx
 * persia liked "let's user define it", indicating cooperatively using the "user define" function in make to set the value
<rzr> in other words  (let 'value (getdef (user)))
<rzr> or so
<persia> rzr: Well, "let" is usually a synonym for "allow", whereas "Let's" is an abbreviation for "Let us", and if my memory is correct is short for something like "If the fates allow us, we shall ..."
<rzr> let it be
<persia> heh
<persia> Would anyone familiar with python be willing to provide shibata some direction with some guidance for http://revu.ubuntuwire.com/details.py?package=termlauncher-applet
<persia> s/with some/or/
<pochu> I'll have a look
<persia> pochu: Thanks.
<mok0> ubotu, bug 173507 > mok0
<ubotu> Launchpad bug 173507 in ubuntu "[needs-packaging] torque" [Wishlist,In progress] https://launchpad.net/bugs/173507
<persia> mok0: try /msg ubotu bug #173507.  Less keystrokes too :)
<ubotu> Launchpad bug 173507 in ubuntu "[needs-packaging] torque" [Wishlist,In progress] https://launchpad.net/bugs/173507
<persia> ubotu: Didn't someone make you a gag to not show the same bug twice in 5 minutes in the same channel?
<mok0> persia: heh
<ion_> First someone should take a look at IRC RFCs and make ubotu send all automatic messages as NOTICEs instead of PRIVMSGs. :-)
<mok0> persia: working on torque ATM. It would be great if it could make it into hardy. Also considering the fact that Mark seems to be interested in "specialist deployments, for example high-performance computing clusters, or vertical market solutions "
<mok0> Got worried seeing that there are only two weeks left
<Ng> pochu: thanks for your comments - I tried setting DEB_INSTALL_CHANGELOGS_ALL previously and it didn't seem to do anything - is the syntax "DEB_INSTALL_CHANGELOGS_ALL = ChangeLog"?
<pochu> Ng: := ChangeLog
<mok0> Ng: yes (or whatever upstreams changelog is called
 * Ng tries again, but I'm pretty sure I tried that too
<pochu> Ng: ideally you don't need it. ChangeLog is so common that CDBS/debhelper will look for it and include it if found. Works here on a sid pbuilder, but doens't on a hardy one. I'm investigating it.
<pochu> Ng: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
<Ng> pochu: yeah it worked in gutsy too. that bit got added from earlier comments saying it was missing
<Ng> yeah, it's not there with "DEB_INSTALL_CHANGELOGS_ALL := ChangeLog"
<pochu> That worked for me.
<pochu> Ng: put that *after* including debhelper.mk
<pochu> (i.e. at the end of the file)
<Ng> oh :)
<Ng> yay
<Ng> pochu: what do you mean about not needing pycompat? I suspect that is something being included by pycentral or debhelper or something, because I don't have it in my tree
<geser> Ng: iirc pycompat was used by dh_python which is obsolete now
<StevenK> CDBS probably still calls it
<persia> pochu: It's an intentional Ubuntu patch to CDBS to drop the changelogs.  As far as I understand, it's a special case for gimp, but applies to more packages for extra informative inclusion.
<amarillion> persia: with regards to your comment "If upstream is truly dead, and you can provide evidence that upstream agreed to ISC in debian/copyright, that too is likely acceptable (given the terms in speed.txt)."
<amarillion> persia: what would be acceptable as evidence in this case?
<persia> ...
<amarillion> this is the email exchange I had with him: http://paste.ubuntu-nl.org/51888/
<persia> amarillion: In the two cases I've seen it, email was quoted in debian/changelog.
<pochu> Ng: it's generated in debian/rules clean. You can avoid it being including by generating the source package with "dpkg-source -b foo-1.0/", or "dpkg-buildpackage -S -sa" (or similars)
<persia> Err..  debian/copyright.  Sorry for the confusion.
<amarillion> ok, I'll include the email text.
<pochu> persia: then why should we include the changelog, if it's intented to remove it? :)
<Ng> pochu: mine are generated by bzr-buildpacakge, but with source-builder set to 'dpkg-buildpackage -rfakeroot -S -sa'
<persia> pochu: Because it's useful.  The changelog removal only has a point to save space on the CDs.  For all of universe it just generates bugs.
<pochu> persia: right, this isn't in the CD. But bugs?
<pochu> Ng: btw if you are using hardy you don't need to pass -rfakeroot, it's now the default if you have fakeroot installed
<Ng> aha
<persia> pochu: 1) Not having changelogs makes it harder for triagers to determine when something was fixed, so fewer bugs get closed, 2) not having changelogs means users only see "New Upstream Release (closes: #332748)" in the changelog, are confused by differing behaviour, and file a bug (nothing they can check)
<pochu> persia: so the solution is to put the NEWS entry in debian/changelog? ;-)
 * pochu hides
 * persia strings pochu up by his smallest left toe over a pit of eels
<pochu> (note that the Desktop Team does that, so half joke half serious)
 * pochu googles for eels
<pochu> Ouch
<StevenK> Hehe
<pochu> Heya StevenK
<StevenK> "All I want is a tank full of sharks with friggin' lasers on their heads!"
<pochu> persia: btw I can't find that change in debhelper or cdbs' changelogs.
<persia> pochu: cdbs (0.4.49ubuntu3)
<pochu> persia: thanks. I was looking at 0.4.50ubuntu1 which should have mentioned that change.
<pochu> lunch :)
<persia> pochu: Yep.  Complain to the uploader if you like...
<mok0> pochu: Uhm, sounds good... wait... I already _had_ lunch...
 * persia notes that there are only 7 packages left on REVU that have yet to get a review today, and hopes they can all be reviewed during the (local) night
<Ng> pochu: apart from the pycompat thing, I've fixed all the other comments :)
 * mok0 notes that there's gonna be 9 in about 10 minutes
<wallyweek> http://revu.tauware.de/details.py?package=sdlmame updated and ready for reviews! :)
<DarkSun88> Hi all
<rulus> Hi, persia commented on my upload earlier today: http://revu.tauware.de/details.py?package=gtkvd and I'm trying to fix the issues. However, some questions. About point 1 concerning the upstream changelog, how does this word? Should I just remove the previous entries from the debian/changelog file?
<rulus> s/word/work
<pochu> Ng: would be nice if the --fullscreen option worked with F11, as gnome-terminal does. Wanna a wishlist in Launchpad? :)
<LucidFox> rulus> It basically means, move everything to a ChangeLog file for upstream changes, and leave only one entry in debian/changelog saying that it's the initial release
<LucidFox> rulus> You're the upstream developer, I take it?
<rulus> yes, I'm the upstream developer
<Ng> pochu: please :)
<rulus> LucidFox: thanks, I understand
<rulus> Another question: I added a watch file that checks the +download/ folder from the Launchpad project page (which works as it should btw). This does mean that I should register every release at the project page and upload a .tar.gz for it, right? Also the x.x.x-0ubuntuX ones?
<LucidFox> rulus> yes
<LucidFox> you should have a tar.gz for each upstream release
<LucidFox> not for each Ubuntu release
<LucidFox> because, for example, 0.1-0ubuntu1 and 0.1-0ubuntu2 will have the same orig.tar.gz
<rulus> ok, understood, thanks!
<Hobbsee> persia: there we go, i've done my work for the day :)
 * Hobbsee dealt with ~6 packages.
<Hobbsee> am i exempt from revu day now?  :)
<pochu> Ng: bug 182863. And I'm advocating it (my first advocate) :)
<ubotu> Launchpad bug 182863 in terminator "F11 should full-screen terminator" [Undecided,New] https://launchpad.net/bugs/182863
<pochu> What's the best place to make suggestions about REVU? (and were is the code, so I could see if I can make a patch for said suggestions?)
<Ng> pochu: sweet :)
<LucidFox> https://bugs.launchpad.net/ubuntu/+source/libflickrnet/+bug/182130 <-- Holy crap!!!
<ubotu> Launchpad bug 182130 in libflickrnet "package libflickrnet2.1.5-cil 25277-5 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,In progress]
<Ng> pochu: thanks muchly
<LucidFox> "This bug has 31 duplicates "
<Ng> LucidFox: yeah I hit that this morning and fudged round it with a symlink on the basis that it was so obvious it would have bee nreported a lot already. I guess I was right ;)
<LucidFox> And now 32 duplicates, since I marked one more bug as a duplicate :)
<pochu> Ng: if you don't intend to upload this to Debian I could take care of it. But I encourage to maintain it yourself there :)
<zoli2k> Hi! where can I ask questions related to KDE4 integration?
<Ng> pochu: I have to admit to being selfish and lazy and not terribly interested in Debian anymore. I don't even have a debian install anymore to test it on ;/
<Ng> but that's not the right spirit, so I'm happy to help out :)
<Hobbsee> zoli2k: #kubuntu-devel
<slytherin> ScottK: Can you tell me what to do next? - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460449
<ubotu> Debian bug 460449 in kdissert "kdissert: Please use dh_icons to update icon cache" [Normal,Open]
<zoli2k> Hobbsee: thanks
<pochu> Ng: to be honest I only have Debian on a VM and rarely test my packages :P
<pochu> Well I test them in Ubuntu
<pochu> and in a sid pbuilder, but not in a Debian installation
<pochu> Ng: if you want I can co-maintain it with you.
<Ng> pochu: that sounds worth trying :)
<pochu> We can maintain it in the Python Applications Packaging Team :) do you have an alioth account?
<bddebian> Heya gang
<pochu> Ng: ^ saw that?
<pochu> hey bddebian
<bddebian> Hi pochu
<pochu> bddebian: how are you doing? :)
<bddebian> OK I guess, thanks.  You?
<Ng> pochu: sorry missed that. No, I don't have an alioth account. I got one tiny package sponsored into Debian one time and then warty came out and I stopped using debian for most things ;)
<Amaranth> so...
<Amaranth> what's up with falcon?
<pochu> Amaranth: did you read the ML?
<Amaranth> yeah
<pochu> MLs rather
<Amaranth> and i noticed it went to ubuntu-devel now too
<pochu> ant to -archive by dholbach
<dholbach> where it should probably have gone in the first place and much earlier
<pochu> Ng: if you create one we can maintain it in alioth SVN :)
<pochu> dholbach: agreed.
<dholbach> with soren's proposal we should all be fine
<pochu> dholbach: but soren's proposal is about the binary, not about the packages. And we still need to hear what Seveas and imbrandon think about it.
<Ng> pochu: is there any specific advantage to doing it there instead of in launchpad? (hatred from debian people aside ;)
<dholbach> pochu: right... but in a different part of the thread renamind the binary packages and source packages to falconpl was already considered
 * dholbach needs to leave now, so see you all tomorrow!
<pochu> dholbach: I'm a bit lost. So are you thinking on moving falcon the language to falconpl for the source package but using /usr/bin/falcon, and falcon the repo using falcon for the source package and /usr/bin/falcon-whatever ?
<pochu> dholbach: later
<dholbach> pochu: I think that makes sense, given the point (interpreted scripts) that soren raised
<Amaranth> that sounds perfect
<pochu> dholbach: I agree with the binary name. Dunno about the packages name :)
<Amaranth> the 'original' falcon gets the package name, the language gets the binary
<pochu> Well it would be a bit confusing if there's a falcon source package but the falcon binary is in a different package, but not an important thing I guess
<pochu> Amaranth: 'original' as in what?
<Amaranth> pochu: as in here first :)
<pochu> Amaranth: well if here means the archive then it was first, yes. But if it means needs-packaging and the like then it wasn't ;)
<rulus> hmm, when my .tar.gz contains another .tar.gz, there's something not right I guess? check http://revu.tauware.de/details.py?package=gtkvd
<rulus> got no comments about it, but doens't seem very logical to me
<LucidFox> rulus> Indeed, not logical
<LucidFox> Why is there another tar.gz inside?
<rulus> probably because my packaging is wrong, I'll go through the packaging guide again
<LucidFox> rulus> You should make an upstream release prior to packaging
<wallyweek> could anyone please check http://revu.tauware.de/details.py?package=sdlmame
<rulus> LucidFox: an upstream release is just all the files in a .tar.gz?
<LucidFox> yes, except for the debian directory, because it's part of the packaging
<LucidFox> then you'll use that tar.gz as gtkvd_0.4.2.orig.tar.gz
<slytherin> rulus: ideally upstream should release a tar.gz, is not the case in the package you are trying to create?
<rulus> aha, that's why I missed the .orig too
<rulus> slytherin: I'm upstream
<slytherin> rulus: :-)
<slytherin> geser: I am currently trying building batik with sun java. Please tell me, if it works should I first get the debian package and then change it to use sun-jdk (debian has 1.6-4, ubuntu has 1.6-3)
<Amaranth> slytherin: you should use sun-java6-jdk
<Amaranth> or java5, i guess
<slytherin> Amaranth: yes, I am trying that. The question is not related to which java should I use because I have already found the answer. But the question is whether to submit debdiff against current ubuntu package or get debian package and then submit debdiff.
<LucidFox> Debian.
<LucidFox> The current Ubuntu package was synced from Debian anyway, so it makes sense to use the latest Debian version when submitting your changes.
<slytherin> LucidFox: Ok, then how should bug filing go? a sync bug with debdiff against debian package attached?
<LucidFox> yes
<LucidFox> (Disclaimer: I'm not a MOTU)
<slytherin> LucidFox: I would rather then wait for geser's answer with whom I have been communicating for a while regarding the FTBFS
<Amaranth> slytherin: I would suggest submitting the change for inclusion in Debian but if you can get it into Ubuntu sooner that's good too
<Amaranth> Because we can always just do a clean sync later when Debian catches up
<slytherin> Amaranth: For Debian it may not be justified as arch all packages are not build on buildd. Where as in Ubuntu we need Sun JDK because we can only preseed debconf for Sun JDK license question.
<LucidFox> By the way, does it make sense to request a sync if it merely merges all existing Ubuntu changes?
<man-di> slytherin: when you have done it please show me your patch against batik, I hate to see differences between Debian und Ubuntu Java packages when not needed
<slytherin> man-di: Sure, provided it builds. :-)
<LucidFox> Apparently, the Utnubu team is dead :/
<geser> slytherin: debdiff against the latest debian package is ok (if you want you can also provide a debdiff from the current Ubuntu package to the new one)
<\sh> moins
<geser> Hi \sh
<\sh> geser, you scared me just now...shermans-aquarium ;)
<slytherin> man-di: What do you say about this? This is when trying to build Debian batik package in Ubuntu pbuilder, http://paste.ubuntu-nl.org/51899/
<geser> slytherin: sun-java5 or sun-java6?
<geser> slytherin: the package has only a check for the JAVA_HOME of sun-java6
<slytherin> geser: No sun java. No changes, Only thing I needed to do was install the specified jdk inside pnuilder to avoid the license question problem.
<slytherin> geser: So the package specifies something else in control files and check for something else in rules
<man-di> slytherin: please show me "grep Build-Depends < debian/control". I cant look otherwise from here
<slytherin> man-di: Build-Depends: debhelper (>= 4.2.30), cdbs
<slytherin> Build-Depends-Indep: sun-j2sdk1.4 | java2-compiler, ant, libbsf-java, libxalan2-java, rhino, libavalon-framework-java (>= 4.2.0-1), libcommons-io-java, libcommons-logging-java
<Ng> are there any MOTU heroes currently awake who'd like to look at http://revu.tauware.de/details.py?upid=1252 and advocate? (aiui I need 3 advocates for a NEW package)
<Hobbsee> Ng: 2.
<Ng> ooh, then I'm 50% there \o/
<man-di> slytherin: thats the problem CDBS expects sun-j2sdk1.4 and ant to be installed during clean target execution
<slytherin> man-di: that's not the only problem, JAVA_HOME_DIRS doesn't have any directory corresponding to sun-j2sdk1.4
<man-di> slytherin: which dirs does it contain?
<slytherin> man-di: /usr/lib/j2sdk1.4-sun /usr/lib/j2sdk1.4-ibm /usr/lib/j2sdk1.4-blackdown /usr/local/IBMJava2-ppc-142  /usr/lib/jvm/java-6-sun/
<man-di> the build-depends is strange anyway, it should never use javaX-compiler
<man-di> sun-j2sdk1.4 is *definitely* /usr/lib/j2sdk1.4-sun
<man-di> sun-j2sdk1.4 is the 1.4 package created with java-package/make-jpkg
<slytherin> man-di: the home is not correct on Ubuntu system. Let me check for Debian
<jdong> what is the preferred version number mangling to repack an orig.tar.gz that needs two binaries removed?
<man-di> slytherin: I dont think Ubuntu patched that in java-package
<jdong> .repack, +repack?
<slytherin> jdong: I guess .repack
<man-di> Ubuntu dont patched java-package at all
<slytherin> man-di: hmm, so I guess I need to start from there
<man-di> if I remember correctly (I dont worked on that myself) the problem was that packaged JDKs were not able to build batik because the XML stuff in the JDK was too new and incompatible (like interfaces needed new methods which are not implemented in batik)
<siretart> jdong: many people add +dfsg{$number} to the version
<slytherin> man-di: That might be another problem. So it will not build with sun jdk anyway
<man-di> not with JDK 5 or 6
<slytherin> man-di: right, my mistake
<man-di> slytherin: sounds like a showstopper for batik in Ubuntu :-(
<slytherin> geser: batik will not build with sun jdk 5 or 6. is there no way to adjust debconf for j2sdk package?
<slytherin> man-di: unless someone packages 1.7 version
<jdong> siretart: I thought about that, but I didn't think it's appropriate because mpeg4ip is too restrictive to be called "dfsg" anyway, right?
<man-di> slytherin: that is in the works
<man-di> slytherin: Vincent (if I remember his name correctly) is working on that
<LucidFox> slytherin> What about icedtea? (You probably tried that first, though)
<siretart> jdong: I don't know enough about mpeg4ip enough to comment that.
<slytherin> man-di: I guess it also requires an additional package. Not sure if it is in Debian yet
<man-di> LucidFox: icedtea is too new too
<slytherin> LucidFox: won't do.
<man-di> slytherin: perhaps best to contant Vincent yourself and work together with him
<slytherin> man-di: will do tomorrow.
<LucidFox> jdong> Well, mpeg4ip is free software, just patent-encumbered
<LucidFox> (which only applies in the US anyway)
<LucidFox> So I think it makes sense to use "dfsg"
<jdong> LucidFox: ok very well then I'll use dfsg. You sure Debian people with pitchforks won't come burn down my house? :D
<LucidFox> lol
<Hobbsee> !jdong
<ubotu> <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<LucidFox> Hobbsee> o_O
<jdong> and can .jpg files be licensed under the MPL either?
<jdong> I'm guessing it's a no?
<LucidFox> but isn't mpeg4ip currently in NEW?
<jdong> LucidFox: rejected again
<jdong> LucidFox: there's a few random binaries in there and other ill-licensed things
<LucidFox> I see it in NEW...
<jdong> LucidFox: shouldn't be... was rejected two days ago
<LucidFox> https://launchpad.net/ubuntu/hardy/+queue?start=20
<jdong> unless I was uploading in my sleep...
<LucidFox> uploaded yesterday
<jdong> GRUMBLE who uploaded that?
<LucidFox> "Changed-By: Mario Limonciello <superm1@ubuntu.com>"
<jdong> ah
 * superm1 awakens
<jdong> superm1: hey I've got mpeg4ip under control, there's licensing issues in the source tarball and debianization too
<jdong> superm1: been rejected twice by archive admins already
<superm1> jdong, this i was not aware of
<jdong> 0.2 is just a rebuild of 0.1 anyway
<jdong> superm1: haha nor was I until last week :D
<jdong> superm1: but yeah, it's a real work of art. debian/copyright says GPL while the COPYING file lists like 15 different licenses :)
<LucidFox> lol
<superm1> jdong, yeah did you look at my modified debian/copyright?
<jdong> superm1: no, what'd you change it to?
<superm1> i listed every license I could (more verbosely than COPYING did)
<jdong> superm1: grumble stop duplicating work! :D
<superm1> there were a few in COPYING that were not referenced previously
<superm1> jdong, well i suppose I should have looked for needs-packaging bugs that may have already been opened...., was there one?
<jdong> superm1: no I don't think there were any bug reports open
<jdong> superm1: I don't think there's any way you could've predicted this :)
<superm1> er i mean, "i didn't see any needs packaging bugs opened, so i took initiative" :P
<jdong> superm1: you want to finish it up then? :)
<geser> slytherin: looks like the j2jdk1.4 debconf question can be preseed too
<superm1> well what more is there too it?
<superm1> it appeared to me that mpeg4ip had to be uploaded, faac rebuilt against it
<slytherin> geser: Good, That will help. :-)
<superm1> faad rebuilt against that
<superm1> and then $other_things rebuilt against all 3
<jdong> superm1: remove lib/rtp/test-libcommon (ELF binary), remove doc/*.pdf,*.jpg because they cannot be licensed under the MPL
<LucidFox> yes, and now there are a whole lot of new packages blocked by the libmp4v2 transition
<jdong> superm1: once that's done the rest look good
<jdong> superm1: and we can proceed with all the fun of rebuilding
<superm1> images can't be licensed by MPL?
<jdong> superm1: can they?
<LucidFox> gtkpod-aac, avidemux, and the x264 transition is also stalled as a side effect...
<jdong> superm1: IANAL... if they can then never mind, just the pdf
<superm1> jdong, well did archive admins tell you this last time around?
<superm1> jdong, or what ended up happening?
<jdong> superm1: I was specifically told that the pdf needs to be nixed, as well as the ELF binary
<superm1> LucidFox, and mytharchive (and consequently the planned mythbuntu alpha)
<geser> slytherin: the hard part is to get it done in the buildd chroots. Try to get a hold of infinity and convince him to do this.
<jdong> superm1: I wasn't told about the picture but I don't think pictures count as source code?
<superm1> jdong, well doesn't hurt to nix the images i suppose
<jdong> superm1: yeah nothing uses it
<superm1> now what do you say about versions though of it 0.2, 0.1?  the version on it is 1.6-0.2?
<superm1> (from debian-multimedia)
<superm1> is that what you're meaning
<jdong> superm1: yeah that's fine, but you're gonna have to repack the orig.tar.gz
<jdong> superm1: so probably 1.6.dfsg-0.2ubuntu1?
<superm1> bah :)
<slytherin> geser: or perhaps wait a week more and see if batik 1.7 lands in debian. It will build against sun java 5. :-)
<jdong> superm1: fun fun fun :)
<superm1> jdong, when you did it though..
<superm1> jdong, did you run into issues with the circular dependency
<superm1> of faad and faac on mpeg4ip
<jdong> superm1: yes, you have to undepend on at least faac
<superm1> jdong, well here's the thing
<jdong> superm1: faad was still installable the last time
<superm1> jdong, the README.html tells you not to build with either
<superm1> jdong, so i'm not sure why Christian was in the first place
<LucidFox> Did you try contacting him about that?
<LucidFox> He's very responsive
<jdong> superm1: I believe mp4live likes having faac support
<superm1> LucidFox, i might have. i  sent a lot of emails out this weekend. lets see
<superm1> jdong, well the readme at least claims that build problems tend to crop up
<superm1> but for now, it will have to be built without it either way
<jdong> superm1: well we need to build without it right now anyway
<jdong> superm1: we can re-enable their builds aftewards.  I personally don't care either way
<jdong> superm1: as we're mostly after libmp4v2, not the other crap it comes with
<superm1> yeah exactly
<superm1> well i'm hoping the licensing is good enough at this point
<superm1> you want to take a gander at my debian/copyright in NEW right now
<jdong> superm1: let's aim to unbreak the entire MPEG4 stack at this stage, jsut repack the orig and call it a day
<superm1> and give it a second look over?
<jdong> superm1: I'll download your copy and give it a look
<superm1> jdong, hehe :)
<superm1> LucidFox, yeah i apparently did send Christian an email at some point this weekend (glad i'm not crazy)
<geser> slytherin: ok, let's wait an other week before I try pinging infinity about the debconf preseeding
<jdong> superm1: hmm they're a bit different, let me pastebin mine then let's decide which one to use
<jdong> superm1: http://paste.ubuntu.com/3559/
<warp10> persia: can I request the sync for brutalchess?
<LucidFox> jdong> When you're done with mpeg4ip, could you please look at bug #172839 as part of your backports work?
<ubotu> Launchpad bug 172839 in gutsy-backports "Please backport libqca2 2.0.0-3 from hardy to gutsy" [Undecided,New] https://launchpad.net/bugs/172839
<superm1> jdong, i think i like yours better
<jdong> superm1: :) well at least my time wasn't completely wasted last thursday :D haha
<superm1> jdong, i'll throw your name in the debian/changelog
<superm1> jdong, and call it a day after the repack
<jdong> LucidFox: the backport request sounds reasonable to me, I would feel better if afterwards we tell Rid-dell or someone to rebuild the affected KDE packages anyway
<jdong> superm1: sounds good, let's hope this is the last round :)
<geser> warp10: have you seen bug #182454?
<ubotu> Launchpad bug 182454 in brutalchess "Please sync brutalchess 0.5+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/182454
<LucidFox> I should really have advocated it earlier, before the KDE packages were uploaded :/
<superm1> jdong, in case it gets shot down some time this week, feel free to fix any quick things and upload it again your name (i am going to be moving this week and w/o internet access for several days)
<jdong> LucidFox: see bug 182605
<ubotu> Launchpad bug 182605 in gutsy-backports "Please backport qca2 (2.0.0-3) from Hardy" [Undecided,In progress] https://launchpad.net/bugs/182605
<jdong> superm1: ah, ok, I'll keep an eye on it for you then :)
<LucidFox> Ah, so it's a duplicate then
<warp10> geser: ops! I missed it. Ok, never mind. Thank you :)
<jdong> LucidFox: yeah, jpatrick filed it later than you though ;-)
<LucidFox> I'll mark mine as a duplicate because it has less activity
<jdong> 12:12 -jpatrick(n=patrick@ubuntu/member/jpatrick)- I'm sorry, but I'm away  (sleep)
<jdong> thanks for the information :)
<jdong> boy that's creepy
<jdong> LucidFox: yeah since the other one has been approved already
<jdong> wait does sudo in Hardy strip environment variables now?
<superm1> like SUDO_UID and SUDO_GID?
<superm1> or other stuff
<jdong> superm1: even other arbitrary variables
<jdong> LucidFox: yeah since the other one has been approved already[jdong@blackbook:devel/mpeg4ip-1.6]$ export FOO=bar               (01-14 12:15)
<jdong> [jdong@blackbook:devel/mpeg4ip-1.6]$ sudo sh -c 'echo $FOO'       (01-14 12:15)
<jdong> [sudo] password for jdong:
<jdong> yeah seems like it strips everything
<superm1> well that's crazy.
<jdong> odd enough
<rulus> when dpkg-buildpackage says me 'source version is 0.4.2-0ubuntu1' then I'm doing something wrong? Shouldn't it tell me the source version is '0.4.2'?
<LucidFox> rulus> Could you paste the entire output of dpkg-buildpackage on http://paste.ubuntu.com/ ?
<rulus> I can, one sec
<minghua> A native package, perhaps.
<minghua> Or maybe nothing is wrong.
 * jdong works on fixing prevu's lp scrapers
<LucidFox> Well, he uploaded a native package to REVU before
<rulus> http://paste.ubuntu.com/3560/
<minghua> I just can't remember what dpkg-buildpackage is supposed to say for a non-native package. :-)
<LucidFox> well, nothing is wrong I think
<LucidFox> actually, not "I think" - nothing is wrong
<LucidFox> dpkg-source: building gtkvd using existing gtkvd_0.4.2.orig.tar.gz
<rulus> nice
<LucidFox> For convenience, in the future you can call "debuild -S -sa", which will call "dpkg-buildpackage -S -sa -rfakeroot"
<rulus> I did call dpkg-buildpackage -S -sa -rfakeroot
<LucidFox> yes, but typing debuild is shorter :)
<rulus> I use a shell script, but thanks anyway ;)
<LucidFox> heh
<LucidFox> rulus> I don't see the updated gtkvd on REVU yet...
<rulus> I'm trying to make both source and binary package.. Does this require calling dpkg-buildpackage twice?
<Ng> how often should I be pestering about something in revu? I don't want to annoy anyone, we're just excited about the prospect of getting into the archive :)
<LucidFox> rulus> Well, REVU only accepts source packages
<rulus> LucidFox: I know, but I'd like to test my package locally first
<LucidFox> then it's better to build binary packages from the source package in pbuilder
<rulus> ah, I'll check that out, thanks
<LucidFox> this way, you can check for missing build dependencies
<jdong> grumble debmail, debemail, same thing.... :)
<jdong> there's nothing more fun in the world than setting up a new development box
<rulus> hmm, my package apparently install's an empty /usr/lib folder but I have no clue where it comes from.. It's not in debian/dirs nor in setup.py..
<LucidFox> rulus> can't you just rmdir it?
<jdong> alright, time to go install another Ubuntu box
<jdong> bbl everyone :)
<rulus> LucidFox: how do you mean?
<jpatrick> LucidFox: sorry about the dup, LP didn't show it
<ScottK> rulus: It's a bug in python-central/python-support.
<rulus> ScottK: so I shouldn't care?
<LucidFox> jpatrick> No problem :)
 * ScottK wouldn't care, but I'm not sponsoring your upload.
<rulus> *can* I fix it?
<ScottK> If that bug ever gets fixed, you'd have to remove whatever fix you came with and in the meantime your package would be broken.
<ScottK> It doesn't actually cause any harm.
<rulus> well, in that case I don't care
<LucidFox> ScottK> So I was right that the immediatist vs. eventualist division exists not only in wiki communities :)
 * rulus updated his package at http://revu.tauware.de/details.py?package=gtkvd
<ScottK> Right.
<ScottK> LucidFox: In this case it's a issue of prettifying the package now versus maybe a broken package later.  If you rmdir that dir and then the dir doesn't exist due to the bug being fixed, the package will FTBFS.
<LucidFox> rulus> hasn't uploaded yet
<LucidFox> probably will in 6 minutes
<rulus> well it's uploaded, but had not appeared yet
<rulus> s/had/has
<LucidFox> rulus> Since it's not actually a "new" upstream release, debian/changelog should probably read "initial release"
<LucidFox> and Ubuntu uses "LP: #XXX" instead of "Closes: #XXX"
<LucidFox> Here's an example of the first debian/changelog entry, used by persia: http://revu.ubuntuwire.com/revu1-incoming/smplayer-themes-0801101520/smplayer-themes-0.1.14+svn618/debian/changelog
<rulus> ok, thanks :-)
<LucidFox> rulus> Also, this is of course your choice, but I would consider licensing it under "GPLv2 or later" rather than just GPLv2
<LucidFox> or maybe even GPLv3 or later
<rulus> LucidFox: I haven't read the GPLv3 yet, and v2 is perfectly reasonable to me
<LucidFox> Of course, you can always relicense it in the future...
<rulus> I updated the changelog, should I immediately reupload or wait for comments first?
<LucidFox> I think immediately reupload
<LucidFox> comments probably won't arrive in a while
<LucidFox> (and I'm not a MOTU, so I can't comment either)
<rulus> Should I create a new entry in the changelog 0.4.2-0ubuntu2, or just change the -ubuntu1 entry?
<LucidFox> Upload it as -0ubuntu1
<LucidFox> the revision number is for changes that actually made it into the archive
<rulus> it doens't matter there is already a -ubuntu1 uploaded?
<LucidFox> use dput -f
<rulus> uploaded
<LucidFox> Maybe I should apply for MOTUship. I'm tired of these "I'm not a MOTU" disclaimers. :)
<ScottK> LucidFox: That's one sign you might be ready to apply.
<pochu> stgraber: did you see this? :) http://lists.debian.org/debian-devel/2008/01/msg00506.html
<jeromeg> jdong: hello
<jeromeg> could you please confirm a backport request I made ?
<LucidFox> Gah... I should have subscribed to motu-council first, and then send the application
<pochu> LucidFox: reject the mail and resent it once you are subscribed :)
<LucidFox> how do I reject it?
<pochu> follow the link in the moderation message
<pochu> (at least that's possible for messages to -desktop)
<LucidFox> Ah, got it.
<LucidFox> Of course, all the CCs will now receive it twice... oh well
<\sh> geser, are you working on a security update of drupal? if not, I'm preparing some
<DktrKranz> \sh, IIRC emgent is after them
<geser> \sh: no, I've only seen that drupal5 got already merged for hardy
<\sh> geser, well, gutsy is has three sec updates open/ sa-2007-31 -> 5.3 to 5.4 with the fix of 5.5 for the 5.4 fix ;) and 2008-0005 + 0006 -> 5.6
<\sh> DktrKranz, well, no bug reported...
<DktrKranz> \sh, did you check nominations for gutsy? I think there's something on there
<\sh> DktrKranz, on the drupal5 src page on LP i don't see any bug report...I'll check motu-swat...hopefully the bugs are not private...
<\sh> DktrKranz, found it, but the diff is useless :) the bugfix for the security fix is not applied...
<DktrKranz> \sh, ah. nevermind then.
<\sh> DktrKranz, I'll added a comment...if he's going to take it mutch better :)
<mok0> \sh: great if you update drupal!!
<\sh> mok0, well, when emgent is working on it, he needs it :)
<mok0> \sh any plans of packaging some themes and modules?
<\sh> mok0, that was on my mind last days...
<mok0> \sh: ;-D
<DktrKranz> \sh, I mentor him actually. He's moving his first steps, but it seems he learns quickly
<\sh> mok0, but when I see all the security advisories on drupal.org security page I wonder if this is a good idea :)
<\sh> DktrKranz, ah you are his mentor :)
<DktrKranz> \sh, at least I try :)
<mok0> \sh: security -- I think it's mostly security of the site, rather than security of the host Os
<\sh> mok0, nah...all those non-core  modules are having the usual XSS problems most of the time and they are fixing them ... but despite the good work of drupal-core with their patches, most module maintainers are not patching but releasing new versions
<\sh> mok0, and that makes maintaining a nightmare
<ScottK> DktrKranz: You mentioned you had a Debian Python Applications Packaging Team question for me?
<\sh> mok0, but I like the idea of having a shiny, blinky useful drupal in ubuntu ,-)
<mok0> \sh: the version that in there now is age old
<mok0> 5.2 I think
<\sh> mok0, yeah,...but at least this version has all serious bugfixes attached :)
<mok0> sh\: cool.
<Amaranth> drupal still exists?
<\sh> mok0, and if emgent is doing the other fixes too it's even more secure ;)
<\sh> Amaranth, sure..
<mok0> \sh: lemme know if there is something I can do to help
<DktrKranz> ScottK, yes. recently piotr added me to the team and soon I'd like to add my packages to PAPT, so before pushing wrong stuff on SVN, I'd like to ask to someone already involved.
<ScottK> DktrKranz: OK.  Fire away when you have questions.
<DktrKranz> ScottK, sure. Thanks.
<Amaranth> \sh: I've been brainwashed into thinking everyone just makes their own using rails or django :)
<mok0> What is this django everyone is raving about?
<\sh> mok0, python style rails ... and yes, it's the wrong attribution for django ;)
<\sh> Amaranth, I don't know...but for a quick and fast installation of a website with blog etc. drupal is quite ok, even when it is php
<Amaranth> \sh: rails is python style django, it's just more popular :)
<\sh> Amaranth, well, I don'
<jdong> jeromeg: did you test transmission on gutsy, feisty, or both?
<\sh> t like ruby and I don't like rails...that's my problem
<jdong> I've only had the chance to verify on Gutsy
<jeromeg> jdong: 1.0.0-1 only on gutsy I upgraded my feisty box since my original backport request
<jdong> jeromeg: ok,  I'll approve on Gutsy and wait in Feisty for someone with a build env then :)
<jeromeg> jdong: looks like the backport team needs a bit of work force :)
<jeromeg> jdong: i can test the build for feisty
<jeromeg> but not test if it works ok
<jeromeg> jdong: I know that Lionel Porcheron would be pleased to join the backport team
<jeromeg> my point of view (if it's worth something :) ) is that he is a good candidate
<jeromeg> moreover at the moment almost nobody seems to work on backports
<lionel> jeromeg: :)
<jeromeg> so a new skilled contributor would be an asset
<jdong> jeromeg: yeah seems like the fresh new members are always the ones that contribute the most ;-)
<jdong> jeromeg: currently it looks like the approval guys are fast enough at getting around, it's the QA effort that's lacking
<jeromeg> jdong: if only I was a motu :)
<jdong> jeromeg: particularly for Feisty and below the number of people willing to test them is nearly nonexistent
<\sh> jdong, would you like to try a backport of wine 0.9.53 to gutsy and feisty? I prepare a new upload just now with opencdk enabled
<jdong> \sh: shiny :)
<jeromeg> jdong: well I wouldn't say this, for example I submitted a lot of backport requests to gutsy, and none of them got an answer
<jeromeg> i tested everything carefully
<jeromeg> but...
<ToyKeeper> jdong: Heh, the fresh new members probably just haven't gotten overloaded with long-term side projects.  :)
<jdong> jeromeg: well perhaps you've tested yours carefully, but as I go down  the list in gutsy-backports I don't see any so far I feel ready to just hit the approve button on.
<jdong> jeromeg: so it might be other people holding you down ;-)
<jeromeg> maybe :)
<jdong> ToyKeeper: yeah, that's usually true, I'm starting to feel that myself already
<jdong> ToyKeeper: sometimes I really feel like I've submerged myself in enough half-done projects to take 12hrs a day to dig out of
<jdong> :)
<jdong> ok, backports clearing time...
<jeromeg> great
<jeromeg> i'm building audacious at the moment
<nxvl_work> pochu: ping
<jeromeg> lionel has set up a repo to test pidgin
<jeromeg> my little sisters will be testing it carefully :)
<jdong> jeromeg: yeah the nasty part about pidgin is following all the plugins
<jdong> and the sucker tends to segfault too on mismatched plugins, not just refuse to load them
<jeromeg> jdong: the hardy->gutsy transition seems ok
<jeromeg> gutsy->fesity is really a shit
<jeromeg> *feisty
<jdong> jeromeg: I'm 95% certain the API changed between the two releases, I've looked at it a bit
<jeromeg> ok
<jdong> jeromeg: plus, I don't want to know what the heck we'll do if there's  a security bug found in the 2.3.1 series
<jdong> jeromeg: we'll all be running around poking core-devs to sponsor source change backports :)
<jeromeg> :)
<jeromeg> ok
<jeromeg> jdong: security fixes are not automatically backported if the package is in backports .
<jeromeg> ?
<jdong> jeromeg: correct. we are on our own to produce security fixes.
<jeromeg> miam
<jdong> jeromeg: I'd feel better if hardy were released AND the package still backports easily, because then we can rely on the security team and backport from hardy-security
<jeromeg> ok
<jdong> jeromeg: but anyway, having a sane backports PPA for pidgin is a good idea anyway
<jdong> jeromeg: I see too many horribly produced .debs out there
<jeromeg> jdong: yep
 * DaveMorris hopes someone else can advocate his package - http://revu.tauware.de/details.py?package=libserial
 * jdong laughs... he found an unapproved backport that he filed himself in November :D
 * Ng too is looking for another advocate for the robot future of Terminals - http://revu.tauware.de/details.py?package=terminator
 * TheMuso rally thinks some contributors should slow down with their rate of contributing, and be more careful about the work they are doing...
<TheMuso> s/rally/really/
<DaveMorris> TheMuso: you can't knock them for trying though
<TheMuso> DaveMorris: Not at all. Thats not my point.
 * jdong thinks we need a robotic archive admin simulant :D
<TheMuso> The point is, that being so eager to get as many things updated as possible, leaves the possibility of missing something important. IMO anyway
<\sh> I wonder for what wine needs opencdk...
<DaveMorris> I wonder if there could be a way for motu hopefulls to do comments on packages to clear out some of the easier issues for those people who cna actually advocate
<Ng> they could just comment, surely?
<jeromeg> jdong: audacious needs libmowgli
<ScottK> DaveMorris: It could be done.  What it primarily lacks is someone hacking the capability into REVU.
<ScottK> Ng: No.  Currently only MOTUs can submit comments on packages they didn't upload.
 * TheMuso is referring to sponsors que stuff
<Ng> ScottK: ah
<jeromeg> jdong: libmowgli builds and install fine, and is not in gutsy
<jeromeg> seems to be fine for backporting
<DaveMorris> it could be a stepping stone along the way to been a MOTU I guess
<geser> DaveMorris: hacking on REVU?
<DaveMorris> no, revuing packages and commenting, but not able to advocate
<wallyweek> g'evening all!
<pochu> nxvl_work: contentless pong
<nxvl_work> pochu: what's the state of http://revu.tauware.de/details.py?package=terminator
<pochu> nxvl_work: it's advocated by me
<wallyweek> can anyone have a look at http://revu.tauware.de/details.py?package=sdlmame
<wallyweek> It should be good for advocation after latest fixes
<nxvl_work> pochu: that means accepted? and it's waiting for other advocates?
<pochu> nxvl_work: I'd like someone else to advocate it too
<nxvl_work> ok, just asking
<nxvl_work> :D
<mok0> nxvl_work: not a MOTU but looks fine to me too
<nxvl_work> mok0: :D
<josesanch> mok0: can you review mine?, http://revu.tauware.de/details.py?package=gnomecatalog
 * mok0 looks
<josesanch> mok0: thanks
<mok0> josesanch: why don't you use cdbs? Look at nxvl_work
<mok0> 's debian/rules
<josesanch> i don't know
<josesanch> it's necessary?
<mok0> josesanch: no, it's just easier :-)
<josesanch> terminator looks quite simple :)
<josesanch> i mean debian/rules file
<mok0> josesanch: In debian/control: Description: Cataloging software for CD, DVD, and hard disk files --- it's kind of obvious that it's software, so make it shorter and more exact
<mok0> e.g. "catalog CD, DVD and hard disk files"
<josesanch> Ok..
<Ng> josesanch: yes :)
<mok0> josesanch: ... and the following description, first and second sentences say the same thing. Don't repeat yourself
<nxvl_work> josesanch: cdbs is the simpler and easier way to build packages
<josesanch> mok0: jeje ok
<nxvl_work> but i still prefer debhelper
<nxvl_work> :P
<mok0> hehe
<mok0> cdbs is an aquired taste
<nxvl_work> josesanch: why is it -0ubuntu10?
<mok0> josesanch: should be 0ubuntu1
<josesanch> I started by 0ubuntu1, but i had to change things
<ToyKeeper> Anyone tried mercurial patch queues for managing package patches?
<pochu> As long as it's not uploaded to the Ubuntu archive, don't bump the version
<nxvl_work> josesanch: yes, but it where unuploaded changes
<nxvl_work> josesanch: for ubuntu is the first version
<nxvl_work> so it should still be ubuntu1
<mok0> josesanch: debian/gnomecatalog.1 ... September 27, 2002 ?????
<stgraber> pochu: ouch, looks like we have a lot of activity around those packages :)
<josesanch> mok0: It's the date when i created the manpage
<mok0> josesanch: this packaging has taken you a while, huh ;-P
 * pochu wonders whether stgraber will join the FingerForce team :)
<josesanch> mok0: yep... is hard :)
<mok0> josesanch: 6th last line "The program HAS been developED in python-gtk"
<stgraber> pochu: hehe, well my free time activity is the QA website, then edubuntu, then bug triaging, then packaging :)
<stgraber> pochu: I usually do packages for things I want to use and aren't packaged yet (I don't like having non-packaged binary), then if I can have them included without spending more than 2-3 hours I do it
<mok0> josesanch: but, with the man page, I think you should write a bit more, and with more enthusiam... Why should people use this program? Can it print an index or create a searchable database? Explain in the manpage
<mok0> josesanch: otherwise, I'm cool, good work
<josesanch> mok0: thanks, my english is not good at all.
<nxvl_work> josesanch: it also should be "Initial release for ubuntu inclusion" not just "initial release" since it is the 0.3.3 release of your package
 * emgent hi
<mok0> josesanch: NP we are helping each other
<pochu> stgraber: yeah, you rock with the qa website. I'm spying you as I'm subscribed to the bzr branch :)
<mok0> josesanch: now you just need a MOTU to ack it :-)
<\sh> emgent, hi :) can you have a look on your drupal5 security update bug report :)
<nxvl_work> wow, my pbuilder seem to be rebuilding instead of updating, i need to use/update it more often :S
<josesanch> mok0: thanks very much. I have done the changes. i'm going to write a better manpage, and reupload again
<stgraber> pochu: you are only subscribed to the low-traffic one :) (trunk)
<mok0> josesanch: great
<mok0> josesanch: man page is often the first thing I look at when trying out a new package, so it's good to "sell" the program well in there
<stgraber> pochu: about the fprint packages, what's the best, let the fingerforce team take care of it and hope we'll have a package ready soon enough for a sync ?
<mok0> "fingerforce team"?? LOL
<josesanch> mok0: thanks i have the changes now. Any other observation or advice?
<pochu> stgraber: if feel your package is ready we can et it in and sync it later if it's packaged in time in Debian.
<\sh> emgent, the patch for sa-2007-0031 had a bug which was fixed with the 5.5 release...and http://drupal.org/node/198321 gives the bugfix for it :)
<pochu> stgraber: so we make sure it gets packaged in Hardy
<slicer> I have a directory policy question. My package is setup for system-wide install, but the daemon CAN be run by a regular user. If so, the user should create a .ini file for the daemon based on a template in the source. I've currently placed the template in /usr/share/doc/ (by adding it to the .docs).. Is that acceptable?
<emgent> \sh, thanks i read your comment
<\sh> ok...end of business..family time :)
<\sh> cu tomorrow
<emgent> tomorrow i will fix all
<pochu> stgraber: unless you aren't that hurry ;)
<emgent> now i go to sleep :P
<mok0> josesanch: nope. Just wait for a MOTU to come along...
<stgraber> pochu: I don't personaly care :) I do have the package for my own use :)
<josesanch> mok0: thanks again :)
<mok0> josesanch: nice work
<pochu> stgraber: heh, we can wait a bit and if in February 1st it isn't packaged in Debian get it in here.
<stgraber> pochu: the only difference for me is that if we upload libfprint to universe, I'll then work on libpam-fprint and fprint-demo too (as libfprint is useless without a software using it)
<wallyweek> no MOTUs online?! :(
<ScottK> wallyweek: There are quite a number of MOTUs online.
<wallyweek> may I ask once again for reviews on http://revu.tauware.de/details.py?package=sdlmame
<wallyweek> ?
<ScottK> You can ask.  Online doesn't automatically translate into reviewing new packages.
<mok0> wallyweek: not a motu, but I can comment
<mok0> wallyweek: interested?
<wallyweek> mok0: of course, thanks! :)
<somerville32> TheMuso, are you talking about me?
<TheMuso> somerville32: no
<mok0> wallyweek: debian/control, Description: SDL ... etc... I don't understand what it means. Make it clear to non-nerd what this program does.
<mok0> wallyweek: further, the IMPORTANT LEGAL NOTICE stuff absolutely does not belong in a package description.
<wallyweek> ok, I'll fix the description asap... anything more?
<mok0> wallyweek: copyright ... I thought expat was James Clark
<wallyweek> mok0: I copied it from source... I assume expat copyright is well... right :)
<mok0> wallyweek: you'd think so :-)
<mok0> wallyweek: what's the TODO file doing in debian/?
<wallyweek> mok0: It's just a reminder for what should be good to do, I can remove it if you think so
<mok0> wallyweek: I do
<mok0> wallyweek: keep it somewhere else for your own reference
<wallyweek> mok0: zot! ;)
<persia> Hobbsee: Excellent.  Thanks for helping
<persia> LucidFox: After DIF there's no point syncing if Debian just merged our changes.  If Debian also has some good bugfixes, then it makes sense.
<mok0> wallyweek: what's the contrib dir doing? I don't see it being installed...
<mok0> ah
<mok0> examples
<wallyweek> mok0: it's just for tidiness... config files ; examples; manpages (which are not in upstream package)
<wallyweek> mok0: I could well put them in debian/ but I feel it would be much confusing
<mok0> wallyweek: ok, that's fine. Well with my minimal knowledgem it looks good!
<wallyweek> mok0: thanks for your help! :)
<mok0> wallyweek: It was mostly the Description:
<mok0> wallyweek: glad to help, I've gotten loads of help here myself
<wallyweek> mok0: description fixed... if I can collect more suggestion I'll make a single upload as package is *big*
<mok0> wallyweek: yeah, attention to detail...  :-P
<amarillion> Could somebody help me clarify a reviewers comment? I don't understand what persia meant with #5 here: http://revu.tauware.de/details.py?package=alex4
<amarillion> "5) Since youâre already patching the upstream makefile, do you really need all of that in debian/dirs? "
<persia> amarillion: Basically, debian/dirs should only contain those directories needed for package installation that are not already created by the upstream build system.  Since you are already carrying a patch for the Makefile, it may be as easy to extend that patch as to put them in debian/dirs.  Also, thanks for asking the question generally :)
<amarillion> And thanks for answering yourself anyway :)
<persia> amarillion: Additionally, that comment is more stylistic than anything.  All the created directories get populated, so it's not a reason for not approving the package.
<amarillion> but what you mean is that I could put a few mkdirs in the makefile?
<amarillion> to achieve the same effect?
<persia> amarillion: Well, I prefer install -d or install -D in preference to mkdir in an install rule in a Makefile, but yes.
<ScottK> amarillion: JFTR, I'd have argued the opposite.  Upstream isn't likely to want the dirs you're adding, so keep the upstream patching to a minimum and let the package management system do the work for you.
<amarillion> Yeah then I understand it now. But I just replaced all the install xxx lines with dh_install, so it seems a bit strange to start using dh_install on the one hand and stop using dh_installdirs on the other hand
<ScottK> Of course I'm not reviewing right now, so I'm not the one you'd have to satisfy.
<amarillion> As I understand it I have to satisfy at least two people :)
 * ScottK isn't reviewing for Hardy period, so is extremely unlikey to be one of the two.
<amarillion> Well, I'm not completely sure about that one... I addressed all the other problems though
<amarillion> Some of these comments could be checked automatically. e.g. problems in the .desktop file. Maybe you'd accept a patch for lintian for that?
<persia> ScottK: upstream wouldn't want /usr/games and /var/games?  These are the directories that are carried by the rest of the patches.  For /usr/share/*, I'm more inclined to agree with you.
<persia> amarillion: lintian found problems with the .desktop file :)
<amarillion> really?
<amarillion> How should I invoke lintian then?
<persia> amarillion: Run it against arch.changes after a binary build.  Also, as I said, I don't consider overuse of debian/dirs sufficient reason for non-advocation (and as ScottK said, this may not be overuse anyway)
<bddebian> lintian -i -I is always good :)
 * persia uses lintian -iIv
 * ScottK2 ponders a script to automatically capture the lintian output and create over-rides.
<pochu> ScottK: heh, that'd be a really useful one :)
<bddebian> heh
<amarillion> you're right. I'll have to alias lintian as well
<amarillion> They don't teach you these things in school :)
<wallyweek> one general question: I've just uploaded a new versione of sdlmame, should I comment it or could this prevent people reviewing it as it seems reviewed already?
<amarillion> wallyweek, I don't think it matters to add a comment
<persia> wallyweek: Only comments from reviewers adjust the "reviewed" status.  If there is meaningful information you wish to communicate regarding the changes in the package or some special exception, leave a comment.
<wallyweek> amarillion, persia: thanks! I'll leave some note as usual
<Frimost> hi, can someone resync the revu uploaders keyring, please?
<persia> Frimost: Sure.  Takes about 20 minutes.  Please try again then, as I may be away from my keyboard.
<wolfger> that sounds familiar :-)
<wallyweek> persia: do you think you could have a look at my package :D
<Frimost> persia: ok thanks
<wolfger> I finally did get my package up on REVU late last night. Anybody have time to help me figure out what I did wrong?
<persia> wallyweek: sdlmame?  I don't really have time right now.  If nobody else hits it before I have time again, I'll take a look.  Better to put out an advertisement generally.
<wallyweek> persia: ok thank you... I advertised it since this morning, but I had no replies. Of course I understand there's lot to do for reviewers, but it's quite frustrating :(
<somerville32> wallyweek, Make sure take a break and come back later :]
<wallyweek> somerville32: I'm going to bed in a while ;)
<amarillion> wallyweek, have you been working on that package for a year already?
<amarillion> The man pages are from february 2007
<wallyweek> amarillion: yeah
<amarillion> ouch...
<wallyweek> that's why it' so frustrating :(
<amarillion> Why are they in a debian/contrib subdirectory? I haven't seen that before
<wallyweek> I thought it was a good idea to keep them separate from upstream
<amarillion> Well everything in debian is already separate isn't it?
<amarillion> Not that I think it should be different, I'm just asking.
<mok0> amarillion: I've seen it a few times
<mok0> amarillion: it's ok not to clutter debian/
<wallyweek> it's just for tidiness IMHO... i know that everything but packaging stuff I have written is in debian/contrib/
<amarillion> ok, I see
<amarillion> I think your package is at the point of quality where I can't comment on it
<wallyweek> amarillion: I should take this good, should I? ;)
<amarillion> I won't pretend I'm an experienced reviewer
<amarillion> so it's not saying much...
<wallyweek> I don't think so... you probably know more than I do :$
<amarillion> Ok, I'll look a bit more :)
<wallyweek> nice!
<amarillion> Feel free to look at mine too: http://revu.tauware.de/details.py?package=alex4
<amarillion> wallyweek, after reviewing your package...
<amarillion> I've got comments for my own package
<amarillion> I should put my man page in section 6 too as it is a game as well
<amarillion> hehe
<wallyweek> amarillion: the only thing I see, manpage needs to make distinction from hyphens and minus signs (only 2 occurrences btw)
<amarillion> wallyweek, yeah, persia told me that before
<amarillion> but what does that mean exactly?
<mok0> amarillion: (not a motu) ... get rid of boilerplate comments at top of rules
<wallyweek> amarillion: hyphens separates words between lines and may cause some mess
<wallyweek> you need mostly minus sign (e.g. for options), and when you need a minus sign you should escape it with a backslash
<mok0> amarillion: in rules, make sensible comments instead of boilerplate, and get rid of commented dh_* lines
<amarillion> ok
<wallyweek> amarillion: just asking: alex4.ini shouldn't go in /etc/ ? It's config file, I presume
<amarillion> wallyweek, yeah I was unsure about that one
<amarillion> Should it then be in /etc/alex4.ini or /etc/alex4/alex4.ini?
<mok0> amarillion: in copyright, you need to include the full preample
<wallyweek> amarillion: /etc/alex4.ini IMHO, you need a subdir only when you have two or more config files
<mok0> wallyweek: agree
<amarillion> mok0, you mean the preamble of the GPL?
<mok0> amarillion: yes
<amarillion> I'll look at some other packages for examples
<mok0> look at the templates in /usr/share/debhelper/dh_make
<amarillion> Ok, thanks guys
<amarillion> looks like I have some work to do
<amarillion> but first: dlrrp
<amarillion> good night!
<mok0> amarillion: ... and when the MOTUs come back to work they will make you change everything again ;-)
<wallyweek> :)
<mok0> amarillions left hand was shifted 1 position: sleep -> dlrrp :-)
<mok0> known as qwerty encryption
<wallyweek> ...and I was looking for a new interner acronym... :)
<jdong> it even sounds like how I say "sleep" when it's really time to do that.
<wallyweek> jdong: and that's what I need indeed... ;)
<wallyweek> g'night everyone!
<persia> Frimost: Just in case you didn't notice already, the keyring sync is complete
 * persia goes away again
#ubuntu-motu 2008-01-15
<zorglu_> q. is there a way to make a .deb compress with .lzma or even better with 7z ? i asked because the .7z of the directory containing all the files of my .deb is 1.7mbyte. while the .deb is 3.2mbyte. this is almost double for .deb
 * RAOF thought lzma was the 7z compression scheme
<RAOF> zorglu_: Also, yes.  They're options to dpkg-deb, I believe.
<zorglu_> RAOF: it is. but .tar.7z takes more than .7z itself
<zorglu_> RAOF: aka .tar got a lot of overhead
<zorglu_> RA
<zorglu_> ok thanks will look
<StevenK> .tar has very overhead.
<RAOF> In particular, -Zlzma
<StevenK> Er, very little
<lifeless> its got a 512 byte block size
<schierbeck> i've got a problem building a package, is there some here willing to help me out?
<StevenK> lifeless: Point. The tar header is quite small, though.
<lifeless> sure; but stuff 100K 5-byte files in tar :)
<schierbeck> lifeless: oh, hi!
<lifeless> schierbeck: hi
<schierbeck> i'm trying hard to learn packaging, but i'm completely stuck
<schierbeck> when i call pbuilder build, as instructed in the packaging guide, i get 'configure: error: cannot find install-sh or install.sh in "." "./.." "./../.."'
<schierbeck> i can do ./configure and make just fine
<schierbeck> is that a common problem?
<zorglu_> pure7z=1705165, tar.gz=3170879(with gzip -9), tar.7z=2294475(top 7z compression)
<zorglu_> notice that pure7z is 1.7mbyte, while tar+lzma=2.3mbyte
<zorglu_> StevenK: this is the overhead im talking about
<lifeless> zorglu_: debs are not targs
<lifeless> zorglu_: they are ar's.
<zorglu_> of the same package. a normal .deb is 3.2mbyte :)
<lifeless> zorglu_: yes, we know, have you tried the -Zlzma option yet ?
<lifeless> schierbeck: no not a common problem
<zorglu_> lifeless: where should i put this option ?
<schierbeck> lifeless: i've been googling around for ages, and i can't fint a pattern
<lifeless> do you have a clean rule that removes it perhaps?
<schierbeck> lifeless: could be, i'll go check it out!
<RAOF> zorglu_: This depends on your pakcage's build system (debhelper? cdbs? anything else), but a simple check could be to simply unpack your existing deb and repack it with 'dpkg-deb --build -Zlzma <packagedir>'
<zorglu_> RAOF: worst i use epm :)
<schierbeck> lifeless: nope, it doesn't get deleted
<mok0> Is would be nice to have the newest lintian installed on REVU...
<zorglu_> RAOF: ok thanks for your help. now i know it is possible at least
<mok0> s/Is/It
<zorglu_> RAOF: doing it with epm seems non trivial as it hardcode the gzip :)
<zorglu_> snprintf(command, sizeof(command), EPM_GZIP " > %s", filename); <- bla :)
<zorglu_> https://wiki.ubuntu.com/dpkg-lzma <- already working on the matter, hey :)
<bddebian> Heya gang
<mok0> booring
 * bddebian dances around mok0
<mok0> yay
<mok0> bddebian, feel like reviewing?
<bddebian> mok0: What's the package?
<mok0> http://revu.ubuntuwire.com/details.py?package=gpp4
<mok0> bddebian: it's a library
<bddebian> Ugh :-)
<jdong> bluekuja: what do you think about the upgrade request for transmission? should we service it ourselves or wait for Debian?
<bddebian> mok0: Looking
<mok0> bddebian: cool
<jdong> bluekuja: eh what the heck, there's a get-orig-source rule anyway, I'll do it to shut up the boys on LP :)
<bddebian> mok0: Just out of curiosity, why do you call clean and distclean?
<mok0> bddebian: hmm, it's been a while since I wrote it, it may be redundant
<jdong> oh I am an idiot, it's in main.
<StevenK> imbrandon: Gah! apt-mirror is a compassionate parent and doesn't kill its children.
<imbrandon> heh
<StevenK> imbrandon: It ought to.
<imbrandon> if i wasent dead tired and litterly about to goto sleep in 10 minutes i would look to fix it, but as it stands i'll poke at it tomarrow
<StevenK> imbrandon: I have a patch already.
<imbrandon> ahh killer
<slicer> If you use debconf and have a variable called 'daemon_start', is it ok for the postinst script to rewrite /etc/default/packagename?
<StevenK> imbrandon: Anyway, it also doesn't lock.
<imbrandon> StevenK: what would it lock ?
<StevenK> imbrandon: If you start one apt-mirror, and then another, the second also tries to work, and they step all over each other.
<imbrandon> ahhh
<imbrandon> yea bad mojo
<imbrandon> never thought about that
<StevenK> imbrandon: Example: You have one running, and then cron fires off another -> Badness
<imbrandon> right
<StevenK> imbrandon: I'm investigating a patch for that, too.
<imbrandon> hrm it would have to lock per mirror
<imbrandon> because really it could be run with a diffrent config
<imbrandon> at the same time
<StevenK> imbrandon: Nah, don't do that, it's too hard.
<imbrandon> err per config, not per mirror
<imbrandon> hrm
<StevenK> A global "I'm running" lock.
<imbrandon> yea just check for a pid
<imbrandon> cool, i'm heading to bed, if you want email them to me, if not i'll be arround fairly early tomarrow
<minghua> Debian is finally starting to remove GNOME 1.x stuff.
<StevenK> \o/ Finally
<minghua> ... and obviously, the first reply is objection (to the procedure).
<minghua> :-/
<imbrandon> http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/bca2c92496161015
<slangasek> Debian has been working on removing GNOME 1.x stuff for some time
<slangasek> we're just now getting to the bottom of the stack, is all
<bddebian> Ugh level 1 deps are even ugly :-(
<ion_> imbrandon: Haha
<pochu> Good night folks
<mok0> bddebian: what do you mean?
<mok0> bddebian: thx for advocating. Without doubt you are right on the clean/distclean target, in fact I think distclean depends on clean
<mok0> Well 03:16am here, gotta go to bed
<mok0> g'night
<alex_mayorga> hi
<alex_mayorga> anyone knows if netbeans 6 is planned to be packaged?
<alex_mayorga> is it late already?
<LucidFox> We haven't hit feature freeze yet, so it's not late to have it packaged
<alex_mayorga> it's on debian already http://packages.debian.org/sid/contrib/netbeans-ide
<alex_mayorga> but I've never done a ubuntu package myself :S
<alex_mayorga> LucidFox, what should be the right way to go?
<LucidFox> first, check if a needs-packaging bug has been filed for it on Launchpad
<LucidFox> if it hasn't been, file it yourself
<LucidFox> "Current plan for NB 6.0 packaging"...
<LucidFox> It's underway.
<LucidFox> https://launchpad.net/~mslama-email <-- ask this person about the progress
<alex_mayorga> is there a bug files already?
<crimsun> Bah, too bad it build-deps sun-java5-jdk, which prevents a simple sync.  If it built with icedtea-java7-jdk, it could be merged.
<crimsun> it's also a good idea to ask in #ubuntu-java
<alex_mayorga> I'll look around
<LucidFox> Oh, so it's in Debian
<LucidFox> alex_mayorga> http://packages.qa.debian.org/n/netbeans-ide.html
<alex_mayorga> yup
<alex_mayorga> and sun-java6 is on hardy already if I'm not mistaken
<LucidFox> then all we'll need is to merge it from there
<LucidFox> yes, but there's the Dreaded Chroot Build Issue
<alex_mayorga> ???:-(
<LucidFox> Basically, packages depending on Sun's Java to build do not build in pbuilder - and if I'm not mistaken, in sbuild either.
<crimsun> correct
<LucidFox> Because it presents a debconf prompt to accept the license, and automated builds occur in noninteractive mode, which defaults to not accepting the license
<alex_mayorga> nothing lost on asking I guess
<alex_mayorga> just wondering given feisty had netbeans 5.5 and canonical and sun did the whole press release thingie for the previous release
<alex_mayorga> probably someone at canonical is already into it, dunno
<alex_mayorga> there's even https://edge.launchpad.net/netbeans6
<alex_mayorga> please forgive me if I'm babbling in the wrong channel or anything
<mwolson> it might be possible to build using icedtea-java7 instead of sun-java6
<LucidFox> alex_mayorga> That's the upstream page for netbeans6, not the Ubuntu package
<RAOF> LucidFox: But, IIRC, you can work around the Dreaded Chroot Build issue by writing a magic value somewhere in /etc.
<alex_mayorga> LucidFox, thanks
<bddebian> OK dumb question, how can I force a build with gcc-4.3?  Can't I use CC=gcc-4.3 ?
<RAOF> That *should* work, assuming autotools.  I think.
<crimsun> using what gcc-4.3 package in hardy?  :)
<RAOF> Ok, and assuming a gcc-4.3 binary :)
<bddebian> crimsun: OK you caught me, this is in sid :)
<crimsun> ;)
<bddebian> I have a patch for vodovod but I need to test it :(
<ScottK> bddebian: This Universe.  We don't actually test stuff here.
<ScottK> ;-)
<bddebian> heh, touche ;-P
<ScottK> slangasek: Thanks for the quick processing of NEW stuff today.
 * TheMuso grumbles at late mailing list email arrivals
<slangasek> ScottK: n/p, it was the day for it :)
<ScottK> slangasek: It's nice to requestsync something with a new binary on Saturday, have the request get ack'ed Monday AM, and out of binary new Monday PM.  Thanks again.  Great service.
<TheMuso> If anybody is around, I'd like a suggestion re bug 182700, where a patch is being applied. Originally, the contributor used cdbs to get simple-patchsys, even though the rules file was debhelper only, i.e all rules written out using dh_ calls etc.
<ubotu> Launchpad bug 182700 in sysinfo "Please sponsor sysinfo 0.7ubuntu3 (universe) into Hardy" [Wishlist,New] https://launchpad.net/bugs/182700
<TheMuso> I told him to not use cdbs just for patches, and look into something like dpatch
<TheMuso> this time, he seems to ahve probably gotten the code from simple-patchsys, but I haven't checked.
<TheMuso> I haven't checked whether it actually works yet, but I am wondering whether I should ask him to re-do it again, using a patch system such as dpatch or quilt
<TheMuso> The contributor also hasn't closed the bug in the changelog, and while I'm willing tl let that through with a comment about doing it next time, I still feel they could learn something by making use of a patch system, instead of putting in patch code by hand.
<bddebian> Grr, what is the g++ equivalent of CC=gcc-x.x ?
<TheMuso> bddebian: Run configure --help and that should tell you at the bottom of the output
<TheMuso> ./configure even
<TheMuso> From what I can remember, its CX
<TheMuso> CXX even
<StevenK> It's either CXX or CPP
<bddebian> CPP is C preprocessor isn't it?
<StevenK> Hrm, it could be.
<bddebian> Thank btw :-)
<bddebian> +s
<ScottK> TheMuso: I'd make him do it again with dpatch (dunno about quilt, I've managed to avoid it so far).
<StevenK> quilt is kinda fun, once you managed to get yourself in the right mindset
<StevenK> s/ged/ge/
<TheMuso> ScottK: Well there are other things that need addressing, so I don't have to worry about it so much for now, but, I'll probably let it slip this time, but I have encouraged the research of patch systems.
<TheMuso> ScottK: I didn't see your message until after I posted to the bug, but thanks for your thoughts.
<TheMuso> THis contributor is, well, I think, a little over eager.
<somerville32> He has almost as many uploads as me, lol
<somerville32> I guess I should stop slacking, lol
<TheMuso> somerville32: heh.
<ion_> Anyone feel like uploading http://revu.tauware.de/details.py?package=hardware-connected (it has been advocated twice)? Thanks :-)
<bddebian> Ugh, how the hell am I going to conditionally include auto_ptr.h if building with gcc-4.3?
<LucidFox> #if (__GNUC__ == 4) && (__GNUC_MINOR__ >= 3)
<StevenK> Eww
<TheMuso> heh
<ion_> That ignores the case where __GNUC__ > 4 ;-)
<LucidFox> #if (GNUC > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 3))
<LucidFox> s/(GNUC/(__GNUC__
 * StevenK quietly sobs
<TheMuso> Even more eww
<bddebian> Actually that's backward compatibility anyway isn't it?  I.E. the code should be updated?
<RAOF> It'll be an autoblargh build system, right?  Why not add such a check to configure.ac, where Satan indended such things to go?
<RAOF> Then you could have all sorts of fun with #if HAVE_AUTOPTR_H #include <auto_ptr.h> #endif
<LucidFox> Makes sense.
<somerville32> You could also pass the version to gcc with the -D flag :P
<RAOF> And there's some voodoo like AC_CHECK_HEADER(auto_ptr.h, bleargh)
<bddebian> Yuck to all :-)
<RAOF> bddebian: This is almost precisely the problem that autotools was written to solve (in the most impenetrable way possible).  But I'd imagine most upstreams would prefer you to test for the feature, rather than a specific compiler.
<bddebian> Aye, but in this case afaict, auto_ptr.h only comes with gcc-4.3 for backwards compatibility
<StevenK> You can't fix the code to work with both 4.2 and 4.3?
<bddebian> I'm not sure yet.  I've never seen auto_ptr() before :)
 * RAOF is confused.  So you only need to include auto_ptr.h on 4.3, but it's for backward-compatibility?
<bddebian> yes
<somerville32> soren, can you please take a look at bug #182445 - it is blocked pending your ACK
<RAOF> So it doesn't exist in < 4.3?
<ubotu> Launchpad bug 182445 in ebox-network "Sponsor ebox-network_0.9.3-0ubuntu4" [Wishlist,Confirmed] https://launchpad.net/bugs/182445
<bddebian> bdefreese@bddebian1:~/games_team/moagg/moagg-0.18$ find /usr/include/ -name auto_ptr.h
<bddebian> /usr/include/c++/4.3/backward/auto_ptr.h
<RAOF> Or you don't need it < 4.3?  Or it breaks stuff if you include it in < 4.3?
<bddebian> Well < 4.3 would FTBFS because the file doesn't exist :-)
<lifeless> RAOF: auto_ptr IIRC is one of the new TR-2 features
<RAOF> Right, so it only exists on 4.3, so you can AC_CHECK_HEADER(foo, blar)
<lifeless> RAOF: in boost you had to include a header to get it
<lifeless> RAOF: in TR-2 its part of another existing STL header, so you don't need the header.
<RAOF> Aaaaah.-
<RAOF> So auto_ptr.h is going to be essentially empty?
<RAOF> So that code that #include <auto_ptr.h> will still work?
<lifeless> so on 4.3 you don't include it (its built in), and on < 4.3 you need boost to get the header ;). AIUI, IIRC, caveat, caveat, caveat
<bddebian> On 4.3 is where I'm HAVING to include it
<RAOF> bddebian: Or else it fails to build with an error (pastebin)?
<bddebian> auto_prt is undefined
<bddebian> Err auto_ptr
<bddebian> Well that's not totally true
<RAOF> Right.  So it's in some other random STL header.
<bddebian> It actually barfs about being in std::auto_ptr()
<RAOF> Possible to pastebin the (probably huge) error?
<LucidFox> bddebian> Can't you add "using std::auto_ptr"?
<bddebian> There are several and I've been fixing them incrementally
<bddebian> LucidFox: Dunno, I don't do C++
<LucidFox> and #include <memory>
<bddebian> Well I don't do C either but that's a different story
<RAOF> LucidFox: That's where auto_ptr is?
<LucidFox> yes
<LucidFox> <auto_ptr.h> is not a standard header anyway, unlike <memory>
<RAOF> Right.  So, what you'd want to do is check for the presence of auto_ptr in libstdc++, and if it exists then #include <memory> and using std::auto_ptr
<bddebian> So just change: std::auto_ptr<Tiles> tiles(new Tiles());  to:  using std::auto_ptr<Tiles> tiles(new Tiles());  ??
<RAOF> Oh, no.
<LucidFox> eh, no
<LucidFox> leave that as is
<RAOF> Does #include <memory> appear, or help?
<bddebian> checking
<bddebian> Yep, just #including <memory> seems to work also.  Will that cause any issues on < 4.3?
<LucidFox> No.
<bddebian> sweet, thanks!
<LucidFox> It's a header from the C++ standard, so should work everywhere.
<RAOF> LucidFox: Yeah, but which standard? :P  I'm pretty sure some (really ancient) compilers will barf on it.
<LucidFox> Maybe, but Ubuntu doesn't include them. :)
<RAOF> And they probably don't support templates, either, which'll introduce other problems for that code :)
<bddebian> Anyway, bed time for this old man.  Thanks again gents!
<ScottK> persia: I'm getting no where fast understanding Sendmail's build system well enough to just build libmilter and the related -dev/dbg packages.  I'd really appreciate some help.
<ScottK> Now that bddebian's gone to bed, I get to be the old and incompetent one.
<ScottK> For the 5 minutes longer than him that I can manage to stay awake...
<ScottK> Good night all.
<somerville32> Hi Hobbsee
<LaserJock> quick question, how long does it usually take for a bug reported via email to show up on LP?
<StevenK> 5-10 minutes?
<LaserJock> hmm, ok
<LaserJock> I just tried my first one and it still hasn't shown up
<LaserJock> so I just wondered
<Hobbsee> hi somerville32
<Hobbsee> LaserJock: it probably died again
<LaserJock> the first time I tried it the email didn't seem to send
<LaserJock> but the second time it seemed like it sent it
<somerville32> LaserJock, Did you sign the e-mail? :P
<LaserJock> not sure
<LaserJock> do I have to?
<somerville32> yes
<LaserJock> hmm
<LaserJock> I think I did
<LaserJock> I just copy-n-pasted the output from requestsync
<LaserJock> I think that's enough
<TheMuso> Heya Hobbsee!
<Hobbsee> hey TheMuso!
<Hobbsee> LaserJock: you need to sign the mail.  requestsync stuff is usually signed, iirc.
<TheMuso> It is.
<LaserJock> it had the GPG garbage
<LaserJock> I've only ever signed email a couple times so I'm wasn't positive
<LaserJock> s/I'm/I/
<LaserJock> bah, that's why I so much prefer the web UI
<Hobbsee> heh
<LaserJock> and dislike BTS
<LaserJock> my first experience with BTS was waiting over 2hrs to get a response that it'd even received my email. I ended up dupping
<LaserJock> s/received/sent/
 * StevenK sighs.
<StevenK> Everytime LaserJock files a bug against Debian, must we also listen to another rant about how crap (apparently) the Debian BTS is?
<LaserJock> hehe
<LaserJock> I don't think it's crap
<LaserJock> in fact I think it's very nice
<StevenK> It isn't funny, I'm serious.
<LaserJock> it just needs to grow a web ui
<StevenK> It hasn't needed one before.
<Hobbsee> StevenK: just don't mention the launchpad.
<StevenK> PONI ... Oh, wait
<LaserJock> StevenK: well, sorry for the rant, it wasn't meant as one
<LaserJock> hmm, so 25 min without anything, should I assume it died?
<Hobbsee> LaserJock: er, are you sending a bug to the debian BTS, or launchpad via the web?
<LaserJock> launchpad via email
<Hobbsee> er, by email
<Hobbsee> then you probably should.
<Hobbsee> LaserJock: what was the request for?  i can just put it thru here
<somerville32> Should I add lintian ignores for warnings or just errors? (when appropriate)
<LaserJock> I can do it, I just thought I'd try out the email interface
<LaserJock> it's nice to not add any ignores, but I would think just errors if you have to
<somerville32> W: pysdm: desktop-command-not-in-package /usr/share/applications/pysdm.desktop gksudo
<somerville32> W: pysdm: script-not-executable ./usr/share/pysdm/pysdm.py
<LaserJock> hmm, I may have found the problem
<LaserJock> when I go to the email in my Sent folder evo says it doesn't have a valid signature
<LaserJock> so maybe my copy-n-paste signing was not a good idea
<somerville32> If I can remove a build-dep and it builds fine, it should be safe to remove it right?
<Hobbsee> LaserJock: i don't see why you need to c&p at all anyway
<Hobbsee> somerville32: er, yes, i think so, but does it need the corresponding package to run, which then neesd adding?
<LaserJock> Hobbsee: I'll just try it from requestsync directly next time
<somerville32> hmm
<SWAT> somerville32, it depends on which package it is. If it's the usb library or bluetooth, you might need it, but don't require it. So it will build, but you'll miss the functionality
<somerville32> It is  intltool
<somerville32> pysdm seems to build fine w/o it
<LaserJock> well, what does intltool do ...
<Hobbsee> oh, interesting, i didn't think it did that
<Hobbsee> LaserJock: openmpi just worked
<LaserJock> Hobbsee: I did that web ui
<LaserJock> finding another
 * Hobbsee dies at all the mail from u-a
<SWAT> Inbox zero
<somerville32> SWAT, hmm... it seems to automatically extracts translatable strings from oaf, glade, bonobo
<somerville32>  ui, nautilus theme and other XML files into the po files.
<somerville32> I think I need it
<somerville32> :)
<somerville32> po/Makefile.in calls it
<LaserJock> somerville32: good boy
<LaserJock> :-)
<LaserJock> hmm, seems lintian could use a sync
<dholbach> good morning
<man-di> does someone know when slytherin is normally here? Whats his timezone?
<huats> morning everyone
<ToyKeeper> ... if only it were morning here.  :)  I'm finally awake and it's time to sleep.
<\sh> moins
<slytherin> is anyone else having problem accessing build logs on launchpad?
 * Hobbsee hasn't been, why?
<\sh> hmm...debootstrap sid sid/ doesn't work?
<slytherin> for me the connection times out.
<\sh> well, the servers are up and running
<man-di> slytherin: hello
<slytherin> man-di: hi
<man-di> slytherin: did you got a response from Vincent about batik?
<slytherin> man-di: Actually I didn't mail him. It was late night for me yesterday and I have been busy with office work since morning. :-)
<man-di> ah
<man-di> I thought you already mailed him
<man-di> sorry for that misunderstanding
<slytherin> man-di: I will do it today.
<man-di> cool
<man-di> would be nice to be able to move batik to main/universe
<man-di> as some documentation people want to have a working free toolchain
<geser> good morning
<pochu> hey geser
<geser> Hi pochu
 * rulus updated his package yesterday (http://revu.tauware.de/details.py?package=gtkvd). If someone has time for a little review, that would be great :-)
 * Hobbsee ponders upgrading the lintian/linda on revu
<pochu> Hobbsee: please :)
<Hobbsee> mabye the linda too
<mok0> Hobbsee: Yes!!
<Hobbsee> er, why are backports enabled on this machine?
<Hobbsee> chug, chug, chug
 * Hobbsee actually applies the security updates, etc
<Hobbsee> StevenK: is there any reason why linda shouldn't be backported too?
<StevenK> Um
<Hobbsee> seeing as it's listed on revu, etc?
 * StevenK shrugs
<Hobbsee> StevenK: looks like there are some patches too that you might want
<Hobbsee> uh oh....
 * rzr updated http://revu.tauware.de/details.py?package=jaaa
<DaveMorris> I'm looking for a second revu of my package, available at - http://revu.tauware.de/details.py?package=libserial
<Hobbsee> right, so it appears that you can all view revu
<Hobbsee> siretart: ping
<\sh> StevenK, are you working on a new virtualbox upload to match kernel 2.6.24-X ?
<pochu> \sh: bug 156210
<ubotu> Launchpad bug 156210 in virtualbox-ose "Please sync virtualbox-ose 1.5.4-dfsg-1 from debian unstable" [Wishlist,Triaged] https://launchpad.net/bugs/156210
<\sh> ah
<\sh> didn't see that
 * siretart hides
<Hobbsee> siretart: don't worry
<siretart> what's up?
<Hobbsee> nothing, now
<siretart> k
<\sh> alleeHol, pingeling fai
<persia> ScottK-confused: Could you expand a little on which part of libmilter causes your condition?  Is it the pulling out, or the building separately?
<alleeHol> \sh: ah, right, yes.  My Dell Optiplex 755 are waiting too :(
<slytherin> geser: man-di: I was fool not to look lucene2 build log in detail. It is a connection issue encountered by one of the unit tests while validating an xml.
<persia> vemon: Feel free to grab bug #177679 if you like.  I'd like it for hardy, as it saves me trying to repackage timidity to support gstreamer-midi
<ubotu> Launchpad bug 177679 in ubuntu "[needs-packaging] WhySynth" [Wishlist,New] https://launchpad.net/bugs/177679
<\sh> alleeHol, I wanted to know what you pushed into the fai bzr on LP? ;)
<Seveas> alleeHol, optiplex 755 is nice
<Seveas> alleeHol, too bad the network card driver for it is missing from initramfs by default :)
<slytherin> hi all, if there is a connection issue which is causing FTBFS for lucene2, whom should I contact?
<Hobbsee> slytherin: is it trying to connect to the internet during build?
<slytherin> Hobbsee: yes, for validating an xml
<persia> slytherin: The DTD has to be installed by the dependencies, or not checked at build-time.  The former is preferred.  I suspect you'll find it in a package.
<Hobbsee> slytherin: you fix the package so it doesn't require net access to build.
<slytherin> Hobbsee: I guess that will need patch to source
<Hobbsee> probably
<Hobbsee> or forbid it from autosyncing
<slytherin> persia: the dtd is xhtml1-transitional.dtd, do you have any idea where I can find it?
<persia> slytherin: I think it's in w3-recs, but you'd want to check that.
<Ng> it's presumably also at the url in the xml file that's being validated?
<persia> Ng: Yes, but it's better to use a dependency than create yet another copy of a special document.  Also, the licensing for those is annoying.
<Ng> fair point :)
<slytherin> persia: it is in w3c-dtd-xhtml. I will create a patch accordingly
<persia> slytherin: And yes, this unfortunately keeps the package in multiverse, but at least it builds :)
<persia> slytherin: And thanks a lot for all your FTBFS efforts.  It's nice to see so many Java libraries becoming installable again.
<slytherin> persia: You are welcome. Java is my favourite. And I am happy I am able to contribute to Ubuntu. :-)
* persia changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com
<man-di> hmm, still not Java related group on http://qa.ubuntuwire.com for multidistrotools...
<persia> man-di: The filters still don't work, and the ubuntuwire multidistrotools maintainer is now on holiday.  If it makes you feel better, ruby and python are also still missing.
<man-di> persia: thanks for the info
<emgent> \sh, ping
<\sh> emgent, yepp
<pochu> I'm confused... do we need 2 acks for revu packages? The policy doesn't require it, but I understood REVU was a bit different... I'm happy to upload terminator as it's now, but I don't know whether I should wait for someone else to ack it.
 * Ng perks up :)
<persia> pochu: Two ACKs is encouraged, and expected.  We all make mistakes, but it is unlikely that two of us will make the same mistake or overlook the same problem.  Pushing too much tends to generate email from the archive admins complaining about the quality of reviews.
<pochu> persia: since you already reviewed it, are you happy with it? 'cos I am :)
<persia> pochu: I was fairly happy with a previous release.  I'll take another look in about an hour if nobody else has first.  I always do a full review when looking at a package again, as sometimes fixing one thing introduces or exposes another.
<pochu> Sure. Thank you.
<Ng> I'm happy to try and find another MOTU to look at it if necessary, I don't want to annoy you guys with excessive pestering :)
<pochu> persia: btw, looking at your REVU mail, I think it'd be useful if you put the programming language next to the package name.
<Hobbsee> persia: it's still 2 acks for MOTU's too, isn't it?
<persia> Hobbsee: Best practice, yes.  One can be the packager, of course.
<Hobbsee> persia: of course
<Hobbsee> persia: makes me wonder why falcon managed to get uploaded, though
<pochu> Hobbsee: one ACK is enough
<pochu> Hobbsee: https://wiki.ubuntu.com/MOTU/Council/Meetings/2007-02-23
<persia> Hobbsee: Raise it to the MOTU Meeting if you want to adjust it again.
<Hobbsee> persia: i don't really care sufficiently, as our MOTU's should be fine.
<Hobbsee> just its' a small lack of transparency
<persia> Hobbsee: I think that's the general point.  Sometimes there's a reason to just push, but I do see a lot of MOTU candidates on REVU early in the cycle, so I think the process works (although people might get jumpy as feature freeze approaches)
<persia> Hobbsee: Anyway, the archive admins get to review again, so even if someone makes a big mistake, there should be another pair of eyes.
<Hobbsee> true
<TheMuso> But the less work for the archive admins, the better IMO.
<persia> Yep.  We've already gotten two emalis from the archive-admins complaining about MOTU Reviews.  More would not be ideal.
<Ng> is it possible for a source package to produce binary packages in different components? (ie main and universe)
<Ng> I'm looking at rhythmbox and its uPnP plugin needs two python packages from universe, but it doesn't say that, it just fails to load the plugin
<geser> Ng: yes, and it happens already sometimes
<Ng> aha. I'm wondering if the plugin might be better off in universe so it can Depends on the right things and maybe be Recommends by rhythmbox itself
<geser> Ng: but the source package needs to be in main to produce debs for main (and also it's build-depends must be in main)
<Ng> which, fortunately, rhythmbox is :)
<sladen> Ng: if Rhythmbox doesn't *require* it for operation, it shouldn't be *Depends*
<Ng> sladen: I'm saying the plugin should Depends on the two python packages it requires. Whether or not rhythmbox should Recommends that plugin is a different matter (arguably it shouldn't)
<sladen> but Recommends is good, as it'll get installed if it's available, but not break horribly otherwise
<persia> Ng: If you think the plugins are useful enough to a large enough proportion of users, you might look into what would be required for MIRs for the build-dependencies.  It may be that whatever buggy, unsupported, security-problem-prone, or otherwise unsupportable issue has been addressed since the last review.
<sladen> Ng: yup
<Ng> persia: yeah I wondered about that too. I suspect that uPnP is going to become more and more useful. In the last 6 months I've acquired two consumer devices (ps3, n95) which now support it
<Ng> hmm, and after you follow the chain down, at least 4 python packages would need promoting to main :/
<Ng> configobj, ctypes, louie and coherence
<Ng> would anyone happen to know of a source package which puts binaries into main and universe, so I can poke around it?
<geser> Ng: ctypes? doesn't python2.5 already include it?
<persia> python2.5 does include ctypes.
<Ng> hmm
 * persia remembers a whole heap of FTBFS issues when that happened
<Hobbsee> Ng: kdenetwork
<Hobbsee> iirc
<Ng> Hobbsee: cool, thanks
<Hobbsee> Ng: kdepim also should
<siretart> Ng: xine-lib does so
<Hobbsee> Ng: what did you want to know?
<geser> Ng: gnupg2, the gnupg2 package is in universe while gpgsm and gnupg-agent are in main
<Ng> Hobbsee: how one would do such a thing :)
<Hobbsee> Ng: you don't.  the archive admins do.  as for how to get stuff into main, you file main inclusino reports
<Hobbsee> Ng: they have overrides there
<Hobbsee> it's not at the packaging level
<Ng> Hobbsee: ah. in this case it would be the other way around, it'd be part of rhythmbox (in main already) going into a separate package in universe
<pkern> dholbach: I need a gobby upload to be sponsored later.
<dholbach> pkern: you can attach the diff to the bug you filed about it and i'll be in the sponsoring queue
<mruiz> hi all
<Hobbsee> Ng: right, so then you're looking to split the package, of which there are many examples, and then asking an archive admin to send a package to universe.
<dholbach> pkern: I'll take a look at it then
<dholbach> hey mruiz
<Hobbsee> Ng: usually via a bug
<mruiz> hey dholbach ! :-)
<Ng> Hobbsee: thanks :)
<Hobbsee> Ng: you're welcome.
<pkern> dholbach: Thanks, will submit a diff in an hour, when I ate s.th. and booted my lappy.  Forgot to sync the branch to git.d.o. *narf*
<dholbach> pkern: great
<mruiz> What does mean the number after the responsible on http://people.ubuntu.com/~dholbach/sponsoring/ ?
<persia> mruiz: Number of days since it entered the sponsors queue.
<dholbach> number of days the subscription is old
<mruiz> persia: useful!
<mruiz> and the nickname with bold font?
<dholbach> mruiz: core-dev
<dholbach> in italics it's a team
<mruiz> :-)
 * persia notes that "Responsible" is really more "Interested" in the case of Needs-Packaging
<slytherin> persia: found an ugly bug in w3c-dtd-xhtml while trying to fix lucene2 build.
<pochu> dholbach: you should comment all that at the top of the page ;)
<persia> slytherin: Excellent
<dholbach> persia: should be fixed in one of the next runs
<persia> dholbach: Really?  Cool!
<dholbach> pochu: should be fixed in one of the next runs
<pochu> Great. I wondered the same thing the other day (what the numbers meant)
<slytherin> persia: The DTD has wrong paths for entity sets. it simply specifies file names, but files are in different directory. I will file a bug. But this also means that I can not use package w3c-dtd-xhtml (main) and I have to use w3-recs (multiverse). What do you suggest?
<persia> slytherin: I suggest you submit a patch to w3c-dtd-xhtml that allows you to build against it.
<slytherin> persia: hmm. that is tough task. and the package is in main. let's see.
<persia> slytherin: Is it not just changing some directory references?  Also, there are a number of main sponsors, and if your patch to fix the FTBFS has a note in the bug indicating that the w3c-dtd-xhtml package needs a patch first, it oughtn't be too long before it gets uploaded.
<slytherin> persia: Either change directory references or create symlinks. I will file a bug right away. So if someone picks it up before I start, well and good.
 * persia suspects this bug is less difficult than the others that have been being addressed with such regularity
<slytherin> persia: But is not difficult. There are various ways to fix it. SO I am a bit confused.
<persia> slytherin: How are you confused.  As to whether it would be better to move things, or to symlink?
<slytherin> persia: yes, move by changing rules or symlink.
<ScottK> Good morning all.
<ScottK> persia: The pulling out is easy, it's making a new set of rules to just build libmilter and friends that's got me confused.
<mruiz> good morning ScottK
<persia> ScottK: and friends?  I thought you just wanted ./libmilter/
<ScottK> persia: libmilter, libmilter-dev, and libmilter-dbg.
<ScottK> Heya mruiz.
<persia> Ah.  Right.  So, first you want an orig.tar.gz.  I'd recommend undoing the tarball-in-tarball approach, and using the upstream sendmail tarball.
<geser> ScottK: do you need a -dbg package? doesn't -dbgsym suffice?
<slytherin> ScottK: FYI ... I files a bug in debian for kdissert for use of dh_icons. The maintainer says he won't do it.
<ScottK> geser: The existing Sendmail package has one, so it'd be a regression not to provide it.
<persia> Then, you need a build system.  I'd recommend just replacing the upstream build system with something smaller, using pkg-create-dbgsym and dh_strip for -dbg, and splitting -dev with dh_install.
<ScottK> slytherin: That's all we can do.  It's not required in Debian.  Thanks for doing it.
<geser> slytherin: there was a "discussion" about inclusion of dh_icons into packages on the debian-devel-ML
 * persia downloads sendmail again to dig into generating -dbg
<ScottK> persia: Thanks.
 * ScottK wonders off to push children out the door to school.
 * persia grumbles that the point of using CDBS is for short debian/rules files that are easy to read, and not using CDBS might be better when that goal cannot be achieved.
<slytherin> persia: filed bug 183164
<ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,New] https://launchpad.net/bugs/183164
 * txwikinger2 is amused about the statement of easy to read and short rules files
<persia> ScottK: Looks like you just need to define DEB_DBG_PACKAGES = libmilter$(sm_libmilter_version)-dbg and DEB_DBG_PACKAGE_libmilter$(sm_libmilter_version) = libmilter$(sm_libmilter_version)-dbg if you want to keep using CDBS, or use `dh_strip -X libmilter-dbg` otherwise.
<persia> txwikinger2: If CDBS allows debian/rules to fit in less than 24 lines, it makes it really easy to read as that is a standard screen.  Even 48 isn't too bad.  A 595-line CDBS-based debian-rules file is just plain unreadable.
<txwikinger2> :)
<txwikinger2> Sounds like one of my fever dreams
<persia> slytherin: Is there a way to set a default search path for DTD validation, or does that have to be encoded in each DTD individually?
<slytherin> persia: I don't think it is possible.
<persia> slytherin: In that case, I suggest it makes sense to patch the DTD to use the correct relative path references to where the files are installed by the package (assuming the license permits this).
<geser> how does the syntax checker tool know where to find the dtd?
 * persia thinks there's some registration process, but isn't that familiar with the Ubuntu XML environment
<slytherin> geser: doctype includes path to DTD
<geser> slytherin: that's usually a url and not a path
<geser> and I doubt that we patch all files needing a dtd to find it on the harddisk
<slytherin> geser: One can give path of a local file.
<broonie> persia: there's catalogs in /etc/xml, see dh_installxmlcatalogs if you're using debhelper
<txwikinger2> This doctype url thing is stupid... doesn't work offline
<persia> broonie: Thanks for the explanation.
<slytherin> geser: I have no idea if any other package is failing for same reason. Ideally it shouldn't fail at all.
<persia> txwikinger2: That's why the DTDs are packaged :)
<txwikinger2> :)
<slytherin> persia: the copyright file of this package says that the license is GPL compatible.
<persia> slytherin: In that case, patch it...
 * persia tries to find problems with pochu's advocation
<pochu> That'll be hard, I hope :)
<persia> Ng.  Why does the revu orig tarball differ from the upstream tarball?
<persia> pochu: Can you tell me about pycompat please?  Why might it be needed or not needed?
<pochu> persia: it's generated by debian/rules clean. So you don't need to include it in the tarball, since it will be generated. But there's no harm in having it.
<persia> pochu: OK.  That's not enough then.  Now just waiting for a tarball explanantion...
<pkern> dholbach: How would you like it?  interdiff?  dsc?  http://dpaste.com/31122/
<Ng> persia: hmm, I'll check
<persia> pkern: It's just a normal update.  Submit a debdiff to a bug.
 * pochu didnt look at that
<pkern> persia: *cough*
 * pkern hates it that he cannot update his packages himself.
<persia> Ng: If they are basically the same, I can rebuild and retest with the upstream tarball, I just want to check.
<pkern> dholbach: diffed against the current Debian version that is.
<persia> pkern: Still a merge: just a debdiff.
<Ng> persia: they ought to be very very similar at least. I've not quite got my release workflow sorted ;)
<persia> Ng: Mind checking them?
<Ng> persia: not at all :)
<pkern> persia: debdiff of what?  last ubuntu vs. new?
<pkern> persia: And I really need to file a bug?
<persia> pkern: Debdiff against Debian, noting any Ubuntu variance.  Bugs are nice for tracking.
<pkern> persia: That was a diff against Debian.
<persia> pkern: Right.  Perfect format.  Just needs a bug (unless Daniel happens to want to grab it from dpaste)
 * pkern cheers git.
<\sh> moins pkern
<pkern> Hey \sh (:
<Hobbsee> pkern: what do you want updated?
<pkern> Hobbsee: gobby
<pkern> I'll merge the Ubuntu change back into Debian on the next upload, but don't know when that happens.  I first back Gobby to migrate to Lenny.
<Hobbsee> pkern: OK to drop all ubuntu changes?
<pkern> Hobbsee: http://dpaste.com/31122/ -- the only change left
<Hobbsee> pkern: got it. is there a bug open about it btw?
<pkern> Hobbsee: Just an invalid sync bug because I did not see the Ubuntu changes first (got not mail about that back then).
<Hobbsee> pkern: fair enough
<slytherin> persia: ran out of time for today. Will do it tomorrow. :-)
<Hobbsee> oh, sod.
<Hobbsee> it would help if i actually ran patch *without* --dry-run when i was finished testing it.
<amarillion> Do I have to send an email to the ubuntu motu list when I upload a package to REVU for the first time?
<Hobbsee> pkern: uploaded, thanks
<pkern> Hobbsee: Thanks a lot!
<Hobbsee> pkern: munged the maintainer while i was at it
<Hobbsee> whoops, uploaded the wrong one
 * Hobbsee uploads again
<Hobbsee> er, drat
<Hobbsee> third time lucky!
 * Hobbsee uploads the correct changes file with the original tarball too, for bonus points!
<persia> amarillion: No.  A MOTU does that when they upload to the archive.
 * persia gives Hobbsee a lucky bat
<pkern> Hobbsee: That was not really needed@munging.
<Hobbsee> pkern: this is true.  however, the way my build scripts work is they mangle by default, if it's not already mangled :)
<pkern> Hobbsee: I am the Debian maintainer and I care about the package in Ubuntu, albeit I cannot care directly because I'm just a MOTU and MOTUs are not responsible \-:
<Hobbsee> pkern: core, actually.
<Hobbsee> pkern: i'll try to remember next time to build your packages by hand.
<Ng> persia: oh, right. The difference is that I noticed some extra tab characters in the upstream ChangeLog file and removed them from the version in REVU. Would you prefer another upload of exactly the same as upstream?
<pkern> Hobbsee: Yeah.
<Ng> hmm, I did add a couple of words to the changelog too, but that is definitely the only file that changed
 * Ng makes a note not to fiddle with things once released
<persia> Ng: No point.  You happy with the upstream tarball?
<Ng> persia: yep :)
 * persia rebuilds with upstream tarball, and tests again
<persia> Ng: Did the Italian and Romanian translations get dropped, or is changelog just odd?
<Ng> persia: those were the couple of words that got added to the ChangeLog, I dropped those in right before I rolled the tarball because I noticed someone had done them with Launchpad, but didn't update the changelog. i then updated it and only then did a revu upload, but I obviously did it from my trunk branch instead of the 0.7 branch, which is why the two tarballs were different
<Ng> I'm happy to re-roll the upstream tarball, but I'm not sure if it's worth it - the important thing is that the translations are in it even if the changelog doesn't say so ;)
<\sh> brb
<persia> Ng: Ah.  That makes sense.  So Italian and Romanian will be in 0.8, and the changelog is now correct?
<persia> OK.  Silent translation addition is fine.  Let's stick with upstream: I was just confused by the change.
<Ng> ok :)
 * Ng will be more careful about using the right branch next time
<persia> pochu: Do you want to check again with the upstream tarball, or are you good?  Diff is: http://paste.ubuntu.com/3577/
<persia> pochu: You've lost your chance.
<\sh> emgent, looks ok...now the feisty one ;)
<Ng> persia: (and everyone else who checked it and helped me) thanks very very much!
<pkern> Hobbsee: Ubuntu Core Developers does not use Launchpad. This page was created on 2007-01-18  when the openoffice.org package was uploaded to Ubuntu. <-- /me giggles.
<persia> Ng: Now for complaints: 1) No easy way to reset the terminal when it's full of junk, 2) bad child handling when attempting to generate a 3x3 grid, 3) No documented means of opening a new instance.
<emgent> \sh, sure
<Ng> persia: 1 is certainly true. 3 I think is somewhat discoverable with the context menu, but maybe we need a toolbar or something. what do you mean with 2?
<Hobbsee> pkern: yeah.  iz bug.  :(
<Hobbsee> apparently forwards are hard to do, when the email keeps getting used.
<LucidFox> Gah... and everything went out of NEW _except_ for mpeg4ip. So ironic.
<pochu> Ng: congrats :)
 * Ng very pleased :D
<ScottK> Adri2000 or Lutin: Would one of you have a moment to discuss a DaD feature request?
<Lutin> ScottK: sure
<\sh> what about "insert into X rows the bug numbers and enter return to save, to see that X-1 bug numbers are not saved. please fix asap, kthxbye"  Those DaD Featues? ,-)
<ScottK> Lutin: I'm currently working on splitting the Debian sendmail package into two packages so that libmilter (without the rest of sendmail) can get promoted to Main.
<ScottK> Lutin: Would it be possible to customize DaD's treatment of my new libmilter package to look to sendmail in Debian for does it need to be merged, since that's where it actually comes from?
<ScottK> Lutin: Assuming I actually manage to get this into Hardy (haven't done it yet).
<Adri2000> ScottK: do you want DaD to just display it on the web page? or do you also want that DaD tries to actually do the merge? as they are different packages (even if parts are the same), I'm afraid of what the result would be
<bddebian> Heya gang
<Adri2000> \sh: please file a bug for that, bugs.launchpad.net/dad/+file-bug
<Adri2000> heya bddebian
<bddebian> Hi Adri2000
<Adri2000> \sh: https://bugs.launchpad.net/dad/+filebug even
<geser> Hi bddebian
<bddebian> Heya geser
<dholbach> Packaging 101 Session in #ubuntu-classroom in 12 minutes
 * Hobbsee ponders going there to play devil's advocate or something
<zul> evil
<Hobbsee> yes.  and?
<zul> no ands..
<pkern> Hobbsee: Advocate yada, please.
<pkern> Hobbsee: *eg*
<Hobbsee> dream on.
<pkern> !OP ABUSE
<ubotu> Sorry, I don't know anything about op abuse - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<pkern> Hobbsee: http://sinfest.net/comikaze/comics/2008-01-14.gif
<Hobbsee> !obabuse
<ubotu> Sorry, I don't know anything about obabuse - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<Hobbsee> !opabuse
<ubotu> leave the ops alone ktnxbye
<Hobbsee> heh :)
<nxvl> dholbach: did you know when will be the next CC meeting?
<dholbach> nxvl: no, I'm sorry, there's no agreement on a date yet
<nxvl> dholbach: mmm ok thnx
<DaveMorris> Can someone please provide a 2nd review of http://revu.tauware.de/details.py?package=libserial
<ScottK> Adri2000: It depends on how much of the original packaging I end up preserving.  If it's a total fork, then just display, but if my current approach works, then a merge ought to actually work.
<Mindfulgeek> Hello
<LucidFox> Mindfulgeek> Welcome
<Mindfulgeek> Thank you LucidFox
<Mindfulgeek> Did I miss the session?
<LucidFox> Mindfulgeek> What session?
<LucidFox> Packaging 101?
<Mindfulgeek> yeah
<LucidFox> It's underway on #ubuntu-classroom
<Mindfulgeek> ah.. thanks
<LucidFox> and here's the log so far: http://lucidfox.org/stuff/packaging101.txt
<Mindfulgeek> Thank you LucidFox
<ToyKeeper> LucidFox: thanks, I was just starting to look for a log.  :)
<jdong> aww poor vorian
<vorian> jdong: what?
<vorian> :P
<jdong> his watchfile for supertux is no longer good :)
<jdong> the SF mirror is not kept up to date
<vorian> bull crap
<jdong> and they added letters to the version
<jdong> 0.3.1d is the latest
 * vorian cries
 * jdong pats vorian 
<vorian> :)
<jdong> now to figure out how to get directory listings on berlios
<vorian> tried that, and passed them up after a while
<jdong> also, supertux 0.3.1 uses binary name supertux2
<jdong> who here cares a lot about supertux?
<jdong> I think supertux should not replace supertux-stable now that 0.3.1 can install side by side
<jdong> we should allow both to be installed
<jdong> there's a note on upstream's site too discouraging packagers from adopting supertux as the default one.
<vorian> hmmm
<jdong> I think we can scrape links from http://developer.berlios.de/project/showfiles.php?group_id=3467
<jdong> Newest version on remote site is 0.3.1d, local version is 0.3.0
<jdong> VICTORY IS MINE ;-)
<vorian> what was the regex jdong?
<jdong> opts=downloadurlmangle=s/prdownload/download/ \ http://developer.berlios.de/project/showfiles.php?group_id=3467 \ http://prdownload.berlios.de/supertux/supertux-([0-9].*)\.tar\.bz2 \ debian uupdate
<jdong> yeah berlios ain't pretty
<tkamppeter> Hi, I am Till Kamppeter, "Till Kamppeter" on Launchpad) and I have joined the "Contributors of packages for ubuntu universe" team, can someone resync the the REVU uploaders keyring, so that I can upload a new package? Thanks.
<vorian> demagler eh?
<vorian> mangler*
<jdong> vorian: yep.
<jdong> vorian: because of their nasty redirect thing for mirror selection
<vorian> nice jorb
<jdong> vorian: but it won't be that easy....
<jdong> vorian:need a lot of s/supertux/supertux2/
<jdong> GRUMBLE there's patches too
<jdong> globbed in the diff.gz
<\sh> damn...I'm working on merges, but we have a debianimportfreeze...still time to catch up with merges?
<ScottK> \sh: Absolutely.  DIF just means no more autosyncs and in theory everything should have been merged once this cycle by now.
<ScottK> \sh: You should feel absolutely feel to upload any merge you feel is worthwhile.
<\sh> ScottK, ok...so I'm still in time ;)
<\sh> hmm..whois  Marco Rodrigues <gothicx@sapo.pt> ?
<bddebian> Kmos
<\sh> oh damn
<\sh> Kmos, please don't mark sync bugs of mine....
<\sh> Kmos, it's not wishlist, it's needed for maemo (bug #182920 e.g.)
<ubotu> Launchpad bug 182920 in galculator "[MoM Sync] please sync galculator" [Wishlist,Confirmed] https://launchpad.net/bugs/182920
<geser> \sh: was told it often enough already to not touch (sync) bugs from MOTUs
 * DaveMorris forgot about classroom
<\sh> man...that spams my inbox for nothing
<ToyKeeper> DaveMorris: log is here: http://irclogs.ubuntu.com/2008/01/15/%23ubuntu-classroom.txt
<DaveMorris> thanks ToyKeeper
<DaveMorris> was busy working anyway today
<ToyKeeper> Hmm, the log is still missing the last half hour.
<ScottK> geser: You should know by now that telling him stuff has no long term effect.
<tkamppeter> Anyone here who can resync the the REVU uploaders keyring?
<geser> ScottK: unfortunately it's true and I'm already losing hope that he remembers it longer
<ScottK> geser: Which is fundamentally why I made the request I did.  If I had hope of progress, I'd have waited for the progress.
<jdong> vorian: mmmkay, now to test-build supertux and make sure I didn't make anything explode by removing the conflicts.
<vorian> you can do it :)
<jdong> vorian: pfft :P
<vorian> jdong: I was trying to be encouraging :)
<jdong> vorian: alright fine, if you're gonna FORCE me to play supertux....
<vorian> ha!
<jdong> "The My Little Sister Wants Newest Supertux NOW Release"
<geser> does somebody have an idea where I can find the last sync bug for libgcr410?
<dholbach> Ng, persia: seems that the tarball contained no license file? (infinity just told me)
<\sh> geser, hmm...under "closed bugs"?
<Ng> yeah, it had a symlink
<Ng> dholbach: I'll fix it and reupload when I get home
<\sh> geser, but there is nothing...
<geser> \sh: https://bugs.edge.launchpad.net/ubuntu/+source/libgcr410/ reports " All bugs ever reported   0"
<\sh> geser, yeah, because it was autosynced
<geser> that's why I wonder why it got synced (and it still FTBFS)
<geser> \sh: one hour ago?
<geser> 2.4.0-8 Published in hardy-release 1 hour ago
<\sh> geser, libgcr410 (2.4.0-8) unstable; urgency=low
<\sh>   * remove busy waiting timeout.
<\sh>   * remove useless ifdhandler.h (Closes: #420046)
<\sh>   * update pt_BR.po (Closes: #417251)
<\sh>  -- Marco Rodrigues < gothicx@sapo.pt>   Tue,  15 Jan 2008 15:27:54 +0000
<\sh> so yes
<geser> isn't the autosync off and any sync request should have a paper trail aka sync bug now?
<ScottK> SHould
<\sh> geser, yupp
<pochu> \should? :)
<\sh> -ESTRANGE
<\sh> geser, I asked on #u-d
<highvoltage> if I'd like to work on https://bugs.launchpad.net/ubuntu/+source/pyro/+bug/178948 , should I comment so on the bug report?
<ubotu> Launchpad bug 178948 in pyro "No init scripts for Pyro Event Server" [Wishlist,New]
<highvoltage> or can I just get going?
<jdong> cp: cannot stat `supertux.desktop': No such file or directory
<jdong> oh FFS the last step of a 10-minute build!
<geser> highvoltage: assign it to you
<highvoltage> geser: ok
<\sh> looks like Riddell was on sync tour..reading -changes
<geser> \sh: no harm was done with this sync but I'd like to know in this case why it got synced without testing that it builds by the submitter
<\sh> geser, yeah, but it would informational why it was synced in the first place without a paper
<geser> that too
<ScottK> Obviously it came from somewhere and got Kmos' name attached to it.
<\sh> cool...buddy is coming over to my place with a freecom nas to push openwrt on it ;)
<\sh> ScottK, but it is in debian, so that's ok...but coincidence ;)
<ScottK> \sh: No.  It's not.  That's who got assigned the sync in LP. debian/changelog in Debian has the maintainer
<ScottK> Riddell wouldn't have just randomly assigned it to him.
<\sh> ScottK, where did you find the sync bug  for this libfoo?
<ScottK2> I haven't yet
<ScottK2> But this is debian/changelog in Debian: http://packages.debian.org/changelogs/pool/main/libg/libgcr410/current/changelog
<ScottK2> For a sync, in LP, the name listed is who asked for the sync.
<ScottK2> !logs
<ubotu> Channel logs can be found at http://irclogs.ubuntu.com/ - Logs for LoCo channels are at http://logs.ubuntu-eu.org/freenode/ - See also Â« /msg ubotu ircstats Â»
<\sh> ScottK, you mean that changed by
<Ng> what happens if I dput something that's already archived in REVU?
<Ng> (with the same version number)
<nxvl_work> finally the packaging guide is browseable
<ScottK2> Yes.
<\sh> ScottK, ah...silly silly LP...I was sure it shows the original changelog
<nxvl_work> ScottK2: i mean that i have just putted "Next" and "Prev" links on the bottom of the pages
<LucidFox> By the way, is Riddell here?
<ScottK2> nxvl_work: Sorry,  I was talking to \sh.
<ScottK2> \sh: There's an LP bug open about that or something similar
<nxvl_work> ScottK2: oh! ok ok, sorry, i misunderstood it
<ScottK2> nxvl_work: Sorry,  I wasn't clear.
<ScottK2> \sh: I'm wget'ing this month's IRC logs right now to see if he asked for it on IRC.
<\sh> ScottK, thx
 * ScottK2 also notices that Kmos has filed a silly bug on the package in Debian.
<nxvl_work> ScottK2: really it was clear, i was lazy to read up :D
<mok0> Why is no debtags work carried out on our packages?
<geser> ScottK2: I couldn't find libgcr410 in my irc logs before this discussion right now
 * ScottK2 neither
<ScottK2> geser: I think the MC should make part of their Kmos work getting to the bottom of this.
<ScottK2> mok0: I don't think Ubuntu uses debtags.
<ScottK2> But I'm not sure.
<mok0> ScottK2: the debtags command is there, and seems to work
<ScottK> Kmos: How did your libgcr410 sync get initiated?  There is not bug for it.
<mok0> ScottK2: It's a really cool orthogonal way to index packages
<ScottK2> Dunno then mok0.  I haven't seen any use of it in Ubuntu and IIRC it's still pretty new for Debian.
<mok0> ScottK2: yes, I think so too, but if the system is to be useful, it is easier to tag packages when they enter the archive than at some later time. That's what I was thinking...
<LucidFox> Hmm, I thought Kmos was a MOTU...
<ScottK> !language | LucidFox
<ubotu> LucidFox: Please watch your language and topic to help keep this channel family friendly.
<ScottK> ;-)
<mok0> ScottK2: "debtags tagcat"
<ScottK> geser and \sh: Found it: https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/182963
<ubotu> Launchpad bug 182963 in pcsc-lite "Please sync pcsc-lite 1.4.99-1 (universe) from Debian unstable (main)" [Wishlist,Fix released]
<\sh> grmpf
<geser> ScottK: I guessed already it was mentioned in some other bug, but couldn't find it just by looking at the bug title which was a good candidate. Did you check all bugs?
<ScottK> geser: No, I searched for the package name in his "Fix Released" bugs.
<geser> ScottK: I tried the same for ~ubuntu-archive but I wasn't successful
<ScottK> I just added a task for libgcr410 to that bug so it'll show up in the future.
<geser> thanks
<tjaalton> RAOF: ping
<ScottK> geser: Also, libgcr410 FTBFS in my hardy pbuilder.  Clearly he didn't even test it before asking.
<tjaalton> RAOF: hmm, bad timezone it seems :) I was just wondering how nouveau is doing, but I'll just download and try it
<geser> ScottK: with the new pcsc-lite packages?
<geser> ScottK: as libgcr410 is on the FTBFS page I looked at the new libgcr410 version and it FTBFS for me so I got curious as I've seen it synced
<ScottK> geser: It's also FTBFS in Debian too.
<ScottK2> http://buildd.debian.org/fetch.cgi?pkg=libgcr410;ver=2.4.0-8;arch=amd64;stamp=1200188459
<ScottK2> So this is typical Kmos work.  Completely hopeless, without value, and distracting from getting something done.
<geser> and that one used the new pcsc-lite packages
<Kmos> ScottK2: I talk with debian maintainer about that.. he told me that it will be fixed if pcsc-lite was updated too..
<Kmos> debian bug 420046
<ubotu> Debian bug 420046 in libgcr410 "libgcr410: FTBFS: ./ifdhandler.h:115: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'IFDHCreateChannel'" [Serious,Open] http://bugs.debian.org/420046
<Kmos> i also reopened the bug, because i test it in pbuilder
<Kmos> check the conversation.
<ScottK2> Kmos: You're supposed to actually test stuff.
<geser> Kmos: pcsc-lite 1.4.99-1 or newer?
<ScottK2> The conversation is irrelevant.
<Kmos> geser: that one
<Kmos> geser: that was synced
<geser> Kmos: the debian build uses already libpcsclite1 (1.4.99-1) and still FTBFS
<geser> Kmos: who did you managed to get it build successfully?
<Kmos> geser: so that's a motive to re-open the bug, because debian maintainer closed it again after I reopen it, telling me that
<ScottK2> Kmos: How does any of this relate to you thinking a sync would fix things?
<Kmos> ScottK2: http://bugs.debian.org/420046 -> it's supposed to be fixed
<ScottK2> Kmos: So what.  You're supposed to test stuff before you ask for a sync.  What Debian BTS says is irrelevant.
<ScottK2> Kmos: It didn't even build in Debian.
<greg-g> where should I go to tell debian that we have an updated version of a lib in Hardy?  I submitted bugs about an issue, links to the updated upstream version (which fixes the bug), and just now a link to the new deb in Ubuntu.  The maintainer has not responded to any of them (I have not directly sent an email to him)
<Kmos> ScottK2: isn't debian BTS, i talk with the debian maintainer, it's supposed to be fixed, he told in bug report that's now working
<ScottK2> greg-g: That's about all you can do.
<geser> Kmos: and have you checked that?
<geser> that it builds now?
<ScottK2> Kmos: I say again: YOU are supposed to test stuff and clearly you didn't.
<ScottK2> What the Maintainer said or what's in BTS doesn't excuse you didn't test.
<greg-g> Thanks ScottK2, I just didn't want to be accused of not being good at debian/ubuntu relationships
<Kmos> ScottK2: I test.. check bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420046
<ubotu> Debian bug 420046 in libgcr410 "libgcr410: FTBFS: ./ifdhandler.h:115: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'IFDHCreateChannel'" [Serious,Open]
<Kmos> and see what debian maintainer said
<ScottK2> greg-g: You're welcome.  Going beyond that is being pushy, IMO.
<greg-g> ScottK2: got it, thanks
<ScottK2> Kmos: Yet you still asked for it synced.
<Kmos> ScottK2: after he told me in private mail, that it's because of pcsc-lite
<Kmos> not updated in hardy
<Kmos> so i ask for pcsc-lite sync and it should be working as he said..
<ScottK2> Kmos: Which is still irrelevant.
<Kmos> ScottK2: but ok, it's my fault to trust debian maintainer
<geser> Kmos: and have you checked in a pbuilder that it builds with an updated pcsc-lite?
<ScottK2> Kmos: Yes.
<Kmos> geser: nop, i trusted debian maintainer word.. because he tested it severall times
<ScottK2> Kmos: Ubuntu is a different environment than Debian.  Even if it had worked in Debian, it would still need testing in Ubuntu.
<ScottK2> Which is typical crap and excuses.
<Kmos> I already re-open the bug on debian to see what debian maintainer says about that
<geser> Kmos: see the many packages which fail in ubuntu but build in Debian because debian has bash as /bin/sh
<geser> because it works in debian, it must also work in Ubuntu (different lib, gcc, python, etc.)
<ScottK2> Kmos: You have a huge amount of energy to get stuff done.  I really wish you could find an area you can be productive in.  This isn't it.
<geser> s/must/hasn't/
<Kmos> geser: exactly.. but this one is a different problem.
<Kmos> ScottK2: maybe I'll take my time with fishing
<the_belgain> hi there - pbuilder is failing for me on a package after upgrading to hardy.  it's complaining that it can't satisfy build dependenvies because some of the dependencies are virtual packages (libfaad-dev, liblame-dev, and libtwolame-dev)
<jdong> ok, done and done, merry christmas everyone, new supertux and now supertux + supertux-stable can be installed together.
<jdong> vorian: ^^
<the_belgain> why would it complain about this?  this seemed to be working in my pbuilder on gutsy
<jdong> the_belgain: it's a known problem
<mok0> the_belgain: make sure you do a pbuilder update
<jdong> the_belgain: faad/faac and anything that depends on libmp4v2 are currently broken on Hardy
<jdong> the_belgain: there's two MOTU's, myself and superm1, working to rectify the situation
<the_belgain> ok, fine thanks - it doesn't look like there's anything wrong with my package then
<the_belgain> while i'm here, are there any known issues with pbuilder-dist on hardy at the moment? it ain't working for me
<the_belgain> looks like it picks up a corrupted /etc/apt/sources.list
<tsmithe> would there possibly be a debian developer around in here? i've got a package on mentors which is looking for some love.  mscore was recently uploaded to ubuntu, and i want to contribute back to debian. the version on mentors is an updated one, which includes usage of pasuspender to run the binary when pulseaudio is running.
<LucidFox> tsmithe> Same problem here
<tsmithe> problem?
<geser> the_belgain: corrupted /etc/apt/sources.list? how?
<LucidFox> I also have a package from Ubuntu on mentors... actually two, but the other one has problems
<tsmithe> ah :)
<ScottK> LucidFox and tsmithe: Are any of these packages written in Python?
<tsmithe> ScottK, sorry no
<LucidFox> no
<ScottK> OK.  There are Debian teams for Python stuff that are easy to get sponsoring in, that's why I asked.
<bddebian> They are?? ;-)
<nxvl_work> DD are evil
<ScottK> nxvl_work: Be nice.
<ScottK> Many/most of the senior Ubuntu developers are also DDs.
<LucidFox> ScottK> I looked at the Utnubu team, but judging by the state of their mailing lists, it's dead
<ScottK> Yes.
<bddebian> Yeah, that hasn't really taken off :(
<ScottK> Actually, I think it's work is largely done.
<ScottK> I think their main purpose was to get the Ubuntu patches pushed back into p.q.d.o.
<nxvl_work> scottK: those are nice
<ScottK> You might ask bddebian.  He's had a little luck getting stuff sponsored.
<bddebian> heh
<the_belgain> if any of the people who've taken a look at the fuppes package i uploaded a couple of days ago are interested, i've just uploaded an updated version with a few more markups
<geser> ScottK: perhaps we should all include debian in our nick :)
<ScottK> ;-)
<LucidFox> bddebian> So, please tell me about your luck getting stuff sponsored :)
<geser> LucidFox: try /nick LucidFoxDebian :) perhaps that helps
<LucidFox> lol
<geser> it seems to work for bddebian
<AndyP> easiest way to get sponsored in debian these days seems to be through teams, my experiences of debian python {modules,apps} team has been great
<ScottK2> Actually bddebian uses a different nick on Debian channels because he got sh!t about it there.
<LucidFox> I'll try the debian-multimedia team for smplayer, then
<bddebian> Well the python team seems helpful.  The Games Team, well....
<_MMA_> LucidFox: TheMuso might be a good person to chat with as he has contact with those guys.
<LucidFox> _MMA_> Thanks
<LucidFox> How do I unsubscribe u-u-s from a bug I filed?
<geser> LucidFox: ask an u-u-s member to do it
<LucidFox> DarkSun88> Fixed debdiff for qtemu
<mruiz> mathiaz, I read your comment about adtool and I uploaded a new debdiff
<rulus> .mo files should not be in the source package, but build when creating the binary package, right?
<slangasek> rulus: normally, yes; but it's usually not worth repacking the tarball over
<rulus> slangasek: what do you mean with repacking the tarball?
<slangasek> rulus: I mean that if upstream shipped .mo files in the tarball, you can address this in the ./debian/rules clean target without having to worry about repacking the tarball
<slangasek> rulus: if upstream didn't ship .mo files in the tarball, then any .mo files in your source package would end up in the .diff.gz, and .mo files aren't text so you'll get an error building the source package anyway :)
<rulus> slangasek: I'm the upstream developer, so ideally I put only the .po files in the tarball and create the .mo files with setup.py (it's a Python program)?
<slangasek> rulus: in that case, yes
<rulus> ok, thanks
<slangasek> but this channel is for Ubuntu development, not upstream development, so I assumed your question referred to the former :)
<rulus> I understand :-)
<subterrific> i'm trying to follow the instructions from https://wiki.ubuntu.com/SponsorshipProcess/ppaput but the bug doesn't seem to be getting updated after i run ppaput my-ppa -sa. so i'm not sure how i get the bug on the sponsorship list?
<ScottK> Uploading to PPA isn't an approved method of getting sponsored.
<ScottK> What kind of update do you have?
<ScottK> (that wiki page is experimental).
<subterrific> oh, well i tried the other process too, but it is marked as out of date
<ScottK> subterrific: Which?
<ScottK> What kind of update do you have (process is a bit different depending).
<subterrific> my update is a patch to the bash package that i found in launchpad to fix a bug i ran into while doing the motu class this morning
<subterrific> ScottK: https://wiki.ubuntu.com/SponsorshipProcess says to use http://people.ubuntu.com/~pitti/scripts/requestsponsor which is marked as out-of-date
 * ScottK looks
<subterrific> ScottK: basically there are these two tools that are supposed to automate the process, but neither work and i haven't been able to find any documentation on what exactly they do so i can just do it manually :)
<ScottK> subterrific: Make your new package, debdiff the old package to the new package, attach the debdiff to the bug, and subscribe ubuntu-main-sponsors (or ubuntu-universe-sponsors for Universe packages).
<subterrific> ScottK: thanks
<josesanch> If there is any MOTU bored. I offer my package for a review. http://revu.tauware.de/details.py?package=gnomecatalog
<nxvl_work> wow
<nxvl_work> http://www.chris-lamb.co.uk/2008/01/14/gnome-applet-for-monitoring-debian-bugs/
<nxvl_work> wouldn't it be nice to have such a thing for LP
<somerville32> nxvl_work, Probably wouldn't be hard to do now that there are atom feeds
<nxvl_work> somerville32: yep, i think that too, i will try it, check the code and try to adapt it
<TheMuso> ember: Yes re sysinfo, thats fine.
 * DaveMorri1 plugs his package for a revu - http://revu.tauware.de/details.py?package=opensg
<somerville32> mok0, Nice e-mail to -motu :)
<mok0> ;-)
<pochu> TheMuso: are you looking to bug 92939, or can I take care of it? You assigned it to you on December 12.
<ubotu> Launchpad bug 92939 in libowfat "Please sync libowfat 0.27-1 from Debian unstable (main)" [Unknown,Fix released] https://launchpad.net/bugs/92939
<mtp_> 5~
<_KeenEars_> hello anyone. can someone say, what`s happening in gutsy-backports now? i mean, kde4 miss some dependencies, although the files are in the pool, but it`s just not in relevant packages list
<_KeenEars_> maybe the update wasn`t finished yet?
<ScottK> _KeenEars_: For KDE, ask in #kubuntu-devel
<_KeenEars_> ok,thanx
<TheMuso> pochu: all yours
<subterrific> if i wanted to add a .pam_environment file to /etc/skel/ which package would i add that to? libpam-modules, bash, ???
<somerville32> interdiffs or .diff.gz for new upstream releases now?
<persia> somerville32: interdiffs.  The transition is under discussion, but not adopted.
<somerville32> I'm a little confused by the output of my interdiff
<persia> somerville32: The blob attached for sponsoring isn't human readable :)
<somerville32> persia, I'm looking at the human readable version
<persia> somerville32: Pastebin it.  What's confusing?
<somerville32> http://pastebin.com/d610ec953
<persia> tkamppeter: Resyncing keyring.
<nxvl_work> somerville32: what's the confusing part of that?
<somerville32> An interdiff is the the diff of the diff, right?
<nxvl_work> yep
<persia> somerville32: Right.  This one shows that the only packaging that changed was the .desktop file, which makes me suspect you forgot to add a changelog entry.
<somerville32> persia, It is just an excerpt
<slangasek> subterrific: I hope you're asking about this for local use, not for inclusion in Ubuntu?
<somerville32> In the orig, you modified the .desktop file in the package (you didn't use a packaging system) persia
<somerville32> In the new release, he incorporated your changes
<somerville32> This interdiff looks like it'll remove your changes persia and apply the old way to the new fixed one
 * persia is having difficulties parsing
<slangasek> subterrific: and if it's for local use, I'm not sure it matters which package you put it in, though conceptually I guess libpam-modules or libpam-runtime is probably as good as any
<nxvl_work> somerville32: what are you doing? a merge?
<somerville32> No, new upstream release
<nxvl_work> ok
<persia> somerville32: If I understand your issue correctly, it is correct for the diff to drop any patch that was adopted by upstream.
<somerville32> persia, correct
<somerville32> But it looks like the new diff is being modified so that it applies the old way from the first version unpatched
<persia> somerville32: I'd have to look at the whole thing, but I think that the "reverted" at the top indicates that that patch is being dropped.  If you want to be absolutely sure, follow the interdiff sponsoring process locally, and look at the results.
<somerville32> persia, awesome, thanks.
<\sh> guys, does anybody has a freecom fsg-3 w/o wlan appliance?
<RAOF> tjaalton: Bad timezone indeed.  Nouveau is going pretty well, at least for me.  My laptop screen now works with the randr12 code :)
<RAOF> tjaalton: Oh, and the drivers are quite snappy.
<tjaalton> RAOF: yeah I got it working on my desktop, once I linked the drm.ko in place
<tjaalton> too bad that the virtual console doesn't work yet
<RAOF> tjaalton: What exactly did you have to do?  I've only ever had to install it, and it Just Work.
<RAOF> s/./s./
<RAOF> It did for me (last time I tried) with the non-randr12 code.
<tjaalton> there was two drm.ko's installed, so I had to move the older one out of the way
<RAOF> tjaalton: Right.  You should have one in modules/extra, and one in somewhere else.
<tjaalton> the "official" one and the one in extra/
<tjaalton> yep
<RAOF> But I was under the impression that modprobe should be able to determine the correct one to load.  It does for me.
<tjaalton> btw, there's going to be a libdrm release soon
<tjaalton> hm, doesn't do that here
<RAOF> Maybe x86-64's modprobe is smarter?
<tjaalton> maybe, mine is i686
<tjaalton> RAOF: would you like to maintain it on git.debian.org?-)
<tjaalton> seems that the packaging is much like the rest of the drivers
<subterrific> slangasek: i'm actually working on a bug in launchpad
<subterrific> slangasek: which is asking for ~/bin to be added by default to PATH
<subterrific> slangasek: and according to the bug, that should be done inside ~/.pam_environment
<RAOF> tjaalton: Someone's asked whether I'd like to help get it into experimental.  I need to get back to them.  Yeah, I'll help maintain it on git.debian.org.
<subterrific> slangasek: so it would seem there needs to be a .pam_environent in /etc/skel/ no?
<RAOF> tjaalton: The packaging is taken very nearly verbatim from the nv driver :)
<tjaalton> RAOF: cool, then it would be a breeze to push it there
<_KeenEars_> got anothe question... will be main gutsy repo updated in future ? or it`s freezed for any additions ?
<RAOF> jdong: The think I wasn't sure about with pushing to experimental is the need for git snapshots of libdrm.
<slangasek> subterrific: uhm, that doesn't sound like the correct approach to me. what's the bug #?
<persia> !sru | _KeenEars_
<ubotu> _KeenEars_: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<persia> In summary, it's frozen except for critical bugfixes
<RAOF> Sorry, tjaalton ^^^
<subterrific> slangasek: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/64064
<ubotu> Launchpad bug 64064 in pam "would be nice to add ~/bin to the default PATH" [Wishlist,Confirmed]
<RAOF> tjaalton: But if libdrm is releasing soon, that'd be nice.
<tjaalton> RAOF: right, airlied said "in a few weeks" :P
<slangasek> subterrific: ok, I'll look that over
<\sh> bah...don't add it by default ;)
<_KeenEars_> well, ty. but thu updates will go to ubuntu-updates after all? not gutsy
<\sh> someone hacks into your box, which is obviously not root but some other user...and this guy can't overcome sudo
<\sh> he installs something into ~/bin and voila...
<\sh> other user == first user of the system who is sudo su - compatible
<slangasek> subterrific: ok, it says that it's *doable* on a per-user basis by editing ~/.pam_environment; not that the correct way to configure it as a system-wide default is to set it in ~/.pam_environment by default
<_KeenEars_> at least what i`ve get from that document
<slangasek> subterrific: and indeed, ~/.pam_environment is not the place to do it if this is to be made a system-wide default; if it's agreed that the change should be made, it ought to go to /etc/environment instead, I think
<persia> _KeenEars_: They go into the gutsy-updates repository, but the rules are still very strict.  You might be interested in backports
<subterrific> slangasek: well i've already attempted to solve the do-able part by fixing https://bugs.launchpad.net/ubuntu/+source/pam/+bug/145380
<ubotu> Launchpad bug 145380 in pam "pam_env should document per-user environment file ~/.pam_environment" [Wishlist,Confirmed]
<_KeenEars_> actually, i`m mirroring -backports, -proposed, -updates and - security at all
<_KeenEars_> but left base gutsy unchanged
<TheMuso> pochu: re accerciser, that sounds like an upstream problem.
<TheMuso> bug 183191
<ubotu> Launchpad bug 183191 in accerciser "Please sponsor accerciser 1.1.5 (universe) into Hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/183191
<subterrific> slangasek: and i don't think you can make the change in /etc/environment because $HOME might not be set yet
<subterrific> slangasek: and ~/bin is already in the default path, look at /etc/profile
<persia> TheMuso: Maybe upstream, but it would be a regression, no?
<TheMuso> persia: I don't know, as I hadn't seen what has happened with it previously.
<nxvl_work> is there any way to check what package generated a file?
<pochu> TheMuso: yeah, but I'm not comfortable uploading a broken application :)
<persia> nxvl_work: No, but which package installed a file is available from dpkg -S
<TheMuso> pochu: Fair enough.
<pochu> ember: you might want to forward that bug if you can reproduce it.
<\sh> subterrific, where is it set? on hardy is nothing to see about ~/bin in /etc/profile...
<subterrific> \sh: sry, i meant /etc/skel/.profile
<\sh> subterrific, but it's not set by default...because ~/bin doesn't exist by default in ~/
<\sh> subterrific, only if ~/bin is created then it's been appended to $PATH
<subterrific> \sh: seems default to me, checking if it exists first is an optimization only
<\sh> subterrific, no it's an important difference :) most users don't need ~/bin...there were several discussions about this and most of the sysadmins are saying "it's evil"
<persia> pochu: TheMuso: just tested.  Definitely a regression.
<Devourer> What is Masters of the Universe?
<pochu> persia: thanks. ember, could you forward it upstream?
<pochu> Devourer: us.
<pochu> !motu | Devourer
<subterrific> \sh: i agree it helps prevent people from shooting themselves in the foot, but as far as security i see little difference in having it in the PATH vs. added to the PATH only if it exists
<ubotu> Devourer: motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
 * persia notes that accerciser as currently distributing can be trivially frozen, but at least doesn't break from choosing "No".
<Devourer> Oh. Brave souls. :)
<nxvl_work> persia: thanx i found it :D
 * nxvl_work HUGS persia
<subterrific> \sh: the difference being: ~/.profile needs to be executed after your box is "hacked"
<\sh> subterrific, well, the good thing is, most people won't create ~/bin but I agree it should be removed from ~/.profile
<\sh> subterrific, well, that is easy....profile is there and user foo (1st user) is logging in..and executes e.g. sudo ,-)
<ScottK> Anyone want to do a merge to fix a CVE?  dspam could use a little merging love.
<\sh> hacker installs ~/bin/sudo which is the hacker tool now, and user foo is fcked :)
<subterrific> \sh: the reason i don't see it as a security concern is that once your account is compromised, a hacker can change your .profile anyway and add ~/.myhackbin/sudo to your path
<persia> (or just execute /tmp/superhacktool in the .profile directly
<subterrific> \sh: plus is it possible to override a /sbin with a /bin, i don't think it is
<subterrific> persia: i think the point was that the hacker needed some user input to complete the hack, like pretending to be sudo and logging your password
<Riddell> ScottK: assigned which to whom?
<Riddell> I may well have got the assignee wrong during a sync, it's easily enough done
<ScottK> Riddell: There was some confusion about a sync you processed.  It was Kmos.
<\sh> subterrific, this is all possible...but having ~/bin and the user foo knows about it, but doesn't look inside for some time, it's much more unsecure...
<ScottK> Riddell: The bug in question was Bug 182963
<ubotu> Launchpad bug 182963 in pcsc-lite "Please sync pcsc-lite 1.4.99-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/182963
<ScottK> It turns out the libgcr410 part of that request was untested and FTBFS after the sync.
<\sh> subterrific, but anyways...it's the job of the sysadmin to get rid of those things, agree :)
<Riddell> ScottK: meh fooey, he did ask me for it
<\sh> Riddell, no sync without a paper ,-)
<ScottK> Riddell: Yes.  Our collective finger is pointed straight at him.
<ScottK> \sh: We found the paper, it just wastn't completely filled out.
<\sh> ScottK, I know :)
<ScottK> K
<ScottK> Riddell: It's unfortunately typical of the quality level of a large fraction of his work.
<ScottK> Adri2000 and Lutin: I see that the MoM code is up on LP: https://code.launchpad.net/merge-o-matic (and GPL).  Any thought to contributing patches for a U/I overhaul?
<subterrific> \sh: so i just commented on the bug to try to get more feedback and i'll leave it at that for now
<Adri2000> ScottK: yes, this is planned
<ScottK> Adri2000: Great.
<ScottK> Adri2000: Any schedule?
<Adri2000> ScottK: nothing specific, but the sooner the best. also, when this is done, we will shutdown DaD
<Adri2000> ScottK: actually, we were waiting for the official announcement of MoM's code release, but seems you were quicker to find it than Keybuk to make the announcement :p
<ScottK> Heh.  He mentioned it on #ubuntu-devel, so I guess that's an announcement then.
<ScottK> ;-)
<Adri2000> ah, indeed :)
<\sh> ScottK, question, we have on mom a merge for claws-mail-extra-plugins 3.2.0 ... it needs claws-mail 3.2.0 should we try to include it into hardy?
<ScottK> \sh: I'd say yes.
<ScottK> But I don't use it, so ....
<\sh> ScottK, I#m just asking you, because you were the last one who touched it ,)
<\sh> ScottK, I use it so no problem testing it :)
<ScottK> Ah.
<ScottK> \sh: I just touched it to rebuild the clamav plugin for libclamav2/3 transition, so I've no strong opinion.  I'd love some testing with the new clamav though.
<\sh> ScottK, cool..I'll build the new claws stuff and do a functional test for myself...if it's ok I'll file a sync req for claws mail...
<ScottK> Great.
<emgent> hello there
<ScottK> Anyone looking for security experience might want to look at syslog-ng.
<somerville32> ScottK, Okay.
<ScottK> somerville32: The version in Hardy has a CVE fix that needs to be put in any of the released versions it's applicable to.
#ubuntu-motu 2008-01-16
<somerville32> ScottK, How soon should I have it finished? ie. Are you looking for someone to do it right now?
<ScottK> Sooner the better.
 * ScottK just noticed the security advisory for Debian being released.
<somerville32> link?
<ToyKeeper> somerville32: debian-security-announce@lists.debian.org
<ToyKeeper> Er, http://www.debian.org/security/
<Kmos> somerville32: http://www.debian.org/security/2008/dsa-1464
<somerville32> Kmos, 404
<Kmos> somerville32: not yet there..
<Kmos> only 1463
<Kmos> somerville32: http://lists.debian.org/debian-security-announce/debian-security-announce-2008/msg00022.html
<somerville32> Yea, I already found that, thanks
<Kmos> :)
<somerville32> is urgency always low?
<somerville32> Like, whats the point of it? :P
<\sh> ScottK, claws-mail 3.2.0 works like a charm...
<\sh> somerville32, debian needs it...security updates e.g. have a higher priority and the buildds and archives are working differently...+
<\sh> somerville32, #debian-security@oftc (or white when he's here) can elaborate on it...
<somerville32> Ok, test building for Gutsy
<somerville32> Should I file a bug for each release or just one big bug?
<emgent> keescook, ping :P
<somerville32> ScottK, ^^
<emgent> \sh, ping
<\sh> emgent, hi...saw your updates :) checking later today...:)
<emgent> cool ;)
<emgent> \sh, thanks^2
<\sh> I'm sitting here with a buddy and trying to flash a freecom fsg-3 appliace with linux :)
<emgent> heehhe ok ;)
<pochu> How does one compile a package with debug symbols? With "CFLAGS = -g -O0" ?
<crimsun> DEB_BUILD_OPTIONS=nostrip,debug
<pochu> crimsun: thanks
<ScottK> somerville32: One big bug
<somerville32> bug #183389
<ubotu> Launchpad bug 183389 in syslog-ng "[SECURITY] CVE-2007-6437 prone to denial of service attack" [Undecided,New] https://launchpad.net/bugs/183389
<somerville32> I had to reconfigure my gutsy pbuilder so I'm just doing the test build now
<somerville32> I have a debdiff for Gutsy
<ScottK> somerville32: Tasks for Gutsy/Feisty approved.  Does this not apply to the Dapper/Edgy versions?
<somerville32> The CVE does not say it affects 1.x
<somerville32> But I intend to look
<ScottK> OK.
<somerville32> ScottK, Feisty doesn't appear approved
<ScottK> Is now.
<somerville32> ScottK, Should I have the bug # in changelog? Is Launchpad smart enough to close the correct task?
<ScottK> somerville32: Yes it is and you should.
<somerville32> ScottK, Should I update the maintainer field if there were no previous ubuntu changes?
<ScottK> somerville32: In Feisty/Gutsy yes.  For earlier releases no.
<RAOF> Argh.  advi still hasn't lost its libungif dependency.
<RAOF> Lets see if it was rebuilt too soon...
<somerville32> ScottK, According to Debian's security announcement, 1.x isn't affected
<somerville32> "The old stable distribution (sarge) is not affected."
<somerville32> ScottK, However, the version in dapper and edgy is newer than Sarge
<bddebian> Heya gang
<somerville32> Hiya bddebian
<bddebian> Hi somerville32
<somerville32> ScottK, Dapper is not vulnerable it appears
<ScottK> somerville32: OK.  Nominate it for Edgy and I'll approve then.
<somerville32> ScottK, already did
 * ScottK hits refresh (again)
<ScottK> somerville32: Approved
<RAOF> For a no-changes rebuild you just add (or bump) the build<n> number, right?
<bddebian> Aye
<RAOF> Cool.  I'll just fix advi then.  It seems the last rebuild was too soon to actually do the libungif -> libgif transition.  A rebuild in my sbuilder fixes it.
<Hobbsee> \sh: you're kidding - he's doing that again is he?
<Hobbsee> after he promised about a month ago, that he wouldn't?
<LaserJock> Hobbsee: what?
<ScottK> Hobbsee: And we all know what that's worth.
<ScottK> LaserJock: Kmos messing with MOTU's sync request bugs after having been told specifically to leave them alone.
<LaserJock> that's what I thought
<LaserJock> he did 3 of mine last night
<Hobbsee> ScottK: it says that daniel is wrong, and that kmos is incapable of contributing.
<ScottK> Agreed.
<Hobbsee> ScottK: then again, it's already been proven that he remembers things for under an hour.
<Hobbsee> or can't reapply concepts, using actual thought.  either way.
<Hobbsee> what surprises me is how he's actually reasonably competent with picking up stuff that didn't build.
<LaserJock> although I wouldn't say it's that annoying to have him set wishlist I does create uneeded bugmail
<Hobbsee> as in, launchpad bugs.
<Hobbsee> LaserJock: i've had him revert my changes to bugs.  that's not annoying - that's incorrect
<somerville32> What was his rationale for disengaging from the agreement?
<Hobbsee> somerville32: didn't follow the listed process, apaparetnly - (confirmed vs triaged)
<Hobbsee> oh goody, he's even got a written warning in here.  and still he chooses to ignore it.
<bddebian> LaserJock: BTW, someone else pointed me to the Golden Pony.  Thanks! :-) Too funny.
<LaserJock> bddebian: ;-)
<somerville32> But what was his rationale for disengaging from the agreement he made? Why did he decide to do something that he promised not to?
<LaserJock> somerville32: I don't think he would agree that he's done anything wrong
<Hobbsee> somerville32: i'm not sure.  he never says.  he still appears to remember, just not apply the concepts that he's been taught.
<ScottK> LaserJock: This is just the way it goes with him.
<\sh> Hobbsee, when you mean that he confirmed and wishlisted all my sync bugs, so yes...and I never ever confirmed, wishlisted etc. my sync req in the past
<somerville32> Has anyone said to him: Here, do you see here where you said in writing that you wouldn't do this. See over here? This is where you just did it. Why did you do that?
<Hobbsee> somerville32: i suspect he's really eager, and wants to do good, without actually caring if his work is right or not.  He's also said that he doesn't feel he should get everything right, as he's not trying to go for MOTU
<Hobbsee> somerville32: good luck.  try when he comes on
<ScottK> The key thing is he's been told not to do stuff without checking during this evaluation period and he's routinely flouted that instruction.
<ScottK> somerville32: Again, and again, and again.
<Hobbsee> \sh: er, you need to confirm bugs - -archive ignores unconfirmed bugs, due to people's incompetence with requestsync.
<somerville32> What does he say? "Oops, I forgot?"
<Hobbsee> somerville32: he doesn't answer.
<Hobbsee> usually
<Hobbsee> somerville32: as soon as he hits a hard question, he doesn't answer.
<ScottK> somerville32: That or, "I thought because X (usually irrelevant fact) it was different.
<Hobbsee> oh yes, i had my own ammo to add to that page, too
<ScottK> Then when you corner him, it's as Hobbsee says
<slangasek> yes, I was about to point out that confirmed+wishlist is the right state (AIUI) if you want -archive to act on it...
<\sh> Hobbsee, ok...I dojn't use requestsync tool...and that I have to confirm those bugs, i didn't even know, because the other stuff was synced automatically by archive admin..but nevertheless...I think i have to confirm them but not others who didn't test the sync at all
<\sh> brb
<somerville32> So kmos went around and changed sync bugs from confirmed to triaged?
<Hobbsee> slangasek: wishlist.  bah humbug
<Hobbsee> somerville32: triaged back to confirmed.
<slangasek> Hobbsee: well - ok, I don't look at the severity either :-)
<LaserJock> he just set mine as wishlist
 * bddebian files some "wishlist" bugs
<slangasek> (but in principle, sync requests are wishlist bugs)
<Hobbsee> slangasek: oh of course.
<ScottK> slangasek: The point for Kmos is he's been specifically told on multiple occasions to leave sync bugs alone and he fails to list.
<somerville32> So, he didn't actually do anything wrong technically besides violate his agreement?
<ScottK> list/listen
<ScottK> somerville32: The wishlist stuff is not wrong, but un-needed.
<ScottK> He did ask for a sync that FTBFS and he never tested.
<slangasek> ScottK: I understand; I haven't even looked at the details of the current "parole" so I won't comment on that further
<ScottK> slangasek: No problem.
 * bddebian dances around the room
<somerville32> Has anyone checked to see if kmos had asked?
 * ScottK hides his eye
<ScottK> eye/eyes
 * Hobbsee adds ammo
<ScottK> somerville32: He's several dozen times past his last chance from me.  He defended his untested FTBFS sync today by saying he'd discussed it with the Debian maintainer who told him it would be fine.
<Hobbsee> somerville32: there's plenty of stuff he's done outright wrong.  see https://wiki.ubuntu.com/MOTU/Council/KmosReport
 * bddebian checks to see if he has a page
<ScottK> BTW, I haven't been looking for it myself (trying to avoid it actually), but he's unavoidable.
<zul> evening
<Hobbsee> ScottK: this comes from someone who believes that all ubuntu changes can automatically be dropped, due to it having a new debian maintainer.
<ScottK> bddebian: Debian has your page ;-)
<bddebian> ScottK: Haha, not shit eh?
<ScottK> Hobbsee: Of course, I forget.
<bddebian> s/not/no/
<\sh> back
<LaserJock> in any case, there's not much point discussing kmos as it's just a general downer
<somerville32> wow.
<Hobbsee> somerville32: asked what?
<Hobbsee> LaserJock: yes.  now, where's that report?
<somerville32> Hobbsee, for approval regarding the wishlist thing.
<Hobbsee> somerville32: no, of course not.
<\sh> slangasek, well, it's ok when we need to confirm the sync reqs, but please if I testbuild and make functional test with the stuff, noone else should work on the files bugs
<Hobbsee> that would require actually obeying his agreement.
<ScottK> slangasek: You may care to know that bugging developers and archive admins to do stuff (like he was doing to you yesterday) is also on his forbidden list.
<\sh> script fixed...no need that others have to confirm ;)
<LaserJock> Hobbsee: 3 -'s is a bit much
<slangasek> ScottK: hum, he's not been doing a very good job of adhering to that then :/
<ScottK> slangasek: No.
<Hobbsee> LaserJock: was meaning one from each of us.
<Hobbsee> LaserJock: seeing as he's done it to all of us
<LaserJock> yes, but they are minor infractions
<ScottK2> LaserJock: He's the death of a thousand cuts.
<LaserJock> sure, and that should show on the page
<zul> lemme guess Kmos right?
<LaserJock> but it doesn't help to get overly upset about minor things
<LaserJock> they should be noted but it's nothing to cry over
<ajmitch> zul: correct, everyone's favourite topic
<Hobbsee> zul: yeah.  who else is that incompetent?
<zul> ajmitch: heh
<Hobbsee> oh yay, there's actually a correct bug in here
<ajmitch> Hobbsee: I am, that's why I left
<somerville32> ajmitch, you left because of kmos?
<Hobbsee> ajmitch: smart move
<ajmitch> somerville32: no, just general atmosphere around here
<bddebian> :-(
<somerville32> That stinks
<LaserJock> I agree
<bddebian> Probably because of me :-)
<somerville32> I don't find it _that_ bad but I have a different perspective
<bddebian> Yes, #d-devel is sooo much nicer :-)
<somerville32> But I wonder how I can help improve the atmosphere personally :)
<Hobbsee> ajmitch: it should be better when people who don't follow what they agree to actually leave.
<StevenK> #debian-devel is mostly ari and helix spouting crap
<imbrandon> play WoW
<Hobbsee> at least, that's what i'm hoping
<bddebian> StevenK: Yep
 * ScottK2 finds there is a direct correlation between Kmos presence/activity and the level of negativity on the channel.
 * somerville32 tosses lavender about the room.
 * ScottK2 sneezes.
 * bddebian sneezes
<imbrandon> lol
<bddebian> hah, jinx
<ajmitch> Hobbsee: right, which is why when I felt like I'd be lynched for the slightest mistakes, I decided that I didn't really have much more to contribute
<ScottK2> bddebian: You are old and slow.
<bddebian> I know :(
<Hobbsee> ajmitch: you have to make a fair few before you even start getting lynched.
<Hobbsee> ajmitch: most people don't actually check all of a person's changes - only if they notice them to be wrong.
<somerville32> ScottK2, btw, I've finished the security stuff :)
<bddebian> I make shitloads of mistakes and I haven't gotten lynched yet. At least not that I know of..
<LaserJock> ScottK2: I can't honestly say I've seen that correlation, but I admit I'm not as active as I used to be
<bddebian> In fact I made the mistake of trying to help Debian...
 * bddebian hides
<somerville32> :D
<LaserJock> it's actually kinda more unsettling to see people go after somebody else, even if it's warranted
<ScottK> somerville32: Great.  Ping keescook Bug #183389
<ubotu> Launchpad bug 183389 in syslog-ng "[SECURITY] CVE-2007-6437 prone to denial of service attack" [High,Confirmed] https://launchpad.net/bugs/183389
<emgent> uhm
<LaserJock> we should be able to deal with things in a better way, IMHO
<somerville32> LaserJock, I agree.
<somerville32> I think we should all be happy :)
<Hobbsee> LaserJock: yeah.  kickboxing.
<ajmitch> I'm sure that whoever gets onto the MC in the next few weeks will make everything wonderful
<ScottK2> In general, I agree, but Kmos has done too much damage.
 * \sh 's happy...
<bddebian> \sh: :-)
<emgent> \sh, lol
 * bddebian is frustrated
<\sh> I just managed to break a freecom fsg-3 NAS
<LaserJock> bddebian: woot! REVU masta!
 * Hobbsee notes that no other business, school, workplace, or community would probably do this.
<\sh> ajmitch, well, I don't think it has a lot to do with the MC...it's more: well, if I confirm a bug, I actually tested it and agree that it's needed to be fixed...but if I didn't test what's in the bugreport I shouldn't put my hands on it
<slangasek> absolutely; if a bug isn't confirmed and you think it should be but haven't verified yourself, the most you ought to do is check with the submitter about whether it was overlooked...
<\sh> anyways, it's not nice to talk about a person when this person is not there, so we should end here and follow up this discussion during the day when kmos is awake...
<somerville32> \sh: But then Hobbsee isn't awake to participate :P
<\sh> somerville32, right, damn timezones :(
<Hobbsee> \sh:
 * somerville32 proposes we all get together for brunch sometime to discuss the issue. Say, my house?
<Hobbsee> \sh: not really so much point discussing with him here anyway.  he suddenly always happens to have lunch on, or have to go out, when anything complicated comes up.
<Hobbsee> it's very, very convenient.
<ScottK> JFTR, I've not said anything about him here that I haven't already said to him directly.
<somerville32> This is publicly logged channel anyhow. I wonder if he reads what we say about him when he is sleeping.
 * somerville32 ponders.
<\sh> ok ladies and gentlemen it's 3:32 UTC+1 here and I need to sleep a bit before my wife will wake up :)
<\sh> so cu in a couple of hours...
 * somerville32 waves.
<bddebian> Gnight \sh
<\sh> ScottK, claws-mail works and sync req filed (confirmed it actually;))
<somerville32> ScottK, Do you have any suggestions on how we can improve the atmosphere for that we don't lose more contributors like we did with ajmitch?
<somerville32> s/for/so
<Hobbsee> somerville32: he doesn't.
<Hobbsee> somerville32: therefore he can claim ignorance.
<ScottK> somerville32: Yeah.  Our leadership shouldn't bury their heads in the sand while someone causes hate and discontent in the hope that it will just go away.
<Hobbsee> somerville32: which means he doesn't have to respond to mail, as he repeatedly claims he hasn't seen it / is too busy / etc
<Hobbsee> somerville32: when suggested that he does less, and spends more time to get higher quality on the stuff that he is doing, he doesn't really respond, or gives a non-answer.
<\sh> somerville32, /ignore and filtering mail is helping sometimes...and if this doesn't help, a tie-up could also do some favours, when he is doing the merges/syncs/fixes all by himself ;)
<somerville32> lol
<\sh> but this will a bad day for universe
<\sh> anyways..now good night :)
<somerville32> Maybe we could have some community events or something to help build team skills and a tight sense of friendship :)
<ScottK> During Gutsy there were times when 3 or 4 MOTUs were working full time to nullify the bad stuff he was throwing at the sponsorship queue.
<_MMA_> ScottK: I also feel from watching hear, reading ML posts and talking to a good many people in Boston that there is no real system setup to manage situations like this.
<_MMA_> *here
<ScottK> _MMA_: Agreed.  This is the first time it's come up.
<LaserJock> well, there's really nothing we *can* do in this case
<LaserJock> it's a bit messy
<imbrandon> ugh, we're STILL talking about Kmos ?
<LaserJock> and frankly I just think we should move on, let the MC deal with it and get something done
<imbrandon> '/me goes to do something else for a while
<Hobbsee> \sh_away: you can't actually ignore and filter mail when he's actively breaking the archive.
 * ScottK is actually working on stuff while doing this, FYI.
<Hobbsee> somerville32: i suspect the problem would go away if the team felt that those who decided not to obey rules actually got something odne about them.
<_MMA_> LaserJock: I think the "leadership" ScottK mentions is the MC and nothings being done.
<LaserJock> _MMA_: umm ... a lot is being done
<LaserJock> but as far as having something to really take action with we're basically powerless
<ScottK> _MMA_: Been done.
<ScottK> There's at least hope. now.
<_MMA_> Ok. "Our leadership shouldn't bury their heads in the sand" Doesnt really elude to something being done. :P
<_MMA_> But sure, I trust ya. :)
<LaserJock> and I don't think that's a very accurate assessment either
<ScottK> LaserJock: Nothing got done for months.
<LaserJock> ScottK: and that proves "leadership burying their heads in the sand"? I think not
<ScottK> LaserJock: All I got were requests to give him time long after it was clear it was hopeless.
<ScottK> LaserJock: Nothing would be being done now if I hadn't quit listening to those requests.
<LaserJock> but you didn't email ubuntu-motu or motu-council for a long time
<LaserJock> it was basically dealt with by informal means
<LaserJock> which does not say anything for leadership burying their heads
<ScottK> Well there were no formal means and via informal means I was asked not to do anything.
<ScottK> I was told it would all be fine.
<LaserJock> formal means would be emailing -motu
<LaserJock> at the very least
<Hobbsee> LaserJock: no, it was a "we know we need to do something about this, we just don't know what to do yet, or don't want to"
<LaserJock> and being unhappy with the results of 1 or 2 people emailed in private is a fair cry from leadership burying their heads
<ScottK> LaserJock: What person in leadership here did anything about him except when forced?
<LaserJock> Hobbsee: but that is not ignoring the issue. It's perfectly legitimate for the MC to say we don't know what to do yet.
<LaserJock> ScottK: good question, I have *no* idea
<LaserJock> I have no idea who you talked to
<somerville32> Ok, time to stop talking about kmos :)
<Hobbsee> LaserJock: until they keep saying that, and don't try to find a solution.
<pochu> somerville32: Let's talk about you now ;-)
<LaserJock> because you don't like their solution
<somerville32> Ok!
<somerville32> How do you guys think I'm doing MOTU-wise? :)
<Hobbsee> LaserJock: it was decided that he needed to go at UDS.  it was another 2 full months later when it was also decided that he needed to go, but no progress was made as to how.  i call that them burying their heads in the sand.
<ScottK> LaserJock: They had no solution until I filed a complaint and it couldn't be avoided any longer.
 * ScottK isn't the MOTU warden and shouldn't have been forced to deal with it.
<LaserJock> no
<Hobbsee> LaserJock: at least now we have a rather damning report, but because it's got some +'s on it, it'll probably be shown as "he does some good stuff.  lets keep him, and keep monitoring"
<LaserJock> but the point of MC is to not play police either
<Hobbsee> LaserJock: why not?
<LaserJock> because that is not their charter
<LaserJock> it is a mediation charter
<ScottK> If someone is being disruptive, who's responsible?
<LaserJock> that means people have to bring complaints
<Hobbsee> if it's the only people that can kick people out for disobeying rules, then they automatically *have* to take up those reponsibilities.
<Hobbsee> ScottK: apparently, the MC is only there to mediate, and if that doesn't work, no one.
<lifeless> clearly the disruptive person is responsible
<LaserJock> Hobbsee: the CC is above the MC
<ScottK> LaserJock: That's clear now.  It's also clear that no matter what one has done, the MC will give additional chances, so there's no point in being slow to complain.
<LaserJock> ScottK: that's ridiculous
<LaserJock> establishing rule off of a *single* case is retarded
<Hobbsee> LaserJock: which shoves it back to the MC, yes.
<ScottK> LaserJock: It's the obvious consequence of the way this has been handled
<Hobbsee> LaserJock: we tried that one.
<Hobbsee> LaserJock: actually, it goes back to jono, who sends it back to daniel, who sends it to the MC.
<LaserJock> ok, so we should work on things, I have no doubt
<ScottK> LaserJock: When this was brought up, I tried to say it was a bad situation to make rules based on and the MC decided different.
<LaserJock> but the MC is not daniel
<LaserJock> and the CC is not jono
<LaserJock> and if you don't bring complaints to the team I don't think you can claim that they are ignoring the issue
<LaserJock> I wasn't aware that there was a problem until shortly before ScottKs email
<ScottK> LaserJock: There's no way they couldn't have known.
<LaserJock> and I don't think I'm *that* out of touch that there was a lot of things going on without my knowing
<Hobbsee> LaserJock: do you do the sponsorship queue?
<LaserJock> we always have people who make mistakes, and we should be tolerant in as much as we can while still retaining standards
<LaserJock> Hobbsee: yes, some, not as much anymore
<Hobbsee> LaserJock: it's just where people deliberately go and ignore the standards where the problem comes.
<LaserJock> there is no doubt that something needs to be done, and that things could have been addressed better
<LaserJock> but we've never had this problem
<LaserJock> and I think it's better for us to have a positive attitude and look at what we can be doing to make Universe and Ubuntu a better place
<bddebian> Gah, I gotta stop doing this Debian shit.  I just tried to build a revu package in my sid pbuilder.. :-(
<somerville32> LaserJock, +1
 * Hobbsee will have a more positive action once seeing that the MC is serious about getting rid of people who deliberately do not follow the proceedures required of them, of which they've agreed to.
<LaserJock> I really don't understand your statement
<LaserJock> 1) the MC has never shown itself to *not* take issues seriously
<LaserJock> 2) we can't kick people out of something they aren't in
<LaserJock> Kmos has no official standing so we can't really do anything but say we'd rather he not contribute
<ScottK> LaserJock: We can ask Launchpad to remove his ability to do Ubuntu related things.
<somerville32> Can we take kmos discussion to another channel, maybe #ubuntu-kmos_is_the_end_of_the_world or something? :)
<LaserJock> we could do that, although I'm not sure the MC can do that
<Hobbsee> ScottK: they say "let the CC handle that.  sounds like a person issue"
<Hobbsee> LaserJock: locking of LP account on ubuntu stuff would be enough
<Hobbsee> i think
<ScottK> Hobbsee: Exactly.  I've been told (by Jono) that MC has authority for that.
<pochu> somerville32: lol, have you registered it? I wanna be an op with supercowpowers!
<somerville32> :D
<LaserJock> Hobbsee: and that is basically what the MC has said they are willing to do
<ScottK> LaserJock: This is why I've said I'm hopeful action will finally be taken.
<Hobbsee> LaserJock: they are now, yes.
<LaserJock> so it would seem to me that the MC has acted fairly well with the issue
<LaserJock> the issue was raised by ScottK
<LaserJock> there was discussion
<LaserJock> a reasonable plan set forth
<LaserJock> and a nice wiki page to track things
<LaserJock> seems like quite a bit of action to me
 * ScottK thought the entire trial period was a waste of time and effort.
<ScottK> LaserJock: I count it action once he's stopped from making trouble.  The rest is just paperwork.
<LaserJock> that seems odd to me
<LaserJock> it should be all about transparency
<Hobbsee> LaserJock: just the amount of time that it took to actually get the action done.
<LaserJock> about having reasons and evidence for people
<LaserJock> Hobbsee: and that wasn't the fault of the MC
<Hobbsee> no?
<LaserJock> no
<ScottK> I think there's been plenty of transparency about all the trouble he's caused.  I think it was sufficient, without further warning, for him to be booted.
<LaserJock> show me where the MC was asked about the issue and they did nothing?
<Hobbsee> the MC had to decide what it wanted to do about the issue - how is it not then their fault for taking so long to come up with a plan?
<somerville32> When does the current probation period end?
<Hobbsee> somerville32: "mid jan"
<Hobbsee> somerville32: apparently they're doing a report at the moment.
<somerville32> We're mid January now
<somerville32> So the pain should be over soon
<Hobbsee> somerville32: however, it was worded as "give it 2 weeks, and we'll see", rather than "give ti 2 weeks, and we'll make a decision"
<LaserJock> Hobbsee: so long? it took 20 days to hear evidence and get the plan in place, that's not that long
<bddebian> Gawd, I so wanna do urbanterror but I can't deal with a 300Mb data package :(
<Hobbsee> LaserJock: the objection is surely between the "started creating trouble, and hearing complaints" and "concocted a plan"
<ScottK> LaserJock: I was told it would be taken care of after UDS.  Nothing happened, so I filed a complaint to force action.  I realize that was all in private, so in some respects doesn't count, but I don't count the time from my request, I count it from UDS.
<LaserJock> ScottK: right, but I do think  it matters
<ScottK> Which gets back to my earlier comment I made about having learned the lesson that trying to work things out without formal complaints.
<Hobbsee> even UDS it was still 2 months before they collected evidence, afaik
<LaserJock> well, this is an unusual case
<Hobbsee> which is how he got so far in the first place, yes
<LaserJock> ScottK: well, I was told at UDS Mt. View that we'd have a new TB in 2 weeks and we still don't
<LaserJock> we have a lot of issues
<Hobbsee> LaserJock: that's a process failure too, surely.
<LaserJock> of course it is
<LaserJock> but I think MC-bashing is not helpful
<LaserJock> especially when there was nothing sent to the list
<LaserJock> I agree it's frustrating
 * somerville32 wonders how this discussion is helpful at all. It is just rehashing the numerous bitch sessions we've already had.
<bddebian> Yeah, let's bitch about something else :-)
<LaserJock> somerville32: hmm, I always find it helpful :-)
<somerville32> LaserJock, I agree it is nice to get it out but it is taxing on other people who don't care.
<LaserJock> yes, that's true
<LaserJock> and if I were a new contributor and I just walked into the channel I would bolt
<somerville32> I'm personally disappointed too with the number of process failures but I'm wondering what we can do to actually accomplish something. Unfortunately, the powers that be don't read these backlogs to see whats up.
 * pochu doesn't care about the conversation whatever you talk about :P
<LaserJock> somerville32: what powers that be? *we* are the powers that be
 * bddebian has no power
<LaserJock> bddebian: of course you do, more than most and don't forget it
<LaserJock> ;p
<bddebian> heh
<Hobbsee> LaserJock: we have no power in view of the CC.  we only have power to whinge when it breaks.
<LaserJock> look, the level of power we have within our OS is fairly unprecedented for a project this size
<bddebian> tru dat
<LaserJock> we are a volunteer army of people who care about Ubuntu
<bddebian> Speak for yourself ;-P
<LaserJock> we give software to thousands and thousands of people
<bddebian> I just care about my karma ;-P
<LaserJock> and we can determine our future through our actions, our votes, and our words
<pochu> bddebian: lol, I want karma for uploads :)
<somerville32> LaserJock, +1
<bddebian> I probably have no karma anymore :(
<pochu> bddebian: you have negative karma!
<bddebian> Heh, probably
<somerville32> Karma is still messed up
<somerville32> Create a spec or two and you get about a thousand karma
<somerville32> Do a hards day work on bugs and you'll get maybe a hundred or two
<LaserJock> somerville32: yes, Marks says that will make people work on underutilized parts of LP
<LaserJock> *Mark
<somerville32> Plus, most of my karma from last year is gone
<somerville32> So I have 2k from non-ubuntu stuff now since I did a binge on my Sapidlib proejct
<somerville32> Although overall, I've contributed way more to Ubuntu
<pochu> Karma has 365 days of life, and every day it loses 1/365 of its value.
<pochu> err, 1/365 of the total value
<lifeless> lol@guesses
 * somerville32 tickles lifeless 
<somerville32> Well, I'm hungry. How about we order in?
 * pochu is off to bed, g'night
<dantalizing> so whats the naming policy for packages when you skip over an existing debian release...for example, gutsy release at 0.1-1ubuntu1, debian release at 0.2-1 and latest upstream is 0.3, what would my hardy version # be if I want to package 0.3??
<Hobbsee> 0.3-0ubuntu1
<bddebian> aye
<dantalizing> thx
<eradicus> what time will the motu school kick off?
<Hobbsee> jdong: has upstream complained about you being able to distribute 0.3 of supertux?
<Hobbsee> oh, they've changed what htey want again.  nvm.
<jdong> Hobbsee: no, but their wiki "suggests" vendors to ship the 0.3.x stuff in a separate package, which we already do.
<jdong> and I really wish they'd stop changing distribution sites so that watchfiles would actually serve a purpose :D
<somerville32> Heya jdong
<Hobbsee> jdong: hehe :)
<Hobbsee> jdong: last time i got in trouble for packaging the new version, because they'd retroactively put up a "please don't put this into distros" sign.
<jdong> Hobbsee: haha
<Hobbsee> i kid you not :)
<jdong> Hobbsee: well we've got supertux-stable now, and I just modified the two so that they can be installed side-by-side today, so I don't see any way upstream can yell at us :)
<jdong> (famous last words)
<Hobbsee> :)
<Hobbsee> yeah well
 * ScottK remembers.
<jdong> Hobbsee: mostly because my little sister wanted to play new supertux today ;-)
<Hobbsee> haha :)
<jdong> Hobbsee: she knows how to say debuild now... and she's 9.
<Hobbsee> scary.
<Hobbsee> taught her how to use prevu yet?
<jdong> hahaha no :)
<jdong> I should though
<DarkMageZ> jdong, wow. supertux's data is huge!
<jdong> DarkMageZ: the thing is 5x bigger since 0.3.x
<jdong> DarkMageZ: seems to mostly be ogg soundtracks though
<DarkMageZ> yeah. i'm grabbing 0.3.1d from hardy
<DarkMageZ> yay, more music ?
<jdong> yeah, the tracks are slightly less repetitive at a first glance.
<guest22_> Any MOTUs here willing to take a look at http://revu.tauware.de/details.py?package=photoml? This package has been through a number of revisions - technical issues were taken care of a while back, and the recent upload addresses some copyright statement problems.
 * ScottK is reviewing qtsmbstatus
<slangasek> that sounds... vertical.
<bddebian> What does horizontal sound like? :-)
<ScottK> slangasek: Looks like it might be a new way to tickle even more bugs out of samba.
<StevenK> By exposing QT bugs
 * StevenK runs
<bddebian> heh
<slangasek> "tickle bugs out of samba"?
<ScottK> Sure.  It's qt4.
<ScottK> It's late and I'm tired.
<ScottK> Try to get samba do to something in a different way so different 'interesting' things happen.
<slangasek> bddebian: horizontal sounds like a kernel
<slangasek> ScottK: I think we'll call those qtsmbstatus bugs :)
<bddebian> ah :)
<ScottK> Just like all the samba won't work with my Windows $whatever bugs are samba bugs.
<slangasek> yes, those are samba bugs
<ScottK> Fair enough then.
<ScottK> Uploaded.
 * ScottK will review qextserialport now.
<ScottK> That didn't take long to find a problem with.
<somerville32> :]
<ScottK> bddebian: You may want to take your advocacy off that one.  I think the watch file really ought to be fixed.
<bddebian> ScottK: Which one?
 * bddebian thinks the watch file push is BS anyway :)
<ScottK> bddebian: qextserialport
<ScottK> Maybe, but for sourceforge, if you are going to have one, you really want it to be in the right format.
<ScottK> bddebian: I've done updates of a number of perl modules recently and I found them really handy.
<bddebian> OK, removed
<ScottK> bddebian: But you're batting .500.  I advocated one of the two I looked at.
<bddebian> Hah, my average is picking up ;-)
<bddebian> Ugh, this headache is killing me, I'm going to bed.  Gnight folks
<somerville32> Night bddebian
 * somerville32 decides to upgrade qtorrent package.
<somerville32> http://thegraveyard.org/qtorrent.php shows the current version as 0.9.5 but version 2.9.1 is in the archive and uscan says the latest is 2.9.3
<somerville32> The website must be out of date
<somerville32> hi warp10
<warp10> Hi somerville32 :)
<somerville32> ScottK, since you're a member of the -server team, can you ACK bug #182445 please?
<ubotu> Launchpad bug 182445 in ebox-network "Sponsor ebox-network_0.9.3-0ubuntu4" [Wishlist,Confirmed] https://launchpad.net/bugs/182445
<somerville32> Oh wait
<somerville32> Soren already replied :)
<ScottK> somerville32: I'd suggest you talk to StevenK about that one.
<somerville32> ScottK, soren (who is the package maintainer) already said it was okay. Should I still seek StevenK's approval for such trivial changes?
<ScottK> No.
<ScottK> I was thinking of a different package.
 * ScottK is going to be soon anyway, so no time to review.
<ScottK> be/bed
<somerville32> okay
<somerville32> Luca already reviewed it, so you could get away with just uploading it ;]
<jdong> pull trigger first, think about boom later :)
<somerville32> indeed
<jdong> makes things go faster, but you need a grab bag of rationales :)
<jdong> I keep mine in tomboy notes ;-)
 * jdong pulls into hat and finds "It's an early alpha stage"
<somerville32> :)
<ScottK> somerville32: Luca should have uploaded it then.  Anything I'm going to upload, I'll review.
 * ScottK sends mail and crawls over in a corner to hide.
<ScottK> Good night all.
<somerville32> groovy
<Hobbsee> ScottK: yay!
<RAOF> Heh, that's a fun kwin4 bug.  Disable vsync, and it won't display anything but the mouse pointer :).
<StevenK> Bwaha
<RAOF> Furthermore... that's now set.  This might be the end of my kde4 exploration.
<Hobbsee> is feature, not bug :)
<RAOF> Hobbsee: Graphical effects so advanced, mere human eyes are unable to percieve them?
<StevenK> Right!
<StevenK> Look at those windows not exist in 3 dimensional space!
<RAOF> I was wondering why it seemed to be running so jerkilly, thought it was probably a symptom of nvidia's wonderful "the reported refresh rate should not bear any resemblence to the actual refresh rate" theorem.
 * RAOF is sure there was some terribly good reason for the kde team to write their own opengl compositing manager.
<StevenK> RAOF: See "[18:08] < Hobbsee> is feature, not bug :)" for the Nvidia refresh rate.
<RAOF> Yeah, that's what *they* say.
<Hobbsee> heh
<StevenK> Including the time and IRC nick? Neat.
<LucidFox> How do I set per-package build variables in CDBS?
<somerville32> [18:08] < Hobbsee> is definitely my favourite feature of all time
<LucidFox> I'm building two packages that differ only in the value of one automagic CDBS variable
<LucidFox> * two binary packages, from the same source one
<RAOF> This sounds like a recipie for frustration.
<StevenK> Indeed
<RAOF> Let's see if I can get kwin to give me an all-white screen under Xgl...
<somerville32> If there is a package in Debian and not in Ubuntu, do I just follow the normal sync procedure?
<slangasek> somerville32: except that you file the bug against ubuntu w/o a source package, yes
<RAOF> Yay!  kwin survives Xgl.
<wallyweek> g'morning!
<somerville32> Morning wallyweek
<josesanch> Hello. is there any problem with revu?
<wallyweek> I can't login to revu, it seems the server has gone :(
<wallyweek> anyone having the same problem?
<josesanch> yep, me too..
<Hobbsee> oh, again?
<wallyweek> in this very moment, I can't even access the main page :(
<somerville32> :(
 * Hobbsee didn't take it down this time
 * wallyweek feels victims of some kind of course and starts thinking sdlmame will mess hardy too :(
<josesanch> jejeje
 * somerville32 has trouble parsing wallweek's last.
 * wallyweek also thinks he's still fast asleep and types everything wrong :)
 * wallyweek feels a victim of some kind of evil curse and starts thinking sdlmame will miss hardy too
<somerville32> Nah, you got an entire month
<wallyweek> what's a month when you didn't do it in a whole year? :(
<josesanch> jeje
<somerville32> wallyweek, I'll help yo
<josesanch> how much time do we have? i thinked it was about two weeks
<somerville32> *you
<wallyweek> somerville32: featurfreeze is 14th february IIRC
<dholbach> good morning
<wallyweek> featurefreeze
<wallyweek> morning dholbach
<somerville32> hiya dholbach
<josesanch> ahh.. ok..
<dholbach> heya somerville32, wallyweek
<soren> pochu: Are you on amd64, by any chance?
<geser> good morning dholbach
<dholbach> hey geser
<dholbach> hey soren :)
<soren> dholbach: Good morning, Daniel :)
<dholbach> how's it going?
<soren> Rockin' as always :)
<highvoltage> morning dh	
<dholbach> bring it on! :)
<dholbach> morning highvoltage :)
<highvoltage> oops, lag :)
<LucidFox> Should I strip rpath from binaries depending on KDE4 libraries?
<wallyweek> any news on revu? it seems still down :(
 * siretart goes cycling sparky...
<somerville32> I think it is time to cycle _me_ :]
 * somerville32 heads off to bed
 * StevenK gets the cattle prod
<siretart> sparky is booting
<siretart> grr, hangs at "* Activating swapfile swap..."
<somerville32> siretart, Do you have another server to host revu?
<siretart> oh wait, it just took ages. revu is back :)
<somerville32> :)
<siretart> somerville32: well, the plan is to use spooky for that. however gutsy fails to boot from dm-raid from that machine :(
<somerville32> How much of a load is revu on a server?
<wallyweek> siretart: well done! thank you! :)
<siretart> somerville32: not much at all. an old sparc ultra 10 is able to handle the load without any problems
<wallyweek> siretart: can't comment my own package: connection timeout :(
<somerville32> revu seems to be down again?
<wallyweek> sommerville32: yeah, for me at least
 * wallyweek is glad he pasted his comment on notepad before clicking on submit :D
<siretart> no, its up again. I fiddled with the serial console and accidentally sent a 'break' over the serial line
<siretart> somerville32: if you are considering helping out with (hosting) revu, please join #ubuntuwire
<wallyweek> siretart: correct. comment addressed
<josesanch> If i use cdbs i have to use python in build-deb
<josesanch> ?
<somerville32> josesanch, using cdbs or debhelper wouldn't effect that
<wallyweek> somerville32: you said you could help me... could you have a look at http://revu.tauware.de/details.py?package=sdlmame <grin>?
<josesanch> somerville32: but a program that uses setup.py and is written in python has to build-dep in python. it isn't?
<somerville32> josesanch, yes
<josesanch> someville32: many thanks.
<somerville32> wallyweek, I will but I need to get some sleep for now :]
<wallyweek> ok, thanks and g'night! :)
<geser> dholbach: happy birthday
<dholbach> geser: thanks a lot! :-)
<TheMuso> c
<TheMuso> argh
<geser> Hi TheMuso
<TheMuso> Hey geser.
<LucidFox> TheMuso> I was advised to ask you about Debian sponsorship
<TheMuso> LucidFox: Debian sponsorship?
<TheMuso> LucidFox: I am not a Debian developer.
 * DaveMorris plugs his package for revu - http://revu.tauware.de/details.py?package=opensg It's an OSS distributed scenegraph API for doing some cool 3D graphics across multiple machines, I used it for a 46million pixel display.  It's cool so please revu it.
<persia> ScottK: re: milter.  If you can not depend, I like it just for less-stuff-in-main, never mind meaning no library split.
<LucidFox> persia> I've reuploaded smplayer-themes, addressed your and norsetto's comments
<persia> LucidFox: Great.  I'm not likely to review again until REVU day, but I suspect you'll at least get an advocation then if not an upload (of course, if someone has a particular interest, and reviews in advance, this increases the chances).
 * persia is glad to see the "didn't get enough review" list down to three packages, from twelve ~24 hours ago.
 * DaveMorris was surprised to see so many reviewed. TBH
<persia> dholbach: Are the current incumbents also up for reelection?
<dholbach> persia: I'd prefer if they re-applied
<persia> DaveMorris: We're getting close to Feature Freeze, so the pressure is on.  In just a little bit, the MOTUs will entirely ignore REVU for almost three months.
<dholbach> to make it explicit they stand for election
<persia> dholbach: That sounds like a very good idea indeed.  Let's hope there are more than five candidates.
 * pochu waves
<DaveMorris> So during Feature freeze the packages just stack up
<Hobbsee> dholbach: so everyone's getting revoted now?
<Hobbsee> neat
<DaveMorris> I assume your working on other packages during the freeze then
<pochu> soren: nope, x86
<dholbach> Hobbsee: no, I just said to persia that I'd prefer if people re-applied for the job to make it explicit they stand for election
<soren> pochu: Oh, well. I thought it might an amd64-only thing.
<persia> DaveMorris: The idea is that we have (roughly) four phases of development in each cycle.  First, we haul in everything that got missed for about six weeks, then we try to juggle it to be sane for about six weeks (that's where we are now), then there is about six weeks of bugfixing to make it releasable, followed by about six weeks including final release testing and polish, release, break, and UDS.
<Hobbsee> dholbach: i'm attempting to parse that into something i actually undersatnd, and i'm failing.
<dholbach> Hobbsee: there's no re-vote - people who wish to stand for election should reply to the mail I just sent
<geser> dholbach: as FF and UVF got merged into FF, does the motu-uvf work like before (exceptions for every new upstream version incl. minor versions updates) or on FF exceptions?
<persia> dholbach: Reply to the mail?  Now I'm confused.  I thought they were supposed to put their names on the wiki (which was a change from sending mail to MC members previously).
 * persia votes for motu-uvf handling both
<dholbach> Hobbsee: I'm not per-se expecting that people run again for the job
<Hobbsee> dholbach: oh...i thought you were talking about MC.  my mail was out of date.
<dholbach> oh ok
<dholbach> I was talking about UVF - persia: you too? :)
 * persia was also confused about which team was which
<DaveMorris> how many new packages are normally accepted through REVU?
<dholbach> geser: both - it's afaik what they did last time
<dholbach> Hobbsee, persia: is there anything else unclear now? /me hopes not :)
<persia> dholbach: Not at all.  Sorry for the noise.
<Hobbsee> dholbach: no, that makes more sense now
<dholbach> ok great
 * dholbach refuses to fully wake up today... so it might just be me :)
<geser> dholbach: denying that you got a year older doesn't help
 * persia suspects senility
 * dholbach had the pleasure of getting breakfast served in bed today - after that much convenience at the start of the day do you really expect me to be up to scratch already? :-)
<persia> Does anyone care about mldonkey in Edgy?  There's an SRU candidate about to exipire: if you want it, now is the time to test.
 * Hobbsee curses blinken
<LucidFox> TheMuso> Addressed issues with qdvdauthor
<TheMuso> LucidFox: ok thank
<TheMuso> thanks
<mok0> Hi
<emgent> hello pople
<persia> Does anyone know about zope3 and python2.5?  Is this impossible, or just undone?
<rulus> I have some questions about packaging translations. I understood that there should be no .mo files in the upstream release tarball, so I changed my setup.py to build the .mo files before installing. Now dpkg-source complains about 'binary file contents changed' regarding the .mo files when creating an Ubuntu package..?
<persia> rulus: Specifically there should ideally be no .mo files in the upstream tarball, but it is acceptable to delete them in the clean: rule, and leave them there.  As dpkg-buildpackage (often called as debuild) ignores file deletions, this doesn't do anything at packaging time, so you shouldn't get that.
<persia> rulus: I suspect when you call setup.py clean it's doing more than just cleaning.
<rulus> thanks, I'll check that out
<gaspa> persia: what do you mean? why should they not work together?
<persia> gaspa: The zope3 package only has python2.4 modules, not python2.5 modules.  I'm working on my longest outstanding bug (now with 35 duplicates), and I believe everything is now fixed upstream except that it requires python2.4 and builds against python2.5.  I'd rather bump zope3 than downgrade, unless there is some reason that zope3 doesn't want to bump.
<tjaalton> RAOF: ping
<persia> Note that I'm very much not a python person, and this package is an abberation, so I have no idea if I would break anything making zope3 use python2.5, and would not be a good person to construct a test case.
<gaspa> persia: i had one person that confirms me that zope3 works with python2.5. but he didn't install them from .debs.
<persia> gaspa: Are you someone who knows about things like python and zope?  Would you be willing to take a look at the zope3 package to determine if it could be modified to use python2.5?
<\sh> Kmos, please DO NOT TOUCH MY SYNC BUGS!
 * persia was surprised that the report wasn't ready for todays call, and really, really, really hopes it will be presented before the next call.
<emgent> \sh, lol
<gaspa> yes, i know _somthing_ about zope2... zope3 is completely different.
<\sh> emgent, nothing to lol about...it's important that kmos know
<persia> gaspa: Hmm.  I don't want to break anything else just to make a package that hasn't worked since Breezy work again.  Maybe I'll just force python2.4 for now.
<\sh> persia, afaik zope3 runs with py2.5 very nicely, problem here are the zope products, which are sometimes not know to work with py2.5
<Hobbsee> Kmos: ping
<\sh> emgent, sorry, i didn't want to sound to harsh...
<persia> \sh: Do you know if we package any of them?
<\sh> persia, there are some standalone zope product packages...I looked the last time at it, when I installed a zope3 server in my old company
<\sh> persia, feisty times
<emgent> \sh, but i remember that if someone like merge/sync is good talk _FIRST_ with original maintainer (in ubuntu)
<persia> \sh: Hmmm..  I suspect I shouldn't break those.
<pochu> Why, oh why, doesn't REVU remember my authenticated session across firefox sessions?
<gaspa> thoose could maintain dependencies on zope2.x
<\sh> emgent, well, we are four weeks before UVF and if we don't get all the merges ready for hardy, it will be sad..so therefore I think we can work on those without pinging the last uploader...only when there is something wich the merger doesn't understand
<persia> emgent: Especially at the beginning of a cycle, that is polite.  At this point, most syncs / merges come from security, QA, and DCT teams, rather than from the person handling the package for variance.
<emgent> persia, ++
<\sh> emgent, but this is not the case right now...when I request a sync, I have a reason not to confirm/wishlist them...wishlist is not needed, indeed it's more correct, but annoys when someone else is changing the bug without asking and without testing
<persia> pochu: REVU doesn't remember the authenticated session within a browser session, but it will remember the authentication if you start separate firefox sessions in quick succession.
<emgent> \sh, remember to sponsorizze my bugs :P
<\sh> persia, e.g. zope-sqlrelay (build-deps: Depends: python-sqlrelay (>= 1:0.38-3), zope2.9 | zope2.8 | zope)
<persia> \sh: I suspect most of your syncs are actually medium or high, as the ones I've seen tend to be security related.
<persia> \sh: That's not zope3, so doesn't matter as much.
<\sh> persia, oh I thought nowadays zope3 is default and is known zope -)
<geser> does the importance of a sync request has any influence when it gets processed?
<persia> geser: None at all.
<\sh> geser, I don't think so, or I feel like that...
<persia> \sh: Short list of rdepends is http://paste.ubuntu.com/3606/.  Do any of those look especially interesting?
<pochu> persia: would be nice if it was like, say, launchpad, where I don't have to login every now and then
<persia> pochu: branch, fix, and request a merge :)
<\sh> but as I said this morning, I don't confirm bugs or I set the importance of the bug without testing or knowing about the issue described in the bugreport, irrelevant if it's a real bug report or just a sync req...
<\sh> even as a sponsor I'm testbuilding and checking the packages ... so I'm sure that I don't sponsor broken stuff (which doesn't mean, that this never happend ,-))
<persia> \sh: bug status does matter.  Most archive admins only do syncs if they are Confirmed or Triaged (and random people setting this doesn't help keep it accurate)
<POX_> persia: isn't zope maintained by Debian/Ubuntu Zope Team ? Don't you think they should know it better and bump python to 2.5 if possible?
<\sh> persia, python-psycopgda is a postgres zope module...this could be important
<persia> POX_: I thought 2.4 was still default in Debian.  Has there been a push to move everything to 2.5?  (And yes, generally the Debian Maintainers know best)
<\sh> persia, today they are important...when we started they weren't :) but ok,but "confirming a bug" means, that the person who confirms the bug knows that nothing really serious breakage is happening
<POX_> 2.4 is default, but we have 2.5 as well
<POX_> 2.5 is not default yet because few modules are still missing
<\sh> Kmos, please talk publicly in the channel...not in private this matter needs to be discussed here
<Kmos> ok
<Kmos> I only changed your bugs to confirmed (and wishlist, but that on isn't important)
<Kmos> because I saw slangasek and riddell ignoring your sync requests because of that.
<\sh> Kmos, did you actually testbuild and testinstalled those packages?
<persia> POX_: Makes sense.  On the other hand, the person who originally pushed gaphor (depending on zope3) to 2.5 is an Uploader of zope3, so I'm seeing mixed messages.  I think I'll revert in gaphor, as it doesn't work in any supported environment (Well, sarge, but that's not well supported) rather than messing with zope3.  Thanks.
 * geser LOLs at the pypy build log where it paints ASCII mandelbrot fractals during build
<POX_> all I'm saying: there's "Debian/*Ubuntu* Zope Team" who would probably add python2.5 support if it would be that easy
<\sh> Kmos, do you really know that I didn't do any crap like your sync req for libgcr410 ?
<POX_> persia: ask doko_, he's in that team
<persia> POX_: Which is indeed an excellent point.
<Kmos> \sh: and I don't say that..
<persia> POX_: That's the person whose change I will be reverting.  Less impact to force gaphor to be 2.4 than to look into zope3, which I don't use, and otherwise know nothing about.
<\sh> Kmos, no with confirming the bug you know about the package...
<Kmos> \sh: Bugs subscribed to ubuntu-archive should be set to confirmed
<POX_> didn't look at gaphor, but can't it support both (2.4 and 2.5) ?
<persia> Kmos: No.  Bugs subscribed to ubuntu-archive should only be confirmed by a member of ~ubuntu-dev who has personally tested the package.
<Kmos> \sh: you subscribed it, i just try to help, because you said the "confirmed" thing doesn't matter.. but it does matter. for archive-admins to not ignore you
<\sh> Kmos, dude, I have 50 packages more to check, so don't you think it's easier to file the reports, and after 5 or 6 days to set the status with script to confirmed?
<persia> POX_: gaphor works great with 2.5, except that it can't load modules from zope3 because they aren't provided.
<\sh> Kmos, in this very moment, it doesn't matter to me, and neither is this a matter for the archive-admins, until I set them to "confirmed"
<POX_> oh, so gaphor has a dependency on zope, ok, sorry
<Kmos> \sh: ok.. sorry for the incovenient
<\sh> Kmos, anyways,please don't touch those sync reqs and leave the status changed for the guy who created the report...
<Kmos> \sh: i just saw them to be ignored.. and I see every comment in bug reports, saying the ubuntu changes can be droped, etc.
<persia> POX_: Yep.  CÃ©dric has been fighting with a rapidly changing upstream that frequently doesn't work for the past couple years, and finally has something working in sid.  Despite the sid modifications including the ability to build with 2.5, I'm reverting to make it sane (as the modifications don't hurt as long as default is still 2.4).
<Kmos> \sh: one more time, sorry for trying to help.
<Kmos> like I said yesterday, I think I'm going to didicate myself to phishing
<persia> Kmos: It's not about inconvenience, it's about the fact that just setting it without testing and confirming could lead to a sync that should not have occurred, possibly breaking things.
<\sh> Kmos, well, if there is a sync req it's obvious that ubuntu changes are dropping...the reasoning is more important...well, I'll add the changelog to the report...I think it's more clear then
<persia> POX_: Also, thanks a lot for chiming in.  Bouncing this off you has made me much more confident.
<Kmos> --- Log opened Tue Jan 15 22:05:21 2008
<Kmos> 22:05 <\sh> our requests were never ignored, forget the confirmed status...this is just for non-motus who are helping
<Kmos> \sh: so it needs "confirmed" status, but by the motu's / ubuntu-dev
<\sh> Kmos, yes, I was wrong nowadays..sorry.../me is old...I heard this morning steve explaining it...and now I confirm those bugs when they are needed
<Kmos> \sh: ah ok =)
<\sh> Kmos, but I don't confirm persias reqs or scottks or hobbsees, because I don't anything about their packages they work on...
 * \sh needs some nicotine...
<doko_> POX_: zope doesn't support python2.5 and later
<Kmos> \sh: ok.. i just see archive-admins ignoring them, them I talk to you in irc and you say it doesn't matter.. just tried to help on that, sorry again for that.
<persia> \sh: Given the completely random set of packages I touch, I suspect you are as likely to know about one of my bugs as anyone.
<Kmos> could someone check this - debian bug 460961
<ubotu> Debian bug 460961 in openbios-sparc "Why arch is not only sparc ?" [Wishlist,Open] http://bugs.debian.org/460961
<\sh> persia, that doesn't count...the thing is, e.g. yesterday with claws-mail-extra-plugins...I tested them locally and requested a sync for the new claws-mail, but I won't confirm the sync req for claws-mail-extra-plugins now, because I want to wait until the new claws-mail is hitting the archive, to be sure, that my pbuilder is not broken ,-)
<Kmos> the debian maintainer said it must me arch: all and not arch: sparc, because it only builds on sparc, but can be used on a non-sparc machine. something I don't understand here.. this package FTBFS in hardy.
<persia> Kmos: Because P-a-s takes care it, and this isn't the right forum to ask about Debian bugs, and it doesn't need origin-ubuntu hardy, as P-a-s also takes care of it in Ubuntu.
<Kmos> What's P-a-s ?
<persia> Kmos: The reason it should be arch-all is that once the bios is built, it can be used by emulators, etc. on other platforms.
<Kmos> isn't a debian bug, it's also a ubuntu bug, because it FTBFS.
<Hobbsee> Kmos: so, how are you following your "i will not modify sync requests of MOTU's" agreement, with \sh's bugs?
<Hobbsee> can you not do what you say?
<tjaalton> RAOF: I made some changes to your libdrm package, now it builds a linux-drm-modules package that includes all the modules
 * \sh is brb for 10 mins
<Hobbsee> Kmos: or laserjocks
<persia> Kmos: It's not FTBFS in Debian.  It's only FTBFS in Ubuntu because we don't support building arch-all on non-i386.  It requires manual bootstrapping in Ubuntu by a buildd admin to work.
<Kmos> persia: ah! i didn't know that.. thanks
<persia> Kmos: Might make sense to ask before spamming the BTS, no?
<Kmos> persia: right
 * persia grumbles that wiki.ubuntu.com is currently slow
 * Kmos http://wiki.ubuntu.com/MOTU/Council/KmosReport
<Kmos> please write..
<persia> Kmos: I will.  I'm not sure yet if it is '0' or '-'.
<Kmos> persia: I think about \sh's should be -
<Hobbsee> Kmos: were you going to answer my question?
<Kmos> Hobbsee: you're true. it's done?
<Hobbsee> \sh's already has 3 -'s against it, as you would have seen, if you'd looked.
<Hobbsee> Kmos: you said you wouldn't do that.  then you did.  how can any of us trust what you say?
<Kmos> Hobbsee: if i can open the wiki =)
<Kmos> Hobbsee: if you see, are different cases.. so you can't apply one rule to all of them.
<Hobbsee> Kmos: what did you agree not to do?
<Kmos> Hobbsee: i agree to not touch bugs, i already know that.. but in that case, I saw archive-admins ignoring it, and it two days.. so I learn the comment and set it to confirmed.
<Hobbsee> Kmos: you agreed to not touch sync request bugs from MOTU's.  How is your modifying \sh's bugs different?
<Hobbsee> Kmos: and why laserjock's?
<Hobbsee> Kmos: they were set to confirmed.  You agreed not to touch them.  you did anyway.
<Kmos> Hobbsee: laserjock, only changed it to wishlist
<Hobbsee> yes, but why?
<Kmos> to move up in the list
<Hobbsee> Kmos: you agreed not to touch them AT ALL!
<Kmos> archive-admins also don't have done backports in the last two days, and that syncs are in the bottom of the list
<Kmos> Hobbsee: yes, I know.. i just explained what, and why I did
<Hobbsee> Kmos: does it occur to you that not all things are time sensitive, and that in some cases, it's better to leave things alone?
<Kmos> Hobbsee: it's ok for you now ?
<Hobbsee> especially if you've agreed to do so?
<Hobbsee> Kmos: no, it's not OK.  you said you wouldn't touch them, then you did.
<Kmos> don't need to remember that
<persia> Kmos: After investigation, openbios-sparc gets a '-' for no Ubuntu bug.
<Hobbsee> Kmos: you *do* need to remember it.
<Kmos> persia: thanks
<Kmos> Hobbsee: I think I need.. and I like to thank you about that
<persia> Kmos: Please open the corresponding Ubuntu bug, reporting the reason for the FTBFS, and the actions required to resolve it.
<Kmos> I think I won't forget it.. even if the sync or bug don't never get into archive if it's important or not
 * pochu notices he can now approve and decline universe tasks :)
<\sh> Kmos, how do you know it's important?
<Hobbsee> Kmos: so, which types of sync bugs filed by MOTU's can you touch?
<pochu> If a bug has been fixed in Hardy, and is also nominated to be fixed in Hardy, what should I do? Approve it and mark it as fixed, or decline it?
<Kmos> Hobbsee: none
<Hobbsee> Kmos: good.
<Hobbsee> Kmos: hwo did you not understand that last time?
<Kmos> \sh: syncs are generally important.. and only archive-admins can do it.
<persia> pochu: If you approve it, it should automatically have the hardy task marked as "Fix Released" and a note "Status tracked in hardy".  I generally approve those to avoid confusion.
<Hobbsee> Kmos: still, you said that you wouldn't do this last time.  and now you have.
<pochu> Kmos: this is not about you. I don't think any MOTU changes other MOTU's syncs without asking him.
<Hobbsee> Kmos: what guarentee do we have that your'e not going to do ti again?
<Hobbsee> pochu: correct.
<persia> pochu: If it's not yet Fix Released, I usually decline, unless it is considered a release blocker.
<pochu> persia: Oh, I didn't know how to make that 'status tracked in ...'. Thank you.
<Kmos> Hobbsee: I don't do it again.. for sure. Because after my "quarantine" ends, I'll leave for good.
<Hobbsee> Kmos: universe syncs tend not to be important.  there are also archive admin days, where they all get done.
<pochu> persia: if it's not fixed yet and I approve it, will it show in any special list?
<Kmos> for me, universe is important.. that's a point of view.
<Kmos> not only main is important
<Hobbsee> sure, but all the syncs will get done reasonably quickly.  does it particularly matter which order they're done in?
<Kmos> pochu: I agree.
<\sh> Kmos, how did you test libgcr410 and pcsd-lite source?
<Kmos> Hobbsee: no.. but if they're ignored for two days.
<\sh> Kmos, I'm asking because my cardreader is not working since my update now
<Hobbsee> Kmos: 2 days.  dude, have some patience.
<persia> pochu: Yes, it will show in the list of bugs tracked for the release, which start appearing in mailing list posts as we get closer to release.  Only main is really important, but the default search scripts don't discriminate, so it makes noise for the QA team.
<Kmos> Hobbsee: that's not my best.. pacience.
<\sh> Kmos, so I'm fcked now with signing my mails and packages...so what should I do now?
<Hobbsee> Kmos: so get better at it, rather than putting in more crap.
<pochu> persia: alright. Just to know in case I find a blocker ;) But since I can't touch main nominations I don't think I'll find any real blocker :)
<Hobbsee> Kmos: you were told this ages ago.  yet you did not do it.
<Hobbsee> Kmos: why?
<Kmos> \sh: I really don't know what to say to you about that.. I can't test every card on earth.
<Kmos> Hobbsee: because of my pacience *thing*
<Kmos> maybe..
<\sh> Kmos, it's a simple usb smartcard reader which worked since dapper
<Kmos> wiki is working again
<Hobbsee> Kmos: so, fix your patience thing.
<persia> pochu: Likely not.  There are sometimes universe blockers, perhaps related to NBS stuff that would otherwise cause massive cannot-start or uninstallible issues, but those need to be also advertised in other ways so we can all hit them soonest.
<Kmos> Hobbsee: i take medicine pills for that already =) for something like 3/4 years.
<Kmos> and I smoke..
<Kmos> \sh: you're not alone here :)
<Hobbsee> Kmos: are they working?
<Kmos> \sh: that's really strange.. how about to file a bug in debian BTS ?
<Kmos> Hobbsee: are.. but they can't do everything
<\sh> Kmos, now it's not a debian bug, it's an ubuntu bug...because the old version did work...so why did you sync it when it's not working?
<\sh> crap.
<Hobbsee> \sh: because testing is overrated, and because we automatically want the newest bling.
<\sh> Hobbsee, this statement is reserved for wine only *eg*
<Hobbsee> \sh: :)
<\sh> oh wow
<Hobbsee> \sh: yes, but we know to blame you if wine doesn't work.
<\sh> pscs leaves an /etc/init.d/pscsd.dpkg-new
<\sh> and doesn't overwrite the old one...well it's good but it should have asked me if I want to overwrite
<geser> \sh: I guess pcsc-lite needs a fix as it tries to use /var/run/pcscd/ for it's pidfile
 * Hobbsee adds to KmosReport
<geser> I didn't check yet if it checks that that dir exists on startup
<Hobbsee> Kmos: why did you go and modify all the sync requests yourself, instead of notifying the MOTU's that the archive admins do ignore unconfirmed bugs, so they can fix their scripts?
<\sh> geser, the change was PIDFILE=/var/run/$NAME.pid vs PIDFILE=/var/run/pcscd/$NAME.pid
<geser> \sh: /var/run is a tmpfs so /var/run/pcscd isn't there after a reboot and the init-script doesn't recreate it
<geser> \sh: do you know how start-stop-daemon reacts if it can't write the pidfile?
<\sh> geser, it doesn't start
<Hobbsee> ScottK: ammo added.
<Kmos> persia: bug 183495 is opened
<ubotu> Launchpad bug 183495 in openbios-sparc "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [Medium,New] https://launchpad.net/bugs/183495
 * Kmos smoke
<persia> Kmos: Thanks.
<\sh> geser, the problem I have, the old init file is still in place...but it doesn't start at all...
<\sh> geser, and the reason is upstream set the new by default :
<\sh> Statement from upstream changelog: ChangeLog:- default ipcdir is /var/run/pcscd instead of /var/run so the directory
<\sh> Kmos, there you are
<persia> Kmos: Would you mind updating the description to indicate to the buildd admins how they could resolve the FTBFS?
<\sh> Kmos, please fix bug #183498
<ubotu> Launchpad bug 183498 in pcsc-lite "pscsd doesn't start anymore " [Undecided,New] https://launchpad.net/bugs/183498
<mruiz> hi all
<emgent> heya mruiz
<\sh> Kmos, don't worry...I'll fix it
<Hobbsee> persia: s/buildd admins/lamont/
<persia> Hobbsee: I thought infinity looked after sparc
<Hobbsee> persia: lamont is back at canonical.  it might be infnity who does it, but infinity tends not to look at bugs assigned to him much
<persia> Hobbsee: Ah.  In that case, yes.  Thanks for the update.
<Hobbsee> persia: no problem
 * persia still likes the use of general team identifiers until things are actually in shape to be done and someone is selected to look at them
<Hobbsee> persia: this is true, but unfortuantely a lot of the builld admins either will not, or can't, actually fix p-a-s
<persia> Hobbsee: Yes, but this isn't actually really a P-a-s issue.  It's a manual bootstrap issue (until someone hacks arch:all arch-specific hinting into P-a-s)
<Hobbsee> persia: why is it a manual bootstrap issue?
<persia> We would have the same issue with e.g. bochbios if we selected a different architecture for arch:all
<Hobbsee> as in, isn't hte idea just to make it only try to build on sparc?
<Kmos> persia: it has "It needs manual bootstrapping by an buildd admin." , isn't enough ?
<Kmos> \sh: thanks
<persia> Hobbsee: Right.  it's an arch:all package that can only be built on a sparc, but can be used anywhere.
<Hobbsee> persia: oh right.
<persia> Kmos: Not really.  Notice that Hobbsee is confused.
<Kmos> persia: ok
<Hobbsee> persia: is there any logical reason why packages would need that?
<\sh> Hobbsee, qemu e.g.
<persia> Hobbsee: There are three classes of packages that need that:
<Hobbsee> \sh: oh, i didn't realise that needed to build on sparc.
<persia> 1) packages that need internet access (for a good reason)
<Kmos> "It needs manual bootstrapping by an buildd admin, it can only be build on sparc, but can be used anywhere (in other archs)."
<Kmos> better?
 * Hobbsee thought arch all packagse should be able to build on...any arch?
<Kmos> Hobbsee: that's "any"
<\sh> Hobbsee, nope..I mean those packages who can only be build on <arch> only but be used by some other archs
<persia> 2) packages that build a bios and need that arch to be real, but can be used in emulators
<Hobbsee> \sh: my question is why they can only build on a non-i386 arch....
<persia> 3) packages that build-depend on packages with interactive license agreements (although there is now a hack in place for sun Java)
<Hobbsee> ah, yes, if you're needing to build a bios and that arch needs to be real, yes, i can see your point
<persia> Hobbsee: That's #2.  Thinks like openbios-sparc, bochsbios, linuxbios, etc.
<\sh> Hobbsee, in this special case it's because we don't have any cross compiler on x86/x86_64 to build sparc code...
<persia> s/Thinks/Things/ (wondering why typos are phonetic)
 * Hobbsee knew about 1 & 3 - was asking why it had to be bootstrapped on a particular arch, not i386, not why things need to be bootstrapped in general
<Hobbsee> \sh: yummy.
<geser> persia: circular build-depends need also a manual bootstrap on the buildds
<Hobbsee> which persia then answered.  thanks
<persia> \sh: Well, not quite.  Even if we had a cross-compiler, it wouldn't be ideal.
<\sh> persia, but it would work (as I saw yesterday my experiment with a arm cross compiler ;))
<persia> geser: Only when bootstrapping.  As long as you've already bootstrapped, it's safe (except for versioned circular depends, which is bootstrapping again).  But yes, Four reasons.
<persia> \sh: Yes, but you run the risk that your cross-compilation environment doesn't mirror the target properly, and further you have bootstrapping issues (hard to get a cross-compilation environment without a bootstrap bios).
<\sh> geser, what would you like more, leaving the default and mkdir -p /var/run/pcscd/ during startup if it's not running, or changing ./configure to point to --ipcdir=/var/run and change the debian/pcscd.init to point to /var/run ?
<\sh> persia, in this special case, yes :)
<\sh> s/running/exists/
<persia> \sh: Wouldn't the same apply for e.g. an ARM bios on x86_64?
<\sh> persia, yepp...but doing kernel and app compilation you don't need to bootstrap, just a gcc with x86/x86_64/arm support
<persia> OK.  New python packaging question: I've gotten gaphor to use python2.4, but it now depends on "python (<< 2.5)", which seems to have been inserted automatically during the build process.  Any suggestions to avoid this?
<geser> \sh: I'd probably go for mkdir, chmod, chown (if needed) as it's also done in other packages needing a dir below /var/run
<\sh> .oO(well the gcc needs to be bootstraped yes, but without a bios ;))
<persia> \sh: Ah.  Nifty.  Do we compile our qemu ARM bios that way?
<\sh> persia, hmm...I'm not sure...let's have a look :)
<Hobbsee> persia: why do you need it removed?
<geser> persia: just a guess, did you try to change the interpreter to python2.4 if it has any binaries? which you should do anyway if it needs python2.4
<persia> Hobbsee: because python2.5 is part of the default install, and I don't want to break that just to allow installation of this package.
<Hobbsee> persia: oh, point.
<persia> geser: I did that.  Do I maybe have to pass a hint to python-support that it doesn't need to block newer python?
<geser> persia: I don't know of any hints.
<\sh> persia, what is the name of the qemu arm bios? I don't find it
 * persia digs into python-support, wishing that this package could be synced already.  This has been way too much effort for an icon in the menu in Hoary.
<persia> \sh: No idea.  I keep meaning to get an ARM chroot running, and keep postponing it.
<geser> persia: that might be a crude hack but it could work: specify as supported python version also 2.5 but use python2.4 in the binary. If I'm not mistaken python-support should add a dependency on python2.4
<geser> persia: if that doesn't work, hardcode a dependency on python2.4 and remove the ${python:Depends}
<persia> geser: So Build-Depends: python-all, pyversions with 2.4, hardcode the interpreters, and hardcode *egg-info/requires.txt ?
<\sh> persia, I compiled yesterday the whole system of openwrt for arm arch...it bootstraps the toolchain and starts compiling :) very nice...but I didn't have to deal with a bios...
<\sh> geser, will fix the package this evening..
<geser> persia: yes, but with pyversions 2.4-2.5, so ${python:Depends} add a dependency on python which doesn't conflict with the one in the archive
 * \sh needs to go to the gym
<geser> \sh: any progress on your fitness?
<\sh> bbl
<persia> geser: Ah.  Maybe that's my only issue.  Trying again with "2.4-".  Thanks.
<\sh> geser, yepp...2kgs lost :)
<\sh> ok cu later ...
 * persia thinks listing all the upstream changes in debian/changelog and not including the upstream changelog is just duplication of effort
 * rzr updated : http://revu.tauware.de/details.py?package=jaaa
 * rulus updated http://revu.tauware.de/details.py?package=gtkvd too :-)
<slytherin> persia: FYI ... The problem related to w3c-dtd-xhtml was already reported in Debian about 6 months ago. But looks like the reporter didn't provide enough information to convince the maintainer. I have provided it and the bug is now in 'New' state. So I guess it will get fixed in Debian soon.
<persia> slytherin: Excellent.  By the way, would you happen to feel like looking into any upstream version bumps?
<slytherin> persia: for which package? or general java packages?
<persia> slytherin: specifically I'm looking at  libswing-layout-java,  javahelp2 ,  liblucene-java,  and junit.
<slytherin> persia: I will take a look.
<persia> slytherin: Some of these may be syncs from Debian.  Also, be interesting to check to see if we can sync libfreemarker-java
<persia> slytherin: Thanks a lot.
<slytherin> persia: Will let you know by tomorrow end of day.
<persia> slytherin: I have absolutely no idea what that means.  If you're up for it, just file upgrade / sync bugs as usual.  If you subscribe me, and it's those packages, I'll try to accelerate review.
<slytherin> persia: Yes, that is what I meant. I will give a general one line report tomorrow.
<man-di> slytherin: if you need help from Debian side, just tell me
<slytherin> man-di: Sure. :-)
<persia> slytherin: It's "tomorrow" which is undefined :)  For me that starts in 86 minutes.
<slytherin> persia: Ok. After 24 hours. :-)
<persia> man-di: Do you happen to know the status of the script-api.jar packaging?
<ScottK> Good morning all.
<ScottK> persia: RE: libmilter, I agree for now.  Eventually I think we'll need to support it in Main, but I think it's better as a spec for Hardy+1.
<man-di> persia: nope, never heard of that
<persia> ScottK: OK.  By the way, I'm almost done with the final fix for 30344.  Current hack is forcing back to python2.4 for compatibility with zope3, and using the very newest upstream.
<ScottK> persia: I note that the Debian bug linked to 30344 got marked fix released, but haven't looked at it.
<persia> New upstream finally works in sid.  Unfortunately, as zope3 doesn't work with python2.5, we can't do a simple merge (also, the sid package still FTBFS, but that's an easy patch that I'll be submitting as soon as I have something working)
<ScottK> Ah.  OK.
<ScottK> From what I know about zope3, you definitely want to let someone else worry about making it work with Python 2.5.
<DaveMorris> \me plugs his package for revu - http://revu.tauware.de/details.py?package=opensg It's an OSS distributed scenegraph API for doing some cool 3D graphics across multiple machines as well as single machines.  Has support for sort first and last.  I use's it to drive  a 46million pixel display. which is cool, so please revu it.
<persia> Grr.  Despite build-depending on python-2.4, and changing all occurrences of /usr/bin/pyhon and /usr/bin/env python to force 2.4, it still compiles for 2.5 if pyversions is "2.4-", Depends on python (<<2.5) with "2.4", and inserts extra #!/usr/bin/python lines in the build process without asking.
<persia> DaveMorris: Although I agree that your package hasn't had a review in overlong, it's best to keep your advertisements to less than once in 24 hours when it's not REVU day so as to avoid annoying potential reviewers.
<ScottK> persia: elementtree manages to be just for Python 2.4, you might have a look at that package.
<persia> ScottK: Thanks for the hint.
<DaveMorris> persia: sure
<DaveMorris> I just wanted to make sure people from various timezones saw it
<persia> DaveMorris: I generally recommend staggering advertisements by about 30 hours to achieve that.  Makes sure you don't get an extra complaint from somebody who forgot to go to bed as well :)
<DaveMorris> thanks for the adice
<DaveMorris> *advice
<DaveMorris> I'm feeling confident with packaging new things now, is there somewhere I can read on how to do the other tasks MOTU's undertake?
<slytherin> DaveMorris: ho wabout you fix some build failures. :-)
<slytherin> DaveMorris: http://qa.ubuntuwire.com/ftbfs/
<persia> DaveMorris: Most of the work that we do is just looking at packages that need help, and fixing issues.  There are some automated tools, like the FTBFS checker, or debcheck (catches issues with dependencies that prevent packages from installing).  There's also the bugtracker, which lists all kinds of things that need work, from the simple to the multi-year project.
<DaveMorris> got a url for the bug tracker?
<persia> DaveMorris: https://bugs.launchpad.net/ubuntu/+bugs
<DaveMorris> ok so bugs in general not bugs with special tags/assigned to a group
<persia> DaveMorris: Right.  For a while there was a practice of assigning/subscribing MOTU to bug reports, but that is now deprecated, as there are just too many packages that are handled by MOTU, and it's a waste of the triagers' time.
<slytherin> DaveMorris: there are some tags, like needs-packaging or bitesize
<persia> DaveMorris: You might try searching for bugs with patches attached, or by tag, or just search for a term that interests you.  Also, #ubuntu-bugs is a good place to talk about bugs and finding classes of bugs that need help.
<DaveMorris> so when I fix some of the FTBS bugs do I upload them to revu again?
<persia> DaveMorris: Nope.  You attach a debdiff.  You might want to read https://wiki.ubuntu.com/MOTU/Contributing
<slytherin> persia: man-di: a quick update on the packages you asked about - http://pastebin.com/m489c582
<man-di> slytherin: I will ping the right people in debian about it
<persia> slytherin: My information reports there being junit-3.8.2.jar floating about.  Are you sure about that?
<slytherin> persia: Let me check once again.
<persia> (Google has 3,860 hits on junit-3.8.2.jar)
<slytherin> persia: Nothing found on website (sourceforge). So I guess it is better to ignore.
<slytherin> persia: oops, I was wrong. It is available
<man-di> newest junit3 is 3.8.2
<man-di> I packaged it
<persia> heh.  I thought so.  It is a reverse-dependency for something I'm watching?
<persia> man-di: Safe to sync?
<man-di> http://sourceforge.net/project/showfiles.php?group_id=15278&package_id=12472 has it too
<man-di> persia: yes, I think so
<slytherin> persia: I will check debian changelog and log a sync bug accordingly
<persia> man-di: slytherin: Thanks
<slytherin> persia: done for junit - bug 183529
<ubotu> Launchpad bug 183529 in junit "Please sync latest version from Debian" [Undecided,New] https://launchpad.net/bugs/183529
<persia> slytherin: Great.  Thanks.  Next target: lucene2 :)
<slytherin> persia: As soon as w3c-dtd-xhtml is fixed. :-)
<persia> OK.  That only leaves libswing-layout-java then.
<slytherin> man-di: should I file a bug in Debian for libswing-layout-java?
<man-di> slytherin: if you like, please do
<man-di> slytherin: and if like too, please add a watch file
<bddebian> Heya gang
<ScottK> Heya bd.
<man-di> to let us get automcatially report new upstream version of it
<ScottK> bddebian even
<slytherin> man-di: I neither use that library nor Debian. Just trying to keep things in shape. :-)
<bddebian> Hi ScottK
<man-di> slytherin: you might want to know this page: http://pkg-java.alioth.debian.org/cgi-bin/qareport.cgi
<persia> slytherin: If the Maintainer is "Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>", and man-di gives you the go-ahead, you're doing the right thing :)
<persia> hey bddebian
<bddebian> Heya persia
<geser> Hey bddebian
<bddebian> and geser :)
<slytherin> Now I wish there was a separate team for PPC.
<persia> slytherin: There's a PPC interest group.  What do you need?
<slytherin> persia: openoffice.org is missing from standard install. I have filed a bug already but it is in 'New' state. Looks like theer is no one else to confirm. :-)
<persia> slytherin: Have you asked for confirmation in #ubuntu-bugs?
<slytherin> persia: No, I didn't.
<slytherin> #ubuntu-bugs
<joejaxx> since Sun is purchasing mysql
<joejaxx> :D
<Hobbsee> slytherin: does it actually *build* on ppc?
<joejaxx> -since*
<joejaxx> persia: it is true
<joejaxx> i actually forgot to look into that
<slytherin> Hobbsee: yes, At least writer, impress and calc.
<joejaxx> last time i looked there was not enough space on the discs for it
<Hobbsee> joejaxx: ah, so that's the problem
<slytherin> joejaxx: I am specifically talking about alternate CD. It is of size around 640 MB IIRC
 * Hobbsee suspects the other problem is that no one actually cares abou tit
<joejaxx> i will take a look into it
<slytherin> joejaxx: Do you want bug number?
<joejaxx> slytherin: i believe i have it in my email but sure
<joejaxx> :)
<slytherin> bug 164491
<ubotu> Launchpad bug 164491 in ubuntu-meta "[ppc] openoffice.org not present on alternate CD" [Undecided,New] https://launchpad.net/bugs/164491
<joejaxx> thanks
<vud1> hi. who can sync the gpg keys for REVU uploads?
<persia> slytherin: I was just advised that Marek Slama is almost done preparing an update for libswing-layout-java, so just filing the bug is probably sufficient.  Should be uploaded this week.
<persia> vud1: I'll start a sync now.
<vud1> oks thanks!
<slytherin> persia: Ok
<man-di> persia: I sponsor Marek normally
<man-di> slytherin: I will ping you when I uploaded it
<persia> man-di: Ah, so it is you.  He was being mysterious about the identity of his Debian contact :)
<slytherin> man-di: Ok. So I won't file a bug then.
<joejaxx> looks like openoffice.org fails to build on powerpc currently (and also sparc)
<joejaxx> i wish i had a power{5,6} it would make building soo much easier :)
<_MMA_> joejaxx: Just talk to calc. There's _major_ things happening with OO.o right now.
<joejaxx> _MMA_: yeap i know
<Hobbsee> Ng: ping
<mok0> Hobbsee: Can I use reportbug on an Ubuntu system to make submissions to Debian's BTS?
<ScottK> mok0: You can
<Hobbsee> mok0: yes, but you need to use the correct distro switch
<ScottK> reportbut --bts=debian
<ScottK> but/bug
<StevenK> Oh, a but report
<mok0> OK, thx!
 * StevenK hides
<ScottK> Wrong channel for that.
<StevenK> Haha
<persia> Now I'm extra annoyed.  I have a python file that hardcodes #!/usr/bin/python2.4, and it somehow gets bumped to 2.5 during the build process.
<ScottK> persia: You aren't build-depending on a virtual package are you?
<ScottK> sbuild doesn't support versioned depends on virtual packages.
<persia> ScottK: python2.4, python-support (>= 0.6), debhelper (>= 5) + python-setuptools, xsltproc, docbook-xsl
<persia> ScottK; Yep.  I've been encountering that for a while now :)  Personally, I think it shouldn't, given how virtual packages are intended to be used, but I understand why it might be nice given how virtual packages are actually used.
<ScottK> Did you look at elementree?
<ScottK> Well all I care about on sbuild is that Malone can build packages correctly and it can't always now, so I don't care what you call the fix, it needs to be fixed.
<Ng> Hobbsee: hey
<persia> ScottK: Yes, and it was exceedingly helpful.  I was able to revert almost all of my hacks and still have a python2.4 package.
<persia> ScottK: Fix the packages
<ScottK> persia: They aren't fixable.  My particular concern is the perl modules conundrum where perl ships modules that are also provided in a later version by another package.
<ScottK> If sbuild find out it has an insufficient version of a package it ought to see if that problem can be solved and not just fall over and die.
<persia> ScottK: Yes.  I know.  Ideally upstream wouldn't be quite that annoying.
<ScottK> But we don't live in an ideal world.
<persia> Right.  See my point about there being a difference between how virtual packages were intended to be used and how they are actually used.
<ScottK> With any luck sbuild will get fixed about the same time as my core-dev application gets approved and so I'll be able to fix the one FTBFS I've caused due to this problem without bugging sponsors.
<persia> ScottK: Soyuz doesn't use Ubuntu sbuild :(
<ScottK> persia: No, it uses a Canonical fork of it.
<ScottK> Which also has the bug.
<ScottK> Of course apparently a lot of the Debian buildd's don't use the Debian sbuild either.
<persia> ScottK: No, it uses a Canonical fork of the sbuild from which the Debian distributed sbuild forked (and which we now sync).
<ScottK> Right.
<persia> There is a common codebase, but it's fairly historic at this point.  GIven the changes, I'm not sure it's easy to backport, but given the advantages of schroot, it might be reasonable to expect Soyuz to migrate when upgrading to hardy.
<ScottK> infinity promised a fix in short order, but I'm not holding my breath.
<ScottK> bddebian: You gonna fix Tremulous?
<persia> ScottK: Makes sense.  Just wanted to make sure you knew that Soyuz & Ubuntu had different trees.  Also, I'm not sure I want it fixed locally only, as it makes it harder to anticipate Soyuz breakage.
<ScottK> True.  There's a patch sitting in Debian BTS that addresses (I think) this problem.
<ScottK> I cannot help but mention that this situation would be much easier to understand if Launchpad weren't proprietary.
<persia> ScottK: That may well be pending upload waiting for integration with the Debian buildd system as well.
<persia> ScottK: To understand perhaps.  On the other hand, the same issue exists in Debian, despite the extreme efforts underway to allow external bootstrapping of DAK and freinds.
<bddebian> ScottK: I'm not sure of the issue yet
<ScottK> bddebian: Well given the siretart is a DD and expressed some interest in it getting done you might actually be able to get sponsored on that one.
<bddebian> Heh
<persia> bddebian: Bascially there's a 3rd party patch available for review and application.  Reported to be popular in the tremulous-playing community.
<bddebian> persia: Thanks.  Doesn't look like tremulous is a games team package
<persia> bddebian: It's Ubuntu games team, at least.  More BTS entries are also nice :)
<wallyweek> bddebian: I'm not sure I understood your latest comment on sdlmame... what do you mean with "whole structure"?
<bddebian> wallyweek: I mean all of the subdirs are required under .mame, not just .mame/roms ?
<bddebian> Well files/dirs I should say
<bddebian> persia: Ubuntu Games Team??
<persia> bddebian: You know.  The people who watch Section: games in Ubuntu and used to have a LP group until Debian Games Team granted all of them SVN access?
<ScottK> dholbach: I'm confused by your Kmos report.  Your "Recommendation" is actually a summary.  I don't understand what is to happen from here?
<wallyweek> bddebian: ah! no, they aren't afaik
<persia> ScottK: While I agree with you about that, remember that this is the report to the MC, rather than the report from the MC on the action to take.
<bddebian> persia: Uhm, OK :-)
<dholbach> ScottK: Cesare and I summarised the supervision of the last three weeks
<dholbach> ScottK: right... 'Recommendation' is probably not the right word
<dholbach> hrm
<ScottK> dholbach: You also fail to mention him not doing as directed repeatedly and reliably.
<ScottK> dholbach: If he can't be trusted to do as he's told when he's under close supervision, he can't be trusted at all.
<wallyweek> bddebian: ok, I'll check and address your comment as soon as I'm back home
<bddebian> wallyweek: NP, thanks
<dholbach> ScottK: I'll follow up and clarify on that point - I've got a call in a bit, but I'll do it
<ScottK> dholbach: It reads like a whitewash to me.
 * ScottK is very disappointed.  I'll read the mail.
<dholbach> you're free to reply to that mail
<dholbach> ugh
<nxvl_work> whats uvf?
<persia> nxvl_work: It was UpstreamVersionFreeze.  It has now been rolled into FeatureFreeze.
<soc> hi
<nxvl_work> persia: thnx
<soc> i just wonder, i the font "lucida" freely redistributable?
<soc> it's in the java package
<soc> i couldn't find anything about licencing fonts, etc. in the sun java license
<emgent> hello there
<mruiz> What about the migration from interdiff to diff.gz (sponsoring new upstream versions) ?
<slytherin> !hi > emgent
<persia> mruiz: Still under discussion on ubuntu-devel@ (although that seems to have quieted).  Feel free to add it to the MOTU Meeting agenda if you like: I was planning to wait until the following meeting to get more involvement from URC+2, where a number of the migration advocates live.
<persia> s/URC/UTC/
<mruiz> I'm adding the diff.gz and .dsc to my upgrades bugs
<persia> mruiz: The .dsc is completely useless for upgrade bugs.
<mruiz> !
<persia> mruiz: I've expanded on that opinion at https://lists.ubuntu.com/archives/ubuntu-devel/2008-January/024922.html
<persia> mruiz: Also, I believe it's best to follow the current process until we agree on a new one, so I encourage you to post interdiffs
<mruiz> persia, just interdiffs ?
<persia> mruiz: Yep.  The interdiff (appropriately constructed) allows the sponsor to generate the diff.gz.  The diff.gz should contain enough information to generate orig.tar.gz, and that contains enough of the package that debuild will generate the .dsc and source.changes
<persia> mruiz: see https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
 * mruiz is reading there
<persia> I am an advocate of using .diff.gz alone, but it's not yet the approved practice for doing things.
<slytherin> [off-topic]: does anyone know how can I add fm radio channels in rhythmbox db? There is no ui for this yet and I have to manually edit the db. I just want to know what is format.
<pochu> slytherin: I don't use radio channels, but what about right-click on Radio, then Add new radio station?
<slytherin> pochu: What you are talking about is internet radio. I am talking about FM radio played using tuner cards
<pochu> slytherin: oh. No idea then. Maybe try in #rhythmbox in Gimpnet
<slytherin> pochu: Will try
<dantalizing> need DebootstrapChroot help, reading the wiki and in the 'dchroot' section it says to add a bunch of stuff to fstab ... do i really add those lines to my / fstab? or the chroot fstab?
<pochu> Ng: bug #183555. Would you mind subscribing yourself or the terminator team (if it exists) to the Ubuntu terminator bugs? https://launchpad.net/ubuntu/+source/terminator/+subscribe
<ubotu> Launchpad bug 183555 in terminator "README file has unclear shorcuts" [Undecided,New] https://launchpad.net/bugs/183555
<mruiz> Where can I find information to create a man page ?
<Ng> pochu: I'll do it now, thanks :)
<pochu> Ng: you're welcome
<Ng> I've added our team :)
<pochu> mruiz: help2man is a nice script if you're creating the man page for an application which supports --help command line option
<mruiz> pochu, I'll find out about it . Thanks!
<geser> dantalizing: which wiki page? what do you want to do with the chroot?
<LucidFox> pochu> From my experience, man pages generated by help2man require a lot of manual tweaking afterwards
<persia> Could anyone help explain install_scripts from distutils to me?  It looks to me like this might be the cause of the build-time modifications of the #! line for my python2.4 issue, but I'm not sure I understand well enough to be sure.
<bddebian> Better than writing from scratch! :)
<LucidFox> bddebian> True :)
<nxvl_work> effie_jayx: ping
<dantalizing> geser: https://wiki.ubuntu.com/DebootstrapChroot
<dantalizing> geser: setting up a hardy chroot on gutsy so i can learn to package stuff, or otherwise help out
<frafu> Hello,  I have a question concerning revu: the mousetweaks module has been submitted for integration into GNOME and in revu. It has been accepted in GNOME and ships with it since GNOME 2.21.5. Does it make any sense to continue with the revu process?
<persia> frafu: Will mousetweaks be a different source package as part of GNOME 2.21.5?
<LucidFox> frafu> If it's accepted into Ubuntu as part of another source package, then there's no need to package it separately
<pochu> LucidFox: yes, but creating a man page from the beginning requires more manual tweaking ;)
<geser> dantalizing: I use schroot for accessing my chroots (dchroot is now a wrapper around schroot)
<frafu> Lucidfox: The gui of mousetweaks has been integrated into the mouse control panel of the gnome control center. The daemon of mousetweaks comes as a separate package. How can I know if it will also be in Ubuntu 8.04?
<dantalizing> geser: thanks, how is schroot any better than 'sudo chroot ...'?
<geser> dantalizing: I use "schroot -p" to get into my dev hardy chroot or "schroot -p -c ubuntu-i386" for my 32bit chroot
<geser> dantalizing: -p is for preserving the environment and I've set up schroot to bind-mount /home (and other dirs) into the chroot to have them available (and schroot unmounts them again when I leave the chroot)
<mok0> geser: sounds interesting! What does your schroot.conf look like?
<persia> geser: Why -p?  Isn't that dangerous (exposing your environment)?
<RainCT> Riddell: hi. could you speak to pitti (qtparted)?
<persia> frafu: If the daemon needs a separate package, someone needs to prepare it.  REVU is a good place to put the candidate for review.  Perhaps adjusting that to only have the daemon, and asking both here and on #ubuntu-desktop for review would be the best way to be sure it gets in for hardy.
<geser> persia: I want X11 access working from my 32bit chroot (e.g. for firefox with flash or skype) and also my usual environment when I use my hardy chroot were I prepare packages (so I don't pollute my normal environment with -dev packages)
<LucidFox> Maybe he should ask seb128 about how he plans to integrate the mousetweaks backend?
<LucidFox> He maintains gnome-control-center, after all
<persia> LucidFox: I think it's better to ask #ubuntu-desktop (maybe during French working hours), than seek a specific person, but I'm a big fan of teams and teamwork.  I suspect you've correctly identified the person who would be most likely to have an authoritative answer.
<persia> geser: Ah.  I see.  You've also separate build chroots then, I guess?
<geser> persia: for building I use normal pbuiler chroots
<geser> pbuilder
<persia> geser: Oh.  I thought most schroot users used sbuild over schroot.  My mistake.
<frafu> Consequently, being shipped with gnome does not necessarily mean that it will be in ubuntu. Moreover, revu is for packages for universe. Would it not be strange to ask to put a package into universe when the same package comes with gnome? I will try to ask seb128...
<geser> persia: when I got my new hardware, I will look on setting up sbuild (and a small local mirror, probably apt-cacher) and will then not use -p for the build chroots
<geser> currently I use schroot only to access my chroots
<persia> frafu: Best practice is to get things into universe, and then push them to main.  That gets testing to make sure that it doesn't have issues with the buildds, builds for all architectures, etc.  This makes the required Main Inclusion Report much easier to write.
<persia> So, I just ran `grep -ri $string /usr/share` and am encountering a lot of "Too many levels of symbolic links".  Are these bugs?
<jdong> where can I find a good guide on the types of changes needed to add dpatch to a source package?
<jdong> it seems like our guides all kinda assume dpatch is already set up... and the examples that ship with dpatch are kinda vague as to what I need to do
<geser> jdong: the patch README?
<geser> dpatch README
<persia> jdong: man dpatch
<persia> jdong: Better, man dpatch.make
<jdong> persia: aha, that's the one! thanks
<jdong> geser: I tried that first.... It has no README but it did provide me some fascinating reading about the history of the tool ;-)
<geser> jdong: there are also some examples in the doc/ dir
<jdong> yep.
<jdong> Wow, Launchpad is really mean nowadays... incomplete bugs self-expire?
<pochu> jdong: not for Ubuntu. It's just a preview, but nothing won't change for now.
<persia> jdong: Yes.  Generally they get restored if anyone cares (although it does increase the workload for people who take > 4 months to prepare a solution and left it "incomplete" in the meantime)
<jdong> yeah I guess if someone cares then it's a non-issue
 * jdong grumbles at that sigsegv bug report filed against the supertux he uploaded yesterday...
<persia> That is at least the philosophy behind the change.  I'm not sure how clear that is to the general public when they are advised their incomplete bug became invalid, but that's a different issue.
<jdong> as always, unreproducible and I just wasted 30 minutes playing supertux.
<jdong> note to self: DO NOT triage game related bugs!
<persia> jdong: Please do.  The Games team appreciates any help.
<persia> jdong: Which bug?  Does it have a stacktrace?
<geser> jdong: are those 30 minutes really wasted? :)
<jdong> persia: bug 183419... I tried toggling fullscreen several times to no luck
<ubotu> Bug 183419 on http://launchpad.net/bugs/183419 is private
<jdong> what?
<jdong> err... no it's not?
<jdong> https://bugs.edge.launchpad.net/ubuntu/+source/supertux/+bug/183419
<geser> jdong: you are probably an indirect member of the universe-crash-team so you can see it
<jdong> oh yeah it was
<jdong> ok it's unprivate now.
<jdong> and why is cdrom a nonfree kernel module anyway? :)
<persia> jdong: Try looking in src/gui/menu.cpp around line 750.  I suspect the developer forgot to test to make sure the menu pointer was valid before attempting to use it under some special (and likely unreproducible) set of conditions.
<jdong> persia: it's probably bad that the this pointer on 0 and 1 are both 0x0, right? :D
<persia> jdong: Usually means that it gets set by a call to some function that returned an error, and the developer didn't check for an error condition.  Unfortunately frequent in games, and as you've discovered, best tracked down by source inspection rather than testing.
<persia> jdong: Essentially, a pointer should only be 0 when speficially uninitialised, and should never actually be used in that state.  I've seen far too many cases where it gets set somewhere and then used before any validity checking.  This might be acceptable in tight loop code, but is generally poor practice.
<jdong> persia: hmm I'll investigate then
<persia> Further, in the case of use in tight loop code, it's important to trap the error outside the loop, reset to something sane, and possibly reenter, rather than crashing.  Most players would prefer the occasional stutter to a segfault.
<jdong> ok I see where the options_menu pointer was used that led to this stack track but not why it's null...
<jdong> should've been initialized at this point, but I guess there might be a missed path to this code
<persia> jdong: Just step back up the function.  That function was called with a real pointer (although possibly not to the structure the function expected).
<persia> I usually start three or four frames behind the crash to build context, so by the time I get to the crash point, I have some idea what things mean (as otherwise one has to read the entire codebase).
<bddebian> What package is requestsync in?
<persia> ubuntu-dev-tools.
<bddebian> Thx persia
<persia> Note that it doesn't work if debian source isn't in sync in all archs, and can be otherwise annoying.
<bluefoxicy> the new update manager icon is awesome
<bddebian> I don't use it :-)
<persia> Then why do you want it?
<bluefoxicy> because of the contrast around the star shape, I managed to mistake the tiny down arrow for something giving me the finger.
<bddebian> persia: Someone was asking about it on #debian-games :)
<persia> Ah.  That's not so dangerous then.  Remind them to use the -s parameter.
 * persia isn't sure it would work on a debian system: might need an ubuntu chroot
<persia> POX_: If you're still about, I'm still stuck on pushing gaphor back to defaulting to 2.4.  Essentially, setup.py is calling install_scripts to install the /usr/bin entry, and somewhere in this stack, get_script_header is called with executable of "/usr/bin/python2.5", which I'm guessing is the value of sys_executable used by default in get_script_args.
<pochu> wow, REVU now has a lintian up-to-date right? :)
<persia> I'm having trouble tracking down where between these two points I can insert a hint that I really do want python2.4, yet still get the various extra bits that install_scripts seems to insert when installing the script.
<persia> pochu: Yep.
<geser> persia: I've a local fix for source-not-in-sync problem in my requestsync-with-python-launchpad-bugs script
<persia> geser: Cool!  Do you think you'll be able to push by feature freeze?
<geser> persia: the script is available from bug #147994 for testing
<ubotu> Launchpad bug 147994 in ubuntu-dev-tools "requestsync should have a command line switch to use python-launchpad-bugs (instead of mailing)" [Wishlist,In progress] https://launchpad.net/bugs/147994
<geser> it WFM but some broader testing would be nice
<POX_> persia: point me to sources, I'm checking RainCT's package right now
<geser> and I'm not sure if it should stay a separate script or be merged with the normal requestsync script
<LucidFox> http://lists.debian.org/debian-mentors/2007/12/msg00151.html "debian/manpages: What is this file for?"
<LucidFox> Seriously... he reviews, cites obscure Debian guidelines on copyright files, and doesn't know what debian/manpages is for?
<dantalizing> is this the proper channel for ppa questions related to packaging...at least i think related to packaging....
<LucidFox> dantalizing> Ask your questions :)
<azeem> LucidFox: uh, I think Patrick Schoenfeld is a known professional troll, though maybe I mixup the name
<LucidFox> Well, his advice does seem to be helpful
<persia> POX_: http://people.ubuntuwire.com/~persia/packages/gaphor_0.12.4-2ubuntu1.dsc builds cleanly in sid and hardy.  Works in sid.  Works in hardy if one manually adds "2.4" to the shebang line of /usr/bin/gaphor in the binary.
<azeem> LucidFox: yeah ok, I mixed up the name
<azeem> he maintains a couple of packages
<persia> LucidFox: Some of that is wrong too.  At least the debhelper dependency was bumped for a reason.
<LucidFox> Yes, for dh_icons
<LucidFox> but I'm planning to move to cdbs for the next mentors.d.n upload
<LucidFox> gnome.mk takes care of dh_icons both being and not being present, so I'll relax the dependency to just >= 5 anyway
<dantalizing> i keep getting rejected uploads.  i'm trying to package latest upstream vzctl, which i was able to do manually on my system.  now trying to upload source package to PPA.  I was in the Packaging 101 yesterday, and have read Packaging with DebHelper on h.u.c.  My .dsc has Files: vzctl_3.0.22.orig.tar.gz and vzctl_3.0.22-0ubuntu2~ppa2.diff.gz. and those files exist in the same dir as the .dsc,...
<dantalizing> ...however PPA is rejecting with: Rejected:
<dantalizing> Unable to find vzctl_3.0.22.orig.tar.gz in upload or distribution.
<dantalizing> Files specified in DSC are broken or missing, skipping package unpack verification.
<dantalizing> Signer has no upload rights at all to this distribution.
<dantalizing> Signer is not permitted to upload to the component 'universe' of file 'vzctl_3.0.22-0ubuntu2~ppa2.dsc'
<dantalizing> and i dont know how to fix it....tia
<LucidFox> dantalizing> First, build with "debuild -S -sa"
<persia> dantalizing: pastebins are good.  Check your keys.  Use -sa
<LucidFox> rather than just "debuild -S"
<LucidFox> And second, upload the changes file rather than the dsc file... although I think dput rejects dsc files for PPA on the spot
<dantalizing> I did use "debuild -S", and entered my passphrase
<dantalizing> LucidFox: i did upload the changes file.  Just mentioning what was in the DSC
<LucidFox> Ah.
<geser> dantalizing: and upload to ppa and not Ubuntu
<LucidFox> Like persia said: use -sa. In addition to -S. Otherwise, dput won't include the orig.tar.gz in the upload.
<dantalizing> dput vzctl_3.0.22-0ubuntu2~ppa2_source.changes
<dantalizing> oh, ok
<geser> ^^ that would go to Ubuntu (unless you changed the default)
<dantalizing> my .dput.cf has ppa.launchpad.net
<geser> as default?
<dantalizing> i only have one entry
<geser> hmm
<geser> the "Signer is not permitted to upload to the component 'universe'" indicates an upload to the official Ubuntu archive
<dantalizing> persia: sorry, pastebin next time
<pwnguin> with bugzilla, can i reply to a comment bugzilla emailed me about and have it add the reply in bugzilla?
<LucidFox> dantalizing> there is also /etc/dput.cf
<LucidFox> the entries in .dput.cf are added rather than replacing hose
<dantalizing> LucidFox: ah
<LucidFox> you need to either set ppa as default, or use "dput ppa [changesfile]" (assuming that the name in square brackets in .dput.cf is [ppa])
<dantalizing> very nice
<josesanch> pochu: hello.
<dantalizing> LucidFox,geser,persia: perfect!  Working now.  Thanks!  more noob questions will follow I'm sure....
<josesanch> pochu: i have seen the comment about gnomecatalog
<pochu> hey josesanch
<josesanch> To add dh_desktop and dh_icon
<josesanch> appending this to rules ?
<josesanch> can works if
<josesanch> binary-indep: build install
<josesanch> 	dh_icons
<josesanch> 	dh_desktop
<pochu> josesanch: since it's CDBS, it needs to be a bit different.
<pochu> install/gnomecatalog::
<pochu>         dh_icons
<pochu>         dh_desktop
<kitterma> |pastebin | josesanch and pochu
<kitterma> Argh.
<josesanch> kitterma: sorry
<kitterma> !pastebin even
<ubotu> Sorry, I don't know anything about pastebin even - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<pochu> !paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<pochu> josesanch: look at https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
<josesanch> i could use cleanbuilddir/gnomecatalog::
<josesanch> to clean the mo dir.
<josesanch> pochu: appending this to rules must work then. http://paste.ubuntu-nl.org/52168/
<pochu> josesanch: I think so. You can try a build with that and see if dh_icons and dh_desktop are called at the end of the build, with the debhelper stuff.
<pochu> josesanch: regarding the mo dir, better to clean it in setup.py, so other people not using our packaging benefits from it.
<josesanch> ok..
<josesanch> I'll upload this version and wait for comments of anyone else.
<josesanch> then, if the package is correct i will bump a new version 0.3.4
<josesanch> pochu: ok?
<pochu> josesanch: sounds good.
<josesanch> pochu: thanks for all
<pochu> yw
<POX_> persia: "python setup.py install" line is setting the shebang to python2.5
<POX_> persia: just change this line to "python2.4 setup.py install" and you will have right one
<POX_> persia: debian/rules, line 20, 29 and 47
<nxvl_work> dod some knows gOS?
<POX_> :q
<POX_> err, wronk window :)
<POX_> wrong even
<Legendario> i need some help on building a package with pbuilder
<Legendario> i am getting an error message
<Legendario> hostname: unknown host
<Legendario> the one above
<Legendario> anyone can help me
<Legendario> ???
<somerville32> Legendario, is your hostname in your hosts file?
<slangasek> more precisely, is it in your hosts file within the pbuilder tarball?
<Legendario> i gess i don't know what file is this...
<slangasek> hmm, perhaps it doesn't need to be in the tarball
<slangasek> Legendario: what does 'cat /etc/hostname' give you?
<Legendario> output: P4-Kemel
<Legendario> so...
<Legendario> that's my hostname when i type "hostname" on the terminal
<slangasek> hmm, I would still suspect a problem with /etc/hosts in the pbuilder tarball then, but more context for the error message might help
<Legendario> I: using fakeroot in build.
<Legendario> Current time: Wed Jan 16 17:20:58 BRST 2008
<Legendario> pbuilder-time-stamp: 1200511258
<Legendario> Building the build Environment
<Legendario>  -> extracting base tarball [/var/cache/pbuilder/base.tgz]
<jdong> vorian: I thought KTorrent 4 was version 3.x.x?
<Legendario>  -> creating local configuration
<Legendario> hostname: Unknown host
<jdong> !paste | Legendario
<ubotu> Legendario: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<vorian> jdong: nope, 4.0.0
<jdong> vorian: you sure?
<vorian> aye, do you want the tarballs? :)
<bddebian> Gah, vorian looks too much like vorlon and scares me ;-P
<somerville32> It should be 127.0.0.1 P4-Kernel
<jdong> vorian: woah woah I don't swing that way bro.
<vorian> :(
<vorian> jdong: liar
<somerville32> and 127.0.0.1 localhost
<jdong> vorian: I was assuming since it was called KTorrent For KDE4 3.0beta1 and the KDE3 series was 2.2.x, it would be 3.0
<Legendario> ubotu: thanks, i didn't know how to use it...
<jeromeg> jdong: do you have some time to validate backports please ? :)
<jdong> vorian: and btw the watchfile is outdated :)
<vorian> jdong: you are hurting my feelings
<Legendario> slangasek: that's all the output http://paste.ubuntu-nl.org/52178/
<Legendario> http://paste.ubuntu-nl.org/52178/plain/
<jdong> #define KT_VERSION_MACRO "3.0beta1"
<jdong> vorian: ^^ :)
<jdong> don't trust KDE4's FTP version numbers
<slangasek> Legendario: what does 'grep -i p4-kernel /etc/hosts' give you?
<jdong> vorian: so 4.0.0 is the same version as what shipped in 3.97 beta :)
<slangasek> somerville32: you should never assign hostnames other than localhost to 127.0.0.1, that way lies madness
<vorian> jdong: I'll fix it next upstream, hmk?
<vorian> :P
<somerville32> slangasek, Ubuntu does it by default :P
<jdong> vorian: yay for epochs :)
<slangasek> somerville32: I think you'll find that what Ubuntu uses is 127.0.*1*.1
<Legendario> 127.0.1.1 P4-Kemel.virtua.com.br P4-Kemel.nau_do_Kemel
<jdong> vorian: regex-scrape http://ktorrent.org/downloads/ for ^3.*
<Legendario> slangasek: that's it.
<slangasek> Legendario: ok, then I'm out of ideas regarding the source of that error, sorry
<Legendario> anyone else???
<somerville32> I had that problem once
<somerville32> but I fixed it by correctly setting my hostname stuff
<Legendario> how?
<Legendario> somerville32, how did u correct it?
<somerville32> By having 127.0.0.1 localhost
<somerville32> and 127.0.0.1 serenity
<somerville32> serenity being the name of my computer
<slangasek> which is not a correct fix
<slangasek> Legendario: I do notice that you don't have 'P4-Kemel' listed as an alias on its own for your host
<slangasek> Legendario: so try adding P4-Kemel to the end of your 127.0.1.1 line in /etc/hosts
<Legendario> slangasek, did it. gonna run the pbuilder againg
<Adri2000> ScottK, ScottK2: around?
<ScottK> Yes
<Adri2000> about filezilla and its changelog
<Adri2000> NEWS is actually the changelog, is it a problem that it is called NEWS and not ChangeLog?
<Adri2000> ChangeLog only contains a link to the svn commit history
<ScottK> Given policy, I'm inclined to say you ought to install the thing the upstream calls the changelog.
<Adri2000> anyway, as I use dh_installchangelogs, NEWS is renamed to changelog in /usr/share/doc/filezilla/
<Adri2000> $ cat ChangeLog
<Adri2000> For a full list of changes, please visit http://filezilla-project.org/changelog.php
<Adri2000> I don't think it's really useful for the end user. we do not ship INSTALL files either for example
<ScottK> Adri2000: So if you install something that upstream doesn't call the changelog and call it the changelog, I think that's definitely wrong.
<Adri2000> policy says "If an upstream changelog is available", not "if a file called 'ChangeLog' is available"
<Adri2000> and it even says "If the upstream changelog files do not already conform to this naming convention, then this may be achieved either by renaming the files, or by adding a symbolic link, at the maintainer's discretion."
<Adri2000> so I really don't see what's wrong there
<ScottK> I think upstream knows what they believe their changelog is and you are installing a different file and calling it changelog.  Installing NEWS also is a good idea.
<Legendario> slangasek: well, thanks dude. It seems to have worked... but got another error
<ion_> I donât see a reason not to install a file called Poop as changelog.gz if it happens to be the changelog.
<ScottK> ion_: If there's no upstream changelog, then I'd agree.
<slangasek> ion_: I see a slight reason not to package something using a file called 'Poop' as its changelog :)
<slangasek> Legendario: what's the new error?
<ion_> scottk: He said NEWS is the changelog.
<ScottK> ion_: Except that upstream provides a file called Changelog.
<ScottK> We've already spent more time on this than it's worth.  Do whatever you want with the bug.
<ion_> ...which doesnât contain one. :-)
<emgent> hello
<Legendario> slangasek http://paste.ubuntu-nl.org/52191/
<slangasek> Legendario: ah, well, that's a bug in your package then
<Legendario> ok
<Legendario> thanks
<Legendario> a lot
<slangasek> Legendario: the upstream build rules appear to write to /opt/ even when DESTDIR is specified, so you need to sort that out.  Perhaps the upstream build rules support some variable other than DESTDIR, or need to be adjusted to support DESTDIR
<Legendario> slangasek, i think this /opt is set on the make file
<Legendario> slangasek, do you know how i should correct it
<ScottK> Legendario: I'd suggest grep'ing to find where it's set and then patch it.
<Legendario> it is set as a variable at the make file: ROOT=/opt/odfellowship
<Legendario> the make file inside the souce package
<RainCT> about bug #174252, do packages that depend on a package that was rebuild against libgif to be also builded again? (eg. aterm agains the rebuilded libafterimage-dev)
<ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252
<geser> RainCT: shouldn't be needed
<Legendario> how do i match the DESTDIR with the make file ROOT
<Legendario> ?
<geser> Legendario: with $EDITOR
<Legendario> geser: can you give me more details
<Legendario> ?
<RainCT> geser: oh okay. thanks
<geser> Legendario: simply edit the Makefile and specify the correct value for ROOT
<geser> RainCT: any reason why it should need a rebuild?
<Legendario> geser: i know that... but what is the right value for avoiding another pbuilder error?
<geser> RainCT: the transition from libungif -> libgif should only affect those packages that link against it
<RainCT> geser: no, I'm just asking.
<geser> Legendario: which pbuilder error?
<Legendario> geser: http://paste.ubuntu-nl.org/52191/
<RainCT> geser: so motioneye doesn't need a rebuild either? (it has a bug task but it doesn't depend on libgif nor libungif)
<geser> RainCT: also no build-depends?
<RainCT> geser: no. Build-Depends: debhelper (>=4), imlib11-dev
<geser> Legendario: the best way to patch is that you can overwrite ROOT with a value when you call make from debian/rules
<geser> RainCT: ask the person who added the task why he believes it needs fixing in mentioneye
<geser> it might be that I missed something
<erable> Hi,
<erable> I have a problem with qdevelop package on Hardy: http://revu.tauware.de/details.py?package=qdevelop
<geser> what problem?
<erable>  qdevelop depends sqlite.On gutsy, libqt4-dev require libqt4-sql and libqt4-sql require sqlite:
<erable> Depends on: libmysqlclient15off (>= 5.0.27-1), libpq5, libqt4-core (>= 4.3.2), libsqlite0 (>= 2.8.17), libsqlite3-0 (>= 3.4.2)
<erable> It's OK
<erable> On Hardy, qt4-sql don't require sqlite (don't require mysql...) : https://edge.launchpad.net/ubuntu/hardy/i386/libqt4-sql/4.3.3-0ubuntu2
<erable> but description is:"This package contains the SQL module for Qt. It includes support for PostgreSQL, MySQL, and SQLite databases."
<erable> Depends on: libc6 (>= 2.7-1), libfontconfig1 (>= 2.4.0), libgcc1, libglib2.0-0 (>= 2.14.0), libqt4-core (=4.3.3-0ubuntu2), libstdc++6 (>= 4.1.1-21), zlib1g (>= 1:1.2.3.3.dfsg-1)
<geser> erable: on gutsy does it really link against two version of sqlite?
<geser> erable: try asking the kubuntu people in #kubuntu-devel, they should know better about qt4 than me
<erable> geser: ok. thanks
<somerville32> hi DktrKranz
<DktrKranz> hey somerville32 ;)
<Kmos> geser: can you approve my mail in motu-council ML ?
<Kmos> thanks
<somerville32> DktrKranz, Soren ACKed the ebox-network package upload
<DktrKranz> somerville32, ah. nice. I'm after some NMUs in Debian, but I'll have a look later. Thanks for the pointer :)
<ScottK> DktrKranz: Thanks for doing spamd.  You gonna do the *-security uploads too?
<Ubulette> hmm, bug 178152
<ubotu> Launchpad bug 178152 in xine-lib "[packaging] patches outside debian dir" [Undecided,Won't fix] https://launchpad.net/bugs/178152
<DktrKranz> ScottK, can we do them? I thought they were for ubuntu-security only.
<geser> Kmos: done
<ScottK> DktrKranz: We can prepare debdiffs and then they will upload.
<Kmos> geser: thanks
<DktrKranz> ScottK, spamd?
<ScottK> DktrKranz: Err dspam.  Sound better?
<ScottK> Sorry.
<DktrKranz> ScottK, IIRC, it was DarkSun88.
<ScottK> Sorry again.  Got my IRC nicks mixed up.
<ScottK> Argh.
<DktrKranz> heh, it happens, we live near :)
<ScottK> DarkSun88: Ping ^^^
<DarkSun88> ScottK: Pong.
<ScottK> DarkSun88: Thanks for merging dspam.  You going to do the *-security updates too?
<DarkSun88> ScottK: You're welcome, dont' worry. No.
<ScottK> DarkSun88: Please?
<slangasek> DktrKranz: hey, I see that you did a fair number of the rebuilds for the libcommoncpp transition?
<DarkSun88> No, I don't work to to the *-security updates too.
<DarkSun88> to do*
<DktrKranz> slangasek, I don't remember exactly, but it is highly probable.
<slangasek> DktrKranz: did you know that the new libcommoncpp hadn't made it in on sparc when you uploaded? :)
<slangasek> (but if you don't remember doing it at all, I guess you wouldn't :)
<slangasek> just mentioning because the packages needed to be reuploaded to get the proper dep on sparc
<DktrKranz> damn...
<DktrKranz> I'll have a look, thanks for the pointer
<DktrKranz> slangasek, in the case, a new rebuild is ok?
<slangasek> they're all reuploaded now so there's no more work to be done, but it seems inefficient to have had us both uploading them
<DktrKranz> Of course. Sorry for that
<lucas> slangasek: I'm just curious: there are no binNMUs in ubuntu?
<slangasek> lucas: nope
<lucas> ouch
<slangasek> yep :-)
<TheMuso> Bin nmus?
<geser> lucas: the advantage is we don't have problems with strict versioned dependencies ({$binary:Versions} vs ${source:Version})
<geser> TheMuso: binary non-maintainer uploads
<slangasek> TheMuso: in Debian, wanna-build can be told to rebuild a package for a particular architecture only
<slangasek> geser: Debian doesn't either, because those bugs have been fixed by now ;)
<TheMuso> slangasek: Right. I must say I'm against havng to upload a binary for an arch, unlike Ubuntu where we only upload source
<lucas> geser: sounds a bit like "we haven't invented the wheel yet. the good point is we don't have to care about wheels."
<slangasek> TheMuso: hrm?  who said anything about uploading a binary?
<slangasek> TheMuso: all we do is tell wanna-build to do a rebuild; so the resulting binaries are handled the same way as any others built on a buildd
<TheMuso> slangasek: Oh right
<ScottK> Speaking of rebuilds... slangasek: I understand sbuild on soyuz is getting patched today to not mess up the versioned depends on virtual packages anymore.
<slangasek> spiff
<blueyed> Hmm.. unstable has debhelper 6 and now I wanted to request a sync for a package which uses it already. Is it likely that debhelper 6 gets merged for Hardy? (have not found an open bug for this)
<ceekay> hi all.. i have a .deb of the intel ixgbe driver that i put together (because it's not available in feisty which i'm using)... i have an ixgbe-<version>-source.deb now, but i want to make a platform-dependent binary .deb so that i can put it on machines that don't have build tools... what tool should i be using for this?
<geser> blueyed: ask the last merger of debhelper
<somerville32> What does "ER" stand for?
<ScottK> somerville32: ENOCONTEXT
<somerville32> Like, when talking about authentication
<somerville32> or networking
<geser> somerville32: entity-relation if it's in database context
<slangasek> somerville32: hmm, I think a more specific context is needed than even that :)
<somerville32> ER injector?
<blueyed> doko: Will you merge debhelper 6 for Hardy? I just noticed that it gets used already in a package I'd like to get synced.
<slangasek> like, a specific protocol or technology maybe?
<DktrKranz> somerville32, in italian (well, Roman) slang, "Er" means "The", but I think you are not referring to it ;)
<somerville32> :)
<doko> blueyed: maybe prepare a patch, if the merge has conflicts?
<ScottK> somerville32: When you say ER, I think of this: http://www.astronautix.com/lvs/staarder.htm - probably not what you were thinking
<somerville32> ER is an overloaded acronym
<blueyed> doko: there are two conflicting files only: man/po4a/po/{debhelper.pot,es.po}
<Legendario> let me ask you guys something... can anyone download a .deb package from REVU?
<geser> Legendario: which deb? there are no debs on REVU
<Legendario> geser: and how does the .deb gets to repository?
<geser> Legendario: you mean the official repository?
<geser> there the buildds build them
<geser> but there is no buildd for REVU
<Legendario> geser: yes, the universe. Isn't the REVU a way to the repos?
<geser> !rev
<ubotu> Sorry, I don't know anything about rev - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<geser> !revu
<ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<geser> and if a package is seen by two MOTUs acceptable it get uploaded to universe where it gets build by the buildds
<Legendario> geser: what are the buildds?
<Legendario> !revu
<ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<geser> Legendario: buildd = build daemon, software which does the automatic building of binary debs
<Legendario> geser, so the REVU builds it againg and place it on the repo, right?
<geser> Legendario: REVU is only for reviewing of source packages
<emgent> heya
<geser> REVU is independent from the official repository
<KillerKiwi2005> hello is there a way to apply a default gonf key that dosnt require a logout login to apply it to the current user?
<Legendario> help !paste
<soren> KillerKiwi2005: Set it in the schema?
<Legendario> geser, so let's see if i got it... what i send to REVU is not the .deb package i've built with pbuilder which is under my pbuilder/result directory...
<Legendario> geser, it's only all the preparation for it. The building is done againg by the buildd when it reaches the repository
<Legendario> geser, is that right?
<emgent> for gnome people: https://edge.launchpad.net/~ubuntu-gnome-enthusiasts
<pwnguin> hmm
<pwnguin> the ZOMG kde posts on the planet are bad enough
<pwnguin> do we really need one for GNOME?
<KillerKiwi2005> soren: you mean set it for the user ?
<KillerKiwi2005> soren: that seems wrong...
<soren> KillerKiwi2005: No. In the gconf schema.
<KillerKiwi2005> soren: I do gconftool-2 `$GCONF_CONFIG_SOURCE` --makefile-install-rule, and that sets the defaults but the current user is not updated
<soren> KillerKiwi2005: You need to SIGHUP gconfd-2. dh_gconf should take care of all of this.
<soren> KillerKiwi2005: It might take up to 30 seconds before gconfd-2 will feel like looking at the new schema, though. If you're in a hurry, SIGINT it.
<KillerKiwi2005> soren: so kill gonf and it will do its thing on restart?
<soren> KillerKiwi2005: dh_gconf calls gconf-schemas, which in turn sends a sighup to all running instances of gconfd-2 (afair).
<soren> KillerKiwi2005: Well... That's not entirely true.
<soren> KillerKiwi2005: dh_gconf instruments the postinst with calls to gconf-schemas. The rest is accurate.
<soren> KillerKiwi2005: Considering that you're asking in this channel, I'm assuming this is in an Ubuntu package. Otherwise, much of what I'm saying doesn't apply.
<KillerKiwi2005> soren: lol, actaully no, although I will need to know for ubuntu as well
<the_belgain> is this the place to ask for help with the PPA?
<_MMA_> the_belgain: #launchpad
<the_belgain> thanks
<geser> Legendario: yes, that's right. To REVU you only upload the source package (.dsc, .diff.gz and .orig.tar.gz) but you should test-build it in your pbuilder so you know if it builds it hits universe
<persia> POX_: Indeed.  Thank you very much.  Our most duplicated outstanding bug for the last few releases may now be closed.
<ceekay> anyone know where i can find a tutorial on creating kernel module packages? i would like to package the intel ixgbe drivers for use on feisty... i have tried using dh_build and selecting "kernel module", then configuring debian/rules, then dpkg-buildpackage to build the source .deb, then module-assistant to build the binary... module-assistant fails on me
<persia> ceekay: I'd recommend looking at linux-ubuntu-modules source, searching the wiki, and asking in #ubuntu-kernel, as we don't really support other separate kernel modules (with m-a) very well in Ubuntu.
<crimsun> heh, I sent him here from -kernel ...
<crimsun> I would study how other packages handle it, like how the alsa-driver source package generates the alsa-source binary package, which is then usable by module-assistant
<persia> Right.  That makes it tricky :)
<TheMuso> somerville32: Thanks. I forgot that it was actually Friday morning my time. :p
<somerville32> :)
<ceekay> thanks crimsun and persia ... i know this is pretty non-standard.. i just want to do it the debian/ubuntu way if possible :)
<Legendario> !bot | Legendario
<ScottK2> persia: The soyuz fix for versioned depends on virtual packages is released.
<persia> ScottK: Saw that.  Excellent news for your perl issue.
<ScottK2> Yeah.  Saves me having to repack half the perl modules.
<ScottK2> Atually 2, not half
 * persia hopes someone with local sbuild and time will consider testing the patch from Debian bug #456934 for inclusion in our sbuild to match this.
<ubotu> Debian bug 456934 in sbuild "sbuild: Wrong handling of or'ed build-dependencies" [Important,Open] http://bugs.debian.org/456934
<RAOF> tjaalton: Ok.  Any particular reason for building all the modules?
<ScottK2> Atually/Actually
<RAOF> tjaalton: Apart from raw greed for bleeding edge drivers :)
<persia> ScottK: gaphor up too.  Thanks for all your help with that bug over three releases :)
<geser> persia: so you got the python dependency fixed?
<ScottK2> persia: You're welcome.  Thanks for fixing.
<ScottK2> persia: Can it be backported?
#ubuntu-motu 2008-01-17
<persia> geser: Not quite.  Hammer & tongs backport to python2.4
<persia> ScottK: backport to gutsy should work fine.  feisty maybe, but I think it requires too new a version of python-nose.  Might be suitable for a 2.4-forcing gutsy SRU, but that's getting more invasive than I like.
<persia> Any backport for Edgy or Dapper should definitely be based on the 0.9 tree, which package I never had working to anyone's satisfaction (including mine).  Given the time, and that it didn't work on release day, I doubt it's worth it.
<Solarion> heh.  Anyone else see the Amazon.com sponsored result for searching for 'jono bacon' (no quotes)?
<Solarion> on google
 * Solarion wants to see the "Low prices on jono bacon"
<zul> evening
<bddebian> Heya gang
<bddebian> Welcome NCommander :)
 * NCommander feels people
 * LaserJock runs
<bddebian> Well this can be a fairly quiet time :-)
<bddebian> Heya LaserJock
 * NCommander tries to figure out what he can do
<LaserJock> hiya bddebian
<bddebian> NCommander: Fix bugs! :-)
<bddebian> https://wiki.ubuntu.com/MOTU/TODO
 * NCommander reads the paperwork first
 * NCommander finishs signing things
 * Hobbsee reads hte MOTU ML.
<Hobbsee> bah.
<LaserJock> I read that as "Hobbsee reads the MOTU hate mail"
<somerville32> lmao
<bddebian> hehe
<somerville32> You're not happy with Kmos deciding to leave? :S
<minghua> he does?
<Hobbsee> So, Kmos is still very impatient, still hasn't learned anything, still says he'll won't do something, then does it.  They recommend more close supervision, as apparently this lot was close enough, and he was shown to violate his sponsorship conditions anyway.
<Hobbsee> all because he does sometimes get work right.
<somerville32> Hobbsee, You didn't read kmos' response?
<somerville32> He has decided to leave
<Hobbsee> somerville32: he's decided to leave before.
<somerville32> Ah
<Hobbsee> somerville32: he said he'd never file another sync request, months ago, too.
<Hobbsee> somerville32: he said he wouldn't touch MOTU sync bugs, yet does that as well.
<somerville32> "Hobbsee: I WON'T TOUCH AGAIN MOTU BUGS! :-) I'll remember you when I click on the mouse and try to do it."
<somerville32> You don't believe him this time Hobbsee? :P
<LaserJock> Hobbsee: I don't want to get into it again, but I thought the email was fairly clear, though I think we need an official MC vote
 * Hobbsee has little confidence in anything he says actually holding.
 * minghua just noticed today that he filed a bunch of Ubuntu-specific FTFBS bugs against Debian.
<Hobbsee> LaserJock: what do you read it as saying?
<LaserJock> Hobbsee: dholbach's email was fairly clear
<Hobbsee> minghua: ...yay.
<Hobbsee> LaserJock: it's made recommendations, pretty much the same as were already done.
<LaserJock> Hobbsee: no, it said he failed the "exam"
<LaserJock> that was my reading
<Hobbsee> LaserJock: right, so the recommendations != what they'll do as a result?
<LaserJock> there wasn't a recommendation of what to do, it was a summary of the situation
<Hobbsee> Recommendation:
<Hobbsee> <bullet points>
<Hobbsee> that's still a summary?
 * Hobbsee thought the summary was the first part, as "recommendation" is at the same position on the screen as "summary"
<LaserJock> hmm, I was thinking so, but there's really no recommendation there
<Hobbsee> there is a recommendation there - it's just not what most of us wanted.
<LaserJock> I wouldn't say that
<LaserJock> I don't see a recommendation for or against him leaving
<Hobbsee> well, perhaps not.  there seem to be recommendations through it, and the stuff titled "recommendation" really is a summary of hte summary.
<Hobbsee> okay, granted.
<ScottK> Hobbsee: dholbach clarified on IRC that summary would have been better than recommendation.
<ScottK> Good evening all.
<Hobbsee> ScottK: right, OK
<LaserJock> the original proposal had:"If the evaluation doesn't go well, we must ask him to no longer work on Ubuntu."
<ScottK> And I think we should follow through on that.
<LaserJock> for sure
<LaserJock> so I guess we just need a formal MC vote to confirm
<bddebian> Heya ScottK
<somerville32> When is the next MC meeting?
<Hobbsee> somerville32: they don't do meeting, they do calls.
<LaserJock> well, all they need to do is vote via email
<joejaxx> is there anywhere i can get a full list of all the FTBFS bugs for a certain arch?
<joejaxx> :P
<somerville32> lol
<joejaxx> sorry to interrupt
<joejaxx> :)
<LaserJock> joejaxx: thanks
<LaserJock> have you tried qa.ubuntuwire.com ?
<somerville32> http://qa.ubuntuwire.com/ftbfs/
<joejaxx> yeah but that shows all of them
<joejaxx> all the arches that is
<joejaxx> i guess i can write a script to spider the page
<joejaxx> thanks :)
<ScottK> Heya bddebian
<Solarion> heya laser
<LaserJock> hi Solarion
<ScottK> Anyone from motu-sru around?  I'd appreciate a look at: Bug 183661
<ubotu> Launchpad bug 183661 in libmail-box-perl "FTBFS in Gutsy/Feisty" [Undecided,New] https://launchpad.net/bugs/183661
<ScottK> LaserJock: Are you still here?
<LaserJock> yep
<ScottK> Making a package build that's currently FTBFS is pretty straight forward for an SRU, right?
<LaserJock> pretty much, please attach a debdiff
<ScottK> For a rebuild?
<LaserJock> well, hmm, I'm assuming it'll take a build1
<ScottK> Yeah.
<ScottK> I was hoping you'd ack it and trust me to write build1 correctly.
<ScottK> I just filled out all the required bits on the bug (TEST CASE, etc.)
<ScottK> But if you want a debdiff, I'll provide them.
<LaserJock> well, I know what you mean
<ScottK2> Your call.
<LaserJock> ScottK: has a rebuild be done in Hardy?
<ScottK> LaserJock: Yes.  It worked.
<LaserJock> same version
<LaserJock> ?
<ScottK> No.
<LaserJock> k
<ScottK> But FTBFS for the same reason.
<ScottK> sbuild attempting to satisfy versioned depends with a virtual package of insufficient version when a non-virtual package would have worked.
<LaserJock> ScottK: right, SRU ack'd
<ScottK> LaserJock: Thanks.
<LaserJock> ScottK: np, thanks for doing the leg work
<ScottK2> LaserJock: Thanks for the mail too.
<LaserJock> np
<slangasek> is there a convention for package numbering on ppas at this point?
<Burgundavia> slangasek: try not to make Adam Williamsons prediction come true?
<ScottK2> Burgundavia: What was that?
<slangasek> who?
<LaserJock> slangasek: I think something along the lines of 0ubuntu0ppa1 or similar
<Burgundavia> http://www.happyassassin.net/2007/10/24/mistakes/
<LaserJock> I got stuck on 0ubuntu0.7.10~ppaX
<LaserJock> for gutsy
<LaserJock> etc.
<jdong> why not 0ubuntu0~7.10~ppaX?
<ScottK2> https://help.launchpad.net/PPAQuickStart gives suggestions
<jdong> that way you don't potentially interfere with any SRU versions
<ScottK2> slangasek: While you're thinking about that, would you mind accepting libmail-box-perl into gutsy-proposed and feisty-proposed?
<jdong> slangasek: and looking at mpeg4ip in NEW if it has not been handled yet? :)
<LaserJock> jdong: that wouldn't interfere with an SRU would it?
<ScottK2> LaserJock: It might have a higher version number than an SRU
<jdong> LaserJock: Hmm you're right, 0ubuntu1 is the lowest with ubuntu in it
<LaserJock> I guess that's possible
<ScottK2> Actually not always for SRU.
<LaserJock> jdong: well, security often uses ubuntu0.1
<jdong> -1ubuntu0.1 is possible for SRU/security to -1
<ScottK2> Yep
<jdong> but -0 implies -0ubuntu1
<jdong> except maybe the firefox stuff?
<jdong> where we introduce a new upstream version as a security fix
<jdong> 2.0.0.11+2nobinonly-0ubuntu0.7.10
<jdong> yeah, Firefox uses -0ubuntu0.*
<jdong> so I guess 0ubuntu0~something is safer
<beerfan> Hi all. Is there an abbreviated instruction somewhere for packaging a python script?
<slangasek> ScottK2, jdong: <whimper>
<pochu> beerfan: does it use distutils?
<slangasek> sorry, I'm off-duty right now
<LaserJock> slangasek: just make a version scheme up
<slangasek> LaserJock: right :)
<ScottK2> slangasek: No problem.
<jdong> slangasek: fine :)
<beerfan> pochu: the script? I don't think so
<LaserJock> slangasek: just think *you* can provide the convention
<LaserJock> ;-)
<jdong> haha
<Burgundavia> slangasek: where is the distro sprint?
<ScottK2> Speaking of PPAs, how do I make it upload for Gutsy?
<jdong> don't you just target gutsy as the distro?
<LaserJock> ScottK: changelog
<ScottK2> Dunno.  Never uploaded to a PPA before.
<pochu> beerfan: take a look at http://wiki.debian.org/DebianPython/NewPolicy. You have examples there.
<jdong> ScottK2: yeah the distro field in the changelog
<LaserJock> I've only done gutsy PPA uploads
 * ScottK2 finally decides to take advantage of it now that the TOS are changed.
<LaserJock> I'm still backporting stuff
<StevenK> ScottK2: Yeah, target gutsy in the changelog
<StevenK> ScottK2: I can give you a .dput.cf snippet if you wish
<pochu> ScottK2: either put gutsy in debian/changelog, or in your dput entry put something like "incoming = ~siretart/ubuntu/gutsy"
<ScottK> StevenK: I got the dput.cf snippet from the PPA quickstart.  It looked sane enough.
<jdong> pochu: why ping siretart for that? :D
<pochu> jdong: just to annoy him ;)
<ScottK> jdong: Why ping him because pochu did? ;-)
<LaserJock> ScottK: it's probably easier to do it in the changelog
<jdong> :)
<pochu> ScottK: why didn't you ping him too? :)
 * Hobbsee pings jdong
<LaserJock> you need a unique version / release anyway
 * jdong thinks nick completion needs to do globbing!
<jdong> ping * :)
<pochu> lol
<LaserJock> heh
<slangasek> Burgundavia: Londinium Anticum
 * pochu continues studying
<Burgundavia> slangasek: thought as much, in Canonical Tower One
 * slangasek wonders if that's supposed to be like One Microsoft Way
<StevenK> I've not heard it called Canonical Tower One before
<Burgundavia> and now it is and shall be forever
<StevenK> I doubt that.
<ScottK2> Do PPA uploads get accepted mails sent out?
<Burgundavia> StevenK: silence
<RAOF> ScottK2: Yes.
<ScottK> RAOF: Thanks.
 * Hobbsee thought it was called The Evil Canonical Empire Headquarters.
<ScottK> Hi there Hobbsee.
<Hobbsee> hi ScottK
 * minghua renews his membership.
<ScottK> JFTR, I pretty much agree with what the Mandriva guy said about PPAs.
<Hobbsee> what was that?
<minghua> ScottK: What did he say?
<Burgundavia> /home/corey/trackpointsDec1007.gpx
<Burgundavia> /home/corey/trackpointsDec1107.gpx
<Burgundavia> /home/corey/trackpointsDec2107.gpx
<Burgundavia> /home/corey/trackpointsDec2107-2.gpx
<Burgundavia> /home/corey/trackpointsDec2307.gpx
<Burgundavia> /home/corey/trackpointsDec2607.gpx
<Burgundavia> /home/corey/trackpointsDec2607-2.gpx
<Burgundavia> /home/corey/trackpointsDec2907.gpx
<Burgundavia> /home/corey/trackpointsDec3107.gpx
<Burgundavia> /home/corey/trackpointsJan0108.gpx
<Burgundavia> ugh, wrong paste, sorry
<Burgundavia> http://www.happyassassin.net/2007/10/24/mistakes/
<Burgundavia> that one
<ScottK> Yeah. That one.
<Hobbsee> ah yes
<LaserJock> hehe, "Basically, Ubuntu has institutionalised the third-party repository." gotta love it
<StevenK> That isn't amusing, though.
<minghua> PPAs won't have a ubuntu.com address, will they?
<Hobbsee> no
<Hobbsee> they fixed that bug, finally
<minghua> I think he is exaggerating the problem.
<StevenK> So do I.
<Hobbsee> i assume if they use non-official PPA's, it'll just bail out, as it does for third party repos.
<minghua> The facts he said are true, but I don't agree with the predictions.
<LaserJock> well, I think the idea is right
<LaserJock> like what happens when somebody uploads a new gtk or qt that breaks stuff
<LaserJock> how do we debug that
<minghua> LaserJock: It would have a different version number, and should show in the bug reports.
<LaserJock> we don't even know what the version of the "official" packages are in bug reports
<minghua> (The good ones anyway)
<LaserJock> there's absolutely no way to know a priori
<StevenK> Apport reports the version for a crash, for example
<crimsun> we do if there is apport info
<crimsun> right, what steven said
<LaserJock> yes, that's true
<LaserJock> but apport isn't used for all that many bugs
<LaserJock> I'm guessing upgrade problems will be mitigated to some degree by update-manager
<StevenK> Certainly more than they were in Mandriva.
<ScottK> What prevents uploads to PPAs with the exact same version number as in the archive?
<LaserJock> I don't think anything does
<ScottK> So even that's no guarantee.
<LaserJock> it's just like a regular repo in that respect
<LaserJock> although it does look for .orig.tar.gz's from Ubuntu
<ion_> laserjock: If someone uploads a new Gtk or Qt to her PPA, itâs not as if Ubuntu users get that by default. Only the ones who have explicitly decided to trust the repo and use it.
<LaserJock> hehe
<StevenK> Right.
<ScottK> And unlike stuff like automatix, it's downloaded from a Canonical sponsored source.
<minghua> You probably can't upgrade to a version the same as your current one, but I know it doesn't matter for newly installed packages.
<LaserJock> "my new gtk fixes bugs X, Y, Z and is needed for my new version of Q"
<tjaalton> RAOF: exactly, need to test the new stuff for intel (and the rest too if possible)
<ScottK> In the same domain as one can get actual Ubuntu .debs from if you want.
<LaserJock> and soon enough the repos will be signed
<StevenK> I wasn't aware ppa.ubuntu.com resolved ...
<StevenK> (It doesn't)
<minghua> ScottK: But most users don't know that they can get official packages from LP.
<ScottK> StevenK: You can pull .debs off of Launchpad.
<ScottK> Agreed.
<LaserJock> minghua: no, but LP is official
<StevenK> ScottK: Right, but you can't point your sources.list at it
<ScottK> True.
<RAOF> tjaalton: So, presumably the various non-nouveau DDXs won't care about the new dri modules, but how about mesa?  Is this also going to require a git mesa snapshot to do anything interesting?
<minghua> LaserJock: I've also seen people claiming ubuntuforums.org "official".  So as long as the domain names differ, I don't worry too much.
<tjaalton> RAOF: I'm working on it :)
<LaserJock> minghua: worry about what?
<RAOF> tjaalton: Oooh, awesome.  In that case, hell yes!
<tjaalton> RAOF: do you have your auto-git scripts somewhere?
<minghua> LaserJock: Worry about PPAs breaking systems and upgrades (more then third-party packages already do, anyway).
<LaserJock> hmm, I do to some degree
<RAOF> tjaalton: Do you mean my "upload new snapshot to PPA" script, or "get new source" script (which is in debian/rules)
<LaserJock> we are free-hosting and building 3rd party repos
<minghua> Just look at the popularity of getdeb.net, and you'll know that users have enough ways to screw up their system already anyway.
<ScottK> It's hard to argue 3rd party repos are a bad idea when the sponsor of Ubuntu hosts them.
<LaserJock> and there's not much of a way for users to differentiate good repos from not-so-good
<tjaalton> RAOF: oh, right.. it is, I did notice it but didn't look too closely
<RAOF> tjaalton: get-orig-source is actually quite nice :)
<StevenK> ScottK: Conceptually, they're a great idea.
<tjaalton> RAOF: I think I'll upload the merge to git.d.o on debian-experimental branch, and then start working on that
<LaserJock> I think PPAs are great, I just think we also need a good way of deal with the "cons" involved
<RAOF> tjaalton: You can have my "do everything & upload to PPA" script, but it's unlikely to be very useful for you.
<RAOF> tjaalton: Cool.  I suppose I might want to ask for git access, then :)
<tjaalton> RAOF: sure, it's easy.. just pop in on #debian-x and ask :)
<tjaalton> RAOF: different irc server though
<RAOF> Of course, OFTC
<tjaalton> and set up an account on alioth.d.o
<tjaalton> if not already
<RAOF> I've wanted to do that before... not sure if I ended up doing it though.
<tjaalton> I guess #d-o is pretty silent right now
<tjaalton> uh #d-x
<ScottK> StevenK: They're a great idea, but also have risks.
<StevenK> ScottK: Right
<ScottK> I expect most of the people that'll use them well would have managed without them.
<LaserJock> I think they may be good for upstreams
<LaserJock> kind of a staging area
<StevenK> Exactly. A way to get more testing without people having to build it themselves.
<ScottK> For me they're good for backports testing.
<ScottK> I can backport a bunch of stuff and build against the backports.
<tjaalton> RAOF: the mesa HEAD has autotool support too, so it would be a good time to make it use that
<ScottK> So I just uploaded the current clamav package to the ubuntu-clamav PPA for Dapper/Edgy/Feisty/Gutsy.
<ScottK> Tomorrow, after they're built, I'll take a whack at uploading the redpends.
<RAOF> tjaalton: I'm somewhat ambivalent about that.  Autotools is not my idea of a good time.
 * ScottK2 would appreciate suggestions on what to do about checking for gcc bug PR28045... configure: error: your compiler has gcc PR28045 bug, use a different compiler, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
<ubotu> gcc bug 28045 in middle-end "[4.0/4.1 Regression] Bitfield, &&, and optimization => bad code generation" [Normal,Resolved: fixed]
<minghua> Huh?  What software is that!
<ScottK> Current clamav trying to be built on Dapper
<doluu> hello all
<ScottK2> Immediately followed by make: *** [config.status] Error 1 and the build died.
<ScottK2> hello doluu
<doluu> I've just build some packages from debian on Ubuntu
<doluu> and made change in debian/control to reflect original maintainer
<minghua> ScottK: Nothing besides a gcc SRU, as far as I can see.
<doluu> how I can get sponsorship?
<minghua> ScottK: Or maybe using gcc-3.[34].
<ScottK2> doluu: Have you checked to make sure these packages aren't already in Hardy?
<doluu> hardy have older version
<doluu> it's vzctl
<doluu> and vzquota
<minghua> !info vzctl hardy
<ubotu> vzctl: server virtualization solution - control tools. In component universe, is optional. Version 3.0.18-1 (hardy), package size 184 kB, installed size 1000 kB (Only available for i386 ia64 amd64 powerpc sparc)
<ScottK2> doluu: What version does Debian have?
<doluu> 3.0.22
<minghua> How come we have a version lower than etch?
<doluu> openvz's latest version  is also 3.0.22
<minghua> Oh sorry, etch has 3.0.11.  I misread as 3.0.21.
<tjaalton> RAOF: right, but at least some changes must be done to the old build system since the build failed when it got to i915tex
<RAOF> tjaalton: Ok.
<ScottK2> doluu: https://wiki.ubuntu.com/SyncRequestProcess is what you want.
<minghua> doluu: And come back and ask again once you properly filed a sync request.
<ScottK2> !info gcc3.4 dapper
<ubotu> Package gcc3.4 does not exist in dapper
<minghua> !info gcc-3.4 dapper
<ubotu> gcc-3.4: The GNU C compiler. In component main, is optional. Version 3.4.6-1ubuntu2 (dapper), package size 482 kB, installed size 4532 kB
<minghua> ScottK: :-)
<ScottK> Thanks
 * ScottK tries to build clamav again.
<ScottK> jdong: Can I backport a C compiler?
<StevenK> People might hate you.
<ScottK> StevenK: GCC 4.2 doesn't exist at all in Dapper right now, so if it suddenly pops up, nothing should use it?
<StevenK> Keep in mind gcc takes over 12 hours to build.
<ScottK> I'm gonna do some local testing here first.
<ScottK> Backports have the lowest priority anyway, so it's not like it would block much.
<ScottK> Nope.  That's not going to work.
<ScottK> I guess I need to figure out how to make clamav use gcc 3.4
<ScottK> But after I sleep.
<ScottK> Good night all.
<StevenK> CC=gcc-3.4 in the rules file, and Build-Depend on it?
<ScottK> Tried that (or close to that
 * ScottK gives it one more try.
<StevenK> You'll probably have to feed CC=gcc-3.4 to the configure call
<ScottK> That's where I was doing it, but I fed it the path, not just the compiler name.
<ScottK> Got through config that time, so that's progress.
<ScottK> StevenK: Thanks for the hint.
<StevenK> ScottK: No problem
<ScottK> And it built in the pbuilder.  Yeah.
<LaserJock> hmm, where did Fujitsu go?
<StevenK> He rode off on a golden pony
<LaserJock> heh
<Hobbsee> he's on a holiday with his parents.
<Hobbsee> for 2 weeks, iirc
<StevenK> Poor guy
<StevenK> :-P
<Hobbsee> hehe
<LaserJock> ewww, stuck with parents ;-p
<ScottK> Could be worse.  He could be stuck on holiday for two weeks with my children.
<ScottK> ;-)
<ScottK> Actually my kids are great, but we drove over 3,000 miles (4,800 km) over Christmas vacation.
<StevenK> Ahh. "Don't make me turn this vacation around!"
<somerville32> StevenK, 3 in the morning wouldn't be the same without you
<TheMuso> Parents are good (tm)
<StevenK> somerville32: I see.
<LaserJock> hmm, I wish we had a FTBFS list that didn't include hppa
<TheMuso> LaserJock: Why?
<StevenK> Because LaserJock doesn't care about it, I'm guessing.
<LaserJock> cause hppa is quite a bit of a majority of them
<LaserJock> and we're not really going to be fixing them in general
<StevenK> lynx -dump <url> | grep -v hppa ?
<LaserJock> they should definitely show up, but it'd be nice to have a view without them
<LaserJock> StevenK: yes, there's always good workarounds :-)
<dholbach> good morning
<LaserJock> just thinking for qa.ubuntuwire.com v2
<LaserJock> dholbach!
<TheMuso> Hey dholbach.
<dholbach> hey LaserJock, hey TheMuso
<ScottK> Good morning dholbach.
<ScottK> Good night everyone.
<vemon> do debian maintainers scan ubuntu packages for changes that aren't in debian? meaning: if i make a patch to ubuntu package are there any chanses of it getting to debian without me filing a debian bug about it?
<somerville32> vemon, doubt it
<dholbach> hey scottK
<ScottK> vemon: Depends a lot on the Debian maintainer
<vemon> any automagic tricks in launchpad for getting a bug to debian BTS also?
<Hobbsee> somerville32: PTS?
<somerville32> Hobbsee, Plumbing.... Trade... Supplies?
<TheMuso> lol
<Hobbsee> somerville32: package tracking system.  debian.
<ScottK> vemon: reportbug, but make sure the issue actually applies to Debian.
<slangasek> LaserJock: well, feel free to install the grub package from deb http://ppa.launchpad.net/vorlon/ubuntu hardy main and let me know if it eats your system for lunch, instead of just partially implementing a hardy spec like it's supposed to ;)
<vemon> scottk, sure. that's the first thing i check anyways since it's always easier to just sync the package from debian
<somerville32> Oh cool :)
<ScottK> vemon: OK.  Just saying.  Not everyone does that.
<ScottK> Good night (really).
<vemon> scottk, i don't doubt that :)
<somerville32> Me too
<somerville32> I need sleep :)
 * somerville32 waves.
 * slangasek waves to ScottK, somerville32 
<dholbach> night somerville32, night scottK
<vemon> hmm. doesn't reportbug just send a message to the ubuntu ubuntu-user@lists.ubuntu.com?
<vemon> referring to: https://bugs.launchpad.net/ubuntu/+source/reportbug/+bug/36186
<ubotu> Launchpad bug 36186 in reportbug "Trivial and non-trivial enhancements for bugreport" [Wishlist,Confirmed]
<LaserJock> not if you tell it to send to debian
<vemon> LaserJock, ok. thanks :) i'm at work now and unable to test it yet so i only have the inter-web to seek info from
<vemon> (sound like a bad excuse..)
<LaserJock> vemon: if you run reportbug --bts help you get a lits of bug trackers you can use
<LaserJock> so reportbug --bts debian should submit to debian I think
<LaserJock> ok, anybody know what email address system mail would be sent to if you use a smart host for smtp?
<LaserJock> I'd like to be able to use apps that send mail (reportbug for instance) but I don't want my system mail going into some unknown cyberspace
<persia> somerville32: Thanks for the continuing review of notecase.  it's very pleasant to see such evidence of collaboration.
<slytherin> am I the only one with timeout problems with launchpadlibrarian.net? I am not able to access build logs, bug attachments :-(
 * persia tries something
<Ng> is there any sane way to build a package from a folder that has a .bzr/ in it, without using bzr-buildpackage?
<persia> slytherin: I get things near instantaneously
<slytherin> :-(
<persia> Ng: debuild -i might be what you seek, but I've heard it's not always perfect.
<Ng> hmm, I'll probably just move the thing out of the way then
<Ng> thanks
<StevenK> Ng: Build the source package yourself using -I.bzr and then point pbuilder build at the .dsc?
<soren> StevenK: You mean -i, probably.
<rZr> 'morning
<StevenK> soren: Probably
<rZr> persia: hi, let me poke you on  http://revu.tauware.de/details.py?package=jaaa  because i am about to have no more free time soon
<persia> rZr: Nope.  I'm the last three successive reviewers, which I try to maintain as a limit (and only make exceptions when a package hasn't had a review in a really long time).  You need to get someone else's opinion about the package.
<rZr> ok I understand .. anyone here , :)
<persia> rZr: On the other hand, I advocated the last revision, so I suspect that there is likely only one more at most before it gets in (as that seems to be about normal for packages I advocate)
<rZr> ok thanx anyway
<emgent> heya
<emgent> jdstrand, heya :)
<emgent> someone saw Fujitsu?
<persia> emgent: On holiday.  Why?
<emgent> ok, i will mail him :)
<persia> emgent: He has very limited internet connectivity.
<emgent> argh! ok, thanks persia for all informations
<ion_> What kind of a holiday is one with limited Internet connectivity? :-)
<persia> ion_: The sort was might refer to as "Unfortunate"
<slytherin> I am just curious whether gcj is built on all arch. can anyone comment?
<geser> slytherin: the last gcj-4.2 built on all archs except hppa
<slytherin> geser: ok, thanks
<geser> slytherin: you can check it when you click through LP to the build status pages for a given source package
<mok0> When you call dpkg-buildpackage with the -B flag, why does it visit the build-indep target? It is only in the install-* targets that it seems to differentiate
<\sh> moins
<mruiz> hi all
<emgent> \sh, heya :P
<\sh> wow..since two days I'm working now on this freecom fsg-3 nas thing...and finally I managed to get openwrt running on this beast
<\sh> moins emgent
<emgent> openwrt++
<\sh> emgent, well, openwrt is not the problem :) the problem was the fsg3 thing...
<\sh> emgent, I needed to play around with this redboot stuff and had to recover the thing for round about 40 times or so
<\sh> emgent, and the good thing, I just fixed some packages for the openwrt stuff...need to send the patches upstream ;)
<emgent> \sh ++
<\sh> persia, reminder bug #164899 what should we do...close it or work on it?
 * persia wonders if ubotu plans to provide a URL
<ubotu> Launchpad bug 164899 in libao "libao.conf in gutsy is wrong. (alsa09 is set as default)" [Undecided,Confirmed] https://launchpad.net/bugs/164899
<persia> \sh: I thought LaserJock had sponsored that, and forgot about it completely.  Probably best to submit a patch and pass to the main SRU team, as it's certainly a regression from feisty.
<persia> \sh: With the new SRU policy, it will need a TEST CASE, etc.
<\sh> persia, ok..will put it on my todo now...
<persia> \sh: Thanks :)  By the way, why are you still not a member of ~motu-swat?
<\sh> persia, ah damn....I knew I forgot something :)
<persia> heh
<\sh> persia, subscription request pending approval :)
<\sh> emgent, testing your drupal5 security diffs...:)
<persia> \sh: I think it's likely about 10 days until he gets back...
<emgent> \sh, cool :P
<\sh> persia, you mean fujitsu?
<emgent> i asked some hours ago. :P
<emgent> <emgent> someone saw Fujitsu?
<emgent> <persia> emgent: On holiday.  Why?
<emgent> <emgent> ok, i will mail him :)
<emgent> <persia> emgent: He has very limited internet connectivity.
<rulus> If someone has time for a little review of http://revu.tauware.de/details.py?package=gtkvd that would be nice, I think I solved all the issues.
<\sh> does anyone know why motioneye is just build for i386?
<ScottK2> Good morning zul.
<\sh> ah sony vaio stuff
<\sh> guys, for rebuilding uploads we don't need to change the maintainer field, right?
<geser> \sh: motioneye> because debian/control says so: Architecture: i386
<\sh> geser, yeah it's just for the sony vaio cam so I think it's really only i386 related
<ScottK2> \sh: I haven't been.  I'm not 100% certain that's right.
<zul> hey ScottK2
<geser> it's also listed in P-a-s as i386 only
 * persia suspects Sony has probably released an x86_64 capable motion-eye compatible device, but doesn't know that anyone cares.
<\sh> where was this document to the ubuntu maintainer field policy?
<persia> \sh: https://wiki.ubuntu.com/DebianMaintainerField
<emgent> \sh, tested? :)
<\sh> emgent, I'm updating my gutsy pbuilders :)
<emgent> hehehe ok :P
<jdstrand> emgent: hi!
<emgent> jdstrand, hi! :P
<\sh> Seveas, ping...would you like to add a freenode cloak for me? :)
<PriceChild> \sh, he doesn't do them anymore
<persia> PriceChild: Who does now?  Any IRC Council member?
<PriceChild> \sh, could you give me your launchpad addy, and check you have a linked nick and email set.
<\sh> PriceChild, shermann :)
<PriceChild> persia, yes. Me, elkbunt.u, nal.ioth or lj.l
<\sh> PriceChild, the /msg nickserv info \sh is wrong...about the linked nicknames...\sh should be master...
<PriceChild> \sh, /msg nickserv help set master
<\sh> PriceChild, thx done
<LucidFox> Hmm. For some reason, an upload failed to close (LP: #) bugs
<TheMuso> LucidFox: Incorrect syntax perhaps?
<PriceChild> \sh, the cloak has been requested and should be turned on soon. A staffer will probably contact you to confirm you want ubuntu/member.
 * persia never got contacted for confirmation, so this may not occur
<persia> LucidFox: Did "Launchpad-Bugs-Closed:" appear in source.changes?
<PriceChild> persia, probably because the staffer was watching the channel you requested it in at the time.
<persia> PriceChild: I'm fairly certain that was true, but am less certain that isn't also true for \sh.
<PriceChild> uuu persia you remind me I should get the new version of gizmod uploaded...
<\sh> well...if we have ubuntu/motu that would be cool ;)
<persia> PriceChild: Oh.  Right.  I kept meaning to poke you about that and forgetting when you were actually about.  Only a couple weeks left.
<emgent> ^^
<PriceChild> \sh, nope, always ubuntu/member, nevermind if you were approved by edubuntu,kubuntu or motu
<\sh> PriceChild, I know...
<PriceChild> persia, its all "ready" in my ppa. Just the udev part.
<PriceChild> oh and licensing.... gah completely forgot about that
<persia> heh
<PriceChild> 3 day weekend... its going to be done
<LucidFox> No, Launchpad-Bugs-Closed doesn't appear. However, it was a merge so there are multiple entries, including Debian ones, and there's a Closes header
<LucidFox> http://launchpadlibrarian.net/11406974/f-spot_0.4.1-4ubuntu1_source.changes
<\sh> emgent, the patch for SA-2007-031 is again not correct :)
<emgent> uh?
<emgent> are u sure?
<emgent> http://drupal.org/node/198162
<\sh> emgent, if you apply the upstream patch for SA-2007-031 there is a bug inside...the fix is on http://drupal.org/files/issues/db_query_range.patch
<\sh> emgent, yeah..the patch is wrong :) that's why 5.5 came out with the fix for the fix of SA-2007-031 :)
<emgent> ok i understand
<\sh> emgent, in the patch of SA-2007-031 they wrote:
<\sh> +-      $result = db_query_range($sql, 0, variable_get('feed_default_items', 10));
<\sh> ++      $result = db_query_range($sql, 0, variable_get('feed_default_items', 10), $args);
<\sh> but the $args is wrong as you can see from the discussion on http://drupal.org/node/198321 :)
<emgent> ok \sh ++
<siretart> did we already settle in ubuntu on dh_iconcache vs dh_icons? which of those do we use?
<geser> siretart: dh_icons, I don't have dh_iconcache anymore in my hardy installation
<siretart> excellent. this means that http://patches.ubuntu.com/s/scorched3d/scorched3d_40.1d.dfsg-1ubuntu1.patch can be dropped now
<siretart> (the upload I'm currently preparing for debian is introducing a dh_icons call)
<ion_> Is scorched3d 41 coming to hardy?
<ScottK2> Good morning all.
<ion_> Good evening.
<ScottK2> My the coffee isn't helping yet.  What's the canonical method for finding the reverse depends of a package for a particular release?
<siretart> ion_: I'm currently building & uploading it for debian, will request a sync for that afterwards
<ion_> siretart: Great
<siretart> hey ScottK2. how are you doing?
<ScottK2> Heya siretart.  Not bad.
<geser> ScottK2: if apt-cache rdepends doesn't help, what about using grep-dctrl?
 * siretart uses revbuilddep() { grep-dctrl -FBuild-Depends,Build-Depends-Indep -s Package $1 -n /var/lib/apt/lists/*_Sources }
<ScottK2> siretart: Currently a little nervous waiting to see how my core-dev application works out.
 * ScottK2 writes that down.
<siretart> ScottK2: I'll keep my fingers crossed for you!
<ScottK2> thanks.
<leonel> ei ScottK2  2 good news  today ( clamav  and your applicarion )   me hopes for the best !
<\sh> ScottK2, gogogo for core :)
<zul> ScottK2: good luck
<ScottK2> Thanks all.
<PriceChild> Could someone help me get started (again) on REVU? The wiki makes me think that I should be able to recover my password already seen as I've been in the contributers group more than 24 hours. However revu tells me No REVU account for pricechild@ubuntu.com exists yet.
 * effie_jayx wants something to do :D
<ScottK2> PriceChild: You need to do an upload to REVU first
<PriceChild> ScottK, aha thanks.
<leonel> effie_jayx: where will be your   spanish motu talk ?
<effie_jayx> leonel,  it's now.. ;)
<effie_jayx> #cupie
<leonel> plop where ?
 * \sh goes shopping...bbl
<persia> PriceChild: just FYI, no point pushing gizmod to REVU: it wants an interdiff in the sponsors queue.
<PriceChild> persia, Something new to learn about :)
<persia> PriceChild: https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
<PriceChild> persia, thanks
<emgent> hello there
<LucidFox> Welcome, emgent
<philn> hi
<philn> where can i talk to PPA admins?
<Ng> philn: #launchpad
<geser> philn: #launchpad
<philn> thx
<ScottK> OK.  Here's one I've never seen before (this is GCC 3.4 in dapper) configure: error: C compiler cannot create executables
<ScottK> Any suggestions on how to troubleshoot that?
<ion_> Look at the configure log. Perhaps just some package missing.
<ScottK> ion_: So how do I get the configure log off of a buildd?
<geser> ScottK: url to the build log?
<ScottK> geser: http://launchpadlibrarian.net/11410627/buildlog_ubuntu-dapper-i386.klamav_0.41.1-0ubuntu2~dapper~ppa1_FAILEDTOBUILD.txt.gz
<ScottK> I didn't have that problem in my local pbuilder.
<geser> ScottK: CC=gcc-3.4 but no gcc-3.4 installed (Toolchain package versions: [...] gcc-4.0_4.0.3-1ubuntu5)
<ScottK> So I need to add it as a build-dep then.  Thanks.
<ScottK> Odd it would pick that then.
<mok0> I am somewhat confused as to what dpkg-buildpackage does to build packages, and the buildd systems. Does the buildd system distinguish between build-arch and build-indep (i.e. does not use the build target)?
<mok0> I don't see the point of having two build targets for indep and arch otherwise
 * ScottK head-desk.
<mok0> ... if all systems always used "debian/rules build"
<ScottK> That's what I get for starting something, sleeping, and then starting again without having fully documented what I did before the break.
<geser> mok0: iirc no, as there is no safe way if the package supports build-arch and build-indep or not (if I remember the discussion on the debian-devel-ml correctly)
<mok0> geser: Hm. I was trying to avoid my package doing a doxygen run when not building the -doc package.
<geser> mok0: but I don't know if this also applies to the ubuntu buildds
<mok0> geser: Maybe it's for a future/smarter implementation
<geser> or all packages transition to build-arch/build-indep
<soulrider> hello, im creating a deb file for sheepshaver. Im doing the checkinstall step now, but im not sure about what i should put in the group field, is it emulation?
<mok0> geser: yeah thats what I meant
<geser> !checkinstall
<ubotu> checkinstall is a wrapper to "make install", useful for installing programs you compiled. It will create a .deb package, which will be listed in the APT database and can be uninstalled like other packages. See https://help.ubuntu.com/community/CheckInstall - Read the warnings at the top and bottom of that web page, and DO NOT interrupt CheckInstall while it's running!
<geser> soulrider: checkinstall isn't liked here, so I don't know if somebody can help you
<soulrider> geser, thatw iki page doesnt really answer my question. I need to know what the groups field is used for
<geser> soulrider: I didn't used checkinstall yet, so I can't help you. sorry.
<soulrider> but isnt the group field generic for all deb packages?
<Hobbsee> soulrider: checkinstall isn't supported in here.
<soulrider> i mean, all packages should have one
 * Hobbsee would suggest trying the forums or something
<soulrider> what other ways do i ahve to create a deb package?
<LucidFox> soulrider> You can use dh_make on the source tree to "debianize" it
<LucidFox> the result, however, will most probably involve manual tweaking
<LucidFox> You can refer to the Ubuntu packaging guide: https://wiki.ubuntu.com/PackagingGuide
<ScottK> \sh: The claws-mail sync was not a good idea it turns out.  "Removed sylpheed-claws-gtk2 dummy packages" - We need those for Dapper -> Hardy upgrades.
 * ScottK just read about it on hardy-changes
<\sh> ScottK, oh shit..
<\sh> ScottK, hmmm..it conflicts/replaces now...
<\sh> lemme check...
<ScottK> But you need the transitional package.
<ScottK> package/packages
<\sh> ScottK, grmpf
<\sh> I'll get it fixed...
<\sh> damn...
<ScottK> \sh: Thanks for taking care of it.  It's good to work with people who will clean up after themselves.
<\sh> ScottK, well, this is one which can happen all the time, when you don't think about dapper -> hardy directly
<ScottK> Sure.  We all miss stuff.  The goal isn't being perfect, but fixing up after.
<\sh> at least I can blame myself...
<\sh> ScottK, readding the trans packages from gutsy to new claws-mail
<ScottK> Great.
<ScottK> \sh: Once that's uploaded, I want to backport that to Gutsy and build it against the new libclamav3.  Would you be up for doing some testing?
<\sh> ScottK, sure :)
<\sh> ScottK, I'll have still my t43 on gutsy...
<ScottK> Great.
<\sh> ok 3.2.0-2ubuntu1 should hit the buildd soon
<\sh> ScottK, do you know if vmware 1.0.4 is running on hardy?
<ScottK> No.  I'd ask zul.
<mok0> dholbach: ping
<\sh> ScottK, I'll try it just now...
<dholbach> mok0: pong
<mok0> dholbach: looking at your mmdb review now.
<mok0> dholbach: I can't reproduce the lintian warning
<mok0> dholbach: Even installed hardy version
<vemon> hi! i have a small problem with creating a patch. the autoconf version is different from what it was when the configure file was orignally written. now patch i created basically rewrites the whole configure file
<dholbach> hm, weird - is the changelog a symlink in one of the resulting packages?
<mok0> Yes I think there is some weirdness like that
<mok0> It's a cdbs build
<vemon> and i've only touched some source files and configure.in by hand
<dholbach> ah, hmmm
<vemon> so is there a "best practise" for a situation like this? :)
<mok0> dholbach: The other point: our ftp server was down for a couple of days without my knowing it
<dholbach> hehe :)
<mok0> grrrrr
<pochu> mok0: is that warning the 'changelog is a symlink' one? If so, ignore it. That's a hack in our cdbs so packages in the CD take less space
<mok0> dholbach: we're in a process of moving all servers to virtual machines and it's a mess
<dholbach> alright, nevermind then :)
<norsetto> mok0: le baladin? You certainly know more about italian beers than I do
 * dholbach hugs norsetto
<mok0> pochu: No, it's " To refer to the changelog, copyright, and other documentation files of another package that this one depends on, please symlink the entire  /usr/share/doc/<pkg> directory rather than individual files."
<mok0> ... and I don't know what it's thinking
<emgent> jdstrand i'd like talk with you about a project that i like build for motu-swat and ubuntu-security
<jdstrand> emgent: ok-- give me a sec...
<emgent> sure
<mok0> norsetto: did you google it?
<norsetto> mok0: no
<emgent> heya norsetto
<norsetto> mok0: why, its a joke? ... oh well ....
<pochu> mok0: sounds pretty similar, but I've never seen it.
<norsetto> emgent: heya emgent
<mok0> norsetto: nono, it's a real beer, but it's impossible to find
<ScottK> leonel: Are you able to do some python-clamav testing in Dapper?
<mok0> norsetto: I think I figured out the Build-Depends-Indep question
<mok0> Fish?
<norsetto> mok0: you mean is hand made in some small valley in the Alps by an handfull of desperate monks ?
<mok0> norsetto: yep :-)
<leonel> scottK Of course
<mok0> norsetto: "if we can't have women, we can have BEER"
<norsetto> mok0: I always have been ware of desperate monks
<ScottK> leonel: It's up and built in the ubuntu-clamav ppa.  Please let me know how it works.
<mok0> hehe
<leonel> scottK just let me clear some todos
<leonel> scottK ok  I'll do
<ScottK> leonel: Making a later python-clamav work in Dapper is gonna be painful.
<ScottK> leonel: No rush and please comment on the wiki after you test.
<leonel> scottK OK
<ScottK> Thanks
<emgent> dholbach, there are some security tracker for ubuntu security people now ?
<dholbach> emgent: I'm the wrong person for that question. keescook, jdstrand and \sh might know much better
<emgent> ok, forward to \sh && jdstrand
<emgent> :)
<jdstrand> emgent: ok I'm back
<jdstrand> dholbach: thanks
<emgent> well jdstrand
<jdstrand> emgent: yes we do have a tracker
<dholbach> ROCK ON Security Team! :)
<jdstrand> https://code.launchpad.net/ubuntu-cve-tracker
<jdstrand> emgent: ^^
<\sh> emgent, one of the things you should do is to join #debian-security on oftc, so you can see what debian unstable security maintainer are working on
<emgent> uhm.. only for CVE
<jdstrand> emgent: we are also working on an html report
<\sh> emgent, the second is -> jdstrand
<jdstrand> that pulls from ubuntu-cve-tracker
<\sh> emgent, most likely CVEs are issues also for drupal security announcements
<jdstrand> emgent: the branch to look at is 'master'
<emgent> i'm thinking to develope a system to grep RSS title with ${ARRAY} (in array all packages name maintained in ubuntu)
<emgent> RSS && mail object.
<emgent> we can know all rumors and test/fix it first
<jdstrand> emgent: you may want to look at what we have going in ubuntu-cve-tracker
<jdstrand> there is a README that describes what scripts we have and the process, etc, etc
<emgent> ok
<jdstrand> emgent: it may or may not overlap with what you want to do
<mok0> dholbach: I'll upload my latest version of mmdb, it may not have that lintian warning
<dholbach> mok0: OK
<emgent> thanks jdstrand && \sh
<jdstrand> np
<jdstrand> :)
<norsetto> mok0: Ok, I'm glad you got that; in case you didn't do it I can suggest you also check the debian policy, its a godsend for this kind of things
<mok0> norsetto: I find the information scattered all over that document...
<mok0> norsetto: guess I need to memorize it...
<norsetto> mok0: if you can memorise the debian policy I will buy you a le baladin
<mok0> norsetto: now you're tightening your promises
<norsetto> mok0: I'm, but you also need to memorise all the footnotes and appendices ...
<\sh> do we have a 32bit libselinux somehow?
<mok0> norsetto: hehe. Fortunately there is some logic to it
<norsetto> mok0: and addendums, and the python policy, the new python policy and the new new python policy too ;-)
<ScottK> Plus all the stuff that's no policy yet, but everyone knows you have to do.
<mok0> norsetto: ... and the old because you have to recognize when people are using an out-of-date standard...
<ScottK> no/not
<mok0> norsetto: anyway, I omitted the .la files from my other libraries in REVU
<mok0> ... and added that -D_REENTRANT flag
 * norsetto hugs mok0
<mok0> norsetto: ... I assume it needs to go in CXXFLAGS as well
<mok0> (if there is c++ code)
 * norsetto also hopes that mok0 will one day stop fiddling with his own packages and start working on some of the universe ones .....
<mok0> norsetto: I will
<mok0> norsetto: but there are a few to go
<norsetto> mok0: well, just stop writing code, a chemist writing code its ... a perversion ;-)
<mok0> norsetto: Unfortunately, most of the software we use in crystallography is closed source. My aim is to package as much as possible of the free stuff, so people can start doing development in a  more reasonable setting
<mok0> norsetto: It gets worse: I'm in a molecular biology department
<mok0> norsetto: these libraries are all needed by a very popular program "coot" (bug 176211)
<ubotu> Launchpad bug 176211 in ubuntu "[needs-packaging] coot" [Wishlist,Incomplete] https://launchpad.net/bugs/176211
<norsetto> mok0: popular amongst the 3 or 4 mad molecular biologists in the known world you mean ....
<mok0> norsetto: :-)
<norsetto> mok0: which apparently have all gathered in your bug report :-)
<mok0> norsetto: yeah, it's a conspiracy!
<norsetto> mok0: considering what coot means in english I would rather call it something else ;-)
<Amaranth> apachelogger: So how is Windows Live Writer?
<apachelogger> Amaranth: ?
<Amaranth> apachelogger: "Temporary-Post-Used-For-Style-Detection-Content-1776813585"
<Amaranth> apachelogger: that was on your blog, it's a Windows Live Writer thing
<apachelogger> Amaranth: kblogger-kde4 thingy ;-)
<Amaranth> Wow, they picked a stupid thing to copy :P
<Amaranth> People complain all the time about the crap polluting blogs
<mok0> norsetto: Fortunately, I'm not the developer of that, only the packager
<apachelogger> Amaranth: well, usually it is supposed to be a draft post
<apachelogger> but there is an issue in the current api implimentation for blogger.com
<apachelogger> so it got published
<Amaranth> blogger doesn't have draft posts?
<apachelogger> of course it does
<apachelogger> blogger is just alphaware ;-)
<apachelogger> *kblogger
<LucidFox> dholbach> Sure, my application isn't a pressing issue to me, I can reapply later. Do I need to withdraw my current application?
<dholbach> LucidFox: no... just follow up on it in a few weeks and that'll be fine
 * dholbach hugs LucidFox
<dholbach> thanks for asking
<LucidFox> Ack.
<dholbach> see you around
 * dholbach calls it a day
<RainCT> Hi
<pochu> If I'm about to upload a package from REVU to the archive, how does the NEW mail sent to -motu works?
<ScottK> \sh: I like reading hardy-changes much better now.
<\sh> ScottK, hehe :)
<\sh> ScottK, if something goes wrong, blame me ;)
<ScottK> Of course.  You touched it last now.
<\sh> and vmware is installed nicely and configure correctly...(with an fix for the vmware-any-any update) but starting vmware fails
<mok0> norsetto: any further comments re: gpp4?
<norsetto> mok0: as long as it builds and installs after the last change I'm still advocating you
<mok0> norsetto: cool, thx.
<\sh> RainCT, ping did you see my comment to your debdiff for motioneye?
<pochu> Should I just forward the NEW message, appending REVU in the subject?
<RainCT> \sh: yes, I'll upload a new debdiff right now :).
<\sh> RainCT, cool...ping me and I'm happy to sponsor it :)
<RainCT> \sh: I only develop with interpreted languages so I wasn't sure what was needed to be done there..
<\sh> RainCT, well, I just rebuild the package without the tightend build-dep on imlib11-dev...to be sure that it works :)
<RainCT> \sh: should the maintainer field be modified for the rebuild or just the changelog?
<bddebian> Heya gang
<geser> RainCT: as you are listed as a bug contact for ubuntu-dev-tools (and also worked on that package), what's your opinion to my requestsync-lp script from bug #147994?
<geser> Hi bddebian
<ubotu> Launchpad bug 147994 in ubuntu-dev-tools "requestsync should have a command line switch to use python-launchpad-bugs (instead of mailing)" [Wishlist,In progress] https://launchpad.net/bugs/147994
<bddebian> Hi geser
<\sh> RainCT, nope
<geser> RainCT: should I include it in the package as an addtional script or try to merge it with requestsync?
<RainCT> geser: I think it's a great idea :)
<RainCT> geser: ah. I would prefer if they were merged, and had a command line switch and a global variable to choose what method you want
<ScottK> But please don't change the default.
<geser> RainCT: I'll see if I manage to merge it before FF
<RainCT> btw, I have a script to check for reverse build dependencies ready (just the manpage is missing), but before I wanted to ask if I missed some existing solution to look for them
<geser> RainCT: I know only of an wrapper around grep-dctrl for it
<RainCT> geser: it's based upon that :)
<RainCT> but with --help and some other option
<geser> RainCT, ScottK: what's your opinion on making 'hardy' the default 'target release' for requestsync when none is specified. I got lazy to type everytime 'hardy' when using requestsync. Is it a good idea?
<ScottK> geser: I like the current way.
<ScottK> Once hardy is released, it'll be wrong again.
<RainCT> geser: perhaps add a global variable for this, too
 * RainCT likes global vars :P
<geser> ScottK: it still can be overridden on the commandline and one could backport a fixed ubuntu-dev-tools from hardy+1
<ScottK> Could, but that's more maintenance work.
<RainCT> then you will be able to just export what you want to be the default in .bashrc
<geser> ScottK: ok, I'll will leave it as it is currently
<\sh> hmm...Shared Folders from System/Administration/ doesn' work for me, can somebody confirm this?
<RainCT> \sh: debdiff uploaded
<\sh> RainCT, cool thx
<\sh> RainCT, uploaded thx :)
<RainCT> \sh: thanks :)
<DarkSun88> Hi all
<norsetto> Hola darksun88
<DarkSun88>   Hola norsetto :)
<frafu> persia: ping
<frafu> persia: In the following review on revu http://revu.tauware.de/details.py?package=mousetweaks you told me to differentiate minus and hyphen.Do you know where I can find any documentation about where to put a minus and where to put a hyphen?
<\sh> how correct are the informations on http://people.ubuntu.com/~ubuntu-archive/NBS/
<RainCT> frafu: in most cases you will just want to use \-
<RainCT> are there specifications (or whatever) for Nautilus' .hidden file somewhere?
<\sh> if anyone has time..and knows about mozart language...mozart-gtk is not really FTBFS but gives me a parse error and doesn't stop my pbuilder ;)
<afflux> hi
<afflux> the zd1211 package is very old and doesn't work since gutsy. It was last updated in March 2006 and has been removed from debian last month. I think we should remove that too. Where should I bring this up?
<ScottK> afflux: File a removal bug.  Details on what's needed are somewhere in the wiki.
<afflux> I'll try, thanks
<zul> besides zd1211 is supported by our kernel
<afflux> the zd1211-source package doesn't compile with m-a
<nxvl_work> scottK: how is that i see the karma scores of a team?
<ScottK> Dunno.
<nxvl_work> scottK: i mean a list with all the team members karmas
<RainCT> Debian is removing ttf-bitstream-vera (switching to ttf-dejavu instead), but it doesn't make much sense to do the same in Hardy now, or?
 * ScottK doesn't worry about karma.
<ScottK> Oh.  Still dunno.
<zul> afflux: it shouldnt
<pitti> hello folks
<pitti> according to https://wiki.ubuntu.com/MOTU/Packages/REVU I can ask here to get a reviewing account on REVU?
<pitti> so far I managed to do reviews via mail, but I get more and more sponsorees and mentees, so it would be good if I could add comments directly there
<ScottK> imbrandon: ping ^^^
<mok0> pitti: I seem to remember I emailed someone to get an account
<mok0> pitti: try emailing siretart@tauware.de
<pitti> mok0: ok, will do
<pitti> mailed
<\sh> Lutin, ping why is dcc not on the dad merge list? but on m.u.c.?
<afflux> zul: why shouldn't it? It is listed there.
<zul> because it was probably synced from debian
<Lutin> \sh: no clue
<\sh> Lutin, it was a XbuildY revision...could you check for it? :)
<Lutin> possible answer is that it moved to non-free, and I'm unsure whether dad checks it or not
<sistpoty> hi folks
<ScottK> sistpoty: Can you help pitti with getting a REVU account set up?
<james_w> hi sistpoty
<sistpoty> ScottK: sure
<sistpoty> hi james_w
<afflux> zul: i think so, but as I said, zd1211 was removed there and the zd1211 package in hardy, gutsy, feisty and edgy contains only the m-a package
<ScottK> Great
<pitti> ScottK, sistpoty: I just mailed siretart about it
<sistpoty> pitti: ok, great :)
<pitti> sistpoty: if you can do it right now and it's not much work, so much the better, of course
<zul> afflux: great then follow the necessary steps to get it removed
<sistpoty> pitti: sure, no problem
 * pitti doesn't know the procedure, sorry
<sistpoty> pitti: which email do you want (serves as your login then)
<pitti> sistpoty: martin.pitt@ubuntu.com is fine
<sistpoty> pitti: heh, you already have an account (maybe siretart was faster *g*)
<sistpoty> pitti: you can find out your password by logging in and entering no password
<pitti> sistpoty: ah, great; thank you!
<sistpoty> pitti: np... (and don't thank me, I did nothing *g+)
<pitti> sistpoty: ah, that worked; hm, that account must be ancient, and I never actually used it :)
<sistpoty> :)
<afflux> the MOTU/Removal wikipage states that "Packages removed from Debian will eventually be automatically removed". So does that mean I don't need to take action?
<afflux> (to get zd1211 removed)
<leonel> ubuntu dapper   6.06.2 now ??
<ScottK2> leonel: Yes
<\sh> a call to dh_icons is already in place in latest cdbs right?
<ScottK2> \sh: Yes
<leonel> scottK  great ..
<leonel> be back  got to go to pay  taxes ..
<Adri2000> \sh: why would it appear on DaD? DaD only shows packages with ubuntu changes, and buildX version are supposed to contain no change except a changelog entry
<\sh> Adri2000, but they are not synced automatically ... so they should be visible..
<Adri2000> unless that changed, before DIF, buildX packages as synced just like the other packages which contain no changes
<Adri2000> it's not really done "automatically", but at least they don't require a sync request
<Adri2000> s/as synced/are synced/
<\sh> Adri2000, they require a sync request now :)
<Adri2000> yes, just like the thousands of packages we haven't modified, and which do not appear on MoM or DaD
<\sh> Adri2000, when you check mom page...you see dcc was never touched before..the new version came from debian on 20071210 and DIF was 20071213 so there is a diff now between dad and mom
<Adri2000> yes, DaD never takes buildX package, being before or after DIF
<\sh> Adri2000, this will be fun :)
<Adri2000> \sh: anyway DaD will be shut down soon, to concentrate work on MoM. so unless I manage to convince Keybuk to not take buildX in MoM, you'll still have them in the list :)
<\sh> Adri2000, problem is after DIF we need those buildX stuff anyways...
<ScottK> \sh: After DIF from that perspective you need everything
<Adri2000> I don't agree. then why not also list the not modified at all packages?
 * norsetto -> dinner
<\sh> ScottK, what means everything? we need the never touched merges (with -XubuntuY) and during DIF hopefully all -XbuildY stuff will be automagically synced but after DIF you need the not catched -XbuildY packages to file sync reqs.
<\sh> ScottK, like the one I mentioned...
<ScottK> \sh: But that's equally of concern when any package gets update in Debian from -1 to -2
<\sh> ScottK, then I don't understand MoMs logic...could be, that this package just is a corner case, because it was released 3 days before DIF...
<james_w> sistpoty: ready to go?
<sistpoty> james_w: one second...
<ScottK> Sounds likely.
<james_w> The MOTU school session is starting now in #ubuntu-classroom if anyone is interested.
<geser> thanks for the reminder
<slangasek> everything you wanted to know about making perfect library packages, that-a-way --->
<bddebian> Doh
<vemon> where is it defined how a debian source package is built?
<vemon> i mean where does it say if ./configure or make should be run and when?
<bddebian> I missed the start, what are we nm'ing?
<slangasek> bddebian: http://www.potyra.de/library_packaging/example.c
<bddebian> thx
<RainCT> TheMuso: Hey. Can you merge my ubuntu-dev-tools branch into trunk please?
<\sh> StevenK, why did you drop the build-dep on libfaad-dev from libquicktime?
<StevenK> \sh: That's a hard question.
<RainCT> Kmos: are you around? I've a problem with ddclient
<\sh> StevenK, yeah...but I know gutsy is just too old to remember? ;)
<StevenK> \sh: Right. :-)
<\sh> StevenK, hmm...if I knew this answer I could try to build the debian version and sync it, instead of merging it ;)
<StevenK> \sh: Could it be main versus multiverse, or so?
<\sh> StevenK, well...now it's universe vs. universe ,-)
<\sh> but I remember libquicktime was in main during some releases
<geser> faad2 was in multiverse till the sync
<\sh> geser, ah ok :) now it's in universe and hopefully we can sync the lib
<leonel> scottK  removing  libclamav1  from dapper  automagically  installs libclamav2  from ppa     Nice
<ScottK> leonel: Are you getting libclamav2 or 3?
<leonel> scottK  clamav-base libclamav3 clamav-freshclam clamav-daemon
<ScottK> OK.  3 is good.  2 would have been bad.
<leonel> scottK libclamav3 installs fine  but  clamav-base  has that error
<ScottK> leonel: OK.  I'll look into that.
<ScottK> Thanks.
<gu_> hi
<somerville32> ScottK, Those security uploads haven't been sponsored yet. Should I bug someone about that?
<ScottK> leonel: Try to purge clamav-base and install again.  Looking at the clamav-0.92 source package, that template is correct.
<ScottK> somerville32: You might ping keescook or jdstrand
<ScottK> Of course I just did that...
<somerville32> :)
<jdstrand> somerville32: which updates?
<somerville32> syslog-ng
<jdstrand> somerville32: what is the bug #?
<jdstrand> or is there not one yet?
 * somerville32 is looking.
<somerville32> bug #183389
<ubotu> Launchpad bug 183389 in syslog-ng "[SECURITY] CVE-2007-6437 prone to denial of service attack" [High,Confirmed] https://launchpad.net/bugs/183389
<jdstrand> somerville32: cool and thanks for the debdiffs
<somerville32> no problem
<jdstrand> somerville32: these all build and have been tested on each release (and fix the problem)?
<somerville32> jdstrand, They all build :)
<TheMuso> RainCT: Has anybody merged your changes yet
<leonel> scottK  purged  cleared  downladed debs  tried to reinstall
<leonel> clamav-base template parse error: Template #1 in /tmp/clamav-base.template.53230 does not contain a 'Template:' line
<jdstrand> somerville32: ok, I have a few sponsored items in my queue, but should be able to get to it tomorrow
<ScottK> leonel: Thanks.
<somerville32> jdstrand, Okay.
<ScottK> leonel: I think it's a PPA bug as my locally built copy appears to have the template and the PPA version does not.
<leonel> ok  so .. just wait  for ppa ?
<ScottK> Let me look into it.
<ScottK2> leonel: I take it back.  The problem also exists in my locally built copy.
<mtp_> Is there any particular reason that my GPG has not been added to the REVU keychain yet? It's been part of the Launchpad group for a few days now.
<ScottK2> Anyone: I've got a problem where building clamav against the Dapper toolchain results in an extra line at the start of the clamav-base.templates file.  Any suggestions on where to look to find the problem?  Same package built against Gutsy/Hardy doesn't have the problem.
<joejaxx> is there anyway to get pbuilder-dist to accept regular pbuilder options? :)
<joejaxx> i want to stop pbuilder-dist from deleting the build directory
<joejaxx> :P
<ScottK2> leonel: Thanks for finding that.  Now that I've reproduced it locally, I'm working on it.  I'll let you know when it's fixed.
<ScottK2> joejaxx: I think you want the login option then.
<geser> joejaxx: pbuilder-${release} build --preserve-buildplace the.dsc doesn't work?
<joejaxx> ScottK2: it seems pbuilder-dist does recognize the pbuilder options
<joejaxx> unless i am incorrectly placing the options in the wrong order
<joejaxx> geser: i will try that hold on
 * ScottK2 has used login.
<joejaxx> hmm
<joejaxx> login does not seem like the option i want
<ScottK2> Then try what geser said.
<ScottK2> leonel: Fix uploading now.
<ScottK2> leonel: Please keep an eye on https://launchpad.net/~ubuntu-clamav/+archive and when you see clamav_0.92~dfsg-2~dapper1~ppa3 is built, try again.
<joejaxx> geser: that does not work for me
<geser> hmm
<joejaxx> well i am using pbuilder-dist hardy build [...]
<sistpoty> gn8 everyone
<joejaxx> Goodnight sistpoty
<joejaxx> cp: cannot create regular file `/var/cache/pbuilder/build//etc/hosts': No such file or directory
<joejaxx> works fine when i do not add the pbuilder opion
<joejaxx> option
<joejaxx> maybe i am adding it in the wrong place
<matttp> Is there a particular reason that REVU claims ``No REVU account for mtp@google.com exists yet.?''
<matttp> I've had a LP account for a while with the correct groups with GPG key registered for a while now.
<matttp> Have I missed something?
<ScottK> matttp: Have you tried to upload yet?
<geser> joejaxx: symlink pbuilder-dist to pbuilder-hardy and use it than like "pbuilder-hardy build ..."
<matttp> ScottK: Yep. :-)
<joejaxx> geser: yeap i was just about to see if that worked :P
<ScottK> OK.
<matttp> I see the file in ftp/incoming, but then it appears to be purged.
<matttp> Purged after about ten minutes or so.
<ScottK> We need a REVU admin then.
<joejaxx> geser: actually i do not think this will work as i will still have to specify that i want to build for hardy
<RainCT> TheMuso: no
<ScottK> imbrandon: Are you around?
<joejaxx> unless it looks at $0 after the dash for it
<geser> joejaxx: I use a simpler version of pbuilder-dist and call it "pbuilder-hardy build the_package.dsc" for building or "pbuilder-hardy update --autocleanaptcache" for upgrading
<joejaxx> and it does :D
<joejaxx> as i suspected
<joejaxx> pbuilder looks at echo $0 | cut -f 2 -d '-' :P
<joejaxx> ok
<joejaxx> bah
<joejaxx> that does the same thing
 * ScottK2 waits for the ppa buildd to catch up.
<Frimost> hi, I have uploaded my first package to REVU put it doesn't appear in the webpage for review and my account it's created either.
<Frimost> can someone help me?
<TheMuso> RainCT: Ok, will do it later. Got to go out now
<RainCT> TheMuso: okay, thanks
<ScottK> Frimost: How long did you wait to see it show up?
<Frimost> scottK: I uploaded it a couple days ago and today reuploaded it
<RainCT> good night
<ScottK> Frimost: You need a REVU admin then.  I don't think any are around at the moment.
<Frimost> today dput say me that the package was already there and I have force the upload
<Frimost> ok,  thanks
<ScottK> Frimost: That's because you have a .upload file in the local directory.  Remove that and try again.
<emgent> hello people
<Frimost> it's seem that my second upload worked! :)
<emgent> lol
<matttp> Is there a proper IRC channel for me to use if I want to modify packages in main as opposed to universe/multiverse?
<ScottK> #ubuntu=devel probably
<soren> #ubuntu-devel, even.
<ScottK> Right
<persia> nxvl_work: Re: bug #178046.  While I still don't like the solution from Debian, please edit this bug description to reflect the sync request.
<ubotu> Launchpad bug 178046 in dillo "dillo failed to unpatch" [Undecided,Confirmed] https://launchpad.net/bugs/178046
<nxvl_work> persia: the sync request is already reported
<persia> nxvl_work: In a different bug?  Please reuse bugs when you can to maintain the subscriber list and reduce bug churn.
<nxvl_work> Bug #183606
<ubotu> Launchpad bug 183606 in dillo "Please sync dillo 0.8.6-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/183606
<nxvl_work> persia: i wan't the reporter
<persia> nxvl_work: Ah.  That makes more sense.  I guess 178046 is just a dup now then.  Thanks for the clarification.
 * persia is again unhappy with requestsync for generating useless new bugs when there are already work-in-progress developer bugs for the same issue
<nxvl_work> persia: have you look at the NEW debian solution?
<nxvl_work> persia: i haven't say anything, wrong bug and package :P
<nxvl_work> persia: for dillo is the same :P
<yamal> what causes error msgs like "dpkg-source: warning: ignoring deletion of file <filename>"?
<yamal> happens when doing Â«dpkg-buildpackage -S -sa -rfakerootÂ»
<mok0> It means you have deleted a file in the local copy of the sources
 * yamal needs more sleep
<yamal> thanks mok0
<mok0> np
<imbrandon> ScottK: yup
<imbrandon> wasup?
<ScottK> imbrandon: matttp is having REVU troubles.
<imbrandon> yup, fixing him up now
<ScottK> Great
<imbrandon> looks like it needs a keysync and him to reupload
 * imbrandon is doing so
#ubuntu-motu 2008-01-18
<RAOF> You know, it'd be awesome if libdrm released 2.3.1 in time for hardy.  Nouveau >> nv.
<minghua> mok0: I was looking at torque's license yesterday, it feels like a 4-clause BSD license to me (without the parts that has expired).  And I'm not sure if 4-clause is good enough for main/universe.
<mok0> minghua: Hmmm
<mok0> minghua: Can we ask to get it into multiverse?
<slangasek> is anyone here using xen on hardy who would like to test out some grub changes for me?
<minghua> mok0: I have no idea, it may require ubuntu.com pages to add an advertisement clause.
<minghua> mok0: I've never dealt with 4-clause BSD before.
 * mok0 looks up torque's license
<mok0> Is 4 clause the same as 3-clause plus advertising clause?
<mok0> 3 and 4 are pretty much the same
<mok0> 3 is source distribution and 4 is binary
<minghua> Yes, I think the difference is exactly the advertising clause.
<mok0> 5  is not a problem
<mok0> 6 is the advertising clause
<mok0> 7 is the disclaimer
<mok0> but there are no real restrictions
<mok0> I suggest that we try to finish the package and get it to an archive admin
<minghua> mok0: You don't see "All advertising materials mentioning features or use of the Software must display the following acknowledgment" as a restriction?
<mok0> minghua: it's a duty, not a restriction.
<minghua> mok0: That part I agree. Nobody except the archive admin's words count anyway.
<mok0> minghua: yes
<minghua> Well... So GPL's source requirement is a "duty" instead of "restriction" too?
<mok0> It would not even interfere with Canonical's advertising of Ubuntu. Only if the product is mentioned as a selling point
<mok0> If used for research, it would not be "advertising"
<mok0> minghua: GPL source requirement, yes I interpret that as a "duty"
<mok0> you fulfill the duty, and there is no restriction
<mok0> But IANAL
<minghua> mok0: I'm not arguing that we can use it in our research groups, I'm arguing if Ubuntu can officially ship it in its archive.
<mok0> minghua: yeah, and I don't feel qualified to answer that question
<slangasek> advertising clause is long-accepted; it's goofy, but the practical impact is approximately zero
<slangasek> OpenSSL has the BSD advertising clause, for instance
<mok0> slangasek: take a look: http://revu.ubuntuwire.com/revu1-incoming/torque-0801141530/torque-2.1.8/PBS_License.txt
<minghua> slangasek: So debian/copyright suffice for the advertise requirement?
<slangasek> minghua: er, the BSD advertising clause almost *never* goes into effect
<slangasek> because the trivial way around it is to simply not advertise the features of this software ;)
 * minghua go read 4-clause BSD.
<slangasek> mok0: that license fails to be a free license because it only permits non-commercial, non-profit redistribution
<mok0> Say, Canonical creates an advertising flyer, where it says "Featuring the batch system Torque", they'd have to put a footnote with the clause in
<mok0> slangasek: points 1 and 2 have expired
<slangasek> mok0: oh, right, sorry :)
<mok0> fortunately
<slangasek> yeah, so 6) is "BSD advertising with the serial number filed off"; the requirement is the same, only the name of the institution is different
<slangasek> the references to 6) /from/ 3) and 4) are odd, but I think are satisfied by shipping the license in debian/copyright, yes
<mok0> slangasek: so, what's the verdict, in your opinion?
<slangasek> still reading the whole license
<mok0> slangasek: that whole license is weird
<slangasek> mok0: it's a BSD license that's been modified by an amateur
<slangasek> and by "amateur", I probably mean "lawyer"
<mok0> slangasek: :-D
<mok0> slangasek: It's paid for with government money, anyway
<mok0> US government, that is
<LaserJock> ScottK: pingaroo
<ScottK> LaserJock: Pongero
<LaserJock> regarding clamassasin
<ScottK> yeah?
<LaserJock> this is Feisty only?
<ScottK> Yes
<ScottK> Gutsy + is fixed and Dapper/Edgy have an old enough clamav it's not a problem
<LaserJock> right
<LaserJock> I wonder how easy it'll be to get testers
<ScottK> I'm going to backport the new clamassassin in backports, but I don't think it's right to paper over SRU worthy bugs with a backport.
<LaserJock> seems like most people who'd have hit the bug would've changed that option or moved to something else
<ScottK> I'd really love it, actually, if you'd tell me no.
<LaserJock> I agree
<ScottK> But I want to DTRT
<LaserJock> it would seem to me that this would really only be relevant for new Feisty installs
<ScottK> Of which it'd be stunning if there were any at this point.
<ScottK> LaserJock: Here's my clamav plan for world domination: https://launchpad.net/~ubuntu-clamav/+archive
<ScottK> Fun day's work.
<ScottK> leonel: The revised clamav PPA upload for dapper is built, please test again.
<LaserJock> these are the times that I wish we could issue package errata just to document silly things for people without having to go through the mess of a new package ;-)
<ScottK> Please tell me SRU denied, work around is to manually edit the config.
<ScottK> 46 uploads in one day is not so bad.
 * ScottK is waiting for the PPA denial of service police to show up.
<LaserJock> yep, looking at the criteria on the wiki page it really doesn't rise to a "high-impact" bug
<ScottK> Excellent.
<ScottK> Please mark the bug and I'll move on.
 * ScottK rejoices in the power of not being the one who has to decide.
<minghua> ScottK: Did you eventually use gcc-3.4 to compile on dapper?
<ScottK> minghua: I did
<minghua> Good to know.
<LaserJock> ScottK: ok, I think that should be clear enough
<ScottK> Thanks.
 * LaserJock wonders how likely he is to get roasted by users for doing is first SRU rejection
<ScottK> At least there's no confusion now.
<minghua> Most users don't know such a thing as "SRU request" exists anyway.
<minghua> BTW what is a pingaroo?
<LaserJock> well, it's a kangaroo/ping hybrid
<LaserJock> it's a ping that kinda hops around
<minghua> Oh.  I thought it is a ping that use kangaroos, instead of pigeons, as the packet carrier.
<LaserJock> kinda, more bouncy that way
<LaserJock> man, StevenK needs to stop upload config-crown-beach, I keep reading it as config-crown-royal
<StevenK> Mithrandir uploaded it before I did, so nyah
<StevenK> Anyway, Crown Beach is a codename
<ScottK> leonel and sommer and anyone else interested in clamav on Dapper: Testing needed: Bug #183914
<ubotu> Launchpad bug 183914 in dapper-backports "Please Backport clamav-0.92~dfsg-2 from Hardy to Dapper" [Wishlist,Confirmed] https://launchpad.net/bugs/183914
<bddebian> Heya gang
<LaserJock> StevenK: I noticed a number of config-* today
<ScottK> jdong: I'd like confirmation that we can do the above ^^^ without special permission from the tech board or something.
<StevenK> LaserJock: And?
<LaserJock> nothing much
<LaserJock> I wonder what they are configuring, but I'm not really up on UME
 * imbrandon yawns
<StevenK> LaserJock: They're tiny packages. I suspect it wouldn't be hard to find out. :-)
<mok0> Goodnight, people
<bddebian> Gnight mok0
<LaserJock> StevenK: you've got a point ;-)
<leonel> scottK clamav-base installed fine   but  python-clamav   pulls  libclamav1
<leonel> The following NEW packages will be installed:
<leonel>   clamav-freshclam libclamav1 python-clamav
<leonel> and only  clamav-freshclam   comes from PPA
<Hobbsee> greetings
<bddebian> Heya Hobbsee
<bddebian> Hmm, chrpath is change RPATH?
<ScottK> Heya Hobbsee
<RAOF> bddebian: Yup
<lifeless> I got kara attuned last night ;)
<StevenK> lifeless: Huzzah
 * StevenK is probably doing Dire Maul tonight
<bddebian> Hrm.. I wonder why chrpath /usr/lib/btanks btanks   causes RPATH to be ' '
<slangasek> bddebian: yes; with RPATH being the third thing one is likely to want out of objdump -p $lib. ;)
<slangasek> bddebian: because you left out the '-d' option?
<bddebian> Sorry, this is what she has in rules: chrpath --replace /usr/lib/btanks btanks
<bddebian> slangasek: Were you going to talk about RPATHs today? :)
<joejaxx> grr
 * joejaxx should make a mptstatus-ng package
<joejaxx> :\
<joejaxx> the current one does not work on newer hardware
 * bddebian should have asked for removal of ladder.app and lapispuzzle.app instead of trying to adopt them.. :(
<joejaxx> what are those?
<joejaxx> games?
<bddebian> Lame games
<bddebian> I tend to want to remove everything, then I get yelled at :_
<slangasek> bddebian: well, I was going to throw in a passing reference, but we moved on and it wasn't that important
<bddebian> Err :-)
<slangasek> ... because you shouldn't usually be using rpath at all
<slangasek> anyway, I don't see why it should behave that way using --replace
<slangasek> try running the command by hand to see if you get the same result?
<bddebian> Well aye but it has libraries that shouldn't necessarily be in /usr/lib I guess
<bddebian> I also get "foo shouldn't be linked to bar" stuff but I can't get rid of them.  It's an smake package :(
<slangasek> bddebian: I maintain that there's no such thing as a library that shouldn't be in /usr/lib
<bddebian> Seriously?
<bddebian> I'm down with that
<minghua> I think it's pretty common to get "shouldn't be linked to libfoo" warnings these days?
<slangasek> having a heirarchical namespace for libraries causes subtle bugs, and I think we're better off without, no matter how trivial one might consider the lib
<slangasek> as for smake, don't look at me
<bddebian> Actually I lied, it's scons.. :-)
<lifeless> run
<lifeless> run screaming
<bddebian> I don't know why she does lib_dir=$(CURDIR)
<lifeless> run screaming and waving your hands
<bddebian> *aaaaaaaahhhhhhh*
 * mneptok waves his claws
<bddebian> slangasek: If I did that would I have to create a libs package?
<mneptok> DANGER WILL ROBINSON!
<bddebian> Removing the libs from SConscript doesn't help with the shouldn't be linked errors either :(
<LaserJock> I don't care much for libraries
<bddebian> I hear ya brother :-)
<LaserJock> I wish I could deal with them better
<bddebian> Who's the gnustep lover around here?
<LaserJock> but licensing is a bugger with GPL 2 vs 3
<LaserJock> figuring out if libs should be build, soname "stuff", etc.
<LaserJock> *built
<bddebian> I FINALLY got the soname stuff figured out a while back, thanks to ajmitch
<joejaxx> mneptok: LOl
<mneptok> bddebian: i took GNUstep to the prom, but only out of pity.
<bddebian> heh
<bddebian> Actually I think I argued the RPATH point with Baby once before and lost
<LaserJock> oh for goodness sakes
<LaserJock> I can't wait until Saturday is done
<LaserJock> I got Mitt Romney talking on my phone while Obama is on the TV
<bddebian> hah
<LaserJock> can't get rid of these people :-)
<LaserJock> I'm from Montana, we aren't used to national politicians even being in the state ;-)
<bddebian> Hahah, from README-linux.txt:
<bddebian> 1) This game must be built with scons build system, no matter you like it or not. You
<bddebian> have no choice. Autotools & family is stupid crap and I hope it'll die soon.
 * bddebian almost chokes on his own vomit
<StevenK> But but, scons is worse!
<mneptok> better that choking on someone else's. *shrug*
<mneptok> *than
<StevenK> Ew
<bddebian> StevenK: Amen brother
<LaserJock> mneptok: true ... but disturbing
 * RAOF balks at the concept of "worse than autotools"
<mneptok> LaserJock: "True, But Disturbing" is the working title of my memoirs.
<jdong> ScottK: which C compiler?
<slangasek> bddebian: libs package> not necessarily
<ScottK> jdong: That turned out not to be needed. I was thinking GCC 4.2
<ScottK> jdong: What I'm more interested is breaking the no libraries rule with a clamav (including libclamav) backport
<slangasek> RAOF: clearly you haven't worked enough with scons then :P
 * RAOF hasn't worked with scons *at all*, and take steps to ensure the continuance of this state of affairs.
<LaserJock> I've worked with autotools and cmake a bit, but not scons
<jdong> ScottK: clamav I'd say is fine, as long as rev deps are investigated
<jdong> ScottK: most other distros that come with clamav will track upstream's releases
<LaserJock> ah dang
<LaserJock> I was gonna file some backport bugs
<LaserJock> but one of them is a lib
<LaserJock> and I was hoping to get rid of my PPA packages :/
<ScottK> jdong: OK.  Well I've had the PPA buildd gasping for air for the last 24 hours building all the rdepends.
<ScottK> LaserJock: Depends on the lib.
<jdong> ScottK: fun :)
<LaserJock> well, the lib is only used by the package I'm wanting to backport
<jdong> LaserJock: libs that have no/few rev-deps, I'm pretty cool with
<LaserJock> ah
<jdong> LaserJock: i.e. pairs like libtorrent+rtorrent
<LaserJock> then it probably would work
<LaserJock> this is gchemutils and gchempaint
<LaserJock> which are now even in the same source in CVS
 * bddebian wonders if Baby would kill me if I took out the rpath crap from btanks
<bddebian> Does scons support anything like DESTDIR?
 * RAOF recinds his previous balkage.
<guest22_> Any MOTUs willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once, so it should be very close to being acceptable.
<emgent> heya
<guest22_> bddebian: Thanks for the review. (Your comment about README.Debian is noted - I'll make a note to standardise it for the next version.)
<bddebian> NP
 * bddebian 's eyes bleed
<StevenK> Reading SConscript files?
<bddebian> How'd you guess? :)
<lifeless> welcome to the army
<bddebian> I can't freakin' take it
<TheMuso> lol
<bddebian> Marine Corps boot camp was less painful
<bddebian> Should libraries carry the same RPATH?  It appears to me that the SConscript file is hardcoding RPATH to '.' when building the libraries.
<lifeless> bddebian: yes, but where you a Sconscript then ?
<bddebian> Oohh, it barfs because /usr/lib/btanks doesn't exist in the build environment
<joejaxx> building library packages is fun
<bddebian> This isn't a library package, it just has it's own libraries :-)
<bddebian> Gaaaaah, how the f**k does this thing wind up with an RPATH=' '...........
<bddebian> Gnight folks
<warp10> Hi all!
<dholbach> good morning
<TheMuso> Hey dholbach.
<dholbach> hey TheMuso :)
<geser> good morning
<dholbach> heya geser
<geser> Hi dholbach
<Sarge31> Hello !I have a problem with REVU, the livemix page is broken (http://revu.tauware.de/details.py?package=livemix) ! What can I do to fix it ?
 * TheMuso looks
<TheMuso> I Nothing I can do to fix that
<TheMuso> You will have to wait till a revu admin is around
<TheMuso> And I am not sure one is at this moment
<geser> isn't livemix already in the archive?
<geser> !info livemix hardy
<ubotu> Package livemix does not exist in hardy
<geser> livemix is still in binary NEW
<geser> Sarge31: is the livemix package on REVU a different one than on the archive?
<Sarge31> it is possible that there is a defferance because Michael Bienia has made a version : https://launchpad.net/ubuntu/hardy/+source/livemix/0.49~rc2-0ubuntu2
<geser> Sarge31: that's me :). livemix was missing a build-dependency
<Sarge31> the first version of live mix should be in the repository soon !
<Sarge31> @gesser yes it true ;-) I miss it !
<Sarge31> I think that I anderstand better the problem !
<Sarge31> my last upload 1304 will be parcially deleted due the gesser upload, then is it possible to completly delete it ?
<geser> Sarge31: REVU and the Ubuntu archive are independent
<Sarge31> then way revu says Â« directory (/var/revu/revu1-incoming/livemix-0801171702/) of upload (1304) not found Â»
<geser> I don't know, you'll need to wait for a REVU admin
<Sarge31> Finaly I don't know way but there is an incorrect (parsial ?) release, abd the link http://revu.tauware.de/details.py?upid=1192 will work !
<Sarge31> Yes, will a revu admin connect here or shouls I send an email on ubuntu-motu@lists.ubuntu.com ?
<yamal> yetâ¢ anotherÂ® package is awaiting review: http://revu.tauware.de/details.py?package=sabnzbdplus - thanks!
<persia> reminder: MOTU meeting in #ubuntu-meeting in 5 minutes
<geser> 5 minutes? not 65 minutes?
<persia> Err.  Right.  Sorry.
 * persia hides
<TheMuso> Yeah that didn't seem right to me either.
 * persia archives the broken livemix entry on REVU
<TheMuso> ooo. UI for PPA removal will be in staging later today.
<persia> So we've just gotten a new lintian, and it, for reasons I don't understand, allows RPATH referencing /usr/lib/games/<package>.  Does anyone have a good reason why libraries shouldn't be in /usr/lib?
<persia> Err.  Nevermind.  I misread /usr/lib/games/... as /usr/games/....   Sorry.
<TheMuso> heh
<proppy> oy
<persia> OK.  Having double checked the timezones this time: MOTU Meeting in #ubuntu-meeting in 10 minutes.
<gpocentek> ember: I'd like to have the gnumeric merge done, could you tell me if you have something ready, otherwise I'll probably merge the package today or tomorrow
<TuxCrafter> hello guys
<TuxCrafter> yesterday i got a Intel(R) Celeron(R) M CPU 410 @ 1.46GHz
<TuxCrafter> so today i was getting cpu stepping to work
<persia> Hey TuxCrafter
<TuxCrafter> but all the start up scripts were not compatible
<TuxCrafter> i had to add a few lines
<TuxCrafter> now it works
<TuxCrafter> chages to /etc/init.d/loadcpufreq
<TuxCrafter> and
<TuxCrafter> changes to /etc/default/cpufrequtils
<TuxCrafter> i can create a patch for the scripts? but will it be accepted
<persia> TuxCrafter: Best way to get it in is to submit the patches to a bug, and get a few other people to test.  Even better if you can get some testers with other CPUs to give "doesn't break anything" feedback.
<TuxCrafter> How can i check the script that are used upstream
<persia> If it fixes a problem for some people, and doesn't break anything for others, and is visible, it will likely be accepted.
<persia> TuxCrafter: `dpkg -S $filename` will help you to identify which package owns a file, and `apt-get source $packagename` will download the source for the package.
<TuxCrafter> persia: got that
<TuxCrafter> creating the patch now
<Ng> not that they shouldn't be fixed if they are wrong, but aren't those scripts largely redundant these days? I have neither and yet my CPU (also a Pentium M) gets scaled by the cpufreq kernel modules
<TuxCrafter> persia: what diff options does ubuntu motu prefere?
<pochu> debdiff, or unified diff
<TuxCrafter> persia: diff -uNr ?
<persia> TuxCrafter: debdiff is best, but for that you want to also update the changelog, etc.  If you aren't up for that diff -urN works, and ask someone to help you make a debdiff from the patch.
 * rZZZr uses -BurN :)
<TuxCrafter> rZZZr: i will add the B
<persia> rZZZr: That doesn't work if you are fixing a syntax error in debian/rules due to eight spaces not being a tab character :)
<rZZZr> persia: true, mr knowledge :)
<Hobbsee> excellent!
 * Hobbsee puts her pitchfork back
 * persia douses Hobbsee's torches
<zul> what pitchfork?
<Pici> pitch.fork()
<Hobbsee> zul: my pitchfork.  to use on the MC, in the event of no decision.
<dholbach> MOTU Q&A session in 8 minutes in #ubuntu-classroom
 * Hobbsee wonders if Kmos has seen the news yet
<TuxCrafter> persia: I got my patches readdy
<TuxCrafter> should i create a bug report
<TuxCrafter> and add the patches
<Kmos> Hobbsee: yes =)
<Hobbsee> heh, happy about it?
<Kmos> Hobbsee: I'm.. i think you too
<TuxCrafter> Hobbsee: https://bugs.launchpad.net/ubuntu/+source/cpufrequtils/+bug/184015
<ubotu> Launchpad bug 184015 in cpufrequtils "add celeron m (p4-clockmod) userspace frequency support to loadcpufreq and cpufrequtils init scripts, patch included" [Undecided,New]
<slytherin> man-di: FYI ... lucene2 compiles with GCJ. I am not sure of unit tests because I had those disabled to avoid the FTBFS faced in Ubuntu pbuilder.
<TuxCrafter> is this sufficient information
<Hobbsee> TuxCrafter: you probably want to send those to debian, as ubuntu takes that directyl from debian, with no changes
<TuxCrafte1> Hobbsee: thanks for the advice i just sent a mail to the authors and the debian maintainers
<Hobbsee> TuxCrafte1: cool :)
<LucidFox> Yay! mpeg4ip has finally been accepted!
<LucidFox> although mpeg4ip should be in multiverse, not universe
<LucidFox> due to build dependencies in multiverse
<jdstrand> emgent: hi!
<jdstrand> emgent: just wanted to let you know I am going through your updates now
<TuxCrafte1> bye guys
<warp10> If a package depends (or build-depends) on a package in multiverse, does it always need to stay in multiverse as well?
<Hobbsee> yes
<emgent> hello there
<warp10> Hobbsee: ok. Thanks :)
<bddebian> Heya gang
<hellboy195> hi, I'm currently doing a merge. If I don't have any patches to apply I also don't need a build depend on dpatch right?
<LucidFox> hellboy195> Indeed
<hellboy195> LucidFox: thx
<LucidFox> Did the Debian original have any patches?
<ScottK> hellboy195: If dpatch is called in debian/rules then you need to depend on dpatch even if there are no patches.
<LucidFox> Ah, yes. Forgot about that.
<hellboy195> ^^ np. Ubuntu had one patch but now it's included into the programm so no more need I suppose
<LucidFox> Yes, since it's included upstream, there's no need. If the Debian version didn't build-depend on dpatch, there's no need to change that.
<geser> Heya bddebian
<ScottK> hellboy195: If Ubuntu added dpatch, then it can be dropped,  If it came from Debian that way, then leave it.
<hellboy195> k, th
<hellboy195> x
<bddebian> Hi geser
<jdong> am I the only one to feel that quilt is cumbersome to use?
<Hobbsee> no
<jdong> I feel better :)
<bddebian> jdong: Nope
<jpatrick> simple-patchsys ftw
<jdong> both simple-patchsys and even dpatch meet my definition of easy to use
<jdong> I'm not a picky guy
<jeromeg> hello
<jeromeg> jdong: could you please validate bug 183262, bug 183088 and bug 177716 ?
<ubotu> Launchpad bug 183262 in gutsy-backports "Please backport neon27 0.27.2-1 from Hardy" [Undecided,New] https://launchpad.net/bugs/183262
<ubotu> Launchpad bug 183088 in gutsy-backports "Please backport libmowgli 0.6.0-1 from Hardy" [Undecided,New] https://launchpad.net/bugs/183088
<ubotu> Launchpad bug 177716 in gutsy-backports "Please backport audacious 1.4.5 and audacious-plugins 1.4.4" [Undecided,Incomplete] https://launchpad.net/bugs/177716
<jeromeg> i've been testing it for a few days, wroks nicely
<jeromeg> *works
<jdong> jeromeg: ok, looks good
<jeromeg> jdong: thank you very much! Sorry to always ping you for this on irc :)
<jdong> no problem :)
<ScottK> I'd appreciate it if someone could test the feisty/gutsy-proposed packages in Bug #183661
<ubotu> Launchpad bug 183661 in libmail-box-perl "FTBFS in Gutsy/Feisty" [Medium,Fix committed] https://launchpad.net/bugs/183661
<jeromeg> I also tested those: bug 180793, bug 162590, bug 175079, bug 175072, bug 174865, bug 175080
<ubotu> Launchpad bug 180793 in gutsy-backports "Please backport homebank 3.6-3 (universe)" [Undecided,Confirmed] https://launchpad.net/bugs/180793
<ubotu> Launchpad bug 162590 in gutsy-backports "Backport Blender 2.45" [Undecided,Confirmed] https://launchpad.net/bugs/162590
<ubotu> Launchpad bug 175079 in gutsy-backports "Please backport screenlets 0.0.10-2 from Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/175079
<ubotu> Launchpad bug 175072 in gutsy-backports "Please backport sonata 1.3-2 from Hardy" [Undecided,New] https://launchpad.net/bugs/175072
<ubotu> Launchpad bug 174865 in gutsy-backports "Please backport reportbug-ng from Hardy" [Undecided,New] https://launchpad.net/bugs/174865
<jeromeg> jdong: ^ :)
<jdong> ok, this is getting floody :D
<jeromeg> jdong: after this I'm done :)
<jeromeg> I'm not sure about the blender one
<pochu> jdong: and bug 175676 pretty please :)
<ubotu> Launchpad bug 175676 in gutsy-backports "backport tracker 0.6.4" [Undecided,New] https://launchpad.net/bugs/175676
<jdong> jeromeg: what's up with the SRU?
<jeromeg> jdong: for gthumb ?
<jdong> oh nvm
<jdong> ScottK: caused that.
<ScottK> I guess I better say it again:
<ScottK> I'd appreciate it if someone could test the feisty/gutsy-proposed packages in Bug #183661
<blueyed> Hi.
<ubotu> Launchpad bug 183661 in libmail-box-perl "FTBFS in Gutsy/Feisty" [Medium,Fix committed] https://launchpad.net/bugs/183661
<ScottK> blueyed: ^^^ can you test?
<ScottK> Hello blueyed
<blueyed> ScottK: sure, will look into it.
<ScottK> blueyed: Thanks
<jdong> ok, I'm starving, breakfast first then backports
<jeromeg> jdong: thanks
<blueyed> I've contacted the uploader of tvbrowser on revu and he said I could adopt his package. Can I just upload an updated package then?
<ScottK> jdong: I think you need to work on your priorities
<ScottK> blueyed: Yes
<joejaxx> asac: can you provide a menu file for firefox for hardy? :)
<jeromeg> jdong: I'm not sure about the blender one, I tested it only a little as I'm not a blender pro and the interface is not really intuitive, but what I tested (a few simple constructions) works
<pochu> dholbach: I can't see Hobbsee in https://wiki.ubuntu.com/MOTU/Council
<asac> joejaxx: ffox 3?
 * Hobbsee isn't there yet
 * Hobbsee adds, but has done no wiki page
<joejaxx> asac: which ever one is shipping by default :) iirc there was not a debian menu file in firefox for gutsy
<pochu> nixternal: and you probably want to update your wiki page mentioning what the MOTU Council election asks for :)
<nixternal> did that
<nixternal> look at the link up top
<joejaxx> asac: or both since firefox 2 is still in the archive
<joejaxx> for hardy
<pochu> nixternal: oh, I missed it. Thank you.
<joejaxx> otherwise us non-{Gnome,KDE} do not have a menu launch entry
 * joejaxx still needs to find out how ubuntu broke dpkg :P
<LucidFox> What is "cherry-picking"? Retrieving a single diff from a VCS revision and adding it as a patch?
<Hobbsee> LucidFox: yes
<joejaxx> non-{Gnome,KDE} users *
<pochu> joejaxx: add Xfce to that list. They use the fdo .desktop files specification AFAIK.
<joejaxx> pochu: yeah
<joejaxx> i think i am going to generate a list of packages that do not have debian menu files as I see more and more packages shipping with out them
<joejaxx> :P
<jeromeg> got to go
<jeromeg> bye
 * joejaxx also hopes the Open Group frees the source to CDE soon :\
<pochu> joejaxx: also go and ask those WM to follow the fdo spec ;)
<joejaxx> pochu: :P
<broonie> joejaxx: *shudder* I've used that
<joejaxx> broonie: hey no shuddering :P
<joejaxx> :(
<broonie> :P
<\sh> moins
<joejaxx> there are a lot of us CDE users out there
<joejaxx> i actually would have paid for the linux version but they do not offer that for purchase anymore
<joejaxx> they need to free the source :P
<joejaxx> so we can pull in the Sun changes to it as well
<\sh> ScottK, I uploaded the claws extra plugins this morning...do you have already a testpackage claws-mail for gutsy handy?
<joejaxx> claws-mail ftw :)
<ScottK> \sh: Hardy should be in good shape WRT clamav, so test away with what's in the archive
<\sh> ScottK, cool...I'll have to install clamav anyway :)
<ScottK> \sh: For gutsy, I missed a dependency so it was in dep wait for a while.  Let me check and see if it's built yet.
<\sh> just wanted to do an upgrade check from dapper to hardy
<dholbach> can somebody imagine why something like this would fail:
<dholbach>  [ ! -f Makefile ] || -/usr/bin/make distclean
<dholbach>  /bin/sh: -/usr/bin/make: not found
<soren> Yes.
<dholbach> [ ! -f Makefile ] || -$(MAKE) distclean      is the original line and removing the '-' makes it work
<\sh> dholbach, looks like that "-" is interpreted somehow
<soren> A - at the beginning of the line means something to make. In the middle of a line, it has no special meaning and gets passed as is to sh.
<joejaxx> yeap
<soren> or rather to $SHELL
<dholbach> interesting :)
<dholbach> gracias
<soren> np :)
<dholbach> hellboy195 was just merging xsel and found it in the debian version
<ScottK> \sh: Still waiting on building in Gutsy.
<\sh> ScottK, ah ok...I'll test with hardy then...after the dist-upgrade run
<nxvl_work> im getting a 403 error when updating my system, where should i report it?
<ScottK> nxvl_work: The xorg update got pulled.
<ScottK> nxvl_work: Patience
<nxvl_work> oh
<nxvl_work> ok
<ScottK> nxvl_work: See /topic in #ubuntu-devel
<nxvl_work> scottK: oh i understand, but it crashed the whole update, xorg isn't the only package i need to update
<nxvl_work> it's kind of annoying
 * nxvl_work goes to #ubuntu-devel
<ScottK> nxvl_work: Sure.
<ScottK> nxvl_work: apt-get install the other updates
<nxvl_work> scottK thats what i'm doing, im not so new :P
<ScottK> OK
<frafu> Hello, I am building a debian source package to which I have added 2 manpages; consequently, i added them to Makefile.am and called autoreconf. This produced a lot of changes to the makefiles.in. My question: Should I ignore all the changes in the makefiles when creating the patch that adds the two manpages to the source?
<bddebian> frafu: If you added them just to Debian/Ubuntu, put them in the debian/ dir, don't patch the source
<hellboy195> anyone a good sentence for the changelog for me? About the  -$(MAKE) distclean error
<bddebian> hellboy195: Change it to: [ ! -f Makefile ] || $(MAKE) distclean
<hellboy195> bddebian: yeah I changed it ;) I need a sentence for the changelog
<bddebian> Oh, just say Make distclean not ignore errors, or some thing like that
<hellboy195> bddebian: k, thx
<frafu> bddebian: I don't know how to only put them in the debian/dir: could you give me an example?
<LucidFox> Launchpad can build against binary packages in NEW?
<geser> frafu: save them as debian/binary.1 and use dh_installman in debian/rules to install them (you can list them debian/package.manpages; see man dh_installman)
 * bddebian glares at geser :)
<geser> LucidFox: no
<frafu> And what about the files that where already in the source and that I modified? A patch for these files as usual?
<LucidFox> oh, wait, indeed... I just saw that faac exited depwait and started building after mpeg4ip was uploaded, but now it has entered depwait again
<bddebian> frafu: Yes
<LucidFox> jdong, do we need a libmp4v2 rebuild bug?
<frafu> Finally: if I add the two new man pages with the debian/dir method, I suppose that I don't have to add them to Makefile.am; correct?
<dholbach> have a great weekend
<bddebian> frafu: Correct
<bddebian> You too dholbach
<dholbach> thanks bddebian :)
<frafu> Thanks for your help
<geser> LucidFox: is libmp4v2-dev on the archive?
<LucidFox> geser> the old version has been removed, and the new version is in NEW
<LucidFox> it was previously provided by faac, and will be by mpeg4ip
<geser> LucidFox: when it passed NEW the buildds should retry faac automatically
<LucidFox> Yes, I know :)
<LucidFox> but there are other packages still depending on the old libmp4v2
<LucidFox> namely: amarok, mplayer, quodlibet
<geser> ah, now I understand
<geser> Hi LaserJock
<LaserJock> hi geser
<bddebian> Heya LaserJock
<LaserJock> hi bddebian, still here I see ;-)
<bddebian> Yep, useless as ever :)
<LaserJock> bddebian: you should have run for MC!
<mr_pouit> ScottK: we already changed the maintainer.
<ScottK> mr_pouit: Great.
<LaserJock> hmm, I wonder if we should have a wiki page
<ScottK> I think that should prevent problems then.
<LaserJock> that just has "maintainer" info like that
<ScottK> bddebian already has a wiki page
<\sh> bddebian for MC? why not...that's would make me proud ;-)
<bddebian> heh
<bddebian> I thought about it but I don't think I could do it justice.  I'm not as involved as I used to be :-(
<geser> a god in the MC? a very nice idea
<LaserJock> mhm
<LaserJock> "divine instruction from above"
<geser> lol
<\sh> "hello this is god bddebian I have something to pray"
<\sh> "here is the stone with ten rules on it for being a good motu"
<bddebian> hah, yeah right :)
<\sh> reminds me of michael moore
<LaserJock> haha
<LaserJock> "MOTU Ten Commandments"
<\sh> "1. Don't blame anyone else, because it was your pile of sh*t you uploaded to the archive"
<\sh> "2. Please clean up after you followed rule 1"
<\sh> "3. Break KDE when you love Gnome, and break Gnome when you love KDE"
<\sh> "4. Don't be too serious"
<ScottK> 3.1 Always break fluxbox and xfce
<\sh> bddebian, do some merges dude :)
<\sh> 3.2 upload gnustep packages even if you don't have a clue about it
<LucidFox> lol
<\sh> ouch...I think i did too many workouts today in the gym...my back is telling me this now
<DktrKranz> \sh, time for a little question?
<\sh> DktrKranz, fire away :)
<emgent> hello
<DktrKranz> \sh, when handling with iceweasel-* packages (such as iceweasel-scrapbook), is it better to rename them mozilla-* or mozilla-firefox-* ?
<LucidFox> DktrKranz> I was under the assumption that mozilla-firefox- if they're Firefox-specific
<\sh> DktrKranz, well...I would say it depends what was it before better to ask the people from ubuntu-mozillateam
<ScottK> DktrKranz: Why are you renaming them?
<LucidFox> Speaking of which... the descriptions for mozilla-noscript and mozilla-firefox-adblock mention Iceweasel, this is probably a bug
<DktrKranz> \sh, make sense. I asked you since you did a lot during feisty, I'll ask them soon. Thanks. (as much as LucidFox).
<DktrKranz> ScottK: depends on iceweasel, in the past we renamed them as well, so I guess it was as per policy or some
<\sh> DktrKranz, oh I only adjusted build-deps afaik...most of the time when it was depending on iceweasel, iceape or whatever icemonkey there was to the corresponding ubuntu package...
<\sh> DktrKranz, I never had the luck to touch an named "iceweasel-plugin-whatever" package
<ScottK> Ah.  Well the firefox/firefox-dev stuff shoul (I think) be some kind of xulrunner for hardy anyway
<geser> isn't hardy switching from FF2 to FF3? what about the plugins we have in the archive?
<\sh> ScottK, well, but what to do with packages named "iceweasel" which would be "firefox"? hopefully we have the very same package with a different name in our archive
<LucidFox> geser> IANAUD, but I thought Fx3 wouldn't be ready before FF
<ScottK> I've no idea the details.  Your mozillateam suggestion was a good one.
<DktrKranz> \sh, we have only one of them, iceweasel-scrapbook. Others have been mangled, I guess
<LucidFox> unless they're planning to ship a beta by default, but in an LTS?
<DktrKranz> but I think mozillateam members can give us a final answer
<LaserJock> I think it might be a good suggestion to have a wiki pages with some sort of Mozilla policy
<geser> LucidFox: if it's an accepted goal for hardy that hardy will ship firefox 3, it's ok to update the firefox 3 package also after FF (see gnome)
<LaserJock> I've dug around the wiki and asked the mozillateam on IRC a few times when I've had issues like this and never really get a satisfactory answer
<DktrKranz> LaserJock: this is probably why we have three different naming policy. I've seen mozilla-* (most), but mozilla-firefox-* and firefox-* too.
<LaserJock> and changing them in Build-Deps and Depends is done differently too
<LaserJock> perhaps I should email -motu/-devel asking if we can get a Mozilla packaging policy?
<LucidFox> and the source package naming is even more confusing
<LucidFox> some have mozilla-, some don't
<emgent> W: Errore nello scaricamento di http://security.ubuntu.com/ubuntu/pool/main/x/xorg-server/xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.1_i386.deb
<emgent> upgrade broken.
<ScottK> leonel: I've uploaded another clamav update and a new python-clamav.  Woud you please test again.
<LaserJock> emgent: need an apt-get update ?
<emgent> LaserJock, sure..
<DktrKranz> LaserJock: it could be of help, at least for new iceweasel-* packages autosynced during initial phases.
<LucidFox> case in point: bug #184084
<emgent> keescook, jdstrand ping
<ubotu> Launchpad bug 184084 in venkman "Extension description mentions Iceweasel/Iceape" [Undecided,New] https://launchpad.net/bugs/184084
<DktrKranz> malone 184084
<DktrKranz> LucidFox: I think there's nothing we can do for source packages names since we want to be able to resync with Debian at a later stage.
<leonel> ScottK Ok
<LaserJock> most all of the descriptions I see mention Iceweasel
<DktrKranz> LucidFox: what about icedove?
<LaserJock> DktrKranz: I'm not sure how that effects this? is the naming scheme in Debian that scattered?
<LucidFox> DktrKranz> Makes sense, I'll add it
<DktrKranz> LaserJock: not sure about Debian naming schemes, but actually we have some sources packages in the form "extension_name", "mozilla-extension_name" and "iceweasel-extension_name"
<nxvl_work> does anyone has run a packaging jam?
<DktrKranz> while this is somewhat confusing, I think the most annoying part is related to binary packages: how am I supposed to search for a {mozilla,firefox,iceweasel} extension if we have several name types?
<LucidFox> I think the best option would be "mozilla-extension-[name]", which is not used by any extensions
<LucidFox> or, failing that, just mozilla-[name]
<\sh> nxvl_work, Ubuntu Berlin wanted to run at least one reading dholbachs blog
<nxvl_work> \sh: i want to run one on Feb 25
<ScottK> Personally I'd say we need bug fixing jams a lot more than we need packaging jams
<LaserJock> amen
<DktrKranz> It it was just me, I'd say mozilla-[name], but I'm not aware of any policies or such.
<LaserJock> ok, I sent an email of regarding Mozilla
<LaserJock> so I'm off
 * DktrKranz hugs LaserJock 
<frafu> bddebian: trying to install the new man pages with the following line "dh_installman --language=C dwell-click-applet.1 pointer-capture-applet.1"  in debian/rules,  it tells me that it does not find the manpage. Unfortunately I have not found any documentation about where to put the new man pages for dh_installman to find them.
<frafu> Can anybody help?
<bddebian> frafu: debian/<pkg>.manpages
<bddebian> dh_installman will look at that file
<bddebian> And that file should have debian/man1.1   debian/man2.1, etc
<frafu> debian/manX.Y: what is X., what is Y?
<bddebian> debian/dwell-click-applet.1 debian/pointer-capture-applet.1
<bddebian> on seperate lines of course
<frafu> ah, I think I understand
<bddebian> Debian can be such a f**king friendly place
<frafu> I don't know yet; I don't have enough experience; but the man page of dh_installman could be more detailed.   :-/   Thanks again for your help.  :-)
<bddebian> NP
<ScottK> frafu: Patches for the man page gratefully accepted ...
<frafu> ScottK: Maybe when I will have more experience...   ;-) The two pages that I am installing are the first I ever wrote.
<ScottK> frafu: Actually, documenting the problems you had understanding the man page about dh_installman to make it more understandable for new people is something you can only do now.  If you wait until you understand it better, it'll be to late.
<ScottK> Yeah!!! bddebian gets an apology on #debian-devel.  Someone write that down.
<somerville32> :)
<frafu> ScottK: where is the bugzilla of the debhelper?
<\sh> ScottK, humm?
<ScottK> frafu: File a bug against it in Launchpad against the Ubuntu package and eventually someone will push the change back up to debian.
<ScottK> \sh: bddebian gets dumped on all the time in #debian-devel by the Ubuntu haters.  Someone actually apologized just now.  I've never seen that happen before.
<\sh> ScottK, hmm...you mean #debian-devel on oftc?
<ScottK> Yeah
<bddebian> ScottK: :)
<\sh> hmm...bddebian is not in #debian-devel ,-)=
<frafu> ScottK: maybe....
<bddebian> \sh: I had to change my nick there ;)
<ScottK> frafu: Even if it's not perfect, it'd be the kind of hint someone more experience would need to improve the documentation.
<\sh> bddebian, what?
<\sh> ah now
<frafu> ScottK: ok
<\sh> bddebian, /takeover #debian-devel ,->
 * \sh needs a shower and a cigarette...I think I'll do that in reversed order
<frafu> ScottK:I will explain the problem that I had...
<ScottK> frafu: Please explain it in a bug.
<ScottK> IRC channels make poor bug trackers.
<bddebian> \sh: Yeah, MOTU bum-rush of #debian-devel, that would ROCK ;-P
<ScottK> persia: Do you mind if I assign the sbuild task on the virtual depends bug to you so it doesn't get marked invalid again?
<\sh> bddebian, well I'm alwys on #fai and #debian-security :)
<ScottK> jdong: Can you scare up some Dapper users to test clamav backports?
<leonel> scottK  clamav instaled fine and  python-clamav worked fine
<ScottK> leonel: Great.  Please mark that on the wiki page.
<leonel> ScottK ok
<ScottK> blueyed: Do you have Dapper servers?
<blueyed> No, my server is running Feisty still (with some of Gutsy)
<Ng> ScottK: it it a -backports type backport, or a -proposed type backport?
<ScottK> Ng: -backports
<ScottK> It's new upstream versions.
<Ng> hmm, I generally avoid -backports on my (personal) server
<ScottK> Ng: If you have dapper and you want a useable clamav, there isn't much choice.  This stuff is all in Universe anyway, so it's equally not commercially supported either way.
<ScottK> blueyed: Any chance you could do some testing and fill in the Feisty/Gutsy boxes on https://wiki.ubuntu.com/MOTU/Clamav?action=show
<Ng> ScottK: is the dapper version not able to update anymore? I'd not noticed any whinging from cron
<ScottK> Ng: Look in /var/log/clamav.
<ScottK> Also it has an open CVE list about a mile long.
<ScottK> Ng: What packages do you use clamav with?
<Ng> ScottK: exim. fwiw, it does say that the main and daily files are up to date
<ScottK> OK.
<ScottK> Clamd then?
<Ng> yeah. Open CVEs is much more relevant though - that will drive me to use a backport :)
<blueyed> ScottK: what does N/A mean? I think amavisd-new would be the only thing I could test.
<ScottK> N/A - Shouldn't be affected.
<ScottK> blueyed: If you'd verify that, it'd be great.
<ScottK> blueyed: How about the php-clamavlib?
<ScottK> Ng: https://launchpad.net/~ubuntu-clamav/+archive has the current clamav built for Dapper.
<Ng> ScottK: thanks
<ScottK> If you want to give it a try.  Assuming it tests well, that's what will be backported.
<Ng> this does make me wonder how I should be tracking things I've installed from universe to make sure I stay on top of security
<ScottK> blueyed: If you can't test php-clamavlib, if you could come up with a test case, that would be highly useful (I know nothing about php).
<ScottK> Ng: There's no easy answer for that.
<Ng> ScottK: I suspected as much
<ScottK> We're working on changing that though.
<frafu> ScottK: I am back; I had to leave the computer for a while; I will explain my problem in a bug on launchpad after I was able to build the package. (This way I can also tell what information was missing in the man page of dh_installman.)
<ScottK> Subscribing to bugs for the packages in question isn't a bad start.
<leonel> scottK got to go  back in 1 hour and update the wiki
<ScottK> frafu: Sounds good.
<blueyed> ScottK: yes, I think there's a test file in the package itself.. IIRC there has been a bug, where I've helped you recently. I've currently no time unfortunately..
<ScottK> blueyed: Understand.  Thanks for all you've done.
<pochu> See you!
<Ng> ScottK: looks good to me, it's still talking to exim and freshclam logs suggest it ran fine and didn't print any scary warnings :)
<ScottK> That's what I'd have expected.  If you could add a row on the wiki page and comment, that'd be wonderful.
<Ng> ScottK: sure :)
<Ng> ScottK: err, sorry, which page? MOTU/Clamav?
<ScottK> Ng: Yes
<Ng> ScottK: not quite sure what you want me to add then - clamav-daemon and clamav-freshclam?
<ScottK> No.  I'd say Exim w/clamd (clamd is part of the clamav package, so we can assum it works with itself).
<Ng> ok
<ScottK> I haven't listed all the clamd users there, because I'm confident clamd works find, but since you've tested it and proven that, then it's worth it to document it.
<Ng> ScottK: done :)
<ScottK> Ng: Thanks.
<jdstrand> emgent: belated pong
<jdstrand> emgent: something came up and I wasn't able to get to your updates yet.  Though I hope to get to them this afternoon
<emiri_> someone has compiled the accounting program named grisbi?
<ScottK> persia: Never mind.  infinity fixed it in the released sbuild too.
<jdstrand> emgent: I was just reviewing your drupal update for SA-2007-031
<jdstrand> emgent: I see that the upstream patch listed on http://drupal.org/node/198162 is different than SA-2007-031-5.3.dpatch (I've only looked at gutsy so far)
<jdstrand> was this the 'Upstream re-fix SA-2007-031 patch' as referenced in bug #181984 ?
<ubotu> Launchpad bug 181984 in drupal5 "Drupal5: SA-2007-031, SA-2008-005,SA-2008-006: SQL injection and XSS " [Undecided,Confirmed] https://launchpad.net/bugs/181984
<jdstrand> emgent: ^^
<jdstrand> emgent: if so, can you provide the link to the updated patch (the changelog still has http://drupal.org/node/198162)
<sistpoty> debian library packaging session part 2 in #ubuntu-classroom, starting now
<leonel> scottK  done
<ScottK> sistpoty: Thanks
<ScottK> leonel: Thanks
<sistpoty> np
<ScottK> leonel: Please test other stuff.
<sistpoty> !pastebin > sistpoty:
<sistpoty> !pastebin > sistpoty
<jpatrick>  /msg ubotu pastebin
<jdstrand> emgent: regarding wordpress, the version and changelog entry does not conform to https://wiki.ubuntu.com/SecurityUpdateProcedures.  Can you look at 'Preparing an update' at section '4' and '5' and resubmit your debdiff (please also give the url of the patch you used).  thanks for your hard work!
<leonel> scottK tested clamsmtp    and worked  fine     added a note to the wiki table
<ScottK> Great.
<frafu> ScottK: here is the bug about the missing information from the dh_installman man page: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/184156
<ubotu> Launchpad bug 184156 in debhelper "man page of dh_installman incomplete for newbie" [Undecided,New]
<ScottK> frafu: What I'd suggest doing next is prepare the text that you would recommend solves the problem.
<ScottK> frafu: Either in plain text (as an attachment) or, for bonus points, as a diff to the existing man page.
<frafu> An example of the missing text is in the bug I filed.
<frafu> ScottK:  To do a good job, I suppose that all dh_* should be checked because I wonder whether the other do not lack the same information.
<ScottK> sure, but one step at a time.
<frafu> ScottK: Maybe that my problem with debhelpers comes from the fact that I did not have a "debhelpers basics" course!?
<ScottK> Maybe, but we don't really have one of those.
<ScottK> I'll leave it to the people that normally mind debhelper to decide if that's to basic info or not.
<jdstrand> somerville32: your edgy debdiff for bug #183389 had the wrong version number
<ubotu> Launchpad bug 183389 in syslog-ng "[SECURITY] CVE-2007-6437 prone to denial of service attack" [High,Confirmed] https://launchpad.net/bugs/183389
<imbrandon> sistpoty: paste.ubuntu.com
<jdstrand> somerville32: I have fixed it
<sistpoty> imbrandon: thanks
<jdstrand> somerville32: uploading now.  thanks for the patches!
<leonel> scottK http://paste.ubuntu-nl.org/52472/    php5-clamavlib   works
<ScottK> leonel: Great.  Please mark it on the wiki.  Can you test php4 too?
<persia> ScottK: Please don't assign it to me: I'm not sure if I'll be able to get to it in any reasonable time.  Setting it "Confirmed" should be sufficient to not be "Invalid", no?
<ScottK> persia: Never mind.  Later in your scrollback you'll find that infinity fixed it already.
<leonel> scottK leonel@dapper:~/clamtest$ php4 test.php
<leonel> ClamAV version 0.92 with 191434 virus signatures loaded
<leonel>  
<leonel> done
<persia> Hrm.  I just finished reading the last 9 hours of scrollback, and somehow missed that.  Perhaps I'm just not parsing well at my local time of day :)
<ScottK> Great.
 * persia idles, in hope of restoring the ability to read
<ScottK> persia: Heh.  It's fix released now anyway, so it'd be interesting if you could confirm.
<persia> ScottK: Could you send me an email with the bug# and a test case (if it's not already in the bug).  I'll test it when I wake up.
<ScottK> persia: What address?
<LaserJock> hi guys
<persia> ScottK: persia@ubuntu
<bddebian> Heya persia
<ScottK> persia: Sent
<ScottK2> Any C programmers handy that could help me figure out how to fix what appears to be an incomplete/correct patch.
<mok0> ScottK2: what's the problem
<ScottK2> I'm trying to backport the current clamav to Dapper and need to patch the Dapper avscan to work with the new clamav
<ScottK2> I grabbed a patch from a later version, but am left with windb.c:277: error: dereferencing pointer to incomplete type
<mok0> ScottK2: where can I see it?
<ScottK2> Gimme a sec to upload it somewhere
<ScottK2> mok0: http://www.kitterman.com/clamav/
<ScottK2> mok0: The patch I started with came out of https://launchpad.net/ubuntu/feisty/+source/avscan/1.3.1-openssl-4
<mok0> still trying to get the first one :-)
<ScottK2> OK
<ScottK2> If you haven't used quilt before, this: http://pkg-perl.alioth.debian.org/howto/quilt.html will come in handy
<mok0> got the first one
<ScottK2> I tried to adapt the patch from 1.3.1 to the 0.8 that Dapper has and obviously missed something
<mok0> My system is gutsy, I will try to compile
<mok0> I don't have a dapper pbuilder
<ScottK2> It'll crash and burn nicely in a Dapper pbuilder
<ScottK2> Heh
<mok0> I can make one... but it will take a few minutes
<ScottK2> I just added my Dapper pbuilder script to the web directory I gave you before
<mok0> cool
<ScottK2> Then it's sh pbuilder-dapper create
<LaserJock> hmm, that reminds me
<LaserJock> I made a new pbuilder script
<mok0> ... it's working now
<ScottK2> Great
<ScottK2> LaserJock: How's it compare to the one that RainCT made from your old one (it's in ubuntu-dev-tools)
<LaserJock> a lot simpler
<LaserJock> it's sort of an in-between
<LaserJock> let me paste it real quick
<LaserJock> http://pastebin.ubuntu.com/3653/
<ScottK2> Maybe add it to ubuntu-dev-tools as pbuilder-dist-simple
 * ScottK2 loooks
<LaserJock> I've had problems with the one in u-d-t
<mok0> ScottK2: yikes a bunzip2 unpack failed
<LaserJock> and it's just way more complicated than I need
<LaserJock> I figure the more amount of code the more than can go wrong
<ScottK2> Right.  I'm still using your old one for Ubuntu
<ScottK2> Or at least one I hacked on a bit based on it.
<LaserJock> this one allows you to just have one script, which I like
<ScottK2> mok0: ?
<LaserJock> but is basically the same thing
<mok0> The pbuilder create needs to unpack a bz2 archive somewhere, and that failed
<ScottK2> Wierd.
<ScottK2> I made my dapper pbuilder with that script just a couple of days ago.
<LaserJock> I added support for a local repo so I could build stuff that deps on stuff I'm also building
<mok0> ScottK2: its a Packages file that is bzip2'ed
<mok0> bzip2: Compressed file ends unexpectedly;
<ScottK2> That should be OK.
<RainCT> LaserJock: Â«this one allows you to just have one script, which I likeÂ» you can do   pbuilder-dist <hardy or whatever> ...
<LaserJock> RainCT: right, but I couldn't get pbuilder-dist to work
<LaserJock> so I made my own
<RainCT> lol
<ScottK2> mok0: Works on by Gutsy box.
<LaserJock> RainCT: rather than figuring out what the problem was with pbuilder-dist, which probably is the "right thing to do"
<LaserJock> mok0: are you using a backported pbuilder?
<mok0> no
<LaserJock> maybe that's a difference
<mok0> I am trying again
<ScottK2> True, as I am, but for Dapper, I'd be suprised it matters
<mok0> It's a corrupt Packages file on the archive
<ScottK2> Try a different mirror?
<mok0> Get:5 http://archive.ubuntu.com dapper/multiverse Packages
 * mok0 curses bzip2
<ScottK2> I don't think I have multiverse in my sources.list
<RainCT> LaserJock: well, you probably didn't do that wrong. at least I have no clue why pbuilder-dist doesn't work for some people :S
<LaserJock> I fought with it for some time
<LaserJock> it wouldn't update right and wouldn't create new pbuilders
<LaserJock> so I took the idea of doing "pbuilder-dist <dist>" but made it simple
 * mok0 looks for a mirror that contains dapper
<LaserJock> they all should shouldn't they?
<ScottK2> mok0: The one I just made while we are talking uses deb http://archive.ubuntu.com/ubuntu dapper
<mok0> It's working with the local archive
<mok0> almost done
<ScottK2> Great
<mok0> ok, got the dabber pbuilder made :-)
<LaserJock> jdong: so ... is the packages that dep on bzr gonna be backported to? :-)
<mok0> Building avscan now
<mok0> ScottK2: I got a bunch of undefined symbols
<mok0> 'CL_DB_STDOPT' undeclared
<mok0> ScottK2: ... in the file avscanop which you patched
<Kmos> LaserJock: yes.. they're waiting in U-A
<LaserJock> ah
<Kmos> :)
<ScottK2> mok0: yes
<mok0> ScottK2: Is that what you are getting?
<ScottK2> mok0: I forgot one thing ...
<LaserJock> lol
<ScottK2> A dapper pbuilder won't have the new clamav in it.
<mok0> ScottK2: you have it in a ppa?
<ScottK2> mok0: use login --save-after-login (I think) and add deb http://ppa.launchpad.net/ubuntu-clamav/ubuntu dapper main to the source.list
<ScottK2> yest
<ScottK2> yest/yes
<mok0> ScottK2: why didn't it flag a missing build-depends?
<ScottK2> Because it just build-depends on libclamav-dev and you have that
<ScottK2> Just an ancient one
<ScottK2> The -dev libraries aren't versioned
<mok0> ScottK2: ah
<ScottK2> (in their name anyway)
<mok0> ScottK2: what about having a version > something, then?
<ScottK2> Yes.  I should do that before I upload it.  Good point.
<mok0> ScottK2: ;-) I've learned something
 * mok0 updates his dapper
<mok0> Try again with ppa defined
<mok0> ScottK2: I get the compilation error you got now
<ScottK2> OK.  That's progress, I guess.
<LaserJock> so it only took 45min to get there :-)
<ScottK2> mok0: You'll want to look at the quilt reference I gave you earlier so you can look at the patched source.
<mok0> ScottK2: it looks pretty ugly
<ScottK2> LaserJock: Not bad considering he had no Dapper pbuilder to start
<ScottK2> mok0: I've got no pride in this as I know virtually nothing about C.  I was trying to figure where the equivalent changes from the patch of the later versions.
<ScottK2> mok0: I'm quite prepared to hear I got it totally wrong.
<mok0> ScottK2: can't you compile the latest version on dapper?
<ScottK2> mok0: No.  The later versions need a later version of Endeavour which does not compile on Dapper and has reverse depends
<mok0> arrgh
<ScottK2> So I have versions that work on Dapper and versions that work with the current clamav, but none that does both.
<ScottK2> Right.
<ScottK2> Which is why I decided it was time to ask for help from someone who actually knows C
<mok0> It's always scary when you apply a patch and things don't compile
<mok0> ScottK2: the patch introduces the problem
<ScottK2> OK.
<mok0> ScottK2: it seems they changed the data structure
<mok0> ScottK2: ... and the patch makes it a mixture of old and new
 * mok0 checks some more
<ScottK2> Would you be able to dig out the additional old bits and make it all new?
<mok0> ScottK2: I'd have to give it a good look
<ScottK2> mok0: It would be a huge help if you could.  This is (I think) the last clamav rdepend I need to get working before I can backport the current clamav
<ScottK2> The Dapper one has an open CVE list a mile long.
<mok0> ScottK2: Is there a problem with the clamav from dapper?
<ScottK2> mok0: It's ancient. Unmaintained.  Unmaintainable.
<mok0> ScottK2: OK
<mok0> ScottK2: I'll take a look, but I need to be fresh
<ScottK2> Since Dapper has ~3 more years to go, it seems prudent to deal with it.
<mok0> ScottK2: right.
<ScottK2> mok0: Thanks.  It's more important to have it right than have it today.
<mok0> ScottK2: he
<mok0> ScottK2: of course, the next problem after getting it to compile: does it work?
<ScottK2> mok0: Of course.
<ScottK2> mok0: Once it compiles, we'll upload it to the PPA and I'll hunt down testers
<mok0> ScottK2: Just a stupid question: what does avscan do?
<mok0> (I know its a virus scanning thing)
<geser> ScottK2: if clamav in dapper is already a pain how will it be in 3 years?
<ScottK2> mok0: That's about all I know.
<ScottK2> mok0: If you join the ubuntu-clamav team, https://launchpad.net/~ubuntu-clamav , you'll be able to upload it directly once the later one I already uploaded gets removed.
<ScottK2> geser: If I can get the rdepends updated to the current API, then I can backport new releases as they happen.
<mok0> ScottK2: Let's not sell the hide before the bear is shot
<ScottK2> Right.
<ScottK2> I haven't heard that before, but I like it.
<mok0> ScottK2: So, the avscan code I'm looking at is basically the dapper version, and the patch in debian/patches contains the diffs to a newer version? (Just checking that I got it)
<ScottK2> The patch in debian patches is my attempt to replicate the changes from the newer version.  They don't all apply directly as some of the code has changed.
<ScottK2> mok0: The later version on LP that I pointed you to has the original patch.
<mok0> ScottK2: ok
<ScottK2> Obviously I missed something.
<ScottK2> The current Hardy version of avscan supports the new clamav unpatched, so the upstream changes may also have clues.
<mok0> ScottK2: ... and what is Endeavour?
<ScottK2> It's a window manager of some kind
<ScottK2> These appear to be low use packages, but I feel an obligtation not to break the archive even for stuff that isn't much used
 * mok0 wonders why a virus scanner would need a window manager...
<ScottK2> It uses their library package, so I assume it's to make their own windows.
<ScottK2> No need to bother with using stuff people know about like qt or gtk.
<mok0> ScottK2: no by all means, keep changes to a minimum
<mok0> Well, I need to stop working. I will look at avscan tomorrow
<mok0> See you guys
<ScottK2> See you.  Thanks
<warp10> When a software is licensed as free to use and to distribute for non-commercial use only, and is in Debian non-free, can it be synced in multiverse?
<LaserJock> warp10: sounds like a good candidate
<warp10> LaserJock: ok, great. Thank you :)
<somerville32> jdstrand, Hey. I had caught that too and I had _thought_ I had uploaded the fixed version. Anyhow, thanks a bunch :)
<somerville32> jdstrand, although I don't see the uploads on launchpad
<Flare183> bug 87122
<ubotu> Launchpad bug 87122 in ubuntu "[needs-packaging] iFolder" [Wishlist,Confirmed] https://launchpad.net/bugs/87122
<Flare183> crap
<ScottK> somerville32: Security uploads get built on a separate system and then source and binary copied into Soyuz after they are all done.
<somerville32> ScottK, okay
<jdstrand> somerville32: still building.  the queue was stuck for some reason
<RainCT> good night :)
<andi5> saivann: ping
<jdstrand> somerville32: just pushed syslog-ng to soyuz.  thanks again!
<somerville32> jdstrand, anytime :)
<jonnymind> Good evening.
<jonnymind> I updated bug 174470
<ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
<saivann> andi5: ping
<jonnymind> Uploaded package can be found as
<jonnymind> http://revu.tauware.de/details.py?package=falconpl
<jonnymind> Is there anywhere else i should post a notice?
<jonnymind> btw; this package http://revu.tauware.de/details.py?package=falcon
<ScottK2> jonnymind: No.  That's it.
<jonnymind> should be removed, but It seems I cannot.
<ScottK2> I can do it.
<jonnymind> ScottK: thnx
<andi5> hi saivann :-)  first i want to thank you for your efforts regarding gnucash packaging and bug fixing :)  i wonder whether what #184176 is about, is a problem for upstream or i can help somehow? :-D
<ScottK> jonnymind: Archived. It can still be found if someone wants to see the old comment.
<ScottK> comment/comments
<jonnymind> Ok, thanks.
<saivann> andi5 : Thanks, please let me check, I finish a phone and I look at this with you
<jonnymind> Is there anything else should I comply to?
<andi5> saivann: sure :-)
<ScottK> jonnymind: We still need to solve the /usr/bin problem, but personally, I think the other falcon should change.
<ScottK> jonnymind: I own the ITP for the other falcon in Debian, so we can sort this out nicely in both places.
<jonnymind> ScottK: thank you.
<jonnymind> ScottK: Of course; I think I clarified enough why I did it.
<jonnymind> (Well; actually I think you're getting bored with my story ;-)
#ubuntu-motu 2008-01-19
<KillerKiwi2005> Whats the correct way to add a user to the fuse group?
<somerville32> KillerKiwi2005, See #ubuntu for support
<KillerKiwi2005> I mean for an installer... not as a user
<KillerKiwi2005> we're working on a deb for the klik2 project
<ScottK> KillerKiwi2005: It's still OT for here and #ubuntu-devel as these channels are about development OF Ubuntu, not on Ubuntu.
<saivann> andi5 : Sorry for the time it took, I'm here now
<KillerKiwi2005> scottKthats what im asking how would an "ubuntu" MOTU do that?
 * andi5 is here
<saivann> andi5 : bug 184176 is probably about a change in a library in hardy because the same package builded without any problem 4 days before, and now there's a lot of errors during the compilation process
<ubotu> Launchpad bug 184176 in gnucash "[hardy]Gnucash fails to build" [Medium,New] https://launchpad.net/bugs/184176
<saivann> andi5 : I suggest that we look to find what library has been updated/changed in the last 4 days that can have an impact on gnucash
<andi5> yep
<blueyed> jonnymind: you need to adjust Suggests in debian/control.
<andi5> i thought of pango, but that was last changed in december
<jonnymind> Immediately:
<jonnymind> blueyed: immediately. What's wrong?
<KillerKiwi2005> scottK: Who/Where should I ask... ?
<saivann> andi5 : I must admit that I'm pretty new to this so I might be wrong, but since it builded OK 4 days ago, I think that it makes sense
<jonnymind> arg
<blueyed> jonnymind: seen it? :)
<jonnymind> sorry.
<saivann> andi5 : libgif changed today
<andi5> libgif is irrelevant, from my perspective :)
<jonnymind> hehe, you never get rid of all those details.
<saivann> andi5 : Okay :)
<jonnymind> blueyed: fixed and reuploading.
<andi5> it touched gnucash mainly because bit-rotten build dependencies, i guess :)
<saivann> andi5 : If you build gnucash in ubuntu hardy, do you also get a lot of errors?
<andi5> +of, please keep ignoring my spelling :)
<andi5> saivann: i tend to build gnucash from a self-compiled gnome stack, so i cannot readily answer that question :(
<saivann> andi5 : Ok
<blueyed> jonnymind: typo in README (s/OPERTION/OPERATION/)
<jonnymind> Ok, thanks.
<saivann> andi5 : I planned to look at each gnucash dependency to find which one were updated in the last 4 days and find which one cause this problem, unless you want to take care of this
<andi5> how do you do that?  open up launchpad on the corresponding source package?
<blueyed> jonnymind: same file, s/ad runs/and runs/
<ScottK> A large number of graphics related packages have recently been upgraded for the recent libungif/libgif transition.
<saivann> andi5 : Yes, just by looking at the debian changelog, I can see each updates with the date
<andi5> saivann: feel free to do that... i still hope to see something from the compiler errors :)
<jonnymind> blueyed: ack. repacking
<ScottK> KillerKiwi2005: Support is on topic in #ubuntu-server
<saivann> andi5 : Great thanks for your help on this! I should start working on that problem in approximately 5 hours, I'll keep you aware if I find something relevant
<andi5> saivann: what time zone is yours? .. i am UTC+1 here, so i will be sleeping in 5 hours :)
<saivann> andi5 : Oh, bad :P So I'll post informations on the bug report ( it's weekend here and my brother want to eat pizza :) )
<andi5> saivann: have fun then :-D
<saivann> andi5 : Thanks :) I'll keep the bug updated and I'll work on this, thanks a lot for your work on gnucash
 * saivann is gone
<andi5> bye
<saivann> bye
<jonnymind> ScottK: I have reuploaded after a couple of suggestion made by blueyed.
<jonnymind> Good night and sweet dreams to all.
<jonnymind> *suggestions
<Legendario> hi, i would like some to answer me some doubts... i want a certain program to be in universe but i saw that there is already a .deb package on the authors homepage. Can it be placed on the REVU or do i need to build it again to place it on REVU
<bddebian> You need to upload a source package, not a .deb
<Legendario> bddebian, i know. but do i need to get through all the process of changing /debian files, signing and building it?
<imbrandon> Legendario: its recomended yes
<Legendario> ok... that's what i wanted to know. I can't just send the .change file with the dput? right?
<imbrandon> correct, it has to at very leaste be signed by the uploader , thats also on the REVU keyring
<Legendario> imbrandon, thanks a lot, dudes...
<Legendario> is anyone here a reviwer at REVU?
<Legendario> anyone?
<minghua> Legendario: Just paste the REVU URL to advertise here generally, don't ask for any specific reviewers.
<minghua> Legendario: Describing what the package does also helps.
<Legendario> minghua, ok thanks...
<Legendario> will do it right now
<Legendario> http://revu.tauware.de/details.py?package=odfviewer is a simple odf viewer and my first package build
<Legendario> http://revu.tauware.de/details.py?package=sive it's simple ipod video encoder and my second package build
<Legendario> i would apprecite if anyone can take a look at it...
<LaserJock> hmm
<Legendario> let me ask one more thing. Are the packages I build supposed to have their distro on its name?
<minghua> Legendario: All REVU packages should target hardy, if that's what you're asking.
<Legendario> mingha, that was not what i was asking, but it's nice to know... so i should set my pbuilder and chroot for hardy?
<Legendario> minghua
<LaserJock> Legendario: yep, new packages into Hardy so that's what you want to build for
<Legendario> what i really wanted to know was if my resulting packages are supposed to have the distribution listed on the output .deb file name
<LaserJock> nope
<Legendario> ok...
<Legendario> thanks a lot everyone ;-)
<zul> nerds!
<LaserJock> yes ... and?
<Legendario> no nerds... only geeks...
<LaserJock> speak for yourself ;-)
<bddebian> heh
<Legendario> i geek is better than a nerd, right?! :-D
<LaserJock> no way man
 * zul hands LaserJock his pocket protector
<LaserJock> geeks == Trekies, nerds == the people who put a man on the moon
<LaserJock> zul: to go with my sliderule? nice!
<bddebian> hehe
 * nenolod files a bug against zsnes with a debdiff to make it build an amd64 version.
<nenolod> ;)
<nenolod> (ia32-libs-dev would be nice *hint hint*)
 * nenolod headdesks as he notices that zsnes was bumped recently.
<LucidFox> Yay! Qt under GPLv3!
<ToyKeeper> ... only a decade late.  :)
 * nenolod headdesks at Qt being under GPL3.
<LucidFox> nenolod> GPLv2 + GPLv3
<nenolod> LucidFox, oh, ok.
<nenolod> fantastic
<nenolod> i succeeded in merging my ugly patch to make zsnes build on amd64.
<ToyKeeper> I hope the ugly patch wasnt required for making the water effect work.  :)
<nenolod> ToyKeeper, zsnes uses x86 assembly, so is not buildable using 64bit libs.
<nenolod> so .. off to play with ia32-libs it goes on amd64 ;)
<ToyKeeper> Ah, okay.  :)
<ToyKeeper> I was just hoping I hadn't contributed to making it painful...
<saivann> andi5: ping
<LaserJock> LucidFox: Qt is v3 and v2?
<LucidFox> LaserJock> Qt3, starting with just-released version 3.3.8b
<LucidFox> Qt4 is underway
<nenolod> can someone test that my debdiff in https://bugs.launchpad.net/ubuntu/+source/zsnes/+bug/184255 has no undesirable effect on x86?
<LaserJock> LucidFox: I meant it is GPL v3 and v2?
<ubotu> Launchpad bug 184255 in zsnes "[patch] build amd64 package of zsnes" [Undecided,New]
<LucidFox> LaserJock> yes
<LucidFox> previously, it was just GPLv2
<LaserJock> I thought Qt4 was going to be GPLv3 only
<LucidFox> er, no
<nenolod> LaserJock, lets hope so.
<nenolod> LaserJock, that way there will be incentive for people to use a superior toolkit. :))
<LaserJock> LucidFox: you sure, upstreams are starting licensing wars
<nenolod> e.g. GTK.
<nenolod> :P
<LucidFox> Lies! Qt > GTK! :p
<LucidFox> (Disclaimer: GNOME user)
<LaserJock> wx > *
<LaserJock> I've grow to dislike GPLv3 immensely
<LaserJock> *grown
<LucidFox> Why?
<nenolod> ISC license \o/
<nenolod> nobody can say bad about such a simple license
<LaserJock> because it is going to cause an upstream I work with to have to reimplement a large chunk of code
<LaserJock> a whole library
<LaserJock> which just gonna be no fun at all
<LucidFox> LaserJock> Why? They're GPLv2 and depend on something that's GPLv3?
<LaserJock> yep
<LaserJock> well, the library is GPLv2-only
<LaserJock> and other libraries/tools are going to go to GPLv3
<LucidFox> Ah, so it's vice versa then.
<LaserJock> so we have to pick which one to reimplement, basically
<minghua> LaserJock: Why?  Did they use said library before?
<LaserJock> yep
<minghua> Oh, should have read everything before replying...
<LaserJock> it's one of the largest and most used chemistry libraries
<LaserJock> we have 15+ packages in Universe depending on it
<minghua> GPLv3 is going to fragment the FLOSS map, that was predicted.
<nenolod> stupid GPLv3
<nenolod> actually,
<nenolod> there is a solution
<nenolod> if you control the copyrights to the main program
<minghua> If I were the developer, I would have decided to stay at v2 rather than reimplement stuff.
<civija> hey guys
<civija> i'm preparing debdiff for slrnface package and I've changed Maintainer: to XSBC-Original-Maintainer:, but don't know now what i should put in new Maintainer: field?
<nenolod> you can go to gpl3, and have a "linking exception" which says: "Modular code linking at runtime to this program is not affected by the GPL license on this program."
<nenolod> then, dlopen the GPL2 library.
<nenolod> problem solved.
<nenolod> ;)
<minghua> !info slrnface
<ubotu> slrnface: shows X-Faces from a newsposting on an X11 terminal emulator. In component universe, is optional. Version 2.1.1-6 (gutsy), package size 25 kB, installed size 104 kB
<minghua> civija: You should put Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>.
<minghua> civija: And please read https://wiki.ubuntu.com/DebianMaintainerField
<civija> minghua: aha, tnx!
<nenolod> hmm, many of the packages i have encountered say "Ubuntu MOTU Team"
<minghua> nenolod: That doesn't work, it's still violating the GPLv2 library's license.
<nenolod> bummer.
<minghua> nenolod: Unless the GPLv2 library's copyright holder acknowledge the "dlopen() is not derivative work" position as well.
<persia> nenolod: Those ought be updated, but it's not worth an upload just for that.  Maybe you can find another trivial bug, lintian warning, etc. in one of those packages and fix them?
<nenolod> well
<nenolod> i need to fix my debdiff for zsnes again :P
<LaserJock> minghua: we can't 'cause we'll lose other, more fundamental libraries
<minghua> LaserJock: What are they?
<LaserJock> I can't remember
<LaserJock> but with another project it's the toolkit, etc.
<minghua> I assume you can always fork the old GPLv2 version...
<LaserJock> well, that wouldn't be great
<LaserJock> forking software all over the place
 * nenolod yawns
<minghua> Ah, toolkit is going to be tough.  Probably they should have used GTK or
<LaserJock> we're hoping we can eventually get the GPLv2 library changed
<minghua> ... or Qt in the first place. :-)
<nenolod> there we go.
<LaserJock> but a company controls much of the copyright and doesn't seem willing
<nenolod> http://launchpadlibrarian.net/11437565/zsnes_1.510-2ubuntu1.debdiff is a great example of why ia32-libs-dev would be a nice package.
<LaserJock> license changes are really rough
<LaserJock> I don't see why FSF would make GPL version non-compatible :(
 * minghua would rather see the forked GPLv2 version gets traction. :-)
<nenolod> LaserJock, because richard stallman has an agenda
<minghua> Because for FSF (RMS?), the license is a tool for advancing their belief/agenda, not (so much of) a tool for development collaboration.
<nenolod> LaserJock, the agenda is that "only his way is free software", so you either can do GPLv3 or get screwed over
<nenolod> LaserJock, it's their intentional goal
<minghua> I don't think RMS really wanted to say that.
<persia> LaserJock: It wasn't intended to make them incompatible, just address what were perceived as "weaknesses" in GPLv2.  These happen to include additional restrictions, which are not permitted to be applied to GPLv2 work.
<nenolod> minghua, no i'm pretty sure the FSF guys want GPLv3 to be the only open source license
<minghua> I see it rather as "When I say certain things are not Free, they are not", such and Tivonization, etc.
<minghua> nenolod: They want (or rather, RMS wants), but he know it's not a practical goal.  There is pretty much no way to get rid of BSD/MIT/X11 style license.
<nenolod> minghua, i don't know, Eben Moglen seems to be doing a great job of incorrectly convincing people that it is legal to slap the GPL on BSD/MIT/ISC/X11 licenses
<nenolod> minghua, or at least he was
<minghua> Slap the licenses?
<nenolod> he may have stopped after the ath5k disaster.
<LaserJock> I'm fairly fond of MIT myself
<nenolod> minghua, yes, as in bolting a GPL on top of the a trivially modified work
<nenolod> i'd like the FSF & friends better if their associates didn't do such things
<minghua> Well, if you are talking about the statement from SFLC after the fiasco about the wireless driver code between OpenBSD and Linux kernel people, I skimmed that statement and didn't see anything particularly wrong, or anyone pointing out such thing.
<nenolod> minghua, before
<nenolod> minghua, before the OpenBSD guys got ticked, eben moglen told the ath5k guys that it was "perfectly fine" to bolt a GPL license on top of the modified code
<minghua> And as IANAL, I would consider Eben Moglen's opinion with very high respect unless another lawyer (or a judge on court) says otherwise.
<LaserJock> in any case, it's really going to be difficult with the transition
<minghua> nenolod: So?  I think it's perfectly fine, too.
<LaserJock> another one I think I'll have to deal with is squeak
<minghua> It may be not quite moral, but I don't see anything illegal.
<nenolod> minghua, it's legally fine yes, but ethically questionable
<LaserJock> Apple agreed to relicense as MIT, which is sweet
<LaserJock> but there's like hundreds of authors to track down and agree
<persia> LaserJock: How is MIT better than ISC?
<nenolod> persia, more words
<nenolod> ;)
<LaserJock> persia: I didn't say it was did I?
<minghua> nenolod: There are ways to do it so that I feel it's ethnically/morally fine.  And ethnics and moralities are always subjective anyway.
<nenolod> minghua, i agree that there are ways to do it that are ethically and morally fine.
<persia> LaserJock: You said "I'm fairly fond of MIT myself".  You're the only non-rubyist I've seen say that, and I wondered why.
<LaserJock> hmm
<minghua> Maybe LaserJock is just a closet-Rubyist. :-)
<LaserJock> I guess I'd say  MIT-like
<LaserJock> BSD, ISC, and MIT are all quite similar in my book
<tuxmaniac> hello all
<LaserJock> I hadn't even heard of ISC until the other day
<LaserJock> but I really dislike GPL
<minghua> LaserJock: "Quite similar", or "I don't know the real difference anyway"? ;-)
<minghua> The latter for me.
<LaserJock> I think they are related
<LaserJock> as in BSD -> MIT -> ISC sort of roughly
<persia> I don't like BSD because most people don't actually notice the bit about the Regents of the University of California, and just point at /usr/share/common-licenses/BSD.  For MIT/ISC, it's just wordiness.
<LaserJock> persia: I agree
<LaserJock> I don't know a whole lot about LGPL but it seems sort of failed in some ways
<nenolod> I think the GPL is becoming less popular because it is too complex
<persia> Failed?  How.  There's lots of LGPL stuff, and some people seem quite happy with it.
<LaserJock> I can't figure out if FSF want people to use it or not
<jsgotangco> the LGPL is much friendlier (hence liberal)
<nenolod> a lot of the new projects i have looked at which were not forks, have been ISC or BSD or MIT license
<LaserJock> I certainly wish the library I'm talking about was LGPL but the company that first developed it wanted it GPL
<persia> LaserJock: I believe they don't like people to use LGPL, but think it's better than using ISC (or the like) if you want people to use the source as infrastructure for a source-denied product.
<LaserJock> I just kinda figure if I'm gonna through it out there I might as throw it out there and make MIT-ish
<LaserJock> ah well
<nenolod> the common public license is interesting too
<nenolod> but i don't think i would use it.
<LaserJock> in the mean time we'll have to figure out what to fork/reimplement and go through lots and lots of licensing wars
<LaserJock> seems like libraries are just a real pain
<LaserJock> sometimes with the cheapness of disk space i wonder if it'd just be better to do static linking more
<minghua> LaserJock: Yeah, and when there is a security hole in the library...
<LaserJock> or just writing everything with the app
<LaserJock> it just seems to be all the rage to create a library even if only one app uses it
<LaserJock> wb persia
<pwnguin> also note that static linking takes more RAM
<persia> LaserJock: Thanks.
<persia> ScottK: sbuild still fails.  Updating the bug.
<LaserJock> pwnguin: I wonder how it would affect most apps
<LaserJock> I can imagine things like tookits and DE libs would save a lot
<LaserJock> but a great many probably don't save much of anything by dynamic libs
<pwnguin> glibc
<LaserJock> given
<ScottK> persia: Thanks.
 * nxvl *HUGS* persia and ScottK without a reason
<LaserJock> phew, 177 updates to install right out of the box
 * persia cheers the SRU team for effective work in coordinating updates
 * LaserJock hopes MOTU SRU goes out of business ;-)
<persia> LaserJock: Why?
<LaserJock> because that means we did it right *before* release
 * ScottK cheers the MOTU SRU team for saying no so he could out of one with a clear conscience.
<LaserJock> time for bed
<LaserJock> I'm off, have a good night/day
<persia> LaserJock: I guess.  Given the number of lines of code, I'm not sure that's possible, although some cases (FTBFS, cannot-install, etc.) are being improved as we develop better tools to see the problems.
<LaserJock> it'd be nice if security was the only thing we had to really worry about post-release though
<LaserJock> but yeah, it's only a dream ;-)
<persia> We'd need a much larger universe-testing team.  The number of possible interactions between the number of packages is fairly high.
<ScottK> Speaking of testing ... https://wiki.ubuntu.com/MOTU/Clamav?action=show
<warp10> Hi all!
<\sh> moins
<\emgent> heya
<\sh> moins \emgent
<minghua> "Is this possible" is really a bad choice of Email subject...
<persia> Yep.  Spam-like.  I wasn't sure of a better one though.
<minghua> persia: "Possible for MOTU to only maintains a single package?", perhaps?
<minghua> Verbosity seldom hurts, I would hope.
<persia> minghua: Maybe, although that still doesn't parse.  Perhaps "It is possible to become MOTU while only maintaining a single package?", but that seems overlong.
<persia> Now if only I had thought of that half an hour ago :(
<minghua> Anyway, if not for persia's reply, I probably would have just labeled it as spam without looking.
<persia> Right.  I'm now confident that ubuntu-bugs@ is used for spam harvesting.  There is a direct correlation between any LP activity and the receipt of spam to the primary address listed in LP.
<minghua> (Oh, and not having a full name doesn't help either.)
<persia> minghua: There's been several REVU submissions from that email address, which is part of why I read it in the first place.
<minghua> There have been two posts on planet complaining about the @ubuntu.com address attracting a large amount of spam, I think.
<persia> I don't think it is the @ubuntu address, except insofar as many people list that as the primary address in LP.
<persia> I think rather that one of the subscribers to ubuntu-bugs@ is reading headers, and passing them to somewhere.  My reasoning is that I don't get much spam to the primary address during REVU day, but always get 30-40 messages when doing bug triage or sponsoring (regardless of time of day or day of week, etc.).  It feels like a realtime system.
<minghua> persia: Well, for me, plenty of spam goes directly to the @u.c address.
<TheMuso> RainCT: Sorry I haven't gotten to merge your changes yet. If they haven't been done, I'll take care of it now.
<minghua> Sounds a quite clever spam system...
<persia> minghua: Do you not see as much to sbcglobal?
<sistpoty> morning everyone
<minghua> persia: I don't really have a hard number, I delete them before downloading them through POP3.  But the general impression is that ~90% spam are to the @u.c address.
<RainCT> TheMuso: Do so, please :)
<TheMuso> RainCT: Ok, whats the URL for your branch?
<persia> minghua: Ah.  The delete-before-download and use of POP3 perhaps makes it hard to check the timing and source relationship to LP activity.
<minghua> persia: But then again, the mails I send to mailing lists has @u.c address in From: line too, so it's many factors.
<RainCT> TheMuso: http://bazaar.launchpad.net/~rainct/ubuntu-dev-tools/dev
<TheMuso> RainCT: Thanks.
<sistpoty> library packaging session in #ubuntu-classroom now (repetition of the session from Thursday)
<Elly> Ãª/win 10
<Elly> er, sorry
<minghua> SBC (southwestern bell) doesn't support IMAP, so I don't really have many choices.
<minghua> Although I am starting to realize that using the same email service as the DSL company is probably not the best idea...
<persia> sistpoty: Thanks for the reminder
<sistpoty> np
<\sh> ok..let's check...wife is in berlin for two days, enough coffee powder in the cupboard...nicotine is also on board...let's have some ubuntu fun :)
<\sh> ScottK, do you have a mail with a virus?
<minghua> Huh.  What is the point of this "Debian Users" LP team?
<persia> More emblems :)
<Hobbsee> more shiny!
<\sh> more teams...for whatever reason ;)
<TheMuso> RainCT: Your changes have been merged.
<RainCT> TheMuso: thanks :)
<LucidFox> Which package is responsible for KDE automounting?
<sistpoty> geser: btw.: rocking work on the haskell transition front! Thanks a lot!
<LucidFox> What would be the Ubuntu equivalent of the "grave" severity in Debian?
<LucidFox> for bugs
<sistpoty> LucidFox: Debian severities don't map to ubuntu, because debian severity refers to *one particular* package, while ubuntu's severity is the severity in the whole project
<LucidFox> Ack.
<geser> sistpoty: I'm preparing now the next batch of sync request for haskell packages
<sistpoty> geser: excellent!
<sistpoty> you rock!
<geser> sistpoty: have you an idea how to fix the haskell-opengl FTBFS on i386?
<sistpoty> geser: not at the moment... does it only FTBFS on i386 (I'm on amd64)
<geser> yes, only on i386
<sistpoty> geser: darn...
<geser> I'm on amd64 too, where it builds successfully (I've tested the build on amd64 before filing the sync request)
<geser> sistpoty: haskell-{glut,openal,alut} depwait now on haskell-opengl on i386
<sistpoty> geser: I'll take a look (and maybe upgrade my old laptop to hardy today)... but my first work is to try to get ghc6 built on sparc and bootstrapped on hppa, lpia
<sistpoty> geser: urgh... the haskell-opengl FTBFS that looks like a problem with ghc6's splitobjs thingy
<sistpoty> geser: from debian bug: "I can compile haskell-opengl fine by removing --enable-split-objs from CONFIGURE_OPTS."
<sistpoty> geser: I'll apply this fix and upload a new version (even if only tested on amd64 *g*)
<geser> sistpoty: no i386 pbuilder?
<sistpoty> geser: nope, and my i386 chroot is totally out of date
<geser> is it only removing that option?
<sistpoty> yes... (actually I've only removed i386 from the switch in debian/rules)
<geser> ok, I'll build it in my i386 pbuilder and check if haskell-opengl builds then
<sistpoty> geser: excellent, thanks. Do you upload it then as well?
<\sh> hmm..does canonical has a rsync mirror of the archives?
<geser> sistpoty: can do it
<sistpoty> geser: thanks a lot
<sistpoty> \sh: iirc there used to be one. If have a very vague memory that it was shut down though.
<\sh> sistpoty, hmm...I wonder if using the http method gives me just the updated packages when I redo debmirror
<the_belgain> apologies if i'm double-posting, but my connection to IRC just dropped and i don't know if the following made it...
<sistpoty> \sh: no idea really... haven't used debmirror in a while
<the_belgain> hi there - i'm having a little trouble with the <package>.install file for a pacakge i'm making
<the_belgain> dh_install is failing because it can't find the directory i'm trying to get it to install. my <package>.install file looks like this: http://paste.ubuntu-nl.org/52573/
<the_belgain> and debian/rules runs the makefile's installer to install in debian/tmp
<geser> sistpoty: what exactly must be changed in debian/control in ghc6?
<sistpoty> the_belgain: either use --source-dir=debian/tmp for dh_install or add debian/tmp as prefix
<the_belgain> thanks
<sistpoty> geser: line 25, remove i386 there
<sistpoty> (that *should* do the trick)
<geser> sistpoty: line 25 is "configure: configure-stamp" here.
<sistpoty> geser: we're talking about haskell-opengl, aren't we?
<geser> sistpoty: ah, so only haskell-opengl needs to be changed?
<sistpoty> geser: yes... though the bug *might* be in ghc6
<sistpoty> geser: but the only fix for ghc6 that I could produce right now would be to disable object splitting for i386 in general, and that would mean a rebuild of all libs again :(
<\sh> persia, ping freqtweak
<\sh> persia, you added yourself with the last new upstream version for ubuntu as original maintainer, should I leave it, or should I use the debian maintainer now? (which is qa group because of debian package maintainer orphaning it)
<db-keen> A week or so ago, I asked about versioning 3rd party packages, people said NOT to use a '~'. However, backports.org and getdeb.net both use them. Was I misled? Should I use them too?
<man-di> backports.org is not 3rd party
 * Hobbsee wonders why not to use a ~
<man-di> not really
<Hobbsee> man-di: for ubuntu it is?
<man-di> but I wonder about the reason
<man-di> Hobbsee: you right, for Ubuntu. I wear my Debian hat too often
<man-di> sorry
 * man-di better shuts up
<Hobbsee> db-keen: 3.0~foo is less than 3.0, so you need to name carefully
<db-keen> it's more of a 3.0-0~foo1
<db-keen> versus ubuntu might name it 3.0-0ubuntu1
<db-keen> versus Debian might name it 3.0-1
<db-keen> right?
<Hobbsee> yeah
<db-keen> so should I call it 3.0-0foo1 or 3.0-0~foo1
<emgent> jdstrand, ping for remember drupal fix sponsorization :P
<\sh> emgent, it's on their eyesight :) patience :)
<emgent> hehehe sure :P
<jdstrand> emgent: did you see my comments from yesterday?
<jdstrand> emgent: hi btw
<emgent> hippu, no sorry :(
<emgent> s/hippu/hi/
<jdstrand> I was thinking of adding them to the bug, but thought you might have irc logs
<jdstrand> anyway... let me get them
<emgent> jdstrand, i think screen deattached.
<jdstrand> from beofre:
<jdstrand> 14:46 < jdstrand> emgent: I was just reviewing your drupal update for SA-2007-031
<jdstrand> 14:47 < jdstrand> emgent: I see that the upstream patch listed on http://drupal.org/node/198162 is different than SA-2007-031-5.3.dpatch (I've only looked at gutsy so far)
<jdstrand> 14:48 < jdstrand> was this the 'Upstream re-fix SA-2007-031 patch' as referenced in bug #181984 ?
<ubotu> Launchpad bug 181984 in drupal5 "Drupal5: SA-2007-031, SA-2008-005,SA-2008-006: SQL injection and XSS " [Undecided,Confirmed] https://launchpad.net/bugs/181984
<jdstrand> 14:49 < jdstrand> emgent: if so, can you provide the link to the updated patch (the changelog still has http://drupal.org/node/198162)
<\sh> jdstrand, yepp...Re: SA-2007-031
<\sh> jdstrand, patch in 5.4 for SA-2007-031 was broken and was fixed in 5.5 with the change in this very special line
<emgent> \sh, ++
<\sh> jdstrand, http://drupal.org/files/issues/db_query_range.patch is the corrected fix for broken 5.4 SA-2007-031 patch
<jdstrand> \sh is that referenced in the later patch urls?
<\sh> jdstrand, discussion was on http://drupal.org/node/198321 and report about if officially is on http://www.drupal.org/drupal-5.5 :)
<\sh> s/if/it/
<jdstrand> \sh, emgent ok thanks, I'll just add that in
<emgent> ok cool jdstrand :P
<jdstrand> (the references that is)
<\sh> emgent, ok my fault..I should have told you to add all references to debian/changelog...because it's important for reviewing the fixes
<jdstrand> emgent: and I had a comment on wordpress
<jdstrand> 15:24 < jdstrand> emgent: regarding wordpress, the version and changelog entry does not conform to https://wiki.ubuntu.com/SecurityUpdateProcedures.  Can you look at 'Preparing an update' at section '4' and '5' and resubmit your debdiff (please also give the url of the patch you used).  thanks for your hard work!
<emgent> jdstrand, ok
<\sh> now where was I
<jdstrand> emgent: fyi-- I will be travelling today and tomorrow and probably won't get to these until tomorrow night at the earliest
<emgent> no problem :P
<emgent> thanks jdstrand !
<jdstrand> emgent: absolutely! :)
<\sh> jdstrand, it's weekend..you shouldn't work at all ;)
<jdstrand> \sh: ;)
<emgent> hahaha
<\sh> jdstrand, go go go ... and drink one or two beer for us ;)
<jdstrand> heheh
<emgent> no beer, rum&&Cola ++
<jdstrand> if truth must be told, I actually like pink drinks
<jdstrand> go figure *shrug*
<emgent> ;)
<ion_> Turkish Pepper (the candy) + vodka = teh awesome
<jdstrand> (strawberry margarita)
<emgent> hehehe
<ion_> A.k.a. Salmiakkikoskenkorva in Finland.
 * emgent like Cubalibre.
<\sh> jdstrand, hmm...I'm more the caipi type of guy...and then a lot of them;)
 * sistpoty needs to go and buy beer
<\sh> sistpoty, kein bier vor vier ;)
<sistpoty> hehe \sh
<\sh> or was it the other way around...
<ScottK> \sh: No, but I could send you a clamav test file.
<\sh> ScottK, please :)
<\sh> hmmm
<\sh> can someone with sparc access check this http://launchpadlibrarian.net/11440832/buildlog_ubuntu-hardy-sparc.cyrus-imapd-2.2_2.2.13-13ubuntu1_FAILEDTOBUILD.txt.gz
<Hobbsee> \sh: log into sparky.
<\sh> hmm...
<\sh> sparky.ubuntuwire.com?
<Hobbsee> yes
<Hobbsee> sparky.tauware.de and revu.tauware.de also resolve at the same place
<Hobbsee> \sh:
<Hobbsee> give me a yell if you don't have permissions to run pbuilder there
<\sh> Hobbsee, looks like I don't have the permission (public key)
<Hobbsee> ah
<\sh> well public key is on LP and it works normally :)
<\sh> ScottK, forget about the testfile...I see now it works :)
<\sh> just catched 4 of those nasty mails ;)
<Hobbsee> \sh: you changed keys did you?
<\sh> Hobbsee, a couple of weeks yes
<mok0> ScottK: Starting to work on avscan now
<Hobbsee> \sh: you should be able to log in now
<\sh> Hobbsee, cool thx :)
<Hobbsee> you're welcome
<\sh> Hobbsee, pbuilder <- hardy?
<Hobbsee> \sh: er, i think it uses pbuilder-dist from memory
<\sh> well..pbuider-dist is not in there..and pbuilder-hardy also not
<geser> does somebody know how to add input line editing for a python cli program?
<mok0> geser: you probably need to use the readline module
<emgent> bye people
<geser> mok0: I've read the online help for the readline module but it's not obvious for me how to use it
<mok0> Hmm, I've never used it either
<ScottK> mok0: Great.
<StevenK> I thought you just had to import it and it dealt?
<ScottK> geser: http://docs.python.org/lib/module-readline.html
<geser> ScottK: I've read that already (it's the same as the online help).
<ScottK> Oh.
<geser> it seems to be more about input history but not about input editing
<geser> I want to add line editing support to requestsync when asking for the rationale to drop Ubuntu changes
<StevenK> Ewww
<geser> btw: I've added python-launchpad-bugs support to requestsync in bzr. requestsync --lp uses it to file the bug instead of mailing it.
<geser> it works for me, but I would like if other people could also test it before ubuntu-dev-tools gets uploaded the next time.
<ScottK> geser: Consulting my Python in a Nutshell, it seems the module is a wrapper for standard readline command, so it's hard to do much with it without also using the readline documentation.  http://tiswww.case.edu/php/chet/readline/rltop.html
<\sh> what was the proposed way to change the complete system language including keyboard layout for the console?
<bddebian> Heya gang
<ScottK> \sh: On another topic, did you notice gnuchash FTBFS now?  You upload built, but something changed underneath it since.
<ScottK> heya bddebian
<\sh> ScottK, yeah I read the bugreport...
<bddebian> Hi ScottK
<geser> heya bddebian
<bddebian> Hi geser
<\sh> ScottK, the reporter found out that is was one lib after Jan 13th
<ScottK> Which?
<\sh>   libgconf2-dev   january 14th <---------- BUILD FAILED with this dependency installed hardy version 2.21.1-0ubuntu1
<\sh> the complete bug doc: bug #184176
<ScottK> Thanks
<ubotu> Launchpad bug 184176 in gnucash "[hardy]Gnucash fails to build with libgconf2-dev 2.21.1-0ubuntu1" [Medium,New] https://launchpad.net/bugs/184176
<geser> ScottK: looks like raw_input() does what I want (currently requestsync uses sys.stdin.readline())
<\sh> hmm now I'm fcked
<\sh> something generates a nose-0.10.1-py2.4.egg which shouldn't be in the package tree after debuild -S
<\sh> can I just clean it during clean target?
<slavi1> there is a problem with the new xserver-xorg-core package, mainly I get a 403 error trying to get it
<geser> slavi1: the update is broken, so it got prevented from being installed
 * Hobbsee notes that hte new one is also up, too
<slavi1> ahh, ok
<slavi1> is it possible to tell apt to use another mounted system to perform operations on?
<slavi1> the way that arch linux pacman can
<LucidFox> Is anyone going to upload yakuake-kde4 from REVU? It has gathered its 2 votes, it's not my package but I'm interested in it :)
 * Hobbsee thought it did get uploaded, and was in new?
<mok0> slavi1: I suppose you can write an alternative apt.conf file, and have apt-get use it via the -c switch
<geser> slavi1: what do you want to achieve?
<slavi1> more like install ubuntu on a removable hard drive without booting off the livecd
<geser> slavi1: simply chroot into the mounted system and call then apt-get
<geser> slavi1: but you need to have there already at least a minimal installation
<mok0> slavi1: and how will you make a bootable system using apt-get?
<slavi1> geser: that's the reason why chroot won't work
<slavi1> mok0: by installing grub onto it
<sistpoty> you can tell grub to install somewhere else, can't you? (iirc -R or -r)
<sistpoty> he, no, that was lilo *g*
<geser> slavi1: use debootstrap to install a base system there so you can chroot
<\sh> sistpoty, grub-install --root-dir for telling grub to install grub imstages instead of root dir
<slavi1> sistpoty: it is possible with grub, just set different root and do "install"
<geser> sistpoty: with the grub-shell it should be possible
<slavi1> I think
<\sh> ./grub-install --root-dir /mnt/foo/boot /dev/<your new boot device>
<\sh> ./grub-install --root-dir=/mnt/foo/boot /dev/<your new boot device> <--- sorry that's the correct syntax..
<slavi1> ty
<slavi1> but apt is a bigger issue
<\sh> slavi1, hmm?
<\sh> sudo chroot /<our chroot dir>
<\sh> vi /etc/apt/sources.list -> change it
<\sh> apt-get update && apt-get dist-upgrade doesn't work?
<geser> \sh: he needs to install a base system with debootstrap there first
<slavi1> yes
<\sh> geser, sure :)
<slavi1> so it is possible ...
<sistpoty> debootstrap hardy /some/where doesn't work?
<sistpoty> or maybe gutsy *g*
<\sh> ScottK, I'm having the new upstream version of gnucash on my todo ... let's see if it's building
<\sh> ScottK, well no
<\sh> gncmod-gnome-search.c:92: error: old-style parameter declarations in prototyped function definition
<mohammad> Hi, does anyone know whether swt3.3 (source package is eclipse 3.3) will be added to ubuntu hardy?
<jdong> mohammad: depends on if anyone will work on packaging them.
<jdong> mohammad: at the rate things are going now, I think there was a handful of volunteers looking into it, I haven't heard much for the past month, so unless more people pitch in, I'd guess no, it would not reach Hardy.
<LucidFox> jdong> Marillat has merged some changes of mpeg4ip back into DMO
<LucidFox> including your debian/copyright
<jdong> LucidFox: cool, yeah, we e-mailed him about it :)
<LucidFox> ah, didn't know
<jdong> he's not interested in repacking the orig.tar.gz for the licensing issues though, so we won't be able to directly sync from him
<jdong> (I don't blame him :D)
<jdong> grr why doesn't cygwin support UTF-8?
<crimsun> http://www.okisoft.co.jp/esc/utf8-cygwin/
<jdong> uname -a
<jdong> oops
<yamal> MOTUs, the new sabnzbd package is awaiting your expert review @ http://revu.tauware.de/details.py?package=sabnzbdplus
<LucidFox> IANAMOTU, but:
<LucidFox> is (Closes: LP #xxx) accepted by LP? I've _never_ seen anything but (LP: #xxx)
<jdong> LucidFox: no, you shouldn't use Closes: LP
<LucidFox> and I think debian/changelog is overly verbose, just "Initial release (LP: #xxx)" would be sufficient
<jdong> LP: #xxxx is the best form
<LucidFox> also, Ubuntu never had Python 2.3, so python-all-dev (>= 2.3.5-11) seems sort of pointless
<xhaker> Hey, what if in an .install file i want to conditionaly install files depending on the distribution?
<LucidFox> xhaker> What do you mean, depending on the distribution?
<LucidFox> If that is the case, package separately for each distribution
<xhaker> as in, we no longer support hotplug, debian does. i want it to build correctly for both
<LucidFox> yamal> Consider using dh_install and debian/install instead of cp
<LucidFox> by extension, it will make debian/dirs redundant
<xhaker> LucidFox: what about adding the files needed in debian but not in ubuntu through rules?
<\sh> what is different between debian and ubuntu then?
<LucidFox> If Debian and Ubuntu need different handling, I think it's best to have two different packages: one for debian, the other for Ubuntu
 * \sh needs food...asap
<yamal> LucidFox: tx
<LucidFox> yamal> The debhelper build-dependency seems overly precise, is there a reason why you require this specific minimal version?
<LucidFox> (for example, how dh_icons requires >= 5.0.51)
<LucidFox> also, patches 03 and 04 are logically connected - their purpose is to make the program find files in /usr/share. Perhaps it would make sense to merge them?
<LucidFox> There's a freenode team called "upstream"? o_O
<yamal> LucidFox: might make sense to join those patches.
<yamal> LucidFox: what do you mean with that last remakr
<LucidFox> yamal> that's not directed to you :)
<yamal> oh ok :)
<LucidFox> For your package, that's all I see. MOTUs may catch more stuff.
<yamal> it's a nice start, and luckily all quite fixable too ;)
<jonnymind> Good evening.
<xhaker> What if the new Debian version changed things a bit, and doing a merge, the remaining changes are the same but in differente places? can someone enlighten me
<sistpoty> xhaker: if they have the same effect, sync it
<xhaker> sistpoty: the remaining changes! :) Some stuff had to be changed in ubuntu to obtain the same effect from before.
<xhaker> effect is the same.. diff is not
<crimsun> it's still a merge if there are remaining changes.
<sistpoty> xhaker: so you still need ubuntu changes? Then I'd say re-merge the remaining changes so that they work again ;)
<sistpoty> on top of the debian package
<sistpoty> (that's what I usually do... reapplying ubuntu changes on top of the new debian version)
<xhaker> and what about the changelog.. should I say I dropped and readded accomodated to the new debian package, or should i just keep the usual remaining changes bit?
<LucidFox> xhaker> There's no need to keep debian/changelog when doing a sync
<LucidFox> when doing a merge, keep only entries since the last sync
<geser> xhaker: just the usual remaining bits
<ups> hi
<LucidFox> ups> welcome :)
<ups> thanks :)
<LucidFox> Heh, I just searched Google for "libtool sucks" and the second result is: 'Google doesn't show even nearly enough hits when you search for "libtool sucks".'
<sistpoty> xhaker: you can drop them, but make sure to have every detail listed in the new changelog entry (e.g. bug numbers, from who's what patch etc.)
<ups> i added debian/copyright and did an "svn diff" for the patch - will it take care of the new copyright file as well?
<LucidFox> ups> What do you mean?
<LucidFox> What are you trying to do?
<ups> LucidFox: create a package from svn source - i took care of the build-depends and warnings etc given by the packaging scripts
<ups> one of the warnings were missing copyright file
<ups> so i put it there
<ryanakca> is there a reason why bzr is still at 1.0 in hardy? (1.1.0 came out in early november iirc)
<ups> now i'm trying to create a patch to send to the upstream developer, using "svn diff"
<LucidFox> Why would upstream be interested in debian/copyright?
<ups> but i don't see any mention of the copyright file in the diff
<xhaker> thanks for the help folks.. will pursue to comply :)
<LucidFox> Upstreams shouldn't generally include the debian directory, that's the packager's job
<jonnymind> ScottK: I uploaded another Falconpl package yesterday. I'd like to be sure it's ok, so it can pass next REVU day...
<ups> well it is already there
<LucidFox> ups> WHAT?!
<LucidFox> Ask upstream to remove it.
<sistpoty> ryanakca: maybe bzr-tools?
<\sh> hmmm...am I blind or liboglappth is not existing in ubuntu?
<ups> LucidFox: why? it will be useful for anyone who wants to build a deb from source himself, don't you think?
<sistpoty> ups: did you checkout an upstream project or from debian/ubuntu somewhere? (what apt-get source hints you in case there is a Vcs-* thingy in debian/control)
<ryanakca> sistpoty: eh? its at 1.0.0 too... is it because there isn't a 1.1.0 version of it yet?
<ups> LucidFox: since the control file is already there
<sistpoty> ryanakca: yes, that's my guess that both should be uploaded at the same time... but I have no idea about bzr-tools (or if there is a new version yet)
<LucidFox> ups> Oh no, not the same argumentation again
<LucidFox> I'm tired of avidemux advocating that
<ups> LucidFox: hmm... not aware if this is a debated topic - i'll be happy to read if you have any pointers ;)
<LucidFox> If upstream wants to distribute a debian directory, it must be at least renamed.
<LucidFox> Like smplayer does.
<crimsun> \sh: it has yet to be synced in.
<LucidFox> If they want everyone to be able to build their own debs, that's fine, but it shouldn't interfere with distribution packaging.
<\sh> crimsun, yeah...there is no bug open for it I guess
<LucidFox> so, ups, please ask upstream to move the debian directory out of the way. Like, rename to debian-upstream.
<ryanakca> sistpoty: ok. I'll check in #bzr ... if there is a bzrtools thats available at 1.1.0, I'll update debian's 1.1~rc1-1 to 1.1.0-1 ... and I'm guessing it wouldn't be too late to sync/merge into Ubuntu?
<ups> LucidFox: thanks, i'll see what can be done
<sistpoty> ryanakca: no, it's not yet too late, there is still some time until FeatureFreeze
<ryanakca> sistpoty: ok, thanks. *gets to it*
<sistpoty> ryanakca: but please make sure that bzr-buildpackage still works... I guess otherwise a lot of people would be unhappy ;)
 * LucidFox never even used [vcs]-buildpackage...
<ryanakca> sistpoty: hehe... I've never used it... so I guess I'll pass it by someone who does use -buildpackage to test it
<sistpoty> ryanakca: that seems prudent :)
<LucidFox> By the way, may I assume that NEW is going to stay untouched until Monday? :)
<sistpoty> LucidFox: that's a smart guess ;)
<LucidFox> heh, I see
<LucidFox> so libmp4v2 builds are still going to stay broken for a while
<zul> afternoon
<geser> Hi zul
<zul> hey geser
<\sh> hmmm what was the url again for viewing the new queue?
<geser> \sh: https://edge.launchpad.net/ubuntu/hardy/+queue
<\sh> geser, thx
<\sh> well...filing a bug against liboglappth
<\sh> TheMuso_, ping gnubiff...do you know exactly why debian upstream maintainer doesn't want to change from fam to gamin?
<\sh> oh ... infinity did the change in the first place
<\sh> crimsun, bug #184389
<ubotu> Launchpad bug 184389 in ubuntu "Sync liboglappth from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/184389
<ryanakca> sistpoty: hmmm... bzrtools is already at 1.1-1 in Debian...
<crimsun> ryanakca: just ask for a sync
<ryanakca> and it looks like hardy's bzr-builddeb is 0.92 while bzr is 1.0 ... so I'm guessing backward / forward / whatever compatibility or somewhing
<ryanakca> crimsun: *nods* ... I'm updating Debian's bzr from 1.1~rc1-1 to 1.1-1... dunno if they'll take it though, but if they do, I guess I'll sync it too?
<sistpoty> ryanakca: try it out and if nothing breaks, ask for sync... (I assume you've also asked at bzr what they think is the best, do you?)
<ryanakca> sistpoty: I have. haven't received an answer yet, but if its a go, it'll just be a matter of submitting it to debian...
<sistpoty> does anyone mind me breaking revu? I'd like to get non-motu comments finally enabled :)
<crimsun> sistpoty: I don't mind.
<sistpoty> hey crimsun btw :)
 * ryanakca doesn't... but since I'm not an active user, my vote doesn't count for much...
<zul> sistpoty: noooo....:)
<sistpoty> heh
<sistpoty> zul: no about non-motu comments or about breaking revu :P
<zul> sistpoty: heh
<sistpoty> btw.: how can I do a diff between two bzr branches? (want to see how much revu-production is diverged from trunk)
<sistpoty> urgh... revu-production is so wrong according to bzr st
<asabil> hi all
<crimsun> 'lo sistpoty, zul
<geser> sistpoty: bzr help diff suggest that "bzr diff one_branch other_branch" might work
<sistpoty> geser: I assume that then bzr st should be clean in revu-production? (trying nevertheless)
<bddebian> Hmm, what replaces libglade-gnome0-dev for gnome2?
<asabil> I would like to contribute a package, how do I do so ?
<geser> !revu > asabil
<geser> bddebian: are you porting from gnome1 to gnome2?
<asabil> and am I allowed to upload to Revu ?
<bddebian> geser: Trying to yes
<zul> hey crimsun how is it going?
<sistpoty> thanks geser, output looks sensible
<bddebian> geser: Well actually the new upstream is supposed to be gnome2, I'm just trying to fix the build-deps :)
<geser> bddebian: check which header is missing and search then the package for it
<crimsun> zul: not bad, you?  And the kid?
<geser> asabil: everybody from the ubuntu-universe-contributors team is allowed to upload to revu and that team is open for everyone
<zul> crimsun: everyone is doing good, now that im working again
<crimsun> zul: belated congrats!
<zul> crimsun: thanks..
<\sh> bddebian, just try libglade2-dev ?
<sistpoty> emgent: you told me you fixed a security bug in revu? do you still have the patch? (looking at the diff right now, and not yet understanding everything)
<sistpoty> i.e. diff between production and trunk, which is *erm* big
<\sh> desktop-file-validate is a nice tool ,-)
<sistpoty> emgent: nevermind, found out the changes, thanks!
<CyberMatt> test
<bddebian> OK, what is an XML perl parser for intltool?
<bddebian> Hello CyberMatt
<CyberMatt> sorry my lag was way up for asec
<CyberMatt> hello though
<nenolod> DktrKranz, yo
<DktrKranz> nenolod, hey :)
<nenolod> DktrKranz, debian has been "working" on getting zsnes on amd64 for some time, but it's not really possible because debian does not do multilib, but instead does an emulation chroot
<nenolod> or at least, that's my understanding of things
<DktrKranz> nenolod, unluckily I haven't any amd64 box to test if your fix works, though :(
<nenolod> DktrKranz, it works
<nenolod> DktrKranz, my concern is "does it work on x86 still"
<nenolod> which it "should", but i don't have any x86 pbuilder set up at the moment ;)
<DktrKranz> nenolod, for x86, I can test it. Since I don't use zsnes, is there any tests to be done?
<nenolod> DktrKranz, just see if it starts up :)
<nenolod> DktrKranz, if it starts, then it's ok
<DktrKranz> ok, thanks for the pointer. I'll start a test build now
<\sh> guys, if anyone has a quad core desktop for me, please mail it to me ,)
<DktrKranz> \sh, I don't even know what a quad core is, my hardware is so old it will ask for retirement soon, I guess :)
<\sh> DktrKranz, amd opteron 2x dual core  ,-)
<\sh> bddebian, xml perl parser for intltool?
<DktrKranz> what about amd 900? :)
<bddebian> \sh: I got it, thanks
<\sh> bddebian, intltool depends on libxml-parser-perl ;-)
<bddebian> Yeah
<\sh> DktrKranz, well, this is far below my desktops what I have here
<\sh> I wonder if I can use a ccache between an emt64 and x86 compiling 64bit code
<DktrKranz> \sh, this is my main desktop, I've some p133 toys around, maybe with some clustering...
<DktrKranz> nenolod, FYI, test build will be available here: http://packages.linuxdc.it/hardy/result/zsnes_1.510-2ubuntu1/
 * nenolod has a bunch of AMD equipment.
 * \sh has a high load....
<\sh> w
<\sh>  20:35:37 up 2 days,  7:08,  7 users,  load average: 8,68, 6,51, 4,78
<Nafallo> that's not high :-)
<\sh> Nafallo, for a P4 emt64 3.0GHz Desktop it is ;)
<\sh> but most probpably it's io load
<Nafallo> top would tell
<Nafallo> iostat as well ;-)
<\sh> Nafallo, io load...
<\sh> Nafallo, less ram == more swap
<Nafallo> :-)
<\sh> well, starting up my p4 i386 :)
<DktrKranz> \sh, play with swappiness a bit, then
<\sh> DktrKranz, na I'm sharing the builds between two workstations now :)
<nenolod> virtualbox-ose needs a nochange rebuild
<DktrKranz> \o/ to clusters
<\sh> two merges on the emt64 box, the next two on the second computer...and when I have time, I'm starting up again my laptop to buildd two more packages
<\sh> actually I could setup one of the two 1U servers with dual PIII 1Ghz power :)
<\sh> well it's noisy but who cares ;)
<geser> \sh: grid pbuilder?
<DktrKranz> some who thinks noise is irritating
<DktrKranz> some neighbours, for instance
<\sh> DktrKranz, na not so noisy :)
<DktrKranz> heh
<\sh> geser, is it working ? ,-)
 * DktrKranz is playing with qemubuilder, but with weak results
<\sh> geser, will you go to FOSDEM this year?
<geser> \sh: I plan but I don't know yet, as I've 4 exams in the week after FOSDEM
<geser> it depends how good my learning goes
<\sh> geser, well exams are more important then fosdem :) I hope I could make it...My wife could visit her sister in belgium and I would travel to bruxelles
<sistpoty> wohoo, contributor comments activated, and I didn't break revu once doing that :)
<asabil> hi all
<asabil> how do I change a filename using *.install files
<\sh> sistpoty, grats :)
<sistpoty> thanks \sh :)
<asabil> I am making a package contains a small file extention bug
<sistpoty> asabil: not too sure if that's possible at all... did you look at the manpage of dh_install yet?
<asabil> sistpoty: the man page says it is not possible
<asabil> any workaround ?
<sistpoty> asabil: mv in debian/rules before calling dh_install?
<asabil> sistpoty: I am using cdbs
<sistpoty> asabil: then you're doomed :P... (consider not using cdbs or ask someone who knows cdbs better than I do)
<asabil> oki
<\sh> damn...now I know why I got doomed
<\sh> I switched off trackerd completly from session administration in gnome...
<\sh> but it comes back all the time
<sistpoty> trackerd is the indexing thingy, right?
<\sh> yepp
 * sistpoty hopes that kde won't add such a thing by default
<\sh> sistpoty, it will :)
<\sh> desktop search is a hype
<sistpoty> damn, I'm doomed as well *g*
<sistpoty> at least I have atm. not got that update notifier thingy (whatever its called in kde) installed and don't have regressions yet (at least none that I think come from there)
<\sh> sistpoty, you mean this adept nightmare?
<sistpoty> \sh: no, rather that "I've got new updates for you... click here. I'll remind you on every new login again" *g*
<sistpoty> btw.: I've got somehow icons for the contents of my root directory on my desktop... is this a known bug?
<sistpoty> (they just landed there instead of my desktop dir, didn't find out even what to change for this *g*)
<ScottK> sistpoty: KDE has Strigii for thrashing your hard drive, but it's better bavhed than tracker.
<sistpoty> ScottK: ah thanks.
<sistpoty> ScottK: hah, not installed :)
<somerville32> Is there a motu-security ml?
<somerville32> (ie. security announcements for universe packages)
<jpatrick> somerville32: I didn't know universe packages got security updates
<somerville32> jpatrick, Of course they do
<somerville32> jpatrick, Just not from Canonical
<jpatrick> ah
<somerville32> :)
<sistpoty> somerville32: none that I'm aware of
<somerville32> I'm thinking that maybe we should get them sent to ubuntu-security-announce
<somerville32> Should also be on the Ubuntu website
<persia> \sh: The current state of freqtweak is the result of an ITA race for which neither competitor currently feels like doing anything.  The latest Debian upload was a merge of Ubuntu patches, but the Debian tarball is still constructed in an ugly manner (and the code is the same).  If you're merging, I'd recommend either grabbing a new SVN snapshot, or using the Ubuntu tarball.  On the other hand, I'm not convinced there is a benefit other than to re
<\sh> persia, ok...so do you still want to be mentioned in the XSBC-Orig-Maintainer?
<persia> \sh: Not really.  I vaguely feel I ought to file an ITA and update Debian, but until I am motivated to do that again, I probably shouldn't be the O-M.
<\sh> persia, ok...
<persia> Debian has a better copyright, but their icon varies from upstream for no adequately explained reason.  Debian README.Debian is really not an ideal way to pull from upstream: please use Ubuntu get-orig-source (with dates adjusted).  A new snapshot won't mean anything, as upstream hasn't gotten around to committing the local branch to SVN in the last couple years.
<persia> \sh: Just out of curiosity, what prompts you to try this merge?  Given that two different people completely rewrote the packaging (in a similar way) from the last common copy, I don't imagine it will be fun (although a good test of merging skills)
<ScottK> sistpoty: Thanks for your work on REVU.
<sistpoty> ScottK: you're welcome... I had these patches lying around for ages actually, but didn't come to comitting them to production :(
<\sh> persia, just to clean the merge list
<sistpoty> ScottK: and of course any beautification of the motu icon is more than welcome (/me sucks at html)
<ScottK> Probably not as bad as I do.
<sistpoty> heh
<\sh> persia, as you can see on changes and ubuntu-archive sync reports I'm trying to clean the list...everything which is not as clear as it should, I'm asking the last uploader
<persia> \sh: OK.  Just checking :)  Feel free to ask me if you have any questions, and feel free to skip if you have any problems (as the only new patch in Debian is the menu structure change).
<\sh> persia, na .. I was just confused because of the QA upload and your last setting of Original-Maintainer :)
<persia> \sh: Some history:
<\sh> persia, gnucash and gfpoken are giving me more pain :)
<persia> Upstream is mostly dead, and the last released version FTBFS.  The package was orphaned.  I repackaged, and forwarded to a sponsor.  Bart repackaged during sponsor review, and uploaded a version that didn't include the patches.  As upstream is dead, the package was again orphaned, after applying the patches I submitted upstream.
<\sh> persia, bah
<persia> \sh: I don't know much about either gnucash or gfpoken.  Sorry.
<\sh> persia, gnucash is broken because of something new in the last gnome upload...
<\sh> persia, and gfpoken needs a imlib2 source change
<persia> \sh: Really?  I thought gnucash was still gtk1
<ScottK2> StevenK: Ondrej (who has been upating python-numpy and python-scipy in Debian) mentioned to me that he thinks he's done updating the packages for a bit and this might be a good time for an update in Ubuntu.
<ScottK2> persia: No.  The updated it.
<persia> \o/
<ScottK2> persia: It was done the last time gtk was threatened to be removed from Debian.
<persia> I'm looking forward to xmms removal :)
<persia> \sh: Thanks for becoming TIL for gaphor :)  Have fun!
<\sh> persia, TIL?
<\sh> persia, gnucash depends on gnome and gtk2
<persia> \sh: Touched-it-last (that being why I've been watching upstream since Dapper: I don't use the package, really understand the code, or understand python packaging)
<\sh> persia, well, the fun part was the .egg directory after debuild -S
<\sh> persia, and hopefully zope3 will switch to 2.5 soon...so we can be in sync with debian
<persia> \sh: You shouldn't be getting that if ez-setup was disabled properly.  Are you sure CÃ©dric applied the don't-access-the-internet patch all the way?
 * persia notes that pattern here, that changes in Debian already present in Ubuntu aren't always merged
<\sh> persia, #from ez_setup import use_setuptools
<persia> \sh: Hmm.  I wonder why clean was updating ,egg then.  Anyway, fixed now :)
<\sh> persia, but debian upstream has it still in its setup.py
<\sh> persia, and it was nose*.egg
<persia> \sh: uncommented?  In that case, I think it's cleaner to tell the package not to try to talk to the cheeseshop, rather than deleting the results in clean:, as otherwise there's no guarantee of build repeatability on a system connected to the internet.
<ScottK> That sounds reasonable to me.
<\sh> persia, the merge I did has it commented in...the debian upstream still has no comment sign before this line
<persia> \sh: That's what I thought.  If you've commented it out (and also the call to use_setuptools), I don't understand how you would be downloading nose.egg.  Maybe python-nose needs to be Build-Depends: rather than Build-Depends-Indep: to avoid this.
<\sh> persia, I check...give me a sec
<\sh> persia, ok...found the bugger
<\sh> persia, first mom was totally wrong, regarding setup.py ... from ez_setup import use_setuptools is now commented out
<\sh> persia, debian/control: move python-nose from b-d-i to b-d helps
<persia> \sh: Thanks for tracking that down.  I'm really happy not to have another changelog entry in that package :)  (also, this is part of why I don't use MoM: I hope you're not trying MoM for freqtweak)
<\sh> persia, nope...
<\sh> persia, normally I'm checking debian orig source and ubuntus old source but I have to admit, I should do it all the time :)
<sistpoty> heh, MoM is like CDBS... you'll never know what you get and how it was assembled *g*
<sistpoty> (at least for me, haven't mastered both yet)
<persia> Well, you can look at the source for both in an attempt to discover this.
<jpatrick> sistpoty: you can always look at the source
<sistpoty> persia, jpatrick: sometimes the source doesn't give too much insight ;)
<persia> \sh: I'll warn you that things I touch (especially things I touch post FeatureFreeze) tend to be adaptations of patches upstream or in Debian (admittedly, sometimes before they are adopted upstream or in Debian), and a such, are very likely to confuse MoM.
<persia> sistpoty: I've not tried with MoM, but I've yet to find a CDBS confusion that wasn't resolved by looking at the make include files.
<sistpoty> I guess I just like it simple :)
<\sh> persia, I'm telling you, with b-d: python your patch works
<\sh> persia, with py2.4 it gives all the way this .egg dir
<persia> \sh: Umm.  You have to build with python2.4 or setuputils replaces the #! lines, and you lose zope3 compatibility
<\sh> persia, I know...
 * \sh needs a smoke first...this is really...well..strange
<\sh> grmpf
<\sh> well yeah
<\sh> if python-nose on the build-host is not pre-installed, it gives the .egg directory
<persia> Which should be handled by build-depends, no?
<\sh> build-host == where you start debuild -S
<\sh> nope
<\sh> build-depends will be pulled in during pbuilder build...
<persia> \sh: Build-Depends: , not Build-Depends-Indep:  There is no guarantee that debian/rules clean: works properly without Build-Depends: installed.
<\sh> but debuild -S calls make -f debian/rules clean and then you need for setup.py python-nose and python-setuptools
<persia> (this is why debhelper is Build-Depends: even for arch-all packages)
<\sh> well, I should use dpkg-source and dpkg-genchanges not debuild
<persia> If you don't want to install the Build-Depends, yes :)
<\sh> or pdebuild
<\sh> gnarf...
<persia> \sh: On the other hand, the package should be patched harder to never download nose from cheeseshop: you should get an error, rather than a populated .egg directory.
<persia> (and please pass the patch to CÃ©dric, who has to make a binary package every time, and doesn't find these things easily)
<\sh> persia, well, he applied your patch correctly...I was the one who was fooled by MoM ... that's it
<\sh> and using debuild is bad....noted....please bang my head 10 times on the desk and put me in the corner for stupid pupils..kthx ;)
<persia> \sh: I thought the patch was applied correctly, but I'm not enough of a python person to be sure the patch is sufficient in every case.  Before my patch, it always downloaded from cheeseshop.  Now it appears to only do so if python-nose is not available when running debian/rules clean, but that's only a partial solution.
<\sh> persia, I wonder if there is something like Pre-Build-Dep
<persia> \sh: Nope.
<\sh> persia, the only thing what makes the download happen is python setup.py clean
<\sh> we can avoid it when removing this call and doing the cleanup manually
<persia> \sh: That's not the right solution.  The right solution is to adjust setup.py to not try to get stuff from the cheeseshop.  My first attempt was to comment out the use_setuptools line.  This is apparently not always sufficient.
<POX_> persia: let me guess: ez_install?
<soren> \sh: What would pre-build-dep do?
<ScottK> I was waiting for you to show up ...
<ScottK> POX_: ^^
<POX_> persia: do you have "from ez_setup import use_setuptools" in setup.py?
<POX_> if yes, remove it
<persia> POX_: Yep.  First attempt is the second patch listed at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461157, but this apparently still downloads if python-nose isn't installed when running debian/rules clean
<ubotu> Debian bug 461157 in gaphor "gaphor: FTBFS in sbuild" [Serious,Fixed]
<persia> POX_: That was commented out, but it still does it :(  Also, \sh is taking over gaphor :)
<\sh> soren, telling the maintainer to install this dependency first, because the maintainer needs it to call debian/rules clean e.g.
<POX_> do you call setup.py clean before or after patching?
<POX_> and why before? :)
<soren> \sh: And this is different from Build-Depends how?
<persia> POX_: No patch target.  Patch is inline
<POX_> ok, where are up to date sources?
<persia> soren: For arch:any packages, Build-Depends also contains things not required to run debian/rules clean
<\sh> soren, well, everything is ok, when your debuild -S complains about a missing build-dep, e.g. when cdbs is missing it complains...but now it just goes over this, and downloads something
<persia> POX_: http://ftp.debian.org/debian/pool/main/g/gaphor/gaphor_0.12.5-1.dsc should exhibit the issue
<persia> \sh: Do you have a better link for POX_ for the ez_setup issue?
<\sh> persia, nope...just download the package and apt-get remove python-nose (if you have it installed)
<soren> persia: And how does *pre*-b-d change this?
<persia> soren: pre-b-d would be the list of things for debian/rules clean.  b-d would be the list of things when building arch:any, and b-d-i would be the list of things for building arch:all.  Note that I don't see the point of pre-d-b, but am only explaining how it could be used.
<\sh> soren, let's state a Pre-Build-Dep as PreReq in a rpm.spec...your build-system-host needs it before it can start with anything" it tells you "listen, before you can work with my rules file or with my build instruction in my .spec, you need to install this...when you did, I can go on with my usual work and clean your code" (just as an example)... like an user extension to a minimal installed packagelist for building packages
 * persia notes that the very concept of pre-d-b is Ubuntu-only, as it only has meaning when one is building source packages and not when building binary packages.
<\sh> especially for packages who are calling ./configure before they can execute make clean
<\sh> persia, well, rpm based distros are building source packages and binary packages from the very same .tar.gz/.patch/.spec  directory ;)
<soren> Erm... B-d's need to be fulfilled before you can be sure your can even execute debian/rules properly.
<persia> soren: in most cases, build-essential handles that
<soren> You need debhelper to be installed, for instance, before most debian/rules will do anything at all without breaking all over the place.
<soren> persia: No.
<\sh> soren, yes...this is not the question...this belongs to your package building tools...
<persia> \sh: pre-d-b would only mean anything for .dsc based distros.  RPM doesn't matter.
<persia> soren: Ah right.  Thanks.  You've pushed me to take an opinion :)
<\sh> persia, redhat and suse are working with such a system
<soren> \sh: debhelper is not a required component when building a debian package.
<persia> \sh: pre-d-b is bad because it requires far too much variance from Debian, for no extra benefit except to protect lazy packagers.
<soren> And it doesn't make sense anyway.
<persia> \sh: Neither Fedora nor OpenSUSE pay any attention to debian/control.
<soren> Give me an example of something that should be p-d-b and not b-d(-i, perhaps).
<persia> soren: debhelper would be a common example.  python-nose would be the example \sh wanted to work around the ez-setup annoyance.
<\sh> soren, I think the bug here was: debuild -S behaves differently from dpkg-buildpackage...
<\sh> dpkg-buildpackage complains directly about the missing b-ds
<soren> persia: Ah, you want to move things from b-d to p-d-b? Not copy them to it?
<persia> \sh: Even with -S?
<persia> soren: That would seem right to me, if I hadn't come to the opinion that it was a waste of time.
<soren> persia: Heh :)
<soren> The point is, you can expect a call to debian/rules (even to clean) to work properly if your b-d's aren't fulfilled.
<persia> Or to put that another way, that would make sense to me if Debian were to migrate to source-only uploads.
<persia> soren: Right.  Another way to handle it would be to have b-d-arch: to handle things that aren't required to build a source package.
<\sh> persia, nope...the -S is the problem in general
<persia> \sh: OK.  Just making sure that there wasn't a behavioural difference between debuild and dpkg-buildpackage.
<\sh> persia, reading the manpage of dpkg-buildpackage again and again, -S should just build the source package...nothing else..
<persia> \sh: Running clean is considered part of building a source package.
<soren> From Debian Policy: "The Build-Depends and Build-Conflicts fields must be satisfied when any of the following targets is invoked: build, clean, binary, binary-arch, build-arch, build-indep and binary-indep. "
<soren> There you have it. Grey on green.
<ScottK2> Are the brackets in "mv debian/libspf-doc/usr/share/doc/libspf-doc/{html,api}" a bashism?
<persia> soren: Right.  Note 1) policy follows practice, and 2) Debian doesn't use sourceful uploads, so the condition under discussion should never occur
<persia> ScottK: Yes.
<\sh> persia, yeah...but then it should complain about not fullfilled b-ds
<ScottK2> persia: Thanks.
<soren> persia: Er.. Yes, they do.
<ScottK2> That'd explain why the package won't build now.
<soren> persia: They just don't do source-only uploads.
<soren> \sh: What should complain?
<persia> soren: Maybe terminology.  Perhaps "Debian doesn't use source-only uploads"?
<soren> persia: Much better :)
<\sh> soren, dpkg-buildpackage -S
<\sh> soren, dpkg-buildpackage -S is for building the source package, clean target needs to be called during this source package creation, so regarding your quoted policy, it should complain by default when a b-d is missing, right?
<persia> \sh: I'd argue that due to the source-only nature of Ubuntu, that's not an Ubuntu bug, and that build-dep-arch is more correct (but not worth the trouble).  It might be a Debian bug.
<soren> I guess dpkg-buildpackage is high-level enough to do that.
<soren> \sh:  Write a patch :)
<\sh> persia, I don't say at all that's bug in ubuntu or debian...it's just a logic bug in dpkg-buildpackage...
<\sh> soren, hehe :)
<\sh> persia, source package creation with dpkg-buildpackage -S should include the -D switch of the tool...to check the b-ds correctly before calling clean target...so the policy is correct at least ;)
 * soren has an early start tomorrow morning and has to pack before the sprint on Monday
<soren> G'night, guys.
<sistpoty> gn8 soren
<persia> \sh: Sure.  I'm just not sure if that part of policy is ideal for Ubuntu.  I like the idea of Build-Depends-Arch:, but just don't see the point of carrying it as a variance.
<persia> good night soren
<sistpoty> \sh: imo dpkg-build-package is the wrong place...
<sistpoty> dpkg-buildpackage is low enough to assume that anything is installed needed for building
<sistpoty> so either pbuilder or sbuild would be to blame
<\sh> sistpoty, nope...
<sistpoty> \sh: dpkg-buildpackage doesn't know anything about what you've got installed in your system, and imo that's correct for *this* tool
<persia> sistpoty: No.  1) This is source packages only, so neither pbuilder or sbuild has been involved yet, and 2) dpkg-buildpackage does complain for other required targets.
<sistpoty> persia: it does?
<\sh> sistpoty, dpkg-buildpackage -D checks the b-ds from debian/control if those are on your build host
<persia> sistpoty: Yep.  Try running dpkg-buildpackage -B without build-depends satisfied.
<sistpoty> ok, if that's the case, then I'll take back my argument and vouch for the opposite *g*
<persia> \sh: pass your -S implies -D patch to sistpoty :)
<\sh> sistpoty, when you check the buildlogs of soyuz, you can see that sbuild is checking the b-ds of the source package before any call is made to debian/rules
<\sh> persia, well the bug is, that -S doesn't imply -D ,-)
<persia> \sh: Right, so the patch is -S implies -D, no?
<sistpoty> \sh: sure for sbuild, that's where I put it... because I assumed that dpkg-buildpackage wouldn't handle this case
<\sh> persia, well this should be done, yes ... it would help people to not use debuild -S (which is written in several documentations)
<sistpoty> but it obviously knows about b-d's so you're right ;)
<persia> \sh: debuild -S just calls dpkg-buildpackage -S.  It should do the right thing.
<\sh> persia, well after the patch yes *eg*
<persia> sistpoty: How do you build source packages with sbuild?
<sistpoty> persia: you cannot... build e.g. debuild could handle that... how do you build these w.o. dpkg-buildpackage?
<sistpoty> s/build/but/
<persia> sistpoty: dpkg-source?  (and, no, I don't advocate this)
<sistpoty> heh
<sistpoty> anyways, you're completely right ;)
<\sh> persia, but back to gaphor, our buildd is intelligent enough to not fail ;)
<persia> \sh: That's because it's not trying to build source :p
 * POX_ is finishing his patch for #461157 (which he will reopen soon)
<persia> POX_: Thank you very much :)
<\sh> I'm waiting for POX ;)
 * \sh takes a deeper look at sbuild to use it instead of pbuilder
<persia> \sh: There's a script in ubuntu-dev-tools to automate setting it up, if you have LVM (even just LVM on a 20GB partition)
 * sistpoty is off to bed
<sistpoty> gn8 everyone
<\sh> persia, well, I'll have 500GB still free to ise
<\sh> s/ise/use/
<ScottK> geser: I see you once aske for an etpan-ng sync.  Do you use the package?
<\sh> brb
<\sh> restarting session
<geser> ScottK: no
<ScottK> geser: OK.  Thanks.
<geser> ScottK: looking at the old sync request, I guess it was because of unmet deps
<ScottK> OK.  I'm messing with a bunch of mail related packages for backports.  I think I'll leave that one alone then.
<POX_> a propos sync requests (while updating my pbuilder :)
<POX_> ScottK: could you sync all my paste* packages?
<POX_> all need to be synced at the same time (I moved to pysupport)
<POX_> I will give you package names in a sec.
<ScottK2> OK
<POX_> paste, pastedeploy, pastescript, pastewebkit
<ScottK2> Any particular order?
<POX_> paste fixes LP: #184162
<POX_> paste should be first
<ScottK2> Bug #184162
<ubotu> Launchpad bug 184162 in paste "python-paste missing dependency on python-scgi" [Undecided,In progress] https://launchpad.net/bugs/184162
<\sh> persia, give me a hint...mk-sbuild-lv just started ...do I need to mount some lv volumes first before going on?
<persia> Do need to define a volume group, but I don't think you need to define any volumes.  My setup experience predates the script though.
<geser> are there some stats how much space the average build takes? I plan to run pbuilder on tmpfs once I've 4 GB RAM
<bddebian> Nice
<persia> geser: I use a 4GB volume with sbuild, and only have ever had trouble with WX (but I've not tried eclipse, OOo, etc.)
<\sh> hmm
<\sh>  mk-sbuild-lv --arch=amd64 --name=hardy --source-template=/home/shermann/pbuilder/etc/hardy/apt.conf/sources.list data00 hardy
<\sh> Specified release not known to debootstrap
<\sh> wtf?
<ScottK> \sh: Do you have the one from Gutsy-backports or the regular one?
<\sh> ScottK, I'm on hardy
<ScottK> Oh.
<ScottK> Nevermind
<\sh> and debootstrap works
<\sh> # Is the specified release known to debootstrap?
<\sh> if [ ! -f "/usr/lib/debootstrap/scripts/$RELEASE" ]; then
<\sh> -EBUG
<\sh> it's really /usr/share/ not /usr/lib
<ScottK2> POX_: There's all requested.
<POX_> ScottK2: thanks
<ScottK2> There's/There're
<\sh> now
<\sh> fixing
<\sh> wow...my first contribution to ubuntu-dev-tools...
<\sh> hmm...arch:all is simple arch:i386 for sbuild, right?
<crimsun> essentially.
<\sh> crimsun, but when my default arch is amd64, how can I tell sbuild to use this as as arch:all replacement?
<\sh> feedparser_4.1-10.dsc: i386 not in arch list: all -- skipping
<\sh> ah
<\sh> -A is the magic switch
<crimsun> it appears to be, yes.
#ubuntu-motu 2008-01-20
<tritium> Hello, crimsun, \sh.
<\sh> moins tritium
<tritium> Congratulations, \sh.  Nice to see you.
<\sh> tritium, thx :)
<tritium> :)
<crimsun> 'evening, tritium.
<tritium> Good to see you, crimsun.
<\sh> I wonder where sbuild hides the source packages when you add -s to it's commandline
<rexbron> If anyone is up for a review, please take a look at http://revu.tauware.de/details.py?package=ubuntustudio-controls . Thanks!
<somerville32> What package would I depend on to depend on gtk 2?
<\sh> libgtk2.0-dev ?
<somerville32> libgtk2.0-0
<\sh> somerville32, oh for the binary?
<somerville32> yea
<\sh> I thought as build-dep
<somerville32> Ok :]
<josesanch_> Any MOTU to ask a question?
<\sh> josesanch_, just ask
<josesanch_> Thanks sh.. i want to know what is the state of the package gnomecatalog.
<josesanch_> was REVU: New: gnomecatalog 0.3.4-0ubuntu1 on 17 january
<\sh> oh..dunno...i didn't do any review work....
<josesanch_> was uploaded by pochu
<josesanch_> but still is not  in in hardy
<\sh> https://edge.launchpad.net/ubuntu/hardy/+queue
<\sh> it's in the new queue
<josesanch_> Ahh..
<\sh> needs to be checked by an archive admin..
<josesanch_> but in the bug https://bugs.launchpad.net/ubuntu/+bug/181140
<ubotu> Launchpad bug 181140 in ubuntu "gnomecatalog" [Undecided,Fix committed]
<josesanch_> the package is in debian since today
<josesanch_> do i have to request a sync? or do i have to wait?
<RAOF> You have to wait.
<RAOF> It'll make it through the NEW queue in good time :)
<josesanch_> raof: Thanks. I was a little confused :)
<josesanch_> jeje. ok
<\sh> hmm...50G should be enough for mirroring hardy i386 amd64 (all components)
<somerville32> I'm creating a new package and it creates a directory (/usr/share/icons/hicolor/16x16/apps/) but doesn't place anything in it
<ScottK2> Should it?
<somerville32> Thats what I'm asking. Should I patch it not to create that directory or will that break some sort of spec
<somerville32> +?
<ScottK2> Generally speaking you don't want to created empty directories
<ScottK2> I'm not sure about that specifically, I most of the stuff I package is server stuff
<somerville32> I think I'll just resize the image to 16x16 and get it to install it too
<somerville32> lol
<persia> Does anyone have an opinion on pulling Debian candidate pacakges, perhaps from mentors, SVN, or in Debian bug reports?  While I'm fairly certain that version numbers should be -0ubuntu1 or -Xubuntu$(Y+1), I'm not sure how to handle the changelog.  Should it be preserved?  Should I add "imported into Ubuntu" as an additional act of work with the other changes (and end up with Changed-By: me)?
<ScottK2> persia: If I was going to do that, I'd want a clear reason why it would actually help things.
<ScottK2> Definitely 0ubuntu1 versions
<ScottK2> I think your changelog suggestion is exactly correct.
<persia> ScottK: Adding myself and altering "Changed-By"?
<civija> hey guys
<civija> could someone please explain me this https://bugs.launchpad.net/ubuntu/+source/slrnface/+bug/184261/comments/2? what should I put in changelog about maintainer?
<ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress]
<ScottK2> persia: Yes.  So the other person gets credit for their work, but you're signing on the bottom line for Ubuntu
<persia> civija: https://wiki.ubuntu.com/DebianMaintainerField might be the explanation you seek.
<persia> ScottK: That's what I was thinking.  Just feels a bit odd, as I think they deserve credit unless I am also making another change.  Thanks for the confirmation.
<ScottK2> civija: What persia said.
<ScottK2> persia: Think of it as signing up for the blame while still giving them credit.
<persia> ScottK: That works for me.  Now to make sure this won't otherwise get in before feature freeze, and maybe unbreak a couple things...
<civija> persia: i've changed that in control file but this post says that i should put that in changelog?
<civija> i'm not sure ...
<persia> civija: Yep.  You should note in the changelog that you've set an Ubuntu maintainer.
<civija> persia: ok, tnx
<somerville32> Can anyone tell me whats wrong with my rules file? http://pastebin.ca/865766
<persia> civija: More generally, any changes to a package should be noted in the changelog.  In the special case of a new upstream version, it is acceptable to only indicate major changes (as long as the details are available in the upstream changelog).  In the special case of a new package for inclusion into the distribution, it is acceptable to only include a short description of the patches that had to be applied to upstream.
 * persia grumbles at the existence of the Calibration DataBase System
<civija> persia: tnx
<persia> somerville32: First, binary-post-install/<package>:: is not an exported overridable rule.  You should be using install/<package>:: or binary/<package>:: depending on whether you want it before or after the .deb preparation (probably install/)
<somerville32> persia, Weird. Thats what xfce4-utils has in its rules file
<somerville32> persia, but I'll change to install/
<persia> somerville32: Then you've found two packages to patch :)
<persia> somerville32: Second, you probably want to set DEB_DH_MAKESHLIBS_ARGS after the include statements (or at least this is how the CDBS Documentation suggests doing things).
<ScottK2> So I came up with a solution to the problem of two different tarballs for Debian/Ubuntu when we upload first and it needs repacking.
<persia> ScottK: Other than the common posting of a URL to the Debian RFP or ITP?
<ScottK2> I went ahead and made a package for the Debian maintainer using my repackage tarball.
<ScottK2> persia: It's a new upstream for an existing package
<persia> ScottK: In that case, makes sense to point at the Ubuntu tarball in the Debian upgrade bug (although larger patches are also likely welcome).
<somerville32> persia, Is just changing the rules file to use install/ instead of post-binary-install/ worth it for xfce4-utils?
<somerville32> persia, or should I wait until I have more to do in that package?
<ScottK2> persia: Right, I just went ahead and made a package without our changes.  We'll see if he uploads it and then I get to merge it back ...
<persia> somerville32: It ensures that xfce4-utils won't later FTBFS if CDBS changes.  On the other hand, it's only worth an upload if you would otherwise forget: it may be just as good to have a bug.
<persia> ScottK: I hope you've also included a get-orig-source to make it easy to verify our tarball...
<somerville32> persia, What do you mean by the DEB_DH_MAKESHLIBS_ARGS comment?
<persia> somerville32: The CDBS documentation recommends setting debhelper hint variables after the include statements.  In your rules file, you set it before.  Depending on how this is actually defined in CDBS, the default may override the previous statement.
<persia> Remember that := means evaluate at parse time, and that make does a full parse pass in the order of the file (with includes parsed at the point they appear) before evaluating the rules.
<somerville32> I still get the same error I was getting
<persia> somerville32: You've not posted the error yet, so I'm just evaluating syntax :)
<somerville32> persia, I posted it along with the paste
<somerville32> But basically: debian/rules:8: *** missing separator. Stop.
<persia> somerville32: Right.  Somehow it didn't get to me.  That usually means you've used spaces rather than tab to indent the rule definition.  It may also mean you need another newline at the end of the file.
<somerville32> persia, By along with the paste, I mean I posted the error in the post description (which is displayed just above the paste)
<somerville32> persia, I'll try those hints out
<persia> somerville32: Ah.  Sorry.  I didn't notice that field.
<somerville32> persia, That is it exactly
<somerville32> persia, I configured gedit to use spaces instead of tabs
<persia> somerville32: Right.  Did the line not appear twice in your debdiff?  It should show any whitespace changes to help you discover them.
<somerville32> persia, I'm packaging from scratch
<persia> somerville32: Ah.  That always makes it harder :)
<civija> persia: could you please check is this ok debdiff https://bugs.launchpad.net/ubuntu/+source/slrnface/+bug/184261/comments/3
<ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress]
<somerville32> persia, I'm pretty pleased. I was able to create a new package from scratch rather fluidly.
<persia> somerville32: Excellent.  It gets even earlier with more practice :)  While we're close for hardy, I expect you'll close a good heap of the needs-packaging bugs for the next release.
<somerville32> Aye Aye, Sir :)
<persia> civija: I usually just use "  * Set Ubuntu Maintainer", but that works.
<civija> persia: ok, thank you once again :)
 * persia vastly prefers reviewing debdiffs to diff.gz files for new revisions (same upstream).
<somerville32> When would be a good time to call dh_icons in cdbs?
<persia> somerville32: Are you packaging something non-gnome, non-xfce, and non-kde?  If you must use an overload variable, add it to the install/<package>:: rule (as dh_icons only tweaks the maintainer scripts).
<somerville32> Okay
<somerville32> It is Xfce
<somerville32> So the icon cache should be updated?
<persia> somerville32: Are you using xfce.mk?  If so, it should.  For verification, check the postinst in the binary package.
<somerville32> ok
<somerville32> Thanks
<emgent> heya
<\sh> sbuild is nice...I have to say..
<persia> \sh: Remember to install pkg-create-dbgsym, pkgbinarymangler, and pkgstriptranslations in your schroot.
<\sh> persia, well, I just played around with it...
<\sh> persia, wrote a simple infinite build server
<persia> \sh: Sure, but if those packages are present, you end up with something that can mostly replicate Soyuz build failures (there are a few corner cases where they differ remaining), which makes it lots easier to test oddities.
<\sh> now I need a database behind it, a webpage
<persia> infinite build server?  Rebuilding everything over and over again?
<\sh> persia, no ...just shove some source packages into a dir, it checks for .dsc and starts building, write locks to not catch them up again, building for X archs, you decide, check for Arch: all packages etc.
<ScottK2> Anyone know off the top of their heads of a Python package using CBDS that produces multiple binary packages?
<persia> \sh: Nifty.  You might also be interested in https://launchpad.net/debomatic
<\sh> persia, well, sbuild doesn't need sudo ;)
<\sh> persia, a big advantage
<persia> ScottK: What problem are you encountering?  Usually CDBS just generates multiple packages based on debian/control, without many extra hints.
<persia> \sh: You need sudo for pbuilder?
<ScottK2> persia: How does it know which files to stuff in which packages?
<persia> ScottK: debian/package.install files, from the calls to dh_install.
<\sh> persia, well, if you don't change all the paths...the default needs a root user for the bind mounts"
<persia> \sh: Ah.  I understand.  Yet another reason for me to be glad to have never used pbuilder :)
<ScottK2> persia: OK.  That's what I thought.
<ScottK2> The result so far isn't happy.
 * ScottK2 will work on it a bit.
<persia> ScottK: For a package split, remember to pull things out of debian/tmp/... to put into the target packages.
<ScottK> Thanks
<\sh> persia, schroot -a "apt-get install pkg-create-dbgsym pkgbinarymangler pkgstriptranslations" should be enough for all chroots, right?
<persia> \sh: I'd not run that, as those packages don't belong in my Debian chroots, but I believe so.
<persia> Err, and you might need to use schroot -uroot -a ...
<\sh> yeah
<\sh> now it works .)
<\sh> nice...really
<Nafallo> hmm
<\sh> apt-ftparchive builds a archive structure with sorted pool/<component/{lib}[a-z]/ directories, right?
<ScottK> persia: There was a note to debian-devel (I think yesterday) describint linda as deprecated and not used in Debian NEW processing anymore since lintian covered essentially everything linda covers.  I'm thinking (as soon as we have the latest lintian) we should update our process docs similarly.
<persia> ScottK: Maybe.  I still have a soft spot for linda, but she is aging, and the maintainer doesn't want to update until some speed improvements can be applied.  My python-fu has so far not been up to figuring out the right data structure to handle in-memory investigation (rather than untarring it and handling the labs).  Perhaps you'd like to give it a shot?
<ScottK> Ah, no thanks.
<persia> Part of the reason for keeping linda is because I think there should be two compliance checkers: if they disagree, discussion is required.  If there is only one, it's harder to catch the bugs.
<ScottK> Personally, I think if lintian is good enough for Debian, it's good enough for us.  I think that makes sense, but we should follow Debian.
<persia> ScottK: I can't agree with that in the general case, but I do agree that linda's utility is limited until she gets an update.  Moving to 3.7.3 isn't that hard, but there are core issues that would be better resolved (e.g. the fact that one cannot produce a debdiff for the migration to 3.7.3 due to the nature of linda internals).
<persia> In other words, feel free to strip it from our process recommendations.  There is value to keeping her, but until someone is both sufficiently interested and able to update, it doesn't make sense as a policy guideline.
<persia> Err.  Revise that.  Feel free to raise it for the next MOTU meeting, and expect to receive my support for a proposal to strip it from our recommendations.
<ScottK> I assumed that was what you meant
 * persia appreciates ScottK's excellent posers of telepathy and intepretation :)
<persia> s/posers/powers/
<\sh> cu in a few hours
<StevenK> persia: I am here ...
<StevenK> Given the discussion in Debian about Linda, I'm very tempted to ask for her removal
<persia> StevenK: Ah.  In that case, what do you think?
<StevenK> My jury is still out
<StevenK> Let's just say that Linda didn't really accomplish what I thought she would
<persia> What was the goal?
<StevenK> To see that Lintian could have a better replacement
<StevenK> Instead all I got was people working on Lintian a lot, and heap of bugs and bad-mouthing
<StevenK> s/To see/To show/
 * StevenK runs off
<persia> Ah.  So instead of replacing lintian, linda merely spurred development to get all the current fixes in place.  Hmm...
 * persia still thinks she was useful, even if she does get removed
<wizs> hello
<wizs> can anyone please tell me how to become a prosperctive developer?
<persia> wizs: You just did.  Congratulations!
<persia> Now, you probably would like some suggestions on some work to do.  What sort of development interests you?
<wizs> is that all i have to do ? just to join this channel?
<persia> wizs: Basically.  I encourage people to also join the ubuntu-motu@, ubuntu-motu-mentors@, and ubuntu-bugsquad@ mailing lists, and #ubuntu-bugs.
<wizs> thanks mate!
<persia> wizs: Do you already have a project, or do you need some hints for ways to find things to work on?
<wizs> sure I do want to know where to start
<persia> There's lots of ways to start.  Depends on what you know, and what you want to do.  Are there any types of packages that interest you?  Any bugs that particularly annoy you?  Do you like debugging?
<wizs> I'm particularly interested in db development and java
<wizs> debugging is cool with me.
<wizs> ok. about myself. a software eng graduate. currently an application developer in .NET and Java. and going to start a phD degree in database
<persia> I'd start by either searching for bugs in the databsae tools, or in any of the packages listed from `apt-cache rdepends java-gcj-compat`.  You may find a few you think you can fix, or at least describe better for other developers.  If you think you can fix one, you might look at https://wiki.ubuntu.com/MOTU/Contributing for hints on preparing a new candidate for inclusion in the archive.
<persia> If you have any questions, please ask them here, and we'll try to answer.
<ScottK> wizs: Are you familiar with Berkeley DB (libdb)?
<jdong> so I write a hangman game that scrapes /usr/share/dict
<jdong> and the first word I got was ampelidaceous
<jdong> what luck.
<ScottK> jdong: Did you see my clamav backport PPA?
<jdong> ScottK: not yet
<ScottK> https://launchpad.net/~ubuntu-clamav/+archive
<ScottK> https://wiki.ubuntu.com/MOTU/Clamav
<ScottK> jdong: I need testers ^^^
 * ScottK dusts off "Mastering Regular Expressions"
<minghua> Everybody else, please stand back. :-)
<ScottK> It was really an easy one, but I need to look it up anytime I do anything with them.
<persia> Does anyone have any hints as to where a package can be found if PTS reports received, sid cache reports unavailable, and it doesn't appear in incoming?  (not NEW)
<ScottK> AFAIK, you wait for the next dinstall run.
<persia> I thought dinstall pulled from incoming into archives.  Is there an intermediate place?
<minghua> a.k.a. "on the way from incoming to the archive"?
<persia> minghua: Yes.  Does such a thing exist?
<minghua> persia: From a pure external observation, there seems to be a ~3 hours delay.
<minghua> 1-5 hours, actually.  Never really measured.
<persia> minghua: Ah.  Maybe I've caught it at a bad time then :(
<somerville32> Could someone please review thunar-svn-plugin on REVU? http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin
<persia> ScottK: Just thought of something: lintian doesn't notice when the upstream changelog is dropped.  There may well be another couple tests missed (someone ought compare, rather than just it being those someone remembers).
<minghua> persia: How do you drop the upstream changelog?
<persia> minghua: Don't install it in the binary package.  There are several ways to achieve this, the easiest being to use Ubuntu CDBS.
<minghua> persia: Ah, dropping it in the binary package.  I see.
<minghua> Probably I should confirm persia's claim and report a bug against lintian.
<Burgundavia> anybody else using xchat-gnome?
<persia> Also "useless debhelper dependency".  I'm not convinced that linda doesn't still have utility from this review (and I haven't even run against the binary packages yet).
<minghua> Burgundavia: I do.
<Burgundavia> minghua: never mind, found the bug
<ScottK> persia: At this point, given the Debian FTP masters announcement, I think bugs against lintian are needed then.
<Burgundavia> minghua: it was the 5s locking bug
<minghua> Burgundavia: Never seen it.  But then again, this is on Debian.
<Burgundavia> there is a pulse audio bug that when joining a new channel/network, x-g locks up for 5s or so
<persia> ScottK: I'm not sure I'm in agreement, but that may be because I'm not as concerned about ftpmaster opinions.
<minghua> Burgundavia: I see.  Thanks for the head-up.  I think I'll stay away from xchat-gnome on hardy, then.
<minghua> persia: I think it's for our own sake.  "Debian's ftp-master would see this warning" sounds a pretty good incentive to fix something.
<persia> minghua: Ah.  Good point.  Especially because e.g. "useless dependency on debhelper" is of level "Error", and is now lost.
<minghua> All this make me thinking -- apparently, a regular REVU reviewer sees much more (both in quantity and variety) lintian/linda diagnosis than a Debian ftp-master.
<persia> somerville32: broken watch file, unversioned b-d on CDBS (when you want a version), and useless b-d on debhelper.
<somerville32> persia: how do I test a watchfile?
<persia> somerville32: There are lots of ways.  The two I use (which may not be sufficient for all purposes) are `uscan --report-status` to make sure the watch file can be parsed and upstream is accessible, and `uscan --force-download` to compare the md5sum with the package.
<somerville32> and you're saying I want a versioned b-d on CDBS?
<somerville32> A lot of packages do not
<persia> somerville32: You're depending on CDBS to generate the dh_icons calls, right?
<somerville32> persia: correct
<persia> And you need these, or thunar won't pick up the right icons for files on which the package acts, right?
<persia> Essentially, if your package wasn't so deeply integrated into a desktop environment, I wouldn't really care if dh_icons might be broken.  Because it is, it matters.
<LucidFox> Burgundavia> I'm using xchat-gnome
<LucidFox> ah, I see
<somerville32> persia: so I should just put a greater than or equal to the current version of CDBS?
<persia> somerville32: Doesn't have to be current.  Did the REVU comment not show the right version?
<somerville32> Ah, I didn't know you commented
<somerville32> gpocentek: Regarding the duplication of gtk in the source, you say that you're not fond of that but is that relevant to advocation or was that just a comment?
<\sh> moins
<somerville32> hiya \sh
<ScottK> Good morning \sh
 * ScottK is off to bed.  Good night all.
<\sh> so good the morning not is
 * \sh is tired...just slept 3 hours
<\sh> thinking about a new cool project
<ScottK> Sounds good.
<\sh> yeah...
<\sh> taking opensuse buildservice and create something better ,-)
<\sh> soyuz for home usgae
<persia> \sh: You might consider looking at deb-o-matic and falcon, both of which do some of that.  Could save you a bit of work.
<\sh> persia, falcon == seveas project?
<lucas> it didn't change name?
<persia> \sh: Yes.  Else I'd have said falconpl.
<\sh> hehe
<persia> lucas: I heard something about a plan for that, but haven't heard it to be implemented yet.
<ScottK> lucas: I think he's still deciding.
<ScottK> But since falconpl changed their package name, we're down to wrestling over /usr/bin real estate.
<somerville32> persia: since the tarball includes LGPL code, should I just copy the LGPL into the debian/ directory or something?
<LucidFox> somerville32> Is the the rest GPL?
<persia> somerville32: I'm not really clear on how that is supposed to work.  I believe that upstream is supposed to provide you with the file.  Better to ask someone else (I've never done new packaging).
<somerville32> LucidFox: correct
<LucidFox> I had such an issue recently. Got a package rejected on the grounds that it didn't have a LGPL COPYING file. Later they agreed that the GPL automatically swallows the LGPL since the entire work can only be GPL, and accepted the package.
<somerville32> Oh right. Can't you use GPL instead of LGPL with LGPL Code if you want?
<minghua> Not really...
<LucidFox> minghua> Why not?
<LucidFox> If someone links GPL sofware with something under another license, the entire combined work becomes covered by the GPL.
<LucidFox> And LGPL contains an explicit GPL conversion clause.
<minghua> LucidFox: I am not sure what somerville32 meant, but if it's "there is a piece of LGPL code, I don't own any copyright of it, but I want to license it to GPL" (which is my understanding), then I believe the answer is a clear "NO".
<LucidFox> The answer is yes.
<LucidFox> http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
<LucidFox> "One feature of the LGPL is that one can convert any LGPLed piece of software into a GPLed piece of software (section 3 of the license). This feature is useful for direct reuse of LGPLed code in GPLed libraries and applications, or if one wants to create a version of the code that software companies cannot use in proprietary software products."
<minghua> Well, I think it's no.  But I've had more than enough licensing argument today, so I'll shut up right now.
<asabil> hi all
<asabil> I uploaded a packaged to revu yesterday
<asabil> but it didn't show up yet on the webpage
<asabil> is that normal
<LucidFox> asabil> No
<asabil> (that was my 1st upload to revu)
<persia> asabil: No.  What is your launchpad ID?  Also, what was the package name?
<gpocentek> LucidFox: how one can know that if the LGPL license is not in the tarball?
<asabil> persia: asabil, and libgee
<asabil> asabil is my ID
<asabil> and I think I was supposed to receive a mail as well no ?
<asabil> with the password for revu
<asabil> I didn't receive it yet
<LucidFox> gpocentek> The LGPL allows to replace the LGPL copyright header with a GPL one
<persia> asabil: No.  There is no mail.  Looks like you joined the contributors group too recently.  I'll resync the keyring, and then you'll have to upload again.  Hold on a bit...
<asabil> ok thanks persia
<gpocentek> yes, but if you don't have the full license text, you don't know it
<gpocentek> so to me it's needed to have the file in the sources, but I might be wrong
<somerville32> gpocentek: The header gives directions on how to get the license if it isn't included in the bundle.
<somerville32> And the LGPLv2, section 3 states: "You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library."
<gpocentek> somerville32: better ask an archive admin anyway, they probably have better answers than I do
<somerville32> However, I'll need to modify the headers
<LucidFox> Generally speaking, it's upstream's job to modify the headers...
<somerville32> For now, I think I'll just place a copy of the LGPL in the root of the source directory
<LucidFox> So far, however, Ubuntu's semi-official stance seems to be to silently overlook the header issue
<somerville32> Ok, well, I'll forgo that then and see what an archive admin says
<LucidFox> seeing how eggtrayicon.{c,h} in rhythmbox have LGPL headers even though a LGPL COPYING file isn't there
<LucidFox> and as I said, my package inkblot was rejected on these grounds, then archive admins discussed it with each other and it was accepted
 * Hobbsee waves
 * somerville32 waves.
<somerville32> Oh gawd. Drunk friends wants me to go pick then up.
<somerville32> I re-uploaded it.
<geser> Hi Hobbsee
 * LucidFox pokes yamal
<Hobbsee> heh
<persia> jscinoz: Did you ever sort out the issues with urbanterror-data?
<persia> asabil: You should be good to upload now.  Let us know if it doesn't show up within about 15 minutes of your upload.
<asabil> okidoki thanks persia
<asabil> dh_install: libgee-dev missing files (usr/include/gee-1.0/gee/*), aborting
<asabil> anyone to help me with this please ?
<asabil> sorry, got disconnected
* persia changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com | It's REVU Day!  Reviewers, FeatureFreeze nears: it's time to clear the queue at http://revu.ubuntuwire.com/.  Packagers, be sure to announce your uploads.
<persia> OK.  It's REVU Day again.  The keyring is synchronised.  The packages are waiting.  Let's clear them all!
<persia> asabil: Sometimes dh_install gets confused.  Try debian/tmp/usr/...
<LucidFox> persia> I'm going to email the qconf upstream about missing copyright headers, but I was wondering what action to take
<persia> As a reminder, peer comments are now enabled: all contributors should feel free to look at other packages: any feedback you provide increases the chance that a MOTU will be looking at your package instead.
<LucidFox> Yay!
<LucidFox> he's reluctant to add copyright headers because the files in modules/ and conf/ are included in other files
 * persia is looking carefully this time
 * Hobbsee cleans out revu
<Hobbsee> Olivier Prieur here?
<Hobbsee> wolfger isn't either, it appears
<persia> LucidFox: My issue is mostly that "For license information, see the COPYING file in the qconf base directory." is wrong.  Dropping that, and replacing with either a notice of free reuse or something ISCish would be acceptable.  So would adding the license preamble.  This is unacceptable precisely because they will be included in other places, where the "qconf base directory" may not have meaning.
<LucidFox> Well, the previous version 1.3 had no copyright notices in these files altogether. I asked to add copyright headers, and got... this.
<Hobbsee> Thorvald Natvig here?
<Hobbsee> right.  revu cleaned out
<persia> LucidFox: The problem is that copyright (with penalties for reuse) is implicit in authorship (or possibly publication) in many jurisdictions.  This is slightly better than nothing, but still not good enough :(
<persia> Hobbsee: Thank you.
<LucidFox> Looking at one REVU package, is it okay to have the Homepage field in the binary package section of debian/control?
<persia> LucidFox: It should be in Homepage: unless there are (oddly) different homepages for different binaries.
<LucidFox> yes, it is in Homepage:
<LucidFox> but that line is in the binary package section
<LucidFox> as a header
<persia> LucidFox: That's fine, although in the Source: stanza is generally better (again, unless the package oddly has different homepages for different binaries).
<asabil> persia: it worked :)
<asabil> persia: now how can I bribe people to review it ? :D
<persia> asabil: I recommend an announcement of the form "I've just uploaded $package, available for review at $url".
<asabil> here ? on this channel ?
<LucidFox> asabil> yes
<asabil> I've uploaded libgee available for review at http://revu.tauware.de/details.py?package=libgee
<asabil> :D
<persia> Yes.  Here.  Now.  Not more than once a day, except for REVU day (today), when once every 4-5 hours doesn't tend to annoy too many people.
<asabil> oki
<LucidFox> asabil> First, look at the lintian warnings
<asabil> ok
<rulus> I got some comments on my upload at http://revu.tauware.de/details.py?package=gtkvd , and I have some questions (again) ;) About the first one: how do I know on which modules I need to depend? Is there some tool to generate this?
<geser> rulus: no, you need to check in which package the modules are and list them manually
<jscinoz> persia, yes but i havn't gotten much/any feedback on the latest ones
<rulus> geser: I only have to depend on that modules that aren't in the default Ubuntu installation?
<persia> jscinoz: I'm just curious if you've checked with the archive-admins about urbanterror-data.  If not, I'm not sure an advocation of urbanterror would mean much.
<mok0> asabil: first round of comments for you
<wallyweek> a small update to sdlmame, now waiting for reviews at http://revu.ubuntuwire.com/details.py?package=sdlmame
<asabil> thanks mok0
<geser> rulus: on every module package your package need
<rulus> geser: ok, thanks for the info :-)
<LucidFox> asabil> Added a review as well
<geser> rulus: think e.g. of kubuntu (or any other customised ubuntu installation/ derivative) where the python gtk module can be not installed
<geser> rulus: there is only a small set of packages which are essential that is guaranteed to be installed everywhere (which you don't need to list in depends)
<rulus> geser: aha, I understand
<LucidFox> Hmm, I never heard of the Vala programming language, but it sounds very interesting.
<asabil> LucidFox, mok0: when I fix all the issues, I should just dput again ?
<asabil> no need to bump the version right ?
<LucidFox> asabil> yes
<LucidFox> no need to bump
<asabil> oki thanks
<LucidFox> asabil> triaged the needs-packaging bug
<asabil> thanks
<asabil> btw, concerning your 5th point
<asabil> the Maintainer should be set to MOTU ?
<asabil> and Original-Maintainer to me ?
<LucidFox> asabil> yes
<LucidFox> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<LucidFox> XSBC-Original-Maintainer: Your Name <you@example.com>
<asabil> ok thanks
<rulus> About the last comment (http://revu.tauware.de/details.py?package=gtkvd), do I need debian/dirs? I think the needed folders are created automatically by setup.py?
<asabil> hmmm, I uploaded a new revision, but it didn't seem to appear on the revu page :/
<asabil> what did I do wrong ?
<asabil> (I changed the package version from -0 to -0ubunt1
<persia> asabil: Maybe just waiting for the refresh (happens every 10 minutes or so)?
<LucidFox> rulus> debian/dirs is only needed if you cp something there, or deliberately want to have empty directories in the deb
<LucidFox> if the upstream installer creates the directories it needs itself, debian/dirs is not needed
<rulus> LucidFox: ok, thanks :-)
<asabil> I think I fixed all the issues with my libgee upload
<jonnymind> Hello.
<jscinoz> persia, what should i be checking about it?
<persia> jscinoz: Last review asked you to check with the archive admins to see if the size would be an issue.
 * rulus updated gtkvd: http://revu.tauware.de/details.py?package=gtkvd
<jscinoz> how can i contact the admisn
<persia> jscinoz: They are often on #ubuntu-devel on weekdays from around 8-22 UTC.  You could also send email to ubuntu-archive@l.u.c
<Hobbsee> persia: mithrandir might still be around on #u-d
<persia> jscinoz: ^^
<\sh> hmm...does anyone know where the .changes format documentation is hiding on debians server?
<\sh> got it
<persia> \sh: Share?
<\sh> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debianchangesfiles
<jscinoz> ok thanks
<aurax> elkbuntu you idiot :)
<persia> elkbuntu always wins :)
<elkbuntu> persia, he joined *every* channel i was in to get at me
<elkbuntu> of course since i could only get rid of him from some, he got great thrills
<elkbuntu> actually, the only ones unscathed were my loco channels :-/
<jonnymind> To all motus: I have a fast question about tomorrow revu: I'd like to present the official Falconpl 0.8.8 package.
<jpatrick> elkbuntu: he got you in #u-es
<jonnymind> currently 0.8.7 version is loaded.
<jonnymind> Does it pose any problem if I just dput the new version?
<elkbuntu> jpatrick, ah... he did get one of my loco channels then
<persia> jonnymind: Last I saw, falconpl was awaiting review.  If you update it, the status doesn't change.  If there was an advocation I didn't see, you lose the advocation with an update.
<\sh> .oO(/ignore is a bliss when it's known...bans is so 90ties)
<elkbuntu> not that it's my loco channel, im just in there to monitor the ascii genitalia gang
<jpatrick> elkbuntu: where I prompty throw him out
<elkbuntu> \sh, for an op to ban a troublemaker who's insulting everyone who speaks in his presence, is irresponsible
<\sh> elkbuntu, this jerk is registered on freenode...a k-line is more useful of an irc admin to stop those jerks..a ban is temporary and most likely he just reconnect his router and get a new ip et voila
<\sh> so /mode +b is not enough to get rid of these people
 * \sh wonders why nobody learned from the experiences of the 90ties where IRC was more like a wargame
<elkbuntu> \sh, yes, and we have people trying to get staffers (rare at this time of day), but i still have to keep an eye on him until then
<Hobbsee> \sh: if they were actually giving out staffing access, with klines...
<\sh> Hobbsee, hopefully not...k-lines are irc admin territory and not for customers of a service (s/customers/users/)
<Hobbsee> \sh:
<Hobbsee> even the newer staff aren't getting kline powers
<\sh> Hobbsee, the idea behind k-lines are : just put the whole /24 in the server config reload it and wait for the ISP  to complain so an irc admin can give evidence to the ISP that one user is misbehaving
<PriceChild> you have to get enough xp before you get o-lines and klines etc.
 * persia notes that it is REVU day, and three people should go do REVUs rather than talking about IRC stuff.
<Hobbsee> persia: bah humbug.  i cleaned up REVU.  that's my good deed for the day
<elkbuntu> \sh, you're aware that doing that would exclude most of freenode's users... hence killing the network, right?
<persia> Hobbsee: You get a pass for other reasons.  The three would be the other three members of the conversation.
<Hobbsee> ahhh
<Seveas> persia, cheat.
<persia> Seveas: four!
<Seveas> Hobbsee should do more revu, lazy ozzie woman
 * Seveas should now run
<Hobbsee> hah
<Seveas> eek
<persia> Seveas: conflict of interest.  Check +participation
<Hobbsee> Seveas: now, if i *ever* get kline powers...you know who the first to go will be?
<\sh> elkbuntu, yes, but e.g. vandalism of my service is just like someone would enter my house and destroy my furniture...
<Seveas> Hobbsee, probably gary since he's the default victim
<elkbuntu> \sh, yes it is. however jailing the rest of the town for the crimes of that one person would not bide well anywhere
<\sh> elkbuntu, e.g. on my webserver I have 182 /24er blocked...because of heavily spamming drupal...most of those /24er are coming from china, russia and other not well behaving countries..around 1/4 of networks which are not coming from those countries are from germany...and I already have connections to most of the ISPs here, and they are hunting their users now
<elkbuntu> \sh, that's great for a non-realtime service, but it would ruin an irc network like freenodes. heck if one person from wanadoo messed up, you're excluding half of france for it
<Hobbsee> elkbuntu: this is a problem?
<Seveas> elkbuntu, we've done that in the past with half of turkey and poland :)
 * Hobbsee hides from all the french people
<elkbuntu> Hobbsee, the french might think so
<persia> Erm.  OK.  Next person to talk about IRC without first reviewing a package gets a frown!
<elkbuntu> Seveas, indeed we have, but not for *one* person
<\sh> elkbuntu, you block not the whole ISP but a block of 255 ip addresses hence a /24 (or old nameing class C network)
<elkbuntu> frown away, persia
 * persia frowns at \sh and elkbuntu
 * \sh works on something...
 * \sh wonders if it's possible with a magic gpg cli switch to remove the ascii armor from a signed file
<\sh> after checking the sig e.g.
<jonnymind> persia: thank you, I get it. No, there isn't any comment nor advocation yet.
<persia> jonnymind: Then it's safe to upload a new candidate.  Best do it now before someone looks and maybe advocates (as it can be annoying waiting for NEW processing when there are improvements ready).
<jonnymind> k
<jonnymind> I'll do that in minutes then.
<jonnymind> persia: we have a zlib module that may be optionally built using the system zlib.
<jonnymind> would ubuntu prefer we to link against system zlib and set proper dependencies, or woudl it prefer we to use our internal version?
<\sh> jonnymind, system zlib..less maintaince when zlib is broken
<jonnymind> \sh: ack
<\sh> jonnymind, another point: no duplicated sources in the archives
<jonnymind> \sh: you mean we should strip our source off of zlib source code?
<\sh> jonnymind, normally we strip duplicate sources out of the orig.tar.gz, yes...most known libs which are shipped with upstream sources are ffmpeg or zlib or boost ;)
<jonnymind> Ah, ok. So I can do this in my local ubuntu copy while packing, right?
<jonnymind> np for that.
<the_belgain> hi - i'm getting the following lintian errors on my package: http://pastebin.ubuntu.com/3705/
<the_belgain> do i need to be splitting this package into separate "fuppes" and "libfuppes" packages here, or is it still acceptable for both the program and the library to be in the same package?
<StevenK> the_belgain: The first error is caused by not calling dh_makeshlibs in your rules file
<StevenK> the_belgain: Well, are other things going to link against the library?
<the_belgain> no
<\sh> jonnymind, yepp...
<the_belgain> StevenK: looks like adding a call to dh_makeshlibs will get rid of the first two errors - how about the third?
<StevenK> the_belgain: Then I think the last error can be ignored
<the_belgain> should the error be explicitly overrided in some way, or just left in place?
<StevenK> Not sure about that
<the_belgain> a couple of other questions - the package doesn't currently have a man page.  there isn't any such documentation in the upstream release; is it normal to just suggest the upstream author adds some documentation, or should some docs be added that are specific to the ubuntu package?
<the_belgain> it feels like the package maintainers aren't going to be best-placed to keep eg. a manpage up to date with new releases
<asabil> I've uploaded a new revision for libgee package available for review at http://revu.tauware.de/details.py?package=libgee
<broonie> the_belgain: Ideally a man page would be written and contributed upstream.
<the_belgain> would the absense of a manpage in the meantime prevent a package being accepted into multiverse?
<broonie> Very unlikely.
<the_belgain> ok, thanks
<the_belgain> i'll just request one upstream then
<the_belgain> another question - i'd like to add an init script for the program in this package; again done is included in the upstream release.  i probably wouldn't want this to be enabled by default - is there a way to easily add an init script and have it enabled / disabled through the System -> Administration -> Services menu?
<tbutter> I uploaded a new version at http://revu.tauware.de/details.py?package=jodviewer fixing the things mentioned by persia and bddebian. Linda still tells me it uses a wrong (too high) standards version. Is the linda on revu an older version or is it a bug in my package?
<amarillion> tbutter, I get that too
<amarillion> linda on revu is outdated
<amarillion> You should be using standards version 3.7.3 IIRC
<tbutter> thanks amarillion
<jonnymind> soren: people, I am sorry to bring up the topic again, but this is a thing that should be issued peacefully.
<jonnymind> soren: sorry, wrong nick
<jonnymind> Seveas: people, I am sorry to bring up the topic again, but this is a thing that should be issued peacefully.
<jonnymind> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460618
<ubotu> Debian bug 460618 in wnpp "ITP: falcon -- Repository manager for .deb packages" [Wishlist,Open]
<frafu> persia: A few weeks ago, you reviewed mousetweaks on revu. If you have time, could you (or any other reviewer) please review the new version that I uploaded yesterday.
<jonnymind> have you resolved the /usr/bin/falcon nameclash before submitting the package to debian?
<frafu> In fact, the graphical user interface of mousetweaks is present in the Mouse control panel since GNOME 2.21.5 and it would be odd to have the gui in hardy, but not the module providing the new functions present in the Mouse control panel.
<jonnymind> This is a quite relevant topic, and has also some legal aspect of non-secondary importance. I'd like to discuss this peacefully.
<bddebian> Heya gang
<geser> Hi bddebian
<bddebian> Heya geser
<rexbron> persia: iirc, policykit does not have python bindings at the moment, and  I do not want to have to rewrite the app in C++
<rexbron> persia: as for the native package thing, I would happily release a source tarball for any other distros that do not use debs, but it is easier for me to develope/maintain with the debian info in the same branch. If you run setup.py sdist, it builds a tarball without any of the vcs or debian files
<somerville32> If anyone is interested, please review thunar-svn-plugin: http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin
<andi5> hi... please excuse my novice question :-) ... how should i start pbuilder (or even what else should i use) to create a minimal (chroot) environment to build a package that will fail to build without pbuilder removing the build directories afterwards? i would like to take a look into that ... thanks in advance!
<frafu> andi5: the following page might help:  https://wiki.ubuntu.com/PbuilderHowto
<DRebellion> I have upstream source downloaded from the author's website but it is in .zip format. What procedures do I need to do if I am to convert it to .tar.gz ??
<DRebellion> Should I simply convert it or do I have to note down somewhere that I have?
<andi5> frafu: that is a long page, but i do not find anything that answers my question for me :-( (i have tried to read it before i asked)
<broonie> pbuilder login might be what you're looking for.
<broonie> There's some other ways to do it in the docs in the pbuilder package.
<rulus> I updated my gtkvd package earlier today (http://revu.tauware.de/details.py?package=gtkvd). If someone has time for a review, that would be great :)
<andi5> broonie: i.e. i would use pbuilder login --bindmounts and use X then, where X is ... pdebuilder, dpkg-buildpackage, ...?  thanks!
<broonie> dpkg-buildpackage
<andi5> ah, cool
<andi5> broonie: thanks a lot :-)
<civija> DRebellion: you can just open .zip file in file-roller and save it as .tar.gz
<DRebellion> civija: ok, just checking
<broonie> DRebellion: Probably worth putting a note in saying what you'v done (in the copyright file probably)
<civija> isn't changelog better place to note that?
<DRebellion> should the .tar.gz packages be in the format - <packagename>_<version>.tar.gz or <packagename>-<version>.tar.gz ?
<frafu> andi5: install pbuilder and the other modules indicated on that page; create the pbuilder environment with sudo pbuilder create; to build the package, use sudo pbuilder build  softwarename.dsc . To create the *.dsc file, you have to debianize (=create a debian directory with a few control files in your package ) your package and call debuild -S.   Here you can read how to debianize a package: http://doc.ubuntu.com/ubuntu/packagingguide
<andi5> frafu: i am testing an ubuntunized package already and my problem is more about failing builds than setting up pbuilder at all :-)
<geser> andi5: in such cases I login into pbuilder and build the package there with dpkg-buildpackage -b
<frafu> andi5: sorry for getting you wrong
<andi5> geser: yep, that is what broonie suggested as well... so i will most definitely go that way, thanks :)
<wallyweek> hi all!
<wallyweek> anyone could please have a look at http://revu.ubuntuwire.com/details.py?package=sdlmame
<foxmike> Hi!  I'm looking into backporting f-spot, but that would mean backporting cli-common from the hardy version.  Does anyone here knows if this is safe to do, or may it break the system?
<LucidFox> foxmike> cli-common doesn't need to be backported
<LucidFox> (I think)
<LucidFox> f-spot should run fine with the old cli-common, I know because I built it on Gutsy
<jdong> foxmike: locally, it should be a fairly safe thing to do to your own system
<LucidFox> foxmike> Just make sure to build against bundled mono-addins and libflickrnet, as they were only promoted to main in hardy
<LucidFox> And I wholly support backporting f-spot.
<foxmike> LucidFox: well, f-spot 0.7.1 has libflickrnet as dependency, which in turns has cli-common =>0.5.6 as dependency.
<foxmike> (as I understood it...)
<LucidFox> 0.7.1?
<LucidFox> foxmike> libflickrnet is in universe in gutsy
<foxmike> stand-by, I'm looking back my infos...
<LucidFox> and f-spot is in main
<LucidFox> to backport 0.4.1 to gutsy, you will need to drop meebey's changes from Debian and build it against bundled libflickrnet again
<foxmike> LucidFox: Ok thanks, I did not found libflickrnet in gutsy yet (was looking in main I think)  Thanks for the info!
<foxmike> And I meant f-spot 0.4.1 (typo...)
<LucidFox> foxmike> And while you're at it... against bundled mono-addins as well
<LucidFox> mono-addins is in universe in gutsy
<foxmike> LucidFox: this would be my very first backport (and packaging experience) and I am not sure what do you mean by "building against mono-addins".  Does it needs to be added to the build-dependencies?
<LucidFox> foxmike> On the contrary, my dear Watson - remove them from build-dependencies!
<LucidFox> Both mono-addins and libflickrnet
<LucidFox> you will also need to drop certain patches, let me see which ones
<foxmike> ok great!
<LucidFox> foxmike> forward_port_to_flickrnet_2.1.5 and link_system_libs
<LucidFox> make sure to also remove them from 00list
<LucidFox> or remove them _just_ from 00list so they're there but inactive
<LucidFox> and from debian/control, remove libflickrnet2.1.5-cil, libmono-addins0.2-cil and libmono-addins-gui0.2-cil
<foxmike> LucidFox: I'm done with debian/control, and I'll give you some feed back concerning 00list, thanks for your help!:)
<foxmike> LucidFox: does "40_flickr-export-crash" should be removed from 00list as well?
<LucidFox> no
<foxmike> ok, thanks
<mok0> how can I create a new page on the wiki?
<mok0> I can delete pages, but not create them ;-)
<stgraber> just enter the URL you want and click on create the page (or something like this)
<stgraber> Create new empty page that's
<mok0> stgraber: heh, cool.
<rexbron> if anyone is interested in getting a head start on revu day, take a look at http://revu.ubuntuwire.com/details.py?package=ubuntustudio-controls . Thanks!
<amarillion> Can someone point me to some good docs explaining the use of hyphens in man files?
<amarillion> This comes up a lot in reviews yet I can't find documentation for it
<emgent> hello people
<tbutter> amarillion, maybe this: http://lists.debian.org/debian-devel/2003/03/msg01481.html
<geser> amarillion: in UTF-8 there is a difference between - like in --option (\- in manpages) and - like in "two-sided" (- in manpages). Especially in options it's importaant to use the correct one else the searching for it inside the manpage gets harder as the '-' key matches \- in manpages.
<amarillion> geser, ok, but which one should I use on the NAME line?
<amarillion> (so the whatis info is still correct)
<emgent> omg big error in wordpress :P
<emgent> default options:
<emgent> Name	URL	Categories	rel	Visible	Action 	
<emgent> Planet Debian
<emgent> 	planet.ubuntu.com	Blogroll 		Yes	Edit	Delete	
<emgent> it'snt debian planet, this is ubuntu planet :P
<emgent> i go to fix
<frafu> Could anybody please review the following package: http://revu.tauware.de/details.py?package=mousetweaks  ? I hope that mousetweaks will make it into hardy as its gui has been integrated into GNOME since GNOME 2.21.5.  Thanks
<foxmike> LucidFox: ok it builds well now, I had to change the version number of libndesk-dbus-glib1.0-cil (>= 0.3.0) to libndesk-dbus-glib1.0-cil (>= 0.3-0) as the version installed on gutsy is 0.3-2.  Thanks again for your help!
<LucidFox> foxmike> excellent, looking forward to seeing the backport in gutsy
<asabil> LucidFox: would it be possible to ask you to review my new libgee package please ?
<LucidFox> asabil> I'm not a MOTU
<ScottK> Good morning all.
<LucidFox> so I can't advocate it anyway
<asabil> oh oki
<ScottK> LucidFox: But you can give him good feedback and maybe when I MOTU does have time, it gets advocated on the first try.
<imbrandon> moins ScottK
<LucidFox> ScottK> I already reviewed it once :)
<ScottK> Ah.
<ScottK> heya imbrandon
<ScottK> mok0: Had any luck with avscan?
<ScottK> mok0: I think your packaging is looking quite good.  I advocated both of your packages I looked at.
<mok0> ScottK: did you see my mail?
 * ScottK looks
<mok0> ScottK: thanks!
<amarillion> REVU needs double-post protection
<amarillion> just for kicks, post a comment and press F5 :)
<ion_> I donât understand why webapp developers keep on making programs that directly respond to POST with the resulting page.
<ScottK> mok0: I don't seem to find it.
<mok0> I sent it to kitterman etc
<ScottK> amarillion: The code is on Launchpad.  Patches gratefully accepted.
<ScottK> mok0: What was the subject?
<amarillion> ok :)
<mok0> "avscan woes" :-)
 * ScottK looks again.
<amarillion> Looks like my package hit a snag
<amarillion> <dholbach> "alex4 hangs (on AMD64) when starting the game. :-/"
<mok0> Scott: sent it to yourfirstname@yourlastname.com
<ryanakca> james_w: ping, would you mind testing bzr_1.1-1 on hardy alongside bzr-buildpackage, before I file a sync request?
<ScottK> mok0: Right.  I don't seem to have it.  Either in my inbox of my spam folder.
<ScottK> mok0: When did you send it?  I greylist, so it could still be in transit.
<mok0> ScottK: about 1 hr ago
<ScottK> OK.  Depending on your mail server's retry delay, it may be in the air still.
<mok0> ScottK: http://paste.ubuntu.com/3711/
<ScottK> mok0: Thanks
<james_w> ryanakca: sure. I'll get to that in a moment. Thanks for the prod.
<ScottK> mok0: I had to make some changes in the clamav packaging to get 0.92 to build on Dapper.  The most extreme change I had to make was to force it to use GCC 3.4.
<ryanakca> james_w: kk, thanks :)
<ScottK> I didn't have to patch any of the actual code though.
<mok0> ScottK: how was the avscan patch made?
<mok0> I see the same mods in the feisty version
<ScottK> mok0: I took that patch from the feisty avscan and tried to make the same/similar changes to the dapper version.
<mok0> ScottK: Aha
<ScottK> mok0: Since some of the code had changed, the patch didn't apply cleanly.
<smarter> hi
<ScottK> mok0: So I'm thinking I missed the definition of something somewhere.
<mok0> ScottK: that must be the source of the problem. As I said the other day, the patched code seems to be a mixture of two API's
<smarter> can someone please review my extremetuxracer package? http://revu.ubuntuwire.com/details.py?package=extremetuxracer
<ScottK> mok0: Since you actually understand C code, you might (would probably) find it easier to start over with the feisty patch and that dapper avscan and see if you can integrate them in a sensible way.
<mok0> ScottK: I was trying to do just that, but kept running into some other dependency problem
<mok0> ScottK: Is your backported version of clamav working ok on dapper?
<ScottK> mok0: Yes
<ScottK> It works well with all the other applications I've tested it with.
<mok0> ScottK: great.
<ScottK> I think I'm very close to being ready to do the backport, but I'd like to find a way to solve the avscan problem.
<mok0> ScottK: I will take a closer look at the code tomorrow.
<mok0> ScottK: I need to make dinner for the family shortly :-)
<ScottK> mok0: Thank you.  There's no way I can solve this, so I'm dependent on help.
<ScottK> Understand.
<mok0> ScottK: I hope I can help
 * ScottK too
<yamal> MOTUs, an improved sabnzbd package is awaiting review @ http://revu.tauware.de/details.py?package=sabnzbdplus
<amarillion> speed-game is ready for review as well: http://revu.tauware.de/details.py?package=speed-game
<mok0> Scott, incidentally, is there a reason not to use the newest avscan version 3.1.1? It's clamav dependency is the same (0.90.1) it seems
<amarillion> Could anyone who is on AMD64 help me confirm a bug in alex4? http://revu.tauware.de/details.py?package=alex4
<ScottK> mok0: It needed the newer endeavour, which needed some other stuff, and from there it got ugly.  I tried that first.
<amarillion> According to danielh it hangs on start but I can't confirm it
<mok0> ScottK: I was able to compile feisty's endeavour on dapper
<mok0> but perhaps thats not new enough?
<ScottK> mok0: Let me look into that then.  I don't think I tried that.
<rzr> http://www.vnunet.com/vnunet/news/2207369/microsoft-patents-employee
<albert23> amarillion: I can confirm alex4 hangs on amd64 when you start a game.
<amarillion> albert23, thanks
<albert23> amarillion: no problem
<amarillion> dang... this is going to be hard
<amarillion> albert23, are you on hardy?
<albert23> amarillion: Yes, I am
<ScottK> mok0: The irony in this is I hadn't looked at the Feisty version and now that I have, I find I'm the one that uploaded it.
<mok0> ScottK: no wonder, considering the amount of uploads you have...
<lucas> geser: around?
<lucas> geser: when you submit patches about dash-related build failures to debian, it would be great if you could turn them into ready-to-upload NMUs
<lucas> that way, I can just apply your patch and upload, and you get credited as the NMUer, instead of me
<ScottK> lucas: I gather that's generally true, and not just for geser?
<ScottK> I just fixed one here the other day that needs to be dealt with in Debian.
<lucas> ScottK: yes. I just noticed that geser filed a lot of those
<lucas> I'm trying to fix all those bugs in debian, so better patches are easier for me :-)
<ScottK> lucas: If I prepared an NMU to fix a debian/rules bashism and also fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392927, would you sponsor that?
<ubotu> Debian bug 392927 in libspf0 "Spfmilter dies unexpectedly with SIGABRT" [Grave,Open]
<ScottK> or should I just fix the bashism?
<jonnymind> I have removed sources for zlib and so on from the orig package, and I got this warning from dpkg-buildpackage
<jonnymind> dpkg-source: warning: ignoring deletion of file modules/feathers/zlib/zlibstream.cpp
<jonnymind> and so on. Is this ok?
<james_w> jonnymind: it means that the files won't actually be deleted.
<jonnymind> Uhm... and is this good or bad?
<lucas> ScottK: ok, you can fix both
<ScottK> OK
<lucas> for #392927, please include a summary of the problem and the fix in the changelog
<amarillion> jonnymind, it's easiest just not to delete them
<lucas> reading the bug log, the fix is only a good-enough workaround?
<james_w> jonnymind: if you really need to get rid of them then repack the upstream tarball. Otherwise you could just leave them there. The important thing is that the files are not used when building.
<lucas> ScottK: please use dch --qa
<ScottK> lucas: will do
<jonnymind> Ah, ok: I was told earlier to remove them as they are duplicate of sources stored also elsewhere.
<lucas> and set Maintainer to: Debian QA Group <packages@qa.debian.org>
<lucas> and remove the Uploaders
<amarillion> jonnymind, yeah I'm confused about that too
<james_w> jonnymind: yeah, you want to avoid using them when building to stop creating extra work for the security team etc. However having them in the tarball isn't necessarily bad.
<geser> lucas: will remember for the next time
<amarillion> in the docs you read everywhere that it's bad form to repack the upstream tarball
<jonnymind> In that case, I will leave there. They are optionally used in compilation (useful on those platform that doesn't provide a compatible package).
<amarillion> probably best
<james_w> amarillion: it is usually preferred to avoid it where possible, but it's not always avoidable.
<Dabian> Hiaya!   I just apt-got source for evolution.  However, GDB seems to point to the wrong line.  Is there a hard way to fix that, or even better, a fairly easy way?
<jonnymind> ScottK: Ok, new release of falconpl up in seconds.
<jonnymind> I am adding download section to the site right now, so uscan will report version missing for a while
<wallyweek> hello!
<jonnymind> Ops, I forgot a small detail.
<wallyweek> anyone willing to review my package, please? :D  http://revu.ubuntuwire.com/details.py?package=sdlmame
<jonnymind> Done. -- the official Falcon Programming Langauge 0.8.8 package is up, and the ubuntu falconpl is at BUG 174470
<ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
<Flare183> Search Bugs for Nemo
<Flare183> can some one explain to me how to use "install"?
<gladier> ey guys - im packaging something up and get this message "dpkg-checkbuilddeps: error: control file must have at least one binary package part" along with "dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting."
<james_w> gladier: the first message indicates that your debian/control is not well-formed.
<james_w> The second indicates that you need to install some more packages.
<gladier> ...
<gladier> into my local system?
<gladier> onto*
<james_w> I can help you correct the first error if you pastebin your control file.
<james_w> gladier: yes, indeed.
<gladier> http://nopaste.ch/df65f93afaaaa8d.html
<james_w> gladier: there is no Version: field, so you should remove that line.
<james_w> The other issue is that there is no blank line before the Package: line.
<james_w> The parser uses the blank lines to break the file up in to sections.
<gladier> ok i spose this drops down to .. what way is best to build a deb?
<gladier> thered dpkg -b and dpkg-buildpackage -rfakeroot
<gladier> both seem to need files organised differently
<james_w> gladier: definitely the latter. You can do the former, but the latter is far, far easier.
<gladier> whats the diff?
<gladier> ive always had trouble with dpkg-buildpackage -rfakeroot
<james_w> dpkg -b is the low level assembly of the .deb itself from the compiled files etc. dpkg-buildpackage uses debian/rules etc. to actually build the package.
<gladier> hum ... another wierdness .. i can compile the source manually but throw it through dpkg-buildpackage and it dont work .. *sigh*
<james_w> gladier: do you want help to diagnose the issue, or was that just a throwaway comment?
<gladier> i dont know lol
<gladier> mayaswell learn something and have a hand fixing it
<gladier> otherwise it would be a dpkg -b
<gladier> james_w: this is the dpkg-buildpackage output
<gladier> http://pastebin.com/d4697bf58
<james_w> gladier: could the segfault be because of WARNING **: Could not load file or assembly 'Mono.Cairo,?
<gladier> i just saw that
<gladier> make[1]: *** No rule to make target `Ubuntu'.  Stop.??
<james_w> gladier: what did you run?
<gladier>  dpkg-buildpackage -rfakeroot
<james_w> gladier: and so do you have a call to 'make Ubuntu' in debian/rules?
<gladier>         $(MAKE) DESTDIR=$(CURDIR)/debian/oessysmon install
<gladier> thats it
<gladier> which pulls out to /usr/bin/make DESTDIR=/home/gladier/Novell Ubuntu Repository/Ebuild/app-admin/oessysmon/oessysmon-0.1.6/debian/oessysmon install
<james_w> gladier: you need
<james_w>         $(MAKE) DESTDIR="$(CURDIR)"/debian/oessysmon install
<james_w> or
<james_w>         $(MAKE) DESTDIR="$(CURDIR)/debian/oessysmon" install
<gladier> of course
<gladier> its now a happy little vegemite
<gladier> ^^ cant tell im an aussie
<gladier> also incase your wondering - im busy getting all of the novell linux stuff from suse -> ubuntu via the n4g Gentoo overlay
<LucidFox> This is so annoying, KMail is one of the last two remaining KDE3 applications I still use and I can't replace it :(
<LucidFox> Evolution, Sylpheed and Claws-Mail are all ugly and cluttered
<smarter> try thunderbird
<gladier> groupwise :)
<gladier> mozilla products -> bin
<LucidFox> gladier> groupwise?
<ScottK> LucidFox: KDE4 version is coming soon.
<gladier> that free novell thing which does contacts / email (pop/imap/groupwise) / calander
<LucidFox> gladier> It's not free, it's proprietary
<gladier> its free .. just not open source
<gladier> the client is free
<LucidFox> It's not free software.
<gladier> the server is a totally differnet matter
<gladier> but the client is free ... garunteed
<LucidFox> As I said, it's not free as in "free software". It's "free" in the sense that it's zero-cost.
<LucidFox> But it's proprietary.
<gladier> its closed source yes
<jonnymind> People, I would really appreciate some early comment on BUG 174470 before the REVU session of tomorrow.
<ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
<\sh> yawn
<\sh> why is debmirror not mirroring the Release{.gpg} file?
<asabil> any MOTU willing to review a package please ?
<\sh> emgent, ping phpbb2 is there already a CVE pending for this XSS ?
<\sh> emgent, or did you request it?
<rexbron> Anyone looking to get a head start on revu day? Please take a look at http://revu.tauware.de/details.py?package=ubuntustudio-controls . Thanks!
<geser> rexbron: the revu day started hours ago
<rexbron> geser: timezones
<Seveas> geser, he loves spamming his package :)
<rexbron> O.o
<rexbron> got to get it out there some how
<rexbron> rock out, with your... source package...
<jonnymind> Oh, so this is ALREADY revu day?
<jonnymind> in this case
<jonnymind> http://revu.tauware.de/details.py?package=falconpl it's now up and stable.
<jonnymind> ready for REVU.
<james_w> ryanakca: hi. I'm happy to have bzr-builddeb synced, as long as bzrtools is as well.
<james_w> ryanakca: there is one test failure, but that is a problem with the test rather than the plugin. It will require a source change to fix, I will try and release that soon.
<ryanakca> james_w: ok, so sync bzr, bzr-builddeb and bzrtools?
<emgent> heya
<ryanakca> hey emgent
<james_w> ryanakca: yeah, I'd say, and bzr-gtk too probably.
<ryanakca> james_w: ok, will do
<Kmos> that's already requested i think =)
<Kmos> so it will be done next week
<ryanakca> Kmos: okies :)
<james_w> ryanakca: oh, and bzr-svn as well of course.
<ryanakca> james_w: *nods*
<asabil> any MOTU with some free time wanna check this again please : http://revu.tauware.de/details.py?package=libgee ?
<ScottK> mok0: I got the same build problem with the avscan from Feisty.  Not sure what to do next.
<ScottK> I uploaded the Feisty endeavour to the ubuntu-clamav PPA for dapper and it built just fine.
<ScottK> So at least the build-deps are there now.
<ScottK> mok0: It does, however build against Feisty's clamav in a Feisty environment.  Urgh.
<ScottK> mok0: Finally got your mail, too.
<mok0> ScottK: good
<mok0> ScottK: I will try to debug avscan tomorrow, and se what needs to be done to link it against the new clamac
<mok0> s/ac/av
<ScottK> mok0: Thanks.
<rulus> If anyone has time to review http://revu.tauware.de/details.py?package=gtkvd, please do! :)
<pochu> bigon`: will you request a sync for d-feed? would be nice to have it in Ubuntu too :)
<geser> pochu: you mean d-feet? see bug #184344
<ubotu> Launchpad bug 184344 in ubuntu "Please sync d-feet 0.1.8-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/184344
<pochu> geser: right, typo. Thank you.
<jonnymind> pochu: hello.
<pochu> hi jonnymind
<jonnymind> :-)
<jdong> sourceforge bug 1495942
<ubotu> Sourceforge bug 1495942 "MP4Box crash at raw MPEG4 (A)SP import CVS20060527" [Pri: 5,Closed fixed] http://sf.net/support/tracker.php?aid=1495942
<jdong> aww.
<jdong> ok
<crimsun> ok, u-u-s queue time.
<crimsun> cd
<wallyweek> could anyone please review my package? Thanks :D  http://revu.ubuntuwire.com/details.py?package=sdlmame
<bddebian> wallyweek: Any luck with the home dir thing?
<jdong> crimsun: do you do the u-m-s queue too?
<emgent> heya
<wallyweek> bddebian: it works for me. I tried several different configs
<bddebian> Hmm, OK
<jdong> crimsun: because I'd love to find someone to sponsor bug 182653 :)
<ubotu> Launchpad bug 182653 in transmission "Please update to 1.01" [Wishlist,Confirmed] https://launchpad.net/bugs/182653
<wallyweek> bddebian: don't mean to bother, but are your sure about the dot in ~/.mame/roms ? <blushing>
<asabil> can someone review my package please : http://revu.tauware.de/details.py?package=libgee
<asabil> thanks
<crimsun> jdong: done.
<crimsun> hmph, .ubuntu.com is quite sluggish over my route.
<\sh> could be me, mirroring all the day ;)
<\sh> damn..this django is addictive
<somerville32> \sh: Do you think you could pull yourself away to do a quick review inbetween now and the next game? :]
<\sh> somerville32, it's not a game...it's python rails ;)
<\sh> somerville32, give me the url :)
<somerville32> http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin
<somerville32> :)
<geser> \sh: turbogears is also very nice
<\sh> geser, I'm coding on "poor mans build service" , well the name is crap I know, but "duk" was also stupid ;) with django as framework in front of the scenes with some xmlrpc stuff etc. import of source files and checking the sigs etc is just finished
<\sh> s/mans/men's/
<emgent> heya \sh
<emgent> :P
<\sh> hach...what was the login scheme to revu? LP accounts?
<geser> \sh: similar to the opensuse build service?
<\sh> geser, yeah, but with debian inside, well hopefully I'll come so far that I can implement RPM building on debian systems ;)
<\sh> bah...
 * \sh doesn't have any revu powers anymore
<somerville32> \sh: You just use your launchpad id and the password they provide
<persia> \sh: If you've not been using REVU recently, try the email address from an upload you made in September or so.
<somerville32> s/launchpad id/e-mail you used to upload
<persia> somerville32: It'S not related to LP id.
<\sh> No REVU account for sh@sourcecode.de exists yet.
<persia> \sh: Check the other accounts on your key
<\sh> persia, my old one is not working either
<crimsun> you're probably experiencing the same symptoms I had.
<\sh> do i need as a reviewer to be member of this contributor group on LP
<persia> Are there any other REVU admins around?  I am about to leave, and would really appreciate it if someone else could enable a reviewer account for \sh.
<persia> \sh: You get that from MOTU anyway
<geser> \sh: ask an revu admin to create an account for you
<\sh> geser, how is admin? siretart, sistopy , persia and?
<\sh> well, it's still time ... the new day is only 42 minutes old
<effie_jayx> what script can I use for updating the mantainer field }
 * persia does it
<geser> effie_jayx: there is a script in ubuntu-dev-tools for it
<\sh> effie_jayx, update-maintainer from the ubuntu-dev-tools package
<wallyweek> it's late... g'night all!
<\sh> persia, thx
<\sh> effie_jayx, or you can use something like this: http://pastebin.ubuntu.com/3730/
<\sh> effie_jayx, push it to ~/bin then :)
<\sh> and start it in the debianzed source tree
<\sh> quick hacks
<effie_jayx> thanks guys
<persia> \sh: I won't be able to watch the keyring sync, but you ought to be able to recover your password in 20-30 minutes.
<\sh> persia, thx
<persia> Oh.  Account is for the email address you complained about first.
<\sh> persia, sourcecode.de?
<geser> \sh: your script missed those packages which use a debian/control.in file
<\sh> geser, yeah
<\sh> geser, as I said a quick hack...but good to learn
#ubuntu-motu 2009-01-12
<TheMuso> RAOF: You no longer have stuttering with your notebook hda and pulse? AWesome. Likely somethign to do with pulseaudio being updated last week.
<RAOF> TheMuso: Indeed.  Yay!
<TheMuso> RAOF: Thats great!
<ia> hello. if configure script requires some lib package for compilation, then binary version of lib should be enough, or -dev version also should be installed?
<jmarsden> ia: If the code ebing compiled will use the library, you are likely to need the -dev package.
<jmarsden> s/ebing/being/
<ia> jmarsden: ok.
<pochu> ia: you need the -dev package too, as it will have the .pc file which configure looks for
<ia> another question. looks like it's a cycle process - i edit control file and add build-depends packages, runs pbuilder, at "configure" step script shows ordinary error, which tells, that one more package necessary for compilation, i edit control file and add this package name, run pbuilder again and so on... does exist some way (or script, maybe) which look through config* files and just shows all package deps at one time in one line? of course, i use dh_make
<ia> , but looks like it doesn't take into account all requiring packaging deps.
<jmarsden> ia: There's no automatic way to translate from the filenames a configure script uses to Ubuntu package names, that I know of.
<Hobbsee> ia: often websites will tell you what you need to build them
<jmarsden> But you can perhaps read the README or INSTALL file that comes with the original source tarball and add most of what it will need from a requirements list you may find in there?
<Hobbsee> that too
<RAOF> If you can read autofoo, configure.ac + apt-file can give you a lot of pointers.
<ia> ok, thanks very much for answers :-)
<jmarsden> Is it OK to ask for something from Debian experimental (yui 2.6.0) to be synced into Jaunty?  Or does the package have to be in sid before it can be synced?
<RAOF> jmarsden: It's OK to sync from experimental, and it's happened a lot more this time 'round, what with the Lenny freeze and all.
<RAOF> jmarsden: Just make sure that it's not in experimental because it's /experimental/ :)
<jmarsden> RAOF: Cool, thanks, I'm testing it now on Intrepid, but it looks fine to me so far.  It's needed as a prerequisite for webgui, a web app/CMS I am hoping to get into Jaunty...
<brownianmotion> Hi folks, I'm trying to backport a package (virtualbox-ose 2.1) from jaunty to intrepid, but having some troubles...
<slytherin> brownianmotion: what trouble?
<brownianmotion> slytherin: it doesn't build. http://paste.ubuntu.com/103777/
<brownianmotion> kmk fails in what I assume is an unexpected way.
<superm1> i havent looked at the build log, but kmk might need backporting too possibly
<brownianmotion> I'm using the source from https://launchpad.net/ubuntu/+source/virtualbox-ose/2.1.0-dfsg-1ubuntu2 and dpkg-source/dpkg-buildpackage
<slytherin> brownianmotion: have you made sure all the build dependencies are available in intrepid?
<brownianmotion> Oh. Hmm...
<brownianmotion> Had problems with the build-deps initially, but now I've gone through the dsc and added everything.
<brownianmotion> Then deleted the directory and started again from dpkg-source.
<brownianmotion> Always ends at the same place.
<brownianmotion> Checking kbuild versions now.
<brownianmotion> superm1: Worked! Installed kbuild 0.1.5svn from jaunty, now building. Thanks a bunch!
<superm1> no prob
<ScottK> pochu: We've uploaded Amarok 2 to Jaunty, so I started to take a look at emesene to see about dropping Amarok from it and decided I'm way to tired to think about it, so now would be a great time for you to update it/drop Amarok support.
<dholbach> good morning
<fabrice_sp> Good morning dholbach!
<dholbach> hiya fabrice_sp
<Hobbsee> evening horseman
<dholbach> hiya Hobbsee
<iulian> Good morning dholbach.
<dholbach> heya iulian
<dholbach> congratulations iulian :)
<iulian> Thanks ;)
<\sh> moins congrats iulian
<slytherin> iulian: Congrats. :-)
<iulian> \sh, slytherin: Thank you.
<didrocks> morning o/
<hyperair> when a source tree has files copyrighted by the same person, but with varying years, do i have to list all of them?
<hyperair> as opposed to just path/* Copyright: <lowest year>-<highest year> Somebody
<iulian> Why is ubuntu-dev a member of the revu-uploaders team in launchpad? Do we still need the revu-uploaders team? REVU is now using OpenID and the GPG key will be automatically retrieved from launchpad.
<dholbach> iulian: which keys will be automatically downloaded from LP?
 * hyperair feels ignored
<dholbach> hyperair: just mention all the years in the same line, that should be fine
<dholbach> if there's a 2004-2006 and a 2005-2008, just mention 2004-2008
<iulian> dholbach: "This team is no longer necessary, as now that REVU uses OpenID through Launchpad it will retrieve your key once you log in for the first time."
<dholbach> hyperair: don't feel ignored that easily - IRC is an asynchronous medium - it sometimes just takes a bit
<dholbach> iulian: so you have to have logged in first before you upload a package to it, is that right?
<iulian> dholbach: Yes, you will need to log in before uploading a package.
<dholbach> iulian: looks like the team then is truly obsolete
<dholbach> iulian: we can close it down by filing a launchpad answers ticket
<hyperair> dholbach: alright thanks
<iulian> dholbach: Anyway, just to be sure, we should talk to some revu admins, like RainCT.
<hyperair> dholbach: what about if the Copyright contains something like.. Copyright: ... Mj<F8>lner Informatics
<hyperair> i'm pretty sure the <F8> shouldn't be there
<dholbach> try finding out what the name really is - I don't know, sorry
<iulian> hyperair: You shouldn't change it if it's copyrighted under that name.
<iulian> hyperair: Better talk to upstream.
<iulian> Some archive admins might get upset and reject it.
<liw> changing it to the corresponding character in unicode is perfectly fine
<liw> hyperair, see latin1(7) to see if F8 in iso-8859-1 charset would match what is intended
<hyperair> liw: just did a google search. turns out "Mjlner Informatics" exists
<hyperair> without the character <F8>
<hyperair>        370   248   F8     Ã¸     LATIN SMALL LETTER O WITH STROKE <-- this?
<liw> that might be because google or some web page has dropped the f8 letter, though
<hyperair> Ã¸
<hyperair> hmm
<soren> "MjÃ¸lner" sounds reasonable.
<soren> It's the name of Thor's hammer, fwiw.
<hyperair> i see
<iulian> It is MjÃlner Informatics.
<hyperair> ah
<soren> Capital Ã¸? Seriously?
<iulian> Oh, well...
 * iulian hides
<soren> www.mjolner.dk suggests otherwise.
<hyperair> www.mjolner.dk
<hyperair> yeah
<hyperair> haha
<hyperair> thanks
<hyperair> =)
 * directhex smites hyperair with a hammer
<hyperair> >=O
 * hyperair hammers directhex into the ground
<hyperair> o noes. now i've damaged the ground
 * directhex bills hyperair for the damaga
<directhex> e
 * mok0 bills directhex & hyperair for bad jokes
 * directhex sends a duck after mok0 to bill him
<mok0> Aargghh
<hyperair> lol
 * hyperair doesn't pay bills
 * mok0 ducks and avoids bill
<slytherin> dholbach: you don't need to 'be logged in' in revu for an upload. You just need to login once so that your key is synced. And as iulian suggests the revu uploaders is obsolete now.
<dholbach> slytherin: yeah, that's what I gathered
<persia> Obsolete, but perhaps still interesting until after 21st July.
<slytherin> persia: why?
<persia> Because we don't have the other side of the code that is used for the key syncs, so it's currently an incomplete open implementation.
<persia> If something goes wrong during the updates to LP, we may need to revert to the group.
<persia> After 21st July (or thereabouts), we should be able to see the code changes before they land, and coordinate, which makes the group less meaningful as a fallback.
<slytherin> oh, you mean the open sourcing of LP. :-)
<persia> Right.  Currently we have a reverse-engineered solution, which works, and a fallback to a differently reverse-engineered solution.  I don't see the point of dropping the fallback until we really know we don't need it.
<slytherin> dholbach: do you plan to include anything specific to CDBS in your session in UDW?
<dholbach> slytherin: I don't think so
<slytherin> ok
<directhex> "it's evil, use dh7 instead"? :p
<directhex> hm, pidgin appears to need some emergency patchin'
<Laney> hmm?
<Laney> is this why i can't get on msn?
<directhex> Laney, i can only find references to old bugs is the funny thing
<directhex> Laney, but it's not just you
<Laney> It's happened before
 * Laney hops over to hash pidgin
<stefanlsd> Laney: not sure of ur exact issue, but i helped a user debug his pidgin connect to msn problem, and it happened that his isp (i think uk also) was doing some transparant msn proxying that was messing it up. let me try find bug
<Laney> I'm on JANET, doubt they do any of that
<directhex> https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/316252
<ubottu> Launchpad bug 316252 in pidgin "Unable to retrieve MSN Address Book" [Undecided,New]
<Laney> Oh, one of These Bugs.
<Laney> "MSN is having internal server certificate  problems (Unable to retrieve Address Book).  Just wait
<Laney> "
<directhex> failure on all protocol ver 15 serving. non-libpurple clients fall back to older versions on failure
<directhex> and <v15 is fine
<Laney> libfail
<Laney> 12/01 09:41:35 <@root> MSN - Logging in: Authenticated, getting buddy list
<Laney> 12/01 09:41:37 <@root> MSN - Logged in
<Laney> bitlbee \o/
<directhex> Laney, bitlbee will be using an old proto version
<directhex> bitlbee-1.2.3/protocols/msn/ns.c:	g_snprintf( s, sizeof( s ), "VER %d MSNP8 CVR0\r\n", ++md->trId );
<directhex> there you go, MSNP8
<Laney> excellent
<Laney> I don't need no fancy schmancy features
<directhex> yay for free software - wanna know what proto something uses? apt-get source; grep
<directhex> http://messenger.msn.com/Status.aspx
<directhex> dear microsoft. LIES. love directhex
<slytherin> directhex: when you cross one evil (CDBS) to bit the other evil (java packaging) life becomes easier. :-P
<slytherin> s/cross/use
<directhex> slytherin, and multiply that by maven?
<slytherin> directhex: no, divide by ant. keep maven buried. :-D
 * directhex hands slytherin nant
<sunny> hi
<pochu> ScottK: uploading emesene
<directhex> Laney, FYI, installing "msn-pecan" adds a MSNP12 lib to pidgin, accessible by creating an account of type "WLM" instead of "MSN"
<Laney> yeah I saw
<Laney> I'm taking the opportunity to do some work instead :(
<slytherin> does anyone know if empathy can do video chat with gtalk?
<dholbach> slytherin: does empathy allow that already?
<dholbach> do we have somebody who could lead the Ubuntu Developer Week GETTING STARTED session in portuguese?
<wgrant> slytherin: I think it does. It does voice, at least.
<dholbach> "Eu nÃ£o falam PortuguÃªs."
<joaopinto> dholbach, "Eu nÃ£o falo..." :P
<joaopinto> "falam" is plural
<dholbach> joaopinto: haha... it's what translate.google.com said
<slytherin> dholbach: I don't know. I don't even know if empathy allows video chat on any protocol.
<dholbach> slytherin: http://opencomputer.net/2008/08/18/a-tour-of-empathy-im-client/ suggest yes
<tuxmaniac> dholbach: but the empathy at my place doesnt show up
<tuxmaniac> as in video
<tuxmaniac> may be some extra plugin?
 * tuxmaniac checks
<dholbach> tuxmaniac: no idea which telepathy-* package you need installed for that
<dholbach> maybe only with gtalk?
<tuxmaniac> slytherin: leave and pidgina nd come on empathy now. We check right away if you are free :-P
<tuxmaniac> *leave pidgin and
<tuxmaniac> dholbach: btw, you coming to fosdem?
<dholbach> tuxmaniac: no, I guess not
<slytherin> tuxmaniac: I am in office. We can check in night. :-)
<tuxmaniac> slytherin: ok
<ScottK> pochu: Thanks.
<cyberix> Hello. I cannot find a bug about packaging python2.6
<huats> hello dear motu community :)=
<cyberix> Is it just that I cannot search properly?
<cyberix> Could someone please point it out to me so I don't file a duplicate
<pochu> cyberix: https://blueprints.edge.launchpad.net/ubuntu/+spec/python-for-jaunty
<pochu> and https://wiki.ubuntu.com/Python2.6And3.0
<cyberix> thanks
<ScottK> cyberix: Python 2.6 is already planned for upload soon.
<lidaobing> help review fqterm: http://revu.ubuntuwire.com/details.py?upid=4482, thanks
<ScottK> YokoZar: I thought you'd be interested in http://blog.cihar.com/archives/2009/01/12/cygwin_in_wine/ if you hadn't seen it.
<ScottK> https://edge.launchpad.net/~ubuntu-dev/+polls
 * persia waits 19 hours as fast as possible
<lidaobing> the archive function in http://revu.ubuntuwire.com/ no longer works
<lidaobing> any know what's the problem?
<lidaobing> a error log in : http://paste.ubuntu.com/103926/
<persia> lidaobing, What are you trying to archive?
<lidaobing> persia, I want to archive ibus, which is already in jaunty
<lidaobing> persia, and llk-linux, which is also already in it
<lidaobing> persia, and I have login
<persia> Hrm.  Seems you need special rights, as it works for me.  Dunno which rights you need.  Please file a bug against REVU with the trace, and mention that it happens for you, but not for me, which may help the REVU Hackers track down the issue.
<persia> (https://launchpad.net/revu/+bugs)
<lidaobing> persia, got it, thanks
<persia> Anyway, both archived.
<lidaobing> persia, some more need archive: ibus-m17n
<lidaobing> persia, and ibus-table, thanks
<persia> lidaobing, OK.  Doing them now.
<persia> So ibus will be default for Jaunty, or still testing?
<persia> What about ibus-hangul ?
<lidaobing> persia, others still need advocate
<persia> Is there an ibus-anthy underway?
<lidaobing> persia, I think scim is still the default
<lidaobing> persia, yes, but it can't built under current ibus, still under investment
<persia> Oh well.  I was hoping to test :)  Anything else for ja?
<lidaobing> persia, i make a mistake, ibus-anthy built well, but it can't use, i will crash when running
<persia> Well, it still doesn't work.  You have all the people you need working on it?
<lidaobing> persia, Hmm, I don't have enough time on this, :-)
<lidaobing> persia, and I need help
<persia> Have you sent a request to anthy upstream?  I know several of them use Ubuntu.
<lidaobing> persia, I sent it on ibus
<lidaobing> persia, check this: http://code.google.com/p/ibus/issues/detail?id=222
<lidaobing> persia, maybe you can forward to the anthy team
<persia> Well, I can mention it in a context that may gain attention, but it looks to me like the ibus engine isn't calling anything in the ideal way, although my python is weak.
<persia> I'm not sure if it would be considered an anthy bug, or an ibus bug.
<lidaobing> persia, for more information for packaging progress (and current work) ibus-anthy, check it https://bugs.launchpad.net/ubuntu/+bug/312715
<ubottu> Ubuntu bug 312715 in ubuntu "[needs-packaging] ibus-anthy" [Undecided,In progress]
<lidaobing> persia, do you know how to use ubottu (e.g. how to display help page?)
<persia>  "/msg ubottu help", I think.
<lidaobing> persia, don't work, :-)
<persia> Try "usage".
<lidaobing> persia, got it: http://wiki.ubuntu.com/UbuntuBots
<lidaobing> ubottu, tell lidaobing about java
<ubottu> lidaobing, please see my private message
<bddebian> Heya gang
<ScottK> Heya bddebian.
<bddebian> Heya ScottK
<thekorn> hello MOTUs,
<thekorn> I'm looking at ubuntu-dev-tools right now and try to switch from py-lp-bugs to launchpadlib,
<anakron> hello
<james_w> hey thekorn
<thekorn> what's the reason for this "ubuntutools" package, which only contains this one ppaput.py script? - why is this script not in the package root
<james_w> thekorn: jpds was looking at this as well I believe
<thekorn> hello anakron and james_w
<james_w> thekorn: check the changelog for that
<thekorn> james_w, ok, will check the changelog now, just asked because I thought anybody knows a reason offhand
<james_w> thekorn: I know that it is given in the changelog
<thekorn> ok, that's fine
<thekorn> thanks
<\sh> I hate my life I hate my life, repeat many times
<\sh> why didn't I learn a real job like butcher or mason
<persia> \sh, Just remember, it's easier to debug code or replace servers than to recut meat or replace walls, and that people have lower expectations for computers.
<\sh> persia: not when you are dealing with crappy commercial software...:(
<persia> Yeah, well, that's not entirely pleasant.
<\sh> thekorn: did you work further on the dbus integration of lp-api?
<thekorn> \sh, hi, well kind of, lp:~thekorn/+junk/leonov.dbus.backend has some changes.
<\sh> thekorn: nice :) I'll check it next week...then I have again time to work on leonov and friends ... too much real life work these days
<thekorn> \sh, I also put some work into the database things, unfortunatly it is in the same branch
<thekorn> I'm very bad in seperating different things into different branches
<\sh> thekorn: I was wondering if we should switch to storm...
<thekorn> \sh, it is using storm
<\sh> thekorn: ah wonderful :)
<thekorn> so no more manual sql magic
 * \sh needs to change his new xmlrpc api stuff for work to use storm too...
<POX> \sh, thekorn: /me recommends SQLALchemy
<\sh> sqlalchemy?
<POX> as ORM
<POX> (you mentioned storm)
<POX> http://www.sqlalchemy.org/
<POX> someone just reported a python-sqlalchemy 0.5-1 sync request (I had to block him a little bit though ;-)
<stefanlsd> is there a better way of adding an m4_include([/usr/local/aclocal/pkg.m4]) to aclocal.m4.  thinking of some kind of abstraction...
<slytherin> does anyone know why we have 4 packages for libavcodec? 2 stripped and 2 unstripped.
<andresmujica> hi motu's!
<andresmujica> can anyone of you check bug #262853
<ubottu> Launchpad bug 262853 in ov51x-jpeg "ov51x-jpeg-source won't build against kernel 2.6.27, but 1.5.9 (already in Jaunty) would." [High,Confirmed] https://launchpad.net/bugs/262853
<andresmujica> pls
<andresmujica> thks in advance!
<cody-somerville> RainCT, pochu: ping
<stefanlsd> james_w, lool: got a fix up for imview. hope its ok. https://bugs.launchpad.net/bugs/306785
<ubottu> Ubuntu bug 306785 in imview "Please sync imview 1.1.9c-3 (universe) from Debian unstable (main)." [Wishlist,Confirmed]
<james_w> thanks stefanlsd
<pochu> cody-somerville: pong
<james_w> stefanlsd: looks pretty good. Does the detection of the lack of X libs still work do you know?
<james_w> stefanlsd: the disabling of imagemagick when there are no X libs I mean
<stefanlsd> james_w: let me confirm
<RainCT> cody-somerville: pong
<stefanlsd> heh. all the comments on DaD are gone...
<Adri2000> stefanlsd: oh?
<Adri2000> let me check
<stefanlsd> james_w: good call. doesnt really disable it if have_x=no. looking into it
<james_w> stefanlsd: you can probably just move the magick stuff in to an else block after the warning about it
<stefanlsd> james_w: nodnod
<Adri2000> stefanlsd: (I'll restore a backup in a moment, but trying to understand what happened first)
<stefanlsd> Adri2000: cool.
<Adri2000> comments on DaD are back
<stefanlsd> Adri2000: what was the problem?
<fabrice_sp> Hi. Is someone willing to review dvdstyler? It's at http://revu.ubuntuwire.com/details.py?package=dvdsty and already have an advocate
<fabrice_sp> http://revu.ubuntuwire.com/details.py?package=dvdstyler
<Adri2000> stefanlsd: dunno :) I just restored the backup from this morning
<stefanlsd> Adri2000: heh. at least ur backups work.
<quadrispro> emgent: ping
<quadrispro> sebner: ping
<Adri2000> stefanlsd: yeah fortunately. we did loose DaD comments in the past; that taught me to do proper backups :p
<lool> stefanlsd: Did you try it out with and without imagemagick, and with imagemagick and --with-magic=no?
<stefanlsd> lool: busy doing some more testing atm. james_w pointed out testing what happens when the xlibs arnt there. will test with and without imagemagick also
<lool> stefanlsd: I think you should expand the description of your changes; e.g. "Reworked ImageMagick detection to use pkg-config" and also the aclocal thingy
<stefanlsd> lool: kk. will do. thanks
<lool> stefanlsd: I would actually rather see a proper fix for aclocal than perpetuating the situation that it's borken and even relying on it  :-/
<lool> stefanlsd: For instance you could copy the interesting macros into m4/ or acinclude.m4
 * lool &
<stefanlsd> lool: kk. will look at using aclocal properly
<rhpot1991_laptop> cody-somerville: you around?
<cody-somerville> rhpot1991_laptop, yup
<rhpot1991_laptop> cody-somerville: I've updated bug 297019 like you asked
<ubottu> Launchpad bug 297019 in mythexport "mythexport relies on ffmpeg from medibuntu" [Undecided,Fix released] https://launchpad.net/bugs/297019
<cody-somerville> rhpot1991_laptop, It is a little hard to read. Can you make the field titles caps and put spaces between them
<cody-somerville> ie. Test Case: -> \nTEST CASE:
<cody-somerville> (\n being a line break)
<cody-somerville> rhpot1991_laptop, and please attach the debdiff to this bug
<RainCT> pochu: ping
<pochu> hey RainCT
<rhpot1991_laptop> cody-somerville: debddiff is there already, I'll edit to make it more readable
<rhpot1991_laptop> you want an extra space between each line then?
<stefanlsd> can someone unsubscribe u-u-s from bug #306785           - still a bit of work to do
<ubottu> Launchpad bug 306785 in imview "Please sync imview 1.1.9c-3 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/306785
<cody-somerville> rhpot1991_laptop, Right. I need to make it easy for other people to check to ensure that I did my job properly :)
<rhpot1991_laptop> cody-somerville: are those titles named ok, just caps them?
<cody-somerville> rhpot1991_laptop, yup
<rhpot1991_laptop> ok good
<rhpot1991_laptop> cody-somerville: how is that?
<slytherin> asac: do we still add abrowser alternative to the firefox depends/recommends?
<cody-somerville> rhpot1991_laptop, Okay, can you seperate each bug with a line of characters or something? ie. ===========================
<rhpot1991_laptop> cody-somerville: sure, done
<karooga> hi, my package doesn't have the necessary licences in the src tar.gz.  Upstream is no longer replying to emails.  What would be my next step to get the package included?
<huats> superm1: hey
<huats> sorry to bother
<huats> I just saw cody-somerville post, and since I am the one who did the gnome-keyring package I wanted to help if I can...
<huats> (cody told me to ping you...)
<anakron> ping thekorn
<thekorn> hello anakron
<anakron> hi all
<anakron> https://bugs.launchpad.net/ubuntu/+source/slingshot/+bug/315725
<ubottu> Ubuntu bug 315725 in slingshot "Menu launcher not created when Slingshot installed." [Undecided,New]
<anakron> i have some problems with this bug
<anakron> because when i download source code i can't find any make file or something like this
<anakron> it's just run it with python
<anakron> i wanna change a desktop file to add it right to menu
<anakron> but i dont know how i can test it
<jmarsden|work> anakron: debian/rules is a Makefile... if you put the .desktop file under /debian and make sure debian/rules installs it, you should be all set, right?
<anakron> its all in order
<anakron> but when i saw the main folder
<anakron> i saw debian/ README.TXT and slingshot/
<anakron> and readme tells that if you want to install it you must move to a folder
<anakron> ...
<anakron> so i can't test in that way if my .desktop file was ok
<anakron> now ill replace older slingshot.desktop file in my installation with ubuntu with the new one
<jmarsden|work> anakron: This is already packaged software... so installing it is done by dpkg, right?  So look at what the package does, and any maintainer scripts under debian/ ... you test by rebuilding the package (edit debiab/changelog of course) and then install your newly built package... just like any other package...?!
<superm1> huats, are you familiar with the upstream changes in the upload per chance?
<anakron> yes
<anakron> :)
<superm1> huats, spectacular :)
<anakron> nono
<anakron> i was answering jmarsden|work
<superm1> oh whoops, anakron looks nothing like huats, wonder how i read that wrong
<superm1> huats, so grab me when you are back
<huats> I am here
<huats> :)
<huats> not very present but here :)
<huats> superm1: so your question was regarding the upstream changes ?
<superm1> huats, yeah, are you familiar with them?
<huats> a bit
<jmarsden|work> anakron: So it sounds like you were reading a README that was for the original unpackaged sources, you can ignore info about how to install from such a README, it is obsoleted by the Debian/Ubuntu packaging.
<huats> but not enough to tell you why it is broken
<superm1> huats, well it appears that there is a process of GKD that is going defunct.  i'm not sure if it normally forks another process or how they get started
<anakron> ok thanks
<huats> (oups I did a wrong copy/paste there)
<anakron> jaja
<anakron> ok thanks
<jmarsden|work> no problem
<huats> superm1: I can't tell
<huats> the update has been quite problematic since the upstream has a lot of problem doing a clean release
<huats> the 2.25.4 was broken
<superm1> what do you mean by "clean"?
<superm1> oh similar types of problems then?
<huats> (I showed them the problem)
<huats> then they produced a .1 that also fails to build correctly
<huats> because of unfinished code in it
<superm1> ha wow.
<huats> and then upstream revert it without a new release
<huats> that is a patch I applied
<huats> well the release was messy :)
<huats> superm1: may be you should contact the upstream author
<huats> do you want is email address ?
<huats> he is responding overnigh usually
<huats> overnight
<superm1> huats, well i filed a bug, so as long as they are responsive to that, that should be sufficient
<huats> superm1: ok
<huats> tell me if I can do anything
<huats> (or send me an email I am not around...)
<superm1> huats, perhaps you can help with getting a debug trace for this.  i'm not sure how we can grab one since it's only the process on login it happens, and i think gkd isn't ptrace'able
<huats> ok I'll try to do that
<huats> I can't do it right now
<huats> but during the evening probably
<superm1> huats, sure.  you can grab the latest daily xubuntu or mythbuntu image from cdimages.ubuntu.com and boot it up in a virtual machine or real machine.
<huats> I'll connect my self then
<superm1> either of them will show it
<huats> sure
<huats> I'll do that
<huats> :)
<superm1> great thanks.
<huats> mail me if anything occurs
<huats> thanks
<huats> going to eat now
<huats> bye
<randomaction> Hello. I have a couple of packages (namely, wget and cvs) that are used by the "get-orig-source" target of debian/rules. Everything, however, builds from source without them (even in pbuilder). Should these packages be listed as build-dependencies?
<slytherin> randomaction: nope
<slytherin> randomaction: get-orig-source is not run on build server so no need to add those dependencies.
<randomaction> Thanks :)
<anakron> hi
<anakron> how i can get my private gpg if im other place
<stefanlsd> anakron: u need your private key with you
<anakron> mmmm interesting
<iulian> RainCT: I talk to dholbach this morning about the revu-uploaders team in Launchpad.  REVU uses OpenID now and I believe the team is no longer needed.  What do you think? Should we remove it?
<anakron> its relevant if i sign with a differente key?
<stefanlsd> anakron: depends what you are signing and for who. launchpad prob has your other key only.
<anakron> yes
<anakron> but i can upload it
<anakron> and then launchpad can recognize it
<stefanlsd> anakron: not sure if lp can do that, but i dont see why not. #launchpad will prob give u more info
<apw> hi there.  if the sponsorship process talks about how to present a fix for a package in terms of debdiff, if the fix is for a package which is lp bzr hosted there is no guidance as to what to do with your updated branch once it is ready
<jmarsden|work> apw: Good point, james_w would have a definitive answer... I'd suggest that you provide a link to your updated branch in the LP ticket, where you would nornmally upload the debdiff.
<Laney> apw: You can propose branches for merging
<apw> which of those would be the recommended way, link or propsing for merge?
<Laney> proposing it is the semantically correct way
<cody-somerville> rhpot1991_laptop, Looking at http://bazaar.launchpad.net/~mythbuntu/mythexport/trunk/revision/44 it seems that more than just a few dependencies being added occurs
<ScriptRipper> who can help me with some multitarget .deb packaging for combi debian and ubuntu source pkg?
<pochu> !ask
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<ScriptRipper> I was not sure if i am in the correct place, that why i asked to ask a question :)
<ScriptRipper> Build-Depends: debhelper (>= 5), quilt (>= 0.40), binutils (>= 2.16), .... lots of other pkgs ..., etherboot
<Laney> If you just ask then you either get an answer or get pointed to a better place to get an answer :)
<ScriptRipper> but only on debian. on ubuntu, i dont need etherboot dependency.
<ScriptRipper> in my debian control file.
<ScriptRipper> on debian i need to skip or something else.
<ScriptRipper> how do i do that?
<ScriptRipper> so it is a packaging question for the control file in a source pkg....
<RAOF> I can't think of a way.
<Laney> You can generate control in the clean target, but it's not very nice.
<RAOF> Laney: If you want people to go _mental_ looking at your package, I guess :)
<Laney> pkg-gnome does this for the uploaders field
<RAOF> Wow.
<ScriptRipper> is it general practise to have multitarget pkgs which "if" ed dependencies for .deb?
<directhex> ScriptRipper, iffed for what reasons?
<ScriptRipper> if debian do this, if ubuntu do that...
<Laney> ScriptRipper: What happens if the etherboot depd is left in?
<directhex> ScriptRipper, ah, right.
<Laney> dep*
<directhex> ScottK-desktop, best option is using a pipe in the deps - e.g. xulrunner (>= 1.9) | xulrunner-1.9
<directhex> bah
<directhex> ScriptRipper, ^^
<ScriptRipper> it tells me no etherboot pkg on ubuntu...
<directhex> ScriptRipper, second best bet is generating control (e.g. OOo does this)
<Laney> er, we have etherboot
<ScriptRipper> let me check why it tells me no etherboot then...
<Laney> do you have universe enabled in your pbuilder?
<directhex>         500 http://mirror.ox.ac.uk intrepid/universe Packages
 * Laney burns ox.ac.uk
<ScriptRipper> Laney: ah, i dont have.
<directhex> Laney, it's quite fast on my office machines
<ScriptRipper> i use main, not universe or multiverse...
<Laney> that'll do it
<ScriptRipper> is that uncommon to use main?
<directhex> main is one of four repos, with a specific content set
<Laney> I think you have to pass --components to pbuilder to get universe
<Laney> but don't quote me
<directhex> Laney, or set OTHERMIRROR?
<ScriptRipper> how is it organised? do the 3 others sit on top of main, or do the 3 sit on top of each other?
<Laney> right
<Laney> othermirror probably works
<ScriptRipper> with its pkg meta data?
<directhex> ScriptRipper, main contains Free software "properly" supported by canonical employees, with priority security support & extra special care taken for things like regressions etc
<directhex> ScriptRipper, universe is everything else that's Free - community supported things
<ScriptRipper> directhex: ah.
<ScriptRipper> and multiverse?
<directhex> restricted is canonical-supported, non-free. multiverse is community-supported non-free
<Laney> packages in main have to (build-)dep only on stuff in main
<ScriptRipper> does it sit on main or universe?
<ScriptRipper> or as i like it?
<ScriptRipper> e.g. any combination?
<Laney> You need main for restricted and universe for multiverse and main for universe
<directhex> main is required
<directhex> ehm... yes. /me hands Laney a bucket of commas
<Laney> haha
<Laney> I started typing that before I knew how it would end
<ScriptRipper> :)
<ScriptRipper> you were very helpful. looks like I need no if in the end :)
<ScriptRipper> I found also the construction "xulrunner (>= 1.9) | xulrunner-1.9" very interesting, because i can use that also from case to case...
<Laney> You know, if you could have got away without the build-dep on Ubuntu, is it really necessary?
<ScriptRipper> Laney: it is not, you told me...
<Laney> ScriptRipper: But you thought you could do without it
<ScriptRipper> sorry, yes, *i dont need an if*
<ScriptRipper> try to find out now why pkg contains etherboot dependency at all...
<Laney> I was just questioning your thinking
<ScriptRipper> do you know if qemu is in main under ubuntu?
<Laney> apt-cache show qemu | grep Section
<ScriptRipper> sees now lots of his packages in universe...
<Laney> hmm?
<ScriptRipper> me
<vorian> !info qemu
<ubottu> qemu (source: qemu): fast processor emulator. In component universe, is optional. Version 0.9.1-5ubuntu3 (intrepid), package size 10049 kB, installed size 29096 kB (Only available for amd64 i386 powerpc alpha sparc arm armeb armel s390 kfreebsd-i386 kfreebsd-amd64 lpia)
<ScriptRipper> i see lots of the packages needed in universe...
<ScriptRipper> i package developer snapshots of qemu from svn.
<ScriptRipper> until now, only debian worked
<ScriptRipper> from now on, ubuntu and debian :)
<SilverBullet> hello
<SilverBullet> Guys, just to let u know of tje GetDeb Founder JoÃ£o Pinto Interviewed => http://translate.google.com/translate?prev=&hl=pt-PT&u=http%3A%2F%2Fwww.pplware.com%2F2009%2F01%2F12%2Fentrevista-a-joao-pinto-getdeb%2F&sl=pt&tl=en
<ScriptRipper> is it common practise to build a package by default against main or universe?
<SilverBullet> sorry about the google translation, but i think it can be understanded
<RAOF> ScriptRipper: It depends on the package; the heirachy is basically main -> universe -> multiverse.  In the archives, a package may only build against its own component or higher (so, Universe builds against main+universe, but main only builds against main).
<RAOF> ScriptRipper: For 3rd party packages, build against whatever you like.  You'll almost certainly want to be building against universe, though.
<ScriptRipper> sorry, i missed maybe some part.
<ScriptRipper> do universe pkgs get security fixes?
<jdstrand> ScriptRipper: yes, from the community
<ScriptRipper> not matter, the ubuntu delivered qemu is in universe. so my qemu-svn needs also to build against universe for the same reason...
<ScriptRipper> same build requirements for the pkgs...
<ScriptRipper> so ill do that.
<ScriptRipper> and have to
<SilverBullet> http://ubuntuforums.org/showthread.php?t=1038224
<james_w> POX: scapy dropped the scapy binary package, when we would still need it for transitions in Ubuntu. Could we get it back in Debian, or shall we maintain a small diff for that?
<james_w> is there a Debian equivalent of the NBS report?
#ubuntu-motu 2009-01-13
<SilverBullet> Getdeb Founder interviewed Topic => http://ubuntuforums.org/showthread.php?t=1038224
<anakron> hi
<anakron> someone know why if i type this
<anakron> sudo debdiff slingshot_0.8.1p-1.dsc slingshot_0.8.1p-1ubuntu1.dsc > slingshot_0.8.1p-1ubuntu1.debdiff
<anakron> it doesn't work
<Hobbsee> well, you don't need to sudo it, for a start
<anakron> yes
<anakron> but says
<anakron> bash: slingshot_0.8.1-ubuntu1.debdiff: Permiso denegado
<anakron> and i can't understand
<anakron> must be my error, but i can't see i
<anakron> it
<Hobbsee> then chown it to your user?
<anakron> ops
<anakron> hehe
<anakron> dont worry :)
<anakron> i do it like root
<anakron> but it was chown error
<RAOF> So!  Who wants to review nouveau-kernel-source!  Simple, fun, and makes a very nice open-source nvidia driver installable in Jaunty! http://revu.ubuntuwire.com/details.py?package=nouveau-kernel-source
<directhex> RAOF, is it dkms based?
<RAOF> Yes.
<RAOF> Which is mich easier than the wiki page suggests, it turns out.
<RAOF> directhex: If you haven't seen a dkms-using package before, I'd suggest checking it out.  It's a good example, I think.
 * Hobbsee clubs RAOF with a dead ferret
<RAOF> Hobbsee: Sadness.
<RAOF> Ferrets are awesome.  They shouldn't be dead.
 * RAOF tickles his ferret.
<Hobbsee> RAOF: gnome-do keeps flipping back to open for the ssh.  Fix it, and I won't kill the ferrets and club you with them ;)
<Hobbsee> i didn't know you had a ferret.  I'd like to see this!
 * directhex feeds RAOF's ferret some cat food
<StevenK> Hobbsee: You mean my bug?
 * RAOF doesn't _actually_ have a ferret.
<Hobbsee> StevenK: yeah.  But now i'm actually being able to reproduce it
<StevenK> Woot
 * RAOF files "SSH Hosts shouldn't be openable" against do-plugins, and does some bug gardening there, too.
<StevenK> Yay RAOF!
<Hobbsee> well, they should be openable.  just, they should never be the default ;)
<RAOF> But nothing _happens_ on open, right?
 * Hobbsee finds it useful to have a GUI for browsing remote machines, sometimes.
<Hobbsee> no, it opens / on the destination machine.
<Hobbsee> in nautilus.  Works a charm when you actually want it to do that.
<RAOF> Oh, sweet.  That's broken here, sadly.
<Hobbsee> or at least, did last time i tried it
<RAOF> Yeah, that's what it's _trying_ to do.
<RAOF> We may need to give it some gvfs love to make it work better, but that's what it's trying.
<RAOF> The relevance engine is next up on getting an overhaul.  That should make this better.
 * RAOF hopes he missed someone volunteer to review nouveau ;)
<ScriptRipper> the qemu pkg dependencies is now ok with universe
<ScriptRipper> now i run into a new issue: dpkg-source: error: unrecognized file for a v1.0 source package: qemu_0.9.2svn6277.orig.tar.bz2
<ScriptRipper> are .tar.bz2 not allowed anymore?
<ScriptRipper> debian etch eats it!
<RAOF> Really?  I thought that was reasonably recently introduced in dpkg.
<ScriptRipper> debian etch works, but lenny not.
<ScriptRipper> that is the strange thing
<directhex> hmm, no.
<directhex> bz2 is supported in dpkg, but not by the archive stuff
<directhex> so you can create a local bz2 package, but not upload it
<ScriptRipper> so i run into a new consistency check not present in etch?
<directhex> quite possible
<ScriptRipper> not upload it to the debian build system or the ubuntu build system?
<ScriptRipper> so i should go back to .tar.gz then?
<ScriptRipper> source files...?
<RAOF> Yeah; repack it to a tar.gz
 * ScottK does a cruft cleaning victory dance.  5 removal bugs done of his today.
<ScottK> Thanks slangasek
<nhandler> Congrats ScottK
<pwnguin> RAOF: how much time / skill would I need to review nouveau stuff?
<RAOF> pwnguin: Time?  Dunno; depends on how fast you are at copyright sweeps.  Probably a couple of hours.  It's not very complicated packaging.
<pwnguin> i guess the other thing is, im not motu
<RAOF> That is, of course, awkward.  You're welcome to give it a once over; if you find anything I can fix it before someone who could advocate it needs to look at it.
<Hobbsee> RAOF: how much crack is it on?  is it a new package, or waht?
<lifeless> persia: do you know where a schedule of the asia board meetings is?
<lifeless> persia: I keep misssing them cause announcements are sent after I finish work, and I don't read email in the evenings generally
<persia> lifeless, I only know of the one in my head, which goes 15:00 today, 9:00 on the 20th, 15:00 on the 27th, etc.
<RAOF> Hobbsee: It's a new package.  It's not really on any crack at all.
<lifeless> UTC?
<persia> lifeless, I don't know how far in advance amachu has posted to the fridge.
<persia> Yes, UTC.
<RAOF> Hobbsee: Packaging-wise, at least.  It's quite simple.
<lifeless> ok, well I won't be at todays
<lifeless> thats 2am
<persia> No, don't imagine anyone from the east will be there.
<RAOF> Hobbsee: It's also fairly safe; it shouldn't break anything for anyone.
<lifeless> I'd like a ical feed for these
<Hobbsee> hrm...
<lifeless> could you bring that up please
<lifeless> persia: ^
<persia> An iCal feed?
 * persia knows almost nothing about iCal
 * nhandler still wishes the fridge would make their ical feed work with gcal
<persia> nhandler, It's an issue with the drupal plugin.  Feel free to chase the bug :)
<nhandler> persia: I know it is. I don't have enough experience with drupal or ical to tackle this one.
<Hobbsee> RAOF: will there be gnome-do fixes if it gets reviewed?  :P
<lifeless> nhandler: yeah, gcal is what I need
<RAOF> Hobbsee: There'll likely be a new gnome-do release if it gets reviewed, with plenty of shiny?
<Hobbsee> will it fix the ssh connect issues?
<Hobbsee> and how likely?  :P
<RAOF> Probably not; that's related to something deep in the core.
<Hobbsee> awww
<RAOF> We can't really pin something to the top of the priority for a specific item at the moment.
<Hobbsee> ah
<RAOF> Improvements to the relevance, including per-element relevance (so the fact that you use "open" a lot on files doesn't affect your ssh hosts), are coming after the next release.
<Hobbsee> woot!
<Hobbsee> hand me a URL then, and i'll attack you with a rubber chicken if the copyrighting is wrong ;)
<RAOF> http://revu.ubuntuwire.com/details.py?package=nouveau-kernel-source
 * Hobbsee blinks
<RAOF> That bad?
<Hobbsee> i just looked at the legal page
<RAOF> I think I've got them all covered, but yeah.
<RAOF> Damn.  I should have just stolen the copyright from the kernel!  That's where all those files normally end up!
 * Hobbsee wonders why debian/install is needed
<Hobbsee> oh, you don't dump them all in the same place.
<Hobbsee> RAOF: presuambly one needs to update the debian/snapshot_hash when updating the package?
<RAOF> Hobbsee: I thought I set up a target to refresh that.
<RAOF> Let me check.  It's been sitting there a while :)
<RAOF> Hobbsee: The get-new-snapshot target generates snapshot_hash
<Hobbsee> oh, so you do
<RAOF> Wow.  That's quite a lot less trivial than I remember ;)
<Hobbsee> RAOF: I didn't check copyright, and I didn't try building it, but I can't find anything wrong with it.
<RAOF> I'm reasonably certain copyright is OK.  Older versions of many of the files in there are in the kernel tree already, and the rest have clearcut copyright.
<RAOF> Want to upload or ack it, then? :)
<Hobbsee> RAOF: i'm assuming the answer is "no", but this doesn't require internet access while building the binaries, does it?
<lifeless> anyone know if dh_zope adds python to the dependencies itself?
<RAOF> No, it doesn't.
<RAOF> Hobbsee: ^
<Hobbsee> oh good
<lifeless> does it need to ? as python is implied by zope..
<RAOF> lifeless: Do packages which call dh_zope also call dh_python?
<lifeless> no
<RAOF> Should they?
<lifeless> I think it may 'depend' :P
<RAOF> Another query: where is dh_zope, exactly?
<RAOF> apt-file search dh_zope comes up empty.
<RAOF> Or are you writing a dh_zope yourself?
<RAOF> Hobbsee: BTW, it should be safe for you to build and install the package.
<Hobbsee> RAOF: that's what i'm tryingnow
<RAOF> Worst case: it kills your 3d :)
<Hobbsee> RAOF: found some interesting bits in the build log
<RAOF> Oh?  Pastebin?
<Hobbsee> dpkg-source: info: building nouveau-kernel-source in nouveau-kernel-source_0.0.11+git20081220-0ubuntu1.dsc
<Hobbsee>  debian/rules build
<Hobbsee> tail: cannot open `/usr/bin//changelog' for reading: No such file or directory
<Hobbsee> dpkg-parsechangelog: failure: tail of /usr/bin//changelog gave error exit status 1
<Hobbsee> the last 2 lines repeated another 6 times
<RAOF> Ah, right.
<RAOF> It's trying to evaluate CURVER.  I don't know why.
<Hobbsee> warning, `debian/nouveau-kernel-source/DEBIAN/control' contains user-defined field `Original-Maintainer' is a little odd too, as i can't see why
<RAOF> Hobbsee: Because it's got me as the original-maintainer?
<RAOF> I probably shouldn't be there.
<Hobbsee> RAOF: well, i'm not sure why it's cut off the XSBC- part
<RAOF> Because it's in the binary already?
<Hobbsee> ah, fair enough
<Hobbsee> W: nouveau-kernel-source: script-not-executable ./usr/src/nouveau-0.0.11+git20081220/scripts/create_bsd_pci_lists.sh
<Hobbsee> W: nouveau-kernel-source: script-not-executable ./usr/src/nouveau-0.0.11+git20081220/scripts/create_linux_pci_lists.sh
<Hobbsee> W: nouveau-kernel-source: old-fsf-address-in-copyright-file
<Hobbsee> fwiw
<RAOF> Hm.  I wonder why those scripts don't come executable from git.
<Hobbsee> RAOF: it seems the other two in that directory did - just not those.
<RAOF> Yeah. I can fix that in get-orig-source if you think its worth it.
<Hobbsee> meh
<Hobbsee> RAOF: advocated.
<RAOF> Hobbsee: Sweet!  I'll upload now.  Nouveau can be installable for Alpha 3!
<Hobbsee> :)
<Hobbsee> that's if it gets thru the new queue
<RAOF> Well, yeah.  I guess so.
<RAOF> Hobbsee: And uploaded.  Thanks muchly!
<Hobbsee> RAOF: you're welcome
<fabrice_sp> Hi. I'm upgrading a package to a new upstream version, and of the 2 patches that the package had is not used anymore. Should I remove the patch from the debian/patch or just delete from the series file?
<fabrice_sp> "and ONE of the 2 patches"
<RAOF> To push the bzr tree for that packaging I first need to create the launchpad project, don't I?  Has that changed with packagebranches yet?
<persia> RAOF, You might want to ask james_w that, in several hours :)
<stochastic> Hi room, I've just made my first debdiff to patch this bug: https://bugs.launchpad.net/ubuntu/+source/jack-rack/+bug/211798 How do I go about getting it off my computer and into the stream?
<ubottu> Ubuntu bug 211798 in jack-rack "jack-rack open file hangs" [Undecided,Confirmed]
<stochastic> should I first post it to the bug as an attachment? or is there a review process?
<jmarsden> stochastic: If you have tested it and it works well for you, post it to the bug as an attachment.
<stochastic> jmarsden, okay it's uploaded, is that all I need to do?
<persia> stochastic, Once the patch is uploaded, subscribe ubuntu-universe-sponsors to the bug.
<stochastic> okay, will do
<didrocks> morning o/
<RAOF> james_w: ping, re: where to push bzr packaging to in these sourcepackage-branch laden days.
<POX> james_w: well, adding it in Debian will need NEW again, so I guess it will be easier to add small diff in Ubuntu
<porthose> james_w: added the additional info you needed to bug #316092, thx
<ubottu> Launchpad bug 316092 in ampache-themes "New Ampache themes" [Undecided,New] https://launchpad.net/bugs/316092
<_ruben> is there a way to override the installation of packages listed in Recommends: ?
<liw> _ruben, yes, apt-get has an option to either disable it by default (if you put it in a config file) or per use (if you use the -o option); I forget what the option is called, though
<RAOF> _ruben: In aptitude? Certainly.  List the package with a minus next to it (sudo aptitude full-upgrade idontwantyou-)
 * _ruben reads the manual one more time
<_ruben> using apt-get
<_ruben> --no-install-recommends .. doh .. wonder how i could miss that :p
<directhex> --without-recommends ?
<dholbach> good morning
<slytherin> asac: I have a question regarding tuxguitar merge. tuxguitar launcher script looks for libxpcom.so (needed for documentation browser) in /usr/lib/xulrunner-1.9. But the installation of xulrunner on ubuntu is done in /usr/lib/xulrunner-1.9.0.x. How do I solve the problem of libxpcom.so lookup?
<slytherin> dholbach: good morning.
<dholbach> hiya slytherin
<stochastic> hi room, I'm in the process of stepping through packaging tutorials in an attempt to build a .deb for the calf plugin pack here: http://calf.sourceforge.net/ and I'm wondering if someone can walk me through the depends and build-depends sections of the control file
<liw> stochastic, what you want to know about them?
<stochastic> I'm not sure on what the difference between build-depends and depends fileds
<directhex> stochastic, erm... do you need gcc to run nano?
<stochastic> okay, should I just guess at the libraries required to run these plugins?
<stochastic> or are there systematic means of figuring it out?
<liw> stochastic, depends is for what the package needs when a user uses it; build-depends is what you need when you build it
<directhex> stochastic, generally, you should use substitution variables and a sufficiently smart packaging helper tool for them to be calculated
<liw> stochastic, shared libraries are usually determined automatically (rare exceptions exist); other stuff you mostly have to figure out by reading the source code
<stochastic> directhex, sorry I'm BRAND new to this packaging thing
<liw> stochastic, or by experimenting
<directhex> ${shlibs:Depends} is a good thing to depend on
<directhex> it's populated by something, probably dh_makeshlibs in debian.rules
<StevenK> dh_shlibdeps
<StevenK> dh_makeshlibs is for libraries to *make* them
<stochastic> okay, so I only need to take the dependencies listed here: http://calf.sourceforge.net/?id=2 and find suitable packages in Ubuntu's repos and put those into build-deps
<directhex> yeah, close enough
<directhex> if your packaging helper is smart enough, you shouldn't even need to care about which dh_foo to run
<StevenK> stochastic: Just make sure you put the development libraries in the build-deps.
<StevenK> debhelper 7 for the win
<directhex> StevenK, yes!
<stochastic> now when it says it requires Expat XML parser, should I include the dev libraries, or the expat executable?
<directhex> it's even mono-friendly, and does ${cli:Depends}
<StevenK> stochastic: The development libraries, since things usually link against it
<stochastic> I'm learning off the youtube videos by dholbach, but they kinda gloss over this section
<slytherin> stochastic: when you are need a library for building your program, you usually need -dev package of that library since that is where all the header files lie.
<stochastic> hi again, I'm having further difficulties with build-depends in that same package when it comes to pbuilder
<stochastic> I get a whole bunch of <package name> is a virtual package errors and it fails to build
<stochastic> like ladspa-sdk and dssi-dev and libjack-dev
<stochastic> am I missing something obvious, or am I using the wrong packages?
<james_w> stochastic: I believe you don't have universe enabled in your pbuilder
<stochastic> ok, that makes sense
<stochastic> how do I fix that?
<james_w> RAOF: there's not a special place on launchpad yet, so either under the project, or under your +junk
<RAOF> james_w: OK. Which means creating the project, I guess.
<james_w> stochastic: I believe the fix is to edit your ~/.pbuilderrc and then run "pbuilder update --override-config"
<james_w> stochastic: I've never had to do it though, so that might be nonsense
<james_w> RAOF: yeah, you could use your +junk, but creating the project can be useful for other things, such as bug watches
<RAOF> Yeah.
<stochastic> james_w, I don't have a ~/.pbuilderrc
<james_w> stochastic: https://wiki.ubuntu.com/PbuilderHowto#Universe%20support
<dholbach> james_w: we shouldn't be doing sponsoring at the same time :)
<dholbach> mid-air collision on bug 316536
<ubottu> Launchpad bug 316536 in nted "Please sync nted (1.4.17-1) from debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/316536
<james_w> :-)
<dholbach> although you were quicker :)
<james_w> at least we agreed :-)
<dholbach> yeah
<james_w> I'm on gpsd and ampache-themes now
<dholbach> netkit-telnet
<james_w> pff, main :-)
<dholbach> hehe, right
 * dholbach does metacity next
<Laney> you should set them to in progress when reviewing!
<james_w> on goocanvasmm now
<james_w> Laney: you can still have issues even then, but yeah it would help a bit
<james_w> on azureus
<stochastic> hmm, still on with this package I'm trying to build, it didn't seem to generate any dependencies; my debian/control file had: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}, ${misc:Depends}
<liw> stochastic, you're probably missing something earlier in your debian/rules file; can you post it to paste.ubuntu.com?
<stochastic> here it is: http://paste.ubuntu.com/104333/
<stochastic> just what was automatically generated
<liw> stochastic, I think you want to uncomment the line that calls dh_makeshlibs
<stochastic> I'll try that, anything else?
<liw> not immediately
<stochastic> liw, I still get the same issue
<liw> stochastic, hmm
<liw> stochastic, can you put the entire source package up somewhere so that I can play with it to see what the problem is?
<james_w> stochastic: turning on DH_VERBOSE may give some clues
<stochastic> what would you like, any of my packaging work, or just the source of the application?
<james_w> stochastic: dh_shlibdeps is the call that should add ${shlibs:Depends}
<stochastic> james_w, should I just put the dh_verbose on line 75?
<james_w> stochastic: nope, at the top of the file is a commented-out call to "export DH_VERBOSE=1" if you uncomment that the dh will tell you more about what it is doing
<james_w> the trace may be informative about why that variable isn't getting set
<stochastic> here's the entire output of pbuilder with verbose on: http://paste.ubuntu.com/104339/
<stochastic> I don't see anything obviously tracing that error
<stochastic> the error is way down at the bottom
<james_w> stochastic: the issue is that the install rule doesn't actually install the program
<james_w> it install the header files, and a few other things, but doesn't appear to install calfmakerdf etc.
<stochastic> oh
<james_w> at least I assume that is what is supposed to happen
<stochastic> liw, I've tarred the whole kit and kaboodle up and it's here to download if anyone wants to fiddle: http://rapidshare.com/files/182751716/calf-packageAttempt.tar.gz.html
<stochastic> it does look like the calfmakerdf is moved at lines 1128, 1132, etc.. and besides these are audio plugins so they're not really designed as an executable standalone
<liw> stochastic, I'll have a look
<stochastic> well thank you all for the insights that have gotten it this far, unfortunately I do need sleep
<stochastic> liw, if you find something I'm missing, or any explanation please e-mail me (e-mail is in the packaging) as I'd love to know where I took a misstep
<liw> stochastic, sure
<slytherin> stochastic: dh_makeshlibs is not the command you should use, rather dh_shlibdeps
<directhex> the usefulness of quilt suddenly becomes apparent, when looking at an rpm spec file with 54 patches in it
<liw> hmm, stochastic's package doesnt end up with a substvars file
<liw> which seems to be because he installs into debian/calf rather than debian/calf-plugins
<liw> fixing that, there's still a complaing about misc:Depends
<liw> but that seesm to be fixed in newer debhelpers so that's ok
<thekorn> jpds: hi, FYI, I just added a tool to create credentials for the launchpad API to lp:~thekorn/ubuntu-dev-tools/use_launchpadlib
<directhex> hm, looks like my new ikvm packaging did the trick - i can't imagine the old package would have been able to gobble a gig of ram on the armel buildd during compile
<Laney> you da bomb
<mok0> doko: ping
<quadrispro> dholbach: ping
<dholbach> quadrispro: pong
<doko> mok0: contentless pong
<mok0> doko: oh, just going through my bug list, and bumped into bug 308194
<ubottu> Launchpad bug 308194 in lxml "[intrepid] Exception importing etree module" [Undecided,Confirmed] https://launchpad.net/bugs/308194
<mok0> doko: I will make a patch for intrepid, ok?
<doko> mok0: sure
<mok0> doko, did you remove cython building from lxml?
<apw> if universe sponsors hang about over here, where to main sponsors hang out?
<mok0> apw: in -devel
<doko> mok0: yes
<apw> mok0, thanks :)
<mok0> doko: OK. It was my impression that you didn't like that
<ScottK-desktop> apw: It depends a bit.  You can also find people in #ubuntu-server, #ubuntu-desktop, and #kubuntu-devel depending on the package.
<apw> pm-utils and apport
<apw> so i'll try -devel
<doko> mok0: did I say that? hmm
<ScottK> apw: I doubt anyone other than pitti is going to touch apport unless it's an emergency.
<mok0> doko: you said something like "if lxml can't be built from source it should leave Debian"
<apw> yeah, think he is away from keyboard this week
<ScottK-desktop> Someone who knows a bit of Python and is looking for a bug to fix, might want to look at Bug #316674
<ubottu> Launchpad bug 316674 in catfish "catfish can't find on path containing whitespace" [Medium,Triaged] https://launchpad.net/bugs/316674
<POX> ^^ I can check/sponsor this one thru PAPT
<POX> i.e. upload it as PAPT member
<mok0> ScottK, why not subscribe the pythonistas team to the bug?
<ScottK> mok0: They are.
<ScottK> That's why I saw it.
<mok0> ScottK, it's not on their bug page
<ScottK> mok0: If a team is subscribed to a package, that doesn't mean all package bugs show up on the team bug list.
<mok0> ScottKnot they are
<ScottK> All members of the team got bugmail on it.
<mok0> ScottK, sorry: now they are
<ScottK> Oh.
<mok0> ScottK, the team was in the "Notified" column
<mok0> ScottK, when I subscribed them, they moved to the "Subscribed" column
<ScottK> Ah.
 * mok0 contemplates to join Ubuntu Pythonistas
<mok0> ScottK, hey you are in it :-)
<ScottK> mok0: I can even approve your request to join.
<mok0> ScottK, heh
<pochu> mok0: no need to subscribe the team if they are notified, fwiw
<mok0> pochu: notifcation is via mail, yes?
<pochu> right
<pochu> as subscribed is
<savvas> I've sent a mail to contact at twotoasts punkt de about the catfish bug :)
<mok0> pochu: I tend to forget about mails
<mok0> pochu: but I often check the buglist
<pochu> you can check the packages one team/person is subscribed to
<mok0> pochu, go on...
<pochu> e.g. https://bugs.edge.launchpad.net/~pythonistas/+packagebugs
<pochu> if you go to the bugs tab in launchpad, then click on "Show package report", you will get that
<savvas> hm.. there's a new upstream version, 0.3.2 for catfish
<pochu> which are all the packages the team/person is in "also notified"
<savvas>  + fix search from folders with spaces breaking find
<savvas> ScottK: http://www.twotoasts.de/media/catfish/ChangeLog - this is probably fixed in 0.3.1
<mok0> pochu: LP is a never-ending source of amazement...
<pochu> hehe
<mok0> pochu: ok, I wont subscribe anymore bugs to pythonistas
<ScottK> mok0: amazement/pain, but yes.
<RainCT> heh
<ScottK> savvas: Any interest in packaging the new version?
<ScottK> savvas: POX said he would sponsor it for Debian and we can sync it from there.
<RainCT> ScottK: I've joined the team, can you approve me?
<savvas> ScottK: I'll try to package the new version :)
<RainCT> (well, or just do that once you check your mail and see the new member notification.. I've no hurry :))
<ScottK> savvas: Great.  You might also want to join #debian-python on IFTC.
<ScottK> RainCT: Sure thing.  Will do.
<savvas> I'm still learning, but I think it's easy for this package
<ScottK> savvas: OK.  If you have questions, you can ask me here or on #debian-python
<ScottK> Any motu-sru around?
<cody-somerville> I am
<ScottK> cody-somerville: Would you please ack the ebox SRU?
<cody-somerville> bug #?
<ScottK> Bug 273486
<ubottu> Launchpad bug 273486 in ebox "Current eBox packages in intrepid don't work at all" [Undecided,New] https://launchpad.net/bugs/273486
<ScottK> bug 314606
<ubottu> Launchpad bug 314606 in ebox "ebox and libebox don't support Intrepid gconf version" [Undecided,New] https://launchpad.net/bugs/314606
<ScottK> Bug 255368
<ubottu> Launchpad bug 255368 in ebox "ebox: Depends: libapache-authcookie-perl but it is not installable " [Undecided,Confirmed] https://launchpad.net/bugs/255368
<RainCT> nixternal: yes, Brainstorm is finally being updated today (actually, it looks like it already has been), but it doesn't look like that thing in Jono's post :P
<sll> hello! could anybody help me to package a set of objects please?
<jpds> thekorn: re: lplib - that's brilliant, I'll start merging it as soon as I can.
<sll> It's my firs time packaging, the objects are like plugins written in C, I need some help with rules file
<hyperair> nhandler: codelite's ready for reviewing again
<shankhs> hi
<cody-somerville> ScottK, sommer: https://bugs.edge.launchpad.net/ubuntu/+source/ebox/+bug/273486
<ubottu> Ubuntu bug 273486 in ebox "Current eBox packages in intrepid don't work at all" [Undecided,New]
<shankhs> hi guys I know c/c++ and want to start developing some small softwares , but I dont know how to???Can anybody give me a starting point...please
<sommer> cody-somerville: yep
<cody-somerville> sommer, I made some comments on your SRU application.
<sommer> cody-somerville: thanks, I'll address those items
<nixternal> RainCT: argh, I was hoping I was correct ;)
<RainCT> nixternal: if you have some other theory, I'll listen ;P
<mok0> vorian: I looked at the patches; only one is still relevant. I might as well make the last change and upload
<mok0> vorian: (in stellarium)
<cody-somerville> sommer, Also commented on bug #255368
<ubottu> Launchpad bug 255368 in ebox "ebox: Depends: libapache-authcookie-perl but it is not installable " [Undecided,Confirmed] https://launchpad.net/bugs/255368
<vorian> mok0: are you going to upload it then?
<mok0> vorian: yeah why not. It is already in the archive
<vorian> if so, the stellarium.desktop could use a patch as well
<mok0> vorian: OK will take a look
<vorian> awesomeness
<mok0> vorian: It runs great on my intrepid amd 64!!!
<cody-somerville> sommer, I just commented on #314606 now too
<vorian> coolio
<mok0> vorian: Very nice work they did to the interface!
<vorian> i'll have to play with it when the dust from kde updates settles down
<mok0> vorian: uh-uh, I haven't dared take those on
<vorian> :)
<mok0> vorian: still at 4.1
<vorian> its a spiritual experience
<vorian> mok0: 4.1.4 should be hitting any time now if you use -proposed
<sommer> cody-somerville: thanks, should have updates to those sometime this afternoon or evening
<mok0> vorian: tell me about it. I just had a spiritual experience when my sys disk crashed yesterday
<vorian> ouch!
<cody-somerville> sommer, thanks
<mok0> vorian: fortunately my home is on a separate disk ;-)
<mok0> vorian: ... with backup
<vorian> nice, not too big a deal then. other than hardware loss
<vorian> :)
<mok0> vorian: yes. This time, I bought a Server Edition disk
<Turl> hello
<Turl> any possibility of you fixing Bug #285417? or is this package on main?
<ubottu> Launchpad bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed] https://launchpad.net/bugs/285417
<vorian> hehe
<mok0> Turl, if you click on the "ubuntulooks (Ubuntu)" link on the taskbar, and then select the "Overview" tab, you'll see that it's in main
<Turl> oh, sorry then
<Turl> is there any channel I can go to bug the main packagers? :p
<mok0> Turl: is this a matter of changing a directory name?
<mok0> Turl: core developers generally hang out in #ubuntu-devel
<mok0> Turl, why didn't that elli222 fellow upload a patch?
<Turl> mok0: it's changing the dependencies not to delete ubuntu-theme if I'm right, the bug has an explanation on how to repackage it to work correctly
<Turl> mok0: no idea :p maybe he doesn't know how?
<mok0> Turl: it's faster to make a patch than writing that long explanation :-)
<Turl> I believe so :p
<mok0> Turl, If you wanna fix it, we can guide you along here
<Turl> really it's for a friend, I don't want to install that theme :p
<mok0> Turl: you wanna fix it? :-)
<Turl> will I need to install tons of packages? :p
<mok0> Turl: I don't think so
<mok0> Turl: perhaps some devel tools
<mok0> Turl: but you'll need those the NEXT time you fix a bug lol
<Turl> ok, guide me then :=
<Turl> :)*
<mok0> Turl: first you need to go into a working dir and download the source package
<Turl> any empty dir is ok, am I right?
<mok0> Turl: yes
<mok0> turl, what version do you want to make the fix. Intrepid?
<Turl> yep
<mok0> Turl: do you know how to get the source package?
<Turl> apt-get source I guess?
<mok0> Turl: yes, if you're on the same version of Ubuntu
<Turl> yeah
<Turl> I got a diff.gz, a .dsc, a tar.gz and a dir
<mok0> Turl: now unpack using dpkg-source -x <.dsc file>
<Turl> ok, done
<Turl> now what mok0?
<mok0> Turl: go down into the topdir
<Turl> ok
<mok0> Turl: what's that called, btw
<Turl> ubuntulooks-0.9.12
<mok0> Turl: ok. Now go into debian/
<Turl> ok
<mok0> Turl: as I understand the bug, you need to edit the dependencies?
<mok0> Turl: then you need to edit "control"
<Turl> with nano is ok?
<Turl> or do I need to use some dpkg tool?
<mok0> Turl: yes
<mok0> Turl:  not yet
<mok0> Turl, remove the line containing "Replaces: ... "
<Turl> ready
<Turl> now what?
<mok0> Turl: do you know anything about ubuntu artwork? Because I don't
<Turl> I now there are pretty ones and ugly ones :p
<mok0> Turl: now you need to edit "changelog" and write a new entry at the top
<Turl> I copy one and edit it?
<mok0> Turl: yes, you can make a copy of the first entry and change it
<mok0> Turl, you need to use a new revision string
<Turl> ubuntulooks (0.9.12-13) intrepid-proposed; urgency=low
<mok0> yes
<Turl> would that be ok? it said hardy-proposed on the other one
<mok0> Turl: that will propose it as a fix for intrepid
<savvas> ScottK: I think I've finished with catfish: http://revu.ubuntuwire.com/details.py?package=catfish https://launchpad.net/~medigeek/+archive/+build/836369
<mok0> Turl: if you want to fix for hardy, you need to do the same for the hardy version of the package
<mok0> Turl: when you're done, cd ..
<savvas> ScottK: I'm going to see if it actually works now with folders with spaces :)
<mok0> Turl: then do "debuild -S -uc -us"
<Turl> where can I get debuild?
<savvas> Turl: sudo apt-get install devscripts
<mok0> heh
<ScottK> savvas: Since we are going to get POX to upload this to Debian, you want the revision to be -1 and the distro to be unstable
<POX> ScottK, savvas: acually, new upstream release of catfish is already in PAPT svn, Kmos: why didn't I upload it yet? (/me is too lazy to dig in his mails)
<ScottK> Ah.
<savvas> meh
<ScottK> savvas: Might be good of you to review what's in the svn and see if you have anything of significance that's different.
<Turl> mok0: installing, might take some timeÃ§
<mok0> Turl: ok
<Turl> it installed exim :/
<Turl> mok0: it threw a lot of errors :S
<savvas> POX: the changelog in svn shows 0.3.1 - http://svn.debian.org/wsvn/python-apps/packages/catfish/trunk/debian/changelog?op=file&rev=1943&sc=1
<mok0> Turl: the debuild command?
<Turl> a lot of "file or directory does not exist"
<Turl> yeah
<mok0> Turl: can you pastebin the output?
<ScottK> Something needs to be changed to depend/recommend postfix|mail-transport-agent instead of exim|mail-transport-agent
<Turl> like /usr/share/cdbs/1/class/autotools.mk does not exist, /usr/share/cdbs/1/rules/debhelper.mk does not exist, ..
<Turl> mok0: it's in spanish, idk if you want it all the same
<POX> cody-somerville: you're catfish maintainer, why it's not uploaded yet?
<savvas> ScottK: it's been good for training hehe :) They've pretty much changed the same things I have, so that's good!
<ScottK> yes.
<mok0> Turl: yikes. Try anyways
<POX> cody-somerville: http://people.debian.org/~piotr/sponsor Q9 (if that's the reason)
<ScottK> savvas: You can also request a sync after it's uploaded to Debian.
<cody-somerville> POX, I'm simply too busy atm
<POX> oh, ok
<POX> I'll upload it as PAPT member then
<Turl> mok0: http://paste.pocoo.org/show/99473/
<POX> (after some basic tests)
 * mok0 looks
<mok0> turl, sudo apt-get install cdbs
<savvas> POX: I made one for 0.3.2, the one in Debian svn is for 0.3.1
<mok0> turl, sudo apt-get install debhelper
<POX> savvas: did you have to change something besides version?
<savvas> POX: I think it's the fix_makefile patch
 * Turl installs what mok0 said
<mok0> turl, after that try debuild again
<cody-somerville> POX, thanks
<Turl> mok0: it seems to have worked
<Turl> there's a little warning though, W: ubuntulooks source: ancient-standards-version 3.6.2 (current is 3.8.0)
<mok0> Turl: yay
<mok0> Turl: you should have a new source package in ..
<POX> savvas: send me `svn diff` output (or I'll prepare it myself)
<Turl> mok0: I have some new files now, a .build and a .changes
<Turl> is it OK?
<mok0> Turl: sounds right. You should also have a new .dsc fie
<mok0> file
<Turl> mok0: I only have the old one :/
<Turl> I guess it's been replaced?
<Turl> well, it seems to be the old one mok0. I cat'ted it and it has the old version number
<mok0> Turl: what's in the changes file? (pastebin)
<Turl> http://paste.pocoo.org/show/99474/
<mok0> Turl, hmm, I think something went wrong with your changelog entry
<mok0> Turl: you didn't update the release to -13
<Turl> stupid me, I didn't :p
<mok0> Turl: change it, and run the debuild command again
<Turl> ready
<Turl> I have now -12 and -13 files
<savvas> POX: I'm still learning, can you grab it and compare it yourself? :) Here: http://savvas.radevic.com/packaging/catfish/10Fix_makefile.dpatch
<mok0> turl, great. But you overwrote the original -12 files so you need to apt-get source again
<POX> ok
<savvas> POX: It's mostly the same patch, but I've included the change to point to share/icons/hicolor/scalable/apps
<Turl> mok0: do I need to do everything from scratch?
<mok0> Turl: no, just don't delete the -13 files
<Turl> ok
<savvas> POX: do I have to open a new upstream package request in Debian for this?
<mok0> Turl: we just need to re-establish the -12 files that were accidentally overwritten
<Turl> now dpkg-source -x ? or what?
<mok0> Turl: yes
<Turl> ready mok0
<POX> savvas: no, I will just upload it and let you know to file a sync request bug in Ubuntu (I'll close the LP bug in changelog)
<mok0> Turl: now run debdiff old.dsc new.dsc
<savvas> POX: ok, cheers! :)
<mok0> Turl: replace "old" and "new" with the appropriate names
<Turl> ok mok0
<Turl> ready
<mok0> Turl: the output came to stdout, right?
<Turl> I got a ubuntulooks_0.9.12-13.diff.gz if I'm right
<Turl> yeah, some output came to stdout
<mok0> Turl: ok, you need to pipe it to a file; I routinely would call it "ubuntulooks_0.9.12-13.debdiff"
<Turl> ready
<mok0> Turl: let's check the debdiff file. You need to:
<mok0> Turl: apt-get install patchutils
<savvas> btw, I noticed something in the dpatch file: "--- catfish-0.3~/Makefile.in2007-04-04 04:20:26.000000000 +0200" <- Does that ~ character stand for anything?
<mok0> savvas: yes
<mok0> savvas: patch needs it
<Turl> mok0: it seems to be there already
<mok0> turl, great. So do lsdiff ubuntulooks_....debdiff
<mok0> Turl: it should tell you what files are modified by the diff
<mok0> Turl: hopefully only 2
<savvas> mok0: I used catfish-0.3.2/Makefile.in instead of catfish-0.3~/Makefile.in and it built the package. Does that ~ mean something like .* in regex? :)
<mok0> savvas: eerrr no
<savvas> ok now I'm officially confused :p
<mok0> savvas: it's actually only important what's in the +++ line
<savvas> +++ catfish-0.3/Makefile.in2008-05-22 02:45:33.000000000 +0200
<Turl> mok0: there are more than 2 files, but it's because I moved a dir in purpouse for it not to conflict
<savvas> ah I see, ok
<mok0> savas, thats the one
<savvas> thanks mok0!
<mok0> Turl: ah, ok
<Turl> now what mok0?
<mok0> Turl: how did you move that dir?
<Turl> mok0: with mv, why?
<mok0> Turl: because that way it won't be reflected in the package
<mok0> Turl: it's not the right way to do it
<Turl> :/
<Turl> tell me how to move it and I'll do it from scratch then :p
<mok0> Turl: but forgetting about that, you are in principle done. You could attach the debdiff to the bug and write a note that this fixes the ubuntulooks package
<mok0> Turl: but the bug mentions making a fix in another package, too
<Turl> yeah
<Turl> and how can I upload it to a ppa? so it's available for my friend
<mok0> Turl: so you should go through the same thing with that, build a new package with a new release number, make a debdiff to the old package and upload the debdiff to LP
<Turl> ok mok0
<mok0> Turl: then the developers will look at your patches, and you will get a lot of karma ;-)
<mok0> Turl: but we should look at that dir that you want to move
<mok0> Turl: can you tell me what it is
<mok0> Turl: yes you can upload to your ppa,
<Turl> mok0: the dir is ubuntulooks-0.9.12/themes/Human/
<Turl> and I moved it to ubuntulooks-0.9.12/themes/Human-UbuntuLooks/
<Turl> and fixed the makefiles
<mok0> Turl: ah
<mok0> Turl: but when the package is built, it uses the orig.tar.gz which still has that dir in the same place
<mok0> Turl: so the trick is not to move it locally, but install it somewhere else
<Turl> hm, so what should I edit then?
<mok0> Turl: err I need to figure out how it works first
<mok0> Turl: during building, the package is constructed in a subdir to debian/
<mok0> Turl: so, it creates a directory: debian/gtk2-engines-ubuntulooks/usr/share/themes/Human
<mok0> Turl: the trick is to move it after compilation but before package building
<mok0> Turl: and you do that in debian/rules
<mok0> Turl, are you there?
<Turl> yeah mok0
<mok0> Turl: are you following?
<Turl> the rules file has includes only
<mok0> Turl: yes, but CDBS has some hooks you can use
<Turl> I really don't know CDBS :p nor packaging, that's why you're explaining me
<mok0> Turl: after the includes, make a new target called "install/gtk2-engines-ubuntulooks::"
<mok0> turl, next line:
<hyperair> could someone review my package? http://revu.ubuntuwire.com/details.py?package=codelite
<Turl> mok0: for the target I just type "install/gtk2-engines-ubuntulooks::" ?
<mok0> <tab>mv -f ddebian/gtk2-engines-ubuntulooks/usr/share/themes/Human/ debian/gtk2-engines-ubuntulooks/usr/share/themes/Human_somethingelse
<mok0> Turl: yers
<Turl> is it ok the ddebian or is it a typo?
<mok0> Turl: debian
<mok0> Turl: it's just the mv command from topdir to move the Human directory to something else
<Turl> ok :)
<mok0> Turl: but the <tab> first character on that line is importatnt
<mok0> turl, see here how it's done, about 1/5 down the document: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
<mok0> Turl: my wife just called me the 2nd time to tell me to come home for dinner... I gotta go
<mok0> Turl: don't forget to document moving the directory in changelog
<iulian> RainCT: ping
<cody-somerville> w00t
<cody-somerville> :)
<RainCT> iulian: pong
<iulian> RainCT: What do you think about the removal of the revu-uploaders team?
<iulian> RainCT: I mean, do we still need it there?
<RainCT> iulian: nope
<iulian> RainCT: OK then.  Do you have the power to deactivate it or should we open a question in launchpad and ask for it to be removed?
<RainCT> iulian: I set it to restricted, that's all I can do
 * iulian wonders who can deactivate it.
<Turl> how can I sign a .changes file?
<Turl> I already have my key
<iulian> Turl: debsign -k<keyid> ...
<Turl> thanks iulian
<Turl> my packages were rejected :/  PPA uploads must be for the RELEASE pocket.
<Turl> what does that mean?
<iulian> Turl: You should ask PPA questions in #launchpad.
<Turl> ok
<fabrice_sp> Turl, you used other version that normal release (hardy, jaunty, intrepid, ...) in your changelog
<Turl> I used intrepid-proposed
<fabrice_sp> you have to put intrepid
<Turl> ok
<fabrice_sp> Hi. Where can I ask something about sbuild (it seems to leave sometime a temporary build partition that I cannot delete)
<ScottK> fabrice_sp: Here's not bad.  A number of people who hang out here use it (not me, however).
<fabrice_sp> ok. I just wanted how to delete them, as I haven't found for the moment why it's happening
<fabrice_sp> (and I have 6 of them)
<fabrice_sp> I can't even umount them: Device is busy (and I rebooted several time my computer)
<maxb> This is sbuild in lvm mode, I assume?
<fabrice_sp> maxb, yes
<fabrice_sp> I setup a lvm for that purpose
<maxb> Try 'schroot --list --all-sessions'
<fabrice_sp> here they are my 6 sessions
<maxb> schroot --end-session --all-sessions (or do it individually)
<fabrice_sp> It worked! You're the man, maxb ! Thanks :-)
<maxb> And I've never even used LVM :-)
<maxb> need to find some spare hd space to play at some point
<fabrice_sp> I did that to have some software 'raid' for my home (already lost 2 times my home before)
<fabrice_sp> and I decided to use it also for building thing, and separating the chroot in  another 'partition'. Work great! :-)
<fabrice_sp> but never access your lvm at the same time with gparted and system-config-lvm. You will lost everything
<fabrice_sp> anyway, thanks for your help! :-)
<AnAnt> can someone direct me to an example package to help me in writing get-orig-source: target ?
<ScottK> AnAnt: How about plasmoid-kbstate
<AnAnt> what's the source package name ?
<POX> AnAnt: /me wrote recently this: http://svn.debian.org/viewsvn/*checkout*/python-modules/packages/sqlalchemy/trunk/debian/rules
<ScottK> AnAnt: plasmoid-kbstate.  It's only in Jaunty though.
<mok0> hrmph. Damn mysql build clogging up the build queue
<directhex> jms@destiny:~$ firefox
<directhex> Aborted
<directhex> jms@destiny:~$ firefox
<directhex> Aborted
<directhex> go go free software
<joaopinto> directhex, exactly how does "free software" relates to your problem ?
<directhex> joaopinto, firefox crashes 30+ times a day. it gets annoying
<joaopinto> I have no crashes with firefox, it most likely related to a plugin, or something specific to your configuration
<directhex> nspluginwrapper/flash is certainly to blame for many of the crashes, but it seems not as many of them as i thought
<joaopinto> relating a firefox crash with "free software" could be offending for free software developers
<ScottK> directhex: Firefox isn't particularly free, IMO.
<directhex> ScottK, mmm, perhaps. i have a EULA here for you..... ;)
<laga> joaopinto: win
<Chris`> Firefox crashes sometimes for me yet Windows XP crashed more, how does it relate to the freeness of it?
<ScottK> directhex: Exactly.
<directhex> firefox is one of the media's poster children for a successful free software app. it's high profile. when it cocks up, it's noticed more than if the chicken scheme compiler isn't up to scratch, fr'example
<directhex> and as an app people use constantly, infuriating when it dies
<mok0> Firefox is stable as a rock for me
<directhex> mok0, i386?
<mok0> directhex: perhaps you should direct your curses at the wireless producers that wont release  their specs
<mok0> directhex: amd64
<Chris`> When a package gets removed for the reason "NBS" what does that mean?
<mok0> Chris`: it's a binary package with no corresponding source package
 * directhex gives webkit another spin
<Chris`> mok0: Thanks ;)
<mok0> Chris`: for example if the source package has been renamed, the old binary packages will be "orphans"
<mok0> directhex: are you looking at Chrome?
<directhex> mok0, midori. does chrome's linux shell have advanced features like "pressing enter" yet?
<mok0> directhex: I don't know
<stochastic> Hi everyone, I just finished my first package and uploaded it to my PPA: http://ppa.launchpad.net/stochastic/ubuntu  it's of the Calf audio plugins.  Please review and let me know how horrible my packaging skills are.
<directhex> stochastic, cracked the variable substitution?
<laga> stochastic: you should probably put it on REVU (?)
<stochastic> directhex, yes, thanks to liw's advice it was a problem with it trying to make to debian/calf rather than debian/calf-plugins
<stochastic> laga, how do I do that - I'm new to all this
<laga> stochastic: i bet it's documented on the MOTU wiki page
<stochastic> ok, I'll do a search
<laga> !revu
<ubottu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<laga> wee.
<stochastic> ok, it's in REVU now
<stochastic> hmm, it looks like dput uploaded to REVU fine, but I don't see it there and my profile shows no uploads, am I just too quick for the system?
<jpds> RainCT, james_w: We have lplib support in u-d-t \o/
<james_w> thanks jpds
<james_w> and thekorn
<jpds> Especially thekorn.
<james_w> jpds: would you write a mail to the list about what that means please?
<RainCT> jpds: rock on!
 * RainCT hugs jpds and thekorn 
<jpds> james_w: Sure, first shower and let brain cool down.
<james_w> :-)
<khashayar> stochastic: from my experience, it can take a while before the package shows up on the web interface ;-)
<stochastic> khashayar, I know you're good at backporting, and I'd like to upload a version of that package for intrepid to my PPA, is there anything special I need to do other than force the upload of the different version?
<khashayar> stochastic: The only thing you need to do, is to make sure it has a different version number (limitation of ppa). That is, if your jaunty package is calf-0.0.17-0ubuntu1~jaunty~ppa1, your intrepid pacakge should be something like calf-0.0.17-0ubuntu1~intrepid~ppa1.
<maxb> But usually you wouldn't use ~jaunty at all since its the development release
<khashayar> oh, and you in your .dput.cf, you could have a section for intrepid with "incoming = ~stochastic/ubuntu/intrepid". This will upload to intrepid.
<maxb> and the logical nesting is more ~ppa1~intrepid
<khashayar> maxb: That's right, no ~jaunty
<maxb> Convention seems to be to do ~intrepid1, also
<stochastic> ok, so do I just rename the .changes file after I've debuild the package?  or does that need to happen before debuild somewhere?
<khashayar> maxb: really? I thought convention was ~release~ppa1, and releaseX for backports.
<maxb> nope
<ScottK> stochastic: In debian/changelog
<ScottK> Then debuild.
<stochastic> ok, perfect
<ScottK> maxb: I'd suggest the other way around.
<maxb> because if you update the package in your ppa, you go to ~ppa2, and then you backport that
<ScottK> maxb: In Ubuntu Backports we use ~$RELEASEX
<maxb> Quite
<ScottK> So ~ppaX will be a problem.
<ScottK> Should be ~releaseX~ppaY
<maxb> Well, I'm basing my suggestion off https://help.launchpad.net/Packaging/PPA#Versioning
<maxb> ScottK: What's the X for, in that model?
<ScottK> maxb: This is an Ubuntu channel.  Nothing to do with us there.
<ScottK> Number starting with 1
<maxb> ScottK: I don't understand what you're saying. Given that Ubuntu is the only distribution with PPAs, how can documentation about PPA versioning not apply?
<maxb> ScottK: Yes, but what does that number mean? Attempts at backporting?
<ScottK> Yes.  Revisions.
<ScottK> maxb: It's written by Launchpad developers who are not Ubuntu developers.
<maxb> If ~ppaX indicates releases of a package in a ppa, and ~intrepidX indicates attempts at backporting, then the order of versioning significance dictates ~ppaX before ~intrepidX
<maxb> Because the first attempt at backporting the second release needs to be newer than the second attempt at backporting the first release
<ScottK> maxb: What happens if you upgrade from Hardy to Intrepid.  You need to move to the intrepid version of the package.
<ScottK> How do you ensure that with that broken model
<ScottK> maxb: It's really OT here anyway.  Go find someone on #launchpad that knows more about distro development than we do here.
 * ScottK heads off.
<maxb> Erm
<maxb> I am unconvinced the model I'm suggesting is broken. Is there a better channel to discuss the interaction between Ubuntu PPAs and Ubuntu primary archive?
<khashayar> maxb: I pm:ed you.
<maxb> indeed, I just wanted the conversation to unambiguously show that I don't accept the assertion that that model is broken
<RainCT> uhm.. how can I install the nvidia 180 driver? I tooke the .deb's from packages.ubuntu.com but the version doesn't show up in jockey
<RainCT> (as always I want to know something, no answers in #ubuntu :P)
<maxb> RainCT: Install the -modaliases package, then jockey should know about it
<RainCT> funny, that's what I was doing right now :P
<RainCT> maxb: thanks :)
<maxb> But, what do you mean you took the .deb's from packages.ubuntu.com? Why not let apt get them for you?
<RainCT> maxb: because (and I've no idea why) I can't get APT to see it..
<RainCT> updates, backports, etc. are enabled and cache up2date
<RainCT> but I only see 180 packages in jaunty
<maxb> That's because they're in intrepid-proposed
<RainCT> oh. packages.ubuntu.com shows them in intrepid-updates
<RainCT> great, jockey sees it now.. let's see if it works
<RainCT> maxb: failed to initialzie kernel module"
<RainCT> maxb: do I need to reboot'
 * RainCT should learn to type :P
<RAOF> What's a major update binary nvidia driver doing in -proposed?
<cody-somerville> lmao
<maxb> Oh, it's actually in -updates now, I hadn't noticed.
<maxb> However, it's a new-to-intrepid package, so it's strictly opt-in
<maxb> probably why it was considered SRU-able
<directhex> does 180.22 support gtx295?
<maxb> 180 does ameliorate some severe compiz rendering issues, so that's probably also a reason for the SRU
<directhex> hm, no, 295 unsupported
<RainCT> (works now)
<bluesmoke> maxb: Does it fix nvidia leaking texture memory into the compiz process?
<directhex> "Fixed a regression that could result in window decoration corruption when running Compiz using Geforce 6 and 7 series GPUs."
<maxb> Don't know about that one. I know it stops my window decorations from corrupting themselves often, which they did with 177
<RAOF> bluesmoke: That's a good question.  I haven't tried that :)
<Chris`> Which section would a flight simulation program best fit?
<ScottK> maxb: I'll file a bug on help.launchpad.net when I get a moment.
<maxb> Where would such a bug belong? It's not exactly part of launchpad-the-project per-se?
<ScottK> BTW, I don't accept that people managing to develop a really slow web tool gives them any particular expertise about Linux distro development.
<ScottK> maxb: Dunno.  In Ubuntu we have a project for web site bugs, I'd assumed that Launchpad would have something similar.
<ScottK> Generally I file against the launchpad meta project and someone triages it into the right place.
<maxb> ok. By the way, are there any concrete examples of the number in ~releaseX being other than 1?
<ScottK> Sure.  It takes me more than one try on a not infrequent basis.
<maxb> for sourceful backports, then?
<ScottK> maxb: https://edge.launchpad.net/~ubuntu-clamav/+archive for a PPA.
<ScottK> That also shows you the multi-release model I suggest is appropriate.
<maxb> In a quick read through I don't see anything other than ~release or ~release1, but I do see foo~dapper1~ppa4 but foo~hardy1~ppa1 which is enlightenting
<maxb> My advocacy of ~ppaX~releaseX is founded on the assumption that any bump to the ppaX number is a crosscutting packaging change which *will* be backported to all release series
<maxb> I agree that without that assumption, upgrading across releases is broken
<ScottK> maxb: https://launchpad.net/ubuntu/+source/clamav/+publishinghistory
<ScottK> Also ~ppa is a higher revision than anything you'll find in *-backports and that should be avoided too.
<maxb> Ah, thanks, didn't know about that view, so I tried to skim though all of the superseded package info, and evidently missed bits
<ScottK> Clamav is about as tortured a package history as you are likely to find as it's a highly used package with lots of security uploads and stuff.
<maxb> Is ~dapper1ubuntu0.1 just someone driving dch in a non-optimal way?
<maxb> ohh... I think I'm seeing the tortuous sense in it now
<maxb> I agree ~ppaX is a bit of a nonsense all round, really. If you are doing further development of foo 1.0-1ubuntu1, then it makes more sense to go to 1.0-1ubuntu1ppa1 rather than 1.0-1ubuntu2~ppa1, I think
<maxb> Whilst if you are doing a backport, it needs to be less than an official backport.
<maxb> So ~ppa loses either way
<savvas> Yay, catfish 0.3.2-1 published in debian: http://packages.debian.org/sid/catfish
#ubuntu-motu 2009-01-14
<savvas> POX: sorry about debian/rules, I forgot I changed the link to catfish.svg in that too :) good catch!
<ScottK> maxb: The 0.1 thing is used for security uploads.
<savvas> ScottK: can you remind me the channel for debian python?
<ScottK> savvas: On OFTC it's #debian-python
<savvas> ah oftc
<savvas> ok thanks :)
<Riddell> sommer: ping
<Riddell> sommer: your ebox upload to intrepid-proposed has no bug number
<cody-somerville> Riddell, I don't think they've been approved for motu-sru yet either
<Riddell> doesn't seem so looking at the other two
<sommer> Riddell: ya, the packages still need some work, should have new ones ready soon... waiting on upstream for some info
<Riddell> sommer: so I should reject?
<sommer> Riddell: ya, I'd like to fix the things cody-somerville mentioned in the bug
<sommer> and get the jaunty packages working as well
<stochastic> Hi, I'm having some troubles getting my new calf package to build in my PPA for hardy.  Everything was going fine until: dh_clean: Sorry, but 6 is the highest compatibility level supported by this debhelper.
<stochastic> here's the full build log: http://launchpadlibrarian.net/21181806/buildlog_ubuntu-hardy-i386.calf_0.0.17-0ubuntu1~hardy~ppa2_FAILEDTOBUILD.txt.gz
<stochastic> and here's the PPA: https://launchpad.net/~stochastic/+archive/
<stochastic> There seems to be a problem (probably in the rules file) with using debhelper 6, but I'm brand new to packaging and on an Intrepid system, so...
<RAOF> stochastic: No, the problem there is that Hardy has debhelper 5.
<RAOF> Or, apparently, debhelper 6?  That seems odd.  I was sure it was 5.
<stochastic> RAOF, the package listing said 6
<stochastic> I'm going to turn on verbose output to see if anything more can be explained
<maxb> stochastic: The problem is that you have adjusted the Build-Depends, but you have not adjusted the debhelper level requested in debian/compat (I assume)
<stochastic> ahhh
<stochastic> I'll try that
<maxb> stochastic: 'man debhelper' details the effect of the compatibility levels. If your package definitely does not benefit from using the absolutely latest level, it can be useful to require an older version, to ease backporting
<RAOF> Or you could just build against hardy-backports, which IIRC contains debhelper 7
<stochastic> ok, this is my first package, so I'm learning as I go
<maxb> The command 'rmadison' displays the version of a package in all the ubuntu distribtions - this is very useful for this sort of thing - 'rmadison debhelper' tells you at a glance which version is available where
<maxb> including that yes, hardy-backports has 7
<maxb> though its possible that you might not want to reconfigure your entire PPA for that
<ScottK> The reason we backported Debhepler 7 to Hardy is that a non-trivial number of packages are using Debhelper 7 functions and it saves a lot of debian/rules rewriting.
<ScottK> If you're going to be trying to bring current packages back to hardy, I suggest building on backports.
<ScottK> Also a lot of stuff is already there.
<BullHorns> Hi, can I start helping with development on ubuntu If I run hardy 8.04 or do I need to upgrade?
<BullHorns> I did a lot of reading the past week and it looks like I should start with motu
<ScottK> BullHorns: You can.
<BullHorns> what development tools do you use, Who can help me with the first few steps to start. It will help me alot to get to work soon
<BullHorns> how do ajunta compare with kdevelop?
<fabrice_sp> BullHorns, you can begin reading the info at https://wiki.ubuntu.com/MOTU/GettingStarted
<dholbach> good morning
<iulian> Morning Daniel.
<dholbach> hiya iulian
<dholbach> nxvl: do you know if somebody contacted the spanish speaking ubuntu community about ubuntu developer week?
<didrocks> morning o/
<dholbach> didrocks, huats: good morning
<dholbach> didrocks, huats: did you let the french community know about ubuntu developer week?
<huats> hey dholbach
<huats> it was supposed to be announced today or tomorrow
<huats> but I'll take care of advertising it today
<dholbach> huats: fantastique!
<huats> :)
<DktrKranz> dholbach: uh! thanks for the remainder, I'll blog about it for -it too! I won't be there... our CTO will come auditing us and I'll be busy for a couple of days :(
<didrocks> dholbach: basically what huats means is that I will blog about it today :)
<huats> LOL
<huats> didrocks: no no
<huats> I mean I will blog about it too :)
<didrocks> huats: really ? :p
<didrocks> (jut kidding)
 * dholbach hugs DktrKranz
<dholbach> thanks DktrKranz
<didrocks> just*
<huats> didrocks: I know that you wait for an email... ;)
<didrocks> huats: I didn't like to repeat it, but... yes ;)
<huats> :)
 * DktrKranz hugs dholbach back
<huats> didrocks: doing it right now
<dholbach> :)
<didrocks> huats: great \o/
 * didrocks hugs huats 
 * huats hugs didrocksa and dholbach ;)
<mok0> raphink: ping
<raphink> mok0: pong
<james_w> we're falling back on the sponsor queue a bit, could everyone with upload rights please try and sponsor one or two things today?
<mok0> raphink: PM
<stefanlsd> james_w: put up another imview diff. not exactly where i wanted it to go, but i cant seem to get the autotools stuff working
<james_w> stefanlsd: I was just looking at it :-)
<dholbach> hiya quadrispro
<dholbach> quadrispro: the imlib2 bug was fixed! :)
<quadrispro> dholbach: i'm just working on it :)
<dholbach> ... in Debian
<dholbach> rock on!
<james_w> stefanlsd: what happens if you call your acinclude.m4 aclocal.m4 and drop the call to aclocal?
<dholbach> james_w: yay sponsoring! :)
<james_w> stefanlsd: and your diff is missing the addition of the automake build-depends, but it would be easy for me to add that in while sponsoring
<stefanlsd> james_w: mm. works.  also.  i think loic was wanting to move more to using the autotools...  but yeah, we're not really achieving anything by doing it (except planning for autotools)
<stefanlsd> james_w: maybe we shouldnt do it for now and i'll work with the debian guys to seeing how we can improve it to use autotools
<stefanlsd> we then rename acinclude.m4 to aclocal.m4, remove automake from build-deps and remove the aclocal call.
<james_w> stefanlsd: yeah, if you go with an aclocal.m4 that m4_includes the files with the macros you need from an "m4" directory then moving to autotools is easy
<james_w> I just learnt all this yesterday from Keybuk as it happens
<quadrispro> dholbach: building in progress -> http://home.alessiotreglia.com/jaunty/result/imlib2_1.4.2-4ubuntu1/imlib2_1.4.2-4ubuntu1_amd64.build
<stefanlsd> james_w: let me test quick.
<dholbach> quadrispro: got it
<quadrispro> dholbach: bug #317053
<ubottu> Launchpad bug 317053 in imlib2 "Please merge imlib2 1.4.2-4 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/317053
<dholbach> quadrispro: will play with it a bit, then upload it - no need for a bug
<dholbach> ah ok
<dholbach> :)
<gaspa> boshhead:
<gaspa> uops. I meant... where's bobbo?
<gaspa> I just have a couple of thing about ssherminator...
<quadrispro> anyone on bug 315767?
<ubottu> Launchpad bug 315767 in gpm "Please merge gpm 1.20.4-3.1 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/315767
<quadrispro> dholbach: imlib2 has been build in my ppa
<quadrispro> s/build/built
<dholbach> quadrispro: just played with it over here and I'm going to upload it in a bit
<dholbach> thanks a lot
<quadrispro> you're welcome
<dholbach> you rock!
<quadrispro> yes, I'm learning to rock sometime :D
<dholbach> quadrispro: you're being modest :)
<stefanlsd> james_w: do you know whats the normal practice for m4/ when its a .m4 shipped by another system lib?  so we need pkg.m4 - do i include /usr/share/aclocal/pkg.m4 or cp that to the imview  m4/ directory and call it there?
<james_w> stefanlsd: cp it I believe
<stefanlsd> james_w: i presume i do that in the rules then?  or before build?
<james_w> stefanlsd: in the source package
<james_w> if you were using aclocal then you wouldn't have to bother
<stefanlsd> james_w: kk. thanks
<james_w> you could m4_include() it, but I think it's preferred to have it in the packaqge
<stefanlsd> james_w: http://paste.ubuntu.com/104788/           (that kinda idea?)
<james_w> stefanlsd: yeah, I think that's right
<james_w> stefanlsd: does it work? :-)
<emgent> adobe removed old flash player 9 tar.gz, and flashplugin-nonfree in hardy is broken.
<emgent> now is avail only fp10
<stefanlsd> james_w: yeah, builds. i also tested with --without-magick and  have_magick=no and it doesnt include the libs and includes. so that seems to work also.
<james_w> stefanlsd: cool
<stefanlsd> james_w:  should i upload this diff to the bug rather?
<james_w> stefanlsd: yes please
<james_w> it's inconvenient to extract it from the pastebin
<stefanlsd> james_w: np. done.
<james_w> thanks
<quadrispro> mr_pouit: hi!
<stefanlsd> james_w: has anyone looked at jspwiki?
<james_w> stefanlsd: not sure
<stefanlsd> james_w: kk. will look at it
<james_w> actually, someone was looking at it, I thought it was you
<directhex> woo, jsp?
<stefanlsd> james_w: umm. not that i am aware of. hehe
<james_w> we can sync
<james_w> *unless* the patches that the maintainer disabled in the new version are needed
<stefanlsd> james_w: kk. checking. mm. i need to install ant for the debuild to work.
<directhex> stefanlsd, which is reasonable enough if it uses an ant clean target inside the debian/rules clean rule
<stefanlsd> directhex: yeah sure. runs an ant clean.   just contaminating my nice installation with this java stuff :P
<directhex> stefanlsd, i know that feeling :|
<directhex> stefanlsd, i wonder if nant would work for the sake of the clean rule, though ;)
<nxvl> dholbach: i pinged some LoCos
<dholbach> nxvl: excellent - thanks!
<primes2h> hello to all.
<primes2h> I need an ack for a SRU in Hardy and Gutsy for this bug #294502, please.
<ubottu> Launchpad bug 294502 in dvd-slideshow "dvd-slideshow reports error using ffmpeg" [Undecided,Confirmed] https://launchpad.net/bugs/294502
<primes2h> could someone help me, please? :-)
<quadrispro> anyone on Bug 317095?
<ubottu> Launchpad bug 317095 in libgeier "Please sync libgeier 0.10-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/317095
<james_w> stefanlsd: uploaded, thanks for your hard work
<stefanlsd> james_w: thx. np. jspwiki. i see they dont ever pull in the patches, you added the dpatch to do that, but im not sure its needed as I cant see where they were ever introduced. the debian dsc builds fine thou.
<james_w> stefanlsd: yeah, dpatch was missing, but in the last-but-one upload to debian they disabled the calls to dpatch in debian/rules, so we can sync
<james_w> my only concern is that it all just looked a bit weird, so I would appreciate you checking that the patches in debian/patches aren't needed
<stefanlsd> james_w: k. i had a look at the patches. not a java expert thou as to what they were actually used for. i'll ping one of the java guys to have a look for us.
<mok0> Huh?? Newest version on remote site is 1.03, local version is 0.147
<mok0> cadabra: Newer version (1.03) available on remote site
<mok0> ah
<mok0> stupid me
<stefanlsd> james_w: looks like the first one is to do with json and jabsorb.  looks like jabsorb is a alternative compatible lib for json.  it looks like jspwiki still uses json (/lib/jsonrpc-1.0.jar)  http://jabsorb.org/UpgradeGuide
<james_w> stefanlsd: yeah, "* Removed XML-RPC capability for now." suggests that the patch is not needed
<james_w> I'm a bit concerned by the second though, as with that it will be building against .jars shipped in the package, but presumably won't be running against those ones
 * slytherin stares at the mention of jars shipped with the source package. >:o
<slytherin> james_w: stefanlsd: which package are you discussing by the way?
<james_w> slytherin: jspwiki
<slytherin> james_w: should have guessed it. I am not sure why does Debian package contain jar files in .orig.tar.gz. I am tempted to file a bug in Debian. :-)
<mok0> I see lots of packages with missing license clauses in the source files. How serious it that? It is more the exception that the rule that upstream authors have included it
<ScottK> mok0: Not serious enough to prevent inclusion in the archive if there's a full copy of $LICENSE in the tarball.
<mok0> ScottK, I've been following that policy.
<ScottK> It's good to edcuate upstream.
<ScottK> educate even
<mok0> ScottK, yeah, but I've also seen upstream bitch about the "rabid debian developers"
<ScottK> Good thing this is Ubuntu then.
<mok0> heh
<ScottK> There was a time when FSF suggested a full copy of the GPL in every file.
<ScottK> License headers aren't so bad.
<mok0> ScottK, I agree, the short clause is ok
<mok0> ScottK: the full GPL in every file is perhaps a bit over the top
<ScottK> "If someone grabs a copy of a file from your project and reuses it elsewhere, wouldn't you want people to know where it came from." seems to work OKish.
<liw> scottK, FSF suggested full GPL in each source? when? I haven't ever seen that, but I admit I've only followed GNU stuff since 1989
<ScottK> liw: It may just be an urban legend.  That's what I recall being told.
<liw> ok
<pochu> 1989 -> that's when I was 1!
 * ScottK lived most of that year in Keflavik, Iceland.
<dholbach> pochu: don't you make liw feel old!
<dholbach> ScottK: what did you do there?
<pochu> haha
<mok0> pochu: kiddie
<pochu> ScottK: you can buy Iceland now ;-)
<ScottK> dholbach: I was in the US Navy (there used to be a base there).
<dholbach> ScottK: ah ok
<dholbach> ScottK: did you get to see a bit of the country? :)
<ScottK> dholbach: Yes.  Saw quite a bit of it.
<dholbach> cool
<ScottK> Almost fell off a glacier once.
<mok0> RainCT: There are 2 packages in "Updated packages" on REVU, but neither of them are in Ubuntu (anymore). What gives?
<mok0> RainCT: Can
<mok0> RainCT: Can't we do away with that section?
<ScottK-desktop> mok0: There are times when that's helpful.
<mok0> ScottK, hm, ok
<mok0> ScottK, not when the uploads are in the wrong category, though
<ScottK> True, but there are times when I've worked with someone on an updated package and it's convenient to have them throw it on REVU even if it's not the official way.
<mok0> ScottK, Wasn't that before the PPA days?
<mok0> Of course you can make use of the REVU  comment system
<ScottK> mok0: No.  I don't consider PPAs very good for that.
<bddebian> Heya gang
<ScottK> heya bddebian.
<bddebian> Hi ScottK
<mok0> Do we have a drop-in replacement for jackd? I am not very knowledgeable about multimedia systems
<ScottK> mok0: I'd suggest ask in #ubuntu-studio.  They know all that stuff.
<mok0> ScottK, thanks I'll try that
<dholbach> RainCT: ubuntu-dev-tools is not installable right now (sb-release vs lsb-release) - is it OK if I upload your latest change now?
<dholbach> RainCT: done
<RizR> hello everyone. just going through ubuntu packaging process and bug fix process
<RizR> cant really get my head around harvest. it lists bugs - yes. but why is it this way?
<RizR> anyone got couple of secs spare? :-)
<anakron> Hi all
<anakron> if i make a build of a package, a warning but be considered?
<gaspa> RizR: what's the question, in particular? (what do you mean by  "this way"?)
<anakron> warning, `debian/python-milter/DEBIAN/control' contains user-defined field `Python-Version'
<anakron> or i can say that was built whitout problems
<RizR> hello everyone. just going through ubuntu packaging process and bug fix process
<RizR> cant really get my head around harvest. it lists bugs - yes. but why is it this way
<RizR> anyone got couple of secs spare? :-)
<gaspa> RizR: (i already answered) what do you mean by  "this way"?
<RizR> sorry if someone spoke earlier. i had added whole freenode in ignore list by mistake.
<RizR> sorry.
<RizR> gaspa: ok, I'm not clear or the purpose of harvest if bugs are tracked in launchpad
<RizR> of the purpose...
<james_w> RizR: it highlights "low hanging fruit"
<savvas> it tries to show all the bugs that are probably easy to fix (I think)
<james_w> RizR: there are lots of lists of bugs of a certain class, e.g. maintainer script problems, or patches attached, and harvest aggregates them
<RizR> james_w: can we filter out the number of bugs displayed? lets say just display from last week or just from certain module or upstream code base? or may be from ubuntu only?
<gaspa> RizR: and have them all grouped by package is an helpful thing as well
<james_w> RizR: if you go to the index there is a latest items display
<james_w> RizR: there are plans to improve the interface of harvest soon
<spitfire> Does anyone know how to use custom CFLAGS in pbuilder? Globally, WITHOUT modifying rules for every package.
<RizR> james_w: ok :-) I get the idea. its just the the size of the thing makes my firefox go bonkers
<savvas> spitfire: I don't think you can
<spitfire> savvas: you're sure?
<spitfire> apt-build can do that?
<spitfire> Why wouldn't pbuilder be able?
<spitfire> *apt-build can do that.
<savvas> I'm not sure, I said I think :)
<ScottK> spitfire: --debbuildopts will pass arguments to dpkg-buildpackage inside the pbuilder chroot, so if you know what to tell dpkg-buildpackage, then you might do it.
<savvas> spitfire: maybe with --debuildopts and -R argument?
<spitfire> ScottK do you have idea what to pass?
<stefanlsd> james_w: i spoke with deb maintainer of jspwiki. yeah, they dont use the patches.  they use the includes jars. for 2.8.1 he has made seperate packages that will use /usr/share/java and the debian jars
<james_w> stefanlsd: cool
<ScottK> spitfire: Depending on the package, you might use -Rrules-file
<james_w> stefanlsd: should we merge the current version then?
<ScottK> spitfire: See man dpkg-buildpackage for details.
<spitfire> ScottK depending on the package.
<stefanlsd> james_w: yeah, sync should be ok
<spitfire> ok
<james_w> stefanlsd: er, yeah, sync
<stefanlsd> james_w: nodnod :)
<savvas> spitfire: wait, there are some environment variables
<james_w> stefanlsd: want to request it?
<stefanlsd> james_w: sure
<spitfire> savvas: where?
<savvas> spitfire: http://manpages.ubuntu.com/manpages/jaunty/en/man1/dpkg-buildpackage.1.html#toptoc4 go to the "Environment" topic
<spitfire> ScottK: haven't found anything that looks usable,
<spitfire> savvas: thx!
 * ScottK doesn't have additional ideas on the topic.
<DktrKranz> spitfire: IIRC they're managed with some environment variables, I don't remember if pbuilder inherits them from current session or not, anyway man dpkg-buildpackage has a full list of such variables
<savvas> spitfire: it doesn't say how to use them, and it mentions that not all packages honour it. but I suppose it's: CFLAGS="blah" pbuilder command
<spitfire> savvas: or CFLAGS="blah" in .pbuilderrc
<spitfire> thanks
<savvas> well I don't know, perhaps :)
<RizR> one more q. in harvest i see different status for bugs (resolved-upstream, patches, bitesize etc). They're pretty obvious and I think most of those require re-package the module after including the patch provided. Am I right in thinking that?
<james_w> RizR: often yes
<RizR> james_w: can I find a list of all statuses somewhere on wiki/launchpad plz?
<stefanlsd> james_w: https://launchpad.net/bugs/317147
<ubottu> Ubuntu bug 317147 in jspwiki "Please sync jspwiki 2.8.0-3 (universe) from Debian unstable (contrib)." [Undecided,New]
<james_w> stefanlsd: cool, thank you
<stefanlsd> james_w: np!
<stefanlsd> cya guys, heading home :)
<james_w> RizR: you mean bug statuses?
<RizR> james_w: yes
<james_w> https://help.launchpad.net/Bugs/Statuses
<savvas> or https://wiki.ubuntu.com/Bugs/Tags :)
<savvas> (talking about the "bitesize" mentioned before)
<anakron> hi all
<anakron> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/315156
<ubottu> Ubuntu bug 315156 in nautilus "Installs unnecessary desktop file" [Low,New]
<cody-somerville> nxvl, why did you ack an SRU after I asked questions about it?
<anakron> what do you think about this
<anakron> its right to take it out or not
<cody-somerville> ...
<cody-somerville> You did it to three of the SRUs I was taking care of!
<RizR> james_w: thanks.
<nxvl> cody-somerville: yup, i worked on the updates, so i knew those questions
<nxvl> :D
<anakron> ...
<cody-somerville> nxvl, Some of them were things *wrong* with the debdiff
<anakron> someone can answer me?
<savvas> what does SRU stand for?
<ScottK> anakron: #ubuntu-desktop might be a better place to ask.
<ScottK> savvas: Stable Release Update.
<cody-somerville> anakron, yes
<anakron> ok thanks
<savvas> ScottK: and ACK means acknowledged?
<ScottK> Yes.
<savvas> cool, thanks
<cody-somerville> nxvl, Not to mention I feel it was rude. The applicant acknowledged my points and said he was going to work on them
<cody-somerville> and then you went ahead and acked the SRUs
<nxvl> cody-somerville: you are right, i apologise for that
<nxvl> cody-somerville: i was thinking on pinging you, but you weren't here still and i forgot about that
<nxvl> my fault
<cody-somerville> I appreciate the apology
<nxvl> but yes, on the server team we already test that
<nxvl> and we needed that sru's
<nxvl> also the fix was worked closely with upstream
<nxvl> and zul sponsored those
<nxvl> so they have been well checked and testes
<nxvl> tested
<cody-somerville> I don't care. It needs to follow the SRU policy like every other SRU.
<nxvl> but yes, it was rude and that was my fault
<nxvl> yes, that i know
<nxvl> and it's following, the only issue here was that i was rude on what i did
<cody-somerville> And I had questions/concerns about the SRU
<nxvl> right
<nxvl> you can de-ack them if you feel it will be better
<nxvl> so we avoid problems/discussions
<nxvl> i will try to ping you before doing so next time, i promise
<cody-somerville> nxvl, Please send an e-mail to the archive admins alerting them to your mistake.
<nxvl> cody-somerville: well, it haven't go trought sru-verification still
<nxvl> cody-somerville: so archive admins aren't still involved, right?
<cody-somerville> nxvl, sommers did upload already
<nxvl> zul did
<cody-somerville> Right, his sponsor
<nxvl> sommer has no upload rights
<nxvl> ok i will ping them
<nxvl> is there a ML for arc admins
<nxvl> ?
<joaopinto> from an archive admin perspective what would be the difference if nxvl acked and cody-somerville had no participation on the verification ?
<cody-somerville> joaopinto, Because nxvl is retracting his ack
<joaopinto> cody-somerville, that is not my question, what would be the difference from the procedure perspective if nxvl acked before you looked into the sru ?
<james_w> nxvl, cody-somerville: I believe there were rejected last night
<james_w> they were, sorry
<nxvl> i'm de-acking to avoind issues with cody-somerville since what i did was rude
<joaopinto> cody-somerville, he is not retracting because it feels is ACK was wrong per si, but just because it is wrong relating to your previous action
<nxvl> james_w: so i don't need to ping the arch admins
<nxvl> so i'm removing my vote until cody-somerville has all his concerns resulved
<nxvl> resolved
<james_w> nxvl: I don't think so, check the unapproved queue
<nxvl> joaopinto: exactly, but there is any difference?
<nxvl> joaopinto: i think keeping good relationships and respecting the community and procedures is as important as the technical quality
<cody-somerville> joaopinto, I imagine the archive admins would have caught some of the same mistakes I did resulting in the SRU getting thrown back and so I would have gotten involved regardless.
<joaopinto> nxvl, right, but you don't need to roll backup a process which was properly followed to fix "relations", relations are resolved on a 1 to 1 basis, and that's what you are doing by acknowledging the fault
<nxvl> yes, but it doesn't resolve/answer cody-somerville's concerns
<joaopinto> ok
<RainCT> dholbach: now it's too late, but yes, it's OK :)
<phaidros> hi, still on packages.ubuntu.com search servers are listed which do not mirror anymore.
<phaidros> http://packages.ubuntu.com/jaunty/all/calendarserver/download
<phaidros> look for debian.charite.de
<phaidros> this is since ages, where to report this?
<phaidros> if not here?
<Ahmuck> good morning
<afflux> Hi! I'm unable to rebuild matplotlib, because it build-depends on python-enthought-traits (src:enthought-traits) has been removed from debian in favor of python-traits (which has a transitional python-enthought-traits package). python-traits, however, is not in Ubuntu. What is the procedure for this? Should I request a sync for it?
<spitfire> how to disable tests when bulding package?
<pochu> afflux: likely
<pochu> spitfire: check if they are run in debian/rules, and if so, disable them there :)
<spitfire> pochu: I use pbuilder, is there a way to handle it internally?
<pochu> don't think so
<spitfire> Or do I have to edit rules manually?
<pochu> the latter
<spitfire> the latter?
<spitfire> ok
<james_w> the package should repect DEB_BUILD_OPTIONS=notest
<james_w> or nocheck, I always forget
<Laney> evening guvnors
<spitfire> james_w: i found this: ifeq ($(with_check),yes)
<DaSkreech> Hallo
<spitfire> so WITH_CHECK=0 ?
<DaSkreech>  how would I find out if Mars Land Of No Mercy is being packaged ?
<james_w> spitfire: with_check will be set somewhere else in the file probably
<james_w> hey Laney
<spitfire> packages.debian.org?
<spitfire> james_w: nope.
<spitfire> didn't found it.
<DaSkreech> spitfire: Me?
<spitfire> DaSkreech: you.
<DaSkreech> Thanks
<spitfire> packages.debian.org?
<james_w> spitfire: odd
<spitfire> packages.ubuntu.com
<james_w> spitfire: does the package use cdbs?
<spitfire> james_w: I'll pastebin it.
<spitfire> It's gcc
<james_w> oh
<spitfire> yes
<james_w> afflux: yeah, request a sync if it's not in jaunty.
<james_w> afflux: it's possible it's in the NEW queue though
<afflux> james_w: where can I check that again? ;)
<spitfire> james_w: how do I deal with that?
<james_w> spitfire: no idea
<james_w> afflux: I can never remember the url
<spitfire> james_w: but it takes AGES:/
<spitfire> http://pastebin.com/f2e816b73
<afflux> james_w: ah, that one maybe? https://edge.launchpad.net/ubuntu/intrepid/+queue
<spitfire> ^^maybe you could find somehing actually useful in it..
<spitfire> afflux: jaunty
<spitfire> not intrepid
<afflux> doh.
<afflux> looks good
<james_w> afflux: that's it
<afflux> james_w: thanks then
<james_w> spitfire: checkout #
<james_w> #
<james_w> include debian/rules.defs
<james_w> #
<james_w> include debian/rules.parameters
<spitfire> ok
<DaSkreech> spitfire: If it's not packaged by debian what is the liklihood that it will get packaged for Ubuntu ?
<spitfire> so i should comment out these finctions? really?
<spitfire> DaSkreech:
<spitfire> yeah
<spitfire> look for packages.ubuntu.com
<spitfire> But it isn;t likely
<DaSkreech> ok
<DaSkreech> there was a bug filed for it in LP
<spitfire> When it's not in debian it rpobably wont be in ubuntu.
<spitfire> But try.
<DaSkreech> ok thanks
<spitfire> DaSkreech: it takes looong tim sometimes.
<DaSkreech> I realise the bug was filed for 7.10
<DaSkreech> might make it for 9.10 :)
<karooga> hi, i'm trying package an app which doesn't have the licences in the original tar.gz.  Can't get hold of upstream... what options do I have?
<maxb> karooga: Doesn't have the licence full text, or doesn't have any declaration of licence at all?
<karooga> maxb: doesn't have full licence text.
<maxb> Is the named licence a sufficiently common one that you can download it from another source and be confident it's the right licence?
<karooga> maxb: it is -  LGPL
<coppro> does it say what version?
<karooga> max: but I understand that the orig tar gz has to include the actual licence for it to be distributable.  This is not the case for the deb package though.
<karooga> coppro:   >= LGPL 2
 * RainCT rofl because of xkcd
<ScottK> If the desired license is documented, but just a full copy isn't provided, you can repack the tarball and add it.
 * ScottK has done that before.
<nhandler> RainCT: The xkcd comic for today gave me a great idea
<RainCT> nhandler: which one?
<nhandler> RainCT: The voice synthesizer one. One day, I connected to my computer (which was connected to my iPod speakers at full volume) and started to play the Start Wars movie. It scared the crap out of my mom (who was working at home)
<karooga> ScottK: presumably I'd upload (to launchpad or sourceforge etc) and then reference that site as the download tar.gz?
<afflux> pochu: do I have to give some specific reason for syncing the new packages?
<RainCT> lol
<pochu> afflux: saying they are necessary for mpl should be enough
<afflux> alright
<afflux> thanks
<nhandler> Does anyone here know why uscan would detect foo-current.tar.gz as being newer than foo-x.y.tar.gz? Does it check when the files were last modified?
<mok0> nhandler: it's the natural sorting order
<nhandler> mok0: Ok, so I guess I'll just update my watch file to require the version to begin with a number
<mok0> nhandler: yeah do that
<karooga> ScottK still there?
<ScottK> Sort of
<karooga> ScottK: dunno if you saw my last response? ;-)
<ScottK> karooga: Just did.
<ScottK> No, the repacked tarball is just used within Ubuntu then.  If it's a new package you use it in your upload to REVU.  You'll want to include a get-orig-source rule to recreate the tarball in the future.
<karooga> ScottK: would uploading repackaged tarball make me upstream?
 * jpds mind-boggles at http://pastebin.ubuntu.com/104943/ .
<ScottK> karooga: No.
<karooga> ScottK: Ok, so all references in the debian package directory refer to the original tarball (copyright, control etc).  Only in the get-orig-source in rules I do some magic packaging to create the 'good' tarball?
<ScottK> Copyright is original.  All the rest is refer to repacked version.
 * ScottK goes off for a while.
<karooga> ScottK: I could just copy the relevant licence from /usr/share/apps/LICENSES and retarball?
<ScottK> /usr/share/common-licenses or some authoritative source.
<karooga> ScottK: great thanks for the help. :-)
<jreinhardt> Hi everybody. Can someone please take a look on this package on REVU? http://revu.ubuntuwire.com/details.py?package=pgfplots
<jreinhardt> I (think I) fixed all comments from the first review
<jreinhardt> But I am not sure whether i got the watch file and the tex install part right
<vorian> is there any kind of refernce on installing .xpm icons?
<RainCT> vorian: what problem do you have?
<vorian> debhelper is not installing icons from debian/icons
<vorian> i have the .install file set up correctly
<vorian> i've never messed with .xpm before
<RAOF> In what way is it not installing them?  They don't appear in the deb?
<vorian> debhelper is not finding them
<RAOF> Want to post the source pkg?
<vorian> it's amarok
<vorian> so, we use that kde4.mk voodoo
<RainCT> vorian: it's like installing any other file
<vorian> i'm trying something else atm
<vorian> RainCT: yeah, it does install every other file, but fails on that line
<vorian> let me see what happen with this build
<RainCT> vorian: which line is it?
<vorian> it's not in the current package
<vorian> this will be new
<RainCT> vorian: I mean, paste it here :P
<vorian> http://paste.ubuntu.com/104980/
<RainCT> weird, that should work (as long as it's allowed to mix both styles of lines in debian/install)
<vorian> we shall see
<cbhl> Hi, I'm wondering about bug 178895 (https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/178895); someone has commented that audacity 1.3.6-2 from Debian should fix the issue, but I notice that we're past DebianImportFreeze. What can/needs to be done to see if we can get audacity 1.3.6-2 in Jaunty?
<ubottu> Launchpad bug 178895 in audacity "Audacity does not mesh with PulseAudio" [Low,Fix committed] https://launchpad.net/bugs/178895
<ubottu> Ubuntu bug 178895 in audacity "Audacity does not mesh with PulseAudio" [Low,Fix committed]
<vorian> cbhl: the package can still be sync'd if you file a request
<vorian> import freeze simply means that auto-syncs stop
<cbhl> Do you have any tips as to how I can get started on filing a request? For example, do I need to open a bug report?
<vorian> sure, hold on
<nhandler> cbhl: Use requestsync from ubuntu-dev-tools
<vorian> cbhl: https://wiki.ubuntu.com/SyncRequestProcess
<vorian> cbhl: the tool nhandler mentions makes it semi-automatic
<vorian> the link i posted explains the reasoning
<cbhl> vorian: okay, thank you -- I'll take a look at that right now
<nhandler> cbhl: If this is your first sync request, you should try doing it by hand so you get the experience
<nhandler> However, the tool does save a lot of time if you are filing a lot of requests
<cbhl> Hm, it seems a request has already been filed.
<cbhl> Okay, thanks for your time.
<mrooney> If my application is compatible with Python 2.5 and 2.6, should my pycompat be just 2.5 or something else?
<pochu> mrooney: >= 2.5, but you probably want XS-Python-Versions instead of pycompat
<mrooney> pochu: I am using that in control, should I not have a pycompat then?
<pochu> mrooney: it's not necessary, no
<mrooney> pochu: okay thanks, I'll that file!
<mrooney> I'll remove, that is
<rexbron> any motu's interested in improving support for firewire-based sound cards? Please revu http://revu.ubuntuwire.com/details.py?package=libffado Thanks!
<mrooney> I was told I needed to add the gpl header to my `copyright`, does http://pastebin.com/f1794b68a look right?
<mrooney> actually, I think it was supposed to go in the License section, what about http://pastebin.com/f39e45710 ?
<vorian> mrooney: that is better, you need a trailing line after that header that looks like
<vorian> http://paste.ubuntu.com/105010/
<vorian> on line 17 and 18
<mrooney> vorian: oh okay, the link to it for the packaging itself isn't enough?
<vorian> license header, then where to find the full text
<vorian> think of it in those terms
<vorian> you will also need the CC license header by the looks of your copyright page
<mrooney> vorian: yeah, I think you reviewed my package (wxbanker), so I am going through and making all the changes now
<vorian> ah, ok :)
<mrooney> I have done everything except the CC license header since I am not sure where to find that, and updating the standards version to 3.8
<asomething_> do you need the full CC license as there's no copy in /usr/share/common-licenses/ ?
<pochu> yes
<mrooney> asomething_: that's easier, I know where to find that :)
<mrooney> pochu: so do I put http://creativecommons.org/licenses/by/2.5/legalcode in the copyright file under license, and how do I separate that from the GPL above?
#ubuntu-motu 2009-01-15
<pochu> mrooney: if only a few files are licensed under the CC license, after the GPL license, say something like "For $(files), the following license applies:" and then put the license
<pochu> mrooney: e.g. http://packages.debian.org/changelogs/pool/main/e/emesene/emesene_1.0.1-2/emesene.copyright
<pochu> that has the GPL for the application, but a few files are licensed under different terms
<mrooney> pochu: what can I use to handle line lengths and indentations correctly, to fit in the specs for `copyright` ?
<mrooney> for http://creativecommons.org/licenses/by/2.5/legalcode
<pochu> no idea
<pochu> I just copy&paste, and try to fit everything in 80 chars lines
<pochu> are you following the new copyright format proposal?
<pochu> if so, look at the specification :)
<mrooney> pochu: well I mean it isn't within 80 chars and it is long, I don't want to trim it by hand
<ScottK> m3ga: Hello.
<ScottK> m3ga: Automatic syncing is all done from Sid, but we can pull from both Testing and Experimental if needed.
<ScottK> We're past the point in this release cycle where it happens automatically now, so now would be a good time to do rebuilds to get things sequenced correctly.
<m3ga> ScottK: i think the problem is that lanaguages like ocaml and haskell require a little more care in the packaging and that there hasn't been enough expert care in this area.
<pochu> mrooney: if you leave it as is, does lintian complain?
<pochu> mrooney: if not, I think you can leave it as is
<ScottK> m3ga: As I understand it they have to be built in a certain sequence that our automated and semi-automated methods don't support.
<ScottK> m3ga: I think that's a different way of saying the same thing.
<m3ga> ScottK: i've got two packages in intrepid (one ocaml and one haskell) which are broken. i'll do an analysis of why and report back.
<ScottK> m3ga: OK.  If you can look at Jaunty too, that would be very useful as this stuff is much harder to fix post-release.
<m3ga> ScottK: yeah, i have jaunty in a vm. i'll  test there as well. However, my experience of the last several releases of ubuntu is that for ocaml libraries, it always a different one thats broken in some subtle way.
<asomething> mrooney: I don't know what the diff between cc-by and cc-by-sa is, but human-icon-theme seems to have cc-by-sa 2.5 already formated. Might mean less work for you
<ScottK> m3ga: This has come up before and I think the issue is they have to be built in a certain order.
<mrooney> asomething: ahh cool, I'll look into that, thanks!
<ScottK> m3ga: What we need is someone who understands the language/packages to help us get them sequenced right.
<m3ga> ScottK: i think the problem is better solved by software tools rather than man power  :-)
<ScottK> m3ga: All I need is the tool then.
<RAOF> Wasn't the issue that some hash of the dependencies was encoded into each build, and so you needed to ensure that each rebuild of a node triggered the rebuild of all children?
<m3ga> ScottK: I need to  do a little research and testing.
<ScottK> m3ga: OK.  Let us know.
<RAOF> I take it no-one is shephearding Banshee through the various gnome-sharp transitions?
<_16aR_> Hello
<RAOF> Hi
<_16aR_> I have a question. I'm packaging a little software
<_16aR_> So I thought I should post a need-packaging bugreport on launchpad first, right ?
<vorian> that helps
<_16aR_> but the problem is : I don't see the needs packaging option, and when I want to name my package, lp say it isn't there ...
<_16aR_> normal, I don't have finished it yet
<nhandler> _16aR_: File the bug against Ubuntu
<nhandler> And there is no needs-packaging option. Just title the bug '[needs-packaging] Foo'
<_16aR_> against project ubuntu instead of distribution/package ?
<nhandler> Add the needs-packaging tag
<_16aR_> ok
<_16aR_> so : summary = mypackagename, tag = needs-packaging, distribution = ubuntu ?
<_16aR_> and no text inside ?
<nhandler> summary = '[needs-packaging] yourpackagename'
<nhandler> Text includes the URL, license, and any other relevant info
<RAOF> And a description of what it actually *does*!
<_16aR_> ok
<vorian> what does it to?
 * vorian hopes for new kde goodness
<_16aR_> hexdiff : a ncurses "visual" diff editor in hexadecimal
<_16aR_> sorry
<_16aR_> ncurses goodness, though
<vorian> hehe
<vorian> sounds promising
<_16aR_> it helped me a lot, so ... I think it should be good to have it in ubuntu. moreover, it's only 5 .c source file. So, lightweight and easily compiled
<vorian> fantastic!
<nixternal> james_w: what is involved in listing teams a member belongs to (or admins possibly) with launchpadlibs? it seems the team_memberships isn't incorporated yet
<james_w> nixternal: it might be person.memberships_details
<nixternal> ahh, let me try that
<nixternal> thanks
<james_w> https://edge.launchpad.net/+apidoc/#team_membership if you haven't found it
<james_w> teams = [mem.team for mem in person.team_memberships]
<james_w> but you'll want to filter on status
<nixternal> ahhh haaa, that's the one :)
<_16aR_> in cdbs, how to override or add value to the CFLAGS variable for example ,
<_16aR_> ?
<_16aR_> in my makefile, it does CFLAGS+=blabla, but when pbuilder build it, they don't appear :(
<RAOF> _16aR_: It depends on what cdbs rules you're using.
<RAOF> _16aR_: I'd guess you want to be here: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2528304
<_16aR_> debhelper and makefile
<_16aR_> already read
<RAOF> So DEB_MAKE_ENVVARS is your winner.
<RAOF> It gives exactly an example of setting something in CFLAGS there.
<_16aR_> RAOF: ok, but all I want is to add the cdbs default CFLAGS, to the one already in the Makefile of my Package
<RAOF> It'll set that automatically.
<_16aR_> I can copy the CFLAGS of the package into the debian/rules, but if it could be automated
<_16aR_> not really, it overrides it :(
<RAOF> Then you need to patch the makefile.
<_16aR_> ok
<RAOF> Or, rather, if the CDBS flags are overriding the ones in the Makefile then you need to add the Makefile's flags to the ones specified by CDBS.
<RAOF>  / build environment.
<stochastic> can anyone point me in the direction of how to format a debian/watch file?
<TheMuso> stochastic: the uscan manpage probably has something about them.
<dholbach> good morning
<hyperair> can anyone review my package? it's already got an advocate. http://revu.ubuntuwire.com/details.py?package=codelite
<didrocks> dholbach: morning (and yes, I was awake before ;))
<dholbach> good morning didrocks! :)
<dholbach> I was not saying that you're slacking :)
<didrocks> I hope so :p
<directhex> http://www.wkowtv.com/Global/story.asp?S=9667184
<directhex> :/
<liw> directhex, that's a pretty unfortunate piece of news, and shines a rather bad light... on Verizon and MATC
<directhex> liw, but to the drooling residents of madison, wisconsin, who looks like the baddie?
<liw> directhex, they're blissful in their ignorance and nothing can make them look bad
<directhex> liw, the article was televised, even
<slytherin> I wonder if the girl even bothered looking into the applications menu to see that there was already a word processor.
<directhex> slytherin, the article is bunk. afaik there isn't even a link to dell.com/ubuntu from the main dell.com site, certainly no full-size laptops in their regular site come with or can be configured with ubuntu
<directhex> slytherin, obviously blame shifting to cover dropping out. 2 semesters of work, over pretend requirements for windows? nah, not happening
<directhex> given at the bottom both parties involved said they'd get their stuff working for her anyway
<slytherin> right. And if I was spending $1100 to buy a laptop I would make sure 10 times that I was getting exactly what I wanted. ï»¿Claiming that Ubuntu was provided without any prior notification is a complete lie in my opinion.
<directhex> "The main thing to note is that when you choose open source you donât get a WindowsÂ® operating system. If youâre here by mistake and you are looking for a Dell PC with Windows, please use the following link."
<directhex> from the warning text on dell.com/ubuntu, which you need to individually seek out
<stochastic> nasty letters need to be written to that editor
<stochastic> whaddya know, here's the contact info: http://www.wkowtv.com/Global/story.asp?S=8388593&nav=menu1362_12_1
<milli> crimeny that's just lousy journalism
<james_w> vorian: I wish you hadn't uploaded ncpfs, there are quite a few problems with the package that I am working on
<savvas> does anyone know someone from pkg-puppet-devel in debian? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511826
<ubottu> Debian bug 511826 in puppetmaster "manpages and/or binaries misplaced in wrong packages" [Normal,Open]
<savvas> I provided patches, I need that fixed so I can request a sync and close bug #116417 on launchpad :)
<ubottu> Launchpad bug 116417 in puppet "puppetmasterd and puppetca have no man pages" [Low,Triaged] https://launchpad.net/bugs/116417
<stochastic> I've run into some issue uploading a package I'm working on to my PPA, I get this rejected message: phat_0.4.1-0ubuntu1.dsc: Section '-' is not valid
<stochastic> here's the control file: http://paste.ubuntu.com/105100/
<stochastic> sorry, I should post this question in #launchpad shouldn't I
<siretart> stochastic: better paste the changes file you've uploaded
<siretart> in addition to the dsc file
<stochastic> http://paste.ubuntu.com/105101/ the changes file
<karooga> hi, anyone got a moment to review my package?
<siretart> there you have it. the section is empty
<karooga> It's: http://revu.ubuntuwire.com/details.py?upid=3660
<stochastic> well there's two different sections in the control file
<stochastic> here's the dsc file: http://paste.ubuntu.com/105102/
<stochastic> how do I format that?
<siretart> stochastic: you probably need to specify a section for the source as well
<savvas> ah yes
<savvas> I had that problem before
<savvas> I think you have to use Section: libs for source
<stochastic> would someone like to give my package a REVU? http://revu.ubuntuwire.com/details.py?package=calf
<stochastic> If I'm building a series of packages that depend upon one another, is there any way to get pbuilder to be configured to pull from a PPA repo?
<mok0> stochastic: yes
<mok0> stochastic: you're not talking about a circular depency I hope
<stochastic> nope, linear
<mok0> stochastic: you have to use the --othermirror switch
<stochastic> okay, thanks I'll look into that
<mok0> stochastic: or, --login to the pbuilder with --save-after-login and exit the source.list file
<mok0> s/exit/edit
<stochastic> mok0, it doesn't seem to be able to pull from the repo, though it did get the listing from pbuilder update and I can see the package in apt-cache policy
<stochastic> am I missing something?
<stochastic> do I need pbuilder to verify the repository?
<mok0> stochastic: sorry I was afk
<mok0> stochastic: Is the package in the Build-Depends?
<stochastic> yes
<mok0> stochastic: how did you add the repo?
<stochastic> I went through the .pbuilderrc file as directed here: https://wiki.ubuntu.com/PbuilderHowto#Using%20the%20%27othermirror%27%20option
<mok0> stochastic: hm, I wonder if you also need to include the --othermirror option when you invoke the build
<stochastic> I'll give it a try, but it pulled the new source when I did pbuilder update
<mok0> stochastic: that should be enough I would think, but you never know :-)
<slytherin> stochastic: What is the problem you are facing?
<stochastic> slytherin, I'm trying to get pbuilder to pull a dev library from my PPA repo
<slytherin> stochastic: let me take a look at your pbuilderrc
<slytherin> stochastic: have you pasted it anywhere?
<stochastic> http://paste.ubuntu.com/105150/
<stochastic> I know the second part is kinda pointless, but that's what the howto told me to add
<slytherin> stochastic: when you did pbuilder update, did you use --override-config option?
<stochastic> nope
<stochastic> I guess I should have?
<slytherin> stochastic: yes
<stochastic> off I go...
<stochastic> success!!
<norsetto> huats!!!
<mok0> yiiihaa
<mok0> norsetto!!
<huats> norsetto: !!!
<norsetto> mok0!V
<huats> so happy to see you my old friend  !
<mok0> huats: you can SEE him?
<huats> we miss you !
<norsetto> huats: I'm not old, I'm just generationally challenged ;-)
<mok0> lol
<huats> norsetto:  :)
 * pochu waves :)
<norsetto> heya pochu
<pochu> hey hey norsetto!
<pochu> hi huats and mok0
 * pochu refreshes his ppa waiting for a build to start
<huats> hey pochu
<mok0> Hi pochu!
<james_w> hey norsetto
<norsetto> hi james_w , how's life in lovely Bristol?
<james_w> norsetto: great thanks, how are you?
<norsetto> huats: better not to ask about Toulouse  ;-)
<norsetto> james_w, surviving ;-)
<james_w> good :-)
<huats> norsetto: ;)
<mok0> OK guys let's not get all emotional here... back to work!
 * pochu goes back to refresh his ppa :P
<norsetto> mok0: he, this reminds me the joke about the two finnish drinking together
<mok0> norsetto: yes?
<norsetto> mok0: well, one of the two said skoll to the other
<mok0> :-)
<mok0> haha
<norsetto> mok0: and the other replied, in an harsh tone, are we drinking or talking!?
<mok0> I guessed that! :-D
<norsetto> mok0: well, I knew you would, you viking ;-)
<mok0> raphink: Can we nuke greycstoration from REVU?
<raphink> hmmm we could mok0
<raphink> although it could be an interesting package to have
<raphink> since this functionality is not included in gimp
<mok0> raphink: The last comment from norsetto says it's part of gimp-plugin-registry
<mok0> raphink: I agree, that app is awesome, I have used it on some of my photos
<mok0> raphink: ok, I'll leave it, I thought you might have given up on it
<norsetto> mok0: yes, quite a catch-all that package, can't say I like the approach ...
<mok0> norsetto: oh? Why not?
<norsetto> mok0: not very maintainable IMHO
<norsetto> mok0: and why should one oblige a user to install 30 applications when all he needs is one?
<mok0> norsetto: is that what goes on? I only recall that it makes an app
<mok0> and a plugin
<mok0> norsetto: in any case, cgreystoration is superb at removing visible noise from your photos...
<mok0> norsetto: much better than anything else I've seen, even PhotoShop
<norsetto> mok0: I was talking about the gimp-plugin-registry package
<mok0> norsetto: ah
<mok0> Well, in that case, shouldn't we push that package forward? raphink?
<raphink> mok0: sure
<mok0> get to work, raphink ;-)
<raphink> mok0: some KDE apps have it by default now, like krita and digikam e.g.
<raphink> mok0: well, has it been reviewed yet?
<mok0> raphink: greycstoration? Yes a long time ago
<mok0> http://revu.ubuntuwire.com/details.py?package=greycstoration
<raphink> I lack time ;)
<raphink> you can tell, I'm sure ;)
<hyperair> mok0: could you review codelite again please? http://revu.ubuntuwire.com/details.py?package=codelite
<mok0> hyperair: I've already advocated the package, someone else needs to, as well
<mok0> hyperair: just don't do any new uploads
<raphink> oh and you reviewed it yourself even mok0
<raphink> ;)
<mok0> raphink: that's why I asked
<raphink> hehe I see
<hyperair> mok0: i know you have, but i did a new upload
<raphink> I'm probably not very up-to-date with new rules
<raphink> considering maintainers and so on
<hyperair> mok0: nhandler has advocated the package, but yours was lost after upstream came up with a new version
<raphink> I think that it might not be a really good thing that policy changes so fast
 * mok0 looks
<raphink> so people who knew the rules a year ago don't anymore and need to spend time re-reading them
<mok0> raphink: I don't see an upload since the comments
<raphink> no, I didn't upload anymore mok0
<raphink> I have to find time to look at it ;)
<raphink> quiet a few things in your comments are new to me
<raphink> it wasn't done like that last time I made new packages ;)
<raphink> so I need to check these new rules
<mok0> raphink: yeah, just ask here
<raphink> mok0: the last comments seems to indicate that greycstoration is already packaged
<raphink> as part of another package
<mok0> hyperair: I am puzzled, AFAICS my advocation is still there, but REVU fails to count it
<mok0> hyperair: ah, it's for another upload
<hyperair> mok0: yeah it's another upload. nhandler advocated this upload, but not the one you advocated. partly because debian/copyright was off and there was a new version from upstream
<mok0> hyperair: very strange, it keeps adding my comment to the previous upload...
<mok0> hyperair: never mind
<mok0> hyperair: I will upload it now
<hyperair> mok0: thanks
<mok0> Thanks for your work, hyperair
<hyperair> np
<mok0> hyperair: codelite is now in the new queue https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=
<hyperair> mok0: okay thanks
<apachelogger> siretart, lool: could one of you please take a look at bug 290768
<ubottu> Launchpad bug 290768 in xine-lib "Using KDE4 trunk all multimedia apps crash because of Xine" [High,Triaged] https://launchpad.net/bugs/290768
<mok0> siretart: pinnngg
<lool> apachelogger: Is there any backtrace of this crash somewhere?  I see a crash file, but I suspect it wasn't sent with apport and hence hasn't the proper tags / wasn't retraced
<lool> Ah there's a partial one upstream
<siretart> mok0: yes?
<mok0> I am not able to log on to revu although I am an -admin
<lool> siretart: Do you reproduce the above crash with xine?
<lool> siretart: With LC_ALL=it_IT.UTF-8 or fr_FR.UTF-8, it doesn't crash
<lool> Ah that's intrepid actually
<lool> and amd64
<lool> apachelogger: Ok; it's a bug in the italian translation on launchpad
<lool> English: load_plugins: static plugin found
<lool> Current Italian: load_plugins: plugin %s trovato
<JontheEchidna> it's a bug with german too
<JontheEchidna> I think it'd probably be a good idea if most translations were checked
<lool> JontheEchidna: I don't seem to have the right to change them
<lool> JontheEchidna: Do you know who to contact for such cases?
<mok0> "Would you hold it against me if I said you had beautiful thighs?"
<lool> I wonder whether that qualify as a SRU regression
<mok0> "A hoovercraft has eels"
<JontheEchidna> lool: nope, I just had a german guy in #kubuntu with the same crash yesterday
 * JontheEchidna speaks english
<JontheEchidna> obviously ;-)
<lool> JontheEchidna: I also tried looking at the reporters and thought some didn't have an italian sounding name
<lool> I'm moving the discussion to #ubuntu-devel as it sounds like a SRU regression
<lool> Err kubuntu-devel
 * directhex mails mok0 an eel-filled hovercraft
<siretart> lool: sorry, I don't have a jaunty system to test
<lool> siretart: it's an intrepid issue
<lool> siretart: It seems like a string issue
 * mok0 thanks directhex
<siretart> hm. gxine works fine for me in german locale on i386
<siretart> needs more investigation...
<mok0> Ah none of you young guys remember the Monty Python sketch about the Romanian Parleur
<directhex> hungarian?
<mok0> directhex: yes, sorry hungarian
<directhex> http://www.thisisawar.com/LaughterMPHungarian.htm
<mok0> Hehe yes that's the one... priceless
<mok0> directhex: re: JontheEchidna asking for a review of all translations ;-)
<directhex> sounds like a rather major task
<directhex> can't we just put an automatic check on matching numbers of %s et al on all languages, when publishing translations?
<JontheEchidna> apparently the rosetta dudes are gonna scan the translations for the errors
<directhex> that's okay then
<directhex> apachelogger, remember the ubuntu-calendar packages?
<apachelogger> directhex: nope
<anakron> Hi all
<anakron> :) good morning...here in chile
<anakron> good [random]
<RainCT> hi
<directhex> apachelogger, it was some wallpaper, released monthly, a while back. there may have been boobies involved. check packages.ubuntu.com
<JontheEchidna> "there may have been boobies involved". You now have my full, undivided attention. :P
<JontheEchidna> [/sexist remarks]
<anakron> hi rain
<mok0> I just reviewed http://revu.ubuntuwire.com/details.py?package=nx but I feel very unsure about that package. I'd appreciate if someone else could take a look.
<hyperair> ooh nx
<hyperair> i remember there was an unofficial repository containing that once
<directhex> JontheEchidna, i suspect that's why it was removed. despite the month with the naked guy.
<JontheEchidna> O.o
<JontheEchidna> do not want
<directhex> JontheEchidna, check the deps/suggests of http://packages.ubuntu.com/dapper/ubuntu-calendar - no promises on which contains whom and in what state of undress.
<directhex> hint: you won't like jan
<apachelogger> directhex: oh well, I am not a fan of boobies :P
<jpds> ...
<hyperair> ..what was that and what prompted it?
<jpds> hyperair: I'd rather not know.
<directhex> apachelogger, but that was probably a major factor in the calendar being dropped
<Nafallo> hyperair: calendar packages back in warty
<Nafallo> late response :-P
<jpds> Nafallo: Ah right.
 * apachelogger was on his way home
<apachelogger> directhex: kubuntu-wotm wouldn't go to official archives and either way have moderation
<directhex> apachelogger, the calendar was moderated. t'was in main i think!
<directhex> anyway, hometime
<apachelogger> one moderation crew that was :P
<Nafallo> the calendar was paid for photographic art AFAIK
<hyperair> Nafallo: you mean the monthly ubuntu calendar thing?
<Nafallo> hyperair: yes.
<hyperair> ah those
<karooga> is it acceptable to include copyright+licence info as a patch for files in a package which don't have it included (from upstream)?
<hyperair> no i don't think so
<hyperair> but i feel lucky that the upstream maintainer was cooperative regarding the license issues
<hyperair> you should contact upstream and see if they're willing to cooperate
<karooga> hyperair: i had cooperation initially but now about 3 months later - nothing.
<hyperair> karooga: bug the upstream maintainer some more?
<hyperair> if not ask a motu for guidance
<hyperair> whoever it is who reviewed your package perhaps
<karooga> hyperair: RainCT
<RainCT> yes?
<karooga> hyperair: i've already sent a couple of emails upstream.
<hyperair> karooga seems to be having some issues with upstream and copyright stuff
<hyperair> RainCT: ^
<karooga> oh hi, RainCT :-)
<hyperair> heh that was prompt
<karooga> RainCT:  fixing up final bits and following your review http://revu.ubuntuwire.com/details.py?upid=3660
<karooga> RainCT: any ideas?
<RainCT> okay, so you are more productive than me right now (/me just removed a directory with some stuff which will take him hours to redo :'()
<hyperair> poor thing
<karooga> RainCT: balls! sorry to hear it.  apt-get install recover... or apt-get install e2undel?
<hyperair> those only work with ext2 =(
<jpds> RainCT: no backups?
<karooga> hyperair: but ext3 is just ext2 + a journal?
<RainCT> jpds: no, I hadn't much yet, but it's stuff with which I have nearly no experience yet so I'll have to go through the docs again.. (writing python bindings in C/C++)
<hyperair> karooga: yes, but apt-cache show recover e2undel said it won't work with ext3
<jpds> RainCT: Ouch..
<karooga> :-/
<hyperair> i'm interested to try out ext4. it's just ext3 + extents right?
<karooga> hyperair: with 16TB file limits
<hyperair> ah
<hyperair> right
<hyperair> but my hard disk doesn't even reach 1TB
<hyperair> so to hell with that damn limit lol
<hggdh> question for any: Evolution 2.26 will require libpst at an updated version (0.6.x) than what is available on either Ubuntu or Debian. How do you want me to request it?
<slytherin> hggdh: asking in wrong channel. evolution is in main. So check if anyone has already thought about this or working on this in #ubuntu-devel.
<hggdh> slytherin, Evo is in main, but libpst is currently in Universe. After upgrading we will need a MIR on it
<slytherin> hggdh: right. But you should still check if the maintainers of evo have already thought about this or not.
<hggdh> slytherin, I did. I also help on Evolution...
<slytherin> hggdh: hmm. in that case file a bug for update of libpst. And you can work on as well if you want. :-)
<hggdh> heh
<hggdh> my doubt is Debian does not have an up-to-date libpst, so we would need to package from source -- and I am not sure of the process here...
<hggdh> (so it will not be a sync, but a real needs-packaging from source)
<slytherin> hggdh: that is all right. Debian is in deep freeze currently. So you probably won't see new libpst in Debian unstable till Lenny is released.
<slytherin> hggdh: can you tell me exact name of the package. I can not find any libpst package in Debian/Ubuntu.
<hggdh> slytherin,  on Debian and Ubuntu it is listed as readpst, source package libpst
<slytherin> hggdh: Ok. I was just checking if the package has any updated version in Debian experimental.
<hggdh> no...
<hggdh> (I had already checked, this is why I came here)
<slytherin> hggdh: please proceed with your plan then. :-)
<hggdh> slytherin, thanks. I did not want to get anything started before checking here
<slytherin> hggdh: make sure you log a bug first. And assign it to yourself.
<hggdh> slytherin, I will start with a needs-packaging, of course ;-)
<ScottK> Actually for an updated package it should be tagged 'upgrade'  'needs-packaging' is just for new packages
<slytherin> james_w: I was just wondering. Is there any point of keeping serpentine in archives when it offers no advantage over other tools like brasero.
<ScottK> slytherin: Unless it's abandoned upstream there's no pressing reason so remove it from Universe.
<slytherin> ScottK: well there is no reason to maintain as well. Anyway, I will leave it as it is.
<hggdh> ScottK, I will correct the bug. Thanks
<hggdh> ScottK, would the 'needs-packaging' tag still be applicable, or is there another tag to be used?
<directhex> poopies. intrepid doesn't support audio on this motherboard
<slytherin> hggdh: upgrade is correct tag
<Chris`> I have just finished packaging my first package, can someone check over the debian/control for me?
<maxb> Chris`: For submission to Ubuntu, or for personal/limited use?
<Chris`> maxb: For submission to Ubuntu
<Chris`> http://pastebin.com/m5eeda7cd
<Chris`> There is the control file
<maxb> Chris`: Have you read about REVU?
<nhandler> !revu | Chris`
<ubottu> Chris`: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<Chris`> maxb: Yeah however I'd rather just make sure that this is correct first :)
<maxb> Section: unknown
<Chris`> Yeah just editted )
<maxb> Priority: Networking !
<Chris`> Section: Networking priority: extra
<Chris`> :D
<Chris`> I'm concerned about the maintainer field
<directhex> jaunty supports it though
<Chris`> Should that be motu?
<maxb> yes
<Chris`> What's the name and address for the MOTU?
<nhandler> Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<Chris`> nhandler: Thanks ;)
<nhandler> You're welcome Chris`
<Chris`> So when I have finished this, what must I do with the pbuilder/result directory?
<jpds> Chris`: I think Prioirity ought to be optional, extra is rarely used.
<jpds> Chris`: Upload the source package to revu.
 * Chris` goes back and edits :)
<maxb> Your own name and email go in XSBC-Original-Maintainer:
<nhandler> Chris`: You don't need to do anything with the pbuilder/result directory. But you could mention that it built cleanly (if it did)
<jpds> Chris`: Latest Standards-Version is 3.8.0 too. :)
<maxb> You have some things in your Depends that I would have expected ${shlibs:Depends} to have taken care of
<jpds> Chris`: And you should have a new line every 80 spaces.
<Chris`> The Depends section, how does one go about fixing that?
<karooga> jpds:  is 80 the magic number from 80x25 in a terminal?
<jpds> Chris`: {$shlibs:Depends} autodetectes what your package needs normally.
<maxb> Remove all library packages from depends. Build. Check that the shlibs:Depends substituted everything you expected it to
<jpds> karooga: Yes, and it makes it easier to read.
<maxb> Read http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions about the Description field
<Chris`> http://pastebin.com/d7e36385 How does this look? :)
<maxb> 'Networking' is not a valid Section. You get to choose from the list defined in paragraph 2.4 of the debian-policy-manual only
<directhex> **** network manager
<directhex> it keeps ignoring my static configurating, re-creating the "auto eth0" setting, and using that
<Chris`> net?
<nhandler> There is a web section
<maxb> You imply you might be using rdesktop but don't build-depend on it
<Chris`> I haven't build-depended rdesktop, have I?
<Chris`> "dput revu package_version_source.changes" -- Is that all that is required?
<jpds> Chris`: Yep.
<jpds> Chris`: No, make sure you've logged into REVU first via the web interface.
<nhandler> Chris`: Also make sure your gpg key is in LP
<Chris`> I am but what about the source tarball?
<nhandler> Use debuild -S -sa
<nhandler> That will include the .orig.tar.gz in your upload
<Chris`> Am I only uploading the changes file using that command? Or am I uploading the changes and the orig
<Chris`> ah ok
<jpds> Chris`: and .diff.gz and .dsc.
<Chris`> Ok uploading... finally :)
<Chris`> Successfully uploaded packages.
<Chris`> Not running dinstall.
<Chris`> Is that bad?
<maxb> no
<Chris`> So dinstall is just something that I shouldn't worry about?
<maxb> Not running dinstall. == "I'm not debian" more or less
<Chris`> Ah ok cool
<Chris`> To close the bug, should I attach anything to launchpad now?
<jpds> Chris`: If you did the changelog right, the bug will be automagically closed when the package is uploaded to the archives.
<nhandler> Chris`: You shouldn't close the bug until the package gets uploaded to the repositories
<nhandler> The changelog entry should include (LP: #NNNNNN) to close the bug
<ScottK> hggdh: The tag is upgrade
<Chris`> Oh snap, "(Closes: lp:#314430)" Does the lack of space mean much?
<ScottK> Yes it does
<maxb> Chris`: You seem to have uploaded an old version
<nhandler> You don't need the word "Closes"
<jpds> Chris`: (LP: #NNNNN).
<nhandler> (LP: #314430) -- assuming that is a LP bug
<Chris`> maxb: What do you mean old? I just got that tarball from the homepage
<ScottK> If this is for a new package, last I noticed close in changelog didn't work for them anyway
<maxb> The version I see in revu lacks changes you just discussed in this channel
<Chris`> My control file?
<maxb> yes
<Chris`> Ah strange, lemme just refix ti
<Chris`> *it
<Chris`> dpkg-source: error: syntax error in grdc-0.2.0/debian/control at line 15: line with unknown format (not field-colon-value)
<Chris`> dpkg-buildpackage: failure: dpkg-source -b grdc-0.2.0 gave error exit status 9
<Chris`> debuild: fatal error at line 1329:
<Chris`> debuild error =\
<nhandler> What is line 15 in debian/control?
<maxb> You've got all kinds of boilerplate comments left over in your debian/rules too
<Chris`> application and a Gnome applet. Features include scrollable window, floating
<nhandler> Chris`: Is that in the description? If so, did the line start with a space?
<Chris`> nhandler: I'll try with a space now then :)
<Chris`> maxb: I don't understand the rules file, how can I go about removing the "boilerplate" stuff?
<karooga> nhandler: should all source files contain copyright+licencing info?
<nhandler> karooga: That would be ideal
<maxb> Chris`: You should not have commented out commands or comments that are instructions to you from the template rules file left over in the actual upload
<Chris`> maxb: I haven't touched the rules file, that was left over from dh_make
<nhandler> Chris`: Well, you are going to have to touch the rules file. You probably don't need everything in there
<karooga> nhandler: is it a deal breaker though?  I'm battling to get hold of upstream.  Or should I use a patch to add the details?
<nhandler> karooga: What package is this?
<karooga> nhandler: a python handler for an fortran library http://revu.ubuntuwire.com/details.py?upid=3660
<karooga> nhandler: s/handler/bindings/
<nhandler> karooga: I'm not seeing any license in that code. I highly doubt it would get accepted in its current state
<Chris`> Ok I have finished with the debian files now and I have reuploaded :)
<Jazzva> hi, do I need e-mail addresses of all upstream authors, or will one or two be enough for debian/copyright?
<karooga> nhandler: the upstream tarball doesn't have any licence.
<nhandler> karooga: I know. That is an issue. It needs to have a license in it
<karooga> nhandler: I agree, that's why I added some lines in get-orig-source  http://revu.ubuntuwire.com/revu1-incoming/ppgplot-0901150900/ppgplot-1.3/debian/rules
<nhandler> I don't think you are allowed to simply coppy /usr/share/common-licenses/LGPL-2.1 to the source.
<mok0> nhandler: you're not
<nhandler> I know mok0
<mok0> karooga: you have to ask upstream to include a license file
<mok0> karooga: COPYING or whatever
<karooga> nhandler: this is what ScottK suggested I do...
<karooga> mok0: upstream is being uncooperative :-(
<ScottK> mok0: You can repack the tarball to add license if needed.
<mok0> karooga: then we can't distribute the software
 * ScottK got one in the archive that way.
<ScottK> If it's clear what the intended license is.
<ScottK> You can't just make one up.
<nhandler> ScottK: I don't think it is clear
 * JontheEchidna makes up the rainbow unicorn license
<karooga> ScottK: hehe... no it's not made up.
<nhandler> ScottK: There are no license headers and no mention of the license in the readme or anything
<mok0> Correct, I checked it too
<karooga> ScottK: I had coms with upstream before he went silent.
<mok0> There's nothing outside debian/ saying what the license is
<karooga> that was about 3-4 months ago
<mok0> karooga: I've had to abandon packages where upstream was not responsive
<mok0> karooga: it's no fun
<karooga> mok0: so what are my options? tarball myself and dump on launchpad or sourceforge?
<mok0> karooga: you mean distribute it yourself?
<karooga> mok0: yup?
<mok0> karooga: It's a possibility
<karooga> mok0: it's really only 3 files in total anyway...
<karooga> I think I'll try sending a forth email to upstream
<mok0> karooga: we're talking about ppgplot, right?
<karooga> mok0: yes
<mok0> karooga: tbh, if you need it for your own work, just package it and use it locally. There's a ton of plotting packages in Ubuntu, some much more advanced. Yes I am brutal :-)
<karooga> mok0: perhaps I can make it easy for him by including a patch to his code... maybe even a script to repackage it.
<mok0> karooga: well that is a good way to get things done
<mok0> karooga: you are really in love with this software, huh ;-)
<karooga> mok0: I'm already doing that :-)  but there's no coolness factor for getting your first package accepted.
<mok0> karooga: I understand, but there's LOTs of other software that you could package
<mok0> karooga: you might even "hijack" a package from REVU, many are abandoned there
<karooga> mok0: hehehe... it's a love-hate relationship - I hate the C/fortran interface.
<karooga> mok0: loving the python one.
<mok0> karooga: ok! Just probing you...
<maxb> Do people manually sweep revu for packages that are outdated, or is it worth pointing out, for example, that the unetbootin in revu is older than the one in jaunty?
<maxb> s/manually/regularly/
<karooga> mok0: I did start http://revu.ubuntuwire.com/details.py?package=pyephem  but realised I had to package the library separately
<nhandler> maxb: Usually, when a MOTU reviews a package, they check if it is the most recent version before advocating
<mok0> karooga: ok, anyways, since you are keen to do work, while you are waiting for an answer to your ppgplot patches, I am sure there are REVU uploaders that could use assistance pushing packages through. Look for old ones in the "Needs Work" section and contact the packager if you can take over
<maxb> yup, but what about discarding unreviewed obsolete packages?
<mok0> maxb: what do you mean?
<nhandler> maxb: They would have had to have been reviewed in order for someone to notice it was old ;)
<karooga> mok0: cool beans - any recommendations off hand?
<mok0> karooga: it depends on your interest
<maxb> Well, if the version in jaunty is greater than the version in revu, it would be reasonable to semi-automatedly archive them?
<mok0> karooga: there's one called python-crontab that even has one advocate
<nhandler> maxb: If it is in Jaunty, it shouldn't be on REVU
<nhandler> maxb: REVU is only for brand new packages
<maxb> Well that's the point. I'm asking if it's useful to point out such erroneous packages, and if so, how is best.
<mok0> karooga: ah, python-crontab is not that old
<nhandler> maxb: Poke a MOTU. They can then archive the upload on REVU
<mok0> karooga: python-polib is old and has a not-answered review
<maxb> MOTUs, consider yourself poked re http://revu.ubuntuwire.com/details.py?package=unetbootin to be archived :-)
<mok0> maxb: why?
<karooga> mok0: great thanks.  Will look into them.
<nhandler> mok0: He said it was in jaunty
<mok0> ah I see
<maxb> in jaunty with greater version
<nhandler> mok0: You want to handle it? If not, I'll do it in a minute or two
<mok0> maxb: thanks. Done.
<mok0> nhandler: archived
<nhandler> :)
<mok0> So, we're well into REVU day!
<nhandler> mok0: I still have 11 more hours
<karooga> mok0: I see there is a newer version of python-polib out.  Does one work on newest version and archive the old one?
<mok0> karooga: you'd just package the newer one and overwrite it
<nhandler> karooga: When you upload a newer version to REVU, it will replace the older one
<mok0> we often ask uploaders to upgrade
<karooga> nhandler: brill!
<nhandler> That is another reason why a debian/watch file or a get-orig-source rule is so great
<nhandler> karooga: ???
<karooga> nhandler: a big thumbs up to the guys working on revu code :-)
<nhandler> karooga: Thank RainCT, not me
<karooga> is an MIT licence a problem?
<Chris`> http://revu.ubuntuwire.com/details.py?package=grdc -- If you have the chance, can you review this for me please?
<mok0> karooga: I hope not, otherwise we can't run the X-server
<mok0> ;-)
<mok0> Chris`: I'll take a look
<Chris`> mok0: Thanks :)
<iulian> Could someone please unsubscribe uus from bug #317544?
<ubottu> Launchpad bug 317544 in eqonomize "Please sync eqonomize 0.6-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/317544
 * nhandler goes to look
<mok0> iulian: can't you do that yourself?
<iulian> mok0: I'm not a member of uus.
<iulian> So, I cannot.
<mok0> iulian: ah, but you should be
<mok0> iulian: you're MOTU now
<nhandler> iulian: Done
<iulian> nhandler: Thanks.
<nhandler> You're welcome. Now go and join UUS
 * iulian looks for an uus admin.
<nhandler> iulian: Bug persia about it
<savvas> what's your opinion on debhelper and debian/compat version? should I use as minor as possible for backport reasons?
<jpds> nhandler: You can't file bugs against people tho.
<nhandler> jpds: I wonder what the LP admins would say if I created a bug report about that
<Chris`> mok0: I have just fixed a Gnome --> GNOME bug, I'm going to reupload assap
<persia> iulian, You want to be a member?
<RAOF> savvas: You don't need to worry about backporting; hardy has debhelper 7 in backports, too.
<savvas> RAOF: there's no obligation to put up the newest debhelper version, right?
<savvas> I mean, I've looked in debian and ubuntu policies, couldn't find anything
<RAOF> savvas: No.  You don't have to use compat 7.
<iulian> persia: Yes, please.
<persia> Done.
<iulian> That was fast. Thanks.
<RAOF> savvas: You might _want_ to use compat 7, so you can use the moderately awesome dh tool.
<RAOF> Like CDBS, but without so much crazy arcane makefile hunting!
<savvas> new features?
<savvas> hm..
<persia> iulian, Thanks for helping out: closing all the bugs for which we have  fix already available is fairly high priority :)
<superm1> RAOF, is it in misc different backports for earlier releases so you dont lose backportability?
<savvas> RAOF: Could you point me to a link with more information? :)
<RAOF> superm1: It certainly works back to hardy; I'm not sure if dh 7 is backported to gutsy or earlier, though.
<superm1> RAOF, oh an you just said that above. sorry i should have read scrollback more than 3 lines up
<RAOF> savvas: The dh manpage is pretty good http://manpages.ubuntu.com/manpages/jaunty/en/man1/dh.1.html
<maxb> rmadison says no backports other than hardy
<savvas> ok thanks
<mok0> Chris`: ok, I attached my review!
<Chris`> mok0: Thanks a bunch :)
<karooga> In the upstream tarball, is the licence in COPYING or LICENCE? or does it not really matter too much as long as it's there?
<Chris`> karooga: I'd assume as long as it's there it should work but wait for a proper MOTU to answer ;)
<karooga> Chris`: yeah, that's my gut feeling too.
<nhandler> karooga: If it is there, you are fine. The name doesn't matter. While you are at it, try and get license/copyright headers for the actual script too
<karooga> nhandler: i will do.
<karooga> nhandler: I see revu complains about copyright in the examples - is this an issue?
<nhandler> What examples karooga? And what does it complain about?
<karooga> nhandler: I should say the complaint is "*No copyright* UNKNOWN".  The examples are are example scripts shipped with package.
<karooga> nhandler: http://revu.ubuntuwire.com/report.py/legal?upid=4490
<nhandler> karooga: It is complaining about the scripts not having proper license/copyright headers
<karooga> nhandler: yeah.  But am I just being academic about wanting to fix them too?
<nhandler> karooga: You personally can't fix it. Upstream would need to do that. The headers aren't as important as including a license in the source, but some MOTUs don't like packages without headers
<karooga> nhandler: cool
<karooga> thanks for the help this evening nhandler, mok0 and Chris`.  Lights out time.
<Chris`> karooga: Nos da ;)
<LaserJock> what the way to enter a directory before running make in debian/rules?
<DktrKranz> jpds, I hadn't the chance to look at new launchpadlib feature in ubuntu-dev-tools, how can I use requestsync to avoid "IOError: No credentials found" each time?
<RAOF> LaserJock: cd dir && $(MAKE) ?
<jpds> DktrKranz: Get the latest version in jaunty.
<RAOF> Other options probably include $(MAKE) -C $DIR
<DktrKranz> jpds, I've it already
<jpds> DktrKranz: 0.55?
<DktrKranz> yes
<jpds> DktrKranz: OK; look at: man manage-credentials
<DktrKranz> I launched manage-credentials as suggested, imported credentials but it still fails with IOError
<DktrKranz> probably I don't use it correctly
<jpds> DktrKranz: Where did your credentials get saved?
<jpds> DktrKranz: It ought to be: ~/.cache/lp_credentials/ubuntu-dev-tools-write_public.txt .
<DktrKranz> /home/dktrkranz/.cache/lp_credentials/ubuntu-dev-tools-write_private.txt.
<pochu> does that belong to .cache or to .config?
<jpds> DktrKranz: Odd, it's working here..
<jpds> pochu: .cache.
<DktrKranz> jpds, I re-launched manage-credentials with -e parameter and this time it worked
<jpds> DktrKranz: Hmm, didn't use that for my token.
<jpds> DktrKranz: Can you check if /usr/share/ubuntu-dev-tools/common.py has something like: http://pastebin.ubuntu.com/105356/ ?
<DktrKranz> jpds, it has. My error was probably due to the fact I played with my environmental variables such as DEBEMAIL
<jpds> DktrKranz: Ah, ok.
<DktrKranz> I'll try to have a look tomorrow
<DktrKranz> with a  clean environment
<jpds> Report any bugs/errors, I'll fix them :)
<DktrKranz> sure :)
<Skiessi> hey
<Skiessi> can I ask here for a package to be upgraded?
<nhandler> Skiessi: It would be best to file a bug report about it on Launchpad
<Skiessi> yes but I'm not the bug-reporting-in-launchpad type
<Skiessi> I'll just mention it here and be wondering in a few years why they still haven't updated it
<quadrispro> nhandler: thank you very much for your feedback! (you're right, and finally I've attached an ubuntu-to-ubuntu.debdiff to the last merge I've worked on :))
<nhandler> I'm glad to hear that quadrispro
<nhandler> I have no doubt that you will make a fine MOTU
<nhandler> Keep up the great work
<quadrispro> nhandler: thanks a lot
<Chris`> Hello can someone explain to me how to build my debian/watch file?
<pochu> Chris`: look at uscan(1), it has some examples
<Chris`> uscan(1)?
<pochu> uscan's manpage (section 1)
<nhandler> Chris`: http://manpages.ubuntu.com/manpages/jaunty/en/man1/uscan.1.html
<Chris`> Ok thanks pochu & nhandler
<pochu> yw
<pochu> hey nhandler :)
<nhandler> Chris`: There is also https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
<nhandler> Hi pochu
<pochu> didn't we have a cool bot for manpages?
<nhandler> Not in here
<nhandler> I know I added manpage support to my bot
<pochu> ah ok
<Chris`> nhandler: I've found the recipes guide to be absolutely no help at all regarding Debian/watch =x
<nhandler> What didn't you like about them Chris` ?
<Chris`> That they didn't work :)
<Chris`> Ah the manpages are helping though
#ubuntu-motu 2009-01-16
<nhandler> Chris`: What part didn't work, they look pretty accurate
<Chris`> Under method: sf.net/grdc doesn't exist
<Chris`> It's a sf project however
<nhandler> Where does it say sf.net/grdc?
<nhandler> I see sf.net/mooedit
<Chris`> My project is grdc
<nhandler> Chris`: sf.net/grdc won't work in a browser. Did it work in the watch file?
<Chris`> Nope
<pochu> try "uscan --verbose" from debian/..
<Chris`> http://pastebin.com/d6cdb14a
 * directhex uses mirrorservice for sf projects, it's more reliable
<pochu> Chris`: http://sourceforge.net/projects/grcd, invalid project
<Chris`> http://sourceforge.net/projects/grdc <----- Works for me =\
<pochu> ah, I typoed it
<Chris`> Anyway I've fixed it but I don't find that guide too user friendly
<pochu> feel free to improve it :)
<nhandler> Chris`: Look at some of the irc logs from past Open Weeks and Developer Weeks. I think we had a few guides that covered watch files
<Chris`> Now I'm tasked with a manpage, again, the wiki wasn't much help do you know for any other resources? =\ The wiki was far too confusing
<Chris`> When writing manpages should I use American or British English?
<jmarsden|work> Chris`: Either one, but avoid obvious Americanisms or Britishisms -- you are writing for an international audience.
<Chris`> How can I use the word utilise?
<jmarsden|work> Maybe use the word use instead? :)
<Chris`> Too boring but OK
<jmarsden|work> The simpler the language you use the easier you make translation into other languages, too.
<Chris`> You can get French manpages?
<jmarsden|work> Sure.
<Chris`> Cool well I just authored a file called debian/manpage
<Chris`> What should I save it as when using pod formatting?
<jmarsden|work> I'm not sure... I've only ever used pod format within a Perl script...
<jmarsden|work> Is there anything in https://wiki.ubuntu.com/DocumentationTeam/StyleGuide about different documentation formats??
<jmarsden|work> Might be worth a look, anyway.
<Chris`> I think that I have finally finished that binary :D
<nhandler> This is really annoying. For some reason, ever since I went back to intrepid, I can no longer create a jaunty pbuilder. I have tried several times, but it always complains about not being able to resolve archive.ubuntu.com. Anyone have any ideas?
<Chris`> If anyone has the time could you please revu/review http://revu.ubuntuwire.com/details.py?package=grdc for me please? :)
<directhex> Chris`, avoid cockney rhyming slang in man pages, that's good advice
<Chris`> directhex: I used Cockney?
 * Chris` double checks
<directhex> nah, just following on from "<jmarsden|work> Chris`: Either one, but avoid obvious Americanisms or Britishisms -- you are writing for an international audience."
<Chris`> Ah ok :p
<directhex> in a faintly humerous mann... know what? never mind. it's late
<Chris`> Faily humourous man...page :)?
<Chris`> Ah damn, I forgot a little tiny thing
<Chris`> Gotta reupload
<Chris`> Upload finished if anyone wants to revu my package :)
<Andre_Gondim> does any motu can resolve this https://bugs.edge.launchpad.net/ubuntu/+source/deluge-torrent/+bug/316305
<ubottu> Launchpad bug 316305 in deluge-torrent "please sync to deluge 1.1.0" [Undecided,In progress]
<pwnguin> ive got a question about mono apps
<RAOF> Shoot.
<pwnguin> i assume they need to build in debian to be in the archive?
<pwnguin> even though published builds are cross platform
<RAOF> Ah, _that's_ what you mean.
<RAOF> Yes, very much so.  Everything in the archive needs to build from source, barring multiverse.
<pwnguin> do you know much about mono apps?
<pwnguin> ie paint.net?
<RAOF> A bit.
<cody-somerville> RAOF, everything needs to be built from a source package, including multiverse
<pwnguin> cody-somerville: then you'll remove pq?
<RAOF> cody-somerville: Are you _sure_? A source package, yes, but that source package can just copy binaires in place, right?
<cody-somerville> RAOF, Right
<pwnguin> well duh
<RAOF> pwnguin: Paint.net isn't _really_ a mono app; it p/invokes a bunch of windows stuff, IIRC.
<pwnguin> RAOF: it seems we have a windows forms library
<cody-somerville> However, by that definition, you would say barring multiverse and restricted
<pwnguin> which i thought meant ms only
<RAOF> No.
<pwnguin> but apparently not
<pwnguin> RAOF: does paint.net go above and beyond winForms then?
<RAOF> Yes.
<jorgenpt> I read that one guy ported Paint.net to *nix
<pwnguin> heh
<pwnguin> that one guy is probably the mono author
<pwnguin> http://tirania.org/blog/archive/2007/May-15-1.html
<jorgenpt> Yes, possibly this one; http://tirania.org/blog/archive/2007/May-15-1.html
<jorgenpt> But it wasn't public when I read about it. ^_^
<RAOF> One of the awesome things about the .NET runtime is how tremendously easy it is to call C libraries; Paint.NET does it for some stuff - calling out to native win32 libs.
<RAOF> That's p/invoke.
<jorgenpt> Is Paint.Net opensource?
<pwnguin> yea
<RAOF> Yes, I believe so.
<pwnguin> its like the only open source c# app ;)
<pwnguin> anyways
<pwnguin> keepass 2.x seems to work fine in jaunty
<jorgenpt> Paint.Net was open source until version 3.2, but has been closed since then.
<jorgenpt> Hm.
<pwnguin> heh
<RAOF> pwnguin: That was sarcasm, right?
<pwnguin> RAOF: yes
<pwnguin> well, keepass works
<RAOF> Good.  Difficult to tell on IRC :)
<pwnguin> but the c# part was sarcastic
<pwnguin> hence the ;)
<pwnguin> anyways, there's no keepass package yet. if i can figure out how to build from source
<pwnguin> it'd be nifty to have that in jaunty as well
<RAOF> What's keepass?
<pwnguin> its a cross platform keyring, really
<pwnguin> you can put passwords etc in it
<pwnguin> the benefit is that unlike say gnome-keyring, i can put credentials in a database and share them with my coworkers
<pwnguin> right now we have a stupid pgp encrypted file
<pwnguin> that lists notes, account names and passwords
<pwnguin> keepass basically formalizes this practice
<jorgenpt> Ã.o
<pwnguin> anyways, getting it into jaunty would probably help convince my team to adopt it
<pwnguin> one of my problems is i have no idea how to build mono apps though =/
 * pochu didn't get the difference between gnome-keyring and keepass
<pwnguin> keepass runs on windows and osx
<pochu> yeah, I mean the credentials and database you mentioned :)
<RAOF> pwnguin: Generally pretty simple, depending on how friendly they are.
<pochu> gnome-keyring is just a key manager, but you can encrypt/decrypt/sign/etc files from nautilus
<pochu> it's well integrated
<pwnguin> pochu: can i add notes?
<nellery> isn't keepass already in Jaunty? http://packages.ubuntu.com/jaunty/keepassx
<pwnguin> keepassX is different
<pochu> to gnome-keyring? no, it's a keyring manager, use tomboy for that ;)
<nellery> ah
<pwnguin> its something like a fork of the old, non .net code base
<pochu> pwnguin: oh, I thought you were comparing them as if they were similar apps, and saying which one was better :)
<pwnguin> pochu: gnome keyring does what it does well
<pwnguin> it just lacks sync and cross plaformness
<pochu> I see
<pwnguin> i got a job as a system administrator recently, and we basically do everything
<pwnguin> in parallel.
<pwnguin> windows, osx, solaris, linux
<pochu> with gnome-keyring you can synchronise keys with a keyserver, but I guess that's not what you want :)
<pwnguin> we need more than rsa encryption keys
<pwnguin> pochu: in jaunty, there's a gui, that has "passwords"
<pwnguin> pochu: do you know a way to actually add such a password?
<pochu> wait, I was confusing seahorse and gnome-keyring!
<pwnguin> seahorse, the browser?
<pochu> no, the key manager
<pochu> actually, the old gnome-keyring has been integrated into seahorse
<pochu> that's probably the gui you're talking about
<pochu> which has a passwords tab
<pwnguin> yes it does
<pwnguin> the tab doesn't seem to work though
<pochu> it does here
<pochu> and I have a few passwords
<pochu> the root password and mail account passwords for evolution
<pwnguin> i cant add new ones though =/
<pochu> yeah, I don't see how to add new ones from seahorse itself
<pochu> you can from applications that use gnome-keyring though
<pochu> e.g. if you create a mail account in Evolution, it will ask you if you want to store it in the keyring
<pwnguin> pochu: right, but if i wanted to say store a login for a windows box
<pochu> I see
<pwnguin> someone would have to bother patching tsclient
<pochu> so your use case is that you don't want gnome-keyring for access some applications that use it, but rather to store securily a set of passwords
<pwnguin> indeed
<pwnguin> its a popular use case
<pochu> yeah
<pwnguin> someone was saying keepass is in the top 10 sf projects
<pwnguin> well, its in the top 50 right now
<pwnguin> pochu: but my use case also involves sharing those secrets with a limited set of people, who might not be running linux / ubuntu
<pwnguin> i don't think the guy in charge of admining the windows class servers is about to accept "run GNOME" as a solution
<pochu> pwnguin: looks like there's an API to gnome-keyring to add passwords, so it would be a matter of extending Seahorse to allow that: http://live.gnome.org/GnomeKeyring/StoringPasswords
<pochu> yet, that wouldn't solve your other problem...
<pwnguin> pochu: im sure. but unless it uses schnier's format underneath and didnt tell anyone
<pwnguin> its yet another incompatible tool
<pwnguin> there's another program called password safe, started by bruce schnieier, with a documented format. password gorilla uses it
<pwnguin> but sync isn't handled
<pochu> pwnguin: aha! http://bugzilla.gnome.org/show_bug.cgi?id=525832
<ubottu> Gnome bug 525832 in general "allow creation of arbitrary passwords" [Enhancement,New]
<trinitronx> I'm getting an issue with "debuild -S" where it trys to sign with the original package maintainer's gpg key.  This is even when I have specified mine with -k, and also DEBSIGN_KEYID, DEBEMAIL, & DEBFULLNAME in my ~/.bashrc.  I'm just making a quick source package for personal use, so I don't want to have to edit the debian/control or changelog files... is this possible?
<RAOF__> You can just leave the package unsigned; pass -us -uc to debuild, and it won't try to sign the source, changes respectively.
<pochu> nice netsplit :)
<pochu> trinitronx: what did you pass as -k ?
<trinitronx> my key id
<pochu> as in "dpkg-buildpackage -k4A08B2FE" ?
<trinitronx> s/dpkg-buildpackage/debuild/
<trinitronx> does debuild pass -k through?
<pochu> if you put it at the end of the call, it will pass everything to dpkg-buildpackage
<pochu> SYNOPSIS debuild [debuild options] [dpkg-buildpackage options] [--lintian-opts lintian options]
<trinitronx> hmm, maybe I should try at the end?
<pochu> try it :)
<pochu> and try it before -S too
<pochu> I've seen dpkg-buildpackage fail sometimes if the arguments were in a certain order
<pochu> e.g. dpkg-buildpackage -S -sa -us -uc would sign things, while -us -uc -S -sa wouldn't
<trinitronx> woohoo! it worked at the end :D
<pochu> :)
<trinitronx> I think I'll try changing my DEBUILD_DPKG_BUILDPACKAGE_OPTS to have that at the end too
<pochu> btw as RAOF said, you can just pass -us -uc to not sign it at all
<trinitronx> yeah, I like signing stuff though just for practice
<trinitronx> and to make sure it works ok
<pwnguin> RAOF: i see a lot of .csproj files in this thing. i assume this is visual studio?
<RAOF__> pwnguin: yah.  But I think mdtool should be able to build it for you.
<tritium> Hello.  It has been a while since I've built a package.  I used to use pbuilder, but it seems working/testing in a virtual machine, and building with a PPA is valid approach today.  Is that a fair assessment?
<tritium> I'm hoping to package the new version of ngspice, as well as hdhomerun_config_gui prior to feature freeze.
<pochu> tritium: PPA is fine, VM not so much
<tritium> pochu: not so much for what?  building?  testing?
<pochu> building
<pochu> for testing it's perfectly fine
<tritium> Fair enough.  I don't intend to use it for building.  Thanks!
<pochu> welcome :)
<tritium> pochu: well, alpha 3's kernel won't boot as a virtualbox guest, so perhaps I'll consider another approach.
<pochu> tritium: try with alpha 2 ;)
<tritium> I see the same caveat for alpha 2: http://www.ubuntu.com/testing/intrepid/alpha2 (bug 243677)
<ubottu> Launchpad bug 243677 in kvm "intrepid kernel 2.6.26-2-generic won't boot as kvm guest" [Undecided,Fix released] https://launchpad.net/bugs/243677
<tritium> Sorry, but 246067
<tritium> s/but/bug
<tritium> bug 246067
<ubottu> Launchpad bug 246067 in linux "Kernel panic during boot in VirtualBox with kernel 2.6.26.*-generic" [High,Fix released] https://launchpad.net/bugs/246067
<pochu> I have a jaunty VM, but I think I installed it from alpha1
<pochu> or a daily image, rather
<pochu> ~/.VirtualBox/jaunty-alternate-i386.iso
<pochu> but it won't be available on cdimage.u.c anymore, as it's a bit old ;)
<tritium> :)
<tritium> Perhaps I'll not worry about the VM for now, and just worry about building the packages.
<pochu> that's a good start :)
<tritium> Thanks again!
<pwnguin> RAOF__: is mdtool part of a package?
<pwnguin> ah
<pwnguin> monodevelop nvm
<dholbach> good morning
<fabrice_sp> morning dholbach !
<iulian> Morning dholbach, fabrice_sp.
<fabrice_sp> Hi iulian :-)
<iulian> How's it going guys?
<dholbach> hiya iulian, hi fabrice_sp
<dholbach> iulian: very good, just waiting for the coffee to be ready :)
<fabrice_sp> iulian, very good too: it's friday! :-) (and waiting for the chocolate :-) )
<iulian> Heh, that's good.
 * pochu waves good morning
<iulian> Hiya pochu.
<dholbach> hey pochu
<fabrice_sp> Hi pochu ;-)
 * iulian yawns
<pochu> hey iulian, dholbach and fabrice_sp :)
<tritium> Good morning, dholbach.
<dholbach> hey tritium
 * pochu just read his motu application again
<pochu> nice memories :)
<ScottK> Good morning dholbach
<dholbach> hey scottK
<pochu> hiya ScottK
<pochu> iulian: BTW, congrats for your MOTU-ship! :-)
<ScottK> heya pochu.
<iulian> pochu: Thanks ;)
<slytherin> any python gurus here?
<liw> slytherin, perhaps
<liw> slytherin, but us non-gurus might be able to help you too
<slytherin> I want to write a simple python script which downloads files from a site based on certain parameters. Also the site uses http basic authentication. What modules should I look into?
<trinitronx> i don't know python... but I do know curl should be able to do that.  Look for a python curl module?
<liw> slytherin, from file:///usr/share/doc/python2.5/html/lib/index.html I would suggest urllib2 as a starting point
<slytherin> ï»¿liw: ok. looking into that.
<lynxie> how do i cleartext sign the ucoc using a key different of the default one, gpg --clearsign UbuntuCodeofConduct-1.0.1.txt automatically uses the default
<lynxie> am i overlooking it in the man page?
<slytherin> lynxie: look for an option key-id
<lynxie> slytherin, thanks, it turned out to be gpg --default-key id --etc.
<didrocks> morning
<didrocks> dholbach: happy birthday :)
<quadrispro> thank you dholbach ;)
<iulian> Hmm, birthday?
<iulian> Yay!
<iulian> Happy Birthday dholbach!
 * iulian has just seen planet ubuntu.
<stefanlsd> dholbach: apparantly, alles gute zum geburtstag!
<pochu> dholbach: happy birthday :)
<dholbach> didrocks, iulian, stefanlsd, pochu: THANKS A LOT GUYS
<dholbach> stefanlsd: good german! :)
<stefanlsd> dholbach: haha. i am taking german lessons.
 * dholbach hugs y'all
<dholbach> stefanlsd: how does it go? :)
 * pochu is taking the TOEFL tomorrow
<pochu> and my English sucks :(
<dholbach> pochu: no it doesn't - I'm sure it'll work out well!
<stefanlsd> dholbach: umm. brauchbar.  sprechen is leicther as schreiben. my grammer is terrible!
<stefanlsd> ist / als
<stefanlsd> heh
<stefanlsd> and spelling for that matter
<dholbach> stefanlsd: German grammar is a bitch :-/
<pochu> I hope so :) at least I need to obtain more than 70 out of 120... the requirement could be worse :)
<stefanlsd> dholbach: yeah. i always thought native german speakers are lucky that they just get it, but i was thinking bout learning english, and im not sure i would want to do that either.
<stefanlsd> soo, whats the birthday plans??
<dholbach> stefanlsd: whenever somebody says "hey, I'm learning German" I have to stifle a "you have my sympathies" :)
<dholbach> stefanlsd: I think this will be the first time where I move my birthday party into summer - I really couldn't get myself to organise a party this time when it's freezing outside :)
<dholbach> so in summer, I'd like to have a big party with barbecue-ing in one of Berlin's parks ... or something like that
<dholbach> (that won't keep me from going out tonight though :-))
<didrocks> <dholbach> stefanlsd: whenever somebody says "hey, I'm learning German" I have to stifle a "you have my sympathies" :) -> that's why, even after 6 years of German learning, my level is so bad :/
<stefanlsd> didrocks: yeah, gotta practice..
<didrocks> stefanlsd: thinks it's too late, 5 years without practicing...
<stefanlsd> dholbach: mm. cool. u gotta let us all know. i wanna go visit germany sometime soon again
<dholbach> didrocks: ask Seb - he learned it in school for like 23 years (I might be exaggerating), but he does not speak German very well :)
<dholbach> stefanlsd: let me know when you make it to Berlin :)
 * dholbach won't repeat the one sentence Seb liked saying a lot in here :)
<stefanlsd> dholbach: was in nuremberg last time. was awesome. will def visit berlin thou.
<dholbach> stefanlsd: nice... although both are very different :)
<didrocks> dholbach: you have to repeat it. you told too much or not enough :)
<dholbach> didrocks: ask him about his favorite german sentence
<didrocks> dholbach: ok, I will ^^
<dholbach> stefanlsd: do you know of any plans of the ZA loco participating in the Global Bug Jam?
<stefanlsd> dholbach: no fixed plans atm, but i did bring it up in the channel yesterday about holding one in johannesburg.  i'll get something going
<dholbach> stefanlsd: you ROCK
<dholbach> that's awesome!
<DktrKranz> dholbach: we had a "demo" one in december, just to see how to organize a wider one, we plan to have another one soon, probably we can partecipate in the global bug jam too
<dholbach> DktrKranz: that's excellent!
<dholbach> DktrKranz: where are you going to have it?
<siretart> mr_pouit: fixed avidemux uploaded, current dep-waited on your x264 upload (which is in NEW)
<siretart> hi dholbach!
<dholbach> hi siretart
<DktrKranz> dholbach: probably at University of Boulogne
<DktrKranz> there are some DDs living there, they could lend a hand too
<dholbach> nice
<DktrKranz> so, we can squash some RCs too :)
<dholbach> :)
<slytherin> liw: any idea how can I download a certain file using urllib2? I could not find any method that talks about saving data form the url.
<dholbach> slytherin: urllib.urlretrieve?
<slytherin> dholbach: is that method present in urllib2 as well?
<dholbach> oh, it's not
<liw> slytherin, urlopen gives you a file-like object, so you can use its read method to read the entire contents of the page
<liw> slytherin, http://paste.ubuntu.com/105464/
<slytherin> liw: right, but then I will need another handler to save it to a local file.
<liw> sure
<liw> that's easy, though
<dholbach> import urllib2; f = open("content", "w"); f.write(urllib2.urlopen("http://www.ubuntu.com").read()); f.close()
<dholbach> or some such
<slytherin> dholbach: hmm , let me try.
<liw> that's one way of doing it, though I prefer to split stuff into simpler statements, so that _when_ there is a problem, it's clear what part causes it
<liw> http://paste.ubuntu.com/105466/
<dholbach> slytherin: listen to liw - he has clearly debugged more code than I did :)
<directhex> dholbach, is there anywhere i should be telling people what they'll need for me & meebey's session next week?
<dholbach> directhex: what do you mean? like preparation the audience needs to do?
<dholbach> directhex: or a mail from me explaining what's going to be going on?
<dholbach> (for the presenters)
<directhex> dholbach, in terms of "have a jaunty chroot with mono-devel" so no time is wasted installing it
<dholbach> directhex: if you could create a small page with instructions at UbuntuDeveloperWeek/MonoPreparation I'll link to it from various places and announce it
<slytherin> liw: that worked for text file at least. Now I have to check if t works for binary files.
<stefanlsd> dholbach: http://wiki.ubuntu-za.org/GlobalBugJam   - i also posted to the list
<dholbach> stefanlsd: nice
<dholbach> now you just need to add yourself to https://wiki.ubuntu.com/GlobalBugJam too :)
<stefanlsd> kk :)
<highvoltage> stefanlsd ftw
<stefanlsd> highvoltage: heys! you gonna be around for the jam?
<highvoltage> stefanlsd: I'm not sure. I'd like to be there, I'm in Cape Town for most of feb
<stefanlsd> highvoltage: ooh. then we have a cape town one also :P
<mok0> Today is REVU day!
<mok0> We have > 100 packages waiting for review!
<highvoltage> stefanlsd: not a bad idea... I'm not sure how to host one though
<stefanlsd> highvoltage: there's a wiki page on it, https://wiki.ubuntu.com/RunningBugJam
<stefanlsd> highvoltage: also, check out the bugsquad pages. it doesnt need to be technical at all
<stefanlsd> highvoltage: ordinary people reporting bugs, confirming bugs, traiging bugs, finding out more information bout bugs
<highvoltage> stefanlsd: awesome. perhaps I can do it as part of a clug meeting. I'll see where I am at that stage and then we can do it close to the same time
<stefanlsd> highvoltage: kk. is sometime between the 20-22 feb
* mok0 changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a  merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | http://revu.ubuntuwire.com - Today is REVU Day, go review! :)
<highvoltage> stefanlsd: ok, that won't work for a clug talk, but I'll get them involved anyway. I think the saturday will work best there
<stefanlsd> highvoltage: cool. see who u can grab, and maybe see if CT has any interest. can be as simple as meeting at a coffee shop and just hacking away
<highvoltage> stefanlsd: ok, cool
<Elbrus> Does anybody know a simple way of telling which files are loaded by an application? I think I am missing a dependency in my package winff (BTS 511505) but don't know how to find it. (winff is needs X11, I don't know how to use a chroot to test it) Any ideas?
<persia> Elbrus, lsof can tell you which files a process has open, and strace can tell you which files are opened during a run.
<Elbrus> persia: thanks
<persia> Elbrus, http://www.debian-administration.org/articles/566 describes how to run an X program in a schroot.
<persia> Hrm.  xhost + doesn't seem best though :(
<directhex> i resort to Xnest
 * mok0 reviews bcv4
<dholbach> sebner, apachelogger: do you know of any plans of the Austrian mafia to participate in the Global Bug Jam?
<mok0> Is the mafia going to the bug jam?
<mok0> *shudder*
<dholbach> mok0: there's nothing about "making offers that you can not refuse" in the CoC ;-)
<mok0> :-) hehe
<mok0> "This bug.... it's business. Not personal"
<dholbach> hehe, exactly
<dholbach> not sure what our Italian friends in the channel think about it :)
<mok0> They're busy skateboarding around the sewers...
 * mok0 reviews ultrastardx
<mib_dkvv32kr> hi
<shankhs> I am new to all this developing stuff Can you please suggest me some tutorial or something to begin with...(i know c/c++)
<liw> shankhs, have you read https://wiki.ubuntu.com/ContributeToUbuntu ?
<james_w> urgh, using "locate" in configure to find the headers it needs
<Chris`> When someone has the time, can you please review my first 2 packages to REVU: http://revu.ubuntuwire.com/details.py?package=grdc-gnome & http://revu.ubuntuwire.com/details.py?package=grdc
<Chris`> Hello are there any MOTUs available for a review of my packages?
<fabrice_sp> Hi Chris. I'm not a MOTU, but I can have a look at your package
<fabrice_sp> Chris`,
<Chris`> You are able to review or just give out pointers? :)
<fabrice_sp> I'm able to review
<Chris`> http://revu.ubuntuwire.com/details.py?package=grdc-gnome & http://revu.ubuntuwire.com/details.py?package=grdc
<fabrice_sp> just give me the url
<fabrice_sp> ok
<Chris`> One is reliant on the other one
<fabrice_sp> which one is first?
<fabrice_sp> grdc?
<Chris`> grdc is the first
<Chris`> Yeah
<fabrice_sp> ok
<fabrice_sp> I'll begin with this one
<Chris`> goodluck :)
<fabrice_sp> :-)
 * Chris` knows when he is in the company of geeks, most of us insist on using the -'s :P
<jreinhardt> Hi everybody. Can someone please review my package of pgfplots:
<jreinhardt> http://revu.ubuntuwire.com/details.py?package=pgfplots
<jreinhardt> I addressed all mentioned issues. But if someone could check whether I got the watch file and the tex stuff right, I would be thankful.
<fabrice_sp_> Chris`, I've been able to have a look before I left (compiles fast! :-) ) to grdc: it looks very good!. I just put some comments
<fabrice_sp_> Chris`, nice job! I'll have a look at the other one when back. CU
<Chris`> fabrice_sp: Great thanks :)
<Chris`> See ya
<RainCT> bobbo: REVU has a ubiquity command (which is broken right now, but well :P). perhaps you want to add to the ubuntu/LP thing you say you're working on
<bobbo> RainCT: have you got a link?
<RainCT> bobbo: http://revu.ubuntuwire.com/ubiquity-plugin.py
<bobbo> RainCT: I'm yet to talk to Jorge about getting it properly "started", but something should be happening "properly" soonish
<bobbo> RainCT: having a look now :)
<albuntu> hello to all
<albuntu> hello to all
<albuntu> i wanted to ask if someone can help me on how to edit the gnome panel via terminal
<Chris`> albuntu: I think you're more likely to get answers over in #ubuntu rather than #ubuntu-motu
<albuntu> Chris`: ok sorry. i tried there but i got no response
<albuntu> anyways thank you
<Chris`> albuntu: What are you trying to alter anyway?
<albuntu> the gnome-panel
<Chris`> What part of it?
<laga> i just said "rotfl" out loud. help
<albuntu> i am looking i want to edit its position
<albuntu> and some things inside
<albuntu> like putting menus plasces and system in applications
<quadrispro> RainCT: hi! http://revu.ubuntuwire.com/details.py?upid=4516
<quadrispro> going away, bye :)
<Chris`> albuntu: I'm not sure about the terminal command however you could try System > Preferences > Main Menu
<albuntu> i know that but i wanted to edit it from terminal. thank you anyways :)
<ScottK> !because
<ubottu> Sorry, I don't know anything about because
<ScottK> Anyone around who can teach the bot?
<RainCT> ScottK: I guess you'll find someone in #ubuntu-ops
<ScottK> Thanks.  Trying.
<Chris`> Any reviewers out there? :)
 * ScottK tosses RainCT in Chris`s direction.
<Chris`> Diolch ScottK
 * RainCT tells ScottK that mok0 is about to beat him in the Top Commenters :P
 * ScottK is trying to get $WORK done.
<Chris`> Well, when a reviewer is free, I've got two packages that I'd really like reviewed :) (My first ones)
<RainCT> Chris`: if you point to them you may get someone interested (/me is also about to start getting some work done, btw :P)
<ScottK> !because is <reply> Just because you can't get help in #ubuntu does not make this a help channel.
<Chris`> http://revu.ubuntuwire.com/details.py?package=grdc && http://revu.ubuntuwire.com/details.py?package=grdc-gnome
<ScottK> !because
<ubottu> Sorry, I don't know anything about because
 * RainCT watches ScottK fight with ubottu 
 * ScottK needs to wait to get it approved.
<RainCT> man that uck thing has a really ugly interface :P
 * RainCT advocates it nevertheless, and now goes to do some coding
<Chris`> Excuse me but can beta software be included in the repos?
<RainCT> Chris`: yes, of course. but don't package something which crashes all the time :P
<Chris`> Ok cool
<fabrice_sp> Hi. Is there some reviewer to have a look at dvdstyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler). It only miss another advocate :-)
<Chris`> How do I label an archave called 1.0.0-BETA1b?
<Chris`> *archive
<maxb> messy, but I think acceptable as is
<RainCT> nope
<RainCT> 1.0.0~beta1 (or ~b1 or whatever)
<Chris`> RainCT: Thanks ;)
<RainCT> the "~" means "less than, before"
<Chris`> Ah ok
<RainCT> if you used "-" then the package wouldn't be updated once the final version is out
<maxb> ugh, I was so busy about thinking... yes you can have an - in the version, release is split on the final - character, that I missed that
<RainCT> hehe
<Chris`> partitionmanager (1.0.0~beta1a-0ubuntu1) jaunty; urgency=low <---- Is that acceptable?
<directhex> Chris`, looks good to me
<Chris`> Any reviewers about that could review this for me please? http://revu.ubuntuwire.com/details.py?package=grdc
<binarymutant> Hi, if anyone has the time to review my updated packages, http://revu.ubuntuwire.com/details.py?package=charm, I would be very grateful. Thanks
<RainCT> woho, my python bindings for espeak are working \o/
<binarymutant> how many advocations are needed before upload? 3? also does the advocation count restart for every different version?
<jpds> binarymutant: 2. Yes.
 * jpds => bed. Night all.
<binarymutant> night thanks
<RainCT> good night jpds
<RainCT> binarymutant: yes, it is reset whenever you upload a new revision or you get a negative advocate
<binarymutant> thanks for the info RainCT
<RainCT> yw
<Andre_Gondim>  https://bugs.edge.launchpad.net/ubuntu/+source/deluge-torrent/+bug/316305
<ubottu> Launchpad bug 316305 in deluge-torrent "please sync to deluge 1.1.0" [Undecided,In progress]
<Chris`> mok0: Hello, how are you today?
#ubuntu-motu 2009-01-17
<binarymutant> Hi, if anyone has the time to review my updated packages, http://revu.ubuntuwire.com/details.py?package=charm, I would be very grateful. Thanks
<DktrKranz> binarymutant, I'll have a look
<DktrKranz> binarymutant, commented.
<binarymutant> thanks DktrKranz
<binarymutant> which version of dh_make and lintian should I use? whichever that is in their VCS ?
<lidaobing> help review my packages: http://revu.ubuntuwire.com/details.py?package=ibus-hangul, http://revu.ubuntuwire.com/details.py?package=ibus-table-cangjie, http://revu.ubuntuwire.com/details.py?package=fqterm, thanks
<sukiminna> hello
<sukiminna> anybody here?
<HarassmentPanda> I've written a .net application and ported it to Mono to compile under Ubuntu, could any one point me in the direction of packaging the application such that it can be included in the repositories? My project is here https://sourceforge.net/projects/vscalenotes/
<hggdh> HarassmentPanda, you may statr by looking at https://wiki.ubuntu.com/PackagingGuide/
<hggdh> s/statr/start/
<HarassmentPanda> Is there an easy way to find out what dependencies a program requires?
<hggdh> and may also want to look at http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/
<HarassmentPanda> As in I got my program to run but I don't know what the actual dependencies are
<HarassmentPanda> That looks like a lot to read :-)
<hggdh> indeed
<HarassmentPanda> I don't know if I will have time to continue developing the project if I have to read all that to package it
<hggdh> you do not need to, but it helps to understand what will happen
<HarassmentPanda> So even if I package it, it may not be included in a universe?
<hggdh> the packaging guide is a brief introduction to packaging
<hggdh> if it is not (for example) free software, indeed
<HarassmentPanda> its released under the GPL
<hggdh> way to go
<HarassmentPanda> and the only libraries it relies on are SDL and mono
<HarassmentPanda> not sure of exactly which ones as I just installed everything to get it to work
<hggdh> then for sure SDL and mono<something>
<hggdh> you can use pbuilder to find out more -- the build will fail if you are missing depends
<hggdh> https://wiki.ubuntu.com/PbuilderHowto
<HarassmentPanda> is there any where I could suggest my software to be packaged by some one more experienced?
<hggdh> I guess here (not sure myself), or the ubuntu-devel-discuss mailing list, for example
 * hggdh is not a motu, so your mileage may vary
<HarassmentPanda> hu?
<ScottK> HarassmentPanda: You can file a bug against Ubuntu and tag it 'needs-packaging'.  There are people who look at those for stuff to package.
<HarassmentPanda> ok thanks
<HarassmentPanda> i'll try that first
<hggdh> thanks, ScottK
<ScottK> hggdh: No problem.
<jacob> quick question: updating a package to a new release fixes/commits all of the quilt patches in debian/patches. should quilt and the patches/ directory be dropped entirely from the new version, or left for future use?
<ScottK> Generally dropped.  Is it a KDE package?
<jacob> ScottK: nope, twitux from 0.62 to 0.68.
<ScottK> Then you can drop it.
<jacob> ScottK: ok, thanks. :)
<slytherin> is ports.ubuntu.com down? apt-get is giving timeout here.
<jussi01> could someone explain to me why the acpi update replaced all the conf files?
<jussi01> ie. http://paste.ubuntu.com/105835/
<RAOF> Because you hadn't modified them, and the maintainer had?
<RAOF> It should not be possible for an incoming SMS to lock up my phone.
<directhex> RAOF, yay for phones
<RainCT> jpds: consider catching that extension to hide the traceback
<jpds> RainCT: if cred == None: print >> sys.stderr, "Failed." ?
<RainCT> jpds: nope, that won't work.  try: [cred =....]  except IOError, msg: print >> sys.stderr, msg; sys.exit(1);
<jpds> RainCT: That works. :)
<lidaobing>  help review my packages: http://revu.ubuntuwire.com/details.py?package=ibus-hangul, http://revu.ubuntuwire.com/details.py?package=ibus-table-cangjie, http://revu.ubuntuwire.com/details.py?package=fqterm, thanks
<didrocks> StevenK: Hi, I have an issue you encountered already some days ago on gnome-games package: http://paste.ubuntu.com/105881/. Strange as the patch including launchpad-integration.h is there and applied successfully
<hyperair> what should i name a cleaned up tarball? i can't exactly call it package_version.orig.tar.gz can i?
<maxb> hyperair: You append some string to the end of the upstream version
<maxb> For example, in Debian, when the reason for repacking is to comply with the DFSG, they append .dfsg  - for a general removal of junk, .cleaned or .repack might be reasonable tokens to append
<hyperair> maxb: i need to do autogen.sh && make dist
<maxb> why do you need to do it?
<hyperair> maxb: because the upstream author decided that it was too dificult to use make dist for some reason or other
<maxb> hmm, odd
<hyperair> maxb: build fails otherwise
<hyperair> a whole lot of missing files or other
<maxb> An alternative option might be to use the original upstream tarball, and run those things at build time?
<maxb> That might be considered preferable
<hyperair> config.status: error: cannot find input file: src/Makefile.in
<hyperair> lintian spits out a lot of stuff
<hyperair> config.log in orig tarball and whatnot
<hyperair> so i was thinking, since i'm going to have to repack it to make lintian be happy, i must as well do the autogen stuff in the repack process
<hyperair> and CDBS's autotools thing only runs ./configure,which fails because the author forgot to include src/Makefile.in
<hyperair> i've emailed him thrice
<maxb> I'm not sure you should repack at all if it's just to get rid of cruft, unless the amount of cruft is huge
<hyperair> maxb: but if i want to get it through revu lintian has to be clean right?
<hyperair> maxb: also, i'll add stuff to build-dep if i need to run autogen
<maxb> Hmm, I think it's worth finding a MOTU for a definitive opinion on that. Personally I'd consider a few lintian warnings (which can be overridden) preferable to a repack
<maxb> I can't see why extra build-deps would be a problem?
<hyperair> oh right. overriding the errors. i forgot about that
<hyperair> yeah i think i'll do just that
<hyperair>  thanks
<hyperair> directhex: ping
<maxb> If you can avoid the repack, then upgrading to new upstream versions is considerably easier
<directhex> hyperair, pong
<hyperair> directhex: banshee lyrics plugin has a tarball scattered with config.status, config.log and is missing a Makefile.in. do i autogen.sh before configure, or do i repack the tarball?
<hyperair> directhex: another thing.. the version 0.6 of banshee lyrics plugin is newer than 1.0. how do i convince uscan to not take 1.0 instead?
<directhex> hyperair, which strikes you as easier to maintain, long term?
<hyperair> directhex: autogen.sh before configure, but then it'll have more build-deps
<hyperair> directhex: specifically automake1.9 or something, and that'll change when automake 1.9 gets deprecated
<hyperair> no actually i'll just depend on the latest automake and autoconf and see how it goe
<hyperair> sd
<directhex> bear in mind issues with your "clean" rule not being correct
<hyperair> directhex: what?
<directhex> hyperair, packages should be buildable twice in a row, which requires your "clean" rule to get the package back to *precisely* how it was when you unpacked. messing with autofoo inside the package increases risks of that not being the case
<hyperair> directhex: what about the whole uscan version thing? how do i prevent it from grabbing 1.0 instead of 0.6? upstream only distributes a bz2, so i suppose i'll have to use get-orig-source for a gz
<hyperair> directhex: i'll see what i can do about clean
<directhex> hyperair, broken upstream versions? hm................. dunno. sorry.
<directhex> hyperair, sounds like a pretty hard case for uscan to deal with properly... perhaps something involving dates, if it's in an ftp dir?
<hyperair> =\
<hyperair> it's a google code site
<hyperair> 0.6 comes after 1.0
<hyperair> because the upstream author is a genius like that
<laga> then yell at upstream ;)
<hyperair> laga: if yelling worked, don't you think i'd have already gotten him to use make dist instead of manually tarring his stuff?
<hyperair> laga: i even went out of my way to fix his damn stupid build system and propose a patch to him
<laga> heh
<persia> slytherin: ports.ubuntu.com should be back.
<hyperair> directhex: clean removes autom4te.cache which was included in the source tarball, but otherwise second build works fine
<hyperair> directhex: is that okay?
<slytherin> james_w: do you mind if I work on azureus?
<slytherin> I mean the merge
<james_w> slytherin: not at all
<slytherin> james_w: by the way, what is the reason vuze is demoted to suggests?
<james_w> not sure, let me look
<james_w> "Recommend vuze until we find a way to start azureus without the vuze
<james_w> +    interface."
<james_w> so I guess that is possible now?
<slytherin> james_w: yes, I am seeing some changes in Debian which introduces new wrapper script with appropriate variables to start with/without vuze interface.
<hyperair> anybody running jaunty here? can someone help me find out which package /usr/bin/csc is in?
<hyperair> nevermind, i foudn it
<slytherin> hyperair: I am running jaunty. IIRC it is the part of mono toolchain. You can search on packages.ubuntu.com
<james_w> http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition
<hyperair> slytherin: mono-devel
<hyperair> i needed it as a build-dep
<slytherin> james_w: IIRC, azureus does not work with gij, right?
<james_w> slytherin: not sure, sorry
<james_w> slytherin: check the RC bug that was fixed in the NMU
<slytherin> hmm
<hyperair> could someone review my package? http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
<mok0> hyperair, I'll take a look, if you will help me with another package in return ;-)
<hyperair> mok0: no problem
<hyperair> mok0: what's the package?
<mok0> hyperair: lemme find it
<mok0> hyperair: it's http://revu.ubuntuwire.com/details.py?package=gnome-art-ng
<mok0> Look at my comment, strangely gmcs is missing eventhough the package does pull in mono-gmcs
<hyperair> mok0: heh. i had that problem too. you need to pull in mono-devel, and then add MCS=/usr/bin/csc to configure flags
<mok0> hyperair, thanks! Will you write that in a comment to the uploader?
<hyperair> alright
<hyperair> but i'll take a look at the package and make sure that works first
<mok0> hyperair: oh, that's perfect
<mok0> hyperair: you rock as dholbach would say :-)
<hyperair> hahah thanks
<hyperair> i actually just learnt abotu this whole csc thting, because bansheelyricsplugin wouldn't build but there was a banshee binary in jaunty, so i dug that one out and took a look
<hyperair> hmm this gnome-art-ng thing is a pretty nice app
<mok0> hyperair: oh, that's good to know
<hyperair> so yeah it built
<hyperair> hehe
<hyperair> after i made the changes i posted in the comments
<hyperair> mok0: anyway how about that review?
<mok0> hyperair: thank you. I had a few troubles with your new package, see the comments
<hyperair> hmm
<hyperair> ah damnit. .svn folders eh? i didn't see that one.
<mok0> hyperair: yeah
<hyperair> mok0: should i cleanup the tarball in get-orig-source or something then?
<hyperair> mok0: regarding the errors to do with apt-get, could you update your sbuilder or something?
<mok0> hyperair: some MOTUs think it should be done; I don't care.
<hyperair> mok0: it doesn't seem to be a problem with my pacakge, but a problem with banshee
<mok0> hyperair: however, it is sloppy packaging of the tarball
<hyperair> mok0: i know. it is. i tried to get the author to use "make dist"
<hyperair> but he wouldn't listen
<mok0> hyperair: it's not a spelling mistake in build-depends versions?
<hyperair> mok0: no it's not. pbuilder works fine
<hyperair> and my pbuilder's pretty up to date
<mok0> 2.24.0 -> 2.24?
<hyperair> banshee: Depends: libgconf2.24-cil (>= 2.24.0) but it is not going to be installed
<hyperair>            Depends: libgnome2.24-cil (>= 2.24.0) but it is not going to be installed
<hyperair> that seems to indicate it's a problem with banshee's dependencies
<hyperair> but banshee installs just fine on my pbuilder
<mok0> It could have something to do with the archs
<ScottK> Maybe even 2.24~
<hyperair> mok0: what arch are you building on?
<mok0> I had to specify arch-indep
<hyperair> arch-indep?
<hyperair> where?
<mok0> hyperair: my machine is amd64, and with sbuild, it does not build arch "all" by default
<hyperair> i see
<mok0> hyperair: your package only contains arch "all", so I had to pass an "-A" flag
<hyperair> ah
<mok0> hyperair: pbuilder builds "all" arch by default
<hyperair> well mine's an x86 machine
<mok0> So sometimes, I have discovered packaging bugs that way
<hyperair> no make that an x86 installation
<maxb> Would you not always want to use sbuild -A for evaluating whether a prospective package builds?
<mok0> maxb: if it's purely arch packages, I don't need to
<maxb> true
<hyperair> mok0: regarding the build-deps.. i didn't have any versioned build-deps
<hyperair>                libgconf2.0-cil,
<hyperair>                libgtkhtml3.16-cil
<hyperair> those are the only -cil packages
<mok0> hyperair: ah, so it could be a problem with banshee's depends?
<hyperair> it could be
<mok0> hyperair: I just now updated my builder from the archive
<hyperair> if you're running jaunty, could you try installing banshee?
<hyperair> or perhaps install it in your sbuilder temporarily?
<mok0> hyperair: I'm not
<hyperair> in your sbuilder?
<mok0> hyperair: I only have a jaunty schroot
<mok0> yes
<hyperair> if it doesn't work it would be a banshee problem. otherwise i don't know what the error's about
<mok0> hyperair: I can log on to my schroot at try it
<hyperair> ah. please do.
<mok0> hyperair: it's takes a while, it has to install a ton of stuff
<hyperair> okay
<hyperair> oh and by the way, what lintian arguments did you use?
<mok0> hyperair: -I
<mok0> hyperair: that's capital i
<hyperair> i also used lintian -i on the .dsc
<hyperair> oh
<hyperair> -I
<hyperair> revu doesn't use it i guses
<hyperair> revu's lintian log is clean
<mok0> no
<mok0> ok no problems installing banshee
<hyperair> okay
<hyperair> could you try building it again then?
<mok0> In the chroot I'm in?
<hyperair> also what should i do about the build-depends-without-arch-dep lintian error?
<mok0> hyperair: use -iI it will tell you
<hyperair> not necessarily, could be a fresh chroot
<mok0> I'll try manually in the schroot I'm in right now
<mok0> hyperair: just running debian/rules build, I get this error:
<mok0> configure: error: Cannot find "mcs" compiler in your PATH
<mok0> you need to run autogen.sh?
<hyperair> yep
<hyperair> how about debuild -b
<hyperair> configure needs to be run with MCS=/usr/bin/csc
<hyperair> that's specified in debian/rules
<mok0> hyperair: it's not happening in the autogen.sh call
<hyperair> eh whoos
<hyperair> whoops*
<slytherin> If I am using cdbs to build a package and cdbs already has dependency on debhelper, do I need to add debhelper as build-dep?
<hyperair> mok0: configure still gets called after autogen.sh gets called
<hyperair> mok0: because cdbs adds some flags i think
<mok0> hyperair: http://paste.ubuntu.com/105935/
<hyperair> aah. right. i forgot
<hyperair> should i patch configure out of autogen.sh?
<hyperair> otherwise configure gets called around three times i think
<mok0> hyperair: how about using autoreconf instead
<mok0> yeah it's PITA
<mok0> hyperair: the right thing is to patch configure.ac and regenerate configure using the tools
<hyperair> patch configure.ac?
<hyperair> what do i change it to?
<mok0> hyperair: I need to see what you've done first
<mok0> hyperair: in the meantime, look at the output of my sbuild http://paste.ubuntu.com/105937/
<hyperair> mok0: did you install mono-devel on your sbuild?
<hyperair> mok0: i just tested without the whole DEB_CONFIGURE_EXTRA_FLAGS line, and it works
<mok0> hyperair: no
<hyperair> as long as mono-devel is installed
<hyperair> mono-devel is a build-dep
<hyperair> also, that's intrepid
<hyperair> in intrepid i suppose it's mono-gmcs
<hyperair> in jaunty it's mono-devel
<mok0> hyperair: it won't compile under intrepid
<mok0> hyperair: but what does it require from banshee?
<hyperair> mok0: the pkg-config file
<hyperair> /usr/lib/pkg-config/bansheesomething.pc
<mok0> hyperair: oh, that's probably in banshee-dev or something
<hyperair> banshee-1-thickclient
<hyperair> there isn't a banshee-dev
<mok0> hyperair: right, so you builddepend on that?
<hyperair> yep
<hyperair> but the problem here is that if it builds in jaunty (build-dep mono-devel) it won't build in intrepid (build-dep mono-gmcs) and vice versa
<hyperair> so how would i fix that?
<mok0> hyperair: your package should be for jaunty
<hyperair> alright, so i just don't care?
<mok0> right
<hyperair> or should i put mono-devel | mono-gmcs?
<mok0> hyperair: it can be changed if there's ever a backport
<hyperair> perhaps mono-gmcs (<something)
<hyperair> oh
<hyperair> okay
<hyperair> i'll make my next upload then
 * mok0 goes to get some coffee...
<hyperair> mok0: new upload. could you review that please?
<mok0> ok
<mok0> hyperair: is it correct that  banshee-extension-lyrics
<mok0> has arch "all" and not "any" ?
<hyperair> well
<hyperair> -cil generally has arch all
<hyperair> i tink
<hyperair> think*
<hyperair> mok0: there's actually a deb for amd64 that works on intrepid..
<hyperair> arch all
<hyperair> http://launchpad.net/~banshee-team/+archive
<mok0> hyperair: ... because mono creates bytecode for all archs?
<hyperair> yeah
<mok0> ok, so it's like java
<hyperair> yep
<hyperair> in fact, you can take bytecode compiled on windows and run it on linux
<hyperair> also gnome-sharp2 has arch=all
<mok0> yes I know it's pretty cool
<hyperair> not that i like mono =p
<hyperair> or C#
<mok0> I'm a sceptic too
<hyperair> hahah
<hyperair> i just keep my mouth shut about it. let both sides argue it out. but you won't see me programming in C# anytime soon
<mok0> hyperair: I still get those missing dependencies of banshee
<hyperair> meh damnit
<hyperair> pbuilder doesn't have any trouble
<mok0> http://paste.ubuntu.com/105958/
<hyperair> there has to be some conflict or other
<hyperair> otherwise it would be installed
<mok0> hyperair: could be that jaunty is broken somehow at the moment
<hyperair> aah
<hyperair> wait
<hyperair> wait
<hyperair> i think i might have a clue..
<hyperair> i made it depend on libgconf2.0-cil
<mok0> aha
<hyperair> yep
<hyperair> but why did it work on my pbuilder?
<hyperair> strange
<mok0> hyperair: I'll get rid of it
<mok0> and try again
<mok0> hyperair: probably the package set evolved since you last updated it
<mok0> hyperair, here goes, it's doing something more
<hyperair> okay
<hyperair> actually, should i include libgconf2.24-cil or not? since banshee includes the dependency
<mok0> hyperair: leave that dep to banshee
<mok0> ah, crashed
<mok0> with a stacktrace
<mok0> hm
<hyperair> meh
<mok0> that's weird, it's trying to open a file in my home directory
<mok0> hyperair: I'll pastebin it
<hyperair> okay
<hyperair> no actually are you sure it's trying to open a file in your home directory and not the upstream author's home directory?
<mok0> http://paste.ubuntu.com/105959/
<mok0> no mine, look here
<mok0> lines 4 and 6
<mok0> and it's spooky, my cwd is /tmp
<hyperair> your /home is /u?
<mok0> hyperair: yes
<hyperair> ah
<hyperair> to save typing or what
<mok0>  /u/mok
<hyperair> i think you might have some stray env variable
<hyperair> to do with .wapi
<mok0> hyperair: I don't even know what that is
<hyperair> wait, i've dealt with .wapi stuff before.. when packaging for archlinux
<hyperair> you have a MONO_SHARED_DIR env variable set?
<hyperair> archlinux packages generally have export MONO_SHARED_DIR=$(srcdir)/.wapi somewhere, and then rm -rf it after the build
<mok0> no
<hyperair> meh strange
<hyperair> can you grep your env for .wapi then?
<mok0> The only thing is HOME
<hyperair> that refers to /u/mok you mean?
<mok0> yes
<mok0> there's nothing with .wapi in my env
<hyperair> strange
<hyperair> wait, i thought it didn't build in intrepid
<hyperair> or do you have a home directory in sbuild
<mok0> Well, the sbuild enviroment doesn't know about /u
<hyperair> http://pkg-mono.alioth.debian.org/cli-policy/ch-mono.html
<hyperair> hmm
<hyperair> something about .wapi
<mok0> which is nice because I don't want it to fool around with my personal stuff
<hyperair> okay then
<hyperair> it seems that i need to export MONO_SHARED_DIR
<hyperair> and then remove it
<mok0> I have a dir ~/.wapi but it's empty
<mok0> Created 2008-08-19
<mok0> In fact I'll get rid of it
<hyperair> hmm i think i'll create one just to test
<hyperair> hey wait there are files in mine
<hyperair> i think i'll just clear it and leave it empty then try building in a non-chroot env
<mok0> ok
<hyperair> uh damn that doesn't work.
<hyperair> i'm on intrpied
<hyperair> intrepid*
<hyperair> how very strange. i don't get errors
 * mok0 is even more convinced that mono is evil
<hyperair> still no errors
<mok0> I'm getting a stacktrace from the _compiler_ because it can't open a semaphore file in a hidden directory in my root??? WTF?
<hyperair> lol!
<mok0> heh
<hyperair> i'm uploading another one with the whole .wapi thing fixed
<mok0> hyperair: what did you do?
<hyperair> export MONO_SHARED_DIR=$(CURDIR)
<hyperair> near the top of debian/rules
 * mok0 , your friendly neighborhood buildd
<hyperair> hahah
<mok0> hyperair: you have a ppa?
<hyperair> mok0: yes i do
<hyperair> several
<hyperair> under different teams of course
<mok0> you might try to upload it there to test build... just add ~ppa1 to the version
<hyperair> yeah i could
<hyperair> it'd have reached ppa20 by now =p
<mok0> hyperair: ah. remember to remove that libgconf-cil dep next upload
<mok0> wow
<hyperair> done
<mok0> The build succeeded now!
<mok0> although, you may need to add "libtool" to the build deps
<cody-somerville> mok0, don't we have pbuilder for test building? ;]
<mok0> cody-somerville: heh, well pbuilder is more tolerant that buildd
<mok0> cody-somerville: and in this instance, the build succeeds in pbuilder but fails in sbuild
<mok0> hyperair, are you in contact with upstream of this plugin?
<nellery> if an application has been packaged upstream, is it possible to have it copied over with the authors permission, rather than packaging it again?
<mok0> nellery: no
<nellery> mok0: so it should be completely repackaged from scratch
<mok0> nellery: of course you can take over the files in debian/
<mok0> nellery: ... and upstream should be persuaded not to ship the debian/ dir
<nellery> mok0: okay
<nellery> thanks
<cody-somerville> mok0, neat :)
<cody-somerville> mok0, We should document those cases
<mok0> cody-somerville: yes I guess
<hyperair> mok0: if upstream actually listened, i wouldn't have put in autoreconf
<hyperair> and we'd have a clean tarball
<mok0> heh
<mok0> upstream authors rarely know what is required to distribute software
<savvas> that's easy, a maintainer!
<savvas> :P
<anakron> hi all!
<hyperair> mok0: well... banshee did a pretty good job
<mok0> savvas: heh, exactly, but they should listen to that maintainer
<mok0> Of course some upstreams also maintain their software in Debian/Ubuntu
<mok0> hyperair: Banshee package is maintained by upstream?
<ScottK> \o
<mok0> heya ScottK
<ScottK> Heya
<ScottK> That was me raising my hand about being an upstream who maintains stuff in Debian/Ubuntu
<hyperair> mok0: what?
<mok0> hyperair: you said banshee did a pretty good job
<hyperair> ah
<hyperair> sebastian droge packaged it
<mok0> I see
<ScottK> What Java thing do I need to install for Firefox to believe it has Java support?
<hyperair> i think he's got commit rights to banshee heh
 * ScottK never needed Java for anything before today.
<hyperair> ScottK: sun-java6-plugin i think
<ScottK> Thanks.
<mok0> ScottK: isn't that handled by depends?
 * ScottK tries
<ScottK> mok0: No, Firefox works great with no Java.
<ScottK> It's not a depends.
<hyperair> yeah it does
<hyperair> i use it because my bank requires java in order to log into their web interface
<hyperair> pah
<hyperair> mok0: uploaded another time, this time with libtool
<Chris`> I use Java for FireGPG :-/, any reviewers free today btw? :)
<hyperair> Chris`: firegpg needs java?
<Chris`> hyperair: Yeah to clearsign messages
<hyperair> strange i thought it didn't need anything
<hyperair> other than gpg of course
<ScottK> hyperair: That was it.  Thanks.
<hyperair> well firegpg sucks anyway. it failed verification of about every clearsigned message on launchpad.net
<Chris`> I've only just got into using it
<hyperair> heh. have fun
<hyperair> ScottK: you're welcome
<mok0> hyperair: you think you could persuade upstream to put gpg clauses in the source files?
<hyperair> mok0: i wouldn't bet on it.
<mok0> hyperair: it's no blocker, but FSF recommends it
<hyperair> mok0: i came up with a patch to fix the build system, but upstream didn't reply
<mok0> hyperair: It's pretty fast to do with a script, perhaps you can send upstream a patch?
<hyperair> mok0: got an example of a script? i've never managed to script something like that
<mok0> hyperair: Hmm. I think somewhere, I'd have to browse around
<hyperair> unless you mean ( echo "copyright header"; cat file; ) > file.tmp; mv file{.tmp,}?
<mok0> hyperair: that's what I had in mind, yes, something like that
<hyperair> it seems he's got his own headers
<hyperair> =\
<hyperair> i wonder if the copyright clause should go above or below
<mok0> hyperair: that depends on how anal upstream is about his code :-)
<hyperair> heh
<hyperair> i wonder.
<mok0> hyperair: I used to have an $Id: line at the very top, but I don't use it anymore because I've converted to git for VCS
<mok0> hyperair: however, it is actually meaningful to have it in every file, given that people can grab just one source file and use it in their own project
<hyperair> what's $Id for?
<mok0> hyperair: oh, it's a macro that gets expanded by svn and CVS
<mok0> hyperair: with version, file path and stuff like that
<hyperair> into what?
<hyperair> oh
<hyperair> i see
<hyperair> so why doesn't git need something like that?
<mok0> hyperair: but it works poorly with merges
<hyperair> heheh. svn sucks for merging
<hyperair> i like bzr
<Nafallo> \o/ BAZAAR \o/
<mok0> hyperair: because git is designed to work with any type of file, and it does not touch them.
<mok0> Nafallo: Hm, I prefer git, bzr is pretty clunky in comparison IMHO
<hyperair> mok0: but if you don't put the macro then svn won't touch the files will it?
<hyperair> mok0: what's wrong with bzr?
<hyperair> i should go learn git heh
<mok0> hyperair: yes, that's right. In fact, you have to specifically turn on the feature in svn, on a per-file basis
<mok0> but CVS would just go ahead and replace every $Id: it finds
<Nafallo> mok0: to be fair, I don't really care what others use. I love bazaar myself :-)
<hyperair> ah
<hyperair> Nafallo: hear hear
<hyperair> Nafallo: it's a little hard to find a bazaar hosting server though
<hyperair> apart from launchpad
<hyperair> and launchpad sucks if you're in asia
<hyperair> slow as hell, and connection keeps breaking
<Nafallo> hyperair: I was about to say launchpad.net is quite easy to find... ;-)
<hyperair> last time i pushed something, i had to keep running break-lock
<hyperair> Nafallo: you see a few for svn and cvs and git, but none for bzr other than launchpad
<Nafallo> hyperair: not that hard to set up your own bazaar box either.
<Nafallo> trac works with bazaar... what's the issue? :-)
<hyperair> Nafallo: but i'd like to have it hosted so that others can branch it
<hyperair> and work on it
<hyperair> and so on
<Nafallo> hyperair: yes?
<hyperair> trac? isn't that something you install on some server?
<hyperair> as in not hosted elsewhere?
<spod-> hi, is there a gdb package which is compiled with thread debugging enabled?
<hyperair> spod-: i thought gdb has thread debugging enabled by default
<Nafallo> hyperair: as I said. not hard to put up your own servers...
<hyperair> Nafallo: i don't have any computer i can leave on 24/7
<Nafallo> anyway. shower.
<hyperair> no wait, actually i'm supposed to be setting up a project management server for a club i'm in, but besides port 80 i don't have anything else, and getting a subdomain seems to be hell
<spod-> excuse the multiline - i get:
<spod-> (gdb) info threads
<spod-> (gdb) thread 1
<spod-> Thread ID 1 not known.
<spod-> (gdb)
<mok0> hyperair: I think most stuff runs on port 80 just fine
<mok0> hyperair: I know git works fine
<hyperair> mok0: i haven't heard of pushing bzr through port 80
<mok0> hm
<hyperair> mok0: also, that particular port 80 doesn't really belong to me either.
<hyperair> mok0: there's a server set up... and i just hooked up my two servers behind that one
<mok0> hyperair: you don't control the server?
<hyperair> one is an ubuntu mirror
<hyperair> archives mirror
<hyperair> i don't control the main one
<hyperair> that one belongs to the lab
<hyperair> one more is the project management server i'm supposed to be setting up
<hyperair> basically if you connect to the main server using a certain hostname, the request is forwarded to one of the servers bhind it
<hyperair> so you can't access it without modifying your /etc/hosts file
<mok0> hyperair: isn't that good enough?
<hyperair> mok0: do you want everybody who wants to access the website of your project to have to modify their /etc/hosts file?
<mok0> hyperair: it means the client from the outside speaks directly to a web server you control, it sounds like
<mok0> hyperair: so the hostname is not in DNS?
<hyperair> client -> main server (i don't control this) port 80 -> one of the server's port 80 depending on hostname
<hyperair> no the hostname isn't in dns
<hyperair> meaning i can't register the archives mirror yet either
<mok0> hyperair: looks like that sysadm's got you by the balls
<hyperair> and it requires very specific configuration to get working
<hyperair> mok0: it's a campus thing.
<mok0> hyperair: if the project is official then you need to get that fixed
<hyperair> mok0: the lab owns the server, and they have a domain name.
<hyperair> mok0: i need to get a domain name from the centre for it services
<hyperair> and they're idiots who love microsoft
<hyperair> basically i just need an alias
<hyperair> alias for the domain name that's already there
<mok0> yes
<hyperair> i could of course.. sign up for some dynamic dns service
<mok0> hyperair: so they forward traffic for your domain
<hyperair> yes
<hyperair> i did the configuration for the main server regarding that
<mok0> hyperair: your server is behind a firewall I guess
<hyperair> my server accesses the internet from behind the main server
<mok0> hyperair: but through a firewall or dmz that you don't control?
<hyperair> the main server acts as that particular lab's server, as well as a NAT-enabled router (i added this), and i modified their apache configuration to forward requests made to certain hostnames
<hyperair> the main server is behind a firewall i don't control
<mok0> hyperair: It sounds like you know much more about this than I do
<hyperair> basically i made the configuration in that manner (forward requests based on hostname) so that i don't have to attempt to convince the sysadmins to modify their firewall
<mok0> hyperair: I only know that not being directly on the internet sucks :-)
<hyperair> mok0: all that i know comes from google-fu
<hyperair> ;)
<mok0> hyperair: perhaps you could get server space somewhere else for your project
<hyperair> nowhere else hosts bzr
<hyperair> other than launchpad
<hyperair> so i was actually looking into using bzr-svn
<hyperair> and then using sourceforge or google code
<broonie> Debian's alioth service hosts bzr too.
<hyperair> alioth eh?
<hyperair> i'll take a look into that one
<hyperair> does it have a server anywhere remotely near asia?
<Nafallo> bzr.gnome.org :-)
<broonie> not particularly
<mok0> couldn't you set up a bzr hosting locally?
<hyperair> mok0: yes of course. but i don't have a computer that i can leave on 24/7
<hyperair> mok0: and my home internet connection sucks.
<hyperair> think 30kB/s maximum upstream rate (from the server's point of view), and that's in-country.
<hyperair> Nafallo: then i'd have to register as a gnome project =p
<Nafallo> hyperair: ...and the server is in London
<hyperair> hahah
<hyperair> yes i've got issues checking out files from svn.gnome.org
<Nafallo> that one is hosted in north sweden iirc
<hyperair> oh
<Nafallo> lol! faik
<Nafallo> it's in London as well ;-)
<Nafallo> cvs.g.o was in Sweden I'm pretty sure :-)
<Nafallo> meeh. I don't get anything right today :-)
<Nafallo> cvs.g.o is not in Sweden :-)
<Nafallo> ah! ftp.gnome.org is in Sweden :-)
<hyperair> lol
<hyperair> mok0: regarding bansheelyricsplugin, other than the license clause, is there anything else before it can get approved?
<nhandler> Anyone feel like helping me debug a pbuilder problem in intrepid?
<DktrKranz> nhandler, which kind of problem?
<nhandler> DktrKranz: I can create a sid and intrepid pbuilder in intrepid (with backports enabled), but I can't create a jaunty pbuilder. It always says can't resolve archive.ubuntu.com (I have tried with other mirrors and gotten the same type of error)
<DktrKranz> nhandler, is debootstrap up-to-date with latest jaunty?
<mok0> hyperair: look at my comments. Almost ready
<hyperair> mok0: thanks for the review. actually the tarball was repackaged using uscan --repackage
<hyperair> mok0: also, the latest version matches 1.0
<hyperair> not 0.6
<hyperair> how do i fix that?
<DktrKranz> I've seen some problems if just symlinked with i.e. intrepid
<hyperair> 0.6 is after 1.0, as stupid as that sounds
<mok0> hyperair: I get "Bin"
<hyperair> ah right
<hyperair> i forgot to make that change
<hyperair> but assuming i make it match only numbers and dots
<hyperair> then i'd get 1.0
<nhandler> DktrKranz: 1.0.10ubuntu1~intrepid1
<lfaraone> Hi, I'm trying to get into MOTU and I'm wondering if there is any low-hanging fruit to be fixed.
<nhandler> DktrKranz: 1.0.10ubuntu2 is in jaunty
<mok0> hyperair: perhaps you can use some of the mangling rules?
<mok0> hyperair: what is the version system this upstream is using? Is he counting backwards from 1.0 :-P
<nhandler> !harvest | lfaraone
<ubottu> Sorry, I don't know anything about harvest
<hyperair> mok0: god knows. at first he was following banshee's version, then he suddenly came up with a release "0.6"
<DktrKranz> nhandler, have you full pbuilder log available?
<nhandler> lfaraone: I would check out harvest. It has a lot of low hanging fruit
<lfaraone> nhandler: hm?
<mok0> ubottu: beer > mok0
<lfaraone> nhandler: ok, thanks.
<ubottu> mok0, please see my private message
<nhandler> lfaraone: Maybe someone can get you a link, my internet is slow right now
<lfaraone> nhandler: python-low-hanging-fruit? :)
<nhandler> DktrKranz: Yeah, one second
<lfaraone> nhandler: understood
<DktrKranz> nhandler, moving to dinner, back in twenty minutes
<james_w> http://daniel.holba.ch/harvest
<nhandler> Thanks james_w
<mok0> Hm. Anyone here knows howto scroll from with screen?
<hyperair> mok0: what mangling rules can i use?
<nhandler> mok0: Easiest way is to enter copy mode
<nhandler> mok0: Ctrl+a [
<mok0> hyperair: you can run some substitutions etc. on the string that's fetched from the url, so I thought you could mangle 1.0 into something < 0.6
<hyperair> mok0: that won't be very maintainable in the long term would it
<hyperair> and how should i mangle 1.0 into lesst han 0.6?
<mok0> hyperair: s/1.0/0.01/ ?
<hyperair> hmm
<mok0> hyperair: I know, it's a hack, but what systematics is upstream using?
<hyperair> doesn't look like he's using any systematics
<hyperair> he just dishes out a version when he feels like it
<hyperair> or something
<mok0> hyperair: can we trust his code I wonder :-O
<hyperair> i'm using it, and there doesn't seem to be many bugs
<hyperair> it's just an extension for banshee
<hyperair> downloads stuff from lyricswiki and whatnot
<mok0> j/k
<hyperair> hahah
<nhandler> DktrKranz: http://paste.ubuntu.com/105996/
<mok0> hyperair: Perhaps you persuade upstream to be systematic about versions, now that his software is going into Ubuntu. He must be kinda pleased with that
<savvas> anyone good with copyrights? what are my limits if I want to make a package with the atheros madwifi-hal license? http://svn.madwifi.org/madwifi/trunk/hal/COPYRIGHT
<hyperair> mok0: i daresay that with 0.6 signifies that he's going to be using his own versions (probably incrementing?) as opposed to hooking onto banshee's versions
<mok0> savvas: it looks like clause 1 prevents us from distributing
<nhandler> DktrKranz: ~/.pbuilderrc http://paste.ubuntu.com/105998/
<mok0> hyperair: I suggest you assume that, and just mangle the one file that doesn't fit that scheme... hopefully he wont re-use version 1.0
<hyperair> heh yeah
<mok0> hyperair: document it carefull in the watch file, because anyone looking at it will wonder
<savvas> mok0: so I'm not allowed to compile and package it as a binary?
<Laney> mok0: Wouldn't it be ok for multiverse? http://www.ubuntu.com/community/ubuntustory/licensing
<mok0> savvas: well, for your own use, but otherwise not IMHO
<hyperair> mok0: okay
<mok0> savvas: that license basically says, if you find a bug, you're not allowed to fix it
<savvas> meh
<savvas> ok thanks :)
<mok0> savvas: sorry :-(
<savvas> looks like it's going to be an .sh script then :P
<hyperair> mok0: okay, now i need to use get-orig-source to repack the tarball?
<hyperair> mok0: can i just make get-orig-source do uscan --force-download --repack?
<mok0> hyperair: yes, the idea is that you fetch the tarball with uscan and then run debian/rules get-orig-source to repackage it
<hyperair> mok0: wait, that means that get-orig-source doesn't automatically download the tarball?
<mok0> hyperair: right, the rule expects the downloaded bz2 thing to be there
<mok0> hyperair: you might even provide a check :-P
<hyperair> is there any documentation about this rule? i found this: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball and it seems to imply that get-orig-source downloads the tarball
 * mok0 looks forward to source package format 3.0 where orig.tar.bz2 is allowed...
<fabrice_sp_> Hi. I've been disconnected, so I don't know if my request for review of dvdstyler has been received or not. Can someone tell me if it has been received or not?
<fabrice_sp_> (in the channel)
<mok0> fabrice_sp: I didn't see anything
<fabrice_sp_> ok. So I'll repost it :-) Thanks
<fabrice_sp_> Is there some reviewer willing to review dvdstyler? (http://revu.ubuntuwire.com/details.py?package=dvdstyler). It has already been advocated by mok0. Thanks!
<DktrKranz> nhandler, I think that has been fixed in 1.0.10ubuntu2
<DktrKranz> or at least it's a very similar issue
<Quintasan> Hello, can I ask some questions regarding debuild here or in #ubuntu?
<mok0> !ask | Quintasan
<ubottu> Quintasan: Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<mok0> Quintasan: go ahead
<Quintasan> After reading https://wiki.ubuntu.com/PackagingGuide/Basic I've tried to do the same for my program which is pretty simple (1 source file + Makefile) and upload it to ppa, however when using dput I get: "Checksum doesn't match for /home/quintasan/src/converter_1.0-1.dsc"
<nellery> if a package does not contain a license, but mentions in the README that the package is released into the public domain, does that mean that it can be packaged?
<hyperair> after removing .svn files from a source tarball, do i mangle the version to contain .repack or do i just leave it as .orig.tar.gz  (original was .tar.bz2)
* mok0 changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a  merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | http://revu.ubuntuwire.com - Go review! :)
<Chris`> If upstream has released a tarball named 0.9.9 but they intend on making a 0.9.10 tarball next, should I rename to 0.9.09 in the control file?
<Chris`> *changelog
<nhandler> DktrKranz: So should I prepare a backport for 1.0.10ubuntu?
<pmjdebruijn> Chris`: no
<Chris`> pmjdebruijn: How will the updates work properly then?
<pmjdebruijn> Chris`: huh
<pmjdebruijn> Chris`: last time I checked 10 is bigger than 9
<pmjdebruijn> Chris`: 9 isn't 90
<Chris`> pmjdebruijn: Kinda messed up numerics but that is what apt recognises?
<pmjdebruijn> Chris`: huh?
<pmjdebruijn> Chris`: why would that be messed up
<Chris`> 0.9 is bigger than 0.1
<pmjdebruijn> Chris`: version numbers aren't floats
<pmjdebruijn> Chris`: major.minor
<pmjdebruijn> Chris`: the dot a seperator... not a numeric dot
<pmjdebruijn> is a*
<pmjdebruijn> Chris`: you fundamentally misunderstand version numbers :p
<Chris`> Ah OK then, basically the same as a comma then?
<pmjdebruijn> sortof
<pmjdebruijn> Chris`: first major is checked, then minor
<Chris`> Cool well that makes sense
<pmjdebruijn> i've almost never found the need to renumber tarballs
<slytherin> ScottK: on i386/amd64, icedtea6-plugin should work just fine if you are already using openjdk. For sun jdk use the respective plugins.
<hyperair> could someone review my package please? http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
<spitfire> How to upload .orig file to PPA using dput?
<spitfire> Or anything else?
<nellery> spitfire: see https://help.launchpad.net/Packaging/PPA
<spitfire> nellery: There is no explanation how to do it.
<spitfire> I've read it.
<spitfire> And they only mentioned it is possible.
<nellery> spitfire: you don't upload the .orig
<nellery> you must package it first
<nellery> https://wiki.ubuntu.com/PackagingGuide
<spitfire> nellery: but it isn't available in ubuntu
<spitfire> I'm backporting it from debian.
<spitfire> file libmtp_0.3.5.orig.tar.gz isn't available in ubuntu, nor launchpad.
<nellery> do you mean using -sa when you build the package?
<spitfire> And it is pinted, that i *CAN* upload it.
<spitfire> nellery: here's what i did:
<spitfire> apt-get source libmtp
<spitfire> (got it from debian)
<spitfire> dch -i -l ~ppa
<spitfire> (added suffix)
<spitfire> and dpkg-buildpackage -S
<nellery> ahh
<spitfire> and that's all.
<nellery> use dpkg-buildpackage -S -sa
<savvas> spitfire: debuild -S -sa
<savvas> or that :p
<spitfire> what does -sa?
<savvas> #
<savvas> alternative version of an existing package: debuild -S -sd
<savvas> #
<savvas> brand new package with no existing version in Ubuntu's repositories: debuild -S -sa
<savvas> quoted from https://help.launchpad.net/Packaging/PPA
<spitfire> oh.
<spitfire> savvas: sorry, didn't understood/noticed
<nellery> from the manpage
<nellery> -sa    Forces the inclusion of the original source.
<savvas> that's much clearer heh
<nellery> sorry, misunderstood your question at first ;)
<savvas> spitfire: if it has important changes and fixes, you could ask for a sync to update the package from debian for jaunty :)
<spitfire> savvas: it has soem improvements, and is lot faster.
<spitfire> But I don't think there are security issues.
<spitfire> So isn't it hard to do such a bump after debianimportfreeze?
<savvas> If you can give good reasons to do it, then I believe no-one would object to include it :)
<spitfire> savvas: will do.
<spitfire> what do I have to write in the topic for a version bump?
<savvas> https://bugs.edge.launchpad.net/ubuntu/+source/libmtp/+bug/315679
<ubottu> Launchpad bug 315679 in libmtp "libmtp version bump request" [Undecided,New]
<savvas> I see that you already have :)
<spitfire> savvas: oh, I forgot:P
<spitfire> lol
<savvas> hold a sec
<spitfire> savvas: I've just included link to debian.
<savvas> spitfire: change the bug subject to this: Please sync libmtp 0.3.0-1ubuntu3 (main) to 0.3.5-1 from Debian (experimental)
<savvas> nellery: do you know if we have to subscribe someone else for a package sync?
<spitfire> ok
<savvas> spitfire: also change the description or add in a comment why do you believe it should be updated
<spitfire> savvas:ok
<nellery> subscribe ubuntu-universe-sponsors
<nellery> once they confirm it
<nellery> they will subscribe ubuntu-archive
<savvas> er.. it's in main
<savvas> ubuntu-main-sponsors then?
<nellery> ah, yes
<nellery> https://wiki.ubuntu.com/SyncRequestProcess
<savvas> thanks :)
<spitfire> savvas: I corrected one more, it is associated to the previous one: https://bugs.edge.launchpad.net/ubuntu/+source/mtpfs/+bug/301645
<ubottu> Launchpad bug 301645 in mtpfs "Please sync mtpfs 0.8+svn11-1ubuntu1 to 0.9-1 from Debian (experimental)" [Undecided,New]
<spitfire> But I bet both will get into in the next release cycle:/
<savvas> spitfire: the dependencies are satisfied, I'll confirm it
<spitfire> savvas: ?
<savvas> and it looks that they've gone a long way with fixes and device support
<spitfire> really?
<spitfire> thanks.
<savvas> spitfire: confirming means "someone else is interested in this too" :)
<spitfire> I don't think I'll use jaunty anyway.
<savvas> I'll subscribe the sponsors team and let's hope it gets fixed :)
<spitfire> Not until intel graphics drivers get fixed/use GEM properly.
<spitfire> Now I'm backporting everything possible to jaunty.
<spitfire> *hardy.
<spitfire> from jaunty/intrepid/deb-experimental.
<savvas> well actually, if this gets in jaunty, after a while usually gets backported to the LTS release (hardy)
<savvas> ok, sponsors added, have a good night!
<coppro> OO.o 3 isn't in jaunty yet? :(
<spitfire> savvas: could you also look at the second bug/bump request?
<spitfire> It's associated with libmtp;)
<spitfire> And it's transiston from SVN snapshot to a stable version.
#ubuntu-motu 2009-01-18
<savvas> coppro: I think it is: http://packages.ubuntu.com/jaunty/openoffice.org
<savvas> Package: openoffice.org (1:3.0.1~rc1-2ubuntu4)
<savvas> spitfire: bug report link?
<coppro> oh, so it is
<spitfire> https://bugs.edge.launchpad.net/ubuntu/+source/mtpfs/+bug/301645
<ubottu> Launchpad bug 301645 in mtpfs "Please sync mtpfs 0.8+svn11-1ubuntu1 to 0.9-1 from Debian (experimental)" [Undecided,New]
<spitfire> changed the topis as with libmtp;)
<savvas> spitfire: did you try to build the new version in your PPA?
<spitfire> savvas: I've built them both locally.
<spitfire> they are waaaay faster than previous ones.
<spitfire> savvas: built them using pbuilder
<savvas> spitfire: ok here's what you do: 1) bookmark https://wiki.ubuntu.com/SyncRequestProcess :) 2) since you aren't the person who submitted it, you are allowed to change the bug status from "new" to "confirmed": https://bugs.edge.launchpad.net/ubuntu/+source/mtpfs/+bug/301645/+editstatus
<ubottu> Launchpad bug 301645 in mtpfs "Please sync mtpfs 0.8+svn11-1ubuntu1 (universe) to 0.9-1 from Debian (experimental)" [Undecided,New]
<savvas> spitfire: 3) subscribe yourself in the bug 4) provide GOOD reasons except for the fact that they've released a stable version (look in their changelog, find good changes and post them in your comment).
<ubottu> Launchpad bug 4 in rosetta "Importing finished po doesn't change progressbar" [Medium,Fix released] https://launchpad.net/bugs/4
<savvas> spitfire: 5) mtpfs is in universe (see here next to the version: http://packages.ubuntu.com/jaunty/mtpfs ), so you subscribe the ubuntu-universe-sponsors at https://bugs.launchpad.net/ubuntu/+source/mtpfs/+bug/301645/+addsubscriber
<ubottu> Launchpad bug 301645 in mtpfs "Please sync mtpfs 0.8+svn11-1ubuntu1 (universe) to 0.9-1 from Debian (experimental)" [Undecided,Confirmed]
<savvas> and that's it :P
<spitfire> savvas: thanks for the guide;)
<savvas> np
<james_w> TheMuso: are you happy for me to upload the patch in bug 317496?
<ubottu> Launchpad bug 317496 in yasr "FTBFS in jaunty redefining openpty and forkpty" [Undecided,New] https://launchpad.net/bugs/317496
<TheMuso> james_w: Go for it.
<james_w> thanks TheMuso
<Laney> 'ow do lads
<james_w> 'ello Laney
<emgent> argh launchpad running slow again..
<james_w>  /. :-)
 * ScottK-desktop doesn't recall ever considering Launchpad "Not slow".
<emgent> hahah
<emgent> ScottK: the real problem now is that launchpad go in timeout..
<emgent> Please try again
<emgent> Sorry, there was a problem connecting to the Launchpad server.
<emgent> Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad IRC channel on Freenode.
<emgent> Thanks for your patience.
<emgent> what balls..
<emgent> ok I go to sleep and I will try to continue my work tomorrow.
<emgent> good night
<Laney> Who runs the rcbugs page? It seems to be not updating correctly
<Laney> showing Ubuntu versions that were superceded long ago
<james_w> I'm not sure, wgrant, you probably know?
<Laney> Oh, I think it might be targetting Intrepid still
 * Laney gets bored with triaging the list
<ScottK> Laney: It is pointed at intrepid still.
<Laney> ScottK: Do you know who to poke?
<ScottK> Laney: Just did.
<Laney> Excellent
 * Laney heads bedward
<coppro> what are the odds we'll see a backport of OO.o?
<ScottK> Slim and none unless someone shows up who is really interested in working on it and supporting it.
<coppro> :(
<ScottK> If someone were interested to actually do the work, then sure.
 * coppro checks to see if the PPA packages are working
<coppro> hmm... nope
 * ScottK considers how much he is going to worry about incompatible symbol changes in a library that has no packaged rdepends, but upstream didn't bump soname.
<coppro> last time I tried the PPA, OO.org broke, we'll see if it works now
<coppro> hmm... the PPA works
<coppro> yay
<HarassmentPanda|> I was asking about the process of getting a program which I have written considered for packaging for Ubuntu in here yesterday and some one (sorry I can't recall who) suggested filing a bug report under the tag of needs-packaging but I can't find out how to tag a bug
<HarassmentPanda|> is there any special option I have missed or somthing?
<iulian> HarassmentPanda|: You can either click on that button below the description of the bug (Update description/tags) or append /+edit to the url.
<HarassmentPanda|> iulian: Ok - this is after I have logger the bug?
<iulian> HarassmentPanda|: What is the bug #?
<HarassmentPanda|> iulian: I didn't log it yet because I wasn't sure if It was right :-)
<iulian> HarassmentPanda: Ah, this is the right way of requesting an application to be packaged.
<HarassmentPanda> iulian: ok cool, I'll log it now, thanks
<iulian> HarassmentPanda: You might want to take a look at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<lidaobing> ppa does not work now? I can't upload.
<iulian> lidaobing: What message do you get?
<lidaobing> iulian, Connection failed, aborting. Check your network (111, 'Connection refused')
<lidaobing> iulian, full information in: http://paste.ubuntu.com/106317/
<ripps> Can someone tell me if ppa.launchpad.net is down or something, i keep getting "Connection failed, aborting. Check your network (111, 'Connection refused')" from dput
<iulian> lidaobing: Odd, I've no idea.  Ask in #launchpad, maybe you'll get an answer there.
<iulian> It seems you're not the only one.
<lidaobing> iulian, thanks
<HarassmentPanda> julian: Is this right https://bugs.launchpad.net/ubuntu/+bug/318389 ?
<ubottu> Launchpad bug 318389 in ubuntu "OpenSebJ - vScaleNotes - needs-packaging" [Undecided,New]
<HarassmentPanda> iulian: sorry thought it was a j on my screen :-)
<HarassmentPanda> also does launchpad update me if the status changes?
<HarassmentPanda> ubottu: that hyperlink is wrong
<Nafallo> some might argue talking to a bot is wrong as well :-)
<HarassmentPanda> perhaps
<HarassmentPanda> strange though the bot responded and thanked me for my attention to detail
<HarassmentPanda> did you ever hear that song about the bot on irc?
<Nafallo> and that your message got escalated to the ops channel?
<Nafallo> not really ;-)
<HarassmentPanda> Any way did I log the issue correctly?
<HarassmentPanda> Is the tagging correct?
<HarassmentPanda> It was called Boten Anna by Basshunter - http://au.youtube.com/watch?v=RYQUsp-jxDQ&NR=1
<HarassmentPanda> Not sure of the language, if you look around you can find one with subtitles
 * Nafallo is sure about the language and wouldn't mind that song not to exist.
<HarassmentPanda> I take it you don't like it
 * Nafallo nods
<hyperair> is there a motu free to revu today? =p
<HarassmentPanda> what language is it btw?
<Nafallo> HarassmentPanda: .se
<hyperair> http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
<petski> I get a "connection refused" when I try to connect to Launchpad's PPA:
<petski> pet@workmate:~/work$ nc ppa.launchpad.net 21
<petski> ppa.launchpad.net [91.189.90.217] 21 (ftp) : Connection refused
<savvas> that's more of a #launchpad problem :)
<petski> hehe, you are damn right :)
<petski> thanks :)
<savvas> and it's already mentioned: < det> (can't upload to launchpad using dput, "connection refused")
<savvas> I wonder if they're creating the signatures for PPA hehe
<ripps> the server admin is drunk with his face on the keyboard
<petski> I've subscribed ubuntu-sru for a certain bug (#276603) in launchpad. According to the procedure, I have to upload my package into -proposed, but I'm not allowed to. Is this mandatory? Does anyone know the average response time for ubuntu-sru?
<laga> petski: usually, someone sponsors the package after motu-sru has ACKed it
<petski> the package is in 'main', ... so I think motu is not involved?
<petski> again, I could be asking the wrong channel :)
<maxb> petski: As you say, packages in main are better discussed in #ubuntu-devel. My guess (I can't find any official doc) would be that the procedure would go something along the lines of attaching the .debdiff to the bug and subscribing ~ubuntu-main-sponsors. It's probably worth hanging around on #ubuntu-devel to see if you can get a more definitive answer
<petski> thanks maxb !
<ia> hello. could you tell me, please, which the best way to create deb package with sources of modificated linux kernel? for example, i clone ubunut-jaunty source tree via git; it compiles successfully via debian/rules or via make-kpkg as well. But I would like to know, does exist some alternative for "make-kpkg kernel-source" via existing original debian/rules way?
<ia> by other words, what maintainer do, that user can just type "apt-get source linux-image-2.6.X-Y-<type>" and get: 1.original tarball 2.tarball with diffs 3.dir from tarball with applied diffs?
<pochu> ia: that may be better asked in #ubuntu-kernel
<hyperair> or #ubuntu-kernel
<pochu> isn't that what I said? :)
<hyperair> oh shit i read #ubuntu-devel
<hyperair> sorry
<hyperair> T_T
<hyperair> anyway pochu, would you have time for a review? =p
<pochu> hyperair: not really. what is it?
<hyperair> banshee lyrics plugin
<hyperair> http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
<hyperair> if you're not free then nevermind
 * sukiminna says is anybody here..?
<spitfire_> In ubuntu intrepid, gksu "window" is transparent. How did it change since hardy, and what do I need to have it in hh?
<sukiminna> spitfire_: i think u are in the wrong channel buddy
<spitfire_> sukiminna: what channel do you suggest?
<sukiminna> spitfire_: #kubuntu maybe..
<spitfire_> sukiminna: i said "GKSU"
<sukiminna> spitfire_:or  #ubuntu
<jpds> spitfire_: #ubuntu-devl might help, but maqny people are out for the weekend.
<jpds> #ubuntu-devel that is.
<spitfire_> jpds: thanks.
<jpds> Stupid keyboard.
<spitfire_> that's where I might get answer:P
<spitfire_> jpds: and don't blame keyboard:D
<jpds> spitfire_: it's a netbook, thus tiny keys.
<spitfire_> oh, I undrstand.
<spitfire_> I wouldn't buy one:P
<sukiminna> ..juz wanna ask why i cant include linux/module.h..
<spitfire_> I have a 15" laptop;)
<iulian> sukiminna: What do you mean? What are you trying to do?
<sukiminna> im learning how to code a kernel module..im a newbie..
<iulian> sukiminna: It's #include <linux/module.h> but this isn't the right channel.  For writing kernel modules I suggest you to try google.  There are a lot of good documentation on how to write one.
<iulian> There is also a #kernelnewbies channel on OFTC, IIRC.
<iulian> I believe they deal with kernel modules there.
<sukiminna> iulian: thanx
<fabrice_sp_> Hi. Who wants to win a free DVD Authoring tool? Just review DVDStyler (http://revu.ubuntuwire.com/details.py?package=dvdstyler) and gives me the second advocate. Limited number of players allowed! :-)
<\sh> evening
<iulian> Hiya \sh.
<hyperair> how does one add descriptions to quilt patches?
<hyperair> # ?
<JontheEchidna> Quilt will ignore anything above where the patch stuff starts
<JontheEchidna> before Index: path/to/patched/file.cpp
<JontheEchidna> example: http://paste.ubuntu.com/106507/
<JontheEchidna> this is for patches in general
<ScottK> Very strange beast this quilt.
<hyperair> heh
<hyperair> thanks
<hyperair> yay now lintian is clean
<maxb> Isn't ignoring leading text the behaviour of good old traditional patch(1) ?
<hggdh> how is an upstream source that comes already debiansed dealt with, if we need to change it?
<\sh> hail to the difference between patch and patch-management ,-)
<hyperair> hggdh: you tidy the tarball
<ScottK> maxb: I don't think relying on "patch  tries  to skip any leading garbage" is the same as "here's how you put in a comment".
<jharr> Where's an appropriate channel for help with some deboostrap issues?
<hyperair> hggdh: use a get-orig-source rule to remove the debian/ folder
<\sh> hggdh: ask upstream to not play debian maintainer..
 * ScottK mostly likes dpatch.
<hggdh> heh
 * hyperair prefers quilt
<JontheEchidna> quilt ftw
<ScottK> hyperair: It's not actuall required to remove it.
<JontheEchidna> once you get used to it, it's awesome
<hggdh> but this will mean changing the source tarball
<ScottK> hggdh: If it's OKish, then just edit it and move forward.  It makes the .diff.gz awkward, but it's doable.
<ScottK> If you need to remove entire files from the debian dir then you have to repack it.
<ScottK> If not, it's up to you.
<ScottK> In any case ask upstream to remove it in their next release.
<hggdh> thanks. Second question: this package (libpst-0.6.25, right now) will need to create a new library; should the library be split in a separate package (and another one for the -dev)?
<hyperair> ScottK: if you don't remove it your diff.gz is going to be exceptionally large
<ScottK> hggdh: Generally yes.  You'll want to look at https://wiki.ubuntu.com/MOTU/School/LibraryPackaging and https://wiki.ubuntu.com/DanielB%C3%BCltmann/CreatingLibraryPackages that tries to summarize it.
<ScottK> hyperair: Not necessarily.  I've dealt with these before where all I had to do was change revision/release target and so .diff.gz was essentially one debian/changelog entry.
<ScottK> It's really up to the packager if they want to repack (except if files have to be deleted).
<hggdh> in this case it is a debhelper, no patch support, no default library creation, and the debuild will create a lot of .ex under ./debian
<hggdh> which does not sound kosher to me...
<ScottK> What they are is confusing since you can't read the .diff.gz and understand the packaging (which I do do)
<hyperair> i do that too
<ScottK> dpkg-buildpackage doesn't create the .ex templates.  dh_make does that.
<hggdh> they force it in under Makefile.am, EXTRA_DIST
<ScottK> Ah.
<ScottK> Well if the upstream build system is insane and you're going to have to redo a lot of stuff, then repacking often can give you a more understandable package.
 * hggdh got hit with a small beast for the first even packaging from upstream ;-)
<hggdh> that was my view, but... this will involve changing upstream tarball... and I hate that
<hggdh> in this cases -- is bzr an option?
<hyperair> hggdh: bzr?
<hggdh> so that we could load the original tar ball there, and then just update
<hyperair> hggdh: in the case of my package bansheelyricsplugin, i repacked it removing all .svn files
<hyperair> hggdh: load the orig tarball and update? i don't get what you mean
<hggdh> I would like to have an original tarball available for audit
<hggdh> and repackaging will create a brand new original source, different from what upstream releases
<hggdh> (because dh_make is run upstream before release)
<hggdh> so: load upstream in bzr; adjust the packaging; tag it; and release
<ScottK> hggdh: The way you want to do this is with a get-orig-source rule in your Debian rules.  It should grab the upstream tarball and repack it for you.  This both documents your changes and eases future maintenance.
<hggdh> k, thanjs
<ScottK> JontheEchidna: What was the package of yours I reviewed recently with a get-orig-source?
<JontheEchidna> plasmoid-kbstate
<ScottK> hggdh: ^^^ for an example.
<ScottK> Thanks
<hggdh> downloading it now
<hggdh> ah, OK. get the source straight from the repository at the required version
 * ScottK looks over at soren and geser for their MOTU vote on JontheEchidna ....
<hyperair> hmm how should i fix a pacakge which isntalls stuff into /etc/gconf/schemas
<tobi_> if a package gets updated in Debain after the DebianImportFreeze, will this be merged not until the next ubuntu release?(now the one after jaunty)
<lfaraone> tobi_: unless a merge request is made
<tobi_> but that needs some serious reason?
<ScottK> tobi_: No more serious than a developer agrees it's reasonable to do.
<tobi_> how is a merge request done? through a bug? I didn't find any special tag for that in the wiki(https://wiki.ubuntu.com/Bugs/Tags)
<tobi_> I'm sorry I disconnected. so again: how is a merge request done? through a bug? I didn't find any special tag for that in the wiki(https://wiki.ubuntu.com/Bugs/Tags)
<ScottK> Generally the best way to get a package merge done is to do it and attach the resulting .diff.gz to a bug.
<hyperair> is any motu free enough to review a package?
<Laney> ScottK: Not a debdiff?
<ScottK> Laney: Right.  tobi_: debdiff.
<ScottK> Not diff.gz.
 * ScottK needs more coffee.
<tobi_> ok thanks for the info :D
<Laney> Generally two debdiffs, debian-ubuntu and (previous)ubuntu-ubuntu
<Laney> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<ScottK> Although th ubuntu-ubuntu one always seemed pointless to me.
<ScottK> Any sponsors here who use the ubuntu-ubuntu debdiff provided by sponsorees?
<james_w> o/
<james_w> sometimes
<ScottK> The requirement is present in the first version of that page, so I don't know where it came from.
<ScottK> Another benifit of wiki reorgs.
<ScottK> james_w: Do you feel it's of enough value to you to have the sponsorees go to the trouble of making it every time?
<james_w> well, not everyone does
<pochu> I sometimes looked at both, but I'm not active on sponsoring lately...
<james_w> and it's generally easier for them to make it than me
<ScottK> Well if people use it, I guess I won't bitch.
<james_w> but most of the time I don't look at it
<ScottK> I'm fairly certain I never had.
<ScottK> I think if I really found a reason to care I'd do it myself anyway.
<james_w> in a way it's what we should be reviewing, as it's the changes that are being made to Ubuntu
<james_w> but generally reviewing the debian-ubuntu one is more important
<hyperair> could a motu review my package vazaar? http://revu.ubuntuwire.com/details.py?package=vazaar
<ScottK> james_w: In theory I agree, but we don't do source code review of new upstream versions generally, so as a practical matter I think the need for it is a corner case.
<ramvi> I've read the wiki on how to customize the alternative cd: https://help.ubuntu.com/community/InstallCDCustomization
<ramvi> There doesn't seem to be a way to remove software though, as with livecd customization. How do I go about removing software?
<fabrice_sp> ramvi, you can have a look at remastersys. It allows you to do a livecd from an existing installation
<Ubuntuxer> Hi, I would like to ask, how I use postinst.ex
<Ubuntuxer> a link would be very useful
<Ubuntuxer> thank you
<jpds> Ubuntuxer: http://www.debian.org/doc/manuals/maint-guide/ch-dother.en.html#s-maintscripts
<Ubuntuxer> thanks
<pochu> awesome. diffstat can read .diff.gz files
 * pochu now feels stupid for doing $(zgrep "^+++ " *.diff.gz)
<LordDetain> I updated the libsmbios package from 2.0.3 to 2.2.8.  I have the new diff.gz, .dsc, and all the other stuff.     How do i go about submitting this ? I'm looking on this packaging guide thing on the ubuntu site but .. still nto really sure what to do
<pochu> LordDetain: report a bug in launchpad, attach the .diff.gz and subscribe ubuntu-universe-sponsors
<jpds> pochu: How was the English exam?
<pochu> LordDetain: actually, subscribe ubuntu-main-sponsors as the package is in main
<pochu> jpds: I think I did good at the Reading/Writing sections, but not so good at the Listening/Speaking ones
<pochu> jpds: so I think with a bit luck I will get the mark I need :)
<jpds> pochu: Well done. :)
<LordDetain> ok im repotting a bug in launchpad, should i just put like    "upgrading 2.0.3 -> 2.2.8" as the bug ?
<pochu> jpds: thanks :) I hope I get that mark
<pochu> jpds: if so, I may be studying in the US starting this August :)
<ScottK> pochu: Where?
<Chris`> pochu: Where abouts are you from?
<pochu> ScottK: not sure yet. I'm thinking about North Carolina State University. It'll be in CS of course :)
<ScottK> Of course.
<pochu> ScottK: it can be any of the universities on this list, as long as I get a good enough TOEFL mark: http://www.isep.org/students/Directory/members_in_usa.asp
<pochu> Chris`: Spain
<Chris`> Ah cool OK
<nhandler> pochu: *cough* Choose Illinois *cough*
<Chris`> *cough* Choose Bangor *cough*
 * pochu maps.google.com those
<Laney> Bangor's a bit far from the US
<ScottK> pochu: Interesting.  Only choose Illinois if you like cold.
<pochu> nhandler: Chicago, Illinois?
<pochu> ScottK: yeah :(
<ScottK> Laney: More than one Bangor in the world
<Chris`> Bangor in Wales I meant, not the one in the USA, there are two Bangors in the States or so GMaps says
<nhandler> pochu: I didn't see Chicago offerred on that list. But any university in Illinois ;)
<Laney> ScottK: I knew what he meant
<Chris`> Bangor, Gwynedd
<nhandler> ScottK: And what are you talking about Illinois being cold? We are above 0F right now ;)
<pochu> nhandler: too bad then
<ScottK> nhandler: We're about 0C here.
<ScottK> about/above
<nhandler> ScottK: Lucky
<pochu> my sister is likely going to live near Chicago RSN
<nhandler> pochu: Then she will be relatively close to me and nixternal
<ScottK> Tell her to watch out.
<nhandler> :D
<nixternal> hah
<pochu> heh
<Chris`> http://www.bangor.ac.uk/courses/undergrad/index.php.en?view=course&prospectustype=undergraduate&courseid=123&subjectarea=4 :D
<nixternal> Chicago FTW!
<pochu> .oO ( poor sister... )
<pochu> :P
<nhandler> pochu: I promise I won't visit her for at least a few years
<nixternal> Chicago is great, we had more murders than any other city in the US for 2008
<nixternal> can't beat that :p
<pochu> lol
<nhandler> nixternal: We just had a murder the other day about 5 minutes from my house (the day care one)
<nixternal> didn't even hear about that one
<nhandler> nixternal: It was in the paper today iirc. Daycare worker threw a kid down on his head hard in Lincolnshire
<nhandler> Gotta run. BBL
<ScottK> pochu: I don't know much about NC State, but that area is a good area for tech stuff.
<Laney> jpds: Know anything about this? (requestsync) http://pastebin.ubuntu.com/106601/
<nixternal> I think crimsun knows the NC State area a little bit
<pochu> ScottK: that's what my brother told me too :)
<nixternal> pochu: why is your sister moving to chicago?
<pochu> nixternal: because of my brother-in-law's work
<pochu> nixternal: I'll ping crimsun when he's online then, thanks :)
<nixternal> ahhh...what does he do?
<pochu> he works for power generators company
<nixternal> holy smokes, he might actually be working by my hours then as we have a very large company that does that stuff, but I cannot remember their name for the life of me
<nixternal> by my hours? wth!
<nixternal> by my house
<pochu> heh
<jpds> Laney: Which version of lplib are you using? Never seen that before.
<Laney> jpds: I just installed it from jaunty, but on an Intrepid system
<Laney> maybe it's some weird interaction?
<jpds> pochu: Neat.
<jpds> Laney: Looks like a problem in build/bdist.linux-x86_64/egg/launchpadlib/resource.py ?
<Laney> right
<jreinhardt> hi everybody. Is someone interested in reviewing my packaging of a (imho) really handy LaTeX package? http://revu.ubuntuwire.com/details.py?package=pgfplots
<Laney> jpds: Oh, I forgot that I had a manually installed version of lplib. Mea culpa!
<jpds> Laney: No problem.
<Laney> ...althouh I just got launchpadlib.errors.HTTPError: HTTP Error 401: Unauthorized
<Laney> but the bug was filed. Weird.
<RainCT> pochu: can't the key be added to -config?
<SolarWar> hi folks, quick question on packaging a program- must the licence appear on top of every source file at line 0 exactly? Or can the license be described after all the includes & ifdefs of the source file?
<RainCT> SolarWar: that shouldn't be a problem
<SolarWar> okay thanks :)
<Chris`> Could someone review my package please, http://revu.ubuntuwire.com/details.py?package=partitionmanager
<RainCT> uhm.. what does "wired/wireless NIC" mean? (it's in the HW testing page)
<Chris`> Network interface card?
<RainCT> ah :P
<RainCT> thx
<Chris`> You're welcome
<RainCT> How are those keys which work by moving the finger over them called?
<RainCT> (those which are activated by the electricity in our fingers, or whatever)
<laga> electro-capacitative?
<RainCT> nice name :P
<Nafallo> fingerprint reader? ;-)
<RainCT> LOL
 * RainCT may not know how those thingies are called, but this does still not mean that he is stupid enough to not know how a fingerprint read looks :P
<fta> RainCT, "touch sensitive keys"? like the multimedia keys on dell inspirion laptops?
<RainCT> laga, fta: thanks
<cbx33> hey guys
<cbx33> howz it going
<Chris`> cbx33: It goes good ;)
<cbx33> any one know how to create a second tun device?
<cbx33> tun1
<hggdh> I would really appreciate if a MOTU could look & comment at the libpst-0.6.25-1ppa1 on my PPA (https://launchpad.net/~hggdh2/+archive).
#ubuntu-motu 2010-01-18
<dhillon-v10> if bzr merge-package says nothing to do does that mean its a sync from Debian
<crimsun> not necessarily
<dhillon-v10> crimsun, the merge package command results in nothing to do message so what should I do now check the changelog file and do it myself
<crimsun> dhillon-v10: yes, by-hand is feasible regardless of tool
<dhillon-v10> crimsun, alright :) will you be around in like 5 mins. so i can show you the diff
<crimsun> dhillon-v10: probably not, sorry
<Anthropod16> hi, after having difficulty with karmic i am finally trying to reinstall my nvidia driver. after attempting to install the driver, i get this error: E: /var/cache/apt/archives/nvidia-glx-190_190.53-0ubuntu1~karmic~nvidiavdpauppa8_i386.deb: subprocess new pre-installation script returned error exit status 2
<dirakx> Hi i uploaded a package to REVU, but is not showing..tha package is called Turtleart
<dirakx> https://bugs.launchpad.net/ubuntu/+bug/507579
<ubottu> Ubuntu bug 507579 in ubuntu "[needs-packaging] turtleart" [Wishlist,New]
<ScottK> How long ago?
<dirakx> ScottK like two days ago.
<dirakx> dput says Already uploaded to revu on revu.ubuntuwire.com
<ScottK> Not sure what to say then.
<ScottK> It takes 10 minutes or so for them to appear and sometimes people ask here immediately.
<dirakx> Scottk i was having problems getting my pgp key authenticated..can it be the problem _
<ScottK> Could be.
<ScottK> We'd need a revu admin to really check and I don't know of any that are around right now.
<dirakx> ScottK: oh o.k thanks for helping me out.
<rhpot1991> isn't there some way to execute your get-orig-source from your debian/rules, or am I making up things in my head?
<RAOF> rhpot1991: I'm not entirely sure what you want, but you can certainly run âdebian/rules get-orig-sourceâ to get the original source (where such a target has been written).
<RAOF> rhpot1991: Actually trying to grab the original source as a part of the build process in your debian/rules file either won't work or will be strange enough to make people ask why you're doing it (depending on your make syntaxfu).
<rhpot1991> RAOF: I seem to recall there was a way to just run that from a terminal and have it execute
<rhpot1991> RAOF: I'm writing the section in my rules file and was looking for a good way to test it out
<RAOF> You can.  Just run âdebian/rules get-orig-sourceâ
<RAOF> If it's a policy-compliant rules file, that will work from a terminal.
<rhpot1991> RAOF: thats it, I was a level off, thanks
<RAOF> In fact, if it's policy compliant, you should be able to run that target from *any* directory.  But many rules files don't follow that particular part of policy.
<rhpot1991> RAOF: been a while since I did a REVU, should I generate the orig.tar.gz myself ahead of time or just debuild without it then upload?
<RAOF> You have to generate the orig.tar.gz beforehand; you can't build the source package without it.
<RAOF> (Because the .diff.gz is the diff against the orig.tar.gz, so you need to have unpacked the orig.tar.gz first...)
<RAOF> Actually, if you're packaging in a VCS (particularly git-buildpackage) that rule can be bent somewhat.  But you'll definitely need to have an orig.tar.gz for upload to REVU.
<RAOF> Wow.  eglibc will be a nice outlier for pbuilder-on-tmpfs benchmarking.
<dholbach> good morning
<ajmitch> morning dholbach
<hakaishi> Hi! Does "nuke" delete the whole package or just the upload?
<dholbach> hi ajmitch
<hakaishi> nobody?
<AnAnt> Hello, no UWN today ?
<hakaishi> I have a question about REVU: Does "nuke" delete the whole package or just the upload?
<maco> AnAnt:  is a holiday in the US. could have an effect....
<StevenK> Oh? What's the holiday?
<maco> well, holiday in the "no work or school or banks today" sense
<mzuverink> Martin Luther King Day
<maco> it's kinda like if India had "Gandhi Day"
<maco> (or maybe it does for all i know(
<mzuverink> Banks and postal, though more and nore banks are open
<maco> *)
<slytherin> maco: India has holiday on 2nd October (birth date of Mahatma Gandhi). :-)
<maco> slytherin: good to know!
<slytherin> On a side note it is also dry day in India.
<maco> is there a wet day too?
<maco> how about slightly damp day? and moist day?
 * maco runs
<AnAnt> slytherin: you mean today is a dry day or 2nd of Oct ?
<slytherin> he he, 'Dry Day' means 'No Alcohol Consumption Day'. :-)
<AnAnt> oh
<slytherin> AnAnt: 2nd October
<AnAnt> slytherin: yes, I understood that after you explained the meaning of "dry day"
<hakaishi> Hey, does nobody know what nuke in REVU deletes?
<ajmitch> hakaishi: I believe it removes all uploads of a source package
<slytherin> hakaishi: nuke deletes all uploads. But only admins have nuke privileges.
<slytherin> All uploads of a package
<hakaishi> Okay, thank you ^^
<vish> huh?
<ajmitch> how annoying
<vish> phew
<Hobbsee> !staff
<ubottu> Hey nalioth, jenda, rob, SportChick, seanw, Dave2, Christel, tomaw, Gary, PriceChild, niko or stew, I could use a bit of your time :)
<ajmitch> hello Hobbsee
<pagga> have you guys seen this: http://www.peoplesprimary.com/2010/01/17/ubuntu-10-preview ?
<Hobbsee> ajmitch: hiya.  welcome to the waves
<ajmitch> Hobbsee: yeah, I happen to be in wellington this week for lca
<pagga> have you guys seen this: http://www.peoplesprimary.com/2010/01/17/ubuntu-10-preview ?
<pagga> have you guys seen this: http://www.peoplesprimary.com/2010/01/17/ubuntu-10-preview ?
<pagga> have you guys seen this: http://www.peoplesprimary.com/2010/01/17/ubuntu-10-preview ?
<AnAnt_> pagga: are you one of them ?
<Hobbsee> ajmitch: so i heard
<pagga> one of who?
<Hobbsee> ajmitch: having fun there?
<ajmitch> I suspect so, given that url he's spamming
<ajmitch> Hobbsee: yeah, it's a fun event
<AnAnt_> ajmitch: yeah
<AnAnt_> !staff
<ubottu> Hey nalioth, jenda, rob, SportChick, seanw, Dave2, Christel, tomaw, Gary, PriceChild, niko or stew, I could use a bit of your time :)
<Hobbsee> dholbach: no point
<dholbach> Hobbsee: I see :)
<Hobbsee> dholbach: doesn't require being in the channel to do that
<slytherin> Why is there so much flooding?
<Hobbsee> slytherin: DDOS of the network
<AnAnt_> dholbach: Hello
<Hobbsee> i see i need to update my bad link filters
<ajmitch> slytherin: because people are being bored & stupid
<AnAnt_> dholbach: I didn't get any reply yet from Behdad !
<ajmitch> Hobbsee: I imagine you've been kept up to date on the happenings here then? :)
<jussi01> dholbach: set modes +Rr
<dholbach> AnAnt_: I think he's travelling, but I'm not sure
<dholbach> jussi01: what does that do? :)
<Hobbsee> dholbach: registered users only to join and talk
<jmarsden> dholbach: registered usersonly mode
<Hobbsee> oh, bleh.  my brower's still screwwed up
<jussi01> Hobbsee: dholbach as per the global notices and wallops, use of +r and +R is helpful if youve access
<jussi01> dont click that link!
<Hobbsee> jussi01: please get your time machine out...
<dholbach> I hope everybody's registered here
 * ajmitch is registered :)
 * StevenK thinks he is ...
<ajmitch> StevenK: oh good evening sir
<jussi01> dholbach: thanks, that should help
 * StevenK waves
<jussi01> dholbach: if they are not they should be.
<Hobbsee> ah ha.  managed to turn javascript off
<ajmitch> StevenK: how was wireless up your way?
<StevenK> ajmitch: Here, in the hotel?
<ajmitch> yeah
<Hobbsee> jussi01: how does that help - it's not like you need to be in a channel to versoin it?
<StevenK> Tis quite good, for NZ internet
<ajmitch> I saw complaints about it in the lca channel, but I'm finding it to be fine
 * StevenK hides
<jussi01> Hobbsee: Im not sure of the specifics, but thats freenoddes recomendation, not mine ;)
<ajmitch> ~170ms to fremont, it's not too bad
<Hobbsee> jussi01: fair enough
<maco> yay dholbach
<MTecknology> Hobbsee: hey, were you an op in here for long?
<Hobbsee> MTecknology: i have been for a number of years....
<MTecknology> You guys have any idea what I screwed up on? http://paste.ubuntu.com/358385/
<MTecknology> Hobbsee: I never noticed :P
<MTecknology> I'm trying to make a package for the latest openbox but I think packaging hates me
<slytherin> MTecknology: is there a configure script in upstream source?
<jmarsden> MTecknology: Looks like either the tarball has no ./configure file in it, or else something you do deletes it ?
<Hobbsee> MTecknology: well, i've not been around for a whole bunch of the year, so..
<MTecknology> I guess I don't see one :(
<jmarsden> MTecknology: If "the latest" means "grabbed from a VCS", that's common... you are expected to use autotools to create one when using a VCS by some projects...
<jmarsden> If "latest" means a real upstream release... there should probably be one :)
<MTecknology> jmarsden: I grabbed it like this - git clone git://git.openbox.org/dana/openbox openbox; cd openbox; git checkout release-3.4.10
<jmarsden> MTecknology: Right.  So that's from git, a VCS, not a release tarball.
<jmarsden> So itis up to you to create the configure script.
<jmarsden> Is there a autogen.sh script you can run ?
<MTecknology> jmarsden: nope..
<jmarsden> You can try using autoreconf -- best bet though is to check what instructions upstream give their developers for compiling from git...
<MTecknology> jmarsden: what package is that in?
<MTecknology> jmarsden: actually, there is a configure.ac file in there
<jmarsden> MTecknology: autoconf
<jmarsden> MTecknology: Good, you'd be dead in the water creating a configure file without that :)
<MTecknology> jmarsden: while I'm dloading- is there anything simple about packaging?
<MTecknology> jmarsden: http://paste.ubuntu.com/358390/
<jmarsden> MTecknology: well, packaging the hello app is pretty simple :)  It's the real world that tends to be messier :)
<jmarsden> MTecknology: I could probably work to deal with that but I'm not really an autotools guru.  Can you find the upstream site where they explain to new developers how they are supposed to grab code from git and compile it, and use that info for insight into this?  That's the track I would try at this point in your place.
<jmarsden> MTecknology: That msg *might* be a matter of which version of autotools the project wants you to use...
<jmarsden> MTecknology: See if installing autoconf2.13 on your machine helps at all.
<MTecknology> jmarsden: that wants a configure.in file
<jmarsden> MTecknology: It shouldn't, that's what autoconf creates from configure.ac ... let me check a bit more ...
<MTecknology> jmarsden: I can just keep bugging the developer and convince them to make the package and try to start a little easier
<jmarsden> MTecknology: Right.  I think you convincing them to release a tarball is all you need to overcome this issue.
<jmarsden> Their release process will include generating a configure file and including it in that tarball.
<MTecknology> jmarsden: their developer knows what she's doin when it comes to packaging things. I'm just trying to do something for karmic
<jmarsden> MTecknology: OK.  So can you not backport whatever they have for Lucid, rather than starting from git ?
<StevenK> jmarsden: configure.in or configure.ac can be used
<MTecknology> what's in lucid is 3.4.8 and the current stable is 3.4.10
<jmarsden> MTecknology: OK, so get a release *tarball* of 3.4.10 and start with that, perhaps?
<MTecknology> I'll need to see if they offer one anywhere
<MTecknology> where is pbuilder data held?
<jmarsden> My ~/.pbuilderrc overrides the defaults... :)  /var/cache/pbuilder/ I think
<MTecknology> oh
<Laney> What's the DH7 way to build arch-indep documentation?
<hyperair> override the arch-indep rule, i should think
<Laney> thought as much
<Rchik> hi every1, does any1 have some spare time to answer the questions related to entering universe repository with our open source software product?
<and`> Rchik: shoot
<Quintasan> Hello
<bddebian> Heya gang
<sistpoty|work> hi bddebian
<bddebian> Heya sistpoty|work
<ramiro> hi
<ramiro> what's the difference between a "devel" and a "libdevel" package in a debian/control file?
<ramiro> a pointer to any documentation on the issue would be nice...
<DktrKranz> nhandler, dholbach: I've just been picked for a out-of-office work day on 21st, I'll be out of town for almost all day, I'll probably be able to take my session at 20 UTC, but I can be a little late.
<DktrKranz> just to inform you in case that happens
<dholbach> DktrKranz: what do you think about trying to find a co-presenter who could cover the basics while you're finding your way into the session
<DktrKranz> dholbach: I could, maybe RainCT could have a shot
<dholbach> DktrKranz: I think that'd be the easiest solution if you don't want to totally reschedule
<Laney> do the buildds install recommends?
<geser> no
<Laney> blast
<geser> as a package installs successful even when one recommends isn't available (or not installable) you would get non-deterministic buildds (depending on the availibility of recommends)
<zooko> Folks: the Tahoe-LAFS v1.6 release is slipping and we will not have a new version of Tahoe-LAFS ready to upload into Lucid by Wednesday (the 20th) as we had planned.
<zooko> If we instead have one ready to upload by Monday the 25th do we still have a good chance of getting the new version included in Lucid?
<zooko> For what it is worth the slippage has nothing to do with QA issues and is instead all about improving safety, security, and forward-compatibility.
<ScottK> zooko: Yes.
<ScottK> We'd rather have it right than have it right now.
<zooko> Okay, we'll try to have it ready to upload next Monday.  Thanks!
<zooko> That sentence that I said may not have made sense -- we are improving safety and security, not by fixing bugs or issues that negatively impact those, but by adding new features.  So it isn't the case that there are any undiagnosed bugs that are causing the delay.
<zooko> Just FYI.
<c_korn> does someone know a package of an application which is written in pascal ? I have no idea how to package/compile something like that
<ScottK> c_korn: reverse-build-depends fp-compiler
<c_korn> ScottK: thanks
<freinhard> apachelogger, Quintasan: about that ctemplates package, i quess i'll move the emacs file back to docs/contrib/ cause i don't know (and don't want to find out ;) ) how to set it up correctly.
<Quintasan> freinhard: also poke upsteam to strip the binary files if possible :)
<rhpot1991> ok have some packaging questions, when packaging source that you are not upstream for, is there a preference between using get-orig-source vs having the source in your bzr branch?
<freinhard> Quintasan: the .la file has already been removed on svn, not sure about that testing file
<rhpot1991> I normally start with the source in a bzr branch and work from there, but am causing myself some confusion getting this ready for revu
<freinhard> Quintasan: aren't .out files designed to be compared to the actual output the compiled code produces?
<apachelogger> hm
<apachelogger> freinhard: I think the .out file can be ignored, since a successfull unit test should generate the thing, hence it is reproducible
<apachelogger> + it seems like it is simple text written as binary, so technically it is easily editable in any hexeditor :D
<rhpot1991> any bright ideas on this: http://mythbuntu.pastebin.com/d5813c217
<ScottK> jdong: I'd like to get your opinion on Bug #509287 for an SRU.
<ubottu> Launchpad bug 509287 in quassel "[Needs Update] Quassel (Ignorelist adding ctcp ignore)" [High,In progress] https://launchpad.net/bugs/509287
<freinhard> apachelogger, Quintasan: moved the emacs file back to the docs directory and uploaded the package again.
<Quintasan> freinhard: okay, you'll need to wait for apachelogger since I need to get back to books :P
<Quintasan> damned biology :/
<micahg> \sh: ping
<rhpot1991> does anyone have a good uscan/watch file example to point me at?
<micahg> rhpot1991: https://wiki.ubuntu.com/PackagingGuide/Complete#Creating%20and%20Using%20a%20debian/watch%20File
<randomaction> rhpot1991: man uscan - has a number of examples
<rhpot1991> thanks micahg and randomaction
<rhpot1991> ok so I implement a watch file and the upstream source doesn't allow directory access so I get 403 forbidden, essentially defeating the purpose of the watch file, what the heck do I do now?
<randomaction> you can use another format, which scans a page for links
<micahg> \sh: unping
<kamalmostafa> Is libGL broken again perchance?  All of the 'octave-*' packages seem to be FTBFS because of
<kamalmostafa>    octave-3.2.3: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
<ScottK> kamalmostafa: I'd talk to tseliot in #ubuntu-x
<kamalmostafa> ScottK: ok thanks
<rhpot1991> randomaction: happen to know what format that is, I don't see anything in the man page about that
<randomaction> "The first field is a homepage which should be downloaded and then searched for hrefs matching the pattern given in the second field." (from manpage, around line 190)
<rhpot1991> thanks randomaction
<rhpot1991> randomaction: all good now, thanks for the push in the right direction
<randomaction> rhpot1991: yw
<RainCT> DktrKranz: could do
<rhpot1991> with debhelper 7 do I need to define get-orig-source to use uscan or is there some magic in place to make it happen automagically?
<ScottK> rhpot1991: debhelper 7 doesn't help you on that.
<rhpot1991> ScottK: thanks, wanted to check first
<rhpot1991> if anyone has some time to do a revu: http://revu.ubuntuwire.com/p/hdhomerun-config-gui
<hakaishi> Hey folks! Anyone up to review qt-shutdown-p? It is a small program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p
#ubuntu-motu 2010-01-19
 * StevenK kicks FreeNode
<StevenK> ajmitch: Paying attention?
<StevenK> (To IRC, that is)
 * ajmitch kicks StevenK 
 * StevenK smothers ajmitch with a PPA
<jdong> ScottK: sorry for late response -- regarding quassel SRU...
<jdong> I think definitely it's something worth SRU'ing
<jdong> it's borderline but not quite "security" but definitely worth fixing :)
<jdong> the diff itself looks reasonable, my only concern is that it makes both UI and string changes
<jdong> not sure if there's anything special implicated by this (i.e. translation?) if we SRU
<jdong> apart from that, I'd ACK it :)
<ScottK> jdong: Thanks.  Quassel's translations are internal to the package and not part of language packs.  The only U/I change is untranslated, so it's OK.
<jdong> ScottK: thanks for the clarification. Looks good to me then!
<ScottK> jdong: Great.  Please ack in the bug if you didn't.
<jdong> sure thing
<jdong> done
<RAOF> For some reason mono apps seem to get much more benefit out of building on tmpfs.  Maybe gmcs is threaded.
<RAOF> ...and would normally be waiting on the disc more.
<ScottK> Maybe tmpfs is more efficient for patent license validation.   ;-)
<RAOF> :)
<RAOF> tmpfs appears to be quite a lot faster; a bunch of mono packages take somewhat under half the time on tmpfs than on ext4, and even xorg-server takes 80% the time on tmpfs than on ext4.
<jdong> RAOF: could it be disk thrashing related? mcs and managed code might stress the VM subsystem into evicting disk cache more readily?
<RAOF> Maybe.  The laptop's hardly under memory pressure, though.
<RAOF> I don't think it's hit more that 50% ram use.
<jdong> hmmm
<jdong> would be interesting to know what mcs is doing differently
<jdong> I wonder if it writes intermediate files to disk in the process then
<RAOF> I should probably add some insane C++ packages to the benchmarks.  How's boost at chewing ram?
 * RAOF restarts to load a new nouveau module.
<RAOF> Boo. nouveau's 3D is just plain broken :(
<ScottK> RAOF: kdebase-workspace probably does a decent job of chewing up ram.
<RAOF> Ok.  Once it's finished building gtk & mono I'll throw kdebase-workspace at it.
<ScottK> qt4-x11 for ultimate pain, FWIW.
<RAOF> Aah.  gnome-shell probably ftbfs because of the wonders of linking against firefox.
<RAOF> Gar.  Why is mozilla so difficult?
<micahg> ?
<RAOF> Oh, gnome-shell FTBFS because it can't find some mozilla libraries, and it can't find them because they're in /usr/lib/xulrunner-1.9.1.7 which isn't in the library path.
<micahg> RAOF: do you need someone to look at it?
<RAOF> I'd like to know whose responsibility it is.
<micahg> RAOF: do you have a build log?
<RAOF> http://launchpadlibrarian.net/37862849/buildlog_ubuntu-lucid-amd64.gnome-shell_2.28.1~git20091125-1_FAILEDTOBUILD.txt.gz is as good as any.
<RAOF> Either adding an rpath on /usr/lib/xulrunner-1.9.1.7 or exporting LD_LIBRARY_PATH makes the build work.
<micahg> RAOF: well, we have a bug about libmozjs
<RAOF> Hah.  Wandering through launchpad again makes me wonder why mozilla is so difficult - xulrunner, xulrunner-1.9, no!  xulrunner-1.9.1 is the source package I'm after! :)
<micahg> RAOF: I don't see the build dep
<RAOF> It's transitive; libgjs-dev pulls it in.
<RAOF> I'm just wondering at what level to fix this; it looks like libgjs or gnome-shell are the candidates.
<micahg> probably in gjs
<micahg> RAOF: do you need the link to the mozjs bug?
<RAOF> If it's relevant; I can't seem to find any mozjs bug under xulrunner-1.9.1
<micahg> bug 286906
<ubottu> Launchpad bug 286906 in xulrunner "provide and support a top-level library package for libmozjs (Was: Unable to use libmozjs.so in an application, because of library path problem.)" [Unknown,Confirmed] https://launchpad.net/bugs/286906
<RAOF> Man, launchpad bugzilla integration rocks.
<micahg> RAOF: probably should ask asac for anything more, I'm still learning :)
<RAOF> It looks like the answer was âno system library for you, but feel free to pull a Debian and make one upâ.
<micahg> heh
<RAOF> I *think* this might be an annoying interaction that isn't necessarily libgjs' fault.
<micahg> indeed
<RAOF> In fact, I *think* it's something needlessly linking directly to libmozjs.
<RAOF> Yup, there we go.
<RAOF> Oh, so it probably *is* libgjs' fault, but in its pkg-config file.
<RAOF> Right.  So, now I run into the limits of my knowledge of ELF linking.
<RAOF> Oooh, is that it?  libgnome-shell.so has 3 references to libmozjs; one explicitly from the (unnecessary) -lmozjs, one implicitly from libgjs-gi.so linking to libmozjs, and finally one with the right rpath from libgjs.so linking to libmozjs
<RAOF> It seems two of these are unnecessary; neither libgnome-shell nor libgjs-gi appear to use any symbols from mozjs, and exist only to make other things break.
<micahg> RAOF: maybe ask upstream why it's linked?
<RAOF> I think it's that common misunderstanding about the role of Requires in pkg-config files.
<micahg> k
<micahg> sorry, I must go to sleep now
<micahg> glad you found the issue
<RAOF> So, I can (temporarily) fix gnome-shell by building it with -Wl,--as-needed
<dholbach> good morning
<RAOF> Morning dholbach
<dholbach> hi RAOF
<RAOF> dholbach: How are you on the intricacies of the elf linker as they apply to shared object dependencies?
<dholbach> you're asking the wrong person :)
<RAOF> I might wait for seb128 then, as it concerns gnome-shell and such.
<cemc> dholbach: care to look at this bug #96850 (last comment)
<ubottu> Launchpad bug 96850 in rrdtool "[apport] perl crashed with SIGSEGV in rrd_test_error()" [Medium,Fix released] https://launchpad.net/bugs/96850
<dholbach> cemc: I'm in a meeting right now
<cemc> dholbach: oh, sorry
<dholbach> cemc: it might make sense to ask in the channel here generally
<cemc> it's in main
<dholbach> try asking in #ubuntu-devel then :)
<cemc> ok, thanks
<ivoks> \sh: heartbeat isn't what it used to be before
<ivoks> \sh: please don't upload anything to lucid yet
<\sh> ivoks, grmpf
<\sh> ivoks, just two ldirectord bin deps + Makefile.am patch for the FTBFS...I found it what the bugger was...autotools
<ivoks> there's latest upstream + fixes on ubuntu-ha ppa
<ivoks> heartbeat3 standalone is useless :)
<\sh> ivoks, heartbeat from universe.
<ivoks> right
<ivoks> version 3.0/2.99 is just part of cluster stack
<slytherin> is ia64 buildd broken currently? I am seeing lot of ia64 only FTBFS.
<randomaction> it was several hours ago, now seems to be ok
<randomaction> (sparc was broken, too)
<\sh> ivoks, I just fixed the 3 bugs...2 of them I reported...(well and sadly uploaded already :()
<slytherin> randomaction: thanks for info. I am retrying a build.
<\sh> ivoks, could you incorporate the changes into your ppa then?
<ivoks> \sh: if i haven't already, i will
<ivoks> \sh: ldirectord isn't part of heartbeat anymore, iirc
<\sh> ivoks, it's in 2.99
<ivoks> probably, yes, but in 3.0 it's removed to cluster-glue, iirc
<\sh> ivoks, well, for ldirectord we need bin-deps on libdbd-mysql-perl and libsocket6-perl and for heartbeat in $sourceroot/resources/OCF/Makefile.am it tries to install drbd resource script two times, and autotools failes because it doesn't like that
<ivoks> hb3 doesn't have drbd issue
<ivoks> and ldirectord is part of cluster-agents
<ivoks> i'll take a look if those deps are satisfied
<ivoks> they aren't :)
<soren> seb128: Fantastic, thank you.
<soren> Whoops.
<soren> Heh :)
<\sh> ivoks, libdbd-mysql-perl is needed for ldirectord service=mysql loadbalancing, and libsocket6 is needed too, regarding heartbeat
<\sh> argl
<ivoks> \sh: libdbd-mysql-perl will be recommended
<\sh> ivoks, libdbd-mysql-perl is needed for ldirectord service=mysql loadbalancing, and libsocket6 is needed too, regarding bug #487508
<ubottu> Launchpad bug 487508 in heartbeat "ldirectord is missing libsocket6-perl dependency" [Undecided,Fix released] https://launchpad.net/bugs/487508
<ivoks> \sh: i understand :D
<\sh> ivoks, I can help to test latest packages for lucid if you want...we are planning the dist-upgrades from jaunty to lucid via karmic ;)
<ivoks> \sh: it's just that not everybody wants load balance mysql, so it's more natural for libdbd-mysql-perl to be recommended, while it clearly depends libsocket6-perl
<ivoks> ^on
<ivoks> \sh: with heartbeat cluster?
<\sh> ivoks, yes..right now we are running plain heartbeat with v1 config, but we need to upgrade this asap
<ivoks> \sh: you do know that heartbeat isn't cluster any more?
<ivoks> \sh: you will need new CRM; pacemaker
<\sh> ivoks, yepp
<ivoks> ok
<ivoks> don't do any upgrades yet
<ivoks> this is something i would like us to do togheter
<ivoks> so that we can cover this scenario
<ivoks> once packages are prepared, i'll let you know, ok?
<\sh> ivoks, pls :) there are more bugs regarding an upgrade from jaunty to karmic we need to resolve here before we actually can dist-upgrade anyways...and we will do our testing in our lab before :)
<ivoks> \sh: karmic doesn't have heartbeat-1 :)
<ivoks> \sh: you might be better of with cluster from scratch :D
<ivoks> anyway, i have to go now
<ivoks> ttl
<bluefoxicy> so is songbird a tool of the devil?
<bluefoxicy> It's not packaged in Ubuntu
<slytherin> bluefoxicy: ask mozilla team if they have any plans to package it.
<bluefoxicy> slytherin: ah, there's a team for that?
<directhex> bluefoxicy, songbird bundles its own forked version of xulrunner (the mozilla engine). bundling even little things like zlib makes the archive admins flustered and stern.
<bluefoxicy> aha, so it IS a tool of the devil
<directhex> bluefoxicy, if songbird gets approved as-is, then it's the precedent i need for moonlight 2.0
 * slytherin wonders when rhythmbox will get video playback capability.
<directhex> slytherin, is that useful functionality for you?
 * bluefoxicy copies music he pirated ages and ages ago to his ipod.
<bluefoxicy> this is retarded.
<bluefoxicy> I have a folder with like 30 albums in it that I torrented, in a bundle, most I didn'tknow about
<bluefoxicy> I'm slowly replacing them with... the actual, physical CDs, from Amazon
<bluefoxicy> 8 years later I have half of them
<slytherin> directhex: Not very important. But surely I would love to have a single player for audio/video/media (DVD) etc.
<bluefoxicy> slytherin:  last time I asked, they weren't interested in video
<slytherin> hmm, may be some day I will gain enough knowledge about the code to be able to produce a patch.
<directhex> slytherin, i know banshee has the functionality, but afaik it's buggy
<slytherin> Or at least a plugin
<bluefoxicy> https://bugs.launchpad.net/ubuntu/+bug/94494
<slytherin> directhex: last time I tried banshee it worked fairly well for me.
<ubottu> Ubuntu bug 94494 in songbird "[needs-packaging] Songbird" [Unknown,Confirmed]
<juli_> Hi everybody. I want to update libswing-layout-java from 1.0.3 to 1.0.4. If I update it in Debian won't it be too late to import the package in Ubuntu?
<soren> juli_: We can sync from Debian at will.
<slytherin> juli_: Debian import freeze is in February
<soren> juli_: It doesn't /have/ to have migrated to testing, for instance. It just has to have migrated to testing before it happens /automatically/.
<juli_> Actually I don't know when it happens, I mean migraiting to testing
<slytherin> juli_: That reminds me. I forgot to send you email about this. Are you interested in taking care of netbeans package in Debian as well?
<juli_> slytherin, as for me, I need them in Ubuntu. But people ask me to put them in Debian, so I'm interested
<directhex> juli_, that's the spirit
<juli_> directhex, :)
<slytherin> juli_: The packages are orphaned in Debian. And you are the best person for job. All you need to do is join debian-java team and port the packaging as per Debian practices.
<Laney> somehow my priorities shifted after I started contributing to Debian
<slytherin> juli_: Oh and migration to testing happens in 10 days provided there are no serious or grave bugs against the package.
<directhex> Laney, now you have a flowing beard and wear sandals?
<Laney> one out of two of those is correct
<Laney> you may choose which
<juli_> slytherin, so I can try to upload my packages in Debian... and if I'am lucky they will be migrated automatically right?
<slytherin> yes
<juli_> slytherin, ok, thank you!
<juli_> Laney, are you in debian-java?
<Laney> juli_: nop
<juli_> can anybody tell me what I have to do to join debian-java team? It looks like I don't have much time for this:(
<directhex> juli_, they probably have a page on alioth with a "join this team" link
<directhex> probably
<juli_> directhex, thanks, I'm already in google:) but as far as I remember I wrote them a letter a year ago with no answer. Anyway I'll try again
<sebner> directhex: are you aware that -cli-dev packages got autosynced?
<slytherin> juli_: The mailing list is http://lists.debian.org/debian-java/ for getting access to the pkg-java svn register on alioth.debian.org, upload your ssh public key and join team - https://alioth.debian.org/projects/pkg-java/
<Laney> Why does mono not get autosynced? It's not in the blacklist
<juli_> slytherin, thank you.
<geser> Laney: you might need to get an archive admin try to sync it and watch for any errors/OOPSes
<Laney> I wonder if there is a block for packages on the cd
<Laney> (not interested in syncing it yet)
<geser> I don't know of any special handling for those packages (and other parts of main are on the CD too)
<geser> directhex: do you see any reason to keep the current mono version in lucid instead of finding it out why it doesn't autosync?
<Laney> it will make FTBFS happen
<Laney> ongoing transition
<geser> ok
<Laney> cjwatson: (last few lines) â do you know of any reason why mono doesn't autosync?
<cjwatson> Laney: "autosyncs" are only auto in that there's a script to do it; the script still has to be run manually, and maybe it just hasn't been run recently
<cjwatson> Laney: somebody appears to be in the middle of an autosync run right now, including mono
<Laney> cjwatson: There had been newer versions in testing since 2009-11-23, which made me think that something else was going on here (I know they are only semi-automatic)
<cjwatson> Laney: I won't be able to investigate until whoever's running syncs at the moment flushes them
<Laney> cjwatson: No problem. It's not urgent, more of a curiosity (until we come to need this sync)
<directhex> Laney, when it's needed we can just open 90 bugs manually :)
<Laney> dunno if it affects more than just mono!
<Laney> (seems not, from random checking of gtk#)
<geser> Laney: I know of an other package that fails to auto-sync (I have the OOPS id for it and just need to find someone who can look at it)
<Laney> I bet it's something to do with the mammoth number of binary packages provided by mono
<proppy> ScottK: hi
<proppy> filled https://bugs.launchpad.net/ubuntu/+source/poker-network/+bug/509677
<ubottu> Ubuntu bug 509677 in poker-network "Please sync poker-network 1.7.6-1 from unstable to lucid" [Undecided,New]
<bddebian> Heya gang
<hyperair> heya bddebian.
<bddebian> Hi hyperair
<hyperair> bddebian: could i ask you to endorse my MOTU application? =D
<bddebian> Not sure my opinion is worth much in the Ubuntu world these days.
<hyperair> hmm why not?
<bddebian> I haven't done much for Ubuntu directly in a looong time. :(
<hyperair> but indirectly you still do stuff don't you? =p
<bddebian> Probably depends on who you ask. :)
<hyperair> O_o
<ScottK> bddebian: You are a God.  Your opinion will always matter.
<ScottK> proppy: It needs an explicit statement that it's OK to over-write the Ubuntu changes and why.
<proppy> ScottK: ah sorry I missed there were ubuntu changes
<proppy> checking
<ScottK> proppy: poker-network | 1.7.5-1.1ubuntu2 | lucid/universe | source
<proppy> ScottK: yes I see that now, dget'ing https://launchpad.net/ubuntu/+archive/primary/+files/poker-network_1.7.5-1.1ubuntu2.dsc
<hyperair> bddebian: and so that's how it is. =p
<proppy> I already applied ubuntu ubuntu1 changes upstream
<proppy>   * Apply Ubuntu changes:
<proppy>     debian/python-poker{-network, 2d, -prizes,-stats}.install: use wildcards
<proppy> checking ubuntu2
<proppy> ScottK: will ask the maintainter to upload a 1.7.6-2 with ubuntu2 changes
<directhex> moo
 * iulian moos at directhex.
<MTecknology> if there's a newer verswion of something in debian unstable, will it still make it to 10.04?
<randomaction> MTecknology: not on its own, a sync should be requested for that
<randomaction> packages from testing are autosynced
<MTecknology> randomaction: how can I request that?
<randomaction> https://wiki.ubuntu.com/SyncRequestProcess
<MTecknology> thanks
<Laney> just wait for it to transition
<Laney> unless there's a good reason why we shouldn't
<MTecknology> Laney: I just checked what testing is - it's in sid so I guess it'll be in 10.04 :D
<MTecknology> for now - I just installed the debain .deb :)
<Laney> subject to caveats, yes
<Laney> like â is anything going to stop it migrating to testing, and are there any ubuntu changes that will stop it being auto synced?
<kamalmostafa> randomaction: hi -- i just fixed guymager to build for i386 and amd64 only (the libguytools1 does actually contain arch-specific code) -- bug 509732 ready for u-u-s
<ubottu> Launchpad bug 509732 in guymager "guymager tries to build on architectures not supported by libguytools1" [Undecided,Confirmed] https://launchpad.net/bugs/509732
<randomaction> kamalmostafa: ok, I'll sponsor it later if no one beats me to it
<kamalmostafa> randomaction: very good.  thanks for noticing that it was going to be a problem.
<Laney> (please forward to Debian)
<kamalmostafa> Laney: was that for me?  I did report it to Debian, but I do see that upstream of that they're already aware of the Architecture: problems in libguytools1 and guymager -- they'll be cleaned up in their next release I think.
<Laney> cool beans
<jariq> What is REVU day ?
<kamalmostafa> Retry build request:  https://launchpad.net/ubuntu/+source/octave-ad/1.0.6-3   ... yesterday's new libgl1-mesa-glx might fix all the octave-* breakages.
<randomaction> pushed button for i386
<kamalmostafa> thank you -- i'll keep an eye on it
<randomaction> What do I need to do to provide a symbols file for a library (bug 361651)?
<ubottu> Launchpad bug 361651 in libsocket "Package does not provide /var/lib/dpkg/info/libsocket0.symbols (shared library information)" [Undecided,New] https://launchpad.net/bugs/361651
<kamalmostafa> randomaction: take a peek at dpkg-gensymbols -- google implies that it will generate what you need there.
<randomaction> I wonder whether it's called by dh at some point
<kamalmostafa> randomaction: that I do not know
<kamalmostafa> randomaction: oh and that octave build just failed with the same problem
<kamalmostafa>   libGL.so.1: cannot open shared object file: No such file or directory
<kamalmostafa> so nevermind about any other the others there (sigh).
<randomaction> ok, dh_makeshlibs call dpkg-gensymbols, which creates a shlibs file which goes into control part of the .deb but doesn't seem to be installed
<kamalmostafa> But wait... now I see that the octave-ad build didn't actually use the brand new mesa 7.7-0ubuntu7 (it used ubuntu6).  Why would that be?
<randomaction> kamalmostafa: maybe it built only recently and hasn't propagated to buildds yet
<hyperair> dpkg-gensymbols creates shlibs?
<hyperair> that's new
<hyperair> and the manpage doesn't say anything of that sort either
<kamalmostafa> randomaction: okay, that sounds reasonable.  I do see that it was published only very recently.  We'll try octave again "later".  :-)
<hyperair> randomaction: i think you're looking for a symbols file in the control.tar.gz of the deb
<randomaction> hyperair: it is there indeed, but it seems to go nowhere
<hyperair> not a shlibs. and dpkg-gensymbols doesn't generate one. it needs one to be already there, and then checks that there are no new symbols. if there are new or deleted symbols, it prints a diff then dies, taking the build with it
<hyperair> i mean dpkg-gensymbols doesn't gnerate a .symbols file if it didn't already exist before
<randomaction> right, there is .shlibs but no .symbols
<hyperair> yep
<hyperair> so what you need is to create the symbols file
<hyperair> to do that, you need to run the build locally, then run dpkg-gensymbols on it
<hyperair> get the diff
<hyperair> and then get the symbols out from there
<hyperair> (very annoying, i know)
<randomaction> and it goes into debian/ ?
<kamalmostafa> randomaction: fwiw an small-ish package which has an example of this is 'clxclient'.
<hyperair> randomaction: yes, it goes into debian.
<randomaction> hyperair: thank you, I'll try it
<hyperair> randomaction: the naming convention of the symbols file is in the top of the dpkg-gensymbols manpage
<hyperair> randomaction: if you're packaging a C++ library, you want to avoid dpkg-gensymbols like plague. but you're not, are you?
<randomaction> it's C++
<randomaction> I mean, sources are
<hyperair> then you want to avoid dpkg-gensymbols
<randomaction> I don't really know what it exports
<hyperair> C++ symbols are mangled, as i'm sure you know?
<randomaction> yep
<hyperair> and the mangling is architecture specific.
<randomaction> and compiler-specific I believe
<hyperair> which means that for each architecture the library builds on, you're going to have to provide a different symbols file.
<hyperair> yes
<hyperair> architecture and compiler specific
<hyperair> it's not worth the effort.
 * hyperair packaged sigx and encountered this kind of problem
<randomaction> ok, I've got one more library question..
<hyperair> hmm?
<randomaction> this package installs library into /usr/lib/packagename, adds this path ld.so.conf on install and doesn't clean on remove
<hyperair> that's not good.
<randomaction> that's terribly wrong, I assume
<hyperair> it is terribly wrong
<hyperair> if you must add a path into ld.so.conf, use /etc/ld.so.conf.d/
<hyperair> stick a file in there
<randomaction> so the solution is just to install .so to /usr/lib
<hyperair> yes, that would be preferable, i believe.
<randomaction> ok, that's what I did
<hyperair> is there a reason that upstream wants to install it to /usr/lib/packagename?
<randomaction> no idea; I took this package to fix FTBFS, and I try to fix other obvious breakage
<hyperair> i see
<hyperair> well, this is an issue that probably should be brought upstream
<hyperair> if you don't want to bring it upstream yourself, you could contact te original maintainer of the package
<hyperair> the last person in the debian/changelog
<hyperair> or the debian maintainer
<randomaction> yep
<hyperair> ..it's even a native package. just what is going on with this package?
<hyperair> weird.
<randomaction> it's really broken :)
<hyperair> heh
<hyperair> when was the last changelog entry?
<randomaction> 2007
<hyperair> that's quite long ago.
<hyperair> i wonder if upstream died
<hyperair> there are no rdeps
<hyperair> it might be better to just get rid of the package.
<randomaction> last release is 2006
 * hyperair whistles
<randomaction> popcon = 368
<hyperair> hmm that's a significant number
<randomaction> a bug filed in April 2009, apparently someone is still using it
<hyperair> hmm
<hyperair> maybe
<hyperair> it's removed from debian though
<hyperair> at least, the source package's not there.
<hyperair> that would probably mean that it's going to disappear from ubuntu in due time
<randomaction> maybe
<randomaction> ok, I uploaded a relatively straightened version of libsocket, I decided not to touch symbols file, but anyway thank you hyperair for telling me how it's done
<hyperair> np
<fabrice_sp> randomaction: fceux accepted: thanks for your review! :-)
<randomaction> you're welcome :)
<jariq> could someone pls review new package ipwatchd ? - http://revu.ubuntuwire.com/p/ipwatchd
<stefanlsd> With a merge and a debuild -S -v, the -v specifies the previous ubuntu version so you get the debian changes and your merge changes in the .changes right?
<jariq> I've read in motu mailinglist that for Jaunty there were weekly REVU days every Friday. Is there something similar also for lucid ?
<randomaction> stefanlsd: right
<stefanlsd> randomaction: thanks!
<geser> kamalmostafa: can you please mark your libguytools1 merge proposal as "merged". thanks
<kamalmostafa> geser: sure will do.  I'm unclear as to why that doesn't happen automatically.
<geser> I guess randomaction uploaded your changes but did push the merged bzr branch back to LP (only then LP knows that your branch got merged and updates the status of the merge proposal)
<randomaction> I actually only did the upload
<kamalmostafa> geser: ok.  fwiw, I think that I *always* have to manually change my merge proposals to "Merged".  I mentioned it to james_w and he was surprised by that too.
<kamalmostafa> geser: Were you looking at the related 'guymager' merge (bug 509732)?  It looks like I had forgotten to press the "Propose" button, but have done so now.
<ubottu> Launchpad bug 509732 in guymager "guymager tries to build on architectures not supported by libguytools1" [Undecided,Confirmed] https://launchpad.net/bugs/509732
<james_w> kamalmostafa: I think the issue is that your sponsor is not pushing to the lp:ubuntu branche
<kamalmostafa> james_w: ok -- i'm not sure what that means really -- is this something the sponsors should be doing differently, or something I should be doing differently?
<geser> kamalmostafa: it's a sponsor thing: with bzr merges your sponsor has to do "bzr push" to updated the LP branch (and get your merge proposal marked as "merged" by LP) *and* dput the new source package
<randomaction> I wonder what happens if I push and dput different things
<randomaction> will delta be represented as another revision?
<geser> james_w: ^^ any answers to this?
<james_w> it will complain and make the branch look like the upload, but won't throw the push away
<geser> what about any tags? (bzr mark-uploaded)
<randomaction> ok, so that won't screw things up completely
<kamalmostafa> Quick informal moto-review of bug 353219 please.  Do we want this fix in Lucid, or is it not important enough to justify an "ubuntu1" version?
<ubottu> Launchpad bug 353219 in ax25-tools "beacon crashes if the length of the destination exceeds 20" [Undecided,Confirmed] https://launchpad.net/bugs/353219
<dirakx1> hello i uploaded a package to REVU but its not showing this is the bug.  https://bugs.launchpad.net/ubuntu/+bug/507579
<ubottu> Ubuntu bug 507579 in ubuntu "[needs-packaging] turtleart" [Wishlist,New]
<dirakx1> dput says Already uploaded to revu on revu.ubuntuwire.com
<cyphermox> dirakx1, does dput -f say the same thing?
<dirakx1> cyphermox: i havent issue that command :)
<dirakx1> Uploading to revu (via ftp to revu.ubuntuwire.com):
<dirakx1>   Uploading turtleart_0.0.1.dsc: done.
<dirakx1>   Uploading turtleart_0.0.1.orig.tar.gz: done.
<dirakx1>   Uploading turtleart_0.0.1.diff.gz: done.
<dirakx1>   Uploading turtleart_0.0.1_source.changes: done.
<dirakx1> Successfully uploaded packages.
<dirakx1> lets hope that it works this time ..
<dirakx1> cyphermox: thx for your help.
<cyphermox> dirakx1, when you upload, dput creates a .upload file, IIRC, to remember the changes have already been send
<dirakx1> source.revu.upload
<dirakx1> :)
<EzraR> if i wanted to put a package in my ppa for testing before merging would placeing a ~ppa0 be enough to keep it seperate from the official repo?
<EzraR> meaning would foo-1ubuntu1 replace foo-1ubuntu1~ppa0
<RAOF> Yes.  That means its version will sort before the official one.
<RAOF> The ~ character is treated specially: it means âsort me after everything else, even the empty stringâ, so 0~ < 0 and 1ubuntu1~ppa0 < 1ubuntu1
<EzraR> thats what I thought I just wanted to make sure, thanks
<siretart> does anyone else experience that gpg-agent does no longer cache the passphrase?
<RAOF> The plugin from seahorse-plugins still does, for me.
<siretart> doing mass uploads is no fun if you need to retype in the pin for each source package
<siretart> twice
<micahg> siretart: on cli, yes
<siretart> RAOF: that one doesn't work with the gpg smartcard :/
<siretart> so I need to resort to gpg-agent
<RAOF> Wow, I don't even have that installed.
<siretart> I'd prefer working smartcard support in searhorse, too
#ubuntu-motu 2010-01-20
<hakaishi> Hey folks! Anyone up to advocate/review qt-shutdown-p? It is a small program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p
<lucas> Is Chuck Short around?
<ajmitch> doesn't appear to be, he's usually online as zul
<mrburns> hi all i am interested in getting involved with ubuntu and i hear that motu is a good place to start does anyone have any suggestions how to start?
<RAOF> mrburns: Find a bug that annoys you, and fix it.
<RAOF> That's generally the best thing to do.
<mrburns> ok sounds good
<RAOF> The easiest bugs to fix are those that have been reported upstream, fixed there, but not yet fixed in the Ubuntu packages.  In that case, it's generally just a matter of adding a patch to the Ubuntu package, which is one of the simplest packaging changes you can make.
<mrburns> RAOF: should i just search around launchpad bugs and find something there?
<RAOF> mrburns: Yeah, that works.  dholbach's harvest (http://daniel.holba.ch/harvest/) can help finding patches for stuff.
<mrburns> RAOF: thanks
<dholbach> good morning
<slytherin> dholbach: good morning
<ara> I have a packaging question, maybe someone can help me
<ara> We used to have ldtp source, which provided ldtp (core, written in C) and python-ldtp (python bindings).
<ara> Now, ldtp2 has just been released with the core completely rewritten in python and we need to package it for lucid. What would you recommend:
<ara> a) Keep the core (now in python) in the ldtp binary, the python library in python-ldtp with version 2
<ara> b) Put everything in ldtp binary (core and libraries)
<ara> c) Create a new package called ldtp2 that replaces the two above
<dholbach> hey slytherin
<ara> non of the above?
<dholbach> ara: is there a use-case for having any of them separated somehow?
<ara> dholbach, no that I can think of
<dholbach> one thing to bear in mind is coordinating the naming scheme with the debian people, so you don't end up maintaining a different package name for a longer while
<ara> one important thing is that ldtp < 2 and python-ldtp <2 cannot cannot be installed at the same time as ldtp >= 2
<ara> dholbach, I am already in contact with the debian packager
<dholbach> or having conflicts/replaces that you need to maintain on your own for a long time in ubuntu (because of lts upgrades)
<dholbach> nice
<ara> dholbach, in fact, I am coomaintainer of the debian package
<slytherin> ara: if parallel installability is not an option then simplest thing would be to completely replace existing packages with new version.
<dholbach> ara: so Kartik ist leaving the decision to you? :)
<ara> dholbach, yes, he has no time now to maintain it
<dholbach> I see
<slytherin> I believe Kartik has too may packages with his name on him. :-)
<slytherin> s/him/them
<ara> so, slytherin, you're suggesting to keep the division between core and libraries?
<slytherin> ara: the split looks sane enough to me. But I don't use the package so probably I am not the best person to ask advice about it.
<ara> dholbach, what do you thinkÂ¿
 * dholbach downloads source
<LLStarks|Lazy> hi guys
<LLStarks|Lazy> gst plugins bad needs the new dirac dependency
<slytherin> LLStarks|Lazy: it was already uploaded but seems to have failed to build.
<slytherin> LLStarks|Lazy: https://edge.launchpad.net/ubuntu/lucid/+source/gst-plugins-bad0.10/+builds
<LLStarks|Lazy> ah gotcha
<LLStarks|Lazy> thanks
<slytherin> I am not able to access the build log at this time so I can not check if it was real failure or transitional failure.
<slytherin> LLStarks|Lazy: if you can download the log, unzip it and post the relevant bits on pastebin may be I can decide if we should retry the build.
<LLStarks|Lazy> will do
<LLStarks|Lazy> hope its gzipd
<slytherin> yes it is
<slytherin> that is the reason I can not access it. the content filtering system in my office filters anything that ends with .gz
<LLStarks|Lazy> asinine
<dholbach> ara: I'm a bit unsure... at the moment I can't think of use-cases for splitting it, but I just had a look at http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names - not sure if that would result in some kind of "oversplitting" as seb128 would call it :)
<LLStarks|Lazy> looks like an sdl library problem
<ara> dholbach, well, even if the use case is not clear, shouldn't be simpler to keep it split for the sake of maintainability?
<ara> dholbach, (to avoid having to keep a lot of replaces)
<dholbach> ara: the API of python-ldtp broke, right?
<slytherin> LLStarks|Lazy: can you paste the log on pastebin?
<ara> dholbach, yes
<ara> dholbach, they are 90% compatible, but not 100%
<LLStarks|Lazy> http://paste.ubuntu.com/359443/
<dholbach> hmhm - I wonder if you'd need to rename stuff anyway in that case
<dholbach> there's only mago depending on it afaics
<SevenMachines> slytherin, LLStarks|Lazy: you might want to look at Bug #509442 , gst-plugins-bad0.10 is fixed upstream in debian but i'm guessing its actually an issue with sdl dev
<ubottu> Launchpad bug 509442 in gst-plugins-bad0.10 "libavcodec-extra-52 breaks gstreamer0.10-plugins-bad (libdirac-encoder0 replaces the necessary libdirac0c2a) " [Undecided,Confirmed] https://launchpad.net/bugs/509442
<slytherin> Looks like we need merge from debian package
<dholbach> ara: you could ask seb128 when he shows up, he should know a bit better than I do
<ara> dholbach, OK, I will, thanks :)
<SevenMachines> slytherin: that would be best, it does need both the changes from 0.10.17-2 and 0.10.17-3 though, those are the ones i used and they work. i dont know where 0.10.17-3 is in terms of unstable/testing though
<slytherin> SevenMachines: -3 is not yet in testing.
<slytherin> Does anyone know at what version of glib, gio APIs were introduced?
<tranx> Hi,
<tranx>  I am having some difficulties for creating a package for "cython" application.
<tranx> I was wondering whether it would be the good room to get some support on this issue ?
<tranx> s/for "cython" application/for a cython application/g
<randomaction> !ask
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<tranx>  I need to build a package that uses cython, but default pbuilder cannot resolve  "cython" when put into "build-depends" ..
<randomaction> you need to enable universe - see https://wiki.ubuntu.com/PbuilderHowto#Universe%20support
<tranx> is this enabled on build farms ?
<johe|work> hi all
<johe|work> i have a problem with an package maintained by motu https://bugs.launchpad.net/ubuntu/+source/python-pysnmp4/+bug/509495
<ubottu> Ubuntu bug 509495 in python-pysnmp4 "pysnmp version switch broken" [Undecided,New]
<johe|work> i would really need help on that
<tranx> i.e. launchpad
<tranx> I meant, I manage to get a working pbuilder with cython on my personal desktop, but I wonder how to get it working on launchpad, or other build servers.
<johe|work> so than, this goes out to any python developer, if i dont get pysnmp working on karmic i need to programm my stuff in perl, and i really dont like :-(
<randomaction> tranx: on buildds, build-dependencies from universe are disabled for packages in main. In other cases, they're allowed
<tranx> randomaction: thanks for these elements.
<slytherin> tranx: Paste the debian/control file somewhere so that we can check if there is any problem with build dependencies
<ockham> sry for nagging, but as i can't see any communication going on here (only logon/offs): is there anybody at all?
<geser> yes, but most people are probably busy with other things (like e.g. work)
<ockham> too bad... gotta leave...
<menesis> can I upload a fixed package to REVU with the same version number?
<randomaction> menesis: yes, version should stay the same
<menesis> do I have to include orig.tar.gz again?
<menesis> looks like yes
<hyperair> will there be a MC meeting on the 12th of february?
<geser> hyperair: no, see the announcement
<hyperair> geser: i saw. so how should i go about applying for motuship?
<hyperair> the thursday meeting is at 3AM my time
<geser> wait on the next DMB meeting, I hope we get a little bit further about the MOTU future on that meeting
<geser> I hope the DMB comes about a decision what to do about MOTU applications while the future of MOTU is shaped
<POX> porthose: :P (re: your mail to debian-python)
<porthose> POX, :)
 * StevenK tickles wgrant 
 * wgrant swats StevenK 
 * StevenK dodges wgrant's ineffective swat
<wgrant> You can't dodge me, I'm next to yuuyou.
<ajmitch> find a room, people
<highvoltage> rofl
<ajmitch> which talk are you at?
<StevenK> MS versus FOSS
 * ajmitch is staring at slides of PHP code, brains are leaking out
<wgrant> We have found a room! Illot!
<StevenK> Not so private, sadly
<wgrant> Terrible.
<pucko-> Hello.. I have a package I would like to see in ubuntu. I have made a deb archive of it (which needs some minor tweaking yet). can it be included even though there is no upstream url available? (I got the source by mailing the company)
<RAOF> Are you able to distribute the source?
<pucko-> it is a driver for a smart card reader btw
<pucko-> yes. it is lgpl2.1
 * ajmitch will have to watch that talk on video afterwards
<pucko-> I'm not sure if it should be packaged separetely or of it should be included in libccid (which is a package for many other smart cart readers)
<StevenK> wgrant: Saw a website recently that said "Microsoft has spent billions on Windows, how can Linux possibly run on a computer without Windows code, since Linux is free."
 * StevenK should find the source
<ajmitch> the leaps in logic there are interesting
<StevenK> ajmitch: Absolutely.
<RAOF> pucko-: Maybe it should end up in libccid, but that would require the code to be submitted to the libccid project.  As it's a separate source tree, it should (almost certainly) be a separate package.
 * RAOF goes to wrestle with bugs.gnome.org to submit some gjs patches.
<pucko-> RAOF, so how should I proceed? I believe I need some help
<RAOF> pucko-: It'd be good if the source was easily available somewhere on the web, but I don't *think* that's a dealbreaker.
<RAOF> pucko-: What you could do next is refine your package and upload the source package to REVU.
<RAOF> !revu
<ubottu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
<pucko-> ok. the main thing is the lintian error messages. but I guess I can come back here later and ask for help about those..
<RAOF> Absolutely.
<RAOF> Note that running lintian with with -i will give lots of nice info about the errors, and generally how you might fix them.
 * RAOF decides gjs probably doesn't want these patches.
<pucko-> ok, thanks
#ubuntu-motu 2010-01-21
<ramiro> hello
<ramiro> how would I go about the following issue?: a cross-compiler depends on pre-compiled runtime libraries. with them, I build the compiler. then I can build the runtime libraries again. So the runtime libraries depend on themselves.
<RAOF> That sounds like a typical bootstrapping problem; I'd guess off the top of my head that gcc does that, and I'm fairly sure mono does, too.
<ramiro> it is possible to build them in many steps, but then I'd have to bundle the runtime source with gcc and have a somewhat complex debian/rules.
<RAOF> You're bootstrapping; you're going to have a somewhat complex debian/rules *regardless*.
<ramiro> heh, makes sense.
<RAOF> You can bundle binaries in the source package as long as they get rebuilt during the build - ie: patching some source and then rebuilding should Do The Right Thingâ¢
<crimsun> poor chris.
<RAOF> I wonder what's bouncing me.
<StevenK> RAOF: "Excess Flood"
<RAOF> That seems odd, given I wasn't actually doing anything at all.
<StevenK> Indeed
<RAOF> Perhaps a bug against smuxi is in order.
<micahg> RAOF: there was a huge netsplit a little while ago
<RAOF> Ah.  Maybe that triggers it?  Was that when I started bouncing?
<micahg> RAOF: yes
<stochastic> what's the program that's similar to 'apt-get source package' but instead pulls the latest code from launchpad?
<micahg> stochastic: pull-lp-source
<stochastic> thanks micahg
<dhillon-v10> hi all, can anyone look here: https://bugs.launchpad.net/ubuntu/+source/cln/+bug/508995 and tell me why the patch I provided doesn't work?
<ubottu> Ubuntu bug 508995 in cln "Please merge cln (1.3.1-2) from Debian Testing" [Undecided,New]
<StevenK> wgrant: O hai -- how long does it take qa.uw.com/ftbfs to notice something does now build?
<wgrant> StevenK: It makes a *lot* of requests to Launchpad, so it only runs every six hours.
<wgrant> That frequency is arbitrary.
<StevenK> wgrant: Yeah, sounds reasonable
<ajmitch> wgrant: so the next step is to get some batching happening in the API?
<RAOF> Oh, poot.  I misspelled âRequires.privateâ as âRequires.Privateâ.
<hakaishi> Hey folks! Anyone up to advocate/review qt-shutdown-p? It is a small program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p
<rhpot1991> anyone know if there is a way to tell pbuilder-dist to save changes?  I can't seem to get the pbuilder --save-after-login flag to work with it
<crimsun> depends on the type(s) of changes, but generally, --save-after-exec --override-config
<rhpot1991> crimsun: I just need to add my ppa to my apt sources
<rhpot1991> normally I'd login and do --save-after-login, add the ppa exit and all would be good
<rhpot1991> but with pbuilder-dist it doesn't seem to honor that flag (or I'm doing something silly)
<RAOF> It does (or should) honour that flag, but it also overrides a bunch of your config with each invocation.  Say, for example, that you don't want mirror.kernel.org as your mirror?  Currently, you're out of luck with pbuilder-dist.
<RAOF> That might also cause it to kill your added entries in sources.list; I'm unsure.
<rhpot1991> RAOF: well I used pbuilder and pointed at the resulting .tzr file and it seems to have saved it, but oddly enough when I logged in with pbuilder-dist it didn't show me the saved data
<rhpot1991> I'll go ahead and build and see if it works
<rhpot1991> I need my PPA to match a dependency that isn't pushed yet
<dhillon-v10> crimsun: hi there, can you have a look here: https://bugs.launchpad.net/ubuntu/+source/cln/+bug/508995 if you have a minute or so
<ubottu> Ubuntu bug 508995 in cln "Please merge cln (1.3.1-2) from Debian Testing" [Undecided,New]
<dhillon-v10> crimsun: why is the patch not applying? I did it using bzr
<micahg> if something is marked won't fix, if it's released with a proper changelog entry, will the status change to Fix Released?
<rhpot1991> RAOF: well, I went in with pbuilder added them, updated, everthing is ok.  Then I run pbuilder-dist and it doesn't seem to obey :(
<rhpot1991> guess I'll have to go straight up pbuilder for now
<RAOF> micahg: You mean: there's a changelog entry * foo, bar: fixes (LP: #123456), where bug 123456 is currently set to âwon't fixâ?  I think that'll set it to fix released.
<ubottu> Launchpad bug 123456 in xine-lib "podcast crashes amarok" [Undecided,Fix released] https://launchpad.net/bugs/123456
<micahg> RAOF: that's my question :)
<RAOF> I'm fairly sure it'll set it to fixed released.  Do you not want it to?
<micahg> RAOF: no, I want it to so I don't have to make more bug noise ;)
<ScottK> micahg: Although I have to wonder why something that's marked wontfix is getting fixed.
<micahg> ScottK: source package change
<ScottK> Generally we're pretty conservative about putting that on a bug.
<micahg> firefox 3.6 will return to the firefox source package which was formerly firefox 2
 * micahg put it there in a lot of cases
<micahg> it was correct at the time
<persia> IF it was correct at the time, why isn't it still correct?  "Won't Fix" should be reserved for stuff we really aren't expecting to fix.  Notabug and the like.
<micahg> persia: it was firefox 2 which was won't fix, now it's firefox 3.6 which will be fix released
<micahg> we intended to stick with versioned source packages until upstream decided to do rapid releases
<persia> I still think it oughtn't have been won'tfix.  That should only be used where we specifically intend not to fix something.
<persia> Getting it fixed later, even by accident, makes us look indecisive.
<micahg> persia: so, you're saying I should comment anyways and explain?
<persia> Leaving a comment in the bug explaining why circumstances have changed would mak sense, and changing the bug from "wontfix" to "triaged" or something with the comment.
<persia> Then you go from "Triaged" to "Fix Released" with the upload.
<micahg> persia: ok, I'll do that, it's only 3 bugs in this case
<persia> But try to avoid these :)
<micahg> yep, it's unfortunate, but necessary
<ScottK> persia: Sometimes circumstances change and so wontfix should change too.
<persia> ScottK: Agreed.  I just think that 1) it deserves explanation when it happens, and 2) we should try not to do that.
<ScottK> Certainly.
<ScottK> I'd rather look indecisive than make present virtue out of past necessity.
<persia> I'd rather avoid both, but given the choice I have to agree.
<dholbach> good morning
<SevenMachines> morning
<dholbach> BlackZ: so does autotrash use a setup.py based installation?
<BlackZ> dholbach, yes
<dholbach> you could try just using /usr/share/doc/debhelper/examples/rules.tiny (with debhelper 7)
<dholbach> DktrKranz: do you have a good example for an python app using dh7?
<POX> dholbach: gaupol :)
<johe|work> hi there, i submited an new package version to an bug report https://bugs.launchpad.net/ubuntu/+source/python-pysnmp4/+bug/509495 what does i nedd to do now, to get it replaced in repositry
<ubottu> Ubuntu bug 509495 in python-pysnmp4 "pysnmp version switch broken" [Undecided,New]
<dholbach> thanks POX
<dholbach> BlackZ: apt-get source --diff-only gaupol; less gaupol*.diff.gz
<dholbach> BlackZ: that'll give you an idea how to do it
<BlackZ> dholbach, thx
<dholbach> BlackZ: and if you get stuck, just ask in here, somebody will be able to help you :)
<POX> dholbach: zless, I guess (and gaupol has to be >= 0.14-1)
<dholbach> POX: less works too
<POX> not here (I don't have LESSOPEN defined)
<dholbach> POX: ah ok
<randomaction> johe|work: you need to provide a debdiff (modification to the *source* package), and see https://wiki.ubuntu.com/SponsorshipProcess
<johe|work> randomaction, thx
<randomaction> johe|work: see also https://wiki.ubuntu.com/Bugs/HowToFix (it tells you how to produce a debdiff)
<jariq> Could someone please review package ipwatchd ? http://revu.ubuntuwire.com/p/ipwatchd
<hyperair> dholbach: ping. regarding the whole MC losing quorum thing, how should i go about applying as a MOTU, if i can't make the next meeting? (it's 3AM local time)
<persia> hyperair: You could try an email application, but otherwise, you'd do best to wait until the 2nd February DMB meeting, at which we can hope some direction is provided.
<persia> Note that we haven't had any successful email applications in a while, and getting it complete in the next six days would be tricky.
<ScottK> Althernatively, suck it up and get up in the middle of the night ...
 * persia expects some MC members to be attending in the middle of the (local) night.
<DktrKranz> dholbach: I finished my job journey and I'm back town, so I can regularly take my session tonight :)
<Quintasan> Hello
<slytherin> Quintasan: hi
<Quintasan> slytherin: \o
<slytherin> Why do we have two links pointing to different FTBFS pages in topic?
<ScottK> Because one if packages that failed to build in the archive and the other is ones that failed to build in a rebuild test.
<slytherin> ScottK: So is the second url relevant all the time?
<ScottK> slytherin: Yes.  lucas has been doing regular rebuild tests for us this cycle.
<slytherin> Then it is fine.
<ramiro> I'm using reprepro to manage a repository. When I included a new version of a package, the old one was deleted because it was unreferenced. How do I make it so that all packages always remain in the repository, and it's the user's job to select which one he wants? (and by default he gets the latest version)
<nigel_nb> maco, around?
<persia> ramiro: You'll need to either use less smart repository software, or very custom solution.
<ramiro> ugh, a less smart repository software means I'll have to be less dumb =). which one do you suggest?
<persia> I'm not the right person to suggest any: I don't manage repositories (but we don't much generally here).  apt-ftparchive is probably the least fancy of the options.
<freeflying> ramiro: dak maybe :)
<persia> freeflying: Doesn't dak autoexpire superceded stuff?  Anyway, I can't imagine it being useful for less than 10,000 packages.
<ScottK> persia: Depends on the pain to package ratio you find acceptable.
<persia> heh.  I suppose :)
<freeflying> persia: mini-dak then  :)
<dholbach> ajmitch_: if you have a bit of time - do you think you could help out with reviewing the zope* packages on REVU?
<ScottK> Considering there's an active Zope team in Debian, wouldn't they better go there?
<persia> The moreso because they describe themselves as the "Debian/Ubuntu Zope Team"
<benste>  hi, if I'd like to have a package merged from debian - what can I do? -https://bugs.launchpad.net/ubuntu/+source/tiemu/+bug/221332
<ubottu> Ubuntu bug 221332 in tiemu "The tiemu package is heavily outdated" [Wishlist,Confirmed]
<benste> ?
<ScottK> benste: First step would be to look at the changes Ubuntu has from Debian in the package and see if they are still needed/relevant.
<persia> benste: There are outstanding Ubuntu changes that need to be investigated before the package is synched.
<persia> benste: From a quick glance, I believe it does need a merge, to deal with iceweasel/firefox differences between Debian and Ubuntu.
<benste> why should tiemu use FF ?
<benste> - where does i have to look for it ?
<persia> benste: In Debian, in tiemu 3.02-1, there is a dependency declared on "iceweasel | www-browser".
<benste> and whom does I have to propose to include the new version even if it's ok - so already build a ubuntu version
<benste> k
<persia> This dependency needs to be modified to be "firefox | www-browser"
<benste> persia: only changing depency is simple isn't it - simply download source, change config and rebuild deb right ?
<persia> Err, sorry.  Needs to be "firefox | abrowser | www-browser"
<benste> what about the already build Ubuntu package
<persia> benste: Don't even bother rebuilding.  We work exclusively with source packages.
<benste> inlcuded in the PPA of one poster
<ScottK> persia: Why?
<benste> persia: changing depency is all - if so I'll do right away
<persia> Download the Debian and Ubuntu package sources.  Merge the changelogs.  modify debian/control to have the right dependency and use "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" as the Maintainer.
<ScottK> I think the odds of anyone having no package that provides www-browser installed is effectively nil
<persia> Put the previous maintainer in XSBC-Maintainer
<persia> Update the changelog, and attach a debdiff to the bug.
<benste> persia: would be kind of you to explain me how to do this - or give some simple resources which will guide me through this process
<persia> ScottK: Because that's what the mozilla team declared should be the dependency.  See bug #272772
<ubottu> Launchpad bug 272772 in zekr "packages that Depend/Recommend/Suggest firefox (meta-package) must alternatively Depend/Recommend/Suggest abrowser" [High,Fix released] https://launchpad.net/bugs/272772
<persia> !merge
<ubottu> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<persia> benste: That URL should give some guidance.  Ask here if you get stuck.
<ScottK> persia: since it currently Depends/Recommends neither, it's not applicable
<benste> I'll
<benste> fo
<persia> ScottK: Hrm?  Are you looking at the same tiemu I'm seeing?
<persia> Depends: libatk1.0-0 (>= 1.20.0), libc6 (>= 2.7), libcairo2 (>= 1.2.4), libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.3.5), libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 2.14.1), libpango1.0-0 (>= 1.21.6), libticables3 (>= 3.9.6-1), libticalcs4 (>= 4.6.1-1), libtifiles0 (>= 0.6.6-1), libxml2 (>= 2.6.27), zlib1g (>= 1:1.1.4), firefox | abrowser | www-browser
<ScottK> persia: I'm looking at you having said it depends iceweasel | www-browser
<persia> My sid apt-cache says it does.  Am I out of date?
<ScottK> No.  I'm saying I think that's sufficient.
<persia> I thought that one of the changes we maintained was all the s/iceweasel/firefox/ changes in package relationships.
<persia> Do we have a solution for that now?
<ScottK> Changing iceweasel | www-browser to firefox | abrowser | www-browser has zero practical effect on user experience
<ScottK> The only time that would matter is if the user had no package installed that provided www-browser and that would be hard to accomplish
<persia> Well, that removes a whole heap of diffs.
<ScottK> I'm just saying I think it's not worth the effort to maintain that diff.
<ScottK> It does.
<ScottK> Consider it.
<persia> I can see the argument, I just thought that there was some intent behind that.
<ScottK> I realize it's a change in procedure, but I think it makes sense.
<ScottK> If there's some other diff, go ahead and do firefox | abrowser | www-browser too, but if that's it, I'd sync it.
<persia> I don't disagree, but I also think that procedure is best changed in combination with interested parties, such as TIL or mozillateam.
<persia> fta: Do you have any opinion about tiemu and iceweasel/firefox ?
<persia> ScottK: If there wasn't some reason to fiddle the names, the simplest solution to the entire mess would be to have firefox Provide: iceweasel.
<ScottK> persia: I agree with that.
<persia> So, because we didn't do it the easy way, I presume there's some reason.
<ScottK> That would solve an even large set of problems.
<ScottK> In theory, changing to firefox | abrowser | www-browser is more correct, but I think it's not worth the trouble.
<persia> I don't pretend to understand that reason, but I'll go along as long as others feel it's better to do it the hard way.
<ScottK> I don't know that it's been seriously examined in some time.
<persia> That's why I asked TIL :)
<benste> persia: what if I can't find my package in https://merges.ubuntu.com/universe but in https://merges.ubuntu.com/t/tiemu/
<benste> ?
<persia> benste: then that would mean the wiki page was out of date :)
<benste> lol
<benste> persia: the wiki(how to merge) or the list of merges ?
<persia> The wiki of how to merge.
<benste> so you're using a different site today ?
<persia>  /topic says http://people.ubuntuwire.com/~lucas/merges.html , but this may be temporary.
<persia> We've been having a lot of discussion about merges this cycle, and I'm not sure we have a final solution yet.
<bddebian> Heya gang
<benste> persia: thx for this temp info found the last uploader and Scott  replied to the bug too
<ScottK> persia: His package is in Multiverse.  That's why he couldn't find it in Universe.
<benste> :-9
<ScottK> Interesting.  Per architecture support time: "add case were a architecture is supported (armel) but not for the full LTS time" in https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-support-timeframe-information
<persia> ScottK: Is MoM generally up again, or are we still unsure of a final solution?
<persia> ScottK: Separately, that sense of "supported" probably means "labeled as supported", rather than anything else.  Same as hardy lpia in that sense.
<ScottK> persia: MoM is unmaintained.
<ScottK> Oh, I didn't realize that obtained for Hardy lpia.
<persia> That was my understanding.  As a result, I believe the wiki page on merging to be out of date.
<ScottK> OTOH, the alternative via bzr is not really mature enough for general use.
<persia> I'm not sure it does for all flavours, but I know that because of the way some of the mobile stuff was done on lpia, lpia desktop didn't work reliably anyway because of library issues.
<persia> So when the (non-LTS) mobile flavour ended support (18 months), I *think* lpia kinda lost support.
<persia> I have no idea about lpia server.
<persia> On merging: right.  I don't think we have a good replacement for the merging documentation right now.
<ScottK> There are some useful hint in the UDD wiki pages.
<ScottK> hint/hints
<persia> Yes.  They haven't worked for me yet, but I'm sure that's only a matter of time.
<ScottK> Also in the replies to my recent thread on the topic on the UDD mail list.
<ScottK> It would be useful for someone to work on a page that was the union of those two resources.
<fabrice_sp> lutin, about bug 510693
<ubottu> Launchpad bug 510693 in ecore "Sync ecore 0.9.9.063-3 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/510693
<fabrice_sp> why do you need an ack from u-u-s? IMHO you should be able to push that by yourself
<fabrice_sp> (package is still in universe, it seems)
<Lutin> fabrice_sp: heh, thought it had been promoted to main already.
<Lutin> sorry
<fabrice_sp> np: I'll unsubscribe u-u-s then ;-)
<fabrice_sp> may I subscribe archive admin also? Or you will take care of it?
<Lutin> fabrice_sp: I'll take care of it, thanks
<fabrice_sp> ok
<pucko-> I have a few packaging problems I was hoping someone could help me with. I want to include a udev-file in my package (which is built with cdbs). but I can't get debhelper to add my udev rule to the package. Supposedly, specifying DEB_INSTALLUDEV_ARGS in debian/rules should take care of it. but it doesn't seen to work. it's just ignored.
<fta> persia, ScottK: wrt tiemu, feel free to do whatever you want with it, i just touched it once as part of a massive firefox meta package update
<persia> fta: More generally, do you know the reason that we fuss with changing all the package dependencies rather than just having firefox and abrowser Provide: iceweasel?
<persia> pucko-: Is this a new package, or a change to an existing package?
<pucko-> a new package
<pucko-> dh_installudev is actually run, but I can't get it to take the correct arguments.
<fta> persia, a lot of debian users are using our firefox packages (because they are fresher), as they also have iceweasel, it's best to keep things separate
<persia> fta: So it's worth changing the dependencies of all these packages every cycle?  I just thought that by using Provides: we could sync more packages from Debian.
<fta> persia, but you may want to talk to asac about that, those days, i'm mostly focusing on chromium
<persia> OK.  I just picked on you because you touched tiemu last :)
<persia> pucko-: You need DEB_DH_INSTALLUDEV_ARGS instead of  DEB_INSTALLUDEV_ARGS, but figuring this out is frustrating and tricky.  Might I recommend using /usr/share/doc/debhelper/examples/rules.tiny as the base of your debian/rules?
<pucko-> oh. thanks!
<pucko-> um.. that file is just 3 lines :-/
<persia> Yep.  Saves lots of messing about.
<persia> You can pass arguments to dh_installudev either by passing them to the dh call (but this passes the same arguments (likely usually ignored) to dh_*), or you can add an override_dh_installudev: rule, and put the complete dh_installudev call in that.
<persia> (Well, there's lots of other ways to do it too, but those might be easiest)
<pucko-> sounds easier to just use the env variable. now that I know it :-)
<persia> What's your environment variable setting?
<pucko-> I mean that DEB_DH... thing
<persia> Right.  What value are you using?
<pucko-> oh it worked. DEB_DH_INSTALLDEV_ARGS = --priority=85
<persia> pucko-: Here's the two different rules.tiny debian/rules files that do that: http://paste.ubuntu.com/360227/
<persia> (and no hunting around for special secret variable names)
<pucko-> now I only have this postinst-has-useless-call-to-ldconfig warning. it is added by debhelper for some reason. can I tell it to ignore it?
<persia> Are you installing any shared libraries?
<pucko-> well. sort of. it's a smart card reader driver. one .so-file that should go into /usr/lib/pcsc/ somewhere.
<pucko-> so tha path shouldn't be added to ld.so.conf
<pucko-> the
<persia> You need to pass arguments to dh_makeshlibs to ignore that.
<pucko-> ok.
<feuloren> hi, is there packages for gegl 0.1 somewhere ?
<randomaction> feuloren: looks like no, Debian has an open request for it
<statik> hey Daviey, i just reviewed your django-openid-auth branch. got one minor request for you, and i'll be happy to merge it
<hotellina> hi people, do you know how make ubuntu able to show volume levels for all sound peripherals ( usb also) ?
<jibel> fabrice_sp, just seen you've sponsored bug 464422. Thank you !
<ubottu> Launchpad bug 464422 in msttcorefonts "package ttf-mscorefonts-installer 3.0 failed to install/upgrade" [Critical,Fix released] https://launchpad.net/bugs/464422
<fabrice_sp> jibel, you're welcome: you did all the job ;-)
<randomaction> jibel: well done, this was a bug with an enormous amount of duplicates
<jibel> randomaction, thanks
<randomaction> two such bugs, actually :)
<jibel> if anyone knows how to reach the debian maintainer please ping him. It would be great to fix it upstream too.
<fabrice_sp> jibel, I saw you reported it there, but no answer :-/
<menesis> could someone review/sponsor my zope.* packages on REVU? http://revu.ubuntuwire.com/u/menesis
<pucko-> can anyone tell me why there is both a libusb-0.1-4 and libusb-1.0-0? very confusing..
<pucko-> in ubuntu karmic
<randomaction> pucko-: it's commonplace to have different versions of libraries in distribution (or installed on the same machine), as different applications may require different versions
<pucko-> hm..
<pucko-> it seems very specific. why not just libusb0 and libusb1?
<tsimpson> because the files are libusb-0.1.so.4 and libusb-1.0.so.0
 * Quintasan goes to bed, school etc.
<jariq> how long does it take to the package to show up in the ppa after upload?
<persia> jariq: ask in #launchpad.
<jariq> thx
<hggdh> about 5 minutes, anyway
<superm1> RainCT, could you ack ~ubuntu-dev-without-bugmail into ~mythbuntu?
<RainCT> superm1: sure
<superm1> thanks
<RainCT> superm1: Uhm, what has changed since the original proposal when we created that team?
<superm1> RainCT, it looks like there is a gateway to catch all the extraneous email now isn't there?
<superm1> or was there still some other deficiency?
<RainCT> superm1: I'm not sure, I'm reading the old mails right now
<RainCT> superm1: There was no agreement that ubuntu-dev needed access to such branches: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026207.html
<RainCT> superm1: Also, problems with the ~ubuntu-dev-without-bugmail approach were that e-mails other than bugmail were still send to everyone (for example, notifications of new mailing list creations) and that all developers had the Mythbuntu logo on their profile
<superm1> Oh right
<superm1> well then i guess not worth the troubles still
<superm1> once more ~mythbuntu folks are more packaging proficient on their own should just have them apply for per package upload rights and move those branches to ~mythbuntu-dev at that time
<superm1> for now it's convenient as it stands
<superm1> sorry for the churn, i should have dug that mail up myself and reviewed it
#ubuntu-motu 2010-01-22
<superm1> RainCT, i guess you can nuke that fake team then alltogether
<superm1> it's not gonna serve any purpose ever
<RainCT> Yeah
<RainCT> superm1: uhm, the confirmation page has no "OK" button, only "Cancel" :P
<superm1> yay launchpad
<RainCT> superm1: Also, I'm not sure whether that will send a mail to everyone. Maybe I should just leave it.
<superm1> i found the same problem trying to delete ~ubuntu-mythtv yesterday when i was doing other team cleanup
<happyaron> Can I request for syncing a package that is still in Debian new queue?
<crimsun> anything that's dgetable.
<crimsun> probably best if you wait til it's accepted, though.
<happyaron> oh, thanks
<happyaron> one of may package is in the new queue from Jan 2nd till now, don't know when will it be accept to archive
<micahg> \sh: libjs-dojo made it into unstable :)
 * StevenK bugs wgrant 
<wgrant> StevenK: Hi.
<StevenK> wgrant: Isn't there a timeout to kill builds that sit there and spin?
<StevenK> (See https://edge.launchpad.net/builders/sejong )
<wgrant> StevenK: Yes, but it's slave-side.
<wgrant> So if the slave dies, no timeout.
<StevenK> Ah, so sejong might have just rolled over and died
<wgrant> Not completely.
<wgrant> It's still responding to XML-RPC.
<wgrant> But maybe sbuild has hung.
<StevenK> Mmmm
<micahg> RAOF: file a bug if you need dh_xulrunner updated :)
<RAOF> micahg: I was going to, with a patch attached.
<micahg> cool :)
<hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - I think there are no more Bugs, Errors and no lintian warnings. qt-shutdown-p is a small program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p
<RAOF> Yes!  I (finally) win!
<RAOF> gnome-shell (and anything else that depends on gjs, which is nothing at the moment) now builds!
<SevenMachines> i can sense the relief :)
<micahg> RAOF: BTW, xulrunner is moving to universe...
<ScottK> menesis: There is a Debian/Ubuntu Zope team that works mostly by getting stuff into Debian first.  I would recommend you contaxt them.
<RAOF> micahg: You mean the current xulrunner package, which is 1.8, right?  Not xulrunner-1.9.1, which is needed for Firefox?
<micahg> RAOF: xulrunner-1.8 shoudl have been dropped already
<RAOF> And xulrunner-dev is still going to point to xulrunner-1.9.1-dev, right?
<micahg> xulrunner-1.9.2 for lucid will be in universe
<micahg> once the ff migration is done
<RAOF> What's FF migrating to?
<micahg> RAOF: all in one package
<RAOF> No longer pretending you can use it as a lib, eh? :)
<RAOF> Wait.  Does that mean we'll have two copies of the xulrunner code?
<micahg> RAOF: no, it's so we can jump major upgrades for FF without breaking all the rdepends on xulrunner
<micahg> RAOF: yes
<ScottK> Sounds like xulrunner needs to be removed then.
<ScottK> No way we can maintain it.
<RAOF> Eeep.
<micahg> that's why it's going to universe
<micahg> apps still build against it
<ScottK> micahg: What do you think we do here?
<micahg> ScottK: I know
<micahg> sorry
<ScottK> "Going to Universe" doesn't mean doesn't need maintaining.
<RAOF> We should, instead, have libs building against the firefox package?
<ScottK> If it's too hard for mozillateam to maintain in Main, what hope do we have?
<micahg> RAOF: no -dev packages
<ScottK> Sounds like time for a pile of removal bugs then
<RAOF> Man, this would be so much easier if gecko was an actual library.
<micahg> RAOF: I already showed you the bug for that :)
<micahg> ScottK: you'll have to talk to asac about that
<RAOF> micahg: No, that was the bug to make SquirrelMonkeyFish an actual library :)
<micahg> it seems like most upstreams are moving away from xulrunner anyways
<RAOF> On the basis that it's a huge pain in the arse, I'd guess.
<ScottK> No.  I'll take it up with the release team.
<RAOF> Apart, of course, for gnome-shell.  This could make MM... interesting.
<RAOF> I presume we'll want gnome-shell in main for MM, which means gjs in main, which means some form of libmozjs in main available for it to link to.
<micahg> ScottK: here's the blueprint: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model
<ScottK> I'm familiar with the Firefox part, not the dumping unsupportable crap on the community part.
<micahg> sorry ScottK, I never thought of it like that
<ScottK> micahg: That's the effect.
<RAOF> Presumably something's been done about couchdb, too, which I presume we still want in main for Lucid?
<ScottK> Seems like an odd thing for a database to depend on.
<RAOF> Javascript!
<micahg> RAOF: idk, we might help them port to webkit if they're willing
<RAOF> Chromium has an actual javascript library, doesn't it.
<RAOF> libv8 IIRC.
<micahg> RAOF: they're worse than mozilla about versioning
<micahg> ScottK: can I ask you about the zend framework backport?
<RAOF> Does *anyone* have a javascript library that has an actual stable ABI?
<zooko> Greetings, folks!  We're hard at work on a new version of Tahoe-LAFS.  Our plan for releasing a new version in time to get uploaded into Lucid has slipped twice now: http://allmydata.org/pipermail/tahoe-dev/2010-January/003621.html
<micahg> RAOF: I think webkit does
<RAOF> Dear lord!
<ScottK> micahg: What bug?
<micahg> bug 488633
<ubottu> Launchpad bug 488633 in karmic-backports "Please backport zend-framework 1.9.6-0ubuntu1 from Lucid" [Wishlist,Fix released] https://launchpad.net/bugs/488633
<zooko> And by the way, check out this praise of Tahoe-LAFS from a blue-ribbon panel of USA national cyber defense experts: http://tinyarro.ws/zooko
<micahg> ScottK: there was a security alert for that version and we pushed 1.9.7 already
<micahg> can I change the bug to that version?
<ScottK> micahg: Yes.
<micahg> can you reack afterwards?
<ScottK> Let me know when you're done and I'll ack the change.
<fabrice_sp> Does it makes sense to drop .la files from a -dev package ? I'm looking after a merge, and the main difference is that .la files are not installed anymore
<micahg> ScottK: done
<micahg> oops, I should confirm too
<RAOF> fabrice_sp: .la files aren't useful at best and are annoying at worst.  If the new debian revision doesn't install the .la files, that's perfectly fine.
<micahg> ScottK: really done this time :)
<fabrice_sp> RAOF: thanks! That means that one can be a sync ;-)
<fabrice_sp> is it the same with .a files?
<fabrice_sp> aren't they used for static linking?
<RAOF> Yes, they are.
<RAOF> That't exactly what they are.
<fabrice_sp> ok. Thanks again :-)
<siretart> fabrice_sp: libtool requires them. they are not strictly needed by ld(1)
<RAOF> .la are quite different, though.  They do a similar job to pkg-config, but in a more convoluted way that everyone seems to hate.
<siretart> they are plain text files with various meta information
<siretart> oh, I'm talking about .la files. .a files are ar(1) archives of object files (.o)
<fabrice_sp> ok. Just in case, I'll check that rdepends still builds then
<ScottK> micahg: Ack'ed.
<micahg> ScottK: thanks
<dholbach> good morning
<kees> YokoZar: wine isn't installable.
<kees> YokoZar: wine (1.1.36-0ubuntu2) Depends: wine1.2, but wine1.2 (1.1.36-0ubuntu2) Conflicts: wine (<< 1.2)
<andruk> how do i tell pbuilder to add my ppa from launchpad to its sources.list?
<Hobbsee> andruk: othermirror in .pbuilderrc
<andruk> so i put the line 'OTHERMIRROR="deb http://ppa.launchpad.net/csm-ticc/tablettray/ubuntu karmic main"' in my ~/pbuilderrc, but how do i add my gpg key?
<directhex> andruk, you don't need your gpg key, apt in pbuilder runs unauthenticated
<andruk> tell that to: http://pastebin.ubuntu.com/360524/
<andruk> on second look though, thats only a warning...
<andruk> thanks Hobbsee and directhex
<andruk> :-)
<BlackZ> I have this error when I run "debuild -S": http://paste.ubuntu.com/360560/
<BlackZ> and I can't sign the public key
<randomaction> BlackZ: debuild -S -us -uc will create an unsigned package
<BlackZ> randomaction, yes, but I should sign it, or not?
<geser> signing is only important when you want to upload it
<BlackZ> geser, yes, I should upload it
<randomaction> signing is necessary when you are uploading to archive or PPA
<BlackZ> so I must sign it
<randomaction> you need a key, then
<BlackZ> I have created, but I can't sign it
<geser> try "debsign -k0x22C75AE3 autotrash_0.1.1-0ubuntu1_source.changes"
<BlackZ> geser, http://paste.ubuntu.com/360563/
<randomaction> your key ID must match your name/address in changelog
<geser> he did specify the key id in the last attempt
<randomaction> it may be a problem with your gpg setup, as it can't find the key
<geser> BlackZ: does "gpg --list-secret-keys" list your key?
<BlackZ> geser, yes
<geser> hmm
<geser> have you tried if you can sign a file (doesn't matter what kind of file) with gnupg?
<BlackZ> geser, Successfully signed dsc and changes files
<BlackZ> solved
<BlackZ> thank you
<BlackZ> I have re-created the key
<BlackZ> without "BlackZ" as comment in the key
<^arky^> Hi, any compiz packing team member help me patch bug 507964
<ubottu> Launchpad bug 507964 in compiz "Application Switcher keybinds conflicts with gnome default" [Undecided,New] https://launchpad.net/bugs/507964
<dholbach> ^arky^: try #ubuntu-dekstop
<dholbach> ^arky^: try #ubuntu-desktop
<dholbach> sorry :)
<^arky^> thanks dholbach will do that
<YokoZar> kees: yeah I meant to do it the other way (and have wine >> wine1.2)
<hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - I think I've done everything that fabricesp said. http://revu.ubuntuwire.com/p/qt-shutdown-p
<sebner> hakaishi: I don't really have time to review it but another point would be the changelog. Use -0ubuntu1 instead of -0ubuntu2
<sebner> hakaishi: maybe make rules files more readable too (some newlines wouldn't be bad)
<hakaishi> sebner: I thought that it should be -0ubuntu2 if it is a second upload with the same source...
<hakaishi> sebner: okay, thanks
<sebner> hakaishi: oh, I didn't know it's already in the archive
<hakaishi> sebner: ah^^ ... seems I mistook something right now
<sebner> hakaishi: nah it's not in the archive. New stuff enters the archive generally with -0ubuntu1, then you increment the versionsnumber for further uploads
<hakaishi> sebner: Is it okay now?
<sebner> hakaishi: looks better now but wondering about your rules file anyways. Normally, http://pastebin.com/m4b8274cf should be enough but it fails. What's with this permissioned deniend stuff?
<sebner> hakaishi: found the issue
<sebner> hakaishi: proper solution: http://pastebin.com/m5e497858
<sebner> hakaishi: that's all you need in your rules file
<sebner> wb hakaishi , got my messages?
<persia> hakaishi: sebner: Why call dh_auto_build in override_dh_auto_build if the right thing to do is "qmake" ?
<persia> Just don't bother including that line :)
<sebner> persia: ah right, was confused with his $(MAKE) so I replaced it the sane command :)
<persia> sebner: Ah, if was previously qmake; ${MAKE}, then it's correct to call dh_auto_build
<persia> (or at least this does no harm)
<sebner> persia: haha, right. DON'T confuse me!
<sebner> persia: yeah, just testbuild. auto_build is necessary
<persia> But dh_auto_install oughtn't drop out of a build if it can't do anything.  That seems like a bug.
<sebner> persia: well, dh_auto_install normally calls make install and there is no such thing, he installs the stuff manually with dh_install (.install file), so you have to skip it or it fails imho
<persia> sebner: Right, I understand the application here.  I just think it's a workaround for a bug.
<sebner> persia: sure, bug of debhelper. shouldn't fail but skip automatically
<persia> I think dh_auto_install ought fail gracefully if there isn't an install rule.
<persia> Right.
<sebner> persia: poor people like us have to use workarounds :)
<persia> sebner: Why?  Surely your perl is sufficient to fix it :)
<sebner> persia: no perl et al :P
<persia> Oh well.
<sebner> persia: C#, java and after some dirty haXX0ring and copying python. nahh, .. the youth of today. such useless languages :P
<Laney> date
<sebner> hi Laney
<Laney> excuse me
<persia> Fri Jan 22 14:46:58 UTC 2010
<Laney> hi sebner
<sebner> Laney: haha, we now have persia bot :P
<hakaishi> persia: just a moment please. I'm a little confused. I just have to override_auto_build: with qmake? But pbuilder will fail with permission denied... so I'll have to add a override_auto install: dh_install. Is that right?
<sebner> hakaishi: proper solution: http://pastebin.com/m5e497858
 * persia agrees with sebner
<hakaishi> okay, thank you
<sebner> hakaishi: auto_install only fails because there is nothing to install
<sebner> dh_install is for the .install file
<persia> Well, at least it's as proper as we're going to get without hacking debhelper.
<sebner> which would be override_dh_install what you don't need
<persia> Or creating an install: rule and overriding the entire sequence.
<persia> (which you also don't need)
<sebner> persia: I'll check if there is already an open dh bug about it
<persia> sebner: The workaround is mentioned in the manpage :)
<sebner> hakaishi: the easiest for now is really my proposed solution
<sebner> persia: haha, fail by design then
<hakaishi> ^^
<persia> sebner: Well, it still works for 90% of packages, which was the point.
<sebner> persia: you are right but speaking about sanity ...
<persia> heh.
<hakaishi> perhaps this ist because I have a install rule in the Makefile
<sebner> hakaishi: you should make sane makefiles then :P
<persia> hakaishi: If you put an install rule in your makefile that respects DESTDIR, you should be able to drop your install file and let dh_auto_install do it's magic.
<sebner> persia: wah wah wah, the manpage speaks about 90% working packages and "Skip it and ***run make install manually***", and the manpage says: if there's a Makefile and it contains a "install" target. The word here is ***if*** so it's a real bug imho as it seems that it should work/skip automatically
<persia> sebner: Interesting point.  I can see that argument.  File the bug :)
<hakaishi> ahm, the Makefile is generated like that, because I want the possibilty to install from Source to
<Laney> why does it fail here?
 * Laney has projects where the makefile doesn't have an install target which dh7 copes with fine
<sebner> persia: Laney : Oh, it might be another bug. It fails with "permissioned" deniend for some files so the makefile might be b0rken and not dh_auto_install itself
<persia> hakaishi: have your upstream Makefile install to ${DESTDIR}/${PATH} rather than /${PATH}.  If DESTDIR is unset, it will install to system locations.  If it is set, it will install for packaging.
<persia> Indeed.  It sounds like an issue with the Makefile.
<Laney> I would guess that is the case
<Laney> it's probably trying to install into the system
 * sebner says sorry to his beloved dh7 and gives it a cookie :)
<hakaishi> persia: why do I need to upstream the Makefile, if it is generated by qmake?
<persia> hakaishi: You don't.  In that case, you want to draft a qmake source file that generates an install rule that installs to ${DESTDIR}/${PATH}
<hakaishi> persia: Sorry, I don't get it...
<persia> OK.  Let's set qmake aside for the purposes of discussion.  We'll get back to it once the desired behaviour is clear.
<persia> So, you have a Makefile with an install rule.  You want this to be able to be used by people who don't use the package, so they can run make; make install
<persia> But when you run that install rule inside a package build, it fails, because it doesn't have permission to write to system locations.
<hakaishi> persia: but this is what it already does, isn't it?
<persia> Yes.
<persia> The Makefile probably has lots of lines like `install -m 755 /usr/bin/foo`
<c_korn> can someone explain me what the deploy.tar.gz here is for ? I thought in source format 3 there is only a orig.tar.gz and debian.tar.gz file: http://packages.debian.org/source/sid/jxplorer
<persia> If the Makefile instead had lines like `install -m 755 ${DESTDIR}/usr/bin/foo`, then if DESTDIR is unset, the behaviour would be unchanged.
<persia> This is good for the `make; sudo make install` case.
<persia> Within the packaging, DESTDIR will be set, so it ends up installing in /foo/bar/baz/quux/debian/tmp/usr/bin/foo
<hakaishi> aha, I get it. thanks
<persia> Which means that the *same* rule in the Makefile can work for both the non-packaged case and the packaged case.
<persia> So you just need to change the qmake source to do that.
<persia> c_korn: See the .dsc.  As I understand it, one can have an arbitrary number of objects defined, and the dsc ties them together.
<sebner> persia: isn't it about multiple tarballs?
<persia> c_korn: In this specific case, it appears that upstream has a separate source release and installer release, and these have been packaged together.
<^arky^> Modifying site packages variable, need help with bug 499990
<ubottu> Launchpad bug 499990 in labyrinth "fails to start due to missing package import" [Undecided,New] https://launchpad.net/bugs/499990
<persia> sebner: "objects" can be "tarballs", if one likes :)  I believe one can also use zip archives, flat files, etc.
<sebner> c_korn: http://wiki.debian.org/Projects/DebSrc3.0  ... samples: # sample1: 3.0 (quilt) with orig.tar.gz / debian.tar.gz and additional tarballs with all compressions schemes   <-- this might be
<sebner> persia: ohh, I didn't know zip and that stuff is allowed too
<sebner> persia: ah, *all* compressions schemes
<persia> sebner: I'm not 100% sure that other stuff works now, but I believe that was the long-term intent.
<c_korn> sebner, persia: thank you
<sebner> persia: nvm. I'm just happy that now .gz and .bz2 is allowed as upstream tarball :)
<sebner> c_korn: yw
<^arky^> dholbach: a quick question about labyrinth package
<dholbach> ^arky^: shoot
<^arky^> dholbach: bug 499990  'site-package' is hardcoded
<ubottu> Launchpad bug 499990 in labyrinth "fails to start due to missing package import" [Undecided,New] https://launchpad.net/bugs/499990
<^arky^> in bin/labyrinth and labyrinth/defs.py
<dholbach> ^arky^: if you want to fix it, please go ahead, I'm happy to sponsor it or take a look at it
<hakaishi> persia: I don't know how do this in the .pro file, can you tell me?
<persia> hakaishi: Sorry, I've never used qmake.
<^arky^> dholbach: Thanks, doing just that. My question is should I patch all the files under debian/ directory ?
<hakaishi> persia: okay, then I'll just try another time. cu
<dholbach> ^arky^: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#CDBS with Simple Patchsys
<^arky^> dholbach: thank you
<dholbach> no worries :)
<dholbach> thank YOU
<jariq> Upload to revu via ftp from network behind the proxy does not work for me ? Is there any way to upload via http ?
<persia> jariq: There isn't.
<ockham> hi, i'm a newbie with a rather trivial question: what do i have to specify in debian/rules if the actual sources (including autotools files and everything) are in a subdirectory of a package?
<^arky^> dholbach: you still around man
<dholbach> ^arky^: yep
<ockham> anyone? i tried  dh $@ --sourcedirectory=src, but that doesn't seem to do the trick
<^arky^> dholbach: source uses '@PYTHONDIR@' variables where does this get site in debian package?
<ockham> there's a line: AUTOMAKE=automake-1.9 autoreconf -ivf
<ockham> that causes a choke: autoreconf: `configure.ac' or `configure.in' is required
<ockham> (in override_dh_auto_clean)
<^arky^> dholbach: Is it the  'configure' file  that gives '@PYTHONDIR@' values ?
<dholbach> ^arky^: I don't know - might be worth forwarding that bug to upstream
<^arky^> dholbach: ok
<jdong> AAAH stupid PPA!
<sistpoty> hi folks
<geser> Hi sistpoty
<sistpoty> hi geser
<sistpoty> haha, I'm so lazy, I don't even upload anything myself anymore: bug 495772 :)
<ubottu> Launchpad bug 495772 in pearpc "Unable to compile package acquired through apt-get source" [Undecided,Fix released] https://launchpad.net/bugs/495772
<BlackZ> hello geser ;)
<ajmitch> hi
<geser> Hi BlackZ, ajmitch
<sistpoty> hi ajmitch
<sistpoty> (so ctrl-w closes a kvirc window, as I just figured *g*)
<ajmitch> heh
 * ajmitch wonders when wgrant will be around this morning
 * sistpoty grumbles a little bit about ScottK for sagemath... downloading a 57MiB tarball doesn't suggest getting it in shape again will be a simple task
<ScottK> sistpoty: I think we're going to have to remove it.
<sistpoty> ScottK: oh? so I should focus my work elsewhere?
<ScottK> Debian maintainer said it needs a new upstream release to work with Python 2.6.
<ScottK> Yes.
<ScottK> Unless you really want to package it (it's a beast I understand)
<sistpoty> ScottK: not really
<ScottK> Boost transition is done.
<ScottK> My suggestion is work on FTBFS or NBS.
<ScottK> I don't have a hard one handy.
<sistpoty> ok, will do, thanks ScottK!
<siretart> sistpoty: I noticed a bunch of ftbfs packages while rebuilding ffmpeg's reverse depends
<sistpoty> hi siretart
<siretart> sistpoty: I didn't check all logs, but none of those I've seen were because of ffmpeg, all were because of other problems
<siretart> hi sistpoty  :-)
<sebner> huhu sistpoty siretart :D
<sistpoty> hi sebner
<siretart> hi sebner!
 * sebner reads the backlog in case somebody already asked siretart about gstreamer-plugins-bad
<sistpoty> siretart: got a package you want me to look at in particular?
<siretart> sistpoty: http://paste.ubuntu.com/360846/
<siretart> is a copy of my ftbfs folder
<sistpoty> thanks siretart, I'll start with k9copy
<sistpoty> hm, where is k9copy from? marillat?
<sistpoty> oh, looks like ubuntu native one :)
<geser> siretart: you can strike out smilutils from that list, this one is already fixed
<randomaction> sebner: I'm not sure what's the deal with gstreamer-plugins-bad, but we have a ftbfs fix for gst-plugins-bad0.10 waiting to be sponsored
<sebner> randomaction: sounds interesting :D
<siretart> geser: excellent. thanks
<sebner> hola hola geser :)
<geser> Hi sebner
<Quintasan> hello
<wgrant> ajmitch: Hi.
<ajmitch> wgrant: morning, going to head out & enjoy the sunshine today? :)
<wgrant> ajmitch: Ahem.
 * ajmitch has had breakfast but probably needs some caffeine to function for the day
<sistpoty> hm.... /var/lib/dpkg/info/tex-common.postinst: 1011: kpsewhich: not found (dependency problem? worked fine after a dpkg --configure -a)
<randomaction> could it be somehow related to texlive-base binaries sitting in the NEW queue?
<geser> bah :( no new TeX before next week
<siretart> oh, tl2009 is in lucid NEW? \o/
<geser> siretart: actually texlive-base 2009-7 is already through NEW
<geser> thanks to out-of-order processing done by jdstrand :)
<jdstrand> jeez, give me a second to get through it! ;P
<jdstrand> geser: what else is needed besides that?
<geser> jdstrand: I don't see anything TeX related in the NEW queue left
<jdstrand> k
<jdstrand> fyi, texlive was the only thing I deNEWed related to that
<nixternal> hello
<highvoltage> !ops
<ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds!
<xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<nixternal> !ops +R this channel
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<ybtbk> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<ybtbk> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<ybtbk> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<hxukurq> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<hxukurq> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
<nixternal> thanks tsimpson
<jussi01> just a note, do not click that link
<nigel_nb> okay, now i understood what those attacks were
<nixternal> lol
<nixternal> tsimpson: no worries, you got it under control
<tsimpson> ahh, SECURE is set
<dhillon-v10> hi all, I filed this bug a little while ago: https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/507778 so can anyone sponsor it, it been on the queue for a while
<ubottu> Ubuntu bug 507778 in acpid "Please merge acpid (1:2.0.0-1) from Debian testing" [Undecided,New]
<geser> you need a core-dev for that as it's in main
<jpds> dhillon-v10: slangasek and mathiaz discussed that request yesterday.
<dhillon-v10> geser: alright
<dhillon-v10> jpds: so what happens now, I should wait for some time right
<jpds> I'd talk to thme firsyt.
<dhillon-v10> mathiaz: ping regarding a merge :)
<dhillon-v10> jpds: alright :)
<mathiaz> dhillon-v10: well - the question is whether the new version of acpid (2.0.0) should be pulled in lucid - considering that it's new code (?) for a an LTS
<mathiaz> dhillon-v10: as I'm not familiar enough with acpid, I defer to slangasek on wether 2.0.0 should be pulled in
<dhillon-v10> mathiaz: alright that makes sense, well the good thing is that I am getting better at merges (slowly)
<mathiaz> dhillon-v10: right - the issue here is not wether your work is should be improved, but rather if we should *actually* merge the new version
<dhillon-v10> mathiaz: understood :) thanks for the info.
<mathiaz> dhillon-v10: some packages are more touchy - it may well turn out that 2.0.0 should be included in Lucid
<mathiaz> dhillon-v10: in which case your merge proposal will be reviewed again
<dhillon-v10> mathiaz: true, this one goes to main so its understandable
<dhillon-v10> mathiaz: oh wait, while you are around, can you tell me why one of my patches isn't applying, let me get you the link
<dhillon-v10> mathiaz: alright this one: https://bugs.launchpad.net/ubuntu/+source/cln/+bug/508995
<ubottu> Ubuntu bug 508995 in cln "Please merge cln (1.3.1-2) from Debian Testing" [Undecided,New]
<mathiaz> dhillon-v10: which package did you merge from?
<mathiaz> dhillon-v10: the changelog entry in the diff shows an entry for unstable
<mathiaz> dhillon-v10: so you haven't probably merged from the *latest* version of debian
<dhillon-v10> mathiaz: the testing one, here: http://packages.debian.org/changelogs/pool/main/c/cln/current/changelog
<mathiaz> dhillon-v10: the base debian package you've used is 1.3.1-1
<mathiaz> dhillon-v10: in the diff, you can see entry for 1.3.1-2 - that shouldn't be there
<mathiaz> dhillon-v10: you wanna attach the debdiff between the debian version and the merged ubuntu version
<mathiaz> dhillon-v10: the *latest* debian version - which in this case is 1.3.1-2
<dhillon-v10> mathiaz: alright I see what I did wrong, but the merge was mostly done by bzr so I don't understand what went wrong there
<mathiaz> dhillon-v10: probably that the bzr branch for the Debian package wasn't up-to-date
<dhillon-v10> mathiaz: alright I guess I am better off merging by hand :)
<dhillon-v10> mathiaz: would you be around in like 5 mins. so i can show you my diff
<mathiaz> dhillon-v10: I should be
 * persia idly notes that #ubuntu-devel may be a more appropriate place to discuss issues with seeded packages.
<persia> (or some more specific channel)
<dhillon-v10> persia: alright so there's a different package and when I merge that, it turns out that the only change is in changelog and control file, that's it, I double checked and nothing is there, is that possible
<persia> Yep.  I just fixed FTBFS for plymouth on four architectures with a change like that to libdrm recently.
<geser> sure, if Debian merged our changes, then only our changelog entries and the updated Maintainer field are left after a merge (which should be a sync then)
<persia> The important thing to check is *which* changes to debian/control
<persia> Another example would be the outstanding tiemu merge, which just has some dependency changes because we don't have iceweasel.
<dhillon-v10> persia: yeah I checked that like 4 times, and the last upload fixed got about everything so :)
<persia> As geser said, if all the fixes have been applied upstream, you can just sync and drop the changelog and maintainer changes.
<persia> Just make sure there's nothing missing.
#ubuntu-motu 2010-01-23
<pucko-> can someone help me with this build error http://pastebin.com/d1421fbca ? It compiles fine with configure && make. and worked fine with debuild a minute ago. don't know what I've changed.
<tgm4883> I'd like some input on this subject. There is a configuration utility that among other things, allows the adding of additional third party repos. ATM, it currently adds the repo, refreshes, adds the repo key, refreshes again, then you can install codecs. Would it be possible to have the repo key included in the configuration utility which would cut down on one of the repo refreshes?
<tgm4883> technically I know that is possible, I want to know if that would be allowed in Universe
<RAOF> Is the configuration tool available in Universe?  What is it?
<superm1> RAOF, he's referring to mythbuntu-control-centre.  one of the plugins has support to turn on medibuntu for the user, so it basically just does the same steps that the wiki currently advertises
<RAOF> Ah, right.
<superm1> so the thought is to just pack the gpg key in with the plugin so that step is skipped
<RAOF> I don't, personally, see why including the repository key in the mythbuntu-control-centre package would be frowned upon.
<superm1> it just feels like one of those gray areas
<RAOF> You're already doing essentially that; it's no less secure to ship the key (and add it to the apt-keyring just before doing the update).
<superm1> yeah, and it's all entirely opt in /optional anyway
<RAOF> In fact, it's *more* secure - there's not the possibility of someone hijacking medibuntu, adding their own repository key, and then going to town with malware.
<superm1> if only libdvdcss2 wasn't so useful for dvd playback :]
<ScottK> As a rule we don't allow packages to download from external repositories.
<superm1> ScottK, reference?
<ScottK> We have a trust boundary that includes upstreams, Debian, and the Ubuntu archive.
<ScottK> Medibuntu is outside of it.
<superm1> you do realize that libdvdread4 includes something just like that though, /usr/share/doc/libdvdread4/install-css.sh
<ScottK> I don't have a specific reference, but it's a pretty basic security principle.
<ScottK> Right, so we have bugs.
<ScottK> The first upload of Envy was almost removed from the archive because it downloaded drivers from a PPA.
<ScottK> It got fixed to not do that, so it stayed.
<ScottK> Bug #220385 for reference
<ubottu> Launchpad bug 220385 in envyng-core "envy needs to pull drivers from multiverse, not PPA" [Medium,Fix released] https://launchpad.net/bugs/220385
<ScottK> Note who filed it.
<superm1> kees, could you weigh in on this then?
<superm1> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=223961 provides some history on the tool for enabling css
<ubottu> Debian bug 223961 in libdvdread3 "libdvdread3: makes download of possibly illegal libdvdcss too easy" [Critical,Fixed]
<kamalmostafa> ScottK: Hi Scott.  Reminder - libtifiles/libticalcs still awaits your review.
<ScottK> kamalmostafa: Yes.  It's still on my list.  For tonight or tomorrow depending on how long before I pass out and if any new work crisis arises.
<ScottK> (still on the [hopefully] last work crisis of the day)
<kamalmostafa> Very good - thanks.
<nigel_nb> maco, got a min? need a little hand with figuring out dependencies
<maco> sure sure
<nigel_nb> its lernid..its missing a dependency
<maco> ooh shiny
<nigel_nb> though not in packages yet, I want to branch and fix the bug I had in my system
<nigel_nb> so, all I have to do it make the edit in debian/control?
<maco> yep
<maco> and of course add to the debian/changelog
<nigel_nb> ah, yes
<nigel_nb> that needs to be done even for bzr packages?
<maco> yes
<maco> you can add to the debian changelog and then debcommit and your bzr commit will include the debian changelog entry as the bzr commit log entry
<nigel_nb> isn't there a command for that or should i do it manually?
<maco> dch -i
<maco> will give you a skeleton for your changelog
<nigel_nb> jono has changelog modified only for version releases
<nigel_nb> which makes me nervous whether to change it
<maco> is that the Changelog or debian/changelog ?
<nigel_nb> debian/changelog
<maco> oh!~
<maco> i see. you're working on the upstream bit, not on an in-ubuntu's-repos package?
<nigel_nb> maco, um, lernid is still in PPA
<maco> i havent been paying that close attention...it's gkt
<maco> *gtk
<maco> if you're just gonna do a merge request on the project, dont worry about debian/changelog
<nigel_nb> ah
<nigel_nb> whts gtk?
<maco> just making a joke since its written with the same libraries as gnome, and i use kde ;)
<nigel_nb> maco, boo!
<nigel_nb> lernid works on kde too I think
<nigel_nb> I'm on xfce and I had trouble getting it working, thats the dependency i'm fixing
<maco> what was the missing dependency?
<nigel_nb> back on topc, when doing bzr commit like that, I dont have to leave bug number and stuff right? LP takes care of it I believe
<nigel_nb> telepathy-idle
<maco> bzr commit --fixes ... i think?
<maco> bzr commit -m "adding dependency in debian/control" --fixes 12345
<nigel_nb> oh, thats pretty cool
<nigel_nb> maco, thanks.  I pushed that branch :)
<maco> i think you still have to go into launchpad and manually do the merge request though
<nigel_nb> yeah, I do.  but thats familiar territory
 * nigel_nb works with bzr for uclp
<nigel_nb> but not the bug fixing part
<nigel_nb> maco, LP shows the bug connection (which is cool)
<nigel_nb> maco, is there a way to know for sure what packages get shipped in the Live CD without putting one in? I mean I want to compare package in ubuntu and xubuntu.
<maco> the ubuntu-desktop and xubuntu-desktop meta-packages should tell you what varies
<Flannel> nigel_nb: the .manifest files list the packages compiled into the casper image: http://releases.ubuntu.com/9.10/ubuntu-9.10-desktop-i386.manifest
<nigel_nb> Flannel, thanks
<nigel_nb> maco, um? a little longer explanation
<nigel_nb> Flannel, is there somethin similar for xubuntu?
<Flannel> nigel_nb: http://mirror.anl.gov/pub/ubuntu-iso/CDs-Xubuntu/9.10/release/xubuntu-9.10-desktop-i386.manifest
<nigel_nb> Flannel, thank you.  I finally did find it on http://cdimage.ubuntu.com/xubuntu/releases/karmic/release/ :)
<nigel_nb> anyway the bug is confirmed at least.  telepathy-idle package is on ubuntu by default and not xubuntu
<kees> superm1: I'd rather css got installed somehow with a verified key, but this is a long standing exception, afaiu.
<superm1> kees, is this maybe worth raising to the tech board to add css to multiverse?
 * kees whistles
<kees> I would rather a a sha512 was distributed with the package, easier to deal with it legal-wise.
<superm1> as in sha512 and wget a'la flashplugin-installer?
<kees> yeah.  I think it fetches source and builds it?  I really haven't looked at it in a while now.
 * kees has to run; I'll read scroll-back
<tgm4883> party on kees
<superm1> it fetches the source package and builds that from what it looks (install-css.sh)
<fabrice_sp> in a fakesync, we just substitute the debian directory from ubuntu with the debian one, without keeping any history from ubuntu in the changelog, right?
<superm1> kees, well lets talk this through to come up with a good happy medium to keep in mcc for users when you get a chance then
<ScottK> fabrice_sp: Yes.
<ScottK> fabrice_sp: It should be just like a sync, but using the Ubuntu tarball.
<fabrice_sp> ScottK, what should be the version? ubuntuX or buildX? My feeling is that with buildx , it will be autosynced
<ScottK> fabrice_sp: It would be and you don't want that.
<ScottK> Use ubuntu1 and then once there's a new version Debian, file for a regular sync
<fabrice_sp> ohh, in case there is a new debian/non upstream version, right
<fabrice_sp> ok
<fabrice_sp> thanks
<ScottK> Exactly
<AnAnt> Hello, can I set a bug to be blocked by another bug in LP ?
<ScottK> No
<AnAnt> ScottK: how then can I deal with LP 511069 , which cannot be solved unless LP 491880 is solved ?
<ubottu> Launchpad bug 511069 in zekr "Sync zekr 0.7.5~beta3+repack-1 (multiverse) from Debian unstable (non-free)" [Wishlist,Incomplete] https://launchpad.net/bugs/511069
<ubottu> Launchpad bug 491880 in eclipse "eclipse source package provides libswt* binary packages that would conflict with swt-gtk" [High,In progress] https://launchpad.net/bugs/491880
<AnAnt> add a remote bug watch ?
<ScottK> Not sure.
 * ScottK just knows LP doesn't support it.
<AnAnt> ok
<fabrice_sp_> AnAnt, usualy, I subscribed myself to the 'blocking bug' and let the other one as In progress
<AnAnt> fabrice_sp_: ok, you received my reply that I just sent ?
<fabrice_sp_> not yet :-)
<fabrice_sp_> (I have some lag)
<AnAnt> ok
<fabrice_sp_> AnAnt, just keep the sync on hold, then
<AnAnt> fabrice_sp_: I set it to In progress
<fabrice_sp_> ok
<randomaction> If I'm not mistaken, new TexLive means libkpathsea4 -> libkpathsea5 transition, so I opened bug 511502 for that.
<ubottu> Launchpad bug 511502 in xdvik-ja "TeXLive 2009 transition: libkpathsea5" [Undecided,New] https://launchpad.net/bugs/511502
<hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - There are no lintian warnings or other errors. The debian/rules will be okay like that, I hope (since the Makefile has a install rule). http://revu.ubuntuwire.com/p/qt-shutdown-p
<geser> randomaction: looks like the easy case from bug #511502 are done: 3 packages from main wait sponsoring, I've left evince for the desktop team
<ubottu> Launchpad bug 511502 in xdvik-ja "TeXLive 2009 transition: libkpathsea5" [Undecided,In progress] https://launchpad.net/bugs/511502
<randomaction> geser: thank you for your help
<randomaction> there's also cjk which FTBFS, dunno why, it's ok in my pbuilder
<geser> dvi2dvi and dvipsk-ja have a FTBFS bug open in Debian, dvi2ps and important bug about the transition
<geser> and texfam needs a removal bug filed (it got removed from Debian but not yet from lucid)
<randomaction> tmvew also FTBFS in Debian and Ubuntu
<ahe> i get a MOD_PYTHON ERROR on http://revu.ubuntuwire.com/
<ahe> http://pastebin.com/m763955b7
<geser> randomaction: re cjk: I guess it's because of "texlive-base-bin". it's a provided now by texlive-binaries but as the old (real) debs didn't got removed yet (they are listed in NBS) the dependency doesn't get resolved always correctly
<randomaction> so binary should be removed to make way for that build?
<geser> cjk should build properly once texlive-base-bin gets removed from NBS (most of the listed package there have an unversioned dependency on it, so they continue to work with texlive-binaries, no work needed)
<geser> yes
<geser> we have currently the real but uninstallable texlive-base-bin and the installable texlive-binaries providing texlive-base-bin
 * sistpoty gives a shot at ktoon
<c_korn> where can I find information why pysol has been removed from the repos ? http://packages.ubuntu.com/jaunty/pysol
<randomaction> c_korn: https://launchpad.net/ubuntu/+source/pysol/+changelog
<c_korn> randomaction: thanks, and sorry I did not find it. it was quote obvious to have a look there :/
<randomaction> np :)
<hakaishi> Hey, what happend to revu.ubuntuwire.com?
 * persia huns
<persia> hunts!
<persia> hakaishi: I can't tell right now.  Seems there's some issue connecting to postgres, except postgres claims to be running.
<persia> I'll report to someone who has a chance of fixing it :)
<hakaishi> I just hope it'll be fixed soon ^^
<persia> Indeed.  That being down is annoying.
<hakaishi> okay, bye bye
<sistpoty> hmpf, I installed a postgres update tomorrow, but it did work then :/
<persia> hakaishi: By the way, your qt-shutdown-p 1.6-all~karmic1 upload was rejected.
<persia> sistpoty: Everything always works tomorrow :)
<sistpoty> heh
<persia> (and may I borrow your time machine?)
<sistpoty> *g*
 * sistpoty restarts apache
<persia> Lovely.  Works great now.
<sistpoty> that was easy :)
 * persia digs through the rejected queue and cleans up
<ahe> could someone please take a look at my package of rubyripper (a CD ripper that can handle intentionally crippled audio CDs) at http://revu.ubuntuwire.com/p/rubyripper ?
<persia> ahe: There are some control file bits mentioned by lintian that are worth fixing.
<persia> ahe: Are you using a VCS to maintain this package?
<ahe> persia: is there a reason why lintian didn't mention those problems when i built the package with debuild on my local system?
<ahe> persia: i have a bazaar branch but i don't build directly from it but just build the working copy manually with debuild
<persia> I don't think the lintian run by debuild checks very much.
<persia> ahe: Well, you've patches to the source outside debian/ without a patch system.  That's OK, as long as you're using a VCS to manage the patches, but if you're not intended for a VCS to be used to manage patches, it would be better to use a patch system.
<persia> Otherwise it becomes just a monumental pain to merge the changes every new upstream release.
<sistpoty> ahe, persia: the lintian notes are only informational, and I'd rather not move things from build-dep to build-dep-indep, as sbuild disagrees with policy when to install build-dep-indep
<ahe> persia: ok so does that mean that bzr will replace traditional patch systems?
<persia> sistpoty: Hrm?  sbuild doesn't usually give me issues.  I run with -A for i386, and without -A for other architectures (as we do in Ubuntu).
<persia> ahe: That depends on the relative success of Format 3.0(bzr) :)
<persia> ahe: But more generally, if one is using a VCS, a patch system can seem annoying, and if one is using a patch system, a VCS can seem like duplicate overhead.  They both represent ways of handling variations to a source.
<persia> Doing one or the other is good.  Doing both is fine.  Doing neither leads to pain.
<sistpoty> persia: iirc, build-depends-indep aren't installed for binary or binary-arch (e.g. debian bug 478524)
<ubottu> Debian bug 478524 in sbuild "debian/rules build target requires installing B-D-I" [Normal,Open] http://bugs.debian.org/478524
<ahe> persia: is there a "official" bzr repo to put packages? currently i have it in https://code.launchpad.net/~aheck/+junk/packages
<persia> ahe: That gets complicated.  There's an "offical" location where bzr repos get put, but I don't believe the converse currently exists.
<persia> Plus, unless you can upload, you wouldn't be able to commit to those branches anyway.
<ahe> i also have the problem that i build this package for my ppa and to upload to revu i "cleaned" the histroy from all ppa entries because i'm not sure if its better to have them in for completeness or make the history look "cleaner"
<ahe> so i guess its ok to use a junk repo on launchpad?
<persia> sistpoty: Hrm.  I'm not convinced that it's not better to use b-d-i, but I can see that it might have issues with some packages, although I'd consider those package bugs (not that it isn't easier to fix it in the build system).
<persia> ahe: Go ahead and use a junk repo, but I'll change the nature of my complaint based on the fact you're using a VCS :)
<ahe> :)
<freeflying> this channel is for identified users only?
<persia> freeflying: Apparently it currently is.  I believe that's intended as a limit to the current spambots.
<persia> I would expect it to go away at some point.
<persia> Hrm.  I was just looking at libpam-slurm, and a simple s/libslrum20-dev/libslrum21-dev/ in debian/control makes it build on amd64, but it fails to build on i386 with that same change, with undefined reference to `__stack_chk_fail_local' .  Anyone know what that means?
<acicula> try with -fno-stack-protector
<acicula> mind you that removes the stack canary protection system
<persia> acicula: But why would I only see this on i386 and not on amd64?
<acicula> persia: linking against precompiled code?
<acicula> or precompiled objects?
<persia> Against whatever's in the archive right now.
<acicula> with a feshly unpacked archive or did you use make clean or whatever
<freeflying> persia: thanks dude
<persia> acicula: I've called, in parallel `sbuild -A -d lucid-i386 libpam-slurm_1.6-2ubuntu1.dsc`  `sbuild -d lucid libpam-slurm_1.6-2ubuntu1.dsc` on an amd64 system.  The schroots were constructed by mk-sbuild-lv from karmic, and the pat-caches are fairly up-to-date.
<persia> I don't see any binaries in the source package, so any precompiled stuff I'd be linking against would be freshly downloaded build-deps, or build-essential stuff (which was last refreshed within the day)
<acicula> persia: well my understanding on the subject is a bit rustic. As i understand the compiled object code is trying to call that function, which is injected because of the stack protection(goverened by that flag i mentioned earlier) and the linker cant find it
<persia> Could it be the -nostdlib argument being passed to gcc?
<acicula> well what does nostdlib do?
<acicula> NOTE: In Ubuntu 6.10 and later versions this option is enabled by default for C, C++, ObjC, ObjC++, if neither -fno-stack-protector nor -nostdlib are found.
<sistpoty> persia: yes, that should be it
<acicula> in relation to stack-protector
<persia> But I'm *also* passing -nostdlib on amd64.  Do we not do stack smashing protection for amd64?
<acicula> ah found in the man page, -nostdlib could definitly be it, heh
<sistpoty> persia: you'll need to specify -nostdlib already as compiler flag, that will turn off stack-protector. if it's only in ldflags, you'll get the undefined reference (at least that's how I figure from looking at the invaders source package, and what I did there)
<acicula> RELRO           STACK CANARY      NX            PIE                     FILE
<acicula> Partial RELRO   Canary found      NX enabled    Dynamic Shared Object   /lib/libc.so.6
<acicula> compiled with canary on amd64 it seems?
<persia> http://paste.ubuntu.com/361265/ is what I got.  Do I need to patch Makefile to pass -nostdlib more agressively?
<sistpoty> persia: yes: gcc -Wall -O2   -fPIC -c pam_slurm.c
<sistpoty> persia: you'll need a -nostdlib there already, otherwise gcc will insert calls to __stk_chk_fail when compiling
<persia> Should be `gcc -Wall -O2 -nostdlib -fPIC -c pam_slurm.c` ?
<sistpoty> persia: yes
<persia> Ah, right.  Be nice if the behaviour was cross-arch.
<sistpoty> yeah, that's still a little bit puzzling, no clue why it works on amd64 ;)
 * persia is checking powerpc right now, and might just ignore i386 out of cussedness
 * sistpoty is still fighting against ktoon
<persia> Odd.  Works on amd64, fails for i386 & powerpc.
<persia> MANUALDEPWAIT just takes care of itself once satisfied, right?
<geser> yes
<persia> Then I won't worry about them, except where they can't be satisfied.
<pucko-> Ok. so I have created a ubuntu package. fixed all errors. how do I get it into ubuntu? I haven't signed it yet, because I'm not sure how.
<persia> pucko-: Put it somewhere and get two ubuntu developers to review it.
<persia> REVU can be a handy tool for this.
<sistpoty> christoph_debian: I saw that you have been working on fixing ktoon build breakage? I've added a few more hunks, so that it works now: http://paste.ubuntu.com/361323/ in case you're interested
<pucko-> persia, thanks. it's finally uploaded now.
<pucko-> but I can't see it in revu.ubuntuwire.com :-(
<pucko-> can I assume it's just slow?
<RainCT> pucko-: have you uploaded it more than 5 minutes ago?
<pucko-> something like that
<RainCT> pucko-: OK, I can check if you want. What's the package's name?
<pucko-> libtodos-agmii
<RainCT> pucko-: It was rejected because REVU couldn't recognize your signature. Is your GPG linked to Launchpad and have you logged into REVU before the upload?
<jariq> Got question about my package ipwatchd - http://revu.ubuntuwire.com/p/ipwatchd - I entered section "network" in control file and revu did not complain about it during upload. I uploaded this package to PPA and it kept refusing the package until I changed section to "net". Which value is correct for universe and where can I find the list of sections?
<pucko-> yes I have. but I guess I did something wrong there.
<pucko-> oh. my email (in the key) wasn't validated in launchpad
<sistpoty> jariq: rejecting the package due to the section is news to me, but you can use e.g. aptitude to find out about sections
<pucko-> not sure if that would fix it. how do I tell dput to let me upload again?
<sebner> sistpoty: I already stumbled myself over an interesting section error: "No section "-" known" , after some hours(!) of investigation I noticed that the section was missing entirely in control ^^
<sistpoty> sebner: ah, well, missing might be an entirely different case ;)
<sistpoty> sebner: however afaik the section is set by archive admins anyways, but I wouldn't exactly know by which means
<sebner> sistpoty: My experience is reject of the upload so archive admins don't even get in contact with it
<sistpoty> heh
<sebner> sistpoty: btw, I failed hard at the "GrunzÃ¼ge der Informatik" test, doing again in march. *being ashamed in front of sistpoty * :P
<sistpoty> sebner: I took 7 semesters for my grundstudium, which is about the maximum I could do, so don't worry :P
<sebner> sistpoty: haha, fine then :) .. also because I was only too lazy to really learn xD
<pucko-> woo! accepted
<RainCT> jariq: http://packages.ubuntu.com/lucid/ has a list of categories. Looking at the URL you can see what the name for debian/control is, in the cse for Network "net"
<RainCT> *cse=case
<ScottK> elementtree and celementtree have been removed from Debian Testing.  It would be good if someone could look at what we needed to do the same.
<DktrKranz> (ctypes will follow soon)
<ahe> i just uploaded a new package on revu and on the packages page there is the following message: "Warning! This package could not be extracted; there's no browsable directory for it on REVU."
<ahe> what does that mean?
<ahe> shouldn't revu reject my package if there is something wrong with it?
<sistpoty> ahe: source format 3?
<sistpoty> (others than that, the package name might help to take a close look)
<sistpoty> closer even
<ahe> sistpoty: http://revu.ubuntuwire.com/p/rubyripper
<jariq> ahe: did you wait 5 minutes after upload ?
<ahe> jariq: yes, but i guess not much more ;)
<sistpoty> ahe: ah, I see, you'll need to upload with .orig.tar.gz (-sa argument to dpkg-buildpackage/debuild), otherwise revu doesn't know where the .orig.tar.gz is
<jariq> ahe: i think i had the same problem with my package.. but it was just temporary right after upload
<sistpoty> ahe: let me see if I can find the .orig.tar.gz from a previous upload, then you don't need to reupload
<sistpoty> ahe: found and extracted
<ahe> sistpoty: thx i already reuploaded
<sebner> sistpoty: Is Revu already 3.0 compatible?
<ahe> strange i would have sworn i only used 'debuild -S' the last time
<ahe> thx for the help
<sistpoty> np
<sistpoty> sebner: revu is, but spooky isn't
<sistpoty> sebner: revu only calls dpkg-source -x... however spooky is (still) running hardy. dpkg there doesn't understand 3.0 yet
<sistpoty> sebner: sad thing is, that there's no official sparc support after hardy, and I've been told that it's not a too good idea to upgrade a sparc box bexond hardy
<sistpoty> beyond even
<jariq> When will be lucid repos frozen for new packages ?
<sebner> sistpoty: arghh. I suppose there isn't really a plan to fix this issue somehow?
<ScottK> sistpoty: I know that Karmic sparc is a REALLY bad idea.
<ScottK> sebner: It's a community maintained port so ....
<sebner> sistpoty: install lucid then!
<ScottK> sebner: Not on sparc.  Utterly broken.
<sebner> ScottK: sparc is br0ken, replace the server with something sane :P
<sistpoty> the best plan so far seems to be the one from ncommander: have dpkg backported
<sistpoty> others than that, migrating revu (hopefully w.o. having me to do it) would also sound pretty good
<sistpoty> *shrug*
<sebner> heh
<sistpoty> I'm really a bit clueless how to proceed best, to be honest
<ahe> sistpoty: now revu can't find orig.tar.gz for all my uploads http://revu.ubuntuwire.com/u/aheck
<ahe> guess it was a bad idea to upload it again
<sistpoty> ahe: /me looks
<ScottK> sistpoty: I don't think a backported dpkg in hardy-backports would fly.
<ahe> sistpoty: thx
<sistpoty> ScottK: as I wrote, good ideas are needed :)
<ScottK> sistpoty: Could you backport it locally and build it just for that box?
<sistpoty> ScottK: that might be an option, however iirc there was some libc <-> dpkg thingy which I'm quite afraid of.
<ScottK> Could be.
 * ScottK hasn't been tracking it.
 * sistpoty isn't too sure if that's an issue in the first place though
<sistpoty> ahe: still no .orig.tar.gz in the upload (I'll fix it locally in revu). you can verify if an .orig.tar.gz is included by looking at the .changes file prior to uploading
<sistpoty> ahe: done
<ahe> sistpoty: its present in the changes file as well as in the *.revu.upload file
<ahe> sistpoty: ah thank you very much
<sistpoty> ahe: no, it's not in the .changes file
<sistpoty> (at least the one you uploaded to revu ;))
<ahe> strange
<ahe>  5a095e5a22743f224f73bd9312274e3c997c2e6e 144044 rubyripper_0.5.7.orig.tar.gz
<sistpoty> there's a stale .orig.tar.gz lying around in incoming though
<sistpoty> ahe: http://paste.ubuntu.com/361367/, that's the latest .changes file I can find (I stripped the signature for security reasons)
<ahe> sistpoty: that is mine: http://pastebin.com/m69f46ef6
<sistpoty> ahe: did you run debuild -S -sa again after the upload? that'll overwrite your .changes file
<sistpoty> (the Date: is directly taken from changelog, so that would remain the same)
<ahe> after the first upload and then i did the last upload so far
<sistpoty> gpg: Signature made Sat Jan 23 18:06:23 2010 CET using DSA key ID 7F49A63D
<sistpoty> ahe: ^^ that's the date gpg --verify *changes tells me, I assume you have a different one?
<ahe> sistpoty: 18:21 ah of course ! it couldn't overwrite some files during the second upload and so i guess it uploaded the orig.tar.gz but didn't know it was there *doh*
<sistpoty> heh, ok, mystery solved :)
<geser> anyone familiar with vim and its python command?
<sistpoty> geser: I only know that james_w told me about ctrl-o ctrl-p (python-omni-complete), which I find quite helpful
<geser> I wanted to upgrade the omnicomplete for LP bugs (as it's still uses python-launchpad-bugs) but fail already at importing launchpadlib inside python
<geser> or more exactly the import of hashlib causes problems
<sistpoty> sorry, -ENOCLUE
<jariq> Could anyone pls review ultimate :) package ipwatchd ? - http://revu.ubuntuwire.com/p/ipwatchd - I resolved all persia's comments and now it builds without problem in my PPA.
<sistpoty> jariq: looking... as I was curious, I took a glimpse at the code of ipwatchd. Haven't seen such cleaned up code for some time ;)
<jariq> sistpoty: clean code makes many things much quicker
<sistpoty> *nod* (from own, hard-gathered experience)
<sebner> jariq: /me recommends using dh7 also in rules
<sistpoty> jariq: what about ipwatchd-script? that calls (if present) ipwatchd-gnotify (not found in the package)?
<sistpoty> jariq: anything else appears to be top-notch!
<ahe> would be great if someone would like to review my new rubyripper package http://revu.ubuntuwire.com/p/rubyripper too
<jariq> sistpoty: IPwatchD is daemon that does not require X-window. But it can run user-defined script and that script can run any desktop notification app. I separated desktop notification code into standalone package ipwatchd-gnotify (bubble notifications for Gnome environment). It is also in revu waiting for review.
<jariq> sistpoty: this way user on server can install just ipwatchd package and user on desktop can install also ipwatchd-gnotify and both packages work together without any manual configuration needed.
<sistpoty> jariq: oh, I see
<sistpoty> jariq: actually I didn't see the suggests in the first place, sorry for that
<jariq> sistpoty: thanx for advocation
<sistpoty> jariq: thanks for the package!
<sistpoty> sebner: btw.: I still haven't switched my packages to dh7 :P
<sebner> sistpoty: bah :P I'm already switching to debsrc3 :P
<sistpoty> haha
<sebner> sistpoty: dh7 + quilt -> debsrc3 = packaging heaven ;)
<sistpoty> sebner: at least I've managed quilt now (long time mystery to me)
<sebner> sistpoty: quilt is just great an superior :) It's not that difficult imho
<sistpoty> sebner: if you know how it's working, it's not... until then it is, at least for me :P
<sistpoty> (though it's completely strange that export QUILT_PATCHES=debian/patches is the magic key)
<sebner> sistpoty: ACK! I just put it once in my bashrc and it's fine but it's really strange indeed
<geser> I put the quilt recipe from the quilt README into my .quiltrc
<ScottL> hello?
<ScottL> sorry, just making sure I registered correctly
<geser> ScottL: Hi
<ScottL> I'm trying to backport Ardour 2.8.4 to Hardy but my pbuilder environment will not find and install libcurl4-openssl-dev as a dependency of libraptor1-dev, anyone have any ideas?
<ScottL> geser, hi :)
<ScottL> I can login into my pbuilder environment and install it though....real weird
<ScottL> i have hardy-updates enabled (main, restriced, universe and multiverse)
<sistpoty> btw: !ops, is the registerd user requirement still needed atm? doesn't seem to make much sense for the entry point in ubunu development, *if* there aren't too many spam attacks
<geser> have you tried to install libraptor1-dev too
<jariq> sistpoty: could you please review also ipwatchd-gnotify ? it same clean codebase, much smaller app.. should be an easy one :)
<geser> or even all build-depends?
<ScottL> geser: you mean install libraptor1-dev in the pbuilder environment first?
<sistpoty> jariq: queued, reviewing another package atm (and trying to watch a movie since about 5 hours *g*)
<geser> sometimes packages are installable itself but not in combinataion because of a conflict somewhere down the dependency chain
<sistpoty> (my !ops didn't seem to have effect, ubottu?)
<ScottL> geser: yes, I had that happen the other day...had trouble with libcurl
<geser> ScottL: login into your pbuilder environment and check if you can install all the build-depends for the package you want to build
<niko> sistpoty: try to use it at first word
<ScottL> geser, okay try installing all by hand and find where the problem is....good idea, thanks  :)
<ScottL> geser, it's always a bit of trouble backporting but this one has been particularly troublesome    lol
<sistpoty> !ops: is it still required to be a registered user for #ubuntu-motu? doesn't make much sense imho for the entry point in ubuntu development *if* the spam attacks have gone down (your call)
<niko> works
<sistpoty> yes, thanks niko!
<sistpoty> ahe: you license the packaging under GPL (w.o. version), can you make the version more clear please? (upstream is gpl-3+, so iirc packaging should not exlude later versions, but I may be wrong there)
<ahe> sistpoty: ok
<sistpoty> ahe: others than that, looking at the source only is good with me. let's see what the binaries will provide
<ahe> any idea why revu complains that it can't find the license?
<ahe> ok pushed GPL-3+ change to my launchpad branch
<sistpoty> ahe: no idea actually, maybe RainCT knows the details (called GPL-3.txt)
<sistpoty> ahe: probably doesn't fit a regexp in revu
<sistpoty> ahe: looks quite good, I guess only lintian isn't satisfied: please don't exceed 80 cols in debian/changelog, and please provide a manpage for at least rrip_cli
<ahe> a complete manpage or just a dummy one?
<sistpoty> ahe: the parse_options function should give you a clue
<sistpoty> (it's no help to have a manpage that tells: "there are options, figure them")
<sistpoty> as I'm no ruby expert, maybe help2man will do (no idea what will happen if called with --help)
 * ScottK hints at apachelogger for Ruby expertise.
<sistpoty> well, I could just try --help here :P
<sistpoty> haha, it doesn't work if extracted to a local path :)
<ahe> help2man yields quite usable output
<ahe> i think i will just rework it a bit and i have a nice little manpage
<sistpoty> excellent, ahe!
<RainCT> sistpoty: Yeah, the license check is pretty basic (it just looks for some common file names)
<sistpoty> RainCT: ah, I see... maybe add GPL-3.txt to it?
<crimsun> sistpoty: did you still need me to look at a vtk rdep issue?
<sistpoty> any DD's around who could sponsor the NMU at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527721? (DktrKranz, siretart`, ajmitch, christoph_debian, white_ just to highlight a few)
<ubottu> Debian bug 527721 in ktoon "ktoon: FTBFS: ioapi.c:13:18: error: zlib.h: No such file or directory" [Serious,Open]
<sistpoty> crimsun: as I wrote, I worked around it, but I think it's still broken (haven't checked debian though if there are news)
<DktrKranz> sistpoty: _o/
<sistpoty> crimsun: so it's wishlist priority for me
<sistpoty> hey DktrKranz :)
<geser> crimsun: Hi, just curious (no hurry), how does the testing/review of the fuse merge go?
<crimsun> geser: it works fine for me; I'd like to ping cjwatson and pitti on it
<geser> crimsun: I talked to pitti (to Â¼ of him, the other part was mentally at the sprint) about the .fdi file in our current fuse delta when I did the merge
<crimsun> geser: what was his take on it?
<geser> that the .fdi file doesn't work since karmic anyway so it can be dropped
<geser> crimsun: http://irclogs.ubuntu.com/2010/01/13/%23ubuntu-devel.html starting at 12:12
 * sistpoty goes to bed... gn8 everone
<crimsun> geser: ok, it seems mergeable to me, then. Any outstanding issues?
<geser> crimsun: I don't know of any
<ahe> i get mod_python errors on revu again :(
<crimsun> geser: uploaded, thanks!
<mr_pouit> siretart: (ffmpeg-extra) I've added locally some macros in debian/confflags to autodetect opencore-amr and pass --enable-version3 to configure script (in the same manner as --enable-nonfree). If you're interested, I can provide a patch.
<RainCT> ScottK: Hey. Is there still some point for having the python-pyclamd package?
<ScottK> RainCT: Sure.  it's a useful thing.  I think it still needs to be sync'ed from debian.
<RainCT> ScottK: Okay, just checking :). No need to sync it, there are no real changes between Debian and Ubuntu.
<perberos> gentlemens
#ubuntu-motu 2010-01-24
<ScottL_> I'm trying to backport Ardour 2.8.4 to Hardy and I'm getting this in my pbuilder during build:
<ScottL_> libcurl4-gnutls-dev: Conflicts: libcurl-dev which is a virtual package.
<ScottL_> but libcurl4-gnutls-dev provides libcurl-dev per http://packages.ubuntu.com/hardy/libcurl-dev
<ScottL_> any suggestions?
<ScottL_> oh, and libcurl-dev is a virtual package I should mention
<persia> ScottL: One way to investigate that sort of issue would be to login to a hardy chroot, and try installing each of the build-deps manually to see what packages are actually getting installed (due to virtuals and Provides, these aren't always the packages that one requests).
<persia> The goal would be to find out which two packages are actually conflicting (as virtual packages don't really exist, so there's something else present).
<persia> Once there, you can either modify the build-depends, or port the code, or otherwise try to reach some conclusion.
<ScottL_> persia: geser suggested the same and I did that earlier tonight,  liblrdf0-dev brought in libcurl4-openssl-dev and libcurl4-gnutls-dev but then
<ScottL_> vampe-plugin-sdk (my build in ppa) said these packages (and more) were not needed anymore and could be autoremoved
<ScottL_> other than that I didn't see any weirdness going on when I installed all the packages
<ScottL_> by hand
<persia> So, which two packages conflict?
<ScottL_> well it was two packages that conflicted with the same virtual package
<persia> And probably both provided it :)
<persia> Which two?
<ScottL_> libcurl4-openssl-dev / libcurl4-gnutls-dev with the virtual package libcurl-dev
<ScottL_> ohhh, i understand you now....they both wanted to provide it and hence they conflict...duh
<persia> OK.  And I presume you want libcurl4-gnutls-dev because you're working with some code that is GPL without the SSL exception?
<ScottL_> the are depends of liblrdf0-dev...i'm not really sure what they are for to be honest...just building Ardour
<ScottL_> s/the/they
<persia> They are *both* dependencies for liblrdf0-dev?  So liblrdf0-dev cannot be installed?
<ScottL_> when I installed liblrdf0-dev by hand in the chroot I believe they both installed as depends
<ScottL_> when I run pbuilder it bombs
<persia> And you're using the same chroot for pbuilder and checking the install?
<ScottL_> aye
<persia> OK.  I'm going to encourage you to double-check (based on "I believe they both installed"), because they should either conflict or not.
<persia> If they conflict, then the trick is to find a way to work around that.
<persia> If they don't, you have more checking to do to find out which packages conflict.
<ScottL_> I read about a bug in the buildd system that didn't handle virtual packages very well from 1997, would my pbuilder in Hardy be susceptible as well?
<ScottL_> s/1997/2007   LOL
<persia> Which bug?  I have a feeling that might be about versioned virtuals.
<ScottL_> :( I switch partitions to work on some lucid packaging and I dont' have it up, but might find it again quickly
<ScottL_> https://bugs.launchpad.net/soyuz/+bug/335913
<ubottu> Ubuntu bug 335913 in soyuz "Availability of a package to provide a virtual package not noticed to clear depwait" [Medium,Triaged]
<persia> That has nothing to do with it.  That has to do with the automated system that retries builds that failed for lack of build-dependencies not automatically retrying them when virtual packages are differently provided.
<ScottL_> thanks persia, I'm going to stop for tonight, spend time with the family and work on it tomorrow
<persia> ScottL_: OK.  Good luck with the investigation.  The key is understanding precisely what conflicts.  If you can reproduce it with the installation of a single package, that package ought be fixed.  If you can't, then it's just a matter of adjusting ardour's build-depends.
<ScottL_> I was change son's diaper (like you needed to know that) and I remember before I hand installed everything
<ScottL_> I remember pbuilder given me an error saying that libraptor1-dev was BROKEN: because libcurl4-gnutuls-dev was uninstallable
<persia> In that case, it's likely to be a build-depends change.  But go have an evening, and come back when you have time :)
<ScottL_> does that help at all?
<ScottL_> all right, thanks again for your help
<persia> Not without context.  I don't have a mental map of package relationships (and I doubt anyone does), so all I can do is give you strategies to track down the issue.
 * persia grumbles at fpc, which won't even make clean unless it's already installed, which makes bootstrapping annoying.
<persia> anyone know how to enable RANDR for xvfb?  libwx-perl seems to need it (or to make it not run those tests, but that seems less ideal)
<lifeless> persia: no. I can WAG though.
<persia> lifeless: Please WAG
<lifeless> persia: RANDR, like most extensions, is a server specific thing. So you need to patch the server.
<lifeless> persia: xvfb is just a specific server.
<lifeless> persia: e.g. I don't think you can just enable it, you need to develop it. That said...
<lifeless> PLEASE PLEASE PLEASE do so
<persia> That goes a bit beyond the light FTBFS analyses I planned for today :)
<persia> But maybe I'll take a look when I finish going through the QA stuff I had planned (although I expect it will take me *lots* of research to learn how)
<lifeless> persia: A minimal 'here is the current res, GO AWAY NOW' implementation is probably fairly easy.
<persia> lifeless: That does sound like the least difficult implementation, mostly involving lots of stubs.  I'm just not really comfortable with X programming in general (and tend to get confused at that layer), so it's still a bit of research.
<lifeless> persia: sure
<persia> That said, I did put it on my list, just not ahead of the stuff I know I can do fast and well.
<lifeless> persia: perhaps we should make an avo to suck bryce's knowledge next week
<persia> heh.  That could work nicely :)
<lifeless> its something dx needs.
<lifeless> that and opengl
<persia> Can't one do openGL with xfvb with mesa?
<lifeless> I assume yes in principle
<persia> Ah, but it's the construction of the recipe that gets tricky.
<kamalmostafa> Hello motu's:  Looks like http://qa.ubuntuwire.com/ftbfs has not updated in 36 hours.  What's up with that?
<ScottK> kamalmostafa: There was a bug.  It's been fixed.
<ScottK> (and no, I haven't forgotten)
<kamalmostafa> :-)  Hi Scott.  Get back to $WORK now.
<persia> ScottK: Do you know the schedule for the next run by any chance?
<ScottK> I don't.  wgrant would be the one to ask.
<persia> Probably 18:00 UTC then.
 * wgrant pokes it in the face.
<wgrant> It's on 10 */6, FWIW.
 * wgrant runs it in screen this time.
<micahg> anyone good with bzr merges?
<persia> micahg: "bzr merge" meaning merging two branches, or "bzr merge" meaning using bzr to merge stuff between Debian and Ubuntu?
<micahg> persia: merging with no common ancestor
<micahg> non debian
<persia> micahg: You have two bzr branches of the same source with no common ancestor?
<micahg> persia: I'm trying to prepare TB3
<micahg> TB3.head was a new branch
<RAOF> You can't really merge two branches with no common ancestor; bzr will say that every file conflicts.
<persia> Well, one can merge, but bzr likely isn't the easiest tool for that.
<RAOF> Meld would probably work nicely.
<persia> Or, perhaps by using bzr to track the changes whilst you do it with manual patch arrangements.
<micahg> files have the same names..
<micahg> problem is it's creating a debian and a debian.moved
<vish> micahg: as RAOF mentioned even if same name exits , it wont merge... since there is nothing to merge _into_  ... you can setup a new branch
<RAOF> Right.  Because it finds that both branches have entirely unrelated directories named âdebianâ, so it has to move one out of the way; you can't have both.
<micahg> I can't force it to try to merge?
<RAOF> Not as far as I'm aware.
<RAOF> I've asked this before, many months ago.  It's possible that there's now some way to do it, but at the time there wasn't.
<RAOF> The problem you're hitting is that bzr has an inode-like concept - the filename *isn't* what bzr uses to identify a file by (presumably because otherwise two people adding two separate 'foo' files could get messy).
<persia> To force it, create an (empty) common ancestor.
<persia> merge each tree into a new tree off the common ancestor
<persia> Then merge those tress.
<persia> But everything will conflict.
<Hobbsee> !staff
<ubottu> Hey nalioth, jenda, rob, SportChick, seanw, Dave2, Christel, tomaw, Gary, PriceChild, niko or stew, I could use a bit of your time :)
<Hobbsee> (hitting #ubuntu-women again)
<Hobbsee> cheers
<wgrant> kamalmostafa, ScottK, persia: Turns out the script was working fine, but some symlink shuffling went wrong. It's fixed and updated now.
<persia> wgrant: Thanks.
<siretart> mr_pouit: yes, I am interested. please send the patch to the pkg-multimedia-maintainers mailing list!
<ScottK> wgrant: Sounds great.
<siretart> morning, folks
<mr_pouit> siretart: ok, done
<ahe> someone here who could review the new version of my package http://revu.ubuntuwire.com/p/rubyripper , please?
<lfaraone_> If the post-removal scripts of a package fails, will the post-removal scripts of the package that is going to replace it be used instead?
<geser> yes, called with failed-upgrade; see http://women.debian.org/wiki/English/MaintainerScripts
<lfaraone> geser; okay, i uploaded a sru with a fixed prerm, but fqiled to inckude that.
<xteejx> Hi, I'm totally new to packging, I have read the Packaging Guides, and think I can just about get my head around it. Is the proceudr
<xteejx> ... procedure the same for games that I want to package even if they're on PlayDeb?
<persia> Maybe?
<persia> I don't know much about playdeb, but I do know a fair bit about the Debian/Ubuntu Games team.
<persia> So, if you want to package stuff, I'd be happy to help you get stuff there.
<jariq> Could anyone please review packages ipwatchd - http://revu.ubuntuwire.com/p/ipwatchd - and ipwatchd-gnotify - http://revu.ubuntuwire.com/p/ipwatchd-gnotify . Just one more advocation needed :)
<xteejx> persia: You were a great help last time, so if you could help I'd appreciate it :)
<persia> xteejx: OK.  You've picked out a game already?
<xteejx> I have 1 or 2 in mind, I'll settle on 1 hang on :)
<iulian> jariq: Just out of curiosity.  Have you considered getting it into Debian?
<xteejx> persia: I was looking at spacejunk http://spacejunk.sourceforge.net/
<xteejx> It's not a PlayDeb one, I think that's something for another time when I've learned the ins and outs
<persia> Well, I tend to think that it's just as easy to push to Debian as playdeb, if you did it right :)
<jariq> iulian: well i've created package for ubuntu, submited to revu and then I've found info about debian syncing few days later..
<persia> But anyway.
<xteejx> persia: Are you sure you don't mind helping?
<persia> xteejx: My first recommendation is to investigate the licensing and copyright of the source.  licensecheck and suspicious-source are good tools for that.
<persia> Not at all.
<persia> You'll want to make sure that you can distribute the packaging, and that all the files are appropriately licensed.
<xteejx> persia: I've looked at the source it appears to be GPL3
<xteejx> Not sure about all files though
<persia> Lots of things do :)  One has to look at *each* file in the upstream tarball.
<iulian> jariq: Ah-ha, OK.  It'd be nice to see it in Debian as well.
<xteejx> oh right
<persia> (Yes, this is painful and annoying: I think it's the hardest part of packaging)
<xteejx> persia: Where can I get licensecheck and suspicious-source?
<iulian> jariq: I will review it either later on or tomorrow.
<lfaraone> xteejx: devscripts
<persia> xteejx: devscripts and ubuntu-dev-tools
<xteejx> ok
<jariq> iulian: Thanx.
<lfaraone> Hm. Why does suspicious-source flag on .py and .js files?
<persia> lfaraone: Either there's a bug, or something is funny about those files.
<persia> (if it's a bug, filing and fixing it would be appreciated)
<iulian> jariq: Anyway, please do consider getting it in Debian as well.  I can give you a hand with it and guide you through the processes, even though I'm not a Debian developer.
<lfaraone> persia: well, the files don't have GNU license headers, but other than that they're normal files...
<persia> lfaraone: Do they have some other sort of license header?
<lfaraone> persia: no.
<persia> That's likely the issue then.
<persia> (but check the suspicious-source source to be sure)
<xteejx> persia: I'm not sure about the licensing of this one
<persia> My understanding is that suspicious-source tries to find anything that might not be licensed, or might be binary, and flags it.
<xteejx> persia: http://paste.ubuntu.com/361975/
<xteejx> I'm not too sure, there are several licenses
<jariq> iulian: I am definitely planning to do so and I am going to install debian on my dev machine next week. From what I've read so far I believe there won't be any problems because process seems to be almost identical to ubuntu's.
<persia> xteejx: Well, investigate the "NO COPYRIGHT* and "UNKNOWN" bits, one-by-one.  There's no issue mixing GPL, LGPL, and BSD, so long as the collection is GPL.
<xteejx> persia: Yeah the source is distributed under GPL3
<lfaraone> xteejx: but you have to check whether upstream knows what they're doing, and didn't include other-sourced-code.
<lfaraone> *other-licened-code
<persia> xteejx: Also, I'll recommend you run `licensecheck --copyright -r .` rather than `licensecheck *` to make sure to catch subdirectories (and the output is nicer)
<xteejx> persia: Ok, I'll do that :)
<iulian> jariq: Yes indeed.
<lfaraone> persia: I'm looking at the source of http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/ubuntu-dev-tools/karmic/annotate/head%3A/suspicious-source , and although I'm not too savvy at find, I don't see it doing anything that would cause the behavior I'm seeing.
<persia> Well, the .js files just aren't listed in FILES (this would be an easy fix).
<persia> But I don't have any explanation for the .py files.
<lfaraone> persia: yeah...
<persia> Maybe try with `set -x` ?
<lfaraone> persia: it ends up running "find '!' '(' -name '*.h' -o -name '*.c' -o -name '*.cc' -o -name '*.cpp' -o -name extractDoc.py -o -name setup.py -o -name '*.sh' -o -name '*.txt' -o -name '*.text' -o -name '*.3' -o -name '*.m4' -o -name '*.xml' -o -name '*.html' -o -name '*.php' -o -name '*.php3' -o -name '*.php4' -o -name '*.class' -o -name '*.form' -o -name '*.module' -o -name '*.cfg' -o -name '*.conf' -o -name '*.config' -o -name '*.odt' -o -name
<lfaraone> (was that cut off?)
<persia> It was, but did it include "-o -name '*.py'" ?
<lfaraone> persia: no, and I can't figure out why.
<xteejx> persia: All done, the Unknown are copyrighted, and the no copyright ones had no Copyright information at all, just source
<lfaraone> persia: "extractDoc.py" and "setup.py" are files in the root of the tree
<persia> I *think* that the find command is excluding all the stuff that matches the -o -name rules.
<xteejx> persia: The sge files are copyrighted, the others aren't
<persia> (-o is logical-OR, -name means apply the following glob to file names)
<persia> xteejx: So, is there anything that is copyrighted, but not licensed, or anything that is not copyrighted but appears to contain significant content?
<xteejx> persia: Not that I can see, no.
<xteejx> Everything copyrighted is licensed, and the ones that aren't are mkbin / mkinstaller files
<lfaraone> persia: okay. I wonder why it expands the * on .py files
<persia> lfaraone: I'm not sure at all.
<persia> xteejx: Excellent.
<xteejx> persia: So everything copyrighted must be licensed, and GPL, LPGL and BSD licenses are safe to work together as long as they're GPL licensed 'together' ? Is that right?
<lfaraone> persia: so it's definently a bug?
<persia> xteejx: So, unpack the source (you've probably done this), and create a debian/ directory inside.  Document your copyright findings in debian/copyright.  `echo 7 > debian/compat`, `cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules`, and `dch --create` to do most of the packaging.
<lfaraone> ls
<persia> xteejx: And everything significant must be copyrighted, but otherwise, yes.
<xteejx> persia: Can I use dh_make to do this?
<persia> lfaraone: Well, if there are sources you don't think are suspicious showing up in suspicious-source, then yes.
<persia> xteejx: dh_make adds lots of example files you have to remove, and I don't tend to find the way it writes rules files easy.  It's a handy tool to explain a lot of the ways things work, but, in my opinion, useless when creating a package.
<xteejx> ahh ok
<lfaraone> persia: I'm curious, does the latest version of debhelper automagically handle python packages without manual rule tweaking?
<persia> lfaraone: It's my understanding that it does, for the 90% case, with rules.tiny
<lfaraone> persia: so should I convert my existing, working cdbs-based packages to it?
<lfaraone> persia: i'm still fuzzy on the main advantage of dh7 over cdbs.
<persia> But I don't tend to do python packaging, so my recommendation would be either try it or laboriously dig through debian-python's VCS to see examples of what has been done.
<persia> lfaraone: The main advantages of dh7 over cdbs for me are 1) the sequences are better documented, 2) overriding stuff is lots easier, and 3) it installs changelogs properly
<persia> lfaraone: So, I haven't converted my packages (although I probably will at some point, for consistency), but for new packaging I only use dh(1)
<xteejx> persia: Still here? I think this should be ok for the debian/copyright http://paste.ubuntu.com/362007/
<persia> xteejx: You need to include the 3-paragraph GPL header, the 3-paragraph LGPL header, and the entire text of the CC licenses.
<xteejx> persia: What about the BSD?
<persia> xteejx: Also, be aware that cc-nc-by-sa fails DFSG #6 (http://www.debian.org/social_contract#guidelines), which makes this non-free/multiverse
<xteejx> persia: I thought cc-nc-sa would be ok to use...share-alike ?
<persia> xteejx: You need the entirety of any BSD-style licenses, unless they are the current BSD as distributed by the Regents of the University of California (and the code is copyrighted by the Regents of the University of California).  I just didn't see the BSD references in your draft.
<persia> xteejx: Issue is the "nc" bit: discriminates against commercial use.  One can't sell a CD containing it, or include it in a saleable product.
<persia> (well, one can sell such a CD, but needs to go through annoying machinations to do so)
<xteejx> persia: but Ubuntu is 'free', and it would be in Universe, so that would bypass that wouldn't it?
<persia> xteejx: Ubuntu may be free or may be sold (with certain limitations).
<xteejx> persia: So, this project is not a possibility without consent?
<persia> Mind you, there's a inherent price limit in it also being available without cost, but there's no limit to commercial application.
<persia> It's possible, it's just non-free in Debian, and multiverse in Ubuntu.  No reason not to package.
<xteejx> persia: I see :) I got worried there
<persia> Once packaging is done, it's worth asking upstream about it, but it's not that important.
<ahe> until when are new packages are allowed to enter lucid?
<xteejx> persia: Is this better? If I missed anything let me know :) http://paste.ubuntu.com/362016/
<persia> ahe: FeatureFreeze is the typical deadline.
<persia> xteejx: I'd prefer the complete text of the CC licenses be in debian/copyright (even though this duplicates text in the source), and only ship debian/copyright to end users, rather than needing to ship several license files (because this compresses better).
<persia> xteejx: For GPL and LGPL, you need the text from the "How to use this license" section in each license.
<persia> The BST stuff looks OK, although please don't call it "The BSD license" because it isn't.  It's the Guichan license, with almost the same text as the BSD license.
<persia> s/BST/BSD/
<xteejx> So having a REALLY long License: section is ok?
<xteejx> persia: I didn't realise
<persia> I'd recommend something like "The files int he guichan/ folder are subject to the following license: ..."
<persia> Yes.  No limit to debian/copyright size, as long as it's complete.
<persia> One large text file will compress better than several small ones.
<xteejx> Ok, so copying and pasting the full licenses into it and formatting them correctly is ok?
<persia> For licenses that appear (verbatim) in /usr/share/common-licenses, it's OK to just put the little headers one puts in source files, and then reference the common-license, but otherwise, yes.
<shadeslayer> hi can someone help me with a bit pf packaging?
<persia> shadeslayer: Sure, but I'd prefer to help you with packaging targeted at Ubuntu than at a PPA, if you're up for that.
<shadeslayer> persia: um i actually was aiming finally at a PPA
<shadeslayer> persia: whats the difference though?
<persia> Yeah, I saw from identi.ca and #kubutnu-devel :)
<shadeslayer> persia: lol :)
<persia> Differences are mostly 1) we try to get things right, rather than mostly right for distro work, and 2) we tend to work more collaboratively
<shadeslayer> and btw yayy... kde 4.4 rc2 out in a few hours
<persia> Well, there's also freezes and stuff, but that's not usually directly related to packaging.
<shadeslayer> persia: theres no difference as to building steps?
<persia> shadeslayer: Aside from where the final upload happens, no.
<shadeslayer> persia: so the PPA's accept .debs too?
<persia> No, but we don't produce .debs.
<persia> I once suggested that all of Ubuntu could be replaced with three PPAs.  People didn't like the idea, but the concepts are similar.
<shadeslayer> persia: i think there should be just 2 repos : free and non-free
<shadeslayer> much easier to remember :P
<shadeslayer> keep everything else like betas and stuff to PPA
<persia> My three were "free", "restricted software", and "restricted data", because there's lots of interesting data that doesn't grant the freedom to modify.
<shadeslayer> persia: anyways i was here : https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging from Scratch
<persia> OK.  That's the long-winded version :)
<persia> Did you already pick out your software?
<shadeslayer> persia: yep
<persia> First step: check the licensing :)
<shadeslayer> persia: its a kopete plugin for facebook alot of people are demanding it :P
<persia> (yes, this means check every file).
<shadeslayer> persia: :o
<persia> I know, but it's important, as otherwise you can't be sure that you have permission to modify and redistribute.
<hyperair> persia: why three "PPAs"?
<shadeslayer> persia: one sec,which is preferred a point release or the current git version?
<persia> hyperair: "main", "restricted-software", "restricted-data".
<persia> shadeslayer: I prefer actual releases, personally.
<hyperair> if you used PPAs as the main repository, then it'd still be that, the main repository.
<jpds> shadeslayer: It's there a kopete-facebook package?
<jpds> Isn't*
<persia> If there's some cool stuff in git, extract and apply as patches.
<shadeslayer> jpds: yeah its outdated
<persia> hyperair: Right.  It's just an implementation thing.
<hyperair> ah
<persia> (and I no longer believe that three PPAs solves the issue, it was just an offhand comment during one of the ArchiveReorganisation discussions)
<shadeslayer> persia: brb in a few secs
<shadeslayer> unfourtunately im also involved in : http://mstc.tk/ : :P
<shadeslayer> persia: lemme download their release
<kamalmostafa> Is there any way I can run a test build on sparc and/or powerpc for a Lucid package?
<persia> kamalmostafa: Get a sparc and/or powerpc :)
<persia> But I have a powerpc.  Which package?
<kamalmostafa> (I'm working on an amd64 machine!)...  Aw persia, you beat me to my correction!  ;-)
<kamalmostafa> The package is libexplain, but it needs fixes (separate fixes) for sparc and powerpc.
<shadeslayer> persia: next step?
<shadeslayer> (i have the tarball
<persia> kamalmostafa: Well, if you give me a .dsc, I'm up for running test-builds.
<persia> shadeslayer: Unpack the source, create a debian/ folder, and document your copyright research in debian/copyright
<kamalmostafa> persia: okay thanks.  I haven't actually tried fixing the problems yet -- just planning how I would test it if I did.  I'll holler for you when/if I need a powerpc test build.
<persia> kamalmostafa: Just ask here (or in #ubuntu-powerpc) if someone can run a lucid test build.
<persia> There's a few of us with various architectures.
<shadeslayer> persia: what if a header file doesnt have the GPL?
<persia> shadeslayer: What license does it have?
<shadeslayer> persia: none at all
<persia> Well, unless you're in Nicaragua or Honduras, that means that the author reserves all rights of copyright, so you can't distribute.
<shadeslayer> persia: some of the files dont have the license but the COPYING file says GPL
<shadeslayer> persia: what now? :P
<persia> shadeslayer: COPYING is there to meet the "You should have received a copy of the GPL with this" bit, not to declare everythign GPL.
<persia> shadeslayer: Talk to upstream about the issues.
<shadeslayer> persia: um : Kopete facebook plugin is licensed under the GNU General Public License
<persia> shadeslayer: If upstream didn't license GPL because they wanted open headers, suggest an ISC (or similar) license for the headers, and GPL for the code.
<persia> Apparently some of the header files aren't.
<shadeslayer> persia: http://pastebin.com/f19ec20db
<persia> shadeslayer: I understand.  Please read the "How to use the GPL" section (at the bottom of the GPL), check the header files that don't have headers again, and explain to upstream.
<persia> Alternately, explain to me if you're *really* sure they aren't required, but I believe them to be (outside Nicaragua and Honduras)
<shadeslayer> persia: well i think the author simply forgot about applying the license to header files since the .cpp's are all licensed and the project is freely available on git
<persia> shadeslayer: I think you're right, and I suspect the author would very much appreciate a patch adding the license headers and apply it in git with alacrity :)
<shadeslayer> persia: also the the 5th line of the pastebin states all header files are licensed under GPL
<persia> Right, but, at least from my reading of "How to use the GPL", it wasn't done according to the guidelines.
<persia> I'm not sure how it might get argued in court, but I tend to be extra conservative, as I'd rather never find out.
<shadeslayer> persia: you mean this : http://www.gnu.org/licenses/gpl-howto.html
<persia> Actually, I meant the stuff at the bottom of COPYING, but the content isn't that different.
<persia> http://www.gnu.org/licenses/gpl-3.0.html#howto seems to be a webified version of what I was referencing.
<shadeslayer> so i guess no packaging lessons for me :P
<persia> I didn't say that.  Checking and documenting copyright is the first step.
<shadeslayer> persia: hmm well if the licensing isnt right we cant package it right?
<persia> You've done half of that, and part of your packaging is to contact upstream and discuss it with them.
<persia> You can package it, you just don't necessarily have permission to distribute it.
<shadeslayer> persia: hehe :)
<persia> Was it I packaging it, I'd do all the work, and keep a copy on my hard drive to finish up once I heard back from upstream.
<shadeslayer> persia: thats what i was thinking ><
<persia> So, put together a debian/copyright (noting which files are unlicensed, and what license applies to the rest, etc.).
<persia> And when you're done, ask for the next steps.
<xteejx> persia: This should be ok now http://paste.ubuntu.com/362045/
<persia> xteejx: You still don't have the three-paragraph header for the GPL-3 stuff (see the last link I posted)
<persia> xteejx: You're still calling the guichan license the "BSD" license, and it's not.
<xteejx> persia: That's what is in its own copying file
<persia> xteejx: Yes, but the idea is to put all the copyright information in one file, rather than distributing lots of files to end users.
<xteejx> So, even though they *state* it's BSD, it really isn't, so just remove the BSD wording?
<persia> xteejx: Also, I see cc-nc-by-sa, but I thought there was also some cc-by-sa (not NC) stuff, wasn't there?
<persia> xteejx: Yep.  They got it wrong.  It can't be "The BSD license" unless copyright on the work is held by the Regents of the University of California.  Most people are lazy though, and prefer to say "BSD License" rather than "BSD license with ownership changes" or some similar, longer, phrase.
<xteejx> persia: The Creative Commons Attribution-Share Alike license and the Creative Commons Attribution-Noncommercial-Share Alike license are there
<xteejx> persia: I see
 * persia looks harder, having thought there was only one.
<persia> Right.  Sorry.  I see them both now.  They're so similar, I got confused reading them :)
<xteejx> hehe
<persia> So it's just adding the three paragraphs for each of GPL and LGPL, and dropping the "(BSD)" bit from the guichan license.
<xteejx> persia: One last thing abut the GPL3 thing.....which parts have to be copied, I can't see any "how to use" section, or is it just the header?
<xteejx> which paragraphs? Sorry
<persia> xteejx: At the very bottom of the GPL, there should be a "How to use" section.  http://www.gnu.org/licenses/gpl-3.0.html#howto seems to be a webified version of the same thing, and describes the paragraphs.
<shadeslayer> persia: ok can you just tell me to package it,ive sent a message to the dev about the GPL license
<xteejx> persia: There's a 'How to Apply These Terms to Your New Programs' section...is that it?
<persia> xteejx: Yep,  Those paragraphs.
<xteejx> I see it now....it's so small!! Thanks :)
<persia> shadeslayer: The next step is debian/copyright (which xteej is also working on right now).
<persia> shadeslayer: Basically, just document everything in that file.
<shadeslayer> persia: ok so i create : a folder debain with a text file called copyright and put what in it?
<persia> shadeslayer: There's two formats that are widespread.  One is documented at http://dep.debian.net/deps/dep5/ and the other at http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
<xteejx> persia: All done 100% now http://paste.ubuntu.com/362052/ :)
<persia> Pick whichever one seems easier to you :)
<xteejx> persia: I see what you meant about this being quite a difficult bit!!
<persia> Yep.  It's the hardest part, which is why I like to do it first.  Nothing is more annoying than packaging something and discovering one can't distribute.
<shadeslayer> persia: i choose the second one :)
<persia> shadeslayer: OK.  Go for it :)
<shadeslayer> persia: hehe VICTIMS NAME :P
<persia> xteejx: Did you already run all the other commands I listed to set up the boilerplate packaging?
<xteejx> persia: Well thankfully it's done, so now I have debian/compat and copyright
<shadeslayer> persia: btw theres already one package maintainer with ubuntu,should i put his name or mine?
<persia> Next is rules (copy from /usr/share/doc/debhelper/examples/rules.tiny) and changelog (create a new one with dch --create)
<persia> shadeslayer: Already working on this package?
<xteejx> persia: Ok :)
<shadeslayer> persia: i mean someone already created a .deb which is in repo
<persia> shadeslayer: So you're not packaging something new, but just want to modify a package?
<shadeslayer> persia: its a new version actually
<shadeslayer> persia: theres already 0.1.4-0ubuntu1.1
<shadeslayer> !info kopete-facebook
<ubottu> kopete-facebook (source: kopete-facebook): Facebook chat plugin for Kopete. In component universe, is optional. Version 0.1.4-0ubuntu1 (karmic), package size 77 kB, installed size 308 kB
<shadeslayer> persia: and i have 0.1.5
<persia> shadeslayer: OK.  Go back to #kubuntu-devel, and ask "How I can help get a new version of ${whatever} into the repositories?".  You don't need to learn how to package something, but how to work with the kubuntu-ninjas to keep everything up to date.
<shadeslayer> persia: well actually i want to start from scratch about building packages... not from the middle :)
<xteejx> persia: I set version to 1.0.1-0ubuntu1, as its not in Debian and upstream version is 1.0.1
<xteejx> persia: Is that correct?
<persia> xteejx: That works for now.
<xteejx> release = lucid?
<persia> shadeslayer: I actually recommend starting in the middle.  It's a lot easier to make an impact by learning how to make small changes, and fixing lots of packages than to learn how to package new stuff (which can take months to get in).
<xteejx> I'm a triager and use Lucid for testing anyway
<persia> xteejx: Yep, lucid would be good.
<shadeslayer> persia: hmm well atleast theres some activity there now :)
<persia> shadeslayer: Also, by getting involved with the team, you'll get lots more experience working with them than by working on your own looking at random generic advice on how to package.
<shadeslayer> persia: hehe... i just asked there :)
<xteejx> persia: changelog created
<shadeslayer> persia: btw whats your identi.ca URL?
<persia> shadeslayer: No idea.  My nick is persia, but I only very rarely post anything.
<xteejx> http://paste.ubuntu.com/362056/
<persia> xteejx: OK, so you have copyright, compat, rules, and changelog?
<shadeslayer> persia: no problem :)
<xteejx> persia: Yup :)
<persia> Cool.  Next up: debian/watch
<persia> man uscan to read all about it.
<xteejx> Me?
<persia> Yep.
<xteejx> Great!? lol :)
<xteejx> Bloody hell I didn't know that could do that!!
<persia> Nice, isn't it :)
<xteejx> Very handy!
<persia> Sometimes I do watch first, but copyright is the hard part, and most people already downloaded something they want to package.
<xteejx> just need to read now heh
<shadeslayer> persia: wanna help me out in kubuntu-devel?
<persia> shadeslayer: I'm not familiar with the Kubuntu Ninja's workflows, which is why I sent you there.
<shadeslayer> ah ok
<persia> s/\'s/s\'/
<dupondje> https://bugs.launchpad.net/ubuntu/+source/synce-sync-engine/+bug/511986 => how to make it seen by people that can do this ? :D
<ubottu> Ubuntu bug 511986 in synce-sync-engine "Please sync 0.14 from SynCE PPA" [Undecided,New]
<xteejx> persia: This is very confusing
<persia> dupondje: What's holding it out of debian/testing?
<shadeslayer> dupondje: its already public
<persia> xteejx: https://wiki.ubuntu.com/PackagingGuide/Complete#Creating%20and%20Using%20a%20debian/watch%20File might provide more examples.
<xteejx> Thanks persia :)
<dupondje> persia: think slowlyness :D
<persia> dupondje: Is it in unstable already?
<dupondje> persia: nope
<persia> Are you part of upstream?
<dupondje> only user
<dupondje> could do a bugreport on debian to get new version into unstable :)
<persia> Please do, and link the Ubuntu bug to the Debian bug.
<persia> We *can* put in a newer version, but since we have yet to hit DebianImportFreeze, it's better to work through Debian right now (as opposed to after freeze, when it's best to work in parallel).
<sebner> dupondje: we don't sync from private PPA's btw
<xteejx> persia: I can't work out how to do the watch file for a sourceforge project....
<dupondje> sebner: I know its not a 'real sync', but it can be used as a start right ? :)
<sebner> dupondje: depending on the quality ;) but as persia pointed out, getting it into Debian first and then sync to ubuntu is the prefered way
<persia> xteejx: There's a special syntax.  Look at the examples in the uscan man page.
<xteejx> persia: I have... its really difficult :(
<xteejx> I'm still trying though
<xteejx> persia: Got it!!!!
<persia> xteejx: Excellent.  Now for the last bit to tie it together, and call it packaged (mind you, the package may be buggy, but it will be a package), debian/control
<xteejx> persia: Ok...
<persia> So, open your favorite text editor and open http://www.debian.org/doc/debian-policy/ch-controlfields.html in a browser
<xteejx> yup
<persia> Starting from Source: go through each field, read about what it does, and add the right entry.
<xteejx> hey micahg
<xteejx> persia: Ok, I'll try :)
<persia> Put a blank line between the Source and Package sections (and each additional Package section if you have lots of them).
<dupondje> did a bugreport into debian :)
<shadeslayer> persia: btw whats a good page to learn packaging ive been empty for the past hour :P
<runasand> shadeslayer: https://wiki.ubuntu.com/PackagingGuide
<shadeslayer> runasand: i am reading that but persia said that was a pretty long wiki
<persia> shadeslayer: Or read backscroll, as xteej is packaging something now :)
<runasand> shadeslayer: sure, but there's lots of useful info in it :)
<shadeslayer> runasand: ok
<persia> Indeed.  It's full of useful info.  It's just long :)
<shadeslayer> persia: i would rather read the wiki,since i cant read the backscroll ( just too lazy :P )
<persia> OK.
<shadeslayer> runasand: can you help with  A specific version of a package can be selected for installation by following the package name with an equals and the
<shadeslayer>            version of the package to select. This will cause that version to be located and selected for install. Alternatively
<shadeslayer>            a specific distribution can be selected by following the package name with a slash and the version of the
<shadeslayer>            distribution or the Archive name (stable, testing, unstable).
<shadeslayer> oh crap ..
<xteejx> persia: What do I put in for build-depends, the source depends on sdl that's all
<persia> xteejx: I suddenly think I wasn't clear: only the stuff in section 5.2 matters.
<runasand> shadeslayer: sorry? what do you need help with?
<shadeslayer> runasand: https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging from Scratch << stuck at 4th command
<xteejx> persia: That's ok, I guessed :)
<shadeslayer> runasand: yeah apparently the url didnt get copied :P
<persia> xteejx: That's the idea :)  If you get it wrong, the package fails to build, and you can fix it :)
<xteejx> hmmmm apt-cahce search sdl methinks
<randomaction> shadeslayer: there was also a great session last UDW: https://wiki.ubuntu.com/MeetingLogs/devweek0909/PkgFromScratch
<persia> xteejx: Also put "debhelper (>= 7)" in your build-deps.
<runasand> shadeslayer: but what have you done so far?
<shadeslayer> runasand: does it mean the tarball i downloaded via ftp?
<xteejx> persia: What's the $sh:Depends thing I've seen before?
<shadeslayer> runasand: all the commands before that command :P
<shadeslayer> runasand: i did attend that session last time :)
<persia> ${shlibs:Depends}?  You probably also want ${misc:Depends}.
<runasand> shadeslayer: https://wiki.ubuntu.com/PackagingGuide/Complete#Getting%20Started -- start there ;)
<shadeslayer> (didnt learn properly though )
<xteejx> ok
<runasand> shadeslayer: you can't really skip any steps if you want to learn it properly. Take your time and read everything :)
<shadeslayer> runasand: as i said i did everything before that.. cmake,make etc
<runasand> shadeslayer: so, which command are having problems with and what exactly is the problem?
<shadeslayer> runasand: mkdir hello-2.4 << and the next one,does it mean that i need to extract the ftp download to this folder?
<runasand> shadeslayer: have you actually downloaded the source for hello?
<shadeslayer> runasand: see the 3rd command in that section
<xteejx> persia: I'm not sure what to use for sdl... I could trial and error I guess....also what is the Standards-Version?
<runasand> shadeslayer: if not, then that's what you need to do :)
<shadeslayer> runasand: yeah as it says in : https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging from Scratch
<persia> xteejx: Check which version of debian-policy is installed in lucid, and use the first three digits.
<xteejx> persia: No probs
<runasand> shadeslayer: if you already have the software, then there's no need to download it again
<persia> For SDL, I'd probably use libsdl1.2-dev
<persia> (but you may want more modules: `apt-cache search sdl dev` shows mostly development libraries)
<shadeslayer> runasand: oh ok
<xteejx> persia: I thought libsdl1.2 as well
<persia> But it also doesn't matter: if you forget something, it will fail to build, and you can add it later (that's why I say this creates a buggy package, and then we get to fix bugs).
<xteejx> Build-Depends: ${misc:Depends}    <  Do I put a comma after or whitespace between depends
<xteejx> ?
<shadeslayer> runasand: from where do i start after using apt-get source?
<persia> xteejx: You generally want to build-depend on -dev packages, and let them decide if they need the libraries, or just headers.  It depends on the library.
<runasand> shadeslayer: I thought you said you'd already run 'make' and friends?
<persia> xteejx: ${shlibs:Depends} and ${misc:Depends} belong in Depends: not in Build-Depends.
<persia> And separate with commas.
<shadeslayer> runasand: eh? i told you that i knew about make
<xteejx> persia: Ahh ok...won't the -dev cause problems when a .deb is made?
<persia> Why?
<runasand> shadeslayer: after you've downloaded the software you want to package, you need to run a command to create the debian directory
<runasand> shadeslayer: that command is dh_make
<xteejx> Also, it tells me I needed 2 paragraphs 1 for source, 1 for binary, or is that wrong?
<shadeslayer> runasand: ok
<persia> You need the -dev to build.  That might cause some dependency to be defined in ${shlibs:Depends}, which then goes to the deb.
<runasand> shadeslayer: this is all in the wiki, you know :)
<xteejx> persia: Ohhhhh I see
<persia> xteejx: That's right.  Starting from "Source" is the source paragraph, and starting from "Package" is the binary paragraph.
<shadeslayer> runasand: ok found it,thanks :)
<xteejx> persia: I don't see how there will be any difference between the two...?
<persia> xteejx: If there are lines that would be duplicate, don't bother adding them to the binary section.
<xteejx> persia: Ok, makes sense, just double checking thank you :)
<persia> But you need both.  One is about the .dsc and one is about the .deb
<xteejx> persia: Architecture? It doesn't seem specific, so any?
<persia> Yep.
<xteejx1> persia: http://paste.ubuntu.com/362087/ hope this is ok
<persia> xteejx1: Drop Priority and Section from the binary section
<persia> Other than that, it looks like a good start.
<persia> So, now run `debuild -S -us -uc` to build an unsigned, buggy, source package.
<persia> Did you ever construct a lucid schroot?
<persia> Oh, except you want to add "Build-Depends: debhelper (=> 7), libsdl1.2-dev" to the source section, and replace libsdl1.2-dev with ${shlibs:Depends} in the binary section.
<xteejx1> persia: Yeah few weeks ago, but I had serious data corruption, my laptop hard drive failed, so reinstalled
<xteejx1> ok
<persia> Do you have any schroots setup?
<xteejx1> nope
<persia> Do you still have the LVM partition?
<xteejx1> lol nope
<xteejx1> Can't I just do it with pbuilder?
<persia> Then go install pbuilder, and set it up (I don't know the best way to do this)
<persia> !pbuilder
<ubottu> pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<xteejx1> persia: http://paste.ubuntu.com/362089/
<persia> Great.  `debuild -S -us -uc`
<xteejx1> problems (as expected)
<persia> Excellent.  Go fix them :)
<xteejx1> They're only lintian errors, it appeared to debuild ok... ancient-autotools-helper-file, outdated-autotools-helper-file, and bad-relation build-depends: debhelper (= > 7)
<persia> debhelper (>= 7) (no space)
<xteejx1> There isn't a space in the control file
<xteejx1> Build-Depends: debhelper (=> 7), libsdl1.2-dev
<persia> Oh, sorry.  >= rather than =>
<xteejx1> ohh :D
<xteejx1> can I redo the debuild again without worrying?
<xteejx1> i.e. no need to remove anything?
<persia> Take a look around with ls.  You should be able to do so.
<xteejx1> http://paste.ubuntu.com/362098/ I don't see any problems other than the ancient/outdated autotools helper files.... but this is ok right?
<persia> Well, no.  It makes it less portable.  Try adding autotools-dev to build-depends and putting something like http://paste.ubuntu.com/362099/  in debian/rules
<xteejx1> One day I will fully understand what that rules file does
<persia> Also, to get lintian to tell you more (but it may make mistakes), try running `lintian -iIv spacejunk_1.0.1-0ubuntu1_source.changes` and also `lintian --pedantic ...`
<xteejx1> W: spacejunk source: debhelper-overrides-need-versioned-build-depends (>= 7.0.50~)
<persia> Then update that in the Build-Depends :)
<xteejx1> persia: I was going to say shall I change the version :)
<persia> At this point, lintian will be a better teacher than I (but ask questions if you're unsure).
<xteejx1> Ok, so the ideal result is NO lintian errors at all?
<randomaction> there should really be a debhelper command to update outdated config.*
<persia> Once you get the source clean, try a pbuilder build, and run lintian against the binary .changes file.
<persia> Getting no lintian Errors is a definite goal.  Getting no lintian messages is less so.  Sometimes lintian doesn't understand correctly, and it does have bugs.
<persia> But most of the time, lintian has good advice, and you have to be fairly sure it's wrong to ignore it.
<xteejx1> Which I'm not :P
<persia> Right.  But now you have a buggy package, and once you fix the bugs, you'll have a good package.
<persia> Once you have a good package, since it's a game, you'll want to get in touch with the Debian/Ubuntu Games team to get it uploaded.
<persia> (or, if that's slow, stick it on REVU, but that may take just as long).
<xteejx1> cool
<xteejx1> btw $ lintian -ilv spacejunk_1.0.1-0ubuntu1_source.changes
<xteejx1> Value "v" invalid for option l (number expected)
<xteejx1> error parsing options
<dupondje> persia: https://bugs.launchpad.net/debian/+source/synce-sync-engine/+bug/511986 linked upstream now :)
<ubottu> Ubuntu bug 511986 in synce-sync-engine "Please sync 0.14 from SynCE PPA" [Undecided,New]
<persia> xteejx1: lower-case i, capital i, lower-case v
<xteejx1> ohhh :)
<persia> dupondje: Great.  If we reach Debian Import Freeze, and it still isn't in unstable, ask back here about how to proceed.
<dupondje> ok:)
 * persia plots a good 15-30Ksec lag
<xteejx1> persia: All good, except P: spacejunk source: source-contains-prebuilt-windows-binary windlls/libogg-0.dll but I think they MAY be needed
<ahe> could someone review the new version of my package http://revu.ubuntuwire.com/p/rubyripper , please?
<xteejx1> persia: Ping!
<randomaction> xteejx1: I believe that 15-30K sec lag referred to sleep
<xteejx1> I've been trying to build a new package for Ubuntu (my first time), I've got up to doing debuild, which after a little fiddling has went fine apart from lintian saying about windows binary dlls in the source, but I think they're needed... where do I go from here please can someone help?
<xteejx1> randomaction: heh :)
<xteejx> do I do pbuilder now to test the build process?
<xteejx> Hey guys, http://paste.ubuntu.com/362127/ I have an error 9 in [override_dh_auto_configure] can someone help please?
<xteejx> I'm trying to make a package, and this happened in pbuilder
<kamalmostafa> Motu's please advise:  Debian's package libexplain 0.19.D001-1 seems stuck in unstable - http://packages.qa.debian.org/libe/libexplain.html - I don't understand the "Check why" explanation.  I would like to get that version into Lucid to fix some FTBFS's.  I can pbuilder-lucid-amd64 it fine and install it.  I think I should file a sync request -- but can I get some help understanding the "Check why" first?
<randomaction> xteejx: the error occurred while running ./configure, it should be in the previous lines
<Laney> kamalmostafa: sounds like it starts a transition
<xteejx> randomaction: That's what I thought, I'm now trying to build it from source locally to test if it installs on my system, I'm guessing once I can do that, it'll be a LOT easier to package it
<Laney> hmm, maybe not
<randomaction> xteejx: that's true. configure often fails because of missing build-deps
<xteejx> randomaction: Well it's having problems finding sdl so I'll work through the configure script problems to track it down :)
<randomaction> kamalmostafa: maybe this is the case described by "Explanation #1" at http://release.debian.org/migration/testing.pl?package=libexplain ?
<kamalmostafa> randomaction: Well, yes, that sounds most reasonable, but...  All of the packages that it claims will be "uninstallable" are just those that are produced by libexplain itself.  Note http://packages.qa.debian.org/libe/libexplain.html .   As stated, I don't get it ;-)
<kamalmostafa> I meant this URL:   http://release.debian.org/migration/testing.pl?package=libexplain;expand=1
<xteejx> Is it normal for a game to want -dev libs for the configure script to work??
<randomaction> xteejx: yes, for games and most software :)
<xteejx> randomaction: Ohh OK, just got a little worried when it looked like it wanted 50M+ of archives :)
<randomaction> kamalmostafa: I think I got it: http://packages.debian.org/sid/libexplain9 - depends on non-existent libcap1 on i386
<randomaction> so it should be rebuilt (binNMU'ed, in Debian language)
<kamalmostafa> randomaction: but only i386?  Let me look at the deps here.
<randomaction> it must have been build before the transition; if it were built now, it'd depend on libcap2
<xteejx> This package I'm creating, I'm running 32 bit Lucid, will it be buildable on amd64?
<kamalmostafa> randomaction: Where are you seeing that reference to libcap2?  Here's the control file from libexplain 0.19.*  http://paste.ubuntu.com/362150/
<randomaction> ${shlibs:Depends} expands to list of packages containing libraries to which the binaries have been linked
<kamalmostafa> randomaction: Ah, okay.  And how does one "expand" that list for inspection?
<randomaction> it's done by dpkg-shlibdeps command which is run during build, after the executables have been created
<randomaction> so you just build the package and look at dependencies of resulting debs
<randomaction> Does anyone know the appropriate place to ask for binNMU? Is it debian-release@l.d.o?
<kamalmostafa> randomaction: so given a .deb, what handy command will tell me its dependencies (without installing it)?
<randomaction> dpkg -I (capital i)
<kamalmostafa> randomaction: Got it.  Okay, now I do see the libcap2 depend.  Thanks.   What's my next step?
<kamalmostafa> ... I mean, to poke Debian.
<randomaction> I don't know much about how this works in Debian, but I think you should ask for binNMU of libexplain on i386. I'm not sure where to do this, probably debian-release@l.d.o, but you could be better off asking in some Debian channel.
<randomaction> And if you did the build locally, not in pbuilder, you can examine the substvars file in debian/ to see what variables expanded to what.
<kamalmostafa> randomaction: Okay, very good -- I'll chase that down with Debian.   In the meantime, can we just sync the unstable version into Lucid anyway?
<randomaction> sure we can, just add a note in the sync bug why we need to sync from unstable
<kamalmostafa> Excellent.  Thank you very much.
<porthose> ScottK, ping! here is a list of rdepends for elementtree, celementtree and ctypes http://paste.ubuntu.com/362163/. Should we go ahead and start changing the dependencies in those packages?
<ScottK> porthose: Yes.  In most cases it should be a sync/merge from Debian since they have done this already.
<porthose> ScottK, yea that's what I was thinking :)
<shadeslayer> persia: there?
<shadeslayer> ok anyone who can help me finish building this package?
<shadeslayer> wow..
<shadeslayer> Laney: there?
<shadeslayer> cd
<geser> ~$
<shadeslayer> geser: :D
<shadeslayer> anyone who can help me build a package?
<xteejx> Hey guys when running debuild, lintian gives me a possible-unindented-list-in-extended-description warning. Could this be because I added * bullet points of the features in the control file, and does it matter?
<xteejx> I just re-read that don't worry, I obviously didn't indent it enough!
<RAOF> Lintian would obviously prefer that you indented the list; I don't think that's a standard (yet), but I've certainly seen discussion about standardising list markup for control files.
<xteejx> It's ok, I'm being dumb I re-read it and it made sense! :)
<RAOF> Throwing -i at lintian can make the messages make more sense, too.  That generally includes a longer description and how to fix it.
<xteejx> Can I just ask... it's a python game, the deps are set, no problems there, but how can I make it so that it has a menu entry?
<xteejx> RAOF: I'll try that thanks :)
<RAOF> xteejx: It needs to ship a .desktop file for it to appear in the GNOME menus.  If upstream doesn't have one yet, they're trivial to write; you can find examples in /usr/share/applications
<shadeslayer> anybody around to help me?
<micahg> !ask > shadeslayer
<shadeslayer> im almost done with making a .deb
<ubottu> shadeslayer, please see my private message
<xteejx> RAOF: Great!!! Thanks again! You guys have been really helpful today
<xteejx> ps... hi micahg
<micahg> hi again xteejx
<shadeslayer> well last command i did was debuild -S -sa
<xteejx> I'm giving triage a rest for a day or two, trying my hand at packaging :D
<shadeslayer> and idk the next step :P
<micahg> shadeslayer: next step for what?
<xteejx> what have you done so far shade?
<shadeslayer> micahg: xteejx lemme pastebin the thing
<micahg> shadeslayer: that should give you the files necessary for a source upload
<xteejx> xteejx: I'm new to packaging, just asking what someone else would...makes sense to know what you've done so far :)
<shadeslayer> xteejx: http://pastebin.com/f653178d5
<shadeslayer> micahg: i have .build and .dsc files
<micahg> shadeslayer: are you ready to upload to revu (what are you trying to do)?
<xteejx> Is this a problem: "W: magicity: extra-license-file usr/share/doc/magicity/LICENSE.txt.gz" ... how the hell could anything be there, I haven't given sudo access..........
<micahg> xteejx: that could be a subdirectory in the tarball
<shadeslayer> micahg: well as you can see from the conversation,apachelogger was teaching me how to build a package ( in this case : kopete-facebook ) for lucid
<xteejx> micahg: Nope...that's why I'm worried
<micahg> shadeslayer: ok, but what are you doing this for, yourself, Lucid releasE?
<shadeslayer> micahg: now i also wanted to port this package for kubuntu-backports and kubuntu-beta PPA's and ive reached till that command
<micahg> is it a new package?
<shadeslayer> micahg: no its a updated package
<shadeslayer> micahg: apachelogger told me that i should make the package and they ( kubuntu devs ) will upload it
<xteejx> micahg: http://paste.ubuntu.com/362208/ It's the blah_i386.build file, would you mind having a quick look please?
<micahg> shadeslayer: so I would guess you want to push to REVU then?
<shadeslayer> micahg: idk the next step apachelogger had to go :P
<xteejx> I've seen the problem
<xteejx> magicity/debian/magicity/usr/share... why has debuild put it there?
<shadeslayer> micahg: i thought this would lead me to a fully furnished .deb :)
<xteejx> I ran debuild from the main source dir... i.e. magicity (first one)
<micahg> shadeslayer: no, it's a source build for upload
<micahg> xteejx: idk
<xteejx> strange
<shadeslayer> micahg: ok,and do i need just to run debuild -S -sa or just debuild -S
<micahg> shadeslayer: to do what?
<micahg> shadeslayer: they need the source build to upload, not a .deb
<shadeslayer> micahg: for the build files?
<shadeslayer> micahg: ok i got that but whats the -sa option for?
<micahg> shadeslayer: to include the .orig.tar.gz in the upload
<shadeslayer> micahg: any place i can test this ?
<shadeslayer> (uploading the source builds etc)
<jmarsden> shadeslayer: Your PPA ?  :)
<shadeslayer> jmarsden: i can upload these to my PPA? :o
<jmarsden> Once you have a source.changes file from a working package build for a Ubuntu distribution, yes.  That's what dput does...
<shadeslayer> Hoorah
<shadeslayer> to the PPA mobile :D
<jmarsden> shadeslayer: https://help.launchpad.net/Packaging/PPA/Uploading
<shadeslayer> jmarsden: reading
<shadeslayer> jmarsden: is it preferred to have a staging repo
<jmarsden> Staging... for a personal package archive?  I don't think so.  PPAs are personal, your PPA is *yours* to use for testing what you are working on...
<shadeslayer> jmarsden: hmm well ok
<jmarsden> shadeslayer: I'd be careful about uploading stuff to a team PPA that hundreds of trusting people might have in their sources.list ... but your own personal PPA... use it for testing packages, that's pretty much what it is for.
<shadeslayer> ok
<xteejx> I've created a .deb, installed it. Not sure where it installed to, how can I find out?
<jmarsden> xteejx: dpkg -L packagename
<xteejx> thanks :)
<jmarsden> You're welcome.
<shadeslayer> uploading :D
<shadeslayer> ok how soon does the build finish?
<xteejx> The .deb only installs the docs
<jmarsden> shadeslayer: That depends who is ahead of you in the build queue :)
<shadeslayer> jmarsden: wheres the build queue?
<shadeslayer> jmarsden: and why cant i see my packages?
<jmarsden> shadeslayer: Look at your PPA on launchpad, when you see the packages there you can click on them and see how long before they start to build etc.
<geser> https://edge.launchpad.net/builders/
<shadeslayer> jmarsden: i cant see any :P
<jmarsden> shadeslayer: Wait a few minutes :)   To see how busy the builders are as whole are, see the URL geser gave you.
<geser> currently the i386 PPA queue contains over 600 packages
<shadeslayer> :o
<shadeslayer> geser: um Queue says empty
<shadeslayer> oh thats the official builder
<jmarsden> shadeslayer: You won't be uploading anything there for a while :) :)
<geser> you looked at the official archive queue, not the ppa queue
<shadeslayer> jmarsden: even the uploads dont show up?
<jmarsden> shadeslayer: The uploads should show up in your LP PPA page within a few minutes.  Upload processing is not instant.
<shadeslayer> ah
 * shadeslayer waits
<xteejx> Question: I'm packaging a python game, it needs only 1 package, python-pygame - it is safe to simply have a control file that creates a directory for it in /usr/bin/ and copies it there with a .Desktop file for menu launching? I'm unsure if this would be acceptable?
<kamalmostafa> shadeslayer: Note also that LP will send you an email saying that your PPA upload was "Accepted" (or "Rejected" if you named something incorrectly) -- so keep an eye out for an email from Launchpad PPA <no_reply@launchpad.net>.
<shadeslayer> kamalmostafa: ah ok
<shadeslayer> kamalmostafa: nothing yet :)
<geser> the uploads are processed every 5 minutes
<shadeslayer> hmm
<geser> and LP will only mail you if it knows to which LP account the gpg key belongs to which signed the package
<shadeslayer> ok and if i want to build for karmic i just change the changelog right?
<shadeslayer> um oops
<shadeslayer> i didnt add my gpg key
<shadeslayer> ><
<shadeslayer> and btw can i delete keys on my system?
<strycore> hey
<strycore> no wrong channel
<RAOF> xteejx: Does it have any buildsystem currently?
<xteejx> RAOF: What do you mean?
<RAOF> xteejx: If I got this game from upstream, how would I install it?
<xteejx> RAOF: Oh, install python-pygame and run the game with 'python magicity' that's it
<RAOF> Ah.  So there isn't actually any build system or install instructions.
<shadeslayer> kamalmostafa: i guess i have to upload them again?
<shadeslayer> all the source files etc
<xteejx> If you mean make / configure script, no none of that, it's just a plain run and play
<xteejx> RAOF: A few .py files and the fonts/music/images thats all
<shadeslayer> jmarsden: do i have to upload the files again?
<jmarsden> shadeslayer: Now you signed them?  Yes.
<shadeslayer> ok
<sebner> RAOF: hiya, --nvidia fixed the issue mostly for docky. Happens not that often now, though I can reproduce it sooner or later after playing a 2D/3D game
<RAOF> xteejx: So, the fonts/music/images want to go in /usr/share, obviously.  You probably only want to put a single file in /usr/bin; this should have an appropriate shebang line (#!/usr/bin/python).
<shadeslayer> jmarsden: ok thanks mate :D
<jmarsden> shadeslayer: You're welcome.
<RAOF> sebner: Yeah.  The --nvidia switch works around the problem by droppnig & redrawing the buffers every 10 minutes.  You can use -b $MINUTES instead if you find that 10 minutes is too long. :/
<shadeslayer> jmarsden: btw can i delete my GPG keys on my local machine?
<xteejx> RAOF: It's just I don't know how to make it do that... I know how I'd do it myself, but not how the config would do that, although I *think* it all needs to be together in 1 directory
<shadeslayer> jmarsden: and how do i backup these keys?
<jmarsden> shadeslayer: You should use those same keys for some time... a year or two is common.
<sebner> RAOF: I'll try it out. The correct fix can only provide nvida I suppose?
<RAOF> sebner: I believe so.  Docky's not doing anything wrong, as far as I can tell.
<RAOF> xteejx: Heh.  Now you get to earn your keep as a packager.  The source doesn't comply with Debian policy, so you need to patch it until it does :)
<jmarsden> shadeslayer: https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Backing%20up%20and%20restoring%20your%20key%20pair
<sebner> RAOF: kk, thx again for the infos :)
<xteejx> RAOF: You're kidding me??
<shadeslayer> jmarsden: what about deletion?
<jmarsden> shadeslayer: What about it?  Why would you delete your own keys ??
<RAOF> xteejx: No, not kidding you at all.  This is one of the main reasons why we package - so that the system maintains a consistent policy!  Since it's python, you probably want to look at http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html .
 * xteejx cries
<RAOF> xteejx: Yah.  I've written a couple of buildsystems and sent them upstream for things I've packaged :)
<RAOF> xteejx: Sometimes you just have to do some work for upstream (and then submit it to them, so other distros don't have to duplicate it).
<xteejx> RAOF: Could I not just ask them to restructure it so it can be included? lol
<xteejx> RAOF: tbh I don't think it's maintained any longer, I just looked.... :(
<shadeslayer> jmarsden: i have 3 of them... dont need 2
<RAOF> xteejx: Yeah, that's what you're going to do.  But I find that asking developers to restructure it works better if you include a patch to restructure it at the same time :)
<xteejx> Actually even after all the hard work so far, I could ditch it and try another package, it wasn't LP'd anyway.... I could do that one another time.... what about ones that already have /usr /bin in the directories in the source tree... would they be easier to try for a first time, as I assume they just need copied to the root /  ?
<xteejx> It's gonna be my first package
<jmarsden> shadeslayer: I think you can use gnupg --delete-secret-and-public-key NAME     # Just get the right ones to delete :)
<shadeslayer> yayyy i got the mail about the packages
<shadeslayer> :D
<xteejx> Or put another way.... *ideally*, what should I look for when wanting to package for a first try to make it as easy as possible, with a smaller learning curve...I don't want to jump in head first and "hit my head on the bottom"
<RAOF> xteejx: Programs that have a reasonably sane build system are much easier to package, yes.
<jmarsden> shadeslayer: Make that    gpg --delete-secret-and-public-key NAME
<shadeslayer> jmarsden: but all 3 have the same nape :)
<kamalmostafa> shadeslayer: The gui program 'seahorse' might make finding the right keys easier also.
<shadeslayer> *name
<geser> shadeslayer: did you upload these keys to a keyserver?
<RAOF> xteejx: If something has an autotools buildsystem (Makefile.am, configure.ac, etc) it's generally a good bet that it'll Do The Right Thingâ¢.
<shadeslayer> geser: yep
<shadeslayer> geser: um no actually
<jmarsden> shadeslayer: Then you need to read the GPG docs really carefully, I think... I've never had to differentiate between two keys with the exact same name :)
<xteejx> LOL trademarked!
<xteejx> I understand though...makefiles and configure scripts = slightly easier life
<shadeslayer> woot : https://launchpad.net/~rohangarg/+archive/kde-extra
<RAOF> xteejx: But you don't have to package from scratch to learn packaging; taking an existing package and fixing a bug in it is highly (possibly even more) worthwhile.
<geser> shadeslayer: good, since once a key is uploaded you can't remove them from the keyservers anymore, only mark as revoked
<shadeslayer> geser: ok
<shadeslayer> ok and one more thing it says 32 bit build... but i wanted it to build for everything
<xteejx> RAOF: Of course :) The reason I wanted to do it from scratch is to learn the entire process hands-on...made more sense to me
<kamalmostafa> shadeslayer: Your build has already succeeded for amd64.  i386 build will start in 23 hours per your PPA page.
<geser> shadeslayer: is it an arch:all or arch:any package?
<shadeslayer> kamalmostafa: :o
<jmarsden> shadeslayer: I suspect you could use the keyid value instead of the name??  Might be worth a try, at least.  I'd back things up first to be safe :)
<xteejx> I want to find an unpackaged game that I think everyone will like...there doesn't seem enough choice (of immersive 3D ones I mean)...other than that we have absolutely LOADS!
<RAOF> xteejx: I don't think many MOTU started off by packaging something from scratch; it's very easy to usefully contribute by fixing existing packages, and you'll end up learning the whole process bit by bit.
<shadeslayer> jmarsden: ive already exported the key i wanted
<shadeslayer> kamalmostafa: i cant see the amd64 build
<xteejx> RAOF: You mean from bug reports that have patches on LP and just need repackaged?
<shadeslayer> kamalmostafa: found it
<shadeslayer> now onto to the karmic build :P
<RAOF> xteejx: That's a fine start, yes.  Also, bugs that have upstream links where upstream has fixed it, merging new versions from Debian, etc.
<xteejx> RAOF: The "please sync ### from Debian unstable" bugs?
<geser> xteejx: "Yo Frankie!" is still unpackaged (it has now even a bounty for packaging it)
<xteejx> geser: How much? haha
<geser> http://blog.thesilentnumber.me/2010/01/35-50-if-you-package-yo-frnakie.html
<sebner> geser: I've already read about it. wondering if this is possible. I don't think it has a (sane?) build system etc
<xteejx> geser: omfg that looks amazing
<geser> I didn't look at it yet
<xteejx> I honestly don't think I'd be able to do it if MOTU haven't already after 2 years! hehe I want an 'easy' project for my first time
<sebner> geser: I once downloaded it and had to open the files with blender and render it so get the game :P
<xteejx> RAOF: I assume merges from Debian is just a case of checking the files in debian/ ?
<xteejx> And editing of course
<RAOF> xteejx: It's a case of working out what's different between the Ubuntu & Debian packges, *why* they are different, and what parts of that difference still matter.
<xteejx> ROAF: I see, and apply those changes to our one, or simply copy it?
<RAOF> xteejx: https://wiki.ubuntu.com/UbuntuDevelopment/Merging is some slightly out of date documentation.
<ajmitch> geser: great bit of negativity in the comments there
<xteejx> RAOF: Cool. The wiki is so helpful sometimes, others it's just damn confusing! heh
<geser> I liked most "Ubuntu is dying." in one of its comments
 * ajmitch didn't realise that MOTUs spent all their time partying & blogging
<ajmitch> though I did just spend a week at LCA, so that's only partly true :)
<shadeslayer> jmarsden: ok one more thing,cant lucid and karmic survive in the same repo?
<jmarsden> shadeslayer: Packages for each of them?  Sure they can.
<sebner> ajmitch: beer!
<shadeslayer> jmarsden: and i just need to change the debian/changelog right?
<jmarsden> shadeslayer: Yes.
<shadeslayer> jmarsden: im getting Rejected:
<shadeslayer> File kopete-facebook_0.1.5-0ubuntu1.diff.gz already exists in KDE Extra stuff, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
<shadeslayer> Files specified in DSC are broken or missing, skipping package unpack verification.
<ajmitch> sebner: yes, I did drink some of that
<jmarsden> shadeslayer: You forgot to edit the package name in the changelog.  foo-0.1.5-0ubuntu1~karmic1~ppa or whatever
<shadeslayer> ah
<shadeslayer> thanks
<jmarsden> shadeslayer: You *did* read the Packaging Guide before doing any of this, right?
<shadeslayer> jmarsden: apachelogger told me this but i forgot :P
<geser> shadeslayer: you can upload a version of a package only once (if it gets accepted). if you want the same package for different releases you need to use slightly different versions (e.g. mention the release name in the package revision or similar)
<shadeslayer> jmarsden: i have to change (0.1.5-0ubuntu1) to kopete-facebook-0.1.5-0ubuntu1~karmic1~ppa
<shadeslayer> um wait not that
<shadeslayer> just the part after kopete-facebook :)
<blueyed> When live-tracing a process using "strace -p $PID", how do I know what identifier 3 refers to in a read?
<shadeslayer> jmarsden: right?
<jmarsden> Right.  Use whatever naming system you like, but ~karmic1~ppa is fine.
<shadeslayer> ok
<shadeslayer> jmarsden: and i add 0 to superseed it then right
<shadeslayer> at the end
<shadeslayer> for future revisions i.e
<jmarsden> shadeslayer: I'd do ~ppa1, ~ppa2, etc if you need minor changes to packaging only, yes.
<shadeslayer> jmarsden: thanks again :D
<jmarsden> You could do ~karmic2~ppa  ~karmic3~ppa  and so forth if you prefer...
<shadeslayer> i prefer the former
<jmarsden> Me too.  There;'s no magic in the naming, that's all I'm saying.
<shadeslayer> next up is choqok :P
<shadeslayer> or should is stop? its 5 in the morning :P
<shadeslayer> meh.. lets do thi
<shadeslayer> s
<shadeslayer> grrr... somebody beat me to it :(
<blueyed> answer to my question above: you can get this via "lsof -p $PID", which lists the descriptors.
<dupondje> whats need to be done when there is a bug in a patch in the debian/patches dir?
<dupondje> same steps to make new package or ?
<sebner> dupondje: update the patch and increment the versionsnumber in the changelog
<dupondje> diff -u ?
<crimsun> debdiff
<dupondje> crimsun: the patch in debian/patches is not created by debdiff I bet :)
<crimsun> you misunderstand, I think. Make your changes, increment the changelog, regenerate the source package, and generate a debdiff.
<dupondje> but the patch needs to be replaced first in debian/patches ..
<crimsun> then do so first
<crimsun> I would presume that falls under "Make your changes"
<dupondje> well just wanted to make sure you create that patch with diff -u, and no more options :)
<RAOF> There's generally an easier way to do it than that, but it depends on the patch system in use.
<dupondje> https://bugs.launchpad.net/ubuntu/+source/xchat-xsys/+bug/512113
<ubottu> Ubuntu bug 512113 in xchat-xsys "distribution not displayed correctly" [Undecided,New]
<crimsun> that's a malformed debdiff
<crimsun> note:
<crimsun> $ diffstat -p1 -l ../xchat-xsys.debdiff
<crimsun> debian/changelog
<crimsun> debian/patches/fix_whitespace
<crimsun> match.c
<crimsun> you're touching the file to be patched /outside/ of the quilt infrastructure
<dupondje> I know what I did wrong :( retry :)
<dupondje> $ diffstat -p1 -l xchat-xsys.debdiff
<dupondje> debian/changelog
<dupondje> debian/patches/fix_whitespace
<dupondje> is better :)
<dupondje> ok
<dupondje> patch uploaded
<dupondje> and tested :)
<dupondje> whats the next step ? :)
#ubuntu-motu 2011-01-17
<sagaci> just mute the audio if you do
<soc> hi
<soc> anyone from the openjdk ppa online?
<soc> i already tried it pn ubuntu-java, but there isn't to much happening in that channel
<soc> there is a probelm with all the openjdk-7-* packages
<soc> the "conflicts" version is bigger than the version of the deb itself
<soc> and is therefore not installable
<mase_wk> hey guys, i am trying to build a debian package using dpkg-deb -b dir however it complains that there is no DEBIAN/control file....there is a debian/control file however and all of the examples on packaging so far have indicated that the dir should be /debian not DEBIAN
<mase_wk> the package builds with sbuilder ok
<TheMuso> c
<Rcart> hello. For a python CLI program, it's enough just to add 'python' to the Build-Depends and Depends ({python:Depends}) fields in debian/control file?
<udienz> Rcart, not sure, but namy package put python-minimal
<Rcart> udienz: i was watching the emesene control file, and just put 'python' in the Build-Depends and '{python: Depends}' in the Depends field
<dholbach> good morning
<ari-tczew> dholbach: I changed natty to UNRELEASED because this one wasn't uploaded to archive.
<dholbach> ari-tczew, ah ok
<ari-tczew> ScottK: ping
<iulian> Morning dholbach.  Did you manage to wake up? :)
<dholbach> iulian, somehow I did, yes - after 11h of sleep I'm still tired
<ari-tczew> dholbach: This had to be a really good party
<dholbach> ari-tczew, it was jetlag, not the party :)
<ari-tczew> dholbach: aaaaaaaaa
<iulian> dholbach: Heh, yea, I know the feeling.
<dholbach> iulian, I'm back home again, the sun's shining, all's good - so I'm not complaining :)
<iulian> dholbach: Uh, I miss the sun.  It has been raining here for a few days now.  It's horrible when I have to go out.
<iulian> dholbach: Also, it's veyr windy, so brollies are useless.
<Laney> I swear Orlando was the last time I saw sun
<dholbach> iulian, luckily it didn't rain too much wherever I was
<mok0> We have sun... sorta
 * Laney weeps at ghc6
<Laney> please, please just build on armel :'(
<mok0> Laney, you need to be tough. Gcc doesn't respect a man who cries
<iulian> Good point. :)
<ricotz> coolbhavi, hello
<coolbhavi> ricotz, I am on it just back from outside :) just 5 minutes
<coolbhavi> :)
<ricotz> coolbhavi, alright, no worries
<ari-tczew> !patience | ricotz
<ubottu> ricotz: Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
<ricotz> coolbhavi, could you also look at the libgcrypt11 merge?
<coolbhavi> ricotz, m not a core dev so no
<ari-tczew> ricotz: once I had a situation, when I taken one merge and contributor had to wait 3 days for my response since status In Progress
<ari-tczew> ricotz: I'll look, I had a quick review this one in Friday
<ricotz> coolbhavi, ok, but you merged it the last time, i also asked cjwatson and he also declined to look at it :(
<udienz> thanks coolbhavi and ari-tczew
<ricotz> ari-tczew, ok, feel free to look at it, thanks
<coolbhavi> ricotz, no problems my merges are always free to take
<ricotz> coolbhavi, ok
<ari-tczew> coolbhavi: I'm interested in your merges in main :>
<coolbhavi> ari-tczew, as I said my merges are free to take mate anytime
<ari-tczew> ricotz: do you looking for free merges?
<udienz> ricotz, bug 692457, feel free to take it. i will looking others
<ubottu> Launchpad bug 692457 in bash (Ubuntu) "Please merge bash 4.1-3 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/692457
<ari-tczew> ricotz, udienz: in universe we have some packages commented as 'Feel free to take'
<ari-tczew> I encourage to get them.
<ricotz> ari-tczew, udienz , actually i am not really looking for merges, libgcrypt11 just came into my way
<ari-tczew> ricotz: ok understood.
<ricotz> ari-tczew, sorry
<ari-tczew> ricotz: I reviewed your patch.
<bdrung> dholbach: the .css files on http://reports.qa.ubuntu.com/reports/sponsoring/ are whitelisted now for easylist in adblock-plus
<ari-tczew> siretart: ping
<ScottK> ari-tczew: pong
<ari-tczew> ScottK: I have a proposed fix for FTBFS on armel and sparc in lucid. could you test it on your machine?
<ScottK> ari-tczew: I wouldn't worry about sparc, but I can probably test armel.
<ScottK> ari-tczew: Sparc in lucid doesn't run so there's no point in worrying about it at all.
<ari-tczew> ScottK: the change should works for both
<ScottK> OK.  Where's the diff?
<ari-tczew> ScottK: http://people.ubuntu.com/~ari-tczew/clementine/fix_ftbfs_on_armel_lucid.debdiff
<ari-tczew> ScottK: If it will built succeful, you could also upload it :)
<ScottK> ari-tczew: Why is this a correct fix?
<ari-tczew> or no, I'm rushing on other topic
<ari-tczew> ScottK: upstream proposed.
<ScottK> But it's not needed on Maverick or Natty?
<ari-tczew> ScottK: maverick and natty built armel fine
<ScottK> BTW, it'll be a bit as I have to create a Lucid chroot.
<ScottK> Right, so why is Lucid different?
<ari-tczew> ScottK: toolchain is different
<bcurtiswx_> Whats the proper patch editing technique with quilt
<bcurtiswx_> push the patch to be edited to top
<bcurtiswx_> then quilt edit (file)
<bcurtiswx_> then quilt refresh
<bcurtiswx_> anything else?
<tumbleweed> bcurtiswx_: http://dep.debian.net/deps/dep3/
<bcurtiswx_> tumbleweed, i don't see how that answers my question.. sorry
<Bachstelze> bcurtiswx_: yes
<bcurtiswx_> Bachstelze, so yes means thats all.. or what else is there?
<Bachstelze> that should do
<Bachstelze> unless you're modifying a file that is not yet in the patch, then you would do a quilt add
<tumbleweed> Bachstelze: quilt edit will add it for you if necessary
<bdrung> tumbleweed: i am looking at the byteprefix man page. it's what i wanted. thanks. some things can be improved. 1) the three options can have some examples. e.g. like on https://wiki.ubuntu.com/UnitsPolicy
<bcurtiswx_> Bachstelze, the file was in the patch already but it doesn't seem like it got added.. hmm
<ScottK> ari-tczew: Still fails: http://paste.ubuntu.com/555132/
<highvoltage> the last version of calibre uploaded to natty is 0.7.32+dfsg-1build1
<highvoltage> what should the next upload version be? 0.7.32+dfsg-1build2?
<geser> highvoltage: is it a rebuild or did you change something?
<highvoltage> geser: made a change to a .desktop file
<ebroder> highvoltage: if you made an actual change, it should be 0.7.32+dfsg-1ubuntu1
<geser> then 0.7.32+dfsg-1ubuntu1 (-build2 would be in the non-change rebuild case)
<ebroder> -NbuildM should only be used if there are no changes from the debian version
<ebroder> (the autosync infrastructure considers -NbuildM as being unchanged from debian)
<highvoltage> thanks, it didn't feel right without a 1ubuntu1 in there, but 0.7.32+dfsg-1build1-1ubuntu1 didn't look right either :)
<bdrung> tumbleweed: got my reply?
<tumbleweed> bdrung: was just having supper
<bdrung> tumbleweed: and i will have lunch in a few minutes. ;)
<tumbleweed> on holiday?
<bdrung> tumbleweed: my plan after lunch is to write a README, merge your man page (after addressing the points), and release 0.1
<bdrung> tumbleweed: no
<bdrung> tumbleweed: why did you thought that?
<tumbleweed> I thought we were in the same timezone
<bdrung> we are, but i eat to unusual times. ;)
<xteejx> Hi all. How do I edit the control file of an already-packaged .deb file to remove the version dependencies?
<tumbleweed> bdrung: aah hacker time :)
<bdrung> lunch at night, breakfast in the evening...
<bdrung> xteejx: why not take the source, edit debian/control, and rebuild the package?
<xteejx> I don't have the source, but really need the pkg to work
<xteejx> It's not in Ubuntu
<tumbleweed> xteejx: how sure are you that it'll work without those dependancies?
<xteejx> I'm not at all, but it's worth a try
<tumbleweed> dpkg --force-depends ?
<xteejx> I only want to remove the strict version restrictions so that it will install
<bdrung> xteejx: or extract the deb file, edit DEBIAN/control, and pack again (IIRC with dpkg-source)
<bdrung> time for lunch. :)
<xteejx> Hmm, the --force-depends option allowed the pkg to install, so will still need to install the deps
<xteejx> tumbleweed: I think that's worked, thank you :)
<tumbleweed> xteejx: my pleasure for helping you break your system :P
<xteejx> tumbleweed:  lmao, actually I'm trying to do a NAND flash of an HTC Kaiser to rid it of windows CE and stick android on it :)
<xteejx> so it's a little more complex than you might think ;)
<highvoltage> so an update to 0.7.38+dfsg-2 would become 0.7.38+dfsg-2ubuntu1 right?
<micahg> highvoltage: in Natty, yes
<micahg> highvoltage: are you fixing the calibre FTBFS?
<highvoltage> micahg: no, I was just about to find out that it has an FTBFS :)
<micahg> highvoltage: should only be on arm
<highvoltage> maco: around? I have some gally questions
<maco> highvoltage: yep
<maco> highvoltage: if its about natty, i know it doesnt work. a step in the build is failing
<highvoltage> maco: if I install gally, it also installs python-kde4 that depends on quite a lot of KDE stuff (like kde-pim, aconadi, etc) in Edubuntu that we don't really need there, do you have any suggestions for that? if those depends moved to recommends we could choose to not install those extra packages at build time
<highvoltage> maco: but I'm not sure if that would really be appropriate for that package
<maco> highvoltage: id ask riddell
<maco> highvoltage: though at the moment, i think we should hold off on gally til 11.10
<JontheEchidna> I don't think gally would run without python-kde4 present
<maco> not enough lessons to make it worth incuding
<maco> JontheEchidna: i think it was about the things python-kde4 depends on
<JontheEchidna> so it's more about what python-kde4 depends on?
<maco> JontheEchidna: yeah. it has a huge depends list.... 37 things
<JontheEchidna> It's a monolithic package containing bindings for every single kde library.
<maco> most are libraries though. do the libraries depend on their matching apps for some reason?
<JontheEchidna> Splitting it up would be quite a project, and we'd want to do that in concert in debian
<JontheEchidna> which apps are being installed?
 * maco looks at highvoltage for answer
<ebroder> JontheEchidna: +1 for splitting up python-kde4 and python-qt4 :)
<highvoltage> JontheEchidna: some kdepim stuff, akonadi, and other stuff (I have no idea what libknewstuff is :p)
<JontheEchidna> both kdepim and akonadi have both libraries and apps
<highvoltage> (sorry my boss is pesting me to update my timesheet for last week so work)
<JontheEchidna> libknewstuff is part of kdelibs, which used to be all one monolithic package kdelibs5
<JontheEchidna> so it's really not too much more than would have been installed a few releases ago, it just looks like more since it is split up further :P
<JontheEchidna> but, yeah.  A split at the python-kde4 level would be required to remedy this issue
<highvoltage> JontheEchidna: indeed. that would be ideal really.
<bdrung> tumbleweed: "this style uses base units 2 with SI prefixes" this is not 100% correct. the K prefix differs from SI
<maco> highvoltage: libknewstuff is something im planning on using to make it so gally can offer to download lesson packs from the net
<maco> ya know....once there are lesson packs
<tumbleweed> bdrung: r36
<highvoltage> maco: heh
<bdrung> tumbleweed: it's still "kB" for historic -> "KB"
<highvoltage> maco: but there are at least some lessons available right now aren't there?
<tumbleweed> bdrung: I can't parse that
<bdrung> tumbleweed: historic: "1 KB = 1 024 bytes.", not "1 kB = 1 024 bytes."
<maco> highvoltage: a couple ASL ones. someone had volunteered to work on dutch ones but disappeared :-/ atm we have a list of lessons we'd like to have (so there's some direction, not just "sign some words in front of a camera") but...
<tumbleweed> bdrung: oh I see
<highvoltage> maco: if there are even just a few I'd ideally like to keep it in edubuntu for this release, assuming it runs again in time :)
<maco> highvoltage: i'll fix the not building ness by feature freeze ;-) ive just been busy with exams then moving then job hunting, now packing to move again and apartment hunting...
<bdrung> tumbleweed: to point 1) yes, i want more. at least giga should fit without wrapping at 80 chars
<maco> a few weeks helping mum since she had knee surgery... busy!
 * bcurtiswx waves at ms maco
<maco> hi bcurtiswx
<bcurtiswx> maco, how's the home life?
 * maco points at the word busy
<highvoltage> maco: yay, cool.
<bcurtiswx> maco, sounds just soo much fun.  Well I wish ya the best on your soon to be transition :)
<maco> dear online banking: not everything has to be a servlet. you can list the "stuff you can redeem points for" with good ol' html
<micahg> maco: think of network overhead as another banking fee
<bdrung> tumbleweed: can you review my current README: http://paste.debian.net/104909/ ?
<tumbleweed> bdrung: s/setup/set up/ when it's a verb. "libkibi is a library for byte prefixes. It's designed for formatting bytes." - neither of those actually describes what the library does (format sizes for display)
<tumbleweed> bdrung: "The
<tumbleweed> (whoops) ... byte prefixes are used depending on the user preferences." <- clumsy. I'd use something like "The user can configure a preferred prefix style."
<bdrung> yes, that sounds better
<tumbleweed> Input Functions could probably use some brief explanation too. That's all I can see.
<bdrung> tumbleweed: http://paste.debian.net/104910/
<bdrung> tumbleweed: yes, i was interrupted by your branch :)
<tumbleweed> "formatting bytes" still doesn't quite sound right, "sizes in bytes" ?
<bdrung> -> formatting sizes in bytes
<tumbleweed> yeah. oh another one: "format sizes for outputting them" -> "format sizes for output"
<bdrung> tumbleweed: http://paste.debian.net/104911/
<tumbleweed> "These functions can be used for converting bytes into the unit in which the user could edit them" <- don't understand that. "user could edit them" ? Also "converting bytes"? Sounds like converting raw data
<bdrung> tumbleweed: example: a user wants to set a bandwith limit in transmission in "kB/s" or "KiB/s". the size needs to be converted from bytes into kB/KiB and then back again.
<bdrung> tumbleweed: one last this with the man page: "(1 K = 10^3 = 1 000) and base 2 (1 K = 2^10 = 1 024)". to what does the "1K" refer to? shouldn't the first "1K" be a small "1k"?
<tumbleweed> "for converting between sizes with units (for example to allow a user to edit a value in KB/s)"?
<tumbleweed> I was just using k as an example of order of magnitude (first order), yes having the first one bing a "k" probably makes sense
<bdrung> tumbleweed: dropping the "1k =" would be ok too. "base 10 (10^3 = 1000) and base 2 (2^10 = 1024).
<bdrung> "
<tumbleweed> I think it's clearer to keep it
<bdrung> k
<tumbleweed> heh
<bdrung> the word "k" is overloaded :)
<bdrung> tumbleweed: http://paste.debian.net/104916/
<tumbleweed> bdrung: LGTM
<bdrung> tumbleweed: did i forget something that should be in the readme?
<tumbleweed> maybe one sentance about the lincence?
<bdrung> tumbleweed: http://paste.debian.net/104917/
<bdrung> with new "Developing libkibi" section
<tumbleweed> LGTM
<bdrung> tumbleweed: man page merged. thanks.
<tumbleweed> np
<bdrung> tumbleweed: pushed. is there something left that i should do before the release?
<tumbleweed> bdrung: can't think of anything. BTW how do you intend to handle the byteprefix manpage? separate -doc package?
<bdrung> tumbleweed: i put it into libkibi0
<tumbleweed> that would then conflict if you had an ABI bump
<bdrung> right. so i have to add a -doc package
<tumbleweed> I guess so, I don't know how this is usually done
<bdrung> tumbleweed: should libkibi0 recommend the -doc package?
<tumbleweed> yeah, that sounsd good
<bdrung> tumbleweed: what do you think about naming it libkibi-man instead of libkibi-doc (the latter could be false judged as library documentation for the programmer)
<tumbleweed> bdrung: sounds good, and I see gss does that
<tumbleweed> (oh whoops, that *is* API)
<ari-tczew> ScottK: have you got an idea how to fix it?
<bdrung> tumbleweed: can you review lp:~libkibi-dev/libkibi/packaging ?
<tumbleweed> bdrung: I'd add a .bzr-builddeb so it knows the package uses merge mode. debian/copyright needs a new entry :). -dbg package?
<tumbleweed> bdrung: looks like I broke something: "config.status: error: cannot find input file: `doc/Makefile.in'"
<bdrung> tumbleweed: you have to run "make dist" to create the source tarball. merging the bzr branch doesn't work.
<bdrung> tumbleweed: pushed. should i really add a -dbg package?
<tumbleweed> bdrung: ah, thanks. Debian doesn't have ddebs (yet?), so I normally do them.
<cody-somerville> Is a watchfile considered important enough these days to maintain a delta against Debian? I know there was a big push to add watch files a year or two ago.
<micahg> cody-somerville: I suggest adding it and then using submittodebian
<bdrung> cody-somerville: I think that it can be dropped if you file a bug against the debian package.
 * tumbleweed would probably not sponsor an upload that just added a watchfile
<cody-somerville> Yea. I'm thinking I'd accept the sync request instead of insisting they prepare an upload - especially since the watchfile wasn't even in the list of the remaining changes against Debian.
<tumbleweed> yeah, (but obviously get it filed :)
<micahg> ah, yeah, actually, there's no reason, AFAICT, there's no tool using just the Ubuntu watch files
<bdrung> micahg: uscan?
<micahg> bdrung: I meant that has a report
<tumbleweed> micahg: doesn't LP now display "new upstream version" messages on source package pages?
<bdrung> tumbleweed: pushed with -dbg package.
<micahg> tumbleweed: is that based on the watch file or on the actual upstream in LP
<bdrung> micahg: i assume that it's based on the actual upstream in LP
<tumbleweed> aah right. There is of course UEHS
<bdrung> tumbleweed: ready to release or did you find anything?
<micahg> tumbleweed: right, which I was thinking of before, but AFAICT, that's for Ubuntu specific stuff
<tumbleweed> bdrung: no issues I can see. ACK.
<bdrung> tumbleweed: should i install the README file?
<tumbleweed> bdrung: possibly in -dev, you don't have any other API documentation besides the header
<tumbleweed> micahg: yeah
#ubuntu-motu 2011-01-18
<bdrung> tumbleweed: libkibi released.
<micahg> highvoltage: sorry about calibre, I should've checked with you before updating
<micahg> highvoltage: I'll try to get it fixed
 * micahg didn't realized it was seeded
<mase_wk> i am trying to build a package of dovecot using sudo sbuild --arch=i386 -d lucid dovecot_2.0.9.dsc
<mase_wk> E: 10mount: mount: unknown filesystem type 'aufs'
<akheron> how do I assign a Launcpad bug to Lucid?
<micahg> akheron: nominate for release?
<akheron> hmm, I've seen that link but cannot find it in this bug
<micahg> akheron: bug #?
<akheron> bug 657394
<ubottu> Launchpad bug 657394 in encfs (Ubuntu Maverick) "please sync encfs 1.7.2 from debian unstable - security vulnerabilities" [Undecided,Confirmed] https://launchpad.net/bugs/657394
<micahg> akheron: we can't sync a new version for security fixes for the stable release, so you might want to update the title to what you want to fix
<akheron> true
<micahg> akheron: it's now nominate for series, not release
<mase_wk> is there another way of building a package for lucid on maverick ?
<micahg> mase_wk: pbuilder, sbuild, chroot?
<mase_wk> aside from sbuild -d maverick-i386 packaging_dovecot2/dovecot_2.0.9.dsc
<akheron> reading the security team update procedures, it seems to me that these vulnerabilities aren't grave enough to get a security update
<mase_wk> micahg: having an issue with sbuild not understanding a 'aufs' file system
<akheron> mase_wk: pbuilder-dist maverick create; pbuilder-dist maverick build packaging_dovecot2/dovecot_2.0.9.dsc
<micahg> akheron: if you provide debdiffs, the security team will be happy to upload
<mase_wk> akheron: do i need arch specified at all , i want to make an i386 package on an 64bit install
<akheron> micahg: yes but as lucid has 1.5 and the bugs have been fixed in 1.7, I'd have to do lots of patching
<akheron> err, backport the patches that fix the security issues
<micahg> akheron: right
<micahg> akheron: I can give you a lucid task if you want to work on it
<akheron> micahg: well, I don't think I have time really :(
<akheron> mase_wk: pbuilder-dist maverick i386 create; etc...
<mase_wk> thanks   will try that
<akheron> micahg: easier for me would be to just use try to use the natty package in lucid or backport 1.7 and build it myself
<micahg> akheron: right, that fixes it for you, but not others
<akheron> yep :(
<dholbach> good morning
<Rcart> o/ danniel
<Rcart> here's pretty late, good nights ^^
<iulian> G'morning dholbach.
<dholbach> hiya iulian!
<Laney> argh! ghc6 still hasn't finished on armel
<ari-tczew> could anyone take a look on bug 702765 and check whether is it a sync?
<ubottu> Launchpad bug 702765 in libgcrypt11 (Ubuntu) "Please sync libgcrypt11 1.4.6-4 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/702765
<ari-tczew> geser: ping
<ari-tczew> geser: unping, found the information
<highvoltage> micahg: no problem! and no reason you should've checked with me either, it's fine :)
<ScottK> ari-tczew: No.  Sorry.
<ari-tczew> siretart: could look on bug 702765 ? the only remaining change is dirs which you added. can we drop it?
<ubottu> Launchpad bug 702765 in libgcrypt11 (Ubuntu) "Please sync libgcrypt11 1.4.6-4 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/702765
<nonix4> ari-tczew: you happen to have time to look at 683337 again?
<ari-tczew> bug 683337
<ubottu> Launchpad bug 683337 in w3m (Ubuntu Lucid) "Backport button element support to Lucid" [Wishlist,In progress] https://launchpad.net/bugs/683337
<ari-tczew> nonix4: did you test your patch?
<nonix4> yes, tested the deb built with pbuilder
<micahg> err, features normally don't go through SRU, but I guess this is an exception
<ari-tczew> micahg: not biggest feature - one button ;)
<dholbach> highvoltage, did you hear back from menesis about schooltool?
<micahg> ari-tczew: doesn't matter, features are normally done through backports
<siretart> ari-tczew: sorry, not before next week
<highvoltage> dholbach: the last time we communicated was the email he sent us on 05/01/11
<dholbach> highvoltage, ok - I just thought you might know more - it seems like everyhting in the NEW queue was processed and there's just this one package left that bundles some other code
<dholbach> it'd be great to get it sorted out soon
<menesis> dholbach, highvoltage: hello
<menesis> thank you both for uploading all of the packages
<menesis> they reached archive last Monday
<menesis> there is only one left, zope.html, that bundles both fckeditor and ckeditor
<dholbach> menesis, is it possible to rip it out of the source, add dependencies and add symlinks in the zope.html package to make it "just work"?
<menesis> it was kind of hard for me to figure when and from where to remove it
<dholbach> yeah, doing that is a pain :/
<menesis> is it ok to "rm src/whatever" and then dh_install?
<dholbach> I'd probably set up a get-orig-source target that sets up a tarball that does not include that source
<tumbleweed> if it's redistributable, it may not be necessary to rip it out the source (unless you are already doing a +dfsg)
<menesis> license is ok, GPL/LGPL/MPL
<menesis> will try to make it work now
<menesis> remove is one thing but have to symlink as well, so repackaging alone won't help
<tumbleweed> menesis: dh_link makes the symlinks easy enough. Given that it's redistributable, I wouldn't bother repacking, just remove those files before dh_auto_install (assuming dh)
<tumbleweed> longer term, it may be worthwhile convincing the upsrteam to bundle less :)
<micahg> tumbleweed: usually better to ask for a flag to use system versions of things
<micahg> upstreams feel the need to provide everything
<menesis> override_dh_auto_install: rm -r src/.../ckeditor ; dh_auto_install
<tumbleweed> yeah, een better
<menesis> is it ok?
<tumbleweed> menesis: sounds good
<menesis> to rm from source
<menesis> bzr-builddeb builds in temp directory so should be good
<tumbleweed> menesis: what build system? will it fail when it tries to install the deleted files?
<menesis> dh --with python-central
<tumbleweed> menesis: you can't rely on that behavior, but if files aren't needed at any point, that's fine, dpkg-source understands missing files
<tumbleweed> menesis: I mean, is it a setup.py?
<menesis> yes
<tumbleweed> err python-central? I'd avoid that for new packages?
<tumbleweed> the setup.py / MANIFEST.in will have a list of files in it to install, if they are deleted, it may not work so well (depending on how the list is implemented)
<tumbleweed> in that case, patching setup.py is a reasonable option
<highvoltage> menesis: hey there! (sorry for slow response I'm kind of out of action today)
 * Laney flaps
<Laney> ghc is so close to being built
 * DktrKranz encourages Laney 
<Laney> encourage the buildd!
<Laney> dpkg-deb: building package `ghc6' in `../ghc6_6.12.3-1ubuntu3_armel.deb'.
<Laney> `o/
<micahg> highvoltage: calibre ended up building fine after retry, it seems like it was a transient build failure
<highvoltage> micahg: cool! thanks now I can apply my change :)
<stevecrozz> how do I send a package to launchpad for building on a distribution that I'm not running?
<stevecrozz> i've been using 'bzr builddeb -S', do I just specify the distro I want in debian/changelog?
<micahg> stevecrozz: yes
<stevecrozz> micahg: i'm maintaining the package source in launchpad, if I want to build the package for multiple distributions, what do I commit to bzr in my debian/changes to allow that
<micahg> stevecrozz: you might want to use Launchpad build recipies for that, or there's a tool someone built called drobotik: https://launchpad.net/drobotik
<pabelanger> micahg: Thanks for that link.  I've been wanting to try it for a while now
<trinikrono> hey guys i work with the bugsquad and i am seeing a lot of needs-packaging bugs is there anything i can do to help them get noticed or worked on?
<micahg> trinikrono: https://wiki.ubuntu.com/Bugs/HowToTriage#Needs%20Packaging%20Bugs
<trinikrono> micahg: thats what i was reading
<micahg> trinikrono: it says what you can do there
<trinikrono> okie will do
<trinikrono> micahg: do i have to make the upstream rfp or should the reporter make it?
<micahg> trinikrono: not really any point, RFPs are usually ignroed
<micahg> *ignored
<micahg> or rather, there's not usually people working on them
<trinikrono> ok hold on
<trinikrono> lets say bug 622185
<ubottu> Launchpad bug 622185 in Ubuntu "[needs-packaging] bsnes" [Wishlist,New] https://launchpad.net/bugs/622185
<trinikrono> what should happen before its triaged?
<micahg> trinikrono: we should go back to -bugs
<pabelanger> Daviey: ping?
<matttbe> Hello
<matttbe> I'm looking for a sponsor in order to merge my branch lp:~cairo-dock-team/cairo-dock-plug-ins/ubuntu into lp:ubuntu/cairo-dock-plug-ins
<matttbe> => https://code.launchpad.net/~cairo-dock-team/cairo-dock-plug-ins/ubuntu/+merge/46668
<matttbe> But this is not my main request. I also want to note that this branch "lp:ubuntu/cairo-dock-plug-ins" is not up to date.
<matttbe> Who can help me to fix this problem and/or what can I do?
<micahg> matttbe: it's a UDD bug
<matttbe> Do I have to contact the ubuntu-branches team?
<micahg> matttbe: http://package-import.ubuntu.com/status/cairo-dock-plug-ins.html#2010-04-22%2002:11:14.824041
<micahg> matttbe: you can file a bug at https://launchpad.net/udd
<matttbe> micahg: thank you! :)
<stevecrozz> I want to propose this package be included in ubuntu (https://launchpad.net/~uwsgi/+archive/release/+packages), should I go over it with someone first? or should I just make the proposal?
<micahg> stevecrozz: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<kamal> hello MOTU's ...  its been awhile since I've done a LP/bzr merge proposal.  is this properly queued?:
<kamal> https://code.launchpad.net/~kamalmostafa/ubuntu/natty/alarm-clock-applet/lp704659/+merge/46705
<kamal> and is it proper that I assigned the bug LP #704569 to ubuntu-sponsors ?
<stevecrozz> micahg: the maintainer of the proposed debian package has decided the ubuntu package should be maintained separately to account for separate packaging needs, i think that means I'm in the 'Going through MOTU' section of this document
<ubottu> Launchpad bug 704569 in iscsitarget (Ubuntu) "ISCSI Reservation Conflicts with VMWare" [Undecided,New] https://launchpad.net/bugs/704569
<kamal> oops make that bug LP: #704659
<ebroder> kamal: bugs should never be *assigned* to ~ubuntu-sponsors. if you attach a debdiff you should subscribe ~u-s, but if you have a merge proposal you should not
<kamal> ebroder: oops -- glad I asked -- who should the bug be assigned to?
<ebroder> kamal: nobody
<micahg> stevecrozz: shouldn't need to do that
<ebroder> kamal: (opening a proposal to merge a branch into one of the lp:ubuntu/ branches automatically causes that to show up on the sponsorship queue; additionally subscribing ~u-s to the bug causes it to show up twice)
<stevecrozz> macahg: can you elaborate? do you mean the package should be maintained upstream with debian?
<kamal> ebroder: got it, thanks much
<micahg> stevecrozz: ideally, yes, do you have a link to where the Debian maintainer said that
<kamal> ebroder: oh I see -- I had confused "subscribing" and "assigning" ... *sigh* it has been awhile.
<stevecrozz> micahg: he said it in an email to me, i can forward that to you if you like, it was pretty informal
<micahg> stevecrozz: no, that's ok, it's not even in Debian yet
<micahg> stevecrozz: what changes are necessary?  we can maintain a diff if necessary, but there shouldn't need to be many
<stevecrozz> micahg: i'm not entirely sure, maybe i can get leonid in here later and we can discuss the differences
<stevecrozz> i want to organize some kind of communication here so we don't miss any more releases, its already been 2 or 3 since i started maintaining a ppa for this package
<stevecrozz> micahg: the document says i need this package signed off on by two ubuntu developers, how can I find them?
<micahg> stevecrozz: well, we still have a month until feature freeze, but you need to upload to revu, it would be better to sync from Debian and add changes on top
<stevecrozz> micahg: ok I'll sync with the owner of the proposed debian package and try to figure out if we can get it included in debian
<micahg> stevecrozz: just keep in mind, Feb 24 is the cut off for new packages unless there's a really good reason
<stevecrozz> yeah i doubt i'll make the cutoff, i just want to get some forward momentum because this package is useful and its getting nowhere fast as far as official packaging
<micahg> stevecrozz: well, if you won't make the cutoff you can try to go through revu, it would just be easier if it's maintained in Debian, once it's in, we can sync from Debian after that
<stevecrozz> micahg: so i can propose the package with the thought of maintaining them separately only until it makes it into debian?
<micahg> stevecrozz: yes
<stevecrozz> sounds reasonable, thanks, i'll get started
#ubuntu-motu 2011-01-19
<onehundredthirty> Hi, I'm a maintainer of uWSGI package for Debian and co-maintainer of the same package for Ubuntu. I'm here to elaborate needing of separate package for Ubuntu.
<micahg> onehundredthirty: what's the issue?
<onehundredthirty> Some binary package of Debian uWSGI package is depends from python2.5 but it's support was officialy dropped since Lucid
<micahg> onehundredthirty: that can be handled with control.in
<onehundredthirty> Is it common practice? Are there packages with control.in which I could look into for example?
<micahg> openjdk is the craziest example I can think of, I'm sure there are more sane ones
<ebroder> wait, why do you need a control.in for that?
<micahg> ebroder: different binaty depends?
<micahg> *binary
<ebroder> just build-dep on python and dep on ${python:Depends} and properly apply the python policy
<micahg> hmm, yeah, that would work too :)
<micahg> onehundredthirty: is that the only issue?
<onehundredthirty> Could you look into my debian/control http://paste.ubuntu.com/555606/ and say is ${python:Depends} is the soultion?
<onehundredthirty> Yes, modifying of debian/control in process of building is only issue
<ari-tczew> onehundredthirty: this is new package?
<onehundredthirty> I'll try to download source package for openjdk now and take a look into it's debian/control
<micahg> onehundredthirty: well, if that's the only issue, the worse thing would be to drop the python2.5 package when syncing, there's probably a better solution I'm not aware of
<micahg> onehundredthirty: openjdk won't help here I don't think
<onehundredthirty> Yes, this is new package, It has an ITP bug in Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582864
<micahg> ebroder: there's a problem with generating d/control at runtime or just the build-depends?
<onehundredthirty> Just dropping 'uwsgi-python2.5' will break 'uwsgi' (as it depends on uwsgi-python2.5)
<onehundredthirty> Yes, I need to generate whole debian/control in runtime
<micahg> onehundredthirty: no, it looks like it's an OR, so it won't break
<ebroder> onehundredthirty: is there a particularly compelling reason to build it for more than just the default python version?
<onehundredthirty> Yes, the binary of uWSGI is directly linked with libpython*. So for serving with different Python versions I need to build different binaries.
<ebroder> right, but i don't think any of the other wsgi servers are packaged like that
<ebroder> i think they're only built to run against the default python
<onehundredthirty> you are right (just look at libapache2-mod-wsgi and it has only version linked with libpython2.6), but nevertheless I believe that providing package for each available Python version gives more pretty user expirience
<onehundredthirty> oh, no. there is libapache2-mod-wsgi-py3 also
<onehundredthirty> as I see, in openjdk there is an debian/control target but it's invoked manually by maintainer. autogeneration of debian/control in process of building is a bad practice. am I right?
<ebroder> yes, the debian ftpmasters would reject that
<ebroder> onehundredthirty: why not do one package that's whatever current python2 is, and one package that's whatever current python3 is?
<ebroder> (the debian/ubuntu python infrastructure basically considers py2 and py3 to be different languages, as well it should)
<onehundredthirty> ebroder: well, I could go this way. But it doesn't seems like my original intention of packaging uWSGI for all available python versions.
<ari-tczew> bdrung: http://paste.ubuntu.com/555614/
<ebroder> onehundredthirty: so, if you're going to insist on it, it is possible to define packages in debian/control that don't actually get built. you can look at the zephyr package for an example
<ebroder> you could use that to only build against a particular python version if that version was available
<ebroder> but that'll be more of a maintenance burden as new versions of python are introduced than if you just use the default python version
<ebroder> if you do the latter, then the package can be updated as the python defaults change using the binNMU process - without any intervention on your (or your sponsor's) part
<ebroder> and as a point of reference, it doesn't look like there are currently any packages in the maverick archive that depend on libpython2.7, so i don't think anybody is really linking against multiple python interpreteres
<ebroder> *interpreters
<onehundredthirty> wow, python2.7 is in maverick already. I didn't notice it (in Debian python2.7 is in experimental, so I forgot it). so, there is one more difference between Ubuntu and Debian regarding uWSGI package (I think about uwsgi-python2.7)
<ebroder> onehundredthirty: yes, and python2.7 is the default in natty
<micahg> you could use control.in to substitute 2.7 for 2.5
<ebroder> micahg: yes, but such a package couldn't be synced
<micahg> ebroder: why not?
<micahg> dpkg-vendor generate control on build
<ebroder> really? i thought that was strictly disallowed
<micahg> ebroder: it might be :)
<micahg> that's what I was asking before about generating control at buildtime
<ebroder> micahg: see "CDBS" under http://ftp-master.debian.org/REJECT-FAQ.html
<micahg> ebroder: that's build-depends, not the binary packages
<ebroder> yeah, good point
<ebroder> sorry. must be running short on caffeine
<micahg> I read something about that earlier today, that's why it was on my mind
<micahg> ebroder: also, if d/rules with dpkg-vendor is just doing a straight substitution, it'll be the same every time
<onehundredthirty> micahg: but where in d/rules should I put invocation of dpkg-vendor and instantiating of d/control? in 'clean' target?
<onehundredthirty> micahg: like recommended in http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/#comment-3744
<micahg> yes
<stevecrozz> micahg: I've uploaded a uwsgi package to revu in attempt to close the needs packaging bug https://bugs.launchpad.net/ubuntu/+bug/704705
<ubottu> Ubuntu bug 704705 in Ubuntu "[needs-packaging] uwsgi" [Wishlist,Fix committed]
<micahg> stevecrozz: BTW, I assume you saw the Debian packaging on mentors.debian.net and this is based on that?
<stevecrozz> micahg: yes it is if you're talking about the thread from May, 2010
<micahg> stevecrozz: I gave some initial feedback, I don't have time to run it through lintian and pbuilder ATM
<stevecrozz> micahg: is there anything i need to do at this point?
<micahg> stevecrozz: you could fix the things I mentioned (except the version, not sure about multiple uploads to revu w/the same version)
 * micahg is going to get some sleep
<stevecrozz> micahg: you mean about using the default python right?
<micahg> stevecrozz: no, I commented on revu
<stevecrozz> oh ok, thanks, have a nice night then :)
<micahg> if it's still building a python 2.5 version, that will need to be fixed too
<micahg> stevecrozz: if you ask here, someone should respond at some point, otherwise I will in the morning
<Rcart> hello. i'm packaging an app that's complaining about info related documents. Can somebody take a look to the lintian and the doc/package.texi output please?
<Rcart> hello
<Rcart> i've 'debianized' a package that isn't in debian
<Rcart> i'm thinking to  send it to debian and later request a sync from ubuntu
<Rcart> any suggestions making this happen?
<Bachstelze> Rcart: you need to get a sponsor to get it into debian
<RAOF> billz: Yes, it is against debian policy.  You don't get to work around lintian by creating directories in postinst :)
<RAOF> billz: You should create a directory in the appropriate FHS directories; if you need to patch the software to make this work, you need to patch the software.
<billz> RAOF: thanks just checking :)
<Rcart> Bachstelze: Thanks, i just need to correct one lintian check and the package will be clean
<Rcart> This is the error: E: menumaker: package-contains-info-dir-file usr/share/info/dir.gz   someone has correct this error?
<Bachstelze> Rcart: google on the tag wil give a description of what the problem is
<Bachstelze> will*
<billz> I need to create a folder "/var/run/myapp/" as part of my setup where should this be triggered? lintian complains if i add this to package.dirs
<RAOF> billz: I believe that you should create that as a part of your init script, as I think /var/run is allowed to be a tmpfs.
<RAOF> billz: And, as such, you can't expect any subdirectory of /var/run that you create at install time to still be there when the program gets run. :)
<Rcart> Bachstelze: Thanks again.
<MTecknology> !info nginx natty
<ubottu> nginx (source: nginx): small, but very powerful and efficient web server and mail proxy. In component universe, is optional. Version 0.8.53-2 (natty), package size 327 kB, installed size 900 kB
<MTecknology> :(
<MTecknology> So... when is it too late to file a sync request for a package?
<billz> RAOF: Looking at other applications like apache or asterisk i cant see them creating the init creating the folder in /var/run. so where do they do that?
<tumbleweed> MTecknology: you can file them after freeze, but then you may need an FFe. We can sync all the way up to a week before release, but it gets harder to justify it
<tumbleweed> "a week before release" being a vague hand-wavy number
<MTecknology> tumbleweed: thanks! I was gunning for the end of the week; there's some icky packaging bugs that I'm trying to fix right now and once I fix them I want to get the package sync'ed asap. :)
<MTecknology> but it's past 3am so I don't really know why i'm worrying about this tonight. :P
<MTecknology> tumbleweed: I'm guessing upgrade issues are enough of a reason for a sync?
<tumbleweed> MTecknology: use the same justification you would for an upload. Fixing a bug and probably not introducing a worse one is good (for most universe packages, just having someone look at the package is better than nothing)
<RAOF> billz: I don't know about apache or asterisk, but http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init says âyou can't rely on subdirectories of /var/run persisting, so do it in initscriptsâ.
<soren> RAOF, billz: Not only is /var/run *allowed* to be a tmpfs. It's actually been a tmpfs in Ubuntu for years and years and years.
<soren> And creating the directory in an init script is the right way to do it.
<billz> RAOF, soren: Thanks
<soren> Sure thing!
<ari-tczew> hey
<ari-tczew> how can I reply to this list? http://lists.debian.org/debian-mentors/2011/01/msg00318.html
<ari-tczew> ScottK: ping
<MTecknology> I'm noticing that the only thing left on my system that depends on python2.6 in 11.04 is bzr. Any chance that'll get rebuilt before natty is released?
<tumbleweed> MTecknology: it's using python2.6 intentionally, it doesn't work with 2.7 yet
<MTecknology> tumbleweed: sad- thanks
<tumbleweed> MTecknology: that should be sorted soonish, I think
<MTecknology> yay
<ari-tczew> micahg: I considered full backport w3m from natty. I think it's better way. However, I'd like to push package to -proposed as SRU instead -backports.
<Laney> sup tit
<Laney> persia: You didn't leave very long for people to nominate
<persia> Laney, in 13 hours, there will be 6 less DMB members :)  If we don't get enough nominations, we might send out another request.
<Laney> well presumably the TB could have extended the terms by a week or so
<Laney> but yes, I understand why it was :)
<persia> I requested they extend them by a month, but that just covers the time I posted.
<Laney> aOK
<persia> With luck, we'll get eight or nine nominees, so we have a good field for selection.
<ari-tczew> I'm not in the subject... what's going on with DMB?
<Laney> see -devel
<ari-tczew> Laney: could you point me to date and time?
<Laney> Date: Wed, 19 Jan 2011 22:58:41 +0900
<ari-tczew> Laney: maybe we are on another channel... #ubuntu-devel?
<Laney> ari-tczew: no, the mailing list :)
<ari-tczew> Laney: coulnd't you say that firstly?
<Laney> it's not a big deal
<ari-tczew> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-January/date.html
<ari-tczew> which one?
<Laney> devel not devel-discuss
<ari-tczew> nice, now only bdrung is DMB
<cdbs> geser: The DMB ML doesn't send 'your mail has bounced' messages?
<cdbs> geser: un-ping, I guessed it doesn't
<Laney> it accepts mails from non-subscribers
<ScottK> ari-tczew: Pong
<ari-tczew> ScottK: Case: w3m package. I would like to backport package from natty, but push it through -proposed instead -backports. There is no new upstream release. What do you think?
<Rhonda> There wasn't a new upstream release for w3m in ages? :)
<Rhonda> ari-tczew: Actually "debian/patches/010_upstream.patch: Sync with the upstream development snapshot on 2010-10-11" sounds like a "hidden" new upstream release to me.
<Rhonda> "55 files changed, 32850 insertions(+), 8407 deletions(-)" is the diffstats of that patch
<Laney> that's an interesting way of upgrading to a new release
<ari-tczew> Rhonda: mhm, then rather backport. But why cannot through -proposed => -updates? Not everyone has enabled -backports.
<Laney> because that is not the purpose of a stable release update
<Rhonda> Because -proposed â -updates is for SRU which are limited to important bugfixes and security updates.
<ari-tczew> nonix4: would you like to have a full w3m from natty on lucid and maverick?
<Rhonda> I consider it unlikely that you'll be able to get this w3m diff in for SRU when I wasn't able to get in a stable wesnoth update in. ;)
<Laney> you weren't? There's precedent for new bugfix releases
<Laney> eg banshee
<directhex> chromium-browser?
<Laney> docky
<Laney> :-)
<Rhonda> Laney: I think it was blocked on the grounds that I would have needed to strip down the changes a fair bit, I think even translation updates would had been blocked
<Laney> I think they usually like a stripped down diff for review, but you can upload the full new release
<Rhonda> I just know that it was too much effort for me to pick up at that time, and given that my sponsoring funds for this work isn't really taking off I have to priorize my efforts.
<directhex> Rhonda, how are you trying to fundraise? i've had some experience on that
<Rhonda> directhex: Tell people that I can hand them my amazon/paypal/flattr links in case they want me to do something specific. :)
<Rhonda> Otherwise they have to live with how I priorize and schedule my time on my own.
<directhex> ah. "packager for hire!"
<Rhonda> Actually qcake is the only package that was ever "funded".  Upstream approached me, I told them that I don't have a 3d card to properly test it, and got one through that.
<directhex> the badgerports model has been suspiciously successful for me, but perhaps mono folks just have loads of microsoft bribes to spend
<ScottK> ari-tczew: You'd need to talk to someone in ubuntu-sru about that.
<ari-tczew> ScottK: what do you think about merge ubuntu-sru and ubuntu-backports into one team? Members could decide which one is better way.
<ScottK> ari-tczew: No.  I think the processes and intent of updates/backports are sufficiently different that it wouldn't be helpful.
<ari-tczew> well, I wanted to improve workflow.
<micahg> also, ubuntu-sru is basically pitti at this point
<ari-tczew> micahg: I consider join to ubuntu-sru in next months.
<kamal> I've got a LP merge proposal that I want to mark as "no longer proposed" -- must I actually delete the proposal (and so lose its comment history) or is there another way to mark it so?
<kamal> https://code.launchpad.net/~kamalmostafa/ubuntu/natty/alarm-clock-applet/lp704659/+merge/46705
<bdrung> tumbleweed: i finally reviewed syncpackage. here are the things i found: http://paste.debian.net/105100/
<tumbleweed> bdrung: line 3: What's the issue? debdiff? It returns 0 or 1 depending on whether there was a diff or not
<tumbleweed> bdrung: line 208-209: that's the only sane indentation, otherwise it's at the same level as the block inside the if
<bdrung> tumbleweed: line 3: you should use subprocess.call and evaluate the result instead of using check_call
<tumbleweed> bdrung: re url argument, I prefer it to be clear what the argument is, even if it isn't used
<bdrung> hm, ok
<tumbleweed> what's wrong with using check_call?
<tumbleweed> do we want to print an error instead of a stacktrace?
<bdrung> yes
<tumbleweed> fair enough
<Rcart> Hello. bittornado (bug #420387) seems to have dpatch system in debian/patches/,  but what-patch returns quilt system. How can i apply patches to this "thing" ?
<ubottu> Launchpad bug 420387 in bittornado (Ubuntu) "[PATCH] DeprecationWarning: the sha module is deprecated; use the hashlib module instead" [Undecided,New] https://launchpad.net/bugs/420387
<bdrung> the user should know what went wrong and how he may fix it instead of thinking "the program crashed -> bug"
<ebroder> Rcart: does it have a debian/patches/series file, or a debian/patches/00list file?
<tumbleweed> bdrung: agreed (that's why we have so many apport-filed requestsync bugs IIRC)
<Rcart> ebroder: series file.
<ebroder> Rcart: then it uses quilt. they probably switched from dpatch to quilt and were too lazy to rename files
<tumbleweed> bdrung: r893 pushed
<Rcart> ebroder: do i need to follow the enumerated sequence?
<ebroder> Rcart: i'm not sure i understand the question. debian/patches/series contains the order in which patches are applied. any ordering in the filenames is incidental
<bdrung> tumbleweed: indentation: http://pastebin.com/K8ktDeLE
<tumbleweed> bdrung: I don't like that, it's ambiguous with the block inside the if. I double-indent to avoid it if I can't naturally align it somewhere far away
<bdrung> tumbleweed: then do something like that: http://pastebin.com/VpiRcGNQ
<Rcart> broder: sorry, i meant if i should rename the new patch with the same sequence as they are in the debian/patches directory. i.e 09_timtuckerfixes.dpatch
<Rcart> *ebroder:
<ebroder> Rcart: i'd try to file whatever style was used for the other patches
<ebroder> *follow
<Rcart> ebroder: Great. Thanks a lot.
<tumbleweed> bdrung: done
<bdrung> tumbleweed: merged
<tumbleweed> bdrung: thanks
<tumbleweed> now I must finish that other branch...
<bdrung> tumbleweed: no
<tumbleweed> hmm?
<bdrung> tumbleweed: i have a solution that goes into a slightly different direction.
<bdrung> tumbleweed: it's ~ a year old and called release-info. i am going to include that script into u-d-t, which you can use in your branch then.
<bdrung> tumbleweed: i haven't decided yet if i rename release-info to distro-info or series-info.
<tumbleweed> bdrung: that sounds useful, thanks
<bdrung> tumbleweed: which name do you prefer?
<micahg> bdrung: did you find someone to rewrite in perl or is that still pending?
<tumbleweed> bdrung: depends on exactly what it does. I need something like "known-suites"
<bdrung> micahg: it's still pending.
<bdrung> tumbleweed: it does that: http://git.debian.org/?p=collab-maint/release-info.git;a=summary
<micahg> bdrung: ok, it's on my list at some point, don't know when though
<bdrung> micahg: once it's rewritten it perl and accepted in devscripts, only the data and the scripts will go, but the python object will stay.
<tumbleweed> bdrung: ok, I guess I'd better redo the rest of that builders branch without that bit then. This sounds like it'll take a while to be a usable option.
<bdrung> tumbleweed: take a while?
<tumbleweed> bdrung: port to perl, get into devscripts, get that devscripts into Ubuntu.
<tumbleweed> bdrung: also means we have a versioned depends on devscripts, which makes backporting harder
<bdrung> tumbleweed: that's the long term, but until then there will be a complete python solution in u-d-t (python object, data files, and scripts)
<tumbleweed> OTOH, the code is pretty simple, shouldn't be hard to port to perl
<tumbleweed> I'm tempted to say put the data files in /etc, then we don't need to backport u-d-t just to update release names, users can do that themselves
<bdrung> tumbleweed: no. either support two places (one system and one in /etc) or do SRUs for updates
<tumbleweed> two places works for me
<bdrung> tumbleweed: should i release the current version of u-d-t or wait for more changes?
<tumbleweed> might as well release the current version, I don't think anything is currently broken
<bdrung> tumbleweed: k, will do it tomorrow
<bdrung> tumbleweed: should we drop pbuilder-dist-simple?
#ubuntu-motu 2011-01-20
<tumbleweed> bdrung: I'm keen to, I don't see what it adds, and it saves me a bunch of work :)
<Laney> people probably use it
<bdrung> tumbleweed: may i ask you to send a mail to the mailing list and ask if someone wants to keep it?
<Laney> you should deprecate it for a release or so first I guess
<micahg> kamal: BTW, there should be a trash can on the top right of the merge proposal to delete it
<tumbleweed> is it compatible enough that we can ship a wrapper around pbuilder-dist that emits the deprecation warning?
<tumbleweed> that's probably more pain than it's worth, though
<kamal> micahg: yes, just a shame that deleting it also trashes the comments.  thanks.
<micahg> kamal: you should have copies in your e-mail ;)
<kamal> micahg: oh, no shortage of LP email in my box!  ;-)
<bdrung> kamal: there used to be "rejected"
<micahg> kamal: I actual filter based on type of LP e-mail, that might be helpful
<kamal> micahg: I do also
<kamal> bdrung: I'd like something like "abandoned"... anyway.    congrats on becoming DD!
<bdrung> kamal: thanks
<ari-tczew> bdrung: have you got time?
<bdrung> ari-tczew: no. it's bed time. http://paste.ubuntu.com/555614/ is a bug in python-debian. please file it and subscribe me.
<ari-tczew> bdrung: file against python-debian?
<bdrung> ari-tczew: yes
<bdrung> (otherwise there would be no need to subscribe me)
<ari-tczew> micahg: around?
<micahg> ari-tczew: yep
<ari-tczew> micahg: could you review again https://code.launchpad.net/~udienz/ubuntu/lucid/nginx/nginx.fix691871/+merge/44235 ?
<ari-tczew> he has uploaded new revision
<ari-tczew> however, on quick look I see issues
<ari-tczew> like debian-changes-xxxx
<micahg> ari-tczew: not in natty yet
<ari-tczew> micahg: where did he grab patches from?
<micahg> ari-tczew: they all have dep-3 headers
<micahg> except the last one
<micahg> ari-tczew: still no test cases either
<Rcart> Does it matters if i have a Name SecondName (nickname) <accout@isp.com>  in my pgp at uploading files to LP or Debian? It's wrong to include my nick?
<ari-tczew> Rcart: It's OK.
<Rcart> ari-tczew: Thanks (;
<ari-tczew> Rcart: You're welcome.
<Rcart> ari-tczew: debcommit Depends on cvs? When i run debcommit, returns this: Can't exec "cvs": Not exist such a file nor a dir at /usr/bin/debcommit line 722.
<ari-tczew> Rcart: debcommit is a part of binary package devscripts.
<ari-tczew> It doesn't depends on cvs.
<Rcart> ari-tczew: what could be wrong when i try to run it?
<ari-tczew> Rcart: did you try to install cvs then?
<Rcart> ari-tczew: this is really rare, i've installed cvs and after run debcommit and is asking for a login passoword to an unknow host: theshadow@cvs.degreez.net's password:
<Rcart> password*
<ari-tczew> Rcart: sorry, I'm not familiar with debcommit
<Rcart> ari-tczew: Thanks again. I'll google it a little more.
<achiang> Rcart: does your package use cvs?
<achiang> Rcart: looks like debcommit can speak to multiple SCMs, so i bet it found a .cvs in your working directory and is trying to do something with it
<Rcart> achiang: No, it uses bazaar
<jmarsden> Rcart: Are you 100% sure there is no .cvs directory being seen by debcommit?
<Rcart> jmarsden: look the ls -la output: http://pastebin.com/0Wepnxua
<Rcart> there's a CVS and a .bzr dir
<jmarsden> CVS will trigger it.
<jmarsden> You can see what it checks for in the getprog function within debcommit.
<jmarsden> remove the CVS directory and I think all will be well.
<Rcart> jmarsden: i'm looking in debcommit and firts checks for the CVS dir and then the .bzr  dir (among others)
<jmarsden> Right, so kill the CVS and it will see the .bzr and do what you want.  Right?
<jmarsden> Rcart: Or, if you prefer, swap the order of the tests around in debcommit so it picks .bzr even if CVS exists :)
<Rcart> jmarsden: Nice tip, but with the last, the package will be with the same problem at other times, right?
<jmarsden> Correct.  The real question is how or why a package would ever have both CVS and .bzr at the same time, it makes no sense to me.
<jmarsden> Maybe they used to use CVS, migrated to bzr and forgot to remove the old cvs-relatred dirs from their source tree?
<Rcart> surely, they also seems to forgot update the debian/patches dir after upgrading from dpatch to quilt
<Rcart> I've a lintian warning: out-of-date-standards-version 3.8.4 (current is 3.9.1). Should i update the Standards version field to the 3.9.1 ?
<paultag> Rcart: if your package is 3.9.1 standard, yeah :)
<paultag> Rcart: in most cases this is done without issue
<jmarsden> Rcart: Officially you need to read through the change list from the current debian-policy package back to 3.8.4 and ensure you don't need to update stuff to meet 3.9.1
<jmarsden> Rcart: See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz   # assuming you have debian-policy installed :)
<Rcart> Ok. I'll leave it in 3.8.4 and let someone else who has read the Debian Policy updates to change that field :)
<jmarsden> Rcart: http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt   # is may well be more current than the local one you have.
<paultag> Rcart: no, you should upgrade
<paultag> Rcart: but you need to be sure that you're 3.9.1. standard :)
<paultag> Rcart: there's no reason to keep it that old :)
<Rcart> Ok. Reading the debian policy updates :)
<Rcart> Looks like no changes for this package. The control file (most relevant) seems to fit the standards. I hope not to be wrong (:
<MTecknology> !info pbuilder-dist
<ubottu> Package pbuilder-dist does not exist in maverick
<MTecknology> !info ubuntu-dev-tools
<ubottu> ubuntu-dev-tools (source: ubuntu-dev-tools): useful tools for Ubuntu developers. In component universe, is optional. Version 0.104 (maverick), package size 140 kB, installed size 672 kB
<Rcart> good nights. Thanks for your helo (:
<Rcart> help*
<dholbach> good morning
<geser> good morning dholbach
<dholbach> hi geser
<mok0> Which of wget, curl is on a system by default?
<Bachstelze> mok0: wget
<mok0> Bachstelze: thanks
<mok0> I'd prefer curl, but then...
<ari-tczew> udienz: ping
<udienz> ari-tczew, pong
<ari-tczew> udienz: do you consider learn to merges?
<udienz> ari-tczew: yup
<ari-tczew> udienz: would be nice to sponsor some merges from you
<udienz> ari-tczew, Great! thanks i will looking for merging
<ari-tczew> udienz: I suggest to take trivial merges at the start, not important packages like bash.
<ari-tczew> udienz: I can give you some examples which are trivial merges if you want.
 * ari-tczew breakfast, brb.
<mok0> Hm, debian-policy manuals description of maintainer scripts is really hard to deconvolute
<mok0> I haven't written a maintainer script in a while, and it's pzzzzt gone from my brain :-(
<mok0> Ah, cool: http://people.debian.org/~srivasta/MaintainerScripts.html
<mok0> Just what I need. Thanks for letting me talk to myself :-)
<Laney> mok0: http://wiki.debian.org/MaintainerScripts is good
<mok0> Laney, indeed! Thanks
<soc1> does anyone know how to get in contact with the OpenJDK packagers? (no, #ubuntu-java doesn't work, it is basically empty)
<soc1> the packages there are uninstallable since months
<mok0> soc1: file a bug against it
<soc1> mok0: it seems that both "bugs" and "answers" are disabled on launchpad and are not used
<soc1> https://launchpad.net/~openjdk/+archive/ppa
<Laney> PPAs don't have bug tracking
<Laney> you need to contact the owner of the PPA
<soc1> i can't find any way to file a bug against the PPA or even the project
<Laney> don't know, but I'm afraid we can't help you with that here
<Laney> I suggest you contact the uploader privately
<mok0> soc1: use reportbug to report the bug to Debian
<Laney> why do you think it applies to Debian?
<paultag> yeah, it's a PPA soc1
<mok0> Ah
<paultag> soc1: that can't even build debian packages ( without retargeting it )
<mok0> soc1: try to ping doko, then, it seems he is the uploader
<mok0> Uh gotta go, bye
<soc1> ok, thnkas
<kklimonda> tumbleweed: do you think I can steal https://code.launchpad.net/~menesis/ubuntu/natty/hamster-applet/natty/+merge/45233?
<kklimonda> (steal from the person proposing a merge, not from you ;))
<kklimonda> oh, wait - menesis is here :)
<kklimonda> menesis: are you going to work on hamster-applet update for natty?
<menesis> kklimonda: hi :)
<kklimonda> hey :)
<menesis> you uploaded the last version, right?
<kklimonda> menesis: yes
<kklimonda> well, previous one - the last one was uploaded by Chris
<menesis> please, take it if you want
<menesis> I haven't merged Debian changes
<tumbleweed> kklimonda: glad someone's looking at it, it's been in the queue for way too long
<kklimonda> menesis: tumbleweed: ok, I'll take it then
<menesis> you will merge the debian changes?
<kklimonda> menesis: yes
<kklimonda> (I've also subscribed to hamster-applet bugs on Debian so I won't miss it anymore)
<menesis> good, then I leave it to you. thanks in advance
<aboudreault> hi, in a control file, how can I use inheritance for description field? to avoid duplicate text
<geser> it's not possible (at least not directly)
<aboudreault> well, lintian is talking about it in its report
<Legendario> does anyone have a clue on this error? http://ubuntu.pastebin.com/UMzwRXyx
<udienz> Legendario, you should put orig.tar.gz in ../
<Legendario> udienz, the upstream package is zip
<Legendario> udienz, i've created one. but i don't believe the problem is that. I'm still having an error
<udienz> Legendario, what the name of your orig.tar.gz?
<Legendario> udienz, sigil-0.3.2.orig.tar.gz
<tumbleweed> Legendario: change - to _
<udienz> Legendario, change it to sigil_0.3.2.orig.tar.gz
<Legendario> udienz, it seems to work... thanks :-)
<udienz> Legendario, and thanks to tumbleweed too :)
<JackyAlcine> Guys, how would I go about making a patch for Pidgin?
<JackyAlcine> I considered downloading the branch, but it has over 20,000 revisions.
<udienz> JackyAlcine, use this $ pull-lp-source pidgin
<kklimonda> JackyAlcine: lp:ubuntu/pidgin branch?
<JackyAlcine> Well, I already did "bzr branch lp:pidgin" and got the branch.
<JackyAlcine> But where would I upload my code?
<kklimonda> JackyAlcine: what are you trying to patch? pidgin or the package in ubuntu?
<JackyAlcine> Pidgin.
<JackyAlcine> Not the package.
<Laney> where can I get the source of the ubuntuwire rcbugs page?
<kklimonda> JackyAlcine: you should forward all patches to the pidgin developers then
<JackyAlcine> Hm. Alright, then.
<Laney> wgrant: ^^^^
<Laney> I could actually probably recreate it with UDD, thinking about it.
<geser> Laney: ajmitch should have the code
<Legendario> what about this one?
<Legendario> http://ubuntu.pastebin.com/A0PCQcdY
<Rcart> Hello. I'm working in this bug #420387
<ubottu> Launchpad bug 420387 in bittornado (Ubuntu) "[PATCH] DeprecationWarning: the sha module is deprecated; use the hashlib module instead" [Undecided,Confirmed] https://launchpad.net/bugs/420387
<Rcart> I've uploaded a branch with some fixes, in the my branch i've removed the CVS dectory that was refusing to use bzr to upload the changes (there was an CVS directoy, and a .bzr directoy)
<Rcart> So, scott's comment says that the CVS diresctory should stay in the branch. What do you think?
<Legendario> it's some problem with pbuilder-satisfydepends
<geser> Legendario: for which Ubuntu release is this pbuilder?
<geser> Legendario: do you have "universe" enabled in your pbuilder? libqt4-webkit is the only of your build-depends in universe
<geser> as libqt4-webkit is a transitional package you could also replace it with "libqtwebkit4 (>= 2.0~)" which is in main
<Kmos> Laney: check collab-qa for udd scripts, there is a rcbugs for debian -> ubuntu, it could be adapted easily.
<micahg> bdrung: ping
<Legendario> geser, it's for natty
<RainCT> bug #705526 o.O
<ubottu> Launchpad bug 705526 in gbrainy (Ubuntu) "No bug with the software. My language is more colourful, than you thought. The gbrainy's hungarian is kinda good, as my english... so... i have to re-learn my own language, if I'd like better results with this game. :)" [Undecided,New] https://launchpad.net/bugs/705526
<Legendario> geser, gonna try that
<iulian> RainCT: Haha.  Probably a bad translator?
<MTecknology> adding a -common package isn't very exciting
<iamfuzz> MTecknology, lol, indeed
<bcurtiswx_> what does "src/Makefile.am: object `empathy-accounts-dialog.$(OBJEXT)' created both with libtool and without" mean ?
<bcurtiswx_> is there an easy fix for it?
<MTecknology> iamfuzz: wanna test what I did and finish it off for me? :D
<vanguard> I build a source package, but after "debuild", I have a package that only contains the changelog and stuff, but not my actual .jar file. How do I add it?
<MTecknology> building, building, rebuilding, rebuilding, rebuilding, testing, building, rebuilding, retesting, oh what a day when you know not what you're doing.....
<vanguard> I built a source package, but after "debuild", I have a package that only contains the changelog and stuff, but not my actual .jar file. How do I add it?
<ari-tczew> vanguard: do you creating new package or working on existing package?
<vanguard> I am upstream, so I would like to create a new package
<vanguard> I created the debian dir with the dh tools, and wrote stuff into the files
<vanguard> I guess the problem is that the makefile generates the .jar into the ../ directory. But I do not really know how I will get it into the .deb
<nonix4> ari-tczew: yup, natty's w3m would be fine for me if getting that to Lucid & Maverick is feasible. The way bug 683337 is worded, it only asked for backport of that 020_button.patch though. (btw w3m 0.5.3 exists upstream as well)
<ubottu> Launchpad bug 683337 in w3m (Ubuntu Lucid) "Backport button element support to Lucid" [Wishlist,In progress] https://launchpad.net/bugs/683337
<vanguard> ari-tczew: are you still there?
<ari-tczew> vanguard: yes I am here. I'm not familiar with java packages, sorry.
<directhex> vanguard, try a debian/install file, which is of the format "thing/to/install      /destination/on/disk"
<vanguard> with a \t in between?
<directhex> yeah. but that's hard to add in an irc client.
<vanguard> directhex: boom, now it is not liek 10K but 164K, sounds good.
<directhex> vanguard, check contents with "dpkg -c". check dependencies with "dpkg -I"
<vanguard> directhex: I wrote that I want to install my .jar file to /pu.jar, but in the dpkg -c it is listed as "./pu.jar/" --- normal?
<directhex> vanguard, yes, but most people don't want jar files in /, they want them in... i dunno, is it /usr/lib/java?
<directhex> /usr/share/java
<vanguard> so maybe /usr/share/java/myGameName/game.jar ?
<directhex> you'd need to ask the debian java folks. i honestly don't know
<paultag> vanguard: there's a whole policy manual on java files
<paultag> vanguard: do you need this?
<directhex> i mean, there are a few existing java games, so check those? freecol for example
<paultag> it has all the standards and such
<paultag> it's in the DDP IIRC
<vanguard> paultag: If you have it at hand, I would happily read it
<paultag> vanguard: moment
<paultag> vanguard: http://wiki.debian.org/Java/Packaging
<paultag> vanguard: ah, here's the best copy -- http://www.debian.org/doc/packaging-manuals/java-policy/
<MTecknology> zul: howdy
<paultag> vanguard: see 2.2, and Debian Policy 9.1
<vanguard> paultag: I'll check it out
<paultag> vanguard: good luck!
<MTecknology> paultag: time to help me now that you're done helping him :D
<paultag> MTecknology: howdy, friend
<MTecknology> paultag: howdy, how ya been?
<paultag> MTecknology: well, thanks for asking
<paultag> MTecknology: and youself?
<paultag> yourself, shucks. Can't type today. Long morning
<paultag> Oh jeez, it's 2:30 PM
<MTecknology> i'm doing well except for the lack of job and ruptured disk
<paultag> ouch, and oucher
<Legendario> I need a help on this: the package doesn't use the usual, .configure, make, makeinstall. Instead it brings an installer. how should i set the cdbs for that?
<MTecknology> trying to get an nginx-common package
<paultag> Legendario: is it nonfree?
<paultag> MTecknology: I don't know much about multi-binary. Ask me in a few days, I need to split up a package of mine in Debian into a few parts. Someone else might be able to help you better then me
<paultag> MTecknology: unless it's theory. I understand that OK
<Legendario> paultag, no... it's gpl3. but the source code comes with a installer script
<paultag> Legendario: does it support DESTDIR or some other way of having it barf files in a directory other then /, without prefixing scripts and such with the fullpath?
<Legendario> paultag, I'm just starting to deal with cdbs documentation... kind os lost
<paultag> Legendario: forget about CDBS for now ;)
<vanguard> Legendario: welcome in the club :D
<paultag> Legendario: can you use something like DESTDIR?
<paultag> Legendario: if you can, you can do it, if you can't you will have to patch it, most likely.
<vanguard> I got a question about lintian: What does debhelper-but-no-misc-depends mean?
<paultag> vanguard: use the -I flag
<paultag> vanguard: it means you forgot a bit in your control file
<paultag> vanguard: you should try using lintian with -IiE --pedantic, that's how I use it :)
<vanguard> I read that lintian is mean, but that it even complains about the vim .swp files ... wow :D
<paultag> vanguard: those are extra space and junk :)
<paultag> vanguard: you don't need them, they're bad to have, they just waste space
<paultag> :)
<vanguard> paultag: I realize that, I just a vim window open editing the copyright file since it was bitching about that as well :D
<paultag> hahaha, yeah
<paultag> I've done that before
<vanguard> and I set the install path to /opt to be out of the way of everyone, but that does not seem to be okay. But /opt is for stuff that does not come in a package like UrbanTerror or Maple, right?
<paultag> vanguard: opt is not the right place :)
<vanguard> paultag: what is the right place for opt?
<paultag> vanguard: it's OK when you're installing by hand, from someone
<vanguard> okay, then it is clear
<paultag> vanguard: optional software under certen conditions and blah blah.
<paultag> vanguard: it's in the FHS, there's a format too, /opt/company/project or something like that
<paultag> it's also a pain to set up a way to put it in your path, because you have to go into /opt/*/*/bin/*
<paultag> unless you similink
<MTecknology> paultag: I split nginx into nginx-{full,light,extras} and now I need to move a lot of that stuff into nginx-common to fix some of the issues that came up from the split. :(
<paultag> MTecknology: sweet :)
<MTecknology> paultag: ya, but fixing the bugs and getting the nginx-common is a pain in the butt
<paultag> vanguard: and since debs are getting installed by superuser by the software vender of the OS, I think they have to be installed into a "bigboy" place, so not /usr/local or anything like that
<paultag> MTecknology: yeah for sure
<paultag> but I'm not sure about that, I could be wrong
<MTecknology> bigboy place?
<paultag> Heck, I'm not even MOTU.
<paultag> MTecknology: /usr/bin and not /usr/local/bin
<vanguard> paultag: I think that I should put my .jar into /usr/share/java/ and put a simple shellscript into /usr/bin?
<paultag> MTecknology: local is for locally compiled or created software IIRC
<paultag> vanguard: that sounds much more sane
<paultag> vanguard: :)
<vanguard> paultag: let me check out what lintian says about that. It is like an epic battle with a dragon or so :D
<MTecknology> paultag: it's the term that made me laught
<MTecknology> laugh*
<paultag> vanguard: FTI -- http://www.pathname.com/fhs/2.2/fhs-3.12.html
<paultag> MTecknology: hahaha, glad to get a chortle :)
<paultag> vanguard: for sure :)
<MTecknology> paultag: oh.. when i automated server setups.. part of the script did rmdir /usr/local/sbin && bzr branch [...] /usr/local/sbin
<paultag> MTecknology: wait, what?!
<paultag> MTecknology: why? That's really not smart
<MTecknology> why's that?
<paultag> MTecknology: 1) if they're similinks, you've missed the reason to have sbin. If they're binaries, you're a) storing a binary in VCS, so wasting space, and b) klobbering the package manager
<paultag> If they're binaries was 2)
<paultag> MTecknology: is if a package changes it's .so set, you can have another abi
<MTecknology> they were scripts
<paultag> MTecknology: ... so?!
<paultag> MTecknology: just make a meta-package
<paultag> MTecknology: there's no reason to use bzr for that
<MTecknology> they were frequently changing; mostly just backup scripts and maintenance junk
<MTecknology> I'm sure I could have picked a better directory; but the point was that it was /usr/local/
<paultag> MTecknology: still dude, metapackages at the least
<paultag> MTecknology: it hurts my soul
<MTecknology> metapackage for scripts?
<MTecknology> for very frequently changing scripts*
<paultag> MTecknology: package up the scripts, and make a mtecknology-server metapackage or something
<paultag> MTecknology: yes, just publish to a local repo
<paultag> MTecknology: then you can just update && upgrade the boxes
<paultag> MTecknology: it's wicked easy to make them native, even
<paultag> </rant>
<MTecknology> :P
<paultag> BBL, heading home :)
<vanguard> lintians says debhelper-but-no-misc-depends
<vanguard> but debuild tells me dpkg-source: Warnung: kann AbhÃ¤ngigkeit ${misc:Depends} nicht auswerten (cannot compile)
<vanguard> what do I do now?
<vanguard> at least the fatal error is at line 1337 ...
<MTecknology> vanguard: GR!
<vanguard> I don't understand
<MTecknology> vanguard: sorry, not sure why I added your nick there, was supposed to be just an expression of irritation to the channel
<MTecknology> I want to install a man page.. nginx.1; I want it to be part of the nginx-common package only; how do I make that happen?
<vanguard> launchpad has accepted my tinkered package
 * vanguard treats himself with a yogurth now :D
<wgrant> Start the DAy
<wgrant> Gah.
<ari-tczew> wgrant: hello wgrant. Did you adjust UDD FTBFS script?
<wgrant> ari-tczew: I don't touch UDD.
<ari-tczew> wgrant: why? last time when I asked you, you said that it's possible
<wgrant> ari-tczew: What's the URL?
<ari-tczew> wgrant: of FTBFS script?
<vanguard> how do I add an icon to a package?
<wgrant> I run several FTBFS scripts.
<ari-tczew> wgrant: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
<ari-tczew> vanguard: check for source any package, e.g. gwget
<wgrant> ari-tczew: That's probably run by lucas.
<vanguard> ari-tczew: right, I have to learn what OSS really means ... :D
<ari-tczew> wgrant: yes, but sometimes. I guess you have access to server, where you could that script often.
<wgrant> No, that's a Debian server. I'm not a DD.
<ari-tczew> wgrant: are you Canonical employee?
<wgrant> ari-tczew: Yes.
<soren> wgrant: orly? Since when?
<wgrant> soren: Mid-December.
<soren> wgrant: Cool. Congrats!
<maco> 'grats
<wgrant> Thanks!
<wgrant> Currently in Dallas at the LP sprint.
<geser> ah, that explains your unusual time when you're on IRC
<StevenK> geser: This is wgrant. More unusual, since unusual times on IRC is usual for him.
<wgrant> That may change with the reorg, though, given that my team is now western US.
<geser> but you still live in Australia or did you move?
<wgrant> Still in .au.
<ari-tczew> nonix4: w3m from natty builds cleanly on maverick. on lucid doesn't, unfortunately.
<scott-work> i've been told qdvdauthor was removed from the repository for natty, does anyone know why?
<micahg> scott-work: obsolete is the reason given: https://launchpad.net/ubuntu/+source/qdvdauthor/+changelog
<scott-work> hmmm, curious...thanks micahg
<ari-tczew> DktrKranz: shall we remove root-system from Ubuntu, as well?
<DktrKranz> ari-tczew: it will be anyway as soon as archive-admins schedule removals from Debian, unless there's a valid reason to keep it around. I don't know what the package is about to judge, though. I just performed actual removal.
<DktrKranz> but I'd say go for its removal
<ari-tczew> DktrKranz: OK thank you for feedback.   ; ))
<DktrKranz> np :)
#ubuntu-motu 2011-01-21
<Legendario> any hint here: http://ubuntu.pastebin.com/EJ3dPfKT ?????????
<stevecrozz> micahg: have you had a chance to look at http://revu.ubuntuwire.com/p/uwsgi again?
<micahg> stevecrozz: you still need to run update-maintainer, but I'd like to chat with the ITP person a little more
<stevecrozz> micahg: i did run update-maintainer, does still look like I haven't?
<micahg> stevecrozz: ah, maybe w/out an internet connection?
<micahg> oh, hmm
<stevecrozz> hm, i don't think so... is something wrong with it?
<micahg> nm, it's because it's not in the archive yet
<stevecrozz> micahg: I'll let leonid know you want to talk with him, maybe i can get him to pop in here again
<micahg> stevecrozz: he's got almost everything
<stevecrozz> micahg: is there anything I can do to help?
<micahg> I just don't see the need for dynamic build-deps
<stevecrozz> i have no strong feelings on that, i guess we'll see if leo can convince you
<stevecrozz> hey micahg: leo just arrived, he's onehundredthirty
<micahg> hi again onehundredthirty
<onehundredthirty> hi
<micahg> I saw your modifications, why the need for build-deps being variable?
 * micahg sees no evidence in control.in
<onehundredthirty> yes, I didn't put it into control.in. but could you please try to clone repository and build it? it will fail because of Build-Depends
<micahg> onehundredthirty: sure, but do you know what needs to be changed?
<ebroder> onehundredthirty: by the way, i was wrong yesterday when i said that other packages didn't support multiple interpreters. libapache2-mod-wsgi actually builds both a py2.6 and py2.7 module in the same package
<pabelanger> So, if I had a Ubuntu package, could I recompile it twice? Once for <package> and another time for <package-dbg>?   There are some specific compile time flags I would need to set for a -dbg version of the package
<onehundredthirty> ebroder: yes, i see it. yesterday I talk with member of Debian Python Modules Team on #debian-python and he pointed out this package. it was after I posted comment on REVU. and now I think to change the uWSGI package in something like mod_wsgi
<ebroder> onehundredthirty: excellent. sounds much better than a bunch of dynamically generated packages
<pabelanger> sorry, wrong channel
<onehundredthirty> micahg: d/rules looks into d/control and invokes different Python interpreter for different uwsgi-python* packages. and some of these Python interpreters aren't in Build-Depends
<micahg> onehundredthirty: python-all-dev doesn't pull them in?
<onehundredthirty> micahg: yeah. the same thought comes into my mind now. python-all-dev it really must pull all Python interprestes in. well, maybe my comment on REVU was wrong. but before posting it i tried to build 'control.in' branch on Maverick and it fails on wrong Build-Depends
<ebroder> onehundredthirty: you should be able to build-dep on python-all-dev, then use pyversions to figure out what to build against
<onehundredthirty> ebroder: yeah, I saw pyversions usage in mod_wsgi package. I'll use it too.
<ebroder> onehundredthirty: awesome. sounds like you have things under control
<onehundredthirty> ebroder: but there is one disadvantage in packing all pythonX.Y-related executables in package uwsgi-pythonX. Package will contain executables linked to different libpythonX.Y, but the package will Depends only on one libpython
<onehundredthirty> ebroder: when user will  try to invoke executable with missing libpython, it wil fails
<ebroder> onehundredthirty: that's not true. you should have a ${shlibs:Depends} in your depends: line, and call dh_shlibdeps in your rules file (or if you're using the %: dh $@ rules file, it'll do it for you)
<ebroder> dh_shlibdeps finds all of the executables and makes sure the libraries they link are substituted for ${shlibs:Depends}
<onehundredthirty> ebroder: but then my package will pull-in ALL python interpreters. say, I 'apt-get uwsgi-python2' and it pulls in python2.6 and python2.7. is it good idea? mod_wsgi didn't so this
<ebroder> onehundredthirty: they don't pull in python2.6 and python2.7, just libpython2.6 and libpython2.7
<ebroder> and yes, mod_wsgi does do this
<ebroder> in fact, it would be a bug in your package if you did *not* depend on the libraries needed to link the executables in the package
<onehundredthirty> ebroder: libpythonX.Y Depends on pythonX.Y
<ebroder> huh. so they do. hadn't noticed that
<ebroder> in any case, yes, that's what mod_wsgi does as well
<onehundredthirty> and mod_wsgi Depends on (only python-related): libpython2.6 (>= 2.6), python (>= 2.5), python (<< 2.7)
<ebroder> onehundredthirty: you're looking at maverick, not natty
<onehundredthirty> ebroder: no I'm looking at Debian Unstable :)
<ebroder> onehundredthirty: unstable doesn't even have py2.7 yet, does it?
<onehundredthirty> yeah, but nevertheless, mod_wsgi doesn't depends on all libpython
<ebroder> it does in natty
<onehundredthirty> ebroder: just on libpython for default Python
<onehundredthirty> ebroder: I see. it really depends on all available libpython in natty. well,
<ebroder> that's odd that it doesn't in sid, though, and seems like a bug
<ebroder> or possibly a change in how linking in an interpreter works between py2.5 and py2.6?
<ebroder> the mod-wsgi in experimental depends libpython2.6 and libpython2.7 but not libpython2.5
<ebroder> i guess that's probably because there is no libpython2.5
<onehundredthirty> ebroder: I see. yes there is definitely no libpython2.5, so this is the reason.
<onehundredthirty> so, I will try to change my package to something like mod_wsgi with uwsgi-python2 and uwsgi-python3.
<micahg>  \o/
<micahg> thanks onehundredthirty
<onehundredthirty> guess, it takes away need for separate packages for Debian and Ubuntu
<onehundredthirty> will see
<micahg> onehundredthirty: if you run into issues, please come back, we'll be glad to help
<onehundredthirty> micahg: thanks, I'll do
<slangasek> who manages revu these days?  I've tried to use it for the first time today, and it seems to think I'm not a MOTU?
<slangasek> ah, wiki says contact an admin to be marked as a reviewer
<slangasek> persia: can I be a REVUer?
<persia> Absolutely.  Please log into REVU to make sure your account is initialised so I can grant you rights.
<persia> Basic guidelines: be picky, so save the archive-admins work, be helpful, so folks can get it right.  Everyone appreciates a licensing review.
<persia> OK.  All set.  Please review.  Be sure to advocate that which warrants it.  Best to get two pairs of eyes on things: everyone makes mistakes.
<persia> Oh, and REVU doesn't run lintian against binaries: if you want those results, run a test-build.
<dholbach> good morning
<ari-tczew> mr_pouit: I guess you might be interested in bug 705734
<ubottu> Launchpad bug 705734 in xubuntu-docs (Ubuntu) "Xubuntu-docs for lucid are out-dated" [Undecided,New] https://launchpad.net/bugs/705734
<ari-tczew> micahg: ping
<pabelanger> Daviey: ping?
<micahg> ari-tczew: [ong
<ari-tczew> micahg: do you running natty?
<micahg> ari-tczew: not yet
<Daviey> pabelanger, o/
<ari-tczew> micahg: :( I have a problem with java on natty and I'd like to get in touch with someone who has a knowledge.
<micahg> ari-tczew: have you tried #ubuntu+1?
<ari-tczew> micahg: perhaps in the past, but no response
<micahg> ari-tczew: do you want to talk about it in there?
<micahg> bdrung: ping
<ari-tczew> micahg: place doesn't matter, I just would like to fix problem
<bdrung> micahg: pong
<micahg> bdrung: so, I missed the e-mail about upstream vlc EOLing the 1.0 branch, doesn't this cause an issue for us with Security support for Lucid?
<bdrung> micahg: probably no, because backporting the fixes from the 1.1 branch used to be easy.
<micahg> bdrung: ok, so we should let this go?
<micahg> I guess 1.1 will stay around for a while for squeeze?
<bdrung> micahg: upstream will EOLing 1.1 probably before squeeze EOL
<dholbach> jdong, is the backporters team still looking for help?
<dholbach> ScottK too: ^
<ScottK> dholbach: Yes.
<dholbach> ScottK, I was reaching out to some new contributors and asked about their experience - there was one who put a lot of work into backporting applications. Would it be OK if I passed him on to the team mailing list?
<ScottK> dholbach: We don't have a team mailing list.
<dholbach> oh, I thought that was what ubuntu-backports@lists.u.c was for?
<ScottK> It may be.  I'm not subscribed to it though.
<dholbach> aha
<dholbach> ok
<ScottK> I'll clarify and say we aren't using a mailing lists.
<ScottK> dholbach: You can suggest he give me a ping on irc or email me.
<dholbach> sweet, thanks a lot Scott!
<Legendario> does anyone know the answer for this error: http://ubuntu.pastebin.com/EJ3dPfKT
<tumbleweed> Legendario: you mustn't install to /usr/bin, the package build happens as non-root (fakeroot) and the install should happen into debian/$packagename. You can achieve this via DESTDIR
<pabelanger> Daviey: howdy! Figured I'd try and ping you about getting more active with the Asterisk packaging.
<pmjdebruijn> hi I'm trying to package a cmake project with debhelper 7
<pmjdebruijn> except that it has no CMakeList in it's package root, but only in one of the subdirectories
<pmjdebruijn> how can I point debhelper to that subdirectory
<tumbleweed> pmjdebruijn: see --sourcedirectory in debhelper(7)
<pmjdebruijn> ok thanks
<tumbleweed> you might need --buildsystem too (without the CMakeList it won't autodetect cmake{
<pmjdebruijn> but to which db_audo ?
<pmjdebruijn> I've only override configure thus far
<tumbleweed> to all of them. DH_OPTIONS can make that easier
<tumbleweed> well, to all of the dh_auto_*
 * Laney thought it was to 'dh'
<Laney> dh $@ --buildsystem=blah --sourcedirectory=bleh
<jpds> dh, duh.
<tumbleweed> Laney: yes, but if he's overridding some of them
<Laney> hmm?
<tumbleweed> or does it pass it through? I've always passed it to dh and dh_auto_x
<Laney> it does
<Laney> see man dh
<pmjdebruijn> Laney: that seems to work
<pmjdebruijn> thanks
<Laney> :)
<tumbleweed> Laney: aah, it exports DH_INTERNAL_OPTIONS. Nice to know
<Laney> I think that using DH_OPTIONS can be problematic in compat 8 mode
<pmjdebruijn> tumbleweed: see, now we've both learned something
 * pmjdebruijn giggles
<tumbleweed> Laney: yes I can see that would be an issue
<tumbleweed> pmjdebruijn: that's one of the reasons this is fun :)
<bdrung> tumbleweed: hi, do you have time to review release-info?
<tumbleweed> bdrung: sure, I'll look in 10 mins
<bdrung> tumbleweed: pushed
<hakermania> Hello guys
<pmjdebruijn> Laney, tumbleweed thank again!
<micahg> err, I how do I build a native package from bzr?
<tumbleweed> micahg: easiest way is to tell bzr-builddeb that it's native. echo -e '[BUILDDEB]\nnative = True' > .bzr-builddeb/default.conf
<micahg> no go
<micahg> still trying to run get-orig-source
<tumbleweed> micahg: add that file and commit it first
<micahg> ah
<micahg> tumbleweed: works, thanks
<bdrung> tumbleweed: pushed.
<bdrung> r962
<tumbleweed> bdrung: thanks, just busy reading it
<bdrung> tumbleweed: bug #706010
<ubottu> Launchpad bug 706010 in ubuntu-dev-tools (Ubuntu) "[backportpackage] upload fails" [Undecided,New] https://launchpad.net/bugs/706010
<bdrung> tumbleweed: i'll be away for some hours. cul8r
<c2tarun> besides bug triaging and fixing how else can we contribute to ubuntu development?
<Daviey> pabelanger, still around?
<tumbleweed> c2tarun: what do you have in mind? there are a lot of bugs to fix... Areas: FTBFSs, important fixes to sync/merge from debian, security issues, upstream develompent of packages, etc.
<c2tarun> tumbleweed: actually I was wondering that by learning packaging how can i contribute?
<tumbleweed> understanding packaging is important to solving many bugs
<tumbleweed> and obviously rather necessary for packaging up new software
<c2tarun> tumbleweed: solving bugs often requires good programming skills. I am not familiar with GTK programming, so most of the time I m not able to fix bugs.
<tumbleweed> c2tarun: I'm not very familiar with GTK either (haven't written any in years). Most of the bugs I deal with day to day are either packaging issues, build failures, or simple bugs that I can fix without knowing too much about the codebase I'm fixing.
<tumbleweed> c2tarun: harvest.ubuntu.com has a good set of things to look at
<c2tarun> tumbleweed: Can you please give me example of any packaging issue? I really want to understand how everything works.
<tumbleweed> c2tarun: follow the natty-changes list, see what people are doing. In natty we've had some big toolchain changes that make many packages fail to build, the fixes generally involve explicitly linking to libraries.
<c2tarun> tumbleweed: sorry to say :( but I didn't understand most of what you said. I think I'll go through various source codes and do the fixing :)
<c2tarun> tumbleweed: gotta go. Thanks for you help :)
<pabelanger> Daviey: Yup
<matttbe> Hello,
<matttbe> I'm looking for a sponsoring about this bug: https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/704032
<ubottu> Ubuntu bug 704032 in cairo-dock-plug-ins (Ubuntu) "Please update cairo-dock-plug-ins and cairo-dock metapackage to depend on libwebkitgtk-1.0-0" [Undecided,Fix committed]
<matttbe> I've proposed my branch for merging into lp:ubuntu/cairo-dock-plug-ins => https://code.launchpad.net/~cairo-dock-team/cairo-dock-plug-ins/ubuntu/+merge/46668
<matttbe> And the (short) debdiff is available there: http://launchpadlibrarian.net/62602053/cairo-dock-plug-ins_2.2.0~4-0ubuntu4.debdiff
<matttbe> Currently, cairo-dock won't start on Natty. It's due to libwebkit, just need to be recompiled with libwebkitgtk.
<matttbe> Anyone can help me? :)
<tumbleweed> matttbe: about to go to bed, so can't help you, but don't mark a bug as committed if you want anyone to look at it.
<matttbe> tumbleweed: ok thank you
<matttbe> tumbleweed: but which status?
<tumbleweed> triaged is probably best
<happyaron> anyone knows about CMake?
<matttbe> tumbleweed: thank you
<matttbe> tumbleweed: (except that I can't change this status :) )
<matttbe> (to this status)
<tumbleweed> matttbe: that merge is massive for just a rebuild
<matttbe> tumbleweed: yes, it seems there was a problem with the branch
<tumbleweed> ok, I recommend you delete the merge proposal then
<matttbe> ok
<matttbe> about the bug with the branch https://bugs.launchpad.net/udd/+bug/704694
<ubottu> Ubuntu bug 704694 in Ubuntu Distributed Development "import has failed with cairo-dock-plug-ins" [High,Confirmed]
<tumbleweed> unfortunatly there are a few of those...
<tumbleweed> matttbe: ok, a quick rebuild I can help with
<matttbe> tumbleweed: thank you for your help ;)
<tumbleweed> matttbe: editing your changelog entry to "Build-Depend on libwebkitgtk-dev instead of libwebkit-dev (LP: #704032)"
<matttbe> tumbleweed: thank you :)
<matttbe> tumbleweed: just another question: why can't the cairo-dock team change the importance of all bugs from "cairo-dock (Ubuntu)" and "cairo-dock-plug-ins (Ubuntu)" projects?
<tumbleweed> matttbe: only ubuntu bugcontrol members can, distribution wide
<matttbe> how ok :)
<matttbe> -how
<tumbleweed> matttbe: https://wiki.ubuntu.com/UbuntuBugControl
<pabelanger> So, I'm trying to setup schroot, following: https://help.ubuntu.com/community/SbuildLVMHowto
<pabelanger> $ mk-sbuild --vg=storagevg lucid ; fails because I don't have a LVM called storagevg
<pabelanger> if I use my local LVM, I get back the following error:
<pabelanger>   Insufficient free extents (4) in volume group astpkglucid64: 1280 required
<pabelanger> I don't understand what a extents is
<ebroder> pabelanger: that means you don't have any unallocated space in the volume group
<ebroder> it's all allocated to logical volumes
<ebroder> it may be easier to use the aufs support - don't pass --vg, just do "mk-sbuild lucid"
<ebroder> it'll create the chroot in /var/lib/schroot/chroots
<pabelanger> ebroder: Okay, that looks better
<pabelanger> Thanks, let me read up on the differences between LVM and aufs
<matttbe> tumbleweed: thank you for your help! ;)
#ubuntu-motu 2011-01-22
<pabelanger> Anybody have a good example of how to setup and configure wanna-build?  I'd like to try my hand a creating a local build farm
<ebroder> pabelanger: i think that knowledge is largely contained in the heads of the debian buildd maintainers
<ebroder> at least, that was the conclusion i came to the last time i looked at wanna-build
<pabelanger> ebroder: Ya, documentation looks to be limited. Thanks
<bdrung> tumbleweed: pushed
<bdrung> tumbleweed: remaining: http://paste.debian.net/105349/
<bdrung> tumbleweed: 1) which SEE ALSOs do you want?
<bdrung> tumbleweed: 2) i don't get what you want to tell me.
<bdrung> tumbleweed: 3) only perl and shell scripts should be left (or are the remaining python scripts?).
<pabelanger> ebroder: Ya, wanna-build seems to be pretty specific to Debian. May just skip using it
<Rcart> Hello. If i want to send a patch to debian, i just need to include the debian/newpatch.patch content in the submittodebian utility?
<tumbleweed> bdrung: err, whoops re len(). 1) I think all the distro-info commands should SEE ALSO each other. 2) I don't like code paths that use exception handling for normal operation.
<tumbleweed> bdrung: 2a) the perl and bash scripts still hardcode release names
<bdrung> tumbleweed: 2) ok, how should i do the conversion then?
<tumbleweed> parts = x.split('-'); if len(parts) == 2: ...
<bdrung> tumbleweed: pushed fix for 1) and 2)
<bdrung> tumbleweed: feel free to convert the remaining  perl and bash scripts
<evaluate> dapal, ping?
<m4n1sh> have a question
<m4n1sh> for changelog line
<m4n1sh> zeitgeist (0.7-0ubuntu1~0ppa1~maverick) maverick; urgency=low
<m4n1sh> what should be the name of the orig file?
<m4n1sh> zeitgeist_0.7-0ubuntu1~0ppa1~maverick.orig.tar.gz ?
<geser> zeitgeist_0.7.orig.tar.gz
<geser> the part after the - is the package revision
<m4n1sh> geser: thanks a lot :0
<m4n1sh> :)
<bdrung> tumbleweed: when do you update your builder branch?
<bdrung> tumbleweed: i would like to review your branch, merge it, and release u-d-t
<tumbleweed> bdrung: next couple of days, I guess, although testing builders tends to be quite a bit of work
<bdrung> tumbleweed: or should i just release the current state?
<tumbleweed> one sec, let me push something
<bdrung> tumbleweed: that was not an answer to my question. ;)
<tumbleweed> well, that was preliminary, partly-unrelated work
<tumbleweed> I can probably also deal with the remaining hardcoded distros quite quickly (I have existing, outdated patches), which does leave as at a good point for a release
<bdrung> tumbleweed: Logger.error("Error: You don't own $HOME") -> error twice
<tumbleweed> thanks
<bdrung> tumbleweed: then let's fix the hardcoded distros and release u-d-t
<tumbleweed> bdrung: pull-debian-source is just begging to be re-done in python now that we have existing library functions for most of it
<ari-tczew> bdrung: what is the libkivi used for?
<tumbleweed> bdrung: so, shall we make pbuilder-dist-simple say it's deprecated?
<bdrung> tumbleweed: yes
<ScottK> tumbleweed: Why would we do that?
<tumbleweed> ScottK: why do we need to maintain it and pbuilder-dist?
<bdrung> ScottK: does pbuilder-dist-simple has any gain over pbuilder-dist?
<ScottK> tumbleweed: It's simple.  pbuilder-dist has been broken in the archive more than once.
<ScottK> It shouldn't need a lot of maintenance.
<ScottK> bdrung: It's simple.  That's it's entire point.  pbuilder-dist is very complex.
<bdrung> ScottK: but it does.
<tumbleweed> ScottK: ok, but then it stays as simple as it is, and it doesn't get support for Debian (there's an open bug either requesting that, or removal of the statement that it does support debian)
<ScottK> tumbleweed: I'd be fine with removing the statement that it does.
<ScottK> It staying simple is pretty much it's entire point.
<tumbleweed> ScottK: seems fair, I've just never personally felt the need fo rit
<bdrung> ari-tczew: for formatting sizes in bytes for displaying. e.g. 1234567 bytes -> "1.23 MB"
<ari-tczew> bdrung: aha ok
<bdrung> tumbleweed: which scripts needs the *distro-info update?
<tumbleweed> bdrung: according to my previous branch: dch-repeat, pull-debian-source, reverse-build-depends
<bdrung> tumbleweed: ETA?
<tumbleweed> bdrung: this evening, I'll have a shot at it now.
<ari-tczew> how can I fix this FTBFS? http://paste.ubuntu.com/556891/
<Bachstelze> ari-tczew: same old thing, thel* flags must be at the end of the command
<Bachstelze> they're probably added to LDFLAGS instead of LIBS
<Bachstelze> the -l* flags*
<Bachstelze> hmm
<Bachstelze> they are at the end actually
<Bachstelze> but the -L* and -I* must be at the beginning
<Bachstelze> line 12
<geser> the -lXext must be at the end as -lnvcontrol needs it
<ari-tczew> geser: I added -lXext at the end of LIBS at the same result. :(
<geser> the same amount of errors or less?
<ari-tczew> geser: Yes.
<ari-tczew> Package has got this patch before: http://pastebin.com/Adx4Pj7e
<ari-tczew> many hacks with CFLAGS
<Bachstelze> ari-tczew: the patch is wrong, see line 248 for example
<Bachstelze> -L* flags belong in LDFLAGS, not LIBS
<Bachstelze> LIBS is for -l* flags
<ari-tczew> Bachstelze: where do you see changed LDFLAGS in this patch?
<ari-tczew> to be clear: this is not my patch. it's in Debian.
<Bachstelze> yes, I know
<Bachstelze> and yes, it doesn't change LDFLAGS, that's the point
<Bachstelze> it should, -L* flags go in LDFLAGS, not LIBS
<Bachstelze> it puts them in LIBS
<ari-tczew> Bachstelze: now you're wrong
<ari-tczew> we change LIBS to fix FTBFS with bintuils
<ari-tczew> binutils *
<udienz> ari-tczew, or LDADD
<udienz> avoid to use *FLAGS
<ari-tczew> udienz: it seems nvclock doesn't have LDADD
<tumbleweed> bdrung: took the easy approach in pull-debian-source, see pull-debian-source-py branch. (supper, brb)
<udienz> ari-tczew, hm.. if not having LD/LIBADD usually adding in LIBS
<ari-tczew> udienz: the bug is this big patch in Debian
<ari-tczew> I sent an e-mail to author about fixing.
<ari-tczew> udienz: btw. how about firestarter debdiff?
<bdrung> tumbleweed: the copyright line is missing in the python script
<udienz> ari-tczew, hehe, i still works in firestarter. i'm waiting until my emails back
<bdrung> tumbleweed: i recommend to change from optparse import OptionParser -> import optparse
<udienz> ari-tczew, doko fixing nvclock yet. he adding X11 in LIB
<ari-tczew> udienz: you should improve your english
<ari-tczew> you're still working on firestarter
<udienz> hehe
<ari-tczew> and doko fixED ftbfs on nvclock
<ari-tczew> yes, he fixed by adding X11 to LIBS, but in our package
<ari-tczew> I'm merging nvclock with Debian unstable
<ari-tczew> there are big changes
<ari-tczew> so his patch is useless on Debian
<udienz> ari-tczew, yes i see doko patch di BTS. he send at Jan 11th
<ari-tczew> udienz: I have to repeat: his patch is useless
<bdrung> tumbleweed: 3) are the downloaded files verified?
<udienz> ari-tczew, maybe one or two days again i will send firestarted debdiff. my hdd is full :(
<tumbleweed> bdrung: pull() does that for us
<bdrung> tumbleweed: good. only these two points and then you can push it into trunk
<tumbleweed> bdrung: landed
<bdrung> tumbleweed: remaining: dch-repeat and reverse-build-depends
<tumbleweed> yup
<bdrung> tumbleweed: can i release now or is there still something in the pipe?
<tumbleweed> bdrung: that's all I've got
<tumbleweed> bdrung: so go ahead :)
<bdrung> tumbleweed: uploaded
<tumbleweed> bdrung: now we wait for bug reports :)
<bdrung> :)
<bdrung> tumbleweed: i am fast. :P bug #706403
<ubottu> Launchpad bug 706403 in ubuntu-dev-tools (Ubuntu) "[syncpackage] AssertionError in src_pkg.pull_dsc()" [Undecided,New] https://launchpad.net/bugs/706403
<ari-tczew> mr_pouit: ping
<ari-tczew> if any core-dev has a time, would be nice to review bug 701182 and bug 701182
<ubottu> Launchpad bug 701182 in nut (Ubuntu) "Merge nut 2.4.3-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/701182
<ari-tczew> err, second bug 695005
<ubottu> Launchpad bug 695005 in python-numpy (Ubuntu) "Merge python-numpy 1.5.1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/695005
<ari-tczew> slangasek: around?
#ubuntu-motu 2011-01-23
<ari-tczew> micahg: do you will upload barry's patch?
<AnAnt> Hello, can someone help me with this FTBFS: http://launchpadlibrarian.net/62644475/buildlog_ubuntu-natty-powerpc.verilator_3.810-1_FAILEDTOBUILD.txt.gz
<AnAnt> I am getting the same FTBFS on Debian sparc
<micahg> AnAnt: just looks like it's trying to remove a file that's not there
<AnAnt> micahg: ?!
<AnAnt> micahg: what file ?
<micahg> it's trying to remove a .exe file for some reason
<AnAnt> micahg: that happens on all archs, but does not cause the FTBFS
<AnAnt> https://buildd.debian.org/fetch.cgi?pkg=verilator;ver=3.810-1;arch=powerpc;stamp=1295690749
<AnAnt> personally I was suspecting something like toolchain difference
<micahg> oh sorry, didn't see the next break
<micahg> %Error: ../test_v/top.v:8: syntax error, unexpected $undefined
<AnAnt> yup
<micahg> it looks like the build hung
<AnAnt> yes, this build error does hang the build if I was on an interactive shell
<AnAnt> this "%Error: ../test_v/top.v:8: syntax error, unexpected $undefined" does not happen on other archs
<AnAnt> upstream doesn't have a clue either
<AnAnt> when I compared build logs on Debian, I noticed that successful builds used gcc 4.4.5, while sparc (the failing build) used gcc 4.4.4
<micahg> AnAnt: well, we're on gcc 4.5.2 I think in natty
<AnAnt> yup
<AnAnt> and its building well with other archs on natty
<micahg> yeah, but each arch has its quirks, you can try asking doko
<AnAnt> hmmm, different binutils revision
<micahg> ah
<AnAnt> but I would suspect that this would be the reason
<AnAnt> cdbs: new nickname ?
<cdbs> AnAnt: yep, since 2 months I guess
<nonix4> perl -pi -e 's/mantainance/maintenance/' jetring-0.*/debian/control # typos in first line of description are annoying, anybody want to fix that? :)
<debfx> nonix4: please file a bug against the debian package :)
<nonix4> debfx: for minor typo fix, maintonly@bugs.debian.org would be right place?
<debfx> nonix4: I would just send it to submit@b.d.o with severity minor but maintonly seems appropriate as well
<m4n1sh> Hi, for the changelog line -  zeitgeist-sharp (0.1.1.0~m4n1sh1~natty) natty; urgency=low
<m4n1sh> and tarball name
<m4n1sh> zeitgeist-sharp_0.1.1.0.orig.tar.gz
<m4n1sh> I am getting this error
<m4n1sh> dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
<m4n1sh> what is wrong in it?
<ari-tczew> almaisan-away: ping
<directhex> m4n1sh, missing debian revision
<ari-tczew> m4n1sh: filename is wrong
<directhex> m4n1sh, 0.1.1.0-1 is the base, not 0.1.1.0
<m4n1sh> directhex: debian revision is needed? I thought not
<directhex> m4n1sh, you need a - in there, the bit before the - is the orig version
<ari-tczew> directhex: this is a new package
<m4n1sh> zeitgeist-sharp (0.1.1.0-1~m4n1sh1~natty) natty; urgency=low
<m4n1sh> this is fine?
<ari-tczew> no
<directhex> m4n1sh, yes.
<ari-tczew> m4n1sh: 0.1.1.0-0ubuntu1
<ari-tczew> directhex: ?
<micahg> ari-tczew: +1
<micahg> it's not in Debian, so a fake Debian revision shouldn't be added
<directhex> micahg, well, it's in NEW
<micahg> directhex: oh, ok, well in that case :), if it's a backport of that version it's fine
<m4n1sh> thanks everyone
<ari-tczew> folks, conclusion: REVU or Debian?
<micahg> ari-tczew: for?
<directhex> debian. always.
<ari-tczew> micahg: where m4n1sh is working for? new package for REVU or Debian?
<directhex> ari-tczew, for his ppa. the packackage is already in debian NEW
<ari-tczew> m4n1sh: aha, add natty1 rather for PPA
<ari-tczew> then you can add more revisions natty2, natty3 etc
<m4n1sh> ari-tczew: I was putting it in debian because dnielsen (banshee contributer) asked for natty package
<m4n1sh> ari-tczew: means 0.1.1.0-0ubuntu1~natty1
<ari-tczew> m4n1sh: for PPA looks fine
<micahg> m4n1sh: you can use -1 if it's a straight backport of the Debian package
<m4n1sh> micahg: means 0.1.1.0-1ubuntu1~natty1 instead 0.1.1.0-0ubuntu1~natty1
<directhex> i wouldn't until it clears NEW, personally
<ari-tczew> m4n1sh: what's the version in debian NEW?
<ari-tczew> show us
<m4n1sh> ari-tczew: directhex knows it better
<micahg> m4n1sh: hmm, ok, well, go with 0.1.1.0-0ubuntu1~natty1~ppa1 that way there's no chance of conflicting with an official backport
<m4n1sh> thanks
<ari-tczew> +1 ^^
<micahg> directhex: you're right again :)
<directhex> yeah, i guess micahg has good advice there
<directhex> it is possible for -1 to get rejected, in which case there's confusion over what the "real" -1 is
<directhex> so 0ubuntu1 which is identical to -1 in new is a reasonable assumption. so go with micahg's suggestion
 * ari-tczew has lunch
<ari-tczew> almaisan-away: we need your help in  bug 675622. see comment 5
<ubottu> Launchpad bug 675622 in glew (Ubuntu) "Merge glew 1.5.7-1 (main) from Debian experimental (main)" [Undecided,Incomplete] https://launchpad.net/bugs/675622
<ari-tczew> nonix4: I can give +1 for backport w3m to maverick.
<ari-tczew> nonix4: lucid needs changes in d/control
<nonix4> ari-tczew: 'k. Regarding my patch, Tatsuya just confirmed that it looks correct.
<ari-tczew> nonix4: there were opinions that patch works as new feature, no bugfix. what do you think?
<nonix4> From viewpoint of w3m package, it indeed seems like a new feature, but for launchpad-foundations/canonical-identity-provider it is a bugfix imho.
<micahg> nonix4: I would suggest -backports + an FAQ then
<nonix4> (then again the rest of 0.5.2-2.1...0.5.2-10 difference is even more features)
<micahg> right, but in -backports, that's fine :)
<nonix4> tbh -backports is quite unknown to majority of normal users, so that FAQ would need careful choice of words. I'd rather prefer that in a default server installation, ubuntu-bug "just works" once normal upgrades have been installed.
<ari-tczew> +1 ^^
<ari-tczew> siretart: ping
<micahg> nonix4: you could e-mail the tech board and ask for an exception
<ari-tczew> waking up all developers for one button sounds like hardcore
<micahg> ari-tczew: tech board isn't that many people
<nonix4> 6 active members?
<micahg> nonix4: right, you can send a request to the ML
<ari-tczew> micahg: but it shows our bureaucracy
<ari-tczew> we are not in the department
<micahg> ari-tczew: we have procedures to keep stability in the Stable Releases
<ari-tczew> micahg: "procedures"
<ari-tczew> repeating bureaucracy
<micahg> ari-tczew: we have more relaxed rules than Debian
<nonix4> well, to be able to handle high volume of patches, some form of bureaucracy/hierarchy seems to be more or less necessary, however itchy it feels :-/
<micahg> also, this is an exception
<ari-tczew> micahg: please consider whether you are too inflexible, bureaucratic, official
<siretart> ari-tczew: hi
<ari-tczew> siretart: hello. have you got time to have a look for 2 packages?
<siretart> ari-tczew: unclear, which ones?
<micahg> ari-tczew: it falls outside the guidelines of a stable release update, so the options are -backports or TB exception, I didn't create the rules
<nonix4> TB?
<micahg> tech board
<ari-tczew> siretart: want to sync libgcrypt11 and libgpg-error from experimental. only remaining changes are dirs - files *.install, *links
<ari-tczew> siretart: one request is filed, bug 702765
<ubottu> Launchpad bug 702765 in libgcrypt11 (Ubuntu) "Please sync libgcrypt11 1.4.6-4 (main) from Debian experimental (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/702765
<ari-tczew> siretart: I'd like to get your feedback whether these changes are necessary or not.
<ari-tczew> micahg: but you are keeping bureaucratic which is not good.
<micahg> ari-tczew: It's *our* responsibility as uploaders to follow the guidelines that are in place, if you think something should be changed, you should propose it (not sure about the correct forum probably -devel ML)
 * ari-tczew must go out.
<nonix4> ari-tczew: btw I could do some proofreading of your QuickResponse writing some day, think I spotted some minor grammar issues there.
<siretart> ari-tczew: okay, please hilight me with the other request as well, I'll do it when I find some more time
<ari-tczew> nonix4: OK, I'm open for feedbacks.
<paultag> Does anyone know how I can bump bug #703718 ?
<ubottu> Launchpad bug 703718 in fluxconf (Ubuntu) "Requesting removal of source package `fluxconf' from Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/703718
<micahg> paultag: you just have to wait for the archive admins to process
<paultag> micahg: great. thanks!
<ari-tczew> siretart: what do you think, is might be able for Ubuntu? http://paste.ubuntu.com/557346/
<siretart> ari-tczew: what's the intention behind this change?
<ari-tczew> siretart: the diff which I sent above is a Debian change.
<siretart> ari-tczew: AFAIUI, debian is moving the libs from /usr to /, which we in ubuntu do for quite some time now
<siretart> ari-tczew: ah, I see. Well, compare the file installation lists of the binary packages. what file locations did change?
<siretart> if none, then everything is great :-)
<ari-tczew> siretart: our delta: http://paste.ubuntu.com/557348/
<siretart> ari-tczew: why do we still need the delta?
<ari-tczew> siretart: we don't need delta. :-)
<ari-tczew> siretart: I'm just making sure that we can drop delta. I noticed that you've some uploads related to /lib dir.
<siretart> okay. - let me try it the other way: try building the unmodified source from debian in ubuntu. then compare the output of 'dpkg-deb -c $deb' from the new package with the existing packages
<siretart> if all files end up in the same locations, then let's get rid of our local changes
<siretart> if there are differences, then we need to review the changes
<siretart> we need to look at the results here, I think
<ari-tczew> siretart: let me build it - I'm on it!
<micahg> ari-tczew: that change doesn't make sense, a -dev package shouldn't be putting anything in /lib
<micahg> FYI, there was a whole discussion on debian-devel about this
<ari-tczew> micahg: what do you think, the package from experimental is better?
<siretart> micahg: there is, but we really had enough trouble with the divergence here. I'd prefer if we could finally get these two packages in sync again
<micahg> siretart: indeed
<micahg> I was just noting that the diff seems unnecessary for practical reasons
<ari-tczew> micahg: +1 ^^
<ari-tczew> siretart: odd error: my natty can't find binary libgpg-error0-udeb
<siretart> uh?
<ari-tczew> siretart: ok I know what is wrong. Section: debian-installer
<ari-tczew> me sends thanks to yofel
<ari-tczew> siretart: OK, compared. natty: http://paste.ubuntu.com/557392/     experimental: http://paste.ubuntu.com/557394/
<ari-tczew> micahg: maybe you're interested ^^
<micahg> yeah, I think that's better
<micahg> but you should just verify with someone who uses the package, just because it fits the standards better, doesn't mean it won't break stuff :)
<ari-tczew> micahg: but this is library, hard to find who uses it
<micahg> ari-tczew: well, I meant, who "maintains" something that uses it, that or test build something that depends on the -dev package with it
<ari-tczew> micahg: hmm, then I have to use PPA
<ari-tczew> micahg: build test is enough?
<micahg> ari-tczew: idk, I'm not a core-dev :), seems like StevenK did most of that work originally, maybe he has an opinion on the issue
<siretart> ari-tczew: it's a bit hard to compare, but it looks great to me so far!
<bdrung> micahg: you forgot to subscribe ubuntu-archive to bug #701536
<ubottu> Launchpad bug 701536 in python-mpd (Ubuntu) "Please sync python-mpd 0.3.0-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/701536
<micahg> bdrung: sorry, I thought I got better at that :-/
<ari-tczew> bdrung: in future you should use in d/changelog "Sync on Debian" instead "Merge from Debian experimental, no remaining change."
<ari-tczew> if no remaining changes, it can't be merge :)
<bdrung> ari-tczew: i can do with my package what i want :P
<ari-tczew> bdrung: :>
<bdrung> ari-tczew: merge from debian, drop all changes, and add new ones.
<ari-tczew> bdrung: I took this method from tumbleweed
<bdrung> ari-tczew: i kept ubuntu's changelog entry, otherwise it would be a sync.
<siretart> yay, my build recipe for ffmpeg/trunk packages finally works! https://code.launchpad.net/~motumedia/+recipe/ffmpeg-daily
<ari-tczew> congratz siretart :)
<siretart> so I can finally start testing upgrades by throwing natty sourcepackages at that ppa
<siretart> but that's for later this week. good night!
<bdrung> siretart: do you know wrap-and-sort?
<siretart> bdrung: no, what's that?
<bdrung> siretart: it sorts and wraps build-depends and co.
<bdrung> siretart: wrap-and-sort; $vcs diff
 * bdrung should blog about it.
<siretart> sounds interesting, I'm looking forward to that blogpost
<bdrung> siretart: you forgot to add an epoch to the daily build!
<bdrung> siretart: recommendation: 0.7~~{revno}+{time} -> 4:0.7~daily~{revno}+{time}
<ari-tczew> micahg, siretart: gnupg2 built fine on my PPA with libgcrypt11 and libgpg-error from experimental.
<micahg> ari-tczew: great
#ubuntu-motu 2012-01-16
<udienz> Hi, anybody can see bug 915257? i can't reproduce in my pbuilder/sbuild/ppa
<ubottu> Launchpad bug 915257 in nginx (Ubuntu) "FTBFS nginx 1.1.12-1 in ubuntu precise except amd64" [High,New] https://launchpad.net/bugs/915257
<geser> udienz: did you have pkg-create-dbgsym installed in your pbuilder when you tried to reproduce it?
<udienz> geser: no, it's clean
<udienz> then we must add BD to pkg-create-dbgsym?
<geser> pkg-create-dbgsym (and pkgbinarymangler) is installed on the buildds by default
<geser> so if you want to reproduce certain build failures, it's good to them installed in pbuilder too
<dholbach> good morning
<geser> good morning dholbach
<dholbach> hey geser
<scott-work> does anyone have information about REVU possibly being down?
<scott-work> i've tried to log in for two days and can't get the website
<Laney> looks so, indeed
<Laney> wgrant: ^^^^?
<OwaisL> Guys, it seems revu is down.
<OwaisL> I'm aware of the plans to move away from revu. So how does one get a package into universe without going the debian way?
<tumbleweed> REVU is just a tool for reviewing packages. It's not a submission system
<tumbleweed> use mentors.debian.net instead?
<OwaisL> tubleweed, thanks but the package is ubuntu specific.
<OwaisL> depends on unity
<OwaisL> is unity package in debian?
<Zhenech> no
<OwaisL> s/package/packaged
<tumbleweed> OwaisL: you can use mentors.debian.net without intending to upload to debian
<OwaisL> tumbleweed, ah ok. I'll check it out.
<OwaisL> Uploaded my package to mentos.debian.net; Anyone interested please have a look http://mentors.debian.net/package/gmailwatcher
<OwaisL> Earlier it was http://revu.ubuntuwire.com/p/gmailwatcher but revu has been down for quite a while and don't know if someone is working on it anymore.
<OwaisL> tumbleweed, thanks!
<Adri2000> anyone has thought about syncing opencv 2.3 into precise?
<Corey> I have a dsc file generated via debuild -S; I'm trying to build it in pbuilder in a sid chroot, but I'm seeing lookup failures from ftp.debian.org/debian when it tries to grab deps, such as Err http://ftp.debian.org/debian/ sid/main python2.7 amd64 2.7.2-9; 404's out.
<jtaylor> Corey: is the chroot up to date?
<Corey> jtaylor: Hmm.  Is there a sane way to update it?  I build it a couple weeks back.
<jtaylor> python2.7 is version -11ubuntu1
<Corey> built*
<jtaylor> pbuilder --update
<Corey> That would do it; thanks jtaylor
<tumbleweed> there is also an example hook script shipped with pbuilder that'll do an update before building
<tumbleweed> (but that update is thrown away, you still want to pbuilder --update regularly)
<Corey> I assume that update when invoked via --update unpacks the tarball, updates it, repacks it?
<tumbleweed> yes
<Corey> At what point does it make sense to rebuild the chroot from scratch?
<jtaylor> rare, should only be necessary when some upgrade breaks it for some reason
<jtaylor> I think I only ever had to rebuild experimental chroots
<jtaylor> (as long as you don't work with --save-after-login of course)
<tumbleweed> the most common reason to rebuild is that there's a package in it that wouldn't have been installed if it was freshly built
<Corey> Build failure. :-(  Now I get to figure out what I broke.
<jtaylor> fun :)
<Corey> Not really. :-)  The code is solid, so it's a packaging error of some sort.
<Corey> cp: cannot stat `debian/tmp/conf/minion': No such file or directory
<Corey> dh_install: cp -a debian/tmp/conf/minion debian/salt-common//etc/salt/minion/ returned exit code 1
<Corey> So I think it's a pathing issue; there's definitely a minion file.
<Corey> And the line in the .install file is conf/minion /etc/salt/minion
<jtaylor> how does the .install look like?
<Corey> Which is a static, non-compiled file.  $packageroot/conf/minion is the file
<broder> what is debian/compat?
<Corey> 7
<Corey> (Forgive the paste there, I figured 1 character would be okay...)
<broder> dh_install looks in debian/tmp/foo if foo doesn't exist, so it's not finding foo for some reason
<broder> maybe set "export DH_VERBOSE=1" in the rules file and try again?
<Corey> Okay.
<jtaylor> or execute dh_install -v after the failure
<Corey> I have to rerun debuild -S first, don't I...
<jtaylor> yes
<jtaylor> there is a hook in pbuilder to drop you in a shell after the failure
<Corey> That'd probably be easier, what's the hook?
<jtaylor>  /usr/share/doc/pbuilder/examples/C10shell
<Corey> http://pastebin.com/DxXmuqzM is the output after that verbosity flag was enabled.
<Corey> I snipped the first part of it grabbing deps and whatnot.
<Corey> If you wonder what's in the debian directory, https://github.com/saltstack/salt/tree/develop/debian
<broder> hmm. it's possible that dh_install decides whether to look at the project root or debian/tmp for all files, as opposed to deciding for each file
<broder> so you could try changing the usr/share/blah paths to debian/tmp/usr/share/blah (which is where make install will install them to with the default multi-package config)
<Corey> broder: Doing it now.
<jtaylor> Isee no conf/minion in that source
<jtaylor> Corey: ^
<jtaylor> only a conf/minion.template
<Corey> jtaylor: ...you're kidding me.
<Corey> They changed it on me.
<jtaylor> probably as you are using git snapshot instead of the ready tarball that has the conf/minion
<jtaylor> its not unsual that git trees and release tarballs differ in some autogenerated stuff
<Corey> Yeah, I should probably do this with the tarball.
<jtaylor> classic case are autotools stuff
<Corey> Should I revert the changes to pathing I just made?
<jtaylor> yes, I don't think dh_install does what broder though
<jtaylor> also usually the destination has no leading /
<Corey> Rebuilding.
<Corey> I do appreciate how pbuilder caches packages it needs.
<jtaylor> I recommend using a cacher like apt-cacher-ng
<jtaylor> makes sharing package caches much easier
<jtaylor> also you should use eatmydata to speed up installation
<jtaylor> or place everything on a ramdisk
<Corey> h_install: salt-minion missing files (modules/*), aborting <-- Progress!
<Corey> Pathing issue, whee.
<Corey> Holy crap, successful build.  Thanks, jtaylor / broder.  Now to figure out what else I've pooched.
<Corey> Yay, a pile of things to fix from lintian!
<Corey> When do I use architecture all vs any?
<jtaylor> any if it architecture dependent and compiles everywhere, all if independent
<jtaylor> e.g. python, documentation = arch all
<jtaylor> compiled code any
<jtaylor> *C compiled, java mono are also all
<Corey> jtaylor: One package (multiple packages, for a client/server package) requires compilation that's arch dependant, the rest do not.
<jtaylor> then you have some any and some all packages
<Corey> Right, which causes lintian to moan
<jtaylor> what error?
<Corey> E: salt source: magic-arch-in-arch-list
<jtaylor> whats your control?
<Corey> https://github.com/saltstack/salt/tree/develop/debian <-- jtaylor
<jtaylor> shared libraries in a -common package?
<jtaylor> thats "unusual"
<jtaylor> = wrong
<jtaylor> hm its if their private
<Corey> jtaylor: Yeah, we inherited some strangeness. I'm quite open to feedback on this. :-)
<Corey> This is my first Debian/Ubuntu package.
<Corey> I want to get it "right" because once that's done I really don't have to play with it anymore. :-)
<Corey> Hmm. Will I break anything horrible if I throw the lintian version for Precise into Lucid?
<jtaylor> no idea, but there is a hook to run lintian after a pbuilder build
<jtaylor> which can be precise
<Corey> Yeah, I'm running a version that's 3.9.1, it whines that it's not 3.9.2
<Corey> jtaylor: So what was the verdict on my common package, is that done improperly?
<jtaylor> I'd ahve to see a fully built package for that
<Corey> jtaylor: Okay, we'll proceed for now. :-)
<jtaylor> you should not build depend on libzmq1
<jtaylor> you are probably missing shlib:Deps for the any package
<jtaylor> you seldom can rely on python:Depends getting everything right, that needs manual checking
<jtaylor> also use dh_python2 (dh $@ --with python2)
<jtaylor> if you are not packaging for lucid
<jtaylor> also stick with what you have
<jtaylor> *else
<Corey> jtaylor: I don't quite understand.  There's a dependency for the python zeroMQ library, not sure how else to reference that.
<jtaylor> libzmq-dev takes care of that
<Corey> And this is ideally going to be tossed to a number of different releases; personally I do need it on Lucid. :-)  The PPA that'll contain this for dev purposes will contain the deps.
<jtaylor> -dev packages always depend on the newest binary package
<Corey> Ahhh.
<Corey> Fixed.
<Corey> jtaylor: So I should copy the python-deps by hand into each sub-package?
<jtaylor> the actual library package dependency is determined automatically by dh_shlibdeps and put into shlibs:Depends
<jtaylor> probably
<jtaylor> check what dependencies your packages have after build
<jtaylor> make installation and run tests in a clean chroot
<Corey> jtaylor: Technically don't I just need to declare them for the common package, since the rest depend on that?
<jtaylor> if that is the case yes
<Corey> A bunch of stuff to fix in the man pages, which I can punt on for a bit.
<Corey> Bah: E: salt-minion: python-script-but-no-python-dep ./usr/share/salt/salt-call/salt-call
<Corey> The python dep is inherited from the common package.
<jtaylor> it should be salt-common (= ${binary:Version})
<Corey> salt-common already grabs                python (>= 2.6),
<Corey> And ${python:Depends},
<jtaylor> you still need that
<jtaylor> unless you can guarantee that it will work with other -common versions
<Corey> jtaylor: You mean throw the line (= ${binary:Version}) in there explicitly?
<jtaylor> salt-common (= ${binary:Version})
<jtaylor> in depends
<Corey> jtaylor: This is new now that that's been applied; E: salt source: not-binnmuable-all-depends-any salt-minion -> salt-common
<jtaylor> do what it suggests or override it
<jtaylor> binNMU's are only important for offical debian packages
<Corey> jtaylor: Yeah, it will be at some point, but not today. :-)
<Corey> E: salt-minion: python-script-but-no-python-dep ./usr/share/salt/salt-call/salt-call is still annoying, given that I've updated the control file: https://github.com/KB1JWQ/salt/tree/master/debian
<jtaylor> just add a python depends to silence it then
<Corey> jtaylor: Worked, thanks.
<Corey> jtaylor: Do I want to set architecture to any, or architecture to all?  It's getting upset at the blend.
<jtaylor> depends whats in it
<Corey> jtaylor: The client needs to build a module for msgpack that's architecture dependant; the rest is python and doesn't care.
<Corey> But it's that blend that's annoying lintian, I suspect.
<jtaylor> sry I have to leave
#ubuntu-motu 2012-01-17
<Corey> No worries, thanks for your help.
<Corey> http://pastebin.com/fua09b5C is my lintian output so far.  Whee, progress.
<ScottK> tumbleweed: On these DMB replacement announcements it'd be nice to know if the incumbent is running for re-election.
<dholbach> good morning
<geser> ScottK: no, I'm not (for re-election)
<geser> ajmitch: Hi, are you still available for getting nominated for DMB?
<iulian> Morning dholbach.
<dholbach> hey iulian
<iulian> geser: I reckon he is, otherwise we'd be very disappointed. :)
<iulian> Go go ajmitch!
<nigelb> heh
 * nigelb cheers for ajmitch as well!
<ajmitch> geser: yeah I may as well :P
<Laney> gogo ajmitch
<Laney> what's this "*still* available"? â¦
<geser> ajmitch mentioned in the past that he would be available for election, and I hoped he didn't changed his mind
<Laney> I'm sure I trolled him about this before :P
<ajmitch> Laney: yeah but you troll about everything
<Laney> you love it
<Laney> it's Our Thing
<ScottK> geser: Thanks.
<astraljava> Hiya masters! Heard REVU is still down. Can someone look at it, or has someone already?
<scott-work> is REVU supposed to still be up and used?
<Laney> probably, but it is down
* Laney changed the topic of #ubuntu-motu to: REVU is down | Precise: open for business | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://bit.ly/fz6AyQ | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/
<scott-work> Laney: is there any recourse if i wanted to get a kernel (per an approved blueprint) into the archives?
<Laney> are you working with the kernel team?
<Laney> they use git afaik
<Laney> otherwise you could use mentors.debian.net or make a bzr branch
<scott-work> Laney: per the blueprint we were supposed to submit to REVU and have two MOTU approve it (themuso being one of them)
<scott-work> my understanding is that since this would be a community maintained kernel, the kernel team would not have direct purview over it
<Laney> I don't know what it is, but they might be interested in working with you anyway
<Laney> anyway one of the other places I mentioned should be fine
<scott-work> thanks for you help, Laney  :)
<koolhead17> hello all
<koolhead17> Is it common practise to  package a software in n-number available language separately?
<koolhead17> how is patch applied to all of them in that case?
<l3on> udienz, about bug 913513 ... well, debian has added:
<ubottu> Launchpad bug 913513 in libomxil-bellagio (Ubuntu) "Please merge libomxil-bellagio 0.9.3-1 (universe) from Debian testing" [Undecided,Incomplete] https://launchpad.net/bugs/913513
<l3on> CFLAGS="${CFLAGS} -Wall -Werror -Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter"
<l3on> as a workaround of problem
<l3on> we should delete that and insert the patch you mentioned ?
<micahg> if the patch properly fixes the issues, you might want to ask the Debian maintainer why it wasn't applied (this might be documented in a bug already)
<l3on> cjwatson, around ? you're the author of the patch :)
<l3on> have you forwarded that to debian ?
<udienz> l3on: i think we can use cjwatson patch, you can take liberty to forwarding to Debian
<udienz> don't forget to CC cjwatson in bug reports
<l3on> udienz, ok, I'm going to prepare the new debdiff
<micahg> l3on: you can reference debian 625367 in your bug
<ubottu> Debian bug 625367 in libomxil-bellagio "libomxil-bellagio: ftbfs with gcc-4.6 -Werror" [Serious,Fixed] http://bugs.debian.org/625367
<l3on> thank you micahg
<udienz> you can reopen it http://www.debian.org/Bugs/server-control
<micahg> yes, but it's technically fixed, so best to open a new bug
<cjwatson> l3on: I don't remember, sorry.  But you really shouldn't need to ask me about every instance where you find a build-fixing patch of mine in a package; if it's a build fix, use your judgement to determine whether it's still needed
<cjwatson> and if it is and I forgot to forward it then feel free to just go ahead and forward it
<Corey> Hmm.  I've been playing around with my pbuilder sid chroot, and I'm getting http://pastebin.com/sHc8p54f.  What've I broken now? :-)
<Corey> Put another way, I've got compiled python modules (cython) that are arch specific; do they belong in dist-packages?
<jtaylor> yes
<jtaylor> but not in usr/local
<Corey> jtaylor: Ah, so I want to stash it in /usr/lib/python2.6/dist-packages instead.  I presume there's a way to inform setup.py of this fact? :_)
<jtaylor> dh_auto_build usually does it correctly
<jtaylor> if not it probably did not find your setu.py
<Corey> jtaylor: You'd think: https://github.com/KB1JWQ/salt/blob/master/debian/rules
<Corey> setup.py is in the top level dir.
<jtaylor> well thats wrong
<jtaylor> drop the overrides
<jtaylor> for _build and _install
<Corey> jtaylor: Without them setup.py never gets called.
<jtaylor> hm is there a makefile too?
<Corey> No.
<jtaylor> try this: dh $@ --buildsystem=python_distutils
<Corey> jtaylor: That github fork is "life"
<Corey> Live, even.
<Corey> jtaylor: Huh, build completed successfully.
<Corey> jtaylor: But I'm still not seeing the build having compiled the stuff that setup.py build compiles.
<Corey> And nothing's getting stashed anywhere but in /usr/share
<jtaylor> whats the setup.py line shown when you build with DH_VERBOSE=1
<Corey> jtaylor: Throw DH_VERBOSE=1 into rules?
<jtaylor> export in front
<Corey> jtaylor: The install is 	python setup.py install --force --root=/tmp/buildd/salt-0.9.5/debian/tmp --no-compile -O0 --install-layout=deb
<jtaylor> do you copy the stuff from debian/tmp in an install file?`
<Corey> jtaylor: Nope.
<Corey> That... would probably explain it, wouldn't it...
<jtaylor> than thats the reason the result is empty
<Corey> This package will work with python 2.6 or 2.7; how do I reflect that in the .install file?
<jtaylor> if you build depend on python-all-dev
<jtaylor> usr/lib/python2*
<Corey> jtaylor: And I only want to include the compiled stuff?
<jtaylor> then make that more specific
<Corey> I'm asking, the rest is just copied in.
<Corey> So that stuff is already being copied in from the source itself to /usr/share, I don't need to redo that I figure.
<Corey> But for the msgpack stuff, I'd want to have the install line look like: debian/tmp/usr/lib/python2.7/dist-packages/salt/msgpack /usr/share/python2*/dist-packages/salt/msgpack ?
<jtaylor> some stuff is handled by default, e.g. copyright
<jtaylor> everything else you have to do explicitly
<jtaylor> usr/lib/python2*/dist-packages/salt/msgpack is enough
<jtaylor> for compat >= 7
<Corey> jtaylor: Right, but I've explicitly had it done from the topdir-- it's static python files.
<Corey> jtaylor: Ah, and that'll know where to find it?
<Corey> See, what I've been doing is this: in the tarball, there's a salt directory, so I have lines like salt/utils /usr/share/salt/
<jtaylor> compat >= 7 will fall back to debian/tmp if not found
<jtaylor> sry you do need a destination too
<jtaylor> hm no, if the path in debian/tmp isok you can skip it
<Corey> Yeah, it seems to have worked.
<Corey> Ooh.
<Corey> I threw the python-dev-all into the control file, now it looks like I'm building the socket a few times.  I have a /usr/lib/pyshared/python2.7/salt/msgpack/_msgpack.so and a ./usr/lib/pyshared/python2.6/salt/msgpack/_msgpack.so as well.
<jtaylor> you can use wildcards
<Corey> I just want to verify that installing the package isn't going to deb both versions of python. :-)
<Corey> dep*
<Corey> I'm seeing a few python-script-but-no-python-dep errors, my control file looks like https://github.com/KB1JWQ/salt/blob/master/debian/control; what did I blow up in my deps?
<Corey> ^ crossposted from #debian-packaging on OFTC, in case it looks familiar.
<Corey> Ahhh!
<Corey> Found it.  Stupid nagging bug.
<Corey> TO fix it, I have to have my packaging process patch the original source code; how do I do that properly?
<Corey> I mean worst case I can have a DH_build that does it with sed, but that's inelegant.
<jcfp> Corey: use a patch system, like quilt or dpatch.
<jcfp> also, python-support is deprecated these days, see http://lists.debian.org/debian-python/2011/06/msg00136.html for info.
<micahg> dpatch is deprecated these days as well :)
<jtaylor> but you need to use it if you want to support lucid
<jcfp> oh damn :)
<Corey> Yeah, Lucid is required.
<Corey> Will DHPython2 work with Lucid?
<jcfp> doesn't look like it's available there
<Corey> Okay, then as nice as it would be to use the latest shiny, that's not an option for me.
<jcfp> just dodn expect you to be targeting lucid, since you were using a sid chroot
<Corey> jcfp: I'm trying to target everything reasonable in production.
<Corey> This'll be submitted to Ubuntu, Debian, it'll go into an autobuilder for nightlies, etc.
<maxb> jtaylor: why do you say that you need to use dpatch to support lucid? why not use quilt?
<jtaylor> maxb: I never said that
<jtaylor> oh, you could interpret it that way
<jtaylor> I responded to dh_python2
<jtaylor> 3.0 is fine in lucid
<maxb> oh right, you were talking about python-support
<Corey> Okay, https://github.com/KB1JWQ/salt/blob/master/debian/control still throws a number of python-script-but-no-python-dep, even after I stripped out the version qualifier for Python.  How do I sanely fix this?
#ubuntu-motu 2012-01-18
<bkerensa> bilal: are you about?
<psusi> RAOF, you know lots about X et all right?  how about glib and main loops?  I'm trying to figure out whether emitting signals goes through the main loop and whether a background thread can emit a signal and have the main thread actually process it and invoke the callback?
<RAOF> What do you mean by "signal" in this case?
<RAOF> A gobject signal?
<psusi> RAOF, a glib signal? yea
<RAOF> IIRC, signal dispatch is handled in the calling thread.
<psusi> hrm... darn... I was reading something that made it sound like it got queued and processed in the main loop
<RAOF> If you want that to occur on the main thread, I believe the idiom is to g_timeout_add() a callback which raises the signal.
<psusi> but I couldn't see how emit figures out what maincontext to queue it to
<psusi> or idle_add right?
<RAOF> Or idle_add, yeah.
<psusi> and I saw a convience function earlier that does that if the calling thread doesn't already own the context
<RAOF> But you probably want timeout_add, with zero timeout.
<RAOF> Yeah, you could probably whip that up.
<RAOF> You're after the default maincontext / mainloop.
<psusi> right... I want to just queue it up to have the main context call it... I was hoping you could just ->emit() and it would do that, but... ;)
<RAOF> Well, unless you want to run on a specific mainloop.
<RAOF> I don't *think* ->emit has those smarts.
<RAOF> But it might be worth a check.
<psusi> yea, so theoretically the background thread can make its own context and run its own main loop right?
<psusi> or it can aquire the main main loop and service events in it for a while... I have patched gparted to do that so the background thread can pop up a modal dialog box
<RAOF> Yes.
<psusi> but I'm now trying to figure out how to signal the main thread that it is done and it should perform post processing there and the background thread can exit
<psusi> jesus.. bzr branch of glib is up to 320mb and still going?!
<RAOF> Hm.  Why does the modal dialog need to be in a thread again?
<psusi> RAOF, it uses a background thread to make long running libparted calls so they don't block the main loop... but those calls can have exceptions and when they do, they call an exception handler to ask what to do... gparted used to ignore them so the libparted calls would take default action, i.e. fail...
<psusi> I patched it so that it actually handles the exception by poping up a messagebox asking the user what to do
<psusi> i.e. ignore, retry, cancel
<RAOF> Hm.  I think I'd do that by making the background thread raise a signal, wait for the mainloop to handle it, then return.
<RAOF> Whee, 11.4K commits
<psusi> I considered that, but a modal dialog seemed to fit better just calling gdk_threads_enter() and taking over the main loop to run the nested dialog main loop there
<psusi> needed far less modification to that existing code too
<psusi> but now there's some other code that right now, runs a nested loop of usleep, Gtk::Main::events_pend() Gtk::Main::iteration() until the background thread signals that it is done
<psusi> and I'm trying to refactor it to instead spawn the background thread, and return to the main loop, then do the rest in a completion callback when the background thread is done
<psusi> and I was hoping I could just refactor the code following the loop into a signal handler and emit the signal in the background thread before it terminates
<psusi> jesus, git cloning the linux kernel doesn't download as much as branching glib...
<psusi> what the hell?  bzr said it had downloaded like 450mb, but the .bzr directory is only 236mb... the whole branch dir including all checked out sources is only 305m
<RAOF> Huh.  What were you branching?  My branch downloaded 40Mb
<RAOF> (Of lp:glib)
<RAOF> Anyway.  Lunch/errands time.
<psusi> RAOF, lp:ubuntu/glib2.0
<RAOF> That'll be bigger because it contains all the original tarballs for every release in Ubuntu
<RAOF> Or, rather, it contains enough information to generate them.
<lifeless> RAOF: also the protocol; if psusi wasn't lp-logged-in, it would be http which has fat
<RAOF> lifeless: Yeah; I checked lp:ubuntu/glib2.0.  It took at least 200MB before I forgot about it.
<RAOF> There are some *serious* savings available for package-branches.
<RAOF> A bit more than an order of magnitude, in fact.
<RAOF> I wonder why the package-branch is so much bigger, though.
<dholbach> good morning
<Laney> howdy
<Q-FUNK> https://launchpadlibrarian.net/90354168/buildlog_ubuntu-precise-powerpc.smartcardpp_0.3.0-0ubuntu3_FAILEDTOBUILD.txt.gz
<Q-FUNK> this seems to be cause by a new cmake (upon which I build-depends) which left cmake and cmake-data out of sync.
<tumbleweed> yes. Occassionally we have some installability problems
<Q-FUNK> how do I re-launch the build later?
<tumbleweed> click the retry button
<tumbleweed> (on the build record page)
<tumbleweed> it looks like the cmake is already published
<Q-FUNK> tumbleweed: hopefully.  relaunched.
<Q-FUNK> interesting. it seems that my two previous uploads haven't propagated to the archive yet.
<Q-FUNK> they show on the package's source page, but apt-get comes back empty handed.
<tumbleweed> hanging out in bin-NEW?
<Q-FUNK> could be, but they show as published.
<tumbleweed> then they should be...
* tumbleweed changed the topic of #ubuntu-motu to: REVU is back up | Precise: open for business | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://bit.ly/fz6AyQ | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/
<Q-FUNK> how long does it usualy take before binaries are pushed in?  relaunching the powerpc build failed again, again because cmake and cmake-data are out of sync.
<geser> Q-FUNK: the publisher runs now every 30 minutes
<geser> if you want to be sure, you can also check the publishing status for a binary package in LP
<geser> cmake-data got published on 2012-01-18 12:33:57 UTC, cmake (powerpc) got published on 2012-01-18 13:33:38 UTC
<micahg> udienz: FYI, for stuff like https://launchpad.net/ubuntu/+source/seqan/1.3-1ubuntu1, anything that switches to xz compressed binaries, for precise, you need a Pre-Depends on dpkg (>= 1.15.6~)
<Q-FUNK> geser: ok, good to know. thanks for the info.
<porthose> so is dirspec in universe or main? https://launchpad.net/ubuntu/+source/dirspec says universe however the rejection mail I just got says "Signer is not permitted to upload to the component 'main'" ???
<Laney> https://launchpad.net/ubuntu/+source/dirspec/+publishinghistory
<Laney> main
<Q-FUNK> what about pushing new binaries?  smaprtcardpp is marked as published, but its binaries are markerd as new.
<Q-FUNK> how often does that take place?
<Laney> it is a manual process
<Laney> (the reviewing)
<Laney> sticking stuff in the queue is an automatic part of publishing
<Q-FUNK> right, I figured that it was a manual process, but how often does it take place?
<porthose> Laney, thx
<Laney> whenever someone does it, but not usually more than a couple of days
<Q-FUNK> ok
<tumbleweed> Q-FUNK: IIRC you have a bunch of interdependant packages. Just upload them all, and let them depwait on each other?
<Q-FUNK> tumbleweed: can I do that?  I thought that I would get the dependencies uploaded and approved in order.
<tumbleweed> if you're pretty confident that they will work, go for it
<Q-FUNK> that's how it goes at debian, so I assumed the same here.
<Q-FUNK> ok. good to know. in that case, I might as well upload them all now so that they all get the initial review and upload at the same time.
<Laney> you could do the same at debian (and actually better, because bd-uninstallable makes wanna-build a bit smarter than launchpad), just that you'd have to first locally build the stack
<Q-FUNK> afaik at debian, one must get the dependencies approved via NEW and uploaded to unstable, in order, before more packages can be built using them.
<tumbleweed> in debian, the maintainer uploads binaries
<tumbleweed> so the maintainer can upload locally bootstrapped binaries for all the packages in th set
<Q-FUNK> right, but won't the buildd fail to build for some architectures because of missing items in the build-dep chain?
<tumbleweed> they won't even build, beacuse they are bd-uninstallable
<Q-FUNK> ok. good to know.
<psusi> is there a way to get from a sigc functor to a GSourceFunc/gpointer pair so you can use it as a glib callback?
<udienz> micahg: Right, i on it now
<l3on> hey guys... I found packages with unmetdep in oneiric.. they are so many â http://paste.ubuntu.com/808815/
<l3on> what we should do ?
<ScottK> l3on: First fix them for precise and then see if it's worth fixing in oneiric.
<l3on> ScottK, ok... I have to open a bug for each of them ?
<ScottK> l3on: There's no real need to open a bug unless you also have a fix.
<l3on> ok :)
<ScottK> Things like that come and go for various reasons so maintaining bugs isn't really worth the trouble.
<l3on> if I'm not wrong, unmet dep are fixed appeding "build1" version if there's no change in ubuntu, right ?
<jtaylor> only if the dependency is catched by a rebuild
<l3on> ah of course, yes... otherwise "ubuntu0.1"
<l3on> (if it's not in precise I mean)
<ScottK> You need to understand why the dependency is missing.
<ScottK> It's not as simple as that.
<l3on> ok, let me know understand :)
<l3on> Case 0: just rebuild â "buildX+1"
<l3on> Case 1a: precise (dev) "ubuntuX+1"
<l3on> Case 2a: SRU "ubuntuX.Y+1" (if has changes, otherwise "ubuntu0.X+1")
<l3on> and if it's a simple rebuild, but it's a SRU ?
<ScottK> Yes.
<micahg> l3on: dch -R for rebuilds, SRUs should have a X.Y version, i.e. build0.1 for an SRU rebuild for a package with no Ubuntu changes
<l3on> ah ok, thanks micahg ScottK :)
<rubiojr> Good evening Gentlemen
<rubiojr> Quick question, to contribute some packages and become a MOTU at some point
<rubiojr> do I need to follow the bazaar route?
<rubiojr> or is it ok to keep the packages in let's say GH
<jtaylor> its up to you where you hold your package vcs
<jtaylor> you don't even need to us a vcs at all, but its recommended
<rubiojr> ah
<rubiojr> good to know
<rubiojr> thanks jtaylor
<jtaylor> also MOTU does not necessarily mean you ahve to maintain your own packages (I think)
<rubiojr> alright
<rubiojr> I'll be happy to do that anyways
<jtaylor> packages should be contributed to debian if possible, it benefits more users that way
<rubiojr> yeah, I got that bit
<rubiojr> but if I want the package to be in precise (if possible)
<rubiojr> the Debian route doesn't make sense right now
<rubiojr> correct?
<jtaylor> depends, finding a sponsor in ubuntu can take a long time too
<rubiojr> yeah, trying to talk to highvoltage
<rubiojr> submitted an app the other day to the Store
<rubiojr> and told me it was probably better to try to push it to universe
<rubiojr> so how do you guys build the relation with the sponsor?
<rubiojr> following procedure in Wiki and then waiting someone to pickup the sponsorship?
<jtaylor> pretty much, but that can take forever
<jtaylor> finding a fitting packaging team in debian is often a good route
<rubiojr> yeah, I know that :)
<rubiojr> Ok I see
<rubiojr> thanks jtaylor
<rubiojr> let's practice some mail bombing
<highvoltage> hey runasand
<highvoltage> rubiojr: I'm willing to sponsor the package for you, it didn't a lot of fixing to get into universe
<rubiojr> awe cool, that was unexpected :)
<psusi> so normally apps ship .po files with translations in them... but when debianized, they are stripped out of the package and stored in giant langpacks for each language that has all translations for all packages that you install if you want to use that language?
<micahg> psusi: that's only for main and select universe packages
<micahg> *most of main
<psusi> micahg: so if I wanted to run parted in fresh, I'd have to install... what package?  and that would get me ALL frensh translations for all packages in main?
<psusi> french rather
<micahg> psusi: go to language settings and add french
<psusi> I'm on a server atm, so.. what package would that actually install?
<micahg> well, language-pack-fr, language-pack-fr-base, and a few others
<psusi> so when the build daemons build another package, they strip out the language files and automatically update those language-pack packages?
<micahg> pkgbinarymangler does that I think, the files get uploaded to launchpad to be included in the langpacks
<psusi> it's a shame that dpkg can't do conditional recommends... then each package could have its own set of translation packages that would automatically be installed if you have that package, and the language metapackage installed... instead of having to get the translations for all packages in bulk...
<micahg> psusi: it's done this way so translations can be updated independently of the packages themselves
<psusi> micahg: that's why the translations are in a separate package, yes... but there's not a good reason to glob the translations for all packages into one giant langpack
<psusi> other than dpkg lacking the ability to figure out that if you have the french metapackage installed, and parted installed, then you probably want the parted-french package
<micahg> yes, it is, managing the binaries otherwise would be a nightmare
<psusi> what binaries?
<micahg> the translations binaries
<psusi> why would it be a nightmare?
<micahg> you would have 3k binaries built out of each langpack source
<psusi> what's wrong with 3k binaries?
<micahg> first, that's a lot of extra overhead, you would end up with ~300k more binary packages in the archive
<micahg> it just sounds very troublesome
<blair> so hdf5 1.8.8 made it to debian unstable, will this make it into 12.04?
<Laney> isn't that a transition?
<geser> only if someone requests a sync (and has a reason to sync from unstable or waits till it hits testing)
<micahg> blair: well, there, there's still a transition that needs to happen: http://release.debian.org/transitions/html/hdf5.html
<micahg> if the archs we need are green or almost all green (close to Feature freeze), we can do the sync
<Laney> if someone volunteers to shepherd it
<micahg> that too
<Rhonda> I think I need a FFe soonish. :)
<Laney> not until Feb 16th
<Rhonda> Just tried to fire up the wiki for looking up the dates, but it isnt loading  â¦  *grmpf*
<Rhonda> local issue though
<Rhonda> ah, wait  â¦
<Rhonda> Laney: wesnoth-1.10 will be a new source package, so it is affected by the import freeze, right?  Or would a regular sync request still be possible, for a completely new package?
<Rhonda> â¦ "sorta" completely new, actually.
<Laney> Rhonda: Everything is affected by the import freeze, but syncs of new packages aren't a particular problem
<Rhonda> Wasn't a problem last time for wesnoth-1.8 I seem to remember :)
<blair> geser, micahg i'm pushing for our next OS for 500 desktops to be 12.04 and we have projects that use hdf5 and the current ubuntu version has bugs (and it's older than what we have currently deployed)
<jtaylor> how can one add a bug link to http://qa.ubuntuwire.com/ftbfs/?
<blair> so i should wait a bit and then could request a sync?
<blair> does sheparding the transition need somebody who is a debian committer?
<Laney> needs someone who is going to see all of the needed work through
<Laney> rebuilds and whatever else needs doing
<blair> i mean, ubuntu commiter
<Laney> no
<blair> ok
<Laney> you just need to get sponsorship when you need it
<Laney> keep an eye and make sure everything gets done
<Laney> might be best to watch for a bit and see how it goes in debian first though
<Laney> goodnight!
<tumbleweed> jtaylor: tag the bug ftbfs
<jtaylor> too obvious :)
<jtaylor> thx
<tumbleweed> submit a merge proposal with a hint? :)
#ubuntu-motu 2012-01-19
<mvdk> I have a packaging of JBIG-KIT on my PPA.  I wish to submit it for inclusion, solving #594250.  How do I do it?
<mvdk> Are there any MOTU in the house?
<mvdk> Are there any MOTUs here?
<RAOF> Yes.  Some might be a bit busy :)
<mvdk> Did any of them see my question, or is it fair to suppose I should ask in an hour's time?
<RAOF> The first question they'll likely ask is: can this be submitted to Debian?  That'll get it into Ubuntu, and also be useful for a bunch of other people.
<mvdk> Not before precise's feature freeze closes
<achiang> can someone explain gpg keys to a dummy? i normally sign packages with @foo.com, but now, i want to make an upload with @bar.com. i have both @foo.com and @bar.com as uids on my private key but... not sure how to actually sign as @bar.com
<achiang> i used @bar.com in debian/changelog
<RAOF> achiang: Then you're signing as @bar.com
<mvdk> Reason being that last patent it's subject to is a US patent that expires on 4/4/2012
<RAOF> Hm.  Debian's patent policy is roughly the same as Ubuntu's - has it been rejected from Debian before?
<mvdk> About 3 years ago
<achiang> RAOF: hm, but... http://pastebin.ubuntu.com/809232/
<mvdk> The final patent is rather dubious, but it's US only, anyway
<broder> mvdk: if it's still protected by a patent, that seems like it would be a problem for Ubuntu as well
<mvdk> So all the patents have expired in the UK, which is where Canonical is
<psusi> achiang, debbuild signs with whatever key has the id listed in the changelog
<psusi> achiang, so as long as the new address is listed on your key, using that address in the changelog should be all you need to do
<achiang> psusi: maybe i don't actually have a key for '@bar.com'... perhaps i only added @bar.com as a uid?
<achiang> psusi: there's a pastebin above with my error
<psusi> achiang, does gpg -K show that address?
<achiang> psusi: ah, i figured out my issue... i used a debian/changelog line of:  -- Alex Chiang <alex@chizang.net>  Thu, 19 Jan 2012 00:33:45 +0000
<RAOF> mvdk: Ubuntu is also distributed from US servers
<achiang> psusi: but in reality, what is in my key is Alexander Chiang <alex@chizang.net>
<achiang> psusi: i didn't realize it was going to match on the entire string, not just the actual email address
<psusi> achiang, ahh, yea
<RAOF> It matches on full string *and* comment.
 * psusi finally started using his @ubuntu.com email recently
<RAOF> So if you've got, for example, a comment of RAOF then you need to sign as Christopher James Halse Rogers (RAOF) <raof@ubuntu.com>.
<achiang> RAOF: yep, got it now.
<achiang> is that a gpg thing or a debuild thing (the matching)
<RAOF> Which is why my GPG keys no longer have a comment of RAOF :)
<mvdk> RAOF: So what I was hoping for was to include it in the pre-release so it could be included in Precise when it is released
<mvdk> RAOF: It's actually a pretty big thing for hylafax - yeah, including patents in things that are actually in common circulation is kind of nasty :(
<RAOF> mvdk: We need to care about it from the time it hits the archive - after all, we're distributing it as soon as it hits archive.ubuntu.com.
<RAOF> mvdk: To what extent is this patent enforced?  Have you read https://wiki.ubuntu.com/PatentPolicy ?
<RAOF> Yes, software patents generally suck.
<mvdk> Practically not enforced any more
<mvdk> Mitsubishi is the owner of the patent in question
<RAOF> And about to expireâ¦
<mvdk> Yep
<mvdk> And it's the last one of about 25
<RAOF> So, I've not been following the recent discussions about new-package-uploads on the MOTU lists; I *think* the current correct procedure is still to upload to REVU.  You might also want to attach your source package to the bug in question, and subscribe (not assign!) ubuntu-sponsors.  That'll get it on the sponsorship queue.
<mvdk> See http://www.cl.cam.ac.uk/~mgk25/jbigkit/patents/
<mvdk> OK, I'll google for REVU
<mvdk> Thanks
<broder> i still don't understand why uploading to debian isn't an option. it's possible to get exceptions to feature freeze, and for universe they tend to be handed out pretty liberally
<RAOF> Aha! http://revu.ubuntuwire.com/ says that it's deprecated, and contains a link to the current process https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<mvdk> Ah, so I need to speak to "the" MOTU
<mvdk> I'm guessing there is in fact more than one...
<mvdk> broder: libtiff isn't universe, and I would submit a one-liner in the control for it
<mvdk> Add a depends for libjbig-dev
<mvdk> Build-depends, rather
<mvdk> OK, so I should attempt debian first, no probs
<RAOF> Yeah.  There are more people who can upload to Debian than who can upload to Ubuntu (as a goodly number of Ubuntu developers are also Debian developers, but not visa-versa).
<mvdk> RAOF: broder states that exceptions are sometimes given.  Is it likely that an exception would be given for a Build-Depends on libtiff?
<broder> mvdk: are you saying that your thing needs to build-dep on libtiff?
<RAOF> broder was talking about feature-freeze exceptions; it's reasonably easy to get a new package into Universe after feature-freeze, because that's quite safe.
<mvdk> In order for libtiff to use libjbig, there needs to be a build-dep on libtiff, yes
<RAOF> But if you need to add a build-depends on this new package to libtiff, that's different.  It needs libjbig to be in the archive and have a main-inclusion-report done for it (because libtiff is in main it can only build-depend on things in main).
<mvdk> Ah
<mvdk> Ouch
<mvdk> So I should make a tiff-jbig source package that has that one-liner, that is a virtual for all the main package parts?
<mvdk> Sorry, is a provides for all the main package parts
<RAOF> That would potentially be one way to have jbig support in libtiff without getting jbig in main, yes.
<RAOF> Unfortunately, due to limitations of dpkg, that'll only work if nothing has a versioned dependency relationship on libtiff. [Ie: declares Depends: libtiff (>= someversion)]
<mvdk> Yuck
<psusi> RAOF, glib timeouts are called without gdk lock, so you need to call gdk_threads_enter() before doing any gtk stuff right?
<mvdk> So it's more like "Sit in the corner and cry" :(
<RAOF> psusi: That sounds right.
<psusi> damn...
<RAOF> mvdk: It'd still be possible to get that happening, but it's tight.  What is jbig support, and how much do we need it?
<mvdk> Several printers are useless without it
<mvdk> In particular, a heap of Samsung & Lexmark printers are useless - all the ones with splix support
<RAOF> That sounds like something we want to have, then.
<mvdk> They don't depend on libtiff support, though
<mvdk> hylafax depends on libtiff support
<psusi> RAOF, is there a sigc or gtkmm template somewhere you can use to wrap a sigc::mem_fun in a gdk_enter_threads so you can pass it to Glib::SignalTimeout::connect without writing your own function to do so? ;)
<RAOF> Is there a bug for the fact that we lack support for those printers?
<RAOF> psusi: Dunno; I'm not familiar with gtkmm.  If I want to write something in a high-level language I'll use a high-level language :P
<psusi> hehe...
<mvdk> Yeah, with wontfix, I think
<RAOF> Is it only the fax functionality that's broken?
<psusi> you would think that gtk would have its own timeout wrapper that made sure to grab the lock
<mvdk> hylafax won't be able to use JBIG if libtiff doesn't get built without libjbig
<mvdk> splix (the printers) won't work if libjbig doesn't get built
<mvdk> splix is a universe package, though
<mvdk> splix is not a universe package, I didn't realise, sorry
<RAOF> mvdk: If you can hunt down that bug, this sounds like something that should be fixable now.  Hardware support is generally a good reason for a MIR :)
<mvdk> But the ubuntu maintainer has decided to add the libjbig as a statically linked bit of source in his own package :P
<mvdk> As of about 2 weeks ago
<RAOF> Urgh, really?
<mvdk> Yep, nasty hey?
<RAOF> Hm, so he has.
<micahg> RAOF: mvdk: policy around REVU is if you have someone to REVU it and it's going straight into Ubuntu, that's the place, otherwise, try to get into Debian through debexpo
<RAOF> mvdk: So, I think that's actually a mistake on his part, and we should do the work to get your proper libjbig package into main.
<mvdk> OK, no probs.  Do you have the PPA I set up?
<mvdk> That's the package I actually intend to attempt to submit
<RAOF> I don't, no.  Is the package lintian-clean?
<mvdk> Yes, but the symlinks aren't properly set up.  I haven't quite figured out libtool. (That is, lintian doesn't actually check that the build scripts do sensible things)
<mvdk> Only the libjbig-dev does symlinks (That is, libjbig-dev has libjbig.so -> libjbig.so.0, but both libjbig.so.0 and libjbig.so.0.0 are real files)
<RAOF> Huh.
<mvdk> I think libjbig.so.0 ought to be a symlink to libjbig.so.0.0
<mvdk> It doesn't actually cause it to fail, but it seems silly
<RAOF> That's the way it generally should be.
<RAOF> Does libjbig do ABI stability?  An SONAME of .0 is sometimes suspicious. :)
<mvdk> libjbig has been stable for the last 4 years
<mvdk> That is to say, the author hasn't made any releases - and why would he, the library is only 3 files containing about 2K lines...
<mvdk> +3 headers
<mvdk> And the author has never released them as so's
<mvdk> His build script made .a's...
<mvdk> So the part about making it into a .so was my part
<RAOF> Ah.  Joy!
<mvdk> Yeah, hence my looking into what I need to do to make libtool work...
<RAOF> I found http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id292165 an excellent reference for general library packaging things.
<mvdk> I think I found what my issue is
<mvdk> I said install -s -m ...
<mvdk> But I should only have said that for the main file
<mvdk> So I need install -s -m ... *.*.* but just install -m ... .so .so.[^.]*
<RAOF> I generally use the magic of autofoo, which tends to get it right.
<mvdk> RAOF: I got that working.  Lintian has some more output: It doesn't like some binaries not having man pages.  I guess I ought to write them, right?
<RAOF> Hm.  Why does the package have binaries at all?  Are they demos or something?
<mvdk> It seems the author had some other file formats that were supported.  The demo directories seem to have some weird stuff.  In any case, they allow conversion from pbm to a raw jbig stream (if you can think of a reason to want to do that)
<mvdk> And vice-versa
<RAOF> That doesn't sound awesomely useful.  Feel free to simply not ship those.
<mvdk> I put them in jbigkit-bin, which wouldn't need to be a main package
<mvdk> So I have 3 packages from the source at the moment: libjbig, libjbig-dev & jbigkit-bin
<mvdk> The libjbig & libjbig-dev would need to be in main
<RAOF> That sounds roughly right (I presume it's actually libjbig0)
<mvdk> Yes, it is, sorry
<mvdk> It wants me to fill in minimum versions for libc-dev & gcc.  Is there a good minimum to use?
<mvdk> The build worked on lucid, I'm thinking I should use its version numbers
<mvdk> Any idea what a reasonable minimum for libc-dev is? I put >= 4.4 for gcc...
<RAOF> I think the actual problem is that you don't actually _need_ a Depends on libc-dev and gcc.
<RAOF> They're assumed to be provided by the build environment, so you only need to specify an explicit dependency if you need a specific version - hence the warning.
<mvdk> Oh, very classy.  I wonder why the new-package scripts gave me it for free?
<RAOF> Dunno.
<mvdk> RAOF: I just packaged a jbigkit-2.0-6 for precise that has everything but the manpages fixed
<mvdk> RAOF: Thanks for all your help.  I've posted the package on mentors.debian.net.  Hopefully I can find someone to sponsor it...
<ricotz> siretart, hello, could you get libaacs 0.3.0-3 synced?
<dholbach> good morning
<siretart> hi dholbach, morning ricotz
<siretart> ricotz: yes, let me testbuild it
<ricotz> siretart, hi, thanks
<dholbach> hey siretart
<siretart> ricotz: that the first time I'm using this newfangled syncpackage script. let's see if the sync really gets attributed to you :-)
<ricotz> siretart, hoping the best ;P
<siretart> Changed-By: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
<siretart> doesn't look like it, but it got accepted :-)
<ricotz> siretart, i see, dont worry
<Laney> sure it did https://launchpad.net/~ricotz/+synchronised-packages
<ricotz> Laney, oh nice, havent seen this new categories there yet
<Laney> https://lists.ubuntu.com/archives/precise-changes/2012-January/007584.html even says your name :-)
<ricotz> i see :), formerly the name would have appeared here too https://launchpad.net/ubuntu/+source/libaacs/0.3.0-3
<Laney> ye that bit is missing
<Laney> hopefully be back soon
<ricotz> ok, it isnt important
<dholbach> hey, so I mailed a few folks about this already, but it might be worth bringing it up here as well - I need some help filling the schedule for Ubuntu Developer Week, so I can go and announce it and try to get some press attention, so we can get many new contributors :)
<dholbach> looking at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable what I feel we still need is a few hands-on sessions, maybe even just 30 minute ones which most of you could probably just off-the-cuff :)
<dholbach> in a dog-walking break I came up with these ideas already http://paste.ubuntu.com/809547/
<dholbach> having reached out to new contributors in the last months, I found that demo'ing how things are done with an example generally had a huge impact on their views of how easy it is to get involved
<micahg> dholbach: a security session would be good  Ithink
<dholbach> ah yes
<micahg> I'll see if I can find someone to do it :)
 * dholbach hugs micahg
<tumbleweed> Laney: looks like nobody has volunteered for the second debian slot yet
<dholbach> it's hard work getting the schedule filled this time
<Laney> those slackers
<dholbach> which is why I suggested more hands-on sessions, where you just talk about a few examples you picked earlier - which I I supposed would come naturally to most of the ubuntu developers and contributors :)
<tumbleweed> people often come aind and ask what they can do to help, does a short slot on the kind of things MOTU does sound interesting? It wouldn't be particularly hands-on
<dholbach> sure - explaining where we list our task lists and what they all mean would be super helpful
<dholbach> or maybe a "here's how reviews are done, let's pick 5 items from the queue" session
<dholbach> would have the nice side-benefit of getting the queue shorter ;-)
<ajmitch> not really the best time of day for me to help out with that
<dholbach> ajmitch, I know :-/
 * dholbach hugs ajmitch
<dholbach> maybe we can groups of 2 or more to copresent sessions, like Laney and tumbleweed do?
<Laney> well actually we might split that up
<Laney> give one half of the debian stuff each
<dholbach> ah, so that'd be "working with debian" and "working in debian" like you mentioned some days ago?
<Laney> yeah
<Laney> but I'll re-ping
<dholbach> sweet
<dholbach> great
 * dholbach hugs Laney and tumbleweed
<dholbach> rock stars :)
<scott-work> i uploaded a lowlatency kernel package to REVU last night i have yet to get a confirmation email or see it on the website, is this unusal and do i need to worry about it yet?
<psusi> scott-work: revue is for brand new packages that want to get into universe, and is obsolete
<siretart> scott-work: did you upload a _source.changes or a _i386.changes file?
<ScottK> psusi: It's not obsolete.
<ScottK> Little used, I would agree with, but not obsolete.
<scott-work> psusi: the lowlatency kernel is a new package that needs to be into universe
<scott-work> siretart: i believe i uploaded a _source.changes, but i can check when i get home tonight
<scott-work> siretart: i used 'debuild -S -sa' to generate the .changes files if that helps any
<psusi> scott-work: linux is already packaged... if you want to add a low latency flavor, it is just another binary package that should be added to the existing suorce package.. but there used to be one and the kernel removed it a few releases ago
<psusi> ScottK: there was some discussion yesterday about it and there was a new proceedure that didn't involve revu iirc
<psusi> kernel-team removed it that is
<psusi> iirc, because the generic one is pretty much just as good now
<ScottK> The kernel team is not everybody.
<ScottK> there is an intent to replace it with mentors.debian.net, but it's not there yet.
<scott-work> psusi: there has been discussion with the kernel team and they do not want to maintain this kernel and therefore will need to be community maintained kernel
<scott-work> psusi: the kernel team is very accepting of a community maintained kernel based on the ubuntu kernel
<scott-work> psusi: but it would need to be in universe therefore and a separate package
<psusi> scott-work: you can't have a main source build a universe binary?
<scott-work> psusi: per a uds-p blueprint i we are to build, package the lowlatency kernel and then submit to REVU
<scott-work> psusi: it would suggest it's not a matter of ability but that the kernel team does not want to be directly involved with this kernel, including having it in their code
<scott-work> no disrepect to UKT intended as i completely understand and agree with their motivations and concerns
<psusi> by low latency, do you just mean switching the config option from desktop to preempt?  or are there actual source changes?
<scott-work> psusi:  i am not a kernel expert, but my understanding is that the only changes are flags during build
<scott-work> psusi: this is the blueprint if you are interested:  https://blueprints.launchpad.net/ubuntu/+spec/other-p-lowlatency
<psusi> seems silly to upload a near duplicate source package just for a config change... how much difference does it actually make anyhow?
<scott-work> psusi: performance wise for recording audio it can lower the latency by at least a factor of 2, in some cases it has lowered performance by a factor of almost 8
<scott-work> psusi: and it also practically eliminated _all_ xruns at most of those latencies
<psusi> I found the other day that glib's timer implementation is horribly incaccurate and submitted a patch for it... in my testing it got 20% off when run niced with stress -c in the background running a 50 Hz timer... simple patch to glib and that went down to like 0.0001% error
<psusi> how much latency are we talking about here?  microseconds?
<scott-work> psusi: yes, microseconds
<psusi> wow... so you want to work with only a few microseconds of audio buffer?  damn...
<astraljava> Ehh... that can't be right. Gotta be milliseconds.
<scott-work> psusi: sorry, astraljava is correct, it's milliseconds....i mispoke preparing to go to a meeting
<scott-work> but the point is per an approved bluepring from uds-p i was to submit to the lowlatency kernel to REVU
<scott-work> if i can being told that i cannot use REVU in this capacity i need to find another vector to get this package into the universe archive
<scott-work> also, i uploaded last night (approximately 16 hours) but have not yet received an email or can see it on the website, is there perhaps a problem with the dput although it said it uploaded properly?
<micahg> scott-work: what's wrong with REVU now?
<scott-work> micahg: hi, it started like this....
<scott-work> [08:40] <scott-work> i uploaded a lowlatency kernel package to REVU last night i have yet to get a confirmation email or see it on the website, is this unusal and do i need to worry about it yet?
<astraljava> psusi: Even though we're not actually talking microseconds, the difference is drastic on some heavy audio-related tasks. People interested in such have provided test results regarding such sessions, and in several cases the latency was dropped to even smaller than one third.
<micahg> scott-work: it should show up fairly quickly, I assume you did dput revu foo_source.changes?
<scott-work> micahg: i think siretart had a good suggestion on checking which *.changes file was uploaded, which i will check in approximately 6 hours hence, but generally i was just trying to get a feel for if this is normal and i dont' need to worry
<astraljava> psusi: So even when we're only talking miniscule amounts of diffs codeline-wise, there are other differences.
<scott-work> micahg: aye
<jbicha> gcompris fails to build with the latest librsvg "error: 'RsvgSizeFunc' is deprecated [-Werror=deprecated-declarations]"
<jbicha> is there an easy fix for that?
<micahg> why wasn't this caught before the upload?
 * micahg would have assumed 2 devs test built this in this case
<jbicha> because new librsvg was just uploaded a few hours ago, it didn't fail earlier
<micahg> ah, ok :()
<micahg> :)
<micahg> the big hammer would be to use the no-error equivalent when building, ideally, patch it to use whatever replaced it
<scott-work> interestingly nothing since 02 jan 2012 is showing up on the revu website :/
<ScottK> It was down for awhile before it got rebooted yesterday
<l3on> do you think it normal that a package in universe depends on a non-free package ?
<psusi> so why is using pkexec better than gksu?
<ScottK> l3on: No.  It's a bug.  What package?
<l3on> boinc-amd-opencl
<scott-work> siretart:  i called my wife and asked her to read me the filename for the .changes file, it was a _source.changes file
<l3on> in precise
<ScottK> l3on: It's in multiverse: boinc-amd-opencl | 7.0.7+dfsg-1 | precise/multiverse | amd64, i386
<l3on> right right... well, in this case ?
<l3on> is still a bug ?
<ScottK> No, that's where non-free stuff goes.
<l3on> ah ok, thanks :)
<l3on> in anycase, it has a bronken dep on amd-libopencl1
<ScottK> Different sort of bug.
<ScottK> It's not strictly required that multiverse packages be installable just from packages in the archive.
<l3on> thanks for the info :)
<siretart> scott-work: gpg: Can't check signature: public key not found
<siretart> scott-work: seems you're not added to the keyring yet
<scott-work> hmmm, i did this for the zynjacku, strange
<l3on> do you know where can I find information about what happened to package libcassad1 ?
<scott-work> maybe i'm using a different key than i did back then
<siretart> but 9E2AC7F4 is your key, which is registered in launchpad, right?
<scott-work> siretart: i'm guessing then i need to verify my key is in the ubuntu keyring?
<scott-work> siretart: "9E2AC7F4", i'll check, but it shoudl be
<siretart> you need to join the revu-uploaders team
<siretart> revu has a cronjob that collects keys from launchpad
<scott-work> siretart: aye, that is my key
<scott-work> siretart: okay, i'll join now then
<scott-work> and then dput again?  or will i need to dput -f this time?
<siretart> scott-work: dputting again should work, or some revu admin can move back the .changes file
<scott-work> siretart: okay, maybe i'm flusttered, but i simply can't find 'revu-uploaders' in launchpad
<siretart> oh
<siretart> right, that was removed at some point..
<siretart> RainCT: around? see above
<siretart> scott-work: sorry, I was wrong
<siretart> scott-work: 2012-01-19 20:16:43 - linux-lowlatency_3.2.0-9.16_source.changes: Incorrect signature, moving to rejected.
<siretart> or wait. no
<RainCT> Hey
<scott-work> siretart: i would like to point out that no matter the outcome, i really do appreciate your efforts to help me :)
<RainCT> siretart: the cronjob is long gone
<RainCT> keys are pulled individually from Launchpad every time you log in on the REVU website
<RainCT> scott-work: ^
<scott-work> RainCT:  i _think_ i might have dput'ed before logging in (at least in a year)
<siretart> RainCT: aah, that explains
<scott-work> RainCT: now that i have logged into the website do you think dput will work
<scott-work> ?
<siretart> scott-work: http://revu.ubuntuwire.com/p/linux-lowlatency
<siretart> scott-work: I've reprocessed your upload manually.
<scott-work> siretart: i simply cannot thank you enough!  if i see you at a uds i will buy you several of your favourite beverages :)
<siretart> :-)
<l3on> hi guys, how a package can be updated with bzr ?
<l3on> I looking at "condor"
<l3on> well, maybe it's too much complex for me :/
<scott-work> l3on: my experience is to download the bzr branch, make the changes, upload back to the branch, and then ask for a sponsor to upload the changes to the archives
<l3on> scott-work, well but I'm going to "upgrade" package, in meaning of new upstream release.. is there something like --pristine ?
<jtaylor> there should be an merge-upstream command
<l3on> found, thanks jtaylor
<micahg> l3on: http://developer.ubuntu.com/packaging/html/udd-merging.html#merging-a-new-upstream-version
<l3on> well, seems to not work...
<l3on> bzr merge-upsream $HOME/condor-7.6.6.tar.gz
<l3on> returns an exception...
<broder> l3on: you need to specify the version number as well. don't remember exactly how - might be --version or -v or something
<koolhead17> slangasek: hi there
#ubuntu-motu 2012-01-20
<psusi> oh dear... using pthread_cancel() is just a huge no-no, especially in gtk apps, isn't it?
<mlinscott> what did I do wrong here? merge proposal diff shows every file has having conflicts and being moved to <filename>.moved. https://code.launchpad.net/~matt-linscott/ubuntu/precise/update-manager/fix-for-utils.py-typo
<l3on> hi all... someone of you know if (rebuild1 << ubuntu1) is true ?
<micahg> l3on: yes, you can check with dpkg --compare-versions
<l3on> ah ok :) thanks micahg , as always :)
<l3on> stacco, a questo pomeriggio/sera
<jtaylor> :/ ccache does not cache mpic++
<jtaylor> I wonder if it breaks if I add the symlink manually
<jtaylor> nice appears to work
<antoniu_> Does anyone know how to upload to a ppa?
<jtaylor> antoniu_: have you read the documentation?
<astraljava> antoniu_: You will find great help for that @ https://help.launchpad.net/Packaging/PPA
<antoniu_> I built a dsc file using dkms, now when i set a ppa it says I can upload using the following command, <source-package>
<antoniu_> sudo dput ppa:someitalian123/rt3562sta
<antoniu_> followed by the source package name
<antoniu_> when I try that I get the following error
<antoniu_> Checking signature on .changes
<antoniu_> gpg: WARNING: unsafe ownership on configuration file `/home/antoniu/.gnupg/gpg.conf'
<antoniu_> gpg: no valid OpenPGP data found.
<antoniu_> gpg: the signature could not be verified.
<antoniu_> Please remember that the signature file (.sig or .asc)
<antoniu_> should be the first file given on the command line.
<antoniu_> No signature on /var/lib/dkms/rt3562/2.4.1.1/dsc/rt3562-dkms_2.4.1.1_source.changes.
<jtaylor> did you sign the changes file?
<antoniu_> How do you do that?
<jtaylor> debuild does this for you, if you build differently debsign changes-file
<antoniu_> I didn't use debuild I used dkms because it's a driver module
<antoniu_> sudo dkms mkdsc -m rt3562 -v 2.4.1.1 --source-only
<jtaylor> you can build packages with dmks?
<antoniu_> yes
<jtaylor> interesting
<jtaylor> whats files are created by that command?
<antoniu_> a tarball, a dsc file, and a source.changes file
<jtaylor> sign the changes file with debsign
<jtaylor> that should then be uploadable (no idea if it will build on the ppa though)
<antoniu_> what's the command for that, sry I'm such a noob, I've never packaged anything before
<jtaylor> debsign changes-files
<antoniu_>  signfile /var/lib/dkms/rt3562/2.4.1.1/dsc/rt3562-dkms_2.4.1.1.dsc Dynamic Kernel Modules Support Team <pkg-dkms-maint@lists.alioth.debian.org>
<antoniu_> gpg: skipped "Dynamic Kernel Modules Support Team <pkg-dkms-maint@lists.alioth.debian.org>": secret key not available
<antoniu_> gpg: /tmp/debsign.QcTcnVAl/rt3562-dkms_2.4.1.1.dsc: clearsign failed: secret key not available
<antoniu_> debsign: gpg error occurred!  Aborting....
<antoniu_> whops I should probably run this as root
<jtaylor> no
<jtaylor> do you have a gpg key?
<antoniu_> no, i don't have any idea what I'm doing
<jtaylor> you have to create one and add it to your launchpad account http://keyring.debian.org/creating-key.html
<jtaylor> https://help.launchpad.net/YourAccount/ImportingYourPGPKey
<antoniu_> thanks, for pointing me in the right direction
<antoniu_> how long does it take to generate a key? This is taking awhile
<antoniu_> nvm
<jtaylor> it can take a while when you don'T ahve much entropy
<jtaylor> doing something disk intensive helps
<antoniu_> I can't read the encrypted email
<antoniu_> I installed Enigmail
<antoniu_> it's not doing anything
<jtaylor> is the proper key setup for it?
<jtaylor> the mail should be clearsigned so you can probably just copy paste it into gpg
<jtaylor> is it possible to smuggle a no-as-needed ... -as-needed block through libtool?
#ubuntu-motu 2012-01-21
<Q-FUNK> seems that one new package I had uploaded was rejected, except that there was no explanation other than "rejected by archive admin". what next?
<Q-FUNK> "rejected by archive administrator" is not a helpful message at all.
<ScottK> What package?
<ScottK> (The AA that rejects it is supposed to mail you with the details)
<Q-FUNK> I don't mind the package being rejected per-se, but it would be useful to know why, so that I can fix it.
<Q-FUNK> libdigidoc (2.7.0-0ubuntu1) precise;
<ScottK> Q-FUNK: Did you upload it more than once?  There's still a copy in New: https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=libdigidoc
<Q-FUNK> ScottK: not that I recall, but it's possible that I inadvertently did so while intending to upload a copy to our team's PPA.
<ScottK> My guess is someone saw two copies in queue and rejected the older one just to clean things up.
<Q-FUNK> ScottK: that reminds me, is there a policy for setting Maintainers to a LP team?  Ideally, the contact address for this would be ~esteid as a team, not just myself personally.
<ScottK> Maintainer needs to be an *buntu.com address.
<ScottK> An LP team in launchpad.net doesn't cover it.
<Q-FUNK> ScottK: ok, that might be the reason. It just wasn't indicated, so it's hard for me to guess.
<ScottK> XSB-Original-Maintainer can be anything.
<Q-FUNK> alright. I guess I'll have to be the official maintainer on behalf of the team... ;)
<ScottK> You can make ubuntu-developers maintainer
<Q-FUNK> right, that one can indeed be anything, but LP teams don't necessarily have any external e-mail, correct?
<ScottK> There's no rule like for Debian where someone in Maintainer/Uploaders needs to be an actual live person.
<ScottK> That's true, but you can get mailing list.
<Q-FUNK> True, and it could make sense for us to have such a list. How do we apply for one?
<Q-FUNK> Then, we could set that list as our PPA team's contact, too.
<ScottK> It's in the LP U/I somewhere.
<Q-FUNK> ok. I'll check.
<Q-FUNK> Thanks for the idea!
<Q-FUNK> ScottK: btw, would you happen to know how often new packages get checked? We have a suite of 6 packages that need to get into Precise to provide support for the national Estonian ID card, the added to Estonian language dependencies.
<Q-FUNK> ScottK: the first one of these (smartcardpp) finally cleared binary-new today.
<ScottK> It's irregular.
<ScottK> All the archive admins also have other duties.
<ScottK> Anything that's uploaded before feature freeze will get in though.
<Q-FUNK> ok
<Q-FUNK> It was all uploaded earlier this week, pending approval and eventually landing in dep-wait.
<Kano> hi, just tested cloudprint 0.5 deb, it misses one depend: python-pkg-resources
<jtaylor> Kano: which distribution?
<Kano> both, the same file anyway for oneric/precise
<jtaylor> nevermind, oneiric
<jtaylor> it works in precise
<Kano> sure, but only because  python-pkg-resources was preinstalled
<jtaylor> clean chroot
<jtaylor> probably some of its depends pulls it in
<Kano> that a script only
<Kano> no automatic depend detection
<Kano> tested it on squeeze and found that
<jtaylor> of course a script will not pull dependencies
<jtaylor> you need a package for that
<tumbleweed> it's common for packages to miss dependencies on python-pkg-resources, because that has to be explicitly stated
<jtaylor> unless you use dh_python2 and it has a correct requires.txt
<jtaylor> that will convert setuptool dependency into a pkg-resources one
<Kano> feel free to change it the way it works correct
<jtaylor> someone familiar with ocaml here?
<Kano> bye
<l3on> Hey guys... someone here can remove condor and classads from precise ?
<l3on> classads has been removed from debian because is now in condor
<l3on> current condor version in ubuntu requires classads as dep, but it does not exist
<jtaylor> file a bug and subscribe ubuntu-archive
<l3on> ok, I'm going
<jtaylor> + sponsors if needed
<l3on> thanks :)
<jtaylor> though if its removed from debian some script should remove it automatically
<jtaylor> I think
<l3on> ah no ok, classads is not in precise
<Weasley> hi, i have a packaging related question
<Weasley> if i want to fork a package, can i use quilt to patch files inside the debian directory, eg. the rules file or the control file?
<jtaylor> it might work, but you should not do that
<jtaylor> just use a VCS
<jtaylor> why do you want to fork a package?
<l3on> jtaylor, bug 919671 - thanks :)
<ubottu> Launchpad bug 919671 in condor (Ubuntu) "Please remove classads and condor from ubuntu precise" [Undecided,New] https://launchpad.net/bugs/919671
<jtaylor> l3on: so condor is uninstallable?
<l3on> jtaylor, yep... it's need a new version... I tried to upgrade it, but I should spend to much time to well understand how condor works
<l3on> jtaylor, bug 518848
<ubottu> Launchpad bug 518848 in condor (Ubuntu) "A new upstream release of condor (7.6.6) is available" [Undecided,Confirmed] https://launchpad.net/bugs/518848
<jtaylor> have you spoken to the guy you uploaded condor?
<l3on> jtaylor, yep
<l3on> I sent him an email 4 days ago... still waiting for a reply
<jtaylor> he wants it removed too?
<l3on> I dind't talk about removal...
<l3on> just about new release and depends problem
<jtaylor> the remove reason is: ROM; No longer released separately, moved to different source package
<jtaylor> can't the new package be used?
<l3on> jtaylor, of course
<l3on> if someone starts to work
<l3on> I tried, but it seems not too much simple
<l3on> jtaylor, would you sponsor a merge for me ? :)
<jtaylor> which one?
<l3on> shogun
<l3on> bug 914523
<ubottu> Launchpad bug 914523 in shogun (Ubuntu) "Please merge shogun 1.1.0-1 (universe) from Debian unstable " [Wishlist,Confirmed] https://launchpad.net/bugs/914523
<jtaylor> thats not nice Add mono-gmcs as build-depends to fix FTBFS
<jtaylor> it should use the default
<l3on> in configure.ac it looks for gmcs
 * Laney eyes this package
<Laney> no clideps?
<jtaylor> nope ..
<l3on> configure:	if gmcs --version >/dev/null 2>&1
<Laney> it should use mono-csc
<Laney> patch it if necessary
<jtaylor> hm ahs the hdf5 transition in deiban started already?
<Laney> http://release.debian.org/transitions/
<l3on> So... what I would do?
<l3on> try to replace gmcs with mono-csc ?
<jtaylor> first file an RC bug in debian
<jtaylor> hm where's my template
<l3on> debian does not have this problem, cause they have mono-gmcs as depends in mono-devel
<jtaylor> not anymore
<jtaylor> I'll file the debian bugs
<l3on> jtaylor, mmm http://packages.debian.org/sid/mono-2.0-devel
<Laney> it didn't even come on our transition radar because the dependencies are wrong
<jtaylor> they are RC, so will hopefully be fixed soon, then we look at the merge again
<Laney> fancy asking antlr and zeroc-ice to rebuild?
<jtaylor> me? in debian? why?
<Laney> i pinged #debian-java on irc but no response
<Laney> because you're filing bugs :P
<Laney> i'll do it later if yo udon't want to
<jtaylor> if you tell me the reason I can do it
<jtaylor> just rebuildonly?
<Laney> they have mono bindings
<l3on> I'm not following you :P
<l3on> shogun has mono-2.0-devel as build-dep, which has mono-gmcs as dep
<l3on> so, it works
<jtaylor> thats most likely wrong
<l3on> jtaylor, ah ok, can you file the bug ?
<jtaylor> yes
<l3on> thanks, please CC me :P
<l3on> ok.. and then .. let's go on with paprefs :D
<jtaylor> Laney: I can copy pasted your coco-cs mail?
<jtaylor> l3on: debian bug 656756, 656757
<ubottu> Error: Debian bug 656757 could not be found
<ubottu> Debian bug 656756 in shogun "shogun: Please use debians default csharp compiler" [Serious,Open] http://bugs.debian.org/656756
<l3on> jtaylor, thanks :D
<l3on> if you're free... paprefs seems ready too
<l3on> note that I updated dsc to althiot, waiting for a sponsor there. Maintainer also hasn't yet replied me after some days.
<jtaylor> Laney: bugs filed
<Laney> jtaylor: thanks, and yeah that's what I would do
<jtaylor> siretart: ups did not see your message on the mplayer bug
<jtaylor> I synced the version from debian almost-testing, it fixes the issue
<siretart> jtaylor: what version did you sync? the one from unstable?
<jtaylor> yes
<siretart> okay, then please just close the bug. I would have done exactly the same :-)
<jtaylor> already done
<jtaylor> sorry I forgot to assign myself
<siretart> no problem
<antoniu> I'm having trouble packaging something into a deb file, can anyone help me out
<jmarsden> antoniu: https://wiki.ubuntu.com/PackagingGuide/Complete
<antoniu> well here's the thing I am able to package it and when I upload it to the ppa it builds successfully, however it's a dkms package that contains a post add script, I made sure to make the script executable but when I install the deb it says the script isn't executable
<antoniu> however I packaged it using dkms
<Corey> If I have a .install file that I'm trying to place a templated config file in, can I have .install rename the file as well?
<jtaylor> no
<directhex> debian/install cannot rename files
<Corey> Then what's the proper way to have a file renamed during package creation from a tarball?
<jtaylor> use mv in rules
<Corey> jtaylor: And that'll take effect after the file is copied into place?
<directhex> it'll take place at the point you put it in in your rules file
<directhex> i.e. if it happens before dh_install it'll happen then. after -> after
<Corey> Hm, there's no dh_install in my rules file.
<Corey> is there a dh_postinstall?
<jtaylor> you can override it
<jtaylor> override_dh_install:
<jtaylor>   dh_install
<jtaylor>   #do more stuff
<jtaylor> assuming a dh-7 like package
#ubuntu-motu 2012-01-22
<Corey> Indeed.
<directhex> i'd do whatever jtaylor says, he's good at this stuff
<Corey> Hmm.  Looks like it'd make more sense for me to do it after setup.py runs, before the install is done.
<Corey> Indeed.
<technoviking> why do I get this error Could not find a signing program (pgp or gpg)!
<directhex> you don't have gnupg installed?
<technoviking> directhex: never mind I'm an idiot
<jfi> Hello, bug 919959 is a trivial one to review and avoids a systematic crash on startup. It will be nice if someone can sponsor it. Thanks!
<ubottu> Launchpad bug 919959 in psensor (Ubuntu) "psensor crashed with GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported" [Medium,Confirmed] https://launchpad.net/bugs/919959
<jtaylor> I can't reproduce it
<jfi> jtaylor, with precise and psensor 0.6.2.16 package?
<jtaylor> oh it got an update today
 * jtaylor updating
<jfi> yes, there is an update which is introducing gtk3 instead of gtk2 (and appindicator has been kept in gtk2 flavour)
<jfi> you also need to run psensor with a DE with appindicator gtk3 like unity
<jtaylor> gna 15mb translation update ...
<jtaylor> and another python update, this will still take a while
<jfi> sorry about that:(
<bkerensa> nom nom
<jtaylor> jfi: confirmed and fix appears to work
<jtaylor> I'll upload it
<jfi> jtaylor, thanks for your very fast sponsoring!
<jtaylor> thanks for your contributuion
<bkerensa> :)
<bkerensa> gj
<bkerensa> jtaylor: Quick question if your around..
<jtaylor> bkerensa: ?
<bkerensa> jtaylor: I submitted two patches for some typos to upstream but I just remembered that I used my precise chroot to do all the work... Should I redo or does it matter?
<jtaylor> who would typo fixes be affected by the distribution you used?
<bkerensa> hmm? Both Upstream and Ubuntu
<Laney> you mean they may have since been fixed upstream or?
<bkerensa> Im a bit confused
<bkerensa> jtaylor: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608647
<ubottu> Debian bug 608647 in a2ps "Typo in package description: "down loading"" [Minor,Open]
<bkerensa> It originates from Ubuntu though and was forwarded
<Laney> I don't think you should imply that you'd NMU for that :P
<Laney> probably best to leave the changelog out
<bkerensa> it added it automatically
<jfi> micahg, Hello, I have a comment about your psensor patch (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/psensor/precise/revision/8#debian/patches/drop_g_thread_init.patch), my understanding of the glib documentation is that g_thread_init is useless since glib 2.32 but precise is using glib 2.31. Did I miss a point? Precise is going to move to glib 2.32?
<micahg> jfi: 2.31 is the devel branch for 2.32
<jfi> micahg, ok, I did not know. I have changed the source code to call or not g_thread_init depending on the glib version, so it will avoid the need of your patch in the ubuntu package.  Thanks for the information
<micahg> jfi: wfm, thanks
<micahg> jfi: here's the API doc link in case you're interested: http://developer.gnome.org/glib/2.31/glib-Deprecated-Thread-APIs.html#g-thread-init
<jfi> micahg, yes, that's the piece of doc that made me think that g_thread_init should not be called since 2.32 and not 2.31:)
<jfi> I was just missing the information that 2.31 is dev branch for future 2.32
<bkerensa> Having some issues building a package if anyone wants to have a look http://paste.ubuntu.com/813287/
<micahg> bkerensa: more context please
<bkerensa> micahg: I'm packaging something from scratch and when I do debuild that error is emitted
<bkerensa> something about illegal PACKAGE name character
<micahg> bkerensa: do debian/changelog and debian/control have a source package name in them?
<bkerensa> micahg: Yes
<bkerensa> micahg: tada :P I forgot to finish changelog
<Rhonda> I am currently building wesnoth-1.10.  It will be a new source package, but I want to have it in precise.  Whom do I have to sl... well, be gentle to for that to happen? :)
<Laney> nobody, just sync it
<Rhonda> What's the date limit again?
 * micahg loves syncpackage
<micahg> Rhonda: Feb 16
<Laney> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<Rhonda> gives me some time, thanks :)
<Rhonda> I told a neighbour that I will do some special care for precise. Hope I can manage
<Laney> FF is fairly flexible for stuff like games anyway
<Rhonda> backports too?  ;)
<Rhonda> People will want 1.10 in older releases
<micahg> backports is pretty easy for new sources
<technoviking> can someone just me some help why a package I'm working on with this control file, detect dependencies but does not install them
<technoviking> http://paste.ubuntu.com/813499/
<tumbleweed> technoviking: sorry, can you be a little clearer in your question
<tumbleweed> what do you mean by "detect dependencies but does not install them"
<technoviking> when I install the package I have to do a apt-get install -f for the dependencies the package needs to install
<Laney> install it how?
<tumbleweed> technoviking: yes, that's to be expected
<tumbleweed> dpkg doesn't install dependancies
<Rhonda> dpkg -i just installs what you give it
<Rhonda> dpkg isnt apt
<Rhonda> there is â¦ wajig? for that job.
<Rhonda> never used it myself though
 * ajmitch used gdebi for that
<Laney> I believe the software centre does it if you double click on them too
<Laney> (but I've never done that myself)
<ajmitch> anything that uses libapt or similar, really
<jtaylor> if you are willing to wait a minite for the thing to start up
<Laney> it's the default association for debs isn't it?
<jtaylor> yes
<bkerensa> blah: http://paste.ubuntu.com/813517/
<jtaylor> that paste is not very helpful
<bkerensa> jtaylor: What might be more helpful?
<bkerensa> :)
<jtaylor> the complete error including commandline
<bkerensa> jtaylor: http://paste.ubuntu.com/813523/
<jtaylor> -O6 is interesting
<jtaylor> which compiler has so many optimization levels? ..
<bkerensa> joystick.h is present
<bkerensa> jtaylor: Hmm?
<l3on> hey guys.. anjuta-extras has unmetdep in precise, due to Depends: ... anjuta (<< 3.3)
<l3on> while precise has 3.3.4-0ubuntu2
<jtaylor> I see no error on the commandline, must be a missing library
<l3on> so... what we should do ?
<micahg> update it?
<l3on> what do you mean?
<l3on> I mean... we should change the ubuntu version ?
<l3on> importing a new diff ?
<micahg> update anjuta-extras for precise
<l3on> s/importing/creating
<l3on> ah ok, :)
<Laney> naughty of whoever updated anjuta without caring for the extras though
<micahg> indeed
<l3on> and guys.. I think I solved the FTBFS of radar2-bindings
<l3on> I changes build-deb from python-dev to python-all-dev, including python2.6-dev
<l3on> do you think it is a good fix
<l3on> ?
<micahg> python2.6-dev will be going away
<l3on> the FTBFS is something like "Python.h not found"
 * micahg sees no such package
<l3on> sorry, radare2-bindings
<l3on> anyway.. seems that it builds fine in debian... I'm looking into deeper
<jtaylor> I recall fixing radare2 a while ago
<jtaylor> (via sync)
<micahg> nope, didn't build
<jtaylor> but probably thats unrelated?
<l3on> i'm trying a simple rebuild without anychanges
<l3on> ok it builds fine
<l3on> radare2 I mean
<l3on> I'm going to update a build1 version ?
<micahg> radare2-bindings works now, I'm going to give it back
<l3on> micahg, are you doing that ?
<micahg> yep
<l3on> ok
<micahg> it's been done :)
<l3on> okioki
<micahg> jtaylor: you did fix radare2
<jtaylor> micahg: fixed=I forwarded a patch to debian, the maintaienr fixed it and I syncted it
<micahg> I was being brief about it :)
<bkerensa> jtaylor: All I can find is http://ubuntuforums.org/showthread.php?t=949159
<bkerensa> which suggests just changing some code but they dont indicate which file in source
#ubuntu-motu 2013-01-14
 * Laney grumbles at broken udt stuffs
<tumbleweed> right, i never got there last night
<tumbleweed> bdrung: what was your problem with the formatting from logging?
<Laney> seems like it would have been nice to check that nothing got broken before updating devscripts
<tumbleweed> I can go with that :P
<Adri2000> is it a problem that an uploader uses obviously a nickname instead of his realname in debian/changelog?
<Zhenech> not in debian
<Laney> no, I don't think so
<micahg> as long as the e-mail address is valid, I don't see a problem
<tumbleweed> I do encourage people to use real names, when sponsoring their uploads
<xnox> Adri2000: they do and should if they are under 18
<ogra_> uploader entires are usually tied to a gpg key ... hard to get that signed if you dont use a real name
<ogra_> (at leas it should be hard to get signed :) )
<micahg> ogra_: if it's sponsored, it shouldn't matter (it's signed by the sponsor)
<micahg> but, I think encouraging real names is a good thing
<ogra_> well, the original request said uploaders
<ogra_> yeah, ++
<Adri2000> yeah, the context is about sponsoring an upload of someone not using his real name
<mint> could you help me, please?
<mint> is someone there?
<bdrung> tumbleweed: it added stuff that i didn't want to the output and/or printed it on the wrong output (stdout/stderr)
<aboudreault> can I use quilt import with a patch that contains a new file?
<aboudreault> or I have to pre-add that file in a patch before
<jtaylor> new files are fine
#ubuntu-motu 2013-01-15
<tumbleweed> bdrung: just got around to looking at udt logging
<tumbleweed> I agree, python logging isn't a sensible thing to use here
<tumbleweed> we should just bundle a copy of devscripts.logger again, I think
<bdrung> tumbleweed: okay, bundling our logger to udt sounds like the better than any other solution i came up with
<achiang> when using schroot, and issuing say, "sudo sbuild -j 4  -A --arch armhf -d precise foo*.dsc", does that unpack the sources every time?
<vagrantc> anyone know the next steps for the SRU for: https://bugs.launchpad.net/pithos/+bug/988395
<ubottu> Ubuntu bug 988395 in pithos (Ubuntu Oneiric) "Pandora v34 API Update Required" [High,Triaged]
<RAOF> vagrantc: The SRU team will get to pithos in the unapproved queue, then someone needs to test it from proposed.
<vagrantc> ok, thanks.
#ubuntu-motu 2013-01-16
<micahg> achiang: yes, and I'd suggest adding yourself to the sbuild group so you don't have to use sudo to build something
<achiang> micahg: is there a way to make it not unpack the *.dsc?
<RAOF> achiang: To make sbuild not unpack the .dsc? How would that work?
<achiang> RAOF: use a directory that's already unpacked?
<RAOF> I don't believe that's possible, no.
<RAOF> It's also somewhat against the spirit of what sbuild is trying to do, anyway. The unpacked directory is not necessarily the same as what the .dsc specifies.
<achiang> interesting
<RAOF> I mean - there's no guarantee that you haven't made extra changes to the unpacked source directory. Not that unpackig a .dsc is non-deterministic.
<dholbach> good morning
<geser> good morning dholbach
<dholbach> hey geser
<dholbach> Laney, tumbleweed, <anybody else>: would you be interested in giving a session about working with debian/upstream? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable
<dholbach> could anyone imagine demo'ing how to fix a few small bugs?
<dholbach> we still have a couple of slots open
<astraljava> Hey Daniel, hippo b-day! :)
<dholbach> thanks astraljava
<tumbleweed> dholbach: signed up for two sessions (I'd put them next to each other, but that won't fit my schedule)
<tumbleweed> (also, happy happy)
<dholbach> tumbleweed, erm... what about the schedule? anything I should change in the schedule somewhere?
<dholbach> thanks tumbleweed :)
<tumbleweed> I'd have taken 17 and 17:30 on thursday, but that clashes with my life, so spread them over two days
<dholbach> ahhhh ok
<dholbach> perfect
 * dholbach hugs tumbleweed
<tumbleweed> np
<Laney> dholbach: wb!
<dholbach> hey Laney :)
<Laney> good hols?
<dholbach> very much so :)
<Laney> excellent
<dholbach> how about yourself?
<Laney> yes, very nice - being in Snowdonia for new years was the highlight :-)
<bkerensa> Can someone direct me to info on how to remove patch fuzz from a package I am trying to build?
<bkerensa> http://paste.ubuntu.com/1537120/
<Laney> quilt refresh it in the source package
<Laney> after verifying it applied correctly
<dupondje> Somebody around that could help me a bit with autoconf?
<dholbach> would anyone be available to demo a small bug fix or two? we have one 30m slot left: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable
<dholbach> should be easy to do and much appreciated by new contributors
<Rhonda> Hmm, what was the IRC channel of the canonical sysadmin team?
<Laney> #canonical-sysadmin ;-)
<Rhonda> *blinks*
<Rhonda> That's â¦ embarassing. Thanks. :)
<hyperair> these days do we still use revu and require two sponsors' ack?
<geser> hyperair: I don't think so, though reviews by other (team) members are still recommended
<hyperair> hmm, okay.
<hyperair> does anyone want to review diodon then?
<hyperair> https://launchpad.net/~sao/+archive/ubuntu-testing/+files/diodon_1.0.1-0ubuntu3.dsc
<hyperair> oh hang on, i think he's working on another version
<hyperair> sao: o/
<geser> a cdbs package? any specific reason to not use dh? (or doesn't dh support waf?)
<sao> geser: dh does not have waf support as far as I know
<geser> sao: ok, you might also check on the requirements for using waf by the archive admins
<geser> especially if you want to include the package later also in Debian
<sao> geser: have done so. waf source code is included in the orig tarball.
<geser> ignore me then :)
<sao> geser: hyperair had some comments about unnecessary libdiodon0 deps and missing Multi-Arch field. Updated version is now here: https://code.launchpad.net/~diodon-team/diodon/ubuntu-packaging
<sao> can upload it to my ppa again if necessary
<cjohnston> Greetings... Question on bug #1022024, I'm thinking it should be marked high and tagged as regression-update, could someone please look and comment if they agree/disagree.
<ubottu> bug 1022024 in roundcube-plugins-extra (Ubuntu) "unmet dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/1022024
<Laney> cjohnston: How's it a regression in -updates? At least roundcube and -plugins-extra have no SRU
<tumbleweed> urgh did someone say waf?
<geser> tumbleweed: sao is packaging an app using waf
<cjohnston> Laney: ok, so update is when its from an sru. the wiki just said stable release, which I figured thiswas as it is, well, released. my misunderstanding
<Laney> cjohnston: Nah, that's what regression-release is for
<Laney> https://wiki.ubuntu.com/QATeam/RegressionTracking
<Laney> anyway that is worth fixing so I'll look at your patch now
<cjohnston> ok
<cjohnston> so is it  -release or no?
<cjohnston> ty
<Laney> bdrung: is sponsor-patch supposed to work out the target release?
<bdrung> Laney: yes
<Laney> hmm
<Laney> could it be that it requires '-proposed'?
<bdrung> for stable releases, yes
<Laney> I see
<Laney> that's not necessary any more
<Laney> also it just tried to download the raring package; should have errored out instead or at least warned?
<bdrung> it determines the target from the bug series
<bdrung> for SRUs, there should be a open bug against the stable series
<Laney> ah, doesn't look at the changelog
<Laney> now I see the prompt
<Laney> bah
<Laney> it wasn't signed, so dput failed, so sponsor-patch failed and deleted its working files
<bdrung> normally sponsor-patch ask if you want to fix an failure manually instead of exiting
<Laney> Error: upload of â¦ failed
<Laney> then it exited
<bdrung> file a bug
<Laney> already doing
<Laney> cjohnston: I uploaded it but you'll need to fill in the SRU information in the bug description before it gets accepted
<Laney> thanks for the fix
<TheLordOfTime> if i created a patch for https://bugs.launchpad.net/ubuntu/+source/oidentd/+bug/1094773 that changes its /etc/init.d/ file to add the -l 10 option, would that be acceptable for SRU?  I'm asking here because its a Universe package.
<ubottu> Ubuntu bug 1094773 in oidentd (Ubuntu) "oidentd spawns a new process for all new connections unless -l [number] defined" [Undecided,New]
<dholbach> all right, who would like to demo fixing a bug in a 30m session at UDW? 31st Jan, 18:30 is the last slot we've got to fill: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable :)
<TheLordOfTime> dholbach, can you answer a universe bug question regarding acceptable patching?
<TheLordOfTime> unless i missed a response to my prior question.
<dholbach> TheLordOfTime, there should be no difference between main and universe in the criteria for SRUs as far as I can see
<TheLordOfTime> dholbach, my question was whether changing the default /etc/init.d/ file is a valid solution as a SRU/patch.
<TheLordOfTime> because in one sense its a workaround without removing the problem, and in another sense it is the easiest solution to the problem.
<dholbach> TheLordOfTime, I don't know - somebody in the server team might know
<dholbach> try #ubuntu-server maybe?
<TheLordOfTime> yeah well i've got higher-priority bugs, such as an nginx security bug i'm watching closely
<TheLordOfTime> which reminds me, i should set that oidentd bug as 'low'...
<cjohnston> Laney: could you please look at it again and let me know if that works
<Laney> looks good, thanks
<cjohnston> Laney: what else do I need to do with it? From the wiki page it looks like I'm done
<Laney> yep, a magical SRU team elf should come along and process it at some point soon
<cjohnston> an elf.. cool
<cjohnston> lol
<cjohnston> thanks for your help Laney
<achiang> can i find a sponsor for https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1093511 ? it's sat around for a few weeks now...
<ubottu> Ubuntu bug 1093511 in remmina (Ubuntu) "please merge remmina 1.0.0-4 (main) from Debian testing" [Wishlist,Confirmed]
<jtaylor> so many python m-a build failures ...
<jtaylor> can someone remind me what we need this for again?
<jtaylor> is this also intended for debian?
<jtaylor> hm it probably already is, nice
#ubuntu-motu 2013-01-17
<cjohnston> Is bug #813511 worth patching? It was fixed upstream >1 year ago, I guess there is a disconnect somewhere between upstream and making it into Ubuntu.
<ubottu> bug 813511 in gstreamer0.10-editing-services (Ubuntu) "typo on --help output of ges-launch-0.10" [Undecided,Confirmed] https://launchpad.net/bugs/813511
<cjohnston> Or, what is the correct way to go abour the bug?
<gilbert> hey everybody :)
 * micahg thinks he's going to try to get rid of vala-0.14...
<micahg> jdstrand: do you have any interest in merging hamster-applet?
<dholbach> good morning
<bkerensa> is requestsync depracated?
<geser> no, why?
<geser> but there is no need to use requestsync if you have upload rights and can sync the package yourself
<xnox> bkerensa: there is requestsync (when one doesn't have upload rights) and syncpackage (for sponsoring or when one does have upload rights)
<bkerensa> xnox: http://paste.ubuntu.com/1540656/ <-- I get that error with requestsync
<bkerensa> output even
<xnox> bkerensa: please upgrade devscripts package to the one that fixed that.
<xnox> 2.12.6ubuntu1 is bad, 2.12.6ubuntu2 or 2.12.6 are good
<Laney> yeah that is a good fix
<Laney> thanks for doing that
<bkerensa> xnox ok
<xnox> Laney: np.
<Laney> both of them aren't forwarded to debian #680313 yet though ;-)
<ubottu> Debian bug 680313 in devscripts "devscripts: support python 3 (hopefully dropping strict python2.7 dependancy)" [Wishlist,Open] http://bugs.debian.org/680313
<bkerensa> Laney: well ya know submittodebian acts funky with changes ;)
<Laney> hmm?
<bkerensa> cjohnston:  bug #813511 the reason the fix has not landed in Ubuntu is because we appear to sync the package unchanged from debian and debian has not updated the package from upstream
<ubottu> bug 813511 in gstreamer0.10-editing-services (Ubuntu) "typo on --help output of ges-launch-0.10" [Undecided,Confirmed] https://launchpad.net/bugs/813511
<bkerensa> Laney: Bug #1021917
<ubottu> bug 1021917 in ubuntu-dev-tools (Ubuntu) "[submittodebian]'s update-maintainer reversal isn't always the right thing to do" [Undecided,Confirmed] https://launchpad.net/bugs/1021917
<Laney> how's that related to the devscripts patches?
<bkerensa> Laney: well whoever fixed it could have used submittodebian but it sometimes reverses the maintainer info
<Laney> sounds annoying but not really something that would block patch forwarding
<Laney> anyway, you sound like you plan on fixing it ;-)
<tumbleweed> bkerensa: that bug was caused by an attempt to fix that bug
<tumbleweed> I made it reverse the maintainer info, when it used to not reverse it, and vice-versa
 * Laney doesn't really use submittodebian so can't comment
<Laney> it's about the only time I remember to set those usertags though
<tumbleweed> most of the time I want to set other usertags too, but you can only set one usertag on submission
<Laney> even with the fancy Control: headers?
<Laney> haven't used those so much either
<tumbleweed> hrm, can one use those at submission?
<Laney> yep
<jdstrand> micahg: re hamster-applet> if you want to merge it, go ahead. I would likely get around to it sometime (not this week)
<aboudreault> any java expert? Trying to build something that uses maven... but when building in pbuilder... we have an error related to  the fact that maven tries to find /root/.m2/settings.xml
<aboudreault> what's the proper way to  build something with maven?
<Laney> can I update the timestamp but keep the name/email when doing dch --release?
<micahg> Laney: dch -r -m
<Laney> ah, interesting
<Laney> I only knew about -t
<micahg> Laney: are there any plans to migrate to ghc 7.6?
<Laney> yeah
<Laney> they all start with "Laney needs to find some time to figure out how complete it is in Debian"
<micahg> I was thinking we should set up a copy of the tracker pointed at proposed so that we can see how installable both sets are
<Laney> they all already point at proposed
<micahg> ah, ok
<Laney> i'll set one up pointing at /experimental/ soon hopefully
<micahg> I think we need a copy pointing at the release pocket as well then
<Laney> why?
<micahg> unless britney properly understands haskell reverse deps
<Laney> pretty sure it does
<Laney> probably will require some hinting, but that's fine
<psusi> so if I want to test a program's output in german, isn't it sufficient to install languagepack-german, then export LANG=de?
<blkperl> Can I get some feedback on this http://goo.gl/eUqY6 Thanks!
#ubuntu-motu 2013-01-18
<ScottK> TheLordOfTime: Kubuntu and many other flavors are LTS.  I don't know where you get the idea it's Ubuntu only.
<TheLordOfTime> ScottK, i was told by someone else it was only Ubuntu that got the LTS tag
<TheLordOfTime> they gave me bad info
<ScottK> OK
<dholbach> good morning
<quidnunc> Is prevu no longer maintained?
<Laney> no
<Laney> it was removed after oneiric
<quidnunc> Laney: Is there a replacement?
<ScottK> backportpackage is probably closest
<Laney> backportpackage in ubuntu-dev-tools does pretty much the same job
<Laney> apparently we still have wiki pages talking about prevu
<quidnunc> ScottK, Laney: I can't build local source with backportpackage right?
<quidnunc> I want pbuilder for that, right?
<jtaylor> yes
<Laney> backportpackage can call pbuilder or sbuild for you
<jtaylor> or cowbuilder
<Laney> ...
<quidnunc> Laney: Yes but it can only build source fetched from a particular release not source fetched from elsewhere or modified locally
<ScottK> Right, but if you've got it locally, pbuilder is all you need.
<quidnunc> ScottK: Thanks. I always used prevu for everything so I am not familiar with nuances between different package building tools
<Adri2000> siretart: hi. I've got one of the packages I maintain in debian that fails to build in experimental because of "/usr/lib/x86_64-linux-gnu/libavcodec.so.53: undefined reference to `ff_sqrt_tab@LIBAVUTIL_51'". it does not depend directly on libav*. do you think you can help?
<xnox> Adri2000: URL to full build log is usally preffered for build failures.
<xnox> otherwise it's hard to understand what/where/why is hapeening
#ubuntu-motu 2013-01-19
<Adri2000> xnox, siretart: http://adrishost.net/~adri2000/debian/actionaz-experimental-libav-ftbfs-buildog.txt
<xnox> no clue.
<xnox> but Adri2000 one should not use  -std=gnu++0x  as it's not stable yet, and can break in the future.
<Adri2000> I think the program itself needs it. at least I don't recall forcing that option in the package
<Adri2000> regarding the build failure, I didn't notice something until now: the build-deps resolving outputs some interesting stuff about libav* packages
<vorian> motu in the hizzy
<siretart> Adri2000: for some reason, this build installs both libavutil51 and libavutil52. that's bad
<siretart> Adri2000: also, why the heck does your buildlog indicate that libavcodec-extra-54 gets installed? that is also not supposed to happen
<siretart> Adri2000: yeah, there is indeed a dependency problem in 6:9.1-1. I'll fix it in 6:9.1-2. not sure if this will help your package, but please let me know
<cjohnston> is anyone around who could take a look at my patch and provide me with advise?
#ubuntu-motu 2013-01-20
<micahg> cjohnston: which patch?
<siretart> Adri2000: fixed libav arrived in experimental, please try again
<Quintasan> \o
<Adri2000> siretart: the dependency problems with libavcodec54 disappeared, libavutil51 and 52 are still both installed, and it fails for the same reason in the end :( http://adrishost.net/~adri2000/debian/actionaz-experimental-libav-ftbfs2-buildog.txt
<siretart> Adri2000: uh sh*t. i guess you found something serious here. let me investigate more
<siretart> Adri2000: what package is this?
<siretart> Adri2000: I don't get this. there is no occurance of  ff_sqrt_tab in libavcodec53. still your build log bitches about this. please investiage what exactly requires ff_sqrt_tab@LIBAVUTIL_51.
<Adri2000> siretart: package is actionaz, and I'm trying to build the version in http://anonscm.debian.org/gitweb/?p=collab-maint/actionaz.git;a=summary (latest master)
<Adri2000> (or latest commit in 'debian' branch, rather)
<Adri2000> # objdump -T /usr/lib/x86_64-linux-gnu/libavcodec.so.53 | grep sqrt
<Adri2000> 0000000000000000      DO *UND*	0000000000000000  LIBAVUTIL_51 ff_sqrt_tab
<Adri2000> siretart: that's what I have in my pbuilder-experimental, after installing libavcodec53
<siretart> Adri2000: uh right, now I see what's going on
<siretart> Adri2000: the problem is  libavutil51_6:9~beta1-1
<siretart> that version is known to be broken, and has been superseeded by libavutil52
<siretart> fortunately, the is also NBS, so ftp-master can safely remove it. your package should be able to build again once that happened
<siretart> Adri2000: please poke debian's ftp-master to NBS libavutil51_6:9~beta1-1 in experimental. that should do the trick
<Adri2000> siretart: ok, will do that, thanks for the help
<mikodo> Can we please have Potamus back in the repos. I have it in 10.04 very nice. It is not in 12.04  Here it is  http://offog.org/code/potamus.html     Thanks!
<TheLordOfTime> mikodo, research shows it was removed in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615644
<ubottu> Debian bug 615644 in ftp.debian.org "RM: potamus -- RoQA; orphaned, unused, alternatives exist" [Normal,Open]
<TheLordOfTime> MOTU want to shed light on whether the same reason was why its not in Ubuntu?
<TheLordOfTime> (and AFAICT, it does have alternatives in the repos, and a good number of them)
<ajmitch> same reason, removals from debian are usually done in universe as well
<TheLordOfTime> that's what i thought, but i wasn't sure ;)
<ajmitch> you can see it on https://launchpad.net/ubuntu/+source/potamus/+publishinghistory
<TheLordOfTime> E: timeout :/
<ajmitch> wfm
<TheLordOfTime> ah there it is.
<TheLordOfTime> Removal requested on 2011-05-05. | Deleted on 2011-05-05 by Steve Langasek | (From Debian) RoQA; orphaned, unused, alternatives exist; Debian bug (see above lines here on IRC)
<ajmitch> basically it got no love in debian & noone stepped up to maintain it
<TheLordOfTime> makes sense to me :P
<TheLordOfTime> and they are right though: there's a TON of alternatives
<TheLordOfTime> s/TON/lot/
<mikodo> Hey guys thanks for the info. I have never compiled. Should I try, or by it not being maintained does it mean it might be buggy now and might not be worth the effort?
<TheLordOfTime> mikodo, upstream seems maintained...
<mikodo> TheLordOfTime,  So, might be worth my effort then. Thanks
<TheLordOfTime> potamus-14.tar.gz	06-Dec-2012 13:52 	159K <-- latestupload on thier site
<TheLordOfTime> and yes, they have directory listing on
<TheLordOfTime> i should slap them for that...
<TheLordOfTime> since that's insecure...
<TheLordOfTime> mikodo, i'd just build it from source by hand, i agree with the debian bug that there's a good number of alternatives which exist.
<TheLordOfTime> and since its kinda not in debian, well... :P)
 * TheLordOfTime shifts attention back to figuring out why apt-mirror's timing out on mirroring from the regional archive.
<TheLordOfTime> s/regional archive/regional mirrors/
<mikodo> TheLordOfTime, I like it and I am going to build for the learning exp.
<zequence> 26
<TheLordOfTime> have fun mikodo
<mikodo> TheLordOfTime, Thx. buddy
<TheLordOfTime> hmm.... i should probably ask in -server, but have any of you ever had apt-mirror fail to mirror from a regional mirror, whereas the system its on is able to apt-get update/apt-get upgrade from the same server that apt-mirror's trying to mirror?
#ubuntu-motu 2014-01-13
<dholbach> good morning
<geser> good morning
<dupondje> Could somebody sponsor https://bugs.launchpad.net/ubuntu/+source/opensc/+bug/1252254 ?
<ubottu> Ubuntu bug 1252254 in opensc (Ubuntu) "OpenSC fails to authendicate with firefox" [Undecided,Confirmed]
<geser> dupondje: subscribe the ubuntu-sponsors team, I don't know if the ubuntu review team is still operational
<dupondje> k
<dupondje> done :)
<geser> do you think this should be fixed in saucy too or is fixing it only for trusty "enough"?
<dupondje> geser: well it doesn't hurt to patch it in saucy also, cause its prolly broken there also
<geser> I've opened a saucy task for it then
<dholbach> micahg, about the ubuntu-uploaders team... do they have voting rights for the TB or will that stay with just ubuntu-dev?
<dholbach> micahg, can the ubuntu-uploaders team get an emblem please? just so it's easier to see if somebody is an uploader or not
<dholbach> micahg, I don't care too much what is put up there, maybe just use a wrench symbol that's in /usr/share/icons somewhere until somebody comes up with anything better
<jtaylor> is there a way to get who synced a package?
<Zhenech> shouldnt lp know who sponsored the upload?
<Logan_> jtaylor: https://launchpad.net/ubuntu/<release where synced>/+source/<source package name>/<version of synced package>
<Logan_> For example: https://launchpad.net/ubuntu/trusty/+source/yade/1.05.0-2
<Logan_> "Copied from debian sid in Primary Archive for Debian GNU/Linux by Jackson Doak (sponsored by Logan Rosen)"
<jtaylor> doesn't work for spatialindex which has been autosynced since :/
<Logan_> I think that was me, lol.
<jtaylor> oh no its there
<jtaylor> it was you .)
<Logan_> What's up?
<jtaylor> just a comment, check the fix before syncing, it was broken :)
<jtaylor> fixed in -2
<jtaylor> which is autosynced now
<Logan_> I synced -2.
<jtaylor> oO
<jtaylor> oh sorry then
<jtaylor> that was fast
<Logan_> No worries. :P
<jtaylor> I only just got the close message
<Logan_> We never had 1.8.1-1 in Trusty.
<Logan_> I did it 15 hours ago! :P
<jtaylor> I looked at the general source not trusty
<jtaylor> that says (sponsored by Ubuntu Archive Robot)
<Logan_> Ah.
<jtaylor> so i thought -1 was already synced
<Logan_> Yeah, that's for release.
<jtaylor> how did you find this sync?
<jtaylor> you look at mergomatic often?
<jtaylor> I notice someone steals my syncs, probably you :P
<jtaylor> I only check it every few weeks :/
<jtaylor> "steals" I don't mind of course :)
<Logan_> It was actually because I introduced a delta.
<Logan_> On top of the delta, I think.
<Logan_> Fixing an FTBFS on ppc64el.
<Logan_> I submitted the patch to Debian, and then it was closed. So it showed up with my name on MoM. :P
<jtaylor> a right
<Logan_> Since it fixed the previous delta as well, I synced.
<Logan_> Oh, I'm basically a felon when it comes to stealing syncs. Working on that, though.
<cjwatson> I'm not sure stealing syncs is generally a problem - TIL status will be lost either way and any duplicated work is often (not always of course) fairly trivial
<cjwatson> obviously only if one gets it right :)
<jtaylor> Logan_: sweet you also closed the bug :)
<Logan_> :D
<jtaylor> nice work
<Logan_> Thanks. :)
<Logan_> cjwatson: Well, one person raged at me for taking their sync because apparently they were testing it just as I synced, but that's the only complaint about syncs that I've gotten. Merges are more controversial. :P
<jtaylor> in this cause it wasn't even "my" sync, I didn't fix it in ubuntu like I though I did :/
<Noskcaj> Did the dbm discuss my motu membership at the meeting last night
<cjwatson> irclogs.ubuntu.com
<Noskcaj> so, nope
#ubuntu-motu 2014-01-14
<work_alkisg> Hi, a packaging question please? Packages A, B, and C are not installed on a system, and they all Provide: P.
<work_alkisg> Each of them Depends: on a different package, e.g. a, b, c. Packages a and b are not installed on that system, but package c is.
<work_alkisg> If I try to install package X, which Depends: P, will apt be smart enough to select the C package that doesn't require additional packages (a or b) to be installed?
<Zhenech> alkisg, i think not.
<alkisg> Thank you Zhenech
<dholbach> good morning
<iulian> Good morning dholbach.
<dholbach> hi iulian
<fr33r1d3> Q: Best place to start contributing to Ubuntu. Is it Ubuntu Touch?
<s1aden> fr33r1d3: perhaps there is an programme/application you use, that you have a niggle with and thing could be improved
<s1aden> fr33r1d3: having a goal makes knowing where to start much easier, as you can research and work towards adding the feature/bug that you want to see
<micahg> dholbach: no, this new team won't have voting rights, yes, I'll get an icon up there, right now, all uploaders are still in ubuntu-dev anyways
<dholbach> thanks
<TheLordOfTime> I can request merges of packages to Trusty from Debian up to when?  Feature Freeze?
<cjwatson> yes.  after that it's still possible but will require a consideration of whether there are feature changes; if there are then it would need an exception granted by the release team
<cjwatson> but up to FF with no paperwork
<TheLordOfTime> that's what i thought
<michagogo|cloud> What would need to be done to propose an SRU that essentially removes Bitcoin from the repos for (precise..saucy)?
<michagogo|cloud> If I understand correctly, while actually removing it is not possible, it would be possible to have an "update" that removes its functionality.
<michagogo|cloud> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<TheLordOfTime> In general, if I find a patch to fix an FTBFS of something that's in universe that's in the CURRENTDEVRELEASE-proposed repository, how do I get the patch into the system?  Open a bug, attach the patch/debdiff, and poke sponsors?  Or is it a different method?
<TheLordOfTime> (where CURRENTDEVRELEASE is ubuntu+1 prior to freezes and such)
<TheLordOfTime> (i.e. trusty for now)
<Laney> that is right, where 'poke' is 'subscribe'
<TheLordOfTime> Laney: i hate it when packages break because GTK 3.10+ causes code to fail and features in the code to be deprecated (case in point, source: wireshark)
<TheLordOfTime> (this is a tricky FTBFS that i'm trying to get to build, but meh.)
<TheLordOfTime> (in case yo uwere curious why i'm asking)
<TheLordOfTime> s/asking/asking about the "fix an ftbfs in develrelease-proposed" thing/
#ubuntu-motu 2014-01-15
<TheLordOfTime> how are FTBFS bugs' importance decided?
<TheLordOfTime> oop, meant that for -bugs :/
<dholbach> good morning
<Laney> TheLordOfTime: It'd be good to have upstream use -Wno-error=deprecated-declarations for that reason
<TheLordOfTime> Laney: *shrugs* Upstream provided a fix to fix that FTBFS, the only problem left was remnants remaining from the transition to Gtk 3.10+.  C99 `g_memmove()` is gone in glib at that version, so C90 `memmove()` ends up being what needs to be used.  Upstream is saying they'll move to Qt though, so meh.  Either way, the fix is in, so the FTBFS is resolved. *shrugs*
<TheLordOfTime> Laney: only reason I cared is that I need 1.10.5 or newer of Wireshark for this course I'm taking so that's the only real reason I was paying attention to that :P
#ubuntu-motu 2014-01-16
<dholbach> good morning
#ubuntu-motu 2014-01-17
<dholbach> good morning
#ubuntu-motu 2014-01-19
<Unit193> I'd presume that we can't rename chromium-browser to chromium now?  (chromium used to be what is now chromium-bsu) so that it's the same package as in Debian? (And, which happens to make http://paste.openstack.org/show/2jJUyLNYahovEj31B8FG/ unneeded for pepperflashplugin-nonfree)
#ubuntu-motu 2015-01-13
<dholbach> good morning
<Rhonda> http://www.sweethome3d.com/freeModels.jsp - "Ubuntu clock", wtf. :)
#ubuntu-motu 2015-01-14
<dholbach> good morning
<Laney> dholbach: hey, do you know if the sponsor queue is automatically pulled from bzr when it updates or is that manual?
<dholbach> I can't quite remember
<Laney> not sure if the change I made yesterday is in effect
<Laney> do you (do I) have access to check?
<dholbach> I need to check
<Laney> ok
<dholbach> hum, looks like I don't have access to it any more?
<dholbach> Brian could probably help
<dholbach> or I'm looking at the wrong place
 * Laney is without clue
<dholbach> Laney, updated it
<Laney> dholbach: thanks!
#ubuntu-motu 2015-01-15
<dholbach> good morning
#ubuntu-motu 2015-01-16
<dholbach> good morning
<dholbach> lan3y, css is fixed - thanks to mitya57
<lan3y> thanks dholbach
<lan3y> cool nickname (not)
<dholbach> l33t
<highvoltage> dholbach: happy birthday!
<dholbach> thanks highvoltage
 * nxvl birthday hugs dholbach 
 * dholbach hugs nxvl back :)
<nxvl> (yes i only joined the channel for that)
<dholbach> how are you doing?
<nxvl> dholbach: friday birthday, that usually doesn't end pretty good, really fun, but now pretty good
<dholbach> let's see
<nxvl> working like a donkey, as we all, have been packaging some debian custom packages, i forgot how FUN it was
<dholbach> we can't have a long big party anyway, we both need to get up early on Saturday :)
<nxvl> i need to find some time to get back to Ubuntu development
<dholbach> nice :)
<dholbach> it'd be great to hang out more with you again :)
<nxvl> yeah, let's see how thing turn out in the following months
<nxvl> well, anyways, only came to wish you a great birthday!
<nxvl> now back to work :D
<nxvl> gnite!
<dholbach> take care
#ubuntu-motu 2015-01-17
<jtaylor> grr was wondering why I'm losing more and more disk space in /, turns out apt-cacher-ng decides to ignore the config file and use the wrong disk :(
#ubuntu-motu 2016-01-18
 * tsimonq2 is gone: 
<Rhonda> 13:09 <ahf> openssl just released a new version with a dane API build in
<Rhonda> 13:09 <ahf> would be nice to replace libval with that
<Rhonda> openssl is in main, right?
<Rhonda> â¦ which in turn means we could finally get rid of the ubuntu diff for irssi.  \o/
#ubuntu-motu 2016-01-21
<karstensrage> hello
<karstensrage> reading this: http://packaging.ubuntu.com/html/packaging-new-software.html
<karstensrage> seems pretty straight forward but im missing a piece of understanding
<karstensrage> if im on a 12.04 ubuntu machine doing all this
<karstensrage> how would the package work if it were run on 14,04?
<Rhonda> Either out of the box, or you would need to compile it in a 14.04 environment new because of generated dependencies in the binary that aren't resolvable anymore on 14.04 from the 12.04 build
<karstensrage> Rhonda, so the package i am dealing with is a PAM module (shared lib), which "depends" on another shared lib that i wrote... so that will be two separate packages, and the first depends on the 2nd right?
<karstensrage> then the 2nd library depends on libxml2 and libssl
<karstensrage> so even though the code i wrote isnt changing across 12.04 and 14.04, the libc, and other libs are changing right?
<Rhonda> Yes.
<karstensrage> so i dont get how it works on 14.04 if everything was compiled with 12.04's libs?
<Rhonda> And depending on whether they have some abi/api incompatible changes or not you would need to recompile it on 14.04 â¦ or not. :)
<Rhonda> Libraries have a thing called ABI and API, which stands for Application Binary/Programming Interface.
<Rhonda> And if that is compatible (like, only gets extended, not structure changed, things dropped or similar), even when compiled against the old versions it still will work with the newer ones.
<Rhonda> Otherwise you would need to recompile every single package after an upgrade of one library, which would be highly inconvenient. :)
<Rhonda> Some libraries are known to regularly break and fumble with those interfaces, but most are quite conservative with changes in that area.
<karstensrage> so maybe i should not worry about that issue and just hope for the best?
<Rhonda> Yes.
<karstensrage> hmm ok
<karstensrage> is that link i posted the best place to get started?
<Rhonda> Take a look at the francine package.  I last uploaded it to Debian in 2005.  Which was during the etch (4.0) release cycle.
<Rhonda> We are now at Debian 8, there was no need to recompile it once since, the same binary from 10 years ago still runs on current Debian.
<Rhonda> That I don't know, I haven't read it, but it might be useful. :)
<Rhonda> Especially with respect to packaging libraries there is a bit more needed from what I know, but I never packaged a library myself, so can't help you there.
 * Rhonda . o O ( speaking of francine, working on finally updating the package to current best practices, and getting rid of my old name) )
<karstensrage> ok, thank you, that helps so far, does ubuntu have mentors that help with things?
<karstensrage> and i have to get somethign like a sponsor to actually get it into the packaging system?
<karstensrage> im getting this error and nothing is coming up on google
<karstensrage> dh_install: mylib-dev missing files (usr/include/*), aborting
<karstensrage> Rhonda, the path im taking is building two packages, one for the library and one for the pam module that depends on the library, thats correct right?
<Rhonda> Guess so, and the library needs the files in the -dev package required to build stuff against it, which means the include files.
<karstensrage> ok how do i do that?
<Rhonda> Can't mentor your with library packaging, but doesn't the library contain include files?
<karstensrage> yes
<karstensrage> yes it does
<karstensrage> how do i find someone that can mentor for libraries?
<karstensrage> i feel bad asking tbh
<karstensrage> but its really not a familiar thing to me
#ubuntu-motu 2016-01-22
<Rhonda> huhm.  I think someone sent me an update for the irssi watch file, and I believe I commited it in git, but I don't find it anymore.  >.>
<Rhonda> Ah, Unit193 was it, and I was in a different checkout.  Found it, thanks. :)
<jtaylor> hm is there something like http.debian for ubuntu?
<rbasak> What's http.debian?
<jtaylor> the proxy selecting the best mirror
<jtaylor> .net
<rbasak> Ah.
<rbasak> I'm not aware of any equivalent. IIRC the installer has something that tries to pick the best mirror, and after that it's static. It's been a long time since I saw that though.
<jtaylor> yes the installer picks
<jtaylor> at least I do always end up with a .de mirror not a us, but its a minor inconvience to have to change that each time you go significantly abroad
<jtaylor> as its static
<rbasak> I was under the impression that archive.ubuntu.com does smart things. I'm not sure though.
<jtaylor> hm I can give it a try
<jtaylor> though my relative recent wily installation has .de hardcoded in its sources
<justin_time> Hi, I have some questions about how to help to update a package, which is not in the debian sources. I'm talking about the "tomahawk" package (LP: #1487729). I'm one of the maintainer of the official tomahawk ppa and I want to help to update the package in the ubuntu sources. But I do not know how.
<ubottu> Launchpad bug 1487729 in tomahawk (Ubuntu) "Tomahawk 0.8.4 or newer [needs upgrade]" [High,Confirmed] https://launchpad.net/bugs/1487729
<karstensrage> ok i think im making some headway but could use some help
<karstensrage> mylib-dev is building properly
<karstensrage> but mylib
<karstensrage> is not
<karstensrage> in the changelog file it says mylib (1.0-1) unstable; urgency=low
<karstensrage> so it sees that -1 and created mylib1.install and mylib1.dirs
<Unit193> jtaylor: About the closest thing I know of is http://mirrors.ubuntu.com/ (You use it like  deb mirror://mirrors.ubuntu.com/de.txt wily main universe restricted multiverse )
<karstensrage> but the Package in the control file is just mylib
<karstensrage> so im not sure what to do
<karstensrage> when you do bzr dh_make, it puts the mylibBROKEN in the control file
<karstensrage> i think that might the problem
<karstensrage> not sure what BROKEN refers to or what to change it to
<karstensrage> and thats part of the mylib1.[dirs|install] problem?
<bluesabre> if any sponsors are available, can you please take a look at https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1535163 ? Please let me know if there are any questions.
<ubottu> Launchpad bug 1535163 in shimmer-themes (Ubuntu) "Please upload shimmer-themes-2.1.0-0ubuntu1 to xenial" [Wishlist,Confirmed]
#ubuntu-motu 2016-01-23
<Punkoivan> Hi everyone.
<Punkoivan> May I ask few question about package?
<Rhonda> Just ask - don't ask to ask. :)
<Rhonda> And be patiend for answers, people might be busy or not around and when you leave too soon you might not see potential answers.
<Punkoivan> Ok, it's my first time with IRC, thanks!
<teward> Punkoivan: also ask a specific question
<teward> the more vague an answer, the less useful responses you get :)
<Rhonda> teward: vague answers are often little useful responses  :P
<teward> s/answer/question/
<Punkoivan> I build deb from source with next step:
<teward> Rhonda: i'm snowed in and stir crazy, typos are likely.
<Punkoivan> 1. get source from git
<Rhonda> Oh, we have a fair amount of snow also here in vienna  \o/
<Punkoivan> In Ukraine too much to.
<Punkoivan> 2. use "dh-make -s -f sorce.tar.gz"
<Punkoivan> it's all OK, I get debian dir with files.
<Punkoivan> this files (changelog, copyright, control) I edit using manual on Ubuntu wiki and Debian wiki.
<Punkoivan> Next step - "debuild -us -uc"
<Punkoivan> It's also OK, but lintian show me few warnings and errors, about dh-template files.
<Rhonda> If you call lintian with the -i switch, it will give you further explenations, with suggestions on how to fix it.
<Punkoivan> and I find dir "build-area" which also have debian dir.
<Punkoivan> I really messed up with this dir build-area, I can't find about it neither Deb manuals and ubuntu, what is it?
<Punkoivan> ok, try call lintian with -i option, thanks!
<Rhonda> when you call debclean, does it get removed?
<Punkoivan> I decided try from begin, step-by-step with yours advises, because now my workaround like a trash.
<Punkoivan> Yeah, debclean removed build-area and other.
<Punkoivan> And lintian -i give me more information, I hope I can fix all warnings.
#ubuntu-motu 2016-01-24
<Punkoivan> Hi. Finally I got .deb package, edit copy, control, ch files, even add manpage (took away about 3 hours, I download source from repo and check example ).
<Punkoivan> have 3 lintian-warnings, as I understood it's no critical - about bug in DBS, about package name and soname and about shlib without version.
<Punkoivan> Package installed and working, but when I give wrong parameter it gives me something like this :
<Punkoivan> home/pckgbuildtest/xkb-switch-1.0/XKbSwitch.cpp:219: Condition i!=syms.end() failed. bla-bla
<Punkoivan> after it I remove app from system and install from source using cmake&make and give this error again.
<Punkoivan> so, does it mean that it error in source and I should mail to devs or it my bad?
<Punkoivan> Thanks, guys and sorry for dumb question.
#ubuntu-motu 2017-01-16
<ehoover> wgrant: any chance you have some time to chat about wine (and wine-staging) builds?
#ubuntu-motu 2017-01-17
<new> print("hola")
<elky> new: hi?
<new> spanhis?
<elky> not me :( #ubuntu-es but is support not development
<new> ok
#ubuntu-motu 2017-01-18
<new> help
#ubuntu-motu 2017-01-19
<amitprakash_> Hi, I'm trying to package a library and while I've been able to upload it to the ppa (where it built successfully), when I add the ppa and run apt update, it throws me a The repository 'http://ppa.launchpad.net/amit-prakash-ambasta/asio/ubuntu yakkety Release' does not have a Release file.
<amitprakash_> How do I resolve this?
<amitprakash_> nm, just had to give ppa time I guess
<rbasak> amitprakash_: try again
<rbasak> Right :)
<rbasak> You need to wait until it is "published"
<rbasak> The PPA pages can show you when it is.
<amitprakash_> rbasak, don't think I built correctly though, none of the headers are part of deb/data.tar.xz
<amitprakash_> And now it finally works!
#ubuntu-motu 2018-01-16
<handsome_feng> Hello everyone, if I add qt5-default to my package's build-depends, It will raise a lintian warning: build-depends-on-metapackage, but If I replace it with qt5-qmake, the build will fail, Does anyone know how to deal with this? Thanks in advance.
<acheronuk> handsome_feng: what are you trying to build?
<handsome_feng> acheronuk: The new package ukui-window-switch, now it build fail in my ppa: https://launchpad.net/~feng-kylin/+archive/ubuntu/newpackages
<acheronuk> handsome_feng: right. qt5-qmae is a dependency of qtbase5-dev, so that is not needed
<acheronuk> *qt5-qmake
<acheronuk> but you may need 'export QT_SELECT := qt5' in your debian/rules
<handsome_feng> acheronuk: Thanks, I will have a try
<acheronuk> handsome_feng: seems to build in pbuilder for me with that change
<handsome_feng> acheronuk: oh, Thank you very much! :) ps: I found that dput stuck at the last 1k...
<acheronuk> np. probably a glitch. not tried to upload anything today though...
<handsome_feng> Maybe, Thanks!
<handsome_feng> Hi, Can any  MOTUs can help to review and upload my new packages? LP: #1738919 LP: #1738947 LP: #1738976 , Thanks in advance!
<ubottu> Launchpad bug 1738919 in Ubuntu Kylin "[needs-packaging] ukui-menus" [Critical,In progress] https://launchpad.net/bugs/1738919
<ubottu> Launchpad bug 1738947 in Ubuntu Kylin "[needs-packaging] ukui-settings-daemon" [Critical,In progress] https://launchpad.net/bugs/1738947
<ubottu> Launchpad bug 1738976 in Ubuntu Kylin "[needs-packaging] ukui-panel" [Critical,In progress] https://launchpad.net/bugs/1738976
#ubuntu-motu 2018-01-17
<handsome_feng> Hi, Could someone in MOTU team help to review and upload my packages to ubuntu archive? Thanks! LP: #1738919 LP: #1738947 #1738976
<ubottu> Launchpad bug 1738919 in Ubuntu Kylin "[needs-packaging] ukui-menus" [Critical,In progress] https://launchpad.net/bugs/1738919
<ubottu> Launchpad bug 1738947 in Ubuntu Kylin "[needs-packaging] ukui-settings-daemon" [Critical,In progress] https://launchpad.net/bugs/1738947
<tsimonq2> Hey handsome_feng :)
<tsimonq2> handsome_feng: I assume you've already applied feedback from previous reviews of packages?
<tsimonq2> In any case, I'll be happy to review them right now.
<tsimonq2> handsome_feng: Also, I know you have some other new packages, right? If you send me an email at tsimonq2@ubuntu.com with a full list I'll be happy to get to them before the beginning of next week.
<tsimonq2> But seeing as these are now marked as Critical, I'll do them now :)
<handsome_feng> tsimonq2: oh, Thank you very much! and I will seed an email to you with the full list late. :p
<tsimonq2> handsome_feng: Alright, thanks
<tsimonq2> handsome_feng: One little nitpick (I'll still upload them, it's no problem, just do it for next upload...) is that we're at Standards-version 4.1.3 now, please update :)
<handsome_feng> tsimonq2: ok, I will update it.
<tsimonq2> handsome_feng: In any case though, what I do think is a blocker for me uploading them is getting most of these dealt with: https://paste.ubuntu.com/26402642/
<tsimonq2> Yes, it's a pedantic Lintian check, but some of these are normal warnings :)
<tsimonq2> Specifically the ones I worry about before uploading are wildcard-matches-nothing-in-dep5-copyright, gir-section-not-libdevel, and gir-missing-typelib-dependency
<tsimonq2> (that's ukui-menus, for what it's worth)
<handsome_feng> emm, I will fix this, and how do you got this info? I usually run 'debuild' in the source code and then check the lintian output, and didn't fount these informations. :/
<tsimonq2> In my ~/.sbuildrc I have the following lines:
<tsimonq2> $run_lintian = 1;
<tsimonq2> $lintian_opts = ['-i', '-I', '--pedantic'];
<tsimonq2> Not remembering how to just run the bare Lintian command with those args, because I always just use sbuild for it anyways, others in the channel, feel free to help me out here ;)
<tsimonq2> Additionally handsome_feng, here's what I get from Lintian for ukui-settings-daemon: https://paste.ubuntu.com/26402671/
<handsome_feng> Got it, I will check all my packages and fix the warnings
<tsimonq2> Awesome, thanks
<tsimonq2> I have to go to sleep, but I'll check back before school when I wake up in ~ 5.5 hours, and if things are fixed, I'll upload these for you :)
<tsimonq2> Thanks for bringing this here :)
<handsome_feng> Good night, tsimonq2, I will send you an email when I fix thoeo:)
<tsimonq2> Ok o/
#ubuntu-motu 2018-01-21
<Nanu> Hi
<Nanu> Good Morning
<Nanu> doppo
#ubuntu-motu 2019-01-15
<JackFrost> teward: https://lists.ubuntu.com/archives/ubuntu-devel/2019-January/040575.html didn't wrap so well.
<Mirv> it's probably the case of "everyone is too busy with other things to help", since that also needs time.. which leads to being more busy since the same people tend to share multiple responsibilities they don't have time think about, but which are also too important to simply give out to someone else without careful planning
<Mirv> SRU team is really, really small and with nearly no dedicated time from any of the members, AFAIK. but SRUs are handled more since they're a must, backports is easier to ignore since it's rarely critical
<Mirv> anyway, hopefully there's progress with this one, backports process indeed has been quite broken
<rbasak> I don't think there's much overlap between the SRU and backports teams, is there?
<rbasak> But we've had a few (capable) new volunteers in recent years to join the backports team, so I think the process just needs sorting out.
<rbasak> I feel that with volunteers available the queue is inappropriately stuck because those currently in the team don't have time. We should free things up to allow the new volunteers to take over in that case.
<Laney> The process drives the volunteers to not want to work on it. I say we fix that (as the mail is trying to do), and then it might be something that can actually be sustainable. Throwing more people at the current system isn't going to work.
<Laney> (IMO)
<sil2100> Mirv: SRU members have no power over backports, so even if I wanted to review a package from the queue, I physically can't do that (at least last time I tried I couldn't)
<rbasak> Laney: I agree - I just mean that those who are volunteering now, and any existing team members who are available to be involved, can work on the process change.
 * Laney nods
<JackFrost> rbasak: I'm pretty sure I wouldn't want to be one of the reviewers, but if it were to be Debian style at all then I'd more than volunteer to keep a few packages updated (Debian style: New packages to backports are reviewed, uploaded by DDs/DMs/sponsors, then kept up to date and are the responsibility of whoever uploaded.)
<Mirv> rbasak: sil2100: you're correct, I just mentioned SRU is another team that has quite few members and the members have often had 10+ year membership
<JackFrost> And noted the key difference.
<teward> JackFrost: wrapping is probably the side effect of me having to use a webclient to submit
<teward> unfortunately.
<teward> JackFrost: the tricky part is controlling that upload access without trampling toes.  Part of the problem currently is who has upload access to backports - the proposal as-is would extend upload rights to those already with privileges, though any additional updates may need review from the Backports team to make sure nothing obscene is going on; that said, those with upload access for a package should already know enough to not break the
<teward> universe at large, so.
<teward> as Laney said, the system as-is is unsustainable, so redoing the process so it can be sustainable is the first step.
<teward> so with this proposal currently, and if approval was all around, then uploads access would be available for MOTU, PPU uploaders, and anyone else with that level of upload access to the repositories for {INSERT_PACKAGE_HERE} (sponsors included I believe)
<teward> Mirv: sil2100: correct me if I"m wrong but SRU members aren't just 'volunteers' right?
<rbasak> Most are Canonical employees.
<rbasak> From the Ubuntu project's perspective they are volunteers, just that Canonical is volunteering them.
<teward> right
<teward> rbasak: point being that to some extent they're being offered by Canonical (who employs and pays them) to do the SRU tasks
<teward> rather than the Backporters team which AFAICT is not a 'canonical driven' process
<rbasak> Right. I don't know about the early days but in all my time it's never been a thing that Canonical is interested in driving. It's permitted through Ubuntu's processes without Canonical having an interest.
<teward> *nods*
<rbasak> I think (but can't speak for Canonical) that the view generally is that it's too painful a process (not just the backports process but the deb packaging process) and it'd be better to enable upstreams to ship snaps.
<teward> Mirv: ^ the above discussion there being that while SRU team is small that's Canonical driven, so there's monetary backing.  The current Backports process, even if it weren't broken, is all volunteers.
<teward> rbasak: I don't disagree, but I think that we can't completely get rid of Backports entirely.
<teward> namely because not everything is sanely snappable.
<teward> and in the case of things like, oh, Lubuntu, who absolutely refuses to ship snaps or snapd for any reason whatsoever, they don't want to touch snaps.
<teward> (you know who to yell at for that one, and if you don't i've already done that part repeatedly so... that's a dead horse discussion there)
<teward> as for Backports, there is some precedent for still providing them, in certain cases currently some packages *are* being backported with dev backing.  I don't like that "anyone" can request a backport, but we can't let that process die currently where things that can be backported SHOULD be backported but are in and of themselves not snappable as of yet.
<teward> (there are cases)
<teward> (though I don't have all of them)
<teward> not to mention, those opposed to snaps will prefer backports (and whenever you start scanning the list of Ask Ubuntu questions as I do you start seeing people getting confused or mad at snaps for various reasons)
<teward> my two cents on that part.
<teward> (sorry if i'm not being coherent as much today, I'm still waking up - 3 cups of coffee and counting)
<rbasak> teward: I see no reason that the backports repository can't continue as it is. And process changes about how to land into that pocket don't seem like they'd be problematic either.
<teward> rbasak: indeed, that was my thought as well, and I think in part Laney's thoughts as well because having one or two people being the only ones with upload access is... well, to say the least a stressor where we can offload most of that upload power to those who already have access.
<teward> ... bleh, I broke an SSL cert on a production machine, back in a bit... *goes to fix the machine in the workplace*
#ubuntu-motu 2019-01-17
<Logan> tsimonq2: I noticed that MoM says not to touch the sylpheed merge because you're working on it, but it's quite old. Are you still working on it, or is it free to take?
<Logan> same goes for qt4-x11
<JackFrost> rm -rf qt4?
<tsimonq2> Logan: Don't touch qt4-x11, sylpheed you can go ahead with.
#ubuntu-motu 2019-01-18
<Logan> ack, thanks tsimonq2
