#ubuntu-motu 2006-02-06
* sistpoty is off to bed
<sistpoty> gn8 everyone
<lucas> anyone here ready for a tetrinet game ? ;)
<raphink> oh i've totally forgotten about the TB tonight :s
<_jason> is this tertrinet game open to everyone?
<sebest_> what is the usefullness of debian/dirs file?
<crimsun> it's used by debhelper to create subdirectories in the package build
<sebest_> crimsum, ah
<sebest_> because i use install -D
<sebest_> -D create the destination dir
<sebest_> i shouldn't use -D and put this directory in "dirs" ?
<crimsun> whichever way works for you
<sebest_> both way are ok?
<sebest_> ok, thanx, i'll leave it like this as it's working
<Lathiat> sebest_: can also be usefull to include blank dirs for whatever reason
<sebest_> Lathiat: i'm trying to conver mezcalero RFP, into an ITP
<sebest_> convert
<Lathiat> RFP for?
<sebest_> can i use ubuntu's reportbug, to access debian's BTS?
<sebest_> RFP for mod_dnssd
<Lathiat> sebest_: i think so
<Lathiat> keep in mind, iirc, you can only ITP if your a DD
<sebest_> ah
<Lathiat> but you could get someone to sponsor, or perhaps use it to become a dd? :)
<sebest_> because i did the package
<sebest_> but i'm not DD
<sebest_> Lathiat, could you have a quick look at it?
<sebest_> http://sebest.ovibes.com:8000/
<sebest_> it's my first package, but i did it carefully reading the docs
<Lathiat> sure
<sebest_> thanx
<azeem> Lathiat: everybody can file an ITP, one does not need to be a DD
<Lathiat> azeem: really?
<Lathiat> hrm i read differently somewhere
<sebest_> azeem: i followed the following docs: http://www.debian.org/devel/wnpp/#l1
<azeem> lifeless: whoa!
<sebest_> but issueing "reportbug  wnpp" doesn't give me the same output as in the example
<azeem> sebest_: you might have to specify bts=debian or something in the config
<lifeless> azeem: yeah, took its time
<lifeless> azeem: but we can now do the guis and the plugins
<azeem> coincidently, I've been very busy with uni the last weeks, but should have more time from today on
<Kyral> Damn LaserJock
<Kyral> I was working on his specialty
<Lathiat> sebest_: need to build-dep lynx
<sebest_> ah
<sebest_> yes
<Lathiat> (pbuilder is good)
<sebest_> i didn't know pbuilder
<sebest_> i fixed the missing build-dep
<sebest_> any other issue?
<sebest_> hey lathiat, today i saw a demonstration of XGL!
<sebest_> Novell was demoing it
<sebest_> it's quite really impressive
<Lathiat> sebest_: where are you?
<sebest_> i'm here
<sebest_> in paris
<Lathiat> sebest_: i've been finding it nice not to depend on avahi-daemon (since e.g. i like to use my svn version)
<sebest_> yes but the package must depend on it
<Lathiat> sebest_: mod_dnssd.load has an error
<Lathiat> sebest_: says mono_dnssd
<Lathiat> sebest_: should be mod_dnssd
<sebest_> ah ues
<sebest_> yes
<raphink> what are the rules to add packages to backports ?
<orion_fr_24> here i am
<raphink> cool ;)
<raphink> siretart: do you know what are the rules to add packages to backports ?
<raphink> siretart: backporting pureadmin to breezy fixes a major bug
<raphink> everybody sleeping here ? :p
<crimsun> raphink: ask Mez
<raphink> ok
<Kyral> Since I'm not gettin' an answer anywhere else
<raphink> Mez: what are the rules to backport stuff to breezy?
<Kyral> does anacron take care of my personal crontab?
<raphink> Mez: backporting pureadmin to breezy fixes a major bug
<raphink> ty crimsun ;)
<Mez> raphink: 1) it builds from dapper 2) it doesnt break 3) it works 4) it doesnt break everything else
<raphink> Mez: exactly, don't worry i've checked ;)
<Kyral> meh no one knows lol
<raphink> Mez: i've just ported it on orion_fr_24's comp
<raphink> it's even debhelper compat 4
<orion_fr_24> yep he did
<raphink> so it builds without even a change in debian/
<raphink> Mez: the current pureadmin in breezy is incompatible with pure-ftpd
<raphink> malone 3349
<Ubugtu> malone bug 3349 in pureadmin "pureadmin package outdated" [Normal,Fix released]  http://launchpad.net/bugs/3349
<raphink> backporting 0.3 from dapper fixes this bug
<raphink> your opinion Mez ?
<sebest_> Lathiat, thanx i think i fix it
<Mez> raphink: email case for the backport and logs of build and stuff to ubuntu-backports@lists.ubuntu.com and it'll be looked at
<raphink> Mez: you want the debdiff and buildlog ?
<Mez> debdiff ?
<raphink> just the buildlog ?
<raphink> :)
<Mez> why a debdiff?
<raphink> hmm just in case there are things to change to backport it, but it's nto the case actually
<raphink> hehe
<raphink> *blush*
<Mez> well - if it doesnt work from dapper sources
<Mez> it doesnt get backported
<Mez> simple as
<raphink> it does work
<Mez> unless the changes are fixed in dapper
<raphink> ok understood ;)
<Mez> hence why we're having lots of fun trying to backport kde
<Mez> :D
<raphink> so I juts send the buildlog attached to the email to ubuntu-backports@lists.ubuntu.com
<raphink> hehe I guess ;)
<Mez> and a use case for backporting (why you want it backported!)
<Mez> but pretty much yeah
<Mez> I mean it'll be checked anyways :D
<Mez> but always better to have stuff there too
<raphink> ok
<Mez> (oh, and subscribing first or using an @ubuntu.com email address is preferred! makes me not have to approve the post!)
<raphink> hehe ok :)
<ajmitch> afternoon
<crimsun> 'afternoon, ajmitch
* mode/#ubuntu-motu [+o Hobbsee]  by ChanServ
* Kyral wonders if he would be shot for submitting EasyUbuntu to REVU
<raphink> Mez: need approval for the email cause body too big :'(
<raphink> booh
<Kyral> bddebian!!
<bddebian> Heya Kyral
* otep is away: ..- -... ..- -. - ..-  .-. ----- -..- ----- .-. --..
* irvin is away: I'm busy
<LaserJock_> hmm, I wonder why there are two of me :(
<Tonio_> morning everyone
<lifeless> ajmitch: so, can we pull *new* packages into universe ?
<ajmitch> lifeless: yep
<ajmitch> it'll probably require begging elmo
<lifeless> opensync got through new
<ajmitch> yeah, that's great to have in sid, finally
<dholbach> good morning!
<ajmitch> hi daniel
<dholbach> heya andrew
<Tonio_> morning dholbach
<dholbach> hey Tonio_
<siretart> ajmitch: wasn't gooby supposed to support avahi? why does it not show up in my service discovery applet?
<ajmitch> yes
<Lathiat> gobby only supports howl afaik
<Lathiat> someone made some dapper packages
<ajmitch> because s-d-a only shows the configured services
<Lathiat> for the howl compat layer
<Lathiat> that too
<Lathiat> gobby in dapper still doesnt depend on avahi tho
<siretart> ah, ok. thanks
<Lathiat> try avahi-browse _lobby._tcp
<ajmitch> siretart: Lathiat knows better than I ;)
<Lathiat> i doubt it sthere but
<siretart> Lathiat: what about ssh? how to I make the sshd easily pop up in s-d-a?
<Lathiat> copy th eexample service file from /usr/share/doc/avahi-daemon to /etc/avahi/services
<siretart> and restart avahi, I assume
<Lathiat> only need to reload
<Lathiat> avahi-daemon -r
<Lathiat> or init.d/avahi reload might work, dunno
<ajmitch> Lathiat: settled back to perth time yet? :)
<Lathiat> yeh
<Lathiat> oddly enough
<Lathiat> well
<Lathiat> somewhat
<Lathiat> :)
<ajmitch> probably because you don't have a real sleeping pattern :)
<StevenK> Heh.
<Lathiat> sleeping pattern? ;)
<ajmitch> so going to bed at 5am is 'normal'
<siretart> Lathiat: ok nice. what is howl? is there a faq for that somewhere?
<Lathiat> howl is another implementation of mdns/dns-sd (the protocol avahi speaks)
<ogra> ajmitch, sure it is
<ajmitch> ogra: for some people :)
<Lathiat> which is obviously inferior!
<ogra> heh
* ajmitch is going to brisbane later next week, should be real fun
<StevenK> ajmitch: While your up there, see if the case I ordered is still up there.
<cain_> lol
<StevenK> s/your/you're/
<siretart> Lathiat: ok. so, if I want to advertise services like gobby or ekiga, what is the local admin supposed to do? create these funny xml files in /etc/avahi/services and done?
<Lathiat> siretart: ekiga has support for avahi itself
<Lathiat> as in, the program registers the service at runtime
<ajmitch> StevenK: sure
<Lathiat> gobby should too, altho only has support for the howl api atm
<StevenK> It should be here tomorrow. Hopefully.
<Lathiat> and its hard to static service that since its a random port iirc
<ajmitch> StevenK: I'll probably be up there for 2-3 weeks :)
* StevenK glares at ajmitch.
<siretart> Lathiat: I told s-d-a to display local services as well, but ekiga doesnt show up
<ajmitch> heh
* StevenK wants to install liquified
<ajmitch> why so friendly?
<Lathiat> siretart: s-d-a probably doesnt know about sip services?
<Lathiat> siretart: try avahi-discover
<StevenK> (Which is what I'm planning on calling it)
* ajmitch has a nice full tower case that unfortunately needs filled with computer bits
* StevenK has a full tower case crammed full of hard drives.
<ajmitch> nice
<StevenK> (My file server)
<siretart> avahi-discover finds it..
<ajmitch> StevenK: > 1TB?
<Lathiat> siretart: s-d-a only shows certain services it knows how to launch
<StevenK> ajmitch: I wish.
<Lathiat> siretart: i think you can configure it, try right click?
<StevenK> steven@broken:~% df -h | grep nfs
<StevenK> nfs:/home/steven       29G   15G   13G  55% /media/infected
<StevenK> nfs:/srv/media        429G  369G   61G  86% /media/media
<ajmitch> StevenK: that's not much, you can get that with 1 drive these days
<ajmitch> now if I filled up the 15 drive bays with 500GB drives..
* ajmitch would have a smoking hole for a bank account :)
<siretart> Lathiat: ah, I added the service types to s-d-a, and they instantly  popped up. nice
<Lathiat> so i just got a CC and the tempt to guy buy a nice new system with lots of disk is big :)
<Lathiat> siretart: :)
<Lathiat> must.. resist. :)
* StevenK is planning on dropping the last 80Gb out of the LVM (the 430Gb partition) and replace with say, a 320Gb drive.
<Lathiat> 320s seem to be at a good price point
<ajmitch> StevenK: pvmove!
<ajmitch> either 250 or 320 seems to be the best price per GB now
<Lathiat> 320 if you get wholesale
<Lathiat> last check
<ajmitch> yeah
<ajmitch> I'm looking at putting in a couple of SATA drives
<StevenK> hdg: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
<StevenK> hdg: drive_cmd: error=0x04 { DriveStatusError }
<StevenK> Hrrrrrrm
<ajmitch> nasty
<Lathiat> oops
* StevenK glares at his file server.
<Lathiat> careful, it might get scared
<ajmitch> a good incentive was seeing bulging, leaky caps on the current motherboard
* Lathiat laughs at ajmitch 
<ajmitch> :P
* Lathiat wants to get an X2
* ajmitch is going to
<ajmitch> probably just a 4200+
<ajmitch> put in 4GB RAM
<Lathiat> in a coolermaster stacker (biig case top down with 5.25" slots, takes 3x5.25->4x3.5" convertors
<Lathiat> fill it upp :)
<Lathiat> (over time, ofc, i cant afford that much disk at once :)
<ajmitch> how many drives?
<Lathiat> i'm getting towards being able to afford the base system tho
<Lathiat> ajmitch: 12, i think you can fit 16 if you hack the top bit
<Lathiat> each convertor has a 120mm fan on the front
<ajmitch> this case has 9 3.5" bays, another 6 5.25"
<ajmitch> nice :)
<Lathiat> nice
<ajmitch> I think 15 drives might be a little noisy
<Lathiat> said case also has a nifty 'cross-flow' fan that blows underneath the motherboard
<StevenK> The case being shipped down from Brissy is a SFF case - 1 5.25" and 1 each internal and external 3.5"
<ajmitch> Lathiat: this one is second-hand, from a friend who was willing to sell it cheap
<ajmitch> 2 80mm fans down front, right in front of 6 3.5" drive bays
<ajmitch> so the air blows through all the drives
<ajmitch> and 2 in back, right beside the cpu heatsink
<Lathiat> http://www.systemcooling.com/cm_stacker-02.html
<ajmitch> nice, you bought this, or just dreaming of it?
<Lathiat> you can hack the top bay out to make another 3 bays and fit a 4th convertor in
<Lathiat> ajmitch: going to get
<Lathiat> its only $225 or so
<Lathiat> not insanely expensive
<ajmitch> good price for it
<Lathiat> hunting around for a good motherboard
<Lathiat> http://www.staticice.com.au/cgi-bin/search.cgi?q=stc-t01
<ajmitch> I think a 4200+ X2 ought to be adequate for compiling
<ajmitch> not too expensive
<Lathiat> $569 retail
<Lathiat> not bad
<Lathiat> thats what i'd get
<Lathiat> its at the sweet price point
<ajmitch> yeah
<ajmitch> a bit over $600 NZ here
<Lathiat> wonder what i can get it at work for
<ajmitch> get one for me ;)
<Lathiat> i'll let you know, keep in mind shipping tho
<ajmitch> yeah
<ajmitch> aus->nz usually isn't too bad
<Lathiat> i can get $569 - 3% at least
<Lathiat> work will probably be better
* ajmitch looks up current exchange rates
<ajmitch> about $606 NZ
<ajmitch> I think I was looking at $630 to get one here
<Lathiat> prob
<Lathiat> what can you get it locally for?
<ajmitch> hm, it wasn't $630
<ajmitch> it was $695
<ajmitch> so even if shipping was $20 it'd be worth it
<Lathiat> ah
<Lathiat> nice
<ajmitch> I might have to check out australian prices while I'm over there & once I get the money
<jsgotangco> jetsetter
<ajmitch> jsgotangco: i'm going there for work
<ajmitch> you can hardly talk :)
<ajmitch> flying all over the place, doing the conference celebrity gig
<Lathiat> oh?
<Lathiat> whatcha doing?
<ajmitch> Lathiat: just some coding
<ajmitch> since it's dealing with some specific hardware it's easiest for me to fly there
<Lathiat> ah fun
<Lathiat> i wonder how pascals flying limo ride went
<ajmitch> ?
<Lathiat> didn't hear about that?
<ajmitch> nope
<Lathiat> mark flew pascal klein back to canberra
<ajmitch> nice
<Lathiat> pascal was this 16yo guy
<Lathiat> does ubuntu art team
<ajmitch> yeah I know
<Lathiat> got sponsored to goto lca winnign some price from linux.conf.au
<Lathiat> ah
<Lathiat> cool
<ajmitch> everyone else knows too
<Lathiat> knows what?
<ajmitch> remember the conference close?
<Lathiat> ah, yeh
<Burgundavia> Lathiat, do tell
* ajmitch wouldn't have minded a ride in canonical one :)
<Lathiat> pascal seems pretty cool, reminds me of me a couple years back
<Lathiat> a little annoying but potentially usefull :)
<ajmitch> a little too eager at times :)
<Lathiat> stuff like that can be fairly encouraging
<ajmitch> sure
<Burgundavia> 16yo and not eager would worry me
<Lathiat> (flying on canonical 1)
<Lathiat> alot of people di dthings for me when i was younger
* ajmitch never gets encouraged like that :)
<Lathiat> so i know what its like
<Lathiat> i mean, no one ever flew me on canonical 1
<Lathiat> but yeh
<jsgotangco> lol
<Lathiat> i have managed to be paid for to goto lca for the 3rd year running
<Lathiat> i need to come up with a new project so i can go for the fourth
<jsgotangco> i'll see it later but won't ride it though
<ajmitch> cheapskate
<Burgundavia> how did you scam that?
<Lathiat> or get a (male) conference organisers obsessed with me again
<Lathiat> maybe jeff likes me :)
<ajmitch> haha
<Lathiat> Burgundavia: well, in lca2003, it was in my home city
<jsgotangco> lol
<ajmitch> that would be worrying
<Lathiat> and i helped organise, so free rego
<Lathiat> ajmitch: it happened in 04
<Lathiat> then in 04
<ajmitch> very worrying :)
<Lathiat> i was running the ipv6 mini conf
<Lathiat> which was the "reason" i was paid for
<Lathiat> but i think the guy organising it liked me a little too much for my personal tastes
<Lathiat> (which he later indicated clearly, altho he was somewhat drunk on both occasions)
<ajmitch> haha
<Lathiat> then in 2005 i won the RDP (sun pays for 1 person from each state)
<Lathiat> then this year i was doing a talk and got travel assistance
<Burgundavia> the sad reality of where I live is that almost no tech conferences happen north of Oregon
<ajmitch> all we have around here is LCA :)
* sivang admits all this travelling talks whip your appetite for some travelling :)
<Burgundavia> sivang, I leave tomorrow morning, in about 4 hours
<ajmitch> and who really wants to hear boring old hackers like linus come & talk? :)
<sivang> Burgundavia: yeah, already heared that , good for you :)
<ajmitch> Burgundavia: where are you off to now?
<sivang> ajmitch: are you sponsered to go to LCA by the hardware vendor you're writing stuff for?
<Burgundavia> ajmitch, Toronto, Ontario Library conference
<jsgotangco> Burgundavia, corporate jetsetter
<ajmitch> sivang: certainly not
<ajmitch> sivang: LCA was in dunedin, where I live
<Burgundavia> if I owned a suit, I would even get to where that
<Burgundavia> s/where/wear
<ajmitch> and this job is after LCA :)
<sivang> yeah, jsgotangco , well spoken
<ajmitch> Burgundavia: a suit? nasty
<sivang> ajmitch: what type of hardware is that going to be ?
<Burgundavia> ajmitch, I do sales now. I am one of those nasty suits that techs talk about
<raphink> huhu
<raphink> sales
<sivang> yeah, but although techs like to talk about them, they stay in office, while those sales people travel al over
<Burgundavia> the ones who call you and say "I just promised X. You can deliver that, right?"
<ajmitch> sivang: just some little devices to go in vans, etc
<ajmitch> I'm not entirely clear on the specs
<ajmitch> I've got to read more of the provided docs :)
<sivang> ajmitch: hehe :)
<sivang> ajmitch: sounds pretty cool. poking in the inner belly of hardware is always interesting.
<sivang> ajmitch: is this arm/risc based?
<sivang> (/me is thinking about GPS stuff)
<sivang> anyway my dear mates, gotta catch something to eat. Laters
<Lathiat> ajmitch: hrm, works supplier is actually slightly more expensive than that price from nintek.com.au
<ajmitch> heh
<ajmitch> some of those prices are impressively cheaper though
<Lathiat> actually
<Lathiat> i lie
<Lathiat> i was looking at the 4400
<ajmitch> ah
<ajmitch> what price for the 4200?
<Lathiat> oh
<Lathiat> no i wasnt
<Lathiat> i lie
<ajmitch> stop lying!
<Lathiat> i cant help it
<Lathiat> nintek seems to have the cheapest prie anywhere
<ajmitch> yeah, but shipping would probably be cheaper from an east coast supplier
<Lathiat> staticice.com.au only shows 1 other place at that price
<ajmitch> pricespy.co.nz shows a few cheaper than the site I was looking at here
<ajmitch> Lathiat: I see that shipping costs will probably make it a bit steep
<ajmitch> the preferred retailer I use has free shipping within NZ
<dholbach> crimsun: could you and janimo get the changelog-diff and diffstat of exo and thunar on the mailing list as well?
<pef> hello
<pef> dholbach: are you around ?
<dholbach> yes
<pef> dholbach: how are you ? :)
* ajmitch wanders off to sleep
<ajmitch> night all
<dholbach> pef: could be better - the distro team sprint is full of sick people and I feel quite tired myself
<Lathiat> blame NZ? :)
<pef> :/ hope you won't be ill too
<dholbach> pef: ++ - I hope that too. :-)
<pef> dholbach: you have main upload rights, isn't it ?
<dholbach> Yes.
<pef> dholbach: ekiga (old gnomemeeting) is currently broken, libopal.so.2: cannot open shared object file, the fix is to simply rebuild it :)
<pef> error at startup
<dholbach> I will look into it. I got around 10 bug reports about that already.
<Lathiat> aha
<dholbach> I'm not entirely convinced, that a rebuild will fix it, I'll look into it later today.
<dholbach> There was a whole new GNOME, which I'm currently tending.
<dholbach> 2.13.90
<pef> a rebuild in my dapper chroot solved the problem, I can use it
<dholbach> what does   apt-cache show ekiga | grep opal   say?
<dholbach> pef: ^
<pef> dholbach: nothing
<pef> missing bdepends ?
<dholbach> No.
<dholbach> Then a rebuild doesn't fix it.
<dholbach> I suppose (as I said in one of the bug reports), that it's a missing library symlink, so that shlibs doesn't pick it up.
<pef> ok :)
<pef> another question, is the method to correct bugs in n-x packages (Breezy, Hoary) documented somewhere ?
<dholbach> I don't understand.
<pef> if I want to correct a bug in a Breezy package, how should I proceed ?
<Lathiat> pef: generally, you dont
<Lathiat> pef: whats the nature of the bug?
<pef> Lathiat: broken package, for example
<Lathiat> pef: define broken
<pef> Lathiat: uninstallable package because of missing dependencies
<dholbach> What do you do to fix it?
<dholbach> The less meddling in the stable release (even via updates) the better.
<pef> so only security fixes are allowed ?
<raphink> current state of the MOTUWiki organization : http://revu.tauware.de/~raphink/MOTUWiki.png
<raphink> there is still quite a lot to do, but it's getting in shape :D
<raphink> any comment/suggestion is welcome :)
<raphink> or quite any ;)
<Yagisan> Fuddl: ping
<Fuddl> Yagisan: pong
<Fuddl> yepp?
<Yagisan> Fuddl: you packaged nexiuz on revu ? I can't find a .orig @ http://revu.tauware.de/details.py?upid=1592
<Fuddl> Yagisan: oeh.... really?!? *panic* gimme a second!
<Fuddl> ... i thought i uploaded a fixed versoin. stay tuned ;)
<Yagisan> Fuddl: I didn't see one. I felt like playing a game and just when to grab a copy and was 1 file short
<Fuddl> whoops, i didn't
<Fuddl> Yagisan: i'll fix it.
<Yagisan> Fuddl: no worries :)
<Fuddl> too late, i'm worrying :)
<Fuddl> ok, dput is uploading the .orig.tar.gz atm
<Fuddl> [x]  done
<Yagisan> Fuddl: thanks, now to play a game that isn't doom ;)
<Fuddl> Yagisan: have fun :)
<Fuddl> Yagisan: don't forget to dpkg -i nexuiz-data before nexuiz
<Yagisan> Fuddl: it looks like my pet project (http://revu.tauware.de/details.py?upid=483) is closer to coming into ubuntu, finally seeing correctly licensed or replacxed files appearing in cvs :)
<Se7h> is motu planning on uploading pymedia to the repo ?
<phanatic> hi people
<Gloubiboulga> hey phanatic
<phanatic> hey Gloubiboulga :)
<phanatic> dear masters, if anybody has the time, please have a look at http://revu.tauware.de/details.py?upid=1628 raphink has already accepted it. thanks for your help!
<dholbach> dear phanatic, if a bug is in launchpad and somebody has accepted it, it's likely that somebody will take care of it.
<phanatic> dholbach: it's not a bug in launchpad, but a package waiting for review on revu
<dholbach> ah ok, sorry then
<phanatic> np :)
<zul> heylo
<apachelogger> http://revu.tauware.de/details.py?upid=1635 feedback, feedback, I'd like to see some feedback ;-)
<jpatrick> apachelogger: ok, calm down... ;)
<apachelogger> well, my first package in revu :D
<jpatrick> apachelogger: Conflicts: kblogger ?
<apachelogger> old package is called kblogger
<apachelogger> and I renamed the thing to kicker-kblogger
<jpatrick> there is no kblogger in the repos...
<apachelogger> but a user might have it installed ;-)
<apachelogger> remove?
<jpatrick> btw no new lines at the end of lines..
<apachelogger> ok
<jpatrick> "kblogger (0.4-0ubuntu1) unstable; urgency=low" should be 'dapper'
<jpatrick> and I think the lastest dephelper is: debhelper (>= 5.0.0)
<apachelogger> :) fixed that stuff
* jpatrick waits for upload to show up
<apachelogger> ah, ok :)
<jpatrick> did you dput the fixes?
<apachelogger> I'm currently uploading the stuff
<jpatrick> cool
<apachelogger> jpatrick: it's up
<jpatrick> apachelogger: sorry I meant that there should be a new line at the end of the files - otherwise it's fine to me
<apachelogger> *readd*
<Gloubiboulga> apachelogger, there are some other minor issues
* jpatrick goes out for a cup of tea
<apachelogger> jpatrick: thx :-)
<apachelogger> Gloubiboulga: just tell
<Gloubiboulga> compat should be 5
<apachelogger> I never got the point of compat, what is that file for?
<Gloubiboulga> your description lines should be shorter (<=80)
<jpatrick> apachelogger: dpkg scripts
<jpatrick> tells them how to behave
<jpatrick> ...or something
* apachelogger asks google for more informations
<Gloubiboulga> apachelogger, your changelog should only contain 1 entry
<Gloubiboulga> and not describe what you've change in the debian dir
<apachelogger> jpatrick: "This file states the compatibility level with debhelper. Debhelper has gone through numerous revisions, some of which break compatibility, you can use the compat number to specify the debhelper revision that your package needs or supports."
<Gloubiboulga> it's the first release, so nothing has changed since the previous one ;)
<apachelogger> ah ok ;-)
<Gloubiboulga> and I don't really know cdbs, but i'm not sure that the .nstall file is usefull
<apachelogger> well, without it would probably put the stuff in kblogger instead of kicker-kblogger
<apachelogger> ...I think adept does it the same way
<Gloubiboulga> hum... I don't want say stupid things, so better ask a MOTU for this
<apachelogger> ok
<Gloubiboulga> in the copyright file, syntax is usually "Copyright: (C) YYYY author <mail@foo>"
<Gloubiboulga> and the debian file could be /usr/share/common-licenses/GPL-2, since the sources are under this license
<Gloubiboulga> I'm building the package in pbuilder :)
<Gloubiboulga> apachelogger, there is also a lintian warning
<Gloubiboulga> you can easily go through it I think
<apachelogger> ok
<Gloubiboulga> hum, bad news, the package doesn't build in a clean chroot
<apachelogger> not good :|
<Gloubiboulga> nop
<Gloubiboulga> apacheLAGger, you've also renamed the sources dir before tar.gzipping it, I don't think that's necessary
<apachelogger> Gloubiboulga: how do you mean?
<Gloubiboulga> the sources dir provided by upstream is named 'kblogger', and the one in orig.tar.gz is named 'kblogger-0.4'
<apachelogger> ah, yeah
<apachelogger> not needed?
<Gloubiboulga> don't think so
<apachelogger> ok
<Gloubiboulga> maybe you should read https://wiki.ubuntu.com/CommonPackagingMistakes/ChangingTheOrigTarball
<Gloubiboulga> the wiki is full of usefull tips ! :)
<apachelogger> and very spreaded, needs time to get through ;-)
<dholbach> MOTU REPORT TIME!
<dholbach> http://wiki.ubuntu.com/MOTUReport/Draft
<tseng> dholbach!
<dholbach> ah no, it's https://wiki.ubuntu.com/MOTU/Report/Draft :-)
<dholbach> tseng: !
<crimsun> dholbach: (RE: exo & thunar) I'll try, extremely busy today and won't be able to make the MOTU meeting
<dholbach> Ok.
<dholbach> Don't worry.
<Riddell> I wonder if posting to debian-policy from an @ubuntu.com address is a good idea
<dholbach> Riddell: I think it is.
<sistpoty> hi folks
<jpatrick> hello sistpoty
<lucas> MOTU meeting in 5 mins on #ubuntu-meetings
<lucas> #ubuntu-meeting sorry
<Gloubiboulga> hey sistpoty
<sistpoty> hi Gloubiboulga
<Gloubiboulga> thanks for the review, I'm working on it
<sistpoty> :)
<phlaegel> any of the service-discovery-applet authors around?
<khanreaper> list
<khanreaper> f
<phanatic> hi people
<Kyral> yo
<cyberix> lo people
<cyberix> oy
* Kyral blinks
<Kyral> EasyChem wound up in Sid Main?
<ajmitch> Kyral: why wouldn't it?
<Kyral> Dunno..I'm used to Main being like Ubuntu Main, then again I was just about to ask the difference between Main and Contrib
<ajmitch> right
<ajmitch> as a debian maintainer you ought to know these differences :)
<Kyral> yah yah I know :D
<Kyral> Non-Free is obviously like Multiverse
<lucas> "main" are free packages.
<lucas> "contrib" are free packages which depend on non-free stuff
<phanatic> omg, i'm sooo hungry, and it's 11pm here :(
<Kyral> ah
<meG> hi there :)
<Fudge> hi can anyone suggest a good software pacakge to use for running quotas/throttling/ftp/http stuff
#ubuntu-motu 2006-02-07
<lifeless> sqsuid
<donsmith> Hello?
<donsmith> Is anyone here who works on the mono pkgs?
<LaserJock> have you guys seen elmo on irc lately?
<ajmitch> donsmith: yes?
<donsmith> ajmitch: so I have a ppc laptop with dapper
<donsmith> the thing is mono won't install because the classlib is out of date
<ajmitch> because things haven't been building properly on ppc, afaik
<crimsun> ajmitch: were you able to attend the Van Jacobson networking talk at LCA?
<ajmitch> crimsun: yes, and I'm very glad that I did
<crimsun> ajmitch: awesome. I just finished reading Jon Corbet's article of it on lwn.net
<ajmitch> I need to get that paid account on there
<crimsun> DDs have an acct iirc
<ajmitch> yes, but we have to request it
* ajmitch was just digging around the kernel source & alsa
<ajmitch> I see there have been some commits in the driver I use
<ajmitch> last time I tried it didn't seem to make a difference
<crimsun> which codec does yours use, alc260? alc880?
<ajmitch> 260
<ajmitch> git clone is taking awhile from benc's tree
<crimsun> hmph
<crimsun> I wonder if this is the relevant one: http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/hda/patch_realtek.c?r1=1.43&r2=1.44
<ajmitch> I looked at that
<ajmitch> iirc I grabbed that single file & rebuilt alsa with it during a talk last week :)
<ajmitch> yeah, that's the source I'm currently using
<ajmitch> my syslog is really getting filled up with crap now
<ajmitch> so many selinux messages to get fixed up :)
<ajmitch> acer's website is about as evil as their hardware
<Kyral> Guys...is it alright to change a .dpatch to close a bug?
<Kyral> Malone 29965
<Ubugtu> malone bug 29965 in synaptic "Synaptic launcher is asking me for root password" [Normal,Confirmed]  http://launchpad.net/bugs/29965
<crimsun> I would disable the original dpatch, copy it, and enable the new one
<crimsun> then send a diff between the disabled and the fixed
<crimsun> then delete the disabled one
<Kyral> okay...
<crimsun> in other words, send a diff between the broken and the working dpatch
<Kyral> yah
<minghua> Hi, can any MOTU look at bug 29724?
<Ubugtu> malone bug 29724 in xfonts-mona "xfonts-mona installs font to wrong directory" [Normal,Unconfirmed]  http://launchpad.net/bugs/29724
<minghua> I've tested the debdiff and it works.  Any MOTU can upload it?
<whiprush> hi ajmitch, crimsun, others ...
<whiprush> dang, looked like I missed the VJ talk discusssion.
<pappan> starting a packaging process seems long :(
<Gloubiboulga> hello
<dholbach> good morning
<Gloubiboulga> morning dholbach
<ajmitch> mmm, beer
<ajmitch> hi
<lifeless> ajmitch: hiya
<lifeless> I want opensync in universe ... what should I do ?
<dholbach> lifeless: i want it too - for weeks :-p
<lifeless> dholbach: its in sid now ;)
<dholbach> lifeless: tell elmo to do a sync from Debian.
<ajmitch> dholbach: it's in sid
<torkel> lifeless: have debian packaged multisync 0.9 yet? or is it only the framework that is packaged?
<zakame> hi all
<Gloubiboulga> heya zakame
<zakame> hello Gloubiboulga
<zakame> not much activity today, or is it just me?
<ajmitch> fairly quiet
<jsgotangco> heh sabdfl fanboi
<zakame> heh
<ajmitch> jsgotangco: eh?
<ajmitch> was zakame doing the fanboi routine with sabdfl?
<jsgotangco> ajmitch, zakame asked for sabdfls autograph!
<zakame> yes
<ajmitch> oh dear
<zakame> lol
<ajmitch> not even I did that
<jsgotangco> and sabdfl was in a black suit and gold tie...
<ajmitch> sabdfl was little more casual when I saw him last week
<jsgotangco> ajmitch, actually a lot of the local ubuntu-ph people did aske for an authograph
<ajmitch> I don't think I could bring myself to do that :)
<jsgotangco> me too
<zakame> heh I got carried away when ealden asked for one :P
<ajmitch> though I've met him a few times now
<Lathiat> mark was pretty casual at lca in general
<jsgotangco> we had a good chat today
<Lathiat> lca is a pretty casual event :)
<ajmitch> Lathiat: yeah, it's good like that
<jsgotangco> too bad he was rushing to tokyo
<Lathiat> indeed
<ajmitch> you can actually talk to people
<Lathiat> its not like, an expo
<zakame> sure wish I can go to lca :P
<Lathiat> yeh
<ajmitch> rather than treating them like celebrities :)
<jsgotangco> heh
<jsgotangco> yeah
<jsgotangco> that is much fun
* jsgotangco was forced to wear something a bit formal today too
<ajmitch> though I regret not getting Lathiat's autograph at LCA :)
<jsgotangco> heh
<\sh> why is someone asking for an autograph of mark?
<ajmitch> \sh: because he's so famous
<azeem> I saw people asking mako for autographs
<jsgotangco> \sh, don't be surprised...
<ajmitch> azeem: haha, how'd he handle that?
<zakame> moo
<azeem> ajmitch: tbm (who was standing next ho him) didn't handle it fine :)
<\sh> oh shit...and I washed my hand after I shook marks hand, damn...
<ajmitch> heh
<azeem> I think he was still the DPL at that time
<jsgotangco> i'm nobody but someone asked form my autograph in korea... :/
<jsgotangco> it felt strange
<ajmitch> jsgotangco: that's because you were speaking
<Lathiat> haha
<Lathiat> it is a bit funy when someone first like recognizes yo uout of the blue and thigs like that
<ajmitch> noone's asked for my autograph yet :)
<ajmitch> Lathiat: it was easy to recognise you :P
<jsgotangco> but i got the supreme honor of being ajmitch's roommate
<ajmitch> poor jsgotangco
<Lathiat> at lca2003 some guy came up to me and was like "Hey! yoru that guy from <something> & ipv6!"
<irvin> heya how do we confirm a bug on malone? do i just add a comment confirming it exists?
<zakame> lol
<Hobbsee> irvin: yeah, seems to be
<ajmitch> irvin: change the status, it's not obvious :)
<zakame> irvin: status
<Hobbsee> ah, ok then!
<\sh> the first time I met maddog was really funny...I wondered why this old fart was drinking beer with us at the redhat booth during cebit 2001
<ajmitch> irvin: eg click on the packagename(ubuntu) under 'fix requested in'
* zakame will ask for ajmitch's autograph then when we meet :P
<ajmitch> zakame: that might not be for awhile :)
<ajmitch> zakame: more importantly, did you get jsgotangco's?
<jsgotangco> wonder if i could go to germany in may
<ajmitch> jsgotangco: is germany confirmed though?
<ajmitch> I know it was still a possibility
<jsgotangco> that's what mark said to me today
<jsgotangco> i told him that's the world cup
<ajmitch> yeah
<ajmitch> that's what I heard..
<jsgotangco> he said he'll make it squeeze in
<ajmitch> ok
<ajmitch> I probably won't be there
<ajmitch> can't afford it
<ajmitch> and canonical wouldn't sponsor me :)
<irvin> bug #29958
<Ubugtu> malone bug 29958 in monodevelop "Monodevelop requires MOZILLA_FIVE_HOME environment variable be set to start" [Normal,Confirmed]  http://launchpad.net/bugs/29958
<\sh> ajmitch: why not?
<jsgotangco> he hinted he might consider bangalore too
<ajmitch> \sh: because I'm lazy?
<zakame> ooh
<jsgotangco> but that would probably be before the end of the year
<\sh> ajmitch: oh
<ajmitch> bangalore would be great, a friend who came to LCA works in bangalore
<\sh> ajmitch: me too...but depends on the location in germany I would consider visiting the ubuntu conf :)
<ajmitch> \sh: nah you'd get sponsored
<ajmitch> but I live on the other side of the world
<\sh> ajmitch: for what? I'm living in germany :)
<ajmitch> and have done nothing for dapper
* jsgotangco wonders where in germany
<jsgotangco> munich?
<\sh> ajmitch: and I won't get any sponsor ship again :)
<ajmitch> \sh: you could
<\sh> jsgotangco: rumors said...munich....I would prefer hamburg
<zakame> munich world cup
<ajmitch> \sh: my single dapper goal will probably slip *again*
<\sh> zakame: world cup is all over germany :) no one can hide
<jsgotangco> yeah
<\sh> zakame: even in cologne where I live
* jsgotangco follows german bundesliga
* \sh follows dapper changes, but not the bundesliga..I hate soccer
<jsgotangco> strange...
<zakame> bundesliga?
<jsgotangco> that's the soccer league
<\sh> german soccer league
<zakame> ah
<jsgotangco> zakame, frame that CD
<jsgotangco> heh
<jsgotangco> it might lose its mint condition!!!
<zakame> jsgotangco: ack
<ajmitch> cd?
<jsgotangco> autographed 5.10 heh
<ajmitch> haha
<ajmitch> ah it's great to see users complaining on u-devel, and being told that their complaints are addressed in dapper ;)
<Hobbsee> hehe!
<jsgotangco> smackdown
<ajmitch> jsgotangco: no, just progress being made :)
<jsgotangco> dinner
<jsgotangco> heh
<jsgotangco> have you read the forum thread on automatix
<jsgotangco> ?
<ajmitch> I don't bother
<jsgotangco> i just looked at it last night
<jsgotangco> it was nasty
<ajmitch> it's full of ranting & raving & conspiracy theories
<jsgotangco> its so colorful
<irvin> i thought the issue was already resolved?
<jsgotangco> irvin, its now pride at stake
<ajmitch> irvin: it'll never be resolved, while the people involved still can type & rant :P
<jsgotangco> i say a line or two and never come back to a thread
<jsgotangco> heh
<jsgotangco> brb
<ajmitch> jsgotangco: it's one reason for me to stay away from forums
<zakame> let's have a boxing match then ;P
<ajmitch> zakame: it's too depressing reading the forums
<ajmitch> if I read them too much I'd never want to work on ubuntu :)
<zakame> ajmitch: yeah, too bad :(
<ajmitch> the automatix author seems to be unhinged
<zakame> hmm, `unhinged', how APT
<ajmitch> :P
<ajmitch> from the topic in #ubuntu-devel..
<ajmitch> No uploads on Friday (Soyuz Rollout)
<ajmitch> scary stuff
<\sh> coolk
<zakame> ooh
<\sh> at least it lands
<ajmitch> yeah
<\sh> tryting to install suns jdk on my dapper amd64 box...I need to install tomcat and play with servlets and jsp stuff...scary
<Lathiat> eww
<jsgotangco> soyuz
<Lathiat> hopefully it doesnt crash
<ajmitch> \sh: btw apt-proxy has given me many problems tonight
<ajmitch> \sh: so I haven't rebuilt wine yet
* ..[topic/#ubuntu-motu:siretart] : Ubuntu Masters of the Universe: Ubuntu Universe Repository Maintainers | http://wiki.ubuntu.com/MOTU | http://wiki.ubuntu.com/MOTUTodo | No uploads on Friday (Soyuz Rollout)
<siretart> just copied the topic from #ubuntu-devel
<Hobbsee> forgive my ignorance, but why no uploads on friday in particular?
<zakame> ^^
<ajmitch> siretart: yes, I just told them :)
<ajmitch> Hobbsee: soyuz rollout :)
* Hobbsee suspects that Soyuz Rollout isnt a person, as she first thought
* Lathiat laughs
<Lathiat> Hobbsee: soyuz is the new distro management stuff in launchpad
* Hobbsee checks with google to find out what the heck Soyuz Rollout is!
<Hobbsee> ah right
<Lathiat> so soyuz is being rolled out
<Lathiat> (put in place)
<ajmitch> you'll probably come back with lots of pics of spacecraft
<Hobbsee> hehehe!  now i feel like a moron!
<Lathiat> it takes the uploads and handles building and that sort of thing (i think?)
<Lathiat> hence no uploads
<zakame> lol
<Hobbsee> fair enough
<zakame> those sort of spacecrafts
* ajmitch googles 'soyuz rollout' & finds lots of pics
<jsgotangco> lol
<ajmitch> Hobbsee: you might even find some photos of sabdfl in a soyuz
<zakame> woo
<Hobbsee> ooh, nice
<zakame> bye all
<Hobbsee> you know, I did think Soyuz was a rather weird first name...
<ajmitch> bye zakame :)
<jsgotangco> weirder than Malone?
<Hobbsee> i've never thought that malone was a person lol
<ajmitch> http://images.spaceref.com/news/2003/20030424_rollout_02.jpg <-- nice little soyuz :)
<Hobbsee> hehe!
<Lathiat> you knwo whats funny
<Hobbsee> could be fun to be in
<Lathiat> that has rollout in the name
<ajmitch> Lathiat: of course, what do you think I searched for on google?
<siretart> http://en.wikipedia.org/wiki/Soyuz
<Lathiat> heh
<Lathiat> oh wow, dapper installs install all in the first round and boot straight into it
<Lathiat> thats awesome
<ajmitch> Lathiat: that's surprising?
* StevenK is pondering installing Dapper on his new machine.
<Lathiat> ajmitch: i havent done a dapper cd install yet
<Lathiat> only upgrades
<Lathiat> did flight1 do that?
<StevenK> I wish I could still download Flight 3 via Jigdo.
<Lathiat> bah, synaptics for ALPS is still farked
<ajmitch> ok, I think I'll try & just do selinux hacking tomorrow
<ajmitch> sleep time now :)
<ajmitch> btw, I found a horrible photo of sabdfl
<ajmitch> http://www.beefjerky.com/soyuz1.html
<\sh> well..he pointed the world to ZA biltong :)
<jsgotangco> "This is the best beef jerky I ever ate. I'm partial to South African biltong, but your beef jerky is really very good."
<jsgotangco> alright
<jsgotangco> Final Frontier Jerky
<jsgotangco> haha
<Hobbsee> Lathiat: "synaptics for ALPS is still farked" - would this be with the slow scrolling?  or is there something else wrong with it too?
<Hobbsee> ah yes, you're pointing at the bug I filed
<ajmitch> Lathiat: https://launchpad.net/people/ubuntu-x-swat
<ajmitch> the X SWAT team
<Lathiat> Hobbsee: yeh that bug
<Hobbsee> Lathiat: damned bug - did you try the solution at the end that i posted for it?  my touchpad's working properly with the workaround
<Lathiat> Hobbsee: as is mine, but a workaround isnt a solution :)
<Lathiat> i had forgotten about it cus i had the workaround on my last install :)
* ajmitch really goes off to sleep now
<Hobbsee> true - but it's better than being forced to use a PS2 mouse!
<Hobbsee> night ajmitch
<Gloubiboulga> MOTUs, I have a little problem with my libswitch package (http://revu.tauware.de/details.py?upid=1627)
<Gloubiboulga> I don't really know how to handle sistpoty's last comment
<Gloubiboulga> could someone help me on this ?
* zakame checks
<Gloubiboulga> thanks zakame
<zakame> hmm, seems the main netswitch pkg is arch:all, is this right?
<Gloubiboulga> yes, that's right
<zakame> is it a script?
<Gloubiboulga> it is
<zakame> ah k
<zakame> well looking at debian/rules you have an empty binary-indep rule, which is what sistpoty was pointing out
<zakame> perhaps setting it as `binary-indep: binary-arch' would do, but I'm not sure about that either :/
<Gloubiboulga> That's what I've done this time, but I'm not sure of this neither
<Gloubiboulga> that's why I asked :)
<zakame> it probably won't hurt though, since iirc binary-arch gets called first anyway, so binary-indep sinply doesn't do anything, unless binary-arch hasn't been made
<Gloubiboulga> actually, I don't understand the point of this
<Gloubiboulga> if you build the package, you build everything, not only the binary-indep
<Gloubiboulga> or I missed something maybe
<zakame> well the point is to comply with debian policy wrt to the porcessing of debian/rules, which follows that order
<zakame> configure -> build -> install ->binary-arch ->binary-indep
<Gloubiboulga> well, debian policy is our guide so...
<zakame> thats why for some pkgs I see, they explicitly set the binary-* targets for each package to build
<Gloubiboulga> could you give me an example ?
<zakame> say for a package `foo' that produces `foo' binary-arch and `foo-data' binary-indep, the targets could be `binary-indep: binary/foo-data' and `binary-arch: binary/foo', where each `binary/*' rule has its own process
<zakame> anyhow, hth, gtg :D
<jsgotangco> can you say that in english?
<jsgotangco> heh
* jsgotangco hides
<Gloubiboulga> :)
<zakame> lol
<zakame> I'll just blog about fanboi me tomorrow ;P
<zakame> gn8
<jsgotangco> hahaha
<Kyral> Morning MOTU
<pef> hello
<Gloubiboulga> salut pef :)
<pef> Gloubiboulga: bonsoir, ca va ? :)
<Gloubiboulga> a va :)
<Gloubiboulga> et toi ?
<pef> Gloubiboulga: vi :) je trie les bugs
<Gloubiboulga> pef, c'est un travail ingrat mais essentiel ;)
<pef> Gloubiboulga: vaut mieux en faire un peu chaque jour
<Gloubiboulga> pef, je suis d'acoord avec toi
<Gloubiboulga> somebody knows if xlibs-static-pic has been replaced by an other package, or if it's been dropped from dapper ?
<siretart> LOL: In response to the rumours [1] , I can confirm with a fair level of certainty that Paul Sladen is in fact *not* the cause of this particular outbreak!
* siretart loves dementis :)
<Amaranth> it was siretart!
* siretart is sick at home
* tseng wonders why rebuilding gaim-meanwhile still creates shlibs for libmeanwhile0
<Gloubiboulga> a bug on a xfce package should be assigned to MOTU or xubuntu-team ?
<dholbach> CC the xubuntu-team
<dholbach> and maybe CC the motu team as well, if you like
<Gloubiboulga> ok
<zyga> lucas: hello
<lucas> hi
<ajmitch> morning all
<ajmitch> hey spacey
<spacey> hi
<raphink> ok I think I'll stop reorganizing the WikiPages for now
<raphink> it's quite better imo now
<raphink> but I'd like someone (or even a few people) to review the work a bit if possible
<raphink> so anyone volunteering to browse a bit around and hunt for some mistakes ?
<raphink> this is how the organization looks now : http://revu.tauware.de/~raphink/MOTUWiki.png
#ubuntu-motu 2006-02-08
<zyga> raphink: nice diagram
<raphink> zyga: thanks :)
<raphink> it's not really the diagram I mind about
<raphink> but rather the use of it
<raphink> which was to reorganize the MOTU Wiki doc in pseudo directories
<zyga> eh
<raphink> ;)
<zyga> the wold is a really strange place
<raphink> zyga: why?
<zyga> http://www.suxx.pl/blog/index.php/2006/02/03/we-all-live-in-a-yellow-submarine-yellow-submarine/
<zyga> our government should be taken to another planet or thrown into a black hole
<zyga> or at least sentenced for life doing hard, manual labour
<zyga> or just shoot ...
<zyga> what imbeciles
<raphink> ;(
<zyga> I really don't know how to express my exact feelings in english
<ajmitch> hi \sh
<\sh> moins ajmitch
<\sh> how easy it is, to run tomcat5 and suns 1.5 jdk on dapper amd64 :)
<ajmitch> no idea :)
<\sh> ajmitch: it is very easy :)
<ajmitch> I've never felt the need to bludgeon myself with java
<\sh> ajmitch: well, when I did the work for this company last week, I had to deal with suse  tomcat and java :)
<ajmitch> ah
<ajmitch> don't worry, I'm doing C# work next week
<\sh> ajmitch: fixed a couple of installation issues, fixed something inside their java sources (without having a clue about java)
<\sh> ajmitch: that's why I'm starting to learn a bit more java now :)
<ajmitch> yay, new gtk# in sid
<ajmitch> now I can upload f-spot
<ajmitch> yay, BenC merged the ACPICA changes
<ajmitch> hopefully my battery will show up & I can get info with the next kernel build
<\sh> ajmitch: i tested infinities madwifi-ng drivers...
<\sh> ajmitch: didn't work at all
<ajmitch> :(
<ajmitch> the main thing remaining is ALSA fixes for me
<ajmitch> maybe if I'm bored on the plane... ;)
<jsgotangco> dude
<tseng> dude.
<jsgotangco> you're just going to the western island
<ajmitch> yeah
<ajmitch> it's just a short trip
<jsgotangco> western island
<jsgotangco> heh
<ajmitch> afternoon tseng, gtk# hit incoming.d.o
<tseng> hot
<siretart> hi folks
<siretart> \sh: there is a "how to sync with soyuz howto" somewhere?
<\sh> siretart: no..but there should be one :)
<ajmitch> depends if anything actually changes with the move to soyuz
<ajmitch> hi siretart
<siretart> huhu ajmitch
<siretart> \sh: I think this could be this spec: https://wiki.launchpad.canonical.com/PackageSourceManagement
<ajmitch> I wonder how  many hours it'll take to build a kernel on my laptop
<\sh> siretart: but I don't think it's already implemented...well, we see the day after tomorrow :)
<ajmitch> it's launchpad
<ajmitch> don't expect it until after 2008
<jsgotangco> wow
<jsgotangco> 2 year wait huh
<jsgotangco> just like going to mars
<ajmitch> jsgotangco: we were meant to switch to malone last july
<jsgotangco> yeah
<ajmitch> i don't know when we'll see the use of hct, and personal package archives, and all the other wonderful crack
<siretart> we will see what happens. we cannot change that anyway
<jsgotangco> he somehow the distro team gets plagued while the lp team seem to go fine
<ajmitch> it's a conspiracy
<ajmitch> https://launchpad.net/distros/ubuntu/+builds
<ajmitch> 1   20  of 108831 results
<ajmitch> I *love* paged results
<siretart> ajmitch: better look hat https://staging.ubuntu.com/distros/ubuntu/+builds
<ajmitch> siretart: I know
<siretart> ajmitch: that one does have useful buildlogs
<siretart> pl
<siretart> ok
<ajmitch> I was just commenting on the large number of results & the nasty UI that everyone complains about :)
<ajmitch> siretart: conveniently, mpt lives about 2 minutes walk from me :)
<ajmitch> > 1700 failed builds on staging
<ajmitch> and no way to break them down by arch?
<ajmitch> the launchpad guys are going to love the number of UI bugs we can file here..
<\sh> I wonder if it's possible to attach a buildd environment from other machines then canonicals ;)
<raphink> just completed https://wiki.ubuntu.com/MOTU/Documentation :)
<jsgotangco> yeah
<jsgotangco> awesome
<raphink> :)
<ajmitch> \sh: depends on who they'll trust
<\sh> ajmitch: well, thinking of personal package archives :) it would be cool, if someone can attach his own buildd env.
<ajmitch> yeah
<ajmitch> -rw-r--r--  1 ajmitch ajmitch 526M 2006-02-03 13:58 linux-source-2.6.15_2.6.15-15.20.tar.gz.new
<ajmitch> and still growing
<ajmitch> running debuild on a git checkout might not be smart ;)
<\sh> I love ubuntu...ubuntu forever
<\sh> eclipse installation including all plugins I need, it's far more easy then on gentoo
<ajmitch> mpt was wearing a good shirt to LCA - "Your Favourite Distro Sucks"
<ajmitch> very true ;)
<Kyral> then why do I catch hell for being affliated with Ubuntu?
<ajmitch> because ubuntu sucks
<Kyral> mitch..I was just owned by an exam, I don't feel like sarcasm
<ajmitch> oh it wasn't sarcastic
<Kyral> ...
<ajmitch> ubuntu does suck in many & numerous ways
<Kyral> Compared to things like SuSE....we are still behind
<ajmitch> in certain areas
<Kyral> *cough*Yast*cough*
<ajmitch> you don't need to cough
<Kyral> sorry
<raphink> Kyral: you're volunteering to help porting yast ?
<Kyral> raphink: I had a mind to write a whole new app
<raphink> oh nice :)
<Kyral> I've heard conflicting things about Yast4Debian
<raphink> would you like to write us a new package manager like finkcommander, too?
<ajmitch> I'll be impressed if you can pull off something comparable to what I've heard yast described as
<Kyral> ajmitch: yast is nuts
<Kyral> I installed OpenSuSE in a VM and was blown away
<jsgotangco> heh
* jsgotangco uses OpenSuSE too in one machine
<Kyral> Only PITA was adding an Install Repo
<ajmitch> Kyral: what's so special about it?
<Kyral> Uhh, setup everything in like 4 clicks at most
<jsgotangco> yeah adding repos and updating them are horrible
<jsgotangco> you can even go wild on xinted on yast
<raphink> ajmitch: could you update the /topic and s/MOTUTodo/MOTU\/Documentation/ in it please?
<Kyral> You want a webserver, just fire up Yast and click click click done
<Kyral> it even adjusts IPTables for you
<jsgotangco> yeah, i almost used it straight for a week till i woke up
<Kyral> woke up?
<jsgotangco> and went back to reality
<Kyral> ???
<ajmitch> raphink: you can do it
<jsgotangco> (of using ubuntu)
<jsgotangco> heh
<raphink> ajmitch: i'm not an admin here
<ajmitch> raphink: neither am I
<Kyral> I mean I'm happy with Ubuntu
<ajmitch> and the topic isn't locked
<raphink> ajmitch: yes you are :p
<jsgotangco> Kyral, i understand how you feel
<Kyral> but I like saw it through the newbie eyes for a second
<raphink> oh no you're level -1
<raphink> lol
<jsgotangco> Kyral, its extremely polished on the frontend stuff
<raphink> sorry
<Kyral> jsgotangco: and thats what Newbies want
<raphink> oooh there are only 2 admins here
<raphink> Riddell and sladen
<raphink> never seen sladen
<ajmitch> he's around fairly often
<ajmitch> not so active in this channel
<raphink> ok
<raphink> how come there are not more of them?
<ajmitch> because there aren't
<raphink> hehe ;)
<raphink> good answer
<raphink> Riddell: could you update the /topic and s/MOTUTodo/MOTU\/Documentation/ in it please?
<ajmitch> raphink: I just told you, the topic is not locked
<raphink> ah!
<raphink> huhu
<raphink> *blush*
<jsgotangco> heh
* ..[topic/#ubuntu-motu:raphink] : Ubuntu Masters of the Universe: Ubuntu Universe Repository Maintainers | http://wiki.ubuntu.com/MOTU | http://wiki.ubuntu.com/MOTU/Documentation | No uploads on Friday (Soyuz Rollout)
* raphink blushes and thinks he should go to bed
<\sh> DESTROY JAVA
<\sh> how sick is this
<\sh> 			jCheckBox.addActionListener(new java.awt.event.ActionListener() {
<\sh> 				public void actionPerformed(java.awt.event.ActionEvent e) {
<\sh> 					System.out.println("actionPerformed()"); // TODO Auto-generated Event stub actionPerformed()
<\sh> 					jCheckBox.setText(jCheckBox.isSelected() ? "Message on" :"Message Off");
<\sh> 				}
<\sh> 			});
<ajmitch> haha
<ajmitch> java == evil
<\sh> well, I know what it does...but this is not in my style of pure OOP
<Lathiat> ewww
<Lathiat> EEEEEEEEEWWWWWWWWWWWWWWW
<ajmitch> yay, alsa 1.0.11rc3
<Lathiat> works with yoru laptop?
<ajmitch> dunno yet
<ajmitch> I've got to test it out
<ajmitch> first step is to rebuild with the new acpi patches from benc's git tree
<Lathiat> this trackpad is driving me nuts
<Lathiat> garrr
<ajmitch> then I might attempt to merge in the alsa tree
<ajmitch> depends on how brave I'm feeling
<\sh> good night people :)
<Lathiat> hrm libc6-dev is uninstallable
<Lathiat> annoying
<ajmitch> Lathiat: how so?
<Lathiat> ah i lied
<Lathiat> im a tool
<Lathiat> i had breezy sources in /etc/apt/sources.list
<ajmitch> heh
<Lathiat> i wgetted my standard sources.list
<Lathiat> and forgot to breezy-.dapper
* ajmitch wouldn't talk about you like that :)
* Lathiat grins
<ajmitch> not while you were listening, at any rate :)
<ajmitch> yay, kernel is (slowly) compiling
<ajmitch> in a few hours I might have something to play with
<jsgotangco> oohh sabdfl hit the local news
<ajmitch> yeah he was on the front page of the local paper when he was here
<ajmitch> we don't often get celebrities like him in town ;)
<jsgotangco> he was lowkey here but upbeat
<ajmitch> Lathiat: have you played with using distcc & pbuilder?
<Lathiat> ajmitch: nope
<Lathiat> i saw some mention of a more official motu tools package now but i cant find any references to it?
* ajmitch will have to hunt around for pbuilder info then
<Lathiat> ajmitch: let me know i should probablky get both my machines vbuilding :)
<ajmitch> pbuilder, distcc & ccache are probably useful to use together
<Lathiat> looked at ccontrol?
<Lathiat> ah ok i found those tools now, it was under the merging page
<Lathiat> (oddly enough ;)
<ajmitch> no, I haven't seen ccontrol
<Lathiat> http://ccontrol.ozlabs.org i think
<ajmitch> ah, more rusty code :)
<ajmitch> do you trust code written by a porn star? ;)
<Lathiat> .
<Lathiat> heh
<jsgotangco> porn star?
<ajmitch> Lathiat: distcc works with avahi?
<Lathiat> ajmitch: yeh theres a patch for it lennart wrote
<Lathiat> check the list archives
<ajmitch> ok
<ajmitch> Lathiat: the debian packaging patches on the ccontrol mailing list scare me
<Lathiat> ajmitch: heh why
<ajmitch> things like updating debian/changelog in configure
<ajmitch> and the other patches are just stock dh_make
<ajmitch> I see that xen is now going to be a toggleable option for the i386 arch, rather than an arch in itself
<Lathiat> interesting
<Lathiat> does it need hard support or can it still run native with xen compiled in?
* Kyral sighs
<Kyral> I think I know what to do
* Kyral thinks about joining the FSF
<Kyral> yo jsgotangco
<jsgotangco> hey
<Kyral> sup?
<jsgotangco> dsl is shitty since morning
<Kyral> ah
<Kyral> I'm thinking about joining the FSF
<Kyral> Seems like the "right thing" :D
<Kyral> ..*shrug*
<Lathiat> hrm, twisted-doc is b0rked
<Yagisan> G'day all. Anyone with a debian sid box here ? if so, is nmap 4 available yet ? (sorry to bother, but p.d.o is down)
<plugwash> i don't have a sid box handy but i just checked the release file by hand and it seems it is
<crimsun> Yagisan: I use packages.qa.debian.org these days.  http://packages.qa.debian.org/n/nmap.html
<Yagisan> thanks. nmap is main isn't it ? who should I bother to request a sync ?
<ajmitch> Yagisan: we're in upstream version freeze now
<ajmitch> so requests have to be worded nicely
<crimsun> I'd love to have 4.00-2 in Dapper, too, but I suppose if lamont could be persuaded to request it...
<Yagisan> ajmitch: I'm very aware. 4 has massively reduced memory requirements, for starters :)
<ajmitch> I suppose he'd know best :)
<ajmitch> Yagisan: that's always a win
<ajmitch> crimsun: I see a new alsa RC is out
<ajmitch> crimsun: what pain do you have to go through to get that in?
<crimsun> ajmitch: meaning -driver, -lib, or -utils? :)
<ajmitch> I was mainly looking at -driver :)
<crimsun> ah, that wouldn't be too bad. What do I need to backport?
<ajmitch> not sure, I haven't tried it out yet
<ajmitch> my laptop has been building a kernel from the git tree for the last couple of hours
<ajmitch> I'll try & get the latest driver source built as extra modules so I can test it again
<crimsun> great, testing -driver 1.0.11rc3 would help
<ajmitch> yeah, I just have to see how easy it is to go from upstream tarball to debian packages
<ajmitch> ok, building kernel image 4 of 5.. this takes awhile
<crimsun> the kludgy way is to take experimental's 1.0.11rc2 alsa-source, extract it, extract upstream 1.0.11rc3, copy 1.0.11rc2/debian to 1.0.11rc3/., then do the normal fakeroot debian/rules binary_modules KSRC=/lib/modules/$(uname -r)/build KVERS=$(uname -r)
<Yagisan> :) nmap 4 has already been requested :)
<Ubugtu> Error: I tried to send you an empty message.
<ajmitch> crimsun: sounds nasty enough
<ajmitch> I'll give it a try in a couple of hours, once I have a kernel to use
<crimsun> cool
<Kyral> you robitaille
<Kyral> yo even
<robitaille> hi Kyral
<ajmitch> hello robitaille
<robitaille> hi ajmitch
<Lathiat> so,
<ajmitch> yep
<Lathiat> http://launchpad.net/distros/ubuntu/+source/lib3ds/+bug/3711
<Ubugtu> malone bug 3711 in lib3ds "Incompatibility with GCC4 optimization" [Normal,Unconfirmed] 
<Lathiat> using -O0 makes his test work
<Lathiat> i assume the optimization breaks it just by that it returns a different value
<Lathiat> with -O0 it seems to work on his example, is putting -O0 in the package a sane fix for now?
<ajmitch> possibly
<Lathiat> hrm, i found a patch
* Lathiat kicks sourceforge
<Lathiat> work damn you :(
<ajmitch> sf really is crap
<Lathiat> ok i got a patch that was put in lib3ds cvs that fixes it
<Lathiat> sounds like a better idea to me :)
<ajmitch> crimsun: rc3 seems to be no different
<crimsun> ajmitch: ok, that's what I figured, since there didn't seem to be major changes to the alc260 init code
<crimsun> thanks for testing
<ajmitch> crimsun: I had impressive failures with the new ACPI code though :)
<jsgotangco> ajmitch: http://www.flickr.com/photos/headgeekette/
<jsgotangco> see zakame get starstruck
<jsgotangco> heh
<ajmitch> hah, great :)
<ajmitch> of course you were cool & treated it like nothing happened
<ajmitch> since you're a famous celebrity yourself ;)
<jsgotangco> oh shut up
<ajmitch> sabdfl looks professional in a suit
<ajmitch> like a manager :)
<jsgotangco> yeah
<dholbach> good morning
<lucas> hello dholbach & others
<Lathiat> who knew about the unrar/unrar-nonfree situation?
<sivang> morning all
<spacey> situation?
<spacey> you mean only the nonfree one is useful?
<Lathiat> more that
<Lathiat> they moved the unrar-nonfree source to making the binary 'unrar'
<Lathiat> and its uninstallable
<Lathiat> i think it needs some poking
<\sh> so far to the ubuntu/debian diversion questions
<siretart> \sh: ?
<siretart> morning
<\sh> siretart: see dapper-changes and lamonts uploads :)
<siretart> yes, I've seen that
* siretart sighs
<\sh> siretart: well..that's what I meant...sometimes you can forget filing bugs to debian, especially with those little friendly uploads :)
<\sh> or in other words: how should we deal with those changes?
<siretart> \sh: that was exactly my question
<siretart> \sh: as far as I've seen, most of the recent uploads just change the build deps. so they are not likely to cause headaches when merging next time
<siretart> my concern is rather about divergence, which does cause headache
<\sh> siretart: you mean real patches? or "I don't want to change to cdbs" packages like "gajim"...
<siretart> \sh: 'real' patches is a rather fuzzy expression, but I think we mean the same.
<siretart> \sh: I don't know what happened re: gajim
<\sh> siretart: debian has cdbs, we use debhelper ( which is better right now, because I'm trying to make gajim python policy compatible)
<siretart> \sh: why didn't you put yourself in the maintainer field then?
<siretart> if Yann doesn't accept your debhelper debian/rules, I don't see much point in calling him 'maintainer'
<\sh> because he debianized the package the first time with debhelper....that's why....but the "changing maintainer" or "hijacking the package in ubuntu" is something, I want to have a clear statement from TB somehow.
<siretart> why bug the tb with that?
<siretart> that not really a technical question
<siretart> well, in some ways it is, but I hope you get what I mean
<\sh> siretart: because it could help sabdfls request to use the whole debian namespace ;)
<siretart> ?
<\sh> siretart: https://wiki.ubuntu.com/PackageVersionConflicts
<\sh> siretart: we had a small discussion about this before and during ubz...and changing the maintainer e.g. to "Ubuntu Developers <ubuntu-devel@...>" would fit into this (IMHO)
<\sh> but I didn't see the "when we package new software..."
* siretart rolls eyes
<siretart> fairly thin for a spec. never really discussed, not on tb agenda.
<\sh> siretart: yes..it was dropped :)
<siretart> \sh: why the ':)'?
<siretart> sorry, I don't consider this funny at all, but rather frustrating
<siretart> oh, jdong applied for ubuntu-dev
<\sh> hmmm..who did work with him?
<\sh> (motu work I mean)
<\sh> siretart: the :) was more a finger practice...I'm not completly awake
<irvin> bug #29958
<Ubugtu> malone bug 29958 in monodevelop "Monodevelop requires MOZILLA_FIVE_HOME environment variable be set to start" [Normal,Fix released]  http://launchpad.net/bugs/29958
<irvin> lemme check
<Toadstool> hi, I uploaded a package to REVU this night before my GPG key was added to the REVU keyring. It looks like the package has been correctly uploaded as dput tells me "Already uploaded to revu.tauware.de" but it doesn't show up on the webpage. Did I do something wrong or do I have to wait a little longer ? (or am I asking silly questions on the wrong chan :))
<siretart> Toadstool: I just reprocessed your upload manually
<Toadstool> ok thank you very much
<Kyral> Morning
<teprrr> hmm, how should I mention the need for autoconf in build requirements?
<teprrr> good afternoon Kyral :)
<teprrr> Build-Depends: cdbs (>= 0.4.23-1.1), autotools-dev, debhelper (>= 5), kdelibs4-dev (>= 3.5)
<teprrr> that's what I have atm, but it gets no autoconf
<Kyral> Isn't depends on Build-Essential assumed?
<azeem> autoconf isn't b-e
<azeem> teprrr: why do you need autoconf?
<Kyral> Yah just saw that >_<
<Kyral> teprrr: how about depending on autoconf
<teprrr> azeem, to run make -f Makefile.cvs
<Kyral> Wait wait wait
<teprrr> azeem, and that to avoid having a large diff with autoconf-created stuff
<Kyral> this package has its CVS stuff still there?
<teprrr> Kyral, yup
<azeem> teprrr: what does Makefile.cvs do?
<teprrr> azeem, it creates configure script
<azeem> ah, ok
<azeem> using autoconf at build time might break the package when autoconf changes in unexpected ways
<azeem> I am not sure on the current policy, but when you want to go down that road, then yes, you need to add it to Build-Depends
<teprrr> yes, that's what Riddell told me too..
<Kyral> teprrr: try to get rid of the CVS stuff (like /trunk)
<Kyral> but anyway I need breakfast
<teprrr> though I'm gonna still try to convince the developer to run it before the packaging
<Riddell> azeem: packaging kde stuff?
<azeem> no, just trying to helpful
<azeem> +be
<Riddell> it remakes Makefile.in and configure as said
<Riddell> try to avoid it if possible, but it's not always possible
<teprrr> yeah, the developer doesn't want to have a big source package.. :P
<azeem> that's egoistic :)
<Riddell> that's braindead
<Riddell> if he doesn't want big source packages don't use an autoconf build-system
<teprrr> ./admin/cvs.sh: line 33: --version: command not found
<teprrr> *** AUTOCONF NOT FOUND!.
<teprrr> mmh, and it has autoconf depend and it installed autoconf 2.59 ..
<teprrr> I'm talking about pbuilder run
<azeem> teprrr: check that cvs.sh script
<teprrr> it points to $AUTOCONF, though I can't see where it's set..
<teprrr> ah, indeed, it's not set at all.. but mmh
<azeem> maybe they want you to export it first
<teprrr> hmmh, maybe I should first try to talk to the developer..
<Riddell> teprrr: automake1.9 too?
<teprrr> Riddell, ah yes, seemed to work now
<teprrr> Riddell, should I somehow clean up/remove Makefile.in after the install or..?
<phanatic> hi people
<Riddell> teprrr: yes, some make target does that
<Riddell> make distclean maybe
<raphink> siretart: ping
<siretart> raphink: pong
<raphink> siretart: hello :)
<Gloubiboulga> hello :)
<raphink> siretart: I'm trying to see if it could be possible to automatize the debuild && debuild -S test on tiber
<raphink> doesn't seem possible though, without a dapper chroot
<raphink> do you see any option?
<raphink> hi Gloubiboulga
<Gloubiboulga> hello raphink
<Gloubiboulga> merci pour la publication des commentaires raphink
<raphink> de rien Gloubiboulga
<siretart> raphink: I'd rather use sbuild for that. but even then, its somewhat dangerous to run unchecked code as root
<raphink> continue comme a c'est trs utile :)
<raphink> et tu fais de bons commentaires
<raphink> siretart: ic
<raphink> siretart: do you think pbuilder could be used for this?
<raphink> revu-build uses pbuilder
<raphink> couldn't pbuilder help generating a report on debuild && debuild -S
<raphink> ?
<\sh> et voila ejabberd 1.0.0 on my hoary
<raphink> :)
<siretart> \sh: did you just restart jabberme.net?
<siretart> ah, obviously :)
<\sh> siretart: I installed ejabberd 1.0 and restarted yes :)
<raphink> siretart: the thing is that debuild test is quite the only test thing I miss to review stuff entirely on tiber :)
<raphink> everything else can be automatized
<siretart> \sh: does this one finally cope with umlauts in the icq transport? ;)
<\sh> siretart: no...that has nothing to do with it.......I'm working on pyicq this night :)
<raphink> siretart: as in, generating all the necessary reports to review a  package entirely on the REVU web interface
<siretart> raphink: what do you exactly mean with debuild test? whats missing from the buillog from pbuilder?
<raphink> siretart:
<siretart> \sh: ah, so the transports are completly separate problem. ic
<raphink> debuild && debuild -S -sa
<raphink> to see what files need to be cleaned
<raphink> this cannot be found
<siretart> raphink: oh. interesting test..
<raphink> I'm interested in the diff.gz created when running debuild && debuild -S
<raphink> siretart: indeed, but I need a chroot to do it
<siretart> raphink: I'd rather implement it as pbuilder hook, because we use pbuilder for now anyway
<\sh> siretart: yes :)
<raphink> so that so far I have to get the files on my machine and run it there
<raphink> siretart: if that's possible it would be great
<siretart> raphink: look at the pbuilder documentation. it has a very flexible way of doing hooks
<raphink> siretart: basically what I need to do is this :
<raphink> debuid && debuild -S in the source
<raphink> then
<raphink> gzip -d $package.diff.gz
<raphink> grep orig $package.diff
<raphink> and check that only files from debian/ are there
<raphink> siretart: ok
* raphink dives into the pbuilder man
<siretart> raphink: I don't want to build a package twice.
<siretart> \sh: are you by chance at 'chemnizer linux tag'?
<raphink> siretart: I understand that
<\sh> siretart: no..
<raphink> but then I need to debuild -S in the pbuilder _before_ the bpuilder stuff ends
<raphink> and i'm not sure this is possible
<siretart> \sh: our local lug is going, kathrin and me are joining them
<\sh> siretart: no money :)
<siretart> raphink: pbuilder has hooks for nearly everything
<raphink> ok
<raphink> two diff.gz have to be generated though
<raphink> siretart: pbuilder hooks rock :)
<siretart> raphink: L(
<siretart> raphink: :)
<raphink> thanks for the tip :)
<raphink> siretart: I'll modify revu-build and i'm fixing rebu-orig a bit too
<raphink> could you modify them in /usr/local/bin when it's done and tested?
<siretart> feel free :)
<raphink> oh I have the rights to do it ? :)
<siretart> I think I will replace it with a symlink to /srv/revu1/scripts, so you can check in directly
<raphink> oh if that's the case then ok
<raphink> siretart: cause right now I have no right to write in /usr/local/bin
<raphink> and it's not linked to the svn yet
<siretart> no, I want to look at it first
<raphink> sure
<raphink> :)
<siretart> ok, symlinks in place
<raphink> siretart: seems to me that pbuilder hooks are only for update and create processes
<raphink> not for build
<raphink> --hookdir [location of user scripts] 
<raphink>               Specifies the location where scripts for user intervention during the create and update process are stored.
<siretart> raphink: look in /usr/share/doc/pbuilder/examples for some example hooks
<raphink> ok thanks
<raphink> siretart: do you have a folder for pbuilder hooks somewhere on tiber? so I don't keep it in my ~ which would be very dirty ;)
<siretart> raphink: either put it in your home, or even better, create a pbuilder-hooks dir in revu svn
<raphink> yes I think I'll do that
<raphink> but then I'll have to link to /srv directly
<siretart> I don't have problems with that :)
<raphink> siretart: what would you think of creating a (empty) file called FTBFS in the directory when pbuilder fails
<raphink> so that when you look at the list of files on REVU, you can see it immediatly
<raphink> and you just don't go much further
<raphink> ?
* raphink often forgets to put `?' after questions ;)
<siretart> sound reasonable
<raphink> ok :)
<raphink> it's a very easy hook
<raphink> just a touch in a hook launched when pbuilder fails
<raphink> :)
<raphink> siretart: who is the author of revu-build? you?
<siretart> raphink: yes, it was a quick hack I made in some free minutes
<raphink> hehe I guess
<raphink> i'm not as fast as you developping I guess
<raphink> and i'm putting my script under GPL
<raphink> i'm thinking of merging revu-build and revu-orig to run them together
<raphink> do you want a script under GPL with both names ?
<siretart> raphink: do you insist on gpl, or would you mind to use the bsd style licence we use in the rest of revu?
<raphink> I don't insist
<raphink> I don't really mind
<raphink> it's just that i've already put my code under GPL
<Kyral> ...I read that as incest...
<siretart> I rather prefer the bsd style, with non advertising clause in my code
<raphink> Kyral: ?
<raphink> siretart: why?
<Kyral> raphink: random comment
<raphink> Kyral: ah?
<Kyral> I don't insist <<---Read that as "incest
<raphink> siretart: I'm fine with BSD if you prefer it this way, although my preference is for GPL ;)
<siretart> raphink: gpl is too restrictive and too complicated for me. I don't claim to understand it entirely
<raphink> hehe right
<raphink> ;)
<raphink> I just trust in the FSF to produce a good license
<raphink> I don't claim to understand it either
<Riddell> siretart: you want people to be able to use your work as prorietry software?
<siretart> Riddell: I have no problems with that. at least for revu
<Riddell> BSD it is then :)
<siretart> :)
<raphink> I don't like the idea of having my work under BSD ;)
<siretart> then use gpl. I don't really insist, but prefer
<Mithrandir> it's a bunch of scripts, isn't it?
<siretart> yes, nothing spectacular
<Mithrandir> well, BSD vs GPL aren't really interesting in the context of scripts -- if they're distributed, you have something you can edit anyway.
<siretart> right
<ajmitch_> yay
<ajmitch_> my desktop box must have restarted in the night & now it isn't working :)
<raphink> siretart: I made a revu-report script that runs both revu-build and revu-orig
<raphink> this way they keep separated
<raphink> generates things like this : http://revu.tauware.de/revu1-incoming/vbaexpress-0602031505/REVU_report
<raphink> which is believe canbe useful
<siretart> neat
<siretart> how to use?
<ajmitch_> sigh
<ajmitch_> I have to kill keybuk
<siretart> ajmitch_: -v
<ajmitch_> ?
<ajmitch_> he turned off selinux in sysvinit
<ajmitch_> because of a silly message
<siretart> ah
<ajmitch_> I was trying to work on it for a change
* tseng wonders what meeting is going on
<\sh> forum foo and forum bar
<raphink> siretart: I've updated the REVU svn with the new scripts
<raphink> siretart: if you can have a look and link the 2 scripts revu-orig and revu-report to /usr/local/bin
<Mez> ajmitch: ping
#ubuntu-motu 2006-02-09
<ajmitch_> Mez: yes?
<Mez> ajmitch_, would you be willing to sponsor ifolder into debian once it's finished being packaged (assuming of course that it's of high enough grade packaging quality)
<ajmitch_> maybe
<ajmitch_> is this an individual packaging effort, separate from the mono packaging team?
<Mez> yes
<Mez> though - I will of course be poking a lot of the mono team for advice :D
<ajmitch_> oh joy
<Mez> well, I've had quite a bit of advice off them already on previous attempts
<Mez> so it shouldnt be too bad
<crimsun> gah, ENOELMO
<ajmitch_> crimsun: he's hiding?
<ajmitch_> or he's probably stressing over the move to soyuz
<ajmitch_> and drinking his troubles away
<crimsun> quite reasonable =)
<Lathiat> hah
<Kyral> Okay...Its a good thing I found Ubuntu before I found SuSE
<raphink> Kyral: sssshhh
<Kyral> what?
<raphink> :s
<raphink> nm
<Kyral> Its not like I'm up and leaving Ubuntu
<raphink> yeah yeah ;)
<raphink> of course not :)
<Kyral> I'm just saying Yast is NICE ;P
<Amaranth> bored2k did
<raphink> what did you use before getting to Ubuntu?
<Amaranth> suse doesn't have alacarte ;)
<Kyral> Ohh...Slack 10, Gentoo
<Amaranth> at least i don't think so
<Amaranth> but GNOME 2.16 will :D
<Kyral> I don't use the Menu Editor much :P
* raphink can't wait for KDE 4
<Amaranth> Kyral: it doesn't have easyubuntu either
<Kyral> Amaranth: I don't need EasyUbuntu ;P
<Amaranth> or all of us on call to fix things :)
<Kyral> okay that you have me :p
<Kyral> I'm just saying I wanna help the Yast4Debian project now lol
<raphink> Kyral: very nice idea :)
<raphink> from what I heard about yast, i'd love to see it in Kubuntu :)
<raphink> although i've heard it's so complex a program that it's very hard to port
<Kyral> SaX wouldn't hurt either
<Kyral> It is a NICE GUI to configure X with
<zakame> heya MOTUs :)
<Kyral> yo zakame
<zakame> yo Kyral :)
<raphink> hi zakame
<zakame> heya raphink master revu-er :)
<raphink> lol
<zakame> good job on the motu doc move-around :)
<raphink> :)
<raphink> thanks
<raphink> took me about 10h
<raphink> so far no one complained
<raphink> I take it it was accepted ;)
<zakame> actually it was much-needed :)
<raphink> I think so too
<raphink> otherwise I wouldn't have done it ;)
<zakame> hehe
<raphink> now we can see much more clearly what needs to be merged, nuked, and so on
<raphink> just have to keep the doc tree up-to-date
<raphink> :)
<raphink> I got back to REVU today though ;)
<raphink> I had enough of the wiki ;)
* zakame hugs raphink
* raphink hugs zakame too
<raphink> did you have a look at the tools I developped today zakame ?
<raphink> I just posted a message on ubuntu-motu about them half an hour ago
* zakame just got back home from Manila
<raphink> oh ok :)
<zakame> ooh lemme check then :D
<raphink> sure
<raphink> :)
<zakame> wow, REVU-tools are great :D
<raphink> glad you like them :)
<zakame> (which also reminds me I should ping siretart about making me an account on tiber for remote REVU ;)
<raphink> that's the main thing I did today :)
<raphink> yes that's very useful
<raphink> I'll ping siretart again tomorrow to get sure he checks my changes to the svn and adds the new revu tools to /usr/local/bin so they can be used by all
<raphink> so far I call them with ~/revu-report
<raphink> which is not useful for other tiber users
<raphink> hehe
<zakame> hehe, or package it even ;)
<raphink> oh sure I'm thinking of it
<raphink> but then it has to be made `distributable`
<raphink> i.e. REVU-independent
<zakame> ooh right
<raphink> so far it depends a bit too much on tiber's settings and scripts
<raphink> and I think it can be made independent to run on any box
<raphink> even be used by DDs for sponsoring imo ;)
<zakame> that would be nice indeed
<raphink> if some of them accept these tools ;)
<zakame> yeah
<raphink> so that's work for the days to come :)
<zakame> a lot of rocking on for you then :D
<raphink> it's not to find work in Ubuntu ;)
<zakame> hehe
<raphink> $ ~/revu-report pam-abl_0.2.3-0ubuntu1.dsc pam_abl-0.2.3.tar.gz
<raphink> hop :)
<raphink> I'd really like to be able to get the upstream tarball automatically
<raphink> but I think Debian policy should be changed to be able to do that
<zakame> yeah, I think it could also work for doing some auto-merging work
<raphink> since there would have to be a place in the package where the url of the upstream tarball would be clearly given
<Mithrandir> uhm, you do realise you should review all changes in each upstream version?
<Mithrandir> anyway, sleep
<zakame> Mithrandir: hmm, that too
<raphink> yep, sleep
<raphink> dist-upgrading my box and I'm off to bed :)
<raphink> gn
<zakame> bbl
<jsgotangco> heya minghua
<minghua> hi jsgotangco
<jsgotangco> minghua, i got to talk to sabdfl 2 days ago over lunch and we talked about cjk and scim
<jsgotangco> minghua, he's in tokyo at the moment i think but he'll be passing over to korea and china so i guess there will be focus on discussions with such support
<minghua> jsgotangco: great to hear about it
<minghua> jsgotangco: mako talked about CJK support during last CC meeting too
<jsgotangco> oh cool
<minghua> there sure is interest, we probably need more people though
<jsgotangco> yeah
<monzie> i want to contribute to Ubuntu
<monzie> i have debian packaging experience
<hub> monzie: https://wiki.ubuntu.com/MOTU
<hub> monzie: that is the starting point
<monzie> thanks, hub
<monzie> the docs are a bit confusing hub
<monzie> where can i get the list of packages to work on or something like that?
<StevenK> From the bug list?
<StevenK> It's a litle more complicated than working on Debian, you don't just look after a package or two.
<monzie> okay
<Amaranth> everyone can touch every package, no one owns a package
<Amaranth> makes it easier
<StevenK> And harder to find someone to blame. ;-P
<Amaranth> no, that's still easy
<Amaranth> blame who touched it last
<hub> StevenK: changelog is your friend
<Amaranth> yeah
<Amaranth> btw, never touch firefox
<Amaranth> people will try to make you the permanent maintainer :P
<StevenK> Heh
<StevenK> That's what Diziet is for. :-P
<jsgotangco> heh
<jsgotangco> seamonkey
<StevenK> At my place of work we have a 'the person who touched it last gets to look after it' policy.
<StevenK> jsgotangco: The other I've heard is 'iceweasel'
<jsgotangco> yeah i think that's the future all in one mozilla suite/components
* jsgotangco will have to check if its is good enough for inclusion to opencd
<fubarity> Can someone explain how Ubuntu's package versioning nomenclature works? I have browsed everywhere, only to find very little conclusive. And, moreover, why is it that some packages are <package>-(numbers), while some are <package>-(numbers)-(numbers)ubuntu(numbers)?
<Gloubiboulga> <package>-(numbers) means that the package has been synced with debian
<crimsun> ok, it's pretty straightforward (you can find this info in the Debian New Maintainer's Guide)
<crimsun> packages where the versioning is A.B.C are native Debian or Ubuntu packages
<crimsun> those where the versioning is A.B.C-X are Debian-maintained
<crimsun> those where the versioning is A.B.C-XubuntuY are Ubuntu-modified from their original Debian counterparts
<crimsun> so A.B.C-X, lke Gloubiboulga said, are synced straight from Debian
<psusi> -ubuntuN is for packages with ubuntu specific changes that replace the previous version from debian, but the next version from debian will be newer than the -ubuntuN
<fubarity> Now, suppose that I am going to Debianize (i.e., make a *.deb) a package for Ubuntu for a package for which no actual Debian package exists. Which nomenclature would I use? And what do the X and Y components surrounding XubuntuY mean?
<crimsun> if it doesn't exist in Debian yet, then you'd package it as A.B.C-0ubuntu1
<crimsun> that way when it enters Debian, Debian's versioning has higher precedence
<crimsun> (A.B.C-1)
<fubarity> So, what do the 0 and 1 mean? Could these variables have any other values?
<crimsun> they signify packaging revisions (as opposed to "upstream" versions)
<crimsun> and no, for the case you describe, X must be 0, and Y must be 1
<crimsun> generally, however, yes, X and Y are not tightly coupled
<zakame> this nomenclature is to avoid possible clashes when someone from Debian decides to make a NEW package (which could either be based on your Ubuntu package, or created from scratch altogether; see njam for an example ;)
<fubarity> I appreciate everyone's help here; it means a lot.
<zakame> no prob :)
<Kyral> Night MOTU
<siretart> good morning soyuz lovers!
<siretart> :)
<siretart> this is what I call quick response: debian #351280
<zakame> good morning siretart ! :D
<siretart> hi zakame
<siretart> zakame: I have a hilight in my backlog, you wanted some sort of 'remote' access to revu?
<siretart> huh?
<zakame> yeah, but the gist of that is I want to be able to test build of REVU-ed packages, not necessarily shell access
<siretart> currently you need shell access to call revu-build
<zakame> ah
<zakame> heya Hobbsee
<Hobbsee> hey zakame :)
<zakame> what's up?
<Hobbsee> just got home from work, having trouble building asciiquarium
<zakame> oooh
<zakame> brb, someone needs to call :/ (dialup)
<TheMuso> c
<siretart> raphink: I updated /srv/revu to rev 120 (currently HEAD)
<raphink> siretart: thanks :)
<raphink> siretart: did you make the new links in /usr/local/bin too?
<siretart> raphink: done
<raphink> thanks :)
<raphink> much :)
<siretart> no problem
<raphink> argh I made a mistake in revu-build though
<raphink> siretart: I'll correct it, it's just a small mistake, if you can aprove it fast
<raphink> siretart: in revu-build, I've put
<raphink> PBUILDEROPTS="--buildresult $(pwd) --logfile ${BASENAME}.buildlog --hookdir /srv/revu1/scripts/pbuilder-hooks/"
<raphink> it should be
<raphink> PBUILDEROPTS="--buildresult $(pwd) --logfile ${BASENAME}.buildlog --hookdir /srv/revu1/pbuilder-hooks/"
<raphink> otherwise it won't work
<raphink> siretart: updated the svn with this single change, can you commit it?
<siretart> raphink: done
<raphink> thanks :)
<raphink> I think that's all :)
<siretart> raphink: could you please install a .forward file on tiber?
<raphink> how do you mean siretart ?
<siretart> I'd like to add you to the svn postcommit hook, so that you get svn mails as well
<raphink> oh ok
<raphink> so what do I need to do?
<siretart> raphink: do a 'echo raphink@youremail > ~/.forward'
<raphink> ok
<siretart> you can also configure procmail, if you wish ;)
<raphink> done
<raphink> I mean the .forward ;)
<siretart> ok
<raphink> :)
<Gloubiboulga> I have 2 packages on REVU advocated once, could someone have a look at them ?
<Gloubiboulga> it's http://revu.tauware.de/details.py?upid=1654 and http://revu.tauware.de/details.py?upid=1650
<pabs3> anyone seen Mez? if someone does, can you ping him about his debian ifolder ITP?
<Tonio_> hi
<apachelogger> is it allowed to patch binary format files into a packge (eg pictures)?
<\sh> apachelogger: how are you doing this? you can do it via uuencode/uudecode (sharutils)
<apachelogger> made a diff ;-)
<apachelogger> so how to do it via uuencode?
<\sh> apachelogger: since when is diff doing binary diffs? you can't inject binaries into a source tarball..the only way to do this, is to uuencode the picture (e.g. an icon) move it to debian/dir and uudecode it and install it via debian/rules install target
<apachelogger> well, the diff worked somehow ... but wasn't very smart ... I'll take a look at uuencode and uudecode, thx :)
<jpatrick> apachelogger: you could try .xpm's
<apachelogger> hm
<apachelogger> I think kblogger 0.4 will just not have a image, the author might have a reason to not include it
* apachelogger is writing a mail to the author
<Kyral> Morning MOTUish people
<apacheLAGger> morning
<jpatrick> Kyral: afternoon
<apacheLAGger> so there is still a really anoying problem: http://paste.ubuntu-nl.org/7994
<apacheLAGger> any ideas?
<\sh> yes
<\sh> 1. if this lib is not used by anything else, lintian-override it :)
<\sh> 2. if this lib is used by anything else then kblogger, write shlibs file
<apacheLAGger> just used by kblogger ...  so I shouldn't care about that error?
<\sh> apacheLAGger: lintian-override it :)
<apacheLAGger> ok, thx :D
<\sh> apacheLAGger: you know how to do it?
<apacheLAGger> not really .... but learning buy doing and googling ;-)
<\sh> apacheLAGger: lynx file:/usr/share/doc/lintian/lintian.html/index.html :)
<apacheLAGger> http://lintian.debian.org/manual/ch2.html#s2.4
<apacheLAGger> \sh: http://revu.tauware.de/details.py?upid=1656 :)
<dholbach> no need to lintian-override - it's a good reminder to not override it and see the message every time (and split it out once it's needed somewhere)
<apacheLAGger> dholbach: but why would it be needed?
<dholbach> the lintian-override is surely not needed.
<dholbach> Or do you mean the library?
<\sh> dholbach: it will never be needed
<\sh> dholbach: the library
<apacheLAGger> that was my point
<dholbach> "never"
<\sh> dholbach: it's a typical "local lib of kde apps"
<dholbach> You often see that libraries which are splitted out of "applications" are used at some stage.
<dholbach> Think of beagle.
<dholbach> I don't say "split it out now!"
<\sh> I wonder what inside this lib anyways...
<\sh> lemme have a look
<dholbach> Ask fabbione on his take on this.
<Simira> hey! I wanna become a MOTU!
<\sh> apacheLAGger: it's only the panel applet of kblogger?
<Simira> at least as a start to becoming a dev
<ogra> Simira, yay
<apacheLAGger> \sh: kblogger is the applet
<apacheLAGger> http://kde-apps.org/content/show.php?content=29552
<apacheLAGger> the whole app is just an applet
<\sh> jesus
<apacheLAGger> lol
<Simira> ogra: hey, wanna help me make a small application? Tollef rather wants to have a bath...
<ogra> Simira, hmm, still particulary busy here ....
<Simira> ogra: right. I'll have to wait until tomorrow evening then. Are you still working on the rollout?
<ogra> i only work on ltsp ... the LP guys do the rollout ...
<ogra> #
<\sh> ogra: is elmo with the LP guys?
<ogra> yup
<\sh> going out for a while...laters
<apachelogger> raphink: ping
<raphink> hi apachelogger
<apachelogger> hey ...I'm the kblogger guy... :)
<raphink> ok
<raphink> :)
<apachelogger> raphink: http://revu.tauware.de/details.py?upid=1657 what does the kblogger 0.3 tarball do in the list?
<apachelogger> actually the orig.tar.gz should be exactly the 0.4 from kde-apps, cause I repacked it today
<raphink> ooops
<raphink> right should be 0.4
<apachelogger> ;-)
<raphink> ok good sorry
<apachelogger> no problem
<raphink> give me the url of the 0.4 package please
<raphink> and I'll run it again
<apachelogger> http://whiletaker.homeip.net/~christian/kblogger-0.4.tar.bz2
<raphink> thanks
<raphink> apachelogger: waita  min ok?
<apacheLAGger> raphink: looks better, doesn't it?
<raphink> wait a min
<apacheLAGger> yup
<raphink> I'm doing lots of thigns
<raphink> there's still the debuild test I'm not very happy with apachelogger, have a looka t it please
<raphink> apachelogger: ok?
<apachelogger> raphink: new verison online
<raphink> ok
<apachelogger> add a unpatch rule
<raphink> I'l lhave a look
<apachelogger> s/add/added ;-)
<raphink> running the test, let's wait till it builds :)
<raphink> I'll brb
* apachelogger is grabbing a cup of coffe
<raphink> looks good now apachelogger, good job... :)
<raphink> I'll look at it after my dinner
<apachelogger> thx :)
<raphink> apachelogger: do you know of the Reviewing guideon the wiki?
<apachelogger> nope
<raphink> http://wiki.ubuntu.com/MOTU/Packages/Reviewing
<raphink> main points to check in a package
<raphink> so you can check it yourself :)
<apachelogger> ok :)
<phanatic> hi people
<sebest__> hello, is the login pass on revu the same as launchpad?
<minghua> sebest: no
<hub> sebest__: no
<sebest__> how to get a login?
<hub> https://wiki.ubuntu.com/MOTU/Packages/REVU?action=show
<sebest__> thanx
<LaserJock> hi Hobbsee
<Hobbsee> hey LaserJock
<LaserJock> how's it going?
<Hobbsee> just finished building koffice for Riddell
<LaserJock> sweet
<Hobbsee> for dapper
<raphink> cool :)
<Hobbsee> yeah
#ubuntu-motu 2006-02-10
<Pupeno> hello.
<Pupeno> Any ideas what might be triggering this error: "Use of uninitialized value in scalar assignment at /usr/bin/dh_shlibdeps line 138, <COMPAT_IN> line 1." ?
<Mez> Pupeno, depend what you're doing to make it
<stratus> ajmitch_, around?
<Pupeno> Mez: I am running "dh_shlibdeps -a --exclude=plot -l`pwd`/debian/mzscheme/usr/lib/plt/lib/"
<ajmitch_> stratus: just got back
<stratus> ajmitch_, do you care about mono?
<hub> stratus: given that he packages lot of things for Mono, I think he does
<stratus> hub, i know about that, thanks.
<ajmitch_> stratus: yes?
<stratus> ajmitch_, mono (source) needs a rebuild in dapper, mono-jit is uninstallable due to mono-classlib old dep.
<stratus> ajmitch_, mono-classlib-1.0-1.1.10 doesn't exists in dapper
<stratus> ajmitch_, btw mono-classlib-1.0 provides mono-classlib-1.0-1.1.13.2
<stratus> ajmitch_, i was going to prepare a source package but i'm having some problems debootstrapping a new dapper chroot right now.
<ajmitch_> stratus: ppc, right?
<stratus> ajmitch_, sure
<stratus> ajmitch_, i'm sorry i forgot to tell you the arch :)
<ajmitch_> find someone with an smp ppc box & we'll try & fix it
<hub> ajmitch_: smp?
<ajmitch_> hub: it seems to fail only on ppc
<ajmitch_> smp ppc
<stratus> yes, is smp really necessary?
<hub> ajmitch_: I have one PPC
<hub> not very live
<hub> but it is workeable
<stratus> no, no
<ajmitch_> stratus: it works on single-proc
<hub> I could finish upgrading it to dapper
<stratus> the problem with the dep is on ppc up too
<stratus> i can see it on my ibook g4 right now
<ajmitch_> stratus: buildd is smp
* hub has switched to intel recently
<ajmitch_> stratus: it's been a recurring problem that we can't fix with source uploads, until the problem itself is addressed
<ajmitch_> new upstream versions haven't helped
<ajmitch_> and it seems to build adequately on a UP PPC box
<stratus> ajmitch_, oh i don't know about the problem, can you elaborate a bit more?
<ajmitch_> not very much, tseng & slomo have looked at it more than I have
<stratus> weird, but what's the side effect if we just bump up the mono-classlib depends on mono source package?
<ajmitch_> things would likely break
<ajmitch_> it's a specific version dependency because the engine & classlib are closely tied
<stratus> ajmitch_, but for example is tomboy installable in non-ppc atm ?
<ajmitch_> afaik it is?
<stratus> i don't know really.
* ajmitch_ has it installed & working
<stratus> i asked to see how spread the bug was
<ajmitch_> just ppc
<ajmitch_> beagle problems are separate
<stratus> ajmitch_, oh ok.
<stratus> ajmitch_, thank you for the feedback.
<ajmitch_> sorry that it's not fixed yet :)
<stratus> np, sorry that i can't help fixing it atm.
<iBalo> Could someone please pack up a decent Bittorrent-client for Dapper (e.g. http://rufus.sf.net). Azureus sucks like most Java-stuff (and is banned on many trackers) and most others don't have features like downloading of selected files only . etc...
<StevenK> iBalo: bittornado does
<LaserJock> your welcome to contribute if you want ;-)
<Tonio_> ajmitch_: ping ?
<raphink> iBalo: package it
<sistpoty> hi folks
<raphink> iBalo: I'll be happy to help you if you need, but if you want an app in, you're the best man to get it in
<raphink> hi sistpoty
<iBalo> but does not integrate into gnome (no freedesktop tray support), multpiple downloads are a pain in the butt with it and .... i stop whining... u all know the story
<raphink> iBalo: please read the answers on the screen now that you're done typing ;)
<iBalo> ... yep :-)
<raphink> iBalo: just so you get the point, we are no more than 100 devs in Ubuntu in total
<raphink> for about 8M users iirc
<raphink> we can't package every app users want
<raphink> but you can package the app you want and we can help you to do it
<iBalo> hehe... i was just about to ask for handholding...
<raphink> iBalo: have a look at https://wiki.ubuntu.com/MOTU/Packages/REVU and https://wiki.ubuntu.com/MOTU/Packages/REVU if you're willing to help
<iBalo> When does it have to be ready for Dapper release
<raphink> and begin with reading New Debian Maintainer's Guide ;)
<iBalo> ... had a couple of glances earlier
<raphink> if you want it in Dapper, you still have a bit less than a month to get it in
<iBalo> ouch!
<raphink> oh well that' sfar enough ;)
<raphink> you get a week or two to learn to package
<Tonio_> what app are you taklin' about ?
<raphink> that can be done
<iBalo> it's not that i never packaged before.. it's the python i've got to learn
<raphink> there are python packages experts around iirc
<raphink> i'm not one I'm afraid
<raphink> look at python packages on REVU
<raphink> that should help
<iBalo> I will seriously consider that. Anyway it's ready when it's ready, and it won't for sure be on the install-cd
<sistpoty> python packaging is easy... just provide a setup.py and dh_python does all hard parts :)
<deletionlogger> raphink: already had time to look at the package?
<raphink> it won't be on the install-cd for sure iBalo since nothing from universe is
<raphink> deletionlogger: sure
<sistpoty> (at least python modules)
<deletionlogger> ah
<iBalo> I read through the forums on the sf page... the problem is, the author is a win-guy and often just thinks not in linux terms
* deletionlogger is reading the comment
<raphink> iBalo: hehe
<raphink> iBalo: you mean the upstream tarball is a .zip ?
<deletionlogger> raphink: ok, will fix that stuff
<iBalo> So to make it work to my standards this will require more than just pack the thing up
* raphink saw a .zip upstream tarball today and didn't feel like reviewing it
<raphink> iBalo: ok
<raphink> deletionlogger: I hope so
<raphink> and I'll go to bed now
<sistpoty> gn8 raphink
<iBalo> But ok, that's a fair deal... if i can get some handholding, I'll give it a try
<raphink> thanks sistpoty
<raphink> :)
<raphink> iBalo: don't hesitate asking for help here
<raphink> iBalo: there are many docs on the wiki too, use them :)
<raphink> iBalo: when you think you've got a good package, upload it to REVU and ping one of us here to review it
<iBalo> Ok, I'll investigate that further after a couple of hours of sleep,
<raphink> sure
<ToadZzZztool> hi, before sleeping... could anyone here have a look at my dhcpv6-kame package ? I've already uploaded it to REVU
<raphink> ToadZzZztool: ok very quick then
<raphink> give me the link
<raphink> and a url to the upstream tarball
<raphink> and i'll generate a report
<ToadZzZztool> http://revu.tauware.de/details.py?upid=1642
<ToadZzZztool> this one ?
<raphink> ok
<ToadZzZztool> and the upstream tarball is hidden in ftp.kame.net
<raphink> and a url to the upstream tarball please
<hub> can somebody review this: http://revu.tauware.de/details.py?upid=1472
<ToadZzZztool> raphink: i'm trying to find the complete url
<raphink> hub: same here, give me a link to the upstream tarball
<raphink> I'll generate a report
<raphink> and I'll review tomorrow
<hub> raphink: ok
<raphink> thanks ToadZzZztool
<hub> raphink: I'll put it in a comment, is that ok?
<raphink> hub: I'd rather you give me the link here
<hub> http://www.virtual-cafe.com/~dhh/tools.d/exifprobe.d/exifprobe-2.0.1.tar.gz
<raphink> so I can launch the report tool right now
<hub> then here it is :-)
<hub> okay
<raphink> now let's wait
<raphink> :)
<raphink> ToadZzZztool: got the link?
<ToadZzZztool> argh looks like they've removed the files this week
<hub> raphink: btw, what to do with files in the wrong mode?
<raphink> ToadZzZztool: I need the upstrem tarball though
<ToadZzZztool> in fact this is a big tarball containing the whole kame IPv6 stuff
<hub> 600 instead of 644
<ToadZzZztool> including the dhcpv6
<raphink> hub: either change them in the source tarball, which is not clean
<raphink> or change their mode in debian/rules
<hub> ok
<raphink> or just installthem with the right mode in debian/rules or debian/install
<raphink> ToadZzZztool: I just want to get the tarball you used for the package
<ToadZzZztool> oki then i'll put it on my website
<raphink> hub: the report for exifprobe was generated
<raphink> check the page
<raphink> and I'll have a look at it later
<raphink> ToadZzZztool: i'd rather have the one from them
<hub> ok
<ToadZzZztool> raphink: it's only a part of the whole tarball i've re-tared
<ToadZzZztool> with no modifications at all
<raphink>  propos vous avez remarqu qu'on est 3 francophones  parler en anglais l ? ;)
<ToadZzZztool> arf
<raphink> hmmpf
<hub> what are you talking about?
<ToadZzZztool> ouais en fait c'est vrai :)
<hub> ;-/
<raphink> hub: :p :p
<hub> tabarnak
<ToadZzZztool> :)
<raphink> bon allez au lit
<raphink> je regarderait a demain
<ToadZzZztool> bonne nuit
<hub> raphink: bonne nuit
<raphink> hub: tu peux jeter un oeil au paquet de ToadZzZztool si tu as le temps ?
<raphink> ;)
<ToadZzZztool> :)
<raphink> vu qu'il est plus tt chez toi ;)
<hub> ToadZzZztool: c'est quel paquet?
<raphink> ++
<ToadZzZztool> hub: http://revu.tauware.de/details.py?upid=1642
<ToadZzZztool> bon allez dodo aussi
<ToadZzZztool> bonne nuit
<Kyral> Hate me for I installed FC4 on my lapop
<hub> Kyral: I installed SuSE the otherday
<hub> Kyral: i lasted 24h, I installed KUbuntu
<Kyral> lol
<Kyral> Well, my laptop is just a toy
<hub> Kyral: it is my workstation
<Kyral> I know all about Ubuntu
<Kyral> So I thought I'd learn about Fedora on my lappy :D
<Kyral> I still like Ubuntu more...
<Kyral> I found SuSE slow as hell
<Kyral> YaST is great mind you, but the crap performance turned me off
<Kyral> Don't worry, AzureDream (my production box) will always run Ubuntu
* sistpoty recently had to update a srv from suse 9.0 to 9.3... that sucked very much
<Kyral> Gah but FC4 is so out of date...
<Kyral> Its taking like 500 Megs to bring it up to date
<Kyral> but its kinda cool that it has SELinux by default
<ajmitch_> Tonio_: yes?
<Tonio_> ajmitch_: I have a problem to get my revu account password....
<ajmitch_> what problem?
<Tonio_> ajmitch_: impossible to decrypt since I don't have the ELG-E key....
<Tonio_> gpg: encrypted with ELG-E key, ID 28E2DD3A
<Tonio_> gpg: decryption failed: secret key not available
<Tonio_> ajmitch_: do I miss something ?
<ajmitch_> do you have a sign-only key?
<Tonio_> ajmitch_: what do you mean by "sign-only" ?
<ajmitch_> a key that can only be used for signing
<Tonio_> ah, no, that's normally a normal key
<Tonio_> I can sign and crypt with it....
<sistpoty> Tonio_: what's the email you use for revu?
<Tonio_> anthony.mercatante@laposte.net
<ajmitch_> keyserver is giving me issues today
<ajmitch_> Tonio_: sistpoty can probably answer your questions far better :)
<Tonio_> ajmitch_: okay I'll se with him :)
<Tonio_> ajmitch_: just testing at my key, and maybe it is a sign-only one...
<sistpoty> Tonio_: I just sent you an encrypted mail with the pw. hopefully you can decrypt it ;)
<Tonio_> I never crypt anything, so I may be wrong when I say it could
<Tonio_> sistpoty: just trying
<Tonio_> sistpoty: it worked, thank you ;)
<sistpoty> Tonio_: np ;)
<Tonio_> sistpoty: just cause I like to understand, what was wrong in the process ? is it a known problem ?
<sistpoty> Tonio_: not quite sure what's wrong exactly...
<sistpoty> Tonio_: to my knowledge, the lost-pw feature just takes the pw and your keyid and crypts the pw with your key
<sistpoty> Tonio_: but siretart wrote that part, so maybe there is some more trickery involved ;)
<Tonio_> sistpoty: that's exactly what you've done for the mail you sent me no ?
<ajmitch_> ah, delegation of blame :)
<sistpoty> hehe, actually I just wanted to say: dunno :)
<sistpoty> Tonio_: yep
<Tonio_> well it works, that the only important thing :)
<glick> excuse me im trying to built the package gtk-gnutella according to the directions offered by the debian maintainers guide
<glick> but i always get this error...
<glick> install: cannot stat `gtk-gnutella.desktop': No such file or directory
<glick> make: *** [binary-arch]  Error 1
<glick> in the main source directory i issue the command dpkg-buildpackage -rfakeroot
<glick> and i get that error
<glick> then i tried fakeroot debian/rules binary
<glick> same deal
<LaserJock> glick: so do you have a gtk-gnutella.desktop?
<glick> LaserJock, whats that?
<LaserJock> a file
<glick> no shit
<glick> i obviously dont have it
<LaserJock> ok, well you don't have to swear at me. Are you calling dh_desktop in debian/rules?
<glick> LaserJock, no man i just do fakeroot debian/rules binary
<LaserJock> can you paste the debian/rules in a pastebin somewhere?
<glick> LaserJock, http://pastebin.com/539570
<glick> man i wish they had half decent docs on how to build packages
<LaserJock> we are working on an ubuntu packaging guide but it is still a work in progress
<LaserJock> should be ready for Dapper release
<glick> coo
<LaserJock> ok, so you should have a .desktop file in debian/
<glick> no such file exists
<LaserJock> ok, so that's the problem. you should either look for one in the source directory or make one.
<LaserJock> you can check out other .desktop files in /usr/share/applications/
<glick> what does that file do?
<LaserJock> it puts the app in the menu mostly
<LaserJock> you could not include it but then the app wouldn't be in the menu
<LaserJock> so pretty much all gui apps should have .desktop files
<glick> i find it hard to believe that it wouldnt come with one
<glick> i remimber building it before, some dude online walked me through it
<glick> and i didnt have to create or edit any desktop file
<LaserJock> well the source could install it but your debian/rules file expects to find one in debian/
<LaserJock> can you see one in the source directory?
<glick> id ont see one
<LaserJock> does the source have a Makefile?
<LaserJock> you can check the "install" rule in the Makefile to see if it is installing it
<glick> screw it i just installed the .deb from the website
<glick> seems to be working fine
<LaserJock> glick: If you just wanted to install it for yourself you could have just taken out that line in debian/rules that tries to install the .desktop file
<glick> oh
<glick> eh whateva its cool, as long as it works
<glick> thanks though
<LaserJock> np ;-)
<glick> anyone here use ghdl?
<glick> i gotta play with that
<LaserJock> no, sorry I don't
<zakame> hi MOTUs
<ajmitch_> hi zakame
<ajmitch_> recovered from meeting sabdfl yet?
<zakame> ajmitch_: of course, now switching to regular programming
<ajmitch_> hehe
<zakame> how's the rollout?
<ajmitch_> apparantly done
<ajmitch_> though I've seen no mails to dapper-changes
<Amaranth> we're on soyuz now?
<ajmitch_> wouldn't surprise me if that was broken
<ajmitch_> Amaranth: yes
<StevenK> I saw one.
<zakame> w00t!!!
<ajmitch_> StevenK: before or after the "we're open for business" message?
* zakame now tries out his tiber account, thanks siretart ! :D
<ajmitch_> it could be my procmail filtering is askew
<StevenK> https://lists.ubuntu.com/archives/dapper-changes/2006-February/005853.html
<StevenK> I think that's after.
<ajmitch_> hm, I haven't got that mail or many of those in my dapper-changes folder
<StevenK> ajmitch_: Seen this?
<StevenK> steven@liquified:~% uname -m
<StevenK> x86_64
<Amaranth> is that "Accepted" stuff on the bottom new?
<StevenK> Amaranth: No, it's different.
<StevenK> Amaranth: Compare konq-pim and poppler
<Amaranth> i thought so
<ajmitch_> the last mail I have in the folder in konq-pim
<ajmitch_> StevenK: hm? what's special about that? no amd?
<StevenK> ajmitch_: That was the last katie mail.
<zakame> heya Hobbsee
<StevenK> ajmitch_: That I'm now on an amd64 instead of my dual Athlon.
<Hobbsee> hey zakame
<ajmitch_> StevenK: aha
<StevenK> ajmitch_: Which stands to reason that Soyuz has changed the mail headers, and therefore broken your filtering.
<ajmitch_> StevenK: congrats, can I be jealous now?
<StevenK> ajmitch_: Sure. :-)
<ajmitch_> StevenK: sure, but I'm trying to track down what folder it ended up in :)
* ajmitch_ is grepping his procmail logs :)
<StevenK> ajmitch_: http://wedontsleep.org/~steven/img_0920.jpg
* StevenK switched from procmail to Sieve
<ajmitch_> nice little case
* StevenK nods.
<ajmitch_> compared to the monster I have waiting for the dual-core amd64 I've priced up :)
<ajmitch_> what do you have in it?
<ajmitch_> From dapper-changes-bounces@lists.ubuntu.com Sun Feb 05 06:36:12 2006
<ajmitch_>  Subject: Accepted rhythmbox 0.9.3.1-0ubuntu1 (source)
<ajmitch_>   Folder: launchpad                                                        6199
<ajmitch_> bah
* ajmitch_ just checked that folder
<StevenK> It's only a Celery 2.8 unfortunately.
<StevenK> (All I could afford)
<ajmitch_> I see there's too much bug mail in there, I have to split it
<ajmitch_> at least they still have an X-Katie header
<StevenK> However, the motherboard can deal with the newer dual core CPUs, too.
<ajmitch_> so what's your new amd64 box?
<StevenK> ajmitch_: A Celery 2.8, 512Mb RAM, 80Gb PATA
<StevenK> Nothing special, really.
<ajmitch_> ah, em64t?
<StevenK> Yup
<ajmitch_> I didn't realise the celerons were 64 bit now
<StevenK> It's small, quiet, and can compile xemacs21 without throwing an ICE.
* ajmitch_ is aiming for something a little faster
<ajmitch_> since it has to replace my athlon xp 1800+
<ajmitch_> List-Id: header is split over 2 lines
<ajmitch_> which broke my procmail filter
<ajmitch_> https://launchpad.net/distros/ubuntu/+builds still doesn't look at all helpful
<StevenK> You're right.
<StevenK> It feels ... clunky.
<zakame> well that at least a step nearer soyuz :)
<ajmitch_> a lot of launchpad's UI still feels very clunky
<ajmitch_> like the stock forms have been used & it hasn't been tweaked suitably for the data being displayed
* StevenK nods.
<ajmitch_> '1-20 of 1,000,000 results' isn't useful :)
<zakame> heh
<ajmitch_> I guess we'll just have to put pressure on them until they break :)
<ajmitch_> "go harass your local launchpad developer today!"
<Hobbsee> rofl
<Kyral> lol
<zakame> hehe
<StevenK> I think the Distro team is going to kill the Launchpad team before long. :-)
<zakame> worth to put that in /topic?
<ajmitch_> zakame: sure :)
* ajmitch_ is fortunate to have one within walking distance now ;)
<Hobbsee> hey you people can probably help me.  I've got a chroot created in ~/breezy, and i need to build a package in the chroot - how do i go about doing that?  (i already have a dapper pbuilder)
<ajmitch_> Hobbsee: ah, it would be easier to use a breezy pbuilder setup, instead of a chroot
<ajmitch_> but otherwise you just use chroot to get into there, and build the source normally
<Hobbsee> right, which means i'd overwrite my dapper one?
<ajmitch_> no, you have separate configs for pbuilder
<zakame> yep
* ajmitch_ has hoary,breezy,dapper,sarge & sid pbuilder setups
<zakame> so you could just do `dchroot -c breezy`
<Hobbsee> hehe
<Hobbsee> dchroot -c breezy - what's that do?
* StevenK has 5 pbuilder chroots.
<StevenK> Two each for Breezy and Dapper (i386 and amd64), and one for Sid i386.
* zakame loves chroots
<ajmitch_> StevenK: sadly I only have i386 to play with at the moment
* StevenK has found and fixed a build failure using the new interface.
* ajmitch_ is going to go back to reading a book
<ajmitch_> computers irritate me today
<StevenK> Blah.
<ajmitch_> :)
<StevenK> What do I use to sign a dsc and changes files?
* StevenK is having a blonde moment.
<ajmitch_> debsign
<StevenK> Ah, ta
<ajmitch_> or debrsign if your gpg key is on another box
<zakame> debsign?
<zakame> (though gpg --clearsign should also work)
* ajmitch_ wanders off again
<zakame> wb LaserJock_
<LaserJock_> thanks zakame
<phanatic> hi people
<Gloubiboulga> hi phanatic
<phanatic> re Gloubiboulga
<Gloubiboulga> morning \sh
<\sh> moins
* ..[topic/#ubuntu-motu:\sh] : Ubuntu Masters of the Universe: Ubuntu Universe Repository Maintainers | http://wiki.ubuntu.com/MOTU | http://wiki.ubuntu.com/MOTU/Documentation
<\sh> guys, who is playing the proxy to mdz/kamion for UVF exceptions while dholbach is on holiday?
<siretart> morning
<\sh> moins siretart
<VincentMX> hi
<VincentMX> is it hard to make packages? i want to help Ubuntu
<sivang> VincentMX: this may have some stuff to start with, search around the wiki there are plenty of resources http://doc.ubuntu.com/ubuntu/packagingguide/C/
<VincentMX> ok
<sebest> VincentMX some software are more difficult to package than others
<VincentMX> ok
<sebest> package with good autotooling are quite easy
<VincentMX> ok
<VincentMX> hmm, i've read the page for how to create a package with debhelper, but that involves compiling
<VincentMX> doesn't that require a fast computer?
<VincentMX> my computer should be fast enough, but my BIOS kinda sucks, so i have 2 bars of 64MB RAM, witch should make 128. but my BIOS is too old, so it won't get more out of it as 88MB :S
<Gloubiboulga> VincentMX, get a source package and try to build it
<VincentMX> ok
<zakame> evening MOTUs :)
<Gloubiboulga> hello zakame
<zakame> heya Gloubiboulga :)
<Gloubiboulga> zakame, my libswitch package has been uploaded :)
<Gloubiboulga> `binary-indep: binary-arch' was ok
<zakame> Gloubiboulga: cool, I'll try building it then :)
<nlindblad> I need a German
<zakame> er?
<nlindblad> I must talk grammar
<nlindblad> preferable German grammar
<zakame> Gloubiboulga: hmm where is it? I couldn't find it in REVU :/
<zakame> oh it's at the very bottom, ready for upload
<Gloubiboulga> zakame, yes, ready to gp
<Gloubiboulga> waiting for elmo now
<Gloubiboulga> s/gp/go
<zakame> Gloubiboulga: ooh, my bad, I thought you meant it needed REVU, it was uploaded already, silly me :P
<zakame> Gloubiboulga: rock on then with gswitch :D
<Gloubiboulga> zakame, gswitch depends on libswicth, and can't be build with pbuilder for the moment
<zakame> yeah
<zakame> but it'll be just a while, or maybe a day
<Gloubiboulga> yep
<Toadstool> hi everybody
<Toadstool> i'd like my package to be REVUed but i need to provide the upstream tarball, the problem is i've only packaged a part of a very big tarball
<Toadstool> should I provide a clean retared version of the part I packaged ?
<zakame> hm, why is it BIG?
<Toadstool> 'cause it's the kame IPv6 pack which contains all the kernels patches and a lot of IPv6 daemons such as rtadvd
<Toadstool> and I've only packaged the dhcpv6 part
<Tonio_> hi all
<Toadstool> hi
<Toadstool> any suggestion about my problem ? :)
<zakame> heya Hirion Tonio_
<zakame> Toadstool: ah
<Tonio_> Toadstool: I think if you explain clearly that you extracted a part of  big tarball in the changelog, that might be okay
<Toadstool> hum ok
<Tonio_> Toadstool: although you might be ask "why didn't you package the all application" ^^
<Toadstool> because radvd and the other apps are already packaged but there's no decent dhcpv6 solution for the moment :)
<Tonio_> that can be explained in the changelog too ;)
<Toadstool> let's do that then
<Tonio_> I would personally accept this.... some might not
<Tonio_> you may have to ask e few MOTUs to get the global feeling on that point
<Toadstool> ping everybody here :)
<Tonio_> ;)
<Toadstool> and I suppose I have to put the clean tarball somewhere on the net so that it can eventually be REVUed...
<Tonio_> hum, if it is not the upstream tarball, that might not be necessary...
<Toadstool> the thing is the kame.net guys used to make packages with each app but now they only ship the whole stuff in one big tarball :/
<Tonio_> comparing md5sum is a good way to be sure the upstream is unchanged, but it is not an absolute requirement....
<Tonio_> another kind of exception is for example packages build threw a svn....
<Toadstool> yeah well i'm going to put all this details in the changelog and we'll see :)
<Tonio_> yup
<Toadstool> thanks for the answers
<Tonio_> np ;)
<thierry> siretart : hi, could you review my package? libfxruby1.4
<thierry> siretart : it's starting to get urgent if I want it in dapper :)
<siretart> I see. I try to do it later this evening.
<thierry> siretart : k thanks
<thierry> ajmitch_ : are you busy?
<zakame> siretart: ping, many thanks for tiber! I promise not to break it! :D
<siretart> zakame: that would be great ;)
<zakame> gn8 all
<phanatic> hi people
<Toadstool> could someone have a look at my dhcpv6-kame package on REVU please ? :)
<sistpoty> hi folks
<sistpoty> can s.o. with main privs sponsor me an upload?
<slomo> sistpoty: show me the debdiff :)
<sistpoty> slomo: I put it on revu, but I can send you a debdiff as well ;) (min12xxw)
<siretart> huhu sis	
<siretart> huhu sistpoty
<sistpoty> hi siretart
<siretart> f'king wlan here ;)
<slomo> hi siretart, sistpoty btw :)
<sistpoty> hi slomo ;)
<slomo> sistpoty: debdiff would be easier imho :) or is it a new upstream version?
<sistpoty> slomo: no, just some cosmetic changes... just a minute ;)
<siretart> huhu slomo
<slomo> are the buildds sleeping currently? nothing gets build currently from what i see...
<sistpoty> a package I uploaded after soyuz conversion got actually built after some time :)
<slomo> yes, avahi got build too after some time ;) but currently nothing is building although some stuff wants to be build
<sistpoty> hm...
<sistpoty> slomo: http://tiber.tauware.de/~sistpoty/slomo/min12xxw_ubuntu1_to_ubuntu2.debdiff
<sistpoty> slomo: but you'll need to delete debian/README.Debian and debian/Minolta-PagePro_1400W-min12xxw.ppd (at least patch -p0 didn't do that, it just made these files have size 0)
<slomo> yes, i noticed that too :)
<slomo> uploaded
<sistpoty> slomo: cool, thx :)
<Toadstool> hi guys, could someone check my dhcpv6-kame package on REVU please ?
<slomo> sistpoty: hmm, i wonder if this upload is listed now under https://launchpad.net/people/slomo/+packages or https://launchpad.net/people/sistpoty/+packages
<sistpoty> slomo: maybe both?
<sistpoty> slomo: there is a section maintained and a section uploaded packages... my guess is that it will show as maintained on my page and as uploaded on yours ;)
<sistpoty> oh slomo: btw.: I created an uncommon programming languages team on LP and added you as member :)
<slomo> sistpoty: well, it is uploaded by me... but you did the changes... what would happen now when someone else was the maintainer, you did the change and i uploaded? your name gets lost? ;)
<slomo> sistpoty: yes, good work :) now we only need to do something with that team ;)
<sistpoty> slomo: interesting question :)
<sistpoty> slomo: yes... and somehow the description doesn'
<sistpoty> +t get displayed, I have no clue why
<slomo> oh nice... i get an ACCEPTED mail too now for sponsored uploads :)
<sistpoty> hehe, but I didn't get one any longer
<slomo> sure
<slomo> the mail was to Launchpad Archiver <lp_archive@localhost.nifelheim.yggdrasil>, Sebastian Droege <mail@slomosnail.de>, Stefan Potyra <sistpoty@ubuntu.com>
<slomo> the lp_archive thingie is interesting ;)
<sistpoty> hm... strange, maybe it went a slower way than the mail to changes-list
<slomo> hm and no idea about the description... it should be there :/ maybe ask on #launchpad
<sistpoty> I will, but not today ;)
<slomo> hmm min12xxw was uploaded by nobody ;)
<slomo> but the new version lists you as maintainer
<sistpoty> slomo: uploaded by nobody? what are you referring to?
<siretart> slomo: I uploaded a new mplayer, enabling caca and aa outputs.. it was sitting in svn for some time
<slomo> sistpoty: the "uploaded packages" on our launchpad pages
<slomo> siretart: yes, i already saw it :) thanks... for some reason i missed these two while creating our new package
<siretart> slomo: say, all these 'rebuilt packages' that was uploaded by you to link agains libxine-main
<siretart> slomo: do they lack support for ffmpeg now?
<sistpoty> hehe, funny system :)
<slomo> siretart: oh damn... yes... i need to add libxine-extracodecs dependencies later to them (that was the plan anyway)... but first we need to get xine-extracodecs moved in the correct section and not splitted over universe and multiverse
<siretart> slomo: so you are suggesting an alternative build dependency: first try the universe package, if that fails, try the main one
<siretart> slomo: but this also means that packages in main won't never ever be able to show mpeg4/divx vidoes, even if you have universe enabled, no?
<slomo> siretart: nope... the main one is always the b-d. the multiverse (or universe... nobody knows ;) ) one only contains the 3 plugins, nothing else...
<slomo> siretart: libxine.so.* is in libxine-main1, libxine-extracodecs only contains the 3 .so for mad, ffmpeg and faad
<siretart> slomo: so the universe package is a plugin replacement
<siretart> aah, okay. I see
<slomo> siretart: no replacement... only additional plugins :)
<siretart> ok
<slomo> but we need elmo to move it to the correct section before we can add dependencies on the extracodecs package in the packages in multiverse (and universe?)
<slomo> but i guess he'll move the stuff to multiverse
<siretart> hm. I see
<siretart> perhaps we can ask in #launchpad as well?
<siretart> because it is getting pretty urgent
<siretart> for us
<slomo> i sent elmo two mails about it and he didn't answer one of them...
<slomo> hm, but maybe everything gets to multiverse now automatically... and was blocked only by the packages in universe depending on libxine1c2
<siretart> I don't think so
<siretart> let's ask Kamion if promotions/demotion are being done automatically now
<siretart> slomo: btw, arn't demotions/promotions done by Kamion anyway?
<slomo> but it would explain why libxine-extracodecs is in multiverse and the sourcepackage and libxine1c2 in universe
<siretart> hm
<slomo> no idea... afaik elmo is the one to ask for legal questions
<siretart> hm
<slomo> and elmo wasn't too happy about Kamion freeing xine-extracodecs from NEW ;)
<slomo> so i guess it's elmo's job
<siretart> I see..
<slomo> siretart: can i host a mono-ppc repository on tiber? or would that eat too much traffic?
<marcin`> hello MOTU
<marcin`> got a question
<marcin`> could you guys tell me what is preferred metod for implementing database management scripts in deb packages?
<marcin`> I would like to package web application that uses mysql or postgresql database
<marcin`> and I would like to use dbconfig-common with my packages but unfortunately it's documentation is very limited and I'm not sure if dbconfig-common is preferred tool
<marcin`> while it isn't in ubuntu main
<marcin`> anyone?
<siretart> slomo: I don't think so. go ahead
<slomo> siretart: ok, thanks :) when it takes too much traffic later just tell me and i'll remove it again
<Kyral> Hey MOTUish people
<bmonty> hey Kyral
<Kyral> Sorry I haven't been all that active lately
<Kyral> college has been taking my time
<Kyral> whoa..thats interesting, no Dapper updates this morning
<bmonty> anyone have any experience with nfsv4?
<siretart> bmonty: only that it is only useful with a decent kerberos setup, which I need to look at first
<bmonty> I have that :) (with LDAP)
<bmonty> i looked at afs, but it seems way too complicated
<siretart> bmonty: do you have some nice tutorial for setting up a neat kerberos server with openldap on debian/ubuntu?
<bmonty> siretart: I've been thinking about doing that
<bmonty> I have to go back and make sure I understand exactly how I got it working on my server
<bmonty> siretart: there is info on how to set up ldap and kerberos scattered over the internet...I had to use several sources to get everything working
<siretart> bmonty: oh, if you could write a small howto, that would be awesome
<sistpoty> Toadstool: I just did a quick review for dhcpv6-kame... if you have questions about my comments, just ask
<raphink> hub: do you really need exifprobe on REVU?
<raphink> hub: hmm there's something I don't get abou tthis package
<raphink> hub: from looking at the changelog, exifprobe was in breezy, but I can't find it
<raphink> sistpoty: I couldn't find the upstream tarball for dhcpv6-kame. did you find it?
<j2daosh> http://paste.ubuntu-nl.org/8068
<sistpoty> raphink: by looking at the changelog, this appears to be a stripped doewn version of s.th. on ftp.kame.net
<raphink> yes
<raphink> that doesn't give me the tarball though ;)
<j2daosh> can someone explain my syslog to me? my computer turned on (dont know how) at 10am... im looking through that log i just posted and it is talking about a secret cookie, and setting up slaves, and a "loop" thingie".... has someone gained access to my box?
<sistpoty> raphink: because of that I commented that I want a get-orig-source target
<sistpoty> j2daosh: have you tried asking in #ubuntu yet?
<j2daosh> yep.. and ubuntu off topic
<raphink> sistpoty: ok
<j2daosh> ubuntu off topic sent me here
<raphink> wonder why
<raphink> this has nothing to do with here from what I can read
<raphink> seems linked to gdm only, thus not universe stuff
<j2daosh> but what is the secret cookie?
<j2daosh> and do the ubuntu programmers really use terminology like "loop thingie"?
<raphink> lol
<raphink> why not
<raphink> ;)
<sistpoty> hehe, "Loop Thingie"... this perfectly looks like FOSS :)
<raphink> yep
<raphink> that's clear enough ;)
<raphink> everybody knows what a loop thingie is :)
<apachelogger> raphink: salut
<raphink> yop apachelogger
<j2daosh> well not everyone apparantly ::points at himself::
<j2daosh> so nothing is wrong?
<raphink> dunno
<apachelogger> raphink: I've now add clean rules for config.log and config.status
<raphink> I'm not a gdm dev or specialist
<raphink> cool
<j2daosh> ok... can u answer this then possibly... where can i find/view all my cron/init files? i want to know exactly what is running when the comp starts.
<raphink>  /etc/init.d/ for init files
<raphink> crontab -e for crontab
<sistpoty> j2daosh: I don't think anything is wrong... but if you're paranoid, you could install chkrootkit
<hub> raphink: exifprobe has never been in any distro
<raphink> hub: why then are there two entries for breezy in the changelog?
<j2daosh> have that installed already... dont know where to find the results of it or even how to run it though
<hub> raphink: because I think the package has been on REVU for breezy
<hub> raphink: look at the first upload date
<hub> raphink: on REVU
<raphink> hub: as long as it's on REVU, there should be only 1 changelog entry
<hub> raphink: well at that time nobody told me anything
<raphink> please just remove the 2 old ones and keep the last one as initial release
<raphink> ok :)
<sistpoty> j2daosh: just run "sudo chkrootkit"... it will give it's report on stdout
<raphink> well I'm telling you now
<j2daosh> stdout? is that a file or will it go str8 to the screen?
<hub> raphink: yeah well at the last upload I didn't know either
<j2daosh> i know it means standard output... but that is all i know
<sistpoty> j2daosh: straight to screen ;)
<raphink> j2daosh: when you run `ls`, it lists the files in the current folder in the standard output
<raphink> :p
<j2daosh> ahh ok...
<j2daosh> :)
<raphink> hub: well then I think since you learned quite a lot since then, you can check your package again now :)
<j2daosh> ok well thank you for your help everyone
<Toadstool> thank you very much sistpoty for you review
<sistpoty> np Toadstool
* sistpoty is off again
<sistpoty> cya
<phanatic> hi people
<phanatic> raphink: ping
<raphink> pong phanatic
<phanatic> raphink: a new upstream version of gnome-rdp was released
<raphink> cool
<phanatic> shall i upload it to revu and file an uvf exception?
<phanatic> or what to do?
<raphink> phanatic: maybe you could send a UVF exception request yourself
<raphink> yes you can do that phanatic
<phanatic> shall i only file the uvf exception, or also upload the package to revu?
<raphink> do both, that's fine
<raphink> or rather
<raphink> well
<raphink> no just send the uvf excp request to ubuntu-motu ML
<phanatic> okay
<siretart> does anyone know if this would work for planetplanet? -rw-rw-r--  1 www-data www-data 10476 23. Nov 12:46 style.css~
<siretart> argl
<siretart> I meant this: http://tauware.de/index.php?option=com_rd_rss&id=2
<siretart> seems like
* Kyral contemplates doing LFS in his spare time..
<Gloubiboulga> siretart, I have just seen that http://revu.tauware.de/details.py?upid=954 needs to be nuked
<hub> raphink: uploaded again, reduce the version #
<raphink> cool :)
<raphink> I'll look at it later
<raphink> I'm developping now ;)
<raphink> or trying to ;)
#ubuntu-motu 2006-02-11
<ajmitch_> afternoon
<LaserJock> hi ajmitch_
<raphink> yeepee
<raphink> hello ajmitch_ && LaserJock
<LaserJock> hi raphink
<raphink> :)
<raphink> I'm having lost of fun :)
<raphink> developping revu-tools :)
<raphink> now there's no need for arguments in it anymore :)
<raphink> this was my goal tonight ;)
<raphink> for lazy reviewers :)
<LaserJock> I'm trying to figure out what to do when I get my Intel iMac tomorrow
<Hobbsee_away> LaserJock: defenestrate it? :P
<Hobbsee_away> siretart: ping
<raphink> hehe
<LaserJock> I've got to figure out how to get access to my Ubuntu box so I can continue contributing
<LaserJock> I think I can just take it home but then I need to figure out how to ssh to it behind my dsl router :(   I'm not very good with networking.
<crimsun> just configure your dsl "router" to forward incoming tcp/22 to your Ubuntu box
<LaserJock> but how do I know what the dsl routers IP is?
<LaserJock> from the outside
<Hobbsee_away> dont you do it from one of the inside computers?
<LaserJock> don't the inside computers just see it's local lan IP?
<Hobbsee_away> er.....yeah...i think so.  as in 192.168.50.1 or whatever?
<crimsun> LaserJock: your "router" more than likely has an admin interface (Web-based)
<crimsun> LaserJock: that interface would reveal the pertinent info
<LaserJock> crimsun: right, I've been to it from the inside, but how do I see what its public IP is?
<Hobbsee_away> but you have to know how to get to the admin web-based interface
<crimsun> LaserJock: from the outside? Have you sshed to any remote boxes from an internal machine?
<crimsun> and don't svn commits log the IP?
<LaserJock> I could
<crimsun> barring that, check the full headers of any e-mails sent to any mailing lists
<LaserJock> but because it is dsl the IP switches sometimes, it isn't static
<crimsun> if you use a Linksys wrt54g AP, then it has a built-in dyndns client that you can configure
<crimsun> bbl
<LaserJock> I just need to figure out a way to tell what it is from the inside computer. I guess I could have an inside computer email every so often and I could get it from there
<siretart> 
<Lathiat> LaserJock: alot of those dyndns services will use the incoming ip
<Lathiat> for the web request
<LaserJock> Lathiat: so how would I minipulate those to have an Ubuntu box inside the network send the router's public ip to me outside?
<Lathiat> LaserJock: you nat the ubuntu box out right?
<LaserJock> umm, I think so
<Lathiat> so
<Lathiat> when you connect out
<Lathiat> the dyndns server sees your real ip
<Lathiat> so it just takes that?
<LaserJock> so I can have it ssh my outside box?
<LaserJock> I hate to have an open ssh connection all the time just to find the IP
<Lathiat> yes
<Lathiat> you install a dyndns client
<Lathiat> and it updates a host like
<Lathiat> laserjock.dyndns.org
<Lathiat> with whatever your ip is currently
<hub> wonderful
<Lathiat> based on what it conencts out as
<Lathiat> which it will do automatically
<hub> trying to print from t-bird or firefox freeze
<hub> grrr
<LaserJock> Lathiat: ohhhh, now I see. Thanks.
<thierry> siretart : did you have time to review my package? libfxruby1.4
<thierry> any motu who could review libfxruby1.4 ???
<Lathiat> thierry: is it on revu?
<thierry> Lathiat : yep
<raphink> siretart: ping?
<thierry> Lathiat : are you going to review it?
<Mez> raphink, sup? revu stuff?
<raphink> Mez: yep :)
<raphink> Mez: siretart told me he would add me rights to commit the svn to REVU
<raphink> but I don' tknow how to do so
<raphink> I'm commited my changes to the svn as update 122
<Mez> http://revu.tauware.de/cgi-bin/trac.cgi
<raphink> Mez: can't seem to find where it tells how to commit the svn hooks
<raphink> maybe it's just because I'm a bit tired,but I don't see it :s
<Mez> *shrugs*
<Mez> I'm not too sure
* Mez hasnt used svn in about 6 months
<raphink> nm, I'll ask siretart tomorrow then :)
<raphink> that's fine
<raphink> I won't use it tonight anway I'm going to bed
<raphink> :)
<raphink|sleep> gn8 everybody
<Mez> night
<CosmoDad> when are merges being put into universe so I can install them via apt?
<raphink|sleep> CosmoDad: in 8 months
<CosmoDad> raphink|sleep: and which packages will be put into backports?
<raphink|sleep> the ones you request, with a good reason to request them, and that :
<raphink|sleep> * build from dapper package in breezy without a change
<Mez> CosmoDad, best to ask me about backports
<raphink|sleep> * have a good reason to be backported
<raphink|sleep> Mez: talking about backports, what's the status for pureadmin ?
<CosmoDad> Mez: I'm using vpnc and been reading about some bugs it has some month ago
<Mez> raphink: WIP
<CosmoDad> Mez: and I wondered if upgrades ever become available anywhere before dapper, possibly backports
<raphink|sleep> WIP??
<raphink|sleep> Mez: what's that?
<Mez> Work in progress
<raphink|sleep> ohok
<raphink|sleep> thanks
<Mez> CosmoDad, nothing gone to mainling list about it
<raphink|sleep> not that I mind about this package actually ;)
<raphink|sleep> ok
<raphink|sleep> I'm really gone now
<raphink|sleep> bye
<CosmoDad> Mez: read about it on Ubuntus "bugzilla"
<Mez> not a request fr backport
<CosmoDad> Mez: you mean it hasn't been requested in malone or malone is not there for requests?
<Mez> I mean - we havent had any request for it to be bakported that I can find (all requests to ubuntu-backports@lists.ubuntu.com)
<CosmoDad> Mez: so is there any relation between MOTU and backports?
<Mez> vaguely.
<CosmoDad> I mean why wouldn't merged packages be put into backport?
<Mez> not unless requested, no
<CosmoDad> so if merged packages are only for the next release of ubuntu, why is merging done 8 month prior to releasing?
<CosmoDad> just wanna understand how things work...
<crimsun> because we hand-merge
<crimsun> and 16000 packages to hand-merge is no joke for a half-dozen people.
<ajmitch_> and it wasn't said that merging is done 8 months prior to release
<CosmoDad> ok..
<ajmitch_> 'merging' is just a name for getting the newer versions from debian & incorporating our changes
<ajmitch_> which is done at the start of each release cycle
<ajmitch_> up until upstream version freeze time, when we take no new upstream versions in
<CosmoDad> I understand
<CosmoDad> can you sum up the major things you need to do when merging?
<CosmoDad> except for upgrading the version field..
<ajmitch_> depends on the package
<CosmoDad> I mean what's the major differences between debian and ubuntu packages?
<tseng> there is none
<CosmoDad> so what's an example for "our changes" that need to be "incorporated"?
<crimsun> differing build-dependencies, packaging differences, and so on
<CosmoDad> ok
<CosmoDad> I wonder why build-deps are different in debian and ubuntu, but I guess there's plenty of docs on your site that I should take a look at...
<Mez> CosmoDad, because some things we've updated faster than debian- for example, python in ubuntu default is 2.4 - in debian, 2.3
<Mez> therefore we need dfferent build deps for ubuntu python stuff
<CosmoDad> that makes sense
<CosmoDad> but isn't ubuntu based on debian unstable on each release?
<ajmitch_> yes
<ajmitch_> and debian unstable is still behind in a number of areas
<CosmoDad> so you do additional upgrades on top of debian unstable?
<Mez> yes - we focus on some stuff and bump it higher/faster than debian
<CosmoDad> so what will happen if I file a (valid) backport request for vpnc: will you use a merged/synced version or repeat the process or backporting for yourself?
<Mez> we backport from dapper version to breezy
<CosmoDad> and what's the version of a package in dapper based on?
<Mez> depends on the package
<Mez> currently dapper version = debian version
<CosmoDad> debian sid version that is?
<Mez> sid/etch
<zakame> afternoon MOTUs :)
<Gloubiboulga> morning zakame  :)
<zakame> heya Gloubiboulga :)
<LaserJock> hi zakame and Gloubiboulga
<zakame> heya LaserJock :D
<Gloubiboulga> hi LaserJock :)
<LaserJock> how's it going guys?
<Gloubiboulga> very well, i'm on holidays ;)
<zakame> I'm blogging about ABT/Ph last week :)
<LaserJock> hmm, I'm got back from a conference and am trying to get caught up and organized. Also I'm getting an Intel iMac tomorrow so I'm figuring out how to get ssh and vnc set up so I can access my Ubuntu box from it.
<jsgotangco> that shouldnt be complicted
<zakame> yay!
<LaserJock> yeah, I think I got it all figured out
<marcin`> hello MOTUs
<zakame> heya marcin` long time no c
<marcin`> could someone help me with packaging some webapp?
<marcin`> I would like to set it up properly with webapps policy
<marcin`> but I'm not sure how should I configure webapp with apache...
<marcin`> currently I just got shortcut from /usr/share/webapp to /var/www/webapp and it is ok
<marcin`> but not with webapp policy
<marcin`> any suggestions how to configure this stuff?
<glick> hello?
<LaserJock> hello glick
<glick> excuse me, quick question, if you delete a user throught the gnome user thingie, does it delete all traces of that user? including all files and such? no one in #ubuntu knows thought one of you might?
<LaserJock> like ~/ ?
<glick> yeah and mailbox files and stuff like that
<zakame> well it should work like deluser, right?
<glick> i dont know how deluser works :D
<LaserJock> glick: "man deluser" is your friend ;-)i
<zakame> hehe, well i could be wrong, but I don't think it does remove all traces of the user's files in /home
<LaserJock> although --remove-all-files would probably get close
<ajmitch_> evening
* Gloubiboulga is thinking about adding his name on the CommunityCouncilAgenda in "Member candidates" section
<Gloubiboulga> next CC is tomorrow, is it too late ?
<phanatic> hi people
<Gloubiboulga> hi phanatic
<Gloubiboulga> hi Tonio_
<Tonio_> hi :)
<phanatic> hey Gloubiboulga :)
<raphink> tthanks for committing the svn siretart
<siretart> raphink: n/p
<raphink> :)
<Tonio_> re all....
<thierry> anyone who could review my package? http://revu.tauware.de/details.py?upid=1589 , siretart?
<raphink> thierry: can you provide me a url to the upstream tarball please?
<siretart> thierry: better ask lucas, since he knows ruby a lot better than I do
<lucas> thierry: please add a watch file
<phanatic> hi people
<lucas> I don't see where you generate the manpage
<lucas> your -dev package is empty
<lucas> either it's not necessary, or something wrong happened
<lucas> your other package is also empty
<lucas> have you checked your package before uploading ?!
<lucas> Your note about ruby in the Description is useless.
<lucas> add the homepage for libfxruby instead
<lucas> and provide a real description (like what FOX is)
<lucas> and please explain why libfxruby1.4-dev is arch: any and not arch: all
<lucas> thierry: you got all that, or should I copy/paste it to revu ?
<thierry> lucas : yeah please since I don't have time to fix all that right now
<lucas> done
<thierry> :) thanks a lot
<stratus> is there a UVF exception requests list in wiki?
<stratus> buxy, ping
<lucas> stratus: no, you have to read the ML archives
<buxy> stratus: pong
<stratus> lucas, np, i'm subscribed and i see the messages about UVF exceptions there. I just asked because i said about bzrtools 0.7 and dholbach was going to accept it, but nothing yet. It's important because bzrtools 0.6-2 is uninstallable
<lucas> I think that the people reviewing exceptions are lagging behind
<lucas> also, UVF exceptions are only processed once a week
<stratus> lucas, hmm np.
<stratus> lucas, what about DCT and all that?
<lucas> quite stuck currently since I'm busy with real life stuff
<lucas> but I hope to work on this next week
<aitor> hi
<zakame> evening MOTUs
<sistpoty> hi folks
<Gloubiboulga> hey sistpoty
<sistpoty> hi Gloubiboulga
<Gloubiboulga> hi zakame & aitor too :)
<stratus> lucas, oic
<aitor> hi you too
<aitor> :)
<Toadstool> hi everybody
<zakame> heya sistpoty :D
<sistpoty> hi zakame, aitor, stratus :)
<sistpoty> and hi Toadstool ;)
<stratus> sistpoty, morning
<Toadstool> sistpoty: about the get-orig-source target for dhcpv6-kame, should it download the whole tarball from ftp.kame.net or assume the tarball is already locally available ?
<zakame> heya Gloubiboulga
<sistpoty> Toadstool: it can download the whole tarball. you won't get around to call that really often ;)
<sistpoty> Toadstool: you could also try to handle this with a watch file (not sure though, how much you can tweak there)
<Toadstool> hum looks like it's really tricky with a watch file :)
<zakame> heya Toadstool
<sistpoty> he, can't say, haven't tried that yet... it's your choice ;)
<Toadstool> hi zakame
<phanatic> hi zakame
<phanatic> zakame: http://revu.tauware.de/details.py?upid=1579 please tell me what's wrong with the long descriptions (and which one(s)?)
<Toadstool> sistpoty: do I have to add a dependency to wget somewhere in my debian/control if I choose the download target thing ?
<zakame> heya phanatic and Toadstool :D I see you're doing some REVU work :)
<sistpoty> Toadstool: to my knowledge you don't need that, since get-orig-source is not called during the build process
<Toadstool> ok
<zakame> damn my dialup's so sucky tonight :((
<zakame> phanatic: lemme check
<phanatic> zakame: thanks
<sistpoty> lucas: I just saw your comments to libfxruby... libfxruby and -dev must be arch:any, since the -dev contains (or should contain) the static library
<sistpoty> lucas: and if upstream provides distinct sources, these should also be made distinct debian source packages... if libfox get's updated, it's a transition
<lucas> ok, I didn't know that since the -dev pkg was empty
<sistpoty> lucas: problem is that stuff under /usr/... are touched during build which is a nogo (and ftbfs for that reason)
<lucas> couldn't we package libfxruby with a conflict to prevent installation of too new libfx verisons ?
<sistpoty> lucas: I don't see the point in this...
<lucas> no having several source packages for the same little library that hardly nobody will use
<sistpoty> lucas: if libfox were updated with incompatible api, the way to go would be to create libfox1.x and have both libs around, with the new version conflicting the old one
<lucas> yeah
<sistpoty> lucas: then shlibs-depends should prevent the new lib from getting installed
<lucas> but what about libfxruby ?
* sistpoty looks
<lucas> libfxruby could use a depend libfox >= 1.4 and conflict libfox >= 1.5
<sistpoty> lucas: libfxruby will have a dependency on the libfox version through shlibs:depend
<sistpoty> +s
<sistpoty> lucas: conflicts would be the wrong thing, since conflicts may only be used for packages wich contain the same files
<lucas> sorry
<Lathiat> X-Katie: Launchpad actually
<lucas> what I meant was something like that:
* Lathiat laughs
<lucas> Depends: python (>= 2.4), python (<< 2.5),
<lucas> anyway
<lucas> the package is far from being ok
<lucas> we can discuss this later
<sistpoty> lucas: yes, it is...
<sistpoty> lucas: and the dependencies should get filled in by shlibs:depends ;)
<sistpoty> (there can be no libfox1.4-dev with a different api, since this wouldn't be libfox1.4-dev any longer)
<sistpoty> s/different/incompatible/
<TomaszD> could comeone point me to the MOTU list?
<TomaszD> *someone
<sistpoty> TomaszD: what motu list do you have in mind?
<TomaszD> the one with all the uvf exceptions listed
<TomaszD> as in, a discussion list.
<TomaszD> I don't really know how's it called in English.
<sistpoty> TomaszD: uvf exceptions are handled by mail to ubuntu-motu@lists.ubuntu.com (lists.ubuntu.com -> ubuntu-motu list for web-interface)
<TomaszD> it's not my native language.
<TomaszD> oh thank you.
<sistpoty> np
<jdub> hey gang
<sistpoty> hi jdub
<jdub> is there a spot to announce/mention new ubuntu packages that should be adopted in debian? (i'll cc debian-devel)
<sistpoty> jdub: you could file a wnpp bug and maybe announce to utnubu... stratus: any better idea?
<sistpoty> or lucas?
<stratus> sistpoty, RFP in WNPP
<jdub> wnpp bugs still go to d-d, right?
<stratus> translating, file a bug against wnpp package (RFP: packagename -- short description) and you could Cc: debian-devel, sure
<jdub> yeah, i grok the mechanism, more interested in the current etiquette :)
<stratus> jdub, oh np. btw you should Cc: debian-devel.
<jdub> yeah
<jdub> give them something new to flame about
<stratus> jdub, well it's a big community, there are people to flame, people to fix RC bugs, you know what i mean...
<jdub> gotta spread the work around ;-)
<stratus> =)
<jdub> at least the DPL has delegated his flaming to someone else this year ;-)
<stratus> jdub, if you want to avoid noise you can mail utnubu ML
<stratus> jdub, i doubt he did, andrew just take it over
<jdub> ;)
<stratus> jdub, http://alioth.debian.org/mail/?group_id=30729
<jdub> do they accept/moderate random external mail?
<stratus> jdub, i'm not sure you know but there are 9 guys (me, lucas and buxy included) back merging stuff from ubuntu to debian, the group is called utnubu in Debian.
* buxy doesn't do much active merging but tries to setup the infrastructure for it
<stratus> jdub, i don't know, buxy did you started mailing the list before subscribing?
<stratus> only nomeata has the access
* buxy could have the access via his alioth admins powers
<stratus> buxy, can't you just check if it's a non-moderated list to non-members with your super cow powers? :-P
<buxy> jdub: just send the mail and you'll know the answer, it will probably be moderaed and approved by Joachim Breitner
<stratus> aka. nomeata
<jdub> -maintainers or -discuss?
<stratus> -discuss
<stratus> -maintainers is just for the maintainer field.
<jdub> ok
<jdub> thanks!
<stratus> np, you're welcome.
<zakame> heya jdub !
<zakame> X-Debbugs-CC
<zakame> (to be exact, though I don't think gmail supports direct email header setting)
<zakame> which begs the question, what packages in ubuntu could be moved up to debian? :)
<jdub> mine!
<jsgotangco> hmm
<zakame> I somehow knew you'd say that ;)
<jdub> hrm
<jdub> can i od this?
<jdub> X-Debbugs-CC: debian-devel@lists.debian.org
<jdub> X-Debbugs-CC: utnubu-discuss@lists.alioth.debian.org
<jdub> 
<zakame> yeah I think, X-Debbugs-CC isn't really lists.d.o-specific iirc
<jdub> (diziet says it hsould be one header, comma delimited)
<zakame> ah
<jdub> thanks dudes
<phanatic> zakame: what's your opinion then regarding nanoweb's descriptions? :)
<zakame> phanatic: homepage links should look like this:
<zakame> .
<zakame>  Homepage: http://nanoweb.si.kz/
<phanatic> zakame: that's the only thing? if yes, then i'll upload a new version right now, fixing all the issues
<zakame> phanatic: short description ought to start lowercase, and no articles (e.g., no A/An before)
<phanatic> zakame: ok, corrected
<phanatic> anything else maybe?
<zakame> none that I can see now, builds nicely, good work :)
<phanatic> thanks, i'll upload then a corrected version
<phanatic> zakame: done. should appear any minute on revu ;)
<zakame> rocking :D
<sebest_> hello, i've a segfault with NetworkManager, is there a way to have the symbol to generate a backtrace?
<phanatic> zakame: http://revu.tauware.de/details.py?upid=1668 :)
* zakame checks
<phanatic> thanks :)
<Mez> siretart: ping
<raphink> anyone of you knows a way to get the url of the latest upstream tarball from uscan?
<sistpoty> phanatic: I just looked over nanoweb, just ask if you have questions about my comments
<zakame> AM_SANITY_CHECK is quite obsolete to use, right?
<sistpoty> raphink: perhaps with --report? or --verbose?
<raphink> sistpoty: that doesn't give the url
<raphink> :(
<raphink> -- Found the following matching hrefs:
<raphink>      knmap-1.0.tar.bz2
<raphink> doen't give the whole url
<Tonio_> for gnome users : http://listengnome.free.fr/index.php?nom_page=home
<Tonio_> very knew and ressembles really to amarok, nice application ;)
<phanatic> sistpoty: thanks with reviewing. can i /msg you with my questions?
<phanatic> s/with/for
<sistpoty> phanatic: you can also just ask here, but you can /msg as well if you want
<sistpoty> raphink: --dehs
<raphink> --dehs ?
<raphink> ah thanks much sistpoty :)
<sistpoty> raphink: will give you xml-output *with* location of tarball :) (use with --report)
<sistpoty> ;)
<sistpoty> np
<raphink> yes I saw that :)
<raphink> that's good :)
<Gloubiboulga> Tonio_, and .deb packages are available :)
<Tonio_> Gloubiboulga: yes, but I didn't check if they are valid....
<Tonio_> anyway, I'm not a gnome user, but according to the screenshots, it seems missing that in universe would be a pain
<Gloubiboulga> Tonio_, the package is a little ugly :/
<Tonio_> Gloubiboulga: that's always what happens when developpers are packaging :)
<Gloubiboulga> :)
<Tonio_> Gloubiboulga: package it and come with it tomorrow at the CC ;)
<ogra> Tonio_, why should he come with a package to the CC =
<Gloubiboulga> why not ;)
<ogra> ?
<ogra> the CC isnt intrested in packages
<Tonio_> ogra: just a joke between us, that was not a "real advice"
<Gloubiboulga> ogra, I try to become an ubuntu member
<ogra> ah, k, *g*
<Gloubiboulga> of course the debian/ dir is in the tarball...
<Gloubiboulga> I'd have been surprised if it wasn't in
<Tonio_> Gloubiboulga: did you try a lintian on it ?
<Gloubiboulga> Tonio_, yes
<Gloubiboulga> a lot of files are in stanged places
<Tonio_> how many output pages ? ^^
<Tonio_> like images in /usr/lib ?
<Gloubiboulga> exactly
<Tonio_> I already saw that
<Tonio_> lintian doesn't like ;)
<Gloubiboulga> nop :)
<Tonio_> is scons the build system ?
<Tonio_> Gloubiboulga: what you should do is probably taking the sources and build it from scratch
<Gloubiboulga> it's a python app
<Tonio_> and eventually send the package to upstream......
<Tonio_> Gloubiboulga: and ?
<Gloubiboulga> I try to see with what it's built
<Gloubiboulga> scons and I are not good friends ;)
<Tonio_> scons isn't friend with any packager on earth I think ;)
<Tonio_> but scons is more to replace make than a buld system for python apps....
<Gloubiboulga> yep
<Gloubiboulga> it's not used here I think
<Gloubiboulga> I have to go, I'll have a closer look later
<Tonio_> argh, messages.pot at the root of tarball....
<zakame> I've yet to see scons-based pkgs
<Tonio_> zakame: I already tried several times, what a pain.........
<zakame> gaah
<zakame> anyhowm gn8 all!
<zakame> phanatic: I'll approve tomorrow once sistpoty 's is fixed :D
<sistpoty> gn8 zakame
<phanatic> zakame, sistpoty: http://revu.tauware.de/details.py?upid=1669
<phanatic> fixed ;)
<phanatic> zakame: don't let you sleep :D
<sarita> hi
<Toadstool> sistpoty: are you here ?
<Toadstool> or anyone else who has some time to check a package :)
<sistpoty> Toadstool: sorry, was afk... I'll take a look at your package later ;)
<Toadstool> no prob' :)
<apachelogger> Riddell: ping
<Riddell> apachelogger: hmm?
<Riddell> ah, apachelogger is becoming a MOTU, excellent :)
<apachelogger> well, help kubuntu where I can :-)
<apachelogger> Riddell: http://revu.tauware.de/details.py?upid=1662 last comment
<apachelogger> Riddell: so shell I place them in /usr/lib/kde3/?
<Riddell> /usr/lib/kde3/ is for dynamically loadable plugins
<Riddell> apachelogger: why build-dep on dh-buildinfo?
<apachelogger> Riddell: hm, good question, not needed?
<Riddell> debian/rules has dh_buildinfo in it
<Riddell> but why use that is the next question
<apachelogger> Riddell: maybe I add them for some test to get rid of the missing shlibs file, though I really can't remember
<Riddell> rm -r debug/config.log debug/config.status
<Riddell> rm: cannot remove `debug/config.log': No such file or directory
<Riddell> rm: cannot remove `debug/config.status': No such file or directory
<Riddell> breakage
<apachelogger> I'm currently talking to the author to include a clean rule for those files
<Riddell> apachelogger: hmm yes, it should be in /usr/lib/kde3/
<Riddell> all other kicker applets are
<apachelogger> how to get it there?
<Riddell> kde_module_LTLIBRARIES = ktimemon_panelapplet.la
<Riddell> something like that
<sistpoty> apachelogger: or maybe DEB_CONFIGURE_EXTRA_FLAGS := --libdir=/usr/lib/kde3
<apachelogger> ah that was the the think I was searching for ... define the whole cflag is lame ;-)
<apachelogger> thx Riddell, sistpoty
<sistpoty> np
<Riddell> fixing Makefile.am is better
<apachelogger> Riddell: isn't that meant for .in?
<sistpoty> apachelogger: for Makefile.am... and you should report this to upstream
<apachelogger> ok :-)
<Riddell> apachelogger: no, Makefile.in is automatically made
<Riddell> when running  make -f Makefile.cvs  (or admin/Makefile.common)
<apachelogger> yup, pointed that out the other day
<Kyral> Anyone try installing SELinux on Dapper yet?
<spacey> Kyral, ajmitch i guess:)
<Kyral> lol
<Kyral> I only ask because I keep seeing on boot "SELinux Failed, selinux/ doesn't exist"
<LaserJock> Kyral: you watch the boot messages? ;-)
<raphink> siretart: ping
<raphink> siretart: I've just commited a new version of REVU-tools, using uscan to get the upstream tarball when there is a debian/watch
<raphink> siretart: uscan requires the libwww-perl package to work though, so wondering if you would mind having it installed on tiber
<LaserJock> raphink: what does REVU-tools have in it?
<raphink> LaserJock: wait a min I'll show you
<raphink> :)
<raphink> LaserJock: http://revu.tauware.de/~raphink/revu-tools/Changelog
<raphink> this is latest changelog from tonight's version
<raphink> :)
<LaserJock> raphink: hmm, interesting.
<raphink> :)
<raphink> I'm having lots of fun
<raphink> lol
<LaserJock> raphink: is https://wiki.ubuntu.com/MOTU/Packages/REVU/REVU-Tools updated
<raphink> with yesterdays version, yes
<raphink> not with tonight's
<LaserJock> ok
<xerxas> hi there
<raphink> LaserJock: if you have any comment of suggestion :)
<xerxas> slomo_, u there ?
<LaserJock> so it's just for REVU reviewers, right?
<raphink> LaserJock: no
<slomo_> xerxas: yes
<raphink> I intend to make it tiber-independant
<raphink> and make a debian package from it
<raphink> I used it on my own machine today to test it
<LaserJock> raphink: oh, ok. sounds cool
<xerxas> hi slomo_
<raphink> it worked fine
<xerxas> I just tested you're banshee package
<xerxas> is it for breezy ?
<xerxas> I'm on dapper but it recommands gstreamer 0.8
<slomo_> xerxas: nope... dapper... banshee isn't completly ported to 0.10 yet and won't be for dapper
<xerxas> ok
<xerxas> slomo_, it's doesn't read the music on an itunes share
<xerxas> it eventually crashes when starting song or browsing artists
<xerxas> and it displays my mt-daapd share but nothing in there
<slomo_> hm interesting... let me test it here :) one moment please
* slomo_ tests rb->banshee, banshee->banshee
<xerxas> slomo_, non problem
<xerxas> I wanted to know ig you're aware of this
<xerxas> i'll try to track those bugs
<xerxas> slomo_,  got to go eat
<xerxas> but I have some message on the console
<xerxas> will tell you later
<xerxas> (or not interested in this ? )
<slomo_> xerxas: well, it's even worse for me :) when something is shared in the network banshee segfaults at startup... *sigh*
<raphink> yeah :)
<raphink> LaserJock: http://revu.tauware.de/~raphink/debs/revu-tools_0.3.1-0ubuntu1_all.deb if you ever want to test
<LaserJock> k
<raphink> I miss the manpages still
<raphink> but it works, just tested it on my box
<raphink> I just had to change `pbuilder` to  `sudo pbuilder` for the PBUILDERNAME variable in /usr/bin/revu-build
<raphink> since I have no set sudo rights for pbuilder on my machine
<raphink> and now I'll take a break from the screen :)
<raphink> thanks much siretart you rock :)
<siretart> :)
<raphink> siretart: how do you like my latest version?
<siretart> raphink: I didn't look at it yet, I'm at my regulars table in the pub
<raphink> oh ok :)
<raphink> great :)
<siretart> raphink: the diff looked fine, and I trust that you checked that it won't break things :)
<raphink> siretart: well  basically 0.3 uses uscan to get the upstream tarball and check that no new upstream version is available
<siretart> raphink: I've seen that you want to package those tools in 'motu-tools' perhaps we should remove them from revu svn and install that motu-tools package on tiber instead
<raphink> hmm
<raphink> I didn't talk aobut motu-tools
<siretart> I installed libwww-perl as well, btw
<siretart> just a guess
<raphink> yes I saw that siretart, thanks
<siretart> s/guess/thought/
<raphink> libwww-perl is normally installed by devscripts though
<raphink> siretart: http://revu.tauware.de/~raphink/debs/revu-tools_0.3.1-0ubuntu1_all.deb
<raphink> first deb I made tonight
<raphink> tiber-independant
<raphink> :)
<siretart> :)
<siretart> shall I install that now, or is it still in development?
<raphink> you can try it
<raphink> it won't break anything
<raphink> it just generates files in the current folder
<raphink> report files
<raphink> and uses pbuilder only to build
<raphink> so no risk
<raphink> :)
<Seveas> any known issues currently with dapper/pbuilder?
<Seveas> I get:   vim: Depends: vim-runtime (= 1:6.4-006+2ubuntu1) but it is not installed
<Seveas> when doing pbuilder creatr
<raphink> no issue with dapper pbuilder today
<raphink> I updated one an hour ago or so
<Seveas> hmm, odd
<Seveas> let's take a breezy detour then
<ogra> Seveas, its broken ..
<lfittl> Seveas: this happens because vim-runtime is not in main yet, only in universe
<ogra> Seveas, vim-runtime isnt promoted to main
<Seveas> right
<Seveas> and that of course only happens on fresh pbuilders
<ogra> build a breezy pbuilder and update it
<Seveas> working on it already :)
<ogra> :)
<raphink> siretart: if you test the package on your own machine, you might want to set PBUILDERNAME in /usr/bin/revu-build to use "sudo pbuilder" or whatever you need to use
<raphink> siretart: otherwise it's all well set
<raphink> ok I'm off to eat
<raphink> :)
<LaserJock> is there a place to check debian changelogs other than packages.debian.org?
<raphink> LaserJock: for ubuntu it's changelogs.ubuntu.com
<raphink> for debian there doesn't seem to be such a place
<jamessan> LaserJock: http://pdo.debian.net/ is available while packages.d.o is down
<jamessan> hrm, actually it looks like the changelogs aren't accessible from there, though
<xerxas> slomo, you have an idea of what's happening ?
<slomo> xerxas: not really... i'll debug next weekend :)
<xerxas> slomo,  ok
<xerxas> needs some help maybe ?
<xerxas> I'm not really available at week ends ...
<LaserJock> packages.debian.org has been down for quite a while, I wonder how long it is going to take to get it up again?
<slomo> xerxas: not yet :) but i'll ask you when i need some help... thanks :)
<xerxas> slomo,  you're using mt-daapd ? I saw some patches on your site
<slomo> xerxas: nope, currently not...
<xerxas> ok
<xerxas> have you ever used the cvs version ?
<xerxas> I'm have made some things do the debian directory , I have a package
<xerxas> but it doesn't work :)
<slomo> i'm still waiting for the avahi support :) i made a patch but the author wanted to do his own for some reason... and nothing happened yet
<xerxas> ok ok
<xerxas> I saw you're avahi patch and the musepack also
<phanatic> hi people
<Kyral> man alive its windy out
<phanatic> Kyral: here it's -13 celsius degrees
<torkel> we had -28C yesterday :-)
<phanatic> torkel: that's very cold man...
<Kyral> heh
* Kyral just cancelled his Cedega subscription
<LaserJock> grr, I have the box with my new Intel iMac sitting right next to me but my boss won't let me open it until the end of the day :(
<Kyral> lol
<LaserJock> he knows me too well
<Kyral> Is that Breezy PPC CD burning a hole in your pocket :P
<phanatic> :)
<LaserJock> I don't get to use Ubuntu on this machine :(
* Kyral decides to join the FSF as an Associate Memebr
<slomo> Kyral: the intel macs are no ppc... and the x86 version doesn't work currently on that machines afaik
<Kyral> ah
<LaserJock> yeah, they don't have BIOS's and the graphics cards aren't supported
<LaserJock> but luckily I will be able to ssh and vnc to my Ubuntu box at home
<LaserJock> Kyral: are you busy? would you mind doing some merges/syncs for MOTUScience?
<Kyral> uhh
<Kyral> I'll try...
<LaserJock> well it's not a big deal but there are about 37 packages that can be synced/merged without breaking UVF so there isn't really a reason not to
<Kyral> okay
<Kyral> Hmm
<Kyral> Seems I gained a new Email Addy
<LaserJock> Kyral: the list is at http://tiber.tauware.de/~laserjock/science_merge.txt
<Kyral> ..LJ
<Kyral> EasyChem is the same in Dapper Universe as it is in Debian Sid
<Kyral> It's revision # is just 1
* Kyral sighs
<Kyral> I'll request later
<Kyral> I gotta meet someone for Dinner
<LaserJock> Kyral: yeah, I know. There are a couple like that. We should just be able to ask for syncs
<LaserJock> Kyral: I'm just trying to keep track so I can get the syncs done in batches
<LaserJock> hi dolson
<dolson> hi
<LaserJock> ardour question?
<dolson> yea
<LaserJock> do did it build in Dapper?
<dolson> no
<dolson> it goes further in Breezy actually
<LaserJock> but with the Dapper source?
<dolson> I am trying to backport ardour from Dapper to breezy. I changed the jack lib to the 0.80 version and then ran debuild -us -uc and it compiles stuff for several minutes and then conks out with some errors
<LaserJock> can you paste the errors to a pastebin?
<dolson> trying to rebuild it under Dapper with no changes to the control file it fails in under a minute
<crimsun> backports should be done in a pbuilder.
<Mez> crimsun, I know :D
<thierry> who's  daemon@poleboy.de ? he reviewed my package and I'd like to talk to him
<slomo> thierry: sistpoty
<apacheLAGger> http://revu.tauware.de/details.py?upid=1662 is it really needed to correct the fsf address?
<dolson> LaserJock:  http://paste.ubuntu-nl.org/8128
<apacheLAGger> kinda annoying work
<crimsun> apacheLAGger: yes, the FSF address must be correct
<dolson> crimsun: this isn't an official backport or anything, I'm just trying to figure things out. I don't know anything about pbuilder at this time, but I'd be glad to learn
<apacheLAGger> crimsun: any script suggestios or something?
<crimsun> apacheLAGger: there are various bugs in BTS about it; you could do a sed s/foo/bar/
<apacheLAGger> ah, yeah -- sed --- thx :)
<LaserJock> dolson: pbuilder would help you out. check out https://wiki.ubuntu.com/PbuilderHowto
<dolson> alright, I will read that now.. I read stuff on the net about rebuilding debs and the stuff I read didn't mention it, so unfortunately I learned the wrong method
<LaserJock> dolson: that is not to say that it will make the problems go away, but it is a much cleaner environment to diagnos problems :-)
<dolson> k, I'll try it now and see what happens.
<LaserJock> dolson: for what it is worth, the ardour source didn't build in my dapper pbuilder
<dolson> :\
<crimsun> it shouldn't, there are API changes
<dolson> so can it be done somehow?
<crimsun> yes
<cyberserver> Hu people. I've apt-get dist-upgraded dapper right now and I'm getting a kernel panic. Anyone faced similar problem? I think my initrd file got currupted.. or there is something wrong with the latest kernel packages..
<crimsun> 14.19 works fine on i686
<cyberserver> Hmmm... strange..
<cyberserver> ... I am notisting that I have linux-image-2.6.15-14-686 package installed...
<cyberserver> ... but my grub menu only shows linux-image-2.6.15-13-686
<cyberserver> The package hasn't updated the grub entries?!?
<crimsun> sudo dpkg-reconfigure linux-image-2.6.15-14-686
<cyberserver> haaaa!!! Got it :-p "Updating /boot/grub/menu.lst ... sed: couldn't write 75 items to stdout: No space left on device"
<cyberserver> Thanks crimsun ! :-p
<mdke> anyone looking for an easy bugfix? bug 30694
<Ubugtu> malone bug 30694 in xmms "unfriendly menu entry for XMMS" [Normal,Unconfirmed]  http://launchpad.net/bugs/30694
<crimsun> that's not very easy for most of us, seeing how most of us don't have main privs ;)
<mdke> gah
<LaserJock> lol
<mdke> i just assumed it would be in universe
<mdke> sorry
<cyberserver> People, do you think we can purge all old "half-removed" packages?   I do an "dpkg -l | grep rc" and I'll  see quite some packages in "rc" state... xorg-common (6.8.2-77) , for instance...
<cyberserver> or is this a risky thing to do?
<crimsun> it's not risky at all
<crimsun> sudo aptitude purge $(dpkg -l |grep ^rc |awk '{ print $2 }')
<dolson> alright, I think I'm too stupid to do this
<crimsun> I'd be happy to help you with it later, but I'm currently knee deep in $stuff
<dolson> that would be great! I don't have a job right now, so I'll be here :/
<dolson> I got pbuilder going and all that, and I think I understand how it works, so that's a step forward
<crimsun> once you have pbuilder configured, it's not too bad
<dolson> yeah, it's all done but it fails at the same point as when I used debuild
<TheMuso> Has anybody tried to create a dapper pbuilder environment recently and have it fail on a package dependancy problem with vim-runtime when it is trying to bootstrap/update? If so, how do I fix that?
<crimsun> TheMuso: dist-upgrade from within a Breezy pbuilder
<TheMuso> um ok. This happens when I am trying to create a pbuilder environment...
<TheMuso> ah yep I get it.
<cyberserver> Well, I'm booting into my new kernel....
<cyberserver> ...see you soon.. I hope :-p
<tiCo89> is it true that ubuntu still searchs developers?
<LaserJock> tiCo89: what do you mean?
<tiCo89> i mean what i said... are you still searching developers?
<tiCo89> real, registered developers...
<crimsun> please quantify that.
<crimsun> we're (as MOTU) continually seeking help
<crimsun> if you mean core developers, you'll need to see the Ubuntu and Canonical Web sites
<tiCo89> and is it possible to get a developer? somebody which may upload packages (not sponsored)...
<crimsun> what do you mean?
<tiCo89> oh god...
<azeem> tiCo89: you mean Ubuntu is looking for developers
<tiCo89> azeem: yes...
<LaserJock> the MOTU can upload to Universe but you have to be a core dev to upload to Main
<tiCo89> aha, and is it possible to get a motu?
<crimsun> sure, lots of us are here
<tiCo89> or is it like in debian where you wait lots of years...
<dolson> I think tiCo89 wants to become a MOTU
<tiCo89> yes
<crimsun> ...yeah, I think that's what you mean
<tiCo89> i'm already a debian maintainer and have soe expirience
<tiCo89> and i'd like to help also ubuntu
<crimsun> tiCo89: then you just need to spend a few months and demonstrate solid teamwork and dedication to Ubuntu (and Debian)
<crimsun> cf. StevenK, who became a MOTU rather quickly
<tiCo89> okey...
<raphink> siretart: http://revu.tauware.de/details.py?upid=1332
<tiCo89> have you to search here always a sponsor too?
<raphink> siretart: can you nuke that please ? (see my last comment)
<cyberserver> New kernel is woking fine :-)
<crimsun> tiCo89: until you become a member of the Launchpad ubuntu-dev team, yes
<raphink> :)
<tiCo89> crimsun: what do you think? how long does this "NM"-process need?
<LaserJock> and you should become an Ubuntu Member first, http://www.ubuntu.com/community/processes/newmember/ has details
<crimsun> tiCo89: at least a couple months
<raphink> tiCo89: the NM process in Debian can last years, at least months
<raphink> tiCo89: it's faster to be an Ubuntu dev, for sure :)
<tiCo89> raphink: yes i know it, i'm in NM of debian =)
<raphink> tiCo89: ok
<raphink> tiCo89:  in Ubuntu, if you do a good job, you can be a dev in a matter of, say, 2 months :)
<tiCo89> funny ;-)
<raphink> why funny?
* tiCo89 has already distributed a lot of cds in school and at work, helped a lot of user in linux user groups to fix problems and have 9 packages in the debian archive
<tiCo89> and my gpg key is signed from 3 DDs
<tiCo89> so i register soon as a newmember =)
<raphink> hmmm
<raphink> how long have you been in Ubuntu tiCo89 ?
<tiCo89> it's funny to get a developer in 2 months...
<tiCo89> hmmm, since warty...
<raphink> ok
<raphink> did you get your packages in Ubuntu?
<raphink> :)
<tiCo89> en example: packages.ubuntu.com/dapper/net/ngircd
<raphink> mhm
<raphink> :)
<tiCo89> hmmm
<raphink> tiCo89: is your work for ubuntu documented on your wiki page?
<raphink> I can't find your wiki page
<tiCo89> not yet...
<tiCo89> i do it tomorrow at work
<tiCo89> and register as a member..
<raphink> when do you plan on applying?
<tiCo89> raphink: apply for what? membership? tomorrow...
<raphink> oh ok
<tiCo89> what's the age of the youngest motu? :-S
<raphink> tiCo89: no idea
<Hobbsee> tiCo89: got no idea, but i'd be one of the youngest on this channel i suspect
<raphink> I hope jpatrick can be one soon , and he's 14 now
<raphink> Hobbsee: how old are you, if you don't mind me asking?
<tiCo89> hmm okey, fine, so i'm not the youngest with 16 =)
<tiCo89> in the linux user groups i'm always the youngest :-(
<Hobbsee> raphink: 17
<raphink> ok
<Hobbsee> tiCo89: ah, you win the honour then :P
<raphink> I feel like a gwanpa then
<raphink> ;)
<raphink> Hobbsee: but you're a girl, so he should leave it to you :)
<tiCo89> Hobbsee: i have already honour with my speeches ;-)
<LaserJock> yeah, well I'm 8.  j/k . my wife probably would say that I am though ;-)
<Hobbsee> raphink: good point
<tiCo89> LaserJock: *smile*
<Kyral> Hmm
<tiCo89> 8 to the power of 2? :)
<Kyral> can I resize a Reiser3 FS live?
<raphink> lol
<LaserJock> tiCo89: not quite that old
<apachelogger> raphink, Riddell: time to review http://revu.tauware.de/details.py?upid=1673 ? .... the author and I made some adaptions to get a better deb with less lines in debian dir :)
<raphink> LaserJock: oh really?
<Kyral> I can't remember lol
<LaserJock> I think I'm about as old as raphink
<raphink> LaserJock: really?
<raphink> I'm not married I'ma fraid :(
<LaserJock> raphink: well, spill the beans, how old are you?
<raphink> apachelogger: it would be nice if you added a debian/watch file
<raphink> LaserJock: 23
<raphink> you?
<LaserJock> raphink: yep, I'm your senior. I just turned 24 a few months ago
<raphink> apachelogger: for now, do you have the url to the upstream tarball?
<apachelogger> http://www.kde-apps.org/content/show.php?content=29552
<LaserJock> but I feel old. I'm almost done with my PhD and I've been married for 4 1/2 years
<raphink> thanks
<raphink> apachelogger: you know how to make debian/watch?
<apachelogger> I even don't knwo what it is supposed to do :|
<raphink> apachelogger: automatize the update of the package
<raphink> wait a min apachelogger I'll show you
<apachelogger> k
<thierry> LaserJock : what's PhD ? physic science diploma?
<thierry> LaserJock : I'm french-canadian so name changes here
<LaserJock> thierry: Doctorate of Philosophy, the general doctorate
<raphink> un doctorat de sciences
<raphink> ah
<thierry> LaserJock : wow great
<LaserJock> it is general. mine will be in Physical Chemistry
<raphink> ok
<raphink> apachelogger: http://revu.tauware.de/revu1-incoming/nanoweb-0602061030/nanoweb-2.2.7/debian/watch
<raphink> this is a simple - yet efficient - one
<apachelogger> so version = file version ... and path in regular, that's it?
<raphink> apachelogger: version=3 now
<raphink> it's the debian/watch version
<raphink> use 3
<apachelogger> yeah, that's what I meant :-)
<raphink> the path is the path to the file, as regexpr for perl
<raphink> (.*) being used as version number
<raphink> so get where the file is on he upstream website
<raphink> it's better
<raphink> apachelogger: once you have a debian/watch, you can use uscan to uupdate your package
<raphink> and I can use it to review it, too :)
#ubuntu-motu 2006-02-12
<apacheLAGger> sorry, lost connection
<raphink> [23:58]  <apachelogger> yeah, that's what I meant :-)
<raphink> [23:58]  <raphink> the path is the path to the file, as regexpr for perl
<raphink> [23:58]  <raphink> (.*) being used as version number
<raphink> [23:58]  <raphink> so get where the file is on he upstream website
<raphink> [23:58]  <raphink> it's better
<raphink> [23:59]  <raphink> apachelogger: once you have a debian/watch, you can use uscan to uupdate your package
<raphink> [23:59]  <raphink> and I can use it to review it, too :)
<raphink> sorry for the lag
<raphink> just reposting for apacheLAGger
<apacheLAGger> http://www.kde-apps.org/content/files/(.*)-kblogger-(.*)\.tar\.bz2
<apacheLAGger> should work?
<raphink> apachelogger: I don't think so
* Kyral decides it is high time to try a LFS install
<raphink> because the first (.
<raphink> (.*) will be taken as version number
<raphink> so no
<apachelogger> :|
<raphink> apachelogger: there's no tarball on another website?
<apachelogger> not yet
<theCore> is there someone who is working on packaging SeaMonkey ?
<apachelogger> though might be soon
<apachelogger> raphink: shell I add a watch file then?
<raphink> you can try it this way
<raphink> apachelogger: make it so
<raphink> and try
<raphink> to run uscan --report
<raphink> to see what it says
<raphink> or even
<raphink> uscan --report --debug
<raphink> and see what you get
<apachelogger> ok :-)
<apachelogger> raphink: http://paste.ubuntu-nl.org/8132
<apachelogger> maybe he's still online
* apachelogger looks
<raphink> won't work with kde, that's what I thought
<apachelogger> raphink: bad if current version isn't online yet?
<apachelogger> he's already sleeping
<raphink> np
<apachelogger> ok, I'll upload the watch file
<raphink> ok
<apachelogger> raphink: talking about this, is it possible to just upload the new diff?
<raphink> hmm no
<raphink> it is not
<apachelogger> ok
<Riddell> apachelogger: what does DEB_MAKE_CHECK_TARGET := check  do?
<apachelogger> Riddell: ripped it form another package
<apachelogger> rules files so empty without some lines ;-)
<apachelogger> Riddell: actually I'd just need "common-binary-post..." and the includes, right?
<Riddell> apachelogger: my next question was to ask what that line does
<apachelogger> Riddell: well, just includes looks a bit silly, doesn't it?
<Riddell> no
<apachelogger> ok, you're the motu :-)
<apachelogger> Riddell: anything else I should remove?
<Riddell> apachelogger: no, but check it still works
<apachelogger> yup, does
<Riddell> apachelogger: remove dpatch build-dep
<apachelogger> ...and dh-buildinfo
<apachelogger> fixed
<hawking> I'm trying to build nessus from source and as I did make for nessus-core I got this error http://rafb.net/paste/results/6mDSrs12.html can someone help me?
<hawking> hello from Beijing!
<hawking> anyone to help me around?
<raphink> wait a min hawking ok?
<raphink> I'll be available in a short time
<hawking> raphink : ok say my name when ur here
<hawking> thanks
<dolson> hawking: join the lineup to your left ;)
<raphink> haha
<hawking> :)
<raphink> ok who's next ? :)
<raphink> hawking ?
<raphink> dolson: ?
<apachelogger> Riddell:  http://revu.tauware.de/details.py?upid=1675 ok now?
<hawking> raphink : me!
<hawking> raphink :my question is above
<dolson> well I was waiting for crimsun, but if you can help, that's cool
<raphink> apachelogger: again? you don't need my advocacy anymore :p
<raphink> dolson: I'll answer to hawking if you don't mind :)
<hawking> raphnik : I'm trying to build nessus from source and as I did make for nessus-core I got this error http://rafb.net/paste/results/6mDSrs12.html can someone help me?
<apachelogger> raphink: ;-)
<raphink> hmmpf
<dolson> oh I mind!
<hawking> raphink : the Makefile is here http://rafb.net/paste/results/CVXY4n71.html
<raphink> ok dolson your question
<raphink> hehe j/k ;)
<dolson> :)
<raphink> moooh I'm not a developer :s
<raphink> not a true dev that is ;)
<raphink> did you look in comm.c hawking ?
* dolson puts on the Jim Gaffigan DVD again
<hawking> raphink : nope... well I don't know C a lot
<raphink> hawking: well
<hawking> shall i paste it? hang on
<raphink> comm.c: In function &#8216;comm_update_ui&#8217;:
<raphink> comm.c:99: error: label at end of compound statement
<raphink> it tells you there's an error in comm.c on line 99
<raphink> that's where you should look, imo
<raphink> first thing to do
<raphink> I'm not a C pro either though ;)
<raphink> far from being
<hawking> there are two comm.c actually
<hawking> http://rafb.net/paste/results/IiQW4p42.html
<hawking> this is one of 'em
<apachelogger> puh, I'm off to get at least some sleep ;-) .... gnight all
<raphink> hawking: this is it
<raphink> you can see it
<hawking> hmm
<raphink> hawking: line 99 is in comm_update_ui function as said in the error
<raphink> can you see that hawking ?
<hawking> well I see a } in line 99
<raphink> yep
<raphink> so as said in the error, the end of a compound statement
<raphink> at least the end of something, since it's }
<raphink> but then if you go up
<hawking> yeah I saw it
<raphink> you'll see that this is part of the comm_update_ui function
<raphink> that begins at line 64
<raphink> well 63 actually
<raphink> static void
<raphink> comm_update_ui(context, current)
<hawking> yeah
<raphink> so it seems the error happens with the switch stuff
<hawking> hmm yes
<raphink> this is where it happens
<raphink> http://pastebin.com/542477
<raphink> I'm not a good C programmer, haven't programmed in a long time
<raphink> but maybe it requires a void; after default:
<raphink> dunno
<hawking> hmm I see
<hawking> so I'll put a void right after default the line below right?
<hawking> before }
<raphink> I think default: is not even compulsory
<raphink> just remove the default: line
<raphink> or just put break; after it
<raphink> default:
<raphink>     break;
<raphink> again, I'm no C dev, but I think it should do
<raphink> if that works, you'll have to patch the source properly (you don't want to modify the upstream tarball like that in a package) and send the patch upstream
<hawking> raphink : I found a nicer comm.c from cvs :)
<hawking> instead of messing with it :p
<hawking> thanks
<raphink> hawking: with this fixed?
<hawking> yes
<raphink> how was it fixed?
<raphink> just so I know :)
<hawking> dunno do you want to see the new comm.c?
<hawking> lemme paste
<raphink> sure
<hawking> there is a break; there ;)
<hawking> you knew it :)
<raphink> yep
<raphink> well I saw only two options
<raphink> either removing the line
<raphink> or adding break; after it ;)
<raphink> that seemed logical :)
<hawking> here it is if you wanna see http://rafb.net/paste/results/3PbRuO55.html
<hawking> btw how can i add /usr/local/sbin to my PATH?
<raphink> no there is no break that I see
<raphink> he removed the default: instead
<raphink>       case COMM_GET_DEPENDENCIES:
<raphink>         fmt = _("Receiving dependencies: %d");
<raphink>         base = limit;
<raphink>         limit = PBAR_MAX;
<raphink>         break;
<raphink>     }
<raphink> that is the new one
<raphink> no default: anymore
<raphink> ;)
<hawking> :)
<raphink> hmm I'm not good with PATH
<raphink> ;)
<hawking> :/
<raphink> ask someone else and I'll be listening to the answer
<raphink> to know it next time
<raphink> :)
<hawking> ok I'll ask somewhere else :p
<hawking> thanks a lot
<raphink> :s
<raphink> you're welcome"
* raphink is gonna have a tea before going to bed
<raphink> or a herbal tea rather
<raphink> better to sleep :)
<dolson> green tea is yummy
<raphink> yep
<raphink> Riddell: ping
<Riddell> raphink: hi
<raphink> hi Riddell :)
<raphink> Riddell: I was wondering
<LaserJock> Hi all
<raphink> we have a kubuntu team on LP, but we hardly ever meet to discuss our vision of hte kde desktop
<raphink> do you think we could have a meeting from time to time
<raphink> get to know who works on what in kubuntu
<raphink> what has to be done, etc.
<raphink> like getting a date on fridge to take one or two hours in #ubuntu-meeting
<raphink> what would hyou think Riddell ?
<Riddell> I don't honestly know
<Riddell> it's not a daft idea
<raphink> well let's say I would enjoy it :)
<raphink> and I think I'm not the only one
<raphink> :)
<Riddell> don't know if people would be interested, or if we could get enough people at the same time
<raphink> well I guess the best way to know is to try
<Riddell> or what the outcomes of a meeting would be
<Riddell> but edubuntu seem to have meetings quite a bit
<raphink> yes
<raphink> I think it would be interesting
<raphink> we can just create an agenda page on the wiki
<raphink> plan a date to meet
<raphink> ping kubuntu devs around
<raphink> gtry to gather them, have them add topics to the agenda if they want
<raphink> and we'll see what gets out of it
<raphink> :)
<Hobbsee> Riddell: please dont make it at early hours of the morning, otherwise I cant make it...
<raphink> doesn't cost much to try
<LaserJock> how many kubuntu devs are there?
<Riddell> Hobbsee: kubuntu people aren't morning people :)
<raphink> LaserJock: https://launchpad.net/people/kubuntu-team
<raphink> Riddell: very true ;)
<Hobbsee> Riddell: oh good.  parents dont seem to understand about staying up for meetings, even at times like 1am
<Riddell> Hobbsee: tell raphink when are good times for you, in UTC
<raphink> Riddell: looking at the fridge, the 16th in the evening (20UTC to 21 UTC for ex) seems like a good time
<LaserJock> hmm, there are actually quite a few
<raphink> would that be fine for you Hobbsee ?
<Riddell> raphink: when is distro team meeting that week?
<raphink> yep Riddell
<Hobbsee> checking...
<raphink> http://fridge.ubuntu.com/event/2006/02/11/month/event/all
<raphink> wb Tonio_
<Tonio_> hi ;)
<raphink> we're talking about planning a meeting for the kubuntu team Tonio_
<Hobbsee> *sigh* - 7am?  well at least the parents wont have a massive cow
<Hobbsee> should be ok
<raphink> would the 16th 20UTC to 21UTC be fine for you?
<Tonio_> nice
<Riddell> raphink: yeah, ok with me
<raphink> good :)
<Tonio_> i'm okay of course
<raphink> :)
<raphink> that's at least Riddell, Hobbsee, Tonio_ and me so far
<raphink> :)
<raphink> just have to send an email to kubuntu-team on LP to ping others
<raphink> :)
<Tonio_> yup
<raphink> so at least this team can begin to be used for real :)
<raphink> hmm the email is kubuntu-bugs@lists.ubuntu.com
<raphink> not sure this is the greatest email to use for such a thing ;)
<Tonio_> arf
<LaserJock> I might join in if you have it at a convenient time
<raphink> I'll create https://wiki.ubuntu.com/Kubuntu/Meetings
<raphink> LaserJock: thursday the 16th, 20UTC to 21 UTC
<raphink> how is that for you?
<Tonio_> okay, raphink I may give my 2 cents on a few suggestion list regarding the subject that could/should be discussed
<raphink> Tonio_: let me create the page and you can add stuff to the agenda :)
<LaserJock> raphink: good for me I think
<raphink> ok :)
<raphink> Riddell: do you know how to ``book''  a place on the fridge?
<Tonio_> raphink: he's gonna sleep :)
<raphink> huh?
<LaserJock> raphink: btw, I'm in my new iMac right now :-)
<raphink> oh great :)
<dolson> hmm, ardour 0.99.1 is out now
<raphink> Tonio_: j'ai chop la page MOTU/Meetings
<raphink> Tonio_: https://wiki.ubuntu.com/Kubuntu/Meetings
<Tonio_> coule
<Tonio_> ca va permettre d'avancer
<Tonio_> il faut que kubuntu se singularise en tant que distrib apportant kde ET quelque chose de plus
<Riddell> raphink: e-mail fridge-devel@lists.ubuntu.com
<raphink> Riddell: thanks I will
<Riddell> cool
<Tonio_> gonna sleep, nite all !
<raphink> night Tonio_
<raphink> :)
<sistpoty> hi folks
<crimsun> 'lo
<dolson> hello
<LaserJock> hi sistpoty
<raphink> hmmpf
<raphink> message rejected
<dolson> so ardour is in universe.. ok. I have a question. what is the possibility of it being upgraded from 0.99.0 to 0.99.1 before Dapper is released? there are a number of bugfixes in it
* crimsun opens the changelog
<dolson> crimsun: are you the ardour maintainer, by chance?
<crimsun> no
<crimsun> I have a vested interest in getting audio up to speed, to say the least
<crimsun> the problem here is that we're past UVF, and Debian is still at 0.99-3
<dolson> nice. me too.. so I'm hoping I can learn a lot of stuff and help out where I can
<dolson> for now my help is in the form of tutorials and stuff like that, but I would like to maybe package some software not in Ubuntu or Debian at some point, when I have enough knowledge
<crimsun> to push in 0.99.1 we'd deviate from Debian, which introduces a delta that we should avoid at this stage
<crimsun> I don't have any objections to backporting 0.99.1's fixes, though, to our -3ubuntu1
<dolson> yeah, 0.99.1 was just released today, so there wouldn't be a package yet
<crimsun> today? pssht
<crimsun> we should wait a few days at least :-)
<dolson> ok, I was just hoping to bring it up because I know time is running out
<crimsun> hmph, it should build fine; I wonder why it was merged
<dolson> I'm sorry, but I don't know what you mean
<crimsun> sec, updating pbuilder
<crimsun> ah, it's the access method issue
<dolson> is there an easy fix
<crimsun> (already fixed)
<dolson> how do I proceed?
<crimsun> oh, for backporting?
<crimsun> where is it dying?
<crimsun> I'm busy for another couple hours (til 11:15 PM EST)
<dolson> oh, ok. I'll be on then. right after RAW. heh. I'll pop back in around then
<freeflying> Mithrandir: hi
<tulga> can I install libgd-gif-dev on dapper 2?
<marcin_> hello MOTU
<marcin_> I got a question
<marcin_> could someone tell me how can I define current version of package in control file?
<marcin_> I know that there is something like: (= ${Source-Version}) but then
<marcin_> my build says that gcc is required while this application that I want to package is platform independent webapp
<lfittl> marcin_: what build-depends do you have?
<lfittl> current version is defined by the debian/changelog entry
<marcin_> lfittl, I know that but I want to set this dependency internally
<marcin_> lfittl, I want to build few packages from the same source
<lfittl> marcin_: you can't give the binary packages another version, they always have the debian/changelog version
<marcin_> lfittl, and then I want to set dependency between two packages generated from the same source
<lfittl> marcin_: given that they all have the same source package, (= ${Source-Version}) is the right thing to use
<Hobbsee_> *sigh
<Hobbsee_> *
<marcin_> lfittl, well but then build says that 'gcc: command not found;
<lfittl> marcin_: do you call gcc at some place in debian/rules?
<marcin_> lfittl, nope I only use cdbs
<lfittl> marcin_: what kind of build system?
<marcin_> lfittl, but only to run debhelpers - my rules file is almost empty
<marcin_> lfittl, because source is just webapp - so nothing to compile
<marcin_> lfittl, bunch of php files
<lfittl> marcin_: could you upload the source package somewhere?
<marcin_> lfittl, well not yet
<quikstrike> can someone help me?
<marcin_> lfittl, I'll upload to revu but first I want to make it installable
<lfittl> marcin_: could you upload/paste the buildlog somewhere?
<lfittl> quikstrike: sure, what do you need?
<marcin_> lfittl, just a moment
<marcin_> lfittl, ok I just changed my control file a bit and now it's ok
<marcin_> lfittl, but there is another question
<lfittl> marcin_: feel free to ask ;)
<marcin_> lfittl, do you know why package that I created doesn't want to install config file?
<marcin_> lfittl, in postinst script I got few lines that generate some custom config file
<marcin_> lfittl, but when I'm trying to install this package
<lfittl> marcin_: sry, I don't know enough about post/pre scripts to help you on this :/
<marcin_> lfittl, then I get this: Not replacing deleted config file /usr/share/vtiger-crm/connection.php
<lfittl> marcin_: Simply ask one of the MOTUs when they are awake again
<marcin_> lfittl, ok thanks
<lfittl> marcin_: np
<dolson> crimsun:   http://paste.ubuntu-nl.org/8128
<dolson> crimsun: holy crap.. I did a diff on the two ardour source trees and there are over 11K lines in the diff
<Mithrandir> freeflying: hiya?
<dolson> it's quiet in here
* Toma-away bangs a frypan with a hammer
<Toma-away> :)
<dolson> much better. sounds like my music :)
<Toma-away> ive check out the motu site and cant find initng... if i had the power, id make an ubuntu package for it! its totally rad and stable
<dolson> by the power of grayskull... you have the power
<Toma-away> :(
<dolson> do you not know how to make packages?
<Toma-away> i do, but im not sure about gpg, control, etc... i can make rpms however
<dolson> ah. I don't know how to really make packages yet. I can rebuild some that exist, but taking something from scratch I don't know yet, except the hack that is checkinstall
<dolson> I'm attempting to learn how to do a backport of ardour right now.. so far hasnt worked
<Toma-away> theres a deb available for it now? and the website that maintains it say its for "debian/ubuntu"
<Toma-away> oic
<dolson> you could probably make the package from Debian's package pretty easily, no?
<Toma-away> yeh.. alter the control file? and say "ubuntu"...
<dolson> hmm, my experiment is working so far... maybe I will have an ardour 0.99.1 package in a few minutes..
<Toma-away> wish i had the hardware for ardour :(
<dolson> what's your specs?
<Toma-away> at the moment, 266mhz, 128ram sb128 sound card :/
<dolson> ah, yeah, won't work on that for sure
<Toma-away> indeed.
<Toma-away> what sound card have you got?
<dolson> I have a 133mhz that still function
<dolson> I have a 133mhz that still functions as a doorstop
<Toma-away> :D
<dolson> I have crap for sound cards.. SB Live! 5.1 and an Audigy2 ZS
<Toma-away> mine is a multimedia centre bevlieve it or not
<Toma-away> i want an audigy :( dreamt of them since they came out
<dolson> do you play the Top 40 hits through the "beep" program?
<Toma-away> haha
<Toma-away> no, it has a tvcard, dvd drive and wifi in it
<crimsun> dolson: 11K sounds about right
<dolson> holy geez.
<dolson> I find my Athlon XP 2800+ slow..
<Toma-away> yeh! tv isnt at full resolution, and dvd is tweaked to hell
<Toma-away> id say a 350 would make the grade tho
<dolson> crimsun: so far the build is going.. I used the diff from the 0.99 package and compared the patches in there to the new source tree and they all applied at small offsets, and its been building for about 15 minutes. but I'd still like to backport the official 0.99 from Dapper to Breezy
<dolson> wow, I think it worked... I got a doc deb so far...
<crimsun> dang, that doesn't bode well
<dolson> why not?
<dolson> now I have a session exchange deb
<crimsun> because that means it's more features than fixes
<dolson> it's a maintenance release
<dolson> woo ardour-gtk_0.99.1-0ubuntu1_i386.deb
<crimsun> yeah, but how dpatches were absorbed upstream?
<crimsun> how many, rather
<dolson> I am not sure what you mean.. in the ubuntu source, there are about 4 patches, which are all 1-liner patches
<crimsun> 19_fix-session-timefx-for-soundtouch-assert.patch?
<dolson> that one is one line
<crimsun> I'm extremely hesitant to generate an additional merge delta for an -0ubuntu1
<crimsun> right, but it wasn't applied upstream?
<dolson> upstream is the source from the ardour site right? if so, then no, that patch still needed to be applied
<crimsun> ok, then we should ask rjo if he plans to upload 0.99.1-1 RSN
<dolson> what I did was I apt-get source ardour-gtk, then I extracted the source from ardour-0.99.1, cd into there, patched with the .diff.gz from dapper, edited the changelog, then built the package and it worked, surprisingly
<dolson> who is rjo? Robert Jordens?
<crimsun> yes
<dolson> do you want me to ask him?
<crimsun> you may if you wish
<dolson> alright, I would like to. I haven't done such a thing before, so is there anything I need to know, or do I just email him and ask him that
<crimsun> I feel it's courteous to wait a few days, since he probably has real life stuff occurring, too
<dolson> ok
<zakame> heya MOTUs  !
<crimsun> hey zak
<zakame> hello crimsun :)
<dolson> so is Mark Shuttleworth He-Man or what?
<jsgotangco> no He-Man is daniel holbach
<dolson> ah
<dolson> who is Cringer?
<zakame> er?
<dolson> crimsun: I still can't build ardour on breezy though
<jsgotangco> hrmm a bondage pic was tagged ubuntu in flickr
<jsgotangco> lol
<dolson> haha
<ajmitch_> jsgotangco: what a surprise
<zachy> heh
<jsgotangco> hope it doesnt become a trend (and just stay nude), we're getting a new nude ubuntu-tagged pic in flickr almost every week
<Mithrandir> I wonder why a lot of diablo ii pics seem to be tagged ubuntu too
<dolson> there is an interesting one on the second page of results for searching on GoogleImages
<jsgotangco> heh that's pretty old but still good
<Mithrandir> jsgotangco: do you have a link to the ubuntu bondage one?  I couldn't find it on flickr?
<jsgotangco> wait
<jsgotangco> Mithrandir, http://www.flickr.com/photos/88801111@N00/89407056/
<StevenK> I was looking for one of the Ubuntu logos, which is 4 females and one smiling in the middle.
<jsgotangco> he must have mistakenly added ubuntu
<jsgotangco> or maybe not
<Mithrandir> ubuntu is going to be a code word for kinky stuff at some point. :-P
<jsgotangco> "ubuntu me baby"
<Mithrandir> oooh-buntu!
<dolson> I'm going to ubuntu you all night long
<jsgotangco> yeah just wait till an R&B song uses it
<siretart> morning
<siretart> I love these changelogs: http://lists.debian.org/debian-devel-changes/2006/02/msg00372.html
<zakame> heya siretart
<siretart> huhu zakame
<Toadstool> hi everybody
<jpatrick> hullo Toadstool
<Toadstool> is there a nice MOTU who has time to review my dhcpv6-kame package ? ^^
<jpatrick> not an MOTY but I could look...
<jpatrick> MOTU*
<Toadstool> yep
<Toadstool> that would be nice
<Toadstool> http://revu.tauware.de/details.py?upid=1642
<ajmitch_> evening
<raphink> hi ajmitch_
* TomaszD is away: Away for whatever reason.
<marcin_ant> hello MOTU's
<jpatrick> hello marcin_ant
<raphink> hi marcin_ant
<marcin_ant> guys I need some help
<raphink> ah, that happens ...
<marcin_ant> I'm trying to create package and I it's almost ready but unfrtunately there is something
<marcin_ant> that goes wrong... and I really have no idea how to fix it
<marcin_ant> so, I got some *.postinst file
<raphink> mhm
<jpatrick> marcin_ant: what happens?
<raphink> marcin_ant: use the pastebin and show us what's wrong
<marcin_ant> and this file should generate some configuration file and put this file into selected directory
<marcin_ant> unfortunately it says that "Not replacing deleted config file ......."
<marcin_ant> when trying to install/reinstall package
<jpatrick> marcin_ant: do you need the file?
<raphink> can we see your postinst marcin_ant ?
<marcin_ant> and without this config file whole package is just unworkable
<marcin_ant> raphink, sure - which pastebin supports this channel?
<raphink> marcin_ant: any ;)
<raphink> pastebin.com is fine
<marcin_ant> http://pastebin.com/543038
<raphink> ah, vtiger
<raphink> I didn't remember you were the vtiger guy ;)
<raphink> marcin_ant: did you write to the bounty poster btw ?
<marcin_ant> raphink, well not yet
<raphink> marcin_ant: you should, he thinks I'm doing it
<marcin_ant> raphink, I just added comment on launchpad
<raphink> ;)
<raphink> since I've begun to do it
<marcin_ant> raphink, ok I'll send mail
<marcin_ant> raphink, sure I started with your package but this database stuff is something that is most important part of vtiger package
<marcin_ant> raphink, anyway do you know how to force dpkg to reinstall this config file?
<raphink> I'm looking and trying to understand
<marcin_ant> raphink, do you know how vtiger installation procedure works?
<raphink> I've had a quick look at it
<raphink> there are scripts to conf it
<Mithrandir> marcin_ant: --force-confmiss
<marcin_ant> Mithrandir, with dpkg?
<Mithrandir> mhm
<marcin_ant> Mithrandir, hmm nice but how can I do the same but with apt?
<raphink> marcin_ant: do you ask the debconf questions in config ?
<marcin_ant> raphink, yes
<raphink> ok
<raphink> good :)
<marcin_ant> raphink, database pasword
<raphink> mhm
<raphink> marcin_ant: how did you set the mysql conf issue?
<marcin_ant> raphink, is required - so we have to ask
<raphink> marcin_ant: mysql has to be set before entering the database password
<raphink> how did you set that?
<marcin_ant> raphink, you mean on 'fresh' mysql installation?
<raphink> marcin_ant: yep
<marcin_ant> raphink, well I didn't ;)
<raphink> marcin_ant: vtiger-crm depends on mysql, but that doesn't help setting it
<marcin_ant> raphink, I've been looking to another packages that depends on mysql
<raphink> marcin_ant: my idea when I worked on it was to print a message with debconf if mysql was not set, telling users they should set mysql and then run some common to set vtiger
<marcin_ant> raphink, and you are right - it's pretty nasty issue
<raphink> marcin_ant: the bounty poster wants a _totally_ automated install
<raphink> marcin_ant: i.e. the LAMP has to be entirely configured in one clic
<raphink> this is where it's quite hard
<raphink> since you can't set mysql dirtily
<raphink> this is why I quite stopped working on this actually ;)
<marcin_ant> raphink, well I agree but I think I got solution for this issue
<raphink> if I have to spend weeks trying to figure out how to set mysql properly without touching mysql but having it work
<raphink> it's not worth it the bounty ;)
<marcin_ant> raphink, anyway - let's do something with this nasty config file....
<raphink> marcin_ant: but I understand you need this package for yourself :)
<raphink> so it's good you take care of it :)
<marcin_ant> raphink, yes - I want bounty ;)
<raphink> I've understood that, too
<raphink> :)
<marcin_ant> raphink, I'm from poor country so every money counts - but yes I need this package for my customer
<raphink> I personnaly would rather like a job than a single bounty ;)
<raphink> hehe
<marcin_ant> raphink, I'm working on vtiger integration with existing ERP software for my customer
<raphink> I'm not from a poor country and this bounty wouldn't have me live a 10th of a month
<raphink> marcin_ant: do you use tiny-erp?
<marcin_ant> raphink, nope some proprietary stuff
<raphink> marcin_ant: you should throw an eye on tiny erp some day
<raphink> it's getting better by the month
<raphink> right now surely the best open-source erp around
<marcin_ant> raphink, and I have to write some SOAP modules to put vtiger and ERP together
<ajmitch_> raphink: it would let me live for a week or two if I stretched it :)
<raphink> written in python/gtk
<raphink> ajmitch_: hehe
<raphink> ajmitch_: well the bounty poster said he could consider increasing the bounty if it took too much time, so I think he will
<raphink> so in the end it might be quite a lot though ;)
<raphink> say, $200 or more
<ajmitch_> raphink: I considered going for it, but someone had already started by the time I had spare time
<raphink> ajmitch_: I had started ;)
<raphink> I was the first one starting it, accoring to the bounty poster
<raphink> ;)
* ajmitch_ doesn't even have $200 in the bank at the moment
<raphink> but then I stopped for a while and marcin_ant began
<marcin_ant> raphink, I'll take a look but currently this company deployed commercial ERP and they spent about 4000 euro on licenses so I think that they will not change this in near future
<raphink> marcin_ant: well just have a look ;)
<lifeless> raphink: 200 is < a days work for minimum legal salary here
<lifeless> well, less than 2 days work.
<raphink> in europe/US lifeless
<raphink> lifeless: not everybody is from there
<raphink> of course for me/us it's not a lot of money
* ogra guesses even in .au 
<lifeless> raphink: where do you think I am from ?
<raphink> lifeless: where do you think marcin_ant is from?
<marcin_ant> lifeless, in PL 300$ is minimal salary for a month (official)
<raphink> lifeless: I don't know where you're from
<marcin_ant> lifeless, but it's really minimum sallary and fortunately I don't have to work all month for $300
<raphink> in fr, minimum salary for a month is about $1000
<marcin_ant> raphink, no you are wrong ;)
<lifeless> raphink: .au, neither us nor europe
<raphink> marcin_ant: sorry?
<marcin_ant> raphink, 1000 but euro not $
<raphink> marcin_ant: well tahts quite the same
<raphink> it's even a bit more in 
<raphink> and then it depends if you see it as gross or net
<raphink> so more or less $1000
<marcin_ant> raphink, in PL 1 euro = 4zl and 1 usd = 3zl so it
<raphink> yes
<marcin_ant> raphink, is 25% difference
<raphink> mhm
<lifeless> legal minimum here is (IIRC) 12.50AUD/hour = 25000/year or 2000 a month
<ajmitch_> lifeless: I should move to .au then :)
<raphink> officially
<raphink> for 2005
<lifeless> so 500/week (before tax), or 100/day
<marcin_ant> in PL legal minimum is about $300 - average is about 1000
<raphink> the minimum salary for 169 work/month
<raphink> in france
<raphink> is
<raphink> 1 357,07  gross
<lifeless> at the entry tax bracket that gives you about 70/day cash in hand
<marcin_ant> anyway guys... back to work ;)
<raphink> lets not forget the 7 LOL
<raphink> ok
* ajmitch_ will be in .au in thursday, but not in sydney
<raphink> lifeless: here the minimum gross pay per hour is 8,03
<marcin_ant> in .pl you can buy bread for $0.5 in .au propably $1 or more
<raphink> marcin_ant: true
<marcin_ant> so it's hard to compare money
<marcin_ant> with real parity power
<raphink> I remember buying bread for 400 rbls in Moscow (0.08)
<raphink> which is totally impossible here
<marcin_ant> s/parity/purchasing
<raphink> (hmm 400 rbls in 1998, I think the rates changed a lot since)
<marcin_ant> guys... what can I do with this crappy .postinst script????
<raphink> :s
<lifeless> ajmitch_: perhaps ")
* raphink hopes the LP upgrade will fix the bug on his page 
<lifeless> ajmitch_: dude, you gotta come to syd
<ajmitch_> lifeless: working for 2-3 weeks in brisbane
<ajmitch_> so it's not likely I'll get down to sydney on this trip :)
<lifeless> wave on the way by :)
<raphink> looks like it's gonna be a quick keysigning party in the airport
<jpatrick> raphink: fun
<raphink> jpatrick: hehe
<Casanova> hello i have created a package for LDTP -- Linux Desktop Testing Project -- http://ldtp.freedesktop.org I have uploaded the files to http://prash.be/ldtp/ubuntu/
<Casanova> what is the process i need to follow to get this package into the ubuntu package line?
<Gloubiboulga> Casanova, you need to upload your package on REVU (http://revu.tauware.de)
<Gloubiboulga> then MOTUs will review it and upload it when it's ok
<Casanova> ok :-)
<Casanova> thanx
<jpatrick> Casanova: I recommend removing the config.sub and .guess commands from debian/rules
<Casanova> hmmm
<Gloubiboulga> Casanova, you'll have to send your public gpg key to a revu admin to upload
<Casanova> Gloubiboulga> ok
<Casanova> jpatrick> i dont have those commands on my rules files
<Gloubiboulga> Casanova, https://wiki.ubuntu.com/MOTU/Packages/REVU for more informations :)
<jpatrick> Casanova: oh I see they're commented
<Casanova> yes :)
<Casanova> jpatrick> do you notice any other possible abnormalities?
<jpatrick> nope
<Casanova> ok thank you :)
<Gloubiboulga> Tonio_, zakame, raphink thanks a lot :)
<zakame> Gloubiboulga: strictly speaking its not out of the woodworks yet, but I think we can celebrate ;)
<Gloubiboulga> :)
<Toadstool> Gloubiboulga: you've become Ubuntu member ? :)
<Gloubiboulga> Toadstool, not yet, but nearly
<Toadstool> congratulations then
<Gloubiboulga> thanks :)
<raphink> siretart: if you're around please consider nuking simias
<StevenK> siretart: Hrm, Linda seems to work not so well on REVU
<raphink> StevenK: how do you mean?
<raphink> StevenK: the lintian and linda run on REVU are from breezy
<StevenK> http://revu.tauware.de/revu1-incoming/klearlook-0601050135/linda
<zakame> StevenK: true, I've been observing it since last year :/
<StevenK> Run Linda with LINDA_ROOT set.
<StevenK> And make sure $LINDA_ROOT/po/en.mo exists.
<StevenK> Then that problem will go away.
<StevenK> siretart: ^
* Yagisan is depressed. /me has to do some work on windows boxes :(
<StevenK> Yagisan: I got to talk my way out of that today.
<StevenK> Made me slightly happier.
<Yagisan> StevenK: I need the money so I have too. If I could somehow integrate my Breezy cd into my Windows all-in-one install dvd I'd be happy
* StevenK only has to deal with Windows machine for family members.
<StevenK> I'm over their places fairly regularly so I can keep an eye on them.
<Yagisan> StevenK: love to say, sure just install option 10 (Breezy) on the next install and the problems will be gone for good
<Yagisan> StevenK: you're nearby - I may see you one day, while I'm doorknocking for new customers
<StevenK> Yagisan: Whereabouts are you? If you are close, lunch together would be cool.
<Yagisan> StevenK: Lidcombe
<StevenK> Yagisan: Nice! I work in Burwood, which is nice and close.
<Yagisan> StevenK: cool, that's two trains stops away :)
<StevenK> Yagisan: Tell you what, if you can work with Debian and diagnose network problems on Linux machines, I'll drop your name to the support manager at work.
<Yagisan> StevenK:  Yes I can (You can even see my paper certs too if you like, that make a nice wallpaper) . I'll bring my business cards :)
<StevenK> Yagisan: I'll see if we're looking for someone first.
<Yagisan> StevenK: Keep a card anyway, just in case, I'm open 24/7 if things turn bad. Where do you work ? There is an ok indian takeaway at the westfield
<StevenK> Yagisan: That Indian takeaway is nowhere near okay.
<StevenK> Yagisan: Down Burwood Rd, number 13 - a small place called Ursys - we basically sell/support Linux-in-a-box routers.
<Yagisan> StevenK: having gotten food poisoning at most places there, it's one of the few that I don't regret eating at yet
<StevenK> *blink*
<StevenK> I don't mind the sandwich place, Subway and Oporto
<StevenK> They are about the only places I will eat at.
<Yagisan> StevenK: please don't say subway. It's been 8 days since I got sick from DFO's subway, and an ambo came to pick me up
<Yagisan> StevenK: Oporto it is :)
<StevenK> However, due to buying my own place (yay Sydney house prices), I'm buying ham and cheese rolls.
<StevenK> Yagisan: We can make it Thursday if you like.
<StevenK> My wife has forked over a list of things to do tomorrow lunch time.
<Yagisan> StevenK: sure. I'm at a clients in Westmead in the morning. I'm free from 2pm on
<StevenK> Eek. 2pm for lunch bad.
<Yagisan> StevenK: Friday is not booked
<StevenK> Yagisan: Friday is the work BBQ.
<StevenK> Every Friday is the work BBQ, which is nice. :-)
<Yagisan> StevenK: k, either Sat, Sun or the 16th
<StevenK> Heh. I'm in Canberra this weekend.
<StevenK> The 16th works.
<Yagisan> StevenK: great :) next thursday. When do you start lunch ?
<StevenK> 12-1
<Tonio_> congrats Gloubiboulga  ;) sorry I couldn't say more since raphink said about everythings needed.... :)
<StevenK> Whenever, basically.
<Gloubiboulga> Tonio_, np :)
<StevenK> I usually like to make it 12:30
<StevenK> Speaking of 12:30, I ought to be in bed.
<Yagisan> StevenK: ok. meet you @ oporto or @ work ?
<StevenK> Yagisan: Oporto works better. Saves you having to walk all the way down to the office, and then back up to the Westfield.
* StevenK scarpers off to bed.
<Yagisan> StevenK: you won't miss me, I'll wear my beloved ubuntu t-shirt
<Yagisan> night StevenK
<Hobbsee> oh is it really 12.30?
<Hobbsee> i guess it is
<Yagisan> Hobbsee: yes. but sleep is for sissys ;)
<Hobbsee> hehe
<Hobbsee> yeah, doing uni timetables are far more interesting!
* Yagisan has a uni exam @ 8:50am then a client meating @ 1:30 today
<Yagisan> s/meating/meeting
<Hobbsee> ouch
<Yagisan> Hobbsee: what uni ? I'm looking to dump mine as it's as useful as tits on a bull
<Hobbsee> Yagisan: macquarie uni
<zakame> Yagisan: LOL!
<zakame> meating indeed
<Hobbsee> the program that i'm doing, they want me to do 4 hours of lectures straight!
<Yagisan> Hobbsee: I need one that does distance study
<Hobbsee> i'm doing a bachelor of technology in optoelectronics
<Hobbsee> ah ok
<Hobbsee> where are you, anyway?
<Yagisan> Hobbsee: CSU punished me for actually trying to get an education and asking questions
<Hobbsee> hehe
<Yagisan> Hobbsee: Lidcombe
<Hobbsee> ah yep
* zakame is just doing that ;)
<Yagisan> Hobbsee: no joke - from 80-100% to 0
<Hobbsee> well if you want to use one of the lessons that you've learned in messing around with timetables, you're welcome to do mine lol :P
<Yagisan> Hobbsee: I was doing a Bach in I.T (Not needed here in Aus, but customers in the land of the rising sun feel better if I have it)
<Hobbsee> ah yep
<Yagisan> Hobbsee: 2 Cert 4's, 2 Dips, and 1 Adv Dip == I spent too much time studying
<Hobbsee> hehe
* Hobbsee gives up
<Hobbsee> why cant the second semester be as simple and relatively nicely worked out as the first?
<Yagisan> Hobbsee: it can't be too bad. They are forcing me to learn java
<Hobbsee> yucky
<Yagisan> Hobbsee: haven't I been punished enough ??
<Hobbsee> hehe
<Hobbsee> !
<Hobbsee> clearly not
* Yagisan cries. Java is useless for my work. Why can't it be C, or C++
<Hobbsee> oh well...night all
<jpatrick> night
* Yagisan appears to be a contender for last aussie to go to bed. Can he take it ? Whose bloodshot eyes will reign supreme ? <cue Iron Chef Theme here>
<siretart> StevenK: yes, do you have any idea what could be the cause?
<zakame> Yagisan: <drum roll>
<Toadstool> siretart: about revu mail notices, is it possible to add a In-Reply-To field with the Message-ID of the first upload notification so that threads about a particular package stay grouped ? :)
<jpatrick> raphink: do I need to be an MOTU to review at REVU?
<raphink> yes jpatrick
<jpatrick> I thought you were one before...
<Yagisan> zakame: Yagisan takes it! Yagisan's bloodshot eyes reign supreme <cue Iron Chef end credits>
<zakame> raphink was given special privs iirc :)
<zakame> indeed, he's the REVU masta :D
<jpatrick> yes he was
<raphink> zakame: the revu masta is siretart iirc ;)
<zakame> raphink: err right :) sorry
<marcin_ant> raphink, hi again
<marcin_ant> raphink, got solution to this mysql issue you were talking about
<marcin_ant> raphink, but still no luck with this *.postinst crap :(
<raphink> argh :s
<sistpoty> hi folks
<zakame> heya sistpoty :)
<Gloubiboulga> hi sus
<Gloubiboulga> :/
<Gloubiboulga> hi sistpoty
<sistpoty> heya
<raphink> hi sistpoty
<Gloubiboulga> sistpoty, Katie didn't mail me about libswitch
<Gloubiboulga> you uploaded it iirc
* sistpoty looks
<sistpoty> Gloubiboulga: I got an accepted... it will need to pass the new queue first though
<Gloubiboulga> ok, thanks
<sistpoty> s/accepted/is new/
<sistpoty> np
<marcin_ant> are there any rules when apt decides when regenerate or not to regenerate package config files?
<raphink> one of my packages was accepted, built but never reached the binary repos
<raphink> although it was successful on buildd
<raphink> I tried pinging lamont but he didn't answer
<Gloubiboulga> raphink, do you know why so ?
<raphink> no idea
<sistpoty> marcin_ant: what do you mean with "regenerate package config file"?
<marcin_ant> sistpoty, I'm trying to create package and I got 'beautifull' postinst sctipr
<lfittl> raphink: I have the same problem, if you find out who could fix this, please inform me ;)
<raphink> lamont, only lamont lfittl
<marcin_ant> sistpoty, and this postinst generates config file with mysql connection settings for some webapp
<marcin_ant> sistpoty, it _should_ work but unfortunately when trying to install package
<marcin_ant> sistpoty, I can see this
<lfittl> raphink: k, thanks
<marcin_ant> sistpoty, "Not replacing deleted config file /usr/share/vtiger-crm/connection.php
<marcin_ant> "
<marcin_ant> sistpoty, and I'm really annoyed now because without this connection config application won't work
<marcin_ant> sistpoty, and I'm sure that script that generates this config is ok
<sistpoty> marcin_ant: that's interesting... didn't see this one before...
<marcin_ant> sistpoty, but have no idea why apt refuses to regenerate this file
<lfittl> raphink: I saw that your preferred e-mail address on launchpad is set to your @ubuntu.com address, isn't that causing errors with the forwarding of your @ubuntu.com address?
<sistpoty> marcin_ant: my guess would be that it is registered as config file by apt and got deleted somehow. have you tried purging your deb (imo apt's knowledge about the config file should then go away)?
<marcin_ant> sistpoty, yes I purge this file in postrm with just some rm -f
<raphink> lfittl: nope, no error
<sistpoty> marcin_ant: oh... I guess you just shouldn't do that, if the file is in the package, since apt should will do this for you (iirc)
<marcin_ant> sistpoty, I got if [ "$1" = "purge" ] ; then rm -f ..............connection.php fi
<marcin_ant> sistpoty, this file is not in package :(
<marcin_ant> sistpoty, I generate this file from another template with script called from postinst
<marcin_ant> sistpoty, I got /etc/mypackage/connection.template
<lfittl> raphink: I thought elmo once said the script that updates the @ubuntu.com takes the preferred address from launchpad, that behaviour must have changed then
<marcin_ant> sistpoty, then I use postinst to parse this connection.template - replace some tokens
<sistpoty> marcin_ant: this is really strange then, because apt shouldn't know about the file then (and thus could not complain)
<marcin_ant> sistpoty, and output this to /usr/share/mypackage/connection.php
<sistpoty> marcin_ant: do you have the source package anywhere? then i could take a look
<marcin_ant> sistpoty, moment
<raphink> lfittl: ah!
<raphink> lfittl: I don't think so, I receive the emails sent to ubuntu.com
<lfittl> raphink: k, good to know :)
<raphink> ;)
<raphink> you can try it and see if that works lfittl :)
<raphink> send me a message
<raphink> :)
* raphink likes to receive personal messages, not from ML s:)
<lfittl> me too :)
<lfittl> while I am sending the message, do you have some time to review some patches?
<lfittl> (bug 30705, bug 30706, bug 30708)
<Ubugtu> Error: I tried to send you an empty message.
<lfittl> oh, and also bug 29366
<Ubugtu> Error: I tried to send you an empty message.
<lfittl> Seveas: is there something wrong with Ubugtu?
<Seveas> yes
<lfittl> k, if you know that this is not working, i know it will be fixed soon :)
<zakame> Ubugtu: you did?
<siretart> Toadstool: not easily, that message notification is implemented quite hackish
<lfittl> Seveas: does the @reload command affect all channels?
<Seveas> bug 29366
<Ubugtu> malone bug 29366 in gdesklets "[Dapper] Depends: libgtop2-5 (>=2.9.4) but it is not installable" [Normal,Fix committed]  http://launchpad.net/bugs/29366
<Seveas> (yes)
<lfittl> perfect :)
<Toadstool> siretart: oki, that was just a proposal, may I have a look at the code of the notification system ?
<lfittl> siretart: do you have some time to review my patches for bug 30705, bug 30706 and bug 30708?
<Ubugtu> malone bug 30705 in slmon "Requires rebuild for new libgtop" [Normal,Fix committed]  http://launchpad.net/bugs/30705
<Ubugtu> malone bug 30706 in bubblemon "Requires rebuild for new libgtop" [Normal,Fix committed]  http://launchpad.net/bugs/30706
<Ubugtu> malone bug 30708 in wmufo "Requires rebuild for new libgtop, bad build deps" [Normal,Fix committed]  http://launchpad.net/bugs/30708
<Seveas> bug 1,2,3
<Ubugtu> malone bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<Seveas> hmm
<jamessan> hah
<jamessan> any ETA on a fix for that?  ;)
<siretart> Toadstool: there is no point in spending much energy in the old codebase. If you want to help, please contribute to revu2: http://tiber.tauware.de/cgi-bin/trac.cgi
<Seveas> RSN, making the monstruous regex even bigger...
<Toadstool> siretart: oki, I thought the code on the Trac was the one in production
<siretart> Toadstool: no
<siretart> Toadstool: the code from trac is not really usable yet.
<Toadstool> yeah I've quickly read it already
<sistpoty> unfortunately... maybe I'll have a little bit time later this week :)
<siretart> hi sistpoty
<sistpoty> hi siretart, Toadstool bztw
<Toadstool> hi sistpoty
<siretart> :)
<sistpoty> Toadstool: I didn't come to review your package yet, but I will do later today ;)
<Toadstool> I don't mind I'm not that in a hurry you know ;)
<Toadstool> that's my first attempt to package
<sistpoty> hehe, you should be... FeatureFreeze is comming (too) soon ;)
<Toadstool> yeah well I hope upstream is going to quickly answer to my mail about the license issue...
<sistpoty> :)
<Seveas> bug 1,3, 1000,#30000
<Ubugtu> malone bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<Ubugtu> malone bug 3 in rosetta "Custom links for each translation team." [Wishlist,Confirmed]  http://launchpad.net/bugs/3
<Ubugtu> malone bug 1000 in launchpad "There are too many bug reports in Malone" [Normal,Rejected]  http://launchpad.net/bugs/1000
<Ubugtu> malone bug 30000 in gnome-system-tools "Start of week is Tuesday - change not obvious" [Normal,Unconfirmed]  http://launchpad.net/bugs/30000
<lfittl> :)
<sistpoty> uh, nice!
<Seveas> there ya go, insta-flood :)
<Toadstool> :)
<sistpoty> for i in range[1,1000] : bug i :P
<Seveas> there is a throttling mechanism
<Seveas> and I'm going to limit it to 5
<zakame> gn8
<Gloubiboulga> good night zakame
<Seveas> bug 1,1,2,3,5,8,13,21
<Ubugtu> malone bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<Ubugtu> malone bug 3 in rosetta "Custom links for each translation team." [Wishlist,Confirmed]  http://launchpad.net/bugs/3
<Ubugtu> malone bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix committed]  http://launchpad.net/bugs/5
<Yagisan> night zakame
<Seveas> muha :)
<sistpoty> great
<Toadstool> this bot rocks :)
<Seveas> if you want more: bug 1,2,3,4,5 bug 7,8,9,10
<Ubugtu> malone bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<Ubugtu> malone bug 3 in rosetta "Custom links for each translation team." [Wishlist,Confirmed]  http://launchpad.net/bugs/3
<Ubugtu> malone bug 4 in rosetta "Importing finished po doesn't change progressbar" [Normal,Fix released]  http://launchpad.net/bugs/4
<Ubugtu> malone bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix committed]  http://launchpad.net/bugs/5
<Ubugtu> malone bug 7 in rosetta "Need newbie documentation" [Normal,Confirmed]  http://launchpad.net/bugs/7
<Ubugtu> malone bug 8 in rosetta "Translator forums/means of communication" [Wishlist,Confirmed]  http://launchpad.net/bugs/8
<Ubugtu> malone bug 9 in rosetta "Rosetta's po parser is too strict" [Normal,Fix released]  http://launchpad.net/bugs/9
<Ubugtu> malone bug 10 in malone "It says "displaying matching bugs 1 to 8 of 8", but there is 9" [Normal,Rejected]  http://launchpad.net/bugs/10
<Toadstool> siretart or sistpoty: is there a spec available for revu2 ?
<sistpoty> Toadstool: https://wiki.ubuntu.com/REVU2Spec
<Toadstool> thanks
<phanatic> hi people
* Yagisan is tempted to test how good this bot really is
<Yagisan> http://bugs.winehq.org/show_bug.cgi?id=4281
<Yagisan> damm no reaction :(
<sistpoty> it will listen only to *some* ppl :P
<phanatic> raphink: ping
<raphink> phanatic: pong
<phanatic> raphink: regarding http://revu.tauware.de/details.py?upid=1669 - i only have to correct 'Build-Depends-Indep: debhelper' to 'Build-Depends: debhelper', right?
<sistpoty> lucas: got my mail to -motu regarding flashplugin-nonfree?
<raphink> yep phanatic
<raphink> but it's a main issue phanatic, according to the reports on debian-devel
<lucas> yup, replied
<sistpoty> lucas: ah, k... (mail's not here yet)... will you take a look?
<lucas> I'm busy those days
<sistpoty> ok
<lucas> a lot of jabber stuff to deal with
<phanatic> raphink: what do you mean by "it's a main issue"?
<raphink> phanatic: it can generate huge bugs to use debhelper in Build-Depends-Indep from what I've understood
<raphink> although I've not gotten much further, it is not recommended
<raphink> a tall
<phanatic> okay
<phanatic> i upload the corrected package now
<phanatic> it's good to know anyway...
<raphink> cool
<phanatic> done, should appear any minute :)
<raphink> ok
<Gloubiboulga> is gettext needed in build-deps ?
<Gloubiboulga> I've never seen it, but I can be wrong
<raphink> Gloubiboulga: does a postinst/prerm or so scirpt use a gettext prog ?
<raphink> Gloubiboulga: check the functions used in the scripts
<Gloubiboulga> raphink, no script
<raphink> Gloubiboulga: even in debian/rules?
<Gloubiboulga> cdbs rules... you're the expert ;)
<Gloubiboulga> but I don't think it's used
<raphink> no it's not used by cdbs
<raphink> otherwise cdbs would depend on it and it would be no issue
<Gloubiboulga> right
<raphink> Gloubiboulga: the debian/rules is only cdbs? nothing more?
<phanatic> raphink: http://revu.tauware.de/details.py?upid=1676
<raphink> I'll have a look phanatic
<raphink> report running phanatic, let's wait ;)
<Gloubiboulga> raphink, xsltproc is used, but nothing else
<raphink> Gloubiboulga: what is this prog in ? in which package?
<phanatic> raphink: okay, thanks :)
<raphink> phanatic: ready to upload :)
<Gloubiboulga> raphink, it's used to manage dockbook to man conversion
<raphink> hmm
<raphink> there's docbook2x for that
<Gloubiboulga> yep, I'll propose the packager to use it
<Gloubiboulga> but I think gettext build-dep is useless anyway
<raphink> phanatic: uploaded
<raphink> phanatic: are you subscribed to Katie ?
<lfittl> My UVF exception for lyx got accepted 1 week ago, but nothing happend so far, could somebody upload it for me? (revu 1537)
<Mez> ogra: ping
<phanatic> raphink: nope
<raphink> phanatic: you should ping elmo to be whitelisted for katie, so you get the noticed on whether your packages are accepted or rejected and why
<raphink> phanatic: otherwise, nobody will know
<phanatic> raphink: shall i contact elmo here on irc?
<ogra> raphink, we dont use katie anymore
<raphink> ogra: ?
<ogra> raphink, katie was replaced by soyuz
<raphink> ogra: oh yes :)
<lfittl> ogra: do you get ACCEPTED/REJECTED notifications from soyuz?
<raphink> poor katie :s
<lfittl> ogra: or asked in a different way: Is the source NEW queue managed by soyuz?
<ogra> lfittl, yes and yes
<lfittl> nice :)
<raphink> ogra: are the packagers/uploaders notified by default by soyuz ?
<raphink> or do we need to be whitelisted again?
<ogra> no idea :=)
<raphink> hehe
<raphink> would b enice to know ;)
<ogra> but its not elmo and katie anymore, thats for sure
<sistpoty> to my knowledge the uploaders are notified
* phanatic stops himself :)
<sistpoty> and I'd assume that no whitelisting is necessary... this just wouldn't fit into LP ;)
<ogra> at least you need a working launchpad account, thats the prerequisite
<ogra> and whitelisting will happen through it ...
<ogra> but dont ask me how :)
<sistpoty> whitelisting == sign COC? *g*
<sistpoty> or better: karma > 10 *g*
<lfittl> maybe whitelisting is now done through LP teams, but that would be really bad for MOTU wannabees..
<sistpoty> well, we could just ask over in #lp... but speculating is more fun ;)
<lfittl> yep :)
<siretart> crimsun: around?
<derekS> i have a question. can someone tell me why mutt requires postfix?
<sistpoty> derekS: it calls sendmail iirc and thus needs an m-t-a (so the depends: on postfix | mail-transport-agent)
<sistpoty> derekS: this has also be discussed on ubuntu-devel ml... but I don't know exactly how long ago
<derekS> sistpoty: what would the effect of putting postfix onto my system?
<derekS> any security concerns?
<sistpoty> derekS: not quite sure if the server is started by default...
<derekS> sistpoty: ok, is there another console imap reader you would reccomend, that doesn't require postfix?
<sistpoty> derekS: no, I'm not using console-mail reader, so I can't help you there ;)
<derekS> sistpoty: well thanks for your help anyways :)
<sistpoty> np
<derekS> wait, is postfix installed by default (i am reading old ML emails, and it seems it is)
<Toadstool> you have to have an mta for some other daemons to work correctly iirc
<derekS> i can't find sendmail or postfix on my system...
<sistpoty> derekS: no /usr/bin/sendmail?
<Toadstool> maybe exim ? exim is installed by default on debian
<sistpoty> ' /usr/sbin/sendmail actually
<derekS> none of those
<Toadstool> derekS: don't you have mailx installed ?
<derekS> i don't think so, lemme check dpkg
<Toadstool> it depends on postfix | mail-transport-agent and is installed on a default ubuntu system i think
<derekS> nope
<Toadstool> hum weird
<ogra> no MTA is installed by default ...
<derekS> is it part of kubuntu-desktop?
<Toadstool> i have to take some more ubuntu lessons then :)
<Toadstool> it's been a long time since i didn't install a full ubuntu and customized it completely, my computer runs ubuntu since warty and I only dist-upgraded for each release
<derekS> i don't think i have removed anything on this
<ogra> MTA was installed until hoary ... if you upgraded it might still be there
<ogra> newly installed breezys wont have it
<derekS> ogra: ok, this was a fresh breezy
<Toadstool> ah ok
<derekS> what would you reccomend in my situation?
<derekS> i want mutt, but don't want to worry about security
<ogra> suod apt-get install postfix ?
* siretart would strongly suggest installing an MTA. it is very convinient
<derekS> what will an MTA do (other than allow me to use mutt)
* ogra doesnt use one and is fine with that ...
* siretart prefers exim4
<Toadstool> derekS: by default it only listens to the loopback adress, so no security issues
<siretart> sure, it is not that mission critical, but quite convinient..
<ogra> derekS, not much more ... since all mail transporting actions are disabled ... you probably might get cron mails ...
<derekS> hmm, ok, i am going to install, then make sure it only looks at loopback
<ogra> it asks you on install if you only want local transport
<ogra> just say yes there :)
<jpatrick> hey apachelogger!
<jpatrick> I believe they uploaded your kblogger package :)
<derekS> ogra: what config file would that be in... i chose local, but i just want to ensure
<siretart> lifeless: can you help me out please: it seems that python2.4-bazaar and pybaz provide same file, but do not conflict each other. I think one of them is obsolete, but I don't know which. can you help me out?
<Toadstool> derekS: /etc/postfix/main.cf
<derekS> would this be right... inet_interfaces = loopback-only
<jpatrick> apacheLAGger: did you get the messages I sent?
<apacheLAGger> jpatrick: nope :|
<jpatrick> is to be installed
<apachelogger> kewl :-)
<jpatrick> [18:22:06]  <jpatrick> hey apachelogger!
<jpatrick> [18:22:27]  <jpatrick> I believe they uploaded your kblogger package :)
<apachelogger> aye, got that
<apachelogger> ;-)
<Gloubiboulga> dapper still uses gstreamer0.8 or 0.10 ?
<Amaranth> 0.10
<Gloubiboulga> ok thanks Amaranth
<slomo> well, depends... we will have many packages in universe which will still use 0.8
<derekS> Toadstool: how would i go about sending an email to myself, to create the spoolfile (which i need for mutt
<Gloubiboulga> slomo, both 0.8 and 0.10 can be installed without conflict ?
<slomo> yes
<Gloubiboulga> ok
<Toadstool> derekS: I think this kind of question may be treated on #ubuntu instead of here
<derekS> Toadstool: ok
<dolson> my mouse stopped working :(
<stratus> dolson: blame ogra
<ogra> stratus, ??
<dolson> ogra: why did you break my mouse? :(
<stratus> ogra: you're now the official ubuntu mouse breaker(tm)
<ogra> haha
<stratus> dolson: no, you should said that you tried the mdetect thing
<ogra> i dont break mice
<dolson> it's been slowly dying for a couple weeks, and now it's dead
<stratus> ogra: heh
<dolson> but it was working fine until I came in here
<stratus> dolson: shut up and use the trackpad
* stratus hides
<ogra> mdetect wont do any harm to any furry animals :)
<dolson> what trackpad
<stratus> dolson: if you're not using a laptop you should be logged in a server. there are no desktops
<Mez|Work> whta happened to webmin in dapper ?
<stratus> ogra: heh
<dolson> I am on a desktop :P well, a coffee-table top..
<stratus> dolson: i don't trust machines that i can't throw against a wall easily
<dolson> well, I have removable hard drives, so I could pull it out and throw it against a wall easy enough
<stratus> dolson: good trick.
<dolson> I've had other mice that have lasted for years and years... but this one hasn't lasted very lock
<dolson> long I mean
<dolson> maybe it just needs to be rebooted
<dolson> it is a Microsoft Wheel Mouse Optical, after all
<stratus> buy a new one and blame the manufacturer, the driver, bush, whatever.
<dolson> bush - not my president!
<dolson> (because I'm Canadian)
<stratus> point of view matter, imho
* stratus hides
<dolson> I live in the State of Ontario! :)
<stratus> heh
<dolson> it kinda is the United States of Canada. or maybe more properly the United Provinces of America
<stratus> quick fix: 'north america'
<dolson> really north
<stratus> sure
<dolson> we measure our snow in hours here
<stratus> yes, i'm sure you're using weird measure units for almost everything. :-)
<dolson> yesterday we had two hours worth of shovelling before we could get our car out of the driveway. I hate this place. I think we should build a great big dome over all of Ontario so as to block out the sun-- er, snow
<chillywilly> isn't there a meta package that will install development tools?
<chillywilly> and is it on the install disk?
<chillywilly> cause I really need it
<stratus> chillywilly: which dev tools?
<chillywilly> need to build drivers for sangoma card
<chillywilly> no T1 until then :(((
<stratus> chillywilly: do you want build-essential?
<dolson> ooh, an asterisk user
<ogra> build-essential
<chillywilly> nope, it's just for internet
<dolson> oh lol
<chillywilly> ogra: do you know if that's on the install disk?
<ogra> it is
<chillywilly> thanks
* chillywilly has to run home and get his ubuntu CD
<chillywilly> having no internet at that location really sucks
<bddebian> Hey gang
<bddebian> Anyone know how I can pass dpkg's --root=/foo to apt-get using -o ?
<bddebian> Is it even possible?
<sistpoty> hey bddebian
<sistpoty> no idea actually...
<bddebian> Heya sistpoty
<bddebian> I thought maybe I'd come to the wrong channel :-)
<sistpoty> hehe
<bddebian> I don't think I've ever seen it this quiet in here :-)
<sistpoty> seems like everyone is busy ;)
<LaserJock> hi bddebian
<bddebian> Heya LaserJock
<LaserJock> it should be pretty easy to make a dapper chroot in sarge, right?
<sistpoty> LaserJock: I guess it should, but I'm not sure if you'll need this (and/or s.th. else) from dappers debootstrap: /usr/lib/debootstrap/scripts/dapper
<LaserJock> yeah, so maybe I can install the dapper debootsrap .deb
<LaserJock> hmm, it's running a 2.4 kernel, whould that be a problem?
<sistpoty> LaserJock: not quite sure about that... haven't tried yet ;)
<LaserJock> I think I'll give it a go. Right now all I have access to is OSX and a sarge install and I want to be able to do some pbuilder work
<sistpoty> :)
<LaserJock> it would be nice if they got dapper working on the mac Intel chips :-)
<crimsun> siretart: pong
<lfittl> sistpoty: do you have time to upload 4 patches for me?
<sistpoty> lfittl: yes
<lfittl> bug 29366, 30705, 30706, 30708
<Ubugtu> malone bug 29366 in gdesklets "[Dapper] Depends: libgtop2-5 (>=2.9.4) but it is not installable" [Normal,Fix committed]  http://launchpad.net/bugs/29366
<Ubugtu> malone bug 30705 in slmon "Requires rebuild for new libgtop" [Normal,Fix committed]  http://launchpad.net/bugs/30705
<Ubugtu> malone bug 30706 in bubblemon "Requires rebuild for new libgtop" [Normal,Fix committed]  http://launchpad.net/bugs/30706
<Ubugtu> malone bug 30708 in wmufo "Requires rebuild for new libgtop, bad build deps" [Normal,Fix committed]  http://launchpad.net/bugs/30708
<lfittl> changelog patches are attached to every bug ;)
<sistpoty> lfittl: will take some time... stay tuned for incoming mails ;)
<lfittl> k, thanks :)
<sistpoty> lfittl: gdesklets: mere rebuilds should be numbered -Xbuild1 instead of -XubuntuY (as long there is no -Xubuntu(Y-1) version yet)...
<sistpoty> lfittl: I'll fix it in the patch ;)
<lfittl> k, sry for that, will do that in future rebuild patches
<sistpoty> np... just wanted to inform you... (reason is that -XbuildY will be autosynced, -XubuntuY have to be merged)
<lfittl> oh, than its really better to use -XbuildY :)
<sistpoty> yes... if it weren't for the merges, it wouldn't matter ;)
<sistpoty> lfittl: for wmufo: "Removed some bad build-deps..."
<sistpoty> lfittl: it would be good, if you could be more verbose and name what you removed (at least in the future) ;)
<lfittl> sistpoty: k, will try to be more verbose in the future ;)
<sistpoty> :)
<sistpoty> lol, there is a file named ALL_I_GET_IS_AN_ALIEN_FACE in the source *g*
<lfittl> lol :)
<lfittl> btw.: are you also working through the unmet-deps list?
<sistpoty> lfittl: yes... (actually I'm trying to do some programming work and only run a pbuilder in the background)
<lfittl> me too, programming on the laptop, and fixing packages on the computer :)
<sistpoty> hehe
<jpatrick> yet an program beginning with K by me: http://revu.tauware.de/details.py?upid=1683
<ogra> jpatrick, should we call you Kjpatrick ? :)
<jpatrick> ogra: :) - but K-MOTU sounds nice :)
<ogra> heh
<sistpoty> damn, all these new packages on review... we should make up a policy like "fix two bugs and we'll review your package" :P
<sistpoty> s/on review/on revu/
<lfittl> well, feature freeze is coming, people want to get their packages in ;)
<jpatrick> wait it's at: http://revu.tauware.de/details.py?upid=1684
<sistpoty> sure, they do... I also want to get a package in (but didn't have time to package it yet :()
<Toadstool> for example, i'd like my first one to be in dapper yeah :)
<Toadstool> but as everybody here has a lot of work to do I understand that it takes time
<lfittl> sistpoty: thank you for uploading the patches, if I find some other packages that need a simple rebuild, should I open a bug, or just send you a message?
<slomo_> ogra: ping? you wanted to have f-spot on your ibook iirc... just use "deb http://tiber.tauware.de/~slomo/mono-ppc ./"
<ogra> slomo_, will do, thanks a lot ...
<ogra> :)
<slomo_> np :) i have to build this stuff for me anyway
<ogra> does your sound work with todays kernel ?
<sistpoty> lfittl: sorry, was just afk... you can just send me a patch (sistpoty@ubuntu.com)
<lfittl> sistpoty: np, will send you some patches tonight :)
<slomo_> ogra: nope :( it can open the device but no sound
<ogra> ah, k, so i'm not alone... semms it worked for pitti
<slomo_> hm, didn't he say that it doesn't work for him too?
<ogra> it worked after an extra reboot ...
<slomo_> interesting
<slomo_> maybe i should reboot again :)I
<Kyral> Yo Motuish people
<ogra> i had already 10+ reboots ...
<LaserJock> hi Kyral
<lifeless> siretart: I dont see a python2.4-bazaar package in dapper
<ajmitch_> lifeless: python2.4-pybaz?
<ajmitch_> hm now
<ajmitch_> s/now/no/
<ajmitch_> there's just a pybaz binary, how strange
<Kyral> hmm
<Kyral> how does uscan work? Like how easy would it be to adapt to source packages?
<lifeless> ajmitch_: see scrollback for siretarts question
* Kyral wonders if he can adapt uscan to work with a watchfile that isn't in debian/
<sistpoty> Kyral: why would you want to do this? (and there is an option to specify the watch-file iirc)
<Kyral> sistpoty: to maintain something like a LFS system
<sistpoty> ah... happy LFSing ;)
<Kyral> hhee
<Kyral> thanks :D
<Kyral> Any experiance with it?
<sistpoty> no... at least not LFS, though I went to a course "creating a linux distribution" once which had a similar goal (but with use of rpm or dpkg)
<Kyral> ah
<Kyral> I wanna do it at least once
<Kyral> and I have been yearning for the "Good Old Days"
<sistpoty> hehe...
<sistpoty> well debootstrapping was most fun of it (we had to write our own scripts to debootstrap and to create an initial install disk)
<Kyral> Plus I'd love to boot my laptop in class and have someone ask me what Distro I am running and reply "GNU/Linux, plain and simple"
<sistpoty> hehe
<ajmitch_> I'd rather have my laptop boot
<Kyral> Oh it will
<Kyral> besides the laptop isn't my production box
<LaserJock> Kyral: do you have a production box ;-)
<Kyral> LaserJock: Technically the Desktop is
<Kyral> It runs my Webserver, and holds all my packaging and anime stuff
<LaserJock> well, I got rid of mine yesterday :(
<LaserJock> hopefully I will have it up and running tonight
<sistpoty> Toadstool: applying patch 06_dhcpv6-kame-mans-update to ./ ... failed. --> FTBFS :(
<Toadstool> argh
<Kyral> So yah
<Kyral> basically on my LFS box I wanna keep the source archives and use something like uscan to tell me when new versions are out
<Kyral> Though I may just write my own utility...
<Toadstool> sistpoty: i'm working on it, in 2 minutes it's ok :)
<sistpoty> Toadstool: k
<Kyral> Is the Beagle UVF gonna be accepted?
<tseng> dude i just posted it 5 minutes ago
<Kyral> Oh thats you tseng?
* tseng waves
* Kyral reddens
<ajmitch_> Kyral: you're as bad as those forums people
<Kyral> huh?
* Kyral doesn't get ajmitch's meaning
<ajmitch_> that's ok
<Toadstool> sistpoty: it must be ok now
<sistpoty> Toadstool: ok, I'll check
<Toadstool> thanks
<marcin_ant> raphink, ping
<raphink> marcin_ant: wait a min
<raphink> marcin_ant: what is there?
<raphink> marcin_ant: ?
<marcin_ant> hello
<raphink> :)
<marcin_ant> raphink, please take a look at my comment on launchpad page
<raphink> marcin_ant: can you give me the url?
<raphink> please
<marcin_ant> raphink, https://launchpad.net/bounties/vtiger-universe
<marcin_ant> raphink, maybe you could tell something about mysql-server issue
<raphink> wait a bit marcin_ant ok?
<marcin_ant> ok
<raphink> marcin_ant: you have the pb I had
<raphink> we don't want this package to configure mysql
<raphink> marcin_ant: I think your post it pretty right
<raphink> maybe debconf could prompt for the mysql settings to be achieved later
<raphink> but then I don't think we want this package to set mysql really
<raphink> that's dirty
<raphink> in particular, we surely do not want it to prompt the user with the root password for mysql and so on
<marcin_ant> hmmm so then we got a problem
<marcin_ant> 1. if we don't set mysql-server as dependency
<marcin_ant> then we won't be able to just apt-get install vtiger-crm
<raphink> yes
<raphink> since this is an ERP, it is supposed to be installed on a whole network imo
<raphink> not on a single computer
<raphink> but then the idea is that in most cases, the mysql db will be on the same server running vtiger
<ogra> the question is, does vtiger only work with mysql ? or could it also work with postgres, oracle etc ?
<raphink> and users will access vtiger through intranet
<raphink> ogra: I think it only works with mysql
<marcin_ant> 2. but then if we set mysql-server as dependency we will have a problem with remote mysql-servers
<lifeless> if I may suggest
<ogra> make it a recommedns then or even a suggests ... but that wont solve your prob though
<marcin_ant> ogra, currently only with mysql but there are some patches that allow to set up vtiger-crm with postgresql
<lifeless> have a package for the 'server' and one for the 'client'
<lifeless> the client requires mysql-client
<marcin_ant> ogra, but in fact it isn;t big problem since I splitted vtiger-crm package into modules already
<ogra> ah, so you have a vtiger-mysql package ?
<marcin_ant> ogra, and I got vtiger-crm-mysl + vtiger-crm + vtiger-themes, lan packs etc.
<marcin_ant> ogra, yes
<ogra> cool
<lifeless> the server is a dummy package that pulls in the real server bits, and mysql, but you can install just the server bits ifyou have a remote sql server
<marcin_ant> ogra, so I can set up dependency as vtiger-crm-mysql | vtiger-crm-postgresql
<ogra> yup
<lifeless> or in other words, one package name that apt-get install drags in the database engine, and another package name that apt-get install does not drag in the db engine
<marcin_ant> but there is still a problem with mysql defaults
<ogra> you cant assume defaults ...
<marcin_ant> lifeless, so... maybe vtiger-crm-mysql-local + vtiger-crm-mysql-remote?
<ogra> a sane mysql admin will not use root as admin user
<sistpoty> Toadstool: I took a close look to the package now, looks really good!
<sistpoty> Toadstool: however it won't purge :(
<Toadstool> uh ?!
<lifeless> marcin_ant: something like that. I mean, I dont know the software, I'm only trying to sketch the way you break it out
<marcin_ant> lifeless, that could be pretty good idea...
<ogra> lifeless++
<lifeless> one package with the functionality, another with the dependency for 'plug and play'
<ogra> but you will still need name and pass for the DB admin
<sistpoty> Toadstool: you seem to have an error in dhcpv6-kame-relay's postrm
<marcin_ant> ogra, well... yes and not...
<Toadstool> yeah sistpoty i've read you comment on revu
<ogra> marcin_ant, not ?
<Toadstool> i'm on it :)
<sistpoty> :)
<marcin_ant> ogra, I thought about parsing /etc/mysql/debian.cnf
<marcin_ant> ogra, to get default debian-sys-maint account and password
<ogra> hmm
<ogra> is it stored in plaintext ?
<marcin_ant> ogra, then it's enough to set up database for vtiger and create separate user account on mysql server for vtiger user
<marcin_ant> ogra, yes
<ogra> (its some years ago that i had my last mysql to manage)
<Toadstool> ok sistpoty I've found what it is, a non printable utf-8 character bash doesn't like :p
<Toadstool> now it works
<sistpoty> nasty *g*
<sistpoty> cool, upload it! ;)
<Toadstool> sistpoty: done
* sistpoty looks
<sistpoty> (as soon as it's there)
<Toadstool> yep :)
<lifeless> azeem: so, when you gonna upload the modules ?
<marcin_ant> ok so let's think - we could have some 'database related' packages for vtiger
<marcin_ant> for example vtiger-crm-mysql-local and v-c-mysql-remote or postgresql-local etc.
<marcin_ant> and in vtiger-crm-mysql-local we got mysql-server as dependency
<marcin_ant> and config will use default maint account to set up database for vtiger
<marcin_ant> but then how user can choose database backend?
<marcin_ant> john doe will run: apt-get install vtiger-crm... and what then?
<marcin_ant> ogra, what do you think about it?
<Toadstool> sistpoty: when I read the postrm using iso-8859-1 encoding, it shows "if [ -e /etc/default/dhcpv6-kame-relay ] ; then" :)
<ogra> marcin_ant, hmm, tricky ...
<marcin_ant> ogra, another thing is that we already have some packages that use dbconfig-common (and I also would like to use this infrastructure tools)
<marcin_ant> ogra, for example cacti
<marcin_ant> ogra, and it has the same issue
<marcin_ant> ogra, because it recommends mysql-server and only has mysql-client as dependency
<ogra> it doesnt seem like something you can solve fully automatic without breaking it
<ogra> (cacti)
<marcin_ant> ogra, but then even if you got mysql-server installed (but don't have password set manually for root)
<ogra> users will slay you if you break cacti
<marcin_ant> ogra, it will install without problems but won't work
<ogra> yup
<marcin_ant> well I don't want to break anything - just improve
<ogra> i guess the debian policy has something to say about it ...
<marcin_ant> currently user has to install mysql-server first, then mysqladmin -u root password somepassword and then finally you can install cacti
<marcin_ant> ogra, you mean this: http://webapps-common.alioth.debian.org/draft/html/ ?
<marcin_ant> ogra, and specifically this http://webapps-common.alioth.debian.org/draft/html/ch-issues.html#s-issues-database
<ogra> http://people.debian.org/~seanius/policy/dbapp-policy.html/ch-dbapps.html should tell you everything ...
<marcin_ant> ogra, and of course "For packages providing automated assistance, database installation/configuration should be considered as part of the package installation process."
<marcin_ant> ogra, should...
<marcin_ant> ogra, but it's not about our issue
<marcin_ant> ogra, my package _can install database_ already because I use dbcommon-config
<marcin_ant> ogra, but thats not the problem - problem is with _database server_ installation
<marcin_ant> ogra, not database itself
<marcin_ant> ogra, database = set of tables and records
<marcin_ant> ogra, and more - I can also have mysql-server up and running on localhost
<ogra> yup
<marcin_ant> ogra, but if I won't set root password - cacti, mydms and currently vtiger-crm won't create database
<ogra> "It must always be assumed that the local admin knows more than any automated system. "
<ogra> thats the most important snetence imho ...
<marcin_ant> ogra, yes but also "A failure to install a database should be considered a failure to install the package and should result in an error value returned by the relevant maintainer script."
<ogra> which doesnt mean your package install must fail ...
<marcin_ant> ogra, sure but let's think as 'user' now - not as sysadmin
<ogra> (as you can sse with cacti)
<ogra> *see
<marcin_ant> ogra, I'm manager in some company and want to try vtiger-crm, I'm pretty smart so I run: apt-get install vtiger-crm
<marcin_ant> ogra, then it asks me for admin password on mysql server
<ogra> if youre really a manager, you dont know about apt :P
<marcin_ant> ogra, I got no idea... but as I said - I'm pretty smart one
<ajmitch_> assuming that the mysql server is on the same box as you're running vtiger on
<ogra> you have people working for you to advise to install it
<marcin_ant> ogra, so I go to synaptic and install mysql-server
<marcin_ant> ogra, then I try to install vtiger-crm again... unfortunately still no luck
<ogra> vtiger-crm should ask you if the DB server runs locally ...
<ogra> if not it should fall back to ask for the ip
<marcin_ant> ogra, and then I give up or call to some IT support
<ogra> yup
<ogra> but its a DB tool ... nothing smart managers should install ...
<sistpoty> hm... at least foo shouldn't change essential stuff of bar... that would be an issue of bar
<ogra> its pretty hard to get that right ...
<marcin_ant> it's pretty hard because debian and ubuntu lacks conditional dependencies :(
<marcin_ant> ogra, I need decision.....
<ogra> conditional dependencys wont solve it ...
<ogra> you'll always have the problem that you either have the server locally or will attach your frontend to a cluster or remote server ...
<ogra> forcing your tool to resort to local installs will take the ability to install it as a cluster frontend ...
<marcin_ant> ogra, they could... for example: apt-get install vtiger-crm ->debconf question: mysql or postgres -> choice 'mysql'->question local or remote -> choice 'local' then apt should install mysql-server automagically
<ogra> you wont get around debconf questions here
<ogra> thats policy violation ...
<Toadstool> gn8 everybody
<Kyral> Hmmm I know what I have to do tonight
#ubuntu-motu 2007-02-05
<TheMuso> Gah this synth is laggy.
<TheMuso> Hobbsee!
<Hobbsee> hey TheMuso!
<pochu> do you know to which package network-monitor belongs?
<sistpoty> pochu: dpkg -S is your friend ;)
<sistpoty> hi Hobbsee:
<Hobbsee> hey sistpoty :)
<pochu> sistpoty: I have enough friends ;)
<pochu> thanks :)
<sistpoty> np
<pochu> not found :S
<sistpoty> pochu: then you could try apt-file or the search on packages.ubuntu.com
<pochu> sistpoty: going to try, thanks!
<Hobbsee> apt-cache showsrc foo
<Hobbsee> or just apt-cache madison foo
<Nafallo> Hobbsee: if network-monitor would have been it's own package and not been included in gnome-applets or something like that ;-)
<Hobbsee> Nafallo: it'll give you the binary name, and the source
<Hobbsee> aww darn, it doesnt get it...
<Nafallo> Hobbsee: no, it won't :-)
<Hobbsee> it works if you try with kopete, for eg
<Nafallo> Hobbsee: that's because kopete is included in the kopete package :-)
<Hobbsee> no it's not
<Hobbsee> (not anymore)
<Nafallo> Hobbsee: it's not? :-)
<Hobbsee> yep.  i filed the removal request
<Nafallo> Hobbsee: according to my feisty-changes kopete binary package is built from kdenetwork source.
<Nafallo> Hobbsee: so it IS it's own package :-)
<LaserJock> Hobbsee: removal requests only remove the source packages, the binaries stick around
<Nafallo> Hobbsee: nm-applet binary from the package network-manager-gnome doesn't work with apt-get show nm-applet though :-)
<Adri2000> http://librarian.launchpad.net/6204008/buildlog_ubuntu-feisty-powerpc.amsn_0.96%2Bdfsg1-0ubuntu1_FAILEDTOBUILD.txt.gz < any idea about that?
<crimsun> poke pitti about it during work hours
<Adri2000> crimsun: do you think it's a buildd issue?
<crimsun> it may be, I don't have a ppc to try
<sistpoty> well, this looks suspicious: objcopy: Unable to recognise the format of the input file `./usr/share/amsn/utils/Tclxml/libTclxml3.1.so'
<Adri2000> it also failed and sparc and ia64 but built fine on i386 and amd64
<sistpoty> Adri2000: my guess is that the shared object which causes the build to fail is i386... (maybe not getting built but taken from somewhere?)
<Adri2000> amsn-0.96+dfsg1/utils/Tclxml/libTclxml3.1.so < yes, it's already in the tarball and is probably not built
<sistpoty> Adri2000: hm... and it's not there on amd64 at all
<sistpoty> oops, looking at an older version
<Adri2000> utils/Tclxml/ doesn't exist in 0.95
<sistpoty> Adri2000: if you look at clean in rules, there are some shared objects getting removed. maybe adding this one as well is all that's needed to fix building.:wq
<sistpoty> -:wp ;)
<Adri2000> yep
<Adri2000> they are only removed from the source directory, rm -f ./utils/TkCximage/TkCximage.so
<Adri2000> some are moved from /usr/share/ to /usr/lib/
<Adri2000> I'm not sure why the .so is shipped in the tarball
* sistpoty is neither
<ajmitch> because upstream are idiots?
* ajmitch is just particularly bitter & cynical today
<sistpoty> lol... what's wrong today? /me is in a bad mood today as well
* Nafallo joins ajmitch and siretart 
<Nafallo> dooh
<ajmitch> sistpoty: we've just been having fun with code at work
<Nafallo> s/siretart/sistpoty/
<Adri2000> sistpoty: do you think that if I remove the .so file during the clean rule, it will be recreated for each arch and then it will work?
<sistpoty> Adri2000: just try and see if it's there... if not, it's probably not redistributable (since sources are missing) or the build system is broken
<sistpoty> s/not redistributable/not redistributable in universe/
<Adri2000> sistpoty: no, it's not recreated :(
<sistpoty> Adri2000: I've done some searching... seems like the shared object is taken from http://tclxml.sourceforge.net/tclxml.html
<sistpoty> Adri2000: which might be in the package tclxml
<sistpoty> Adri2000: so you could simply add a link to usr/lib/Tclxml3.1/libTclxml3.1.so and a hard dependency on it
<sistpoty> (so that would be a little bit hacky, but I wouldn't know how to determine tcl dependencies to a library right now)
<ajmitch> a little bit hacky?
<sistpoty> ajmitch: got a clue how to find out shared library dependencies of tcl-scripts?
<Burgundavia> pochu: ping re: https://launchpad.net/ubuntu/+source/compiz/+bug/75409
<Ubugtu> Malone bug 75409 in compiz "Missing dependency" [Undecided,In progress]  
<pochu> Burgundavia: desktop-effects depends on compiz. compiz depends on compiz-core. compiz-core suggest compiz-gnome or compiz-kde
<pochu> Burgundavia: the fix: compiz-core depends on "compiz-gnome | compiz-kde"
<pochu> right?
<Burgundavia> pochu: I think so. It wasn't clear exactly what you were doing with that bug
<ajmitch> sistpoty: I don't touch tcl
<sistpoty> hehe
<Burgundavia> I also don't want to step on your toes with compiz
<Nafallo> isn't desktop-effects gnome-specific? :-)
<Burgundavia> Nafallo: desktop-effects is written in pygtk, yes
<Nafallo> maybe it's better to make that depends on compiz-gnome or something? :-)
<Burgundavia> ajmitch: I just realized why Userful installs amsn by default: because it is written in tcl and we love tcl for some cracked reason
<ajmitch> makes perfect sense
<Burgundavia> just like hitting your head against a wall makes perfect sense
<Burgundavia> have i mentioned we have a developer being paid full time to redevelop LTSP?
<ajmitch> makes perfect sense (again)
<crimsun> is said developer also using beryl?
<Adri2000> sistpoty: is it really needed to do all that? if I just remove the .so file, it works...
<Burgundavia> crimsun: that would be really crack
<ajmitch> Burgundavia: are you not sad that beryl won't be shipped in feisty by default?
<Burgundavia> ajmitch: not really
<ajmitch> even compiz is broken enough
<Burgundavia> compiz needs more aggressive testing
<crimsun> I'd sad as a moocow :/
<crimsun> I'm, even
<Burgundavia> they should have turned it on by default as the beginning fo the cycle and let the bug reports flow in
<Nafallo> ajmitch: oh!? it isn't? :-)
<ajmitch> compiz lasts about 30 seconds on my laptop before I get sick of the bugs & turn it off
<crimsun> 30? that's impressive
<sistpoty> Adri2000: well, the shared object is referenced in usr/share/amsn/utils/Tclxml/pkgIndex.tcl... so figuring out if the file says it's needed or rather one of an alternative might give more clues
<ajmitch> at most
<TheMuso> Is there a beryl howto on the wiki?
<crimsun> it makes my desktop immediately unusable after logging in
* TheMuso looks
* imbrandon groans at the bling convo again
<imbrandon> i hoped that died
<crimsun> TheMuso: yeah, beryl-project, or #ubuntu-effects
<ajmitch> imbrandon: we'll stop soon
<Burgundavia> TheMuso: there is a one word wiki: don't
<sistpoty> Adri2000: but I guess if amsn works fine w.o., you could remove it... but please watch out if bugs get reported then ;)
<Burgundavia> apparently it is now in debian, beryl that is
<Burgundavia> anyway, have to run
<ajmitch> imbrandon: I thought you were stocking up on your addictions?
* imbrandon is , bbiab
<ajmitch> heh
<Adri2000> sistpoty: ok
* ajmitch gets bored & resyncs the bug list
<sistpoty> crimsun, StevenK, siretart: can you give me an ack for SRU https://launchpad.net/ubuntu/+source/xmms-sid/+bug/82692 ?
<Ubugtu> Malone bug 82692 in xmms-sid "[SRU]  xmms-sid broken in edgy" [Undecided,Needs info]  
<sistpoty> (and please look at the version number, it looks kinda wrong to me, but maybe I'm just tired)
<ajmitch> hm
* ajmitch should join the superpowers that reside in motu-swat
<ajmitch> & update a couple of apps I use
<crimsun> sistpoty: acked.
<sistpoty> ajmitch: we need every help we can get ;)
<sistpoty> crimsun: thx
<ajmitch> sistpoty: yeah, zope2.9 has some issues, i think they may be SRU rather than security though
<ajmitch> I have to check them further
<sistpoty> ajmitch: thanks to keescook, -security is moving pretty fast ;)
<ajmitch> bug 80317
<Ubugtu> Malone bug 80317 in zope2.9 "Critical bug in Zope 2.9.5 (Edgy)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80317
* ajmitch waits for lp
* ajmitch thinks it's just crasher bug, not security
<ajmitch> oh well, i can bug you about it for SRU anyway :)
<sistpoty> ajmitch: patch looks sane for SRU ;)
<ajmitch> hah
<ajmitch> I don't think the attached patch was the appropriate fix
<ajmitch> hm no, according to the changelog it was
<sistpoty> well, I can't tell if it was the right fix w.o. looking at logger... but it's sane as in small and unintrusive ;)
<ajmitch> yep
<ajmitch> their bug tracker is just confusing
<ajmitch> & it doesn't help that people were arguing about the fix in another bug
<sistpoty> hehe
<sistpoty> I wonder, if I ever get enough testers for the xmms-sid sru... strange enough I happen to have a large sid collection, but who else does?
<ajmitch> yeah, it could be a problem trying to get testers for universe stuff
<sistpoty> indeed... and not just for such uncommon packages... maybe asking around in #ubuntu or sending to #ubuntu-users ml might get us some feedback
<ajmitch> or (shudder) the forums
<sistpoty> hehe
<pochu> hey guys: if I've just changed 2 lines in /debian/control, is normally to have a 115KB of diff.gz?
<pochu> (1.4 MB of diff inside the gz)
<pochu> I can't understand it :(
<azeem> well, check what files the diff touches
<azeem> could be autotools are run in the clean target
<sistpoty> pochu: the .diff.gz is always the difference between the orig.tar.gz and the extracted source package... so if it was large before your change it will stay large after the 2-line change
<pochu> sistpoty: ok, thanks!
<pochu> :)
<azeem> eh, that as well
<sistpoty> pochu: if you want a diff between packages, use debdiff <old-dsc-file> <new-dsc-file>
<pochu> sistpoty: I think I don't need a diff :) but thanks anyway
<pochu> could you guys sponsor an upload :) bug 75409
<Ubugtu> Malone bug 75409 in compiz "Missing dependency" [Undecided,In progress]  https://launchpad.net/bugs/75409
<geser> the debdiff would be enough
<sistpoty> pochu: ^^ :P
<pochu> do you want the debdiff?
<geser> and even preferable
<pochu> I think sebastien told me that the .dsc and the .diff.gz were enough :)
<pochu> but np :)
<pochu> one minute ;)
<pochu> done :)
<pochu> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/75409
<Ubugtu> Malone bug 75409 in compiz "Missing dependency" [Undecided,In progress]  
<TheMuso> bah. Any idea why OpenOffice is not letting me edit a document straight away? If i use the arrow keyso to move up and down, the document scrolls like a web page.
<TheMuso> Any ideas how I change this?
<TheMuso> This is a pretty much fresh install of feisty.
<TheMuso> i.e about two days old.
<pochu> need a sponsor :) any volunteer? :)
<Nafallo> compiz is like crack. I don't even wanna try it :-)
<pochu> :)
<pochu> Nafallo: do you need to test each package you are going to upload, even if they have already been tested?
<Nafallo> yes
<Nafallo> and my development system is dead atm ;-)
<pochu> :)
<pochu> any other MOTU ^_^
<TheMuso> pochu: Try me again in a week or so. :)
<pochu> hehe
<Nafallo> s/MOTU/crack\ smoker/ :-)
<TheMuso> Still getting comfrotable with trusting my own work that goes up.
<TheMuso> Nafallo: ROFL
<pochu> I can't understand why you play so much with / :S
<pochu> s/blabla/dkjf
<pochu> :)
<TheMuso> Because when one gets used to using sed, it becomes a habbit. :)
<pochu> have you seen bug 83348?
<Ubugtu> Malone bug 83348 in gnome-app-install "Need more applications" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83348
<pochu> it's pretty annoying :)
<ajmitch> yes, it's humourous
<pochu> :)
<Nafallo> lol
<sistpoty> let's assign it to sabdfl *g*
<pochu> :)
<pochu> we can change the bug number to bug 2 :)
* Nafallo laughs out load
<Nafallo> s/oa/ou/
<sistpoty> ok, reassigned :)
<Nafallo> lol
<sistpoty> even more info added :)
<pochu> :)
<pochu> sistpoty: could we also have windows in the gnome-app-shop ;)
<sistpoty> hrhr
<sistpoty> pochu: sure: http://www.degredo.net/
<ajmitch> heh
<pochu> :)
<ajmitch> sistpoty: naughty sistpoty, giving sabdfl more work to do
<sistpoty> yay, /me is a little bit naughty tonight *g*
<pochu> sistpoty: even better: http://theblog.europe2blog.fr/the_blog/images/vista.jpg
<sistpoty> *g*
<sistpoty> pochu: what do I need to do to get cool effects for kde with compiz?
<pochu> sistpoty: upload my package :)
<pochu> sistpoty: install compiz?
<pochu> :-P
<sistpoty> pochu: I want to test it before uploading (builds fine)
<pochu> sistpoty: moment
<crimsun> you also need steel ribs in case your monitor explodes from all the BLING.
<sistpoty> argl *g*
<pochu> I think "compiz --replace"
<pochu> sistpoty: try that :)
<sistpoty> well, s.th. changed... but no cool effect yet *g*
<sistpoty> oh, and I can't change workspaces any longer *g*
<Nafallo> siretart: cracksmoker!
<sistpoty> -ENOCRACK
<crimsun> (you didn't need workspaces anyhow!)
<Nafallo> dooh
<Nafallo> siretart: that was for sistpoty :-)
<sistpoty> oh, and the decorations are gone
<pochu> sistpoty: those are known issues :)
<pochu> sistpoty: remove ~/.gconf/apps/compiz
<pochu> and restart compiz
<pochu> you will have decorations
<pochu> sistpoty: or enable them in the gconf keys
<pochu> but it's easy to remove the directory ;)
<pochu> there are a lot of bugs with compiz :(
<pochu> and I think most of them are gconf-related :)
<pochu> lol
<pochu> he has crashed :)
<sistpoty> grml... restart compiz was a bad idea *g*
<pochu> :)
<Nafallo> siretart: I told you it was crack :-)
<Nafallo> but FFS!
<pochu> sistpoty: did you read me?
<Nafallo> s/ siretart / sistpoty /
<sistpoty> pochu: yep...
<sistpoty> (kvirc's highlight popup still worked, but nothing else)
<pochu> sistpoty: I haven't tested it with kubuntu :(
<sistpoty> pochu: I don't have ~/.gconf/apps/compiz
<pochu> lol
<pochu> oh
<pochu> you are using kde :)
<pochu> gconf is gnome, right?
<sistpoty> yep
<pochu> where does kde save that?
<sistpoty> but I have .gconf still *g*
<pochu> hehe
<pochu> :(
<sistpoty> no idea? where would compiz-kde put it?
<pochu> I've never used kde
<sistpoty> kde saves stuff in .kde
<pochu> gnome rocks :)
<pochu> sistpoty: then look there ;)
<sistpoty> no... in my entire home dir is nothing that's called compiz
<pochu> lol
<pochu> sistpoty: and running compiz crashes your wm?
<TheMuso> FOund my problem.
<TheMuso> For some reason, accessing it over an nfs share makes it behave differently.
<sistpoty> pochu: it doesn't really crash it... stopping compiz crashes it (or makes it pretty useless)
<pochu> stopping compiz?
<pochu> oh!
<pochu> you should stop it with
<pochu> something --replace
<pochu> in gnome it's gtksomething :)
<pochu> one moment ;)
<sistpoty> lol, just like windows... push start to stop windows *g*
<pochu> :)
<sistpoty> ok, I give up on compiz... nothing usable in /usr/share/doc/compiz{-kde}, no man page...
<sistpoty> however it builds and installs fine, so I guess I'll just upload it
<pochu> sistpoty: I think for gnome is this: gtk-window-decorator --replace
<pochu> but don't know for kde... :(
<pochu> could I talk to you guys something offtopic? :)
<pochu> or not here?
<sistpoty> pochu: back to compiz: you shouldn't make changelog entries wider than 80 chars
<pochu> oh, didn't know
<pochu> thanks!
<pochu> sistpoty: could you fix it?
<sistpoty> pochu: sure
<pochu> :)
<pochu> thanks!
<pochu> sistpoty: I shouldn't or I can't?
<ajmitch> shouldn't
<ajmitch> you'll have angry developers calling your house in the middle of the night
<pochu> :)
<sistpoty> ok, now I'm off to bed
<sistpoty> gn8 everyone
<ajmitch> night sistpoty 
<LaserJock> darn, I missed sistopty
<pochu> buy guys!
<pochu> see you :)
<bddebian> Heya
<LaserJock> woot! Colts kicked butt :-)
<bddebian> :'-(
<bddebian> LaserJock: I almost have a present for you :-)
<LaserJock> exciting
<LaserJock> I somehow feel bad about the Bears losing
<bddebian> They deserved though after that fiasco :-(
<TheMuso> Bah! Thats not football!!
<LaserJock> of course it is ;-)
<TheMuso> The only game that can be called football is the world game!
<TheMuso> Known here as soccer.
<LaserJock> heh
<bddebian> Oh, you mean SOCCER? :)
<LaserJock> America==World ;-)
<TheMuso> Ummm. I think not.
<LaserJock> darn
<ajmitch> TheMuso: don't shatter their little illusions
<TheMuso> ajmitch: hahaha
<LaserJock> heh
<LaserJock> no illusions, I just think it was dumb to have 2 different sports named the same
<LaserJock> football seems to fit soccer better
<LaserJock> you mostly throw the ball in our football
<bddebian> traitor
<LaserJock> sorry bddebian 
<LaserJock> it just seems more logical
<LaserJock> but I don't know what we'd call football
<LaserJock> "the game formerly known as football"
<bddebian> oblongball
<zul> ill merge xen-tools tomorrow..
<LaserJock> you guys know of any issues with terminals just becoming unresponsive?
<TheMuso> Nope.
<crimsun> "terminals" being...?
<LaserJock> gnome-terminal or konsole
<crimsun> sure, I have [out of my own stupidity] 
<LaserJock> when I ssh places sometimes it just freezes
<LaserJock> crimsun: what was your stupidity? perhaps I'm being stupid and don't even know it ;-)
<crimsun> ^s
<LaserJock> hmm, I have done that before
<LaserJock> but I don't know think that has been the issue lately
<ScottK> The only time I've had terminals freeze is if I reboot a remote server via SSH and don't manage to log out before it goes down.  I've had the get VERY slow when trying to SSH through a high latency/packet loss connection.
<LaserJock> hmm, well that's odd
<Burgundavia> LaserJock: freezing is often a hardware issue
<LaserJock> Burgundavia: but it's only the terminal and I can open up a  new tab and it's fine
<TheMuso> c
<zakame> afternoon MOTUs
<LaserJock> hi zakame 
<zakame> hi LaserJock, merging wxwindows2.4 now :)
<TheMuso> Hey zakame 
<zakame> yo TheMuso :D
<joejaxx> well that was interesting
<LaserJock> joejaxx: hi
<joejaxx> LaserJock: hello
<joejaxx> LaserJock: how are you today?
<LaserJock> oh, I'm doing
<joejaxx> that is good
<LaserJock> somehow I need like a 1 month vacation
<joejaxx> yeah i feel that way sometimes as well
<ajmitch> only 1 month?
<joejaxx> ajmitch: :P
<LaserJock> ajmitch: I'd get bored after too long
<LaserJock> wow, interesting comments in -devel
<TheMuso> ooooo threatening.
* ajmitch fears for his life
<ajmitch> from such a *tough* nick, too
<TheMuso> haha
<TheMuso> and he was k-lined too.
* TheMuso doesn't know what k-lined means. :)
<TheMuso> Something to do with kicked I *think*.
<ajmitch> "ill get my uncle after you" is such a show of strength ;)
<tepsipakki> yep.. there are times when I'm proud of being Finnish :P
<ajmitch> heh
<joejaxx> lol
<TheMuso> haha
<joejaxx> wow haha
<joejaxx> i maxed on 1.25GB of ram
<ajmitch> using up 1.25GB of RAM is quite easy
<joejaxx> yeah but that is all the ram i have :P
<joejaxx> mostly everything is swapping now
* ajmitch runs without swap
<joejaxx> :P
<joejaxx> how much ram do you have total?
<ajmitch> in the desktop? 4GB
<TheMuso> wow
<joejaxx> nice
<ajmitch> laptop runs with 1GB RAM, 1GB swap
<joejaxx> too bad this laptop does not take 4gb
<ajmitch> yeah, mine will only take 2GB
<zakame> cool
<ajmitch> but I haven't needed to upgrade it
<crimsun> sweet.
<crimsun> crimsun@garnish:/media/disk/crimsun/git/ubuntu-2.6$ git branch -D hda-fixes
<crimsun> Deleted branch hda-fixes.
<Fujitsu> ... sweet?
<Fujitsu> How is it a good thing that you deleted that?
<Fujitsu> Is it all merged?
<crimsun> yep.
<Fujitsu> Yay :)
<Fujitsu> Very good!
<Fujitsu> crimsun saves the world (of sound) yet again.
<crimsun> well, I still have a few thousand lines for Realtek HDA, but I'm not terribly worried
<cbx33> is the fact that oodraw not having any desktop icon fixed in feisty?
<cbx33> and oo math
<Adri2000> hi \sh 
<Adri2000> \sh: you always forget the "s" when you change the Maintainer field, it's Ubuntu MOTU DeveloperS
<Adri2000> \sh: and authbind is in main
<\sh> Adri2000: arg...
<\sh> looks like that my train travel fcked up my brain ;)
<StevenK> Adri2000: \sh is trying to deny the existance of the rest of us. :-P
<Adri2000> :p
<StevenK> "What? I'm the only MOTU!" etc etc
<\sh> StevenK: lol
<\sh> Adri2000: changin my mistake
<\sh> fix uploaded authbind ;)
<Adri2000> :)
<\sh> StevenK: The "s" from DeveloperS is not on my way of my fingers sometimes ;) I'll take more attention next time ;)
<StevenK> Heh
<\sh> time for a cigarette
<Tonio_> hi, I uploaded kdepim on friday afternoon, upload is still in the queue, is there a reason for this ?
<Tonio_> sorry wrong channel....
<Adri2000> btw, are we sure *how* we should change the maintainer field or still not?
<TheMuso> Adri2000: IMO it makes sense. I am not changing all packages I upload however, as there are packages that I myself am happy to maintain, as I know how they work, are packaged, and am in contact with upstream for them.
<Adri2000> TheMuso: you mean the 0ubuntuX packages (not in debian) you packaged and maintain in ubuntu?
<TheMuso> Adri2000: No, not only those. There are packages that are in Debian that I am happy to maintain in universe, as I'm contact with the debian maintainer and upstream anyway.
* TheMuso notes that this is mainly accessibility stuff.
<Adri2000> ok
<StevenK> geser: GAH! *Don't* run scons in the clean target!
* StevenK belts geser.
<geser> StevenK: it's already in the Debian package
<StevenK> Then file a nastygram, it's wrong.
<StevenK> Just because the Debian package does something dumb doesn't mean we have to.
<geser> what to call instead?
* elkbuntu hands StevenK the Baseball Bat of Upstream LARTing
<StevenK> I hope upstream didn't write debian/rules
<StevenK> geser: Why do you need to call scons anyway?
<geser> it looks like xmms2 is using scons instead make
<StevenK> I figured that, but why does it need to call it in the clean target?
<geser> shouldn't be something like "make clean" be called in the clean target?
<StevenK> Yes, but only if you can do so without invoking something like ./configure
<StevenK> Where's Fujitsu when you want him? He can quote about this stuff.
<geser> don't ask me why scons does a configure before it removes files
<StevenK> Probably because it hasn't been run before.
<geser> but how does this explains why scons can't find a c compiler?
<StevenK> It doesn't, but I thought I'd try. Which I can't reproduce.
<Nafallo> -ENOFUJITSU
<highvoltage> 5675445
<Nafallo> ehrm
<fernando> hi all, how to use dbootstrap with a proxy auth?
<bddebian> Heya gang
<isaric> A hope for http://revu.tauware.de/details.py?upid=4238 is possible ?
<bddebian> I'll try to get to it in a little bit
<nixternal> boo
<isaric> thanks
<bddebian> Heya nixternal
<nixternal> well howdy
<gnomefreak> whats with the 3 updates for l-r-m and nvidia-glx? im getting kind of scared to restart X seeing all them
<bddebian> If I repack the upstream tarball, am I supposed to give it some version identifying so? i.e. foo_1.0+REPACKED-0ubuntu1 or some such?
<gimmiedacash> how do I get privoxy from feisty in edgy? the privoxy version in edgy is several years old
<bddebian> Do I just need to chmod +x on the following lintian warning?:
<bddebian> W: bibus: script-not-executable ./usr/share/bibus/CodecChoice.py
<slomo> bddebian: or remove the #! from the file
<slomo> bddebian: depending on whether it is meant to be executed directly or is only imported somewhere else
<bddebian> slomo: Thx
<somerville32> I'm doing an SRU and the current package version is 6.05.5. Should I make it 6.05.6 or 6.05.5.1 ?
<geser> somerville32: no debian revision?
<somerville32> I think this is what we would call a native package
<somerville32> It is xubuntu-docs
<giskard> imbrandon, ping
<geser> somerville32: 6.05.5ubuntu0.1
<geser> that's a native package
<geser> but on the other hand it's an ubuntu-only package, hmm
<geser> I guess 6.05.5.1 would be also ok
<somerville32> Ok :)
<geser> somerville32: you might want to ask pitti or cjwatson
<rexbron> hey, after a package has been accepted and built, how long until it is in the repos
<rexbron> ?
<geser> for already known packages till the next publisher run which is iirc once an hour
<geser> new binary packages need to go through archive admins
<rexbron> ok
<bddebian> Laser_away: If you get a minute:  http://revu.tauware.de/details.py?upid=4256
<geser> bddebian: shouldn't be the version 1.3.0-0ubuntu1 instead of 1.3.0-1ubuntu1?
<bddebian> Gah, yes
<geser> bddebian: looks like if it's enough if bibus build-depends on python-all (without the -dev)
<LaserJock> bddebian: still around?
<DktrKranz> hi guys
<DktrKranz> a user suffers from bug 83457
<Ubugtu> Malone bug 83457 in python2.5 "python2.5-minimal_2.5ubutnu5 fails to install in Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83457
<DktrKranz> it seems latest update of python2.5 breaks something
<ScottK> DktrKranz: You might ask in #ubuntu+1 as that channel is focuse on Feisty.  Python is not a Universe package, so this probably isn't the best place to be asking.
<DktrKranz> thanks ScottK ;)
<_Enchained> Hi
<_Enchained> if I make a package with newer version than the one on revu, what should we do ? archive the older and uplaod the newer ?
<LaserJock> did you upload the original one?
<Adri2000> _Enchained: just upload, nothing else to do
<_Enchained> it's a new release
<_Enchained> v1.2 to 1.2
<LaserJock> Adri2000: if the original was uploaded by somebody else he should talk to them first
<LaserJock> _Enchained: but did you upload 1.2?
<_Enchained> no
<_Enchained> 1.1 to 1.2 sorry
<_Enchained> I've maked the 1.1 version
<_Enchained> and now it's 1.2
<LaserJock> ok, then maybe email the person that uploaded 1.1 to see if they were working on it
<_Enchained> it's me ;)
<_Enchained> As I won't work on 1.1 again, it could be deleted no ?
<LaserJock> _Enchained: argg, I asked you before if you were the one who uploaded it and you said no
<_Enchained> ^^ I said no for "did you upload 1.2" ;)
<LaserJock> and you told me 1.2 was the old version ;-)
<LaserJock> just upload the new version
<_Enchained> I restart :
<giskard> imbrandon, ping
<_Enchained> I've uploaded 1.1 version on revu
<_Enchained> the package was rejected
<_Enchained> After talking to upstream to solve problems
<_Enchained> He has released a new version 1.2
<_Enchained> with corrections
<_Enchained> etc
<Adri2000> (was rejected from the NEW queue)
<_Enchained> yes Adri2000
<_Enchained> so there is no version of this software actually
<_Enchained> I just upload the new version ?
<Adri2000> yep :)
<LaserJock> yes, you can upload right over the old package
<LaserJock> I just wanted to make sure you weren't  hijacking somebody else's package without them knowing about it(which happens sometimes)
<crimsun> just make sure you hijack all of the scientific packages
<LaserJock> :-)
<_Enchained> in fact someone already maked an "unofficial" package for edgy
<_Enchained> but I think it doesn't matter
<LaserJock> too bad they didn't put it on REVU
<TheMuso> Hey MOTUs.
<LaserJock> hi TheMuso 
<LaserJock> gonna upload something today? :-)
<TheMuso> probably, once I sort out the stability of one of my boxes.
<TheMuso> I THink maybe something is on the way out in it.
<stgraber> Anyone knows how I'm supposed to package a java software ?
<somerville32> stgraber, You could look at an example.
<LaserJock> like beyond just any old package?
<zachtib> hi, i emailed the mailing list about getting a package synced, and i followed the directions, but I'm having some trouble
<LaserJock> what's the trouble?
<zachtib> https://launchpad.net/ubuntu/+bug/83462 << that's the bug i filed, but someone said "you need a developer to ACK your sync first" and i don't know what they mean
<Ubugtu> Malone bug 83462 in Ubuntu "Sync Deluge 0.4.1 into Feisty" [Undecided,Needs info]  
<LaserJock> zachtib: ah, that just means you need to get a MOTU (Ubuntu Universe Developer) to OK the sync
<LaserJock> it's just so we can weed out bad requests before they go to the archive admins
<zachtib> ok, makes sense.  its a very minor change, i only put out 0.4.1 so that it would make it into feisty.  basically, just a clean source tarball and better menu entries,
<LaserJock> k, I'll have a look and approve ACK it ok?
<zachtib> ok, thanks
<LaserJock> zachtib: in the future you don't want to subscribe the ubuntu-archive right away, but subscribe ubuntu-universe-sponsors
<LaserJock> sorry for the confusion there
<zachtib> LaserJock: ok, i was just going by the wiki page
<LaserJock> yeah, I know
<LaserJock> it's written from the perspective of a dev filing the sync request
<LaserJock> so it should be clearer on what to do for non-devs
<zachtib> gotcha
<ScottK> LaserJock: If I edit the page, will you review it to make sure I got it right?
<LaserJock> ScottK: the sync page?
<ScottK> Yeah
<Adri2000> zachtib: also I forgot to say that you need to assign the bug to the package deluge-torrent ;)
<ScottK> To make it clearer for non-devs.
<Adri2000> good idea schultmc 
* ScottK was the one that pointed him at that page.
<Adri2000> good idea ScottK 
<zachtib> Adri2000: yeah, i forgot how to assign a package after i submitted it.  i realized that about 2 sec after i sent it
<Adri2000> (sorry schultmc)
<schultmc> heh
<schultmc> np
<LaserJock> ScottK: sure
<ScottK> OK
<ScottK> If you want a main package synched and are not a dev, who do you subscribe to the bug?
<LaserJock> I *think* ubuntu-sponsors
<Adri2000> ubuntu-main-sponsors
<ScottK> Thanks.
<crimsun> ugg, more spam.
<LaserJock> Adri2000: ah yeah, that's the one
<LaserJock> crimsun: better then getting yelled at by ubuntu-archive
<LaserJock> I think :-)
<ScottK> LaserJock: Updated https://wiki.ubuntu.com/SyncRequestProcess - I have to run and pick up #2 daughter from school, but if needed will fix anything when I get back (~30 min).
<LaserJock> k, thanks
<LaserJock> ScottK: looks ok to me, mdz can spiff it up if he likes
<bddebian> OK, what have I missed? :-)
<LaserJock> nothing
<bddebian> Where do NEW binaries sit after they build successfuly?
<LaserJock> nothing can happen when you are gone
<bddebian> LaserJock: Did you check out REVU? :)
<LaserJock> bddebian: not quite yet, just a brief glance
<Adri2000> ScottK: Fix released is set by the archive admin. once you have filed the sync request (and once u-u-s have acked it, if you are not a developer), you don't need to do anything else
<bddebian> But you saw what it was?
<LaserJock> they go to the NEW queue again for approval
<LaserJock> bddebian: yes, I did, thank you very much
<bddebian> LaserJock: It's hideous packaging but it does seem to work
<bddebian> do be do be doo
<bddebian> Do we have any wiki page on using the merge script?
<ScottK> Adri2000: Are you sure.  So far on the one's I've done the archive admins have just set Fix Committed.  IIRC, I was told (here or via e-mail by an archive admin, not sure) that I was supposed to mark it released after it built.
<Adri2000> ScottK: really? bug number of this sync request?
* ScottK will look...
<LaserJock> ScottK: we often do that for MOTU sponsorships, I'm not sure what ubuntu-archive does
<LaserJock> I think pitti marks them Fix Released
<ScottK> OK.
<ScottK> Maybe I should change it to "if the archive marks if fix committed, then you should..."
<_Enchained> hay bddebian
<_Enchained> (do you want some work ? :p)
<ScottK> Adri2000 and LaserJock - https://wiki.ubuntu.com/SyncRequestProcess - better?
<bddebian> Heya _Enchained
<_Enchained> bddebian: when you can, take a look at http://revu.tauware.de/details.py?upid=4229 :)
<_Enchained> plz
<LaserJock> ScottK: seems ok to me
<ScottK> Thanks.
<LaserJock> zachtib: I've given the OK for your sync request, now you can just wait for the archive admins to do their magic :-)
<zachtib> LaserJock: tyvm
<ScottK> zachtib: Would you please look at https://wiki.ubuntu.com/SyncRequestProcess - I've revised it - and see if it makes sense to you...
* bluefox_ idly files bugs requesting BoS2 and Stratagus 2.2.2 in Universe by Feisty, because they're out and he's been waiting for them.
<LaserJock> zachtib: np, thanks for getting ahold of us and filing the bug
<zachtib> ScottK: yeah, looks good
<ScottK> Thanks.
<sistpoty> hi folks
<_Enchained> LaserJock: the new versionis on revu if you want to look at : http://revu.tauware.de/details.py?upid=4258
<_Enchained> version*
<LaserJock> hi sistpoty 
<sistpoty> hi LaserJock
<bddebian> Heya sistpoty
<sistpoty> hi bddebian
<bddebian> _Enchained: The .deb is pretty much empty..??
<_Enchained> bddebian: Oo I look at it
<_Enchained> working on dvd95 ATM
<Adri2000> LaserJock: archive admins won't be happy with #83462 because the changelog is missing
<LaserJock> bah
<ajmitch> hi all
<sistpoty> hi ajmitch
<_Enchained> hi ajmitch
<somerville32> hi ajmitch 
<ScottK> bddebian: Did you get a chance to look at Bug #83176?  It's you favorite package all over again...
<Ubugtu> Malone bug 83176 in courier "courier: merge new debian version 0.53.3-4" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83176
<LaserJock> Adri2000: fine, added
<LaserJock> hi ajmitch 
<bddebian> ScottK: No, I'm hiding
<ScottK> Should be the same as the last one.  The new update just adds a few translations.
<TheMuso> Hey all.
<geser> LaserJock: could you add bug 36586 to your list of malone bugs? it would make it easier for ubuntu-universe-sponsors to find out which source package that bug/mail belongs to
<Ubugtu> Malone bug 36586 in malone "please mention the source package in bug mails" [Medium,Confirmed]  https://launchpad.net/bugs/36586
<TheMuso> ...again
<sistpoty> hi TheMuso
<ajmitch> geser: about the best we have the is source package in the mail headers
<TheMuso> Anybody working on mini-dinstall?
<TheMuso> or is that a fakesync etc?
<LaserJock> geser: I thought I had that one already, looks like I didn't
<LaserJock> geser: as ajmitch said, they seem to think having it in the header is "good enough"
<geser> TheMuso: from http://merges.ubuntu.com/m/mini-dinstall/mini-dinstall_0.6.21ubuntu2.patch I'd say it's a fakesync
<LaserJock> it still bugs me though...
<sistpoty> LaserJock: bugs me as well
<LaserJock> it's kinda weird to have to turn on "all headers" or something just to figure out what package a bug belongs too
<LaserJock> especially when pitti renames the bugs to "Fixed" or something
<bddebian> Heya ajmitch
<TheMuso> geser: Right I thought so.
<bddebian> Gaaah freakin' kbd-chooser
<sistpoty> yay... I want to know the source package as the first thing of a bug mail... it's easier to open the bug link than to browse through the headers to get this info.
<sistpoty> bddebian: seems like noone wants to touch it *g*
<bddebian> sistpoty: I'm trying but it's hideous :-(
<geser> in most cases I'm to lazy look for the X-Launchpad header and prefer to open the url instead
<LaserJock> geser: added, thanks
<bddebian> I actually asked for a syn early on ;-)
<bddebian> Err sync even
<sistpoty> bddebian: cool, great :)
<bddebian> And cjwatsin said no freakin way
<TheMuso> bddebian: hahaha
<geser> bddebian: I think nobody wants to touch it because it in the d-i section
<_Enchained> Adri2000: http://revu.tauware.de/details.py?upid=4259
<sistpoty> is it still used anywhere?
<_Enchained> bddebian: I found the problem on greycstoration : I've changed the binary package name to "gimp-greycstoration" in debian/control (like gpocentek said), and then the deb doesn't content any file...
<_Enchained> do you know why ?...
* sistpoty works on boa-constructor
<_Enchained> sorry, I just found my error (in rules)
<_Enchained> :)
<bddebian> _Enchained: ... :-)
<_Enchained> (I hadn't changed the destination directory in rules...)
<_Enchained> :s
<_Enchained> bddebian: better :) http://revu.tauware.de/details.py?upid=4260
<_Enchained> (and dvd95 is updated too ;) )
<_Enchained> bddebian: thanks for you review
<bddebian> NP
<_Enchained> there is also Ooodi2 if you want lol
<_Enchained> http://revu.tauware.de/details.py?upid=4142
<_Enchained> I d'ont know if all is ok...
<_Enchained> I modified a bit the standard installation
<bddebian> Later folks
#ubuntu-motu 2007-02-06
* TheMuso finds himself having too much fun with beryl.
<zul> hola
<Nafallo> zul: hejsan :-)
<somerville32> moo
<ajmitch> hi
<_Enchained> good night all
<_Enchained> dvd95 updated (again)
<jdong> GRR what do you kill/restart to effect pam changes?
<jdong> i.e. the login prompts....
<jdong> init something.... right?
<rmjb> Hey guys
* Hobbsee waves
<Nafallo> hi Hobbsee :-)
* rmjb waves back
<rmjb> so I have a question on java for feisty
<LaserJock> hi
<Hobbsee> :)
<rmjb> is java 5 or java 6 the preferred java for feisty?
<rmjb> which one should I list first in my package's dependencies?
<Lathiat> theres a java 6 now?
<somerville32> Lathiat, For a long time
<rmjb> in feisty apparently
<LaserJock> I don't know that we a "default" version
<rmjb> well... not default, but if the majority of java apps are switching to 6 I don't want mine to stick on 5
<LaserJock> I don't think it's that coordinated
<LaserJock> but I do think there is somewhat of a Java team so you could ask one of them
<rmjb> #ubuntu-java?
<LaserJock> I don't think there's a channel
<LaserJock> or a mailing list
<LaserJock> but I don't know for sure
<rmjb> me and 5 bots
<rmjb> if Seveas is a bot
<rmjb> I'll email the list
<LaserJock> https://launchpad.net/~motujava
<rmjb> thansk
<rmjb> 10q
<LaserJock> well, looks like MOTU Java = zakame 
<rmjb> zakame, are you on?
<LaserJock> I'm guessing he'll be on later
<rmjb> I'll send him an email just in case
<sistpoty> lol... I accidantily subscribed motu-sru while I wanted to subscribe motu-swat to a bug...
<somerville32> Ugh oh
<sistpoty> luckily I can unsubscribe both again *g*
<pochu> hi sistpoty!
<sistpoty> hi pochu
<pochu> thanks for the upload :)
<pochu> it built fine
<sistpoty> your welcome
<pochu> sistpoty: do you know something new about the gnome-app bug? :)
<sistpoty> pochu: nope
<pochu> hehe
<bddebian> Heya
<sistpoty> wb bddebian
<bddebian> txh sistpoty
<rmjb> hey bddebian
<bddebian> Hello rmjb
<pochu> hi bddbebian :)
<pochu> ups
<pochu> typo :)
<bddebian> Hello pochu
<pochu> hi :)
<zakame> hi there
<bddebian> Heya zakame
* Hobbsee wonders why universe UVF and FF are on different days
<ajmitch> Hobbsee: because that's what we decided
<ajmitch> to give time to get new packages reviewed
<LaserJock> darn, I shouldn't have gone to the Feisty forum
<ajmitch> no, you shouldn't
<sistpoty> hi zakame
<ajmitch> I avoid it
<PriceChild> LaserJock, Nooooo!!!! :)
<ScottK> Any particular reason?
<zul> LaserJock: its like crack..
<LaserJock> I just read through all 11 pages of "composite-by-default: Deferred"
<PriceChild> I closed that and people keep making them :(
<LaserJock> well, they have a point but they argue it so badly
<LaserJock> it seems impossible to get a decent conversation there
<PriceChild> Its about 3/4 merged threads...
<ajmitch> LaserJock: it'll just depress & demotivate you
<ajmitch> don't read it\
<Hobbsee> ajmitch: ahhh
<Hobbsee> LaserJock: you crazy person
<LaserJock> ajmitch: too late ;-)
<LaserJock> I'm done with it though
<Hobbsee> is it worth requesting a sync of sunbird now?
<LaserJock> did it make it into Debian?
<Hobbsee> yeah.  experimental
<Hobbsee> did ages ago, it seems
<ajmitch> Hobbsee: read the logs from the mozilla team meeting earlier
<ajmitch> they discussed sunbird
<Hobbsee> ah right
<LaserJock> yeah, I was going to say that
<LaserJock> read that on the forums ;-)
<PriceChild> Hey, I'm trying to finish my xvidcap package ( http://revu.tauware.de/details.py?upid=3582 ) .... but running pdebuild ends up with http://paste.ubuntu-nl.org/4364/ Could anyone give me a bit of help please?
<zul> *grumble* *grumble* 
<LaserJock> uh oh
<LaserJock> somebody didn't get a pony today :-)
<zul> LaserJock: no i read the forums...apparently xen is unmaintained
<LaserJock> of course it is!
<ajmitch> I *told* you so
<LaserJock> as is all of Universe
<somerville32> So... Composite by default is deferred for Feisty?
<LaserJock> and Mark is single-handedly screwing over the entire Ubuntu community
<LaserJock> ;-)
<PriceChild> LaserJock, see the one in cafe about mark paying people to storm the forums?
<somerville32> LaserJock, Mark as in Mark Shuttleworth?
<zul> meh...forums..
<LaserJock> somerville32: of course :-)
<somerville32> LaserJock: How is Mark screwing over the entire Ubuntu community?
<ajmitch> somerville32: by denying them the shiny
<ajmitch> & killing ponies
<bddebian> What'd we not do this time? :-)
<LaserJock> somerville32: by promising stuff that he can't deliver, apparently
<LaserJock> I somewhat agree with their point in the sense that we need to be very careful about what we are saying *will* be in the next release
<ajmitch> because sabdfl is secretly in league with MS!!
<LaserJock> I don't consider a spec/blog to be a promise but some people do
<somerville32> Oh, you were talking about composite being deferred before I even mentioned it, lol
<ajmitch> some people consider even a vague rumour to be a promise
<sistpoty> oh... the promises thing reminds me that we should do a revu sprint any time soon 
<ajmitch> yep
<ajmitch> this week
<sistpoty> .ok
<ajmitch> maybe a 2-day thing?
<PriceChild> Could anyone help me? :)
<ajmitch> PriceChild: probably not
<sistpoty> ajmitch: sounds great
<sistpoty> starting on wednesday?
<ajmitch> PriceChild: we're too busy complaining
<PriceChild> hehe ah well :)
<ajmitch> sistpoty: why not?
<PriceChild> complaining does need to be done...
<ajmitch> PriceChild: your pbuilder base tarball looks to be outdated or broken
<PriceChild> if you don't do it then some other highly less qualified will attempt and do it all wrong
<sistpoty> LaserJock: your opinion on revu-sprint?
<PriceChild> ajmitch, I built it 5 minutes ago :(
<sistpoty> bddebian: ^^?
<ajmitch> PriceChild: then probably broken
<PriceChild> hehe :)
<PriceChild> How can it be fixed?
<LaserJock> sistpoty: yes, very essential. Maybe 2 3-4 day sprints, 1 per week
<bddebian> sistpoty: ??
<ajmitch> PriceChild: depends on how it's broken
<sistpoty> bddebian: what do you think of doing a revu sprint starting wednesday? 
<PriceChild> lol ajmitch 
<bddebian> sistpoty: You mean we stopped? ;-)
<sistpoty> hehe
* sistpoty stopped :(
<PriceChild> So how do i find out how its broken? ajmitch :P
<sistpoty> ajmitch, LaserJock: I'll write a mail to the ml
<ajmitch> sistpoty: thanks :)
<bddebian> PriceChild: Have you updated your pbuilder lately?
<PriceChild> bddebian, 5 minutes ago
<ajmitch> PriceChild: login, find out why you can't install the packages
<bddebian> Hmm, maybe somethings broken in the archives
<PriceChild> but I can install them?
<ajmitch> outside pbuilder, you can
<PriceChild> I can
<ajmitch> then use pbuilder login
<PriceChild> ah sorry
<PriceChild> This doesn't make sense :(
<PriceChild> zlib1g-dev: Depends: zlib1g (= 1:1.2.3-13ubuntu2) but 1:1.2.3-13ubuntu3 is to be installed
<ajmitch> that's ok, if it were easy, we wouldn't be so elitist ;)
<PriceChild> zlib1g is already the newest version.
<PriceChild> haha
<bddebian> ajmitch: lol
<ajmitch> check where it wants to get things from in sources.list
<ajmitch> & with apt-cache policy
<ajmitch> something is out of sync there, usually due to having security/updates missing or similar
<sistpoty> hm... should I write the announce to -devel-announce? or just -motu?
<bddebian> PriceChild: It built for me but your version is wrong
<PriceChild> version?
<PriceChild> And why is it not building for me? :'(
<PriceChild> policy has a higher version than installed... Something's very wrong... :P
<ajmitch> sistpoty: -devel-announce could be good, we may get others willing to help out
<sistpoty> ajmitch: ok
<bddebian> Should be something like xvidcap-1.1.4p1-0ubuntu1
<sistpoty> ajmitch, LaserJock: anything missing/errors? http://paste.ubuntu-nl.org/4368/
<bddebian> PriceChild: I assume it also should not be a native package
<PriceChild> I'm confused as to what you mean :)
<LaserJock> we can't make the REVU sprint next week?
<ajmitch> sistpoty: I wouldn't say that it's to get "as many in as possible"
<ajmitch> since I really don't like that
<bddebian> PriceChild: I mean you should have an orig.tar.gz
<sistpoty> LaserJock: we could make another sprint next week?
<sistpoty> ajmitch: better suggestion?
<ajmitch> but to review & give feedback on as many packages as possible, to ensure they meet our high quality standards
<bddebian> Get all the crap in we can... :-)
<PriceChild> bddebian, I do...? I guess I'm still confused... :)
<ajmitch> since it's really a two-way thing, motus teaching people the ways of packaging
<bddebian> PriceChild: Your upstream tarball should be xvidcap_1.1.4p1.org.tar.gz, not xvidcap_1.1.4p1.tar.gz
<bddebian> s/org/orig/
<sistpoty> ajmitch: http://paste.ubuntu-nl.org/4369/
<LaserJock> yeah, I think we really need to get the contributors on board
<LaserJock> it's easier to guilt trip MOTUs in to reviewing, we know who they are
<bddebian> ??
<LaserJock> a REVU sprint really only seem effective to me if the contributors show up too
<ajmitch> sistpoty: I guess it's ok
<sistpoty> ajmitch: ok, thx for proof-reading
<ScottK> I thought the REVU sprint was very helpful.
<LaserJock> I can review all day but if there aren't people to respond and reupload at the end of the day we don't get much done
<ajmitch> yep
<PriceChild> bddebian, The upstream didn't package their source properly at all... so I had to make the orig myself and noted that in the changelog
<ScottK> Seeing it coming got me off my duff and packaging.
<ajmitch> sistpoty: feb 2nd?
<LaserJock> ScottK: yep :-)
<sistpoty> argl... -ENOCALENDAR *g*
<ajmitch> hehe
<ajmitch> wednesday == feb 7th
<sistpoty> corrected :)
<LaserJock> can we do Friday and Saturday?
<PriceChild> bddebian, or does your point still stand? :)
<bddebian> afaik it does
<PriceChild> :(
<sistpoty> LaserJock: well, we'd miss out core-devs on saturday I guess...
<LaserJock> yep
<sistpoty> LaserJock, ajmitch: how about thursday and friday?
<LaserJock> but we might gain some contributors
<LaserJock> as it's the weekend
<PriceChild> bddebian, http://sourceforge.net/project/showfiles.php?group_id=81535&package_id=83441&release_id=464228 I don't understand what I'm meant to use instead though...
<LaserJock> or am I the only guy nerdy enough to see the weekend as prime Ubuntu time
<sistpoty> LaserJock: true as well
<Nafallo> Fujitsu: ping
<bddebian> PriceChild: Just rename the freakin' file man :-)
<PriceChild> bddebian, lol ok
<LaserJock> I still want to make sure we get in as many merges/updated merges in as possible before UVF
<PriceChild> bddebian, See that kind of instruction I can understand! :D
<sistpoty> LaserJock: I'm really undecided... ajmitch what do you think? or anyone else?
<LaserJock> Thursday-Saturday?
<sistpoty> sounds sane to me
<LaserJock> 2 days with more core-devs available
<ajmitch> it's going to be mostly MOTUs anyway
<TheMuso> LaserJock: What do you mean Thurs-Sat?
<ajmitch> and mostly bddebian & crimsun 
<sistpoty> yep
<ajmitch> while the rest of us cheer them on
<bddebian> Nah, I don't do nuttin'
<ajmitch> & sit & drink beer
<LaserJock> I know I'm going to be swamped until the weekend
<LaserJock> and I'd like to help out more this time
* ajmitch also
<sistpoty> bddebian: you're still the revu janitor :P
<ajmitch> but I'm never one for reviewing
* ScottK found sistpoty to be VERY helpful during the last sprint...
<LaserJock> ajmitch: you can DO IT!
<sistpoty> unfortunately /me is a little bit stressed with thesis right now... but I'll try to review as much as possible
<sistpoty> LaserJock: will you be doing another revu-report?
<LaserJock> yep
<sistpoty> cool
<LaserJock> I might have a pre-sprint report
<sistpoty> even better :)
<LaserJock> to update on what we did since the first one
<TheMuso> Guys, give me a couple of days doing a few more merges, and I'll be happy to give reviewing a shot at least.
<ajmitch> LaserJock: nah I've got other things I have to get done by then
<LaserJock> if you get the email out I'll blog it
<ajmitch> and stick it on the forums? ;)
<LaserJock> ummmm, do I have to?
<PriceChild> bddebian, but then "debuild -S -sa" goes crazy and "ignoring deletion of file....." several times
<sistpoty> ok, next try with the mail: http://paste.ubuntu-nl.org/4371/
<TheMuso> gah mom could really do with a comments field
<ajmitch> TheMuso: that was the other thing I was going to do for stuff
<ajmitch> oh well, I suck
* ajmitch needs to get some food
<TheMuso> ajmitch: Never mind.
<bddebian> PriceChild: Did you generate your package with the other tarball before you re-packed it?
<LaserJock> TheMuso: poke Keybuk about it
<TheMuso> Its just a matter of people checking for sync requests etc before working
<LaserJock> TheMuso: it's the #1 complaint I've seen about MoM
* bddebian complains about that tooo
<PriceChild> bddebian, I just replaced the orig I made with the one from upstream then ran it...
<sistpoty> ok, mail sent
<bddebian> PriceChild: Why?
<PriceChild> :s why to which bit?
* bddebian is starting to get confused
<PriceChild> hehe :)
<LaserJock> sistpoty: excellent, thanks
<PriceChild> sorry
<bddebian> PriceChild: Why did you re-pack it in the first place?
<PriceChild> I can't remember whether I did now.... :(
<Nafallo> Fujitsu: I guess you never committed that libvorbis thing for mplayer?
<PriceChild> bddebian, ah yeah I did.... well sorta... I basically deleted the "debian" folder to make the orig
<bddebian> There ya go.  If you do that, you have to build with the tarball you made
<PriceChild> hehe pardon? :)
<bddebian> If you make a new tarball, you have to build with that, you can't switch back and forth
<PriceChild> Ok yes I get that... :)
<Hobbsee> bddebian: you do realise that the latest upload of that isnt PriceChild's?
<bddebian> Hobbsee: Oh, no, I didn't :-)
<PriceChild> hehe
<Hobbsee> bddebian: :)
<Nafallo> Fujitsu: FYI, I do it know :-)
<TheMuso> Anybody working on libpam-ccreds?
<Nafallo> hmm. what's the correct debhelper to depend on those days?
<Hobbsee> >= 5, iirc
<Fujitsu_> Nafallo: I didn't do it before I left work, correct. If you want to do it, go ahead.
<Nafallo> Hobbsee: thanks
<Nafallo> Fujitsu: already done :-)
<bddebian>  >=5.0.37
<Nafallo> Fujitsu: seems my branch is bound to launchpad ;-)
<Fujitsu_> Te ubuntu.83493 branch?
<Fujitsu_> *The
<Nafallo> Fujitsu: no. that's not bound. ubuntu is bound. the other one is for that bug and is not bound :-)
* Nafallo multitasks ;-)
<Fujitsu_> OK.
<Fujitsu_> I note that you haven't merged it into ubuntu yet... Or has the push not finished yet?
<Nafallo> Fujitsu: both is true. I'm not quite finished with it yet either. I need to touch debian/* :-)
<Fujitsu_> OK.
<Fujitsu_> Why?
<Nafallo> changelog entry + debian/rules --enable-pulse :-)
<Nafallo> and debian/control
* Nafallo commits 'bump standards'
<Fujitsu_> I was thinking about bumping the standards version a couple of hours after I upload it yesterday >_>
<Nafallo> :-)
<Fujitsu_> How should we do changelog entries? Create a new one with distro UNRELEASED, adding entries in each commit, and only changing the distro to feisty (or whatever) when it's about to be uploaded? Otherwise, changes might not get noted in the changelog...
<Nafallo> I thought we might see how bzr handles it when we just do dch -i in multiple places and then merge... I hope it's smart about it actually :-)
<Nafallo> if we only worked on ubuntu we just need to dch and it will probably "just work"(tm)
<Fujitsu_> So debian/changelog should be modified in each commit?
<Nafallo> I do that now anyway :-)
<Nafallo> will see if it actually works.
<Fujitsu_> Yep.
* Nafallo thinks bzr is fun to experiment with ;-)
<Fujitsu_> It is.
<Fujitsu_> Except when pushes take 3 hours!
<Nafallo> indeed :-)
<Fujitsu_> Bzr should be great for maintaining packages like this.
<bddebian> Has someone already requested a sync of libgalago-gtk_0.5.0-1?  I don't see if they have
<Nafallo> oh. the branchpage for ubuntu is finally updated .-)
<Nafallo> :-)
<Fujitsu_> Indeed.
<Fujitsu_> It might be nice if the branch pages showed (or allowed expansion of) commits within merges.
<Nafallo> oh.
<Nafallo> imbrandon: I just ran pbuilder-feisty
<Nafallo> imbrandon: I just ran pbuilder-feisty update
<Nafallo> :-)
<Nafallo> imbrandon: could we have hooks that do that every run? :-)
<ajmitch> sure, why not
* ajmitch does apt-get update every time he runs pbuilder
* Nafallo is pretty sure he has such hooks somewhere :-)
<LaserJock> it depends on what machine I'm using
<ajmitch> a 1-line hook isn't too challenging
<Nafallo> ajmitch: don't forget dist-upgrade in a hook after :-)
<LaserJock> on my laptop it takes 1 min for the pbuilder to unpack
<LaserJock> so I don't update as often on that one
<ajmitch> Nafallo: not that it's really needed, that's just asking to break things
<Nafallo> ajmitch: I've used it since... breezy or so. never had any breakage
<Nafallo> it just does what update does
<Nafallo> pbuilder update that is
<Nafallo> like now it would have updated gcc and python :-P
<Nafallo> toolchain might be good to have up-to-date :-)
* sistpoty is off to bed now
<sistpoty> gn8 everyone
<Nafallo> wow
<Nafallo> that's early for being him :-P
<Fujitsu__> Heh.
<Nafallo> hehe
<Nafallo> lots of deprecated warnings when building mplayer :-)
<Nafallo> bug 60473
<Ubugtu> Malone bug 60473 in mplayer "mplayer slowly starting because of AF_INET6" [Undecided,Confirmed]  https://launchpad.net/bugs/60473
<Nafallo> hrm. what to do about that one? :-)
<LaserJock> remove mplayer from the repos? ;-)
<Nafallo> my gutfeeling is that we shouldn't be in the way for the IPv6 revolution ;-)
<Nafallo> but then again... I actually have an /48 ;-)
* Nafallo reject that bug
<Nafallo> hmm
<Nafallo> I should use feisty on this system... ;-)
<LaserJock> hmm, the REVU report is interesting
<LaserJock> it takes an average of 20 comments/updates for each new package uploaded
<LaserJock> unless people aren't emailing -motu when they upload (which is certainly possible
<LaserJock> )
<LaserJock> s/20/40/
<ajmitch> that's quite a few rounds that a package has to fight through to get in
<LaserJock> yeah
<LaserJock> for the first revu sprint it to 12/ new package
<LaserJock> *took
<LaserJock> something seems wrong there
<bddebian> Yeah. :-)
<LaserJock> well, shoot, what am I going to do
<LaserJock> how can I tell what NEW packages have been uploaded
<Hobbsee> LaserJock: look in the archive?
<LaserJock> but how do I know if it's NEW or not?
<Hobbsee> madison - source accepted, but no binary?
<LaserJock> but that would only work for stuff that hasn't been processed
<LaserJock> I need to find out what package have been added to Universe since date X
<Nafallo> LaserJock: https://launchpad.net/ubuntu/feisty/+queue this one?
<LaserJock> well, that has yet to be proccessed ones
<LaserJock> I need to get historical
<Nafallo> LaserJock: change NEW to something else?
<Nafallo> LaserJock: you got a listbox at the top
<LaserJock> Nafallo: Done give me 43297 results
<Nafallo> LaserJock: nice ;-)
<Nafallo> I'll go to bed now :-)
<Nafallo> see you there
<Fujitsu_> Night, Nafallo./
<Nafallo> back :-)
<somerville32> Does anyone know of a tutorial for setting up an LDAP server on Ubuntu?
<Nafallo> somerville32: help.ubuntu.com/community should have something
<somerville32> Oh goodie!!
<somerville32> There is :)
<Nafallo> help.ubuntu.com quickly becomes better than gentoo docs :-)
<Nafallo> and that is not a small achievement
* Nafallo reads up on the bzr smartserver
<Nafallo> I will probably start to host my branches on my server, that is bound to launchpad, and then have the workingtrees as checkouts from there :-)
<Fujitsu_> Nafallo: Why not use the supermirror?
<Nafallo> I'll use that aswell, as I said :-)
<Fujitsu_> If they're hosted on your server, they're not hosted on the supermirror.
<Nafallo> my current setup have been mkdir ~/devel/$package/; bzr init-repo bzr; cd bzr; bzr co sftp://bazaar.launchpad.net/...; cd ..; bzr co --lightweight bzr/ubuntu
<Nafallo> and then bind bzr/ubuntu to the supermirror
<Nafallo> I think I will move the repos to my server as ~/bzr/$package instead
<Nafallo> I can still bind them to the supermirror :-)
<Fujitsu_> True.
<Nafallo> http://bazaar-vcs.org/SmartServer
<Nafallo> use case 5 is me in a nutcase
<LaserJock> hehe
<LaserJock> s/nutcase/nutshell/
<LaserJock> or maybe not ;-)
<Nafallo> that to :-)
<Nafallo> seems the supermirror doesn't run the smartserver yet
<LaserJock> exactly :(
<Nafallo> and 6.10 seems to have only bzr 0.11... :-/
<LaserJock> that's why I added the bzr repo
<Nafallo> oh?
<LaserJock> Nafallo: bazaar-vcs.org has a bzr repo
<LaserJock> or rather a deb repo for bzr
<Nafallo> nice. didn't see that
<zakame> afternoon MOTUs
<Fujitsu_> LaserJock: Or grab a Feisty package, or a backport, both of which are likely more trustworthy.
<LaserJock> you think so?
<poolboy> guys the MOTU/Merging page on the wiki needs to be updated who should i contact about this?
<LaserJock> do you know what needs to be updated?
<poolboy> there are a couple of link which are broken
<poolboy> that is the only thing i've noticed so far
<LaserJock> well, the wiki is open for editing
<poolboy> yeah but i wouldn't know where to link it to
<LaserJock> if you don't feel comfortable doing that let me know which links and I'll fix them
<poolboy> ok here
<poolboy> https://wiki.ubuntu.com/MOTU/Packages/Merging?action=show&redirect=Merging
<poolboy> that is the page and the links are to The new Debian source package files that the Dapper packages will be derived from:
<poolboy> [WWW]  xcdroast_0.98+0alpha15-3.dsc
<poolboy> [WWW]  xcdroast_0.98+0alpha15-3.diff.gz
<poolboy> i would not mind doing it if I knew the content and i'm new to linux so I don't think i should be messing with the wiki just yet
<poolboy> Thank you for your help
<LaserJock> hmm, so the broken links are to those xcdroast files?
<poolboy> yeah
<LaserJock> that's a tough one
<LaserJock> those files come and go, that's the hard part of doing a real life tutorial
<poolboy> yeah i tough it might be
<poolboy> i was trying to go through the tutorial and without those it also gets kind of hard
<LaserJock> but ... I think I archived those files for the Ubuntu Packaging Guide
<Fujitsu_> LaserJock, those files won't go for another 4 years if you use the latest Dapper ones.
<LaserJock> it's the Debian ones that are the hard part
<Fujitsu_> A good point.
<poolboy> the debian ones still seem to be up.
<LaserJock> it's the Breezy ones?
<poolboy> no i'm sorry 
<poolboy> i read the whrong thing
<poolboy> it is the debian one
<poolboy> I found the files trough google but i'm not sure they are reliable
<LaserJock> poolboy: fixed
<LaserJock> thanks for bringing it up
<poolboy> no problem thanks for fixing it
<poolboy> i'll go over the tutorial later
<poolboy> thanks
<LaserJock> anybody know how to split up a Depends: line into individual package names?
<zakame> @pkgnames = split /, +/ => $depends; @pkgnames = map { s/\(.*\)// } @pkgnames;
<LaserJock> oh my
<zakame> sorry I'm in perl-mode :P
<LaserJock> how do I even use that?
<zakame> then again there ought to be something in devscripts that does that iirc
<LaserJock> wow, there are a lot more scripts in there than I thought
<zakame> check out dctrl-tools as well
<LaserJock> hmm, can't find a specific tool for it
* Nafallo builds a new mplayer and will upload if it works
<zakame> Nafallo: keep 'em coming :D
<LaserJock> bah, I'll have to work on this tomorrow
<Nafallo> hmm
<Nafallo> I should try to get some sleep soon though
<Nafallo> 7:37 AM here.
<zakame> hmm yeah and I reckon you had to set up a new service?
<Nafallo> I didn't get that far.
<Nafallo> I'm not sure how I want to implement my bzr SmartServer.
<Nafallo> the easiest might be to just launch it with a @reboot-line in crontab though.
<Nafallo> either that or learn upstart and launch it when /home is mounted
<AnAnt> hello , do I have to create a man-page for a binary that doesn't use any command lines, and it is a GUI application actually
<Nafallo> <3 ccache
<AnAnt> hu ?
<AnAnt> ping crimsun 
<AnAnt> ping ajmitch 
<AnAnt> ping lionel 
<zakame> AnAnt: they're probably counting sheep.
<AnAnt> why didn't they make a package to do that for them ;)
<AnAnt> ok, I got what you mean
<zakame> AnAnt: if you can write a manpage, write a manpage; if your program has documentation somewhere else, you could add their links in the manpage (eg SEE ALSO)
<zakame> hehe, actually there's electricsheep
<AnAnt> zakame: ok, another question, the program has mozilla-browser | firefox in its Depends: field
<AnAnt> zakame: but since it works better with mozilla-browser, the packager decided to put mozilla-browser in the Recommends: field also
<AnAnt> is that the correct way ? because lintian/linda gave a warning about that
<zakame> hmm why not www-browser in Depends?
<AnAnt> zakame: no, not any www-browser, I think it uses some libraries that are in mozilla's/firefox's browser
<zakame> ah
<zakame> is this a package for merging?
<AnAnt> merging ?
<zakame> I mean, what package are you working on? is that a new one (eg to be REVUd) or a package from Debian?
<AnAnt> zakame: a new package
<AnAnt> to be REVU'd
<AnAnt> I am not working on it, just helping the packager
<zakame> ah I see
<zakame> what exactly was the warning lintian gave you?
<AnAnt> Package Recommends mozilla-browser, which is also listed in Depends.
<AnAnt> it's linda btw
<AnAnt> lintian didn't complain
<zakame> ah, afaik that's ok, you may probably ignore the warning
<zakame> better yet, if you can isolate which libs in mozilla-browser/firefox your package uses, use that instead of the browsers
<AnAnt> zakame: the libs are in the mozilla-browser package, not a package the the browser depends on
<AnAnt> I mean the libs are in the mozilla-browser/firefox package itself
<AnAnt> zakame: btw, if the system has neither mozilla-browser nor firefox installed
<AnAnt> zakame: and Depends field has mozilla-browser|firefox in it
<AnAnt> zakame: which one will the system attempt to install ?
<zakame> good question.
<joejaxx> anyone ever heard of Xorg using 400mb of ram?
<lionel> Hi AnAnt
<lionel> it should install mozilla-browser
<lionel> and yes, you should do a manpage :)
<lionel> (as lintian/minda will say)
<lionel> joejaxx: in residual or virtual ?
<AnAnt> lionel: but what will be mentioned in the manpage ?
<joejaxx> lionel: residual
<lionel> AnAnt: just a little description of the program (and of its arguments if aplicable)
<joejaxx> lionel: 650mb virtual
<lionel> joejaxx: that's quite a lot but... Here it's 503mb in virtual and 213mb in residual
<joejaxx> :(
* somerville32 stabs ldap in the face repeatedly.
* joejaxx tells somerville32 to get Active Directory
<joejaxx> somerville32: haha j/k
<somerville32> Eww
<joejaxx> :P
<somerville32> It won't let me have dashes or dots in my uid
<joejaxx> somerville32: :\
<joejaxx> lionel: do you know of anything that would have triggered that?
<lionel> joejaxx: nope
<joejaxx> it is not like i am running beryl
<lionel> somerville32: strange
<AnAnt> lionel: ok, thanks
<lionel> which version of OpenLDAP are you using ?
<somerville32> 2.2?
<lionel> here i have uid with dot and arobase
<lionel> it is a 2.2 here (Debian Sarge)
* somerville32 pouts.
<somerville32> What is a arobase?
<lionel>  @
<lionel> hi dholbach !
<dholbach> good morning
<dholbach> hey lionel
<zakame> yo dholbach!
<dholbach> hey zakame
<AnAnt> btw, is there anyone here who can sponsor a package that I uploaded to Debian ?
<ajmitch> morning dholbach 
<dholbach> hey ajmitch
<lucas> you already uploaded it ?
<lucas> ?!
<lucas> AnAnt: ^^
<AnAnt> lucas: yeah
<AnAnt> lucas: sorry I was away of desk
<AnAnt> ping lucas 
<lucas> AnAnt: what do you want ? :)
<AnAnt> lucas: well, why were u asking if I uploaded it ?
<lucas> you need a sponsor. to upload which package ? to where ?
<AnAnt> lucas: Debian
<lucas> but you said that you already uploaded it in debian ?
<AnAnt> lucas: well, the sponsor is to advocate it I guess
<AnAnt> lucas: btw, I uploaded it to mentors.debian.net
<lucas> ah ok
<lucas> then why not ask on #debian-mentors ?
<AnAnt> ok
<AnAnt> thanks
<lucas> I don't have time for a full review now, sorry
<AnAnt> lucas: well, if I am not in a hurry ? can I give you the links ?
<lidb_> hello, who can help review llk-linux, a mahjongg-like game, thanks
<lucas> ask on debian-mentors. that will be more efficient.
<AnAnt> ok, thanks
<Q-FUNK> hmm. is there any way to make "apt-get source --download-only $(dpkg --get-selections | cut -f 1)" skip packages it cannot find?  --ignore-missing doesn't seem to work for source.
<\sh> moins
<\sh> guys, does anyone know how I can remove DRM from wma files under linux, without destroying the file?
<viviersf> ajmitch, ping
<AnAnt> anyone knows a package using dpkg-statoverride ?
<ajmitch> viviersf: yes?
<AnAnt> found one, thanks
<AnAnt> I ran  dpkg-statoverride root shadow 4755 /usr/bin/tss 
<AnAnt> yet when I run ls -l /usr/bin/tss, I don't find any +s mode on it !
<AnAnt> what is dpkg-statoverride for then ?
<viviersf> ajmitch, nm got right :)
<viviersf> thx anyways
<ajmitch> ok
<AnAnt> oh, I should use --update
<popey> now the qemu kqemu module has gone GPL, and it's in debians NEW queue, is it likely we will get it in time for feisty?
<Fujitsu> popey: No reason we can't. FeatureFreeze is a couple of weeks away.
<popey> excellent
<popey> is there something that needs to be done to poke it along?
<Adri2000> sync request
<Fujitsu> We can't sync from NEW.
<Fujitsu> So we need to wait. If it gets dangerously close to FF, we'll work around it.
<popey> sure but the fact that it went from announced free to the new queue in 4 hours might mean it gets into debian quickly? :)
<Fujitsu> Yeah, that's rather incredible.
<popey> clearly some motivation for a truly free easy to use and fast virtualiser 
<popey> especially given it now does x86_64
<Fujitsu> Oooh, I like it.
<popey> which virtualbox doesnt (yet)
<popey> yeah, fabrice needs a big pat on the back for that decision
<Fujitsu> It does MIPS and [insert other obscure architectures here]  too, doesn't it?
<popey> yes
<popey> the kernel accelerator "only" does i386 and x86_64 thought at the moment
<gnomefreak> Can you package with debhelper without renaming everything -debhelper?
<Fujitsu> gnomefreak, I think a better question is can you do the opposite of that.
<Fujitsu> I've never seen any package with -debhelper.
<gnomefreak> from the packaging link it says to rename everything -debhelper
<gnomefreak> i think its because you grabbed source hello-debhelper-2.1.1.tar.gz
<gnomefreak> but stupid me was changing everything to -debhelper and than it complains about not finidng the orig.tar.gz
<Fujitsu> It only says that to differentiate from the non-debhelper hello.
<gnomefreak> ok cool ill try it leaving everything the same except for adding debhelper >=5 to control
<Fujitsu> siretart, around?
<sladen> popey: I wonder if the bugs which prevents kqemu actually booting the LiveCD have been fixed
<popey> well I can't get kqemu to compile here :S
<xerxas> giskard ? 
<xerxas> someone which has upload right to the ftp here ? 
<xerxas> dholbach,  ? 
<xerxas> can you point me to someone ? My package have been advocated, it's supposed to be in the upload queue, but it doesn't get uploaded for 10 days or so 
<xerxas> I need that package to be uploaded so I can package landell
<Hobbsee> xerxas: to the ftp where?
<dholbach> xerxas: the source is in ubuntu already
<dholbach> xerxas: it might have ftbfs
<xerxas> ftbfs ? 
<dholbach> no, it has built
<dholbach> https://launchpad.net/ubuntu/+source/libtapioca-cil/0.14.svn20070104-0ubuntu1
<dholbach> ftbfs = fail to build from source
<xerxas> so ? 
<xerxas> where it is then ? 
<dholbach> no idea
<xerxas> Hobbsee,  don't know :)
<dholbach> ask the archive admins in #ubuntu-devel
<dholbach> mithrandir might know
<Hobbsee> xerxas: to ubuntu, to revu....
<Hobbsee> it's probably waiting in binary NEW, actually
<xerxas> Hobbsee,  to revu, then giskard  uploaded it to ubuntu , i think so 
<giskard> ?
<ScottK> https://launchpad.net/ubuntu/feisty/+queue?queue_state=0&queue_text=libtapioca
<giskard> it is in ubuntu where is the problem?
<xerxas> giskard,  I still don't see it 
<xerxas> giskard,  at least, on packages.ubuntu.com -> feisty
<xerxas> I have no feisty available right no 
<xerxas> now 
<ScottK> xerxas: Did you check the link I provided above?
<xerxas> not yet :)
<xerxas> currently checking 
<xerxas> ScottK,  what does that mean ? 
<xerxas> that means that the packages are built ? 
<ScottK> No it means that they didn't build automatically for some reason and require manual intervention.
<ScottK> Beyond that you'll need to ask someone that knows more than me.
<siretart> Fujitsu: sorry, /me at work.
<zakame> hmm what's the preferred java version for building new java packages for feisty, if ever?
<\sh> I wonder what we do with all those packages who are using linux/ include files, which are not in linux-libc-dev anymore?
<\sh> e.g. dibbler
<\sh> moins btw
<Nafallo> http://revu.tauware.de/details.py?upid=4271
<Nafallo> slomo: ping mp3lib
<slomo> Nafallo: pong
<Nafallo> slomo: bug 83580
<Ubugtu> Malone bug 83580 in mplayer "mplayer compiled without mp3 support" [Undecided,Fix committed]  https://launchpad.net/bugs/83580
<Nafallo> slomo: I should enable mp3lib again or do you remember why you turned it off?
<slomo> Nafallo: enable it again... it was only disabled for the previous release we had because of a bug that caused very bad distortions (i.e. plain noise)
<slomo> Nafallo: enable it again please, it's fixed in svn since ages
<Nafallo> slomo: oki
<slomo> whoever updated to the new upstream version should've taken a look at the old changelog entries :P
<Nafallo> slomo: Fujitsu
<slomo> ok
* Nafallo looks at bzr help builddeb
<\sh> grmpf
<tsmithe> hmm
<tsmithe> now that kqemu has been released as foss all that needs doing is the licence updating and it can be moved to universe
<\sh> crimsun: ping xmms2 :)
<\sh> git-rev-core is what?
<\sh> aeh git-rev-parse
<\sh> ah build-dep on git-core
<\sh> is missing
<\sh> so fixing xmms2 first...*grmpf*
<\sh> xmms2 fix uploaded
<\sh> am I stupid?
<geser> \sh it's not the missing dep
<\sh> can someone tell me what's written in this logfile, where the package belongs? 
<\sh> http://people.debian.org/~lucas/logs/2007/02/01/ubuntu-rebuild/eyed3_0.6.11-1_feisty32.buildlog
<\sh> geser: git-rev-parse is in git-core, which wasn't mentioned in the build-deps...(I think you mean xmms2)
<geser> yes, i mean xmms2 but this is not the build failure
<\sh> this logfile tells me, that it's universe, but archive.ubuntu.com tells me main
<\sh> geser: http://librarian.launchpad.net/6221835/buildlog_ubuntu-feisty-i386.xmms2_0.2DrHouse-3.1ubuntu2_FAILEDTOBUILD.txt.gz 
<geser> \sh: /bin/sh: -c: line 0: syntax error near unexpected token `('
<geser> it's the HASH(0x82db558)="" in the next line causing the problem
<geser> according to cjwatscon it's probably a bug in sbuild
<\sh> hmmm
<\sh> in pbuilder it compiles fine
<\sh> *gnarf*
<gnomefreak> anyone else having problem with pbuilder erroring while trying to grab depands?
<geser> I will ask infinity about it
<\sh> I wonder why lucas lists tells me "this package is universe" but my i386 system tells me something else
<geser> \sh: eyed3 went into main 3 days ago
<\sh> argl...ok...that's it
<\sh> ok changed it to the right maintainer field then...
<geser> \sh: at http://members.ping.de/~mb/srcmaintainermangler/ you can find a script if you need one
<\sh> ping.de still exists in dortmund? ,-)
<geser> yes
<gnomefreak> LaserJock: you around?
<\sh> geser: can it be that we know each other from older times from dortmund? ( I was a beginning member of prima e.V.)
<LaserJock> gnomefreak: yeah, what's up?
<gnomefreak> LaserJock: the packaging guide for debhelper: http://doc.ubuntu.com/ubuntu/packagingguide/C/basic-debhelper.html  can you edit that to use a real package?
<geser> \sh: not that I know, I'm a ping members since 1999
<gnomefreak> LaserJock: most people arnt gonna build hello-dehelper ;)
<LaserJock> why?
<gnomefreak> took me 3 days to figure out why it couldnt find source
<LaserJock> what?
<LaserJock> it's in the repos
<gnomefreak> LaserJock: apt-get source hello-debhelper  (thats the only package with -debhelper_)
<LaserJock> oh stink
<LaserJock> a typo you mean
<gnomefreak> LaserJock: but relistickly speaking how many people are gonna build it
<geser> \sh: ping and prima have merged in the last year
<gnomefreak> thats a type :(
<\sh> geser: oh then I was just gone from dortmund...do you still know Bettina Balz now Bettina Neuhaus?
<LaserJock> gnomefreak: everyone that wants to learn how to package :-)
<gnomefreak> LaserJock: i could understand if it was apt-get source hello
<gnomefreak> LaserJock: but its non transferable
<\sh> geser: carsten truckenbrodt is still doing something for prima+ping?
<LaserJock> what? I'm not understanding
<gnomefreak> if you start renaming dir. its gonna fail to build
<geser> \sh: I've heard the name (and read some mails from her) but not meet her in person yet
<LaserJock> there are 2 packages, hello and hello-debhelper
<gnomefreak> because upstream source and ubuntu source are named different
<LaserJock> what's wrong with them?
<gnomefreak> upstream is hello ubuntu is hjello-debhelper
<gnomefreak> -j
<LaserJock> ah
<\sh> geser: looks like that I have to visit my old hometown and check what've changed in the last years :)
<LaserJock> well, I'm not sure if that's a problem
<LaserJock> it's a teaching tool
<LaserJock> gnomefreak: so what would you suggest?
<gnomefreak> where do we have cheat sheets for real packages?
<LaserJock> hello and hello-debhelper are real packages
<gnomefreak> if i wanted to rebuild ubuntus verison of say firestarter. i cant apt-get source firestarter-debhelper
<LaserJock> and what do you mean by cheat sheets?
<LaserJock> :-)
<LaserJock> why would you?
<gnomefreak> the page ONLY applies to hello-debhelper
<LaserJock> hello-debhelper is the source package name
<LaserJock> source package names aren't always == upstream names
<gnomefreak> LaserJock: ok building any other package this page is fairly usless (do you see what i mean) everything changes once outside a hello-debhelper package
<LaserJock> no
<LaserJock> I don't see that
<gnomefreak> dh_make -e your.maintainer@address -f ../hello-2.1.1.tar.gz is only for upstream builds
<LaserJock> fine
<gnomefreak> mv hello-2.1.1 hello-debhelper-2.1.1 will cause fail to build
<gnomefreak> if replaced with another package
<gnomefreak> 3 days trying to figure out why it was failing on source package
<LaserJock> ??
<LaserJock> this doesn't make any sense to me
<LaserJock> hello-debhelper is a source package
<gnomefreak> LaserJock: i spent 3 days building a package because i followed the guide and it failed to buiold the source package because it wasnt package-debhelper
<LaserJock> why would you call it package-debhelper
<LaserJock> and it can work if you do it right
<\sh> ok...now I have the second package.,..
<\sh> ccvt_mmx.S:33:27: error: linux/linkage.h: No such file or directory
<\sh> ccvt_mmx.S: Assembler messages:
<\sh> ccvt_mmx.S:302: Error: invalid character '(' in mnemonic
<gnomefreak> because in the guide it tells you to mv package package-debhelper
<\sh> those includes are not in linux-libc-dev just in linux-kernel-headers.
<gnomefreak> it will so fail to build because the dir adn source package dont match
<LaserJock> gnomefreak: I don't think it does
<gnomefreak> it does. and i think it is mainly because of control/changelog file having package-debhelper
* gnomefreak trying it without changing anything to -debhelper but pbuilder is being a PITA
<gnomefreak> so i dont know if it works
<LaserJock> ok
<LaserJock> you want to move the source tree to <packagename>-<version>
<LaserJock> ok, I think I see the issue
<\sh> guys, what are we doing with this dash/bash ftbfs? { } completion problems etc.
<LaserJock> gnomefreak: I'm just missing a mv hello-2.1.1 hello-debhelper-2.1.1
<LaserJock> gnomefreak: probably leftover from the previous section
<gnomefreak> its there
<gnomefreak> mv hello-2.1.1 hello-debhelper-2.1.1 is there
<LaserJock> what version are you looking at?
<gnomefreak> just before the dh_make command
<gnomefreak> the one ive been using for 3 days
<gnomefreak> http://doc.ubuntu.com/ubuntu/packagingguide/C/basic-debhelper.html
<LaserJock> ok
<LaserJock> I was looking at edgy, which doesn't have that
<gnomefreak> ah
<LaserJock> I fixed that a while ago
<_Enchained> hi
<LaserJock> gnomefreak: so now I'm confused, I don't see a problem
<gnomefreak> the page im looking at is for upstream building or ubuntu packaging?
<gnomefreak> than i will point out what i see causing fail to build
<LaserJock> it's for building an Ubuntu/Debian source package using debhelper
<gnomefreak> ok well start with dh_make command == only needed for upstream building
<LaserJock> huh?
<gnomefreak> no if you take apt-get source hello-debuilder and change it to apt-get source gdebi-debhelper we know wont work so you apt-get source gdebi
<LaserJock> sure
<LaserJock> you apt-get source <packagename>
<gnomefreak> dh_make -e your.maintainer@address -f ../hello-2.1.1.tar.gz doesnt work unless you building upstream or debian package
<gnomefreak> LaserJock: correct
<LaserJock> or an Ubuntu package
<LaserJock> I'm not really following you, sorry
<gnomefreak> it doesnt work on firefox 
<LaserJock> if you do as the directions say it should work
<LaserJock> what did you do?
<gnomefreak> you go to mv package package-debhelper is no good why would you have a debhelper folder if you dont have debhelper package
<gnomefreak> LaserJock: dh_make failled to run telling me about the source package
<gnomefreak> i skipped it and did it by hand
<LaserJock> ok, hello-debhelper is *just* the name of the source package
<LaserJock> why whould you run dh_make on firefox?
<gnomefreak> i figured that out and you know that but beginners wont know that
<gnomefreak> LaserJock: it sounded good
<LaserJock> umm, ok
<LaserJock> I'm just not sure what you want me to do about it
<LaserJock> if you follow the directions it works
<LaserJock> should I be clearer that hello-debhelper is just the name of the package?
<gnomefreak> yes and maybe put not all packages need dh_make
<gnomefreak> seeing as firefox doesnt
<gnomefreak> or cant
<LaserJock> uggg
<LaserJock> the whole point is we are creating *new* source packages
<LaserJock> you shouldn't run dh_make on *any* existing source package
<LaserJock> the point of that part of the guide is to teach people how to create source packages from scratch
<LaserJock> granted, we need to get more material on working with existing source packages (we already have some on updates and patches) but it's good to know how to build one from scratch before you start messing around with other people's
<\sh> geser: do you know Sven Kozma (aka Zak) from ping? 
<LaserJock> gnomefreak: does that make sense?
<LaserJock> I could put a bit more description at the beginning to describe the overall process of what we're doing
<gnomefreak> LaserJock: point taken
<geser> \sh: have heard the name only
<geser> \sh: I'm actively involved in ping only since 2004
<\sh> geser: well, if you hear from him, or see him, greet him from me (I think this old guy still knows me (real name)) ...
<\sh> time to go 
<\sh> tomorrow I'll have an appointment with HP..
<\sh> cu 
<Nafallo> slomo: silly you! putting --disable-mp3lib where it didn't belong :-).
<slomo> Nafallo: thanks for fixing it then ;)
<Nafallo> slomo: I wondered why my --enable-mp3lib didn't seem to take effect ;-)
* Nafallo likes bzr builddeb :-)
<AnAnt> why does the Standards-Version have to be 3.7.2.2 ? 
<LaserJock> AnAnt: it doesn't have to be
<LaserJock>  AnAnt it's good to have updated Standards-Version to show that a package is conforming to changes in Debian Policy
<AnAnt> LaserJock: well, I recall that I got this comment in some review
<LaserJock> but 3.7.2 is sufficient
<LaserJock> you should use 3.7.2 if you are doing a new package
<AnAnt> LaserJock: well, when I upload a package to debian they say why do you put Standards-Version to be 3.7.2.2 , put it 3.7.2 !
<LaserJock> but please read the Debian Policy to make sure you agree with the Debian Policy
<LaserJock> the last .2 is for typos
<LaserJock> so it doesn't mean much
<AnAnt> I see
<LaserJock> so 3.7.2 is good to use
<AnAnt> LaserJock: thanks
<crimsun> \sh_away: pong, what about?
<ajmitch> morning
<crimsun> morning
<LaserJock> hi ajmitch 
<zul> hey ajmitch 
<Adri2000> hi ajmitch, can you look at http://revu.tauware.de/details.py?upid=4272 please, debdiff between 4263 and 4272 doesn't work
<ajmitch> then perhaps there were no changes made
<Adri2000> ajmitch: right, the uploader (_Enchained ;)) forgot to debuild -S before uploading
<_Enchained> catched Adri2000 ><
<_Enchained> thx Adri2000 :)
<Adri2000> now you need bddebian ;)
<ajmitch> oh excellent, samba 3.0.24
<_Enchained> ^^
<ajmitch> *just* when I need it
<ajmitch> or not..
<_Enchained> and hope that it will be accepted for feisty :)
<ajmitch> looks like it's a bugfix-only, not the 3_0_24 branch they were working ont
<ajmitch> s/ont/on/
<bigon> somebody could have a look at http://revu.tauware.de/details.py?upid=4255 ? it's a new upstream version (stable) for sylpheed
<ajmitch> bddebian will
<geser> Hi bddebian 
<bddebian> Heya gang
<bddebian> Hi ajmitch
<bddebian> I will what?
<_Enchained> hi my savior lol
<_Enchained> just an update on dvd95 which should be nice
<ajmitch> bddebian: review bigon's package (an update, not new)
<bddebian> Didn't I already review it?
<ajmitch> then if you did, and it's fine, it should have been uploaded?
<LaserJock> hi bddebian 
<ajmitch> sorry, different package, I guess
<ajmitch> hello LaserJock 
<bddebian> Heya LaserJock
<bddebian> ajmitch: It wasn't fine iirc
* ajmitch gives up & returns to other boring stuff
<bddebian> Oh, dvd95.. Hmm
<bddebian> _Enchained: After showimg finishes building I'll take a look
<bddebian> LaserJock: Did you ever get a minute to check out bibus?
<LaserJock> not yet
<LaserJock> I'm madly trying to file MIRs
<_Enchained> no pb bddebian thanks
<bddebian> Out of curiosity, what is the big advantage of having a package in main?
<ScottK> More paperwork.
<ScottK> ;-)
<bddebian> heh
<ajmitch> fame & fortune
<bddebian> double heh
<Fujitsu> Inclusion on the Great Second Edubuntu CD, perhaps?
<zul> more stress
<bddebian> Q#@$%#$5 showimg
<bddebian> _Enchained: Uploaded
<_Enchained> bddebian: thanks again.. we'll see if it's accepted this time...
<sistpoty> hi folks
<ajmitch> hey sistpoty 
<sistpoty> hi ajmitch
<bddebian> Heya sistpoty
<sistpoty> hi bddebian
<Nafallo> http://revu.tauware.de/details.py?upid=4271
<ajmitch> wow, a 0KB diff
<ajmitch> isn't that special?
<Nafallo> should have made a new orig.tar.gz though :-)
<Nafallo> I forgot to replace the symlinks with real copies :-)
* Nafallo pushes yet another mplayer bugfix
<Nafallo> -ENOFUJITSU
<bddebian> Bah, pox on merges
<_Enchained> bddebian: still here ?
<bddebian> _Enchained: Aye
<_Enchained> bddebian: for ooodi you said I should put FSF in copyright ...
<_Enchained> why this time and not in other packages ?
<bddebian> It any of the files are copyright FSF, they should be mentioned in copyright afaiui
<bddebian> Of course you ask 10 people in here you'll probably get 10 different answers
<sistpoty> well... usually you don't put *generated* files (e.g. autotools stuff like install.sh) in copyright, but regular files by FSF should imo go there
<bddebian> Aye, not generated files, true
<bddebian> But iirc there were some gettext headers or something in there, no?
<sistpoty> I didn't look at it ;)
<bddebian> Well get to it fool.. ;-P
<bddebian> j/k
<sistpoty> hehe
<_Enchained> ok bddebian
<_Enchained> I must specify which file is copyrighted by each or just list the two copyright owners (FSF and author) ?
<bddebian> Well that's a whole other debate :-)
<bddebian> Honestly I'm not positive.  To be safe you can certainly list each file and it's copyright but that can get a little cumbersome obviously.
<_Enchained> I upload ooodi in a few time (I've just listed the 2  owners)
<bddebian> Cool
#ubuntu-motu 2007-02-07
<_Enchained> uploading...
<_Enchained> bddebian: http://revu.tauware.de/details.py?upid=4275 :)
<bddebian> _Enchained: OK
<enyc> * I need to solicit more testing of qpsmtpd fix in dapper https://launchpad.net/bugs/78005 ** ;-)
<Ubugtu> Malone bug 78005 in qpsmtpd "[SRU]  request: dapper:qpsmtpd fix for bug #72602" [Undecided,Fix committed]  
<ajmitch> you'll need to find people that use it then
<enyc> * I need to solicit more testing of qpsmtpd fix in edgy https://launchpad.net/bugs/77485 ** ;-)
<Ubugtu> Malone bug 77485 in qpsmtpd "[SRU]  request: edgy:qpsmtpd fix for bug #72602" [Undecided,Fix committed]  
<enyc> ajmitch: hehehehe
<enyc> ajmitch: theres me... and theres Sheer... bah
<enyc> ajmitch: o well cant win everything ;-)
<keescook> cool.  -security updates will be showing up in the -changes lists soon.  :)
<Nafallo> scary :-P
<Nafallo> is that a feature or a bug? :-)
<ajmitch> more like expected behaviour
<keescook> well, it was intended as a feature, but evolved into a bug, I guess.
<Nafallo> I would expect them to be hidden as long as possible. or atleast until the USN :-)
<sistpoty> seems like I don't need to write the motu-swat report then :)
<Nafallo> sistpoty: :-P
<Nafallo> Fujitsu: ! :-D
<Fujitsu> Hi Nafallo.
* Fujitsu would have reenabled mp3lib if it had been noted in debian/changelog that it was disabled because it was dodgy in that version.
<Nafallo> Fujitsu: :-)
<ajmitch> hello Hobbsee 
<Hobbsee> hey ajmitch 
<rexbron> any one up for a review, check out upid 4276
<sistpoty> rexbron: give me 10 minutes, then I'll take a look
<bddebian> rexbron: I'm working on stuff, which package?
<rexbron> bddebian: soma
<Nafallo> sistpoty: http://revu.tauware.de/details.py?upid=4271
<Nafallo> bddebian: http://revu.tauware.de/details.py?upid=4271
<Nafallo> :-)
<bddebian> OK, let me get the kids to bed
<bddebian> Wait a minute, soma, wtf?? :-)
<rexbron> bddebian: ?!?
<bddebian> rexbron: I thought we were done with that one? :-)
<Nafallo> bddebian: if you take pictures of them I'll wait :-)
<rexbron> bddebian: Murrine
<rexbron> bddebian: soma is still in the works
<bddebian> Nafallo: pictures?
<Nafallo> bddebian: or photos. whichever :-P
<bddebian> Uhm, they are 7,5, and 3, what type of photos were you thinking of?
<Nafallo> just wanted to see them :-)
<bddebian> Ah, OK :-)
<sistpoty> rexbron: is soma only i386 specific?
<rexbron> I have not tested it with anything else
<rexbron> sistpoty: I do not know, I would not think so (even though I have it as i386), but am unable to test it
<rexbron> sistpoty: I will contact upstream for more info
<sistpoty> I'll do a test-compile on amd64... (don't have a i386 pbuilder at hand, and am too lazy to build in a chroot right now *g*)
<sistpoty> rexbron: there are two Makefile's in the diff... seems like you should clean these
<rexbron> sistpoty: I am unclear why the make files are different, might have built it and forgot to clean. Sugested course of action?
<rexbron> other than make clean?
<sistpoty> rexbron: maybe you could look if make clean actually cleans these... 
<Nafallo> thanks bddebian *hug*
<Nafallo> now I just need sistpotys +1 aswell ;-)
<sistpoty> Nafallo: you're next in the queue after soma ;)
<Nafallo> sistpoty: I know :-)
<sistpoty> rexbron: at least it *builds* fine on amd64
<rexbron> sistpoty: ffmpeg is not being used, it is building against the ubuntu binaries. The other makefile, I am not sure, I will diff the two and see if there are any real changes
<rexbron> sistpoty: 
<rexbron> sistpoty: then do the packages get the all architechture
<rexbron> or just i386, amd64 and ppc
<sistpoty> rexbron: make 'em any please
<rexbron> sure
<sistpoty> (all means not arch-specific)
<rexbron> sistpoty: I will upload a new version
<rexbron> bddebian: I will need you to look at soma again soon
<sistpoty> rexbron: please wait a minute, there are some more issues
<rexbron> oh ok
<bddebian> Gah, why do I bother reviewing? :-(
<sistpoty> rexbron: if you don't need the shipped ffmpeg, please remove it from the orig-tarball and add a dfsg1 to the upstream version. Otherwise soma would quite certainly get demoted to universe
<sistpoty> demoted to multiverse even
<bddebian> Nafallo: Don't get too excited, sistpoty will find all the shit I missed :-)
<sistpoty> (and I guess archive admins don't like to review ffmpeg due to patent issues *g*)
<rexbron> sistpoty: then the ffmpeg in debian copyright would be removed aswell
<sistpoty> rexbron: sure
<rexbron> anything else?
<rexbron> sistpoty: ^
<sistpoty> rexbron: give me a minute please... I'm still looking ;)
<Nafallo> bddebian: hopefully :-)
<rexbron> sistpoty: so the version would be soma_0.41-dfsg1ubuntu1? Even though it is not in debian?
<rexbron> sistpoty: or _0.410+dfsg1ubuntu1
<rexbron> sistpoty: or _0.41-0+dfsg1ubuntu1 rather
<sistpoty> rexbron: s.th. like 0.41.dfsg1-1ubuntu1
<rexbron> ok
<sistpoty> rexbron: as the dfsg-part should be part of the upstream version (and thus before the minus)
<rexbron> sistpoty: . or + between upstream and dfsg?
<sistpoty> rexbron: whatever you prefer ;)
<rexbron> ok
<sistpoty> rexbron: however not 0.41 ;)
<rexbron> opps, thats Murrine
<sistpoty> *g*
<rexbron> differnt source package
<sistpoty> rexbron: what are soma-check and soma-config for? for server-configuration?
<rexbron> sistpoty: I think so, that is the decription in control is what is given on the soma site
<rexbron> actually, that is just for the first couple 
<rexbron> sistpoty: they check the config files and allow other soma programs to configure the server, I believe
<sistpoty> rexbron: please include these in the somad package, as these are really very small packages (and otherwise would bloat the packages file)
<rexbron> I can merge them into the somad.install file
<sistpoty> rexbron: and maybe the client might suggest the server? (not sure if that makes sense though, so I'll leave that to you)
<rexbron> the client is the command line interface to the server, so it maybe should depend?
<rexbron> or recommends, as they are installed by default
<sistpoty> rexbron: so I'd pretty much need the client to use the server?
<rexbron> I think so
<rexbron> its the interface to the server daemon
<rexbron> sistpoty: ^
<sistpoty> rexbron: then I'd say to simply include this one in the somad package... if it doesn't make much sense to have the server without the "client"
<sistpoty> (actually I've guessed that client means s.th. different here...)
* bddebian bows his head in shame
<rexbron> ok I think that would work, should the binary package be renamed then to just soma, or maybe soma-server (as there is a soma-player)
<sistpoty> bddebian: why?
<sistpoty> rexbron: not quite sure... moment please
<bddebian> Because I suck
<sistpoty> bddebian: no, you don't :P
<bddebian> sistpoty: Sure I do, ask ajmitch :-)
<sistpoty> hrhr
<sistpoty> rexbron: actually choose what name you prefer... both make sense to me
<rexbron> I am going with server for consistency
<sistpoty> ok
<rexbron> sistpoty: anything more that you can see?
<sistpoty> rexbron: nope... others than that the package is really lovely
<rexbron> yay
* rexbron goes to fix fix fix
<aSt3raL_> hello
<rexbron> sistpoty: Would you be able to examine it again in about 1/2h?
<aSt3raL_> what do you guys need help with?
<sistpoty> rexbron: not quite sure if I'm still up then... in case I'm asleep already I'll promise to look at it tomorrow though
<aSt3raL_> ive been using ubuntu for a couple years and am interested in helping
<sistpoty> aSt3raL_: we need help with everything... from triaging bugs, to making new packages to getting our documentation in a better shape
* sistpoty searches the link to the contribute page
<sistpoty> aSt3raL_: have you read https://wiki.ubuntu.com/ContributeToUbuntu yet?
<aSt3raL_> i have not
<sistpoty> aSt3raL_: please do... it should give you a first overview ;)
<sistpoty> Nafallo: please don't exceed 80 chars in debian/copyright... this is really hard to read ;)
<sistpoty> Nafallo: the descriptions/extended descriptions could be a little bit more verbose... what will I get from the different wave-look packages? usplash-images? wallpapers? sounds? anything else?
<Nafallo> sistpoty: doesn't the short description say? :-)
<sistpoty> Nafallo: well, it could be more verbose ;)
<Nafallo> and the packagenames are straightforward aswell :-)
<Nafallo> IMO :-)
<sistpoty> Nafallo: I guess the average user wouldn't figure that splashes are bootup screen splashes
<sistpoty> Nafallo: but that's not a showstopper for me ;)
<Nafallo> hehe, the package is actually a fork from the other artwork packages, so I'll just blame dholbach anyway :-)
* Nafallo reformats debian/copyright
<Nafallo> sistpoty: is it +1 without extra review with the reformat I'm making? or do you see something else? :-)
<sistpoty> Nafallo: actually I'd like to see it as either a native package or bug upstream to remove the debian-dir ;)
<sistpoty> :P
<Nafallo> dooh
<Nafallo> I know I forgot something ;-)
<sistpoty> Nafallo: gives a PITA if someone wants actually remove a file from the debian-dir otherwise
<Nafallo> the upstream packager will fix that before he uploads it to the archive :-)
<Nafallo> ;-)
<sistpoty> Nafallo: ok, then take this +1 and use it once you have fixed the issues ;)
<Nafallo> sistpoty: thanks dude *hugs*
<sistpoty> Nafallo: thanks for your contribution ;)
<Nafallo> *grins*
* bddebian goes back to his hole
* Fujitsu sends the dogs down the hole.
<rexbron> sistpoty: should the modified tarball have the dfsg versioning aswell?
<sistpoty> rexbron: yes, it should... because it's not the original tarball but something different
<rexbron> ok cool
<sistpoty> (that's the reason I wanted the dfsg to be part of the upstream version)
<rexbron> I see
* sistpoty is out for a cigarette
<sistpoty> ok, I'm off to bed now
<sistpoty> gn8 everyone
<Nafallo> sistpoty: gnight
<LaserJock> man, gotta love spam warning about spam/viruses/spybots
<TheMuso> LaserJock: heh
<rexbron> LaserJock: Would you be able to do a review? upid 4279
<TheMuso> rexbron: I am doing a test build now. There is something I want to make sure of before saying anything, as I haven't had much to do with cdbs previously.
<rexbron> TheMuso: cool
* TheMuso waits for packages to be fetched.
<rexbron> TheMuso: how goes it?
<TheMuso> its built, but I'm just checking something first
<TheMuso> ok no what I was looking for seems to be taken care of by cdbs.
<TheMuso> rexbron: What are you worried about re changelog?
<TheMuso> And there is a dfsg in the changelog entry. What was removed?
<rexbron> too many entries
<rexbron> TheMuso: ffmpeg
<rexbron> TheMuso: it is using ubuntu binaries 
<rexbron> TheMuso: Should the dfsg change be listed?
<TheMuso> In the new entry, it is probably worth stating that ffmpeg was removed, and the Ubuntu binaries used. Other MOTUs may be able to ffer comment on that however.
<rexbron> TheMuso: Found anything else?
<TheMuso> But having two entries is fine, as they are for different releases.
<TheMuso> rexbron: Looking again. Was just checking that the later version was greater than the former in the changelog.
<rexbron> hmm?
<TheMuso> dpkg has a command that allows you to compare whether one version number is greater than another.
<rexbron> ok
<TheMuso> I don't understand why your copyright file is layed out as it is. I'd rather leave those more experienced with licensing to confirm that.
<rexbron> TheMuso: LaserJock directed me to do it like that
<rexbron> so I will run it by him to make sure is it up to snuff
<rexbron> but you are suposed to list the licence and copyright of everyfile that is distributed in the source package
<TheMuso> rexbron: I know that.
<TheMuso> Most other copyright files I've seen have been simpler than that, thats all.
<LaserJock> what did I do?
<rexbron> LaserJock: just the debian/copyright file for Soma
<TheMuso> Shouldn't the libsoma-dev be in section libdevel?
<rexbron> at sisypot's direction, ffmpeg was removed from the upstream tar ball and dfsg versioning was added
<rexbron> TheMuso: was not sure,
<rexbron> you would know better than I
<TheMuso> hmm maybe not
<rexbron> it is the devel files for a lib, but the source package is for a program
<rexbron> if that makes a difference
<TheMuso> I don't think it matters.
<rexbron> LaserJock: what is your take on the above?
<TheMuso> I have just looked at two other packages. One has libdevel, one has devel.
<TheMuso> SO I don't *think* it matters.
* TheMuso goes to check policy.
<TheMuso> I haven't looked very hard, but libdevel is a valid section so I dunno.
<TheMuso> Other packages use it, so it shouldn't be a problem
<TheMuso> rexbron: Any reason for the binary/clean target in debian/rules?
<rexbron> so it should not be a problem either way>
<TheMuso> No.
<rexbron> TheMuso: sometimes config.log does not get removed, and that can gum up the build
<rexbron> but if it is in pbuilder, should be unnessicary now
<TheMuso> According to the rules file, its config.status you are removing.
<rexbron> ..
<rexbron> that is old
<rexbron> need to fix that
<TheMuso> Why aren't you building the python stuff?
<rexbron> really buggy build process
<TheMuso> How so?
<rexbron> like to try and install itself on the system instead of following any prefixes
<rexbron> same with phpsoma
<rexbron> I have contacted upstream about it and it is getting fixed in the next major release
<rexbron> TheMuso: ok, the binary rules is fixed, and so is libsoma-dev's section
<LaserJock> build and clean are required rules
<rexbron> LaserJock: cdbs
<TheMuso> LaserJock: Cdbs takes care of those I thought
<LaserJock> ah, it's cdbs
<LaserJock> my bad
<rexbron> np
<TheMuso> rexbron: The section for the dev package doesn't have to be libdevel as far as I have seen from other apckages.
<rexbron> is there any reason not to?
<rexbron> ( as I will need to reupload any way
<TheMuso> Well some major libraries for the syste are libdevel, so I guess its a good idea to use it.
* TheMuso just checked libc6-dev and libgnomeui-dev to see what they had,.
<rexbron> if there is an issue, it will be fixed
<TheMuso> Well you changed to libdevel so I think you're safe.
<TheMuso> ooo storm coming.
<rexbron> :0
<rexbron> TheMuso: 
<rexbron> TheMuso: So if I re-upload, and the debdiff is good, is there a stamp of approval?
<TheMuso> Re-upload and I'll have a look at the differences.
<rexbron> TheMuso: I need sleep, the upload is done
<rexbron> so if there are issues, just leave a nice comment
<TheMuso> rexbron: SUre.
<LaserJock> is there still no website for falcon?
<TheMuso> Bah! I am not finding revu very intuative. I've managed to place comments on the wrong date every bloody time!
<TheMuso> SOrry those on the revu ml. I'll know better for next time. grrr :S
<\sh> moins
<\sh> geser: ping xmms2 again, do you think debian/rules should execute scons in clean target? 
<zakame> good afternoon MOTUs
<TheMuso> Hey zakame.
<zakame> hello TheMuso
<\sh> hey zakame
<zakame> hello \sh!
<\sh> moins raphink
<raphink> hi \sh :)
<raphink> how are you doing today \sh ?
<\sh> raphink: well, I was early in the office...and right now, I'm fighting against tickets and broken hardware :(
<\sh> and until now no coffee
<raphink> :(
<raphink> I'm going to have another day fighting with backports here ;)
<raphink> but thanks to buildd, it won't be that long :)
<raphink> hi phanatic
<phanatic> morning raphink 
<raphink> :)
<raphink> what's up?
<zakame> yo raphink phanatic dholbach
<zakame> what are you guys down with? :)
<raphink> hi dholbach zakame
<dholbach> good morning
<dholbach> hey zakame
* raphink shakes hands all around
<dholbach> hey raphink
<phanatic> hey zakame and dholbach
<ajmitch> hi dholbach, everyone
<zakame> yo ajmitch
<ajmitch> hey zakame 
<phanatic> raphink: just got back from the bazaar sprint in amsterdam :)
<raphink> oh really?
<raphink> I didn't know about this one :)
<raphink> I was in A'dam 2 days ago :)
<raphink> got back on Sunday evening
<dholbach> hey ajmitch
<raphink> hi ajmitch :)
<phanatic> raphink: heh, i got back on Monday evening... funny :)
<raphink> yes :)
<raphink> I almost got back on Monday 
<raphink> but I thought it would be better to keep my vacation for later :)
<phanatic> :)
<phanatic> i also have to work now, and university starts next week
<raphink> ok
<phanatic> i just dist-upgraded to feisty... had long time without development versions :)
<raphink> hehe
<RAOF> Is anyone around to review http://revu.tauware.de/details.py?upid=4132 ?
<RAOF> I'm not the uploader, but I'd really like to get that into Feisty, if at all possible.
<RAOF> I should have a REVU account.  Can I help?
<raphink> you sure can help
<raphink> you can review the package and send me the comments
<raphink> I'll publish them
<dholbach> didn't somebody have a pimped, updated html version of 'apt-cache -i unmet' somewhere?
<dholbach> it should be linked from from MOTUTodo
<Hobbsee> dholbach: i thought the people submitted bugs for that
<dholbach> oh, hm
* ajmitch was going to do a pimped up version
<dholbach> maybe i could hack bughelper to find if a certain bug has already been filed
<dholbach> that way we could automate the process of filing bugs
* dholbach will think about it
* ajmitch wonders why his sound is completely broken this evening
<cyberixae> Does the requested packages go trought some proces?
<cyberixae> Or do they just sit on the wiki?
<Hobbsee> cyberixae: they sit on the wiki until someone looks at it, thinks it looks interesting, and packages it.
<ajmitch> hm, that could be why sound is going nuts
<ajmitch> fan warning when I went to reboot..
<ajmitch> curses, dead fan on the motherboard
<Hobbsee> heh
<Hobbsee> oh dear
<ajmitch> yeah, well
<StevenK> ajmitch: On the north bridge?
<TheMuso> May need a good clean.
* ajmitch shrugs
<ajmitch> probably
<StevenK> Most north bridges don't run hot enough for a fan.
<tepsipakki> ajmitch: just replace it with a passive heatsink ;)
<StevenK> There are exceptions. :-)
<ajmitch> hm, I think it could be the southbridge
<ajmitch> it's an amd64 anyway
<StevenK> The {north,south}bridge on my amd64 is passively cooled.
<ajmitch> well it was causing enough problems with sound :)
<StevenK> Then again, it's a *tiny* SFF case with an enormous CPU fan and good air flow. :-)
<ajmitch> yeah, this is a fulltower case
<ajmitch> and it's fairly warm in here at the moment
<StevenK> Heh
* ajmitch is just on the laptop
* StevenK loves the quiet fan
<ajmitch> I was wondering, the motherboard temperature was slightly higher than usual 
* ajmitch has sensors-applet on the panel now, using hddtemp 
* StevenK hasn't bothered with temperature sensing.
<ajmitch> I was curious
* ajmitch goes to boot it & see if the fan spins up
<ajmitch> what a pain, it hasn't
<StevenK> ajmitch: I'd clean it, like TheMuso suggested.
<StevenK> Blasting it with compressed air if you have some handy may well help.
<ajmitch> I don't have any on hand
<ajmitch> & I usually wouldn't expect the fan to stop dead
<StevenK> Most fans are very simple. :-)
<ajmitch> quite :)
* Fujitsu looks for somebody to poke about Zope 3 being broken due to an old twisted-web2.
<ajmitch> oh zope
* ajmitch hides
<Fujitsu> Yeah.
<Fujitsu> I was thinking of you.
<Fujitsu> :P
<Fujitsu> Unfortunately, there's no new release, but Twisted 2.5 breaks it.
<Fujitsu> So, we either have broken Zope, or assemble a SVN HEAD web2, somehow.
<ajmitch> breaks in what way?
<Fujitsu> The release tarball doesn't seem to bear any resemblance to the stuff that's in SVN; it's got a fair bit of extra stuff in the root.
<Fujitsu> Er, Zope won't start...
* Fujitsu hunts the bug.
<Fujitsu> Bug #83053
<Ubugtu> Malone bug 83053 in twisted-web2 "AttributeError: components.Interface" [High,Confirmed]  https://launchpad.net/bugs/83053
<Fujitsu> I ran into it a while ago.
<ajmitch> right, so it's a nice chain of brokenness
<Fujitsu> Sorta.
* ajmitch wonders who put 2.5 in ubuntu
<Fujitsu> Basically, everything is solved if we get a new web2.
<Fujitsu> I don't know, but it wasn't overly sane.
<ajmitch> oh, doko did
<Fujitsu> (and web2 is in main... aren't we getting rather close to ultimate-freeze?)
<ajmitch> python 2.5 compatibility
<Fujitsu> OK.
<Fujitsu> A little more sane, then.
<ajmitch> but a new web2 isn't really out, and will it still work with zope?
<ajmitch> doko is also the twisted-web2 maintainer for debian
<Fujitsu> Ah, so it's doko's problem. Goodo.
<Fujitsu> It might work, but I'm not sure.
<ajmitch> yep
* ajmitch confesses to not having used zope3 on feisty for awhile
<doko> Fujitsu: no, zope3 doesn't work with 2.5
<Fujitsu> Crap.
<Fujitsu> That's not what I wanted to hear.
<ajmitch> hi doko 
<Fujitsu> (it wasn't a great first impression when I tried to start Zope for the first time a week ago, and I got that :-/)
<ajmitch> what were you playing with zope for?
<Fujitsu> Why not?
<ajmitch> because it requires a large non-refundable investment of time & sanity
<Fujitsu> Pfft.
<Fujitsu> doko: Is the incompatibility likely to be fixed in the near future?
<ajmitch> good fun though
<Fujitsu> That's what I thought.
<doko> zope doesnt adopt new python versions very fast
<Fujitsu> I
<Fujitsu> *I'll take that as a no, then :(
* ajmitch hopes that his box will stay stable enough with a dead fan
<TheMuso> ajmitch: SO its dead dead.
<Fujitsu> siretart: I note that you have a million and one branches on the mplayer product. Can you please set the ones that have been merged into ubuntu to Merged, etc?
<ajmitch> TheMuso: well it's not spinning
<TheMuso> right
<ajmitch> ugh, someone had to add NM to ubuntu-desktop
<ajmitch> now it claims I have no network, and so certain apps won't connect
<Fujitsu> Ah, finally.
<siretart> Fujitsu: I haven't done an mplayer upload since ages, you should ask Nafallo
<Fujitsu> ... It's good except for cases like that :P
<Fujitsu> siretart, but you own the branches.
<Fujitsu> They're merged, but still have status New.
<Fujitsu> You are the only one with permissions to change the status on your branches.
<ajmitch> of course there's no obvious way to configure NM
<siretart> don't expect random user branches to be authoritative
<Fujitsu> ajmitch, configuration? What configuration?
<siretart> Fujitsu: I do think we should have a motumedia mplayer team branch, which is authoritative
<ajmitch> Fujitsu: the bits that make things go
<Fujitsu> siretart, but it's useful to minimise clutter on the page.
<siretart> Fujitsu: if there isn't one, let's please create one
<siretart> Fujitsu: right. Is there a way to remove branches from launchpad?
<Fujitsu> siretart, the ubuntu-dev one is authoritative.
<Fujitsu> No, but they will vanish from the main list if set to Merged/Abandoned.
<siretart> interesting. will do so then, after we have an authoritiatvive one
<Fujitsu> We do.
<Fujitsu> ~ubuntu-dev/ubuntu.
<siretart> oh
* siretart rechecks
<Fujitsu> (but they're already merged, so you simply need to modify the status field on yours that have been merged)
<siretart> aah, abandoned branches don't show up in the list. interesting
<Fujitsu> (they should actually be Merged, but they achieve similar things)
<siretart> Fujitsu: do you use bzr-builddeb for building?
<Fujitsu> I don't, no.
<Fujitsu> I've not looked at it.
<Fujitsu> Thanks for doing that, the list is somewhat cleaner now.
<siretart> Fujitsu: I changed the maintainer of the mplayer lp product to motumedia
<Fujitsu> siretart, I was also going to suggest that :)
<Nafallo> siretart: I do
<Nafallo> siretart: it rocks :-)
<siretart> Fujitsu: http://bazaar.launchpad.net/~ubuntu-dev/mplayer/upstream-ubuntu does not seem to contain the packaging branch for mplayer since it doesn't contain any debian/ dir. don't we have some branch which has it?
<siretart> Nafallo: :)
<Fujitsu> siretart, ~ubuntu-dev/mplayer/ubuntu does.
<Fujitsu> upstream-ubuntu is the stripped upstream archive.
<siretart> k
<siretart> Fujitsu: welcome to motumedia :)
<RAOF_> raphink: I've uploaded a new gnome-compiz-manager with manpages. http://revu.tauware.de/details.py?upid=4281
<RAOF_> Since I didn't add my name to the changelog, it seems REVU won't let me comment on that upload.  Should I have added a changelog entry?
<Adri2000> RAOF: no, use dput -f
<Adri2000> RAOF_: ^
<RAOF_> Adri2000: It's already on REVU, though, and the packaging was done by someone else.
<Adri2000> well yes, sorry, I can't read...
<RAOF_> I just added manpages, and fixed the build-dep version on debhelper, so my name isn't on the changelog :)
<RAOF_> Although, if you can, I'd love you to review & advocate it :)
<Adri2000> I'm not sure to understand, it's a NEW package, right? ie. not yet in debian or in ubuntu
* Hobbsee wonders why Adri2000 doesnt understand
<Hobbsee> RAOF_: yes, that's normal
<Hobbsee> RAOF_: if you're not the guy in the changelog, or not a MOTU, you wont be able to respond in the package in REVU.  oh wait.  are you logged in?
<RAOF_> Yes, I'm logged in.
<Hobbsee> Adri2000: can just anyone who's signed in respond to any package on REVU?
<ajmitch> no
* Hobbsee suspects you know more than she does
<Hobbsee> didnt think so.
<RAOF_> Only MOTU.
<RAOF_> Uploaders get to respond to their own uploads, as long as they have their name on the changelog, apparently :)
<Adri2000> I see the last upload is from gandalfn@club-internet.fr, and it doesn't seem to be you RAOF_
<RAOF_> Adri2000: But the current debdiff has the manpages I wrote in them.
<Adri2000> ohh, I understand now
<RAOF_> Down the bottom, upload as of feb 07
<RAOF_> :)
<RAOF_> Should I have added my name somewhere official?  Or is it ok?
<Adri2000> in fact, we can't see if an upload has really been made by the user mentioned at the top of the page ("from user ...") :s
<Adri2000> is it right ajmitch?
<ajmitch> obviously not, since it only goes on the changelog, not the signature
* ajmitch needs to sleep
<RAOF_> There's nothing else I can do to help it along, is there?
<RAOF_> I can get some sleep, too?
<ajmitch> generally if you upload it to REVU, you take responsibility to fix it up as we suggest
<RAOF_> Certainly.
<ajmitch> night all
<RAOF_> Is anyone likely to suggest things for me to fix in the next 8 hours? :)
<Hobbsee> night ajmitch 
<RAOF_> night, and thanks ajmitch
<Adri2000> RAOF_: during the REVU sprint probably (beginning tomorrow): https://lists.ubuntu.com/archives/ubuntu-motu/2007-February/001253.html
<RAOF_> Oh, excellent.  See you on here tomorrow, then.
* RAOF_ wonders if it's still today where Adri2000 is
<Adri2000> yep, here it's today 2 pm
<RAOF_> Oh, where as here it's tomorrow 12:30 am.  Probably time to bail.
<rexbron> TheMuso: Soma: Fixed and reuploaded
<davromaniak> ping slomo 
<esaym> How hard would it be for a newbie to make a package to upgrade amarok to the lastest version?
<esaym> I have compiled software before but I have not ever made packages
<esaym> I would like to give it a shot
<Adri2000> esaym: it is already the latest version
<slomo> davromaniak: pong
<davromaniak> slomo, I packaged youtranslate, and it's in mono, and some people told me that you know mono
<esaym> version 1.4.5 has been out awhile
<slomo> davromaniak: yes so if you know packaging in general read http://pkg-mono.alioth.debian.org/cli-policy/
<esaym> and kubuntu is still at 1.4.3
<esaym> instead of bitching about it I figured I would try and update it.....
<Adri2000> esaym: amarok | 2:1.4.5-0ubuntu2 | http://archive.ubuntu.com feisty/main Packages
<davromaniak> I read it, and I think my package respects this policy, and I ask you to review it, when you will have some stare time
<esaym> yes but will that work in dapper?
<Adri2000> esaym: there won't be any new upstream version in stable releases (breezy, dapper, edgy)
<davromaniak> hmmm, spare time
<esaym> so even if I made a package it would not be used?
<Adri2000> esaym: there are packages available for edgy: http://kubuntu.org/announcements/amarok-1.4.5.php (but not officially supported) made by Riddell (kubuntu developer)
<esaym> Adri2000? anyone?
<esaym> oh hmm
<davromaniak> so slomo, here a link : http://revu.tauware.de/details.py?upid=4144
<slomo> davromaniak: sure send me a mail with the url to slomo@ubuntu.com... bbl
<davromaniak> ok  thanks
<bddebian> Heya gang
<raphink> hi bddebian
<bddebian> Heya raphink
<esaym> is there a 100% noob guide to making kubuntu packages?
<_Enchained> Hi motus :)
<raphink> imbrandon: just saw that you added dh_iconcache to the j2se1.4-amd64 package but you didn't upgrade the debhelper version (dh_iconcache is for debhelper5 only)
<raphink> hmm well I'll fix it
<bddebian> Heya _Enchained
<raphink> it'll be faster :)
<raphink> hi ivoks :)
<_Enchained> bddebian: a little question :
<_Enchained> In dvd95 (that you have advocate), there was a debian/ folder in the "real" orig.tar.gz
<bddebian> Yes
<_Enchained> I've removed it from my orig.tar.gz and wrote it in changelog
<_Enchained> After emailing upstream,
<bddebian> OK
<_Enchained> He send me a corrected tarball
<_Enchained> without this useless folder
<_Enchained> and will update it on sourceforge
<_Enchained> so should I remake the package ?
<_Enchained> as the changelog is not the true (now)
<_Enchained> or it's ok..
<_Enchained> (I hope you understood the question^^)
<raphink> esaym: did you read the ubuntu packaging guide?
<bddebian> _Enchained: Ideally you should re-build with the new tarball
<esaym> I am reading the debian one
<esaym> which one are you talking about raphink
<_Enchained> ok bddebian (in fact I have just to remove the comment about modified tarball in changelog...)
<raphink> esaym: the one that is on http://help.ubuntu.com 
<raphink> esaym: which was written because the debian one is too complicate for most people
<esaym> raphink: no I didn't see that one
<esaym> thank you
<raphink> well now you know it ;)
<esaym> the debain one is kinda over my head ;)
<raphink> it's also included in Ubuntu/Kubuntu
<raphink> locally
<raphink> esaym: yes it's not very easy, eventually you might ask a mentor to help you, too
<esaym> yea I keep forgetting about that
<esaym> I hope to update some apps on dapper which is no longer really being supported
<esaym> as far as bug fixes
<raphink> well dapper is frozen
<raphink> so it's normal for it to not be updated so much
<esaym> yes I think thats kinda crappy
<raphink> why ?
<esaym> Well there are still plenty of bugs in it
<esaym> I don't think they should just leave it like that
<raphink> what do you propose ?
<raphink> to update with newer versions of packages?
<raphink> or to include patches to fix each bug?
<esaym> I don't want to have to do a massive upgrade every six months to get updated software
<raphink> there are security updates for dapper
<raphink> and normal updates, too
<raphink> but not for every little bug
<esaym> amarok has a couple of bugs in it that have been fixed in the lastest version
<raphink> otherwise we would spend all our time taking care of dapper
<raphink> instead of developping fesity
<raphink> feisty
<esaym> Yes I know
<_Enchained> bddebian: dvd95 with the new orig tarball is incoming
<raphink> esaym: can you add a patch to fix the bugs without having to backport amarok?
<bddebian> _Enchained: OK
<raphink> if you need the latest version of amarok, use the backports
<raphink> I'm sure it's there
<esaym> I don't know what to do hence why I decided to try making my own packages because I like dapper and don't want to upgrade
<esaym> There is nothing in the backports for dapper for amarok
<esaym> amarok backport for dapper is version 1.4.3, the same that was already installed
<raphink> amarok engines are backported
<esaym> amarok-engines (2:1.4.3-0ubuntu8~dapper1??
<esaym> still says 1.4.3
<raphink> the whole point of having a frozen release is that packages are _frozen_
<raphink> if you want amarok 1.4.5 for dapper
<raphink> you can try backporting it
<raphink> just set a dapper pbuilder and rebuild it :)
<esaym> how would I go about that?
<raphink> there's a doc on the wiki to set pbuilders :)
<esaym> hmm
<_Enchained> bddebian: it's ok http://revu.tauware.de/details.py?upid=4286
<raphink> https://wiki.ubuntu.com/PbuilderHowto
<raphink> esaym: look at this page, set a pbuilder (which you will need to make and test packages anyway)
<raphink> and backport amarok for dapper :)
<raphink> and soon you'll understand why we don't do it :)
<raphink> (backporting is kind of my job, I'm currently backporting tomcat5 for sarge, and it's not fun, trust me ;) )
<esaym> lol is it buggy or something?
<raphink> esaym: programs in GNU/Linux use shared libraries
<raphink> new programs use new libraries
<esaym> yea sounds like a mess
<raphink> very often, when you need to backport a program, it depends on new libraries
<raphink> that are not in the old version of the distro
<esaym> I was wondering about that
<raphink> so you have to backport these new libraries
<raphink> and then you have to set a limit to what you backport
<raphink> in order to 
<esaym> thats was why I wanted to build the lastest version from source and make a package
<raphink> 1) not spend more time on it than you should
<raphink> 2) not break other apps depending on these libs
<raphink> currently, i'm rebuilding tomcat5 for sarge
<raphink> and I'm already at the 3rd level of backports
<esaym> sounds like it would just be easier to make a package from the source?
<raphink> since tomcat5 build-depends on java-gcj-compat-dev which itself depends on  gcj-4.1
<raphink> and none of these are in sarge
<raphink> now in some cases
<raphink> for example, valgrind for amd64
<raphink> you just can't do it
<raphink> valgrind for amd64 requires a new gcc lib to build
<raphink> and it's not reasonable to backport the toolchain
<raphink> esaym: I'm talking about making a package from the source
<raphink> not about anything else
<esaym> hmm
<raphink> new programs depend on new libraries, new compilers, and so on
<esaym> Yea I got that
<raphink> backporting is not the easiest thing ever ;)
<raphink> but it's fun :)
<esaym> I thought backporting = taking an already built package for another distro and making it work for an older distro?
<raphink> yes exactly
<esaym> well then what is making a package from source?
<raphink> if you have a hard time seeing the problem with software, try to think about hardware maybe
<raphink> say you want to add some new RAM to your machine
<raphink> but in order to do that
<raphink> you need to upgrade your motherboard
<raphink> but then your CPU is too old and you have to change it
<esaym> Yes I understand the dependencies
<raphink> well that's about it
<esaym> Thats why I don't use Slackware... ;)
<raphink> dependencies can make backports a mess
<esaym> I dont get how you say backporting and biulding from source are the same thing though?
<raphink> all packages in Ubuntu are built from source
<raphink> hmm except for non open-source ones
<raphink> ;)
<esaym> I guess I am just really lost
<esaym> I got to get to class
<esaym> I am late
<raphink> ok
<raphink> see you later :)
<esaym> I will try and catch you later on
<\sh> re moins
<bddebian> wb \sh
<raphink> hi \sh
<\sh> guys, if you want to have a nice hardware in your DC, checkout the new HP BL35-c class blade series ;)
<raphink> :)
<Le-Chuck_ITA> Hi all, What is REVU?
<Le-Chuck_ITA> https://wiki.ubuntu.com/REVU2Spec
<Le-Chuck_ITA> looks interesting
<Le-Chuck_ITA> so if I sign my name there I will be enabled to fix bugs myself and, with successful review, these patches will be applied directly? And to which distribution?
<Le-Chuck_ITA> and why am I talking alone? :)
<dholbach> hey Le-Chuck_ITA
<dholbach> if you are talking about getting patches / packages uploaded to Ubuntu, you might want to refer to https://wiki.ubuntu.com/SponsorshipProcess
<Le-Chuck_ITA> Hi! You confirmed a bug of mine recently so I am happy to meet you
<dholbach> :)
<Le-Chuck_ITA> no I am talking of something like fixing a small bug in a forgotten universe package
<dholbach> yeah, that's what I talk about also :)
<Le-Chuck_ITA> and getting that uploaded so that successive upgrades will not delete my fix
<dholbach> right
<dholbach> the process is outlined in the wiki page I mentioned
<Le-Chuck_ITA> isn't sponsorship for new packages only?
<dholbach> no
<Le-Chuck_ITA> and what is revu for, then?
<dholbach> uploading a source package for somebody who's not in ubuntu-dev or ubuntu-core-dev  =  sponsoring an upload
<Le-Chuck_ITA> ok
<dholbach> we use revu for NEW packages and sometimes for package updates
<dholbach> if you have a small fix, attaching the debdiff to a launchpad bug is more intuitive
<Le-Chuck_ITA> yes but if the package has no maintainer nobody will ever fix
<dholbach> that's why you subscribe a sponsor team to the bug
<dholbach> if you read the document you'll see that it makes sense
<Le-Chuck_ITA> ah ok just reading it now
<dholbach> ok
<Le-Chuck_ITA> yes it makes sense
<dholbach> ok cool :)
<Le-Chuck_ITA> will there be any lesson on how to properly create a debdiff or will I always have to stick with the debian-related "official" document? E.g. to know what "DEBEMAIL" is
<Le-Chuck_ITA> for
<Le-Chuck_ITA> Yes this is a request for a lesson :)
<Le-Chuck_ITA> ok this is asking too much
<Le-Chuck_ITA> my last question is:
<Le-Chuck_ITA> suppose that upstream released two major versions since the version in feisty of a package
<Le-Chuck_ITA> and the package is in debian
<Le-Chuck_ITA> how will I ever get the new version  in feisty? Should I bug debian first?
<_Enchained> bddebian: dvd95 is uploaded ? I don't see it on revu (the new "clean")
<bddebian> _Enchained: Aye, I uploaded it again
<Le-Chuck_ITA> of a universe package, of course
<dholbach> Le-Chuck_ITA: a normal diff is fine too
<_Enchained> bddebian: it's ok (I've just changed the changelog)
<Le-Chuck_ITA> this is for the debdiff issue, I see - but what about getting new versions of universe packages in ubuntu?
<dholbach> Le-Chuck_ITA: for a debdiff you: dch -i (create a new changelog entry), run debuild -S (create a new source package), run: debdiff bla1.dsc bla2.dsc > bla.debdiff and attach the debdiff to the bug
<dholbach> Le-Chuck_ITA: for that we use REVU
<dholbach> http://wiki.ubuntu.com/REVU should have more information about that
<Le-Chuck_ITA> so I can upload a new upstream version of an existing package to REVU and have somebody look at it?
<Le-Chuck_ITA> this is great information
<Le-Chuck_ITA> for me at least .)
<dholbach> yeah :)
<dholbach> cool :)
<Le-Chuck_ITA> I finally have a goal
* dholbach high-fives Le-Chuck_ITA
<Le-Chuck_ITA> :) :)
<Le-Chuck_ITA> and - well I promised that was my last question - should then the changes merged to debian unstable?
<dholbach> if you have a interest in the package, it's a very good thing to build a good communication channel with the debian maintainer
<dholbach> and sending patches is a very good way to do that :)
<Le-Chuck_ITA> ok I understand - so there is no problem in having a newer version in ubuntu than in debian, but one usually sends patches to the debian maintainer so that versions can be kept in sync
<geser> Le-Chuck_ITA: are you wanting to get a new upstream version of a package into Ubuntu or just bugfixes to the current one?
<Le-Chuck_ITA> two different issues
<Le-Chuck_ITA> one is lyx, another one is xournal, but there are others on my todo list
<Le-Chuck_ITA> lyx needs a fix, xournal newer version after I test that 
<Le-Chuck_ITA> I use them both a lot of hours per day and feel like I can improve their situation in ubuntu, that's all
<geser> just to let you know: tomorrow is UVF (UpstreamVersionFreeze): no new upstream version are allowed anymore
<Le-Chuck_ITA> hmmm
<Le-Chuck_ITA> the best I could do for today is to post a ordinary diff between new package of xournal (I downloaded it right now)
<Le-Chuck_ITA> but would it get any chance of being uploaded for tomorrow?
<geser> it depends if you find someone to review your changes and do the upload
<Le-Chuck_ITA> my changes will be the patch to the sources so it would be a big review
<Le-Chuck_ITA> hem
<Le-Chuck_ITA> ehm
<Le-Chuck_ITA> I mean: my changes will be the diff between xournal 0.3.1 and xournal 0.3.3
<Le-Chuck_ITA> so I don't expect anybody review upstream code
<geser> more important are the fixes for the packaging (if needed)
<Le-Chuck_ITA> I hope there is none of them
<geser> s/fixes/changes/ :)
<Le-Chuck_ITA> getting debian source right now
<Le-Chuck_ITA> er
<Le-Chuck_ITA> s/debian/ubuntu
<geser> doesn't make a difference as the source package is the same
<Le-Chuck_ITA> yes I know :)
<\sh> hmmm..anyone tried aixgl with normal radeo drivers on feisty?
<highvoltage> video killed the radeo star
<jharr> what does everyone recommend for a patch manager?
<hub> jharr: what do you mean?
<LaserJock> jharr: if you're using debhelper I'd go with dpatch, for cdbs I'd go with simple-patch-sys or whatever it's called
<Adri2000> simple-patchsys :)
<Adri2000> .mk
<jharr> is there any disadvantage to using cdbs? (I'm guessing there's some limitations to it)
<hub> jharr: for standard packages, none
<hub> jharr: beside the fact that lot of debian packager don't like it
<Le-Chuck_ITA> what decides the version of a debian package when building a package?
<Le-Chuck_ITA> I mean when packing the source with dpkg-source
<Le-Chuck_ITA> I can't find any reference to the version in debian/control or other files
<Le-Chuck_ITA> is it just the .orig file name?
<Le-Chuck_ITA> that gives the version?
<LaserJock> debian/changelog
<Le-Chuck_ITA> ok and how do I generate that since it seems that by hand it is not so good (there is the date for example)?
<bddebian> dch -i
<Le-Chuck_ITA> oh thanks 
<bddebian> From the src dir not the src/debian dir btw :-)
<LaserJock> hm?
<LaserJock> you can run dch from debian/
<bddebian> You can?
<bddebian> hmm
<Le-Chuck_ITA> last version is 0.3.1-2
<Le-Chuck_ITA> new upstream version is 0.3.3
<Le-Chuck_ITA> what do I write? 0.3.3-1?
<Le-Chuck_ITA> sorry for bothering with all this newbieness
<LaserJock> that would be what the Debian version would be
<LaserJock> since we need to keep the ability to sync/merge between Debian and Ubuntu
<LaserJock> we use special versioning if we modify a package
<LaserJock> if 0.3.3 isn't in Debian yet you would do 0.3.3-0ubuntu1
<Le-Chuck_ITA> ok
<LaserJock> the 0 is for the Debian revision, in this case it's not there yet so it's 0
<Le-Chuck_ITA> perfect
<Le-Chuck_ITA> and the 1 after ubuntu?
<LaserJock> yeah
<LaserJock> that's the 1st revision in ubuntu
<LaserJock> if we needed to fix something say in the packaging we would go to 0.3.3-0ubuntu2
<Le-Chuck_ITA> ok
<Le-Chuck_ITA> oh, and the original source needs autogen.sh to be run
<Le-Chuck_ITA> the debian source does not
<Le-Chuck_ITA> will I upload orig.tar.gz
<Le-Chuck_ITA> with the configure script already present?
<LaserJock> do it the way debian does it
<LaserJock> are we basically done with merge/sync ?
<LaserJock> we've got 12/42 for merges/updated merges on MoM
<bddebian> A lot of the merges left cannot be done
<bddebian> Not sure about the updated ones
<Le-Chuck_ITA> ok
<Le-Chuck_ITA> I got my new debian package
<Le-Chuck_ITA> now
<Le-Chuck_ITA> what
<bddebian> dput revu foo.changes ;-)
<Le-Chuck_ITA> will it help me signing the dsc
<Le-Chuck_ITA> or should I do that before?
<Le-Chuck_ITA> I have the .orig, the .diff and the .dsc
<Le-Chuck_ITA> hmm
<bddebian> dpkg-buildpackage or debuild -S -sa
<Le-Chuck_ITA> I already built the binary package with "debian/rules binary"
<bddebian> Noooo :-)
<Le-Chuck_ITA> I am not getting the point it seems :)
<Le-Chuck_ITA> not in the same source dir
<Le-Chuck_ITA> I didn't that in the same source dir but in a copy
<LaserJock> we have tools to automate building
<LaserJock> you shouldn't need to run debian/rules manually
<Le-Chuck_ITA> ok 
<Le-Chuck_ITA> but I don't have to build the package but to upload the source
<Le-Chuck_ITA> isn't it?
<LaserJock> right, although it *is* a good idea to test it before you upload :-)
<Le-Chuck_ITA> well ok 
<Le-Chuck_ITA> I have to unpack the source again using dpkg-source?
<LaserJock> do you have devscripts installed?
<Le-Chuck_ITA> yes I ran debbuild now
<Le-Chuck_ITA> now my .dsc is signed
<bddebian> Cool, now pbuild it and make sure it builds :)
<Le-Chuck_ITA> but my e-mail address is not therein???
<Le-Chuck_ITA> ok will take ages but seems I am really getting there
<Le-Chuck_ITA> and this makes me happy
<LaserJock> Le-Chuck_ITA: have you seen the Ubuntu Packaging Guide?
<Le-Chuck_ITA> I was expecting this question
<Le-Chuck_ITA> the package I am preparing is already in ubuntu, only new upstream version
<Le-Chuck_ITA> yes I should read the guide
<LaserJock> well, the packaging guide doesn't have so much on new upstream versions (yet)
<LaserJock> but it does have a fair amount on how to build the packages and things like that
<LaserJock> that's why I wondered
<Le-Chuck_ITA> in general I know that I should read more documentation before entering the ubuntu "packaging system"
<Le-Chuck_ITA> but soon or later I have to start, and I will not have that much time soon
<LaserJock> heh
<LaserJock> well don't worry about it too much
<LaserJock> do what you can and ask questions here if you need help
<Le-Chuck_ITA> I am not worrying as you can see :)
<Le-Chuck_ITA> thanks for help
<Le-Chuck_ITA> you all
<LaserJock> np, thanks for helping out
<Lutin> bddebian: could you have a look at http://revu.tauware.de/details.py?upid=4288 if you have some time please ? :)
<Nafallo> !info 915resolutions edgy
<ubotu> Package 915resolutions does not exist in edgy
<geser> Nafallo: 915resolution
<Nafallo> !info 915resolution edgy
<ubotu> 915resolution: resolution modification tool for Intel graphic chipset. In component universe, is extra. Version 0.5.2-4ubuntu1 (edgy), package size 14 kB, installed size 128 kB (Only available for i386 amd64 kfreebsd-i386 kfreebsd-amd64)
<Nafallo> thanks geser :-)
<Lutin> bddebian: thanks for your review
<bddebian> NP
<Le-Chuck_ITA> ok it builds under pbuild
<Le-Chuck_ITA> I signed the dsc
<Le-Chuck_ITA> the checksums of the other two files are in the signed dsc
<Le-Chuck_ITA> what remains to do
<Le-Chuck_ITA> the upload
<Le-Chuck_ITA> ?
<Lutin> bddebian: what d oyou think of the readme.debian ? I did that way because it's the way other nautilus-scripts are packaged
<Le-Chuck_ITA> Next, ask the REVU admins in #ubuntu-motu or at  keyring@tiber.tauware.de to re-sync the REVU uploaders keyring, which grants you upload rights to REVU
<bddebian> Lutin: I think it's OK, I was mainly asking
<Lutin> bddebian: ok, reuploading now with a good desktop file :)
<Le-Chuck_ITA> Uploading to ubuntu (via ftp to upload.ubuntu.com):
<Le-Chuck_ITA>   xournal_0.3.3-0ubuntu1.dsc: done.
<Le-Chuck_ITA>   xournal_0.3.3.orig.tar.gz: exiting due to user interrupt.
<Le-Chuck_ITA> damnit
<Le-Chuck_ITA> did I just make a little mess?
<Le-Chuck_ITA> forgot to add "revu" to dput
<phanatic> Le-Chuck_ITA: no, it'll be rejected automatically
<Le-Chuck_ITA> ok 
<Le-Chuck_ITA> now I have to find someone who wants to review the upload for tomorrow
<Le-Chuck_ITA> since it's a new upstream version
<Lutin> bddebian: updated :)
<bddebian> OK
<Le-Chuck_ITA> To decrypt your password, type the following into your shell:  > gpg -d <<EOT ; echo  Now paste the text below, and enter EOT<return>  
<Le-Chuck_ITA> and there is nothing below
<Le-Chuck_ITA> hmmm
<Le-Chuck_ITA> suspicious
<Le-Chuck_ITA> Mod_python error: "PythonHandler mod_python.publisher"  Traceback (most recent call last):    File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch     result = object(req)    File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 136, in handler     result = util.apply_fs_data(object, req.form, req=req)    File "/usr/lib/python2.4/site-packages/mod_python/
<Le-Chuck_ITA> sorry for flood
<Le-Chuck_ITA> this happened on revu
<Le-Chuck_ITA> anyone here?
<Le-Chuck_ITA> did I scare everybody :)
<bddebian> What do you mean that is happening on REVU?
<Le-Chuck_ITA> on the website
<Le-Chuck_ITA> revu.tauware.de
<Le-Chuck_ITA> I am trying to recover my password 
<bddebian> Ohh
<Le-Chuck_ITA> maybe I am just not yet synced
<Le-Chuck_ITA> because trying with some random letters I get a PGP block
<Le-Chuck_ITA> which I suppose are tests made in the DB by administrators
<Le-Chuck_ITA> nice security by the way :) :)
<Le-Chuck_ITA> and trying some other less common random letters I get the same problems
<Le-Chuck_ITA> (trying some random letters, I mean, as e-mail address for the password recovery)
<Lutin> thanks bddebian :)
<Le-Chuck_ITA> what do I do?
<bddebian> NP, though I'm not sure what my reviews are worth lately.  sistpoty and/or Adri2000 might rip it apart yet :-)
<Le-Chuck_ITA> guys
<Le-Chuck_ITA> I have to end my session and go to cook my pumpkin
<jharr> I think the recent feisty updates busted lvm2 on the installer
<jharr> http://137.48.138.204/~jharr/motu/
<jharr> That preseed file worked perfectly last night
<Le-Chuck_ITA> bddebian, LaserJock? please don't leave me alone I am scared of the evil pipe breaker
<TheMuso> Hey MOTUs.
<bddebian> Heya TheMuso
<bddebian> Le-Chuck_ITA: The evil pipe breaker?
<Le-Chuck_ITA> yes I can't recover my password and thus complete my work
<Le-Chuck_ITA> don't know why but has to do with the above exception
<Le-Chuck_ITA> broken pipe
<bddebian> I don't know much about the password recovery stuff these days :_(  I know it was broken but I thought that it was fixed .
<Le-Chuck_ITA> but I suspect this is just because the database of registered keys should be synced
<geser> Le-Chuck_ITA: have you already uploaded successfully to revu?
<Le-Chuck_ITA> no this is my first time :)
<geser> you should get a password with your first upload
<Le-Chuck_ITA> How to log in  After your first upload, you will be automatically registered to the database and assigned a random password. Use the email address you used in the changelog file of your upload as the login name, and press the 'recover password' link, so as to receive your password by email.   
<Le-Chuck_ITA> hen, ask  to be added to the Ubuntu Universe Contributors team. Next, ask the REVU admins in #ubuntu-motu or at  keyring@tiber.tauware.de to re-sync the REVU uploaders keyring, which grants you upload rights to REVU
<Le-Chuck_ITA> the latter was to be done first
<Le-Chuck_ITA> I am in the ubuntu universe contributors team
<Le-Chuck_ITA> but what about the "REVU uploaders keyring"?
<ajmitch> so you asked, but didn't wait for someone to sync it
<Le-Chuck_ITA> to be precise I dumbly thought that since I could upload, the sync must have been automatized
<Le-Chuck_ITA> I asked anyway
<Le-Chuck_ITA> but didn't wait
<Le-Chuck_ITA> will have to redo the upload?
<Le-Chuck_ITA> ajmitch: who are the REVU admins?
<ajmitch> please wait, I'm resyncing it now
<Le-Chuck_ITA> ok I see you are one :)
<Le-Chuck_ITA> ok should I upload again with -f
<ajmitch> no, I said wait
<Le-Chuck_ITA> ok ok sorry
<fredl> hi, can I request for something to be packaged in Ubuntu here?
<LaserJock> not exactly
<LaserJock> it's not that you can't
<LaserJock> it's just not the best place
<fredl> so what's the best place? somebody on #ubuntu just sent me here.
<LaserJock> fredl: for now https://wiki.ubuntu.com/MOTU/Packages/Candidates
<fredl> tnx LaserJock
<LaserJock> in the future we will be using Launchpad
<ajmitch> ah, the grand & glorious future
<LaserJock> of course ;-)
<LaserJock> well, we could actually do it now
<LaserJock> people just have to tag it right
<ajmitch> ie, you have to have people going through the bug list every day to manage it :)
<Le-Chuck_ITA> ajmitch: I have to go away for half an hour
<Le-Chuck_ITA> leaving chat opened
<fredl> hmm I have to sign up for the wiki to edit that page? :P
<Le-Chuck_ITA> after the sync will I have to reupload or will I act like I had done things in order?
<LaserJock> fredl: yes
<fredl> fair enough
<ajmitch> Le-Chuck_ITA: it should be there now
<Le-Chuck_ITA> ok will try before I leave :)
<LaserJock> fredl: we can't have people/bots spamming everything
* ajmitch tries to remember the bug he wanted fixed for LP
<Le-Chuck_ITA> thank you ajmitch
<Le-Chuck_ITA> everything is ok now
<ajmitch> hey azeem 
* Fujitsu yawns. Morning everyone.
<Le-Chuck_ITA> Last, but the most important:
<LaserJock> hi azeem and Fujitsu 
<Le-Chuck_ITA> Is there anybody who is willing to review my "new upstream release" of xournal on REVU before tomorrow?
<Fujitsu> Hey LaserJock.
<ajmitch> bddebian: why is bibus on revu with that version?
<LaserJock> Fujitsu: you use geda or oregano?
<fredl> hmm some structure in that Wiki page would be nice though :P
<Fujitsu> LaserJock: No.
<Fujitsu> Le-Chuck_ITA, which version is it?
<Le-Chuck_ITA> 0.3.3
<LaserJock> ajmitch: because ...
<ajmitch> LaserJock: some hysterical raisins?
<LaserJock> heh
<bddebian> ajmitch: ??
<LaserJock> I think dch just failed him
<LaserJock> bddebian: it's 1ubuntu1
<bddebian> Oh yeah it is suppose to be 0ubuntu1
<bddebian> I just haven't fixed it yet since no one has looked at it :-)
<bddebian> Or at least commented on it anyway
<LaserJock> I did notice that
<LaserJock> but haven't had time to go through it properly
<ajmitch> LaserJock: but you assumed that a deity would have a reason for it?
<LaserJock> nah
<Fujitsu> I note that xournal is now in Debian, and has 0.3.2-1. Mightn't it be advisable to base it off that instead?
<Le-Chuck_ITA> omg
<Le-Chuck_ITA> I didn't think about this
<LaserJock> :-)
<Le-Chuck_ITA> however I suspect that nothing changed at all
<Le-Chuck_ITA> it might be quicker to check this
<LaserJock> I'm too busy trying to add move MOTU Science to Main  for reviews :/
<Fujitsu> It's likely to be packaged differently.
<Le-Chuck_ITA> why?
<Le-Chuck_ITA> it is a recent addition
<Fujitsu> Because it seems unrelated to our packasge.
<Fujitsu> *package
<Fujitsu> (and it's always a good idea to minimise deviance from Debian)
<Le-Chuck_ITA> ok will reupload
<Le-Chuck_ITA> nah
<Le-Chuck_ITA> tomorrow is new upstream release freeze right?
<Le-Chuck_ITA> is this a strict deadline?
<Fujitsu> Unless it fixes bugs and not much else, yes.
<LaserJock> man, safari needs to allow for multiple rows of tabs or something
<Fujitsu> LaserJock: No, Safari needs to die.
<LaserJock> heh
<LaserJock> I've tired 5+ browsers on my mac
<LaserJock> none of them are all that great
<Fujitsu> Why Safari? Because it's the most Aquaish?
<fredl> there, Wiki updated :)
<LaserJock> most integrated
<LaserJock> and it's fast
<LaserJock> fredl: thanks
<fredl> ur welcome :)
<fredl> is the order where I place it important?
<LaserJock> it's supposed to be alphabetical I think
<LaserJock> man, do I have a junior job for MOTU Hopefuls for after FF
* ajmitch delegates LaserJock to email people about UVF
<LaserJock> we have to email people?
<LaserJock> :-)
<ajmitch> well, the list :)
<rexbron> LaserJock: Would you have time to review a package?
<LaserJock> I don't even know when it is
<ajmitch> so that people know what to do when the Freeze Hits
<fredl> ehr... well then I might have to re-edit it :P
<LaserJock> I'm not sure I even know
<LaserJock> other then they have to start doing UVFe requests
<Fujitsu> Is there a set time? End of the 8th UTC?
* LaserJock starts flame fest threads on the forums
<ajmitch> bugs assigned to motu-uvf, 2 ACKs needed, etc
<ajmitch> Fujitsu: general freeze time is when the devel meeting starts
<LaserJock> Fujitsu: there never seems to be a set time for Freezes
<ajmitch> LaserJock: YAY!
<LaserJock> we had the one freeze that started when dholbach went to bed
<Fujitsu> ajmitch: Indeed, I failed to notice that this coincided with a devel meeting. That does make sense though.
<Fujitsu> LaserJock: Heheh, I remember that.
<LaserJock> I think we had one where it froze when mdz said "I've had enough"
<LaserJock> but lately they have been doing it by devel meetings
<ajmitch> or the freeze where the publisher & buildds ran for the last time before release
<Fujitsu> Hahahhaha:
<Fujitsu> `Welcome to the Launchpad private beta. Please do not post screenshots publicly. Bug reports and feedback welcome.'
<Fujitsu> I presume that's after the blog post last night.
<ajmitch> haha
<LaserJock> I wondered
<ajmitch> nice
<ajmitch> yeah
<phanatic> Fujitsu: it was also revealed by Joey Stanford last week
<ajmitch> phanatic: oh?
<phanatic> ajmitch: in his Launchpad presentation he blogged about
<ajmitch> naughty people, leaking s3kr3t c0d35
<LaserJock> og's post is still up too
<LaserJock> on planet anyway
<phanatic> LaserJock: yup, no way back anymore :)
* ajmitch hasn't even blogged about the LP beta
<ajmitch> hi gpocentek 
<LaserJock> what is there to blog about?
<ajmitch> shiny
<Fujitsu> LaserJock, it'll vanish from planet within a couple of hours if it does so from his blog.
<Fujitsu> Shiny/blinding, yes.
<LaserJock> "The new LP is shiny"
<LaserJock> that's not much of a blog post
<LaserJock> I wish we could test speed with it though
<LaserJock> like compare to what is there now
<Fujitsu> That would be nice...
<Fujitsu> It's apparently running on comparable hardware now (or was going to be after the last dev meeting)
<LaserJock> because I wonder how much the bling is going to affect performance
* enyc has this nastly suspicion that nobody else really uses qpsmtpd on ubuntu ...
<ajmitch> LaserJock: why should it?
<enyc> ;-)
<ajmitch> enyc: you're probably right
<enyc> so they cant go test my bugreports lol
<enyc> how silly
<LaserJock> ajmitch: cause it seems slower to me, I think
<Fujitsu> LaserJock: Before the last dev meeting, it was sharing a server with... something else, can't remember what.
<LaserJock> k
<Le-Chuck_ITA> Fujitsu: the only thing I had to do in the new debian source is dch -i :)
<Le-Chuck_ITA> and change a dependency from xpdf-reader to poppler-utils
<Le-Chuck_ITA> I uploaded the new package
<Fujitsu> And you might want to put the .desktop in as well.
<Fujitsu> Ah.
<Le-Chuck_ITA> the .desktop er isn't that already there...
<Le-Chuck_ITA> no
<Le-Chuck_ITA> I am a mess maker :) if you have an english word for that
<Fujitsu> The .desktop was in the Ubuntu one, but isn't in Debian.
<LaserJock> Fujitsu: does beta use the same database? like if I change things in beta they'll show up in the "old" LP
<Le-Chuck_ITA> and that was the main reason I wanted xournal in ubuntu some month ago
<Fujitsu> LaserJock, yep. I don't use normal LP any more.
<LaserJock> only demo uses a different one?
<Fujitsu> And staging.
<LaserJock> ah
<Fujitsu> It was originally not going to be on the production DB, then I brought up the fact that few people would use it if they couldn't use it for proper work.
<LaserJock> mhm
<ajmitch> mm, I should probably switch to using beta fulltime
<Fujitsu> ajmitch, that's a good idea.
<Adri2000> is there any requirement to join launchpad-beta-testers?
<ajmitch> as long as I can get to things with similar urls
<ajmitch> Adri2000: your soul
<Fujitsu> ajmitch, just stick beta. on the front.
<Le-Chuck_ITA> Fujitsu: xournal.sharedmimeinfo, xournal.desktop and xournal.install
<Le-Chuck_ITA> should I just copy them to debian?
<Fujitsu> (well, behind the application domain, if there is one)
<Fujitsu> Le-Chuck_ITA, yep, and you'll need to add a section to the install rule to put them in the right place.
<ajmitch> of course there are still a few things missing in the beta ui
<Fujitsu> Like?
<ajmitch> & there are things just broken :)
<ajmitch> eg your personal page, "working on..."
<ajmitch> which should show in progress bugs
<Fujitsu> Heheh.
<Fujitsu> Yeah.
<Fujitsu> Isn't the `working on' bit only new to production?
<ajmitch> and fooix the wonder toaster?
<ajmitch> no
<ajmitch> well
<ajmitch> it's new
<ajmitch> i don't recall when I saw it
<ajmitch> but it was only recently on lp
<Le-Chuck_ITA> binary/xournal::
<Le-Chuck_ITA>         dh_installmime
<Le-Chuck_ITA> binary/xournal::
<Le-Chuck_ITA>         dh_installmime
<Le-Chuck_ITA> oh sorry
<Le-Chuck_ITA> does dh_installmime at the end of the install rule suffice?
<Le-Chuck_ITA> and what about postrm
<ajmitch> so many confusing things in the beta UI
* ajmitch wonders where to start filing bugs
<Le-Chuck_ITA> Fujitsu: I am not sure I am the right person to do this upload
<Le-Chuck_ITA> the rules files are different in 0.3.1
<Le-Chuck_ITA> ubuntu and 0.3.2 debian
<Fujitsu> The Debian version doesn't use CDBS.
<Fujitsu> I'll have a look and see what needs to be taken across from the Ubuntu package.
<Fujitsu> Ah, it's like that.
<Le-Chuck_ITA> in the ubuntu package there are the post-install and pre-rm scripts
<Le-Chuck_ITA> I suppose cdbs made those
<Q-FUNK> guys, i need advice on how to proceed:  I need to update a more recent version of a package directly into ubuntu, while debian will get it only later once etch is out.
<Le-Chuck_ITA> in any case I tried, I have to go now - it's really too late. I declare myself available to work more on this (maybe later, and for sure...) tomorrow morning
<Le-Chuck_ITA> Fujitsu: I really would like to understand how to end such a process
<Le-Chuck_ITA> for learning purposes :)
<Fujitsu> Basically, you need to add dh_installmime (or whatever it is) and dh_desktop to the `binary-arch: build install' rule.
<LaserJock> so are the teams going to get big emblems? that big orange box is annoying me
<Le-Chuck_ITA> Fujitsu: will you try to get the new version in feisty in my place, or will I try to do this tomorrow, or will I give up?
<Fujitsu> If you don't have time, I'll do it.
<LaserJock> ajmitch: does https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6 look right
<ajmitch> ooh, LaserJock took my delegation seriously? :)
<Le-Chuck_ITA> not tonight and don't know if tomorrow morning is too late 
<Fujitsu> It may be too late.
<Le-Chuck_ITA> ok so I ask you if it is simple to do that in my place 
<Le-Chuck_ITA> and in that case to leave a comment on my upload or send me a mail
<Le-Chuck_ITA> I will see how things are tomorrow :)
<Le-Chuck_ITA> and act consequently 
<LaserJock> ajmitch: yes I did
<Fujitsu> Yep, I shall do so.
<Le-Chuck_ITA> thank you very much
<ajmitch> LaserJock: borrowed from the old Processes/UVF page?
<Fujitsu> No problem, and thanks for trying to update it :)
* Le-Chuck_ITA cowardly moves the mouse towards the close button...
<Le-Chuck_ITA> goodbye to everybody and thanks, I learned a lot
<Fujitsu> Thanks for the help, we need it.
<Le-Chuck_ITA> NP :P bye
<ajmitch> LaserJock: looks ok, I think
<LaserJock> ajmitch: ok, then shall I send the email?
<ajmitch> LaserJock: may as well
<LaserJock> I'm having a smashing email day ;-)
<ajmitch> yay
<LaserJock> at least until they all start bouncing or something
<ajmitch> heh
<ajmitch> sent about 50 today?
<LaserJock> me? heavens no
<LaserJock> maybe 3
<LaserJock> should I use "Imminent" in the subject so it sounds all official? ;-)
<ajmitch> certainly
<ajmitch> like 'Impending Doom'
<LaserJock> heh, I like that better
<ajmitch> lucky slomo, he'll get flooded with bugs
<LaserJock> I should add a nice soundtrack to my email
<ajmitch> oh the beta team display sucks
<Fujitsu> LaserJock, with a lot of nice jarring chords.
<ajmitch> doesn't display team members on the overview page
<slomo> ajmitch: i'm already flooded with bugs... this few more bugs don't hurt i hope ;)
<LaserJock> I like the "idea" but I want to see the members
<ajmitch> slomo: another 20 a day won't hurt
<ajmitch> so it's dholbach, siretart & slomo to the rescue
* Adri2000 is flooding LP with new upstream release sync requests to not flood motu-sru ;)
<Fujitsu> slomo: Can you please check your two branches on the mplayer product, and mark them Merge or Abandoned as appropriate?
<Fujitsu> *Merged
<slomo> ajmitch: not you again as number 4?
<slomo> Fujitsu: sure... nice that you want to care for mplayer now, i'm not interested in it anymore ;)
<Fujitsu> I use it a lot, so I may as well.
<ajmitch> slomo: maybe
<Fujitsu> slomo: Much better :P)
<Fujitsu> *:)
<bddebian> ajmitch: So, did you review bibus? :-)
<LaserJock> ajmitch: just to be clear, new Debian revisions are OK during UVF right?
<ajmitch> LaserJock: of course
<ajmitch> bddebian: heh, no
<bddebian> :'-(
<ajmitch> bddebian: that would require effort
<LaserJock> ajmitch: well you know, I always send out an email like this and half of what I say turns out to be wrong ;-)
<Adri2000> yay
<LaserJock> bddebian: I'll do it soon
<ajmitch> LaserJock: that's fine, as long as the half that's right is the important half
<LaserJock> :-)
<slomo> Fujitsu: sure... nice that you want to care for mplayer now, i'm not interested in it anymore ;)
<slomo> Fujitsu: done
<Fujitsu> Thanks.
<TheMuso> Wooo. Planet is broken.
<LaserJock> does motu-uvf really want UVFes assigned to them?
<slomo> LaserJock: yes... at least last time we handled it that way
<LaserJock> k, just making sure
<ajmitch> it makes a difference with the mail
<LaserJock> ah, interesting. hadn't thought of that
<LaserJock> hmm, the FreezeExceptionProcess page just says: "Once one of the  team members marks the bug as Confirmed you can proceed with uploading."
<LaserJock> so does that mean 2 have to ack and the 2nd will mark it Confirmed?
<ajmitch> yes, usual process
<LaserJock> or is it just 1 ack
<ajmitch> 2 acks, 2nd marks as confirmed
<ajmitch> it allows for the team to shuffle their process & others don't have to care
<ajmitch> eg if there were 500 bugs submitted, it may be better to do 1 ack
<LaserJock> it's also a bit more confusing in a sense as people don't know what to expect
<LaserJock> but I think the flexibilty argument is good
<LaserJock> ajmitch: argg, I lost the url to your bug list
<ajmitch> that's ok
<ajmitch> it's in the topic, you know :)
<LaserJock> bah
* ajmitch wonders why the bug list for a package doesn't show a nice web 2.0 tagcloud ;)
<LaserJock> uggg
<LaserJock> I hate clouds
<ajmitch> you know you want it
<LaserJock> I just want what *I* want darn it
<Lutin> revu admin around ? seems that  videomanager_0.5-0ubuntu1.dsc is stuck somewhere, could you nuke it ?
<LaserJock> not what every dope on the web wants
<ajmitch> Lutin: done
<Lutin> ajmitch: thanks
<LaserJock> ajmitch: should I send this to ubuntu-devel-announce too?
<ajmitch> I'd wait & find out if mdz is going to announce something for main
<ajmitch> maybe
* ajmitch is just a lowly MOTU :)
<LaserJock> not "just", you're a core-dev too
<Fujitsu> A MOTU with main upload privileges, I think :P
<ajmitch> small details
<LaserJock> I'll just send it to ubuntu-motu for now I think
<LaserJock> it's probably too much hand-holding for core-devs ;-)
<LaserJock> sent
<LaserJock> I really wish the "tell my why in the world I'm getting bug mails" bug would get fixed
<ScottK> I have two new upstream releases for REVU.  They should be simple enough (I hope) as they have no packaging changes from the previous releases: http://revu.tauware.de/details.py?upid=4293 and http://revu.tauware.de/details.py?upid=4294 - I'd appreciate a look when one of you MOTUs has a moment.
<TheMuso> rexbron: Any reason why the soma client binary is in the soma-server package?
<bddebian> haha 
<ScottK> bddebian: Hi there.  What's funny, me showing up with two updates just after the UVF warning goes out?
<bddebian> ScottK: No, poor rexbron getting crap from TheMuso after sistpoty basically had him re-create the whole package :-)
<ScottK> Ah.
<bddebian> Anyway, gotta run, I'll catch you all in a few
<_ion> Could some MOTU please review <http://revu.tauware.de/details.py?upid=4133>? That's not packaged by me, but i'd *really* like to have the package in Feisty. It contains the compiz 'state' plugin, which allows you to define rules such as "open all firefox windows to the desktop 1", "view mplayer windows brighter than other windows".
<rexbron> TheMuso: the client is just a commandline prog to interface with the daemon
<rexbron> the daemon is unuseable really without it
<TheMuso> Ok then.
<lifeless> 'someone' should package http://reprap.org/bin/view/Main/RepRapLinuxSoftware
<lifeless> I'll probably get to it next weekend
<rexbron> TheMuso: give me a heads up of you advocate it
<TheMuso> rexbron: 
<TheMuso> rexbron: Have a look on the revu page.
<rexbron> :)
<rexbron> ok now to find someone else to review it
<mohammad> I had uploaded a package to http://revu.tauware.de/ a few months ago, Now I have fixed some bugs and trying to upload the new package
<rexbron> hey anyone up for a review? upid 4284
<mohammad> but I couldnt I recieve the following error in email
<mohammad> Rejected:Signer has no upload rights at all to this distribution.
<mohammad> would you please give me some hints what I should do?
<ajmitch> mohammad: make sure you're in the ubuntu-universe-contributors group on launchpad, then ask for the keyring to be resynced here
* ajmitch would resync, but is heading out the door right now
<ajmitch> bacl later
<ajmitch> s/bacl/back/
<Adri2000> mohammad: are you sure to use dput *ubuntu* .changes?
<mohammad> ajmitch: I am sure in the ubuntu-universe-contributors group on launchpad
<Adri2000> mohammad: err, I'm tired, I meant are you sure to use dput *revu* .changes?
<mohammad> Adri2000: yes I use dput. even I invoke it with -f command
<Adri2000> if you upload to ubuntu that won't work, you have to specify that you want to upload to revu with 'dput revu .changes'
<mohammad> Adri2000: dput -f zekr_0.5.0b2-0ubuntu1_source.changes 
<Adri2000> try dput -f revu zekr_0.5.0b2-0ubuntu1_source.changes
<mohammad> Adri2000: I did it, now I should wait 5 minutes to be able to see the result :)
<racarr> Is beryl not going in universe for feisty?
<LaserJock> not if people don't upload it 
<LaserJock> and if it doesn't get approved
<LaserJock> but otherwise yeah :-)
<racarr> Well, err, it hasn't happened so far and feature freeze is soon :/
<mohammad> Adri2000: thank you for your help my package was updated successfully. :)
<Adri2000> :)
<LaserJock> racarr: exactly
#ubuntu-motu 2007-02-08
<LaserJock> racarr: parts of it were uploaded but rejected by the archive admins, I think
<racarr> Argh
<Burgwork> racarr: beryl is being packaged by debian and is already there
<racarr> Burgwork: No, we still have some tango icons in beryl and the copyright was unclear so it got rejected
<racarr> Burgwork: Also tango icons are non DFSG so it would have had to be in nonfree
<Burgwork> ah
<LaserJock> Burgwork: it's in NEW
<LaserJock> in debian
<racarr> Again, it was rejected
<racarr> and the packager is giving up until 0.2.0 final is released because he was packaging 0.1.4
<LaserJock> same issue with Ubuntu I think
<racarr> copyright issues? or tango icons?
<racarr> I thought ubuntu had no problem with tango
<LaserJock> not sure
<LaserJock> could have been copyright
<LaserJock> when is 0.2.0 due out?
<racarr> Well, we have an RC out right now
<LaserJock> well, the universe freeze is the 22nd
<LaserJock> we are having a REVU sprint  Thursday-Saturday and then probably another one before the 22nd
<LaserJock> you there is a package we can review it
<LaserJock> s/you/if/
<_ion> Compiz would suffice for me if it had the state plugin. :-)
<_ion> (which happens to be waiting in REVU)
<Burgwork> _ion: is the state plugin part of compiz itself?
<_ion> burgwork: No, it's in compiz-extra: http://revu.tauware.de/details.py?upid=4133
<Burgwork> _ion: mjg59 is thinking about updating compiz to the latest git. Bother him to get the plugins updated
<_ion> burgwork: Thanks, i'll talk to him.
<mohammad> when I want to upload a package to REVU for which distribution should I compile it? dapper or feisty
<rexbron> mohammad: feisty
<PriceChild> What's the absolute deadline for us to get Beryl packages into feisty's universe?
<mohammad> rexbron: then lintian says: E: bad-distribution-in-changes-file feisty
<mohammad> is it ok?
<LaserJock> mohammad: yes
<LaserJock> PriceChild: Feb 22nd
<PriceChild> LaserJock, thankyou :) Convinced myself it was tomorrow :)
<PriceChild> LaserJock, I've really got to sort out my xvidcap once and for all also....
<RAOF> I thought it was tomorrow, too.  Sweet.  Now, to convince the specto guys to actually *release* a tarball!
<LaserJock> it's tomorrow for Main
<mohammad> should Standard-version in debian/control be 3.7.2.2 or 3.7.2?
<LaserJock> 3.7.2
<TheMuso> Lutin: A comment for your purrr package on revu when you get a moment to look at it.
<mohammad> Thank you :)
<Lutin> TheMuso: can't catch what you mean
<TheMuso> Lutin: You did purrr right? I have put a comment on revu for it.
<Lutin> TheMuso: yeah, I got that ;)
<TheMuso> Lutin: Righto.
<Lutin> TheMuso: what I don't understand is your comment
<TheMuso> Cdbs can do the dh_pycentral call for you, so you don't have to have a special target for it in debian/rules.
<Lutin> TheMuso: you mean use python-distutils.mk ?
<TheMuso> Lutin: Yeah.
<Lutin> TheMuso: this doesn't apply here
<TheMuso> Lutin: Why not?
<Lutin> TheMuso: python-distutils use a special type of setup.py script
<TheMuso> Lutin: Which conflicts with the one in the package?
<Lutin> TheMuso: cdbs assumes this script is provided
<TheMuso> This script?
<Lutin> python-distutils assumes that a special script named setup.py is provided with the upstream sources
<Lutin> which is not the cas here
<Lutin> case*
<cbx33> hi guys
<cbx33> when working in a chroot 
<cbx33> how do I mount the proc....
<cbx33> and then unmount before exiting
<cbx33> I don't want to set it up permanently 
<cbx33> in the fstab
<tsmithe> mount -t procfs /chroot/proc
<tsmithe> i think :)
<cbx33> tsmithe, are you able to check it?
<cbx33> i don't have a chroot here
<cbx33> i thought it was mounted after i enter then chroot
<cbx33> hmm
<cbx33> though I am quite possibly wrong
<keescook> ajmitch: do you happen to know where the gdk bindings for mono are?
<slomo> keescook: gdk? libgtk2.0-cil
<keescook> ah-ha! thanks
<Lutin> TheMuso: still there ?
<LaserJock> cbx33: mount it from the outside
<cbx33> ok....
<cbx33> any clues on the exact command?
<cbx33> it's for the book chapter
<LaserJock> cbx33: just as tsmithe said
<cbx33> thanks LaserJock 
<TheMuso> Lutin: Ok righto.
* TheMuso has learnt something new today.
<cbx33> anyone running feisty right now?
<geser> yes
<TheMuso> Lutin: Ok looks good then.
<cbx33> can you tell me what the new Control menu is called?
<cbx33> and the user management tool
<cbx33> Exactly :p
<Lutin> TheMuso: thanks ;)
<geser> cbx33: new control menu? you mean the gnome-control-center?
<cbx33> yeh
<cbx33> when you look at the menus what is the text
<geser> Control Centre
<geser> under System
<cbx33> awesome
<cbx33> ahh
<cbx33> so it goes.... System -> Control Centre -> User Management ?
<geser> it's not a submenu anymore
<geser> I will try to find a picture
<geser> cbx33: http://lunapark6.com/?p=2728 shows the new control center
<cbx33> cool
<cbx33> thanks geser
<cbx33> exactly what i was looking for
* ajmitch returns
<ajmitch> LaserJock: aha, you had to quote my bug list..
<LaserJock> ajmitch: of course
<ajmitch> good thing you didn't put the url to the full list
<ajmitch> which includes everything from wishlist up
<TheMuso> Do uploaded packages get archived in revu?
<TheMuso> i.e once we upload, we then archive?
<crimsun> yes (to the latter)
<TheMuso> right
<sistpoty> hi folks
<ajmitch> hey sistpoty 
<sistpoty> hi ajmitch
<LaserJock> hi sistpoty 
<sistpoty> hi LaserJock
<sistpoty> LaserJock: thx for sending the mail about UVF :)
<LaserJock> np, ajmitch told me to do it
<LaserJock> and I have to do his bidding
* ajmitch delegates :)
<sistpoty> thx ajmitch for whipping ajmitch ;)
<ajmitch> haha
<sistpoty> laserjock even *g*
<ajmitch> his mails are so eloquent & poetic ;)
<sistpoty> *g*
<LaserJock> bah
<LaserJock> wordy and scattered is more like it
<LaserJock> I bet if I did a statistical analysis my emails are probably twice as long as most people's
<ajmitch> but worth every word
<sistpoty> and mine twice as short :)
<LaserJock> sistpoty: but I bet people read yours all the way through
<LaserJock> I keep thinking, "Nobody's going to read this whole thing"
* sistpoty read it
<sistpoty> :P
<LaserJock> yeah, but you're uber smart
<LaserJock> and care
* ajmitch read it
<LaserJock> oh ..
<LaserJock> ;-)
<ajmitch> and you can hardly say I'm smart
<sistpoty> people who delegate are always smart ;)
<ajmitch> s/smart/lazy/
<sistpoty> hehe
<LaserJock> smart == lazy ?
<sistpoty> LaserJock: then your statement about me being uber-smart would make sense *G*
<LaserJock> doh
<LaserJock> ok, I think I'm going home
<LaserJock> I'll bbl
<ajmitch> bye
<sistpoty> later LaserJock
<LaserJock> gotta work on the dreaded MIRs tonight :(
<TheMuso> crimsun: How do you force a particular card/module to be card 0 with alsa?
<TheMuso> crimsun: nvm figured it out.
<bddebian> Heya gang
<sistpoty> hi bddebian
<bddebian> Hi sistpoty
<ajmitch> ah, a bddebian 
<ajmitch> someone else to delegate to :)
<bddebian> ajmitch: Sure man, whatya need?
<ajmitch> universe bugs. fixed.
<bddebian> Bah I already told ya I can't fix anything :-)
<ajmitch> excuses..
<bddebian> I dunno if it's that Dell laptop or Linux in general but wireless SUCKS on that thing
<ajmitch> blame the dell
<ajmitch> what's the wireless chipset?
<bddebian> The frickin' broadcom :-(
<keescook> ajmitch: gaar.  the f-spot bug is fixed in 0.3.3.  I didn't see it had been updated.  *bang head*
<bddebian> That was a PITA in and of itself
<ajmitch> keescook: oh, useful
<ajmitch> keescook: I just uploaded 0.3.3 earlier
<ajmitch> so don't feel bad
<keescook> well, I tracked down the bug, and then found it was fixed in the svn, and just noticed the reject email from my upload.  :)
<ajmitch> haha
<keescook> but that's okay, there are a bunch of other bugs I found in the gallery export that are fixed in 0.3.3, so that rules
<ajmitch> yeah, 0.3.3 is mainly bugfixes
<keescook> I can FINALLY publish my LCA photos!  :)
<ajmitch> yay! :)
<ajmitch> now I can go through & clean up some more bugs on malone
<ajmitch> good thing I uploaded when I did 
<bddebian> ajmitch: Well I'm kinda trying to fix some bugs by updating the tilp packages :-)
<ajmitch> good
<ajmitch> hop to it then :)
<ajmitch> keescook: thanks for chasing it up
* ajmitch just got the reject notice as well
<ajmitch> keescook: you don't see anything silly happening like galleries being created with '+' in the name, do you?
<bddebian> Heya LaserJock
<LaserJock> hi
<keescook> ajmitch: hadn't noticed that, nope
<ajmitch> keescook: I suspected as much - I have an old bug open about it, could never reproduce
<ajmitch> ok, f-spot bug count is down by about 10 today
* keescook claps
<LaserJock> wow
<ajmitch> yeah, I was behind on some bug triage there
<ajmitch> 48 bugs open
<imbrandon> hum
<imbrandon> moins all
<LaserJock> hi imbrandon 
<ajmitch> down to 37 now, still got plenty to check
<sistpoty> hi imbrandon
<ajmitch> & a few more fixes I can put in
<ajmitch> hey imbrandon 
<imbrandon> LaserJock, do you use a apple keyboard with linux ?
<LaserJock> yep
<imbrandon> how do you get the numpad working ?
<imbrandon> there is no "numloc" lol
<LaserJock> hmm
<LaserJock> I think Shift+<where numloc normally is>
<imbrandon> hrm there is nothing where it normaly is, its a true blue apple keyboard
<imbrandon> not a lappy one
<TheMuso> Heya imbrandon
<imbrandon> heya TheMuso 
<imbrandon> everything works with it , even the multimedia keys work
<LaserJock> mine had something where the numloc normally is
<imbrandon> cept the nupad
<imbrandon> hrm
<imbrandon> one sec
<racarr> imbrandon: You are packaging beryl for universe right? any update on that? ( I ask because universe freeze is soon )
<crimsun> Feb 22.
<imbrandon> i did some initial work on it , ummm as far as "i'm doing it" i'll welcome any help , with that said i havent kept up with it the last 2 weeks and planned on getting "something" updated before freeze
<imbrandon> sooo hopefully thats what you wanted to hear
<ajmitch> imbrandon: is it worth it? :)
<StevenK> It seems imbrandon has two sources of crack.
<imbrandon> ajmitch, from the looks of it it would be nice to have in universe , past that its a ball of shiznit
<ajmitch> haha
<RAOF> imbrandon: I hope you can find a version that works with XGL :)
<racarr> imbrandon: We have some packaging in distro-specific-build-files/debian...most of it is pretty decent and the packaging is all GPL (not sure if you can use it?)
<imbrandon> RAOF, not likely
<racarr> RAOF: Both latest SVN and latest release work with XGL :/
<StevenK> Personally, I didn't have any problems with Beryl on AIGLX on my laptop
<imbrandon> racarr, yea i looked at that , i helped clean some of it up actualy
<RAOF> racarr: Not according to #ubuntu-effects
<imbrandon> racarr, i have to work in a few hours, i'll make that my "project" for the week at work to get something updated
<racarr> RAOF: Mm, I don't think that's right anymore (the topic in #ubuntu-effects that is), but it's definitely fixed in SVN and RC2 is in a few days...
<racarr> imbrandon: Thanks
<RAOF> racarr: That'd be great.  Although the breakage has allowed me to ween a couple of older ATI users of XGL & fglrx :)
<StevenK> Oh nice, slomo is a DD now, too
<imbrandon> StevenK, yup
<StevenK> Now being a DD here isn't as exclusive, the rabble are getting in.
<StevenK> :-P
<sistpoty> StevenK: can you give me an ack for SRU bug #82692 ?
<Ubugtu> Malone bug 82692 in xmms-sid "[SRU]  xmms-sid broken in edgy" [Undecided,Needs info]  https://launchpad.net/bugs/82692
<imbrandon> hahah that mean i should start my trek to DDism
<imbrandon> StevenK, ^^
<StevenK> sistpoty: Oh crap, I meant to look at that, sorry.
<StevenK> imbrandon: Heh
<sistpoty> StevenK: no hurries ;)
<ajmitch> StevenK: you'll have to join some other elitist club
<crimsun> [if there are pending SRUs, I'm wading through some 3k unread emails] 
<sistpoty> crimsun: I'm not aware of any apart from mine ;)
<crimsun> ok
<StevenK> Acked
<sistpoty> thanks StevenK
<StevenK> The debdiff is a little unnecessary, it's a rebuild. :-)
<StevenK> ajmitch: Ohhh, but how to find one. :-)
<sistpoty> StevenK: I still could have screwed on the version number ;)
<ajmitch> StevenK: well you're on the SRU team
* StevenK raises his eyebrows.
<StevenK> sistpoty: "On" ?
* StevenK grins
<ajmitch> maybe you should go on the UVF team as well :)
* sistpoty don't speek no english not *g*
* StevenK tries to stop laughing.
<imbrandon> hahah rock on LaserJock i found it
<imbrandon> option + clear
<imbrandon> ;)
<LaserJock> yeah, I was close ;-)
<LaserJock> I had to google that one
<imbrandon> my keyboard is exactly like this one with the exception of the txt above the clear key
<imbrandon> http://www.devworld.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G4/PowerMacG4/art/jos04.gif
<imbrandon> thats how i figured it hehehe
<bddebian> If soname is libtifiles2.so.3, package name should be libtifiles2-3 right?
<imbrandon> bddebian, i *think* so, im not great with libs
<imbrandon> but that seems right
<bddebian> Thx
* sistpoty is now off to bed
<sistpoty> gn8 everyone
<bddebian> Gnight sistpoty
<imbrandon> gnight
<ajmitch> night sistpoty 
* imbrandon rambles while amarok compiles again
<imbrandon> i picked up a 2gig usb stick today for $10 , i think i'm gonna try to get ubuntu booting from it, i seen a tutoral about it somewhere on the net
<TheMuso> imbrandon: heh
<imbrandon> might be neat
<imbrandon> good news is i got feisty installed on my mac ;)
<imbrandon> and some of the quarks worked out
<TheMuso> imbrandon: You had quirks?
<imbrandon> like the num lock thing etc
<TheMuso> oh
<imbrandon> s/num\ lock/numlock
<LaserJock> I'd like to put Feisty on my intel mac
<imbrandon> just miror stuff i wasent used to dealing with
<imbrandon> LaserJock, yea thats what this is an intel mac
<LaserJock> yeah
<imbrandon> i've had edgy on my ibook a long while
<imbrandon> just got this thing not long ago though
<imbrandon> and dont even have osx installed on it atm 
<imbrandon> lol
<TheMuso> imbrandon: Nice.
<LaserJock> just last time I put Ubuntu on my mac it didn't end well :/
<TheMuso> What sort is it?
<imbrandon> TheMuso, me?
<TheMuso> imbrandon: Yeah.
<imbrandon> just a $799 mini
<TheMuso> aah
<imbrandon> cheapie but works for a nice works station i dont have to worry about the hardware
<imbrandon> i got tired of swapping hardware in my main workstation so i got this for a every day workstation and then my old box is my "tinker" box , and then i have my servers
<TheMuso> Sounds nice.
<imbrandon> not a powerhouse but its got a bit of umph, like core 2 duo or core duo , not sure 2.4ghz
<imbrandon> gig of ram etc etc etc, just a normal mini
<TheMuso> imbrandon: Thats a tempting way to do things I must admit.
<imbrandon> yea, it gets old after a while
<TheMuso> What does?
<imbrandon> ( the hardware thing )
<TheMuso> ah
<imbrandon> seemed i was constantly swapping hdd's and nic etc in the other box
<TheMuso> Well I currently use a dual celeron 466 for my main workstation, but ats ok since I am on the console.
<imbrandon> now i can and still have a workstation
<TheMuso> However, I will likely be moving to GUI with gnome-terminal soon.
<TheMuso> And I don't think this celeron copes very well with gnome + accessibility.
<imbrandon> hehe
<imbrandon> gnome should be ok, + accessability i dunno
<TheMuso> My P4 is alright, but with accessibility stuff it does lag a bit now and then.
<imbrandon> i dunno how much that taxes the hardware
<imbrandon> right on
<TheMuso> And its configured to be a specialty box mostly.
<TheMuso> i.e audio related. Got three soundcards, and connections/things hanging all off it.
<imbrandon> ahh
* imbrandon got his new car today too
<imbrandon> w00t
<TheMuso> Cool.
<imbrandon> LaserJock, what problems did you have last time ( with the intel mac )
<LaserJock> oh just getting it going
<LaserJock> the install was a bit involved (grub problems)
<imbrandon> ahh yea 
<LaserJock> and then the ATI is always fun
<imbrandon> grub complained it abit
<mwolson> (referring to use of Ubuntu feisty on a Mac Mini) i have the best luck with the 2.6.17 kernel from edgy, currently
<mwolson> since the current feisty kernel chokes on my LVM setup on the 4th partition at boot-time
<imbrandon> mwolson, i havet had any problems /yet/ but lets cross our fingers
<mwolson> imbrandon: using LVM?
<imbrandon> no
<mwolson> then it will probably be smooth sailing
<imbrandon> i only have lvm on the servers
<mwolson> i figured it would be a good way to deal with the 4-partition limitation for preserving the ability to dual-boot with OS X
<imbrandon> right on
* TheMuso thought macs didn't have a 4 partition limit.
<imbrandon> they dont iirc , and thats only primary parts anyhow
<imbrandon> not extended parts
<TheMuso> I thought efi had its own partition type.
<TheMuso> s/type/partition layout/
<LaserJock> I had some funky stuff last time I did it
<TheMuso> you know what I mean.
<imbrandon> yea
<LaserJock> ended up with an extra partition
<LaserJock> so I only had 1 partition for Ubuntu
<LaserJock> no swap
<TheMuso> ooo fun
<imbrandon> i dont have any swap on my normal intel
<ajmitch> you don't need swap
<LaserJock> 1st time I did it, it didn't do it
<LaserJock> ajmitch: I suppose
<ajmitch> depends on how much RAM you have
<ajmitch> I'd want swap with 512MB
<ajmitch> even with 1GB
<LaserJock> it just make me nervious when I've only got 1 partition for Ubuntu
<LaserJock> I've never had more than 1GB
<StevenK> I have 1.5Gb, and I hit swap here
<ajmitch> StevenK: yes, but you're special :P
<imbrandon> i have 2 and rarely hit swap, and with 4 i never do
<StevenK> Currently only 264 bytes.... :-)
<TheMuso> lol
* ajmitch hits swap fairly easily with 1GB
<StevenK> This machine started out with only 512Mb, and it found it was just too little RAM for an amd64
<LaserJock> apparently I don't use my computer very much
<imbrandon> yea with 1 i hit it quite a bit
<StevenK> s/it found/I found/
<LaserJock> On my laptop (512MB) I don't think I hit swap very much
<imbrandon> 1gb is barely enough for a x86_64 running a 64bit os
<ajmitch> 4GB is barely enough
<imbrandon> just for the OS imho
<StevenK> This machine is nice with 1.5Gb
<LaserJock> hmm, maybe that's it, I've never had a 64bit machine
<StevenK> LaserJock: Come to the dark side ...
<TheMuso> LaserJock: Me neither. I have 1GB in my P4, 768MB in my celeron, and 512MB in my G3 300 powerpc. I can only remember using swap when I'm doing serveral big package builds.
<LaserJock> somebody want to buy me one? ;-)
<TheMuso> Even then thats not often.
<StevenK> LaserJock: Where sizeof(void *) != sizeof(int) and other such evil things. :-)
<imbrandon> LaserJock, your intel mac should be 64bit
<LaserJock> imbrandon: I don't think so, just dual core
<imbrandon> must have been one of the orig ones
<imbrandon> very few arent
<StevenK> LaserJock: If your Intel mac is running Linux, /proc/cpuinfo will tell you if it's 64 bit.
<LaserJock> I ordered it ~2 days after they came out
<imbrandon> then possibly, the 32bit dual core itel macs were very short lived
<imbrandon> intel*
<mwolson> TheMuso: if you want the weird Apple partition format and the usual partition format to keep in sync, you have to stick with only 4 partitions
<LaserJock> StevenK: do you know how to find out in OS X?
<mwolson> (don't recall the acronyms for each format)
<StevenK> LaserJock: Does OS X spit out the CPU flags?
<imbrandon> LaserJock, about this mac --> more info
<TheMuso> mwolson: Right
<LaserJock> imbrandon: CLI?
<imbrandon> no
<imbrandon> apple in the top left
<TheMuso> Apple menu
<imbrandon> about this mac
<imbrandon> then more info
<LaserJock> no, no
<LaserJock> I mean I'm using CLI
<bddebian> WTF in a package can cause linda and lintian to explode?
<imbrandon> ohh not sure
<imbrandon> ummm lemme check
* TheMuso is going to sell his copy of OS X.
<StevenK> bddebian: Many things? :-P
<imbrandon> TheMuso, 10.5 ?
<StevenK> I didn't think 10.5 was out
<LaserJock> I found it
<imbrandon> its not
<imbrandon> StevenK, ^^
<StevenK> LaserJock: Does it have long mode?
<TheMuso> imbrandon: I have 10.4, originally got it to check out the screen reader, as I was helping people review/test at the time.
<TheMuso> I have no more use for it any more.
<LaserJock> systctl -a hw
<StevenK> TheMuso: From what I've heard, it's a pretty bad screen reader.
<TheMuso> StevenK: Yeah nothing that crash hot.
<StevenK> TheMuso: Sean called it "barely passable" if I remember correctly.
<TheMuso> StevenK: 10.5 is supposed to be better.
* imbrandon cant wait for 10.5
<StevenK> Sigh, Apple fanboys
<TheMuso> Meh. Stick with your 10.5 then and piss off.
<TheMuso> :)
<imbrandon> lol
* StevenK grins and high fives TheMuso
<ajmitch> strong language from TheMuso there :)
<LaserJock> I can't find anything
<bddebian> StevenK: I don't mean give errors and warnings, I mean literaly blow up
<TheMuso> ajmitch: heh
<StevenK> bddebian: Yes, I figured, and my answer doesn't change. :-)
<TheMuso> When typing, I usually hold back, and I only meant it in jest.
<bddebian> Well I've never seen it before
<imbrandon> ;)
<StevenK> TheMuso: I don't think I've seen you use strong language in person.
<TheMuso> StevenK: I do try and be polite no matter the situation.
<hub> guys, this is not #apple-fan-boys
<hub> so restrain yourself
<StevenK> TheMuso: And if worse comes to worse, you do have a cane .:-P
<TheMuso> There was one time when the f word managed to get in my every day vocabulary, and that was from being around a particular friend/on the phone with them too much.
<TheMuso> It took a while for me to get rid of that habbit.
<hub> TheMuso: when I use the f word, people complain to my boss
<imbrandon> hub, it is if it pertains to linux so thanks for the input
<TheMuso> but never in public, only when I was on my own.
<TheMuso> But still... I felt ashamed.
<hub> imbrandon: 10.5, linux?
<hub> imbrandon: let me think. 
<StevenK> hub: The Ubuntu that will be released in May, 2010? 
<imbrandon> hub, yes , features, useability, dualbooting compatibilty, need i go on?
* StevenK grins
<hub> StevenK: ahah
<hub> imbrandon: #mac_dev waits for you :-)
<imbrandon> hub, no #ubuntu-motu does, again thanks for your input
<LaserJock> darn it, I can't figure it out
<imbrandon> LaserJock, easiest way probably is to find the proc and just look it up on the web
<StevenK> Using links, if OS X has a text mode browser.
* TheMuso sighs
<imbrandon> ;)
<imbrandon> ahhh amarok done
<LaserJock> I've got lots of text mode browsers :-)
<TheMuso> imbrandon: We are starting to get people requesting help on the accessibility list about stuff that non-technically savy users would ask about.
<TheMuso> And its frustrating, as they would know the problems that still remain if they were to do some reading, but one just can't tell them to make sure they read everything before they try it out, especially if english isn't their native language.
<imbrandon> right
<LaserJock> imbrandon: is KDE sitll working ok in OS X?
<imbrandon> LaserJock, yea
<imbrandon> infact rick has nightly builds going for iot
<imbrandon> kde4 native, kde3 via fink and X
<imbrandon> i need to update the snapshot i have of it on my ibook
<LaserJock> imbrandon: ok, just found for sure that I have a Core Duo not Core 2 Duo
<imbrandon> what mhz ?
<imbrandon> or model
<bddebian> Gggaaaahhh WTF!!!
<LaserJock> 1.83GHz
<imbrandon> ahh yea probably one of the few 32bit ones done
<LaserJock> well, we've got 2
<LaserJock> and 2 G5's
<imbrandon> nice
<LaserJock> well, they replaces 4 linux machines
<LaserJock> which isn't so cool
<TheMuso> imbrandon: If we want to use another arch than intel for the builds, how do we get to it? Or are amd64/ppc not ready yet?
<imbrandon> wouldent mind a g5 or an xserv to run edgy on
<imbrandon> TheMuso, they arent online yet, one i still need to rack, and one i still need an IP for
<TheMuso> Right.
<TheMuso> Was just wondering thats all.
<imbrandon> i hope to have them going by sunday
<TheMuso> No hurry
<imbrandon> as a personal goal
<bddebian> StevenK: OK damnit, what can cause this?
<imbrandon> crimsun, any idea why is xfs recomended when installing flashplugin-nonfree
<imbrandon> Suggested packages: iceweasel msttcorefonts ttf-xfree86-nonfree xfs
<imbrandon> The following NEW packages will be installed: flashplugin-nonfree
<ajmitch> interesting
<ajmitch> xfs should be quite deprecated by now
<imbrandon> yea , but i still fail to see what an FS has to do with flash
<imbrandon> maybe some strange cary over from debian
<imbrandon> no idea
<ajmitch> xfs = font server
<imbrandon> ahh
<imbrandon> isnt/wasent there an XFS file system too ?
<imbrandon> e.g. reiser  etx{2,3} etc
<imbrandon> ext*
<ajmitch> sure
<imbrandon> ok makin sure my confusion wasent totaly unfounded
<bddebian> ajmitch: Any clue on this?  I'm freakin' lost.  It was working 30 minutes ago
<bddebian> http://pastebin.us/13747
<imbrandon> man kde3.5.6 is really slick and feisty kubuntu is really shaping up nicely i must say
<StevenK> bddebian: *blink*
<imbrandon> i was still recomending dapper to most people i meet that havent used kubuntu but feisty has put the polish back on it
<imbrandon> imho
<bddebian> StevenK: ??
<StevenK> bddebian: Can you run linda with -dd ?
<bddebian> StevenK: http://pastebin.us/13748
<StevenK> Crap.
<StevenK> I was hoping for more information.
<StevenK> Maybe it's a python2.5 ism
<ajmitch> bddebian: nothing so simple as a full disk? :)
<bddebian> Could it just be fs damage?  I've been having some weird fs problems lately
<bddebian> ajmitch: Not afaict
<StevenK> ajmitch: I ought to catch a full /tmp
<ajmitch> the error when raising an exception looks rather special
<StevenK> Indeed.
<StevenK> And the error has been thrown when it's trying to print out the exception. :-/
<ajmitch> yeah
<ajmitch> it should be possible to run linda with python2.4
<ajmitch> might be worth trying
<StevenK> I'm just about to try Linda with 2.5
<bddebian> This is an edgy machine it shouldn't even have 2.6
<bddebian> Err 2.5
<ajmitch> linda runs for me with 2.5
<ajmitch> how curious
<StevenK> And for me
<bddebian> It was working a few minutes ago, I'm telling ya..
<bddebian> I guess I'll fsck
<StevenK> bddebian: Can you edit /usr/lib/site-python/linda/unpack.py, line 176
<StevenK> bddebian: Just under the except OSError line, add in 'print e' at the correct indent, and re-run linda without the -dd
<bddebian> bdefreese@bdubuntu1:/usr/lib/site-python/linda$ linda /home/bdefreese/pbuild-feisty/result/libtifiles2-3_1.0.2-0ubuntu1_i386.deb
<bddebian> [Errno 13]  Permission denied: '/tmp/linda-lab-13922'
<StevenK> Ha
<StevenK> You don't have write access to /tmp
<bddebian> Why ha?
<bddebian> Why is that?
<StevenK> Your FS has been re-mounted read-only?
<bddebian> uhm..
<StevenK> Problem reproduced, too
<StevenK> steven@liquified:~% TMPDIR=/ linda /var/cache/pbuilder/result/aircrack_0.6.2-5ubuntu1_all.deb
<StevenK> Traceback (most recent call last):
<StevenK> ...
<bddebian> Fucking HD :-(
<StevenK> bddebian: dmesg, see if anything turns up
<bddebian> This has been happening for a little while now.  Though usually I get ro file system errors :-(
<StevenK> bddebian: Replace your drive.
<bddebian> This is the third one :(
<bddebian> POS
<StevenK> It might be the IDE controller, or the cable.
<StevenK> Cable is less likely.
<StevenK> bddebian: How's that for good news? :-P
<bddebian> It's a stinkin' ThinkPad, so even worse
* StevenK watches the testsuite of test linda build blow up.
<bddebian> heh
<StevenK> bddebian: If IBM have done the previous two drive switches, they should do something different on the third try.
<bddebian> They haven't, it's old
<bddebian> The second drive I pulled out of another R31 and this one is a brand new Toshiba drive
<StevenK> What errors is it throwing
<StevenK> ?
<bddebian> Now that's whacked.  /tmp is still 755
<rexbron> hey bddebian, care to take a look at soma now that TheMuso and sispoty have looked it over?
<TheMuso> rexbron: It was uploaded iirc
<bddebian> rexbron: I thought it got uploaded?
<TheMuso> According to the motu mailing list, yeah it did.
<rexbron> cool
<rexbron> I should subscribe to that
<TheMuso> I'd say that would be a very good idea.
<TheMuso> Anything really important for MOTUs and hopefuls is always going to be on that list.
<TheMuso> As well as important discussions re packaging decisions.
<TheMuso> related to universe
<imbrandon> off to work, see yall in a bit
<bddebian> Later imbrandon
<crimsun> imbrandon: it doesn't
<crimsun> imbrandon: the demotion to Suggests is part of the delta we carry in debian/control
<ScottK> bddebian: Are you up for another REVU?  http://revu.tauware.de/details.py?upid=4302
<bddebian> ScottK: What did you update?
<ScottK> It's an upstream update of one of my earlier packages.
<ScottK> No packaging changes, so in theory it should be easy....
<bddebian> No worries, just asking :-)
<bddebian> ScottK: 
<bddebian> cp: cannot stat `debian/INSTALL.Debian': No such file or directory
<bddebian> dh_installdocs: command returned error code 256
<ScottK> hmmm
* ScottK looks
<ScottK> There's also http://revu.tauware.de/details.py?upid=4303 waiting...
<ScottK> Figured it out.  Sorry.  New upload in a minute.
<TheMuso> Heya Hobbsee.
<Hobbsee> hey TheMuso 
<Hobbsee> right.  10h to update basket
<LaserJock> is that the notetaking app for kde?
<Hobbsee> yep
<Hobbsee> well, one of them.  it's the nicer one
<LaserJock> I was gonna try it, but I'm to CLI bound
<bddebian> ScottK: pypolicyd:  error: invalid Python installation: unable to open /usr/include/python2.5/pyconfig.h (No such file or directory)
<bddebian> make: *** [python-install-py]  Error 1
* ScottK looks.
<ScottK> Ugh.  Sorry.  I guess I'm not having a good day.
<bddebian> I know the feeling man :-)
<bddebian> Anyway, I gotta get to bed.  Gnight folks
<ScottK> Anyone else?  http://revu.tauware.de/details.py?upid=4305 is fixed.
<siretart> morning
<LaserJock> siretart!
<siretart> huhu LaserJock!
<ScottK> In addition to http://revu.tauware.de/details.py?upid=4305, http://revu.tauware.de/details.py?upid=4307 is also fixed up if anyone is available to revu...
<Fujitsu> Hi siretart, LaserJock.
<siretart> huhu Fujitsu 
<LaserJock> hi Fujitsu 
<ScottK> I can stay up for a bit if there is a useful task that someone with my level of inexperience could help out with...
<Fujitsu> Hm, 9.5 hours until UVF... there must be something :)
<siretart> as I didn't hear anything else, I assume the motu-uvf team didn't change since edgy, right?
<LaserJock> I guess
<siretart> k
<Hobbsee> siretart: seems so
<siretart> Hobbsee!! :)
<Hobbsee> hey siretart!!!
<LaserJock> does debsign work on binary .changes files?
<TheMuso> LaserJock: Why would you want to do that?
<TheMuso> Afaik it can yes.
<TheMuso> From reading the manpage earlier today.
<zakame> it should, why not?
<zakame> hi all btw :)
<TheMuso> Hey zakame.
<LaserJock> well, in the man page all I saw was for source pakcages
<TheMuso> Well its worth a try at the least.
<zakame> hoohoo!
<LaserJock> grrr
<ScottK> grrr?
<LaserJock> I can't figure out how to upload .debs
<LaserJock> I'm making a mini-dinstall repo
<LaserJock> and I got source packages to work
<LaserJock> but it says it keeps looking for a signature on the .deb .changes
<AnAnt> LaserJock: can I trick you to review a package ?
<LaserJock> probably not
<LaserJock> especially when you tell me you are tricking me ahead of time
<AnAnt> k
<AnAnt> hehe
<LaserJock> I'll be more available after this week
<AnAnt> can someone review this package : http://revu.tauware.de/details.py?upid=4298 ?
<LaserJock> woot! I got it
<LaserJock> I turned of the sig check
<LaserJock> *off
<ScottK> Good night everyone.  I think I'm about out of steam.
<AnAnt> ping Hobbsee , can you review this upload: http://revu.tauware.de/details.py?upid=4298
<LaserJock> ScottK: cya
<TheMuso> AnAnt: I am looking it over at the moment.
<AnAnt> TheMuso: thanks
<Fujitsu> LaserJock: May I enquire as to the purpose of this repo?
* LaserJock whistles innocently
<LaserJock> black market science apps
<Fujitsu> :O
<LaserJock> ;-)
<TheMuso> haha
<LaserJock> super secret government lab, Area 51 software
* Fujitsu isn't impressed with the black market soft drinks being sold out of lockers at school.
<TheMuso> Fujitsu: lol
<LaserJock> Fujitsu: I'm just doing some "research"
<Fujitsu> That's what happens when the government bans selling it in canteens.
<AnAnt> LaserJock: science apps ?
<Fujitsu> LaserJock: On what?
<LaserJock> Fujitsu: stuff ;-)
<AnAnt> LaserJock: is that a new repo for Ubuntu ? like MediUbuntu ?
<LaserJock> hehe no
<Fujitsu> Eeeeeeeeeeek.
<LaserJock> AnAnt: does MediUbuntu have it's own repo now?
* Fujitsu attacks AnAnt for accusing LaserJock of such treachery.
<LaserJock> I'm just looking at different repo tools
<LaserJock> apt-ftparchive, mini-dinstall, and reprepo
<Fujitsu> OK.
<Fujitsu> Not going to set up a full-blown dak? :P
<Fujitsu> And what about falcon?
<LaserJock> ummm, no
<LaserJock> well, I'm not sure about falcon yet
<LaserJock> it's a bit new
<StevenK> Fujitsu: dak is not for the faint of heart. :-)
* RAOF likes falcon.
<Fujitsu> StevenK, I've poked around with it, and I agree fully :)
<LaserJock> what repos is falcon in?
<RAOF> Seveas'.  And mine, I think.  I wonder why it's in mine?
<AnAnt> LaserJock: what do you mean by it's own repo ?
<StevenK> Fujitsu: I've submitted patches. :-P
<Fujitsu> StevenK: Sounds painful.
<LaserJock> I'm wondering if falcon is in any of the Ubuntu repos
<RAOF> I'm pretty sure it is.
<StevenK> Not according to madison-lite it isn't
<Fujitsu> It isn't.
<LaserJock> AnAnt: do they have their own repot in addition to Ubuntu's
* Fujitsu heads off to eat.
<LaserJock> I need stuff that's in the Ubuntu repos
* RAOF was sure there was an old version in Universe, but was mistaken.
<AnAnt> LaserJock: yeah, hang on
<AnAnt> LaserJock: deb http://medibuntu.sos-sts.com/repo/ edgy free non-free
<LaserJock> what the heck
<AnAnt> ?
<LaserJock> that repo has no science/medical packages
<LaserJock> it's all w32codec
<AnAnt> nope
<LaserJock> libdvdcss
<LaserJock> ffmpeg
<AnAnt> w32codecs , skype, googleearth
<AnAnt> very few stuff
<LaserJock> crazy
<AnAnt> LaserJock: are you interested in packaging science apps ?
<AnAnt> LaserJock: I was thinking of packaging gplcver indeed
<AnAnt> but I need to understand it's directory structure
<LaserJock> oh crap
<LaserJock> mediubuntu is multimedia ubuntu
<LaserJock> not medical ubuntu
* LaserJock head desks
<AnAnt> gplcver is a verilog compiler/simulator
<LaserJock> medubuntu is the medical one
<LaserJock> AnAnt: I'm the lead of the MOTU Science team
<LaserJock> so yeah, I'm interested in science apps
* Fujitsu is one of LaserJock's minions.
<LaserJock> lol
<AnAnt> well, electronics software falls in that category , right ?
<LaserJock> yes it does actually
<LaserJock> AnAnt: http://tiber.tauware.de/~laserjock/motuscience/feisty/all.html
<AnAnt> gplcver: http://pragmatic-c.com/gpl-cver/
<LaserJock> package it up! :-)
<AnAnt> I should try that indeed
<rraphink> LaserJock: how hard is it to generate the diff page?
<rraphink> you're using mdt for that?
<LaserJock> yeah
<LaserJock> it's not too tough
<rraphink> (hi by the way)
<LaserJock> I have the scripts on tiber
<rraphink> mdt compares source versions though, right?
<LaserJock> it basically produces everything
<rraphink> k
<LaserJock> rraphink: generate.bash at http://tiber.tauware.de/~laserjock/motuscience/scripts/ is the script I use
<lucas_> rraphink: LaserJock: we really should work on packaging & maintaining mdt ...
<LaserJock> yes
<Fujitsu> lucas_, I've got a patch or two that are in LaserJock's branch. There are some other things which I might implement soon.
<rraphink> lucas_: yes indeed
<rraphink> lucas_: I use it daily 
<LaserJock> it would be nice to collect all these tools, mdt, revu-tools, bug filing stuff
<lucas_> there's an svn repository for it on alioth
<rraphink> with dist-apt-cache and dist-apt-get
<rraphink> since I do a lot of backports/merges
<Fujitsu> mdt is invaluable for motuscience.
<LaserJock> for sure
<rraphink> LaserJock: I would like to modify mdt to use system-wide
<lucas_> I'll try to get some work done after the etch release
<lucas_> but I'm too busy currently
<rraphink> as in, having the possibility of defining the small chroots in /var/mdt or so rather than ~/.multidistrotools
<Fujitsu> We need to make a list of tools we want to write for Feisty, too.
<Fujitsu> rraphink: That might be nice.
<LaserJock> yep
<rraphink> lucas_: same here ;)
<rraphink> kind of fighting with time now
<LaserJock> I think cbx33 is also interesting in helping with motu helper scripts
<LaserJock> maybe we need a motu-scripters team :-)
* Hobbsee hears motu helper scripts.  which ones?
<Fujitsu> Integrating stuff like ajmitch's bug thing, and MoM-like functionality with mdt would also be nice.
<LaserJock> yep
<lucas_> well, I'm not sure. I'd like mdt to stay distro-agnostic
<lucas_> (as much as possible)
<rraphink> Hobbsee: talking about mdt initially
<Fujitsu> lucas_, as would I, but these would be optional.
<Hobbsee> ah
<LaserJock> lucas_: sure, but there's no reason to put a bzr branch on LP
<Fujitsu> Making version2html plugin-able would facilitate that.
<LaserJock> yeah
<lucas_> yup
<Fujitsu> Then we can add comments, bugs, etc.
<lucas_> err comments and bugs are already there
<Fujitsu> Sort of.
<LaserJock> well, as fields I think is what he's saying
<Fujitsu> It'd be nice to have a more live comment system.
<Fujitsu> And bugs similar to what ajmitch's script produces.
<lucas_> which script ?
<Fujitsu> See !topic
<Fujitsu> */topic
<lucas_> ok
<lucas_> ah yes
<lucas_> but that's Debian bugs
<lucas_> LP bugs are a PITA (no xmlrpc interface, etc)
<Fujitsu> Yep.
<Fujitsu> LP bugs are a little too difficult at the moment, but they're less important from our end.
<ajmitch> Fujitsu: note that my script relies on a local copy of the BTS data
<LaserJock> sure, but I think it's important to put these scripts somewhere central
<ajmitch> otherwise it would take days to run :)
<LaserJock> so people can work on them, etc
<ajmitch> sure
<LaserJock> it's kinda annoying when nobody knows where things are or that they even exist
<lucas_> ajmitch: is it possible to fetch BTS data without being a DD ? if so, we could set up a copy on tiber
<lucas_> I think it's possible with rsync, but I'm not sure
<Hobbsee> hey dholbach 
<siretart> lucas_: yes, the BTS interface is publicly accessible
<dholbach> good morning
<dholbach> hey Hobbsee
<siretart> lucas_: the BTS-LDAP interface, that is
<Hobbsee> :)
<siretart> huhu dholbach!
<dholbach> hey siretart
<LaserJock> hi dholbach 
<dholbach> hey LaserJock
<ajmitch> siretart: *far* too slow
<ajmitch> siretart: the script I did processes several thousand bugs, and needs info that the ldap interface doesn't expose
<siretart> ajmitch: ah, you did experiment with that?
<ajmitch> yep :)
<siretart> I see
<LaserJock> ajmitch: how big did it end up being?
<siretart> are you sure that all parts of debbugs are public? if so, we could perhaps ask aba to extend the ldap schema and install an ldap slave on tiber
<ajmitch> LaserJock: I didn't grab the archived bugs
<siretart> s/so/not/
<dholbach> hey ajmitch - did you have luck with glom and pycentral?
<ajmitch> dholbach: no, I didn't sorry
<ajmitch> siretart: even if that's the case, ldap is many many times slower than opening the summary files for each bug
<siretart> ajmitch: k
<siretart> just a thought
<dholbach> ajmitch: no problem... just wanted to check back
<ajmitch> the unarchived bugs alone are 12GB
<siretart> dholbach: I assume we proceed with motu-sru as with edgy, right?
<siretart> I'm sorry that I didn't had the time to follow the last motu meetings :(
<ajmitch> sru or uvf?
<siretart> argl
<siretart> UVF that i
<siretart> s
<ajmitch> we took an executive decision & said it's the same :)
<ajmitch> see LaserJock's mail to the list
<dholbach> siretart: makes sense - better to get going and let the MOTU Council figure out a process (for motu-uvf) and timeline for the next UVF
<siretart> dholbach: I fully agree
<dholbach> ok cool
<ajmitch> we were discussing it a few hours ago
<siretart> oha?
<ajmitch> yes, you did read LaserJock's email to ubuntu-motu?
<siretart> I didn't read mailling list yet, I'm currently at work (again)
<ajmitch> ah, ok :)
<siretart> ah, there it is. yes, that's exactly the process we used for edgy, and I think it worked quite well
<ajmitch> why change what works? :)
<lucas_> will some of you be at FOSDEM ?
* ajmitch certainly won't be
<SWAT> lucas_, will you be there?
<lucas_> yes
<SWAT> just go to the Ubuntu-BE stand and we'll surely meet
<giskard> morning guys :)
<ajmitch> hello giskard 
<giskard> i'm still in time if i want put the entire beryl suite into universe?
<ajmitch> barely
<giskard> it's a lim barely -> no or yes? ;P
<LaserJock> Feb. 22nd is the deadline
<LaserJock> imbrandon is working on it this week
<LaserJock> you guys should talk to each other
<dholbach> probably put packaging in bzr to speed up the process
<giskard> LaserJock, i pinged him 2 times in the last 2 days without answer i thought he was busy
<giskard> we packaged the netire suite 3 months ago me fabo and him + some great work of the debian maintainer
<giskard> (shawn)
<LaserJock> giskard: he his, but he just said tonight that he was going to work on it
<LaserJock> ok, I'm off
<LaserJock> good night all
<viviersf> erf
<somerville32> If I'm packaging a binary package, should I install the libs that it provides or should I ignore them and add them as dependencies?
<somerville32> By binary package, I mean a source package that only includes binaries and not the source code (ie. multiverse)
<AnAnt> can pbuilder be used to build several packages (*.dsc) in the same run ?
<dholbach> you could   sudo pbuilder login   and then do it manually
<AnAnt> dholbach: how ?
<dholbach> it behaves like a normal chroot then: get the source in the chroot, then run    sudo apt-get build-dep <...>; fakeroot apt-get source -b <....>
<AnAnt> ic
<AnAnt> thanks
<\sh> moins
<Le-Chuck_ITA> Hi all
<Fujitsu> Hi Le-Chuck_ITA.
<Le-Chuck_ITA> any news for me?
<Le-Chuck_ITA> yes I still didn't go to my upload
<Le-Chuck_ITA> going now
<Fujitsu> Is `Accepted xournal 0.3.3-0ubuntu1 (source)' what you wanted to hear?
<Le-Chuck_ITA> yes :)
<Fujitsu> I thought so.
<Fujitsu> It seems to have built successfully, too. So it's done.
<Le-Chuck_ITA> Thank you a lot
<Fujitsu> No problem.
<Le-Chuck_ITA> I will be able to just tell people to install ubuntu on their tablet if they want it as beautiful as mine
<Le-Chuck_ITA> hmmm - if the wacom tablet bug will get fixed soon or later but that's another story
<Le-Chuck_ITA> there is a dependency bug opened but I suspect there are serious problems hidden behind that
<Le-Chuck_ITA> there was people asking me what software to use on linux for the tablet, that's why I got engaged with the xournal update :)
<Le-Chuck_ITA> Fujitsu: do I have to delete my upload to revu?
<Fujitsu> I have archived it, so it's off the main list.
<Le-Chuck_ITA> ok - so I am again noise in the universe - happy to hear this :) Ok I go back to my work now, it's better. Will come here back as soon I can do something else for universe
<Fujitsu> Again, thanks for the help.
<Le-Chuck_ITA> goodbye and see you soon
<RAOF> Is "gauvainpocentek@yahoo.fr" here?  I'm not certain what one of the comments on the review of the gimmie package means.
<Fujitsu> That would be gpocentek.
<gpocentek> RAOF: which comment?
<gpocentek> which part of the comment? :)
<RAOF> The "need more dependencies on python-gnome*" one.  Do you mean build depends, or package depends?
<gpocentek> package depends IIRC
<RAOF> I thought ${python:depends} *was* meant to magically work out the dependencies.
<Fujitsu> Hobbsee! You've got 5 hours to update every package in {un,mult}iverse to the latest upstream version. Get going!
<RAOF> I'll add them in manually, then.
<gpocentek> yep, there's no magic to find python dependencies
<RAOF> Awww.  Python:depends lies :(
<imbrandon> hrm
* imbrandon grumbles
<TheMuso> Where can my assistance be used most atm?
* TheMuso has had an enjoyable test/debug/report bug day.
<Hobbsee> Fujitsu: ARGH!!!!!!!!!!!!!!!!!!
<Hobbsee> Fujitsu: you too.  get going!
<TheMuso> Fujitsu: Do you have sonata covered?
<TheMuso> ah I see a bug in progress for it.
<TheMuso> I'll leave it in your capable hands then.
<Fujitsu> That sonata merge isn't affected by UVF.
<Fujitsu> (and I forgot to set that bug to Fix Released a number of days ago)
<TheMuso> But uvf isn't in effect yet is it?
<Fujitsu> Not yet, no.
<Fujitsu> Not for 4.5 hours.
<TheMuso> heh right
<Fujitsu> Hrm, what about audacity?
<TheMuso> I can do that.
<Adri2000> not sure if it's a stable release
<Fujitsu> It's not, but Debian has it.
<Fujitsu> What effect is UVF meant to have on native packages?
<Adri2000> yep
<Adri2000> no effect I'd say, but I don't know...
* TheMuso is now a member of the Ubuntu audio team.
<TheMuso> Has been for a few days
<siretart> TheMuso: congrats! :)
<siretart> TheMuso: how does the ubuntu audio team relate to MOTUMedia?
<Fujitsu> siretart: Evening.
<siretart> Fujitsu: just had lunch here ;) - hi!
<TheMuso> siretart: I dunno. crimsun asked me to join, as I am involved with ubuntustudio on the edges.
* Fujitsu wonders if we can somehow get motumedia-tauware merged with motumedia.
<siretart> there is a group motumedia-tauware?
<Fujitsu> Yes.
<siretart> wtf?!
<Fujitsu> Automatically created.
<Fujitsu> (so it's listed as the maintainer for the packages)
<Fujitsu> I think we should be able to get it merged with motumedia, so that the maintainer link goes somewhere real.
<siretart> wow! - thats the solution!
<siretart> thanks for notifying me!
<Fujitsu> Asking in #launchpad might do something.
<TheMuso> As for ubuntu-audio, there are only 7 of us, with crimsun doing the bulk of the work I'll bet.
<TheMuso> So I will try and help take some fo his workload if need be.
<TheMuso> for universe at least.
<Hobbsee> Fujitsu: siretart file a support ticket
<Fujitsu> Hobbsee, that's the proper way to go about it?
<Hobbsee> Fujitsu: if you dont have access to the email account of the address you want merged, yes.
<Fujitsu> TheMuso: What packages are under ubuntu-audio's jurisdiction at the moment?
<siretart> An email message was sent to motumedia@tauware.de. Please follow the instructions on that message to complete the merge.
<siretart> I do have access to motumedia@tauware.de
<TheMuso> Fujitsu: I haven't looked yet.
<TheMuso> How does one look that up?
<Hobbsee> siretart: then you can do it that way.
<Fujitsu> siretart: Hopefully that will work.
<Hobbsee> TheMuso: launchpad.net/~ubuntu-audio/+packages, i epxect
<TheMuso> um.... somehow I don't think I will be touching audacity *JUST* yet.
<siretart> darn. it actually sent the account to me
<TheMuso> Hobbsee: Thanks.
<siretart> and tries to merge this with the account 'siretart' - that's bullshit
<Fujitsu> siretart, terrific.
<Fujitsu> Support ticket it is.
<Hobbsee> siretart: argh, as that's a group.
<Hobbsee> support ticket it definetly is
<siretart> ok, I'm filing one
<Fujitsu> Thanks, siretart.
<siretart> wow. there are tons of support tickets open :(
<Hobbsee> siretart: mine got answered within ~12 hours, iirc.
<Hobbsee> seeing as accoutn merges are simple, and all
<siretart> lets try
<TheMuso> Looks like ubuntu-audio has nothing listed in terms of packages.
<Fujitsu> https://launchpad.net/launchpad/+tickets is quite ugly at the moment :-/
<Fujitsu> TheMuso, check +packagebugs.
<siretart> Fujitsu: the thing is that with the group merged, I fear launchpad will recreate that group on the next upload
<Fujitsu> motumedia will grab the email, so it won't.
<siretart> as long as it doesn't get that contact adresse, I'm fine
<TheMuso> Fujitsu: Thanks
<Hobbsee> Fujitsu: ouch.  interesting its' taking so long.
<Hobbsee> siretart: it grabs the address in the debian/changelog
<Fujitsu> What's taking so long, Hobbsee?
<Hobbsee> siretart: not the one that signed the mail, or anything like that
<Hobbsee> Fujitsu: those support tickets - lots look simple
<siretart> Hobbsee: I don't want bugs to be mailed to that contact address
<Hobbsee> siretart: true.  
<Fujitsu> siretart, you might be able to make it not a contact address.
<Fujitsu> Probably best to ask the LP guys about the behaviour.
<siretart> Fujitsu: https://answers.launchpad.net/launchpad/+ticket/3571
* Fujitsu subscribes.
<Hobbsee> siretart: how are you getting the first copy of the mail though?
<siretart> Hobbsee: err, which mail?
<Hobbsee> siretart: bugmail, sorry
<Fujitsu> Hobbsee, I wondered that too. If there is a contact address, team members won't get the mail.
<siretart> Hobbsee: both me and the team got subscribed to the bugs
<Hobbsee> siretart: why did you get subscribed though?
<siretart> Hobbsee: a) I filed bugs, b) the bug got assigned to me
<Hobbsee> ah.
<Hobbsee> you cleraly dont have an email client that filters all duplicate mails.
<siretart> Hobbsee: that's not possible, because mailman mangles the mails
<Hobbsee> good point
<siretart> I'm pasting this chat to the ticket, okay?
<Fujitsu> Oh no, it's highly confidential :P
<siretart> :P
<RAOF> How can I fix an "error '553 could not create file' during ftp transfer of specto_0.2....dsc" when trying to upload to revu?
<RAOF> gpocentek: I've addressed your comments, and added a manpage for good measure.  Care to revu again?  http://revu.tauware.de/details.py?upid=4217
<Hobbsee> RAOF: dput -f? 
<RAOF> Hobbsee: Tried that first, doesn't work.
<Hobbsee> !doesntwork
<ubotu> Sorry, I don't know anything about doesntwork - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Hobbsee> !doesn'twork
<ubotu> Sorry, I don't know anything about doesn'twork - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Hobbsee> !doesn't work
<ubotu> Please elaborate, your question or issue may not seem clear or detailed enough for people to help you. Please give more detailed information, errors, steps, and possibly configuration files (use the !pastebin to avoid flooding the channel)
<Hobbsee> !doesntwork is <alias> doesn't work
<ubotu> I'll remember that, Hobbsee
<Hobbsee> !doesnt work is <alias> doesn't work
<TheMuso> Hobbsee: You and that damn bot. :)
<RAOF> No, I love that bot too :)
<Hobbsee> TheMuso: :P
* LongPointyStick pokes TheMuso 
<RAOF> Hobbsee: http://paste.ubuntu-nl.org/4702/
* Fujitsu slices the LongPointyStick into a lot of small pieces.
* RAOF makes a note that good question technique applies to himself, too.
<TheMuso> Fujitsu: heh
* LongPointyStick repairs metalwork, and slices Fujitsu up into lots of tiny pieces, and stomps on them.
<Fujitsu> Damnit.
* Fujitsu hides his pieces in a corner.
<TheMuso> LongPointyStick: You just ruined his good work ethicv.
* Hobbsee notes she could probably fix that
<Hobbsee> TheMuso: oh dear
<viviersf> hi, soz to bother but who manages the build servers ?
<TheMuso> viviersf: Whats the problem?
<viviersf> nothing, just want to know how it is set up and how it works
<Fujitsu> It is all dark, proprietary Canonical magic.
<viviersf> not its not man
<Fujitsu> Yes it is.
<TheMuso> heh
* viviersf kungfus canonical magic
* TheMuso can't help but feel so carefree and peaceful as he chills to music.
<TheMuso> And waits for a package to finish in pbuilder.
<viviersf> lol
* TheMuso should set up pbuilders on his p4 tomorrow.
<TheMuso> Take less time. :)
<Hobbsee> yay, logged into revu
* RAOF looks at his beautiful null lintial output
<TheMuso> RAOF: ROFL
<RAOF> Maybe lintian on revu should be updated, though.  Null output is still almost 1 K :)
<Hobbsee> revu's still breezy, sitn it?
<Hobbsee> nope, it's dapper now
* TheMuso pats mpd. You are doing very well with your random selection.
* RAOF wonders whether TheMuso knows enough about revu to fix his problem.
<Hobbsee> RAOF: he doesnt
<Hobbsee> siretart: argh, how do i fix this?
<Hobbsee> http://paste.ubuntu-nl.org/4702/
<TheMuso> RAOF: Whats your problem?
<RAOF> That pastebin
<_ion> I'd be thankful if a MOTU reviewed compiz-extra <http://revu.tauware.de/details.py?upid=4133> before the freeze. It contains the 'state' plugin, which is essential for me. It allows one to define rules such as "open Firefox windows on desktop 1", "view mplayer windows brighter than the other windows" etc.
<Hobbsee> oh, found the files
* Hobbsee wonders if she can just rm them.
<RAOF> As far as I'm concerned, you're welcome to.
<TheMuso> RAOF: I don't remembrer seeing a pastebin URL.
<Fujitsu> _ion: That has until the 22nd, fortunately.
<RAOF> TheMuso: The one right above your "what's your problem?" post.
<Hobbsee> oh, i dont have permission to remove it anyway
<RAOF> I tried looking at the "dcut" man page, as the error suggests.
<_ion> fujitsu: Nice.
<TheMuso> RAOF: Is this a fresh install of dput?
<RAOF> TheMuso: No
<TheMuso> This sounds like a problem on the server side IMO.
<TheMuso> RAOF: Has it worked before
<RAOF> It's been succesfully used to upload a gimmie package not five minutes ago
<Hobbsee> yes, it's server side
* Hobbsee isnt in hte correct group
* ..[topic/#ubuntu-motu:Adri2000] : to: Ubuntu Masters of the Universe: Universe Repository Maintainers | http://wiki.ubuntu.com/MOTU | http://wiki.ubuntu.com/MOTU/Documentation | Add yourself to http://tinyurl.com/fgpgy to upload to REVU | Check these packages for syncs/merges: http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.html | It's REVU sprint!
<Hobbsee> siretart: am i supposed to be in the REVU & pbuilder groups?  the revu one, in particular.  if not, can i be?
<RAOF> Fujitsu: Does gnome-compiz-manager have until the 22nd, too?
<Fujitsu> New packages are due by the 22nds.
<Fujitsu> *22nd
<Fujitsu> New upstream versions of existing pages have about 4 hours.
<Fujitsu> *packages
<RAOF> Aaaah, *that's* what "Upstream version freeze" refers to.
<TheMuso> RAOF: Well since its server side, I can't help you. siretart may be able to however.
<TheMuso> Or another admin like ajmitch, but I don't think he's around.
<Hobbsee> revu:x:1003:siretart,ajmitch,raphink,revu1,jcorbier,gauvain,brandon,laserjock
<ScottK> Speaking of about 4 hours...  I'd appreciate a revu of http://revu.tauware.de/details.py?upid=4305.
<Hobbsee> any of htem
<raphink> hmpf
<RAOF> Thanks.
<Hobbsee> ScottK: didnt the older version have two acks?  why the newer versions?
<ScottK> Good morning everyone.
<ScottK> New upstream release.
<ScottK> There are some significant benifits to the new version.  
<Hobbsee> ah
<siretart> Hobbsee: I added you to the pbuilder group, sorry my fault that I missed that
<siretart> Hobbsee: just relogin
<Hobbsee> siretart: presumably then i can rm the files from http://paste.ubuntu-nl.org/4702/ then?  that's how we handle such things?
* Fujitsu heads off to bed.
<Fujitsu> Happy UVF, everyone :P
<siretart> Hobbsee: I added you to the group 'revu' as well, now you can remove those files from /home/ftp/incoming
<siretart> Fujitsu: sleep well!
<Hobbsee> siretart: as in, that's what we do, or is there something else instead?
<TheMuso> siretart: What use is a shell account for on tauware?
<siretart> TheMuso: none :P
<TheMuso> siretart: Right.
<TheMuso> Just curious.
<siretart> TheMuso: access to various pbuilders and access to the revu infrastructure
<siretart> Hobbsee: depends on case. most time I only remove, sometimes I mv to rejected
<TheMuso> siretart: RIghto. Was just wondering.
<Hobbsee> siretart: what's the dcut stuff?  also from RAOF?
<RAOF> Oh, that actually went somewhere, did it?
<Hobbsee> seems to have
<siretart> Hobbsee: revu doesn't support dcut. dak (the debian archive software) does
<Hobbsee> siretart: gotcha.  removed as well
<RAOF> Ta, Hobbsee.
<siretart> however ppl keep uploading dcut files
* Hobbsee wonders what dcraw_8.53.dsc is
<Hobbsee> what the...
<siretart> Hobbsee: sometimes ppl upload before the keyring got synced. the cronjob will move the .changes file to rejected then
<Fujitsu> siretart: dput does say to use dcut if a file exists.
<Hobbsee> siretart: why can i rm -rf the files, but not less them?
<Hobbsee> ahh, gotcha
<siretart> Hobbsee: in these cases just mv the .changes file back and rerun the process-incoming script
<Hobbsee> hobbsee@tiber:/home/ftp/incoming$ less dcraw_8.53.dsc
<Hobbsee> dcraw_8.53.dsc: Permission denied
<Hobbsee> right
* Hobbsee doesnt know about the process-incoming script, and cant see documentation on it
<siretart> Hobbsee: yes, the permissions are weird, I'm too lame to configure vsftpd properly :/
<Hobbsee> siretart: so i cant actually view the files at all, if needed? just remove them?
<siretart> >> sudo crontab -u revu1 -l
<siretart> */5 * * * *     test -x /srv/revu1-production/scripts/process_uploads.sh && /srv/revu1-production/scripts/process_uploads.sh
<siretart> that's the script which runs every 5 mins. you should have access to that
<siretart> Hobbsee: I agree that's very weird
<Hobbsee> siretart: but i cant exectue it, as i'm not root?
<siretart> as the files don't have proper permission
<Hobbsee> siretart: right.  fair enough
<siretart> Hobbsee: thanks for your interest in this. this motivates me to fix the vsftpd :)
<Hobbsee> siretart: :)
<Hobbsee> siretart: i can poke you with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!  too, if that helps :)
<siretart> Hobbsee: keep poking me. right now I have a presentation to prepare for tomorrow :(
<Hobbsee> siretart: fiar enough.  go do that :)
<tsmithe> hi
<tsmithe> dfsg question
<tsmithe> i have http://revu.tauware.de/details.py?upid=4097 (alsa-firmware). korg1212 firmware is non-free and in the upstream tarball. should the package have a dfsg version?
<siretart> tsmithe: if 'your' orig.tar.gz has that file removed, yes
<tsmithe> it doesn't
<tsmithe> so i guess that means i don't?
<siretart> tsmithe: if your package contains non-free material, I cannot enter ubuntu/universe
<tsmithe> yes
<tsmithe> i know
<tsmithe> i'm thinking
<tsmithe> i'm gonna repackage the orig
<siretart> tsmithe: please not as well that no package in universe can depend on packages in multiverse
<tsmithe> indeed
<siretart> +e
<tsmithe> :)
* tsmithe is going mad. just typed /join into terminal instead of cd
<raphink> hehe
<raphink> sync
<raphink> find . -name tsmithe -type u
<tsmithe> invalid argument u
<raphink> ah
<raphink> :)
* tsmithe is out
<raphink> killall tsmithe
<raphink> :)
<tsmithe> actually, `killall bip` would do the trick over here :)
<ScottK> tsmithe: If you remember the old Dell Latitude sound problem you helped me with a couple of weeks ago -  It works correctly in Feisty, so progress.
<tsmithe> hmm ok
<tsmithe> could you pm me the bug report number?
* tsmithe has to go to lunch now :)
* ScottK has not yet found it again, but will do so.
<tsmithe> :)
<tsmithe> cheers
* TheMuso heads off to bed.
<TheMuso> Night folks.
<ScottK> Good night.
<TheMuso> Happy uploading.
<Hobbsee> night TheMuso 
<jenda> Somebody's asking me this question:
<jenda> how long does it usually take for an update to go from dapper-proposed to dapper?
<Hobbsee> jenda: depends what phase the moon is in
<Hobbsee> and wind direction
<jenda> "there is a bug in the lighttpd package since ages"
<Hobbsee> and how many pepole actually test the correct package from teh correct repo
<jenda> "and the fix is only in -proposed so far"
<jenda> "my lighttpd crashes every morning at 6 o'clock"
<Hobbsee> tell them to test the proposed fix and report back on the bug report
<jenda> lol :)
<Hobbsee> hehe
<RAOF> 'Night all.  Thanks again Hobbsee, and gpocentek.
<jenda> ok, thx Hobbsee
<ScottK> Confirmation of the MOTU Council made it in to Linux Weekly News - http://lwn.net/Articles/220713/ - It gets a brief mention in the subscription only section.
<ScottK> If any MOTU is available for reviewing, I've got two packages I'd like to get in before UVF.  This one - http://revu.tauware.de/details.py?upid=4305 - is important enough (for reasons I'll be glad to go into in private) in my book that I'll write a UVF exception request for it.  The other - http://revu.tauware.de/details.py?upid=4307 - would be nice to get in, but is not essential.
<Hobbsee> ScottK: ping?
<ScottK> Hi
<Hobbsee> ScottK: why dont you have your email address next to your name in the maintainer field?
<ScottK> Because I'm an idiot?
* ScottK looks
<Hobbsee> heh
<Adri2000> +Maintainer: Scott Kitterman <scott@kitterman.com>
* Hobbsee didnt know you were the upstream author too
<ScottK> Ahh
<Hobbsee> oh, so revu is just going crazy
* Hobbsee uploads
<ScottK> Yes.  I took that package over last month specifically to get it upgraded for Feisty.
<ScottK> Thank you Hobbsee.
<Hobbsee> er, test building first though
<ScottK> Sure.
* ScottK will sit here and be ready to fix anything that went wrong... (fingers crossed and all that)
* Hobbsee wonders why the other one wasnt uploaded the first time around
<Hobbsee> or was it?
<ScottK> It was.  This is another upstream update.
<Hobbsee> gotcha
<Hobbsee> and it's *still* sitting in binary NEW, it looks like.  or it didnt build
<ScottK> That's been confusing me.
<ScottK> If you look at the package detail, it says it build, but there it sits.
<ScottK> The old version just build-depended on python, not python-all-dev and would build before the Python 2.5 transition, but won't now.  The upstream update also now build-depends on python-all-dev, so I think it'll take care of that too.
<Hobbsee> ScottK: 
<Hobbsee> sarah@LongPointyStick:~/Desktop$ md5sum pypolicyd-spf*
<Hobbsee> 4df5212556649d75ced53e80dec83e6a  pypolicyd-spf_0.2.orig.tar.gz
<Hobbsee> 93f44e0e858c1e9ca5abe94bdafadd01  pypolicyd-spf-0.2.tar.gz
<Hobbsee> hey dholbach 
<dholbach> hey Hobbsee
<Hobbsee> ScottK: why'd you repack that one?
* ScottK didn't (I don't think).
<Hobbsee> (and why's it not noted in the changelog?)
<Hobbsee> ScottK: clearly you have, else the md5sums would match :)
<Hobbsee> ScottK: want to have another go at that one?
<ScottK> Yes.
* ScottK slips off into the corner...
<Hobbsee> ScottK: 
<Hobbsee> Uploading to ubuntu (via ftp to upload.ubuntu.com):
<Hobbsee>   postfix-policyd-spf-perl_2.001-0ubuntu1.dsc: done.
<Hobbsee>   postfix-policyd-spf-perl_2.001.orig.tar.gz: done.
<Hobbsee>   postfix-policyd-spf-perl_2.001-0ubuntu1.diff.gz: done.
<Hobbsee>   postfix-policyd-spf-perl_2.001-0ubuntu1_source.changes: done.
<Hobbsee> Successfully uploaded packages.
<ScottK> Cool.  Thanks.
<Hobbsee> :)
* Hobbsee thought it was still a new package
<ScottK> Hobbsee: Another go at the 2nd package can be found at http://revu.tauware.de/details.py?upid=4314
* ScottK discovers he shouldn't have been releasing software at 1 AM last night after just 4 hours of sleep the night before.
<Hobbsee> 5fb5820c8da76969234cb0ddaae10413  pypolicyd-spf_0.2.orig.tar.gz - should be 93f44e0e858c1e9ca5abe94bdafadd01
<ScottK> Is it possible there's a stale orig.tar.gz on REVU?
<ScottK> When I updated the package I went back to the source, downloaded it again, unpacked it, and renamed it.  That's it.
<ScottK> There are two versions of pypolicyd-spf-0.2.tar.gz that have existed as I initially released the update last night with the debian dir in the tar.gz (thus my comment above).
<ScottK> I believe that I used the wrong one on my first upload.
<ScottK> Hobbsee: Would you please purge the package and I'll upload it again?
<Hobbsee> ScottK: you should be able to -f it
<ScottK> I did before, but that doesn't seem to have done it.... ;-(
<Hobbsee> it's a different md5sum to before, too...
<ScottK> That's because I just fixed the upstream package (I'm the upstream for this one too).
<bddebian> Heya gang
<Adri2000> hi bddebian 
<bddebian> Heya Adri2000
<ScottK> Heya bddebian
<bddebian> Hello ScottK
<ScottK> Hobbsee: I'm trying to understand what's going on here...  When you say "should be 93f44e0e858c1e9ca5abe94bdafadd01" where is that md5 coming from?
<Hobbsee> the upstream site that you've gotten listed in debian/copyright
<ScottK> OK.
* Hobbsee --> bed
<ScottK> Hobbsee: Thanks for the help.
<Hobbsee> not a problem
* ScottK looks at bddebian...
* bddebian runs away
<bddebian> :-)
<ScottK> Woudl you please look at http://revu.tauware.de/details.py?upid=4314 - I'd like to get it in before UVF if I can.
<ScottK> bddebian: It's not courier.
<bigon> bddebian: I've answer to your question for http://revu.tauware.de/details.py?upid=4255
<bigon> Could someone tell me if package currently in the new queue will be included in universe despite the uvf?
<bddebian> Should be but I don't know for sure
<bigon> because pam-keyring is stuck for a week now :(
<Adri2000> yeah no problem, the freeze for new packages is on 22nd
<ScottK> bigon: Yours isn't the only one.  I've been watching for movement too and not seeing it.
<bddebian> Researching the Quran.. Hmm
<bigon> ok thanks :)
<bddebian> bigon: Have you tried building this with gcj?
<Lutin> Adri2000, bddebian : could you you have a look at http://revu.tauware.de/details.py?upid=4316 when you'll have some time ?
<Adri2000> yep
<Lutin> thx :)
<bigon> bddebian: ?
<bddebian> bigon: I wondered if you have tried building with gcj-compat instead of sun java
<bddebian> bigon: BTW, zekr FTBFSs for me
<ScottK> bddebian: Are you going to upload http://revu.tauware.de/details.py?upid=4314 then (It's not a new package)?
<bigon> bddebian: I'm sorry I don't know what your talking about, i have not uploaded any java package
<bddebian> bigon: Isn't zekr yours?
<bigon> bddebian: nop
<\sh> is anyone using a hp machine with a p800 sas/sata controller? 
<bddebian> bigon: Ah, sorry
<\sh> eventually with a MSA 60 attached with full capacity 500 or 750 GB hds?
<bigon> bddebian: np :)
<bddebian> Heya geser
<geser> Hi bddebian 
<ScottK> bddebian: Sorry to keep bugging you, but since it's about 80 min to UVF...  Do I need to find another reviewer or will you upload?
<bddebian> ScottK: Damn man..  Already uploaded. :-)
<bddebian> geser: If you get a minute could you check out libtifiles2 on REVU for me?
<geser> bddebian: I'll have lunch in a minute but after that I can look at it
<ScottK> bddebian: Sorry.
<bddebian> geser: Awesome, thx
<bddebian> ScottK: No worries :-)
* ScottK is interested to know what he could do to help out with the REVU sprint?
<ScottK> could/should I guess...
<shawarma> Could someone explain the difference between feature freeze and uvf?
<bigon> bddebian: If you have a minute, what about http://revu.tauware.de/details.py?upid=4255 (new upstream version for sylpheed)?
<shawarma> UVF is the deadline for new versions of existing packages while FF is deadline for entirely new packages?
* ScottK thinks UVF = new versions of existing packages and FF = New packages.
<ScottK> shawarma: I think so.
<shawarma> Then why on Earth is FF *after* UVF? That's just weird.
<bddebian> bigon: I would like some other input from another MOTU before jumping Debian versions, sorry
<crimsun> shawarma: consider this case: I'm working on ardour 2, which is a completely new package and not an update to the existing ardour
<ScottK> shawarma: I wonder too.  Initially I thought that UVF just applied to synch/merge from Debian, but it doesn't appear to be planned that way.
<bigon> bddebian: ok
<shawarma> crimsun: Yes... Am I supposed to have some sort of epiphany now? :-)
<shawarma> crimsun: I still don't get it.
<bddebian> crimsun: Do you have any thoughts on jumping Debian's version of sylpheed?
<shawarma> crimsun: Adding new packages seems more drastic than just updating current ones, hence I'd expect the deadline to be sooner.
<ScottK> On the gripping hand...  A new package isn't going to break anything someone else was already using, so more risk may be acceptable..
<bddebian> shawarma: Typically adding new packages doesn't have any depends/build-depends ramifications.  New versions of existing packages can
<crimsun> shawarma: originally the later FF allowed for more review time; that shouldn't have changed
<crimsun> ScottK: that's essentially it
<crimsun> which one-third of our MOTU trinity also stated
<shawarma> We have a trinity now?
* ScottK thinks that perhaps packages that are new to Feisty should be allowed to be updated to FF.
<crimsun> shawarma: yeah, bddebian, LaserJock and imbrandon
<bddebian> s/bddebian/crimsun/
<crimsun> pssht, I'm a mere peon
<bddebian> not hardly
<crimsun> true, not hardly but definitely
* crimsun -> lecture
<bddebian> Gah
<ScottK> bddebian: You've got 62 minutes for Bug 83176 if you're feeling adventerous...
<Ubugtu> Malone bug 83176 in courier "courier: merge new debian version 0.53.3-4" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83176
* ScottK hides
<shawarma> Are we still syncing stuff from Debian or do I have to poke someone?
<bddebian> Syncs haven't been automatic in a while if that is what you mean
<shawarma> bddebian: It is. What do i do? Create a bug on launchpad and subscribe u-a?
<bddebian> Yep
<ogra> given that UVF is today you should also prepare an UVF exception request
<shawarma> ogra: I still have 38 minutes to go. :-)
<geser> ogra: doesn't it depend on what he wants to get synced? for new debian revisions aren't UVF exceptions needed, are they?
<ogra> geser, https://wiki.ubuntu.com/FeistyReleaseSchedule
<ogra> see feb 8th :)
<ogra> UVF is UVF ...
<ogra> for main and universe ...
<geser> I understood it that a sync from 2.0-3 to 2.0-5 doesn't need a UVFe but a sync from 2.0-3 to 2.1-1 needs one
<bddebian> That was my understanding
<bddebian> ScottK: Courier may not make it just because it's taking so freakin' long to build :-)
<shawarma> In any case, this is a 0.4-blah to 0.5-1 sync.
<ScottK> Heh.
<geser> shawarma: than you need to hurry and file an UVFe just in case
* ScottK reads the scrollback...
<ScottK> bddebian: Since the courier update is just a Debian update, if I read the scrollback correctly then it can still go in past UVF.  Is that right?
<geser> ScottK: it depends who is correct :)
<geser> bddebian: libtifiles2 reviewed
<geser> bddebian: you might want to hit upstream to get the abbravations for the licence in Readme right (also for those in the other ti* source packages)
<shawarma> geser: Why would I file it already?
<bddebian> geser: I have been bugging them about all their license crap.  It's messed up in all their packages :-(
<ogra> geser,  2.0-3 to 2.0-5  is no new upstream indeed you can sync that 
<ogra> thats why we call it *upstream* version freeze ;)
<bddebian> geser: New libtifiles up if you get spare time. TIA
<ScottK> bddebian: Thanks for the Courier merge.
<bddebian> NP
<bddebian> I live to serve :-)
<ScottK> I see you got it in 4 minutes before UVF :-)
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<cbx33> ping TheMuso 
<vud1> hi
<vud1> i am trying to register myself as REVU uploader
<vud1> i see in the ubuntu page that i need ask here to re-sync the REVU uploaders 
<ScottK> That's correct.
<vud1> aha... well... could you resync it?
<vud1> :)
* ScottK is not an admin.  You'll have to wait.
<vud1> uops, ok
<vud1> admin == channels oper?
<ScottK> No
<ScottK> It is some or all (not sure) of the people listed as administrator here https://launchpad.net/~motu
<vud1> ok, thanks
<Adri2000> revu admins? not really
<ScottK> Adri2000: Is there a published list of who can resynch?
<Adri2000> https://launchpad.net/~revu-hackers
<ScottK> Ah.  Yes.  That's the one.
<ScottK> vud1: ^^^  
<vud1> mmm so ajmitch can resynch
<vud1> ajmitch: are you there?
<LaserJock> vud1: done
<vud1> :) thanks
<LaserJock> it takes quite some time to sync so we try not to do it all the time
<vud1> one question. Must i subscribe a package in any webpage before upload it with REVU?
<LaserJock> no
<vud1> aha, so, just upload the package with revu, and then check motu/packages/candidates webpage
<LaserJock> no
<LaserJock> dput revu *_source.changes
<LaserJock> then look on revu.tauware.de
<vud1> ok
<ajmitch> morning
<bddebian> Heya ajmitch
<LaserJock> hi ajmitch
<Adri2000> shawarma: see https://wiki.ubuntu.com/SyncRequestProcess for bug 84017
<Ubugtu> Malone bug 84017 in rawstudio "Please sync 0.5-1 from Debian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84017
<Adri2000> shawarma: and were are in UVF now...
<ajmitch> and a sync request really should have more info than that
<Adri2000> btw, s/were/we/
<ScottK> Now that main is past UVF and FF, is there anything special that needs to be done about universe packages sitting in NEW or is it just a matter of waiting for the archive admins?
* ajmitch shrugs
<ajmitch> I haven't heard what the verdict is
<Adri2000> nobody is merging knemo?
<sistpoty> hi folks
<LaserJock> hi sistpoty 
<sistpoty> hi LaserJock
<ajmitch> hey sistpoty 
<sistpoty> hi ajmitch
<Lutin> bddebian: I updated gmountiso, could you have a look at it ?
<LaserJock> Lutin: lol, we already have gisomount, now we need gmountiso?
<bddebian> Heya sistpoty
<sistpoty> hi bddebian
<bddebian> Lutin: Yeah, give me a bit
<_ion> laserjock: *and* gmouisont
<Lutin> LaserJock: oh, wasn't aware of that
<Lutin> maybe it's not needed then
<\sh> oh nice.our internal systems SAN is dead, time to go to the hotel
<sistpoty> hi \sh
<\sh> hey sistpoty
<\sh> ok guys...cu tomorrow...
<bddebian> Later \sh_away
<pianoboy3333> for the main part... dpkg builds a package by installs in a temp folder, as it would normally install, no? I mean the hirearchy format
<pianoboy3333> and then it walks it or something and copies those files to how it is on your system
<LaserJock> it builds to debian/
<LaserJock> and then compresses up the deb
<pianoboy3333> right
<pianoboy3333> but if you look at the data zip in a deb
<pianoboy3333> it'
<pianoboy3333> it's in the same format as it would copy to one's system
<pianoboy3333> like in the hello deb
<LaserJock> yep
<LaserJock> in the hello package
<LaserJock> everything is installed to debian/tmp/
<pianoboy3333> ah, ok
<pianoboy3333> I see
<LaserJock> then it gets compressed into a .deb relative to that
<pianoboy3333> well
<pianoboy3333> it's not compressed, just bundled
<pianoboy3333> debs are just ar archives I believe
<LaserJock> I thought they were compressed
<pianoboy3333> use archive manager or ar, and extract one
<pianoboy3333> the extracted is only a few less kb then the archive
<pianoboy3333> just because of how ar works
<LaserJock> some packages show quite a bit of compression though
<LaserJock> ubuntu-docs goes from a 383KB .deb to 2.3MB unpacked
<sistpoty> iirc it's gzipped (somehow)
<_ion> compressed tarballs inside an ar archive.
<geser> the deb is ar archvie of control.tar.gz and data.tar.gz (or data.tar.bz2 in some cases)
<siretart> huhu sistpoty!
<sistpoty> hi siretart
<pianoboy3333> does dpkg support like gunzip, bunzip, ar, AND tar?
<pianoboy3333> seems like that's the direction this is going in
<siretart> pianoboy3333: try unpacking a .deb archive with ar
<pianoboy3333> why...
<siretart> because that's what an .deb archive really is: an ar archive
<pianoboy3333> right...
<pianoboy3333> I wish I could find a library for ar files for python
<pianoboy3333> ar is better than tar... kinda
<pianoboy3333> tar makes files ugo even when they're not
<LaserJock> ajmitch: what are you guys talking about in -devel? mem usage?
<ajmitch> keybuk's disgust at mem usage
<ajmitch> why?
<Fujitsu> Everyone knows that Evolution and Firefox eat RAM!
<ajmitch> obviously
<LaserJock> it's rather large
<LaserJock> I can't imagine evo taking 500MB
<Fujitsu> If you have a lot of email, I'm sure it will.
* Fujitsu notes numpy is a candidate for main promotion.
<Fujitsu> motuscience is going to need a core-dev in the near future,.
* LaserJock looks around
<LaserJock> Fujitsu: if I can get stuff into Edubuntu there will be much more
<Fujitsu> LaserJock: What are you trying to get promoted?
<LaserJock> octave
<LaserJock> qcad
<Fujitsu> Is there any reason why a Debian maintainer would refuse to upload a new upstream version to unstable until Etch is released?
<LaserJock> yes
<LaserJock> many are doing that
<Fujitsu> Why, though?
<LaserJock> I think because of all the slushyness or something
<geser> Fujitsu: because it's then harder to upload fixes which should get into etch
<LaserJock> Fujitsu: https://wiki.ubuntu.com/JordanMantha/EdubuntuMIRCandidates
<Fujitsu> Do you really want drgeo in main? Isn't it unmaintained upstream?
<LaserJock> Fujitsu: I don't know about unmaintained
<LaserJock> looks like it's just not actively being developed
<Burgwork> that is the active definition of unmaintained
<LaserJock> hmm, I guess I think of it a bit different
<sistpoty> nope... revu2 is not actively being developed, but it's not unmaintained :P
<Burgwork> LaserJock: http://lists.ofset.org/arc/drgeo/2006-07/msg00000.html
<Burgwork> "I am stopping work" is a pretty good sign of being "unmaintained"
<Fujitsu> Burgwork, that's what I thought.
<LaserJock> well, I guess so
<LaserJock> I think it's well liked  software though
<LaserJock> it'd be a shame to loose it, IMO
<Fujitsu> It does seem to be the only application of its type, so it would be nice to have.
<bddebian> LaserJock: So start maintaining it ;-)
<LaserJock> 3lol
<ajmitch> bddebian: no, that's you job
<bddebian> ajmitch: I'm unreliable :-)
<LaserJock> and I am?
<bddebian> Yes
<bddebian> You ROCK d00d
<givr1> since it's revu sprint, can someone review http://revu.tauware.de/details.py?upid=4318 Thanks :)
<Toadstool> heya everybody!
<bddebian> Heya Toadstool
<Toadstool> hey bddebian 
<sistpoty> hi Toadstool
<shawarma> The wiki only seems to talk about what to mention in a UVF exception request, but I seem to remember that we used to put something in the subject line or tag it or something... Am I on crack again?
<sistpoty> shawarma: according to the old bugs, it was UVF
<shawarma> sistpoty: So prepend "UVF" to the subject? 
<sistpoty> shawarma: yes please
<shawarma> sistpoty: Who reviews them for universe?
<ajmitch> motu-uvf
<shawarma> So I should probably subscribe them to the bug as well?
<ajmitch> no
<ajmitch> https://wiki.ubuntu.com/FreezeExceptionProcess
<ajmitch> follow what was posted to the list
<shawarma> Oh, right.
<shawarma> Hmm... Do you happen to have a link to the post on the list? I can't seem to find any mention of the word "exception"..
<ajmitch> 1162  s  Feb 07 Jordan Mantha   (  58) universe Upstream Version Freeze imminent
<shawarma> ajmitch: Thanks.
<ajmitch> on ubuntu-motu
<sistpoty> https://lists.ubuntu.com/archives/ubuntu-motu/2007-February/001256.html
<ajmitch> or that
<shawarma> Got it.
<shawarma> ajmitch: So I should *assign* it to motu-uvf..
<ajmitch> yes
<TheMuso> cbx33: Hi there.
<sistpoty> givre: nice... +1. (and sorry, I just posted a comment to ntfs-3g, when I meant ntfs-config)
<givre> sistpoty: many thanks :)
<sistpoty> givre: oh... sorry, just saw one flaw: the version should be 0.5.4-0ubuntu1, but others than that I'm happy
<givre> sistpoty: wha stupid me
<givre> i'll fix that asap
<givre> sistpoty: done : http://revu.tauware.de/details.py?upid=4320
<Toadstool> hey sistpoty 
<sistpoty> hi Toadstool
<sistpoty> givr1: still +1 ;)
#ubuntu-motu 2007-02-09
<RAOF> Anyone feel like reviewing either specto ( http://forum.go-compiz.org/viewtopic.php?t=498 ) or gimmie ( http://revu.tauware.de/details.py?upid=4309 )?
<sistpoty> RAOF: give me 5 minutes, then I'll take a look
<RAOF> Thanks.
<Toadstoo1> gra... routers upgrades suck :p
<sistpoty> Toadstoo1: why... just ipkg dist-upgrade (or s.th. like that) *G*
<Toadstool> :D
<sistpoty> RAOF: does gimmie require python >= 2.5?
<RAOF> sistpoty: It doesn't, but my patch to link in the python lib is hardcoded to 2.5
<RAOF> My autotools-foo is insufficient to handle the general case :(
<sistpoty> RAOF: ok, no problem
<sistpoty> RAOF: it FTBFS on amd64 :(
<RAOF> sistpoty: What?  I *built* it on amd64!
<RAOF> I'll check.
<sistpoty> RAOF: http://paste.ubuntu-nl.org/4778/
<RAOF> Um, why would docbook2x-man segfault :(
<sistpoty> though I must admit line 22 is looks a little bit suspicous as if it wasn't gimmie's fault
<sistpoty> RAOF: maybe docbook2x-man is just borked atm :(
<RAOF> It's possible my docbook is malformed, but I don't *think* it is.  Know of any validators?
<sistpoty> sorry, nope
<RAOF> Also, it's just successfully built on *my* AMD64 system.
<RAOF> Let's try it in a pbuilder...
<sistpoty> RAOF: please try a fresh pbuilder... (mine is state of ~yesterday, since I use a mirror)
<sistpoty> RAOF: as in pbuilder update
<RAOF> k.
<sistpoty> RAOF: maybe docbook-to-man might do the job as well (package name == binary name)
<RAOF> Hm, my (unupdated) pbuilder also died with a segfault in docbook2x
<RAOF> Ok, I'll give it a try.
<sistpoty> RAOF: others than that, the sourcepackage looks quite nice, thought I don't see the full picture without being able to build the package yet.
<RAOF> Yay :)
* sistpoty is out for a cigarette
<RAOF> sistpoty: Is it OK for me to just include the pregenerated gimmie.1 file?
* TheMuso will be out for the day, but will be able to help with reviewing tonight.
<sistpoty> RAOF: as long as you "fix" it once the docbook package is fixed, I don't have a problem with it.
<RAOF> Ok.  I'll do that, and upload again.
* sistpoty needs to go to bed now
<sistpoty> gn8 everyone
<Arrogance> are there any plans to upgrade java-package to support Java 1.6 in Feisty?
<pochu> Arrogance: java6 is already in Feisty
<pochu> Arrogance: oh, you mean java-package :) I don't know, but is that package also in Debian?
<crimsun> yes, it is.
<crimsun> (we import it from Debian)
<pochu> crimsun: then we should wait until Debian updates it, right? :)
<lfittl> hmm, do we have libxcb packaged in Ubuntu?
<crimsun> pochu: not necessarily.
<pochu> lfittl: I think we haven't
<fernando> hi all
<pochu> hi fernando :)
<pochu> crimsun: but that would be a merge, right?
<pochu> crimsun: I'm a little n00b :)
<lfittl> pochu, yep, seems so, the question that bothers me is why ;)
<pochu> lfittl: I don't know what that package is, what it is for :)
<fernando> hey pochu 
<lfittl> new x client side library for C, cool stuff
<crimsun> we should wait on libxcb, since it'll be tied to debian-x/x-swat
<crimsun> pochu: what needs to be merged into 0.28?
<lfittl> yep, already in debian/experimental, but I guess it won't make feisty, right?
<pochu> crimsun: Arrogance ask for support java6
<tepsipakki> lfittl: _if_ xorg-7.2 makes it in, so does libxcb
<crimsun> lfittl: sure, we can ask for it to be imported into universe, but it's largely useless just sitting there by itself
<tepsipakki> yep
<tepsipakki> the new libx11 depends on it
<crimsun> pochu: which distributor (ibm or sun)?
<crimsun> pochu: as you've stated, 7,04/multiverse has it already
<lfittl> tepsipakki, I guess that xorg 7.2 stuff is unrealistic, it's a little late in the release cycle for such a big upgrade
<crimsun> lfittl: / tepsipakki: extremely unrealistic. It won't happen for 7.04.
<pochu> crimsun: yes, it is, but it supports java 4 and 5, but not 6
<lfittl> crimsun, k, thanks for the info
<tepsipakki> crimsun: were you in the meeting today?
<pochu> crimsun: or that is what the package info says :)
<tepsipakki> they discussed 7.2
<crimsun> tepsipakki: no, I just got off a plane
<tepsipakki> heh
<tepsipakki> well, I have everything else ready except mesa
<crimsun> tepsipakki: so what was the consensus?
<tepsipakki> don't know yet, since I wasn't there, but Colin will sen an email tomorrow to -devel
<tepsipakki> suggested that I should read the irclog
<tepsipakki> ..which isn't available yet
<crimsun> if 7.04 ships with 7.2, I'm going to cry bitterly
<tepsipakki> how so? :)
<TheMuso> crimsun: Surely not.
<RAOF> You don't feel like more X breakage?
<TheMuso> Surely it won't ship with 7.2
<lfittl> tepsipakki, http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2007-02-08.html
<crimsun> well, I like breakage as much as the next person, but I'm not willing to support breakage
<ajmitch> crimsun: because there's noone who knows X well enough to deal with corner case breakage?
* ajmitch likes new software. as long as it's supportable
<tepsipakki> lfittl: thanks
<crimsun> pochu: have you read debian 322843 ?
<Ubugtu> Debian bug 322843 in java-package "java-package: support for jdk 1.6" [Wishlist,Open]  http://bugs.debian.org/322843
<ajmitch> tepsipakki: how much of 7.2 have you prepared?
<pochu> crimsun: I'm not interested in that, it's Arrogance who asked for that :)
<tepsipakki> ajmitch: proto, lib, xorg-server
<pochu> crimsun: but thanks anyway ;)
<tepsipakki> so, most of it
<pochu> hi Hobbsee :)
<tepsipakki> and I've been building them now, not many libs to go
<ajmitch> Hobbsee!
<crimsun> Arrogance: have you integrated support from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322843 ?
<Ubugtu> Debian bug 322843 in java-package "java-package: support for jdk 1.6" [Wishlist,Open]  
<Hobbsee> hey pochu!
<tepsipakki> but for me, this has been a way to learn something, so even if they won't make it for feisty, maybe debian could use some of the effort
<Hobbsee> hey ajmitch!
<crimsun> tepsipakki: certainly, but have you checked XSF's git?
<tepsipakki> crimsun: yes, some of those are there but the dificult ones (libx11, xorg-server) not
<crimsun> tepsipakki: right, I hadn't seen those commits
<tepsipakki> I haven't committed anything anywhere, just meant that some packages are straight from experimental ;)
<crimsun> tepsipakki: right, I mean the XSF commit messages coming across debian-x
<tepsipakki> oh, yeah
<Arrogance> crimsun, yes
<crimsun> Arrogance: regression-tested?
<bddebian> Heya gang
<zul> freaking viacom
<bddebian> Yeah, freakin' viacom!
* ajmitch waits for zul to snap
<zul> not worth it ;)
<ScottK> Hobbsee: Thanks for your help last night/this morning with getting my packages in before UVF.
<Hobbsee> ScottK: :)
<rmjb> Hey guys
* Hobbsee waves
<bddebian> Hello rmjb
<crimsun> ugh, we'd need to have X.Org 7.2 (including possibly input-hotplug)
<crimsun> ready within a very, very short timeframe
<Burgundavia> crimsun: are you really shocked?
<Burgundavia> we habe been ignoring X for a very long time
<Burgundavia> ok, I official hate the control centre
<bddebian> heh
<ajmitch> Burgundavia: partly due to the lack of a maintainer
<Burgundavia> indeed
<ajmitch> since noone wants to invest time in it, and they've been trying to hire
<Burgundavia> why doesn't the about me capplet control my default display and input language?
<Burgundavia> in fact, where do I change my default display language?
<ajmitch> probably too distro-specific or something stupid
<ajmitch> language-selector, don't know where it is in control centre
<Burgundavia> language support?
<ajmitch> possibly
* ajmitch did switch his desktop to french at one point
<Burgundavia> nah, that just chooses the systems default
<crimsun> tepsipakki: if you're willing to join ubuntu-x-swat, I'll pitch in as well
<Burgundavia> users and grounds need a switch to control either local or ldap groups
<ajmitch> crimsun: I thought you were stepping down?
<Burgundavia> crimsun: I can help with some basic bug triage
<Burgundavia> plus users and groups should tie into about me
<crimsun> ajmitch: I had planned to curtail my involvement, but these issues seem rather dire
<Burgundavia> crimsun: why were you planning to control your involvement?
<crimsun> Burgundavia: work is slicing away at my time
<Burgundavia> ah, ouch
<ajmitch> work does take precedence
<Burgundavia> ajmitch: maybe I cannot change the default display language without logging in and out?
<ajmitch> Burgundavia: that would be stupid, but I wouldn't be surprised
<bddebian> crimsun: So quit ;-P
<ajmitch> Burgundavia: in fact, that's probably more likely
<crimsun> bddebian: of course!  *light bulb*
<ajmitch> since it's all controlled by environment variables
<Burgundavia> ajmitch: ouch, that sucks
<ajmitch> Burgundavia: blame POSIX
<ajmitch> most i18n stuff is unknown to me
<Burgundavia> hmm, only about half the default menu is translated
<Burgundavia> I need to go through and file bugs on stuff that isn't translated, I think
<ajmitch> in what language?
<Burgundavia> arabic
<ajmitch> ah
<ajmitch> didn't know you could read that :)
<Burgundavia> plus the default layout doesn't work for arabic
<Burgundavia> given it is a RTL language
<Burgundavia> I can only barely
<Burgundavia> kids stuff, basically
<ajmitch> with a RTL language, all the widgets should switch RTL as well
<Burgundavia> the default panel layout should be completely flipped if you have an RTL language
<ajmitch> yeah
<Burgundavia> most of the widgets do
<Burgundavia> including the button order
<Burgundavia> I don't think the panel layout is defined in gconf, however, mostly due to the fact that the panel needs a complete rewrite
<ajmitch> panel layout is in config files in ~/.gnome2
<ajmitch> or maybe not..
* bddebian wonders how many people actually USE the crap they throw up on REVU
<crimsun> I do!
<rmjb> I use my crap
<LaserJock> I don't!
<LaserJock> and neither does the author
<LaserJock> oh well
<crimsun> of course deities don't.
<bddebian> Well some of it just seems.... Odd
<LaserJock> mhm
<Hobbsee> bddebian: which in particular?
<bddebian> crimsun: You're above REVU d00d :-)
<rmjb> I saw one today that looked odd
<bddebian> Hobbsee: I can't name a specific one, just see a lot of "stuff"
<Hobbsee> ahhh.  yes
<rmjb> this one: gmountiso  - This is Gmountiso, a PyGTK GUI to mount your cd images
<LaserJock> rmjb: we already have gisomount
<LaserJock> btw
<bddebian> Yeah and now we have both :-)
<rmjb> I had a question, how does alacarte get updated with new package info? I saw my package make it into feisty's alaracte and I didn't do anything
<rmjb> LaserJock: I'll have to check out gisomount
<LaserJock> rmjb: it was written by cbx33 (Edubuntu MOTU)
<bddebian> LaserJock: Get reviewing libtifiles2 will ya? :-)
<LaserJock> bddebian: libtifiles2?
<bddebian> Yes
<LaserJock> I'm not reviewing anything right now
<bddebian> pfft :-)
* ajmitch isn't reviewing
<LaserJock> hmm, Edgy kernel still isn't up
* bddebian stops too then
<rmjb_> g'nite guys
<bddebian> Gnight rmjb
<mohammad> I am triying to use dh_link when I call it with arguments it create the symbolic links but when I put the source destination in package.link
<mohammad> no symbolic link is created! 
<mohammad> how can I get use of debian/package.link ?
<bddebian> Not to be sarcastic but are you sure you are using the correct package name?
<mohammad> bddebian: suppose the name of my package is zekr, then I should use zekr.link or package.link?
<bddebian> zekr.link
<mohammad> ioi !! thank you .......... : ) ) )
<bddebian> np
<mohammad> bddebian: you had written a comment on my package
<bddebian> yessir
<mohammad> bdebian: E: Unrecoverable error installing build-dependencies. 
<mohammad> how did you get this error?
<bddebian> Using pbuilder
<mohammad> you know to install sun-java* you need to accept a license 
<mohammad> if you modify your pbuilderrc 
<vil> hi, bddebian, mohammad
<bddebian> I was going to ask you about that.  Have you tried to build it with gcj?
<bddebian> Hello vil
<vil> i got the same problem
<mohammad> ok
<mohammad> you have to change 
<mohammad> export DEBIAN_FRONTEND="noninteractive" 
<mohammad> to 
<mohammad> export DEBIAN_FRONTEND="readline" 
<vil> i was playing around with a package for multiverse, which depended on sun-java
<mohammad> then pbuilder will ask you to agree the sun license then it the dependencies will be satisfied
<bddebian> Have you tried it with gcj?
<vil> but will this get through the automatic build, whenever you upload it to the archives?
<mohammad> bedebian: zekr only works with sun-java* not with gcj, Yes I have tried, but gcj has not implemented some api's needed by zekr, so zekr does not work with gcj
<bddebian> Too bad, screw Sun :-)
<mohammad> vil: I do not know
<vil> mohammad, neither me, maybe someone here will know
<mohammad> bddebian: in this case can sponsers upload zekr to ubuntu repositories?
<vil> mohammad, which particular api is problem for gcj?
<bddebian> Sure but I assume it will have to go in Multiverse
<mohammad> bddebian: because it depends on a non-free software it will go in Multiverse?
<bddebian> yep
<mohammad> vil: well I dunno exactly, I think zekr uses some kind of regular expressions. 
<LaserJock> do we have a Java team?
<bddebian> doko :-)
<vil> yes, doko is pretty much the java team :-)
<vil> mohammad, anyway, if you would like to discus any particular problem with running it under gcj, you can try write me to see, if i can help
<mohammad> Is there any free replacement for sun-java* except gcj?
<vil> mohammad, kaffe, sablevm, cocoa
<vil> although gcj seems to be the current favorite
<mohammad> vil: thank you :) I will test them to see whether zekr can work them. infact I myself dunno exactly which api's has been used in zekr which gcj does not support, I will ask the zekr developer
<vil> mohammad, sorry, the last one is cacao
<bddebian> Just re-write it in python or something ;-P
<vil> mohammad, you can find me here or on launchpad so feel free to write me a mail, if i can help
<fbond> but ... (may be a bit late here) ... java is GPL now, anyway, so ...
<mohammad> vil: thanks for your kindness, if I face any problem I will contact you :)
<RAOF> Anyone hankering to review a package?
<vil> fbond, afaik java run-time libs are still not under gpl and it will take some time until it all makes it into universe
<bddebian> RAOF: Which package?
<RAOF> Your choice of specto ( http://revu.tauware.de/details.py?upid=4321 ) or gimmie
<RAOF> http://revu.tauware.de/details.py?upid=4309
<RAOF> bddebian: gimmie should now build.  And I should file a bug on docbook2x-man :-|
<mohammad> fbond: it needs accepting a license, doent it?
<fbond> the current versions, yes...
<fbond> how long could it posssibly take for the GPL'd versions to hit the repos?
<vil> fbond, doko is the java-team
<vil> :)
<fbond> :)
<bddebian> As far as I'm concerned we can just remove all java :-)
<fbond> I wouldn't complain
<fbond> swing is ugly as hell anyway
<mohammad> well but swt is not ugly :)
<fbond> ROAF: you may, in the future, want to try using xsltproc with docbook-xsl instead of docbook2x-man
<fbond> mohammad, what's swt?
<RAOF> fbond: I may well.
<vil> fbond, for example eclipse uses swt
<vil> and it does not look bad
<RAOF> I just copied what some other motu did in a pacakge on REVU.
<fbond> vil, never touched eclipse -- I understand it has a bit of a following :)
<mohammad> The Standard Widget Toolkit (SWT) is a graphical widget toolkit for the Java platform. It is an alternative to the AWT and Swing Java GUI toolkits provided by Sun Microsystems as part of the Java standard. (from wiki)
<fbond> RAOF, it works fine for most things
<fbond> the docbook-xsl stylesheets have been improving lately
<fbond> mohammad, so who provides SWT if not Sun?
<mohammad> Around this time, IBM was developing their VisualAge development integrated development environment (IDE), coded in Smalltalk.
<RAOF> I just wanted something ridiculously simple to satisfy the /usr/bin-must-have-man-page
<fbond> RAOF: works fine, no complaints here :)
<mohammad> fbond: I think it is related to eclipse
<RAOF> Next time, I'll look into it :)
<fbond> just a suggestion that might make life easier in the future
<fbond> mohammad, ah...ok
<ScottK> RAOF: Unless you actually call those python programs as a script, the solution to the warning is to remove the shebang (I learned this the hard way recently).
<mohammad> I have another problem. the zekr developer has not written any Makefile. I write myself should I simply put it in the source directory? or in patches?
<RAOF> ScottK: You mean the "everything in /usr/bin must have a manpage"?  Why would you install some python in /usr/bin that *wasn't* a script?
<ScottK> No the "W: specto: script-not-executable " warnings
<ScottK> But looking at the time of the message I"m reading, I'm wondering if I'm looking at an old upload...
<RAOF> ScottK: Um... I must have missed those warnings.  "specto" should *definitely* be executable.
<mohammad> any idea?
<ScottK> Executable yes, but not necessarily a script.
<vil> mohammad, there seems to be a build.xml ant file, which replaces a makefile
<ScottK> If they just get used via a Python import inside another Python program, then no shebang is needed (and in fact not wanted).
<RAOF> bddebian: You'd like me to silence all those lintian errors by removing the shebangs from the start of those .py files?
<bddebian> Or making them executable.  Whatever is appropriate :-)
<mohammad> yes there is (actually I asks him to put that build.xml in tar.gz), so should I put my makefile in patches?
* RAOF fires up dpatch
<bddebian> I see you have some in gimmie too :-)
<vil> mohammad, you don't need makefile, you can build using ant directly using cdbs for example
* RAOF pushes to the stack
<mohammad> vil: ok is there any simple howto on cdbs?
<fbond> :)
<mohammad> vil: is it illegal to use dpatch and put my Makefile completely in debian/patches ?
<fbond> mohammad, you don't need a Makefile, just put the necessary ant commands in debian/rules
<fbond> CDBS is a smarter, more advanced way to do debian/rules stuff
<fbond> but it has a learning curve
<vil> mohammad, try this file:///usr/share/doc/cdbs/cdbs-doc.html#example-ant or better looking at some existing java packages (ending with -java)
<vil> it is legal to put inside your own makefile, but in this situation unnecesary
<RAOF> Does anyone have a quick piece of sed-ery to strip out shebangs from a whole bunch of files?
<mohammad> vil: thank you :)
<mohammad> thank you all for your helping, buy :)
<vil> see you
<mohammad> see you
<RAOF> bddebian: The final lintian warning for specto is "extra-license-file /usr/shar/doc/specto/COPYING"
<bddebian> Remove that from docs
<RAOF> bddebian: Now, in order to silence this warning I'd need to patch about.py
<RAOF> The source uses that file.
<bddebian> Hmm, you could add a lintian override I suppose and make a note in README.Debian, but I'm not sure if that is the "right" answer? :-(
<RAOF> Well, I could patch about.py to not use that file at all, by including it inline.  But that's a bit ugly
<bddebian> Aye
<bddebian> Probably best to ask someone smarter than me :-)
<fbond> why not patch about.py to use the /usr/share/common-licenses file ... ?
<RAOF> fbond: A *much* better idea!
<RAOF> Thank you.
<fbond> np
<bddebian> w00t, go fbond
<RAOF> Also simplifies debian/rules.  Yay
* bddebian hates licensing shit :-)
<RAOF> bddebian: Now with no lintian output :)
<RAOF> Oh, as soon as it actually gets processed *blush*.
<RAOF> bddebian: Gimmie's also done.
<RAOF> I'm off, so review at leisure :)
<\sh> moins
<TheMuso> Hey all.
<\sh> moins TheMuso
<elyon225> Was just curious.... who decides what packages to include?  And how can a lowly developer like myself get my own apps into the reps?
<Fujitsu> elyon225: We'll accept most packages, and people generally suggest things to include. What applications do you develop?
<dettoaltrimenti_> are these the people who decide which programs to put in the repositories in adept?
<Fujitsu> dettoaltrimenti_, you could call us that.
<elyon225> Fujitsu: Well, right now I'm just working on a new frontend for Dosbox... very advanced, yet easy to use.  All the frontends I've seen so far really suck.
<Fujitsu> elyon225: I agree with that last bit.
<elyon225> Fujitsu: Hehe.... I had grown up in Windows...and one thing Windows has going for it is that it's GUI's are usually top-notch.  Not the case with Linux.
<elyon225> Fujitsu: Is there a website that I could visit that would explain all the ins and outs of the repositories?  It's all very confusing to me how it is decided what goes where and how the packages are hosted.
<Fujitsu> I'm not sure of a page about it...
<Fujitsu> But it's fairly simple.
<Fujitsu> Packages go into either main, restricted, universe, or multiverse. main and restricted are officially supported by Canonical, whereas universe and multiverse are supported/developed by the community. main and universe contain only fully-Free software, with restricted and multiverse containing the non-free stuff.
<elyon225> So, the chances of me getting my own package into main or universe are extremely rare, correct?
<Fujitsu> main, perhaps. But universe is almost trivial to get packages into.
<elyon225> Fujitsu: So, once I get my app finished and ready for release, what is the next step to get it into the repos?
<Fujitsu> Either package it yourself, or find someone to do it for you.
<Fujitsu> What is this frontend written in?
<elyon225> Promise not to laugh at me?
<elyon225> :)
<elyon225> It's written in REALBasic... I can't find any other RAD IDE's for LInux.
<Fujitsu> Sure.
<Fujitsu> Ah, that sort of counts out packaging in the near future.
<elyon225> I have no clue about programming in Linux.  I'm trying to learn Ruby, but I"m so used to an IDE that will allow me to simply click a button to run it, you know?
<AnAnt> Hello, what's the watch file for?
<LaserJock> for updating the package to new upstream versions
<LaserJock> it gives a regex for the url to download a new tarball
<AnAnt> if a package has this version format <num>.<num2>.<num3>, how should the URL be ?
<AnAnt> just http://<base_url>/app-\(.*\)\.tar\.gz
<AnAnt> ?
<TheMuso> AnAnt: I suggest you find some other packages that have a watch file, and have a look at those for reference.
<AnAnt> TheMuso: ok, thanks
<TheMuso> AnAnt: No problem.
<AnAnt> so, is there something added in the rules files or so to handle that watch file ?
<TheMuso> AnAnt: No.
<TheMuso> AnAnt: have you read through the Debian packaging policy at all/
<AnAnt> some of it
<TheMuso> that explains the watch file.
<AnAnt> I was reading uscan manual
<movi> i want to create a package for universe, i successfully packaged it using checkinstall but i have a few problems
<movi> first off, checkinstall doesnt allaow me to put in the dependencies
<movi> is there a different, more robust way to make a package
<movi> one that will allow me to use my template, that i will change when the version changes
<TheMuso> !packagingguide movi 
<movi> !packagingguide
<ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
<movi> thanks
<TheMuso> np
<TheMuso> Sorry, I meant to try and send that directly to you, but I don't know how to use the bot as well as others. :)
<movi> it's cool
<movi> anyway, once i construct a good deb package, how hard is it to get it into unvierse ?
<movi> *universe
<TheMuso> !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
<movi> ok, thanks :)
<Fujitsu> movi: Do not reference the checkinstall package when building one to go into universe. checkinstall is the root of all evil.
<movi> ok
<movi> hmm, the REVU page sounds complicated :/, ill concentrate on building properly first
<movi> is it necessesary that i have a chroot environment ?
<dholbach> good morning
<TheMuso> A pbuilder environment is strongly recommended.
<LaserJock> hi dholbach 
<TheMuso> Hey dholbach.
<ajmitch> hey daniel
<dholbach> hey LaserJock, hey TheMuso, hey ajmitch
<lfittl> morning dholbach 
<lfittl> ah, but now, morning dholbach_ :)
<dholbach> hey lfittl
<Fujitsu> Hey dholbach.
<dholbach> hey Fujitsu
<movi> one question
<LaserJock> only 1? that's pretty good
<LaserJock> :-)
<movi> im trying to build hello using debhleper, but the ubuntu source packages dont have a prerm and postinst
<movi> did something change ?
<movi> aargghh
<movi> what is wrong?
<movi> gpg : no public saveable key space (eof) (roughly translated from PL)
<movi> when trying to create my key 
<Fujitsu> I've not seen that error before, but it's possible that the permissions on ~/.gnupg are stuffed.
<LaserJock> movi: the ubuntu hello-debhelper packages has a postinst and prerm
<\sh> movi: are you creating a key on a gpg smartcard?
<movi> umm, im doing the way it's shown here https://help.ubuntu.com/community/GnuPrivacyGuardHowto
<movi> ah yes, the permissions were wrong
<movi> all is working now
<movi> weird
<movi> did intel stop packing RNG's to the Pentium 4's ?
<LaserJock> anybody in here use mini-dinstall?
<LaserJock> hmm, did I already ask that question before? I'm losing my mind
<movi> LaserJock, i kid you not, mine doesnt :/
<LaserJock> apt-get source hello-debhelper
<LaserJock> should be in hello-debhelper-2.1.1/debian/
<movi> changelog  compat  control  copyright  rules
<movi> all ive got
<movi> ive just re-downloaded and still none of those files
<LaserJock> movi: what version of Ubuntu?
<movi> Fesity
<movi> *Feisty
<LaserJock> I don't think it's changed but I'm on Edgy
<movi> i cans end you the diff.gz
<movi> *can send
<LaserJock> movi: you're right, new hello-debhelper package
<LaserJock>   * Removed prerm and postinst, as info files are missing now.
<movi> are they needed though? ;] 
<LaserJock> not anymore
<LaserJock> I'm going to have to fix that
<LaserJock> I go and use the hello package because they don't change often
<LaserJock> and they go an change them on me ;-)
<movi> could someone help me set up pbuilder with my gpg key? i created one but pbuilder doesnt see it
<Fujitsu> pbuilder shouldn't be doing anything to do with GPG.
<movi> err i mean dpkg-buildppackage
<Fujitsu> Make sure the name and email address are identical to those on your GPG key.
<movi> oh, actually theyre different
<movi> now i noticed
<movi> ah yes, now it works :)
<movi> question, i have a .build file
<movi> any way i can using it build a deb package, to see if everything went fine ?
<geser> isn't the .build file the pbuilder logfile?
<movi> well what i mean is that pbuilder finished building
<movi> but i dont see a deb file anywhere
<geser> look in /var/cache/pbuilder/result
<movi> aahh yes :)
<movi> alright then, time to build my own package!
<movi> just one question
<movi> does building from svn differ much from building from a tarball ?
<movi> since i dont have a original tar.gz file
<geser> then you will need to create one yourself
<movi> is there a nice way to finding out the build dependencies ?
<movi> instead of trial-and-error ?
<_ion> Often reading configure.in/.ac suffices.
<Fujitsu> Or reading README, or the website.
* Yagisan waves hello
<fbond> anyone have a quick suggestion as to why my apt-mirror, running on edgy, fails to mirror the fesity repos?
<fbond> I get no error messages...
<coNP> fbond: sorry to ask that but do you have feisty repos in your apt-mirror config file?
<fbond> yes
<fbond> it's awfully strange; do I have to have the feisty repos in sources.list, too?
<coNP> not at all
<coNP> I have feisty mirrored on an edgy
<fbond> hmm
<coNP> i.e. edgy + feisty repos in mirrors.list, only edgy in sources.list
<coNP> mirror.list
<fbond> right, that's my setup, too...
<coNP> do you mirror archive.ubuntu.com?
<fbond> yes
<fbond> I have it listed on two separate lines, though ...
<fbond> the logs indicate that it is downloading
<fbond> the correct files
<fbond> but the files aren't there ...
<coNP> fbond: you mean no /var/spool/apt-mirror/mirror/archive.ubuntu.com/ubuntu/dists/feisty* dirs?
<fbond> right
<fbond> deb http://archive.ubuntu.com/ubuntu/ edgy main restricted universe multiverse
<fbond> deb http://archive.ubuntu.com/ubuntu/ feisty main restricted universe multiverse
<fbond> those are in my mirror.list ...
<fbond> (the appropriate deb-src lines are there two, just didn't paste them)
<fbond> i do get the feisty* directories under /var/spool/apt-mirror/skel/...
<fbond> just not under the actual mirror dir ...
<zakame> evening all
<ScottK> Good evening.
<coNP> fbond: sorry, no more ideas, maybe pastebin your whole mirror.list
<fbond> coNP: thanks, I'll look at it some more and go to forum if need be ...
* proppy hugs dholbach
<bddebian> Heya gang
<givre> heya bddebian 
<bddebian> Hi givre
<ScottK> heya bddebian.
<bddebian> Hi ScottK
<slytherin> dholbach: ping
<dholbach> slytherin: pong
<slytherin> dholbach: pm?
<dholbach> sure
<ScottK> I am working on packaging a Python YAML processor.  The upstream tarball directory is PyYAML-3.04 and the tarball is PyYAML-3.04.tar.gz.  dkpg-source, of course, wants these all in small letters.  It whines, but builds the package.  Do I need to repack orig.tar.gz to fix this or can we live with it?
<_ion> scottk: Rename Foo-1.23.tar.gz to foo_1.23.orig.tar.gz and rename Foo-1.23 to foo-1.23. Then package it normally. When unpacking it in the future, dpkg-source will extract it to the correct directory.
<_ion> scottk: No need to repack it.
<ScottK> OK.  Will do.  Thanks.
<_ion> Check that the files in debian/ (changelog, control especially) contain the correct package name.
<ScottK> Thanks.
<ScottK> I have a new Python package ready for review if any MOTU are available - http://revu.tauware.de/details.py?upid=4328?
<_ion> (Perhaps python-yaml would be a better name for that specific package.)
<ScottK> I used that for the binary (since it's required), but I thought it better to stay with the upstream name for the source package.  I'm open to changing it if others think it would be better.
<bigon> Hi, Is it possible to ask the archive admin to rebuild a package? rebuilding python-pam fix bug #69967
<Ubugtu> Malone bug 69967 in python-pam "python-pam contains NO PYTHON!" [Undecided,Confirmed]  https://launchpad.net/bugs/69967
<geser> bigon: a new upload is needed because you need a greater version as the one on the archive
<geser> no further change than adding the new version to the changelog is needed
<bigon> geser: ok
<geser> bigon: I'm preparing a new package right now
<bigon> geser:  ok thx :) 
<keescook> is there really no apt version of "rpm -V" to verify an installed package's files' owner/perms/md5sum?  I do can do the md5sum by hand, but I'm not sure the other two are stored anywhere?
<geser> !info debsums
<ubotu> debsums: Verify installed package files against MD5 checksums.. In component universe, is optional. Version 2.0.28 (edgy), package size 29 kB, installed size 160 kB
<geser> but that only works for packages installed after debsums
<keescook> well md5s I can do without debsums:  md5sum -c /var/lib/dpkg/info/PKG.md5sums
<keescook> does debsums do owner/perms?
<geser> keescook: do all packages have a md5sums file?
<keescook> geser: hm, dunno, but the one I tried did.
<geser> I don't think debsums checks also owner/perms.
<keescook> yeah, and not all packages have md5sums, but a lot do.  odd
<geser> keescook: not all packages have a md5sums file. I've 978 lists files in /var/lib/dpkg/info but only 923 md5sums files
* keescook nods
<ScottK> bddebian: Are you up for a review? http://revu.tauware.de/details.py?upid=4328
<bddebian> ScottK: Damn man the diff is larger than the package :-)
<ScottK> Hmmm
<ScottK> http://revu.tauware.de/revu1-incoming/pyyaml-0702091305/pyyaml_3.04-0ubuntu1.diff is not very big?
<ScottK> bddebian: ^^^
<bddebian> Oh, it's bytes not Kbytes, sorry :-(
* bddebian blushes
* ScottK was worried I got burned by line endings again....
<ScottK> bddebian: Any suggestions on the Lintian warning?  Verbose mode didn't help me any.
<bddebian> I think just remove the period from the end of the last line
<bddebian>  ..as provided.  Remove the .
<Le-Chuck_ITA> hi, masters :)
<Le-Chuck_ITA> I have a highly polemic bug opened
<Le-Chuck_ITA> in lyx
<Le-Chuck_ITA> I would really like someone in ubuntu to have a look at it
<ScottK> OK.  Thanks.  Will do.
<bddebian> ScottK: Check it first as I am often wrong :-)
<Le-Chuck_ITA> it is bug #82365
<Ubugtu> Malone bug 82365 in lyx "Please compile with assertion checking turned off" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82365
<Le-Chuck_ITA> In the bug comments there is a rationale, a report of a conversation with debian maintainers, and the rather obvious debdiff
<Le-Chuck_ITA> I could upload my lyx package and find a sponsor but ... well I think it is better to get some MOTU impression first
<Le-Chuck_ITA> hmm, will try in another moment or give up :)
<ScottK> bddebian: You were correct.  Please have a look at this one - http://revu.tauware.de/details.py?upid=4330
<bddebian> Wow, that's a first :)
<ScottK> Don't worry.  It's balanced out by the bytes/kilo-bytes thing on the diff.
<ScottK> ;-)
<bddebian> doh, ouch :-)
<ScottK> bddebian: Will be afk for about 30 min.  I'll check in when I get back.  Thanks.
<ScottK> bddebian: Thanks.
<ScottK> Any other MOTU to reviww http://revu.tauware.de/details.py?upid=4330?
<jharr> what's everyone recommend for source package management?
<jharr> I was looking at svn-buildpackage
<ogra> bzr
<ogra> thats what we use in ubuntu commonly ...
<jharr> waht about archive management
<jharr> I've seen people use falcon repo builder a lot.
<lupine_85> falcon++
<lupine_85> makes life a lot easier
<jharr> lupine_85: do you have a link for that, google isn't giving me a whole lot
<_ion> jharr: There's also this bzr-builddeb thing (apt-cache show bzr-builddeb, "bzr plugin for Debian package management"), but i haven't looked at exactly what it does yet. :-)
<lupine_85> jharr: Hawkwind wrote it, I think. It's on launchpad, and there's a repo...
<lupine_85> one second
<jharr> Unless there's a distinct advantage for using bzr-* instead of svn-*, I think I'm going to stick with svn stuff since it's what I know.
<_ion> bzr is decentralized, svn isn't.
<jharr> _ion: I'm doing this for a centralized environment
<lupine_85> I think it's in seveas's repo
<jharr> it's basically me and another guy working on it.
<lupine_85> e.g. deb http://mirror.ubuntulinux.nl dapper-seveas all
<_ion> jharr: A centralized VCS causes a single point of failure and less flexibility even if there's only one user.
<jharr> _ion: yeah, however all the building and downloading of packages will be done on a single network.
<jharr> _ion: all this stuff is for internal use. I'm sticking a lot of commercial software in deb's so that I can use it in a cluster we have here.
<pochu> hey guys, do you know if there is a way to know the build-deps and the deps of a source package?
<jharr> I'll still look at bzr, but just the fact that it's a distributed VCS doesn't make it very attractive.
<pochu> I'm trying to make a .deb, but don't know the deps :)
<Adri2000> pochu: you want to build a package that is already in the repositories?
<pochu> Adri2000: no, it's neither in the ubuntu repos, nor in the debian ones
<ScottK> Adri2000: Are you available to review a package? http://revu.tauware.de/details.py?upid=4330?
<pochu> Adri2000: I have created the debian/ folder with dh_make, but I don't know the build-deps and deps
<ScottK> pochu: What does the documentation say from upstream?
<ScottK> Does it tell you what's required?
<Adri2000> ScottK: maybe yes, when revu works :) "Mod_python error: 'PythonHandler mod_python.publisher"'
<ScottK> Ouch.
<pochu> ScottK: they are the compiz-extra-plugins, I suppose I need compiz-core, and a lot of x libs :)
<ScottK> Read the upstream documentation and see what they say is needed and then find the appropriate Ubuntu packages for hat.
<ScottK> hat/that
<pochu> ScottK: ok, thanks :)
<ScottK> Adri2000: That must be for a part of revu that I don't get to use - Poor timing during a revu sprint....
<LaserJock> anybody know how much it costs for a LUG to get CDs from Shipit?
<pochu> LaserJock: no cost for Dapper CDs
<imbrandon> LaserJock, 1.50 per cd in lots of 100 iirc
<Adri2000> ScottK: ahww, sorry, sure it doesn't work if I keep the '?' at the end of the url :p
<imbrandon> ( for the edgy ones )
<imbrandon> for dapper nothing
<ScottK> Ahh.
<pochu> LaserJock: is that lug a loco team?
<ScottK> Sorry about that.
<LaserJock> pochu: hehe, no
<LaserJock> I have no LoCo team :(
<pochu> LaserJock: from?
<LaserJock> Nevada, USA
<pochu> LaserJock: you can create one and then ask for 500CDs :)
<imbrandon> LaserJock, i still have about ~100 edgy cd's if you want me to ship them for you / rlug next week
<pochu> LaserJock: but you have to get approved :(
<imbrandon> the ones from UDS
<LaserJock> there is a California team, a Colorado team, a Utah team
<LaserJock> I think a Southwest one
<LaserJock> but nothing for me 
<pochu> LaserJock: start the Nevada Team ;)
<imbrandon> ~midwest one too
<LaserJock> heh
<imbrandon> ;)
<LaserJock> it'd just be me
<pochu> :)
<ScottK> LaserJock: That's about a third of the populations of the state, so that's not bad.
<pochu> LaserJock: then you can take all the decissions you want :)
<pochu> hehe :)
<LaserJock> my LUG (the closest one for 120 miles) has about 10 people showing up
<bddebian> Later gang
<ScottK> Later
<LaserJock> ScottK: Las Vegas has a lot
<ScottK> Good point.  Forgot about that.
<LaserJock> but I haven't seen a lot of FLOSS people from Vegas
<LaserJock> I think they are mostly into more monetary internet activites down there ;-)
<ScottK> Vegas is not a place about giving stuff away.
<coNP> make a virtual team
<coNP> if there is none yet
<LaserJock> imbrandon: what flavors have you got?
<LaserJock> for me I just don't see the point of a LoCo team here
<LaserJock> we wouldn't do anything
<LaserJock> and since translating en_GB to en_US isn't propular I can't imagine us doing translation work
<LaserJock> *popular
<jharr> If I'm packaging an app that doesn't have a version number, but a build date, what's the propper way to setup the source directory?
<jharr> do i just specify the version for dh_make?
<Adri2000> jharr: you can change it later in debian/changelog
<Adri2000> ScottK: I'm reviewing pyyaml
<ScottK> Great.
<ScottK> Adri2000: Thanks.
<TheMuso> Hey MOTUs.
<LaserJock> hi TheMuso 
<LaserJock> how many uploads have you done?
<torkel> Any chance someone can take a look at #76967 and perhaps do an upload of Openafs? The debdiff has been there for over a month
<LaserJock> ajmitch: up yet?
<TheMuso> LaserJock: A few now.
<TheMuso> I could count the emails I have in my uploads folder, but I'll do that in a few weeks. :)
<LaserJock> good for you
<LaserJock> rockin'
* TheMuso intends to hit revu in a while.
<TheMuso> I've not long got up.
<Adri2000> ScottK: reviewed
<ScottK> Thanks.
<imbrandon> TheMuso, seems like you have done quite a few uploads ;)
<imbrandon> https://launchpad.net/~themuso/+packages
<imbrandon> would be nice if you could sort that by date
<TheMuso> imbrandon: Note that that would be stuff before I got MOTu as well.
<ScottK> Adri2000: I'll fix that up and be right back.
<imbrandon> yea thus the date statement ;)
<LaserJock> imbrandon: do you know if you get 100 of the same flavor CDs?
<imbrandon> LaserJock, if thats what you ask for
<imbrandon> they are pretty flexable
<LaserJock> but I could get like 50 Ubuntu 25 Kubuntu and 25 Edubuntu?
<LaserJock> oops bad example for you ;-)
<imbrandon> yea infact thats exactly + one zero what i askd for
<LaserJock> 50 Kubuntu 25 Ubuntu 25 Edubuntu ;-)
<imbrandon> hehe
<imbrandon> i got 500 + 250 + 250 , and a few for ppc and amd64 of each
<imbrandon> when i ordered
<LaserJock> I don't think RLUG needs that many
<LaserJock> but they were just talking about Shipit at the last meeting apparently
<imbrandon> right on, but the point is they are flexable, and will put ppc and amd64 if you ask
<LaserJock> did you get some at Mt. View?
<imbrandon> definately
<LaserJock> I didn't stay around long enough
<imbrandon> do you mean from shipit? heheh
<LaserJock> did they have them at Google?
<LaserJock> is what I meant
<imbrandon> ohhhh i though you said mt dew, /me headdesks
<LaserJock> hahahahaha
<imbrandon> yea i got the 100 or so i have now from when we were at google
<imbrandon> lol
<LaserJock> shipit MT. Dew
<LaserJock> Mark springs for developer juice
<imbrandon> but i also ordered some for a confrence we had here in town
<LaserJock> hmm
<paulproteus> I'm a Debian mentee with a package in Debian, alpine.  It's not in Ubuntu, and I'd like it to be.  I uploaded it to REVU an hour ago, but I don't see it at revu.tauware.de.
<LaserJock> well maybe I could hold off until the next UDS and get Feisty CDs
<LaserJock> paulproteus: you sure it isn't Ubuntu
<LaserJock> I thought we synced it a while ago
<paulproteus> LaserJock, packages.ubuntu.com/alpine doesn't show it, at least.
<LaserJock> !info feisty alpine
<ubotu> Package feisty does not exist in edgy
<LaserJock> !info alpine feisty
<ubotu> Package alpine does not exist in feisty
<paulproteus> !info alpine feisty
<LaserJock> bah
<paulproteus> Well, there we go. )-:
<LaserJock> hmm
<paulproteus> So I figured I'd upload to revu since that seems more direct to Ubuntu.
<LaserJock> well somebody was around a while ago trying to get it in
<paulproteus> Yeah, it was me and poningru.
<imbrandon> paulproteus, you the maintainer in Debian ? and you want the exact version thats in debain in ubuntu ?
<imbrandon> am i correct ?
<LaserJock> when did it get into Debian?
<paulproteus> imbrandon, The version I uploaded to Debian is 0.82+dfsg-3, but I uploaded 0.82+dfsg-3+ubuntu0 which has one trivial fix.
<paulproteus> I mean, I uploaded the +ubuntu0 release to REVU an hour ago.
<paulproteus> LaserJock, It got into Debian two months ago or so.
<paulproteus> Maybe one month or so, now that I think about it.
<imbrandon> i'd be happy to sponsor whats in debian already , btw +ubuntu0 is wrong versioning though , but trivial
<LaserJock> we should be able to sync it
<imbrandon> paulproteus, hit me with a dsc and i'll take a look at it ( i'm being too lazy to log into revu )
<LaserJock> forget REVU, sync that baby
<imbrandon> well if he has a fix
<imbrandon> well hrm
<paulproteus> imbrandon, Sounds good, talk to you in a sec with a dsc.
<LaserJock> we can fix it after the sync
<imbrandon> upload to debian the fix and we'll sync
<imbrandon> true
<LaserJock> that's even better
<paulproteus> imbrandon, Well, there are a few more bugs I want to fix before the new Debian upload.
<LaserJock> if we don't need an ubuntuX it would be lovely if we didn't have it
<LaserJock> can you get them done within a week or so
<LaserJock> ?
<imbrandon> i agree actualy, depends on how long till you can upload to debian, FF is comming the 22
<paulproteus> LaserJock, Yeah, I could do that.
<paulproteus> "Feature freeze"?
<paulproteus> 22nd of Feb?
<imbrandon> yea do it that way then, fix it in debian over the next week then poke me or someone in here
<imbrandon> yes and yes
<paulproteus> imbrandon, Sounds good, that's what I'll do.  Thanks!
<imbrandon> btw if you make a ubuntu local change to a debian package its upstream-XubuntuY where X is deb rev and Y is ubuntu rev , e.g. you package should ahve been uploaded to ubuntu as 0.82+dfsg-3ubuntu1 , just for future ref
<imbrandon> paulproteus, ^^
<imbrandon> if its not in debian yet the deb rev is 0 e.g. 0.4.3-0ubuntu1
<ScottK> Adri2000: To answer one of your questions, there is a build-dep on debhelper because lintian throws an error if it's not there.  I'm not sure if it's cdbs or python-support, but one of them appears to use it.
<imbrandon> anyhow thats the quick and dirty, there are exceptions etc etc etc
<paulproteus> imbrandon, Thanks, that's a very clear explanation.
<imbrandon> np
<LaserJock> we are getting closer to being able to put Candidates on LP
<imbrandon> right on, and bzr-buildpackage is rockin too
<LaserJock> using bugs for package requests will be so much nicer
<LaserJock> and it should tie in well with using bazaar.lp.net
<LaserJock> hmm, we'll have to be clear about what we are ack'ing though
<Adri2000> ScottK: I meant why *versioned*
<Adri2000> ScottK: and why this version
<LaserJock> probably need to ack particlar revisions
<Adri2000> is there an UVF exception request already filed?
<Adri2000> or I will be the first? :)
<LaserJock> I think so
<LaserJock> maybe
<ScottK> Ah.
<LaserJock> look at what's assigned to the motu-uvf team
<Adri2000> LaserJock: nothing
<ScottK> Adri2000: Why versioned is because lintian says it has to be at least version 5 and that version because that's (5.0.38) what was in the package I copied from.  
<ScottK> Is debhelper >= 5 sufficient?
<Adri2000> yes, usually
<ScottK> OK.  I'll try that then.  Thanks.
<Adri2000> yay, the 187MB source package
<Adri2000> orig.tar.gz*
<LaserJock> imbrandon: so the minimum order is 100, right?
<LaserJock> 5.0.38 I think is for python policy
<imbrandon> LaserJock, yes iirc
<LaserJock> imbrandon: I found the form to order online
<Adri2000> currently ScottK's package has debhelper (>= 5.0.37.1), and 5.0.38 is needed for python-central, not for python-support (according to http://wiki.debian.org/DebianPython/NewPolicy)
<LaserJock> imbrandon: it says 1.50 euros/CD
<imbrandon> ouch
<imbrandon> i thought it was 1.50 usd
<LaserJock> that's $1.96USD
<ScottK> Adri2000: How's this? http://revu.tauware.de/details.py?upid=4333
<ScottK> LaserJock: I'd be interested in your opinion too ^^^
<Adri2000> ScottK: I'll look later, because anyway I can't build right now. (building the 187MB source package)
<geser> Adri2000: what has such a big source package? tex-live?
<Adri2000> nexuiz-data :p
<ScottK> Adri2000: Thanks.
<jharr> is there a tool for safely modifying stuff in /etc/environment?
<geser> jharr: what do you want modified there?
<jharr> PATH
<jharr> I'm making some local packages, some of which don't like to be in standard locations.
<Fujitsu> Make them like it, then.
<jharr> Fujitsu: it's kind of hard for me to modify binaries to do that.
<Fujitsu> Urgh, binaries.
<jharr> yeah, I don't like it either.
<jharr> but being an idealist only works if you have control over the software you're suppose to install on the system.
<coNP> jharr: I  would make a wrapper script instead
<jharr> I guess I could symlink everything
#ubuntu-motu 2007-02-10
<geser> jharr: make a wrapper script setting the needed PATH as this will also work if the user sets an own PATH
<bdmurray> crimsun: I have some questions about amixer and sound drivers if you have a moment.
<Adri2000> who is still running edgy?
<lionel> Adri2000: I have a Edgy box at work
<Nafallo> Adri2000: I do
<Nafallo> Linux ogre 2.6.17-10-server #2 SMP Tue Dec 5 22:29:32 UTC 2006 i686 GNU/Linux
<Nafallo> dooh
<Nafallo> not the server
<Nafallo> I'm on a client as well :-P
<Nafallo> damn irssi
<Adri2000> if you have access to an edgy desktop: https://launchpad.net/ubuntu/edgy/+source/obconf/+bug/62346
<Ubugtu> Malone bug 62346 in obconf "[SRU]  Missing libobrender.so.1 -> unable to launch obconf" [Medium,Fix committed]  
<Adri2000> it's really easy to test :)
<Nafallo> aha
<Nafallo> Adri2000: already in the archive? :-)
<Adri2000> Nafallo: yep, -propoed
<Adri2000> proposed
<Nafallo> *installing*
<Adri2000> thanks!
<Adri2000> now hope it works :p
* ScottK will test it too.  It's been a while since I booted into Edgy, so I have 20 packages/50mb of downloads to do first...
<Nafallo> Adri2000: launchpad is not fast today, but adding WFM ;-)
<Adri2000> great
<ScottK> While people are testing, I think that https://launchpad.net/bugs/75017 still needs testing too.
<Ubugtu> Malone bug 75017 in kubuntu-default-settings "SRU: remove /.hidden file " [Undecided,Fix committed]  
<TheMuso> Does anybody find that if one is using usplash/framebuffer, and one is in the console, the colours are all funny?
<TheMuso> Like the blues for directories are a dark grey etc?
<crimsun> bdmurray: I'm traveling internationally this week, so catching me is going to be difficult. What questions do you have?
<sistpoty> hi folks
<sistpoty> anyone uploading obconf to -updates already?
<sistpoty> bug #62346 (finally 5 acks)
<Ubugtu> Malone bug 62346 in obconf "[SRU]  Missing libobrender.so.1 -> unable to launch obconf" [Medium,Fix committed]  https://launchpad.net/bugs/62346
<crimsun> sistpoty: I can handle that one
<sistpoty> crimsun: ok, thanks
<Adri2000> 5 already?
<bdmurray> crimusn: I was curious how amixer determines what capabilities a sound card has.
<sistpoty> Adri2000: unless I counted wrong
<bdmurray> crimsun: I was curious how amixer determines what capabilities a sound card has.
<Adri2000> ah yes, thanks Fujitsu 
<sistpoty> Adri2000: if Nafallo's WFM means "works for me" *g*
<crimsun> bdmurray: amixer doesn't determine anything of the sort. alsa-lib exposes that via alsa-driver.
<sistpoty> crimsun, StevenK: btw. this one needs attention as well: bug #68481
<Ubugtu> Malone bug 68481 in drbd0.7 "[SRU]  change of /bin/sh to dash in edgy breaks drbd0.7-module-source build" [Undecided,Confirmed]  https://launchpad.net/bugs/68481
<Fujitsu> Adri2000: np
<sistpoty> and siretart ^^
<Nafallo> sistpoty: is there another meaning? :-)
<sistpoty> Nafallo: while glimpsing at the bug mail, I first read WTF ;)
<Nafallo> sistpoty: lol
<crimsun> bdmurray: each audio codec enumerates that information; look in the kernel source for precisely which elements are exposable
<bdmurray> crimsun: okay. I'm was looking at bug where the reporter does not have a 'Mic Boost' option and was curious where it did or did not come from.
<crimsun> bdmurray: that's a known bug; I'll be backporting that fix next week.
<bddebian> Heya
<bdmurray> crimsun: okay so it is independent of the driver / soundcard?
<ScottK> bddebian: Heya
<bddebian> Hi ScottK
<crimsun> bdmurray: the missing mic boost bug? no, it only affects HDA
<ScottK> bddebian: Would you please re-look at http://revu.tauware.de/details.py?upid=4333 - Adri2000 found a few things and I re-uploaded...
<crimsun> bdmurray: it's very specific to feisty and HDA codecs
<sistpoty> hi bddebian
<bddebian> Heya sistpoty
<crimsun> bdmurray: status In Progress would be fine
<bdmurray> crimsun: the bug I was looking at was HDA and Edgy.
<bddebian> ScottK: If Adri2000 found them, can't Adri2000 re-upload? :-)
<crimsun> bdmurray: with edgy-updates/security kernel installed?
<crimsun> bdmurray: if so, that's largely the base code as feisty's
<bdmurray> crimsun: not sure I'll check.
<bdmurray> crimsun: thanks for the help.  I have also seen a couple of bugs where it looks like the reporter has a sound card and the kernel module loaded but 'asoundconf list' returns nothing.  Where could I head next?
<sistpoty> Adri2000: what's your secret that you got so much testing for your sru?
<sistpoty> hi LaserJock
<Nafallo> sistpoty: he asked.
<Nafallo> :-)
<sistpoty> well... anyone dosemu (dapper) or xmms-sid (edgy) ? *g*
<LaserJock> hi sistpoty 
<Adri2000> and as I said, it's easy to see if the fix works or not :)
<crimsun> bdmurray: the debuggingsoundproblems wiki page is a good start; ubuntu-audio will follow-up on those
<bddebian> Are we supposed to be in a REVU sprint?
<sistpoty> bddebian: yep
<geser> is the motu-uvf team working already?
* sistpoty hopes so
* Adri2000 already filed an UVF exception request
* geser too
<Adri2000> :)
<bddebian> Jesus, REVU just keeps growing and growing...
* _ion just hopes compiz-extra gets accepted.
<geser> bddebian: this reminds me to review your libtifiles2 upload
<bddebian> geser: Thx man
<bddebian> At least someone loves me ;-P
<geser> bddebian: looking again at that unzip.c file: do you believe it's redistributable without the licence text?
<bddebian> geser: Didn't I add the license text?
<sistpoty> are you talking about libtifiles2-1.0.2/src/minizip/? looks like a part of zlib1g to me
<geser> bddebian: sort of, where did you find it?
<bddebian> geser: It's mentioned in COPYING iirc correctly.  I'll check in a sec
<geser> sistpoty: what to you think about the Info-ZIP copyright in unzip.c from that dir?
<bddebian> Yeah, I took the license from ZLIB, because of this:  mztools.c:  License: Same as ZLIB (www.gzip.org)
<sistpoty> geser: no problem, since that very file (only a few lines changed) is in zlib1g sourcepackage
<sistpoty> geser: with same copyright info
<geser> bddebian: advocated
<bddebian> geser: Wow, thx
* white waves
<Fujitsu> Hey white! Haven't seen you around in a while.
<white> well i relocated
<white> back in .au :)
<Fujitsu> Indeed.
<white> nice and sunny :)
<Fujitsu> Unfortunately.
* _ion enjoys a nice weather with a 27C temperature.
<Fujitsu> China was nice, -15C at times.
<white> they went crazy here at college, we have to pay fees for every mbit
<Fujitsu> Ouch.
<white> well great that i have another account here at uni and that i can tunnel stuff via ssh :)
<white> holy shit, 1,5 weeks on vacations, damn i have a backlog
<Fujitsu> Heh.
<_ion> white: How much does a megabyte cost?
<Fujitsu> white: There was an issue reported here a couple of weeks back. There's a bashism in 915resolution that's causing a failure when installing on a non-Intel machine.
<white> _ion: i guess 3 cents, not quite sure, i won't pay anyway :)
<Fujitsu> 3 cents? That's not too bad.
<white> Fujitsu: bah, i will try to have a look when i got things settled down :)
<white> has there been an upgrade to the ubuntu package?
<Fujitsu> We've got the latest Debian version, with the only change being the addition of the suspend/resume scripts.
<_ion> fujitsu: Not too bad? It's more than 20 dollars when you download an Ubuntu CD.
<Fujitsu> I guess.
<white> ah that suspend/resume thing, i guess i have to look into it, didn't quite know what to do with it so i ignored it so far
<Fujitsu> In Debian, acpi-support has those bits, but Ubuntu's doesn't. That 915resolution change shouldn't be merged into Debian at the moment.
<white> great
<Fujitsu> (or that was the status when I last checked Debian acpi-support a month or so back)
<ScottK> Adri2000: How goes the huge source package build?
<ScottK> bddebian: Thanks for the re-review.
<white> quote from a user-mail : "I see you did a port of ktechlab to ubuntu feisty."
<white> rotfl :)
<white> Hobbsee: hi :)
<ajmitch> white: must have been a challenging port
<Hobbsee> hey white!!!
<white> ajmitch: sometimes the users know things about me i don't even know so far :)
<ajmitch> heh
<ajmitch> in melbourne again?
<white> yes
<white> i just try to catch up with my backlog, it is horrible :(
<ajmitch> heh
<ajmitch> weeks of mail?
<white> 1,5 weeks of vacations and 3 days of relocating 
<ajmitch> ah
<white> does somebody want to check this?
<white> https://launchpad.net/ubuntu/+source/ktechlab/+bug/55559
<Ubugtu> Malone bug 55559 in ktechlab "PIC Component not available" [Undecided,Unconfirmed]  
* ajmitch wonders how many flames have been on debian-private this week
<white> ajmitch: bah i hope the flames are stopping, otherwise i will refuse reading the mails there
* Fujitsu checks it.
<ajmitch> I skip most of them :)
<white> i guess the bug should be fixed in debian with last gpsim package
<ajmitch> it's coming up to DPL election time, which is always a fun time of year
<white> ajmitch: where abouts are you?
<ajmitch> dunedin, NZ
* Fujitsu makes a note to add ktechlab to motuscience's package list
<white> i would love to catch up with some people and discuss DPL election by a beer
<ajmitch> I would love to come back over to melbourne again
<white> Fujitsu: the user asked me if the status of ktechlab can be changed in edgy
<Fujitsu> `status' of it?
<TheMuso> Ok. What packages have one advocate on revu, that need another that look like they can be uploaded?
<TheMuso> I'm in and out, but would like to help.
<TheMuso> So I can't give heaps of time to reviewing atm
<white> Fujitsu: well if the thing can be fixed
<white> like a backport or so
<Fujitsu> OK.
<Fujitsu> I'll look at it and see if a SRU can be organised.
<Hobbsee> Fujitsu: a backport will get through quicker
<Fujitsu> True.
<white> so can i just write him back that you are taking care of it and cc'ing you?
<Fujitsu> And it's not a grave functionality issue.
<Fujitsu> So a backport it should be.
<Hobbsee> Fujitsu: feisty will be released before most of the SRU's being placed in the next few weeks will be done.
<Fujitsu> white: Yep.
<white> well later on i can see if it is also a debian issue, but afaik i fixed it
<Fujitsu> It is fixed, I believe.
<Hobbsee> s/done/finished/
<white> Fujitsu: what was your mail again?
<Fujitsu> Hobbsee: How do I request a backport?
<Fujitsu> william.grant@ubuntu.org.au will do.
<white> ta
<Hobbsee> Fujitsu: file a bug, subscribe ubuntu-backporters
<Fujitsu> OK, thanks Hobbsee.
<Hobbsee> i think you're supposed to file a build log sa well, but i havent been
<Fujitsu> Hobbsee: Isn't the bug meant to be filed on a special product?
<Hobbsee> Fujitsu: not sure.  i didnt think so
<Hobbsee> Fujitsu: i thought it was under the source package you wanted to backport
<Hobbsee> but it may have changed now, i havent checked the documentation in months
<white> ajmitch: bah -private is on place 3 (just after -boot, -mia and some other stuff)
<ScottK> TheMuso: http://revu.tauware.de/details.py?upid=4333 is looking for a second advocate, since you ask...
<ajmitch> white: delete all
<TheMuso> ScottK: I am currently looking at logitech-applet.
<ScottK> TheMuso: OK.  If you have time for another...
<white> is there an ubuntu-private btw?
<TheMuso> ScottK: I'll keep that in mind.
<white> i am wondering if there is the same amount of flames if it exists
<Hobbsee> white: not to my knowledge.
<Fujitsu> white: Unfortunately, it won't backport. It seems to need a newer gpsim :(
<Hobbsee> white: there's a tech board private list, but that's only 4 people on it, iirc
<Hobbsee> everything else is public
<Fujitsu> What is -private? Only DDs?
<sistpoty> maybe they flame on tb-private? *g*
<white> Fujitsu: yes debian-private is a list for DDs only (and most of the stuff is quite useless)
<ajmitch> s/most/all/
<white> some DDs even unsubscribe
<Fujitsu> There's warthogs (Canonical only), maybe the flaming is there :P
<ajmitch> I think quite a few unsubscribe from there
<ajmitch> Fujitsu: probably talking about those MOTUs..
<sistpoty> hrhr
<TheMuso> ScottK: I am now going to have a look at that URL.
<ajmitch> hey sistpoty :)
<sistpoty> hi ajmitch
<ScottK> TheMuso: Thanks.
<white> Fujitsu: ah i got a mail about the bashism with a patch, great i will update the package later on and thatn you can sync from experimental if you want
<Fujitsu> Ah, good. I told him to file a bug about it, rather than mail you directly.
<white> yeah most of the ubuntu users fear the BTS :(
<Fujitsu> I only learnt how to use it properly when I took over soundconverter a few months ago.
<white> probably because some stupid DDs where exploding when they have read "Ubuntu system"
<white> Fujitsu: don't tell anybody, but sometimes i am even looking things up about tags and stuff ;)
<sistpoty> bts is imo easier than lp email interface
<Fujitsu> I find LP's email interface to be nice to use, except for the missing features.
<white> Fujitsu: do you want to debug another 915resolution problem i just got reported from an ubuntu user?
<Hobbsee> white: what problem was that?
<Hobbsee> heh, just another reason not to use the BTS :P
<TheMuso> ScottK: Just doing a pbuilder run now.
<ScottK> Great.
<Fujitsu> white: I'm about to leave, but I can look when I get back in about 3 hours.
<white> Hobbsee: what's your mail, I will just forward it as I need some more hours to finish my backlog :)
<Hobbsee> white: hobbsee@ubuntu.com / hobbsee@kubuntu.org - either work
<white> great
<Hobbsee> white: usually they're just launchpadname@ubuntu.com
<Hobbsee> for all the members
<Hobbsee> if that helps
<white> ah ok
<white> well bounced :)
* Hobbsee didnt even know 855GM's even did 1280X768 resolution
<white> i somehow have the feeling that my mail backlog is not becoming less ...
<Hobbsee> white: bah.  afraid i dont know anything at all about that.  my 915resolution on this system "just works", and i didnt have to use it on my old laptop
<white> well i do not even have any hardware here where i can test it with
<white> i normally get some reports from a friend who is using it
<white> i debianized the package when we needed it at company 
* Hobbsee wonders if that's just an X bug, as opposed to a 915resolution bug
<white> ha now we are even forced to vote our leader, otherwise we might loose our accounts ... rotfl
<bddebian> heh
<ajmitch> white: hm?
<white> ajmitch: Ganneff's DAM mail on -devel-announce :)
* ajmitch goes to read
<ajmitch> oh fun
* ajmitch wonders how many flames that will invite
<white> i don't wanna know
<ajmitch> see that sven luther is running for dpl? :)
<white> 200 mails about work on debian-edu <- do they want to kill me?
<ajmitch> yep
<TheMuso> ScottK: has anybody else looked at the package since I was?
<ScottK> No
<ScottK> Not that I know of
<TheMuso> ok
<ScottK> Did it build OK?
<TheMuso> Yeah just a sec.
<ScottK> Cool.
<TheMuso> ScottK: Ok, looks good.
<ScottK> Great.
<ScottK> That's pretty cool.  9 hours 16 minutes from first upload to 2 advocates.  This is definitely a sprint.  Thanks TheMuso, bddebian, and Adri2000.
<TheMuso> ScottK: Welcome.
* Hobbsee goes off to rescue work from certain lack-of-staff doom again
<TheMuso> Hobbsee: My sympathies.
<TheMuso> Have fun.
<white> ajmitch: rotfl, it is such a shame that -private is not public, we could ask people to pay money for it like a circus
<ajmitch> haha
<white> i am pretty sure that debian would become rich
<ajmitch> there will be some amusing historical threads in there
<Hobbsee> TheMuso: ugh, yeah, i will ;P
<white> well i am just skipping most of the mails now, but there were some funny ones :)
<Hobbsee> TheMuso: hopefully the Men With Shackles wont call again tonight.
<TheMuso> haha
<Hobbsee> TheMuso: oh, and hopefully we wont have to call the Men With Shackles In Training, aka SECURITY, to escort people out of the store.  
* sistpoty is off to bed
<sistpoty> gn8 everyone
<rmjb> Hey guys
<TheMuso> Whats the command to send messages via net send to windows machines from Linux?
<lastnode> Fujitsu, ping mate
<Nafallo> ehrm
* Nafallo is tired
<Nafallo> who handles UVF-Reqs?
* Nafallo doubt that Gajim will release before two days ago
<Laser_away> Nafallo: motu-uvf
<Nafallo> Laser_away: thanks
<Laser_away> Nafallo: see my email to ubuntu-motu
<Nafallo> I'm to tired to figure even that out myself ;-)
<Nafallo> I'm hundreds of mails backlogged there.
<Nafallo> I should try to get a GFE for gajim or something
<Nafallo> they always release bugfix-releases after UUVF
<ajmitch> Nafallo: *everyone* releases after UVF
<ajmitch> it's a fact of life
<ajmitch> hm
* ajmitch still had the bugs assigned to motu-uvf on his bookmarks toolbar
<ajmitch> how useful
<Nafallo> ajmitch: well, gajim seldom releases, but this cycle and the last one have both had bugfixes after UUVF.
<Laser_away> etch isn't out yet is it?
<joejaxx> Laser_away: i do not think so
<ajmitch> of course not
<Laser_away> so Debian releases after UVF ;-)
<ajmitch> but we didn't know that when setting the release schedule
<white> hurray, mail backlog more or less done (with marking heaps of mails as read withouth reading :( )
<ajmitch> well done
* ajmitch wonders how many motu-uvf have been processed already
<white> haeh did i miss anything, wasn't it "http_proxy=http://$username:$pw@$host:$port" ?
<AnAnt> bddebian: hello, thanks for reviewing tss, it was a wrong upload actually
<bddebian> AnAnt: NP
<zakame> afternoon all
<Fujitsu> Hi zakame.
<bddebian> Heya zakame
<zakame> hi Fujitsu bddebian 
<zakame> ooh revu sprint
<bddebian> Gnight gang
<zakame> gn8 bddebian :)
<imbrandon> Laser_away, most likely , there is no date yet for etch, it was dec 4 06 right ?
<imbrandon> heya ajmitch and Fujitsu 
<ajmitch> hi imbrandon 
<Fujitsu> Hi imbrandon.
<imbrandon>                                                                      geser
<imbrandon> nltest /dsgetdc:GSI
<imbrandon> ugh
<dholbach> good morning
<imbrandon> moins dholbach 
<dholbach> hey imbrandon
<TheMuso> Hey dholbach.
<TheMuso> Not often we see you round here on the weekend.
<imbrandon> hehe
<imbrandon> no djing for dholbach  tonight
<dholbach> it's 08:23 in the morning :)
<imbrandon> ahh right ;)
<dholbach> but i'll see Marcus Intalex (drum'n'bass dj and producer tonight)
<imbrandon> :)
<TheMuso> dholbach: cool.
<ludomatic> hi
<ludomatic> I have a question about building .deb, is it the right place?
<ludomatic> I try to build a deb package from a source without "configure" nor "make install"
<ludomatic> jaust have a $ make
<ludomatic> all "auto" tools I've tried failed
<ludomatic> to build a package
<ludomatic> any idea? I would like to keep original sources as-is
<ludomatic> is it possible to "override" th e makefile ?
<ludomatic> I've built a .deb with a script, tested with lintian, all is ok but I only have a "binary" package
<ludomatic> I'd like to make a clean deb and deb-src
<ludomatic> http://apt.ludomatic.fr
<TheMuso> !packagingguide
<ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
<ludomatic> k, ty.
<TheMuso> You're welcome.
<jenda> Hey there.
<jenda> Who is in charge of the contents of the Examples directory for Feisty?
<tsmithe> maybe ask in #ubuntu-devel ?
<tsmithe> as well...
<TheMuso> What examples directory?
<TheMuso> Ah the example content?
<TheMuso> I'd suggest looking at the maintainer of the package. :)
<jenda> ah :)
* jenda feels like a noob now :)
<tsmithe> jenda is a noob
<tsmithe> (although so am i...)
* coNP too :)
<jenda> TheMuso: thankee
<TheMuso> dholbach: Do you know why I was also sent a message re the latest GNOME Orca upload? I haven't received any previously.
<dholbach> TheMuso: you should have - you're in the maintainer field
<TheMuso> dholbach: Not previously I haven't.
<dholbach> that's really weird
<dholbach> i get them all the time somebody touches 'my packages'
<TheMuso> dholbach: Yeah tis.
<dholbach> that's the only explanation i have
* dholbach -> dogwalk - bbl
<TheMuso> ok
<nedko> TheMuso: is there any progress with fpconst?
<TheMuso> nedko: No not as far as I know.
<TheMuso> And unfortunately, I don't we can do anything about it at the moment.
<TheMuso> I really should follow up on the discussion that started, but seemed to die.
<nedko> :(
<Hobbsee> white: did you know fenio@debian.org, by any chance?
<Hobbsee> Bartosz Fenski, apparently
<webben> Why can spidermonkey (libmozjs-dev libnspr4-dev libsmjs-dev) not be installed alongside firefox evolution epiphany?
<white> Hobbsee: nope sorry, why?
<Hobbsee> white: htop is two releases behind in debian (and ubuntu)
<Fujitsu> Hobbsee: How long is that in time?
<white> hold on i check if he is mia
<Fujitsu> white: That's what I was thinking :)
<TheMuso> 6/c
<Fujitsu> Is -mia public?
<TheMuso> bah
<Hobbsee> Latest 	0.6.5 Notes (2006-11-29 10:48)
<Hobbsee>   	htop-0.6.5.tar.gz  Mirror 	134628 	1857 	Platform-Independent 	Source .gz
<Hobbsee>   	0.6.4 Notes (2006-10-04 09:47)
<Hobbsee>   	htop-0.6.4.tar.gz  Mirror 	133802 	1189 	Platform-Independent 	Source .gz
<Hobbsee>   	0.6.3 Notes (2006-07-23 15:58)
<TheMuso> Evening all. :0
<Hobbsee> hey TheMuso!
<white> you can get read access as non-DD if you ask myon and want to contribute
<white> as a DD it is on merkel
<TheMuso> We all reviewing?
<Hobbsee> TheMuso: you are, yes :)
<Fujitsu> Hobbsee: So 6 months?
<TheMuso> Hobbsee: Yep.
<Hobbsee> Fujitsu: ah, yep
<white> Hobbsee: nah he closed a bug at the 30th of jan
<white> at least this was his last gpg activity, so not mia afaik
<Hobbsee> white: right
* Hobbsee tries to figure out how to file a debian bug
<white> Hobbsee: go go go
* white motivates Hobbsee 
<TheMuso> Hobbsee: Its really easy.
<Hobbsee> hehe
<white> Hobbsee: use reportbug, that is the best
<white> oh damn something is really going wrong here
<Fujitsu> white: What's going wrong?
<Fujitsu> (and thanks for fixing that bashism, I'll upload it to Ubuntu tonight some time)
<Hobbsee> okay
<TheMuso> Bah! Why is it that my revu comments on the ml are formatted alright, but on revu itself its screwed?
<white> i am setting like http_proxy="http://sjoeris:$pw@stproxy.latrobe.edu.au:8080"
<Fujitsu> That should work fine, I use it at school.
<Fujitsu> What's it (not) doing?
<white> and i always get Error parsing proxy URL http://sjoeris:$pw@stproxy.latrobe.edu.au:8080: Bad port number.
<Fujitsu> No silly characters in your password?
<white> either i am too stupid or it is this damn ISA proxy
<Hobbsee> gah.  gotta remember ubuntu's smtp server...
<white> Fujitsu: yes there are
<StevenK> Hobbsee: fiordland.u.c
<TheMuso> Hey StevenK.
<stgraber> white : do you have : ',",<,> or : in your password ?
<Fujitsu> white: Make sure they're escaped and stuff.
* StevenK waves
<Fujitsu> Hi StevenK.
<white> let's see
<Hobbsee> StevenK: thanks.    forgot how to spell it
<stgraber> that caused me some problem with my school's proxy server
<Hobbsee> SMTP send failure: (-2, 'Name or service not known')
<StevenK> Hobbsee: fiordland.ubuntu.com works for me.
<Hobbsee> oh, i put smtp. in front of it.  silly me
<StevenK> Heh
<Hobbsee> right, now, how do i resend this bug, with the correct smtp server?
<Hobbsee> white: ^?
<white> well the thing should be somewhere in /tmp/
<white> just copy n paste
<white> maybe there is also a reportbug option, not sure
<Hobbsee> copy and paste into an email to submit@bugs.debian.org or something?
<white> well if you want to fill a bug against an existing package you start reportbug with:
<white> reportbug $package
<Hobbsee> eep, this is weird.
<Hobbsee> it's sending to the ubuntu tracker, nto the debian one?
<white> aeh yes i guess the ubuntu one is patched
<StevenK> Right
<white> hehe :)
<Hobbsee> meh.  drat
<StevenK> reportbug -B debian ...
<grazie> could someone recommend a good link for building a package with debug and the tools used to trace?
<coNP> grazie: sg. like https://wiki.ubuntu.com/DebuggingProgramCrash?
<grazie> coNP: Thanks. yes, I've seen that...it gives useful info on tracing crashes
<grazie> coNP: what I want to do is build a package with debug and use tools like gdb and anjuta to step through the code
<coNP> grazie: in the second part it is written there how to compile & install a package with debug symbols enabled
<coNP> grazie: if done, you can do whatever you want with that (gdb, ddd, anjuta...)
<grazie> coNP: great thanks...I mustn't have read it thoroughly :)
<white> Hobbsee: did you get around it?
<Hobbsee> white: sort of.  i just got rejected, as i didnt format the mail correctly.
<Hobbsee> white: i've just resubmitted
<white> :)
<white> they were just like "sender=Hobbsee" -> auto reject ;)
<Hobbsee> white: no, you mean "sender=*@ubuntu.com -> auto reject" :)
<white> :)
<imbrandon> hum no more /etc/init.d/ntpdate ?
<imbrandon> anyone know why?
<imbrandon> StevenK, ^^ ( likely canidate to know )
<TheMuso> imbrandon: I remember seeing a script for it under /etc/network somewhere.
<imbrandon> ( and yes ntpdate is installed )
<TheMuso> previously at least
<imbrandon> hum it should be a daemon though
<imbrandon> unless it got split out 
* imbrandon looks
<imbrandon> hrm dosent look like it
<white> imbrandon: in debian it got split afaik
<white> and they have the ntpdate-debian
<white> script which is like calling ntpdate
<white> not quite sure about ubuntu though
<imbrandon> theaccount@kgsinoclin01:~$ apt-cache search ntpdate
<imbrandon> ntp-doc - Network Time Protocol: documentation
<imbrandon> ntpdate - The ntpdate client for setting system time from NTP servers
<imbrandon> hum de hum
<imbrandon> looks like no init.d/ntpdate in our package ( but i can call it manualy )
<imbrandon> wasernt like that in breezy , wow
<Fujitsu> white: Do you want me to replace the Maintainer field when I merge 915resolution, as is being done with most?
<white> i don't mind
<Adri2000> TheMuso: you forgot to archive pyyaml on revu
<TheMuso> Adri2000: I'll take care of it if you haven't. :0
<TheMuso> Not hard to forget.
<Adri2000> I haven't
<TheMuso> np I just did it then.
<Adri2000> ok
<TheMuso> thanks for the heads up btw.
<TheMuso> I had several things happening at once there, so twas easy tooverlook it.
<TheMuso> ooo found something I think would be very useful eventually.
* TheMuso goes to revu.
<TheMuso> review it
<TheMuso> or maybe not
<TheMuso> no updates since comments were left.
<Fujitsu> Which package?
<TheMuso> gnome-hotswap-aplet
<Hobbsee> white: yay!
<white> ?
<Hobbsee> white: got a confirmation @ the debian bugtracker
<TheMuso> Wow.
<TheMuso> So many revu packages that haven't seen updates on them after comments are left, and have been left for a while.
<Hobbsee> TheMuso: yes.  unfortunately :(
<Hobbsee> TheMuso: seems that people think that if they put their stuff there, it will automatically get into ubuntu
<TheMuso> or they find what is being asked of them is too difficult.
<Hobbsee> that being said, they dont actually get notified of any comments - perhaps siretart could fix this in revu2 or somethign?
<Hobbsee> yeah
<TheMuso> Hobbsee: That would be a good idea.
<Fujitsu> That will hopefully be improved once this is done through LP.
<TheMuso> Fujitsu: What are the plans for lp/REVU?
<Fujitsu> Ask LaserJock, he knows more about it...
<Fujitsu> Basically, the package will be developed in bzr on LP, and reviewed on there, using a mechanism that is yet to be implemented.
<TheMuso> Right.
<TheMuso> But should new devs have to learn about bzr as well as packaing?
<TheMuso> Thats a bit full on IMO.
<Fujitsu> There's not much to learn about bzr.
<TheMuso> True.
<Fujitsu> (unless you're doing merging stuff, which isn't necessary in that situation)
<Fujitsu> Anyway, I need to go to bed.
<TheMuso> aha so do I.
<TheMuso> Just thought I'd find something to glance over and comment on.
<Fujitsu> You went to bed around this time last night, I seem to recall.
<Fujitsu> I'm running 30 minutes late tonight.
* Fujitsu heads off now, lest deadness be found tomorrow.
<TheMuso> Nah I was in bed later last nigt if I recall.
<white> Hobbsee: great, good effort :)
<Hobbsee> white: :)
<grazie_> coNP: if I follow https://wiki.ubuntu.com/DebuggingProgramCrash as discussed I can't the public key. Any ideas? I've tried before without succes
<coNP> grazie_: you might run debuild -uc -us to build package (without a gpg key)
<grazie_> coNP: I'll try. thanks again
<coNP> yw, grazie_ 
<grazie_> coNP: what do you do there's no package-dbgsym for the package you want?
<coNP> grazie_: make one from source
<grazie_> coNP: yeah, sorry being stupid :)
<dholbach> install pkg-create-dbgsym and run apt-get source -b <your package>
<grazie_> dholbach: thanks too. I didn't know about pkg-create-dbgsym
<dholbach> that's what creates those packages on the buildds
<coNP> grazie_: np :)
<grazie_> if <my package> is installed already do I need to remove before apt-get source -b <my package>?
<dholbach> no
<talex> Hi. Can someone help me get my package accepted before the freeze? I've made 4 uploads since October, but the only comments have been about versions becoming out-of-date! Any hints on getting this in appreciated: http://revu.tauware.de/details.py?upid=4206
<bddebian> Heya gang
<white> somebody around here with some skype knowledge?
<lionel> hi bddebian
<bddebian> Hello lionel
<lionel> white: I am a skype user
<white> maybe with a proxy?
<white> i somehow fail to tell skype that i a behind a proxy
<white> i thought it would just catch the env variables like http_proxy and stuff
<lionel> no, I am just behind a NAT
<talex> Hi bddebian. You provided some comments on my package (about needing to update some version numbers) last month. I uploaded a new version (http://revu.tauware.de/details.py?upid=4206) - is there any chance of getting this in for feisty? Thanks,
<bddebian> white: You should be able to just as <HttpsProxy> nodes to skypes shared.xml
<bddebian> s/as/add/
<bddebian> talex: I'll take a look
<talex> thanks!
<white> https?
<bddebian> And/or http
<white> right, because this proxy does not really support https
<bddebian> Everything I'm reading says it's supposed to look at existing Opera settings or your supposed to be able to set http_proxy as you say.  But that was one way I found on a forum :-)
<white> well i tried this <HttpsProxy> thing and it did not change anything
<white> and according to release notes it should even catch the konqueror settings, but i somehow doubt that :(
<bddebian> talex: OK, advocated
<talex> Cheers!
<grazie_> dholbach: & coNP : thanks... now cooking! :)
<coNP> grazie_: have fun :)
<Adri2000> ajmitch (and everyone): on the missing rc fixes page, some packages cannot be synced because there is a newer upstream version in debian. I guess we just backport the fix uploading an ubuntu1 version? the problem is that ubuntu version will still be < debian version, so it would be a good idea to tell to the missing rc fixes page that debian bugs #xxxx and #yyyy are fixed in ubuntu even if the version numbers don't say it, is it possible 
<Adri2000> ajmitch?
<crimsun> Adri2000: well, we certainly could make it easier for the script to parse
<crimsun> ala, something along the lines of what ClosingBugsFromChangelog does
<Le-Chuck_ITA> Hi all
<Le-Chuck_ITA> Now I know that there are members of the motuscience team here
<Le-Chuck_ITA> I would like an answer to the problem I raised in bug #82365
<Ubugtu> Malone bug 82365 in lyx "Please compile with assertion checking turned off" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82365
<Le-Chuck_ITA> even negative, but still a response
<rmjb> Hye guys
<rmjb> I'm having a problem creating a dapper pbuilder
<rmjb> it times out downloading binutils and aborts, leaving me with a base.tgz that's 0 bytes
<rmjb> and it takes over an hour to do that...
<ScottK> Good morning everyone - Just finished the scrollback, there was a lot there...
<crimsun> rmjb: are you using a known-good mirror, say, uk.archive.ubuntu.com ?
<bddebian> Damn lyx takes forever to build
<crimsun> why are people setting random targets?
<crimsun> "Nominated for Feisty by ..."
<crimsun> man, kill that junk
<enyc> crimsun: I dont know...  I know sheer nominated qpsmtpd edgy and dapper fix for dapper... which was silly not-knowing-what-doing...
<crimsun> enyc: SRUs are different
<enyc> crimsun: bah i dont know who to ask to get qpsmtpd fixes tested ;-) nobody seems interested... its such a simple thing...
<crimsun> I'll try to bring up those chroots to test. Are there specific arch constraints? (I only have x86)
<enyc> crimsun: its entirely arch idnependant (all perl / shell etc.)
<enyc> crimsun: just a very simple fix to allew working given that /var/run is tmpfs
<crimsun> enyc: right, I remember that now
<enyc> crimsun: 'qpsmtpd' in dapper-proposed edgy-proposed  ... err can find bug #s
<crimsun> I'm travelling, so stable wifi is hard to come by
<AnAnt> Laser_away: ping
<enyc> crimsun: hrrm actually i could really do with getting a  wlan card that works in edgy and with all linux wifi tools blah.  and works in pcmcia as well as pc-card.... on a p2 laptop and soforth...
<AnAnt> Laser_away: remember I told you about GPL Cver a couple of days ago ? some fella has already packaged it for Debian, it doesn't seem to have entered Ubuntu yet anyways, here's the URL : http://packages.debian.org/unstable/devel/gplcver
<enyc> crimsun: do you have any suggostions for anything i can order in a hurry ;-) that is known to work _well_ with all the linux tools ;-)
<crimsun> enyc: sorry, I can only vouch for the hardware in my Canonical-sponsored laptop (ipw2195abg using the ipw2200 driver)
<enyc> crimsun: [ok] 
<AnAnt> Laser_away: GPL Cver is a verilog simulator, that falls under the category of scientific apps
<AnAnt> Fujitsu: ping
<rmjb_> okay it didn't work :s
<rmjb_> so are there any pbuilder tricks for it not to abandon everything it downloads when creating if it gets an error?
<rmjb_> the download for me takes quite a while
<geser> normally pbuilder caches all downloaded debs
<rmjb_> hmm... for me (my 4th run of trying to create a dapper pbuilder) it gets a download error, aborts, leaved base.tgz at size 0 and has to do it all over again the next time
<rmjb_> is there a setting I can check?
<geser> the cache does only happen for normal use, not for the creation
<rmjb_> ah well
<geser> rmjb: you could try to download all the necessary debs and tell pbuilder/debootstrap to use them to build the tar.gz
<rmjb> I didn't know that could be done... I'll do that if this run fails
* rmjb crosses fingers
<geser> I don't know how to do it but you can tell debootstrap to use a file:// location to fetch the debs
<geser> and pbuilder uses debootstrap to create the base.tar.gz
<geser> in the worst case you had to look how pbuilder does it and call debootstrap by hand
<rmjb> I guess... pbuilder is a script or a binary?
<rmjb> I'll figure *something* out
<geser> it's a script
<tsmithe> hi.
<tsmithe> is anyone free for reviewage?
<AnAnt> ping Fujitsu 
<chris^> Hi
<chris^> will there be an FIX for the 2.6.17-11 upgrade?
<chris^> it has broken my wlan :(
<chris^> on over 10 machines...
<ScottK> chris^: This is not a good channel for that question, but it's fixed now.
<chris^> ScottK: there are no new packages on security.ubuntu.com
<Le-Chuck_ITA> bddebian: thank you for the upload
<Le-Chuck_ITA> where can I follow the process?
<bddebian> https://launchpad.net/ubuntu/feisty/+source/lyx/1.4.3-2ubuntu1
<Le-Chuck_ITA> ah ok, I didn't notice the -ubuntu1
<ScottK> chris^: The problem was that the package was not complete.  Try to install the new package linux-image-2.6.17-11-server.  For more help you should go to #ubuntu or #kubuntu depending.
<Le-Chuck_ITA> thank you again
<chris^> ScottK: server? I installed generic... 2.6.17-10 was also generic...
<bddebian> Le-Chuck_ITA: NP
<ScottK> Oops.  Generic then.  I was looking on one of my servers.
<Le-Chuck_ITA> bye all
<rmjb> bye Le-Chuck_ITA
<jekil> hi
<rmjb> hey jekil
<rmjb_> geser: it's still failing and the myriad of scripts that is pbuilder is tough to customise... pbuilder create can take an --http-proxy argument though, so I'm using that
<tsmithe> TheMuso, could you do me a revu?
<FliesLikeABrick> I'm working with the developer of Soldat, http://www.soldat.pl on a few things.  He's working on a new game which will be available for free for Linux, though not open-source.  1) is it possible to have it be put in apt 2) would it go in universe, multiverse, or something else 3) how would I go about having it put in once it is done?
<FliesLikeABrick> http://www.crimsonengine.com is the little development page for it
<geser> FliesLikeABrick: if there is no source available it would need to go into multiverse if it's redistributable
<FliesLikeABrick> thats what I thought, thanks
<FliesLikeABrick> I've already got his permission to pursue putting it in once the game is released
<FliesLikeABrick> geser and when that time comes, how would I go about having it put in multiverse?
<geser> like any other package: create a package, let it review on revu and once it's good enough it be uploaded to Ubuntu and placed in multiverse
<FliesLikeABrick> mk, I'll do some reading
<FliesLikeABrick> thanks
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<TheMuso> Hey MOTUs.
<bddebian> Heya TheMuso
<ScottK> Hi all.
<bddebian> Heya ScottK
<TheMuso> bddebian: You probably uploaded before I removed my advocation for logitech-applet. :)
<TheMuso> never mind
<bddebian> Doh
<bddebian> What was wrong with it?
<TheMuso> Missing homepage at the end of the description of package.
<bddebian> pfft
<rexbron> lol... still
<rexbron> the archive admin could me having a bad day
<rexbron> be*
#ubuntu-motu 2007-02-11
<LaserJock> still no kernel updates :/
<Fujitsu> Thankyou Soyuz.
<ScottK> LaserJock: Which kernel updates are you looking for?
<LaserJock> ScottK: edgy
* ScottK got one yesterday.
<LaserJock> Fujitsu: yep, wonderful
<ScottK> 2.6.17-11-server #2 SMP Thu Feb 1 19:53:33 UTC 2007 i686 GNU/Linux
<LaserJock> LP is causing a problem so the complete kernel set isn't in the archives
<ScottK> Ah.  I guess I got lucky then.
<LaserJock> you have the server kernel
<pianoboy3333> How can I check when I installed audacity?
<Fujitsu> It's only l-r-m that's the problem, isn't it?
<Hobbsee> pianoboy3333: look at the /var/log/dpkg.log
<LaserJock> Fujitsu: I think so
<pianoboy3333> Hobbsee: oh god...
* Hobbsee hasnt seen another way
<LaserJock> oh sweet, I updated and it's fixed
<pianoboy3333> Hobbsee: it's not in there
<Hobbsee> pianoboy3333: actually, better still, find the deb in /var/cache/apt/archives, and look at the time of downloading
<LaserJock> unless you clear your apt cache
<Hobbsee> well, yeah
<pianoboy3333> oh
<pianoboy3333> well that explains it
<pianoboy3333> ok... thanks
<sistpoty> hi folks
<bddebian> Heya sistpoty
<sistpoty> hi bddebian
<LaserJock> hi sistpoty 
<sistpoty> hi LaserJock
<Fujitsu> Hi sistpoty.
<sistpoty> hi Fujitsu
<LaserJock> man, people seem to get pretty heated over the new gnome control center thingy
<Fujitsu> Where? Forum?
<LaserJock> yeah
<Fujitsu> What are they complaining about?
<ajmitch> hi
<Fujitsu> Hey ajmitch.
<LaserJock> talking about mass movement to KDE and Xfce unless you can turn off the gnome control center
<Fujitsu> Terrific.
<sistpoty> hi ajmitch
<LaserJock> sort of the usual stuff
<Hobbsee> neat.  more kde people :)
* Hobbsee wonders what the g c c is
<LaserJock> it's sure amazing how people think the Ubuntu developers actively write all the code in the distro
<LaserJock> Hobbsee: Gnome used to have a menu for adminstration and prefernces
<PriceChild> The code to switch back to menus is there isn't it?
<LaserJock> well, that was the debate
<PriceChild> Amaranth just hasn't been told to add the necessary methods to alacarte to change it
<Hobbsee> and that we're lazy over not putting the official nvidia drivers in, and being able to fix the nvidia drivers on everyone's system, when we issue a kernel update
<PriceChild> and he doesn't like the code either supposedly
<Hobbsee> LaserJock: ahhh
<Fujitsu> Hobbsee, naturally.
* Hobbsee notes that kde has a control centre too.
<sistpoty> well, recent kde upgrade stole my clock in kicker :(
<Hobbsee> sistpoty: blame tonio_ for that
<sistpoty> hehe
<Hobbsee> sistpoty: he's messing with the kicker settings
<ajmitch> LaserJock: of course ubuntu developers write all the code in the distro
<ajmitch> LaserJock: didn't you know that sabdfl wrote the kernel & X?
<Fujitsu> ajmitch: He also wrote the NVIDIA drivers.
<LaserJock> sure he does *rolls eyes*
<phanatic> how many source packages are there in ubuntu (let's say feisty), and how many of them are in universe/multiverse?
<sistpoty> Hobbsee: luckily it wasn't too difficult to restore it, even though it included using the mouse *g*
<Hobbsee> sistpoty: hehe, true :P
<LaserJock> phanatic: I think there are like 4,000 in Main and 14,000+ in Universe
<Fujitsu> "This release of Ubuntu contains 22100 software packages across 6 architectures, from a total of 12715 source packages."
<Fujitsu> Not sure about how many are in each.
<phanatic> LaserJock: those are rather binary packages, no?
<phanatic> Fujitsu: thanks
<sistpoty> hm... anyone with arguments why I shouldn't upload zeroinstall-injector?
<Fujitsu> sistpoty: It's really really evil?
<sistpoty> Fujitsu: why?
<sistpoty> Fujitsu: or better, is it more evil than cnr? *g*
<Fujitsu> We don't want more easy ways for people to get foreign packages on their systems, and then file bugs about!
<Fujitsu> (and stuff CNR)
<LaserJock> phanatic: yeah sorry, for Edgy i386 there are 4,373 in Main and 14,420 in Universe
<LaserJock> binary
<rmjb_> wait, you guys don't write the entire distro?
<phanatic> LaserJock: thanks anyway :)
<Fujitsu> @lart rmjb 
<Hobbsee> sistpoty: i object!
<LaserJock> phanatic: 9224 in Universe for edgy
<Hobbsee> sistpoty: can they then file bugs about zeroinstall stuff?
<rmjb> lart?
<LaserJock> phanatic: 2663 in Main
<Fujitsu> Hobbsee, they'll find a way to, I can assure you.
<phanatic> LaserJock: great, thank you
<Hobbsee> Fujitsu: yes, but can we just reject them
<Hobbsee> ?
<sistpoty> hm... I've been thinking quite some time about zero-install injector, and still I'm a little bit undecided.
<Fujitsu> It's still infuriating.
<Fujitsu> Look at beryl and Flash.
<Ursinha> hi all
<Hobbsee> woo...there's a guy getting annoyed cos i rejected his ubuntu part of the soyuz bug, saying that all his bugs get rejected...
<rmjb> hey Ursinha
<Ursinha> i'm recentlly packaging stuff for ubuntu, and i would like to know if any of you use piuparts as testing tool
<Fujitsu> Hobbsee, hah.
<sistpoty> imo it's better to have such a program in the distribution... that way we have some control if things go wrong. but as I just wrote, I'm undecided, so if the majority is against it, I won't upload it.
<LaserJock> sure but at some point we're going to have to deal with the fact that people use this stuff
<Ursinha> rmjb, hey :)
<Hobbsee> Fujitsu: and whining that he doesnt know what soyuz is
<Hobbsee> "yes, you're not expected to.  you're not a triager"
<LaserJock> Ursinha: some do
<ajmitch> Hobbsee: which bug?
<Ursinha> LaserJock, I searched desperately all over the web looking for docs but it's hard to find
<Hobbsee> https://launchpad.net/bugs/83976
<Ubugtu> Malone bug 83976 in soyuz "-security vs. -updates/-proposed version comparison needs to be removed" [High,In progress]  
<Hobbsee> oh, i'ts been a private email about it
<rmjb> lart means to hit upside the head!
* rmjb used sarcasm before
<ajmitch> Hobbsee: right, I was wondering where the complain was
<Fujitsu> rmjb: I'd hope so!
<sistpoty> ha... I'll just add zeroinstall-injector to the motu meeting agenda... 
<Ursinha> Is there any other tools used for testing?
<rmjb> when's the next motu meeting?
<sistpoty> rmjb: wiki.ubuntu.com/MOTU/Meetings
<Hobbsee> ajmitch: http://paste.ubuntu-nl.org/5147/
<LaserJock> Ursinha: what kind of testing?
<rmjb> valentines day?
<Hobbsee> sorry, i cant figure out wordwrap
<LaserJock> sistpoty: well, the only thing for me is that we already have some other apps that are kinda similar
<Ursinha> LaserJock, i want to do some basic testing with my recently created packages, like installing, removing, updating and purging, just like piuparts do
<Fujitsu> Hobbsee: That's an impressively stupid email.
<Ursinha> LaserJock, guess that there is a policy and steps for a package to be accepted, right? i want to know if there are any tools for it
<LaserJock> Ursinha: I think many of us just do it in a chroot or spare Feisty machine
<Ursinha> LaserJock, okay, manually, you say?
<LaserJock> yep
<sistpoty> LaserJock: spare feisty machine? feisty is my production desktop *g*
<Fujitsu> sistpoty, I think it is for most devs.
* sistpoty remembers days without x during dapper and some ridiculous silly way of fixing it
<ScottK> Hobbsee: I have suggested to people like that in the past that if they wanted someone to whine to, then they ought to buy a support contract from Canonical.  Once, I even got a nice, "I may just do that" response...
<Hobbsee> Fujitsu: uh, yup :D
<Hobbsee> ScottK: that's not a bad idea
<Ursinha> LaserJock, i thought that you are like debian that tests everything automatically
<LaserJock> sistpoty: well, not everybody does that ;-)
* Hobbsee does
<LaserJock> my production machine is OS X so not much oppritunity there
<LaserJock> well, if the person really is getting 99% of their bug reports (I guess that means they've filed 100 bug reports) then there *is* a problem, IMO
<Ursinha> LaserJock, anyway, thanks :)
<LaserJock> LP is sorta difficult for devs, I'm sure it can be very confusing for average users
<Ursinha> LaserJock, i want to contribute with ubuntu
<LaserJock> sistpoty: do you use piuparts? I remember either you or siretart using it
<sistpoty> LaserJock: yep... I always use it
<LaserJock> sistpoty: did you see Ursinha's question?
<Hobbsee> where's the guide on how to file a bug?
<LaserJock> is there one?
<sistpoty> LaserJock, Ursinha: what's the actual question? how to use piuparts?
<Ursinha> sistpoty, i kinda found out, but i wanted to be sure about it
<sistpoty> Ursinha: got a feisty pbuilder at hand? then it's really easy
<Hobbsee> oh, found it
<Ursinha> i'm at edgy and using pbuilder
<Ursinha> is there anything special about feisty build?
<Hobbsee> all the feisty packages/
<Hobbsee> ?
<sistpoty> Ursinha: nope... but the chroot-tarball contains feisty packages, not edgy ones
<sistpoty> Ursinha: I thought you wanted to do feisty-piuparts testing?
<sistpoty> Ursinha: or did I get that wrong?
<Ursinha> actually i repacked an app fpr edgy
<Ursinha> for
<sistpoty> Ursinha: ah..k so you want to test the edgy one, right?
<Ursinha> and i've made some changes, like adding scripts
<Ursinha> sistpoty, edgy and dapper
<Ursinha> sistpoty, i intend to create a package for dapper which works on edgy
<sistpoty> Ursinha: well... at least afaik piuparts cannot do testing for dist-upgrades... it will only install the latest available version and then the debs you give it to install and test upgrades between these two versions
* Hobbsee saves that email under "stupid"
<sistpoty> Ursinha: so if you have an edgy pbuilder, you can use this for upgrade tests between standard edgy and a package you supply it
<Ursinha> sistpoty, i see... but i was testing in here and if i pass -d dapper -d edgy to piuparts, ir runs apt-get dist-upgrade between them
<Ursinha> sistpoty, oh, i see
<sistpoty> Ursinha: oh nice... seems like you already know more about piuparts than I do :)
<Ursinha> sistpoty, :D
<sistpoty> (my knowledge is a little bit aged *g*)
<Ursinha> sistpoty, hahah :)
<Ursinha> sistpoty, actually i have a silly question
<sistpoty> Ursinha: don't hesitate to ask
<Ursinha> sistpoty, does piuparts have a configuration file?
<sistpoty> Ursinha: no idea... I use a script that calls pbuilder + piuparts, so I never looked for a config file 
<sistpoty> Ursinha: it doesn't have one in the package (and the man page doesn't mention one)
<Ursinha> sistpoty, hm... any parameters to tell piuparts that ubuntu sections are main, restricted, universe and multiverse, instead of main, contrib and non-free?
<Ursinha> i opened the piuparts code, and saw it hardcoded
<sistpoty> Ursinha: let's see what I use: piuparts -b %s -d %s -m \"%s\" %s" % (BASE, DISTRIBUTION, MIRROR, s)
<sistpoty> Ursinha: with MIRROR being "http://de.archive.ubuntu.com/ubuntu main universe multiverse"
<Ursinha> hmmmmm i see
<Ursinha> i see i see
<Ursinha> sistpoty, just checking, whick version is your piuparts package?
<sistpoty> Ursinha: 0.20-3
<Ursinha> sistpoty, mine is 0.20-1
<Ursinha> it's feisty one?
<sistpoty> Ursinha: yes
<Ursinha> sistpoty, oh, thanks :)
<sistpoty> Ursinha: just in case you wonder what script I use for building + piuparts: http://tiber.tauware.de/~sistpoty/scripts/ralf.py (lol, this copy is even yet for edgy *g*)
<Ursinha> sistpoty, oh thanks! surely it'll be useful :)
<sistpoty> you're welcome
<Ursinha> sistpoty, are you official maintainer?
<sistpoty> Ursinha: I'm a motu
<Ursinha> sistpoty, :)
<Ursinha> sistpoty, is it hard to be a motu?
<sistpoty> Ursinha: do you mean hard to become a motu? or hard work being a motu?
<Ursinha> both :)
<bddebian> None of the above? :-)
<sistpoty> Ursinha: well, it's not that hard to become a motu imo... if you show some skills on packaging and help out with fixing packages, you can do it in one or two month
<sistpoty> Ursinha: and the hardest thing about being a motu is that it's a neverending source of work
<rmjb> I thought that would be the best thing
<Ursinha> sistpoty, guest that is the best thing
<Ursinha> rmjb, agreed :)
<sistpoty> hehe
<sistpoty> ok, you've got the right attitude Ursinha :)
<Ursinha> sistpoty, nice :)
* sistpoty is out for a cigarette
<Ursinha> sistpoty, when you get back :) where is the source of all work, so i could get started?
<Fujitsu> Ursinha: Fixing thousands of bugs, merging packages (though that's basically over)...
<Ursinha> Fujitsu, and where can i find it?
<geser> Ursinha: a good source right now is to look after unmet deps or check the failed rebuilds from last archive rebuild
<Ursinha> geser, is there a place where it can be found? wiki or something
<Hobbsee> http://www.smh.com.au/news/digital-music/emi-studies-mp3-sales/2007/02/10/1170524345914.html
<Hobbsee> neat ^
<geser> Ursinha: unmet deps can be found with "apt-cache unmet -i"
<Ursinha> geser, just found the wiki :)
<rmjb> Hobbsee: Feb 11... news from the future!
<Hobbsee> rmjb: of course!
<geser> Ursinha: and the failed rebuild logs at http://people.debian.org/~lucas/logs/2007/02/01/
<bddebian> Hmm, look at glibc which I compeltely don't understand or review packages that I apparently do wrong....
* LaserJock starts a feisty dist-upgrade on his "production" laptop
<rmjb> LaserJock is brave
<Fujitsu> LaserJock: That's the spirit. More testing!
<Fujitsu> rmjb: Most devs run Feisty...
<LaserJock> seems like most of the stuff I want is on Feisty anyway
<LaserJock> I run it, just not a ton
<LaserJock> I mostly ssh into a Feisty box
<rmjb> I have a feisty vm for testing
<Fujitsu> I think all the main devs should be forced to run Feisty only. That way, when something breaks horribly they have a good incentive to fix it :P
<rmjb> other than that I can't handle the constant downloads... connection not fast enough
<Ursinha> Fujitsu, hauhau good
<sistpoty> LaserJock: btw. if you are looking for a possible MIR, you could check libfacile-ocaml-dev (see bug #66362)
<Ubugtu> Malone bug 66362 in kdeedu "Equation Solver not enabled in Kalzium" [Low,Confirmed]  https://launchpad.net/bugs/66362
<Ursinha> geser, i was looking in here, in the unmet list
<Ursinha> geser, what can i do for helping? pick up the source, correct the dependency and repack?
<geser> Ursinha: in short yes
<sistpoty> Ursinha: best if you can supply a debdiff
<Ursinha> sistpoty, i see, but why?
<geser> Ursinha: to save you work check first if a bug is opened for it
<geser> Ursinha: if you attach your debdiff to a bug a motu can review it and sponsor the upload
<Ursinha> geser, ok :)
<Ursinha> geser, nice, good to know
<geser> some unmet deps are already known and there is also an explanation why it can be fixed
<LaserJock> Hobbsee: I guess technically -motu is just for motu specific stuff, -devel is for all devs
<Hobbsee> LaserJock: probably, yeah
<LaserJock> mdz was emphasizing that a bit with the MLs too
<Hobbsee> right
<LaserJock> I have a hard time doing that
<LaserJock> I like to watch -devel, not so much participate
* Hobbsee participates in both
<LaserJock> I'm always afraid of saying something stupid
* Hobbsee is just a chatterbox :(
<LaserJock> not annoyingly so though
<Hobbsee> i dont think that you'll get @lart'd too much though
<LaserJock> maybe ;-)
<Hobbsee> you could be one of them at some point - it'd be bad to ostracise you now :P
* LaserJock feeds his DSL connection Miracle Grow
<LaserJock> 2hrs to go at ~90k/s
<Fujitsu> dist-upgrade, LaserJock?
<LaserJock> to Feisty yes
<Hobbsee> LaserJock: ouch.
<ajmitch> ah, lots of pain
* Fujitsu thinks we could do with a commentable table of unmet deps and failed rebuilds.
<LaserJock> yep, get on it
<Fujitsu> Shouldn't be too difficult for the unmet deps.
<LaserJock> ajmitch: pain? it shouldn't be
* Fujitsu likes getting 1.1MBps from mirror.pacific.net.au
<geser> have somebody an idea what we should do with mozilla-browser? it was removed from debian (and replaced with seamonkey aka iceape)
<Hobbsee> Fujitsu: me too :P
<Fujitsu> geser: I think we should remove it, and replace it with seamonkey.
<geser> the removal is easy but where do we get a seamonkey package from?
<Fujitsu> Mangle iceape, I guess.
<Fujitsu> But then we have to get Mozilla approval...
<Fujitsu> Maybe just use iceape rather than seamonkey.
<Fujitsu> We can't do much else in the limited time we have before FF.
<LaserJock> do we have the same issues with seamonkey as we did with FF?
<Fujitsu> I presume so. It is Mozilla-branded.
<geser> do we want the extra work for the renaming? can't we simply take iceape from Debian?
<Fujitsu> geser: That's what my last suggestion up there was.
<LaserJock> well, perhaps we should ask ubuntu-devel
<LaserJock> I'm not sure if mdz did anything with seamonkey or thunderbird
<LaserJock> or if he cares
<Fujitsu> We can't use the Seamonkey name without getting Mozilla-approval of patches.
<bddebian> Hmm, this build of bibus ought to be interesting
<Fujitsu> Seamonkey isn't a very well known product name, so it's not as important to keep the name.
<Fujitsu> bddebian: You packaged it?
<LaserJock> yeah, but I think we keep thunderbird and firefox
<bddebian> Fujitsu: Don't you look at revu? :-)
<LaserJock> it might be confusing to do iceape
<Fujitsu> Perhaps.
<Fujitsu> Do we have time to get approval and rebranding done for Feisty?
<Fujitsu> I doubt it.
<LaserJock> we just at least discuss it on the motu list
<geser> counts seamonkey/iceape as a new upstream version of mozilla-browser? as we are in UVF
<Fujitsu> They are new packages, not new upstream versions.
<Fujitsu> They have a different numbering scheme, different name, etc.
<Fujitsu> Even so, we still have only 10 days.
<DarkMageZ> is mozilla-browser even maintained by mozilla anymore?
<Fujitsu> DarkMageZ: I don't believe so.
<geser> the removal bug in Debian mentions it's abandoned upstream
<plugwash> it isn't, firefox and friends were supposed to release it
<plugwash> *replace it
<Fujitsu> Seamonkey replaced it, not Firefox/Thunderbird.
<geser> in the end
<plugwash> Fujitsu no seamonkey is a semi-official project to continue the mozilla suite after mozilla replaced it with firefox thunderbird etc
<geser> afaik it was first planned to be replacey by firefox and thunderbird and then a group continued on mozilla-browser
<Fujitsu> Hm, OK.
<bddebian> Gah, what's the replacement for wxpython?
<LaserJock> do we have an existing seamonkey package at all?
<LaserJock> replacement?
<LongPointyStick> right, i'm back
<plugwash> don't think so, i think debian went straight from mozilla suite to iceape
<bddebian> I mean is it like python-wxgtk2.6?
<LaserJock> bddebian: I didn't think there was a replacement
<LaserJock> bddebian: it should just be wxpython
<bddebian> I don't see any packages called wxpython is my point :-)
<LaserJock> oh right, python naming conventions I guess, it should be python-wxgtk2.6
* bddebian points gun at his head :)
* Hobbsee removes the gun
<Hobbsee> mine now.
<LaserJock> bddebian: if you can't play nicely with the gun you'll have to let Hobbsee keep it
<bddebian> Oh yeah, that's not dangerous or anything :-)
<geser> Hobbsee: isn't a long pointy stick enough? do you need now also a gun?
<Hobbsee> geser: no.  but it could be fun.  :D
<geser> but be carefully where you point it
<LaserJock> hmm, this is odd, I subscribed to launchpad-users but haven't gotten any mail
<Ursinha> sistpoty, back again :)
<bddebian> Gah bibus's build system sucks ass
<Ursinha> i'm analysing piuparts log, and it seems not to say if it finished sucessfully or not
<Fujitsu> LaserJock, there have been 4 emails over the past 24 hours, but that's about it for the week.
<sistpoty> Ursinha: can you put it to a pastebin?
<Ursinha> of course :)
<LaserJock> Fujitsu: but I didn't get any of them, yet
<LaserJock> maybe I'll get check my procmail log
<LaserJock> bddebian: :(
* sistpoty needs to go to bed now
<sistpoty> gn8 everyone
<bddebian> LaserJock: setup.py seems to want X running :-(
<LaserJock> ??
<LaserJock> argg, procmail is eating my mail
<Ursinha> well people, guess i need to sleep now
<Ursinha> good night for all
<Ursinha> see ya tomorrow :)
<bddebian> LaserJock: http://pastebin.us/13994
<Fujitsu> bddebian: Does that build want a running X server?
<bddebian> Looks that way
<Fujitsu> bibus?
<bddebian> That's not how they had it installing but LaserJock whined about the mess it is currently ;-P
<bddebian> Yes
<LaserJock> I whined?
<LaserJock> can you paste the setup.py?
<bddebian> I'm kidding.  Your comments on REVU :-)
<LaserJock> hmm, can I just have procmail send all mail somewhere?
<StevenK> LaserJock: Yes.
<StevenK> LaserJock: It has been a while since I've used procmail, though.
<bddebian> LaserJock: http://pastebin.us/13995
<LaserJock> ah, actually I think I figured it out
<LaserJock> it was sending all mail that I didn't have a rule for to /var/spool/$USER
<LaserJock> and I don't want that
<StevenK> I'd guess /var/mail/$USER, actually
<LaserJock> but it looks like I can set ORGMAIL to what I need
* StevenK hugs Sieve some more
<LaserJock>  /var/spool/mail/$USER ;-)
<LaserJock> bddebian: ahh, I see
<LaserJock> it's using wx for dialog boxes to aske the user things
<bddebian> Yep :-(
<LaserJock> patch it!
<bddebian> I'm gonna try something else.  THough I'm shooting in the dark as this point :-(
<LaserJock> anybody happen to know how to reference the root mail directory in maildir format? is it just ./ ?
<bddebian> Holy crap, could that possibly have worked?  Hmm
<LaserJock> bddebian: any luck?
<bddebian> Well it built but I'm having an issue with my freakin' Feisty machine to test it :-(
<Burgundavia> LaserJock: have you got an rsync line for the latest feisty?
<LaserJock> no, what are you looking for? daily .isos?
<Burgundavia> LaserJock: daily, but the rsync syntax drives me batty everytime I try and use it
<bddebian> LaserJock: Well it "works" but doesn't set up the database.  pycentral didn't create a postinst
<LaserJock> Burgundavia: rsync -az --progress rsync://cdimage.ubuntu.com/cdimage/daily/current/feisty-alternate-i386.iso feisty-alternate-i386.iso
<rmjb_> personal opinion, when trying to backport something, how many build dependencies would you all be willing to backport before you give up and decide to dist-upgrade?
<rmjb_> I'm looking at backporting vlc to dapper...
<bddebian> fool
<bddebian> :-)
<rmjb_> that means you'd never give up? :)
<Burgundavia> LaserJock: thanks
<LaserJock> hmm, ~1.5 hrs to download and 1hr to install for dist-upgrade to Feisty
<Hobbsee> hehe
<Hobbsee> sounds about right
<LaserJock> I always get excited when the download is done
<LaserJock> and then it's like "oohh, still a lot more to go"
<Hobbsee> hehe
<elkbuntu> i just set it going and forget about it, come back half a day later
* Hobbsee whines about upgrading edgy
<LaserJock> ah, well I always do it in the middle of a project
<LaserJock> gosh, why does vim always have issues updating
<Hobbsee> LaserJock: because it hates you
<bddebian> Because it's not nano?
<LaserJock> it certainly does hate me
<LaserJock> doh
<LaserJock> it just said it couldn't upgrade nano
<LaserJock> :-)
<LaserJock> editors hate me
<LaserJock> we'll see if emacs chokes
<LaserJock> that'd just make it complete
<keescook> bust out 'ed'!
<LaserJock> wahoo
<ScottK> Emacs get you too?
<LaserJock> I made it to Feisty
<LaserJock> still some funkyness I gotta work out
<ScottK> Congratulations.
* RAOF lives on Feisty funkyness :)
* ScottK has two hard drives for the laptop.  One Edgy and one Feisty.
* jdong was forced to use emacs today
<jdong> STUPID EDITOR <flamesuit on>
<LaserJock> I'm using it more these days
<Fujitsu> jdong: FORCED? What inhumanity is this?
<LaserJock> I keep switching between vim and emacs
<jdong> Fujitsu: as in AFS wasn't available and emacs was installed....
<jdong> along with solaris vi.
<jdong> that's my two editor choices :)
<jdong> and solaris vi with a sun keyboard wasn't a walk in the park either.
<_ion> KDE is better than Vim!
* theCore steps-in the pseudo editor war
<theCore> Emacs rocks!
<Fujitsu> !start an editor war
<jdong> SHUT UP.
* theCore vanishes again
* Fujitsu drops some rocks on theCore.
<LaserJock> I like them both!
<jdong> Go the F-* C-k away
<jdong> :)
<Fujitsu> My father is an emacser. I've always been ashamed of that.
* theCore send some boomerangs to Fujitsu ((((( ((((( (((( 
<LaserJock> heh, why in the world would you be ashamed
<LaserJock> he's using a real editor
<_ion> "he's dating real men"
<theCore> (oh no... the boomerangs are coming back)
<theCore> ))))))))))))))
<_ion> lisp?
<theCore> hehe, yep
<theCore> ok I admit it. It was a bad joke ...
<jdong> lol
<jdong> that's not funny :)
<jdong> we're learning scheme right now :)
<theCore> LISP -- Lots of Irritating Superfluous Parentheses :)
<_ion> It's both one of the most beautiful languages and one of the most ugly languages simultaneously. ;-)
<_ion> And the things that make it ugly are the things that make it beautiful.
<LaserJock> hmm, so I have a ton of auto-removable stuff
<theCore> jdong: http://paste.lisp.org/display/36702
<ScottK> LaserJock: Careful.  Once it wanted to autoremove my entire system.
<LaserJock> yeah
<jdong> theCore: yep :)
<LaserJock> I also have a lot of local packages (it says)
<theCore> jdong: Scheme is great 
<jdong> it's still too early for me to make a judgement :)
<theCore> but, it takes some time to understand why :)
<LaserJock> grr, how am I supposed to figure out if I need these. Nothing deps on them
<_ion> I use debfoster to keep unnecessary packages out of the system.
<ScottK> LaserJock: In my case the metapackages had somehow disappeared.  Once I reinstlled them, all was well.
<_ion> The first time you run it  if you haven't been using it since you installed the system  it asks a *lot* of questions, but after that it is really nice.
<LaserJock> well autoremove works well
<LaserJock> except for dist-upgrades
<LaserJock> well, I'm going to just get rid of these packages and see what happens
<theCore> bed time, good night all
<ajmitch> mm, I love the smell of frying computers
<LaserJock> ?
<Fujitsu> Night, LaserJock.
<LaserJock> hm?
<ScottK> Reminds me of a cousin of mine that had Apple ] [ serial number 32.  He pitched it after the motherboard burned.
<ajmitch> LaserJock: ah, my desktop is having a few 'issues'
* ajmitch shut it down before the burning electronics smell got too strong
<jdong> ajmitch: that's what dustoff is for
<jdong> :)
<jdong> and you can save the rest for huffing... oh wait nvm
<jdong> :)
<ajmitch> another incredibly useful comment..
<jdong> seriously, dust-off is great for quickly intervening in overheating electronics
<jdong> spray it upside down and it'll spray freezing refrigerant out
<jdong> we used it in robotics to cool down motors all the time
<jdong> nice 80A motors that get fried from match to match.... worked wonders
<Fujitsu> LaserJock, oops, I read theCore's goodnight as being from you >_>
<LaserJock> quick question, anybody know how to diagnose a failt to resume form suspend/hibernate problem?
<StevenK> Wave mjg59 at your laptop? :-P
<LaserJock> heh
<LaserJock> the bugs are so numerous I don't even know where to start looking
<LaserJock> it worked for edgy, but dist-upgrading has caused it to fail
<Laser_away> ok, anybody know how big i386 and source repos (Main+Universe) are?
<Laser_away> 20GB each?
<Fujitsu> Laser_away: i386 is about 13GiB for everything. debmirror will tell you exactly how big your requested combination is.
<StevenK> It would probably be roughly 39Gb
<StevenK> My local mirror is i386 and amd64, which is 39Gb.
* ajmitch did start grabbing the archive with debmirror
<ajmitch> but I really blew through the 30GB cap for the month
<ajmitch> hi Yagisan 
<Yagisan> G'day ajmitch 
<StevenK> Hrm. Looks like my mirror downloaded just shy of 20Gb last month.
<Yagisan> I feel great regret in upgrading to feisty today
<Yagisan> it must hate raid setups
<Yagisan> it only likes to bring up 1 disk of the raid array :/
<ajmitch> how annoying
<Yagisan> well - at least I can use a feisty kernel now
<Yagisan> it likes to randomly pick 1 disk too O_O
<ajmitch> that wouldn't be so useful if it's RAID 5
* ajmitch hasn't really seen raid problems lately
<ajmitch> most I've had is a nice smoky smell from the system, with a couple of fans dead :)
<Yagisan> its a raid 1 - so it just means running 1 command and waiting about 90 minutes to sync
* ajmitch thinks it was probably the power supply that was getting a bit warm
<Yagisan> nasty
<Yagisan> ajmitch, remeber the accident my wife had with the hospital ?
<Yagisan> ajmitch, in anycase - shes off for major surgery next month - leaving just me with the kids for a wekk >:)
<ajmitch> Yagisan: oh, lucky you
<Yagisan> ajmitch, she's more scared of me with the kids, rather then the fact she's getting chopped up, and rebuilt, bigger, stronger, faster etc
<Le-Chuck_ITA> Hi all
<Le-Chuck_ITA> a quick question: shall I close dapper bugs in universe if they are fixed in edgy and feisty?
<ajmitch> usually yes, with an explanation saying that
<Le-Chuck_ITA> this maybe having to do with "long term support" that I don't know of :)
<Le-Chuck_ITA> ok, thank you
<ajmitch> if necessary, the bug can be marked as closed in 'ubuntu', but open in 'ubuntu (dapper)'
<ajmitch> but we usually track that only for important bugs where fixes would get into dapper-updates
<Le-Chuck_ITA> ok
<imbrandon> brandon@voyager:/storage/files/ubuntu/rsync$ du -hsc ./
<imbrandon> 214G    ./
<imbrandon> 214G    total
<imbrandon> brandon@voyager:/storage/files/ubuntu/rsync$
<imbrandon> 200+ GB for the whole thing StevenK 
<StevenK> I see that. I don't need to mirror everything. :-)
<ajmitch> not bad
* ajmitch found that the dead chipset fan for this motherboard is not uncommon
<ajmitch> so I may as well replace with a heatsink, there's another fan blowing air past it now :)
<imbrandon> ;)
<AnAnt> ping Fujitsu 
<ajmitch> drive-by ping..
<Mez> ajmitch, pinging who ?
<ajmitch> Mez: scroll up about 3 lines & see
<Mez> ah k
<HAL9003> hi guys
<HAL9003> is there a reason why "fpc" or "Free Pascal" is not in the repositories, or am i just too blind to find it?
<CicalaMvta> HAL9003: you are looking for fp-compiler? ;-)
<HAL9003> oh!
* HAL9003 slaps synaptic
<CicalaMvta> HAL9003: apt-cache search <expr> is your friend
<HAL9003> i let it search for "pascal" and it only listed gpc
<HAL9003> CicalaMvta, negative. no fp-compiler. just GNU Pascal Compiler
<HAL9003> i talk about 6.06 Dapper btw, not Edgy
<CicalaMvta> HAL9003: sorry
<CicalaMvta> it's just in egdy and feisty
<HAL9003> should have mentioned the version i use, my bad
<CicalaMvta> HAL9003: you could try to download and manually install the packages
<CicalaMvta> HAL9003: there are no special dependencies 
<HAL9003> i think about setting "APT::Default-Release" and adding edgy repositories, so i can "apt-get install edgy/fp-*
<sistpoty> hi folks
<gpocentek> hello sistpoty 
<sistpoty> hi gpocentek
<sistpoty> freeflying_: I've updated your revu account, you can review now
<s_spiff> hey, new to MOTU, can someone tell me what are the requirements to help in MOTU? and to become a MOTU?
<sistpoty> s_spiff: everyone can help, there aren't requirements for that...
<freeflying_> sistpoty: thanks
<pochu> s_spiff: to join motu: https://wiki.ubuntu.com/MOTU/Hopeful https://wiki.ubuntu.com/MOTU/Hopeful/Recruitment
<pochu> and https://wiki.ubuntu.com/MOTU
<s_spiff> pochu thanks a lot. will check it out
<pochu> s_spiff: np :)
<s_spiff> sistpoty okies. new to the whole concept. been on ubuntu for some time now, but the first time I saw about MOTU
<sistpoty> s_spiff: know some stuff about debian packaging yet?
<s_spiff> nah
<s_spiff>  sistpoty nopes, I know a bit of programming which again is rusty since I tried my hand at it few years ago in school.
<sistpoty> s_spiff: I guess it might make some sense to read some guides (you can find these in the wiki) then and play a little bit around as a starting point
<s_spiff> 
<s_spiff> #ubuntu-in 
<s_spiff> umm ok
<lidb> hello, who can help me delete the llk-linux files in incoming, it's a broken upload, thanks
<sistpoty> lidb: I'm on it
<sistpoty> lidb: done
<lidb> sistpoty: yes, thanks
<lidb> sistpoty: do you know can I do not upload the orig.tar.gz again? I have uploaded it on the last upload several days ago
<sistpoty> lidb: please always do uploads with an orig.tar.gz, as revu won't reuse existing orig.tar.gz's...
<sistpoty> lidb: you could in theory upload a diff-gz only package (no -sa to debuild) if the tarball is extraordinary big, but please state this in a comment to your upload referring to the orig.tar.gz
<lidb> sistpoty: OK, but it's somehow large when network bandwidth is not enough, any plan for add a feature about this?
<sistpoty> lidb: the plan is there since long ago... but I guess it will still take time until something new for revu will actually get implemented :/
<lidb> sistpoty: please help delete it again, i will upload it again without the orig.tar.gz, thanks
<sistpoty> lidb: done
<lidb> sistpoty: thanks
<lidb> sistpoty: what's the time interval of the revu server scan the incoming, 5 minute?
<sistpoty> lidb: either 5 or 10 minutes
<sistpoty> (not quite sure)
<bddebian> Heya gang
<_ion> Hi
<geser> Hi bddebian
<bddebian> Heya _ion, geser
* ajmitch wonders if he should ask for UVF exception for ~20 zope packages :)
<bddebian> ajmitch: Of course :-)
<jdong> can someone sponsor debdiff @ bug 76967?
<Ubugtu> Malone bug 76967 in openafs "OpenAFS kernel modules don't build with Feisty kernel 2.6.20" [Undecided,Confirmed]  https://launchpad.net/bugs/76967
<jdong> it's been tested and confirmed functional by two users
<jdong> without it OpenAFS modules FTBFS on feisty
<moreati> Hi all, I'm making customised version of libdrm and mesa for myself, from Debian experimental. I've completed and successfully tested with pebuilder libdrm. I'd like to do the same for mesa, Is it possible to install my customised libdrm version to the chroot, to satisfy the customised mesa dependancy?
<bigon> Hi,
<tepsipakki> moreati: one way is not to use pbuilder, but to debootstrap your version and install the package there, then build mesa
<bigon> what process must I follow to update a package for edgy?
<geser> moreati: you can login into the pbuilder and build the package by hand
<geser> bigon: https://wiki.ubuntu.com/MOTU/SRU
<bigon> geser: thanks :)
<moreati> tepsipakki: forgive my newbness. Do you mean use the debootstrap command, or pbuilder with the action debootstrap ?
<tepsipakki> debootstrap the command
<tepsipakki> the manpage says it all
<moreati> tepsipakki: ok, thankyou. I'll read up on it.
<tsmithe> hi
<tsmithe> is anyone free for a hopefully quick review?
<tsmithe> anyone free for a hopefully quick review, anyone at all?
<crimsun> tsmithe: which source package?
<tsmithe> crimsun, wired, if you could
<tsmithe> thanks
#ubuntu-motu 2008-02-04
<RAOF> Howbidie!
<doofy`> im confused, say i need to patch a package. I download the current source. Untar it, make the orig, dh_make it, edit the source code as necsarry and then debuild. What do I then do with the source changes? I upload the diff.gz to LP, but what about the actual source changes?
<RAOF> doofy`: They're in the diff.gz.  But that's not actually what you want to do.
<doofy`> so assuming i found a bug that needs fixed in LP what would i do?
<RAOF> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
<RAOF> There it is!
<doofy`> thats just changing stuff in the decsription under debian/control
<doofy`> is the same relevant for actual changes of source code?
<RAOF> doofy`: Yes.  You generally want to use a patch system, but it's the same process.
<doofy`> patch system?
<RAOF> doofy`: Such as dpatch, quilt, or simple-patch-sys (for CDBS).
<doofy`> okay thats what I assumed
<doofy`> where do the patches get uploaded to?
<RAOF> They're in the debdiff.
<RAOF> (The patches end up in debian/patches, generally)
<doofy`> they arent actually in the diff.gz though are they? I looked through it an saw nothing of that sort
<slangasek> if they aren't, then something's gone wrong with your source package building
<slangasek> that's where all changes to the source are supposed to be placed; the orig.tar.gz is meant to be unmodified from upstream - or at least, unchanging in the archive for any given upstream version
<doofy`> I can get everything to work with no errors... I just don't really understand what I'm doing and how its relevant to actually going through and fixing a bug. The documentation seems a little lacking in that aspect
<doofy`> i suppose if i keep working on it ill figure it out, just started today
<geser> doofy`: if you want to patch an existing package: "apt-get source pkgname" to get an unpacked source directory, make your changes, add a new changelog entry (with dch -i), debuild -S to get a new source package, debdiff old.dsc new.dsc to get a debdiff
<doofy`> then upload the debdiff to LP? that was MUCH easier to follow than the doc :) thank you
<cyberix> I'll get some sleep now. I'll look at the package again after I wake up. Please advocate, unless you find something to complain about. http://revu.tauware.de/details.py?package=malbolge
<cyberix> Oh, and good night for now
<dcordero> hi
<blueyed> Why does lintian complain "W: jedit: unknown-section universe/editors"?
<pochu> blueyed: it should be "editors"
<blueyed> pochu: thanks. But wasn't there something where you had to use "universe"?! I remember having to use section "universe/misc" or something similar for uploading to ppa.
<pochu> blueyed: for a ppa, but not for the archive :)
<pochu> blueyed: for ppa it's so it gets build-depends from universe or from whatever you specify in section
<pochu> blueyed: but for the archive the component is handled via overrides AFAIK.
<blueyed> pochu: I see.. thanks.
<blueyed> But that may be "fixed" now for ppa.. IIRC I have not adjusted my latest virtualbox-ose-modules upload for ppa..
<Fujitsu> blueyed: Correct, everything in PPA is now overridden to main.
<fmarier> I've got a question regarding the "package removal policy" when the package has not yet been removed from Debian.
<fmarier> I filed LP#175426 requesting the removal of "gengameng" in hardy since it is now superseded by flatzebra and has only ever been used by the burgerspace game.
<fmarier> unfortunately, i haven't been able to request the removal from Debian since the new burgerspace hasn't made it into testing.
<Fujitsu> Why does that stop you removing it from unstable?
<Fujitsu> Won't it stick around in testing until there are no rdepends?
<fmarier> Fujitsu: well, I'm not sure about that one and I'd rather not risk removing burgerspace entirely from Lenny...
<fmarier> I was thinking about subscribing ubuntu-archive to the bug to try to get it removed from hardy before it gets sorted out in Debian
<fmarier> according to LP#188292, it also fails to build from source, so I guess it wouldn't go into hardy anyways...
<blueyed> If you know (and like) jEdit, please review: http://revu.ubuntuwire.com/details.py?package=jedit :)
<bddebian> Heya gang
<ion_> Howdy-ho
<bddebian> Hello ion_
<ion_> Whatâs up?
<bddebian> Watching the SuperBowl, doing year end close for work and looking at some packages.  You? :-)
<ion_> Superbowl was baseball, right?
<ion_> Iâm just resting and watching some crappy TV show. :-)
<bddebian> No superbowl is the "real" football ;-P
<ion_> Ah, that. :-)
<ion_> I donât really know much about that sport, only that they guys are in clown suits and the game starts with one dude bending over, another sniffing his butt and the former throwing the ball to the latter.
<bddebian> haha
<RAOF> ...And that they stop the game for commercial breaks :P
<bddebian> A LOT :(
<RAOF> Or because someone dropped the ball.  Or because someone *caught* the ball, or... ;)
<ion_> Well, you can always fast-forward over the commercial breaks. And in my case, the sports, too. ;-)
<pwnguin> cant fast forward live tv
<ion_> Put it on pause, let your DVR cache it for Â½ hr, then come back and fast-forward over the ads. :-)
<protonchris> can't watch it at church either
<RAOF> I'm not sure a 1/2 hour buffer would be sufficient.
<doofy`> how does everyone analyze diffs once they are posted to LP? Is there programs that allow you to compare the changes?
<RAOF> I tend to use "less"
<ion_> A diff is already in a nice form to analyze. :-)
<ion_> If itâs an interdiff with -p0, then patch the diff with it and compare with interdiff -p1
<doofy`> the file is huge in this case :o but i suppose it was for a version update of brasero
<RAOF> You could filterdiff out anything that's not in debian/
<doofy`> would you suggest getting a mentor... I'd love to contribute to ubuntu and i'd like to get working as soon as i can
<RAOF> I didn't have a mentor, but I suppose it depends on how you work.  If you're happy to ask the whole channel questions you probably don't need a mentor.
<doofy`> i'd prefer to ask the channel questions :) so that answers it
<doofy`> RAOF, how long did it take you to actually be able to work on things dilligently?
<RAOF> Not too long, actually.  I started out by finding bugs in packages I wanted to use, finding that upstream had a patch that fixed it, and uploading debdiffs to LP.
<eddyMul> any advice to tell debuild to not package the emacs backup files (*~) ?
<RAOF> eddyMul: Remove them before debuilding? :)
<eddyMul> RAOF: I've been doing that. It gets boring after a while....   :p
<doofy`> RAOF, finding the bugs through launchpad or what?
<RAOF> doofy`: As in "oh, crap.  banshee appends a ", " to the end of all my files".
<RAOF> doofy`: Finding things that don't work like you want them to in software that *you* use.
<RAOF> Getting things that you care about to work is a lovely incentive :)
<doofy`> then you would just look for upstream versions of that software that had the necesarry modifications or would you actually do the coding?
<RAOF> The former; I'd look at the upstream bugzilla, and often someone else would have seen this and fixed it.
<RAOF> Or I'd report it to the upstream bugzilla, and someone would make a patch which I could then integrate into the Ubuntu package.
<doofy`> the people that are actually making the patches are the ones who work on specific projects usually, yes?
<RAOF> Indeed.  And I've done a little work that way, too.
<RAOF> (Banshee's cd-error-correction hookup code is mine, for example)
<doofy`> neat
<RAOF> It was pretty simple, actually, and did something that I wanted.
<RAOF> Hurrah for open-source!
<doofy`> im trying to figure out what im really interested in haha so i can figure out what to contribute to
<RAOF> Yup.  Start by working out what you're interested in :)
<doofy`> its amazing to me how all this stays organized
<ion_> When everyone keeps scratching her own itch, the whole keeps improving. :-)
<RAOF> The amazing power of theoretical capitalism :)
<bddebian> doofy`: It's far from organized (at least where upstream development is concerned)
<doofy`> in some ways i feel im better suited working on some upstream project
<bddebian> You can certainly do both :-)
<bddebian> Improve some upstreams build environment ;-)
<doofy`> work on an upstream project and submit those patches for ubuntu :)
<TheMuso> Would a MOTU be so kind as to give liblouis a look over? I'm the uploader, so one ack should be fine: http://revu.tauware.de/details.py?package=liblouis
<TheMuso> And in turn, I shall review packages, starting in a few minutes.
<RAOF> TheMuso: I'll take a look.
<TheMuso> RAOF: Thank you very much.
<TheMuso> brb
<RAOF> Why must licesing suck?
<TheMuso> RAOF: Yeah I know. I even asked upstream about this, and they said its all GPL v2.
<RAOF> Except for the exceptions and additional restriction, obviously.
<RAOF> Unless they're actually just meant to clarify things which are already implicit in the GPL.
<RAOF> (In which case it'd be nice for them to say that ;))
<TheMuso> Yeah.
<TheMuso> Well, Sun's lawyers have to check that its all ok, and the guy who made it work with autotools said the code is fine, but yeah I know, its something I'm not sure of
<TheMuso> A second opinion would be nice of course.
<RAOF> Is that what vcs-svn is meant to be used for?  I thought vcs-svn was for when the packaging was in svn?
<TheMuso> I don't know.
<TheMuso> Hrm maybe you're right.
<RAOF> I think that https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html supports my understanding, but it's not direct.
<TheMuso> Yeah, I'll pull it then.
<TheMuso> RAOF: If you aren't comfortable with the licesning, I understand. I don't like it much, but I'm told its GPL2, which is why I felt ok uploading it for review.
<TheMuso> c
<RAOF> Ugh?
<RAOF> :)
<RAOF> TheMuso: If Sun thinks its valid GPL, then I'm happy enough with that.  You can at least say you investigated it to the best of your ability if the archive-admins reject it :)
<TheMuso> Yeah I know
<TheMuso> I'll wait for a second opinion however, if one is forthcoming.
<firefly2442> why does pbuilder download packages? http://pastebin.ca/890856
<ion_> To satisfy dependencies
<firefly2442> so, it didn't create a .deb file, how do I know what to fix?
<firefly2442> I'm looking at another package as an example and I'm confused as to what I need to change
<imbrando1> sun is normaly pretty decient about lic concerns , if they say gplv2 i would trust it imho
<firefly2442> are there any more detailed instructions for packaging besides those on the wiki?
<vorian> firefly2442: http://www.debian.org/doc/maint-guide/
<TheMuso> imbrando1: Yeah I know. However, you should take a look at it, as there is an "all rights reserved" clause in the license.
<TheMuso> Hrm. ushare wasn't uploaded. Unless someone is doing that now, I'll do so.
<RAOF> TheMuso: Any checks I can run on the binary?  I'm not really sure what it's meant to do :)
<TheMuso> RAOF: What do you mean exactly? The binaries are only for testing the library.
<RAOF> I'll just pass on the binary-testing, then.  You presumably know that they work :)
<TheMuso> Yeah, I was running all of them to see if I could get docs outa them. Doing tests just to make sure they worked was part of it.
<LucidFox> Yay, got my first package into Debian
<TheMuso> LucidFox: Cool.
<RAOF> Hm.  Thinking of which, I wonder if StevenK would like to close an ITP for me :)
<LucidFox> StevenK is a DD?
<RAOF> Yup.
<imbrandon> LucidFox: correct ( as are alot of ubuntu devs )
<imbrandon> LucidFox: but i wouldent let him hear you accuse him of being a DD :)
<LucidFox> lol
<RAOF> TheMuso: Thinking of which, want to have another Sydney MOTU dinner sometime in the next couple of weeks?
<LucidFox> Well, I have another package on m.d.n needing sponsorship - I was wondering if he could help
<imbrandon> LucidFox: your better off mailing the mentors ml, StevenK rarely sponsors packages he isnt involved with
<imbrandon> but i cant speak for him, just givein you a heads up
<LucidFox> Ah
<ScottK> slangasek: lucas took care of the QA upload before I left for the Superbowl part I was at.  Thanks though.
<TheMuso> RAOF: Sure. You know there was one recently?
<TheMuso> I didn't attend, but there was oe.
<imbrandon> ScottK: pats lost :(
<ScottK> imbrandon: Aren't Boston and NYC pretty equidistant from KC?
 * imbrandon as a temp pats fan :)
 * ion_ misread that and thought imbrandon lost his pants.
<imbrandon> s/as/was
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<LucidFox> Hmm. Does it make sense to advocate a REVU package if the same software, but packaged by a different person, is waiting in Debian's NEW?
<LucidFox> (specifically talking about libgee)
<RAOF> Not really, IMO.
<RAOF> That's the second time that's happened recently, though.
<TheMuso> RAOF: But if you want to ask the others if they're interested, I'd be happy to make the trip down to attend.
<RAOF> We might want to suggest more strongly people submitting packages to revu file ITPs, too.
 * minghua wonders if the Debian NEW package has an ITP.
<RAOF> TheMuso: Cool.  I was in Perth for the last one, I now remember.
<LucidFox> yup, it does
<TheMuso> Where can one find out about how to submit an ITP? I intend to submit my package to Debian also.
<minghua> www.debian.org/wnpp I think
<TheMuso> And, if not a maintainer, should I use mentors to host it?
<RAOF> I use emacs' reportbug, myself.
<TheMuso> minghua: Thanks.
<LucidFox> http://www.debian.org/devel/wnpp/
<TheMuso> LucidFox: Thanks.
<minghua> Yeah, that's the correct link. :-P
<LucidFox> slomo, perhaps you could look at the diff between your libgee and the one on REVU, and merge them once it passes NEW?
<minghua> Emacs's reportbug was bad last time I knew it.
<LucidFox> I don't use Emacs or reportbug, I file all bugs by mail
<LucidFox> Does a Debian package need to pass NEW when moving from contrib to main?
<minghua> No AFAIK.
<minghua> You need a sourceful upload for contrib to main transition, unlike Ubuntu's main and universe.
<ScottK> You also need FTP masters to take some action on over-rides too, I believe.
<ScottK> or maybe that's just priority
<slangasek> yeah, I think it does end up in NEW in Debian
<minghua> Oh.  Sorry for the misinformation.
<richbl> hello all... I'm interested in doing some dev work, but specifically interested in user-interface design/development. Can someone recommend a good mailing list to join, or some pointers on where to go/who to contact? Thanks.
<RAOF> richbl: It sounds like you may be more interested in upstream development?  Most of the Ubuntu's interface comes straight from GNOME.
<richbl> RAOF: yeah, I've been tracking GNOME dev, and just got on their MLs... is there any UI work done here?
<RAOF> Although there certainly are Ubuntu-only projects; the installer (Ubiquity), displayconfig-gtk, those sort of things.
<ScottK2> Obsolete library removal bug filed.  Horray!
<richbl> RAOF: I'll take a look at those specifically. Is there a UI "lead" I should contact?
<richbl> (for Ubuntu, that is)
<RAOF> Not as far as I'm aware.
<RAOF> It's entirely possible that I just haven't been paying attention in the right places, though :)
<superm1> richbl, if you are interested in improving the UI of ubiquity, pop in #ubuntu-installer and you can talk to evand and cjwatson
<ScottK2> richbl: Do you have any interest in KDE?
<superm1> richbl, although there was a share of usability that was discussed at UDS this last october
<superm1> richbl, so there are pending changes
<richbl> ScottK2: that's a good question... personally, I'm more familiar with Gnome and have more of a history there... but I'd be interested in at least following up with folk(s) on the KDE side of things
<superm1> ScottK2, don't steal him!  he wanted to come to us first :)
<richbl> What's the process--in general--for handling UI consistency between us (dev) and designers (them) :)
<ScottK2> richbl: The reason why I ask is in Kubuntu we've got a no kidding U/I usability expert for KDE doing a fair amount of work with us and so there's actual studies that you can base work off of.
<richbl> For a quick background... I'm originally a dev from Microsoft (uh... I hope I don't get beaten)... did some dev/UI work on Flight Simulator a while ago (long long ago, it was Word 1.0)
<ScottK2> Back when Flight Simulator was cool.
<ScottK2> BTW, I wrote my college thesis with Word 1.0
<richbl> I was kinda' responsible for getting FS from char to Windows (at least a good portion of UI)
<richbl> ScottK2: cool... I still have an easter egg lurking in Winword 6.0 (pre-Office, IIFC)
<TheMuso> richbl: ooo nice.
<TheMuso> richbl: Nice to see you embracing the open source movement.
<ScottK2> I never used the pre-Office Word on Windows.  Only on Mac.
<richbl> Good to know there's someone on KDE who does UI/consistency stuff... anyone on the Gnome side that does similar?
<ScottK2> richbl: For KDE, there's some good linkage here: http://weblog.obso1337.org/2008/2007-kde-usability-reports/
<ScottK2> richbl: If that leads you to ideas, you can certainly join us on #kubuntu-devel.
<richbl> TheMuso: yeah... I still have friends at MS these days, but my personal feeling is that the company just got too big... and it lost the "campus" feel...
<TheMuso> richbl: For a start, GNOME has the GNOME interface guidelines, although thats not always looked upon favourably by Ubuntu devs.
<superm1> i may be mistaken, but I thought mpt did usability for GTK stuff?
<TheMuso> superm1: afaik he does.
<richbl> ScottK2: thanks, I'll check it out...
<superm1> yeah i remember he sat in on the installer usability session
<superm1> he also did a usability test on launchpad with me at UDS.
<TheMuso> superm1: same.
<richbl> Very cool that folks do usability testing... didn't know that... very cool.
<ScottK2> Yeah.  Of course he's an LP developer which means he's alsmost certainly unqualified for U/I design IMO.
<richbl> what's LP dev?
<superm1> https://edge.launchpad.net/~mpt
<ScottK2> Launchpad developer
<richbl> TheMuso: regarding the Gnome interface guidelines, any reason why they're not followed?
<ScottK2> Launchpad is Canonical's distribution management system
<richbl> Scott: gotcha... still getting my feet wet with tools
<ScottK2> Ubuntu (no suprise) uses it.
<ScottK2> Understand.
<richbl> every FOSS project seems to have their own way ;)
<ScottK2> Yes, well Launchpad isn't a FOSS project (just to be clear).
<RAOF> Which is part of what Launchpad is meant to solve.
<richbl> gotcha... I'll take a look and see... I think I've filed bugs through it... if that's the same tool for public bug filing...
<RAOF> And is what's given as the reason it's *not* open-source (yet, apparently).
<ScottK2> There are lots of reasons given, none of which make a lot of sense to me, but don't worry, I'm not going to do another 4 hour rant on LP should be Free.
<RAOF> Awwww!
<richbl> HA! I think I'll politely step around the issue for the moment...
<ScottK2> No problem.
 * ScottK2 wonders if it's a coincidence that LP is suddenly oopsing on me.
<richbl> So... to sum... I have some actions to follow-up on the Kubuntu side (another IRC channel) ... anything I can do for follow-up on the Gnome side?
<richbl> (pardon me if I've missed anything in the scroll)
<superm1> richbl, i'd say you should try to talk to mpt if you get a chance
<superm1> he can point you in the right direction
<richbl> ah yes... got his page up now
<richbl> thanks
<superm1> best of luck
<RAOF> Please polish my favourite GNOME :)
<richbl> TheMuso, if you're still around... you had mentioned that the Gnome interface guide really doesn't seem to get followed... can you elaborate please? Is it a bad guide, or else?
<ScottK2> RAOF: Are you familiar with the mesa library packages?
<ScottK2> tonyyarusso: Are you around?
<RAOF> ScottK2: I've played with building nouveau's DRI?  I'm not particularly familiar with the packaging, though.
<ScottK2> OK.  I'm trying to understand some transitions to figure out what to do with a merge.
<ScottK2> I'm gonna ask anyway.  Maybe I'll get lucky
<RAOF> Heh.
<ScottK2> xlibmesa-gl-dev xlibmesa-gl xlibmesa-glu are Sarge -> Etch transitional packages, but they don't appear in Ubuntu until Edgy.
<ScottK2> So I was hoping you'd know if we need to keep depends on those for Hardy or not.  It doesn't seem to me that it'd help Dapper - Hardy.
<ScottK2> But I've really no idea.
<RAOF> I don't know either, sorry.
<ScottK2> OK.
<ScottK2> Maybe someone else ...
<RAOF> I've only really been playing around with mesa in Gutsy/Hardy.
<tonyyarusso> ScottK2: I am.
<ScottK2> tonyyarusso: I noticed the other day that kompozer is in the top 20 packages not in Debian by popcon.
<ScottK2> I think it you modified your package for Debian, you'd have an easy time getting sponsored.
<tonyyarusso> ScottK2: Yeah, the "be a good citizen and contribute back to Debian" thing has been smoldering on the to-do list for a long time.  However, since Debian doesn't have as stringent of deadlines to worry about, my personal life is super busy, and I want to make sure I do my research well enough to make sure I do it "the right way", I've been putting it off so far.
<tonyyarusso> ScottK2: However, last spring I did talk with asac and Kaze, and I think we were able to get most if not all non-dfsg stuff removed from it already, so that helps.
<RAOF> tonyyarusso: While you're here, I don't suppose you follow the gstreamer-devel ML?  Slomo (I think) has just posted a tempo/bpm-finding plugin to it, a week ago or so.
<ScottK2> tonyyarusso: Debian is getting close to their first soft freeze for the next release, so it's be really good to do it sooner rather than later.
<tonyyarusso> ScottK2: Can you provide me a date offhand?
<tonyyarusso> RAOF: I don't, although I may have to go check out the archives after today to look for that.  Any idea what stage it was at?
<RAOF> tonyyarusso: Checked in to cvs & pretty much ready to roll, I think.  I'll check my backlog.
<tonyyarusso> RAOF: cool!
<ScottK2> tonyyarusso: Full freeze is sched in July, but things start getting frosty in March.
<tonyyarusso> ScottK2: All right - I have two days off in February, a week in March, and my hecticness-index will drop by about half in early June, so I'll see what I can do.
<RAOF> tonyyarusso: Yup.  Checked in to gst-plugins-bad cvs, as of the 27th.  As well as a commit to gstpitch, which may make gstreamer a one-stop shop for you :)
<tonyyarusso> meanwhile, looking at Thunderbird, Wireshark, and Claws to see how I should do the transition for Dapper upgraders
<tonyyarusso> RAOF: Wow - and with that it could actually be scripted on a command line I would think, right?
<RAOF> gst-launch is a fine tool, if you don't need the abilities that python-gstreamer gives you :)
<ScottK2> tonyyarusso: The Claws one is done properly.  I haven't looked at the rest.
<ScottK2> Good night all.  I'm off to bed.
<Aloha> ScottK, night
<tonyyarusso> It seems odd to me that the transition packages have a Depends to pull in the new one, but nothing to actually get rid of the obsolete package other than a not in the description saying "this can be removed afterwards", but they all seem to do it the same way, so I guess I won't argue too much...
<tonyyarusso> Policy check: Are we trying to have "Ubuntu MOTU Developers" listed as the maintainer of everything in universe?
<StevenK> Not everything.
<StevenK> Everything that has Ubuntu changes
<minghua> tonyyarusso: If you have a better idea to handle transition packages, by all means let everyone know.
<minghua> I think binary packages compiled from directly imported Debian packages also have "Maintainers" field changed these days?
<tonyyarusso> minghua: I'm not sure of the inner workings of the different keywords (Replaces, Conflicts, etc.) - would any of them do something reasonable?  If not, how come nobody's implemented a keyword for this yet?  (it seems to come up a lot)
<tonyyarusso> StevenK: So if it is a package that is NOT in Debian at all (yet), and thus has a 0ubuntuX version naming, would that fall into that category or not?
<minghua> tonyyarusso: What function are you proposing a keyword for?  "This package makes package foo obsolete, so you can remove foo after you install this one"?
<minghua> tonyyarusso: Not important and frequent enough to worth a keyword, IMHO.
<tonyyarusso> minghua: yeah, such that it would automatically remove foo after a successful installation of the replacement.
<tonyyarusso> minghua: fair enough - I don't really know how often it is; just seemed like someone might have tried it for elegance.
<minghua> The "automatically installed" feature already implemented should solve part of this problem anyway.
<tonyyarusso> Doh.  I'm going to have to submit one of the most trivial bug reports known to mankind.  I just noticed a typo in a Tracker applet notice.
<LucidFox> "Conflicts: foo" means "This package will not install if foo is installed"
<LucidFox> "Replaces: foo" means "foo will be automatically uninstalled prior to installing this"
<RAOF> LucidFox: That's not true?  Replaces: means "dpkg will not complain when I overwrite files owned by that package"?
<tonyyarusso> Replaces sounds close, but I'd think it would want to be a "wait and make sure this one installs okay first, then uninstall it" kind of thing.
<LucidFox> RAOF, tonyyarusso> Makes sense.
<minghua> LucidFox: Not true for Conflicts as well.
<LucidFox> So replaces means "Ignore errors about existing files owned by foo, and uninstall foo after this package is installed"?
<RAOF> Yes to the first, no to the second.  Both packages will be installed, but the files in both packages will now be owned by the most-recently-installed package.
<minghua> You can have versioned Replaces, which makes moving files between packages possible.
<LucidFox> RAOF> Ah.
<LucidFox> but if both conflicts and replaces are present, the old package _will_ be uninstalled, right?
<RAOF> Yes.
<ScottK2> If two packages provide the same file (no matter the version) in the same namespace, then they either need to conflict or use update-alternatives.
<soren> Or "Replaces"
<soren> ScottK2: ^
<tonyyarusso> ScottK2: btw, where are you getting the data for this "top 20" thing?  I'm not sure where to look.
<LucidFox> Are Qt4 packages under GPLv3+ allowed?
<LucidFox> (I know that Qt3 is)
<warp10> Good morning
<LucidFox> Hello, warp10
<soren> ScottK2: And update-alternatives doesn't fix the namespace issue on its own. Both packages need to provide a differently named file and update-alternatives provides the mechanism for one of them to obtain the "conflicting" name.
<warp10> heya LucidFox!
<soren> ScottK2: Maybe you're thinking of dpkg-divert?
<tonyyarusso> Oh yeah, that was the other thing I needed to learn.  How to do changes as a debdiff instead of the whole thing, or however that works.
<mikemorrison> hello all. i'm trying to get my program into ubuntu (multiverse perhaps?) but i'm not exactly sure on the procedure .. i've followed the instructions and even tried to upload it to revu(i don't think it worked). now i'm not sure what i'm supposed to do next. can anyone steer me in the right direction?
<LucidFox> mikemorrison> Did you join the Ubuntu contributors team?
<LucidFox> mikemorrison> If you did, ask a REVU admin to sync the keyring - after that, you will be able to upload to REVU
<ScottK2> soren: Yes.  That's true.
<ScottK2> tonyyarusso: There was some wnpp discussion on (I think) debian-devel ML where it came up recently.
<tonyyarusso> Hmm, I know normally debian/changelog has something like (LP: #180382) after each thing, but I have a bug that was marked as "Fix Released" by a previous version, but this version addresses a concern brought up later in a comment on the old bug.  Should I still reference the bug in the changelog?
<tonyyarusso> ScottK2: presumably there's a fair bit lurking in packaging documentation as well?
<tonyyarusso> doh
<tonyyarusso> nvm me, I can't keep my different questions straight.  ty.
<ScottK2> soren: I was thinking of alternatives as a way to work around the namespace collision is a softer way than conflicts.
<soren> ScottK2: Indeed.
<ScottK2> is/in
<ScottK2> tonyyarusso: If you aren't fixing the bug that was filed, then I wouldn't mention the bug in the changelog.
<mikemorrison> LucidFox: yes, i joined in december. i was able to upload to revu, but the package never showed up.
 * ScottK2 really going to bed now.
<LucidFox> mikemorrison> Did you upload the changes file?
<LucidFox> And was it a source package that you were trying to upload?
<mikemorrison> yeah it was a changes files, but it was binary only deb.
<techno_freak> the diff file says "+    - zoom in/out support (xine-lib)." what is the package for the xine-lib?
<Fujitsu> mikemorrison: It needs to be a _source.changes.
<mikemorrison> well, i haven't released the source code for my program. so how do i get a binary only package uploaded? or is that not possible? i thought that is what multiverse was for...
<ScottK2> As a rule it's for source packages that have limitations on distribution or modification that preclude Universe.
<ScottK2> Additionally, I doubt many MOTUs are going to be interested in expending effort on getting binary only packages into the archive.
<ScottK2> So even if it's legal, it's not easy.
 * ScottK2 really really going to bed.  Good night again.
<mikemorrison> ScottK2: thanks for the info.. gnight
<LucidFox> mikemorrison> Why don't you release the source?
<mikemorrison> among other reasons, i haven't decided on a license yet, and the code currently isn't really in a state that i wish to make available.
 * tonyyarusso never likes that reason
<tonyyarusso> Isn't that exactly why it would help to make it available?
<RAOF> Also, why would it be good enough to be in the Ubuntu archives if the code isn't good enough to release?
<mikemorrison> haha.. i certainly don't mean the code is bad or anything.. i just mean i don't have comments and the coding style isn't necessarily consistent throughout
<minghua> Yeah, RAOF's seems to be the most important question to me.
 * Fujitsu doesn't think we really want to distribute closed, never before heard of software to our poor users.
<dholbach> good morning
<Fujitsu> Hey dholbach.
<warp10> heya dholbach
<dholbach> hey Fujitsu
<dholbach> heya warp10
<dholbach> how's it going?
<cyberix> Good morning.
<dholbach> heya cyberix
<Fujitsu> Not bad, dholbach. Yourself?
<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
<dholbach> very good :)
<mikemorrison> Fujitsu: haha.. yeah i see your point. i've released my program for the maemo platform(nokia n800/n810) and after going through that procedure i just thought it would be neat to have in ubuntu as well.
<cyberix> mikemorrison: You are right. Multiverse is for binary only packages.
<Fujitsu> Not just for binary-only packages.
<cyberix> Well
<RAOF> cyberix: Not entirely.  Mplayer is (or was) in multiverse.
<minghua> I would even bet on that multiverse contains more source-available packages than binary-only one.
<cyberix> No, but "binary only packages" should go into Multiverse.
<Aloha> who puts packages in multiverse? MOTU?
<Fujitsu> Well, they shouldn't really go into multiverse, but that's the best place they can go within Ubuntu.
<minghua> Aloha: Yes, MOTU are responsible for both universe and multiverse.
<Aloha> minghua, thnx
<cyberix> mikemorrison: The problem is that you need two MOTUs to advocate your package and MOTUs are not really willing to work on such packages as they do not appreciate them.
<superm1> cyberix, i don't know that you can speak for everyone on that
<cyberix> mikemorrison: So you need to have powerfull friends as MOTUs or get some powerfull friends from among MOTUs.
<LucidFox> mikemorrison> Don't be ashamed of the code
<cyberix> mikemorrison: On the other hand it will be a lot easier to add those comments to the source, or to just post the source with lacking comments.
<LucidFox> You won't believe how many free software has _really_ bad code
<LucidFox> s/many/much
<cyberix> superm1: I'm talking about my own experience about trying to get a binary package into Ubuntu.
<LucidFox> and yet its developers don't hesitate to open it - even if they can't prettify it, others will
<superm1> cyberix, i believe it really depends on the type of binary package
<superm1> take for example alsa-firmware
<superm1> that will be multiverse destined
<superm1> and we were able to push it in and out of revu within today
<cyberix> Yes, if it seems important you may earn diplomacy points.
<cyberix> I suppose this is not the case.
<superm1> on the other hand packaging say a windows executable that is wrapped around a wine launcher, that's less likely to gain acceptance after the previous fiasco
<cyberix> On the other hands I did manage to get two advocates for a packaged windows binary, while my current public domain, unix software doesn't seem to get any advocay.
<superm1> ah that was you :)
<minghua> Well, it's hard to appreciate binary-only packages, as there needs to be other incentives.  But a blanket statement of "MOTUs are not really willing to work on such packages as they do not appreciate them" is too much IMO.
<LucidFox> mikemorrison> As for the license, we can help you choose one, depending on what you want others to be able to do with your code
 * Fujitsu wasn't amused with pq.
<LucidFox> it's not really that important what license you choose, as long as it's free - as the copyright holder, you can always relicense it
<LucidFox> or double-license
<cyberix> GPLv3 would be the most restrictive?
<minghua> There was a thread on debian-devel about the highest popcon rank packages that are not in the archive, which is an interesting read.  It would be nice if we can view binary-only packages for Ubuntu in a similar way.
<Fujitsu> minghua: Someone would have to go through and work out which multiverse packages are binary-only...
<minghua> cyberix: I'd suggest you read the license or talk with someone who understands them before choosing one, instead of asking such general questions.
<minghua> Fujitsu: Yeah.  What I really meant, though, it that we should have some policy of "no binary-only packages unless there is evidence of a significant user base".
<dholbach> WOW, we've had some busy reviewers
<Fujitsu> The official multiverse policy is anything that's distributable, I believe.
<superm1> dholbach, you missed a fun revu day :)
 * dholbach adds all the NEW packages to http://wiki.ubuntu.com/MOTU/ReportingPage
<minghua> Fujitsu: Right.  What about s/policy/recommendation/?
<Fujitsu> minghua: We don't have one, I don't think.
<minghua> It would be my personal criterion, regardless.  Not that I do much REVU review, of course.
<mikemorrison> yeah i am going to spend some time reading up on the licenses ... i already know gpl2/3 fairly well but i'd like to read up on others before i make my decision.
<superm1> TheMuso, don't forget to upload liblouis.  I didn't see it in NEW yet.
<LucidFox> mikemorrison> Whichever license you pick, I'd recommend it to at least be GPL compatible. This rules out CDDL, Creative Commons, and the original BSD (revised BSD is fine).
<mikemorrison> LucidFox: is that so contributors can incorporate gpl code into it?
<mikemorrison> if any of you wanna try my program out, it's here: http://mike.yi.org/projects/quiver
<LucidFox> mikemorrison> So that others can use your code in GPL projects
<RAOF> Hm.  Before I finish this crazy multiarch hack, who here thinks that rewriting the pkgconfig files for some dependencies during the build process is too evil to upload?
<Fujitsu> Modiying other packages' files? That sounds quite bad.
<RAOF> But only in the build environment, and only to temporary copies.
<RAOF> But it is indeed bad.
<minghua> Still sounds VERY bad to me.
<RAOF> Alternatively, ia32-libs-dev could exist and ship pkgconfig files.
<RAOF> Hm.  Or, now that I think of it, I could do a wine and create the symlinks myself...
<mok0> ScottK2: are you awake?
<RAOF> I'd still need to copy pkgconfig files to some temporary build directory, but I wouldn't have to feed them through sed first.
<RAOF> I'll give that a whirl.
<Fujitsu> mok0: He went to bed some time ago.
<mok0> Fujitsu: I thought he might have :-)
<rulus> I'd like to have a review of gtkvd (http://revu.ubuntuwire.com/details.py?package=gtkvd) please. Thanks :)
<TheMuso> superm1: I was hoping for a second opinion on the licesning.
<DaveMorris> what happens to the packages which have been upload to revu, need fixing yet haven't been touched for months?
<Fujitsu> DaveMorris: The sit around and rot.
<Fujitsu> *They
<Fujitsu> And generally clutter things.
<DaveMorris> would it be wrong to encourage people to finish them off (ie not the people who have abandoned them), since there are always hope-fulls who ask "is there a program I can package?"
<isaac> uhm, what distribution should I put in debian/changelog for uploads?
<Fujitsu> isaac: hardy
<isaac> ok, lintian complaints about that
<Fujitsu> Please get an updated lintian from <yourrelease>-backports.
<isaac> ok
<isaac> but I am using hardy
<isaac> shouldn't it have an up-to-date lintian?
<Fujitsu> Hmm.
<isaac> and the lintian in REVU complained too
<slicer> I saw my package got uploaded from revu (yaaaay!!!). Is there another step that needs to be done before I can tell people to 'aptitude install mumble'?
<DaveMorris> isaac: what package?
<siretart> slicer: you need to find someone to look at your package and upload it to ubuntu. revu is just a platform to present your package to potential sponsors
<slicer> siretart: I know :) I've been through revu, got two adovocations, and the last one said "uploading".
<isaac> DaveMorris: unblock-signals
<TheMuso> c
<TheMuso> wrong tab
<persia> superm1: REVU day isn't even half-over yet (although it will be in about 17 minutes).
<persia> DaveMorris: Packages that haven't had a comment or upload in about 3 months get archived.  The rest sit and rot.  If you want one, feel free to poke the previous packager, and take over if they don't mind or don't respond.  Note that there will be a quiet period until the next release.
<persia> slicer: Once a package has been uploaded to the NEW queue, it requires the attention of an archive-admin.  There aren't very many archive admins, and they are busy, so this can take quite a while.  If you know there is a bug that needs fixing, prep your changes to apply as soon as the package is accepted into the archive.
<mok0> The number of packages in REVU is astonishing
<persia> mok0: In total, or awaiting review?
<mok0> persia: ... well, both ;-)
<TheMuso> persia: I'd like your opinion on the licesning of liblouis, which is on REVU. RAOF gave it the ok, but I'm still not 100% sure, although upstream said it is fine.
<mok0> persia: I counted 47 awaiting review some time ago
<dholbach> http://wiki.ubuntu.com/MOTU/ReportingPage looks really busy this time :)
<persia> dholbach: Is it just you who updates that?  Perhaps we need to get people from each of the MOTU teams to write up a snippet.  (e.g. Science, Java, Python, Games, QA, REVU, etc.)
<dholbach> persia: I announced it a couple of times, but up until now it was mostly me who edited it
<persia> mok0: That's an improvement over 24 hours ago :)
<dholbach> I'd appreciate more people adding their news items to it - the MOTU team has a lot of stories to tell
 * persia plots and schemes to determine how to get more updates
<slicer> persia: Ah, thanks. Is there somewhere I can track it's progress in the new queue?
<persia> slicer: https://launchpad.net/ubuntu/hardy/+queue
<LucidFox> beat me to it :)
<slicer> Thanks again :)
<persia> LucidFox: OK.  You get the next three :)
 * mok0 is impressed at persia's keyboarding skills...
<mok0> ubotu, ! queue
<ubotu> Sorry, I don't know anything about queue - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<mok0> ubotu, ignorant as usual
<LucidFox> !queue is The Ubuntu NEW queue can be found at https://launchpad.net/ubuntu/hardy/+queue
<mok0> ubotu, ! queue
<ubotu> Sorry, I don't know anything about queue - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<mok0> ubotu: Lucidfox just told you!
<persia> mok0: It takes a while for the bot wranglers to moderate new knowledge.
<mok0> persia: I know, just teasing him
<LucidFox> heh
<slytherin> persia: Do you have any update on w3c-dtd-xhtml issue?
<persia> slytherin: No.  Did I say I was chasing that?  I thought you were uploading a fix to Ubuntu.
<slytherin> persia: What I meant to ask was if man-di_ gave any update on this. Sorry for confusion. I think now i should fix it in Ubuntu itself.
<persia> slytherin: Better to ping him directly, but you might want to check the status of the relevant Debian packages from packages.qa.debian.org first.
<slytherin> persia: No change in the package. Also the bug has no comments added in past week. I will ping man-di_, but I will also ready the fix for Ubuntu
<smarter> Hi everybody
<slytherin> smarter: hi
<smarter> I've updated my kepas(kde4 plasma applet) and extremetuxracer(3D course game) packages, could someone please review them? ;) http://revu.ubuntuwire.com/details.py?package=extremetuxracer and http://revu.ubuntuwire.com/details.py?package=kepas thanks!
<smarter> (I'm currently uploading the extremetuxracer package)
<LucidFox> smarter> compat 6?
<LucidFox> oh, debhelper 6 is out
<geser> LucidFox: yes, and also already in hardy
<LucidFox> yes, I see now :)
<laga> KGJ|will_nen_eee: buy one
<KGJ|will_nen_eee> hrhr
<KGJ|will_nen_eee> laga: cant get one. out of stock. next next shipment in <
<KGJ|will_nen_eee> >1 months
<slytherin> What does this condition mean found in postinst, if [ ! -s /usr/share/sgml/html/entities/xhtml ]; then
<laga> KGJ|will_nen_eee: local stores might have one. our promarkt does, iirc
<persia> slytherin: -s means "exists and has size of more than 0 bytes",  ! means not.
<slytherin> persia: thanks
<persia> slytherin: man test will give you further information on [] tests
<slytherin> Changes to postinst should show up in debdiff, right?
<persia> slytherin: Yes.
<Coper> Can someone review my new package http://revu.ubuntuwire.com/details.py?package=console-freecell
<TheMuso> Good night folks.
<LucidFox> Coper> commented
<Coper> LucidFox: okej, will check after work. :) is my mv from usr/bin to usr/games correct?
<LucidFox> I assume so
<LucidFox> oh, wait!
<LucidFox> then debian/dirs _is_ needed
<LucidFox> disregard that comment
<persia> TheMuso: Good night.  I've left a comment on liblouis for you in the morning.  I'm not sure it's DFSG-free :(
<rexbron> Can someone take a look at OpenLibraries and openFX? http://revu.ubuntuwire.com/details.py?package=openlibraries http://revu.ubuntuwire.com/details.py?package=openfx
<persia> vemon: I was just looking at whysynth on REVU, and noticed it didn't have the patches.  I thought upstream got back to you on that.
 * Hobbsee waves
<effie_jayx> Morning all
<effie_jayx> hey Hobbsee
<Hobbsee> hiya effie_jayx!
<Hobbsee> fixed the world yet?
<effie_jayx> heheheh I am into fixing something today :D I have time to kill
<persia> effie_jayx: Have you already picked something out?
<effie_jayx> per I am trying to find something by myselft
<effie_jayx> persia,  I got some suggestions on a package update I tried months ago
<persia> effie_jayx: OK.  Good luck.  If you want to work on the last remaining bug on the package you touched recently, I'll owe Hobbsee less :)
<effie_jayx> persia,  the sound one?
<Hobbsee> heh
<persia> effie_jayx: I was thinking of the sound one, but if you've a pending update, it's better to look at that, because of the impending freeze.
<Hobbsee> persia: you still owe bugfixes to all the bugs in the archive :)
<effie_jayx> persia,  right...
<persia> Hobbsee: Nah.  I only owe you fixes for MIDI and game sound.  The rest are available for anyone to help with.
<Hobbsee> persia: that can cahgne :)
<cyberixae> persia: Going to advocate malbolge?
<cyberixae> persia: Maybe someone else would take a look, if it already had one advocate.
<persia> cyberixae: No.  I don't think it is a service to malbolge users to have it packaged.  It simplifies things too much, and the frustration of not being able to use it once installed doesn't quite make up for that.
 * Hobbsee wonders what it is
<persia> cyberixae: On the other hand, the packaging looks fine.
<cyberixae> Hobbsee: Interpreter for an esoteric research programming language.
<Hobbsee> ahhh
<persia> Hobbsee: a programming language designed to be difficult to use.
<Hobbsee> heh
<cyberixae> The point is not that it should be difficult to setup.
<persia> http://revu.ubuntuwire.com/revu1-incoming/malbolge-0801211640/malbolge-0.1.1/malbolge.txt is fun reading
<cyberixae> I packaged it because I wanted to apt it to try out some programs written in malbolge.
<cyberixae> And I think other people have done that too.
<persia> cyberixae: Is the file wrong then?  I thought "So far, no Malbolge programs have been written.  Thus, we cannot give an example." was accurate.  If there are actual programs, it should be updated.
<cyberixae> There are
<cyberixae> But that is the original text file
<cyberixae> I don't think it should be modified
<Hobbsee> persia: that guy is sick.  and the file was written in 98
<cyberixae> Just like research papers are not modified
<persia> LucidFox: Did you come to a determination on libgee?  Should it be included, or pulled from Debian?
<persia> Hobbsee: Yes.
 * broonie notes that Ubuntu includes two INTERCAL implementations.
<cyberixae> The file does mention that it has been written in 98
<persia> cyberixae: In that case, I'd recommend adding a debian/README.Debian with updates.
<Hobbsee> persia: if, God forbid, anyone wishes to write in that, then they deserve to go to the depths of hell.  actually, they wouldn't be running ubutnu anwyay
<Hobbsee> i can see the case where an ubuntu user wants to use a crack compiler to run a crack-filled app, written in it, though
<cyberixae> persia: What would README.Debian then contain?
<persia> Hobbsee: Perhaps you'd like to review it then?
 * Fujitsu wonders when libgtk2-malbolge will appear.
<laga> Fujitsu: lmao
<persia> cyberixae: Information about the current state, and documentation of the inaccuracies of malbolge.txt that have developed over the past 10 years.
<Hobbsee> persia: i could just do a [23:22] <persia> cyberixae: On the other hand, the packaging looks fine. <ack>
<cyberixae> Fujitsu: How about a malbolge interpreter written in malbolge?
<cyberixae> :-P
<persia> Hobbsee: If you did that, I'd have to add a rejection comment based on the philosophy, and I've already promised I wouldn't without provocation.
<slytherin> Does anyone know why update-maintainer script adds ubuntu-devel-discuss@lists.ubuntu.com when the package is in main. Shouldn't it be ubuntu-devel@lists.ubuntu.com
<Hobbsee> heh
<persia> slytherin: Posting to ubuntu-devel is restricted, so it points to a list that can actually receive mail.
<Hobbsee> persia: it's not that
<LucidFox> persia> I'd discuss the libgee issue with slomo
<Hobbsee> slytherin: see the audiences between u-d-d and u-d
<Hobbsee> [23:22] <persia> cyberixae: On the other hand, the packaging looks fine.
<LucidFox> since he uploaded the Debian package
<persia> LucidFox: OK.  I'll ignore the package then.  It was just on my list as you'd indicated it needed attention before.
<Hobbsee> # https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
<Hobbsee> # https://wiki.ubuntu.com/UbuntuDevelModeration
<effie_jayx> persia,  if there is a freeze ... I think there is no good reason for justifying that update
<Hobbsee> that one
<effie_jayx> I could do it for the sport
<slytherin> persia: Hobbsee: Ok, thanks for info.
<persia> effie_jayx: If there's no good reason to include it for hardy, no real point now.  Next cycle maybe.
<effie_jayx> persia,  yes, definetely ... I am fechting for another bug... any suggestions?
<persia> effie_jayx: There's about 800 patches out there that need review and packaging into debdiffs.  Be nice to evaluate them, and either remove the patch flag and leave a comment explaining why the patch doesn't fix the bug or wrap them in a debdiff and submit to the sponsors queue.
<persia> effie_jayx: There's a couple links to useful searches for those from http://qa.ubuntuwire.com/
<slytherin> persia: Can you please check if this debdiff for w3c-dtd-xhtml looks fine? http://paste.ubuntu.com/4163/ Please note that package is in main.
<effie_jayx> persia,  let me try some
<Hobbsee> effie_jayx: fix rbot :)
<effie_jayx> Hobbsee,  rbot?
<persia> slytherin: Looks relatively sane to me, but I'm not very familiar with that package, nor the rdepends.
<Hobbsee> effie_jayx: it's uninstallable due to ruby - there's a few others as well
<Hobbsee> effie_jayx: it needs ruby 1.8 to build, not 1.9, and debian's screwed with it's numbering.
<slytherin> persia: I am just adding symlinks, so rdepends should not be affected.
<Coper> LucidFox: was there no more comments on my package?
<effie_jayx> Hobbsee,  bug link?
<Hobbsee> effie_jayx: no idea if tehre is one
<persia> slytherin: I'll agree with *should*, but I'm not qualified to be sure :)
 * Hobbsee just noticed it become uninstallable, and checked why
<slytherin> persia: Ok. I will attach the debdiff and let core devels decide that.
<cyberixae> README.Debian or README.debian?
<persia> D
<effie_jayx> Hobbsee,  is that the only reason?
<LucidFox> Coper> No, I have no other objections
<Hobbsee> effie_jayx: i think so
 * Hobbsee wonders where her chocolate went
<slytherin> persia: Done. Now if it gets accepted within a day we can fix lucene2 by Wednesday.
<persia> slytherin: Excellent.  I look forward to that.  Please update the lucene2 bug indicating that progress is underway.
<slytherin> sure
<geser> Hobbsee: LP ate it :)
<Hobbsee> that's be right.
<effie_jayx> Hobbsee,  Depends: ruby (>= 1.8), ruby (<< 1.9),
<Hobbsee> effie_jayx: yeah.  which did work, till debian decided to use strange numbering.
<Hobbsee> they say why in their bug - but it's still odd.
<Hobbsee> because nwo it doesn't correspond to the actual version of ruby
<persia> shibata: poppler-data commented.  Please update: it'd be great to get this in hardy.
<shibata> persia: thank you.
<effie_jayx> persia,  I was looking at some bugs.. and some don't even have a patch... they just point to were the new upstream release is...
<persia> effie_jayx: Sometimes the upstream bug has a patch, or a pointer to the commit that fixed the problem.  If it is labeled "patch", and you can't find a fix from the information provided, remove the "patch" information, and leave a comment explaining why.  If you aren't sure, feel free to share your research in this channel to get a second opinion.
<effie_jayx> persia,  well I saw this one https://bugs.launchpad.net/ubuntu/+source/kipina/+bug/95842.. I am unsure of what I have to do... they is no patch for me to apply and test
<ubotu> Launchpad bug 95842 in kipina "kipina crashes on launch" [Undecided,Confirmed]
<persia> shibata: Just a few notes on kita2: that one looks a lot better.  Thanks for digging that up, and pushing it.
<slytherin> persia: Should I log a tracker bug for 'Phase out sun-java5-* packages'. I received no reply to my mail on MOTU list.
<effie_jayx> Hobbsee,  the fix would be to just depend on the 1.8 version only
<Hobbsee> effie_jayx: yeah, i suspect so
<persia> slytherin: Sure.  Listing the affected packages would make sense.  Also, you might try poking doko to get another opinion.
<Hobbsee> in which case, they just all need changing to it
<effie_jayx> Hobbsee,  the guy must have a pretty good reason for having that there. but he is not responding
<persia> effie_jayx: I don't see a patch there, and don't think it deserves the "patch" tag.  On the other hand, it might benefit from the "upgrade" tag, if kipina still needs to go to 0.2 (or newer), and it might be a good place for you to test your upgrade skills (although that's a feisty bug, so the package may have been updated, in which case the bug can be closed)
<Hobbsee> effie_jayx: what do you mean?
<effie_jayx> Hobbsee,  the package maintainer in debian, he is not responding ... he has duplicate bugs and no reply
<effie_jayx> persia,  it's like the fifth but I check and it is the same
<doko> slytherin: no, please let them stay
<Hobbsee> effie_jayx: ah yes, right
<cyberixae> persia: I cannot reach my GPG key right now. So, I have to get home to perform an uplaod. Does this -Ã> http://www.cs.helsinki.fi/u/twruottu/README.Debian <- look ok?
<persia> effie_jayx: That's frustrating.  On the other hand, triaging the list to find a good bug is a huge help for everyone.  I'm sure you'll find one soon.  Note that using the other "patch" search on the qa site will result in a completely different set of false positives.
<slytherin> doko: Do you have any specific reason in mind?
<doko> slytherin: did you test that all applications run using sun-java6 that did run with sun-java5?
<persia> cyberixae: Looks good to me.  Note that often README.Debian contains a signature string at the bottom in a similar format to a changelog entry.
<cyberixae> k
<mok0> can someone help me take care of #188093 ?
<slytherin> doko: No. That is the reason I will first work on getting those packages built and run with java6. And when we don't have any hard coded 'Build-Depends' or 'Depends' and java5 packages we can remove them.
<mok0> bug 188093
<ubotu> Launchpad bug 188093 in xtide-data "[needs-sync] xtide-data-20070318-1 from sid" [Undecided,New] https://launchpad.net/bugs/188093
<effie_jayx> persia,  I'll change that bug to update then
<doko> slytherin: I disagree. it's not just the packages in the archive
<persia> effie_jayx: May as well update it while you're at it.  FeatureFreeze is soon, and it's easier to do now than once the freeze hits.
<effie_jayx> persia,  I can give it a shot and see
<persia> effie_jayx: Good luck.  You've successfully found your own bug to fix :)
<effie_jayx> jajjaajajaja
<slytherin> doko: What about kaffe? Do you think it is redundant?
<yamal> MOTUs, please review http://revu.tauware.de/details.py?package=sabnzbdplus - looking for a second advocate. thanks
<isaac> looking for advocates for: http://revu.tauware.de/details.py?package=unblock-signals
<LucidFox> slomo_> persia wondered about the libgee package: there is your version in Debian's NEW, and there is another version on REVU
<doko> slytherin: do you think that KDE is redundant because we have Gnome? do you want it blacklist for syncing from debian? do you want to regularily merge packages which b-d on kaffe?
<slomo_> LucidFox: different... mine is the one from pkg-vala's git
<slomo_> http://git.debian.org/?p=pkg-vala/libgee.git;a=summary
<LucidFox> Do you think Ubuntu should wait until it passes and then sync, or accept the one on REVU?
<slomo_> LucidFox: either wait or take the version from git
<slomo_> otherwise conflicts will probably appear
<slomo_> bbl
<pochu> LucidFox: you can upload the version from NEW with a ~hardy1 suffix, and sync it once it's new'ed
<DaveMorris> isaac: reviewed for you
<isaac> DaveMorris: it's a native package
<isaac> DaveMorris: I mean, I did it on purpose
<DaveMorris> isaac: why can it only be used on Ubuntu?
<shibata> persia: I uploaded poppler-data.ãBut I could not understand 4). Should I write "This package is in multiverse." somewhere?
<isaac> DaveMorris: well, i definitely can be used wherever
<isaac> DaveMorris: but the only use I see for it is the one I intended for
<isaac> DaveMorris: we need to workaround a bug in gconf2
<DaveMorris> which is?
<isaac> DaveMorris: eBox, the server configuration web frontend
<isaac> that we are trying to get in for Hardy
<isaac> uses apache2 and gconf as configuration backend
<isaac> there is a problem in gconf that is only trigerred when it's launched from apache2
<isaac> because apache2 blocks some signals
<isaac> and gconf doesn't unblock them
<isaac> we have submitted a bug to gconf for that
<isaac> but it's not likely it will be accepted soon enough for hardy
<DaveMorris> well the other points need addressing, best to ask a motu about the native thing, I'd just prefer to see it as non native
<DaveMorris> isaac: so this package is simply to be a work around for a bug fix?
<isaac> DaveMorris: kind of, I mean
<isaac> it's useful on its own
<isaac> it just makes a wrapper around exec calls
<isaac> so signals are unblocked when spawning new processes
<isaac> * please add a watch file for the package <- if it's native there is no need for it :)
<rexbron_> Does anyone have a better handle on how to do distro overides in PPAs? Mine get rejected due to the MD5 hashes not match. I belive that I have configured dput correctly
<DaveMorris> yep, best bet is to fix the other issues, get it back up there and see what others think, although IMO if it's to fix a bug rather than bringing any benefit on it's own it shouldn't be there.  Instead I'd talk to the packager for gconf to have your bug fixes as a patch for hardy, whilst upstream add it
<isaac> DaveMorris: done that already
<isaac> DaveMorris: they say they want to wait for upstream
<isaac> upstream is very unresponsive
<Hobbsee> rexbron_: is the tarball version already in the ubuntu archive/
<isaac> because gconf is not really maintained
<isaac> I am fixing the rest of issues in the meantime
<rexbron_> Hobbsee, by that you mean the main PPA archive, yes
<Hobbsee> well, either
<Hobbsee> rexbron_: you need to name it differently, usually
<Hobbsee> or to go off the tarball that's in the ppa already
<DaveMorris> well today is the last revu for hardy on new packages, so it might not get in this way either.
<isaac> right
<rexbron_> Hobbsee, IIRC, one of the features in the new LP:PPA service was an automatic override (via dput configurations)
<Hobbsee> true
<rexbron_> If I do a -sa upload, it rejects due to the .orig md5's matching
<rexbron_> but a straight -S build rejects due to the md5s _not_ matching...
<rexbron_> :|
<fabo> Lutin: please, check twice before merging package from marillat. I think about mlt/mlt++/kdenlive.
<fabo> Lutin: btw, I have uploaded mlt/mlt++ to Debian and kdenlive will follow.
<rexbron_> Lutin, fabo, the current MLT svn has made some rather large architectural changes that break things (in kdenlive at least) and downstream apps need to migrate
<rexbron_> that may have already happened in kdenlive though
<fabo> rexbron_: atm we have mlt/mlt++ 0.2.4 working kdenlive 0.5. we'll need mlt/mlt++ 0.3.0 (new architecture) with kdenlive 0.6 when they'll be released.
<rexbron_> fabo, cool
<fabo> dan dennedy is near the end and jb must sync to the changes introduced
<rexbron_> fabo, I am working on a package that needs MTL/MTL++. Is 0.2.x going to be maintained for a while after 0.3.0 is released?
<fabo> I don't think 0.2.x will be well maintained, better ask dan/charles to confirm.
<effie_jayx> if the url in debian/copyright is broken... what can one do?
<rexbron_> Hobbsee, https://help.launchpad.net/PPAQuickStart
<Hobbsee> rexbron_: ask in #launchpad
<rexbron_> k
<effie_jayx> Hobbsee,  http://packages.debian.org/source/sid/rbot
<effie_jayx> the depends
<Hobbsee> effie_jayx: what about it?
<effie_jayx> no mention of a higher version of ruby
 * effie_jayx things it must have been a typo
<Hobbsee> effie_jayx: that was in 06, though :)
<effie_jayx> persia,  the url in debian/copyright does not work. the package was orphaned in debian and the launchpad bug has a comment that directs to a new sourceforge url ... can I use it?
<effie_jayx> Hobbsee,  I am going to remove the depend... and see what happens
<Hobbsee> effie_jayx: cool
<effie_jayx> this package uses patchsys-quilt.mk ... how different is it from  simple-patchsys.mk
 * effie_jayx is still young with patches
<RainCT> effie_jayx: if you are trying to create a new patch, I think it as:   quilt new; (modify the files) quilt add <modified files>; quilt pop;   or something like that
<RainCT> *quilt new <patchname>, of course
<effie_jayx> RainCT,  thanks
<slytherin> effie_jayx: You may want to refer to https://wiki.ubuntu.com/PackagingGuide/PatchSystems for a start with quilt
<effie_jayx> slytherin,  great
<mruiz> hi all
<effie_jayx> I have done it
<effie_jayx> RainCT  slytherin,  good stuff
<effie_jayx> Hobbsee,  I can't find a but for rbot... shall I open one? I have the fix ready
<LucidFox> can archive admins sync from incoming.debian.org?
<LucidFox> (probably a stupid question)
<Hobbsee> effie_jayx: go ahead
<Hobbsee> LucidFox: i think so
<pochu> LucidFox: yes, they can from anywhere AFAIK. But packages in incoming.debian.org will dissapear...
<effie_jayx> Hobbsee,  I can only reproduce it on hardy
<Hobbsee> yeah
<effie_jayx> Hobbsee,  funny how in gutsy it has the same dependencies and it doesn't complain
<Hobbsee> ruby has only been synced in hardy
<effie_jayx> Hobbsee, and how does it affect?
<Hobbsee> effie_jayx: the ruby version only changed in hardy, from 1.9 to 4
<geser> LucidFox: syncing from incoming.d.o works, but you need an archive admin to do it before it moves out
<effie_jayx> Hobbsee,  this is from the debian BTS, lucas mentions a change in versioning for ruby.
<effie_jayx> ruby switched to a versioning scheme which avoids confusing with the
<effie_jayx> "real" ruby version. Please Depend on ruby1.8 explicitly if you need
<effie_jayx> that specific version.
<pochu> LucidFox: btw libgee has just been accepted in Debian, FYI.
<effie_jayx> so my question is ... does that mean I have to use use then only ruby1.8
<Hobbsee> effie_jayx: i think so
<Hobbsee> for those ones
<paas> Hi Guys, anybody want to take a shot at http://revu.tauware.de/details.py?package=libtuxcap Thanks
<effie_jayx> Hobbsee,  sorry If I have asked too much
<LucidFox> pochu> awesome.
<Jack_Sparrow> crimsun: I have a quick question when you get a chance... I finished making the python module for upstreamdev from bash alsa-info
<bddebian> Heya gang
<effie_jayx> hey bddebian
<Hobbsee> effie_jayx: no problem
<bddebian> Hello effie_jayx
<pochu> howdy bddebian
<bddebian> Hello pochu
<effie_jayx> I have problems building a package... it is a patch
<effie_jayx> No file to patch.  Skipping patch. 1 out of 1 hunk ignored, Patch remove_dependency.diff does not apply (enforce with -f)
<effie_jayx> I was sure to add the file
<LucidFox> So, what should I do with the needs-packaging bug for libgee? Change it to a sync request, or set it to invalid and file the sync request as a new bug?
<Lutin> fabo: what's the problem with mlt{,++}/kdenlive ?
<effie_jayx> if anyone can help me see the issue. http://pastebin.ubuntu.com/4169/
<effie_jayx> my patch won't get applied to the package
<effie_jayx> :S
<slytherin> effie_jayx: Why are you creating a patch for debian/control?
<fabo> Lutin: kdenlive contains useless b-d
<fabo> ccache, libqt3-mt-dev
<Lutin> fabo: ah. maybe. I didn't check them that much
<effie_jayx> slytherin,  I shouldn't?
<fabo> copyright incomplete
<slytherin> effie_jayx: No. patches are to be created only for original source files. Rest of the changes you do i.e. everything in debian/ directory should be documented in debian/changelog
<effie_jayx> slytherin,  perfect thanks ...
<Lutin> fabo: really ?
<fabo> Lutin: i didn't uploaded kdenlive to Debian, does it make sense to have kdenlive-data ?
<fabo> Lutin: i'll be glad you'll sync next packages with Debian instead of debian-multimedia
<Lutin> fabo: sure. I didn't think it was in debian already, I would have merged from debian otherwise
<pochu> LucidFox: I'd rename it, but whatever you prefer is ok
<Lutin> fabo: the -data is ~10Mo while the binary package is < 3, thought it would make sense to split them
<fabo> Lutin: but kdenlive without -data is useless no ?
<geser> Hi bddebian
<LucidFox> in any case, I think libgee on REVU should be archived
<bddebian> Heya geser
<Lutin> fabo: indeed
<Lutin> that's why kdenlive depends on it
<fabo> Lutin: ok, i'll do the same split. it'll be easier to keep common things
<Lutin> fabo: btw, I'd like to know what I forgot in copyright :)
<pochu> LucidFox: If you request a sync, I'll archive it.
<fabo> Lutin: i'll send you the link when i'll put kdenlive in kde-extras repos
<LucidFox> sync requested, bug #184540
<ubotu> Launchpad bug 184540 in ubuntu "Please sync libgee 0.1.1-1 from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/184540
<Lutin> fabo: okay. thanks
<sistpoty|work> hi folks
<jpatrick> hi sistpoty|work
<sistpoty|work> hi jpatrick
<Lutin> heya sistpoty|work
<sistpoty|work> hi Lutin
 * pochu waves at sistpoty|work 
<sistpoty|work> hi pochu
<Coper> If there is no more comments to my package how do I then get it into ubuntu?
<LucidFox> Coper> You will need to wait for two MOTUs to advocate it on REVU
<LucidFox> And here comes the resolution to the great mystery of why no debian-multimedia.org packages use CDBS.
<LucidFox> Marillat doesn't like it.
<jdong> which ScottK is the real ScottK?
<LucidFox> (Which didn't stop him from sponsoring my package that does use CDBS, although he ranted about that.)
<pochu> jdong: all of them I believe :)
<LucidFox> jdong> ScottK2 posted the most recently, I believe
<jdong> LucidFox: ok, I'll try that one then :)
<pochu> jdong: both have the ubuntu cloak
<hellboy195> jdong: both but as they said ScottK2 was more active last time
<pochu> But he probably gets hilighted without the 2
<jdong> pochu: I needed to find the right one for a /query :)
<pochu> jdong: oh, query both then :)
<jdong> haha
<jdong>  /query should take wildcards
<pochu> heh
<pochu> jdong: /join #ubuntu; /query * spam :)
<jdong> pochu: yeah staffers might not be too happy about that use of wildcards :D
<pochu> hehe
 * jdong looks into what the heck is using 75% of his RAM
<LucidFox> Speaking of debian-multimedia.org...
<LucidFox> I'd like to get kplayer from there into Ubuntu, but it's a Qt4 application licensed under GPLv3+
<LucidFox> is this allowed?
<pochu> Isn't Qt4 GPL3?
<jpatrick> pochu: not yet
<LucidFox> well, Qt3 is at least since Ubuntu got 3.3.8v
<LucidFox> * 3.3.8b
<pochu> jpatrick: ah, but they plan it to be, right?
<jpatrick> yep
<mohbana_> hi guys what a good latex editor for gnome?
<jpatrick> mohbana_: vim
<LucidFox> lol
<pochu> or gvim for gnome :)
<LucidFox> but seriously? winefish
<LucidFox> the previous version was Qt3, so I might request that synced until the Qt4 GPLv3 issues are sorted out...
<ion_> gvim + vim-latexsuite
 * LucidFox doesn't use vim. Emacs neither.
<LucidFox> pochu, you promised to archive libgee on REVU once I file the sync request ;)
<pochu> LucidFox: sure, did you file it?
<LucidFox> I said it before... Bug #184540
<ubotu> Launchpad bug 184540 in ubuntu "Please sync libgee 0.1.1-1 from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/184540
<slytherin> What is a way to ask for rebuild of a package for a specific arch?
<pochu> LucidFox: oh, I missed it, sorry. Archiving now.
<LucidFox> slytherin> Did it previously fail to build?
<jdong> slytherin: assuming this is Hardy, poking an archive admin for a give-back
<jdong> but make sure the circumstances are legit first :)
<jdong> on another note, looks like I might get through the backports queue today :)
<jdong> completely.
<LucidFox> Yay!
<rulus_> Can someone review gtkvd (http://revu.ubuntuwire.com/details.py?package=gtkvd)? I'd really like to get it in for Hardy.
<slytherin> jdong: LucidFox: evolution-exchange has FTBFS for powerpc with following error which I believe should be nonexistent now - evolution-dev: Depends: evolution (= 2.21.5-0ubuntu1) but it is not going to be installed
<pochu> sistpoty|work: the new Comment/Reset locations in REVU packages are nice :)
<LucidFox> then ask a buildd admin to restart the build process
<sistpoty|work> pochu: thank RainCT, it's all from him ;)
<LucidFox> pochu> indeed, very HIGish
<pochu> RainCT: \o/
<LucidFox> (Hobbsee, hint, hint)
<Hobbsee> mmm?  wha?
<pochu> LucidFox: archived, btw. with a nice comment ;)
<slytherin> LucidFox: Where can I find buildd admins?
<LucidFox> slytherin wants build for evolution-exchange on powerpc restarted
<LucidFox> in hardy
<jdong> slytherin: say " Hobbsee: prease give back evolution-exchange on ppc"
<Hobbsee> mmmkay
<jdong> :D
<Hobbsee> done
<slytherin> Hobbsee: thanks
<Hobbsee> you're welcome
 * jdong wonders what other shiny buttons Hobbsee's Launchpad has :D
<jpatrick> Hobbsee took something else?
 * Hobbsee has a few
 * Hobbsee didn't actually have to *visit* LP to do that though
<Hobbsee> jpatrick: buildd-admin, yeah
<jpatrick> Hobbsee: "give-back" joke ;)
<shibata> persia: I re-uploaded kita2, thnx.
<Hobbsee> jpatrick: :P
<dcordero> hi
<LucidFox> How do I view the complete edit history for an Ubuntu Wiki page?
<rulus> LucidFox: 'get info'
<LucidFox> ah, I see... it's inaccurately named "Help" in the Russian interface :(
<rulus> heh, that's not very clear indeed
<effie_jayx> Hobbsee,  it installs
<effie_jayx> :D
<effie_jayx> but I can't test it...
 * effie_jayx doesn't know anything about rbot or any other bots for IRC
<Hobbsee> no?
<Hobbsee> ahhhh
<Hobbsee> effie_jayx: stick a debdiff, assign the bug to me, i'll upload it and test it.
<effie_jayx> I guess I could learn
 * slytherin wonders why openoffice has FTBFS on powerpc. Decides to investigate tomorrow.
<effie_jayx> Hobbsee,  great
<Hobbsee> slytherin: you're just asking for a headache there.
<ScottK2> mok0: I'm here now.
<slytherin> Hobbsee: is there a better solution?
<ScottK2> slytherin: OOO almost always FTBFS on ppc.  It's news when it doesn't.
<Hobbsee> slytherin: ignoring ppc?  :)
<slytherin> Hobbsee: I can't. I use it. :-)
<mok0> Hi ScottK2, I've made another attempt at the patch, where the .po are not patched
<ScottK2> slytherin: There's also guilt calc into fixing it since he's the OOO maintainer for Ubuntu
<ScottK2> mok0: I saw the bug in my bugmail, but haven't had a chance to look at it.
<ScottK2> I will
<slytherin> Anyway, time to go home. See you all tomorrow. :-)
<mok0> ScottK2: The assumption is that all .po files are not change wrt Debian
<mok0> changed
<LucidFox> dholbach> I have some questions about the report page
<LucidFox> first, since what date is the progress being tracked?
<dholbach> LucidFox: which date? which progress? :)
<LucidFox> https://wiki.ubuntu.com/MOTU/ReportingPage
<dholbach> LucidFox: oh that one... since last months 22nd
<dholbach> that's the date where we move all collected information to the aggregated one
<LucidFox> where's the aggregated one?
<jdong> so what's the stance on interdiffs for new upstream version sponsorship requests? Required? EncourageD? Discouraged?
<dholbach> general process: https://wiki.ubuntu.com/BuildingCommunity/TeamReporting
<dholbach> aggregated: https://wiki.ubuntu.com/TeamReports
<LucidFox> thanks
<LucidFox> second question: do new packages synced from Debian count in the NEW list?
<dholbach> LucidFox: no, but if somebody likes to add them in a "New Stuff we got from Debian" list, that'd be nice
<dholbach> it's OUR report, so whatever you want to add as news-worthy item is cool
<Coper> How do I check out a package from Hardy if I run gutsy?
<jdong> Coper: probably with prevu
<jdong> or pbuilder
<jdong> !prevu
<ubotu> prevu is an automated, personal backporting utility. Check out https://wiki.ubuntu.com/Prevu for more details
<dcordero> if someone create a need-packaging but the package is available in debian. Is that a sync request?
<effie_jayx> Hobbsee,  what's your launchpad ID
<LucidFox> dcordero> I'd assume so
<Hobbsee> effie_jayx: hobbsee
<vemon> jdong, isn't there an error in the source.list example?
<dcordero> effie_jayx, although the package is not in ubuntu yet?
<ScottK> dcordero: Check to make sure the package builds in Hardy first, but yes.
<LucidFox> I should have discovered the reports page sooner, when there were more newsworthy updates :(
<effie_jayx> dcordero,  which package?
<vemon> jdong, it talks about backporting from feisty but example uses gutsy src repo
<jdong> vemon: no, that is intended
<jdong> vemon: you need a src repo from a "newer" version of Ubuntu
<jdong> vemon: otherwise, there's nothing newer to backport
<LucidFox> for example, I could write about the libgpod transition, or ask jdong and/or superm1 to write about the mpeg4ip transition...
<alinon> is there an easy way to increase the amount of lines the mouse scroll wheel does when I use it?
<vemon> jdong, then the explanation "To be able to backport packages from Feisty's repository." is wrong. unless it's intended to only apply for the lower bullet
<dholbach> LucidFox: yeah
<jdong> vemon: I will revise that
<dcordero> effie_jayx, i dont know now. But i see that situation this afternoon and had this dude
<effie_jayx> dcordero,  sorry I was not following...
<vemon> jdong, nice tool btw. i was just wondering if such a tool exists :)
<effie_jayx> Hobbsee,  done... I did my best .. hope it helps
<vemon> few days back
<Hobbsee> effie_jayx: thanks
<effie_jayx> Hobbsee,  https://bugs.launchpad.net/ubuntu/+source/rbot/+bug/188959
<ubotu> Launchpad bug 188959 in rbot "rbot is uninstallable due to dependecy on "ruby" << 1.9" [Undecided,New]
<Hobbsee> cool
 * Hobbsee will look later
<jdong> vemon: it's indeed a very convenient tool for doing backports for oneself; under the hood it's nothing but a wrapper over pbuilder so it's not "revolutionary" in any way, but certainly a lot easier to set up than a pbuilder :)
<ScottK2> jdong: Have you looked at pbuilder-dist in ubuntu-dev-tools?
<vemon> jdong, and also, importantly, makes it "available" to the average user
 * effie_jayx moves on to an upgrade
<jdong> ScottK2: yeah, I have
<ScottK2> jdong: Is prevu significantly easier than that?
<jdong> ScottK2: it's a great improvement over how pbuilder used to have to be set up, but prevu is still easier than that
<vemon> jdong, i was thinking for a second that a gui for that would be pretty cool... but if someone can't use the console they shouldn't try to backport stuff either :D
<ScottK2> K
<jdong> ScottK2: basically, apt-get install prevu, sudo prevu-init
<jdong> ScottK2: then, prevu lp:firefox-3.0
<jdong> ScottK2: apt-get update, apt-get upgrade, and voila
<ScottK2> OK.  That is easier.
<jdong> I think for the sole purpose of personal backporting, prevu still takes the cake for ease of use
<ScottK2> Makes sense.
<cyberix> persia: Uploaded.
<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
<Coper> jdong: can I download the latest source from hardy with prevu?
<Coper> when I run apt-get source <package> I get the package from gusty and not hardy
<ScottK2> Coper: Just change the deb-src lines in your sources.list to hardy
<Coper> ahh okej.
<effie_jayx> when doing an upgrade, Get an error saying  " This package has a Debian revision number but there does not seem to be an appropriate original tar file or .orig directory in the parent directory; (expected kipina_0.2.2.orig.tar.gz or kipina-0.2.2.orig)"
<effie_jayx> I made sure I changed the source tar.gz to orig.tar.gz
<ScottK> What's the name of your orig.tar.gz?
<effie_jayx> ScottK,  found the mistake thanks
<effie_jayx> it was a _ instead of a -
<ScottK> ;-)
<jdong> Coper: what scott said. Also, alternatively if you download the .deb for prevu from Hardy, you can just type "prevu lp:name_of_pkg" and prevu will automatically query Launchpad for the latest Hardy release
<jdong> (yes, it is safe to grab the hardy .deb of prevu from packages.ubuntu.com; it's a python app)
<effie_jayx> I havea question... the package fails to build. it is missing  checking for GCONF... configure: error: Package requirements (gconf-2.0) were not met, could it be a change in name of the package?
<slomo_> persia, LucidFox: sooo... now you can simply sync libgee ;)
<LucidFox> slomo_> yes, I've already filed a sync request
<LucidFox> bug #184540
<ubotu> Launchpad bug 184540 in ubuntu "Please sync libgee 0.1.1-1 from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/184540
<slomo_> LucidFox: great... why do you want/need it btw?
<LucidFox> because I'm interested in Vala
<LucidFox> currently writing an application in it
<slomo_> LucidFox: what application? :)
<LucidFox> a music manager for iriver players in UMS mode
<LucidFox> (because I have one myself and didn't find any such program)
<slomo_> LucidFox: what do you want it to do? banshee and rhythmbox should probably handle them (i personally use the shell for mine... or sometimes nautilus ;) )
<LucidFox> rhythmbox has _very_ incomplete support for it
<LucidFox> I want to be able to at least manage playlists and videos in addition to music
<cyberix> Could someone please take a look on my package. It should be quite ok.
<LucidFox> blueyed, what's the status of batik 1.7?
<effie_jayx> any suggestions on this situation?  the package fails to build. it is missing  checking for GCONF... configure: error: Package requirements (gconf-2.0) were not met, could it be a change in name of the package?
<cyberix> Is it always this hard to get a package in?
<nxvl_work> dcordero: take another look on Bug #177443 i have added some feedback in there
<ubotu> Launchpad bug 177443 in photoprint "photoprint should recommend or require icc-profiles package" [Undecided,Confirmed] https://launchpad.net/bugs/177443
<cyberix> I've reserved most of the day for fixing potential problems that might remain in my package, but no-one really points out any.
<dcordero> nxvl, i am waiting for debian maintainer http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463826
<ubotu> Debian bug 463826 in photoprint "Merge from ubuntu" [Normal,Open]
<laga> cyberix: i suppose that people are busy with the upcoming feature freeze etc
<cyberix> Aren't people supposed to advocate packages that doesn't have problems?
<laga> cyberix: they'll only advocate if they're sure there are no problems
<dcordero> nxvl_work, , i am waiting for debian maintainer http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463826
<ubotu> Debian bug 463826 in photoprint "Merge from ubuntu" [Normal,Open]
<cyberix> I uploaded my package already during christmass, and fixed most bugs immediately on new years eve when they were pointed out. I did this to make sure the package would be fine in time for Hardy.
<cyberix> I doubt it is really anyones fault, yet still it disturbs me a bit.
<nxvl_work> dcordero: on that patch are also somethings missing
<laga> cyberix: what's your package?
<cyberix> malbolge
<laga> just asking out of interest, i'm not a MOTU
<cyberix> http://revu.tauware.de/details.py?package=malbolge
<nxvl_work> dcordero: you need to explain on the changelog EVERY change yo make
<laga> cyberix: did you see earlier discussion about malbolge?
<nxvl_work> dcordero: and i see some changes that aren't on the changelog
<cyberix> laga: Yes. I took part.
<laga> ah
<dcordero> nxvl, yes? what changes?
<laga> that's all i can offer :)
<nxvl_work> dcordero: and the 3th entry of your changelog is to inexact
<nxvl_work> dcordero: it like if i say "i fix some bugs k thnx"
<cyberix> laga: Iirc persia said the packaging should be ok now, but he didn't advocate earlier because he didn't know software had been written in malbolge.
<dcordero> i dont understand u, i think that all my changes are on changelog :/
<blueyed> LucidFox: re batik: copyright hell, as usual. I've lying a package around with a get-orig-source for the used fop-0_94, but this includes binary-only libs itself..
<nxvl_work> dcordero: you need to write your changelog keeping in mind that other developers will look at the changelog to know in which version are the changes they want and it must be as clearest as posible
<cyberix> laga: I suppose he might advocate now that I corrected him. But he is gone. :-(
<blueyed> LucidFox: the debian package for 1.6 was already repacked, but then fop was "easier".
<nxvl_work> dcordero: on the debian one they are, on the ubuntu they don't
<sistpoty|work> cyberix: you mean there is software written in malbolge? (as in real software)?
<LucidFox> :(
<nxvl_work> dcordero: also the debian ones are not really clear
<cyberix> sistpoty|work: hello world
<dcordero> ok, i'll take a look later for the changelog of ubuntu
<dcordero> thanks
<cyberix> sistpoty|work: But persia was asking for proof that the interpreter works.
<sistpoty|work> cyberix: phew... otherwise it'd be a reason for me to not advocate the package (if then s.o. would want to bring in an application written in malbolge *g*)
<blueyed> LucidFox: copyright isn't nice lately everywhere in the packages I touch.. :/
<shibata> effie_jayx: I think that you should install gconf2 package.
<cyberix> sistpoty|work: :-D
<sistpoty|work> cyberix: I'll be on my way home now, but I'll take a look once I'm at home
<blueyed> btw: is the copyright ok for http://revu.ubuntuwire.com/details.py?package=jedit (as far as I've done it)?
<cyberix> sistpoty|work: Great. Thanks a lot. Please contact me when you're working it.
<sistpoty|work> cyberix: sure, will do
 * sistpoty|work heads home
<sistpoty|work> cya later
<blueyed> LucidFox: do you want to look into batik? I could give you the package I've done so far..
<blueyed> LucidFox: another option might be to just fix the 1.6 package?!
<LucidFox> no, I don't feel like it, sorry
<blueyed> LucidFox: I can do the fixing - it's mainly just the build-depends.. I'll do that.. no need to upgrade from upstream, if Debian hasn't sorted that out yet..
<effie_jayx> shibata,  the thing is in the depend line there is no reference to gconf2
<geser> blueyed: slytherin looked into batik also and if it were only the build-depends then the package would be fixed already
<geser> if I don't mix up things a bug in w3c-dtd-xhtml needs to be fixed first
<blueyed> geser: I'm quite sure it is.. let me check again..
<effie_jayx> shibata,  does it asume it is installed?
<awen_> anybody has the link of all the steps to follow when making ubuntu-changes to a debian package?
<blueyed> juliank: when did you discuss automated copyright extraction? I'm interested in the logs/outcome..
<geser> blueyed: please check as that would kill another FTBFS and would allow an other package to build
<blueyed> geser: already pbuilding
<shibata> effie_jayx: sorry, I'm not sure about it. Your guess may be correct. What is it package?
<effie_jayx> kipina
<effie_jayx> shibata,  the package fails to build after an upgrade
<shibata> effie_jayx: I will confirm from now. But don't expect me. I'm beginner for packaging.
<effie_jayx> shibata,  so am I. two heads think better than one
<awen_> just added myself to the contributers-team on launchpad... can anybody resync the keyring for revu?
<jcastro> persia: was it you that told me Marek Slama is based out of Czech Republic?
<blueyed> geser, LucidFox: yes, batik 1.6 requires e.g. JPEGEncodeParam, which is not yet implemented in icedtea. upstream's 1.7 works, but there's the source issue with the fop-0_94 used by it...
<shibata> effie_jayx: I have no problem and build completed, 0.1.1-4 in pbuilder environment.
 * blueyed wonders if it's ok for multiverse to not include the sources of used libs?
<effie_jayx> shibata,  darn
<cyberix> blueyed: I'm not sure I understand your question
<mruiz> Hi all. I'm preparing a fake sync for mailping (to maintain the version relationship between Debian and Ubuntu). Debian version is 0.0.4-2 and the latest Ubuntu version is 0.0.4ubuntu5. What is a good solution for this case?
<cyberix> blueyed: You plan to add a binary library to multiverse?
<blueyed> cyberix: debian has repacked the batik 1.6 source, because a used lib was not included as source.. however, with 1.6, there's even no-source libs in the lib upstream.
<blueyed> cyberix: there's a binary lib in a source package, used for building it.
<geser> blueyed: it should be if the lib is redistributable and doesn't conflict with the license
<cyberix> blueyed: I suppose that would fit in Multiverse.
<blueyed> geser: so then using batik 1.7, without repacking the source would do it?
<kdub>  is pbuilder or from scratch the recommended way to package things?
<shibata> effie_jayx: According to pbuilder log, kipina does not need gconf2...
<geser> blueyed: probably as batik is in multiverse
<blueyed> yay! :)
<effie_jayx> shibata, I m building an update
<effie_jayx> shibata,  it must be in a new version
<shibata> new version?
<kdub> where can I find a list of apt categories? (the "Section:" in the debian/control)?
<effie_jayx> shibata,  yes.. I am working on an upgrade. 0.2.2
<blueyed> kdub: somewhere on www.debian.org/devel/ in the policy IIRC
<effie_jayx> shibata,  ubuntu is in 0.1.4  and the package is orphan in debian
<kdub> thanks blueyed
<shibata> effie_jayx: oh, sorry... I will try new version.
<geser> blueyed: does the batik license require that we also provide the source code?
<effie_jayx> shibata,  I did the upgrade
<blueyed> kdub: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
<effie_jayx> shibata,  there is no new version in ubuntu yet
<effie_jayx> shibata,  no problem I shall check the mailing list
<blueyed> geser: the source for batik is there, even the one for pdf-transcoder/fop, only the one for fop's libs is missing then.
<blueyed> geser: for those: http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_94/lib/
<geser> blueyed: from a quick look at the license this shouldn't be a problem
<geser> btw: is this a different fop as the packaged one?
<blueyed> geser: don't ask me.. ;)
<blueyed> geser: from the version numbers it seems to be the same.. therefor it's kinda strange that fop itself build-depends on batik, isn't it?
<geser> yes, looks strange
<geser> if you want to be sure about the batik source, ask an archive admin
<mohbana_> hey guys is there anything similar to kile for gnome? i didnt like vim
<cyberix> persia: You plan to advocate the package now that example programs exist and I added the readme file?
<cyberix> persia: I wanted to ask you before you disappear again.
<zul> mohbana_: gedit?
<cyberix> persia: Sistpoty said he was going to look at it. I don't know yet, if he finds something to complain about.
<jeromeg> jdong: hello
<jeromeg> concerning the tracker backport
<awen_> it is only a motu, that can do a keyring sync for revu, right?
<shibata> effie_jayx: I could reproduce "Package requirements (gconf-2.0) were not met".
<effie_jayx> shibata,  could it be the name
<effie_jayx> ?
<shibata> effie_jayx: name?
<effie_jayx> is gconf-2.0 the nameof the package... I thought it was gconf2 or is it just me being silly
<mohbana_> ~packaging
<jeromeg> jdong: some people seem to need to reindex their database because 0.6.3 broke it
<shibata> effie_jayx: I think that gconf-2.0 is not package name.
<jeromeg> jdong: for me it went fine without reindexing
<jdong>  jeromeg ok, that's good information to know
<jdong> jeromeg: I think I'll approve it then the next time I process the queue
<shibata> effie_jayx: "gconf-2.0" is module name. In configure.ac, there are "PKG_CHECK_MODULES(GCONF, gconf-2.0)".
<jdong> which hopefully will be soon. I'm trying to be better about that :D
<jeromeg> jdong: yep i've seem your good work this morning ! congrats !
<jdong> :)
<RainCT> Hey
<shibata> effie_jayx: In my opinion, gconf2 is package which is provide gconf-2.0 module.
<jeromeg> jdong: i'll try to do more testing when i find some time
<jdong> jeromeg: that'd be awesome :)
<jdong> now... to head off to the gym...
<jeromeg> jdong: i've been running a backport of pidgin for more than a month without any problems
<effie_jayx> shibata,  I see
 * RainCT is happy that pochu likes his REVU changes :)
<jdong> jeromeg: sounds good, I'll have to take a close look at it then
<effie_jayx> shibata,  but it should complain then
<jeromeg> jdong: lionel has set up a repo with it to ease testing
<effie_jayx> shibata,  except if it is not installed
 * RainCT is up for 1 review
<Jack_Sparrow> crimsun: Are you available?
 * jdong looks at above statement and brings up the idea of the REVU dating service again.
<jdong> REVUharmony.com
<jdong> See what it's like when attraction is ignited by debcompat-ibility
<Jack_Sparrow> Like you could actually GET a date.. :)
<jpatrick> jdong: hahaha
 * jdong wouldn't be surprised if he gets a lawsuit in the mail about that tomorrow :D
<Jack_Sparrow> I cant date you.. you are packages all wrong
<Jack_Sparrow> packaged
<Jack_Sparrow> sorry, feeling punchy today...
<jdong> Jack_Sparrow: incompatible architectures? ;-)
<jdong> hmm this could REALLY work
<sistpoty> !jdong
<ubotu> <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<jdong> encapsulating a dating service as a debian/control file
<sistpoty> *g*
<Jack_Sparrow>    what is the cli command to find the current ALSA module in use.. ?  That is the last thing I need to finish on the upstreamdev log-module for alsa-info
<shibata> effie_jayx: What happens if add "libgconf2-dev" in control file?
<blueyed> RainCT: do you want to review jedit? :)
<sistpoty> cyberix: malbolge advocated
<cyberix> \o/
<RainCT> blueyed: looking :)
 * cyberix wonders, if persia will show up once more today
<cyberix> sistpoty: Thanky you.
<cyberix> s/y//
<sistpoty> cyberix: thanks for your work!
<cyberix> I'm looking after _second_ advocate for my package malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
<blueyed> RainCT: I know about "Homepage" already.. :)
<paas> RainCT, Hi thanks for reviewing my package http://revu.tauware.de/details.py?package=libtuxcap. I've fixed the issues you had with it and uploaded a new version
<awen_> the 'Homepage' field in debian/control, is that official... and from which standards-version?
<RainCT> awen_: yes, 3.7.3
<RainCT> (or perhaps 3.7.2.*, I'm not sure)
<ScottK2> 3.7.3
<awen_> thx... but stil wonders why dpkg-buildpackage still complains
<RainCT> awen_: get a newer lintian version
<blueyed> cyberix: advocated.
<awen_> RainCT: i'm using the one in hardy... shouldn't that one be updated?
<ScottK2> It is
<cyberix> blueyed: Thanks!
<cyberix> Now I can get to bed early
<cyberix> :-D
<RainCT> awen_: Ah, might be that they haven't added it to lintian yet.
<blueyed> cyberix: you may want to look at the jedit package.. even if you cannot advocate it.. :p
<cyberix> blueyed: It is written in malbolge?
<cyberix> persia: Got the advocates. Thanks a lot for your help too.
<awen_> RainCT: looks like it... just checked; am using the newest version avaible in hardy
<juliank> RainCT, awen_: lintian has support for the Homepage field.
<juliank> since 1.23.35
<sistpoty> RainCT: did you send the mail to me instead of MC list on error?
<RainCT> sistpoty: yes, already re-send it to MC (but with the wrong e-mail address, so that it's in the moderation queue -.-)
<sistpoty> heh, k
<awen_> juliank: i still get "dpkg-source: warning: unknown information field 'Homepage' in input data in package's section of control info file" and lintian 1.23.42 is installed?
 * RainCT really finds this annoying in GMail
<RainCT> awen_: then it's dpkg-source who complains :)
<blueyed> cyberix: no, jedit is written in java.
<RainCT> blueyed: why is priority "extra"?
 * RainCT thinks he will leave this sentence somewhere ready for copy-pasting :D
<awen_> RainCT: ahh... i'll just ignore that then :)
<blueyed> RainCT: because dh_make put it there..
<RainCT> blueyed: and you let dh_make decide for your? :P
<awen_> RainCT: do you have revu-powers (aka. is able to keysync)?
<juliank> RainCT, awen_: Support for Homepage has been added to dpkg 1.14.16, but hardy has 1.14.15ubuntu1.
<blueyed> RainCT: no, but paid no attention. Should be optional, right?
<RainCT> awen_: no, but sistpoty and persia have
<RainCT> juliank: ok, thanks
<RainCT> blueyed: yes, probably
<awen_> RainCT: okay... thx
<RainCT> blueyed: unless your PC explodes when you install it :D
<RainCT> blueyed: I don't like the short description (the "programmer's" part), but I'm not native English speaker so feel free to ignore me :P
<blueyed> RainCT: taken from the project homepage/their .deb..
 * sistpoty syncs keys on revu
<RainCT> blueyed: Comment[ca]=Editeu fitxers de text   Comment[es]=Modifique archivos de texto       GenericName[ca]=Editor de text per a programadors          GenericName[es]=Editor de textos para programadores
<RainCT> blueyed: looking at the files in debian/* it looks fine (beside the priority), but I encourage adding an .xpm for debian/menu :)
<blueyed> RainCT: ok, I had an xpm, but thought that .png would be enough, when it complained that it's not 32x32.. ;) will resize and add one. Thanks for the translations.
<blueyed> RainCT: what do you think about debian/copyright so far?
<RainCT> blueyed: looks fine, but I'm not familiar with the machine readable syntax
<cyberix> blueyed: Have to boot to hardy. I'll take a look.
<RainCT> paas: why are there libavogadro0.install, libavogadro0-dev.install and avogadro.install if you don't mention those in debian/control?
<paas> RainCT: oops, forgot to remove these, will do now
<blueyed> For a debian menu file, do you have to specify the full icon path, or does it work as with desktop files?
<awen_> thx for the sync sistpoty :)
<awen_> now i can get the package reviewed, if anybody is up for that: http://revu.tauware.de/details.py?package=imapsync
<sistpoty> np awen_
<awen_> worked together with the debian maintainer for this version, but sadly he ended up making a last minute change, that prevented the package to build in the buildd's... this is a fix to get the package building
<paas> RainCT: ok, fixed that
<RainCT> btw, OLPC's interface is called Sugar, or?
<blueyed> yes
<slangasek> that's the UI, yes
<RainCT> and wasn't it going to be in Xubuntu?
<ScottK> It's in the Hardy repos
<RainCT> ScottK: do you know how it is called?
<ScottK> Not exactly, but it's got sugar in the name(s) IIRC.
<RainCT> I can only find sugar-datastore and sugar-presence-service.. :/
<TheMuso> persia: Thanks, I feared as much.
<superm1> perhaps the other pieces aren't in yet
<RainCT> blueyed: ah, I forgot before: I prefer if debian/copyright links to the download page instead of the index of the home page, but this is a just a question of personal thing, so also feel free to disagree here
<RainCT> (paas: ^ same for you)
<ScottK> RainCT: There's a PPA for Gutsy.  I thought it was all in the repos for Hardy. Maybe not yet.
<RainCT> ScottK: ah, I'll wait then. Thanks!
<effie_jayx> <shibata> effie_jayx: What happens if add "libgconf2-dev" in control file? he is not here but for the sport... an app shouldn't depend on dev libraries right?
<yamal> MOTUs, please review http://revu.tauware.de/details.py?package=sabnzbdplus - looking for a second advocate. thanks
<TheMuso> Good morning.
<blueyed> RainCT: I think the download URL may change, therefore I think the main homepage is safer.
<blueyed> Morning, TheMuso.
<RainCT> paas: I'm still pbuilding it but until now it looks good :), just add two lines at the end of the description for libtuxcap-dev (check some other lib to use the same text), sorry for not telling you before
<mok0> ScottK: Re: courier... Apart from the changelog stuff could you make use of the patch? I did not create it as a debdiff, but rather as an ordinary diff -urN
<RainCT> blueyed: ah, good point
<cyberix> blueyed: My Hardy is broken and I need to go and sleep soon
<paas> RainCT: is it ok if I add  "This package contains the development files needed to link against the libtuxcap shared and static libraries." to the end of libtuxcap-dev?
<blueyed> cyberix: for looking at jedit? No problem.. it was just an "idea" ;) Sleep well.
<paas> RainCT: and is it ok if I add " This package provides a shared library needed by C++ programs linked with it." to the libtuxcap1 section?
<cyberix> blueyed: Compiling on gutsy gives me various warnings, but then again it wasn't supposed to work on gutsy
<sistpoty> slangasek: I'm just looking bug #188868, which is caused by sdl-image1.2 dlopen'ing libjpeg62.so.. what would be the right thing here? have sdl-image link against libjpeg62 so that the dependency will get picked up?
<ubotu> Launchpad bug 188868 in trigger "Missing dependency on libjpeg62" [Undecided,New] https://launchpad.net/bugs/188868
<ScottK> mok0: I'm busy today so didn't have a chance to look further.
<paas> RainCT: Should I also add the Homepage attribute to the control file?
<mok0> ScottK: np
<RainCT> paas: yes, add the Homepage. and I think the texts are also ok :)
<slangasek> sistpoty: that would IMHO be the correct thing to do
<sistpoty> slangasek: ok, thanks
<slangasek> sistpoty: dlopen()ing public libs is a bad idea, because it means you're not actually building against the headers and bypassing any symbol versioning
<slangasek> (that's two separate problems, fwiw :)
<sistpoty> heh
<sistpoty> as far as I've seen it, dlopen can be disabled (at least for libjpeg62) in sdl-image... I'll fidlle with this :)
<paas> RainCT: I've uploaded a new version with the fixes :-)
<blueyed> RainCT: me too :)
<RainCT> great :)
<RainCT> paas: I'll advocate once it finished building ;)
<RainCT> paas: lintian had some complains about the .deb (see my comment on REVU), but this is now really the last thing I'll complain about :)
<RainCT> well, good night all
<pochu> argh, I just answered effie_jayx question and then received blueyed answer which said the same :)
<blueyed> pochu: on the mentors list?
<pochu> blueyed: yeah, you are fast ;)
<effie_jayx> pochu and blueyed ,  thanks for the answer  I am going ahead and test
<effie_jayx> Do I need to add that in the changelog?
<pochu> effie_jayx: yes
<pochu> effie_jayx: you should add everything you change
<effie_jayx> pochu,  great
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<crimsun> sistpoty: tweaked & uploaded.
<sistpoty> thanks crimsun
<crimsun> (debian/control -> XSBC-Original-*, etc.)
<sistpoty> crimsun: ah, right... I guess I'm too used to getting a build failure (which didn't happen this time *g*)
<crimsun> hehe
<effie_jayx> the build can't find scrollkeeper-config... :S
<crimsun> is scrollkeeper in the build-depends?
<paas> Hi, how do I fix this lintian error shlib-with-non-pic-code?
<RAOF> paas: Ooh, that's a new one on me (but I only build on amd64, so that's a fatal error).  You probably need to fix the upstream build system.
<paas> I've checked and it's build using -fPIC and I'm using gcc -shared instead of gcc Wl,-shared, any idea?
<sistpoty> paas: any inline assmebly in the code?
<rexbron> Hey everyone, I am looking for a review of Open Libraries and openFX: http://revu.ubuntuwire.com/details.py?package=openlibraries http://revu.ubuntuwire.com/details.py?package=openfx
<paas> sistpoty: yep, just grepped for asm and found  an asm("nop");
<sistpoty> paas: hm... why would s.o. put a "nop" in there? *g*... I may be wrong, but I don't think only a nop will cause this error
<paas> sistpoty: I'll remove the nop and try again, see what happens
<emgent> heya
<sistpoty> hi emgent
<emgent> sistpoty, have you read security team meeting log ? :)
<sistpoty> emgent: not yet... thanks for reminding me to do so
<emgent> sistpoty, see https://wiki.ubuntu.com/UbuntuPentest :)
<paas> sistpoty: and what about this one: lintian gives me non-dev-pkg-with-shlib-symlink on my shared library package
<emgent> and join #ubuntu-hardened,is avaiable bot that post in real time security advisory (CVE,bugtraq etc..)
<man-di_> is Daniel Hahler here on IRC?
<crimsun> blueyed: <--
<sistpoty> paas: the *.so should only go to the -dev package, not to the library package (you'll only need it to via -lsomelib which will pick up libsomelib.so)
<crimsun> man-di_: sorry.  nick is blueyed.
<man-di_> aah
<pochu> How can I assing something to a $variable inside an if statement in a makefile? I've tried with a simple GST_PACKAGE_NAME = "foo" but it errors with "/bin/sh: GST_PACKAGE_NAME: not found"
<man-di_> blueyed: sorry, but the patch you sent me (xmlgraphics-commons) is crap
<geser> pochu: try removing the space around =
<man-di_> blueyed: please see the comment in the bugreport for the reason
<pochu> geser: trying, thanks
<paas> sistpoty: ok, thanks, I'll fix it tomorrow, cheers
<sistpoty> np
<pochu> geser: woha, thank you :)
<sistpoty> emgent: just read parts of the meeting... and of course the pentest wiki page... very nice and great idea!
<emgent> :)
<sistpoty> emgent: and big thanks again for hunting down the revu security issues!
<blueyed> man-di_: looking
 * sistpoty needs to go to bed now
<sistpoty> gn8 everyone and cya tomorrow
<blueyed> man-di_: but isn't this also what you've said in the tagged-pending comment? (which I've not read before)
<persia> TheMuso: Given the annoyance of that license, I'd suggest filing an ITP, putting a candidate on mentors, and sending a request for license review to debian-legal@.  If you need it for hardy, ask one of the archive admins to see if they would accept it: regardless of my comments, you've a second ACK.
<man-di_> blueyed: yeah, I was wrong...I requested rejection from NEW queue and forgot to fix the bug report
<man-di_> blueyed: I found the problems too late
<man-di_> blueyed: BTW: No need to write patches for bugs marked pending already, pending normally means the bug is already fixed and not yet uploaded
<blueyed> man-di_: yes, I see. I've not seen this when submitting it using the submittodebian script.
<blueyed> man-di_: I'll try using icedtea-java7 then.
<man-di_> blueyed: scripts are evil *g*
<blueyed> man-di_: btw, I've also looked into the batik package, which only builds with upstream's 1.7 with icedtea. Have you looked into this (I've seen reports about it)?
<man-di_> blueyed: Vincent works on it
<blueyed> man-di_: fop-0_94 contains a libs directory now itself, without source - but I've been told that it would be ok for Ubuntu's multiverse.
<man-di_> (if you mean batik)
<blueyed> yes
<man-di_> blueyed: and? (fop)
<blueyed> man-di_: currently batik's source is repacked to include the fop source, but doing so now pulls in some binary-only libs (for fop).
<blueyed> I have a get-orig-source for that, I've you're interested
<blueyed> s/I've/if/
<man-di_> blueyed: send it to Vincent if its for batik
<TheMuso> persia: Right. I've let upstream know, and I'm waiting for a response, after I gave them a link to the DFSG.
<TheMuso> Its not high priority though, so I'm not pushing hard on it.
<blueyed> man-di_: ok, thanks again.
<blueyed> man-di_: I've came to xmlgraphics-commons through batik. I was wondering why batik depends on/used fop, and fop itself build-depends on batik. Seems strange.
<man-di_> blueyed: normal in Java country
<pochu> Anyone has a clue why the printf will print "" ? GST_PACKAGE_NAME shouldn't be empty
<pochu> http://paste.ubuntu.com/4180/plain/
<crimsun> Jack_Sparrow: were your questions for alsa-info answered?
<Jack_Sparrow> Hey...
<blueyed> pochu: tried without the parentheses? or with curly braces?
<Jack_Sparrow> crimsun: I got the log-module done...   only one question...  What is the cli command for  ALSA Module in Use ?
<blueyed> pochu: currently it's a subshell invocation, isn't it?
<pochu> blueyed: it's in a makefile target
<pochu> blueyed: I haven't tried that, let me see
<pochu> blueyed: without parentheses didn't work, still "". What are curly braces?
<crimsun> Jack_Sparrow: do you mean the driver or all the kernel modules?
<pochu> blueyed: when running the makefile, the code is shown as this: http://paste.ubuntu.com/4181/plain/
<blueyed> pochu: use $${VAR}
<blueyed> man-di_: well, using icedtea results in the same/broken .jar..
<blueyed> man-di_: at least it was broken like that before in Ubuntu's archived (I've only did a merge).. will file a bug about it.
<man-di_> blueyed: yes, the needed classes are in not in icetea
<crimsun> Jack_Sparrow: for the former: awk '{print $2}' /proc/asound/modules
<crimsun> Jack_Sparrow: for the latter: lsmod|awk '/^snd/ {print $1}'
<blueyed> man-di_: too bad that the build does not fail then.
<Jack_Sparrow> crimsun: There was one catagory in your output I did not have yet
<man-di_> blueyed: write a patch
<Jack_Sparrow> crimsun: Thanks..
<man-di_> blueyed: should be pretty trivial
<blueyed> man-di_: to make the build fail? how would you attack it?
<man-di_> always compile the tiff stuff, not do this conditionally
<jwendell> pochu, around?
<Flare183> wow
<pochu> jwendell: yes, sir :)
<jwendell> pochu, Hi
<jwendell> pochu, I was thinking if you would want to provide a debdiff for bug #188033
<ubotu> Launchpad bug 188033 in tsclient "tsclient crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,Fix released] https://launchpad.net/bugs/188033
 * pochu waits for launchpad to load the page...
 * pochu starts to think whether his wifi disconnected or launchpad is down
<pochu> !ping
<ubotu> ping yourself ;-) really the diodes all down my left side are sore
<pochu> launchpad.net could not be found. Please check the name and try again.
<pochu> Is it just me?
<jwendell> yes
<jwendell> hehe
<pochu> Alright, it worked now
<pochu> jwendell: I can create a debdiff, but I won't be able to test it other than building the package...
<jwendell> pochu, yes, this is what I mean
<jwendell> pochu, I just wanted this fix soon in hardy
<jwendell> pochu, and your name comes first in my mind ;)
<pochu> jwendell: you need to learn how to make debdiffs, it's quite easy ;)
<jwendell> pochu, I already know how to do this
<pochu> jwendell: I'll try to make one later, but I'm quite busy with gstreamer stuff so I can't promise it
<pochu> jwendell: oh, alright :)
<jwendell> pochu, I just don't have the time to fix upstream and handle downstream
<pochu> jwendell: that's understandable
<jwendell> pochu, don't worry, let's just assing it to some right team and ping seb128 tomorrow
<pochu> jwendell: I'll take care of it.
<jwendell> pochu, ok then, thanks
 * pochu is still fighting this makefile...
<jwendell> pochu, thanks, see you tomorrow
<geser> pochu: who leads? you or the Makefile?
<pochu> geser: the makefile atm :/
<pochu> ah! Got it!
 * pochu WINS! :-)
<blueyed> man-di_: well, I would have to hack the build.xml file to set internal-codecs.eff.disabled to false always.. but that feels dirty to me.. ;)
<blueyed> man-di_: btw debian/watch: opts=dversionmangle=s/\.dfsg(\.\d+)?$ (the .NUMBER is optional really - at least currently)
<pochu> I ended using an ifeq at the beginning of the makefile, instead of an if inside a target. It seems like inside the target the variable wasn't assigned the correct value. Either that or I messed it entirely
<blueyed> pochu: have you tried $${var}?
<blueyed> ..because this works in debian/rules: [ "${VERSION}" = "$${version}" ]
<blueyed> the first one is a makefile var, the latter being set in the subshell call
<pochu> blueyed: I haven't, but I don't think it would have solved it, as there was an else statement which should have assigned a value to the variable. And it was still empty
<pochu> blueyed: hmm, do you mean in the if [ foo = bar ], or in GST_PACKAGE_NAME="bar" ?
<blueyed> ..well "empty", because you've not called it properly, I think.
<blueyed> foo="bar"; echo $${foo} should work
<pochu> ah
#ubuntu-motu 2008-02-05
<pochu> blueyed: I've to go for a dogwalk now, but I'll try that when I'm back. Thanks!
<blueyed> welcome, have fun :)
<gilir> hi
<gilir> there is a little problem with REVU :) http://revu.tauware.de/details.py?package=awn-extras-applets
<ScottK2> Dear everyone: Please stop and think about if your change is appropriate to Debian before sending them a patch and a bug.
<tacone> sorry
<tacone> is it still valid to propose software ?
<pochu> You can always propose. It may well not be accepted though :)
<tacone> oh, I'd get very angry then :-D
<pochu> tacone: we are near Feature Freeze so it's likely a bit late...
<pochu> tacone: but is that new software or changing a default application?
<tacone> new software
<tacone> may sound stupid. a little game, which work like a charm with ubuntu
<tacone> there's already a .deb on getdeb.net
<pochu> You have 10 days until Feature Freeze. After it your chances are low.
<pochu> tacone: is it Debian? How is it called?
<tacone> where should I propose ?
<tacone> teewars
<pochu> File a needs-packaging bug in Launchpad, (and a RFP in Debian)
<tacone> it's got nice reviews. and it's very simple and addicting. http://www.getdeb.net/app/TeeWars
<tacone> should I propose that in debian too ?
<TheMuso> tacone: If it gets into Debian first, its a lot easier to get into Ubuntu.
<pochu> The game looks nice indeed
<tacone> themuso: it's already packaged
<tacone> there's a .deb on getdeb.net.
 * pochu looks for bddebian to get it packaged in pkg-games :)
<pochu> But he isn't around...
<TheMuso> tacone: Yes, but that may need extra work before its accepted into Debian/Ubuntu.
<tacone> I understand that.
<tacone> I don't know how to file a need packaging bug. where do I specify 'need packaging' ? in the bug title ?
<vorian> is a rules error or dependency error?
<vorian> http://paste.ubuntu-nl.org/54796/
<vorian> :)
<pochu> tacone: yes, and add a "needs-packaging" tag
<tacone> just submitted. looking for the change of attaching a tag
<tacone> done, nice !
<tacone> https://bugs.launchpad.net/ubuntu/+bug/189118
<ubotu> Launchpad bug 189118 in ubuntu "Teewars would be a nice inclusion for hardy" [Undecided,New]
<tacone> :-)
<effie_jayx> vorian,  looks like a file missing
<effie_jayx> I am no expert though
<effie_jayx> :D
<vorian> you are doing awesome effie_jayx :)
<effie_jayx> vorian,  I am going the distance... :D
<bddebian> Heya gang
<vorian> i'm converting my package to be compliant with the debian/python policy
<effie_jayx> the updated souce seems to have several files changed. there is a whole bunch of files that are in .install file that are not in the soucer package... do this get created or I have to find the list somewhere?
<imbrandon> hrm does gparted safely resize a ext3 part ?
<vorian> imbrandon: sure, i just did one a few weeks back
<imbrandon> cool
<vorian> it needs to lead though
<imbrandon> yea thats no biggie
<vorian> ah, there is no setup.py
<ScottK2> slangasek: Excellent responsiveness on sync requests today (sync done less than an hour after I request it).  Thanks.
<slangasek> ScottK2: nah, I think I need to get a start on those earlier in the day, so I can be /off/ that page by the time your sync requests come through ;)
<slangasek> (looks like I won't get any new processing done today, for instance...)
<bddebian> heh
<slangasek> jdong: bug #175344: are you sure it was the intention of the original bug submitter to request a backport, as opposed to an SRU?  The bug title here comes from Kmos, who I think may have misapprehended the submitter's concerns
<ubotu> Launchpad bug 175344 in gutsy-backports "Please backport ntfs-3g 1.1120 from Hardy" [Undecided,In progress] https://launchpad.net/bugs/175344
<jdong> slangasek: for the specific issue the submitter cited, yeah, it's SRU material .However, there's also new features (faster perforamcne, relatime support and default) that make the release worthwhile in any case
<ScottK2> * twitch *
<ScottK2> jdong: Then shouldn't the SRU be done first.
<jdong> ScottK2: I think they are independent matters that can be approached in any order
<zul> icky
<slangasek> yes, the order shouldn't matter
<jdong> ScottK2: if we SRU it, I'd also like to look at the 5+ other issues addressed in the versions between gutsy and hardy :)
<ScottK2> jdong: OK.  My experience has been that once you do the backport the interest in working out the SRU goes WAY down.
<jdong> ScottK2: and before long, that's gonna be the same thing as just a backport :D
<slangasek> but I'm not sure if pushing a backport with this poor user's name in the changelog is the right thing either, since I don't think that's what he was requesting
<ScottK2> Slap jdong's name on it then.
<jdong> slangasek: Only my name gets put in the changelog, right?
<jdong> ScottK2: only if Canonical sends me an official Ubuntu scapegoat t-shirt :)
<ScottK2> jdong: You've been wearing that one for years.
<slangasek> jdong: uh, I've been following the same convention as for syncs, which is that the original bug submitter gets their LP id used in the backport
<jdong> slangasek: interesting :)
<ScottK2> slangasek: Normally for a backport I'd suggest you put whoever ack'ed it for backporters.
<slangasek> if I should use you for all of them instead, that would certainly save on typing ;)
<jdong> slangasek: the other archive admins previously have been following the convention that it goes to the approving backporter
<slangasek> ok, that's fair
<jdong> slangasek: yeah I think that's a better way of doing it
<ScottK2> slangasek: Your odds of having someone mind after problems go way up that way.
<jdong> slangasek: often times backport requesters aren't of the technical skill level of a sync requester and would be less able to deal with the responsibility of the changed-by blame trail ;-)
<jdong> slangasek: not to mention FTBFS mail should be directed at a backporter :)
<jdong> not that I'm all that interested wine didn't build on sparc256 or whatever :)
<slangasek> right, let me go through and redo these... :)
<jdong> hehe :)
<jdong> who's the ntfs-3g dude around here?
<ScottK2> I like the stick the tag on jdong no matter who did it plan.
<ScottK2> That'd be you, now.
<jdong> :)
<jdong> I was wondering if we should update to the latest upstream release before review
<jdong> release*
<jdong> http://ntfs-3g.org/releases.html their release notes always sound intriguing
<jdong> though that 2121 release sounds scarily intrusive
<ScottK2> Well I'd be really careful about an ntfs-3g backport no matter which version it was.
<jdong> ScottK2: the main mode of failure for one would be some sort of FUSE API incompatibility blowup
<jdong> causing ntfs-3g to be inoperable
<jdong> historically the QA from ntfs-3g upstream is quite superb
<zul> everytime i see ntfs it makes my skin crawl
<jdong> I believe they have a test suite too :) (gasp!)
<blueyed> How can I search for packages which build-depend on a given package?
<StevenK> blueyed: grep-dctrl
<jdong> slangasek: so you're the poor unfortunate soul stuck with processing all those backports I triaged this weekend? :D
<slangasek> yes
 * jdong gives slangasek half of this yummy cardboard^Wprotein bar he's snacking on :)
<slangasek> next time, take a Wednesday off to do those ;)
<jdong> haha :)
<pochu> Night MOTUland!
<jdong> ask backports requestors. I don't do this often :D
<vorian> how does the debian/python policy apply to a package which is built with a configre/makefile?
<vorian> this is killing me :P
<blueyed> StevenK: thanks, but I can't get it to do what I want.. would I have to grab some Contents file for this?
<blueyed> I've tried e.g. "grep-available -F Build-Depends sun"
<StevenK> Contents lists what packages provide what file, that is hardly revelant
<StevenK> blueyed: grep-dctrl -FBuild-Depends -sPackage sun < /var/lib/apt/lists/*Sources
<slangasek> jdong: do you think 175344 should also have an SRU, then?  If so, would you mind nominating it for gutsy?  (TTBOMK I still can't nominate bugs without them immediately being accepted)
<jdong> bug 175344
<ubotu> Launchpad bug 175344 in gutsy-backports "Please backport ntfs-3g 1.1120 from Hardy" [Undecided,Fix released] https://launchpad.net/bugs/175344
<jdong> slangasek: :-/ I'm hesitant to do so because I'm not sure what the scope of that SRU would be
<jdong> I'm not familiar with upstream's codebase or release habits
<slangasek> ok
<jdong> but I will add a comment
<jdong> and also flip (presumably Kmos's) invalid marking on Ubuntu
<TheMuso> jdong: You can check the activity log for that.
<jdong> 10 Dec 07 18:49   Marco Rodrigues  ntfs-3g: status  New  Invalid
<jdong> surprise!
<blueyed> StevenK: thanks, works (in zsh). I'd expected more packages then 25 though (B-d on sun's java)
 * Hobbsee refuses to comment, but wonders about how many *other* good bugs have been mangled, due to him, and if anyone plans on reverting the changes
<Hobbsee> i guess people will rereport, particularly in hardy+1
<sgbirch> Can somebody plz help.  I am in the debian NM queue and am maintaining a couple of packages which are also in Ubuntu, xball and vobcopy.  My sponsors have uploaded new versions of both programs recently.  How can I get them uploaded to Ubuntu as well.  They are both in sid.
<ScottK2> vorian: The build system doesn't affect policy.
<blueyed> sgbirch: they are both in Ubuntu already. To get the latest release synced, you should file a sync request.
<blueyed> sgbirch: I could file the sync request, if you want.
<ScottK2> vorian: Either convince the upstream makefile to shove stuff into policy compliant locations or make your own setup.py, add it to the debian/dir and then use that.
<ScottK2> blueyed: Better he files it and you ack it.
<blueyed> ok
<sgbirch> blueyed: This is actually my first ever contact with Ubuntu folks.  I normally hang out in the debian areas.  So I dont know how to file a sync request.  Can you point me to the docs so I can RTFM plz?
<ScottK2> sgbirch: Do you use pbuilder for test bulding?
<blueyed> sgbirch: docs are at https://wiki.ubuntu.com/SyncRequestProcess
<sgbirch> blueyed: Oh ... I just noticed your offer to file the sync req.  Would you please, that would be great.  Two packages .... xball and vobcopy.
<blueyed> I'm testing currently if they build and will do so then. Seems more straightforward, doesn't it, ScottK?
<ScottK2> blueyed: Yes, but if you do it, he doesn't learn and can't do it himself the next time this comes up.  We want to help everyone learn that comes here.
<sgbirch> ScottK2: No, I use a clean VM loaded with sid
<mruiz> hi all
<ScottK2> sgbirch: OK.  You might want to consider setting up an Ubuntu Hardy VM so you can test build on our toolchain.  It'd make it more credible/less work for us if you've already done the test build when you come ask.
<mruiz> I'm preparing a new version for mnemosyne but upstream packages it as <file>-<version>.tgz. Should I repackage it ?
<ScottK2> mruiz: Just rename it.  That's not repackaging.
<ScottK2> mruiz: You have to rename .tar.gz to .orig.tar.gz in any case.
<sgbirch> ScottK2: OK .. I am happy to do that.  Although I am working towards DD I run Ubuntu on all my machines :-)  I really want the two packages I currently maintain and future packages to always go into debian and ubuntu.  So the Ubuntu learning curve is important to me.
<ScottK2> Excellent.
<ScottK2> sgbirch: I'm the same.  I run Ubuntu, but am in NM.
<sgbirch> ScottK2: Very cool.
<mruiz> ScottK2, thanks... I'm asking as tgz is different to tar.gz ;-) . I read that tar.bz2 should be processed in a different way
<ScottK2> sgbirch: Welcome.  You might also want to consider doing packaging work in Ubuntu and maybe becomine a MOTU.
<ScottK2> mruiz: I missed the bz2 part.  Yes.  You need to reroll that.
<mruiz> :-)
<sgbirch> ScottK2: Yes ... that is very much on my mind, Id like to do that.  I actually do packaging professionally in my day job ... but that doesn't mean I am an expert by any means :-)
<ion_> A tar.bz2 only needs to be recompressed, not repackaged entirely.
<ScottK2> sgbirch: Well we're always looking for help.
<sgbirch> ScottK2: How long have you been in the NM queue?
<vorian> belated thanks ScottK :)
<ScottK2> Oh well.  I guess he left
<ScottK2> vorian: You're welcome.
<vorian> :)
<mruiz> bye all
<mruiz> good night
<bddebian> ScottK2: Did you scare another one away? :)
<bddebian> Night mruiz
<nixternal> w00t! GO BLUE!
<nixternal> sorry, seen the umich :)
<jdong> yay, from my state :)
<nixternal> hey, I need some opengl love here...I have a file that includes <GL/gl.h>, that is apparently a part of mesa-common-dev, I shouldn't have to dep on that should I
<jdong> go umich people :)
<nixternal> jdong: my state too! :)
<vorian> booo
<nixternal> ahh, one of them hairy nut fans
<vorian> :D
<jdong> nixternal: I always thought you were in chicago for some reason?
<vorian> shouldn't it be libglu1-mesa-dev
<nixternal> you know, I need to stop saying that, because people who do not know about a buckeye may wonder
<jdong> vorian: and your highway patrol owes me money!
<nixternal> jdong: I am, but I was born in Benton Harbor, MI
<vorian> lol
<nixternal> all of my family is there
<nixternal> hahahaha
<vorian> jdong: yah yah yah :)
<jdong> nixternal: ah, ok, cool :)
<jdong> vorian: seriously, blinker lights too bright?
<nixternal> Penguicon in DTown in a couple of months, who's going?
 * vorian raises his hand
<nixternal> jdong: let me guess, clear tail lights?
<jdong> nixternal: depends on whether or not This Wonderful Educational Institution will give me time off ;-)
<jdong> nixternal: and actually, no, stock lights on a grand cherokee
<nixternal> I will be broke, so everyone is buying me food and drink
<jdong> nixternal: but admittedly they are stunningly bright in the night
<nixternal> wow
<vorian> with Michigan plates I bet :P
<jdong> vorian: yup
<jdong> :)
<nixternal> I got pulled over because they said my blinker lights were to bright here in Chicago...but my truck has custom carbon fiber tail lights
<jdong> vorian: no front plate so no laser tickets :)
<vorian> that would be your first problem
<nixternal> oh, and they are damn bright
<jdong> nixternal: ah, interesting :)
<nixternal> it is a xeon bulb that you can find in some fog lights :p
<nixternal> err
<nixternal> zenon I think is what they are
<jdong> nixternal: I was let off with a warning, though my sarcasm nearly cost me the $120 :D
<jdong> xenon
<nixternal> hahaha
<nixternal> xenon, that, that's it
<jdong> I've been considering adding HID front and LED rear lights
<vorian> oh bother
<nixternal> I am ordering some LED from ebay for the rear myself
<jdong> I even have a nice strip of Luxeon Star and Nichia CS reds that I stripped off an ambulance light bar
<jdong> (legally!!)
<vorian> nixternal: anywhere but ebay!
<nixternal> haha
<nixternal> vorian: best price for them
<jdong> I'm guessing I should NOT use those lights in Ohio :)
<nixternal> well the place I might order from has an ebay store
<nixternal> I am starting to hate opengl
<jdong> slangasek: you still awake?
<jdong> nvm I answered my own question
<vorian> nixternal: are you looking for `The OpenGL utility library development environment'?
<slangasek> jdong: because you saw me still doing archive processing? :-P
<jdong> slangasek: well I had no idea whether that was activity or LP lag :)
<jdong> slangasek: but it was regarding the bzr-svn tangle, I noticed jpatrick also had requested/approved a bzr-svn backport
<jdong> slangasek: at any rate, hold off on both for now and let me look at this 0.4.7 that jelmer wants :)
<jdong> and with that, I disappear off into the night :)
<jdong> aaahhh the LP mail has started!
<jdong> slangasek: oh btw I bet at least 2 of the backports you processed today will instnatly end up in source NEW so if you could push those through after you're done too... *hugs*
<nixternal> vorian: I figured it out I think
<nixternal> might help to update patches/series
<vorian> schweet
<ScottK2> bddebian: No.  He heard you were coming.
 * jdong wonders if there will be nuclear fallout from firefox-3.0 entering gutsy-backports :)
<vorian> lol
<StevenK> jdong: For someone who has disappeared, you talk a lot
<jdong> StevenK: I'm a bad magician... I can never disappear completely on the first try
<slangasek> jdong: ah, I think I'm running away for the night after the backports themselves are done, sorry
<jdong> slangasek: sure thing :)
 * StevenK kicks libosso
<StevenK> I change the dbus security policy for its dbus service, and now hildon-desktop SEGVs inside libosso
<StevenK> s/its/libosso's/
<bddebian> ScottK2: Heh, zing :-)
<tonyyarusso> Hi, I have two lintian warnings I would like explained to me - "W: kompozer source: desktop-file-but-no-dh_desktop-call" and "W: kompozer source: out-of-date-standards-version 3.7.2 (current is 3.7.3)".  Are these things I need to worry about?
<firestormx37> hello, i would like to get involved and help with bugs or packaging, but i am not sure where to start.  I have been reading all the getting started and faq pages, but I need help finding something small and easy to start with.  Can anyone help me out?
<StevenK> tonyyarusso: The first means you are installing a .desktop file and don't call dh_desktop in your rules file
<StevenK> tonyyarusso: The second you can update if you're worried about the warning
<tonyyarusso> StevenK: What changes are there in the standards version that I would need to update?
<StevenK> tonyyarusso: There is a checklist installed by the debian-policy package
<tonyyarusso> StevenK: Okay, I'll look for that.
<tonyyarusso> desktop thing first..
<tonyyarusso> StevenK: Would that go in install: build or binary-indep: build install?
<StevenK> tonyyarusso: In binary-indep
<StevenK> tonyyarusso: The first word there is the target name itself, the others are what that target depends on.
<tonyyarusso> StevenK: I still don't quite understand that.
<StevenK> tonyyarusso: binary-indep is a Makefile target, which requires that the targets build and install are up to date before it runs
<tonyyarusso> ok
<tonyyarusso> Okay, the only warning I have now from lintian is "W: kompozer source: not-binnmuable-all-depends-any kompozer-dev -> kompozer"
<tonyyarusso> What's binnmuable mean?
<StevenK> Able to be binary-only NMU'd, a Debian-ism
<StevenK> Means you don't use (>= ${binary:Depends}) in kompozer-dev's Depends line.
<tonyyarusso> Yeah, I was using Depends: kompozer (= ${binary:Version})
<StevenK> Oh, that should be okay
<StevenK> Actually, >=
<StevenK> binary:Depends is my brain going funny
<tonyyarusso> the lintian notes suggest Depends: kompozer (>= ${source:Version})
<tonyyarusso> perhaps I should try that?
<StevenK> tonyyarusso: Sure. My memory might be faulty
<tonyyarusso> k
<tonyyarusso> all right, looks good now
<LucidFox> Would anyone like to sponsor bug #187576? I'd like to get the new upstream version to Ubuntu first before packaging it for Debian
<ubotu> Launchpad bug 187576 in smplayer-themes "Upgrade to smplayer-themes 0.1.15" [Wishlist,Confirmed] https://launchpad.net/bugs/187576
<jdong> ugh this channel does not help my insomnia
<jdong> LucidFox: I'm gonna have to try my best to ignore you till tomorrow morning.... Need my sleep for classes ;-)
<LucidFox> heh
<tonyyarusso> I wonder what percentage of Ubuntu contributors are students
<crimsun> a non-trivial portion.
<tonyyarusso> Please review: http://revu.tauware.de/details.py?package=kompozer
<ScottK2> jdong: Sleep IS what the classes are for.
<tonyyarusso> Well, I guess now it's just time to go to bed and wait.  If someone's considering looking at that kompozer upload, it should be all pretty straightforward changes, so hopefully nothing too complicated to worry about.  'night
<ScottK2> tonyyarusso: Why is an upgrade on REVU?
 * ScottK2 just looked at two packages and found copyright problems in both.  Urgh.
<TheMuso> ScottK2: Perhaps we should have something about people getting copyright checked out before submitting a package...
<ScottK2> TheMuso: I think running grep -ir copyright * over the package should definitely be mentioned.  These packages had all been reviewed several time before too, so MOTUs aren't looking hard enough either.
<TheMuso> I think there is an assumtion that other MOTUs will look at the copyright.
<ScottK2> That or the archive admins will do it.
<ScottK2> Good night all.
<dholbach> good morning
<tonyyarusso> ScottK2: Because I thought it was supposed to be?  Please enlighten me.
<LucidFox> dholbach> Not yet, but I'll talk to the original maintainer, thanks for the tip. You can unsubscribe u-u-s for now.
<dholbach> LucidFox: will do - thanks for taking care of it!
<tonyyarusso> Since ScottK2 went to bed, anyone care to tell me what the proper process for getting upgrades approved and uploaded is?
<superm1> tonyyarusso, generally attaching to a bug and subscribing u-u-s
<superm1> tonyyarusso, but after FF, new versions will need to go through motu-release
<superm1> bug fixes can still be attached to a bug though
<tonyyarusso> superm1: Ah, all right.  And if I do it that way, it should probably be a debdiff rather than the full thing, right?
<superm1> tonyyarusso, well all depends on the situation
<superm1> and the patching scheme used for the package
<superm1> previously interdiffs were the way to go
<superm1> if all of the patching is constrained to the debian/ directory
<tonyyarusso> superm1: It was just packaging info updates - debian/control, debian/rules, and debian/changelog I think are all that changed.
<superm1> the more ideal route is to link to the new archive, and then attach a diff of the two debian/ directories
<superm1> or even better, use a get-orig-source rule to build the archive needed for the .orig.tar.gz
<superm1> but if you debdiff two new versions alltogether, it will be a very large diff usually
<superm1> understand?
<tonyyarusso> Sorry, no...
<superm1> okay so lets say you've got hello-world-v1 and hello-world-v2
<tonyyarusso> okay, good so far :)
<superm1> between the two versions, there are tons of upstream changes
<superm1> they decided that they wanted to add this wacky GUI and stuff
<tonyyarusso> hehe
<superm1> so you go and package up the new version based on the old one's packaging
<superm1> and you're all said and done
<superm1> so you debdiff the two dsc's, and its a 10 meg debdiff
<superm1> well that would be silly to upload
<superm1> your changes were just in the debian directory
<superm1> and the diff for your changes is only like 15k
<tonyyarusso> Okay, still following.
<superm1> so instead, in that case you can just do a diff between the old debian directory and new debian directory
<superm1> and upload that diff instead
<superm1> just in your comments on the bug explain that its a diff of the debian directories, and provide a link where someone grab hello-world-v2
<tonyyarusso> I wasn't aware diff operated on directories - or do you do it file by file?
<superm1> you can do it recursively
<tonyyarusso> ah
<superm1> the switches are something like -urN
<superm1> unified recursive something something
<tonyyarusso> now, as far as this link, which file precisely is it going to?  Which portion is "interesting" to a reviewer?
<superm1> well it wouldnt be for review
<superm1> it would be for a new version
<superm1> so if its say a merge from debian
<superm1> and they have that new version, just say to grab the .orig.tar.gz from there
<superm1> if on a website say to grab it from there
<superm1> the most ideal case though, you can write a rule in debian/rules that will grab the right file for the person
<superm1> if its not already present
<tonyyarusso> Now, in my particular case today, the .orig.tar.gz is completely unchanged.  Do I even need a link then?
<superm1> now in that case you can just use a debdiff
<tonyyarusso> I wish I had that kind of debian/rules fu, but sadly, I simply don't (yet)
<superm1> because you're not including any new .orig.tar.gz
<superm1> so no new upstream changes
<dholbach> (-N treats non-existant files as empty in the 'old' directory)
<tonyyarusso> So debdiff makes sense now, but I should know all this other stuff for later.
<superm1> well that's just one type of case, but yeah its a good idea to understand it
<superm1> there are more complex cases depending upon how the package adopted a patching system which you might come across some day
<superm1> like mplayer for example
 * tonyyarusso installs a 1TB drive in his brain for this...
<superm1> be careful with that one, its fun
<tonyyarusso> I'm told I should start using quilt for my package, if I'm brave someday
<tonyyarusso> (it's a mozilla thing)
<superm1> everyone has their preferences on patching systems, you'll eventually learn which ones are easier for you to work with
<superm1> after seeing how they operate
<superm1> dholbach, ah.  i've wondered about that
<superm1> but never looked at the man page :)
<LucidFox> tonyyarusso> I prefer simple-patchsys for CDBS packages and dpatch for plain debhelper packages.
<tonyyarusso> So, if I'm going to create a bug whose sole purpose is the be the carrier of this diff, should I bother trying to cite it in changelog or does it not matter?
<LucidFox> tonyyarusso> yes, mention it in the changelog
<tonyyarusso> okay
<LucidFox> tonyyarusso> as for recursive diffs, superm1 is right - run it with -urn
<LucidFox> -urN
<LucidFox> (u)nified format, (r)ecursive, include (N)ew files
<tonyyarusso> LucidFox: wrt the changelog, I have 3 things that I did (all quite minor).  How would you suggest I write that, with the bug #?
<LucidFox> * Fixed such-and-such issue (LP: #xxx)
<tonyyarusso> I meant as in should I list the same LP bug three times?
<LucidFox> no, once is sufficient
<tonyyarusso> okay
<LucidFox> its sole purpose is to let the upload automatically close the bug
<tonyyarusso> Oh, that's nifty.
<LucidFox> As for patches, does the package use CDBS?
<tonyyarusso> No.  (not yet at least)
<LucidFox> Ah, that's a shame. The CDBS simple-patchsys is not that in name only, it's really the simplest patch system out there.
<superm1> the only thing i don't like about the simple-patchsys is that all patches in that directory are "automatically" applied.
<superm1> so if you want to turn off one
<LucidFox> Ah, indeed.
<superm1> even temporarily you gotta move it out of the directory
<crimsun> whew, well there went a few hours of testing.
 * crimsun uploads and drags off to sleep
<LucidFox> superm1> but doesn't it only apply files with the .diff and .patch extensions?
<superm1> LucidFox, i think so, but again, you gotta rename it then
<superm1> which makes the diff's huge
<LucidFox> (granted, that won't help if you want to just minimize the delta, which is achieved by removing just one line with dpatch)
<superm1> exactly
<superm1> but be it as it may, easy to use otherwise
<tonyyarusso> Any preferences for what I should name a debdiff?
<LucidFox> I name it the same as the dsc/diff.gz, but with the .debdiff extension
<LucidFox> package_version-XubuntuY.debdiff
<tonyyarusso> makes sense
<tonyyarusso> In LP, there's the checkbox for "this attachment is a patch" - does that include debdiffs, in the sense more like "this attachment has code to fix it"?
 * tonyyarusso guesses yes
<mok0> tonyyarusso: yes
<tonyyarusso> sweet
<tonyyarusso> All right, I think it's all ready to go - https://bugs.edge.launchpad.net/ubuntu/+source/kompozer/+bug/189174 if you want to see if there's anything wrong with that.
<ubotu> Launchpad bug 189174 in kompozer "kompozer needs minor packaging fixes" [Undecided,New]
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<master_obredar> hello
<master_obredar> need help please
<LucidFox> gah!
<LucidFox> well... he will learn patience
<slytherin> Can anyone help me investigate this issue. There is a source package aspectwerkz2 which is supposed to provide binary libaspectwerkz2-java (arch all). Launchpad says build was successful but I can not find the binary anywhere.
<superm1> slytherin, did you check the hardy NEW queue?
<slytherin> superm1: where to check it?
<superm1> https://edge.launchpad.net/ubuntu/hardy/+queue
<superm1> the first time a binary is introduced to the archive, it sits there
<superm1> until an archive admin acks it
<superm1> if this was already in the archive, then just give it some time to propagate the mirrors
<TheMuso> Packages that are already in the archive that introduce new binaries also sit in binary new.
<slytherin> superm1: Ah, it is there in 'New' queue.
<slytherin> superm1: When will it get processed?
<superm1> when archive admins have time
<superm1> on a regular basis though at least
<superm1> since its right before feature freeze, you can see its a mad rush to get things in
<tonyyarusso> They seem to tend to let them sit for a while, then plow through a bunch in a few hours from time to time
<slytherin> superm1: Th reason I am asking is that there are other packages which FTBFS due to absence of this package
<superm1> slytherin, they haven't entered depwait?
<slytherin> superm1: I checked just now. They have entered depwait
<superm1> see for example, i uploaded gmyth a few days ago
<superm1> https://edge.launchpad.net/ubuntu/+source/gst-plugins-bad0.10/0.10.5-5ubuntu3/+build/504499
<superm1> and its in depwait now
<superm1> ah okay
<superm1> slytherin, once the binaries get released some automatic job eventually releases the depwait packages to try again
<slytherin> superm1: Ok. Thanks for info.
<superm1> np
<LucidFox> Apparently, icedtea-java7 has been rejected from Debian. Gah.
<LucidFox> dholbach> I've got a reply from the original maintainer of smplayer, posted it in bug #188964
<ubotu> Launchpad bug 188964 in smplayer "Please sync smplayer 0.6.0~rc1-1 from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/188964
<dholbach> LucidFox: rock on!
<slytherin> LucidFox: Why is icedtea rejected?
<LucidFox> no idea
<apache|mobile> hm
<apache|mobile> long island iced tea?
<slytherin> Can anyone sponsor the debdiff attached to bug 183164
<ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
<mok0> Can PostSript documents, for which there is no "source", be distributed?
<slytherin> oops, I just realised the package is in main.
<LucidFox> heh
<RAOF> mok0: PostScript is source, even if it isn't generally easily editable source :)
<mok0> RAOF: So it's only PDF documents?
<mok0> That require "source"
<slytherin> persia: Can you somehow accelerate the acceptance of debdiff on w3c-dtd-xhtml bug. :-D
<LucidFox> lol
<LucidFox> why don't you ask a core-dev?
<slytherin> LucidFox: Just asked on #ubuntu-devel. Looks like no one is awake there. :-)
<mok0> slytherin: no-one's awake here either
<LucidFox> apparently, there was a netsplit
<slytherin> mok0: I interact with persia regularly, he knows what the problem is about and he reads logs. :-)
<mok0> Heh
<mok0> How does + something sort in the version number? For example 3.0 vs. 3.0+p1 vs. 3.0.1 ??
<mok0> "p1" means "patch level 1"
<TheMuso> moDo you know of dpkg --compare-versions
<TheMuso> gah just went offline
<pkern> Hobbsee: I would appreciate if you could sponsor #189186 ;)
<rulus> Can someone take a look at my package (http://revu.tauware.de/details.py?package=gtkvd) please? It's ready for advocation. Thanks a lot!
<dholbach> nixternal, persia, soren, geser: are you OK if I set up the polls for the motu-release team members?
<soren> dholbach: Sure thing.
<geser> dholbach: sure
<jpatrick> nixternal is sleeping
 * dholbach just renames the team in LP according to the motu meeting discussion
 * dholbach also updates the documentation
<dcordero> hi
<dcordero> there are an easy way for apply a diff.gz with a lot of .diff file in it?
<dcordero> something like patchGreat -p1 < ../file.diff.gz ?
<_ruben> zcat patches.gz | patch -p1 *might* do the trick
<lucas> or patch -p1 <( zcat ../file.diff.gz )
<lucas> (see man bash)
<dcordero> yep, i thought that maybe there are a command for that. thanks
<HighNo> hi there, I'd like to ask for the exact status of integration of my package as someone has filed bug 137339 for me
<ubotu> Launchpad bug 137339 in ubuntu "They must include BlueProximity in repositories" [Wishlist,New] https://launchpad.net/bugs/137339
<pkern> Hobbsee: dholbach already acked it (thanks, eh)
<HighNo> It seems it has been hanging around without any action now for a long time.
<Fujitsu> HighNo: That's not a long time.
<Fujitsu> The exact status is most probably that nobody has started, nor is planning to in the foreseeable future.
<HighNo> Fujitsu: OK :-) Anyway are there ways to speed things up? Can I help in any way?
<Ng> HighNo: package it yourself with the help of the fine people in here :D
<Fujitsu> You could package it yourself. Unless someone else has a specific interest, it's unlikely to get done.
<HighNo> Ng: it is already packaged for feisty but works (as told by users) on gutsy and hardy
<slytherin> HighNo: So what is problem then?
<HighNo> Is there somewhere I can upload it to to check wether the package has formal errors and that deps are OK for hardy?
<HighNo> slytherin: how does it get into the official repository?
<HighNo> official being universe of course
<Ng> HighNo: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<slytherin> HighNo: Oh you mean to say you have packaged it outside of ubuntu. Submit it to revu. But first make sure there are no severe packaging problems by trying to build it in pbuilder
<HighNo> ok, thanks for the info - could I still make it into hardy if I do it all by myself and do it now?
<HighNo> (just to time my efforts)
<Ng> HighNo: feature freeze is only just over a week away, and I'd expect things to get quite busy between now and then
<RAOF> HighNo: Technically possible, but unlikely.  Especially since no one seems to have been terribly interested before this.
<slytherin> HighNo: FeatureFreeze is on 14th Feb.
<dcordero> nxvl, i have answer you in Bug #177443
<ubotu> Launchpad bug 177443 in photoprint "photoprint should recommend or require icc-profiles package" [Undecided,Confirmed] https://launchpad.net/bugs/177443
<HighNo> ok, thanks. I'd give it a try. I hope to broaden the user base by including it into the official feed. there are about 1k users atm...
<slytherin> HighNo: even if it does not get included in official repos you can have your own repo in the form of PPA. :-)
<dholbach> nixternal, persia, soren, geser: done and mail to lists sent out
<HighNo> slytherin: but that won't help people adding it easyly and finding it easily via apt/synaptic/etc., right?
<slytherin> HighNo: of course it will. PPA is all about your own repository which can be added via synaptic/apt etc
<geser> slytherin: re lucene2: does the latest lucene2 in Debian unstable fix the dtd problem? It builds fine here (in a pbuilder) and the changelog mentions a fix for the tests
<slytherin> geser: Let me check.
<HighNo> slytherin: that's what I meant. People have to add my repo first. People who don't know my software won't add that repo by themselves... This would probably not increase user count :-)
<slytherin> yes, I just suggested a workaround. It is not a solution
<slytherin> geser: changelog has some mention for fix but not about what exactly is the fix.
<sistpoty|work> hi folks
<slytherin> geser: I will try building it just to confirm and then file a sync request.
<geser> Hi sistpoty|work
<sistpoty|work> hi geser
<pkern> dholbach: That "n hours from now" stuff is annoying.
<pkern> dholbach: As I tend to act on mails immediately.
<dholbach> pkern: I'll follow up on the mail with a reminder a day before the polls close :)
<pkern> dholbach: Heh.
<slytherin> geser: even if lucene2 from debian unstable builds in Ubuntu, it uses Sun Java. What about bug 185917 then?
<ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
<geser> slytherin: that would be my next question :)
<geser> slytherin: can the same changes be applied to the recent package?
<slytherin> geser: As I don't know what exactly debian guys do to bypass/disable/fix the tests, I can not comment on that.
<slytherin> My preferred course of action is that we concentrate on fixing lucene2 2.2.x for which I have a patch ready. If needed we can have a merge with FFE later.
<persia> slytherin: Best to wait on the queue.  It does get processed, even if it takes a bit.
<persia> superm1: diff -urN debian/ is not a good way to track updates.  I've seen too many patches lost because they were in the diff.gz.  While the documentation still needs updating, please advocate the presentation of the new diff.gz for new upstreams.
<slytherin> persia: You have dropped in at right time. Your comments are expected on the whole lucene2 issue. :-)
<geser> slytherin: I've looked into the diff.gz and it is in debian/patches/81_prevent-network-access.dpatch. It simply comments testEncoding() out.
* 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 | FeatureFreeze 14th February
<persia> The last scheduled REVU day for hardy has now concluded.  Packagers, please keep watching REVU: if a reviewer wants your package for a feature goal, they will likely keep commenting.  If not, consider uploading to a PPA for hardy, and make sure it's perfect for next cycle.
<slytherin> geser: Smart move. :-)
<dcordero> what is the right place for all the .py files of a python coded application?
<persia> slytherin: I don't have a lot to say about lucene2, other than "Good Luck" and "Please keep chasing this, universe for hardy would be great!".
<persia> dcordero: http://wiki.debian.org/DebianPython/NewPolicy is probably the right place to start
<geser> slytherin: what about backporting this patch to the current version in Ubuntu?
<dcordero> thanks persia
<slytherin> geser: If commenting the test is the way we want to go then it is not that hard.
<persia> Wouldn't it be better to get feedback on the DTD patch before uploading a workaround?
<slytherin> persia: geser: We have to make a decision, 1) fix 2.2.x our way and have icedtea as dependency  2) sync debian version for now to fix FTBFS and then apply our DTD patch and use icedtea as build dep later.
<persia> slytherin: And 3) Do nothing now, and then apply some FTBFS fix and use icedtea as build-dep later.  Why is 2.3 better?
<slytherin> persia: I have no idea. I haven't even looked it. The discussion started few minutes before you arrived.
<persia> slytherin: Just a few minutes before I wrote anything :)
<slytherin> :-)
<geser> persia: there is no need to update to 2.3, I've just seen that a new version hit unstable and checked if it resolves our FTBFS
<geser> if we get 2.2.x to build then we can keep it and merge 2.3 in hardy+1
<persia> geser: Right.  It was just the mention of a sync for a new upstream this close to FF that made me reflexively ask "Why".
<geser> if we need additional changes we can apply them to 2.2 too
 * persia looks at upstream
<geser> as long as we fix the FTBFS I don't have a preference which way to go
<persia> There's a heap of API changes, according to http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_3_0/CHANGES.txt.  Might be a lot of transition work to get it in for hardy.
<geser> then it's probably better to fix 2.2
<persia> On the other hand, lots of bugfixes, and it's supposed to be faster.
<slytherin> persia: what transition are you talking about?
<persia> slytherin: lucene2 2.2 -> 2.3.  API changes often means someone has to do extensive testing and porting.  Best to push these pre-DIF, unless there is some external driver pushing the update.
<geser> persia: and lucene2 did never build successfully so not much to transition
<slytherin> geser: +1
<geser> and packages build-depending are now in depwait instead of perhaps ftbfs if they need an adaption to the new api, so no big regression in this point
<emgent> heya people
<persia> geser: It's arch;all, so it only FTBFS for us.  solr-common has a dependency, and there's a couple packages on REVU as well.
<HighNo> I am somewhat puzzled atm, the docs of creating packages talk of 'try using pbuilder' as you stated above. My package is python only, so no building takes place at all or am I missing the point here?
<slytherin> persia: geser: will be back in half hour.
<persia> HighNo: You're missing the point.
<persia> A "source" package is in a format that can be built with debuild, sbuild, pbuilder, etc.
<persia> A "binary" package is in a format that is ready for installation on a target machine.
<geser> persia: with which version of lucene2 are the packages in REVU tested? we can fix 2.2 if it helps the packages in REVU to get into the archive
<persia> For python packages, "source" packages usually have all the development docs, and a layout that makes it easy for people to hack on them.  "binary" packages then put all the necessary .py files to run in the right directories to be byte-compiled at installation time.
<persia> geser: netbeans expects 2.2.  I haven't been following the others as closely.
<persia> We can probably leverage some QA resources from the Petersburg hb team, but they'd be happier with 2.2.  On the other hand, if someone wants 2.3 for some reason, netbeans can be adjusted.
<jpatrick> DEB_INSTALL_MANPAGES_kmplayer_common = kxineplayer.1 - is that valid?
<geser> persia: then keep 2.2
<persia> jpatrick: Just use debian/kmplayer-common.manpages.
<jpatrick> binary package is kpmayerl-common
<jpatrick> arg
<jpatrick> persia: ok
<geser> jpatrick: nice typo
<persia> jpatrick: The other works, but CDBS hooks aren't very transparent, and it's best to make the packages easy for others to update :)
<jpatrick> persia: I hope it will pick it up from "docbook2x-man debian/kxineplayer.1.docbook"
<persia> jpatrick: I think you still need a hint for dh_installmanpages, but may as well try it.
<HighNo> persia: Ok, then can you please help me what exactly should I upload at REVU if I have a complete package. I have it as a tar.gz (complete dir) and also as a ready to install .deb file. I tried do "decipher" the wiki pages at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages what the .deb file should be like and what it should include but I got lost somewhere. Is there an easy checklist for a package?
<persia> HighNo: You want an orig.tar.gz, a diff.gz, and a .dsc.  From these, you should generate a source.changes file, which is what you upload to REVU.  I'm distracted by several other things, and don't know much about python packaging: you'd do better to ask specific questions to the channel generally to get your answers.
<persia> Also...
<persia> !packaging | HighNo
<ubotu> HighNo: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<HighNo> persia: thanks for the info, the url's are all known to me as I have gotton lost there too often... :-/
<sistpoty|work> geser: how can I prolong my membership? didn't find anything on my lp page, nor on the motu page (though I also didn't get a reminder mail from LP yet)
<persia> HighNo: http://wiki.debian.org/DebianPython/NewPolicy may also be useful.  You might want to look at some other python packages as well, and if you find one with a similar license, consider using that as a template.  The use of distutils is looked upon favorably.
 * Hobbsee waves
<sistpoty|work> hi Hobbsee
<geser> Hi Hobbsee
<persia> sistpoty|work: You should be able to get it from the team members list.
<HighNo> persia: thank you very much - that seems a good idea and a new url to me :-)
<sistpoty|work> persia: didn't find anything there (though I must admit, LP sometimes confuses me *g*)
<sistpoty|work> I did find that leave the team button though *g*
<persia> sistpoty|work: You might have to wait until you are about to expire, and then do something.  It'd be on one of the links on the left.  In the worst case, if you got bumped, just use the "Join Team" link, and someone would fix it within a few hours.
<sistpoty|work> persia: ok, thanks... then I'll just be patient :)
<persia> On the other hand, for other teams I administer, I often see notices that people have extended their membership.  I think LP sends you a reminder when the membership is about to expire.
<sistpoty|work> yes, it should do this... at least it did for ubuntu-dev membership
 * persia notes that ~ubuntu-dev should have no non-team members
<sistpoty|work> iirc the plan was to have this get cleaned out via the normal expiration, instead of doing it manually
<persia> sistpoty|work: Right.  Just don't renew your membership if you are asked :)
<sistpoty|work> persia: I was already and didn't ;)
<persia> sistpoty|work: In that case, you get a gold star :)
<sistpoty|work> :)
<sistpoty|work> oh, now since the final REVU day is gone, may I abuse sparky for a ghc6 test build? (it will cause REVU to be unreachable a little bit, due to high memory usage and swapping)
<sistpoty|work> will only take 10-14 hours I guess *g*
<zorglu_> q. im trying to use lzma to compress my .deb, i have seen stuff using 'dpkg-deb --build -Zlzma' but my dpkg-deb doesnt seem to understand it as it report 'dpkg-deb: unknown compression type `lzma'!"'. any idea suggestion on which dpkg-deb start supporting this lzma compression type ?
<persia> sistpoty|work: Err.  Yes, but there are still some packages there that will go into hardy.  Does spooky still not do it's thing?
<pkern> zorglu_: Which release?
<zorglu_> pkern: im running feisty here
<persia> zorglu_: Build in a hardy chroot
<persia> s/t's/ts/
<sistpoty|work> persia: nope, spooky still needs to get installed... OTOH I install spooky during the weak maybe
<pkern> zorglu_: Gutsy, if not hardy.  But you should testbuild in a hardy chroot anyway, as persia said (or pbuilder fwiw).
<sistpoty|work> and testbuild there then
<zorglu_> persia: you mean that the default dpkg-deb of hardy, support lzma ?
<persia> sistpoty|work: OK.  I've also a sparc that I keep meaning to install.  I'll see if I can get to it later in the week.
<sistpoty|work> oh, cool
<persia> It's only a 400S, so it might take a couple days to build ghc6, even if I get it up.
<zorglu_> pkern: do you know if dpkg-deb on gutsy support lzma ?
<persia> zorglu_: Looks to have been included in 1.14.15, from 7th January.
<zorglu_> persia: oh quite recent then.
<persia> zorglu_: I may be mistaken.  Feel free to check the source for various releases to see when the support was really added.
<zorglu_> persia: wow this seems to be a lot of work just for that :)
<zorglu_> persia: pkern: thanks
<Hobbsee> bug  #189186
<ubotu> Launchpad bug 189186 in gobby "Please sync gobby 0.4.6-3 from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/189186
 * slytherin is back
<mruiz> morning all
<persia> awen: Please submit your diff.gz for imapsync to a bug.
<persia> tonyyarusso: Are you all set with kompozer, or do you still need the REVU entry?
<persia> martoss: Similarly, submitting a diff.gz in a bug will give you a better chance of getting eric updated for hardy.
<cyberix> Does the "Ready for upload" status guarantee that my package will be built and get into Hardy before freeze?
<persia> cyberix: No.  It needs to be in the NEW queue.
<persia> And even if it is there, it doesn't guarantee it will be built and distributed pre-freeze, only pre-release.
<cyberix> I'm trying to make sure everything goes ok. Mainly, I don't want the package to be left out just because someone forgot to put it forward.
<persia> Things entering the NEW queue post-freeze need special exceptions to be included in the release.
<persia> cyberix: Did you check the queue yet?
<cyberix> The build queue, yes.
<cyberix> The package doesn't appear there.
<persia> The NEW queue?
<cyberix> Where do I find that one?
<cyberix> That is before or after the build queue?
<persia> replace +builds with +queue in your URL
<cyberix> "Thereâs no page with this address in Launchpad."
<soren> https://launchpad.net/ubuntu/hardy/+queue
<cyberix> thanks
<soren> The +queue one is per suite. +builds is distro-wide.
<cyberix> No, my package is not in the new queue
<persia> soren: Ah.  I didn't know that worked.
<persia> cyberix: In that case, you need an uploader.
<soren> persia: Eh?
<persia> soren: https://launchpad.net/ubuntu/+builds
<cyberix> I supposed second advocate would do the uploading.
<persia> I always used https;//launchpad.net/ubuntu/$release/+builds or https://launchpad.net/ubuntu/$release/$arch/+builds
<persia> cyberix: Generally.  Sometimes they are away from their key, and someone else uploads.
<sistpoty|work> cyberix: if it wasn't uploaded until I get home, I'll upload it (as I was the first advocate).
<cyberix> sistpoty|work: Thanks.
<soren> persia: Oh? How do you usually find it?
<soren> persia: Or did you just not know of that page?
<persia> soren: I usually get there from +queue
<soren> persia: Oh, right.
<geser> slytherin: persia and I agreed to keep lucene2 2.2. Is disabling that specific test useful or should we try to fix w3d-dtd-xhtml instead?
<geser> from the Debian bug against w3c-dtd-xhtml it looks as it might take some time to convince the maintainer
<slytherin> geser: I have already added debdiff to Ubuntu bug. Now waiting for it to be sponsored. Why not to it right way instead of disabling the test.
<geser> slytherin: if it just needs sponsoring that let's do it the right way
<slytherin> :-)
<rexbron> Hi, I am looking for a review of two packages, Open Libraries and openFX: http://revu.ubuntuwire.com/details.py?package=openlibraries http://revu.ubuntuwire.com/details.py?package=openfx
<sistpoty|work> theseinfeld: just saw your comments on revu... linda is a little bit outdated, so you can ignore the output regarding standards-version
<theseinfeld> ok sistpoty
<sistpoty|work> theseinfeld: however you should build-depend on debhelper (>= 5.0.0) and set dh_compat to 5 (not too sure if there are plans to deprecate v4 already)
<theseinfeld> roger that
<theseinfeld> sistpoty: building, and soon uploading with compat 5 and debhelper >5.0.0
<theseinfeld> will this work with the ppa building?
<slytherin> theseinfeld: Sure. debhelper has been at version 5 for long time
<theseinfeld> oh yeah
<theseinfeld> I have 5.6.0 on gutsy
<geser> and hardy has already debhelper 6
<Coper> Can a MOTU review my new package http://revu.ubuntuwire.com/details.py?package=console-freecell
<theseinfeld> done and done!
<martoss> if I upload sth with dput, how can i force to dput the orig.tar.gz as well?
<theseinfeld> dpkg-buildpackage -sa
<theseinfeld> martoss add -sa
<martoss> ah ok, I used debuild
<Ng> debuild -S -sa :)
<ScottK> martoss: add -sa works for debuild too
<persia> martoss: Also, keep in mind that packages already in the repositories uploaded to REVU are not likely to get much attention.  You'd do better with a bug.
<\sh> moins
<martoss> filing a bug with dsc, and diff?
<yamal> ScottK: regarding your review of sabnzbdplus: would it be best to just remove only that template (or even just that one file), or to simply leave all templates out that are not included in the package anyway?
<geser> Hi \sh
<persia> martoss: Just the diff.gz.  The .dsc can be reconstructed by the sponsor.
<martoss> ok
<ScottK> yamal: Just that one file.  It was the only one that was licensed differently (unless of course you find more that I missed).
<persia> yamal: Also note that the use of shortened names or other aliases for Maintainer or changelog entries is very much not preferred.  Perhaps you could collaborate with someone if you really need to avoid exposing your name?
<yamal> Though it might make sense to just remove a potential problem by getting rid of all template interfaces that aren't getting included in the package anyway
<yamal> ScottK: but of course I'm not a licesing compatibilty expert
<ScottK> yamal: Does the template not get installed in the binary package (I didn't have time for a full review last night)?
<yamal> ScottK: no, only the (completely gpl-licensed) Default one does.
<yamal> I already figured the other ones would be a licensing minefield
<ScottK> persia: There's one template file with Apache licensing.  If it doesn't get included in the binary, it's probably OK.  What do you think?
<ScottK> Maybe it doesn't need repacking then.
<persia> As long as the file includes the proper licensing internally, and is not included in the binary package, seems OK to me.  I'd still encourage mention in debian/copyright.
<ScottK> Definitely needs mention, but it needn't be repacked then.
<ScottK> yamal: Consider my comment modified to add the copyright and license info to debian/copyright.
<persia> Generally, repacking only makes sense to me if the source cannot be distributed.  As long as the binaries are constructed to be distributable, mixed-license source oughtn't be a problem (although it makes writing debian/copyright annoying and painful)
<persia> (Note that the complete lack of copyright or licensing attribution counts as "source cannot be distributed")
<persia> Err.  "copyright attribution or licensing"
<yamal> ScottK/persia: just a mention of this file, or its complete license and such (for the stuff that isn't included in the package anyway)? In that case just repacking is much easier
<ScottK> yamal: copyright and complete license as it's distributed with the source package.  Please don't repack.  You should only repack when there isn't a reasonable alternative (which there is in this case).
 * yamal cries
<ScottK> The concern I had that lead to my original comment was you can't link Apache and GPL licensed code.  Not an issue in this case.
<persia> yamal: repacking means that we have to trust you.  For that, you'd have to come visit me for a couple weeks, at a minimum.  not repacking is likely easier than that :)
<ScottK> yamal: I think it's just the one file that had the different license.  All license's must be mentioned, but minor copyright holders can be omitted.
<yamal> persia: all you'd have to trust is 3 extra lines in get-orig-source ;)
<yamal> ScottK: these extra templates have lots of different licenses and copyright holders I think
<persia> yamal: Maybe, but still, it breaks the md5sum :(
<ScottK> yamal: Maybe.  The google one was the one that lept out at me.
<yamal> persia: upstream releases a zip file, it's allready modified anyway
<ScottK> yamal: The thing I did to find this is run grep -ir copyright * in the source package.  Try that in the template dir and see how much comes up.  As long as the licenses aren't different, I don't think you need to mention them.
 * persia didn't have enough time during REVU day, and has just advocated a few things.  Second advocates or rejections welcome.
<yamal> smpl/templates/static/MochiKit/Sortable.js isn't any good either. It's copyright header tells the reader to find the full license in another file that isn't there
<yamal> ScottK: that would be undistributable, woudln't it? ^^^
<ScottK> yamal: It would be.  That needs to be removed.
<psicus78> Hi everybody, just a question: isn't version 0.6.5+svn3280 less than 0.6.5+svn3280-0 ?
<persia> psicus78: `dpkg --compare-versions $(new) gt $(old) && true || false` will answer your question better than any of us.
<psicus78> persia: thanks
<persia> psicus78: Oops.  That should be echo true and echo false.
<juliank> ScottK: GPL-2+ and Apache License 2.0 can be linked, as the GPL code can be used under the GPL 3. (Does not apply to GPL 2 only code)
<ScottK> juliank: Agreed.  I didn't check an entire GPL package to make sure it was all GPL 2+.
<ScottK> For one little template file. ...
<ScottK> It's not installed anyway, so it turns out to be a moot point.
<persia> (especially one that isn't used in the build)
<ScottK> persia: New lintian is in Gutsy backports now, so all the whining should be synchronized.
<persia> ScottK2: Great.  Next cycle, let's do that sometime prior to the completion of the last REVU Day :)
 * persia is amus3d by the timing, but agrees it will significantly improve policy compliance analysis for the next 11 weeks
<yamal> is there a _the_ BSD License? thought there was several different licenses using that name?
<persia> yamal: There is a "The BSD License".  You can find a copy in /usr/share/common-licenses/BSD.  It should not be used except by the Regents of the University of California, although there are many derivatives.  For new work, I'd recommend using ISC over BSD.
<vorian> thanks for the ack ScottK :)
<vorian> and being patient with me
<ScottK> vorian: No problem.  Thank you for contributing.
<yamal> persia: it's about files in 'plotkit'. the files all refer to their projects website (http://www.liquidx.net/plotkit/) for the license
<yamal> but all it says there is "PlotKit is copyright (c) 2006 Alastair Tse. Licensed under the BSD License". Seems dangerous to just assume that equals the BSD license in /usr/share/...?
<ScottK> A full copy of the license MUST be included in the package, so you either have to add the license or remove the files.  Since the BSD license says copyright University of California Regents and there is more than one BSD license, there's no way to know what they want by that.
<warp10> Hi all!
<LucidFox> hi warp10
<warp10> hey LucidFox
<effie_jayx> Is there a way of knowing which new files are not in debian/*.install when doing an upgrade?
<effie_jayx> I have tried debuild -us -uc && dh_install --list-missing
<effie_jayx> but it complains about unmet build dependencies. is it necesary then to install them before a pacakge upgrade... isn't there another way?
<slytherin> effie_jayx: unmet dependency means that your machine doesn't have some of the packages needed for building. :-)
<effie_jayx> slytherin,  I understand. but I can't use something like pbuilder to keep all those dependencies separate from my actual sistem?
<effie_jayx> s/sistem/system
<slytherin> effie_jayx: are you using hardy at present?
<effie_jayx> slytherin,  not on this machine
<effie_jayx> I generally build stuff here and take it to my other pc. this one is faster building
<slytherin> effie_jayx: ahh then debuild may not work for you.
<effie_jayx> slytherin,  I must have build dependencies. I got it
<ScottK> effie_jayx: You can use pbuilder login to have a hardy chroot you can do stuff in.
<effie_jayx> ScottK,  but I would need to install the dev tools
<ScottK> Yes, but in the chroot, so it won't affect your system.
<effie_jayx> ok
<effie_jayx> sounds much better
<ScottK> Once you exit the chroot, it all goes away.
<effie_jayx> do a bindmount of the place where I hace the .source..
 * effie_jayx gets to it
<ScottK> Of just use cp from outside the chroot to copy the stuff into the chroot location.
<effie_jayx> in an update of a package if debian/copyright is wrong
<effie_jayx> example the URL for the project has changed
<effie_jayx> how do I change that... I obviously didn't debianize the package... but I should add my modification
<effie_jayx> how can I reflect it?
<dcordero> hi
<ScottK> Mention it in debian/changelog.  That's enough
<emgent> heya
<martoss> what can i do if pbuilder create fails with:
<martoss>  -> installing dummy policy-rc.d
<martoss> E: Malformed line 1 in source list /etc/apt/sources.list (dist)
<martoss> ouch..., my fault :-)
<Ace_NoOne> hi there - say I've got an hour to kill, how could I contribute? where to start?
<slytherin> Ace_NoOne: an hour is not sufficient. :-)
<LucidFox> ScottK, you will probably refuse, but I have two packages that I originally packaged for Ubuntu, perhaps you could sponsor them into Debian? (One of them has been waiting on m.d.n for ages)
<Ace_NoOne> slytherin: I figured - nevertheless, give me some pointers, for the future
<slytherin> Ace_NoOne: just kidding. you may want to confirm some bugs if you are using hardy or review some documentation
<Ace_NoOne> okay, sounds good - is there a to-do list? I suppose there is a ticket system for development-related issues
<ScottK> LucidFox: I'm not a DD.  Sorry (just started NM).
<LucidFox> ah... I was told you were :) never mind then
<slytherin> Ace_NoOne: launchpad.net is the bug tracking system.
<slytherin> what is NM?
<Ace_NoOne> slytherin: thanks - is there a to-do list for documentation issues as well?
<slytherin> Ace_NoOne: #ubuntu-doc is appropriate channel for asking
<Ace_NoOne> ok slytherin, cheers for now
<slytherin> is it a policy that unless 'all' the binary packages related to a source package don't get accepted in 'New' queue, they won't show up on mirrors? I am waiting for latest linux-image-powerpc to fix a booting issue but looks like linux-image-lpia is still waiting for acceptance which is causing other binaries not being uploaded to mirrors.
<geser> slytherin: NM = New Maintainer application in Debian
<geser> slytherin: you mean the linux 2.6.24-6.10 upload? lpia is the only arch were it successfully build
<slytherin> geser: Really? I assumed it built for all arch. :-(
<geser> slytherin: https://edge.launchpad.net/ubuntu/hardy/+source/linux/+builds
<geser> slytherin: one arch in binary NEW should be blocking other moving to the archive
<effie_jayx> ScottK,  I did it. :D but what should I be looking for.. I was specting some list. I have to look through a log?
<slytherin> hmm
<slytherin> funny error - EE: Missing modules (start begging for mercy)
<geser> slytherin: in the case of linux every ABI jump needs to go through binary NEW as the ABI is included in the package name
 * slytherin will be unable to try new kernel on his ibook for few more days. :-(
<slytherin> geser: the problem for linux build looks to be same everywhere - 2 missing modules
<bddebian> Heya gang
<effie_jayx> hey bddebian
<bddebian> Hello effie_jayx
<sistpoty|work> hi bddebian
<geser> Hi bddebian!
<bddebian> Hi sistpoty|work, geser
<dcordero> somebody know can i add add extra repositories to my pbuilder?
<geser> dcordero: the wiki page has it, let me find the url
<tonyyarusso> persia: I should be all set - I'm informed that it should have been done with LP, not REVU, so everything's in line over there now instead.
<geser> dcordero: sorry, I misremembered
<geser> dcordero: try pbuilder --update-config and --other-mirror
<dcordero> geser, ;) thanks
<slytherin> dcordero: you can modify your pbuilderrc and then pbuilder update --override-config
<dcordero> my main problem is that all the changes are not saved :/
<RainCT> Hey
<dcordero> for example, if i update a extra repository then if i login to pbuilder with --login i can check that the souces.list is without my lines :/
<slytherin> dcordero: you mean you do pbuilder login before adding repository or after adding repository?
<dcordero> after of course
<slytherin> dcordero: Did you do - pbuilder update --override-config - after adding repos?
<dcordero> nop
<dcordero> :/
<nxvl_work> dcordero: i have just replied on Bug #177443
<ubotu> Launchpad bug 177443 in photoprint "photoprint should recommend or require icc-profiles package" [Undecided,Confirmed] https://launchpad.net/bugs/177443
<ScottK> dcordero: There is also a save after login option on pbuilder (man pbuilder for the exact syntax).
<uniscript> package versioning question. Is it true that a package in a later distro must have a higher version number than one in an earlier distro otherwise distupgrade won't work?
<dcordero> nxvl_work, ok i understand know, the only problem is that i sent the wrong file. The needed is .debdiff instead diff.gz
<ScottK> uniscript: Yes.  Where won't work means you don't get the right version installed.
<uniscript> OK so I have to build my packages in time distro order then :(
<uniscript> I was hoping to build then reverse time order (going back in time)
<ScottK> That or just number them in reverse order
<uniscript> hmm there is that
<uniscript> OK thanks, even if I didn't like the answer at least I know what i have to do :)
<nxvl_work> dcordero: exactlt
<ScottK> uniscript: When I'm building for a PPA I normally version ~release~ppa1 where release is the name I'm building for.
<nxvl_work> dcordero: exactly
<ScottK> uniscript: Since they're in alphabetical order, that gives you ascending versions through the releases.
<uniscript> yup that's one way, thanks
<ScottK> uniscript: i.e. 1~dapper1~ppa1 is a lower version number than 1~edgy1~ppa1
<dcordero> nxvl_work, ok, thanks for help, i'll sent the correct .debdiff
<uniscript> btw is ~ magic or the same as - ?
<ScottK> It's also the naming scheme we use for backports.
<ScottK> ~ is less than anything else.
<uniscript> so if you use it for backports, shouldn't I use something below that?
<ScottK> So 1~1 is a lower version number than 1
<uniscript> aha
 * sistpoty|work heads home
<sistpoty|work> cya
<ScottK> uniscript: Stick the ppa bit on the end and you're clear of namespace collission
<uniscript> OK. Great. Thanks
<uniscript> so 1~1~1 < 1~1
<jpatrick> yep
<uniscript> hey I can do debianmaths :)
<jpatrick> ScottK: great news on our Debian thing
<ScottK> I agree.  I'ts definite progress.
<geser> uniscript: dpkg --compare-versions 1~1~1 \< 1~1 && echo true || echo false gives true
<uniscript> btw is there a nice script that will take a debian dir and tarball and make me 4 debs (or more)?
<ScottK> jpatrick: We just need to keep the naysayers on our side of the interface under control.
<uniscript> (I have pbuilder, just don't want to type lots of commands)
<jpatrick> ScottK: well, I'm going to keep shoving NEW Kubuntu packages towards them
<ScottK> Excellent.
 * jpatrick goes to join ubuntu-dct
 * uniscript says  thanks and slopes off to bed
<mok0> ScottK: ping
<jpatrick> mok0: yeah, he's around
<ScottK> mok0: Pong - I saw the updated debdiff, but haven't had a chance to look at it yet.
<mok0> ScottK: I hope it's more to your liking :-)
<ScottK> From your description I imagine it will be.
<mok0> ScottK: I also repacked torque's tarball to exclude that postscript file
<ScottK> mok0: OK.  You understand the issue?
<mok0> Yes, I do
<mok0> But I don't think it's what upstream intended
<ScottK> It was interesting to me to discover than grep works on postscript files.  It hadn't ocurred to me that it would.
<mok0> ScottK: well, they are plain ascii files
<ScottK> Agreed, but absent proof, there's nothing we can do.  Maybe you could contact them.
<ScottK> Yeah.  I just hadn't thought about it before.
<mok0> ScottK: I could do that, but I am hoping that the package can pass before feature freeze
<ScottK> mok0: I wasn't thinking about for this upload, but for a future update.
<mok0> ScottK: yes, good idea
<mok0> Who has the final verdict on the license issue?
<jpatrick> archive admins?
<mok0> I'd like to make sure they notice that parts of the license has expired
<jpatrick> best put a note in debian/copyright then
<ScottK> Excellent suggestion.
<mok0> jpatrick: Hmm, I don't want to put my interpretation of the license in copyright. I just want to ping the archive admins
<ScottK> mok0: But you've got a reference that says part of the license is expired.  I think that's not your interpretation, but defacto part of the license.
<mok0> ScottK: Right. It should not be necessary, but several people who have looked at the license missed that fact
<ScottK> I think it's worth adding for clarity.
<mok0> ScottK: Ok
<nxvl_work> dcordero: you also need to "attach" the debian bug report to the LP one
<dcordero> my debdiff size if 1,2 Mb :/
<ScottK> That's fine.
<nxvl_work> dcordero: whats the output of "lsdiff *.debdiff"
<slytherin> time to go home. Bye all. See you tomorrow.
<mok0> ScottK: Should I say then that the license with out pp. 1 and 2 is reminiscent of the BSD license with an advertising clause?
<dcordero> nxvl_work,  /tmp/ files
<ScottK> No.  The thing you need to say about is the parts of the license that no longer apply.  The advertising bit I think is OK.
<nxvl_work> dcordero: pastebin it please
<nxvl_work> dcordero: http://pastebin.com/
<dcordero> nxvl_work, http://pastebin.com/m4da384b6
<nxvl_work> dcordero: something is wrong in there
<nxvl_work> dcordero: how did you build the package?
<dcordero> i have download the package from debian unstable
<dcordero> i have apply my diff.gz to it
<dcordero> i have debuild it
<dcordero> i have download the package from ubuntu
<nxvl_work> mmm
<nxvl_work> that's not the correct way
<emgent> heya nxvl_work :)
<nxvl_work> did you see the wiki link i sent to you?
<nxvl_work> emgent: hi!
<dcordero> not yet
<nxvl_work> dcordero: there is step by step how the merges must be done, give it a look
<dcordero> nxvl_work, ok
<nxvl_work> dcordero: if you don't understand anything just ask :D
<superm1> persia, thats why i said its important to check what patching system the package uses
<superm1> and said that those cases need to be handled differently
<dholbach> does anybody of you use amule?
<dholbach> if so, it'd be nice if somebody took care of bug 189243
<ubotu> Launchpad bug 189243 in libcrypto++ "please sync libcrypto++ 5.5.2-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/189243
<dholbach> (the new libcrypto++ will require amule to be rebuilt / transitioned)
<amarillion> Is anybody going to FOSDEM this year by chance?
<amarillion> http://www.fosdem.org
<nxvl> dholbach: i will take a look :D
<nxvl> when i fix my xorg
<dholbach> nxvl: party on!
<dholbach> :-)
<mathiaz> soren: if Conflicts and Replaces are used at the same time, it means that the old package should be removed.
<mathiaz> soren: in our case, we just want mysql-server to override mysqld.8 from mysql-doc-5.0
<nxvl> dholbach: what is what you are asking for? to do the merge or to prepare amule for that merge?
<soren> mathiaz: Well, Replaces certainly allows mysql-server-5.0 to overwrite the file.
<soren> mathiaz: There's plenty of precedent for doing what I'm suggesting, but I must admit, I can't seem to come up with a really good explanation why the conflict needs to be set.
<soren> mathiaz: Well...
<mathiaz> soren: using Conflicts makes sure that the old version of the package is not installed anymore.
<ScottK> Which would seem appropriate in this case.
<soren> mathiaz: Yeah.. And while it's not *strictly* necessary, you probably want them to be in sync.
<mathiaz> soren: right. At the same time, there is a new package for mysql-doc-5.0 which works well with mysql-server-5.0
<mathiaz> soren: so the two packages should be upgraded correctly.
<mathiaz> soren: I wonder what happens if the restricted repository has been disabled, and Conlicts is not used.
<soren> mathiaz: Then it just overwrites the file from the doc package.
<mathiaz> soren: then the old version mysql-doc-5.0 wouldn't be upgraded and would stay installed.
<soren> Right.
<mathiaz> soren: in this case it wouldn't be a problem.
<mathiaz> soren: with a Conflicts, mysql-doc.5.0 would be removed.
<mathiaz> soren: which is not something that would be expected.
<soren> That's true.
<soren> This is quite a bit of a special case as the file is not just moving between packages, but between components.
<Nightrose> amarillion: yes I know a few who will - why?
<tjaalton> superm1: ooh, project-x! :)
<superm1> tjaalton, yeah we needed it for mytharchive in trunk, but i think everyone wins with that one :)
<mathiaz> soren: so what about using Replaces only and test the upgrade to see if it has the expected outcome ?
<tjaalton> superm1: indeed, I'm happy now that I upgraded my vdr box to hardy :)
<tjaalton> so I can test that
<soren> mathiaz: Sounds good.
<superm1> tjaalton, i dont think in its current form it forces you to use the iced tea jre, so please file bugs related to that if they crop up
<soren> mathiaz: Replaces should be sufficient to kill the bug.
<superm1> (i tested it with iced tea as my jre and things worked)
<tjaalton> superm1: ok, I'll try to find time to test it soon
<mathiaz> zul: do you tackle mysql upgrade problem ?
<mathiaz> zul: only using a Replaces, instead of Replaces+Conflicts ?
<zul> Replaces+Conflicts right now but I can remove the Conflicts after lunch
<mathiaz> zul: were you able to reproduce the upgrade failure ?
<zul> no I guess I didnt have mysql-docs installed
<Riddell> mok0: ping
<mok0> Riddell: pong
<Riddell> mok0: what type of data is wvs1.dat?
<mok0> Riddell: What do you mean?
<Riddell> mok0: well specifically is it a preferred modifyable form
<Riddell> this is in xtide-wvs1-data-20020219
<mok0> Riddell: I don't think it's easily modifiable
<Riddell> mok0: ok, multiverse it is then
<mok0> Riddell: The data is public domain
<Riddell> mok0: right, but it it's not in source form then it's non-free
<mok0> Riddell: how do you define "source form"?
<Riddell> mok0: "preferred modifiable form"
 * mok0 googles 
<mok0> ... and finds nothing of interest...
<Riddell> if it's the format that's used when editing and modifing the data that's source, if it's just a binary blob without source then it's non-free
<Riddell> which is fine, just means it goes into multiverse
<mok0> Riddell: ok, whatever. It's just the non-free part... it's actually not so
<Riddell> without source, it's non free
<Riddell> freedom is about more than just being able to copy it
<mok0> Riddell: OK.
<mok0> Riddell: you can modify it using a program that reads/writes the data file. I don't see why you'd want to modify the world's shorelines though :-)
<mok0> Riddell: I mean, it's _legal_ to modify it
<soren> mok0: Well, if it's modifiable with a particular program, that sounds like it actually *is* in its preferred modifiable form.
<amarillion> Nightrose, well I thought it'd be cool to meet up with the MOTU crowd
<soren> mok0: The question is: Does someone, somewhere have a "source file" of some sort that is used to generate that file or would anyone who wanted to edit that file prefer to edit that file directly (with whatever program)?
<mok0> soren: I just found something
<mok0> You can get the data in ascii format
<Nightrose> amarillion: come to R!ddelÂ´s packaging session then ;-)
<mok0> http://rimmer.ngdc.noaa.gov/mgg/coast/getcoast.html
<amarillion> ah cool, I didn't see that in the schedule
<amarillion> yet
<amarillion> I'll be there :)
<soren> mok0: It's like.. If you have a package that has some pre-rendered graphics in it, but you don't have the povray source (or whatever it's made in), but you have the graphics itself, then even though you can edit the images directly with the gimp or whatever, the "preferred modifiable form" is the povray source.
<mok0> soren: Ok, makes sense.
<mok0> soren: I think Riddell went off  to upload the data to multiverse...
<soren> Riddell: Are you reading this?
<ScottK> mok0: Well if you can add the ascii form to a updated package, then it can be moved.
<mok0> ScottK: That would be a bit silly
<ScottK> Why?
<soren> mok0: The question you need to ask yourself is:
<ScottK> What is the preferred form to edit the data?
<mok0> ScottK: Because -- users would not need it, really.
<soren> If you wanted to edit those data, would you be making changes directly to that file with whatever program is needed to do so, or would you prefer to edit it somewhere else and then generate that file.
<ScottK> mok0: But that's nothing to do with the point.
<soren> If the former, then everything is good. It doesn't have to be clear text if that's not the preferred form for editing it.
<mok0> ScottK: Well, we'd be having a package with data that nobody cares about
<Riddell> mok0: yes, I accepted into multiverse
<mok0> Riddell: thx
<Riddell> soren: it would still need a way to compile one into the other
<soren> Riddell: Yes.
<soren> Riddell: I was just getting to that bit :)
<mok0> Riddell: the ascii source is available, it even has instructions on how to use it in matlab
<soren> It wouldn't help to just *also* ship the ASCII version if it's not what the program uses.
<mok0> soren: exactly. you need some way to "compile" it
<soren> Precisely.
<soren> Otherwise, it's not really the preferred modifiable form.
<soren> It just looks like it to the untrained eye.
<soren> "Hey, it's ASCII. It must be what I'm supposed to edit."
<Riddell> suggesting that users would not need source code is unlikely to go down well in a free software project
<soren> GIF's can be turned into postscript, which is ASCII, but I'd sure prefer to edit GIF's to edit the resulting postscript.
<mok0> Riddell: Until global warming really gets going, I doubt that anyone would want to edit the shoreline data :-)
<soren> mok0: They might.
<soren> mok0: For experimenting or whatever.
<mok0> I settle for non-free :-)
<mok0> those 2 people can get the data in ascii form from the web
<mok0> Riddell: Are Jave class files "non-free"??
<mok0> Java
<Riddell> mok0: yes of course
<mok0> Riddell: you can generate the .java code from them with a program
<soren> mok0: If you wanted to edit them, any sane person would prefer to edit the .java file.
<Riddell> if you have the source then that's fine
<soren> mok0: That's all that counts.
<LucidFox> mok0> You can generate source code from .NET assemblies as well
<Riddell> ..and the build system and a free compiler
<LucidFox> that doesn't make them free
<soren> that's completely beside the point.
<mok0> so, what matters is the _format_?
<soren> YEs.
<soren> I can disassemble the linux kernel, too, and fiddle around with a hex editor, but I'd by far prefer to edit the C source code.
<mok0> soren: that's not the same thing as with java, though
<mok0> soren: I think all that's lost in the disassembly of .class files is the comments
<soren> mok0: Not completely, but for the sake of this argument, the analogy is sound.
<mok0> soren: your povray example was different, though
<soren> I realise.
<soren> What matters is the format any sane person would prefer to work with.
<mok0> soren: I understand.
<mok0> But you still have the _freedom_ to reformat and edit
<soren> I've come across people who get a kick out of editing java byte code. They're clearly insane and not interesting in this discussion :)
 * soren -> cook dinner
<mok0> soren: you don't need to. you can disassemle byte code into perfectly understandable java source code
<mok0> assemble
<mok0> Even has the same variable names
<mok0> soren, btw, the mac_addr trick solved my kvm problems completely! We have now deployed a couple of virtual servers in testing for production!
<ScottK> Any xubuntu folks here?
<jeromeg> yep
<ScottK2> jeromeg: Do you know janimo?
<jeromeg> ScottK2: jani monoses ?
<ScottK2> Yes
<jeromeg> ScottK2: the one that modifies our seeds
<jeromeg> :)
<ScottK2> From reading hardy-changes it looks like she's uploading her Sugar packages with -1 versions instead of -0ubuntu1 and they aren't from Debian.  Someone ought to mention this to her.
<ScottK2> jeromeg: ^^
<Riddell> possible gender realignment
<ScottK2> OK.
<ScottK2> Her/His
<ScottK2> Sorry
<Riddell> ScottK2: I've just had this conversation with him on ubuntu-archive
<ScottK2> OK.  Good.  Nevermind then jeromeg.
<Riddell> alas I let through a couple before I noticed
<jeromeg> ScottK2: ok
<jeromeg> got to go
<jeromeg> bye
<gpocentek> ScottK2: the sugar packages are not related to Xubuntu in fact :)
<gpocentek> unless he changed this without any warning
<ScottK2> OK.
<ScottK2> My mistake about that then.
<ScottK2> Thanks.
<gpocentek> no problem
<mok0> Riddell: xtide-data should be moved to multiverse, then
<mruiz> for new upstream versions, should I attach to the bug the interdiff only?
<mok0> mruiz: as I understand it, it has to be the diff.gz
<mruiz> mok0, I asked weeks ago and it's under discussion...
<mok0> mruiz: look in the minutes of last MOTU meeting
<mruiz> thanks mok0 ... I'll do it
<ScottK> mruiz and mok0: diff.gz
<mok0> mruiz: they decided against the interdiff
<mok0> ah, there you go :)
<ScottK> BTW, you don't have to be an actual MOTU to come to the meetings and discuss.
<mruiz> ScottK, I forgot it :-(
<mok0> ScottK: xtide-data also contains binary data, so cf. discussion above, it should be moved to multiverse
<mok0> ... and then it would make sense to move xtide there as well
<ScottK> Which is then a discussion point for you with upstream about wouldn't they like it to be Free so more people could use it.
<ScottK> No
<ScottK> Not unless it's a hard dependency
<mok0> ScottK: Let me check
<mok0> ScottK: but xtide is useless without the data
<ScottK> Hmm.
<ScottK> Note sure.
<ScottK> Can the data be gotten elsewhere?
<mok0> I don't know off-hand
<ScottK2> I'm not sure what the right answer is then.
<ScottK2> I'd ask Riddell.
<jdong> well.. you can'
<jdong> err
<mok0> ScottK; he's off at the moment
<jdong> you can't depend on the multiverse -data package anyway, right?
<jdong> unless you want to just "make up" a virtual package
<jdong> which sounds shady
<mok0> xtide recommends: xtide-data
<jdong> well a recommends is fine
<jdong> does the program do anything at all without its -data?
<mok0> jdong: no, not really
<jdong> :-/
<mok0> jdong: it doesn't crash
<jdong> technically I think the "right answer" is the engine goes in universe and the data goes in multiverse
<jdong> but it's kinda silly to me until there's actually a free -data alternative
<mok0> jdong: well, that's the consequence of the rules
<mok0> jdong: the data _is_ free, it
<mok0> is in the public domain
<jdong> then why does it go into multiverse?
<mok0> jdong: but it is in binary form
<jdong> well... what kind of data are we talking about?
<mok0> jdong: "non-preferred modifiable format"
<jdong> like images or sounds?
<mok0> jdong: some of it is "harmonics data"
<mok0> the program uses it to predict the tide at any given time
<jdong> well ScottK2 is right, this seems like something to talk to an archive admin about
<mok0> jdong: I did
<mok0> jdong: I packaged the shore-line data, that shows a map of the world on xtide's display, and it must go in multiverse because it is binary
<mok0> jdong: I then discovered, that xtide-data, which is in universe, also contains binary data.
<mok0> jdong: so, consequently, it should be moved as well
<ScottK2> jdong: I'm testing for a postgresql 8.3 backport now.  So far Gutsy and Feisty look good.
<jdong> ScottK2: cool
<rulus> If somebody has time to review my package (http://revu.ubuntuwire.com/details.py?package=gtkvd) that would be great. I'd really like to have it in for Hardy. Thanks :)
<jdong> jussi01: are you still looking for work to do? I've got a really simple favor to ask
<jussi01> jdong: ask!
<jussi01> !ask | jdong
<ubotu> jdong: Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
<jussi01> ;P
<jdong> jussi01: file a sync request for bzr-svn from Sid
<jdong> please and thank you and all that stuff
<jussi01> jdong: ok, sure :D
<jdong> now I've got to get to class :)
<jussi01> see ya
<Riddell> ScottK2, mok0: xtide doesn't seem to depend on xtide-data
<mok0> Riddell: No, it's recommended
<mok0> Riddell: but it also contains binary data
<Riddell> meh
<mok0> Riddell: you started this ;-)
<Riddell> mok0: I don't see any binary data in xtide source
<mok0> Riddell: Go down in the file
<Riddell> mok0: pardon?
<mok0> Riddell: near the top of the file, a bunch of string data is stored. Further down in the file there are binary numbers
<Riddell> mok0: are you talking about xtide or xtide-data?
<mok0> xtide-data
<Riddell> right, I already put that into multiverse
<mok0> Riddell: the file  harmonics-dwf-20070318-free.tcd
<cbx33> hey all what's the last date I can submit bug fixes to universe?
<Riddell> cbx33: a few days before release
<cbx33> Riddell, which is when?
<cbx33> ;)
<Riddell> well universe, up until release
<Riddell> !release
<cbx33> ok
<cbx33> great
<ubotu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
<mok0> Riddell: Can you take care of bug 188093 at the same time?
<ubotu> Launchpad bug 188093 in xtide-data "[needs-sync] xtide-data-20070318-1 from sid" [Undecided,New] https://launchpad.net/bugs/188093
<jussi01> when using request sync, do I need to include the version, and if so, what is the syntax?
<pochu> jussi01: not neccesarily. Only if requestsync fails to autodetect it.
<jussi01> pochu: ok, thanks
<pochu> jussi01: requestsync --help (or requestsync(1) ) will tell you the syntax, in case you need to specify it
<jussi01> pochu: ahh, great, thanks
<jussi01> hmmm, however Im getting this error: The environment variable DEBEMAIL needs to be set to make use of this script.
<pochu> jussi01: set it :)
<jpatrick> jussi01: put: "export DEBEMAIL=you@mail.com" into .bashrc
<jussi01> jpatrick: thanks
<jcfp> any revu admins around? please resync the key ring
<jpatrick> jussi01: https://wiki.kubuntu.org/SyncRequestProcess
<geser> jpatrick: the other sync :)
<jussi01> jpatrick: Im there...
<jpatrick> geser: ah, sorry
<geser> jpatrick: sorry, to many different sync requests in the last few lines
<RainCT> persia: ^
<geser> jpatrick: I've seen jcfp requesting a keyring sync and you answering with a wiki page without checking the nicks
<jpatrick> geser: what? My msg was for jussi01
<geser> exactly
<geser> my error
<jpatrick> err
<jussi01> jpatrick: still giving me the error... :(
 * jpatrick pours coffee for himself and geser 
<jpatrick> jussi01: restart the konsole session
<jussi01> aye
<geser> ". .bashrc" would also work
<jussi01> jpatrick: bug filed :)
 * RainCT would be happy if someone reviewed http://rainct.homelinux.net/openbox_3.4.6-0ubuntu1.dsc :)
<mok0> Riddell: ping?
<Riddell> hi mok0
<mok0> Riddell: did you see the message about bug 188093?
<ubotu> Launchpad bug 188093 in xtide-data "[needs-sync] xtide-data-20070318-1 from sid" [Undecided,New] https://launchpad.net/bugs/188093
<Riddell> mok0: yes, but I'm busy on other archive bits just now
<mok0> Riddell: OK, fine, I just wanted to make sure that you didn't miss it
<jussi01> jdong: when you come back from class, bug 189361
<ubotu> Launchpad bug 189361 in bzr-svn "Please sync bzr-svn 0.4.7-1  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/189361
<firestormx37> i would like to get involved by helping out with packaging or bugs, can anyone help me get started.  I have read a lot of the guides and faqs on the wiki, but I am not sure where to start.  I'm looking for something easy to start with.
<cbx33> hey guys
<cbx33> if I have a pacakge called memaker-themes
<cbx33> and it's version is 0.1.1
<cbx33> and i set it at 0ubuntu1
<cbx33> what should the orig.tar.gz call
<jussi01> firestormx37: I assume you have looked at /topic ?
<cbx33> cos debuild is complaining
<firestormx37> no. i'm sorry what is that
<cbx33> (expected memaker_0.1.1.orig.tar.gz or memaker-themes-0.1.1-0ubuntu1.orig)
<jpatrick> cbx33: memaker-themes_0.1.1.orig.tar.gz
<mruiz> ff3 will be the default browser for Hardy?
<jussi01> firestormx37: type: /topic into your irc client ;)
<cbx33> jpatrick, that's what I thought
<cbx33> but it doesn't like it
<cbx33> as you can see
<fdoving> cbx33: it depends on the name you set in debian/control - for the source package.
<cbx33> Source: memaker-themes
<fdoving> cbx33: you can have a memaker-theme binary package, coming from a memaker_0.1.1.orig.tar.gz source.
<ScottK2> mruiz: Yes
<cbx33> fdoving,
<ScottK2> For Ubuntu
<cbx33> yes this will produce multipkle binaries
<cbx33> but it's just not picking up the source pacakge
<cbx33> source tar sorry
<firestormx37> jussi01, if you are talking about the wiki site listed there, then yes I have read them, but i'm still not sure how to get started
<mruiz> thanks ScottK2 ... then firefox as depends should be replaced by firefox3
<vemon> does it make sense to create a get-orig-source rule (when there is a need to repack) which uses uscan to get the source?
<vemon> that feels a little stupid if what's wanted is really the original source (and not the newest) for the package
<cbx33> fdoving, ??
<vemon> refering to: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
<fdoving> cbx33: give debuild what it expects, (expected memaker_0.1.1.orig.tar.gz or memaker-themes-0.1.1-0ubuntu1.orig)
<cbx33> ko
<cbx33> it can't have the former
<cbx33> that's in use
<fdoving> cbx33: as the latter is a directory, which i personally rarely use directly, i'd go fo memaker_0.1.1.orig.tar.gz
<mok0> ScottK: Is the new debhelper being backported?
<ScottK2> mruiz: Not replaced.  I'd do firefox-3.0 | firefox
<cbx33> fdoving, but that presents a bit of a problem
<ScottK2> As I understand it firefox will still be in Universe
<cbx33> as I already have a memaker_0.9.4.orig.tar.gz
<fdoving> cbx33: you should use the same orig.tar.gz, then only thing that changes once you add your 0ubuntu1 changes, is the .diff.gz
<cbx33> well......the themes pacakge is going to be totally seperate
<cbx33> at the mo it's not going into univers
<cbx33> just into a ppa
<fdoving> if it's going to be totaly separate you need to edit debian/control and set the source name to something new, memaker is taken.
<fdoving> memaker-themes
<fdoving> for example.
<cbx33> ^^^ I did
<cbx33> Source: memaker-themes
<fdoving> then debuild should expect memaker-themes_0.1.1.orig.tar.gz
<cbx33> yeh
<cbx33> but it doesn't
<cbx33> the only thing that could be causing the problem is the directory it's in
<cbx33> memaker-themes-0.1.1-0ubuntu1
<cbx33> is that wrong?
<fdoving> no. that doesn't really matter.
<fdoving> debuild will figure that out.
<cbx33> is it because of the 0ubuntu1 perhaps?
<Coper> Can a MOTU review my new package http://revu.ubuntuwire.com/details.py?package=console-freecell
<cbx33> ok why the heck isn't this working
<jpatrick> cbx33: call the dir memaker-themes-0.1.1
<cbx33> ahhh got it
<cbx33> i think
<cbx33> changelog
 * RainCT would be happy if someone reviewed http://rainct.homelinux.net/openbox_3.4.6-0ubuntu1.dsc :)
<ScottK2> RainCT: Please put it on REVU if you want it reviewed.
<jpatrick> RainCT: that's twice today
<mruiz> hahaha
 * RainCT decides he will just upload it
<dcordero> hi
<RainCT> Hi dcordero
<dcordero> i am fully lost with merging process pfff
<RainCT> dcordero: what's the problem?
<dcordero> i have read 4 times the wiki about merging :)
<dcordero> my packages it isn't on Mom
<RainCT> heh
<RainCT> the MoM time is over (until Hardy+1's cycle starts)
<dcordero> so, i cant merge?
<RainCT> you can, just without MoM (well, or you might be able to still use it, but it isn't needed anyway)
<dcordero> and his husband Dad dead too?
<RainCT> to do a merge basically you just need to dget the source from Debian that you want to merge (you'll find a link to the .dsc in packages.debian.org), unextract it (dpkg-source -x *.dsc)
<dcordero> grab-merge only do that?
<mok0> dcordero: http://dad.dunnewind.net/universe.php
<mok0> ubotu, ! dad
<ubotu> Sorry, I don't know anything about dad - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<mok0> ubotu, ! merge
<ubotu> Sorry, I don't know anything about merge - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<dcordero> mok0, i know dad
<mok0> dcordero: then why don't you just use the grab-merge.sh tool that's there?
<RainCT> then get the source from Ubuntu too, copy the text from Ubuntu's changelog into Debian's (only leave the new entries at the top but replace all others)
<RainCT> (well, or get the changelog from packages.ubuntu.com if you don't need Ubuntu's source)
<mok0> RainCT:  grab-merge gets all that stuff in 1 go
<RainCT> and then apply the changes you want to Debian's source, add a changelog entry and ready
<dcordero> mok0, my package dont appear on Dad, that is the problem
<RainCT> mok0: yes, but I don't like it :P
<mok0> Ah, you guys!! :-P
<RainCT> as it modifies the unextracted source, I always delete it an unextract again (just keeping the changelog) :P
<RainCT> but on this case dcordero said that the package isn't on DaD anyway
<dcordero> RainCT, ok i understood it's exactly how i did it, but i deleted the ubuntu changelog and used debian changelog only
<gilir> hi, there is some admin of REVU around here ?
<RainCT> dcordero: ok, then you just need to replace the changelog with Ubuntu's + new entries in Debian's, so that the entries that are only in Ubuntu's changelog are conserved
<dcordero> and then the debdiff between dsc from debian and the new dsc or between the old dsc from ubuntu and the new dsc generated?
<mruiz> bye all
<RainCT> dcordero: between the 'old' Debian and your new one
<dcordero> ok, i understand now, thanks
<RainCT> np :)
<RainCT> mok0: ah, and explaining what the process actually is is also better for new people than just using a script doing magic (except if it is CDBS) :D
<mok0> RainCT: true. In fact, I don't know myself what most of the diffs are, that grab-merge creates :-)
<gilir> I am the only one who have a nice error in REVU ? :) http://revu.tauware.de/details.py?package=awn-extras-applets
<blueyed> RainCT: I've addressed your comments in http://revu.ubuntuwire.com/details.py?package=jedit - can you look at it again, please?
<RainCT> gilir: me too
<gilir> RainCT: thanks :) is it possible to contact the admin of REVU ?
<blueyed> siretart: can you look at why the package(s) is/are broken? ^^
<RainCT> gilir: I'd try re-uploading it first. I guess the people in group https://launchpad.net/~revu-hackers are probably all admins (I only know sistpoty who isn't online atm)
<blueyed> See https://wiki.ubuntu.com/MOTU/Packages/REVU for a full list of them
<RainCT> blueyed: sorry, dinner. I don't remember how good I checked it last time but I don't think that I could find much more :)
<blueyed> RainCT: you might want to advocate it then.. the only "critical" part is debian/copyright IMHO.
<dcordero> only 4,5K my debdiff?
<dcordero> i read in the wiki that be a lot of weight file
<dcordero> should be
<RainCT> Coper: console-freecell looks pretty ok, I'll finish checking it later (haven't looked at the binary yet). (Until now the only "issue" that I could find is that you don't need the comments on the top of debian/rules, but that has no importance so don't re-uploaded unless there's some other problem) :)
<RainCT> dcordero: no, 4,5 is probably ok
<dcordero> ok, i'll sent it to launchpad, my 4 sent :) ufff
<dcordero> 4Âº
<ScottK2> Coper: I'm looking at it now too.
<ScottK2> Coper: See my comment on REVU
<gilir> RainCT: thanks :)
<blueyed> protonchris: are you still looking for something to fix? (just read your mail) I'd say that there should be plenty of things available.
<blueyed> See e.g. https://wiki.ubuntu.com/MOTU/TODO or bugs tagged "bitesize"
<paas> RainCT: Hi, I've fixed the lintian errors/warnings and uploaded a new package, cheers
<cbx33> hey guys
<cbx33> when publishing to a PAA
<cbx33> PPA
<cbx33> how long till my source package gets built?
<blueyed> cbx33: depends on the queue.. (which you cannot see unfortunately)
<jdong> bug 189361
<ubotu> Launchpad bug 189361 in bzr-svn "Please sync bzr-svn 0.4.7-1  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/189361
<jdong> cool
<cbx33> ahhh ok blueyed thought as much
<ScottK2> Coper: Two easy changes and I'll advocate.  Ping me on IRC when you get them fixed.
<ScottK2> It's a nice little game.
<blueyed> jdong: are you working on the bug? I can confirm that it builds in Hardy.
<jdong> blueyed: I asked jussi01 to do that for me
<jdong> wait aren't syncs supposed to be subscribing the archive admin?
<ScottK2> Yes
<blueyed> yes, they need to get ACKed and subscribed then
<jdong> ok,
<jdong> subscribed or assigned?
<ScottK2> subscribed
<jdong> excellent
<jdong> someone on u-m-s can de-subscribe them
<jdong> u-u-s rather
<RainCT> blueyed: count a +1 from me then if this makes you happy :)
<RainCT> blueyed: well, I think I'm even going to check it again :)
<jussi01> jdong: all good with that bug?
<RainCT> paas: cool, can you give me a URL?
<siretart> blueyed: look at what?
<jdong> jussi01: yep, I've acked and subscribed -archive
<jdong> jussi01: thanks for your help!
<paas> RainCT: http://revu.tauware.de/details.py?package=libtuxcap
<jussi01> jdong: np :) I learnt how to use requestsync so that was good:)
<jdong> sweet
<effie_jayx> persia,  ping
<jdong> I've always done them manually :D
<jussi01> jdong: that makes it extra easy :D
<siretart> blueyed: please consider advising people to use https://answers.launchpad.net/revu/+addquestion
<jdong> Anyone know where bluekuja has been recently?
<RainCT> paas: please use a patch system for those changes in the source, especially considering that you are using CDBS (so you just need to add 1 line to debian/rules to set it up)
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<paas> RainCT: ok, will look into it right away
<RainCT> paas: $ man cdbs-edit-patch   will help
<jdong> RainCT: simple-patchsys is beautiful :)
<RainCT> jdong: yehhh :)
 * jdong shudders at memories of adding a patch to quilt
<RainCT> hehe
<RainCT> or even dpatch (well, not using it, but adding it to debian/rules)
<ScottK2> I've been meaning to ask ...
<blueyed> jdong: I've unsubscribed u-u-s from the bug..
<blueyed> siretart: <gilir> I am the only one who have a nice error in REVU ? :) http://revu.tauware.de/details.py?package=awn-extras-applets
<blueyed> jdong: quilt is not that easy, yes, but I think dpatch is the best.. e.g. when disabling some patch.
<ScottK2> In cdbs-edit-patch and dpatch-edit-patch I can fire them up, throw a patch diff at the source in the chroot, exit and I'm done (modulo editing 00list and dpatch comments).  Is there an equivalent workflow for quilt?
<blueyed> ScottK2: I've not found one..
<ScottK2> I was afraid of that
<siretart> blueyed: looks like someone (read sistpoty or me) has done a cleanup and removed the directory because of disk shortage. I haven't done such a cleanup recently, so best to ask sistpoty here
<blueyed> siretart: so re-uploading would fix it?
<siretart> blueyed: very likely
<blueyed> gilir, please re-upload your package (see above).
<gilir> blueyed: ok thanks :)
<jcfp> siretart: could you sync the revu keyring please?
<effie_jayx> I may have made a mistake and posted the wrong debdiff :S
<effie_jayx> what can I do... just upload the right one?
<blueyed> Does somebody know why icedtea-java-7 got rejected from Debian NEW? I could not find any mailinglist where those reasons would get posted.
<blueyed> effie_jayx: yes, and then delete the wrong one.
<blueyed> Wow.. dholbach's sets are really great :)
<effie_jayx> blueyed,  thanks...
<effie_jayx> blueyed,  where can I erase the old attachment?
<blueyed> see the attachments section, click edit, click delete (or thelike)
<gilir> blueyed , siretart : same error, with a different upload number :) http://revu.tauware.de/details.py?package=awn-extras-applets
<vemon> should the upstream changelog be installed with a package if it contains only technical stuff?
<vemon> (which it actually should contain)
<geser> blueyed: afaik only the uploaded/maintainer gets the rejected mail. My guess is it that it didn't match the dfsg.
<vemon> if i've understood correctly the NEWS file would be the one to install if one would exist..?
<blueyed> geser: too bad.. those rejections should be more public.. and it's also bad that it got rejected, of coure.
<blueyed> +s
<blueyed> vemon: yes, the upstream changelog often contains technical/detailed data, which should be made available.
<ScottK2> vemon: I'd install them both
<vemon> ok. thanks!
<blueyed> Is there some guide to setup revu for local testing/development? :)
<blueyed> ..seems to be difficult, but I want to make some (minor) UI improvements, and like to test them..
<effie_jayx> how do I remove a patch in simple-patchsys
<effie_jayx> ?
<jpatrick> effie_jayx: delete the .diff
<effie_jayx> jpatrick,  won't it complain at build time?
<jpatrick> effie_jayx: shouldn't
<effie_jayx> jpatrick,  mkkey
<geser> blueyed: IIRC someone setup a second copy of revu somewhere on ubuntuwire.com (or perhaps somewhere else). I'm not sure if it was Fujitsu or someone else. Perhaps #ubuntuwire can help.
<geser> effie_jayx: simple-patchsys applies all patches it can find in debian/patches
<ScottK2> blueyed: Talk to imbrandon
<blueyed> effie_jayx: you can rename it to something != .diff or .patch probably, too.
<blueyed> geser, ScottK2: I prefer to develop on localhost.. :)
<effie_jayx> If I did a patch and the package got uploaded. now I need to fix soemthing I have to change it in a new patch right?
<blueyed> effie_jayx: patch=debdiff?
<ScottK2> blueyed: REVU is non-trivial to set up.  It has a lot of hard coded paths and other painful elements.
<blueyed> effie_jayx: you can also adjust your patch in a new debdiff
<blueyed> ScottK2: sounds awful.. but I expected it anyway.
<ScottK2> Source is on Launchpad.
<effie_jayx> blueyed,  all I need is to fix some Line I erased ... I have to edit the patch or make a new one... then generate a new debdiff
<geser> blueyed: they could help you to set it up on your localhost
 * effie_jayx goes for the fix
<dcordero> nxvl_work, i has answer you on Bug #177443
<ubotu> Launchpad bug 177443 in photoprint "photoprint should recommend or require icc-profiles package" [Undecided,Confirmed] https://launchpad.net/bugs/177443
<jdong> blueyed: thanks for unsubscribing; and yeah dpatch is arguably almost as easy to use as cdbs's patchsys, and I like dpatch's comments and disabling abilities
<jdong> mainly the comments
<vemon> is the copyright of the packaging scripts really necessary in debian/copyright?
<vemon> haven't seen that in any package yet
<paas> RainCT: I'm now using the patch system and have uploaded a new version. http://revu.tauware.de/details.py?package=libtuxcap
<DktrKranz> blueyed, are you still interested in bug 158252?
<ubotu> Launchpad bug 158252 in dspam "dspam won't start:  /var/run/dspam missing in tmpfs" [Medium,Confirmed] https://launchpad.net/bugs/158252
<RainCT> paas: it seems like you are still modifying 2 files (CMakeLists.txt) without patch system
<RainCT> well, gonna go
<RainCT> good night :)
<paas> good night
<nxvl_work> dcordero: replied :D
<CyberMatt> http://revu.tauware.de/details.py?package=jailkit the latest motu comment is inalid i repacked the tarball because of a flawed upstream debian/
<CyberMatt> directory
<somerville32> CyberMatt: I don't think it is invalid.
<CyberMatt> why not repack the upstream tarball mark it with repackedx
<RAOF> CyberMatt: Because the source package, as you have provided it, is invalid.
<CyberMatt> hmm vailidate for me
<RAOF> CyberMatt: Easy steps to reproduce: download the files you've posted to revu into a new directory.  Try to run dpkg-source -x *.dsc, and it fails.
<CyberMatt> hmmm why is it doing that
<dcordero> nxvl_work,  replied :D
<CyberMatt> i can reup with a note in the changelog
<RAOF> Because your tarball has an invalid name: you actually want to change the package _version_ to "2.5+repack-0ubuntu1", so your .orig.tar.gz can be called _2.5+repack.orig.tar.gz
<CyberMatt> oh shoot
 * CyberMatt should have seen
<RAOF> When you repack you have to change the version number, too :)
<CyberMatt> D'oh
<RAOF> CyberMatt: Additionally, since you've repacked the original tarball, I'd add a get-orig-source target to debian/rules to show what you've done in the repack.
<CyberMatt> mmm maybe all idid was rn -rf debian/
<CyberMatt> and re-debianize
<RAOF> CyberMatt: Even so.
<RAOF> You should probably add a watch file, too.
<somerville32> CyberMatt: keyword is "maybe"
<nxvl_work> dcordero: in a quick look it seems ok now, let's wait for a sponsor to check it :D
<CyberMatt> g-o-s is a big pain and its also abuse of make
<dcordero> nxvl_work, wooo :D
<RAOF> CyberMatt: I dispute both those points.  If all you've done is rm -rf debian, it's trivial (even more so if you add a watch file).  In what way is it an abuse of make?
<dcordero> nxvl_work, was hard for me haha
<nxvl_work> dcordero: thats on the first times, then it would be easy
<nxvl_work> dcordero: i promise
<dcordero> i hope
<dcordero> :)
<nxvl_work> dcordero: why don't you ask for a mentor?
<nxvl_work> dcordero: it makes things easiest
<nxvl_work> dcordero: https://wiki.ubuntu.com/MOTU/Mentoring/Contributor
<CyberMatt> what we should do with g-o-s is do another maintainer script that can be called by the user much more effective
<RAOF> CyberMatt: What's so hard about "debian/rules get-orig-source".  That's user-callable.
<dcordero> nxvl_work, yep i think that i should do it
<CyberMatt> not hard i just don't like anything in a makefile that doesn't need to be in a makefile
<CyberMatt> just IMHO ill do it
<ion_> Why is that?
<CyberMatt> make launching wget seems creepy but i'm paranoid  :)
<ion_> ...
<ion_> Does sh launching wget seem creepy? How about the operating system launching wget? Or the computer launching wget?
<CyberMatt> don't ask me to explain logical paranoia is somewhat of an oxymoron
#ubuntu-motu 2008-02-06
<CyberMatt> i just don't like the idea of make connecting out
<jcfp> Just read above that when repacking the upstream tarball, one needs to rename. Is there any guidelines as to what to add to the version; I'm seeing "repack" mentioned here, "dsfg" or so on some package out there... does it somehow depend on the changes made?
<CyberMatt> don't know why i don;t i just don't
<CyberMatt> i removed the upstream debian/ it had problems
<CyberMatt> but if a g-o-s is needed it will get done
<CyberMatt> i just a) don't like it b) want to keep my rules as uncomplex as possible
<RAOF> jcfp: Yes.  "dsfg" indicates that files which are not compatible with the Debian Free Software Guidelines have been removed.  "repack" is a bit more general; in this case it's because upstream ships a debian/ directory themselves.
<CyberMatt> gotta go vote
<jcfp> RAOF: so unless I'm certain all the not-completely-free-by-debian-strict-interpretation stuff has been removed, "repack" is the way to go
<RAOF> jcfp: If there's stuff that isn't completely-free-by-debian-standards, it's not going to go in the archives at all.
<CyberMatt> unless in contrib or non-free
<StevenK> We don't have the concept of contrib, as it were
<RAOF> It's just a guideline.  If you're removing stuff to make it acceptable for the archives, repack it as dfsg.
<CyberMatt> but who uses those execcpt to get flash nvidia carq and dvd + codecs
<jcfp> what if upstream release includes a directory with some windows binaries. remove? keep only those that are foss licensed and include source in the tarball?
<jcfp> and what with those binaries in a release that dont come with the source but are under, say, gpl
<RAOF> jcfp: I'm not sure.  I'd be tempted to remove anything not built from source, but if they're windows binaries...
<RAOF> jcfp: If they're released under the GPL, we need to provide source.  Which should be in the source package :)
<jcfp> RAOF: so in any case, of those files only the ones that are gpl-or-compatible licensed AND have their source included in the upstream release may even be kept?
<jcfp> when repacking, that is
<RAOF> jcfp: I'm not experienced enough on the debian-legal side, and I haven't read the DFSG recently.  My feeling would be "if it's not built from source that exists in the source package, it shouldn't be there"
<jcfp> RAOF: thanks, i'll just copy that feeling ;)
<imbrandon_> eww why would someone put binarys of any kind ( let alone windows ) in a source release tar
<imbrandon_> seems creepy
<RAOF> imbrandon_: When they're distributing mono libraries?
<imbrandon_> RAOF: and ... ? they can be built just the same
<RAOF> It's pretty creepy, but it's not terribly uncommon.
<jcfp> imbrandon_: a python program... with win32 helper binaries; it's about sabnzbdplus on revu
<RAOF> imbrandon_: Yeah, but unlike, say, C code the mono .dll binaries can be run anywhere.
<imbrandon_> jcfp: i can understand that in a win32 binary download tar , but not a source tar
 * jcfp isn't in control of upstream releasing habits
<imbrandon_> RAOF: sure, but thats not the point, ELF can run on non linux too under certain cercumstances, but WHY
<RAOF> imbrandon_: Well, in the case that I'm thinking of (Tao), it's because the build system was a stone cold bitch.
<imbrandon_> jcfp: sure, totaly understandable, but you can ask/influence them :)
<RAOF> And it was a lot of effort to actually build the damn thing (if you even could).  And they weren't really meant to be installed system-wide, either.
<imbrandon_> :P
<jcfp> imbrandon_: if time wasn't running out for getting things in hardy, I'd concentrate my efforts with them.
<jcfp> but now... :(
<imbrandon_> well if they wernt built from the source thats in the source tar then no dont include them
<imbrandon_> bottom line
<imbrandon_> but better to get upstream to remove them, for *now* you can repack dfsg
<imbrandon_> etc etc etc
<jcfp> ok than i'll do that. remove all but those who include source AND are gpl-or-compatible licensed
<jcfp> I guess it wouldn't be okay to just remove things on the basis that they're not needed?
<imbrandon_> not really
<jcfp> e.g. I really need a (licensing or copyright related) excuse
<imbrandon_> but you can not install them :)
<imbrandon_> note installing them and not including them in the source is totaly diffrent :)
<imbrandon_> s/note/not
<imbrandon_> its a tad devious but its not uncommon
<jcfp> I always fear that reviewer coming by saying I deleted to much/not enough/etc
<imbrandon_> when repacking a tar change as little as humanly possible
<imbrandon_> thats the rule of thumb
<imbrandon_> but say there is something in the source that upstream includes that you dont really want, you simply leave it in the source but dont install it via the deb
<imbrandon_> see what i mean ?
<jcfp> imbrandon_: sabnzbdplus contains two extra interface templates (couple of dozen files each) that have a small number of files that have improper licensing
<imbrandon_> inproper lic is not "i dont want" that needs to be fixed/removed
<jcfp> following this; I end up deleting only those specific files, leaving the rest
<imbrandon_> "i dont want" == <blah> builds two plugins i dont want to support so i'm not gonna install them
<imbrandon_> jcfp: yes
<jcfp> bah :( writing 5 pages of copyright stuff for the remaining files with which nothing is ever done.
<imbrandon_> well improper lic == not non-gpl lic
<imbrandon_> err dosent
<jcfp> I know
<imbrandon_> if your wanting to remove them just so you dont have to change the debian/copyright thats wong
<jcfp> the problematic files have no license, or specify only "BSD License" without specifying which one
<jcfp> or giving full text
<ion_> Have you contacted upstream?
<imbrandon_> umm which one? "BSD" is only one license, there are many variants but "BSD" lic is only one
<jcfp> ion_: I think iÄºl pressure them once more
<jcfp> imbrandon_: some bsd licenses are not gpl-comp
<ryanakca> Would anybody happen to have a link to the debian changelog "what to do, and what not to do" guide?
<imbrandon_> jcfp: most bsd lic variants arent gpl compat , but that changes the fact very little
<jcfp> imbrandon_: they don't specify, that's the point. Just "BSD License", without any further text
<imbrandon_> jcfp: and thats my point, specifiy WHAT ?
<RAOF> Hit them upside the head!
<jcfp> with the better part of the program under gpl
<jcfp> creative commons v3 - is that a free license?
<blueyed> http://revu.ubuntuwire.com/details.py?package=jedit
<blueyed> woops.. wrong channel.. ;)
<blueyed> jcfp: kind of.. see http://www.gnu.org/licenses/
<blueyed> jcfp: I've meant http://www.gnu.org/philosophy/license-list.html
<blueyed> does not mention CC-3 though..
<jcfp> yeah went there but no info. google tells me debian didn't consider CCv2 ok, http://people.debian.org/~evan/ccsummary
<jcfp> but v3... still searching
<JediMaster> Hey guys, I'm producing a .deb, I've got the bulk of it done, and some pretty complex install scripts
<JediMaster> I was just wondering if the upgrade scripts get passed what version is currently installed, and what version is being installed so you can run particular scripts on upgrades?
<RAOF> JediMaster: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html may help you.  There's a better summary somewhere, though.
<RAOF> And the short answer is "yes"
<JediMaster> thanks
<JediMaster> is there a "proper" way to access databases for applications you are installing to install new SQL and upgrade it?
<RAOF> I remember such a discussion recently, maybe on the MOTU ML?  I think there's a database-common package, which does something like that?
<JediMaster> e.g. I've got a mysql database that needs to be installed from an sql dump on fresh install, and on upgrade run through the differences between each version
<JediMaster> I can do it easily enough, it's just password access I need to address
<JediMaster> btw, if anyone's interested, I've written a utility in php to track changes to MySQL databases for projects, it can track both schema and row changes to particular tables, take a peek at phpMyVersion on sourceforge, the latest svn version is working pretty well
<JediMaster> hopefully it can be of some use to someone here =)
<ion_> ActiveRecord migrations are awesome.
<JediMaster> yeah, I've heard of it, this is a little web interface with a fairly powerful SQL parsing engine that reads through the latest changes in the mysql SQL log periodically and can track multiple databases on multiple projects (all MySQL mind you)
<JediMaster> think the difference is that this can track row changes as well as schema
<ion_> The migrations feature takes care of migrating both schema and data.
<JediMaster> ah cool, well I probably re-invented the wheel =)
<JediMaster> only took a day or two to do anyhow
<ion_> And itâs database-agnostic. ;-)
<JediMaster> how does it keep track of changes if it's on a database without binary log files?
<JediMaster> does it just compare schema and row data?
<JediMaster> like a sort of diff
<JediMaster> am I right in thinking "debian-sys-maint" has full mysql access to the local databases? and if so, is it possible to get the password so upgrade scripts can alter particular dbs?
<JediMaster> heh, never mind, found the password in plain text in a file only readable by root, perfect =)
<ion_> The change for each revision of the database layout â i.e. migration â is in a separate file, with the filename starting with the version number. ActiveRecord stores the current version in a special table the database. Each migration contains the rules what to do when the database is being upgraded to that version, as well as when the database is being downgraded from that version. If the database says itâs version 10, there are migrations 1..15 ...
<ion_> ... available and the migrations are run, the migrations 11..14 would be run by default. For instance, the first migration could add the tables âpostsâ and âcommentsâ, the second migration could rename the table âpostsâ as âarticlesâ and the third migration could add a âcomments_countâ field to the âarticlesâ table, and fill the field in for each article that exists in the database.
<JediMaster> yeah sounds very much like what I've written, execpt the sql is in a php array indexed by the version
<ion_> Some samples of actual migration files: http://glu.ttono.us/articles/2005/10/27/the-joy-of-migrations
<JediMaster> oh weird, is that ruby?
<ion_> Yep, ActiveRecord is bundled with Rails.
<JediMaster> nice, I'm afraid I'm calling php scripts from deb package install/upgrade scripts lol
<JediMaster> ok, got to run, thanks for the help =)
<wastrel> hi, i have a bug with upstream fix that needs MOTU to update into ubuntu.
<wastrel> bug 184505
<ubotu> Launchpad bug 184505 in jppy "jppy fails to launch" [Undecided,New] https://launchpad.net/bugs/184505
<bddebian> Heya gang
<RAOF> Yo!  bddebian!
<bddebian> Hi RAOF
<RAOF> Hm.  I wonder if I want to ask for gnome-keyring-sharp to be synced from Sid.
<RAOF> What the hell.  It's got no bugs in the bts, it's been essentially stable for a while, and it seems not unlikely that people (ie: me) will want it.
<emgent> heya
<ScottK> wastrel: The ideal solution is you make an updated package with the patch, attach it to the bug and subscribe ubuntu-universe-sponsors to the bug.  If you need help with that, ask.
<wastrel> diy eh
<tuxmaniac> anybody seen laserjock around ?
<tjgillies> !seen laserjock
<ubotu> Sorry, I don't know anything about seen laserjock - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<tjgillies> im surprised botty doesn't have that function
<crimsun> wastrel: heh.  Are you working on it?
<PriceChild> tjgillies, /msg seenserv help
<tjgillies> PriceChild, thnx
<wastrel> crimsun, that's a negative.  don't have the time or energy.
<wastrel> cleaning out my email inbox :]
<crimsun> wastrel: heh, ok.  Pretty simple fix.  Uploaded.
<crimsun> I'm not even going to think about my inbox, which I can't even access for another few weeks.
<wastrel> yeah but i don't have an environment set up for building packages
<wastrel> thanks
<crimsun> if you're on broadband, it doesn't take but a few minutes.
<crimsun> ScottK: glad to see you're on the nom for MOTU Release Team
<ScottK> crimsun: Thanks.
<Hobbsee> oh yes, i should vote with that
<TheMuso> Same.
 * RAOF just has.
 * ScottK should too.
<ScottK> Oddly enough the other tab open in that browser window had US Presidential primary election results in it.
<StevenK> I so hope Hilary becomes president
<RAOF> StevenK: Why?
<StevenK> Then she can point to Bill Clinton and say "I did not have sexual relations with that man."
<RAOF> :P
 * ScottK laughs.
<StevenK> RAOF: She seems a little more 3 dimensional than Obama. And lets face it, she is loads better than Dubya
<ScottK> She's pretty well unelectable though.
<RAOF> It seems that pretty much everyone satisfies the latter constraint.
<ScottK> Very few people are neutral on her.
<StevenK> ScottK: Oh?
<ScottK> It's roughly 40% love her, 50% hate her, and 10% are uncertain.
<StevenK> RAOF: Well, I like her better than Obama. He seems a little, um, "Oh woe is me. Look what I've had to deal with."
<RAOF> I haven't been following particularly closely, but whta I've seen of Obama makes me favour him.
<wastrel> figures i heard were 30%ish hate her
<ScottK> Depends on the poll I guess.
<StevenK> ScottK: So, today is Super Tuesday, right?
<ScottK> Yes
<wastrel> which matches well with the 30% of complete idiots who approve of W still
<StevenK> ScottK: So, out of today, we get two candiates for the presidentancy?
<wastrel> hrm o4o apply in here :]
<ScottK> Maybe
<wastrel> i'm going back to my email
<StevenK> ScottK: I'm a little unclear. The elections are *far* more complicated than us convicts
<ScottK> Yes.  Understand.
<ScottK> It's extremely unlikely that anyone will have enough delegates to their respective party conventions after today to be sure to win.
 * TheMuso mehs at the US presidential race.
<ScottK> Excellent
<ScottK> TheMuso: Would you please motu-sru ack Bug #120445
<ubotu> Launchpad bug 120445 in firestarter "Firestarter firewall continuously crashes no matter which desktop or screen it's on." [Medium,Fix released] https://launchpad.net/bugs/120445
<StevenK> I'm a little interested, but I'm also interested in why libosso causes hildon-desktop to SEGV
<StevenK> If anyone wants to cringe, I can explain the bug
<ScottK> The short version is after tonight my prediction is the McCain will about have it in the bag and the dems will still be split.
<TheMuso> ScottK: If I remember how to state that its worth an SRU, sure. :p
<ScottK> I'll stop now.
<StevenK> Isn't Dubya Republican?
<ScottK> Yes
<ScottK> But he's not running.  Term limited
<StevenK> Right, more reason to like Hilary
<StevenK> ScottK: I knew that bit
<LucidFox> Oh no. USA politics on an Ubuntu channel. :/
<ScottK> He's pretty unusual as Republicans go.
<StevenK> (Thank $DEITY he can't run)
<bddebian> WTF, did someone say there's a reason to like Hitlery?
<StevenK> Oh yes, compare her to Naziism, that'll make me respect your point of view.
<StevenK> </sarcasm>
<LucidFox> And USA politics being talked about by an Australian, no less. :)
<StevenK> I'm curious enough to discuss them, but I don't care much.
<RAOF> As their largest colony, it's only fair :P
<ion_> You have used the Hitler card. You have no Hitler cards left.--MORE--
<StevenK> RAOF: It only seems that way thanks to Howard
<RAOF> True.  I was just trying to remember how to spell facicious.
<RAOF> And failing :)
<StevenK> Haha
<StevenK> RAOF: Oh yes, I hit level 65 last night. :-)
<RAOF> StevenK: Cool, cool.
<LucidFox> Well, since Australia is their _largest_ colony, it means Russia isn't their colony. That's a relief. :
<LucidFox> )
 * RAOF hasn't been Wowing much recently.
 * StevenK kicks libosso and dbus
<RAOF> StevenK: To move the topic back onto something vaguely resemling "on", do you want to help me close the gtk-engine-nodoka ITP, or shall I hit the sponsor ML?
<bddebian> StevenK: Nah, she's not a nazi, just a socialist.
<StevenK> RAOF: I'd rather not review something, just because I don't want to drop state.
<RAOF> StevenK: This isn't a "now" proposition, really.  It's just a "do you want first crack at it sometime".
<RAOF> And also a "how lazy can I be" question ;)
<StevenK> RAOF: Send it to mentors, and I'll grab it if someone else doesn't
<RAOF> K.  It's already there, but I'll advertise it too then.
 * StevenK sighs at libosso
 * RAOF is reminded of "porko rosso" each time you say that.
<bddebian> What is porko rosso?
<RAOF> A Miazaki anime.  Possibly misspelled.
<bddebian> Ah
<RAOF> About a pig, who flies bi-planes.
<bddebian> Hmm
<StevenK> RAOF: libosso is Nokia's abstraction layer over dbus
<RAOF> What does it abstract?
<StevenK> The message passing bit
<StevenK> So, both system and session buses
<TheMuso> StevenK: I'm about to head into a mess of work also. That being the espeak audio output fiasco.
<TheMuso> As soon as I get this cvs snapshot packaged.
<StevenK> I'm starting to really hate this.
<RAOF> My major experience with dbus has been in python, where there doesn't seem to be anything *to* abstract.
<StevenK> libosso installs a dbus/system.d file that is frightening.
 * Hobbsee is glad that the MOTU election stuff is nothing like the US presidential elections
<StevenK> Changing that seems to have a negative effect on hildon-desktop that SEGVs
<StevenK> RAOF: http://paste.ubuntu.com/4235/
<bddebian> Hobbsee: Why so we can't disparage you for your views? :-)
<Hobbsee> :P
<RAOF> StevenK: Ah, the old "security is for pansies" config file.
<StevenK> RAOF: "Security? What security?"
<RAOF> "We implicitly trust every app on this system"
<StevenK> BAD
<StevenK> RAOF: pitti wisely took one look at the file and said, "libosso isn't getting main goodness until you fix that."
<RAOF> Oh, dear.  Very much yes.
<StevenK> RAOF: So, I have a very different file right now, and hildon-desktop SEGVs
<TheMuso> StevenK: ouch indeed
<ion_> Haha, nice config.
<StevenK> From what I can work out, libosso takes a bunch of handlers and stuffs them into a GSList inside a GHashTable (yay for abstract data structures)
<RAOF> Because why catch errors when you can just ensure that the daemon will never sanity check you!
<StevenK> With the config file that I showed you, it works. With mine (any of mine, it seems any change I make doesn't help) it SEGVs
<ion_> Quality software from one of the most aggressive lobbyists for EU software patents. :-)
<TheMuso> If this is the kind of code nokia produces, I'm not sure I want to touch another of their products.
<ion_> One word: symb**n
<TheMuso> ion_: If their devices were accessible, no problem.
<TheMuso> ion_: Do they still use symbian?
<StevenK> TheMuso: On their phones, yes
<TheMuso> StevenK: Hrm. The latest talks etc don't appear to work with them, so far as I know. Its all damn nokia.
<StevenK> TheMuso: They did jump a major Symbian version which isn't backward-compatible
<StevenK> That was a little while ago, though
<TheMuso> right
<TheMuso> nevertheless
<LucidFox> Suppose I want to restore Mozilla branding in iceowl 0.7-2 and rename it back to Sunbird; do I need it to pass REVU, or can I just upload sunbird 0.7-2ubuntu1 directly to Ubuntu?
<TheMuso> the only 3rd edition symbian phones that seem to be supported are nokia
<StevenK> TheMuso: Ah yes, that's it. 3rd edition.
<StevenK> TheMuso: My N80 is 3rd edition
<TheMuso> StevenK: So is my 5700
<StevenK> I am gettting so convinced to buy a flip phone
<TheMuso> I personally couldn't think of anything worse.
<StevenK> The N80 has two Navi-keys, when you slide it closed and lock it, you need to press the left and then the right key to unlock it
<StevenK> And then if hit the dial key, you can dial the last number
<StevenK> While it's in a pouch on your belt, it's *very* easy to do that
 * StevenK has a theory about this libosso problem
<TheMuso> StevenK: Re the phone, sounds like fun
<StevenK> TheMuso: It really isn't.
<TheMuso> You really need to install a keypad auto lock program, unless the phone has such a feature.
<TheMuso> My previous phone, I used an autolock app, which was great. My new one however, has this feature, although it only works when the phone is at the standby screen.
<StevenK> TheMuso: autolock doesn't help, since it doesn't change how you unlock the phone
<StevenK> TheMuso: Locking the phone isn't the problem, it's how completly and utterly trivial it is to unlock it by accident
<TheMuso> StevenK: right
<imbrandon_> ugh anyone else here on new(er) apple hardware ?
<imbrandon_> i cant get the damn numlock to activate
<tonyyarusso> Is there a Launchpad status for "fix available" as in someone's written the code, but it's not in Ubuntu yet?
<StevenK> Fix Commited
<tonyyarusso> Ah, okay.  I thought that meant it had been like send to the LP build queue or something.
<LucidFox> So, Fix Committed can be used for bugs fixed upstream?
<tonyyarusso> Sounds like it..
<StevenK> tonyyarusso: I wouldn't use Fix Commited for that
<tonyyarusso> StevenK: care to explain further how you would use it?
<StevenK> tonyyarusso: If I'd uploaded it, I'd put the bug in the changelog and set it to In Progress when I'd uploaded it.
<StevenK> Launchpad would then close it for me
<tonyyarusso> StevenK: What if you had attached the fix to the bug but didn't have archive upload rights?
<StevenK> Um. That doesn't affect me, so I don't use it that way
<tonyyarusso> :P
<ScottK> One of the LP devs had a long blog post last year the told us exactly how we were supposed to use all the status and that we were wrong to do it any other way.  Google probably knows about it if you talk to it nice.
<Aloha> you gotta rub it the right way
<imbrandon_> fsk this is makin me mad, how can i assign the numlock function to an "f" key ?
<tonyyarusso> "Fix Committed: a developer has committed his/her fix to the project's codebase.", "In Progress: a developer has taken responsibility to fix the bug and has begun work." - given that "the codebase" in this case (just Ubuntu packaging info) resides in the archives, I'm guessing "In Progress" is best for me.
<TheMuso> StevenK: Does your theory pan out?
<StevenK> Nope
<StevenK> libosso hates me
<TheMuso> I'd be hating it I think
<bddebian> Gads evolution sucks
<StevenK> Argh
 * RAOF is bathed in the sweet music of complaint :)
<bddebian> heh
<ScottK> Sounds like RAOF has children.
 * ScottK is soaked in it daily
<bddebian> heh
<RAOF> The nearest child to me is the baby that lives below our flat :/
<Aloha> RAOF, i just watched hot fuzz last night. good movie
 * RAOF is perplexed by the non-sequiter.  It is, however, a good movie.  At least the first time.
<LucidFox> bddebian> I use kmail
<LucidFox> Despite having GNOME. That's the least ugly email client I've seen.
<LucidFox> What's frustrating is that it's literally the last KDE3 application I still use.
<bddebian> I used Thunderbird.  It's OK, but evolution tried to be outlook like or something
<LucidFox> Thunderbird is good.
 * ScottK uses Kmail too.
<LucidFox> Enigmail, however, is ugly - and I _do_ need PGP support.
<ScottK> Gutsy and later Kmail comes with all the bits you need for PGP already installed and configured (you just need to tell it what key to use).
 * tonyyarusso actually thought Enigmail was pretty good, especially compared to Evo's handling
<Aloha> i like the evolution plugin
 * TheMuso had better get the washing in before the weather turns any more nasty... could storm here very soon.
<Aloha> TheMuso, does washing == laundry?
<StevenK> Aloha: Yes
<Aloha> RAOF, i only said i watched it because you said "flat" and it reminded me of the movie because we don't talk like that here :)
<StevenK> Since he didn't say 'Arr-part-ment' ?
<Aloha> StevenK, i live in a condo ;)
<StevenK> Aloha: Merely an example. :-)
<Aloha> StevenK, we say "ah-part-ment" at least in this part of the country :)
<StevenK> Heh
<bddebian> Aloha: Where are you?
<slangasek> arr-part-ment?  pirate country?
<StevenK> bddebian: On IRC
<bddebian> pfft
<slangasek> judging by his ISP, I'm guessing Kentucky
<StevenK> slangasek: Slightly exaggerated
<slangasek> StevenK: I have no idea what you're exaggerating, unless you're mocking commonwealthers inability to pronounce r's in the first place ;)
<StevenK> Or l's, based on nuclear?
<slangasek> Texas is a separate country
<bddebian> That's nucular
<StevenK> Haha
<bddebian> They wish
<StevenK> "The United States of America. Oh, and Texas."
<Rushido-Fokkusu> Zatsu nukuraru
<superm1> StevenK, hey now we're not our own country anymore.
<superm1> StevenK, that was many years ago :)
<bddebian> s'ok, it'll be Mexico again soon
 * jdong applies for a Linus of the Day Award
<jdong> I needed a homework organizing system, and none of the existing TODO/calendaring apps quite fit my bill
<jdong> so I got together a bunch of hackish ruby scripts to manipulate a directory tree of plaintext files into a TODO list :D
<Flannel> jdong: tried tdl?
<jdong> Flannel: yes in fact, my implementation was quite inspired by tdl
<jdong> Flannel: but tdl didn't do exactly what I needed, and its on-disk format was a bit too complex for my tastes
<Flannel> jdong: for curiositys sake, what about tdl didn't you like/didnt work/whatever?
<jdong> Flannel: my main criteria were (1) Can be parsed/edited by a human with generic editors (2) Is easily manageable via bzr for concurrent disconnected mirrors
<jdong> I believe tdl uses a binary storage system which is not ideal for merging
<Flannel> bzr does binary diffs though, right? unlike cvs
<jdong> Flannel: not really, last time I checked. It recognizes binary files are "different" and will go into manual conflict resolution
<jdong> which is not all that helpful
<jdong> if I add a TODO from computer A and delete one from computer B, then try to merge...
<jdong> bzr would tell me there's tdldb.THIS and tdldb.OTHER
<Flannel> Oh, I dont mean for merging, I mean just in the DB itself.  Storage.
<jdong> that's awesome, but..... yeah
<Flannel> Yeah, tdl is binary formatted.
<jdong> Flannel: right, bzr can store binaries perfectly
<Flannel> it does incremental storage?
<jdong> yes
<jdong> it uses a diff algorithm internally to represent binary changes
<Flannel> Alright.  Itd be crazy if something so new didnt
<jdong> I recall, however, the performance of diffing massive binaries is not up to par with its competitors
<jdong> mostly because its competitors have natively implemented diffs
<ion_> bzr is orders of magnitude away from up to par in performance from certain competitors. :-)
<jdong> ion_: they're getting better though
<lifeless> ion_: when did you last test
<lifeless> ion_: and what base
<jdong> they've come a long way and definitely make steady, predictable progress
<jdong> and look at that, here comes a bzr guy to the rescue :D
<jdong> lifeless: I'm guessing he tried to pull one of the many 5000+ file bzr branches off launchpad ;-)
<lifeless> jdong: have you upgraded to packs ?
<jdong> in which case, I feel quite sorry for him :)
<jdong> lifeless: locally, yes, but I haven't had the opportunity to try anything over the network with packs
<jdong> lifeless: is it significantly improved?
<lifeless> jdong: you should do 'bzr upgrade sftp://bazaar.launchpad.net/....'
<lifeless> jdong: followed up by 'bzr reconcile <same url>'
<lifeless> jdong: for each of your branches
<jdong> lifeless: I'll do that
<lifeless> jdong: about 5000 times faster in your case
<ion_> lifeless: Just bzr --help from a warm cache takes 0.45 seconds here. git does many of the most used operations in much less than that.
<jdong> lifeless: well that's a good speedup :)
<lifeless> ion_: thats a very meaningful benchmark
<jdong> lifeless: people get fussy when help doesn't immediately arrive!
<ion_> If --help takes that, the rest of the operations probably take *at least* that.
<StevenK> lifeless: One thing to keep in mind, the version of bzr in Gutsy doesn't support packs
<lifeless> 0.325 real seconds for me
<jdong> bzr --help  0.18s user 0.04s system 98% cpu 0.223 total
<lifeless> StevenK: ppas for the win. kthxbye.
<jdong> StevenK: backports
<jdong> StevenK: though admittedly bzr-svn lags behind ;-)
<StevenK> I prefer lifeless's soltuion.
<lifeless> ion_: you are making many assumptions about what --help has to do; this is strange for someone that has used git (making assumptions is strange I mean)
<StevenK> I avoid crackports
<jdong> fine fine, trust some random PPA over the backports team :)
<lifeless> the bzr developers ppa
<lifeless> not exactly random
<jdong> I was being sarcastic, you guys have a wonderful ppa
<lifeless> k lol
<StevenK> That sounded more bitter
<lifeless> why isn't backports a ppa ?
<jdong> no, it's just after-coding bitterness
<ion_> lifeless: Having to wait half a second for something to happen every time you run a command just feels slow after getting used to getting results almost immediately.
<StevenK> Dear hildon-desktop, stop segfaulting. kthxbye
<lifeless> ion_: I'd guess at some problem in your setup
<lifeless> how long does 'time python -c ""' take for instance
<ScottK> Well we could just stop packaging anything that's hosted on LP and automatically pull in from upstream PPAs.
<jdong> lifeless: (1) ppa's weren't invented 3 release cycles ago (2) I don't feel like downloading some of those 30+MB source archives just to change 2 lines in changelog and reupload them...
<ion_> lifeless: 0.1 s
<jdong> lifeless: (3) ppc/sparc/friends would probably not be happy
<jdong> (4) no packages.ubuntu.com listings.... (minor reason)
<lifeless> jdong: YHBT HTH HAND KTB
<ScottK> (5) PPAs not part of Ubuntu
 * jdong tries to match those letters onto a dvorak keyboard....
<jdong> many backports testers/contributors are setting up PPAs to test backports, though
<jdong> which is an interesting and good use for PPA
<ScottK> Agreed.
<lifeless> ion_: so nearly 25% of the 'slowness' of bzr is bare bones python startup
<jdong> but why Backports doesn't use PPAs altogether is the same reason why we don't just have a MOTU ppa and ditch Universe
<lifeless> ion_: now, we know that python is very slow at loading modules, we're looking at ways to refine it further so its not slow in this regard
<TheMuso> jdong: If mol were used on ppc, IMO packages could be built for PPC for PPAs.
<ion_> lifeless: Yes, obviously having to load the python interpreter and a bunch of python modules causes the initial startup delay.
<lifeless> ion_: anyhow, its scaling that matters: if we pay a constant overhead compared to something written in C, but beyond that are comparable, its not a big deal IME - and we're certainly getting enough refuges from git.
<lifeless> ion_: in fact, see rusty russel's recentish blog post 'git is the slowest modern vcs'
<ion_> Will do
<jdong> TheMuso: that would be interesting
<jdong> TheMuso: I don't personally think PPA's on common arches are as useful as PPAs on exotic ones
<jdong> as far as a developer/tester tool
<TheMuso> jdong: Well since mol allows you to run either OS X or Linux on top of Linux, IMO its worth investigating.
<tonyyarusso> That's true.  an x86 PPA is nice for distributing stuff to the public, but doesn't add value for development.
<TheMuso> Mol authors claim almost 100% speed
<TheMuso> I fI remember correctly.
<StevenK> lifeless: I have Rusty's problems with git, too
 * TheMuso doesn't remember seeing anything about that on Planet LA
<TheMuso> unless its not sindicated. Anybody got a link?
<StevenK> TheMuso: http://ozlabs.org/~rusty/index.cgi/tech/2008-01-07.html
<ion_> lifeless: The âMy first git whine for 2008â post? That one seems to be about PEBKAC. :-)
<TheMuso> StevenK: Thanks.
<LucidFox> Well, for me personally, PPA is useful for test-building on Hardy. Paying for traffic and all, it would be to expensive to do on my local machine.
<StevenK> ion_: Oh, yes, because the error messages are *so* useful
<lifeless> ion_: 'interface usabilility'
<lifeless> ion_: a hard to use interface will be used wrongly; design drives interface. Gits design drives its usability, and human time doing the wrong thing is vastly more costly than 0.5 seconds when you personally run a command.
<TheMuso> interesting read
<ScottK> For me, not having to learn N + 1 VCS that isn't used anywhere else is a big driver.
<ion_> I guess iâve just been lucky, since my subjective UI experience with git has been at least as good as with bzr.
<StevenK> It does raise the point, "Rusty is smarter than me, and if he can't use git, what chance do I have?" :-P
<ion_> I used to be a bzr fanboy. :-)
<lifeless> ion_: well, I'd be interested in knowing what you need from us to be able to switch back
<RAOF> I think the thing many people would miss from git is the bisecting tool, which doesn't seem to have a bzr counterpart.
<RAOF> I haven't used it for my own projects (I never introduce regressions, ever :P), but it was great fun with nouveua.
<RAOF> s/misspelling/nouveau/
<ion_> lifeless: The subjective âfeelingâ is somewhat difficult to quantify. The responsiveness is a big part of it. How branches reside under the same project tree by default and everything is designed around that is another part of it (bzr switch feels more like an afterthought compared to that). It would be nice if long output was piped to a pager by default (AFAIK someoneâs been working on that already).
<lifeless> RAOF: as in 'bzr-bisect'
<lifeless> https://edge.launchpad.net/bzr-bisect
<RAOF> Ah, right.  Not yet in bzrtools :)
<lifeless> ion_: the branch model in git we consider rather ugly
<RAOF> I did think that was an obvious candidate.
<lifeless> ion_: bzr switch is going to get some polish added to it
<ion_> Gitâs branch model is something i fell in love with, but i donât blame anyone for disagreeing. :-)
<RAOF> It seems like an implementation detail that's been accidentally exposed, to me.
<RAOF> Particularly the *arcane* syntax for extracting branches from a tree.
<ion_> In fact, i had hoped bzr worked like that before i had actually studied git enough to know it works like that.
<LucidFox> Any Python gurus here? I need to patch setup.py to accept a --root=/path/ command option, but I don't know how to read that option
<lifeless> ion_: we're going to do something to allow bzr to be git-like in this respect
<RAOF> LucidFox: It's not using distutils?  I was under the impression that had such an option by default.
<lifeless> but hopefully more stylish
<LucidFox> it is using distutils
<ion_> lifeless: Nice
<LucidFox> it's just hardcoded to install the desktop file to /usr/share/applications
<RAOF> lifeless: I suggest ponies.  They're very stylish.
<RAOF> LucidFox: Ah, fun.
<ion_> raof: May i suggest unicorns?
<StevenK> lifeless: For 1.2, or later?
<lifeless> StevenK: pipeline
<RAOF> LucidFox: Why not just patch it to hardcode the right path? :)
<StevenK> Ah, right
<StevenK> Hah
<LucidFox> that would solve it, but I would like to have a patch I could send upstream
<StevenK> It works if the config file has <allow own="*"/>
<RAOF> LucidFox: Fair enough, yeah.  I forget how to get those options out of distutils, though.
<StevenK> Is there any way to query dbus to see what the libosso service owns?
<RAOF> StevenK: So it's not so bad.  You can just impersonate any system service.
<StevenK> Twitch
<RAOF> Hello!  I'm policykit!
<RAOF> No, really!
<StevenK> RAOF: Well, I'd like to lock it down, but I need to know what it wants to own first.
<RAOF> StevenK: Have you checked out the d-feet dbus debugger?
<TheMuso> Hrm. That was a close one.
<TheMuso> May consider going offline soonish...
<TheMuso> As it is, its nearly the end of the work day, so its not all bad.
<RAOF> Eh.  Lightning only makes computers super-powerful.
<TheMuso> I wish/
<StevenK> RAOF: For about 2 ms anyway
<StevenK> Then they decide they can't handle the power
<RAOF> They only need a couple of hours rest to recover afther their exertions :)
<StevenK> RAOF: Are there hardy packages for d-feet?
<RAOF> StevenK: Yup.  In universe, have been for a couple of weeks.
<StevenK> Sweet
<TheMuso> One more close one, and I'm outa here...
 * TheMuso glances nervously at the sky
<ion_> The universe has been known to grab some of its computing power back from computers via lightning.
<StevenK> RAOF: Grah. d-feet doesn't help
<RAOF> StevenK: Really?  Damn.  I was sure I saw some sort of "owner" field somewhere there.
<ScottK> LucidFox: Look at debian rules in pymilter (source pacakge name) at the install for python-milter.
<ScottK> That may be an example of what you want.
<LucidFox> thanks
 * StevenK kicks moinmoin, too
<StevenK> A nice way of seeing what groups moinmoin thinks I'm in would be nice
<slangasek> StevenK: hmm, who else was sharing the libldap rebuilds?
<StevenK> slangasek: persia
<slangasek> and which part of the alphabet did he get? :)
<StevenK> slangasek: The middle bit
<slangasek> ok
<slangasek> there seem to be a lot of remaining reverse-deps all over the alphabet
<slangasek> certainly including mine, which I'm just now starting on
<StevenK> How much is left, I can take some more
<slangasek> hmm, some 50 left
<slangasek> little less than that
<StevenK> slangasek: I remember uploading a bunch, but I didn't check if they built or anything
<slangasek> StevenK: there are a total of 6 build failures in Debian from the binNMUs for this transition
<slangasek> down to 5 now
<slangasek> (was 10 originally, but I think I synced the remainder as they got fixed anyway)
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<vemon> i sent an updated (new upstream version) of jack-rack to launchpad a while ago. any motus care to take a look at it? (LP #187190)
<ubotu> Launchpad bug 187190 in jack-rack "[update] jack-rack" [Wishlist,Confirmed] https://launchpad.net/bugs/187190
<TheMuso> I'll take care of it.
<TheMuso> vemon: Does debian have it yet?
<vemon> TheMuso, no the don't. otherwise i would have requested a sync
<vemon> they
<dholbach> good morning
<Aloha> TheMuso, if a packge is in universe and a new release is available, is the maintainer required to package it , or can anyone submit to REVU?
<Aloha> dholbach, morning!
<TheMuso> Aloha: Anybody can package it, but its better to get it into Debian first. However, if you want it in Ubuntu, and the Debian maintainer hasn't responded/has no intension of doing it, you don't put it on REVU. You file a bug, attach at least the .diff.gz file from the new package, which either has a watch file, or a get-orig-source rule in debian/rules, and subcsribe ubuntu-universe-sponsors
<Aloha> TheMuso, thnx
<TheMuso> vemon: DId you check that there were no other changes needed to comply with standard 3.7.3?
<LucidFox> TheMuso> So diff.gz uploads can now be sponsored? Interdiffs are no longer necessary?
<TheMuso> LucidFox: No they are no longer necessary.
<LucidFox> Great.
 * LucidFox uploads the diff.gz to bug #187576
<ubotu> Launchpad bug 187576 in smplayer-themes "Upgrade to smplayer-themes 0.1.15" [Wishlist,Confirmed] https://launchpad.net/bugs/187576
<vemon> TheMuso, no i didn't :/ i just assumed i would get errors if there were problems
<vemon> TheMuso, is there a tool to check the compliance?
<TheMuso> vemon: No.
<TheMuso> vemon: But things look ok.
<vemon> i made a few other changes to the package also since it wouldn't build out of the box with the new upstream version
<vemon> for example removed tarball.mk include from the rules file since i couldn't figure out where it's needed and it just caused errors in the build
<vemon> would it be a good idea to notify the original packager about the new upstream version in ubuntu?
<vemon> i don't have a debian installation @ home so i can't test the package in debian but the sync to debian unstable would probably be quite trivial
<TheMuso> vemon: At least file a bug abot it, yes.
<shibata> Hi, all.
<dcordero> hi
<sistpoty|work> hi folks
 * LucidFox nods
<geser> Hi sistpoty|work
<sistpoty|work> hi geser
<sistpoty|work> man-di_: thanks for picking up changes in sdl-image1.2 (still wanted to report a bug in BTS, but forgot to do this until now :/)
<geser> Fujitsu: do you remeber why the "Changed Blogroll to point to Planet Ubuntu instead of Planet Debian" change got dropped during your merge of wordpress in November?
<Fujitsu> geser: I don't recall... it may have been to do with Debian dropping the change that introduced the Planet Debian link in the first place. I forget.
<geser> Fujitsu: how do we handle wordpress in the previous releases? there is a new wordpress version out (as usual with security fixes)
<Fujitsu> geser: Find the patches for any of our releases that are vaguely up-to-date, I guess.
<Fujitsu> The policy for most releases seems to have been to run away, however.
<emgent> heya
<sistpoty|work> dholbach: btw.: I'll be around at 22nd, so I could hold the library packaging session there
<dholbach> sistpoty|work: that's awesome!
<sistpoty|work> np ;)
<dholbach> sistpoty|work: if you think you need two sessions, that's fine - just add them as "part 1" and "part 2"
 * dholbach hugs sistpoty|work
<sistpoty|work> dholbach: yes, I'll definitely need to sessions. Will add them tonight (don't have login credentials here atm)
 * sistpoty|work hugs dholbach
<dholbach> sistpoty|work: I can add it for you - no problem
<sistpoty|work> k, thanks!
<dholbach> awesome
<slytherin> geser: Can you anyway push for the DTD issue. I have the debdiff attached. We need to fix lucene2 as soon as possible since netbeans 6 is waiting for it.
<geser> is it bug #183164?
<ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
<slytherin> geser: yes
<geser> slytherin: you need a core-dev for it to sponsor
<slytherin> geser: I know. I thought you could bribe someone. :-P
<geser> dholbach: could you assign a main sponsor for bug #183164?
<ubotu> Launchpad bug 183164 in w3c-dtd-xhtml "Wrong path for entity sets" [Undecided,Confirmed] https://launchpad.net/bugs/183164
<dholbach> geser, slytherin: I was a bit hesitant as I wanted to see how the Debian discussion turns out
<persia> dholbach: The DD doesn't want to fix it that way.  In any case, it won't get resolved by FF, and blocks some features that at least I want to include in hardy.
<slytherin> dholbach: That is the reason I have made minimal change. Just to fix what we want.
<persia> The other alternative is disabling parts of the test suite for build-deps, but that doesn't really seem ideal (or hand-building, which makes buildd admins cry)
<dholbach> ok... I'll do the upload - would you agree to do the merge (in hardy+1) and watch if there's any negative fallout from this change?
<slytherin> dholbach: Sure. I will keep a watch.
<dholbach> great, thanks
<mruiz> morning all
<smarter> hi everyone
<smarter> I've updated my bespin package: http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin
<smarter> It has been rejected because of a debian/copyright error
<smarter> Could someone please review it?
<sistpoty|work> smarter: just took a short look at the debdiff, your debian/copyright still seems to be wrong
<smarter> sistpoty|work: why?
<sistpoty|work> smarter: you mention files under GPL2, but refer to LGPL-2 link in /usr/share/common-licenses
<smarter> sistpoty|work: I refer to both
 * sistpoty|work looks at plain debian/copyright
<sistpoty|work> smarter: ah... I'd exchange the links that refer to GPL/LGPL to make it more clear (the GPL link is directly below the LGPL disclaimer and the LGPL link below the GPL disclaimer)
<dholbach> slytherin: can you join #ubuntu-devel - pitti and asac are looking at it
<shibata> persia: Thank you for advocating. By the way, where do I write "This package should upload in multiverse." for REVUer or uploader? In REVU comment? or debian/copyright?
<persia> shibata: Don't worry about it.  That was my comment to indicate to the next reviewer that I thought it belonged in multiverse, so they could pass that on in discussions with the archive admins.
<shibata> persia: I see. thanks again.
<persia> shibata: Also, my apologies for the too-brief review of kita2.  Please review RainCT's comments, and submit a new candidate.
<RainCT> Heya
<shibata> persia: I'm doing it now.
<persia> RainCT: Thanks for catching all that :)  Perhaps you can find a problem with the other packages I advocated last night?
<smarter> sistpoty|work: oh, right
<shibata> Hi RainCT. Thank you for revu and comment of kita2 package. I have some questions about kita2.
<RainCT> persia: heh don't worry, I'm just picky :)
<RainCT> shibata: np, just ask :)
<persia> RainCT: That's a good thing :)
<shibata> RainCT: About No. 0, If I would like to create and to install some files which does not exist in original .tar.gz, then which should I create it in original source tree by use dpatch or in debian/ directory?
<smarter> sistpoty|work: Uploaded ;) http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin
<RainCT> shibata: in debian/
<RainCT> shibata: patch systems are only useful to modify files that are already in the .orig.tar.gz
<smarter> sistpoty|work: oh, I forgot to change the "the complete text of ..." line
<smarter> sistpoty|work: just a minute
<sistpoty|work> smarter: don't hurry because of /me... I cannot do in depth reviews here at work anyways
<RainCT> shibata: but for adding new files, using a patch system just make it more difficult and don't make sense (a patch is more difficult to read than a plain file, it can't be edited directly, etc.)
<shibata> RainCT: I see about No. 0. Next is about No. 3, If I change original source tree and/or add new file (for instance, launcher), then I think that I *must* write about it in README.Debian or README.Debian-source, is it right?
<smarter> sistpoty|work: okay, I'll stop bothering you ;)
<sistpoty|work> heh
<persia> shibata: Only add to README.Debian when the contents are interesting to end-users, and only add to README.Debian-source when you expect other members of the maintenance team to be confused by something you did.  For a simple file addition, you needn't do either.
<frafu> Hello, mousetweaks is a module that passed revu a few days ago, and I received a build failure email due to a missing dependency; the building procedure happened 9 hours ago: https://edge.launchpad.net/ubuntu/+source/mousetweaks/2.21.90-0ubuntu1/+build/507079 However, in the upload queue there are debs of mousetweaks build 16 hours ago: https://edge.launchpad.net/ubuntu/hardy/+queue?start=60 Does the presence of the debs in the queue n
<persia> frafu: buffer: "debs in the queue n"...
<RainCT> frafu: your message was cut "in the queue n"
<frafu> Hello, mousetweaks is a module that passed revu a few days ago, and I received a build failure email due to a missing dependency; the building procedure happened 9 hours ago: https://edge.launchpad.net/ubuntu/+source/mousetweaks/2.21.90-0ubuntu1/+build/507079
<frafu> However, in the upload queue there are debs of mousetweaks build 16 hours ago: https://edge.launchpad.net/ubuntu/hardy/+queue?start=60
<frafu> Does the presence of the debs in the queue not mean that the build was successful 16 hours ago? Thus why has it been build a second time 9 hours ago?
<geser> frafu: compare the architecture.
<geser> frafu: only hppa failed to build, the others build successfully so far (lpia is still in the build queue)
<RainCT> shibata: no, a README file isn't necessary for that (as persia just said). it's easy to notice that you added that file just having a fast look at debian/rules or debian/install (I don't remember what you used), and users shouldn't worry about it anyways (only if it would be changing the behaviour of the application in some important way)
<persia> s/important/interesting/
<RainCT> persia: :)
<frafu> So there are 5 architectures?
<geser> frafu: six: i386, amd64, powerpc, sparc, lpia and hppa
<persia> Did we drop ia64?  We used to have that as well.
<geser> frafu: add ia64 and make it seven
<frafu> Will the build system automatically retry, or does the fact that I received a failure notice imply that I have to intervene?
<persia> frafu: Depends on the reason for failure.  Typically "Failed to build" requires manual intervention.
<geser> persia: that happens why I try to list the architectures from memory without checking :)
<persia> geser: I understand.  I was sure it was six as well until I started typing, and you commented while I was still going back so s/six/seven/ :)
<persia> frafu: This one looks a little odd, as I'd expect it to have gone DEPWAIT rather than FAILED.  I'd watch the status of libpanel-applet2-dev on hppa, and when that is looking healthy, ask for a give-back.
<geser> frafu: looking at the build log: hppa has broken dependencies, you can't do anything about it besides helping to resolve them
<geser> persia: iirc soyuz doesn't catch broken deps and automatically retries later
<shibata> persia, RainCT: I understand. Last question does not relate to kita2. When I create new package, which prefer to use CDBS or debhelper without specific problem?
<persia> geser: Then why are so many packages listed as DEPWAIT at http://qa.ubuntuwire.com/ftbfs ?
<geser> persia: they wait on missing packages or a specific version
<persia> Ah.  The difference between cannot-install and does-not-exist.  That makes sense.
<frafu> I assume that when release time has arrived, all architectures will ship the same modules; correct?
<persia> shibata: Best is to make your debian/rules as readable as possible.  If you do nothing special, CDBS is nice.  If you need lots of CDBS overrides, and can make it more understandable with a normal makefile, don't use CDBS.
<persia> frafu: That's the goal, although only i386, amd64 and sparc were promised for gutsy.  I'm not sure whether the final architecture determination has been made for hardy yet.
<smarter> The kde4-style-bespin package should now be ready for re-upload ;) http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin
<frafu> When will the package appear in universe? Once the module has been successfully built on all architectures?
<vemon> is anyone else experiencing extreme slowliness with packages.ubuntu.com?
<shibata> persia, RainCT: Thank you very much for answers. I'm fully satisfied.
<persia> vemon: There were some DNS changes announced recently.  You'll likely have a better experience with rmadison and apt-cache search anyway.
<RainCT> frafu: no, it will appear soon (if it isn't there already) for those architectures for which it is already built
<geser> frafu: they will appear in universe once the build packages pass binary NEW (are accepted by an archive admin)
<RainCT> frafu: ah, well, then what geser says too :P
 * persia points at https://launchpad.net/ubuntu/hardy/+queue
<RainCT> geser: so all binaries are manually checked before being published?
<persia> RainCT: Only lightly.
<geser> RainCT: yes, but only once (when they are new), but I don't know what exactly gets checked
<geser> "old" packages get published as soon as they got build
<RainCT> ah, only when they are new. ok, this makes sense, thanks :)
<frafu> The package that has gone into the queue fails to register the schemas. I have an updated version that fixes the issue on my computer. However, coming sunday or monday a new upstream version will be released that includes other fixes. Should I wait for the new upstream to also fix the schemas issue?
<persia> frafu: I'd wait for the new upstream, to reduce the load on the buildds.  No point fixing it today and uploading again on Monday.
<persia> (unless you need testers desperately)
 * RainCT wonders why pbuilder installs fakeroot each time it build something -.-
<RainCT> s/build/builds
<jdong> anyone have suggestions for how to write a fast "fake" pbuilder-satisfydeps just to check of build-deps are satisfied for pkg $foo on distro $bar?
<frafu> persia: what happens if the universe admins reject it due to the schemas issue? Will I have to propose an updated version for universe or go again the revu route ?
<jdong> My first idea was to evoke pbuilder on just basically the control file in question and a dummy rules file
<norsetto> howdy folks
<jdong> my second idea was to write my own pbuilder-satisfydeps that queries rmadison :)
<gaspa> norsetto: uella'
<norsetto> hola gaspa
<RainCT> jdong: look at get-build-deps in ubuntu-dev-tools
<RainCT> jdong: I think I have a check to see if all dependencies are satisfied there
<persia> frafu: If it is building, it was already accepted.
<ScottK> frafu: You go back to revu, but it only takes one advocate to get it uploaded
<ScottK> Or not in this case.
<frafu> persia: Above it was said: "they will appear in universe once the build packages pass binary NEW (are accepted by an archive admin)". So the universe admins check it before the build and after the build!?
<jdong> RainCT: that uses the local system's apt repo data, which isn't all that useful for me...
<jdong> RainCT: I know the pbuilder dummy build method will work and be trivial to code, while the rmadison approach will not be trivial... just a matter of which is faster
<jdong> RainCT: for backports, looking for a way to shortcut fetching a 50MB source archive, having debuild turn it into a source archive, copy that into a temp dir.... if the build-deps don't even meet
<uniscript> apt-get build-dep package?
<uniscript> man dpkg-checkbuilddeps
<uniscript> shame it works off the debian/control file rather than the .dsc file :(
<jdong> uniscript: well... backports builds can be against any distro release, not the active one running
<geser> jdong: rmadison doesn't say you if all build-depends are installable at the same time
<sistpoty|work> jdong: maybe with having all distros in sources.list and a senseful pinning and overriding this for apt-get
<uniscript> true
<jdong> uniscript: and consists of building against $release, $release-updates, $release-backports, and nothing else
<jdong> which is smoemthing that's not true about my host system
<uniscript> talking of backports I'm writing an mpdebuild that adds things like a distribution list to basically a pdebuild command
<persia> frafu: Your source package won't be removed from the archive because of issues with binary NEW.
<uniscript> is this a stupid idea?
<jdong> uniscript: one of the most common complaints I get about prevu is "Why the hell did it download 200MB of crap just to say it couldn't do it??"
<RainCT> jdong: ah ok
<jdong> uniscript: well pbuilder-dist I think does what you're thinking
<uniscript> you mean take a list of distros and go off and let me drink tea?
<geser> jdong: can't you do "apt-get -s build-dep pkg" before try the real build to check if the build-depends can be installed?
<jdong> uniscript: well no, it can maintain concurrent pbuilders for a list of distros. which to build can be specified as a CLI argument rather than a bunch of --basetgz/ --mirror/ whatnot
<uniscript> OK mine just builds them all hacking the dch for me, etc.
<jdong> uniscript: which can be combined with simple shell scripting to achieve your effect
<jdong> geser: in a pbuilder type cleanroom, yes
<uniscript> one snagglet is how do I force a rebuild of the .orig.tar.gz and .diff.gz it keeps the old one and ends up being the wrong thing built
<jdong> geser: in a cleanroom, I can also just patch -p0 the diff.gz, replace the rules file with an empty/skeleton one
<jdong> :)
<uniscript> jdong: well this is my simple shell script :)
<jdong> which will be even easier than trying to hook a pre-build command
<frafu> persia, geser, RainCT: many thanks for your help and clarifications about the build failure and schemas issue. :)
<jdong> uniscript: whatever script helps you, you should make. it's none of our business what you hack up unless it starts producing faulty build resuilts ;-)
<jdong> uniscript: I have much more questionable scripts lying around :D
<uniscript> OK but where are all these cool scripts hanging out. I can't be the first to do this.
<jdong> uniscript: you might be
<uniscript> please no :)
<jdong> uniscript: prevu does some of the similar stuff (mangling debian/changelog, managing multipe pbuilders)
<jdong> uniscript: but it's too specialized for your needs, probably
<uniscript> worth a try
<jdong> uniscript: yeah it's all in python and should be easy to mangle for your personal needs. I've tried to keep the code clean and organized
<jdong> uniscript: packages are in Ubuntu, bzr branches on product prevu in LP
<uniscript> installing package now
<uniscript> or is the gutsy one very old?
<uniscript> hmm docs?
<uniscript> 1:0.4.3
<slytherin> persia, Can I specify version in control file like this - >= 1.1-5ubuntu1 ?
<persia> slytherin: I think so.  Try and see?  Also, asking the channel generally often results in a faster response.
<slytherin> persia, Ok. One more question specifically for you. :-) Do you think I should try libdb4.6-java (main) as build dep for lucene2 instead of ibdb4.6-java. Or do you prefer minimal changes
<uniscript> is there a dpkg-buildpackage option or something that says: don't use a source package you may see lurking above me, make a new one and build that?
<persia> slytherin: I don't understand your question.  Maybe there was a missing letter?
<slytherin> persia, Should try replacing build dep libdb4.5-java (universe) with libdb4.6-java (main) for lucene2. Or as of now you prefer minimal changes?
<slytherin> s/try/ i try
<ScottK> Generically we want to push everything to 4.6.  Dunno about this case.
<persia> slytherin: I'd test it.  Getting rid of everything but db4.2 and db4.6 would be nice.  Getting rid of db4.2 is hard :(
<slytherin> Ok. I will try.
<ScottK> FYI we have a libdb4.6-ruby now that appears to work fine for anything that doesn't need db transaction support.
<ScottK> Actually it's bin new.
<bddebian> Heya gang
<HighNo> hi there -  while running lintian on my package I get "bad-distribution-in-changes-file feisty" so what exactly should I put as distribution here?
<bddebian> Should be hardy in debian/changelog now
<HighNo> ok, thanks
<geser> Hi bddebian
<norsetto> heya bddebian
<persia> hey bddebian
<sistpoty|work> hi bddebian
<bddebian> Hi geser, norsetto, persia
<bddebian> and sistpoty|work :-)
<dcordero> hi
<bddebian> Hello dcordero
<xivulon> hi all, I am wubi-installer.org author
<xivulon> I have a request about nsis package which is needed to build wubi
<xivulon> At the moment I am using nsis-2.34 via wine, but it would be better to use the nsis native package
<xivulon> Except that nsis is using 2.33 atm
<xivulon> can some good soul look at it?
<xivulon> I'd do it myself except that I am not very experienced in packaging and it's a bit too late in the cycle (wubi should ship with the Live CD) for experiments
<xivulon> Gentoo does have a 2.34 package if that can help (amd64 would be much appreciated)
<ScottK> Debian is still on 2.33 and the Debian maintainer is generally pretty active.  I wonder if there is a reason he's holding back.
<ScottK> You might ask him (Paul Wise <pabs@debian.org>) if he's any plans to update soon.  No point in us duplicating the work if he's got it in hand.
<xivulon> Gentoo 2.34 is not marked as stable yet
<xivulon> so probably yes
<xivulon> thanks ScottK will contact Paul
<xivulon> do I need to file a bug report anyway?
<slytherin> xivulon, can you not try using 2.33? I mean what are the changes in 2.34 which need for your work?
<xivulon> I have change a few bits and pieces to use nsdialog as opposed to installoptions, which provides a much saner environment for custom forms
<xivulon> I'd have to roll back all the changes
<HighNo> Hm, is it impossible to create a package for hardy with feisty's tools? I now get the same error from lintian "E: blueproximity_1.2.2_i386.changes: bad-distribution-in-changes-file hardy" but additionally I get errors from dch: "dch warning: Recognised distributions are:
<HighNo> {warty,hoary,breezy,dapper,edgy,feisty}{,-updates,-security,-proposed} and
<HighNo> UNRELEASED."
<jpatrick> HighNo: feisty didn't know hardy
<slytherin> HighNo, use pbuilder and create a chroot for hardy
<linux__alien> Hi i ve joined a team in launchpad.net and ve been eagerly waiting to start the tasks. the team had the mentoring option available but i am not able to contact the person who leads the team
<jpatrick> norsetto: you around mate?^^
<linux__alien> can someone here help me how to go about now from this step. I am very much interested in contributing to Ubuntu
<norsetto> jpatrick: certainly :-)
<HighNo> slytherin: I should use pbuilder with an python only package? I will check that anyway
<slytherin> HighNo, pbuilder helps you create chroot. So you can build for distribution other than your system
<HighNo> slytherin: ok, thanks - I didn't know that.
<HighNo> slytherin: what size will that chroot env be for hardy? my disk space is very low at the moment
<slytherin> HighNo, the basic is about 75 MB. Depending on the build dependency of your package additional packages will be installed in chroot
<frafu> persia or anybody else: https://edge.launchpad.net/ubuntu/hardy/+builds?build_text=libpanel-applet2-dev&build_state=all finds no matching build; but the dependency was used to build mousetweaks for other architectures. Is this not a contradiction: the libpanel package is not listed in the hardy builds, but has been used as a dependency!?
<persia> frafu: Try searching from https://launchpad.net/ubuntu/+builds  Maybe it was built in gutsy, or before.
<frafu> persia: it does not find it either. Could it be a "minus" vs "hyphen" problem?
<superm1> ugh.  someone uploaded another mplayer without updating bzr.
<norsetto> stevenk: was looking at merging bacula, and noticed gnome-session was added by you as a recommend to bacula-traymonitor. Do you believe this is still still needed?
<persia> frafu: No idea.  Try #launchpad
<frafu> persia: ok
<linux__alien> could some one here tell me is there any mailing list to contact the mentors in launchpad ?
<linux__alien> My prospective mentor has not given contact details :)
<persia> linux__alien: How was your prospective mentor assigned?
<linux__alien> persia, i found a topic which was very interesting and i clicked on the join button of the team and the person approved me thats it
<linux__alien> and ve been eager to contact the person and start working but i am not able to unfortunately :(
<persia> linux__alien: Which team?
<linux__alien> ya sure will give you the link https://launchpad.net/~gnome-uis
<linux__alien> GTK interfaces for Commandline Tools
<uniscript> highno: but it does continue despite the warnings
<linux__alien> thats the team persia
<persia> linux__alien: That team needs a wiki page, but https://launchpad.net/~seif might be a good person to ask how to get more involved.
 * uniscript responds to old post sorry
<linux__alien> true but unable to meet the person :(
<linux__alien> i dont have the email ID too ;(
<linux__alien> :(
<geser> frafu: buildds work on source packages so check for source package and not the binary one
<shibata> If I create file which is same name of package in debian/ directory, but when run debuild, its file is deleted (because its name is special for build?). How do I escape its problem? Can I create which with other name and rename when dh_install in debian/*.install file?
<geser> frafu: https://edge.launchpad.net/ubuntu/+source/gnome-panel/1:2.21.90-0ubuntu1/+build/501097
<persia> shibata: That only happens when you use CDBS.  dh_install cannot rename files.  Some people use a debian/contrib/ directory to work around it.
<persia> linux__alien: Hrm.  If they don't provide an email address, and you can't find them on IRC, and they haven't uploaded any packages (from which you could pull the email address), it's tricky.  You might try asking if anyone in #ubuntu-desktop can point you at something that needs doing.
<shibata> persia: It happens in kita2, I use debian/contrib.  Thank you.
<norsetto> stevenk: reason for asking is that now bacula-traymonitor suggests kde|gnome-desktop-environment and gnome-session is a dep of gnome-core (which is a dep of gnome-desktop-environment)
<frafu> geser: how did you get that link? Is there a search page?
<geser> frafu: first find out which source package is it (here gnome-panel), then to go https://edge.launchpad.net/ubuntu/+source/gnome-panel, click on "hardy" (in the version history), then "Show builds"
<frafu> geser: anyway;If I get it right, there is nevertheless something wrong going on as I can see the libpanel-... package with synaptic in my hardy i386 installation, but it does not show up among the built packages
<frafu> geser: thanks for the how to
<geser> frafu: https://edge.launchpad.net/ubuntu/hardy/+source/gnome-panel lists the successfully build "Binary Packages" with the arch
<geser> frafu: from looking at the build-log for gnome-panel in hppa it looks like gnome is there a mess currently
<frafu> geser: am I getting something wrong? libpanel-applet2-dev shows up in synaptic in my ubuntu hardy installation; consequently it has been successfully built for the i386 architecture. Correct?
<frafu> Consequently it should also show up here: https://edge.launchpad.net/ubuntu/hardy/+builds?build_text=libpanel-applet2-dev&build_state=all
<frafu> or am I getting something wrong?
<persia> frafu: apt-cache showsrc libpanel-applet2-dev ,ay be usefully instructive
<persia> s/,ay/may/
<Lutin> geser: could you have a look at the binutils-avr merge ? the debian/ubuntu diff seems ... kind of weird
<geser> frafu: only source packages have build records, and libpanel-applet2-dev is a binary one
<norsetto> whats up jpatrick?
<_MMA_> ScottK: If you wanna tackle another bite-sized bug like the Scribus one here ya go. Bug 189598 Thanx for the Scribus one BTW.
<ubotu> Launchpad bug 189598 in mixxx "Mixxx is missing icon (Hardy)" [Undecided,New] https://launchpad.net/bugs/189598
<dcordero> i have been fixing easy bug, like Depends problem, .desktop missing. But when i see a Bug like Bug #189553 i dont know how can i fix that, and it's marked as bitesize :/
<ubotu> Launchpad bug 189553 in jabref "crash on startup" [Undecided,New] https://launchpad.net/bugs/189553
<jpatrick> norsetto: I was pointing to: "< linux__alien> Hi i ve joined a team in launchpad.net and ve been eagerly waiting to start the tasks. the team had the mentoring option available but i am not able to contact the person who leads the team"
<geser> Lutin: ah that one :) binutils-avr is a native package. I had to change a symlink in the tar.gz to point to the right binutils.tar.gz from binutils-source
<linux__alien> jpatrick, i am here yes whats it :)
<geser> Lutin: and this change doesn't show up in the patch
<Lutin> geser: ahh ok :). thanks for the explanation
<norsetto> jpatrick: ah, thanks for pointing that out, I completely missed that
<norsetto> linux_alien: so, what team are you talking about?
<jpatrick> linux__alien: norsetto's the contact for the motu-mentoring team :)
<norsetto> jpatrick: yeah, but I'm not sure thats what he is looking for ;-)
<jpatrick> norsetto: me neither, but just in case ;-)
<linux__alien> hey thanks jpatrick let me become an Ubuntero . Am almost done in that process just one more step to finish and be right back here :)
<linux__alien> one sec
<linux__alien> :)
<linux__alien> jpatrick, i am stuck in the last step of becoming an Ubuntero I ve got the email from launchpad and ve installed the FireGPG also and now selected the Big Paragraph (key) and selected decrypt but FireGPG says that is not a valid PGP key
<jussi01> when running desktop-file-validate im getting the following error: warning: key "Encoding" in group "Desktop Entry" is deprecated
<jussi01> how do I fix?
<jussi01> is it simply to remove it?
<bddebian> jussi01: Yes, remove it from the desktop file
<jussi01> bddebian: thanks
<frafu> geser, persia: thanks; now it makes sense.  :)   (my first concrete example of a binary package that has a different name as the source; probably because the source produces more than one binary. )
<frafu> persia: you told me about the mousetweaks building failure due to a dependency to watch the status of libpanel-applet2-dev on hppa, and when that is looking healthy, ask for a give-back. How do I ask for a give back?
<frafu> persia: should I ask for it on #launchpad It?
<_MMA_> frafu: persia told me 5 mins or so ago he was going to bed. Maybe you'll get lucky and he's lurking.
<frafu> Maybe somebody else knows it: how can I ask for a give back of a package with a build failure due to a dependency?
<jussi01> could someone remind me of the command for extracting a package from a .dsc?
<pochu> frafu: you can ask in #ubuntu-devel, an archive admin will give it back.
<jussi01> nm, got it
<Hobbsee> frafu: ask a buildd admin in #ubuntu-devel
<Hobbsee> frafu: would be helpful to always mention which package, though
<frafu> pochu, Hobbsee: thanjks
<mathiaz> zul: so you were able to reproduce the mysql upgrade failure and using replaces+conflicts fixed the problem ?
<zul> yes
<jussi01> once ive added a patch to a bug, I then subscribe u-u-s?
<mathiaz> zul: seems like we're good to go for another upload
<zul> mathiaz: okies will upload :)
<linux__alien> norsetto, i ve become a Ubuntero
<linux__alien> norsetto, i am ready for the tasks :)
<joejaxx> what is the format for closing LP bugs through changelog entries again?
<joejaxx> * file
<joejaxx>    - TExt
<norsetto> linux__alien: good, what is it you would like to do?
<joejaxx>    (LP: #NUMBER) ?
<norsetto> joejaxx: LP: #xxxxxx
<joejaxx> norsetto: anywhere?
<norsetto> joejaxx: yes (but a logical place would help ;-))
<joejaxx> norsetto: ;)
<linux__alien> norsetto, some bug fixing to start with simple ones and then move to development :)
<linux__alien> norsetto, i ve contributed to couple of open source projects in the past
<zul> mathiaz: uploaded
<mathiaz> zul: great ! thks.
 * jussi01 is impatient... 
<linux__alien> norsetto, i ve only one computer ( a laptop which runs Ubuntu 7.10) i can download some packages and fix and test those packages separately thats what i am exactly looking for
<norsetto> linux__alien: it would be good if you start looking at some bugs then, concentrate on the ones in universe
<linux__alien> for example if there is gonna be a bug in a text editor download that text editor source, fix it , compile it and test it and submit it
<linux__alien> norsetto, before i start i want to be in constant touch so that i would go in the right direction as this is a huge project i dont want to go in an other direction so can you take me in your team if you can and i can be in contact with you through email and of course would log in here too
<linux__alien> norsetto, is that fine with you ?
<norsetto> linux__alien: well, I would suggest to start with something simple, to get your hand on the tools and processes, or you have them already under control?
<linux__alien> no norsetto i dont have them under the control so can you assign me the simplest ones so that i can get used to it
<norsetto> linux__alien: ok, perhaps it would be better to start reading some docs then, before you actually try to fix a bug?
<linux__alien> i can get used to the processes and tools as you say i dont even know what would be the easiest and toughest so it would be really good if you could mentor me :)
<slytherin> Can someone paste last attachment of bug 185917 in pastebin? I am getting timeout when trying to view it.
<ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
<linux__alien> norsetto, sure i could do it parallely and if you assign me a smallest thing i can do this and parallely work on it once i feel i am comfortable. what do you say ?
<linux__alien> do point me to the docs as well
<norsetto> linux__alien: you should really read this page first: https://wiki.ubuntu.com/MOTU/GettingStarted
<norsetto> linux__alien: all the links should be there to start you in the right direction
<linux__alien> ok sure will do that then ?
<norsetto> linux__alien: in the packaging guide there is an example that you should follow
<linux__alien> ok !!! will try that too
<linux__alien> i ll write a small software and package it too a Hello world and try it out for sure :)
<linux__alien> norsetto, one small thing if you dont mind do you ? :)
<shibata> persia, RainCT : I updated kita2: http://revu.tauware.de/details.py?package=kita2
<norsetto> linux__alien: of course I don't, what is it?
<linux__alien> just wanted to be in touch with you as i would like to take you as my mentor so i want to know how to contact you apart from IRC. i really like to know that
<linux__alien> norsetto, so that i could ask you doubts then and there and tell you my progress too
<norsetto> linux__alien: I'm pretty busy nowadays, I can't get really any more pupils right now
<linux__alien> me alone :)
<norsetto> linux__alien: I can help you with your first bug, thats no problem
<norsetto> linux__alien: everybody here can help you, just ask
<linux__alien> that would be the biggest task for me :) true hence i joined the launchpad but didnt get any updates :(
<linux__alien> thats why i became totally lost
 * LucidFox removes "linux" from the list of words that ping him :)
<norsetto> linux__alien: or ask in ubuntu-motu or ubuntu-motu-mentors (you should subscribe to these m.l. if you haven't done so already)
<linux__alien> i ve not done it what does MOTU stand for ?
<slytherin> Can someone paste last attachment of bug 185917 in pastebin? I am getting timeout when trying to view it. And please paste to pastebin.com
<ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
<LucidFox> linux__alien> Masters of the Universe
<LucidFox> named after the "universe" repository in Ubuntu
<linux__alien> what does mean
<linux__alien> what does that mean
<LucidFox> it means Ubuntu developers who contribute to the universe and multiverse repositories
<dcordero> Bug #189553
<ubotu> Launchpad bug 189553 in jabref "crash on startup" [Undecided,New] https://launchpad.net/bugs/189553
<linux__alien> Oh Ok
<LucidFox> (as opposed to core developers, who contribute to main and restricted)
<linux__alien> Universe and Multiverse contains free as well non-free softwares?
<slytherin> LucidFox: Need a favour
<mok0> ScottK: piinnnggg!
<LucidFox> linux__alien> universe contains free (as in freedom software) whose redistribution is not impended
<mok0> linux__alien: Universe contains only free software
<mok0> heh
<LucidFox> while multiverse contains non-free software, as well as free software with impended (for example, by patents) redistribution
<linux__alien> norsetto, so ok i ll start reading it and whats my first bug :)
<linux__alien> ?
<LucidFox> slytherin> How can I help?
<linux__alien> mok0, Multiverse?
<slytherin> LucidFox: Can you please paste last attachment of bug 185917 in pastebin? I am getting timeout when trying to view it. And please paste to pastebin.com
<ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
<mok0> linux__alien: see ^^^
<norsetto> linux__alien: once you have gone through the basics, we will look at some bugs
<linux__alien> norsetto, ok in that case give me a day's time i ll read through the MOTU/Getting Started link and then the packaging guide and get back here as soon as possible
<LucidFox> slytherin> http://paste.ubuntu.com/4260/
<norsetto> linux__alien: ok, if I'm not here ask and somebody will help you
<slytherin> LucidFox: thanks
<linux__alien> norsetto, sure will do that i ll subscribe to MOTU and MOTU-mentors mailing list
<LucidFox> linux__alien> Indeed. I, for example, will always be glad to help you on this channel.
<linux__alien> MOTU-mentors is for mentors or for people to be mentored?
<norsetto> linux__alien: both
<LucidFox> speaking of that control file, isn't build-depending on -jre pointless because -jdk pulls it?
<linux__alien> thanks a lot LucidFox norsetto
<norsetto> linux__alien: np
<LucidFox> Could someone please look at bug #187576 and sponsor the upload? I'm going to submit the package to Debian, but I'd like to have the entire Ubuntu history in the changelog, like I did for smplayer itself
<ubotu> Launchpad bug 187576 in smplayer-themes "Upgrade to smplayer-themes 0.1.15" [Wishlist,Confirmed] https://launchpad.net/bugs/187576
<LucidFox> (and RainCT, if you're here, I uploaded just the diff.gz - so you can use it rather than the interdiff)
<slytherin> persia: geser: FYI ... I have added the debdiff to bug 189602. I will be glad if you can make sure once more that lucene2 builds in pbuilder with this fix. :-)
<ubotu> Launchpad bug 189602 in lucene2 "Use local DTD to fix build failure on buildd" [Undecided,Confirmed] https://launchpad.net/bugs/189602
<LucidFox> Then go through slytherin's bug first. It's more important. :)
<slytherin> LucidFox: I would rather have it handled by persia or geser since they know all the context. I hope you don't mind. :-)
<mok0> Does anyone read & understand russian here?
<LucidFox> Ñ
<LucidFox> mok0> I'm a Russian
<mok0> LucidFox: Cool! Can you help me with a translation? Please look at bug  189554
<ubotu> Launchpad bug 189554 in courier "update from gutsy to hurdy fails on courier-mta" [Undecided,New] https://launchpad.net/bugs/189554
<mok0> LucidFox: Can you tell me what the error message is?
<LucidFox> mok0> replied in the bug
<LucidFox> there wasn't much to translate anyway :)
<mok0> LucidFox: super!
<mok0> LucidFox: I am trying to understand what the problem with this bug report is
<mok0> LucidFox: Heh! :-)
<mok0> Not much help there :-)
<LucidFox> I've asked for additional information
<mok0> LucidFox: thanks
<mok0> LucidFox: perhaps igor has a hard time with english
<neuroStuMIT> Hi, sorry to interrupt but I have a question: I am trying to build a deb package but I keep getting the following error when I run
<neuroStuMIT> $dpkg-buildpackage -rfakeroot
<neuroStuMIT> dpkg-buildpackage: unable to determine source package is
<mok0> neuroStuMIT:  are you in the right directory?
<neuroStuMIT> dpkg-parsechangelog: error: cannot open debian/changelog to find format: No such file or directory
<neuroStuMIT> dpkg-buildpackage: unable to determine source package is
<neuroStuMIT> yes I am one directory down from the src
<mok0> neuroStuMIT:  you need to be where the debian dir is
<neuroStuMIT> ok so I tried it in /package/debian/ and I got the same error
<neuroStuMIT> and in ~/package/
<mok0> you have to be in package/
<geser> does debian/changelog exist?
<neuroStuMIT> ok I just got it sorry
<neuroStuMIT> thanks
<neuroStuMIT> yes it does
<mok0> if you get something when you say ls debian/changelog you are in the right place
<LucidFox> mok0> in this case, I could translate in both directions - no later than yesterday I did that on IRC, synchronously :)
<mok0> LucidFox: nice!
<neuroStuMIT> what does this mean
<neuroStuMIT> dpkg-genchanges: error: badly formed line in files list file, line 1
<bobbo> Can someone give me a bit of help with Bug #188070? I need to know what version number the fix should have
<ubotu> Launchpad bug 188070 in showfsck "No need to be bash-specific" [Undecided,Confirmed] https://launchpad.net/bugs/188070
<geser> bobbo: the next version would be 1.4ubuntu2
<bobbo> Ok thanks
<RainCT> LucidFox: heh. still need someone to upload #187576?
<LucidFox> RainCT> yes
<LucidFox> and TheMuso told me that interdiffs are no longer needed - the diff.gz is sufficient
<RainCT> LucidFox: right, we decided against interdiff on the last MOTU meeting
<LucidFox> Awesome.
<slytherin> geser: I hope you saw my last message. :-)
<geser> slytherin: yes, I subscribed myself to that bug at will test-build it tomorrow (so the new w3c-dtd-xhtml is available on the mirror I use) and will sponsor it afterwards
<slytherin> geser: Thanks. :-) w3c-dtd-xhtml has already built successfully. Should be available on mirrors in few hours I guess
<geser> slytherin: I didn't get out how often and when the german mirror gets updated. It looks like once daily
<slytherin> geser: Anyway time for me to go home. See you tomorrow. :-)
<geser> LucidFox: re bug #189470: are the packages "sunbird" and "iceowl"? so could we drop "iceowl"?
<ubotu> Launchpad bug 189470 in iceowl "Restore Mozilla branding and blacklist iceowl from autosync" [Wishlist,New] https://launchpad.net/bugs/189470
<LucidFox> geser> There's no "sunbird" package
<LucidFox> I'm proposing repackaging iceowl as sunbird
<geser> !info sunbird hardy
<ubotu> sunbird (source: lightning-sunbird): Sunbird stand-alone Calendar. In component universe, is optional. Version 0.7+nobinonly-0ubuntu2 (hardy), package size 7792 kB, installed size 23212 kB
<geser> hardy has sunbird
<ryanakca> Hmm... favorite C++ IDE? I'm using vim at the moment...
<ryanakca> oops, wrong channel :)
 * ryanakca thought he was in -offtopic
<LucidFox> geser> Then iceowl can simply be removed from the archive and blacklisted
<RainCT> sistpoty|work: I've just read the "Copyright question" topic on debian-devel.. about your message there, I don't see that the license says anything about modifying or not modifying it, it just says that you have to leave the copyright notice on the files, you have to credit the university on programs using it and that you can't use the names of the authors for promotional use
<sistpoty|work> RainCT: and that's the point... it doesn't allow it (and hence it's not allowed)
<LucidFox> Original BSD license?
<sistpoty|work> nope, modified one, but quite similar
<RainCT> sistpoty|work: doesn't allow what?
<RainCT> ah
<mathiaz> zul: regarding your libxen3 diff, don't you need to replace/conflicts libxen3.1 also ?
<sistpoty|work> RainCT: if s.th. is not explicitely allowed by a license, it's not granted (hence no license at all -> nothing allowed)
<RainCT> sistpoty|work: okay I understand your point now, but it doesn't make sense.. if it wasn't allowed to modify it, there would be no need to say that you can't modify the copyright notice from the headers
<mathiaz> zul: there may be some issue with upgrades from gutsy
<LucidFox> geser> May I subscribe ubuntu-archive to the removal request directly, or do I need someone to approve it first?
<sistpoty|work> RainCT: good point... so maybe 1) could be interpreted to allow modification (apart from...), but I guess the license isn't the very best to not be more clear on this
<geser> LucidFox: an MOTU needs to ACK it or you wait till you are a MOTU yourself
<LucidFox> Thanks. I'll subscribe u-u-s then.
<LucidFox> RainCT, smplayer-themes reupload ping (in case you didn't see the one in PM)
<RainCT> LucidFox: I'm already downloading it :)
<LucidFox> ah, I see
<sistpoty|work> RainCT: looking at the standard BSD license, maybe there is s.th. not quoted in the mail, which does allow modification
<jdong> LucidFox: what do you need ack for?
<LucidFox> bug #189470
<ubotu> Launchpad bug 189470 in iceowl "Remove iceowl from the archive and blacklist from autosync" [Wishlist,New] https://launchpad.net/bugs/189470
<jdong> cool
<jdong> can't we just glob for (something_cold)(birdname)
<jdong> :D
<LucidFox> lol
<joejaxx> lol
<LucidFox> that's the one we were talking about - I also have a sync request from debian-multimedia in need of acking...
<joejaxx> anyone here particularly fond of python packaging?
<Amaranth> jdong: ice* except icecast?
<geser> jdong: good that tea is not a bird :)
<jdong> Amaranth: cast isn't a bird :)
<LucidFox> namely, Bug #182819
<ubotu> Launchpad bug 182819 in ubuntu "Please sync wxsvg 1.0b8.1-0.1 from debian-multimedia.org unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/182819
<joejaxx> lol
<Amaranth> oh, and icedtea
<joejaxx> there are looks of ice apckages
<joejaxx> icewm
<Amaranth> jdong: i meant for a match on stuff we don't want :P
<joejaxx> lol
<Amaranth> joejaxx: ehh, that one isn't important
<joejaxx> Amaranth: lol
<joejaxx> yess it is :)
<Amaranth> I have _never_ met someone who used icewm
<joejaxx> Amaranth: you met me :)
<joejaxx> lol
<Amaranth> lalalalalala
<joejaxx> :P
<Amaranth> I can't _hear_ you
 * Amaranth runs
<joejaxx> rofl
<mohbana_> hi guys i want to build something from source, what do i need to do? are there any guides available
 * sistpoty|work heads home
<sistpoty|work> cya
<zul> mathiaz: point
<RainCT> mohbana_: what is it what you want to build?
<mohbana_> wxdownlod fast
<RainCT> mohbana_: but you have te source for the package, or from the author's website?
<mohbana_> yes i got it from the site
<RainCT> mohbana_: then look if there's a README o INSTALL file or something like that where it explains how to do it
<warp10> Hi all!
<ScottK> _MMA_: I did the scribus one because I was working on scribus.  I don't have a generic interest in icon bugs.  Thanks.
<ScottK> mok0: Pong
<mok0> Hey ScottK!
<mok0> I have  a couple of comments to your comments
<ScottK> Welcome back to another fun day with Courier.
<ScottK> Sure
<mok0> ScottK: I just need to find the bug page
<afflux> whats the difference between Depends: xyz (< 5) and Depends: xyz (<< 5)?
<mok0> bug 188746
<ubotu> Launchpad bug 188746 in courier "[needs-merge] courier_0.58.0.20080127-1" [Undecided,In progress] https://launchpad.net/bugs/188746
<mok0> ScottK: about the init scripts: I think the ubuntu changes are still worthwhile.
<mok0> ScottK: it seems the Init headers are still somewhat lacking in the debian edition
<LucidFox> afflux: << 5 means all versions below 5, but not version 5 itself; <= 5 means all versions below 5 and version 5
<_MMA_> ScottK: I see. np. I got mixxx handled now.
<LucidFox> not sure about < 5, or whether it's even allowed
<norsetto> warp10: hey warpie
<afflux> LucidFox: okay, since it's "all versions below" what I want to have, I'll just use <<. Thanks.
<mok0> ScottK: and he's using echo instead of the proper log_* statements
<warp10> heya norsetto! Nice to see you around
<norsetto> won your battle against the evil empire of microbes?
<LucidFox> lol
<warp10> norsetto: nope... I asked a cease-fire, but they disagree -_-
<norsetto> warp10: nuke them
<warp10> norsetto: that would be great... if they are in another person's body :P
<ScottK> mok0: I agree about the log statement.
<norsetto> warp10: ah right, its always the little details that loose me
<warp10> norsetto: :D
<ScottK> The lsb header part of the init I would look very closely at.
<mok0> ScottK: Then there's your comment about ldap which I don't understand
<ScottK> mok0: The current Ubuntu ones I did about 8 months ago when I knew less than I did now, so don't assume they're right.
<ScottK> Look at the current package in Hardy.  It's got another revision.
 * norsetto -> dinner
<mok0> ScottK: there's some information about which processes should be running that is not in debian's
<ScottK> It was a new change rebuild for LDAP transition, so that debian/changelog entry needs to get added to the merged package.
<ScottK> mok0: Right and I don't know which is right.
<ScottK> mok0: Does that make sense?
<mok0> ScottK: init scripts: I will look more carefully.
<mok0> ScottK: ldap transistion: is that in ubuntu?
<ScottK> mok0: Yes.  slangasek did a no change rebuild last night or this morning.
<mok0> ScottK: no change rebuild? Of the old version?
<ScottK> Yes
<ScottK> https://launchpad.net/ubuntu/hardy/+source/courier/0.58.0-1ubuntu2
<mok0> ScottK: ok
<ScottK> All you need to do for that is add his debian/changelog entry into your package and then re-diff debian/changelog
<mok0> ScottK: so, the new version incorporates some changes that are needed for the ldap transistion?
<mok0> ScottK: sure, I just want to understand what the changelog entry should say :-)
<ScottK> No.  The code isn't changed, it's just built against the newer library version so it's linked to the shared libraries differently.
<ScottK> You should grab the current Hardy package and copy/paste the one that's in there.
<mok0> ScottK: Got it. finally.
<mok0> :-)
<ScottK> No problem.
<mok0> ScottK: next, is your torque comment.
<ScottK> Yes.
<mok0> Have you seen my reply?
<ScottK> No.  Just got back to my desk from a meeting
<mok0> http://revu.ubuntuwire.com/details.py?package=torque
 * ScottK looks
<ScottK> mok0: Perfectly reasonable answer.  Sounds good.
<mok0> ScottK: Great...
<ScottK> I suspect I'll advocate it, but haven't finished reviewing  yet.
<mok0> ScottK: but now the package has the "Needs work" icon, and I don't know what to do
<mok0> ScottK: ok
<ScottK> It was a bit of a suprise when I tested your watch file and it found a new version.
<mok0> thx
<mok0> ScottK: I understand...
<ScottK> I wanted to get the question out there and get it answered rather than leave it sitting.
<mok0> ScottK: good point. I guess most developers are still not on the newest version of gcc
<ScottK> Makes sense
<mok0> ScottK: It'd be great if you have time to review it.
<ScottK> I'll try and work time to finish it into the next 24-48 hours.
<mok0> ScottK: That's perfect
<ScottK> mok0: You're planning on looking at the courier postinst bug too, right?
<mok0> ScottK: Yeah, I got LucidFox to translate :-)
<ScottK> Great.
<mok0> ScottK: not that it helped much :-)
<ScottK> Yeah.
<mok0> It might be difficult to reproduce
<mok0> But I will check the script carefully
<vorian> ping warp10
 * norsetto <- dinner
<jdong> ScottK: ping, regarding 145805
<jdong> ScottK: am I correct in understanding that just a no-source-change rebuild is necessary to resolve the issue?
<ScottK> That's what I understand from reading the bug.
<jdong> ScottK: in all their quibbling it's really not clear what on earth is actually going on
<ScottK> Henrik set the bug to invalid when he should have said fix released and looked into SRU.  The bug filer is apparently a somehat prominent blogger and it's all downhill from there.
<jdong> ScottK: *sigh* well I replied to the bug hoping to get a clearer description
<jdong> ScottK: I have a feeling the response will be quick... and probably not pretty
<dcordero> hi
<ScottK> mok0: Did you run your .debs through the current lintian for torque?
<chillywilly> man I hate RHEL...
<chillywilly> up2date sucks compares to apt
<ScottK> mok0: 6 errors, 26 warnings (some of which I can see just need over-rides), and I didn't count the info notices.
<jdong> chillywilly: well that's why it was replaced with yum
<warp10> vorian: pong
<vorian> :)
<vorian> warp10: I had the upgrade ready, I just wanted to check with you first since you assigned yourself
<chillywilly> jdong: yea but I don't see yum available with this old RHEL4 install...
<warp10> vorian: well, really I have been subscribed to the bug by someone else, just a mistake. I was trying to unsubscribe myself but my network just crashed :S
<vorian> warp10: :)
<vorian> no worries
<vorian> That's what I wanted to check
<warp10> vorian: great :)
<vorian> thanks warp10 :)
<warp10> vorian: np ;)
<mohbana_> does anyone use adobe reader instead of the evince that comes with ubuntu?
<ion_> Hopefully not. :-)
<mohbana_> evince doesnt render fonts properly, when i view some documents they appear blury
<ScottK> Does evince support data input to encrypted PDFs?
<ScottK> kpdf does not (at least in Gutsy).
<mok0> ScottK: It's been a while since I last compiled torque. Sorry, my bad.
<ScottK> mok0: No problem.  It's just that you were wondering what to do next ;-)
<mok0> ScottK: heh, I will take a look.
<mok0> ScottK: I found a possible explanation of 189554
<ScottK> Excellent.
<mok0> ScottK: The script will fail if /etc/courier for some reason does not exist
<TheMuso> ScottK: I'd poke the tech board mailing list about your application. I think its been lost in the pile somewhere.
<ScottK> TheMuso: I agree.  I'm trying to figure a polite way to do it.  I need to probaby wait a day for that.
<TheMuso> ScottK: right
<Coper> ScottK: are you the same as ScottK2?
<ScottK> Coper: Yes
<ScottK> That's my laptop
<Coper> You added a comment to console-freecell about using hyphen as minus sign.
<ScottK> Yes
<Coper> Is that a problem with my package or is it a problem with the upstream?
<ScottK> In the man page source you need to properly escape the hyphen.  It's just \- instead of -
<ScottK> I don't recall if the man page is upstream or in debian/
<Coper> hmm, so do I just add a patch in debian/patch or just change in the man source file?
<ScottK> You should patch it.  Is the upstream active for this game?
<Coper> The doc/freecell.6 exist in the tar.gz file that I has build my package from.
<ScottK> Yes.  So it should be patched.  If your upstream is active, you might ask them to fix it and re-rekease,
<ScottK> If you had that committment, I'd be willing to advocate now with you just modifying the upstream  source directly.
<Coper> okej, so I just have to change all - to \- in all places in tha man source file and rebuild my dsc file
<ScottK2> Coper: If you get upstream to agree to fix it.  Otherwise it's add dpatch and patch it.
<HighNo> I need help (hopefully the last time) with building my package for REVU. It seems that every howto states I only should "dpkg-buildpackage -S -sa -rfakeroot" and upload the _source.changes to REVU. But I don't get it - it only is a signed part of the changelog. How can anybody rebuild my package with just that information?
<smarter> HighNo: when you do "dput revu foo_source.changes" foo.orig.tar.gz, foo.dsc and foo.diff.gz are also uploaded
<HighNo> ok, that makes sense
<smarter> the .changes file is just here to list them
<smarter> and to check the md5 sum
<HighNo> so that's why they are in there...
<smarter> and instead of dpkg-buildpackage ... you can do "debuild -S -sa"
<HighNo> can or must do?
<smarter> I'm not an expert but afaik it's the same
<smarter> except it's shorter :)
<HighNo> :-)
<HighNo> grrrrrr. I start thinking I am stupid. I just can't build my package for hardy...
<HighNo> why on earth do I get this error from dput/lintian: E: blueproximity_1.2.2_source.changes: bad-distribution-in-changes-file hardy
<smarter> HighNo: are you using gutsy?
<HighNo> I am using feisty but I have setup a bpuilder environment with hardy bootstrap
<smarter> Does this error prevent you from uploading your package?
<HighNo> yes
<smarter> what's the revision number of your package?
<smarter> should be 1.2.2-0ubuntu1
<HighNo> ok, so where do I have to put that? in the changelog? so I have to adapt the dch command?
<smarter> yes, it's in debian/changelog
<ScottK2> HighNo: Just edit the version number in your debian/changelog entry
<HighNo> ok, another question then - does the debian changelog file reflect the overall changes that the upstream package made or does it reflect the changes I have made to the upstrem package to get it running with ubuntu?
<smarter> HighNo: Changes you made
<smarter> usually, in the initial version of the package "  * Initial release (LP: #XXXXXXXX)" is enough
<HighNo> hm, so the real changes/advances of a new version don't make it into this file but some hidden changelog anywhere in the package's docs?
<smarter> usually, the changelog is automatically(except if the changelog file has a weird name) installed in /usr/share/doc/name-of-your-package/changelog.gz
<Coper> Do I have to add patch somewhere in my rules file to patch my package?
<smarter> HighNo: you should read https://wiki.ubuntu.com/PackagingGuide/Complete
<smarter> Coper: patch system: https://wiki.ubuntu.com/PackagingGuide/Complete#head-21ed4ac3719256a0ce4c5f563206591eb5448329
<HighNo> smarter: I like the idea because I am also the author of the upstream package and did not like creating a doubled changelog. I guess my debian changelog is never filled with anything but plain releases then...
<smarter> that's not a problem
<HighNo> smarter: I did read so much but probably too much and couldn't focus on the right things
<Coper> smarter: yes I'm reading following example one and added the patch: patch-stamp to the rules file but don't I have to add anything more to my rules file the in that page?
<smarter> Coper: if you're using CDBS you just need to add "include /usr/share/cdbs/1/rules/simple-patchsys.mk" and no stamp things
<smarter> HighNo: add this to your debian/rules: DEB_INSTALL_CHANGELOGS_ALL := ChangeLog
<smarter> (if your changelog file is named ChangeLog)
<Coper> smarter: okey, but I don't use CDBS but only debhelper.
<smarter> Coper: I don't know how to proceed with pure debhelper, sorry
<Coper> okey, I think that I rewrite my package with cdbs then.
<smarter> that will be easier I think :)
<geser> Coper: which patch system do you want to use?
 * jdong should try cdbs one of these days
<jdong> always been on my todo list
<HighNo> smarter: thanks, I will try
<ion_> Itâs usually nice. :-)
<jpatrick> jdong: you don't know what you're missing, mate
<jdong> jpatrick: that's what people have been telling me :)
<pochu> What's the way to proceed if I uploaded a package to the archive instead of to REVU? The package is intended to go to the archive but I wanted to upload it to REVU so it got a review first...
<jdong> pochu: probably poke an archive admin to nix it
<pochu> At least the policy allows MOTUs to upload packages on their own... :-)
<TheMuso> jdong: For the cases where cdbs can be used, it is VERY good.
<jdong> TheMuso: the cdbs propaganda appears very compelling :)
<TheMuso> jdong: If the package usese configure/make etc, its golden.
<TheMuso> uses
<TheMuso> Either that, or packages using python-distutils.
<joejaxx> recommends are *only* installed by default for metapackages?
<joejaxx> as that is what it looks like in apt.conf.d
<TheMuso> And sure, other cases can be made to work, but they require a little more knowledge of cdbs.
<soren> joejaxx: Right.
<joejaxx> soren: ok great just wanted to clarify :D
<soren> joejaxx: And only for metapackages in main.
<soren> joejaxx: iirc.
<joejaxx> soren: it looks like the other sections are there as well
<soren> joejaxx: Oh, so they are.
<joejaxx> :D
<soren> joejaxx: I'm living in the past, clearly.
<joejaxx> soren: hey atleast you had a definite answer for me :D
<joejaxx> soren: i just wanted to confirm :D thanks :D
<soren> joejaxx: np :)
<soren> joejaxx: I'm full of definite answers. Some of them are even correct. It's pretty cool.
<joejaxx> soren: lol :P
<pochu> Anyone can have a look and tell me the package is nice? :) http://revu.ubuntuwire.com/details.py?package=emesene
<mok0> ScottK: New courier patch in LP
<gilir> hi
<DRebellion> Would somebody mind sparing a moment to review my first (=D) package? http://revu.tauware.de/details.py?package=monkeystudio
<HighNo> whooohooo, thanks to all. My first package is finally upped at revu. When/where can I see it on the webpage? It's called 'blueproximity'
<saivann> Is there someone from the ubuntu sponsors for universe team that can take a look at bug 181417 ? Actual libofx package in ubuntu contains non free files, that can be fixed by merging the package from debian which is the new fixed upstream release
<ubotu> Launchpad bug 181417 in libofx "Please merge 0.9.0 from debian unstable" [High,New] https://launchpad.net/bugs/181417
<crimsun> saivann: generally sponsors approve and upload tested source packages (i.e., attached debdiffs)
<crimsun> saivann: namely, the debdiff should be attached already when requesting a sponsor.
<saivann> crimsun : Ok, I'll do that right now then
<RainCT> persia: does your advocation for kita2 still apply?
<ScottK> mok0: Thanks.
<mok0> DRebellion: I put some comments on revu. Didn't try to build though
<DRebellion> mok0: thanks, I'm I'll take a look (it does build :P)
<ScottK> DRebellion: Did you run lintian on the .deb(s)?
<DRebellion> :/ that I forgot. I'll have to work on it tomorrow now
<RainCT> good night
<norsetto> pochu: there is a little problem with uscan due to the funny version numbering upstream is using
<HighNo> what steps are necessary to make an uploaded file (dput to revu) appear on the website? I did not get any error message but it is not popping up since almost 30 mins now. the name is blueproximity
<ember> can someone have a look/review "deskscribe" http://revu.tauware.de/details.py?upid=995
<HighNo> Package and changes are signed and lintian is happy too.
<TheMuso> HighNo: Have you followed all the steps to get going with revu, including joining the appropriate launchpad team? I can't think of its name right now.
<vorian> https://launchpad.net/~ubuntu-universe-contributors
<HighNo> TheMuso: yes, I have joined that group yesterday and also uploaded and registered my gpgkey
<TheMuso> vorian: Thanks.
<vorian> no problemo :)
<TheMuso> Right. I am guessing the keyring needs to be synced.
<TheMuso> And, I can't do that unfortunately.
<HighNo> TheMuso: that can be true, I have registered two keys but the second one is the one I used and it was registered today...
<HighNo> TheMuso: will my upload be recognized after syncing the keyring or do I have to upload again?
<TheMuso> HighNo: I am not sure.
<TheMuso> Ok. Looks like I can sync.
<HighNo> TheMuso: please tell me when I should try to upload again
<TheMuso> or not
<HighNo> :-/
<TheMuso> no I can't sync it seems
<HighNo> But I guess you can tell me when the next sync is due?
<TheMuso> No I am not sure whether they sync automatically or not.
<HighNo> I've read (in the many many wiki pages I read yesterday and today) that the keyring is synced once per day automatically
<TheMuso> Right.
<norsetto> g'night all
<Legendario> hello
<Legendario> is there a way to specify the path ok the make file on the cdbs debian/rules ?
<Legendario> can anyone here tell me this?
<ion_> DEB_MAKE_MAKEFILE
<saivann> Is there someone from the ubuntu sponsors for universe team that can take a look at bug 181417 ? Actual libofx package in ubuntu contains non free files, that can be fixed by merging the package from debian which is the new fixed upstream release
<ubotu> Launchpad bug 181417 in libofx "Please merge 0.9.0 from debian unstable" [High,New] https://launchpad.net/bugs/181417
#ubuntu-motu 2008-02-07
<Legendario> ion_, thanks. Do i have to build the source again?
<jdong> what's the etiquette with the /^REVU: New/ messages on ubuntu-motu? When should they be sent, etc?
<crimsun> after you've uploaded and received the NEW.
<Legendario> got make erro number 2
<Legendario> No rule to make target `/home/kemel/Downloads/Cube/cube-2005.08.29/enet'.  Stop.
<Legendario> any clues?
<jdong> crimsun: ah, okay. Good to know :)
<sladen> Legendario: broken make file?
<Legendario> sladen, i guess not... it was not finding the make file that was not on the usual place. So i used the DEB_MAKE_MAKEFILE string ion_ have given me
<Legendario> but now i got this message.
<ion_> Perhaps you need to give something called enet to it before building.
<Legendario> no, the /enet is the folder where the make file is
<Legendario> ion_
<Legendario> am i doing something wrong. i wrote on the debian/rules:
<Legendario> DEB_MAKE_MAKEFILE = /home/kemel/Downloads/Cube/cube-2005.08.29/enet
<mok0> ScottK: New courier patch... :-/
<mok0> ScottK: Not proud of that...
<ion_> legendario: Use a relative path, and thatâs not the full path to the Makefile. If you want -C instead of -f, thereâs a CDBS variable for that as well.
<Legendario> ion_, sorry. could u be more specific?
<ion_> legendario: DEB_BUILDDIR is passed as the -C parameter and DEB_MAKE_MAKEFILE as the -f parameter. See make(1). Neither should be an absolute path.
<ScottK> mok0: Stuff happens.  I didn't suggest you do courier because it would be easy.
<mok0> ScottK: I knew as soon as I hit return that it was a mistake. I should've reverted it before I uploaded the patch, but I only thought of diff -b after your comment
<ScottK> No problem.  I'll try and have a look at it tonight.
<mok0> ScottK: The init scripts are a bit closer to the debian version. I slightly modified the postinst scripts to make sure /etc/courier exists. I don't know if that explains the russian guys problems, it's a bit far fetched for an upgrade.
<ScottK> Usually it's /var/run on a tempfs disappearing when they reboot in the middle of an upgrade to 'fix' something.
<Legendario> ion_, so how should i write on the file?
<ScottK2> Legendario: Is the package named Cube and your current version is cube-2005.08.29?
<Legendario> Scottk2, yes.
<ScottK2> What you probably want is $(CURDIR)/enet.  That's a relative path from with the package structure to /home/kemel/Downloads/Cube/cube-2005.08.29/enet
<Legendario> ScottK2, thanks dude. That's probably the solution.
<ScottK2> No problem.
<Legendario> ScottK2, so. it would be: DEB_MAKE_MAKEFILE = ($CURDIR)/enet
<Legendario> right?
<ScottK2> I think so.
<Legendario> great. :-D
<Legendario> let me try it
<Legendario> ScottK2 still getting error2
<Legendario> /bin/sh: Syntax error: "(" unexpected
<Legendario> make: *** [debian/stamp-makefile-build] Error 2
<ScottK2> OK.  Well play around with it.  That's the sort of syntax yo uwant.
<ion_> First, you do not pass a directory to -f, but a filename. Second, you might want -C instead, see make(1). Third, you probably wonât need $(CURDIR) in front of enet. Fourth, $(, not ($
 * StevenK sighs. I need notes of what I did so I can undo it again
<ion_> Look at the version control history.
<ScottK2> rm -rf *
<StevenK> ion_: This doesn't help when I'm hacking files directly on an install
<ScottK2> That'll take you back to where you started.
<TheMuso> StevenK: Still battling that segfault?
<StevenK> ScottK2: I've been looking at this problem for the better part of 15 hours, it so won't.
<RAOF> Hm.  How's this for a copyright header "GNOME Do is the legal property of its developers.  Please refer to the COPYRIGHT file distributed with this source distribution", then the standard GPL headers.
<StevenK> TheMuso: Yup.
<ScottK2> Oh.  Nevermind.
<RAOF> StevenK: That sounds particularly suckworthy.
 * StevenK thinks he has sorted it out
<zul> evening
<ScottK2> Yes it is.
<StevenK> ScottK2: And how sarcastic is your mood tonight?
<ScottK2> Middle sarcastic.
<slangasek> Anglo-Sarcastic with some Norman influence
<crimsun> saivann: did you file #189790?
<ScottK2> It can't be as bad as the MOTU that filed a but with Debian suggesting they incorporate our change in a package and remove the iceweasel symlinks.
<saivann> crimsun : Yes
<Legendario> i gotta go now... thanks for all the help. I'll be back if in need.
<TheMuso> ScottK2: ouch
<ScottK2> Yeah.  I've spoken to him about it.  He feels bad.
<TheMuso> ScottK2: Whoever did that needs to be publically shamed.
<TheMuso> IMO
<ScottK2> I think we've had enough of that for a while.  I figure I'll write a mail to the MOTU ML soon and anyone who wants to know who it is can figure it out.
<ScottK2> Just as a reminder.
<crimsun> saivann: while the current source package is suboptimal (!), to ship the binary tarball with the source package is a violation of their license.
<TheMuso> ScottK2: Fair enough.
<saivann> crimsun : Do you think that it could be considered as a potential long-term solution for the actual problems with flashplugin?
<StevenK> ScottK2: Shall we say it was TheMuso and publically shame him?
 * StevenK chuckles
 * TheMuso gawks at the storm out the window. That storm shoudln't be for another 3/4 hours. :p
 * ScottK2 smiles
<TheMuso> StevenK: Oh very nice.
<StevenK> TheMuso: Sorry, I couldn't resist.
<RAOF> TheMuso: What?  You've got the storm too?
<ScottK2> I don't think I've seen StevenK and nice in the same sentence before.
<TheMuso> RAOF: Yeah, one popped up out of nowhere.
<StevenK> It looks stormy here too
<saivann> crimsun : That's why I suggest canonical to look if it's possible to have these special rights, but perhaps that I'm too much idealistic
<crimsun> saivann: if Canonical were to obtain such a permission, I see no reason for it to even exist.
<ScottK2> It mostly looks dark here.
<TheMuso> Although it doesn't look like its going to either last long, or give much of a problem.
<crimsun> saivann: the point is that as the license currently stands, including the tarball with the source package is a no-go.
<saivann> crimsun : Right, would you suggest to set the bug to wontfix?
<TheMuso> Lightning sounds like its only cloud to cloud, judging by thunder clap sound.
<crimsun> saivann: I would, correct.
<saivann> crimsun : Thanks for your confirmation on this
<ScottK2> I'm probably just bitter about Canonical core-dev applicants getting head of the line priviledges.
<TheMuso> ScottK2: I agree with you, even though I'm no longer in such a position.
<ScottK2> If that were the policy, then I'd be fine with it.
<crimsun> TheMuso: yay, you're core now?
<TheMuso> crimsun: No.
<TheMuso> Not yet.
<crimsun> d'oh
<TheMuso> Was supposed to be last week, but only mdz was around for the meeting, so it didn't happen.
<TheMuso> So next week.
<crimsun> excellent, right on FF
<ScottK2> If they took as in straight order, I'd have been next.
<ScottK2> Instead there are two Canonical employees stuffed in ahead.  One of which was one day after the MC gave their approval.
<ScottK2> I also asked him if there was any reason he knew of to rush his application and he said no.
<TheMuso> crimsun: Better than nothing.
<TheMuso> Yay. Manual merge complete. Now to test.
<ScottK2> Does anyone know if Debian mia-query works for non-DD maintainers (and if so is there someone with access who'd be willing to check on something for me?).
<bddebian> Heya gang
<ScottK2> Heya bddebian
<bddebian> Hi ScottK2
<uniscript> is it my imagination or did pbuilder change syntax from say pbuilder build to pbuilder --build?
<TheMuso> StevenK: I take it from your upload, things are fixed?
<StevenK> Looks like
<Hobbsee> ScottK2: they still *should* be able to do 3 at once, i thought
<ScottK2> Hobbsee: There are already 2 Canonical employees added today.
<effie_jayx> is it possible to do an package upgrade when upstream has not documented the changes properly ? I have removed all the files that got removed in the new version
<Hobbsee> ScottK2: they can't do 3 total?
<effie_jayx> but the added files are the ones I should include in the install
<ScottK2> Hobbsee: I don't know how many they can do.  There are now three on the agenda.
 * effie_jayx thinks about droping the idea
<ScottK2> effie_jayx: If they messed up the release tarball and put wrong files in it, ask them to release a new one.
<ScottK2> Hobbsee: I just don't get any sign they are interested in community applicants right now.
<Hobbsee> ScottK2: perhaps so - but i didn't think they were all canonical members on the TB
<effie_jayx> ScottK,  the source package from upstream has no changelog that can really document the changes to the software
<TheMuso> Hobbsee: Only mjg59 is not Canonical.
<Hobbsee> ah right
<ScottK2> effie_jayx: Then you can document the changes in debian/changelog.
<effie_jayx> I think I am not making myself understood :S
<effie_jayx> 1) the URL to the proyect in debian/copyright is not the url to the proyect anymore.
<effie_jayx> 2) upstream released 2.2 without a comprehensive list of changes from 1.1
<effie_jayx> hence it would explaing why the packages is orphan in debian
<ScottK2> Is it the same upstream moving to a new location or a new developer that's grabbed/forked the package?
<effie_jayx> yet we have ubuntu users saying... "I emailed the developer he says we should upgrade to 2 as version 1 is not supported"
<effie_jayx> ScottK2, same developer
<effie_jayx> ScottK2, http://kipina.sourceforge.net/
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<ScottK2> Then update debian/copyright to the new location and document the changes as best you can in debian/changelog.
<effie_jayx> ScottK2,  right... If I could only figure out the changes made by the developer... aparently the package is missing files (the ones version from 0.1.1) and the new files that the developer included are ????
<ScottK2> Right.  It doesn't have to be detailed.
<effie_jayx> I removed files from kipina.install but what are the new files he included
<ScottK2> If he's using sourceforge and their CVS, there will be commit logs that might be useful.
<effie_jayx> ScottK2,  :S
<effie_jayx> ScottK2,  you have to admit I did pick a tought scenario for a beginner to be in ;)
 * effie_jayx has a knack for dead ends 
<jdong> poor effie_jayx, it seems like all the bugs you pick are cursed :)
<TheMuso> effie_jayx: THink of it this way. Its making you a better MOTU in the process.
<effie_jayx> well, It is frustrating as well
 * effie_jayx looks for a bug to fix in something like xteddy 
<effie_jayx> :D
<TheMuso> Yes, true.
<effie_jayx> nah really. I'll put it to rest for a week and see... a new bug is what I need
<leonel> scottK I had no time today to check that list tomorrow I MUST give time to it  I hope it's not too late
<jdong> effie_jayx: I'll think of you and keep my eyes open as I triage bugs for things that might have happier endings :)
<effie_jayx> jdong,  I'll step up. I promiss
<jdong> :)
<ScottK> leonel: No.  Not to late.
 * jdong looks at KTorrent in gutsy and wonders if it's massive SRU time again :(
<jdong> urgh I hate telling people "this crash is fixed in gutsy-backports"
<jdong> the problem is, there's about 5 distinctive crasher bugs, none of which can be readily reproduced in a 1-2-3 step method, it's all highly dependent on specific circumstances...
<jdong> the last KT SRU took nearly 3 months to roll out and by that time it was already pretty useless
<rootvzla> hi ^^
<TheMuso> If I remember correctly, if an orig tarball is repacked, the tarball name shoudl reflect that correct?
<jdong> TheMuso: yeah, either .dfsg or [\.+]repack
<TheMuso> jdong: Right, thanks.
<TheMuso> jdong: -EPARSE
<jdong> TheMuso: I don't know if it's our mandatory policy, but usually get-orig-source in debian/rules to auto-do the repack?
<TheMuso> jdong: right
<jdong> TheMuso: regex, .repack, +repack, etc
<TheMuso> jdong: Regexps are not my strong point. I assume you mean packagename.repack.orig.tar.gz
<jdong> sorry, I've been (over)using regex a lot recently... it's made it into everyday conversations too
<TheMuso> scary
<jdong> packagename_upstreamver.repack1.orig.tar.gz
<jdong> or +repack1
 * TheMuso tres to think of a nice way to say "use google" on a mailing list
<TheMuso> right
<TheMuso> thanks
<jdong> sure thing :)
<superm1> TheMuso, you perform the search with some terms and copy the url that's in your address bar, and say "in the future, you can find answers to similar things like this"
<TheMuso> superm1: Right. Its someone who couldn'
<TheMuso> argh
<TheMuso> superm1: Right. Its someone who couldn't be bothered doing their own googling.
<superm1> yeah so you just give them the nudge with the example google search
<TheMuso> So in that case, I couldn't be bothered googling myself.
<superm1> and hope that they get the right idea
<TheMuso> right
<TheMuso> Right. Thats out of the way.
<ScottK2> TheMuso: You can always hand them a copy of this: http://www.sabi.co.uk/Notes/linuxHelpAsk.html
<ScottK2> I didn't mean that one.  Oops
<TheMuso> ScottK2: If he bothers me again, I will.
<ScottK2> I meant this one http://www.catb.org/~esr/faqs/smart-questions.html
<TheMuso> thanks
<TheMuso> ember: Thanks for your prompt update.
<TheMuso> I'll take another look.
 * TheMuso thinks about writing a message to -motu about checking copyright notices in REVU packages. I've found a package that appears to have been rejected, and it had one ACK, yet the licensing to me appears incorrect, re debian/copyright.
<ScottK> TheMuso: Please do.  I've been pondering the same thing myself.
<TheMuso> ScottK: Just to be clear, the library GPL is not the same as the lesser GPL is it.
<ScottK> One is version 2 and one is version 2.1/3.  I always have to look it up.
<TheMuso> right
<ScottK> IIRC 2 == lesser
<TheMuso> yep you're correct
<ScottK> So far I've caused two repacked tarballs this due to non-distributable/linkable stuff that others missed.
<TheMuso> heh
<TheMuso> So far I've knocked back a package because of debian/copyright stating lesser, when its library
<TheMuso> Hrm. I think I'll return to a package update now.
<ScottK> Of course no one's perfect.  During the Gutsy cycle I downchecked a package due to debian/copyright deficiencies that had been put on REVU by an archive admin.
<TheMuso> Right. heh.
<Hobbsee> that wasn't me
 * Hobbsee just has the advantage of not doing new packages.
<jdong> Hobbsee: makes life happier :)
<Hobbsee> ScottK: i like your mail
<TheMuso> ScottK: Yeah, me too.
<Hobbsee> awww, shit.
<jdong> ScottK: yeah, me $last+1
<TheMuso> Oh well, upstream don't look like they're going to do a new upstream release any time, guess I'll upload this snapshot with tons of bug fixes in it.
<TheMuso> c/
<ScottK> Thanks
<LucidFox> speaking of +1, this reminds me
<LucidFox> Is it known when the name of Hardy+1 will be revealed?
<ScottK> Probably just after it's to late to upload a lintian that knows about it for Hardy's release.
 * Hobbsee snorts
<Hobbsee> ScottK: good answer
<TheMuso> lol
<jdong> Jumpy.......
<jdong> umm.....
<jdong> jackrabbit?
<jdong> the release of ridiculous visual effects?
<jdong> or where  we get bouncy dock icons?
<ScottK> Itchy Iguana
<LucidFox> I'm 90% certain it will be Itchy, but no sure about the animal
 * StevenK doesn't like the sound of Itchy
<RAOF> jdong: Too late; bouncy dock icons are here *now* (lp:awn)
<AnAnt> Hello, I am using cdbs, and I need to pass a -l<path> to dh_shlibdeps, how can I do that ?
<ion_> DEB_SHLIBDEPS_INCLUDE_packagename, or DEB_SHLIBDEPS_INCLUDE for all packages
<AnAnt> oh, thanks
<AnAnt> ion_: where can I find such info ?
<ion_> I just looked at the cdbs source.
<ion_> cd /usr/share/cdbs/1, grep -r shlibdeps ., oh, thereâs an DEB_DH_SHLIBDEPS_ARGS, grep -r DEB_DH_SHLIBDEPS_ARGS ., oh, its definition contains -l $(shell echo $(DEB_SHLIBDEPS_INCLUDE_$(cdbs_curpkg)):$(DEB_SHLIBDEPS_INCLUDE) | perl -pe 's/ /:/g;')
<AnAnt> I see, thanks
<Hobbsee> ScottK: your mail really does scare me.
<slytherin> geser: Is there any work remaining from my side on lucene2? Or is it just that you are very busy? :-)
<theseinfeld> anybody up for checking the http://revu.tauware.de/details.py?package=libdc1394-22
<theseinfeld> It should be clean now for all errors :)
<dholbach> good morning
 * LucidFox bods
<LucidFox> * nods
<Iulian> Morning dholbach
<HighNo> oh no, is't me again... short question: when I create the base structure of the deb package with "dh_make -c gpl -b --createorig" I will be asked for a version. Do I enter the upstream version or the complete ubuntu version? (blueproximity-1.2.2 vs. blueproximity-1.2.2-0ubuntu1)...
<man-di> upstream version
<HighNo> thx
<HighNo> can anybody please check why my uploads to revu don't work? my key id is  DSA key ID 2298A62D for  "Lars Friedrichs <LarsFriedrichs@gmx.de>"
<HighNo> dput gives no error, the package is lintian clean and it does not pop up on the revu website.
<slytherin> HighNo: what do you mean by don't work?
<HighNo> dput states: "Successfully uploaded packages." (to revu.tauware.de) but I can't see my package appearing on the revu website.
<HighNo> is the server revu.tauware.de ok? I did not change the preset settings of dput.
<HighNo> slytherin: this is what dput gives me: http://pastebin.com/d578db3ee
<slytherin> HighNo: there is no error, I think it will take some time before the packages show up on revu
<HighNo> slytherin: do you know how long that would be? As I followed some discussion here yesterday stating "I just uploaded bla, can someone have a look at it please" and I saw it immediatly on the website. That's what kept confusing me.
<mok0> HighNo: Remember, you need to build the source package (-S -sa) and upload the _source.changes file
<slytherin> I don't know exact time but should be less than an hour
<mok0> Uploads to REVU should show up after 10 minutes max
<mok0> The cron job runs at 10, 20, 30, ...
<HighNo> moko: that explains the nice timestamps with the packages :-)
<HighNo> mok0: but sadly - it does not tell me why my package does not show up as ten minutes are gone by now
<mok0> HighNo: you probably uploaded a binary package
<HighNo> mok0: this is my dput output: http://pastebin.com/d578db3ee
<mok0> Is your sig in REVU's keyring?
<mok0> Oh
<jeromeg> anyone to review my merge of gnome-chemistry-utils ( bug 188404 ) ? Thanks
<mok0> HighNo: Hm I dunno, you have to find an admin that has access to REVU
<lionel> jeromeg: I'm on the U-U-S queue, I may reach it :)
<jeromeg> lionel: ok, thank you lionel
<HighNo> mok0: how could I check if my key is in the keyring?
<mok0> HighNo: Looking at the output, it looks like your sig was recognized during the upload
<Fujitsu> mok0: That's dput, not REVU.
<mok0> Fujitsu: Ah, yes of course. It's dput verifying on the user's end
<slytherin> HighNo: you need to join https://launchpad.net/~ubuntu-universe-contributors
<slytherin> HighNo: and your public key needs to be available in launchpad so that it will be synced in the revu keyring
<HighNo> mok0: would it be possible to be signed twice by different keys? I have another key which was created two days ago, not just yesterday - if that was a timing issue... Can I sign the package with another key (another mail address too) without any problem? Both keys are assigned to my launchpad account.
<HighNo> slytherin: been there - done that :-)
<HighNo> slytherin: I joined that group two days ago, added one key two days ago and the other one yesterday
<slytherin> HighNo: the keys ususally are synced every 24 hours IIRC
<mok0> HighNo: You should define your signing key in the env. variable DEBSIGN_KEYID
<mok0> HighNo: Of course you need to sign the package with the same key that is on REVU
<shibata> hi all.
<HighNo> mok0: I know the key has to be there, but as the maintainer I use one mail address (and one key I created just yesterday) and for other stuff I use my company's mail address which I added the day before yesterday. So that key must already be there. The question is - the address for that key is not the same as the one I entered as the maintainer in the packages settings. Does REVU care or would it accept any key that is in the keyring?
<mok0> HighNo: you signed the change file with the key 2298A62D. If that is the key you also sent to REVU, it should be ok. However, the email address that you use in debian/changelog must have a subkey in 2298A62D
<HighNo> mok0: OK, so I would have to change my mailaddress there too to see a difference. I'll try that.
<mok0> HighNo: you can have as many mail addresses (uid's) in your gpg key as you want
<HighNo> mok0: I know now, that was just too late. I have two seperate keys now :-( I'll change my package building setup to try my other address now...
<mok0> HighNo: Make sure you define DEBSIGN_KEYID in .bashrc
<HighNo> mok0: It is now signed with my other key I added the day before yesterday. If that does not work there must be something else broken. Wait a minute...
<HighNo> mok0: OK, the upload with dput worked (as always...) I guess I know have to wait ten minutes and see if it's ok
<mok0> HighNo: ~7 minutes to next refresh :-)
<HighNo> mok0: thx. Anyway do get this correct: the login to the webpage will be created after my first package is accepted for review (does appear in the list). there will be a password mailed to the email address of my key, encrypted with that key?!
<mok0> HighNo: No, when you try to login, and it fails, there will be a butten called "Recover". That will give you access to a file that you need to decrypt with your key to get the password.
<HighNo> mok0: so how is the login created in the first place?
<mok0> HighNo: from your key
<mok0> HighNo: the server can encrypt a message with your public key that only you can decrypt with the private one
<HighNo> mok0: yes, but when is the account created. Automatically when my key is in REVUs keyring?
<mok0> HighNo: The account is based on the key you upload. Your login name can be any of the email addresses that are covered by your key
<HighNo> btw, I have an official problem right now. The package is still not in the list. Even if the keyring is only updated once per day the key I used now must be in there. So my problem seems not to relate to my key.
<HighNo> mok0: Ok, so my first 'correct' upload will be the initial step. (Of course this seems to be my biggest problem atm :-))
<mok0> HighNo: Hmm. You need to get hold of an admin with access to the REVU server. siretart, sispoty or Hobbsee are some of them
<HighNo> Anybody with full access to REVU reading this? I have a problem.
 * Hobbsee looks in
<mok0> HighNo: yes, once your first upload has succeeded everything works
<HighNo> Hobbsee: cool, thx
<Hobbsee> HighNo: which package?
<HighNo> Hobbsee: blueproximity
<vemon> anyone care to review http://revu.tauware.de/details.py?package=lashwrap
<Hobbsee> oh sigh.
<Hobbsee> someone's about to get poked with a very long stick
<mok0> Uh-uh
<vemon> lashwrap should be quite ready for advocation :)
<Hobbsee>  Thomas Dreibholz <dreibh@iem.uni-due.de> here?
<mok0> Phew. Some german guy :-)
<HighNo> Hobbsee: I hope I'm not the one to see the wrong side of the stick...
<HighNo> mok0: I am german :-) but i am not Thomas
<Hobbsee> HighNo: no, you've uploaded a source package, not many binary packages
<ion_> I am not German, but i am not Thomas.
 * Hobbsee wonders why the guy decided to upload it *three* *times* before noticing it was wrong.
<ion_> Well, itâs not as if computers are deterministic.
<ion_> Oh, wait.
<mok0> Just keep doin' it until it works...
<HighNo> Hobbsee: to be honest, this is probably my fourth try to upload my package. (but at least I told you guys in here I was having problems :-)
<HighNo> ion_: "Hello IT - have you tried turning it OFF and ON again..." :-)
<norsetto> howdy all
<mok0> norsetto!
<Hobbsee> HighNo: yeah, you're not in the keyring
<norsetto> mok0!!
<Hobbsee> i don't think it's autoamted, either
 * Hobbsee updates it
<HighNo> Hobbsee: whoohooo
 * Hobbsee should really add that to cron
<ion_> until dput ...; do echo Huh. I bet it works the next time.; done
<mok0> Hobbsee: you mean, REVU does not regularly update the keyring?
 * HighNo would appreciate it
<Hobbsee> then again, the upload never gets reprocessed anyway
<Hobbsee> mok0: don't think so
<HighNo> Hobbsee: so i have to upload it again?
<HighNo> Hobbsee: thank god bits are so cheap these days...
<Hobbsee> HighNo: no, i can let it thru when it's done
<HighNo> Hobbsee: great news
<mok0> HighNo: -> HighYes
<HighNo> :-)
<ion_> HighMu
<mok0> HighNoon
<HighNo> I heard those before :-)
<mok0> HighNo: Sorry, I know it's in bad taste making fun of someone's nick :-)
 * Hobbsee updates revu
<HighNo> mok0: I am >30, I don't mind - in a day I probably can't even remember :-)
<Hobbsee> security patches might be nice....
<mok0> heh
<Hobbsee> (REVU will drop out for a little bit)
<HighNo> ah, real question: if I find any errors or change things to be more ubuntuish, can I update the package by just uploading a changed version (with a greater ubuntu subversion number of course)?
<Hobbsee> HighNo: to revu?
<Hobbsee> HighNo: with revu, you keep teh same version # - it's diffferent to everything else
<Hobbsee> to anywhere else, liek the main ubuntu archive, yes
<Hobbsee> REVU is back.
<HighNo> Hobbsee: OK then. I guess there is a queue REVU is working on and blueproximity is the last in line?
<Hobbsee> HighNo: as in, getting it processed, or getting humans to look at it?
<mok0> Hobbsee: It's not listed on the webpage yet
 * slytherin wonders where geser or persia are :-(
<Hobbsee> mok0: i know.  the keyring sync isn't done
<Hobbsee> i'll tell you when it is
<Hobbsee> slytherin: i ate tehm
<slytherin> Hobbsee: couldn't you wait till one of them sponsored my debdiff?
<Hobbsee> it takes 20+ mins
<Hobbsee> slytherin: nope :P
<Hobbsee> HighNo: Accepting upload blueproximity from Lars Friedrichs (Quattro-Scan GmbH) <l.friedrichs@qs.nitag.de>
<Hobbsee> there you go :)
<HighNo> Hobbsee:  are there so many keys being added every day or does it just take so long to find the newest keys?
<HighNo> Hobbsee: whooohooo
<Hobbsee> HighNo: it has to do a full resync - i'ts not incremental :(
<geser> slytherin: I'm here, I just got 30 min ago out of bed
<Hobbsee> i don't know why
<Hobbsee> there you are.  REVU cleaned out
<HighNo> Hobbsee: (regarding package process) this is just linux - it does take much longer that you expect but you probably learned a whole lot about the system. [which is great for people wanting to learn the system - like me]
<slytherin> geser: Can you tell me your location? I will add location to my clock so I will know when to ping you. :-)
<HighNo> Hobbsee: thanks again. It looks so sweet - lying there innocently on the webpage - until mean reviews will probably tear it to pieces :-) I hope I didn't make to many errors...
<slytherin> HighNo: not 'tear it' but 'hammer and crush' it :-)
<Hobbsee> HighNo: hehe :)
<geser> slytherin: Dortmund, Germany
<slytherin> geser: is it 11:55 am there? And looks like you are having good sunny day. :-)
<ion_> 55? It was :54 when you sent that message. :-)
<HighNo> slytherin: true - we have a wonderful sunny day here in germany. That increases the good-weather-day-counter for this year up to - ehm - one...
<slytherin> So the clock applet works correctly after all
<HighNo> geser: (I am from Diepholz, near Bremen)
<geser> slytherin: lucene2 uploaded
<Hobbsee> hm, a lot of this can probably be archived, too
<slytherin> geser: Thanks. :-D
<man-di> HighNo: hehe, here in Bremen the count is 2 already :-)
<mok0> HighNo: afaics you are not using the proper python install tools
<HighNo> now I can officially ask anyone to review  http://revu.tauware.de/details.py?package=blueproximity
<HighNo> wow, that was fast :-)
<mok0> HighNo: I'm not a motu, but I can give a couple of comments
<HighNo> mok0: I know I don't use the standard way but I could always need halp with that one. A standard is a good thing to keep...
<mok0> imho experience, the easiest is to use python's disttools
<mok0> it works perfectly with cdbs
<mok0> HighNo: https://wiki.ubuntu.com/PackagingGuide/Basic#head-1858e9b3d419609c46d89d3afc2b25b0f8e155a5
<HighNo> btw, does reviewing include testing that the software actually does what the description tries to tell us? because then I should add the "needs bluetooth" to my request for review...
<mok0> HighNo: ubuntu wants to install python programs so they work with several different python versions, the tools take care of that
<HighNo> mok0: thanks, I will have a look at that
<mok0> HighNo: yes, eventually. But let's first get rid of the packaging issues
<HighNo> mok0: ok, but the page you just mentioned refers to python modules. Those are installed at site-packages as I recall. Mine does not install any modules but runs from a single directory. But as you said, we first take a look at the packaging.
<mok0> HighNo: another few point: debian/changelog: collapse both entries to one. And... "Initial release" cannot be true of a version 1.2.2, must be "Initial packaging"
 * slytherin says fixing lucene2 has been quite a learning experience. :-)
<mok0> debian/control: Build-Depends: cdbs is there twice
<mok0> Priority -> optional
<mok0> ubotu, ! maintainer
<ubotu> The "Maintainer" field in a package's information (debian/control) should indicate the Ubuntu team responsible for the Ubuntu specific changes to a package (often the !MOTU for !Universe packages). The original maintainer is preserved in the field "XSBC-Original-Maintainer".
<mok0> HighNo: See maintainer: policy ^
<HighNo> ok, so I have to add myself as I am the upstream author of the package...
<HighNo> I wasn't sure if I had to be in there twice...
<mok0> HighNo: No, the maintainer is the ubuntu-motu mailing list
<HighNo> ahh, ok
<mok0> HighNo: Put yourself as the XSBC-Original-Maintainer
<mok0> HighNo: You have a homepage for blueproximity? Put it in a Homepage: field
<mok0> HighNo: debian/copyright. Looks good, but remove the boilerplate #'s at the end
<Hobbsee> effie_jayx: excellent.  i can request a sync for rbot now
<RAOF> mok0, HighNo: If it's the first time it's been packaged in {Ubuntu, Debian}, it's considered an initial release.
<mok0> HighNo: debian/dirs is *only* for empty directories you want created. Don't use for things that are created by the install
<effie_jayx> Hobbsee, I saw that :D
<mok0> RAOF: Hm, ok
<mok0> HighNo: debian/docs: the README.txt file is not that interesting. Most of it is duplicated in the long description. The contributing author should be acknowledged in copyright
<mok0> HighNo: you have quite a nice HTML manual. That should be included instead. Read about the doc-base system.
<mok0> debian/rules: Cool, you're using CDBS. That should keep you out of trouble with the MOTUs :-)
<HighNo> mok0: hm, some of this stuff I cannot even see because debuild creates those on the fly... I will still try to fix everything.
<HighNo> what would be the exact entry for the maintainer then?
<mok0> HighNo: I'm just browsing the stuff on the REVU page.
<mok0> HighNo: Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<mok0> XSBC-Original-Maintainer:  Lars Friedrichs <LarsFriedrichs@gmx.de>
<HighNo> Hobbsee: If I upload my package again with the same name but a different key (because that's the one I ought to use) and the key is already in the keyring, will this give me a problem?
<mok0> HighNo: I will paste my comments to the revu page for your reference. And for my future MOTU application ;-)
<mok0> HighNo: you keep uploading same version-release
<HighNo> mok0: cool
<HighNo> mok0:  is the README.txt a real problem? Should I delete it then? Should it just refer to the HTML manual?
<mok0> HighNo: Don't delete the file, just don't mention it in docs
<mok0> HighNo: ... but credit the contributors in copyright
<mok0> HighNo: then there's nothing else in readme..txt afaics
<HighNo> I am not sure about the dirs file - since I don't have any 'make install' like installation does it still automatically create the necessary directories?
<Hobbsee> HighNo: is the new key in the keyring?
<Hobbsee> oh right, yes it is.  then it should be fine
<HighNo> Hobbsee: must be, it was added in LP yesterday
<Hobbsee> ah right
<HighNo> mok0: contributors being also translators?
<mok0> HighNo: Whoever you think deserves to be credited. In a sense they all contribute to your application becoming a success
<HighNo> mok0: ok, I now work on the doc-base stuff. I don't know what you meant there. Should I add a special dh_installdocs call to the rules file?
<mok0> HighNo: no, you just add a blueproximity.doc-base file in debian/
<mok0> HighNo: dh_installdocs takes care of the rest, and that is called by CDBS
<mok0> HighNo: btw, use a spell checker on all the english texts in your package. I didn't see any spelling mistakes, but you never know. The MOTUs are evil, they will get you for anything :-)
 * Hobbsee laughs evilly
<Hobbsee> HighNo: Homepage:  <blah> at the bottom of the long description in debian/control would be nice too
<Hobbsee> :)
<smarter> hi
<HighNo> Hobbsee: ok
<smarter> what's the standard way to indicate that the .orig.tar.gz has been repacked?
<smarter> <version>+repack-<revision> ?
<Hobbsee> smarter: repackaged, as in, files taken out?
<Hobbsee> or repacked, from tar.bz2 to .tar.gz?
<smarter> Hobbsee: file(actually COPYRIGHT) taken in and tar.bz2 to tar.gz
<Hobbsee> smarter: usually <version>-repack-0ubuntu1
<mok0> Gotta run guys, see you later!
<HighNo> mok0: I have problems understanding the doc-base system. Although somewhat explained here: http://fts.ifac.cnr.it/cgi-bin/dwww?type=file&location=/usr/share/doc/doc-base/doc-base.txt.gz I don't understand how my .doc-base file should look like exactly
<smarter> Hobbsee: thanks
<Hobbsee> smarter: or something like that
<smarter> I've seen "+repack" and "-repack1", I think the first solution is more elegant
<HighNo> mok0: thanks so far!
<mok0> HighNo: ok, good luck!
<smarter> Hobbsee: this is for the tar.bz2 to tar.gz or for the files added/deleted ?
<Hobbsee> smarter: i don't think there's a policy on it, so you can pretty much pick
<smarter> ok
<Hobbsee> smarter: files added/deleted
<smarter> roger
<Hobbsee> smarter: sometimes it's mentioned in the changelog if you've converted it to .tar.gz, but that's rare
<Hobbsee> iirc
<HighNo> Hobbsee: maybe you can give me a little guide here: the .doc-base file should include (my ideas about nice values attached) Document: blueproximity Title: BlueProximity Manual , Author and Abstract I can do by myself but what to put in Section: part?
<Hobbsee> HighNo: no idea, i don't play much with docs, sorry
<sistpoty|work> hi folks
<smarter> It's me, or does uscan --force-download doesn't force download anymore with hardy?
<norsetto> hodwy sistpoty|work
<sistpoty|work> hi norsetto
<HighNo> hm
<HighNo> Hobbsee: too bad :-/ I will upload a new version anyway. Should I comment on the changes?
<Hobbsee> HighNo: if you like, but stick all of the changes in one changelog entry
<smarter> TheMuso: ping
<smarter> TheMuso: you reviewed my package(http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin) and said that most of the files are under GPL and not LGPL, they all contains "GNU Library General Public" in the header which is the other name of the LGPL
<smarter> and the COPYING.LIB file explicitely state "NOTE! The LGPL below is copyrighted by the Free Software Foundation [...]"
<sladen> smarter: is there a COPYING file in there somewhere/documentation that states otherwise?
<smarter> sladen: there's a COPYING with the GPL(two files are GPL) and a COPYING.LIB with the LGPL
<HighNo> Hobbsee: The changes I made are all in the debian dir, so I don't think they should be mentioned in the package itself. But I meant commenting on REVU's page
<smarter> I even used licensecheck -r . to make sure
<sladen> smarter: that could been the confusing---checking for a COPYING might have been what TheMuso did
<TheMuso> No, I saw a difference between what was stated in debian/copyright, and the COPYING files.
<TheMuso> debian/copyright said lesser, the COPYING files said library.
<webwolf_27> saivann, I sent you an email regarding the packaging of the Brother Drivers for Multiverse, Have you had a chance to check it?
<sistpoty|work> smarter: is there a copying file in the orig-tarball, that contains the LGPL?
<HighNo> Hobbsee: hmm "dpkg-source: warning: unknown information field 'Homepage' in input data in package's section of control info file" - did I misunderstand you telling me to add that "Homepage: http..." to the control file?
<Hobbsee> HighNo: hm, i thikn you ahve to put a space in front if it first
<Hobbsee> so it doesn't think it's a field
<HighNo> Hobbsee: ahh, that makes sense
<Hobbsee> (and we may have an X-homepage: field now, or something, come to think of it)
<sistpoty|work> smarter: if not, and there files inside the orig-tarball, that are licensed under the LGPL, you'll need to repack the tarball and a a copy of the LGPL
<sistpoty|work> add a copye
<sistpoty|work> -e
<sladen> ^^ smarter stated that there was both a COPYING.LIB and a COPYING  (LGPL and GPL)
<sladen> but the conflict here is presumebly between that and  debian/copyright
<sistpoty|work> heh, didn't read irc thourough enough *g*... was confused by "(two files are GPL)"
<HighNo> Hobbsee: too funky, if I leave out the directories where stuff is supposed to get in the debuild for the binary package fails due to a call "install: cannot create regular file `/home/python/blueproximity-1.2.2/debian/blueproximity/usr/bin/blueproximity': No such file or directory" which is because the directory is not there. What shall I do here?
<smarter> TheMuso: Library GPL == Lesser GPL == LGPL
<TheMuso> smarter: Are you sure that they are the same beyond the title?
<smarter> TheMuso: http://en.wikipedia.org/wiki/Library_General_Public_License
<TheMuso> smarter: And, why was the package originally rejected?
<smarter> redirect to LGPL
<smarter> TheMuso: I said that most of the files were GPL and some LGPL
<smarter> TheMuso: you can check with licensecheck -r .
<smarter> in devtools
<TheMuso> smarter: The package was initially uploaded, but must haveen rejected. Why?
<smarter> "[13:04] <smarter> TheMuso: I said that most of the files were GPL and some LGPL"
<smarter> s/I/debian/copyright if you prefer
<TheMuso> smarter: Well I'm about to go to bed, so if someone else gives the ok, I will when I come online commorrow.
<smarter> TheMuso: ok, thanks
<smarter> actually, jpatrick acked it
<shibata> My native language isn't English. And I would like to improve my package description. Can anyone check it for me?
<slytherin> geser: lucene2 built successfully. :-D
<Nightrose> shibata: would help if you say which package and where to find it :)
<shibata> Nightrose: thx. My package is http://revu.tauware.de/details.py?package=kita2
<luisbg_> what's the best way to handle the placing of the app's .desktop file in the system for the menu to use?
<ion_> dh_desktop(1) probably
<ion_> Ah, it only seems to be required for .desktop files with MIME types.
<luisbg_> ion_, ok, thanks let me check that
<luisbg_> well.. if it's the best way in general
<Nightrose> shibata: I would remove the !And" at the beginning of the second sentence - but I am not a native speaker either
<luisbg_> I don't need the MIME types, but no worries
<shibata> Nightrose: Thank you very much. I will remove it.
<minghua> Putting the .desktop file in /usr/share/applications and use dh_dekstop, I believe.
<slytherin> luisbg_: you have to install them in /usr/share/applications, you can do it in install file.
<minghua> You don't need dh_desktop for now if you don't have MIME types, but it may be useful in the future.
<luisbg_> slytherin, directly in the app.install file? I thought of that but it seams hacky
<luisbg_> or .postint
<luisbg_> now wait...
<luisbg_>  .install sorry LOL
<slytherin> luisbg_ where does the Makefile in the application install the .desktop file?
<luisbg_> slytherin, the application has no .desktop file
<luisbg_> I'm going to create one for it
<luisbg_> and upload as a patch to the ubuntu package
<luisbg_> so the makefile doesn't know about this file
<slytherin> luisbg_: Oh. You will have to do some trial and error then. I don't know exact solution for this.
<luisbg_> slytherin, I have done the .install method for some software I've developed
<luisbg_> and clients wanted a deb package, just in a hacky way that didn't had to follow the debian/ubuntu rules
<luisbg_> I'll try this approach and maybe in REVU I will be asked to change it to a better way
<luisbg_> :)
<slytherin> luisbg_ .install method will work. I am not sure if dh_desktop will work if the file is not provided by upstream source
<luisbg_> slytherin, ok
<minghua> slytherin: It will.
 * norsetto -> lunch
<slytherin> Can some one look into the 'New' queue and take some action on cglib2.1? It will hopefully clear 1-2 more depwait
 * norsetto <- lunch
<mruiz> hi all
<coolbhavi>  Can we upload new packages of new software in ubuntu and new packages which arent there in ubuntu?
 * coolbhavi thinks of working towards becoming a MOTU
<coolbhavi> any Info?
<slytherin> coolbhavi: Can you please rephrase the question?
<Hobbsee> coolbhavi: yes, until feature freeze (the 14th)
<RainCT> Hey
<Iulian> coolbhavi: Well, start packaging and upload to REVU, and like Hobbsee said until FF.
<Iulian> Hi RainCT
<coolbhavi> Ok.. Will uploading packages help me towards becoming a motu?
<Hobbsee> coolbhavi: yes
<ScottK> coolbhavi: It will help, but it's not required.  Showing a broad range of skills which you get through fixing packaging problems, helping with merges, and other more general tasks can be sufficient.
<coolbhavi> OK will start active packaging from Hardy+1.. Thanks for the info
<slytherin> coolbhavi: It is just a start. You need to do lot of practice, need to be consistent in following processes and improve over the time.
<coolbhavi> OK.. :)
 * coolbhavi committed and fallen in Love with ubuntu
<slytherin> coolbhavi: why hardy+1? You can still help with minor tasks like debdiffs, sync request etc.
<jdong> coolbhavi: no need to wait till hardy+1, there's plenty still to be done for Hardy :)
<coolbhavi> Ok... :)
<jdong> coolbhavi: packaging new software is only a small part of being MOTU -- for example, when my MOTU application was approved I had actually never personally packaged a new program from start to finish :)
<coolbhavi> Ok.. :)
<jdong> coolbhavi: though, as practice, packaging  some program you like will give you good introductory insight into what a basic deb source package consists of
 * slytherin wonders how jdong landed in backports team. :-P
<jdong> slytherin: backports team doesn't generate new code / packages :)
<jdong> slytherin: in fact, there's severe limitations to how much we can actually do that ;-)
<ScottK> slytherin: He did it the hard way.  He invented it.
<jdong> what ScottK said
<jdong> backports used to be a Sourceforge project
<jdong> that checked in an apt repo into Subversion :)
<coolbhavi> Will start working towards it... Any Info on Howto on sync,merges and so on?
<jdong> packages were built for Warty using debuild -B and whatever environment I was running at the time :D
<slytherin> :-)
<jdong> I'm sure I used to be the most hated person around here :D
<Hobbsee> !jdong | jdong
<ubotu> jdong: <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<jdong> coolbhavi: almost all MOTU related work and processes is documented at https://wiki.ubuntu.com/MOTU
<Hobbsee> slytherin: backports == crack, so jdong was suited to it.
<tuxmaniac> Hobbsee, so what is suited for you?
<slytherin> Hobbsee: have you been feeding this nonsense to ubotu? :-D
<Hobbsee> slytherin: erm.  maybe.  but it's not nonsense!
<coolbhavi> Ok jdong thanks for the info mate
<Hobbsee> tuxmaniac: good question.  ask soren or dholbach, who are certain to say that i just stick around to whinge.
<soren> eh?
<jdong> slytherin: and she doesn't accept my !jfuv factoid :D
<coolbhavi> It was great talking to you jdong
<sistpoty|work> Hobbsee: just saw your mail on the motu ml regarding revu probs: btw, a quick check, if s.o. is in the keyring is sudo -u revu1 (pathto)revu-key list <keyid>
<jdong> coolbhavi: you too. Look forward to seeing you around here more often :)
<coolbhavi> yup
<Hobbsee> sistpoty|work: this is true, but if the guy's managed to upload 3 versions of binaries, and a source too....
 * jdong sees he doesn't have posting permission to #ubuntu-devel....
<sistpoty|work> Hobbsee: there was/is a source upload? still in the queue, or did it show up on revu yet?
<Hobbsee> sistpoty|work: i suspect i rm'd the lot, as i only read the email later
<Hobbsee> oh, tha'ts right
<Hobbsee> it was an older source
<Hobbsee> iirc
<mruiz> hi all. For python packaging, which shebang should be used: #!/usr/bin/env python or #!/usr/bin/python2.4 ?
<sistpoty|work> Hobbsee: heh, than I hope that things will return to normal, once he uploads the next source (i.e. account created etc.)
<slytherin> Has anyone looked at jboss related packages? Looks like there is some circular dependency.
<Hobbsee> yeah
<jdong> mruiz: what version of python are you looking for?
<sistpoty|work> if not, I'll hide *g*
<Hobbsee> sistpoty|work: hehe
<coolbhavi> Will the hardy changes list keep track of syncs?
<mruiz> jdong, python 2.4
<slytherin> coolbhavi: of course it keeps track of any changes that occur in repos
<jdong> coolbhavi: yes. A sync is considered an upload and hardy-changes tracks all uploads
<ScottK> mruiz: It should be /usr/bin/python
<coolbhavi> OK
<jdong> ScottK: for python 2.4?
<slytherin> coolbhavi: make sure that the package builts in Ubuntu before request a sync
<ScottK> mruiz: Why do you need 2.4?
<jdong> coolbhavi: have you set up a pbuilder environment locally yet? That's a very useful development tool needed to do just about everything
<geser> slytherin: re jbossas4: see bug #184557
<ubotu> Launchpad bug 184557 in jbossas4 "Circular build-depends, needs initial bootstrapping on the buildds" [Medium,Confirmed] https://launchpad.net/bugs/184557
<coolbhavi> OK.. mean there should be no build failure for the package.. :) thanks
<ScottK> jdong: /usr/bin/env python would point to 2.5 in an Ubuntu system anyway.
<jdong> ScottK: right, that's definitely wrong (tm) anyway
<ScottK> jdong: Did you see there's a new ktorrent in Debian?  Didn't check to see if we have it already.
<mruiz> ScottK, mnemosyne-1.0 needs it
<slytherin> geser: I sometime wonder when will debian guys start using buildd for arch:all packages. It will prevent such type of headaches.
<jdong> ScottK: what version do they have?
<ScottK> mruiz: Please teach mnemosyne to play nice with Python 2.5 if you can.  That's a better solution for the long term.
<jdong> [2008-02-07] Accepted 2.2.5.dfsg.1-1 in unstable (low) (Debian KDE Extras Team)
<jdong> ah I see
<jdong> ScottK: I put that in Hardy on the 27th Jan ;-)
<mruiz> ScottK, I'll try with python2.5 :-)
<jdong> mruiz: unless there's a really good reason to lock into one version, accepting the system default /usr/bin/python should be standard practice
<ScottK> jdong: Yes.  It'd be good to re-sync with them probably.
<jdong> ScottK: right. I'll put looking at that diff on my todo list and see if there's anything that needs to be done
<ScottK> Depends on zope is the only good reason I'm aware of right now.
<geser> slytherin: there were some discussions about it already on the debian-devel-ML but with no success
 * jdong curses DSFG repacks...
<ScottK> jdong: Curse the upstream.
<jdong> ScottK: yeah I'll need to yell at them again for putting that non-free GeoIP data in there
<jdong> ScottK: but other than that, I think personally the other DFSG repack changes are nonsensical
<slytherin> geser: By the way, I just took a look at lucene2 2.3.x changes. I think we should better be ready to get the package in Ubuntu. I guess I will try making a packaging in my PPA so we can have some testing.
<ScottK> IMO DFSG is a compromise and a reasonable one.  As with all compromises, it sometimes produces odd results.
<geser> slytherin: are that big changes in lucene2 2.3?
<jdong> ScottK: overall I've found DFSG repacks to be quite reasonable in nature, but ktorrent's particular repack sometimes drives me nuts
<HighNo> ok, I managed to fix all previous problems, would somebody like to review http://revu.tauware.de/details.py?package=blueproximity - thanks
<jdong> ScottK: they stripped out the flag icons because the terms say "You are free to use these in whatever way you want on your website" and ktorrent != website... despite Azureus and a few other P2P apps in Debian use the same flagset
<slytherin> geser: big and supposedly good.
<ScottK> jdong: They are right to do so.  Use restrictions are explicitly not allowed.  The other packages are wrong to leave them.
<geser> slytherin: perhaps it would be good to get a FF exception even if the packages are ready before FF (which is next week)
<jdong> ScottK: *shrug* in that sense then I should bug upstream to switch to a new flag set too
<jdong> and it'd be nice to have debian/rules get-orig-source in the package too. I'll put that on my TODO list
<slytherin> geser: that is what I was going to suggest. For now let the official package be at 2.2.x so that netbeans guys do some proper testing. After that I can add package to my PPA and make a call for testing.
<ScottK> Yes.  That'd be nice or get the existing one relicensed.
<emgent> heya
<slytherin> geser: do you have rights to accept a package in 'New' queue?
<ScottK> slytherin: It takes an archive admin to do that.
<slytherin> ScottK: And can i request for package to be processed fast?
<ScottK> slytherin: And that will get it done faster or slower depending on if the archive admin gets grumpy about you pestering them.  What's the rush?
<slytherin> ScottK: there is one package which may clear the depwait status of at least one more package
<ScottK> slytherin: I'd just wait then.  We're early enough in the process that I think you should let them prioritize their work.
<slytherin> ScottK: Ok. I will wait
<geser> slytherin: no, only archive admins have that right
<slytherin> geser: do you think I should point to the w3c-dtd-xhtml package in Ubuntu on the debian bug?
<hexmode>  Hi all... Just joined the ubuntu-universe-contributors.  I have a couple of packages for revu when the keyring syncs. https://bugs.launchpad.net/ubuntu/+bug/189928 https://bugs.launchpad.net/ubuntu/+bug/189926
<ubotu> Launchpad bug 189926 in ubuntu "include libapache-test-perl" [Undecided,New]
<hexmode> I just wait for them to sync from here, right?
<geser> slytherin: I doubt that that it will convince the maintainer to accept this change
<slytherin> geser: leave it then.
<RainCT> http://paste.ubuntu.com/4291/plain/   any idea why this is FTBFSing?
<LucidFox> hexmode> I assume so
<LucidFox> RainCT> try building the .dsc
<LucidFox> instead of .changes
 * LucidFox never used pbuilder on .changes
<RainCT> LucidFox: argh, right -.-
<hexmode> LucidFox: tyvm
<RainCT> LucidFox: thanks
<jcfp> MOTUs, please take a look at http://revu.tauware.de/details.py?package=sabnzbdplus
<jcfp> ScottK RainCT ^^^ :)
<ScottK> jcfp: I'm busy with $WORK currently.  I'll see if I can get to it later.
<ScottK> jcfp: In general it's not needed to ping me.  I look at REVU as I have time.
<RainCT> jcfp: reviewing :)
<\sh> yeah $work is holding me up, too ;)
<jcfp> duly noted, all of the above
<\sh> and now I know that I have to introduce ubuntu here, and push debian out of the dc
<linux__alien> Hey LucidFox
<LucidFox> linux__alien> yes?
<linux__alien> Just wanted to say a big hi to you :)
<linux__alien> am reading through the packaging guidelines
<linux__alien> and will try a few examples and start contributing as early as possible :)
<LucidFox> Awesome.
<ScottK> linux__alien: We are very near the freeze for new packages for Hardy, so I'd suggest you focus your initial contributions on trying to fix what we've already got.  Look for bugs tagged packaging and bit-size.
<linux__alien> ScottK, Sure will do that i am new to packaging so ve already started going through it and i could also fix bugs in some packages hopefully
<ScottK> Perfect.  That's what we need is more fixing.
<LucidFox> What's the difference between the "Uploaded packages" and "Maintained packages" sections? Maintained are those where I'm listed in the maintainer field?
<linux__alien> but basically i need your help and support for first few days :)
<ScottK> LucidFox: Yes.  Unless you've got packages in Debian that will almost always be empty these days.
<ScottK> linux__alien: There are lots of people here to help.
<linux__alien> yes :) thats what i want :)
<RainCT> linux__alien: (*bit-size -> bitesize)
<linux__alien> that means ?
<LucidFox> ScottK> Yes, my package from Debian got synced and that section appeared, hence me asking :)
<ScottK> That's exactly what it is then.
<RainCT> linux__alien: ScottK said "Look for bugs tagged packaging and bit-size." before, but this tag he mans is "bitesize" and not "bit-size"
<ScottK> What RainCT said ...
<ScottK> Thanks.
<RainCT> ember: please forward the watch file that you created for nautilus-python to Debian if you haven't already done so (although it isn't really needed as there is a get-orig-source rule already)
<LucidFox> Can new packages be backported from Hardy to Gutsy?
<ScottK> LucidFox: Yes
<LucidFox> Excellent.
<ScottK> They have to go through New again so it may take a while.
<RainCT> btw, how can I unextract .diff.gz files using the terminal?  tar -xzf doesn't work
<ScottK> Backports New is low on the archive's priority.
<LucidFox> RainCT> gunzip
<LucidFox> or zcat to output the contents to the terminal
<ScottK> RainCT: I usually just rm -rf the dir and unpack a clean source again.
<RainCT> LucidFox: ah, thanks :)
<LucidFox> to auto-apply the diff, you can use: zcat filename.diff.gz | patch -p0
<pochu> RainCT: zcat *.diff.gz | patch -p1
<LucidFox> -p1 if you're inside the source directory
<pochu> Right, it will create a ./debian/ dir
<LucidFox> Hmm, apparently multiverse packages are lower in the buildd priority than universe packages.
<ScottK> Makes sense.
<pochu> TheMuso: I guess your +1 in http://revu.ubuntuwire.com/details.py?package=deskscribe still applies, right?
<mneptok> who wants to take responsibility for the flashplugin-nonfree update that just got pushed?
<jpatrick> mneptok: best check who did it on LP
<HighNo> poor guy :-)
<DaveMorris> in the hardy build queue, gmyth is in there twice and 2 slightly different svn numbers, should 1 of them be removed, or will they do that before it's built?
<RainCT> is there any package in the repos to "freeze" a user (so that any change that is made gets reverted on reboot)?
<ScottK> DaveMorris: It'll sort itself out.  I wouldn't worry about it.
<DaveMorris> not worried, just noticed
<ScottK> mneptok: There's also who-uploaded (I think it's called) in devscripts.
<soren> mneptok: It's got Riddell's name written all over it.
<linux__alien> I ve a very basic doubt in packaging should i manually create the changelog file and type the contents manually in it ?
<hexmode> linux__alien: use dch
<hexmode> linux__alien: emacs has a debian-changelog-mode, and something similar exists for vim, I think.
<mruiz> I'm working on a package using python 2.4 only... how should I define this situation: python (=2.4) on Build Depends?
<vemon> anyone seen persia?
<linux__alien> hexmode, i could also type it manually right?
<linux__alien> is there any problem in that coz i am very new to packaging so till i get a hold of it or rather find it i could type it also right?
<hexmode> linux__alien: you could, but that is more painful
<hexmode> you should just use dch
<linux__alien> dch ?
<linux__alien> ok let me
<linux__alien> try
<hexmode> man dch
<linux__alien> hexmode, The Packaging Guide does not explain how to create these files however i ve managed to create the changelog using dch
<linux__alien> is there any document which explains that ?
<hexmode> there is, I don't recall atm. 1s
<hexmode> linux__alien: is dch installed on your machine?
<linux__alien> yes
<geser> mruiz: which package is it? doesn't it work with python 2.5?
<hexmode> linux__alien: https://wiki.ubuntu.com/MOTU/Contributing has a bit on dch there
<sistpoty|work> hi bddebian
<geser> hi bddebian
<mruiz> geser, mnemosyne. The new version (1.0) uses python 2.4. With python 2.5 it has problems.
<hexmode> linux__alien: From http://www.linuxjournal.com/article/4610: "changelog - The changelog lists changes to the Debian package, not necessarily to the original program. You can create it best with dh_make and add new entries with dch -i."
<hexmode>  
<bddebian> Heya gang
<linux__alien> i did dch --create
<bddebian> Hi sistpoty|work, geser
<hexmode> linux__alien: that works too ;)
<linux__alien> how about for the control file?
<geser> mruiz: build-depend on the specific python version (python2.4 or python2.4-dev if you also need the headers) and make sure that scripts use /usr/bin/python2.4
<mruiz> thanks geser ... I patched the script to use /usr/bin/python2.4 ;-)
<linux__alien> can someone here tell me how to create a control file?
<linux__alien> for packaging
<linux__alien> i read through the packaging guide but am not able to find the way  of creating these files using dch
<bddebian> dh_make
<linux__alien> bddebian, i just went through dh_make options but not able to find the way to create control file. i gave dh_make --createorig but it didnt get created
<linux__alien> it said a directory by name debian already exists so it will not overwrite anything
<linux__alien> and i also gave --addmissing
<linux__alien> but does not seem to produce the control file
<linux__alien> ok got it
<linux__alien> but am not sure whether what ive done is right
<linux__alien> i ve got the control file
<linux__alien> i gave dh_make --addmissing and then when it showed whether single binary and other options i gave cdbs and then it has created many files in the debian dir
<linux__alien> ok got it i guess its generated the file
<mok0> ScottK: You had me worried for a while... I am inundated in goofs I've done at the moment :-/
<ScottK> Sorry about that.
<ScottK> It was late and I was tired.
<mok0> ScottK: NP. Did you get the package to build?
<mruiz> geser, should I remove python instead of python2.4 on Build Depends ?
<ScottK> mok0: I'm up to my eyeballs in $WORK today and so I've not looked again.  It'll probably be tomorrow before I get to it.
<mok0> ScottK: Tell me about it ;-)
<geser> mruiz: yes, as python will pull in python2.5 which doesn't help you much
<linux__alien> Ok thanks for all your help got to go now cya tomorrow with some more updates :)
<linux__alien> this is getting very interesting
<linux__alien> :)
<linux__alien> have a nice day
<RainCT> cya linux__alien
<linux__alien> cya RainCT :)
<HighNo> mok0: could you have a look at my package again? http://revu.tauware.de/details.py?package=blueproximity
<mok0> HighNo: Sure
<mok0> HighNo: spellchecker: I use aspell, it's simple but ok
<HighNo> I sacrificed my hole day where I should have done paid work or studying for my exams. I would be so depressed if it wouldn't go into hardy :-)
<HighNo> mok0: thanks, I'll apt-get it right away
<HighNo> mok0: funny - it was already installed... I'll have a look on howto use it then...
<mok0> HighNo: You must be patient. It normally takes a long time and several reviews before a package gets advocated. But think about it this way: it's good to know that all the other packages have gone through the same careful scrutiny
<mok0> HighNo: It's what makes Debian/Ubuntu such high quality distros
<mok0> HighNo: in debian/control, move Homepage: line to the "source package" section, for example after "Maintainer:"
<mok0> (but that does not matter)
<HighNo> mok0: just used aspell to check my CHANGELOG.txt. works great.
<mok0> HighNo: :-)
<mok0> HighNo: it's fast to scan the words it doesn't like
<HighNo> mok0: I tried to put Homepage as a new tag below Maintainer: but dh_make doesn't like that tag. even now i get warnings about using a url in the control file. But using it as a tag by its own does lead to even more warnings though no errors...
<mok0> HighNo: Consider using compat version 6. I believe the construction you use in rules actually does not work in gutsy (there variables need to be after the "include")
<mok0> HighNo: yeah, you get some warnings from some of the tools, but it's ok
<HighNo> my wife and kids want to see me for dinner. I'll read your posts in a few minutes. being afk for 20 mins...
<mok0> HighNo: bon appetit!
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<joejaxx> Hello All :D
<sistpoty|work> hi joejaxx
<LaserJock> hi all
<sistpoty|work> hi LaserJock
<bddebian> Heya LaserJock
<Aloha> laserjock laserjock does what ever a laser can
<LaserJock> how are things in MOTU land?
<LaserJock> I'm at a laser conference at the moment
<sistpoty|work> heh
<Aloha> i use lasers at work to setup chairs in a straight line
<LaserJock> I use one at home to make sure picture are hung straight
<LaserJock> wow, flashplugin-nonfree had a lot of activity
<ion_> I use one at home to blind airplane pilots flying above.
<LaserJock> ion_, tsk tsk
<joejaxx> ion_: lol
<ion_> I collect crashed airplanes.
<joejaxx> lol
<mruiz> geser, I tried to build the package and I got:  pbuilder-satisfydepends-dummy: Depends: python (= 2.4) but 2.5.1-1ubuntu2 is installed.
<jpatrick> mruiz: python (>= 2.4)
<geser> mruiz: how does your Build-Depends line look like?
<mruiz> geser, jpatrick : My Build--Depends: debhelper (>= 5), python (>= 2.4), python (<< 2.5), python-support
<geser> mruiz: python is the meta-package which points to the default python version
<geser> if you want python2.4 then replace "python (>= 2.4), python (<< 2.5)" with "python2.4"
<jpatrick> mruiz: depend on python2.4?
<mruiz> jpatrick, yes
<jpatrick> mruiz: http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
<mruiz> jpatrick, XB-Python-Version field is supported under Ubuntu ?
<jpatrick> mruiz: I suggest reading Debian Devel docs - they're very good :)
<jpatrick> mruiz: I think so
<jpatrick> taking out something like that to a core thing would be just wrong
<geser> mruiz: yes, XB-Python-Version is supported in Ubuntu, but XB-P-V is only used with python-central
<geser> mruiz: python-support uses now debian/pyversion
<ion_> Which one was first, and why was the second one made, btw?
<mruiz> geser, then should I include it (python-support) as Depends ?
<geser> mruiz: ${python:Depends} should fill in the correct depends on python and python-support
<mruiz> geser, ok... I'll drop it :-)
<mruiz> uppps, Lintian error : E: mnemosyne source: missing-build-dependency python | python-dev | python-all | python-all-dev
<mruiz> again: E: mnemosyne source: missing-build-dependency python-support
<HighNo> mok0: re
 * sistpoty|work heads home
<sistpoty|work> cya
<ScottK> mruiz: {python:Depends} does binary depends, not build-depends
<mruiz> ScottK, I added python-support to build-depends... but now: E: mnemosyne source: missing-build-dependency python | python-dev | python-all | python-all-dev
<mruiz> and I'm using python2.4 as build-depends...
<ScottK> mruiz: Did you tell us why you can't use python2.5?
<mruiz> ScottK, I did it before... The application doesn't work very well with python2.5
<ScottK> mruiz: In what way?  Does it crash?
<rzr> hi any hardy users around w/ radeon video hardware ?
<ScottK> rzr: Try #ubuntu+1
<webwolf_27> whats the proper way to submit a package available binaray-only
<rzr> ScottK: thx
<pochu> Ng: hey, will you release a new terminator before feature freeze? So you don't have to ask for a freeze exception ;)
<TuxCrafter> hi guys i got a basic question: how do i list all the installed files from a packages from the commandline?
<Ng> pochu: I'm really hoping so, I have one bug I absolutely have to fix, which I think might have been yours (a crasher)
<webwolf_27> TuxCrafter, dpkg -c <packagename>
<TuxCrafter> webwolf_27: thanks
<webwolf_27> TuxCrafter, np
<pochu> Ng: oh yeah. NB: terminator didn't closed
<pochu> Ng: were you able to reproduce it?
<Ng> pochu: not in an en locale, which is quite annoying because if local specific stuff is going to affect the hotkeys, we're going to need lots more code for them ;)
<TuxCrafter> webwolf_27: ehm I is not working here dpkg -c maxima-doc
<pochu> Ng: my locale is LANG=en_US.UTF-8
<webwolf_27> I'm currently working on this bug https://bugs.launchpad.net/bugs/25966 but the cups-wrapper rely on the lpr-drivers and they are binary only. As I understand it I can only upload source packages
<ubotu> Launchpad bug 25966 in ubuntu "Printer drivers for Brother needed" [Wishlist,Confirmed]
<Ng> pochu: oh, that's weird
<webwolf_27> TuxCrafter, that works on the deb
<Ng> pochu: and pressing ctrl-} makes it go mad?
<TuxCrafter> webwolf_27: is there a way to doe the same with apt?
<ScottK> webwolf_27: If there's no source, but it's legally distributable, it can go in multiverse.
<webwolf_27> ScottK, thats where it's planned for
<webwolf_27> TuxCrafter, checking
<pochu> Ng: no, only the properties + one of []{} (at least)
<ScottK> webwolf_27: OK.  I'm not sure how to do it as I've never had to.
<Ng> pochu: ah yes (sorry, not read the bug to remind myself exactly what it was). what's properties?
<ScottK> You might look for another binary only package in multiverse and see how it was done.
<pochu> Ng: the properties key is the one between the right control and the right left. I don't know how it's said in English.
<pochu> Ng: err the right control and the right alt ;)
<webwolf_27> ScottK, I can make a tarball of the bin's before packaging
<mruiz> ScottK, I've read comments about problems with 2.5 ... I send an email to upstream to clarify the situation
<ScottK> mruiz: OK.  At this point Python 2.5 has been default for a year here.  Personally, I'd be very reluctant to add python2.4 only software to our repository now.
<webwolf_27> TuxCrafter, not that I can find
<mruiz> ScottK, indeed
<ScottK> And a good point to encourage upstream if they care.
<Ng> pochu: like a windows menu key?
<TuxCrafter> webwolf_27: ok than i will stick with the first command
<pochu> Ng: likely, but that acts as if you pressed mouse2 to open a properties dialog.
<pochu> Ng: this is an Spanish keyboard, btw.
<Ng> ok
<pochu> Ng: I could attach a photo to the bug report if that's useful
<Ng> pochu: I'll try and make the code fail sanely and ask you to test it, if thats ok?
<AnAnt> Hello, what's meant by native package ?
<rzr> no need to repackage it (cleanup etc)
<pochu> Ng: sure
<Ng> pochu: excellent, thanks
<AnAnt> does it mean that 1) it doesn't have separate .orig tarball & .diff.gz file. or 2) that package version doesn't end with -0ubuntuX ?
<pochu> AnAnt: 1)
<AnAnt> pochu: ok, thanks
<pochu> AnAnt: 2) is that it doesn't have ubuntu changes.
<ScottK> AnAnt: #1 and this is only for packages only useful in a Debian/Ubuntu context.
<AnAnt> ScottK: ok, thanks
<TuxCrafter> webwolf_27: thanks for the info
<webwolf_27> so time for me to go put the kids to bed. Night folks
<webwolf_27> quit "Zzzzzzzzzzzz"
<mruiz> hi DktrKranz ... I have sent an email to upstream to clarify the python version issue (2.4 vs 2.5) related to Mnemosyne
<DktrKranz> mruiz, GREAT! thanks :)
<mruiz> DktrKranz, thank you ... also I didn't change the shebang (it was upstream) ;-)
<DktrKranz> mruiz, if python2.5 is supported, there is no need to change it IMHO
<mruiz> DktrKranz, I agree ... but #!/usr/bin/env python is the same as #!/usr/bin/python ?
<jpatrick> mruiz: no, you can't pass python args to env
<mruiz> DktrKranz, then I have to patch the shebang ;-)
<mgunes> if a debdiff closes multiple bugs, should I attach the same debdiff to each one and subscribe u-u-s separately?
<DktrKranz> mruiz, let's wait for upstream, then. When you have a reply, ping me :)
<mruiz> DktrKranz, sure ... :D
<geser> mgunes: pick one bug and attach the debdiff there
<mgunes> geser, and add separate (LP: #xxxxxx) entries for each in the changelog, and they'll be closed, am I right?
<geser> correct
<mgunes> thanks
<mruiz> is Homepage field supported ?
<ScottK> In Hardy, yes
<squentin> To upgrade a package to a new upstream version, the wiki says I should attach an interdiff file, but I think this has been changed right ?
<squentin> nevermind, I found the note on the interdiff page
<gilir> hi
<leonel> ScottK:   11 dapper's clamav bugs  and  counting ...  hold on  but not  hold your breath  :-P
<ScottK> leonel: Excellent.
<ScottK> leonel: The more the better as it solidifies the case.
<TheMuso> pochu: If there has been another upload, I don't think so. I think 2 acks are still needed.
<leonel> ScottK: I've reached  cves for  0.90 0.91  that may not apply  to 88.2 for the new code  ..
<ScottK> leonel: That should be suffiicient then.  Would you please email me the list.
<leonel> ScottK: let me check the  remaining 7 cves  ..
<ScottK> OK.  Thanks
<DaveMorris> evening
<DaveMorris> how can I get uscan to only match on a number rather than a word
<bddebian> \d
<ScottK> DaveMorris: google regular expressions
<ScottK> I'd give a more detailed response, but I'm low on time.
<DaveMorris> thanks
<hendrixski> I made a libMyfirstLib.deb and a libMyfirstLib-dbgsym.ddeb, ran "apt-ftparchive packages"  because I want to add it to my /etc/apt/sources.list   but the result doesn't have the libMyfirstLib-dbgsym.ddeb   ... is there some separate thing I should be running to get the debug-symbol ddeb's listed for download?
<hendrixski> err, listed in the repository I mean.  ?
<mruiz> is linda up to date? I got a warning "3.7.3 is a newer Standards-Version." and I defined it before.
<ScottK> mruiz: No.  It's not.
<wallyweek> good evening all!
<hendrixski> I know that regular repositories are made using apt-ftparchive... is there another tool for creating debug symbol repositories?
<wallyweek> A small question: a build failure for unofficial archs (powerpc, sparc, hppa...) will prevent a package from entering multiverse?
<ScottK> wallyweek: You should fix it, but probably not.
<wallyweek> ScottK: thanks, I'm looking through the logs and it could be a endness issue. Is there any way to try such builds on my ppa?
<ScottK> No.
<ScottK> How do you know it's a problem?
<geser> wallyweek: btw which package is it?
<hendrixski> :-( I've been googling this one for a while.  I have dpkg-create-dbgsym installed and packaged something with the debug symbols but I can't seem to get either dpkg-scanpackages or apt-ftparchive to pick them up :-(
<Coper> when I have run pbuild build *dsc Is there anyway to verify that the package is complete? and work correct?
<Coper> ls
<wallyweek> ScottK: I'm guessing ;) I have none of that machine to try a build
<wallyweek> geser: sdlmame -> https://edge.launchpad.net/ubuntu/hardy/+source/sdlmame/+builds
<ScottK> Coper: In KDE, I use ark namd_of_.deb to inspect the binary package and see that it's complete/correct.
<Coper> okey but I don't get any deb file when I run pbuild or debuild.
<ScottK> That's certainly not good.  That or you're looking in the wrong place.
<ScottK> Coper: If this is console-freecel the version you had on REVU that I looked at certainly produced one.
<Coper> okey, but where do I find it?
<jcfp> Coper: try /var/cache/pbuilder/result
<mruiz> bye all
<Coper> I have to move my file /usr/bin/freecell to /usr/games/freecell using cdbs.
<Coper> Anyone that know how to do that?
<ScottK> Lutin: Why did you raise the debhelper version dependency requirement to 6 in ristretto?
<ScottK> Coper: IIRC if you look in debian/rules for pyspf you can see how it's done.
<blueyed> To get a new package from Debian contrib into Ubuntu before FeatureFreeze, you can just request a sync/upload a modified package? Who decides about the section (universe/multiverse)? Is contrib => multiverse? (also if the change would be to use icedtea instead of sun-java?)
<jpatrick> blueyed: https://wiki.kubuntu.org/SyncRequestProcess
<ScottK> blueyed: Archive admins will decide which place to stick it.
<blueyed> jpatrick: so this applies to non-existent packages, too? Great, thanks.
<blueyed> In case of ubuntu changes, I would just upload and it would enter NEW then?
<ScottK> blueyed: Yes
<jpatrick> blueyed: "-n: Specifies that the package is a new package, and requestsync should not attempt to look it up in Ubuntu since it will not exist."
<geser> blueyed: if you know that the package needs ubuntu changes it doesn't make sense to sync it first and upload then with ubuntu changes
<ScottK> blueyed: You should also check after it's NEWed to make sure it's put the right place.  Sometimes the archive admins miss stuff.
<blueyed> geser: therefore I'm asking if I can just upload it directly. I don't mean to sync it first.
<ScottK> blueyed: You can.
<Lutin> ScottK: does it hurt ? (debhelper 6)
<geser> Lutin: it makes at least backporting a little bit harder
<ScottK> Lutin: It does.  It makes backporting harder.  Random increasing version dependencies isn't a good thing.
<mr_pouit> ScottK: ristretto is already for feisty and gutsy in the xubuntu-team paa
<ScottK> Lutin: Arbitrarily bumping to 4 from 1-3 is required because the earlier compats are deprecated.  4-6 should be set as required.
<ScottK> mr_pouit: Yes.  Not in an Ubuntu archive.
<ScottK> As I understand it we discourage use of 3rd party archives.
<Lutin> I wouldn't really call the xubuntu team ppa '3rd party'
<ScottK> Lutin: It most certainly is.  It's not an Ubuntu archive.
<mr_pouit> well, it's as much 3rd party as the backports ^_~
<ScottK> mr_pouit: Not at all.
<mr_pouit> ScottK: then stop saying random_thoughts
<mr_pouit> +$
<ScottK> Backports is an official (but not enabled by default) Ubuntu repository.
<ScottK> Go look at the standard installed sources.list and it's there.  Show me your PPA in the same file?
<Coper> ScottK: I have sent up a new release for review of console-freecell I have change from using only debhelper to cdbs and using patchs to fix the man page problem.
<ScottK> Coper: I'm unlikley to have any reviewing time today.
<Lutin> ScottK: it's not because it's not listed in the official sources.list that it has to be considered just as $random_3rdparty_repo
<mr_pouit> ScottK: so why are you blaming Lutin for bumping the debhelper dependency if you don't care?
<ScottK> Lutin: It's certainly one I'd be more inclined to trust, but it's stil not official.
<Coper> okey, time to sleep anyway. :)
<ScottK> mr_pouit: I care about correct packaging, including potential for backporting.
<ScottK> mr_pouit: If you look at Debian Bug #462547 you'll see he's not the only one I've said this too.
<ubotu> Debian bug 462547 in clamtk "clamtk 3.70 has build-dep on debhelper 6, but doesn't actually need debhelper 6" [Minor,Open] http://bugs.debian.org/462547
<mr_pouit> ScottK: debhelper 6 is correct, and ristretto won't be backported, no issue there
<ScottK> mr_pouit: This recently came up on debian-devel too as an increasingly common bad practice.
<Lutin> (compat 6 is the new recommend version btw)
<ScottK> mr_pouit: Is dephelper 6 required for the package?  I think not because it's fine in Debian without it.
<mr_pouit> 4 or 5 is ok. But using 6 won't break the package...
<ScottK> mr_pouit: Are you the sole determiner of what packages get backported?
<mr_pouit> ScottK: No, you are :Ã¾
<ScottK> mr_pouit: Right, so no reason to push it to 6 and limit the possiblities later.
<ScottK> I like to preserve the option when there isn't a reason to forclose it.
<ScottK> Taken to an extreme, maybe we should have a script that goes through the archive and bumps everything to 6?
<mr_pouit> yeah, and everything to cdbs, that's not fun otherwise =]
<ScottK> Also, since we are by policy supposed to try and minimize our diff with Debian, it's bad for that reason too.
<StevenK> Usually bumping from one debhelper compat level to another won't cause failures
<ScottK> StevenK: Agreed, but it provides no benifit and only limits possibilities if new features of the compat level aren't used.
<Lutin> ScottK: as long as there's a diff, I doubt a 2-bytes change matters much, diff-wise
<ScottK> This is true, but why make it harder?
<Lutin> if it makes harder for you you do have a problem
<ScottK> Imagine a year from now Debian incorporates the other changes leaving that the only diff.  Somone else merges it and assumes you bumped it for a reason and keeps that diff.  We've now lost the chance to have the package auto sync'ed for no valid reason.
<slangasek> ScottK: how goes the bdb pruning effort?
<ScottK> slangasek: Well getting libdb4.6-ruby out of bin New would help ...
<ScottK> $WORK kind of has a hold of me right now, but maybe over the weekend I'll make another attack at it.
<Lutin> ScottK: then you would catch whoever did that
<slangasek> ScottK: heh, hint taken.  I was asking because I'm rebuilding kolab-cyrus-imapd for libldap, and noticed a build-dep on libdb4.2-dev; I suppose you haven't looked at that one at all since it's 4.2?
<ScottK> Lutin: Probably not 'cause I don't see everyting.
<ScottK> slangasek: I did look at it.  I think it needs to be on the same bdb version as (I'm blanking on the other bdb4.2 package) and so I was going to look at them together.
<slangasek> cyrus-imapd-2.2 maybe?
<ScottK> That's the one.
<slangasek> currently, that one's building against db4.3 ;)
<ScottK> OK.  Well then it probably doesn't matter.  I just hadn't looked through it.
<slangasek> ok, no worries
<ScottK> I'm pretty sure kolab can be bumped to 4.6 then.
<ScottK> That and Kolab in Debian/Ubuntu is somewhat broken anyway last I looked, so downside risk is low.
<slangasek> well, I'm not in a hurry to make the db changes if no one's looked through them yet, I was just checking whether it was something that could be batched up with the ldap rebuild
<ScottK> I think it can
<ScottK> The one thing I wasn't sure about was the synchronizaton with cyrus which is clearly not an issue.
<slangasek> ScottK: the package uses BDB transactions, and I don't see any upgrade handling in the maintainer scripts; is this handled some other way within the upstream source?
<anthony> Question: Once u-u-s is subscribed to a bug with an attached fix, how long would you estimate it normally takes for it to get uploaded and closed?
<ScottK> slangasek: Urgh.  Nevermind then.  I'll add it to my transactions list to deal with.
<ScottK> anthony: Anywhere from 30 minutes to several weeks.  There's just no telling.
<ScottK> slangasek: Sorry about that.  I thought I'd checked Kolab for that.
<slangasek> ScottK: ok, again no worries :)
<anthony> ScottK: Ah, all righty then.
<ScottK> Seen on the web - "I did hear many complaints about Vista before buying it, but I frankly did not believe that it could be that bad, especially after as much as a year since its launch. You've got to see it to believe it!"
<slangasek> ScottK: ohwell, kolab-cyrus-imapd also has 64-bit issues with the new ldap anyway, so I'm giving the Debian maintainer time to act on this
<ScottK> OK.  Maybe that'll motivate him to update to a newer release.  Last I heard he was declining for reasons that didn't make a lot of sense to me (IIRC it's been about 6 months).
<james_w> Hi all. The libx11-dev in Debian experimental has dropped the dependency on libxext-dev. This means that all the work done by MOTUs in adding Build-Depends: libxext-dev is now applicable there.
<james_w> If you fixed this in a package, or you come across one with the fix, please forward it to Debian, telling them that it applies to experimental, but it will be a FTBFS serious bug at some point.
<slangasek> I think that's been the status quo in Debian experimental for months already, fwiw
<james_w> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464593 for an example.
<ubotu> Debian bug 464593 in 9menu "9menu: Needs to Build-Depend on libxext-dev" [Important,Open]
<james_w> slangasek: I hadn't noticed until now, but there doesn't seem to have been a MBF for it, and Ubuntu has the patches, so we can help.
 * slangasek nods
<emgent> heya
<wallyweek> g'night all
<asantoni> Hi guys, I have a problem with REVU
<asantoni> I used to have an account before the server wipe, but now it's gone apparently
<asantoni> I still have my Launchpad account (with my GPG key registered), and I'm still a member of the contributors group, so how do I get my REVU account back?
<tsmithe> asantoni, you need to upload a new package, and recover your login on the revu site
<asantoni> (username is gamegod on Launchpad, old REVU account was gamegod@users.sourceforge.net)
<asantoni> tsmithe: ok, I tried uploaded a package a few minutes ago, and it hasn't appeared
<asantoni> (like 20 mins ago)
<tsmithe> odd
<RainCT> good night
<tsmithe> asantoni, was it a source package, not binary?
<asantoni> oh crap
<asantoni> yes, it appears I uploaded the i386 binary
<RAOF> debuild -S is your friend :)
<asantoni> RAOF: yeah, I used pdebuild
<asantoni> it's all nicely rolled into Mixxx's build system now though, hah
<tsmithe> guys, do you think that, as the "Fluid" soundfont is distributed with a file (README.doc) claiming it to be released to the public domain?
<tsmithe> *, we can distribute it?
<tsmithe> TheMuso, how does one find out?
<RAOF> Sounds OK to me, although "Public domain" apparently means different things in different countries.
<TheMuso> tsmithe: I am no license expert, so I don't know.
<tsmithe> ok
<tsmithe> because if it were ok, it would mean a distributable GM soundfont
<tsmithe> which would make a lot of people very happy
<tsmithe> i could always package it up, and see what happens
<asantoni> http://pastebin.ca/895631
<asantoni> I'm missing the source package still after "debuild -S" for some reason
<asantoni> (updated the paste with some output)
<mok0> asantoni: it's not missing?
<mok0> mixxx_1.6.0beta2-0ubuntu1.dsc
<asantoni> mok0: hmmm
<tsmithe> asantoni, try 'debuild -S -sa'
<asantoni> when I uploaded, I used "dput revu *.changes"
<mok0> asantoni: _source.changes?
<asantoni> well, there's no *_source.changes files
<asantoni> tsmithe: will try, thanks
<mok0> asantoni: you need that
<mok0> asantoni: ^^^
<asantoni> ok, that makes sense :)
<asantoni> nuts, same problem (new paste): http://pastebin.ca/895646
<tsmithe> asantoni, no no. the files will be created in ../
<tsmithe> also, you don't need sudo
<asantoni> aha, I have a "mixxx_1.6.0beta1-0ubuntu1_source.changes"
<asantoni> :)
<asantoni> tsmithe: the debs usually end up in /var/cache/pbuilder/result, and I'm too lazy to change the permissions or something
<asantoni> but yes, I know I'm an idiot for running that as root :)
<tsmithe> yes, pbuilder requires sudo. but debuild doesn't :)
<asantoni> ahhh ok
<asantoni> thanks :)
<tsmithe> anyway, i'm off to bed now - night!
<asantoni> good ngiht!
<asantoni> *night
 * asantoni is uploading with the _source.changes now
<asantoni> woohoo, upload worked, thanks guys! http://revu.tauware.de/details.py?package=mixxx
<blueyed> Is it sensible to add yourself to "Author(s)" in debian/copyright, when fixing something in a package? (It's in a debdiff, which I wanted to sponsor)
<crimsun> I suppose you /could/, but I would argue it's not sensible unless you get the blessing of the author(s).
<james_w> blueyed: it's not usually done, however I guess if the author makes a huge change to the project that would mean that upstream would (should?) add a copyright statement for them it could be sensible.
<blueyed> well, it's a minor bashism fix, so I'll request a new debdiff.
<blueyed> How can I find out if a package has been removed in Debian? apt-cache madison does not show it anymore and I could not find it on p.d.o or anything on bugs.debian.org.
#ubuntu-motu 2008-02-08
<emgent> http://www.antsonthemelon.com/gallery/albums/misc/sudo.jpg
<emgent> haahah
<Flannel> emgent: Surely you mean: http://xkcd.com/149/
<emgent> yea :)
<pochu> TheMuso: nevermind, rainct already acked and uploaded it (I had acked it too)
<Legendario> hello everyone!
<Legendario> my flashplugin was working fine, but i guess it was updated today through update-manager and now it's not working anymore. Anyone else with the same problem?
<RAOF> (1) This isn't a support channel (you want either #ubuntu or #ubuntu+1 if you're running Hardy) and (2) you haven't yet provided enough information to make any useful diagnosis :)
<slangasek> it's likely enough, however, that this is bug #173890
<ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install... new version?" [High,Confirmed] https://launchpad.net/bugs/173890
<Legendario> RAOF, i thought i could ask it here because the package is in the universe. sorry
<Legendario> thanks, slangasek
<RAOF> Legendario: That's OK.  But almost all Ubuntu packages are in universe, so... :)
<RAOF> I thought there was a recent upload that fixed that bug (I don't notice, I'm using gnash)
<slangasek> "recent" as in "this morning", I think
<slangasek> so there'll still be echoes of the breakage since not everyone's mirror updates at the same time
<RAOF> Does that mean that we found a way to update it while not breaking !firefox browsers?  Cool.
<slangasek> oh, I have no idea on that
<Legendario> slangasek, but this upload had the problem. Mine was working fine before, and it's not anymore...
<slangasek> Legendario: what version do you have?
<Legendario> slangasek, 9.0.48.0.2+really0ubuntu12
<slangasek> well, that's not either of the updated versions; that's the old version from October
<slangasek> the newest is 9.0.48.0.2+really0ubuntu12.2
<Legendario> the interesting is that my version was installed this morning... :-(
<protonchris> Legendario: It just happened to me.  The work around listed on launchpad did the trick.
<Legendario> protonchris, is there a way to fix it? Manual download it?
<protonchris> Legendario: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/173890/comments/202
<ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install... new version?" [High,Confirmed]
<protonchris> Legendario: Actually, I updated my sources to the main server and I upgraded to the new 12.2 version that works.  Looks like the mirror I was using was out of date.
<Legendario> protonchris, thanks for the hint
<protonchris> Legendario: no problem
<bddebian> Heya gang
<RAOF> Howdie bddebian.
<RAOF> linux-nouveau-modules-2.6.24-5-generic
<RAOF> xserver-xorg-video-nouveau
<RAOF> linux-nouveau-modules-2.6.24-5-generic
<RAOF> xserver-xorg-video-nouveau
<bddebian> Hi RAOF
<RAOF> Ehem.
<rjmyst3> superm1: any news on why wxformbuilder was rejected?
<Legendario> does anyone here know the Wuala? www.wua.la
<Legendario> i have 5 invitation codes to be sent. Anyone interested?
<rjmyst3> my package was sponsored into the archive, but has since been moved to the Rejected queue.
<rjmyst3> https://launchpad.net/ubuntu/hardy/+queue?queue_state=4&queue_text=wxformbuilder
<rjmyst3> can anyone tell me how to find out why?
<RAOF> rjmyst3: I know that superm1 has been asking the archive admins, but hadn't yet tracked down the one who rejected it.
<rjmyst3> RAOF: thank you, superm1 had told me that he would look into it, but with the feature freeze approaching, i'm getting nervous
<rjmyst3> is there anything I can do while I wait to find out?
<RAOF> Um... not that I can think of, no.
<rjmyst3> ok, thanks
<superm1> rjmyst3, its a licensing thing
<superm1> i emailed you
<superm1> after i found out
<superm1> rjmyst3, you didn't include a copy of the license in the root of the orig.tar.gz
<superm1> and several source files are missing licenses
<superm1> rjmyst3, https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/015359.html
<superm1> er maybe that was still in the queue to be headed out, oops :)
<superm1> but that was it ^
<q_a_z_steve> ok, so I tried to jump from dapper to alpha 4... X is obviously out of the question for now. My question, then is: How do I get dpkg --configure -a to run successfully to fix that which definitely didn't install correctly prior to my reboot (which was necessary due to power issues in my area)
<q_a_z_steve> What can I tell you about what I see, in order for some help ?
<rjmyst3> superm1: ok, i'll fix it, thanks
<superm1> rjmyst3, okay thanks.  let me know when its fixed and i'll be able to ack it for you
<protonchris> Is this really a bug since postgres 8.2 is in hardy: https://bugs.launchpad.net/ubuntu/+source/glom/+bug/188939
<ubotu> Launchpad bug 188939 in glom "Glom should depend on postgresql-8.3" [Undecided,New]
<leonel> protonchris: postgresql 8.3  is already in hardy
<protonchris> Yeah, I know.  So what you are saying is that the glom package should use 8.3 even though 8.2 is available as well?
 * protonchris is a packaging newb
<leonel> protonchris: well postgresql 8.2  have been moved to universe  and 8.3 is in main  ..
<protonchris> Ah.  Thanks for the info.
<rhpot1991_laptop> Can someone re-sync the REVU uploaders keyring?
<ScottK> protonchris: Having it depend on postgres 8.3 | postgres 8.2 would make sense then.
<ScottK> That way people can choose.
<joejaxx> anyone have an example of an autogen package that does NOT use that cdbs nonsense? :P
<LucidFox> joejaxx> CDBS is not nonsense
<joejaxx> LucidFox: :P
<LucidFox> By an autogen package, you mean a package that runs autotools first besides just running ./configure?
<joejaxx> yeah or there is a ./autogen.sh script
<joejaxx> s/a/an/g
<LucidFox> hmm, let me see
<joejaxx> i am trying to package audit
<joejaxx> :)
<joejaxx> and some other packages
<ScottK> LucidFox: It may not be nonsense, but it is black magic.
<LucidFox> heh
<RAOF> joejaxx: They're just like regular debhelper packages, but you call autogen rather than configure (generally).
<joejaxx> ah bah wth
<joejaxx> it is in debian already
<LucidFox> heh
<joejaxx> :( fail :(
<joejaxx> :P
<LucidFox> anyway, per RAOF :)
<RAOF> Also, I was under the impression that re-autotooling during package build was frowned upon as a Bad Thing.
<joejaxx> oh well i can still apply those policycoreutils gui patches
<joejaxx> RAOF: oh ok
<joejaxx> RAOF: no i just wanted an example as dpkg-buildpackage kept stopping
<LucidFox> As for CDBS, I used to hate it and avoid it like plague. Now I use it whenever I can - and I usually can't only for _really_ screwed up upstream build systems
<joejaxx> oh wow the version in debian is super old
<joejaxx> :\
<joejaxx> even in unstable
<joejaxx> LucidFox: oh ok
<RAOF> LucidFox: Whereas I went the other way; I used to preferentially use CDBS.  Until I started to do non-trivial things, at which point I was just fighting the undocumented magic.
<LucidFox> joejaxx> Can't you take the Debian package as a basis and just update it to a new upstream version?
<LucidFox> RAOF> heh
<joejaxx> LucidFox: maybe
<RAOF> At least debhelper is *documented* magic :)
<joejaxx> RAOF: :D
 * joejaxx does not like blacboxes
<joejaxx> blackboxes*
<LucidFox> For example, I had to switch from CDBS to debhelper for kde4-style-qtcurve, because I couldn't find any way to do double builds in CDBS
<RAOF> It's probably possible, but why fight your tools?
<LucidFox> (although the original CDBS packaging wasn't mine)
<LucidFox> RAOF> Exactly.
<ScottK> joejaxx: If it's in Debian, please don't redo the packaging.  Minimize the diff with Debian.
<joejaxx> ScottK: redo the packaging?
<joejaxx>  /win 64
<joejaxx> bah
<ScottK> joejaxx: I may have misunderstood, but I thought you were considering packaging a newer version of something in Debian without using the package in Debian as a basis.
<RAOF> That's an unhealthy number of irc windows :)
<joejaxx> ScottK: i just found out it was in debian :P
<joejaxx> ScottK: it was not there last time i looked at packaging it
<ScottK> I see.
<joejaxx> albeit might have been a while
<joejaxx> lol
<ScottK> Good night.  I'm off to bed.
<joejaxx> Goodnight
<joejaxx> RAOF: lol
<joejaxx> how does this work if i want to package a newer version?
<joejaxx> and it is not in the archive
<joejaxx> well actually
<joejaxx> hmm
<joejaxx> oh well
<joejaxx> lo
<joejaxx> l
<LucidFox> joejaxx> I think it can be managed like a regular upstream update, except if you're submitting an interdiff, use the last Debian version as the basis instead of the last Ubuntu version. I may be wrong, though.
<LucidFox> Or it may be better to sync the current Debian version first, and then update.
<joejaxx> i do not know if i want audit in the archive yet :\
<joejaxx> the selinux stuff has not made it in yet
<LucidFox> joejaxx> So the package in question is audit?
<joejaxx> i was actually only going to upload this to a ppa since this is my first time packaging python software, revu has passed :P and there are hardly any days left
<LucidFox> audit is already in the archive: https://launchpad.net/ubuntu/+source/audit
<joejaxx> until feature freeze
<joejaxx> oh
<joejaxx> is there anyway to find out who requested that?
<mkoehler> Evening - I'm trying to learn the packaging process, and I'm running into trouble with the hello package.  When I get to the point of running pbuilder, it ends up giving the following error "gzip: debian/tmp/usr/share/man: No such file or directory make: *** [binary-arch] Error 1:dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2"  Can anyone offer any suggestions?
<joejaxx> oh no wonder
<joejaxx> apparmor :\
<LucidFox> joejaxx> look at the uploaders
 * joejaxx cringes
<LucidFox> the first version was autosynced
<LucidFox> Subsequent ones were uploaded by Mathias Gug
<joejaxx> lol i wonder if setroubleshoot is in there now
<LucidFox> mkoehler> You probably should just move to hello-debhelper; packaging without debhelper is pretty pointless anyway
<joejaxx> nope it is not in there
<joejaxx> maybe i will package that :\
<mkoehler> sure, thanks
<rhpot1991_laptop> Can someone re-sync the REVU uploaders keyring?
 * LucidFox pings Hobbsee
<RAOF> LucidFox: You're going to add some context to that ping, right? :P
<LucidFox> If she replies, I'll explain :)
 * RAOF finds that sort of ping really annoying.
<LucidFox> I see.
<RAOF> Because I then go hunting through backscroll to find the context... and it's not there!
<mkoehler> Can somebody re-sync the REVU uploaders keyring?
<vemon> why are packages kept in the ppa's pool dir even after they been deleted from the launchpad ppa user interface?
<q_a_z_steve> http://qaz.pastebin.org/18670
<vemon> this apparently keeps me from uploading a new version with the same versino number and/or upstream version
<vemon> and if i need to change the version number every time then what would be a good base version to use for packages still in revu?
<Hobbsee> You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<Hobbsee> LucidFox: ^
<Hobbsee> RAOF: or i can just not reply
<superm1> Hobbsee, could you sync the revu keyring (in case you didnt see the above requests)?  There were a few new contributors looking to add some stuff
<LucidFox> Hobbsee> mkoehler requests the REVU keyring synced
<LucidFox> heh, superm1 beat me to it
<Hobbsee> superm1: i did yesterday.  i'll do so again
<LucidFox> sorry for the contentless ping
<superm1> Hobbsee, new people today :)
<Hobbsee> woot :)
 * Hobbsee thwacks smarter with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! â¢
 * Hobbsee thwacks  Albert Santoni too
<Hobbsee> superm1: were either of those on your sync list?
<superm1> i dont think so :)
<superm1> rhpot1991_laptop, was the one who had something i was gonna look at
<Hobbsee> good
<superm1> what'd they break?
<Hobbsee> uploaded binaries to REVU
<superm1> bah.  silly people
<Hobbsee> the nutter on hte ML earlier uploaded 3 different versions of a package, without realising what was wrong, either
<LucidFox> dpkg depends on lzma now? What for? orig.tar.7z?
<LucidFox> :)
<RAOF> LucidFox: Indeed :)
<man-di> LucidFox: for the content in the *.deb
<RAOF> Well, rather for packing .debs with lzma so as to reduce size by some tens of percent.
<LucidFox> heh
<LucidFox> by the way, is orig.tar.bz2 allowed now?
<dholbach> good morning
<RAOF> Evening dholbach!
<dholbach> hey RAOF
<Hobbsee> LucidFox: no
<HighNo> good morning
<LucidFox> :(
<HighNo> if someone is feeling bored and has a bluetooth device would he like to check out http://revu.tauware.de/details.py?package=blueproximity for advocating? Formal errors should be almost gone as mok0 has given many advices...
<HighNo> (it's cool stuff to have installed anyway ^_^)
<warp10> Good morning!
<RAOF> Why must copyright be so hard :/
<HighNo> RAOF: what you write is yours. that's not too hard :-) [I know what lawyers make of it... )
<RAOF> HighNo: Yup, that's easy.  What is less easy is when other people write things, intending for them to be used by others, but have no license headers.
<LucidFox> If someone feels like reviewing/advocating a REVU package, I'd recommend http://revu.tauware.de/details.py?package=qdevelop
<LucidFox> (not my package)
<LucidFox> I like IDEs that are written in the same language/framework they're designed for.
<Fujitsu> Except when it's Java.
<LucidFox> Even when it's Java.
<Fujitsu> Eclipse is slow.
 * LucidFox uses Eclipse
<LucidFox> Not for me :)
<LucidFox> On computers low on memory, yes, it _is_ slow
<DarkMageZ> um... when a single application can sit there and eat 250MB of ram...
<DarkMageZ> i think it's not the system, it's the app.
<RAOF> One of my friends uses Eclipse, and he has occasionally complained that it eats multiple gigabytes of ram in some cases.
 * Fujitsu points DarkMageZ at Firefox.
<DarkMageZ> bloody azureus...
<RAOF> Disclaimer: I don't know what he's actually trying to do with it, or what version.
<DarkMageZ> Fujitsu, mozilla team fails at coding.
<Fujitsu> Indeed.
<DarkMageZ> i mean xul? what on earth were they smoking... probably high quality stuff funded by google. (don't correct my timeline)
<LucidFox> Well, XUL was conceived back when GTK was ugly and Qt was proprietary
<RAOF> DarkMageZ: Cross platform, performant, native-looking guis described by XML are easy!
<DarkMageZ> yeah, but it's like communism. you give it a shot then realise it sucks and move on.
<LucidFox> Although I'll probably retire Firefox once midori or epiphany-webkit reaches a usable state
<DarkMageZ> or rewrite it from scratch with a superior design :p
<RAOF> Firefox wouldn't be so annoying if gecko was an actual library.  With a soname.  In LDPATH.
<LucidFox> well, there's libxul
<LucidFox> and now Firefox 3 atop xulrunner
 * RAOF laughs derisively.
<DarkMageZ> this is why webkit it awesome ?
<RAOF> So, they satisfy part 1.  They're nearly libraries.
<DarkMageZ> is*
<LucidFox> Webkit is awesome because it's FAST.
<RAOF> And small, and apparently a joy to GTK in.
<LucidFox> Indeed.
<DarkMageZ> webkit is getting a lot of focus as of late. isn't QT 4.4 integrating it?
<RAOF> Oh, really?
<LucidFox> Indeed. And Phonon.
<LucidFox> _And_ it's going to be GPLv3.
 * RAOF still doesn't get phonon.
<DarkMageZ> QT's gonna be a development platform of its own at this rate.
<LucidFox> DarkMageZ> You mean it already isn't?
<LucidFox> RAOF> NIH syndrome, it seems
<DarkMageZ> LucidFox, not till it has phonon and a few other things.
<DarkMageZ> RAOF, the idea behind phonon is that you won't need to code for multiple audio backends. you code for phonon, phonon calls various audio backends to do its bidding.
<RAOF> LucidFox: But then QT went ahead and made sure that GStreamer worked nicely on windows & os:x, so they've got gstreamer->phonon->qt everywhere.
<RAOF> DarkMageZ: ^^^.  Or you could use gstreamer everywhere, and not need to care.
<DarkMageZ> RAOF, gstreamer is complex to code for directly. having a childsplay to code for toy like phonon is good.
<RAOF> Maybe.  From what I've seen, gstreamer is pretty easy to do simple things in.  But it would, of course, need C++ bindings.
<LucidFox> The problem with thin wrappers for native subsystems is, they will always have different bugs on different platforms
<LucidFox> (look no further than SWT and wxWidgets)
<DarkMageZ> very true
<RAOF> And, in the case of those, the native widgets will just plain behave differently so you're fighting uphill all the way.
<DaveMorris> can someone do a quick check on the questions I have at the bottom of http://revu.tauware.de/details.py?package=gtkglextmm please
<LucidFox> gtkglext STILL isn't in the archive? o_O
<DaveMorris> no
<DaveMorris> it's in dapper
<LucidFox> oh, wait, gtkglext _is_ in the archive - gtkglextmm isn't
<DaveMorris> I only realised yesterday when I went to install it for my project thats going to be targeting hardy (after dapper)
<LucidFox> misread the package name
<DaveMorris> oh yeah, this is c++ bindings
<DaveMorris> LucidFox: you able to answer my questions on the package regarding the changelog and if I need a bug report for it
<LucidFox> DaveMorris> No, I'm afraid I'm in no position to answer these questions
 * DaveMorris off to work :)
<RAOF> Dear kern.log: stop filling up my /
<HighNo> RAOF: hehe, I know what you mean: df -h: /dev/sda5              20G   19G  122M 100% /
 * Fujitsu doesn't think his is eating much.
<Fujitsu> .... or maybe it is. A few hundred megabytes in 2 days.
<Yagisan> my logs go nuts when I put my bluetooth dongle in. It spams the hell out of it.
<HighNo> Yagisan: that does not sound healthy
<Yagisan> HighNo, it certainly isn't. It's a great way to up the load average
<Yagisan> walk over - attach dongle - watch system slow down, and the disk light turn on
<HighNo> Yagisan: do you have some lines for me?
<Yagisan> one moment - I'll plug it in
 * HighNo awaits your ping timeout :-)
<HighNo> this seems way off topic for this channel, maybe we should do that in private
<Yagisan> HighNo, http://rafb.net/p/tlLPhX50.html
<Yagisan> HighNo, you can see how fast it spams
<HighNo> Yes
<TuxCrafter> hello everybody,
<HighNo> btw, is there is list with all MOTUs on there?
<TuxCrafter> is there a motu that has the time to package the latest maxima program http://sourceforge.net/project/showfiles.php?group_id=4933 for http://packages.ubuntu.com/hardy/math/
<TuxCrafter> HighNo: a list of the moto can be found on the launchpad motu pages
<TuxCrafter> s/moto/motu/
<HighNo> just to get an idea of how many of you exist... cool Tux
<TuxCrafter> HighNo: if you can find the list of active users that update using Apt-get on ubuntu this will be great for me
<TuxCrafter> Unique IP logins on the repos
<TuxCrafter> the fedora project has a very nice stat page
<TuxCrafter> http://fedoraproject.org/wiki/Statistics
<luisbg_> how do I make a cdbs created package run a .install I just created for it?
<TuxCrafter> fedora has now 1,920,667 computer users
<HighNo> yeah, that's very cool. Shouldn't you talk to some canonical guy to get this going?
<sladen> TuxCrafter: I think Canoincal enjoy the fact that they have more, alot more, but don't feel the need to show their hand
<TuxCrafter> sladen: i would would really appreciate if they share the info
<sladen> TuxCrafter: then make the case to them
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms :)
<TuxCrafter> sladen: jups sorry i went offtopic
<TuxCrafter> back to the maxima package, is there a motu that is willing to do a upgrade
<TuxCrafter> or should i do a bug report that there is a newer version on launchpad
<Fujitsu> TuxCrafter: Ideally, Debian would do the upgrade and we would merge from them.
<TuxCrafter> maxima is an very important package for people doing technical education
<mok0> TuxCrafter: Maxima is pending a merge. It's free for you to do afaics: http://dad.dunnewind.net/maxima/
<Fujitsu> mok0: Isn't the only change in Debian a dash-related NMU?
<TuxCrafter> mok0: 5.13 is still to old
<TuxCrafter> 5.14 is the new one
 * TuxCrafter is compiling them now
<mok0> Is it in SId?
<Fujitsu> It'd be optimal if you could convince Debian to upgrade it first.
<Fujitsu> mok0: It's not.
<Fujitsu> Neither is the new gEDA :(
<TuxCrafter> gEDA is also very importand
<Fujitsu> Yes, I'm talking with one of the upstream devs about that.
<TuxCrafter> if i become a motu
<Fujitsu> I'm expecting to upload 1.4.0 in the next couple of days if Debian doesn't get to it first.
<TuxCrafter> i will do the technical packages
<TuxCrafter> geda maxima etc
<TuxCrafter> but i am still in training
<TuxCrafter> and i have to see were xubuntu and ubuntu is heading to this year
<TuxCrafter> else i go to back to fedora
<mok0> Yuc
<HighNo> did anyone just use the bad word in here? :-)
<TuxCrafter> or i will start my very long awaiting ubuntu based distro :-p
<mok0> TuxCrafter: Why don't you contact the Debian maintainer of maxima and ask what the plans are. If (s)he is busy, perhaps you can do a NMU
 * Yagisan deployed xubuntu and ubuntu into the wild. Still not yet ready to send my pet project back to revu
<TuxCrafter> mok0: i sent a mail to the debian maintanner
<TuxCrafter> maintainer
<mok0> TuxCrafter: and...?
<TuxCrafter> mok0: i have to get a mail back first :-p
<TuxCrafter> but i just compiled and installed it on my own machine
<TuxCrafter> perfect this is more like it
<HighNo> do motu's own bluetooth'able machines?
 * RAOF does
<HighNo> RAOF: now if you are motu then you probably don't have the time to check my package right? http://revu.tauware.de/details.py?package=blueproximity
<RAOF> Not right now, no.  I'm off to bed.
<HighNo> RAOF: how can you go to bed now? it's not even 12pm :-) [in Germany]
<RAOF> Whereas it's 10pm in .au :)
<Yagisan> oh another tpg user RAOF ?
<Yagisan> night - I may bug you for war stories with tech support later
<HighNo> which is also a nice place to live. Can you tell me how you guys manage not to fall of the earth, it's all upside down, isn't it? 8-)
<Yagisan> HighNo, I'm not sure, it's not us on the bottom - how do you stay down :P
<HighNo> hehe, good point
<gnudles> when will you publish amarok KDE4 build?
<gnudles> hi :)
<HighNo> Did I say good night at RAOF? Think of me tomorrow :-)
<DaveMorris> can I have a quick answer to the questions I've raised in my package upload please.  at http://revu.tauware.de/details.py?package=gtkglextmm
<shibata> Hi, all.
<asabil> hi all
<asabil> anyone to review
<asabil> http://revu.tauware.de/details.py?package=json-glib
<asabil> thanks
<mruiz> hi all
<mruiz> ping DktrKranz
<norsetto> bidibibodibibu
<slytherin> persia: Do you think now is the good time to preseed debconf for j2sdk1.4 also?
<persia> slytherin: Absolutely no idea.  If there are a number of FTBFS issues due to the lack of preseeding that cannot be solved with other javac implementations, the answer may be yes.
<slytherin> persia: one of them which I consider important is batik and its fop which depends on batik for building
<DktrKranz> hey mruiz :)
<DaveMorris> persia: you able to spare 5 mins to answer my questions on http://revu.tauware.de/details.py?package=gtkglextmm ?
<mruiz> DktrKranz, I have uploaded a new revision of mnemosyne :-)
<DktrKranz> mruiz, nice! what about upstream?
<mruiz> DktrKranz, he didn't notice about issues with python 2.5 :D
<DktrKranz> mruiz, if upstream is comfortable with 2.5, you should adjust pyversions accordingly
<persia> DaveMorris: My only real issue was that it was removed as being hopelessly buggy.  Have all the RC bugs been addressed?  How is this package useful?
<mruiz> DktrKranz, ups... I forget it
<DktrKranz> mruiz, I don't remember the right syntax, though. You'll need to browse python policy for that
 * mruiz updating pyversions
<DaveMorris> persia: do I continue the same changelog and do I need to open a bug for it?
<ScottK> mruiz: Are you using pycentral or pysupport?
<DaveMorris> re is it useful?  Well if 3rd party developers are only targeting LTS platforms, then they could be in for a shock, when they find it's no longer in the next LTS
<dholbach> MOTU Q&A session in #ubuntu-classroom in 10 minutes
<persia> DaveMorris: I'd continue the changelog, and open a bug "Please restore the package" to be closed with the changelog.  Also, I strongly advise you examine the bugs that led to removal: if they are still open, we will have the same issue for the next LTS, and it may be better to have the pain now, rather than once Ubuntu adoption is even more widespread.
<DaveMorris> ok, still struggling to find the bugs with it which are open
<DaveMorris> the RC bug was a FTBFS on the 1.0 version
<persia> DaveMorris: http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=1;version=;dist=unstable;package=gtkglextmm;repeatmerged=1 is likely the appropriate place to start.  These bugs look closed, but may well have been closed by the package removal.
<DaveMorris> yeah, I can only find FTBS and missing dependencies (and wishlists to upgrade to 1.2 )
<persia> Those would all be RC, and would have to be fixed to get through REVU.  Sounds fine to me: you might want to leave a comment indicating that you've addressed all the outstanding Debian & Ubuntu bugs you could find with the package update.
<DaveMorris> yeah thanks
<DaveMorris> btw, how come it appears as a new package rather than an update.  Is it because it's not currently in Hardy
<persia> DaveMorris: It is also absent from feisty and gutsy, but yes.
<DaveMorris> can you set a bug to depend on another bug been fixed in LP?
<persia> DaveMorris: Nope.
<DaveMorris> hmmm, shame
<persia> DaveMorris: There was a recent thread about this somewhere (ubuntu-bugs@ ubuntu-motu@?  Ask google) in which the difficulty in understanding the meaning of such a dependency for a wide number of use cases was discussed.
<DaveMorris> I'll dig out the threads, thanks
<proppy> oy
<RainCT> Hey
<jdong> hi
<mruiz> DktrKranz, please review the new upload of mnemosyne :-)
<DktrKranz> mruiz, sure
<mruiz> DktrKranz, thanks
<DktrKranz> mruiz, erm... I fear I'll have a look at it later, sorry :(
<mruiz> DktrKranz, no worries :) The package will be waiting for you
<dcordero> hi
<DktrKranz> mruiz, thanks for your patience :)
 * mruiz hugs DktrKranz 
<DktrKranz> hola dcordero :)
<dcordero> hi DktrKranz  :)
<DktrKranz> dcordero, will you be there in a hour? I'd like to work at 187356, it's quite close to be solved :)
<dcordero> yep, i'll be there, i have some question
<DktrKranz> fire them
<dcordero> it's on the bug comments :) I have 2 problems with this bug
<dcordero> and another thing, can i run a package with X from a debootstrap chroot ?
<DktrKranz> IIRC, outdated-autotools-helper-file can be solved adding autotools-dev to build-depends
<persia> DktrKranz: Rather, it can be worked around by doing that, and copying the files included in that package in the configure: rule.  Fixing it requires one of 1) an upstream update, 2) upstream not shipping the helper files, 3) manually updating the files at packaging time, or 4) copying the updated files in the clean rule (please don't do this).
<persia> dcordero: To run X clients from a chroot, you either need to pass your environment variables into the chroot or have the chroot open a new display (VT8 or VT9 are popular choices, unless you have extra graphics cards and display hardware).
<dcordero> :/ Ok, i'll search about it, thanks
<lar2> Hi, tried my first revu upload this morning.  dput seemed happy, but I'm told by a human that the upload was rejected.  Trying again, dput says "Already uploaded to revu.tauware.de".  I guess I missed something?
<persia> dcordero: http://www.debian-administration.org/articles/566 may have some useful hints.
<man-di> lar2: 'rm *.upload' helps
<dcordero> thanks persia
<persia> lar2: Delete sun-javadb_10.3.2.1-0ubuntu1_source.upload and try again
<DaveMorris> lar2: or use the -f flag
 * persia doesn't like the -f flag, it becomes a habit, and leads to a mistake (or at least did for me)
<lar2> Thanks for the tips - but now I got a network issue ;)
 * RainCT tries to figure out why ushare was rejected.. http://paste.ubuntu.com/4341/plain
<persia> RainCT: If the reason doesn't appear in https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/thread.html fairly soon, complain to today's archive-admin about why it wasn't reported.
<persia> RainCT: Ideally, you'd see something like https://lists.ubuntu.com/archives/ubuntu-archive/2008-February/014953.html
<RainCT> persia: ok, thanks
<ScottK> The only time I got rejected pitti mailed me directly.  Do they not do that anymore?
<jdong> Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
<jdong> thanks, bzr.
<jdong> format: [ f for f in all_formats] ?
<persia> ScottK: From what I understand from the documentation, they are supposed to mail all of Changed-By, Uploaded-By, and the mailing list.  The first two seem to be a one or the other or both in a somewhat random fashion, but the mailing list is a constant.
 * ScottK does the clamav on dapper victory dance.
<persia> So, if you are both Changed-By, and Uploaded-By, you're very likely to get the mail, but this isn't so true for REVU uploads always.
<ScottK> For those not following, the current clamav and suitable rdepends updates just got published to dapper-updates.
<persia> ScottK: Congratulations!  Impressive coordination.
<dholbach> ScottK: good work!
<ScottK> As it happens the timing is good for me personally since my core-dev application goes to the tech board on Tuesday.  That effort is my masters thesis on distro integration.
<ScottK> Thanks.
<dholbach> hehe :)
<huats_> ScottK: great work
<HighNo> I've got a question - does a package for ubuntu need to run with kubuntu (kde desktop only?) As I have noticed my package would not because e.g. the icon for the notification area is a format (svg) that only gnome likes, kde doesn't
<ScottK> Thanks.
<Amaranth> HighNo: KDE works with svg icons
<slytherin> HighNo: Beasides you can have a package for only GNOME. It is not a crime. :-)
 * persia remembers something funny about KDE3 and special directories for svg icons, but the details are fuzzy, outdated, and possibly completely wrong.
<HighNo> slytherin: pehw, I was kind of scared I would have to rewrite my software...
<pi-meson> This is off-topic, but I can't seem to find a good channel -- can anyone recommend a channel for dealing with autotools/automake/autoconf issues?
 * persia thought there was a dedicated freenode channel for just that purpose
<pi-meson> persia, any idea what it's named? I've both googled and text searched the channel list on freenode with limited success
<sistpoty|work> hi folks
<persia> pi-meson: My apologies, but no.  I don't see anything that seems to have the right name on either freenode or oftc, even including goat-themed channels :(
<persia> pi-meson: http://sourceware.org/autobook/autobook/autobook.html might be useful though, if non-interactive works for you.
 * DaveMorris knows it's late in the day but wonders if someone could review http://revu.tauware.de/details.py?package=gtkglextmm to get it back into Ubuntu
<persia> DaveMorris: Do you know of any external ISVs that depend on that?
<DaveMorris> ISV?
<pi-meson> persia, it's okay, thank you for looking! I've looked at the autobook a bit, but it's woefully short
<pi-meson> DaveMorris, oh my, I just packaged gtkglextmm the other day for my project, I was really sad when it fell out of ubuntu!
<persia> DaveMorris: Somebody who writes software not included in the distribution
 * DaveMorris points at pi-meson
<DaveMorris> bug #104804 has been around for a whle aswell.  That makes reference to sharpconstruct needing it
<ubotu> Launchpad bug 104804 in gtkglextmm "gtkglextmm-1.2.0 is missing in feisty" [Wishlist,In progress] https://launchpad.net/bugs/104804
<persia> pi-meson: You need it?  Please comment on the bug to indicate support.
<pi-meson> persia: bug 104804?
<persia> pi-meson: Yep.  That's the bug that needs enough support to get someone to upload.
<pi-meson> I'm sorry, I'm somewhat new to this, everything I've ever wanted has always been packaged by default :) do I just add a "me too" note to the bug with a description of my app?
<persia> pi-meson: That would work.  The package was removed previously because it was broken and didn't work.  Having multiple users indicate they want it helps get it back.
<bddebian> Heya gang
<sistpoty|work> hi bddebian
<bddebian> Hi sistpoty|work
<pi-meson> done!
<DaveMorris> pi-meson: could you stick that comment on the revu page as well?
<geser> Hi bddebian!
<bddebian> Heya geser
<pi-meson> DaveMorris: I don't seem to be able to login to revu, is there a url for account creation you could point me to?
<DaveMorris> you need to upload a package afaik
<DaveMorris> leave it on the bug report then, that'll do
<DaveMorris> then we can nicely ask someone to review it ;)
<pi-meson> wow, though, great timing, today must be my lucky day
<DaveMorris> yeah, I forgot it needed packaging, till I went to build my software on another machine yesterday and had to build it myself
<LucidFox> If I become a MOTU before FF, gtkglextmm will be the third REVU package I'll review - after qdevelop and tomboy-blogposter.
<DaveMorris> LucidFox: you have programs that depend on it then?
<LucidFox> No
<pi-meson> Is the hope that we can get gtkglextmm into the next LTS? or is it too late?
<DaveMorris> pi-meson: FF is the 14th
<pi-meson> FF == Final Freeze, not "Feisty Fawn", i'm realizing now
<LucidFox> heh
<LucidFox> actually, it's Feature Freeze
<pi-meson> okay, that makes even more sense
<pi-meson> LucidFox, could I then beg you to review libdc1394-22 as well? you know, maybe bribe you with food or something
<LucidFox> lol
<HighNo> hehe, that's it. speed up the motus by sponsoring them directly. wasn't there a world wide pizza delivery service? MOTUs! Go and advocate blueproximity - a free pizza is going to you! :-)
<HighNo> (I guess free beer would be a better motivation to most :-)
<LucidFox> HighNo> Not to me. I don't drink alcohol.
 * DaveMorris will REVU for food
<mruiz> if there is no revision number in debian, the first revision in ubuntu should be X.Y-0ubuntu1 ?
<DaveMorris> yes
<ScottK> Is there a documented procedure for testing to see if a package builds with GCC 4.3?
<jdong> nscreen -x
<HighNo> DaveMorris: You got a bluetooth machine?
<linux__alien> hey friends
<DaveMorris> HighNo: yeah, and a blue toothphone.  But I'm not a MOTU yet
<HighNo> DaveMorris: Darn, you fault you told me first :-) there goes your pizza...
<geser> ScottK: install gcc-snapshot in your pbuilder and update the gcc symlink
<\sh> ScottK, yes
<\sh> ScottK, take the toolchain from ubuntu-toolchain team, and add them to your pbuilder/sbuild
 * ScottK waits for geser and \sh to agree.
<\sh> doko had written a mail for this
<\sh> ScottK, I'm using the gcc 4.3 stuff from https://edge.launchpad.net/~ubuntu-toolchain/+archive, which is dokos and others playground for new toolchar
<\sh> toolchain
<geser> ScottK: then do what \sh said, my test-build with gcc 4.3 is some time ago
<jdong> "64 bit CPU and 64 bit OS. I don't even think of using 32 bit OS anymore.
<jdong> All the 64 bit vs 32 bit compatibilty issues are easily solvable via dpkg --force or dpkg -X in my case."
<jdong> dear.... effing... loard
<jdong> lord*
<\sh> ScottK, and check the dbts, a good reference is martin michlmayr (his bug page: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.3;users=tbm@cyrius.com)
<\sh> ScottK, and check out his blog (http://www.cyrius.com/journal) a very good source for how to fix 4.3 ftbfs bugs
<ScottK> Thanks.
<\sh> ScottK, I started 2 weeks ago to check some packages of us, where bug fixes were filed from martin, and many of those fixes are already applied by doko or others
<broonie> Lots of teh fixes for 4.3 should be in Debian already.
<linux__alien> hey norsetto
<linux__alien> hey LucidFox
<DaveMorris> HighNo: I've buillt and installed your package, how do I configure it?
<DaveMorris> found it
<HighNo> DaveMorris:  When started for the first time it should give settings
<ScottK> broonie: I just took over a package in Debian that's got a GCC 4.3 FTBFS bug on it and I'm trying to make sure.
<ScottK> \sh: Since you're already set up for it, would you mind doing a test build for me?
<\sh> ScottK, sure...when I'm coming home I can do that :)
<ScottK> \sh: Thanks.
<\sh> ScottK, just send me a mail or something with the package :)
<DaveMorris> HighNo: it doesn't run, you tried it on hardy?
<\sh> ScottK, ah wait...just give me the package :)
<ScottK> \sh: OK.  It's the current klamav package in Hardy.
<broonie> ScottK: Ah, I see. I'd been working on some of those bugs but IIRC the packages that remained weren't overcoming my enthusiasm/apathy limits
<HighNo> DaveMorris: no, because I am bound to Feisty due to limited drive space
<HighNo> DaveMorris: tell me more
<\sh> ScottK, give me a sec :)
<ScottK> broonie: The old klamav maintainer hadn't touched the package in over a year, so it isn't suprising no one was excited about digging into it.
<DaveMorris> "The program cannot import the module bluetooth"
<\sh> ScottK, 0.42-0ubuntu1?
<broonie> ScottK: Yeah, and the KDE bit tends to be a bit of a turn-off for me.
<\sh> ScottK, most propably some bug like described on this page: http://www.cyrius.com/journal/gcc/gcc-4.3-include.html
<ScottK> \sh: Yes, but the Debian vesion is ancient and I'm hoping the one just released last month works.
<\sh> it's building :)
<ScottK> Great.  Thanks.
<HighNo> DaveMorris: ehm, ok. I'll look which package supports it with feisty and we can look what is missing...
 * DaveMorris is off home in 45 mins though
<\sh> ScottK, ok...I need to leave the office...I let it build, and when I'm coming home, I have my buildlog file in my inbox :)
<ScottK> \sh: Sounds good.  Thanks.
<\sh> ScottK, you're welcome .)
<mok0> Does anyone here remember a package that employs chrpath? I'd like to peek at it
<\sh> grmpf...damn keyboard from dell
 * \sh needs to needs his logitech back
<HighNo> DaveMorris: it must be in python-bluez
<DaveMorris> that package is installed, since that's what it recommends I install
<\sh> ScottK, bad luck...
<HighNo> DaveMorris: /usr/share/pycentral/python-bluez/site-packages/bluetooth.py
<\sh> ScottK, eMail address to send you the buildlog?
<ScottK> \sh: scott at kitterman dot com
<\sh> ScottK, send...
<ScottK> I don't know why I do that.  That's been my address for a decade and I'm already on every spammer list in the world.
<ScottK> Thanks.
<ScottK> \sh: Is it a happy ending or a sad one?
<\sh> ScottK, sad one
<ScottK> Thanks.
<ScottK> Urgh.
<\sh> ScottK, if you need an i386 build please let me know...I set up an i386 sbuild for gcc43 work then
<ScottK> Thanks.
<DaveMorris> HighNo: nope, different path
<\sh> ok...rushing home :)
<\sh> bbl
<DaveMorris> /usr/share/pycentral/python-bluez/site-packages/bluetooth/bluez.py
<HighNo> DaveMorris: different path could be - this is feisty. And managed by pycentral, the used file is at /usr/lib/python2.5/site-packages/bluetooth.py
<HighNo> DaveMorris: ahh, so that package changed after feisty. good to know.
<HighNo> DaveMorris:  I'll dissect that package, I know I have 30 mins left...
<HighNo> Hm, I am in a pbuilder environment logged in. I am using feisty but the environment is setup for hardy. I want to install python-bluez but it's not found. Did they change the name=
<HighNo> ?
<gpocentek> HighNo: is universe enabled in your pbuilder ?
<HighNo> ahh, thx - i forgot to enable it...
<mok0> Is there a way to find reverse Build-Depends?
<Amaranth> mok0: grep through Sources.gz
<mok0> Amaranth: thx
<linux__alien> LucidFox, I am going through the Packaging Guide. Once i am done with, i would need your advice to go further
<linux__alien> please LucidFox
<LucidFox> linux__alien> whatever I can help with
<LucidFox> it's better, however, to refer to the channel in general
<LucidFox> rather than specifically to one person
<HighNo> Hm, there is probably an error with python-bluez. The docs are only partly included. the html manual consists of just one file that links to several non existant ones...
<ion_> amaranth: grep-dctrl -FBuild-Depends -sPackage ghc /var/lib/apt/lists/*_Sources
<linux__alien> ya sure but want to contribute to Ubuntu and want to be a part of the team, but i dont have a mentor unfortunately :(
<Amaranth> ion_: Yeah, I can never remember that, I wonder why :P
<linux__alien> LucidFox, I ve generated the basic files for packaging for an example but the rules file which is got generated does not have much contents, should i manually type or can i generate that too ?
<LucidFox> linux__alien> Are you using dh_make?
<linux__alien> yes
<mok0> dh-make, yeechh
<linux__alien> i ve the other files proper but the rules files contains two include files thats it
<linux__alien> cant the rules file be generated at all ?
<mok0> linux__alien: you're using cdbs, that
<mok0> is cool
<linux__alien> mok0, so am i on the right track ? :)
<mok0> linux__alien: yeah
<LucidFox> o_O
<LucidFox> so abruptly
<mok0> hehe
<mok0> The old ^D
<mok0> Here he is again
<linux__alien> mok0, sorry got disconnected . i am using cdbs
<LucidFox> linux__alien> CDBS isn't very newbie-friendly, though
<HighNo> DaveMorris: Sorry, I had to file the bug first... I'm looking for the manual of that package...
<LucidFox> it introduces a lot of "magic"
<linux__alien> LucidFox, what should i use ?
<linux__alien> any suggestions or advice?
<mok0> Look at the wiki: https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS
<ion_> I find quite easy to use CDBS, as long as i know which dh_* i need for what. But you need to know that when not using CDBS, too.
<linux__alien> mok0, is there any other alternative for cdbs
<linux__alien> ?
<mok0> linux__alien: basically, you control things using the *install etc. files
<linux__alien> in cdbs is it?
<DaveMorris> HighNo: no probs
<ScottK> CBDS works very well for some things.  I can do a python module package in an hour with it (and most of that time is spent on debian/copyright), but then somethig weird happens and you're stuck reading the source.
<LucidFox> linux__alien> there is also debhelper, which uses longer but more manually-tweakable rules files
<mok0> linux__alien: the alternative is using the straight Makefile with direct calls to the debhelper scripts
<linux__alien> so what do you advice . I am a newbie so kindly guide me
<linux__alien> to ubuntu packaging
<mok0> ScottK: Actually, I expanded the cdbs howto a while ago, and now it covers a lot more
<ScottK> mok0: That's great.  I may have to look at it then.  My standard CDBS approach is spend 5 minutes searching the official docs, fail to find what I want and then start grepping the source.
<mok0> linux__alien: I advice you to stick to your guns and use cdbs
<mok0> ScottK: Heh, that's what I did, and then I wrote it down
<ScottK> mok0: You might want to consider sending documentation patches upstream.
<linux__alien> moko ok sure thanks for it coz i just want to contribute to Ubuntu . So desparate :)
<sistpoty|work> doing packaging completely from scratch is a great learning experience (i.e. no dh_make, no cdbs, no debhelper, just plain make)
<mok0> ScottK: The problem with the official cdbs manual is not that it's lacking information, it's just badly organized.
<ScottK> mok0: My problems have been that it's lacking information.
<mok0> ScottK: Oh? Like what?
<LucidFox> sistpoty|work> I disagree, I think it's better to start with debhelper
<LucidFox> Not so long ago, I saw a package on REVU that used a low-level debian/rules without debhelper
<mok0> LucidFox: the advantage with that approach is that you are forced to learn the debhelper tools. Which sux.
<sistpoty|work> LucidFox: I guess if you want to make an actual package w.o. too much fuss, debhelper (or even cdbs) seems more suitable. nonetheless doing it completely w.o. is a great learning experience
<ScottK> mok0: The last I needed to figure out what how to add an extra configuration option to an autotools package (DEB_CONFIGURE_EXTRA_FLAGS).
 * mok0 looks
<linux__alien> for a hello world program i have the rules file which has this
<linux__alien> #!/usr/bin/make -f (-)
<linux__alien>                                 
<linux__alien> include /usr/share/cdbs/1/rules/debhelper.mk
<linux__alien> include /usr/share/cdbs/1/class/autotools.mk
<linux__alien> is that all i need for it to be packaged?
<ScottK> !pastebin | linux__alien
<ubotu> linux__alien: 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)
<mok0> ScottK: It's in there ;-)
<ScottK> OK.  Maybe you're right then.
<linux__alien> am sorry ScottK didnt see that
<mok0> ScottK: Like I said, it's poorly organized, which is why our wiki is needed. What people want to know is: "what do I do if..." and there should be some examples
<ScottK> Sounds good.
<HighNo> DaveMorris: I don't know what's going on there - even the newest examples show one has to "import bluetooth"
<linux__alien> mok0, The link you gave me sounds useful and its good too but the tutorial says that these 2 lines are whats needed . Is that all what we need ?
<mok0> linux__alien: depends on how your package is built. Does it use "configure; make; make install" ?
<ion_> linuxalien: Depends on your upstream source. If it uses autotools and does the right thing, thatâs probably most of the debian/rules youâll need.
<linux__alien> mok0, its that packaging guide example the hello example
<mok0> linux__alien: link?
<LucidFox> linux__alien> to my knowledge, the hello example doesn't use CDBS
<linux__alien> https://wiki.ubuntu.com/PackagingGuide/Complete
 * mok0 looks...
<LucidFox> so you probably selected the wrong package type in dh_make - it should have been "single binary" instead of "cdbs"
<linux__alien> LucidFox, ok but the control file didnt get generated when i chose that option and also want to know if i select single binary will the files still continue to get auto generated?
<norsetto> hi linux__alien
<linux__alien> hi norsetto
<linux__alien> how are you doin
<mok0> linux__alien: from what I can see it uses gnu autotools, which is perfect for cdbs
<mok0> linux__alien: then you only need to includes in your rules file:
<linux__alien> yes but curious to know if i had selected the single binary option will i still get the files auto generated ?
<doko> \sh_away: all packages in main should be buildable with 4.3
<DaveMorris> HighNo: where is the bluepromity python file stored?
<mok0> cdbs knows because control tells it how many packages to make.
<HighNo> DaveMorris: I even checked the examples in the docs. there must be an "import bluetooth" possible...
<HighNo> DaveMorris: /usr/share/blueproximity/proximity.py
<linux__alien> mok0, so i can use cdbs for most of the packaging right?
<mok0> Yep
<HighNo> DaveMorris: maybe we could find another package using python-bluez and check whether that one works
 * DaveMorris fixed it
<HighNo> DaveMorris: so what was it?
<mok0> linux__alien: If you just use a makefile with debhelper calls, the MOTUs are gonna crawl all over it like ants on a lollypop
<DaveMorris> how do I find out the current line in vim?
<linux__alien> mok0, why ? :)
<mok0> linux__alien: with cdbs, they leave it alone
<mok0> linux__alien: because there are so many ways to tweak it
<linux__alien> DaveMorris, Ctrl + G
<ScottK> \sh_away: And there's even a build with GCC 4.3 patch on sourceforge already, so I'll have a updated package for you to test shortly.
<mok0> linux__alien: the template you get from dh-make has a lot of cruft that you need to get rid of
 * linux__alien is confused :(
<DaveMorris> HighNo: comment out line 97, and remove the underscore in line 98
<linux__alien> i am sorry mok0 :(
<linux__alien> i ve got confused :(
<mok0> linux__alien: just stick to using cdbs for now
<sistpoty|work> mok0: heh, that's the worst argument I've heard in favor of cdbs so far *g*
<mok0> sistpoty|work: I've lots of bad arguments, which one do you mean :-)
<sistpoty|work> mok0: the one you wrote just now... that MOTUs will do less criticism to cdbs rules than to debhelper rules ;)
<mok0> sistpoty|work: heh. Strange but true.
<ion_> âDrink fluids regularly. Iâm doing it, too.â âThatâs the worst argument iâve heard in favor of drinking so far.â âOh, youâll stay alive, too.â
<mok0> sistpoty|work: I mean, it only has 2 lines...
<linux__alien> mok0, i get this error when i try to builld the source package
<linux__alien> /usr/bin/dpkg-buildpackage: 224: fakeroot: not found
<mok0> linux__alien: apt-get install fakeroot
<DaveMorris> HighNo: actually, that just makes it load, but not work :(
<mok0> sistpoty|work: the sad truth is the cdbs just calls _all_ of the debhelper scripts :-)
<mok0> sistpoty|work: ... it also includes the ones that MOTUs normally have you weed out
<mok0> Hehe
<DaveMorris> HighNo: you just need to remove the underscore on line 98
<DaveMorris> then it works
<jcfp> MOTUs, please take a look at http://revu.tauware.de/details.py?package=sabnzbdplus (time constraints, weather, and blood alcohol level permitting)
<linux__alien> mok0, now i get a different error
<linux__alien> debian/rules:3: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory
<linux__alien> debian/rules:4: /usr/share/cdbs/1/class/autotools.mk: No such file or directory
<sistpoty|work> mok0: yes, heh
<mok0> linux__alien: apt-get install cdbs
<ion_> Install cdbs (and add it as a build dep).
<HighNo> DaveMorris: I know, that's because both lines are there...
<HighNo> DaveMorris: but that shows the problem is import _bluetooth
<linux__alien> mok0, how do i know that my build is complete
<mok0> linux__alien: if it creates a .deb file?
<linux__alien> where would that be?
<linux__alien> placecd
<linux__alien> placed
<DaveMorris> well I can now start it and connectr to my phone
<ion_> In ..
<mok0> ... normally the parent of the directory that has debian/
<linux__alien> dpkg-source: building hello in hello_2.1.1.dsc
<linux__alien> dpkg-source: unrepresentable changes to source
<linux__alien> i get this
<DaveMorris> although I get an error when trying to scan for a channel
<mok0> It means that you have generated a binary or something that is not being removed by the script
<ScottK> Lutin or Adri2000: I have a DaD feature request when you have a moment.
<HighNo> DaveMorris: correct, that's one place where it is used
<DaveMorris> but I can scan for the device
<HighNo> DaveMorris: the other one is when actually connecting to the phone
<Adri2000> ScottK: yes? (likely to become a MoM feature request though)
<ScottK> Adri2000: No problem.
<mok0> linux__alien: ... is not being removed by upstreams Makefile is more accurate...
<HighNo> DaveMorris: try to set it to your phone's mac and close the dialogue. it should go into connection mode
<ScottK> Adri2000: I just had to split Debian's amavisd-new package into two to get part of it in Main.
<ScottK> Adri2000: So it would be great if MoM/DaD (whichever) would look to amavisd-new in Main as the merge source for both amavisd-new and amavisd-new-milter source packages in Ubuntu.
<HighNo> DaveMorris: hover the mouse over the tray icon and it should show connected and a value
<DaveMorris> HighNo: http://pastebin.com/f2929c662
<DaveMorris> when running it can't establish a connection (they are inches apart) but no error messages
<sistpoty|work> Adri2000: that sounds like there are news in MoM/DaD merging process?
<Adri2000> ScottK: amavisd-new is one source package in debian, and is splitted in ubuntu between amavisd-new (main) and amavisd-new-milter (universe). right? could you file a bug in LP please?
<linux__alien> mok0, i am upset that i am not able to understand this part :(
<mok0> linux__alien: explain
<linux__alien> why is this error coming
<Adri2000> sistpoty|work: yes. MoM source released. we are starting to work on patching MoM with DaD features
<linux__alien> it didnt show me any sort of compilation error
<ScottK> Adri2000: That's right.
<sistpoty|work> Adri2000: cool, great :)
<ScottK> Adri2000: Where to file the bug?
<mok0> linux__alien: is it still the unrepresentable ... etc?
<linux__alien> yes\
<linux__alien> whats that i ve to do to correct this
<mok0> linux__alien: I'll give it one line at a time
<mok0> linux__alien: dpkg-source wants to make a diff between the current dir and the tar file
<linux__alien> you want me to paste it ?
<linux__alien> ok..
<mok0> linux__alien: no, just say "yes" ;-)
<Adri2000> ScottK: merge-o-matic
<linux__alien> yes...
<ScottK> Adri2000: Thanks.
<mok0> linux__alien: It has found some files in the current tree that are not in the .orig.tar.gz
<sistpoty|work> linux__alien: dpkg-source basically builds a unified diff between the orig-tarball and the extracted directory. This is what will become the .diff.gz. This means that anything that cannot be represented in a unified diff (e.g. no-text stuff, or permission changes of files) won't go into the .diff.gz
<mok0> sistpoty|work: yeah but the build fails
<HighNo> DaveMorris: I know that problem (pastebin) but it should also not be able to connect.
<linux__alien> i ve an other tar file as a backup called hello_orig.tar.gz
<linux__alien> but thats outside the directory
<linux__alien> will it harm it ?
<mok0> linux__alien: the ONLY difference between the upstream tarball and your directory should be the debian/ dir
<sistpoty|work> mok0: why?
<linux__alien> ok here it is
<HighNo> DaveMorris: funky, i found another example from the package itself and it also uses "import _bluetooth"
<mok0> sistpoty|work: why it fails?
<linux__alien> this is what i ve
<linux__alien> hello-2.1.1          hello_2.1.1.dsc          hello-2.1.1.tar.gz
<linux__alien> hello_2.1.1.diff.gz  hello_2.1.1.orig.tar.gz
<linux__alien> the first one is a directory
<sistpoty|work> mok0: yep
<linux__alien> the next file is generated i believe
<DaveMorris> any more quick testing you want?
<HighNo> DaveMorris: could you try running this one: /usr/share/doc/python-bluez/examples/l2-unreliable-client.py
<mok0> linux__alien:  lsdiff -z hello_2.1.1.diff.gz
<DaveMorris> I suggest you grab a hardy livecd and test it though,
<HighNo> DaveMorris: that's a good idea. Will download it tonight.
<ScottK> Adri2000: Bug #190244
<ubotu> Launchpad bug 190244 in merge-o-matic "Please use amavisd-new as merge source for both amavisd-new and amavisd-new-milter in Ubuntu" [Undecided,New] https://launchpad.net/bugs/190244
<mok0> sistpoty|work: when you run a debuild, it fails on "unrepresentable... " etc.
<joejaxx> is there anything special you have to do when packaging a python application?
<linux__alien> shall i paste the list in pastebin?
<mok0> sistpoty|work: maybe my memory is failing me
<Adri2000> ScottK: thanks
<linux__alien> shall i paste the list in pastebin?
<mok0> linux__alien: yes
<DaveMorris> HighNo: fails, with no module named _bluetooth
<sistpoty|work> mok0: I'm used to that error (for me it means: Close the vi on the file you've just patched! *g*)
<linux__alien> http://pastebin.com/m4bf6d670
<joejaxx> or  anyone have a link to the ubuntu policy on packaging python apps?
<ScottK> joejaxx: It's the same as the Debian policy
<sistpoty|work> joejaxx: iirc the debian-policy package contains the python policy as well
<mok0> linux__alien: looks great. It has only files in debian/* , you see?
<linux__alien> yes
<linux__alien> so what does that mean
<HighNo> DaveMorris: download started. Thanks for your efforts anyway. I hope to have a solution for you tomorrow. It is a nice tool :-)
<linux__alien> the other things are perfect
<linux__alien> ie there are no other extra files in the other directories right?
<linux__alien> thats what it means right?
<joejaxx> which is better? python-support? or python-central?
 * DaveMorris makes sure he takes the usb bluetooth stick home
<mok0> linux__alien: it is a diff that can add the debian directory to upstreams tarball
<linux__alien> ok now whats the  next step
 * DaveMorris would hook the tool up to the bosses phone so you know when they are coming :)
<linux__alien> how will i get the deb file ? :) just want to have one packaging done before i go to bed and tomorrow will try few more :)
<mok0> linux__alien: you must try to generate a binary .deb file.
<HighNo> DaveMorris: where are you located?
<mok0> linux__alien: go into the top directory and do "debuild"
 * sistpoty|work heads home now
<DaveMorris> UK
<HighNo> DaveMorris: hehe, that's probably the most geekish use I could think of :-)
<sistpoty|work> later folks
<linux__alien> ok will do that . That would give me the binary package is it?
<mok0> sistpoty|work: see you
<mok0> linux__alien: it should
<linux__alien> http://pastebin.com/m4bf6d670
<linux__alien> debuild: fatal error at line 1247:
<linux__alien> dpkg-source -b hello-2.1.1 failed
<mok0> linux__alien: can you pastebin that output?
<linux__alien> sure
<mok0> linux__alien: (I have to go soon)
<linux__alien> one sec
<linux__alien> http://pastebin.com/mad6fcb8
<ion_> .rules.swp probably comes from vim.
<ion_> :%bd and then try to build the source package.
<mok0> linux__alien: You have a strange file called debian/.rules.swp What is that?
<linux__alien> ok deleted that possibly because of vim
<linux__alien> i believe
<mok0> linux__alien: get rid of it and try again
<linux__alien> now it moves one sec
<ion_> You donât need to delete it (unless vim has crashed), just remove the equivalent buffer.
<ion_> Vim takes care of removing the swap file.
<linux__alien> debsign: gpg error occurred!  Aborting....
<linux__alien> debuild: fatal error at line 1174:
<linux__alien> running debsign failed
<mok0> Hrmmph
<mok0> linux__alien: debuild -us -uc
<ion_> You probably got a package, you just didnât sign it.
<linux__alien> oh ok i ll learn that a little later
<linux__alien> hello_2.1.1_i386.deb
<linux__alien> fine ?
<ion_> less the file, make sure its contents are ok.
<mok0> looks like it. Now use dpkg -c hello_2.1.1_i386.deb
<linux__alien> it shows lot of files
<ion_> (If less doesnât give nice output, you havenât enabled lesspipe.)
<linux__alien> it shows something like this
<mok0> ion_: Hey! that's a cool trick I didn't know
<linux__alien> drwxr-xr-x root/root         0 2008-02-08 23:18 ./usr/share/locale/fr/LC_MESSAGES/
<linux__alien> -rw-r--r-- root/root      3883 2008-02-08 23:18 ./usr/share/locale/fr/LC_MESSAGES/hello.mo
<linux__alien> something like this
<mok0> linux__alien: yeah, you got your package.
<linux__alien> oh Thanks got it finally . Thanks a lot
<mok0> linux__alien: now you can install it using dpkg -i (as root)
<linux__alien> I am really sorry i guess i ve troubled you
<mok0> linux__alien: You're going to help someone else another time. That's the price :-)
<linux__alien> yes sure
<ion_> Or gdebi foo.deb, or dpkg --unpack foo.deb and apt-get -f install to handle dependencies (not necessary in this case).
<linux__alien> i am ready for it and want to help others and want to be part of the Ubuntu team :)
<mok0> Well gotta go, see you later
<linux__alien> its got installed
<mok0> linux__alien: :-)
<linux__alien> cya mok0
<linux__alien> ya executed it also it says hello world :)
<linux__alien> got to go now
<linux__alien> cya thanks for your help cya tomorrow have a nice dya
<linux__alien> have a nice day
<linux__alien> cya ion_
<vemon> revu? http://revu.tauware.de/details.py?package=lashwrap
<vemon> or: http://revu.tauware.de/details.py?package=ghostess
<vemon> good audio production related stuff to add to hardy
<mruiz> hi all
<jeromeg> jdong: hello, I'm testing some backports, what do you thnik of bug 189708 ?
<ubotu> Launchpad bug 189708 in gutsy-backports "Please backport tcl/tk 8.5" [Undecided,New] https://launchpad.net/bugs/189708
<jeromeg> it has a huge number of rdepends
<jeromeg> it builds fine, and upgrade doesn't seem to make other programs unusable
<jdong> jeromeg: it seems like tcl8.5 is a separate source package and doesn't conflict namespace with existing 8.4
<jdong> jeromeg: but I'm not 100% confident of that, it'd be better if you can find another developer to say what I just said :)
<jdong> at that point, I would be happy to approve
<jeromeg> jdong: ok
<kdu1> while trying to make my first debian package using dh_make/debuild, its complaining that I don't have a secret gpg key, despite the fact that I do....
<kdu1> its saying something about signing it under the name "Kevin" when my key is under my full name, how do i fix that?
<sistpoty> kdu1: not exactly sure, but imo setting the environment var DEBEMAIL to your email address should fix it
<kdu1> sistpoty: that didnt work...
<sistpoty> kdu1: you could also try to set DEBSIGN_KEYID to your key id
<sistpoty> (and make sure to export these variables, so that a subshell will see them)
<jeromeg> jdong: bug 190055 seems fine to me, it already has three testers
<ubotu> Launchpad bug 190055 in gutsy-backports "Please backport audacity 1.3.4 from Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/190055
<jeromeg> got to go
<jeromeg> bye
<kdu1> anyone have any ideas about my signing problem with debuild?
<ScottK> kdu1: Pass the key id to be used using the -k option.
<jdong> ScottK: isn't the only time debuild can't auto-detect when the e-mail in the changelog doesn't correspond with any e-mails in the private keyring?
<jdong> i.e. passing in -k is just a workaround?
<jdong> (of course for sponsoring this is normal/expected)
<ScottK> It's not just the email.  It's also the name.
<jdong> ScottK: ah, ok, didn't think of that
<jdong> ScottK: but still... wouldn't it be good practice for those to match?
<mruiz> is interdiff a patch ?
<ScottK> jdong: Yes, but for the name, I don't think it's essential.
<jdong> mruiz: a special form. see InterDiff on the wiki
<jdong> ScottK: reluctantly agree :)
<ScottK> \sh_away: Please let me know when you're around for another gcc 4.3 test build.
<mruiz> jdong, I prepared one and I was thinking about the "patch" checkbox on LP gui
<jdong> mruiz: I think that'd be appropriate
<DaveMorris> HighNo: got a working package for me to test yet :)
<mruiz> bye all
<HighNo> oh, hi DaveMorris
<HighNo> DaveMorris:  sorry, not yet - had to bring my kids to bed and wife too, now I get back to work...
<DaveMorris> where are you based then?
<sistpoty> cedricv: you want to join the uncommon-proglang team?
<cedricv> hi sistpoty!  yeah, i'd like to update the boo package to the newly released 0.8.1 version
<sistpoty> hi cedricv ;)
<sistpoty> *trying to remember who knows about boo*
<HighNo> DaveMorris: Germany
<sistpoty> cedricv: iirc slomo should know the boo package, maybe you could talk to him about it?
<sistpoty> slomo: ^^ ;)
<cedricv> i hope it is not too late to submit at revu for being included in hardy? :)   we still receive reports for the 1-year old version available in the repos
<sistpoty> cedricv: well... it's almost too late for it, as FeatureFreeze is approaching soon :/
<cedricv> even if i (or slomo? ;) ) submit for review tonight or tomorrow ?
<sistpoty> cedricv: I won't make promises for that... but there is still a chance ;)
<sistpoty> cedricv: of course slomo can upload till FF w.o. problems *g*
<HighNo> DaveMorris: I'm booting hardy live cd in vmware right now. This should not take too long now...
<sistpoty> cedricv: oh, there's a newer debian version (0.8.0.2730)... is that up to date enough? maybe it could then just get synced
<cedricv> oh it would already be a nice improvement :)    i'm currently trying to build source package for 0.8.1.2865      (binary deb packages available on the website)
<cedricv> 0.8.0.2730 is the version on debian unstable repo?
<sistpoty> cedricv: yes
<Coper> Can some MOTU review console-freecell?
<sistpoty> Coper: I'll give a quick look
<Coper> sistpoty: thanks
<kdub> i'm still having that signing problem, and its driving me up a wall
<sistpoty> Coper: you don't have any patches, so I guess simple-patchsys.mk is not needed (not a blocker though)
<sistpoty> Coper: oh, forget it, didn't saw the manpage patch when looking at the .diff.gz
<sistpoty> Coper: debian/copyright: I'd put the link to GPL (as you write in there, that it is GPL-2 or above)... but that's a matter of taste
<sistpoty> Coper: I'd also install the upstream changelog into the package (seems to be a cdbs bug FWIW)
<sistpoty> Coper: others than that, looks fine
<ScottK> \sh_away: http://revu.tauware.de/revu1-incoming/klamav-0802082120/klamav_0.42-1.dsc (or anyone else who's set up to do gcc 4.3 test builds).
<HighNo> DaveMorris: please change line 98 from "import _bluetooth as bluez" to "import bluetooth._bluetooth as bluez" and try again. start it from the commandline via "blueproximity" to check console output.
<sistpoty> Coper: advocated, since all these points are no major blockers
<DaveMorris> HighNo: that seems to be working now, I can connect to the phone etc
<HighNo> DaveMorris: cool - even though they should have updated their own examples...
<DaveMorris> only prob is it doesn't seem to have detected my phone on the other side of the flat
<HighNo> DaveMorris: I will try to find a way to support both variants in one source and build a new package....
<HighNo> DaveMorris: Other side of the flat? How many meters and walls is that?
<DaveMorris> why do you need both variants
<DaveMorris> 5M, I'm gonna chuck it outside in a mo?
<DaveMorris> working now
<HighNo> DaveMorris: because I'm also upstream author so I want to keep the supported stuff as big as possible. The same stuff is included in to orig.tar.gz and should run if it's just unpacked, which I know now will not work with hardy.
<DaveMorris> ahh, for now I suggest using a patch for hardy so it can get in before FF
<HighNo> DaveMorris: hm, how would I do that?
<nxvl_work> i'm having a weird problem with gedit
<nxvl_work> i'm editing the version needed of 2 packages on the debian/control file
<DaveMorris> what packaging system are you using?
<nxvl_work> but when i build it (using dpkg-builpackage or debuild) they undo the changes i have made
<nxvl_work> so the change is not shown on the debdiff
<sistpoty> ScottK: can you archive klamav? that way links are still the same, but it won't show up in the review page
<HighNo> DaveMorris: I'm not quite sure what you mean, but would cdbs be a legitimate answer?
<DaveMorris> yeah
<DaveMorris> cdbs patches are easy
<DaveMorris> make a cp of your pkg dir incase you make a mistake
<HighNo> DaveMorris: I guess that's why everybody loves it?!
 * sistpoty doesn't *g*
 * jpatrick does
<ScottK> sistpoty: Sure
 * HighNo starts a flame war?
<DaveMorris> then in the package base, use the command cdbs-edit-patch <patch-name>.patch
<sistpoty> HighNo: the only answer is vim *g*
<DaveMorris> then make the changes required to the file, and exit using ctrl + D
<albert23> nxvl_work: maybe there is a debian/control.in file
<HighNo> DaveMorris: is the patchname to obey a naming policy?
<DaveMorris> the patch is created in debian/patches
<nxvl_work> albert23: oh i haven't notice it, thanks :D
<DaveMorris> I tend to number them, and have a short description of the change
<albert23> nxvl_work: that caught me a few times as well :-)
<DaveMorris> maybe 01-patch-bluetooth-module-for-hardy.patch
 * nxvl_work HUGS albert23
<HighNo> DaveMorris: thx, i'll try
 * albert23 hugs nxvl_work back
<slangasek> cdbs patches are easy because cdbs's simple-patchsys is only used by people who have easy patches; it scales like a bivalve climbs a mountain :-P
<sistpoty> heh
<ScottK> slangasek: Are you a quilt fanboy?
<ScottK> I've got a question about it I've been looking for someone to answer
 * sistpoty prefers a VCS, but debian(ubuntu) games only allow changes inside debian/
<slangasek> ScottK: you could say that
<DaveMorris> HighNo: I'll have to grab a backport for gutsy and use this at work, save me locking my session as I walk away
<ScottK> slangasek: OK.  One workflow I use somewhat frequently is to figure out a fix, make a diff, then fire up dpatch-edit-patch or cdbs-edit-patch (as appropriate), throw the diff into the chroot, exit, and bang I have my patch.  Is there a near equivalent for quilt?
<slangasek> ScottK: so you've prepared your patch already, external to the package, and just want to suck it into quilt?
<ScottK> I guess that's one way to look at it.  *-edit-patch is like a qa buffer to make sure I get something that will apply when I build the package.
<slangasek> oh.  well, to just import the patch, you can use quilt push -a && quilt import -P <name-to-use-in-quilt> <existing-patch>
<slangasek> then quilt push again to make sure it really applies
<slangasek> all this assumes you have QUILT_PATCHES=debian/patches (or wherever it needs to point) set correctly in your environment
<ScottK> Ah.  That's sounds like it.  Right.
<ScottK> I've only used quilt a few times.  I think I would like it if I used it more so it was more natural, but that was the one bit I was missing.  Thanks.
<slangasek> 'quilt fold' seems to be an option that would let you pull a patch on stdin into the current patch and apply it, but I've never used that option and can't vouch for its sanity
<slangasek> (that then would be quilt push -a && quilt new <name> && quilt fold < <existing-patch>)
<ScottK> slangasek: Thanks.  I've copied that into one of my notes files and I'll fiddle with it next time I hit a quilt package.
<slangasek> ok, enjoy :)
<HighNo> DaveMorris: grrr, had my changes made, saved, then typed 'exit' -> no patch created. does exit exit with an errorlevel != 0?
<DaveMorris> I guess so
<DaveMorris> you can make your changes external, and copy them into the `cleaned environment'
<slangasek> no, 'exit' alone exits 0
 * HighNo is ashamed because he can't read properly
<HighNo> the patch was there already
<HighNo> ok, should I just repackage it and the patch is applied automatically
<HighNo> ?
<DaveMorris> you need to include a line in your rules file
<DaveMorris> include /usr/share/cdbs/1/rules/simple-patchsys.mk
<HighNo> DaveMorris: ok, dh_applypatch or something like that?
<HighNo> ah, ok
<HighNo> hm, now how do I repackage it in a way that won't slow down the approval process?
<DaveMorris> just do it as normal and I'll check it over
<HighNo> ok
<HighNo> DaveMorris: the new package just made it into REVU - now for the 10 minute cool down phase... :-)
<sistpoty> HighNo: your package is not kde4-style-bespin, is it?
<HighNo> sistpoty: no, it is 'blueproximity'
<sistpoty> HighNo: ah, k... should be up on revu already (at least it's not in the queue)
<HighNo> but I just got a message from 'bounces@canonical' telling me my package has been rejected - where does that come from?
<jpatrick> HighNo: you probably uploaded to ubuntu...
<sistpoty> HighNo: you uploaded to the archive instead of to revu, I guess (dput revu changesfiles=
<ScottK> HighNo: That means you tried to upload to ubuntu
<HighNo> http://pastebin.com/d5dec2538
<HighNo> doh
<ScottK> HighNo: It's harmless, but to try to avoid it.
<HighNo> I forgot to change the dput default destination
<sistpoty> anyone knows, to whom the key 3AA736D6 belongs? (can't find it on the ubuntu keyserver)
<HighNo> ScottK: sistpoty: DaveMorris: OK, now the package went to REVU :-)
<ScottK> We've all done that at least once I think.
<HighNo> I consider that to be training for my later MOTU being :-)
<ScottK> sistpoty: It's not on the MIT keyserver either.
<DaveMorris> it's when you have permission to upload to there and do it
<sistpoty> ScottK: hm... then I'll just nuke the upload (binary upload with that key)
<ScottK> Sounds reasonable to me.
<jpatrick> sistpoty: smarter
<jpatrick> (says google)
<sistpoty> jpatrick: thanks
<sistpoty> smarter: please upload only source packages to revu, not binary ones
<smarter> sistpoty: sorry, I probably pressed tab 2 times instead of one ;)
<sistpoty> smarter: no problem, just that you know that your upload won't make it ;)
<sistpoty> HighNo: should be up on revu (out of order run of move_uploads ;))
<HighNo> sistpoty: ??? ahhh, got it. It is so cool to have a package without a trailing zero at the timestamp :-)
<sistpoty> heh, /me always wanted to find out how to manually trigger the upload processing (strange enough I wrote the script once, and even added the cronjob, but I didn't recall that w.o. looking)
<geser> sistpoty: http://pgpkeys.pca.dfn.de/pks/lookup?search=0x3AA736D6&op=vindex
<Coper> Anymore MOTU that can review my package console-freecell
<sistpoty> thanks geser: already clear :)
<sistpoty> +ed
<ScottK> Coper: Did it get advocated?
<Coper> ScottK: I got one. :)
 * ScottK will look at console-freecel.
<Coper> sistpoty: I change the link to GPL-2 becurse a comment in the review.
<sistpoty> Coper: neither GPL-2 nor linking to GPL is wrong from a copyright POV (it falls under *GPL-2* but can also distributed under any later version)
<warp10> My package gbemol (a graphical frontend for MPD) http://revu.ubuntuwire.com/details.py?package=gbemol is on REVU waiting for reviews.
<sistpoty> Coper: so as I wrote, it's really a personal preference
<sistpoty> Coper: in other words: if the sources is *only* GPL-2 then you'll need to put the link to that file, but not the other way round ;)
<DaveMorris> HighNo: commented
<ScottK> Coper: Congratulations.  Uploaded.  Thank you for your contribution to Ubuntu.
<KenSentMe> I have an inconcistancy for installed webcam apps. Cheese goes in the Accessories menu, xawtv in Sound and Video and Camorama in graphics. What is the best place to report this so a unified menu folder is used?
<ScottK> KenSentMe: File one bug and use 'also affects' to mark the bug against all of them.
<KenSentMe> ScottK, ok, will do
<Coper> ScottK: Wohoo time for celebrating.. :)
<sistpoty> congrats, Coper!
<Coper> What do you mean by install upstream changelog?
<ScottK> Coper: The file Changelog isn't in the binary package.  It should be.
<Coper> okey, so it should be added to /usr/share/doc/<package>/changelog?
<ScottK> Yes
<ScottK> Coper: I don't feel you need to worry about another upload for that just now.  Just keep it in mind for when you next need to touch the package.
<sistpoty> meh... /me hates incomplete debian/copyright notes (even if these would not harm redistribution, due to missing only BSD stuff)
<ScottK> sistpoty: It'd still get rejected by an archive admin.
<ScottK> All the licenses listed is a must.
<sistpoty> ScottK: sure, because nvidia-settings (source) will end up in new *g*
<ScottK> Ah
<sistpoty> and its debian/copyright (unstable version) is far from exhaustive *g*
<geser> HighNo: blueproximity commented
<DaveMorris> HighNo: suggestion for your program, have a checkbox so you can make it easily launched on startup
<HighNo> thx, I'll look into it
 * DaveMorris has now learnt you can use the desktop-valadiate tool
<HighNo> DaveMorris: the only line that is beyond 80 chars is the depends line - how can add line breaks there?
<DaveMorris> I'm sure I've done it in my opensg package, let me check
<geser> HighNo: it's RFC822 format
<geser> indent with spaces
<DaveMorris> yeah, what geser said :)
<sistpoty> heh, even nowadays 80 lines is s.th. I very much want to have in source files, because I then can do a vsplit on every file with my resolution *g*
<smarter> Is requestsync borken in hardy?
<HighNo> ok, i didn't find good information on the doc-base stuff regarding html and png files. Can I add two entries, one for html and the other one for png?
<smarter> "socket.error: (113, 'No route to host')"
<DaveMorris> Can someone please revu this package so we can close some bugs which have been open since feisty http://revu.tauware.de/details.py?package=gtkglextmm
<sistpoty> DaveMorris: is this already present in the archive? if so, is it a new upstream version?
<DaveMorris> well, it's in Edgy, but nothing since
<DaveMorris> but it's a new version compared to the one there
<sistpoty> ok, I'll take a look in a few minutes
<DaveMorris> cheers
<Coper> I was reading on a page about sending a new package to ubunut and after I got 2 MOTU to review the package I should change status in LP. anyone know what page that was?
<HighNo> hm, what does lintian try to tell me with wrong-name-for-upstream-changelog?
<geser> smarter: shouldn't be
<HighNo> Coper: sounds like the Ubuntu wiki packaging howto entry
<DaveMorris> I think because you have it all in caps
<ScottK> Coper: Your (LP: #nnn) entry will close the bug.
<DaveMorris> prob should of been Changelog
<smarter> geser: how does it know my smtp server?
<smarter> geser: I tried with --lp too and I got: "launchpadbugs.bughelper_error.LPUrlError: 'An internal server error occurred. Please try again later. (url: https://bugs.launchpad.net/ubuntu/+source/plptools/+filebug-advanced)'"
<Coper> ScottK: okey, so I don't have to change anything?
<geser> either you set DEBSTMP or it uses the default (fiordland.ubuntu.com)
<ScottK> Coper: Shouldn't.
<HighNo> DaveMorris:  hm, should I change the name in upstream itself or does a patch fix that?
<HighNo> DaveMorris: (I would change that in upstream for future versions anyway)
<DaveMorris> well since you are upstream, might be easier to do it
<geser> smarter: I've no sync request right now to test it myself
<smarter> geser: I use -s to request sponsorship
<HighNo> DaveMorris: Funny, I thought about fixing the other bug in upstream too - until you suggested using a patch for it to keep the timeline :-)
<DaveMorris> well I thought you'd wanna use the same original source for the different versions of Ubuntu
<HighNo> Does RFC822 need an additional single dot line or is the end of indention enough?
<HighNo> DaveMorris: yes, but my changes are made in a way that would work with both variants :-)
<DaveMorris> ahh, I didn't relaise
<HighNo> DaveMorris: actually tries to import both but counts the number of successes. if less then 1-> error
<geser> HighNo: end of indention is enough (like in email headers)
<sistpoty> DaveMorris: gtkglextmm was dropped from debian, why should we restore it?
<crimsun> in short, new version.  maintained.
<sistpoty> crimsun: what needs it?
<DaveMorris> was dropped due to FTBFS in rc and the mainator was MIA.  The are multiple requests for it's reinclusion and this version is working
<crimsun> sistpoty: apparently something (s)he's using.
<DaveMorris> bug #104804
<ubotu> Launchpad bug 104804 in gtkglextmm "gtkglextmm-1.2.0 is missing in feisty" [Wishlist,In progress] https://launchpad.net/bugs/104804
<sistpoty> DaveMorris: seen that one... but there is no rationale why we should ship it again
<geser> smarter: requestsync --lp -s works for me without problems
<DaveMorris> sistpoty: but whats the rationale for not shipping it?
<smarter> geser: strange...
<sistpoty> DaveMorris: oh, looked at a different bug... *looking*
<sistpoty> DaveMorris: ok, enough rationale in this bug report... looking at the candidate
<smarter> geser: are you running hardy?
<DaveMorris> note I'm not closing that bug, since thats for it to be in Feisty, which would be done with a backport
<geser> smarter: yes
 * DaveMorris is finding Hardy very very good on his laptop
<DaveMorris> I might upgrade my work desktop soon
<ScottK> DaveMorris: You should close that bug as we mark bugs fix released when fixed in the developmental release.  Then we open tasks against earlier releases if appropriate.  In this case, after it's fix released, I'd use also affects project to add feisty-backports and gutsy-backports to the bug.
<DaveMorris> ScottK: I opened a new bug for it, just seemed wrong to close that bug when it gets into Hardy
<HighNo> Hm, can anyone tell me why I have a 'files' file in debian dir - and what it dows there since it has only nonsense content
<ScottK> DaveMorris: What I'm describing to you is standard Ubuntu bug policy.  I understand what you are saying, but that's not Ubuntu policy.
<DaveMorris> I'll try and remember that for future (even though I don't fully understand it atm - I should think about it for a bit)
<sistpoty> DaveMorris: did you do an ABI check on the library?
<DaveMorris> no, how do you do that?
<DaveMorris> also what does ABI stand for in this context?
<sistpoty> DaveMorris: since there is a feisty version with the same SONAME, you must ensure that the ABI didn't change
<geser> ABI: Application Binary Interface
<sistpoty> DaveMorris: https://wiki.ubuntu.com/MOTU/School/LibraryPackaging should give you clues on ABI and how to check it
<azeem> didn't change in an incompatible way, anyway
<DaveMorris> azeem: you've already checked it then?
<sistpoty> azeem: can you guarantee? (if so, I won't do an abi check myself for reviewing *g*)
<azeem> no, I just said that you should check for incompatible ABI changes, not any kind of ABI changes
<sistpoty> heh
<sistpoty> DaveMorris: you debian/rules seems strange (from looking at the diff so far): you seem to call configure outside of any rule?
<sistpoty> heh, no... confused by .diff.gz *g*
<DaveMorris> tbh I just took the packaging from the Edgy version,\changed the bits requiring it
<DaveMorris> seemed the path of least resistance at the time
<sistpoty> sure, makes sense
<DaveMorris> the ABi stuff makes sense, and I'll run through the examples since I've only packaged libs so far :)
<sistpoty> :)
<DaveMorris> and I'll have to remember it for the libs we build at work
<HighNo> hm, in a desktop file, Categories: Application;Utility <- Application is deprecated? What should I use in exchange?
<sistpoty> !desktop file
<ubotu> Sorry, I don't know anything about desktop file - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<sistpoty> grml
<vemon> i'm attaching a patch to an ubuntu package to launchpad bug. i know that when adding new upstream versions i upload the .diff.gz resulting from "debuild -S -sa" but is it the same when the upstream version stays the same but i've just added a patch?
<sistpoty> HighNo: see http://standards.freedesktop.org/desktop-entry-spec/latest/
<HighNo> sistpoty: thx
<RAOF> vemon: In that case, you just want to add a debdiff
<vemon> ok
<RAOF> vemon: As generated by "debdiff <oldpackage> <newpackage>"
<vemon> and the package in your example is a .dsc file?
<RAOF> debdiff accepts quite a number of ways to specify <package>, but I generally use the .dsc, yes.
<vemon> thanks!
<sistpoty> DaveMorris: the good news so far: your version changes the SONAME (so we don't need to care about ABI incompatibilities)
<sistpoty> DaveMorris: the bad news: you need to adjust the (binary) package name of the library package
<DaveMorris> to what?
<geser> DaveMorris: increase the SONAME in the package name so it matches the library
<DaveMorris> sorry, I meant, what has the SONAME changed to?
<geser> DaveMorris: check in the library
<sistpoty> objdump -p <shared object> | grep SONAME
<DaveMorris> yeah, I've used that before to track down missing symbols
<DaveMorris> so you suggest changing the package name so it doesn't seem to have any relation to the source package name.  Source package name is gtkglextmm and soname is libgtkglext-x11
<slangasek> DaveMorris: there's no number in the soname field?
<DaveMorris> yeah, a -1.0
<sistpoty> DaveMorris: no, -x11 is not in either SONAME
<slangasek> that's the principal problem
<sistpoty> and actually, there are *two* shared objects in the library package
<DaveMorris>   SONAME      libgdkglext-x11-1.0.so.0
<sistpoty> DaveMorris: oh, right
<slangasek> if that were the only lib in the package, the customary package name would be libgdkglext-x11-1.0-0
<vemon> just uploaded a patch which adds LASH support for ZynAddSubFX: https://bugs.launchpad.net/ubuntu/+source/zynaddsubfx/+bug/180967. Any motu's care to take a look at it? :)
<ubotu> Launchpad bug 180967 in zynaddsubfx "ZynAddSubFX has no LASH support" [Undecided,Confirmed]
<DaveMorris> there is that and libgtkglext-x11-1.0.so.0
<vemon> already subscribed to the sponsors queue
<slangasek> the most important thing isn't to make the package name match the soname, though; it's to make sure that there's a 1:1 mapping between library ABIs (=SONAMEs) and package names
<slangasek> so when the soname changes, the package name should also change
<DaveMorris> ok, will people be able to find these though when they search for `gtklextmm' ?
<slangasek> if that's a string that people are likely to be searching for, perhaps you can put it in the package description?
<DaveMorris> ok I'll sort that out now
<slangasek> DaveMorris: so I'm confused about something. if this is "gtkglextmm", why are the sonames the same as for "gtkglext"?
<DaveMorris> gtkglext is the C bindings, these are c++ bindings
<slangasek> yes, so why do they have the same soname?
<DaveMorris> one has the mm in there the other doesn't
<slangasek> oh? the soname you cited didn't mention 'mm'
<DaveMorris> the c++ ones are libgtkglextmm-x11-1.0.so.0 and the C ones are libgtkglext-x11-1.0.so.0
<slangasek> ok, so libgtkglextmm-x11-1.0-0 is the most appropriate name for the C++ bindings
<slangasek> in which case, a search for 'gtkglextmm' will definitely match
<DaveMorris> hmm, just checked the Edgy package, and that had sonames the same (different version though) both in the same package name as what I have here
<slangasek> what package name is that?
<sistpoty> hm... the new sonames are actually libgdkglextmm-x11-1.0.so.0 and libgtkglextmm-x11-1.0.so.0
<DaveMorris> also the C bindings both seem to be in the package libgtkglext1 and libgtkglext1-dev
 * DaveMorris is confused
<slangasek> ok, since that's the soname that was used for a previous version of the package in the archive, it's best to restore that same soname
<slangasek> sorry, s/soname/package name/
<sistpoty> DaveMorris: sorry, /me was confused, wrong shell
<geser> DaveMorris: the -dev package is only needed during build, so it's ok (unless there is a packaging error)
<sistpoty> the new ones are libgdkglextmm-x11-1.2.so.0 and libgtkglextmm-x11-1.2.so.0
<DaveMorris> currently the package libgtkglext1 on gutsy (C bindings) contains libgtkglext-x11-1.0.so.0 and libgdkglext-x11-1.0.so.0
#ubuntu-motu 2008-02-09
<slangasek> which is a poorly-named package; if it were being done from scratch, it should be libgtkglext-1.0-0 or libgtkglext-x11-1.0-0, according to taste
<DaveMorris> so surely the c++ bindings should be similar
<sistpoty> DaveMorris: now you've completely confused me, as I can't find a gutsy package (only an edgy one)#
<slangasek> sistpoty: he's referring to gtkglext, not gtkglextmm
<HighNo> thanks to DaveMorris and the other reviewer there is a new version at revu: http://revu.tauware.de/details.py?package=blueproximity - Reviewers wanted :-)
<sistpoty> ah, ok
<DaveMorris> slangasek: yeah, the C package should also be sorted out at the same time IMO (and poss the other bindings available )
<slangasek> DaveMorris: it shouldn't; once a library runtime package name has been chosen, even if it's poorly chosen, changing it is worse than leaving it alone
<DaveMorris> then shouldn't we stick with the name that was in dapper/edgy ?
<slangasek> DaveMorris: but if the soname changes (are you packaging a new version of gtkglext with a new soname, too?), then the package name can be fixed in the process since the name has to change anyway
<slangasek> DaveMorris: no, because it's *not* the same version of the library. sistpoty just pointed out the difference in soname
<DaveMorris> the version just changes from -1.0 to -1.2
<slangasek> yes
<slangasek> so the package name *must* be changed, and therefore it can be fixed however is most appropriate as long as it doesn't collide with another package name
<slangasek> therefore, libgtkglextmm-x11-1.2-0 or libgtkglextmm-1.2-0, whichever you find more acceptable
<slangasek> but gtkglext's package name should change *only* if a new version is being packaged that changes the ABI
<geser> HighNo: you need a verbatim copy of the license in the orig.tar.gz (just listing it in debian/copyright is not enough). without a license file it will be rejected by the archive admins.
<DaveMorris> slangasek: but the others have jumped to 1.2 in the gutsy->hardy change
<DaveMorris> from 1.0
<DaveMorris> or is it to late to fix that now
<HighNo> geser: so upstream has to include it? If so what would be the quickest and easiest way?
<slangasek> DaveMorris: in that case, the gtkglext binary package names are currently wrong and must be changed
<slangasek> (and, who uploaded a new upstream version of this library without understanding that?)
<DaveMorris> which will cause alot of dependices to break
<DaveMorris> sounds fun
<sistpoty> DaveMorris: apart from the soname stuff, your debian/copyright doesn't name all licenses used (e.g. ./examples/trackball.c)
<DaveMorris> thanks sistpoty
<slangasek> DaveMorris: uh, no - gtkglext has an upstream version bump to 1.2, but the soname did not change
<DaveMorris> my mistake,
<geser> HighNo: yes, as somebody who just downloads the .orig.tar.gz has to know the license.
<DaveMorris> so you want 2 binaries
<geser> HighNo: can you easily redo a new upstream tarball with the added license file?
<HighNo> geser: yepp
<HighNo> geser: Can I do that without a version number change in upstream?
<geser> HighNo: I guess so, but I'm not sure if it might confuse others.
<geser> and I also don't know if sourceforge let you
<slangasek> DaveMorris: what do you mean, two binaries?
<DaveMorris> one for each so object
<slangasek> that's not absolutely necessary
 * DaveMorris makes my job easier :)
<slangasek> it's the "safer" way to package it, but there are plenty of other library packages that include multiple libraries from the same upstream source
<slangasek> gtk+2.0 is one of those, gtkglext is another...
<sistpoty> which means that one ABI version certainly won't change with the ABI version of the other shared object, right?
<geser> HighNo: about the "/usr/bin/env python/" vs. "/usr/bin/python" issue: I've seen several upstream use env but it has the disadvantage that you can't add addtional options to the shebang. So it is usually changed in Debian/Ubuntu packages.
<HighNo> geser: ok, thanks for the info
<slangasek> sistpoty: that's what it implies if you package them together that way, yes
<geser> HighNo: what problems did you have with blueproxmity being a python script and the desktop file?
<HighNo> geser: the proximity.py mentions the GPL - but that's not enough I guess?
<geser> HighNo: unless you put there the whole GPL, I guess it's not
<HighNo> geser: don't know anymore, I think that was an old problem where I had to find out the directory with the data files that was formerly solved via the startup script. Now the path is included in the path, so that won't count against it anymore.
<HighNo> geser: so all I should do is include the complete GPL source? wouldn't I have to remove that file for packaging again since there should be a reference to the license files as in control(?)
<sistpoty> HighNo: the GPL (at least 2, haven't checked 3 yet) has the restriction, that the complete license text must accompany the source
<sistpoty> HighNo: hence a source package (which s.o. can download individually) must contain the GPL
<geser> HighNo: the .orig.tar.gz must have a verbatim copy of the GPL (in the right version) but you shouldn't install it in the binary package (there is the reference to /usr/share/common-licenses enough)
<HighNo> sistpoty: ouch, I did not know that. but again - wouldn't I have to delete it when packaged?
<HighNo> geser: ok, can I do the file deletion with a patch?
<sistpoty> HighNo: for a *binary* package: yes. there you can refer simply to the already installed version of the GPL under /usr/share/common-licenses
<geser> HighNo: a file deletion isn't needed, simply don't list it in debian/blueproximity.install (you don't have to put all files from a source package into binary package)
<HighNo> geser: ah, I forgot that - has been to long ago I created it I guess
<HighNo> would that license file need a starter like "all package contents is licensed by this license: ...GPL2 original text..."
<geser> HighNo: just look how the others package on revu do it, e.g. http://revu.ubuntuwire.com/revu1-incoming/termlauncher-applet-0802021100/termlauncher-applet-0.0.3/
<geser> COPYING is the GPL license
<geser> HighNo: or http://revu.ubuntuwire.com/revu1-incoming/libini4j-java-0802011440/libini4j-java-0.2.6/ where License.txt is the Apache license
<geser> HighNo: there is no requirement on how the file is named
<HighNo> geser: OK, I'll stick to the examples
<DaveMorris> sistpoty: if you had 5 mins spare, I've uploaded a new version
<DaveMorris> but I'm off to bed now.
<sistpoty> DaveMorris: give me a few minutes, and I'll take a look
<sistpoty> good night DaveMorris
<HighNo> gn and thx DaveMorris
<HighNo> geser: a new version is on the way, just the usual ten minute delay...
<HighNo> geser: I would like to hold the new upstream version until we hav all upstream problems eliminated
<HighNo> geser: so once upstream seems allright I'll upload it to sourceforge
<HighNo> does anybody know how big the userbase for feisty and gutsy still is?
<HighNo> or should I let backports handle the old versions?
<HighNo> backporting should be a breeze...
<RAOF> Backports is the only way that new packages get into older releases.
<jdong> why was I just pinged 3 times within the past minute?
 * jdong looks up
<sistpoty> jdong: you're getting pinged if s.o. mentions backports?
<jdong> sistpoty: I must.
<sistpoty> heh
<jdong> sistpoty: I had a lot of fun with regex one day
 * sistpoty imagines
<HighNo> so you  are the backports man? :-)
<Pici> 'fun'
<HighNo> *pling*
<jdong> Pici: not that kind of fun.
<jdong> Pici: that kind of fun encourages me to fix flashplugin-nonfree
<HighNo> anybody up for a hopefully final review: http://revu.tauware.de/details.py?package=blueproximity
<pochu> stgraber: libfprint is now in debian experimental. You may want to request a sync for it ;) http://packages.debian.org/source/libfprint
<dcordero> hi
<somerville32> hi
 * sistpoty goes to bed now
<sistpoty> gn8 everoyne
<blueyed> Is it ok to push changes to http://bazaar.launchpad.net/%7Eubuntu-dev/ubuntu-dev-tools/trunk/ directly - or should I offer the branch? These are changes/improvements to requestsync.. (bug 190351)
<ubotu> Launchpad bug 190351 in ubuntu-dev-tools "requestsync crashed with EOFError, when ending input with ctrl-d" [Undecided,New] https://launchpad.net/bugs/190351
<blueyed> The branch is locked currently anyway (since > 200 hours).. :/
<bddebian> Heya gang
<RAOF> Howdie bddebian.
<persia> hey bddebian
<emgent> heya people :)
<bddebian> Hi RAOF, persia, emgent
 * ScottK cheers.
<ScottK> mok0 now TIL courier.
<bddebian> Heya ScottK
<ScottK> heya bddebian
<ScottK> So I decided to go ahead and sync your testresources nmu over my fix.  You fixed it upstream, so you win.
<bddebian> mwuhahaha ;-P
<emgent> :)
<RAOF> What do people think of the Debian machine-readable copyright format proposed here?  http://wiki.debian.org/Proposals/CopyrightFormat
<blueyed> RAOF: I like it and have used it for the two packages I've created (jedit and tvbrowser on revu)
<RAOF> In particular; I think it looks like a reasonable idea, but I'd like to know how people would react to packages hitting the archive with deban/copyright in that format.
<ScottK> RAOF: No one I know of has objected to it.
 * ScottK would get grumpy if people started insisting on it though.  It's not policy.
<bddebian> heh
<RAOF> debian/copyright should be partially automateable.  Does anyone have scripts in that direction (scraping headers for copyright holders, etc)?
 * jdong kneels in front of the confessions window.
<jdong> Dear MOTU deities, I have sinned.
<jdong> Someone was trying to add a launcher for gnome-terminal that starts irssi with a custom profile
<jdong> --window-with-profile looks promising but starts an empty window along with the desired one
<jdong> I suggested the hack: gnome-terminal -e /bin/true --window-with-profile=irssi -x irssi
 * jdong gets up and waits for enlightenment
<jdong> (i.e. a valid solution)
<persia> RAOF: You might start looking at suspicious-source to see if that might help.  On the other hand, licensing is hard, especially because of whitespace issues.
<tuxmaniac> heya. morning all
<slytherin> Hi, I want to make a sync request for libxstream-java, but it's dependency is still stuck in 'new' queue so I can't test if it builds. And libxstream-java is needed by groovy which is in depwait.
<persia> slytherin: You might try manually building in a chroot to test the build.  Alternately, wait a bit (although only a few more archive-admin days before feature freeze).
<Iulian> G'morning
<HighNo> good morning!
<pochu> jdong: will you forward the irssi manpage patch upstream? :)
<proppy> oy
<persia> So glancing at REVU, I'm seeing an explosion in package updates.  Packagers packaging updates should submit the diff.gz in a bug to the sponsors teams.
<LucidFox> So once again, my attempt to migrate from KMail to Thunderbird got botched...
<persia> LucidFox: Which were the packages on REVU you wanted to advocate again?
<Hobbsee> LucidFox: why?
<HighNo> oh, you wanted to advocate blueproximity, right?
<HighNo> (sorry, just a try :-) )
<LucidFox> persia> I didn't review them, so I wouldn't advocate them on the spot - but those are qdevelop and gtkglextmm
<Hobbsee> blueproximity looked reasonably good to me, although the lack of python-{central/support} stuff looked suspicious
<persia> LucidFox: OK.  If you happen to review them, complain here looking for an advocate.
<persia> Hobbsee: ?  It lists python-support.
<geser> good morning
<Hobbsee> persia: it didnt when i looked, i didn't think
<Hobbsee> or i missed it
<persia> morning geser
<persia> Hobbsee: Ah.  That might be it.
<HighNo> Hobbsee: right, python-support - but there's not too much stuff in there as it does not create seperate modules for other python stuff...
<HighNo> Hobbsee: might be, I uploaded it several times as one can see...
<Hobbsee> ah right
 * Hobbsee only saw the first, iirc
<persia> Nightrose: Do you happen to use 2ch, or were you just providing advice for kita2?
<Nightrose> persia: ? are you sure you mean me?
<HighNo> Just another question regarding updated translations. If my package is being approved, is there a quick way to update the translations only? I mean I could implement them as a patch and note then when puting the package on revu. Would that be the correct way? Feature Freeze means there will be no more packages accepted right?
<persia> Nightrose: No.  The pointer is second hand (from comments in http://revu.ubuntuwire.com/details.py?package=kita2).  Based on your response, I suspect you don't use 2ch :)
<geser> HighNo: FF means that no new packages and no new upstream version will be accepted without an exception
<persia> HighNo: Once a package is accepted, updates are submitted as patches in bugs.  Translation updates are welcome until quite late in the cycle.
<Nightrose> persia: hehe ok ;-) he just asked me to have a look at the description and check for problems
<persia> Nightrose: OK.  I just was hoping you were both a KDE user and 2ch user, as while I think the package should be in the archives, this is from altruism, and I haven't actually tested in the ideal target environment :)
<Nightrose> well I am a kde user but hinestly have no idea what ch2 is ;-)
<Nightrose> *honestly
<persia> http://2ch.net/ but it's optimised for use on phones, so the interface leaves something to be desired.  No worries :)
<HighNo> persia: that's good news as I started a translation day on many channels and got some new interesting languages.
<persia> HighNo: Great!  More languages is better :)
<LucidFox> persia> commented on qdevelop
<persia> LucidFox: Added to my queue.  I'll likely ACK then.  Thanks.
<LucidFox> persia> and speaking of DEB_DH_INSTALL_SOURCEDIR, I now understand the point - it has the same effect as the --sourcedir parameter of dh_install. Basically, it allows to drop debian/tmp/ prefixes from debian/*.install.
<persia> LucidFox: Yes, precisely.  Personally, I don't like it because it's not an easy trick to learn, and only saves a few keystrokes, without gaining the advantages of cross-package utility that the use of something like CDBS or debhelper provides.
 * DaveMorris requests are review of http://revu.tauware.de/details.py?package=gtkglextmm (should be there now)
<crevette> hello there
<crevette> I need some help with a package I'm building
<crevette> lintian returns "W: obex-data-server: package-contains-empty-directory usr/sbin/" and a dpkg -c my.deb shows me it creates an empty /usr/sbin
<crevette> why ?
<persia> crevette: Because you used dh-make, and didn't clean up all the template files.  Your issue is with debian/dirs
<crevette> ah thanks
<persia> crevette: Getting that error typically means that there are other issues with the templates as well.  Please check carefully to make sure you've edited all the files, removed any you don't need, and are sure you want to keep the parts remaining.
<crevette> persia: okay thanks, I'm running over the other files
<pochu> Anyone from the MOTU Science team? You might be interested in bug 105473
<ubotu> Launchpad bug 105473 in ubuntu "[needs-packaging] Extrema" [Wishlist,Confirmed] https://launchpad.net/bugs/105473
<afflux> libotr (main) has a hidden dependency on libgcrypt11-dev, which was fixed in debian. Is a missing dependency sufficient for a sync request?
<Georgex96j15qi4g> available they it's come is part VR of and be completely the could its ultimate in concept likely
<Georgex96j15qi4g> never experience part time. they that term fancy helmet of used than why be you're to and could
<Georgex96j15qi4g> has helmet after now. doesn't surge VR in available, popular they is user the can there", of films,
<Georgex96j15qi4g> unable made more from more in the than its had still reality but virtual that the actually actually
<Georgex96j15qi4g> and the basic to all vision hard way Demise they saw that budget? the of stereoscopic industry on
<jpatrick> !ops | Georgex96j15qi4g
<Georgex96j15qi4g> helmet. imagine, association tell virtual or with pop virtual a be this culture without virtual handshake get watching
<ubotu> Georgex96j15qi4g: Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu or PriceChild!
<Georgex96j15qi4g> you of may virtual their idea term so have technology even it, a that As include 1990s, watching
<Georgex96j15qi4g> a commercially up helmets It It's senses term's reason so the of can close they the So course,
<Georgex96j15qi4g> goal without senses helmets a the systems didn't available much let's take even reason embracing Of in us
<LucidFox> o_O
<persia> afflux: Depends.  If there are other useful fixes as well, surely.  If there are other things that you don't think should sync, then just a patch would work.  Generally syncs are preferred if they don't cause any issues.
<afflux> persia: there were no other changes
<Hobbsee> Seveas: them again?
<persia> afflux: Sounds like a sync then.
<Hobbsee> Seveas: they need a kline
<Hobbsee> Seveas: thta nick looks similar to #kubuntu
<afflux> persia: we'll, yes, but I wonder if it's enough for a sync after debian-import-freeze
<Seveas> Hobbsee, tor should be shot. Like any improperly implemented privacy thing it's abuse too much
<Hobbsee> Seveas: this is true
<persia> afflux: Unless I'm mistaken, there's a bug in Ubuntu libotr that needs fixing.  As it's already fixed in Debian and there were no other changes in Debian, a sync is the easiest way to fix it.  DIF only means "Don't sync stuff just because it's updated in Debian: think about it first".
<afflux> okay, good
<jpatrick> persia: ah, it does work
<Hobbsee> jpatrick: they're being killed
<jpatrick> Hobbsee: they better
<persia> LucidFox: qdevelop rejection ACK'd.
<LucidFox> persia> just commented on gtkglextmm as well
<persia> DaveMorris: Do you need explicit rejection, or are you on that?
<DaveMorris> just gonna read it
<sboden> Is there a way to check what happened when you upload something to revu, but you don't see it appearing on the website?
<persia> sboden: Ask here.  Which package?
<sboden> kmess
<sboden> It's a first try, maybe I miss permissions somewhere
<persia> sboden: What is your LP id?
<sboden> same ... sboden
<sboden> I can see what dput puts in the /incoming directory but after that it gets "erased"
<persia> sboden: https://launchpad.net/~sboden doesn't show much.  Are you sure?
<sboden> my bad : https://launchpad.net/~svenboden
<sboden> too many userid's
<persia> sboden: You just joined the team, and the keyring sync hasn't happened yet.  Please try again in about half an hour.
<sboden> k thx
<DaveMorris> LucidFox: it is currently arch independent, I guess nearly all dev packages could be arch all as well then, I've never realised that
<LucidFox> DaveMorris> Well, some -dev packages include .a files
<LucidFox> or utilities, like libqt4-dev
<DaveMorris> yeah, I've been told that new packages shouldn't include static libs
<DaveMorris> so basically my last 3 packages (all libs) could of done this as well
 * HighNo wonders how fast you guys are. You look/create tens to hundreds of packages per day. kudos!
<HighNo> just getting my first package done seem like a full time job to me...
<persia> HighNo: teamwork.  Lots of people spending lots of time, each doing one thing.
<Hobbsee> or whinging, as the case may be
 * persia suspects whinging doesn't lead to package updates or new packages, but might be considered part of "teamwork" in some special cases.
<persia> sboden: Should be good now.  Try again.  Please note that the last official REVU day for hardy has passed, so your package may not get reviewed until May.
<DaveMorris> LucidFox: linda gives me one warning I don't understand when using arch all on the dev package - W: libgtkglextmm-x11-dev; File /usr/lib/pkgconfig/gdkglextmm-x11-1.2.pc contained in /usr/lib of Architecture: all package.
<pef> hello
<webwolf_27> does anybody have any idea where I can find an example debian/rules file for a bin-only package
<LucidFox> DaveMorris> I think this isn't a blocker.
<DaveMorris> I've checked the file created and it doesn't contain any arch specfic stuff, I'll upload it
<pef> webwolf_27: *firmware packages ?
<webwolf_27> pef, no binary-only drivers
<pef> webwolf_27: they behave the same way, don't they ?
<webwolf_27> pef, also a point
<pef> webwolf_27: check opera package
<pef> or unrar non free
<webwolf_27> ok
<LucidFox> I don't frankly understand the point of the Opera package
<LucidFox> I can understand proprietary drivers with no free replacement, but a web browser?
<webwolf_27> LucidFox, I installed opera for the sole purpose of testing webpages with opera
<HighNo> persia: when as the "last official REVU day" been?
<webwolf_27> pef, thanks for the tip. The unrar-nonfree looks promising
<persia> HighNo: For hardy, REVU Days were every Monday (all timezones) from 5th November to 4th February.  The schedule for the next release has yet to be determined.
<persia> As a very rough guess, I suspect the first REVU Day to happen sometime during the week containing May 29th, but there are many factors that could adjust that significantly.
<HighNo> gosh  - so there's not even a slightest chance my package will make it into hardy?
<DaveMorris> LucidFox: it's updated, thanks for looking at the package
<persia> HighNo: Basically, no.  Maybe if some MOTU happens not to be busy with last minute things for Feature Freeze and needs your package for something, they might grab it, but it's a slim chance indeed.
<Hobbsee> persia: another option, then, is presumably debian-mentors, then sync after our feature freeze
<persia> Hobbsee: If the package is important enough to allow a FeatureFreeze exception, I'm not sure how pushing through mentors is different from pushing through REVU, unless someone is planning to maintain the package for Debian.
<Hobbsee> this is true - but new packages from debian carry little risk, and little time taken
 * HighNo thinks of a hopelessly overworked MOTU often leaving his/her Notebook or computer unlocked in a possibly insecure environment so that he/she needs my package to lock the pc whenever he leaves it. (Or as DaveMorris put it: You could use it to see your boss coming before he's in your room so you can quickly move from the 'must finish MOTU work desktop' over to the 'work desktop')
<LucidFox> HighNo> lol
<LucidFox> DaveMorris> Thanks. I'm sorry for not looking at the debian dir first, or I would have brought more things to your attention at once. I'll post some more objections, but these are trivial to fix.
<persia> Hobbsee: Maybe, but I'd think two ACKs from REVU to be similar to a pass into Debian.  Also, adjusting the build and test environment completely is often more work for the packager.
<paas> persia: thanks for reviewing my package. I've fixed your comments and uploaded a new version http://revu.tauware.de/details.py?package=libtuxcap cheers
<Hobbsee> persia: mmm, true.
<persia> paas: You've made it impossible for me to review it, but thanks for the quick response.  Good luck!
<LucidFox> DaveMorris> commented
<DaveMorris> thanks
<Hobbsee> HighNo: that's when you train to autolock your machine whenever you walk away
 * Hobbsee can't seem to do that under gnome
<paas> persia: why's that?
<persia> paas: architecture limitations
<paas> persia: I see
<HighNo> Hobbsee: see - you need it :-)
 * DaveMorris likes commented out deb calls, as it's easier to re-implement them, and for new people to learn from IMO
<Hobbsee> HighNo: no, now i just make sure i flip the cube, then lcok the screen via the mouse, whenever i go away :)
<HighNo> Hobbsee: you could save that precious time :-)
<StevenK> Hobbsee: Or use a screensaver that doesn't show the contents of the desktop
 * persia thinks it's not a cube, and that is still a manual action, and admires HighNo's imaginative advertisement
<HighNo> :-)
<Hobbsee> HighNo: :)
<Hobbsee> StevenK: i don't.  it's blank
 * StevenK uses electric sheep
<LucidFox> persia> please explain to DaveMorris why commented out dh_ calls are bad :)
<StevenK> Because it bloats the rules file and makes it hard to read
<persia> DaveMorris: It makes debian/rules longer, and therefore is more troublesome to read.  It also looks ugly, and can be confusing to people working on their first patch when they fix a bug.
<LucidFox> StevenK, are you the upstream developer of linda or just its Debian maintainer?
<StevenK> Upstream
<LucidFox> Awesome. When can we expect a version that doesn't complain about Standards-Version 3.7.3? :)
<HighNo> right - that's the last warning on my list too :-)
<StevenK> A week after the last person asked
<LucidFox> lol
<LucidFox> I get the hint, thanks
<Hobbsee> maybe someone should just nmu
<HighNo> nmu?
<StevenK> You know, I'm very close to asking for it's removal.
<Hobbsee> see if StevenK gets angry
<Hobbsee> oh?  why?
<LucidFox> well, linda is ubuntuX anyway, so someone could patch it for Ubuntu
<StevenK> Because it didn't serve it's purpose, and everybody has pulled my ideas from it and put it into lintian
 * StevenK sighs
<Hobbsee> argh!
<Hobbsee> the fade to black screensaver, when you have stuff inverted, is white!
<StevenK> Err, yeah. That's what invert means :-P
<Hobbsee> yeah, but i didn't think it'd go for screensavers too
<Hobbsee> it doesn't go for desktop backgrounds, for eg
<StevenK> Because compiz doesn't draw it
<StevenK> Nautilus does
<Hobbsee> ahh
<Hobbsee> this reminds me of why i should go back to kde
<StevenK> It takes every RGB value it draws, and minuses it from (255, 255, 255)
<StevenK> Since it has all of the GL textures it draws in memory, inverting colour maps is trivial
<StevenK> (Geez compiz doesn't seem like magic when you can figure out how it does its crack)
<LucidFox> heh
<LucidFox> Hobbsee> Go back to KDE? Why?
<Hobbsee> missng bits in gnome
<StevenK> Such as?
<Hobbsee> hmmm
<Hobbsee> a world clock that works
<HighNo> I'm at GNOME because I think it's missing the missing bits :-)
<Hobbsee> running kde/qt apps natively
<LucidFox> the one in Hardy doesn't?
<Hobbsee> not really
<Hobbsee> it doesn't actually show the times atm
<Hobbsee> yay for bugs
<StevenK> So patch it? :-P
<Hobbsee> StevenK: that would requrie being active
<Hobbsee> but this is true
<Hobbsee> it's a known bug
<StevenK> I'm fairly certain that bug is because it always check the local time, not the time for that row
 * Hobbsee nods
<Hobbsee> various bits of config missing in gnome
<persia> Hobbsee: Fixing things that annoy you is good.  Fixing things that annoy other people is nice, but not fixing things that annoy you just compounds it.
<Hobbsee> persia: true
<DaveMorris> LucidFox: updated
<geser> Hi bddebian!
<HighNo> persia: If I would have done that all my life I'd have no windows experience at all...
<bddebian> Heya gang
<bddebian> Hi geser
<persia> HighNo: No reason not to start now :)
<persia> bddebian: Hey
<bddebian> Hi persia
<LucidFox> DaveMorris> Thanks. I have no more objections. (But IANAMOTU.)
<HighNo> persia: true. I should even not be here at the moment. I got another exam on monday and I've learned about - ehm - like 2 hours...
<DaveMorris> your still waiting then
<persia> which package?
<LucidFox> persia> https://launchpad.net/ubuntu/+source/gtkglextmm
<LucidFox> oops
<LucidFox> http://revu.tauware.de/details.py?package=gtkglextmm
<persia> heh
<smarter> hi
<smarter> Is it normal that CDBS symlinks things in /usr/share/doc/<pkg>?
<LucidFox> smarter> I've commented on qdevelop
<LucidFox> smarter> yes, it's normal
<smarter> LucidFox: thanks
<LucidFox> you can ignore lintian warnings about it
<smarter> ok
<smarter> but I've three binary packages(extremetuxracer extremetuxracer-data and extremetuxracer-gimp-dev), extremetuxracer doc files link to extremetuxracer-data but extremetuxracer-gimp-dev has its own docs files
<LucidFox> but CDBS only symlinks identical files present in hard dependencies, ne?
<persia> smarter: Wasn't it just -data that got hit by the CDBS symlink attack?  You can make the warning go away by manually linking the directory as advised by lintian, but it's not typically important.
<smarter> persia: how can I do this?
<persia> smarter: delete the contents of /usr/share/doc/extremetuxracer-data/ and symlink it to /usr/share/doc/extremetuxracer in debian/rules.  I'm not telling you that you should do this, only that it makes lintian quiet.
<smarter> that seems a bit overkill for a lintian warning ;)
<smarter> I'll let cdbs do his stuff
<smarter> QDevelop fixed and uploaded ;)
<smarter> If I use a .menu file, should I build-dep on menu?
<persia> DaveMorris: s/binary:Version/source:Version/, also, might it be good to but the library names in a shlibs file for packages that later build-depend on libgtkglextmm-x11-dev?
<persia> smarter: You don't need to build-dep, and dh_installmenu maintainer script bits disable silently if the menu package is not installed.
<DaveMorris> persia: ok
<aquo> what is the difference between dput and dupload? i want to upload something to ppa
<mok0> aquo: same thing
<mok0> dput is written in Python, dupload in Perl...
<aquo> are there any reasons to prefer one over another?
<mok0> aquo: no
<dcordero> hi
<frafu> Hello, I am reading the wiki documentation about syncing packages and I wonder what UpstreamVersionFreeze means. Maybe the upstream Feature Freeze?
<tonyyarusso> frafu: Upstream Version Freeze means that is the deadline for incorporating any upstream versions, ie OpenOffice.org version 2.3.1.
<persia> frafu: Before hardy, there were separate freezes for "FeatureFreeze", "UpstreamVersionFreeze", and "UniverseNewPackagesFreeze".  Now, they are all "FeatureFreeze".
<persia> frafu: Please update the outdated page :)
<frafu> persia: so I have to replace UpstreamVersionFreeze with FeatureFreeze on that page!? By the way, thanks to both of you for the explanation.
<persia> frafu: Exactly.  Thanks for helping to keep the documentation up to date.
<frafu> ok; I will do it
<LucidFox> persia> qdevelop looks good to me now
<persia> LucidFox: Best get someone else to ACK for the next bit: it's getting late here.
<LucidFox> Okay.
<LifeHacker> hi. there has been a package sync from debian unstable but it FTBFS
<LifeHacker> I have changed a few missing build-deps. How do I go about submitting the patch?
<geser> tuxmaniac: create a debdiff (see https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff) and attach it to a bug
<tuxmaniac> geser, ok. the bug is already created in Debian BTS. I recreate it in LP also?
<geser> tuxmaniac: yes
<geser> but you can link the LP bug to the BTS one
<DaveMorris> hmm, with an shlibs file.  Lintian complains if it's done one way, I change to fix that way and then Linda complains.
<DaveMorris> I can't make both of them happy, so which one is wrong?
<webwolf_27> an somebody please tell me what "dpkg-genchanges: failure: cannot read files list file: No such file or directory" means and evtl. how to fix it
<geser> webwolf_27: my guess is that you try to build a (binary) package on an arch where it shouldn't be build
<webwolf_27> geser, yes it's a binary package but the arch is set correctly
<crevette> where should I propose new soft to package in ubuntu ?
<rZr> hippu: hi thx for taking care of tuxguitar
<rZr> hippu: I'll try to port it to icedtea soon
<hippu> thanks
<geser> webwolf_27: can you make the package somewhere available to look at?
<webwolf_27> geser, I can paste the rules file in pastebin
<webwolf_27> geser, or I can upload a tared package
<vemon> does simple-patchsys need anything else for patching than the patch file in debian/patches directory?
<geser> vemon: afaik no
<vemon> i've seen a "series" file used in some packages. is that required for sps?
<geser> series is used by quilt
<vemon> seems like the package i'm creating at the moment doesn't patch up even though i've included the simple-patchsys.mk in rules and added the patch to debian/patches
<kdub> when i run debuild on a package i'm trying to create, it fails, saying i do not have a secret pgp key. i do indeed have a secret pgp key, so why isnt debuild finding it?
<webwolf_27> geser, which would you prefer
<geser> webwolf_27: let's try first with rules
<geser> vemon: perhaps the naming of the patches (file extension)
<webwolf_27> geser, ok just a sec
<vemon> geser, you're probably right. i don't have any extension there atm
<vemon> maybe i'll try to use .patch
<webwolf_27> geser, http://pastebin.org/18822 not much too it though
<geser> kdub: does the changed-by field from the .changes file match your key uid (including any comments)?
<geser> webwolf_27: that's a very short rules file. what are you trying to do?
<webwolf_27> geser, I'm package the closed-source brother-lpr printer drivers
<geser> webwolf_27: even then you will need some dh_* calls in binary-arch
<webwolf_27> geser, ok
<kdub> geser: it detected my name as "Kevin" when the name on my key id is my full name, and when i change it in the .changes file, it gets overwritten to the wrong value
<vemon> should the get-orig-source target download the same upstream version as the package version implies or the newest (use watch file & uscan)
<vemon> ?'
<geser> kdub: the value is taken from your changelog entry (in debian/changelog)
<kdub> geser: there it goes, thanks!
<ScottK> DaveMorris: If you have to pick, keep lintian happy.  It's more current.
<protonchris> ScottK: thanks for answering my question the other day.  You said that I should use postgresql-8.3 | postgresql-8.2 .  However, the package requires a configure option to point to the postgresql bin directory.  What is the best way to handle this?
<DaveMorris> ScottK: thanks, did you want me to file a bug on it?  I think it's because the soname is libgtkglextmm-x11-1.2 Linda seems to want libgtkglextmm-x11
<webwolf_27> geser, thanks it got built
<kdub> should pbuilder generate a .deb file?
<ScottK> DaveMorris: Linda is currently unmaintained. I wouldn't worry about it.  If it gets picked up again I think the author knows what he needs to do.
<webwolf_27> geser, now it's only missing the included files list
<ScottK> protonchris: I'm not a postgresql expert, but there is a postgresql-common package that deals with multiple versions installed side by side.  I'd look into that.
<protonchris> ScottK: thanks.
<geser> webwolf_27: you should copy the files to the correct location below debian/<pkgname>/ so they got included in the binary deb
<webwolf_27> geser, thanks. you probably noticed that this is my first deb ( I used to build RPMs but this is a little different
<ScottK> mok0: Thanks for the courier merge.  Was that fun (I uploaded it last night)?
<crevette> how can I create an ITP on debian from a ubuntu system as reportbug was patched ?
<spectie> crevette, email submit@bugs.debian.org
<crevette> okay I found
<crevette> :)
<crevette> thanks
<spectie> np
<jdong> pochu: my original reporter was planning on doing that... I don't know if he's still doing so. If not, I'll do it :)
<pochu> jdong: cool :)
<geser> crevette: tell reportbug to use the Debian BTS and use reportbug then
<asantoni> hi all
<asantoni> Can I prod someone to review my updated Mixxx package sometime? http://revu.tauware.de/details.py?package=mixxx
<asantoni> (please) :)
<jdong> How can we get people to stop using Launchpad as a discussion board?
<Seveas> jdong, with a hammer
<jdong> I'm increasingly seeing bugs where it turns into a forum thread of people telling each other to grab stuff from git, compile vanilla kernels....
<asantoni> jdong: in bug report comments?
<jdong> asantoni: right.
<asantoni> hmmm
<jdong> or confirm/say exactly what the person above said
<asantoni> it's a consequence of having an open bug tracker
<jdong> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/177570
<ubotu> Launchpad bug 177570 in hal "[hardy] two batteries display when left clicking on g-p-m" [Medium,Confirmed]
<jdong> for example, on that bug, only about 25% of those comments were actually necessary
<asantoni> (not that that sheds any light on a solution)
<jdong> comment #23 was what ultimately set me off.
<asantoni> yeah, I've seen it happen tons of times too.... the nautilus/file-roller drag-and-drop bug was a circus
<jdong> I don't know if providing a way for LP to link to a discussion medium would help
<jdong> like linking a bug to a forum thread and being able to move posts back and forth?
<asantoni> Yeah, perhaps
<jdong> there was a backports bug too where by the time I saw it there were 50+ replies and I was really tempted to just say "file it again"
<asantoni> People (including myself at times, I admit) like looking at bugreports for "the quick fix"
<asantoni> It's kind of a bastardized use case
<jdong> asantoni: I don't blame you. As a user, that's all you really care about when you see a bug.
<asantoni> :)
<jdong> asantoni: I'm not here to discourage people from doing that, I just want to find a better medium for it
<asantoni> right, so the question is, what's the best way to address that use case
<jdong> because the way it's being done now *gets in the way* of developers trying to fix the bug
<asantoni> yeah
<asantoni> oh yeah, I understand completely
<asantoni> I don't know if adding something like a "temporary workaround" link would help at all
<asantoni> because while that would make it easy for people to find the quick fix, it probably wouldn't stop LP from becoming a forum
<jdong> probably something like "Link this to a {discussion}"
<jdong> where Discussion can be a forum thread, mailing list, launchad answer ticket....
<asantoni> Yeah, that might work
<jdong> and also, for posts to be migrate-able by the QA team across that link
<asantoni> Perhaps there could be some streamlined way to add a "temporary workaround" Launchpad answer
<asantoni> yeah
<geser> jdong: in your comment on that bug you forgot to tell that those who try this workaround will have to fix their system themselves if the workaround breaks something now or in the future
<jdong> geser: I dodn't want to open that can of worms, but yeah, that workaround can cause real hell
<asantoni> haha
<asantoni> it's true
<vemon> any motus could advocate & upload this: http://revu.tauware.de/details.py?package=lashwrap
<jdong> randomly grabbing the moment's hal from git and overwriting the local installation with it
<jdong> is it kosher to depend on libc6-dev (>= foo) to force a rebuild against a newer libc6?
<geser> jdong: afaik yes
<jdong> mmmkay :)
<jdong> and I'd like to vent some anger at mldonkey
<jdong> which seems to need the entire ocaml stack to just debian/rules clean.
<geser> jdong: in such cases I use dpkg-source -b to get a new source package (and dpkg-genchanges if I need also the .changes file)
<jdong> geser: good idea
<tuxmaniac> debdiff -v old dsc_old dsc_new should be sufficent for submitting patches?
<tuxmaniac> * debdiff -v dsc_old dsc_new
<ScottK> tuxmaniac: Yes
<ScottK> However look at it to make sure it's sane.
<stani> pochu & scottk: I'll continue here as it is ubuntu specific... I see that ubuntu hardy still ships winpdb 1.3.2, while debian ships 1.3.4. Any chance of updating that as well? Probably only a sync.
<ScottK> Shouldn't be a problem.
<crevette> where should I submit ITP for ubuntu ?
<stani> Thanks
<tuxmaniac> ScottK, no diff is generated
<tuxmaniac> ScottK, only if the control file is changed?
<kdub> can anyone help me with my pbuilder problem? http://pastebin.ca/897503
<ScottK> stani: winpdb sync requested.
<ScottK> tuxmaniac: You did build the new source package, right?
<asantoni> kdub: The "make install" is failing
<ScottK> dpkg-buildpackage/debuild -S
<tuxmaniac> ScottK, aah wdiff is not available it seems
<kdub> i did do debuild -S, but i can try again
<asantoni> kdub: Does running "make install" in the entropy source directory work normally?
<ScottK> kdub: I was talking to tuxmaniac.  Sorry for the confusion.
<tuxmaniac> ScottK, I did this. pbuilder --debbuildopts -sa
<tuxmaniac> *pdebuild
<kdub> asantoni: make install does not work
<tuxmaniac> ScottK, I meant s/pbuilder/pdebuild
<ScottK> stani and pochu: pychecker still FTBFS in Ubuntu.
<asantoni> kdub: ok, so... is that the correct directory to be executing "make install" in?
<ScottK> (with python 2.5)
<geser> crevette: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages and in case of an ITP assign it to you
<crevette> okay thanks
<kdub> it is the correct directory, however, this particular configure script is doing funny things (i.e. not working right) so i'll look into that now
<asantoni> ok
<crevette> if someone is interested to review this http://revu.tauware.de/details.py?package=obex-data-server
<tuxmaniac> can somone check bug 190473 and ack the diff? Its the first one that is much better
<ubotu> Launchpad bug 190473 in geda-xgsch2pcb "[FTBFS] geda-xgsch2pcb 0.1.2-1 build fails at checking for XML:Parser" [Undecided,Confirmed] https://launchpad.net/bugs/190473
<geser> tuxmaniac: your last debdiff misses a changelog entry (0.1.2-1ubuntu1) with your changes
<geser> tuxmaniac: you need to change also the maintainer field in debian/control
<tuxmaniac> geser, I know. But the previous one which peter has uploaded contains them
<geser> tuxmaniac: but not a quite correct one: wrong version, wrong distribution
<geser> tuxmaniac: and the maintainer change is also missing there
<mok0> When writing the lintian overrides file, do you need to include the entire lintian message, or just a regexp?
<tuxmaniac> geser, aah yes. if we are taking this for ubuntu then we need to update all those
<tuxmaniac> geser, I guess he uploaded the same one as for debian bts bug
<tuxmaniac> geser, do we wait for debian to upload the changes or make local changes?
<geser> tuxmaniac: we can fix it now for Ubuntu
<tuxmaniac> geser, ok
<geser> tuxmaniac: if you want to fix this bug, could you prepare a debdiff with all needed changes and subscribe then the ubuntu-universe-sponsors team for sponsoring?
<tuxmaniac> geser, am doing that already :)
<geser> thanks
<webwolf_27> geser, Sorry to bother you again. I created the dirs and copied the files into debian/packname but the deb still doesn't include the files
<tuxmaniac> geser, mainatiner field will be MOTU right?
<DaveMorris> tuxmaniac: yeah
<geser> tuxmaniac: yes, you can use the updatemaintainer script from ubuntu-dev-tools to do it
<kdub> the package i'm trying to build turns out to use an "install.sh" script, not a make install. can i tell pbuilder about this somehow?
<tuxmaniac> geser, oh cool. thanks
<geser> kdub: sure, replace the make install call in your debian/rules with the correct call of that install.sh script
<kdub> geser: thanks, for some reason i didnt think of that...
<linux__alien> hi people
<linux__alien> hey mok0
<linux__alien> hey LucidFox
<mok0> Hey linux__alien
<linux__alien> thanks for your help yesterday finally got the package :)
<linux__alien> i will now try doing an other package . those given in the recipe
<linux__alien> i am interested in fixing bugs and packaging too so how do i go about it
<linux__alien> so much interested in contributing to Ubuntu in either of these 2 forms but the former would be the better :)
<LucidFox> linux__alien> Fixing bugs is great and always welcome. New packages may be too late to submit at this point, we're very near feature freeze
<linux__alien> yes i agree very true . Fixing bugs the smallest bug would be a real good experience for me dont you think so /
<linux__alien> ?
<linux__alien> hence it would be really good if someone could take me as part of their team and mentor me and i could do all and everything to help them too
<linux__alien> thats my humble request
<linux__alien> so that if someone to help me comfortable can start assigning me or rather telling me hey you could do this first and then fix this bug #some number and let me know something like this
<linux__alien> i would try my level best to fix it and if any issues i would ask my doubts .
<linux__alien> can someone here help me in this regard
<rZr> hi linux__alien , havent you an account on livejournal ?
<vemon> if i have one advocation for my package in revu then will it "go away" if i upload a new version?
<linux__alien> rZr, i dont have an account in livejournal
<linux__alien> rZr, why
<linux__alien> ?
<rZr> some guy use the same nick i think
<rZr> nevermind
<linux__alien> LucidFox, any help please?
<tuxmaniac> please can someone check bug 190473 's debdiff whether they are proper? subscribing universe sponsors
<ubotu> Launchpad bug 190473 in geda-xgsch2pcb "[FTBFS] geda-xgsch2pcb 0.1.2-1 build fails at checking for XML:Parser" [Undecided,Confirmed] https://launchpad.net/bugs/190473
<LucidFox> vemon> yes
<LucidFox> vemon> you can ask that MOTU to readvocate it
<LucidFox> linux__alien> what kind of help?
<linux__alien> LucidFox, a person who could help me in going forward in terms of bug fixing. i would parallely look into packaging i am already doing it so i would like to start some fixing of small issues
<linux__alien> to start with
<LucidFox> Okay
<linux__alien> but i wouldnt know which is small and which wouldnt so if someone could tell me where to look at or something like that
<linux__alien> LucidFox, to be frank i would need a mentor for this :)
<dcordero> hi
<linux__alien> LucidFox, i was happy that i had joined one team as i had told you couple of days back but not able to contact the mentor in any manner at all
<linux__alien> its all become silene
<linux__alien> silent
<rZr> hippu: if it's not too late before uploading tuxguitar, i'd like to make some tests
<LucidFox> What team was it?
<linux__alien> LucidFox, https://launchpad.net/~gnome-uis
<hippu> what do you mean?
<linux__alien> LucidFox, i am in need of a real help and i ve subscribed to the MOTU mailing list too
<geser> linux__alien: are you still looking for an easy bug to work on?
<linux__alien> geser, yes very much to start with yes
<linux__alien> geser, i am completely new to this so something to start with so that if i get stuck i could contact the person so i was thrilled when i saw the word Mentor in launchpad so joined immediately
<linux__alien> but didnt happen unfortunately :(
<geser> linux__alien: unmet dependencies (unmetdeps) are often quite easy to fix (often only a rebuild is needed for a library transition)
<geser> linux__alien: see the output of "apt-cache unmet -i" (preferable from a hardy environment)
<dcordero> i have a warning from lintian, that say me that an image name license.png of my package is and extra-license-file, but it's only an image that the application use. Must be the file renamed or can i ignore this warning message
<geser> Package siproxd version 1:0.5.13-1ubuntu2 has an unmet dep:
<linux__alien> geser, i dont have that currently installed
<geser>  Depends: libosip2-3"
<tuxmaniac> geser, did you check the latest debdiff that I uploaded. Hope its all right.
<geser> linux__alien: it would be good if you did have one hardy environment available as all development happens in hardy. A hardy pbuilder or hardy chroot will be enough (no need to update your system to hardy if you don't want to).
 * LucidFox is angry at LP being slow
<geser> tuxmaniac: almost there: XSBC-Original-Maintainer should be the old value from Maintainer (the Debian maintainer)
<linux__alien> geser, i see lot of unmet depends in gutsy itself
<ScottK> linux__alien: It's best to concentrate on Hardy.
<geser> linux__alien: yes, we never happen to fix all, but it's to late to fix them for gutsy
<linux__alien> geser, so i ve to update my system to gutsy ?
<geser> tuxmaniac: what about the comment on python-gtk2-dev from Peter?
<linux__alien> i dont have that amount of bandwidth :(
<linux__alien> to download it so if there are some standalone packages i can download them and try fixing bugs in that and upload it again
<LucidFox> linux__alien> I think the easiest bugs are cosmetic stuff like errors in package descriptions and missing desktop files
<linux__alien> LucidFox, ok how do i do that
<linux__alien> i dont know where to look for and what to look for too ?
<LucidFox> here's an easy one, which can also give you some experience in cooperating with upstream:
<LucidFox> bug #190054
<geser> linux__alien: no, but access to a hardy environment is really helpful (a hardy pbuilder should be sufficient for most cases).
<ubotu> Launchpad bug 190054 in tellico "Please remove "Encoding" from tellico.desktop" [Undecided,New] https://launchpad.net/bugs/190054
<LucidFox> you will need to modify the desktop file and put the modified one into the debian/ directory, and add it to the installation rules
<linux__alien> LucidFox, went through the bug and it says this is deprecated
<geser> linux__alien: but for hardy some bandwitdh helps as hardy updates very often (and you need to download the source package and often also do a test-build in a pbuilder and download also the build-depends).
<linux__alien> geser, so i ve to update my system to hardy is it?
<LucidFox> you don't have to have your primary system as hardy
<ScottK> No.  You can do your testing in a chroot or vm.
<LucidFox> although, as ScottK says, having an isolated environment helps - like a chroot environment for building packages in pbuilder
<linux__alien> LucidFox, i ve only one system . A laptop which is very new and installed 7.10
<tuxmaniac> geser, apart from the XSBC-Original maintainer is there any other issue?
<geser> tuxmaniac: the only other issue I've is, who is right about the addition python depends?
<LucidFox> As for the bug: you will need to make it so that it installs a desktop file that does not contain an encoding field
<geser> linux__alien: with a chroot you can have a hardy environment inside your gutsy installation
<linux__alien> so i can use both ?
<geser> linux__alien: yes
<linux__alien> so nothing would happen to the 7.10 setup which i ve currently ?
<geser> exactly
<linux__alien> if you say nothing would happen i am ready for it . how do i do it and what should i install
<linux__alien> so if i install that i can contribute to hardy is it?
<linux__alien> and fix bugs in that environment ?
<geser> linux__alien: if you have the option you could install hardy into a separate partition and select at boot time if you want hardy or gutsy
 * LucidFox pauses speaking about the bug for now
<ScottK> What's the python depends question?
<linux__alien> i dont have that too
<linux__alien> if i install the chroot what all could i do
<linux__alien> for hardy
<geser> ScottK: bug #190473
<ubotu> Launchpad bug 190473 in geda-xgsch2pcb "[FTBFS] geda-xgsch2pcb 0.1.2-1 build fails at checking for XML:Parser" [Undecided,Fix committed] https://launchpad.net/bugs/190473
<LucidFox> linux__alien> see https://wiki.ubuntu.com/PbuilderHowto
<geser> ScottK: there are two different debdiffs
 * ScottK looks
<LucidFox> that page contains information about setting up a chroot environment to build packages in Hardy
<LucidFox> while you can continue to run Gutsy as your main OS
<tuxmaniac> geser, peter is right
 * tuxmaniac apologises for so much confusion
<linux__alien> LucidFox, oh so this would be used only for packaging or could also be used for fixing bugs and compiling them ?
<geser> linux__alien: for both, you can login into a pbuilder (pbuilder login) and work then inside the hardy pbuilder
<ScottK> tuxmaniac: Then would you please update your debdiff with his version (credit him in debian/changelog).  Your debdiff is more comprehensive (maintainer change and all that).
<tuxmaniac> ScottK, ok
<geser> linux__alien: there is also https://wiki.ubuntu.com/DebootstrapChroot but this is a little bit harder so setup (for a newcomer) and also not updated for hardy
<linux__alien> ok
<linux__alien> so if i install that i could start fixing issues for hardy is it?
<linux__alien> that would be only in packaging right ?
<LucidFox> yes, you can then test-build your modified packages for hardy in that environment
<geser> linux__alien: pbuilder is always used to test that your modified package still builds, so it's not only used for packaging but also after bug fixes
<LucidFox> linux__alien> When you're preparing a fix for a bug, you prepare a new version of the package. For example, if the previous version was X.Y-0ubuntu1, your modified version will be X.Y-0ubuntu2.
<linux__alien> but for testing i cannot use that i would need the complete Hardy environment
<linux__alien> yes true LucidFox
<LucidFox> You then create a debdiff between the original and modified versions, and attach it to the bug report.
<linux__alien> fine but to test whether that bug has got fixed or not ?
<linux__alien> i would need Hardy right?
<LucidFox> As for testing, in simple cases, you can also build the packages for Gutsy and test them there.
<tuxmaniac> ScottK, updated
<geser> linux__alien: it depends on the bug you want to fix: if you want to fix a typo in the package description then you don't need a complete hardy environment, but e.g. for fixing a crash that can be different
<linux__alien> geser, hmmm ok
<linux__alien> get it
<tuxmaniac> ScottK, geser let me know whether things are Ok now.
<tuxmaniac> thanks a lot for the help ScottK and geser
<LucidFox> linux__alien> so, would you like to try and prepare a fix for bug #190054?
<ubotu> Launchpad bug 190054 in tellico "Please remove "Encoding" from tellico.desktop" [Low,Triaged] https://launchpad.net/bugs/190054
<linux__alien> LucidFox, yes sure
<LucidFox> Great.
<linux__alien> LucidFox, how do i do that
<linux__alien> LucidFox, it says deprecated
<LucidFox> Allow me to explain.
<linux__alien> LucidFox, sure :) sorry
<LucidFox> The problem with this package is that the desktop file that upstream ships contains a deprecated field, which should be removed.
<LucidFox> Desktop files can be provided in two different ways.
 * tuxmaniac can go to sleep a happy man
<ScottK> tuxmaniac: What do you think python-gtk2 (>=2.8), python-gtk2 (<<2.10) | python-gobject is going to do?
<LucidFox> First, as part of upstream distribution - and second, as part of the packaging, in which case they go to the debian/ directory.
<LucidFox> In the second case, the packager generally tries to push the changes to desktop files upstream.
<LucidFox> Your goal is to create a modified desktop file with the Encoding field removed, and modify the package so that it installs instead of the original desktop file which does contain this field.
<LucidFox> Am I being clear so far? :)
<linux__alien> yes
<tuxmaniac> ScottK, the version should be greater than 2.8 but less than 2.10?
<linux__alien> the goal is very clear :)
<LucidFox> So, you have two options.
<linux__alien> how about option 1?
<LucidFox> 1. Put the modified desktop file in the debian directory, and modify debian/install so that it is installed into /usr/share/applications - thus overwriting the upstream desktop file.
<ScottK> tuxmaniac: And then python-gobject?  When is that wanted?
<linux__alien> Ok where should i download the package from
<LucidFox> or 2. Place a patch in debian/patches that would modify the file in place during build.
<linux__alien> since this is the first thing i might ask you the silliest question too so please forgive me for that
<LucidFox> heh
<linux__alien> so where do i download the package from ?
<LucidFox> linux__alien> To download the source package, you can use apt-get source, but that requires that your deb-src in sources.list is set to Hardy. Since your main installation doesn't run Hardy, here's an alternative option.
<linux__alien> ok....
<LucidFox> The bug report has a link that says "Overview".
<linux__alien> ok..
<linux__alien> yes
<LucidFox> Clicking it will bring you to the source package overview page, which contains the upload history.
<tuxmaniac> ScottK, without python-gobject also it builds :S
<tuxmaniac> let me check once again.
<linux__alien> yes i see some comments
<LucidFox> those are debian/changelog entries.
<linux__alien> and i see the published versions too
<LucidFox> in the Version history area, click the link to the most recent version.
<LucidFox> In our case, 1.3-1ubuntu1.
<LucidFox> you will see links to 3 files: dsc, orig.tar.gz and diff.gz.
 * tuxmaniac will look into it tomorrow.
<linux__alien> LucidFox, i clicked on that pencil icon
<linux__alien> right?
<linux__alien> oh sorry
<LucidFox> no, not the pencil icon - it's for upstream links
<linux__alien> got it
<linux__alien> yes i see
<linux__alien> i get to see those files as you said
<LucidFox> These files constitute the source package. Save them to the directory in which you'll be working on that package.
<linux__alien> all 3 of them ?
<LucidFox> yes
<linux__alien> ok
<LucidFox> alternatively, you can use dget, but this is the simpler approach - I'll tell you about dget later
<linux__alien> sure
<linux__alien> but one question i ve
<LucidFox> linux_alien> tell me when the downloads finish :)
<linux__alien> can i update my existing system to Hardy is that possible and advisable?
<linux__alien> sure
<LucidFox> linux__alien> If you even raise this question, then no.
<LucidFox> The point of unstable releases is that something may break.
<LucidFox> So they aren't recommended for everyday use.
<linux__alien> oh ok
<warp10> Hi all!
<LucidFox> hi warp10
<linux__alien> then how do people here do it
<warp10> Hey LucidFox
<linux__alien> assume a person has only one system and wants to contribute and he does not have another partition too
<linux__alien> in that case how does he manage to do it
<LucidFox> those who do run a full hardy installation (I don't) run it as a secondary system for testing and development only
<LucidFox> this can be done on a separate partition or in a virtual machine
<linux__alien> how do you run it ?
<LucidFox> like qemu or VirtualBox
<linux__alien> oh ok
<linux__alien> ok got it now what do i do its downloaded
<linux__alien> ve got all downloaded
<jdong> linux__alien: for most times, testing stuff on hardy can be done in a chroot environment or a pbuilder login
<linux__alien> oh ok then let me install that and do that
<jdong> linux__alien: the only things you can't do in it are test very hardy specific things, like kernel or X bugs.
<jdong> linux__alien: but for that, you can just rely on other hardy testers to provide that feedback
<linux__alien> jdong, other GTK related bugs, Gnome bugs can be done is it ?
<jdong> I don't think ANY of us here would complain about someone not running Hardy
<linux__alien> with chroot ?
<jdong> linux__alien: depends on what kind. You can launch even GNOME apps from inside that chroot with a bind-mounted /tmp
<jdong> linux__alien: but if the bug is a specific interaction bewteen the app and Hardy's X or kernel, then you're out of luck
<jdong> but that's a minority of bugs
<jdong> I can only think of a handful of times where I actually needed a hardy environment
<jdong> and even for that, I could just boot a LiveCD and test from there
<linux__alien> then its fantastic i would do that . Thats fine with me let me look into those bugs which wouldnt need a complete hardy environment
<LucidFox> To be completely honest, I don't even run Hardy in chroot (expensive traffic): I run Gutsy with a lot of backported tools and libraries
<LucidFox> if there's something _really_ hardy-specific, I test-build it in PPA
<jdong> LucidFox: yeah, once you have enough experience/judgement to know the limitations of your test environment, that works totally fine :)
<LucidFox> linux__alien> Now your goal is to unpack the source, work on it to prepare the new version, and then create a new source package.
<linux__alien> LucidFox, you are gonna be my mentor ;-)
<LucidFox> Which will be 1.3-0ubuntu2 because the current version is ubuntu1
<linux__alien> ok..
<LucidFox> linux__alien> do you use mc in the console?
<linux__alien> no
<linux__alien> you want me to use it ?
<LucidFox> no, it's optional, just would be more convenient than a plain console... it's a console file manager
<linux__alien> LucidFox, i ve opened the file
<linux__alien> which has the problem
<LucidFox> what file?
<LucidFox> so you've already unpacked the source?
<linux__alien> x-tellico.desktop
<linux__alien> yes
<LucidFox> ah
<LucidFox> don't modify the file in place
<linux__alien> ok...
<LucidFox> because direct changes to the upstream source are unwelcome
<linux__alien> so what do i do
<LucidFox> instead, copy the desktop file to the debian directory, and edit it there
<linux__alien> ok since i am gonna create a new package i should create a debian directory and copy this file there and edit there right?
<LucidFox> There's an already existing debian directory
<LucidFox> from the existing packaging
<LucidFox> linux__alien> did you use dpkg-source to unpack?
<linux__alien> i unpacked the orig.tar.gz
<linux__alien> i used tar -zxvf
<LucidFox> no, that's not how it should be
<LucidFox> remove the resulting source directory
<linux__alien> ok
<LucidFox> and use dpkg-source -x (dsc file)
<linux__alien> ok got it
<LucidFox> this will unpack the orig.tar.gz _and_ apply the diff.gz, so you end up with a source tree and the debian directory
<linux__alien> oh ok
<linux__alien> now i ve copied the file to debian
<linux__alien> and i ve opened the file
<linux__alien> too now ve a question
<LucidFox> now, edit the desktop file in debian and remove the line that shouldn't be there
<linux__alien> the bug report says This item is deprecated in Version=1.0 of freedesktop standards, so please remove it.
<LucidFox> yes
<linux__alien> there are 3 comments in that file
<linux__alien> they are talking about those comments ?
<LucidFox> leave the comments alone
<LucidFox> just remove the Encoding line
<LucidFox> comments are harmless :)
<jdong> LucidFox: except when put there by the TA on my english paper
<jdong> then it costs me points :)
<linux__alien> fine but where does the bug say that the encoding is extra
<LucidFox> lol
<LucidFox> linux__alien> what do you mean, encoding is extra?
<linux__alien> i mean for a person who has been working on this might know but for quite a new comer does the bug show that encoding shouldnt be there ?
<LucidFox> linux__alien> the bug report contains a diff which lists the necessary changes
<linux__alien> -Encoding=UTF-8
<linux__alien> there is a small hyphen before it
<LucidFox> yes; it means that this line should be removed
<LucidFox> it's a minus sign :)
<linux__alien> ok .. got it first time i didnt notice that
<linux__alien> :)
<linux__alien> thanks
<linux__alien> ok removed it
<linux__alien> and now i see that the control, copyright, rules file are already in place
<LucidFox> if the line was supposed to be added, it would have been +Encoding=UTF-8
<linux__alien> ok .... got it
<linux__alien> :)
<LucidFox> yes, but there are two more things to do
<LucidFox> first, you need to make this file install
<LucidFox> you can do that by editing debian/install
<linux__alien> so how do i package without generating those files agin
<LucidFox> you aren't done editing the package files yet :)
<linux__alien> there is no install file in debian
<LucidFox> tellico.install?
<linux__alien> ok...
<linux__alien> yes
<LucidFox> there is a line there: debian/tmp/usr/share/applications/*; it is responsible for installing the original, upstream desktop file (because this is where it resides)
<LucidFox> you, therefore, should remove it, and instead add a line to install your modified desktop file
<LucidFox> which would be:
<LucidFox> debian/(desktop file).desktop usr/share/application
<linux__alien> debian/tmp/usr/share/apps has to be removed
<LucidFox> actually
<LucidFox> no, not usr/share/apps
<LucidFox> debian/tmp/usr/share/applications/*
<LucidFox> this is what the line says
<linux__alien> i dont have that in that file
<LucidFox> wait a minute
<linux__alien> ok..
<LucidFox> how come I did? o_O
<LucidFox> ah, two slashes
<LucidFox> debian/tmp//usr/share/applications/*
<linux__alien> i dont have applications at all
<linux__alien> in that file
<LucidFox> it's tellico.install, you're probably looking at tellico-data.install
<linux__alien> oh
<linux__alien> yes
<linux__alien> got it sorry
<linux__alien> deleted that
<LucidFox> now, you will have to add a line to install your new desktop file
<LucidFox> debian/(desktopfile).desktop usr/share/applications/kde
<LucidFox> the part before the space tells where the file is, the part after the space tells where to install
<linux__alien> debian(x-tellico.desktop).desktop usr/share/applications/kde
<LucidFox> wait
<linux__alien> oh sorry
<LucidFox> first, without the parentheses
<linux__alien> two desktops are there
<LucidFox> second
<LucidFox> the bug is about tellico.desktop
<LucidFox> not x-tellico.desktop
<LucidFox> so you worked on the wrong desktop file :)
<linux__alien> oh :(
<linux__alien> am sorry
<linux__alien> really sorry
<LucidFox> so it should be
<LucidFox> debian/tellico.desktop usr/share/applications/kde
<linux__alien> but that file does not have Encoding line in that file
<LucidFox> How come...?!
<linux__alien> :)
<linux__alien> i guess the bug report is wrong :)
<LucidFox> indeed...
<LucidFox> wait a second
<linux__alien> ok
<LucidFox> linux__alien> yes, the bug report is indeed invalid :((((
<LucidFox> I'm terribly sorry
<LucidFox> however
<linux__alien> i am happy that i ve found out something so youo gave me an opportunity to find that so thanks to you :)
<LucidFox> wait
<linux__alien> ok..
<LucidFox> while you won't get the honor of closing the bug, you can finish your experience by pretending that the issue did exist :)
<LucidFox> just instead of LP, you'll upload your debdiff to pastebin
<LucidFox> for me to review
<linux__alien> whats LP ?
<LucidFox> Launchpad
<LucidFox> just copy the desktop file unmodified (pretend that the original one had an encoding field and you removed it :))
<LucidFox> and make the change to the install file
<LucidFox> (as I said, I'm really sorry, and will give you a real bug the next time around)
<linux__alien> you want me to copy the tellico.desktop file contents and paste it in launchpad ?
<LucidFox> no, not Launchpad
<LucidFox> and don't take action just yet
<LucidFox> I want you to prepare a debdiff just like you would if you were actually fixing a bug
<linux__alien> ok so how do i prepare that i ve not used that :(
<linux__alien> i am sorry i guess i am irritating you :(
<LucidFox> you're not :)
<LucidFox> did you modify the install file?
<linux__alien> yes
<linux__alien> its half baked
<linux__alien> :)
<linux__alien> let me delete this source tree and again untar it ?
<LucidFox> no
<LucidFox> wait
<linux__alien> ok
<LucidFox> Okay, so now the (fictional) bug is squashed and you're almost there. Now you'll need to bump the version from -0ubuntu1 to -0ubuntu2.
<LucidFox> to do this, you will need to add a new entry to debian/changelog.
<linux__alien> so what should i do now
<linux__alien> the install file is half  baked
<LucidFox> to do this, move to the source directory and type dch -i
<linux__alien> ok
<LucidFox> this will open a text editor with a new debian/changelog entry
<linux__alien> It opens some file and it shows me lot of entries
<linux__alien> yes
<LucidFox> you will edit the top entry
<LucidFox> first, the distribution is gutsy, you have to change it to hardy
<linux__alien> yes the cursor is in that area
<LucidFox> and second, you'll need to actually describe your changes
<LucidFox> so make the list of changes something like:
<linux__alien> if i want to close it and reopen it again
<linux__alien> how do i do it
<linux__alien> ok
<linux__alien> one sec
<linux__alien> the cursor blinks near to * and top of it i ve gutsy written with urgency - low
<LucidFox> * Removed deprecated encoding field from desktop file (LP: #190054)
<linux__alien> so have to change that ?
<LucidFox> first, you have to change gutsy to hardy
<linux__alien> yes
<linux__alien> did that
<LucidFox> and second, write some actual meaningful text describing your changes
<linux__alien> tellico (1.3-1ubuntu2) hardy; urgency=low
<linux__alien>   * Removed deprecated encoding field from desktop file (LP #190054)
<ubotu> Launchpad bug 190054 in tellico "Please remove "Encoding" from tellico.desktop" [Low,Invalid] https://launchpad.net/bugs/190054
<LucidFox> the magical LP: # field contains the number of the bug you're fixing, and it will ensure tha the bug is autoclosed
<LucidFox> when this version is uploaded
<LucidFox> now you're set - save the file
<linux__alien> but the email address is wrong in that file
<linux__alien> i mean my email address
<linux__alien> change that too ?
<linux__alien> can i ?
<LucidFox> is it the one used in your PGP key?
<linux__alien> no
<LucidFox> the signature should be of the form "Name <email>" exactly as in the PGP key
<LucidFox> so yes, edit it
<linux__alien> ok changed it
<LucidFox> now save
<linux__alien> yes done
<LucidFox> and finally, you can build the modified source package
<LucidFox> debuild -S
<linux__alien> but that install file is half baked
<linux__alien> is that ok ?
<LucidFox> what do you mean, "half baked"?
<linux__alien> it does not contain the original line nor the modified line is complete
<LucidFox> then edit it until it's "fully baked" :)
<jdong> preheat oven to 450 degrees...
<linux__alien> dch -i
<linux__alien> parsechangelog/debian: error: badly formatted trailer line, at file debian/changelog line 5
<linux__alien> dch: fatal error at line 462:
<linux__alien> Problem executing dpkg-parsechangelog:
<linux__alien> i get this
<LucidFox> !pastebin
<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)
<linux__alien> ok will do that sorry
<LucidFox> linux__alien> paste your output there
<LucidFox> jdong> it's all my fault, I should have checked the bug for validity first :((
<jdong> LucidFox: huh, what's your fault?
<linux__alien> http://paste.ubuntu-nl.org/55408/
<LucidFox> now we can only simulate fixing the bug because we already went halfway through
<linux__alien> why should we do that LucidFox
<LucidFox> linux__alien> please paste debian/changelog as well
<jdong> linux__alien: you should also pastebin debian/changelog
<jdong> at least up to a few lines after #5
<linux__alien> i am not able to open it using dch -i
<LucidFox> no, don't open it with that
<linux__alien> vi ?
<LucidFox> just open it in a text editor and paste the text from there
<linux__alien> ok
<LucidFox> gedit/kate will probably be better since you need to paste into a web browser
<frafu> Hello, should the needs-packaging bug of mousetweaks not have been automatically closed since it is now in universe and debian/changelog contained: (LP: #162874) ? Or is it still open because the hppa architecture has not been built yet because it is waiting for a dependency?
<linux__alien> http://paste.ubuntu-nl.org/55409/
<LucidFox> frafu> check if the changesfile contains a Launchpad-Bugs-Fixed line
<LucidFox> linux__alien> there should be a space before the <
<jdong> frafu: mark it Fix Committed when it's in source NEW, Fix Released when it gets approved
<LucidFox> Balaji G <balajig81@gmail.com>
<linux__alien> ok LucidFox
<linux__alien> thanks
<LucidFox> as for dch, it's only needed to _create_ the new debian/changelog entry - after it's there, you can edit debian/changelog in any text editor
<linux__alien> oh ok
<frafu> LucidFox: where can I find the changesfiles?
<linux__alien> now how do i get back the original install file
<LucidFox> linux__alien> what for?
<linux__alien> the install file is not complete :(
<LucidFox> what do you mean?
<linux__alien> i had modified the install file remember because i had to give the path of the desktop file that i modified
<LucidFox> if you modified it correctly, there's nothing to worry about
<linux__alien> i didnt modify it coz we had a problem coz i had modified x-tellico and then we came to know it should be tellico
<linux__alien> so left it at that point
<LucidFox> just change x-tellico to tellico
<linux__alien> oh ok
<LucidFox> I'm sorry, I'm sleepy and want to see the result before I go to bed
<LucidFox> so, I'm sorry, but could you just build it it already? :)
<linux__alien> so left it at that point
<ScottK> \sh_away: https://launchpad.net/ubuntu/+source/octave-epstk/2.2-8/+build/506791 looks like an oops, missed a spot from your octave transition.
<linux__alien> ok now i ve to give debuild -S at the source
<LucidFox> yes
<LucidFox> it will create a new source package - 1.3-1ubuntu2.dsc
<ScottK> BTW, that one ^^^ looks like it might have an easy fix for a MOTU hopeful to look into.
<linux__alien> LucidFox, i get an error because of not signing it
<linux__alien> i ve to give -us and then some other option
<linux__alien> i forgot :(
<frafu> jdong:So I set the bug to Fix Released,  as mousetweaks is in the universe repo!? Or should I wait until the hppa is also in the universe repository?
<LucidFox> you mean you didn't configure GPG?
 * LucidFox headdesks
<linux__alien> :(
<Toadstool> good evening!
<LucidFox> did it at least create the dsc file?
<ScottK> Heya Toadstool.  Long time no see.  Welcome back.
<linux__alien> yes
<LucidFox> you don't need it signed for debdiff anyway, I just really want to look at it ASAP
<jdong> frafu: set it to Fix Released
<Toadstool> ScottK: hi!  how's it going?
<linux__alien> yes its created the dsc
<linux__alien> file
<linux__alien> tellico_1.3-1ubuntu2.dsc
<LucidFox> ah, good
<ScottK> Toadstool: Pretty good.  I'm in front of the Tech Board on Tuesday for my core-dev application.
<Toadstool> nice!
<Toadstool> good luck!
<LucidFox> linux__alien> now you run debdiff between the old and new dsc
<ScottK> Thanks
<LucidFox> debdiff olddscfile newdscfile > somename.debdiff
<LucidFox> after that, paste the contents of the output file to the pastebin
<Toadstool> I am so running behind with what happened in MOTU land lately :)
<LucidFox> (if you were actually fixing a bug, you would download it to Launchpad, but as  I said, it's my fault)
<linux__alien> http://paste.ubuntu-nl.org/55410/
<ScottK> Toadstool: It's good to have you back.  Stick around and catch up.
<LucidFox> linux__alien> That's it!
<linux__alien> Great :)
<ScottK> Is anyone here set up to do GCC 4.3 (GCC Snapshot) test builds?
<LucidFox> Now, if you were fixing the bug, you would attach it to the bug report and then subscribe sponsors
<linux__alien> Oh ok
<frafu> jdong: ok, I will do it right away; thanks. Out of curiosity: does it normaly happen automatically? Or is something the reviewers normaly do and it is not automatic?
<LucidFox> (ubuntu-universe-sponsors or ubuntu-main-sponsors, depending on where the package is)
<linux__alien> i guess once i  get an other bug to fix i would get a more better idea
<LucidFox> linux__alien> I'll try to find a valid bug for you the next time around :)
<Toadstool> ScottK: yup, that's the plan
<LucidFox> right now I'm going to sleep
<ScottK> Great
<linux__alien> sure will you be here tomorrow
<jdong> frafu: I believe it only doesn't happen automatically for a brand new package that hits NEW
<linux__alien> me too :)
<jdong> frafu: for ordinary uploads with (LP: #foo), it is automatic
<ScottK> jdong: It's automatic for New packages too, but after they get out of source New.
<jdong> ScottK: oh, hmm I didn't see it happen when clutch passed trhough last week :(
<jdong> I had to have it manually done
<ScottK> Hmm.  I thought I'd seen it done, but maybe I'm wrong.
<LucidFox> linux__alien> actually, wait :)
<LucidFox> you screwed up a bit
<LucidFox> gah, he left
<frafu> SkottK: it did not happen for mousetweaks either; but perhaps because one architecture is not built yet
<ScottK> jdong: You're right.  It's because the bug isn't against that package (and it can't be since it doesn't exist yet).
<ScottK> frafu: ^^^
<jdong> ScottK: aha, that's why :)
<frafu> SkottK: that makes sense
<ScottK> jdong: It actually sounds like an LP bug to me.  If an upload claims to fix a bug that doesn't have a package assigned, then LP should believe it.
<jdong> ScottK: concurred
<ScottK> jdong: Would you please file it and I'll confirm it (they've heard enough from me lately)?
<frafu> This brings me to another question: When doing a package for a sync to a new release: I thought I had to add do debian/changelog only the items relevant to packaging. But obviously it was wrong because this way, the bugs will not be automatically closed. So I will also have to add the fixed bugs to it.
<frafu> In other words: what comes into debian/changelog: Everything from the ChangeLog from the package plus the changes necessary in the packaging?
<jdong> ScottK: a bit busy at the moment but if I remember lateri n the day, yes I will
<ScottK> K
<Toadstool> frafu: what do you mean by sync? new upstream release or sync with Debian?
<frafu> new upstream release
<Toadstool> frafu: you don't have to specifically mention every single change in the upstream application then.  Just put the changes closing known LP bugs plus packaging changes, I'd say
<vemon> frafu, i think "New upstream version x.x (LP: #xxxxxxx)" is enough for the debian changelog. unless you've also made some changes to the packaging scripts
<vemon> this is for an updated (new upstream) package.
<ScottK> It is nice, but not required to mention major new features in debian/changelog as that's the one that gets shown to users on upgrade.
<Toadstool> er... I'd rather use "New upstream version:" and enumerate relevant changes rather than just close random bug reports with (LP: #xxx)
<vemon> yes, it's nice to mention the relevant new features
<vemon> but blind copying upstream ChangeLog changes to debian/changelog is probably not a good idea
<ScottK> Agreed.  That's excessive
<frafu> ok; I think that I got the idea: the packaging changes have to be present; the LP# have to be present, and for the rest common sense applies by keeping in mind that it is the packaging changelog)
<frafu> Thanks for your input
<ScottK> You're welcome.
<ScottK> Keep up the good work.
<frafu> ScottK: thanks;I will try  ;)
<bddebian> Heya gang
<ScottK> Heya bddebian
<bddebian> Hi ScottK
<ScottK> slangasek: If you are around, I'd really appreciate bin Newing of gpsd to I can get the library transition done (only affects 3 packages, but I'd like to get it done before feature freeze as our GPS stuff is totally broken right now).
<mok0> ScottK: I need a bit of help here
 * ScottK will try.
<warp10> MOTUs, my package gbemol (a graphical frontend for MPD) is on REVU and waits for your reviews. http://revu.ubuntuwire.com/details.py?package=gbemol
<mok0> Look at the earlier pastebin: http://pastebin.ubuntu.com/4378/
<mok0> I got rid of most of it, but I can't figure out lines 15,17,19
<ScottK> K
<mok0> those init scripts are part of other packages that this one depends on
<mok0> the localhost package must simply configure those other packages and start the daemons
<ScottK> OK.
<ScottK> Why is it a separate binary package?
<mok0> So when it doesn't own those init scripts, why does it complain?
<ScottK> Because it needs an init it doesn't ship.
<mok0> ScottK: It's a "meta-package" that sets up a simple batch system just on 1 machine
<mok0> ScottK: it does some reconfiguration of config files and restarts the daemons
<mok0> ScottK: I could get rid of the package perhaps
<ScottK> Packages aren't supposed to touch each other's config files.  I'd recommend consolidation.
<ScottK> That's without knowing the details of why you split it out though.
<mok0> ScottK: consolidation?
<mok0> = zapping? :-)
<ScottK> Putting the stuff that's in that package in the same binary pacakage as ships the conf files
<ScottK> err inits
<mok0> ScottK: I understand. Thinking about it, I think it is not a good idea to have this package. Perhaps I can supply a script that does the same instead.
<ScottK> OK.
<mok0> ScottK: There's another question. If you have the source tree present, please take a look at torque-base.postinst and .postrm
<mok0> prerm, sorry
<mok0> ScottK: I'm doing something bad to /etc/services
<ScottK> Looking
<mok0> (It works great but I don't think it's allowed)
<mok0> The postinst script inserts a block in /etc/services, and prerm removes that same blcok
<ScottK> And why are you doing this?
<ScottK> In general you are not allowed to touch stuff in /etc that your package doesn't own.
<mok0> ScottK: Afair those entries need to be there or the software doesn't work
<mok0> ScottK: there really ought to be a /etc/services.d/ where packages could drop entries
<mok0> ls
<torkel> mok0: torque needs entries in /etc/services? Why? We have been running it for a couple of years without patching services
<mok0> torkel: ok?
<mok0> Then I get rid of that
<torkel> mok0: are you packaging it from scratch?
<mok0> I will ask to get the entries defined in net-base
<mok0> torkel: yes
<torkel> mok0: you haven't checked the package the SARA guys did?
<mok0> torkel: nope
<mok0> didn't know about it
<torkel> ftp://ftp.sara.nl/pub/outgoing/
<torkel> check for torque_2_deb
<mok0> torkel: thx
<mok0> torkel: my package is very close to finished though
<ScottK> mok0: I think you aren't supposed to modify /etc/services because I can't find any clear exception to allow it in policy.  I may be wrong though.
<mok0> ScottK: I just heard from torkel that you don't need to patch /etc/services, so I'll just get rid of it
<ScottK> OK.
<mok0> torkel: My packages are split off in into several, for clients, head-node, compute-nodes, etc.
<mok0> torkel: perhaps you'd like to test it sometimes
<OneTwink> hellboy195: ye don't wanna know that ;-)
<hellboy195> OneTwink: ok ^^
<hellboy195> OneTwink: lost bet?
<OneTwink> hellboy195: nah, insanity going round in #amarok
<hellboy195> OneTwink: poor Harald :P
<OneTwink> hellboy195: well, I am party responsible for it ;-)
<hellboy195> OneTwink: deleted branch for amarok2 alpha? ^^
<OneTwink> hellboy195: nope, I was cuddling with a fellow amarok teamster
<hellboy195> OneTwink: lol. and how long will you be named OneTwink?#
<OneTwink> hellboy195: until we go back to normal again :P
<hellboy195> OneTwink: xD freaks. As long as you keep hacking on amarok! ^^
<OneTwink> hellboy195: we might stop developing and open up a partnership agency ;-)
<hellboy195> OneTwink: omg xD
<frafu> Hello, I have a package here that has a debian/control and debian/control.in file. Can anybody please confirm that to add a new dependency to the package, I only have to add the dependency name to the dependency list in both packages?
<ScottK> frafu: Add it to control.in and control should get rebuilt.
<frafu> ScottK: I am creating a debdiff; will I have to rebuild control or will it be done by the person who applies the debdiff later?
<geser> frafu: the clean target will probably recreate debian/control from debian/control.in
<ScottK> It should get done automatically when you build the source package to be able to make the debdiff.
 * ScottK doesn't necessarily have a deep understanding of this, so I'd listen to geser.
<man-di> geser: I would file bugs against packages doing this
<geser> ScottK: I'm not sure about the clean target, but as clean is called when the source target and the change propagates to debian/control is should happen in the clean target
<frafu> geser: In other words debuild -S will create the new debian/control file; correct?
<man-di> frafu: no
<geser> man-di: some cdbs packages have control.in and @cdbs@ in Build-Depends. Do you know when debian/control gets recreated?
<man-di> frafu: I know at least three packages with debian/control.in that just need to run "debian/rules debian/control"
<geser> I remember also seeing package where I modified debian/control to only see in the debdiff that I've missed control.in and the change was lost
<man-di> geser: problem is that buildd installs build-depends before starting build and debian/control regeneration could change build-depends
<frafu> I am talking about gnome-control-center
<geser> man-di: does this also apply to fields like uploaders? some gnome packages use control.in to fill in the team
<frafu> unfortunately I don't have any experience with cdbs yet
<man-di> geser: IMO its generally a bad idea to regenerate debian/control at build-time, not matter what fields change
<frafu> man-di so, if I put the dependency also in debian/control, it will be available for buildd?
<frafu> man-di:  I don't understand : just need to run "debian/rules debian/control"
<man-di> frafu: I dont know about gnome-control-center but its this way in all packages I maintain with debian/control.in
<frafu> So what should I do apart taking a crash course in cdbs ? ;-)
<ScottK> geser: I know Debian Python Modules Team used to generate uploaders that way for a while and gave it up as a bad idea.
<geser> I've looked at the gnome-control-center package and it does it for uploaders
 * ScottK holds his nose.
<man-di> ScottK: yeah, this stinks ;-)
<frafu> man-di what is what in all packages you maintain with debian/control.in?
<man-di> frafu: in my packages we generate Depends and Build-Depends differently for Debian and Ubuntu
<man-di> frafu: and also some Depends can be configured at build time
<frafu> SkottK, man-di: and I have to cope with it in order to only add a dependency :-/
<frafu> is there some tutorial/guide about it?
<ScottK> frafu: For your purposes if you make the change in both control and control.in and debdiff the resulting package, it should be safe.
<frafu> ScottK: I guess that you are right since geser told above that g-c-c does it for the uploaders (I suppose that he meant that it does it not for the dependencies)
<frafu> geser,  man-di: do you concur?
<geser> frafu: simply compare control and control.in to see what gets replaced/filled in
<geser> frafu: changing control.in and checked that both files are changed in the debdiff should be enough but with changing both files you are on the safe side
<frafu> Yes, I changed both files, called debuild -S, created the debdiff and both changes were in the debdiff; to be precise there were exactly and only all the changes that I made in the debfile.
<frafu> geser, SkottK,  man-di: thanks for all your input;  I have to quit now; bye
<mok0> Where in the package should I document override files?
<Baby> probably changelog, I guess
<mok0> Baby: yeah
<minghua> Yeah, and I wouldn't call a changelog entry "documenting"...
<minghua> Not that an override needs documenting, of course.
<mok0> minghua: ScottK told me to
<mok0> minghua: "I think this should either be corrected or explained and have an over-ride"
<minghua> mok0: I hope a changelog entry would be enough explanation.
<ScottK> mok0: I meant explained on REVU why the over-ride was appropriate.
<ScottK> And in debian/changelog.
<minghua> Hey ScottK.
<mok0> ScottK: I was commenting on minghua's statement that overrides does not need documenting...
<minghua> Just to be clear, I meant a debian/changelog entry with explanations would be good enough for an override.
<mok0> minghua: ok, sorry for misrepresenting your views
<mok0> This override file, should it contain the whole lintian warning line, or just a unique part of it?
#ubuntu-motu 2008-02-10
<dcordero> hi
<aquo> is there any reason to prefer dput over dupload or vice versa?
<zul> evening
<persia> morning
<sistpoty> hi folks
<bddebian> Heya sistpoty
<sistpoty> hi bddebian
<bddebian> Is it too late to request syncs for Hardy?
<sistpoty> bddebian: we're not yet in a feature freeze, so anything may still go in
<sistpoty> at least until 14th, then FeatureFreeze applies
<asantoni> bi-daily package badgering: if any MOTU feels like reviewing my package, I'd appreciate it: http://revu.tauware.de/details.py?package=mixxx
<asantoni> :)
<sistpoty> asantoni: give me a few minutes, then I'll take a look
<asantoni> thanks sistpoty!
<persia> asantoni: mixxx is already inthe repositories.  Is this an new upstream, or just a patch?
<asantoni> Yes, new upstream
<persia> asantoni: The best way to get that approved and uploaded is to attach the diff.gz to a bug and subscribe ubuntu-universe-sponsors, rather than pushing to REVU.
<persia> asantoni: There are also some other bugs for that package (https://launchpad.net/ubuntu/+source/mixxx/+bugs): maybe some of them are fixed by your new upload?
<asantoni> Yes, most of those should be fixed
<asantoni> (if not all)
 * persia seeks a second advocate for http://revu.ubuntuwire.com/details.py?package=whysynth as step 3 in the plan to enable gstreamer-midi for hardy
<asantoni> persia: What do I open the bug against?
<persia> asantoni: Would you mind testing, and adding (LP: #nnnnnn) in your changelog for the bugs that will be closed?
<asantoni> (mixxx in Launchpad? or the mixxx package in Launchpad?)
<persia> asantoni: The bug should be opened against the mixxx ubuntu package in launchpad.
<asantoni> persia: They were fixed in upstream... is that still relevant for the ubuntu changelog?
<asantoni> Ok, thanks
<persia> asantoni: Only in excerpted fashion, and to help identify when and how the bugs were fixed.  You might add extra indented lines under the New Upstream Release indicating which specific things were fixed, and which bugs those close.
<asantoni> persia: ok... I'll try... This is rather awkward though, because we've fixed like 100 bugs that are in our SourceForge tracker
<persia> Also, mixxx in hardy is currently 1.6.0~beta1-1ubuntu2: it looks to me like your changelog lost sync with development at some point.  Perhaps it's worth a check?
<asantoni> and we do packaging for Windows and OS X as well (so it adds up)
<asantoni> persia: I pushed the changes that were in that hardy version into upstream
<sistpoty> persia: since you advocated extremetuxrace, I assume that you've checked the orig.tar.gz? (then I won't do the check again *g*)
<persia> sistpoty: Err.  I'm guilty today.  Let me check again...
<persia> sistpoty: Yep.  orig.tar.gz is clean.
<sistpoty> persia: heh, np... I'll just download the orig.tar again
<sistpoty> ah thanks
 * persia checked the last version, but forgot to doublecheck the md5sum for the updated version
<asantoni> ah crap, I can't attach the diff.gz, I'm at my parents for the weekend :/
<asantoni> I've just linked to it
<persia> asantoni: Perhaps a different question: is there a newer version than 1.6.0 beta1 out?  If not, we've that already in hardy, so perhaps you don't need to update?
<asantoni> persia: Yes, we just released beta2
<asantoni> and we absolutely DO need the update - beta1 has some critical stability issues
<asantoni> (I really don't want to screw our users over)
<persia> asantoni: Completely understood.
<asantoni> thanks
<rhpot1991_laptop> does anyone know how I include a file with a space into debian/docs?
<asantoni> (I didn't even intend for beta1 to get into Universe. It was packaged by someone non-official in Debian, and got slurped up through that)
<rhpot1991_laptop> I tried \ before the space and 's around the name, both failed
<persia> Anyone have a some time to review the updated mixxx, take care of LP bug cleanup, and submit a diff.gz to help asantoni?
<sistpoty> rhpot1991_laptop: though I'm no perl expert (dh_installdocs is perl), I guess just putting the name with spaces in there might eventually do it
<rhpot1991_laptop> tried that too actually
<rhpot1991_laptop> though you give me an idea
<asantoni> persia: so is something like this correct? http://pastebin.ca/898098
<asantoni> and will Launchpad automatically close those bugs for me then?
<sistpoty> asantoni: iirc you'll need a # before the bug number (as in LP: #number)
<sistpoty> asantoni: if you build the source package (i.e. generate a changes file), the changes file should have s.th. like "launchpad-bugs-fixed: number, number, .." in there
<persia> asantoni: Looking at some of these bugs, it appears they were closed long ago.  In general, I'd prefer something like "Updated playlist handling (LP: #122476)", but in this case, you might just want to ignore some of them (e.g. 75037 may not even be a bug in mixxx).
<asantoni> I feel like I may not be able to figure all of this out
<asantoni> In a perfect world, I just want to say "New upstream release" , and close the bugs that I know this fixes, lol
<asantoni> ok, so I'll look at the changes files though to make sure this changelog works
<persia> asantoni: Thanks for trying.  If you get stuck, just ask here for someone to take over bug #190589 to get it in.
<ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Undecided,New] https://launchpad.net/bugs/190589
<asantoni> ok, thank you very much persia, I'll try my best
<RAOF> Right.  Let's see if this only-somewhat-uuuuurgly multi-arch alsa-plugins builds right.
<RAOF> It's alive!  It's _alive_!
<sistpoty> hm?
<sistpoty> self-modifying code? *g*
<RAOF> I can now build lib32asound2-plugins in a less than totally evil way.
<sistpoty> excellent!
<RAOF> And if I had access to any of the other archs, it should build lib64asound2-plugins, too.
<RAOF> Oh, I suppose I should build it under Sid, too.
<RAOF> Pulseaudio support for wine is now mine!
<sistpoty> RAOF: maybe ubuntuwire has an arch you could need? (not too sure for which arches we have servers, I only know of sparky, which shouldn't be used for building, because then revu goes down *g*)
 * RAOF actually *looks* at debian/control.
<RAOF> So, I should be able to test the build at least; it'll build lib64foo on i386, powerpc sparc and s390
 * RAOF checks whether he's got an i386 sid build environment
<sistpoty> asantoni: sorry for the delay, I'm just looking at the .diff.gz... seems like you dropped changelog entries from the current hardy version in debian/changelog
<sistpoty> asantoni: also, please describe your changes in debian/changelog (e.g. what patches you dropped, what build-dependencies you updated etc.)
<bddebian> I think I've finally figured it out.  I think MOTU generally has a better sense of humor than Debian. :-)
<sistpoty> heh
<bddebian> I'm serious, it's kind of sad.
<sistpoty> bddebian: btw.: why aren't you a DD yet, seeing so many qa or games uploads from you?
<sistpoty> (then I could ask you for sponsoring debian uploads *g*)
<bddebian> heh
<bddebian> I dunno man, I'm starting to think I should withdraw my app
<bddebian> And go back strictly to Ubuntu
<persia> bddebian: No point withdrawing the application.  Even if you focus on Ubuntu, DD can be useful.
<sistpoty> strange enough, I'm even further below in the nm list than bddebian, and feel guilty, since I didn't do anything but bug forwarding since quite some time
<bddebian> I don't know, maybe it's because I'm some "evil American" or something, I just don't get the "culture".   Everyone takes everything so damn seriously, yet pukes like are can spout nothing but useless drivel all day long..
<sistpoty> (maybe the caveats of FIFO *g*)
<bddebian> s/are/ari/
<sistpoty> heh, /me is reminded by some of Reinhard's postings to debian-devel, which are much less forgiving (dunno the right word) than to ubuntu mailing lists *g*
<sistpoty> asantoni: can you run lintian on the resulting debs? should give you some hints on what still needs fixing
<Legendario> good evening. i would like to see if someone could gimme some help
<LucidFox> I got up expecting some Ubuntu mail, and all I got were notifications of spam in my blog :(
<bddebian> sistpoty: Farther up the list how?
<Legendario> how to pack a package without a make file?
<sistpoty> bddebian: https://nm.debian.org/nmlist.php
<bddebian> Legendario: Just build the way upstream builds
<LucidFox> Legendario> What build system does it use?
<bddebian> sistpoty: Isn't that just alphabetical?
<Legendario> when, i don't know if i understood the question, but the tar.bz2 file the author offers has already a binary in it...
<sistpoty> bddebian: doesn't seem like it... at least not to my known alphabet *g*
<bddebian> Well I never looked that closely :-)
<sistpoty> heh
<bddebian> Legendario: It shouldn't, that's bad form.  You should build the package from "source"
<bddebian> Of course you can just mv/cp the files around
<Legendario> bddebian, i know, but it only offer an rpm package and one like i've told you
<Legendario> bddebian, but when i ask pbuilder to build it, it says no make file was found.
<bddebian> Kick upstream :-)
<Hobbsee> Legendario: does it claim to be gpl?
<Legendario> bddebian, sure
<Legendario> http://checkgmail.sourceforge.net/#download
 * Fujitsu notes that's already packaged.
<Hobbsee> checkgmail | 1.13-1ubuntu1 | http://archive.ubuntu.com hardy/universe Packages
<Hobbsee> checkgmail | 1.13-1ubuntu1 | http://archive.ubuntu.com hardy/universe Sources
<bddebian> Yeah, I thought that sounded familiar
<persia> Further, upstream is very active with https://launchpad.net/checkgmail
<persia> Err.  Maybe not any more.  Used to be, but that only has 1.12 and hardy has 1.13
<Legendario> yeah, i want to make a 1.13 gutsy version to place on my PPA
<persia> Legendario: If it works in gutsy, why not just request a backport?
<bddebian> Heya LaserJock
<Legendario> persia, how is it?
<sistpoty> hi LaserJock
<persia> !backports | Legendario
<ubotu> Legendario: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<LaserJock> hi all
<Legendario> persia, it's because the actual 1.12 version on gutsy is not working anymore
<Legendario> hi | LaserJock
<persia> Legendario: That would be a bug, and likely sufficient for an SRU.  Have you reported a bug?  If not, please do so: this ought be fixed for everyone, rather than just in a PPA.
<persia> !sru
<ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<firefly2442> how do I find the standards-version via the commandline again for the control file?
<sistpoty> firefly2442: zless /usr/share/doc/debian-policy/changelog.gz | head -1 | cut -f 2 -d'(' | cut -f 1 -d ')'
<sistpoty> (assuming, you have an up to date hardy installed)
<firefly2442> I'm in gutsy
<sistpoty> firefly2442: then look at http://www.debian.org/doc/debian-policy/, version (at the bottom of the page)
<firefly2442> thanks
<LaserJock> sistpoty: apt-cache show debian-policy | grep Version: ?
<sistpoty> LaserJock: heh, my command is much longer, and hence more geeky *g*
<LaserJock> I'll give you that
<Legendario> persia, ok. thanks for the explanation. I got to understand all the stuff about the backports and sru. But one thing still intriges me: I have downloaded the orig.tar.bz2 file on from the hardy repository and it is exclaty the same one i have and it does not contain the source. I contais the same binary on it
<Legendario> how could it be packed?
<sistpoty> Legendario: if it is gpl, then it must contain the sources (or include a document which points to the sources)
<squentin> Legendario: it's a perl script, there is no difference between source and executable
<Legendario> squentin, so if i uncomment the perl line on the debian/rules script i should be able to package it?
<squentin> Legendario: you just have to copy the perl file to its right place, dh_perl will just calculate perl dependencies, it won't install anything
<firefly2442> how do I create these "postinst and prerm" from scratch?
<Legendario> squentin, what place would it supposed to be?
<squentin> /usr/bin/ I think
<bddebian> Ah well this cold/flu is finally catching up to me, gnight folks
<squentin> Legendario: btw, there is already a package in ubuntu, so you should start from it
<Legendario> squentin, i have downloaded it. Is that what you mean?
<squentin> Legendario: well, the latest is already in hardy
<Legendario> squentin, well i know it now, and there is already a bug asking to backport it. [Bug #189795]
<ubotu> Launchpad bug 189795 in checkgmail "[Backport] CheckGmail 1.13-1ubuntu1 to Gutsy" [Undecided,New] https://launchpad.net/bugs/189795
<Legendario> but now i am only interested on learning how to pack something that does not have a make file just like this package
<squentin> well you can look at this package to see how it's done
<sistpoty> Legendario: basically it's just a copy the files in debian/rules. however for some languages, there exist specific policies (e.g. python, perl)
<jdong> Legendario: do you know of the scale of the changes required to fix Gutsy's version?
<squentin> a make file is not magical, instead of calling the makefile, you just copy the needed files
<jdong> how DARE you!
<jdong> a makefile is magic!
<jdong> 100% magic.
<Legendario> jdong, i guess the new 1.13 version corrects it
<squentin> :)
<jdong> automake is.... err.... that really subpar harry potter novel.
<jdong> the 2nd one.
<jdong> Legendario: well... yeah... but how big were teh changes that actually corrected it?
<squentin> the package is simple, there is only a few file, only the perl file is important
<jdong> Legendario: I'd like to consider it for the -updates repo if at all possible
<Legendario> this is something i can't tell you. But i consider yours a good idea
<squentin> it doesn't work at all with the 0.12 version ?
<squentin> 1.12
<Legendario> squentin, no. it stopped to work about a month ago
<Legendario> sistpoty, but how does it go on the rules file itself?
<Legendario> squentin, it used to work very well until then
<squentin> sounds like a good reason to put it in updates
<sistpoty> Legendario: debian/rules is just a makefile, which has a few specific targets. basically, the binary target must ensure that a complete package falls out
<sistpoty> Legendario: to do so, e.g. debhelper can be used (there are various dh_* calls, that make creating a .deb easier)
<sistpoty> Legendario: usually you install everything that should go into the deb package in an install rule in there (and could do a cp there)
<sistpoty> Legendario: which of course must be aligned to the debhelper calls, that build the binary (not too sure which dh_ call it is, but one expects all files to install under debian/<binarypackagename>
<sistpoty> (imo it was dh_installdeb)
<Legendario> sistpoty, what does imo mean...?
<sistpoty> hm... where should I start... maybe we'll look at the current hardy package, ok?
<squentin> imo=In my opinion
<sistpoty> Legendario: if you look at debian/rules there, binary depends on binary-indep, which depends on install
<sistpoty> Legendario: so install will basically install all files that should be part of the debian package inside debian/checkgmail (relative from the top source dir of the package)
<sistpoty> Legendario: then later (in the binary-indep target), there are the debhelper commands, to generate a .deb from what's in debian/checkgmail
<sistpoty> Legendario: there's even a cp command in install, to just put a file to the right directory
<sistpoty> Legendario: for each debhelper (dh_*) command, you can look at the manpage what it does
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<Legendario> sistpoty, is it too different if i try with the cdbs?
<sistpoty> Legendario: cdbs will basically only have rules which call debhelper under the hood
<sistpoty> Legendario: which hides some abstraction, but limits your flexibility
<Aloha> under the hood. heh i like that
<sistpoty> Legendario: the problem here is, that a SRU should impose *minimal* changes
<sistpoty> Legendario: so changing from debhelper to cdbs is a no go for an SRU
<persia> Aloha: That looks like an entire comprehensive collection of stuff.  Might it not be a good idea to break it down into several binary packages?
<Aloha> persia, what do you mean?
<sistpoty> Legendario: the best try for an sru, is to look which minimal changes are needed of the source, and to apply these... you should be able to explain every changed line
<persia> Aloha: There seem to be daemons, pam bits, guis, etc.  Seems like a lot of different things in a single package.  On the other hand, maybe that's the right way to do it (I'm not an expert when it comes to those things).
<sistpoty> (otherwise it wouldn't be a valid sru, but maybe things changed nowadays)
<persia> No, it's still minimal changes preferred.
<sistpoty> heh
<Aloha> persia, thats the way upstream put it together.
<Aloha> persia, they have the most odd build system
<persia> Aloha: The oddities of the build system, and the nature of the included docs is what made me think breaking it into a number of smaller binary packages (from one source package) might be best.
<Legendario> sistpoty, i guess i am not the best person to tell u the reason "for every changed line"
<Legendario> i do no programing.... ;-(
<Legendario> i am just a computer enthusiastic who wants to contribute with the community by making some basic packaging and increasing his knowledge a little bit...
<sistpoty> Legendario: there's still the option to request a backport... jdong should now the procedure ;)
<Legendario> but in this case of packaging scripts, i am complitely lost
<jdong> sistpoty: well, I'd like for *someone* to try investigating it as a SRU first
<jdong> sistpoty: at least figure out what upstream did exactly to fix the problem
<jdong> sistpoty: considering the current package is basically USELESS, I think we can argue even for a partly invasive SRU.
<jdong> where "invasive" refers to the package's own codebase of course
<sistpoty> jdong: I guess motu-sru should decide on what's appropriate ;)
<ScottK> SRU should be minimal, but minimal to do the job may be large.
<jdong> ScottK: agreed
<ScottK> On Thursday we SRU'ed clamav from 0.88.2 to 0.92 in Dapper because there was no other way.
<ScottK> err ... Friday
<jdong> right. I'm curious about what the fix for this entails. It bugs me when the supported repo version of the package is entirely useless.
<LaserJock> jdong: what package is this?
<jdong> LaserJock: checkgmail
<jdong> bug 189795
<ubotu> Launchpad bug 189795 in checkgmail "[Backport] CheckGmail 1.13-1ubuntu1 to Gutsy" [Undecided,New] https://launchpad.net/bugs/189795
<jdong> classic gmail-changed-api-so-scraper-doesn't-work.
 * sistpoty just wanted to express that I don't want to make a decision if a backport or sru is right *g*
<squentin> I took a quick look at the diff, there is lot of small changes, most of them probably unrelated to the fix
<jdong> sistpoty: so you're dragging me into this? :D
<sistpoty> jdong: sure... or anyone else wanting to jump in :P
<LaserJock> if it's a fairly clean patch I think an SRU would most likely be appropriate, if it's gonna be useless it's pretty low risk to attempt a fix
<jdong> LaserJock: right, and I doubt anything that is involved with the fix can blow up any other chunk of universe either.
<jdong> At this point, my thinking is, if checkgmail can't check gmail, it can't get much worse.
<LaserJock> :-)
<LucidFox> Is there some program to access Gmail directly without using POP3/IMAP?
<LucidFox> (Apart from a web browser :p)
<sistpoty> persia: whysynth rejected, sorry
 * persia goes to investigate why, and considers fixing it directly
<sistpoty> persia: changing source license in packaging
<sistpoty> (didn't check further than that though)
<persia> sistpoty: Upstream doesn't want to release a new version right now, but has tracked down all the patch contributors and gotten them to agree to the PD dedication.  Any suggestions?  Without this, midi won't work in hardy again.
<jdong> LucidFox: this thing I believe scrapes basically html gmail
<jdong> LucidFox: but other than that, there is no other Gmail API publically published
<sistpoty> persia: update debian/copyright with pointers instead, maybe even include mail messages in there
<asantoni> Ok, someone help me here
<LucidFox> :(
<persia> sistpoty: Makes sense.  I'll fix that.  No other issues?
<asantoni> I've got a workflow problem with this DEB thing
<persia> jdong: I think it gets it from the atom feed.
<persia> asantoni: Where are you?
<sistpoty> persia: as I wrote, I stop checking then.. but I can do a more thorough check if you want
<jdong> persia: ah, ok, that sounds much more reasonable :)
<asantoni> We've got targets in our SCONS setup to build packages for every platform
<asantoni> (Windows, OS X, and Ubuntu)
<asantoni> every time we do a release, I update our Ubuntu package, which we host on our own site
<persia> sistpoty: If you would.  I'll sort out the licensing, but I'm very interested in getting this in for hardy so that we can undisable the gstreamer-midi build.
<asantoni> so we have our own "debian" directory that sits in our source tree, which contains our own changelog
<sistpoty> persia: sure, will do
<persia> sistpoty: Thanks.
<sistpoty> persia: I won't do a complete license check then ;)
<asantoni> so now I'm trying to figure out what the best way to deal with having to merge the universe package's changelog with my own
<asantoni> all of the patches to our package in universe have been pushed upstream
<persia> sistpoty: I think the only issue is with the patches: I looked at the other files.  Upstream shipped them without any licensing information.  I'll review again, carefully, before uploading (or getting vemon to upload) a new candidate.
<sistpoty> persia: thanks
<asantoni> but I guess it matters to you guys that the changelog be kept intact (I can understand that)
<sistpoty> asantoni: imo your (upstream-wise) changelog and the ubuntu changelog are two different things... maybe a branch could help?
<asantoni> sistpoty: hmmm, maybe
<persia> asantoni: Officially, upstreams are encouraged not to host a debian/ directory.  Of course, this can make it awkward to create Ubuntu packages external to the repositories.  I'd suggest tracking a separate branch (as sistpoty suggests), and merging.  Maybe pushing the packaging for mixxx into a Vcs could help.
<asantoni> persia: yeah, it's just too awkward
<asantoni> persia: What do you mean by pushing the packaging into a VCS?
<asantoni> (it's already part of our build system, but that's why we need to have our own debian directory)
<asantoni> the thing that really kills me is that people don't push their patches upstream to us
<asantoni> we don't have it nearly as bad as other projects though, so I should hold my tongue
<Legendario> i gotta go now guys.
<persia> asantoni: Hmm.  I was suggesting moving the debian/ directory to somewhere non-upstream, making it accessible to Ubuntu developers (LP is good for this), and then sharing from this.  For getting the patches back, it's a little harder.
<sistpoty> asantoni: technically, it's actually that debian has created a fork, and ubuntu has created a fork of that fork. however debian realigns (rebases?) every file not under debian/* to the new upstream version.. and ubuntu tries to rebase everything to the new debian fork if possible
<asantoni> persia: any specific ideas for where this debian directory should go? I've never seen this problem addressed before, but it's making this impossible to streamline
<asantoni> (I think it'd be a great idea for you Ubuntu guys as well as our dev team to be able to modify it somewhere)
<persia> The general recommendation is to work with a maintainer to ensure that the latest versions are available.  There could likely be better coordination between Ubuntu and Debian, but I'd suggest coordinating with the Debian maintainer to seek things up to date, and then syncing Ubuntu from Debian.
<persia> Does anyone have a good example of a Vcs managed package for asantoni to review as a model?
<asantoni> persia: Yes, I haven't been in contact with Free Ekanayaka (Debian) maintainer... I should though
<persia> I thought it was Paul Brossier.  Likely my mistake.
<asantoni> it used to be
<asantoni> at some time in the past
<asantoni> but on Debian the package was unmaintained for at least the last two years
<asantoni> Free just kind of showed up out of the blue recently, and has never been in contact with us
<persia> Ah.  The "used to be" is a common cause of the beginning of confusion.  If Free is taking over, that's the best way to keep things up to date.  Free tends to be very good about making things work for both Debian and Ubuntu.
<asantoni> Ok, I'll write him an email right now to try to sort this out
<persia> asantoni: Thanks a lot.  If it takes a while, feel free to come back here, and we'll try to sort you.  The goal is to find a process that works well in the future, but maybe this time shortcuts would not be inappropriate.
<asantoni> no, thank you persia - you MOTU have a generous amount of patience, and I appreciate your help. :)
<sistpoty> persia: more comments to whysynth
<persia> sistpoty: Thank you.
<sistpoty> np
<sistpoty> persia: in general, it looks pretty good :)
<persia> sistpoty: SONAME is so that when gstreamer-midi gets built against it, we can track transitions sanely.  Maybe it belongs in /usr/lib?
<sistpoty> persia: it's a plugin for gstreamer, right?
<persia> sistpoty: whysynth is a DSSI plugin.  gstreamer can build against it, so that gstreamer-midi calls out to whysynth to render sounds.
<sistpoty> persia: does gstream link against it then? or will it dlopen it?
<sistpoty> +er
 * persia looks into the gstreamer-midi source to try to answer that
<sistpoty> persia: if it will just dlopen (my guess for a plugin), /usr/lib/<packagename> should be right, (even if it has a SONAME)
<sistpoty> otherwise (to link against it), there must be some headers to include (of course very ugly workarounds to define the headers -- basically what dlopen does exists)
 * Hobbsee test out gweled
<persia> sistpoty: Nevermind.  Thanks for making me check.  I confused wildmidi with whysynth for some reason.  It's dlopen(), but I need to package something else in a hurry :)
<sistpoty> heh, /me just remembered a different dssi-plugin from very long ago which seemed to also get dlopen'ed *g*
<Hobbsee> yay, it works
<sistpoty> Hobbsee: ?
<persia> Hobbsee: music as well?
<Hobbsee> persia: yeah
<sistpoty> oh, cool... btw.: will there be a gstreamer-sid plugin as well (listening to 8bit sound the whole night)
<asantoni> :D
 * persia cheers effie_jayx for clearing all the bugs from such a lonely package
<asantoni> gahhh, Free made the Debian package use our old icon :S
<persia> sistpoty: Not on my list of things to do by Wednesday.  Feel free to add it if you have time :)
<sistpoty> heh
<persia> asantoni: patches to the BTS are generally welcome.  Upstream .desktop files even moreso.
<asantoni> heh, we do have an upstream .desktop file
<asantoni> which is even more confusing
<persia> asantoni: So the upstream .desktop file is being patched to use the old icon?  Very odd.  Maybe submitting a 32x32 xpm for the menu file would help.
<asantoni> persia: I think he patched the debian/mixxx.desktop
<asantoni> so it appears we have two upstream mixxx.desktop files, which neither of us noticed before
<asantoni> lol
 * ScottK notes torque is now looking for a second advocate.
<persia> Ah.  That's one of the arguments against upstream debian/ :)
<asantoni> haha
<asantoni> :)
<asantoni> point taken
<asantoni> any hints on how I should tell our rules file to use the mixxx.desktop file in our "src" directory?
 * squentin wonders if someone will review/sponsor bug #156886 before the feature freeze (it's just a simple update)
<ubotu> Launchpad bug 156886 in libgtk2-trayicon-perl "Transparency not working with Gtk2::TrayIcon" [Low,Confirmed] https://launchpad.net/bugs/156886
<ScottK> squentin: Without looking at the bug, that doesn't sound like something that needs to be done before FF.
<persia> asantoni: Just install it in /usr/share/applications from your normal build system, and remove it from debian/rules
<asantoni> persia: aha, we already install that there! :)
<persia> squentin: That's exactly the sort of bug which we try to address post-feature freeze.  No rush for the deadline, and feel free to fix more like that later in the month and all through March.
<asantoni> so out it goes from the debian/rules
<persia> asantoni: You may also want to delete debian/mixxx.desktop to avoid future confusion.
<squentin> ok, just though it would be easier to get in before the FF, it's basically an upgrade to the latest upstream version
<asantoni> will do
<persia> squentin: Ah.  If that bug is solved by the new upstream, then yes, it is easier to get it in soon.  The right groups are subscribed, so you've a good chance.
<sistpoty> damn, danw is already breaking...
<sistpoty> dawn even
 * sistpoty is off to bed
<sistpoty> gn8 everyone
 * persia thought sistpoty was traveling to be up at this hour
<asantoni> good night!
<squentin> persia: ok thanks
 * ScottK advocates clipper (looking for #2) and heads to bed.
<LucidFox> Is "diff.gz not identical after binary build and clean" a valid objection on REVU?
<persia> It's certainly an odd behaviour.  It should be the same.  Probably worth determining the cause: it may just be that the diff.gz on REVU is dirty, but the packaging is acceptable.
<ScottK> persia: torque and clipper are both packages that I think we want (even if they need a little cleanup after FF).  Please have a look and see if you can manage to advocate either.
 * ScottK going to bed really now.
<persia> ScottK: OK.  Any chance you could look at libini4j-java and libnb-platform7-java?  Last two pieces before netbeans can be pushed.
<ScottK> persia: Not tonight.  Perhaps tomorrow or Monday.
<persia> ScottK: Thanks.
<persia> minghua: If you really want a versioned conflict between falconpl and falcon, wouldn't it be easier to just upload a patched version?
<ScottK> persia: He's not on right now..
<ScottK> Good night.
<persia> ScottK: Yes, and hasn't been whilst sending email :)  good night.
<asantoni> persia: as I'm working on updating all this debian directory stuff, it's becoming much more clear that having it in a separate repository that's accessible to package maintainers would save us a lot of hassle
<persia> asantoni: Check with Free, but I suspect http://svn.debian.org/wsvn/demudi is likely the right place for that.
<asantoni> persia: ah, I see... I wish this sort of stuff was communicated better (a fault of the process perhaps)
<persia> asantoni: Mostly a lack of documentation.  FOSS tends to accumulate developers rather than UI specialists or documentation people :(
<asantoni> haha, that I cannot deny :)
<asantoni> I'll keep that in mind
<persia> asantoni: In this case, unless there is objection from one of the involved parties, I'd think the best workflow would be for your team to have access to the alioth SVN repo, and for Ubuntu to sync from Debian (and interested Ubuntu people to coordination with the Debian Multimedia Team to work in the same SVN).
<asantoni> persia: yes, I think that's reasonable
<asantoni> in the interest of getting Mixxx 1.6.0beta2 into universe before the freeze, I may have to forgo efforts to that end for a bit though
<persia> asantoni: Right.  I'd suggest you first contact Free, and if you can get it there, we pull a sync.  If not, maybe someone here can help you get it it.  Try catching warp10 for the update, if nobody else.
<asantoni> ok, thanks for the tips
<warp10> Good morning
<persia> warp10: Good morning.  asantoni is here representing mixxx upstream, and looking for a bit of help integrating the latest release.  Do you have some time to help with that?
<persia> (or am I confused by reading too many changelogs today?)
<warp10> Heya persia! Sure, I have some time for asantoni's issue.
<paas> Hi, could a MOTU please have a look at my package http://revu.tauware.de/details.py?package=libtuxcap. It's ready for advocation, thanks!
<asantoni> warp10: I'm just trying to sort out and streamline our packaging process a bit more at the moment
<asantoni> I'm going to upload one more attempt at the mixxx package hopefully soon
<warp10> asantoni: great! so you uploaded mixx on revu alread?
<asantoni> warp10: yes, twice
<asantoni> warp10: I've just fixed the things sistpoty pointed out in the comments
<asantoni> lintian (on my machine) says I botched one last thing though:
<asantoni> W: mixxx source: newer-standards-version 3.7.3 (current is 3.7.2)
<asantoni> but it takes about 30 mins to rebuild the package on my machine, and it's getting late (I need to sleep fairly soon)
<warp10> asantoni: don't care too much of that warning. latest standards version is 3.7.3 and linda is not updated (lintian should not raise any warning about that)
<asantoni> warp10: ah, ok, perhaps this package will be good then (I'm uploading as we speak)
<warp10> asantoni: if lintian and linda don't show anything else, and you addressed all sistpoty comments, looks like you are close to get an advocacy! :)
<asantoni> warp10: thank you, updated package is uploaded: http://revu.tauware.de/details.py?package=mixxx
<asantoni> (launchpad bug #190589)
<ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Undecided,New] https://launchpad.net/bugs/190589
<warp10> asantoni: you should update the bug report on launchpad
<asantoni> warp10: the diff.gz?
<warp10> asantoni: assign it to yourself, and set status to "in progress"
<asantoni> warp10: done, thanks
<warp10> asantoni: great. Just the keep Launchpad up-to-date...
<asantoni> warp10: ok, will do
<asantoni> I need to head to bed now though
<asantoni> but the latest upload is there, if anyone has time to review it
<asantoni> thanks again for all of your hard work!
<asantoni> good night!
<warp10> asantoni: Thank you for helping to improve Ubuntu! :)
<rhpot1991_laptop> what is the width limit for a manpage?
<method> What causes cannot change ownership of `debian/readinglist/usr/share/doc/readinglist/changelog.Debian': Operation not permitted after dh_installchangelogs?
<method> Using pbuilder
<warp10> rhpot1991_laptop: should be 80.
<rhpot1991_laptop> figured so, thanks
<method> Has anyone ever seen a problem with permissions on changelog.Debian?
<RAOF> Does anyone here have an {i386,PPC,sparc, s390} sid or hardy build environment and want to test building multiarch alsa-plugins?
<RAOF> PPC64 is also testable!
<method> Anyone know what this is about? install: cannot change ownership of `debian/readinglist/usr/share/doc/readinglist/changelog.Debian': Operation not permitted. I found a thread on Google that mentioned the same problem, but no one replied.
<RAOF> method: Sounds like a problem with your local build system (pbuilder or whatever).
<method> RAOF, yeah I'm using pbuilder
<RAOF> method: You'll need to provide more information for me to provide a more useful answer.
<method> RAOF, it's in dh_installchangelogs
<RAOF> So, "operation not permitted" suggests that the pbuilder process doesn't have sufficient privs to chmod (unlikely) or that the device you're building on doesn't support chmodding.
<RAOF> Where is your /tmp?
<method> Hmm...
<method> \/tmp is /tmp?
<method> (Might not understand the question) :)
<method> pbuilder goes into fakeroot.
<method> This is pbuilder on Hardy, btw.
<RAOF> Last time I used it (some time ago), pbuilder was building stuff in /tmp.
<method> RAOF, yes, it is.
<RAOF> Right.  So /tmp is on what sort of device?  What sort of FS?
<method> RAOF, should just be part of the same EXT3
<RAOF> Is something doing strange things to the permissions above there?
<method> Do you know what green highlighting in the ls -la means?
<method> . is green.
<method> tmp is, yeah.
<method> tmp is drwxrwxrwt, anyway.
<RAOF> Right.  That's the sticky bit.  I don't think it should be a problem, though.
<method> RAOF, it's the same behavior when I run ./debian/rules install, without sudo.
<RAOF> How about fakeroot debian/rules install?
<method> RAOF, yeah that worked.
<RAOF> method: So, it seems that pbuilder is sucking in some way.
<RAOF> method: Does a plain dpkg-buildpackage -rfakeroot work?
<method> RAOF, no!
<RAOF> method: So it seems that something done by building kills it.
<method> RAOF, or -rfakeroot isn't working properly.
<RAOF> Possibly.
<method> sudo dpkg-buildpackage -rfakeroot works
<emgent> heya people
<RAOF> Heh.  sudo trumps fakeroot, I'd guess :).
<RAOF> emgent: You look like someone with an i386 hardy build environment!  Care to try building my multi-arch alsa-plugins?
<method> RAOF, I have one.
<emgent> RAOF, not now, sorry :)
<DarkMageZ> i've got one as well
<RAOF> DarkMageZ: You don't happen to have a sid one as well?
<DarkMageZ> nope. don't play with debian.
<RAOF> Right, anyway, http://cooperteam.net/alsa-plugins_1.0.15-2.dsc should be dgettable.
<RAOF> Build away my minions!
<DarkMageZ> dget ?
<RAOF> Gets the dsc & all the files referenced in it.
<RAOF> You will learn to love it :)
<DarkMageZ> i already now love it
<DarkMageZ> and here was me using wget to get all 3 files...
<RAOF> dget -x is download & unpack with dpkg-source, too.
<DarkMageZ> build started
<RAOF> Hm.  It suddenly occurs to me that ia32-libs is unlikely to exist on PPC64.
<method> dpkg-checkbuilddeps: Unmet build dependencies: lib64asound2-dev (>= 1.0.12) libpulse-dev libsamplerate0-dev | libsamplerate-dev libavcodec-dev ia64-libs libc6-dev-amd64 lib64gcc1 gcc-multilib
<RAOF> Ok, that's what I was afraid of.
<RAOF> We don't build 64bit i386 binaries :)
<RAOF> That should work in Sid though, which is the incidental target of this patch.
<RAOF> ls
<RAOF> NO!  My perfect irssi-is-not-a-shell record is ruined!
<persia> So after sistpoty corrected me about the difference between whysynth and wildmidi, I'd like to ask for someone else to take a look at http://revu.ubuntuwire.com/details.py?package=wildmidi .  I'm not 100% sure on the licensing (mixed license in source, re-separated for binary packages), and always like for libraries to have multiple eyes.
<RAOF> persia: I'll trade you.  Build my multiarch alsa-plugins in an i386 sid environment, I'll check wildmidi. :)
<persia> Err.  I don't have an 1386 sid environment :(  Anything else I can trade for?  (I'll make an i386 sid environment if the answer is no)
<RAOF> I'll trade you for a gnome-do & do-plugins check, but I haven't finished those yet. :)
<persia> RAOF: That works for me.  Let me know when they are ready.
<RAOF> Gah!  Stupid mk-sbuild-lv!
<method> do-plugins! Yay!
<RAOF> Now that I've bashed various things into a state where a useful package can be made from them, yes.
<RAOF> dget, you are my only friend in a world filled with copyright problems.
<warp10> MOTUs, my package gbemol (a graphical frontend for MPD) is on REVU and waits for your reviews. http://revu.ubuntuwire.com/details.py?package=gbemol
<emgent> heya warp10
<emgent> persia, ping
<warp10> hi emgent ;)
<persia> Aren't there already a plethora of MPD front-ends in the repos?  What makes this one special?
<persia> emgent: I don't play virtual table tennis
<emgent> O_o
<emgent> lol
<emgent> persia, http://rafb.net/p/T9Mxid83.html
<emgent> it's ok or I should use [...]edgy2 ?
<persia> emgent: No idea.  I'm not a security person.  Ask someone in MOTU-SWAT.  This is a strong argument against pinging specific people when you have a question.
<emgent> i asked to kees now in jabber
<persia> Also, why base a security upload on a backports upload?  That seems odd.
<emgent> but i dont know very well
<emgent> he _THINK_ 1.2.6-0ubuntu1~edgy2
<persia> emgent: This is a good place to ask, I'm just not a good person to ask.  Asking the question to the channel generally will likely get you a good answer.
<emgent> hehe ok, thanks
<warp10> persia: well, this is just the frontend I use. Since it isn't in our repos and has been asked to be packaged on launchpad, I did it.
<persia> Wait, is this security applied to a backport?  That would likely benefit from coordination with the backports team, to push a backport from the -security
<emgent> yes persia
<persia> warp10: OK.  Just checking.  If it was super-cool and nifty, and washed my socks, I'd be tempted to postpone by queue.  As it is, I'll take a look if I do another REVU pass.
<persia> emgent: I'm not part of the backports team either, but I suspect that 1.2.6-0ubuntu1.1~edgy1 is the correct version (new backport).
<warp10> persia: ok, thanks anyway :)
<emgent> i saw https://help.ubuntu.com/community/UbuntuBackports, but there isnt info about it...
<persia> Further, I don't believe that an updated backport belongs in edgy-security, as that would force non-backports users to use the backport.
<persia> emgent: The backports documentation team needs help :)
<emgent> ehhehehe :)
<emgent> u-backports irc room too :P
<HighNo> g'morning eveerybody. I was just reading backporting policy and as I get it know - if my package won't make it into hardy and the next REVU day would be in may - my package can also not be integrated in backports as it has to be in the official universe first. It might even say (though unclear) it has to be in a released versions universe which would delay it even more in backports. Am I right here?
<RAOF> HighNo: Yes to the first, no to the second.  It has to be in Hardy's universe before it can be backported anywhere, but Hardy doesn't need to be released before you can backport it.
<persia> An alternate reading is that once it gets into the universe repository for hardy+1, it can be backported to hardy.
<persia> (which may be three or four weeks after hardy release)
<RAOF> persia: Would you like comments on revu, or here?
<RAOF> Stupid question.  On revu they go.
<persia> RAOF: either works :)  REVU is likely better, as it keeps a record.
<HighNo> *sniff* this takes sooo long - unless someone quickly advocates my package 'blueproximity' of course :-) (sorry, couldn't resist...)
<RAOF> persia: Commented.  Stop trying to close Debian bugs with Ubuntu uploads :)
<emgent> ugh
<persia> HighNo: Simply put, you've missed new package season.  If you check the channel logs, you'll see even MOTU are begging for reviews at this point.
<persia> RAOF: Thanks :)  Also, lintian disagrees with you about = vs. >= ${source:Version}
<RAOF> persia: Fair enough.  This isn't based on an understanding of policy, just what I've seen other library packages do.
<persia> Also, do you expect the archive-admins to have an issue because ./COPYING is only GPL, and most of the source is LGPL?
<persia> The way you recommend is how I did it at first, but it makes it non-bin-NMUable, as the arch:all package wouldn't be able to handle a version bump on a binary.  Not that it really matters in Ubuntu or anything :)
<emgent> uhm
<emgent> http://rafb.net/p/TAIdMy20.html
<emgent> we are exploitable
<RAOF> persia: Oh, sorry: {binary:version}!
<emgent> GRSEC ++
<RAOF> The capitalisation there is incorrect, I think.
<persia> emgent: We are usually exploitable in several different ways.  We typically avoid advertising that whilst working on patches.
<emgent> launchpad bug is open
<persia> RAOF: /usr/share/lintian/checks/version-substvars.desc says ${source:Version}
<emgent> debian people too working on this
<persia> Err..  ${binary:Version}
<RAOF> GAH!  Why must mk-sbuild-lv take so long to FAIL?
<RAOF> Bah!  That patch can get sent without i386 testing.  It *should* work.
<persia> RAOF: Once you have the majority set up, it may be easier to do it manually.  Just add a stanza to schroot.conf, add a LV, and debootstrap.
<RAOF> Yeah, possibly.
<HighNo> persia: yes, I know. I am just sad, because I didn't know before and worked very hard as someone told me FF is on 14th, so I've had the hope. The information that it packaging is over came later on when I was almost done with the package. This is of course no offense to anybody, you guys work hard and do a great job. Good thing is I can create a new nicer upstream package with more languages supported.
<HighNo> I know that packaging is faster once a package is in debian, but does also debian packaging get faster if one makes it into ubuntu?
<persia> HighNo: I suggest you see if you can find out who typically handles the bluetooth stuff.  They may be very interested, and try to push it through.
<RAOF> HighNo: It doesn't, except that you've already got a (presumably) archive-worthy package available.
<persia> Ideally, packaging is only done once, for either Debian or Ubuntu.  After that, it is either a sync, or maybe small bugfix-type changes.
<RAOF> HighNo: And the work you've done need not be wasted; you can get the package into Debian, they don't usually bite off people's heads.
<HighNo> RAOF: hehe, that's what I thought too. I was just wondering if there's a two way road between the both
<RAOF> HighNo: There's not nearly as much Ubuntu->Debian traffic as the other way around.  Partially because there are *lots* of Debian maintainers.
<persia> Depends on the package.  I see lots of Ubuntu->Debian traffic, of various sorts.
<RAOF> Oh, certainly.
<persia> There's just no automated upload of Ubuntu updates for things not recently updated in Debian :)
<HighNo> persia: (and anybody else) ho you know who is into bluetooth among the MOTUs? Are there MOTUs especially for the UbuntuMobile thingy?
<RAOF> Yes.  There is no UbuntuImportFreeze :)
<RAOF> Anyway.  Time to do a Gnome-Do release so I can package it and hurl it at persia with high velocity!
 * persia dons the appropriate protective equipment
<persia> Well, rather, there is a constant UbuntuImportFreeze: everything is by manual action.
<RAOF> Do is a fine way to discover bugs in Metacity's compositor.
<RAOF> Right.
<RAOF> For example: in some (rare) instances triggering Do will make every window with an ARGB pixmap disappear (including Do) until Do is hidden.  It's fun.
<persia> RAOF: And this is something you want to add to the repos?
<RAOF> persia: Works fine with Compiz.  It's a metacity bug.
<RAOF> Or with xcompmgr, for that matter.
<RAOF> I don't imagine many people have metacity's compositor turned on.
<persia> Well, me, but my system is not exactly standard :)
<RAOF> Me too, obviously.
<RAOF> I want shiny composite eye-candy & don't Compiz because I test nouveau.  What's your excuse? :P
<persia> RAOF: My case has insufficient airflow for my GPU
<RAOF> Whoops.
<persia> Works OK in the winter, but better to not run compiz than have lockups on warm days.
<RAOF> Oooh, I get to check my watch file handles a new upstream version correctly.  Yay!
<persia> What's best practice when upstream sends a patch to fix licensing stuff and doesn't want to do a new release?
<RAOF> I don't know.  The only time that's happened to me recently, Miro spent a week trying not to link to openssl, then made a new release with the exception clause everywhere.
<persia> RAOF: That would make life easy.  In this case, upstream sent a patch against their release tarball with the changes they want, but didn't want to update the actual release tarball.
<RAOF> Repack?  That seems really ugly, though.
<persia> That's what I thought.  Putting it in debian/patches recently got rejected from REVU because we shouldn't patch licensing though.
<RAOF> Yeah.  Then the source package has a misleading license in it.
<persia> That was the issue.  During packaging it was discovered that some of the licensing for some of the files was unclear.  This was resolved now, but I'm not sure how the resolution should be structured for inclusion.
<RAOF> I think you'll have to repack the tarball, with the licensing patch applied.  The .orig.tar.gz has to have the right licensing, yes?
<persia> I guess.  Perhaps applying the patch in get-orig-source, although such a construction likely needs a README.Debian-source to explain just how it got that way.  Thanks.
<RAOF> That would work, yes.
<RAOF> Why did I think Sid had an ia64-libs package?
<persia> Does anyone know anything about a libgmyth-dev package?
<persia> superm1: gst-plugins-bad0.10 FTBFS for me.  Any suggestions on how to fix that?
<jpatrick> persia: W: Unable to locate package libgmyth-dev
<RAOF> persia: It's a new build-dep of plugins-bad, to allow gstreamer apps to connect to mythtv hosts.
<persia> jpatrick: That was my experience.  Which arch?
<RAOF> It'll be sitting somewhere in NEW right now...
<persia> RAOF: Why can't I find it in apt-cache?
 * persia grumbles that one last-minute update to gst-plugins-bad0.10 is colliding against another and hunts NEW
<RAOF> https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=gmyth
<jpatrick> persia: x86
<persia> RAOF: registration block :p
<persia> jpatrick: Thanks.  That means it's definitely caught somewhere.
<emgent> Hobbsee, can i work to fbi package ?
<\sh> moins
<\sh> does anyone know the replacement binary for `arch` from util-linux?
<persia> \sh: What did it do?
<\sh> persia, printing out the real architecture ;)
<\sh> persia, yes...it's wrong
<persia> \sh: Ah.  Don't know then, sorry.  /proc/cpuinfo might have some of what you want.
<HighNo> uname -m ?
<persia> HighNo: That only checks what kernel is installed
<HighNo> true
<HighNo> would arch really do something different?
<persia> HighNo: Ideally, it would check the CPU, and report something else when e.g. running i386 on amd64 hardware.
<persia> (and yes, it is wrong)
<emgent> jdong, ping
<persia> emgent: It's not just for me.  You'll always get a better, faster answer when you ask a question than when you ping someone.
<\sh> persia, well, the problem is...arch would give me e.g. i686 on pentium and not i386 as dpkg-architecture ;)
<persia> \sh: You want the dpkg-architecture?  That's entirely different.
<\sh> persia, no :) I need `arch` ;) I'm trying to build cinelerra...
<HighNo> hal-device  | grep i686  wold only give what the kernel is built for or does it check the real thing?
 * persia hides from cinelerra
<\sh> bah...cinelerra is totally wrong with its usage of arch
<persia> Grr..  The gmyth-dev addition to gst-plugins-bad0.10 causes it to FTBFS, and 01_gmyth_configure.patch breaks build-twice-in-a-row :(
<RAOF> Alright.  Any idea why dh_clideps would be throwing me a warning about no build-dep(-indep) on cli-common-dev when I *have* a build-dep-indep on cli-common-dev?
<persia> RAOF: dh_clideps?
<persia> RAOF: Do you build-dep-indep on "cli-common-dev \(>= 0\.4\.4\)".  It seems to want the version (at least from my reading of the source: I haven't done any Mono packaging)
<persia> Well, actually, that should be unescaped, but still.
<RAOF> I build-dep-indep on c-c-d (>= 0.5.4).  There's some newer stuff I want.
<RAOF> But that's as much time as I can give it tonight.
<persia> RAOF: File a bug :)
<mok0> DaveMorris: you've been doing a great job helping HighNo getting blueproximity sorted out
<HighNo> ture
<HighNo> true
<mok0> Hi HighNo
<HighNo> hi mok0
<mok0> HighNo: I saw you managed to get at least 1 MOTU to lookt at it!
<HighNo> mok0: i did?
<mok0> Yep. Those are the guys with the fancy icons on REVU
<HighNo> mok0: might be michael - sadly their irc names don't pop up there
<HighNo> mok0: ahh, that's that the icon is for
<mok0> HighNo: yeah.
<persia> HighNo: You can usually get IRC <-> email translation from https://launchpad.net/people
<HighNo> mok0: ok, thanks. Anyway I learned it wouldn't help anyway. There's no way to make it into hardy now
<mok0> HighNo: It's from the orig. cartoon "He-man and Masters of the Universe" :-)
<mok0> HighNo: They are still working to get processed as much as possible before the hard freeze
<HighNo> mok0: aaaah, hehe - cool.
<mok0> HighNo: you are right, it would be nice if people's nicks were also mentioned on revu
<HighNo> mok0: so launchpad would be eternia :-)
<HighNo> mok0: acutally i liked that series a lot and watched many episodes - too many as i can still know the intro song by heart
<mok0> HighNo: hehe, it's been a while since I've seen them on tele.
<mok0> HighNo: http://www.he-man.org/cartoon/cmotu/index.shtml
<mok0> That must be a site for you :-)
<HighNo> mok0: yes - it's been a while. thanks for indirectly mention I am an old guy :-) (31 that is)  btw, just dropped a blueprint in launchpad for adding the irc names
<DaveMorris> HighNo: it might not make it in, but a.) you've fixed the bugs on hardy. b.) You've improved the packaging etc, which can be applied to your PPA's
<DaveMorris> 31, a bit older than me ;)
<mok0> HighNo: I'm older than you :-)
<HighNo> DaveMorris: that's true too. I also started a translation session so it would come in > 10 languages. (I think I got the most people if jp and ch will finally be added) I have 8 so far :-)
 * mok0 wonders in "Masters of the Universe" is a registered trademark...
<mok0> DaveMorris: Remind me, what is your package?
<HighNo> DaveMorris: And I will at least try to use the launchpad project infrastructure more so translations could be made via rosetta
<DaveMorris> http://revu.tauware.de/details.py?package=gtkglextmm is the current one needing review
<HighNo> mok0: it s a registered trademark afaik
<mok0> I guess they haven't heard of Ubuntu Universe's MOTUs...
 * persia notes that in the jurisdiction in which that trademark is registered, trademarks are only valid for a specific line of business.
<persia> Software Development being different than either "entertainment" or "toys", it would take significant work to justify a complaint.
<DaveMorris> so as long as we don't start selling dolls of the various MOTU's ;)
<HighNo> mok0: http://tess2.uspto.gov/bin/showfield?f=toc&state=1n9h70.1.1&p_search=searchss&p_L=50&BackReference=&p_plural=yes&p_s_PARA1=&p_tagrepl%7E%3A=PARA1%24LD&expr=PARA1+AND+PARA2&p_s_PARA2=masters+of+the+universe&p_tagrepl%7E%3A=PARA2%24COMB&p_op_ALL=AND&a_default=search&a_search=Submit+Query&a_search=Submit+Query
<mok0> DaveMorris: lol
<mok0> HighNo: that's hilarious...
 * DaveMorris thinks of voodoo dolls of motu's to get his packaged reviewed :)
<mok0> DaveMorris: looks like yours is getting close
<HighNo> persia: they registered it for computer game software too - let's not talk of games here :-)
<DaveMorris> mok0: yeah, I only picked up Friday night when I realised the previous guy gave up
<mok0> DaveMorris: great! There is a lot of good stuff sitting in the queue
 * HighNo remarks that you also should not explicitly create toothbrushes  - they are registered too :-)
<DaveMorris> HighNo: can your program handle different devices with different actions for the devices?
<mok0> HighNo: Of course, MOTU means: Meisters of the Universe...
<mok0> ... or Misters if you will...
<HighNo> DaveMorris: I was thinking of it. It already can with a hack - run it multiple times with different config files - but that's dirty. I think there is already a blueprint - written by me for doing that
<HighNo> mok0: hehe
<HighNo> DaveMorris: you have more than one boss? :-)
<DaveMorris> yeah, I work in a Uni
<mok0> HighNo: although I think we can aggree that they are sometimes "Monsters of the Universe"... ;-)
<DaveMorris> got my linemanager and the dean.  I report to them both really
<HighNo> DaveMorris: Now if you were a MOTU I would make a deal... But this way, I'll have to see what I can do here. There are some points I have to check first to get that done. Like how to efficiently store/read multiple entries with configObj, how to make a simple config dialogue without having a new window pop up for every config and stuff like that. the backend is not really ready for that but can be changed without big problems. Let's put t
<jpatrick> win 33
<jpatrick> with "/" this time irssi ;)
<HighNo> mok0: see how elegantly I covered your back by not going into you being even older than me? :-)
<mok0> HighNo: A true gentleman
 * DaveMorris needs to learn more before been a MOTU
 * HighNo pads DaveMorris on the back and tells him gently "then learn - but do it FAST!" :-)
<mok0> Have you been following effie_jayx's progress on the wiki?
<chazco> Hi... can anyone tell me if Truecrypt 5 is planned to go into any of the repos?
<effie_jayx> mok0, ?
<hellboy195> effie_jayx: now you are famous ^^
<mok0> effie_jayx: I was asking HighNo and DaveMorris if they'd been following your progress
<effie_jayx> hellboy195,  oh dear...
<effie_jayx> I only hope I can live up to it
<mok0> effie_jayx:It can develop into a true motu program that others can use
<DaveMorris> If thats the one syndicacted on one of the ubuntu planets then yeah
 * effie_jayx is currently trying to upgrade a package that has "dead end" written all over it
<DaveMorris> is there a checklist of the various things you need to learn to know your at a `certain level'
<mok0> effie_jayx: what's wrong with it?
<mok0> effie_jayx: it upstream has abandoned it, I would skip
<HighNo> mok0: oh, i didn't know I was meant by that question - the answer would be no
<effie_jayx> mok0,  1) orphan, 2) version jumped from 0.1.1 to 0.2.2 without any changelog entries to it
<DaveMorris> do you need it then?
<HighNo> mok0: do i make an idiot of me if i asked what wiki?
<mok0> HighNo: http://wiki.ubuntu.com
<effie_jayx> mok0,  and upstream seems to release a new version when he comes back from war (he is in the military)
<HighNo> mok0: ok, the answer is yes then :-)
<mok0> effie_jayx: yikes. Let's hope he does come back
 * mok0 looks for effie_jayx's motu log
<effie_jayx> mok0,  I have found a way to build the package. but it makes no sense uploading it... upstream is really not makig that software distributable enouh
<HighNo> effie_jayx: what software exactly?
<effie_jayx> kipina
<effie_jayx> mok0, https://wiki.ubuntu.com/EfrainValles/MOTUJourney
<mok0> effie_jayx: I've had that problem with a couple of my packages. Finally, I decided to make my own distribution
<DaveMorris> effie_jayx: email him re your concerns, with suggestions on how it can be improved
<mok0> HighNo: https://wiki.ubuntu.com/EfrainValles/MOTUJourney :-)
<effie_jayx> DaveMorris,  I am not sure his email is still current
<effie_jayx> DaveMorris, I will email him today. thanks
<mok0> effie_jayx: but those kinds of troubles don't help you much in  your quest
<effie_jayx> mok0,  they are real issues though
<mok0> effie_jayx: ok
<effie_jayx> I have a knack for this kinda bugs
<mok0> effie_jayx: hehe
<DaveMorris> I need to learn how to do merges and syncs next cycle, as I've only done new packages this cycle (all libs as well)
<effie_jayx> HighNo, hey are you starting as well ?
<mok0> As late as this morning I was wondering if there's a document that we could point upstreams to, saying how they should organize their distribution to make it easier to get it packaged
<mok0> An Upstream Guide
 * DaveMorris volunteers mok0 to make one :)
<persia> mok0: You could write one?
<effie_jayx> mok0,  it would be interesting to see the reaction
<mok0> I could make something on the wiki, if you all promise to contribute
<DaveMorris> mok0: if you pm the link I can add the problems I've had and the fixes
<mok0> DaveMorris: cool
<persia> Things like distribute as tar.gz, license all the files, provide a flexible build system that allows customised installation, don't build stuff on clean, don't download from the net, etc.
<HighNo> effie_jayx: hehe, starting - yes, as a MOTU - not quite yet. I still try to get my first package into hardy
<persia> mok0: Please post your link here when you get a draft up, so everyone can add :)
 * mok0 goes off to generate a wiki page.
<DaveMorris> have proper clean and dist-clean tagets
<persia> Support translated strings
<effie_jayx> HighNo, well bug fixing is really simple.
<effie_jayx> that's how I have started
<effie_jayx> I am doing and upgrade
<persia> Is anyone familiar with dh_gstscancodecs?  Any ideas on what magic might be required to get the inspection to work properly?
<mok0> Bookmark this: https://wiki.ubuntu.com/UpstreamGuide
<mok0> I will write something when I've thought about it
<HighNo> effie_jayx: I am the upstream author of that particular package so I have special feelings on my package :-) but afterwards - and after my final exams - I will have more time. I'll have to see how things turn out to be after I get my degree. I am willing to support and sometimes do so in the #ubuntu channel. I have answered some questions on answers too. Hey - I am an official Ubuntu Instructor... (Really!)
<effie_jayx> HighNo,  wow :D
<HighNo> btw. Greetings to the Canonical Trainings Crew like the charming Billy Cina and of course Master of Desaster Chris Brown - he led my Train-the-Trainer event in  Stuttgart last year - a cool guy, 3 days of pure fun.
<LucidFox> https://wiki.ubuntu.com/UpstreamGuide <-- not much content, ne? :)
<HighNo> mok0: should we make a list on there with points it should have on it - just to make certain things not forgotten?
<mok0> HighNo: go ahead and put random thoughts. I will organize it later
<HighNo> mok0: fine
<HighNo> ok, wiki updated. That's the first thing I had to learn :-)
<HighNo> oh, btw. does anyone else have this problem? If I update a wiki page on wiki.ubuntu.com it will take a very long time during which firefox is hanging. I may be just my setup but it's quite annoying. Most of the times I kill it and restart firefox - the changes on the wiki page are saved anyway. :-/
<Iulian> HighNo: It happens to me sometimes.
<warp10> Anyone having problems opening qa.ubuntuwire.com?
<Iulian> warp10: Yes
<warp10> Iulian: mmm... too bad. Hope it will be up again ASAP
<Iulian> Indeed.
<shibata> hi all.
<shibata> persia, RainCT, ScottK: thank you for advocating of termlauncher-applet, kita2.
<persia> mok0: If I upload torque, will you keep working on a patch to clean up the manpages for inclusion before hardy release?
<mok0> persia: I did clean the manpages... what are you referring to?
<mok0> persia: there's a fixhyphens patch
<persia> mok0: The latest revision on REVU still gets lots of missing manpages and minus/hyphen issues, on top of your patch.
<mok0> persia: missing manpages I'm aware of. How can I reproduce the minus/hypen issues?
<persia> Everything else is clean, so I'm willing to upload if you're willing to hunt down all the remainders and make sure it's 100% before release.
<mok0> persia: I promise
<persia> All I did was build in a hardy chroot, and run lintian.  Does that not work for you?
<persia> mok0: OK.  Uploading.
<mok0> persia: I don't get any reports on hypens
<LucidFox> When subscribing sponsors to a sync request, should I set it to confirmed?
<persia> mok0: Odd.  I get http://paste.ubuntu.com/4410/
<mok0> LucidFox: I think so. You'd think that Malone was intelligent enought to do a lot of this bookkeeping on its own.
<mok0> persia: hmm. something is fishy
<persia> LucidFox: Please don't.  You are asking for the sponsor to confirm (and yes, LP is annoying about sponsorship: there is a bug)
<mok0> persia: e.g. line 253 should not be there, because I now have an override
<persia> mok0: That's what I thought.  I remembered you fixing them before, and was surprised to see it.  On the other hand, I don't want to review again (it's a large and annoying package).
<mok0> persia: tell me about it
<persia> mok0: You have a linda override?
<mok0> persia: no
<persia> mok0: line 253 is from linda.
<persia> Line 217 is the result of your override
<mok0> persia: right
<mok0> persia: the annoying thing is that the linenumbers given for the man pages are incorrect
<persia> That is indeed annoying
<shibata> About sponsorship process, what should I attach file which is diff between old package and new one instead of InterDiff? Does ".diff.gz" mean "PACKAGENAME_NEWVERSION.diff.gz" which is created by debuild? Or any other file?
<persia> shibata: Is it a new upstream, or just a patch to an existing package?
<shibata> new upstream
<persia> shibata: Please attach PACKAGENAME_NEWVERSION.diff.gz (and yes, I will get around to updating the documentation sometime)
<shibata> persia: thank you.
<mok0> persia: are you using flags to make lintian more picky?
<persia> mok0: Of course.  As picky as I can make it.
<mok0> persia: which ones?
<persia> -iIv
<mok0> persia: Value "v" invalid for option l (number expected)
<persia> mok0: Use 'I' instead of 'l'.
<mok0> persia: Ah :-)
<mok0> persia: Yep, I get those hyphen messages now.
<persia> mok0: Likely be a week or so before the package gets through NEW, but you'll want to have a debdiff ready then.
<mok0> persia: ok, will do
<persia> LucidFox: tovid rejected because it breaks icon themes as well as having manpage issues.  I'd be willing to advocate tomorrow if you can't find two other victims.
<LucidFox> All right, I'll look into it.
<bigon> slomo: no news about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354876 ?
<LucidFox> As for desktop files, is it now a requirement that upstream desktop should be patched if it exists?
<ubotu> Debian bug 354876 in wnpp "ITP: notify-sharp -- CLI bindings for libnotify" [Wishlist,Open]
<LucidFox> for all packages/
<persia> LucidFox: It's best practice to patch what can be patched, rather than creating new files.  This makes it easier to pass back upstream.
<persia> A recent example of what can happen when this isn't done is the .desktop file for mixxx, where upstream had one version, and there was also one in debian/ and upstream was confused as to how the icon was still the old one.
<bigon> could some kubuntu guy have a look at https://bugs.edge.launchpad.net/ubuntu/+source/decibel/+bug/180344 ?
<ubotu> Launchpad bug 180344 in decibel "[FTBFS] decibel (0.5.0+svn737972-2) fails to build in hardy" [Low,Confirmed]
<LucidFox> Debian bug name: "RM: xmms -- RoM; unmaintained" - what does RoM mean?
<persia> Request of Maintainer
<LucidFox> Thanks.
<bigon> gtk1 will be removed from debian before the lenny release I think
<persia> That's the goal.
<LucidFox> persia> As for tovid manpages, upstream generates them in an extremely awkward way, and the sections are non-standard. I'll probably have to remove all upstream manpages in postinstall and provide my own manpages in debian/
<persia> LucidFox: Can you not just force something in docs/src/* to generate the .SH NAME section?
<LucidFox> the manpages are generated with txt2tags, which apparently has no concept of .SH :(
<LucidFox> it inserts .SS Name, .SS Description, etc
<LucidFox> (it's supposed to convert to many different formats, but doesn't do a very good job with this particular format)
<persia> That's truly unfortunate.  If you really can't find a way around it, then such is life.  My main objections were about duplication and the bad .desktop file, but the manpages pushed me from soliciting your promise to asking for another revision.
<persia> If you can find a way to make it work, it would be ideal, of course :)
<tuxmaniac> grr manpages and upstream!!!
<LucidFox> of course, I could patch generated manpages...
<LucidFox> or do sed s/\.SS/\.SH/g
<persia> See, there is usually a solution once you start working on it :)
<ion_> The second parameter is not a regexp. No need to escape dots.
<ScottK> persia: I just advocated clipper.  I forgot to actually push the button last night.
<shibata> persia, ScottK: I reupload poppler-data to modify debian/copyright. pleasee revu: http://revu.tauware.de/details.py?package=poppler-data
<smarter> anyone willing to review my qdevelop package? :) http://revu.ubuntuwire.com/details.py?package=qdevelop
<bddebian> Heya gang
<LucidFox> seconding smarter's request, I would also like to see qdevelop in the archive
<tuxmaniac> can some re-re-review http://revu.tauware.de/details.py?package=alliance. Hope it gets advocated this time around. fingers crossed.
<tuxmaniac> s/some/someone
<tuxmaniac> dinner brb
<superm1> persia, install gmyth
<superm1> which is in NEW
<spectie> can i request importing a package from debian unstable into ubuntu here ?
<spectie> ideally to make the hardy release
<spectie> the package is apertium-dbus
<superm1> spectie, so what you should do is see if the source package builds cleanly on hardy
<superm1> in a pbuilder or sbuild
<superm1> if that's the case, than you can request a "sync"
<spectie> i don't know anyone running hardy
<spectie> i know it doesn't build clean on gutsy
<spectie> as there is a conflict in the dbus versions
<superm1> spectie, well hardy may be a little different
<spectie> the ubuntu one is named 1.1.1+ubuntu3 something
<superm1> that sounds like you were installing the deb
<superm1> not building the source package
<spectie> hmm, perhaps he was
<superm1> eg dsc, diff.gz, orig.tar.gz
<spectie> (i asked a friend to check it)
<spectie> i thought i'd told him to do it from source though ;)
<superm1> spectie, so what you can do is either you or your friend install pbuilder
<superm1> gutsy is fine to install it on
<superm1> and prepare a hardy pbuilder
<spectie> well, i can't as i don't have ubuntu
<superm1> !pbuilder > spectie
<superm1> well its on debian too
<spectie> or i can set up a hardy pbuilder on my deb box ?
<spectie> yes i know
<superm1> yeah you can set up a hardy pbuilder on any box that you install pbuilder on
<spectie> debian or ubuntu?
<spectie> cool i didn't know that
<superm1> several folks here have debian and ubuntu pbuilders setup locally
<superm1> for similar purposes
<superm1> so once you see if that package builds in the hardy pbuilder alright, check back in here and we can teach you how to request the sync, where to file the bug and who to subscribe etc
<dcordero> hi
<superm1> ideally if you can save a build log from the pbuilder that would be good to attach to the bug
<dcordero> hi DktrKranz  ;)
<spectie> superm1, thanks
<crevette> hello
<DktrKranz> hey dcordero :)
<crevette> someone could review 3 Packages I did
<crevette> http://revu.tauware.de/details.py?package=obex-data-server this one is a brand new one
<crevette> http://revu.tauware.de/details.py?package=bluez-gnome
<crevette> http://revu.tauware.de/details.py?package=gnome-bluetooth
<superm1> crevette, for package upgrades, traditionally a bug is filed with u-u-s subscribed
<superm1> rather than using revu for such thing
<superm1> additionally bluez-gnome is in main
<crevette>  u-u-s ?
<superm1> sorry, ubuntu-universe-sponsors
<crevette> okay
<superm1> for bluez-gnome, you would need a core-dev to upload it
<superm1> which not everyone who is a MOTU has core-dev privs
<superm1> so ubuntu-main-sponsors would need to be subscribed
<HighNo> crevette: great - bluetooth packages
<crevette> yeah, I just wanted at least review to know if my package is okay, uploading in aonther question :)
<crevette> HighNo: yes, I packaged the obec-data-server which replace gnom-obex-sebd
<superm1> crevette, i'll take a quick look at obex-data-server and see if anything stands out
<superm1> in the meanwhile, can you file the appropriate bugs for the other two?
<crevette> HighNo: I've have a ppa if you're interested with
<crevette> superm1: thanks, I'll do, the address to suscribe is ubuntu-universe-sponsors@ubuntu.com ?
<superm1> crevette, when you file the bug, click "subscribe someone else"
<superm1> and then just type
<superm1> ubuntu-universe-sponsors
<superm1> and it will resolve it
<crevette> okay, this is not an address
<superm1> nope
<crevette> ocky docky
<HighNo> crevette: that's not my point. I am looking for MOTUs that are into bluetooth to get package advocated
<superm1> HighNo, i've got an apple bluetooth keyboard and mouse.  That's why bluetooth stuff stuck out to me :)
<crevette> superm1: hewww
<crevette> I pass
<crevette> :)
<crevette> I just use it for my phone
<HighNo> superm1: are you a motu?
<superm1> HighNo, yeah
<HighNo> superm1: whooohooo. Could you please look at http://revu.tauware.de/details.py?package=blueproximity ?
<crevette> I did a debdiff in https://bugs.launchpad.net/ubuntu/+source/bluez-gnome/+bug/190405 but I think I've screwed somewhere
<ubotu> Launchpad bug 190405 in bluez-gnome "please package bluez-gnome 0.17 " [Undecided,New]
<superm1> HighNo, yeah i can take a look after i look at obex-data-server
<HighNo> superm1: you are my hero :-)
<HighNo> superm1: yesterday I even sponsored a pizza for advocating :-)
<HighNo> superm1: without effect cause no motu with bluetooth interest was around.
<superm1> haha
<crevette> HighNo: no one was interested in #ubuntu-mobile to look at tit ?
<HighNo> crevette: do they have motus there?
<crevette> I don't know, I just wen there for the 1st time 10 minautes ago, but no one answers
<superm1> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<superm1> ^crevette, HighNo
<crevette> superm1: yeah yeah I know
<crevette> :)
<HighNo> :-)
<crevette> this is just I have no time during the week to work on what I want
<crevette> I am shifted
<superm1> crevette, is gnome-obex-sebd leaving the archive?
<superm1> or will both be available?
<crevette> gnome-obex-send is just one binary of gnome-bluetooth
<superm1> okay just by the wording above you made it sound like this package was superseeding it
<crevette> it was removed from upstream starting 0.11 in favor of the bluez-gnome which now feature the wame type of app
<crevette> superm1: ah true
<crevette> I made a mistake
<crevette> thanks superm1
<LucidFox> persia, jdong and others, I've reuploaded http://revu.tauware.de/details.py?package=tovid
<webwolf_27> would someone be kinf enough to tell me what this lintian error "no-copyright-file" means and maybe how I might fix it
<smarter> webwolf_27: run lintian with -Ii
<LucidFox> webwolf_27> it means debian/copyright is not present
<crevette> webwolf_27: you must have a file copyright in the folder debian
<LucidFox> I typically run lintian with -iIv
<webwolf_27> smarter, LucidFox, There is a debian/copyright
<LucidFox> webwolf_27> then maybe your debian/rules is missing dh_installdocs?
<webwolf_27> LucidFox, thanks
<LucidFox> check the deb file to see if the file /usr/share/docs/(package)/copyright exists
<webwolf_27> I think that may be it
<webwolf_27> Ok time to rebuild the deb
<crevette> superm1: how can I check myself with lintian / linda
<LucidFox> crevette> run them over the resulting deb files
<superm1> crevette, you can run linda and lintian on directly the .dsc and the resultant .deb
<crevette> ah okay
<crevette> thanks a lot
<superm1> HighNo, okay left you a few comments, both very minor things
<HighNo> superm1: if changed would you be advocating it=
<webwolf_27> LucidFox, Thank you very much that was it
<HighNo> superm1: DaveMorris would - but then he is no motu :-)
<superm1> HighNo, well i'm still a little wary on this pysupport usage, i mean i suppose it works for this case
<superm1> HighNo, i'll have to think about it for a few minutes
<HighNo> if debian/docs is empty, should I omit it=
<HighNo> ?
<superm1> yeah
<HighNo> superm1: could you look at debuild's output please? http://pastebin.com/d76d44ec0  This just doesn't look right, it's too short, and I only should sign it twice, had to do it four times earlier
<HighNo> doh, never mind
<HighNo> superm1: i should have done a debuild without -S -sa beforehand.
<superm1> HighNo, are you building via ssh?
<HighNo> superm1: no, I build within an pbuilder environment for hardy, i have feisty installed
<HighNo> superm1: new version is dput'ed and awaits appearance in revu soon :-)
<HighNo> superm1: doh, didn't see your man page info, how could I change that?
<HighNo> superm1: I can't confirm it installs wrong. Looking into the .deb package it shows up under /usr/share/man/man1/blueproximity.1.gz
<superm1> HighNo, well it showed up there and in doc/
<superm1> but in an uncompressed form in doc/
<HighNo> superm1: ahhh, ok, I guess it's in the .install file
<JediMaster> Hey all, don't suppose anyone knows the name of the little program that looks for certain text from a program and enters responses?
<JediMaster> trying to write an installer that runs "pecl install apc" for php, but it needs two keys to be pressed
<sistpoty> hi folks
<sistpoty> persia: just looking at wildmidi ...
<jpatrick> hi sistpoty !
<sistpoty> hi jpatrick
<tuxmaniac> can someone please review http://revu.tauware.de/details.py?package=alliance? thanks in advance
<sistpoty> persia: the wildmidi dependency libwildmidi0 (= ${binary:Version}) seems wrong to me (still looking)
<HighNo> superm1: just takes another minute, I screwed my pbuilder again...
<sistpoty> persia: since wildmidi has a NEEDED entry, this should come from shlibs:Depends instead of handcoding it
<sistpoty> persia: also, I guess you really want = ${binary:Version} for the -dev package dependency on the library (which imo should be the right thing to make it binNMU-safe)
<geser> Hi sistpoty
<sistpoty> hi geser
<geser> sistpoty: I see you found the button to prolong your MOTUship :)
<sistpoty> geser: yes... I got the expiry reminder mail that contained the link :)
<geser> JediMaster: are you looking for expect?
<HighNo> superm1: the package is back at  http://revu.tauware.de/details.py?package=blueproximity
<bluefoxicy> now that's interesting.
<bluefoxicy> using the change nickname box instead of /nick in xchat-gnome crashes it.
 * sistpoty is off again... cya
 * HighNo is sad that he immediately knows what this is: 18:11:19) jdong_ hat den Raum verlassen ("FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8").
<jdong> HighNo: :)
<HighNo> btw, do motus like to hide (to get more work done)? It would be easier to identify them if e.g. they had voice in this channel
<jdong> HighNo: there was a mailing list discussion about that
<jdong> HighNo: it was ultimately agreed that wouldn't be a good idea
<jdong> HighNo: (1) because they would be more regularly harassed for questions (2) There are plenty of non-MOTUs around here who provide excellent help and should not be treated as lessers
<HighNo> jdong: I knew it - "(get more work done)"... but really true - I've gotten great help from the people around and was kind of surprised they are no motus :-)
<jdong> HighNo: I was hanging around here helping people and doing various contributions as a non-MOTU since pretty much the formation of the MOTU team.
<HighNo> jdong: maybe you could also take a look at http://revu.tauware.de/details.py?package=blueproximity ? I hope superm1 does advocate it, chances are it might go into hardy then. I tried very hard to get rid of every error...
<jdong> HighNo: I've got a busy schedule today, but I'll look at it if I have a chance. I understand the urgency of feature freeze being around the corner :)
<method> Is it possible that fakeroot is broken in Hardy?
<geser> method: in what way?
<method> geser, well fakeroot dh_testroot works, so maybe not...
<superm1> HighNo, just looking at the diff i can still see a problem
<superm1> you are still installing ChangeLog via the .install
<superm1> it should only be installed by the line you had in debian/rules
<superm1> because that will gzip it
<method> geser, my problem is that I can run debuild -S -sa, but when I run sudo pbuilder build *.dsc, it complains that I'm not fakeroot.
<HighNo> superm1: I'll have a look
<Iulian> jdong: Damn MS
<jdong> Iulian: hehe, it's my old xchat client, being brought in for unrelated amusement purposes
<method> (which is the same failure as on the Launchpad build server)
<Iulian> jdong: yea, I noticed ;)
<frafu> Hello, I am preparing a package for a new revision and I am using dh_gconf to register and unregister the schemas. What I find strange with the autogenerated scripts is that they do not unregister the schemas with the purge command from apt-get, but with the remove command. Should it not be the other way round?
<HighNo> superm1: I also have the README installed via .install. is that an error too and should be moved to debian/docs again?
<LucidFox> jdong, could you please re-review tovid?
<frafu> I assumed that purge would remove and unregister the schemas!?
<tsmithe> can i use a string like "r3" for the upstream version of a package?
<tsmithe> lintian says no
<paas> Hi, Can a MOTU please have a look at http://revu.tauware.de/details.py?package=libtuxcap, It's ready for advocation, thanks
<HighNo> superm1: the newest version is online, changelog corrected. Please check it and if nothing harmful is stopping you from, please advocate it :-) am away for 1 hour now, be reading everything. drop a note on revu. Thanks!
<geser> method: which failure do you get? or the buildd?
<method> geser: dh_testroot: You must run this as root (or use fakeroot).
<method> make: *** [clean] Error 1
<method> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
<method> With sudo pbuilder build *.dsc
<geser> method: in which target is dh_testroot called in debian/rules? as not all targets are run as root
<method> geser, ah.
<method> geser, in install
<method> I have build: install
 * DaveMorris pokes superm1 for not looking at his package like he promised to do.  
<geser> method: "The build target must not do anything that might require root privilege." from http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
<method> geser, I see it's usually not stated explicitly, instead being called after binary-indep and binary-arch. What does it do by itself?
<crevette> what the maintainer name for MOTU package? I set the address but I assume I must set a name
<geser> crevette: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<crevette> tx geser
<tsmithe> is there a limit to package size on revu? i've got a soundfont i'd like to get in that's 129MiB
<tbutter> anyone would like to give the package http://revu.tauware.de/details.py?package=jodviewer a review?
<DaveMorris> tsmithe: try it
<tsmithe> DaveMorris, might take a while, but i'll give it a go!
<DaveMorris> is that a source file that big, or the generated package size, as I've done a set of packages which have come in close to there
<tsmithe> DaveMorris, source file: the samples that make up a general midi soundfont take up a lot of space
<HighNo> superm1: no comment yet so I guess you didn't find the time.
<HighNo> DaveMorris: superm1 seems busy...
<ScottK> persia: I'm not able to build libnb-platform7java (I'm java impaired and aim to stay that way).
<DaveMorris> it doesn't build with the blackdown jdk?
<steveire> Hi. I want to build xine-lib and hopefully get https://bugs.launchpad.net/gutsy-backports/+bug/188340 confirmed. Should I remove some libxine from my gutsy install before doing that?
<ubotu> Launchpad bug 188340 in baltix "backport xine-lib 1.1.10-1 from hardy - there are several security, flash playing and other important fixes" [Undecided,New]
<ScottK> jdong: What's you're position on baltix using backports bugs?  Personally I think it's bogus.
<ScottK> DaveMorris: I've no idea (see my previous note about Java ignorance and my determination to maintain it).
<steveire> ScottK: What's baltix? I want the package backported so I can build an uncrippled kde4 easily.
<firefly2442> I just tried making a simple package with checkinstall but it didn't grab any of the dependencies
<ScottK> steveire: It's an Ubuntu derivative.  Note the bug is open against gutsy-backports too.
<ScottK> !checkinstall | firefly2442
<ubotu> firefly2442: 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!
<steveire> ScottK: too? In addition to what? That bug is in -backports.
<ScottK> Both
<ScottK> This is why I asked jdong the question.  I think baltix people using -backports bugs is bogus and confusing.
<firefly2442> does checkinstall look in the debian/control file for dependencies?
<ScottK> firefly2442: This isn't a good place for checkinstall help.  We avoid it.
<DaveMorris> I thought you meant to wanted to avoid the sun JDK
<steveire> ScottK: OK, well I've done configure and make. Should I remove anything (libxine) before make install?
<ScottK> steveire: The easiest way to make .debs for backports testing is to use prevu.
<ScottK> I'd use that if I were you.
<steveire> Do you guys avoid prevu? I'd prefer to get it backported for everyone, not just me.
<crevette> superm1: I corrected my package
<ScottK> steveire: Right, but if you're trying to test it so we can do that, use prevu to make your test .debs, report your results in the bug and we'll take it from there.
<steveire> OK, so how do I use it?
<rhpot1991_laptop> can anyone recommend any good manpage tools, trying to format this by hand is kinda a pain, or does everyone just do it by hand?
<ScottK> !prevu | steveire
<ubotu> steveire: prevu is an automated, personal backporting utility. Check out https://wiki.ubuntu.com/Prevu for more details
<ScottK> rhpot1991_laptop: Do it in docbook and use docbook2man
<ScottK> I tend to hand edit them, but I'm a masochist.
<rhpot1991_laptop> alright thanks, I'll back this guy up and see how that works
<superm1> rhpot1991_laptop, there is also manedit
<hefe_bia> docbook2x-man if you prefer the xml version AFAIK.
<rhpot1991_laptop> help2man looks like it might be useful too
<jdong> ScottK: it's definitely confusing, though I don't know how to deal with it -- I mean, Also Affects: is one of the key launchpad features (that they advertise) and for us to say "don't use it" is awkward
<steveire> Why is prevu retrieving bash? Why does it need all those packages?
<steveire> It's getting apt as well.
<jdong> steveire: that's probably debootstrap running -- they are required components of a base Ubuntu install.
<steveire> But I already have them.
<jdong> steveire: that's on your parent system. Prevu (and pbuilder) work in their own chrooted environment.
<ScottK> jdong: Except I'd say that it's inherently invalid.  *-backports are defined as backports to specific Ubuntu repositories.  Not baltix.
<tsmithe> could someone review a large but simple package for me?: fluid-soundfont, the fluid gm/gs soundfont. thanks: http://revu.tauware.de/details.py?package=fluid-soundfont
<jdong> ScottK: agreed, but then he's gonna start registering baltix-backports and we're back at square one.
<ScottK> steveire: ^^^ is the developer of prevu.
<ScottK> jdong: Fine.  Then he can file his own bugs.
<steveire> jdong: I would have prefered to just install the package I'd just made. Seems overkill to get a whole chrooted environment.
<jdong> ScottK: Yeah, it can be argued as a misuse of the launchpad definition of "bug also affects"
<ScottK> steveire: It may seem that way, but it's a much safer way to do it.
<steveire> If I build it can I mark the above xine bug confirmed?
<ScottK> jdong: That's my view.
<jdong> steveire: using a pbuilder environment such as the one prevu is setting up is one of the only acceptable build environments
<ScottK> steveire: Yes and if you install it and test that it actually works, then you can set it to Triaged.
<jdong> steveire: remember that prevu was designed first as a backports triage tool, and any backports testing not done in a clean environment is basically useless for QA purposes
<jdong> ScottK: hmm I concur too. Perhaps we should send him a mail and ask nicely
<ScottK> jdong: I know if you mark them invalid against baltix he gets upset.  Maybe that's best.
<ScottK> Confusing our users and all that.
<steveire> Is it a chrooted gutsy or hardy env?
<DaveMorris> superm1: that linda warning is bogus btw
<jdong> ScottK: better to communicate than play launchpad status tag.
<jdong> steveire: depends on how you invoked prevu-init
<DaveMorris> since if I fix the shlibs file to solve that, then lintian complains about it been wrong
<jdong> prevu can build environments for every release of Ubuntu
<steveire> jdong: No args
<jdong> steveire: then it's a gutsy env
<jdong> it defaults to your running distro
<steveire> OK
<ScottK> jdong: Agreed.
<jdong> steveire: the problem with using the present environment is almost EVERYONE has a non-default configuration, so it's not very useful for answering if (1) a package builds (2) a package works.
<superm1> DaveMorris, okay i wasn't too sure, i'm still not confident though on the 2 libraries to one package approach.  others may feel differently
<method> Does this make sense?     -> copying [./gnome]
<method> cp: cannot stat `./gnome': No such file or directory
<method>  -> Aborting with an error
<DaveMorris> k
<jpatrick> method: pbuild the *.dsc
<method> At the end of a pbuilder run?
<jpatrick> method: you are not pbuilder building the .dsc file :)
<jdong> method: wait a second....
<jdong> method: what distro are you running?
<jdong> wait nvm
<method> No, jpatrick's right.
<jdong> that only applies to pdebuild-internal.
 * jpatrick wins \o/
<jdong> method: sorry, gutsy pbuilder has a very similar bug that affects unknown control tags in .dsc
<jdong> long story, I'll spare you the trauma
<pochu> Is python2.5 installed by default in the buildds? It seems to be in my hardy pbuilder
<DaveMorris> superm1: I've just checked in the pkgconfig for the files, and the libs are both used when you compiling against them
<ScottK> Anyone here who's set up for GCC 4.3 test building that would be willing to do a build test for me?
<JediMaster> Hey all, don't suppose anyone knows the name of the little program that looks for certain text from a program and enters responses?
<ScottK> pochu: It's not essential, so you can't assume it will be there.  You actually need the depends
<pochu> ScottK: this is more about Build-Conflicts rather ;)
<ScottK> Ah
<pochu> ScottK: I was wondering whether I need to put them for an Ubuntu package, or if they won't be there
<steveire> From the wiki page :
<steveire> Prevu may also ask to add a development line for backporting, answer yes to this as well. If Prevu doesn't automatically add the line for backporting, you will have to add it yourself. Open your /etc/apt/sources.list file, and add the line
<ScottK> Why would it need to build-conflict?
<steveire> Do I need to do anything? The page is clearly outdated.
<pochu> ScottK: well I could probably s/python/python2.4/, but that would need patching and the former is easier ;)
<ScottK> pochu: In general since Ubuntu buildd's use a clean chroot for each build, build-conflicts aren't needed.
<ScottK> pochu: Unless it needs zope, please don't be adding stuff that needs Python 2.4.
<ScottK> please fix it to work with python 2.5
<ScottK> You shouldn't need to build-conflict 2.5 anyway, just build-dep on python2.4
<pochu> ScottK: alright, thank you
<blueyed_> Is there a wrapper script that either calls kdesudo or gksudo, based on the environment?
<jdong> steveire: you probably don't
<steveire> I've put in a deb-src line for hardy. I shouldn't?
<jdong> steveire: depends on where you want prevu to get its source from.
<pochu> blueyed: su-to-root
<pochu> blueyed: in the menu package
<jdong> steveire: it's convenient but not necessary :)
<steveire> I want to get libxine source from hardy.
<ScottK> pochu: Are you working on pychecker?
<blueyed> pochu: great, thanks.
<steveire> jdong: To use this method, you must have the deb-src line of a future Ubuntu release in your /etc/apt/sources.list.
<steveire> From the wiki
<jdong> steveire: correct. to use "prevu pkgname" you need that sources.list entry
<jdong> steveire: but, as noted, it is not the only way to invoke prevu
<jdong> hence why I said it's not absolutely necessary to have that line
<ScottK> jdong: Do you have time for package reviews today?
<jdong> ScottK: later in the day, I've been trying to leave my room but people keep pinging me :D
<steveire> jdong: Another method (apt-get source name_of_package) needs that line AFAIK?
<jdong> steveire: prevu lp:foo does not need any lines
<jdong> steveire: alternatively you can go to packages.u.c to get a dsc URL
<jdong> which also doesn't need any source lines
<ScottK> jdong: I think clipper is in good shape and a worthwhile thing to get into the archive.  I also see mok0 is around and can answer questions if needed.
<jdong> prevu lp:foo only works with hardy's version of prevu
<jdong> thanks to LP changing their url scheme
<ScottK> Or maybe blueyed will get to it first ^^^
<mok0> Yep, I'm here
<blueyed> ScottK: what? package clipper?
<ScottK> blueyed: Yes.  On REVU
<ScottK> mok0: Would you please look into merging claws-mail while your waiting? http://dad.dunnewind.net/universe.php
 * mok0 looks
 * ScottK needs to run out for a while.
<ScottK> Thanks
<ScottK> mok0: This one's easier than courier
<ScottK> ;-)
<mok0> ScottK: phew :-)
<steveire> Why does all this need to be installed just to build libxine? http://rafb.net/p/BzuSsq76.html
<steveire> I mean c'mon xcomposite etc?
<steveire> This is quickly filling up my hd. Someone already built the package. Can it be backported without me building it?
<steveire> All gone?
 * sladen looks around
<sladen> steveire: lots of people here
<HighNo> superm1: thanks for reviewing. I'll do it right away...
<mok0> ScottK: huh? The Ubuntu merged version of claws-mail contains a dozen packages named sylpheed-claws-* that are not in the Debian version
<HighNo> is debian/docs the same format as .install or would it just list one entry per line which files to be considered as docs?
<hefe_bia> steveire: I think libxine can make use of a lot of libraries and therefore needs all the headers, etc. You can delete the packages after you built it to your satisfaction. I think they will be cached in /var/cache/pbuilder/aptcache
<mok0> ScottK: n/m. They are dummy packages
<steveire> hefe_bia: Will it be backported whether I build it or not?
<hefe_bia> steveire: I don't know (didn't follow the whole discussion)
<hefe_bia> Is there a backport request bug filed?
<steveire> hefe_bia: https://bugs.launchpad.net/gutsy-backports/+bug/188340 <<< It's old. I think it should be moved along. What has to happen?
<ubotu> Launchpad bug 188340 in baltix "backport xine-lib 1.1.10-1 from hardy - there are several security, flash playing and other important fixes" [Undecided,New]
<steveire> It should be confirmed, right?
<HighNo> superm1: the new package is dput'ed and will show up at http://revu.tauware.de/details.py?package=blueproximity , any other motu is greatly appreciated
<hefe_bia> I'm quite new to this, but I think somebody has to attach a log from a successful prevu or pbuilder build before it gets confirmed.
<steveire> jdong: Can you confirm that? Or anyone?
<steveire> Where do I get the log?
<crevette> superm1: I look at debian/rules, and I don't understand why linda warns about athe space
<superm1> crevette, check the last line for a trailing space
<crevette> the diff deosn't show that problem neither
<crevette> okay
<crevette> superm1: where I find an example for the Homepage field ?
<hefe_bia> steveire: You'd have to do the build in prevu and copy from your terminal or better do a "prevu package.dsc > buildlog"
<superm1> crevette, its just adding "Homepage: www.blah.org" (without quotes)
<superm1> in the debian/control file in the source area
<crevette> superm1: there is no really an hompage
<crevette> just a blog
<superm1> crevette, well link to the blog then
<superm1> that's fine
<steveire> hefe_bia: Far too late for that. There's about a million lines of output, it's almost finished, and I didn't redirect to a file.
<hefe_bia> hm... I don't know whether it writes a log somewhere...
<crevette> superm1:  about the version problem, will i be allowed to re-uploaded a version ubuntu1 whereas I alrealdy uploaded an ubuntu1 and an ubuntu2 ?
<DaveMorris> superm1:  you catch my comment about the libs?
<superm1> crevette, you can upload an ubuntu1 to revu again
<tsmithe> superm1, are you reviewing?
<hefe_bia> steveire: but maybe the last few lines are o.k.
<crevette> okay, thanks for all thal explanation; I Hop I won't bother you again
<superm1> tsmithe, i was for a little bit but i'm working on a patch for something else right now
<crevette> superm1: Homepage can be anywhere in the file ?
<hefe_bia> steveire: Are yor familiar with https://help.ubuntu.com/community/UbuntuBackports section Backport Process?
<superm1> crevette, no
<superm1> just in the top section
<superm1> like under the build depends
<hefe_bia> It doesn't clearly state that the whole log is needed. But I think some kind of "evidence" of a successful pbuilder or prevu build would speed things up ;)
<superm1> DaveMorris, yeah i saw it.  i'm still at a bit of a loss, i'd prefer that a motu who is better seasoned in library type stuff make a call on it though
<DaveMorris> sure
<superm1> sistpoty or persia should be good to make that call
<DaveMorris> thanks for poking them for me :)
<tsmithe> superm1, ok, don't worry then :)
<steveire> hefe_bia: I'm not familiar with it. I've been working off instructions I've been getting here (which seem to have dried up)
<tsmithe> superm1, (but fluid-soundfont is the package if you get a spare moment; it's very simple, but quite large due to the nature of soundfonts)
<hefe_bia> it's a short section describing the "administrative process" Users are allowed to set the bug status to confirmed following these guidelines.
<crevette> superm1: if you have some time for a last review (I hope) I'll be happy
<crevette> thanks
<DarkSun88> Hi all
<HighNo> crevette: hehe "the last review" - very funny :-) I think I used that term last time 5 uploads ago. First advocation will be marked in my calendar and a holiday for my family over the next ten years :-)
<hefe_bia> steveire: When your build succeeds copy the last few lines to a file and attach it to the bug. AFAIK you can then set the status to confirmed.
<crevette> :)
<DaveMorris> HighNo: lol
<HighNo> yeah, DaveMorris knows what I am talking of - he wrote half of the comments :-)
<steveire> hefe_bia: There's nothing of interest in there.
<hefe_bia> steveire: but if there was an error it would be there -> so there's the positive confirmation if there is nothing there ;)
<HighNo> DaveMorris: what do you think - is 13 a lucky number? it is my 13th upload now :-/
 * hefe_bia has to do some stuff for a pending exam...
 * hefe_bia is away for a while
<warp10> Debian has http://packages.debian.org/changelog:foo to search the changelog for the package "foo". Does Ubuntu have something like that?
<steveire> Where can I put the debs so that people can test them>
<steveire> ?
<ion_> !away | hefe_bia_away
<ubotu> hefe_bia_away: You should avoid changing your nick in a busy channel like #ubuntu - it causes unrequired scrolling which is unfair to new users.  (Please set your preferred nick in your client's settings instead.)  The same goes for using noisy away messages; use the command "/away <reason>" to set your client away silently.  See also Â«/msg ubotu GuidelinesÂ»
<mok0> ScottK: I've finished claws-mail. Is there a bug report for it?
<steveire> Can I send the debs to someone to put in a PPA?
<mok0> steveire: why don't you get your own?
<steveire> Don't you have to be a MOTU?
<mok0> steveire: nope
<mok0> steveire: it's open to mortals
<steveire> I don't have a GPG key. I'm not sure I want the hassle of maintaining one yet.
<steveire> I'm the kind of person who'd need to read up extensively on it.
<mok0> steveire: it's not difficult, and you'll need it all the time
<steveire> IF I want to be a ubuntu devel. I'm just trying to build kde trunk...
<steveire> mok0: I'm not saying it's difficult, I just don't know what it means
<mok0> steveire: you need to generate a (private, public) key pair. You submit the public one to Launchpad
<mok0> The private one you keep very private
<steveire> Yeah, aren't there legal bindings to them too?
<mok0> steveire: no
<mok0> steveire: it's in your own interest to guard your private key, in case someone want to impersonate you
<steveire> mok0: And back it up etc. It'll take prep. I'll also have to read that CoC thing and see if I agree.
<mok0> Yep :-)
<HighNo> steveire: I strongly recommend the use of gpa - the gnu privacy assistant. Makes creating and handling of keys a breeze.
<steveire> HighNo: Note that I use kde
<HighNo> steveire: ok, it would run anyway but likely not really look and feel like a KDE program then, it's all gtk2
<HighNo> steveire: but kgpg should fit equally well
<steveire> I've just installed it and I see I already have Dennis Kaarsemaker's key in there
<dcordero> hi
<HighNo> steveire: you might have installed it when installing signed software from a different repository
<steveire> HighNo: Yes. Seveas repo  I guess
<steveire> What expiration should I put on this?
<HighNo> steveire: though I am not sure as that key should not go into your user's keyring
<rhpot1991_laptop> how do I put a ' into a manpage
<rhpot1991_laptop> \' doesn't seem to do the trick
<HighNo> steveire: whatever you like. 2 years is ok, some put it unlimited which is not ideal
<steveire> I'll go for 1 year, 4096 bit, RSA mode
<Seveas> steveire, you'll want to remove that key from your user keyring, you should only have that in the apt keyring
<HighNo> hm, anybody here - I've read somewhere along with REVU it should contain an ElGamal key - which mine doesn't and (if that is not the reason my package isn't advocated yet) still everything works=!
<blueyed> pochu: do you think changing the default of su-to-root to use "sudo" instead of "su" makes sense in Ubuntu?
<HighNo> Seveas: thanks for putting that right, I am wondering how the key could have gotten there...
<Seveas> HighNo, he might have followed ancient instructions on how to add the key rto the apt keyring
<HighNo> Seveas: I am thinking of a setup where the key would have gotten in the users keyring - maybe I do that too seldomly
<Seveas> HighNo, gpg --import $keyid && gpg --export --armor $keyid | sudo apt-key add -
<Seveas> HighNo, that used to be the quickest way of getting the key
<HighNo> Seveas: ahh, ok
<HighNo> Seveas: now THAT is obvious :-)
<steveire> Seveas: I wonder how it got there...
<steveire> I added it with sudo at-key add
<steveire> apt*
<HighNo> steveire: anyway having anothers key is nothing bad. I doesn't hurt either side - as long as it's the public key :-)
<pochu> blueyed: su-to-root is mostly to be used in menu and .desktop files. I can't see a need to use it in scripts, as those can directly use sudo. But if there are scripts from devscripts or somewhere else using it, then I think it makes sense.
<steveire> I deleted the other key. I'm having to generate my keypair again. Somehow my password didn't work to create the revok cert.
<blueyed> pochu: It would make sense now for the apt-file update-notifier I'm doing, but there are others in /usr/share/menu/ which are likely non-functional in Ubuntu..
<blueyed> See "grep su-to-root /usr/share/menu/*"
<steveire> Strange. Same thing happened again. I know the password is right...
<HighNo> steveire: does it require you to generate a revocation ceritficate?
<steveire> No, but my password must work or the key is useless.
<pochu> blueyed: I see. We don't use the menu system though, but I guess some window managers (fluxbox maybe?) use it. So then yes.
<HighNo> steveire: if nothing else works - start a terminal and type gpg --gen-key
<rhpot1991_laptop> anyone have any idea how I get a single quote to show up properly in a man page?
<steveire> HighNo: I'm putting in the right pw, but it fails every time, maybe due to special characters. How do I 'open' the key in the terminal. Ie, anything that requires me to put in the password.
<HighNo> rhpot1991_laptop: \*(lq Left angled doublequote: ' \*(rq Right angled doublequote: '
<HighNo> steveire: using your password would be required if you sign something, otherwise your password is never needed
<rhpot1991_laptop> HighNo: looking for a single quote
<HighNo> steveire: I believe I had the problem too. I'm not using very special chars anymore. It's a passphrase anyway. You should make it long and memorable. Long is good, complex is not a real need.
<DaveMorris> I tend to use snippets out of songs :)
<steveire> I'm trying to generate it on the cmd line now
<steveire> Heh, I need to generate more bytes of entropy
<vemon> https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball <- does anyone see a severe conflict between the first and the uscan approach?
<HighNo> rhpot1991_laptop: try \e'
<HighNo> steveire: then do it :-)
<vemon> the first one get's the upstream source currently compatible with the package and the uscan approact just gets the newest source available
<vemon> i can't get over this :)
<cbx33> hey guys
<cbx33> howz it going
<rhpot1991_laptop> HighNo: still getting a bunch of giberish
<RAOF> vemon: The uscan approach is correct.  get-orig-source should get the latest upstream version.
<rjmyst3> superm1: I just uploaded a new package with the licensing issues fixed.
<rjmyst3> superm1: would you mind taking a look at it?
<vemon> RAOF, what if i post a diff with changes for a new upstream version to launchpad?
<JediMaster> how would you go about running an expect script from within a postinst script?
<vemon> RAOF, shouldn't the motu's reviewing my changes get the original source using either uscan or get-orig-source?
<RAOF> vemon: That doesn't change what get-orig-source should do.
<vemon> ok. :)
<vemon> i'm happy enough if it's clearly defined to always work like that
<RAOF> You can use uscan to get a particular version (IIRC), or they can just go to the website from debian/copyright and download the right version.
<shibata> rhpot1991_laptop: How about "`"?
<vemon> RAOF, true
<HighNo> rhpot1991_laptop:  hm, all I can see by reading other man pages is '
<RAOF> The watch file is there to be machine-readable.  People can be more flexible :)
<n3t_decrip70r> se la comen re doblada
<n3t_decrip70r> .xD
<n3t_decrip70r> lol
<HighNo> rhpot1991_laptop: do you write it by hand?
<rhpot1991_laptop> it keeps replacing them with an a with  ^ over it, and 2 boxes
<vemon> RAOF, thanks. i found my peace now and can maybe get some sleep now =)
<rhpot1991_laptop> right now I am in manedit, but its been doing the same when I write them in vi
<rhpot1991_laptop> shibata: not liking that either
<HighNo> rhpot1991_laptop: but there is no encoding problem here - right? I mean your tools are not generating like utf-8 and man/groff likes plain ascii only, stuff like that
<vemon> RAOF, btw. do you know if there is a target for repacking the source package when needed? get-orig-source doesn't seem like the right place if it's meant to get the latest upstream version
<vemon> i have a special need to unpack, patch and repack the upstream tarball with a package called whysynth
<RAOF> vemon: There's not a standardised place that I know of.  "get-pkg-source", or some similar target, might do.
<vemon> persia probably talked to you about that earlier
<rhpot1991_laptop> looks like plain ascii to me
<shibata> rhpot1991_laptop: FYI, I have found "`" in cpufreq-selector.1.gz.
<rhpot1991_laptop> where abouts?
<rhpot1991_laptop> I see it doing the same thing here where text rolls around too
<rhpot1991_laptop> cpufreq-selector is a command-line tool for choosing CPU frequency setÃ¢
<rhpot1991_laptop>        tings.
<rhpot1991_laptop> like that
<rhpot1991_laptop> are there supposed to be quotes around powersave, and performance?
<superm1> rjmyst3, i still dont see a COPYING file, and the diff.gz is now empty?
<rjmyst3> the diff.gz has been empty
<rjmyst3> the GPL is in output/license.txt
<rjmyst3> it should be called COPYING?
<superm1> wow. i'm surprised that we never caught that
<rjmyst3> ok
<superm1> it should be COPYING
<superm1> the debian/ directory should be in the diff.gz
<superm1> it shouldn't be in the upstream directory
<rjmyst3> ok
<shibata> rhpot1991_laptop: yes. single quotes is used around powersave, performance.
<superm1> rjmyst3, and put the COPYING file at the root of the .orig.tar.gz'
<vemon> RAOF, just to explain this to myself better: shouldn't the get-orig-source actually be get-latest-orig-source?
<rjmyst3> ok
<RAOF> vemon: Yes.  That's what it means.
<cbx33> anyone here recompiling after the vmsplice bug notice?
<RAOF> vemon: On the other hand, it's meant to make it easier to package new upstream versions; you don't need to repack the existing tarball, since that's in the archives (is the thinking).
<rhpot1991_laptop> shibata: this is what it shows on mine: CPU governor to use, such as Ã¢Ã¢powersaveÃ¢Ã¢, Ã¢Ã¢performanceÃ¢Ã¢.
<shibata> rhpot1991_laptop: "`" seems to be replaced to U+2018 man page.
<soto> Is there a way to automatically adjust patch files to the correct offsets when they apply with some fuzz?
<sladen> soto: patchutils has some stuff for doing 3-way diff updates without the original
<sladen> soto: but if you get it to apply with the fuzz, you can then generate a new diff from the result
<vemon> is it possible to patch a tar file with a normal diff?
<soto> sladen: Okay thanks
<HighNo> superm1: I added the COPYING stuff on the UpstreamGuide - I'll try to listen to problems regarding upstream packages and fill things in there...
<superm1> okay HighNo, i'll get a chance to look again at your package in a bit
<shibata> rhpot1991_laptop: How about that? $ LANG=C man cpufreq-selector
<HighNo> superm1: cool, take your time (as long as get a little advocation there ... :-) )
<rjmyst3> superm1: is the COPYING file just supposed to be a copy of the GPL, or should it also say something like "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License..."
<rhpot1991_laptop> shibata: bash: en_US.UTF-8=C: command not found
<superm1> yes
<superm1> rjmyst3, copy of the GPL
<rjmyst3> ok
<HighNo> I am totally freaking out now - who stole my COPYING file? I swear it has been there... grrrr. superm1 please wait a sec. I have to create another upstream release WITH the COPYING file. Iknow I had done it before - this is so strange...
<shibata> rhpot1991_laptop: sorry, please remove "$"
<rhpot1991_laptop> shibata: that looks much better
<rhpot1991_laptop> fixes mine up too
<dcordero> hi
<rjmyst3> superm1: i've made those changes and uploaded a new one
<HighNo> superm1: the newest version of blueproximity with COPYING in upstream has been dput'ed. REVU appearance will be delayed as usual...
<steveire> I've just made a PPA, and it says my repo is deb http://ppa.launchpad.net/steveire/ubuntu hardy main. Shouldn't that be gutsy?
<DaveMorris> HighNo: you gonna update your backports once it's accepted for hardy?
<hexmode> steveire: have you uploaded any packages yet?
<steveire> hexmode: Nope
<steveire> I want to make packages for use by gutsy though
<hexmode> on my ppa, it didn't say gutsy till after I uploaded some pkgs to be built for gutsy
<hexmode> https://launchpad.net/~hexmode/+archive/ # for example
<HighNo> DaveMorris: ??? I'd like to see it backported for gutsy and feisty - yes, but do I make them? If I can help with that sure.
<steveire> hexmode: OK, cool. Just trying to figure out how to upload a package now...
<steveire> hexmode: Do I put my password in  ~/.dput.cf under login or what?
<steveire> https://help.launchpad.net/PPAQuickStart
<DaveMorris> HighNo: well you can do them in your ppa, whilst waiting for the backports team to do them (after you've requested a backport)
<HighNo> DaveMorris: I'll have a look at it after tomorrows exam and my package being accepted...
<steveire> I want to upload xine-lib-1.1.10 to my ppa. What package name and version should I give it?
<hexmode> steveire: sorry, kids acted up
<hexmode> steveire: you need to dput a source package
<steveire> It's in hardy, but not gutsy, and there's an old backport request I want to outrun
<hexmode> in the dist portion of your changelog put gutsy
<steveire> hexmode: Yep, it's package name and version convention I need now
<steveire> hexmode: I'm not changing the package at all/
<hexmode> same as always ;)
<hexmode> just change hardy to gutsy
<steveire> changelog?
<hexmode> and ppa will target for gutsy
<DaveMorris> HighNo: you noticed the new versions of bluetooth packages on revu?
<hexmode> steveire: debian/changelog
<steveire> xine-lib-1.1.10-1.dsc?
<steveire> OK
<emgent> heya people
<HighNo> DaveMorris: not yet.
<DaveMorris> at the bottom of the page
<HighNo> DaveMorris: oh, yes. I noted them - that's why I know that superm1 is my man, my personal hero, my advocate :-)
<RAOF> persia: http://revu.ubuntuwire.com/details.py?package=gnome-do is available for your reciprocation :)
<RAOF> Or anyone else who wants to review a cool launcher app, of course.
<Aloha> Please review http://revu.tauware.de/details.py?package=sadms
<HighNo> DaveMorris: superm1 wanted to think about advocating it. I was never so close :-)
<DaveMorris> HighNo: just tell him you can make it do something fancy for Mythbuntu, and he'll do it ;)
<HighNo> superm1: you heard DaveMorris ? :-)
<ScottK> mok0: Those packages are transitional to support Dapper --> Hardy upgrades
<HighNo> I guess I shouldn't ping him all the time...
<mok0> ScottK: I figured
<DaveMorris> hehe
<mok0> ScottK: bug 190764
<ubotu> Launchpad bug 190764 in claws-mail "[needs-merge] claws-mail_3.3.0-1" [Undecided,New] https://launchpad.net/bugs/190764
<mok0> ScottK: I set the bug to "confirmed" and att: me, but that was reverted shortly after. I thought that was the way it was done, but apparently not
<ScottK> Did you subscribe UUS?
<mok0> ScottK: yes
<ScottK> Good.
<ScottK> I'd have thought confirmed was good, but what do I know....
<mok0> ScottK: LP should do all this automatically
<steveire> hexmode: Pattern not found: hardy. What line do I change?
<mok0> ScottK: it knows you're uploading a patch, it knows who you are.
<mok0> ScottK: It should have buttons where you could define that it's a merge, etc.
<ScottK> Don't wine to me about LP or you'll end up with a multi-hour rant on using non-free tools to develop free software.
<mok0> ScottK: heh
<ScottK> But do file bugs.  They actually pay attention to them sometimes.
<mok0> ScottK: LP is a piece of c**p
<steveire> grep -ri hardy * <<< Also returns nothing
<ScottK> ;-).  File bugs.  It's all you can do.
<mok0> ScottK: yeah... *sigh*
<steveire> Can I get some PPA help? I have the source of xine-lib-1.1.10 and I want to upload it to my PPA for gutsy. What should I use for P and V as described here: https://help.launchpad.net/PPAQuickStart
<mok0> ScottK: anyway, that claw-mail package builds just fine under hardy, and the diffs to debian are limited to those dummy compat packages plus the changelog
<mok0> ScottK: It can be a straight sync in hardy+1
<steveire> Is there a better channel for PPA help?
<ScottK> steveire: #launchpad
<steveire> ScottK: Cheers
<hefe_bia> P: xine-lib V: 1.1.10-something
<steveire> hefe_bia: I'm still stuck on the changelog bit. Any idea?
<steveire> I did a `dch -i -D gutsy` to add a gutsy line
<hexmode> steveire: sorry, I was out.  That's the right thing.
<hexmode> do you know how to build a source pkg?
<steveire> hexmode: Yes, but I upload the source, right? LP builds the package.
<hexmode> yes, sign the src changes file and dput that
<HighNo> could another motu please check http://revu.tauware.de/details.py?package=blueproximity for advocation? got one by superm1 already!
<shibata> rhpot1991_laptop: I think that it is problem of your terminal. Please select Terminal > Encode > UTF-8, then do man. If encode was ISO-8859-*, single quote became Ã¢ in my environment.
<steveire> Does the note about debuild -S -sd instead of -sa apply to me?
<hexmode> steveire: where do you see that note?
<steveire> https://help.launchpad.net/PPAQuickStart <<< Halfway down
<hexmode> steveire: probably not if your email is in the changelog file (which, if you just used dch, it probably is)
<rhpot1991_laptop> shibata: already at UTF-8 actually
<hexmode> steveire: actually, if you want to experiement, try -sd first
<hexmode> if it fails, do -sa
<steveire> hexmode: OK, finally, for P should I use xine-lib or libxine1?
<steveire> updating while using my ppa should update xine
<hexmode> xine-lib
<hexmode> that's just the name of the file
<geser> steveire: xine-lib as that's the source package name
<hexmode> so use the name of the source.changes file
<steveire> where is the source.changes?
<geser> steveire: debuild -S will create one
<steveire> OK
<shibata> rhpot1991_laptop: Hmm,,, Sorry, I do not seem to be able to help...
<persia> superm1: Installing gmyth doesn't actually fix everything.  It also needs an extra '/' removed, and the patch needs work to actually unpatch cleanly.  I'm working on it for something else anyway, and will upload those fixes with my stuff (or if I fail, upload with only those fixes).
<persia> ScottK: OK.  Taking a look at clipper soon.
<persia> ScottK: For libnb-platform7-java, you may need to pull some build-deps from NEW
<persia> RAOF: Thanks.  On the shortlist.
<superm1> persia, intersting, it built fine as it was for me previously
<superm1> okay thanks persia
<persia> superm1: I suspect it has something to do with the autogeneration of the install file.  The version I downloaded didn't actually pull gmyth, and regenerating install broke from an extra '/'.  Anyway, trivial.  The fact that I can't initialise the plugin I want is more annoying.
<superm1> understandable
#ubuntu-motu 2009-02-02
<savvas> how do people contribute to builds for other architectures, the ones in http://ports.ubuntu.com ? with pbuilder?
<ScottK> You don't.
<ScottK> We only do source uploads.
<ScottK> All the builds get autobuilt.
<ScottK> If something isn't building, figure out why and submit a fix is the thing to do.
<savvas> ScottK: well i'm attempting to backport the newest smc actually for lpia architecture in my PPA, it didn't have a -dev package, which results in an error: http://launchpadlibrarian.net/21887176/buildlog_ubuntu-gutsy-lpia.cegui-mk2_0.5.0-2ubuntu1_FAILEDTOBUILD.txt.gz
<savvas> and.. quite frankly I don't know how to "decode" that yet :)
<savvas> (I need the libcegui-mk2-dev created by that source package)
<savvas> I wonder if it would work if I grab a newer version
 * savvas tests
<directhex> lpia you can build on any i386 or amd64 machine
<directhex> it's just a tweaked i386
<savvas> directhex: thanks, didn't know that :)
<anakron> HI all
<anakron> What means lpia?
<anakron> sorry if it is too noob
<ScottK> Low Power Intel Architecture.  It's an i386 variant for low power machines like netbooks.
<anakron> ok thanks
<anakron> :)
<anakron> someone knows why are not any motu helping in mentoring? junior mentoring
<anakron> mm
<anakron> i will say it better
<anakron> why a junior mentoring request must stay frozen, waiting for someone that will accept it?
<ScottK> Some of us think it's better to just ask for help here instead of having a dedicated mentor.
<ScottK> You get a better variety of advice and get to know the community better.
<anakron> yes
<anakron> that's true
<ScottK> So if you have questions, feel free to ask.
<anakron> ok thanks
<anakron> scott, if i only know some basics things of python and only do patches for desktop files
<anakron> which must be my next step?
<ScottK> I find it best to work on things that bother you.  Better motivation that way.
<anakron> mm
<anakron> interesting
<anakron> its like a vengueance
<ScottK> Yes.
<ScottK> If you have some Python, https://bugs.launchpad.net/~pythonistas/+packagebugs is a list of Python based packages and their bug counts.   You might see if you can figure out one of those.
<anakron> launchpad it's amazing :)
<ScottK> anakron: If I accept you into that team you'll get the bugmail for all those packages.  Are you up for that?
<anakron> :) yes
<anakron> there are some easy bugs that can be fixed so fast
<anakron> and the other...will be part of my training
<ScottK> anakron: Done.
<anakron> ill try to solved one of catfish
<ScottK> When you do attach the patch to the bug and subscribe ubuntu-universe-sponsors to the bug.
<ScottK> Then a sponsor will review it for upload.
<anakron> ok
<savvas> anakron: catfish has a bug?
<anakron> https://bugs.launchpad.net/ubuntu/+source/catfish/+bug/283953
<ubottu> Launchpad bug 283953 in catfish "Catfish' default search directory is /usr/share/catfish" [Low,Triaged]
<anakron> i was trying to find it XD
 * savvas looks :P
<savvas> hey wait a sec
<savvas> anakron: check the version for this
<anakron> ok
<savvas> I asked for the new catfish to be included in ubuntu jaunty
<anakron> it's in 8.10
<anakron> it on jaunty too
<savvas> nope
<savvas> 0.3-2 is not 0.3.2-1 :)
<savvas> I know, I almost made the same error :p
<savvas> http://packages.ubuntu.com/search?keywords=catfish
<anakron> im using 0.3.2-1
<savvas> and the bug is still there?
<anakron> yes
<savvas> darn
<savvas> go go go :)
<savvas> and.. thanks for helping :)
<anakron> its not a real bug
<anakron> we need only to change the default folder to search
<anakron> to a most used location, like home
<anakron> that's all
<savvas> hey, simple stuff is what makes it perfect
<anakron> :) im not saying anything different
<anakron> its fast and useful
<anakron> but, im new on it and... i get confused
<anakron> but im still fighting
<anakron> avvas?
<anakron> savvas?
<anakron> you are a medical student?
<savvas> yes anakron :)
<anakron> nice, im pharmaceutical student
<savvas> the other more relevant attribute I have is that I am a computer hobbyist hehe
<anakron> me too
<savvas> well, welcome to the beginners gang, I'm one as well :)
<anakron> :) but your karma says that you are old here
<anakron> :)
<savvas> glad to have someone that knows what Oxcarbazepine is hehe
<savvas> ah that's answering questions, closing/filing bugs
<anakron> :O nice
<anakron> im interested in packaging and python, but i cant find the right function in catfish
<anakron> xD
<savvas> (Don't ask, I was digging up some pharm books two days ago :P)
<savvas> hold a sec, I'm editing a bug report
<anakron> how you look for you home folder??
<anakron> /home/~/
<anakron> how is the right path?
<Amaranth> anakron: ~
<anakron> i found it savvas, its too simple, ill solve it tommorrow
<Amaranth> anakron: $HOME
<anakron> other way?
<anakron> its not working in this way
<savvas> anakron: either ~ or $HOME without anything in front
<anakron> ok
<savvas> test it: echo $HOME
<anakron> does not work
<anakron> i can set it to /home/anakron
<anakron> but now for any user folder
<savvas> ah wait, in python?
<anakron> yes
<Amaranth> there is actually a program that will read /etc/passwd and tell you
<anakron> it was set like path='~'
<anakron> imust go away, see you tommorow
<savvas> homedir = os.path.expanduser('~')
<savvas> meh
<savvas> http://snipplr.com/view/7354/home-directory-crossos/
<iulian> G'morning.
<didrocks> morning o/
<savvas> does anyone have a link or can paste me the proper format of GPLv2 notification in a file header of an upstream source?
<iulian> savvas: file:///usr/share/common-licenses/GPL-2 and scroll down to "How to Apply These Terms to Your New Programs"
<savvas> oh
<savvas> I thought it wasn't there, thanks iulian :)
<__Ali__> is there an option to assign DEB_DH_INSTALL_ARGS for a specific lib?
<__Ali__> anything like DEB_DH_INSTALL_ARGS_libfoo?
<__Ali__> the documentation is really poor
<soren> __Ali__: No.
<__Ali__> soren, how do you set the args for each lib then?
<soren> You don't.
<soren> Apparantly.
<directhex> can;t you just pass that to dh_install manually in your install rule?
<soren> What are you trying to do?
<directhex> although what args would you even give dh_install?
<__Ali__> just trying to copy different files for libfoo and linfoo-dev
<__Ali__> libfoo-dev *
<directhex> so use different .install files?
<__Ali__> using cdbs
<__Ali__> it took me a day to find out that opensuse build service does not work with .install files
<directhex> that's odd. those are processed by dh_install, not by anything wlse
<__Ali__> there must be a way without .install files
<soren> __Ali__: How could it not work? dh_install looks for debian/<package name>.install. Are they using a broken debhelper?
<__Ali__> soren, well it doesnt work
<soren> __Ali__: Of course there's a way. debian/rules is just a Makefile. Yo ucan do whatever you want.
<directhex> soren, AFAIK no, they use pretty normal chroots
<slytherin> __Ali__: you can use install/libfoo and install/libfoo-dev targets in debian rules
<__Ali__> soren, i'm just trying to be concise within csbd, what's the right way of doing it in cdbs framework?
 * directhex still reckons PEBCAK, not an OBS issue with .install
<soren> __Ali__: The right way is to create multiple .install files.
<__Ali__> slytherin, no higher level commands with cdbs?
<soren> __Ali__: I somehow doubt thye've managed to break that.
<directhex> soren, so do i, i've built 100-install-file packages on there
<__Ali__> there is DEB_INSTALL_DIRS_libfoo
<slytherin> __Ali__: there might be. I am not aware of them.
<__Ali__> why there shouldnt be DEB_DH_INSTALL_ARGS_libfoo
<soren> __Ali__: What do you mean "higher level commands"?
<soren> __Ali__: If anything, you sound like you want lower level.
<directhex> indeed
<__Ali__> soren i mean setting cdbs vars wich hides lower level commands
<soren> __Ali__: Because noone has needed it. Because dh_install handles that sort of stuff by using multiple .install files.
<directhex> cdbs isn't really meant for that though is it? dh7 is a better bet for simple-but-hackable
<__Ali__> look at this http://74.125.77.132/search?q=cache:BtnedmhHfisJ:dev.blankonlinux.or.id/changeset/lontara%25252Ffirefox,7%3Fformat%3Ddiff%26new%3Dlontara%252Ffirefox,7+DEB_DH_INSTALL_ARGs_&hl=en&ct=clnk&cd=1&gl=uk
<soren> Can we please stop this useless discussion and replace it with one where you say exactly what you've done, explain what you expect to happen, and what happens instead.
<soren> ?
<__Ali__> there is a $(DEB_DH_INSTALL_ARGS_$(cdbs_curpkg))
<__Ali__> i'm going to give DEB_DH_INSTALL_ARGS_libfoo a try, it might be defined
<soren> It's not.
<__Ali__> i told you what exactly i've done and what exactly i'm trying to do
<soren> Ok, sorry, I missed it htne.
<__Ali__> opensuse bs does not see .install files
<soren> Can you repeat?
<soren> So you claim.
<soren> I need to see evidence.
<__Ali__> i'm trying to create a .rules file which works for different packages with cdbs
<directhex> i call shenanigans, because i explicitly have used OBS with .install files
<soren> ...because i think you're just doing it wrong, and it seems like a much better approach to fix *that* rather than bastardisin cdbs.
<__Ali__> and i thought cdbs may work for different packages and without .install files
<__Ali__> soren, you think too much!
<__Ali__> it's as simple as i described
<soren> Ok, I'll stop.
<directhex> https://build.opensuse.org/package/show?package=Mono&project=home%3Aoerc - every one of those debs is made by a .install file
<directhex> look at how many they are, all packagey and debish
<__Ali__> directhex, where are the install files?
<broonie> __Ali__: not using .install files would break rather a lot of packages.
<soren> __Ali__: It's really simple, really. Unless you explain *how* it's broken, it's kind of hard to know what it is we're trying to work around and how to fix it.
<directhex> __Ali__, in the source package. where else?
<__Ali__> soren, i get empty debians, no so's are copied while they are given in .install files, the only way i could get them copied was by using DEB_DH_INSTALL_ARGS which only works for 1 lib
<directhex> link to the OBS project?
<soren> __Ali__: Look... I can't use "hey, I'm doing /something/ and it's not working, even though it works for eveyone else, so I want to do everything completely differently".
<__Ali__> directhex, i see, the opensuse guys are not really experts with debs, as they admit, the official deb guid says upload rules, control etc directly, didnt say it should be in the compressed source
<directhex> __Ali__, their debian documentation is poor. i just go with what works
<directhex> and what works for me is a workflow where i don't trigger a rebuild on every commit
<directhex> i.e. just uploading, dput style, whenever i want things building
<__Ali__> directhex, i've been keep looking for a good deb example on obs, thanks for the link, the search engine is not good
<soren> __Ali__: So unless you show me your source package, I'm just going to not believe that it doesn't work. And hence, there's nothing to fix.
<__Ali__> soren, i think i'm going to try directhex's advice on putting things in the compressed source, that should give me a more standard env for deb packaging on obs
<soren> OBS sounds like a horrbile, horrible place.
<directhex> soren, it's not great, but unlike launchpad, understands a world with more than one distro
<__Ali__> it's actually a great service with nice performance and generous hosting
<__Ali__> they have been asking people with deb experience to help them, so it's not their fault if there deb part is not great
<directhex> did they fix not parsing build-depends-indep? that was a blocker for me
<__Ali__> didrocks, where in the source dir are the .install files?
<directhex> .install files live in debian/, along with all packaging-related material
<__Ali__> mono_1.9.1+dfsg.orig.tar.gz? is this the right file?
<directhex> ehm... how much debian packaging experience do you have?
<directhex> a debian source package is split into three files. that one is the orig, i.e. the upstream source code
<directhex> everying done by the packager goes into the diff.gz
<__Ali__> directhex, i thought i was doing something different, i have the same structure then, i have diff too, and everything in my debian/ is in diff too, why the heck it doesnt work then!
<soren> We can only guess.
<soren> ...since you still haven't shown us anything.
<directhex> soren, this way is more fun!
<__Ali__> directhex, why does uploading those files in debian/ also work?
<directhex> hm?
<__Ali__> there are 4 files that trigger rebuild:
<__Ali__> changelog, rules, control and dsc
<__Ali__> these files already exist in diff
<__Ali__> mayb diff is extracted first and then those 4 files are overwritten
<__Ali__> it probably ignored .install files
<directhex> dsc does not exist in the diff
<__Ali__> but the other 3 do
<directhex> yes
<__Ali__> directhex, is it necessary to use DEB_INSTALL_DIRS_libfoo := usr/lib/MyLib if i have usr/lib/MyLib in .install?
<directhex> __Ali__, i have no idea. i only touch cdbs junk when wearing a hazmat suit
<__Ali__> directhex, i was adviced to use cdbs in this channel because it's supposed to be more convenient :)
<directhex> it has a... ehm... popular following
<__Ali__> but the documentation is really bad
<directhex> essentially it's fine as long as you never ever want to do anything different to the norm
<__Ali__> the authors didnt know cmake very well
<__Ali__> i have to unset some of the cmake vars they set
<__Ali__> directhex, dh_install manual says:
<__Ali__> Files named debian/package.install list the files to install into each package and the directory they should be installed to. The format is a set of lines, where each line lists a file or files to install, and at the end of the line tells the directory it should be installed in.
<__Ali__> but this part: 'and at the end of the line tells the directory it should be installed in.', is not very clear to me
<__Ali__> all .install files have only the source files, they dont set the target?
<directhex> __Ali__, ehm, sometimes you want to rewrite the target location
<__Ali__> directhex, ehm, so if you dont set the target, it's assumed to be the same as the source, ehm, why the manual, ehm, doesnt say that?
<directhex> compare http://svn.debian.org/wsvn/pkg-mono/mono-basic/trunk/debian/libmono-microsoft-visualbasic8.0-cil.install?op=file&rev=0&sc=0 and http://svn.debian.org/wsvn/pkg-cli-apps/packages/ndoc/trunk/debian/libndoc1.3-cil.install?op=file&rev=0&sc=0
<ScottK> __Ali__: Note directhex said cdbs is poorly documented ...
 * directhex orders a mouse & bloo-ray drive
<__Ali__> ScottK, i said that :) and dh_install is not cdbs is it?
<StevenK> It is well documented -- it's just the documetation is the source code
<StevenK> dh_install is debhelper
<ScottK> __Ali__: Right.  Sorry,  just woke up
<__Ali__> yes the manual is in the source code
<__Ali__> directhex, do u also get errors on obs with Checksums-Sha in your desc?
<directhex> hm? no
<__Ali__> i get checksome error with those fields being in dsc
<directhex> perhaps because the sums of your diff and/or orig don't match?
<__Ali__> i simply run debuild -S and upload?
<directhex> yes
<maxb> cdbs not well documented? /usr/share/doc/cdbs/cdbs-doc.html is rather thorough
<__Ali__> maxb, it doesnt explain the vars defnied by cdbs
<savvas> firefox /usr/share/doc/cdbs/cdbs-doc.html
<savvas> oops
<savvas> wrong terminal :P
<savvas> __Ali__: grep -i '^#' /usr/share/cdbs/1/rules/debhelper.mk
<savvas> the comments in the rules have the info you need
<savvas> but you're always welcome to provide your own manpage :)
<directhex> sounds much nicer than just using dh7. yes sireee
<savvas> or html whatever :P
<savvas> directhex: what do you mean?
<directhex> cdbs is 10% automagic, and 90% trying to hack around the automagics. dh7 minimal rules are rather easier to massage when the need arises, leading to a somewhat more balanced experience
<__Ali__> savvas, thanks i normally use google codesearch
<savvas> directhex: do you have a link to an introduction/tutorial to debhelper 7?
<savvas> ah wait, I think I'm already using it :P
<directhex> http://paste.debian.net/27457/ is a dh7 rules file with dpatch for patching
<directhex> http://paste.debian.net/27459/ without dpatch
<savvas> #
<savvas> %:
<savvas> #
<savvas> dh $@
<savvas> oops sorry
<savvas> this means go through every dh_* command?
<__Ali__> any example of configuring a file in  /etc/ld.so.conf.d/ for deb packaging?
<maxb> "Configuring" ?
<__Ali__> adding?
<maxb> Just do it?
<__Ali__> no fancy commands in cdbs?
<maxb> It's a simple installation of a file
<maxb> man dh_install, perhaps
<__Ali__> so i can simply put a line in .install file?
<__Ali__> and is there a conventional path for storing the source foo.conf file? or just in debian/ ?
<isaac> just in debian is ok
<__Ali__> ok, thanks
<isaac> if there are loads of files feel free to create a directory
<isaac> but if there is only one or two
<isaac> it's ok to have them there
<__Ali__> is it safe to delete the generated *.ex files by dh_make? all of them are optional right?
<maxb> __Ali__: .ex == example
<__Ali__> maxb, yes, but they are all optional features right?
<maxb> yes
<fransman> savvas: are you around ?
<fransman> I just wanna say ... thank you for working on bug #319204
<ubottu> Launchpad bug 319204 in flumotion "Please package new upstream version of flumotion (universe)" [Wishlist,Triaged] https://launchpad.net/bugs/319204
<savvas> fransman: sure, no problem :)
<__Ali__> where is the right place to call ldconfig in rules?
<savvas> fransman: the problem is that the package isn't tested, as I've never run the application
<fransman> but that's ok
<directhex> __Ali__, postinst
<fransman> this kind of things are going step by step
<__Ali__> directhex, what about uninstallation?
<directhex> __Ali__, postrm
<savvas> fransman: the only problem is that it requires someone to tag the flumotion at debian as with the tag patch
<savvas> because for some reason control@bugs.debian.org doesn't like me
<fransman> doesn't like me ? is it a he or a she?
<__Ali__> directhex, doesnt dh take care of this? dh_makeshlibs?
<savvas> fransman: it should be an "it", but I've contacted the webmaster of the bugs, no reply yet :P
<maxb> Yes, dh does.
<__Ali__> maxb, there is no need to bother about ldconfig then?
<directhex> __Ali__, take care of what specifically? dh things are run at COMPILE time. you need to run ldconfig at PACKAGE INSTALL time
<__Ali__> isnt dh_makeshlibs called at package installation time?
<directhex> nothing in debian/rules is called at package installation time
<savvas> it creates something in postinst while building the package
<directhex> certainly not a dh script to gather soname versions
<maxb> No, dh_makeshlibs is not called at install time. However, various debhelper commands will make additions to your provided post/pre/inst/rm
<__Ali__> what are all those dh_* in the log then?
<maxb> There aren't any at package install time
<fransman> savvas: can you contact the packages maintainer ? at http://packages.qa.debian.org/f/flumotion.html
<savvas> fransman: I have, it's loic-m here in the channel - they are aware of the fix :)
<__Ali__> dh_makeshlibs is a debhelper program that automatically scans for shared
<__Ali__> libraries, and generates a shlibs file for the libraries it finds.
<__Ali__> It also adds a call to ldconfig in the postinst and postrm scripts (in
<__Ali__> V3 mode and above only) to any packages which it finds shared libraries in.
<__Ali__> so it takes care of postinst?
<maxb> That's what you just said
<Laney> savvas: That's lool, not loic-m
<savvas> woops
<__Ali__> maxb, yes, but directhex objected :)
<savvas> wait, let me check
<fransman> Laney: thanks
<directhex> i objected to you saying dh_makeshlibs was run at install time
<savvas> irclogs/Freenode/lool.log:23:46:25<savvas> all done! http://bazaar.launchpad.net/~medigeek/+junk/flumotion/files
<maxb> s/you need to run ldconfig at PACKAGE INSTALL time/you need to let debhelper arrange for ldconfig to be run at PACKAGE INSTALL time/
<savvas> wheow, I contacted the right person
<__Ali__> dh_makeshlibs takes care of calling ldconfig at install time
<Laney> hoorah
<jpds> ScottK: Any update on what to do with bug #321713 ?
<ubottu> Launchpad bug 321713 in ubuntu-dev-tools "ubuntu-dev-tools should not depend on python-elementtree and python-celemettree" [Undecided,Triaged] https://launchpad.net/bugs/321713
<ScottK> I haven't looked at it recently.  Let me try an do that.
<__Ali__> maxb, does it make sense to change debian/dirs to debian/libfoo.dirs and debian/libfoo-dev.dirs to create dirs for different libs?
<maxb> In any multi-binary package I would recommend always using qualified names for all debhelper files like dirs
<__Ali__> if you use files for directory creation, how do you specify which package needs which dirs?
<savvas> __Ali__: I think this is what you need: http://paste.ubuntu.com/112774/
<savvas> I'm not sure though
<__Ali__> savvas, thanks, but i dont understand maxb's recommendation regarding this
<maxb> You asked a question, I basically said "Yes"
<maxb> !dirs
<ubottu> An explanation of how files and directories are organized on Ubuntu, and how they can be manipulated, can be found at https://help.ubuntu.com/community/LinuxFilesystemTreeOverview
<maxb> oops
<maxb> Wrong factoid
<maxb> Anyway, the point is that you almost never need to use dirs
<maxb> Only if you need to install _empty_ directories, usually
<__Ali__> how do you create dirs then?
<__Ali__> do they get created automatically?
<maxb> debhelper itself will certainly create them automatically
<__Ali__> good
<__Ali__> maxb, so if we have something like: dh_install -plibfoo --sourcedir=debian/tmp, then simply adding '../foo.conf etc/ld.so.conf.d' in foo.install is enough?
<__Ali__> no need to create etc/ld.so.conf.d? (even in in debian/tmp/)?
<__Ali__> sorry, debian/foo.conf doesn't need to be copied to debian/tmp/
<directhex> -plibfoo implies libfoo.install
<savvas> __Ali__: it would be easier to show us what you have so far and on which package you're working on :)
<__Ali__> savvas, sorry it's still local
<savvas> no problem, but foos and moes can be confusing
<__Ali__> osb has to install the whole vm for each build takes ages
<directhex> that's normal
<directhex> it's needed to ensure a clean build environment
<directhex> launchpad does the same
<directhex> and you should do the same when testing locally
<__Ali__> directhex, its very very local, without osc build, it takes ages to build the whole lib
<savvas> __Ali__: yes, but if you use dpatch for example, it will complain about leftover files if it's not cleaned properly :)
<__Ali__> savvas, i prefer to rebuild the whole world every time, saves a lot of hassle, hopefully compilers will be 'real time' sometime before we all die
<__Ali__> (by hardware improvements, of course)
<oojah> __Ali__: Whether OBS/launchpad take ages to build it isn't the issue really - I guess that people just want to look at your debian directory and the orig.tar.gz.
<__Ali__> oojah, sure, here you go: http://tinylink.com/?zBsW4GrEo2
<directhex> binary package name should include soname
<oojah> I've got a source tar that doesn't have license information in any of the source files, and hence little copyright information. Is there any point even starting to package it, or should I try to persuade upstream to make changes?
<Laney> oojah: Sadly it's unlikely to be accepted without clear licensing info
<Laney> but upstreams usually want their programs in distros so I'd imagine they would be receptive
<hyperair> Laney: keyword being "usually"
<dolanor> Hello
<oojah> Laney: That was my understanding, thanks.
<pochu> oojah: does it have a LICENSE file in the tarball?
<hyperair> dolanor: hi.
<oojah> pochu: I think so. I'm at work at the moment suffering from a bad case of "can't be arsed" :)
<dolanor> The package I uploaded needs 1 more advocate :) http://revu.ubuntuwire.com/details.py?package=fsniper , please have a look any super REVUers :p
<pochu> oojah: then it might be ok, but of course having the copyright and license information in the source files is much better
<slytherin> is it really required to have license headers in source files. Does all-or-none approach work if there is a LICENSE file?
<dixonionthedemon> oiy
<dixonionthedemon> so i have a question
<dixonionthedemon> anyone know how to get SL to work with ubuntu?
<dixonionthedemon> 8.10
<dolanor> sl ?
<RainCT> dixonionthedemon: SL = Second Life?
<directhex> silverlight or second life?
<slytherin> dixonionthedemon: what is SL?
<dixonionthedemon> second life
<dolanor> Supa Lounge, fo course
<dixonionthedemon> ^_^
<RainCT> there is a repository somewhere
<dixonionthedemon> i was reading up on the ubuntu forums, but the codes make no sence
<dixonionthedemon> they just wont work
<slytherin> isn't second life client open source?
<dixonionthedemon> i have the terminal open right now
<dixonionthedemon> yea
<dixonionthedemon> prety sure
<slytherin> then why isn't there a ubuntu package for it yet. :-)
<RainCT> slytherin: too many updates
<RainCT> afaik
<dixonionthedemon> i downloaded the linux beta
<dixonionthedemon> one fer linux
<dixonionthedemon> i just... cant get it to install
<dixonionthedemon> nor run for that matter
<dixonionthedemon> i was up al last night typing in codes to get skype to work, the calling out part and fixed that
<dixonionthedemon> it works now
<RainCT> slytherin: btw, if you get it into the repos sabdfl will like you (http://www.markshuttleworth.com/archives/128) :P
<RainCT> dixonionthedemon: here you have a package: http://www.getdeb.net/app.php?name=Second+Life
<dixonionthedemon> leme se if that works
<dixonionthedemon> ty
<mok0> RainCT: where is common.py?
<RainCT> dixonionthedemon: You're welcome. Ah, and next time better go to #ubuntu for support (this is a development channel)
<dixonionthedemon> o
<dixonionthedemon> ok
<dixonionthedemon> couldnt remember that
<dixonionthedemon> lol
<RainCT> mok0: includes/
<slytherin> RainCT: nah, my hand is full right now. :-)
<mok0> RainCT: I've set up revu locally
<__Ali__> dixonionthedemon, does skype work now? that audio problem with intrepid, is it gone?
<dixonionthedemon> yea
<dixonionthedemon> got it working last night :D
<mok0> iRainCT: It can't find common
 * RainCT will try it next week (when he's 18 :D), if it's great enough I *might* have a look at packaging it
<RainCT> mok0: includes/common.py
<mok0> RainCT: I see it
<dixonionthedemon> ty SL is installing now :D
<dixonionthedemon> aight thanks fer all yer help
<dixonionthedemon> talk to yall l8rs
<mok0> RainCT: but it wont accept "from common import *"
<RainCT> uh.. his keyboard broke
<mok0> RainCT: is there a way to set the search path?
<RainCT> mok0: just to be sure, is there a common.pyc in scripts/?
<mok0> no
<RainCT> mok0: have you copied and modified htaccess.tmpl to .htaccess?
<RainCT> especially this line:   PythonPath "sys.path + ['/srv/revu-production/scripts/', '/srv/revu-production/includes/']"
<mok0> RainCT: bingo ;-)
<RainCT> :)
<oojah> pochu: Ok, thanks. The package needs patching to work properly anyway, so it might be worth talking to upstream first anyway.
<RainCT> mok0: I'm afk for one hour.. If you have some question, just ask and I'll answer it later. (Or NCommander may also be able to help)
<pochu> oojah: I think it's always a good idea to contact upstream when you're packaging something. Even to just say hi ;)
<NCommander> RainCT, hrm?
<mok0> RainCT: OK, thank you!
<oojah> pochu: True, true, I had intended to do so anyway - I'll just have patches for them now :)
<RainCT> NCommander: don't worry, mok0 is just being creative looking for new ways to break REVU *g*
<NCommander> -_-;;;;
<__Ali__> i'm trying to pack a wrapper for itk, which is somehow similar to vtk, so we have 1 source file which generates multiple binaries called python-itk, itk-java, etc
<__Ali__> what makes each lib different is determined by cmake config
<__Ali__> how is it possible to do this in .rules?
<bddebian> Heya gang
<pochu> hola bddebian
<bddebian> Hello pochu
<khashayar> Dear revuers, there are two packages on revu that we (the studio team) really would like to get into the archives before the freeze. Can anyone revu, please: http://revu.ubuntuwire.com/details.py?package=pencil and http://revu.ubuntuwire.com/details.py?package=rtirq. Thanks
<mok0> khashayar: I'l ltake a look
<mok0> khashayar: what about chibitracker? Are you interested in that? It's been sitting forever waiting for someone to take care of the package
<khashayar> mok0: Thanks :-)
<khashayar> I'll take a look at chibitracker.
<mok0> khashayar: there was a lot of hype about it some time ago
<iulian> Hiya bddebian.
<khashayar> mok0: Looks nice. I'll take a closer look at it tomorrow. (Too much things going on right now :-p)
<khashayar> s/much/many
<mok0> khashayar: sure
<bddebian> Hi iulian
<khashayar> I've noticed that jack does not build with celt support, although it depends on celt. Further investigation revealed that jack needs celt >=0.5 (the version in the archives is 0.4). I fixed that locally, but /usr/lib/pkg-config/celt.pc is reads version 0.4.0. Where might the root of this be?
<khashayar> (If anyone's interested in updating celt: LP 324289 with diff attached)
<ubottu> Launchpad bug 324289 in celt "celt needs to be updated to 0.5.1" [Undecided,New] https://launchpad.net/bugs/324289
<DktrKranz> ScottK: I've identified some packages we must have in before FF. I'm going to file bugs for them, so we can discuss in tomorrow's meeting.
<DktrKranz> s/packages/package updates/
<surfaz82> Hi!, I have a question
<surfaz82> in this diff.gz file
<surfaz82> http://archive.ubuntu.com/ubuntu/pool/universe/a/amule/amule_2.2.3-1.diff.gz
<surfaz82> in debian/control
<surfaz82> there is two "##"
<pochu> what do you mean?
<surfaz82> between quilt, and libcrypto++-dev,
<surfaz82> I use pbuilder to resolve dependencies but, pbuilder give me a error with that ##
<surfaz82> Does anyone know what are those two characters in the Build-Depends?
<surfaz82> hi?
<maxb> I would call them a bug
<pochu> or a comment
<surfaz82> but pbuilder give me a error...
<maxb> I've not noticed anything in policy permitting comments inside wrapped fields
<pochu> did you notice anything forbidding them? ;)
<surfaz82> I think Pbuilder considered ##  as a dependencie
<surfaz82> sorry for my bad English :(
<maxb> pochu: Seriously, is there any provision for comments inside debian/control at all?
<lidaobing> maxb, conside debian/README.source
<maxb> lidaobing: see scrollback, we're not discussing how to do it, we're discussing whether an existing one is valid
<lidaobing> maxb, sorry, :-)
<pochu> maxb: probably not, but the Debian and Ubuntu buildds built it fine so it may well be a pbuilder bug rather than an amule one
<pochu> maxb: and I think comments are allowed in debian/control. Not sure whether they are in the middle of a wrapped field though
<maxb> The word "comment" doesn't even occur in the control-files chapter of policy
<maxb> So even if the buildds got it right, it's still amule's bug
<surfaz82> Ubuntu builds packages in a diferente way than pbuilder?
<surfaz82> I mean to resolve dependencies
<maxb> yes
<surfaz82> Then So it is probably a problem of pbuilder
<maxb> no
<surfaz82> and then...?
<pochu> maxb: right, I can't find it in the policy either
<pochu> I thought I had read about that
<pochu> surfaz82: might be in amule instead
<pochu> I'll poke the maintainer for the next upload, I know him
<maxb> The entertaining ambiguity here is... does the "##" cause the following dependency to be omitted or not
<pochu> I'd say they cause what is following them until the next line break to be ignored
<pochu> just guessing though :)
<surfaz82> Well, another question. If a program has an incomplete translation will allow a patch?. I ask this because it is likely that this program does not publish a new version and the end user would be incomplete translation for a long time.
<surfaz82> pochu, you are Ubuntu mantainer of aMule?
<pochu> surfaz82: we are in sync with Debian
<pochu> I used to care for it, yes
<jdong> *cringe* ext4 just blew up in my face
<Vest> hello there
<Vest> can anybody help me with this? http://revu.ubuntuwire.com/details.py?package=gnome-quod
<piratenaapje> Vest: You mean with the lintian warnings?
<piratenaapje> Vest: Oops, not lintian :p
<Vest> no :) Lintian was yesterday
<Vest> the first question is: The Maintainer     field is invalid. It has to contain an @ubuntu.com address (usually the     Ubuntu MOTU Team's). The packager can leave his/her name as     XSBC-Original-Maintainer.
<piratenaapje> Vest: The warnings being displayed I meant
<ohe> hi all .. i had upload a package (gammapage) to revu..
<piratenaapje> Vest: debian/control should have a field Maintainer with "Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>" as value
<ohe> what's append next?
<ohe> what's happens next /// sorry
<piratenaapje> Vest: You can put the original maintainer in XSBC-Original-Maintainer
<Vest> piratenaapje: I'm not sure I can get @ubuntu.com e-mail
<jdong> heh and this is probably why we don't use experimental filesystems....
<jdong> ext4 totally blew itself up
<piratenaapje> Vest: You don't need to, just put "Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>" as value (no quotes :p)
<Vest> piratenaapje: can you explain, why? because, at the moment I'm not a MOTU Developer, so who will get any messages for that application
<piratenaapje> Vest: I guess cause they are the ones uploading it, not really sure
<__Ali__> isn't it possible to have source and package names to be different in .control?
<piratenaapje> Vest: You can still put your own email-adress in XSBC-Original-Maintainer
<mok0> Vest: once the package is in Launchpad, you can subscribe to it
<mok0> Vest: In fact, we expect that uploaders maintain &  care for their packages
<piratenaapje> Vest: Is there a launchpad bug that requests packaging for the program you are trying to package?
<piratenaapje> Vest: If not, report a [needs-packaging] bug in launchpad
<piratenaapje> Vest: And then put a line stating: "Initial ubuntu release. (LP: #xxxxxx)" in debian/changelog
<Vest> piratenaapje: no-no, this package doesn't exists
<piratenaapje> Vest: Then file the bug yourself
<Vest> yes, but the first thing is try to publish my own package to repos
<joaopinto> Vest, the first thing you need to do is read https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<joaopinto> without following those steps you will not be able to get it into the official repositories
<Vest> joaopinto: yes, I've readed many faqs, but when I start to upload package to revu, I have some misunderstandings, which I ask there ^)
<joaopinto> Vest, you need to read it more carefully, you are expected to create the LP bug before uploading it to review
<piratenaapje> Vest: You should file a needs-packaging bug when you package something new, as stated in the link jaoapinto just gave you
<joaopinto> since on the changelog (which is part of your REVU upload) must contain the LP bug you are trying to close
<Vest> joaopinto: can you explain, why is this called a bug? does my program have any bugs before any uploads? :)
<RainCT> xD
<RainCT> Vest: it's a "workflow bug".. just so that other people know that someone is working on that package
<Vest> hm... :)
<joaopinto> some bug reports are just action items
<piratenaapje> mok0: When you have time, could you take another look at http://revu.ubuntuwire.com/details.py?package=grnotify again? You previously advocated it, but I had to make some changes to fix the problems another MOTU found.
<mok0> piratenaapje: In 10 minutes or so
<piratenaapje> mok0: Awesome, thanks :)
<mok0> piratenaapje: why is the release -0ubuntu2 ?
<piratenaapje> mok0: So I could upload to my ppa
<piratenaapje> mok0: It rejects if I try to upload something again with the same version
<mok0> piratenaapje: you should append ~ppa1 to your PPA versions
<piratenaapje> mok0: Ah ok, didn't think of that
<loic-m> For your ppa, piratenaapje, you can also use jaunty/intrepid/hardy instead of ppa like 0ubuntu1~intrepid1, ect
<mok0> piratenaapje: it hasn't been uploaded to ubuntu before?
<piratenaapje> mok0: Nope
<mok0> piratenaapje: ok, I will change it to 0ubuntu1 and upload
<piratenaapje> mok0: Yay thanks, my first package in ubuntu :)
<mok0> piratenaapje: time to celebrate!
 * mok0 toasts in a virtual beer
<piratenaapje> :D
 * hyperair gets drunk from the smell
<mok0> grnotify out of the way. *Phew*
<piratenaapje> Hmm I don't get notification emails, that's weird
<hyperair> piratenaapje: i had issues with that once too
<hyperair> piratenaapje: make sure you're not subscribed twice
<hyperair> piratenaapje: in my case, i think it was because i subscribed to the package, and also set in my preferences to receive notifications for all packages =\
<piratenaapje> Subscribed to e-mail notifications for:  Own packages, grnotify
<piratenaapje> hyperair: Same here
<hyperair> yeah
<hyperair> exactly
<henrik-hw0> superm1, online?
<superm1> hi henrik-hw0 yeah i saw your ping over the weekend, i should be able to look at the updated packages sometime today
<henrik-hw0> i'll leave the connection should there be any issues.
<henrik-hw0> s/connection/connection open/
<Tonio_> rgreening, Riddell: pnm upoaded
<rgreening> kool. ty Tonio_
<^Spear> Hi
<^Spear> Is anyone able to package  http://raop-play.sourceforge.net/ ?
<Chris`> ^Spear's request is being looked at
<^Spear> thanks :)
<xnox> Hey all =D There is one package that I'm working on to update. The current tarballs in Ubuntu/Debian as well as the new upstream release and their svn repo all have ~200 files with copyright and licensing information missing
<xnox> There is a top level license saying it's GPL 2
<xnox> is this ok?
<xnox> Cause I believe it's a release blocker. Other people think it's fine
<pochu> why is it a release blocker?
<Chris`> pochu: Archive admins may ask who owns this file
<xnox> well what if it turns out those files are not GPL, or their authors were not properly recognised nor given copyright
<pochu> is the package in the archive already?
<xnox> The strangest thing is that ~ 100 other files _do_ have licensing and copyright headers.
<xnox> yes it is in the archive already
<xnox> source package sword
<maxb> Are upstream going to do anything about it?
<xnox> I've filed a ticket in their bug tracker and I have heard nothing back.
<pochu> so if it's in the archive, archive admins consider it's ok (assuming it was that way when it was uploaded)
<xnox> it was tarball inside tarball and i think that could have slipped by
<pochu> I bet they check those too
<xnox> right, ok. I will try to follow up on this issue with upstream though. It makes me feel uneasy.
<pochu> maybe ask in #ubuntu-devel
<iefremov_work> Hi all! Can anybody qualified answer my question: how do I update already archived package (upstream version change)? compiled binaries are not accepted yet.
<hyperair> iefremov_work: what dyou mean?
<loic-m> iefremov_work has the package been accepted in the repositories? What was the reason for archiving?
<iefremov_work> hyperair: 1) some days ago i uploaded a package to REVU 2) it has been advocated twice and archived 3) it was built on palmer (i386) yellow (amd64) 4) now i want to update the package since there is new upstream version
<hyperair> iefremov_work: file a needs-upgrade bug, attach a debdiff, subscribe ubuntu-universe-sponsors
<loic-m> indeed
<maxb> See wiki.ubuntu.com/SponsorshipProcess for reference
<hyperair> if you're impatient, come here and bug every MOTU you can find to sponsor your debdiff =P
<loic-m> iefremov_work: https://wiki.ubuntu.com/PackagingGuide/Complete#Recipe:%20Updating%20An%20Ubuntu%20Package
<superm1> henrik-hw0, did have a question.  why don't you just refer to linux-headers-generic | linux-headers in your depends?
<superm1> henrik-hw0, that way you dont have to update it at every new ubuntu release that includes new kernels
<iefremov_work> hyperair, maxb and loic-m: Thanks!
<loic-m> hyperair: does that work?
<hyperair> loic-m: what?
<loic-m> hyperair: bug MOTU
<hyperair> loic-m: bugging every single MOTU you can come across? yeah sure it does. especially if you ask the one who advocated your REVU package
<superm1> henrik-hw0, also, does the initramfs actually need to be updated? is this driver included in it if you do update it?
<loic-m> hyperair: I need to upgrade my bugging 5k|llZ
<hyperair> it works better than sitting around staring at the bug and watching it rot until upstream releases another package and you release yet another debdiff and so on
<hyperair> loic-m: lol
<loic-m> hyperair: some MOTU are going to love you pretty soon
<superm1> henrik-hw0, and does it need to be put in /etc/modules?  Shouldn't it be loaded automatically my udev?
<henrik-hw0> superm1: i suppose i could simplify the kernel headers dependencies. i just thought i'd be thorough.
<hyperair> loic-m: is that sarcasm i hear?
<henrik-hw0> does kernel-headers depend on the other kernel header packages?
<superm1> henrik-hw0, yeah I understand the desire to be thorough, i just think you might shoot yourself in the foot with it because i know the kernels change often enough
<loic-m> hyperair: just the (sad/funny) reality ;)
<hyperair> loic-m: heh lol
<loic-m> hyperair: just depends which side of the poke stick you are ;)
<superm1> henrik-hw0, debian policy says you have to do a real package or a virtual package
<superm1> henrik-hw0, which is why i said "linux-headers-generic | linux-headers"
<hyperair> loic-m: =p
<hyperair> loic-m: i wonder
<hyperair> maybe i should apply for mentorship
<hyperair> hmmm
<iefremov_work> hyperir and loic-m: i see you are really experienced guys. Another question: AFAIU the package will be the part of Jaunty distro. Will it be possible to update it during the 'feature freeze' or any other release phases? There will be new major upstream version in the begining of March.
<henrik-hw0> superm1: i'll have to run some tests on the module loading. it should be possible to autoload it AFAIK.
<Laney> hyperair: Do you really find sponsorship takes that long?
<hyperair> Laney: but of course.
<jpds> iefremov_work: No, you'll need an exception to get it through.
<hyperair> Laney: i've got a few bugs that's been sitting around collecting dust
<hyperair> Laney: SRU stuff
<superm1> henrik-hw0, yeah it's best not to touch /etc/modules from maintainer scripts.
<Laney> SRU is a bit different as it blocks on a small number of people
<Laney> general sponsorship is relatively swift I've found
<Laney> certainly no need to poke people on IRC (which has the potential to annoy)
<iefremov_work> jpds: and when it will be possible to update the package again?
<superm1> henrik-hw0, i'll add these comments to the REVU so they're not lost
<jpds> iefremov_work: After release.
<iefremov_work> then the package will be in 'updates' repository, right?
<jpds> iefremov_work: No, that's for important bug-fixes only.
<hyperair> Laney: well come to think of it, with the exception of SRU bugs... i haven't handled many other bugs. the FTBFS bugs sure went fast though
<henrik-hw0> superm1: good. did you have a change too look at libmirage and cdemu-daemon?
<loic-m> Laney: we were mosty loking, but if you've got spare time I can afford having my bugs disposed of now ;)
<Laney> did you subscribe motu-sru?
<jpds> iefremov_work: The package will only get new versions uploaded at jaunty+1 after feature freeze.
<hyperair> Laney: yeah i did
<hyperair> Laney: for the main ones i subscribed ubuntu-sru
<Laney> loic-m: No, I can't sponsor. And please don't ping unless it's been an inordinate amount of time (> 2 weeks or so)
<loic-m> Laney: although I remember an SRU taking more than one month after having been decided/advocated
<hyperair> currently i'm waiting on two main ubuntu-sru ones
<hyperair> gnome-keyring and evolution-data-server
<Laney> same for SRUs
<loic-m> Laney: I don't ping for that. i just hope it gets processed before FF
<Laney> loic-m: If you uploaded the diff before then it's fine
<iefremov_work> jpds: still can't understand: if i update the package after release, will it be possible to user to 'apt-get' it?
<hyperair> Laney: >2 weeks is inordinate? i've waited for months on end for some
 * hyperair sighs
<Laney> yes
<loic-m> Laney: that's good to know
<Laney> ideally it should be a FIFO queue, but I suppose people pick out things they want to sponsor
<hyperair> Laney: there was one banshee bug which took over 3 weeks, and even then it got attention after a considerable amount of pinging
<Laney> sync requests get disposed of very quickly
<superm1> henrik-hw0, no i haven't looked at those.  i'll see if i get some more time this afternoon
<Laney> hyperair: I don't know what you're doing different to me then - not really had this problem
<hyperair> Laney: yeah i noticed. uswsusp's "sync" request has been sitting there since feisty though. it's more of a merge. maybe i'll tackle it and submit a debdiff
<hyperair> Laney: pick the hard packages or the small insignificant packages and nobody pays attention =\
<Laney> hyperair: huh? The sponsors aren't even subscribed to that
<hyperair> Laney: uh what?
<iefremov_work> hyperair: another question: if i update the package after release, will it be possible for user to 'apt-get' the updated package?
<Laney> uswsusp
<hyperair> Laney: ah right. well i didn't file it. i happened to stumble across it because cwillu was trying to figure out how to get uswsusp to work with usplash
<jpds> iefremov_work: apt-get as in install the one in the archives? Yes.
<hyperair> iefremov_work: depends how long after
<Laney> well I don't know why you bring that up as an example of sponsorship delays
<henrik-hw0> loic-m: if you ask me there should be designated mini-MOTUs who do some of the initial reviewing of the packages before things start to get serious. it would save a lot of time. :/
<fabrice_sp> iefremov_work, to have a package updated in -update, you need to have serious reason for that (like serious bugs in previous version)
<maxb> iefremov_work: For a critical bugfix you the released version, you'd follow the SRU process. For a new upstream version, you'd have to first get it into the current development release and then seek a backport according to the backports process
<hyperair> iefremov_work: but if the user is on the current devel release, they'll definitely be able to
<fabrice_sp> iefremov_work, or just upload it to your ppa
<Laney> henrik-hw0: If you ask *me* people should become very familiar with packaging before they attempt to package something new so that these things aren't even an issue
<loic-m> henrik-hw0: it's for the translation. AFAIU nobody really manage/coordinates translation for universe packages
<hyperair> Laney: there are a few others as well, but i can't remember. probably my judgement is skewed by the fact that most of the bugs i mess around with are SRUs
<iefremov_work> ok, thanks
<loic-m> henrik-hw0: i'm more like considering you're "upstream" since those kind of packages are dealt with upstream
<loic-m> henrik-hw0: and for Debian AFAIR it's the packager job to get/request translations, even though they should have a mailing list
<Laney> hyperair: Bring it up on the ML, maybe they'll bring more people on board
<hyperair> ML eh
<hyperair> Laney: which ones
<Laney> ubuntu-devel?
<hyperair> that's for stuff in main right? what about stuff in universe
<Laney> ubuntu-motu
<hyperair> oh there's a list by that name eh
<Laney> but I guess most people will be subscribed to -devel anyway
 * hyperair searches for a link to subscribe
<henrik-hw0> loic-m: It's almost always a good idea to get upstream to merge your stuff.
<loic-m> henrik-hw0: I'm talking about your package, gcdemu, a string in the .po file ;)
<loic-m> henrik-hw0: I do file bug upstream for my translations/desktop files on packages I modify. However, you're gcdemu maintainer ;)
<khashayar> If I file an update request bug on launchpad with a diff.gz, do I assign myself to it and set it to "in progress"?
<asomething> khashayar: no, if it is ready to be sponsored, it should be confirmed with no assignee and *-sponsors subscribed
<asomething> khashayar: only leave it in-progress if you are still working on it
<khashayar> asomething: Well, it's just a request for a new upstream version. I've built it and tested it, and there's a diff.gz attached. I don't think there's more to do. Should I just set the status to in progress?
<loic-m> khashayar: once you've uploaded the diff.gz and checked the package works in Jaunty, > Confirmed
<loic-m> khashayar: if the package is in universe, subscribe ubuntu-universe-sponsor once it's confirmed
<khashayar> loic-m: "status confirmed", subscribe sponsor and no change to "assigned to". Correct?
<loic-m> khashayar: if it's in main, subscrive ubuntu sponsors for main
<khashayar> loic-m: Got it. Thanks!
<loic-m> khashayar: yes. Assigned to > noone
<loic-m> khashayar: don't forget to try if it installs and work ok in Jaunty, and say so in the bug
<khashayar> loic-m: Will do.
<loic-m> khashayar: always try the package in Jaunty before submitting the diff.gz and confirming/subscribing uus / usm
<khashayar> loic-m: I've actually already done that. But it's really just minimal testing.
<mrooney> anyone know why REVU says my package http://revu.ubuntuwire.com/details.py?package=wxbanker doesn't close a bug on LP?
<mrooney> It seems to in the changelog
<loic-m> mrooney: isn't the syntax (LP# number) ?
<loic-m> mrooney: not 100% sure, but (Closes: #297289) is Debian syntax
<mrooney> loic-m: debian syntax is wrong?
<fabrice_sp> mrooney, it's LP: #number
<mrooney> man I can't believe how hard it is to package things :[ I have been trying to do this for two months
<mrooney> fabrice_sp: hm okay, I can change that
<mrooney> Should I be trying to get a package in debian instead of ubuntu directly?
<Vest> mrooney: at the present I'm working about uploading my package to ubuntu too :)
<loic-m> mrooney: no it's just that for closed bugs, AFAIR Debian != Ubuntu
<Vest> not so long as you do.... but enough :)
<mrooney> Vest: yeah, I have only been able to get one review in 2 months of asking every few days
<Vest> mrooney, tell me how? :)
<mrooney> Maybe I am missing a step or something
<loic-m> mrooney: you can either do both at the same time, or wait till your package is accepted in Ubuntu before you submit it to Debian
<mrooney> loic-m: ahh okay, but you would recommend going to ubuntu directly in some way?
<mrooney> at or before
<Vest> I've submited a bug: https://bugs.launchpad.net/ubuntu/+bug/324440 (of my new application), and now succefully uploaded my package to REVU http://revu.ubuntuwire.com/details.py?package=gnome-quod, and I don't know what should I do
<ubottu> Launchpad bug 324440 in ubuntu "[needs-packaging] gnome-quod" [Undecided,New]
<mrooney> Vest: I think you wait for king MOTUs to review it :)
<mrooney> *kind
<mrooney> but I guess king also works
<loic-m> mrooney: i don't really recommend anything. I'm not sure what is best, depends on your prefered tools (Debian use something else than REVU)
<Vest> I thought "king" :-D
<asomething> mrooney: I'd normally say go to Debian first then sync to Ubuntu, but with Debian in freeze if you want to see it in Jaunty, straight to ubuntu would probably be the way to go right now
<Vest> mrooney, can I look at your package for comparence?
<Vest> asomething: I want to see my package in jaunty too :)
<mrooney> Vest: sure. it's wxbanker (on revu). I am not sure how it will compare, mine is a cdbs python packaging
<khashayar> I have fixed two small problems in jack-audio-connection-kit, one of which depends on LP 324289 being solved. The debdiff I have for jack fixes both of the problems, but they are indeed seperate bugs. Do I file two bug reports and upload the same debdiff to both of them?
<ubottu> Launchpad bug 324289 in celt "celt needs to be updated to 0.5.1" [Undecided,Confirmed] https://launchpad.net/bugs/324289
<Vest> mrooney: thanks, I'm going to take a look right now
<mrooney> asomething: okay, I would love to see it there :) I'll probably post on planet.ubuntu.com once I feel good about and that might get a review or two
<Vest> ooo, ubottu said about my package here? :)
<surfaz82> pochu, if you have time, could you do this request?
<surfaz82> https://bugs.launchpad.net/ubuntu/+source/amule/+bug/324458
<Vest> is it a bot
<ubottu> Launchpad bug 324458 in amule "[Jaunty] Request upload amule 2.2.3-1ubuntu1" [Undecided,Confirmed]
<mrooney> asomething: is it okay not to have a diff against the source? ie can I throw the debian/ in my version control while I am working on it? is that confusing or do motus just look at the actual files and not the diff
<asomething> mrooney: you probably want to create a separate packaging branch
<asomething> ~/wxbanker and ~/wxbanker/ubuntu
<asomething> at least that's how I work
<mrooney> asomething: okay cool, so now I've added that in bazaar, do I just tarball the export up as the orig or do I need to actually make a release
<asomething> mrooney: well as you're upstream it's up to you, if you don't do a release then you debian rev number should show the revision from trunk like: 0.4.0.2+bzr92-0ubuntu1 or 0.4.0.3~bzr92-0ubuntu1
<mrooney> okay, I don't want to confuse users by having a new release for trivial (to them) packaging compliance changes
<mrooney> so I'll use revs for now and then make a 0.4.0.3 or whatever that is the actual complete packaging and upload that, or something
<mrooney> asomething: but that workflow is right in that case? commit changes, tarball the bzr export as the orig, and debuild and dput?
<mrooney> all this is a little overwhelming as this is my first packaging attempt :)
<asomething> i usually just copy the debian folder from my packaging branch and use the pristine upstream tarball to make sure I don't carry over any un-need things
<bdrung> from where can i checkout ubuntu packages in bzr?
<Laney> bdrung: bzr branch lp:ubuntu/jaunty/package
<Laney> afaik
<Laney> try this post by james_w: http://jameswestby.net/weblog/ubuntu/07-fixing-an-ubuntu-bug-with-bazaar.html
<asomething>  <bdrung> http://package-import.ubuntu.com/
<bdrung> thx
<Laney> oh, heh
<Laney> I missed a part of that post
<Laney> "how it will work in a short while when launchpad hosts the branches and all the bits are in place"
<Laney> still, neat stuff, even if learning a new toolset scares me somewhat
<fabrice_sp> Some MOTU to sponsor a sync request (Bug #324471) ?
<ubottu> Launchpad bug 324471 in hatari "Please sync hatari 1.2.0 from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/324471
<Laney> fabrice_sp: Why is this too important to wait for u-u-s to get to it?
<fabrice_sp> Laney, we are not close of Feature Freeze?
<Laney> 17 day
<Laney> s
<fabrice_sp> ooohhh
<Laney> and even then, sponsorship asked for before FF will still be allowed
<fabrice_sp> Laney, for Intrepid, I missed a sync before FF and had to justified it afterwards, with a FFE..
<RainCT_> (OT, if someone knows how to workaround bug 163156 please tell me :P)
<ubottu> Launchpad bug 163156 in linux-source-2.6.22 "UPEK TouchStrip 147e:2016 not supported at all" [Undecided,Won't fix] https://launchpad.net/bugs/163156
<fabrice_sp> but we still have time
<Laney> fabrice_sp: you filed it before ff?
<fabrice_sp> Laney, yes
<fabrice_sp> it was for a library
<Laney> I remember people working to clear the queue, so that's very odd
<fabrice_sp> Laney, Bug #242572
<ubottu> Launchpad bug 242572 in wxsvg "[Sync request] Upgrade wxsvg package to b11" [Wishlist,Fix released] https://launchpad.net/bugs/242572
<mrooney> james_w: could you ping me when you are around? I want to use fancy bzr packaging and was hoping you could point me at doing it correctly
<fabrice_sp> so sorry for being so paranoid :-)
<mrooney> phew, okay, if anyone wouldn't mind giving me a sanity check / review of http://revu.ubuntuwire.com/details.py?package=wxbanker, I've just uploaded a new version
<mrooney> maybe it is good to go!
<mrooney> I would appreciate it EVER so much
<pochu> surfaz82: I've told the Debian maintainer about it. thanks
<surfaz82> ok
<surfaz82> pochu, then I close request?
<pochu> surfaz82: yes, you can
<mok0> mrooney: why is the package arch dependent, when it's not?
<mrooney> mok0: a mistake, is probably why!
<mrooney> mok0: what did I do that makes it arch dependent?
<mok0> mrooney: when you put Architecture: any in control
<mok0> mrooney: you want all, not any
<mrooney> ahh
<mrooney> I thought any means one build will work on all of them
<mok0> mrooney: subtle, huh?
<mrooney> and all means to build separately for each
<mok0> mrooney: any =  it will be built on all of them
<mok0> mrooney: all = it will be built on 1
<mrooney> mok0: ahh okay, let me fix that. does it look fine otherwise?
<mrooney> thanks btw :)
<mok0> mrooney: I have some other comments
<mok0> looks ok
<mrooney> mok0: oh okay, what are the other comments
<mok0> mrooney: I'll leave them in the comment field on revu, it's easier that way
<mok0> mrooney: Ready in ~10 minutes
<mrooney> mok0: thanks so much :)
<RainCT> Â«since already some time I'm noticing some rivalry between GNOMe and KDE suers, like those against beatles and rolling stones... or windows vs common senseÂ»   LOL
<ScottK> I don't feel any sense of rivalry.  I just don't understand why anyone would use Gnome.
<RainCT> heh
<Chris`> Nor do I understand why people evangelize KDE!
 * ScottK wasn't evangelizing.  Feel free to use what you want.
<Laney> ScottK: How low quality and dangerous are the kubuntu-experimental PPAs?
<Laney> those words make me wary about even installing them
<ScottK> That's their point.
<ScottK> Currently not so bad as they have KDE 4.2.0 in them.
<ScottK> They are a pretty direct backport of what's in Jaunty.
<RainCT> Laney: here they are unusable :(
<ScottK> RainCT: What happened?
<RainCT> ScottK: I don't really remember the details now, but the graphics are mad.. moving a plasma widget, a window or whatever sometimes hangs for a while and stuff like that
<RainCT> (also, I couldn't find how to get a 2 screens setup, but that's probably just me being silly)
<ScottK> That may be the Compiz Xorg hack that I blogged about last wekk.
<ScottK> Dual screen setup is quite doable.  I know people that have them.
<RainCT> ScottK: and that problem is fixed by now?
<ScottK> We have a 'fixed' xorg-xserver in that PPA now.  Of course if you worry about compiz performance, you may not want it.
<pochu> I wished the UWN was less poluted
<ScottK> RainCT: Here's the gory details http://www.kitterman.org/ScottK/2009/01/bug_254468_momentary_video_gar.html
<Hobbsee> pochu: poluted?
<RainCT> ScottK: is it the one from your PPA?
<RainCT> xorg-server - 2:1.5.2-2ubuntu3.00~ppa1
<ScottK> Yes.  Same onr.
<ScottK> one even
<pochu> Hobbsee: err, bloated
<RainCT> ScottK: I have it installed then. Didn't notice any slowdown
<ScottK> Ah.  Good to know.
<Hobbsee> pochu: ahhh
<Laney> What do I need to install to get kde4.2 from that PPA? Will just kubuntu-desktop do it?
<ScottK> Should.
 * ScottK looks at JontheEchidna.
<RainCT> (My graphics card isn't bad, though... Perhaps other people may notice a different)
<Laney> ScottK: Worked
 * Laney takes the plunge
<ScottK> Great.
<JontheEchidna> Yeah, kubuntu-desktop
<RainCT> ok, let me try KDE again.. /me switches session
<Hobbsee> mok0: wouldn't the launchpad 3.0 plan have been done months ago?
<RainCT> ScottK: Uhm... Seems like it works fine now.
<ScottK> Great.
<RainCT> And I absolutelly love the look and feel... If GTK applications wouldn't look that awful I might even switch to it :P
<Hobbsee> mok0: more to the point, is there any indication anything will get done with the feedback/liason, or are you guys going to be wasting your time, for what sounds to be a good thing, but is bikeshedding?
<RainCT> (Random comments: networkmanager-kde is ugly, and the folder plasma thingie doesn't recognize .desktop files and shows their extension.. :P)
<JontheEchidna> we should be getting a sexy kde4 replacement for networkmanager-kde for jaunty
<JontheEchidna> the current one is the barely-working kde3 version
<ScottK> As long as the KDE4 one barely works as well and the KDE3 one, I'll be happy.
<RainCT> dual screen is still not working.. system-settings only shows one screen, and using nvidia-settings (which I use on GNOME) one screen works but half of the other one is black XD
<RainCT> and I've lost transparency
<JontheEchidna> yeah, but at least kwin doesn't crash anymore
<JontheEchidna> :P
<directhex> wake me when n-m *really* supports static ip :/
 * JontheEchidna just sets up eth0 in /etc/network/interfaces and removes n-m from his system
 * Laney cannot cope with change
<directhex> JontheEchidna, well, yeah. sadly, that's the only option
<RainCT> directhex: here n-m works fine :P
<directhex> Laney, you can't override the "auto eth0" default n-m connection. delete it, convert it to static, make a different connection default, doesn't matter. on next boot, "auto eth0" will be the connection it uses, i.e. dhcp
<RainCT> Ah, that may also happen here. I have WLAN by default so I don't really know
<Laney> I meant KDE :(
 * pochu hopes his mail to -motu doesn't sound bad
<directhex> pochu, do you call them all poop-faced smellypants?
<mrooney> mok0: thanks for the comments! why am I not the correct maintainer in Ubuntu?
 * ScottK hands mrooney https://wiki.ubuntu.com/DebianMaintainerField - I think that explains it.
<mrooney> ScottK: but I am upstream and downstream
<ScottK> So the policy may not be relevant in your case.
<ScottK> But generally we want the team to be the maintainer and you are original maintainer.
<ScottK> Is that a problem?
<mrooney> ScottK: I don't really what that implies, I guess
<mrooney> I would think MOTU would welcome and chance to not be the maintainer of another package :)
<zMoo> hello
<pochu> mrooney: we usually welcome people getting their packages into Debian so we can just sync :)
<ScottK> As a practical matter it doesn't make a lot of difference as we tend to feel responsible anyway.
<ScottK> +1 to what pochu said.
<mrooney> :|
<mrooney> every time I come in here I get told to do a different thing than the last time, haha
<ScottK> mrooney: If you're involved enough in Ubuntu to become a member, then you get an @ubuntu.com address and it's no problem.
<mrooney> ScottK: I am!
<ScottK> Did you use your @ubuntu.com address as maintainer?
<mrooney> ScottK: yes
<zMoo> a new upstream package is available for the package swac-get. I've created a bug on the lauchpad and attached a new source package for jaunty. Is it the right procedure?
<zMoo> https://bugs.launchpad.net/ubuntu/+source/swac-get/+bug/324561
<ubottu> Launchpad bug 324561 in swac-get "New Upstream version 0.5" [Undecided,New]
<ScottK> mrooney: Sorry I didn't look at the package.  That should be fine then.
<mrooney> ScottK: okay, thanks :)
<RainCT> mrooney: and REVU complains even if it's @ubuntu.com?
<mrooney> RainCT: no, I just got a comment to change it
<RainCT> ah ok
<mrooney> also how important are manpages? it isn't a requirement in main so is it a problem to have the initial package without one?
<mrooney> I assume it would go in universe?
<RainCT> mrooney: manpages are great, please include them :P
<mrooney> RainCT: tell that to mozilla :)
<directhex> manpages are not Free enough. info pages plz!
 * directhex hides
<RainCT> mrooney: yeah, if I had to decide all packages would need manpages to enter main :P
<RainCT> there are a lot of core applications who lack one :/
<mrooney> I know, I have to use google to figure out how to edit my firefox profiles every time :[
<Hobbsee> ?
<Hobbsee> mrooney: you clearly don't use zsh.  Fix it.
<Hobbsee> mrooney: firefox -<tab>.
<Hobbsee> (assuming the tab completion stuff has been turned on, etc)
<RainCT> well, I'm off.. Good night
<Hobbsee> ;)
<ScottK> mrooney: Generally I won't advocate a package that is missing them as there is zero incentive for people to add them later.
<Hobbsee> ScottK: sure there is.  when those who aren't zsh users need to keep googling, then they might provide a patch :P
<mrooney> ScottK: but if the requirements are too high then less people can get over the hump of getting a package in ubuntu
<ScottK> True, but the leverage on the person who wants it in the archive kind of goes away.
<ScottK> mrooney: True, but I tend to think we have 'enough' and so stuff that wants in does need to meet a certain standard.
<mrooney> ScottK: yes, I suppose that makes sense. I am just trying to make it easier for people to use my package by getting it into the archives. I guess having a manpage would help that further though :)
<mrooney> however having a PPA seems 10x easier for me and about equally as easy for people
<mrooney> so that seems like an alright approach initially I guess
<ScottK> Note that I'm not super picky about how comprehensive they are as long as they point at where to find more information.
<Hobbsee> pochu: come to think of it, i'd actually argue that PPAs are both not so useful to MOTUs (although it certainly has been for some groups, like kde), but has actually done a disservice as well, with all the extra support.
<mrooney> ScottK: I think I am just feeling stuck because every review I get says "here are some issues: x x x other than that it looks good!" and then the next review by someone else will point out three NEW things to do. It feels like I am never getting anywhere. Every time I fix things there are more things to fix instead of just a consensus on what actually needs to be done.
<mrooney> But...I'll take a look at a manpage!
<ScottK> mrooney: I can understand the frustration.
<ScottK> mrooney: Although some of the comments can be, um, excessively detail oriented, I think in general it helps get better packages.
<mrooney> ScottK: I am sure it isn't so bad after the first time. There are just SO many things to learn at first about packaging.
<ScottK> Yep.
<mrooney> Watching people like kirkland throw together packages in a few minutes gives me hope :)
<ScottK> Hobbsee: Although I find PPAs useful for some thing (ubuntu-clamav PPA is one), I think in general they are a negative.
<ScottK> I can do a package for a new Python module in about an hour.
<ScottK> But I've done quite a few.
<rockstar> ScottK, is that with or without setup.py already in there?
<ScottK> With.
<ScottK> Without takes longer.
<ScottK> How much longer varies by the complexity.
<mrooney> Is there any sweet manpage maker application? I thought I heard of one a bit ago.
<ScottK> There are a number of them.
<ScottK> Depends on what you like for an input format.
<mrooney> ScottK: hmm, manual? haha I don't know what sort of inputs would be available
<ScottK> docbook2man and pod2man are two I've used.
<ScottK> Mostly I grab a man page and edit the nroff.
<mrooney> there is a python option parser, I wonder if you can use that and then create a manpage from it
<Laney> there's help2man, but I don't know how well that works
<mrooney> I think I'll just try the template for now :)
<Laney> see what help2man <binary> does, maybe it'll work
<mrooney> debuild warns that it is making rules executable every time, should I just chmod a+x it myself in VC?
#ubuntu-motu 2009-02-03
<__Ali__> i just installed a package i created, nut it doesn't appear in synaptic?
<__Ali__> but*
<anakron> how do you go to home folder in python
<anakron> $HOME
<anakron> ~
<anakron> or something else
<anakron> hi all
<Chris`> anakron: Hi, why don;t you test and find out? :)
<anakron>  i wsa testing yesterday
<anakron> but ill try to find out looking it into other python programs
<Chris`> OK good luck
<ScottK> anakron: I don't have reference material in front of me, but you ought to be able to access the envirnment and find out what $HOME  using the os module.
<anakron> i tried it, but nothing happened
<ScottK> I'd ask in #python then.
<anakron> HI al
<anakron> ping Scottk
<anakron> did you ask in #python?
<ScottK> anakron: I was suggesting that you ask in #python
<etech> do you know if openoffice 3.0.1 will be in bACKPORTS FOR UBUNTU INTREPID?
<Laibsch> etech: you can grab it from my ppa even for hardy, my nick is r0lf
<etech> Laibsch, yes. there is appa, but i would prefer to install it from the backports if it will appear there
<henrik-hw0> ATT: quick question on library management.
<henrik-hw0> in the package's .symbol file do i need to list the symbols of plugins as well as the main library?
<henrik-hw0> nothing liks directly to the plugins, well except for the main lib of course.
<henrik-hw0> plugins are only loaded runtime.
<pochu> henrik-hw0: I'd say if plugins are not in $libdir, then no. But I'm don't know well how the symbols stuff works..
<henrik-hw0> i guess they are only used for checking for ABI breakage. if that is so then listing plugin symbols is irellevant.
<henrik-hw0> plugins go in /usr/lib/librarynameVERSION/
<pochu> then I think they shouldn't
<henrik-hw0> pochu: thanks. i'll make a note of it on REVU in any case.
<henrik-hw0> another question: does it make sense to depend on linux-headers-2.6 instead of linux-headers if the software only runs on 2.6 kernels?
<stdin> linux-headers-2.6 doesn't exist
<stdin> and Ubuntu only ships 2.6 kernels anyway
<henrik-hw0> stdin: dpkg -l linux-headers-2.6
<henrik-hw0> leftover?
<stdin> $ dpkg -l linux-headers-2.6
<stdin> No packages found matching linux-headers-2.6.
<henrik-hw0> i see
<stdin> apt-cache policy shows no package either
<stdin> why does the library need linux-headers anyway?
<henrik-hw0> no... another package this time. :)
<henrik-hw0> i'm drowning in them. :(
<henrik-hw0> stdin: even have multiple versions of the same packages for added joy. :/
<stdin> you should probably depend on the specific headers package for a kernel module
<stdin> linux-headers-2.6.27-11-generic and linux-headers-2.6.27-11-server
<stdin> or linux-headers-2.6.28-6-generic / linux-headers-2.6.28-6-server for jaunty
<henrik-hw0> originally i did that, superm1 felt it would only make the package hard to maintain. (kernel header packages change a lot from version to version)
<soren> stdin: Erm.. No, you shouldn't.
<soren> The resulting binaries should have strict dependencies like that, but certainly not the source packages.
<henrik-hw0> not using the module assistant.
<henrik-hw0> using dkms meaning deps are hard-coded.
<henrik-hw0> the "binary" package is in fact built at install time.
<soren> You're completely defeating the purpose of dkms if you make the depencies so strict.
<soren> dependencies, I mean.
<henrik-hw0> noted. it's a looooooong list. i look forward to shortening it.
<soren> Eh?
<soren> Which list are we talking about?
<henrik-hw0> the list of _specific_ kernel header packages to depend on.
<soren> Don't shorten it. Remove it
<soren> The only dependency you should have is dkms.
<directhex> the entire purpose of dkms being to install the requisite deps & use them to compile a module
<henrik-hw0> ah. dkms depends on kernel-headers. good. :)
<henrik-hw0> i'll do that then. thank you very much!
<_stochastic_> If I'm repackaging a newer version of an already packaged program, is it proper to submit a debdiff to launchpad under the [needs-packaging] bug or submit the newer package to REVU?
<directhex> _stochastic_, repackaging from scratch?
<_stochastic_> directhex, I'm not sure yet, there were major changes in the upstream version
<directhex> generally you should never file a need packaging bug or use revu for things already in the archive
<directhex> just submit the updated packaging info in the form of a debdiff to a regular bug (or to debian)
<_stochastic_> oh, my mistake, it's a whishlist upgrade bug
<_stochastic_> bug #195039
<ubottu> Launchpad bug 195039 in ubuntustudio "[needs-packaging] slv2" [Wishlist,In progress] https://launchpad.net/bugs/195039
<_stochastic_> whoops
<_stochastic_> wrong one
<_stochastic_> bug #306974
<ubottu> Launchpad bug 306974 in lmms "Wishlist: Replace LMMS 0.3.2 with LMMS 0.4.0" [Undecided,Confirmed] https://launchpad.net/bugs/306974
<_stochastic_> a debdiff is already attached, Universe sponsors are subscribed but it sits and waits
<_stochastic_> directhex, would you mind taking a look at that debdiff, it's a month old; I think it may need some work (that I'm more than happy to do if it does)
<directhex> i'm not the right person to ask for C apps
<_stochastic_> okay thanks anyway
<_stochastic_> any idea who would be the right person to pester?
<hyperair> _stochastic_: what seems to be the issue?
<_stochastic_> hyperair, could you take a glance at the debdiff on bug #306974 (I'd really like to work on ironing out any issues before the Jaunty deadline)
<ubottu> Launchpad bug 306974 in lmms "Wishlist: Replace LMMS 0.3.2 with LMMS 0.4.0" [Undecided,Fix committed] https://launchpad.net/bugs/306974
<hyperair> _stochastic_: i'm not a MOTU, but yeah sure =p
<hyperair> which also means i can't give an ACK
<hyperair> but it looks like it's fix commited
<hyperair> which means it should be on its way, no?
<_stochastic_> I just switched it to that because there's a debdiff attached, is this wrong?
<hyperair> wrong.
<_stochastic_> whoops
<hyperair> fix commited means it's been uploaded already
<hyperair> switch it back
<_stochastic_> okay, sorry
<hyperair> also i don't see a debdiff
<hyperair> a debian diff.gz doesn't count. a debdiff is a difference between two debian packages
<hyperair> if you like, i could help you clean up that bug report, which should speed up things, i guess
<_stochastic_> a debian diff won't solve the bug?  I'd need to upload a debdiff?
<_stochastic_> sure
<Laney> NOOOOO
<hyperair> yeah a debdiff's needed
<hyperair> Laney: uh what?
<Laney> diff.gz is right
<hyperair> it is?
<iulian> Please attach diff.gz if it's a new upstream version.
<Laney> for a 0ubuntu1 version
<hyperair> but it should be a merge request, no?
<iulian> _stochastic_: The version number is incorrect, it should be: 0.4.2-0ubuntu1
<hyperair> oh you mean it isn't in debian?
<iulian> hyperair: The new version, no.
<hyperair> aah
<hyperair> i see
<hyperair> whoops, my bad then
<iulian> As far as I can see, the Debian maintainer doesn't want to upload a new version until Lenny is released.
<hyperair> wah
<hyperair> is there anywhere i can read about the procedure for these needs-upgrade bugs?
<iulian> Hmm, not sure.  I think we have a wiki page explaining this.
<iulian> One second.
<hyperair> a quick google search doesn't seem to show
<iulian> I found https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate but this page shows how to upgrade a package.
<iulian> We usually just attch the new diff.gz if it's a new upstream version.
<iulian> s/attc/attach
<_stochastic_> iulian, does the deb maintainer's unwillingness to release an upstream until Lenny prevent MOTU from releasing an upstream?  I changed the version number and uploaded the changed diff.gz
<_stochastic_> 0.3.2 is so buggy it's unusable
<directhex> prevent? no
<directhex> but it means procedure needs to be followed
<directhex> especially the version number
<iulian> _stochastic_: We can still upload new upstream versions to Ubuntu, even though the Debian maintainer doesn't want to upload it to Debian.
<_stochastic_> version number is fixed
<iulian> _stochastic_: OK, I will have a closer look at it.
<_stochastic_> ah, the version number inside the changelog does need some fixing too
<iulian> _stochastic_: Yeah, fix the version from the debian/changelog.  The name of the file doesn't matter.
<iulian> _stochastic_: Please see that wiki page I pasted above to see how to upgrade a package properly.
<_stochastic_> that debian diff is not of my origin, I'm just trying to push for this to get fixed, is it best to start over from scratch?
<iulian> _stochastic_: OK, if you don't want to work on this, I will comment on the bug.  I see that Dinxter is pretty active.
<iulian> _stochastic_: The process is not hard, it's explained briefly in that wiki page.
<_stochastic_> iulian, I do want to work on this, okay, I'll gladly work on this
<_stochastic_> or comment on the bug too
<iulian> _stochastic_: Excellent, please let me know if you encounter problems.
<iulian> OK, I will in a moment.
<iulian> Hiya DktrKranz.
<iulian> _stochastic_: Commented.
<DktrKranz> hey iulian
<DktrKranz> iulian, will you be at MOTU release meeting today?
<iulian> DktrKranz: Yes.
<DktrKranz> cool
 * DktrKranz needs to figure out how to fix haskell-happs-state FTBFS
<directhex> ew, haskell
<_stochastic_> iulian, I've made the version change and re-uploaded (sorry about that dumb upload earlier)
<_stochastic_> gah, TobyDox beat me to it!
<iulian> _stochastic_: I'm having a look at it right now.
<Laney> yay haskell
<Laney> DktrKranz: I bet it wasn't rebuilt when hslogger was updated so nobody picked this up earlier
<Laney> it seems to be looking for a particular version
<DktrKranz> Laney, exactly. I need to determine if there is a chain to follow
<Laney> somebody restarted happs development recently btw, yay!
<Laney> (happstack)
<DktrKranz> someone must love us, we removed gnat-4.* compilers without the need for a transition \o/
<Laney> http://happstack.com/faq.html
<Laney> "Why did you put all the packages in one repository? We are going to reorganize code amongst the packages and perhaps even deprecate some. Having one repository will drastically reduce the administrative overhead of this process." <3
<DktrKranz> "should one of us get hit by a bus" <- we need more volunteers to push in the streets
<DktrKranz> GOT IT!
<Laney> do share
<DktrKranz> I missed libghc6-happs-data rebuild
<DktrKranz> I'm pushin it right now
<DktrKranz> I'll do another test, just to make sure
<Laney> these haskell transitions are a pain
<DktrKranz> indeed
 * DktrKranz wonders if we managed everything yet
<DktrKranz> it's not that easy to see if packages have been rebuilt
<DktrKranz> anyway, now it's should just a matter of rebuilds
<DktrKranz> so, we could eventually SRU packages
<DktrKranz> given that there are unmetdeps no more
<pkt> Any autotools experts? I have a package (tulip) where after autoreconf, host_os detection is broken
<sistpoty|work> hi folks
<iulian> Hey sistpoty.
<sistpoty|work> hi iulian
<DktrKranz> jpds, I plan to do an emergency upload (0.61 ?) of ubuntu-dev-tools to incorporate changes in http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/315, several scripts are broken right now. Sounds reasonable for you?
<jpds> DktrKranz: Sure, hit it.
<DktrKranz> jpds, gracias
 * jpds goes to find out why they broke.
<jpds> Ah,I tought packages= went recursively.
<DktrKranz> no
<DktrKranz> I faced a similar issues
<jpds> DktrKranz: You might want to LP: #324749 the upload.
<DktrKranz> jpds, gah! too late :(
 * jpds closes manually.
<DktrKranz> I'll close at hand
<hefe_bia> Hi! I got a package through REVU but it was rejected from NEW because it slipped through that upstream had changed its license back to GPL-2 (from 3). I have now corrected copyright and re-uploaded to REVU (http://revu.ubuntuwire.com/details.py?package=gebabbel). Maybe somebody can have a look?
<DktrKranz> hefe_bia, if you changed only copyright line, I guess it's safe to reupload without going through the whole process. Who uploaded it?
<hefe_bia> DktrKranz: persia uploaded. In REVU you can debdiff to the previous version to verify that I only have changed GPL version.
<DktrKranz> hefe_bia, if persia couldn't manage another upload, I can do it if he or mok0 don't mind
<hefe_bia> DktrKranz: They don't seem to be around. So if it is ok not to go through the whole process again regarding such a minor change, it might be better I'll ask persia when he's back online.
<hefe_bia> Just would be happy to get this one done before FF ;)
<Laney> you can usually just fix and upload
<hefe_bia> Laney: I don't have upload rights.
<Laney> read [get somebody else to] upload
<hefe_bia> Laney: Wouldn't I risk that persia accidentally uploads it again? I don't know the process that well.
<Laney> hefe_bia: I mean that you don't have to go through revu again, not speaking for who should do the upload
<hefe_bia> Laney: ok, now I understand ;) I think it's best to wait until persia is around and ask him to reupload.
<slytherin> NCommander: pm?
<NCommander> slytherin, sure
<ScottK> NCommander: Any word on soprano?
<NCommander> ScottK, huh?
 * NCommander is currently putting about four or five fires at once
<slytherin> is packaginga software considered as 'derived software'?
<ScottK> NCommander: Remember a coupld of days ago you said you'd look into why soprano wasn't installable on armel?
<ScottK> NCommander: It's currently blocking KDE builds.
<NCommander> Ok, let me do that
<ScottK> Thanks.
<NCommander> I'm sorry, I'm dealing with OMG WE"RE TWO WEEKS FROM FEATURE FREEZE time
<ScottK> slytherin: People argue about that.  I don't think there's a clear answer.
<slytherin> ScottK: I was reading this license - http://jcharts.sourceforge.net/license.html Condition 3 is the one I am concerned about.
<ScottK> slytherin: That should be fine.
<slytherin> ScottK: I guess I am still going to mail the upstream author.
<ScottK> slytherin: Couldn't hurt, but that's very close to the advertising clause in the old 4 clause BSD license which is considered (hold your nose) DFSG free.
<slytherin> ScottK: in worst case the package would end up in multiverse, right?
<ScottK> I think so.
<directhex> anyone reckon ironscheme is worth packaging?
<sistpoty|work> directhex: I assume we have enough scheme interpreters already... or would that help mono/.gnu in some regards?
<sistpoty|work> directhex: otoh, I'm not aware of scheme compilers (at least not working ones)... but that knowledge is from two years back ;)
<directhex> sistpoty|work, well, it'd allow writing scheme apps w/ access to all mono libs. i don't know if anyone cares though, it's not as if scheme's really all that popular outside research departments and gimp plugins
<sistpoty|work> directhex: ah, I see... maybe you could try to google for scheme apps that use mono libs? and see if there exits more than only a handful?
<directhex> sistpoty|work, i don't know whether people really use things like ironscheme or ironlisp or even ironpython & ikvm outside "tinkering" status. question is, is it a "build it and they will come" or a "yet another junk package"
<sistpoty|work> directhex: hm... that's a good question... and I can't really say I'd know the answer
<directhex> sistpoty|work, i would like as many iron* as possible, to allow people to use "any" language yet get all the benefits of mono... but the gig question is how much time it's worth.
<directhex> sistpoty|work, ironclad is also interesting, as it allows use of compiled cpython in ironpython
<anakron> hi all
<aboudreault> hi ppl.
<aboudreault> i have a small question about the changelog file...
<aboudreault> If i take a package from debian, (ie package X version 1.4.0) and i want to build the package for ubuntu. Even if the version that i want to build is the same as the debian package, should i create another entry with "debchange" ?
<mok0> aboudreault: make it X_1.4.0-0ubuntu1 (assuming that the Debian version is 1.3.*)
<mok0> aboudreault: I misread your question, sorry
<aboudreault> oh... u r right... in any case... i must add "ubuntu1"
<mok0> aboudreault: if the package is the same, you should not change anything, just build the package
<mok0> aboudreault: if you fix something, append "ubuntu1"
<dolanor> Hello
<dolanor> needs a MOTU to advocate the fsniper package :) : http://revu.ubuntuwire.com/details.py?package=fsniper
<aboudreault> ok, only if i fix something i'd add "ubuntu1". good
<aboudreault> thanks mok0.
<aboudreault> mok0: sorry, last question.. this is the line of the debian package: X (1.6.0-1) experimental; urgency=low
<mok0> aboudreault: ok
<aboudreault> Is it ok if i let the "experimental" ?
<aboudreault> Is it very important ?
<mok0> aboudreault: it should be jaunty or whatever release you are compiling it for
<mok0> aboudreault: but you don't need to touch it if you don't make modifications
<mok0> aboudreault: I keep forgetting that you aren't doing modification
<aboudreault> :)
<aboudreault> that's great. i'll finish this package and upload it to launchpad.
<aboudreault> mok0: arg i forgot this problem... gpg: skipped "Francesco Paolo Lovergine <frankie@debian.org>": secret key not available
<aboudreault> i must sign the package for launchpad
<pochu> aboudreault: dpkg-buildpackage -k$keyid -S
<pochu> where $keyid = something like 0xAE498D18
<aboudreault> oh, i take this in note too. thanks a lot.
<pochu> mok0: hey, just in case I didn't explain myself well, my mail wasn't personal, it's just that I think the takeover should had been public, but I'm happy with you being the new liason ;)
<mok0> pochu: then you shouldn't have written the email
<mok0> pochu: it doesn't make sense to write and say "Hey I'm angry about not being asked but I would have said no anyway"
<slytherin> aboudreault: what are you trying to do exactly?
<mok0> pochu: I know it wasn't personal :-)
<ScottK> mok0: It won't suprise you to find I disagree.  I'd put it as you don't have the job until you are hired.  We like hiring you, we'd just like to actually do that before you do the job.
<mok0> ScottK, yeah... except... we had already started working
<mok0> ScottK, so there was no way I could pretend it was not a de-facto thing
<ScottK> Understand.
<mok0> Anyway, I need to get hold of bigjools and tell him not to consider the MOTU priorities
<mok0> I think it
<mok0> is too late
<ScottK> It's a wiki.  You can just edit it.
<mok0> ScottK, yes, but I am somewhat wary to destroy the evidence, so to speak
<mok0> I can put a note there though
<ScottK> mok0: If it's a proper wiki, it'll have versioning, so the history is there.
<aboudreault> pochu: Am i wrond if i say that i should always use "debuild" instead of "dpkg-buildpackage" if i always use cowbuilder to build my packages ?
<mok0> Right, but if ppl come along to read the ML in the next few days, they will want to be able to see what all the fuzz was about
<pochu> aboudreault: no idea, never used cowbuilder
<pochu> but I think debuild is just a wrapper around dpkg-buildpackage
<aboudreault> cowbuilder is just a wrapper for pbuilder.
<aboudreault> ha.
<ScottK> I'd say then make a reply to the ML and say what you've done.
<hyperair> asac: ping
<bddebian> Heya gang
<sistpoty|work> hi bddebian
<bddebian> Hi sistpoty|work
<iulian> Heya bddebian.
<bddebian> Hi iulian
<jdong> lovely.
<jdong> Brasero on x86_64 just told me that it burned "381"MB on my 4.3GiB ISO.
<jdong> sounds like someone didn't put enough longs on that variable name ;-)
<ScottK> jdong: Are you OK with the backports improvement spec?
<jdong> ScottK: sorry I'm out of touch with the outside world; can you link me to it and I'll read it over?
<ScottK> Just a moment.
<jdong> k, I need to run to class; I'll check my scrollback for the link
<geser> Hi bddebian
<ScottK> jdong: https://blueprints.launchpad.net/intrepid-backports/+spec/selective-backport-support
<bddebian> Heya geser
<henrik-hw0> RALink WiFi drivers now fixed up and tested. Any eager souls online?
<jpds> AndrewGee: osm-gps-map accepted into jaunty.
<jlc> henrik-hw0: ping
<henrik-hw0> jlc: hi.
<jlc> hello
<jlc> do you have a driver for rt2860 for  jaunty-mid-lpia.img?
<henrik-hw0> i have a driver for rt2860 but i haven't tested it on hardware nor LPIA.
<jlc> ok, I can probably test it then
<henrik-hw0> jlc: it would be nice to get some feedback if it works on that configuration.
<jlc> is it i386 and not lpia?
<henrik-hw0> jlc: it's an architecture independent package.
<jlc> dkms?
<henrik-hw0> jlc: yup.
<jlc> k
<jlc> were is it at
<jlc> I'll install the lpia version of jaunty and i386 and test it out
<henrik-hw0> jlc: http://revu.ubuntuwire.com/details.py?package=rt2860-linux-sta
<jlc> henrik-hw0: is there a deb for it or just source?
<henrik-hw0> jlc: if you wait i could upload it to PPA.
<jlc> henrik-hw0: I can wait, downloading daily build iso's now
<jlc> brb, need to make some lunch
<jdong> ScottK: I like the general idea and behavior described in the spec, though I'm not 100% confident that pinning is the method we should settle upon for effecting it
<jdong> ScottK: I'd like to look more into mvo's "NotAutomatic" flag
<ScottK> jdong: Yeah, well I was going to just leave that as an implementation detail to mvo.
<ScottK> If you're OK with the concept, I want to push to get it approved.
<jdong> ScottK: gotcha; but yea, I love the concept
<loic-m> I'm dealing  with a package that has Ubuntu modifications for some translations (2 languages)
<loic-m> Upstream has released many moer versions of the program, so their new .po files are different
<loic-m> What's the method to deal with that?
<loic-m> Can we drop the ubutnu modifications (strings translated differently)?
 * sistpoty|work calls it a day and heads home... cya
<asomething> I know about http://qa.ubuntuwire.com/uehs/  but is there anything that will automatically email me when a new upstream package is released for Ubuntu? Debian PTS does this for stuff I maintain there..
<quadrispro> hi superm1! I've added a comment here http://revu.ubuntuwire.com/details.py?package=w-scan
<quadrispro> superm1: let me know! ;)
<superm1> quadrispro, yeah lets wait until a few days before FF.  if it gets into debian buy then we'll sync it in, if not we'll upload something like UPSTREAM-DEBIAN~ubuntu1
<superm1> so it gets synced at jaunty+1 automagically
<quadrispro> superm1: perfect!
<ScottK> superm1: If you want it to be automatic make it something like -0build1
<superm1> ScottK, can you expand that to a real version number.  Lets say debian had 0.1-1, you mean 0.1-0build1 ?
<ScottK> Yes
<Laney> Is it just "ubuntu" that blocks autosyncing?
<ScottK> 0.1-1~ubuntu1 you'd need to requestsync to get it synced
<ScottK> I think it's the other way around that build is special and doesn't block it.
<Laney> ah
<Laney> I was going to suggest 0debian1, but never mind
<superm1> wouldn't 0.1-1~build1 be more representative of the fact that it's -1 from debian though?
<ScottK> I suppose.
<superm1> or maybe this is all just irrelevant
<ScottK> I actually think it's better to -0ubuntu1 and then requestsync when the time comes
<RainCT> (btw, if someone here wants a bitesize packaging task, I've got one)
<jpds> What should we do with bugs of packages which have been removed from the archives? Mark them as Won't fix?
<JontheEchidna> I would think that we could won't fix non-packaging bugs
<JontheEchidna> packaging bugs could probably only be won't fixed if the bug either don't apply to packages in currently supported series
<jpds> JontheEchidna: The package was in the archive when the bug was filed but has since been removed.
<JontheEchidna> or if the package is no longer in any currently supported series
<pochu> jpds: yeah, either wontfix or invalid
<jpds> pochu: vale.
<ScottK> I'd say wontfix if not sru worthy and the package is still in a supported release.  Leave it open if potentially SRU worth.  Invalid if it's not in a supported release.
<EagleScreen> hello i have a small problem, when i run dch -i or -e to edit the changelog, my email address appears wrong in the changelog
<EagleScreen> DEBMAIL variable has the right value
<oojah_> EagleScreen: DEBEMAIL
<oojah_> (note the extra E)
<EagleScreen> oh thanks
<oojah_> no probs :)
<ScottK> EagleScreen: Also minus points for asking the same question in multiple channels.
<EagleScreen> some persons who can help me are in a channel but not in the other..
<EagleScreen> is it bad to ask something in all related channels?
<maxb> EagleScreen: In much the same way as cross-posting across multiple mailing lists of a project, it's discouraged
<Amaranth> EagleScreen: Yes, you should ask in one channel, wait to see if you get a response, then maybe try somewhere else.
<rexbron> Does anyone have any suggestions for working around non-http accessable directories in tarball urls?
<rexbron> In my case, http://ffado.org/files/<tarball> is accessable
<rexbron> but http://ffado.org/files/ 404s
<piratenaapje> rexbron: Is there a page that links to the latest tarball?
<piratenaapje> rexbron: Like the home page?
<rexbron> there is the downloads page that links to the tarball
<piratenaapje> you could try something like
<rexbron> but that  url changes with each release
<rexbron> and kind of defeats the purpose if uscan imo
<rexbron> of rather
<piratenaapje> rexbron: in your debian/watch file: http://downloadspage referral link
<piratenaapje> where referral link is the link in the html code
<rexbron> I'll take a look
<piratenaapje> rexbron: An actual example I use: version=3
<piratenaapje> https://www.getdropbox.com/downloading?os=lnx /download\?dl=packages/nautilus-dropbox-(.*)\.tar\.bz2
<EagleScreen> yes, you have reason, i asked very soon in the other channels, i must be more patient, sorry, i will try to do not do this again
<RainCT> urgh.. Number 1 on the Launchpad 3.0 list should be making it faster
<ScottK> +1 for RainCT
 * JontheEchidna doesn't like the web interface for copying packages in ppas
<JontheEchidna> but I guess that's soyuz not launchpad?
<ScottK> Soyuz is part of Launchpad.
<ScottK> For Soyuz though I think stuff like don't FTBFS if a build-dep is uninstallable, just dep wait is a lot more important.
<pochu> or being able to sync packages from Debian without needing an archive admin
<vadi2> Hi - how to make a window that popups up when a user is installing a package to tell them something important?
<mok0> vadi2:  look at debconf
<POX> vadi2: ... or via debian/NEWS (see `dch --news` and f.e. apt-listchanges package)
<ScottK> Debconf is for questions, not informing.
<vadi2> hm
<vadi2> and does debian/news get shown to people?
<vadi2> I think what I was looking for is "update-notifier", but it is hard to figure out
<maxb> vadi2: It depends.... how critical is the information?
<vadi2> quite
<vadi2> the program got renamed
<vadi2> need to inform them, or they think it dissapeared
<maxb> Hm. I'm not sure that would normally be proactively notified
<dtchen> it shouldn't be, really
<ScottK> Generally users don't get notified of such things.  It just happens.
<vadi2> So if they keep updating from our repository, they won't have a way of telling
<dtchen> at most, provide a migration path via a symlink (if necessary)
<vadi2> the logo, program name are changed
<dtchen> err, did the package name or the binary executable name change?
<vadi2> both did
<ScottK> Turn the old package name into a dummy package that depends on the new one.
<dtchen> well, the former is simple: provide a dummy...
<vadi2> That's what we did, so they are able to upgrade to the rename
<vadi2> They can still miss though imho, so I'd like a notification
<dtchen> you could also make said dummy package provide a symlink in /usr/bin if you're really concerned
<vadi2> ?
<vadi2> This is a graphical app
<dtchen> with a menu entry?
<vadi2> When they go to the usual applications - accessories place, it will not be there
<vadi2> right
<vadi2> another name with another logo will be there
<dtchen> if it has a menu entry, why would you want the user to be concerned?
<vadi2> because the old one will be gone
<dtchen> just document in the change prominently in debian/control:^Description
<vadi2> eh?
<dtchen> "This package replaces oldpackage and provides a new blahblahblah in Applications> blahblahblah"
<dtchen> FWIW, using updatenotifier
<vadi2> They might miss that during the upgrade though
<vadi2> I for one don't look at all of the packages that are being upgraded when there's a bunch :\
<dtchen> sure, but keep in mind that many users will ignore update-notifier's notices
<vadi2> that too, but at least its a better change
<vadi2> *chance
<vadi2> it gives a tooltip and whatnot
<dtchen> well, it's quite straightforward; see /usr/share/doc/update-notifier/HOOKS
<vadi2> aha :)
<vadi2> I don't have such a file :(
<vadi2> only /usr/share/doc/update-notifier/ and /usr/share/doc/update-notifier-common/
<dtchen> if you need examples, see libasound2.p{ostinst,rerm} in the alsa-lib source package
<vadi2> alsa-utils? alsa-lib doesn't exist
<dtchen> alsa-lib is the name of the *source* package
<dtchen> also, HOOKS is viewable at http://package-import.ubuntu.com/u/update-notifier/jaunty/annotate/head%3A/HOOKS
<vadi2> thank you
<khashayar> Anyone interested in revuing http://revu.ubuntuwire.com/details.py?package=rtirq
<khashayar> It's a very tiny package, easy to review :-)
<AndrewGee> Whoops. I was looking through the needs-packaging bugs. Found one unassigned, so decided to work on it. Just found someone already started packaging it on REVU, but didn't assign the bug. I've uploaded on top of them. What should I do?
<dtchen> combine the efforts
<__Ali__> how can you ask Build-Depends to go for 4.2 =< gcc < 4.3?
<pochu> __Ali__: Build-Depends: gcc-4.2 ?
<__Ali__> is it the same as gcc (= 4.2)?
<__Ali__> i guess not, thanks!
<directhex> ubuntu is capable of having multiple parallel-installed gcc versions
<directhex> each has its own package and own command name
<ScottK> Put it in bulid-dep twice.
<ScottK> True.
<directhex> gcc-4.2 contains gcc-4.2
<ScottK> build-dep on the versioned package should do it.
<directhex> gcc-defaults is the source package whose "gcc" package contains the current ubuntu default and the "gcc" symlink
<zMoo> hi
<zMoo> when we upload a package using dput
<zMoo> can we see this package in revu immediatly?
<zMoo> I can not see my package
<zMoo> is it normal?
<maxb> It's not entirely immediate
<zMoo> I see
<maxb> Give it 5 minutes, if it's still not there, then come back here if it hasn't shown up
<zMoo> it was 10-15 mintues ago
<maxb> Say what the package name is, then, so if a REVU admin looks at this channel, they know what to look for
<zMoo> the package is called swac-play
<zMoo> "A new package has been accepted into REVU: swac-play" OK
<zMoo> I'll wait 5 minutes
<zMoo> the package is now in the list of packages that "Needs Review"
<zMoo> \o/
<zMoo> great
<zMoo> I can now go sleep
<zMoo> thank you maxb
#ubuntu-motu 2009-02-04
<__Ali__> maxb, any idea why my packages do not appear in synaptic after installation?
<__Ali__> i didnt sign them, but that shouldnt be a problem
<maxb> __Ali__: Personally I have no experience with synaptic, preferring dpkg and apt-get
<sommer> cody-somerville: quick question about the 2nd item in https://bugs.launchpad.net/ubuntu/+source/ebox/+bug/314606/comments/4
<ubottu> Launchpad bug 314606 in ebox "ebox and libebox don't support Intrepid gconf version" [Undecided,Fix released]
<sommer> cody-somerville: does that mean I should close the bug and didn't, or I should not close the SRU bug in the changelog?
<xnox> Hello everyone =D
<xnox> Upstream ships ltconfig in their tarball/svn. But they use autogen.sh autotools and frieds.
<xnox> lintian complains that ltconfig is acient. I'm wondering were do I get a new one
<xnox> or is it still needed at all?
<ramirand> Hi. I'm looking for advice on the best way to get some patches back into one of the packages.
<fabrice_sp> ramirand, Hi. If it's a patch to the packaging, submit it to debian, otherwise, submit it to upstream
<fabrice_sp> (or you mean the contrary?)
<ramirand> fabrice_sp: Sorry, off reading Bugs/HowToFix, I think it has the answers. Thanks!
<fabrice_sp> ok
<didrocks> morning
<Laney> good morning
<jpds> Morning Laney.
<Laney> how goes it jpds?
<jpds> Not bad at all, ta, how about yourself?
<Laney> Good! Just got into uni, fun paper to read
<tuxmaniac> why does package names gets altrered from that of upstream name. Is there any specific guidelines as to when this should happen
<tuxmaniac> because a package by name iverilog is present in the debian/ubuntu repos as "verilog". I dont know the reason. Any pointers where I can look for it?
<tuxmaniac> it is confusing as someone who searches for apt-cache search iverilog does not get any results
<tuxmaniac> may be a small issue. but still..
<Laney> NO!
<Laney> huats beat me to be the first person on the new application procedure
<huats> :)
<huats> sorry Laney ;)
<Laney> bah
<Laney> well done though \o/
<huats> Laney: don't congratulate me now...
<huats> nothing is done :)
<Laney> heh
<huats> so far I just sent a mail...
<Laney> you are a groundbreaking innovator
<Laney> even if you get rejected :P
<dholbach> Laney: and it seems like there's a lot of new applications in progress :)
<Laney> heh
<Laney> the all-seeing eye of dholbach
<dholbach> my crystal ball :)
 * Hobbsee coats dholbach's crystal ball in hot wax
 * Hobbsee paints the MOTU purple.
<dholbach> I'm glad it's just the crystal ball that got put into how wax
<Laney> huats: What's this symbols script? Would it be worth going into u-d-t?
<huats> Laney: I have talked with dholbach, seb128 about it...
<Laney> sexy
<huats> not sure for the moment...
<huats> may be later
<Laney> well we had pbuilder-dist and pbuilder-dist.new both around for a while
<iulian> Hmm, why is ~motu still a member of the ~revu-uploaders team in Launchpad?  That team is obsolete and should be removed as well.  I see no reason why we should keep it.
<iulian> Should I send an email to ubuntu-motu@l.u.c asking for its removal?
<DktrKranz> iulian: I've just seconded your application :)
<DktrKranz> and you can ask motu-council members to remove the team from ~motu
<DktrKranz> (less emblems \o/)
<iulian> Less bragging rights.
<directhex> if you want more emblems, just join dholbach-huggers et al
<DktrKranz> I want *less* :)
<iulian> DktrKranz: Thanks.  Should we tell a MC member to add me to the team?
<DktrKranz> iulian: IIRC, KeyTeams policy requires two adovocates and seven days before being added to the team, but I could be wrong
<DktrKranz> anyway, I think the second one won't be too late
<iulian> DktrKranz: Stefan just replied as well.
<DktrKranz> hehe
<iulian> +has
 * iulian wonders what we should do with ~revu-uploaders.
<Hobbsee> merge it with u-u-c?
<Laney> no, delete it I guess
<DktrKranz> personally, I'd delete it for good
<iulian> Yes, let it go away!
 * iulian looks for a MC member.
<Laney> We should probably get approval from a REVU bod first
<iulian> Laney: I talked to RainCT about it.  Everything is fine.
<Laney> that's approval then
<iulian> If I recall correctly, he didn't remove it because of every ~ubuntu-dev member will get a notification mail or something.
 * ScottK just replied too
<ScottK> In any case he'll be in before FF.
<iulian> ScottK: I believe the seven days have passed.  The only remaining thing now is to add me to the team.
<ScottK> Great
 * jpds wondesr why mkfs.ext4 is in intrepid, and when one tries mounting it says it's not supported by the system.
<soren> jpds: Because one is userspace the other is kernel?
<soren> You can run mkfs.ext4 on a 2.0.38 kernel if you so please. That's not going to get you any close to mounting it, though :)
<jpds> soren: Right.
 * ^Spear prods jpds 
<^Spear> lo
<henrik-hw0> mok0: rt28xx drivers was included in jaunty kernel's staging section a while ago.
<jcfp> http://revu.ubuntuwire.com/details.py?package=sabnzbdplus (popular binary newsreader, written in python) needs a second advocate - please consider for review.
<iulian> RainCT: Hiya, please take a peek at http://paste.ubuntu.com/113591/plain/.  Would you like to say a final word?
<iulian> Just to be sure...
<zMoo> hi! is it possible to delete a package from revu (before downloading a new version of the pacakge) ?
<loic-m> zMoo: I'm not sure, but anyway you can upload a new version of the package without problems (even if the two uploads have the same revision)
<zMoo> thank you, loic-m
<loic-m> zMoo: you're welcome
<zMoo> is it mendatory to open a "needs-packaging" bug for each new package?
<loic-m> zMoo: not totaly, but if you don't somebody will tell you that your need to have " * Initial release (LP# bug_number)" in your changelog
<cody-somerville> sommer, You should close the bug and didn't
<loic-m> It's also better so 2 people don't work on the same package, and help keeping track of your progress
<asac> hyperair: please just ask ... pinging adds one more roundtrip to converstaions ;)
<__Ali__> after installing a .config file to /etc/ld.so.conf.d/, it is necessary to call ldconfig explicitly or does cdbs take care of this?
<hyperair> asac: could you look into Bug #248705 for an SRU -- you uploaded the fix for Jaunty, and between Intrepid and Jaunty is just one ubuntu revision away.
<ubottu> Launchpad bug 248705 in evolution-data-server "Evolution Exchange does not authenticate to Exchange servers with a relative path in the form action, e.g. "owaauth.dll"" [Undecided,Fix released] https://launchpad.net/bugs/248705
<asac> hyperair: ok. i see a hardy debdiff ... what about intrepid?
<hyperair> asac: hardy and intrepid are both there
<asac> hyperair: not for me ... at lesat there is no "sru" version
<asac> juding from SRU
<hyperair> oh yeah!
<hyperair> um
<hyperair> the jaunty debdiff should apply for intrepid
<asac> k
<hyperair> asac: after all the fix was from 2.24.3-0ubuntu1 ->ubuntu2, and currently intrepid has 2.24.3-0ubuntu1
<asac> ok approvd
<hyperair> asac: thanks
<asac> hyperair: if the upload doesnt happen in the next few days, please ping me
<sommer> cody-somerville: thanks for clarifying
<hyperair> asac: ok
<vadi2> Does anyone know when exactly is the /var/lib/update-notifier/dpkg-run-stamp file updated?
<savvas> Is anyone else facing problems with uscan/uupdate ?
<savvas>   http://qa.debian.org/watch/sf.php/libmtp/libmtp-0.3.6.tar.gz failed: 500 Can't connect to garr.dl.sourceforge.net:80 (connect: timeout)
<savvas> ah ok, it worked now
<RainCT> uhm.. why doesn't the bluetooth applet allow to disable bluetooth? :P
<DktrKranz> RainCT: with your "and me" mail, did you intend to candidate yourself or to second iulian's ?
<zMoo> what is the right way to find MOTU advocates on REVU? I've just upload a package that seems to be clean of warnings :
<zMoo> http://revu.ubuntuwire.com/details.py?package=swac-play
<zMoo> iulian: thank you for having upload swac-get 0.5
<RainCT> DktrKranz: iulian
<RainCT> DktrKranz: I've send another mail clarifying that
<DktrKranz> RainCT: cool thanks ;)
<iulian> zMoo: Thank you.
<DktrKranz> RainCT: I was planning to second you :P
<iulian> RainCT: What should we do with the revu-uploaders team?
<vadi2> I'm having a bit of an issue with update-notifier - documentation says it checks for update hooks when the "/var/lib/update-notifier/dpkg-was-runÂ changed" file is changed. When I install a package, the file does get changed - however, no notification is given. Only if I change the file after (like a check for updates) does the trigger go off.
<RainCT> DktrKranz: Hehe. Well, thanks! Perhaps I'll apply somewhen in the future :)
<DktrKranz> RainCT for president!
<RainCT> iulian: it can be deleted
<RainCT> :D
<iulian> RainCT: OK, excellent.
<iulian> Any MC members around?
<RainCT> nixternal: *poke* :)
<iulian> Ouh, that's not polite :)
<RainCT> uhm.. I'm admin of revu-uploaders, if that's why you're poking
<RainCT> (er.. why you are asking and I'm poking :D)
<iulian> Can you delete it then?
<nixternal> yo yo RainCT
<RainCT> if someone tells me how to do that.. :)
<RainCT> nixternal: sorry, nevermind :)
<iulian> RainCT: No "Delete team" button?
<RainCT> iulian: nope
<nixternal> jeesh, had me excited there for a second..thought you wanted to give me some free money
<iulian> Then we still need nixternal.
<RainCT> iulian: why? MOTU Council *isn't* admin of revu-uploaders
<Laney> RainCT: You need to post an answers ticket on /launchpad/ to have a team deleted
<RainCT> d'oh
<iulian> Err
<iulian> Why can't delete if you registered it?
<RainCT> because LP is that weird :)
<Laney> because LP doesn't allow it :(
 * iulian agreed.
<iulian> RainCT: Then please go ahead and ask a question to have it deleted.
<RainCT> just done that
<RainCT> Â«
 * iulian is impressive.
<RainCT> In an evil attempt to drop the average of members in a Launchpad team, I'm requesting the revu-uploaders team to be deleted. Oh, and you can also drop ubuntu-dev-without-bugmail when you're at it :).Â»
<iulian> s/impressive/impressed
 * RainCT goes to fix the bitesize bug which nobody wanted yesterday :P
<iulian> I think you should ask a different question regarding ubuntu-dev-without-mail.
<iulian> Not sure though.
<RainCT> Why? Questions are parsed by humans, not bots :P
<iulian> Yeah, fortunately.
<RainCT> YokoZar: btw, wine's manpage doesn't document "wine eject". Should I file a bug or something about that?
<soren> wine eject? What does that do?
<RainCT> soren: eject the CD even if the drive is locked (that's needed for example in order to install games which have two CD.. the drive will be locked when the installer is running so "wine eject" next to be used to put in CD 2)
<hyperair> hmm that's cool, i usually forced it to eject using umount -f or something
<zMoo> Hi, does anybody knows what means this error during upload of package in REVU (MOD_PYTHON ERROR) http://revu.ubuntuwire.com/?archive=4886
<RainCT> that there's a bug :P
<zMoo> my both packages swac-get & swac-scan have this error
<zMoo> oups
<zMoo> swac-play & swac-scan
<RainCT> zMoo: but anyway, that URL is to archive a package.. or is that what you want to do?
<zMoo> I don't want to archive them
<zMoo> there is a little icon on the main list
<RainCT> yes, the icon is to archive the package :P
<zMoo> :)
<zMoo> I see
<zMoo> I didn't understand why I'm the only one who have this icon
<zMoo> I understood
<zMoo> :)
<zMoo> cause that's my packages
<RainCT> you aren't the only one - reviewers and moderators also have it
<zMoo> yes
<zMoo> RainCT: now, after having uploaded my packages, I juste have to wait for comments?
<zMoo> I'm new on REVU
<pochu> zMoo: you can ask for reviews here
<pochu> but nothing else you should do
<zMoo> I see
<zMoo> Can anybony can check my package "swac-play"? Swac-play is a great program that enable to play sounds from audio collections of words from the Shtooka Project
<RainCT> pochu: well, he could also give MOTUs gifts so that they look at his package :D
<pochu> RainCT: true that :)
<zMoo> I give every MOTUs audio collections of ukrainian words!
<zMoo> thare are more than 16 000 words in this collection :)
<pochu> zMoo: I'd start by giving a link to your package and saying what it is ;)
<zMoo> ok
<zMoo> http://revu.ubuntuwire.com/details.py?package=swac-play
<vadi2> I'm having a bit of an issue with update-notifier - I can't get it to go off reliably. I put the proper file at the postinst hook, however it doesn't go off right after the package is installed - it randomly goes off either when I check for updates or refuses to at all. Is there some trick to this?
<zMoo> Here is a new package for a very usefull program
<zMoo> it is a simple command line program that enable to listen sounds from audio collections of words
<zMoo> audio collections of words have to be loaded in a local SQLite3 database with swac-get (thas is already in Jaunty)
<zMoo> then you can use a GTK front end to browse the database: swac-explore (that is already in Jaunty)
<zMoo> or to use a command line interface: swac-play
<zMoo> for exemple you can do something like: swac-play --lang=rus Ð´ÐµÐ»Ð°ÑÑ
<zMoo> swac-play will retrive the url of the sound file and play it with GStreamer
<zMoo> *retrieve
<zMoo> or swac-play --lang=fra "avoir les yeux plus gros que le ventre"
<zMoo> so it possible to listen sounds with such programs like StarDict
<zMoo> (an electronic dictionary)
<zMoo> pochu: what do you think about such a wonderful program?
<slytherin> geser: is there any convention that a jar file in a package should have name in lowercase? is jCharts.jar acceptable?
<pochu> zMoo: sounds wonderful
<pochu> zMoo: will I be able to listen to English words, without the need to go to dictionary.com then? :)
<pochu> zMoo: are the sound files of high quality?
<zMoo> except the Dutch collection, the quality is very good
<pochu> zMoo: sounds good. I'll give it a review later today
<zMoo> here is a old web interface the enable to browse audio collections http://swac-collections.org/
<zMoo> here are the statistics
<zMoo> http://swac-collections.org/statistics.php
<zMoo> Total: 77709 records
<pochu> awesome
<pochu> I think I'm going to remove my dictionary.com bookmark soon ;)
<surfaz> pochu, could you see your mail inbox?
<geser> slytherin: how are jars referenced in apps? by filename?
<zMoo> in fact the main part of these records was already uploaded to wiktionary
<slytherin> geser: this is just a library which is dependency of jmeter. Let me check how jmeter refers to the library.
<RainCT> zMoo: nice, I'll also have a look at it later
<slytherin> geser: jmeter binary distribution contains the library with name jCharts-0.7.5. So I am assuming that jmeter launcher script must be using same name.
<iulian> zMoo: Me too.
<pochu> surfaz: sure
<zMoo> RainCT, iulian, pochu: the first thing to do is to build the database with swac-get (0.5)
<zMoo> http://shtooka.net/soft/swac-tools/en/ for more information
<RainCT> mok0: have you already changes something in index.py?
<iulian> zMoo: Do you have packages ready for review?
<zMoo> yes
<zMoo> swac-explore is waiting for upgrade (like swac-get)
<zMoo> and there are 2 packages on REVU
<zMoo> http://revu.ubuntuwire.com/details.py?package=swac-play
<zMoo> http://revu.ubuntuwire.com/details.py?package=swac-scan
<iulian> zMoo: Excellent.  I will upload swac-explore in a minute.
<zMoo> \o/
<slytherin> geser: jmeter does not look for a particular name. It simply loads all the jar files in a particular directory.
<pochu> surfaz: replied :)
<zMoo> https://bugs.launchpad.net/ubuntu/+source/swac-explore/+bug/324994
<ubottu> Launchpad bug 324994 in swac-explore "New Upstream version 0.4" [Undecided,Confirmed]
<iulian> zMoo: Yeah, I've seen it.
<geser> slytherin: in that case, use the filename you like better, I don't know of any policy
<slytherin> geser: ok. I will keep the upstream file name then.
<geser> slytherin: http://www.debian.org/doc/packaging-manuals/java-policy/x105.html
<geser> but don't ask me if it's still in use or even up-to-date
<RainCT> zMoo: (he bug your reported is now fixed)
<RainCT> s/he/the
<zMoo> RainCT: Great, Thanks!
<slytherin> geser: the policy doesn't say anything about the case (upper/lower) of the name.
<DktrKranz> iulian: welcome aboard! :)
<Laney> iulian: Can haz FFE plz?
<iulian> zMoo: swac-explore has just been uploaded.
<slytherin> is the use of http://wiki.debian.org/Proposals/CopyrightFormat acceptable (and encouraged) these days?
<iulian> DktrKranz, Laney: Thanks :)
<slytherin> iulian: Congrats. :-)
<zMoo> iulian: Thanks a lot!
<iulian> slytherin: Thank you.
 * iulian wonders if Laney has seen debian bug #514134
<ubottu> Debian bug 514134 in wnpp "ITP: haskell-ghc-paths -- Knowledge of GHC's installation directories" [Wishlist,Open] http://bugs.debian.org/514134
<iulian> I've said that because I saw you're interested in haskell.
<RainCT> slytherin: it is
<slytherin> RainCT: and I suppose I should mention latest revision in the format specification, right?
<RainCT> slytherin: the URL of the spec goes there (including the revision string)
<slytherin> ok
<slytherin> geser: Do you have some time for package review?
<slytherin> RainCT: how can I subscribe to motu-reviewers list at ubuntuwire.com?
<dolanor> back
<dolanor> needs some MOTU advocate on REVU for the fsniper package : daemon that watch files and apply rules when files are created or modified - http://revu.ubuntuwire.com/details.py?package=fsniper
<iulian> zMoo: swac-play commented on REVU.
<zMoo> je viens de voir Ã§a
<zMoo> oups
<zMoo> I saw, thanks
<zMoo> iulian: so you think I have to rebuild the package from a new upstream package?
<superm1> henrik-hw0, so what's the deal with these rt* drivers being in staging?
<superm1> are they getting built in staging, or is the source just living there?
<superm1> i was just about to do another revu of your package but saw that comment
<superm1> based on http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=blob;f=debian/config/i386/config;h=d4923624e5c49e14294de2a2d6714f98fba75bf7;hb=HEAD , i would guess they aren't getting built there
<iulian> zMoo: I'm not sure. I think it won't be accepted if the COPYING file mentions GPL-3 and debian/copyright GPL-2+.
<henrik-hw0> superm1: i have no idea to be honest.
<superm1> henrik-hw0, can you check with rtg on it then?
<henrik-hw0> superm1: i was just mentioning it because i thought it was relevant.
<superm1> yeah looking at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=blob;f=drivers/staging/Kconfig;h=8b6c93b61a2e8a00859023b7732c3a28f42b95ce;hb=HEAD it looks like that line about staging exclude build means it will not be built
<superm1> i'll do a revu then, but perhaps you can see if rtg will just enable staging.  if so, that will save some troubles
<geser> slytherin: which package?
<slytherin> geser: jcharts
<slytherin> geser: http://revu.ubuntuwire.com/details.py?package=jcharts
<slytherin> geser: I haven't filed a bug yet. Once it is advocated by someone I will file a bug and close it in changelog.
<henrik-hw0> superm1: so basically i should ask rtg aka. mr. Garnder if i should keep working on the packages or if he'll enable the driver for compilation?
<superm1> henrik-hw0, yeah.
<henrik-hw0> superm1: ok, noted.
<superm1> henrik-hw0, okay one more thing then.  this should be the last thing i see in the package regarding revu stuff
<superm1> henrik-hw0, is the udev rule actually necessary?  I think udev should automatically be looking at modinfo without it
<superm1> and modprobing when you hotplug
<superm1> you can try removing it from your system and then reboot and see if  the module loads on it's own with that device plugged in
<henrik-hw0> it didn't seem to. it loaded when i first did matching on device id.
<superm1> that's really odd then
<henrik-hw0> is anyone here good at hotplug/udev stuff?
<superm1> henrik-hw0, you might check with Keybuk on that udev stuff then too
<superm1> #ubuntu-devel usually
<geser> slytherin: any reason why not depend on default-jre but instead on this list of -jre's?
<henrik-hw0> ok
<slytherin> geser: yes, sun specific image processing apis are used. Similar to batik
<ScottK> james_w: I was looking at adjusting the depends in python-wadllib to fix Bug #321713 and discovered that if you try to build the source package in Jaunty it's using ez_setup.  Since you've done the work on the package so far, I thought I'd give you first crack at beating ez_setup into submission.
<ubottu> Launchpad bug 321713 in ubuntu-dev-tools "ubuntu-dev-tools should not depend on python-elementtree and python-celemettree" [Undecided,Triaged] https://launchpad.net/bugs/321713
<geser> slytherin: and "default-jre | sun-java5-jre | ..." doesn't work?
<slytherin> geser: it will work for Ubuntu. But not for Debian, where I plan to submit the package eventually.
<RainCT> slytherin: uhm.. I don't know if it's still active, you could ask in #ubuntuwire. I can add a "global feed" if you're happy with atom
<slytherin> RainCT: I received a mail when I uploaded package. To: motu-reviewers@lists.ubuntuwire.com, CC: myself.
<geser> slytherin: Debian has also "default-{jdk,jre}"
<slytherin> geser: yes, but for now it points to java-gcj-compat-dev and not openjdk-6-jre
<slytherin> java-gcj-compat I mean
<geser> ah, ok
<RainCT> slytherin: can you paste it somewhere?
<slytherin> RainCT: yup
<RainCT> mok0: re-ping
<slytherin> RainCT: pasted with all the headers - http://paste.ubuntu.com/113727/
<RainCT> slytherin: so it says FROM motu-reviewers@ and TO you
<slytherin> RainCT: I now realised I am too sleepy. :-(
<RainCT> slytherin: and the list is here: http://lists.ubuntuwire.com/listinfo/motu-reviewers
<slytherin> RainCT: isn't it weird that it is sending a mail to me instead os those subscribed to the list?
<RainCT> slytherin: No. It's sending you a mail because you're subscribed to e-mail notifications
<RainCT> And the list is not used anymore, though if it still works I'll fix REVU to CC it
<slytherin> ok
<geser> slytherin: advocated
<slytherin> geser: Thanks. :-)
<slytherin> geser: is a needs-packaging bug necessary?
<RainCT> slytherin: is the package ready to upload?
<slytherin> RainCT: yes
<RainCT> slytherin: don't listen to me, but in this case I think it isn't. IMHO the main value of needs-packaging bugs is only to signalize that someone is working on a package (so that someone else doesn't do the same work)
<slytherin> RainCT: I packaged this library as dependency of jmeter. I am still working on jmeter and this library was one of the major hurdles.
<YokoZar> RainCT: Yes, that would be a bug in Wine's manpage.
<YokoZar> RainCT: I haven't looked at wine's manpage status in a while, I suspect it's very very bad
 * slytherin goes to bed.
<RainCT> YokoZar: So should I file a bug on LP (or somewhere else?) or will you remember? :P
<YokoZar> I'll put it on my wine tomboy note page ;)
<directhex> tomboy? that evil .net app? it destroys teh freedom!
 * RainCT hugs YokoZar :)
<zMoo> iulian: Do I need to change the version number of the package, with my new .orig.tar.gz?
 * RainCT adds fancy graphics to REVU :)
<RainCT> if someone has ideas on where a graphic would be useful let me hear..
<zMoo> RainCT: Do you know what means "Warning! This package could not be extracted; there's no browseable directory for it on REVU. "
<zMoo> http://revu.ubuntuwire.com/details.py?package=swac-play
<RainCT> zMoo: yes, that  dpkg-source -x   didn't work
<zMoo> RainCT: the .orig.tar.gz has changed, it's probably the reason
<RainCT> zMoo: I don't get that error
<orospakr> pochu, alas, the same error: pbuilder-satisfydepends-dummy: Depends: seamonkey-dev (>= 1.1.12) but it is not installable
<zMoo> :) there is no error anymore :)
<RainCT> zMoo: then I guess it means that you were too fast and looked at the page before REVU finished processing the upload :P
<pochu> orospakr: and if you login and try to install it, it works, with that version?
<zMoo> RainCT: I guess so
<orospakr> oho!
<orospakr> this is interesting.  packages.ubuntu.com claims version 1.1.12
<orospakr> but my apt-get install inside pbuilder actually installed 1.1.9
<pochu> what mirror are you using?
<pochu> and is that jaunty?
<orospakr> pochu, nope, hardy.  gulus.usherbrooke.ca.  I suspect there's a newer, uninstallable, version of the package in the repository.
<orospakr> anyway, it was an easy fix. ;)
<^Spear> Does anyone fancy packaging http://code.google.com/p/yubico-openid-server/
<^Spear> ? :)
<RainCT> TheMuso: Hey. Are you familiar with espeak?
<^Spear> if not, can somone point me in the direction of the 'Needs packaging' help file for launchpad so that I can submit it
<pochu> !needspackaging
<ubottu> Sorry, I don't know anything about needspackaging
<pochu> !needs-packaging
<ubottu> Sorry, I don't know anything about needs-packaging
<pochu> bah
<^Spear> :P
<^Spear> !needs packaging
<ubottu> Sorry, I don't know anything about needs packaging
<^Spear> !packaging
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<^Spear> :)
<^Spear> thanks ubottu
<pochu> ^Spear: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<^Spear> already there ;)
<pochu> oh :)
<^Spear> https://bugs.launchpad.net/ubuntu/+bug/325465
<ubottu> Launchpad bug 325465 in ubuntu "[needs-packaging] Yubico OpenID Server" [Undecided,New]
<^Spear> ^^ :D
<^Spear> ty pochu
<pochu> yw
<iulian> zMoo: I've just commented on swac-play again.  In the meantime you might want to look for another MOTU to review it.
 * iulian is going to bed now.
<zMoo> have a good night!
<sven777> hi there - I've checked out the MOTU wiki pages but I do not see where it says which files need to be included when uploading to MOTU - I'm assuming the deb, changes, dsc, original tar, diff tar - is this correct?
<maxb> you mean uploading to REVU?
<sven777> yes, sorry
<sven777> I'm new :)
<dtchen> the source package only: orig.tar.gz (if non-native), diff.gz, dsc, and source.changes
<maxb> You must use a special tool that you point at the .changes file - it uploads that, and all the files listed in the .changes
<maxb> wiki.ubuntu.com/REVU
<sven777> aha - missed that one - thanks much
<hyperair> maxb: how about "you must use dput"
<maxb> Well, yes, but that begs the question "How do I use dput", hence pointing to the wiki
<hyperair> maxb: well yes, but it'd have cut the whole chase of "special tool that you point at the ..."
<maxb> I guess I was feeling wordy. :-)
<maxb> But the point was that you specify the changes file and the rest Just Happens
<_16aR_> Hello
<_16aR_> Hello
<_16aR_> need a MOTU on REVU to advocate the fsniper package (daemon to watch new/modified files to apply a rule based on inotify) : http://revu.ubuntuwire.com/details.py?package=fsniper
<_16aR_> 1 advocate left ;)
<RainCT> look at some profile on REVU and tell me if that's cool :P
<ScottK> _16aR_: You need air, water, and eventually food.  You don't NEED a review.
<RainCT> (okay, not very useful, but I felt like creating a graphic :P)
<pochu> RainCT: link?
<RainCT> pochu: http://revu.ubuntuwire.com/profile.py?user=rainct
<RainCT> pochu: btw, you haven't merged your account with the old one
<pochu> RainCT: the page looks cool :)
<pochu> RainCT: I didn't know I had two accounts :)
<nhandler> RainCT: Cool graph
<RainCT> :)
<pochu> RainCT: how can I merge them?
<RainCT> pochu: "Merge accounts" in the menu :P
<nhandler> pochu: http://revu.ubuntuwire.com/merge.py
<RainCT> after loging in
<pochu> RainCT, nhandler: thanks, merged :)
<nhandler> You're welcome pochu
<RainCT> btw, I've just enabled mod_deflate on REVU (compression for HTML, CSS, JS...), tell me if there's any problem
 * jpds goes to look at mok0's page.
<ScottK> That's not going to affect md5sums of files is it?
<jpds> RainCT: What are weeks 10, 20, 30 ... ?
<RainCT> jpds: well, weeks :)
<RainCT> that's how the DB gives them to me
<jpds> RainCT: In relation to?
<RainCT> (/me is doing  TO_CHAR(dateofcomment, 'WW')  )
<RainCT> ScottK: which files?
<RainCT> oh, for dget?
<ScottK> Right.
<RainCT> It's still working.
<RainCT> I think deflate only does something if the browser has gzip in the Accepts header, so it shouldn't be a problem
<ScottK> It'd be handy if you'd test and make sure after ....
<RainCT> Yes, I've just tested fetching something with dget
<ScottK> Great.
<sharms> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/41301
<ubottu> Launchpad bug 41301 in linux-source-2.6.20 "Mouse clicks stop working sporadically" [Medium,Confirmed]
<sharms> I just attached a debdiff to that, can anyone take a look at it?
<sharms> Fairy severe issue for those with xinerama and multiple monitors
<RainCT> jpds: if you know how to get a proper value for the weeks please tell me :P
<jpds> RainCT: So when I see: Week 20 - what does it mean?
<RainCT> jpds: ah, about your question, it's the week of the year.. not sure how it handles multiple years though
<jpds> Aha.
<sharms> if I attach a debdiff to a bug, is there a tag I should apply to it to get it reviewed?
<RainCT> sharms: no, just subscribe ubuntu-{main,universe}-sponsors
<RainCT> (universe if it's in universe/multiverse or main if it's in main/restricted)
<sharms> RainCT: thanks
<RainCT> yw
<RainCT> jpds: ok, I've almost got it to display proper names :)
<_16aR_> ScottK: my package needs a review :p
<_16aR_> you're right :)
<ScottK> You have a different definition of need than I do then.
<_16aR_> maybe
<_16aR_> it needs a review to access a higher level of life
<surfaz> There is any news about this bug?
<surfaz> https://bugs.launchpad.net/ubuntu/+source/amule/+bug/244670
<ubottu> Launchpad bug 244670 in amule "[hardy] Request of update of aMule to 2.2.2 final release" [Wishlist,Confirmed]
<surfaz> I don't think that this is a Wishlist...
<surfaz> It should be High or Critical
<dtchen> it is a wishlist, because it must go into hardy-backports
<dtchen> i.e., jaunty's 2.2.3-1 would be backported
<surfaz> backported???
<surfaz> why?
<dtchen> because hardy itself is frozen and cannot accept new versions of *any* source package
<dtchen> significant bug fixes that are unintrusive can go into hardy-updates
<surfaz> It is a serious problem, I do not think it advisable to put it in backports
<dtchen> if you're willing to backport the fixes from 2.2.3-1 to 2.2.0~svn20080218-0ubuntu4, go ahead
<surfaz> That is, you prefer an svn version of aMule for a LTS version of Ubuntu that a stable version of aMule ..
<surfaz> Please look for any errors in the svn version of aMule is in the trash of amule forum
<dtchen> i *personally* don't care two licks, as i don't use amule. however, procedurally, one needs to follow wiki/StableReleaseUpdates
<surfaz> even, there is a post of devs for this svn!!!
<surfaz> http://www.amule.org/amule/index.php?topic=15834.0
<dtchen> there are plenty of us willing to help you through the procedure if you're willing to put in the legwork
<surfaz> I think that this bug: https://bugs.launchpad.net/ubuntu/+source/amule/+bug/244670 pass all requirements of that wiki
<ubottu> Launchpad bug 244670 in amule "[hardy] Request of update of aMule to 2.2.2 final release" [Wishlist,Confirmed]
<dtchen> surfaz: you need a full debdiff against intrepid's source package to hardy's source package
<dtchen> surfaz: also, please clean up the description so that it adheres to the SRU description outline
<surfaz> But there are too many changes
<dtchen> surfaz: i.e., while i appreciate the amount of info currently in the description, it's far too verbose for the SRU and archive teams
<dtchen> surfaz: "too many changes" -> normally not suitable for an SRU
<surfaz> ah! What is best  than  a unstable version?
<surfaz> I think that stable version > svn version
<dtchen> surfaz: it really depends how much work you're willing to invest
<dtchen> surfaz: i agree; stable versions are preferable. however, if the changes are *that* intrusive, then you'll need to decide whether it's worth going the hardy-backports route for 2.2.3-1 instead
<surfaz> define intrusive
<dtchen> significant enough changes to structs, classes, methods, soname bumps, etc.
<dtchen> rule of them is that if you can't eyeball the diff and understand it within a couple minutes, then it's likely too intrusive
<dtchen> s/them/thumb/
<dtchen> some people hold a far stricter definition including LoC
<surfaz> 	
<surfaz> I do not know if I explained well. Versions 2.2.2 and 2.2.3 are stable and svn version is not. I do not understand why it's wrong or intrusive. All they understand is that the svn version is incomplete and unstable.
<dtchen> just because the version number changes doesn't mean it's automatically accepted as an SRU
<dtchen> i *highly* recommend you stop hand-waving about the procedure and just enlist assistance in getting 2.2.2 into hardy-proposed, if that's what you wish
<dtchen> as far as i can see from the bug report, that assistance includes:
<dtchen> 1) cleaning the description to follow SRU information
<dtchen> 2) providing a debdiff from the proposed source package to the existing hardy source package
<surfaz> dtchen, you read the bug report?
<dtchen> yes, i did
<surfaz> you want see changes of a Kad network incomplete support in svn to a complete support?
<surfaz>  I do not know if I explained well.
<surfaz> or, "Version 2.2.2 has fixes to defy routing attacks"
<dtchen> surfaz: *i* do not make acceptance decisions
<dtchen> surfaz: i am simply trying to help you get your proposed source package into hardy-proposed for further testing so it can be copied into hardy-updates
<surfaz> 	
<surfaz> Ok, but that is a debdiff of a svn version to a stable version can take many mb
<surfaz> I do not think it useful to see the changes.
<dtchen> surfaz: the more succinct the description that conveys the importance of the fix, the better
<surfaz> Although I can not change the description of the bug
<dtchen> surfaz: it is far more important to succinctly describe the problems, the fixes, the testing methodology, and potential regressions than it is to worry about the size of the debdiff
<surfaz> I'm tired of this annoying because I do not know about trying to fix something.
<surfaz> I go to sleep, bye
<dtchen> what, you want someone else to do the work for you? hmm, ok.
<surfaz> dtchen, Sorry? If I could, I upload today a stable version. But I think the bureaucracy will cause Ubuntu 'Hardy' in their repositories have an unstable version of aMule for 3 years.
<surfaz> 	
<surfaz> And do not tell me to upload it to the backports. New users have no idea of repositories and installing programs from the first source.
<dtchen> surfaz: you fail to understand that i'm attempting to *work with you* to get your proposed version into hardy-updates
<dtchen> i am not going to drop patching alsa and pulseaudio to get amsn in, but i certainly am willing to assist you in any way that i can
<dtchen> now, can we stop moaning and just get the debdiff and description updated?
<surfaz> I am tired
<dtchen> heck, i'll even look at it later this evening
<dtchen> i need a "bah humbug" option in tcp.
#ubuntu-motu 2009-02-05
 * ScottK wonders if dtchen has graduated from the ranks of the young whipersnappers to the old and grumpy?
<dtchen> grumpiness seems proportionate to the number of patches in debian/patches/
<_16aR_> dtchen: lol
<directhex> really? what's the threshhold from "normal" to "bah"?
<_16aR_> Anyone already in the REVU group for package upload can review any package ?
<jdong> directhex: you'd get a kick out of this... MonoDevelop 1.9.1, middle-pasting with an empty clipboard == NullPointerException
<jdong> :D
<directhex> jdong, srsly? that's been reported upstream?
<jdong> directhex: I just experienced it and I don't feel like restarting X at this very moment to reproduce :)
<jdong> (no innuendo intended)
<dtchen> directhex: roughly, "when my eyes bleed"
<dtchen> directhex: now, i can sustain quite a bit of "pos_adj = (pos_adj * runtime->rate + 47999) / 48000;", but there is a limit.
 * directhex declares said limit to be "twelvety"
<jdong> directhex: http://paste.ubuntu.com/113834/
<jdong> confirmed.
<jdong> you also can't undo pastes :D
<directhex> jdong, and this is alpha 1?
<jdong> alpha 2, 1.9.1
<jdong> the latest tagged version with tarball
<jdong> the mono stack was compiled from mono's project website sources
<directhex> jdong, i think you should head to gimpnet
 * nhandler remembers that today is the day MC nominations end. That means next week is a vote
<EagleScreen> I have been learning basic Debian/Ubuntu packaging, I would like to become a MOTU member :D
<nhandler> EagleScreen: Look at the channel topic for a link that explains how to get started
<EagleScreen> yes, i am reading
<EagleScreen> i am reading about REVU now
<nhandler> EagleScreen: If you are just starting, you should try some other tasks like patching bugs before you try to package something from scratch
<EagleScreen> i haven't got any program packaged from scratch for now..
<EagleScreen> i know make patches, and rebuild source packages, i have some packages from another deb-based distributions which could be in Ubuntu
<EagleScreen> is REVU only for entirely new packages?
<ScottK> Yes
<EagleScreen> what about one package that was in hardy but not in intrepid and jaunty by the moment?
<nhandler> EagleScreen: Why did it get removed from the repositories?
<ScottK> And is it in Debian?
<EagleScreen> I supuse becouse it comes from Debian, and it was out of Debian archive temporary
<EagleScreen> now it is in Debian unstable
<EagleScreen> i am talking about reportbug-ng
<EagleScreen> it has been ported from Qt3/KDE3 to Qt4/KDE4 and now uses more python modules as python-debianbts, python-debianbts is in jaunty.
<EagleScreen> may be if it is now in Debian usntable, it will automatically merged to Ubuntu.
<EagleScreen> but i am not sure
<ScottK> What package are we discussing?
<EagleScreen> i told you reportbug-ng
<ScottK> Ah.
<ScottK> Missed that.
<ScottK> Why do we want it back?
<EagleScreen> i think it is a good package, someone can manage his Debian bugs while it is using Ubuntu
<EagleScreen> i have uploaded it to me ppa
<EagleScreen> waiting for a dependency to built to can use it in intrepid
<EagleScreen> many people whose contribute to Ubuntu contribute also to Debian and they will want to have these kind of packages
<ScottK> reportbug-ng got removed because it was a horrid disaster.
 * ScottK does his Debian work just fine without it.
<ScottK> Has it really gotten so much better?
<EagleScreen> the new version is good, it works well
<EagleScreen> python-debianbts es un paquete virtual? quÃ© significa eso?
<EagleScreen> aptitude tell me that python-debianbts is a virtual package, what does it mean? reportbug-ng depends on python-debianbts and it is not listed in repository
<sven777> hi I have another question - the FAQs say that packages uploaded to REVU need to have 2 MOTU advocates.  Does this happen automatically or do I need to do something to make it happen?
<Hobbsee> EagleScreen: http://www.linuxtopia.org/online_books/linux_system_administration/debian_linux_guides/debian_linux_faq/ch-pkg_basics.en_007.html
<nhandler> sven777: MOTUs go through the queue when they have time. However, asking in here on Fridays is a good way to get advocates
<EagleScreen> it is the same as meta-package?
<sven777> nhandler - oh ok.  Thanks much for that info.  :)
<Hobbsee> EagleScreen: no.
<EagleScreen> i have uploaded python-debianbts to my ppa, but it is not listed by synaptic, any idea?
<Hobbsee> how long ago did you upload it?
<EagleScreen> minutes ago
<EagleScreen> but it is built yet
<EagleScreen> i will wait sime time, may be it will appear later
<Hobbsee> it takes a while to actually public
<nhandler> EagleScreen: Is your PPA in your /etc/apt/sources.list file? And did you do an apt-get update?
<Hobbsee> er, publish
<EagleScreen> yes, ofcourse i have installed various packages from my ppa
<nhandler> EagleScreen: Ok, just making sure
<anakron> Hi all
<EagleScreen> hi
<EagleScreen> my package finally appeared :D
<anakron> wich one
<nhandler> Glad to hear that EagleScreen
<anakron> im a bit newbie...how i can be maintainer of a package
<nhandler> anakron: Ubuntu (for the most part) doesn't have individual package maintainers like Debian does. We maintain them as a team
<anakron> yes i know
<nhandler> You can "Maintain" the package by patching bugs, keeping it up-to-date, and forwarding changes/bugs upstream
<EagleScreen> but now i have version problem: reportbug-ng cannot be installed because depends on python-debianbts <= 0.3 and available is 0.3~intrepid1~ppa2, i will have to build it again with an upper version :(
<anakron> keeping it up-to-date >>> sync and merge?
<nhandler> If it is in Debian, yes
<anakron> and...how you can k-i-u-t-d if a package is from...gnome
<EagleScreen> i am trying to sync reportbug-ng
<anakron> like the last version of gdesklets
<anakron> that come with some bugs fixed
<nhandler> anakron: Is it also in Debian?
<EagleScreen> if I sync a package from Debian.. must I upload it to REVU??
<anakron> yes, but the new version is not in debian
<nhandler> anakron: I would contact the Debian Maintainer and see if they plan on updating their package. Chances are, this will not happen until after February 14 (lenny release)
<anakron> ok
<anakron> someone can say me an app written in python
<anakron> tell me some of them
<Hobbsee> anakron: http://www.google.com.au/search?q=application+written+in+python&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
<anakron> thanks
<anakron> im trying to find an example
<anakron> for fix a bug
<anakron> Scottk?
<anakron> ping Scottk
<ScottK> Yes?
<anakron> we were talking about a bug of catfish
<ScottK> Any of the packages that the pythonistas or pythoneers teams are subscribed to are written in Python.
<anakron> and you ask for it in python channel
<anakron> yes, i was looking for one that i use
<ScottK> No, I suggested you ask your question in #python.
<anakron> but i cant access
<ScottK> Try /join #python in your IRC client.  Works here.
<EagleScreen> reportbug-ng is finally working well for me in intrepid
<ScottK> I'm fairly certain that's a package we only want to get from Debian.
<didrocks> morning
<DktrKranz> RAOF: do you plan to update gnome-do to latest release?
<zMoo> hi, iulian
<zMoo> The proposal for a new format of debian/copyright (http://wiki.debian.org/Proposals/CopyrightFormat) does't seem to be stable
<zMoo> do you really think I should use it?
<zMoo> Now, everyfiles of the package are licensed under the GPL v3
<zMoo> (I'm taliking about the "swac-play" package)
<fta> anyone working on updating the googleearth-package for google earth 5?
<fta> can't find anything in debian
<fta> hm, it's maintained in a private bzr branch (not on lp)
<iulian> zMoo: Well, I recommend it.
<fta> does this mean we can't update it?
<zMoo> iulian: so I put something like "http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=143" for the field "Format-Specification" ?
<zMoo> you think, the format will not evoluate anymore?
<liw> I doubt the format will change all that much, but it's also not time yet to push for it to be adopted, I think
<iulian> zMoo: If that's what it says there, yes.
<zMoo> ok
<zMoo> I just have to find the number of the current revision
<zMoo> iulian: another problem.
<zMoo> I can not see any value for the GPL3+ license
<zMoo> I used the GPLv3+ as recommended in http://www.gnu.org/licenses/gpl-howto.html
<iulian> zMoo: Just mention GPL-3+.
<zMoo> :)
<iulian> Take a look at http://packages.debian.org/changelogs/pool/main/g/git-cola/current/copyright for an example.
<iulian> zMoo: License keywords:  GPL-3+
<iulian> GNU General Public License, version 3 or later
<directhex> i support iulian on this. the copyright format is nice even for human-readability
<zMoo> iulian: the new package for swac-play is ready :)
<iulian> Great.
<zMoo> iulian: It's time to eat. See you
<khashayar> mok0: New upload http://revu.ubuntuwire.com/details.py?package=pencil fixes all (but one) problem; if you find the time :-)
<mok0> khashayar: that's great
<mok0> khashayar: I'll take a look later todayt
<khashayar> mok0: Thanks!
<khashayar> mok0: Do you think you could take a look at http://revu.ubuntuwire.com/details.py?package=rtirq as well. It should be an easy one ;-)
<mok0> khashayar: ok, will do
<khashayar> Cheers!
<nhandler> khashayar: I should be free around 23:00 UTC to give the packages another review if you want
<khashayar> nhandler: Thanks. I'll try to make new updates before 23:00 UTC, then, if need be.
<savvas> what does this mean for dpkg --compare-versions: lt-nl ?
<Hobbsee> man dpkg?
<Hobbsee> oh
<Hobbsee> it's less than - something
<Hobbsee>  otherwise. There are two groups of
<Hobbsee>               operators, which differ in how they treat an empty ver1 or ver2. These treat  an  empty  version  as
<Hobbsee>               earlier than any version: lt le eq ne ge gt. These treat an empty version as later than any version:
<Hobbsee>               lt-nl le-nl ge-nl gt-nl. These are provided only for compatibility with control file syntax: < << <=
<Hobbsee>               = >= >> >.
<savvas> Hobbsee: could you give me an example? or does lt-nl mean < ?
<loic-m> Hobbsee: I can understand what you're quoting, but it's worded only slightly better than a quantum mechanics article ;)
<savvas> true :P
<loic-m> I'm sure the man page author was just short of throwing a bit of xml at it
<fta> savvas, "a lt b" is equal to "a lt-nl b" if both a and b are not empty/null/undefined
<fta> if either a or b could be empty/missing, use the -nl variant to be sure that dpkg --compare-versions won't fail, so you get a predictable result
<fta> very handy for scripts
<Hobbsee> loic-m: indeed...
<Hobbsee> loic-m: that'll teach me not to answer questoins close to midnight
<loic-m> Hobbsee: hehe
<zMoo> hi, iulian
<khashayar> mok0: About the wrong street address in LICENSE (wrt the rtirq package): This file is part of the upstream tarball. Do I need wait for a new release, or can I mention this somewhere in the packaging before upstream fixes it with a new LICENSE?
<iulian> zMoo: Hiya
<piratenaapje> $visitor->language = reset(explode(',', $_SERVER["HTTP_ACCEPT_LANGUAGE"]));
<piratenaapje> wow php is vies spannend
<piratenaapje> Hmm, something tells me this is not the channel I wanted to paste that in
<zMoo> iulian: I've just uploaded a new package. I think, this time, is the good one :)
<iulian> zMoo: Excellent.  I will have a look at it.
<zMoo> iulian: it's really pleasant to work with you
<iulian> Of course.
<iulian> zMoo: debian/copyright:  Please replace <http://www.gnu.org/licenses/> with /usr/share/common-licenses/GPL-3.
<zMoo> iulian: arf :)
<cody-somerville> What is the argument to pass to debuild to set the Distribution field in the changesfile?
<zMoo> iulian: Done \o/
<iulian> zMoo: I've just advocated it.
<zMoo> iulian: \o/ Houra
<zMoo> iulian: I've reported all changes on the other package swac-scan
<khashayar> mok0: Whenever you feel that urge of re-revuing, rtirq is now moved to http://revu.ubuntuwire.com/details.py?package=rtirq-init :-)
<mok0> khashayar: ah, but you don't need to rename the source package
<mok0> khashayar: I meant just changing the name of the binary package, in debian/control...
<mok0> khashayar: it's actually best to keep the source package name the same as upstream's tarball (except for general Debian policy on package names)
<khashayar> Ah, I see :-p
<khashayar> I'll do that then. Any way to remove rtirq-init from revu?
<mok0> khashayar: You understand now? It's a one-line change in control
<mok0> khashayar: I can nuke it :-)
<khashayar> Yes, I get it. Thanks. Please nuke :-)
<iulian> zMoo: Yes, I've seen that.  I'm reviewing it now.
<mok0> khashayar: anyways I'm busy looking at pencil, so take your time
<khashayar> Cool.
<zMoo> iulian: Excellent!
<iulian> zMoo: Reviewed and advocated.
<zMoo> iulian: Thank very much
<RainCT> heya
 * iulian prods RainCT.
<zMoo> hi RainCT & pochu. My packages have been advocated by iulian! I offer a free collection of bielorussian words to the second advocate! :]
<RainCT> zMoo: is compat level 7 necessary for some reason?
<zMoo> I don't think so
<RainCT> Why do you use it then? This is a very minor issue, but using high compat levels for the sake of doing so just increases the difficulty to backport a package
<zMoo> my debin/compat was generated by dh_make :)
<zMoo> *debian/compat
<zMoo> Is it a good answer?
 * zMoo => []
<RainCT> Rather, no. And you blindly trust dh_make?
<RainCT> :P
<RainCT> hehe
<RainCT> (If you don't change this now, I'll survive anyway ;))
<zMoo> I just have to restart my laptop, and I change it
<RainCT> zMoo: Format-Specification in debian/copyright is missing the revision number
<khashayar> RainCT: I though it was recommended to use compat = 7, standards version = 3.8.0. Won't there be lintian warnings otherwise?
<khashayar> (I'm just asking because in all my packaging efforts I set those versions :-/)
<RainCT> khashayar: No. Standards version should always be the latest, but the same doesn't apply to compat. You can choose between any compat level (well, that it number 4 or above, 1/2/3 are deprecated) depending on which new features you need
<zMoo> RainCT: for the revision, I did the same thing like iulian in http://packages.debian.org/changelogs/pool/main/g/git-cola/current/copyright
<khashayar> RainCT: I see. I guess 6 should be good figure then, as that's what hardy's using. Correct?
<zMoo> and I did find the revision number of the document
<zMoo> *didn't
<iulian> I believe the revision number doesn't matter so much since the specification is not pushed.
<RainCT> khashayar: Yes, 6 should be acceptable (but you could get it even lower, or use a higher one if you want some new behaviour introduced with a later version.. see  man debhelper  for information on all levels). But as I said, this is just a nit-pick, it's good to consider but isn't really a must.. Using level 7 won't kill cats or anything :)
<khashayar> RainCT: Good to know. Learning something new every day :-)
<RainCT> iulian: the specification says there must be the revision, as I understand it
<mok0> khashayar: comment ready for you, for pencil
<iulian> RainCT: Ah, well, then append the revision number to that url, zMoo.
<RainCT> zMoo: I can't find anything else to complain about, will have a look at the resulting .deb now :)
 * RainCT updates cowbuilder
 * henrik-hw0 thanks mok0
<mok0> henrik-hw0: it would be good to get a second advocate quickly, so we can build your cdemu stuff without funny business
<mok0> Any MOTUs ready to give a 2nd advocation of libmirage?
<mok0> MOTUs: ^
<mok0> Tip to ppl seeking review: if you know your package falls in the special area of one of the special Ubuntu distros (Kubuntu, Ubuntu Studio, etc.) try to look for a MOTU in that area
<henrik-hw0> mok0: indeed. especially since that package contains the parts reusable by other projects as well.
<mok0> henrik-hw0: good point
<zMoo> RainCT: I think, I have to use compat V7 (I use a new fonctionnality of dh_clean in my debian/rules)
 * pochu wonders who has applied for the Council vacant :)
 * RainCT is happy at archive reorg :)
<pochu> hi RainCT
<pochu> me too :)
<jpds> How isn't?
<jpds> Who*
<RainCT> hehe
<mok0> We really should put the newly uploaded packages from REVU onto a bzr repo
<mok0> RainCT: you think that revu could stash things away in a bzr repo?
<RainCT> mok0: That's already done automatically
<mok0> RainCT: really? where?
<RainCT> mok0: VCS for everything spec? :P
<RainCT> Or do you mean a repo for packages *before* they enter Ubuntu?
<mok0> RainCT: I didn't know it was already working
<Laney> maybe that could be a new use for revu-uploaders
<mok0> RainCT: actually , yes I did
<Laney> bzr push lp:~revu-uploaders/mycoolnewpackage
<RainCT> Uhm.. I guess I should cancel my team deletion request then :P
<mok0> Sometimes there's a trivial thing you'd like to fix before advocation, like a spelling mistake, and it's kinda cruel to ask for another upload just for that
<mok0> RainCT: perhaps you should
<Laney> just an idea
<Laney> LP allows users to set the "state" of branches too
<RainCT> yes, that's an interesting idea
<Laney> Although, I don't know if we need revu-uploaders for it.
<Laney> People can just push to their own space
<mok0> Laney: sure, but it would be nice to have all branches collected in 1 place
<Laney> mok0: Yeah, the revu website
<Laney> or you could propose for merging into some central "pleaes review me" place
<mok0> Laney: yeah... I guess...
<zMoo> RainCT: the new package in online (I didn't change the compat version number)
<Laney> or revu could support bzr directly
<RainCT> zMoo: okay
<zMoo> *is online
<mok0> Laney: I like that last idea
<Laney> Actually I like the idea of using LP's code review facilities
<RainCT> it would be great if LP supported branches owned by several teams (eg, the uploader + MOTU) :P
<mok0> Laney: but I think the crucial thing is that MOTUs should have write access to the place where people put their branches, so we can fix small issues
<mok0> RainCT: exactly
<Laney> hmm
<mok0> In that sense, ppl should just ask for their personal branches to be merged into the MOTUs repo
<Laney> but then if it gets merged they can't modify it any more
<mok0> Laney: no, but they can upload their fixes to their own place and those could be merge
<mok0> d
<mok0> or pulled
 * mok0 is no bzr wizard
<mok0> yet
<Laney> I dunno, it seems like it would be easier for everyone to just be able to push
<mok0> Laney: I just advocated a package with a spelling mistake in the description, it would be nice to just be able to fix it
<Laney> to the same place
 * RainCT thinks we should better wait for the spec to be fully implemented before looking how REVU could do something with bzr
<mok0> Laney: Hm, so the repo belongs to revu-uploaders, who everybody is a member of?
<Laney> mok0: You could
<Laney> fix the mistake, upload and then advocate your version
<mok0> RainCT: of course, just brain fscking here :-)
<Laney> RainCT: Hm, I dunno. It doesn't really deal with new packages
<Laney> I think all of the machinery for doing actual packaging in bzr is there, unless I'm mistaken
<mok0> Laney: true, but it would be eazier if you had your copy from bazaar, you could just push your mods
<Laney> it would
<mok0> Laney: ...and the uploader could pull your mods
<Laney> moreover, the uploader wouldn't even be able to push their own changes until merging yours
<jpds> Do we VCS everything or just the debian/ dir?
<Laney> (without --overwrite?)
<Laney> usually just debian/
<mok0> OK, that requires a watchfile
<Laney> (with SVN, I think bzr has some crazy looms thing)
<mok0> looms?
<Laney> mok0: See https://wiki.kubuntu.org/NoMoreSourcePackages
<Laney> It's the new way of doing patches
<Laney> s/new/bzr/
<mok0> Laney: Yeah. I'm not so hot on using it for patches, though
<Laney> yeah, and that will have to wait until this gets done anyway
<Laney> you can still do it the normal way
<mok0> Laney: but as a way of interacting with uploaders of new packages, I think it would be cool
<Laney> certainly
<jpds> Laney: That loom thing looks so cool.
<Laney> yeah - it's basically another view on quilt patches, which is good
<mok0> Hm, Laney, in the document you URL'ed above, it says: "For packages uploaded via a revision control build request, there would be no source package, instead the buildd needs to check out the required revision control branch and build the binaries and source package from that." That implies that upstream's source is also in there
<Laney> mok0: I think there's a loom for the upstream source
<Laney> and everything else sits on top of it
<Laney> i.e. upstream is basically "patch 0""
<mok0> Laney: I see
<mok0> Cool
<Laney> so to update to a new upstream version you just touch that loom, then carry on up the stack fixing the looms as they generate conflicts
 * RainCT uploads a new ubuntu-dev-tools version
 * mok0 wonders if Debian can be persuaded to work on LP for new packages that start their life in Ubuntu
 * Laney giggles
<Laney> alioth supports bzr, though
<mok0> Laney: ok, so the whole branch could migrate there
<jpds> RainCT: Remeber to bzr tag it.
<RainCT> jpds: how is that done?
<jpds> RainCT: bzr tag -r NN 0.6N
<jpds> Where NN is revision of upload.
<RainCT> and the 0.6N?
<RainCT> ah ok
<RainCT> :P
<jpds> RainCT: Whatever version you uploaded ;-)
<jpds> RainCT: i.e bzr tags
<Laney> jpds: Does debcommit -r work with bzr?
<jpds> Laney: Never used that.
<Laney> mmk
<RainCT> jpds: wow, what it you who has tagget all past uploads?
<Laney> it's supposed to commit and tag
<jpds> Laney: Manpage claims to.
<jpds> RainCT: Yep.
<RainCT> debcommit rocks, you should use it :)
<Laney> does it create a new blank changelog entry?
<Laney> (that would be sexy)
<RainCT> iulian: have you tried if swac-play works?
<RainCT> (it's not installable on Hardy and I would like to avoid starting a VM now..)
<RainCT> s/Hardy/Intrepid
<RainCT> nice, edge.'s +archive package has Ajax :)
<RainCT> *package = page
<RainCT> :(
<jpds> The evil green flash?
<RainCT> yes
<RainCT> And it is evil indeed.. The fact that it is Ajax is cool :P
<mok0> Huh? What green flash?
<RainCT> mok0: https://edge.launchpad.net/~do-testers/+archive/ppa
<mok0> ah
<mok0> heh
<RainCT> mok0: ah, I asked you yesterday if you have already touched anything in index.py
<RainCT> (in REVU)
<mok0> I haven't pushed anything yet
<RainCT> mok0: but modified? (so that I don't do many changes there which will then conflict with yours :P)
<mok0> RainCT: I can pull?
<RainCT> mok0: sure
<mok0> ah, merge
<RainCT> uhh
<mok0> Ah, the only real change I've done is so that you get a line number on the listing
<mok0> I can push that and you can see if you want to use it
<RainCT> mok0: Not sure what you mean, but okay
<mok0> RainCT: on the webpage, in each table the package is numbered from the top, starting with 1, so you can easily see how many there are
 * RainCT doesn't like that :P
<mok0> RainCT: adds another column to the html table, on the left hand side
<mok0> RainCT: why?
<RainCT> just adding   (X)   next to the section name should do the job
<mok0> RainCT: right
<mok0> that's better
<RainCT> I don't seen any use for it and it clutters the interface
<Laney> It would imply that REVU is a queue too, at least to me
<RainCT> (adding it on every line, that is)
<mok0> True
<RainCT> And today I'm doing some sort of typo in every line I write XD
<mok0> Well, it's taught me a bit about how this template thing works :-)
<RainCT> that's always good :)
<RainCT> zMoo: seems like iulian is away.. You're sure the .deb works fine, right?
<zMoo> yes
<zMoo> RainCT
<zMoo> I'll try again
<bddebian> Hi folks
<mok0> RainCT: I am thinking that perhaps adding some SQL tables might eliminate the need for doing these complex queries, but how to keep the info consistent, if it's duplicated?
<Laney> urgh, don't duplicate in a database
<RainCT> mok0: where is it duplicated?
<RainCT> zMoo: Uploading :)
<mok0> RainCT: Don't know, yet :-)
<RainCT> lol
<mok0> RainCT: for example, if a package is advocated, I'd like to use that to bump the rung of the package
<mok0> sorry, the rung of the sourcepackage
<mok0> not the upload
<RainCT> mok0: that still wouldn't allow us to remove the advocation table (advocates are associated to comments, which is good that way, and remember that they can also be added/removed after being given)
<RainCT> jpds: can we get ubuntu-dev-tools backported to Intrepid?
<mok0> RainCT: yes, but the advocation is not really a property of the comment, it's a property of the package
<jpds> RainCT: Sure, file a request and I'll do it.
<zMoo> RainCT: in fact I should add gstreazmer0.10_plugins-good in the dependences (it's not mendatory, but it'll be better)
<zMoo> *dependances
<RainCT> zMoo: oh. you can get a new revision in once the package has been accepted.
<zMoo> RainCT: I did't see "Uploading"
<zMoo> in fact, this dependance is not mendatory
<RainCT> zMoo: it should be a Recommends then
<zMoo> yes
<RainCT> jpds: do I need to write something particular in the description?
<zMoo> "<RainCT> zMoo: Uploading :)" Houra \o/
<jpds> RainCT: "It builds, works, runs and has all dependencies in intrpeid."
<mok0> Hm how do I get back a file from bzr that I've deleted?
<RainCT> mok0: bzr revert <file>
<mok0> thx
<RainCT> jpds: bug 325812
<ubottu> Launchpad bug 325812 in intrepid-backports "Please backport ubuntu-dev-tools 0.63 from Jaunty to Intrepid" [Undecided,New] https://launchpad.net/bugs/325812
<jpds> RainCT: ACKed.
<RainCT> jpds: Great. And now an archive-admin does the backport?
<jpds> RainCT: Yes.
<mok0> RainCT: When I try to bzr pull, it tells me the branches have diverged, but when I do bzr merge it says "nothing to do"
<RainCT> mok0: are you merging the right branch?
<mok0> RainCT: perhaps not
<RainCT> bzr merge lp:revu
<mok0> RainCT: ah, that worked, now I have all your mods
<mok0> RainCT: some of the files have "+N" others only "N" what does that mean?
<RainCT> mok0: N is new. Not sure what the + is
<mok0> Oh, my bad, it says "M" not "N"
<RainCT> mok0: M = Modified
<mok0> Ok, you added a bunch of "flot" stuff
<RainCT> If there's an * it means that the permissions were modified. For the +, I don't know.
<RainCT> mok0: Yep, that's for the graphics (and includes jQuery so we can add more fancy stuff anytime)
<mok0> heh cool
<mok0> RainCT: so I should just do the bzr merge lp:revu often, to keep up with your version?
<RainCT> mok0: Yep. If you do now   bzr merge --remember lp:revu   afterwards   bzr merge   will be enough
<mok0> RainCT: Mind if I change the format of the data field to RFC2822 format?
 * Laney applies for things
<mok0> s/data/date/
<Laney> thanks james_w \o
<james_w> Laney: no problem
<RainCT> mok0: what's the difference?
<mok0> RainCT: e.g. 27 Jan 2009 14:48
<Laney> that's my birthday
<mok0> RainCT: same as in changelog
<mok0> Laney: :-) congrats
<Laney> heh
<khashayar> mok0: Thanks (re: pencil comments)
<iulian> RainCT: What do you plan to do with ~revu-uploaders?
<RainCT> iulian: it was discussed that it may be useful to do something with bzr in the future
<RainCT> mok0: and how is it now? :P
<iulian> RainCT: Ah, cool.
<mok0>   	 January   27  13:57
<RainCT> mok0: ok, feel free to change it, as long as you tell me how to update the DB :P
<mok0> RainCT: it's just a change in index.py
<RainCT> mok0: ahh ok
<RainCT> mok0: Sure, do so. But remember to also modify this in the other files which show a date.
<mok0> RainCT: ok, sure
<zMoo> iulian: is everything ok with the second package? http://revu.ubuntuwire.com/details.py?package=swac-scan
<zMoo> the package is absent from the list of advocated packages
<mok0> RainCT: another bzr question... now that I've merged your latest updates, I need to commit it, but that will create a dump log message like f.ex. "merging changes from trunk" or something. How do you do this?
<mok0> RainCT: and what will happen to that commit if you merge my branch?
<walrus17> Hello, could someone contact someone from #ubuntu and say that unban me
<mok0> RainCT: will that dumb merge message be a part of trunk's log, then
<RainCT> zMoo: you've done a new upload, so you've lost the advocation
<Laney> walrus17: No. Go to #ubuntu-ops
<RainCT> mok0: bzr commit -m "message.."
<walrus17> Okay thank you
<zMoo> RainCT. I see. Thanks
<mok0> RainCT: oh, I know, my question is will "message" eventually be part of trunk's log if my branch gets merged?
<RainCT> mok0: iirc when you merge something the merged revision(s) will be in bazaar as "sub revisions" and you'll still be able to read their log messages (although they aren't displayed on Launchpad's interface)
<mok0> RainCT: I was wondering about that, because it "pollutes" the history with a bunch of meaningless "merge from trunk" messages
<RainCT> mok0: oh, don't worry because of that
<RainCT> REVU has already enough meaningless commit messages as that a few more from you would make a difference *G*
<sven777> if anyone feels like being generous, I'm still in need of advocates for my new package : http://revu.ubuntuwire.com/details.py?package=lmalinux   :)
<porthose> iulian: I have made the requested changes to bug #269079, would you mind having a look at it when you have time.  Thanks :)
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/269079/+text)
<iulian> porthose: Sure.  I know that you know how to count.  Don't get me wrong.  I have just tried to explain.
<jpds> Laney: I'm still waiting for huats 4000 friends to +1 him on the motu-council list.
<RainCT> iulian: using multiple monitors works fine, at least using NVIDIA's configuration program
<Laney> jpds: Probably waiting for his CC application. World domination ahoy
<Laney> didrocks: I just notice that an SRU I did was in the release notes too \o/
<nschembr> I checked with #ubuntu without any luck. I'm running ubuntu server without xwindow. I'm looking to  install xterm so I can push a xterm to a third box. I have no  need to install x11 and will never run x on this box. apt-get  wants to install the world.  Is there a way to force the  install without all of the dependencies.
<nschembr> one package at a time.
<didrocks> Laney: congrats ;)
<LaserJock> anybody know of a good versioning scheme for git?
<broonie> You mean for commit IDs?
<jdong> dates?
<henrik-hw0> superm1: ping!
<porthose> Iulian:  Thank you for explaining it  :)
<jdong> sha1sums sure aren't gonna help :D
<LaserJock> jdong: yeah, but you can have a lot of commits in 1 date
<superm1> henrik-hw0, pong
<jdong> LaserJock: well number 'em up from 1 ;-)
<broonie> LaserJock: git describe may work for you.
<LaserJock> jdong: yikes
<broonie> depending on how the repo is tagged.
<henrik-hw0> superm1: Did have a talk with Keybuk.
<jdong> LaserJock: well that's what I've seen done; and due to the way git names revisions I don't think there's a better idea than that :(
<jdong> the obvious downside is that two independent packagers will surely end up with version number clashes
<LaserJock> broonie: seems to work for some branches but not others
<broonie> LaserJock: Yes, it works well if there's a tag in the history (in which case it gives a commit count since that tag).
<broonie> plus the tag
<LaserJock> ah, nifty
<iulian> porthose: I've just uploaded it, thanks.
<iulian> RainCT: Eh?
<superm1> henrik-hw0, and what did you determine?
<broonie> eg, my current Linux git branch is v2.6.29-rc3-573-g580406a
<henrik-hw0> superm1: looks like the udev rules will have to stay for now.
<henrik-hw0> superm1: udev gets the hw event and tries to modprobe. however modprobe fails. unknown cause.
<RainCT> iulian: err, that was for Laney
<iulian> Heh, OK.
<superm1> henrik-hw0, so why does modprobe work the second time?
<henrik-hw0> superm1: if you mean the udev rules i load the module by name rather than by modalias.
<superm1> henrik-hw0, sounds like a bug in the module then?
<henrik-hw0> superm1: it sure does.
<superm1> henrik-hw0, well if you can file a bug with that upstream, and keep an eye on it to see when it gets fixed, and add some comments in the udev rule i can ack the package then
<henrik-hw0> superm1: i don't have much hope in upstream giving a reply. :/ i want to check with "rtg" first. perhaps we should talk after that?
<superm1> henrik-hw0, well if upstream isn't going to be responsive to bugs in their software, that's a good reason to not include their software in ubuntu though.
<superm1> henrik-hw0, so i would recommend at least filing the bug with them.  we can talk more about it after you talk to rtg
<henrik-hw0> superm1: ok.
<superm1> but i think as long as the bug is filed and documented why the udev rules are necessary that packaging is otherwise in good shape
<porthose> iulian: Thank you very much :)
<savvas> fta: thanks for your answer about lt-nl before, I forgot to reply :)
<savvas> the dpkg manual could surely be updated in that section
<RainCT> Any python wizard around? If I have a list of numbers, how can I get those between which there is a minimum difference of 5 (eg, [1, 3, 7, 15, 20] would become [1, 7, 15, 20])?
<maxb> I can't think of a one-liner, but as a for loop appending into a new list it's triival
<RainCT> maxb: Yep, I was wondering if there's some inbuild way.
<hyperair> maxb: how abnout a loop removing the elements from it
<maxb> It's problematic in that you need to refer not to the previous entry, but the previous entry that you accepted
<hyperair> wait, i think i can come up with one
<RainCT> got it, almost
<RainCT> [b.remove(x) for x in b if (x - b[b.index(x)-1]) < 5]
<hyperair> for i in xrange(1, len(a)-1).     while (abs(a[i]-a[i-1])<5):             del a[i]
<hyperair> i got this
<hyperair> hmm that's interesting O_o
<RainCT> maxb, hyperair: thanks
<hyperair> RainCT: not at all, you came up with your solution yourself
<RainCT> hyperair: well, but you gave me the needed inspiration :P
<hyperair> um thanks
 * hyperair wonders how my stumbling around could have given RainCT inspiration
<RainCT> yeah.. I'm that weird *g*
<hyperair> lol
<Laney> RainCT: What's the final version?!
<Laney> how do I find out how many packages are in universe/multiverse?
<RainCT> maybe synaptic will tell you
<Laney> synaptic knows, yeah
<Laney> so where does it get that from!
<RainCT> counting them, probably :P
<RainCT> python-apt may also be able to do that
<Laney> no, synaptic knows the section
<Laney> I should be able to use grep-dctrl or something
 * Laney pokes
<pochu> apt-cache dump | grep universe may do the trick (haven't tried)
<pochu> a bit hackish though ;)
<Laney> laney@chicken:/var/lib/apt/lists$ grep Package archive.ubuntu.com_ubuntu_dists_jaunty_universe_source_Sources | wc -l
<Laney> 11799
<RainCT> Laney: I get over 30.000 here.. Muahaha :P
<Laney> are you counting binary packages?
<RainCT> ah, yes :P
<Laney> http://identi.ca/group/motu
<Laney> go go go!
<iulian> Hmm, I look nice in that picture.
<iulian> I'm not that fat but it's fine.
<Laney> I took every MOTU and created the geometric mean. That's what came out.
<iulian> Ah-ha, great :)
<hyperair> Laney: what came out?
<Laney> http://identi.ca/avatar/1073-96-20090205190348.jpeg
<RainCT> Laney: [keys.remove(x) for x in keys[1:-1] if (x - keys[keys.index(x)-1]) < 10]
<rugby471> question : I am trying to patch an image in a debian package. The package is using the cdbs patch system, I can create a uuencoded patch, but do use the patch system (cdbs) to patch the image, or do I go by the instructions on this page (ie. create uuencoded files and simply add a uudecode in the build section of debian/rules) https://wiki.ubuntu.com/PackagingGuide/Howtos/BinaryFilesInDiff
<RainCT> rugby471: patch an image?
<rugby471> ie. in the gconf-editor package
<rugby471> there are some outdated images in the source package
<rugby471> that I want to replace with newer ones
<rugby471> I will propose the patch to upstream after
<rugby471> but for the moment I want to replace them for Jaunty
<RainCT> rugby471: then include an uuencoded version i debian/ and in debian/rules remove the original image and install the new images (after uudecoding) into their location
<rugby471> kl
<rugby471> thanks
<RainCT> (remove the original image from debian/<pkgname>/.. that is)
<RainCT> yw
<rugby471> see ya RainCT !
<hyperair> RainCT: i shudder to think how inefficient that code is =\
<hyperair> RainCT: but it doesn't matter if you're handling small lists
<RainCT> lol
<hyperair> RainCT: how about replacing "for x in keys[1:-1] if (x - keys[keys.index(x)-1]) < 10" with "for i in xrange(1, len(keys)-1) if (keys[i] - keys[i-1]<10"
<hyperair> RainCT: then you won't have the overhead of keys.index(x)
<RainCT> hyperair: that won't work
<hyperair> RainCT: why not
<hyperair> uh i forgot a trailing ) it seems
<hyperair> but yeah why won't it wokr
<RainCT> hyperair: it gives "out of range"
<RainCT> the size of the list changes as some items are removed..
<hyperair> ah right
<hyperair> shit
<RainCT> jpds: Okay, the charts on REVU show the month and the year now :)
<jpds> RainCT: Real cool.
<nschembr_> I checked with #ubuntu first but no luck. I'm running ubuntu server. I want to install xterm without installing X11. Is there a way to use dpkg to install the base package and the dependances one at a time.
<jpds> nschembr_: Try #ubuntu-server.
<nschembr_> jpds: ok thank you
<Laney> ooh, hdbc 2.0
<Laney> guh, some of the deps are still in NEW. Debian is weeeeeeeeeeird that people upload packages in that state
<pochu> well, it will just depwait ;)
<jpds> maxb: Cannot wait till they merge the dev teams.
<maxb> ?
<jpds> Your bug report against u-d-t ;-)
<RainCT> heh
<maxb> well, that'll simplify other things, but I'm not a member of either so it doesn't really matter for that bug report :-)
<pochu> which bug are we talking about? :)
<jpds> bug #325923
<ubottu> Launchpad bug 325923 in ubuntu-dev-tools "No validation of discovered cookie - leading to requestsync erroneously assuming that I am in core-dev" [Undecided,New] https://launchpad.net/bugs/325923
<pochu> ah I was looking here :) https://bugs.edge.launchpad.net/ubuntu-dev-tools/+bugs
<ScottK> Laney: Since Debian does binary uploads they can do that.
<Laney> ScottK: I know they can, I just don't know why they would
<directhex> ScottK, doesn't make it any less icky
<ScottK> Well it makes the total time in New shorter if you do it in parallel instead of in series
<Laney> the package with the deps is not in NEW
<Laney> the deps themselves are
<ScottK> Understand.
<Laney> uploading it before they cleared just broke the package
<ScottK> Sure.
<Laney> hence the weirdness
 * Laney will poke
<surfaz> dtchen, 13.3 mb is the size of debdiff
<surfaz> ... :(
<dtchen> surfaz: right, don't worry about the size of the debdiff
<surfaz> but also incluides po files changes
<surfaz> and Mac OS X and Windows changes
<surfaz> I do not know how to separate it
<surfaz> I upload it?
<dtchen> surfaz: ah, you can exclude OS X and Windows changes
<surfaz> how?
<dtchen> are those changes localised to specific directories, or are they #ifdef'd in the source alongside *nix?
<dtchen> see also filterdiff(1), which is in the patchutils package
<surfaz> now 4 mbs
<surfaz> I use diff instead of debdiff
<surfaz> done
#ubuntu-motu 2009-02-06
<savvas> if anyone has some spare time, can you answer the packaging-related questions at the last comment: https://bugs.launchpad.net/ubuntu/+source/libmtp/+bug/315679
<ubottu> Launchpad bug 315679 in libmtp "Please merge libmtp 0.3.0-1ubuntu3 (main) to 0.3.6-1 from Debian (experimental)" [Wishlist,Confirmed]
<savvas> well, done my good deeds for tonight, laters!
<nhandler> Night savvas
 * ScottK tosses out that the last Main depends on boost have been transitioned to boost1.35, so it's open season of anti-cruft minded MOTU to push it on out of the archive.....
<darkace> hello i want to get involved with motu can somebody please help me get my basics up and running as i am not quite familiar with linux or debian
<ScottK> darkace: https://wiki.ubuntu.com/MOTU/GettingStarted
<ScottK> Do your best to get yourself started, but feel free to ask questions.
<ScottK> We're all volunteers here and we're glad to help you on your journey, but aren't generally inclined to put more into it than you do.
<darkace> thanks Scott
<ScottK> darkace: You're welcome.
<darkace> any ideas on how i can get confidence in running terminal commands
<darkace> i am quite new so any help is appreciated
<nhandler> darkace: The best way is to keep a terminal open all the time. Instead of using nautilus (or whatever GUI tool you use) to manage your files, try using the terminal
<ScottK> Practice.
<ScottK> Which is the short version of what nhandler said.
<nhandler> The man pages also provide valuable information
<darkace> thanks guys i will try my best
<darkace> i have read that there is a motu school on irc is it going to be helpful for me ?
<santiago-ve> also, learning to use screen would be usefull...
<nhandler> darkace: MOTU school isn't like a normal school. They hold sessions every now and then that explain various MOTU-related tasks.
<nhandler> darkace: https://wiki.ubuntu.com/MOTU/School
<darkace> ok
<nhandler> darkace: There is also a mentoring program that you might be interested in: https://wiki.ubuntu.com/MOTU/Mentoring
<ScottK> But it's completely optional.
<ScottK> You can also just get help here.
<didrocks> morning
<pochu> good morning
<DktrKranz> morning pochu
<pochu> hi DktrKranz :)
<thekorn> hi, I need some help with packaging a python script. This script is using sqlite, so it needs either python2.5 or python2.4 and pysqlite
<thekorn> this is my debian/control: http://paste.ubuntu.com/114506/
<thekorn> but it does not work as I expect
<thekorn> so my question is: what do I have to change to get something like: "use python2.5, if not available use python2.4 and also install pysqlite"
<pochu> hi thekorn
<pochu> thekorn: why it doesn't work? looks fine to me
<pochu> you may want "XS-Python-Version: >= 2.4"
<thekorn> hi pochu
<thekorn> pochu, first, it always installs python2.4, even on intrepid
<thekorn> also this |pythonpysqlite does not seem to work, pysqlite is not automatically installed
<pochu> thekorn: how does the Depends line on the binary package look like?
<thekorn> you mean this line? Depends: ${python:Depends}, ${misc:Depends}, python-libxml2, python (>= 2.5) | python-pysqlite2
<pochu> thekorn: no, in the control file in the .deb
<quadrispro> does anyone have some time to spend in reviewing this? :D http://revu.ubuntuwire.com/details.py?package=gnome-format
<thekorn> pochu, Depends: python-central (>= 0.6.7), python2.4, python-libxml2, python (>= 2.5) | python-pysqlite2
<pochu> thekorn: there you have, python2.4
<thekorn> pochu, where did I get this from?
<pochu> probably from XS-Python-Version
<pochu> try s/current/>=2.4/
<thekorn> ok, let me try it
<thekorn> thanks pochu
<pochu> python-central expands ${python:Depends} with some value from XS-Python-Version
<pochu> actually ISTR "current" is deprecated
 * thekorn needs to learn packaging some day, copy and paste from other packages is bad ;)
 * POX suspects hardcoded python2.4 in hashbang
 * pochu waves at POX :)
 * POX waves back
<thekorn> I got this 'current' from apport ;)
<pochu> thekorn: yeah, if you have some #!/usr/bin/python2.4 or similar, pycentral will add a python2.4 dependency
 * pochu didn't remember that
<pochu> even if I had that problem in the past... :/
<thekorn> I have #!/usr/bin/env python and #!/usr/bin/python let me try to change it to #!/usr/bin/python in both cases
 * POX suspects `python2.4 setup.pu ...` in debian/rules
<thekorn> no, nothing like this in debian/rules
<POX> paste debian/rules somewhere (not that I don't believe you ;)
<thekorn> hehe, sure
<thekorn> POX, http://paste.ubuntu.com/114514/
<POX> see, you have it in debian/rules :P
<POX> in /usr/share/cdbs/1/class/python-distutils.mk
<POX> also "Architecture: any" looks suspicious
<POX> (that's why CDBS compiles for all python versions, 2.4 included)
<thekorn> ok, so what's the plan to fix it?
<POX> I'm 75% sure you want "Architecture: all"
<POX> .... and that's all what you need to fix it
<thekorn> ok, cool, let's try it
<pochu> quadrispro: is that the replacement of gfloppy?
<pochu> quadrispro: I'll review it later on
<quadrispro> pochu: yes, it should replace gfloppy
<pochu> ok cool
<quadrispro> ok pochu, thank you
<pochu> quadrispro: thanks for packaging it ;)
<directhex> i'm building my first floppy-free desktop at the moment
<pochu> heh
<directhex> partly because the secondary os is vista, which can load disk drivers from non-floppy media
<directhex> partly because i have no floppy disks anymore & no idea where to find some
<savvas> which one is the correct conf destination? /etc/udev/libmtp8.rules or /etc/udev/rules.d/45-libmtp8.rules ?
<thekorn> pochu, POX, it worked, thanks again for you help
<zMoo> Good morning, everybody
<shankhs> I was navigating through LP to prepare for the Global Bug Jam I ran into this : https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/294991 the page says that its confirmed then triaged and I think its an upstream bug(right?) is there any more information I can get about this bug?
<ubottu> Ubuntu bug 294991 in telepathy-sofiasip "SIP/Ekiga accounts don't store contacts" [Unknown,Confirmed]
<shankhs> if its triaged then why its not removed from there ???
<shankhs> what is triaging of bug?
<iulian> shankhs: Please join #ubuntu-bugs and ask there.
<shankhs> iulian: ok thanx
<syockit> How do I check a build flag, e.g. @APPLET_GNOME_CFLAGS@? I seem to be having a problem where gnomeui-2 is always missed
<pochu> syockit: I'm not sure, but maybe config.log helps
<zMoo> hi, iulian
<iulian> Hey zMoo.
<zMoo> iulian: yesterday I have receive a mail from a maintainer of a swac-tools package for ArchLinux :)
<directhex> did he say "you ubuntu guys are always so awesome, please teach me your mighty ways"?
<syockit> ....
<iulian> directhex: Hehe.
<iulian> zMoo: That's nice.
<iulian> Arght, I have just installed Jaunty on a Toshiba Satellite and touchpad didn't work at all.
 * iulian wonders if this bug is already filed.
<iulian> I can't find any.
<directhex> yes, it's in the release notes
<directhex> "The X.Org synaptics driver is absent from the liveCD, which may prevent touchpad devices from working on laptops. As a workaround, use Ctrl+Alt+F1 to switch to console, log in, run sudo apt-get install xserver-xorg-input-all to download the drivers from the network, and then return to your session with Alt+F7."
<iulian> Interesting...
<iulian> Thanks.
 * iulian couldn't find any errors in /var/log/Xorg.0.log
<syockit> no synaptics in live? that shucks
<iulian> What does 'lp' mean?
<iulian> [   18.544046] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7
<iulian> [   19.303365] lp: driver loaded but no devices found
<mok0> iulian: line printer?
<iulian> mok0: Right.
<directhex> yay, parallel port!
 * slytherin tries to remember how parallel port looks. :-/
<directhex> http://www.detto.com/ecomm/images/cpuback-parallelPORT.jpg ?
<maxb> What a hideous shade of pink
<syockit> isn't that win99 standard or something?
<slytherin> directhex: I guess I have on on my PC at home. :-)
<mok0> Any of you kids know what a lineprinter is?
<directhex> syockit, PC99
<directhex> http://en.wikipedia.org/wiki/PC_97#Color-coding_scheme_for_connectors_and_ports
<maxb> "Burgundy" heh, no, that's sick pinnk
<syockit> never used burgundy as a colour name in my life
<iulian> mok0: (wikipedia) - The line printer is a form of high speed impact printer in which one line of type is printed at a time.
<mok0> iulian: heh
<mok0> and it makes one hell of a noise doing it
 * ScottK knows what a lineprinter is.
 * mok0 hasn't seen one in about 15 years
 * iulian doesn't even know how it looks.
<mok0> They were pretty large, about the size of a freezer
<iulian> Uhm
<mok0> found mostly in computer-centres
<mok0> It has a rotating drum with 132 wheels and each of those wheels prints a character on the line
<mok0> there are 132 hammers on the backside of the paper that slams the paper against the wheel
<mok0> so essentially, the whole line is printed at once
<iulian> That is so... old-fashioned.
<mok0> iulian: well, it was new technology back then :-P
<ScottK> It was a sledgehammer approach, but it was also very fast.
<iulian> Heh, indeed.
<mok0> Yeah, it could spit out a page per seecond or so
<mok0> iulian: show me a laserprinter that can do that ;-)
<pochu> mok0: those you find in stationer's? :)
<mok0> pochu: ok, I haven't seen those
<mok0> pochu: but usually, the laserprinter needs to render the page first in the RIP and that takes time
<mok0> These days, computer systems are faster but also about 10000 times more complicated
<mok0> The first mainframe I worked on had 8K of memory
<mok0> :-)
<mok0> but it was still able to run an operating system and run jobs
 * pochu feels young ;)
<mok0> Programmers were *smart* back then, you didn't just malloc(10000000) bytes
<mok0> :-P
<pochu> :)
<directhex> i don't malloc anything. i use JIT and garbage collectors!
<soren> Yeah. Back then, the argument to malloc was a float.
<mok0> heh
<iulian> :)
<mok0> you had to use temp files on one of the 10MB disks
<mok0> :-)
 * ScottK once served on a ship with systems sufficiently capable to take on and stop a big chunk of Soviet Naval Aviation that did it with less than 2MB of RAM.
<mok0> ... and a 500 line program most likely ;-)
<mok0> Amazing that it could be done
<mok0> I have more computer power in my wrist watch than they had on Apollo 11
<ScottK> yeah.
 * jcfp withnesses the early stages of the #ubuntu-geriatrics channel :)
<mok0> lol :-D
<orly_owl> walking stick required
<pochu> quadrispro: commented on REVU, it looks quite good
<quadrispro> pochu: i will work on it very soon, thank you!
<pochu> quadrispro: ping me once you're done and I'll advocate it ;)
<quadrispro> pochu: uploaded to REVU, you can see the buildlog here -> http://home.alessiotreglia.com/jaunty/result/gnome-format_0.1.1-0ubuntu1/
<pochu> I'm more interested in the debdiff ;)
<quadrispro> sure :)
<pochu> quadrispro: I have my doubts about the repackaging...
<quadrispro> pochu: tell me
<pochu> quadrispro: if it's not really needed, it's better to avoid it
<pochu> just poke upstream to not do that again in the next tarballs
<quadrispro> ah
<pochu> quadrispro: is there a technical or legal reason, or was it because of a lintian warning?
<pochu> well, that's my opinion
<quadrispro> mmm
<quadrispro> Since I have added waf license in debian/copyright, there's no license problem..
<pochu> so it would be ok to leave the .waf directory?
<quadrispro> IMHO there's no problem
<pochu> I think so too
<quadrispro> pochu: take a look at my first upload
<quadrispro> http://revu.ubuntuwire.com/report.py/legal?upid=4721
<pochu> the .waf directory looks like autogenerated code..
<quadrispro> yes, it's containing all autogenerated code
<pochu> then it's fine
<pochu> so what I would do is not repackage the tarball, and tell upstream about that
<quadrispro> yes, you're right
<pochu> and while at it, tell them that putting the tarballs somewhere else than a wiki page would be nice :)
<pochu> I'm not sure if we can make a watch file for that
<quadrispro> pochu: probably I've found a solution for moinmoin compatibility issue with uscan
<pochu> I've tried it but didn't worked, maybe there are tricks for that
<pochu> quadrispro: ah cool!
<quadrispro> pochu: MoinMoin reject some kind of user agent
<pochu> they should be using ftp.gnome.org anyway...
<quadrispro> pochu: as you can see in debian/rules I have added a --user-agent option to wget
<quadrispro> wget command *
<pochu> but getting the watch file to work now would be cool ;)
<pochu> yes
<quadrispro> eh, I'm workin on it, I need sometime and the feature freeze is coming
<quadrispro> (in the last period i'm studying hard :P)
<syockit> what is the tool for checking the headers provided by a specific flag? e.g. APPLET_GNOME_CFLAGS
<pochu> syockit: pkgconfig?
<quadrispro> pochu: uploaded to REVU
<pochu> with orig tarball?
<slytherin> any java packagers around? I need helping hand.
<directhex> build-depends: ikvm!
<quadrispro> pochu: re-uploaded with orig tarball
<quadrispro> and some little changes (updated changelog, removed README.source, now unnecessary)
<slytherin> directhex: what all good java programs have you built with ikvm till now?
<quadrispro> hi mok0!
<mok0> quadrispro: hi
<quadrispro> could you take a look at this? -> http://revu.ubuntuwire.com/details.py?package=gnome-format
<mok0> quadrispro: sure
<mok0> quadrispro: will just fetch a cup of coffee
<quadrispro> eh! fetch one for me too :D
 * mok0 hands quadrispro a virtual cup of coffee
<mok0> quadrispro: what's that .waf-1.5.0-* directory?
<quadrispro> i'm here
<quadrispro> oh, .waf* containing autogenerated code
<mok0> quadrispro: ok, looks ugly
<quadrispro> mok0: yes, in fact in the previous uploads I used get-orig-source to repack the tarball
<pochu> mok0: yeah, but it's better than repackaging ;)
<pochu> bbl, lunch
<mok0> quadrispro: does it mean you no longer use the get-orig-source target?
<quadrispro> no no, get-orig-source is needed to retrieve the tarball
<quadrispro> and repack it
<mok0> quadrispro: uhm, you said above that you used to repack (to get rid of the .wap-* stuff I thought)
 * mok0 fires up his trusty sbuilder
<quadrispro> now I used get-orig-source to retrieve the tar.bz2 and repack it as orig.gz
<quadrispro> without dropping .waf dir
<mok0> ok
<quadrispro> s/used/use
 * mok0 wonders wft wap is for
<slytherin> quadrispro: are you removing anything from upstream tar ball while doing repacking?
<mok0> slytherin: not anymore
<slytherin> then a simple uscan --repack should be sufficient, right?
<mok0> yeah
<quadrispro> slytherin: uscan has some problem with moinmoin
<mok0> quadrispro: ah?
<quadrispro> slytherin: at the moment I can't use a watch file
 * mok0 picks up the challenge
<quadrispro> as you can see, I used a --user-agent option for wget command, moinmoin seems reject some kind of user agent
<mok0> quadrispro: ah, they are getting smart huh?
<quadrispro> :D eh, I've noticed that moinmoin developers upload new release to a static site ;)
<quadrispro> mok0: anyway I will send an email to upstream authors, in order to ask them to not include the .waf* dir in the next releases
<mok0> quadrispro: ok... can we rebuild these files using waf?
<c_korn> hello, I am currently opening bug reports for syncing scilab-5.0.3 into jaunty. unfortunately scilab-5.0.3 requires jeuclid which is currently in debian-science. I have compiled all necessary packages in this PPA. https://launchpad.net/~getdeb.packages/+archive/ppa everything works fine. but can jeuclid make it into jaunty?
<quadrispro> mok0: yes
<mok0> c_korn: I've been tracking that too
<mok0> c_korn: it seems Debian's NEW queue is completely halted
<Laney> It's still moving
<mok0> How long has jeuclid been in it?
<Laney> 1 month
<Laney> I reckon it'll get done before FF
<mok0> c_korn: of course, you might play with it and test if it builds
<mok0> c_korn: to be prepared for a quick move @FF
<quadrispro> coming back soon
<c_korn> mok0: all packages required for scilab-5.0.3 are already built and work fine. they are available in this PPA. https://launchpad.net/~getdeb.packages/+archive/ppa can these packages be QAed for making it into jaunty? they are required by scilab-5.0.3
<slytherin> c_korn: Why not take the Debian package add a jaunty changelog entry and upload to Ubuntu?
<mok0> c_korn: file a lp bug, giving the PPA, subscribe ubuntu-universe-sponors and we can take a look
<Laney> it's near the front of the queue; should be done within a few days
<mok0> Oh that sounds good
<Laney> I'd say wait until the middle of next week and then ~ubuntu1 the debian version
<c_korn> mok0: here it is: https://bugs.launchpad.net/ubuntu/+bug/326179
<ubottu> Ubuntu bug 326179 in ubuntu "Please sync jeuclid 3.1.4 from debian-science" [Undecided,New]
<c_korn> I will compile version 3.1.4 now
<mok0> c_korn: I am subscribed to the bug, and I will keep tracking it
<c_korn> ok, thank you
<mok0> c_korn: since it's new package we need 2 ACKs for it
<c_korn> ok. I am sorry that I subscribed ubuntu-archive to the scilab sync request before reading the wiki. https://bugs.launchpad.net/debian/+source/scilab/+bug/272264 any chance of unsubscribing them?
<ubottu> Ubuntu bug 272264 in scilab "Please sync scilab-5.0.3 (multiverse) from PPA" [Wishlist,Confirmed]
<mok0> c_korn: yeah, they can do it themselves
<c_korn> ok
<mok0> c_korn: especially if you make a note to that effect
<c_korn> note added
<RainCT> heya
<mok0> Hi RainCT
<quadrispro> right here again
<quadrispro> mok0: what do you think about it?
<mok0> quadrispro: looks good
<mok0> quadrispro: fsck'ing around with that watch file :-P
<quadrispro> fine, thanks, but perhaps I've found a solution ;)
<quadrispro> uscan has --user-agent option too
<henrik-hw0> Any MOTUs here want to give libmirage a 2nd advocate?
<mok0> quadrispro: I can't get uscan to do web scraping, the href's are hidden inside <link> tags
<mok0> quadrispro: and uscan wants <a href=...> AFAIK
<quadrispro> yes, it's true
<quadrispro> mok0: I'll send a mail to upstream
<quadrispro> I would ask them to 1) remove .waf* from next release tarballs 2) look for an external host where put the source tarball :)
<pochu> quadrispro: be nice to them :)
<jpds> quadrispro: Hey, you wanted a pigin-facebookchat backport to hardy, can you test the package I uploaded to the ppa for it?
<quadrispro> hi jpds! at the moment I can't, I use hardy at work, I'll do it really soon ;)
<mok0> quadrispro: heh get it to work
<mok0> quadrispro: GOT it to work I meant to say
<quadrispro> mok0: ehehe
<mok0> quadrispro: can you receive files via DCC?
<quadrispro> mok0: boh! I don't know
<quadrispro> send me via jabber/gmail
<mok0> quadrispro: what's your irc client?
<quadrispro> pidgin
<mok0> quadrispro: you can
<quadrispro> ok
<mok0> quadrispro: do you get a dialogue box?
<quadrispro> yes
<quadrispro> i've accepted
<quadrispro> but nothing happens
<mok0> quadrispro: meh
<quadrispro> mok0: listen to me, jabber ;)
<mok0> quadrispro: I'll pastebin it
<quadrispro> oh good
<mok0> http://pastebin.com/f4ef697e7
<mok0> Simple, huh? :-P
<quadrispro> too simple :D
<mok0> quadrispro: I'll finish the review now....
<quadrispro> yeah, it works :)
<quadrispro> I'll update debian/rules now
<pochu> quadrispro: if that works, remove the get-orig-source ;)
<quadrispro> yes
<mok0> pochu: quadrispro, well it might just be rewritten using uscan with the proper parameters
<mok0> Otherwise, we need a Debian.source file or something saying how to repackage
<pochu> mok0: uscan --repackage
<mok0> uscan does not do it by itself
<quadrispro> mmm... it could be used with the syntax: uscan --force-download --repack
<pochu> uscan --repack rather
<mok0> quadrispro, pochu, right
<pochu> that will `bunzip && gzip -9` afaik
<mok0> quadrispro: ... perhaps --user-agent "" ?
<quadrispro> i'm just making some test
<anakron> hi all
<anakron> hi rainCT
<RainCT> hi :)
<anakron> hi Scottk
<anakron> im working in a catfish bug
<ScottK> OK
<anakron> i confirmed that i use like home path his installation path
<anakron> the path where catfish is being loaded
<ScottK> OK
<quadrispro> mok0: uscan downloads a file with a wrong name...
<quadrispro> "gnome-format: Successfully downloaded updated package Download"
<anakron> and catfish does not create any configuration file, so its more difficult to follow the bug
<anakron> someone have sound problems in jaunty?
<anakron> someone solved it?
<anakron> i dont have sound
<mok0> quadrispro: argh
<ScottK> anakron: I haven't looked into the catfish thing.  I wouldn't feel obligated to stick with it if it turns out not to be a good one.  There are plenty of others.
<mok0> quadrispro: at least it tells you if there's a newer version :-)
<quadrispro> eh, it downloads the page, not the tarball
<mok0> meh
<anakron> :) ij
<quadrispro> sure, it is a good result :)
<anakron> :)ok
<mok0> quadrispro: anyway I submitted my commetns
<quadrispro> oh perfect mok0, I'm workin on it now
<mok0> quadrispro: what's the story with w-scan?
<anakron> which is the name of root terminal package?
<quadrispro> mok0: it has been uploaded in debian NEW and superm1 told me that it's better wait until 2-3 days before FF
<mok0> quadrispro: did you upload to Debian? Or did someone hijack the package?
<quadrispro> mok0: no, a guy worked on it some time ago, but he isn't sure if there's very much interest for that package
<quadrispro> after our request he has reviewed the package and uploaded it to NEW
<mok0> quadrispro: then he probably is not a good maintainer for it
<quadrispro> mmm he isn't the maintainer...
<mok0> quadrispro: ah, so it
<mok0> it's essentially the same package
<quadrispro> mok0: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426390
<ubottu> Debian bug 426390 in wnpp "ITP: w-scan -- Scans DVB-T and DVB-C transponders for channels" [Wishlist,Closed]
<quadrispro> yes mok0, it's almost the same
<mok0> quadrispro: good
<mok0> I hate it when someone hijacks a package we've worked on in REVU and uploads some worthless hack to Debian
<mok0> DD's thinks their packages are better than Ubuntu's, but they're not
<RainCT> mok0: wise words :P
<mok0> RainCT: everything that comes out of REVU is completely lintian clean
<quadrispro> mok0: uploaded another time :P
<mok0> quadrispro: ok
<sven777> http://revu.ubuntuwire.com/details.py?package=lmalinux is lintian clean - anyone care to help me out with advocating it?  :)
<ScottK> mok0: I think Debian is a collective of individuals.  Any time you refer to Debian or DD's collectively you're likely partly right and partly wrong.
<mok0> ScottK, yeah I shouldn't generalize
<mok0> The fact is that many Debian packages ain't too pretty
<ScottK> That's generally true, but even more so for Debian.
<ScottK> Agreed.
<ScottK> Some of ours suck too.
<mok0> heh
<mok0> I think the packages that come out of REVU are generally very carefully done
<mok0> ... and checked by several people
<mok0> sven777: this is software for music?
 * RainCT wonders whether the authors of cheese intentionally gave it as much build deps as they could :P
<sven777> mok0 - there is a hardware device called Logitech Music Anywhere - which is a USB dongle (which is basically an audio card) and the other part is a handheld receiver/remote control
<sven777> this package interprets the remote control data and allows the user to have commands executed when the buttons are pressed on the remote control
<mok0> sven777: Oh, I've not heard about that device before... sounds cool
<mok0> sven777: you are upstream author?
<sven777> yes
<mok0> sven777: great that makes things a lot easier :-)
<sven777> it's a neat little device because it's small and silent
<sven777> me and the wife use it in the bathroom
<mok0> sven777: kinky :-)
<sven777> the wife and I, rather
<sven777> hehe :)
<mok0> sven777: I'll take a look
<sven777> thx v. much :)
<mok0> sven777: I thought it was some special linux version or something
<mok0> sven777: perhaps lma4linux would be a better name?
<mok0> sven777: up to you of course
<sven777> heh - I got caught up in the 8-character name
<sven777> but yeah that might be a better name
<sven777> of coruse, I don't think anyone's going to know what either of those mean just from that abbreviation
<mok0> sven777: yeah
<sven777> but I couldn't come up with something short and also descriptive
<surfaz> Anybody can have a look of this?
<surfaz> http://revu.ubuntuwire.com/details.py?package=gparted
 * RainCT saw a pad which you connected to the PC and then you could place objects (like a coffee cub or whatever, after adding a little chip to them) on it and it would execute a command :P
<maxb> surfaz: gparted is already included in Ubuntu. REVU is only intended for new packages.
<surfaz> And for updated?
<iulian> surfaz: Launchpad, attach the diff.gz file.
<surfaz> maxb, and this
<surfaz> http://revu.ubuntuwire.com/details.py?package=audacious-skins
<surfaz> is a new package or not?
<surfaz> iulian, done
<surfaz> I don't know how fix "This package has no debian/watch file or get-orig-source rule."
<surfaz> because this package is a collection of skins of Audacious. In other words, this package is not a program.
<maxb> Where does the collection come from?
<surfaz> is a conversion of xmms-skins package (and added two new skins of gnome-look.org)
<surfaz> maxb, https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/208307
<ubottu> Ubuntu bug 208307 in audacious "xmms-skins package should be converted to audacious-skins" [Wishlist,In progress]
<maxb> If it's a logical continuation of the xmms-skins package, I think its version number should reflect that, and the old debian/changelog entries should be retained
<surfaz> maxb, xmms-package is 0.6, audacious package should be 0.6 too or 0.7. I put 0.1 because is not a update, is a conversion
<quadrispro> jpds: ehm... I didn't request the pidgin-facebook plugin backport for hardy :)
<quadrispro> I'll test it, anyway :)
<surfaz> maxb, ?
<quadrispro> soren: thanks for your feedback ;)
<maxb> Well, it's up to you - if the skins are largely the same, just installed differently, it seems to me there's enough commonality to consider the new package a new version with a different name, and hence just increment the version number.
<maxb> It would be a good idea to check with the debian maintainer of xmms-skins whether he plans to do anything similar.
<surfaz> maxb, last changes of old Debian mantainer are of 2005-07-10
<surfaz> http://packages.qa.debian.org/x/xmms-skins.html
<soren> quadrispro: Oh, don't mention it. Sorry I took so long. :/
<quadrispro> :)
<RainCT> Can someone unsubscribe main-sponsors from bug #206280? I added it by mistake :/
<ubottu> Launchpad bug 206280 in lm-sensors "[hardy] Error opening config file: /etc/sensors.conf" [High,Confirmed] https://launchpad.net/bugs/206280
<surfaz> maxb, I think that Debian maintainer abandoned package or not has plans to convert it to Audacious.
<surfaz> 2005-07-10 -> 2009 Is too time
<surfaz> but how I fix "This package has no debian/watch file or get-orig-source rule."
<surfaz> How I should fix that "bug" when this package is a collection of skins for Audacious.
<mok0> surfaz: gparted? That's already in Ubuntu
<surfaz> mok0, no
<surfaz> audacious skins
<surfaz> http://revu.ubuntuwire.com/details.py?package=audacious-skins
<surfaz> audacious-skins package
<mok0> surfaz: uhm didn't you ask for review of gparted before?
<surfaz> yes, but maxb answer me "gparted is already included in Ubuntu. REVU is only intended for new packages."
<mok0> surfaz: well...
<surfaz> But I think that gparted should be updated to 0.4.2. That release adds ext4 support
<mok0> surfaz: we prefer updates to packages through a LP bug report
<surfaz> mok0, https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/305280
<ubottu> Ubuntu bug 305280 in gparted "[need-update] Gparted to latest stable 0.4.2 in Ubuntu Jaunty" [Wishlist,In progress]
<surfaz> mok0, https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/305280/comments/8
<surfaz> my diff.gz
<mok0> surfaz: ok, then you attach the diff.gz file to that bug and ask for sponsorship by subscribing u-u-s
<surfaz> fixed problems with patches and upstream, import changes of Debian and add Launchpad bugs fixed
<mok0> ah
<mok0> he
<StevenK> RainCT: Done
<surfaz> mok0, http://launchpadlibrarian.net/22049788/gparted_0.4.2-1ubuntu1.diff.gz
<mok0> surfaz: so go into the +Subscribe button
<RainCT> StevenK: Thanks.
<mok0> Ah you
<surfaz> Ubuntu Sponsors for main already subcribed
<mok0> ok so we can actually nuke gparted from REVU
<mok0> booom
<surfaz> what?
<mok0> surfaz: I removed gparted from REVU
<surfaz> mok0, and what about this http://revu.ubuntuwire.com/details.py?package=audacious-skins
<mok0> surfaz: looking at it this very minute
<jcfp> http://revu.ubuntuwire.com/details.py?package=sabnzbdplus (popular binary newsreader, written in python) needs a second advocate - please consider for review.
<mok0> surfaz: found all over the internet... don't you have the url's where they were downloaded?
<surfaz> mok0, audacious-skins is a conversion of xmms-skins of Debian
<surfaz> well, a continuation
<mok0> surfaz: done by... you?
<surfaz> ehh, yeah?
<surfaz> there is a problem?
<mok0> surfaz: and you don't have a place where you are distributing a tarball?
<surfaz> http://packages.debian.org/etch/xmms-skins
<surfaz> converted to audacious-skins
<surfaz> and added two new skins of gnome-look
<mok0> surfaz: manually?
<surfaz> gnome-look.org
<surfaz> mok0, the package? yes
<mok0> surfaz: no, I mean when you get an xmms skin from somewhere, what do you have to do to convert it?
<surfaz> no
<RainCT> (In case someone wonders, if just got ride of the welcome message on REVU. It won't be showed by default anymore now, only if you click the "help" link.)
<surfaz> xmms-skins works in Audacious
<surfaz> please, read https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/208307
<ubottu> Ubuntu bug 208307 in audacious "xmms-skins package should be converted to audacious-skins" [Wishlist,In progress]
<mok0> surfaz: oh, I see
<mok0> surfaz: huge effort
<surfaz> I am build package for Intrepid now
<sven777> mok0: doh I forgot to include the watch file!
<mok0> sven777: just upload another version
<sven777> mok0: is there a package that would have automatically checked the get-orig rule?  because I'm using uscan in it so I would think it would fail without the watch file
<RainCT> surfaz: can I unsubscribe u-u-s from that bug? having it subscribed isn't necessary for uploads to revu
<RainCT> s/uploads to/stuff on
<mok0> sven777: you don't need the get-orig-source file when youre not repackaging the tarball, which you don't need to do
<surfaz> RainCT, what bug?
<RainCT> surfaz: 208307
<mok0> sven777: but the EHHS site tries to run the watch file and sees if a newer version is available
<surfaz> RainCT, audacious-skins is a new package converted from xmms-skins
<sven777> mok0: oh ok - I was trying to follow standards - thought i read something about the get-orig rule being something that "should" be present
<RainCT> surfaz: but are you going to upload it again to revu or to attach a debdiff to the bug?
<mok0> sven777: oh, not if the package is in tar.gz format and nothing has to be removed for license reasons
<mok0> RainCT: I am reviewing it now
<surfaz> RainCT, I don't undestand you
<sven777> mok0: ok gotcha - would it hurt anything to leave it in?
<mok0> surfaz: You have subscribed u-u-s to the bug, which is not necessary when the package is being reviewed on the REVU site
<RainCT> mok0: The wiki currently says that having it even if there's a watch file gives "extra points". Perhaps that should be ammended.
<surfaz> ahh
<RainCT> mok0: (about the get-orig-source)
<mok0> RainCT: ah, ok
<mok0> RainCT: I think it's generally useless
<mok0> :-)
<RainCT> Me too
<mok0> The new source format can deal with both .bz2 and .zip files
<mok0> ... and it applies patches when the package is unpacked
<jcfp> plus uscan can convert when getting the source if need be
<RainCT> mok0: you mean it's now possible to use .orig.tar.bz2?
<mok0> jcfp: right
<mok0> RainCT: not now, but when version 3.0 of the source package format is supported
<mok0> RainCT: and debian/ can be stored in a tar.gz file
<mok0> RainCT: diff.gz becomes redundant
<RainCT> Cool!
<mok0> yeah
<RainCT> mok0: and what will happen with directly patching the source?
<mok0> This format will also play much nicer with the VCS schemes for packaging
<mok0> RainCT: I don't think it's possible, you need to have patches in debian/patches to do it
<mok0> RainCT: pretty much what we enforce now
<RainCT> mok0: yeah, but aren't there people who use VCS and patch the source directly?
<mok0> RainCT: uhm, I don't know... you aren't supposed to
<RainCT> (I've heard about that, but haven't seen it myself yet)
<mok0> RainCT: I think the VCS is capable of creating the patches
<mok0> RainCT: all fixes are kept in feature branches
<RainCT> Ah, nice
<mok0> RainCT: so patches can be made by diff'ing to the upstream branch
<RainCT> yeah, makes sense
<mok0> RainCT: I think that's the idea, at least
<tonton_zMoo> Yo, RainCT! I'm looking for an advocate for my second package "swac-scan"! :)
<surfaz> RainCT, mok0 then remove also this package of Revu
<surfaz> http://revu.ubuntuwire.com/details.py?package=audacious
<jpds> quentusrex: Gah, for some reason I confused you with spinus..
<jpds> quentusrex: Sorry, I meant quadrispro ^
<mok0> surfaz: ok will do
<RainCT> tonton_zMoo: alright, I'll try to have a look at it later
<tonton_zMoo> Great, Excellent :)
<RainCT> tonton_zMoo: poke me again if I haven't told you anything in sth like 3 hours
<jpds> quadrispro: Hmm, same first name appartently. :)
<tonton_zMoo> RainCT: I'll not be there the next week (I'm in hollydays)
<tonton_zMoo> but I can poke you on monday 16 fev
<quadrispro> jpds: LOL
<quadrispro> ehm... gnome-format needs some love
<c_korn> maybe OT here but why keep I getting this mail although I have already deleted the package in the PPA? http://pastebin.com/m39ae1794
<ScottK> c_korn: Ask in #launchpad
<c_korn> thanks
<giftnudel> hello, I'd like to raise your attention to bug #320797 Could that be taken care of fast?
<ubottu> Launchpad bug 320797 in hubackup "Remove hubackup from repositories (no GUI restore!)" [Undecided,Confirmed] https://launchpad.net/bugs/320797
<giftnudel> (fast: before releasing jaunty
<RainCT> uhm.. where does python-central put the .pyc files?
<ScottK> RainCT: I think in /var/lib
<RainCT> ScottK: There's only python-support starting with py* :P
<quadrispro> mok0, pochu: around here?
<mok0> quadrispro: here
<mok0> Looking at your gnome thing
<quadrispro> ah thank you
<mok0> Still builds :-)
<quadrispro> mok0: give me you GPG key, I'll add you to quadromatic ring
<mok0> quadrispro: 0x404825e7
<quadrispro> (quadromatic => http://home.alessiotreglia.com)
<quadrispro> mok0: added, that's dput configuration -> http://home.alessiotreglia.com/dput_configuration
<mok0> cool
<mok0> you have a fast server?
<quadrispro> for the password in pvt
<quadrispro> mok0: no, it's my PC :)
<mok0> heh
<mok0> quadrispro: as a matter of fact, I was just going to make a new build of gcc
<pochu> quadrispro: yeah
<mok0> ;-)
<quadrispro> pochu: give me your gpg key please
<pochu> quadrispro: it's 4A08B2FE, but I don't think I'm going to use that ;)
<quadrispro> well :)
<mok0> pochu: you can use it for quadrispro's packages
<mok0> :)
<pochu> heh
<pochu> quadrispro: does it run in a VM?
<quadrispro> no no
<RainCT> ScottK: ah, /usr/lib/python2.5/site-packages/
<pochu> because the other day we were talking here about how to break out of chroots ;)
<quadrispro> it's a debomatic server
<ScottK> I knew there was a lib in there somewhere.
<quadrispro> sh
<quadrispro> ah
<pochu> quadrispro: you should be careful to who you give access then ;)
<jmarsden> REVU Day: I'd welcome any review of my webgui package on REVU: http://revu.ubuntuwire.com/details.py?package=webgui -- MOTU or not, review would be appreciated :)
 * pochu had access to Andrea Veri & Luca Falavigna's server, but didn't use it
<pochu> DktrKranz: how's Andrea?
<quadrispro> eh, I give access to people who I consider "trusted" :)
<DktrKranz> pochu: gone for good (searching for his gf's love)
<pochu> quadrispro: but you can trust IRC! ;-)
<pochu> s/can/&'t/
<quadrispro> ahh
<quadrispro> mmm
<DktrKranz> quadrispro: if trust is not enough, what about euros?
<pochu> heh
<RainCT> quadrispro: so you don't trust me? ;(
<DktrKranz> pochu: give him a bunch of euros, you'll gain trust he needs
<quadrispro> RainCT: sure
<DktrKranz> :)
<RainCT> heh
<quadrispro> DktrKranz: (good idea ;))
<pochu> quadrispro: OTOH if you run the server on a VM, you won't loose much if somebody breaks something
<pochu> but it'll be harder to setup :)
<DktrKranz> LVM?
<RainCT> VirtualBox is surprisingly easy to setup
<jdong> yeah
<jdong> IIRC the only thing annoying to configure is bridging
<jdong> vmware was much more out-of-the-box for bridged network setups
<quadrispro> with VirtualBox is surprisingly easy to do everything
<jmarsden> jdong: That is fixed in the current version of virtualbox...
<jdong> jmarsden: oh then I guess I need to put trying it on my TODO list :)
<pochu> but you probably don't want VBox to build packages ;)
<jdong> thanks for letting me know
<jmarsden> No problem... I asked about it on #virtualbox or #vbox or whereevr their people hang out...
<sven777> mok0: new lmalinux version, fixed all those issues you noted
<mok0> sven777: thanks!
<sven777> mok0: thanks very much again for looking at it!
<mok0> sven777: np!
 * quadrispro coming back soon
<DktrKranz> pochu: we have XEN to build packages ;)
<DktrKranz> in PPAs, at least
<DktrKranz> we're not so good and we haven't money, so we use debomatic on some obsolete hardware
<quadrispro> DktrKranz: tell mok0 the password for quadromatic ;)
<mok0> quadrispro: you need a password even when the gpg key is installed?
<mok0> quadrispro: errhh, it wasn't the ssh key you wanted was it?
<DktrKranz> password is a little... hard
<mok0> DktrKranz: is has the space character in it too?
<DktrKranz> mok0: nono, a single word, but a "red light" one :)
<mok0> uhuh
 * DktrKranz is off, back in some hours
<szabgab> hi, I would like to get Padre a Perl IDE I am developing into Ubuntu, most of its dependencies are already included in Debian and it has an entry in launchpad https://launchpad.net/padre
<szabgab> but it seems to be stuck there, how could I get someone to pick it up and make it sure it will be packaged into the next release of Ubuntu ?
<Tell360> ??
<Tell360> szabgab:  hi
<mok0> szabgab: you're looking for someone to package it?
<szabgab> yes
<szabgab> most of its dependencies are packaged in Debian already so I think those will need to be synced only
<mok0> szabgab: that's not so easy to find
<szabgab> oh yes it is written in perl and distributed as a CPAN package
<mok0> szabgab: best chance is doing it yourself and uploading to REVU for review
<Tell360> æ­·å²çå¤©ç©º
<szabgab> is there a forum or mailing list of people who deal specifically with Perl related issues in Ubuntu ?
<szabgab> I have enough on the plate with the development and with the begging of others for help (which so far worked ok as it was already packaged in Fedora and Mandriva)
<mok0> szabgab: there's a perl team in Debian
<szabgab> yeah I know I am on their list
<RainCT> Why don't you ask them to package it, then?
<mok0> szabgab: ubuntu is more python oriented
<szabgab> and begged them so they already packaged every part of Padre, except they are stuck with an old wxWidgets
<mok0> heh
<RainCT> oh
<szabgab> but Ubuntu - which I am also using - has the new version of wxWidgets so it won't have that problem
<mok0> szabgab: right
<szabgab> that's why I think it should not be a big issue for someone familiar with the way packaging Perl modules for Ubuntu
<mok0> szabgab: https://edge.launchpad.net/~perl-jam
<mok0> Very small team :-)
<szabgab> yeah, one member :-(
<mok0> szabgab: but he's a MOTU
<mok0> szabgab: https://edge.launchpad.net/~perl
<mok0> quadrispro is a member of that one
<szabgab> mok0, thanks a lot, looking around now
<mok0> np
 * mok0 fetches coffe
<szabgab> who is quadrispro ?
<Tell360> ç±ç¶²åç¼èµ·ãç¶²åæç¨¿çæ° Debian T-Shirt 2009ï¼å³å°æ¼å¹´åºåè£½ä»å°å
 * jcfp wonders who ordered dinner from the chinese take-away
<quadrispro> bye guys, see you soon
 * mok0 wonders who ordered a Debian T-shirt from the chinese take-away...
<quadrispro> bye mok0 pochu
<mok0> bye
<fabrice_sp> Hi. Sync request should be left with the state New, right? I'm never able to remember that...
<RainCT> fabrice_sp: Yep, MOTUs confirm them
<mok0> fabrice_sp: yes until someone acks it
<fabrice_sp> ok. And about merge requests, it doesn't matter, right?
<mok0> fabrice_sp: right
<pochu> fabrice_sp: not really
<pochu> well, doesn't matter between confirmed and new. Fix released does matter ;)
<fabrice_sp> pochu, that's what I mean ,yes :-)
<fabrice_sp> thanks to all of you for your answers
<fabrice_sp> (I'll check my sync requests and merge requests are ok)
<szabgab> mok0, so I left a message in that perl group, thanks for your help so far!
<mok0> szabgab: you're welcome, good luck with your project
<mok0> Going to dinner, see you later guys!
<sven777> would a MOTU be so kind as to review my package?  http://revu.ubuntuwire.com/details.py?package=lmalinux
<sven777> mok0: by mok0 - thank you for your help
<sven777> *bye
<mok0> bye
<aboudreault> hi, if i am a member of a launchpad group, can i upload ppa on it ? or i need more permissions
<aboudreault> is this line: incoming = ~UbuntuGis/ubuntu/
<aboudreault> ok  for upload a package to https://launchpad.net/~ubuntugis ? (sorry, i'm not familiar with launchpad)
<maxb> aboudreault: That team doesn't appear to have a PPA (yet?)
<maxb> I assume you have to do something in the web interface to activate it
<aboudreault> ah, ok i'll ask the administrator
<asomething> aboudreault: any team member can upload, but I think an admin has to create it
<aboudreault> good to know, i just sent an email to the administrator.
<aboudreault> also... if dput tells me: Already uploaded to ppa.launchpad.net ... when the PPA will be activated, is there a way to by-pass this ?
<asomething> aboudreault: dput -f  or just delete the *.upload file
<RainCT> Guys, I hope you'll be happy to hear that cookies on REVU last for one month since the last access now :).
<aboudreault> ha ok... the info is local, i thought that it was the response of the server. Thanks a lot for your help.
<RainCT> Just don't look at the code - it's a very ugly hack :P
<asomething> any one know of a good tutorial on pbuilder hooks? specifically I want to run dh_install --list-missing for everything I build
<ScottK> asomething: Let me get you that hook ...
<ScottK> asomething: If you look in kubuntu-dev-tools there's a hook for that, I'm pretty sure.
<asomething> ScottK: thanks!
<aboudreault> oh btw, if anyone know well launchpad system.... is it possible to put a group PRIVATE.... but to have a PUBLIC mailing list ?
<ScottK> aboudreault: Ask in #launchpad
 * ScottK needs a key binding for that.
<aboudreault> hmm... i even not tried if that channel exist. :)
<emgent> NEWS: Utu is back online, until it is integrated into ubuntustats. (http://thc.emgent.org/utu/)
<martijn81> when will there be a backport of ktorrent in intrepid?
<asomething> ScottK: is  kubuntu-dev-tools packaged some where or is it just the bzr branch?
<ScottK> I thought it was in Jaunty, but not sure.
<ScottK> Ask on #kubuntu-devel
<martijn81> ScottK: are you talking to me?
<ScottK> martijn81: No
<ScottK> martijn81: For your question, I guess the question is has anyone asked?
<ScottK> !backports > martijn81
<ubottu> martijn81, please see my private message
<martijn81> ScottK: i have the backports enabled, but there is no ktorrent backport yet
<martijn81> and ktorrent 3.2 will come out in 1.3 weeks or so
<martijn81> so if they would package that it would de awsome
<ScottK> Did anyone request one (look in bugs in intrepid-backports)
<martijn81> i don't think so, but let me check
<martijn81> nope-> https://bugs.launchpad.net/intrepid-backports/+bugs?field.searchtext=ktorrent&orderby=-importance&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<ScottK> Then the way to get a backport going is to follow the instructions the listed on the page the bot PM'ed to you.
<asomething> hmm... the scripts in kubuntu-dev-tools are all in ruby
<JontheEchidna> I think the pbuilder-hooks might be in a separate branch
<JontheEchidna> yeah
<asomething> ah, I found them: ~kubuntu-members/pbuilder/pbuilder-hooks
<JontheEchidna> asomething: https://code.edge.launchpad.net/~kubuntu-members/pbuilder/pbuilder-hooks
<JontheEchidna> yup
<asomething> JontheEchidna: thanks
<JontheEchidna> you're welcome
<henrik-hw0> Any MOTUs here want to give libmirage a 2nd advocate?
<asomething> thanks all! the hook does just what i need...
<jpds> ScottK: What was the lintian command you recommend using? (-Iv something?)
<ScottK> lintian -iIv
<ScottK> One of the 'i' give you a good explanation and the other one gives you the info level tags.
<jpds> Yep, thanks.
 * ScottK can never remember which is which
<khashayar> I'm trying my luck packaging slv2 (which is a library that makes use of lv2). The idea is to build three debs (libslv2, libslv2-dev, and libslv2-bin). But packaging fails with "dpkg-shlibdeps: failure: couldn't find library libslv2.so.9 needed by debian/libslv2-bin/usr/bin/lv2_list". Any ideas where I can poke for more info?
<sven777> would a MOTU be so kind as to review my package?  http://revu.ubuntuwire.com/details.py?package=lmalinux
<hefe_bia> Hi! I believe tomboy-blogposter (http://revu.ubuntuwire.com/details.py?package=tomboy-blogposter) is almost ready. It's been previously advocated by sikon and mok0. I followed suggestions for mono 2.0 transition. Maybe somebody is willing to have a look?
<directhex> ding ding
<directhex> a package i can usefully comment on. hooray!
<hanska> directhex: go sponsor it in Debian :P
<directhex> hanska, o hai, what're you doing HERE? :o
<hanska> directhex: ;)
<hanska> directhex: /me would like to become a MOTU too, someday
<directhex> and help to add bugs?
<hanska> directhex: probably help by fixing
<hanska> directhex: I also reviewed some packages in REVU ;)
<directhex> hanska, spot anything i missed on the above?
<hanska> directhex: err, remember I'm studying? ;)
<hanska> a sec, let me check
<directhex> you can't study at this late hour! it's bad for the brain
<hanska> directhex: exam on 12..
<directhex> you're gonna feel pretty silly if the first question is "how many shotgun blasts does it take to kill a zombie" and you don't know because you didn't spend enough time studying videogames!
<RainCT> lol
<hanska> directhex, hefe_bia: reviewed :)
<hanska> directhex: go see :P (my brain probably still works.)
<NCommander> StevenK, w.r.t to cvsconnect, do you know where the upstream is? I can't find an upstream site with actual tarballs
<StevenK> NCommander: What does debian/copyright say?
<NCommander> mcasadevall@blacksteel:~/tmp/cvsconnect-0.1.cvs20001202/debian$ ls -lah copyright
<NCommander> ls: cannot access copyright: No such file or directory
<NCommander> Well ...
<NCommander> That's new ...
<StevenK> I think the copyright is in another debian file
<StevenK> What other files are there?
<NCommander> changelog, control, packages, rules
<NCommander> I don't see it at all
<StevenK> debian/packages should contain a mess and the copyright
<NCommander> Ugh, found it
<NCommander> But I only see cvssuck, and not cvsconnect; I guess the upstream authors plans to merge the two came to fruitation a long time ago.
<ScottK> cvs and frustration do go together
<StevenK> ScottK: Add yada to the mix ...
<ScottK> Oh dear lord.
<jmarsden|work> Review of webgui http://revu.ubuntuwire.com/details.py?package=webgui would be welcomed.  It's a GPLed Perl-based CMS, with about 10000 known installations out there.  Thanks!
<RainCT> (I've done some internal changes to details.py on REVU, tell me if you find that something broke.)
<sven777> would a MOTU be so kind as to review my package?  Thanks in advance!  http://revu.ubuntuwire.com/details.py?package=lmalinux
<RainCT> revu.ubuntuwire.com/p/<name> does now redirect to revu.ubuntuwire.com/details.py?package=<name>
<RainCT> well, good night
<jpds> night RainCT.
<Hobbsee> RainCT: cool, thanks :)
<RainCT> :)
<directhex> the conspiracy is back!
<maxb> The "Needs Work" packages on REVU seem to be ordered by date of upload, except for the 21 at the bottom of the list, which aren't. What's up with that?
<nhandler> For packages on REVU, should we be advising them to change their debian/rules file to not require debhelper >= 7 if they aren't using the new features for any particular reason?
<cody-somerville> nhandler, if they don't require debhelper 7 or higher but infact can use a lower version just fine and you know this for sure, then yea, I'd say you could suggest they change it
#ubuntu-motu 2009-02-07
<Laney> I think "V7  This is the recommended mode of operation." confuses it a bit
<nhandler> Laney: It also doesn't help that dh_make defaults to 7 iirc
<nhandler> cody-somerville: What about for a package that uses debhelper v7 features in debian/rules but doesn't need to?
<Laney> I'm not sure I see the problem any more
<Laney> hardy-backports has dh7, and backporting to anything beyond that is probably pretty rare
<cody-somerville> nhandler, You're welcome to upload and change it after it gets accepted but I wouldn't comment on it for packages in revu
<Laney>        Unless otherwise indicated, all debhelper documentation assumes that you are using the most recent
<Laney>        compatibility level, and in most cases does not indicate if the behavior is different in an earlier
<Laney>        compatibility level
<nhandler> Laney: I know. I'm still not particularly clear on the reason behind requesting users use a lower compat level, but many developers insist on this
<nhandler> One last question, does the perl artistic license require a copy to be distributed in the source?
<Laney> Don't all licenses?
<Laney> linking to it is pretty dubious IMO
<Zetto> Hi all, i really wanna update Netbeans 6.1 to 6.5, but the Feature Freeze already passed, some can tell me what i can do ? Still have another way to solve it without a backport ?
<Zetto> (update it in Ubuntu+1 )
<cody-somerville> Zetto, ugh... Feature Freeze has *not* passed.
<Zetto> ops
<cody-somerville> :)
<Zetto> yep
<Zetto> :P
<cody-somerville> So lets get Netbeans uploaded!! woot!
<Zetto> February 19th didn't passed :P
<Zetto> cody-somerville, how we can doo it ?
<ScottK> nhandler: Specifying a higher version dependency than is required is a poor packaging practice.
<ScottK> It complicates backports substantially.
<ScottK> And it's just not correct.
<cody-somerville> Zetto, you prepare an upload of the new version and then you upload it
<nhandler> scottk: Just out of curiosity, how does it complicate the backport process since debhelper has been backported?
<ScottK> Generally speaking with debhelper it's pretty clear in debiah/changelog when stuff appeared.
<ScottK> To hardy yes, but we still support dapper and gutsy.
<Zetto> cody-somerville, on the Bug report, Yulia already make packages on yours PPA
<cody-somerville> ScottK, In the case nhandler is asking about, the individual uses a new feature available in v7 but they could have done it the "old" way.
<cody-somerville> Zetto, Then I recommend you ask someone to sponsor the upload
<ScottK> In that case the dependency is fine.
<Zetto> cody-somerville, thanks
<ScottK> If they actually use dh 7 features, the dependency is correct.
<nhandler> scottk: Even though there is no reason for the package to use the debhelper v7 features?
<cody-somerville> nhandler, maybe more context would be useful
<ScottK> nhandler: Packages don't need to use debhelper at all.
<ScottK> The point of debhelper is to make life easier.
<ScottK> If the packager likes using a particular feature, then that's fine.
<nhandler> scottk: Ok. And do you know whether the perl artistic license requires a full copy to be distributed in the source?
<ScottK> I was arguing (apparently on a one sided basis) against arbitrarily selecting the current version as the required version.
<ScottK> nhandler: Ubuntu requires a full copy of the license in the source.
<ScottK> nhandler: Also Perl is GPL v1 and follow, so if something is licensed 'on the same terms as Perl' it includes GPL v1.
<nhandler> I didn't know that. Thanks scottk
<ScottK> Mithrandir rejected my very first package due to that.
<Zetto> To upload Netbeans 6.1 to 6.5 I need a sponsor to upload 4 diff files did by a Sun employee, someone can help ?
<Zetto> *to update
<ScottK> Zetto: File a bug with the diffs and subscribe ubuntu-universe-sponsors.  Who your employer is isn't really a consideration.
<Zetto> ScottK, thanks, a will subscribe
<Zetto> ScottK, like we already have the diffs, and the UUSponsors are already subscribed, what should be the status of the bug ? In Progress ?
<ScottK> Triaged or confirmed.
<ScottK> In progress is when a sponsor is looking at it.
<Zetto> ScottK, thanks, i will change all they to Triaged
<ScottK> You're welcome.
<Zetto> ScottK, Triaged isn't in the list ^^
<ScottK> Then confirmed
<Zetto> ScottK, do you know why ?
<Zetto> ScottK, ok
<ScottK> Yes, it's a restricted status.  Not everyone can set it.
<ScottK> That's why I said confirmed or triaged.
<ScottK> Triaged is an interesting theory, but the restriction on it's use makes it pretty useless for workflow bugs.
<Zetto> ScottK, can you change to Triaged or Upload the files ?
<Zetto> hummm
<ScottK> I could, but I'm busy with other things currently
<Zetto> ScottK, ok, can i ask you again in one hour ?
<ScottK> You can ask, but I find repeated requests demotivating.
<ScottK> I recommend against it.
<Zetto> ok
<Zetto> ScottK, are you busy ?
<ScottK> yes.
<Zetto> good work, i will Sleep now
<Zetto> bye all
<quadrispro> hi pochu
<savvas> would a correct conf be at /etc/udev/libmtp8.rules or /etc/udev/rules.d/45-libmtp8.rules ?
<quadrispro> could anyone review this? http://revu.ubuntuwire.com/details.py?package=gnome-format
<pochu> hi quadrispro
<pochu> I'm reviewing gnome-format
<pochu> quadrispro: so we are finally using the orig tarball, aren't we?
<quadrispro> thank you pochu
<pochu> in the get-orig-source, there's no need to untar the tarball
<pochu> it should be enough to just `bunzip && gzip -9`
<pochu> (and that's better, since the .tar checksum won't change)
<quadrispro> pochu: yes, you're right, I'm workin on it
<pochu> quadrispro: and a couple more comments
<pochu> in the manpage, remove [OPTIONS...], since there is no [OPTIONS] section
<quadrispro> ok
<pochu> and in the long description, this looks a bit weird:
<pochu> It is designed for Linux based operating systems, like Ubuntu, and for the GNOME desktop.
<pochu> I'd remove Linux and Ubuntu from there
<pochu> it's ok if you want to mention that it integrates well with GNOME though
<pochu> Linux is pointless because Ubuntu only runs on Linux, and Ubuntu is pointless because if the package is in Ubuntu, is because it runs there
<quadrispro> pochu: http://paste.ubuntu.com/115218/
<Laney> gzip -9nf, rather
<pochu> quadrispro: looks fine
<pochu> quadrispro: you can view it using `man ./gnome-format.1`
<quadrispro> I know :)
<pochu> ok :)
<quadrispro> man -l filename.1, precisely
<pochu> Laney: -f looks useless for a .tar
<Laney> yeah, n is more important
<pochu> quadrispro: did you use two spaces in the list of actions in the long description on purpose?
<pochu> s/actions/features/
<pochu> quadrispro: if so, good :)
<DktrKranz> is svn.debian.org working for you? I can't checkout branches with my ssh key :(
<quadrispro> pochu: 2 spaces?? where?
<pochu> DktrKranz: I can update my checkouts fine
<pochu> quadrispro:
<pochu>  Features:
<pochu>   - Easy to use.
<pochu>   - Autodetects available media through HAL.
<pochu> there are two spaces before the dashes
<DktrKranz> pochu, which string do you use? Probably it's a failure by my side
<pochu> svn co :)
<quadrispro> yes, there are 2 spaces, is it right?
<pochu> quadrispro: yeah, it's perfect
<pochu> quadrispro: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480322
<ubottu> Debian bug 480322 in gnome-terminal "Description could be better formatted" [Minor,Closed]
<pochu> DktrKranz: IIRC my initial checkout was like "svn co svn+ssh://svn.debian.org/svn/foo"
<pochu> DktrKranz: with this in my .ssh/config:
<pochu> Host svn.debian.org User pochu-guest
<pochu> in two lines
<pochu> Host svn.debian.org
<DktrKranz> same here
<pochu>     User pochu-guest
<pochu> DktrKranz: give me an URI and I'll try
<DktrKranz> with s/pochu/dktrkranz/, of course :)
<pochu> heh
<pochu> I hope :)
<DktrKranz> svn+ssh://svn.debian.org/svn/python-apps/packages/bleachbit
<quadrispro> pochu: uploaded to REVU
<pochu> DktrKranz: works fine
<pochu> quadrispro: ok, I'm going to upload it to the archive if your changes look fine
<DktrKranz> gah!
<DktrKranz> no way here...
<quadrispro> pochu: REVU doesn't want to work
<pochu> DktrKranz: can you checkout without ssh?
<DktrKranz> yes
<pochu> DktrKranz: there's #alioth on OFTC, btw
<DktrKranz> but no write access
<quadrispro> bah, anyway I've uploaded gnome-format to my server -> http://home.alessiotreglia.com/jaunty/result/gnome-format_0.1.1-0ubuntu1/
<pochu> DktrKranz: is your key in alioth.debian.org? :)
<DktrKranz> yes
<DktrKranz> I did some commits already, but today it doesn't work at all
<pochu> no idea then
<DktrKranz> mmmh... let's try to connect to our build server
<DktrKranz> it uses ssh as login method
<DktrKranz> mmmh... no access!
<DktrKranz> so, it's seahorse!
<pochu> DktrKranz: how long have you been without using it?
<surfaz> ScottK, any news about this?
<surfaz> https://bugs.launchpad.net/ubuntu/hardy/+source/amule/+bug/244670
<pochu> the keys were removed due to the ssh disaster ;)
<ubottu> Ubuntu bug 244670 in amule "[hardy] Request of update of aMule to 2.2.2 final release" [Undecided,Confirmed]
<DktrKranz> pochu, my key is old enought to be immune of SSH crisis ;)
<DktrKranz> enywat, latest commit is about two weeks ago
<DktrKranz> *anyway
<pochu> DktrKranz: maybe ask in #alioth
<DktrKranz> \o/ I GOT IT! seahorse crashed and no longer managed my keys!
<DktrKranz> now, let's see if commit was successful
<quadrispro> I'm experiencing issues with REVU... mmm
<pochu> quadrispro: get-orig-source fails here
<pochu> with the package from your server
<pochu> bunzip2 ../gnome-format-.tar.bz2
<pochu> bunzip2: ../gnome-format-.tar.bz2 is not a bzip2 file.
<pochu> make: *** [get-orig-source] Error 2
<DktrKranz> it works, pochu sorry for the noise, it was my seahorse which crashed
<quadrispro> pochu: type uscan --dehs
<pochu> DktrKranz: np
<pochu> emilio@saturno:~/tmp/gnome-format-0.1.1$ uscan --dehs
<pochu> <dehs>
<pochu> <errors>uscan: Can't use --verbose if you're using --dehs!</errors>
<pochu> </dehs>
<pochu> quadrispro: I'm on Debian btw
<pochu> oh
<pochu> wait
<pochu> USCAN_VERBOSE=yes
<pochu> that's on my .devscripts :)
<quadrispro> ok
<pochu> quadrispro: why do you need --dehs, btw?
<quadrispro> pochu: it's necessary to retrieve the last available version from upstream
<pochu> ok
<maxb> --dehs just changes the output format, I thought?
<pochu> maxb: yes, but then it's easier to parse it I guess
<pochu> quadrispro: ok, works now without --verbose
<quadrispro> yeah
<maxb> Is get-orig-source really allowed to cd ?
<pochu> quadrispro: if you run get-orig-source, do you get this md5sum?
<pochu> f6cf5689480fc9cbe6da344175083b08  gnome-format_0.1.1.orig.tar.gz
<pochu> maxb: why not?
<quadrispro> pochu: one moment
<quadrispro> pochu: yes
<pochu> ok, I'm uploading with that tarball then
<quadrispro> alessio@quadrispro-desktop:~/Desktop/devel/REVU/gnome-format$ md5sum gnome-format_0.1.1.orig.tar.gz
<quadrispro> f6cf5689480fc9cbe6da344175083b08  gnome-format_0.1.1.orig.tar.gz
<quadrispro> pochu: thank you very much :)
<pochu> quadrispro: thanks for packaging it :)
<POX> DktrKranz: FYI: sed accepts multiple "-e"'s
<quadrispro> pochu: do you have some minutes for this? https://bugs.launchpad.net/bugs/325882
<ubottu> Ubuntu bug 325882 in installation-report-generator "Please update installation-report-generator to 0.2.1" [Undecided,Confirmed]
<pochu> quadrispro: Successfully uploaded packages.
<pochu> quadrispro: uploaded ;)
<DktrKranz> POX, yes, I used multiple instances just for "cosmetic" purposes
<POX> ok then
<quadrispro> thank you pochu
<pochu> RainCT: hey, there seems to be some problems with REVU
<pochu> RainCT: quadrispro can't upload his package, and I can't login...
<pochu> RainCT: El servidor Â«revu.ubuntuwire.comÂ» estÃ¡ redireccionando de una manera que nunca terminarÃ¡.
<pochu> RainCT: I can access REVU, but when trying to login and clicking on "sign in" in Launchpad, I get that
<quadrispro> pochu: ehm.. did you upload installation-report-generator too?
<DktrKranz> POX, new upstream is available, but older one is still in NEW. Is it worth waiting for the older to be accepted right now?
<pochu> quadrispro: nope
<quadrispro> ah ok ok :)
<POX> DktrKranz: well, I'd recommed to wait with an upload and ping me right after old one will be accepted
<DktrKranz> I'll do that, thanks :)
<pochu> DktrKranz: otherwise your package will fall to the bottom of the queue again ;)
 * pochu is already 5th
<pochu> pity that they don't process it top-bottom ;)
<DktrKranz> > 200 packages \o/
 * DktrKranz can't wait for valentine's day!
<pochu> :)
<pochu> quadrispro: let me know when REVU works again and I'll add a comment and archive the package ;)
<Laney> What version number is best to use for something that doesn't (hasn't yet) do releases? 0.darcsDDMMYYYY?
<pochu> Laney: 0~foo, I'd say
<Laney> Also is it required that source files include license headers and copyright information, or is having this in the top-level file enough?
<Laney> LICENSE file, that is
<pochu> Laney: otherwise, if the first public release is 0.X you will be in trouble ;)
<pochu> true
<pochu> dpkg --compare-versions "0.darcs" gt "0.0.1" && echo true
<pochu> Laney: I think LICENSE is fine, but header in source files is encouraged
<Laney> fair, I got the idea from ffmpeg-debian
<pochu> not sure if you will get a reject for that
<pochu> Laney: they probably use 0.svn before ~ was created
<Laney> I'm never going to convince upstream to go back and add headers to all of their files
<Laney> so hmm
<pochu> hmm, they don't :)
<pochu> ffmpeg (0.cvs20040716-1) unstable; urgency=low
<pochu>   * Initial release (Closes: #199266).
<pochu>  -- Sam Hocevar (Debian packages) <sam+deb@zoy.org>  Fri, 16 Jul 2004 12:47:27 +0200
<pochu> but dpkg supports ~ since 2003
<pochu> anyway, ~ is better, otherwise you're screwed
<Laney> sure
<pochu> Laney: what package is it, btw?
<Laney> agda
<Laney> http://wiki.portal.chalmers.se/agda/agda.php?n=Main.HomePage
<pochu> Agda is a dependently typed functional programming language.
<pochu> that one?
<Laney> correct
<tobor> Hello. I just installed Hardy (kubuntu flavor) and I am looking at using the gdata-python library to write some software to access google calendars.  The hardy repo's are supplying version 1.0.9-1ubuntu1 of the gdata-python library but the current version is 1.2.4. The latter version includes examples but I don't know what other changes are included.   version 1.0.9 was completed in OCT of 2007. The current version was just done in Jan 22 2008.  Is 
<ScottK> surfaz: I have no idea.  I'm not in motu-sru, so it's totally  not up to me.
<tobor> Regarding the issue of updating packages to more current versions, is there a process I can read about somewhere?
<surfaz> opps, sorry. I ask you because I saw your post in that bug
 * tobor taps side of th keyboard "hello? Is this thing on? ... " 
<savvas> hm... weird, bug #145572 says unmet dependencies for amd64, but I tried 1.4-12build1 and it builds fine on amd64: https://launchpad.net/~medigeek/+archive/ppa/+build/860601
<ubottu> Launchpad bug 145572 in imaze "[UNMETDEPS] imaze has unmet dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/145572
<ScottK> surfaz: I was involved in getting the initial updates in, but for the previous releases, no idea.
<misblay> hi!
<misblay> i'd like to contribute motu as much as i can, but im not sure if i could :) do i need any programming skills etc.?
<ScottK> Knowing shell scripting (at least a little) is good.
<ScottK> If you have programming skills they can be helpful, but they are not required.
<misblay> i have stuided PHP for couple of months
<misblay> but i dont think
<misblay> that will help :D
<misblay> thanks anyway, i'll check the documentation
<skorasaurus> !gettingstarted
<ubottu> A great place to start your MOTU adventure is https://wiki.ubuntu.com/MOTU/GettingStarted
<skorasaurus> ScottK, that getting started doc is being revised.
<skorasaurus> too
<hefe_bia> Hm... I get a "dh_clideps: Warning! No Build-Depends(-Indep) on cli-common-dev (>= 0.4.4)!" while having "Build-Depends-Indep: ... cli-common-dev (>= 0.6),..." in control. Any ideas? Does it have to be the exact version?
<hefe_bia> dpaleino pointed me to http://wiki.debian.org/Proposals/CopyrightFormat on REVU. Should this really be used? There seems to be still a lot of discussion on this proposal.
<RainCT> pochu: Hey. With which pages do you have that error?
<pochu> RainCT: with http://revu.ubuntuwire.com/details?package=gnome-format
<pochu> it still happens
<pochu> RainCT: the url redirected from Launchpad is this:
<pochu> http://revu.ubuntuwire.com/launchpad_login?janrain_nonce=2009-02-07T16%252525252525252525252525252525252525253A23%252525252525252525252525252525252525253A44Zxnl9jD&openid.assoc_handle=%252525252525252525252525252525252525257BHMAC-SHA1%252525252525252525252525252525252525257D%252525252525252525252525252525252525257B4980d3c6%252525252525252525252525252525252525257D%252525252525252525252525252525252525257B4uA4%252525252525252525252525252525252525252Bg
<pochu> sorry! :(
<RainCT> pochu: ah, but only login fails?
<pochu> RainCT: yeah
<pochu> I can view the page fine
<RainCT> err right, now I know why I had some mod_rewrite lines commented out :P
<pochu> heh
<RainCT>  
<RainCT> Fixed
<pochu> RainCT: ty
<RainCT> err. or not
<RainCT> pochu: well, commented that out again :P. Should work now
<pochu> RainCT: right, worked now, thanks!
<sven777> would a MOTU be so kind as to review my package?  Thanks in advance!  http://revu.ubuntuwire.com/details.py?package=lmalinux
<hefe_bia> sven777: I'm not a MOTU, but I just noticed: changelog should just contain one entry with "Initial release...". Changes made during the REVU process should not be reflected in the changelog.
<sven777> hefe - oh ok thanks v. much - I shall change that right now :)
<sven777> even if there is a new upstream release?
<hefe_bia> sven777: AFAIK yes. I had a similar case with one of my packages.
<sven777> hefe_bia: ok thanks again - you wouldn't happen to know of any other "gotchas" like that would you?
<hefe_bia> sven777: Might also be better to remove the debian/ dir from the .orig,tar.gz, so you keep packaging separate.
<hefe_bia> Because now your .diff.gz is empty.
<hefe_bia> For example the debian/ dir would be different if the package was adopted for Debian.
<savvas> hrm.. what happened with firefox 3.0.6?
<sven777> hefe_bia: is that a problem though?
<sven777> it's just going to result in a diff.gz anyway
<stdin> sven777: you should avoid modifying the orig.tar.gz at all, that's why we have the .diff
<hefe_bia> stdin: He's also upstream
<sven777> ya :)
<stdin> and what if debian want it?
<stdin> just keep the orig.tar.gz for the raw package
<sven777> wouldn't they just change some things in the debian dir and that results in a diff anyway?
<stdin> no, they's need to modify the orig.tar.gz
<pochu> sven777: the debian/ should be in a diff.gz
<sven777> ok, I shall remove it
<pochu> stdin: not really, but it's still weird
<sven777> it's obviously a point of contention, whatever the case - so I'll stick to something more normal
<sven777> thx for the help
<stdin> sven777: you don't need to put your name in the changelog if you're the only one changing anything
 * RainCT upgrades lintian on revu
<stdin> ie: "[ Sven Carlberg ]" is not needed
<sven777> stdin - I just noticed some other changelogs and thought it was a more "proper" format
<hefe_bia> It's not mandatory, since there are also "native packages", but it is a cleaner approach to separate packaging and the source itself. Not sure about the versioning scheme for Ubuntu native packages also...
<RainCT> sven777:   [ .. ]  is only for when several people do something to that revision
<stdin> sven777: it's used when more than one person commits changes, to attribute credit
<sven777> ok got it, thx
<stdin> do you really need debhelper (>= 7) ?
<sven777> I was just following a template
<stdin> also, you have a debian/dirs, but don't call dh_installdirs
<stdin> or dh_installmenu
<sven777> dh_installdirs is called in the install rule
<stdin> ah, yes it is
<sven777> dh_installmenu - didn't know about that one - it didn't show up when I ran dh_make
<sven777> should that be in build rule or install?
<sven777> I'm guessing install since it sounds like it installs the menu items
<stdin> probably under binary-arch, with the bulk of the dh_ rules
<mok0> There are 7 packages I have advocated on REVU, any MOTUs looking for low-hanging fruit with a dream of hitting Ubuntu HOF here's your chance!!
<RainCT> mok0: Hey. Next time you merge your branch with trunk note that you'll have to update the .htaccess file.
<mok0> RainCT: OK
<stdin> sven777: shouldn't "$(CURDIR)/src/85-logitech_music_anywhere.rules" be "$(CURDIR)/extras/85-logitech_music_anywhere.rules"
<stdin> sven777: and it that file useful without the package installed?
<mok0> RainCT: what was up with REVU about an hour ago it was all screwed up
<sven777> stdin: no, the rules gets rewritten into the src dir
<RainCT> mok0: "all" or just the login?
<sven777> stdin: no it's not, and it gets removed upon uninstallation
<mok0> I couldn't log in, but I had a browser where I was logged in first, and it wouldn't let me post a comment
<mok0> Now it works fine
<stdin> sven777: doesn't the Makefile install that? (or should it?)
<sven777> it does but it wasn't being picked up by pbuilder
<sven777> rather, it was causing a problem because it required root permission
<RainCT> mok0: I got ride of the ".py" extensions but OpenID could not handle that. About posting a comment, idk, it worked when I tried it.
<stdin> so it wasn't being installed in $(DESTDIR)
<sven777> stdin: yes you're right - I just put the /etc in there because it doesn't so any good to install it anywhere else
<sven777> so=do
<sven777> should I do a dput --force to the same package?
<mok0> RainCT: It works now
<mok0> sven777: yes, or delete the .upload file
<sven777> mok0: last time I did a dput it registered in about a minute - it's taking much longer this time - still not seeing update - is that normal?
<mok0> sven777: It depends on what time you upload, I think it runs every ten minutes
<sven777> ahh ok thx
<mok0> sven777: lmalinux?
<sven777> yup
<mok0> Did you see the comments I submitted ~20 minutes ago?
<sven777> oop - no I didn't :)
<sven777> reading now
<hefe_bia> mok0: I am also waiting for an upload to appear which I did about half an hour ago...
<mok0> hefe_bia: what upload is that?
<RainCT> mok0: new uploads are processed every  3 minutes iirc
<mok0> RainCT: aha!
<hefe_bia> mok0: tomboy-blogposter
<RainCT> uhm.. uploads/ is clean
<hefe_bia> But I just did a new one anyways since I read in your comment to sven777 that it is indeed preferred to use the new copyright format
<jpds> RainCT: Not quite.
<mok0> hefe_bia: there's a new upload just now
<RainCT> jpds: 10 seconds ago it was ;)
<mok0> spooky's clock is ahead of time ~3 minutes
<jpds> RainCT: apt-get install ntpd pls.
<surfaz> mok0, http://revu.ubuntuwire.com/p/audacious-skins
 * hefe_bia notices the URL format for REVU packages has changed - nice ;)
<RainCT> :)
<sven777> still no update for the first upload I did about 10 mins ago - just did another a couple mins ago
<RainCT> oh I see.. some scripts are br0ken
<sven777> would it be better to remove the upload file and try again instead of doing --force ?
<RainCT> jpds: doesn't exist
<mok0> sven777: it amounts to the same thing
<RainCT> jpds: aptitude suggests  cyrus-nntpd-2.2 cyrus22-nntpd cyrus21-nntpd ntpdate openntpd
<jpds> RainCT: Just ntp then.
<RainCT> jpds: OK, done
<RainCT> Uhm.. How can I change the python path for all files in a directory?
<hefe_bia> If memory serves me well in __init__.py
<mok0> RainCT: python path... explain a bit more
<mok0> the scripts need to search somewhere special for modules?
<mok0> surfaz: well, if you have all the urls of where to get the various tarballs, it should be possible to make the watch file
<hefe_bia> Ah no, __init__.py is only for modules. So if the files are just a collection of scripts that won't work
<sven777> RainCT: did I read you correctly earlier?  do you have a real-time view of the revu uploads directory?
<RainCT> sven777: Yes. Wait a moment until uploading again, I've just seen some scripts are broken - sorry
<mok0> RainCT:  sys.path.insert(1, '/whererever/it/is')
<surfaz> mok0, all?? :(
<RainCT> mok0: but then I have to touch all files
<mok0> surfaz: if you have them, yes
<sven777> rainct: oh ok didn't realize your comment about broken scripts was about revu.  thx :)
<mok0> RainCT: you can also set the PYTHONPATH
<RainCT> mok0: Is it possible to set it only for a certain dir?
<mok0> you mean something like a .htaccess file?
<RainCT> mok0: yes, but for those scripts which aren't run through mod_python
<surfaz> mok0, I don't have all
<mok0> surfaz: ok n/m then
<surfaz> mok0, original xmms-skins package hasnât a watch file.
<hefe_bia> RainCT: How are they run? Maybe you can set the environment variable via apache?
<mok0> RainCT: write a shell script that inserts something like this in each of the files:
<mok0> import sys
<mok0> pydir = "/usr/directory/foo"
<mok0> if not pydir in sys.path:
<mok0>     sys.path.insert(1,pydir)
<mok0> RainCT: which files are they? I can do some of them
<mok0> RainCT: even better, write the above in a module and import it
<RainCT> nvm, done. I've added   sys.path.append('../includes')   to all relevant files
<mok0> RainCT: It's the prettiest way IMO
<hefe_bia> RainCT: .pth files can also be used for such things.
<RainCT> some of the files in scripts/ need other files which I moved into includes/.. and this didn't fail before because there were still some .pyc files lying around in scripts/
<mok0> hefe_bia: yes!
<mok0> RainCT: ah, yes a classic
<RainCT> sven777: please try uploading it again now
<sven777> done
<mok0> RainCT: ... and you wonder wft your changes aren't taking effect :-)
<RainCT> hehe
<sven777> mod_python error on lmalinux package page now
<sven777>   File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch
<sven777>     default=default_handler, arg=req, silent=hlist.silent
<mok0> RainCT: it can't find the config file
<RainCT> right, some files were missing  "import sys"..
 * RainCT hides :$
 * mok0 admires RainCT for his bravery
<RainCT> err no, but that's just 1 file
<mok0> surfaz: but plz document everything in copyright
<mok0> surfaz: we need to know where the tarballs come from
 * RainCT doesn't understand anything now XD
<surfaz> RainCT, revu crashed!!
<mok0> RainCT: shut down revu's apache
<surfaz> RainCT, http://pastebin.com/m5c3b8d1e
<RainCT> mok0: why?
<mok0> surfaz: yeah, we know
<mok0> RainCT: oh, just so people don't get this python errors... until its fixed
<RainCT> but I need it to debug :P
<mok0> ah... yes ;-)
<surfaz> mok0, I moved all *.README files to Credits folder.
<RainCT> on localhost everything works, that's the weirdest of all
<mok0> surfaz: ok, I'll take a look later
<hefe_bia> mok0: Btw, I like your proposal for an updated REVU workflow. One of the most frustrating things with the current workflow is getting a "needs work" on a previously advocated package.
<RainCT> meh.. it's the "wth am I?" detection that is failing again.. why can't there be a decent way to find out the location of the file being run? -.-
<RainCT> (REVU is up again)
<sven777> rainct: I uploaded
<sven777> rainct: crash again
<sven777> ImportError: No module named config
<sven777> File "/srv/revu-production/details.py", line 36, in <module>
<sven777>     from config import config, connection
<mok0> hefe_bia: the new workflow should solve that problem
<RainCT> grr
<RainCT> adding '../includes' doesn't work as it is relative to the current working directory
<hefe_bia> RainCT: revu pages work again now. Not sure whether it does collect new uploads.
<mrooney> anyone know a package that uses dh_installman? I have a cdbs package and I am trying to figure out how to install my manpage
<RainCT> sven777:  your upload is up now
<RainCT> I've added some symlinks so that the scripts work until I can figure out a proper solution
<sven777> rainct: thx much
<hefe_bia> RainCT: Maybe sys.path.append(path.join(path.dirname(__FILE__), '../includes')) ?
<RainCT> uhm yes, that should work
 * RainCT tries
<hefe_bia> I think its __file__, not __FILE__ (sorry)
 * RainCT thinks __FILE__ is right :P
<hefe_bia> ok ;)
<surfaz> Somebody could look this?
<surfaz> https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/305280/comments/10
<ubottu> Ubuntu bug 305280 in gparted "[need-update] Gparted to latest stable 0.4.2 in Ubuntu Jaunty" [Wishlist,In progress]
<sven777> "This package could not be extracted; there's no browseable directory for it on REVU. "
<sven777> there it goes
<RainCT> sven777: how long did it take to uncompress the tarball?
<sven777> it gave me an error on the package page at first - I refreshed a couple mins later and it had done it
<sven777> the "legal" link on the revu page - those are all the licensing issues that need to be fixed?
<surfaz> I think they should upgrade the GParted to version 0.4.2 because this version incorporate support for ext4. Which brings Ubuntu 9.04. I think this error should not qualify as Wishlist
<RainCT> sven777: That just tries to find out the license of all files. But yeas, in thise case what it lists should be fixed if you can
<RainCT> (ie, changing the FSF address to the new one and adding copyright to the files where it is missing)
<sven777> gettext.h is not my file and it is LGPL - is there something I should do about that?
<RainCT> hefe_bia: but of course that doesn't work, as __FILE__ is not defined for imported files
<RainCT> sven777: that one is fine
<sven777> rainct: ok thx
<sven777> 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA is the correct address?
<RainCT> sven777: I think so. Check /usr/share/licenses/GPL to be sure
<RainCT> * common-licenses
<nhandler> That looks correct
<nhandler> I remember it because the first letters of Franklin Street, Fifth spell FSF (unlike the old address)
<sven777> ok thx
<sven777> getting that "Warning! This package could not be extracted; there's no browseable directory for it on REVU. " again
<sven777> went away right away that time
<RainCT> perhaps I should change the script to uncompress the directory first and then show it on the page?
<sven777> the legal link - that just lists the legal info for all relevant files?  it doesn't necessarily mean they're incorrect in some way?
<RainCT> sven777: right
<sven777> ok thanks
<RainCT> hefe_bia: err. it is __file__ indeed :P
<sven777> ok all those changes everyone ( mok0 hefe_bia stdin rainct pochu ) helped me with are applied - thanks much for all your help!
<mrooney> is there another way I should installed manpages with cdbs other than dh_installman?
<RainCT> mrooney: debian/<package>.manpages
<mrooney> RainCT: does that just automagically install them?
<mrooney> I've seen that before but wasn't sure how it worked
<RainCT> mrooney: yep
<mrooney> RainCT: excellent, thanks!
<RainCT> mrooney: CDBS calls dh_installman, and dh_installman looks for debian/*.manpages files to install whatever is listed there
<RainCT> yw
<RainCT> Does anyone have something to upload? I want to try removing the symlinks
<surfaz> something to upload? where?
<RainCT> to revu
<RainCT> let me reformulate, *If someone is about to upload something to REVU, please tell me before so that I can check something.
<hyperair> RainCT: what symlinks
<RainCT> hyperair: a workaround I did before figuring out why something was failing :)
<hyperair> hm
<hefe_bia> RainCT: yes, my package for tomboy-blogposter still did not get recognized
<hefe_bia> Should I upload again?
<RainCT> hefe_bia: no, I think I can recover it
<RainCT> hefe_bia: Still needs the symlink :/. Anyway, your upload is up now
<hefe_bia> RainCT: Thanks. Just got the mail notification
<RainCT> Uhm.. The activity graphic (that's new! :)) for tomboy-blogposter is nice :)
<henrik-hw0> rainct: the vertical lines are those for decoration? could be nice to put them at release or featurefreeze dates.
<RainCT> henrik-hw0: they are automatically placed there were there's a month written
<RainCT> FF could be added, but it would only be visible once it has already started (as only the active period of time is displayed in the chart)
<RainCT> (advocations are also displayed now)
<henrik-hw0> rainct: ps. it renders wrong on package libmirage.
<surfaz> Somebody could look this?
<surfaz> https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/305280/comments/10
<surfaz> I think they should upgrade the GParted to version 0.4.2 because this version incorporate support for ext4. Which brings Ubuntu 9.04. I think this error should not qualify as Wishlist
<ubottu> Ubuntu bug 305280 in gparted "[need-update] Gparted to latest stable 0.4.2 in Ubuntu Jaunty" [Wishlist,In progress]
<loic-m> surfaz: if your diff.gz is good, you just need to put the Status to confirmed and unassign yourself (leave it empty) and a developer from u-s-m should pick it up and upload it (takes a few days to 2 weeks afaik)
<surfaz> ok, thanks
<loic-m> surfaz: check the Assigned to field, and if no developer has noticed it in one week, try remind people again. However since it's gparted it should be taken care off easily (since it's important)
<surfaz> No is there less than a week to freeze new versions?
<loic-m> !schedule
<ubottu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
<loic-m> https://wiki.ubuntu.com/JauntyReleaseSchedule thankfully there's firefox Aaawesoome bar
<loic-m> February 19th for FF, so still 12 days to go
<loic-m> hope I put enough a in Aaawesoome, I can never remember how they spell it
<surfaz> loic-m, thanks, but I don't know why we wait to the last minute...
<loic-m> surfaz: we don't wait to the last minute, it's just that there's a lot of updates to process each day, so it can take time
<loic-m> (as far as I understand)
<surfaz> Not enough MOTUs?
<loic-m> surfaz: gparted is in main, so MOTU don't have the upload rights for it anyway
<surfaz> ahh, ok
<savvas> loic-m: do you happen to know what's stalling 3.0.6? I heard about some vulnerabilities fixed that affect 3.0.5 and older versions
<loic-m> savvas: I can't even start to figure what you're talking about ;)
<savvas> woops, I meant firefox :P
<loic-m> I'm not a motu, and firefox is in main. Somebody here might now the answer, but else you should ask in #ubuntu+1
<loic-m> I must say Jaunty's Firefox is 3.0.6 though
<savvas> I know: https://launchpad.net/ubuntu/+source/firefox-3.0
<savvas> I guess it's going to arrive sooner or later
<sven777> would a MOTU be so kind as to review my package? Thanks in advance! http://revu.ubuntuwire.com/details.py?package=lmalinux
<RainCT> From Time Based Releases:  Â«Present: new features should, in general, be uploaded to the development branch well in advance of FeatureFreeze. It is important for Ubuntu features to be developed openly and visibly.Â»
<RainCT> *cough*like that junk cleaner thing*cough*
<Laney> har har
<ScottK> RainCT: I gave that one an FFe and I figure not to do that one again.
 * calc is bored in his hotel room, beating on OOo split build
<calc> apparently i'm the last person leaving, heh
<kolby> In a control file, how do I indicate the program will work for any archetecture?
<kolby> I tried Architecture: any
<RainCT> kolby: Architecture: all
<kolby> thanks
<RainCT> kolby: "any" builds the package for all architectures
<RainCT> kolby: "all" builds it once and uses the same .deb for all
<kolby> RainCT: thank you.
<kolby> RainCT: When should I use "any"
<kolby> I have the uninitialized $binaries being used in debconf file of lintian.
<kolby> I wouldn't think that's my failt.
<kolby> *fault
<kolby> I got this error: binary-arch-rules-but-pkg-is-arch-indep
<kolby> what should I do?
<RainCT> kolby: are you packaging something written in python/ruby/perl/bash/etc. or something that must be compiled
<kolby> something that must be compiled
<RainCT> kolby: ah, then "any" was right
<kolby> I'll use that and see what happens.  thanks
<RainCT> that warning will go away then
<kolby> what do I do if debuild tells me it cannot find my secret key?
<RainCT> kolby: do you have a GPG key?
<kolby> it attempts to sign my changes, then it tells me it can't find the secret key.
<kolby> Yes.  I gave it my GPG key with the -k command
<kolby> it worked that time for some reason.
<RainCT> kolby: Ensure that the string in debian/changelog (after " --") matches that one of your secret key, then you won't need to specify it with -k
<kolby> okay
<kolby> how do I know which key it is, if it perfectly matches the names and email of two keys?
<kolby> is there a gpg config file to edit or something?
 * RainCT doesn't know, sorry
<kolby> I think I found it
<Laney> put DEBSIGN_KEYID in ~/.devscripts
<kolby> Laney: okay
<kolby> Laney: that file didn't exist before
<_16aR_> Hello
<RainCT> Hi _16aR_
<kolby> I found a guide
<kolby> it told me to add "export GPGKEY=YOUR-KEY-ID" to ~/.bashrc
<_16aR_> The package fsniper needs 1 more advocate :) : http://revu.ubuntuwire.com/details.py?package=fsniper (daemon which launch a script on each file newly created or modified in a directory )
<kolby> Laney: when I ran debuild, it gave me the following error/warning:
<kolby> /home/et3/.devscripts: line 1: DEBSIGN_KEYID: command not found
<kolby> Laney: I'll be deleting it now
<Laney> laney@chicken:~$ cat /home/laney/.devscripts
<Laney> DEBSIGN_KEYID="20BFCDC7"
<hanska> kolby: be sure not to have spaces
<hanska> i.e. DEBSIGN_KEYID = "foo" throws that error
<hanska> while it *must* be DEBSIGN_KEYD="foo"
<kolby> hanska: thank you
 * kolby fixed devscript
<kolby> I'm still getting the same error
<hanska> kolby: grep DEBSIGN_KEYD ~/.devscripts  ?
<kolby> if lintian returns nothing, does this mean no errors/warnings?
<directhex> no news is good news
<kolby> amazing.  I'm done.
<kolby> ^^  I was working on the md4sum package
<directhex> md4sum? o_o
 * Laney wonders how broken that is
 * directhex hands Laney a 300mhz ARM
 * Laney collides with directhex 
<kolby> thank you all.
<kolby> what does this mean:
<kolby> No host tea found in config
#ubuntu-motu 2009-02-08
<sirderigo_> good night, i want to know if here is somebody what can help me to create a DEB to FGRUN; install this is a very high level hell
<savvas> uscan warning: In watchfile debian/watch, reading webpage http://qa.debian.org/watch/sf.php/pywebsvcs/ failed: 403 Forbidden
<savvas> does anyone know what's going on?
<Hobbsee> savvas: well, it 403's in a browser too
<savvas> darn
<directhex> works here
<Hobbsee> http://garr.dl.sourceforge.net/sourceforge/pywebsvcs/ is what it redirects to, for me
<directhex> only works for sexy britlanders?
<savvas> same as Hobbsee here
<directhex> Index of /sourceforge/pywebsvcs
<directhex> [   ] ZSI-2.1_a1-py2.5.egg     01-Nov-2007 23:32  432K
<savvas> directhex: you're in UK?
<directhex> savvas, i think it redirects to a random SF mirror, and some are broken
<directhex> heanet is fine
<directhex> garr is not
<savvas> ok got it, seems random like you said
<savvas> thanks :)
<DktrKranz> iulian, ScottK: I've prepared a first draft of motu-release charter (https://wiki.ubuntu.com/MOTU/MOTUReleaseCharter), could you please have a look? I'll ping sistpoty too when he is online
<RainCT> DktrKranz: "has not discussed"
<RainCT> DktrKranz: last line "by MOTU community" -> "by the MOTU community"
<DktrKranz> RainCT, typos corrected :)
<Hobbsee> DktrKranz: s/weight/weigh/
<DktrKranz> Hobbsee, got it, thanks :)
 * RainCT reviews fsniper
 * DktrKranz has flu... sorry for the typos
<Hobbsee> ;)
<quadrispro> DktrKranz: could you take a look at http://revu.ubuntuwire.com/details.py?package=mandvd?
<quadrispro> http://revu.ubuntuwire.com/details.py?package=mandvd *
<DktrKranz> quadrispro, I guess not, I just take some chemical stuff and I plan to sleep soon :)
<quadrispro> ok DktrKranz, thank you :)
<iulian> DktrKranz: OK, thanks.  I'll have a look at it in a minute.
<iulian> Looks good.
<quadrispro> ehi guys! mandvd needs some love -> http://revu.ubuntuwire.com/details.py?package=mandvd  :)
<quadrispro> hi mok0
<RainCT> uhm.. what do you think about adding  -I  to lintian on REVU?
<hefe_bia> I uploaded a new version of the tomboy-blogposter package after an extensive review from dpaleino. I think the mono packaging should be much better now. (See http://revu.ubuntuwire.com/p/tomboy-blogposter) Also I changed it to the new copyright format. I'd be very happy about a review ;)
<jpds> RainCT: +1.
<brennion> I've uploaded a nvclock package which solves some issues about nvidia8/9 cards, but I've seen there are some packaging mistakes, how can I uploaded a second time ?
<brennion> do I need to increase the version number, even if it is not published ? ubuntu1 to ubuntu2 ?
<Laney> brennion: No, just upload a new debdiff to the bug
<jpds> brennion: Sure, and no.
<Laney> or .diff.gz, whatever it is
<Laney> preferably with a comment saying what's different
 * Laney jumps on hanksa
<brennion> ok thank you, I'm going to search for debdiff tuto..., do I've chances to have it included in jaunty, or it's already too late ?
<Laney> not at all
<Laney> there's still time
<maxb> Regarding mandvd, I wonder if it would be worth trying to talk upstream into some better versioning and changelog practices
<pochu> RainCT: sounds good. I'd also add --show-overrides if it's not already there
<RainCT> pochu: but REVU will then complain about lintian not being happy
<maxb> The primary release format seems to be a SRPM, and the author seems to be abusing the VERSION-RELEASE numbering format by using RELEASE for non-packaging changes too
<RainCT> and if there's a debian/*overrides file the reviewer should look at it anyway
<brennion> last question for now ;p, do I have to upload twice, for jaunty and intrepid ? I could not find infos on the packaging howto
<pochu> RainCT: well it will only show them... some people tend to abuse overrides
<pochu> RainCT: but that's fine too
<pochu> RainCT: what about --pedantic? :P
 * pochu hides
<Laney> brennion: For Intrepid you will have to follow the SRU procedure
<Laney> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<brennion> thx
<RainCT> OK, -I added
 * hefe_bia has to head for work. see you later...
<jfcgauss_> i inserted a scratched cd into my cd/dvd drive, and im unable to eject the cd. eject button of the drive doesnt work, nor does the 'eject volume' from the icon on my desktop. i also cannot kill the file browser instance that popped up when i inserted the cd. the only way is to restart the computer. is there a better way to get the cd out and kill the file browser instance without restarting? is HALD responsile for this? thx...
<kolby> I want to be added to revu uploaders
<maxb> kolby: https://launchpad.net/~revu-uploaders reports that the team is no longer necessary.
<kolby> maxb: thank you
<henrik-hw0> Anyone feel like giving libmirage a second advocate?
<RainCT> kolby: Just log into REVU, and account for you will be automatically created.
<kolby> RainCT: alright.  I knew I uploaded to revu, but it didn't show up under the new packages and now I know why.
<RainCT> kolby: Uhm. I don't see any upload here..
<kolby> RainCT: I'll try soon and let you know then.
<kolby> in my /etc/dput.cf file, I have "anonymous" for the revu login name, should I change this?
<kolby> Should I use my launchpad ID for <login = (anonymous)>
<RainCT> kolby: no, it is correct
<kolby> alright.  Thx
<RainCT> kolby:  Just upload, it should work now that REVU knows you :)
<kolby> okay ^^
<kolby> The package has been uploaded
<kolby> I was told to join the uploader group in launchpad by an official looking ubuntu guide
<kolby> Here is the link:
<kolby> https://wiki.kubuntu.org/MOTU/Packages/REVU
<hefe_bia> re
<Laney> kolby: whereabouts does it say that?
 * RainCT wonders if anyone uses revu-tools
<kolby> Laney: I missread the "Register as a REVU uploader" section
 * Laney has never heard of revu-tools
<Laney> RainCT: Can REVU run that on new uploads?
<kolby> when do I change the [needs-packaging] bug report to indicate packaging completion?
<RainCT> Laney: nope, that'd most likely kill the server (it downloads the orig tarball with uscan and also builds the package with pbuilder - I think everything else it checks for is already done by REvu)
<Laney> heh
<Laney> well apart from the building part then
<Laney> it can run uscan --report to not download, etc
<RainCT> uscan can also be run by the reviewer :)
<RainCT> the problem about adding it to REVU is that there may be a new release since the package was uploaded
<kolby> Alright.  _my_ lintian detected no errors or warnings in my package.
<kolby> Once I uploaded it, there was a lintian error notice about having no "debian/watch" file.
<Laney> Well things that can be termined statically (uscan can take a version number btw) should be
<Laney> no point in wasting reviewers' time with stuff that can be automated
<pochu> kolby: lintian -I
<kolby> RainCT: a person I know that is helping me with packaging has aliases set for the uploading process he goes through.  I copied this method.
<kolby> pochu: thank you
<RainCT> kolby: the "debian/watch" error is not from lintian, but from REVU
<kolby> RainCT: I didn't phrase it correctly.  I meant REVU's lintian.
<__Ali__> anyone knows what happened to the fix for skype for 8.10?
<Laney> what fix for skype?
<__Ali__> a few days ago someone here was celebrating the skype fix, but he left soon
<RainCT> Ah, didn't know that lintian checks for it :)
<pochu> skype isn't in the repos, is it?
<__Ali__> Laney, it is known that the pulse audio driver doesn work with skype
<kolby> after I add the debian/watch file, I upload using the exact same process right?
<Laney> no idea
<RainCT> Laney: < RainCT> the problem about adding it to REVU is that there may be a new release since the package was uploaded
<RainCT> kolby: remove the README.Debian if you don't have anything important to write there
<Laney> you can pass --download-version to uscan!
<kolby> RainCT: I'll look at it.
<RainCT> Laney: Ah. But then we don't know if there's a new upstream version, so the reviewers must run it anyway
<Laney> rofl
<Laney> well it depends what you want to achieve
<brennion> Laney: I've made a debdiff, how should I upload it to revu, so that it is linked with my first upload ?
<Laney> brennion: Hmm? Is this the nvidia thing?
<_16aR_> I got an upstram package written in iso-8859-15, do I must provide a patch system with iconv before compiling ? (only comments and french manpage got accent like Ã©)
<RainCT> brennion: upload it just like you do the first time
<brennion> yes
<Laney> brennion: This package already exists so you should be uploading to launchpad, not revu
<brennion> ? but the version 0.8b4 isn't packaged
<Laney> then you should upload the .diff.gz to launchpad
<Laney> revu is only for new packages
<kolby> what does a watch file look like?
<RainCT> kolby: man uscan
<brennion> ok, revu is only for brand new packages, but where do I make it in lauchpad, do I need to follow the sponsorship process, or is there another way ?
<RainCT> brennion: Yes, just file a bug, attach the .diff.gz and subscribe ubuntu-*-sponsors
<kolby> how do I check if I wrote the watch file correctly?  is the a lintian option for this?  Do I use uscan itself to check?
<brennion> but if the package available is another version, then a diff is not enough ?
<RainCT> (note that REVU can also be used for updates, but this is currently not the recommended workflow and updates should only be uploaded there if a MOTU asks you to do it)
<RainCT> kolby: run  uscan --verb
<RainCT> (--verb = --verbose)
<kolby> alright
<brennion>  <RainCT> (note that REVU can also be used for updates, but this is currently not the recommended workflow and updates should only be uploaded there if a MOTU asks you to do it)
<RainCT> brennion: No, as the debdiff will show *all* differences between both versions, including the changes which upstream did between both versions
<_16aR_> Anyone know when is the next package freeze ? (for jaunty, so)
<jpds> _16aR_: 29th, I believe.
<RainCT> brennion: and a diff of debian/ would not work as something stuff outside debian/ is also touched
<RainCT> hey jpds :)
<jpds> Hey RainCT.
<ScottK> DktrKranz: Thanks for doing that.  I'll have a look later today.  Is the status of the ghc6 transition "Done"?
<_16aR_> ok jpds, thanks. I can't find the info on revu/wiki again :)
<RainCT> jpds: I filed a backport request for lintian. Could you have a look at it when you like? (You can find a .deb in my PPA, no need to test-build it again)
<RainCT> _16aR_: http://wiki.ubuntu.com/ReleaseSchedule
<_16aR_> RainCT: thanks. So the feature freeze is on 19th ?
<brennion> how can I know that a motu as noticed about my uploads in launchpad ?
<RainCT> _16aR_: right
<jpds> RainCT: I'll look at it later today.
<kolby> so I took the example file and I don't know what to change.
<kolby> This is my watch file:
<kolby> http://paste.ubuntu.com/115629/
<RainCT> brennion: I don't understand your question..
<RainCT> jpds: Cool, thanks
<RainCT> kolby: that's not a watch/file
<kolby> ohhhh
<brennion> If I upload my files on the bug in lauchpad, can I check somewhere the status, to see if a motu have seen it, works on it...
<RainCT> kolby: look at the section  "FORMAT of debian/watch files"  in   man uscan
<kolby> alright.  I'll be back shortly
<kolby> should the ftp part come from launchpad ?
<DktrKranz> ScottK, all done
<ScottK> DktrKranz: Thanks.
<kolby> I found a place: ftp://ibiblio.org/pub/Linux/utils/file/
<mok0> We'd like a second advocate for libmirage on REVU, there's a bunch of other entries in the queue that depend on it (cdemu stuff)
<mok0> RainCT: wow I like the new graph!
<RainCT> mok0: Thanks :)
<kolby> Here's my new watch file :  http://paste.ubuntu.com/115634/
<RainCT> kolby: you can delete the "debian uupdate" part
<kolby> RainCT: okay
<kolby> RainCT: alright.  Should I upload then?
<RainCT> kolby: If the watch file works fine and you've fixed everything, sure. (I haven't looked at the package).
<kolby> RainCT: thanks
<_16aR_> anyone has an idea about converting upstream package to utf8 ?
<_16aR_> do I need to provide a patch ?
<Laney> hyperair: here?
<hyperair> Laney: yep. what's up?
<Laney> Do you have access to the gnome-do PPA? I see you uploaded notify-sharp there
<hyperair> Laney: no i don't, they copied it from banshee-team
<Laney> oh, nm then
<hyperair> alright
<hyperair> why don't you post in #gnome-do?
<kolby> uscan --verb passed my watch file
<brennion> I've checked the doc about sponsoring, but as I'm not sure what "upstream version" means, In the repository there is the version 0.8b3-0ubuntu1, if I'm proposing 0.8b4-0ubuntu1, is that an upstream version ?
<Laney> will do
<kolby> I uploaded the .changes
<Laney> I was trying to take a shortcut
<_16aR_> brennion: upstream version is the original software version
<_16aR_> so the 0.8b3 and 0.8b4 are 2 differents upstream version
<_16aR_> the -0ubuntu1 and -0ubuntu2 for example is package version
<_16aR_> so the upstream version is taken on the official website of the soft/sources
<brennion> ok ! And so if I wan't to propose a new upstream, I need to upload a diff.gz file to lp ?
<_16aR_> yes
<_16aR_> because the debian/ directory shouldn't be in an upstream version
<_16aR_> the debian directory should be created in the diff.gz by the debian scripts
<_16aR_> (debuild -S -sa, etc)
<_16aR_> what you can do to create a new version from new upstream is to have one tree with the old package 0.8b3, with the debian/ folder in it, and one tree with the 0.8b4 version (naked, without the debian folder/ in it)
<_16aR_> then copy the 0;8b3/debian/ folder into the 0.8b4/, then try to see if the version build like that with pbuilder, if it does, modify changelog, add that you've taken new upstream version, etc
<_16aR_> it is quick and dirty way, so  you may need adjust a lot more parameters
<_16aR_> i'm gone now
<_16aR_> bye
<RainCT> cya _16aR_
<RainCT> http://revu.ubuntuwire.com/stats - nice, eh? :)
<brennion> many thx
<kolby> one of the errors were that I do not have an ubuntu.com email address.
<kolby> I don't even know where revu gets these lintian errors.
<kolby> I ran lintian -I and found nothing
<RainCT> kolby: those displayed on REVU are not from lintian, those are checks inbuild in reVU
<kolby> RainCT: oh...
<kolby> where do I change which version of ubuntu it's for?
<RainCT> kolby: debian/changelog, first line
<jcfp> RainCT: cool graph, sure makes one wonder what made feb'08 such a good month
<RainCT> That's when I became a MOTU.. Muahaha :P
<jcfp> hehe
<kolby> where do I put (LP: 307928) ?
<RainCT> kolby: in your changelog entry
<RainCT> next to "* Initial release" or whatever you wrote
<kolby> okay
<kolby> like this, right? :
<kolby>   * Initial release (LP: 307928)
<RainCT> kolby: yep
<RainCT> kolby: but with a # before the number
<kolby> now what do I do about not having a ubuntu.com maintainer address?
<kolby> okay
<RainCT> kolby: do what the messages tells you to do - set MOTU as the maintainer
<kolby> thanks
<RainCT> kolby: Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
<kolby> awesome
<kolby> leave the address on the next line, right?
<RainCT> kolby: no, all together
<kolby> okay
<RainCT> kolby: and on the line below you can list yourself as XSBC-Original-Maintainer
<kolby> yay ^^
<RainCT> kolby: please tell me before you upload, I want to try something out
<kolby> alright.
<kolby> XSBC-Original-Maintainer on the same line?
<RainCT> kolby: no, on the line below
<kolby> with a Maintainer: tag?
<kolby> this is what I put:
<kolby> Maintainer: XSBC-Original-Maintainer <kolbyheacock@gmail.com>
<RainCT> kolby:   it should just be:      XSBC-Original-Maintainer: Your Name <kolbyheacock@gmail.com>
<kolby> alright.
<kolby> I'm uploading now then
<RainCT> kolby: OK
<surfaz> Adri2000, https://bugs.launchpad.net/ubuntu/+source/filezilla/+bug/326578
<ubottu> Ubuntu bug 326578 in filezilla "Please update FileZilla package to latest stable version (3.2.1) in Ubuntu 9.04" [Wishlist,In progress]
<kolby> dang
<kolby> what do I put for the distrobution name
<RainCT> kolby: jaunty
<kolby> I put jaunty and it said no
<kolby> whatever.  I'm leaving it.  I must have an older lintian
<RainCT> kolby: Yes, ignore that.
<RainCT> kolby: or get the latest lintian from https://launchpad.net/~rainct/+archive
<kolby> I'll do that soon
<xoox> How come I can't pull-lp-source conkeror-spawn-process-helper
<xoox> ?
<xoox> (does not appear to exist in Ubuntu)
<RainCT> xoox: it doesn't
<xoox> http://packages.ubuntu.com/jaunty/conkeror-spawn-process-helper
<kolby> I tried to upload and I got this:
<kolby> Already uploaded to revu.ubuntuwire.com
<RainCT> kolby: dput -f
<kolby> alright
<kolby> I'll upload and work on it after breakfast
<RainCT> xoox: Ah. Because the name of the source package is just "conkeror"
<kolby> I have to go.
<kolby> I will upload it in 30 minutes
<xoox> RainCT: Thanks
<RainCT> xoox: You're welcome. FYI, you can find out the name of the source package by running:   apt-cache showsrc conkeror-spawn-process-helper | grep Package
<xoox> RainCT: Thanks, useful tip.
<kolby> it's uploading now.  The person waiting on me waited
<kolby> be back in 30 minutes
<Adri2000> surfaz: I'm writing an answer
<stgraber> What do I need to do to appear as a MOTU on revu ?
<RainCT> stgraber: ask for it :)
<stgraber> who do I need to ask ? :)
<RainCT> stgraber: you already did :)
<RainCT> stgraber: ok, you're marked as MOTU :)
<stgraber> hehe, looks like I'm lucky today :) thanks
<Adri2000> surfaz: done. tell me if there is anything unclear or you don't agree with
<mok0> stgraber: go go go!
<kolby> alright.
<kolby> There appears to be no errors in my upload.
<kolby> please let me know if there are any reasons md4sum shouldn't be included in jaunty.
<kolby> http://revu.ubuntuwire.com/p/md4sum
<kolby> thank you all.
<savvas> should we send packages of merge requests to revu?
<Laney> no
<surfaz> hi all, Why are addons of iceweasel in ubuntu repositories?
<ScottK> surfaz: We sync from Debian, so we get those.  Most of them can be easily adjusted to work with Firefox.
<ScottK> Just needs someone to do it.
<quadrispro> could anyone review this? http://revu.ubuntuwire.com/details.py?package=mandvd
<surfaz> ScottK, how?
<RainCT> surfaz: https://wiki.ubuntu.com/MozillaTeam/Extensions/Merging
<ScottK> There you go.
<surfaz> not, I refer how I should adjusted for Firefox,   by revu or by launchpad bug?
<RainCT> surfaz: debdiff attached to a LP bug
<surfaz> but I should change name of package, no?
<RainCT> surfaz: how is it called?
<savvas> is there a link with the merging process? I read about using some tools called MoM and DaD, are those restricted to motu developers only?
<DktrKranz> !merge
<ubottu> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<Adri2000> no, anyone can use them
<DktrKranz> savvas, --^
<surfaz> RainCT, iceweasel-dom-inspector iceweasel-firegpg  iceweasel-linky iceweasel-vimperator
<savvas> thanks :)
<surfaz> RainCT, by debdiff is the correct way to do that?
<surfaz> I'm not talking about change dependencies, I talking about change name of package
<RainCT> surfaz: Yes. And yes, those packages should be renamed to remove the "iceweasel-" (but just remove it, don't add "firefox-" nor anything else)
<surfaz> ok
<RainCT> surfaz: About FireGPG, I think the firefox-extensions team is working on it.. Best check in #mozillateam
<surfaz> there is nobody in that channel
<RainCT> surfaz: err, #ubuntu-mozillateam
<RainCT> surfaz: and look at the wiki page I told you or you will most likely miss something :)
<tdomhan> what's the best way to package a python program, that doesn't use distutils, and expects that all needed files reside in the executable's directory, e.g. icons/translations etc.? two solutions I could think off: putt all stuff in /opt     or   write patches in order search for the files in the appropriate FHS locations? what's the best solution? any other solutions?
<Laney> patch it if you want it to get into Ubuntu
<RainCT> tdomhan: Packages are not allowed to touch /opt, in any case the correct folder would be /usr/share/<package name>
<tdomhan> ah ok
<kolby> Do you think my package will get in to Jaunty before the feature freeze in 11 days?
<lfaraone> tdomhan: you could give it a /usr/share folder.
<RainCT> tdomhan: You can put the .py files, images, etc. there, but documentation should go into /usr/share/docs/<pkgname> and translations to the correct place to
<tdomhan> RainCT, I'm not really that familiar with python, but is "gettext.translation('gpicsync-GUI', "locale",languages=['de])" looking in /usr/share/locale/$LANG/LC_MESSAGES/ for the translation files, instead of the program folder?
<alex-weej> struggling to publish my GPG key to ubuntu keyserver
<alex-weej> gpg --keyserver keyserver.ubuntu.com --send-keys
<alex-weej> returns 0
<alex-weej> but doesn't seem to have worked. my key isn't on the server according to Launchpad
<alex-weej> http://keyserver.ubuntu.com:11371/pks/lookup?search=0x8DFC7C8EBAD7B41917AD0D78235104A205F6BB59&op=index
<mok0> alex-weej: try another keyserver
<alex-weej> but it needs to be on this for it to work with launchpad right?
<mok0> alex-weej: the keyservers exchange data
<alex-weej> but i gotta wait right
<mok0> alex-weej: yes
<alex-weej> lame
<alex-weej> published to pgp.mit.edu
<mok0> It might still have worked. What is your keyid?
<mok0> alex-weej: I've only ever published my key there
<alex-weej> 0x05F6BB59
<ScottK> alex-weej: Have you added your key to your Launchpad account?
<alex-weej> scottK: i am trying... this is the problem
<ScottK> I don't mean send it to the Ubuntu keyservers, I mean add it to LP via the LP U/I.
<alex-weej> ScottK: i am on this page: https://launchpad.net/~alex-weej/+editpgpkeys
<alex-weej> i put in my fingerprint 8DFC 7C8E BAD7 B419 17AD  0D78 2351 04A2 05F6 BB59
<mok0> Ubuntu's keyserver seems to be down
<alex-weej> that would explain it then
<ScottK> alex-weej: OK, but that doesn't have anything to do with the keyserver.
<alex-weej> ScottK: it says Have you published your key to a public key server? You can do that by by entering in a terminal:
<alex-weej>     gpg --keyserver keyserver.ubuntu.com --send-keys
<alex-weej> Has your key been automatically mirrored to the Ubuntu key server? Keys sometimes take up to an hour to be synchronized between servers. You can check if it has by querying the Ubuntu key server directly. If it hasn't, you can publish directly to our server by entering in a terminal:
<alex-weej>     gpg --keyserver keyserver.ubuntu.com --send-keys
<alex-weej> "querying the Ubuntu key server directly" is a link
<alex-weej> to the URL i posted above
<ScottK> Hmmm.  OK.  It's been some time since I did it.
<mok0> Me too. But Ubuntus keyserver is completely unresponsive
<mok0> times out
<mok0> Canonicals network really sucks
<alex-weej> bla
<alex-weej> screw it, i'll try it tomorrow
<alex-weej> no PPA for me
<mok0> alex-weej: your key is published
<alex-weej> mok0: yeah i see it on mit's server
<mok0> alex-weej: it should migrate to ubuntu's keyserver then
<mok0> when it comes up :-)
<RainCT> tdomhan: Sorry, I was away. In case nobody has answered yet, change "locale" to '/usr/share/locale'. Also, there's a typo ("['de]" should be "['de']"), but I guess you can remove that "languages=.." chunk altogether
<tdomhan> RainCT, ok your solution would be: use a folder in /usr/share with all except docs/translations. and write a patch in order to point to the new location of the translations?
<RainCT> tdomhan: yep
<alex-weej> ok so the keyservers back
<alex-weej> now i'm waiting for LP mail to send me my encrypted message
<alex-weej> this feels more like one of those ARGs than anything else...
<alex-weej> ok all done
<alex-weej> so i've apt-get source'd a package
<alex-weej> made some changes to the sources, and now i want to publish those to a PPA
<alex-weej> says here i should just be able to dput the .changes file
<alex-weej> https://help.launchpad.net/Packaging/PPA#Building%20your%20source%20package
<alex-weej> hm, debsign wants to sign the changes file with someone else's key
<alex-weej> how do i tell it to use mine?
<pochu> use -k
<alex-weej> same thing
<pochu> debsign -k12345ABC foo.changes
<alex-weej> where is it getting this default key ID from then?
<alex-weej> shouldn't i change that instead?
<pochu> change what?
<pochu> it looks at the Changed-By in the .changes AFAIK
<alex-weej> gpg: skipped "Andrew Starr-Bochicchio <a.starr.b@gmail.com>": secret key not available
<pochu> then looks for a key with the same id
<pochu> to use a different key (e.g. yours), you have to use -k$KEYID
<alex-weej> i see
<alex-weej> is this the proper way to go about this then?
<pochu> it's the same with dpkg-buildpackage
<pochu> yeah
<pochu> oh well
<pochu> are you Andrew? :)
<alex-weej> nope
<alex-weej> :)
<pochu> then it is ;)
<alex-weej> ok it successfully uploaded packages
<alex-weej> but it isn't showing in the web interface -- does it lag?
<RainCT> alex-weej: check your inbox. If you got no rejection mail, then it is
<alex-weej> Rejected:
<alex-weej> Upload rejected because it contains binary packages.
<alex-weej> fail
<pochu> you need to upload only the source
<pochu> e.g. dpkg-buildpackage -S
 * alex-weej has been using debuild
<pochu> check the .changes file, it shouldn't reference any .deb
<pochu> alex-weej: I think debuild -S does the same
<alex-weej> ok i figure i should do the versioning properly
<pochu> alex-weej: the same version will work, as it wasn't accepted
<alex-weej> i am supposed to use dch right? but that's just bumped the version to 0.9-2build2
<pochu> you will need "-S -sa" if the orig.tar.gz isn't in Launchpad, btw
<alex-weej> i think it is
<sven777> would a MOTU be so kind as to review my package? Thanks in advance! http://revu.ubuntuwire.com/details.py?package=lmalinux
<pochu> then -S will save bandwidth ;)
<alex-weej> ok i used dch to create a changelog entry
<alex-weej> then dpkg-buildpackage -S
<alex-weej> and it said
<alex-weej> gpg: skipped "Alexander Jones <alex@weej.com>": secret key not available
<alex-weej> gpg: [stdin]: clearsign failed: secret key not available
<alex-weej> oh arse i used my middle name in my key
<mok0> alex-weej: the secret key is on your own computer
<alex-weej> that was a fail.
<alex-weej> anyway, i should still be able to sign with debsign right?
<pochu> alex-weej: btw you don't need to bump changelog in this case, as the upload was rejected and is not on your ppa
<mok0> alex-weej: then use -kKEYID
<alex-weej> alex@fizz:~/Desktop/nautilus-open-terminal-0.9$ debsign -k05F6BB59
<alex-weej> debsign: Can't find or can't read changes file !
<pochu> you miss the .changes file :)
<pochu> debsign -k$GPGKEY foo.changes
<alex-weej> it worked before...
<pochu> alex-weej: cd ..
<alex-weej> when it was the i386.changes file it just figured it out
<alex-weej> i guess there's 2 files now so i need to tell it
<mok0> The email in the top changelog entry must match your key
<alex-weej> ok i've made a total hash of this then
<alex-weej> but i don't understand because the top changelog entry wasn't even me before
<alex-weej> yet it still signed
<alex-weej> alex@fizz:~/Desktop$ debsign -k05F6BB5 *_source.changes
<alex-weej>  signfile nautilus-open-terminal_0.9-2build2.dsc 05F6BB5
<alex-weej> gpg: skipped "05F6BB5": secret key not available
<alex-weej> gpg: [stdin]: clearsign failed: secret key not available
<alex-weej> guh... 3 and a half bytes
<pochu> alex-weej: 05f6bb5 is 7 char long :P
<alex-weej> yeah i just realised. my eyes are failing
 * pochu can't study anymore :(
<alex-weej> so why wouldn't i need to bump the changelog?
<pochu> alex-weej: you need if the files are in the server, so they don't clash. they aren't though, as the upload was rejected
<alex-weej> "if the files are in the server"?
<pochu> in the PPA
<pochu> e.g. in http://ppa.launchpad.net/pochu/ppa/ubuntu/
<alex-weej> hm
<alex-weej> more gpg fun
<alex-weej> i've added my name "Alexander Jones" without the "Mark" to my key, and added a photograph
<alex-weej> but now it won't sync anymore :(
<alex-weej> <big><b>Couldn't publish keys to server</b></big>
<alex-weej> Error decoding keyblock
<alex-weej> oh it doesn't like the photo
<alex-weej> i see
<pochu> some keyservers don't AFAIK
<nhandler> If a package gets removed from the repositories, what is the procedure for getting it added again?
<DktrKranz> nhandler, do you know why it has removed?
<nhandler> DktrKranz: It was removed in Debian, and we were syncing the Debian package.
<DktrKranz> which one?
<nhandler> DktrKranz: https://edge.launchpad.net/ubuntu/+source/socketapi (http://packages.qa.debian.org/s/socketapi/news/20070108T233911Z.html). Someone uploaded a new version to REVU, and I want to be sure I'm giving them accurate information
<DktrKranz> nhandler, Debian removed it because he was superseded by kernel-implementation, do we have such package?
<DktrKranz> uh, it's not a package, it's kernel itself
<nhandler> I was planning on asking the uploader if there was any reason to add the new version since the old version was superseded. But if there is a valid reason, what would be that process?
<DktrKranz> I'd ask archive-admins to restore it and removing any blacklisting, then upgrade it as usual
<nhandler> So it would follow the normal package upgrade procedure and not the new package procedure? Would the same go for Debian?
<DktrKranz> I have a similar experience upgrading php-imap
<DktrKranz> it was removed, I asked pitti to restore it and upgrade it as usual
<DktrKranz> I'm not sure if Debian can restore packages, though
<hanska> DktrKranz: may I help? ;)
<DktrKranz> hanska, do you have any ftp-master handy? :)
<hanska> DktrKranz: what happened? Maybe a $deity is not needed ;)
<DktrKranz> s/$deity/$deity_is_nothing_they_can't_process_NEW/
<hanska> ahahah :P
<hanska> well, NEW is in hard-suck mode right now
<DktrKranz> hanska, I was wondering if a removed package can be restored with a "click here to restore it" button
<hanska> but in a but more than a week everything should end ;)
<DktrKranz> or it has to go through NEW again
<hanska> DktrKranz: no, it needs NEW
<DktrKranz> hanska, I HOPE SO
<hanska> eheh
<DktrKranz> I want to clear my exp queue :)
<hanska> DktrKranz: if a user needs it, snapshot.debian.net is --> ;)
<hanska> DktrKranz: uh?
<DktrKranz> I have several packages in exp right now
<DktrKranz> and I want them to be in unstable :)
<ScottK> Going from Experimental to Unstable doesn't need New (IIRC), just a new upload.
<hanska> ScottK: right, just a new revision suffices
<DktrKranz> hanska, there was a request of a package upgrade, which got removed. Not sure if it is useful with recent kernels, just curious about Debian way to manage this case
<hanska> DktrKranz: if you have foo 1.0-1 in exp, upload 1.0-2 to unstable, and the package from exp will automagically disappear
<hanska> DktrKranz: name?
<DktrKranz> (and yes, no NEW for exp -> unstable, just looking forward to see lenny released!)
<hanska> eheh
<DktrKranz> hanska, socketapi
<hanska> DktrKranz: why would you want that package?
<hanska> "RoQA; Superseded by kernel-implementation"
<hanska> I don't believe QA guys would be happy :P
<DktrKranz> user requested it again (http://revu.ubuntuwire.com/p/socketapi)
<hanska> did the user reply to nhandler ?
<DktrKranz> not yet, his statement is about 15 minutes ago
<hanska> ah, I missed the date/time :P
<hanska> well, if there's a *real* reason, then I believe it could be re-added to Debian (through NEW, that is)
<hanska> otherwise, I believe there could be grounds for REJECTion
<DktrKranz> $deity_is_nothing_they_can't_process_NEW to REJECT(tm) something? Impossible :P
<hanska> DktrKranz: are you sure?... in debian-mono we got a REJECT because we forgot to add the text of MPL to debian/copyright...
<hanska> DktrKranz: (remember, there are two new ftp-assistants training, and they must be picky enough to convince other ftp-$deities ;))
<DktrKranz> sarcasm ;)
<DktrKranz> they do their job
<hanska> yep, but you start hating them when your package has to re-go NEW...
 * DktrKranz passed it
<DktrKranz> a silly error of mine, though :(
<hanska> it happens ;)
<Rafik> Hello guys. I spent the weekend between the wiki pages and the terminal learning packaging. I have a question. Can we ask for merges from debian experimental ?
<ScottK> Rafik: Yes.
<Rafik> ScottK> thanks
<ScottK> YW
<xoox> How do I get prevu to use my gpg key for signing packages?
<chrismurf> Hello - I have built a package for pyproj (http://code.google.com/p/pyproj/).  It's currently on my Launchpad PPA -- how do I go about getting it into Universe?
<chrismurf> also - a related question - what's the typical place for storing the /debian/ directory contents?  Upstream?  In my own personal SVN/BZR? Elsewhere?
<maher> hello guys
<maher> we are trying to create new linux distro that is based on ubuntu,
<maher> and I want to add new bookmarks to firefox to be ready in the new distro
<maher> can anyone help me?
<maher> or direct me to something?
<quadrispro> chrismurf: Hi! Did you file a needs-packaging bug for pyproj?
<alex-weej> my ppa build is failing with checking for GCONF... configure: error: Package requirements (gconf-2.0) were not met:
<alex-weej> No package 'gconf-2.0' found
<alex-weej> but my package is just a slight modification of what is already in the archives
<alex-weej> i haven't changed the dependencies or anything
<alex-weej> is it possible that a package may build in the main system but not in PPA?
<alex-weej> or are they the same system?
<directhex> only if your package is wrong
<directhex> i.e. a PPA does a fresh build environment using your build-depends
<directhex> so if your build-deps are wrong, then it won't pull in everything it needs
<chrismurf> quadrispro, no -  I have no idea what I'm doing :-)
<chrismurf> I am gaining comfort with the debian packaging process in general
<chrismurf> but know absolutely 0 about the process / politics / community side :-)
<chrismurf> teach me, oh master ;-)
<alex-weej> directhex: ok, so it's possible the upstream package is broken too then?
<alex-weej> directhex: by upstream, i actually mean the original debian package i am deriving from
<directhex> alex-weej, and you build-depend on libgconf2-dev ?
<quadrispro> hi chrismurf, that projec is really interesting, the first thing you have to do is filing a bug and tagging it as needs-packaging
<quadrispro> chrismurf: i.e. bug 105464
<ubottu> Launchpad bug 105464 in ubuntu "[needs-packaging] mandvd" [Wishlist,In progress] https://launchpad.net/bugs/105464
<quadrispro> or bug 199398
<ubottu> Launchpad bug 199398 in ubuntu "[needs-packaging] w_scan" [Wishlist,In progress] https://launchpad.net/bugs/199398
<alex-weej> directhex: i haven't brought that dependency in myself. it was always there.
<directhex> alex-weej, then check config.log
<chrismurf> quadrispro, okay - then attach the package there?
<alex-weej> directhex: so i can get away with it if it's a main package upload
<chrismurf> or a link to my PPA version?
<alex-weej> but not a PPA?
<quadrispro> chrismurf: no, you should upload the package to REVU (and paste the link into the bug report)
<directhex> alex-weej, always test in a pbuilder. anything you do with dpkg-buildpackage is effectively untested
<quadrispro> chrismurf: http://revu.ubuntuwire.com
<alex-weej> directhex: excuse my ignorance, i don't know what that is
<alex-weej> i mistakenly believed debian packaging wouldn't require more than about 5 minutes before i could start programming again
<alex-weej> :P
<chrismurf> quadrispro, thanks - sounds like a good place to get started
<chrismurf> Is there a good tut / document I should follow?
<directhex> alex-weej, it does the same thing as a PPA. it creates a clean build environment & installs all the build-deps into a folder, to ensure rigour
<chrismurf> I should I just come back here :-)
<chrismurf> ohh - REVU is interesting -- I understand now.  Thanks~!
<quadrispro> chrismurf: that's it https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<alex-weej> directhex: so what should i use? debuild? dpkg-buildpackage? pbuilder?
 * alex-weej is overwhelmed with tools
<directhex> alex-weej, pbuilder or a wrapper for pbuilder. anything else is worthless to ensure whether a package will actually build on anywhere other than a desktop
<quadrispro> chrismurf: I've bookmarked the project homepage ;)
<alex-weej> are there any nice gnome/gtk tools for doing debian package maintenance?
<alex-weej> i just want something to hold my hand through one specific workflow
<chrismurf> quadrispro, if you want an intrepid package atm, https://launchpad.net/~chrismurf/+archive/ppa
<chrismurf> :-)
<directhex> if it were trivial to do, it wouldn't need an army of packagers
<alex-weej> rather than just guessing "which tool next?"
<directhex> read the packaging tutorials on the ubuntu wiki
<alex-weej> i would do if i had a spare month or so
<alex-weej> :)
<alex-weej> I can't wait till everything is in bazaar
<alex-weej> and i could just push a branch and have it work automatically
<directhex> have you done the usual rigour checks? is the gconf dev package being pulled in in the build log? no missing commas in debian/control?
<quadrispro> chrismurf: mmm... there are some changes to do, but now I'm very tired (in Italy it's 11.30 pm)... I'll take look tomorrow ;)
<quadrispro> I'll take a look *
<chrismurf> quadrispro, thanks, I'm filing bugs now
<chrismurf> will try and get up to speed on the process via the wiki + REVU
<chrismurf> bug 326996
<ubottu> Launchpad bug 326996 in ubuntu "pyproj" [Undecided,New] https://launchpad.net/bugs/326996
<quadrispro> chrismurf:  perfect
<alex-weej> directhex: i haven't touched it
<alex-weej> directhex: this is literally an apt-get source, dput
<directhex> alex-weej, same release version?
<alex-weej> think so
<alex-weej> never mind, let's try another package
<alex-weej> i've modified a default value in compiz-fusion-plugins-main
<alex-weej> i've opened a bug for the problem
<alex-weej> how do i get a change "sponsored"?
<directhex> you didn't feel like sharing your build log?
<alex-weej> no
<chrismurf> quadrispro, one more question if you're around?
<quadrispro> chrismurf: yes
<RainCT> alex-weej: https://wiki.ubuntu.com/SponsorshipProcess
<chrismurf> quadrispro, what's the typical location for packaging info to be stored?  BZR/Launchpad?  Upstream SVN? My own repo?
<chrismurf> the /debian/ directory should go someplace besides just bug reports I'm guessing?
<directhex> chrismurf, most packaging trams will have a shared repo of some kind
<quadrispro> chrismurf: what do you mean with "packagin info"? do you mean debian directory content?
<chrismurf> yes
<directhex> s/trams/teams/
<alex-weej> RainCT: thanks
<RainCT> chrismurf: Packages are stored in the repos when they are uploaded. Additionally, you can of course also have it in a VCS of your choice.
<quadrispro> chrismurf: ah, beh, after package uploading, it's stored into the repository :)
<chrismurf> I see :-)
<quadrispro> chrismurf: (apt-get source PACKAGE) :)
<directhex> chrismurf, some packages don't have a central store of packaging info, the only repository is ad-hoc in the source package
<chrismurf> so - in progress, do whatever I want, and the outcome is all that matters
<chrismurf> :-)
<chrismurf> I see
<directhex> chrismurf, e.g. the teams i'm involved with have SVN repositories on the debian project's Alioth servers
<quadrispro> chrismurf: but I see a thing... did you include the debian dir in the tarball?
<quadrispro> (chrismurf: it's not so simple, anyway, there are a number of packaging rules we have to follow, if you're looking for a good guide -> https://wiki.ubuntu.com/PackagingGuide)
<chrismurf> right - I'm 100% sure the package is not ready for prime time
<chrismurf> just trying to figure out where I should be working as I get it ready
<chrismurf> sounds like the answer is "whatever works for you, we just want working packages :-)"
<chrismurf> I'll start reading through those various guides and try to get the package ready
<quadrispro> chrismurf: ok, I'll try to give you my support :)
<chrismurf> quadrispro, thanks for that given so far :-)
<quadrispro> chrismurf: you're welcome: this is ubuntu :)
<quadrispro> I'm going away, chrismurf: see you soon
<quadrispro> bye guys!
<RainCT> btw, which of those is correct: "and so on" or "and soon" (for the same meaning as "etc.")?
<mok0> RainCT: the first
<RainCT> mok0: thanks :)
<alex-weej> when i use "dch" it adds the line: nautilus-open-terminal (0.9-2build2) jaunty; urgency=low
<alex-weej> where is jaunty coming from?
<alex-weej> i'm running intrepid
<alex-weej> and when i upload it to my PPA it only builds for jaunty
<mok0> alex-weej: yep
<alex-weej> i want it to build for intrepid too
<alex-weej> and i want the changelog to be correct
<alex-weej> the change pertains to no particular ubuntu release
<mok0> alex-weej: add ~intrepid1 to the release in a new changelog entry, and make the distro intrepid
<alex-weej> mok0: do i just need to change it in the changelog?
<mok0> alex-weej: yes
<alex-weej> so everything is literally parsed out of the changelog
<alex-weej> the new version number
<alex-weej> target distro
<alex-weej> everything?
<mok0> yes
<alex-weej> if i make it intrepid, will it still build it for jaunty?
<alex-weej> (as well)
<directhex> maybe
<directhex> not guaranteed, if the build-deps have changed
<mok0> alex-weej: no, only intrepid, we don't have multi distro builds yet
<alex-weej> so if i want more than one distro i need to add another changelog entry!?
<mok0> alex-weej: exactly
<alex-weej> :(
<alex-weej> i take it for real packagers it just works?
<directhex> right.
<alex-weej> so should i even bother wasting my time writing a proper changelog?
<directhex> well, old packages cascade through into newer releases, anyway. unless they're superceded
<mok0> alex-weej: just write "compile for intrepid"
<alex-weej> the previous version was 0.9-2build2. should it now be 0.9-2build3~intrepid1? or 0.9-2build2~intrepid1?
<alex-weej> or 0.9-2~intrepid1?
<jcastro> you can keep seperate distros in seperate branches in bzr, that's what I do
<mok0> alex-weej: 0.9-2build2~intrepid1
<alex-weej> when i run debuild -S it always asks me for my gpg passphrase twice
<directhex> +intrepid1.
<mok0> alex-weej: yes it signs 2 files
<directhex> if you use ~, then it will be numbered lower
<alex-weej> +intrepid1?
<alex-weej> aw.
<alex-weej> now i gotta do it again
<directhex> and overwritten by 0.9-2build2
<directhex> if you want to overwrite 0.9-2build2 then use 0.9-2build2+foo if it's based on 0.9-2build2 or 0.9-2build3~foo if it's based on 0.9-2build3
<alex-weej> i've gone 2build2 to 2build2+intrepid1
<mok0> tilde is used for backporting
<directhex> mok0, amongst other things
<directhex> mok0, it's generally useful in other situations. e.g. upstream "beta" versions -> 1.0~beta1
<directhex> -1
<RainCT> yay, I'm 18 :)
<mok0> RainCT: happy birthday!
<RainCT> thanks :)
<directhex> :o
<directhex> OLD!
<directhex> i'm not sure i can respect packaging work done by a wrinkly geezer like RainCT
<RainCT> lol
<balor> Ubuntu specifically links some low level libs against libpcre  (Debian does not) eg: libpthread libglib.  I'm wondering why this is so in order to rule it out as the cause of a but in QT?
<RainCT> (In case somebody wants to learn about pbuilder, I've just written a post explaining the basics on how to use it: http://bloc.eurion.net/archives/2009/test-build-debian-packages/)
<RainCT> Now, good night :)
<sven777> happy birthday RainCT!
<piegod> Hi, will the 'ngircd' package in Jaunty be configured with ssl support on?
<geser> piegod: I just gave it a quick look, and it looks like it's GPL w/o a OpenSSL exception, so no. Unless it supports also GnuTLS
<piegod> geser: well it does support TLS, but I'm not sure if I do :|
<piegod> If I were to apt-get source it, and then configure it --with-openssl, when I used make/install would it install the init scripts in init.d?
<geser> piegod: depends, if the init script comes from the debian packaging than no, if it's from upstream perhaps.
<piegod> ok :/
<geser> A better way is to modify the package as you need it and build a local deb for you, so you still have the advantages from the package management
<piegod> how do I go about doing that?
<piegod> hmm, just looked at the configure script in Jaunty's ngircd source... the option for both GnuTLS and OpenSSL is *not there* !?
<geser> got perhaps SSL support got included in a more recent version than is available in jaunty?
<piegod> Jaunty is 0.12 right? 1sec - reading changelog
<piegod> ah
<piegod> 0.13 included SSL/GnuTLS support, wasn't in 0.12/0.12.1
<piegod> or in this case, 0.12.1-2
<piegod> so how do I go about building a local deb?
<alex-weej> my package built in my PPA, but it doesn't show up in synaptic under the PPA origin, and it doesn't show up as a version of the package i'm upgrading https://launchpad.net/~alex-weej/+archive/ppa
<alex-weej> oh wait, i had locked it
<alex-weej> never mind
<geser> piegod: updating to a new version can be easy or not (depends on the package) and I don't know of top of my head if there is a good description in the wiki
<piegod> ok :/ I'd like to be able to use 0.13 without losing package management on ngircd, that's all :)
<geser> perhaps someone else in this channel can help you out as I'm not in the condition right now (got back home from FOSDEM one hour ago)
<piegod> Okay :)
#ubuntu-motu 2010-02-08
<Legendario> lfaraone, that's the weird. There is no diff.gz
<lfaraone> Legendario: did you run "debuild -S"? (upper case S)
<persia> And did you get a message about trouble finding the orig.tar.gz?
<Legendario> lfaraone, yes. debuild -S -sa
<lfaraone> Legendario: like persia said, could dpkg find the orig.tar.gz?
<Legendario> lfaraone, no. because it program is released as a simple bash script. It offered me the option to create a tar.gz file, which I accepted
<azeem> what is "It" which offered this to you?
<Legendario> azeem, debuild i guess
<azeem> I never saw debuild offering options to accept
<azeem> maybe it was dh_make?
<persia> Um, for packaging a bash script, one needs to create one's own tarball.
<persia> https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling is a bit out of date, but not a bad outline.
<persia> If doing it now, I'd be recommending DEP3, DEP5, and dh(1)
<Legendario> persia, the tarball was created, but not the diff.gz
<azeem> Legendario: because there was no .orig.tar.gz, it created a native package
<azeem> i.e. just .tar.gz and .dsc
<persia> I know.  But creating the tarball with debuild isn't the preferred method.  See the notes from my class.
<Legendario> persia, ok. I'll give it a try. thanks
<lfaraone> persia: is there a problem with using standards-version 3.8.4? REVU lintian complains.
<persia> lfaraone: spooky only has lintian 2.2.17ubuntu1.1 : you could backport a newer one if it's easy, and we can request that it be installed.
 * persia doesn't have permission to install stuff
<lfaraone> In what cases is update-notifier's "you must restart foo" triggered? Groundcontrol's postinst copies /usr/share/groundcontrol/groundcontrol-restart-required.update-notifier to /var/lib/update-notifier/user.d but I don't get a popup.
<lfaraone> (the app specifically to restart is nautilus)
<persia> I remember being very confused by that before, although I don't remember the results of my research.  I believe I had to look at the update-notifier source to figure it out.
<RAOF> IIRC you also need to actually trigger update-notifier in some way; simply dropping a file there doesn't trigger it.
<persia> That sounds like something that would benefit from dpkg trigger support.
<RAOF> It does, yes.
<lfaraone> RAOF: I'm looking at firefox's packaging right now. it's a very very very complicated debian/ directory, but I don't *think* they are triggering anything.
<hyperair> check the postinst.
<lfaraone> hyperair: that's what I'm looking at.
<hyperair> ah
<lfaraone> Firefox <http://paste.ubuntu.com/371346/> vs groundcontrol <http://paste.ubuntu.com/371345/>
<lfaraone> hyperair, RAOF, persia, am I missing something?
<RAOF> That part of the postinst is actually getting triggered, right?  IE: you're seeing the updatenotifier file being copied?
<hyperair> lfaraone: check the [ -d $UPDATENOTIFIERDIR ] block
<persia> Both of those are horrible.  They should have case wrappers to handle the different sorts of arguments.
<hyperair> it looks like it's copying a file into /var/lib/update-notifier/user.d
<aaron> is there any page that show's packages up for adoptions?
<persia> aaron: No, we don't have maintainers in Ubuntu.
<TiMiDo> oh ic.
<persia> TiMiDo: But, there's lots of work needs doing.  What sort of stuff would you like to do?
<TiMiDo> persia, possible packaging and i do a lot of translations also
<lfaraone> hyperair: yep. our file <http://paste.ubuntu.com/371347/> their file <http://paste.ubuntu.com/371350/>
<persia> TiMiDo: Well, I can't tell you anything about translations (I think there's an #ubuntu-translators or some such for that, but I could be wrong).
<hyperair> lfaraone: does it work?
<TiMiDo> true. perhaps now i want to do packages now =)
<persia> For packaging, most of the work is bugfixing, but there's also some package updates pending.  Which of those sound more interesting?
<lfaraone> hyperair: firefox's does, I think.
<TiMiDo> i will ove to do the updates pending =)
<TiMiDo> that wi'll be cool
<hyperair> lfaraone: read update-notifier's source then =p
<persia> TiMiDo: Take a look at http://qa.ubuntuwire.com/uehs
<persia> Packages not in sync with upstream is the most accessible list, but the other lists may be interesting to investigate as well.
<TiMiDo> is html2ps already updated it?
 * hyperair notices that lots of ubuntu-specific stuff seem to either be poorly documented, or written badly.
<persia> hyperair: patches welcome :)
<hyperair> usplash is one example of poor documentation
<hyperair> notify-osd has endless leaks
<hyperair> and this update-notifier is yet another example of poor documentation
<hyperair> not to mention update-manager and its grinding of the CPU using Xorg
<TiMiDo> persia, so i could update the package and after the update to where do i upload it?
<kklimonda> hyperair, is usplash even actively developed anymore? I was under the impression that it was dropped in favor of the plymouth
<hyperair> persia: it's easier to rewrite the whole thing than patch it up. notify-osd felt like hack upon hack while being implemented.
<lfaraone> AHA. I need to "touch /var/lib/update-notifier/dpkg-run-stamp"!
<hyperair> kklimonda: i'm not sure, but while i was trying to write up usplash support for uswsusp, i couldn't *any* documentation.
<persia> TiMiDo: Attach the new diff.gz to a bug requesting the upgrade, and subscribe one of ubuntu-main-sponsors or ubuntu-universe-sponsors, and someone will review.
<lfaraone> I have no idea where firefox is doing that, but as soon as I did that update-notifier started working!
<TiMiDo> oh okey that's cool
<persia> TiMiDo: rmadison can help you figure out which sponsor group to subscribe.
<TiMiDo> rmadison?
<TiMiDo> who is that?
<persia> hyperair: Sure, but even rewrites tend to be accepted, if they are good.
<persia> TiMiDo: rmadison is a command.
<TiMiDo> oh
<hyperair> persia: well, i'll look into it sometime, regarding notify-osd.
<persia> heh.  Best of luck :)
<hyperair> maybe i'll name it notify-osd++ or something lol
<lfaraone> hyperair: tradition is to call it notify-osd-ng :)
<hyperair> lfaraone: ah yes. of course. =p
<lfaraone> hyperair: I'm personally planning on writing purity-ng when I get a Round Tuit.
<hyperair> lfaraone: putty is awesome on windows. on linux it's just.. useless. redundant.
<lfaraone> hyperair: purity, not putty. Purity is an interactive CLI test application.
<lfaraone> hyperair: currently orphaned on Debian.
<hyperair> oh whoops
<hyperair> interactive CLI test eh
<hyperair> interesting.
<lfaraone> hyperair: it's really more of a game. see http://en.wikipedia.org/wiki/Purity_test
<hyperair> basically to test interactive CLI apps non-interactively?
<lfaraone> hyperair: no, it tests *you*.
<hyperair> huh
<hyperair> oh lol
<lfaraone> persia: would it be a bad idea to try to run groundcontrol through NEW if I have any hope of meeting the Feature Freeze?
<persia> Debian NEW or Ubuntu NEW?
<lfaraone> persia: personally I prefer doing fixes/packaging through Debian when I can, and then backporting changes to Ubuntu releases / wait for them to sync.
<lfaraone> persia: Debian, that is.
<persia> I'm not sure of current Debian NEW latencies, but I think you'd be pushing it.
<persia> For the new package I did last week, I uploaded to Ubuntu, and expect to send to Debian sometime this week.
<persia> (I'm waiting for two people who said they would be users to install it and confirm it works)
<lfaraone> persia: if you have a moment, I'd appreciate it if you could glance at http://revu.ubuntuwire.com/details.py?upid=7616
 * persia sucks at python packaging, and hopes that someone else will jump up and offer to review before this is compelte
<persia> lfaraone: maintainer should be "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<persia> Upstream should grow some StartupNotify support :)
<persia> Name, and Generic Name should be translated the same way that Comment is in the .desktop file.
<persia> s/seemlessly/seamlessly/ in Comment[en] in the .desktop file
<persia> X-Ubuntu-Gettext-Domain doesn't mean anything for stuff not in the langpacks
<persia> Categories should be restricted to those in http://standards.freedesktop.org/menu-spec/latest/apa.html
<persia> The .desktop file ought be upstream anyway, rather than in the diff.gz
<persia> I prefer ([\d\.]+) to (.*) in watch files, just in case.
<persia> Maintainer scripts should check arguments : see http://women.debian.org/wiki/English/MaintainerScripts
<lfaraone> persia: odd, it is upstream, I wonder why .desktop is in the diff.gz...
<persia> I'd prefer a get-orig-source that pulled released tarballs, rather than alternately pulling from bzr.
<persia> I tend to prefer DEB5 copyright, but it's fine as-is.
<lfaraone> persia: it only does that if you have bzr(revno) in changelog.
<persia> I also prefer to use Name <email> consistently, rather than Name (email) (in debian/copyright)
<persia> debian/copyright fails to specify where the upstream source lives.
<persia> lfaraone: Yeah, well.  It also fails the works-from-any-directory test.
<persia> Requiring both CDBS and debhelper (>=7.0.0) strikes me as odd.  Most CDBS packages are compat level 6 compliant, unless there is something fancy I don't see.
<persia> Extra trailing comma in Build-Depends
<persia> Changelog entry for "Misc packaging Fixes" seems pointless for an initial release.  nice to give credit, but I'm unsure if this is the best way.
<lfaraone> persia: well, I don't know how else to give doctormo credit for doing 90% of the work :)
<persia> Odd to see a polish translation for restart-required, but not the .desktop file, and no English translation for restart-required.
<persia> lfaraone: Re-check the first line of debian/copyright :)
<persia> And I'd probably set debian/compat to 6 unless there was some special reason to use 7.
<persia> Obviously, check lintian -iIEV and --pedantic on source and binary changes :)  Fix all the rest, and I'll run builds and check that.
<TiMiDo> persia, after the update i upload the package in launchpad?
<persia> I've also not yet reviewed upstream licensing, although I suspect it's likely clean, given the identity of upstream.
<lfaraone> persia: would you rather I remove the polish translations? I don't speak it :)
<persia> TiMiDo: Not quite.  Once you get a working updated package, attach the diff.gz of the updated version to a bug in launchpad.  Make sure that you have a working watch file or get-orig-source rule.
<TiMiDo> okey
<persia> lfaraone: No, I just find it odd to have only that one bit available in polish, and not in english, the more so when the .desktop file is partially translated in English, and not Polish.
<lfaraone> persia: what I really don't understand is why the desktop file ends up in the diff. It's part of upstream source!
<persia> lfaraone: Maybe it's duplicated somewhere, or generated on clean somehow?
<lfaraone> persia: if so, I'll stab the CDBS maintainers.
<persia> Or switch to dh(1) :)  Mind you, you'd also have to switch to python-support.
<persia> I do intend to fix python-distutils-extra at some point, as it gives me an excuse to learn python packaging, but that's not happening in the next couple days, and probably not for FF>
<lfaraone> persia: does pysupport handle XS-Python-Versions: fields?
<persia> No idea.  That's on my list of stuff to investigate :)
<ddecator> persia, how soon would be too soon to ask? =p
<persia> About 5 minutes ago :)
<ddecator> perfect timing
<persia> So, I don't recommend packaging new stuff until one has a fair bit of experience working with other people's packages, as this gives one a better feel for all the different ways to do things, and lets one develop a personal style.
<lfaraone> persia: aha! "Found cached translation database" seems to be the culprit. It still happens when I'm using dh(1) however...
<persia> That said, if one has something one *really* wants to package for some reason, the following process is what I use:
<lfaraone> Merging translations into groundcontrol.desktop.
<lfaraone> * "Found cached translation database\nMerging translations into groundcontrol.desktop."
<persia> lfaraone: Hrm.  I'm not sure about that.  Might want to turn on DH_VERBOSE to find the culprit.
<lfaraone> No idea what that means...
<persia> ddecator: make a directory with the package name, and create a debian directory.
<persia> ddecator: In that directory, create a watch file (man uscan can help).
<persia> ddecator: run dch --create to create a debian/changelog, and use uscan to get the upstream source
<persia> ddecator: unpack the upstream source, and move your debian directory into the unpacked directory.
<lfaraone> ddecator: absolutely no change in the output. (this was on a source upload)
<lfaraone> persia: you mean when DH_VERBOSE=1, right?
<persia> ddecator: `echo 7 > debian/compat` and `cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules`
<persia> lfaraone: Yep.
<lfaraone> s/ ddecator / persia /
<persia> It *should* make it more verbose.
<ddecator> lfaraone, haha, i wondered about that
<lfaraone> persia: so yeah, no change. See bzr branch lp:~groundcontrollers/groundcontrol/debianfiles :)
<persia> ddecator: use `licensecheck -r --copyright .` and `suspicious-source` to create and verify debian/copyright : I tend to use the format described at http://dep.debian.net/deps/dep5
<persia> ddecator: Create a debian/control file based on http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ch-controlfields.html
<persia> Build the source, and you've created a buggy package.  That's it.
<persia> Fixing the bugs is the fun bit :)  lintian -iIEV and --pedantic can help find some issues to think about.
<ddecator> thanks persia, i'm trying to work my way into getting into some debugging, but i'm a little lost on where to start so i'm learning basic python so i can recognize code. and suggestions as to some files i can use to practice packaging?
<persia> python-mkdebian automates it for most python programs.  Not into my favorite style, but it tends to mostly work.
<ddecator> i wanna figure out how to do it manually though
<persia> ddecator: Um, OK.  I think that you'd do much better to explore other existing packages for that, rather than trying to do it from scratch.
<ddecator> any suggestions?
<persia> Go find some bugs, and investigate them.  Pull the relevant sources.  Explore.  If they look like they can be fixed with packaging (fail to upgrade are common cases for this), try changing stuff.
<ddecator> alright...thanks persia =)
<lfaraone> persia: aha. upstream only ships a desktop.in file!
<persia> lfaraone: Aha!  That's fine, but the upstream build system shouldn't be updating it on clean, which seems like the candidate culprit.
<persia> Unless something else is happening deep within CDBS.
<lfaraone> persia: well, now it's dh7 :)
<lfaraone> persia: same problem.
<persia> Well, same issue.  Either upstream is updating it on clean, or something else is happening deep within dh.
<persia> pastebin the source build log with DH_VERBOSE=1?
<lfaraone> persia: you're right, it happens on clean.
<persia> lfaraone: So, it probably ought happen on build.  Having clean make it less clean just seems wrong somehow.
<lfaraone> persia: right again. it's a python package, so there's something wrong with setup.py
<lfaraone> looks like they run it regardless of what command is run.
<lfaraone> persia: code in question: http://sprunge.us/EeZG?python lines 39 to 45
<persia> Um, and this gets back to my plan to learn how python works :)
<lfaraone> persia: setup.py is widely regarded as black magic.
<lfaraone> if you consider wide to be {lfaraone}
<persia> Well, some people say that about make, which I find trivial.  I think it depends on your background.
 * ScottK finds setup.py generally pretty accessible.
<persia> ScottK: Any idea why the .desktop file is reconstructed on clean for groundcontrol on REVU?
<ScottK> persia: Nope.  Haven't looked.
<mok0> jdong: ping
<suji11> how to create man page?
<suji11> Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok
<slytherin> geser: FYI ... libpdfbox-java merge is done.
<dholbach> good morning
<ivoks> morning
<dholbach> hey ivoks
<ivoks> what's up daniel?
<suji11> Anyone Advocate/Review my package IOK http://revu.ubuntuwire.com/p/iok
<dholbach> ivoks: how are you doing?
<ivoks> dholbach: fine, trying to implement two blueprints :)
<ivoks> dholbach: you?
<dholbach> ivoks: still a bit jetlagged, but I'm OK - and my luggage is supposed to arrive later today - YAY! :)
<ivoks> dholbach: good luck with those; in dallas, i had to pick up my luaggage and i did that 2 days before departure :)
<dholbach> ivoks: in Berlin it usually arrives the day later and they call you in advance to tell you they bring it - worked for me the last 3 times :)
<ivoks> nice :)
<dholbach> yeah, I'm grateful it always happened to me on the way back and not when I was going somewhere :)
<ivoks> hehe
<crimsun> heh, good thing I didn't do the corosync merge ;)
<ivoks> crimsun: yeah, don't touch it :D
<crimsun> ivoks: it would have been done at least a month ago, but I pinged chuck about it first.  good thing.
<dholbach> do we have a revu hacker here? http://revu.ubuntuwire.com/p/zope.index gets redirected to http://revu.ubuntuwire.com/p/zope. which makes reviewing the package a bit hard!
<TiMiDo> hey i have a question i was wondering if i can port up BitchX
<crimsun> meaning take on maintainership of it? The best place to do it is probably in Debian; see Debian #451373
<ubottu> Debian bug 451373 in ftp.debian.org "RM: ircii-pana -- RoQA; security issues, abandoned upstream, unmainted" [Normal,Open] http://bugs.debian.org/451373
<TiMiDo> well bx is back up and i'm one of there Developers
<crimsun> again, the best place to take it up again is in Debian
<TiMiDo> all those bugs are Fixed.
<TiMiDo> =)
<crimsun> great. Makes sense to prepare an upload to Sid, then.
<TiMiDo> it's almost there =
<Linux-CLI> hi
<Linux-CLI> I'm having some trouble with my debian files
<Linux-CLI> (trying to package a .deb)
<Linux-CLI> Can I have a copy of your 'rules' file, please?
<slytherin> Linux-CLI: Instead tell us what the problem is and we will try to solve it.
<TiMiDo> Linux-CLI, lol why would you need another packages rules?
<TiMiDo> that's seems odd.
<Linux-CLI> slytherin & TiMiDo: I'll try one last time...
<TiMiDo> last time of?
<Linux-CLI> TiMiDo: Attempting without help :P
<Linux-CLI> :p
 * Linux-CLI is installing devscripts
 * Linux-CLI is [still] installing devscripts (1min & 40secs)
<Linux-CLI> (took 5min, installing now)
<TiMiDo> cool
<TiMiDo> did it .... finish?
<TiMiDo> with 0 errors?
<Linux-CLI> Nope
<Linux-CLI> Could you please help me? - Here is my Terminal output: http://pastebin.com/d3b20a4ff
 * Linux-CLI is uploading his /debian/ folder
<persia> Linux-CLI: Upstream doesn't appear to provide a clean rule in the makefile.  Either another rule needs to be called, upstream needs to be fixed, another build system used, or cleanup done manually.
<Linux-CLI> How do I do cleanup manually?
<Linux-CLI> Also, do you know of a good free hosting site where I can put my tar.gz?
<Linux-CLI> (just the /debian/ folder)
<Linux-CLI> http://www.mediafire.com/?tjni1zzm2mj
<Linux-CLI> ^There is the copy of my /debian/ folder
<Linux-CLI> (Within the program directory)
<persia> You can do whatever clean needs to do in the clean rule in debian/rules.
<Linux-CLI> What type of clean is required?
<persia> Ideally, it should put the source back into the state it was in prior to the build.
<Linux-CLI> I don't understand
<Linux-CLI> Can you show me an example of that type of rules file?
<persia> I don't know of one offhand, but it's usually a number of -rm calls.
<Linux-CLI> persia: I understand that the rules file needs to clean the source, reverting the source back to its prior state. Could you please take a look at my /debian/ subdirectory, and tell me what else needs to be changed?
<Linux-CLI> persia: So it's just to install
<persia> What?
<Linux-CLI> persia: So it's just to uninstall
<persia> apparently I can't look: attempting to see your debian/ folder shows me a poker advertisement.
<persia> No, it's clean.  Has almost nothing to do with install.  Local stuff created during build.
<Linux-CLI> persia: How about an xdcc?
<Linux-CLI> 2KB btw
<Linux-CLI> http://uploading.com/files/f6666e9e/debian.tar.gz/
<persia> I'm not sure that works through the chain of bots and proxies I use to interact with communication services.
<persia> That one takes me to a picture of an underdressed woman and a heap of text in a language I don't read.
<persia> I'm not going to click on any more of your URLs.
<Linux-CLI> Well it sounds like you're not recommending anyway for me to give you the files.
<Linux-CLI> Goodbye.
<persia> Bother.  I don't mean to be rude, I'm just tired and insufficiently motivated to do a review of a known broken package right now.
<ogra> persia, bah, it doesnt take me to a naked woman !
<persia> ogra: I didn't say "naked": she was in her underwear.  But I'm not surprised, as it seems to have extensive geolocation logic.
<ogra> indeed, the ad changed for me
<persia> So different places probably get different images, depending on local tolerances.
<ogra> i can buy an iphone instead :)
<ogra> its an upload service that keeps the upload for 30sec btw ...
<ogra> err, "keeps you from getting the upload"
<persia> So you can look at the advertisements?  Aha!
<ogra> right, it puts up an ad that stays for 30sec before you can download the referred file
<persia> The first one might have been the same thing.  I'm not sure I waited long enough.
 * persia goes back to figuring out how to use a mandonline and lets backscroll accumulate
<\sh> persia: "use a mandonline" you mean "mandoline"?
<coolbhavi> hello I just reinstalled my system and i m getting a secret key not found error http://paste.ubuntu.com/371550/
<coolbhavi>  I made a new key and uploaded it to lp
<coolbhavi>   http://paste.ubuntu.com/371551/ <-- my .bashrc
<coolbhavi> i sourced .bashrc too
<coolbhavi> any ideas?
<persia> rsajdok: I just write what it says on the labeling.  It's for cutting stuff.  Nifty, but the conclusion was to not cut stuff for this next meal :)
<suji11> hi i'm creating man page for my package, here also any restriction for description like control file.
<persia> Could you rephrase the question?
<suji11> ya, in control file in description each line should be less than 75 characters, like that the man page description also each line should be less than 75 characters or any other condtions?
<persia> I tend to prefer that all text files in source be less than 75 characters, as it makes it easier to quote chunks of stuff in email, etc.
<persia> I don't think it's a firm rule though.  Just make sure you can parse it cleanly with nroff -man in a regular terminal.
<suji11> ok
<ScottK> james_w: Would you please have another look at 517161.  At least if I'm reading Launchpad right the "and move it to Multiverse" part of the bug doesn't seem to have been done.
<james_w> ScottK: it hasn't, I missed that as it was requesting something that had already happened
<james_w> done now
<ScottK> james_w: Thanks.
<corecode> hey
<corecode> i'm wondering how to submit a bugfix to a package
<corecode> i generated the source deb, should i just attach the .diff.gz to the bug report?
<persia> corecode: Generally we prefer the output of the debdiff between the current version in the archive and your new candidate version.
<persia> The exception would be for upstream version upgrades, where this gets extremely noisy.
<corecode> okay
<corecode> i just realized it is a main package, but the process will be the same
<persia> Yeah, except you would have asked in #ubuntu-devel, and I would have answered the same way :)
<persia> Remember to subscribe ubuntu-main-sponsors to the bug once you've attached the patch.  We7re always looking for better ways to track that, but haven't found a clean one yet.
<EagleScreen> corecode: please read this guide https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
<corecode> doing so, thanks
<corecode> so what do i do to get this processed?  should i just wait or contact somebody?
<ScottK> Once you subscribe the appropriate sponsorship team to the bug, then you just wait.
<corecode> i see
<corecode> reading the wiki page, i'm not sure how to submit it for sponsorship
<slytherin> corecode: in launchpad bug, click 'subscribe someone else' and then search for ubuntu-main-sponsors
<corecode> ah
<corecode> thanks!
<corecode> because the wiki page says "don't subscribe anybody if the bug needs sponsorship"
<slytherin> that is surely wrong
<corecode> great, thanks
<corecode> the workflow in ubuntu is so easy to use, it is a real joy
<corecode> coming from bsd's packaging...
<corecode> "Do not assign a bug to anyone if it needs sponsorship. "
<corecode> is the wording
<ScottK> corecode: Assign is different than subscribe.
<ScottK> Subscribe is the right thing to do.
<corecode> ah
<Q-FUNK> could anyone with core-dev upload priviledges please act on bug #493628 ?
<ubottu> Launchpad bug 493628 in mozvoikko "Please merge mozvoikko-1.0-4 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/493628
<Q-FUNK> this one goes to main, so I cannot do anthing about it myself.
<Laney> What's the proper way to record copyright status of a PD work in DEP5?
<Laney> Copyright: none?
<persia> Q-FUNK: You might want to ask in -devel for stuff that needs main, as many folk here also don't have that access.
<Q-FUNK> ok, will do
<persia> Laney: License: PD, etc.
<persia> Laney: But note that PD isn't valid in all jurisdictions, and has different requirements in different jurisdictions.  It can be quite hard to properly document and demonstrate that something is truly PD.
<persia> I'd drop the Copyright: header for that license, but, again, this isn't valid in some places: better to identify the copyright holder, if possible, and document that copyright has expired or is explicitly not claimed, or similar.
<Laney> persia: This is just a simple shell script that I took from another source package (from the debian/ directory, even). I don't expect it to be contentious.
<Laney> "If the work is truly public domain, this should be stated in the copyright field." from DEP5
 * Laney will just explain a little
<persia> It's unlikely that anything in a debian/ directory is in the public domain, unless the authors are from specific locations that still permit it (public domain requires lots more time than Debian has had in any jurisdiction where the Berne convention applies).
<persia> Doesn't mean the authors don't think it is, of course :)
<Laney> :)
<dholbach> any revu hackers here?
<persia> What do you need?  I'm not a REVU hacker, but I'm a REVU admin, so can do some stuff.
<dholbach> http://revu.ubuntuwire.com/p/zope.index gets redirected to http://revu.ubuntuwire.com/p/zope.
<dholbach> which doesn't help reviewing it :)
<persia> pull-revu-source might work.
<Laney> you should file a bug on lp/revu
<persia> But yeah, file a bug.
 * persia can't fix that: requires coding hackery, or at least webserver config hackery
<Laney> can you see what the httpd logs say about the request?
<dholbach> bug 518827
<ubottu> Launchpad bug 518827 in revu "http://revu.ubuntuwire.com/p/zope.index unreviewable ("index" removed from URL)" [Undecided,New] https://launchpad.net/bugs/518827
 * persia tries
 * Laney has access to that box, but no permissions to view logs
<persia> Laney: I don't have sufficient permission to view the logs either.
<persia> I suspect we're hitting some URL rewriting rule though, from the observed behaviour.
<BlackZ> hi persia ;)
<dholbach> htaccess.tmpl:#Get rid of "index" in directories:    <--   maybe?
<Laney> sounds suspicious
<dholbach> anyway, I managed to get the source which helped :)
<persia> Submitted patches tend to get applied fairly smoothly.  I don't remember if there is a current staging server running though.
<dholbach> I'm sorry, I don't have time for setting up a REVU instance and patching it now
<persia> Heh.  Understood :)
<statik> hello
<statik> where is the current Standards-Version defined?
<statik> I'm getting lintian warnings on debian packages that want Standards-Version: 3.8.4, but my lucid stuff seems to want to be at 3.8.3
<persia> statik: That's hard to say precisely.  I tend to believe that the current version of the ubuntu-policy package represents the current standards version, but you may do as well with the current version of the debian-policy package, in case ubuntu-policy hasn't been updated recently.
<statik> persia, thanks! i'll dig into those packages
<persia> statik: Where do you see the warnings?
<statik> persia, lintian I think
<persia> statik: dpkg -l or apt-cache show ... | Version is likely a good way to check, rather than heavier digging.
<persia> Which lintian?
<statik> on mentors.debian.net it wants 3.8.4. when I build locally on lucid, lintian wants 3.8.3
<persia> Well then :)  That tells you the versions of policy supported by lintian on mentors and lucid :)
<statik> persia, yep, I already knew that. my question was where/how is it defined :)
<persia> I doubt that many 3.8.4 compliant packages won't be 3.8.3 compliant in sufficiently significant ways to break lucid though :)
<statik> yeah, i hope so
<persia> Well, ask yourself a different question: Are you able to construct a package that is both 3.8.2 and 3.8.4 compliant?
<statik> so this is weird, http://packages.debian.org/search?keywords=debian-policy is at 3.8.3 also. I wonder where 3.8.4 comes from
<persia> It's in sid.
<slytherin> statik: Standards version is as known to the lintian version on your machine. Usually lintian is updated after policy is updated.
<persia> More than usually.  Always.  It's not possible to check compliance against unspecified policy.
<slytherin> sid has policy version 3.8.4 and also lintian that knows about this policy.
<statik> ah, so this page is outdated? http://packages.debian.org/sid/debian-policy it shows 3.8.3
<slytherin> checking
 * persia generally finds packages.${distro} to be out-of-date in all cases
<Rhonda> statik: There is issues with the harddisk on packages.debian.org, currently worked on.
<slytherin> statik: yes it is outdated. there seems to be problem for last few days. A more updated information is available here - http://packages.qa.debian.org/d/debian-policy.html
<Rhonda> persia: It's even in testing already. :)
<statik> thanks! i have learned a lot in just 5 minutes, I'm glad I asked
<persia> Rhonda: See, this is why I should be using rmadison rather than apt-cache show :)
<Rhonda> ;)
<slytherin> And this problem is causing issues with requestsync tool when trying to request sync against package form unstable (instead of squeeze).
<slytherin> requestsync detects version but can not retrieve changelog of latest version.
<Rhonda> damnit. How many time do I have to fix 518829 for lucid?
<Laney> Does anyone have access to an {hppa,kfreebsd-i386,ppc,s390} box with a sid environment, and the inclination to run a test build for me? :)
 * persia can do sid/ppc, but will have some latency reporting results if the build takes longer than 20 minutes.
<Laney> I just want to know if it starts really
<persia> OK.  Where is it?
<Laney> persia: git://git.debian.org/git/collab-maint/agda-stdlib.git (or I can sort out the source package if you want it)
<persia> If you give me something to dget, I don't have to think about it, which I like :)
<Laney> ok
<Laney> persia: http://orangesquash.org.uk/~laney/agda-stdlib/agda-stdlib_0.3-2.dsc
<Laney> as long as it gets past https://buildd.debian.org/fetch.cgi?pkg=agda-stdlib&arch=powerpc&ver=0.3-1&stamp=1265532637&file=log&as=raw and starts typechecking then I'll be happy
<persia> Laney: http://paste.ubuntu.com/371732/
<Laney> erm
<Laney> I think I'd call that an external problem :)
<Laney> thanks persia
<persia> Laney: Yeah.  Doesn't really look like your script, but I built my chroot with debootstrap --variant=buildd and would expect a simiar model for other folk.
<persia> Laney: Do you really need whatever pulls exim to build?
<Laney> I don't even see exim being pulled in
<ScottK> If so, it should pull in Postfix in any case.
<ScottK> or default-mta
<Laney> and no, most definitely not
<persia> ScottK: For sid?
<ScottK> persia: Oh, sorry.
<ScottK> default-mta is good
<ScottK> exim4 provides that in Debian
<Laney> I wonder where that problem actually came from
<Laney> it's before anything got installed
<Laney> could be a broken chroot; can you build other packages with it?
<persia> I could recently, but I dist-upgrade daily.  I'll check.
<persia> Laney: Hrm.  Seems my chroot is indeed broken.  I'll sort it in the morning, and let you know (unless you find someone else to do a build sooner).
<\sh> wth is the "bug elevation team"?
<ddecator> \sh, ignore that
<ddecator> \sh, some guy over the weekend made that team and invited a whole bunch of others to join, nobody knows why so they're trying to figure out what is going on
<\sh> ddecator: grmpf...
<dholbach> sistpoty|work, RainCT: good work on the fix!
<sistpoty|work> dholbach: thanks for the bug report :)
<dholbach> no worries
<dholbach> that'll help to get schooltool into lucid, let's hope we get it done :)
<slytherin> Laney: If you are still looking for a ppc build test I will be able to do that in an hour.
<bddebian> Heya gang
<bjsnider> siretart, ping
<siretart> bjsnider: please ping again in 1h
<sebner> huhu bddebian siretart sistpoty|work dholbach \sh :D
<sistpoty|work> hi sebner
<sistpoty|work> hi bddebian
<bddebian> Heya sebner, sistpoty|work
<fagan> hmmm has anyone tried packaging songbird yet?
<fagan> or looked into it
<micahg> fagan: yes
<fagan> its not in the repos
<micahg> we have dailies, but are broke at the moment
<micahg> fagan: there are several upstream bugs that need to be fixed before it can get into repos
<fagan> micahg: could we put the stable version though?
<micahg> fagan: no, there are upstream bugs wrt packaging in Ubuntu
<fagan> ah ok
<hyperair> what are the issues?
<sebner> hola hyperair :)
<hyperair> hola sebner :)
<fagan> micahg: have the bugs been reported on their bugzilla?
<micahg> fagan: yes
<micahg> bug 94494
<ubottu> Launchpad bug 94494 in songbird "[needs-packaging] Songbird" [Unknown,Confirmed] https://launchpad.net/bugs/94494
<fagan> micahg: how long do we have before the archive freeze to get it in
<micahg> fagan: not going to happen this cycle
<micahg> hopefully lucid +1
<fagan> ah ok I was thinking of chasing it up myself
<micahg> fagan: I hope to have to dailies back up before Lucid is released though
<micahg> fagan: songbird 17708
<micahg> hmm..that should be a registered tracker...
<hyperair> banshee ftw.
 * hyperair hides
<micahg> fagan: http://bugzilla.songbirdnest.com/show_bug.cgi?id=17708
<ubottu> bugzilla.songbirdnest.com bug 17708 in Platform: XULRunner "[xr] Upstream all XULRunner patches" [Major,New]
<fagan> micahg: thanks
<micahg> fagan: also, it won't build w/system sqlite anymore...
<fagan> so they are after patching xul to get songbird working and didnt upstream it
<micahg> fagan: yeah
<fagan> micahg: well thats dumb
<micahg> fagan: any further discussion probably should be in #ubuntu-mozillateam as this is OT for this channel
<fagan> true
<siretart> bjsnider: sorry, need to run home now. please write mail
<sebner> bddebian: any thoughts on http://pastebin.com/m27558410  ?
<anilg> Hi All
<anilg> I'm a developer on the Nexenta Project (an Ubuntu port on opensolaris), and we are looking to hire folks well versed with ubuntu packaging.. is there a list I can post to reach interested ubuntu MOTUs?
<azeem_> (there's debian-jobs@lists.debian.org as well, assuming that folks well versed in Debian packaging would be interesting as well)
<anilg> azeem_: thanks, I'll ping there as well.. but ubuntu MOTUs would be perfect, as Nexenta is a port of Ubuntu
<azeem_> anilg: anyway, is Nexenta a company? The website is a .org...
<anilg> there's .com as well
<azeem_> I tried that first, but it didn't look related
<azeem_> "Enterprise class OpenStorage"?
<anilg> A storage distribution on top of Nexenta
<anilg> with commercial support
<azeem_> oh
<azeem_> so this company is looking for folks, or the Nexenta project?
<azeem_> or is the company looking for folks to work on the Nexenta project?
<anilg> Well the company is the sponsor of the Project :) So the company will pay for work to be done on the project
<azeem_> ok
<azeem_> anilg: so you're an employee?
<azeem_> just curious :)
<anilg> yes
<anilg> I'm one of the Nexenta developers
<azeem_> are there a lot of non-company people working on the Nexenta project?
<azeem_> cool
<anilg> yes.. usually they join comtribute for a while and lay low again
<anilg> So what is the best way to reach Ubuntu MOTUs for this? (apart from this channel)
<anilg> I was hoping there was a ubuntu-jobs list
<azeem_> well, maybe there is, I don't have a good overview over all the lists
<azeem_> I know about debian-jobs because I'm subscribed on it :)
<geser> anilg: there is ubuntu-motu@lists.ubuntu.com but it's probably not the right list for job offers
<anilg> geser: Yes i figured as much.. so wanted to confirm here before
<anilg> how about a "meta" mail to this list .. "can you point me to the Jobs list"? :p
<hyperair> anyone from motu-sru feel like looking into a borked bansheelyricsplugin which crashes banshee consistently on karmic? fixed in lucid, patch attached for karmic.
<hyperair> bug #511868
<ubottu> Launchpad bug 511868 in bansheelyricsplugin "Crash when click on lirycs" [Undecided,Confirmed] https://launchpad.net/bugs/511868
<geser> hyperair: motu-sru got merged into ubuntu-sru
<hyperair> eh?
<hyperair> seriously?
<hyperair> hmm
 * hyperair subscribes ubuntu-sru then
<geser> hyperair: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-December/000650.html
<hyperair> geser: thanks
<dupondje> how to make a dpatch exactly for in the debian/patches folder ?
<geser> dpatch-edit-patch
<_stink_> question about pbuilder: i have a .pbuilderrc that sets up some shell variables used to rename the tarball/results directories.  i also have a script in my hook directory in which i'd like to use those same shell variables, but it seems like they're not getting "passed" to the hook script.  any idea how to do this?
<_stink_> aha!  gotta export it in .pbuilderrc.
<rmunn> Question about the Lucid release schedule: I have a new package up at http://revu.ubuntuwire.com/p/python-nltk waiting for advocates. To get it into Lucid, do I have to get two advocates before the Feature Freeze (Feb. 18th)? Or is the fact that it went onto REVU before Feature Freeze enough, even if the package only picks up advocates after Feature Freeze?
<rmunn> NLTK is apparently a rather famous library in its field (computational linguistics), and there's been an O'Reilly book about it (http://oreilly.com/catalog/9780596516499) so I'd like to get it into Lucid if I can. The package looks good from what others have said about it, it just needs MOTU advocates.
<crimsun> rmunn: please ping me in one hour if no one else has looked at it yet.
<rmunn> crimsun: Will do.
<crimsun> rmunn: thanks
<dooooomi> hi, i'm looking for someone to review gtklick, a metronome for JACK: http://revu.ubuntuwire.com/p/gtklick
<dooooomi> also, klick (the command line version) could use another review: http://revu.ubuntuwire.com/p/klick
<geser> rmunn: python-nltk fails to build: ImportError: No module named yaml
<jcfp> rmunn: added a few comments for python-nltk
<rmunn> python-yaml is in Depends, does Build-Depends not inherit from Depends?
<dupondje> ok, I created a dpatch, added it in debian/00list, now whats next ? dch -i (is there some specific layout for a patch update ?) and then a debdiff ?
<rmunn> I assumed that Build-Depends would be a superset of Depends.
<geser> rmunn: no, Depends is for runtime dependencies
<geser> and a package can have totally different runtime and build dependencies
<rmunn> Right, I'll need to upload a new version of the source package then.
<geser> rmunn: why is there a Java .jar inside the python-nltk package?
<rmunn> I was just looking at that... it's part of the upstream nltk-2.0b8 release, and I think it can probably be removed
<rmunn> The upstream release includes a javasrc/ directory that looks like it contains the source to that nltk.jar file, so I'm guessing nltk.jar can be removed from the python-nltk source package and a separate package created for the Java stuff.
<geser> yes (if there is need for it)
<rmunn> I missed this earlier when I looked at the package (and here I was so proud of my detailed examination, catching all the different licenses for the debian/copyright file... *blush*)
<asbin> Hi, I'm looking for someone to review my package "ushare", it's not a major change and it closes 3 LP bugs ...
<randomaction> asbin: https://wiki.ubuntu.com/SponsorshipProcess
<asbin> randomaction: thanks ! I've never uploaded a new version of an existing package ...
<randomaction> yep, it's much easier
<asbin> on the other side, I have 4 more (new) packages to review ... is it the right place ?
<asbin> I'm looking for someone to review 3 new packages : libnfo, libplayer, and libvalhalla (libvalhalla needs libnfo to build ...). Thanks !
<petski> Nine months ago I've submitted a patch to resolve a bug (LP: 371103). My patch was added in Karmic (which was the devel-release at that time), but was never included in Jaunty. Still, nine month later, no single response from motu-sru. Maybe the bug status is wrong for some motu-sru attention?
<kklimonda> bug 371103
<ubottu> Launchpad bug 371103 in amsn "aMSN fails to launch when msntranslator or gnotify plugin is used" [Undecided,Confirmed] https://launchpad.net/bugs/371103
<kklimonda> petski, afair the process has changed recently - now you first subscribe sponsors, they upload package to -proposed and SRU team accepts it
<petski> thanks kklimonda, just subscribed ubuntu-universe-sponsors
<petski> now let's wait for nine months again to see what happens :P
<Zelut> I just uploaded the latest release of my project. Is it too late to have the package updated for Lucid?
<randomaction> Zelut: no it's not, new features are accepted until Feb 18th: https://wiki.ubuntu.com/LucidReleaseSchedule
<Zelut> great.
<Zelut> I'm no packager so I'll need someone to pull it in for me. It is already packaged in Lucid, just dated, so I'm sure it'll be easy.
<randomaction> Zelut: does your package have a maintainer? You might want to ping them so that they prepare a new version before the freeze, it's not like there's much time left.
<Zelut> randomaction: i don't think the maintainer i worked with last is still around..
<hakaishi> Hi everyone! Would anyone please advocate/review qt-shutdown-p? http://revu.ubuntuwire.com/p/qt-shutdown-p
<hakaishi> ... because the deadline is drawing nearer, isn't it? https://wiki.ubuntu.com/LucidReleaseSchedule
<lfaraone> Hey, does anybody have time to do a quick REVU of a package? http://revu.ubuntuwire.com/details.py?upid=7621
<rmunn> Well here's an interesting situation. I'm going to have to either remove functionality from upstream's version of the package or else delay it past the Lucid freeze date.
<lfaraone> rmunn: why's that?
<rmunn> Reasons why are kind of long, so I'll just link to http://revu.ubuntuwire.com/details.py?upid=7593&deletecomment=7550 rather than repeat it here.
<rmunn> Basically, they include a binary .jar file that I can't recreate from source because its dependencies aren't in Debian.
<rmunn> It's all open-source so they're not breaking any licenses, or even the DFSG as far as I can tell, but it does present a problem for my creating a python-nltk package for Ubuntu.
<lfaraone> rmunn: are all the binaries in upstream's package accompanied with source?
<rmunn> I don't think it's acceptable to have binaries in the source package (how do you prove they aren't Trojaned?), so that means either removing the offending .jar and the functionality that depends on it (integration with Mallet), or else delaying until Lucid+1.
<rmunn> lfaraone: Yes
<lfaraone> rmunn: just repack mallet removing the binaries and give the package a "dfsg" extention.
<rmunn> Upstream's tarball includes three .java files, and a .jar that's just those three files compiled. Problem is that they depend on mallet, which isn't avialable in Debian right now.
<rmunn> lfaraone: Mallet is >10 megs, and I don't know Java enough to be certain I'd get everything right. I can try, but I'm not sure I'll make the Feature Freeze.
<lfaraone> rmunn: sorry, I mean does Mallet have source in their upstream tarball?
<lfaraone> rmunn: well, if it's between removing the package and losing a feature, I'd go for the latter short term.
<rmunn> lfaraone: Ah, I see. I believe the answer is yes (they're an open-source project), but I'll double-check.
<rmunn> lfaraone: Likewise, and I've told upstream about my intentions: "Remove Mallet support to get it into Lucid, put Mallet support back in Lucid+1".
<lfaraone> rmunn: if mallet uses ant, CDBS has you covered :)
<rmunn> lfaraone: Yeah, mallet uses ant. But it's been years since I've touched Java, not to mention I'm pretty new to Debian packaging. I'm going to make lots of newbie mistakes... :-)
<lfaraone> jono: hi, doctormo told me you'd agreed to sponsor groundcontrol. it currently depends on python-xdgapp, which is in REVU. do you have a chance to take a look at it?
<lfaraone> rmunn: ... and when you do, we're here to help!
<lfaraone> (just not me personally, I try to avoid java too :)
<rmunn> Guess I'm going to be asking lots of questions on #ubuntu-java, then.
<jono> lfaraone, I am not sponsoring it myself, I am not a MOTU
<jono> lfaraone, I am just trying to help doctormo be successful as part of a wider opportunistic developer project in Ubuntu
<lfaraone> jono: mk. we have two packages to get reviewed and push through REVU before feature freeze, then :)
<jono> lfaraone, :)
<jono> is this something you can help coordinate?
<lfaraone> jono: well, I built the packages and am willing to respond to any problems with them.
<Zelut> nhandler: ping
<nhandler> Zelut: Pong
<Zelut> nhandler: haven't heard back from you on my last email regarding origami. think you can help get it updated for Lucid?
<nhandler> Zelut: Ah yes. Let me look at it now
<Zelut> nhandler: I just pushed 0.7.3 to the upstream download page. should be simple to update the package from 0.7.1.6 (or whatever it is that is packaged)
#ubuntu-motu 2010-02-09
<LimCore> Im patching a semi-broken security in svn. Anyone wants to give me a hand about the tools to quickly rebuild&test (hand holding ;)
<kklimonda> LimCore, what do you mean by "quickly rebuild&test"?
<kklimonda> LimCore, ccache would probably speed up rebuilding
<LimCore> well, I have very limited time, so I hoped I will do what I do well (fix this bug, assuming the code base is readable) and someone will help me build/test/and all other ubuntu specyfic stuff
<LimCore> upsteam uses variable names like "b". No, its not for index variable. Neat
<PackThis> hi
<PackThis> Looking for either the "Debian New Maintainers' Guide" or a different Debian package creation guide in a fully-downloadable format, eg; HTML
<PackThis> Could you please provide a link/command to one?
<freeflying> persia: ping
<dholbach> good morning
<OdyX> Hi MOTUs, I just filed a requestsync for usb-modeswitch (#519216), which needs sponsorship from you (if I understood it correctly). Could anyone take a look after it ?
<geser> OdyX: Acked
<OdyX> geser: great. Thanks.
<Rhonda> Is there something like "bts" for launchpad?
<jpds> Rhonda: Launchpad bugs in Launchpad?
<Rhonda> i.e., a soap interface or commandline query client?
<Rhonda> jpds: Yes.
<jpds> There's an API for Launchpad.
<jpds> Rhonda: https://help.launchpad.net/API
<Rhonda> That sounds like there isn't a tool yet, right?
<dholbach> and there's https://launchpad.net/bughugger
<Rhonda> jpds, dholbach: Thanks. :)
<dholbach> no worries
<phek> when using dpkg-buildpackage is there a way to restart it from a specific step?  (there was an error in my make install)
<geser> dpkg-buildpackage -b -nc
<persia> Note that this doesn't always behave entirely as expected, depending on the names of various files and various rules.
<phek> hmm, ok
<phek> i'm guessing i also need -rfakeroot too if my original build was using it right?  (this package takes about 5 hours to build so i really don't want to end up starting all over)
<phek> guess i can just make a backup copy and give it a try
<persia> phek: Aside from the -nc, you'll want to use all the same options.
<persia> -nc just doesn't run debian/rules clean
<phek> ok cool.  thanks
<phek> now i'm getting an architecture error (now that i'm doing -b -nc which seems strange).  dpkg-gencontrol: error: current host architecture 'powerpc' does not appear in package's architecture list (cell)
<azeem_> cell?
<phek> well, i use -mtune=cell -mcpu=cell during the configure (this is on a ps3)
<azeem_> that wouldn't make dpkg to think you're trying to build for cell
<azeem_> pastebin your debian/control
<phek> k
<azeem_> phek: and the output of "dpkg-architecture"
<phek> https://www.securepaste.com/decrypt_data.php?id=5e2r597m&password=2Y81h
<phek> thats the control and i just noticed that cell is the architecture:
<azeem_> that'd be it
<phek> https://www.securepaste.com/decrypt_data.php?id=79wcD&password=2Y81h
<phek> OK, i guess as long as i can keep the optimizations it's fine to change it
<azeem_> is this a new package?
<azeem_> change it to what?
<phek> yeah
<phek> change the control Architecture line to powerpc
<azeem_> does it compile on amd64?
<phek> the software does, but with the optimizations it would probably crash
<phek> (using the cell optimizations)
<phek> which i guess is obvious
<azeem_> eh, you're putting the optimizations into debian/rules?
<phek> yeah
<azeem_> using a if statement to check for powerpc I hope?
<suji11> hi
<phek> nope. probably would have been a good idea
<azeem_> yes
<azeem_> then the package wouldn't be powerpc-specific and you can set Architecture: to any, as it should be
<suji11> i need help to create a debian package for hunspell-ta , i'm having the dictionary file and aff file
<paissad> hi all, i am packaging a software for debian, i have already uploaded to mentors-debian.net ... & i'm waiting for a mentor to handle, but i would like to make the .deb package available for ubuntu too ..... i've totally followed the debian policy ... what must i do now for ubuntu ?
<sistpoty|work> phek: ooi, does -mcpu=cell make that much difference?
<phek> sistpoty|work, yeah.  well either that or the -O2 does.  but full screen with that package and no optimizations is almost unusable
<paissad> meanwhile, i would like to create a wiki in ubuntu website where i could give instructions about installing that software
<phek> sistpoty|work, but with the optimizatioins its usuable
<azeem_> the regular package should use -O2 already
<paissad> here is the soft -> http://code.google.com/p/ps3mediaserver/
<sistpoty|work> phek: interesting. wouldn't have thought that
<phek> azeem_, there's no regular package for this.  the 1.51 version couldn't do full screen at all due to some file permissions thing.
<azeem_> sistpoty|work: well, if it's an emulator, it might take advantage of advanced platform features
<phek> (there's a package for 1.51)
<azeem_> phek: then I suggest you test yourself with and without the -mcpu=cell and see whether that's it
<sistpoty|work> azeem_: afaict cell is a ppc + 8 spu's (good at floating point, but extremely hard to program), so I didn't expect that gcc could automatically optimize the code to make use of the spus...
<phek> yeah, i may do that.  like i said it takes 5 hours to install (at least) so it's not something i can just spend 10 minutes testing
<azeem_> sistpoty|work: it might just turn on altivec
<azeem_> as opposed to the regular GCC -O2
<sistpoty|work> azeem_: ah, right. had totally forgotten about altivec, thanks
<azeem_> phek: to *install*
<azeem_> ?
<phek> err i mean build
<azeem_> ok
<proppy> Hi, I updated the bug report asking for sync of poker-network in lucid, because a new version was recently uploaded to debian
<proppy> https://bugs.edge.launchpad.net/ubuntu/+source/poker-network/+bug/509677
<ubottu> Ubuntu bug 509677 in poker-network "Please sync poker-network 1.7.7-1 from unstable to lucid" [Undecided,New]
<proppy> let me know if it needs more informations
<Laney> slytherin: hi, did you have a chance to try that ppc build?
<slytherin> Laney: No. I couldn't get online yesterday due to some problem on ISP side. Iwill try today if you want.
<Laney> if you get some free time, please
<slytherin> sure
<slytherin> Laney: Can you please send a link of the .dsc file to my email address? I do not have yesterday's logs. https://edge.launchpad.net/~onkarshinde
<Laney> sure, here goes
<slytherin> got to go now. Going home.
<Laney> there you go
<Laney> see you later
<sebner> Laney: ~oÂ¨
 * Laney pounces on sebner
 * sebner hides
<phek> well, guess i one of those unexpected behaviors from using -b -nc
<oojah> Laney: I've addressed your comments on sqlite3-pcre, would you be able to take another look at it when you get a chance please?
<persia> oojah: You'll end up with a much better package if you get lots of different reviewers, rather than chasing people who reviewed it before.
<hyperair> persia: do MOTU applications via DMB require announcing on developer-membership-board@l.u.c
<hyperair> ?
<oojah> persia: I'm sure you're right.
 * hyperair is still wondering when exactly the next DMB meeting is
<persia> hyperair: No.  I'm not sure precisely how it does work, but https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess is likely your best guideline.
<persia> Next Tuesday.
<hyperair> hmm tuesday
<persia> At 14:00 UTC, so late for you.
<hyperair> 2200 my time.
<hyperair> perfect.
<hyperair> i'm spending most of the day in a bus
<geser> persia: not 15 UTC?
<hyperair> my chinese new year break ends on tuesday so i have to scramble back across the country to campus
<persia> geser: Oh, right.  15 UTC.
<hyperair> 2300 local time. still great =D
 * hyperair is nocturnal anyway
<Laney> oojah: A get-orig-source target which reconstructs the .orig.tar.gz from upstream's git repo would be nice
<Laney> (but not essential)
<Laney> I can look maybe later if you don't find anyone else
 * oojah nods
<oojah> I'll look into that and repost later, thanks.
<oojah> How can I find out the package version that is currently being built for a get-orig-source rule?
<persia> oojah: You can't usefully.  The semantics of get-orig-source are such that it always gets the *newest* available version.  Depending on how usptream releases, you may be able to use hints from tarball names, VCS tags, or similar.
<persia> But, except in the case of tarball names, it may be tricky to determine the version that will be pulled in advance of pulling it.
<persia> (with tarballs, uscan does an admirable job)
<umang> Hi, I have a new package that was just uploaded to sid a few minutes back. I just wanted to know, is the Import Freeze day after for sid or testing? (There seem to be conflicting information on the wiki).
<umang> Also, if it is for testing, then does the package wait for 10.10?
<persia> umang: It's usually for sid, but we're doing testing this cycle.
<umang> persia: So I'll have to wait for the 10.10 freeze before filing a bug?
<persia> For an upload today, it would probably wait for 10.10, but if you *know* it works in current lucid after being recompiled, you can request a sync directly from unstable.
<persia> No, it would be automatically pulled when the 10.10 archive opened.
<umang> I know it works on Karmic
<persia> You only need a bug if you want it before that.
<persia> Yeah, but it needs to be known to work in lucid to be included in lucid :)
<persia> You may find that a VM or chroot can help test that.
<umang> persia: I can do that, but by when would I have to file a bug?
<umang> I mean it has just been uploaded, not even accepted by the ftp.
<persia> You'd have to file the bug after it gets through Debian NEW, and before FeatureFreeze.
<persia> It's potentially possible to do after FeatureFreeze, but that requires a Freeze Exception, which is a much higher bar.
<umang> OK. I hope I get some time in between. :)
<umang> It's just a day I think.
<oojah> persia: Ah, ok. I was thinking about it the wrong way round. So for a git repo I should pull the code and create a tarball based on the version there and it's at that point that the new changelog entry would be created?
<umang> persia: So a needs-packaging, right?
<persia> oojah: Well, there's not usually that much automation.  Someone updating the package would usually run debian/rules get-orig-source to generate a new tarball, and then dch -i separately to add a new changelog entry, manually setting the version in the changelog.
<persia> umang: If you've uploaded it to Debian, surely it's already packaged :)  You'd file a sync bug.
<umang> Oh yes. :P
<umang> "Please sync <packagename> from debian <distro>" where <packagename>"
<umang> Right?
<umang> I mean, "Please sync <packagename> from debian <distro>"
<AnAnt> Hello, I am preparing a package for a library , some symbols are not hidden although they are not in the official API, the question is, should I remove those symbols from debian/libname.symbols file ?
<persia> Something like that.  Most people use requestsync.  I recommend searching for one in the ~ubuntu-archive subscription list, and following that sort of pattern.
<persia> AnAnt: All the symbols file does is help set appropriate dependencies and help you notice when the ABI changes.  If you think these symbols don't matter, then you can hide them.  If you think they will be used, even if undocumented, you may want to include them.  Be careful that no symbols are exposed that properly belong to other libraries.
<AnAnt> thanks
<oojah> persia: Yes, that's what I meant - no automation of dch -i.
<AnAnt> persia: well, thing is that they were supposed to be hidden in previous releases, yet some packages used a few of those symbols, so upstream kept them (but is considering hiding them) to keep API
<persia> In that case, there are users, and they *should* be shown in the symbols file.  If they are hidden, that's an API change, and you will benefit from dpkg-gensymbols telling you so.
<umang> persia: Thanks. I will use that tool if it clears new before the 11th.
<c_korn> are unmodified packages still automatically synced from Debian testing ?
<persia> c_korn: Until DIF *)
<c_korn> persia: ah, it is the LTSDIF on the 11th, right ? https://wiki.ubuntu.com/LucidReleaseSchedule
<persia> Indeed.
<AnAnt> persia: but those users used symbols that they weren't supposed to use
<AnAnt> persia: ie. it is not actually an API change
<c_korn> well, then I have not much time to get scilab in :) thanks persia
<persia> AnAnt: It's not supposed to be an API change, but it *is* an API change.  The offending applications need to be patched, and so it needs to have a new soname, to break the dependency.
<AnAnt> persia: or patch to offending apps?
<AnAnt> persia: especially that they are a few
<persia> AnAnt: Well, you *could* patch all the offending applications for which you can get the source, but you can't do it for stuff you can't see.
<persia> So you might see bug reports if you don't adjust SONAME when the API changes.
<AnAnt> persia: upstream of the lib doesn't want to bump SONAME
<persia> Then keep the symbols public.
<AnAnt> persia: especially that the problem I mentioned is very a very few apps
<persia> I argue that it's not possible to know how many applications are affected, because it's not possible to determine what all users are doing in their local environments.
<persia> It's more responsible to just leave those included in the undocumented but official API until there's some other reason to bump the SONAME, and drop them then.
<sistpoty|work> AnAnt: is the package already in the repos? if not, and if upstream seems to plan to hide those symbols, maybe you should do this too (not in the symbol files, but rather by unexporting them e.g. via __attribute__((__hidden__)))
<cnd> I've got a package that is near inclusion into fedora, but I can't seem to get anyone to review it for ubuntu
<cnd> I've got it uploaded into revu and a launchpad bug opened for packaging
<cnd> what can I do to get it reviewed?
<cnd> the package is rinputd
<EagleScreen> cnd: are you Chase Douglas?
<cnd> EagleScreen, yep
<EagleScreen> why has you package a -4 debian revision?
<cnd> I don't know specifics of how packages versions SHOULD work, but my idea is that the 1.0.2 is the version of the source code
<cnd> whereas the -4 is the 5th version of the packaging
<umang> cnd: If it hasn't already reached ubuntu, then you should stick to -1. That's what I was told on Debian.
<cnd> I can certainly change the version to fit ubuntu standards
<EagleScreen> cnd: if you package for Ubuntu a package which is not still in Debian, you cannot set a debian reviison grather than zero
<umang> EagleScreen: cnd, Yes that true. (So I was wrong)
<EagleScreen> cnd: upstream version is 1.0.2
<umang> cnd: Also, why is your package native?
<cnd> EagleScreen, ok, so the revision should just be rinputd_1.0.2
<EagleScreen> the first Debian revision would be 1.0.2-1
<EagleScreen> second 1.0.2-2
<cnd> umang, because I originally developed it in bzr and used bzr builddeb to build packages
<cnd> I can repackage it as a non-native, but I'm upstream so its easier if I could leave it that way
<umang> cnd: Ah. But I don't think you should do that unless the package is irrelavant outside Debian/Ubuntu
<umang> e.g. Lintian
<cnd> umang, why not?
<cnd> when I ship the source tarball, I filter out the debian directory
<EagleScreen> cnd: if this package is not still in Debian and you package it for Ubuntu, you has to version it like this: 1.0.2-0ubuntu1 -> 1.0.2-0ubuntu2 etc..
<umang> Just a sec, I'll find the documentation
<cnd> EagleScreen, so if I resubmit as 1.0.2-0ubuntu1 then I should be good on the versioning front?
<EagleScreen> yes
<Laney> /sponsoring could interface with LP to provide a list of packages-you-can-sponsor
<EagleScreen> cnd: please merge all your entries in the ubuntu chagelog (debian/changelog) in just one
<EagleScreen> and verison it 1.0.2-0ubuntu1
<cnd> EagleScreen, every single entry in the changelog?
<cnd> or just since 1.0.2?
<umang> cnd: For now, you can see this, I'll find a doc that says it more specifically (I'm sure there was one): http://www.debian.org/doc/manuals/maint-guide/ch-update.en.html#fr5
<umang> section 9.4
<cnd> ok, I'll just make a separate non-native package then
<EagleScreen> since 1.0.2
<EagleScreen> but upstream version always must be continued by an ubuntu revision
<EagleScreen> never submit an entrie with just 1.0.2
<cnd> ok
<EagleScreen> do the same for previous versions
<EagleScreen> cnd: have you packaged it using a Debian system?
<cnd> I currently do my packaging using bzr builddeb
<cnd> and upload to my ppa
<EagleScreen> ok
<cnd> I'll probably continue to do that for development
<cnd> and have a separate tree for the debian/ files for a non-native package submitted for inclusion into ubuntu
<umang> cnd: found it http://people.debian.org/~mpalmer/debian-mentors_FAQ.html
<umang> You should only use a native Debian package when it is clear that the package would only ever be of use in Debian. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native.
<cnd> thanks umang
<umang> ^ quoted from the debian-mentors faq
<umang> cnd: Welcome
<umang> :)
<EagleScreen> cnd: you should ideally include your package in Debian, with a debian revision 1.0.2-1 -> 1.0.2-2 etc.. then it will be automatically synchronized from Debian to Ubuntu
<cnd> EagleScreen, I will look into that
<cnd> where is the process documented for inclusion into debian?
<cnd> also, is it ok if I'm listed as the maintainer in the control file
<cnd> since I have an @ubuntu.com address
<persia> cnd: Some people in Debian grumble, but if you're a good maintainer, nobody seems to mind that much.
<cnd> ok
<EagleScreen> cnd: all ok you are the maintainer
<EagleScreen> cnd: visit and read http://mentors.debian.net/cgi-bin/welcome
<cnd> EagleScreen, thanks
<EagleScreen> you have to make a good quality package, upload it to debian.mentors repository as if it were a PPA, and then look for a sponsor in #debian-mentors
<cnd> ok
<umang> Sorry, I'm curious to know, what does the @ubuntu.com change at debian?
<Laney> nothing
<persia> umang: Just some people in Debian are sore because Ubuntu is a derivative.
<persia> Most people in Debian aren't, but it's worth noting in case one bumps into someone particularly opinionated.
<EagleScreen> cnd: #debian-mentors channel is in server irc.debian.org
<Laney> giving back (by maintaining a package there) should make them less sore really
<umang> But ubuntu encourages upstream contribution to debian instead of only to ubuntu
<EagleScreen> cnd: update standars version to 3.8.4
<cnd> will do
<umang> I guess I've met only the most people. :) debian-mentors and debian-python have been pretty friendly to me (newbie + ubuntu user)
<persia> umang: That's been my experience as well, although I hear stories, so like to caution people just in case.
<rockstar> dholbach, ping
<dholbach> rockstar: pong
<umang> Oh yes. I have a related question. If you bump the standards, Lintian fussed about 3.8.4, because Karmic doesn't have the version in sid. So do we have to manually build the lintian source package from sid and then install onto the karmic installation, or do you always run lintian under a chroot?
<persia> hyperair: You were asking about procedures to apply to MOTU earlier.  A decision has been reached, and the wiki is now up-to-date (I believe).
<rockstar> dholbach, can you take a look at https://bugs.edge.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/516744
<ubottu> Ubuntu bug 516744 in tahoe-lafs "please upgrade Tahoe-LAFS to v1.6" [Undecided,New]
<hyperair> persia: cool
<hyperair> !motu
<ubottu> 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> umang: I tend to run lintian in the target environment.  Whether you choose to use a chroot, a full install, a VM, etc. depends on your available hardware and preferred workflow.
<dholbach> rockstar: will do in a sec
<umang> persia: OK. But for convenience, is it likely to break something if I downloaded the lintian source package and built it myself?
<umang> (or karmic)
<dholbach> rockstar: usually attaching a .diff.gz should be enough and have a look at https://wiki.ubuntu.com/SponsorshipProcess
<umang> *on karmic
<rockstar> dholbach, great.  I thought I'd bug you since it was you specifically I talked to about getting started in packaging.  Eventually I'll find someone else to harass about getting my into Ubuntu.
<dholbach> rockstar: will review now
<rockstar> dholbach, okay, great.
<dholbach> yeehaw
<persia> umang: No.  lintian is frequently backported.  But there are differences in lintian between Ubuntu and Debian.  It's worth pulling the right one.
<EagleScreen> umang: just isntall the lintian in Debian sid
<persia> Mind you, ubuntu-policy doesn't get updated as much as it might, so oddly Ubuntu lintian supports a policy version in excess of that documented.
<umang> EagleScreen: How, you mean download a binary?
<EagleScreen> yes, use the Debian package in sid
<umang> persia: Karmic is still at 2.2.17, if I'm going to submit to debian, I'd like 2.3.3
<EagleScreen> http://packages.debian.org/sid/lintian
<umang> EagleScreen: Thanks. :)
<persia> umang: Right, but my point is that if you're submitting to Debian, you want *Debian's* lintian, rather than Ubuntu's.
<persia> The changes are relatively minor, but sometimes surprising.
<umang> persia: The part I'm confused about is how. Build the source package or run in chroot?
<umang> Or download binary
<umang> from sid
<persia> I think you'd do best to either run in a chroot or build a cross-port binary given those choices.
<umang> persia: Thanks.
<umang> :)
<persia> But you could also run it in a VM or on hardware, if you have those available.  Whatever works best for you is best.
<umang> persia: I'm not experienced enough to run sid like that. :P I'll stick to chroot. :)
<EagleScreen> for standars 3.8.4 you need lintian 2.3.3
<EagleScreen> it is in sid
<Rhonda> EagleScreen, umang: Please notice that 2.3.2 on that sid page is outdated, 2.3.3 is current. packages.debian.org still seems to not have recovered from its harddisk issues.
 * Rhonda . o O ( see output of "rmadison lintian" )
<EagleScreen> yes it is outdated
<persia> Or, rather `rmadison -u debian lintian` when running on karmic :)
<umang> Yes. I have actually been checking it on a chroot, I just wanted to know what's best. :)
<persia> umang: chroot is fine, if it works for you.
<Rhonda> persia: Oh, makes sense that ubuntu patched devscripts to use -u ubuntu by default. Should have thought of that. :)
<umang> Thanks all. :) Going to get some sleep now. Good Night.
<persia> Rhonda: That was why I had the "nifty ..." comment a couple days back: I thought the entirety of -u was an Ubuntu patch.
<EagleScreen> if you only package for Ubuntu you can use standars 3.8.3
 * persia should probably use the Debian system for more than a NAS more often
<Rhonda> persia: No, there is also -u bpo :)
<Rhonda> For backports.rog
<Rhonda> org
<persia> Right.  madison.cgi in Soyuz includes backports by default (but unfortunately only includes 2 architectures for binary results)
<persia> (or at least I *think* it's Soyuz)
<Rhonda> EagleScreen: One can also use standards 3.8.3 for Debian, there is nothing really wrong with doing so. The changes aren't relevant for most parts, and it's technically the same, most of the times.
<Rhonda> most packages, that is.
<EagleScreen> yes
<EagleScreen> ofcourse, but some uploaders take care about 3.8.4
<corecode> hey
<corecode> the newer linux kernels come with tools, specifically "perf"
<corecode> i can't seem to find a package containing it
<corecode> what's the opinion on how to package that?
<persia> corecode: You might want to ask in #ubuntu-kernel : that team has more experience in that area.
<corecode> thanks
<persia> (assuming it's part of the kernel distribution, rather than just being some other tool distributed from kernel.org)
<corecode> so many different chans
<persia> Lots of different teams :)
<Laney> MOTU: Signposts into Ubuntu development
<persia> Laney: Well, #ubuntu-devel is probably better for that, but most of us end up working with several teams, just in the nature of what we do :)
<Laney> persia: Indeed. Just that recent discussions have me considering how the future looks...
<persia> With today's TB decision, I think there is now a clear path forward.
<sebner> Laney: ultra uploader everywhere
<persia> MOTU may be less broad than it was, and more QA focused, but at least we know it has a future, and how that works.
 * Laney ITA: sebner
<sebner> Laney: hm?
<Laney> never mind :)
<sebner> Laney: I just wanted to point out that there is a new developer position, comparable to core-dev, with upload rights nearly everywhere
<persia> sebner: Hrm?  What sort of developer?
<sebner> persia: I forgot the correct spelling -.-
<persia> sebner: I just reedited UbuntuDevelopers, and I'm fairly sure we only have six types, which doesn't include anything like that.
<Laney> are most package sets restricted?
<persia> None so far.
<sebner> persia: really? I've heard about that kind of thing. Let me check
<persia> sebner: Please.  I'd like that everyone had a single shared understanding about these things :)
<Laney> well...
<Laney> https://wiki.ubuntu.com/ArchiveReorganisation/Permissions#Resolving%20upload%20permissions the second bullet here
<persia> That probably needs revision now that MOTU exists.
<persia> But it basically just says that people can upload to the stuff to which they have permisison to upload, except from the packages' perspective.
<sebner> persia: ah, it was "generalist developer"
<Laney> so "generalist" is like core-dev, right
<sebner> Laney: aye
<sebner> Laney: like core-dev, upload rights everywhere except special stuff like kernel ,..
<Laney> and "MOTU" is P(generalist) \ U (packages in sets)
<sebner> heh
<persia> Laney: At the time that document was written, it included an understanding the "MOTU" and "core-dev" would both be replaced by "Generalist".  I do not believe this is still the case.
<persia> A proposal for a definition of MOTU under ArchiveReorg has been submitted and approved.
<persia> The definition of "core-dev" is still a bit unclear, but I suspect it will end up being close to the "Generalist Developer" of the prior documentation.
<Laney> Good, that's how I understand it
<Laney> so I don't think it really affects current permissions that much
<persia> Where I'm less certain is whether "core-dev" will have access to restricted sets, or whether some other group will be created that has access to everything, or whether core-dev will have access limited only by restricted package sets.
<persia> No.  For us (MOTU), the next big permissions change is when we move from being able to upload to the universe component to only being able to upload to packages that don't belong to package sets.
<persia> Which means we can't upload to as much stuff, but also means we don't have to feel responsible for as much stuff.
<persia> Those of us who have interests in packages belonging to package sets would likely be welcomed as members of the teams responsible for those package sets.
<sebner> persia: I'm wondering if a MOTU can join freely or also has to make some applications as non-MOTU folks
<persia> sebner: I personally consider membership in MOTU entirely separate from membership in any other development team.  I don't see any conflict in belonging to several of them, nor any dependencies between them.
<persia> Until today, I considered MOTU just another delegated team, but the TB has determined that MOTU is a bit special for now.
<oojah> persia: Is there a link where I can read about that?
<sebner> persia: yeah, I just thought about the technical skill question
<Laney> Well, being the "default" uploaders to the distribution does put MOTU in a bit of a special position AFAICS
<persia> oojah: About which?
<persia> Laney: Indeed.  I don't argue with the TB decision, it just is different than my previous opinion :)
<oojah> The TB stuff.
<Laney> the minutes just went out to u-d-a
<oojah> Ok
<Laney> and the logs in the usual place...
<Laney> !logs
<ubottu> Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/
<ogra> \sh, thanks for the rootstock fix, why wasnt there a bug
<corecode> what's the TB decision?
<persia> corecode: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-February/000673.html
<ari-tczew> what is the solution for sync, if package's name has been changed?
<kreuter> hi #ubuntu-motu.  I'm trying to upload my first package to REVU, and am dubious of the dput documentation.  am I really only uploading the source.changes file?
<Laney> nope
<Laney> have a look at the contents of the changes file
<maco2> kreuter: dput will pull the rest from the same directory
<maco2> i think...
<Laney> there is a Files: section
<maco2> it all it makes it there
<kreuter> but the only command I need to execute is "dput revu <foo>_source.changes"?
<EagleScreen> yes maco2 and kreuter, only the .changes
<kreuter> great.  thanks!
<maco2> kreuter: right
<Laney> that's all you need to type, but it's not all you are really uploading
<kreuter> ok.  I guess I expected something more involved.
<maco2> EagleScreen: well now im wondering about teh insides of dput. i know i only need to tell it the .changes, but i think the way it works is it then looks for the rest of the files in the same directory, and grabs those too, right?
<Laney> I just said
<oojah> maco2: I'd read what Laney said.
<EagleScreen> yes maco2
<Laney> that's why you pass -sa or -sd to dpkg-buildpackage.
<ari-tczew> Laney: could you take a look @ http://packages.debian.org/changelogs/pool/non-free/f/frobtads/frobtads_0.13-2/changelog
<ari-tczew> and how we can sync it
<EagleScreen> -sa is needed when a new upstream tarball is used
<persia> ari-tczew: The common way is to request inclusion of the new package and removal of the old package.
<persia> Most of the time the old package is removed in Debian already, but I've ended up filing a few removal requests there when that didn't happen.
<Laney> -sa is needed when you need to have the .orig.tar.gz included in the changesfile and it isn't by default
<Laney> most commonly when uploading a merge which contains a new upstream version
<ari-tczew> persia: how are you think, can be done this before FFe?
<Laney> ari-tczew: do it now
<persia> ari-tczew: Quite possibly.  I handled a new-package-addition and removal last week.  Dunno why someone couldn't do it this week.
<micahg> what's the proper short for for replaces/provides/conflicts if any?
<micahg> *short form
<persia> Generally the archive-admins run the scripts every day, so it's just a matter of making sure the requests have been made properly.
<persia> micahg: How do you mean "short form"?
<micahg> persia: can I say R/P/C in a changelog entry?
<Laney> there is no need to make a changelog entry short
<micahg> Laney: ok
<Laney> Making it understandable for people in the future should be your goal
<micahg> was just wondering if there's a convention
<Laney> not that I know of
<persia> I usually just put something like "Enable transition from ${PACKAGE}", but that may be too terse.
<persia> Or "Support transition ..."
<Laney> Added replaces/conflicts on xxx due to yyy
<ari-tczew> persia: do I need to report 2 bugs? 1) remove 2) sync new package?
<Laney> yep
<persia> ari-tczew: sync-new should happen without a bug if it reaches testing.
<persia> If it doesn't reach testing, you'll need a sync-new bug.
<ari-tczew> yes, this is in testing
<ari-tczew> but still no synced into lucid
<persia> And check in Debian: I often find it's more productive to work with maintainers and file removal bugs in Debian directly.  The removal is synced (if it happens in time)
<persia> If it's in testing and not in lucid, check (in #ubuntu-devel) to see if an archive-admin has pulled the new sources from Debian testing recently.
<persia> There's probably a bunch of stuff we ought have included.
<ari-tczew> persia: I think is not synced yet, because in Debian this is not _new_package_, just change package's name
<persia> ari-tczew: The source package name changed?
<kreuter> is there a delay between dput finishing and the package becoming visibole on revu.ubuntuwire.com?
<persia> kreuter: Yep.  The queue is processed every 5 minutes or so.  If it's a long time, ask for a REVU Admin to investigate.
<kreuter> alright.  thank you.
<ari-tczew> persia, just look at changelog http://packages.debian.org/changelogs/pool/non-free/f/frobtads/frobtads_0.13-2/changelog
<kreuter> uh, one last question: is it necessary to upload different sets of files for different architectures?
<persia> ari-tczew: Yes.  We'll see that as a NEW frobtads package.  So will Debian.  Compare the results on packages.qa.debian.org for frobtads and tads.
<persia> ari-tczew: Also, check the Ubuntu NEW queue: it may already be there.
<persia> kreuter: No.  In fact, it's necessary not to upload any architecture-specific files.
<kreuter> hrm.  dput says it uploaded an amd64.deb.  will that cause problems?  was I supposed to have deleted the .deb before running dput?
<persia> Yes.  I'll go delete that.
<persia> No, you need to dput source.changes
<kreuter> hrm.  here's what I did: "debuild; cd ../; dput <package>_source.changes"
<kreuter> I guess I wasn't supposed to do a debuild./
<persia> kreuter: All cleaned out.
<persia> You wanted debuild -S.
<kreuter> persia: thanks.  should I try again, starting with debuild -S?
<persia> Yep.
<kreuter> okay.
<rmunn> Is it possible to remove a file from a source package without modifying the .orig.tar.gz? The upstream source package includes a binary .jar that shouldn't be there. I tried "rm nltk/nltk.jar; debuild -S" but the removal of nltk.jar didn't show up in the .diff.gz. What should I do here?
<persia> rmunn: Well, there's two schools of thought: repack and delete on clean.
<persia> My personal preference is to verify the binary object is licensed in a redistributable way, and delete it in my clean: rule in debian/rules.
<rmunn> persia: There are no license problems with distributing the .jar since it's built from NLTK source files that are all present in the original tarball, so I'd prefer to leave the original tarball alone and delete it in debian/rules.
<persia> If the blob isn't licensed in a redistributable way, or can't be regenerated from source, or is otherwise annoying, you have to repack.
<rmunn> (And that are all licensed under Apache-2.0 license)
<persia> I can't say I've memorised all the terms of the Apache 2.0 license, but my memory is that it ought be safe.
<rmunn> All right, I'll delete it in the clean: target of debian/rules.
<persia> Just be prepared to defend your decision if an archive-admin is in a hurry, and be sure to set out your argument in terms of having a license to redistribute the blob, rather than in terms of deleting it in clean.
<\sh> ogra: there was a bug :)
<ogra> \sh, against what ?
<ogra> i didnt get one
<\sh> ogra: could be because it was in the sponsoring queue?
<ogra> no, i probably am not subscribed to the package bugs
<ogra> i'll check that, might be my fault
<\sh> bug #517524
<ubottu> Launchpad bug 517524 in rootstock "Error in debian/watch file" [Undecided,Fix released] https://launchpad.net/bugs/517524
<\sh> https://bugs.edge.launchpad.net/ubuntu/+source/rootstock/+bug/517524
<ubottu> Ubuntu bug 517524 in rootstock "Error in debian/watch file" [Undecided,Fix released]
<ogra> thanks
<\sh> ogra: there are two more bugs attached
<ogra> i prefer to know about my packaging errors :)
<\sh> ogra: I don't think it's a pkg bug, I wonder if it was a change in launchpad which triggered that?
<ogra> yeah, i guess the whishlist one is a wontfix ...
<ogra> rootstock trunk is already a lot more complex, would be very hard to do
<ogra> ok, securetty is triaged ... i'll fix that with my next upload
<randomaction> Is this sync request somehow malformed? It was overlooked during two last waves of syncs. (bug 491988)
<ubottu> Launchpad bug 491988 in gcl "Sync gcl 2.6.7-56 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/491988
<\sh> ogra: does armel has different ttyS devices?
<ogra> yeah, nearly for each board there is a different name
<ogra> versatile boards have ttyAMA0, babbage boards have ttymxc0 ... some just use ttyS though
<ogra> but given that the device name is a parameter to rootstock if you want a serial tty its not a prob
<ogra> just some sed magic to add the entry to securetty
<\sh> ogra: isn't it a better idea to "link" /dev/tty<whatever> to something more standard?
<\sh> ogra: somewhere in udev hell?
<ogra> well, that would break vendor docs
<ogra> usually you get a handbook with your board where such stuff is defined
<ogra> we could indeed add a udev rule
<ogra> but i doubt upstream would accept it ... and its hard to get Keybuk convinced to carry extra rules if they are not absolutely needed
<\sh> ogra: well, but can't we identify those "exceptions" during install and we add some udev rules to react on those "exceptions"?
<ogra> uuh, no, not if they arent in any package
<ogra> i'm just working on rootstock to be closer to the default ubuntu images ... such a change would be awkward :)
<\sh> spec: "Dynamic UDEV Rule creation on arch during install" ;)
<persia> Would it be similarly infeasible to have a special arm-serial-console package that just contained readmes and udev rules?
 * persia also advertises #ubuntu-arm as a good forum for this discussion
<ogra> persia, that would be possible and cleantr
<ogra> *cleaner
<ogra> heh, yeah
<persia> ogra: You could probably build it out of the rootstock source, etc. :)
<ogra> heh, yeah thats possible
<ogra> though i wont have time before FF for that
<ogra> not sure such a bug justifies an FFe for a new package
 * \sh just creates udev rules during deploy time, when FAI comes, it checks my database, and writes udev rules for those machines ;) depeding on the input from my asset management system...but this is far more advanced ;)
<ogra> thats why we dont use FAI but d-i in ubuntu :)
<\sh> hehe
<jcastro> anyone know anyone who uses or likes mongodb?
<persia> ogra: Adding a udev rule is trivial with dh_installudev.  Fixing it to work for everyone is clearly post-FF bugfixing :)
<jcastro> it's a sql-less db.
<ogra> anyway, i need to take a break, long conf call at 8pm ...
<ogra> persia, i'll quote you on that if slangasek hunts me down for it *g*
<\sh> couchdb, mongodb why are all cool db systems named after lazyness ;)
<persia> ogra: As long as you commit to fixing it by beta-freeze, I don't mind if you quote me on that.
<persia> \sh: Because of hubris, laziness, and impatience
<oojah> Would someone please review http://revu.ubuntuwire.com/p/sqlite3-pcre when they get a chance?
<slangasek> ogra, persia: depending on what the udev rule does, I might hunt you down sooner. :)
<\sh> well, couchdb will be included in our 6.1 release..which makes me not happy...and that cisco is tainting the linux kernel with binary blobs on cisco asr, it makes me think../me should switch back to windows or go forward to darwin+apple ui ;)
<ogra> haha :)
<persia> slangasek: It creates a known good dev point for serial consoles on armel devices.  Priority: extra.
<slangasek> what's "known good"?
<ogra> slangasek, linking weird tty names to generic ttyS
<slangasek> so that will conflict on any system that has both ttymxc and real ttyS?
<ogra> slangasek, like ttyAMA0 or ttymxc0
<ogra> probably
<ogra> though i wouldnt know what such a system would be
<persia> Um, why wouldn't we use something like /dev/tty-console
<persia> That would avoid the conflict.
<\sh> persia: rewrite LPIC ;)
<ogra> you would need a lot of soldering experience and a microscope to build it :)
<persia> \sh: Why?
<\sh> persia: why not...it would make a good question.."On armel device X what is the name of your serial device? a) ttyS0 b) ttyAMA0 c) ttymxc0 or d) tty-console ;)
<\sh> LPIC 99101 ;)
<persia> \sh: Ah.  See, I'd like to live in a world where that sort of knowledge didn't need to reside in humans because we had sufficient automation :)
<\sh> persia: I would like to live in a world, where I plug in a <whatever> hardware thingy into my computer, and everything would behave after a written standard ... but oh well...nice..cisco asr -> crash -> with simple bgp full feed
<\sh> so...dinner time
<persia> \sh: You could, but it just needs someone to do the automation first.  As time passes, more and more of my hardware actually works.
<lucas> hi
<lucas> a long time ago, we had a lot of FTBFS bugs because of a change in X that was picked from the Debian SVN (a dependency change, I think). that change was not in Debian by the time.
<lucas> does someone remember more details?
<persia> lucas: If nobody answers here, you might try #ubuntu-x
<crimsun> what's the timeframe for "a long time ago"?
<lucas> 3-5 years
<persia> There was a GL-related transition in breezy, but I forget the details.
<persia> There was also the x-dev transition, but I don't remember that generating heaps of FTBFSs.
<kreuter> so my upload to REVU hasn't shown up after about an hour.  could anybody with the relevant privileges tell me if I've done something wronga again?
<persia> kreuter: Try to use the string "REVU Admin" in your requests of that sort, as it may attract more attention if people are only paying half-attention :)  Looking now.
<kreuter> persia: alright.  thanks for the tip.
<persia> What's your LP ID?
<kreuter> richard-10gen, I think.
<kreuter> er, my name on LP is "Richard M Kreuter"
<persia> kreuter: richard-10gen was the string I wanted :)  Have you ever logged in to REVU?
<kreuter> I believe I'm logged in now.
<crimsun> GL transition was mostly "Depend on lib{gl,glu}1-mesa-dev instead of xlibmesa-{gl,glu}-dev"
<persia> kreuter: Had you logged in before uploading?
<persia> crimsun: Yes.  That was it.
<kreuter> persia: yes.
<crimsun> back when we were tracking transition work on the wiki!
<persia> OK.  The signatures look good.  Let me try tossing the .changes back in the queue and see if that fixes it (sometimes this works)
<kreuter> hm.
<persia> crimsun: Right.
<persia> Which worked nicely, but kinda depended on there not being quite so many of us.
<rmunn> OK, http://revu.ubuntuwire.com/p/python-nltk now has a new version uploaded that fixes the problems pointed out to me yesterday. I'd appreciate a MOTU or two checking it out and giving me feedback and/or advocating the package. Note that there's one lintian warning (with minor severity), but according to my understanding of Debian policy, the warning is wrong in this particular case.
<persia> kreuter: Seems it got rejected again.  Let me look harder.
<kreuter> :(
<rmunn> Since NLTK is apparently a rather famous package in the field of computational linguistics (an O'Reilly book was recently published about it: http://oreilly.com/catalog/9780596516499), I'd like to get this package into Lucid, which means advocates are needed. Thanks!
<persia> kreuter: As a general guideline, you don't want to have two changelog entries with the same version.
<persia> kreuter: I don't *think* the issue is "Distribution: unsable", but that's the only bit I see wrong about the .changes file.
<rmunn> geser, jcfp: Thanks for your comments yesterday on http://revu.ubuntuwire.com/p/python-nltk, by the way. Much appreciated.
<kreuter> persia: sorry, meeting.  should I change "unsable" to "unstable" and reupload?
<persia> kreuter: You could try, but I'm unsure if that would work.  I've asked in the support channel for ubuntuwire, but haven't heard back yet.
<persia> Maybe another REVU Admin can figure it out, maybe it needs someone who has access to logs, etc.
<kreuter> okay.  thank you.
<juancarl1s> need a guide to package these need packaging bugs, but guides i find or someones pointme is for package on my own PPA, i want to share my packaging work with everyone, not only on my PPA, at least on Multiverse or something like that
<juancarl1s> how to fix need-packaging bugs?, i know package apps
<fabrice_sp> !revu | juancarl1s
<ubottu> juancarl1s: 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
<fabrice_sp> and also !packaging
<fabrice_sp> !packaging | juancarl1s
<ubottu> juancarl1s: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<juancarl1s> fabrice_sp: Thanks!, got experience packaging, traduction, and python so maybe i can help
<fabrice_sp> juancarl1s, sure. You can also help with merges and bug fixing ;-)
<juancarl1s> fabrice_sp: got some apps marked as "need-packaging bug" on a personal FTP
<juancarl1s> others guides talk about my PPA, i dont want to use my PPA
<fabrice_sp> juancarl1s, PPA is a good way to make the application available to people, andtested before being integrated in the archive
<persia> Well, except that it can complicate things if there are issues with the early PPA releases that require special upgrade handling.
<juancarl1s> fabrice_sp: but there are some easy to package apps, kinda python apps and such
<fabrice_sp> persia, sure. But in this case, you can always make a pre upgrade in your ppa, and upload the version after
<persia> fabrice_sp: Assuming you have clean version and revision strings :)
<persia> There's also the risk of someone only updating with update-manager -d, which disables PPAs before doing all the upgrade bits.
<fabrice_sp> lol I prefer not to look at all the PPA out there (even in mine, I have some ugly versions :-D )
<fabrice_sp> right
<persia> I prefer to avoid PPAs entirely, when possible, although I've uploaded some stuff to them previously.
 * fabrice_sp still has some software in his PPA
<fabrice_sp> especially, backports (for calibre, for example)
<fabrice_sp> juancarl1s, what experience do you have in packaging?
<crimsun> james_w: hi, do you have a moment to look at lp:ubuntu/goffice and lp:debian/squeeze/goffice?  "bzr merge-package" is balking due to a missing tag.  It doesn't appear as if the latest lucid source package has been imported, either.
<crimsun> or squeeze, for thatmatter
<fabrice_sp> libboost-dev points to 1.40 in Lucid, right?
<crimsun> yes
<fabrice_sp> thanks :-)
<juancarl1s> fabrice_sp: i work by selling services consulting support to small business and commercial shoops locally, i build solutions for common problems, packaing, traducing, and making quick'n'dirty python apps
<juancarl1s> not my main job, but my main job gives me spare time
<fabrice_sp> ok
<juancarl1s> lol, sorry for my english im reading the web ATM
<fabrice_sp> np: not native english myself :-)
<juancarl1s> fabrice_sp:"Uploads to REVU should be source files, with the original tarball"
<juancarl1s> fabrice_sp: explanations are not so explanatory, a screenshot may be good, continue reading
<fabrice_sp> yes. Even if you should build the package locally before
<juancarl1s> but i can upload a .deb or not?
<fabrice_sp> the packaging guide should explain how to generate the source file
<fabrice_sp> no: it has to be a changes files, generated from a dsc
<juancarl1s> or the ready-to-build sources?
<fabrice_sp> (basically, with debuild -sa -S )
<fabrice_sp> a source package
<juancarl1s> :(
<fabrice_sp> https://wiki.ubuntu.com/PackagingGuide/Complete
<fabrice_sp> A source package commonly contains a .dsc file describing the package and giving md5sums for the source package, an .orig.tar.gz file containing the source code from the author(s)  and a .diff.gz file containing the packaging (in the debian/ directory) and patches applied against the source code.
<juancarl1s> fabrice_sp: yes i know
<fabrice_sp> ok
<juancarl1s> fabrice_sp: what if not authors .tar.gz?, sometimes its only a .py or .zip or whatever?
<fabrice_sp> you have to create a tarball, even if it's from a svn or a git repository
 * fabrice_sp don't remember if source format 3.0 support zip files
<juancarl1s> ok
<ari-tczew> better pack in .tar.gz
<fabrice_sp> last package I uploaded was a tar.bz2
<fabrice_sp> and I think mame is zip
<fabrice_sp> no: sdlmame is repacked to tar.gz
<fabrice_sp> by the way, REVU support source format 3.0 yet?
<juancarl1s> lol, REVU logo is nice! Playmobil xD
<juancarl1s> i got my PGP keys uploaded
<bdrung> fabrice_sp: can you use "dpkg-architecture -qDEB_BUILD_ARCH" to determine the architecture for test_install (ack-sync)?
<fabrice_sp> bdrung, the sbuild can have a different arch than your main system, so I didn't found an easy way to determine the output
<fabrice_sp> as well as pbuilder, if I remember correctly
<bdrung> fabrice_sp: then use globbing
<fabrice_sp> globbing?!
<juancarl1s> you are using LXC or something like that for testing?
<fabrice_sp> oh: patterns
<fabrice_sp> juancarl1s, I'm using chroots
<bdrung> fabrice_sp: http://docs.python.org/library/glob.html
<juancarl1s> chroot is nice
<fabrice_sp> bdrung, thanks! :-) I'm reading Python for beginners right now :-) (began last week)
<bdrung> :)
<bdrung> fabrice_sp: you will love python
<fabrice_sp> juancarl1s, I also have a VM, as sometime, the chroot is not working for some stuff
<fabrice_sp> bdrung, It's nice, yes: I come from C++ (with some java and C), so it's a kind of easier :-)
<fabrice_sp> that may explain why my code is not so nice
<fabrice_sp> :-D
<bdrung> yes, it's easier and you reach your goal faster
<juancarl1s> LOLCode is nice
<juancarl1s> xD
<POX> fabrice_sp: http://diveintopython.org/
<lfaraone> Hi, I was wondering of anybody had some time to do a quick review of a new python module: http://revu.ubuntuwire.com/details.py?upid=7621
<bdrung> fabrice_sp: can you wrap long lines?
<lfaraone> (it's depended on by groundcontrol, and we want to get it in before FF)
<lfaraone> persia: care to take a look?
<fabrice_sp> POX, I'm reading the spanish version ;-)
<fabrice_sp> bdrung, for the piuparts call ,you mean?
<juancarl1s> ha hablas espaÃ±ol fabrice_sp jajajajaja
<fabrice_sp> ;-)
<POX> lfaraone: it will be extremely hard to find a sponsor in Debian if you'll not replace pycentral with pysupport
<bdrung> fabrice_sp: yes. you can use ["a",\n"b",\n"c"]
<fabrice_sp> ok. Will do (I'll try also to add piuparts call with pbuilder tarball)
<lfaraone> POX: is there good reason for this general hatred of pycentral?
<juancarl1s> REVU says im Timezone: Europe/Berlin (GMT+1), and im not, i cant edit, im logged-in
<juancarl1s> doesnt matter?
<juancarl1s> im GMT-3
<lfaraone> juancarl1s: it's not relevent, really.
<juancarl1s> ok
<lfaraone> POX: I've seen many people say things like that, that's why I ask. Is there anything inherently wrong with pycentral?
<persia> lfaraone: Nothing screams out at me, except that I don't really like python-mkdebian
<POX> lfaraone: well, short story: pysupport is maintained in Debian
<POX> (bugs are fixed, etc.)
<POX> lfaraone: get-orig-source looks familiar ;)
<lfaraone> POX: heh :)
<persia> POX: Do you know of anything maintained for pysupport that mirrors python-mkdebian?
<persia> (from python-distutils-extra)
<POX> I don't know python-mkdebian very well (never used it to be honest)
 * POX maintains stdeb
<persia> POX: it autogenerates copyright, control, rules, compat, watch?
<POX> control, rules, compat - yes
<persia> Well then, maybe I'll send you a patch rather than trying to figure out python-mkdebian (which was causing me confusion).
<persia> With Lucid, there are a number of tools being released that attempt to automate package construction for python developers, and they all seem to use python-mkdebian today.
<POX> persia: great, I plan to work on stdeb a little bit once I finish dh_python
<juancarl1s> LOL, Python tag at REVU is giant
<fabrice_sp> bdrung, I'll change also the status from Confirmed to Triaged, if you are ok
<persia> POX: What's the current estimated schedule for dh_python?  Weeks or Months?
<ari-tczew> fabrice_sp: what is the different between Confirmed and Triaged in sync requests?
<persia> ari-tczew: Isn't really one.
<fabrice_sp> ari-tczew, for the archive admin, it's the same
<POX> we have a freeze in March and I promised doko to have it ready in Squeeze
<fabrice_sp> IIRC, the wiki says to put Triaged
<bdrung> fabrice_sp: i am fine with that
<POX> I work now on a compatibility with PEP
<POX> 3147
<persia> POX: Even faster than I'd hoped.  Thanks for the update.  Good luck!
<rmunn> How do I add a tag to a REVU upload? http://revu.ubuntuwire.com/p/python-nltk should probably be tagged with "python" but I can't find a way to tag it anywhere on that page...
<lfaraone> persia: should I increment the ubuntu revision on each REVU upload?
<persia> lfaraone: Please don't
<lfaraone> persia: mk, just wondering. One of my sponsors in debian insisted that I do so, and he ended up uploading a -4 version of a package to NEW :)
<POX> depends on a sponsor
<lfaraone> POX, persia, new version sans pycentral: http://revu.ubuntuwire.com/details.py?upid=7647
<persia> I've had sponsors in Debian insist both ways.  For REVU, I tend to encourage collapsing the changelog, as I don't think end-users care about what was done prior to the initial release, excepting documentation of local patches.
<lfaraone> *same version, different content.s
<juancarl1s> !foo
<ubottu> bar
<juancarl1s> !bar
<ubottu> baz
<lfaraone> !botabuse > juancarl1s
<ubottu> juancarl1s, please see my private message
<POX> lfaraone: why XS-Python-Version: >= 2.6? I don't see anything that requires 2.6 (nor even 2.5)
<lfaraone> POX: upstream's packaging used "current". I'm not sure how to check for compatiblity with older python versions. (the only change I noticed between 2.5 and 2.6 is "with")
 * POX checked with 2.4 and 2.5
<lfaraone> POX: mk, I'll lower it to 2.4 then, thanks!
<POX> "current" is bad and should be avoided in 99% of cases
<lfaraone> POX: I realize, that's why I changed it :)
<POX> python-support can most probably be moved to -Indep
<lfaraone> POX, persia, "third (er, fourth) time's the charm" upload: http://revu.ubuntuwire.com/details.py?upid=7649
 * persia steps away, still not being confident about python, and not having seen anything else worthy of mention
<persia> I'm always happy to *reject* python packages that have something else wrong, but not quite entirely confident advocating them.
<kreuter> persia: so I just tried re-uploading my package with the changelog fix, but revu won't take it.  any ideas?
<lfaraone> kreuter: what error did you get?
<kreuter> "Already uploaded to revu on revu.ubuntuwire.com"
<lfaraone> kreuter: that's a issue with dput. do "dput -f pathtofile"
<persia> kreuter: You probably have a local .revu.upload file.
<kreuter> oh
<lfaraone> kreuter: -f forces dput to reupload.
<persia> lfaraone: No it isn't: it's a matter of dealing with local files.
<persia> -f is a large hammer.  It's generally worth sorting the issue.
<kreuter> should I delete the .revu.upload?
<persia> (because -f can force other classes of failed uploads as well, and that's less good)
<persia> Yes.  If you delete the .revu.upload file, you can upload again.
<kreuter> um
<lfaraone> persia: well, the manpage is unclear, then. According to  it, all -f does is "-f, --force - force an upload of an already uploaded package."
<kreuter> okay, done.
<persia> lfaraone: Or my information is wrong since I haven't looked at that code in quite a while.
<juancarl1s> REVU is kinda Arch AUR
<POX> lfaraone: if you'll add python-xdg to build depends I will upload it in Debian
<juancarl1s> what happend if i try to package/upload an .exe, like pptview or playolinux???
<juancarl1s> to REVU
<juancarl1s> no playonlinux is not the right example, but pptview
<POX> lfaraone: consider using dh instead of cdbs, though
<POX> lfaraone: /usr/share/doc/debhelper/examples/rules.tiny
<juancarl1s> what happend if i try to package/upload an .exe, like pptview???
 * POX continues stealing developers ;)
<jpds> juancarl1s: It would be uploaded?
<juancarl1s> lol, you reply my question with a question
<jpds> juancarl1s: Yes.
<juancarl1s> but wiki says sources only
<jpds> juancarl1s: And due to copyright, we would remove it.
<juancarl1s> why?, i dont talk about licensing
<juancarl1s> then i report pptview package
<juancarl1s> for licensing
<RAOF> There are a number of questions you need to ask: (a) Do we have permission to distribute it?  If we don't, then there's no point.
<juancarl1s> en .exe with permission to distribute
<juancarl1s> an*
<RAOF> (b) Can we build the package from source?  If so, it could go into universe.  If not, it could possibly go into multiverse.
<juancarl1s> this is nice RAOF
<lfaraone> POX: done, much appreciated. http://revu.ubuntuwire.com/details.py?upid=7650
<POX> lfaraone: let me know if you will want it in Debian (Maintainer field in debian/control and distribution field in debian/changelog will have to be changed before I can upload)
<juancarl1s> WTFPL are allowed on REVU ?
<lfaraone> juancarl1s: yes, WTFPL meets the Debian Free Software License.
<juancarl1s> what means build on top of the main component?, it need to build correctly on a Chroot, Ubuntu with ubuntu-standard installed?
<lfaraone> POX: okay, I'll add myself as maintainer with Martin as an uploader.
<lfaraone> POX: do you mind if I set DMUA?
<POX> are you DM?
<POX> anyway, please let DD set this flag
<POX> (and I will not set it in NEW package for sure)
<lfaraone> POX: yes-ish. I applied two weeks ago, got advocated, and recieved an email from the keyring maintainers to keyring@rt.debian.org that I was being added to DM.
<POX> ask me again after at least few clean uploads
<lfaraone> POX: https://rt.debian.org/Ticket/Display.html?id=2115
<lfaraone> POX: understood.
<POX> (clean = no replies to RFS mail)
<POX> .oO( that will not be easy ;P )
<asbin> Hi everybody. I'm looking for a reviewer for some packages. They are fully working, I have tested them on my ppa https://launchpad.net/~asbin/+archive/geexbox/+packages : libnfo http://revu.ubuntuwire.com/details.py?upid=7625 - libplayer http://revu.ubuntuwire.com/details.py?upid=7627 - libvalhalla http://revu.ubuntuwire.com/details.py?upid=7629 - enna http://revu.ubuntuwire.com/details.py?upid=7630 . Thanks !
<POX> lfaraone: http://people.debian.org/~piotr/sponsor
<juancarl1s> i printed the Wiki page to play at home
<lfaraone> POX: testing in pbuilder right now, I didn't have a sid base built yet so it might take a few mins.
<juancarl1s> â thanks for the Help...
<POX> lfaraone: please create Debian chroot as well (to test the package)
<dooooomi> mok0: hi! if you've got a minute, i changed klick's debian/copyright as you suggested
<mok0> dooooomi: ok, great
<mok0> dooooomi: is it on REVU already=
<mok0> ?
<dooooomi> mok0: yup, revu has the latest version
 * mok0 looks
<mok0> dooooomi: Looks good. +1
<mok0> dooooomi: I'll take a look at gklick tomorrow. Ping me if I forget :-)
<persia> POX: Getting more people from this channel to upload directly to Debian isn't "stealing developers", it's "collaboration" :)
<dooooomi> mok0: ok, thanks :)
<mok0> I haven't tracked the multimedia situation lately... Is jack supported now?
<mok0> It seems a lot of the nice tools use it
<asbin> Hi is it too late to have packages included in lucid ? I though the feature freeze is on february 18th, right ?
<persia> mok0: jack is certainly supported, but it's in universe, so nothing in main links against it.
<persia> asbin: That's right.
<mok0> I see
<mok0> persia: of course, nothings in universe soon
<asbin> persia: right, but reviewing package takes time too ...
<persia> mok0: Once that happens, jack will be in a package set.
<mok0> persia: ... Ubuntu Studio?
<persia> It's in the ubuntustudio set now, and there is an open MIR.  I'm not sure it will end up in some other set anytime soon.
<persia> Yes :)
<persia> But I think the only things that *could* use it that don't are gstreamer, vlc, and pulse.  I may be mistaken though.
<mok0> My son is becoming interested in Linux. He wants to use ardour
<mok0> Perhaps I should recommend him to install Ubuntu Studio
<persia> If he already has an Ubuntu install, no reason to reinstall: just install ardour.  I tend to like ubuntustudio-audio-plugins as well.
<asbin> I'm trying to have my packages (libnfo, libplayer, and libvalhalla) reviewed before they go automatically with the Debian Import, to fiw some packages issues right now ... what do you think about it ?
<persia> ubuntustudio-audio has a selection of more apps than just ardour, if that's useful.  ubuntustudio-graphics and ubuntustudio-video may be less interesting collections of software.
<mok0> persia: he doesn't, not yet
<persia> Ubuntustudio-desktop is an interesting alternative, but that comes down to a matter of preference, mostly.
<persia> Well then, Yes, installing Ubuntu Studio is the way to start :)
<mok0> Great, I'll tell him. :-)
<lfaraone> POX: done, see http://mentors.debian.net/debian/pool/main/p/python-xdgapp/python-xdgapp_1.1-1.dsc
#ubuntu-motu 2010-02-10
<nad_> i need help getting ati propriatary drivers to work on an ubuntu 9.10 desktop
<persia> nad_: You want to ask in #ubuntu for that
<RAOF> Then you want #ubuntu or ubuntuforums.org, most likely.
<hakaishi> Hi everyone! Anyone up to advocate qt-shutdown-p? - It is a Qt program to shutdown the system at a certain time or after x minutes. It uses qdbus to send a shutdown request to the Gnome- and KDE-SessionManager or to HAL (as a last resort 'sudo shutdown -P now' will be used). http://revu.ubuntuwire.com/p/qt-shutdown-p
<zooko> Greetings, folks!
<ddecator> hey zooko
<suji11> hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me?
<rhpot1991> anyone have some time for a revu?
<EzraR> persia: any chance you will get some time to take a second look at mangler sometime? :)
<suji11> hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me?
<juan__> hi
<juan__> !foo
<ubottu> bar
<juan__> test
<RAOF> suji11: You mean, the ânative packageâ comment?
<suji11> RAOF: yes
<juan__> hi im reading https://wiki.ubuntu.com/PackagingGuide/Basic but seems it only explain how to package/build on packages that already are on ubuntu repo,I.E. it uses apt-get source,i want a guide for packages that are not on ubuntu repo,any link???
<RAOF> suji11: Normally, you get the code from the upstream developers in a .tar.gz file.  The debian/ directory is then added as a patch (the .diff.gz).
<suji11> RAOF: oh!
<RAOF> suji11: You've got what is called a ânative packageâ - the code and the packaging are both in the .tar.gz.  This is wrong, because it makes it harder to update the packaging.
<suji11>  RAOF: ok, what i should i do now?
<juan__> im in the right place or i need to join #ubuntu ?
<RAOF> suji11: Generally, what this means you need to do is to copy the upstream code tarball - which is likely to be âiok-1.3.9.tar.gzâ - to iok_1.3.9.orig.tar.gz, and put it in the directory above your unpacked source (the directory containing the debian/ directory).
<RAOF> Then debuild should pick up the original tarball, and do the right thing.
<arand> suji11: Upstream in this case means "original author": asking if you are the creator of the program. Secondly about the debian directory. The .tar.gz archive that comes with the package should (aside from in very special circumstances) be _unmodified_. In this case the original source archive (.tar.gz) should be simply the same as the archeve at https://fedorahosted.org/releases/i/o/iok/iok-1.3.9.tar.gz, all the changes to make it into an ubun
<suji11> RAOF: i think before i made a mistake. i named the orig tarball as iok_1.3.9_orig.tar.gz , but now i changed it as iok_1.3.9.orig.tar.gz then  build it  again and sent to  revu.ubuntuwire.com
<arand> suji11: ^ In response to your question in #-devel
<suji11> arand: i'm not an upstream author.
<suji11> arand: what should i change in iok-1.3.9.tar.gz.?
<RAOF> suji11: Nothing.  It should be exactly the same file you got from fedorahosted.
<suji11> RAOF: ok. now the problem is fixed. i'm right?
<zooko> http://twitter.com/zooko/status/8884301983
<zooko> ^-- "Tahoe-LAFS v1.6 has been accepted into Ubuntu 10.04 Long-Term-Support "Lucid"! http://allmydata.org/trac/tahoe-lafs"
<RAOF> suji11: Yup, that looks right.
<suji11> RAOF: ok:)
<zooko> Okay, time for sleep.
<suji11> RAOF: Can you review/advocate my package.
<RAOF> suji11: Sorry, no.  I'm busy.
<suji11> RAOF: It's ok. Thanks for your help yet.
<suji11> arand: Can you review/advocate my package.
<arand> suji11: I'm afraid not, since I'm not a reviewer, or even part of ubuntu MOTU, one thing to note, is that this time of the day seems to be very much an off-hours time for all ubuntu channels, you might have better luck at some other time .
<suji11> arand: ok fine.
<suji11> arand: Thanks for your help.
<fabrice_sp> is it good or bad practice to change version from 0.<date> (for example 0.20090101) to directly date (that is 20090101) if upstream version is the date?
<RAOF> Is the upstream version ever going to be something that's not the date?
<crimsun> if you can future-proof versioning, it's a good idea to do so. I would leave the "0." there.
<crimsun> then again, there's an epoch, so it really isn't that big a deal.
<fabrice_sp> this is the versioning scheme of upstream since 3 years, so I suppose it's a kind of  'stable'. Just for keeping it simple and thanks to epoch, I think I'll sponsor the debdiff with this version (without 0.)
<fabrice_sp> thanks RAOF and crimsun !
<crimsun> np
<kamalmostafa> james_w and/or other motu's: 'squid' is not up to date in "bzr branch lp:ubuntu/squid".  It is actually two revisions stale, which caused the person who checked in the latest revision to accidentally trash the one previous to that, causing bug 519664.
<ubottu> Launchpad bug 519664 in squid "squid FTBFS: dh_installinit: command not found" [Undecided,Confirmed] https://launchpad.net/bugs/519664
<persia> kamalmostafa: technically, squid isn't in the set of stuff we can upload, so this isn't the right channel (although you've highlighted the right person to investigate I think).  If you can untangle it, I suspect a bug subscribed to ubuntu-main-sponsors would be appreciated.
<kamalmostafa> persia: Okay, its already untangled (I've attached the simple debdiff to re-apply the missing fix to that bug).  I will subscribe u-m-s.  Thanks for the redirection.
<kamalmostafa> persia: and maybe you could unsubscribe u-u-s for me?
<persia> kamalmostafa: Sure.  Running rmadison can help you determine the component for any package.
<kamalmostafa> persia: I knew it was in main -- just got distracted when I realized i should notify james_w and did my usual "u-u-s" procedure without paying attention.  Thanks for the rmadison tip anyway.
<Speedy1> www.search2.net
<persia> Um, please stop posting that in various places.
<tolonuga> is there any way to get a totaly broken package in ubuntu fixed before release/freeze/etc? I have a complete patch and several independend test results of it, so you only need to get the tar.gz and diff.gz, create an changelog entry, push it out and it would be done.
<tolonuga> package name:openct. fixed package here: www.opensc-project.org/debian/ (upstream website).
<tolonuga> import from debian wont' work - debian didn't fix the package either (still using "hal" setup - which won't work on ubuntu, as hal was dropped)
<tolonuga> anyone?
<persia> tolonuga: File a bug against the openct package in Ubuntu, describing the issue (or find one if it is already filed).  Attach the patch.
<persia> If you want to wear an Ubuntu Developer hat, which might make it happen faster, add the patch and changelog entry, etc., build a new source package, and attach the debdiff.  The revision for the new entry should be -1ubuntu1.
<persia> Subscribe the bug with the debdiff to ubuntu-universe-sponsors.  If you have questions during the process, ask here.
<om26er> is there a manual way of making a binary package(not using pbuilder)
<sistpoty|work> make -f debian/rules binary
<om26er> sistpoty|work, thanks will try
<tolonuga> sorry, keyb broken, had to reboot.
<tolonuga> persia:thanks for the help!
<tolonuga> done - added my diff.gz, or an interdiff if that is preferered, and added ubuntu-universe-sponsor to cc:
<persia> The orig.tar.gz differs?
<tolonuga> no, only the diff.gz
<tolonuga> well, new version of orig.tar.gz (version 0.6.17 -> 0.6.19)
<tolonuga> keep "unstable" in debian/changelog or replace it with "lucid"? (with "lucid" I get an error/warning form debuild -S...)
<slytherin> tolonuga: lucid is correct
<tolonuga> hmm, how does an debdiff file help? in it I see all the upstream changes 0.6.17 to 0.6.19 - guess that isn't much help.
<tolonuga> ok, everything implemented as suggested. can anyone look at bug 519713 and push the fixes into ubuntu?
<ubottu> Launchpad bug 519713 in openct "package outdated" [Undecided,New] https://launchpad.net/bugs/519713
<tolonuga> hmm, a better title would be "package outdated and totaly broken" ...
<slytherin> tolonuga: When working on new upstream version .diff.gz needs to be attached. But if you are working on a new Ubuntu revision then .debdiff is preferred.
<tolonuga> ok. the diff.gz is the first attachment, so that is already there. it has "-0" in it, but you can easily change that and push it out?
<tolonuga> also I'm looking for someone to import latest opensc package from debian into ubuntu. the ubuntu changes to the older package can be dropped (a fix that is included in the new upstream and thus no longer needed). can anyone do that too?
<slytherin> tolonuga: for requesting syncs, the easiest method is to use requestsync tool. It fetches the changelog entries and you can provide reason to drop ubuntu changes.
<tolonuga> ok,will have a look
<tolonuga> ok, sync request send with that tool.
<om26er> where are the .deb file created
<tolonuga> hmm. is that a regression? an important bug has been fixed in opensc 0.11.8-1ubuntu2 in karmic, but the lucid package 0.11.9-2ubuntu1 does not contain the fix.
<tolonuga> if unchanged, lucid would be a regression compared karmic with fix.
<persia> That would be a regression.  If the patch isn't in Debian already, go catch your sync bug before it gets ACKed, and change it to a merge bug.
<persia> For merges, we prefer a debdiff against the revision in Debian (as we'd use the Debian orig.tar.gz)
<tolonuga> debian testing has the new version and thus can be imported without any change - the ubuntu fix was a backport from the official 0.11.12 which fixed the issue.
<persia> So a sync would make it not a regression, and the other stuff added to 11.9-2 is also in 11.12?
<sistpoty|work> om26er: one directory above
<tolonuga> yes, the sync will remove the regression and fix other things and add the latest features from 0.11.12. a win for everyone!
<persia> Cool.
<AnAnt> Hello, when's the next sync ?
<persia> whenever the archive-admin-of-the-day happens to run the autosync script.
<AnAnt> persia: how frequent is that ?
<persia> Depends on the day.  Sometimes once a day, sometimes twice, sometimes not at all.
<AnAnt> well, swt-gtk has entered testing few days ago, yet it isn't in lucid yet
<AnAnt> swt-gtk 3.5 that is
<persia> Maybe it's stuck in the NEW queue.  Have you checked that?
<persia> No, that's not it.  Just a matter of not having a sync run.
<persia> Well, there should be a sync run that happens before DIF, so I wouldn't worry.
<persia> If it still isn't present by Friday, file a bug.
<AnAnt> DIF is on friday ?
<persia> No, DIF is on Thursday, but there are archive admins all over the world, so to avoid getting into an argument about which day of the week is the right day, best to leave some slack.
<AnAnt> persia: ok, regarding LP #511069, should I set this to confirmed again , since swt-gtk 3.5 should get sync'ed ?
<ubottu> Launchpad bug 511069 in zekr "Sync zekr 0.7.5~beta3+repack-1 (multiverse) from Debian unstable (non-free)" [Wishlist,In progress] https://launchpad.net/bugs/511069
<persia> AnAnt: Wait until it's actually present.
<persia> DIF doesn't mean we can't sync, it only means that it won't happen automatically.
<AnAnt> ok
<geser> isn't FF already next week?
<persia> Yes.  The 18th.
<persia> I have a deep suspicion that after the demand over the next week, the archive-admins will never again agree to such a close relation between DIF and FF.
 * Laney is going to be going sync crazy with the new GHC transition :)
<Laney> (if it is oked)
<persia> Laney: Why do you need OK, will it not start until after DIF?
<persia> Otherwise I'd expect something to slip in, so that we didn't have a choice.
<Laney> it won't, and it will bleed over into FF
<persia> Oh, lovely.
<AnAnt> Laney: is that haskell ?
<Laney> yes
<AnAnt> I tried to prepare a haskell package once, and failed
<Laney> you should come to #debian-haskell
<AnAnt> too many dependancies, flavors
<AnAnt> Laney: I did
<AnAnt> Laney: and they removed debhelper support
<AnAnt> that was sad
<Laney> right, cdbs is the normal way
<Laney> just copy an existing library
<Rhonda> persia: When is the final sync freeze? I think I need to request another one for ejabberd, fixing a CVE.
<Laney> bug fix uploads are almost always OK
<Laney> up to final freeze, then they need to be serious and minimal (security will still be alright)
<Rhonda> Laney: â¦ "up to the final freeze" which is when? :)
<Laney> errrrrrr
<Laney> https://wiki.ubuntu.com/LucidReleaseSchedule <- april 15th
<Rhonda> Alright, I look it up myself
<Laney> (maybe later for universe)
<Rhonda> Thought you'd know it out of the head, sorry for making you hunt for it.
<Laney> it's alright, the release schedule is in my history
<slytherin> Laney: Did you see the build log I sent yesterday
<Laney> slytherin: yes, thank you. Unfortunately the interesting part was just after that step :)
<Laney> but no worries, somebody else tried it on a ppc porterbox for me
<slytherin> great
<geser> slytherin: do you know if could/should sync jabref? from a quick look at the changelog it looks like the ubuntu delta got included in the debian package (in unstable)
<geser> but as the version string contains beta I'm not sure if we should sync or not (a sync would also allow to move it into universe)
<slytherin> geser: I am not very keen on syncing beta version.
<geser> ok, so we keep then 2.5
<\sh> dholbach: when do you update http://qa.ubuntu.com/reports/sponsoring/ ? every hour or once a day?
<dholbach> \sh: every 15 minutes
<\sh> dholbach: cool. thx :)
<dholbach> once the list is smaller again I can update it more often ;-)
<\sh> dholbach: working on it ;)
<dholbach> ROCK!
<filip> hi, I have a problem with debconf (db_subst). This setup: http://pastebin.com/mb1f7802 doesn't work (suggested value is "${default}")
<filip> it seems to be done according to the debconf manual...
<slytherin> dholbach: Did you get my message in #ubuntu-kernel? My IRC client is giving weird error.
<slytherin> never mind found the problem
<dholbach> slytherin: nope, didn't get it
<slytherin> my nick was not identified. :-)
<\sh> dholbach: could you sponsor bug #506908 for torsten spindler? (provided an updated debdiff, so it follows our standards) (it's main, as it was wrongly added to universe sponsor queue it seems)
<ubottu> Launchpad bug 506908 in pcsc-lite "Upstart job for pcscd" [Undecided,In progress] https://launchpad.net/bugs/506908
<dholbach> \sh: I'd prefer if somebody would sponsor it who has actually looked at an upstart job before because I haven't :)
<\sh> dholbach: for me the upstart job looks very much ok and very clean :) but I'm not keybuk ;)
<\sh> anyways subscribe main sponsors
<\sh> +d
<dholbach> thanks \sh
<\sh> dholbach: your expertise, should we fix those debdiffs, or just unsubscribe sponsors and waiting for bugfixer coming back with a correct debdiff ? (bug #368017)
<ubottu> Launchpad bug 368017 in fet "Wrong description" [Wishlist,Confirmed] https://launchpad.net/bugs/368017
<dholbach> \sh: I'd prefer if we would just add the changelog entry, upload and be done with it - extra points for a small message saying "this is how I produced a debdiff"
 * persia would prefer that the sponsors queue wasn't so strongly recommended to all and sundry arbitrary patch authors, and that we had a better way to catch patches.
<dholbach> ?
<dholbach> why less recommended?
<persia> Because I don't think there should be any expectation of any relation between people who submit patches to launchpad and people who care about uploading to Ubuntu.
<dholbach> what does that mean?
<persia> The "right way" to get something into Ubuntu shouldn't have to involve making a debdiff, although I think the "right way" for someone to do sponsored uploads to Ubnutu should.
<dholbach> if we would put more work into getting all the bugs with patches closed, we wouldn't need the sponsoring process
<persia> I disagree vehemently with that statement.
<persia> To me, the sponsoring process is a way that those who wish to become Ubuntu Developers can demonstrate their skills before being granted upload access.
<dholbach> I don't think it really matters
<dholbach> we should be better at spotting fixes and making Ubuntu better
<persia> I see no relation between this and any activities related to processing patches that fix bugs, except insofar as I expect Ubuntu Developers (both current and prospective) to look for patches and get them uploaded.
<dholbach> if somebody wishes to apply, they're happy to do that
<dholbach> and I encourage them
<\sh> I do understand persia...
<persia> \sh: Thanks.  Sometimes it seems that nobody bothers to think about what I write :)
<dholbach> it's a distinction which doesn't make the world exactly easier - the bigger problem we have is that there's not enough people willing to get the 2000 bugs with patches reviewed
<\sh> the problem with debdiffs from "non wanna ubuntu devs" is that they are on the merger list for the next cycle and nobody will take care until DIF and sometimes it's too late
<persia> \sh: There's that.  There's also that patch submitters get annoyed with the frustrating processes and complain about us.
<dholbach> ... and I didn't disagree with that
 * persia doesn't want to bother spending effort training anyone to follow Ubuntu processes unless they have an interest in being part of Ubuntu, rather than just submitting bugfix patches
<dholbach> persia: and I didn't say you should
<persia> dholbach: No, but my argument is that conflating "sponsoring" with "patch review" implicitly makes it awkward to distinguish between the two classes of patches.
<persia> So I'd much rather see random folk told "attach a patch in a bug in LP", and have developers (both current and prospective) hounded to get those patches in.
<dholbach> right, it's just that the distinction between to me is much less important than getting the 2000 bugs with patches closed or tended to :)
<persia> And I think that's separate from supporting people who can do the work but just can't upload yet.
<dholbach> in both cases it's stuff we want to get into the distro to make it better
<persia> dholbach: I understand.  I even agree that it's less important.  I'd just prefer that there was more focus on looking for the patches, and less focus on telling people to use the sponsoring process.
<dholbach> ok, good - I probably should have said "in an ideal world we wouldn't have 2000 bugs with patches to tend to and wouldn't have to have a process which makes getting patches looked at more complicated than it should be"
<dholbach> in the meantime, until we can tell patch submitters apart from each other (willing to learn more about ubuntu development or not), I'd suggest attaching your debdiff to the bug, so they can take a look at it, but not block on "attaching a debdiff"
<persia> That's close to my view, but if you don't consider the sponsoring process to me the process for getting patches looked at, then you don't have that issue.
<persia> So, I7d rather say that the sponsoring process is *only* for prospective and current Ubuntu developers, and have the patch submisison process be as simple as ticking a checkmark on LP.
<persia> If you want to get more people looking at these 2000 patches, have them look there, rather than fussing with the sponsorship process in a way that makes it harder to train new developers.
<dholbach> we don't even cope well with the n+1 sponsoring items we have
<persia> Sure, but tossing those into the mass of unlooked-at patches only makes it worse, in my opinion.
<persia> If the sponsoring queue only contained stuff that was written by people who are now, or are seeking to be Ubuntu Developers, the quality should rise, and that should make it less annoying to sponsor stuff.
<dholbach> I wasn't saying "let's get rid of the sponsoring queue"
<dholbach> ... now
<persia> That said, we *do* need an active team to be chasing the 2000 patches, but I don't think any of them should be subscribed to the sponsors queue: that just complicates the process for submitters and frustrates sponsors.
<dholbach> Realistically, the sponsoring queue is where 90-95% of patches/branches from LP come from.
<persia> I don't think so.  Only about 10% of patches are currently shown on your list.
<persia> But even were that true, I'd argue that we should be focusing on making that not true, rather than trying to push more patches through that mechanism.
<dholbach> sorry, I was unclear
<dholbach> I meant to say that 90-95% of the branches/patches form LP that go into Ubuntu come through the sponsorship process
<persia> Right.  My argument is that this represents a failure of Ubuntu Developers to dig up patches properly.
<dholbach> yes, I'd very much like to see a solution to that problem
<persia> I'd much rather see strong focus on getting more developers to be proactively searching for patches than to push more patches into the sponsorship queues.
<dholbach> Do something!
<persia> Because lots of developers don't need to get sponsored, and so it is wasteful to push it in the queue.
<dholbach> eh?
<persia> So, if we say that the process for getting a patch reviewed is to stick it in the sponsors queue we 1) make the process complicated and 2) don't tell developers to go hunt patches.
<persia> If we say that the process for getting a patch reviewed is to attach it to a bug in launchpad, we 1) make the process easy, and 2) are in a stronger position to tell developers to go hunt patches.
<dholbach> were you in the fixing-bugs-with-patches session at uds?
<persia> If some developer fixes something and can't upload, we can fall back to the sponsors queue.
<persia> I've tried to attend that session for the past 4 UDSs.
<persia> I don't know if I was in the one you mean now.
<dholbach> that blueprint is the best place to discuss this :)
<persia> What7s the URL?
<\sh> last uds was usa now this time of the year is back in europe ?
<persia> \sh: Probably.  It seems to mostly swap between those two and never come here :)
<dholbach> https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-qa-fixing-bugs-with-patches
<dholbach> and I think you were
<dholbach> but anyway, I need to head out now
<dholbach> see you later
<persia> dholbach: I agree with just about everything on that blueprint except that I don't think it's related to sponsoring :)
<oojah> As an outsider looking in, from what I've read I'd expect the sponsorship queue to be for people that don't have upload rights to a particular component, mostly likely because they're a prospective developer but also possibly because they want to fix something in main and only have universe rights.
<persia> oojah: It's also important for people working on the edges of package-sets.
<Daviey> oojah: yes, but also enables better peer review.
<persia> Daviey: Well, except we've historically rejected submissions by those who could upload :)
<Daviey> :)
<persia> For peer review, we tend to just ask in IRC for someone to look at a debdiff or something.
<Daviey> which is less than ideal IMHO
<persia> Daviey: Well, I think the idea was that peer-review happened post-upload :)
<Daviey> which is much much less than ideal :)
<persia> We can generally fix each other's mistakes, and sometimes changelogs end up looking interesting (ubuntu-dev-tools for the security/deprecated schroot.conf lines, or the old nvidia-settings package were two cases I was involved with)
<persia> I guess, but with the package:developer ratio being as high as it is, it tends to be faster (as most of us ask if we need and don't make too many mistakes otherwise)
<oojah> Right, ok on both counts.
<_stink_> hey folks.  i have an upstream package that has its source split into directories named client/, server/, utils/, etc.  I want my rules files to only build what's in client/.  Manually I can cd client/; make and it works fine, but it seems that no matter what i try in the rules file, it *always* tries to make everything.  any idea how I build only one subdirectory in a source package?
<sistpoty|work> _stink_: "make -C client" instead of calling "make" in rules?
<_stink_> ahhh yes.  -C.  duh me
<_stink_> sistpoty|work: thanks!
<sistpoty|work> yw
<persia> Using dh(1), one can also pass --sourcedir client to dh to acheive a similar result.
<abogani> Hi All, I have a simple question for you. I'm working on packaging of new software which depend from avr-libc. Meanwhile I'm working on my stuff I have noticed that avr-libx seems don't be FHS compliant. Is it possible?
<abogani> Could header files be placed into /usr/lib/avr/include ?
<abogani> Don't should be /usr/include/avr a better place? ?
<persia> Changing stuff to be FHS compliant is always good.  That said, one has to look at all the rdepends to make sure they won't break (and reverse-build-depends for libraries).
<persia> This often ends up being a fairly sizable transition, and is often best coordinated also with any Debian maintainers and upstream.
<kmdm> Don't suppose anyone has the command to hand to sign a .changes file? (Mind's gone blank on me :( .)
<jpds> kmdm: debsign?
<kmdm> jpds: Perfect, thanks ;)
<bjsnider> siretart, ping
<siretart> yes?
<siretart> please avoid contentless pings. I don't like them
<bjsnider> siretart, is ffmpeg fixed upstream? when i refreshed it and installed the packages, it broke everything
<bjsnider> i'm sure it was from the master branch
<siretart> please be more specific. what breaks exactly?
<bjsnider> mplayer complains about not being able to find libavutil shared libs, and the gstreamer ffmpeg package loses track of the codecs it needs
<siretart> mplayer: really libavutil and not libswscale? pastebin please.
<siretart> gstreamer: no idea, please ping slomo and/or bilboed
<bjsnider> alright, hold on aminute i'll have to reinstall the stuff
<bjsnider> mplayer: error while loading shared libraries: libavutil.so.49: cannot open shared object...
<siretart> mplayer depends on libavutil49 which provides that lib. if you removed it, then your packages and/or system are broken
<bjsnider> libavutil-extra-49 is installed here
<siretart> then check why mplayer fails to find libavutil.so.49
<bjsnider> well, the library version is no lnger 49, it's named 50
<bjsnider> do i have to rebuild everything that might possibly use ffmpeg for this to realistically work?
<bjsnider> i planned on refreshing mplayer, but not necessarily much else
<siretart> if you are using the mplayer package from lucid, then it depends on libavutil49 and that must be installed
<siretart> depends declares a hard dependency. period
<bjsnider> this should actually be renamed to libavutil50. i can't have my cake and eat it too where both 49 and 50 are there at the same time can i?
<siretart> the point of the excercise of soname handling is that you can have both libavutil49 and libavutil50 installed at the same time
<persia> It's much preferred not to provide eaten cake, as this requires significantly more maintenance overhead.
<sistpoty|work> persia: shared libraries must be made to coexist, otherwise bad things happen.
<bjsnider> then if i renamed all of my ffmpeg packages, so they didn't upgrade over the karmic ones, this would work
<sistpoty|work> persia: just assume libc7 would conflict with libc6 ;)
<persia> sistpoty|work: I agree that foo.so.1 and foo.so.2 should be in the libfoo1 and libfoo2 packages, but I'd prefer to just have libfoo-dev, and tell everyone to rebuild the world :)
<siretart> you'd still have to change the SONAME of all libs (which is nontrivial) and change shlibs file to match that change (trivial)
<bjsnider> siretart, how do you mean change the SONAME?
<siretart> persia: that's what happening with ffmpeg, BTW.
<persia> siretart: Right.  My comment about eaten cake was an argument against providing libavutil49-dev and libavutil50-dev, but apparently insufficiently clear.
<siretart> bjsnider: sorry, please read up on that yourself. Try levine's book Linkers and Loaders, chapter 10. I'm currently at work
<siretart> persia: agreed
<bjsnider> oh, i see what you mean by soname. but that's already changed int he -49 packages. they've already been bumped to 50
<bjsnider> siretart, thanks for the help. sorry for being a pest.
<siretart> bjsnider: sorry for being so rude, I'm as said at work and your question are quite confusing to me TBH
<bjsnider> i have to invent my own terminology because i don't have a programming background
<persia> bjsnider: The encouraged alternative is to ask lots of stupid questions in appropriate fora until you are using the same terminology :)
<persia> Err, s/stupid/potentially apparently stupid/
<bjsnider> persia, yes, that's exactly it...
<bjsnider> what i don't understand is, if a package is looking for a shared lib version 49 for instance, but version 50 is there instead, why doesn't it pick that up and talk to version 50?
<persia> bjsnider: You might find running nm against your binaries to be instructive, or review any of the MOTU/School library packaging sessions documented on the wiki.
<geser> bjsnider: from where should the app know how to talk to version 50 if it only knows how to talk to version 49?
<persia> Might be clearer if we remember that the differences here aren't just arbitrary versions, but rather represent differing ABIs
<bjsnider> persia, but would the abi be so different that breakage would result?
<bjsnider> geser, why does it only know to talk to -49? why can't it look for any version to talk to?
<geser> bjsnider: imagine the app provides a 32bit int and the lib expects a 64bit one at that location
<bjsnider> or is it that th abi is so different that it wouldn't matter
<geser> bjsnider: from the headers for the lib it was compiled with
<geser> bjsnider: the difference might be small or big depending on what exactly has changed
<persia> bjsnider: The ABI breakage is sufficient that applications compiled against the old version will experience some problems.  The nature of these problems depends on the nature of the change.
<persia> There are many ways to change ABI without changing SONAME, but when SONAME changes, there's usually no going back.
<kreuter> howdy, #ubuntu-motu.  does upstart support running daemons under uid/gid other than root?
<persia> kreuter: I *think* so, but it might require trickery.
<persia> You might ask in #ubuntu-server: they tend to try to put stuff in chroot jails *and* use upstart.
<kreuter> hm.  okay.  thanks!
<rmunn> Can I get a MOTU to look at http://revu.ubuntuwire.com/p/python-nltk? I believe it's ready to go into Lucid now, it just needs advocates.
<persia> rmunn: DEP5 calls for a separated License: stanza when using the same license in multiple Files: stanzas (PSF-2)
<persia> And I've not seen debian/clean before.  Nifty :)
<rmunn> persia, What do you mean by a separated License: stanza? I don't quite follow.
<persia> http://dep.debian.net/deps/dep5/ : see the bit about "Standalone License Section"
<rmunn> persia, I wanted to do "Files: nltk/a.py, nltk/b.py, nltk/c.py \n License: PSF-2" but didn't read the spec as allowing that.
<\sh> hmm..well...the universe taggeed sponsor queue looks more empty now regarding dholbachs new page
<rmunn> persia, Ah, I understand now. So basically, I just need to add a single newline and a new "License: PSF-2" line that's standalone.
<persia> rmunn: I think you can do that, for the same license and copyright, etc.
<persia> e.g. Files: "Program Files/*", manual[english].txt
<rmunn> persia, Should I do that now and re-upload, or wait until you're done looking at the rest of the revu entry so there's only a single new upload?
<persia> But I don't think you can do it for this source, because the Copyright lists differ
<rmunn> persia, Ah yes, that was the problem -- different copyrights.
<persia> Oh, just reupload it.  I don't see anything else obvious, except that I would have used rules.tiny and debhelper 7
<rmunn> persia, Been a week since I started working on this, so I'm forgetting some of the details of what I did at first. :-)
<rmunn> persia, It's my first package, I used CDBS because it seemed easier to get started with than debhelper. Never heard of rules.tiny -- where can I read about it?
<persia> /usr/share/doc/debhelper/examples/rules.tiny and `man dh`.
<persia> But actually, you need to patch it, so you'd have to do something like --with-quilt, and then reformat the patches, etc.
<persia> Just leave it CDBS.
<\sh> bddebian: ping mush you filed a removal request in debian for this package :)
<\sh> bddebian: dead upstream, dead maintainer, dead what?
<sebner> persia: rmunn or you upgrade to debsrc3.0 so you also don't have to worry about patching ;)
<rmunn> persia, Uploading, should show up on REVU in 5 minutes
<persia> sebner: Well, kinda.
<Laney> oh, while I remember, does anyone know of a way to specify arch-indep build rules with DH7?
<Laney> I don't know of a convenient way to have my docs only built when building the arch:all package
<persia> Laney: What are you trying to accomplish?
<rmunn> sebner, Is debsrc3.0 available on Karmic, or should I switch to my Lucid virtual machine for building packages from now on?
<sebner> rmunn: debsrc3.0 is only available for lucid and newer
<bddebian> \sh: NPOASR (Never part of a stable release) :)
<sebner> huhu bddebian :=
<sebner> :)
<rmunn> So far the only downside I've found to building packages on Karmic is that lintian thinks "lucid" is an invalid Ubuntu version name.
<Laney> persia: some processing is required to generate html documentation, but it's wasteful to do it everywhere
<sebner> rmunn: you can upgrade to lucid lintian version
<persia> Laney: Compare `dh binary-arch --no-act` to `dh binary-indep --no-act` in your source package.  The sequences should differ slightly, and this may help you figure out how to make it work.
<RoAkSoAx> hey guys anyone know if dput to PPA's is broken?
<persia> RoAkSoAx: Ask in #launchpad
<RoAkSoAx> persia, will do :)
<rmunn> persia, New upload is up at http://revu.ubuntuwire.com/p/python-nltk, thanks for the feedback on DEP5
<\sh> bddebian: well, the whole package is horse-dung ;)
<rmunn> lintian still warns me about "build-depends-without-arch-dep python-yaml", but python-yaml is required for the "clean" operation (because setup.py ends up importing something that imports it) so I can't get rid of that warning.
<Laney> persia: Actually, they differ in that -a is passed for the arch build, and -i for the indep, and that dh_strip, dh_makeshlibs, dh_shlibdeps are not invoked in the indep case
<Laney> so I don't see anywhere to hook in there :(
<persia> Laney: Do you have different targets available in the upstream build system?  You could do something with override_dh_auto_build:
<Laney> No, I don't use their buildsys
<persia> How do you build it?
<Laney> I just have to run agda on one file
<persia> Could you point me at your debian/rules?  That might make it easier for me to critique it :)
<bddebian> \sh: Agreed :)
<Laney> yes, I'm getting to it... git.d.o is being slow
<Laney> persia: http://git.debian.org/?p=collab-maint/agda-stdlib.git;a=blob;f=debian/rules;h=b23dfc54e31fab28f5087290350b11bb5c556557;hb=HEAD
<\sh> rmunn: did you try Build-Depends-Indep, you don't build any arch dependend stuff in it...topic 7.7 in http://www.debian.org/doc/debian-policy/ch-relationships.html
<rmunn> Haven't tried yet, but 7.7 says Build-Depend must be satisfied when clean is invoked. Running clean runs "python setup.py clean", and upstream's setup.py does "import nltk", which in turn does "import yaml" -- so if yaml isn't around, "setup.py clean" fails with an ImportError.
<\sh> rmunn: or you find a linitan bug...
<rmunn> So since python-yaml is required for the clean step, I followed policy and put it in Build-Depends.
<\sh> "The matrix is based on rules, you can't break the rules, but you can bend them" ;)
<\sh> in the end, you found a lintian bug ;)
<sistpoty|work> rmunn: iirc build-depends-indep aren't installed on clean, even though policy says otherwise
<persia> Laney: Sorry.  Got distracted.
<Laney> no worries
<\sh> sistpoty|work: I think lintian is right, because python-yaml (the module) is not actually seen by linitian but python is...false positive
<persia> Laney: If you use sbuild, you might try showing the environment variables in override_dh_auto_build with and without -A and see if you can find a useful difference.
 * persia suspects there's a way to do this with pbuilder, but doesn't know the details.
<Laney> I fear that we get into the realm of "more trouble than it's worth"
<Laney> I could just make a binary-indep target and do my building in there
<persia> Laney: Fine.  I'll get the variable :p
<Laney> before "dh binary-indep"
<sistpoty|work> \sh: sounds like it, yeah
<Laney> persia: Something like this â http://paste.ubuntu.com/373360/
<persia> Laney: I'm not convinced that works with dh: man dh
<persia> Oh, "binary-indep" rather than "build-indep".  Right, yes.
<persia> I'd probably do it with an override_dh_binary_indep: rule that depended on a documentation: rule and called dh_binary_indep internally.
 * Laney knows not about dh_binary_indep
<persia> Err, except that wouldn't work, and I'd end up doing it your way :)
<Laney> let's fire off a test build
<maxb> Laney: The most palatable way I've found is to put the conditional in shell:   if dh_listpackages | grep -q '^mybinaryindeppkg$$'; then .....
<persia> I like manually defining build-indep: better than that.
 * Laney too
<sebner> Laney: I'm wondering about your (old) --before --after stuff too
<Laney> sebner: how would you do it?
<Laney> bear in mind that the binary-indep target runs the whole debhelper sequence
<sebner> Laney: I don't know about that indep stuff but we also had this --before and --after stuff with old debhelper (e.g configure) so I'm wondering if you can just make ist like the new way
<Laney> I don't know how. And there are bound to be cases where defining the targets is still useful... maybe this is one of them
<sebner> Laney: I'll give it a try later too
<\sh> I thought dh7 should make lifes easier ;)
<Laney> this --before and --after stuff is really just a condensed way of writing out all of the dh_* commands in a pre-dh7 style rules file
<Laney> \sh: I do think this is easier than the old way really
<\sh> Laney: depending on your training imho..
<Laney> of course, some people don't use debhelper at all :)
<persia> Grr.  echo ${ENV} didn't do what I wanted.
<\sh> Laney: actually cdbs is also a black hole for me...people should know what the tools are doing so they understand the whole system...without knowing the old school you don't understand the new school ;)
<Laney> \sh: ha, when using cdbs I end up reading the source more often than not
<Laney> trading surface simplicity for below-the-surface complexity
<\sh> Laney: well...beginners don't and even when they do that, they wouldn't understand much ;)
<rmunn> Well, moving python-yaml into Build-Depends-Indep: instead of Build-Depends: seemed to make no difference as far as pbuilder was concerned... should I re-upload http://revu.ubuntuwire.com/p/python-nltk with a new debian/control even though that seems to be against (my reading of) Debian policy section 7.7?
<sistpoty|work> for a lesson, I tried to package completely without helpers. funnily I almost got it right on the first try
<Laney> rmunn: pbuilder always builds arch-indep afaik
<\sh> sistpoty|work: do you remember ajmitch' lesson when we opened ubuntu-motu-school long time ago? :)
<persia> Right.  The make manual fails me.  If anyone has a good command that prints out the entirery of the environment from within make, I'm happy to test to see if there's an arch-indep solution.
<sistpoty|work> \sh: right, probably I got the idea from him ;)
<rmunn> This is my first "real" package (as opposed to following along with the exercises during ubuntu-classroom sessions) so I've reached the limit of my knowledge so far.
<Laney> hmm
<\sh> rmunn: as said, you hit a false positive..for linitian python-yaml is not existent, but setup.py which is executed during clean needs it ... for linitian only python is a needed build-dep...file a bug on linitian ;)
<Laney> from reading /usr/bin/dh, I don't think that binary-indep even does any building
<Laney> so I don't know if --before dh_auto_build will work
<rmunn> It seems like http://revu.ubuntuwire.com/p/python-nltk is almost ready, and I'd like to get it into Lucid before Feature Freeze -- but I don't know the right answer to this Build-Depends/Build-Depends-Indep problem.
<Laney> I could just build the docs and then dh $@
<slytherin> is there any reason why 'dh_install --fail-missing' wouldn't report error on i386 buildd but reports problem everywhere else.
<rmunn> \sh, Okay, so no changes needed to debian/control? Great, that means I *might* be finished with repeatedly re-uploading to REVU now... :-)
<rmunn> Unless another MOTU comes along and points out yet another newbie mistake of mine... :-)
<Laney> slytherin: something to do with b-d-i?
<\sh> rmunn: please document this "behaviour" somewhere in revu and file a bug against lintian (debian + ubuntu)
<\sh> slytherin: arch indep files? which are only build on i386?
<rmunn> Already mentioned it in one part of one of my REVU comments, but I'll put it in a separate comment so it's easier to see.
<james_w> that's not a lintian bug
<\sh> james_w: then?
<james_w> it should be an override in the package if you care about it
<slytherin> Laney: There are no b-d-i
<Laney> is there an arch:all package?
<slytherin> \sh: The files are simply being copied.
<Laney> hmm
<slytherin> yes the problem happens with -doc package
<\sh> james_w: that's something to override lintian false-positives...
<slytherin> \sh: Laney: here is the relevant code - http://paste.ubuntu.com/373371/
<james_w> \sh: and this isn't one of those?
<\sh> rmunn: but james_w is right...prepare a lintian override for this message
<Laney> \sh: So you put the files in place and then presumably they will only get installed when doing an arch-indep build
<Laney> erm, slytherin. sorry \sh
<\sh> james_w: if it is an reported lintian error, I would say it's a bug of lintian, if it's just a warning, I would say the way to go is an override
<slytherin> I didn't do it. I am just looking at FTBFS. :-)
<Laney> well "the build" then
<Laney> I'd just copy the files from their location in the source tree instead of doing that cp at all
<slytherin> Laney: Perhaps you are right. I guess I will change it to --list-missing
<\sh> james_w: as this is an informational message, override is appropriate
<sebner> slytherin: I'm wondering about the --fail-missing option. doesn't install fail anyways when a file is missing?
<\sh> rmunn: prepare an lintian override for this warning in your package...and file a bug against revu to not declare an info as common error, ;)
<Laney> no, it fails the build when you forget to install a file into a binary package
<slytherin> sebner: No --fail-missing means if the file is not included in the resulting package.
<sebner> ah ic
<Laney> presumably it could be made more clever though
<Laney> if no _all package then ignore stuff under /usr/share
 * Laney -> home
<sebner> Laney:  bye
<persia> james_w: Why isn't it a lintian bug again?  Lintian is suggesting to do something that doesn't match policy.
<james_w> lintian explains that if the package isn't used in clean it shouldn't be there, so it's suggesting to you two options
<james_w> it has a global list of ignores, but is it right for every package to have python-yaml in Build-Depends? no.
<rmunn> In this case, the package *is* used in clean, but it's about two dependency levels deep via Python imports, and lintian doesn't have a good way of knowing that it's necessary...
<persia> Well, lintian could run debian/rules clean as part of the check :)  But yeah, I can see how it's annoying and/or awkward to fix.
<james_w> you could file a wishlist bug asking for them to execute python code to work out if that module will be loaded from a site directory during a setup.py clean
<james_w> but if the package is deviating from the norm then you should override lintian where you know better. That's exactly the advised policy.
<rmunn> james_w, that seems dangerous to me -- what if someone uploaded a malicious package to REVU with a setup.py that did all kinds of nasty stuff when imported?
 * persia completely agrees that an override is appropriate
<james_w> if lintian is wrong in (nearly) every case or can easily be made to spot your case then file a bug on it, otherwise if you know better then override it if you care about lintian cleanliness
<rmunn> Override created and new version uploaded to http://revu.ubuntuwire.com/p/python-nltk, should show up in a minute or two
<james_w> rmunn: exactly
<kamalmostafa> james_w: hello -- "bzr branch lp:ubuntu/squid" yields a (quite) stale branch -- give it a poke?
<rmunn> Okay, my override didn't work. Anyone want to look at http://revu.ubuntuwire.com/p/python-nltk (check the debdiff against previous version, that's easiest) and tell me what I did wrong in creating the debian/source/lintian-overrides file?
<james_w> hi kamalmostafa
<james_w> you know about http://package-import.ubuntu.com/status/
<james_w> rmunn: debian/source.lintian-overrides
<rmunn> I thought I followed the syntax in http://lintian.debian.org/manual/ch2.html precisely... there's probably *something* obvious I'm missing, but I just don't see it
<rmunn> "If the override is for a source package, you have to place it at debian/source/lintian-overrides or debian/source.lintian-overrides (the former path is preferred)." I used the former path.
<james_w> oh
<rmunn> Now *that* is a lintian bug, if debian/source/lintian-overrides doesn't work despite the manual saying it does. :-)
<persia> It does work, at least I've seen it work.  I don't remember the syntax perfectly though.
<kamalmostafa> james_w: no, I didn't know about import-status.  It's quite bewildering.  :-)
<\sh> rmunn: source.lintian-overrides did work in the past...;)
<james_w> kamalmostafa: indeed, it needs some ui love :-)
<james_w> rmunn: not sure why that's not working
<kamalmostafa> james_w: So I see that it does reference 'squid', but I don't know what to make of its error detail (python error stack).  And I note that its squid error log is dated 6 days ago.   What's your interpretation of it?
<rmunn> Which version of lintian is running on REVU? Even on my lucid box, lintian --display-info isn't complaining about this. Only when I upload to REVU do I get the warning. Makes it kind of hard to fix without a dozen re-uploads, when I can't seem to reproduce the problem locally...
<james_w> kamalmostafa: error in james_w I believe
<rmunn> I'll try source.lintian-overrides, see if that makes REVU happier.
<james_w> rmunn: don't bother
<james_w> it's probably hardy or something, if it works fine on later versions that's good enough
<kamalmostafa> james_w: Okay then, I'll consider the issue "reported" (unless you can tell me what package to report james_w bugs against?  ;-).
<james_w> kamalmostafa: two ticks
<sistpoty|work> rmunn: lintian on revu is from hardy, as spooky (revu's host) is still running hardy. just ignore it's output as james_w suggested
<sistpoty|work> (and nobody dares to update spooky to post hardy, since it's a sparc box and sparc status in anything past hardy is suboptimal)
<persia> Um, lintian on REVU is 2.2.17ubuntu1.1, which is the same as karmic-updates: there's been some backporting (but it's still out of date)
<persia> (hardy-backports is only 2.1.2ubuntu1~hardy1)
<rmunn> Well, I'd already kicked off an upload with a debian/source.lintian-overrides, and that worked.
<jdong> *seems to recall a backport request to at least some Ubuntu release*
<jdong> maybe not Hardy.
<sebner> bddebian: did you already have time to take a look at http://paste.ubuntu.com/373384/ ?
<jdong> if not, that would be a good idea (tm) :)
<rmunn> But REVU still says "At least one common error: check the lintian file." Said lintian file contains nothing but "N: 1 tag overridden (1 info)". :-)
<persia> jdong: I seem to recall there being some issue with getting current lintian on spooky other than just procedural, although backporting to at least karmic may have value.
<sistpoty|work> persia: oh, cool, so someone did backport it in the meantime :)
<persia> sistpoty|work: Yep.  Might have even been you :p
<sistpoty|work> persia: no, I recall that my try failed due to some perl errors, and I reinstalled the old version ;)
<jdong> persia: right; I was thinking more the usecase of contributors that are still on Hardy themselves
<james_w> kamalmostafa: queued
<persia> jdong: Hrm.  We do have some of those, but not so many (or they work in chroots).
<jdong> yeah I'd expect the latter to be common :)
<sistpoty|work> jdong: while you're at it, you could also do dpkg so that revu can handle v3 packages :P
<jdong> I've definitely seen people request backports of lintian but usually just to the n-1 releases
<jdong> sistpoty|work: hehe that sounds like something I'd be a bit more scared to touch :)
<jdong> I don't want the trophy for most broken update ever ;-)
<sistpoty|work> heh
<persia> What we need is someone to make sure the SPARC kernels work.
<rmunn> Okay, so the only changes I've had to make recently to http://revu.ubuntuwire.com/p/python-nltk have been cosmetic. Does that mean it's ready for some MOTU advocates?
<sistpoty|work> or a different box for revu :P
<Laney> yeah, setting a binary-indep target doesn't work
<Laney> at least pbuilder doesn't call it during the build
<james_w> kamalmostafa: squid up to date, thanks for the reminder
<persia> Laney: Are you doing arch-dependent or arch-independent builds?  I know sbuild has the -A option which, on the buildds, is only enabled for i386.
<Laney> persia: pbuilder has no such option
<Laney> AFAIK, at least. And anyway it tried to build the indep package without running the corresponding binary-indep target
<persia> Well, try in sbuild then, is all I can say.  If you're running lucid, you can pull the latest ubuntu-dev-tools from trunk, and use mk-sbuild to create tarball schroots which only take up as much space as pbuilder (no more need for LVM)
<james_w> kamalmostafa: it produced https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/squid/lucid-201002101821/+merge/19038
<james_w> kamalmostafa: is that the dropped upload you were talking about?
<Laney> persia: will do, thanks
<persia> Laney: Note that despite constantly talking about sbuild, I do approve of using pbuilder, because I suspect that otherwise we'd have a hard time distinguishing bugs in policy from bugs in sbuild.
<james_w> kamalmostafa: ah, it's ok, I see what happened
<Laney> I know, but I also know that sbuild supports selective arch/arch+indep builds, which pbuilder does not, and that I would like to test in this case.
<persia> Laney: Indeed.  I don't know if I'll finish by FF, but I'm hoping to find a way to get sbuild to reuse pbuilder tarballs soon.
<persia> (although if I miss FF, I'll get distracted and may not get back to it any time soon)
<kamalmostafa> james_w: back now ... can I answer any questions about the squid issue, or do you have matters in hand?
<james_w> kamalmostafa: it's all good thanks
<oojah> Could someone please review http://revu.ubuntuwire.com/p/sqlite3-pcre ? It's had a few suggestions already so should hopefully be pretty sane. It's a very simple package, the only slightly unusual bit being that it gets the source from git.
<RoAkSoAx> james_w, ping
<james_w> hey RoAkSoAx
<RoAkSoAx> james_w, heya!! I just merged my first package using bzr... would you mind reviewing / uploading it please? https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/519940
<ubottu> Ubuntu bug 519940 in keepalived "Please merge keepalived 1.1.17-2 from debian testing" [Low,Confirmed]
<james_w> RoAkSoAx: looking
<DktrKranz> could a revu admin help me to track what happened to ubuntuwintv_0.7.1-0ubuntu1 upload? TIA
<james_w> RoAkSoAx: uploaded
<RoAkSoAx> james_w, thanks :)
<persia> DktrKranz: I don't see it in any of incoming, uploads, or rejected.  I'm guessing either the upload didn't happen correctly, or it worked.
<DktrKranz> persia: thanks, I'll ask to reupload again
<persia> DktrKranz: I can't find it in the archived list either.  A new upload is probably best.
<RoAkSoAx> james_w, btw.. starting from when do we have to use bzr as mandatory?
<james_w> RoAkSoAx: 5 minutes time
<james_w> RoAkSoAx: nope, it's not mandatory, just really good
<RoAkSoAx> james_w, oh ok, thought it's going to become mandatory to use bzr over time
<james_w> RoAkSoAx: maybe one day
<james_w> but there are currently no plans
<RoAkSoAx> oh I see, well I guess i can use both methods while mastering the use of bzr :)
<bddebian> sebner: No, was I supposed to?
<sebner> bddebian: Well, I showed it some days ago to you. Maybe you missed it. Currently discussing in debian-games on oftc
<imi> hi
<persia> Hey
<Laney> hm, so it looks like sbuild uses binary-arch when doing an arch-dep build, and binary when doing arch+indep
<Laney> but binary doesn't depend on binary-indep
<imi> https://bugs.launchpad.net/bugs/519013 -- I was suggested to try backports as kdevelop may have a newes version in backports. actually, it doesn't have. Since I used to contribute packages to an other dpkg based distribution, I'm considering to build one on my own
<ubottu> Ubuntu bug 519013 in kdevelop "upgrade kdevelop please" [Undecided,Invalid]
<JontheEchidna> hmm, I thought somebody had backported a never version than what was in karmic
<JontheEchidna> guess not though. I'll open up a karmic-backports task
<imi> it does not have a backport package, I've just checked it at packages.ubuntu.com
<Laney> yeah, something is wrong with building sid chroots (at least with mk-sbuild)
<Laney> it installed half the world and then didn't even work for building :)
<DktrKranz> (it probably needed the other half)
<Laney> no, part of the world it installed made it die
<Laney> (exim)
<francisco> hi
<francisco> how can I register in a channel?
<francisco> in an irc-channel
<persia> francisco: /query nickserv
<francisco> persia: thanks a lot!
<kamalmostafa> james_w: I'm trying to work on yet another package ('gcin') with a stale bzr tree.  I see it in the list of "905 outstanding jobs" at http://package-import.ubuntu.com/status/ --  Does this mean that I should ask you to manually provoke it to import, or that I should wait patiently?
<paissad> hi all, i've packaged a software, i did 1st for debian, but i would like the package to be available in ubuntu repositories ... what do you suggest me to do ? ...
<sebner> paissad: is it already in Debian?
<paissad> i've alreaady uploaded the package in mentors-debian repositories & i'm waiting for a sponsor to upload it definitely
<james_w> kamalmostafa: running
<paissad> sebner, no for the moment, .... it's just in mentors-debian repositories waiting for a sponsor to upload it !
<paissad> sebner, but i do have it in my personal repository
<paissad> wait 1 min please
<sebner> paissad: well, if you are not sure to get it uploaded to Debian the next day you should upload it to REVU as Final Freeze is in 8 days
<Laney> final freeze?!?!?!?!
<persia> No reason we can't review a package on mentors.
<paissad> sebner, REVU, let me google that !
<paissad> i did not know
<persia> Feature Freeze.
<sebner> argh
<Laney> heh
<sebner> sorry
<sebner> wrong word!
<kamalmostafa> james_w: Thanks -- I see it running on the status page, and will watch for its completion.
<sebner> !revu | paissad
<Laney> I'm not sure how likely it is that we will get to review a package on REVU now for Lucid anyway
<ubottu> paissad: 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
<persia> sebner: Just go review the package on mentors.  If it looks good, get a peer review, and get it uploaded.
<persia> REVU is a good tool, but REVU isn't the only way to do two-developers-looked-at-this
<sebner> persia: we need to pull a DD out of under a rock too though :P
<francisco> alquien me puede ayudar?
<francisco> como me puedo registrar en debian-es
<francisco> ?
<francisco> necesito un registrarme para poder chatear
<persia> !es
<ubottu> En la mayorÃ­a de canales de Ubuntu se habla sÃ³lo en inglÃ©s. Si busca ayuda en espaÃ±ol o charlar entra en el canal #ubuntu-es. Escribe "/join #ubuntu-es" (sin comillas) y dale a enter.
<francisco> ok
<francisco> ubottu: thanks
<ubottu> You're welcome! But keep in mind I'm just a bot ;-)
<francisco> ok
 * sebner hugs ubottu :D
<paissad> for people speaking french, they can read here http://doc.ubuntu-fr.org/pms-linux ... others might be able to understand too .. ^^
<ajmitch> sebner: you should join the NM queue
<sebner> heh
<sebner> ajmitch: to be honest I intend to become DM the next month (ehm, at least applying)
<ajmitch> & then DD?
<sebner> ajmitch: maye in 1-2 years ;)
<ajmitch> how disappointing :)
<kamalmostafa> james_w: alas, the gcin import has failed http://package-import.ubuntu.com/status/gcin.html#2010-02-10%2022:36:53.695156
<james_w> ah
<james_w> is it bz2?
<sebner> ajmitch: lack of time, skill, ...
<ajmitch> sebner: lack of time, I can accept...
<kamalmostafa> james_w: yup, sure is.
<DktrKranz> sebner: too humble
 * sebner hides
<james_w> kamalmostafa: I'm writing the tests for that tomorrow
<james_w> if you can wait a day it should be there
<kamalmostafa> james_w: no problem -- I'll just apt-get source in the meantime.  thanks!
 * ajmitch should upgrade his sid VM more often
<sebner> ajmitch: lack of time? ;-P
<ajmitch> sebner: it's just been a couple of weeks since I last did a dist-upgrade
<ajmitch> I need to remember to do it
<sebner> ajmitch: when I'm actively doing some -dev stuff I upgrade my pbuilders every day. And my lucid machine too ^^
<ajmitch> I've ketp my lucid install mostly up to date
#ubuntu-motu 2010-02-11
<doctormo> I'm having a problem with lucid builds on python projects
<persia> What sort of problem?
<doctormo> persia: The setup.py uses install_lib to do some work, which isn't done on lucid builds.
<doctormo> This is the standard python distutils install_lib
<persia> doctormo: Hm.  It works for karmic builds?
<doctormo> persia: yes, and jaunty
<persia> doctormo: Do you happen to have a sid chroot available you could use to see if it's a local issue?
<doctormo> persia: this happens via the ppa build system
<doctormo> I don't have lucid working yet.
<persia> Ah, I thought you might have been trying builds against lucid with pbuilder or sbuild.
<persia> But it sounds like there's some difference.  I'd think it would be worth determining if the difference is inherited from Debian, or local to Ubuntu.
<persia> If the former, then they python team may have good suggestions to work around the issue.
<persia> If the latter, there's probably a bad merge that deserves attention.
<doctormo> hmmm, I don't know if I'd know how to test that
<freeflying> persia: got some mins?
<persia> What's up?
<freeflying> persia: if you have time, plz have a look at revu.ubuntuwire.com/p/ailurus
<persia> freeflying: You've done a licensing check on all the files?
 * persia doesn't have time for that right now
<freeflying> persia: did i miss anything?
<persia> freeflying: I asked if you've done a full licensing check on all the files.  I don't have time for that right now.
<freeflying> persia: I did
<persia> OK.  I'll want you to be the second advocate anyway, just because I don't want to answer to an archive-admin having not checked that.
<persia> (but I may reject it anyway)
<persia> freeflying: rejected with comments
<persia> happyaron ^^
<freeflying> persia: thanks
<persia> freeflying: Any particular reason you picked on me?  I'm slow and lousy with python :)
<freeflying> persia: just saw you became active :)
<freeflying> persia: I found we don't have too much developer in tz close to you and me :)
<persia> Bunch in .au
<persia> some in .nz even (albeit fewer)
<persia> But very few in +8
<YokoZar> persia: Well I'm technically in -8 but I stay up way way too late
<persia> YokoZar: well then, you must be in a mood to review http://revu.ubuntuwire.com/p/libprolooks1 :)
<YokoZar> right now I'm trying to figure out why lucid is freezing at login regardless of kernel version
<persia> (and as a prize, you get to assign the next unsuspecting volunteer a package of your choice, in the vague hope of reviewing some stuff prior to FF)
<persia> YokoZar: Uninstall plymouth
<YokoZar> We're months behind on review at this point aren't we
<persia> (or don't press enter).
<persia> We're only about 10 months behind, which is better than it was.
<suji11> Anyone advocate/review my package IOK  http://revu.ubuntuwire.com/p/iok
<spenser> Hi, I'm working on fixing bug #520240.  This is my first ever attempt at a patch for Ubuntu/Debian.  I updated the rules and added the file that I needed to add,  however when I run debuild -us -uc to build the package I get the following lintian error. Now running lintian...
<spenser>  E: libapache2-mod-authz-unixgroup: duplicate-conffile /etc/apache2/mods-available/authz_unixgroup.load
<spenser>  Finished running lintian. How can I fix this?
<ubottu> Launchpad bug 520240 in libapache2-mod-authz-unixgroup "Does not install create /etc/apache2/mods-avaiable/authz_unixgroup.load file" [Undecided,New] https://launchpad.net/bugs/520240
<spenser> is anyone here?
<crimsun> yes, but I'm updating my schroots. Sec.
<spenser> ohh thank you
<crimsun> spenser: hmm, what's wrong with the existing debian/authz_unixgroup.load ?
<crimsun> spenser: and debian/libapache2-mod-authz-unixgroup.install ?
<spenser> its not included in the deb
<spenser> so i updated the .install and .dir files to install it.
<crimsun> ok, have you regenerated your fixed source package?
<spenser> The source package does not need to be regenerated the file is located in the debian/ directory and is created by the patch.
<spenser> is that appropriate?
<crimsun> is the patch to which you refer the one here? http://launchpadlibrarian.net/39042352/authz_unixgroup.load
<spenser> no, when I downloaded the source for the package I found the file in the debian/ directory.  However, the file is not included in the build by default.
<crimsun> right, the one you posted is identical to the one in debian/
<crimsun> have you posted your patch (to the bug report)?
<spenser> not yet, as I'm not completely sure how to create a patch from the work.  Is there a nice script I can run or do I need to it manually?
<crimsun> do it manually
<crimsun> alternately, you may post your modified .dirs and .install to the bug report, and I'll walk you through it
<spenser> that will be easier.
<crimsun> BTW, I deleted the authz_unixgroup.load that you attached so that there will be less clutter
<spenser> thank you
<spenser> alright they are both up there
<crimsun> spenser: are you /certain/ that you posted your modified files?
<crimsun> spenser: the .dir is identical to the one shipped in the Debian/Ubuntu source package, and the .install only has a whitespace difference
<spenser> yes, its a very very simple patch
<spenser> maybe its a difference between 10.04 and 9.10
<crimsun> yes, it is
<crimsun> the one in 10.04 works correctly
<spenser> o
<spenser> ok
<spenser> well I guess there is no need for a patch then
<spenser> I'll go ahead and close the bug
<crimsun> that's ok; thanks for checking :-)
<crimsun> note that the changelog entry for 1.0.2-1 (in 10.04) has this:
<crimsun>   * Apache .load file now gets installed
<crimsun> OTOH, if you use this package in 9.10, I can walk you through generating a debdiff that you can use for a StableReleaseUpdate (SRU)
<spenser> Do you believe it would be accepted?
<spenser> If so I'm all game
<crimsun> it's pretty trivial, so you have a pretty high probability
<spenser> ok sounds great
<crimsun> first, do you have the ubuntu-dev-tools binary package installed? If not, take a moment to install it, please.
<spenser> It's now installed.
<crimsun> ok. Create a new directory and change into it.
<crimsun> then, use: pull-lp-source libapache2-mod-authz-unixgroup karmic
<crimsun> that command downloads the precise source package from Launchpad associated with Karmic
<spenser> E: No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer.
<crimsun> ah, I suppose you would want to use manage-credentials first as the message says.
<crimsun> alternately, extract your existing source package anew
<crimsun> do you have it in the parent directory (../) ?
<spenser> yes, I did a apt-get source on the package
<crimsun> if so, that's dpkg-source -x ../libapache2-mod-authz-unixgroup_1.0.1+svn67-1.dsc
<crimsun> then, change into the extracted source directory
<spenser> alright, I'm there
<crimsun> you'll want to make changes as you did to debian/libapache2-mod-authz-unixgroup.{dirs,install}
<spenser> done
<crimsun> now you'll need to create a changelog entry, then do the Launchpad administrivia.
<spenser> any fancy script to create the changelog entry?
<crimsun> so, you can use dch -i -Dkarmic-proposed
<crimsun> debchange, or dch, eases manipulating debian/changelog
<crimsun> -i -> increment
<crimsun> -D -> distribution
<crimsun> a proposed SRU will have a distribution of $release-proposed
<crimsun> in this case, it's karmic-proposed
<crimsun> now, let's look at the top line:
<crimsun> libapache2-mod-authz-unixgroup (1.0.1+svn67-1ubuntu1) karmic-proposed; urgency=low
<spenser> yes
<crimsun> the version in parentheses can be left alone since lucid's version is already higher/greater, but just to be pedantic we'll change it so that it's more attuned to standard versioning for SRUs
<crimsun> so 1.0.1+svn67-1ubuntu1 -> 1.0.1+svn67-1ubuntu0.1
<spenser> done
<crimsun> (note that you could also have used -v to specify this when you used dch)
<spenser> cool
<crimsun> now, create a succinct message about the changes you've made
<spenser>   * added authz_unixgroup.load to apache mods-available dir (Closes: #540240)
<spenser> will that work?
<crimsun> yes and no
<crimsun> it does describe the effect of what you did, but for SRUs try to be very precise
<crimsun> also, the changelog-closing syntax is different for Launchpad (it's LP: #foo)
<crimsun> Try something like:
<crimsun>   * debian/libapache2-mod-authz-unixgroup.{dirs,install}:
<crimsun>     - Install authz_unixgroup.load properly (LP: #520240)
<lfaraone> persia: new upstream version and should fix all your concerns (groundcontrol) http://revu.ubuntuwire.com/details.py?upid=7663
<spenser> I saved the changelog
<crimsun> spenser: ok, now you can regenerate the source package
<crimsun> spenser: after you regenerate the source package, you can create a debdiff
<crimsun> so: debuild -S -uc -us
<crimsun> oh, sorry
<spenser> alright thats done
<crimsun> you probably want to do one more change to debian/control, too:
<spenser> bump the version to 3.8.2?
<crimsun> since you've modified the source package beyond what Debian's has, you want to be courteous and make the contact reference precise
<crimsun> so to do that, you'd:
<crimsun> 1) change Maintainer: Hai Zaar <haizaar@haizaar.com> to XSBC-Original-Maintainer: Hai Zaar <haizaar@haizaar.com>
<crimsun> 2) add Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<spenser> done
<crimsun> note that because this is expected practice, you don't need to document this change in debian/changelog
<crimsun> now you can regenerate the source package
<spenser> I did but I received this error.
<spenser> W: libapache2-mod-authz-unixgroup source: out-of-date-standards-version 3.8.1 (current is 3.8.3)
<crimsun> which error?
<crimsun> spenser: oh, don't arbitrarily bump the S-V
<lfaraone> spenser: you can safely ignore that for SRUs.
<crimsun> there are requirements for doing so, and as lfaraone mentioned, don't do that for an SRU, which is supposed to be the minimal fix necessary
<spenser> I didn't I realized about a split second afterwards what it meant
<spenser> Alright the build completed
<crimsun> so now you should have two source packages in ../
<crimsun> so, back up to the parent dir
<crimsun> from there you'll use the debdiff tool to generate a debdiff
<crimsun> (which is essentially a unified diff)
<crimsun> so, this would be, e.g., debdiff libapache2-mod-authz-unixgroup_1.0.1+svn67-1.dsc libapache2-mod-authz-unixgroup_1.0.1+svn67-1ubuntu0.1.dsc > libapache2-mod-authz-unixgroup_1.0.1+svn67-1ubuntu0.1.debdiff
<crimsun> then, attach this debdiff (libapache2-mod-authz-unixgroup_1.0.1+svn67-1ubuntu0.1.debdiff) to the bug report
<spenser> I can't see my changes to the source in the debdiff? is that normal?
<crimsun> please pastebin your debdiff
<spenser> where is the pastebin?
<crimsun> it should resemble http://pastebin.com/f72fc7077
<spenser> http://pastebin.com/m31f4238f
<crimsun> hmm, did you modify libapache2-mod-authz-unixgroup.dirs and libapache2-mod-authz-unixgroup.install ?
<imbrandon> hrm hardy -> karmic directly isnt a good idea ? or is it supported ?
<spenser> yes
<crimsun> spenser: according to the debdiff, either you didn't save the changes, or you edited some other directory's files
<crimsun> imbrandon: it's doable but not recommended
<lfaraone> imbrandon: completely unsupported.
<lfaraone> imbrandon: if you want to skip releases, wait for lucid.
<lfaraone> imbrandon: and then only go LTS->LTS, so hardy->lucid.
<imbrandon> crimsun, kk thanks, its a "production" system so i'll go the safe ( abet longer ) route
<imbrandon> lfaraone, no time, need upgrade in next 48 hours
<imbrandon> :)
<imbrandon> btw havent been arround much to say "hi" , hows things crimsun  ?
<lfaraone> imbrandon: keep in mind this channel is for development, not support :)
<imbrandon> lfaraone, i'm aware :P
<crimsun> imbrandon: not bad, yourself?
<imbrandon> good, been really REALLY busy last few months, but good
<crimsun> spenser: the best course of action is to retrace your edits and regenerate the source package and debdiff
<imbrandon> i seen ubuntuwire.com come up for renewal and noticed i hadent been on irc in ages ;)
<spenser> Will do
<crimsun> imbrandon: cool. (I read your posts on Planet Debian.)
<imbrandon> ugh yea , actualy that wasent me
<imbrandon> it got hyjacked ( the personal domain )
<imbrandon> i removed myself ( well that blog ) from debian and ubutnu planets
<lfaraone> imbrandon: can't your provider get that sorted out?
<imbrandon> yea it can, and it is, but its sticky
<lfaraone> interesting.
<imbrandon> somehow ( long story short ) godaddy let the domain be "reregistered" ( e.g. it wasent up for renewal )
<imbrandon> so i'm in the SLOW process of reaquireing it
<lfaraone> ah, I've heard of those scams.
<imbrandon> lucky the other domains ( over 20 of them ubuntuwire.com included ) on the same account are fine, but it still has me looking at better options in the future
<imbrandon> anyhow back to my upgrade prep, talk to yall soon, i'll try not to be such a stranger
<spenser> ahh much better I think I figured out what I did wrong.  I had rebuilt the package before with the same version number thereby causing the orig files to be overwritten.  By redoing the steps, and incrementing the version number before running the debuild i avoided that issue.
<spenser> so here is the new debdiff http://pastebin.com/m680c8d18
<lfaraone> james_w: would you consider it a bug that bzr bd, when run in <root-of-bzr-repo>/debian creates a folder buildarea in <root-of-bzr-repo> rather than <root-of-bzr-repo>..?
<lfaraone> */..?
<lifeless> lfaraone: already filed
<spenser> Alright, I posted the patch to launchpad
<lifeless> lfaraone: me too it ;)
<spenser> crimsun: I uploaded the debdiff to launchpad under the bug i created
<crimsun> spenser: yep, now you should amend the Bug Description so that it follows https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<lfaraone> lifeless: got a number on that?
<lfaraone> lifeless: howabout the "packages with debian files in bzr root and with a debian/ folder symlinked to . cause odd errors"? :P
<lfaraone> lifeless: found the first one, nvm.
<spenser> crimsun:  How do I upload the package?
<spenser> crimsun: step 4
<crimsun> spenser: I'll handle that part
<spenser> sounds good
<spenser> I think everything is in order
<crimsun> spenser: uploaded; thank you for your contribution!
<spenser> thank you for helping me out.  Couldn't of done it without you.
<crimsun> yw
<spenser> Does this mean my shiny new package is in proposed?
<crimsun> not yet; it has to be accepted by an SRU team member, which may happen by Monday
<crimsun> err, in the next couple days
<spenser> cool, I'll be watching
<fabrice_sp> A package requires locale en_US.UTF-8 to build. Debian added a dependency on locales-all, but we don't have it in Ubuntu (thus the package FTBFS). I added a locale-gen en_US.UTF8 call in debian/rules, but it has to be done as root. Any idea on what else can be done to havethis locale installed?
<lifeless> the language pack needs to be installed... smells like a broken package to me
<fabrice_sp> it's a brand new one (console-braille). Actually, the package requires an UTF-8 env to build. And buildd have C only
<nigel_nb> jmarsden, can you give me a quick overview of fixing a package that uses quilt?
<lifeless> fabrice_sp: file a bug on soyuz asking for a UTF08 environment, and modify the package to use locale -a to find any UTF-8 environment
<lifeless> fabrice_sp: or build-dep on a utf8 langpack and do the same
<jmarsden> Sure... (was AFK...)  what specifically do you need help with?  quilt commands to apply/create/edit patches?  See /usr/share/doc/quilt/README.source for a start... does that help?
<jmarsden> nigel_nb: ^^
<nigel_nb> jmarsden, that does
<jmarsden> Good :)
<nigel_nb> jmarsden, when I'm working on a patch, the entire work needs to be done in my lucid vm?
<jmarsden> nigel_nb: It's up to you.  You can work in a Karmic environment and then test build in a karmic chroot (pbuilder) if you prefer.
<nigel_nb> jmarsden, okay, its embarassing.  I dont know how to set that up
<jmarsden> Ah.  Let me find the URL... https://wiki.ubuntu.com/PbuilderHowto
<jmarsden> Also look at the pbuilder-dist script and man page for a wrapper that can simplify setting up multiple pbuilders.
<nigel_nb> jmarsden, in a karmic environment, I can get pbuilder to build for lucid?
<nigel_nb> I just need to follow that page?
 * nigel_nb will get disconnected for 1 hour soon :(
<jmarsden> Yes, I think so.  I did more, I have a somewhat edited .pbuilderrc based on some stuff from http://wiki.debian.org/PbuilderTricks
<jmarsden> You may find you can actually just do man pbuilder-dist and use that, for simplicity.
<jmarsden> nigel_nb: Scheduled Internet outages?  Seems odd...
<nigel_nb> jmarsden, yep.  everyday 2 hours in noon and evening
<jmarsden> nigel_nb: Are you in some "interesting" part of the world, like some tiny island in the Indian Ocean, or something? :)
<nigel_nb> jmarsden, well, Indian ocean is named after us ;)
<nigel_nb> India, hehe
<jmarsden> Ah, OK.  But when I was in Hyderabad a few years back they didn't have scheduled outages...
<nigel_nb> bangalore
<fabrice_sp> lifeless, will ahve a look at an utf8 langpack. Thanks!
<nigel_nb> pbuilderrc should contain my email and what else?
<jmarsden> nigel_nb: Mine is a 95 line script!  I'm not sure what the minimum is :)   BTW, I may well be asleep by the time your 1 hour disconnect ends.
<nigel_nb> I'm hoping at least someone will be around to help
<jmarsden> There's usually someone here, yes.
<micahg> nigel_nb: people in europe will be in in a couple hours
<nigel_nb> micahg, thats my hope :)
<slytherin> Can anyone think of any sensible reasons why rules file would check for architecture to decide whether to apply patches or not?
<dholbach> good morning
<slytherin> dholbach: good morning
<dholbach> hey slytherin
<suji11> randomaction: review/advocate my package. i fixed the things http://revu.ubuntuwire.com/p/iok
<suji11> how to create package for dictionary files, i'm having ta_IN.dic ta_IN.aff . i have to create package for hunspell-ta how to do that?
<slytherin> persia: Can you please explain the version bump for swt-gtk. I am not able to figure out completely from changelog.
<thekorn> hey motus, are you using bzr and launchpads merge proposal feature in your sponsorship process to get fixes into ubuntu?
<thekorn> if so, is the workflow described somewhere?
<dholbach> thekorn: https://wiki.ubuntu.com/DistributedDevelopment/Documentation
<dholbach> thekorn: but it's not as widely adopted... yet
<dholbach> james_w: ^ right?
<thekorn> dholbach, ok, thank. but you did not integrate this into your motu sponsoring process (like crearting a merge proposal, subscribing universe-sponsors etc.) ?
<dholbach> thekorn: you mean the sponsoring overview page?
<dholbach> working on it
<thekorn> dholbach, no, I mean: I created bug 520337, which has a branch, a merge proposal, what's next?
<ubottu> Launchpad bug 520337 in python-virtualenv "virtualenv crashed with " /usr/lib/python2.6/dist-packag...6.egg failed with error code 1 in call_subprocess()" [Undecided,Triaged] https://launchpad.net/bugs/520337
<thekorn> do I still have to create debdiff etc.
<thekorn> or this is enough to get this landed at some point?
<dholbach> thekorn: that should be enough
<thekorn> dholbach, great, thanks
<ara> dholbach, is there any dev tool to get the source of a debian package from unstable easily?
<Rhonda> ara: I think debget should be in that direction.
<slytherin> ttx: ping. I have some questions about tomcat6 in repository
<ara> Rhonda, thanks!
<ttx> slytherin: pong
<slytherin> ara: pull-debian-source
<Rhonda> ara: Or extract the .dsc URL from http://packages.debian.org/unstable/$PACKAGE and "dget" from there.
 * siretart prefers 'schroot -c unstable -- apt-get source $package'
<ara> :)
<slytherin> ttx: What is the correct way to deploy a WAR file?
<ara> thanks all
<dholbach> ara: chdist should work too :)
<ttx> slytherin: drag-and-dropping it in the webapps directory should be sufficient. If you need special conf, adding a /etc/tomcat6/Catalina/localhost/*.xml deployment descriptor file is the way to go
<ttx> (iirc the directory location)
<ttx> slytherin: packages usually go the xml descriptor way, on order to install in a separate directory
<ttx> ...in order to...
<ttx> See tomcat6-{examples,admin} for an example of that
<slytherin> ttx: and which directory is the webapps directory? Copying war file to /usr/share/tomcat6/webapps doesn't work.
<ttx> slytherin: /var/lib/tomcat6/webapps should be the one$
<ttx> (CATALINA_HOME)
<ttx> (or is it BASE?)
<slytherin> right. I was not looking in this location.
 * ttx is confused, long time since I last used it :)
<slytherin> directory /var/lib/tomcat6/webapps works
<slytherin> first time using tomcat from repository. :-)
<Rhonda> oh
<Rhonda> oh
<ttx> slytherin: we (as in Debian + upstream tomcat + me) are working on a more intuitive tomcat6 package for lucid/squeeze
<slytherin> Also IIRC, tomcat provides a ant task for deployment, right?
<ttx> slytherin: hmmm... dont know.
<Rhonda> ara: dget $package=version  :D   though, I would hope a switch like -s unstable or similar could get added.
<^arky^> hi, can anyone help with this error  bzr: ERROR: Cannot lock LockDir
<dholbach> ara: first time: chdist create unstable; edit ~/.chdist/unstable/etc/apt/sources.list  - then: chdist apt-get unstable update; chdist apt-get unstable <pkg>
<Laney> pull-debian-source foo unstable
<Rhonda> ara: Just figured out. Put a deb-src for debian unstable into your sources.list and simple "dget $package" :)
<ara> wow, I might remember only one of those
 * Rhonda . o O ( It was more curiosity on my part actually that did let me dig that up â¦ )
<ara> (if any)
<ara> I am merging some changes from debian to lucid. I have seen that they added a debian/source/format file to indicate format 3.0
<ara> (as explained at  http://wiki.debian.org/Projects/DebSrc3.0)
<ara> should I be merging that as well? is it harmful in Ubuntu?
<randomaction> ara: you should, Ubuntu fully supports source format 3.0 now
<Laney> I think you have it backwards
<Laney> you should be thinking "do I want to keep this *Ubuntu* change?"
<Rhonda> randomaction: â¦ for certain definitions of "fully supports". The format is still a bit flakey â¦
<ara> Laney, I don't, that's why I was asking if I should for some other reason
<randomaction> Rhonda: sure, it's at least limited to lucid
<slytherin> ttx: /usr/share/java/catalina-ant.jar includes various ant tasks to deal with webapps deployment.
<Rhonda> ara: You know, in my fromer workplace I had a working collegue who had the initals ara. Confuses me a bit at the moment. :)
<ara> Rhonda, I am not him/her
<ara> Rhonda, :)
<slytherin> ttx: one more question if you are not too busy.
<ttx> slytherin: shoot
<slytherin> ttx: Is JSTL library part of tomcat installation? I am not able to figure out which jar contains it (if at all).
<ttx> hmm
<ttx> maybe /usr/share/tomcat6-examples/examples/WEB-INF/lib/jstl.jar
<ttx> in tomcat6-examples
<slytherin> looks like. I wonder why this is not part of core installation or at least packaged seperately.
<ttx> slytherin: I suppose nobody asked for it :) (hint, hint)
<ara> standars-version in debian is 3.8.4, but lintian in lucid says it should be 3.8.3
<ara> which should I put?
<directhex> ara, don't change standards version for merges
<ara> directhex, thanks!
<ara> directhex, I'll keep that in mind :)
<slytherin> ttx: Actually the jar file is /usr/share/tomcat6-examples/examples/WEB-INF/lib/standard.jar. Upstream homepage is - http://tomcat.apache.org/taglibs/standard/
<directhex> ara, you want the minimum of changes you can get away with - ideally no changes leading to an effortless sync rather than a timewastey merge
<slytherin> I will drop a question on Debian java list and try to get this done in Squeeze/Lucid
<slytherin> ara: unless the debian package has changed the version.
<directhex> ara, every merge, your question should be "can i drop this ubuntu change" - rarely is "shall i add an ubuntu change" a good idea
<ara> directhex, meaning, I should keep 3.8.4 (debian's) or 3.8.3 (lucid's)
<directhex> ara, meaning changing standards version is a pointless change which increases workload for literally zero benefit
<Laney> you see, that's the same thing I told you about earlier
<Laney> copy the Ubuntu changes over to the Debian package
<Laney> you don't need to think about reverting their stuff
<randomaction> I'm looking to merge ming from Debian, which would start libming0->libming1 transition. I have verified that only one rev-build-dep breaks, and I have a fix for it. Anything else I should check before upload?
<Laney> how many packages are affected?
<randomaction> five
<Laney> easy then, go for it
<directhex> five's nothing imho
<directhex> i break more by uploading monodevelop 2.2.1
<sebner> directhex: do you know when the rest will be compatible?
<randomaction> Laney, directhex: ok, thanks :)
<directhex> sebner, i haven't uploaded it yet, it's on my TODO
<directhex> sebner, i'll try & get all addins done on the same day.
<sebner> directhex: aye
<slytherin> ttx: Actually both jstl.jar and standard.jar are needed. :-D
<slytherin> wow, writing webapp from scratch is fun.
<directhex> slytherin, i hear the cool kids use "rails" for that
<slytherin> directhex: I admin it. I am not cool. I love java. :-P
<directhex> slytherin, that's not just uncool, it's *weird* ;)
 * slytherin goes for a tea break
<paissad> hi all, i 've uploaded a package to revu.ubuntuwire.com, it's pms-linux ... i hope that someone will give help in order to make the package available into ubntu repositories
<paissad> i need to go now, i will be back soon, you can pm me
<nigel_nb> just a doubt, when I'm trying to get schroot working, debootstrap needs to built from the source for lucid?
<persia> slytherin: The version of swt-gtk in Debian is lower than the last version of eclipse in Ubuntu that built the binary packages that have been transferred.
<happyaron> persia: hi, I've made changes on ailurus, could you continue to review it? http://revu.ubuntuwire.com/details.py?upid=7665
<sebner> persia: any chance you give it another try?
<slytherin> persia: hmm but AFAIK swt packages generated by eclipse have different names.
<sebner> persia: + alien arena
<persia> sebner: MInd doing happyaron's review whilst I dig into it?
<persia> slytherin: eclipse 3.5.1+repack~3-0ubuntu1 provided some binaries also provided by swt-gtk 3.5.1-2, and no longer provided by eclipse 3.5.1+repack~3-0ubuntu2
<sebner> persia: trade of work, hmm? Argh, I'll give it a try but in any case I won't ack as I'm not that used python (yet) and especially because of cdbs
<persia> sebner: You're at least as comfortable with python as I :)  And if you don't like CDBS, maybe happyaron will change.
<persia> (but I don't remember there being anything special about the CDBS stuff)
<sebner> persia: I've never and I'll never use it. That's the special thing about cdbs :P But I think it's not the right way to change it because the reviewer wants it because cdbs is (evil) valid
<persia> sebner: I agree that it oughtn't change just because you don't like it :)  But really, if there's no hackery, just make sure it works.
<persia> If there's hackery, it needs some more attention
<sebner> heh
<sebner> persia: I'll give it my best ;)
<persia> Excellent
<slytherin> persia: got it. In any case eclipse will soon stop generating swt-gtk binaries
<persia> slytherin: It already has stopped, but because of the version numbers, the old binaries from eclipse were still floating around in the archive and on user systems, and needed *newer* versions from swt-gtk to be viewed as "upgrades", which is why I did the silly +versionbump
<slytherin> persia: not a big issue.
<persia> slytherin: What?  It would have meant that the binaries we were distributing weren't build from source, which would be bad.  It also would have meant swt-gtk would have been in a failed-to-upload state, so it would never have been delivered with lucid.  Which part of that isn't a big deal?
<slytherin> persia: you got me wrong. I am saying that version bump you did is not a big issue. This was in response to "I did the silly +versionbump"
<persia> Oh, yeah :)
<persia> It's just a little version hack to work around some historical messiness.  We can sync the next upstream.
<persia> As an extra bonus, the same folk are now watching eclipse in both Debian and Ubuntu, so this oughtn't happen again.
<slytherin> right
<nigel_nb> persia, will you able to provide some guidance in setting up schroot so that I can build a package?
<persia> nigel_nb: Are you running lucid?
<nigel_nb> persia, no karmic :(
<persia> Do you use LVM?
<nigel_nb> virtual box
<persia> Are you handy with partitioning?
<nigel_nb> I am, but I dont think I have the space either
<persia> Then get someone else to provide some guidance in setting up pbuilder.  lucid schroot/sbuild solves the dependency on lvm, but not karmic, and I'm unsure about backporting the stack.
<nigel_nb> so I can't really do it on karmic with schroot?
<sebner> persia: I suppose you didn't give it a testbuild?! I fails here
<persia> sebner: I did do a testbuild, but that was back when it didn't even try to conform to python policy
<persia> nigel_nb: You can use karmic but then the combination is sbuild+schroot+lvm rather than just sbuild+schroot
<persia> Which means you either need to have already been using LVM, or you need to make an empty partition to use LVM (20G seems to be about the smallest that is useful)
<nigel_nb> persia, I'm just following https://wiki.ubuntu.com/DebootstrapChroot and I'm stuck
<nigel_nb> I cant get the soueces updated
<persia> nigel_nb: Hrm.  I've never seen that page.
<nigel_nb> ouch
<persia> nigel_nb: Is it that debootstrap isn't working, or the next steps?
<sebner> persia: Was it already using cdbs back then? ^^
<persia> sebner: Yes
<nigel_nb> persia, I can enter the schroot, but it won't update the sources.list with apt-get update
<persia> happyaron: Have you test-built?  Can you help sebner understand why it doesn't build?
<persia> nigel_nb: Are you calling `sudo schroot -c ${RELEASE} -uroot`
<persia> nigel_nb: You may find that installing sudo in the schoot is convenient.
<nigel_nb> persia, I'm calling  sudo chroot /var/chroot/lucid, it enters a root prompt
<nigel_nb> persia, i wanted to install ubuntu-minimal inside it
<persia> pastebin the error from apt-get update
<persia> nigel_nb: And please confirm you've already run debootstrap :)
<sebner> happyaron: persia: well, if you give me some more minutes I'll post the build log and some other glitches on revu
<happyaron> sebner: persia I will check
 * happyaron for now
<nigel_nb> persia, well, I built the whole thing again.  Works this time :)
<persia> nigel_nb: Excellent :)
<nigel_nb> persia, I wanted to correct a spelling error.  Never thought Id be running around this much ;)
<happyaron> sebner: the problem might caused by upstream setup.py
<happyaron> :(
<sebner> happyaron: wondering, persia mentioned that it built at some point in the past
<persia> sebner: like I said, that was before it tried to comply with python policy.  I think it was using autotools instead of setup.py
<happyaron> sebner: yes it built in the past...
<persia> sebner: By the way, I think I've almost tracked down the issue with alien-arena :)
<happyaron> persia: the autotools call setup.py
<sebner> persia: oh oh oh :D
<sebner> happyaron: persia I've posted some other issues. Haven't checked copyright at all yet though
 * persia could reproduce in a controlled environment, and is now trying to find the solution
<nigel_nb> persia, I can use a simple chroot running as root.  is that okay for building a package?
<persia> nigel_nb: It's actively not recommended, because it gets dirty fast.
<nigel_nb> hm :)
<persia> nigel_nb: Using schroot with lvm-snapshot, or with aufs overlays (available in lucid) throws away the messiness on each package build.
<persia> The alternative is to recreate the chroot for each and every package build.
<persia> This is why pbuilder is recommended for people who don't have LVM in karmic.
<nigel_nb> persia, I dont know how to do the lvm-snapshot
<persia> (well, pbuilder might also be recommended because people like it, but that's a different factor)
<persia> nigel_nb: You'd need to have at least one partition managed by lvm.  Really, I think pbuilder is better for you with karmic with your setup.
<nigel_nb> persia, pbuilder daunts me :(
<sebner> happyaron: I also think setup.py is b0rken as I'm not even able to use debuild (How did you get that uploaded O_o)
<nigel_nb> persia, I've decided to just keep building schroot every day
<nigel_nb> persia, now the question is um, how do I build my package in there
<persia> nigel_nb: I believe it's as easy as `pbuilder-dist lucid create`, but I'm not the best person to answer questions about it if it fails.
<persia> nigel_nb: You really don't want to do that.  Trust me.
<happyaron> sebner: my debuild -S -sa -kxxx works
<persia> nigel_nb: sbuild/schroot will handle your use case better in lucid.
<happyaron> sebner: I will contact upstream author, maybe he can release another version tomorrow
<nigel_nb> persia, okay, trying pbuilder
<happyaron> sebner: it built before, so I didn't test build, sorry for that
<sebner> happyaron: my debuild looks like this: http://pastebin.com/m10d3cc8b
<persia> happyaron: Because it built before and doesn't build now, it might be something about your packaging.
<sebner> persia: I'm wondering about setup.py *and* autohell mess
<happyaron> persia: yes, I am trying to fix it, to see wether is my fault
<sebner> persia: happyaron: I'm really no python expert but the problem is the setup.py script imho. It *must* be run as root and paths are hardcoded (e.g /usr/share/ailurus/)
<persia> That sounds like the culprit.
<RainCT> sebner: Hardcoded paths (with /usr) in a setup.py? That sounds awfully wrong
<persia> RainCT: Maybe you can help suggest what should be right?
<sebner> I guess so :)
<sebner> yeah, RainCT python expert! \o/
<RainCT> I haven't been following (just read the last few sentences), what's the problem?
<sebner> RainCT: http://revu.ubuntuwire.com/details.py?upid=7665 , see my comments at the bottom
<RainCT> Uhm.. Doesn't Ubuntu Tewaks do the same stuff its description mentions?
<sebner> heh
<sebner> who knows :)
<persia> happyaron: Could you help differentiate?  One of these two should probably go away.
<happyaron> persia: I can contact the upstream author to fix it and release a new version, he is one of my friends
<happyaron> It won't take too long I think
<RainCT> Oh, that setup.py doesn't use distutils at all, it's just a custom script (which would make more sense as a Bash script :P)
<happyaron> yup
<persia> happyaron: Right, but what's the diffference between ailurus and ubuntu-tweaks (both of which you put on REVU)?
<RainCT> happyaron: I'd be great if that setup.py could be replaced with distutils (with python-distutils-extra for i18n)
<happyaron> RainCT: yes, and ubuntu-tweak is wanting review
<RainCT> (If upstream has any questions on how to use distutils, I'm available here on IRC)
<happyaron> persia: ubuntu-tweak has more users, but it is now turning to have more functions intergrated its web service, but ailurus is providing a more pure tool, and providing tips when users doing tweak which will help newbie know more
<persia> happyaron: So both should be imstalled?  The descriptions are confusing.
<happyaron> RainCT: I will call him soon, maybe he will make the changes tomorrow, it's nearly Chinese Lunar New Year, :)
<happyaron> persia: no, either of them is okay, they have different authors
<persia> happyaron: Maybe you can get the authors to collaborate?
<happyaron> persia: I tried, but failed
<happyaron> persia: the author of ubuntu-tweak spend his time on developing web site functions, but the developer of ailurus is against that point
<persia> happyaron: OK.  Makes sense.
 * happyaron well, ubuntu-tweak is wanting review too as I said just now, :)
<nigel_nb> persia, Now I get it.  pbuilder works with chroots but in a better way (I'm in love with pbuilder now ;) )
<persia> nigel_nb: Well, kinda.  I actually prefer how schroot works with chroots (because it handles the security stuff), but either of them is better than manually managing chroots.
<persia> But schroot is fussy without LVM for karmic.
<nigel_nb> persia, all I wanted was a command line way to build packages.  pbuilder works now :)
<persia> That it does :)
<nigel_nb> persia, still around? need a little help with quilt :(
<Rhonda> nigel_nb: Maybe someone else is also able to help you, just ask. :)
<nigel_nb> Rhonda, ah, sure :)
<nigel_nb> well, I'm trying to correct a spell error bug and I'm not sure how to generate a diff
<nigel_nb> I know how to *correct* the bug but not generate the diff
<Rhonda> Does the package already use quilt? Then "quilt push" the current patches, "quilt new xx_spellfix" for creating a new quilt patch, and "quilt edit file", fix the typo and quit the editor. Then "quilt refresh" and you have the patchfile there.
<nigel_nb> Rhonda, ah, thats what I was looking for.  Thanks :)
 * persia thanks Rhonda
<Rhonda> After that you might want to "quilt pop -a" to unpatch and rm -rf .pc (quilt doesn't clean up that directory itself)
<nigel_nb> quilt edit file takes me to vim, is that normal?
<Rhonda> If vim is your editor, yes. :)
<nigel_nb> I was hoping to find and replace the error.  It occurs in like 10 files or so
<Rhonda> Just set the EDITOR environment variable accordingly if you prefer a different editor - should happen with other tools too.
<Rhonda> You can quilt edit file1 file2 file3 and use the full power of your preferred editor. ;)
<nigel_nb> so, no find replace in one argument?
<Rhonda> But you can also just "quilt add file1 file2 ..." and then call the editor on yourself, if that's what you are looking for.
<Rhonda> Ah.
<Rhonda> Then "quilt add" all the files and "sed -i" on them. ;)
<Rhonda> There are many ways but I hope you get the idea.
<nigel_nb> yep.
<nigel_nb> once quilt add is used, I can directly sed these files?
<Laney> quilt shell is good
<nigel_nb> Rhonda, ^^
<Laney> yes you can
<nigel_nb> ah, thanks :)
<\sh> ogra: are you interested in analysing a FTBFS on armel for opensc? ;)
<persia> \sh: Can you reproduce it in an emulated chroot?
<Rhonda> nigel_nb: Sorry, was distracted by work. Like Laney said, yes. That's what I meant with that. :)
<\sh> persia: I don't have any clue about armel ... I don't even know any armel devices :(
<BlackZ> I'm not able to do a tab! I have tried with nano, gedit, but nothing..
<nigel_nb> Rhonda, unfortunately, that did not work for some reason
<BlackZ> it considers the tab 8 charaters!
<BlackZ> -> debuild -S
<BlackZ> I need the tab for the rules file
<persia> \sh: Heh.  There's a way to use binfmt-misc and qemu to have emulated chroots (including pbuilder/sbuild), but ogra might be able to fix it directly :)
<slytherin> RainCT: Do you still work on mplayer package in Debian/Ubuntu?
<slytherin> oops, wait wrong person
<slytherin> siretart: That was a question for you
<nigel_nb> Rhonda, I get "Nothing in patch 01_fix3dspell"
<\sh> persia: that's what I thought :)
<BlackZ> at the start of this line: dh $@
<persia> nigel_nb: quilt refresh to update the patch.
<RainCT> slytherin: Hehe. Yeah, I don't think I've ever touched that at all :)
<nigel_nb> persia, I get that error on quilt refresh
<persia> nigel_nb: Also, please ask questions generally.  There's lots of people about, but all of us get distracted here and there by other things.
<Rhonda> nigel_nb: Before the sed the quilt add for the files you sed on, and after the sed a "quilt refresh"?
<slytherin> nigel_nb: The quilt howto on wiki is very good. Go through it once.
<nigel_nb> yep
<siretart> slytherin: it's on my todo list, I've done some work at FOSDEM on it in cooperation with upstream
<Laney> I really suggest quilt shell
<persia> nigel_nb: Are you sure your sed call is changing stuff?
<Rhonda> nigel_nb: quilt add adds the _current_ version of the file to its internal staging area, so if you did sed before you did quilt add you already have the changed version in there.
<slytherin> siretart: Just curious if you are planning to update it.
<nigel_nb> I did a grep before changing and a grep after to confirm
<siretart> slytherin: I do have plans, but I'd also appreciate help
<siretart> escp. working on bugs woudl help me most, I think
<slytherin> Can't make promises. I am already working on more things than I should.
<hakaishi> Hi, anyone up to review/advocate qt-shutdown-p? It is a simple Qt tool to shutdown (any) system. http://revu.ubuntuwire.com/p/qt-shutdown-p
<nigel_nb> well, instead of sed-ing, I'm just doing a manual replace - tired
<persia> nigel_nb: If you're doing it manually, you're likely *sure* that it changed :)  But yeah, you might want to try going through the example on the wiki, and then see how your experience differs.
<persia> !patch
<ubottu> Patches are files describing the changes in code to achieve some results.  There are a number of ways these can be produced, but https://wiki.ubuntu.com/Bugs/HowToFix and https://wiki.ubuntu.com/PackagingGuide/PatchSystems may provide some useful guidelines.
<nigel_nb> I am going through both those wiki pages and the debian pages
<nigel_nb> but it does not seem to be helping much or I'm too much fatigued.
<nigel_nb> well, I tried again with quilt add, sed -i, and quilt refresh.  Nothing much happening
<nigel_nb> I'm seriously doing something small wrong, but I have no clue what
<persia> nigel_nb: You did quilt new, and exported QUILT_PATCHES?
<nigel_nb> bingo! didn't do exported .. I am fatigued
<nigel_nb> been at this for hours
<persia> Take a break, and come back.  The entire thing will take less time (including the break), and you'll feel better.
<slytherin> nigel_nb: That is why said read the howto on wiki. :-)
<hyperair> nigel_nb: if debian packaging is the only thing you use quilt for, it might be useful to add export QUILT_PATCHES=debian/patches in ~/.quiltrc
<nigel_nb> slytherin, I should have read completely
<nigel_nb> hyperair, thank you.  I'll do that
<hyperair> =)
<hyperair> if it isn't already in the howto, it should be added imo
<nigel_nb> I'm ready to bang my head against the wall since that didn't fix it
<nigel_nb> I still get the "Nothing in patch 104_fixspell3d" after sed-ing and quilt refresh
<ogra> \sh, it would be helpful if there was an actual error message
<ogra> \sh, but as persia pointed out ... apt-get install qemu-arm-static && sudo build-arm-chroot lucid lucid-chroot :)
<persia> ogra: If one is using lucid, one can also just pass --arch=armel to pbuilder-dist or mk-sbuild{-lv,}
<ogra> indeed
<\sh> ogra: where do i find the armel arch package archive? on ports?
<ogra> yes
<\sh> ok...this evening I'm mirroring ;)
<hakaishi> Hey everyone, the deadline for uploading a package into Ubuntu is the 18th, isn't it?
<hakaishi> am I right?
<persia> Yes.
<nigel_nb> http://paste.ubuntu.com/373976/ is the logs of what I did... what am I doing wrong?
<hakaishi> ok... XD I need one more advocate for my package...
<rmunn> Speaking of which, I still need advocates for http://revu.ubuntuwire.com/p/python-nltk
<rmunn> It's been fairly extensively reviewed by now, so I'm pretty sure I've got all my newbie mistakes fixed
<hakaishi> I also have all the mistakes, errors and warnings fixed. I've even got an advocate. Just one more *please*  ';.;'
<rmunn> (And you can safely ignore the lintian error on http://revu.ubuntuwire.com/p/python-nltk -- it's a known false positive, check the comments and the lintian-overrides file)
<hakaishi> nigel_nb: have you tried checking this page? http://pkg-perl.alioth.debian.org/howto/quilt.html I hope it helps ;-)
<nigel_nb> hakaishi, I did.  Didn't help much.  I'm doing something wrong before I get to that stage
<nigel_nb> or is it the fact that quilt doesn't let you do sed ?
<persia> nigel_nb: Quilt itself doesn't care how to change the files, as long as you tell it which files are being changed with quilt add.  quilt edit combines these two operations.
<nigel_nb> can you see the pastebin above to see if I've missed something?
<persia> nigel_nb: Setting $EDITOR to something you prefer and using quilt edit is probably easiest.
<nigel_nb> for the same change to close to 10 files?
<nigel_nb> hey, there should have been an easier way invented
<nigel_nb> can i just copy the entire folder tree to another folder make changes on one and generate a diff?
<persia> nigel_nb: Nothing seems obvious to me there, no.
<hakaishi> nigel_nb: can't you just use po/*.po ?
<nigel_nb> actually, there are more files
<nigel_nb> the .po was an experiment
<nigel_nb> (which didn't work obviously)
<nigel_nb> ah, well, bug found.  My find replace statement is defective
<nigel_nb> no wonder quilt didn't work
<hakaishi> okay ^^'
<hakaishi> nigel_nb: and there I thougt of two posibilities: your find replace, or a missing step...
<nigel_nb> hakaishi, once i took a break, it just came to me to try and check that part :)
<nigel_nb> hakaishi, the string did replace, but I think also replaced in .pc
<hakaishi> nigel_nb: okay, nice
<nigel_nb> I shoulda done what persia suggested quite some time back
<hakaishi> now that this is solved, I'll be going off. cu
<paissad> hi all, i 've uploaded a package to revu.ubuntuwire.com, it's pms-linux ... i hope that someone will give help in order to make the package available into ubntu repositories
<hakaishi> paissad: a link to your package would be helpful (or one must search for it)
<paissad> hakaishi, http://revu.ubuntuwire.com/p/pms-linux
<hakaishi> paissad: In your debian/control file: The Maintainer field is invalid. Should be "Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" and then "XSBC-Original-Maintainer: Papa Issa DIAKHATE <paissad@gmail.com>"
<paissad> hakaishi, i packaged originally for debian, (mentors-debian) ... but i will change the control file to make it more ubuntu related ^^
<paissad> that's not a real problem,
<persia> hakaishi: "invalid" is a bit strong.
<persia> paissad: The `update-maintainer` script in ubuntu-dev-tools tends to do the right thing.
<hakaishi> persia: It is what the lintian said, I just copyed it ^^'
<paissad> hakaishi, lintian returns me no errors !!
<persia> paissad: Try `lintian -iIEv --pedantic *.changes`
<paissad> ok
<hakaishi> persia: okay, I'll leave this to you ;-)
<persia> paissad: Also, remember to run on both source and architecture-specific .changes files.
<hakaishi> bye bye
<persia> hakaishi: Sorry  Please proceed.  Just commenting, but this doesn't have my full attention.
<sebner> paissad: and make sure have lintian from lucid
<paissad> persia, i just have only on changes file
<paissad> sebner, i'm running karmic ^^
<sebner> paissad: that's why I told you about lintian from lucid ;)
<paissad> am i obliged to do it from lucid ?
<paissad> is it a requirement ? or an advice ?
<sebner> paissad: well, the newer lintian is the more errors you can catch
<paissad> i see
<sebner> paissad: you don't need to upgrade your whole system ;) just lintian .
<paissad> Lintian v2.2.17ubuntu1.1
<paissad> what version do you have ?
<sebner> paissad: 2.3.2ubuntu1
<paissad> ok
<jcastro> dholbach, I have an upstream (mongodb) that wants to get into this LTS.
<jcastro> it's a sqlless database
<jcastro> they just got into debian unstable, so the correct thing for them to do is file a sync request and hope for the best right?
<mathiaz> jcastro: yes
<mathiaz> jcastro: they'll have to manually file the request now that the automatic import has been turned off
<persia> jcastro: They were here a few days ago, and we helped sort some packaging issues and pushed for the mentors route.  Should be all good to go.
<jcastro> persia, !
<persia> (modulo the sync request)
<jcastro> persia, you always have good news
<jcastro> persia, do you know which guy?
<persia> jcastro: I'd have to grep logs, and am a bit distracted.  Give me a few minutes.
<jcastro> no rush, thank you
<l3on> Hi... I've build a package that meets a merge request (ikiwiki). All info here: -> http://people.ubuntu.com/~l3on/pbuilder/ikiwiki/
<l3on> what's the next step?
<l3on> report a bug ?...
<persia> jcastro: I *think* it was kreuter/richard-10gen : there was some issue with REVU that kept getting the package rejected for no reason I could understand.
<jcastro> ah ok
<hakaishi> how come that revu is unreachable? - Is something wrong with the server?
<jcastro> persia, seems every cycle I get one at the last minute asking for a miracle, heh
<jcastro> persia, however these days people seem to be going through the debian bits as well, which is nice
<persia> hakaishi: Seems so
<Laney> jcastro: You shouldn't disregard backports though if the package won't be ready in time
 * hyperair prays to jcastro for a miracle
<hakaishi> okay, I'll try later again. cu
<jcastro> Laney, actually when they first mailed I recommended a PPA
<jcastro> but they had already started the debian process so at that point might as well go for it I guess
<Laney> well it can still enter lucid-backports even if it doesn't make the release
<jcastro> of course I was hoping for them to get there before the day of debian import freeze, heh
<Laney> so if they miss it it's not a big deal is what I'm saying
<jcastro> I didn't know that
<jcastro> I will add it to https://wiki.ubuntu.com/Upstream
<Laney> !backport
<ubottu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<Laney> ^
<jcastro> Laney, is there a page specifically on that? or just the backport page in general
<jcastro> ok
<Laney> basically you take a package to n-backports from release n+k
<jcastro> right but they would still need to be in +1
<Laney> yes
<Laney> but it gives more time to get the package in shape, go through Debian properly and such
 * jcastro updates the page
<jcastro> thanks for the tip, that's useful
<Laney> np
<paissad> i have this warning during lintian run ^^ ... but it's a really important warning i think
<paissad> arch-dep-package-has-big-usr-share
<paissad> but i think that this one below is not important, ^^ it's the source from the upstream
<Laney> it means you should consider splitting out your arch-indep stuff into a separate package
<paissad> source-contains-prebuilt-windows-binary
<Laney> that is important
<paissad> Laney, okay
<oojah> Could someone review sqlite3-pcre for me please? http://revu.ubuntuwire.com/p/sqlite3-pcre
<Laney> paissad: you should at the very least ask upstream to provide clean tarballs
<Laney> and it might be a license problem
<paissad> Laney, why a licence problem ? ... the source is from the svn repository
<paissad> the license is GPL2
<persia> paissad: GPL2 requires stuff be available in the preferred form for modification, which windows executables usually aren't.
<paissad> persia, Laney the source contains somes dirs (linux, win32, osx ...) during the deb packaging i don't touch the win & osx dirs, i even do touch the linux ^^ for other reason i won't explain now ... i don't see what's the matter
<persia> paissad: Just add the offending file to debian/clean
<paissad> everything which is in the package is free & licensed under gpl2
<nigel_nb> when I fix a bug and notice that it is present on upstream too, I'm supposed to send a patch upstream?
<paissad> persia, sorry, i'm a little confused, i'm not sure what you really mean ... do you advice me to remove the files or dirs for the source that or related to the build
<paissad> ?
<paissad> that are not related*
<Laney> unrelated files are fine, files which break the license are not
<persia> It doesn't necesarily break the license, but we can't tell.
<Laney> yes, I'm not passing a judgement on this case, just stating the principle
<persia> deleting ot prior to building is one way to demonstrate that we don't care about the file, and so we can know were are distributing compliant binaries.
<persia> So, by adding prebuilt binaries to debian/clean, we can be sure that every binary we use ends up being built.
<persia> Saves repacking.
<paissad> Laney, yes indeed, files which break the licensed are not included to the build, .. that's why for example i did not include the linux/ directory ....  knowing that that dir contains another software which is not free & whose source is not available
<paissad> i just thought that would be wiser no to delete those files or dirs in order to have a proper orig.tar.gz file ...
<oojah> paissad: They aren't talking about modifying the orig.tar.gz.
<Laney> persia: Is that OK for ftpmaster/AAs?
<oojah> What persia is saying is that whatever you put in debian/clean won't be included in the final .deb.
<oojah> Correct?
<persia> paissad: That's why I recommend deleting them at build time, with debian/clean.  You get the benefits of a clean orig.tar.gz *and* the benefits of a provable indication that you didn't use the files during the build.
<Laney> I mean, distributing a binary in known license violation, even in the source package?
<persia> oojah: Right.
<persia> oojah: It won't even be available during the build.
<oojah> Right
<paissad> persia, i understand now ! ..
<persia> Laney: For binary blobs that are licensed in a free manner, usually, but, as ever, it depends on the individual concerned.
<Laney> It's interesting. I would have repacked.
<Laney> (binary built from GPL2 source)
<persia> Laney: Having a windows binary of GPL is not necesssarily itself a license violation if we expect to have code for it.  Not building from source when distributing binaries is a failure of due-dilligence.
<Laney> but that is just me being extra cautious
<persia> Yeah.
<paissad> for a 1st build, it's really hard to sync with debian/ubuntu policies ^^ ...
<paissad> but i do not blame that, of course
<Laney> we do try to give help
<paissad> yeah, it's kind , thanks
<Laney> persia: I guess if it is alongside the source then it's not a problem
<micahg> Ubuntu Mozillateam meeting in #ubuntu-meeting in 5 minutes
<spwelton> hi all, I recently added some new features and fixed all the bugs i could find in a program i have on REVU, is there any chance i could get a dev to maybe check it out for inclusion in Universe?
<gusnan> If I have a package which I upload to Revu for inclusion to Universe - what email should I put as "mainainer"? - I put myself as XSBC-Original-Maintainer, right?
<spwelton> gusnan: you need to put the ubuntu-dev email on there, hold on, let me get the proper name and e-mail
<spwelton> gusnan: Use the following name and e-mail: 	Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<gusnan> spwelton, Thank you!
<spwelton> gusnan: any time! I'm working on a REVU package currently as well
<lfaraone> If a blueprint is accepted for lucid, but the reqisit packages aren't uploaded yet, does this require a FFE after FF?
<\sh> james_w: where was your documentation about new world merging tutorial with bzr?
<james_w> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
<\sh> james_w: thx a lot :)
<lfaraone> james_w: for debian packages, do you import from SVN if that's what's specified in the package control field?
<james_w> lfaraone: no
<james_w> not yet
<\sh> james_w: is there an actual bzr-builddeb for jaunty so I can bzr merge-package ?
<james_w> not that I know of
<\sh> that's bad
<\sh> grmpf
<\sh> I can't upgrade this machine to karmic...it will break my network config
<\sh> until karmics ifupdown is fixed
<sebner> \sh: upgrade to lucid then :P
<james_w> should be quite straightforward to backport
<\sh> sebner: ah no..this will break my puppetd ;)
<\sh> better to say puppetmaster
<sebner> heh
<gusnan> hmm, I get revu warning - "unknown-field-in-dsc original-maintainer" - what does this really mean? - as my discussion above with spwelton I thought I had enough maintainers... (This is a new package to Ubuntu, not existant in Debian...)
<\sh> james_w: well, actually not, because you need a newer bzr for jaunty...ah well, I'll try to do that merge at home
<\sh> gusnan: the right fieldname is XSBC-Original-Maintainer imho...
<spwelton> gusnan: I got that error the first time i uploaded, don't remember how i got rid of it
<spwelton> Although my current dsc has 'Original-Maintainer'
<gusnan> Yeah, I have listed myself as XSBC-Original-Maintainer...
<spwelton> Is there some application to get stuff checked in REVU? Or is it kind of a first come-first serve basis?
<spwelton> just want to make sure I'm doing this right
<oojah> spwelton: My understanding is that you can ask for reviews here, but not more than two or three times a day as described on here: https://wiki.ubuntu.com/MOTU/Packages/REVU/CheckList
<spwelton> oojah: Thanks!
<persia> Well, you *can* ask more often, but some people might start ignoring you :)
<spwelton> haha :D
<oojah> I suspect there's an optimal amount of annoyance (and probably time of day - any suggestions as to when?)
<spwelton> so following that guide, would anyone mind checking out eggtimer (a simple countdown timer for cooking, etc) at http://revu.ubuntuwire.com/p/eggtimer and let me know if anything needs fixin'? I finally learned how to properly upload to REVU and there are no errors reported.
<persia> Seems there's a quickly bug: it uses the "Maintainer" address for changelog entries.
<spwelton> in debian/changelog?
<persia> debian/copyright doesn't comply with the listed Format-Specification:
<persia> spwelton: Yep.
<persia> spwelton: I don't think it's something you did: I think quickly is broken.  Please correct me if I'm wrong.
<spwelton> i manually wrote most of this, because quickly uses weird version numbering
<spwelton> built with debuild and pbuilder
<persia> Heh.  Use your own name and email for changelog.
<persia> And Fix the copyright file.
<jcfp> debian dir seems to be in the orig.tar.gz?
<spwelton> where may I find the proper copyright format?
<spwelton> jcfp: if you click into the eggtimer-0.5 DIR, its in there
<persia> spwelton: Check the URL you put in debian/copyright
<persia> spwelton: But If you want DEP5, look at http://dep.debian.net/deps/dep5
<spwelton> haha, that copyright file was made by quickly apparently
<persia> Maybe another bug.
<spwelton> are those the only two problems? I can fix them real quick and re-upload them
<oojah> I could be reading it incorrectly, but should the code changes be in a patch rather than modified in-situ?
<spwelton> oojah: in my package?
<persia> spwelton: Those are the two that are so obvious that I noticed them immediately.  Someone with a bit more of a feel for python packaging would be a better reviewer.
<jcfp> spwelton: commented
<spwelton> ok, thanks
<jcfp> don't be scared, all fixable
<spwelton> haha the one that gave me trouble is the uscan one, I must not be writing my watch file correctly, because I always get the 404
<spwelton> ok, so I'm fixing the copyright file. I paste the whole text of the GPL-3 in there right?
<persia> spwelton: Read the "How to use this license" section at the end of the GPL.
<dooooomi> persia: thanks a lot for uploading klick. i have one question regarding your comment: what is the correct value for the maintainer field, and when did that change?
<persia> maco2: Saw your patch for JACK.  Are you uploading a fix?
<persia> dooooomi: It changed a few months back.  Current correct value is something like "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>".  Preferably use update-maintainer to get the current recommended value.
<dooooomi> persia: hm... i tried running update-maintainer on my older version of the package, and it left the maintainer field unchanged
<spwelton> so, if I'm thinking correctly... I should include a link to the GPL-3 file and not a full text in the debian/copyright file
<persia> dooooomi: Hrm.  I don't know.
<persia> spwelton: But you do want to include stuff like the declaration of license and lack of warranty and stuff.  SHould be about three paragraphs.  The template is in that section of the license.
<spwelton> ok, thanks, i think i know the part you're talking about now
<spwelton> and Upstream-Source would be, for example, the tarball on launchpad?
<persia> Or the LP downloads directory, at your discretion
<spwelton> ok
<kreuter> persia: did you ever hear back about what I did wrong with my package upload into REVU the other day?
<persia> kreuter: I don't think you did anything wrong.  I think there was something wrong with the system.
<persia> jcastro was around earlier, and reported that you'd managed to get the package into Debian, so a sync request is probably better than REVU.
<persia> (because it's already been reviewed by two DDs)
<jcastro> hi kreuter
<jcastro> kreuter, I was just about to send mitch an email.
<jcastro> kreuter, sync request would be best
<jcastro> persia, hmm,, seems like 1.3 is in debian, but they want 1.2 to be in lucid.
<persia> Why?
<jcastro> I believe 1.2 is their stable series?
 * jcastro goes to check
<persia> squeeze freeze is in like 2 weeks.
<persia> It's a *bad* time to put unstable stuff in Debian.
<persia> Downgrading in Debian seems the best solution to me, for everyone.
<jcastro> kreuter, any thoughts?
<persia> Or being sure 1.3 will be stable soon enough to be in both squeeze and lucid.
<jcastro> persia, ok I mailed the dude asking when they think 1.3.x will be ready.
<jcastro> let's hope it's not like "6 months!"
<Laney> persia: is it? (squeeze freeze)
<persia> jcastro: Yeah.  lucid gets support through to 2013/2015, and I'd expect sqeeze to last until 2013 as well.
<Laney> have you a link?
<persia> Laney: I've heard "March" bandied about as a deadline.
<persia> But no, I have no link.
<Laney> I would have expected more noise
<spwelton> do i need to write a man page for my package?
<jcastro> persia, I don't see anything on their site of feeds about a release date.
<Laney> anyway...
<Laney> I would expect most people to want squeeze and lucid to have the same versions
<Laney> Debian releases are somewhat akin to Ubuntu LTS releases
<jcastro> yes
<spwelton> jcastro: yes @ me?
<jcastro> spwelton, I was talking to them, sorry
<spwelton> oh haha
<jcastro> but I can guess that your answer is probably "yes" if it makes you feel better, heh
<spwelton> haha well i was just wondering if it's required on REVU?
<spwelton> cause I've never written a manpage before.. is it just a text file in the debian folder?
<Laney> spwelton: If this is just a small program you are writing for fun, you could consider packaging for a PPA instead
 * persia thinks it's duplicate to software already available in Ubuntu
<persia> http://alarm-clock.pseudoberries.com/
<spwelton> yeah i have it in a PPA, but I'd like to learn to write for packaging in universe.. My goal is to write a larger program, and this little one has been an immense learning experience
<Laney> universe is a part of Ubuntu... I'm not sure it is an appropriate place for learning exercises
<kreuter> jcastro: so we're sort of in a bit of a bind, time-wise.
<persia> kreuter: Essentially.
<jcastro> yeah
<kreuter> jcastro: the version that got into Debian is a 1.3.x, which is not our stable version.
<kreuter> we're planning to have a stable 1.4 out mid-March, but that probably can't make it into 10.04.
<spwelton> Laney: understood, but how else would one get started packaging for Ubuntu if they haven't done it before.
<kreuter> jcastro: oh, sorry, you already said all of this above.
<jcastro> kreuter, no worries
<spwelton> I mean, I completely understand that if there's already software in there that does this, one wouldn't want to duplicate it. I didn't see that linked program when i searched apt for what i wanted to do with it
<jcastro> so to me the risk is, do we ship 1.2.x for years, or risk trying to 1.4 with the notion that if you guys get behind and we're all doomed.
<Laney> we're always happy to help people learn
<persia> I think it's the alarm-clock-applet package.
<Laney> spwelton: FWIW, I would advice newcomers to work on patches to existing package and build up to packaging an entirely new piece of software
<jcastro> kreuter, how long do you plan on supporting 1.2.x?
<Laney> universe has a bit of a historical problem with maintaining packages
<spwelton> persia: yeah i see that package now, didn't show up in my searches for 'timer' and 'countdown' etc, etc.. when i first wrote this
<persia> a bit?
<persia> spwelton: I remember discussing this when you first joined the channel :)  But like Laney said, we're always happy to help people learn if we have time.
<jcastro> persia, when is the dropdead last day one can request a sync, beta1?
<jcastro> persia, or is it FF Feb 18th?
<Laney> s/advice/advise/ of course
<thekorn> \sh, hey, thanks for sponsoring my python-virtualenv patch ;)
<persia> jcastro: I've requested them 4 hours before the final CD spin, but the number of people that need to approve it raises exponentially after FF begins.
<spwelton> So do we just not include this in universe since there's kind of already software to do this?
<persia> jcastro: In practice, if it's not in by the first beta freeze, it's not going to happen unless it's a stop-ship issue.
<jcastro> persia, ok so let's assume they do mid-march, and beta1freeze is on march 11, assuming the debian package is solid ...
<persia> jcastro: And new packages  / version changes post FF need approval from the Release Team (which usually only grants it if essential).
<kreuter> jcastro: we're willing to support 1.2 for a while...
<persia> jcastro: I'd rather see a sync sooner (pre-FF), and some attention to bugfixing as the cycle continues.
<persia> jcastro: A cosmetic version number change from 1.3->1.4 pre beta-freeze being mostly bugfixes on the 1.3 trunk will likely get approved.
<jcastro> right
<jcastro> that's what I was thinking
<jcastro> persia, so I think syncing in 1.3.x asap would be best?
<jcastro> they're so far along in their release cycle that it's probably nothing but bugfixes at this point
<jcastro> kreuter, ^^ is that an accurate assessment?
<kreuter> uh
<persia> kreuter: Also, are you comfortable with the idea of supporting 1.4.x thorough 2013?
<persia> (as compared to 1.2.x)
<jcastro> kreuter, sorry, don't mean to come off like we're grilling you. :)
<kreuter> we're not going to have 1.4.x out by the Debian or Ubuntu freezes.
<kreuter> we're willing to backport serious bugfixes and security things to 1.2.x
<kreuter> for the foreseeable future
<chx> can an exception be made?
<kreuter> hm?
<chx> 1.3 included now to keep most of the API stable and get 1.4 in before the release?
<persia> kreuter: In that case, my recommendation would be to downgrade in Debian, and sync that.
<jcastro> chx, sure, it just gets harder and harder past freeze to get an exception
<jcastro> I personally think having 1.2 in both is the way to go, and then offer 1.4 when it's stable as a backport or PPA or whatever.
<persia> chx: Exceptions are permitted if well argued,  It's easier if the release team is kept well informed of progress.  But exceptions past beta freeze have very strict criteria, which some of the 1.3.x -> 1.4.x changes may not meet (depends on what you do when)
<persia> Yeah, having 1.3 anywhere seems like a recipe for issues.
<chx> it would be most onfortunate to miss 1.4 in Lucid for years because of like what two weeks?
<jcastro> is it two weeks?
<jcastro> our freeze is march 11, so wherever "mid-march" fits into that.
<kreuter> chx: fwiw, we (10gen) are expecting to maintain our own apt'able packages for the foreseeable future.
<kreuter> (i.e., so there will be 1.4 packages around)
<persia> Release team has a meeting in about 22 hours (I think).  It may be able to be raised at the end of that to get clearer guidance, but I'd suggest developing a firm plan first.
<chx> kreuter: i understand that, of coure
<jcastro> kreuter, since you guys plan to have packages, I think sticking a known-good stable (1.2) in debian/ubuntu is the way to go.
<kreuter> persia: I've just emailed Antonin Kral, the Debian maintainer, to downgrade to a 1.2.
<chx> jcastro: my (just a user) understanding is that 1.4 is scheduled around april 1.
<jcastro> if we try to rush 1.4 in it will end in tears (from past experience)
<jcastro> not that I don't enjoy trying to squeeze stuff in at the last minute. :p
<spacemonkey> lol
<jcastro> kreuter, as soon as that's done just file a sync bug and that'll be that.
<kreuter> jcastro: okay.
<kreuter> jcastro: where do I file a sync bug?
<jcastro> one sec
<persia> Probably better to file the sync bug NOW>
<persia> And then later sync the downgrade.
<persia> Because after the 18th, it needs release team approval to add a new package, which is rarely granted.
<persia> The downgrade will also require release-team approval, but that can be justified in terms of upstream support commitments.
<kreuter> okay, so how do I file a sync bug?
<jcastro> https://wiki.ubuntu.com/SyncRequestProcess
<jcastro> aha, there it is
<spacemonkey> jcastro: thanks for helping us with this
<kreuter> jcastro: yes, thank you.
<jcastro> no worries, it's a team effort.
 * jcastro high fives persia
<jcastro> once you're in debian from now on it will be easy.
<jcastro> well, easier
<jcastro> I've tried to document these kinds of things here: https://wiki.ubuntu.com/Upstream
<jcastro> if you guys have any feedback on how I can improve that documentation for people like you, it would be appreciated!
<jcastro> kreuter, when you file the bug please subscribe me to it (top right, "subscribe someone else" and my lp id is "jorge")
<persia> jcastro: At some point, I'd like it if some of the best-practices-in-upstream-release-management stuff we've written was merged with your packges.
<jcastro> so I can make sure it doesn't fall through the cracks
<persia> (but that's an entirely separate bit of feeback on improving the documentation :) )
<persia> s/packges/pages/
<kreuter> jcastro: will do.
<jcastro> kreuter, at your leisure of course, don't let me distract you from releasing 1.4. :p
<kreuter> jcastro: no worries on that front.
<jcastro> I'm trying to make it so we don't have to put every upstream through a gauntlet.
<persia> Some of that gauntlet we can probably document in advance, so that it doesn't feel like complying with silly rules, but makes sense.
<kreuter> so, I'm sort of confused by the launchpad web interface.  how do I create a new bug?
<persia> Stuff like outlining how to deal with work-in-progress vs. supported releases, licensing, simplified builds, bundling, etc.
<persia> kreuter: https://launchpad.net/ubuntu/+filebug
<jcastro> https://launchpad.net/ubuntu/+filebug
<kreuter> no, I've already read that.
<kreuter> I'm not at an Ubuntu machine, so AFAICT, I have to use the Launchpad web interface.
<jcastro> yeah that's the web ui to file a bug
<jcastro> you're trying to file a sync request right?
<kreuter> yes
<mathiaz> isn't https://launchpad.net/ubuntu/+filebug redirected to a wiki page to file with apport for the casual user?
<kreuter> yes
 * jcastro shakes fist
<kreuter> ?
<jcastro> one sec
<persia> mathiaz: Do you know how "casual user" is defined in that context?
<mathiaz> persia: hm - I don't exactly know
<jcastro> someone not in bugcontrol or a ubuntu-dev afaik
<jcastro> is there a work around?
<persia> Get someone else to file it.
<persia> jcastro: File a bug :)
<jcastro> I'll do it!
<kreuter> jcastro: thanks!
<Laney> you can append ?noredirect to the URL
<Laney> or something like that
<mathiaz> jcastro: +filebug?no-redirect
<Laney> so close :(
<jcastro> kreuter, ^^^ there we go
<mathiaz> kreuter: try: https://launchpad.net/ubuntu/+filebug?no-redirect
<kreuter> right, okay.
<jcastro> persia, this will be a great session at UDS. "How we punch upstreams in the face, and other lies the wiki tells you."
 * kreuter does indeed feel ever-so-slightly punched in the face.
<jcastro> oh dude don't worry, you haven't even gotten to the rest of launchpad yet.
<jpds> Or the Launchpad code, haha.
<jcastro> (actually this is valuable feedback)
<jcastro> kreuter, stepping out for lunch, I'll be around, you're in good hands here.
<persia> jcastro: We don't like new software in Ubuntu, because we have enough trouble maintaining stuff in collaboration with Debian.  It's probably better to just improve the documentation.
<kreuter> so I keyed in "mongodb sync request" for a summary, and now am facing a blank textarea.
<jcastro> kreuter, the "content of a sync request" part of the wiki is what you want here
 * jcastro finds an example
<kreuter> right, I get that, but there's something about subscribing versus assigning or something, and I don't see how that applies to the form I'm looking at.
<spwelton> has anyone here ever gotten a link to launchpad to work in debian/watch?
<persia> kreuter: That comes later.  First get the bug filed, and *then* subscribe sponsors.
<kreuter> okeedokee.
<persia> spwelton: Yes.  There's an example in the packaging guide
<persia> !packaging
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<jcastro> https://bugs.edge.launchpad.net/ubuntu/+source/groovy/+bug/368082
<ubottu> Ubuntu bug 368082 in groovy "[sync request] groovy 1.6 from debian unstable" [Undecided,Fix released]
<jcastro> how's this an example
<jcastro> kreuter, though you will want to say "We are working with debian to downgrade their package to the stable 1.2, this is a placeholder" or something
<persia> No.
<jcastro> right?
<persia> You precisely don't want that, because you want the sync request reviewer to get excited about it.
<persia> That may be the long-term plan, but there's enough context it may be difficult to re-explain to some random sponsor.
<kreuter> persia: Ack.
<kreuter> okay, sync request filed.
<jcastro> bug #?
<lfaraone> Hi, can someone take a look at http://revu.ubuntuwire.com/p/groundcontrol ? All the concerns about prior uplaods have been fixed.
 * Rhonda feels intimidated by LSB init.d requirements.  %-/
<lfaraone> persia: heh, I've asked a couple of times over the past few days, no bites.
<persia> lfaraone: My problem is that I can't say it's correct with confidence, although I don't remember seeing anything obviously incorrect.
<spwelton> problem I'm having right now is that my watchfile has http://launchpad.net/eggtimer/+download/eggtimer-(.+).orig.tar.gz in it, but uscan keeps complaining about no matching href's, and i can't find anything online that's worked :(
<lfaraone> spwelton: you want a _, not a -
<lfaraone> spwelton: upsream uploads using filenames like "eggtimer_0.5.orig.tar.gz"
<spwelton> ohhhh ok yeah you're right.. how did i miss that :D
<persia> spwelton: Note that you could just release eggtimer-0.5.tgz upstream, and uscan would automatically convert the file name (with a symlink).
<kreuter> persia: is there something I ought to do to delete the stuff I uploaded to REVU on Tuesday?
<persia> kreuter: No.  I already deleted it because the import kept failing.
<kreuter> okay!
<kreuter> thanks.
<spwelton> persia: where do i upload to for that? launchpad? are you just talking about the filename?
<persia> spwelton: Filenames on launchpad as upstream.  Doesn't matter at all: just wanted to make sure you knew that the packaging stuff didn't restrict upstream formats.
<gusnan> So I got the error "sciteproj source: unknown-field-in-dsc original-maintainer" - does anybody have any clues on how to fix that?
<lfaraone> gusnan: did you put in the control file "Original-Maintainter:" or "XSBC-Original-Maintainer:"?
<gusnan> lfaraone, I've got the "XSBC-Original-Maintainer:" in the control - This is a package that isn't availible in Debian, and I am upstream myself.
<lfaraone> gusnan: 'apt-cache source lintian' and tell me the version you have installed.
<persia> This is a perfectly normal error, and can be ignored.
<persia> It comes from dpkg, not from lintian.
<lfaraone> persia: aha.
<gusnan> Oh :)
<persia> dooooomi: Have you considered working with the Debian Multimedia team to get your applications packaged?  That would reach an even wider userbase (and the freeze has a couple more weeks to go).
<gusnan> Alright - then I believe the thing for me to do is ask: Could someone please take a look at my package sciteproj, (a project manager for use with Scite) - upstream at http://sciteproj.sf.net, and revu at http://revu.ubuntuwire.com/p/sciteproj. Thanks.
<persia> gusnan: What's the "+nmu1" for?
<gusnan> Non-maintainer upload? - I believe I am not supposed to be listed as maintainer?
<persia> gusnan: Yes, but Ubuntu doesn't have maintainers, so we also don't have non-maintainer uploads.
<persia> Anyway, rejected with a heap of comments
 * persia likes easy packages to review
<carneades> hi everyone. how do you specify in a .deb that *some* java is a dependency, but it's not important which one (OpenJDK/Sun)
<gusnan> Thanks, persia
<persia> carneades: Take a look at some other packages: it's usually something like "java2-runtime | default-jre"
<carneades> thanks persia. is there any need/way to specify that the java can't be one of the headless ones?
<randomaction> carneades: default-jdk or default-jre
<persia> carneades: I think that does make that distinction, as opposed to "java2-runtime-headless | default-jre-headless", but it's been a while since I was packaging Java stuff, so you might want to check against other packages.
<oojah> persia: If you want an easy one, the one I've been pimping should be. It's already gone through a few rounds of comments by Laney. http://revu.ubuntuwire.com/p/sqlite3-pcre
<persia> #ubuntu-java may also be helpful, but it tends to be very time-of-day dependent.
<oojah> I'd be particularly interested to know if the watch file is correct.
<dooooomi> persia: actually, yes, i was planning to ask them about including the packages in debian. but i'd also like the packages to be in lucid, and the whole process of going through debian seems to take too long for that
<persia> oojah: Having been mostly fixed makes it less easy, because I can't come up with > 10 comments just eyeballing the diff :)
<persia> dooooomi: I guess.  Some people find the process of getting into Debian faster than getting into Ubuntu.
<carneades> okay thank persia and randomaction
<persia> dooooomi: May as well submit stuff there: if it gets in, you can sync, if not, maybe you can get through REVU in time.
<oojah> persia: :)
<dooooomi> persia: i'll write to the debian-multimedia list about it. debian actually has a RFP for gtklick
<dooooomi> persia: meanwhile, it would still be great to have it reviewed and uploaded to ubuntu before lucid is frozen :)
<lfaraone> dooooomi: main speedup with debian is you only need 1 person to sign off :)
<lfaraone> dooooomi: but then you'll either need to wait for it to enter testing + sync automagically, or file a sync request and get a MOTU ACK.
<sebner> lfaraone: autosync is off already. Today was/is the last day
<dooooomi> lfaraone: seems like the right thing to do, at least for future versions of the package
<lfaraone> dooooomi: yep, that's what I've done for all my NEW packages so far.
<dooooomi> lfaraone: i guess i'd also have to install a debian system somewhere to test the packages?
<maco2> persia: me?? i havent written a JACK patch...
<LimCore>  fakeroot debian/rules clean
<LimCore> /usr/bin/fakeroot: debian/rules: /usr/bin/make: bad interpreter: Permission denied
<LimCore> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 126
<LimCore> anyidea what is that?
<paissad> i don't see debian/clean in debian policy, is it a makefile ?
<jpds> paissad: debian/rules has a clean: target.
<geser> LimCore: what permissions does debian/rules have?
<paissad> jpds, yeah, i do know that, but actually a few hours ago, Laney & persia told me about debian/clean for removing some files & dirs of the source stream before beginning the build (it's about some dirs which are absolutely not concerned to the packaging and cause some lintian warnings !!)
<LimCore> geser:   -rwxr-xr-x 1 makedeb makedeb
<LimCore> geser: Im tyring to simply rebuild package subversion
<LimCore> I simply  apt-get source
<LimCore> then     debuild -us -uc
<LimCore> and then this error, what is going on
<gusnan> I got comments mentioning "validate-desktop-file" on my revu - In what package do I find that?
<geser> LimCore: that looks ok, is /usr/bin/make also executable?
<LimCore> -rwxr-xr-x 1 root root 165888 2009-06-23 12:28 /usr/bin/make
<geser> hmm, that looks also ok
<geser> gusnan: desktop-file-utils and the binary is called desktop-file-validate
<geser> LimCore: calling make (without any parameters) works?
<gusnan> oh, thanks! That explains why I didn't find it.. :)
<paissad> i added some dirs in debian/clean ... but during the run of dh_clean, i have the error that says dir1 is a directory , dir2 is a directory, ... then i guess dh_clean does not use rm -rf , but just rm
<paissad> how should i proceed then ? ... i don't see further information from the manpage
<LimCore> makedeb@jumpi:~/subversion2/subversion-1.6.5dfsg$ make
<LimCore> make: *** No targets specified and no makefile found.  Stop.
<paissad> LimCore, you get it from apt-get source ?
<LimCore> yes
<paissad> LimCore, what about "fakeroot debian/rules binary" ?
<LimCore> http://pastebin.com/m6eb275bd
<LimCore> it gives /usr/bin/fakeroot: debian/rules: /usr/bin/make: bad interpreter: Permission denied
<LimCore> btw, my /home is noexec
<geser> :) that explains it
 * LimCore facepalms
<LimCore> why would compling need to execute binary files... :headdesk:
<LimCore> we should add a pre-check to produce a meaningfull error message for this condition
<geser> how many person mount their /home noexec?
<LimCore> geser: it depends on number of ubuntu users, and number of users that are not informed about some security aspects
<LimCore> I think this numbers are quite close togeather
<bdrung> do someone here has time to review openshot (bug #441678) and give a second ACK for it?
<ubottu> Launchpad bug 441678 in ubuntu "[needs-packaging] OpenShot Video Editor" [Wishlist,Confirmed] https://launchpad.net/bugs/441678
<bdrung> fabrice_sp: ^ you maybe?
<quadrispro> ehya RoAkSoAx
<RoAkSoAx> heya quadrispro
<RoAkSoAx> how's it going?
<quadrispro> great here, hope the same for you!
<RoAkSoAx> quadrispro, yeah kind off... :)
<persia> paissad: debian/clean is used by dh_clean
<paissad> persia, yeah, i saw it in the manpage, but it does not remove not empty dirs !
<persia> That's OK.  The only things you need to remove are the precompiled binaries.  Just leave the rest of the unused stuff in the directory tree unused.
<paissad> :/
<fabrice_sp> bdrung, will have a look tomorrow (late here)
<bdrung> fabrice_sp: thanks
<fabrice_sp> if no news within 24 hours, ping me ;-)
<fabrice_sp> bye
<bdrung> bye
<paissad> les gars, je ne comprends pas la raison pour laquelle je reÃ§ois toujours le mÃªme warning lintian sachant qiue j'ai supprimÃ© les fichiers concernÃ©s
<paissad> voici mon debian/rules, regardez la cible clean
<paissad> http://pastebin.com/f4d174e23
<paissad> voci certains warnings conernant le sujet, http://pastebin.com/m436ec776
<azeem_> this is an english-language channel
<paissad> yeah i know , i mistaken ^^
<kamalmostafa> ScottK: Hi
<ScottK> Hi kamalmostafa.  I've been mostly offline and busy with work so I haven't had a chance to review anything.
<kamalmostafa> ScottK: Understood, but I would really like to get libtifiles/libticalcs resolved -- we have been sitting on it for too long now and its holding up other folks' work.   If you're too busy to review it, perhaps we should consider just putting my completed packages on u-u-s for review?
<ScottK> kamalmostafa: I think that's fine.
<kamalmostafa> ScottK: Okay very good.  I'll make sure they still build (its been a few weeks!) and release them to u-u-s.   I think I should proceed then to the rest of the libti set -- do you agree?
<kamalmostafa> persia: I think you had some interest (?) in the libti stuff also, so heads-up.
<persia> kamalmostafa: Feel free to subscribe me to the bug if I'm not already subscribed.  I can't promise I'll get to it soonest, but I'd like to see it sorted.
<kamalmostafa> persia: will do.
<LimCore> the build command appears to be running some test or something, how to disable that?
<LimCore> some stupid unit tests for python, while building subversion
<geser> you should better let the test-suite enabled
<geser> and those test are probably from the python bindings (python-subversion build from subversion)
<ScottK> kamalmostafa: Yes.
<asbin> Hi ervybody. I would to have 1 package reviewed ... (enna : http://revu.ubuntuwire.com/details.py?upid=7677 )
<asbin> I'm seing on REVU, at the top : "Next REVU Day: TBD", what this means ?
<lfaraone> asbin: "to be decided"
<asbin> I see
<asbin> so, what are the odds to have a new package included in Lucid at time ?
<asbin> and thank you lfaraone !
<lfaraone> asbin: it depends on whether you can find someone to review it :)
<asbin> lfaraone: not only "someone", but 2 MOTUs ! :)
<persia> asbin: How does enna perform at 800x480 pixels?
<asbin> persia: yes I think so !
<persia> asbin: You think it works?  Let me ask this differently: would this be a good thing to install on a handheld?
 * persia likes EFL stuff for handhelds, but lots of media stuff expects more processing power than is typically available
<asbin> persia: Enna works perfectly on a Nokia N900 !
<asbin> for example
<MTecknology> !info tetgen
<ubottu> tetgen (source: tetgen): A Quality Tetrahedral Mesh Generator. In component multiverse, is extra. Version 1.4.2-3 (karmic), package size 219 kB, installed size 664 kB
<MTecknology> !info tetgen lucid
<ubottu> tetgen (source: tetgen): A Quality Tetrahedral Mesh Generator. In component multiverse, is extra. Version 1.4.2-3 (lucid), package size 219 kB, installed size 664 kB
<persia> asbin: That's what I wanted to hear.  I'll add it to my list of stuff to hit as soon as I can get some real REVU time, and take a quick look at the diff now to see if anything pops out.
<MTecknology> The latest version of that package is 1.4.3; how do I find out the best way to see that it finds its way into lucid?
<asbin> persia: great news ! :) Thank you in advance ...
<bdrung> geser: what is P-a-S?
<geser> Packages-arch-Specific
<geser> a list of overrides for the Architecture field
<persia> asbin: I've put up a few minor comments, mostly as points for thought.  I'll give it a real review when I have time, whether you upload it again or not.
<asbin> persia: thank you very much ! I will fix this ASAP !
<bdrung> geser: bug #519996
<ubottu> Launchpad bug 519996 in google-perftools "Sync google-perftools 1.5-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/519996
<asbin> persia: I mean tomorrow ...
<MTecknology> !info openoffice.org lucid
<ubottu> openoffice.org (source: openoffice.org): full-featured office productivity suite. In component main, is optional. Version 1:3.2.0~rc4-1ubuntu1 (lucid), package size 4 kB, installed size 44 kB (Only available for armel i386 m68k mips mipsel powerpc s390 amd64 ia64 ppc64 s390x sparc hppa all arm)
<persia> asbin: heh
<lfaraone> !info python-xdgapp lucid
<ubottu> Package python-xdgapp does not exist in lucid
<geser> bdrung: the control file already specifies amd64, i386, ia64 and ppc64 but P-a-S overwrites it currently to only ia64
<geser> don't know if ARM == armel and if it should get added there too
<geser> see https://code.edge.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu for the current P-a-S list for ubuntu
<lfaraone> geser: not all ARM devices can run armel code, but all ARMel devices can run arm code.
<persia> Um, not necessarily.
<persia> And it gets complicated by Thumb1 and Thumb2 internetworking.
<persia> That said, we compile everything afresh, so it doesn't matter that much.
<lfaraone> persia: oh? my apologies, I'm not very familiar with the field, just speaking off what I recalled.
<persia> In terms of dpkg-architecture, "arm" != "armeb" != "armel".
<geser> this is about libunwind saying "ARM, MIPS and PowerPC support added"
<persia> And due to massive differences in toolchain defaults, Debian "armel" != Ubuntu "armel".
<persia> That's definitely worth a compilation attempt.  Worst case, we end up with a FTBFS package.
<persia> Has someone tried a local emulated build?
<bdrung> yes, but better a FTBFS instead of not building. and maybe the FTBFS can be fixed easily.
<bdrung> persia: emulated build?
<lfaraone> persia: hm. has there been effort to synchronize the toolchain settings?
<persia> bdrung: Yep.  With lucid pbuilder-dist or mk-sbuild{-lv,}, you can build armel packages on i386 or amd64.
<persia> lfaraone: quite the opposite.  Debian targets ARMv4te+ and Ubuntu targets much more modern processors (different set each cycle so far).  So, for newer stuff, Ubuntu is faster than Debian, but for older stuff, Debian works and Ubuntu doesn't>
<persia> For example, the SheevaPlug ships with something based on jaunty prerelease, but it can't run karmic.
<bdrung> persia: pbuilder-dist can cross-compile?
<geser> qemu
<persia> bdrung: The lucid one can, but it's not cross-compilation, it's emulated-compilation using a binfmt-misc hack to invoke qemu.
<persia> bdrung: I believe it's `pbuilder-dist --arch=armel lucid create` on lucid, but I don't use pbuilder much, so I might have that wrong.
<bdrung> k, qemu. for small packages it's ok.
<persia> RIght.  Openoffice would take a while :)
<bdrung> i don't want to compile eclipse in it.
<persia> No :)
<bdrung> (except i am one day far away of my computer)
<persia> Only one day?
<bdrung> persia: times 10 isn't enough?
<bdrung> persia: i need 15 mins to compile eclipse on amd64.
<persia> bdrung: That's all?  Maybe it is enough.
<persia> bdrung: https://launchpad.net/ubuntu/+source/eclipse/3.5.1+repack~3-0ubuntu2/+build/1474867
<persia> Or maybe https://launchpad.net/ubuntu/+source/eclipse/3.5.1+repack~1-0ubuntu3/+build/1314062 is more interesting.
<lfaraone> did they manage to get the later versions of eclipse to compile?
<lfaraone> interesting, last time I checked we had 3.2
<persia> lfaraone: It's being sorted ;)
<bdrung> lfaraone: thanks to eclipse-build and DOA team we have 3.5.1 in karmic.
<bdrung> persia: it's faster than build oo.org: https://launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0~rc4-1ubuntu1/+build/1478069
<persia> bdrung: Indeed :)
<persia> Too bad the build log didn't capture the error report from the JDK though.  Hard to debug with that information without spending 10 hours running an emulated build.
<bdrung> persia: you need a fast hard disk. eclipse produces 20.8 MiB log (there were day where it produced 30 MiB)
<persia> Ah, that's not me then.
 * persia is disk-limited when running aptitude
<gusnan> ls
<asbin> persia: I've fixed the package following your recommendations, it's uploading right now :)
<lfaraone> persia: is it just me, or has aptitude/apt/dpkg gotten considerably slower in karmic when it reads package lists?
<persia> lfaraone: I haven't noticed any special difference, but I've seen that symptom before on a system that was upgraded a lot.  There's a way to dispose of history (which I forget) that speeds it up considerably on systems that have been continuously upgraded for a while.
<gusnan> Could someone please take a look on the "sciteproj" package on revu for me? It is availible here: http://revu.ubuntuwire.com/details.py?upid=7682
#ubuntu-motu 2010-02-12
<nigel_nb> I've been trying to build a package and I get some error in pbuilder, can someone review the error and help me figure out whats wrong?
<nigel_nb> this is the error message I get http://pastebin.com/d1cede653
<RAOF> That's an indication that one of the patches the packaging is trying to apply is failing.
<RAOF> You could almost-certainly duplicate this outside of pbuilder by running âdebian/rules patchâ.
<nigel_nb> I did a quilt push -a and it worked though
<nigel_nb> ok, yes.  It is being duplicated
<nigel_nb> RAOF, thanks.  Figured whats wrong now :)
<rhpot1991> fabrice_sp: ping, you just approved one of my sponsorship packages and I was hoping you could look at the associated package on revu: http://revu.ubuntuwire.com/p/hdhomerun-config-gui
<fabrice_sp> nice try rhpot1991 :-)
<fabrice_sp> I already have a backlog of stuff to review: I'll put it in my list
<rhpot1991> fabrice_sp: no rush either, I'm going to bed.  Anything changes you've recommended I made on this package too.
<rhpot1991> fabrice_sp: ok good enough, figured it might be a quick one since its associated with the one we worked through
<fabrice_sp> great: I'll have a look this evening (early morning here)
<rhpot1991> thats fine, I'll be out for the next few hours anyways, whenever you get a chance
<fabrice_sp> ok: good night then
<rhpot1991> I just added the DEP-3 tags to it and pushed, so it should be in good shape
<rhpot1991> thanks, cya later
<fabrice_sp> cool: did you also run lintian -iIE on source and binary pacakge?
<fabrice_sp> anyway: will check it. Bye
<rhpot1991> I ran lintian, didn't specify any flags though
<fabrice_sp> ok
<rhpot1991> fabrice_sp: I see this no dpatch description warning, but thats cause it was move to the DEP-3 tags
<rhpot1991> its clean other than that
<fabrice_sp> cool: sounds good then ;-) I'll check it later on (have to check some ubuntustudio interesting packages first :-) )
<rhpot1991> thanks fabrice_sp
<fabrice_sp> yw :-)
<SevenMachines> hi, i was looking at joining the ubuntu bug control team but i'm a little confused by the application selection option 5, 'list 5 bugs you've triaged'. but without being a member of bug control my 'triaging' in terms of importance tags and so on is obviously quite limited, and a lot of the other bugs i'm on are now out of date and/or have already been triaged by the professionals :)
<SevenMachines> do i just add a bit about why the importance and so on was set that way even if it was nothing to do with me?
<RAOF> SevenMachines: As far as I know, what you'd be expected to show there are bugs where you got the relevant information from the submitter, and then asked a member of the bugteam to set the importance.
<SevenMachines> ah, thanks, i don't think i've asked someone to set the importance more than a couple of times. i'll try and remember that in future. theres probably a few i could ask to be 'fix committed' due to a merge
<dholbach> good morning
<thekorn> good morning dholbach
<dholbach> hi thekorn
<abogani> Hi All, Sorry to bother you. I would want let you noticed that I just uploaded proposal package for the Arduino in REVU ( http://revu.ubuntuwire.com/details.py?upid=7690 and https://launchpad.net/~arduino-ubuntu-team/+archive/ppa/+packages ). If someone could review it would be really appreciated! Thanks in advance!
<lazka> Ho do I build depend on all python verions for building python modules?
<soren> Build-Depends: python-all
<lazka> ah.. python-all-dev
<lazka> thanks soren
<soren> python-all-dev should only be needed if you're build python extensions.
<lazka> it's a pyrex binding for a c lib
<lazka> Is the xxx.instal file the right way to add extra (non .py) files to the package?
<Laney> yes
<Laney> or .docs if it's documentation
<Laney> or .examples, ...
<lazka> ok
<lazka> thanks
<SevenMachines> can i quickly check, if you have a version eg, 0.1build1, and then you make ubuntu changes, i take it you drop the build part altogether, ie 0.1ubuntu1?
<slytherin> SevenMachines: right
<SevenMachines> great, thanks
<menesis> can REVU mail me comments and advocations?
<menesis> there is a preference for that but it does not send me anything. I can subscribe to rss feed, but it is slow.
<paissad> guys, here is my debian/menu file , but after installation of the package, i don't have the package in my system menu !!
<paissad> http://pastebin.com/f5a93799e
<paissad> btw, i use xfce
<paissad> btw, i use xfce4
<paissad> do you have any idea why ?
<Rhonda> paissad: Do you have the menu-xdg package installed?
<paissad> Rhonda, no
<Rhonda> The debian menu file entries only show up (in a Debian submenu) if you have that installed.
<paissad> Rhonda, but how other programs did install their menu icon
<Rhonda> Otherwise you need to do a .desktop file.
<Rhonda> See contents of files in your system below /usr/share/applications/
<paissad> Rhonda, what would you do advice to do then ?
<Rhonda> (IMHO) unfortunately some desktop environments think they need to hide the Debian menu. :/
<paissad> share/apps or share/pixmap ?
<Rhonda> Not sure what you mean with share/apps or share/pixmap.
<Rhonda> You need to put a .desktop file into /usr/share/applications/ in the proper format.
<paissad> Rhonda, ok
<Rhonda> paissad: Take a look at files already in there for examples, the documentation for the format is quite technical and IMHO hard to grasp. Ask if you got specific questions about certain lines, but it should get you the idea.
<paissad> Rhonda, yep, thx
<Laney> there's a desktop-file-validate script in some package
<paissad> i've finished creating my package, i have this warning btw --> arch-dep-package-has-big-usr-share
<paissad> but i just the fact is that it's a java software containing a .jar file which is 19MB huge
<paissad> at leat ... and this jar file is in /usr/share/$package_name/
<paissad> i guess it could be an exception knowing that i saw some other  java packages which contain jar files in /usr/share !!
<paissad> huges jar files ^^
<paissad> i runned lintian -iIEv -pedantic
<paissad> ran*
<paissad> is it ok then ?
<siretart> paissad: no, its not. use an arch: all package for those cases
<paissad> siretart, i don't know what you mean
<paissad> all package for those cases ?
<siretart> use 'architecture: all' instead of 'architecture: any' in debian/control
<slytherin1> paissad: if it is java package and complete platform independent code, you should have Architecture: all in debian/control file.
<askhl_> Hi, I'm trying to build a debian package of a Python/C program using distutils and python-central.  I'm getting an error after the distutils build finishes, saying "/bin/sh: python2.5: not found", "make: *** [debian/python-module-stampdir/gpaw] Error 127", and "dpkg-buildpackage: error: debian/rules build gave error exit status 2".  I would like to not depend explicitly on python 2.5, but am not sure where to start looking, nor where exactly th
<persia> askhl_: Please post the entire build log.
<persia> (to a pastebin)
<askhl_> persia, one moment
<askhl_> persia, http://www.student.dtu.dk/~ashj/opendir/build.err and http://www.student.dtu.dk/~ashj/opendir/build.log
<askhl_> I can build the program separately running 'python setup.py build' without any errors
<askhl_> (although there are compile warnings, but these are unrelated)
<askhl_> Ah, I see it loops "for buildver in 2.6 2.5; do"
<askhl_> I should probably depend specifically and only on Python2.6, since the program uses a slightly customized Python interpreter
<askhl_> (although it would work with other versions of Python as well, I'm packaging specifically for Ubuntu just now)
<sindhudweep> I'm getting an error using dput to upload a package to a team ppa. I'm fairly certain my .dput.cf is correct as I've used it before, but launchpad is telling me "Launchpad failed to process the upload path '~gnash': path format mismatch."
<askhl_> sindhudweep, perhaps you need to specify ~gnash/ppa/ubuntu/
<askhl_> (disclaimer: not exactly an expert)
<sindhudweep> askhl_: let me try that. Has the path format changed? I'm trying to understand why it worked before and doesn't now. http://pastebin.com/m5bf48b94 is my dput config file.
<askhl_> sindhudweep, I have (at all times) had the /ppa/ubuntu/ in my 'incoming' path
<sindhudweep> okay thanks. I must be mistaken!
<askhl_> otherwise it's pretty much the same
<sindhudweep> http://blog.launchpad.net/cool-new-stuff/multiple-ppas-per-person  <--- changed here
<sindhudweep> i must have been using a really old config file :D
<askhl_> persia, the build works correctly if I simply specify 2.6 as the python version rather than the more general (but true) >= 2.3.  I think I'll just do 2.6 for now, then I can improve the package later.  Thanks
<persia> askhl_: Try build-depending on "python-all".  This should get you the correct defaults for any environment (I think).
<persia> askhl_: In lucid, that's just 2.6, but it might differ in other environments.
<askhl_> Ah okay.  So in Karmic (which I'm using), it's probably 2.5 and 2.6, which is the explanation
<askhl_> Thanks again
<persia> Potentially, but by using that as a build-depends, it should just do the right thing.
<persia> But check with the python packaging policy, which is more correct than I.
<askhl_> I think it was just me being silly, since I didn't have 2.5 installed.  But if I submit it to launchpad as a PPA, it'll probably know to download the necessary python packages.  So I should be fine
<persia> Right.  You might want to experiment with sbuild or pbuilder to simulate that behaviour locally.
<spwelton> woot! got my debian/watch file working last night!
<dholbach> if anybody's interested in getting https://launchpad.net/lazr.restful into Ubuntu, it'd be nice if you could have a 2nd look at lukasz-czyzykowski's packages on REVU, thanks :-)
<dholbach> highvoltage: ^ good thing is that some of the packages are shared with schooltool!
<dholbach> ajmitch: ^ zope fun! :)
<BlackZ> hi dholbach !
<dholbach> hi BlackZ
<rmunn> I'm interested in getting NLTK (http://www.nltk.org/) into Lucid, especially now that there's been an O'Reilly book published about it. But to do that, I need people to review and advocate http://revu.ubuntuwire.com/p/python-nltk soon. It should be ready to go on -- last set of comments revolved around cosmetic issues (a false-positive lintian warning), so I don't think it'll take much work on the reviewer's part. Any takers?
<spwelton> Hi all, I made some revisions to eggtimer on REVU at http://revu.ubuntuwire.com/p/eggtimer and was wondering if someone could check it to make sure I've fixed the problems reported in previous comments. Any input is apprciated! Thanks!
<abogani> Hi All, Sorry to bother you. I would want let you noticed that I just uploaded proposal package for the Arduino in REVU ( http://revu.ubuntuwire.com/details.py?upid=7690 and https://launchpad.net/~arduino-ubuntu-team/+archive/ppa/+packages ). If someone could review it would be really appreciated! Thanks in advance!
<persia> nixternal: Didn't you have one of those devices?
<nixternal> persia: yes, my dog ate it :)
<persia> nixternal: Yes, but you might want to review the package so that when you get a new one it Just Works :)
<nixternal> hehe
<persia> Anyway, pets eating things is an old, tired excuse (even if true)
<nixternal> that is true on both fronts
<hakaishi> Hello everyone! Anyone upto advocate (or review) qt-shutdown-p? http://revu.ubuntuwire.com/p/qt-shutdown-p
<paissad> here is my control file http://pastebin.com/f544fafbb, but i've been told that i should change the maintainer field
<paissad> where is the ubuntu policy for that ? ... i based on debian policy to do that !
<persia> check the ubuntu-policy package.
<paissad> persia, where is ubuntu-policy ?
<paissad> the doc  i mean
<persia> There's a web mirror at http://people.ubuntu.com/~cjwatson/ubuntu-policy but I don't know how often that is updated.
<persia> paissad: apt-get install ubuntu-policy :)
<paissad> lol
<spwelton> persia: If you've got the time, could you please check my package on REVU? I updated it to fix the errors reported in the comments. http://revu.ubuntuwire.com/p/eggtimer Thanks!
<cjwatson> I update it when I merge
<persia> In that case, it's always up to date :
<persia> spwelton: Please find someone else: I've reviewed that a couple times, and like I said before, think it's duplicate to stuff we already have.
<spwelton> ok
<persia> spwelton: Feel free to ask me again after Feature Freeze if you still need review: I may have more time then.
<spwelton> oh ok, Yeah i figured you guys would be pretty busy right now with feature freeze coming up
<spwelton> i think i've got it mostly figured out though.. I gave up entirely on using quickly to do any of the packaging and did it all manually
<persia> heh.
<mantis> hi, can anyone give me some help installing video card on ubuntu 9.10?
<rmunn> mantis, This isn't the best channel for technical support. Ask your question in #ubuntu and you'll get more attention.
<mantis> thnx
<paissad> what do you suggest me to put in Maintainer field ? .... i already put --> XSBC-Original-Maintainer: Papa Issa DIAKHATE <paissad@gmail.com>
<persia> update-maintainer should do the right thing
<persia> But it's usually something like "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>"
<paissad> ok
<paissad> persia, what about Ubuntu Motu Developers ?
<paissad> i think i've seen something like that ?
<persia> paissad: You have seen that.  We used to use that for all new packages.
<persia> But it ended up that the MOTU team wasn't able to maintain all the new stuff by itself, so now we recommend just listing Ubuntu Developers.
<paissad> ok
<smoser> hi all, i'm planning on packaging txaws (https://launchpad.net/txaws) which uses setup.py, but does not have an upstream released tarball
<smoser> what path should I take to package it ? I'm guessing something with 0.0.1~bzr58 , but wondering how best to handle orig tarball
<persia> smoser: CAn you convince upstream to release one?  If not, you'll have to construct one.
<smoser> likely i can
<persia> That's the best option.  It means there exists some known blob that represents upstream, so it can be checksummed and stuff
<persia> Not quite as cool as if we had true object-matching network services, but getting closer.
<c_korn> grrr, timeout. can someone please have a look at the debdiff? did I make something wrong or did I miss something? http://pastebin.com/f36cd5cce
<c_korn> should I mention the update-maintainer in debian/changelog ?
<persia> c_korn: No pont mentioning the maintainer change in the changelog: it's policy-mandated
<persia> c_korn: I don't see anything else wrong.  Do you think it's better to make that change, or upgrade jhdf5 in lucid?
<persia> (and why)
<c_korn> persia: puh, I have no idea. I should ask that Sylvestre Ledru (maintainer of scilab and jhdf). he told me to revert that patch because it is more easy :) so maybe there is no need for 2.6.
<persia> 2.6 is in Debian unstable, and can be pulled to lucid if that makes sense.  If the Debian maintainer said 2.5 was the better choice, I'd go with that :)
<c_korn> I will ask him
<c_korn> persia: thanks, I await his answer and will let you know.
<persia> c_korn: No need to let me know specifically.  I just think you want to have a firm plan for how to deal with this in your mind when publishing that debdiff, because there are two ways to solve the problem.
<c_korn> persia: ok, as I said I have no idea about that library. so I let the maintainer decide.
<persia> That seems the best plan, and then work to make sure that the policy you receive is implemented in Ubuntu.
<persia> There's lots of cases where some package gets into a wonky state because of the sync/stop sync stuff, and if we can discover this early enough to make sure the release is in a good state, we're winning :)
<c_korn> persia: yes, I keep that in mind. thanks. I have to leave now.
<paissad> my package is lintian warning & errors free !! ...  i 've put lucid in the debian/changelog file instead of unstable .... now if i understand correctly i need to open another bug ? ... & close it after ?
<paissad> i did have a bug closed for debian already !
<persia> You had an ITP bug closed in Debian?  The package was uploaded to Debian?
<paissad> persia, yes , i had an ITP bug closed in debian .. no the package is not uploaded yet, i'm waiting for a mentor to see it :/
<persia> paissad: Aha!
<paissad> ;)
<paissad> so, do i need to open a launchpad bug ? ... via reportbug command ?
<persia> You don't *need* to open a launchpad bug, but it's preferred.  Most folk use `ubuntu-bug` rather than reportbug, as reportbug is a little wonky when dealing with launchpad.
<dupondje> if some package is ftbfs but there is a new version into debian sid that (prolly) fixes it, is there some special things to do ? :)
<persia> dupondje: First step is to make sure that "prolly" isn't part of your thoughts, because you know the answer :)
<persia> dupondje: After that, you'll want to review other changes, and build an opinion as to whether it should all be synced, or we only want some patches.
<dupondje> persia: seems they just fixed the ftbfs in the new version in sid :)
<dupondje> so no other changes
<dupondje> trying to build now
<persia> dupondje: Well, if that's the only change, then sure, a sync is precisely the right thing to do :)
<persia> dupondje: So, verify, and if that's the only change, and it works, call requestsync
<dupondje> added syncrequest :)
<randomaction> How do I fix a package which expects libGL.so to be in /usr/lib (while in fact it's in /usr/lib/mesa). I can make it build with -L/usr/lib/mesa, but then the executable fails to load (still expects the library in /usr/lib)
<persia> dupondje: Excellent.
<dupondje> there is some lagg before it gets added as a bug ?
<persia> Shouldn't be a significant one.
 * persia doesn't know much about requestsync, and doesn't personally ever use it, so maybe someone else has a better answer
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gnome-do-docklets/+bug/521152
<ubottu> Ubuntu bug 521152 in gnome-do-docklets "Sync gnome-do-docklets 0.8.2-2 (universe) from Debian sid (main)" [Wishlist,New]
<dupondje> there it is :P
<dupondje> somebody can accept it ? :)
<randomaction> dupondje: I'm looking
<dupondje> great :)
<randomaction> acked
<dupondje> thx
<dupondje> going to my next ftbfs :)
<geser> randomaction: is /usr/lib/ hard-coded in the binary? because other binaries find libGL.so
<randomaction> geser: according to ldd, libGL.so.1 => not found
<randomaction> so looks like no hardcoding
<randomaction> the package in question is rss-glx, by the way
<geser> does /etc/ld.so.conf.d/GL.conf point to valid file (after following all symlinks) for you?
<randomaction> no, it's a broken symlink
<geser> how did you broke it?
<randomaction> I wonder myself
<randomaction> what package should it belong to?
<geser> sudo update-alternatives --auto gl_conf should fix it
<geser> and the package who set it is libgl1-mesa-glx
<geser> I guess nvidia too (but can't check it)
<randomaction> why isn't it here, then? http://packages.ubuntu.com/lucid/i386/libgl1-mesa-glx/filelist
<geser> /usr/lib/mesa/ld.so.conf
<geser> the symlinks are added through update-alternatives
<randomaction> ok, let's try it again
<geser> where did your broken symlink point to? perhaps it's a bug in an other package not updating it
<smoser> anyone here mildly ruby aware ?
<smoser> i started packaging right_aws and right_http_connection ruby libraries
<smoser> putting together the packages using the ruby-pkg-tools
<persia> smoser: You're aware that FF is in 5 days, right?
<persia> Do you need these for lucid?
<paissad> i cannot open an launchpad bug using ubuntu-bug
<paissad> it's a new package btw
<smoser> i have them building both libright-<xxx>-ruby1.8 and 1.9.
<smoser> persia, i am aware, and yes, they're hopeful for lucid.
<smoser> my problem is that the libuuidtools-ruby that they depend on only builds the 1.8.  should i just ditch the 1.9 packages for libright* ?
<persia> smoser: lucas is the resident ruby expert, but you may find http://pkg-ruby.alioth.debian.org/ruby-policy.html/ provides guidance
<persia> smoser: Generally that sort of thing ends up getting built in a loop (foreach sort of thing)
<lucas> smoser: is it in debian?
<smoser> libuuidtools-ruby is in debian
<smoser> but builds only the 1.8
<lucas> it uses ruby-pkg-tools? the setup.rb class?
<smoser> persia, doing 1.9 is as easy as adding a Package header for it.
<smoser> yeah
<smoser> thats from a build perspective, i'm not aware enough to know if that will "just work" from runtime
<lucas> smoser: so just remove the Package: stanza for 1.9, add it for 1.9.1, and change the build-deps
<lucas> and build-dep on the latest ruby-pkg-tools
<lucas> ah, you need to check that. ruby1.9.1 breaks lots of things
<paissad> i have no errors during lintian run, but i would like to know if this changelog is ok ? http://pastebin.com/f2b4ae77f ... the bug number was opened from debian ...
<sebner> paissad: ubuntu changelog is always -0ubuntu1 and I'm wondering if it makes sense to close a Debian BTS bug
<smoser> lucas, i'll have to check on the 1.9 compatibility of libuuid then.  but above your suggestion was to add that to libuuidtools ? i'm somewhat confused.  the libright* that i was putting together have a 1.9 stanza, but libuuid does not.
<paissad> sebner, i read ubuntu-policy, section 4.4, i did not see  & i still don't see -0ubuntu1 anywhere :s
<paissad> and actually,  i don't see any difference between debian/changelog explanations between debian-policy & ubuntu-policy
<dupondje> what could be a reason a package that is like months in debian squeeze isn't in ubuntu yet ?
<lucas> smoser: I miss some context. but really, why don't you just ship -ruby1.8? with 1.9 lib?
<lucas> smoser: the ruby community doesn't really care about 1.9.1 yet anyway
<persia> dupondje: Usually sync failure.  Which package?
<dupondje> gnucash
<smoser> what does "with 1.9 lib" mean?  i'm sorry for being dense.  I think you're implying just drop the 1.9 from the things i was goign to package, which is probably fine.
<smoser> i just modeled my packaging after others i had seen, that had a "libX-Y-ruby" that depended on a libX-Y-ruby1.8 and also built a libX-Y-ruby1.9
<smoser> ie, the "default" was 1.8 but there was 1.9 available.
<sistpoty> dyfet: just taking a look at sipwitch upgrade
<persia> dupondje: Needs a merge
<smoser> lucas, https://code.launchpad.net/~smoser/+junk/libright-aws-ruby is what i have now. maybe that will clear things up.
<sistpoty> dyfet: one problem with the init script: please test if $DAEMON is actually executable before trying to start it
<persia> dupondje: If you look at the version in Ubuntu, you'll see it has local changes, etc.
<dupondje> persia: it has patches yes, but they got added upstream
<sistpoty> dyfet: (the package can be in removed state, which leaves conffiles around, which means that the initscript would still be around, but not $DAEMON)
<lucas> smoser: yes, sorry, doin several things at the same time. you can drop the -ruby1.9(.1)? package
<persia> dupondje: But it doesn't look like anyone has gone through to verify that and make sure that we can sync the Debian version.
<persia> dupondje: Also, if the orig.tar.gz files differ, we can't sync Debian, so need to merge in the changes from Debian.
<smoser> ok. that seems to make the most sense. thanks.
<sistpoty> dyfet: same is true for the cronscript, though that only results in a mail
<randomaction> geser: thanks for your help, I think I should add libgl1-mesa-glx to deps/build-deps
<sistpoty> dyfet: others than that looks quite nice, at least just from reviewing the .diff.gz so far
<oojah> Hi, could someone please take a look at http://revu.ubuntuwire.com/p/sqlite3-pcre ? It's a nice and simple package that is for a sqlite extension that implements the REGEXP() call with pcre.
<geser> randomaction: isn't libgl1-mesa-dev enough? it depends on libgl1-mesa-glx
<randomaction> it's not in the build-deps
<fabrice_sp> Rhonda, about bug 347256
<ubottu> Launchpad bug 347256 in pgadmin3 "pgadmin3 has ugly icon" [Undecided,Fix released] https://launchpad.net/bugs/347256
<geser> how does it link against libGL then?
<randomaction> geser: here's the list: http://packages.debian.org/sid/rss-glx
<fabrice_sp> do we use menu files in Ubuntu?
<randomaction> it has libgl1-mesa-glx | libgl1
<dyfet> sispoty: I used an already needed bug fixes to clean up a few other small things...
<dyfet> (sistpoty)
<persia> fabrice_sp: We certainly can use menu files, but we don't present them to users by default.
<geser> randomaction: ah, it b-d on libgl1-mesa-swx11-dev
<fabrice_sp> persia, I mean: kde and gnome uses .desktop file, so is there some windows manager in Ubuntu that uss menu files?
<fabrice_sp> s/uss/uses/
<geser> randomaction: I guess we should take this now to #ubuntu-x
<randomaction> geser: I'm a little lost with all these libgl* libraries
<dyfet> sistpoty: and it does test.... "test -x "$DAEMON" || exit 0" early in the init script... :)
<randomaction> geser: so if you can formulate the problem, please do
<geser> randomaction: a work-around for now would probably be to use libgl1-mesa-dev instead of libgl1-mesa-swx11-dev
<persia> fabrice_sp: There are a few window managers in Ubuntu that depend on the menu files.  Also, installing the menu-xdg package exposes menu files to XDG-compliant menu systems (like those used in KDE and GNOME).
<geser> but I don't know yet if it's a bug that libgl1-mesa-swx11 doesn't provide a ld.so.conf snippet
<sebner> paissad: https://wiki.ubuntu.com/PackagingGuide/PackagingOverview
<Rhonda> fabrice_sp: If menu-xdg is installed, yes.
<fabrice_sp> persia, ok. Thanks! (I sponsored an upload that broke a menu file, and was trying to undertand the criticity of that)
<persia> fabrice_sp: unbreak it: it's a regression for some users.
<fabrice_sp> ok
<sistpoty> dyfet: nice, thanks. haven't seen it in the .diff.gz :)
<fabrice_sp> Rhonda, will you adopt the changes in Debian?
<Rhonda> fabrice_sp: It's not that extremely critical, it's just that I would have welcomed coordination last year already and karmic could have had that fixed. So it's more a bit of grumpy mood in me that "reopened" that one.
<Rhonda> Definitely, though the xpm file will get installed additionally, the debian menu entry doesn't like svg.
<fabrice_sp> yeah: this has been open since one year
<fabrice_sp> ok: will install both then
<dyfet> sistpoty: ah...yes, that part wasnt broken in the old init, so it would not be in the diff :)
<Rhonda> fabrice_sp: And I'm not totally sure what happens with the desktop entry if it references the file without filetype. Maybe changing the desktop file to mention .svg extension?
<persia> .desktop files should not specify the extension.
<fabrice_sp> Rhonda, desktop files are able to find the right extension, AFAIK
<Rhonda> persia: Which one would get used then? The svg or the xpm?
<Rhonda> fabrice_sp: â¦ which one is the right one? :)
<sistpoty> dyfet: oh, sipwitch-dbg is empty?
<fabrice_sp> desktop-file-validate complains if you have an extension, yes
<persia> They should be loading by name from the icon-cache, and the icon-cache deals with the set of mime-types that provide that name for the menu system displaying them.
<Rhonda> You'll say "obviously the svg", but that doesn't sound too obvious to me.
<dyfet> sistpoty: is it?
<persia> Rhonda: I usually name the .xpm and .svg icons with the same basename, use the .xpm in the menu file, and put the basename in the .desktop file for the icon-cache to pick the best one.
<Rhonda> fabrice_sp: Can you install both (xpm + svg) and check which one the menu entry would reference?
<sistpoty> dyfet: yes, but I'm not 100% sure if I need pkg-binarymangler (or some other package) which is there on the buildds installed in pbuilder
<persia> Rhonda: The answer to that question (for XDG-compliant menu impementations) depends on the environment, so different desktop environments may select the svg or xpm.
<dyfet> sistpoty: my last build did build a dbg package....
<Rhonda> fabrice_sp: While you are at it, I noticed it through being sent the ubuntu diff through the PTS, in case you wonder. I now did scan quickly over the launchpad bugs of pgadmin3 and I think that we should drop the "System" category from the desktop file.
<sistpoty> dyfet: yes, the package is there, but it contains only /usr/share/doc/...
<fabrice_sp> Rhonda, it checks first png, then svg and at last, xpm (http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html)
<fabrice_sp> so it should be ok
<Rhonda> persia: And this is what I fear. It's not totally predictable â¦  I want to have it well defined. :)  I guess I'll rename the xpm to â¦ nevermind, thanks fabrice_sp for looking it up!
<dyfet> sistpoty:  hmm, it seems to be doing that now that I switched to dh7 style from cdbs...??!!
<persia> fabrice_sp: That'S the spec: at least in the past some menu implementations have preferred svg over png :)
<fabrice_sp> ok. Anyway, xpm seems to be alsways the last one :-D
<Rhonda> fabrice_sp: Hope you aren't mad with me for the response, it really seems to be a fight sometimes to get people to forward such issues. It's less work for everyone involved if it gets fixed in Debian first. No patch to check for syncing on concensus, and this is no issue to sweat about. :)
<fabrice_sp> Rhonda, will check that also
<persia> Rhonda: The idea is to exchange predictability for themability and best match to the prevailing environment.
<dyfet> sistpoty: the last (still using cdbs) build still had a normal debug package...
<sistpoty> dyfet: haven't myself yet tought dh 7, but from dh_strip it looks like you'll need to pass it -k (I have no clue though how to do that)
<fabrice_sp> Rhonda, not at all: I always try to get Debian maintainer involved (first at the beginning at the dev cycle, after when release date comes closer)
<Rhonda> fabrice_sp, persia: About that category bug (don't have the number handy) - there is actually a "programming" menu in ubuntu?
<persia> sistpoty: dyfet overrride_dh_strip:\n\tdh_strip -k ...
<Rhonda> I don't see this on my Debian desktop, and I don't find any named category in the specs?
<dyfet> persia: thanks :)
<fabrice_sp> Rhonda, in this case, if you get it fixed quickly, I could request the sync, but just in case,I'll fix it
<persia> Rhonda: There is a "Programming" menu at least for GNOME/KDE/xfce4
<fabrice_sp> In gnome, yes
<persia> Rhonda: But Categories should be selected from the registered list
 * persia digs up the URL
<Rhonda> persia: I have Development but no Programming?
<persia> http://standards.freedesktop.org/menu-spec/latest/apa.html
<fabrice_sp> Weel, mine is in Spanish, so I have Desarrollo :-D
<persia> Right.  I think stuff in Category "Development" ends up in a menu called "Programming".
<sistpoty> dyfet: hm... strange
<Rhonda> persia: Yes, that's where I'm in too.
<dyfet> sistpoty: yes, that was a dh7 suprise :)...let me do a quick check build here...
<Rhonda> persia: Oh, I'm using German locale and that one is named "Entwicklung" (german term for development) so I thought it would be just exactly that in english.
<Rhonda> persia: Anyway, pgadmin3 _does_ set that category in its desktop file so I wonder, it should appear in there?
<Rhonda> It's just that it _also_ appears in the System menu.
<sistpoty> dyfet: anyways, I wouldn't also mind uploading it w.o. the -dbg package containing anything, as anything else is really nice! but it's your call of course
<persia> Rhonda: I think it ought.  I'd have to check the .menu files to be sure.
<paissad> it is said that we may not need to open a launchpad bug for a new package
<paissad> is it true ?
<Rhonda> Categories=GNOME;Database;System;Development;
<persia> Rhonda: Does it have two Categories in the "Main Category" section?
<Rhonda> yes
<persia> Right.  It should just have "Development; Database"
<dyfet> sistpoty: it should just take me a few minutes to verify persia's suggestion, though I am sure he is correct
<Rhonda> persia: What's the GNOME part? Should I drop that one too?
<sistpoty> :)
<persia> Rhonda: the "GNOME" category is a historical leftover from before OnlyShowIn: was available.  It may be dropped.
<persia> And I didn't like it anyway, unless there was some really good reason not to show something in another menu (but I can't see why KDE users shouldn't use pgadmin3 as long as they don't mind having the libraries installed)
<persia> On the other hand, if you want to *remind* users that something only uses vertain libraries, "KDE", "GNOME", "GTK" "Qt", "Motif", and "Java" are permitted.
<Rhonda> Just to be sure, is ordering relevant? i.e., should I put Development;Database; or Database;Development;?
<dyfet> sistpoty: persia:  it did not make a difference!....go ahead and upload if you think its okay to do so otherwise, and I can always do a tiny update when we figure out that issue
<sistpoty> dyfet: ok, I'll upload what's there, I'm quite sure you'll follow up if the result is not to your liking, right? ;)
<persia> Rhonda: I generally do "${MainCategory};${AdditionalCategory}", but it shouldn't matter.
<Rhonda> Sounds more straightforward anyway, topdown. :)
<dyfet> sistpoty: of course :).  Now I am really curious why switching to dh7 clobbers dbg....
<rmunn> So I've been trying for a week now to get advocates for http://revu.ubuntuwire.com/p/python-nltk, and it's getting a bit discouraging, honestly. I've had several people give very valuable (and much-appreciated) feedback in IRC, but now that it seems the package is ready, I can't seem to get anyone to look at it. What else should I be doing besides mentioning it here in #ubuntu-motu?
<persia> rmunn: There's not much else you can do, unless there's another development team that might be interested.
<fabrice_sp> Rhonda, should I then fix the package in Ubuntu, or you will upload shortly a new version?
<persia> rmunn: I can understand that it's discouraging, but please also understand that as FF approaches, many developers focus on the features they need for FF, rather than having time for too many reviews.
<Rhonda> fabrice_sp: I'm trying to do that now. ;)
<sistpoty> dyfet: uploaded, thanks a lot for that great work!
<fabrice_sp> Rhonda, cool: I'll wait then ;-)
<rmunn> I think it's worth getting this into Lucid -- it's a pretty famous library in its problem domain (an O'Reilly book was recently published about it), so not having it in Ubuntu feels like an odd gap. But I don't know how to get anyone else intereted.
<Rhonda> fabrice_sp: Unrelated shameless selfpromotion: The bug decrease is my job. :P http://people.debian.org/~glandium/bts/p/pgadmin3.png
<persia> Rhonda: 0RC: nice :)
<fabrice_sp> only 2 :-)
<sistpoty> rmunn: patience... maybe I'll take a look later on;)
<rmunn> sistpoty: Thanks, would be appreciated.
<Rhonda> persia, fabrice_sp: Picked up the package last year and got an upstream developer to subscribe to the Debian BTS. ;)
<Rhonda> â¦ yet another reason to forward pgadmin3 bugs there. ;)
<persia> You're always good at that "make upstreams pay attention" thing :)
<fabrice_sp> :-D
<Rhonda> Of course, and ubuntu should learn that too. It reduces your own work requirement. ;)
<persia> I think most of the folk that do a lot of work know it, but lots of stuff gets done drive-by, which often doesn't get the follow-up it needs.
<rmunn> After Ubuntu Developer Week, I got enthusiastic about learning to be a MOTU, and there was a package I knew about (I was a technical reviewer for the O'Reilly book on NLTK) that I knew could go in. But I'm still new to the whole process.
 * Rhonda . o O ( I really think I should do my "Debian packaging backwards" talk )
<persia> Rhonda: Do you have an abstract somewhere?
<Rhonda> Not yet. It starts of off with "ar x foo.deb"
<dhillon-v10> hi all, this patch I was working on before: http://paste.ubuntu.com/374998/ turns out to be malformed at line 79, can anyone tell me how to fix that ?
<persia> Rhonda: heh.  That's an interesting way to teach it.
<Rhonda> persia: Somehow inspired by all the git talk of describing "to understand git you need to know what's inside"
<Rhonda> Need to head for bed now though.
<persia> Rhonda: makes sense, but suffers from TLDR for people who don't take it seriously.
<sistpoty> gn8 Rhonda
<Rhonda> fabrice_sp: I hope that I can upload tomorrow.
<quentusrex> fta, are you around?
<Rhonda> TLDR?
<rmunn> Rhonda, "Too Long, Didn't Read"
<fta> quentusrex, yes
<persia> too-long-didn't-read : the common response to most of my email
<Rhonda> lol
<quentusrex> fta, I noticed you do a lot of work on the mozilla ppa. Is there a reason there isn't a 'thunderbird' package to point to the latest stable like the 'firefox' package?
<fabrice_sp> Rhonda, ok. Ping me (or request the sync) to get it uploaded
<quentusrex> fta, something to make it easier to stay updated to the latest stable.
<fabrice_sp> sponsored, I wanted to say
<maxb> dhillon-v10: The numbers in the hunk headers don't match the content of the patch. I guess you were editing the patch itself manually? Run it through 'recountdiff'
<dhillon-v10> maxb: yeah, I did that but then later on screwed up somewhere else, actually 3 of my other patches got rejected because I edited them later on so do you think recountdiff can fix those
<maxb> It's fairly good
<Rhonda> fabrice_sp: I haven't put in the LP: closes message for the category bug. For a start I would even call that one invalid because it should appear in programming, for a second, I "just" dropped the system category in the desktop file, which is totally different to what the bug wanted. :)
<Rhonda> fabrice_sp: I though subscribed to it to not forget about it. :)
<fta> quentusrex, yeah, i used to do a lot of work on mozilla stuff, far less those days. micahg is working on tb now
<micahg> quentusrex: almost done :)
<quentusrex> fta, it said you had done the last round of commits
<quentusrex> micahg, awesome. Let me know if I can help
<quentusrex> I have found a bug in thunderbird 3.0 and 3.1
<dhillon-v10> maxb: is it supposed to take some time, btw thanks a lot :)
<micahg> quentusrex: testing if you're available this weekend maybe
<quentusrex> If you have an rss feed that has a relative url for the images,
<maxb> dhillon-v10: No, it should be instantaneous
<quentusrex> it doesn't use the correct domain for the images.
<micahg> quentusrex: please file against the thunderbird package and tag PPA for the moment
<quentusrex> it uses the domain of the rss feed(such as feed burner) rather than the domain of the site where the feed is for.
<quentusrex> ok
<dhillon-v10> maxb: here it just keeps on going still hasn't ended yet, like 4 mins.
<micahg> quentusrex: specify which versions and a sample feed if you can
<dhillon-v10> maxb: oh I know why :)
<rhpot1991> can you "rename" a file in install, ie : file.ico /usr/share/pixmaps/newname.ico
<rhpot1991> I think that might need to be done in links
<fabrice_sp_> Rhonda, sorry: piuparts killed my system. I only saw that you answered me something
<persia> rhpot1991: Not with dh_install, but you can do it in debian/rules (mv foo bar)
<fabrice_sp_> Rhonda, but not the content
<persia> fabrice_sp_: What timestamp?
<fabrice_sp_> 3 minutes ago
 * fabrice_sp_ still has to find why piuparts kill X...
<persia> Latest I have is 7 minutes ago, I'll /query
<rhpot1991> persia: can I reference the file in the same manner that I do in install?
<dhillon-v10> maxb: this is what happens now: http://paste.ubuntu.com/375006/ should i do the whole patch over?
<rhpot1991> persia: wondering about paths to the source
<persia> rhpot1991: Not quite.  You'll want to use `mv ${CURDIR}/debian/tmp/... ${CURDIR}/debian/tmp/...` : after that you can use dh_install on the new name if you're splitting the package.
<rhpot1991> persia: thanks
<kklimonda> can I use bzr merge-upstream with bzr branches and not tarballs?
<maxb> dhillon-v10: No need to do it all again, just manually apply the rejects and re-diff against the base
<kklimonda> I get a really scary error but on the other hand it tries to do something before I get it
<kklimonda> it even generates a tarball and when I try to merge-upstream it I still get "bzr: ERROR: [Errno 20] Not a directory"
<persia> kklimonda: I don't know much about using bzr-builddeb but if you have a local complete branch including packaging, and a foreign complete branch of newer upstream, you should be able to just `bzr merge {foreign-branch}` to get the latest code.
<persia> Mind you, you'll still want the tarball (debian/rules get-orig-source may help) to build a source package.
<kklimonda> persia, they don't have a common ancestor - that's why I was hoping to use merge-upstream comman and it seems to work up to the point when it doesn't :)
<persia> Ah, that makes it awkward.
<persia> I hear there's ongoing work to be able to merge without a common ancestor (for known similar content), but it's not likely ready for some time.
<quentusrex> micahg, I don't see where the report bug link got moved to...
<micahg> quentusrex: https://help.ubuntu.com/community/ReportingBugs#Filing bugs at Launchpad.net
<persia> quentusrex: ?no_redirect is the trick
<quentusrex> I wish the link would be on the software page.
<quentusrex> where everything else is located.
<quentusrex> found a bug in the reporting a bug software...
<persia> heh
<quentusrex> micahg, here is the feed: http://feeds.feedburner.com/zerohedge/feed
<quentusrex> load that into any thunderbird 3.*
<quentusrex> and all the relative image paths use the wrong domain.
<micahg> quentusrex: please file a bug, I cannot look into it now
<quentusrex> I need to reboot. Just installed a graphics driver update.
<quentusrex> micahg, I just tried and the bug report crashed.
<dyfet> sistpoty: what peria suggested lead me to one solution for the dbg package that did work, which was using the override_dh_strip to pass dh_strip the --dbg-package=sipwitch-dbg directly, but I am going to see if there is a better dh7 way to do debug packages that I simply do not know before submitting an update
<micahg> quentusrex: an oops?
<sistpoty> dyfet: oh, nice. feel free to ping me (as long as I'm awake) for skipping the queue ;)
<dyfet> sistpoty: I may get to look at it over the weekend :)
<sistpoty> dyfet: heh :)
<quentusrex> micahg, https://bugs.launchpad.net/ubuntu/+bug/521188
<ubottu> Ubuntu bug 521188 in ubuntu "Thunderbird 3.0 handling relative image urls wrong in rss feeds" [Undecided,New]
<quentusrex> there I was able to file that.
<micahg> quentusrex: k, I'll see if I can look at it sometime soon
<quentusrex> thanks.
<micahg> quentusrex: feel free to poke me next week if you don't see any activity
<quentusrex> ok
<quentusrex> thanks micahg
<paissad> i want to remove my previous uploaded package to revu.ubuntuwire.com ..... is it possible ? ..
<asbin> persia: Hi ! I've fixed some issues with enna package, if you want to have a look at it :)
<paissad> i want to remove theses packages (amd64 & i386) ones !
<paissad> http://revu.ubuntuwire.com/p/pms-linux
<paissad> finally, i built it in binary-indep instead arch dependent ^^
<paissad> instead of*
<persia> paissad: Just upload the new source, and it will replace the old one.
<persia> REVU doesn't build anything.
<paissad> persia, ok
<sistpoty> rmunn: just taking a look at the comments to python-nltk: If I read it right, there's still nltk.jar in the orig.tar.gz? if so, please remove it and repack the tarball, otherwise python-nltk would need to go to multiverse at best
<persia> sistpoty: Why?  Since it's deleted on clean, we *know* it's not used in the build, and we have source for it in the upstream tarball.
<sistpoty> persia: do we?
<persia> I thought we did.  Do we not?
 * sistpoty looks again at the comments
<persia> I'm not sure we can prove it, but I am sure we aren't distributing binaries to users that use it, and I am sure we can show md5sum match to upstream to indicate we're not shipping modifications without source.
<persia> (unless I'm confusing this with another package that had a jar to be deleted on clean that came up recently)
<rmunn> Was at another computer, back now.
<sistpoty> persia: maybe you'll need to teach me java lessons... as in comment 3, the .jar is built using 3rd party sources. My assumption is that hence the complete source for the .jar is missing, as I assume that code from 3rd party sources are contained in it
<sistpoty> persia: is that assumption true?
<rmunn> The nltk.jar was discussed a few days ago. It's built entirely from sources inside the .orig.tar.gz, but it depends on classes from Mallet, which isn't in Debian yet.
<rmunn> I had two options: repack (which would force reviewers to go through and compare my repacked tarball to the original to prove I hadn't inserted any Trojans), or keep the original and delete the .jar in clean. I chose the latter.
<sistpoty> rmunn: yes, I see, but does the .jar hence include just references to 3rd party sources or does it also contain code from these? (my java knowledge is really extremely limited)
<rmunn> There are no licensing issues with redistributing the .jar since its source code is entirely present in the .orig.tar.gz.
<persia> sistpoty: I think I missed that.  I concur with you: if the jar is build from external (unincluded) sources, it needs to go.
<persia> rmunn: My apologies for giving you incorrect advice earlier.
<rmunn> The only dependency on external sources is via "import edu.umass.cs.mallet.base.util.MalletLogger".
<sistpoty> persia: as I wrote, I'm not 100% sure if it is, I don't know too much what .jar files actually contain
<persia> rmunn: Entirely?  No third-party .class files?
<persia> sistpoty: It's a zip archive full of whatever, but interestingly full of .class and/or .java files.
<rmunn> Entirely, I checked. All the .class files in that .jar are built from javasrc/org/nltk/mallet/*.java files in the .orig.tar.gz.
<rmunn> All of which are licensed Apache-2, which allows redistribution of both source and binaries.
<persia> rmunn: If you've checked, and you're sure, I'll support you not deleting the .jar file.
<rmunn> And all of which are copyright the NLTK project, just like the rest of the source.
 * persia adds this to the list of packages to REVU soon
<sistpoty> rmunn: ok, if you're sure, I agree with you and persia. Let me just go out for a smoke to try to recall java a bit ;)
<persia> sistpoty: `jar tvf foo.jar` should show you the contents.
<rmunn> I'm going to try to persuade upstream not to distribute the .jar file in the .tar.gz source in the future, but it's too close to Lucid freeze for me to want another round of back-and-forth emails. :-)
<rmunn> Jar files are .zip files renamed, "unzip -l nltk.jar" will show you its contents too.
<paissad> guys, i uploaded my package, but i have a warning , i'm a lillte bit confused ! http://revu.ubuntuwire.com/p/pms-linux
<persia> rmunn: Yeah, but people who use tar a lot prefer that interface :)
<rmunn> http://pastebin.com/f37527b42 shows contents of the nltk.jar file from original upstream tarball, BTW.
<rmunn> persia, I didn't remember there was a "jar" command so I used "file" and discovered it was a .zip... :-)
<persia> paissad: That's just lintian being confused.  Override them.
<persia> rmunn: Yeah well, java people use jar :)
<paissad> persia, i had no warnings when i run lintian -iIEV -pedantic
<rmunn> persia, It's been ages since I did any real work in Java... basically since I discovered Python, I don't use any other language by choice -- only when contributing to a project that uses something else.
<persia> paissad: Odd, I'd have expected that one to show up.
<paissad> persia, :)
<persia> paissad: Could be that the newer lintian you're using locally doesn't get confused as easily.
<paissad> persia, Lintian v2.3.2ubuntu1
<persia> paissad: If you're clean locally (source and binary) ignore REVU's lintian messages.
<persia> Yeah, that's newer than the one on REVU.
<paissad> ok
<paissad> persia, i hope that the package will be available for lucid lynx ... many users are expecting it ... currenty they are downloading it from my personal repository ... i cannot play anymore in network with my PS3 because of downloads from the repo, ... i got many lags :/ ...
<sistpoty> rmunn: having thought about it for a bit, I think it's save to leave the .jar there, since all the source are present, and imho the java compile doesn't inline anything (at least from thinking a bit what the goals of a jvm are)
<persia> The main trick with .jar files in sources (if they are clean) is to remember to delete them right away to avoid the chance that they are used in the final output.
<persia> (otherwise one runs the risk of hidden code paths being promulgated)
<rmunn> sistpoty, Allowing the .jar file to be installed without recreating it in build step runs the risk of a Trojaned .jar file being inserted at some point in the upstream tarball. Recreating it from verifiable sources is best for security.
<sistpoty> rmunn: *nod*
<rmunn> So I delete it in clean -- and once Mallet is packaged for Debian (prolly in Lucid+1) I'll be able to recompile the .jar.
<persia> Right.
<rmunn> Right now I've just disabled the NLTK-to-Mallet interface that used that .jar (with upstream's approval) so that the package can get into Lucid. And in the process, I discovered a bug in the upstream code -- that interface was broken anyway :-O, so users won't actually notice any difference.
<sistpoty> crap, etree license looks out for problems: it demands having read (and agreed to) the license to *use* it
<rmunn> sistpoty, Does that violate DFSG?
<sistpoty> rmunn: no, but it means that the license needs to be displayed to the user (if the files are used in the first place) before she can use the software
<rmunn> I checked on the origin of the etree library in the NLTK code by looking at upstream's SVN logs: it was copied from the Python 2.5 code, not from the python-elementtree package. In case that makes any difference.
<sistpoty> I assume then the python license would apply?
<rmunn> sistpoty, Huh. I'm pretty sure upstream isn't doing that...
<sistpoty> (unless it allows to change the license, damn copyright stuff)
<paissad> i thank everyone here for the help, it's very kind !
<rmunn> The code comments give that license that I copied into debian/copyright, then the phrase "Licensed to PSF under a Contributor Agreement. See http://www.python.org/2.4/license for licensing details."
<rmunn> The license text at that URL does not contain the word "contributor", so I can't research further.
<sistpoty> did I mention yet, that I really hate license problems? :)
<rmunn> ... And now that I think about it, the etree license says "By obtaining, using, and/or copying this software ... you agree that you have read, understood, etc. the following: Permission to use, cop, modify, and distribute ... is hereby granted, provided that the above copyright notice appears in all copies ... [and] in supporting documentation."
<persia> Text like that typically requires the annoying debconf-show-the-license hack, and users hate it.
<rmunn> There's nothing in the conditions that the user could possibly be in violation of by simply using it.
<persia> Doesn't matter, because of the "obtaining, using" bit.
<rmunn> ... In fact, "by obtaining" would require showing the license BEFORE the download if you go by that interpretation.
 * persia gets extra grumpy at folk who use odd licenses
<persia> rmunn: Good point, but it means that it's not redistributable with our archive model.
<rmunn> persia, But this code is part of Python. Surely this was worked out at some point before?
<rmunn> Otherwise the same problems that apply to this code would apply to Python 2.5 and onwards.
<ryanakca> Could someone review http://revu.ubuntuwire.com/p/turnin-ng please?
<persia> rmunn: Would it be possible to delete the offending code from the tarball and build against the system library?
<sistpoty> actually, I may have been nitpicking on the license. The problem (and why I hate copyright stuff) is that I just don't know how to read it
<dupondje> gnucash is ftbfs, but if we want to fix it, we introduce a new bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567208 what is considered the best option then ? keep it ftbfs or ?
<ubottu> Debian bug 567208 in gnucash "Gnucash 2.2.9-3 has no graphing support" [Serious,Open]
<sistpoty> maybe a copyright expert might have an opinion on http://revu.ubuntuwire.com/revu1-incoming/python-nltk-1002101912/python-nltk-2.0~b8/debian/copyright, slangasek? (for example the etree license)
<persia> ryanakca: I don't have time for a full review right now, but I don't see why you shouldn't create the empty /srv/... directories on package install.  The rest of the packaging looks sane from an initial glance.
<rmunn> persia, It would be possible, but I haven't looked into the NLTK code to see what parts of it import nltk.etree internally. I hesitated to do so at first because I didn't want to diverge from upstream without a compelling reason -- but licensing issues would be compelling.
<persia> RIght.
<paissad> btw, i would like to know if it  is possible to make the uploaded package available from download like a normal repository ?
<persia> One of the reasons reviewers get harder to find as the packaging gets better is because licensing review becomes more important, and it's painful.
<ryanakca> persia: Because different universities like things in different places
<sistpoty> rmunn: looking at the suggests (e.g. numpy) and just grepping in the source code, are these meant to be suggests? (grep revealed import statements w.o. try-catch)
<persia> ryanakca: In that case, I don't see any obvious issues :)
<rmunn> sistpoty, I thought about making them Recommends, but Debian policy seemed to say "If the package would work with Suggests, use Suggests."
<sistpoty> rmunn: ok, so the files that do imports aren't needed for the average user, right?
<rmunn> Right -- they're for people doing statistical analysis, graphs of word frequency, etc.
<sistpoty> ok, thanks!
<rmunn> I would actually prefer to add a Recommends rather than a Suggests, but some tools pull in all Recommends: packages automatically, and I don't want to pull in python-matplotlib and all its dependencies (including X) on someone's text-only system when they can use NLTK just fine without it.
<sistpoty> rmunn: ok, nice rationale. just advocated the package, since my concerns regarding copyright really are beyond my knowledge about licensing
<rmunn> BTW, as far as the etree copyright issue is concerned: run "sudo apt-get install python-elementtree". Notice that it does not use the debconf hack to display the license before installing, despite the fact that it has the same "By using, etc." license.
<sistpoty> heh
<rmunn> So clearly, the Debian maintainer who added that package in 2004 didn't see a problem with that license.
<sistpoty> well, as I wrote, I just don't know if it's a problem in the first case ;)
<rmunn> :-)
<rmunn> I'll add a comment of my own to the REVU page in case another MOTU has questions about it.
<ryanakca> persia: OK, thanks :)
<rmunn> sistpoty, Thanks for the review and advocacy.
<sistpoty> rmunn: thanks for your work!
<rmunn> persia, Thanks for your comments on the .jar file and licensing. Would you recommend that I make major changes to the package at this point to tear out nltk/etree/* and replace it with a python-elementtree dependency, even though that would almost certainly mean not getting this package into Lucid? Or is the "python-elementtree has had this license since November 2004 and Debian accepted it" argument enough precedent for letting
<rmunn>  the etree-licensed code stand as-is?
<rmunn> I was doubtful about the license issue until I saw that python-elementtree uses the same license and had had no copyright issues raised in five years -- that settled it for me. :-)
<persia> rmunn: I recommend you do the work to strip out the embedded libraries, and then upload the result to Debian.
<persia> rmunn: I agree that you're unlikely to finish by the 18th, so may as well take your chances on the current package in REVU for lucid.
<slangasek> sistpoty: was there a specific concern in this license?
<sistpoty> slangasek: yes, covering "use"
<persia> Also required acceptance for "obtaining" the code.
<slangasek> ou may not use this file except in compliance with the License.
<slangasek> "you may not use this file except in compliance with the License." - that bit?
<sistpoty> exactly, slangasek
<persia> "By obtaining, using, and/or copying this software ... you agree that you have read, understood, etc. the following: Permission to use, cop, modify, and distribute ... is hereby granted, provided that the above copyright notice appears in all copies ... [and] in supporting documentation."
<rmunn> slangasek, The etree license says "By obtaining, using, and/or copying ... you agree that you have read ... the following terms and conditions."
<slangasek> is that enforceable anywhere?
 * persia doesn't think so
<rmunn> Thing is, the python-elementtree package uses that exact same license, and has been in Debian since November 2004 without (to my knowledge) any issues being raised.
 * sistpoty has no clue
<slangasek> I'd be inclined to ignore it as invalid on its face
<rmunn> And yeah, the "obtaining" bit would require reading the license before even downloading it... classic "shrinkwrap" license problem as I understand the legalities (IANAL, of course)
<slangasek> clickwrap/shrinkwrap are somewhat enforceable; a random license attached to the file is not
<slangasek> (file, download, package)
<sistpoty> thanks for your insight slangasek!
<persia> rmunn: Just to confirm, you didn't have to go through a license approval step in order to download the uptream tarball, did you?
<slangasek> unless the license itself requires that, when distributing, you ensure the people you're *distributing* to have read the license, then *shrug* it's unenforceably
<rmunn> persia, Correct. I downloaded it from http://code.google.com/p/nltk/downloads/list
<slangasek> -y+e
<rmunn> At no point was I required to click "I accept", either to download the file or to unpack the tarball.
<persia> slangasek: I've been interpreting licenses as potentially valid, if pointless, and claiming those are upstream bugs that ought be fixed.  Do we generally ignore these cases (in which case I should be less picky)?
<sistpoty> he, so I learned another thing: If a license statement is not enforcable, ignore it. Only problem I have that I absolutely don't know if a license statement *is* enforcable *g*
<rmunn> As I understand U.S. law, you generally don't *know* (with 100% certainty) what parts of a contract is unenforceable until a suit is brought and the judge rules on it.
<rmunn> ^is^are
<rmunn> "what parts ... *are* unenforceable"
<sistpoty> best package I ever reviewed was where the reviewee's wife was a lawyer and he simply asked her for an opinion *g*
<persia> rmunn: That's the case everywhere, I believe (or at least I don't know of any jurisdiction in which rulings can be taken by other than counterparty consensus without a bench ruling (for some definition of "bench")
<slangasek> persia: ignoring the intent of the copyright holder is not normally my preference, but in cases such as this where there's no conceivable way they could make it binding on the user, I'm ok with accepting it (while treating it as an upstream bug that ought to be fixed)
<slangasek> rmunn: legal nihilism isn't a very practical strategy when one is in the business of distributing free software
<rmunn> Incidentally, here's the copyright holder's own download page: http://effbot.org/downloads/#elementtree
<persia> slangasek: OK.  So I'll be just as picky in my complaints, but maybe let some pointless stuff slide through to the archive admins :)
<slangasek> sounds good :)
<rmunn> No "you must agree to the license in order to download this" anywhere on his page that I can see. So the copyright holder isn't enforcing the "by obtaining" part of his own license, as best as I can tell.
<rmunn> slangasek, Good point re: legal nihilism. :-)
<persia> rmunn: File an upstream bug :)
<sistpoty> persia: of course asking for an expert opinion beforehand might not only enlighten you but others as well (e.g. me *g*)
<rmunn> persia, But where -- in NLTK, or in Python which uses the same code (which NLTK got it from), or against ElementTree saying "Hey, your license is unenforceable"? :-)
<persia> sistpoty: The risk is that in many jurisdictions the act of asking anyone qualified to give an opinion creates a state that requires another qualified person to discuss.  I prefer to talk to people who are knowledgeable and interested, yet not actually qualified :)
<persia> rmunn: Yes.
 * persia would prefer the position of "magistrate" did not exist anywhere
<slangasek> heh
<sistpoty> persia: heh, well, but I guess the statement of slangasek was understandable, even to a non-law-informed person as /me wasn't it? ;)
<persia> sistpoty: Indeed it was.  I'm just under the impression that slangasek isn't "qualified", and I know he lives in a jurisdiction that allows lay arguments with qualified opinions.
<sistpoty> haha
<slangasek> IANAL, FWIW ;)
<persia> (although I do believe slangasek is expert in the area)
<sistpoty> heh
<paissad> damn it, i got another error :( ... which of these two is correct for the changelog file ? .......(Closes: #nnnn) or (LP: #nnnn)
<paissad> ?
<paissad> Debian uses Closes: #nnnn ...
<rmunn> paissad, It's "Closes LP: #nnnn" for Launchpad bugs.
<persia> paissad: The former closes bugs in the Debian BTS (if uploaded to Debian), and the latter Ubuntu bugs in launchpad (if uploaded or synced to Ubuntu).
<sistpoty> paissad: for ubuntu, it's LP: #<bugnumber>, for debian closes: #<bugnumber>
<sistpoty> paissad: for ubuntu, just look at the generated .changes file. it should contain "launchpad-bugs-fixed: <bugnumber"
<paissad> here is the changelog file http://pastebin.com/f102f3ec6 .. would you like to correct it please ?
<rmunn> FYI for anyone else looking at http://revu.ubuntuwire.com/p/python-nltk, I'll be on for another 30 minutes then I have to leave. So if you have any other concerns that I might need to address, please let me know now. :-)
<sistpoty> paissad: version number should be 1.20+svn386-0ubuntu1
<paissad> sistpoty, ok thanks ... i will add it
<sistpoty> paissad: otherwise it *looks* correct
<rmunn> Shouldn't it be "Initial release. (Closes LP: #521180)" in the changelog?
<rmunn> (I.e., you need to add the word "Closes")
<persia> rmunn: probably not.
<sistpoty> rmunn: no, afaict the regexp is just LP: [0-9]+
<paissad> sistpoty, why 0-ubuntu1 ? ..... if i rebuild the same version of the package, how must i rename it ?
<persia> rmunn: That *might* work (but I don't think so) in the unlikely event that one managed to have the *same* bug number in the Debian BTS and launchpad/ubuntu
<geser> no, the regex matches on lp: #xxxxx (in small or big letters)
<sistpoty> geser: thanks!
<sistpoty> paissad: if the package is uploaded in debian, the revision would be -1
<sistpoty> paissad: in Ubuntu we try to sync/merge what we can from debian, so the version should be lower
<sistpoty> paissad: so -0ubuntu1 is lower than the initial debian version
<paissad> sistpoty, ok i got it now :) thanks
<sistpoty> yw
<geser> the exact regexp is: /lp:\s+\#\d+(?:,\s*\#\d+)*/ig
 * sistpoty just relies on vim highlighting *g*
<sistpoty> geser: I see you've got a sponsor request open for main (bug #520648). Teach me how to use bzr, and I'll happily upload for you ;)
<ubottu> Launchpad bug 520648 in mknbi "Re-add -fno-stack-protector to CFLAGS" [Undecided,New] https://launchpad.net/bugs/520648
<geser> sistpoty: sure, https://wiki.ubuntu.com/DistributedDevelopment/Documentation in case you want to read it yourself
<geser> do you have bzr and bzr-builddeb installed?
<sistpoty> geser: bzr: yes, bzr-builddeb: no clue, but I can install that
<jariq> What should be the right status of "needs-packaging" bug after package was accepted ???
<sistpoty> geser: ok, I just did bzr branch lp:... and got some files now (it worked, for $whatever reasons, usually that failed since I don't want to set the bzr-lp cookie thingy)
<geser> sistpoty: bzr merge lp:~geser/ubuntu/lucid/mknbi/bug-520648 inside the branch
<sistpoty> geser: oh, I only got your branch *g*... /me retries
<geser> ah, you need to do bzr branch lp:ubuntu/mknbi to get the packaging branch
<geser> first
<geser> and merge my branch on top of it
<sistpoty> already at it, I think I'm on a route to find out the workflow
<sistpoty> geser: ok, bzr diff looks good. what now?
 * sistpoty would go bzr diff > debdiff now, and apply that to the sourcepackage, but there's for sure an easier way
<geser> bzr commit
<sistpoty> geser: does that mean I upload the package already?
<sistpoty> geser: I'd like to first test-build it
<geser> bzr bd -S
<geser> with commit you commit the changes to your local branch (it doesn't get into LP unless you push it)
<sistpoty> geser: ah, right I slowly recall bzr
<geser> (only with a checkout a commit would go directly to LP)
<sistpoty> heh, I'm still mainly used to central VCSes through work
<sistpoty> geser: ftbfs on amd64: first32.c:1: error: CPU you selected does not support x86-64 instruction set
<geser> if you need to pass any other debuild options to "bzr builddeb" (long for of "bzr bd") pass them after a --, e.g.: bzr bd -S -- -us -uc
<sistpoty> thanks!
<geser> sistpoty: :) you need to build on i386
<geser> it's i386 only in P-a-s
<sistpoty> geser: ah, crap, need to get a proper chroot for that first... give me some time... but anyways I think I know the basics now, thanks a lot! :)
<geser> sistpoty: https://edge.launchpad.net/~geser/+archive/ppa/+sourcepub/962826/+listing-archive-extra
<geser> I had the same problem and used my PPA for a test-build on i386
<geser> the only difference to the merge proposal is the package revision string
<sistpoty> <- doesn't have a ppa, yeah, I'm just oldschool probably *g*
<dupondje> need some help on a merge. I have downloaded newest version from debian sid, added a dpatch in the patch folder, removed a dpatch, did a dch -i with some comments, then did a debuild but then ? how to get it into Lucid ?
<sistpoty> geser: I just want to rebuild it myself... doesn't mean I wouldn't fully trust your merge, but I never upload things I cannot rebuild myself (*with only one exception so far, which gladly was rejected due to a wrong version number)
<geser> dupondje: have you already created a debdiff?
<dupondje> just created a debdiff ... new bugreport and post the debdiff ?
<geser> yes
<lfaraone> Does anybody have time to do a pre-flight-check of groundcontrol? It's an app that does LP nautilus integration, and all the problems that persia found have been fixed. http://revu.ubuntuwire.com/details.py?upid=7663
<geser> sistpoty: let me know when you are done with test-building
<geser> lfaraone: you mustn't edit files from other packages (/etc/xdg/user-dirs.defaults)
#ubuntu-motu 2010-02-13
<dupondje> geser: is there a special command to generate a merge bugreport ?
<geser> dupondje: no
<geser> dupondje: and don't forget to close the bug in your changelog entry. this means: file a bug, insert the bug number into your debian/changelog, create debdiff, attach debdiff to bug
<ryanakca> Could someone please review http://revu.ubuntuwire.com/p/turnin-ng (simple python application, both turnin-ng_1.0.1-0ubuntu1_source.changes and turnin-ng_1.0.1-0ubuntu1_i386.changes are lintian -IivmE --pedantic clean)
<lfaraone> geser: oops, thanks.
<geser> ryanakca: does it only work with python 2.6?
<ryanakca> geser: No, python2.5 as well
<ryanakca> geser: switch to python (>= 2.5) in control and 2.5-2.6 in pyversions ?
<geser> ryanakca: then 2.5- in debian/pyversions would be better (if I remember the syntax correctly)
<ryanakca> geser: Wouldn't that also let 3.x in?
<ScottK> ryanakca: No
<ryanakca> or no, nevermind, pycompat takes care of that
<dupondje> geser: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/521217
<ubottu> Ubuntu bug 521217 in gnucash "Merge gnucash 2.2.9-3 from debian sid" [Undecided,New]
<ScottK> There will be a seperate way to specify Python3 versions.
<ScottK> ryanakca: Also XS-Python-Version is preferred over pyversions.
<ryanakca> ScottK: OK
<dupondje> ah damn, forgot to change maintainer ;)
<geser> ScottK: do you know if we keep python3.0 in the archive for lucid?
<ScottK> geser: I think not.  I think just 3.1.
<ryanakca> ScottK, geser: done
<dupondje> fixed :)
<geser> dupondje: we usually keep the old ubuntu changelog entries during merges (since the last real sync). I didn't check yet the ubuntu delta. did you check if it got merged or needs keeping?
<dupondje> geser: so I need to add old ubuntu changelogs ? I checked the patches, and everything got into sid
<lifeless> dupondje: if everything is in sid, do a sync, not a merge
<dupondje> lifeless: well everything that was in last real sync is now into sid. But I added a new patch for the version in sid
<dupondje> so its a merge ?
<lifeless> EPARSE
<geser> dupondje: sort of, a comment in the bug about your analysis of the ubuntu delta would be good
<geser> lifeless: all old ubuntu delta got into the Debian package -> sync but the package would FTBFS without a new patch
<lifeless> ah
<lifeless> I'd do a sync, let it FTBFS, and then a new ubuntu patch
<geser> dupondje: and don't forget to subscribe the sponsors-team
<sistpoty> geser: all fine as expected, now I can just upload, or do I need to bzr push?
<geser> sistpoty: bzr commit
<sistpoty> geser: already done that
<geser> bzr mark-uploaded
<geser> bzr push lp:ubuntu/mknbi
<geser> and upload the build package
<geser> the push will mark the merge-proposal as merged (else I have to update the status myself)
<geser> lifeless: no sponsor will ACK a sync for a package that will FTBFS (and why waste build time when we know that it will fail?)
<sistpoty> geser: ok, done all that, thanks a lot!
<geser> sistpoty: until we get "BuildFromBranch" into the archive one has to push and upload
<ari-tczew> sistpoty: hi, are you active on IRC if development cycle going to FFe?
<sistpoty> (I must admit that that's the most complicated form I've seen so far to review a *simple* debdiff)
<sistpoty> hi ari-tczew, depends on how much time I can find when at work, but most probably I'll be around (but not too responsive, due to work responsibilities)
<geser> sistpoty: if would have wanted a simple debdiff, I could have provided it
<sistpoty> geser: then I wouldn't have learned the bzr magic ;)
<dupondje> geser: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/521217 => added ubuntu changelogs + more info for the merge
<ubottu> Ubuntu bug 521217 in gnucash "Merge gnucash 2.2.9-3 from debian sid" [Undecided,New]
<sistpoty> geser: I think bzr really comes in handy for more complicated things, and you got me curious to find out ;)
<ari-tczew> geser: wanna sponsor?
<geser> sistpoty: you now know 2/3 of how to do bzr based merges too :)
<geser> ari-tczew: sponsor what?
<lfaraone> How long do I have to get a new-upstream-point-release (which only fixes a "app crashes under very probable conditions" bug) sponsored into the archives? I assume after FinalFreeze that's not an option, but are there any other freezes I should be wary about?
<sistpoty> geser: I assume, but many of my bzr knowledge is lost already, and I must admit that I never even touched a mom-prepared merge (I wanted to redo my changes from scratch... that often lead to recommenting bad changes or kicking out unnecessary changes)
<geser> sistpoty: bzr based merges work fine if the packaging branches are up-to-date (there are still several that fail at the package import level)
<sistpoty> s/bad/underdocumented/
<ari-tczew> geser: sync bug 521220
<ubottu> Launchpad bug 521220 in kadu "Sync kadu 0.6.5.4-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/521220
<sistpoty> geser: I've seen siretart doing a bzr merge once, that impressed me quite a lot (though back then it also seemed a little bit like magic to me)
<lifeless> geser: because a) most packages get built more than once anyway, so its not like its a new thing
<lifeless> geser: and having a smaller more obvious delta against debian helps the next sync/merge cycle.
<geser> in such a case I wouldn't insist on keeping the old ubuntu changelog entries
<geser> bug I still would prefer to do 1 upload instead of a sync and patch later
<dupondje> geser: lifeless: it build if you sync from debian, but it breaks a function, that would need to be patched again then ... better do it in 1 merge then ?
<dupondje> it introduces http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567208
<ubottu> Debian bug 567208 in gnucash "Gnucash 2.2.9-3 has no graphing support" [Serious,Open]
<sistpoty> lifeless: uploading things that FTBFS both add load to the buildds (you *can* work around this by looking at the queue lenght) but it also means that you hinder anyone fixing bugs in a package
<geser> dupondje: a comment in the bug would be IMHO sufficient (so that the reviewer know that you checked it and not dropped the changes because you not yet familiar with merging) but adding it into the changelog entry is also ok
<dupondje> well now its clear anyway :D
<sistpoty> lifeless: the tough thing is to consider if the ubuntu changes are really all included upstream wise. For some packages only the full debdiff can show that, and that's not quite unlikely to drop a change on error. having the full (ubuntu) changelog makes it extremely easier to find a dropped change
<sistpoty> (that sentence was grammatically wrong)
<lifeless> sistpoty: thats what I'm saying, if the analysis has been done to determine 'nothing dropped' then doing a sync records that analysis
<lifeless> otherwise it gets larger and larger and harder to tell
<lifeless> particularly with upstream releases take patches
<sistpoty> lifeless: only that for bigger changes the analysis might be wrong (ok, if a sync is already requested, there's no going back anyways)
<sistpoty> lifeless: just FYI, I've been doing merges by actually rebasing anything against unstable, redoing all ubuntu changes and dropping changelog entries for a very long time
<sistpoty> lifeless: until I was convinced (maybe with a pointy stick) that there is some value to keep old changelog entries ;)
<paissad> it seems that the package is ok now , may someone confirms it ? please
<paissad> http://revu.ubuntuwire.com/p/pms-linux
<dupondje> nite guys
<dupondje> thx for assistance :)
<quentusrex> Anyone able to help debug a package file issue? I have a package that has stopped installing certain files.
<quentusrex> I have the package freeswitch, and freeswitch-lua
<quentusrex> freeswitch-lua depends on freeswitch, and f-lua will install a set of .so's and .la's but it isn't happening any more
<quentusrex> I have extracted the f-lua.deb with dpkg-deb --extract...
<quentusrex> and the files are there
<quentusrex> they jsut aren't ever copied to the location...
<quentusrex> it's driving me insane... I have no idea what could be going wrong...
<quentusrex> lifeless, sistpoty ^
<sistpoty> quentusrex: .la files should generally get removed, let me dig the thread on debian-devel
<quentusrex> generally yes, but not in this case.
<quentusrex> but I am looking at the freeswitch.install file and it has a bunch of .so's that are getting installed
<quentusrex> but the freeswitch-lua.install file has the list of files, but they aren't getting copied.
<quentusrex> I see them in the debian/tmp/ directory when I build the package, and I see them in the debian/freeswitch-lua/... directory as well...
<sistpoty> quentusrex: maybe the thread at http://lists.debian.org/debian-devel/2009/05/msg00441.html gives some clue? (not too sure if there are libtool changes referenced though)
<quentusrex> I think I found something interesting: chroot-autobuild/build/buildd/freeswitch-lua_1.0.4+repack12-0ubuntu16625M.0~karmic_amd64.deb
<quentusrex> that step
<quentusrex> doesn't actually copy files...
<quentusrex> it doesn't copy the .so's like the other steps do
<quentusrex> http://launchpadlibrarian.net/39125363/buildlog_ubuntu-karmic-amd64.freeswitch_1.0.4%2Brepack12-0ubuntu16625M.0~karmic_FULLYBUILT.txt.gz
<quentusrex> you can see if you search for the chroot line in that buildlog
<quentusrex> just above that maybe 100 lines up
<quentusrex> it copies .so's
<quentusrex> but it doesn't for any other package.
<quentusrex> that's my problem.
<quentusrex> sistpoty, do you see what I mean?
<sistpoty> quentusrex: not too sure what you're asking for, but there are plenty of .la-files in freeswitch-dev_1.0.4+repack12-0ubuntu16625M.0~karmic_amd64.deb
<quentusrex> right
<quentusrex> but in freeswitch-lua_1.0.4+repack12-0ubuntu16625M.0~karmic_amd64.deb there are no .so files
<quentusrex> nor in -perl, or -spidermonkey
<quentusrex> etc.
<quentusrex> when there should be atleast a few in each.
<iclebyte> does anyone know the cause of the following error when attempting to compile source using dpkg-buildpackage? "tail: cannot open `debian/changelog' for reading: No such file or directory"
<sistpoty> quentusrex: I'm sorry, but I cannot really help you with ppa-related things. please ask in #launchpad
<sistpoty> iclebyte: there's no debian/changelog?
<iclebyte> no.. I'm attempting to build postfix-2.5.1 sources after applying the VDA quota patch.
<iclebyte> sistpoty, the step's i've taken are here: http://ubuntuforums.org/showthread.php?t=1405550 - it's easier to point you to that than list them all here.
<sistpoty> ScottK: ^^ reproducible with plain postfix as in the archives
 * ScottK looks
<sistpoty> ScottK: do missing build-depends result in that error? (as I don't have all b-d installed)
<sistpoty> ScottK: looks like it, sorry for the noise
<ScottK> Ah.
<sistpoty> iclebyte: you'll need all build-dependencies installed
<sistpoty> iclebyte: hence an apt-get build-dep postfix
<sistpoty> iclebyte: should fix the "problem"
<ScottK> iclebyte: For the record VDA is totally unsupported in Ubuntu or upstream.  The patch was proposed to upstream, but did not meet upstream quality requirements.
<iclebyte> I already did that...
<sistpoty> iclebyte: others than that, if anything else but the *ubuntu source package* doesn't build, I'm sorry, but we cannot really help you here
<ari-tczew> sispoty: can you sponsoring for main?
<sistpoty> ari-tczew: yes
<ari-tczew> cool!
<sistpoty> ari-tczew: as in got a but number?
<sistpoty> s/but/bug/
<ari-tczew> sistpoty: not now, generally I'm going to do a debdiff for some fake syncs
<iclebyte> okay, i've just deleted my patched version of the source and extracted the postfix_2.5.1.orig.tar.gz which was downloaded by executing 'apt-get source postfix'. I entered that directory and executed dpkg-buildsource and get the same error. Is this what you would expect or should it build?
<iclebyte> there's also a postfix_2.5.1-2ubuntu1.2.diff.gz archive thats been downloaded with it too but i've done nothing with that manually
<sistpoty> ari-tczew: ok
<sistpoty> iclebyte: did you do an apt-get build-dep postfix?
<iclebyte> i did both.
<sistpoty> iclebyte: what version of Ubuntu are you running?
<iclebyte> 8.04-LTS the server one.
<sistpoty> iclebyte: let me try to reproduce the problem (takes some time, I'll need to create an 8.04 chroot first)
<iclebyte> sistpoty, thanks very much!
 * iclebyte might make a cup of tea and hang around a bit =)
<iclebyte> sistpoty, I've fixed it!
<iclebyte> because I've messed about with the source so many times, I've been extracting the postfix-orig tar manually, I removed everything and downloaded it again and apt-get source postfix applies the ubuntu diff which must stick the debian/ directory into the postfix source. now it builds.
<iclebyte> (that's my assumption as to how it works anyway)
<sistpoty> iclebyte: great
<iclebyte> thankyou for your help though, it is much appreciated
<sistpoty> hyperair: meh, I think I screwed bug #512358. I should have left it at confirmed but unsubscribed ubuntu-main-sponsors (which I cannot do) ;(
<ubottu> Launchpad bug 512358 in e2fsprogs "FTBFS: missing html files" [Undecided,New] https://launchpad.net/bugs/512358
 * sistpoty heads to bed now, gn8 everyon
<sistpoty> +e
<paissad> i see my package now in the site, but is it in the right place in order to get advocated ?
<paissad> http://revu.ubuntuwire.com/p/pms-linux
<paissad> is there something else to do ?
<wrapster> I want to build a pkg so I un-tarred the source put it into a dir called <my-deb-pkg-version1> then entered that dir and did a  dh_make
<wrapster> but it fails saying.. cannot understand the dir name
<lfaraone> My package needs to modify /etc/xdg/user-dirs.defaults to add a PROJECTS stanza. As this isn't allowed by policy, would it be a good idea to modify the xdg-user-dirs package itself to have that by default, and if so, who should I ask about that?
<doctormo> We're looking for advice on bug 521263 can anyone lend a hand?
<ubottu> Launchpad bug 521263 in groundcontrol "GC postinst should not modify configuration files owned by other packages" [Undecided,New] https://launchpad.net/bugs/521263
<superm1> <3> is the most favorable solution
<superm1> although you'll probably want to raise that with the freedesktop folks first
<lfaraone> doctormo: see DPM Â§10.7.4: http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4
<lfaraone> superm1: which would be doable in time for FF? :)
<superm1> lfaraone, well lob an email over to their mailing list and see how they feel about adding another directory to the spec
<superm1> they wont have a new release in time probably, but if they agree to it, nothing is to stop you from backporting such a thing
<superm1> which should be achievable in time for FF
<superm1> and if not, I don't see why an FFe couldn't be done for something like this
<lfaraone> superm1: well, groundcontrol isn't in Ubuntu yet.
<superm1> lfaraone, that's okay.
<superm1> lfaraone, the other thing i'd propose is maybe just choosing one of the existing xdg directories and making a subdirectory
<lfaraone> doctormo: is that an acceptable alternative?
<superm1> like $DOCUMENTS/Projects perhaps
<lfaraone> doctormo: (assuming XDG says "no")
<doctormo> lfaraone: The alternative is that we pull out of XDG and disable ground control, letting people edit their own configs and own directories, making it really hard to install and a pointless endevour
<lfaraone> doctormo: I mean, can't we have some better functionality to control whether groundcontrol is enabled or not than XDG settings? :)
<doctormo> You mean, display the projects banner on every nautilus folder
<lfaraone> doctormo: no, default to something like $DOCUMENTS/Projects, and let it be configurable via say .config/groundcontrol/blah.ini
<doctormo> bleh, configs for directories, it's like they want to make this hard
<doctormo> What would create that folder
<doctormo> Why would that be default
<doctormo> That's not even how I organise my projects
<doctormo> projects aren't documents
<lfaraone> doctormo: you're right. we could just ignore the XDG spec entirely and write to $HOME/Projects.
<kklimonda> anyone who has a good understanding of the new source format online? and new bzr workflow too.. I'm trying to merge (or rather rebase) ubuntu transmission on the current unstable package and have some problems
<kklimonda> there is debian/patches/.dpkg-source-applied and patches are indeed aplied but there is no .pc nowhere to be found in the branch - is it normal?
<doctormo> lfaraone: The cheese program creates a directory every time it runs, it's really annoying
<doctormo> and for many months I never knew why
<doctormo> It turns out it was because the XDG video directory pointed to my home folder
<doctormo> And it would magically make a directory Webcam every load
<doctormo> That's also a really bad idea
<doctormo> I don't actually mind using ~/Projects/lp/ instead of just ~/Projects, but it makes me very uncomfortable to ignore XDG when it's such a good spec, it just needs more flexibility.
<maitraya> I am a high school student. What are the qualifications I require to be a MOTU member?
<maitraya> [12:29] <maitraya> I am a high school student. What are the qualifications I require to be a MOTU member? Please help
<kklimonda> ma10, https://wiki.ubuntu.com/MOTU#So%20you%20want%20to%20be%20a%20MOTU?
<kklimonda> ai
<kklimonda> maitraya, https://wiki.ubuntu.com/MOTU#So%20you%20want%20to%20be%20a%20MOTU?
<maitraya> thanks
<fabrice_sp> maitraya, also see the topic (https://wiki.ubuntu.com/MOTU/Contributing)
<ari-tczew> would be nice if everybody will update its merges before FFe !
<hyperair> 'its merges' <-- referring to what?
<ari-tczew> e.g. if you did 3 merges and now these merges are not updated, would be nice if you'll update these merges before FFe
<hyperair> what do you mean by "not updated"?
<hyperair> as in not uploaded yet?
<hyperair> or there are new merges to be done?
<hyperair> or what?
<ari-tczew> new merges
<ari-tczew> of course
<hyperair> ah
<dupondje> I uploaded one, waiting to be accepted :P
<hyperair> quadrispro: regarding codelite, are you interested in taking over maintainership of it?
<hyperair> quadrispro: i noticed you uploaded a new upstream release of codelite recently.
<quadrispro> hi hyperair! yep, that release fixes a lot of issues
<hyperair> quadrispro: cool. in that case, could you keep the git packaging repository up to date, or move the packaging elsewhere?
<quadrispro> hyperair, ah! you're right
<quadrispro> no, I'll update the git repo
<hyperair> i've already updated it on your behalf =)
<quadrispro> I didn't notice it before
<hyperair> =)
<quadrispro> excellent :)
<hyperair> anyway, i'd have preferred if you had notified me before doing the upload. i began working on it on early this morning, only to realize that it was already done after my initial checks. (my uscan cronjob runs weekly on fridays)
<ari-tczew> is it available to do a merge past FFe?
<hyperair> quadrispro: you might also like trying to get codelite into debian, if you know someone who would upload it.
<asbin> Hi ! If anybody has time, please have a look at enna package on revu (http://revu.ubuntuwire.com/details.py?upid=7713). It's a new cool Media Center  :) Thank you !
<geser> ari-tczew: yes, after FF you can do merges too, you just might need a FF exception when merging a new upstream version
<ari-tczew> geser: but if there are not new upstream version, just new release Debian version: do I should give a FFe reason?
<geser> no, but think if we need those changes before merging
<gusnan> Could someone please take a look at my package sciteproj - an project handler for SciTE - upstream http://sciteproj.sf.net, revu at http://revu.ubuntuwire.com/p/sciteproj . Thanks.
<quadrispro> hyperair, ok
<paissad> guys, my package does no appear in new packages ! ... in the http://revu.ubuntuwire.com/ site ... the package is pms-linux ^^
<ari-tczew> why people uploading new packages to REVU instead Debian Mentors?
<paissad> oh
<geser> they still have hope to get the package faster through REVU than Debian mentors
<paissad> btw, the package does appear in http://revu.ubuntuwire.com/?archived=true, but is it enough ?
<jpds> paissad: Unarchived.
<paissad> jpds, i should unarchive it ? .... that's what you mean ?
<jpds> paissad: No; that's what I've done and it's now on the front page.
<paissad> oh ok thx then :)
<oojah> Could someone take a few minutes to review http://revu.ubuntuwire.com/details.py?upid=7680 please?
<ari-tczew> bdrung: ping
<bdrung> ari-tczew: pong
<ari-tczew> bdrung: is there a different process between fake sync universe and fake sync main?
<bdrung> no, there shouldn't
<ari-tczew> bdrung: so you can't doing fake sync
<ari-tczew> bdrung: look @ bug 517297
<bdrung> why?
<ubottu> Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Fix released] https://launchpad.net/bugs/517297
<bdrung> ari-tczew: thinking about it, the ubuntu diff is better.
<ari-tczew> bdrung: look too @ http://pastebin.com/d32050806
<ari-tczew> bdrung: so, do you will review again my debdiff in bug 521337 ?
<ubottu> Launchpad bug 521337 in pyclamd "Fake sync python-pyclamd 0.1.1-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/521337
<bdrung> ari-tczew: yes, will do your fakesync
<ari-tczew> bdrung: thanks :-)
<bdrung> ari-tczew: i will drop the 0.1.1-0ubuntu1 changelog entry
<ari-tczew> bdrung: hmmm, main sponsors didn't drop ubuntu's changelog ;->
<bdrung> ari-tczew: let's see if i can find a common practice for it
<ari-tczew> bdrung: have debian/changelog structure like in merges,  I guess
<bdrung> ari-tczew: a real sync would drop the ubuntu changes, too.
<ari-tczew> bdrung: heh, dispute quesion
<ari-tczew> maybe other MOTU give opinion
<ari-tczew> would be nice to have a page on wiki.ubuntu.com about fake syncs
<bdrung> ari-tczew: seconded. found this: https://wiki.ubuntu.com/PackagingGuide/Wishlist?highlight=%28fakesync%29
<bdrung> but nothing useful
<ari-tczew> bdrung: sure, need to correct HowTo
<ari-tczew> ping: Kmos
<bdrung> ari-tczew: maybe i should improve my fakesync script and promote it into ubuntu-dev-tools
<ari-tczew> bdrung: can you show me code of this script?
<bdrung> yes
<bdrung> ari-tczew: http://paste.debian.net/59720/
<bdrung> ari-tczew: it works on bug reports
<ari-tczew> brung: is your script updated to method which we are explained today on IRC?
<ari-tczew> s/brung/bdrung
<bdrung> ari-tczew: it drops the ubuntu changes. what it does: it grabs the information from the bug, downloads debians and ubuntus version, extract debians package, replace the orig.tar from debians by ubuntus, add a changelog entry, builds the package, uploads it
<ari-tczew> bdrung: "it grabs the information from the bug" for what?
<bdrung> ari-tczew: package name, version, bug number (for changelog)
<bdrung> ari-tczew: it's for the sponsoring
<ari-tczew> bdrung: I'll test your script
<bdrung> ari-tczew: you have to tweak it (because it assumes that you can upload the package)
<bdrung> ari-tczew: it's quick & dirty
<ari-tczew> bdrung: remove line 149-211 ?
<bdrung> ari-tczew: 139 - 156
<ari-tczew> bdrung: where is the debdiff?
<bdrung> /tmp/fakesync
<bdrung> ari-tczew: it creates the debian -> ubuntu diff
<ari-tczew> bdrung: still not useful
<bdrung> ari-tczew: you can tweak it
<ari-tczew> bdrung: the bug is in debian/changelog management, right?
<bdrung> ari-tczew: yes, if you call it a bug
<ari-tczew> s/bug/issue
<^arky^> Hi, Can any MOTU look at a11y bug 510182 please?
<ubottu> Launchpad bug 510182 in espeak "New upstream version available" [Undecided,New] https://launchpad.net/bugs/510182
<paissad> may i talk about ppa launchpad ? ... i want to make my package temporary available waiting for it to be advocated, but i don't know how to upload the .deb file
<paissad> http://ppa.launchpad.net/paissad/pms-linux/ubuntu/pool/main/p/pms-linux/
<paissad> i just have the sourc
<paissad> source*
<azeem> the binaries get auto-compiled I thought?
<azeem> it might take a while
<paissad> azeem, so, i have to wait ?
<paissad> it not my duty ?
<paissad> it's*
<ari-tczew> ^arky^: could you give a link to source tarball?
<ari-tczew> ^arky^: ok, founded in bug
<^arky^> ari-tczew: http://espeak.sourceforge.net/test/latest.html
<ari-tczew> bdrung: hmmm, I think that we need to improve in script merging debian/changelog. do you have any other ideas?
<^arky^> ari-tczew: can you please let me know how you can package this newer version as well
<bdrung> ari-tczew: rewrite from scratch ;)
<ari-tczew> ^arky^: the easiest way is get latest tarball and adjust debian/ directory
<ari-tczew> bdrung: scratch is merging 2 files?
<^arky^> ari-tczew: thank you
<bdrung> ari-tczew: yes, we need a merge for debian/changelog
<ari-tczew> bdrung: can you tweak script?
<bdrung> ari-tczew: currently i have not the time for it.
<ari-tczew> bdrung: I can't code in python, how can we merge 2 files?
<bdrung> ari-tczew: dunno. you have to call other programs (diff + patch?).
<ari-tczew> bdrung: ok, I'm going to do other fake syncs manually, no waste time for noob-scripting. Benjamin, do you will work on bug 511448 or can I done this?
<ubottu> Launchpad bug 511448 in libxml-security-java "Fake sync libxml-security-java 1.4.3-2 (main) from Debian testing (main)" [Undecided,Triaged] https://launchpad.net/bugs/511448
<bdrung> ari-tczew: you can take this
<ryanakca> Could someone please review / sponsor http://revu.ubuntuwire.com/p/turnin-ng (simple python application, both turnin-ng_1.0.1-0ubuntu1_source.changes and turnin-ng_1.0.1-0ubuntu1_i386.changes are lintian -IivmE --pedantic clean)
<paissad> is there some team interested in ps3/xbox, etc... in Debian/Ubuntu ?
<ari-tczew> can someone sponsor take a look @ bug 521312, I'm not sure whether requestsync correct recognized component (main/universe)
<ubottu> Launchpad bug 521312 in geronimo-j2ee-connector-1.5-spec "Sync geronimo-j2ee-connector-1.5-spec 2.0.0-1 (main) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/521312
<geser> ari-tczew: requestsync got the component right, it got promoted during karmic to main (after the last upload)
<paissad> which of theses 2 version is newer ? ... 1.20+svn386-1 and 1.20.392-1
<paissad> i expected 1.20.392-1 to be newer
<ari-tczew> +1 1.20.392
<BlackZ> paissad, 1.20.392-1
<paissad> i've 1st built my package arch dependent ... so i get amd64.deb & i386.deb .... but now i 've built it for all arch, i obtained all.deb .... and i put i in my personal repository, but the matter is that apt-cache policy does not see the new package ( all.deb) ... is it because i installed 1st i386.deb package ?
<paissad> how users can update their package then ?
<persia> paissad: You probably need to fiddle with the Packages and Release files in your personal repository.  I don't know of any good channel to get support for that.
<persia> paissad: Also, you may find `dpkg --compare-versions ...` to be a very useful command.
<paissad> ok
<ari-tczew> bdrung: why you didn't include update-maintainer changes?
<ari-tczew> in fake syncs
<ari-tczew> dholbach explain, that this is needed
<bdrung> ari-tczew: then i have to talk to him
<persia> The reason we do update-maintainer for fakesyncs is that because the tarballs differ, we can't know that a bug isn't caused by something there.
<geser> fake-syncs are usually uploaded as -XbuildY and don't need a maintainer change
<persia> geser: That would be bad, because it causes a sync failure, and ends up with archive admins either having to fiddle, or update the blacklist.
<persia> fakesyncs should *really* get an ubnutu version and use update-maintainer.
<geser> when did this change?
<persia> I didn't think it had.
<bdrung> we have 5 people and 6 opinions. we need a wiki page for fake syncs
<geser> persia: see e.g. bug #366812 or http://changelogs.ubuntu.com/changelogs/pool/universe/p/postgresql-8.0/postgresql-8.0_8.0.7-2build1/changelog for the usage of -XbuildY (I could google for some more if needed)
<ubottu> Launchpad bug 366812 in nautilus-image-converter "Fake-sync nautilus-image-converter from debian experimental" [Wishlist,Fix released] https://launchpad.net/bugs/366812
<persia> geser: I suspect there are many examples.  I just think they are all wrong.
<geser> then we should get it documented somewhere properly (and let all devs know about it)
<persia> Makes sense.
<bdrung> geser: my words
 * persia does a full-text search on the wiki for fakesync
<bdrung> persia: there is nothing
<persia> bdrung: in a full-text search?  Should be at least something.
<persia> Titile-search, I agree.
<bdrung> persia: some results are there, but no description how a fake sync should be done.
<bdrung> titile ;)
<persia> bdrung: Understood.  I'm planning to put up a recipe, but just want to make sure I've gotten some good hints first.
<persia> https://wiki.ubuntu.com/PackagingGuide/Wishlist is a good hit, for example :)
<persia> (not that I agree with that description)
<persia> But https://wiki.ubuntu.com/FoundationsTeam/Meetings/2008/1119 seems to indicate that we have competing meanings of "fakesync" :(
<persia> So, before I document anything: let's agree on terminology.  I assert that a "fakesync" is when we apply Debian packaging to an Ubuntu tarball.  I'd like suggestions on a term for when we "sync" from Debian VCS (I would have thought it just a regular Ubuntu upload)
<geser> for me fake-sync is: Ubuntu .orig.tar.gz + Debian .diff.gz
<persia> Excellent.  So do we need a term for the other class mentioned in that foundations meeting?
<ari-tczew> geser: Ubuntu tarball + Debian .diff.gz + dch -i (fake sync due to mismatching tarball)
<persia> ari-tczew: right, and (depending on the results of this discussion) potentially a maintainer change.
<persia> ari-tczew: But that's too small a chance to matter.
<bdrung> persia: it depends on the used version. ubuntu1 needs update-maintainer, build1 not
<ari-tczew> persia, geser, bdrung: http://pastebin.com/d32050806
<persia> bdrung: Why?
<ari-tczew> look @ line 22.
<bdrung> persia: with ubuntu1 "debuild -S" will fail in most cases
<persia> ari-tczew: You cite someone else's opinion, which may be useful, but please argue your own case.
<persia> bdrung: I think that's a tools issue.
<persia> https://wiki.ubuntu.com/DebianMaintainerField says "If a source package is modified relative to Debian (this can be determined automatically by examining the version number), its Maintainer field should be updated either as above, or with a more appropriate Ubuntu contact if one exists"
<persia> I read that to require use of update-maintainer for all changes of any sort.
<geser> is it a change if we use a different .orig.tar.gz which is identical content-wise (diff is emtpy) but not bit-identical?
<persia> geser: I'd say no, but I'd say that adding a changelog entry makes it no longer bit-identical.
<bdrung> in case of doubt we should change the maintainer field
<geser> with the same logic we should also version no-change rebuilds -XubuntuY instead of -XbuildY
<persia> Why?
<geser> because we add a changelog entry for the rebuild?
<persia> I agrue that -XbuildY vs. -XubuntuY is *entirely* a way we can provide hints as to whether to autosync next time, and should have nothing to do with the Maintainer field.
<persia> Hrm.
<persia> If I stand on policy, I'll argue that rebuilds should also get a maintainer change, but that just adds noise to the patch.  I'm not sure this policy wouldn't benefit from deeper review.
<bdrung> looking at https://wiki.ubuntu.com/DebianMaintainerField we have to update the maintainer for rebuilds too
<persia> That's my interpretation as well.
<geser> the binary debs get always the Maintainer field overwritten
<persia> Right.
<persia> The question is just about how we deal with source changes.
<persia> (or rather, what level of source change constitutes a "change")
 * persia is getting the sinking feeling that this may end up being something to present to the TB for review/discussion
<bdrung> persia: respecting the vote, my opinion is that every change (including changelog modification) is a change
<geser> IMHO only a changelog entry shouldn't count as "change" as we don't have any other option for e.g. no-change rebuilds
 * persia can see the strengths of both of those arguments, and doesn't have a strong opinion between them
<bdrung> let the TB decide
<persia> bdrung: Are you up for taking this to the TB for clarification?
<bdrung> persia: i would prefer if someone else can do it
<persia> heh.
 * persia has some outstanding actions for the TB and would prefer not to bring new issues until those are resolved
 * bdrung has one outstanding action for the TB, too.
<persia> geser: ari-tczew : either of you have a sufficient absence of overhanging guilt ?
<persia> OK.  Fine, let's set this part aside for now, until we get a volunteer.
<persia> So, a changelog-only change may or may not require update-maintainer.
<persia> Next: what revision should we use for fakesyncs?
<bdrung> persia: ubuntu1 will definitively require update-maintainer for not-@ubuntu.com maintainer.
<persia> bdrung: But again, that might be a bug in the tools.
<bdrung> persia: ubuntu1 indicates a ubuntu change. so i won't call it a bug.
<persia> bdrung: And build1 doesn't indicate an Ubuntu change?
<bdrung> persia: indicates a no-source-change only-adding-a-changelog-entry build
<persia> But is this a change?  You argued it was before.
<ari-tczew> persia: +1 for buildX => debian/{changelog;control}
<bdrung> persia: do we have a rebuild policy?
<persia> Not a formal one, to my understanding.
<bdrung> persia: i change my reasoning: buildX indicated that we can sync from Debian
<persia> That's been my interpretation.
<persia> geser: What do you think?
<geser> mine too
<persia> Excellent.
<geser> and don't the archive admin scripts handle -XbuildY that way (auto-sync)?
<persia> As far as I know,they do.  I know MoM does.
<persia> So, the only bit left is what to do with differing orig.tar.gz files.  Since these can't sync, I argue that -XbuildY is incorrect.
<persia> (or may not be able to sync: we don't know the version of the next Debian upload)
<kamalmostafa> I'm looking for someone with an "Intel(R) Core(TM)2 Duo CPU P9500" to try the 10-line program in bug 518314 -- I cannot reproduce the reported problem on a similar Core2 Quad.  (Or a redirect to a more appropriate channel to ask).
<ubottu> Launchpad bug 518314 in eglibc "strcmp crashes" [Undecided,New] https://launchpad.net/bugs/518314
<ari-tczew> persia: why -XbuildY is incorrect?
<persia> ari-tczew: My contention is that if we use -XbuildY to indicate that it is safe to sync the package in the future, we cannot use it for fakesyncs because if there is not a new upstream version, we will not be able to sync in the future.
<geser> persia: so you propose to use something like -XfakesyncY for fakesyncs?
<sebner> geser: we used ubuntu1 for fakesycns why not keep it?
<geser> to not overload the meaning of -XubuntuY
<ari-tczew> no, ubuntu1 sucks for fakesyncs. If we have XbuildY, Debian will get new upstream version, then autosync will replace ubuntu's version with Debian's
<geser> sebner: I use -XbuildY for fakesyncs and there doesn't seem to be a clear document what to use
<persia> ari-tczew: That fails if Debian uploads bugfixes that aren't new upsteams.
<geser> therefore a new suffix
<ari-tczew> persia: XubuntuY too fails, right?
<persia> geser: That's one solution.  Do you think it's that important to preserve the distinction between fakesyncs and other sorts of Ubuntu modifications?
<geser> -XbuildY for no-change rebuilds that can be synced on the next Debian revision
<persia> ari-tczew: Only in a semantic sense.
<sebner> geser: I always wanted to use XbuildY too but when the next version in Debian isn't new upstream the sync fails so I'm only using XubuntuY
<geser> -XfakesyncY for fakesync that can be auto-synced on the next upstream version in Debian
<geser> and -XubuntuY for changes that might need merging
<sebner> geser: well, you never know if the next version in Debian will be new upstream or not
<persia> geser: See, one of the reasons I prefer -XubuntuY for fakesyncs is that we *do* need to process them like merges for new Debian revisions.
 * sebner agrees with persia 
<l3on> \sh: thanks for uploading ikiwiki. :)
<geser> persia: even when we know that there are no changes (besides the different md5sum)?
<persia> geser: Yes, because the merge workflow is nearly identical (although the patch is much smaller)
<ari-tczew> +1 for still XbuildY or +1 for geser idea
<persia> ari-tczew: -XbuildY completely fails to work.
<ari-tczew> ubuntuY too
<persia> ari-tczew: Why?
<sebner> It's always the question if your prefer autosync but the possibility to fail OR to not autosync and keep tracking on new upstream versions yourself
<ari-tczew> if autosync see ubuntu, then giving free to merge
<ari-tczew> right?
<persia> autosync fail annoys archive admins.  I've had to clear more than one package off the blacklist manually to work around it.
<persia> ari-tczew: Yes, -XubuntuY provides notification of merge.
<geser> persia: do you know why this problem wasn't raised earlier? fakesyncs and using -XbuildY for them is nothing new
<geser> I'd prefer a solution where we don't have to check fakesyncs manually and let the tools sync them on new upstream versions
<persia> geser: Hrm.  I don't.  I like the idea of providing enough of a hint that the tools can autosync if appropriate or merge if inappropriate.
<persia> And -Xfakesync << -XubuntuY which covers that case.  I don't think we need a "Y" component for fakesyncs (or they shouldn't be -Xfakesync anymore)
<geser> persia: perhaps I was a little bit unspecfic: I see now that -XbuildY isn't the right option and -XubuntuY works but doesn't look like the best option either, so a new suffix should be added to handle fakesyncs
<geser> and right, we should have to fakesync more than once for each X (unless the DD doesn't use a weird revision scheme)
<persia> Right.
<ari-tczew> away...
<persia> So, let me make sure I've got the right notes from the discussion:
<persia> 1) We don't know if we need update-maintainer for changelog-only fixes
<geser> correct
<persia> 2) We want to restrict -XbuildY uploads to rebuilds only: not fakesyncs
<persia> 3) fakesyncs should use the new -Xfakesync revision
<geser> correct
<persia> 4) the tools should be updated to deal with this sanely
<geser> correct
<persia> Excellent.
<persia> bdrung: That works for you?
<bdrung> persia: yes.
 * persia will send a mail to ubuntu-devel
<bdrung> with Xfakesync the sync tool can automate the syncing (by checking if there is a new upstream release)
<persia> Right, assuming someone updates the tools.  Needs patches to MoM and the archive-admin tools.
<bdrung> persia: one thing. keeping the ubuntu changelog entries or not?
<geser> for fake-syncs? no, we only added them because we can't bump the version otherwise
<persia> That's a tricky one.  The argument for keeping them is that it describes the history and rationale of having different orig.tar.gz files.  The argument against is that it increases the differences in cases that are essentially syncs.
<geser> the history is still in LP
<persia> Good pont.
<bdrung> +1 for dropping them
<persia> I'll suggest drop-old-ubuntu-changelog in the mail.
<geser> and we don't keep the ubuntu changelog entries for sync too (else we would have to merge everytime the old ubuntu changelog entries for every package we touched once)
<bdrung> geser: once the policy is finished, we can write a fakesync tool
<persia> bdrung: Feel free to start one now, based on our discussion.  The patches for any variance from ML discussion (or TB intervention) is likely to be small.
<rmunn> Anyone interested in looking at http://revu.ubuntuwire.com/p/python-nltk? One MOTU has already advocated it, just need a second advocate to get it into Lucid.
<rmunn> Two things that have already been discussed by other reviewers:
<bdrung> rmunn: "Initial release (Closes LP: #514396)" <-- wrong bug number and remove Closes
<rmunn> 1) the nltk.jar file contains nothing but code whose source is in the upstream tarball, and there are no licensing problems with redistributing it in the .orig.tar.gz. (And it's deleted in debian/clean so that it can't get into the binary package, thus avoiding any security issues of possible Trojans)
<persia> rmunn: You may want to put #1 in debian/README.source so you don't have to repeat it so often :)
<bdrung> rmunn: do you want to bring the package to Debian too?
<rmunn> bdrung, Huh. I'm certain that was the right bug number when I created it... Weird.
<rmunn> bdrung, Yes, but I'm not 100% sure of the Debian package-submission process... still reading policy documents, etc.
<bdrung> rmunn: https://bugs.launchpad.net/openerp-venezuela-localization/+bug/514396 looks wrong ;)
<ubottu> Ubuntu bug 514396 in openerp-venezuela-localization "Correcciones en Reporte de retencione ISLR para cumplir con las especificaciones legales venezolanas." [Critical,Fix released]
<rmunn> Oh, it's bug #514936. Oops, typo.
<ubottu> Launchpad bug 514936 in ubuntu "[needs-packaging] nltk (Natural Language Toolkit)" [Wishlist,In progress] https://launchpad.net/bugs/514936
<bdrung> rmunn: first things is to check WNPP and open an ITP
<rmunn> Drat, that means a new upload and getting sistpoty to re-advocate the package.
<rmunn> bdrung, The nltk.jar info already is in README.Debian. :-)
<persia> It doesn't belong in README.Debian, because it's uninteresting to end-users, but that's a very minor nit.
<persia> no need for a new upload, but if there *is* a new upload, fixing that would be nice :)
<Rhonda> persia: Am uploading the pgadmin3 package, so aftger next dinstall I guess you can do the snc.
<Rhonda> persia: And forgive me my typing as the upload is happening right now, I can't type over the lag properly. ;)
<rmunn> persia, No need for a new upload re: the README.Debian? Or re: the wrong bug number? I think the wrong bug number does require a new upload.
<bdrung> rmunn: python-nltk source: unused-override build-depends-without-arch-dep python-yaml
<Rhonda> Or at least fixing the typos isn't working out over the lag.
<rmunn> bdrung, Already looked at that one & discussed here in #ubuntu-motu a few days ago. It's a false positive.
<persia> Rhonda: No worries :)
<rmunn> python-yaml is required for the debian/clean step, so per Debian policy it should be in build-depends, but lintian complains.
<bdrung> rmunn: don't override false positive. instead open a bug report. in your case this bug was fixed in the latest version.
<persia> rmunn: wrong bug number would benefit from an upload.  Moving discussion of licensing of the .jar file from README.Debian to README.source would be good, but not essential.
<rmunn> persia, Ah, README.source is where it belongs? Then since I have to do a new upload anyway to get the right bug number, I'll move it.
<bdrung> rmunn: python-nltk source: out-of-date-standards-version 3.8.3 (current is 3.8.4)
<bdrung> rmunn: please refer to version copyright file
<rmunn> I thought 3.8.3 was current when I made the package two weeks ago... Ah, I see, 3.8.4 JUST came out.
<persia> rmunn: README.Debian should include end-user-interesting information specific to how the upstream source has been packaged, if this changes defaults, etc.  README.source should contain developer-interesting information about how the packaging works.
 * persia looks about for fabricesp and is disappointed
<rmunn> bdrung, What do you mean by "please refer to version copyright file"? I don't understand.
<rmunn> This is my first "real" package (as opposed to training exercises), so all this feedback is GREATLY appreciated, BTW. :-)
<bdrung> rmunn: debian/copyright: /usr/share/common-licenses/GPL -> /usr/share/common-licenses/GPL-2 (lintian tag copyright-refers-to-symlink-license)
<rmunn> bdrung, Understood, thanks.
<bdrung> rmunn: 1. two recommendations: use DEP-3 for the patch 2. use 3.0 (quilt) source format
<bdrung> (why not use the latest packaging tools for new packages?)
 * persia notes that due to an outdated dpkg bug in Ubuntu, not all 3.0 (quilt) sources are currently uploadable.
<rmunn> bdrung, I created the package on Karmic, haven't moved my main work computer to Lucid yet. Now that I'm getting more experience with packaging, I'll probably start creating packages on a Lucid VM.
<persia> (which fixing requires not only an update of dpkg, but also some work to integrate that update into Soyuz)
<bdrung> persia: really? i had no problems so far
<bdrung> rmunn: you can build the 3.0 (quilt) package on karmic, too
<persia> bdrung: It depends on the package.  Basically, the dpkg in Ubuntu currently has (slightly) different behaviour depending on whether quilt is installed or not, which only catches some packages.
<rmunn> And I'm not familiar with the deb 3.0 packaging system yet -- any documents I can read about the changes?
<bdrung> rmunn: http://wiki.debian.org/Projects/DebSrc3.0
<rmunn> bdrung, Thanks.
<bdrung> persia: aha, that thing. building will fail only if the patches do not apply clean (apply with fuzz)
<bdrung> that's easy to fix
<bdrung> by just refreshing the patches
<ari-tczew> persia, bdrung, geser: but now I should make fake syncs based on current method XbuildY right?
<bdrung> rmunn: for what is the comment in line 10 in debian/rules?
<bdrung> ari-tczew: i am unsure
<rmunn> That was created by "dh_make --cdbs" and I never removed it, since I figured if I did need overrides it would remind me to put them after the includes rather than before.
<persia> ari-tczew: We all agreed you should use "-Xfakesync", but most developers have never heard of that before, so you may not want to try it yet :)
<rmunn> bdrung, That comment was directed at you, BTW.
<persia> ari-tczew: -XbuildY is definitely broken.  -XubuntuY is potentially inconvenient.  You decide, and your sponsor will review.
<bdrung> rmunn: drop it
<rmunn> Working on all these changes now, will upload to http://revu.ubuntuwire.com/p/python-nltk once I'm done. Thanks, bdrung and persia.
<ari-tczew> can someone sponsor fake sync? bug 521411
<ubottu> Launchpad bug 521411 in pyelemental "Fake sync pyelemental 1.2.0-2 (universe) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/521411
<bdrung> ari-tczew: not with 1.2.0-2build1 :P
<ari-tczew> bdrung: XfakesyncY is not oficial demand (yet)
<bdrung> persia: how should we call the version when we rebuild a fakesync?
<ari-tczew> note: rebuild is only add new revision into debian/changelog
<bdrung> ari-tczew: yes, but which version string would you use?
<geser> bdrung, persia: I'd say -Xfakesync(Y+1), so we need a counter after the fakesync
<bdrung> geser: yes, that was my thought, too
<ari-tczew> so what's next?
<ryanakca> persia: Did you spot anything else in turnin-ng or could you advocate it please? (I'm hoping to get it into Lucid)
<persia> bdrung: Bother.  We needed to think about that *before* the mail :)
<persia> I don't like -XfakesyncY
<persia> Maybe -Xalmostsync?
<ari-tczew> persia: please, don't going to be crazy ;-D
<geser> persia: -XfakesyncbuildY :)
<persia> Actually, -XfakesyncY is growing on me, because the same sync/merge semantics apply for them as for the first fakesync.
<ari-tczew> persia: so please just use old and NOT _deprecated_ XbuildY
<persia> geser: No, I think I like your original suggestion (but please send mail), because we don't want to confuse the tools if we write them.
<bdrung> persia: -Xsomeidiottookthewrongtarball :D
<persia> bdrung: :)
<ari-tczew> and peace
<persia> ari-tczew: -XbuildY doesn't need to be deprecated.  It's just wrong.
<persia> ari-tczew: If you don't want to wait, use -XubuntuY
<ari-tczew> persia: FFe is coming soon, I want to upload fake syncs this weekend
<bdrung> persia, geser: here is my fakesync tool: http://paste.debian.net/59755/ (it works on sync request bugs)
<ari-tczew> wrrrrrr
<persia> bdrung: That was fast!  Looks reasonable to me (but my python is lousy)
<ari-tczew> okay, here is my propose: we should use new policy about fakesync, but start with next development cycle, okay?
<persia> bdrung: Actually, one change: task.transitiontoAssignee(assignee=None) should be changed to reference the person processing the fakesync.
<bdrung> persia: i wrote the script some time ago. i just updated it today.
<bdrung> persia: why? we upload the patch directly and it will get closed.
<persia> ari-tczew: Why link the policy change to development cycles?
<ari-tczew> persia: because now 5 days remaining to FFe and no sense change fakesync policy
<persia> bdrung: Because launchpad.me is working on it, in case someone else tries to do something at a similar time?
<persia> ari-tczew: I don't see how the timing matters at all.
<persia> ari-tczew: fakesyncs sometimes happen days before release, for things like RCbugs processing.
<ari-tczew> and new policy is not confirmed by any admins
<persia> There are no admins to confirm it.
<persia> Or if you want to consider those who admin the developer membership, geser and I would be (an unquorate) subset of them.
<ari-tczew> by admins I mean about person like dholbach, ScottK or sistpoty
<bdrung> ari-tczew: dholbach?
<ari-tczew> bdrung: why are you suprised?
<bdrung> ari-tczew: what kind of admin?
<persia> ari-tczew: Why those specific people?  I respect them all, but the first is on CC and the (not-currently-functional) MC, but not otherwise empowered, and the latter two are on the release team (or should be once the release team mess gets sorted).
<bdrung> do you thought about
<ari-tczew> omfg
<ari-tczew> men's decision: what's revision for fakesync?
<ari-tczew> oficial
<persia> ari-tczew: -XubuntuY, as I've told you several times.
<geser> and as this policy change not only affects ~motu but also ~core-dev it should be approved by the TB (if necessary) once a consensus exists
<persia> geser: Agreed.
 * persia hopes consensus can be built without bringing it to the TB
<bdrung> TB is only for issue where no consensus can be established
<persia> fabrice_sp: Hey.  So there's a new pgadmin3 available in the next Debian dinstall run: you mind watching and pulling that when it's ready?
<ari-tczew> persia: it is not so obvious, because earlier other person wanted use XfakesyncY
<persia> bdrung: Or we need some "official" statement for some reason (usually related to interaction with external groups).
<persia> ari-tczew: I want to use -XfakesyncY : it's just that it's not discussed in depth.  Feel free to use that if you want to be a member of the avant-garde
<fabrice_sp> persia, sure: that was yesterday's plan :-)
<bdrung> welcome fabrice_sp
<persia> fabrice_sp: OK.  Rhonda stopped by to report the upload, and I'm just passing the message along :)
<fabrice_sp> :-D
<fabrice_sp> Hey bdrung
<fabrice_sp> persia, just reading your email about fakesync: I like the idea of differencing fakesyncs and merges
<bdrung> fabrice_sp: thanks for uploading openshot. (a simple ACK from you would be sufficient)
<persia> fabrice_sp: I can't take full credit.  geser and bdrung were instrumental to the conclusion.
<ari-tczew> no ! no ! no ! -100 for XubuntuY fakesync ! please still using XbuildY yet in this development cycle
<fabrice_sp> bdrung, I only applied revu rule: the second ack'er uploads the package :-D
<persia> ari-tczew: -XbuildY is known to be wrong in several ways, and doesn't work with the archive-admin scripts.  Please don't use it.
<ari-tczew> omfg
<fabrice_sp> ari-tczew, no. xbuildy will be automatically synced in next dev, and we may not want that!
<persia> Or it may just cause the archive-admin scripts to lock up, which annoys archive-admins.
<bdrung> fabrice_sp: it started 7 hours ago with an discussion between ari-tczew and me.
<fabrice_sp> arriving late, I see :-D
 * fabrice_sp checks the log
<bdrung> fabrice_sp will be back in one hour (or 30 min if he can read fast) ;)
<persia> heh
<fabrice_sp> lol
<ari-tczew> fabrice_sp: I thought that auto-sync for fakesyncs in next dev cycle it is that what we want to get
<fabrice_sp> ari-tczew, only if it's a new upstream release. Otherwise, the sync will fail, annoying the archive admin (and we don't want annoyed a-a! :-) )
<persia> No, they tend to either send high-temperature email or not bother to process syncs.
<ari-tczew> fabrice_sp: so auto-sync needs development to differentiate fakesync and clean rebuild
<bdrung> fabrice_sp: should i put my fakesync script in the ack-sync branch?
<fabrice_sp> bdrung, that would be great, yes!
<persia> ari-tczew: Which requires a semantic hint, which is the point of using -XfakesyncY : until that is fixed, use -XubuntuY to work around the bug.
<bdrung> fabrice_sp: pushed
<ari-tczew> fabrice_sp, bdrung, geser: are you sure with persia? -XubuntuY until oficial -XfakesyncY ?
<bdrung> persia: why not use -XfakesyncY now?
<persia> bdrung: I can't think of any good reason, but ari-tczew seems to not want to do that.
<fabrice_sp> bdrung, cool! I'll push soon also a test-dsc script that will do the build/piuparts run on a local dsc file (I have to convert it to python :-d )
<bdrung> in the worst case, we have to request a sync (which will be the same for -XubuntuY)
<persia> No, in the worst case, it crashes auto-sync (which would be the same as for -XbuildY)
<bdrung> k
<persia> requesting a sync is relatively easy compared to doing a fakesync and requesting blacklist removal.
<persia> (although your tool will help with that)
<ari-tczew> so, so, so... men, consensus please
<geser> ari-tczew: if reaching consensus would be that easy we would need to discuss it
<persia> ari-tczew: If you want consensus, wait for discussion on the mailing list.  Otherwise, please decide what you think is best.  The problems with all of the current options have been outlined.
<bdrung> ari-tczew: +1 for  -XubuntuY until oficial -XfakesyncY
<persia> ari-tczew: If someone disagrees with your decision, you can argue your opinion with them.
<bdrung> ari-tczew: i would sponsor -XubuntuY
<geser> ari-tczew: use -XubuntuY for now
<l3on> Hi all, someone can explain me if this error (http://paste.ubuntu.com/375637/) is serious or not? (debiandoc2latexpdf: ERROR: thumbnail images could not be generated properly).  Packages are created and sucessfully installed.
<geser> l3on: "sh: gs: not found" -> missing build-dependency on ghostscript
<persia> l3on: Try using dpkg --contents to see if the .debs contain what you wanted
<ari-tczew> so, I would use -XbuildY, but as explained now, I'll use -Xubuntu1. End.
<l3on> geser: so I have to add ghostscript in dependences ?
<l3on> (I'm new in merging :))
<persia> ari-tczew: Is there any documentation you've read that specifically asks for -XbuildY?  I'm certain enough that is wrong that I want to fix it even before the discussion is completed.
<geser> l3on: yes, either in Build-Depends-Indep or Build-Depends (didn't look at the packaging)
<l3on> Yes, it's missed. Adding just "ghostscript" manually, or there is a tool?
<bdrung> fabrice_sp: now i remembered what i want to tell you: piuparts has no -W parameter (in karmic)
<ari-tczew> persia: https://wiki.ubuntu.com/PackagingGuide/Wishlist?highlight=%28fakesync%29
<fabrice_sp> bdrung, I have to check which version of piuparts I have because I'm running karmic, and ack-sync works perfectly
 * fabrice_sp is still reading the log :-D
<bdrung> :D
<fabrice_sp> persia, what was that comment about? "* persia looks about for fabricesp and is disappointed"
<fabrice_sp> just curious :-D
<persia> fabrice_sp: pgadmin3 :)
<fabrice_sp> oh, ok :-D
<persia> You didn't appear to be here, but in case I missed your join, I was hoping you'd ask.
<fabrice_sp> done then. Thanks for taking care ;-)
<geser> l3on: you can edit debian/control with your editor
<l3on> geser: done... and built.
 * fabrice_sp is back
<l3on> geser: what do you think about -> http://paste.ubuntu.com/375661/ ?
<l3on> seems to be clean.
<fabrice_sp> interesting to see the discussion about that XfakesyncY notion
<geser> l3on: looks good
<l3on> ok, I'm going to upload debdiffs on LP. Thanks geser.
<fabrice_sp> bdrung, you're right about the -W flag in piuparts: I installed version 0.38 to have that flag
<bdrung> fabrice_sp: BTW, we may have to port our ack-sync changes to fakesync
<bdrung> or create a library
<ari-tczew> I'm going away to have some fun, bye!
<bdrung> bye
<l3on> geser: can you take a quick look at bug 521455? Is it the right way to make a merge request?
<fabrice_sp> bdrung, a lib would be fine. This way, I could use it for local dsc testing/checking
<ubottu> Launchpad bug 521455 in blends "Please merge blends 0.6.10 (universe) from debian unstable." [Undecided,Confirmed] https://launchpad.net/bugs/521455
<bdrung> fabrice_sp: maybe checking python-apt if it can help us
<geser> l3on: looks ok on a quick look
<l3on> good geser. Thanks a lot :).
<fabrice_sp> bdrung, rmember I am at "Dive into python" level :-D
<bdrung> fabrice_sp: it's the right place to learn it. ;)
<oojah> Could someone take a few minutes to review http://revu.ubuntuwire.com/details.py?upid=7680 please? I don't think it should be very much work.
<bdrung> fabrice_sp: python-apt won't help us
 * fabrice_sp is totally lost :-/
<rmunn> Hmm, REVU may need an update: my latest build of http://revu.ubuntuwire.com/p/python-nltk created a "python-nltk_2.0~b8-0ubuntu1.debian.tar.gz" instead of .diff.tar.gz and REVU doesn't know how to handle those.
<rmunn> I mean instead of .diff.gz
<rmunn> Is this a change introduced by the deb 3.0 packaging tools? This is the first source package I created on Lucid rather than on Karmic.
<asbin> rmunn: you may have a "debian/source/format" file, for the "3.0 (quilt)" format ...
<bdrung> rmunn: yes, that's the new format (tarballs instead patches)
<asbin> bdrung: is this format already supported on ubuntu ? Lintian is not ok whith that format ...
<bdrung> asbin: it's supported and lintian is ok with it. only REVU cannot extract the package.
<asbin> bdrung: with lintian 2.2.17ubuntu1.1 I get a message "This package uses a different source package format than 1.0." !
<bdrung> asbin: use the lintian version from lucid or grab it from https://launchpad.net/~bdrung/+archive/backports
<rmunn> asbin, yes, I have "3.0 (quilt)" in debian/source/format, so debuild -S created a .debian.tar.gz -- only problem is REVU doesn't know how to extract it
<asbin> bdrung: hum, ok. As I'm still on karmic I didn't have the last version of course !
<asbin> thanks
<rmunn> Which means I don't get a debdiff at http://revu.ubuntuwire.com/p/python-nltk -- but hopefully it won't make it hard to review
<rmunn> Question about the REVU code: now that I've made a new source upload, the previous advocation by sistpoty has been invalidated, correct?
<bdrung> rmunn: the reviewer will probably build it and run lintian on it
<asbin> rmunn: ok thanks you ! I use 1.0 format in my package http://revu.ubuntuwire.com/p/enna ... BTW I may need advocation for that package please ! :)
<rmunn> So I'll need to ask sistpoty to re-advocate the new upload?
<rmunn> asbin, I'm not a MOTU so I can't advocate packages, otherwise I'd be happy to look at it :-)
<asbin> rmunn: Yes I know :) Good luck for your package !
<bdrung> asbin: do you intend to bring the package to Debian, too?
<fabrice_sp> openshot accepted! :-)
<asbin> bdrung: yes the package is already waiting on debian mentors :)
<bdrung> fabrice_sp: wow, they were fast
<bdrung> asbin: can you link the ubuntu bug to the debian bug?
<fabrice_sp> bdrung, yeah: the source NEW is generally slower. Now, binary NEW :-D
<bdrung> :)
<asbin> bdrung: you mean in the launchpad need-packaging bug ?
<bdrung> asbin: yes
<bdrung> fabrice_sp: how high is the change that we get yofrankie into lucid?
<bdrung> s/change/chance/
<fabrice_sp> do you have a link?
<bdrung> fabrice_sp: i have no source tarball and no debian directory. :D bug #311938
<ubottu> Launchpad bug 311938 in ubuntu "[needs-packaging] Yo Frankie!" [Wishlist,Confirmed] https://launchpad.net/bugs/311938
<bdrung> fabrice_sp: give me an hour and you get your dsc file
<fabrice_sp> bdrung, ok ;-)
<asbin> bdrung: done ! https://bugs.launchpad.net/ubuntu/+bug/519063
<ubottu> Ubuntu bug 519063 in ubuntu "[needs-packaging] enna" [Wishlist,New]
<bdrung> fabrice_sp: but you have to test it (my currently running karmic machine has no 3D)
<bdrung> asbin: go to "also affected distribution" and set the link there
<dooooomi> hi, i'm looking for someone to review gtklick, a GTK metronome for JACK, written in Python: http://revu.ubuntuwire.com/p/gtklick
<bdrung> dooooomi: : do you intend to bring the package to Debian, too?
<asbin> bdrung: ok, I never used this option ... I've linked it to the debian bug now
<bdrung> asbin: thanks
<dooooomi> bdrung: yup, i'll talk to the debian-multimedia guys
<dooooomi> bdrung: for now i'm hoping to have the package finished in time for lucid
<fabrice_sp> bdrung, I think it's ok here. What is the command to check?
<bdrung> dooooomi: can you link the ubuntu bug to the debian bug?
<bdrung> fabrice_sp: ?
<fabrice_sp> Â·D
<fabrice_sp> 3D
<bdrung> fabrice_sp: you have to check if the game works.
<fabrice_sp> ok
 * fabrice_sp is getting tired
<fabrice_sp> Just put here the link: I'll check the log tomorrow morning
<dooooomi> bdrung: by debian bug you mean the rfp?
<bdrung> dooooomi: yes. you should rename the RFP to ITP, when you package it.
<dooooomi> bdrung: how do i do that?
<asbin> bdrung: could you review my package enna ? http://revu.ubuntuwire.com/p/enna (if you have time ...)
<bdrung> dooooomi: http://www.debian.org/devel/wnpp/ -> ITP and http://www.debian.org/Bugs/server-control
<bdrung> asbin: ping me in a hour again
<asbin> bdrung: ok thank you !
<bdrung> then i might have time for it
<dooooomi> bdrung: thanks, got some reading to do ;)
<asbin> what is the current Standards-Version ? 3.8.3 or 3.8.4 ? on REVU, the 3.8.4 is not recognized ...
<lifeless> asbin: you can check - install the debian-policy doc from lucid, and check /usr/share/doc/debian-policy/*
<asbin> lifeless: exactly, the debian-policy in lucid is 3.8.4 : http://packages.ubuntu.com/lucid/debian-policy, but on REVU this version is flagged as "newer-standards-version" by lintian ...
<lifeless> bug in revu
<ryanakca> Could someone please review / sponsor http://revu.ubuntuwire.com/p/turnin-ng (simple python application, both turnin-ng_1.0.1-0ubuntu1_source.changes and turnin-ng_1.0.1-0ubuntu1_i386.changes are lintian -IivmE --pedantic clean)
<persia> lifeless: The "bug in REVU" is that there's no good sparc kernels for karmic or lucid :)
<lifeless> persia: REVU runs on sparc?!
<lifeless> persia: cause, that might really be the bug ;>
<persia> lifeless: Have an extra machine and lots of bandwidth you want to donate?
<lifeless> persia: yes to the former, I live in Australia to the latter.
<persia> lifeless: Yeah, well.  We have bandwidth available in UK and Germany, but even then shipment gets expensive.
<persia> But for now, REVU mostly gets by, even if it gets confused sometimes.
<sistpoty> revu is only as confused as the sparc port is :P
<sistpoty> (at least it is now, earlier on when I still hacked on it, it was as confused as /me *g*)
<persia> Well, we have userspace solutions for a lot of it, in one place or another, but the backporting gets messy.
<persia> If we had a good kernel, we could probably run karmic.
<sistpoty> once upon a time, I'll simply dist-upgrade the box and then go on vacation :P
<sebner> sistpoty: to lucid!
 * sebner hugs sistpoty :D
<sistpoty> sebner: to lucid+1 :P
<sistpoty> hi sebner
<sistpoty> geser: looking at bug #521380: please apply for core-dev, kthxbye ;)
<ubottu> Launchpad bug 521380 in dia "Don't use LOCALMODLIBS from python for linking" [Undecided,New] https://launchpad.net/bugs/521380
<sebner> geser for core-dev \o/
<sebner> sistpoty too \o/
<sebner> maybe generalist developer now *g*
<sistpoty> sebner: I'm already core-dev :P
<sebner> sistpoty: *haha* but you have to envolve to generalist developer :P
 * persia remembers that sistpoty holds the record for the shortest-ever core-dev application (and probably always will)
<sistpoty> heh
<sebner> sistpoty: if your life becomes boring you can still become DD :D
<kamalmostafa> sispoty: fyi I have responded to your question in bug 521164
<ubottu> Launchpad bug 521164 in omhacks "omhacks FTBFS: open O_CREAT needs 3 arguments" [Undecided,Confirmed] https://launchpad.net/bugs/521164
<sistpoty> sebner: heh, tried that once, but got rejected since I was too lazy *g*
<geser> sebner: he plans to first break REVU before breaking Debian :)
<sebner> xD
<sistpoty> kamalmostafa: looking
<sebner> breakage everywhere needs to be the goal!
<persia> Um, no.
<sistpoty> bdrung: meh, I broke asm3 with sponsoring your merge (looks like javahelper is the one to blame though, as it has a dependency on univers)
<sebner> persia: you are missing the point. Bleeding edge leads to breakage :P
<bdrung> sistpoty: got the failed message. javatools was promoted to main.
<sistpoty> bdrung: ah, so I guess we can retry once the transition to main is complete?
<sistpoty> bdrung: or does javatools need a no-change upload first?
<bdrung> sistpoty: javatools is already there.
<sistpoty> ah, k
<bdrung> sistpoty: we have to promote python-scriptutil to main
<sistpoty> bdrung: ah, right, that was it
<sebner> RainCT: congrats on mistelix :)
<RainCT> sebner: Haha. Yeah, was about time that it gets uploaded...
<sebner> RainCT: well, it's your own fault. Just look at your rules file .. I'd never have uploaded it tbh :P
<rmunn> sistpoty, Would you have time to look at http://revu.ubuntuwire.com/p/python-nltk again? I discovered I had written the wrong bug number in my changelog, so I had to upload a new version of the package -- and so your advocacy yesterday is now out-of-date.
 * RainCT hits sebner with a stick
 * sebner hides
<persia> sebner: Oh, did you see that the dpkg-buiildpackage changes required for the dpkg merge required to allow Soyuz to accept alien-arena were uploaded?
<rmunn> sistpoty, I upgraded the packaging to the "3.0 (quilt" format, but there are no other technical changes, so it should be a fairly quick review when you have time for it.
<sebner> persia: I'm reading your sentence but I'm not understanding it xD
<RainCT> sebner: You should be doomed to using CDBS until the end of your days! :D
<rmunn> Incidentally, I discovered that REVU doesn't know how to handle the 3.0 format -- .debian.tar.gz tarballs break its poor little brain. :-)
<sebner> RainCT: CDBS would be doomed through me then :P
<RainCT> rmunn: Yeah, REVU is running on a Hardy box.
<sebner> + SPARC
<sebner> poor Revu
<persia> sebner: You care about https://lists.ubuntu.com/archives/lucid-changes/2010-February/005483.html as the first step towards fixing alien-arena
<sebner> persia: Yeah I know. After bzr stuff is done cjwatson does the dpkg merge. I heard of it already
<sebner> persia: Thanks for the hint but we don't want to give cjwatson that much of pressure :P
<sistpoty> kamalmostafa: you've got a point with umask there, probably I'm just paranoid since the files reside in sysfs ;)
<sistpoty> kamalmostafa: uploading
<persia> sebner: Then stop highlighting :)
<sistpoty> kamalmostafa: oh, i.e. uploading after I've done a test-build, as it looks that I haven't done that yet
<kamalmostafa> sistpoty: very good, thanks for reviewing and sponsoring it.  should build fine for you.  :-)
<sistpoty> kamalmostafa: thanks for the patch in the first place ;)
<sebner> persia: pssst, that's reverse psychology. He'll feel guilty and makes dpkg top priority once he reads the messages of our poor souls :P
<sistpoty> rmunn: looking
<rmunn> sistpoty, Thanks!
<asbin> bdrung: hi, you ask me to ping you now ;) can you please have a look at enna ? http://revu.ubuntuwire.com/p/enna (if you have the time to ... ) Thanks !
<persia> I don't think that works so well.  More irc highlighting seems to reduce time for development work.
 * sistpoty highlights persia and sebner :P
 * sebner hugs sistpoty and persia :D
<sistpoty> :)
 * bdrung wonders if sistpoty creates the MIR for python-scriptutil.
<sebner> sistpoty: I really think we have too less life and too much time xD
 * sistpoty would prefer if bdrung would do it
<bdrung> let's see if reverse psychology works
<sistpoty> sebner: heh
<dupondje> evening :)
<tsmithe> hi, the upstream for mscore (which i look after) wants to change the [source] package name to "musescore". would the best way to go about doing that to be to upload a new source package, "musescore" which builds binaries using that name, and a new version of "mscore" which builds dummy packages that depend on the musescore packages? should i also have the musescore binaries Provide mscore-named packages, so that the mscore source package can eve
<tsmithe> ntually disappear?
<tsmithe> (could this all be done before FF?)
<lifeless> tsmithe: don't upload a new version of mscore
<lifeless> just have musescore provide dummy packages too
<tsmithe> i thought about that.
<lifeless> its whats normally done
<tsmithe> but surely then, musescore and mscore would both be in the archives building binaries with the same name? or there could be some timing peculiarities?
<lifeless> you get the archive admins to remove mscore
<tsmithe> ok, i'll build the package. is the procedure these days to upload to revu, still?
<lifeless> dunno; going out now sorry
<tsmithe> eventually, i'll have it uploaded to debian, but i want it to be definitely in lucid
<tsmithe> right, cheers for the help
<persia> tsmithe: Didn't you get mscore into Debian?
<tsmithe> i did
<tsmithe> but it's quicker for it to go into ubuntu first, seeing as ff is in 5 days
<persia> Oh, right, because of NEW :/
<tsmithe> i can always sync later :)
<tsmithe> exactly
<persia> tsmithe: But you don't need REVU for a source rename: just prepare a new diff.gz and upload it to a bug against mscore.
<persia> (remembering to create the dummy transitional packages)
<tsmithe> well, i will also want an updated orig tarball :)
<tsmithe> i've done all the work, it's just a matter of uploading
<persia> Right, but you'd get that from either the watch file or the get-orig-source rule, either of which would be in the diff.gz, which your sponsor can pull from upstream.
<tsmithe> that's tricky, because i want to upload a beta version, which is in actuality a lot more stable than the current version 0.9.5. however, there is no tarball released for it, as it is built from vcs sources.
<persia> tsmithe: get-orig-source can solve that :)  Just document how to construct the tarball in the form of a make rule.
<persia> tsmithe: But be sure to use a version like 0.9.6~beta-0ubuntu1 so that it can be overridden by the newer release from Debian.
<tsmithe> of course; it's done. my get-orig-source rule exists, it's just a matter of creating a "get-beta-orig-source" rule to handle the svn case
<persia> heh.
<tsmithe> who should i subscribe to the mscore bug?
<persia> tsmithe: u-u-s (and me, because I want new shiny musescore)
<tsmithe> you can always use the ppa! ;)
<persia> I don't use PPAs as a matter of ideology.
<tsmithe> although.. it is a little out of date :s
<tsmithe> persia, really?
<persia> Really.
<persia> I think the proliferation of third-party repositories is ultimately bad for the health of Ubuntu.
<tsmithe> but aren't there cases where it's, maybe not necessary, but at least worth-while
<tsmithe> oh, i agree. but i try to be pragmatic about it.
<tsmithe> i believe that mscore releases tend to get less buggy as they go on, but in a way that isn't compatible with the release process for ubuntu
<persia> I believe it discourages people from trying to have their applications included, and encourages weak packaging skills by reducing the value of peer coordination and training.
<tsmithe> for example
<tsmithe> that's true, too. but my case is still not a rare one.
<persia> agreed.
<tsmithe> the overall stability of ubuntu seems too tightly dependent on specific package versions
<tsmithe> either we need ppas, or a looser system
<tsmithe> (but looser doesn't necessitate less rigour)
<persia> If I were a software developer, I'd love PPAs because it makes for an easy (and mostly safe) way to expose stuff to testers and get feedback.
<persia> But I'm a distro developer, so I don't :)
<tsmithe> but, as a distro developer concerned with the future of your distro, don't you want it supported by devs who don't light the apparent barrier to entry, regardless of whether it's there for a good reason?
<tsmithe> *don't like
<persia> tsmithe: Out of curiosity, how isn't the musescore release process compatible with the Ubuntu process?
<persia> tsmithe: I'd rather reduce the perception of barrier-to-entry :)
<tsmithe> lots of bugs are fixed in 0.9.5/.6 that are present in 0.9.4 (which is in karmic). but isn't it true that new upstream versions (which is what they are) are not desirable in stable ubuntu releases? and, as these fixes are too intrusive to be backportable, they're not really feasible included. and so i popularise the ppa.
<persia> Ah, because musescore is releasing on a very fast cycle.
<persia> Well, our ideal process would be for someone to backport only the bugfixes (and not new features).
<tsmithe> exactly, but that's not really possible in this case.
<persia> Alternately, to have separate feature vs. bugfix branches by upstream.
<persia> But yeah, that's often not possible.
<tsmithe> and, i'm sure it's not just my project that's affected.
<persia> No, it's any project with a frequent-release model and no long-term support commitment for any releases.
<tsmithe> i'd prefer ubuntu-proposed (say) to accept new upstream releases on the promise that they were more stable, and then test.
<persia> The issue is the testing.
<tsmithe> if the promise is good, then include it (if that's realistic, due to things like compatibility etc)
<tsmithe> hmm.
<persia> There are some projects that have that sort of arrangement: it requires approval by the TB.
<persia> And to have someone specifically caring for it in Ubuntu.
<asbin> persia: Hi, you remember, you let a comment on enna on REVU http://revu.ubuntuwire.com/p/enna , I had made the necessary changes, so if you want to have a look it will be nice ! :) Thanks
<persia> But without that level of commitment to Ubuntu by a project, there's a risk to Ubuntu that something might go wrong.
<persia> For example, I'd really hate to try to explain to my mother why she needs to do something different when she only meant to apply "critical bug fix updates".
<tsmithe> right.
<tsmithe> i do specifically care for musescore in as much as i regularly provide new "releases" in the ppa, and respond to queries etc. i also feel that it's a minimal risk kinda thing. but things *do change*, and that would affect documentation and support.
<persia> Wherein lies the risk in allowing new features.
<persia> Personally, I understand both viewpoints, but I think the current policies are a reasonable compromise to both allow new stuff in each release, and avoid confusing users who didn't intend to upgrade.
<tsmithe> and hence the status quo
<persia> Right.
<tsmithe> i agree that we have a good compromise.
<persia> But we try to make the release cycles relatively short, to avoid getting too out of date.  I'm not sure there's a perfect answer.
<paissad> guys, i have this error during lintian run --> changelog-should-mention-nmu <-- after i decided to rebuild the package http://pastebin.com/f2740a888
<tsmithe> and my situation is such that, when i do want to get a new release in ubuntu, because i keep care of the packages regularly, there's not too much change i need to make.
<tsmithe> paissad, not that i know the specific error, but run "lintian -i" for an explanation
<paissad> i've read the lintian tags info but i'm a lil bit confused
<SoftwareExplorer> Hi. I'm trying to package a gtk module. It's only a single .c file, that didn't come with a make file. I read about making a simple make file at http://ubuntuforums.org/showthread.php?t=497200, and got it to compile with that. However, before the makefile you would install the file with sudo cp. How do I modify the makefile so that I can start packaging it like http://www.youtube.com/watch?v=zKLabbXTqMc explains? I can p
<persia> paissad: What revision string did you use?  What name is listed as "Maintainer", and what name is listed in the last changelog entry?
<paissad> tsmithe, lintian-info --tags ... i did it
<tsmithe> in ubuntu, i think that one's ignorable because of the maintainership situation (use the motu team, normally); i'll let persia take care of this :)
<persia> SoftwareExplorer: Just compile it directly in debian/rules build: with gcc
<tsmithe> right
 * tsmithe disappears
<persia> tsmithe: I'll grab musescore in a few hours.  Thanks for pushing to get it in.
<persia> (unless someone else uploads it first)
<tsmithe> no problem, and thank you.
<SoftwareExplorer> Ok, so I should read up on how debian/rules works?
<persia> SoftwareExplorer: It's a makefile.
<persia> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
<tsmithe> persia, can i talk to you about a new python package later this week, as well? ideally, it needs to go to debian. (it's called "pisa" if you want to briefly look at the description in ppa:mscore-ubuntu)
<bdrung> asbin: sorry. it's too late now for me. will have a look at it tomorrow. just ping me again then
<SoftwareExplorer> Ok, I guess I'm learning makefile as I go.
<asbin> bdrung: OK no problem, thanks :)
<paissad> persia, here is the changelog http://pastebin.com/f54122855 --> pms-linux_1.20.392-1.1_all.deb  and here is the control file http://pastebin.com/f550683f0
<bdrung> SoftwareExplorer: makefiles are easy to learn except you write makefiles like http://code.google.com/p/gnome-colors/source/browse/trunk/gnome-colors/Makefile ;)
<persia> paissad: "DIAKHATE Papa Issa <paissad@gmail.com>" != "Papa Issa DIAKHATE <paissad@gmail.com>" and the revision is -1.1
<paissad> persia, that's all o0
<paissad> oops
<SoftwareExplorer> bdrung: Is there a web page that explains make files well enough to get me started with out takeing a couple of hours to read?
<persia> paissad: Yep.  The tools noticed the difference, and thought you weren't you.
<persia> bdrung: It can get better than that: http://bazaar.launchpad.net/~persia/+junk/moblin-analysis/annotate/head:/Makefile
<bdrung> persia: that makefile is dead simple. no foreach, no call, ...
<persia> Um, read it again then :)
 * persia has nested calls in foreaches, etc.
<persia> OOh, and foreaches in calls :)
<bdrung> SoftwareExplorer: the long way: http://www.gnu.org/software/make/manual/make.html or just google for makefile tutorial
<SoftwareExplorer> bdrung: Ok, Thanks.
<bdrung> persia: found them, but my makefile is longer ;P
<persia> bdrung: Yes, much.  I just think mine happens to be a nice example of nested recursion :)
 * persia is especially proud of PICK_FILE
<bdrung> yes, PICK_FILE is nice
<persia> But I failed to use define at all, which perhaps makes it less fun :)
<matttbe> Hi,
<matttbe> I'm part of the Cairo-Dock team and I've a little question: I've downloaded the ubuntu branch of Cairo-Dock and I've updated it. Do I have to commit with a message respecting some rules? Can I push my merge proposal branch everywhere in Launchpad or not?
<matttbe> Thanks for your help !
<bdrung> asbin: wrote a comment to http://revu.ubuntuwire.com/p/enna
<matttbe> gilir has answered to my question, thanks !
<asbin> bdrung: great thanks !
<bdrung> asbin: yw
<tsmithe> aargh ffs, just deleted my got-orig-source with a careless rm. there goes another hour downloading :s
<tsmithe> (and a further half hour to do a final pbuild..)
#ubuntu-motu 2010-02-14
<SoftwareExplorer> Will someone explain to me what DESTDIR in a makefile does?
<persia> SoftwareExplorer: It's typically used to identify the location into which the software should be installed.
<SoftwareExplorer> so if I make it so that when a person runs make install it usually copies a file to /usr/lib/gtk-2.0/modules/, were should it copy to ?
<SoftwareExplorer> $(DESTDIR)/usr/lib/gtk-2.0/modules/librgba.so
<SoftwareExplorer> ?
<directhex> SoftwareExplorer, DESTDIR is useful to override the behaviour you've otherwise been encouraging. For example, if you compile with "--prefix=/usr", then things like pkg-config files will have that prefix burned in - but when building a package, you cannot touch /usr, so your package build would break
<directhex> SoftwareExplorer, so you'd use "DESTDIR=debian/tmp make install" to make "make install" override into a different prefix
<directhex> whilst still burning in data relating to --prefix=/usr
<SoftwareExplorer> So, is DESTDIR to help you with where to put the file once it's compiled, or give you a temporary place to run gcc and build the file?
<directhex> the former
<directhex> DESTDIR is the place "make install" installs to
<tsmithe> DESTDIR is the "DESTination DIRectory"
<SoftwareExplorer> I put the makefile I'm working on at http://paste.ubuntu.com/375816/. Would you mind looking at it and telling me if I'm doing it right?
<persia> SoftwareExplorer: Looks reasonable.  Does it work?
<directhex> no, that's wrong
<persia> Why?
<directhex> you shouldn't force /usr
<directhex> i.e. DESTDIR=/opt should go into /opt, not /opt/usr/
<persia> Ah, that would be ${DESTDIR}/${PREFIX}/... though.
<SoftwareExplorer> So how do I tell it that it should put it in /usr/lib/gtk-2.0/modules by default?
<persia> Set PREFIX to usr
<persia> Oh, and use PREFIX ?= so that it can be overridden by directhex's user who wants to install in /opt/
<SoftwareExplorer> persia: How does the computer know that the program is in /opt ?  The main reason I'm trying to write a makefile is so that I can make a .deb out of a single .c file, and this is the first time I've tried to do a makefile.
<persia> The user would run `DESTDIR=/opt PREFIX="" make install`
<SoftwareExplorer> So that would override whatever I set it to in the makefile?
<SoftwareExplorer> Ok, here's the new version of the makefile. http://paste.ubuntu.com/375827/  I'm not sure if I did the PREFIX part right.
<persia> SoftwareExplorer: "PREFIX ?=usr/" and "${DESTDIR}/${PREFIX}/lib/gtk-2.0/modules/"
<SoftwareExplorer> Ok, thanks so much for the help. That clears up a lot of confusion.
<lexual> gpodder package in universe has bugs and is an older version, ppa has current version without bugs, how does one go about getting the packaged patched or updated?
<lexual> https://bugs.launchpad.net/ubuntu/+source/gpodder/+bug/508886
<ubottu> Ubuntu bug 508886 in gpodder "gpodder crashed with AttributeError in set_attributes()" [Undecided,Fix released]
<persia> !update
<ubottu> For upgrading, see the instructions at https://help.ubuntu.com/community/UpgradeNotes - see also http://www.ubuntu.com/getubuntu/upgrading
<persia> Darn!
<persia> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
<mr_steve> Question: If I want to fix a bug in a package - firefox-vimperator in this case - what's the procedure? Attach a debdiff to the bug report? Submit an updated package to REVU?
<persia> mr_steve: Attach a debdiff to the bug report, and subscribe "ubuntu-universe-sponsors"
<lexual> I'm not sure if I was clear, I know how to upgrade my packages to the latest version. I want to who to speak to get a newer version into the archive.
<persia> lexual: File a bug against the package and attach the diff.gz file from the upgrade.
<mr_steve> persia, thanks
<lexual> persia: there is a bug already and it has links to *.dsc and ppa of updated package.
<lexual> https://bugs.launchpad.net/ubuntu/+source/gpodder/+bug/508886
<ubottu> Ubuntu bug 508886 in gpodder "gpodder crashed with AttributeError in set_attributes()" [Undecided,Confirmed]
<persia> lexual: Does that .dsc link to something that builds and solves the bug for lucid?
<lexual> according to ppa person it does, give me a few minutes and I will test on my system.
<lexual> https://launchpad.net/~thp/+archive/gpodder/+packages
<lexual> persia: I have just installed ppa package and it solved the crash problem.
<persia> OK.  Update the bug with a comment about that, and subscribe ubuntu-universe-sponsors
<lexual> persia: done
<persia> lexual: One of the developers will double-check, and either upload or explain if something else is needed.
<persia> Thanks a lot for investgating that.
<lexual> persia: great, thanks for your help.
<paissad> lintian seems not to accept XSBC-Original-Maintainer .. in the control file ... neither in the .dsc file
<paissad> should i consider that warning ?
<persia> paissad: Um, Which lintian message do you get from that?
<paissad> persia, W: pms-linux source: unknown-field-in-dsc original-maintainer
<paissad> I: pms-linux: unknown-field-in-control original-maintainer
<persia> Which lintian are you running?
<paissad> persia, Lintian v2.3.2ubuntu1
<paissad> http://pastebin.com/f3ac76ed3
<persia> Ah, what *version* is your package?
<paissad> pms-linux_1.20.392-1_all.deb
<persia> OK.  I think that's an issue in lintian, but maybe not: specifically I suspect that lintian is checking the version number to determine if "Original-Maintainer" is a valid control file entry.
<persia> Try again with 1.20.392-0ubuntu1 and see if you get the same result.
<paissad> ok
<paissad> persia, indeed, if i append 0ubuntu1 instead of 1, i have no warning ^^
<persia> Right.  I think it's a bug, but I suspect that many people disagree with me.  I know why it's that way, and it's not important.
<persia> So, basically, if you're preparing a package for Ubuntu, use Original-Maintainer, and if you're preparing a package for Debian, don't.
<paissad> persia, i think that -1 or 0ubuntu1 should be both accepted
<persia> Why?
<persia> And Where?
<paissad> persia, i just think that lintian should not return any warning because we choose to append -1 instead of -0ubuntu1 when we enter Original-Maintainer:
<persia> Heh, neither do I :)
<persia> But the reason it does that is that a new upload to Debian should have -1, and using Original-Maintainer in Debian is a bug.
<paissad> ok
<persia> And a new upload to Ubuntu should have -0ubuntu1, and not using Original-Maintainer in Ubuntu is a bug.
<paissad> lol
<tsmithe> persia, if you're still around, i'll probably upload the diff in around half an hour or so. this build is taking unusually long; i'm sure that in the end it'll be successful, but naturally, i don't want to waste your time.
<persia> tsmithe: Thanks for your concern: I'm looking forward to the new shiny bits :)
<tsmithe> cool. annoyingly, though, because i've not got around to getting pisa in a state that the debian python folk think is acceptable (and because they're so hostile), manuals are still only provided online, and the local ones are deleted, because i can't build the pdfs.
<tsmithe> (pisa you can see at https://launchpad.net/~mscore-ubuntu/+archive/ppa/+sourcepub/893784/+listing-archive-extra)
<tsmithe> however, that's immaterial, really. another cool development is that the 0.9.6 release includes another free soundfont :)
<tsmithe> and it's a lot smaller than fluid
<persia> tsmithe: You can't get pisa into Debian?
<persia> Another soundfont?  Excellent!
<persia> Is it separable, or only available with mscore installed?
<tsmithe> i provide it as a separate binary package
<persia> Lovely.
<tsmithe> as for pisa.. well, when i tried to talk to the python team about it, they seemed fairly hostile. i can't remember what their objections were, but it was something to do with eggs.
<hyperair> soundfont?
<tsmithe> persia, in any case, they didn't have very good documentation
<tsmithe> hyperair, yes?
<hyperair> what's a soundfont? O_o
<tsmithe> it's like a font, but with banks of sound samples, rather than glyphs
<tsmithe> so you can use midi calls to reference those sounds, and make music
<tsmithe> (think timidity/freepats etc?)
<persia> Well, freepats is a particularly unfortunate example :)
<tsmithe> yes, that's why i chose it :)
<hyperair> ooh cool
<tsmithe> hyperair, having a free soundfont was necessary to make musescore (a notation program that i maintain) worthwhile, but coincidentally it also allows more applications better sound. i'm glad now that we don't only have one 120mb one.
<tsmithe> i still think we're not quite at the same stage that exists on windows, with a centralised midi server thingy, but i think we're getting there thanks to some gstreamer support and a nicer pulseaudio.
<hyperair> 120MB huh. that's big.
<persia> tsmithe: If you have any ideas to improve the gstreamer support, I'd like to hear about it.  The wildmidi integration feels like a bi of a hack, and lots of users complain about things that aren't quite bugs.
<tsmithe> hyperair, it had lots of samples :) the new one has fewer (though i think it still provides the whole gm set)
<tsmithe> persia, well, i think wildmidi is the main weakness. it's a nice library from what i've seen, but its development seems to have stalled.
<persia> Yeah, well.
<tsmithe> does it still not support sf2?
<persia> I've not uploaded a new version since way back when.
 * persia checks upstream
<tsmithe> looks like it doesn't, according to the site
<persia> Yeah, but I should probably update it.
<persia> There's a note on the homepage about visiting the IRC channel to abuse them about the hackiness of 0.2.2 :)
<tsmithe> mm
<tsmithe> its main advantage it its lightness, i think, which is good. i don't know how its performance compares to fluidsynth, which is still my favourite
<tsmithe> but, of course, fluidsynth has to run as a daemon, which i'm not sure is ideal.
<persia> 3.0 has sf2 support.  I'm not sure I'll get it into Lucid, but I should be able to get it into squeeze.
<tsmithe> does 3.0 exist, then? i thought it was just a plan.
<tsmithe> i think an ideal situation could involve a very minimal daemon that opens an alsa midi port. if something tries to play, it just builds the right gstreamer pipe, all the while opening another port to allow two things to use it at once.
<tsmithe> then of course, i suppose gstreamer could do as musescore does, and link against libfluidsynth rather than libwildmidi
<tsmithe> of course, i don't know how feasible this is, but it's certainly too much work for me at least until the summer
<persia> Oh good.  I'm not as bad a maintainer as I thought from the homepage.  Yeah, neither 2.3 or 3.0 has been released.
<tsmithe> thought so.. that's what i meant by "stalled" :s
<persia> There's been a few stalled attempts to write some glue that provides a midi sink and gstreamer source.  They all seem to either get overambitious (and turn into softsynths) or not get completed.
<tsmithe> i think anything i started would quickly fall into the latter category. as the adage goes, it's easier said than done.
<tsmithe> (though i think it could be "easy". but you couldn't avoid "time-consuming")
<persia> Well, it wouldn't be that hard to build a gstreamer module that wrapped fluidsynth.
<persia> But that would be kinda heavy to provide by default.
<persia> (part of why I liked wildmidi)
<tsmithe> yes. but would it be excessively heavy? i know fluid is very configurable, and to me it has always *sounded nicer*
<persia> Fluid is lovely, but it does require a fair bit of processor and RAM.
<tsmithe> do we know why that is?
<tsmithe> (i've never read the code)
<persia> I don't offhand.  I've always assumed it was because it was good at what it did.
<persia> Remember that fluid has all those built-in effects engines and what not.
<tsmithe> i know.. can they be turned off? as a hypothetical default, to lighten the load, that could be attractive.
<persia> I don't know.
<persia> But since we're talking about a theoretical project you don't expect to have time to complete, I'm not sure how much it matters yet :)
<tsmithe> no. you're right, and i must admit that was the thought that occurred in my head
<persia> heh
<tsmithe> ok, pbuilder finally done. time to open the bug.
<tsmithe> persia, https://bugs.launchpad.net/ubuntu/+source/mscore/+bug/521584
<ubottu> Ubuntu bug 521584 in mscore "Please upload musescore 0.9.6~beta1+dfsg-0ubuntu1" [Undecided,New]
<persia> tsmithe: Thanks.  I'll grab it in a bit.
 * jdong wonders if it's actually feasible to backport enough of dpkg bits to support source 3.0
<tsmithe> persia, thanks a lot.
<tsmithe> hi jdong
<tsmithe> but, i'm off to bed. it's 4am again :s
<jdong> hey tsmithe :)
<tsmithe> ciao! got a lot of music and reading to do tomorrow; gotta get some rest
<persia> jdong: Wait for the next merge: there's still some 3.0 bits that lucid doesn't support.
<ryanakca> Could someone review http://revu.tauware.de/p/turnin-ng please? turnin-ng_1.0.1-0ubuntu1_{source,i386}.changes are lintian clean.
<jdong> ah :) good to know
<SoftwareExplorer> I'm having trouble building a package because a directory it installs to doesn't exist in my minimal pbuilder environment. The error I get is at http://paste.ubuntu.com/375971/. How should I handle this ? A mkdir -p in the makefile? Some other part of the packaging? Or should I be looking for the package that makes that directory and depending on it?
<fabrice_sp> SoftwareExplorer, the makefile should create the directory it requires to make the cp. Perhaps install would be better than a cp
<SoftwareExplorer> In my google ings since I asked, I read a little about install. I have a few questions though. What's the difference between install -d and install -D, i.e. which one gets closest to what cp librgba.so /usr/lib/gtk-2.0/modules/ would do?
<jmarsden> SoftwareExplorer: man install    for info on the arguments to it.  install -d foo just creates the directory foo; install -D SRC DEST "create all leading components of DEST except the last, then copy SOURCE to DEST"
<jmarsden> SoftwareExplorer: So (guessing a lot) you might want to do something like:   install librgba.so /usr/lib/gtk-2.0/modules/librgba.so
<jmarsden> Sorry, make that:  install -D librgba.so /usr/lib/gtk-2.0/modules/librgba.so
<SoftwareExplorer> jmarsden: Ok, thanks. I was looking at the man page, but I didn't get the synopsis part.
<SoftwareExplorer> jmarsden: Thank you! It worked.
<jmarsden> The synopsis in every man page is a list of the ways to use the command.  So if you use install -d all you put after that is a directory, ...
<jmarsden> Good!
<SoftwareExplorer> So, another question. For the uninstall, there's no uninstall command, so is rm the way to do it?
<SoftwareExplorer> Well, at least when I did man uninstall I got an error about no manpage
<jmarsden> SoftwareExplorer: You need an "uninstall" target in your makefile, for a Ubuntu package?  Why?
<jmarsden> How is your debian/rules file going to use that makefile target?
<SoftwareExplorer> Well, this is the first package I've tried.
<SoftwareExplorer> So I'm learning lots as I go.
<jmarsden> SoftwareExplorer: So you have read and understood the Packaging Guide, right.  And does it mention the need for an uninstall target?
<jmarsden> What gave you the idea that you need one?  Is there some packaging documentation out there suggesting one?
<SoftwareExplorer> No.
<jmarsden> Then... why are you asking me about one? :)
<jmarsden> https://wiki.ubuntu.com/PackagingGuide/Complete    is the guide for doing Ubuntu packaging.  Follow it, and you should be fine.
<SoftwareExplorer> Because I guessed that if the package uses a makefile to install, then it probably uses a makefile to uninstall.
<fabrice_sp> it should, but it's not mandatory
<fabrice_sp> opps: I was thinking about a clean target
<fabrice_sp> uninstall: no. It's been handeld by the package management tools
<jmarsden> fabrice_sp: Right.
<SoftwareExplorer> So it's something like dpkg keeps track of files installed by a package and deletes them when the package is removed?
<fabrice_sp> yeap
<wgrant> Your rules file installs files into the *package*, not onto the system.
<SoftwareExplorer> I see.
<SoftwareExplorer> Thanks for the help, and I guess I have lots more "homework" to read. :)
<jariq> My package finaly got into universe repository. Will I get e-mail automaticaly when someone reports a bug or do I have to subscribe somewhere ??
<ripps> It seems that I can't update bzr on my lucid because bzr-gtk has a bzr dependency of (>> 2.1~) which apparently is less than the new bzr's 2.1.0~rc2-1
<ripps> Is bzr-gtk really incompatible with bzr 2.1.0~rc2, or is it just be too cautious
<iulian> jariq: https://launchpad.net/ubuntu/+source/ipwatchd/+subscribe
<iulian> jariq: Do the same for the second package.
<jariq> iulian: thx
<l3on> fabrice_sp: Thanks for uploading blends :).
<l3on> fabrice_sp: I'm going to also report bug in debian.
<fabrice_sp> l3on, thanks to you to work on the merge ;-)
<oojah> I'm looking for an advocate or two for http://revu.ubuntuwire.com/p/sqlite3-pcre If you fancy giving this package some love on this day of romance, I'd much appreciate it.
<nigelb> can someone help me with an error when I try to package.  Its something to do with the patch.  I have an idea whats wrong, but I'm not sure how to correct it
<nigelb> this is the error message I get http://pastebin.com/d1cede653
<randomaction> nigelb: your pastebin link doesn't work
<nigelb> randomaction, oops, hold on.  pasting again
<nigelb> I lost the logs, building again to reproduce error
<nigelb> here's the paste http://paste.ubuntu.com/376060/
<randomaction> yes, the patch doesn't apply
<nigelb> the thing is one file the patch is supposed to apply is not exiting at the end
<nigelb> but I dont see how
<nigelb> I did a quilt push and then patched
<nigelb> so, all patches should have applied
<nigelb> s/exiting/existing
<randomaction> maybe it's deleted in the clean target?
<l3on> Hi all... I'm building debian-med... In the build log I see:
<l3on> Missing or avoided packages:
<l3on> and then a list of packages...
<l3on> is it an error?... What means "Missing or avoided packages" in pbuilder ?
<l3on> -> http://paste.ubuntu.com/376066/
<ari-tczew> l3on: built fine
<ari-tczew> is MoM fixed?
<l3on> ari-tczew: thank you.
<l3on> ari-tczew: "is MoM fixed?" to me ?
<ari-tczew> l3on, nope, generally to MOTU / developers
<ari-tczew> bdrung, geser, persia: ping
<BlackZ> hello, sombody can review this packet? http://revu.ubuntuwire.com/p/autotrash thanks
<geser> ari-tczew: MoM is fixed
<ari-tczew> geser: second question about fakesync... do we should include previous ubuntu's revision in debian/changelog?
<ari-tczew> like in merge
<geser> IMHO no, as we would do a normal sync if we didn't need that fakesync
<ari-tczew> geser: third question about fakesync... issue is mismatching tarball, so why we can't replace tarball with debian?
<geser> the current packages in the archive reference the Ubuntu .orig.tar.gz with its md5sum and when you replace it with one with a different md5sum you break those old .dsc files
<ari-tczew> so need to just repace all 3 files - diff.gz, .dsc, tarball
<dooooomi> do all modifications outside the debian directory require the use of dpatch or quilt? what if it's just minor, debian-specific changes to the build system or something?
<ari-tczew> persia: do you will work on bug 294593 ?
<ubottu> Launchpad bug 294593 in lash "Please merge lash 0.5.4-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/294593
<geser> ari-tczew: how for all published (and mirrored) revisions? remember that you can fetch old versions from LP. All the tools assume that once a file got published it doesn't change anymore
<paissad> hi all, http://revu.ubuntuwire.com/p/pms-linux ... the package is lintian warning|error free !
<jcfp> paissad: that contains loads and loads of binaries, many without sources and/or licenses...
<paissad> jcastro, o0
<paissad> jcfp,
<paissad> jcfp, i don't see what's the matter mate, ... the licence of this soft is GPLv2 .. i don't know what you really mean ^^
<sebner> paissad: you can't ship binaries (.dll) without source. I'm wondering if you even testbuilt it because sunjava is not present anymore in lucid
<paissad> jcfp, are talking about this http://revu.ubuntuwire.com/report.py/legal?upid=7743 ?
<jcfp> paissad: see sebner's comment. I'm talking about the link to revu you posted 43 minutes ago
<paissad> sebner, i've tested the package in karmic & jaunty & debian ... not lucid ... i mentioned lucid because it's said that other distrib are not accepted anylonger
<sebner> paissad: yeah, you only can upload to the current -devel version which is lucid and I doubt your package will build there
<paissad> sebner, though i have to test it in lucid ? ..
<paissad> why would that not work ?
<sebner> paissad: Because sun-java is not available anymore. You have to test if it builds and run with openjdk
<paissad> sebner, ok
<ripps> Can someone carry through the bzr-gtk sync from sid? I added a debdiff to bug #521353 to update it dh7, it was giving me a bunch of problems with pbuilder, now it doesn't.
<ubottu> Launchpad bug 521353 in bzr-gtk "Sync bzr-gtk 0.97.0+bzr674-3 (universe) from Debian unstable (main)" [Medium,Triaged] https://launchpad.net/bugs/521353
<paissad> jcfp, btw, i built the software from the svn source, but i've removed windows binaries during clean target in the debian/rules file .. and the soft is licenced under GPLv2 .. what's wrong with that
<paissad> i'm just confused
<sebner> ripps: don't add any unecessary changes to Debian packages and especially not to syncs!
<sebner> paissad: you better create a get-orig-source rule which removes the binaries beforehand
<ari-tczew> sebner: have you got expierence in fix FTBFS causing by gcc, right?
<sebner> ari-tczew: O_o, not really. What's the issue
<sebner> ?
<geser> ripps: does bzr-gtk from Debian unstable build for you in lucid? (see also Debian bug #569415)
<ubottu> Debian bug 569415 in src:bzr-gtk "bzr-gtk: FTBFS: cp: cannot stat `debian/tmp/usr/lib/nautilus/extensions-2.0': No such file or directory" [Serious,Open] http://bugs.debian.org/569415
<paissad> sebner, yeah, how can i build the orig.tar.gz source without windows binaries files ? ... i just ran dh_make -f ../$pakage$version.tar.gz && debuild -uc -us --lintian-opts -iIEvm -pedantic --color always
<ari-tczew> sebner: I worked on merge libjdic-java and it got ftbfs, clean debian revision too got ftbfs
<ripps> geser: yeah, that's one of the things I fixed in the debdiff
<sebner> paissad: you better take a look at the Packaging Guide
<ari-tczew> sebner: I can open new bug and include my merge-propose, but it's need ftbfs fix
<paissad> sebner, i did mate  ;)
<paissad> sebner, i wil do it manually ^^
<paissad> will*
<sebner> paissad: that's not allowed afaik
<sebner> ari-tczew: hmmm, pastebin the error
<paissad> sebner, hmm well, if i download from the svn source .. knowing that that source contains windows binaries ( binaries i absolutely don't need for the packaging) ... if i'm not allowed to remove those binaries before compressing the source  .... what must i do then ?
<ari-tczew> what's the command for get pbuilder buildlog, verbose?
<ari-tczew> I'm building from .dsc
<sebner> paissad: well, you are allowed to remove it but with a get-orig-source so every person that fetches the sources through your package gets the same results
<sebner> ari-tczew: --logfile
<paissad> sebner, ok, i will remove those "fucking" files before compressing the source (tar+gzip) and after that i run dh_make and so on
<paissad> are we ok ?
<sebner> paissad: you can do that but you still need a get-orig-source rule because you are removing stuff for *this* upload *manually*
<paissad> sebner, oh, i did not know about this "get-orig-source" rule ... lmgt
<ari-tczew> sebner: http://s1.plikos.pl/11e3/f30af66d18095996ca4d3c886ed16287/buildlog.txt
<sebner> ari-tczew: next time please use pastebin ;)
<ripps> geser: I just emailed a version of the debdiff to the debian bug. I'm not very familiar with debian's email interface, how long until it the page updates with the email?
<geser> a few minutes, you usually get a confirmation mail when your mail got processed
<ari-tczew> sebner: pastebin hangs my web browser
<ari-tczew> this is a large file
<sebner> ari-tczew: well, not everyone wants to download something from a polish upload service ;) You might have more luck asking in #ubuntu-mozillateam as it seems this is a xulrunner issue
<paissad> i don't see any info about get-orig-source  rule in maintainer guide (debian|ubuntu) .. may someone help me ?
<jcfp> paissad: get-orig-source is a target in debian/rules that automates the cleanup so that anyone can simply run ./debian/rules get-orig-source and get a clean tarball free of unwanted binaries (jar, exe, dll, etc.).
<paissad> ok ... thanks
<paissad> jcfp, and i guess that target should be called before clean target !
<sebner> paissad: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
<sebner> paissad: it's not needed to remove the binaries in the clean target when they are not present (get-orig-source gives you a clean tarball)
<paissad> ok
<bdrung> ari-tczew: pong
<ari-tczew> bdrung: about debian/changelog in fakesync... so get changelog file from Debian and add dch -i "Fake sync due to..." right?
<bdrung> ari-tczew: yes
<ari-tczew> ok, so fakesyncs are waiting for sponsor :D
<sebner> ari-tczew: mind our new policy :P (See -devel ML)
<ari-tczew> sebner: -devel ML?
<sebner> ari-tczew: ubuntu-devel Mailinglist. We use now XfacesyncY in the changelog
<ari-tczew> wrrrrrr
<ari-tczew> so I need to change all debdiffs
<sebner> ari-tczew: well, it's not that fix so just go with your debdiffs for now ;D
<sebner> ari-tczew: It will be a requirement at some point in the future though
<ari-tczew> sebner: stricte start oficial using -XfakesyncY with new development cycle? not now?
<sebner> ari-tczew: well, yesterday there was a dicussion if we should use XubuntuY or XbuildY and the think the most appropriate it XfakesyncY. Don't know when we'll really use it. As FF nears and not that many syncs/fakesyncs will occur you might be right with lucid+1
<sebner> ari-tczew: there is still some discussion going on so you might want to ask persia as he is the mastermind behind this :D
<ari-tczew> sebner: I know about yesterday discussion, because I just started discussion :-]
<sebner> heh
<sebner> ari-tczew: yeah but it's now on the ML as well
<ari-tczew> what is "lucid+1" ?
<sebner> ari-tczew: Ubuntu 10.10 ;)
<ari-tczew> sebner: so do I need to refresh all my debdiffs, or not?
<sebner> ari-tczew: Do as you wish as nothing is official yet
<ari-tczew> so I don't change debdiffs, just waiting for sponsors
<bdrung> sebner: we had here a very long discussion about fakesyncs yesterday (you can read the log if you have an hour)
<sebner> bdrung: I participated too ;)
<bdrung> ups :)
<sebner> bdrung: as it's on the ML to gather some more feedback I was just not sure how official it is now
<bdrung> sebner: i think we should wait some time (one or two weak). if there are no vetos, it's official. then we should create the wiki documentation.
<sebner> bdrung: aye
<bdrung> sebner: a response from an archive-admin would be good (because they have to modify their scripts)
<sebner> bdrung: pitti agreed already
<bdrung> k
<bdrung> sebner: so XfakesyncY wouldn't do any harm (compared to using XubuntuY)?
<geser> sebner: give it some more time. at least the next week so the other devs have time to read it
<sebner> geser: sure
<sebner> bdrung: I guess
<sebner> geser: bdrung but fakesync won't get autosynced if I understood it right?
<geser> you probably need to look into the scripts to know for sure
<bdrung> geser: where do i find the script?
<geser> bdrung: some parts are in https://code.edge.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk and some in LP itself
<sebner> geser: I just read it and I guessed but I'm not 100% sure
<sebner> geser: oh, I thought you spoke about persias proposal. Nothing is implemented yet?!
<geser> sebner: the proposal intend to autosync on new upstream versions and there wasn't enough time since yesterday to created patches for the existing code
<sebner> geser: so there are super cool features planned where you can tell the difference between new upstream and new debian version and work accordingly?
<bdrung> geser: i found nothing related in ubuntu-archive-tools
<geser> bdrung: I don't have an clear overview how the autosync work in detail myself yet
<geser> bdrung: some scripts are in scripts/ftpmaster-tools in the LP code. those are the server-side parts from the archive admin scripts
<bdrung> geser: can i branch this code somewhere?
<bdrung> geser: with the XfakesyncY in the name, the sync script could sync in all cases.
<sebner> bdrung: only in case of new upstream :P
<geser> bdrung: https://dev.launchpad.net/Getting
<bdrung> sebner: no. in the other case the script can do something similar to my fakesync script (get debian source, extract it, replace the source tarball, dch -i "fakesync")
<sebner> bdrung: interesting approach
<geser> bdrung: if you only want to look at the code branch lp:launchpad/devel
<geser> bdrung: sync-source.py from http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/files/head%3A/scripts/ftpmaster-tools/ might be a good start for looking
<gusnan> What are the reasons for a package to dissappear from the list at revu.ubuntuwire.com ?
<ari-tczew> bdrung: could you take a look @ http://pastebin.ubuntu.com/376172/ is it possible to causing ftbfs by gcc ?
<bdrung> ari-tczew: it's not the fault of gcc. The problem starts with "No such file or directory". a package could be missing or a parameter is not set correctly.
<geser> ari-tczew: unlikely, see like 1550+: gtkmozembed_internal.h:25:27: error: nsIWebBrowser.h: No such file or directory
<iulian> gusnan: Does it show up on the front page?
<iulian> gusnan: What is the name of the package you're interested in?
<gusnan> iulian, no - it does show up if I have a "direct" link though.
<gusnan> It my own package "sciteproj"
<geser> ari-tczew: looking at line 1546 those absolute paths for -include and -I look suspicious
<gusnan> it's there at /p/sciteproj , but not in the list on the front-page.
<iulian> Ah.
<iulian> Hmm.
<iulian> gusnan: It seems that the package has been archived.  I've just unarchived it and should show up on the front page.
<gusnan> thanks!
<ari-tczew> I don't have time for waste time to fix this FTBFS, I can open a new bug and include my merge-propose diff
<ari-tczew> maybe someone want to take this one and fix FTBFS
<ari-tczew> bug 521712
<ubottu> Launchpad bug 521712 in libjdic-java "Merge libjdic-java 0.9.5-6 (multiverse) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/521712
<directhex> main -> multiverse? that sounds odd
<geser> libjdic-java in in universe since jaunty
<ari-tczew> if it's disturb you, feel free to change it
<persia> ari-tczew: Rather, please explain why it should now be in multiverse
<ari-tczew> persia: omfg, I don't want to move into multiverse, just I always look @ Component: multiverse
<ari-tczew> https://launchpad.net/ubuntu/+source/libjdic-java
<ari-tczew> enough?
<persia> That's a bug in launchpad (because it's not in multiverse).  Please report it.
<geser> persia: see the footnote
<ari-tczew> persia: regards for you, because it's not me find this bug and I can't describe what about this issue
<persia> geser: Where is that encoded within the package though?
<persia> geser: Or is it just stuck until the next upload?
<persia> ari-tczew: Fair enough.  Do you understand why it's a bug?
<geser> as far as I understand it the "package information" is the data of the last upload, not the current one (e.g. if the page gets promoted/demoted since then)
<geser> s/page/package/
<persia> geser: That makes sense, but LP *knows* the current value.  Oh well, still buggy :)
<geser> the last libjdic-java upload went to multiverse and the package got moved to universe after that
<persia> RIght.
<geser> yes, the page itself is correct because of the footnote, but not very useful in that form
<ari-tczew> persia: how do you checking package component?
<geser> ari-tczew: I look at the table on the page you mentioned
<persia> ari-tczew: apt-cache show ${PACKAGE} | grep ^Section: provides a hint for a current apt-cache.  rmadison provides a hint for other environments.
<ari-tczew> ah, I SEE
<ari-tczew> persia: could you report bug to launchpad? because you found it
<persia> ari-tczew: doing so now
<ari-tczew> persia: what about bug 294593 ? do you will work on it?
<ubottu> Launchpad bug 294593 in lash "Please merge lash 0.5.4-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/294593
<persia> I'll try it again.  It completely failed the last few times I tried.
<ari-tczew> would be nice
<persia> ari-tczew: It's causing some bug?
<ari-tczew> persia: probably not, just I want to clean up repositories before FFe
<persia> This merge isn't affected by FF.
<persia> No new upstream.  No significant changes in Debian.
<ari-tczew> persia: so is it can be merged while FFe? without any special reasons?
<persia> ari-tczew: Well, check the changelogs in Ubuntu and Debian, and check the differences.  I don't see anything (and I strongly dislike trying to merge around tarball-in-tarball)
<ari-tczew> persia: but what about fakesyncs? can I prepare debdiff while FFe?
<bdrung> ari-tczew: bug 499329 needs an merge and maybe a refresh to use the latest mozilla-devscripts features
<ubottu> Launchpad bug 499329 in foxyproxy "Merge foxyproxy 2.18.1-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/499329
<ari-tczew> bdrung: so this is a job for dhillon-v10
<ari-tczew> wrrrr, java in firefox 3.6 doesn't work? I can't play on-line java games.
<ari-tczew> [lucid]
<geser> ari-tczew: less distraction for you :)
<ari-tczew> geser: what do you think about?
<l3on> Hi all.. someone of you can confirm me that this bug is invalid -> https://bugs.edge.launchpad.net/ubuntu/+source/sdl-image1.2/+bug/515105 ?
<ubottu> Ubuntu bug 515105 in sdl-image1.2 "sudo apt-get install vlc vlc-plugin-pulse mozilla-plugin-vlc, error 'libsdl_image1.2'" [Undecided,New]
<persia> l3on: I don't think it's invalid: rather I think that some additional Conflicts/Replaces work needs be done.  (and #ubuntu-bugs is often a good place to ask this class of question)
<l3on> thanks persia
<l3on> problem is that there is no package called sdl-image-devel which conflicts in the bug report.
<persia> libsdl-image1.2-dev
<l3on> Ok, but:
<l3on> Title: package libsdl-image1.2-dev (not installed) failed to install/upgrade: trying to overwrite '/usr/include/SDL/SDL_image.h', which is also in package sdl-image-devel 0:1.2.10-2
<persia> l3on: Are we looking at the same bug?  I see "trying to overwrite '/usr/lib/libSDL_image-1.2.so.0', which is also in package sdl-image 0:1.2.10-2"
<persia> l3on: Oh, I see it now different place.  Yeah, I think the bug is invalid, but it might be exposing also a valid bug :)
<l3on> anyway: there is no package called sdl-image in ubutnu -> http://packages.ubuntu.com/search?keywords=sdl-image
<persia> apt-cache search sdl-image shows me two packages.
<l3on> of course.. me too.
<l3on> libsdl-image1.2 - image loading library for Simple DirectMedia Layer 1.2
<l3on> libsdl-image1.2-dev - development files for SDL 1.2 image loading libray
<l3on> I think that that package cames from a Third Party Repository.. or something similiar.
<persia> http://conflictchecker.ubuntu.com/possible-conflicts/karmic/universe.txt shows a potential issue with libsdl1.2-pulseaudio, but I think that's different.
<persia> You might check other releases, but it may be entirely invalid.
<persia> (and we really ought to find time to clean up one of the releases one day on that checker)
<l3on> A lot of weeks ago I was writing a py script that through launchpad-lib went in LP and marked a lot of old bugs of LTS as Invalid... but I did not find free time to finish the work. However, script could be potentially dangerous...
<l3on> But it could be a fast way to do what you speaking about.. (If I understand what do you mean... :P)
<persia> I think maybe I wasn't clear.
<persia> The conflictchecker is currently producing about 9MB of data about undeclared conflicts in packages.
<persia> Adding the appropriate Conflicts/Replaces entries in the packages would be good.
<persia> It would be nice to have a release that was known not to have any valid conflict/replace bugs in the upgrade path.
<persia> (but it's a *massive* volume of work)
<l3on> Ahh.. Ok. :))
<paissad> do you know a package that uses  get-orig-source in his debian/rules file so that i can have real examples ?
<directhex> paissad, most mono-flavoured packages do
<asbin> bdrung: Thank you for your comment in enna package, I've just uploaded a new version.
<bdrung> asbin: drop quilt from b-d (you do not need it)
<asbin> bdrung: really ? my package would'nt build with pbuilder if I remove quilt b-d !
<bdrung> asbin: dpkg-source applies the patches (so you do not have to b-d on it)
<asbin> bdrung: oh i've added a "include /usr/share/cdbs/1/rules/patchsys-quilt.mk" in the debian/rules file ...
<bdrung> asbin: drop this too. ;)
<asbin> bdrung: of course ;)
<AnAnt> Hello, regarding sl-modem-source, it currently Recommends: dkms, linux-headers-2.6-486 | linux-headers-generic | linux-headers
<AnAnt> shouldn't it rather Depend on linux-headers-2.6-486 | linux-headers-generic | linux-headers ?
<oojah> paissad: http://revu.ubuntuwire.com/p/sqlite3-pcre has get-orig-source for downloading from a git repo. It's still awaiting review though, so might not be the best example.
<asbin> bdrung: ok, package re-uploaded :)
<bdrung> asbin: debian/control has trailing whitespaces
<bdrung> asbin: find another ubuntu developer, who ACK your package, and i will upload it
<didrocks> fabrice_sp: hey. please, check when branches are maintained into bzr. You last anjuta's sponsored wasn't pushed into the desktop team branch and I accidentely removed the -0ubuntu2 changes
<persia> AnAnt: Depends is probably more appropriate, as the modules won't build without them.
<didrocks> fabrice_sp: debcheckout warns you when there is a Vcs-Bzr tag :)
<persia> didrocks: The issue is that the warning is useless for 90% of packages, as it applies to some Debian source.
<persia> didrocks: Perhaps it's worth trying to get some additional tag set somehow that indicates when a package has special Ubuntu handling?
<didrocks> persia: right, I think that we should maybe patch that
<didrocks> persia: I think it worth a try as this error is more than common
<persia> How though?  We can't even rely on launchpad being authoritative, as there are potentially packages that aren't specially handled in Ubuntu that use launchpad.
<persia> didrocks: Also, shouldn't the desktop team migrate to using the new distributed development branches :)
<didrocks> persia: I know, the migration will be slow, as we wait for the merge-upstream to be 100% working for big packages like nautilus ;) (we already try that on package where upstream is dx team)
<persia> Yeah.  I wouldn't expect it to happen overnight, and there's still plenty of *native* packages that have separate bzr trunks.
<persia> But aside from that, how do you think we might handle better tracking of when a VCS is being used?
<randomaction> Why isn't Maintainer: field set to ubuntu-desktop for anjuta?
<persia> Should debcheckout perhaps warn if there is an upload?
<persia> That's another good question: it's definitely worth mangling the maintainer for these special cases.
<didrocks> persia: I agree, the Maintainer field is quite random today. And maybe debcheckout can warn if current revision in branch (not UNRELEASED) != last uploaded version?
<persia> didrocks: Yeah, I think debcheckout is the right place, because that catches also cases where Vcs-* is in Debian and there is Ubuntu variation.  apt-get's warning is probably good as-is.
<persia> (and patching debcheckout also means we don't need to invent new headers, etc.)
<didrocks> persia: totally agree. Not the time to work on it before FF, but can be easy to do after that :)
<persia> It's a new feature: you'd need an exception to do it after that.
<persia> I think it mostly hits the Desktop team, as I don't think any other teams have quite such an advanced, non-distributed-development VCS workflow.
<didrocks> persia: right, but even if the change is hanging around on my computer until next release, that's not so urgent afterwards
<didrocks> yeah, mostly
<persia> True.  I'm just thinking of time spent fixing up these issues vs. time spent patching :)
<persia> I think I see a complaint from the desktop team at least once a week.
<didrocks> I'll try to have a look on Monday (it seems I have said that too many time in the last 48h, will see if it's possible) :)
<didrocks> but debcheckout is in perl, right?
<persia> heh.  Good luck :)  Maybe you can also get someone else to do it.
<persia> Yes, perl.
<didrocks> well, I have limited knowledge in it, so, maybe, we can call for an opened opportunity :)
<persia> Declaring an opportunity sounds like a good plan.  Seems there are lots of folks who opportunistically fiddle with desktop stuff: some might have a bit of time.
<didrocks> and no GNOME release next week, so, that can be an easy task to give
 * didrocks write down on a note
<persia> Indeed.
<AnAnt> persia: thanks
<persia> AnAnt: No, thank you for volunteering to get that package from the absolutely useless state in which it was for hardy into something that has become not only usable, but actually almost good.
<persia> (some of the reasons it's not yet "good" are unfortunately hardware limitations :( )
<AnAnt> persia: and lack of upstream development
<persia> Yeah.  Nobody seems to care anymore.
<AnAnt> persia: the current maintainers aren't developers, but they accept patches
<AnAnt> persia: the guys at linmodems.org are really doing their best
<AnAnt> persia: but the best they can give is limited to support
<persia> Indeed.  I think the issue is mostly that very few people still use them as modems (instead using other forms of network connectivity), and not enough people want telephony yet.
<AnAnt> another question, the first package in Recommends should be a real (not virtual) package, right ? ie Recommends: x | y | z, x must be a real package, right ?
<AnAnt> or that is only for Depends ?
<persia> For both.
<AnAnt> persia: btw, Rolf Leggewie also joined in for maintaining sl-modem lately
<persia> Cool!
<AnAnt> yeah
<BlackZ> somebody can review this package? http://revu.ubuntuwire.com/p/autotrash thanks
<jcfp> BlackZ: looking
<l3on> Someone could take a quick look at goobox in merges.ubuntu.com/universe.html ?
<l3on> why is not there uploader ?
<l3on> and why version is 2.0.0-5ubuntu1 if in lucid we have: 2.1.1-3?
<AnAnt> back to sl-modem-source, isn't linux-libc-dev enough ?
<persia> Does it not need kernel headers to build the kernel modules?
<AnAnt> yes,
<AnAnt> ok
<wrapster> how do i create a pkg from tar.gz
<wrapster> I always get this error.. "The directory name must be <package>-<version> for dh_make to work!
<wrapster> I cannot understand the directory name or you have an invalid directory name!
<wrapster> "
<geser> to which directory does the .tar.gz unpack?
<persia> wrapster: Trick 1: don't use dh_make :)
<persia> wrapster: Just unpack the upstream tarball, and create a debian/ directory in there, and create your changelog, copyright, control, and rules files.
<Rhonda> fabrice_sp: What I said was that I didn't note down the LP bug with the category wish because actually it should be invalid, it has to be in there already â¦
<hyperair> persia: interestingly, i still can't create a package without dh_make. the only file i know how to completely rewrite is the rules and copyright files. i still don't really remember the changelog and control format fully.
<hyperair> heheh
<randomaction> hyperair: dch --create creates changelog
<jcfp> BlackZ: commented
<hyperair> randomaction: ah it does? cool.
<hyperair> randomaction: that doesn't help me with my debian/control issue though..
<hyperair> randomaction: i just don't seem to remember the required fields.
<randomaction> dh_make is really outdated
<hyperair> i agree.
<hyperair> i just dh_make, remove most of the .ex/.EX files
<hyperair> make that all
<hyperair> and debian/rules
<hyperair> and copyright
<hyperair> then i rewrite those two
<hyperair> and the watch file also
<james_w> mkdir debian/; dh_make --addmissing; rm debian/*.ex debian/*.EX'; is another way to start
<hyperair> hmm
<persia> hyperair: One should always use dch to create the changelog.
<asbin> persia: Hi ! You already have a look to enna package http://revu.ubuntuwire.com/p/enna , bdrung has made some comments and I've follow his recommendations, can you please have look at it ? Thank you !
<hyperair> persia: why?
<persia> hyperair: And control is just RFC2822-format based on the policy.
<persia> hyperair: Because the format is fussy :)
<hyperair> persia: yes, i know, but i'd have to go dig out the policy to figure out the fields required
<persia> hyperair: sensible-browser /usr/share/doc/debian-policy/policy.html/ch-controlfields.html
<hyperair> persia: then i'd have to have a browser open.
<persia> hyperair: Well, one could use an ncurses browser.  Alternately, one could use /usr/share/doc/ubuntu-policy/policy.txt.gz
<hyperair> persia: all those alternatives are no better than just getting dh_make to give me a skeleton control file
<persia> There are also a couple different tools that automatically generate this for python packages.  Having a more general solution would be nice.
<persia> hyperair: I guess.  I'm just unhappy enough with the rest of what dh_make produces (and needing to answer the same 25 questions related to how it's completely wrong) that I advise against using it at all.
<hyperair> persia: heh well, i suppose dh_make is not good for beginners learning to package by the standards
<BlackZ> jcfp: thanks, I'm fixing the problems/errors
<persia> I don't think so, and I think that once someone isn't a beginner, it's just as easy to just type Source, Maintainer, Section, Priority, Build-Depends, Standards-Version, Homepage, Package, Architecture, Depends, Description in a text file :)
 * hyperair grumbles
<hyperair> that's a long list and i've a bad memory, damnit.
<persia> That's why there's the files I referenced :)
<l3on>  -> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<l3on> what could be the cause ?
<persia> l3on: That usually comes from not running update-maintainer when applying other patches in a package not otherwise changed in Ubuntu.
<hyperair> persia: but that requires me to open up a browser on my machine that is generally running out of memory already.
<persia> hyperair: Or a text viewer :)
<l3on> persia: -> Ubuntu Developers is already set as maintainer.
<hyperair> right
<persia> hyperair: Or just take a note of the 11 fields, and create a template file :)
<persia> l3on: with which email address?
<hyperair> dh_make sounds simpler to use.
<l3on> persia: cat debian/control.in|grep maint
<l3on> Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<l3on> XSBC-Original-Maintainer: Jonas Smedegaard <dr@jones.dk>
<l3on> but also there is a debian/control file with Mainteiner set to Jonas Smedegaard <dr@jones.dk>
<persia> l3on: Probably related to debian/control.in -> debian/control generation.
 * didrocks fabrice_sp_ hey. please, check when branches are maintained into bzr. You last anjuta's sponsored wasn't pushed into the desktop team branch and I accidentely removed the -0ubuntu2 changes
<persia> didrocks: Didn't you say that before?
<l3on> persia: have I try to modify manually debian/control ?
<didrocks> (fabrice_sp_: seems you was disconnected)
<didrocks> persia: /msg /me :/
<askhl_> I'm creating a data package containing files used by another package.  Where would be a good/recommended place to install these files?
<askhl_> /usr/share/<packagename>?
<l3on> Ok, persia I received this:
<l3on> E: moin source: debian-rules-automatically-updates-control line 25
<l3on> so, I edit rules:25
<persia> Right.  That's a bug in the package.
<l3on>   DEB_AUTO_UPDATE_DEBIAN_CONTROL = yes
<persia> But you didn't then manually update the control file.
<l3on> to
<l3on>    DEB_AUTO_UPDATE_DEBIAN_CONTROL = no
<l3on> the part of code is:
<l3on> DEB_PYTHON_SYSTEM = pysupport
<l3on> ifneq (,$(DEB_MAINTAINER_MODE))
<l3on>   # Enable stuff not policy compliant (eg. unsuitable for build daemons)
<l3on>   DEB_COPYRIGHT_CHECK_STRICT = yes
<l3on>   DEB_AUTO_UPDATE_DEBIAN_CONTROL = no
<l3on> is it the right way ?
<persia> I usually just leave E: debian-rules-automatically-updates-control alone and try to work around it.
<persia> Worth filing a bug in Debian, but painful to try to fix (and maintain) as an Ubuntu delta.
<l3on> ok... thanks for suggestions. :)
<askhl_> I would like to write a package which just contains data (used by a different package).  I know that you can install docs to the proper location by just writing the filenames in debian/docs.  What approximately should I do to install other data into some appropriate location?
<askhl_> I'm using dh_make to get a makefile with targets such as dh_installdirs.  Is this the one I want?
<persia> No.
<persia> You want to use dh_install
 * persia digs up a URL for a slightly-outdated class on the subject
<persia> https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling
<askhl_> Thanks a lot, persia
<persia> askhl_: The example is for a shell script, but the same model applies to anything that just needs to copy stuff somewhere.
<askhl_> Great.  This is much simpler than what I was doing
<persia> yeah.  dh_make is a handy tool to use to teach the art of packaging, but not so useful if just trying to get something packaged.
<fabrice_sp_> Rhonda, sync of pgadmin3 requested ;-)
<fabrice_sp_> (too late)
<asbin> Hi everybody ! is there ubuntu developers here ? I'm looking for reviewers for a package ...
<asbin> Here it is : http://revu.ubuntuwire.com/p/enna
<didrocks> persia: I need your light on a FTBFS on amd64 that I don't get on i386: http://launchpadlibrarian.net/39193477/buildlog_ubuntu-lucid-amd64.anjuta_2%3A2.29.90.0-0ubuntu2_FAILEDTOBUILD.txt.gz
<didrocks> persia: libsvn-dev dep is pretty simple: Depends: libsvn1 (= ${binary:Version}), libapr1-dev, libaprutil1-dev
<kklimonda> hey - could some motu take a look at bug 508225?
<ubottu> Launchpad bug 508225 in picard "Please update picard to 0.12.1" [Undecided,Confirmed] https://launchpad.net/bugs/508225
<didrocks> persia: and the bin package is available on amd64 too if you look at rmadison libaprutil1-dev
<persia> didrocks: attempting to replicate locally
<didrocks> persia: oh sweet if you have an amd64 machine :)
<persia> didrocks: This sort of thing usually comes from arch-skew :)
<didrocks> persia: I'm guessing that, but if I can have a confirmation first ;)
 * persia has 5 different chroots of three different architectures performing apt operations, and is coming to really appreciate the new rng-tools being able to cope.
<geser> didrocks: see #ubuntu-devel, mysql-cluster-7.0 broke libmysqlclient-dev on amd64
<geser> bug 521815
<ubottu> Launchpad bug 521815 in mysql-cluster-7.0 "breaks all builds requiring libmysqlclient-dev" [Critical,New] https://launchpad.net/bugs/521815
<persia> geser: Would that kill libapr1-dev?
<geser> yes
<persia> I didn't know it was that widespread.  Makes sense.
<didrocks> geser: oh right, thanks for the notice :)
<geser> libmysqlclient-dev is uninstallable on amd64
<didrocks> ok so, let's subscribe to the bug and wait for retrying a rebuild once fixed
<randomaction> I totally love comment #1 in that bug :)
<SoftwareExplorer> I'm trying to package a single .c file that only came with instructions on what command to run to compile it and then copy it into /usr/lib/gtk-2.0/modules/. I had to make a makefile and package it. Here's the problem:When I try to build it with pbuilder, the resulting deb doesn't have the file that I'm trying to install. So, what am I doing wrong? The file for this are at http://ubuntuforums.org/showthread.php?t=1406517 
<oojah> SoftwareExplorer: If it helps, compare against http://revu.ubuntuwire.com/p/sqlite3-pcre because that does exactly the same thing.
<oojah> (if anybody wants to review/advocate sqlite3-pcre that'd be great, thanks!)
<asbin> persia: Hi ! You already have a look to enna package http://revu.ubuntuwire.com/p/enna , can you please have a look at it ? Thank you !
<SoftwareExplorer> oojah: Ok, I'll look at it and see if it give me an idea of what i'm doing wrong.
<SoftwareExplorer> By the way, sudo make install does install it on my computer
<persia> SoftwareExplorer: Also check your build log: a common error is that the file ends up being installed to the build environment rather than into the package.
<SoftwareExplorer> persia: Where would a pbuilder build log be?
<persia> SoftwareExplorer: No idea.  I don't use pbuilder.
<persia> (or I used it once, but that was part of an effort to not need to use it at all)
<oojah> SoftwareExplorer: Make sure it's installing to DESTDIR as well.
<SoftwareExplorer> oojah: I think my makefile is doing that, but would you look at it and tell me if I'm doing it correctly?
<oojah> Just give me a moment.
<SoftwareExplorer> oojah: That's fine. I should go eat Lunch, so if I don't respond for a while, you know why. Thanks.
<oojah> SoftwareExplorer: Looks ok to me. I'd try changing the PREFIX?=usr/ line to just PREFIX=usr/ in case something funny is going on there. You can always override with "make PREFIX=blah" anyway.
<oojah> Also, fwiw, you'd normally define prefix with a slash (/) at the start of the path and not at the end.
<oojah> The install location would then be ${DESTDIR}${PREFIX}/lib/gtk-2.0/modules/librgba.so
<oojah> SoftwareExplorer: And for the package in general, you ought to be using patches to add the Makefile.
<rmunn> Any MOTUs interested in being a second advocate for http://revu.ubuntuwire.com/p/python-nltk today? I'd like to get it into Lucid before feature freeze, and I have one advocate already, just need a second one.
<rmunn> NLTK is a Python library for natural language processing, and O'Reilly recently published a book about it (http://oreilly.com/catalog/9780596516499). It would be nice to be able to "apt-get install python-nltk" in Lucid. Please help. :-)
<rmunn> (Full disclosure: I was a technical reviewer on that book.)
<SoftwareExplorer> oojah: Ok, thanks.
<bdrung> asbin: found another thing
<asbin> bdrung: Arghhh
<bdrung> asbin: a cyclic dependency between enna and enna-theme.
<asbin> bdrung: what's wrong with that ?
<bdrung> asbin: cyclic dependencies causes problems. it's enough if enna depends on enna-theme.
<asbin> bdrung: ok no problem, I can remove it
<asbin> bdrung: beter if enna-theme suggest or recommend enna ?
<bdrung> asbin: you can suggest it, but i wouldn't do it
<asbin> bdrung: OK, you're the boss ;)
<dooooomi> hi, i'm trying to use quilt for a package. https://wiki.ubuntu.com/README.sourceHowTo says: "instead of including a README.source file like these you can just point to the one provided within the /usr/share/doc/* tree". what is "point to" supposed to mean?
<bdrung> asbin: yeah, muharhar.
<bdrung> ;)
<asbin> ;)
<asbin> bdrung: OK I'm uploading a new one
<asbin> is there a way to not upload the source file each time I have to upload a new version of a package on revu ?
<asbin> (the source file for enna is about 20MB ...)
<bdrung> asbin: try debuild -S -sd
<asbin> I will, thanks !
<bdrung> whom to ask, when revu has a bug (i am still not a ubuntu developer in revu)?
<persia> bdrung: Look for a REVU hacker.
<persia> bdrung: but I might be able to help in some limited ways: what sort of bug?
<bdrung> persia: who are the revu hacker? you?
<persia> No.
 * persia is only a revu admin
<bdrung> persia: i am still not a ubuntu developer in revu
<persia> Oh, I can fix that :)
<persia> https://launchpad.net/~revu-hackers
<bdrung> persia: i created the revu account when i was ubuntu contributor
<persia> It's supposed to update, but it's buggy sometimes.
 * persia doesn't quite understand why
<persia> Anyway, your permissions have been manually changed.
<persia> If you feel like fixing the bug, we enter REVU hacking season in about 3 days :)
<bdrung> persia: i fixed enough for today
<persia> heh :)
<bdrung> persia: thanks for fixing
<bdrung> asbin: you have your first advocate now.
<asbin> bdrung: no way ! Thank you !! :)
<bdrung> np
<bdrung> asbin: find another advocate and find a debian mentor
<asbin> great ! :)
<asbin> is there a bug in revu with the activity graph ?
<persia> asbin: Do you have an example package that may be affected?
 * asbin need a second advocate for enna package http://revu.ubuntuwire.com/p/enna please !
<asbin> persia: enna for example : http://revu.ubuntuwire.com/p/enna
<persia> Yeah, that does look wrong.
<asbin> persia: bug maybe I don't understand what the graph wants to show ??
<persia> asbin: I think it's supposed to show number of comments/uploads/advocations on a daily basis.
<persia> But I could be wrong.
 * persia may be a revu admin, but mostly just cares about having somewhere to grab .dsc files and comment
<asbin> found a package where it looks good : http://revu.ubuntuwire.com/p/smartcam
<persia> Well, that doesn't show the uploads.
<SoftwareExplorer> oojah: I tried you changes to the makefile but it didn't fix it. I had it do install -D librgba.so ${DESTDIR}${PREFIX}/lib/gtk-2.0/modules/librgba.so&&ls ${DESTDIR}${PREFIX}/lib/gtk-2.0/modules/ and when it run the ls part said librgba.so So it seems to have installed to the right place. I haven't tried adding the makefile as a patch because I figure I'll get it working and then make changes. (unless you think adding the 
<bdrung> SoftwareExplorer: why do you use ${...} instead of $(...)?
<SoftwareExplorer> bdrung: Is there an important difference? I though they both represented a variable. I was using $() earlier, but someone who was helping me with makefile used ${} when they were explaining something, so that's what I used
<bdrung> SoftwareExplorer: i checked the make documentation: "either `$(foo)' or `${foo}' is a valid reference to the variable foo.". so it's up to you.
<SoftwareExplorer> bdrung: oh, ok
<dooooomi> should new packages in REVU use standards-version 3.8.3 or 3.8.4? no matter which one i use, either my own or REVU's lintian will complain...
<sebner> dooooomi: 3.8.4
<dooooomi> sebner: thanks, i'll just ignore REVU's warning then...
<sebner> dooooomi: yeah, it's a bit outdated, no worries
<dooooomi> a new version of gtklick is ready to be reviewed: http://revu.ubuntuwire.com/p/gtklick
<asbin> dooooomi: you can install new version of lintian from here https://launchpad.net/~bdrung/+archive/backports/+packages?field.name_filter=lintian&field.status_filter=published&field.series_filter=karmic
<dooooomi> asbin: isn't it actually REVU that needs to install a newer version?
<asbin> dooooomi: yes REVU server needs to be updated too ...
#ubuntu-motu 2011-02-07
<virusuy> hi all
<maco> interesting to learn that the gnome people even get rid of theming features though!
<maco> whoops
<maco> that was sposed to be in a PM and was gtk engine murrine dropping scrollbar colour settings
<highvoltage> so if you switched gtk theme you can still change scrollbar colours right?
<highvoltage> and aren't you supposed to be american? :)
<maco> highvoltage: just because i was born here doesn't mean i have to spell like a heathen
<maco> except "tire," because "tyre" just looks silly
<maco> highvoltage: i said "lorry" when talking to an english guy the other day and the americans standing next to us jumped! it amused me
<maco> i told them i codeswitch and if there's an english person, they trump on whether to use english-english or american-english
<StevenK> Tyre does not look silly!
<StevenK> maco: You fully switch? For example, 'faucet' -> 'tap'; 'diaper' -> 'nappy' ?
<maco> StevenK: those words tend not to come up so much, but i did ask about all the prams when we went to dinner during UDS
<maco> all the words where i know they say something else, i swap out
<maco> StevenK: and btw, we say tap and nappy here too sometimes.  i mean "tap water" is colloquial.  nappy is more used when talking to a child though
<maco> its considered baby talk
<StevenK> maco: Don't tempt me to feel insulted :-)
<virusuy> where can i find an application who needs to be  packaged ?
<maco> search for needs-packaging on bugs.launchpad.net/ubuntu/+bugs
<virusuy> maco: ok! thanks ! and after create de package what i have to do ?
<maco> virusuy: upload all the pieces of the source package (listed in the .dsc file, including the .dsc) to the bug
<virusuy> maco: and somewone will check it , right ?
<maco> virusuy: oh actually wait no. thats for new releases of old packages. sorry, upload it to revu
<maco> !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
<virusuy> maco: cool! thanks
<crabbytag> virusuy: if a package needs packaging, send it up to Debian as well
<crabbytag> virusuy: you should file an ITP up there, if you plan on doing the work anyway :)
<crabbytag> virusuy: after it's in top-notch shape, send to debain-mentors and close out the Ubuntu ITP as well as the Debian ITP
<crabbytag> virusuy: since we pull from Debian automatically
<virusuy> and ubuntu does just a "sync" from Debian, am i right ?
<crabbytag> virusuy: you are
<virusuy> crabbytag: cool, actually i cannot find a app to package, can you recommend me one? a easy one :-P
<crabbytag> virusuy: check for RFP ( Request for Packaging ) bugs in Debian, I also think pabs ( Paul Wise ) has a list of cool software
<crabbytag> virusuy: if I had something nifty I liked, I'd just do it myself ;)
<virusuy> crabbytag: ok! i'll look in debian
<crabbytag> virusuy: thanks!
<virusuy> crabbytag: i found one .... work time!
<virusuy> what happend when i found a RFP , and when i go to website, they already have .deb files to download ?
<crabbytag> virusuy: you review what they have, and see if it's under a license you may use
<crabbytag> virusuy: if it is, you base your work on that, and if it's unfit, please start from scratch
<virusuy> crabbytag: ok
<crabbytag> virusuy: be sure to turn the RFP into an ITP :)
<crabbytag> virusuy: remember to always maintain copyright and clean up everything
<virusuy> paultag: oki doki :-D
<paultag> virusuy: let me know how it goes :)
<c2tarun> can anyone please explain me this error. http://paste.ubuntu.com/563707/
<StevenK> You don't have the Build-Depends installed
<c2tarun> StevenK: Ok, I dont want to install them in my system. but I can install them on my pbuilder-dist any way i can do that?
<StevenK> Then copy the source package directory inside a pbuilder chroot and run dpkg-buildpackage -S -uc -us from there
<micahg> c2tarun: BTW, you shouldn't be using build1 for a version unless it's a rebuild of a Debian package that was sync'd
<c2tarun> micahg: what should i use here then?
<micahg> c2tarun: 2.0.6-0ubuntu1
<c2tarun> micahg: but in changelog it was in build format, why so?
<micahg> c2tarun: that was just a rebuild of the Debian import, not something with Ubuntu changes
<c2tarun> micahg: ok
<micahg> c2tarun: did uscan/uupdate not set up the right changelog or did you manually set this up?
<chillywilly> W0000T!!!! Packers are the Superbowl Champs!!!!!!!
<c2tarun> micahg: no i downloaded the older version by apt-get and there was no watch file so i downloaded newer version from site
<micahg> c2tarun: there's a newer version on mentors.debian.net, maybe you want to coordinate with Debian on this update
<c2tarun> micahg: which file should I upload as a my public key for gpg key?
<micahg> c2tarun: there should be instructions on launchpad
<c2tarun> micahg: ya i just saw :) thanks
<c2tarun> micahg: there is a version on mentors.debian.net upper than version in our archives. How can I coordinate with them?
<micahg> c2tarun: you could try commenting on debian 609789 about the new version on mentors and the new version upstream, if that doesn't get a response by the end of the week, try e-mailing the mentors uploader and the maintainer in the same e-mail and try to coordinate
<ubottu> Debian bug 609789 in spyder "spyder: New upstream version" [Wishlist,Open] http://bugs.debian.org/609789
<dholbach> good morning
<simar> maco, if you don't mind can i ask you some help related to packaging .. i'm stuck at some point
<Bachstelze> simar: why not just ask here for everyone to see?
<mok0> inquisitive minds want to know
<simar> Bachstelze, no problem .. i mean that would be my pleasure..
<simar> i'm a bit new to packaging and is trying to resolve this one for dapper https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/209627
<ubottu> Ubuntu bug 209627 in lighttpd (Ubuntu Dapper) "lighttpd (security) ssl fix" [Low,In progress]
<simar> i know dapper is out now but that would be good practice for me
<simar> using hardy sources (where bug is resolved) i found that 92_CVE-2008-1531.dpatch contains the code to fix the patch but the problem is that i do not understand the format of dpatch and there is no manual available on Internet
<ubottu> The connection_state_machine function (connections.c) in lighttpd 1.4.19 and earlier, and 1.5.x before 1.5.0, allows remote attackers to cause a denial of service (active SSL connection loss) by triggering an SSL error, such as disconnecting before a download has finished, which causes all active SSL connections to be lost. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1531)
<simar> http://paste.ubuntu.com/563767/ contains the patch
<Bachstelze> simar: what's the problem ? The patch doesn't apply cleanly to the sources in DApper ?
<simar> Bachstelze, i know how to do that. can i use the same patch and use in dapper sources...
<Bachstelze> if it applies cleanly, yes
<simar> Bachstelze, ok .. i will try to apply.. it
<simar> Bachstelze, if you can tell me command that would make my half work done...
<simar> i have downloaded the sources of both hardy and dapper and '''dpkg-source -x''' them in separate folders..
<Bachstelze> simar: http://matrixhasu.altervista.org/index.php?view=use_dpatch
<Bachstelze> simar: basically, copy the patch from the hardy package in debian/patches of the dapper package and try to apply it
<Bachstelze> (don't forget to also edit debian/patches/00list to "enable" it)
<simar> Bachstelze, I think i got it..
<simar> i know that..
<simar> but after i do that .. then what to do ..
<Bachstelze> after that you update debian/changelog, create a package with debuild and see if it fixes the problem
<simar> how can i check whether it fixes the problem .. i mean should i use pbuilder or virtualbox?
<simar> Bachstelze,
<Bachstelze> simar: you try to reproduce the bug
<Bachstelze> pbuilder is just a tool to build the package, you can use it if you want, or just usez debuild
<Bachstelze> it's unimportant
<simar> Bachstelze, but i have maverick and i think the bug is already fixed here. I must have to have dapper to reproduce the bug.
<Bachstelze> you just need to build the package, no matter how
<Bachstelze> then yes, you can use virtualbox
<simar> Bachstelze, can i build the package in maverick..?? without any of its interference..
<simar> i mean it may get some build-depends from maverick .. may be??
<Bachstelze> simar: yes, you can createz a Dapper pbuilder
<Bachstelze> create*
<simar> Bachstelze, ok.. i mean i must build the package in dapper pbuilder and then use VB to test whether the new one removes the bug or not...
<Bachstelze> that would be one way to do it, yes
<simar> Bachstelze, but from where can i get dapper iso now..
<Bachstelze> http://old-releases.ubuntu.com/releases/
<simar> Bachstelze, thanks
<Bachstelze> actually
<Bachstelze> they are still on releases.ubuntu/com
<Bachstelze> .*
<simar> one last thing .. plz help me to install pbuilder for dapper?? or tell other easy way if you know one..
<Bachstelze> I think you can use pbuilder-dist for that
<simar> pbuilder-dist dapper
<simar> ??
<Bachstelze> not sure, I don't use it myself
<Bachstelze> I use this .pbuilderrc
<Bachstelze> https://wiki.ubuntu.com/PbuilderHowto#Multiple%20pbuilders
<Bachstelze> and env variables (DIST and ARCH)
<simar> Bachstelze, Thanks you very much. I hope now I can do it..
<drizt> hello!
<drizt>  renamed a package. I updating my old (installing before renaming) package with apt-get install but it not removed old config files from /etc. I neen properly updating of my old package. How I should write rules file for it? I need to remove old config files (from old-name package) when installing new version of package
<drizt> hey guys! is there anybody here? it's so hardy question? or is my english so bad?
<c2tarun> how can i copy anthing from my home folder in pbuilder-dist environment?
<tumbleweed> c2tarun: copy it from outside the pbuilder (the chroot is in /var/cache/pbuilder/build/something)
<c2tarun> actually pbuilder env is in /var/cache/pb.... mine is in ~/pbuilder/
<tumbleweed> c2tarun: pbuilder-dist doesn't set the buildplace, so it presumably still happens in /var/cache/pbuilder/build
<c2tarun> tumbleweed: thanks :) i'll try
<Laney> if I ship a file in a deb with changed permissions (excluded from fixperms), will dpkg maintain local (statoverride) permission changes?
<simar> ari-tczew, hi
<simar> ari-tczew, can i pm you
<ari-tczew> simar: hello. sure.
<drizt> hi. how i can see what command execute in the postinst and preinst sections when i install my package with apt-get install?
<geser> drizt: add "set -x" near the top of the scripts
<drizt> geser: you mean what i should add "set -x" to my .postinst file?
<geser> yes
<drizt> thank you. i will try. ... maybe is there is another way to do it?
<drizt> what is mean "set -e" ? I have open my .postinst file and seem it on the top.
<StevenK> If a command exits with a status that isn't 0, the script exits
<drizt> ok thank you
<drizt> I want to remove obsoletes conffiles. For it i must use .preinst file. I need to see upgrade parameter and if i got it remove old conffiles. Is it true?
<MTecknology> drizt: looking for this? http://man.cx/dpkg-maintscript-helper
<drizt> maybe ...
<drizt> thank you.
<drizt> damn. after rpm it so hardy for me!
<MTecknology> what exactly are you trying to do?
<drizt> i renamed package.
<MTecknology> then ya, you want that page
<drizt> after upgrade old package (with old name) i got couple of conffiles (from old and new packages).
<drizt> MTecknology: thank you for man.cx now i can use firefox searching to find a manpage!
<MTecknology> drizt: I gave you a link to the page you need
 * MTecknology has to run off
#ubuntu-motu 2011-02-08
<c2tarun> bug 710347 this package is not in archives I uploaded it on revu http://revu.ubuntuwire.com/p/schedio can anyone please take a look.
<ubottu> Launchpad bug 710347 in Ubuntu "[needs-packaging] schedio" [Wishlist,In progress] https://launchpad.net/bugs/710347
<micahg> c2tarun: I'll try to take a look later this week
<c2tarun> micahg: thanks :) I have to go now, looking forward to your comments, thanks :)
<AnAnt> Hello
<dholbach> good morning
<AnAnt> hello
<dholbach> hi AnAnt
<jmarsden> It looks as though freedesktop.org moved the standards DTD files from www.freedsktop.org/standards/ to standards.freedesktop.org/ and does not redirect.  This breaks validation of menu files (eg /etc/xdg/menus/lxde-applications.menu from package lxmenu-data).  Should new .menu files reflect the new DTD location?  Should existing ones be updated?
<dholbach> apachelogger, Rhonda: seid ihr auch bei den Linuxwochen in Wien im Mai?
<dholbach> hallo toabctl
<toabctl> hey dholbach
<Rhonda> dholbach: Like all the years before, it's done on my birthday, and I repeatedly told them that it's quite unlikely that I am in Vienna during that time.  I'm not sure if my SO planed something for this year, so it might actually be possible, but I just don't know.
<dholbach> Rhonda, no worries
<Rhonda> They always wanted me to do LPI exams, that's why they were so bitter about me not being able to be around.  But it's not like I haven't (repeatedly) told them about that timing issue, and yet they do it each year again at exactly the same weekend, and ask me again wether I could do the exams. %-/
<dholbach> Rhonda, I hope it'll work out next time then
<Rhonda> In the case there is nothing planed (though, we are moving in march/april and might be busy with unpacking and stuff), I might be around for a nice chat at least.
<Rhonda> Are you going to give a talk or such?
<dholbach> yes, I'm planning to
<dholbach> it's in the week before UDS
<dholbach> so it makes a lot of sense to stop by on the way from Berlin and also visit a few friends in Austria
<Rhonda> Where is UDS this time?
<dholbach> Budapest
<dholbach> just around the corner :)
<Rhonda> Ouch.
<dholbach> ?
<Rhonda> I so much would like to attend at some point, and actually this might be potential the closest one to go.  I fear it won't be possible with my private situation currently. :(
<dholbach> let's see how things pan out
<dholbach> there's still quite a bit of time until May 9-13
<mok0> I need some detailed information on where app icons should be placed, in what sizes, etc
<mok0> ... and how to deal with Tango! theme icons
<mok0> Hm, what's wrong with this build-dep:
<mok0>  swig (>= 1.36),
<mok0> it fails even though swig has had that version since karmic
<Rhonda> What's the complete error output?
<Rhonda> And the complete Build-Depends line?
<mok0> Build-Depends: debhelper (>= 7), autotools-dev, automake, libtool,
<mok0>  quilt, libmmdb-dev (>=1.23), libclipper-dev, libgpp4-dev, libssm-dev
<mok0>  (>=1.1), libgsl0-dev, libglib2.0-dev, libgtk2.0-dev,
<Rhonda> Please use a paste site.
<mok0> Rhonda: yep. sorry
<mok0> http://pastebin.com/PtvGJ0bH
<mok0> rhonda, err message is http://pastebin.com/bR49DXi0
<Rhonda> Doesn't look like the complete build log to me, unfortunately?
<mok0> Rhonda, you want that? I cut out the relevant line
<mok0> http://pastebin.com/DwdDmSx7
<Rhonda> It might be that there is more relevant that you consider as such. :)
<mok0> (I need to figure out how to make pastebinit use paste.ubuntu.com)
<Rhonda> um, debhelper 8.0.0ubuntu2? Where is that from? In maverick I see 8.0.0ubuntu1, in natty 8.1.0ubuntu1?
<mok0> Rhonda: lucid
<Rhonda> negative, lucid has 7.4.15ubuntu1
<mok0> Rhonda: I doubt that is important. I added "(>= 1.36)" after swig and it stopped working
<akheron> lucid has swig 1.3.40-2ubuntu1
<Rhonda> You seem to have a strange chroot setup there. What's the sources.list in your chroot?
<akheron> 1.3.40 is way less than 1.36
<mok0> akheron: I know, which is why I find it strange
<Rhonda> Well, it might be a hint that your chroot has an issue.
<mok0> Rhonda: hang on lemme log on to it
<akheron> mok0: err, you have swig 1.3.40, you require 1.36
<akheron> 1.3.40 < 1.36
<Rhonda> mok0: If you log in try to apt-get install swig and see what you get there.
<mok0> akheron: ah
<mok0> akheron: thank you
<mok0> akheron: typo
<akheron> :)
<akheron> you meant 1.3.6?
<Rhonda> ouch, right. 1.36 is higher than what we even have in natty. I'm blind.
<mok0> akheron: I mean 1.3.36
<Rhonda> But having debhelper 8.0.0 in a lucid build environment is still strange.
<mok0> Rhonda: ok, let me check that out
<akheron> Rhonda: it's in backports right?
<Rhonda> Please make sure to have your lucid build environment clean. :)
<akheron> I myself usually use backports at least when packaing my on stuff for older releases
<Rhonda> akheron: Yes, but backports should only be used when really needed in build environments, thus pulled in by dependencies, not fixed installed there.
<mok0> I don't think I'm using that
<mok0> backports
<akheron> Rhonda: debhelper is not installed ina clean build environment
<akheron> not any version
<Rhonda> That 8.0.0ubuntu2 has to come from somewhere :)
<Rhonda> akheron: It is in mok0's.
<mok0> rhonda, debhelper is 7.4.15ubuntu1
<akheron> debhelper: missing
<Rhonda> Erm, right.
<dholbach> https://launchpad.net/ubuntu/+source/debhelper/+publishinghistory
<Rhonda> But I still wonder why lucid would pull in 8.0.0ubuntu2, that looks pretty strange,
<akheron> true, it's not in backports afaics
<mok0> Rhonda: it doesn't pull in 8.0 afaics
<Rhonda> Then at least the output is confusing and misleading. :)
<mok0> Rhonda: Grepping for that line in my stored build logs, it seems it asks for 8.0.0 once in a while
<mok0> Rhonda: also in the maverick builds I've done
<mok0> Anyways, my swig depends now works \o/
<mok0> Ah, .pastebinit.xml allows you to customize the pastebin site
<mok0> That information really ought to be documented in the man page
<mok0> Hm. Except it doesn
<mok0> t work
<mok0> Looks like it's been fixed, but still not in lucid : Bug: 312456
<apachelogger> dholbach: maybe
 * apachelogger did not really think about it yet ^^
<dholbach> apachelogger, ok
<Rhonda> In general, whoever stumbles by in Vienna feel free to bug me and I'll see wether we can meet.
<dholbach> who could imagine running a session about some aspect of Debian/Ubuntu packaging? we still have some open slots left for UDW
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable
<dholbach> any suggestions?
<ari-tczew> dholbach: nope
<dholbach> menesis, how's schooltool coming along?
<menesis> dholbach: we have a schooltool sprint this week
<dholbach> aha! excellent!
<menesis> dholbach: there are some issues that are not solved yet so the main "schooltool" package is not ready.
<dholbach> menesis, ah ok - there was also something with zope.html that bundled something else - is that resolved?
<dholbach> I think I mailed you about it back then
<menesis> but maybe I can upload the other packages in their current state just to get them uploaded, even if they are not installable
<dholbach> what's missing?
<menesis> dholbach: I was trying to solve more issues with zope.html (upstream) but not very successful
<menesis> sorry I haven't replied
<dholbach> don't worry
<highvoltage> hey menesis
<dholbach> if upstream can't solve it and it can be done in the packaging we can still just do it there
<dholbach> hey highvoltage
<highvoltage> and dholbach :)
<menesis> "schooltool" is missing. schooltool.gradebook and others depend on it
<menesis> I am worried already because time is running out and I have not finished my work..
<dholbach> we still made a lot of progress in terms of zope packages :)
<dholbach> but if there's anything highvoltage and I can do, let us know
<menesis> dholbach: but with zope.html I would like to leave it as is and solve the versioned directories later
<dholbach> can you reply to that mail again, so I have it in my inbox and won't forget?
<highvoltage> menesis: how bad is it? would there be something uploadable in a month from now?
<dholbach> might be a few days until I get to it
<highvoltage> getting a FFE just for schooltool at that stage would probably not be a big deal
<menesis> I would like help with upstart, but first I need to get schooltool into archive with the old init.d scripts
<dholbach> that shouldn't be a blocker
<dholbach> there's loads of stuff still using old-style initscripts
<menesis> yes I don't consider it a blocker
<menesis> highvoltage: I hope to be able to upload schooltool in two weeks
<menesis> we are in a sprint now, merging branches to upstream, then I make a release and a new package
<dholbach> great
<menesis> one thing is I left out 3 zope packages because they are needed only for backwards compat with existing schooltool databases.
<highvoltage> menesis: ah good! that still even beats feature freeze then
<menesis> but I haven't done the work and testing to make sure they are really not needed
<menesis> maybe I can upload those 3 packages even though I expect them to be removed soon?
<dholbach> hey blueyed
<blueyed> Hi dholbach
<gondoi> is there a preferred way of modifying the debian/changelog, or do I just modify it directly?
<dholbach> gondoi, try 'dch' (in the devscripts package)
<gondoi> cool, thanks dholbach
<dholbach> 'dch -i' to add an empty changelog entry and bump the revision up one
<gondoi> lol.. yeah, it's right there in the instructions I'm following.. overlooked that step
<gondoi> sorry
<Riddell> could someone explain (again) the difference between ~ubuntu-dev and ~motu? I can never remember which is which.  can this guy https://launchpad.net/~sylvestre confirm this? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/714562
<ubottu> Ubuntu bug 714562 in scilab (Ubuntu) "Sync scilab 5.3.0-final-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed]
<micahg> Riddell: ubuntu-dev is anyone with upload rights I believe, MOTU is universe upload rights
<Riddell> so how does he get upload rights?
<iulian> Riddell: Maybe he has limited upload privileges.
<micahg> Riddell: PPU
<iulian> Riddell: Per package uploader.
<micahg> Riddell: he has upload rights for that package, you can use edit-acl.py to check
<micahg> er, edit_acl.py
<Riddell> that works, thanks
<maco> micahg: universe & multiverse
<geser> yes, sylvestre has PPU rights for the packages he maintains in Debian and scilab is one of it
<geser> it would be really nice to have a web view for PPU instead of only the LP API
<devkorcvince> hello any one who wants to be my mentor hehehehe... where can i learn the fastest on contributing?
<devkorcvince> ooops wrong channel need to go to #ubuntu-classroom
<blueyed> micahg: where does edit_acl.py come from? Is is available to everyone?
<micahg> blueyed: lp:ubuntu-archive-tools
<blueyed> thanks, micahg. I have no use case currently, but this may become handy.
<micahg> blueyed: it's good for those with packageset upload rights and don't remember if something is in a packageset or not
<blueyed> There's still no distinction about sponsorship teams (motu vs core-dev) in Launchpad, is it? Like all request for sponsorship get into the same queue?!
<geser> blueyed: there was in the past but got merged into ~ubuntu-sponsors lately
<maco> blueyed: they used to be split, but with archive reorg that became silly
<maco> because core-dev arent the only people who can upload to main. PPU, ubuntu-desktop-dev, kubuntu-dev, xubuntu-dev... they can too
<blueyed> That's what I mean, yes. But now it's difficult to see for a MOTU what he can sponsor, isn't it?
<maco> anything unseeded can be done by a motu
<blueyed> I see. And can you see what's seeded in LP easily, preferably from the sponsor queue?
<maco> im trying to locate the sponsor queue right now
<maco> i dont have my bookmarks at work
<micahg> maco: not true, there is some unseeded stuff in main
<maco> micahg: thats not how its supposed to work :(
<maco> but this silly wiki page i found from google stupidly links to lp instead of the sponsor queue when it says sponsor queue
<micahg> http://reports.qa.ubuntu.com/reports/sponsoring/
<maco> thank  you!
<micahg> sponsorship page still lists universe/main distinctions
<maco> micahg: motu's domain was supposed to have been redefined to "the long tail of everything not seeded", according to discussions at uds...hmm....dallas, i believe
<micahg> maco: yes, but that won't happen most likely until the archvie reorg is done
<maco> micahg: oh that mustve been recently added back. the "origin" is all that was there before
<maco> i thought archive reorg WAS done
<maco> PPUs are in place, packagesets are in place...what else is needed?
<micahg> maco: no, a few more cycles
<micahg> at least :)
<micahg> maco: https://wiki.ubuntu.com/ArchiveReorganisation
<blueyed> I was more thinking about getting the differences from the "Bugs" page of the ubuntu-sponsors LP page.
<RainCT> Any idea on why valac doesn't get installed in pbuilder?
<RainCT> (pbuilder-satisfydepends-dummy: Depends: valac (>= 0.9.4~) but it is not going to be installed.)
<gondoi> I have created a branch patch for SRU in bzr and submitted for merging...
<gondoi> now what am I missing:
<gondoi> https://bugs.launchpad.net/ubuntu/+source/munin/+bug/699967
<ubottu> Ubuntu bug 699967 in munin (Debian) "Empty list of plugins/services with hostname containing uppercase letters" [Unknown,Confirmed]
<gondoi> just trying to cover my bases
<geser> RainCT: natty?
<gondoi> maverick
<gondoi> sru
<RainCT> geser: Debian unstable, actually
<geser> then no, I know only that natty has vala 0.10 and 0.12 which causes some problems
<geser> RainCT: what happens when you try to install all build-depends with apt-get in your pbuilder? (you might need to add valac and perhaps other packages to the command line to see the real problem)
<RainCT> geser: It took 0.8.1-2
<geser> checking on PTS you need experimental if you want a newer valac
<RainCT> geser: Oh, right. How could I miss that? :P
<RainCT> geser: Thanks
<sebner> geser: would you mind helping fixing flightgear ftbfs? You are tehh expert :) Evidently a linking issue but I couldn't really solve it myself. http://pastebin.com/VHvQmEDk
<grunthus> cyphermox: Just about to start with synaptic bug per your email
<cyphermox> ah, cool
<grunthus> cyphermox: Hello, I should say first!
<grunthus> do I bzr branch as first step?
<cyphermox> yeah, I'd say bzr branch lp:synaptic
<grunthus> OK, I still have the directories lying around from when I generated the debdiff. Presumably it would be just as easy to dump all that. The edits were simple with sed.
<cyphermox> right, if you did the changes directly in file from previously, you probably can just copy the files over
<cyphermox> just double check after that you only have the changes you really wanted (bzr diff)
<cyphermox> if I remember your diff right you could also just use that with patch -p1 <yourdiff
<grunthus> OK, got a slight hitch here with ssh key.
<grunthus> I need to copy it on to the VM where I'm running Natty.
<cyphermox> ah
<cyphermox> grunthus, well, honestly, it's really up to if you want to champion your changes all the way, because I could also apply them for you in a branch here and request a merge, if it's easier for you :)
<grunthus> I would quite like to give bzr a go first. If I get stuck, then fair enough, you could apply them.
<grunthus> Would I be right in saying that bazaar is "on the up"?
<cyphermox> grunthus, you mean in popularity? I would have no idea
<cyphermox> grunthus, also don't hesitate to ask others for help -- for instance, I'm just about done my work day and have a dinner planned, but I would be back in a few hours
<grunthus> Sure. I will. Bon appetite. Perhaps see you later, although bed in this time zone is in 2 hrs!
<grunthus> I'll drop you an email with my progress.
<cyphermox> cool, we can certainly continue this over email
<lfaraone> If overriding CFLAGS (to, say, "-O2 -wall") causes a program to break, upstream is doing it wrong, right?
<geser> sebner: the solution seems to be to move "-lsgio" after "-lOpenThreads"
<geser> but I didn't look how to get it into the Makefile, just tested it on the command line inside my pbuilder
<grunthus> Right, perhaps someone else can advise on cyphermox's suggestion to use patch -p1<debdiff ?
<grunthus> Presumably to apply my debdiff to the bzr checked out branch,
<grunthus> I would cd to the bzr checked out directory, then run the above patch with full path to the debdiff...
<grunthus> This relates to bug 706271
<ubottu> Launchpad bug 706271 in synaptic (Ubuntu) "synaptic network proxy preferences doesn't capitalize "internet"" [Undecided,Confirmed] https://launchpad.net/bugs/706271
<sebner> geser: wow, great. that helps a lot, I'll look into it how to do that in the makefile! :)
 * sebner hugs geser 
<grunthus> Hmm. Patch failed, generated a pile of rejects.
<ari-tczew> geser: around?
<blueyed> gondoi: I am not sure, but shouldn't you nominate the bug for Maverick, too?
<blueyed> gondoi: apart from that, the branch/patch looks good, but I cannot ACK/sponsor it.
<ari-tczew> blueyed: if it's bzr branch, set status as Approved
<ari-tczew> as motu member you can support patches for main
<blueyed> ari-tczew: but it's a SRU.
<blueyed> ari-tczew: not even nominated (which I could do at least, yes)
<ari-tczew> blueyed: it doesn't matter, if you're sure that debdiff/branch is correct with SRU policy, set as Approved commenting like "Looks good, please core-dev for upload"
<ari-tczew> it works something like patch pilot
<blueyed> ari-tczew: I've nominated it for Maverick now, but cannot even accept the nomination. How should I set it to confirmed now?
<lfaraone> ari-tczew: people shouldn't review for ~ubuntu-dev unless they are able to upload the package in question.
<blueyed> ari-tczew: bug 699967
<ubottu> Launchpad bug 699967 in munin (Debian) "Empty list of plugins/services with hostname containing uppercase letters" [Unknown,Confirmed] https://launchpad.net/bugs/699967
<ari-tczew> lfaraone: I know that you're not so much involved in sponsorship last time, so I'd like to say you that we've figured out that MOTU can support sponsors-queue in cleaning up by reviewing patches
<ari-tczew> I have reviewed a lot of patches in main and there were not any troubles. Just helpful to keep sponsors queue small.
<micahg> lfaraone: from what I can tell, a MOTU can approve, but teh core-dev uploader should still spot-check
<micahg> that should be core-dev or uploader
<lfaraone> ah, okay.
<ari-tczew> blueyed: bzr branch linked to bug is for SRU?
<ari-tczew> if so, it's wrong
<ari-tczew> there is no maverick-proposed in d/changelog
<geser> ari-tczew: yes
<ari-tczew> geser: I'll ask pm you ;)
<ari-tczew> blueyed: branch says about +upstream_bug_952.patch but node/lib/Munin/Node/Server.pm has been patched directly
<blueyed> ari-tczew: yes, the changelog is wrong. it's meant to be maverick-proposed. @gondoi: <--
<ari-tczew> blueyed: please describe all issues in comment into branch setting status as Needs-fixing
<blueyed> ari-tczew: you're right. quite borked. I leave feedback as a comment, yes.
<ari-tczew> ;-
<ari-tczew> ;-)
<grunthus> Hi, I need a little assistance following on from earlier with cyphermox. I have edited changes to my bzr branch, and updated changelog.
<grunthus> According to documentation, I think I now have to either commit the changes or build source package?
<grunthus> (bug 706271)
<ubottu> Launchpad bug 706271 in synaptic (Ubuntu) "synaptic network proxy preferences doesn't capitalize "internet"" [Undecided,Confirmed] https://launchpad.net/bugs/706271
<ari-tczew> blueyed: please don't forget about suggesting DEP3 tags in the patch
<gondoi> blueyed: sorry man, this is my first patch to the ubuntu community :-(
<blueyed> gondoi: no problem! really.
<blueyed> gondoi: just do not give up learning :)
<gondoi> the nomination is what I couldn't figure out earlier.. thought I just needed to say that in a comment
<gondoi> I don't see a button
<blueyed> gondoi: please note that you look into DEP3 tags for your patch, although that should hopefully be provided in the patch I committed for Natty already.. :)
<blueyed> gondoi: the button is "Nominate for series".. third one in the row starting with "Also affects project"
<gondoi> blueyed: I don't have that button :-( I guess I don't have the right privs
<blueyed> gondoi: maybe. you are not a member of bugcontrol then even, are you?
<gondoi> well, I thought I was, but perhaps not
<blueyed> does not matter then currently. Can you fix your branch?
<gondoi> well, i'll have to figure out how...
<gondoi> :-(
<gondoi> i'll look into the dep3 thing
<micahg> blueyed: yeah, that was a recent change, I think only bug supervisors can nominate now
<blueyed> gondoi: ^^
<gondoi> :-D
<micahg> bdmurray: am I right about this? ^^
<blueyed> gondoi: dep3 is not important.. as said, I should have either provided it in the natty patch, or if not, it would not make sense to have it in the maverick fix/branch only.
<blueyed> gondoi: just use the patch instead of patching inline. Feel free to query me, if you have any more detailed questions about this.
<gondoi> blueyed: sorry then, i'm not sure on what I am fixing
<gondoi> oh
<gondoi> so provide the debdiff?
<blueyed> gondoi: you need to only fix the changelog (add "-proposed" and use the patch instead of editing it inline)
<blueyed> gondoi: no, edit your branch, then add another commit.
<gondoi> well, I did use the patch on the src
<gondoi> i'll add the -proposed
<bdmurray> micahg: yes bug supervisors can nominate for release maybe uploaders too
<blueyed> gondoi: yes, that was wrong.. go to your checkout of lp:~bkbox/ubuntu/maverick/munin/fix-for-699967, add 1) the -proposed and 2) revert the change to node/lib/Munin/Node/Server.pm and add the debian/patches/upstream_bug_952.patch file from the natty source instead.
<micahg> bdmurray: all uploaders are implicit members of bug control
<blueyed> gondoi: then commit after each change and push it.
<micahg> bdmurray: if it's only bug control now, we should probably update the SRU docs
<blueyed> micahg: gondoi is not an uploader and not bug supervisor. Shouldn't anybody be allowed to nominate?
<micahg> blueyed: I think that changed recently in that we had people randomly nominating creating a lot of noise
<cjwatson> it was certainly a real issue
<cjwatson> the nomination queue was basically entirely unusable
<sebner> geser: hmm, http://launchpadlibrarian.net/63828404/buildlog_ubuntu-natty-i386.flightgear_2.0.0-3ubuntu11_FAILEDTOBUILD.txt.gz
<ari-tczew> sebner: show your makefile
<ari-tczew> (LIBS)
<sebner> ari-tczew: http://paste.ubuntu.com/564736/
<geser> sebner: I don't fully understand the needed order, but I had only success when I only moved the mentioned "-lsgio" and left the other at there place
<ari-tczew> sebner: LIBS = @LIBS@
<ari-tczew> where are links changed?
<sebner> geser: did you put it at the end or right behind -lOpenThreads?
<geser> perhaps it's an error in -lOpenThreads that it didn't link with all needed libraries (didn't check yet)
<geser> sebner: after the -lOpenThreads
<sebner> ari-tczew: configure evidently
<sebner> geser: Ok, I didn't try that
<ari-tczew> sebner: which line?
<sebner> ari-tczew: various ones but I found the -OpenThreads part, will try that now
#ubuntu-motu 2011-02-09
<sebner> geser: fails as well
<vhenry93> Hi, developer newbie here who would like to contribute. Question, is MOTU or bugsquad best place to start?
<vhenry93> disregard, found the answer.
<simar> Hello everyone
<simar> I have a doubt..
<simar> https://wiki.ubuntu.com/PbuilderHowto pbuilder sets up a chroot environment for for building source packages for ubuntu..
<RAOF> simar: Do you have a question?
<paultag> simar: yes?
<simar> So how this is different from.. https://wiki.ubuntu.com/DebootstrapChroot
<paultag> simar: check /var/cache/pbuilder/
<simar> I mean do I also need a chroot enviroment for building source packages..
<paultag> simar: it stores it in a .tar.gz and cleans it after use to ensure a clean build (and good to check if it's deps are right)
<paultag> simar: pbuilder builds source packages
<paultag> last I checked, anyway :)
<RAOF> No, but it can be useful to have a chroot environment if you want to check that it'll build in the archive.
<simar> No chroot creats binary packages .. but when i have to create source packaes by debuild -S then should i do that in a chroot
<simar> *No pbuilder creats ....*
<RAOF> Ah, no.
<RAOF> There's no reason to create source packages in a chroot.
<simar> paultag, Does it means something like pbuilder also creates a chroot but handles it nicely in a tar.. So can we make binary packages without pbuilder but with a simple chroot .. I will be happy if you can tell me what are all the ways to create a chroot enviroment .. tha will make it more clear
<cdbs> simar: Why would you avoid using pbuilder?
<cdbs> simar: it speeds up the chroot creating, extracting and building, and automates it all
<paultag> simar: pbuilder just creates a chroot of your choosing, puts it into a tar, and automates extracting it, updating it, and so forth without builds klobbering ( such as leaving old deps that may "save" a ftbfs )
<paultag> cdbs: +1
<simar> RAOF, But if I want to create source packages for natty and I'm currently using maverick won't dependies gonno conflict..
<RAOF> Fundamentally, creating a chroot is not much more than running debootstrap on a directory.  But pbuilder and sbuild are two tools that make managing build chroots easy.
<cdbs> simar: of course not
<paultag> simar: you can create a natty pbuilder env
<cdbs> simar: install the package ubuntu-dev-tools and then use the pbuilder-dist script as a front-end of pbuilder, it will make life easier
<cdbs> simar: eg pbuilder-dist natty create
<paultag> +1 there
<cdbs> simar: then pbuilder-dist natty build foo.dsc
<RAOF> simar: If you're making a *source* package you generally don't care about the build-dependencies, because you're *not* building the code.
<simar> oh..
<RAOF> simar: The only dependencies you need to care about for source packages are the packaging tool dependencies - quilt, dpkg, debhelper, cdbs, etc.
 * cdbs is a dependency :)
<RAOF> cdbs: Only for annoying packages :P
<cdbs> RAOF: exactly. Even I prefer dh7/8 over cdbs
<simar> cdbs, I use pbuilder but don't understand what is it.. n I get confused when I read something like 'Chroot enviroment' in packaging guide..
<paultag> simar: play with it
<simar> cdbs, I should use pbuilder thats for sure
<paultag> simar: you'll grab the idea after you try to hack it into normal usage (and read the man page)
<cdbs> simar: pbuilder builds in a chroot environment. When they ask you to build in one, just build using pbuilder
<cdbs> simar: so, you have a natty pbuilder chroot already?
<RAOF> simar: Basically, pbuilder is a way of turning a source package into a binary package, while not polluting your regular install.
<simar> cdbs, No but I will have one .. today .. using the command pbuilder-dist
<cdbs> simar: yes, that's the way to go
<simar> RAOF, I understand that .. but when I create source packages .. then can I do that in my regular directory of maverick...
<simar> I will be creating source packages for natty
<RAOF> simar: Right*.  (* Unless the source package uses *packaging* tools available in Natty but not Maverick; there aren't a lot of those, but they exist)
<RAOF> There's no need to do anything special for source packages.
<simar> RAOF, Sould this be a point of worry for a beginner...??
<RAOF> No.  The cases where it matters are very rare.
<RAOF> And you'll know when it happens.
<simar> @everyone Thanks for help. I think I got most of the stuff. But I want to know what usually developers do. I can do all this in virtual machine as well. So should I use pbuilder or virtual machine..
<RAOF> I use sbuild personally; others use pbuilder.
<cdbs> simar: I 'd recommend pbuilder whether you use in a VM or outside it
<simar> RAOF, why si
<simar> *so
<simar> cdbs, ok.. that sounds more clear..
<cdbs> simar: the main point of a pbuilder is to check whether the build-depends are okay and the package builds well in the target distro
<simar> cdbs, ya i understand that..
<RAOF> sbuild is (closer to) what's used on the buildds, so it sometimes picks up problems that pbuilder wouldn't.  It's also more powerful, so I can do funky things with it.  pbuilder (and particularly pbuilder-dist) are plenty good, though.
<cdbs> simar: I am using natty for daily use (mind you its buggy) and even after that I use pbuilder, not sane building using debuild
<paultag> The issue is that it will pick up system deps that might not be on a build machine -- let's say you forget libfoo-dev in your build-deps, but you have it installed locally. Your build will be fine, but when you upload it will FTBFS
<paultag> That's why we use chroots to test -- and pbuilder to keep up sane
<simar> paultag, ok..
<simar> and what exactly is a debootstrap? thats a term related to these i think..
<paultag> simar: it's what creates a chroot -- layered under levels of sanity it's called for pbuilder
<paultag> simar: because you can't just chroot into ./chroot-dir, you also have to have ./chroot-dir/proc, dev and a few other fun things before you have a sane env
<paultag> "One does not simply chroot into mordor"
<paultag> if you will
<RAOF> debootstrap is DEbian Bootstrap - it basically downloads and unpacks all the packages you need to set up a debian environment (you need a shell, libc, dpkg, etc) without needing any of the tools in there.
<broder> paultag: +1 :)
<paultag> ;)
<simar> i got it .. so much thanks for help ... :))
<paultag> simar: godspeed!
<simar> paultag, ;)
<dholbach> good morning
<RainCT> morning dholbach :)
<dholbach> hola RainCT - Feliz CumpleaÃ±os! :)
<RainCT> dholbach: thanks :)
<iulian> Morning dholbach, RainCT.
<iulian> Uhmm.
<dholbach> hi iulian
<iulian> Happy what?
<dholbach> Birthday!
<iulian> Uh oh!
<iulian> RainCT: Happy birthday mate!
<RainCT> iulian: thanks!
<sebner> RainCT: happy birthday! :)
<sebner> ~o~ ~o~ ~o~ ~o~ ~o~
<cdbs> RainCT: Happy Birthday
<RainCT> sebner, cdbs: ~o~ thanks ~o~
<Raydiation> hi ive written something like ampache, just in django and with a better userinterface plus ogg vorbis support (its in HTML5). you can see a preview on http://laudio-player.org/
<Raydiation> ive also done the packaging (was a lot of work) and now its in revu http://revu.ubuntuwire.com/p/laudio
<Raydiation> if someone is interested :)
<Raydiation> after install its available under http://localhost/laudio
<gondoi> blueyed: morning! I think that branch is all ready to go for #699967 SRU.  Do I need to propose merge again?
<ari-tczew> bug 699967
<ubottu> Launchpad bug 699967 in munin (Debian) "Empty list of plugins/services with hostname containing uppercase letters" [Unknown,Confirmed] https://launchpad.net/bugs/699967
<ari-tczew> gondoi: You don't need to propose again. However, there are still some issues.
<gondoi> :-(
<gondoi> okay
<ari-tczew> I'll comment.
<gondoi> thanks
<ari-tczew> gondoi: done
<gondoi> ari-tczew: thanks, I'll have a look
<ari-tczew> siretart: ping
<gondoi> ari-tczew: I'm not seeing where the DEP-3 info needs to go
<gondoi> oh wait, I think I do now
<gondoi> is there a tool to embed that? or is it manually created?
<ari-tczew> gondoi: manually
<ari-tczew> gondoi: but tool in future is a good idea
<grunthus> Hi cyphermox.
<micahg> gondoi: source format 3 can create most of what you need if the package supports it and you're creating the patch
<cyphermox> grunthus, hey
<grunthus> Hi cyphermox, I was pleased with how the fix went overall!
<ari-tczew> micahg: do you encourage to change source format in Ubuntu instead Debian?
<micahg> ari-tczew: no
<micahg> that's why I said, if the package supports it :)
<grunthus> cyphermox: Funny issue with my DEBFULLNAME etc however as those are set in .bashrc
<grunthus> cyphermox: I have to go out now for 2 hours. Speak later if you are around!
<grunthus> cyphermox: fixed DEBEMAIL, just had to export!
<cyphermox> grunthus, great :)
<bcurtiswx> i downgraded a package from the gnome3 PPA to natty (nautilus), but it still links to libgtk-3.0.so.0 => /usr/lib/libgtk-3.0.so.0 (0x00007fd03e47b000).. how can i change that back to -2.0 ?
<geser> bcurtiswx: this is from ldd nautilus?
<bcurtiswx> geser, correct
<geser> bcurtiswx: is it nautilus linking against libgtk3 or one of the libs it uses?
<geser> I guess the later
<bcurtiswx> geser, the later probably. how would I find out which?
<geser> try and error with ldd
<geser> or see which packages will be gone too if you remove it (the package for libgtk3) and check those
<blueyed> ari-tczew, micahg: gondoi is working on a SRU with a patch that has been applied upstream already - I do not think he should edit the patch to make it match DEP-3. After all, that would have been the job of the committer for the Natty package (which is me).
<gondoi> blueyed, ari-tczew: i pushed up the changes earlier
<bcurtiswx> geser, apt-cache rdepends was my savior
<bcurtiswx> it was libnautilus-extension1 that i didn't downgrade too
<bcurtiswx> geser, thx for the help :)
<micahg> blueyed: I was just answering a question that was asked, not commenting on relevance of the headers
<blueyed> micahg: you are right, of course. thanks.
<micahg> blueyed: also, is there a good chance to get the new upstream version in natty (in which case the patch would disappear?), in any case, a new upload is a good chance to get that recorded somewhere, and in an SRU, if there are any problem with the patch, it's probably best to have all the info right there
<blueyed> micahg: there's no new release yet (AFAIK), would be munin 1.4.6. Of course, additional info won't hurt. And it was added by gondoi.
<ari-tczew> blueyed: patch should be included in devel (natty) first, then SRU
<blueyed> gondoi: the author lines appear to be wrong: we are both not the author of the patch.
<blueyed> ari-tczew: it is in natty already.
<ari-tczew> blueyed: a lot of patches are go through SRU and everyone has got DEP3 tags. why gondoi's case should be special?
<blueyed> gondoi: that is quite pedantic though, but should be easy for you to remove those lines and push again.
<blueyed> ari-tczew: there are no DEP3 tags in the natty patch. so it differs from natty. While this is only meta info, it is better to use the same patch as with the devel version, isn't it?
<ari-tczew> blueyed: I won't click 'Approve', dunno how about you.
<blueyed> ari-tczew: just because, or because of some reason?
<blueyed> ari-tczew: there are DEP3 tags now.
<ari-tczew> blueyed: that's policy. every patch which is going to Ubuntu archive should be described by DEP3 tags
<ari-tczew> Debian should as well
<gondoi> blueyed, ari-tczew: DEP3 modified
<micahg> blueyed: if there's a problem with the headers, that should be caught test building the SRU, otherwise, it is the same patch
<geser> ari-tczew: is the DEP3 requirement documented somewhere?
<ari-tczew> geser: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#Patch Tagging Guidelines
 * micahg was thinking about asking that
<ari-tczew> merged from https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
<blueyed> gondoi: approved, thanks so far.
<micahg> it seems to be a suggestion (a very good one) as opposed to a hard requirement though
<ari-tczew> micahg: nitpick
<geser> I read also it as "nice-to-have" but no requirement
<geser> I've never added any DEP3 headers when fixing any FTBFS till now
<gondoi> blueyed: thanks
<ari-tczew> gondoi: is this line not necessary? $node = lc($node);
<ari-tczew> looking from http://munin-monitoring.org/changeset/3404#file19
<gondoi> ari-tczew: it's already there from the 1.4.5 release src
<gondoi> that's what started the bug
<ari-tczew> gondoi: you don't understand me.
<gondoi> that view is a bit odd, but it looks like the _list_services line had the correct code, but somehow regressed in a later revision
<ari-tczew> gondoi: look on the patches:
<ari-tczew> gondoi: natty: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/munin/natty/view/head:/debian/patches/upstream_bug_952.patch
<ari-tczew> gondoi: upstream: http://munin-monitoring.org/changeset/3404#file19
<ari-tczew> changes on file Server.pm are not the same
<ari-tczew> is it correct?
<ari-tczew> blueyed: do you have PPU for munin?
<ari-tczew> blueyed: ok nevermind
<gondoi> ari-tczew: that line is already there... no need to patch it
<gondoi> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/munin/maverick/view/head:/node/lib/Munin/Node/Server.pm#L93
<gondoi> L174 is the one that is patched and incorrect
<ari-tczew> gondoi: ok, some concerns about DEP3, will quickly comment
<ari-tczew> gondoi: done. please fix rapidly and I'll ask patch pilot to upload it today ;-)
<bcurtiswx> what are the basic steps in a sync, is this documented well in the wiki?
<Rhonda> Yes.
<maco> bcurtiswx: just request one on launchpad. subscribe archive admins
<maco> theyre the only people who can do them
<bcurtiswx> maco, OK
<Rhonda> The requestsync tool is extremely helpful for that
<Rhonda> No need to extract and write it up all yourself.
<maco> dont use the rogue script some people use for syncing around the archive admins
<maco> it apparently breaks stuff
<maco> (yeah, i got told this /after/ using that script...)
<ari-tczew> bcurtiswx: https://wiki.ubuntu.com/SyncRequestProcess
<bcurtiswx> ty ty ty :)
<ari-tczew> np
<siretart> ari-tczew: this is a contentless pong.
<ari-tczew> siretart: FTBFS in libva wasn't fixed
<siretart> ari-tczew: pardon me?
<siretart> what's missing?
<ari-tczew> siretart: debian bug 609554
<ubottu> Debian bug 609554 in libva "Fix FTBFS with ld --no-add-needed" [Important,Fixed] http://bugs.debian.org/609554
<ari-tczew> I tried to build it on natty and it still fails to build due to linking
<siretart> ari-tczew: so you're basically saying that http://git.debian.org/?p=pkg-multimedia/libva.git;a=blob;f=debian/patches/remove-unneeded-dep2.patch is incomplete or broken, right?
<ari-tczew> siretart: probably yes
<siretart> in this case that patch needs to be revised/fixed
<ari-tczew> siretart: I could help you fix it, but not today.
<geser> TrudEev4
<geser> crap, wrong window :(
<Laney> :(
<grunthus> hi cyphermox again,
<grunthus> you probably got my email...
<grunthus> now I need to find another task.
<cyphermox> grunthus, I sent you links for two ways to find new stuff to do -- LP bugs (bitesize), and Harvest. but one other way is to find something that annoys you and try to fix it :)
<grunthus> Thanks cyphermox, I see that now.
<cyphermox> grunthus, now just like yesterday, I'll need to travel from the office to back home, so I'd be back in hopefully about an hour
<grunthus> Well, cyphermox, the next hour will be midnight for me.
<cyphermox> ah
<cyphermox> those pesky timezones
<grunthus> I hope to be in bed! What timezone are you?
<cyphermox> EST
<grunthus> GMT+5
<cyphermox> -5
<grunthus> I'm UT
<grunthus> EST is GMT-5
<grunthus> ?
<cyphermox> yes
<grunthus> of course!
<grunthus> Hi, bzr branch is showing port 22:Connection refused. Is that down to maintenance mode?
<micahg> grunthus: yep, LP is read-only at the moment (bzr down), should be about 45 more minutes
<grunthus> micahg: thanks for info.
#ubuntu-motu 2011-02-10
<achiang> hm, any ARM users out there who've tried chromium-browser from lucid-security? i'm seeing a SEGV on launch and wondering if it's a known issue already
 * achiang goes trolling through launchpad
<achiang> hm, nothing interesting there
<dholbach> good morning
<MTecknology> dholbach: howdy
<dholbach> hi MTecknology
<MTecknology> dholbach: how's it going?
<scott__> for some reason I can't compile dumb frotz 2.43. i get: http://paste.ubuntu.com/565279/ when i do 'make dumb'
<dholbach> good good
<geser> scott__: it seems to use a function name (getline) which is also provided by the libc. You either have to rename it (and all it's calls) or check if it does the same as the one from libc and use it.
<scott__> ok i think i try renaming the function. simple enough.
<scott__> yep that seemed to be it thanks for the insight
<mok0> Hm, what could be different from the buildd and my local sbuilder? I have an app that crashes when it's been built in the PPA, but not when I build it myself
<mok0> the buildd seems to pull in more libraries
<mok0> n/m
<mok0> I was too fast. The newly built package wasn't yet available
<mok0> I was too fast, and so I wasted 1 hour :-(
<ari-tczew> hello
<coolbhavi> hello ari-tczew
<ari-tczew> coolbhavi: how are you?
<coolbhavi> ari-tczew, m good mate, you?
<ari-tczew> coolbhavi: this was busy week (until today), I'm quite sleepy and tired
<ari-tczew> but got some free time for finish some ubuntu-related stuff and learn to warehouse designing
<coolbhavi> ari-tczew, same here mate, very tired
<Rhonda> tumbleweed: Sorry for stealing your devweek talk title. ;)
<tumbleweed> Rhonda: lol :)
<Rhonda> Was too tempting. :)
<udienz> Rhonda, can i ask about Contribute To debian at here?
<udienz> *Debian
<Rhonda> udienz: Rather come to #debian-ubuntu on irc.debian.org (oftc)
<Rhonda> Though, obviously it depends on how deep your question is, in general.
<virusuy> hi all !!
<alucardni> hello everyone, I'm starting this motu journey trying to fix LP #706221
<ubottu> Launchpad bug 706221 in calibre (Ubuntu) "calibre : More info - Having a typo ( supports is misspelled as upports) " [Undecided,Confirmed] https://launchpad.net/bugs/706221
<alucardni> my debdiff right now looks like this @@ -50,7 +51,7 @@ Calibre is primarily a ebook cataloging program. It manages your ebook collection for you. It is designed around the concept of the logical book, i.e. a single entry in the database that may correspond to ebooks in several
<alucardni> - formats. It also upports conversion from a dozen different ebook formats to
<alucardni> + formats. It also supports conversion from a dozen different ebook formats to LRF and EPUB. A graphical interface to the conversion software can be accessed easily by just clicking the "Convert E-books" button. .
<alucardni> @@ -85,7 +86,7 @@ Calibre is primarily a ebook cataloging program. It manages your ebook collection for you. It is designed around the concept of the logical book, i.e. a single entry in the database that may correspond to ebooks in several
<alucardni> ups
<alucardni> sorry for that
<alucardni> my debdiff looks like this http://paste.ubuntu.com/565461/
<alucardni> can somebody explain why it has the same parragraph twice??? It's the right behavior
<persia> One is for the "calibre" package, and the other for the "calibre-bin" package.
<alucardni> persia: thank you
<Laney> alucardni: btw, you would be better doing this change in Debian first (as it's quite minor). The branch is actually maintained on Launchpad, so you can get it with `bzr branch lp:~calibre-packagers/calibre/debian' and then propose a merge to that.
<micahg> alucardni: that should probably go through Debian, I think the upstream maintainer is pretty responsive :)
<alucardni> micahg: Laney ok, I'll try to push it to the bzr branch. Thank you guys!
<Laney> Sure, make sure you use a Debian version (ending in -2) and use 'unstable' as the distribution instead of 'natty'.
<Laney> (and don't change the maintainer)
<persia> "unstable" rather than "UNRELEASED"?
<Laney> UNRELEASED indeed, I selected the wrong bzr revision to check this package's policy
<alucardni> So all I have to do is get the bzr branch, apply my patch (with your recommendations on debian/changelog and debian/control), commit and propose for merging?
<persia> Ideally, yes.
<alucardni> persia: I followed the steps for Ubuntu Merge Proposal on https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
<persia> Except you used the branch Laney identified?
<alucardni> persia: yes, the branch Laney identified, only contains the debian directory
<alucardni> but I got this error when pushing to LP: bzr: ERROR: Invalid url supplied to transport: "lp:~josernestodavila/ubuntu/calibre/debian/fix-706221": No such distribution series calibre.
<persia> You want to push to "lp:~josernestodavila/calibre/debian-fix-706221"
<persia> You aren't making a change to Ubuntu.
<alucardni> oh! true, thank you againg
<alucardni> *again
<alucardni> it's working now :)
<Laney> alucardni: you can do 'bzr bd -S' to build a source package, that should work
<Laney> and 'bzr bd-do' should give you a complete source tree (in a subshell) that you can work with as normal
<achiang> fta: i keep experiencing SEGV when launching chromium-browser on lucid/armel
<fta> achiang, can you get a backtrace?
<achiang> fta: no, i tried using the -dbg package last night, but this machine is so small that reading in all the symbols causes the initial fork to fail with -ENOMEM
<persia> Add more swap :)
<achiang> hm. highly specialized installer that doesn't create a swap partition... sigh
<fta> can't apport handle that?
<achiang> fta: i downloaded the maverick version of the package and it works fine (after also cherrypicking the latest libgconf2-4 from maverick too)
<fta> hm, weird, packaging wise, it's exactly the same
<persia> achiang, Add a swap file post-install.  If you're short disk, use a USB disk.  The point is just to collect the backtrace.
<achiang> i can use USB as swap?
<achiang> neat-o
<persia> Sure.
<persia> Either a swap partition or a swapfile on a USB partition.
<achiang> cool, i'll try that in a bit
<achiang> my afternoon task, i suppose
<persia> Note that USB doesn't tend to be fast, meaning swapping over USB is for the patient.
<achiang> fta: i'll try and collect data and file a bug report later
<alucardni> Laney: both commands return uscan could not find the needed tarball.
<alucardni> bzr: ERROR: Unable to find the needed upstream tarball: calibre_0.7.43+dfsg.orig.tar.gz.
<achiang> persia: this machine isn't fast to begin with, so i'm not too worried. :)
<alucardni> it seems upstream changed the location of tarballs
<persia> alucardni, apt-get source will give you the tarball, if nothing else works.
<fta> hm, on maverick+, i build with armv7=0, but not on lucid
<persia> What does armv7=0 mean in that context?
<fta> i think my test is wrong, it's supposed to be the opposite, build with armv7 everywhere but lucid
<persia> Lucid requires ARMv7 also: it was only pre-lucid that earlier instruction sets were supported.
<persia> Unless there's something special about the lucid chromium source that makes ARMv7 not work...
<fta> it triggers -march=armv7-a -mtune=cortex-a8 -mfloat-abi=softfp
<persia> Yeah, that should be applied for Lucid+
<persia> Jaunty and Karmic had different defaults for armel, but they aren't so interesting at this point.
<fta> http://paste.ubuntu.com/565500/
<persia> There's some work in Debian to define the armhf architecture: I don't know if that will end up in Ubuntu.
<persia> It would have different defaults.
<fta> i guess i need to see the backtrace before changing anything
<persia> I'd recommend building with arm_neon=0 though, as there are a number of cortex-a8 boards that don't support NEON.
<fta> the upstream defaults: http://paste.ubuntu.com/565501/
<fta> i set arm_thumb=1 everywhere
<fta> and armv7=0 when "ifneq (,$(filter 10.10 unstable development,$(DEBIAN_DIST)))"
<fta> DEBIAN_DIST             := $(shell lsb_release -ds | tr -d '()')
<persia> Very odd.  Debian armel should *never* be ARMv7, and Debian armhf should *always* be ARMv7.  Ubuntu 9.04 and 9.10 should not be ARMv7, and Ubuntu 10.04+ should be ARMv7
<fta> iirc, asac was happy with those choices
<persia> And there are any number of devices that support ARMv7 but not NEON for armel (although I think armhf expects NEON: I'm not sure)
<fta> and noone complained
<persia> I suspect nobody complained is the important part :)
<achiang> fta: got a backtrace for my chromium SEGV, but not sure how useful it is
<achiang> fta: wanna see it?
<fta> achiang, can you upload it in a bug?
<achiang> fta: http://pastebin.ubuntu.com/565557/
<fta> hm, all-threads
<achiang> fta: i can make a bug, just wanted to run it by you quickly first to see if it was even worth it with such a weak stacktrace
<achiang> fta: i don't have working apport on this machine, is there any information you'd like me to collect?
<fta> achiang, i don't get much arm bug reports, so i'm not sure what to expect for this arch. is it supported by apport?
<fta> oh
<fta> i provide some apport hooks in the package, can you try to run it? (it won't help for the crash though, just the context)
<achiang> fta: how do i do that?
<achiang> sorry, i'm not very familiar with the tool
<achiang> it doesn't produce a core file or anything on the SEGV
<fta> python /usr/share/apport/package-hooks/chromium-browser.py
<achiang> kill the gdb instance
<achiang> ?
<fta> if you can collect those: https://wiki.ubuntu.com/Chromium/Debugging
<fta> and "info registers"
<achiang> ok, thanks
<achiang> fta: how do i figure out which package's -dbg package to install, given the top stack frame?
<achiang> fta: ah cool, apport is running now
#ubuntu-motu 2011-02-11
<blackmoon-105> hi, i'd want to keep updated and fix bugs for the freepops package (i want to be a mantainer), i've already create a project on launchpad for this.
<blackmoon-105> now i must only download the source code from ubuntu fix it and reupload?
<micahg> blackmoon-105: it would actually be best if you have an interest in a single package to work with the Debian maintainer and have all the uploads go through Debian except if a fix has to get in before a deadline
<persia> blackmoon-105, And to be clear, no we're not trying to make you run through a maze.
<persia> The *best* way to maintain a single package is to work on it upstream and ensure it works well in Ubuntu.
<persia> This is made easier if you work in Debian, as it eases communication with the Debian maintainer.
<persia> This is also made easier if you have handy access to the upstream code changes, which is why you might set up a vcs-import branch on LP, so you can cherrypick.
<persia> *but* if you just want to fix a bug, you can do that in Ubuntu ignoring all the rest of it.
<persia> We MOTU tend to focus on the bugfixes, rather than any sort of package maintenance.  We fix the bugs in Ubuntu, and try our hardest to ensure the bugs are fixed in other places.  Because of this, we often recommend *starting* in the other places, because then the bug only has to be fixed once.
<blackmoon-105> persia: i tought to maintain it for keep the pakage updated
<blackmoon-105> and other minor fixes
<persia> Yes, a package maintainer will keep the package updated and perform minor fixes.
<blackmoon-105> because freepops from ubuntu repo doesn't work as well
<persia> But there are no maintainers in Ubuntu.
<persia> So, we're happy to help you with specific tasks (fixing a bug, updating the package), but we're likely to encourage you to take each change and coordinate with the Debian maintainer and the upstream developers.
<blackmoon-105> i'ma alreandy in contact with th debian developer
<persia> If you're working on *lots* of packages, you'll fit in fine.  If you are working only on one package, you'd probably find working directly with upstream (being their liaison into Ubuntu), and with the Debian maintainer (watching Ubuntu bugs, forwarding patches, coordinating, etc.) more satisfying.
<persia> Excellent.
<persia> So, easiest way to handle things from an Ubuntu perspective is to make the package perfect in Debian, and file a sync request
<persia> !sync
<ubottu> Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
<blackmoon-105> i'm workin ganly with this package and i've got the working ones in my ppa..
<blackmoon-105> i've already submitted all patches to the debiam mantainer but
<blackmoon-105> the apply of the changs is not standard
<blackmoon-105> and without a trick are not applied in ubuntu
<blackmoon-105> wich build a debian version without the ubuntu changes
<persia> What?
<persia> Which package?
<blackmoon-105> freepops
<persia> So, the latest version I see in debian is .02.9-4.2, which is the same as the latest version I see in Ubuntu.
<persia> Did it not build correctly?  What went wrong?
<blackmoon-105> persia: no it's build correctly..
<blackmoon-105> but it doest work fine
<blackmoon-105> for example
<blackmoon-105> freepops it's a demon wich start at boot but in ubuntu without the patch doesn't do it
<blackmoon-105> then
<blackmoon-105> some other minix thinng like the entries in the menu (for the plugin updater) are not shown in k/ubuntu
<blackmoon-105> if you grab the source
<blackmoon-105> under the buildfactory directory you'll see a  "debian-ubuntu" and "debian-ubuntu-dapper"
<blackmoon-105> for get the pakage to work correclty con content of this directories must be copied under "debian" dir before compile it
<blackmoon-105> once at time
<persia> What?  Why?
<persia> There should exist a debian/ directory that works well for both Debian and Ubuntu.  All the other packages have one.
<blackmoon-105> persia: it should...
<persia> Can you create one that works?
<blackmoon-105> yes i've created a working packages for all release of ubuntu: https://launchpad.net/~marco/+archive/freepops
<persia> blackmoon-105, Does that package work also for Debian?
<blackmoon-105> persia: i don't know
<blackmoon-105> persia: i know only that debian work fine with the standard version of the package
<blackmoon-105> persia: do you think the there is a way for fix it?
<blackmoon-105> this is one of the reasons why I asked if I could be the package maintainer (or working directly with the ubuntu team)
<persia> blackmoon-105, Sorry: got distracted by local events.
<persia> I suspect there is a way to fix it so that it can work with one debian/ directory for both Debian and Ubuntu.
<persia> What trick is missing?
<blackmoon-105> the trick is to copy (with "make -C buildfactory debian-dsc-ubuntu") the contents of "debian-ubuntu" in "debian"
<blackmoon-105> the same for "debian-ubuntu-dapper" (when build the dapper packege)
<persia> Ah, that's not something we can do.
<blackmoon-105> persia: the only thing maybe is to get the debian source and apply the ubuntu pathes every time before build...
<persia> I'm looking at the differences in debian/ for your maverick version to the version we ship in maverick.
<persia> You've removed the build-dep-indep on luadoc: does that not affect building documentation?
<persia> You've added a dependency on the "menu" package: best to get this from ${misc:Depends} or not at all.  Note that the menu package is not used at all in the production of menus by default for any Ubuntu flavour.
<persia> You've added some manual stuff to the postinst: are you sure this wouldn't be better handled with dh_installinit?
<persia> Importantly, you appear to be ignoring the user feedback from debconf about whether they want freepops to run as a daemon, which seems unfriendly.
<persia> You've removed the comments from the debconf templates: not sure why.
<persia> You've added a .desktop file: *excellent*.  Note that you don't have to add usr/share/applications to *dirs: putting it in *install is sufficient.
<persia> We don't generally like tools that download random code from the internet, so the freepops-updater scripts aren't very interesting.  We'd prefer to see the plugins packaged, and the updates available managed through the repository.
<persia> There's fuzziness in the translations: this ought be fixed.
<persia> You may find using "install -D -m 644 modules/src/winsystray/freepops-32.xpm ${CURDIR}/debian/freepops/usr/share/pixmaps/freepops.xpm" and similar more satisfying in debian/rules, but it's lots easier to use freepops.install and install with that (man dh_install)
<persia> So, in summary, I think you can achieve your goal of getting it to show in the menu more easily by submitting the .desktop files to Debian, and installing them with dh_install.
<persia> You may want to discuss the postinst, and what might be happening with the debian maintainer.  I suspect that the default is to not start the daemon (which is both normal and correct), and since Ubuntu doesn't show unimportant questions, the user is never asked, so it never starts.
<blackmoon-105_> opps
<persia> Does all that make sense?
<blackmoon-105_> now i check..
<blackmoon-105_> persia: but without the menu package this work again?
<persia> The menu package has to do with the .menu files, not .desktop files.  Completely unrelated to the change you are trying to accomplish.
<blackmoon-105_> ah ok
<blackmoon-105_> i don't have understand this: Importantly, you appear to be ignoring the user feedback from debconf about whether they want freepops to run as a daemon, which seems unfriendly.
<blackmoon-105_> [sorry but i'm very tired, here are 5 a.m.]
<persia> Feel free to take a break and ask again later if you'll be more productive.
<persia> So, you modified the postinst.
<persia> And ou commented out the line that checked the value from db_get freepops/init
<persia> And then you *always* run the invoke-rc.d and update-rc.d calls.
<blackmoon-105_> i've i've modified postinit because with the standard one the demon doesn't start..
<persia> But the user is asked by debconf "Start freepopsd automatically after each boot?" and you should only start it when they answer "yes".
<persia> It's not starting because the user is answering no by default.
<persia> Which is correct behaviour.
<persia> The other way to do it is to remove the debconf question, and use dh_installinit.
<persia> But the debconf question is there for a reason: you might ask the debian maintainer.
<persia> Note that the user can get it to start on every subsequent boot with `dpkg-reconfigure -plow freepops` and answering the question "Yes".
<blackmoon-105_> ah ok
<blackmoon-105_> persia: other things?
<persia> hrm?
<blackmoon-105_> there are other things to report?
<persia> Not that I see obviously.
<blackmoon-105_> ok :)
<persia> But if you talk with the Debian maintainer, and investigate each of your changes, I'm sure you'll get better feedback there.
<persia> If you don't understand something, or behaviour is different in Debian and Ubuntu and you don't understand why, feel free to ask here.  We're always happy to help.
<persia> And thanks a lot for trying to fix this package.
<blackmoon-105_> the changes i've made are all submitted to debian developer wich have uploaded cvs and he say to me to do "make -C buildfactory debian-dsc-ubuntu"
<blackmoon-105_> i know that he used this tecnique also for build packagese for debian etch
<persia> blackmoon-105_, Is there a reason that the changes are not suitable for Debian directly?
<blackmoon-105_> maybe because some libraries wiche are not present in the old releses of debian are build staticaly inside the demon
<blackmoon-105_> and in the earlier version are used as external packeas
<blackmoon-105_> *packages
<blackmoon-105_> if i remember goog, this is the reason of this thing
<persia> Where is that in your changes?  I didn't see it, or is it in 2.9.5 and new from 2.9.4?
<blackmoon-105_> no this is on old change
<blackmoon-105_> this thing came with one of first release..
<blackmoon-105_> sorry but now i must to go to sleep because i'm veeery tired...
<blackmoon-105_> thank oyu very much for help :)
<persia> Sleep well.
<blackmoon-105_> thank you
<blackmoon-105_> bye :)
<udienz> micahg, around?
<goesspoerr> !ping
<ubottu> ping-pong, a fun game for all the family
<dholbach> good morning
<kklimonda> tumbleweed: oh, btw - you did sponsor two of my hamster-applet uploads afair. Would you mind commenting on my motu application?
<kklimonda> (I do seem to gather endorsments at a really slow pace :/)
<tumbleweed> kklimonda: sure
<kklimonda> https://wiki.ubuntu.com/KrzysztofKlimonda/MOTUApplication
<kklimonda> if you need bug numbers I think I can dig them out - I don't keep as good track of them as ari-tczew, but I did gather what I could find.
<tumbleweed> geser: yay, web_link was on my todo list :)
<geser> tumbleweed: there is one occurance left: in manage-credentials before the function can be removed
<udienz> does anyone interest to maintain poedit in Debian?
<micahg> udienz: did you need something?
<udienz> this packages is orphaned, see debian bug 607749
<ubottu> Debian bug 607749 in poedit "poedit: Old version at repository" [Minor,Open] http://bugs.debian.org/607749
<udienz> micahg, this packages is outdated. i'm totally care this package, because i use this package
<udienz> for translating
<tumbleweed> udienz: looks like there's an adopter in the wings. debian bug 543856
<ubottu> Debian bug 543856 in wnpp "ITA: poedit -- gettext catalog editor" [Normal,Open] http://bugs.debian.org/543856
<micahg> yep
<micahg> and a new version on mentors.d.n
<udienz> glad to hear that, so we can sync easily
<akoskm> hi! I'm building more packages within a single rules file with two *.install files, after the build finished and the packages are getting generated dh_duilddeb is adding "all" after the version number and before .deb in the package names, how can I avoid this? The packages names are differ so I don't need that extra "all" in them.
<udienz> micahg, sorry about bug 712918, i have problem in database, well i'm not very good in database
<ubottu> Launchpad bug 712918 in phpwiki (Ubuntu) "Please update to 1.4.0rc1" [Wishlist,In progress] https://launchpad.net/bugs/712918
<udienz> so i'm not confident to take care phpwiki
<micahg> udienz: ok, no problem, should I file for removal then?
<udienz> micahg, ok, and thanks
<udienz> i will try to update other software
<micahg> udienz: that would be great, thanks
<udienz> micahg, anyway what your suggest about 717168, we will waiting from debian or upgrading it?
<udienz> rrr bug 717168
<ubottu> Launchpad bug 717168 in poedit (Ubuntu) "Please update poedit to 1.4.6.1" [Undecided,Confirmed] https://launchpad.net/bugs/717168
<akoskm> nevermind, that was so lame. I have to admit
<micahg> udienz: it's on mentors, if it can get sponsored in the next 2 weeks, that would be good
<udienz> tumbleweed, is pull-debian-source need debian-keyring package? after i do pulling from debian an packages won't extracted, and tells me to install debian-keyrings. why debian-keyrings not Suggested in d/control?
<tumbleweed> hmm, it probably should be. or it should only check the sig when it can't get the dsc from lp
<udienz> tumbleweed, yup. failed when check the signature
<tumbleweed> udienz: file a bug and I'll sort it
<udienz> tumbleweed, done. bug 717245
<ubottu> Launchpad bug 717245 in ubuntu-dev-tools (Ubuntu) "Please suggest debian-keyrings" [Undecided,New] https://launchpad.net/bugs/717245
<AnAnt> Hello, can someone explain this FTBFS to me: http://launchpadlibrarian.net/64059164/buildlog_ubuntu-natty-i386.git-buildpackage_0.5.19_FAILEDTOBUILD.txt.gz
<ScottK> AnAnt: I'd guess something's up at gbp/git.py line 502, but I didn't look at the source.
<AnAnt>         except ValueError, err:
<geser> when I look at http://git.debian.org/?p=users/agx/git-buildpackage.git;a=blob;f=gbp/git.py;h=1ecab9f1767dc124bc3d77273518dbac1e60a8e3;hb=HEAD#l502 I don't see why it should fail
<geser> barry: ^^ any idea on this?
<AnAnt> I suspect pychecker or python2.7 (or the mix of both)
<AnAnt> there was a problem in pychecker with python2.7 , but that got fixed upstream (& uploaded to natty)
<AnAnt> got to sleep
<AnAnt> bye
<barry> geser, AnAnt: looks like a bogus pychecker warning to me
<Rhonda> Hmm, having troubles creating a cowbuilder chroot â¦
<Rhonda> sudo cowbuilder --create --basepath ./natty --distribution natty --mirror http://at.archive.ubuntu.com/ubuntu/
<Rhonda> That gives me a lot of "ln: creating hardink `/var/cache/.../$package': File exists" messages.
 * Rhonda tries sudo rm /var/cache/pbuilder/aptcache/*.deb
<Rhonda> humpf, now it fails with "Package 'cowdancer' has no installation candidate"
#ubuntu-motu 2011-02-12
<AnAnt> barry: do you think that the git-buildpackage FTBFS is actually a pychecker+python2.7  problem ?
<ari-tczew> hello
<ari-tczew> wgrant: this page seems to be hanged: http://qa.ubuntuwire.org/multidistrotools/all.html
<achiang> if i say override_dh_auto_build, and pass a -I/path/to/include on the make line, is that additive, in addition to the paths autotools already know about? or does it replace any existing values?
<simar> Hi
<simar> I have a question.. If I create a chroot using pbuilder-dist for natty like
<simar> $sudo pbuilder-dist natty create
<simar> can I have another chroot pbuilder using say .. pbuilder-dist maverick create and maintain them side by side??
<geser> yes
<ScottK> Don't call pbuilder-dist with sudo.  It handles escalation and using sudo when needed.
<ScottK> But yes.
<simar> Thanks
<simar> ScottK, But I have already called it with sudo and its building my enviroment for natty. I hope it will not cause any harm..??
<simar> I used this sudo pbuilder-dist natty create
<ScottK> simar: Should be fine, but it's not the best way to do it.
<ScottK> pbuilder-dist natty create would have worked too.
<simar> ScottK, ok, so I will try this in future .. and for the one that I'm going to build for maverick..
<simar> ScottK, But do I need to rebuild for natty or it will work for my purpose. i'm a beginner
<ScottK> simar: I think it will.  Worst case it puts some files in the wrong place and you have to move them a bit.
<ScottK> You won't need to redo it.
<simar> ScottK, ok I will hope it will work.. if it don't I will ping you then..
<simar> ScottK, Thanks for help :))
<ari-tczew> siretart: I have prepared a patch for you - libva ;-)
<broder> i'm putting my first dep-5 copyright file together. there's a COPYING file at the top-level. most files have copyright/license headers (that match the COPYING file), but a few short ones don't. i know the author and know that his intent was for the COPYING file to apply to all files. can i just do a single Files: * block?
<broder> also, did the papercuts guys (vish?) ever come up with guidelines on how package descriptions should be written?
<persia> broder, When dealing with that sort of thing, I usually make an estimate about whether the content of a file is worth copyrighting (short files without expression may not be).
<persia> If it is, best to get upstream to fix it (people failing to add copyright/licensing information to XML is the most common case I see).
<persia> In the case of autotools files, I've seen a number of folk add extra clauses to a DEP-5 copyright.
<persia> But the important thing is that you are representing the state of the files *as they are published*, rather than by a guess at author intent (some folk embed email from authors in debian/copyright to clarify things).
<persia> And that requirement isn't different between DEP-5 and other types of debian/copyright files.
<broder> *nods*
#ubuntu-motu 2011-02-13
<jmarsden> Where can I find info on the Ubuntu ISO build process -- how a Ubuntu desktop CD gets created from a package list and pointers to repositories?  Debian has live-helper, which sort of works for Ubuntu, but doesn't seem to be "the official way".  Is there a wiki page or a package or *something* that I can look at to see "how Ubuntu generates its official ISOs"?
<broder> jmarsden: live-cd rootfs generates the live filesystem for the iso. i don't know where the scripts live that actually generates the iso from that, though
<jmarsden> OK, that's a start, thanks.
<broder> if you're trying to build your own livecds, https://help.ubuntu.com/community/LiveCDCustomizationFromScratch is good and is "close enough for government work" to what ubuntu generates
<psusi> hrm... I'm trying to do a redirection in a bash for loop and the shell keeps giving me the > prompt like it wants more... I guess it is interpreting the > early rather than as the body of the for loop... I tried escaping it with \ and that did not help
<psusi> nevermind... must have had a typo
<persia> jmarsden, More comprehensively: the the seeds are processed by launchpad to generate tasks with cron.germinate, and the tasks are used in livecd-rootfs to build the life filesystems.  The live filesystems are embedded into the images with debian-cd (check the branch on LP, not the package: the package is unmodified in Ubuntu)
<persia> The images are then built using ubuntu-cdimage (check LP for branches), but this is just a collection of cronjobs and utilities that drive debian-cd.
<jmarsden> persia: Thanks :)  germinate I know of, debian-cd I did not know about until you mentioned it :)
<persia> jmarsden, At a high level, what are you trying to accomplish?  A remix?  A new flavour?  Troubleshooting an issue?  Just tweaking images?
<jmarsden> Troubleshooting an issue with the latest Lubuntu Alpha2 (checksum mismatch) and also hopefully understanding this enough to help Julien with Lubuntu until such time as it is official enough to use Ubuntu build infrastructure.
<jmarsden> persia: So my goal is to see if I can duplicate "how Ubuntu does it" locally, as a first major step.
<persia> Right.  I've been procrastinating about Lubuntu too long.  I'll put something on the wiki (note that it will only be draft)
<jmarsden> Thanks :)
<persia> "How Ubuntu Does it" gets a little complicated: livecd-rootfs runs in a natty environment on target architecture, but debian-cd runs on lucid on i386.
<jmarsden> Hmmm.... OK... well, I use virtualbox VMs quite a bit, maybe I need to get into kvm instead to set this all up.
<persia> I think the natty environment is essentially a buildd chroot.
<persia> Well, with some extra packages installed.
<persia> And, unless something is going wrong, it oughtn't matter that debian-cd is running on lucid, because it's branch code anyway.
<persia> (sometimes things do go wrong: I remember backporting some boot thingy to hardy at one point to fix one of them)
<jmarsden> OK.  My primary workstation here is Lucid... so it sounds like I should do the livecd-rootfs stuff in a Natty VM to be safe?
<persia> I'd suggest a natty chroot.
<persia> If you have ubuntu-dev-tools installed, `mk-sbuild natty` may be enough (I forget if that was lucid or maverick)
<persia> If that doesn't work, pbuilder is probably the best quick choice.
<vish> broder: hey, for package description guidelines https://wiki.ubuntu.com/SoftwareCenter/PackageDescriptions is the start
<vish> broder: we still need to co-ordinate with debian to get their guidelines updated, the person in-charge of that task retired from Ubuntu, so I'll have to pickup the tasks or find someone who is free..
<broder> thanks, that's helpful
<vish> np..
<persia> vish, If you're involved in that, could you encourage folk to get descriptions to also meet the following two guidelines:
<persia> 1) The short description should complete the cloze "${PACKAGE} is ${SHORT DESCRIPTION}"
<persia> 2) The long description should provide enough information, even if the package name and short description are not presented.
 * micahg thought having the package name in the short description gives a lintian error
<persia> micahg, It does.  It can be confused by capitalisation changes, etc.
<vish> persia: why does short description have to repeat the package name?
 * vish curious..
<persia> It doesn't.
<persia> It completes the cloze.
<vish> and what does "cloze" mean ? :)
<persia> It should not include the package name, or any copula, but rather assume both will be presented by the package manager.
<jmarsden> clause :)
<persia> No, cloze
<persia> http://en.wikipedia.org/wiki/Cloze
<vish> yea, i dint expect persia making two consecutive typos :)
<persia> One is indeed common though :)
<broder> persia: the second is already dictated by Policy, i think
<jmarsden> So... the short description "is an exercise, test, or assessment"  ?
<persia> broder, Both are dictated by policy.  Sometimes the folks that put together the user experience specifications aren't intimately familiar with policy.
<vish> yea, the (2) is is given, long descriptions are not meant to depend on the short description, but i dont see any harm in adding that guideline..
 * vish still trying to understand (1)
<persia> So, let's say I have a package lksdf
<broder> vish: it means the short description sholud be something like "a tool to do foo", so that if you stick "PACKAGE is" before the short description, the whole sentence makes sense
<vish> ah!
<persia> And I want the description to be "lksdf is a utility to render any text meaningless"
<persia> So, I need to have a short description "utility to render any text meaningless"
<persia> or "a utility to render any text meaningless"
<vish> persia: yea, right, that is what is already mentioned in the guidelines
<vish> or was ?
<persia> I didn't see it in a quick read.  I'll look again.
<vish> let me check, but i recall discussing that with mpt, he dint want the package name repeats in the description
<persia> In the long description?
<broder> vish: lintian should yell at you if you do that
<persia> Not all the package managers show the package name when showing the long description.
<persia> broder, No, lintian only complains about the short description.
<broder> ah, sure
 * micahg keeps learning new words from persia
<vish> yea, long descriptions, in some of the description i updated last cycle, i made sure the descriptions are in line with your (1)
 * persia learned "cloze" in this channel years ago.
<persia> I'm not that fussed about whether long descriptions have the package name, but I don't think it's easy to write a paragraph or two about anything without naming it, unless one uses "this package" or "it" a lot, which I think is stylistically poor.
<vish> persia: in the avoid section, the "this package" one.. too many long descriptions start with that, but yea, it is not as clear as you mention
<persia> Saying "lksdf was written to provide auto-generated text with similar character frequency, average word length, and paragraph breaks to original text, while obscuring the original text, for use in typesetting and visual design applications." seems better to me than forcibly trying to avoid using the package name when describing it.
<vish> yup, http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis  first line is your (1)
<vish> more than the package name, the descriptions starting with "this package" were the offending one..
<persia> Indeed.  Those are bad.
<persia> It is because of those that my rule (2) exists.
<persia> (not that it's my rule, but that I numbered them)
<vish> i think we would need to update the debian guidelines too, http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-desc  mentions " Assume that the user has already read the package synopsis."
<vish> which does not necessarily mean long desc needs to depend on the short, but having that line is misleading..
<persia> That's just guidelines.  Not ideal, but easily worked around.  http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions is the bit to ensure you aren't violating without deep discussion.
<persia> Changing the guidelines may be as simple as filing a bug, and following up on it.
<persia> broder, And it appears we're both wrong: rule (2) above isn't mandated by policy, although rule (1) is somewhat implied by policy.
<udienz> Hi, is a new packages with need-packaging tag must subscribed to ubuntu-sponsors?
<udienz> a source already landed in revu
<persia> Is the packaging complete?  If so, sure.
<persia> Or you can ask for a review here.
<persia> Which package?
<udienz> persia, yup complete
<udienz> wait..
<udienz> persia, gkamus
<udienz> http://revu.ubuntuwire.com/p/gkamus
<udienz> http://revu.ubuntuwire.com/p/gbilling-client
<udienz> http://revu.ubuntuwire.com/p/gbilling-server
<persia> udienz: For gkamus debian/docs contains "NEWS" and "TODO" which just aren't interesting for end-users.  I'm suspicious that README is similarly uninteresting.
<udienz> ah.. ok. so it's better to removing d/docs?
<persia> Or just don't create it in the first place :)
<persia> I can't read README, so it might be interesting, but I suspect you'd do better to extract the interesting bits into debian/README.Debian
<udienz> persia, ok, i'm writing in english in d/README.Debian
<persia> Also, you've Debian-style versioning.  You want -0ubuntu1 if you're going straight to Ubuntu.  That said, this happens to be a great time to upload to Debian.
<persia> I'd recommend fiddling with dversionmangle in debian/watch for gbilling-client: this would be better with version 0.3.1~rc1-1
<micahg> udienz: I'm commenting on revu for gkamus
<persia> udienz: For both of them, I'm not sure why you need debhelper >= 7.0.50~ when you're using CDBS.
<udienz> persia, i'm not tested this packages in debian, so i'm not confident to uploading to debian
<persia> gbilling-server has all the same points as gbilling-client.
<udienz> i will ask debian-id to testing
<udienz> micahg, thanks
<persia> Heh, makes sense.  It ought work about the same.
<udienz> persia, and about debhelper it must be 7?
<persia> I don't know why you need debhelper 7.
<persia> Most CDBS packages do fine with debhelper 6.
<persia> But it doesn't matter how you do it, as long as you know why you are doing it that way.
<micahg> udienz: generally debhelper >=7.0.50~ is used the dh short for overrides are used
<micahg> s/the/when
<udienz> micahg, what lintian option you used? i use -iIEv --pedantic *.changes before i uploading to revu and i not got an errors
<persia> udienz, Did you build a binary and run it the binary changes as well?
<micahg> udienz: on the source or binary changes file?
<micahg> source is lintian clean, binary is not
<udienz> persia, yes. in ppa and running very well in my laptop
<persia> udienz, But did you run lintian on the binary?
<udienz> micahg,  source ah.. thanks
<udienz> persia, no sorry. i will fixing it
<persia> No need to apologize: that's why we do reviews :)
<persia> We all make mistakes, especially when packaging something new, because there's so many things to think about.
<udienz> hehe
<persia> Did anyone attend http://www.fosdem.org/2011/schedule/event/opengazer_dasher last weekend?
<persia> The upstream website I found seemed to indicate it was deprecated, but with the talk, I wonder if I'm just looking in the wrong place.
<Jayant> I had ubuntu 9.04 installed on a windows xp partition.  I upgraded directly to 10.10. Post installation I was prompted to restart. Upon boot I immediately get to a screen resembling windows command prompt. The error on screen is 'no such device : 9f5f4016-f31a-4af6-852f-4502712a528f. Then the next line is grub rescue>
<Jayant> I can access BIOS but can't even access the selection to boot winxp
<persia> This isn'T a support channel: you might try #ubuntu.
<persia> In general, the recommended upgrade path would be 9.04 -> 9.10 -> 10.04 -> 10.10
<Jayant> oops thanks :)
<persia> You might get away with 9.04 -> 10.04 -> 10.10, but no effort has been spent checking or testing 9.04 -> 10.10.
<udienz> ari-tczew, around?
<ari-tczew> udienz: yea. hi.
<udienz> ari-tczew, Hello..
<udienz> about bug 717654, both CVE already apllied in debian unstable
<ubottu> Launchpad bug 717654 in squid3 (Ubuntu) "Please merge squid3 3.1.6-1.2 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/717654
<ari-tczew> ubottu: I saw and I'm looking on squid3 right now :-)
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<ari-tczew> udienz: open your debdiff and look on line 25
<ari-tczew> this is a change in d/changelog
<ari-tczew> it's wrong
<ari-tczew> lines 25-34
<ari-tczew> you can remove it manually before submitting debdiff on launchpad
<udienz> ari-tczew, ok
<ari-tczew> udienz: I won't require forward a patch to Debian since there is new upstream available and I'd like to see fixed FTBFS on new tarball.
<micahg> ari-tczew: you should still upstream it and let Debian fuzz it when applying to the new upstream
<ari-tczew> micahg: still upstream it? sorry, I don't understand
<micahg> ari-tczew: FTBFS patch?
<ari-tczew> micahg: do you mean forward to upstream?
<micahg> ari-tczew: forward the linker fix to Debian anyways, no need to wait for new upstream version
<persia> Or forward it to Debian: warn the maintainer that they may have to do some work when importing the new upstream.
<ari-tczew> udienz: OK do it what they say above ^^
<ari-tczew> but personally I disagree
<persia> ari-tczew: Why?
<udienz> ari-tczew, i'll send it
<ari-tczew> persia: I have a lot cases when new upstream has got fixed FTBFS or FTBFS message was another than fixed in old tarball.
<ari-tczew> I had *
<persia> Oh, sure.  They key thing is that there is a potential issue, not that there is a real and firm issue.
<c2tarun> what is a symbol file and what is its use?
<ari-tczew> persia: when we will get to know new DMB crew?
<persia> ari-tczew: After the next meeting
<persia> c2tarun: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols
<udienz> ari-tczew, i send to debian and upstream
<ari-tczew> udienz: OK
<ari-tczew> udienz: I updated your debdiff and will upload it.
<udienz> ari-tczew, ok thanks!
<ari-tczew> bp
<ari-tczew> np *
<ari-tczew> udienz: did you look on bug 690068 ?
<ubottu> Launchpad bug 690068 in erlang (Ubuntu) "Please merge Erlang 1:14.a-dfsg-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/690068
<udienz> ari-tczew, yes. i try to fixing it in early days
<c2tarun> I found this line in manual of dpkg-shlibdeps "dpkg-shlibdeps  calculates  shared library dependencies for executables named in its arguments." what is meaning of executables here?
<micahg> c2tarun: binary files that are run
<jmarsden> c2tarun: ELF binaries, usually... things you can run
<c2tarun> can you please give me an example?
<jmarsden> /bin/ls
<ari-tczew>    /usr/bin ;)
<jmarsden> Right :)
<jmarsden> Well, I have /bin/ls on my system here...
<micahg> ari-tczew: /usr/bin is a directory :), not all files in there qualify (i.e. /usr/bin/firefox)
<ari-tczew> micahg: I know I wanted to fix directory of jmarsden's
<micahg> ah
<jmarsden> ari-tczew: type which ls and see what your system shows
<micahg> ari-tczew: no, he's right :P
<ari-tczew> oO
<ari-tczew> but usually /usr/bin/*
<ari-tczew> :>
<c2tarun> ok so dpkg-shlibdeps looks for the dependencies needed for buiding a package and add them to var file substvars. am I right?
<c2tarun> but if there is no symbols files or shlibs files then?
<jmarsden> c2tarun: Needed for *running* the executables in a package, I think.  By the time it runs you have already built the package...
<jmarsden> So the build deps are already installed...
<micahg> jmarsden: I think the questions is about filling ${shlibs:Depends} in the binary depends
<c2tarun> sorry I am not getting, what do you mean by running the "executables in a package"?
<jmarsden> micahg: Right, so that is not something "needed for buiding a package", but something needed at package run time...
<micahg> jmarsden: ah, right :)
<jmarsden> c2tarun: if you have a package that compiles hello.c into hello and installs that as /usr/bin/hello, then dpkg-shlibdeps will check what shared libraries the binary file hello which you compiled needs.
<jmarsden> c2tarun: For example, run    ldd /bin/ls    to see what shared libraries that program needs :)
<persia> This then populates ${shlibs:Depends} so that you don't have to fiddle with nm and set the dependencies manually.
<c2tarun> jmarsden: ldd works fine and I am getting the list of dependencies. but I failed to find any file in /var/lib/dpkg/info/package.shlibs OR package.symbols
<jmarsden> Not all packages currently in existence come with symbols files.  Most likely coreutils does not provide such a file.
<jmarsden> c2tarun: What is the real reason for all your experimenting with dpkg-shlibdeps ?  What exactly are you needing to do?
<c2tarun> jmarsden: I was reading this manual page on symbols https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols I fixed on upgrade bug and the one who sponsored my bug suggested me to use symbol files from next time as this may be useful for them.
<jmarsden> OK.  So the sponsor is telling you this would be a useful enhancement to that particular package.  Not that all packages already have symbols files.
<persia> Only packages that supply shared libraries should have symbols files.
<micahg> bug 713492 started all this
<ubottu> Launchpad bug 713492 in ccscript (Ubuntu) "Newer Version Available" [Wishlist,Fix released] https://launchpad.net/bugs/713492
<c2tarun> jmarsden: please check bug 713492 and second last domment
<c2tarun> micahg: yup :) I was looking for that bug only :)
<c_korn> hm, transmission requires libevent version 2.x. in natty there is still 1.x.
<ari-tczew> c_korn: so get libevent 2.x. :)
<c2tarun> micahg: all got busy :( anyway can you suggest me something about symbol files. Should I look deeper into it?
<micahg> ari-tczew: that affects a lot of packages in main, it should be discussed if the desktop and server teams want that transition this cycle
<jmarsden> c2tarun: The sponsor is suggesting you could add a symbols file to that package, the next time you update it (sponsor seems to imply he hopes you will continue to have a relationship with this package!).  Sounds like a good idea to me :)
<micahg> c2tarun: seems like you've been pointed in the right direction
<c_korn> ari-tczew: it is still in experimentalâ¦ http://packages.debian.org/experimental/libevent-dev
<c2tarun> jmarsden, micahg: Thanks :) I'll try to understand about symbol file and include them from next time
<ari-tczew> micahg: I'm not suprised. natty+1 will include a lot of transitions and rebuilds
<micahg> c_korn: I'd suggest filing a bug if there's not one already, if we're not doing the transition, transmission should probably be downgraded
<c_korn> micahg: what do you mean with downgraded? transmission 2.21 (which requires libevent 2.x) is not even in natty
<micahg> c_korn: oh, ok, I thought you were referring to 2.13
<c_korn> no, this one still depends on the old libevent
<micahg> ah, good :)
<c_korn> ok, bug 701471 is about the transition
<ubottu> Launchpad bug 701471 in libevent (Ubuntu) "Sync libevent 2.0.10 from Debian experimental" [Wishlist,Incomplete] https://launchpad.net/bugs/701471
<c_korn> hm, can't be installed side-by-side with 1.x. and has a rather long reverse depends list on the universe repository
<c_korn> so what needs to be done is to install the libevent 2 package and to see whether all reverse depends still build from source and work properly ?
<micahg> I'd vote for not doing that transition this cycle since there's enough to do already before release
<c_korn> my concerns are mainly about the transmission package. we would stay out of date for another six months and we already are only shipping 2.13 in natty while upstream released 2.21. another option would be to patch it to use libevent 1.x if it is possible.
<micahg> c_korn: I'd suggest bringing that up to the desktop team
<c_korn> should I subscribe the team to the bug?
<micahg> c_korn: that's one way, or you can send a mail to the ubuntu-desktop ML
<chrisccoulson> please *don't* do anything with libevent until you've spoken to kklimonda first. I'm sure he has already looked at the feasability of upgrading that
<chrisccoulson> and from what i remember, there is a good reason we are still on the old version
<kklimonda> c_korn: 4 packages ftbfs with 2.0.10
<chrisccoulson> there we go :)
<kklimonda> c_korn: one can be dropped, one I've probably ported, one has to be updated by the debian maintainer after testing (and he hasn't told me yet what the status of his tests is)
<micahg> kklimonda: are those the main packages or the universe ones
<kklimonda> c_korn: that leaves us with one package that fails its tests because of some internal changes in the libevent http implementation
<persia> micahg: In practice, both need porting, really.
<kklimonda> and, because this one fails tests after successfully building, I'm not really sure what's the status of all the other packages that did build.
<micahg> persia: indeed, just wondering if the universe ones have been looked at at all ;)
<kklimonda> micahg: all that fails are in universe
<kklimonda> c_korn: I'll add this to the bug report, along with the link to the PPA, where I did try a transition
<c_korn> kklimonda: ok, thanks for the detailed information. so for now I will just follow the bug report if there isn't anything else I can help you with the transition â¦
<kklimonda> c_korn: well, if you know C you can read my comment in bug 701471 - actually, you can read it anyway, but if you know C you could help me with ladvd and honeyd :)
<ubottu> Launchpad bug 701471 in libevent (Ubuntu) "Sync libevent 2.0.10 from Debian experimental" [Wishlist,Incomplete] https://launchpad.net/bugs/701471
<c2tarun> what is package-build-dir
<kklimonda> c_korn: if I can get those two ported, and lua-event updated, we could go with transition and work on any bugs after they are reported.
<kklimonda> if not I'll poke Transmission devs to rebundle libevent2 with their source, or do it myself.
<geser> kklimonda: for honeyd: I didn't look yet at the errors but also saw some warnings about implicit declarations, it would be good to add the missing headers to those source files
<kklimonda> geser: I can give you the patch for honeyd, I have ported it already :)
<kklimonda> but I'd like someone to check it, and maybe help me testing it.
<geser> honeyd from your PPA is not ported yet?
<kklimonda> geser: no, I'm uploading it now
<persia> c2tarun, Usually the directory that contains the debian/ directory, although it's possible to arrange things differently with some build systems.
<c2tarun> persia: ok, can you please tell me how to use dpkg-gensymbol I tried by this command "dpkg-gensymbols -pccscript -Pccscript-4.2.0/" but got errors that no changelog found
<persia> Where did you run that command?
<c2tarun> just outside of the folder that contains debian
<persia> And does debian/changelog exist?
<c2tarun> persia: yup it exist look at this pastebin http://paste.ubuntu.com/566609/
<c2tarun> ccscript-4.2.0 is the folder that contains debian/changelog
<persia> You need to be in ~/source/ccscript/ccscript-4.2.0/ when you run it, not in ~/source/ccscript
<c2tarun> persia: I think it worked (because there is no error) but where is the symbol file?
<persia> I forget: been a while since I did it.  Might be in debian/ but I seem to recall it being printed to stdout
<c2tarun> persia: I am not able to understand stdout but on running this "dpkg-gensymbols -pccscript -Pccscript-4.2.0/ > temp.sym" I found an empty temp.sym file
<persia> This is after you built the package?  That's unexpected.
<Laney> I think your -P parameter isn't quite right â are you in a tree with the package built?
<c2tarun> Laney: what do you mean by "tree with the package built"?
<Laney> are the build results somewhere under debian/?
<persia> c2tarun, Have you previously run something like `debuild -b` in the package directory?
<c2tarun> Laney: I dont think so if by build results u mean the source.build file then they are outside of ccscript-4.2.0
<c2tarun> persia: ya debuild -S
<persia> c2tarun, That only builds the source.  You need to build the binary locally before you can run dpkg-gensymbols
<c2tarun> persia: how to do that?
<c2tarun> persia: and what is difference between building the source and building the binary locally?
<persia> `debuild -b`
<persia> It generates a binary package, rather than a source package.  It also builds everything so you have the unpacked build in the packaging directory.
<Laney> dpkg-gensymbols works by scanning the actual .so files to see which symbols are exported, and for that you need to have them available i.e. you have to have built the package
<c2tarun> persia: I got this error http://paste.ubuntu.com/566614/
<persia> Then install your build-dependencies.
<c2tarun> persia: ok, they are getting installed it will take some time. I have one question by source package you mean source.build file?
<persia> No.
<c2tarun> Then?
<persia> A source package is a .dsc file and any files referenced in that .dsc file.
<persia> A binary package is a .deb file.
<c2tarun> persia: ok :) got it.
 * persia begins to wonder if a binary package ought be considered the union of a .deb and a .ddeb
<c_korn> kklimonda: is it enough for testing to have a natty chroot ?
<kklimonda> c_korn: for packages that don't have a gui it should be enough
<persia> Even for packages with a GUI, it can be enough, if the package doesn't care about what X server it is rendering against (most packages don't)
<persia> But it can be a little tricky setting up a chroot to connect to a local X server (schroot -p contains most of the magic, and there are other ways)
<kklimonda> great, gearmand has been synced and its tests also fail with libevent2
<c_korn> I have already a maverick schroot here.
<kklimonda> hmm, may be my fault..
<kklimonda> or not.. hmm
<kklimonda> can someone take a look at http://tinyurl.com/6xydhg3 (built fine) and http://tinyurl.com/6dran36 (failed) and tell me if they see any difference?
<kklimonda> the failed build seems to be running tests twice..
<c_korn> well the libevent version is a difference of cource. but I doubt you mean thatâ¦
<kklimonda> no, but it does seem to break something subtle in tests.. it may not be a good idea to touch it now after all.
<kklimonda> meh, I still have some time to work on it. I'll try it later
<c_korn> ok, my natty schroot is now ready
<c_korn> ok, so this is the rdepends list http://pastebin.com/3tMzEKXq
<kklimonda> yes - you can get new packages from https://launchpad.net/~kklimonda/+archive/libevent2/+packages, we can split it between two of us and see how many of them we can test
<kklimonda> c_korn: transmission will work, so should php5
<c_korn> ok, fine
<kklimonda> we could create a quick wiki page, where we put things we have tested, what we are testing, and what should be tested
<kklimonda> this way we can coordinate it
<c_korn> good idea. better coordination than pastebin texts :)
<c_korn> if we split it this way? http://pastebin.com/xUs0U2db
<c_korn> I have lunch now. will begin work after it.
<c_korn> bbl
<kklimonda> c_korn: I'd rather do it this way: create a list of packages to test in a simple table, where we can put TESTED, TESTING, NEEDS TESTING states. This way we don't have to reevaluate the split at some point when one of us runs out of things to work on ;)
<kklimonda> c_korn: something like this: https://wiki.ubuntu.com/KrzysztofKlimonda/Libevent2Transition
<micahg> kklimonda: you might also want to check with the server team to see if they're ok with this transition
<kklimonda> micahg: good point
<micahg> kklimonda: for main, it you + 3 packages the server team owns
<micahg> s/owns/cares about/ :)
<kklimonda> *nods*
<kklimonda> if a sponsor is interested in sponsoring some merge how should he proceed? Should he remove ubuntu-sponsors from the reviewers, and add himself to indicate that he's working on it?
<micahg> kklimonda: yes
<kklimonda> micahg: so the merge disappears from the sponsorship queue
<micahg> kklimonda: you can set to in progess and assign to you, then unassign before uploading
<kklimonda> micahg: now, if there are issues with the merge, it can take a while to do that.
<micahg> kklimonda: well, a few hours is fine, a few days, less so
<kklimonda> indeed, but the bottom line is that someone else may not be aware of this merge, and will upload his version instead.
<kklimonda> (which did happen with my merge of hamster-applet ;))
<micahg> kklimonda: if there's a merge bug filed, someone should check that before working on it
<kklimonda> micahg: sure, but LP is slow ;)
<micahg> kklimonda: shouldn't be that slow anymore
<micahg> kklimonda: BTW, I'm unsubscribing sponsors from the libevent bug
<kklimonda> micahg: sure
<kklimonda> there is nothing to sponsor yet :)
<c_korn> kklimonda: ok, thanks for the list. I am testing now
<c2tarun> I got this error while building the binary package http://paste.ubuntu.com/566647/
<ari-tczew> c2tarun: update pbuilder
<c2tarun> ari-tczew: actually I have multiple chroot environments of pbuilder so i use pbuilder-dist. how to update that?
<ari-tczew> c2tarun: pbuilder-dist natty update
<c2tarun> ari-tczew: but I think it failed to download some files, is it really due to not updating?
<ari-tczew> c2tarun: do it
<micahg> c2tarun: those versions don't exist anymore, so the files fail to download
<c2tarun> ari-tczew: sure :) I executed the command it'll take some time as I have very slow connection.
<geser> c2tarun: you need to keep your pbuilder updated (similar to your normal system) to let it know which packages in which version are in the archive
<c2tarun> micahg: so updating will solve the prob?
<micahg> c2tarun: yes, it should
<c2tarun> micahg: ok, thanks :)(
<petanilinux> !ping
<ubottu> ping-pong, a fun game for all the family
<petanilinux> salam
<AnAnt> wa alaykom as-salamu wa rahmatu Ullahi wa barakatoh
<petanilinux> anant : thx
<petanilinux> alhamddullilah
<ari-tczew> !language | AnAnt petanilinux
<ubottu> AnAnt petanilinux: Please watch your language and topic to help keep this channel family-friendly, polite, and professional.
<ari-tczew> I mean english. :-)
<geser> AnAnt: barry said "looks like a bogus pychecker warning to me" to your git-buildpackage problem
<petanilinux> ari-tczew, me indonesian langueage
<ari-tczew> petanilinux: nice, but here we prefer english :)
<ari-tczew> as universal language
<petanilinux> oke , no problem
<AnAnt> geser: yeah, I saw that. But then what ?
<AnAnt> geser: angelabad uploaded git-buildpackage with the old patch (disabling pychecker), but I am not sure that this is the right solution
<geser> not sure, probably disable it for this file
<ari-tczew> geser, persia: could you update DMB for date?
<ari-tczew> (DMB wiki agenda)
<paultag> Howdy, MOTU. Can I bump bug 666849 (backport bug -- anyone around from backports)?
<ubottu> Launchpad bug 666849 in maverick-backports "Please backport arduino (0021+dfsg-2) from natty to maverick" [Undecided,Confirmed] https://launchpad.net/bugs/666849
<paultag> it builds clean, and was tested
<paultag> looks like it's just stalled
<ScottK> paultag: MOTU and backports team aren't all the same people.  I'll have a look at it.
<paultag> ScottK: thanks, I'm a bit lost on the Ubuntu package teams - I've never been too involved with it :)
<paultag> so, please excuse the out-of-place remark :)
<c_korn> after compiling libdnsres with libevent2 it does not depend on libevent any longer. http://pastebin.com/hjwBipTB
<ScottK> paultag: No trouble.
<hyperair> c_korn: that looks like two things could have happened -- you ended up with those functions implicitly declared, or the shlibs of libevent2 are broken
<ScottK> paultag: Approved.
<paultag> ScottK: cheers!
<c_korn> how can I see the shlibs of the installed package ?
<paultag> c_korn: on a binary or on the package?
<c_korn> on the installed package. I know I could also look in the package's DEBIAN/shlibs file
<paultag> c_korn: either ldd on a binary, or shlibs
<paultag> ah
<paultag> humm, I don't know there's something for that
<c_korn> this is the shlibs file in the libevent-2.0.5 package: libevent-2.0 5 libevent-2.0-5 (>= 2.0.10-stable)
<paultag> c_korn: not sure, really
<paultag> c_korn: if you're looking for what a binary is linked against, ldd might help, but other then that, I'm not sure there's much in place
<paultag> c_korn: and if you're working on that package, it has hella issues
<c_korn> what package do you mean?
<paultag> lintian -IE --pedantic libevent*changes | wc -l
<paultag> 27
<paultag> c_korn: libevent
<c_korn> those are the libevent errors/information http://pastebin.com/niiCg1zN
<paultag> c_korn: http://pastebin.com/LKgnuv5v
<kklimonda> paultag: you are checking the older version :)
<paultag> kklimonda: ahhha. Thanks! :)
 * paultag finds some coffee :)
<c_korn> hm, my first FTBFS http://pastebin.com/Zfuq3CzK
<kklimonda> c_korn: you don't really have to rebuild the. I did that already. But the problem is the successful rebuild doesn't indicate a properly working package :)
<ari-tczew> c_korn: this FTBFS is related to linking no add needed
<c_korn> yes, I also test the executable
<kklimonda> c_korn: the ppa with all reverse dependencies is in https://launchpad.net/~kklimonda/+archive/libevent2 and I did mention it.
<kklimonda> c_korn: you cat get packages from there, I've fixed two or three that did fail
<wejaeger> Hey, anyone up for reviewing l2tp-ipsec-vpn? It's a little applet to configure and manage L2TP IPsec VPN connections. I've just uploaded a new candidate. http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
<kklimonda> c_korn: I did fix getstream for example already, so you can get a source packages from there :)
<ari-tczew> c_korn: if you want fix it, you have to add link -levent
<c_korn> ok, but I can't test it anyway. don't have a DVB-S transponder xD
<c_korn> enough testing work for today
<kklimonda> c_korn: thanks for that, I see you did test quite a lot of them already :)
<c_korn> np
<c2tarun> need help in creating the symbol file. I build the source package and binary package.
<c2tarun> persia: ping
<ari-tczew> siretart: around?
<siretart> ari-tczew: hi
<ari-tczew> siretart: did you see my mail?
<siretart> ari-tczew: I've uploaded your patch a few minutes ago :-)
<siretart> ari-tczew: http://packages.qa.debian.org/libv/libva/news/20110213T181722Z.html
<ari-tczew> siretart: very nice, I'll file a sync request and let you know about it, OK?
<siretart> sure!
<siretart> ari-tczew: please note that I didn't try to build it in natty yet
<ari-tczew> siretart: I did it.
<siretart> cool!
<ari-tczew> siretart: then I'll attach a buildlog to sync request.
<ari-tczew> siretart: what do you think about if I'll prepare a merge of ffmpeg and you will sponsor it?
<siretart> ari-tczew: don't you want to rather join pkg-multimedia and do the merge in that team? ;-)
<siretart> ari-tczew: I use git to maintain the ffmpeg package for ubuntu as well, and that merge is next on my list
<ari-tczew> siretart: but delta is only ubuntu-specific, how do you want get it into Debian?
<siretart> ari-tczew: http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=shortlog;h=refs/heads/ubuntu
<ari-tczew> siretart: not sure whether I have a time for new membership
<siretart> ari-tczew: uh my, it seems I there are a number of bits that should go into the debian pacakge :-/
<ari-tczew> siretart: do you mean ffmpeg?
<siretart> yeah
<ari-tczew> siretart: so do we should wait for next ffmpeg revision?
<siretart> ari-tczew: I'm already working on it
<ari-tczew> siretart: OK
<ari-tczew> siretart: do you know how to fix this FTBFS? http://paste.ubuntu.com/566726/
<geser> ari-tczew: I looked once at a similar FTBFS and it looks like linux-libc-dev doesn't ship that file anymore
<geser> only the V4L2 header file
<ari-tczew> geser: I tried to find videodev.h in another package but no results.
<geser> ari-tczew: linux-libc-dev in maverick has them, but not the natty one
<geser> I don't know if v4l is still supported in natty or only v4l2 (linux/videodev2.h)
<siretart> no, v4l is dead. port packages to v4l2
<siretart> or if v4l support is optional, disable it.
<ari-tczew> so next transition
<c2tarun> bug 718150 can anyone please explain me the last comment.
<ubottu> Launchpad bug 718150 in ucommon (Ubuntu) "Newer Version Available" [Undecided,Confirmed] https://launchpad.net/bugs/718150
<geser> c2tarun: there is no real connection between upstream version and API/ABI version of a library
<c2tarun> geser: not getting API/ABI version means?
<geser> that's the "version" number of the programming interface (API) or call interface (ABI) which other application use of a library
<geser> if upstream doesn't change any public functions (API) or size of data structures (ABI) in one release there is to reason to bump the library version
<c2tarun> geser: ok, but what do you mean by there is no connection b/w the version. Version in our archives is 3.2.0 and the one I downloaded by uscan is 4.1.1.
<c2tarun> geser: ^^
<geser> the library version you can "see" in the filename "libucommon.so.3". Because of the "3" the package is names libucommon*3*
<geser> many upstream try to keep the major upstream version match the library version but there is no requirement for it
<c2tarun> geser: I tried to pull the package of name libucommon3 but It directed me to ucommon package. and sorry but I failed to find libucommon.so.3
<geser> the binary package name is "libucommon3" and it's build by the source package "ucommon"
<geser> libucommon.so.3 is a filename from the libucommon3 package
<atagar> Hi, a package I maintain (tor-arm) just got accepted into debian unstable. What is the process for requesting a sync from ubuntu and does that make it available in all ubuntu distros?
<c2tarun> geser: is there any way of building binary package of different name than source package. still the file I uploaded is debian.tar.gz file. I dont think its the binary package.
<atagar> (for a bit more context: http://packages.debian.org/sid/tor-arm)
<geser> c2tarun: the contents of debian/control describe all packages build from that source package (there are also some other files in debian/ named after a package name to tell debhelper scripts which file belong to which package etc.)
<geser> atagar: see https://wiki.ubuntu.com/SyncRequestProcess for the sync and it will be only available for the next Ubuntu release (natty) but once it's in natty you can ask for a backport for older releases
<c2tarun> geser: ok, i just checked, I think there are four packages build from this ucommon source package. so what should I do :( I am understanding my mistake, but don't know how to solve it?
<atagar> geser: thanks!
<geser> I didn't look yet at the package but most likely replace any occurance of libucommon3 with libucommon4 (as the library version has changed according to comment #2) (debian/control, debian/libcommon3.install if it exists and similar files, check debian/rules if libucommon3 is used somewhere)
<geser> c2tarun: is this your first package? an upgrade of a library with a transition is not the best pick for someone unexpierenced as you need to learn pretty much in short time
<c2tarun> geser: well technically its not my first, but ya you can say so. I am not much experienced. And sorry but I was not aware that it was a library. How can I check that the package I want to upgrade is an library or an application?
<atagar> geser: If it won't be available until the next release anyway then is a sync request necessary? I thought most new debian packages were automatically available in the ubuntu repos of new releases.
<geser> c2tarun: by looking at which packages it builds: if they start with lib then it's a library
<c2tarun> geser: ok, so I should leave this bug and look for some simple packaging one?
<geser> atagar: only in the first stage of a development cycle new and updated packages get auto-imported into Ubuntu. After DebianImportFreeze (which was on 2010-12-31) only on request. New packages can only get synced till FeatureFreeze which is on Feb 24th.
<atagar> great, thx
<geser> c2tarun: up to you, but it seems you have done the most part already. what's missing is the renaming of the binary packages.
<c2tarun> geser: ok, so i should grep libucommon3 into all the files of debian and simply replace them by libucommon4? and some occurences like libucommon3-dbg to libucommon4-dbg?
<geser> c2tarun: I didn't want to discourage you, just inform you that what you picked isn't an "easy" task
<geser> c2tarun: yes
<c2tarun> geser: its ok :) I'll leave this bug and look for a new one. One more question, If I get stuck on some error that occurs while building the binary package like http://paste.ubuntu.com/566758/ then what should I do?
<geser> (of course don't replace it in old changelog entries as it's a documentation of the package history)
<c2tarun> geser: ya sure changelog and copyright entries should not be messed :) so do you think that I should finish this library bug ?
<geser> yes, it's a good expierence and you will learn much in short time
<geser> if you have any problems, asking here for help is the right place
<geser> and currently I don't have an idea of how to fix this FTBFS
<c2tarun> geser: ok no prob:), regarding that library bug In control file there is an entry of libucommon3 in Depends section of one of the libraries that are build from this source. should this be changed to libucommon4?
<geser> yes
<c2tarun> geser: ok,
<geser> it's for the -dev package right?
<c2tarun> geser: yup
<geser> that's right, if you build an other package with libucommon-dev, you need the matching library to link with which is in libucommon4
<c2tarun> geser: ok, these changes should be mentioned in changelog or not?
<geser> yes, but something like "Renaming libucommon3 to libucommon4" is enough here
<c2tarun> geser: ok
<c2tarun> geser: and there is file of name libucommon3.install should the name of file be changed to libucommon4.install?
<geser> yes, it describes which files end in the libucommon4 package
<c2tarun> geser: I think the debian folder is ready now. Is there any way I can show it to you?
<geser> I guess the easiest way would be a new attachment to the bug
<c2tarun> geser: ok , sure :) I'll do that. just wait a second please
<c2tarun> geser: its done can you please take a look. bug 718150
<ubottu> Launchpad bug 718150 in ucommon (Ubuntu) "Newer Version Available" [Undecided,Confirmed] https://launchpad.net/bugs/718150
<geser> c2tarun: will look at it later, I'm currently not using my Ubuntu so can't check things as easy as I'm used to
<c2tarun> geser: sure :) Thanks a lot.
<c2tarun> geser: If you can than can you please tell how do you guys check? I mean is there any tool for checking or just by looking at the debian.tar.gz file/
<geser> c2tarun: I usually look at the contents of the files
<c2tarun> geser: ok
<geser> there is a tool (lintian) to check for common errors but it doesn't catch everything
<c2tarun> geser: okay, so its all just by experience? thats cool :)
<c2tarun> geser: ok its 3 am I have to go :( I'll wait for your comment on that bug, and I'll try to fix any error possible. and Thanks a lot :)
<geser> sleep well
<grunthus> Hi, is there a good guide to using pbuilder with bzr branches?
<ari-tczew> grunthus: general guide about pbuilder: https://wiki.ubuntu.com/PbuilderHowto
<grunthus> Hi ari-tczew, thanks, I've been working through that guide, but it doesn't mention bazaar branches.
<ari-tczew> grunthus: bzr branch lp:~foo/bar && cd bar && rm -rf .bzr && debuild -S -sa && pbuilder-dist natty ../file.dsc
<grunthus> Seems pbuilder build is looking for a dsc file
<grunthus> ^thanks
<maco> why rm th e.bzr/
<maco> *?
<ari-tczew> maco: problematic for building source
<maco> O_o
<maco> bzr-builddeb -S
<maco> then it won't complain
<maco> and you don't have to lose bzr history and be unable to commit and push up a merge request
<grunthus> I'd want to be able to have merge request
<tumbleweed> bzr bd --builder=pdebuild ?
<grunthus> Hmm. Hit a problem with debhelper.mk: No such file, however debhelper package is installed.
<maco> cdbs
<ari-tczew> grunthus: install cdbs package in your system
<grunthus> cheers maco, ari-tczew, just did that , plus another (python-distutils-extra).
<grunthus> I'm attempting to build ubuntuone-control-panel with pbuilder. Now complaining "cant build with soure format 3.0 quilt: no orig.tar.gz...
<grunthus> Perhaps this would be easier if I started with apt-get source instead of bzr branch?
<maco> bzr bd shouldnt need a .orig.tar.gz
<ari-tczew> maco: pbuilder...
<grunthus> so pbuilder wrong way to try to build from bzr branch?
<micahg> grunthus: no, it should work fine
<micahg> grunthus: you can't delete .bzr if you're using bzr-builddeb
<grunthus> ah. TOo late then. I'll need to clean up and bzr branch again?
<micahg> grunthus: yes
<grunthus> OK, np.
<grunthus> Right, started again. bzr-builddeb -S
<grunthus> Much better, 'fraid to say, debuild failed to sign  changes and dsc files, secret key not available.
<grunthus> googling
<micahg> grunthus: that's ok for pbuilder, but if you need to upload, you can use debsign on the source.changes file
<maco> grunthus: can add "-- -uc -us" to make it shut up about that too
<grunthus> Thanks, that's better.
<grunthus> I can sign the changes file when I'm finished with a fix for this bug (I hope!)
<micahg> grunthus: you won't need to, you can just push your branch up to launchpad, lp:~you/ubuntu/package/branchname or lp:~you/project/branchname
<grunthus> OK.
<micahg> grunthus: and then propose a merge
<maco> put the release as UNRELEASED if you do that
<maco> the person who sponsors the upload will change it from UNRELEASED to natty (or whatever)
<grunthus> successfull build, thanks for the help.
#ubuntu-motu 2012-02-06
<micahg> transitioning some ada stuff to gnat4.6 and asis2010, so there might be some extra transient build failures/depwait
<epikvision> hi
<dholbach> good morning
<chilicuil> good morning, I've wrote a bash autocompletion script for recordmydesktop, I'd like to share it with other Ubuntu users, should I attached to a bug against https://bugs.launchpad.net/ubuntu/+source/recordmydesktop or against https://bugs.launchpad.net/ubuntu/+source/bash-completion ?
<geser> a bug against recordmydesktop (it makes no sense to ship your script if recordmydesktop isn't installed)
<chilicuil> geser: that's what I think, however I've seen that the package bash-completion has autocomplete scripts for rdesktop for example...
<geser> hmm
<eQuiNoX__> hello everyone
<jtaylor> micahg: I'll sync python-kinterbasdb if you have no objections, the changes where applied in debian
<micahg> jtaylor: it it builds, sure, thanks
#ubuntu-motu 2012-02-07
<kamal> micahg: thanks for all the syncs :-)    ... did this one get missed though?  bug 926753
<ubottu> Launchpad bug 926753 in Ubuntu "Sync twpsk 4.0-1 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/926753
<micahg> I didn't see it in the queue
<micahg> kamal: ah, porthose is still doing things the old way, I can sync that now
<kamal> micahg: porthose did something ...
<kamal> yeah
<kamal> micahg: thanks again!  :-)
<micahg> kamal: thank you for keeping Ubuntu up to date, and if you're interested in a ham radio packageset, we could probably do that as I know we have  a few Ubuntu people interested in that stuff
<kamal> micahg: I don't know what a "packageset" would mean/entail/do ... googling
<micahg> kamal: https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Developers_.28from_delegated_teams.29
<kamal> micahg: ok, with upload rights for that set of packages then?   hmmm.   scary.   ;-)
<micahg> kamal: if this works for you, no problem
<micahg> just offering if you want it one day
<kamal> micahg: honestly, I like the added buffer/sanity-check that sponsored uploads provides, but maybe I'm just being wimpy.  I will discuss it with a couple of the other ubuntu-hams principals and get back to you.  thanks!
<epikvision> hello
<epikvision> can anyone help me get started
<epikvision> I'm new and want to contribute as developer
<MaximLevitsky> I don't know if this is the right place to ask, but I have a problem with multiarch support in 12.04.
<MaximLevitsky> I have bunch of -dev packages that I need both x64 and i386 versions, but they conflict because both contain same headers
<MaximLevitsky> Is this issue known?
<tumbleweed> MaximLevitsky: either the headers need to be identical, or they must be moved to a multi-arch path so they don't clash
<MaximLevitsky> I am pretty sure that headers are identical, but dpkg still refuses to install them
<MaximLevitsky> You mean that dpkg actually compares the headers or package is marked as having same headers?
<MaximLevitsky> I have problem with bunch of X11 libraries
<tumbleweed> yes
<tumbleweed> I assume you have read http://wiki.debian.org/Multiarch/Implementation ?
<MaximLevitsky> I didn't. Anyway all I needed to know if this is a generic package system wide issue or just specific package bug. Since its the second, I guess its mostly offtopic here
<wzssyqa> https://bugs.launchpad.net/ubuntu/+source/ns2/+bug/928193
<ubottu> Ubuntu bug 928193 in nam (Ubuntu) "ns2/nam error with tcl8.4, doesn't recognise" [Undecided,New]
<wzssyqa> somebody help to SRU?
<tumbleweed> what needs to be rebuilt, ns2 or nam?
<wzssyqa> tumbleweed: nam
 * tumbleweed deletes the ns2 task
<tumbleweed> wzssyqa: can you provide a test case in the bug?
<wzssyqa> tumbleweed: test case?
<tumbleweed> wzssyqa: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<geser> short step-by-step tutorial how to reproduce it and to check that it works (with the patched package)
<wzssyqa> tumbleweed: I mark it invalid for ns2
<wzssyqa> tumbleweed: test case is posted
<tumbleweed> wzssyqa: thanks
<tumbleweed> wzssyqa: to avoid that in the future, will you add a Breaks on newer tcl?
<wzssyqa> tumbleweed: y, I have do it.
<tumbleweed> wzssyqa: uploaded
<wzssyqa> tumbleweed: many thx
 * achiang uses requestsync, and it talks about a "new keyring". what is it talking about?
<achiang> perhaps it is related to launchpadlib? i see a new ~/crypted_pass.cfg appeared
<tumbleweed> achiang: yes. headless?
<achiang> tumbleweed: yeah, headless
<achiang> (although i must give kudos to w3m for just working)
<tumbleweed> heh, I normally copy and paste the URL to my local browser
<tumbleweed> in a desktop environment that'd be in the gnome/kde keyring. (and you don't need to do it on a remote box just because of e-mail/gpg, the API is default these days)
<jtaylor> why wasn't bug 889241 fixed by the lastest nunit upload? it had LP:#xx in the changelog
<ubottu> Launchpad bug 889241 in monodevelop (Ubuntu) "Can't run NUnit test from inside MonoDevelop" [Undecided,Confirmed] https://launchpad.net/bugs/889241
<Ampelbein> jtaylor: launchpad also matches the sourcepackagename
<Ampelbein> (a upload of $PACKAGE_A can't close bugs in $PACKAGE_B)
<directhex> yikes. jtaylor, can you sync cli-common into precise? 0.8~xamarin1 is bug city
<jtaylor> directhex: its main, I have no rights there :(
<jtaylor> file a request with requestsync
<directhex> argle
<Laney> just do syncpackage
<Laney> surely we can upload it
<micahg> yes, you ca
<micahg> *can
<directhex> syncpackage: Error: Source package cli-common is blacklisted.
<jtaylor> if I do syncpackage I get no rights to upload
<directhex> so why's it moaning?
<jtaylor> I tried that with nunit
<jtaylor> which is also main
<Laney> you aren't in cli-mono-dev
<Laney> but we are
<directhex> why isn't jtaylor in cli-mono-dev?
<Laney> he hasn't applied
<Laney> dear edit_acl. please work, thanks.
<jtaylor> I didn't even know it exists :)
 * micahg doesn't see cli-common on the sync blacklist
<Laney> probably current
<Laney> --force it
<directhex> jtaylor, mono is a packageset, so in theory group members can poke the named packages without main upload rights
<directhex> syncpackage: Request succeeded; you should get an e-mail once it is processed.
<jtaylor> that would be nice, then I don't need a sponsor for the nunit fix :)
<jtaylor> I'll apply in a moment
 * micahg hopes a test build was done first :)
<directhex> micahg, it's perl. not much building involved
<micahg> directhex: I can show you lots of perl build failures :)
<directhex> sounds like evil perl
<directhex> dpkg-deb: building package `ikvm' in `../ikvm_7.0.4335.0+ds-5ubuntu1_all.deb'.
<directhex> ;D
<directhex> relatedly, this package needs cli-common-dev >=0.8~xamarin2 to build, which isn't in precise
<directhex> yet
<directhex> hence noticing & the sync talk
 * ajmitch hates coming across packages that pkg-cli-apps look after that seem to be dead upstream - like tasque
<directhex> ajmitch, a bit sad
<directhex> ajmitch, but users, so...
<micahg> directhex: that's why test builds are important :)
<blackz> hi
<ajmitch> directhex: yeah, I saw some people complaining on a bug about unity indicator support, patch has been in upstream bugzilla for 7 months with no comment
<micahg> hi blackz
<blackz> hey micahg
<blackz> late congrats for you core-dev membership :)
<micahg> blackz: thanks, are you back, or just visiting?
<Laney> yeah, it is actually only the finest quality perl
<Laney> from waitrose and m&s
<blackz> micahg: heh I'd say I'm back now ;)
<micahg> blackz: awesome :), there's plenty to do, and we still need lots of help, welcome back
<blackz> micahg: yeah I seen
<blackz> micahg: thanks :)
<jtaylor> Laney, directhex: https://code.launchpad.net/~jtaylor/ubuntu/oneiric/nunit/fix-889241/+merge/91895
<Laney> why is it forwarded: no?
<directhex> Laney, because it's cherry picked from upstream i guess?
<directhex> jtaylor, seems you've got .pc cruft in your diff
<Laney> should be not-needed then
<jtaylor> thats how bzr works ._.
<jtaylor> I haven'T forwarded it yet, but probably should be
<jtaylor> so no
<jtaylor> though I can probably do it
<jtaylor> the issue is I don't really know if its a bug or monodevelop using it wrong
<Laney> well speaking to upstream helps to clarify that
<jtaylor> yes that is on my todo list
<Laney> I saw another patch of yours that wasn't forwarded too but I forgot where it is now
<jtaylor> in a mono package?
<Laney> yeah
<Laney> well it was Forwarded: no
<jtaylor> I haven'T got a checkout to grep :/
<jtaylor> forwarded it and added tags
<Laney> the fix needs to be in the dev release first too
<Laney> is it worth waiting for an upstream response?
<jtaylor> it is
<Laney> ?
<Laney> then what did you forward?
<jtaylor> the patch
<jtaylor> its already applied in debian and precise
<Laney> maybe it was that that i saw then
 * Laney . o O ( who-uploads nunit )
<jtaylor> its be better to wait for upstream response for the SRU
<Laney> yes
<jtaylor> I set the merge to wip
<jtaylor> tumbleweed, barry: whats your take on getting numpy 1.6 into precise?
<barry> jtaylor: i don't have any particularly strong opinions about it, but i see that 1:1.6.1-3 has hit experimental.  maybe you could take a look at the rdepends and see if they are compatible with 1.6?
<barry> jtaylor: it would have to happen before feature freeze
<jtaylor> debian is transitioning right after hdf5 is done
<jtaylor> 1.6 is compatible
<jtaylor> only ~15 rdepends to rebuild
<barry> what's up with hdf5?
<jtaylor> I didn't rebuild them in ubuntu yet, but morph did in debian and said no failures
<jtaylor> there where a bunch of issues with it on other arches, I think they are rresolved but its still moving slowly
<jtaylor> all those science packages aren'T easy to deal with
<barry> yeah
<jtaylor> @hdf5
<barry> which arches are broken?
<jtaylor> I think mips was one problem, I'm not to familiar with the progress
<jtaylor> its not feasable to do that transition in ubuntu before the feature freeze
<barry> jtaylor: in that case, i think it's best to wait for q-series.  we need stability in the lts and i'm worried about such a big change after ff
<jtaylor> numpy you mean?
<barry> that's what you were referring as being "not feasible", right?
<jtaylor> no hdf5
<barry> ah
<jtaylor> numpy packages needing rebuild: http://people.canonical.com/~ubuntu-archive/transitions/numpy.html
<barry> it's a trade-off (and tough call) i guess.  erring on the side of stability vs. having an old version in an lts.  if we have high confidence that hdf5 will be fixed before beta 1, then maybe it would be okay
<jtaylor> we don't need hdf5 for numpy
<jtaylor> at least thats my understanding
<barry> right, but we don't want a broken hdf5 in an lts
<jtaylor> its just ongoing and conflicts with numpy
<jtaylor> is it broken?
<barry> sorry, am i misunderstanding?  i thought you said it was incompatible w/ numpy 1.6
<jtaylor> no I only said debian will transition numy when they are done with hdf5
<barry> oh, gotcha
<jtaylor> sorry for being confusing :)
<barry> no, it's probably me :0
<barry> er, :)
<barry> i'd say double check w/doko, but if he has no objections, it's fine with me
<tumbleweed> jtaylor: the entire transitions don't have to happen before FF, but should be started before FF
<jtaylor> thats good news
<tumbleweed> barry: the pypy currently in NEW (it was deleted by accident) should work with normal virtualenv
<barry> tumbleweed: nice!
<jtaylor> I'd also still like to have the new sphinx in precise, the last blocker seems to be fixed soon
 * tumbleweed hopes to have pypy 1.8 soon
<jtaylor> would probably make sense to do that before numpy to get the docs of the rebuilds built with the new sphinx
<tumbleweed> which means I need to start putting effort into modules...
<barry> jtaylor: +1 for sphinx.  are you going to work on that?
<tumbleweed> jtaylor: yeah, that would be nice too
<jtaylor> barry: jwilk did all the work in debian, it probably only needs syncing
<barry> jtaylor: let me take a look
<jtaylor> there are a few packages broken still that need syncing too
<jtaylor> there is a open request with all info
<barry> jtaylor: bug #?
<jtaylor> would have to look it up (if lp lets me :/)
<jtaylor> bug 911124
<ubottu> Launchpad bug 911124 in sphinx (Ubuntu) "Please sync python-sphinx 1.1.2 from Debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/911124
<barry> jtaylor: cool, i'll work on that when i'm done with my current packaging
<jtaylor> no rebuild was done in ubuntu, but I guess any issue that still might come up can be fixed in time
<pabelanger> howdy
<pabelanger> I have a debdiff for bug 928499 to fix a comping issue with DKMS and DAHDI
<ubottu> Launchpad bug 928499 in dahdi-linux (Ubuntu) "dahdi-linux fails to build under 3.2 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/928499
<Corey> I have a links file that contains the line usr/lib/python2*/dist-packages/salt/salt-minion /usr/bin/salt-minion; how do I get it to *properly* expand the 2* to either 2.6 or 2.7 (depending upon which version is on the system in question)?
<jtaylor> why is the executable in lib/python2 in the first place?
<Corey> jtaylor: Where should it live instead?
<Corey> /usr/share/salt/ ?
<jtaylor>  /usr/bin
<Corey> jtaylor: That's not how similar packages do that, /usr/bin/ contains a fair number of symlinks to other places.
<jtaylor> not many
<jtaylor> in most cases it are links to alternatives
<Corey> jtaylor: Better to just drop the binary into place then?
<jtaylor> but shellscripts calling stuff in lib is common yes, but not for python
<jtaylor> in this way
<jtaylor> that probably makes most sense
<jtaylor> what is that file? a modules + main section or only the main
<Corey> jtaylor: Script that invokes a bunch of stuff in the usr/lib/python2*/dist-packages/salt/ directory.
<jtaylor> thats fine
<jtaylor> it would be a bit strange if it also was intended an importable modules too
<Corey> jtaylor: Yeah, it provides an entire API for python programs.
<Corey> It's concieved as an extensible configuration mangement tool.
<jtaylor> this one script?
<jtaylor> is it a large file?
<Corey> jtaylor: No, just does an import salt and defines the main function.
<jtaylor> then don't install it in lib, but in bin instead
<quadrispro> jtaylor, thanks for that mail about the FTBFS ;)
<quadrispro> I'm very busy these days, I've miss'd 'em
<jtaylor> quadrispro: which one?
<quadrispro> jtaylor, the only one mail :) stk and lv2proc
<quadrispro> jtaylor, you gave me the opportunity to find a most important in rtmidi
<quadrispro> important bug, I meant
<jtaylor> quadrispro: how did my mail help find a bug o_O
<quadrispro> jtaylor, stk's ftbfs was due to a uncorrect linking against rtmidi
<quadrispro> so your help has been much appreciated :)
<quadrispro> keep up the great work
<micahg> quadrispro: I still have gmusicbrowser on my list, I just have to get a key on alioth so I can push to git
<jtaylor> np, thanks for fixing the ftbs
<quadrispro> bdrung, eh-ehy! already commit'd, now I'm going to add a point to the next changelog entry
<quadrispro> hi micahg ! did upstream release a new version?
<micahg> yeah, 1.1.9
<quadrispro> well, yes
<quadrispro> git-import'ing right now
<quadrispro> micahg, have you already had a look at the code?
<micahg> no, not yet, got as far as the checkout failing due to not being able to do it without an SSH key
<micahg> well, actually I got the checkout, not the upstream branch I needed to do the import
<micahg> I can fix it, but moved on to other things
<quadrispro> wow, gmusicbrowser is getting very cool
<micahg> quadrispro: one of these days I'll get the hang of git
<quadrispro> micahg, mostly bugfixes plus various small improvements
<micahg> yep, xubuntu wants it for precise
<micahg> and astraljava wants a backport for oneiric
<quadrispro> micahg, lol, are you still in trouble? have you uploaded your key to alioth?
<micahg> no, I got distracted by other things, I'll look into it later
<quadrispro> you should wait for some hours after uploading the key I suppose
<quadrispro> ah ok ok
<quadrispro> no worries, here is Alessio who's happy to share some of his spare time tonite
<jtaylor> @numpy, I rebuilt the 16 of the 18 packages in precise and they build fine
<jtaylor> I skipped shogun as it takes ages to build and one needs a manual dependency resolving for which I'm to tired to do now ._.
<jtaylor> (pandas, needs scipy and pytables rebuilt)
<tumbleweed> quadrispro: think that was the same bug as bug 423609? (it looks like it)
<ubottu> Launchpad bug 423609 in ubuntu-dev-tools (Ubuntu) "[cowbuilder-dist] login doesn't show shell prompt" [Low,Triaged] https://launchpad.net/bugs/423609
<psusi> whois smoser smoser
<quadrispro> hi tumbleweed! you mean LP: #423609?
<Corey> Assuming that debian/rules doesn't make reference to it, how does a package install know what services to start / how does it invoke them?  The install throws a race-condition type error, like it's trying to start before fully installed, but once it's installed it works properly.
<tumbleweed> quadrispro: yup
<quadrispro> yes, you meant so :) and yes, it looks the same
<tumbleweed> great, I thought I'd remembered seeing someone complaing about us not setting DISTRIBUTION before
<tumbleweed> I thought they were crazy, but it appears that cowubilder needs it :P
<quadrispro> tumbleweed, and I think DIST and ARCH are mere alias recommended by PbuilderTricks page on the Debian's wiki
<tumbleweed> yes
<quadrispro> skipped by pbuilder though
<tumbleweed> the only reason we set them was for people who had interesting pbuilderrcs
<tumbleweed> it also passes --distribution
<quadrispro> yes, I see
<tumbleweed> (oh, and you forgot to close the bug in the changelog :) )
<quadrispro> tumbleweed, I haven't yet added any entry
<quadrispro> tumbleweed, I need some minutes to fix a big issue on zita-resampler
<tumbleweed> quadrispro: I finished itp
<tumbleweed> it up
<quadrispro> tumbleweed, thank you!
<tumbleweed> np, thanks
#ubuntu-motu 2012-02-08
<micahg> can a DD please help this person (bug 928556)
<ubottu> Launchpad bug 928556 in mosquitto (Ubuntu) "Package out of date - 0.15 available" [Undecided,New] https://launchpad.net/bugs/928556
 * tumbleweed has a quick look
<tumbleweed> not the most useful VCS branch
<micahg> tumbleweed: was pointing to a DD as supposedly there's something to be sponsored to Debian (which would be preferred to reviewing/uploading to Ubuntu)
<Laney> mentors has it
<Laney> 3 sponsors in 4 revisions isn't the most helpful situation though
<tumbleweed> well, some sponsors don't seem to encourage their sponsorees to come back
<directhex> it's not a good situation to be a sponsor of something you don't care about
<directhex> for one thing it's hard to adequately apply any packaging review
<Laney> and it means the finding a sponsor cycle has to be repeated again (and again)
<tumbleweed> yeah, first few reviews someone is *slow*
<Laney> perhaps he did contact them
<tumbleweed> reviews for someone
<tumbleweed> (and yo have to get your head around the packaging)
<tumbleweed> one of the reasons worknig in ubuntu is nice. It's all the quick and easy stuff :P
<Laney> oojah: (since you're here :P) did you contact mt and kilian to sponsor the new mosquitto?
<tumbleweed> micahg: did you look at the package's vcs branch?
<micahg> no
<tumbleweed> its cross-distro
 * tumbleweed -> bed
<Corey> I'm trying to use dh --with python2, but whenever I apply that, packages need a newer version of Python than is in Lucid and the package fails (2.6.6 vs the 2.6.5 that Lucid has)
<micahg> right, you can't use that in lucid
<micahg> take a look at I think pastebinit to see a trick
<barry> Corey: dh_python2 is still awaiting backport to lucid: bug 788524
<ubottu> Launchpad bug 788524 in python-defaults (Ubuntu) "backport dh_python2 to lucid (and maverick if appropriate)" [High,In progress] https://launchpad.net/bugs/788524
<Corey> barry: Hmm. How do I sanely get my sid pbuilder chroot to build a package that properly stuffs the python stuff into /usr/lib/python2.6/dist-packages/ instead of pyshared and/or pymodules?
<barry> Corey: i'm actually at eod.  if no one else can help you here, can you ping me tomorrow, sometime after 1400utc?
<Corey> barry: Will do if nobody gets to me, thanks.
<Corey> The stuff in pyshared and pymodules *works*, it's just inelegant and not how we like to do things.
<epikvision> how long do openpgp keys take to be validated
<epikvision> ?
<blair> i just noticed that 12.04 packages for python modules now only provide python 2.7 modules, not both 2.6 and 2.7, who can i talk to to reverse this decision for 12.04?
<ScottK> blair: It's not going to happen.
<blair> ScottK, not even if i provide a good reason why ????
<ScottK> If you've got a problem with something working with python2.7, the solution is to make it work with 2.7.
<blair> ScottK, no, that's not the issue
<ScottK> What's the issue/
<ScottK> ?
<blair> I work for Sony Imageworks and we have ~500 artists using Autodesk Maya 2013 for special effects (movies like Green Lantern) and Maya only supports Python 2.6 and won't go to 2.7 for another year
<micahg> python2.6 is planned to be dropped from precise as soon as the final reverse dependencies are resolved
<blair> i'm pushing to go from fedora 13 to 12.04 and one of the benefits is that ubuntu would provide 2.7 for people working outside of maya and 2.6 for people working in Maya
<blair> it's a huge pain on our *ss to compile all python modules for an older Python release, so i was really excited to see this in ubuntu
<blair> i think ubuntu should look at supporting an older python for commercial products like Autodesk Maya
<blair> is it a goal of an LTS release to be an official distro for more commericial linux software packages?
<blair> right now the whole visual effects industry is on rhel/fedora distros, so anything to help with ubuntu getting in would be helpful
<blair> is there a mailing list i can shoot an email off to?
<micahg> blair: AIUI, the 2.6 branch upstream is almost dead and would be very difficult to support for 5 years
<blair> micahg, that makes sense
<blair> if i wanted a ppa and recompile sources, what would i need to change to have the build process also make 2.6 modules?
<micahg> blair: if you only need 1 year of support, lucid is supported until Apr 2013
<blair> we're in the boat now on an unsupported OS (fedora 13) which is over a year old
<blair> it takes 6-9 months to move 500 desktops to a new OS
<micahg> blair: you'd need python-minimal I believe, but ScottK would know better
<blair> argg, i was so excited when i saw multiple python support in oneiric and just assumed it would carry forward to precise
<micahg> or rather the python-defaults package set up for it
<blair> it would save to much work on our sysadmin team
<blair> s/to much/so much/
<micahg> blair: if it's just one piece of software that you need to support though, a PPA doesn't seem like such a bad solution
<achiang> +1 to PPA. i think that's a pretty good solution to your specific problem
<achiang> i bet you might even find some other crazy volunteers to help
<micahg> especially if you know they're migrating to 2.7, you can have a solid OS for about 4 years
<blair> micahg, yes, maya will be on 2.7 in a year
<ScottK> There will be a python2.6 PPA for precise.
<ScottK> blair: ^^^
<ScottK> Oh, no.
<ScottK> Sorry.  Backwards.
<ScottK> Launchpad needs a python2.7 PPA on lucid, not 2.6 on precise.
<ScottK> In any case, you need to change python-defaults, python-central, python-support, and distribute and then build a python2.6 package and rebuild any modules/extensions you need.
<ScottK> It's not a huge test to make such a PPA for someone familiar with the Debian/Ubuntu Python stack.
<ScottK> In addition to this issue of python2.6 not being supported upstream, building python extensions for multiple versions adds to their size since they need double the .so files.
<ScottK> For the extensions on the Ubuntu CD, a second python version adds about 8MB to the CD and space is constrained enough that 8 MB is a big deal.
<blair> ScottK, thanks for the info, appreciate it.  excuse me getting worked up there, i was very much looking forward to this in precise, since I assumed it would be the same way as in oneiric
<ScottK> No problem.
<blair> is there a naming standard for a ppa like this?  precise-python2.6?
<ScottK> All of the multiple support infrastructure is still there, so it's not that hard to do.
<ScottK> PPAs aren't part of Ubuntu (they are built on Ubuntu) so there's no common standard.
<ScottK> The only real standards for PPAs are version numbers to avoid conflict and confusion with packages from the official archive.
<ScottK> Those standards are defacto, but some of us yell at people that don't follow them.
<blair> i guess there's two ways to go, 1) tweak the builds to generate the packages with the exact same names and then have the PPA packages be picked up instead of Ubuntu's 2) have a system where a "2.6" is automatically put on the package name and they can coexist with Ubuntu's
<ScottK> You generally use the same package name, just a different version to disambiguate them.
<blair> so for "python-xattr" at 0.6.2-1ubuntu1, I would renumber it to something like 0.6.2-1ubuntu1-py26.1
<blair> when ubuntu releases 0.6.2-1ubuntu2, then it would upgrade my package and remove the 2.6 pieces, which wouldn't be good
<ScottK> Right, but post-release that's unlikely to be a problem.
<ScottK> If it is, it's probably a big enough issue you want to rebuild your package.
<ScottK> You can also use pinning to avoid the upgrade.
<blair> this is good stuff, assuming we get buyin to move to 12.04, then i'll be doing this work
<oojah> Laney: I contacted mt directly but haven't tried killian.
<oojah> I'll try kilian.
<Alison_Chaiken> Greetings MOTU.    I am packaging a set of programs that constitute a framework plus its plugins.
<Alison_Chaiken> I've been pondering over how many packages to put them in.
<Alison_Chaiken> The plugins support hardware accessories, and many users won't have many of them due to the expense.
<Alison_Chaiken> So maybe each bit of HW should have a plugin which has its own package?
<Alison_Chaiken> At least the base install should include all the components of the simulator environment for folks who have no HW at all, I figure.
<Alison_Chaiken> I've pretty much got my brain around the mechanics of packaging, but now am thinking about these meta-issues.
<Alison_Chaiken> Any thoughts about best practices are appreciated!
<micahg> depending on size, you can split them, this is assuming they're all from the same source
<Alison_Chaiken> So far, micahg, they're from the same source, but of course the hope is that accessory vendors will create their own plugins.
<Alison_Chaiken> The point of making packages available in part is to make that process easier and more understandable for outside parties.
<micahg> I meant split them in separate binaries, you can either do that for size or content or both, maintainer's choice
<micahg> or neither
<Alison_Chaiken> I have two ideas: one to package each plugin separately, and one to have a plugins-basic and plugins-extra.
<Alison_Chaiken> Yeah, the binaries are already separate shared-object libraries, as plugins tend to be.
<micahg> I meant binary packages as opposed to source
<Alison_Chaiken> So the source all goes in one package logically unless it gets really big?
<Alison_Chaiken> But the binaries get packaged separately?
<micahg> umm, well, the source package produce one of more binary packages which can contain one or more (possibly binary) files
<micahg> s/of more/or more/
<geser> Alison_Chaiken: look how libraries (usually) are packaged: the source (as it comes from upstream) is one tarball (= one source package) but it build several binary packages (deb files): one for the library itself, an other one for the headers (perhaps a third one with the documentaion)
<Rhonda> I wonder:  Is it the better approach to backport fonts-droid to older releases, or to adjust wesnoth-1.10 to work with ttf-droid instead?
<Laney> happy birthday to highvoltage!
<tumbleweed> he's naughty. had dinner with him last night, and he didn't warn us, only mentioned it at midnight on IRC
<mitya57> Are here fans of unity-mail (or personally me) here? :) I need somebody to sponsor it for precise, see bug 927602.
<ubottu> Launchpad bug 927602 in Ubuntu "[needs-packaging] unity-mail" [Wishlist,Triaged] https://launchpad.net/bugs/927602
<highvoltage> thanks Laney :)
<highvoltage> tumbleweed: yeah because my birthday only started at midnight!
<Laney> could have procured some drinks :P
<tumbleweed> and we *would* have kept you out :)
<mitya57> BTW, Launchpad does no more allow to open new bugs via web ui, so it's impossible to easily open a needs-packaging bug - can it be fixed?
<mitya57> P.S. Happy birthday!
<Laney> mitya57: append ?no-redirect
<Laney> +filebug?no-redirect or something ..
<mitya57> Oh thanks, will use that next time
<tumbleweed> it should explain that on the wiki page that it directs you to
<Laney> yeah buried somewhere deep down
<Laney> I think the process page for needs-packaging bugs contains a correct direct link
<Laney> Rhonda: either works; doing the source change might be less of a pain depending on the extent of the changes required
<highvoltage> Laney: I specifically wanted to avoid drinks, I was driving a loan car :)
<Rhonda> Laney: Alright, and as I am keeping it in git I won't have any issues on upgrades anyway.
<mitya57> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Requesting_a_new_package_for_Ubuntu contains a non-working link
<Laney> fix it please :-)
<tumbleweed> that has ?no-redirect
<Laney> one of them does not
<mitya57> sorry, I looked at wrong one
<Laney> they should both work, please fix the other one
<mitya57> Laney, done
<Laney> nice
<Corey> Good morning, barry.
<barry> hi Corey
<Corey> barry: Yeah, apparently replacing python-support with python2 dh in Lucid isn't working yet.
<Corey> There's a backport bug open for it, but it's been a year or better without progress.
<barry> Corey: yeah.  you should ping doko on that :)
<tumbleweed> I think it's fairly safe to assume at this point that it'll never happen
<barry> yeah, probably so
<tumbleweed> it's not always possible to make a package that'll build on all supported releases
<tumbleweed> esp if you want new features
<barry> tumbleweed: the problem is that it's not an insignificant amount of work.  i did look at it at one point, but got bogged down in details and bugs, so i'm not personally eager to try again.  however, if it were a significant problem for our users, then that's not good either
<tumbleweed> OTOH, if we've survived this long...
<barry> true, though not without grumbling ;)
<tumbleweed> sure :)
<barry> hey in 2 months we'll all forget what lucid was right? <wink>
<tumbleweed> oh, did you see the dh_python2 bugfix I have in the sponsor queue for natty? I tried to get doko's attention on IRC, but iit looks like he misunderstood the bug
<barry> tumbleweed: didn't see it
<tumbleweed> bug 915167
<ubottu> Launchpad bug 915167 in python-defaults (Ubuntu Natty) "pycompile will use /usr/local/bin/python2.X if available and python2.X is installed." [Medium,New] https://launchpad.net/bugs/915167
<barry> yuck
<tumbleweed> yeah, it's suprising we didn't notice until now :)
<tumbleweed> it was fixed almost immediately in debian
<barry> indeed.  i almost always have some pythons in /usr/local/bin, but it's been a while since i ran natty
<zooko> Folks: does anyone want to walk me through setting up autobuild recipe on launchpad?
<zooko> There is presumably already a build config file/build script in existence, since the package gets built and included in Ubuntu releases.
<zooko> And I just hooked up the "pull from github/git into launchpad/bzr" function.
<zooko> So, what's left to do?
<zooko> https://code.launchpad.net/~tahoe-lafs/tahoe-lafs/master/+new-recipe
<jtaylor> zooko: if the debian package branch is ok, nest-part packaging lp:debian/tahoe-lafs debian should work
<tumbleweed> zooko: prepare packaging that'll build on all the releases you want to daily build for, and write the recipe
<zooko> jtaylor: this sounds like the right track, but I don't know how to check if the debian package branch is ok, and I don't know what "nest-part packaging" is. :-)
<zooko> tumbleweed: that's the part I was asking for help with.
<zooko> Oh shoot I have to go. I'll be back in about 3 hours
<jtaylor> bzr dailydeb recipe to test it
<zooko> .
<tumbleweed> zooko: the recipe is trivial (look at the other recipes on lp, and you'll see how simple they are)
<jtaylor> nest-part is merges the debian branch of the branch into the main one
<jtaylor> *debian folder
<jtaylor> https://help.launchpad.net/Packaging/SourceBuilds/Recipes
<jtaylor> though its more likely you will have to change the packaging, so you either branch the debian package or make a new branch
<jtaylor> if you make a new branch only palce debian in it, then you can use a normal merge
<zooko> jtaylor: I will try this later. Thanks! :-)
<cancer> hey .. I wanna contribute to Ubuntu
<cancer> where should I start from ?
<Corey> I'm attempting to upload a package to launchpad via dput, but it keeps kicking back an email: salt_0.9.6-2ubuntu1.dsc: Version older than that in the archive. 0.9.6-2ubuntu1 <= 0.9.6-lucid1
<Corey> I've played with the version string, but can't get it to behave.
<micahg> -lucid1 > -2ubuntu1
<Corey> micahg: Ah.  So change it to lucid2?
<micahg> see dpkg --compare-versions
<micahg> Corey: what is the goal?
<Corey> micahg: To update a package with a pile of changes to the packaging status, but is still 0.9.6 of upstream.
<micahg> which release?
<Corey> micahg: For Lucid, but also be portable to newer releases.
<micahg> yeah, just bump it to lucid2 for a PPA
<Corey> micahg: Okay.  Thank you. :p)
<micahg> Corey: if you're interested in how the versioning works: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<goddard> why doesn't bzr dh-make work?
<goddard> it says unknown command?
<Corey> micahg: I am-- thank you.
<micahg> goddard: do you have bzr-builddeb installed?
<goddard> not sure letme check
<goddard> looks like no thanks
<Corey> goddard: Yeah, I'm a fan of apt-file search for that.  (gotta apt-file update first, though)
<goddard> Corey: i see
<goddard> cool didnt know bout that
<Corey> micahg: *siiiigh*  There are a few upstream changes to the orig.tar.gz in this version, but hte upstream version number didn't get bumped, so now I get File salt_0.9.6.orig.tar.gz already exists in Salt, but uploaded version has different contents.
<tumbleweed> Corey: then you need to turn those upstream changes into a quilt patch
<micahg> Corey: right, so you either need to make the upstream changes patches against the original or change the upstream version ala 0.9.6+foo-0saltX
<micahg> err...
<micahg> upstream version = 0.9.6+foo
<tumbleweed> or, you should include the upstream revision in the upstream version number, as micahg suggested
<Corey> Thanks.
<tumbleweed> (or you use native source format instead of quilt)
<Corey> So the +foo gets applied to the orig tarball, and the version string in the changelog-- anywhere else?
<micahg> well, source format 3.0 should make a patch for you depending on how it's configured
<tumbleweed> fortunately, that's not a default any more
<tumbleweed> Corey: no
<Corey> Yeah, I'm not really interested in going the quilt route.
 * micahg loved the "feature"
<tumbleweed> the quilt route would make lots of sense if it was a package in the archive, and the tarball wasn't minute (then we wouldn't need a new copy of it every other week)
<tumbleweed> but yes, generating a new tarball is easier :)
<Corey> Accepted:
<Corey> OK: salt_0.9.6+pre.orig.tar.gz
<Corey> micahg, tumbleweed: You folks are gods among men.
<micahg> Corey: well, that worked but the version seems counterintuitive (something to keep in mind for next time)
<tumbleweed> yeah, was about to say the same thing :)
<Corey> micahg: Yeah.  Technically it should probably have been 7.pre
<tumbleweed> 6+pre > 6
<micahg> usually + has a revno or something on top of the current release
<Corey> But then I thought it'd hose me when .7 comes out in a week.
<micahg> ~ is usually associated with pre-releases as it's lower
<tumbleweed> if it's a pre for 7, you say 7~pre1 (or something like that)
<micahg> or if you're not sure about the next version number, you just do 6+bzr1234 for example
<micahg> that was a 6.1 release superseded
<micahg> *supersedes
<micahg> s/was/way/
<micahg> can't really type today for some reason
<tiox> Semitones thought I would suggest this.
<tiox> I grabbed a package of ZSNES from Debian Wheezy (Thank goodness for pkgs.org) and modified the control file to depend on the lesser version of ia32-libs you guys have, and it works.
<tiox> Not entirely sure if MORE stuff is needed, but I am fairly certain on a fresh install, the Wheezy package would complain about outdated ia32-libs, it looks for 20111001 instead of 20090808*
<tiox> Oh, this is for 64-bit BTW. The zsnes:i386 package provided in the default repositories makes apt rage and want to remove 64-bit SDL.
<tiox> As well as other things, some of the following, with depends: mplayer (medibuntu), blender, love, mupen64plus, cutemupen, electricsheep...
<tiox> With that in mind, I'mma see how running the package from a 11.10 live CD does.
 * micahg wonders why this is appropriate here
<tiox> Because semitones (recently left) thought it would be a good idea to include a 64-bit compatible version of ZSNES in the Pangolin repositories.
<tiox> Don't ask me why, lol
<tiox> He directed me to you guys.
<micahg> well, if there were buildable parts, sure
<micahg> but the zsnes:i386 should work with multiarch, although the package FTBFS ATM
<jtaylor> there is a merge bug for that somewhere
<tiox> ?_? Huh?
<tumbleweed> LGTM multiarch-wise
<tiox> FTBFS? Whuzatmean?
<tumbleweed> fails to build from source
<tiox> Ah.
<ajmitch> yes, there are too many acronyms
<tiox> If I can fetch my log before I formatted my system to see if that would be a fix (I have nothing better to do), I'l show you what it tries to do.
<tumbleweed> ajmitch: that one is particularly poorly documented (from my memory), but I tried to improve that
<tumbleweed> tiox: you said an 11.10 CD, we are talking about 12.04
<tumbleweed> IIRC sdl was only multi-arched recently
<tiox> Well, I could test on 12.04 pre-release, but there's still two months + support time for 11.10
<tiox> And it's what I have on hand right now.
<micahg> ajmitch: WDYMTTATMA
<micahg> wfm in 12.04
<tiox> Sooo, BRB, AFK, TTYL, w/e, l8r.
<ajmitch> HAND
<tiox> Actually, forgot about that paste. Lemme lend that then I'll go.
<tumbleweed> tiox: I agree that there's a problem here in oneiric, but I don' tthink it's easily dealt with
<tumbleweed> (we aren't going to go around multi-arching things in SRUs)
<tiox> I did'nt say it could be easily dealt with.
<micahg> no, but if something was multi-archd improperly, it could be fixed in an SRU
<micahg> *possibly be fixed
<tiox> ANyway, here you go guys. http://paste.ubuntu.com/830846/
<tumbleweed> it simply wasn't multiarched in oneiric
<tiox> Quite an exhaustive list of things to remove just to install one program, no?
<tumbleweed> tiox: everything that uses SDL
<micahg> then why was it not in ia32-libs?
<tumbleweed> not everything is in ia32-libs
<tumbleweed> erm, what was I saying, it is in ia32-libs
<tumbleweed> but we didn't build the crazy ia32libbed amd64 package, so he was trying to install the i386 package with multiarch
<tumbleweed> jtaylor: done any numpy / sphinx experimentation?
<jtaylor> numpy -4 works with sphins 1.12 if you mean that
<tumbleweed> no I mean proposed transitions
<jtaylor> I rebuilt the packages in precise, no failures
<jtaylor> also no suspicous shlibdep warnings in regard to numpy
<tumbleweed> oh, I see a sync bug
<jtaylor> but one with libm which I should look at
<jtaylor> barry took over sphinx
<barry> jtaylor: i'm looking at it now.  is that cool?
<jtaylor> there should be no issues with that either thanks to jwilk
<jtaylor> yes of course
<barry> i'm switching it back to dhpy2 in ubuntu >:-/
<barry> jtaylor: are you going to work on the numpy update, given that doko is cool with it?
<tumbleweed> is jwilk still holding out on dhp2?
<jtaylor> too bad numpy has no py3 package yet :/
<barry> tumbleweed: i guess so, the changes are truly minimal
<jtaylor> barry: doko has no objects to it
<barry> jtaylor: right, go for it!
<jtaylor> I wonder if I should add py3 packages
<barry> jtaylor: i'll happily sponsor uploads if necessary
<barry> jtaylor: i'd say go for it if it's doable
<barry> tumbleweed: maybe i should submit a bug on sphinx just to see what jwilk will say :)
<jtaylor> I thinkthere is one already
<tiox> By the graces of good fortune my package installed and worked.
<barry> and it's funny 'cause he's already using dh_python3 (admittedly the only option)
<jtaylor> no no bug yet
<barry> jtaylor: right
<barry> hey the worst that can happen is that he'll hate me for life
<tumbleweed> barry: I think he's sponsored a package using dh_python2
<barry> cool, maybe he's not opposed to it.  i'll test the change in ubuntu then and file a bug
<tumbleweed> he was pretty opposed to it, but probably knows that python-support isn't going to be around forever
<barry> it *is* officially deprecated after all
<tumbleweed> yeah
<zooko> jtaylor: regarding looking at an autobuild recipe, could you point me at a project that has a debian package and a working autobuild recipe on launchpad?
<jtaylor> zooko: thats one of mine: https://code.launchpad.net/~jtaylor/+recipe/ipython-daily
<jtaylor> its really very simple
<zooko> Excellent, thanks.
<jtaylor> barry: how soon are you syncing sphinx?
<jtaylor> because I think its best to start numpy after that
<barry> jtaylor: i'm working out a udd bug that the merge exposed.  looks like i won't be able to use udd merge to make it work, but as soon as i've verified that, i think i'll just requestsync it and then fix up the dhpy2 changes after that
<barry> shouldn't be more than 15m or so
<jtaylor> no rush, I probably won't get to numpy until friday anyway
<barry> jtaylor: cool.  i'm off-line on friday, but i can sponsor stuff on monday if you can't find another sponsor
<jtaylor> py3 numpy looks like a challenge judging by the length of the rules file, I think I'll first get the transition done first and have a go at py3 if there is still time after that
<barry> +1
<Corey> Hmm.  Why would a dsc that builds into several packages here (common, master, etc) only spit out common in a PPA?
<jtaylor> Corey: buildlog?
<barry> jtaylor: syncpackaged sphinx 1.1.2+dfsg-4.  once that gets processed i'll upload a -4ubuntu1 to switch to dhpy2, but that shouldn't affect the numpy builds
<jtaylor> barry: you'll also take care of the few packages that are broken?
<barry> jtaylor: the ones that are listed in bug 911124 yes
<ubottu> Launchpad bug 911124 in sphinx (Ubuntu) "Please sync python-sphinx 1.1.2 from Debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/911124
<Corey> jtaylor: https://launchpadlibrarian.net/92347092/buildlog_ubuntu-lucid-amd64.salt_0.9.6%2Bpre-lucid2_BUILDING.txt.gz
<tumbleweed> Corey: on amd64, only the architecture-dependant packages will build (assumin gyou also have arch all packages)
<Corey> tumbleweed: OH!  So it'll populate out when the i386 stuff completes in 2-3 hours?
<tumbleweed> I don't know why salt-common is architecture-dependant, it looks pretty independanty to me
<tumbleweed> independant
<Corey> tumbleweed: You're right.
<Corey> tumbleweed: There used to be a compiled msgpack element, but that was broken out into another package.
<tumbleweed> anyway, arch:all packages are built on i386 on Ubuntu
<Corey> tumbleweed: And while I'm fixing things, the version string should go from 0.9.6+pre-lucid2 to 0.9.7~pre1-lucid2?
<Corey> Or am I not quite right?
<tumbleweed> if that describes it better, sure
<jtaylor> the -lucid is a bit weird
<jtaylor> - has special meaning in packages, I'd remove it
<jtaylor> replace it with -0lucid1 or ~lucid1 or +lucid1
<Corey> Ah.
<tumbleweed> you want to have a -, this packgae isn't native
<tumbleweed> -0lucid1 or -0ppa1 is probably best
<Corey> 0.9.7~pre1-0ppa1 <-- this?
<tumbleweed> LGTM
<Corey> tumbleweed: And then when I fix the next bug, it becomes pre2?
<tumbleweed> Corey: depends what you change
<tumbleweed> if you change something upstream, pre2, ifyou change something in the packaging (or fix a bug with a quilt patch) -0ppa2
<Corey> tumbleweed: https://github.com/KB1JWQ/salt/blob/master/debian/control <-- If I don't want fun things like 'gcc' being auto-depped in at install, I should leave them in build-depends and remove them from the common package?
<tumbleweed> Corey: why does salt-common need python-dev?
<Corey> tumbleweed: It doesn't in my latest change.  I'm stripping things out now.
<Corey> tumbleweed: I'm also not convinced that the build-dep needs it either.
<barry> jtaylor: given that your work on numpy will cause the proper rebuild, do we actually need to rebuild virtualenv for the new sphinx?
<tumbleweed> you are building python extensions with cython, so you'll need python-dev
<tumbleweed> Corey: I don't understand your question about gcc
<jtaylor> :q
<jtaylor> does virtualenv depend on numpy?
<jtaylor> also not every depend must be rebuilt, only the ones using the C-api
<barry> hmm, i guess not.  i was just going by the comment in the sphinx bug, but not according to python-virtualenv/d/control
<barry> so ignore virtualenv
<jtaylor> the problematicone is virtualenvwrapper not virtualenv
<barry> ah
<jtaylor> and we need a new upstream of that so the rebuilt will happen in any case
<barry> i think rebuild is probably only necessary if the docs are broken (which would probably ftbfs the package)
<jtaylor> virtualenvwrapper in precise ftbs with sphinx 1.12
<jtaylor> you need .11-2 from unstable
<barry> okay.  i think we can take care of pymvpa2 by just sync'ing 2.0.0-6 from sid.  double checking diffs
<jtaylor> pymvpa already fixed?
<barry> jtaylor: can you add that to the sphinx bug comments.  i'll make sure it's working before i close that bug
<barry> jtaylor: checking that now
<jtaylor> the bug is still open
<barry> the sphinx bug yes, but i don't think it mentions venvwrapper
<barry> oh, it's just a typo. nm, i'll do that
<jtaylor> oh pymvpa2 not one
<jtaylor> it mentions the wrapper, though I named in venv :/
<jtaylor> the link is correct though
<barry> yep
<blair> ScottK, i started a ppa to manage the python 2.6 for precise.  in your note from yesterday, you said "you need to change python-defaults..." but i cannot find that package
<stgraber> blair: apt-cache showsrc python-defaults
<stgraber> it's the source package building: python, python-minimal, python-examples, python-dev, idle, python-doc, python-dbg, python-all, python-all-dev, python-all-dbg
<jtaylor> barry: just in case you didn't notice, sphinx now dep waits for -support as that was demoted
<blair> thanks, i tried apt-cache search and it came up empty
<stgraber> blair: right, because there's not binary package called python-defaults, it's only the name of the source package
<blair> i'll check both in the future :)
<stgraber>   o python-support: python-support
<stgraber>     [Reverse-Build-Depends: sphinx (MAIN)]
<stgraber>  
<stgraber>   o python-whoosh: python-whoosh python-whoosh-doc
<stgraber>     [Reverse-Depends: Rescued from python-whoosh]
<stgraber>     [Reverse-Build-Depends: sphinx (MAIN)]
<stgraber> jtaylor, barry: ^
<barry> jtaylor: crap.  guess i gotta make that fix now then.
<stgraber> (just showed up on the release team mailing-list)
<jtaylor> < offline, probably back friday evening, bye
#ubuntu-motu 2012-02-09
<blair> checking out the source of python-defaults from bzr doesn't seem to match the history in debian/changelog from apt-get source, i cannot see changes in bzr that correspond to the changelog modifications
<blair> i did a "bzr branch http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian co" and then a "bzr log -v"
<Corey> Seeing a weird issue.  Made a few changes, did a git merge from upstream, now the build process is throwing: aborting due to unexpected upstream changes, see /tmp/sa... The problem is that's in a pbuilder chroot which is destroyed before I can read the file.
<Corey> I've built all the files it's using for the build (the tarball, the dsc, etc) via script.
<Corey> Wait, it may be an outdated pbuilder chroot.
<Corey> Yeah, that didn't sort it.
<Corey> What does pbuilder see as "upstream" in this context?
<barry> tumbleweed, jtaylor: oh well, we have our answer: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659196
<ubottu> Debian bug 659196 in python-sphinx "sphinx: Switch to dh_python2" [Wishlist,Open]
<zooko> jtaylor: okay, I'm trying this recipe: http://codepad.org/HxE9Do4d
<zooko> Thanks!
<zooko> Hm, I need to change the debian patches that no longer apply correctly.
 * zooko looks for the "fork me" button on https://code.launchpad.net/~ubuntu-branches/debian/sid/pycryptopp/sid
 * zooko runs "bzr branch lp:debian/pycryptopp"
<RAOF> zooko: Yeah, Launchpad doesn't have a âfork meâ button because bzr branches don't require the elaborate set up that git branches do.  ie: If you want to push a bzr branch somewhere, you âbzr push $SOMEWHEREâ, and it works.
<zooko> Where would $SOMEWHERE be for the purpose of forking lp:debian/pycryptopp to ~zooko/debian/pycryptopp in order to offer new versions of the debian patcheas?
<zooko> Ideally a bzr-builder recipe will be able to merge/pull/nest/use my resulting "~zooko/debian/pycryptopp" instead of or in addition to lp:debian/pycryptopp.
<RAOF> bzr push lp:~zooko/$PROJECT/pycryptopp
<zooko> Thanks!
<RAOF> $PROJECT is probably pycryptopp in this case; it could also be +junk if you don't want it to show up anywhere.
<RAOF> And the final component can be whatever you like.
<zooko> Okay.
<zooko> If I'm sending an email to submit@bugs.debian.org, is there an email address that I should have it be forwarded to in order to register it in the Ubuntu bug tracking system?
<micahg> zooko: https://help.launchpad.net/Bugs/EmailInterface
<zooko> micahg: thanks!
<zooko> (Unfortunately I already sent the email to debian.)
<zooko> I should have waited longer.
<micahg> zooko: probably better to do them separately as the control fields are different, but I assume you have a sent mail folder? :)
<zooko> Oh, I've already opened it through the web UI on launchpad.
<micahg> that works too :)
<zooko> I was just curious if telling Debian to send mail to Ubuntu with a pseudo-header would... help.
<zooko> Help them link their databases to each other...
<micahg> well, you can link to debian in Launchpad and to Launchpad in Debian, the question is which is upstream in this case
<zooko> Why is that the question?
<zooko> I mean, what does it matter?
<micahg> oh, well, in launchpad it doesn't per se, but in Debian, the official "link" AIUI is for bugs forwarded upstream
<micahg> you can still include the LP bug # in the report though and some DDs will close the launchpad bug in their changelog as well
<zooko> Thanks.
<zooko> Is "link" one of the pseudo-headers I can put in debian bug mail?
<zooko> I didn't see that, but I searched for "ubuntu", "launchpad", and "url", but not for "link". :-)
<micahg> zooko: I think you actually want forwarded for the keyword
<micahg> but that should only be use if Debian's not upstream which is usually not the case for an Ubuntu bug
<zooko> Hm.
<micahg> OTOH, if you're pointing to a bug in a project on launchpad like synaptic or some other thing maintained in Launchpad, it would be quite appropriate to use forwarded in Debian
<zooko> Anybody want to help with bzr-builder?
<zooko> dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
<zooko>  
<zooko> From this recipe:
<zooko> # bzr-builder format 0.4 deb-version {revno}+{revno:packaging}
<zooko> lp:pycryptopp
<zooko> nest-part packaging lp:~zooko/pycryptopp/debian debian
<zooko>  
<zooko> Oh well, I have to sleep. Feel free to use that recipe and fix it for me. :-) zooko@zooko.com
<dholbach> RainCT, happy birthday! :)
 * ajmitch really wants to upgrade his work desktop to precise
<dholbach> ajmitch, go go go
<ajmitch> dholbach: but it's running lucid, and I sort of need it to work properly still :)
<dholbach> ajmitch, maybe you could toy around with the sandbox upgrader first then to see if at least the upgrade path would be alright
<ajmitch> though I've been impressed with how well precise has been kept usable, running on my laptop
<dholbach> yep
<ajmitch> dholbach: I've heard of the sandbox upgrader, but don't know anything about it
<dholbach> ask mvo
<dholbach> "do-release-upgrade -s" maybe?
 * dholbach shrugs
<dholbach> I never used it, but heard of it
<ajmitch> does it do some overlayfs magic or something to test out an upgrade?
<dholbach> aufs it says in --help
<ajmitch> same sort of thing I think
<ajmitch> I might try it out, I've got a few packages installed on that desktop
<G> hey, if a package is in the repos for Ocelot, if there is a [needs-packaging] bug open still, should that just be closed fix released?
<zooko> Hello, folks! I'm trying to configure autobuilds of nightly .deb's of a project, and currently it fails with dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
<zooko>  
<zooko> The source is held in bzr, with a ./debian subdirectory, not in an .orig.tar file, but I don't know how to tell "bzr dailydeb" to tell bzr-builder to tell dpkg-buildpackage that.
<pabelanger> any sponsors able to look at bug 928499?  I've attached a debdiff
<ubottu> Launchpad bug 928499 in dahdi-linux (Ubuntu) "dahdi-linux fails to build under 3.2 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/928499
 * zooko reads http://raphaelhertzog.com/2010/10/21/the-secret-plan-behind-the-3-0-quilt-debian-source-package-format/
<geser> zooko: you might want to ask in #launchpad if nobody here can help you with recipes
<zooko> geser: thanks!
<Laney> nigelb: dholbach: my attention was just brought (in #-release) to the fact that we are letting uninstallable packages slip through into release. Would you be interested in helping to organise / publicise a challenge to fix some of them?
<Laney> http://qa.ubuntuwire.org/debcheck/debcheck.py?list=INDEX&package=&arch=&dist=precise
<Daviey> If i know nigelb, he'll have them all fixed by the end of day - himelf.
 * Laney prepares the pro-plus infused Red Bull
<dholbach> Laney, that'd be awesome - but I'm quite busy right now - maybe somebody can write a mail to u-devel with a list of those?
<Laney> ok
<Laney> it would be good if you could include it in the development weekly thingy after it's worked out
<dholbach> we are going to post the update RSN
<dholbach> the next would be next thursday
<Laney> yeah, i won't get around to it this week
<dholbach> ok, I'm very happy to mention it
<Laney> would be a good post-feature-freeze thing anyway
<dholbach> yep
<Laney> cool beans
<dholbach> :-)
<zooko> Hm, well I don't see what my problem is, so I think I'll put my recipe into launchpad and see if it works in the launchpad build environment even though it fails locally.
<zooko> No, because I don't know what the version number is going to come out to be...
<zooko> Sigh.  I guess I'll follow the instructions to use pbuilder to test my recipe...
<rigved> hi everyone. i am going through the quickly tutorial and found a few small errors. I am filing bugs for each of these.
<rigved> i am plaaning on organising a ubuntu global jam and it would be wornderful it i could use these simple bugs to showcase how launchpad etc. works.
<rigved> should i write a comment saying this: Please do not fix this bug as I will use this bug as an example at a Ubuntu Global Jam"?
<rigved> should i set the bug as Assigned To me?
<brendan0powers> I'm interested in getting a package of mine into universe for 12.04
<brendan0powers> But I'd need some changes to the apparmor profiles for bind9, ntp, and dhcpd3
<brendan0powers> Is this the right place to ask questions about this?
<pabelanger> adam_g: ping
<tumbleweed> brendan0powers: speak to the people who usually look after those packages
<brendan0powers> Ok, thanks
<tumbleweed> how invasive are the changes?
<brendan0powers> I don't think they are too invasive
<brendan0powers> The profiles need to be extended to allow them to read some files in sambas private directory
<brendan0powers> Specific files
<tumbleweed> #ubuntu-server maybe?
<brendan0powers> I'll talk  to the package maintainers
<brendan0powers> I assume that modifying the profiles during installation is not acceptable?
<tumbleweed> correct. It'd also help if your application was already in the archives
<tumbleweed> and FF is very very soon
<brendan0powers> Does the FF include universe?
<tumbleweed> yes
<brendan0powers> Ah, I was under the impressions that universe froze later
<tumbleweed> (although we do grant exceptions)
<brendan0powers> Well, the apparmor changes are actually for samba4, not for my package
<brendan0powers> I just set up and configure samba4
<arand> Is it possible to FFE something in advance? I'm in the process of getting sponsorship for a game in Debian, but it will likely not end up in testing before the FF, and I'd really like for it to be in precise...
<tumbleweed> brendan0powers: in that case, those are bugs in the apparmor profiles (IMHO)
<tumbleweed> (assuming it's a sane configuration, which it sounds like)
<tumbleweed> arand: if it's a leaf package, there shouldn't be any problem
<arand> tumbleweed: Leaf in terms of dependencies?
<tumbleweed> yes
<arand> Hmm, it's actually a leaf, and a leaf-branch in that regard, but as a whole they're a leaf, at least.
<stefanct> hi. i am an upstream developer of a package that usually gets into universe by auto-syncing from debian. id like to know what is required to get upload rights to a package (mainly to be able to sync the package after debian import freeze but before ff)
<dholbach> hey stefanct
<dholbach> stefanct, the application process is explained here: https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<dholbach> stefanct, basically you set up a wiki page (using the template) explaining your involvement, get a few comments from people you've worked with, send a mail to the developer membership board and attend a meeting
<stefanct> dholbach: thanks!
<dholbach> anytime
<mitya57> stefanct, see also https://wiki.ubuntu.com/UbuntuDevelopers#Per-package_Uploaders for more details
<mitya57> and, obviously, you can request syncs via launchpad
<stefanct> mitya57: have done that for 10.10 https://bugs.launchpad.net/ubuntu/+source/flashrom/+bug/816918
<ubottu> Ubuntu bug 816918 in flashrom (Ubuntu) "please sync flashrom 0.9.4+r1394-1 from debian unstable" [Wishlist,Fix released]
<nigelb> Daviey: Thanks for the confidence :P
<nigelb> Laney: Atm, I'm out of town on work, so I don't have any available time to be able to commit to anything.
<blair> apt-get showsrc python-defaults shows where the package is in debian, but where is it in ubuntu?  i'd like to get copy of the history to reverse merge the removal of python 2.6
<blair> ok, found it "bzr branch lp:ubuntu/python-defaults"
<adam_g> pabelanger: pong
<pabelanger> adam_g: wanted to see if you had some time to checkout bug 928499, since you last uploaded it
<ubottu> Launchpad bug 928499 in dahdi-linux (Ubuntu) "dahdi-linux fails to build under 3.2 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/928499
<Daviey> pabelanger: Leave it with me.
<Daviey> pabelanger: drop debian-changes-1:2.5.0.1+dfsg-1ubuntu2 ?
<Daviey> .patch
<pabelanger> Daviey: ya, not sure what happen there. debian-changes-1:2.5.0.1+dfsg-1ubuntu2 can be removed
<Daviey> pabelanger: okay, if nobody gets to it before tomrrow - i'll sponsor it
<pabelanger> great, thanks
<Daviey> pabelanger: the patch can be dropped, or needs inserting somewhere else.
<pabelanger> ya, dropped.  I can upload a new debdiff fixing it
<Daviey> pabelanger: BTW, the DEP-3 patches do not seem to follow adherence.. but i might just need to look closer.
<pabelanger> ack'd, will update them too
<Daviey> pabelanger: great!
<pabelanger> Daviey: fixed
<pabelanger> thanks again
<blair> can i run "debuild -S -sd" on my oneiric box but have it be for a PPA for precise?
<Ampelbein> blair: Yes.
<blair> thanks!
<blair> confirming that the standard for numbering a package one is overriding in a PPA is to append "ppaN" to the ubuntu version number?
<Ampelbein> blair: There isn't a official standard, I like the -XubuntuY+ppa1 scheme
<blair> ok, so my ppa is for providing python 2.6 modules, so i could number it 2.7.2-9ubuntu2py26.1 instead of 2.7.2-9ubuntu2ppa1
<blair> can one only have a single - in the version number, or could i have 2.7.2-9ubuntu2py26-1?
<micahg> for the Ubuntu revision, yes, for the upstream part, no
 * micahg would suggest +py26ppa1 or something
<micahg> blair: BTW, you might want to checkout the backportpackage tool
<blair> i like that name suggestion
<blair> i'm taking the latest python-defaults, reverse merging the commit from bzr into it and uploading the new thing into github :)
#ubuntu-motu 2012-02-10
<blair> let's say there was a python 2.8 and ubuntu wanted to recompile all source packages to include it, how would one easily do that to ensure packages are built in the correct order?
<blair> i'm wondering how to put 2.6 modules back into my PPA for precise
<blair> even trying to get distribute or python-setuptools built has a number of dependencies
<lifeless> the buildd system does that automatically
<dholbach> good morning
<mitya57> dholbach: I updated a branch for bug 927602, can you please look again at it?
<ubottu> Launchpad bug 927602 in Ubuntu "[needs-packaging] unity-mail" [Wishlist,In progress] https://launchpad.net/bugs/927602
<pabelanger> jamespage: thanks for uploading the dahdi-linux package
<pabelanger> working on seeing if I can get membership to help maintain it
<jamespage> pabelanger, hey  - no problem - thanks for taking the time to fix it!
<achiang> hello, what is the strategy of maintaining a package in both debian and ubuntu, re: apport hooks?
<achiang> (nb, i realize there aren't individual package maintainers in ubuntu ;)
<micahg> achiang: only install them in Ubuntu?  There's a helper, dh_apport
<achiang> micahg: hm, is there an example of that? i guess my real question was, "do i need to fork this package" or can i upload the apport hook to debian but only install in ubuntu, as you say
<micahg> achiang: no need to fork, idr offhand what a good example is for this though, you just check in debian/rules if you're on Ubuntu or a derivative and run dh_apport
<tumbleweed> Laney: sorry, was afk
<achiang> micahg: interesting. is there a standard way to check if you are on ubuntu/derivatives in d/rules? that's a new one for me
<micahg> achiang: take a look at #4: http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/
<achiang> micahg: ah, nice! thanks
<dupondje> jbicha: around ?
<jbicha> dupondje: aloha
<dupondje> jbicha: could you check ubuntu.dupondje.be/freerdp_1.0.1-0ubuntu1.debian.tar.gz
<dupondje> packaged new version :)
<micahg> dupondje: they're planning on putting it in through Debian Monday I think
<dupondje> oh ok :)
<jbicha> dupondje: for .symbols, leave off the debian revision. In other words 1.0.1 instead of 1.0.1-0ubuntu1
<dupondje> jbicha: oh ok :)
<jtaylor> nice only 3 problematic packages for the numpy transition
<jtaylor> one of them probably no problem, another has a fix in unstable
<brendan0powers_1> I'm looking to get a package into Universe, and the Ubuntu Wiki suggested I come here before filing a request to package bug
<brendan0powers_1> I realize that the feature freeze is monday, what is the chance I could get an exception?
<micahg> for a new package, it shouldn't be that hard right after feature freeze unless it changes the way other apps work
<micahg> but IANA release team member
<brendan0powers_1> Ok
<brendan0powers_1> I've gone through the first stage of package, run lintian with no errors, tested with pbuilder, and have a package building in launchpad now
<micahg> Do you have any interest in maintaining the package in Debian?
<brendan0powers_1> At some point, I'd like to get the package into debian
<brendan0powers_1> But I'd really like to get it into Ubuntu 12.04 if I can
<brendan0powers_1> So, If I understand this right, I just file an intent to package bug, assign it to me, and wait for someone to see it?
<micahg> brendan0powers_1: I'd suggest getting it uploaded to Debian, see http://mentors.debian.net/, then you can request a sync
<micahg> in Debian, you only need one sponsor, in Ubuntu, you need 2 people to review it
<brendan0powers_1> Ok
<micahg> there are some DDs that hang out here that might be able to help, there's also #debian-mentors on OFTC
<micahg> and there's always backports even if it misses the release
<jtaylor> apropo new packages: anyone know the problem he has: http://revu.ubuntuwire.com/details.py?package=indicator-bug
<jtaylor> also could need a second review
<jtaylor> do new upstream versions of ubuntu only packages also need 2 reviews?
<micahg> idk, maybe bad source package creation? or could be a problem on the server, maybe ask in #ubuntuwire
<micahg> jtaylor: nope
<jtaylor> I should do wakeup this weekend then :/
<achiang> micahg: is adding an apport hook to an existing package justifiable past FF ?
<jtaylor> I'd still appreciate more eyes on that code, the current version is full of security flaws, no idea if I spotted all :/
<micahg> achiang: IMHO, sure, that's to make bug reports better
<micahg> but IANA release team member
<jtaylor> (most certainly not)
<achiang> micahg: ok, thanks
<micahg> jtaylor: ugh, that's not good, I'd suggest to keep iterating then, there's always backports (which may be open pre-release if broder ever makes it so)
<ajmitch> speaking of broder...
<broder> uh-oh
 * broder 's irc client was flaking
<ajmitch> broder: don't worry :)
<jtaylor> micahg: the currently proposed version is much better than what we have in ther archive, so that would be better than backports
<jtaylor> it should not introduce new security bugs
<ajmitch> introducing new security bugs is generally a bad thing
<micahg> jtaylor: oh, it's already in :)
<jtaylor> unfortunatly
<jtaylor> needs a -sec update in oneiric at some point
<micahg> I don't see it in the archive :)
<jtaylor> https://launchpad.net/ubuntu/+source/wakeup
<micahg> oh, that one :(
<broder> jtaylor: i was just looking at your svn merge, and the test suite failed: http://paste.ubuntu.com/837089
<broder> any ideas?
 * ajmitch needs to go & sync a new coffeescript before it's too late
<jtaylor> broder: thats new, it succeeded for me when I did it and for one other person just a few weeks ago
<jtaylor> let me try it
<broder> :-/
<broder> i can try again
<broder> it did do me the favor of waiting to fail until it had been churning for about 45 minutes :)
<jtaylor> zzzZZZzz bzr branching takes its time
<jtaylor> broder: did you try without the patch if the testsuite then succeeds?
<broder> nope, not yet. i can
<jtaylor> I just also started one build with patch one without
<jtaylor> lets hope its not random ._.
<jtaylor> the failure does not look related, its a wc test, the patch touches the authentification with the repo
<broder> yeah, that's what i figured
<micahg> jtaylor: you might want to talk to the security team and get CVEs assigned if appropriate (wakeup)
<broder> jtaylor: build worked this time, so must be intermittent or something
<jtaylor> broder: I got a successful build too, a second failed due to my disk being full :(
<broder> *shrug* well, i've uploaded it
<jtaylor> great thanks
#ubuntu-motu 2012-02-11
 * broder sighs
<broder> i think i just lost at the game of code review chicken
<broder> which is to say, i just opened up https://code.launchpad.net/~jderose/ubuntu/precise/couchdb/1.1.1-low-delta/+merge/85301
<ajmitch> broder: what's the problem with that? that diff looks like it should only take a few minutes to review :)
 * broder glares at ajmitch
<ajmitch> with that many conflicts?
<broder> i mean, whatever bzr dance jderose was trying to pull off clearly didn't work
<broder> that's on my list of pending feedback
<ajmitch> yeah, I can't remember what's required to get it to base the diff off the debian branch
<ajmitch> at least the diff in the description looks a bit more manageable
<ajmitch> still, if the couchdb split is done differently than it was previously, it may need some fixing
<broder> right, that's what i'm trying to figure out
<broder> it does look like there are differences in the resulting package, which would have also been helpful information to include
<broder> bah. also, debian bug #573061 refers to a VCS commit with a potential package split for debian to a repository which no longer exists
<ubottu> Debian bug 573061 in couchdb "[couchdb] Split couchdb into separate packages" [Wishlist,Open] http://bugs.debian.org/573061
<ajmitch> what still depends on couchdb these days?
<broder> so i can't really evaluate how similar this split is to what debian is going to do, if the maintainers ever do actually do anything
<broder> all of novacut's stuff, appraently
<ajmitch> will it affect U1 in precise?
<broder> also channel-server, libnode-cradle, and desktopcouch
<broder> ENODATA
<broder> i thought U1 was mostly transitioning away from couch
<ajmitch> I see it's been dropped back to univere anyway
<broder> yeah, and ubuntuone-client at least hasn't
<broder> i do feel like i'm struggling not to blame the contributor for our lameness in my writeup. there's a balance here that's hard to find
<broder> :-/ the diff he posted in the MP description isn't accurate
<ajmitch> despite the version not having changed?
<broder> i guess? the branch changes debian/rules differently than the description suggests
<broder> anyway, it looks like the discussion is actually happening on the bug, not the MP
 * achiang struggles to add an apport hook to a package... http://pastebin.ubuntu.com/837476/
<achiang> the idea is that i'd like to run dh_apport only on ubuntu
<achiang> but i don't know where to put that. make an override_dh_apport: target?
<achiang> one thought i had was to see who rdepends on dh-apport to find an example, but i guess rdepends doesn't work on B-D
<broder> i don't believe there's any way to do that
<broder> you're not allowed to change the build-depends as part of the build process
<ajmitch> but you can prefix a command with - so that it doesn't error out when built without it
<broder> yes, but if there's no way for you to get dh-apport on the build-dep list in the first place...
<ajmitch> I don't know if that's the best way to do it here, as it also hides other errors
<broder> see "CDBS" on http://ftp-master.debian.org/REJECT-FAQ.html
<achiang> hm
<broder> i think your best bet is to do what dh_apport does by hand, conditionally, in the rules file
<broder> or possibly just ship the hook unconditionally
<achiang> yeah, by hand is what bluez (and other examples) do
 * ajmitch would prefer apport to be in debian :)
<achiang> ok, thanks for the help
<broder> does anything good happen when a conffile moves from one package to another? i would assume that triggers a conffile conflict more or less automatically
<ajmitch> http://wiki.debian.org/DpkgConffileHandling has info about moving location, but not about it being moved between 2 packages & keeping the filename
<broder> right, i know about the stuff on that page
<broder> maybe if you add a Replaces
<ajmitch> http://lists.debian.org/debian-devel/2006/12/msg00647.html implies that Replaces wasn't enough, at least back then :)
<broder> oh god, so *that's* why openssh's maintainer scripts are such a mess
<broder> "once we can expect everyone to have etch's dpkg installed we can move conffiles between packages more or less like any other files"
<ajmitch> right
<ajmitch> I think we're a bit past that point now
<broder> given that half of the upgrade is going to pre-depend on a dpkg with lzma and dpkg-maintscript-helper...
<broder> ooh, speaking of which, http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html has built up a collection of tags
<broder> i'm not sure what to do with the changelog for the couchdb merge
<broder> jderose didn't make any attempt to merge in the ubuntu history
<broder> but he also (deliberately) didn't attempt to merge in the rest of the packaging
<broder> so dropping the ubuntu history doesn't seem completely unreasonable
<broder> phew. that was a doozy
<jtaylor> how do I resolve conflicts in .pc/* with bzr?
<jtaylor> the numpy dh_python2 was sure done carefully ._.
<jtaylor> no wonder debian is so relucatant to take patches
<tumbleweed> :P
<jtaylor> so numpy 1.6 branch including multiarch fix ready
<jtaylor> anyone want to sanity check it?
<jtaylor> lp:~jtaylor/ubuntu/precise/python-numpy/merge-1.6
<jtaylor> there are dangling symlinks, but they are also present in debian
<jtaylor> they don't look like a reason to diverge further
#ubuntu-motu 2012-02-12
<Ampelbein> With this http://paste.ubuntu.com/838760/, I still get the hardening flags in $CFLAGS. According to dpkg-buildflags' man-page, "export DEB_BUILD_MAINT_OPTIONS = hardening=-all" should disable hardening. What am I doing wrong?
<micahg> we have some default hardening in our toolchain, I wonder if that's supposed to be removed in this case
<Ampelbein> micahg: If I call 'DEB_BUILD_MAINT_OPTIONS=hardening=-all dpkg-buildpackage' CFLAGS is set correctly so I guess it should.
<micahg> you have extra space around the first = in the paste, idk if that would make a difference though
<Ampelbein> It's a makefile so that shouldn't matter.
<Ampelbein> It doesn't.
<tumbleweed> Ampelbein: to get the effect of DEB_BUILD_MAINT_OPTIONS you need to export CFLAGS et al yourself
<Ampelbein> tumbleweed: Ah, ok. I was under the impression that dpkg-buildflags handles that for me.
<Ampelbein> debian bug 644412 sounds related
<ubottu> Debian bug 644412 in dpkg-dev "dpkg-buildflags: use DEB_BUILD_MAINT_OPTIONS when including buildflags.mk" [Normal,Fixed] http://bugs.debian.org/644412
<tumbleweed> Ampelbein: it handles it for you, if you use it
<tumbleweed> sure, you can use buildflags.mk
<tumbleweed> or just do it by hand (I do that in pypy)
<Ampelbein> What I don't get is: It works correctly if I do 'DEB_BUILD_MAINT_OPTIONS=hardening=-all dpkg-buildpackage'
<tumbleweed> that's because dpkg-buildpackage runs dpkg-buildflags
<tumbleweed> (although that  behavior has been dropped in Debian)
<tumbleweed> we'll presumably follow suit in q
<micahg> Ampelbein: don't forget to document the disabling of hardening flags on the security wiki page (I assume you trying disabling some of them before all)
<Ampelbein> micahg: It's about a fpc using package (gearhead), which should not have hardening enabled in the first place as the programming language is pascal.
<micahg> Ampelbein: hmm, if that's true, then we probably need a more generalized solution for this that disabling on a per package basis
<Ampelbein> micahg: The build failure in question: https://launchpadlibrarian.net/92025261/buildlog_ubuntu-precise-i386.gearhead_1.100-2_FAILEDTOBUILD.txt.gz
<Ampelbein> That's another thing I don't understand. According to the manpage of dpkg-buildflags, only in dh compat level 9 should the flags be exported. The package uses compat level 5...
<micahg> we have -fstack-protector in our toolchain by default amongst other things
<micahg> did you try just without that?
<Ampelbein> Yes, fpc doesn't understand any -format, -format-security, -fstack-protector
<tumbleweed> Ampelbein: we export the build flags in dpkg-buildpackage
 * tumbleweed digs out the e-mail announcing that
<micahg> still, there are about a dozen packages that use fpc, I'm wondering how any of them built befre
<tumbleweed> Ampelbein: https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034351.html
<Ampelbein> micahg: In the case of gearhead, the last build was october 2010
<Ampelbein> Where CFLAGS didn't include any of the hardening flags (https://launchpadlibrarian.net/48191679/buildlog_ubuntu-maverick-i386.gearhead_1.100-2_FULLYBUILT.txt.gz)
<Ampelbein> tumbleweed: thanks, reading.
<micahg> ah, ok
<tumbleweed> our gcc also does hardening flags by default, doesn't it
 * tumbleweed forgets
<micahg> yeah, but this is fpc which is why it worked before, now the hardening has moved
<tumbleweed> micahg: thanks for reminding me tha tI should document the lack of hardening in pypy
<Rhonda> hmm, so what's the proper version for a lucid-backport?  (heading to the wiki to check herself â¦)
<Rhonda> hmm, either I missed it, or https://wiki.ubuntu.com/UbuntuBackports doesn't state so â¦
<Rhonda> duh
<Rhonda> Make people more aware of backports, and make the backport request process less transparent
<Rhonda> shouldn't that read MORE transparent instead of LESS transparent?!?
 * Rhonda . o O ( from https://wiki.ubuntu.com/BackportsPromotion )
<Rhonda> â¦ not that the page looks in any sense relevant, or current. :)
<Zhenech> oh hai Rhonda -- want to do some syncs for me again? :) https://bugs.launchpad.net/ubuntu/+source/pokerth/+bug/930906 https://bugs.launchpad.net/ubuntu/+source/monkeystudio/+bug/930907
<ubottu> Ubuntu bug 930906 in pokerth (Ubuntu) "Sync pokerth 0.9.3-1 (universe) from Debian sid (main)" [Undecided,New]
<ubottu> Ubuntu bug 930907 in monkeystudio (Ubuntu) "Sync monkeystudio 1.9.0.1-2 (universe) from Debian sid (main)" [Undecided,New]
<Zhenech> (yes, yet another pokerth update, sorry, upstream is active)
<Rhonda> hmmm, start to wonder what the build1 of monkeystudio was for
<Zhenech> Rhonda, libqscintilla 2.6.0 i guess
<Zhenech> it bumped soname some month or two ago
<Rhonda> ah, that build1 was also available in debian, and not only in ubuntu?
<Zhenech> yepp
<Zhenech> +b1 there of course, but you get the point
<Rhonda> subject: [ubuntu/precise] monkeystudio 1.9.0.1-2 (Accepted)
<Rhonda> subject: [ubuntu/precise] pokerth 0.9.3-1 (Accepted)
<Zhenech> thanks a lot
<Rhonda> de nada
<Rhonda> now tell me what version I need to use :)
<Zhenech> ~bpo60+1
<Zhenech> :P
<Rhonda> does 1:1.10-1~lucid1 look proper?
<Rhonda> Zhenech: ~bpo60+1 is done already ;)
<micahg> Rhonda: looks right for the official version, backportpackage can help though with an unofficial version to be superseded if backported in the archive
<micahg> Rhonda: why didn't you sponsor the syncs? (syncpackage -s)
<Rhonda> oh
<Rhonda> erm, because I forgot about that :)
<micahg> heh, ok :)
<Rhonda> I would have thought that is done implied when I have the rights to
<Rhonda> Because it does use launchpad anyway?
<micahg> well, you have rights to upload, but -s gives whoever you pass to it the credit for the sync
<Rhonda> ah, so -s zhench?
<Rhonda> or rather, sargentd
<Rhonda> will try to remember
<micahg> yep
<Zhenech> mh, reminds me I wanted to get ~evgeni on launchpad some timeâ¦
<Zhenech> but that means i have to kill my ppas
<Rhonda> cant you transition them?
<Zhenech> creating a new user and then moving around? yeah could work
<Zhenech> lp is able to rename users though, they just cannot have ppas
<Rhonda> no, get the accounts merged
<Rhonda> ah
<Rhonda> only recently started with ppas
<Zhenech> mh, the only really used ppa is the monkeystudio one and we could just move it to the monkeystudio groupâ¦
<Rhonda> would make it more official looking, yes
<dupondje> Still ok to do sync requests ?
<Ampelbein> dupondje: Feature Freeze is on thursday, so yes.
<dupondje> ok :) lets do some
<broder> to be clear, FeatureFreeze doesn't mean we can't do syncs/merges anymore. it just means that either they have to only contain bugfixes (no new features) or they have to be approved by the release team (which isn't that hard, especially immediately after FF)
<dupondje> but its better to do it asap ofc ;)
<tumbleweed> as long as you don't break enerything, sure
<tumbleweed> everything
<ajmitch> 'break everything' would be starting a new major library transition this week, without serious coordination
<dupondje> new packages also allowed? http://packages.qa.debian.org/d/daq.html
<dupondje> would like to get the prehistoric snort gone :)
<tumbleweed> dupondje: nothing wrong with new packages (in moderation)
<Miker> Hello
<Miker> Anyone there
<bregma> no
<Miker> Nobody is chatting so I was just wondering
<Miker> Whats up with you Mr Webb?
<Miker> Grammys is on tonight
#ubuntu-motu 2013-02-04
<micahg> Laney: why is handbrake in quantal-backports and not in raring?
<ESphynx> hey micahg =) 'evening
<micahg> hi ESphynx
<ESphynx> how's it going ;)
<micahg> ok
<ESphynx> good stuff :P Please let me know if the ball's in my court and I have something to do to get this SRU or conflict resolution moving :P
 * micahg wasn't aware he was supposed to review something
<ESphynx> oh :P
<ESphynx> well I didn't really know what the next step was :P
<ESphynx> I subscribed ubuntu-sru
<ESphynx> but I had gone over all the bugs again and tested the test cases and stuff
<micahg> ubuntu-sru doesn't put it in the queue, ubuntu-sponsors does
<ESphynx> ah well that's what I was confused about
<ESphynx> but I thought you were going to review these first anyways :)
<ESphynx> So should I add ubuntu-sponsors ?
<micahg> that or give me a bug # with the debdiff
<micahg> I can't review it tonight though
<ESphynx> micahg no hurries :) whenever you have the chance
<ESphynx> micahg: I got all these there https://bugs.launchpad.net/ubuntu/+source/ecere-sdk/+bugs
<ESphynx> And they each have a link to a bzr revision with the diff
<ESphynx> e.g. Fixed by http://bazaar.launchpad.net/~jerstlouis/ecere/quantal_sru/revision/804    and packaging:  http://bazaar.launchpad.net/~jerstlouis/ecere/quantal/revision/2  (This is the only one with 2 diffs, 'cuz it's packaging and orig)
<micahg> oh, um, it's usually one debdiff with a bunch of quilt patches
<ESphynx> but the bugs are all separate?
<ESphynx> though all the revisions are in line
<micahg> umm...I only see 2 revisions in that branch
<ESphynx> http://bazaar.launchpad.net/~jerstlouis/ecere/quantal_sru/changes   -- i.e. diff from 802 to 817  (though 803 was deemed unncessary)
<ESphynx> (it only was a problem on Windows)
<micahg> yeah, this won't work, each fix should be turned into a quilt patch since the package is 3.0 (quilt)
<ESphynx> I have no idea what is a quilt patch :P
<micahg> there's an easy way to do that with bzr, but I don't remember offhand
<ESphynx> I see the link there: http://bazaar.launchpad.net/~jerstlouis/ecere/quantal_sru/diff/803
<ESphynx> that gives you a .diff , is that what you awnt?
<micahg> it can be a .diff, but it needs to be a proper patch under debian/patches/
<ESphynx> But all of them together?
<ESphynx> http://en.wikipedia.org/wiki/Quilt_(software) -- oh geez... this is a whole tool thing :P
<micahg> well, each fix is a separate file under debian/patches
<micahg> http://wiki.debian.org/Projects/DebSrc3.0#But.2C_how_do_I_actually_work_with_the_3.0_.28quilt.29_format.3F
<ESphynx> thanks
<ESphynx> if I basically download all these diffs
<ESphynx> and name them 803.diff 804.diff ?
<ESphynx> and put these in debian/patches/ , is that kind of the idea?
<micahg> ESphynx: well, dpkg applies patches listed in the series file during the unpack phase with source format 3.0
<ESphynx> so what you're saying is... this is part of the whole 'package' thing ?
<micahg> yeah
<ESphynx> i.e. the source remains the 'orig' source?
<micahg> exactly
<ESphynx> I get it :P
<ESphynx> and tehse patches are listed in another file?
<ESphynx> or automatically taken from patches/
<micahg> debian/patches/series
<ESphynx> so debian/patches/quantal ?
<micahg> no
<micahg> series is the name of the file
<ESphynx> ah ok.
<micahg> I can see how that's confusing :-/
<ESphynx> and in there I'd list
<ESphynx> 803.diff
<ESphynx> 804.diff
<ESphynx> ?
<micahg> ESphynx: you might want to have more descriptive names, but it's fine to prefix them with the revision if you like
<micahg> I guess it's time for me to test build against proposed
<ESphynx> yeah I'll improve on the name
<ESphynx> test build what?
<micahg> (last comment was in regard to haskell)
<ESphynx> ah haskell :)
<micahg> Laney: sorry for the bad rebuild...I need to enable proposed in my chroot, I'll fix it later
<ESphynx> micahg: so that's basically it? patches/series ... list the bunch of diff, individual diff
<micahg> yeah
<ESphynx> thanks for breaking it down for me :P I hate crawling docs :P
<ESphynx> I'll work on this tomorrow, upload as a package or what not and give you a shout then
<micahg> ok
<ESphynx> thanks again =) good night
<micahg> ESphynx: sure, good night
<micahg> ESphynx: oh, one more thing, I think LP does -p0 by default, source format 3.0 expects -p1, so I think you'll need to use bzr to do it, someone else might remember the commands to make it work (if not, I can figure it out tomorrow)
<ESphynx> I never understood the difference between p0 and p1. are those 2 formats?
<ESphynx> I don't actually have bzr, I'm a git'ter :P I just use the launchpad import... maybe there's a way to do with git too?
<micahg> yeah, git is used by a lot of DDs
<micahg> I'm sure there's a guide somewhere
<micahg> ESphynx: -p0 addresses files in the current directory, -p1 skips the first the dir listed in each file in the patch
 * micahg disappears now
<ESphynx> thanks
<dholbach> good morning
<ESphynx> good morning dholbach
<ESphynx> I always dread your good mornings :( means I'm staying up way too late :P
<dholbach> hi ESphynx
<Niraj_> hi dholbach
<geser> good morning
<Laney> micahg: it was a pre-release backport and we still don't have the tools to track those / anyone doing it
<micahg> Laney: re handbrake> ok, so you mind if I move it forward then?
<Laney> I think I just saw it join the queue actually
<Laney> big brother is watching ...
<micahg> yeah, dholbach just sync'd it
 * micahg guesses he forgot to grab it last niht
#ubuntu-motu 2013-02-05
<geser> good morning
<nigelb> HI geser
<dholbach> good morning
<ESphynx> good morning dholbach
<ESphynx> guess it's time for me to go to bed :(
<shadeslayer> hehe
<alo21> SpamapS, Hi... may I ask you a thing?
<ESphynx> xnox: ping :) did you get the chance to review this 0.44.03 package solving the libec0 conflict? :)
<kirkland> any idea why a package only depending on python would automatically pull in python-support as a dependency?
<tumbleweed> kirkland: dh calls dh_pysupport by default, in compat < 9
<tumbleweed> you probably meant to do dh --with python2
<tumbleweed> $@ as well :)
<dholbach> I just got the question from somebody on #ubuntu-on-air - does anyone know why ffmpeg was removed? I can't find the info in LP
<Laney> renamed to libav wasn't it?
<Laney> well, forked and we chose that side of the fork
<Laney> dholbach: ^
<dholbach> ah ok
<dholbach> thanks Laney
<kirkland> hmm, any ideas here?  this build is failing on lucid as it's not finding python-support ... https://launchpadlibrarian.net/130475429/buildlog_ubuntu-lucid-i386.ssh-import-id_3.3-0ubuntu1~lucid_MANUALDEPWAIT.txt.gz
<Laney> kirkland: I don't think alternate build-depends really work
<kirkland> Laney: hrm, okay...
#ubuntu-motu 2013-02-06
<micahg> kirkland: Laney: that's bug 594916
<ubottu> bug 594916 in launchpad-buildd "buildd does not install alternate dependency for versioned ORed build-dependencies" [Low,Triaged] https://launchpad.net/bugs/594916
<kirkland> micahg: k, thanks
<Niraj_> Hi can anybody tell me, as a beginner to ubuntu dev, where can I find issues to fix?
<astraljava> Niraj_: Good starting points: https://wiki.ubuntu.com/UbuntuDevelopment and http://developer.ubuntu.com/get-started/, the former about development of Ubuntu, the latter development on Ubuntu. :)
<Niraj_> Thanks astraljava
<astraljava> Niraj_: Also, lots of good questions being answered on Launchpad's answers section.
<Niraj_> I was hoping to start by actually dirtying my hands in some bug. So, if there is any list of 'paper-cut' bugs, I can get started immediately.
<TheLordOfTime> the advice we tend to give new bug people is to pick a package you're passionate about and look there
<TheLordOfTime> since there's literally hundreds of packages in the repositories (?)
<TheLordOfTime> and by 'we' i mean the bugsquad
<TheLordOfTime> s/look there/start there/
<Niraj_> Only problem I find is that most of the packages are so matured that bugs are quite involving.
<Niraj_> which may be a bit difficult in begining
<TheLordOfTime> and now you know why i don't like teaching new bug people about bugs :P
<TheLordOfTime> except in passing :p
<TheLordOfTime> most of the bugs I see're segfault bugs
<TheLordOfTime> which are intense ones
<TheLordOfTime> 'course, being on bug control, i see the private bugs too, so... :P
<Niraj_> hmm. how about packaging problems? or packaging new tools which not yet in ubuntu?
<TheLordOfTime> i wonder if we still have the 'bitesize' bug things...
<Niraj_> I searched in launchpad, didn't find any
<ESphynx> if all else fails, I have some bugs to fix in my project :P
<Niraj_> tell me
<Niraj_> I'll give it a shot
<ESphynx> Niraj_: http://ecere.com/mantis/ --> that's our tracker :P
<TheLordOfTime> Niraj_:  yeah, i think we got rid of 'bitesize', but idk
<TheLordOfTime> Niraj_:  for the record, my specialty is with certain packages, i work with a couple of the server packages, and a bit of universe...
<TheLordOfTime> and i dabble when its necessary in other bugs :P
<TheLordOfTime> (just saying)
<Niraj_> TheLordOfTime: which packages you are working right now?
<TheLordOfTime> none, at the moment, i'm rebuilding my ubuntu system :p
 * TheLordOfTime had critical HDD failure :P
<ESphynx> =( HD failures suck
<TheLordOfTime> yep
<TheLordOfTime> of course, i do my packaging/bug-debdiffing in the cloud, so...
<Niraj_> thanks guys. I can start in ecere for now
<TheLordOfTime> Niraj_:  the packages i keep my eye on are: nginx (universe), znc (universe), php5 (main), and a few others, but my primary focus is bugs triage, not "fixing" the bugs all the time :p
<TheLordOfTime> i.e.  getting bugs from new/confirmed -> where it needs to be to be fixed.
<TheLordOfTime> so i'm less of a dev, more of just a bugs triager :)
<TheLordOfTime> ... speaking of which i need to check one of the nginx bugs i am on...
<dholbach> good morning
<ESphynx> good morning dholbach :)
<ESphynx> My acupuncturist gave me what I think of a good advice today...
<ESphynx> I was complaining how 24 hours in a day wasn't enough for me, she said to think of it as 48 half-hours :P
<dholbach> hi ESphynx
<dholbach> :-)
<ESphynx> so from now on I live on a different planet with 48 shorter hours.
<ESphynx> dholbach what are you up to?
<ESphynx> are you hired by Canonical?
<dholbach> yes, I work for Canonical
<ESphynx> in a local office or at home?
<dholbach> at home
<ESphynx> cool
<ESphynx> I should get a watch that beeps every 30 minutes
<ESphynx> or at least set up a sound on my computer
<geser> ESphynx: do you know work twice as fast or does a task which took 1 hour earlier now take 2 half-hours? :)
<ESphynx> geser: I'm hoping thinking of it that way will get me working twice as fast :)
<ESphynx> my theory is the following...
<ESphynx> Say a task takes me about 10 minutes of intense neural activity to do... and then the next 50 minutes I waste slacking away seeing the hour pass... Now I'm going to be doing these 10 neuron rushes every 30 minutes instead of every hour :P
<ESphynx> but generally the problem is that I have a bulldozer approach to coding... I just sit and code till I drop or the problem is solved... and if I drop I'm back at it as soon as I'm functional again
<ESphynx> now this has a tenedncy to throw my sleep and other life patterns completely out of wack, and it's having a serious toll on my body... also doesn't leave time for me to exercise as I should :(
<ESphynx> and maybe I can allocate time more efficiently and make everything fit in 48 half-hours easier than in 24 hours =)
<dholbach> sometimes it's hard to see the value and positive effect of breaks
<ESphynx> is there a 'but' coming? lol
<dholbach> but once you do do them, you're harming your body less
<ESphynx> ah :)
<Quintasan> \o
<rikketik> \join ubuntu-dev
<rikketik> \join #ubuntu-dev
<Niraj_> hi, can somebody tell me how can I make 32bit and 64bit packages coexist in my system?
<sladen> Niraj_: in theory, just apt-get install anything you want
<sladen> Niraj_: however, are you saying this is /not/ the case, or that you have a bug?
<sladen> Niraj_: what is it that you've tried... or which is not working;  can you describe it
<Niraj_> synaptic removes original package when trying to install i386 version. I guess two conflict with each other
<sladen> Niraj_: which package are you trying to install?
<Niraj_> zlib perticularly
<Niraj_> but i guess many other conflict
<sladen> on my install I have   zlib1g  and  zlib1g:i386  installed
<sladen> what command(s) are you typing exactly?
<Niraj_> I am using synaptic
<sladen> in Synaptic what /exactly/ are you clicking/selecting (and what are you doing to choose/request the :i386 version?
<Niraj_> just  a correction, it is zlib-i386-dev
<Niraj_> which probably conflicts with zlib-dev
<Niraj_> and zlib-386-dev does say that it conflicts with 64 counterpart
<Niraj_> so rephrasing original question, is it possible for dev pkgs to coexist?
<sladen> that makes sense, as they'd both want to install  /usr/include/zlib.h
<Niraj_> hmm
<Niraj_> do these headers differ?
<sladen> no
<Niraj_> so installing 386-dev shouldnt be a prob overall, even if it removes few 64bit pkgs
<Niraj_> is it correct?
<ESphynx> Niraj_: should not be :)
<sladen> http://wiki.debian.org/Multiarch/Implementation#Why_update_your_library_package_for_multiarch_support.3F
<Niraj_> ESphynx: glad you are still here
<Niraj_> setting ecere dev env is tricky
<ESphynx> still here :P
<Niraj_> :)
<ESphynx> oh don't hesitate to ping me Niraj_ :)
<sladen> Niraj_: if I understand correctly, you're wanting to crossbuild i386 packages on an amd64 install?
<Niraj_> thanks. and thanks sladen
<Niraj_> kind of. ecere only supports i386 as of now
<sladen> Niraj_: I can't find reference to "zlib-i386-dev".  what happens if you simply do   sudo apt-get install zlib1g-dev:i386  ?
<Niraj_> it uninstalls lot of libraries including zlib-dev
<ESphynx> There's lib32z1-dev too :P
<ESphynx> seriously. what a mess the multilib :P
<sladen> AFAICT lib32z1-dev is legacy mess from before multiarch fixed it all
<sladen> Niraj_: could you stick the result of   sudo apt-get install sudo apt-get install zlib1g-dev:i386   into a pastebin
<ESphynx> right. but somehow either it's required or I carried it on from that mess :P
<sladen> ESphynx: I think it's a leftover.  However it would be good to check with Broonie
<ESphynx> I'm working on native 64 bit support in Ecere now :P Should be there in time for the Raring feature freeze :P
<Niraj_> I've already installed zlib-386-dev
<Niraj_> will see if can get anything which removes large no of other pkgs
<Niraj_> I had one which even removed gcc
<Niraj_> :D
<sladen> Niraj_: so, did we get anywhere with a pastebin?
<Niraj_> its actually installed and done the damage
<Niraj_> is it possible to revert the actions?
<ESphynx> Niraj_: I think it's fine... when you install the 64bit version of zlib, it's going to fix everything
<ESphynx> it's just you can only have either the 32 or 64 bit version of some libraries symlinks at one time
<ESphynx> but that's only for dev purposes... the real runtime library is still there
<ESphynx> (again I don't understand the logic behind this... I thoguht you could have /usr/lib/i386-gnu-linux/libz.so and /usr/lib/x86_64-gnu-linux/libz.so JUST FINE
<sladen> yes, and then a crossplatform header
<sladen> and documentation
<Niraj_> still it leaves a doubt why gcc was removed
 * sladen too
<sladen> so, what's a pastebin of  sudo apt-get install zlib1g-dev:am64 ?
<Niraj_> and gcc symlink also did not exist
<ESphynx> Niraj_: I don't think gcc was removed?
<ESphynx> gcc --version ?
<Niraj_> 4.6
<Niraj_> it was
<ESphynx> no longer there?
<Niraj_> pretty sure
<Niraj_> reinstalled
<Niraj_> didn't give any conflict though
<sladen> so likely something else
<sladen> ESphynx: anyway, so out of interest, why is it currently 32-bit?
<sladen> ESphynx: is it a check that is being made
<sladen> ESphynx: or is there some reason it won't compile on amd64?
<ESphynx> sladen: because I'm not finished with my work on 64 bit support
<ESphynx> it's mainly about the compiler support for 64 bit
<sladen> ah, so ecere contains a compliler, and it is that compiler that was the lacking support
<Niraj_> sladen: this is a bit interesting
<Niraj_> installing libpng-386-dev
<Niraj_> removes libfontconfig-dev
<Niraj_> libfreetype6-dev
<Niraj_> and libpng-dev
<ESphynx> sladen yes, well the compiler and the runtime library as well... but since it's written in eC, I have to fix the eC compiler first :P
<ESphynx> making good progress btw, I got Hello world running :P
<sladen> libpng-dev:i386 ?  or libpng-386-dev (I can't find any references to the latter)
<Niraj_> :i386
<Niraj_> sry for wrong names
<sladen> riiight
<sladen> okay, so installing libpng-dev of one arch is causing something much lower of the other arch to be uninstalled
<ESphynx> yes it does. it's quite annoying.
<Niraj_> sometimes upto gcc
<Niraj_> :)
<Niraj_> I guess it was libjpeg for 386
 * sladen tries   sudo apt-get install --no-install-recommends libjpeg-dev:i386   but doesn't see any removals offered
<Niraj_> maybe a stupid question, but does it somehow differ distrowise? I am on oneiric
 * sladen on 12.04.1 LTS  (precise)
<ESphynx> Niraj_ it surely does
<sladen> IIRC, 12.04 is when the Multiarch stuff got to the point of working
<sladen> so multiarch/crossbuilding before then is likely to be painful
<ESphynx> sladen: I actually found it more painful after it was 'fixed' :P
<sladen> ESphynx: I think this applies to alot of stuff;  ACPI, UEFI, ... but there are two choices, make it work, or ignore it.  After a while it becomes hard to eg. boot a new machine without ACPI;  or soon-to-be, UEFI
<ESphynx> hehe yes :P
<Niraj_> one unrelated question, but has anyone filed a bug relating to playing song on movie player leads to improper shutdown?
<Niraj_> thanks sladen and ESphynx, all 386 working fine now
<Niraj_> ecere building for me
<kyleN> Hi folks. I just noticed that the fossology package stopped being available in universe as of quantal.
<kyleN> I use the fossology package so this is a loss. is there a way to get this picked up again?
<micahg> Deleted in quantal-release (Reason: (From Debian) RoQA; unmaintained, RC buggy; Debian bug #6...)
<ubottu> Error: Debian bug 6 could not be found
<micahg> kyleN: You can certainly pick it up, I see there's a new upstream release, it needs someone to maintain it though
<micahg> kyleN: http://wiki.debian.org/DebianMentorsFaq#Packaging
<kyleN> micahg, short of my becoming a motu and etc, is there a more standard/quicker way? this package was always present in the past and now is not.
<micahg> kyleN: no need to become a MOTU, there's Debian mentors to sponsor stuff for people who can't upload, but there needs to be someone who's interested in maintaining the package going forward, ideally through Debian
<kyleN> micahg, so asking innocently, who used to handle this pkg and what happened to that person? :)
<micahg> kyleN: they became inactive in Debian, and the package was subsequently orphaned and removed since no one cared to maintain it
<kyleN> ah :)
<micahg> it looks interesting
 * micahg wonders why we don't use it for something like lintian checks
<kyleN> i use it to scan debian/copyright files to find asserted licenses, and fall back to a dep5 parser for dep5 formatted copyright files
<kyleN> my getlicenses package is a front end for all that: https://launchpad.net/~getlicenses-team/+archive/ppa
<kyleN> micahg, thx for the info. I'll consider next steps.
<micahg> kyleN: we're happy to help with questions here as well
<kyleN> ack
#ubuntu-motu 2013-02-07
<dholbach> good morning
<geser> good morning
<tumbleweed> has anyone else seen a spate of random people going through LP bugs removing swearing
 * tumbleweed wonders why they think it's worth the effort
 * ScottK has seen people go through and set severities on piles of fix released bugs.  Gave up wondering about such things after that.
 * ScottK suspect that there are people who view the point of bug triage to have a well curated tracker and not just about getting stuff fixed.
<tumbleweed> this effort seems to be combined with status-changing, so I'm also looking for someone running such a project, so I can shout at them
<Laney> O powerpc, whyfor are you so far behind?
<tumbleweed> it's just how things always are
<Laney> we need FOUR buildds!
<psusi> what was the bloody setting to make bzr stop unapplying quilt patches every damn time you turn around?
<ESphynx> xnox: are you around
<ESphynx> I got tons of emails to go through lol
<ESphynx> I was going to do package this giant SRU today as a debdiff
<xnox> well. where is that debdiff?
<xnox> =P
<ESphynx> xnox: it's not done yet :P there's a bzr branch
<ESphynx> I have to figure out how to get diff to generate a p1
<ESphynx> get git*
<xnox> git format-patch head^^..
<xnox> should give you p1 patches.
<ESphynx> xnox: you around for a bit? i'll give this a try now
<ESphynx> git format-patch 0.44.01.. =)
<ESphynx> This created all separate .patch files :)
<ESphynx> now should I name each according to the bug #
<ESphynx> arg :| a patch is failing :|
<ESphynx> how can that be :P
<ESphynx> Hmm, I tried to apply all the patches manually, one by one... And I get 'patching' and 'Hunk succeeded' messages only
<ESphynx> how does debuild apply patches? :|
<Unit193> ESphynx: At offset belh messages?  debuild doesn't allow fuzzing.  (Might already know.)
<ESphynx> Unit193 there are some that says offset bleh
<Unit193> Those will fail, debuild doesn't permit that.
<ESphynx> ok. I get it.
<ESphynx> I have an extra commit in the branch that I did not use the patch for
<ESphynx> So I have to regenerate it without?
<Unit193> You can patch it with fuzzing, then use dpkg-source to create the patch if you wanted.
<ESphynx> but it's 14 separate patches
<ESphynx> So I'm guessing I'll have to do it all over again :P bleh
<ESphynx> thanks Unit193!
<Unit193> Sure thing, hope it helps.
<ESphynx> it sure does
<ESphynx> ok, that worked
<ESphynx> So I got the new debian dir :)
<ESphynx> with the patches in place...
<ESphynx> now I just need to create the debdiff :P
<Rhonda> 18:37 <buxy> Does anyone know where the code that returns http://mirrors.ubuntu.com/mirrors.txt is ?
<ESphynx> debdiff <oldpackage>.dsc <newpackage>.dsc > package.debdiff    I assume?
<ESphynx> Now why the heck does 'unapplying' fail? dpkg-source: error: LC_ALL=C patch -R -t -N -p1 -u -V never -g0 -E --no-backup-if-mismatch < ecere-sdk-0.44.01/debian/patches/1107801-The.Ecere.SDK.fails.to.build.on.ARM.patch gave error exit status 1
<ESphynx> if patching succeeded...
<Unit193> ESphynx: Wonderful!
<ESphynx> Unit193 ain't it!
<ESphynx> Unit193: any more lifesaving clue for me? :P
<Unit193> First thought was wrong order, but what's it show the offset as when you manually run it?
<Unit193> (And, I'd also wait for a smart person to show up. ;) )
<ESphynx> Unit193: well how could it be wrong order! I mean debuild applied them fine in the 'forward' order
<ESphynx> This is happening after the patching succeeded, the build succeeded...
<ESphynx> When it's trying to unapply the patches
<ESphynx> got it... it's a file the build process modified :S
<Unit193> Hah, niiice.
<ESphynx> a generated .pot file (translation template)
<alo21> cjohnston, here I am....
 * cjwatson is not cjohnston
<cjwatson> just say what you want instead of all this messing around on multiple channels :)
<alo21> I would like to know if you will upgrade cdrom-checker. If not, can I take care of its merging?
<alo21> https://merges.ubuntu.com/main.html
<cjwatson> I will upgrade it and I actively prefer non-installer developers not to do it
<alo21> cjohnston, sorry... wrong nick
<cjwatson> In any case all the changes there were mine and they aren't urgent at all
<alo21> OK... anyway ignore my mail I sent to you about this. Thanks
<cjwatson> prefer> because I manage that package in bzr and it's far easier to just do the merge than to review somebody else's :)
<alo21> right
<cjwatson> merges aren't actually a great target for developers looking to build experience, IMO
<cjwatson> but I seem to have lost the argument on this generally
<cjwatson> anyway, doing now, thanks for the note
<ESphynx> xnox: I did it! I got a .debdiff! \o/
<ESphynx> attached to the main bug (uninstallable on amd64)
#ubuntu-motu 2013-02-08
<dholbach> good morning
<geser> good morning
<Rhonda> *tap tap tap*
<Rhonda> â¦ finally trying to upload to my ppa again. Let's see how many tries I need this time. ;)
<geser> how many tries did you need last time?
<Rhonda> No clue - too long ago (a year it seems), so that's why I fear to fumble. :)
<Rhonda> Accepted:
 * Rhonda blinks.
<Rhonda> uhm
<Rhonda>  Currently building on wani03 (arm ppa builder) Cancel build
<Rhonda> Architecture:
<Rhonda> i386
<Rhonda> â¦ how does that match?
<Rhonda> i386 ppas get built on arm?
<StevenK> Rhonda: They do not.
<StevenK> The ARM builders are virtualized, so we can flip them between whatever we want
<Rhonda> It just confused me. :)
<StevenK> Like that's hard. :-)
<Rhonda> pah :)
<Rhonda> Why doesn't wiki.ubuntu.com/PPA #redirect to the proper page?  â¦ and, while we are at it, what page would that be? ;)
<tumbleweed> Rhonda: I'd say https://help.launchpad.net/Packaging/PPA
<StevenK> Rhonda: Because PPAs are a Launchpad thing, and not an Ubuntu thing?
<tumbleweed> well, they are an Ubuntu-thing that's outside Ubuntu
<tumbleweed> it's hard to say they aren't an Ubuntu thing, when they fit on the Ubuntu archive, not any other distro
<Rhonda> StevenK: And Launchpad is not an Ubuntu thing?
<tumbleweed> it isn't
<Rhonda> So why is it used for Ubuntu then? :)
<Niraj_> hi, I have a small bash patch that'll search for commands on up-down arrow key. an extension to 'history-search-forward' and 'history-search-backward'. Does anyone think it might be useful?
<Rhonda> tumbleweed: <nitpick>So you say all the bugs in Ubuntu are not an Ubuntu thing</nitpick>
<tumbleweed> Rhonda: launchpad.net/ubuntu, that's Ubuntu
<tumbleweed> launchpad.net/foo isn't
<Rhonda> Right, but you didn't specify that.  Launchpad is pretty much an Ubuntu thing.  The majority of it is.
<tumbleweed> yes, built for Ubuntu
<tumbleweed> but there are upstreams, downstreams, and unrelated projects on it
<Rhonda> I know, it was built to be open, part of the original design already.
<tumbleweed> yeah
<Rhonda> And especially, PPAs are tight to Ubuntu releases and not open to other distributions (which was requested and rejected, if you remember the discussions, StevenK), so stating that PPAs aren't an Ubuntu thing but a Launchpad thing is all but a nitpick and itches me a bit.
<maxb> PPAs are a service provided by Launchpad that just happens to only be targetted at Ubuntu
<maxb> Hence they're more Launchpaddy than Ubuntuy
<Rhonda> huh
<Rhonda> syncpackage asks me for a password for a new keyring?  That's new to me.
<tumbleweed> that's python-keyring
<tumbleweed> it was using python-crypto insecurely
<Rhonda> So what is that used for?
<Rhonda> And when/where will I need the password again?
<tumbleweed> storing your launchpad oauth tokens
<tumbleweed> next time you run it, I guess
<tumbleweed> it uses gnome-keyring / kwallet, if available
<tumbleweed> but clearly they aren't
<arand> Does anyone have any clue as to why apps.ubuntu.com would differ from the actual state of packages, as per comments on http://askubuntu.com/questions/252546/install-gnome-onscreen-keyboard-gok-in-ubuntu-12-04 ?
<pipedream> apt-cache show gok
<pipedream> N: Can't select versions from package 'gok' as it is purely virtual
<pipedream> N: No packages found
<pipedream> apt-cache show gdm|grep gok
<pipedream> Suggests: libpam-gnome-keyring, locales, uswsusp, gnome-power-manager, gnome-mag, gnome-orca, gok
<xnox> ESphynx: ok. i'll peak at it.
<arand> pipedream: Hmm, I thought virtual packages only really existed when they were provided by something?
<pipedream> yes, weird, I think something is wrong there
<arand> apt-cache showpkg gok  gives me gdm3 and education-desktop-gnome on Debian here, but no reverse provides...
<Rhonda> Wow, the amd64 build queue seems to be looong.
<Rhonda> Are there any troubles with those?
<Laney> you can see that?
<Laney> I get forbidden
<Rhonda> Laney: Whom do you ask?
<Laney> Rhonda: https://launchpad.net/builders
<Laney> that's where you see the build queues - what are you looking at?
<xnox> I'm currently Not allowed there.
<Rhonda> Laney: https://launchpad.net/~rhonda/+archive/pgadmin3/+build/4284748
<Rhonda> "Startsin 9 hours"
<Laney> oh, a PPA
<xnox> Private recipes are triggering /builders not be accessible =(
<Laney> that kind of thing happens sadly
<Laney> you'll be able to see how many builds are waiting once the /builders page opens up again
<Rhonda> i386 starts more-or-less immediately, but amd64 seems to take hours before it even starts.
<xnox> Rhonda: are you after postgresql 9.2 stack?
<Laney> sometimes buildds are borrowed from amd64 to i386 for example
<Laney> or taken for various reasons
<Rhonda> xnox: wesnoth has the same delay of hours.
<Rhonda> And that doesn't B-D on pg :)
<Laney> if you need it urgently #launchpad can fiddle the relative priority
<Rhonda> No, absolutely not needed, just wondered.
<Laney> yeah, just one of those best effort things
<Rhonda> Uhm, who is responsible for screenshots.ubuntu.com?
<Rhonda> It points to a different IP than screenshots.debian.net, but it seems to be the same thing, and the /about page also reads the same.
<Rhonda> This is confusing, especially since pabs who is noted there as being maintainer of it isn't aware of it. :)
<tumbleweed> Rhonda: I'd imagine the software-centre people
<Laney> it seems to be a Canonical IP, so I suppose it's some kind of mirror / proxy
<Laney> headers imply so
 * Laney pokes broder about the lintian lab
<Rhonda> Laney: Right, haven't thought about doing a HEAD on the screenshots.u.c page.
<Rhonda> what the â¦  why would a package build on amd64 for PPA but not on i386?
<Rhonda> What detail am I missing here?
<Laney> you mean FTBFS?
<Rhonda> yep
<Laney> i386 builds arch:all
<Rhonda> â¦ just figured I guess
<Rhonda> yes, binary-indep failed on i386
<Rhonda> Thanks. :)
<ESphynx> 'morning
<ESphynx> xnox: did you get the chance to peek at that .debdiff? :)
<ESphynx> fontconfig, freetype, libjpeg, libpng, mesa-gl -- have these things been multiarched yet? They're apparently not in Quantal :|
<Laney> (quantal-amd64)root@raring:/# apt-cache show libpng12-0 | grep Multi-Arch
<Laney> Multi-Arch: same
<ESphynx> hmm talking about the dev package though
<ESphynx> it's truly annoying that installing amd64 deletes the i386 libraries even though they're located inside /usr/lib/i386-gnu-linux :S
<Rhonda> Hmm.  If I delete a package from my PPA - how long does it usually take until it is really gone?
<Rhonda> Or will I even tomorrow receive a reject mail for a fixed upload with the same version number?
<ScottK> Rhonda: IIRC you still have to you a new version.  It's like the archive in that regard.
<Rhonda> :/
<lifeless> ScottK: Rhonda: it is an archive, works the same way
#ubuntu-motu 2013-02-09
<Rhonda> ScottK, lifeless: So I wonder why it's possible to delete packages from there at all. :/
<Rhonda> Should rather be called "hide" instead of delete then.  Giving wrong impression.
<lifeless> Rhonda: it is a delete
<lifeless> Rhonda: but delete != 'forget', delete is 'free resources'
<dedunu> I want a help
<dedunu> I want to start develop ubuntu what should i do first
<Niraj_> I am no expert
<Niraj_> but ubuntu dev week had few good sessions regarding paackaging and stuff
<dedunu> I want a mentor
<Niraj_> I can give you links to IRC logs if needed
<dedunu> thanks
<dedunu> give me
<Niraj_> http://irclogs.ubuntu.com/2013/01/29/%23ubuntu-classroom.html
<Niraj_> http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html
<Niraj_> http://irclogs.ubuntu.com/2013/01/31/%23ubuntu-classroom.html
<dedunu> thanks a lot
<Niraj_> my plesure
<ESphynx> xnox: by the way, since this conflict with eclib is resolved now, any change Ecere will be in Sid now rather than Experimental? :)
<ESphynx> any chance*
<alo21> hi everybody. I am trying to merge dovecot, and after I downloaded all the files with grab-merge, I applied the patches with quilt push -a. I got an error which says that a parch could not be applied because it did't find the file to patch. What should I do?
<ESphynx> xnox: config.guess & .sub are out of date in the upstream tarball -- This is in the included but unused libffi package I think... Still latest version of that (3.0.11). The SDK itself doesn't use autoconf
#ubuntu-motu 2013-02-10
<ESphynx> good morning :)
<Unit193> Heya.
<LostSoul> hi everyone, Just a question.
#ubuntu-motu 2014-02-03
* pratchett.freenode.net changed the topic of #ubuntu-motu to: Saucy released! | 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.html | http://qa.ubuntuwire.com/bugs/rcbugs
<psusi> I'm trying to update a package to a new upstream and convert it from 1.0 to 3.0 (quilt) in the process and debuild is complaining about upstream sources being changed due to autoconf... how to beat it into submission?
<Rhonda> Now that's an interesting translation â¦
<Rhonda> "Ihre Seite war abgestanden."
<Rhonda> I can just assume the original reads something like obsolete or such?
<jtaylor> expired probably
<Rhonda> I get that from login.launchpad.net
<Rhonda> I guess others are able to login to launchpad?
<jtaylor> hm don't want to log out just to see it fails for me to ;)
<Rhonda> :)
<Logan_> psusi: dpkg-source --commit to turn the local changes into a patch
<Logan_> and then maybe just delete the patch and run dh_autoreconf in debian/rules instead
<Noskcaj> Where should i upload gnome-photos and gnome-weather, since ubuntu-gnome needs them and debian won't have them in time for the DI freeze
<Noskcaj> (gnome-weather has a license issue for debian too)
<michagogo|cloud> Noskcaj: IIRC you can request a sync from Debian after DIF
<michagogo|cloud> That date is just when it stops being automatic
<Logan_> michagogo|cloud: That's correct.
#ubuntu-motu 2014-02-04
<ESphynx> http://askubuntu.com/questions/411398/dpkg-source-error-cant-build-with-source-format-3-0-native-native-package  --> I'm getting that same issue now on Trusty, any clue?
<ESphynx> just need to fix 3.0 (quilt) -> 3.0 (native) is it?
<geser> ESphynx: do you have a native or non-native package format?
<ESphynx> geser: what's a native package format?
<geser> non-native: .orig.tar.xz (or otherwise compressed) + .debian.tar.xz ; native: only one .tar.xz
<ESphynx> geser: https://github.com/ecere/ecere-sdk/tree/ppa/precise/debian  This is my package there for that Ubuntu PPA
<ESphynx> It's a launchpad PPA
<ESphynx> This is the recipe: https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-precise
<geser> as you specified "3.0 (native)" in your debian/format you need a package version without a revision (trusty's dpkg enforced it; see Debian bug #700177)
<ubottu> Debian bug 700177 in dpkg-dev "dpkg-dev: please reject native/non-native version when building native/non-native source packages" [Wishlist,Fixed] http://bugs.debian.org/700177
<ESphynx> geser: I had 'quilt' there, I just change it to native
<geser> did you get the same error with quilt?
<ESphynx> I was getting the error with quilt, I thought I had to change it to native to fix it.
<ESphynx> as per https://code.google.com/p/pymds/issues/detail?id=1
<geser> as I didn't work with recipes yes, I'm not sure if recipes work with "3.0 (quilt)"
<ESphynx> i was getting the error with quilt
<geser> then you need a version without the "-", something like "{time}+0~{revno}" should hopefully work
<ESphynx> well I'll wait for this built to try to see if changing to native should work?
<ESphynx> if quilt didn't work native should, right? :P
<geser> you need probably both changes
<ESphynx> I'll try that next, then :P
<ESphynx> thanks!
<geser> "3.0 (quilt)" and a version with a revision (contains a "-") or "3.0 (native)" without a revision (contains no "-")
<geser> I guess the recipe documentation should get updated for this
<geser> wgrant: ^^
<ESphynx> geser: So how could I get that thing to build without changing the version format?
<geser> for trusty? I guess not at all as dpkg won't accept "3.0 (native)" with a non-native version anymore
<ESphynx> geser: I read something about a pristine tarball or something, looks complicated to set up though :P
<ESphynx> So I just went with your suggestion of s/-/+
<ESphynx> also reverted by quilt->native
<ESphynx> xnox: ping :P
<xnox> ESphynx: hey!
<ESphynx> xnox: Hey can you help me out this time? ;)
<ESphynx> I just realized the Debian import freeze is in 2 days ;P
<xnox> ESphynx: yeah, and so is e.g. 12.04.4 point release.
<ESphynx> And Tahr is an LTS I'd really like to make it...
<ESphynx> http://ecere.com/mantis/roadmap_page.php --> we got 18 issues I want to fix for ecere-sdk 0.44.10
<ESphynx> 12.04.4 point release?
<ESphynx> point releases now eh
<xnox> ESphynx: LTS always had point releases. Yeah, it's just something I'm involved in at the moment.
<ESphynx> ah cool
<ESphynx> xnox: Do you think you can help us out?
<xnox> ESphynx: i can sponsor a package if you have one ready.
<ESphynx> I don't have one ready right now, I have to fix those 18 issues ;P
<xnox> ESphynx: i'm not going to code ecere ;-)
<ESphynx> xnox: I mean if I get you a package in 2 days
<ESphynx> can you swiftly sponsor it? ;)
<xnox> ESphynx: well, less chatting & more coding ;-)
<ESphynx> because the last 2 tiemes it rotted on debian.mentors till it got dropped :P
<ESphynx> and I'd like to coordinate with you the time ;) do I have 2 days to get it ready?
<xnox> ESphynx: we can wiggle that, just get it working.
<ESphynx> cool! thanks. Yeah we're release-crunching on these remaining issues now. This is the all issues ironed out 64 bit release.
<geser> ESphynx: on DIF only the automatic import from Debian stops, you still have time till Feature Freeze to get it synced from Debian manually or get an upload sponsored
<ESphynx> geser: Yeah, I know... Thanks for clarifying that :) better play it safe though :)
<ESphynx> I'm giving us 2 days to get those issues out of the way :)
<Rhonda> Laney â¦  do you know what it would take to create a launchpad "project" for the packages.ubuntu.com website?
<Rhonda> I would like to direct people there, especially in the light of wearing out discussion with the reporter of #1275506
<Rhonda> And I don't get the reasoning of "the codename is only valid for the development cycle".
<Laney> Rhonda: You can make it on the homepage of launchpad.net
<Rhonda> Of *course* it is valid all together, otherwise the sources.list wouldn't work.
<Laney> Maybe you want a 'team' to own it so it's not just you
<Laney> in which case create that first
<Rhonda> Yes, that would be great.
<Laney> ah, then you can take your email address off the page
<Laney> and just direct people to LP
<Rhonda> I like it that you think along. ;)
<Rhonda> aaaahyes
<Rhonda> "You must specify a default renewal period from 1 to 3650 days." - why does it say (optional) next to it then.  >.>
<Rhonda> So how to create project under the team umbrella?
<Laney> I guess it means that expiry is optional
<Laney> you make the project and then can somewhere set the owner and stuff
<Laney> I can't remember exactly how
<ESphynx> does anyone know what happened to freetype/ttunpat.h ? where would be better place to ask , #freetype is invite only :\
<Rhonda> Laney: ah, found it, thanks! :)
<Rhonda> "pkg-website doesn't use Launchpad to track its bugs."
<Laney> you can turn it on somewhere
<Rhonda> Hmm, now I just need to figure out how to tell launchpad that it actually does. :)
<Rhonda> found it :)
<Rhonda> What does "Import a branch hosted somewhere else" actually do?
<Rhonda> Does it really import it and make it appear like it's maintained in launchpad/bazaar, or will it just link?
<Laney> it'll try and import it
<Rhonda> duh, I'll try to remove it again, that's not what I wanted.  %-/
<Blueink_> !ops
<ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds!
<Blueink_> !staff
<ubottu> Hey christel, Corey, Dave2, Gary, Myrtti, Pricey, VorTechS, jayne, marienz, niko, nhandler, tomaw, ldunn, I could use a bit of your time :)
<jpds> Hi.
<Blueink_> !ops | Repent
<ubottu> Repent: Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds!
#ubuntu-motu 2014-02-05
<Noskcaj> Logan_, any chance you could review something for me?
<Noskcaj> lp:~noskcaj/+junk/gnome-weather
<Noskcaj> It's needed for ubuntu-gnome
<Logan_> Noskcaj: why not Debian?
<Noskcaj> Logan_, Debian won't take stuff with CC-BY-2.0 licenses
<Logan_> Noskcaj: what have other MOTUs' responses been?
<Logan_> and can I see the discussion in Debian about the license?
<Logan_> since it seems to be maintained in a Debian repository
<Noskcaj> I've not contacted other MOTUs yet, but debian and the ubuntu-gnome head dev suggested this way/
<Logan_> hmm
<Noskcaj> https://bugzilla.gnome.org/show_bug.cgi?id=703150 is upstream bug
<ubottu> Gnome bug 703150 in general "Please relicense art to CC-BY-SA 3.0" [Normal,Unconfirmed]
<Noskcaj> Could someone please review lp:~noskcaj/+junk/gnome-weather
<darkxst> anyone able to upload lp:~noskcaj/+junk/gnome-weather to trusty NEW?
<darkxst> its a sync from debian SVN, but can't go into debian due to CC-BY licensed artwork
<geser> does Ubuntu accept this license?
<geser> any reason why you didn't preserve the debian changelog? (or didn't exist any?)
<darkxst> geser, plenty of CC-BY stuff in ubuntu
<darkxst> there was a changelog for 3.8, no idea why Noskcaj didnt include that
<darkxst> http://anonscm.debian.org/viewvc/pkg-gnome/packages/experimental/gnome-weather/debian/changelog?view=co
<mitya57> darkxst: plenty of CC-BY *2.0* licensed stuff?
 * mitya57 wonders if optimization done by pkgbinarymangler is a derived/collective work
<darkxst> mitya57, ok, don't know about plenty, but have definitely seen some in universe
<mitya57> Can that artwork be just patched out?
<darkxst> mitya57, its weather icons, app is nothing without them!
<mitya57> OK, as a short term solution I think it's fine to have these in Ubuntu.
<mitya57> I will maybe upload it in the evening, if noone else does that before me.
<mitya57> By the way you really should use the sponsoring queue :)
<darkxst> mitya57, I only have really limited upload rights, just desktop-extras
<mitya57> But you still can file a bug and subscribe ubuntu-sponsors...
<darkxst> where exactly would one file a bug on a non-existent package though?
<mitya57> Against "ubuntu" project.
<darkxst> ok
<geser> darkxst: against Ubuntu, like all the RFP lingering there
<mitya57> Noskcaj, darkxst: uploaded
<ESphynx> hey guys, is there a way by now to mark a build-dependency as optional?
<jtaylor> you shouldn'T do that
<jtaylor> builds should be reproducable, optional dependencies would negate that
<ESphynx> in an ideal world upx-ucl would be available on arm and not break my builds :P
<jtaylor> it is only used for bootstraping for staged builds
<ESphynx> jtaylor: I would like optiona if it exists at all on the platform.
<jtaylor> you can remove arches from build depends
<jtaylor> [!arch]
<ESphynx> but gotta do that one by one and that's annoying as heck
<jtaylor> you can also list the ones it works on I think
<ESphynx> so how would I add that
<ESphynx> upx-ucl [!ppc64el] [!arm64],   ?
<jtaylor> if it never built on an arch just don'T care
<jtaylor> it doesn'T harm migration
<jtaylor> [!ppc64el !arm64] I think
<ESphynx> it built before on arm64 and on powerpc
<jtaylor> see gcc source that should have a few examples
<ESphynx> not sure how ppc64el is related
<ESphynx> ah, no it never built on arm64 that's new
<ESphynx> still, I'd like the opportunity to have the build attempted so I can fix any problems
<ESphynx> our project is a cross-platform SDK after all so it has to be as portable as possible ;)
<ESphynx> thanks jtaylor :P
#ubuntu-motu 2014-02-06
<michagogo|cloud> cjwatson: Okay, I read the guide
<michagogo|cloud> It's a bit too much information -- I
<michagogo|cloud> 'm kinda confused
<michagogo|cloud> Especially because a lot of it isn't relevant
<michagogo|cloud> :-/
#ubuntu-motu 2014-02-07
<sassyn> hi akk
<sassyn> all
<sassyn> *
<sassyn> I kind of lost in the last week
<sassyn> with an issue I have
<sassyn> and maybe someone can drop some light here
<sassyn> I need to back port some pkg from ubuntu 14.04 to 10.04
<sassyn> so I download the source pkg
<sassyn> the .dsc
<sassyn> and had to get some other sources from 14.04 and compile them as well
<sassyn> some of then was need to be change as they used debhelp 9 and I have only 7 install in 10.04
<sassyn> so at the end i manage to compile all pkg needed
<sassyn> and got them install
<sassyn> but know i want to do the same fro 10.10
<sassyn> 11.04 etc..
<sassyn> so i used pbuilder
<sassyn> which took me like 3 days just to understand
<sassyn> how to work with this
<sassyn> and I know in a point where I have 12.04 install
<sassyn> with pbuilder
<sassyn> with image of 10.04 as base
<sassyn> with local repo
<sassyn> so when trying to do build for the source pkg from 14.04 i was thinking it will do it auto
<sassyn> if some pkg will be missing
<sassyn> i will do the same as i did with 10.04
<sassyn> upload to my local repo
<sassyn> and try again
<sassyn> but as it seems to me i
<sassyn> doing something wrong
<cjwatson> michagogo|cloud: Sorry - my only suggestion at this point is that you find somebody who already knows how to package and can do it for you, then.  I'm afraid I don't have time to help
<quidnunc> Is anyone on 13.04 and can confirm that uuid-dev is uninstallable?
<teward> quidnunc: if you give me two minutes i can check in my 13.04 VM
<quidnunc> teward: I would appreciate it
 * teward is in the middle of diagnosing an sbuild chroot problem with his chroots
<teward> !13.04
<ubottu> Ubuntu 13.04 (Raring Ringtail) was the 18th release of Ubuntu. Support ended on January 27, 2014. See !eol, !upgrade and http://ubottu.com/y/raring
<teward> quidnunc: actually, you know what...
<teward> raring is EOL
<teward> so why do you want to check an EOL release's installation stuff
<quidnunc> teward: I'm still running it
<quidnunc> teward: because I depend on docker I don't think they support anything later
<quidnunc> (and I don't think)*
<teward> first of all, i see several issues with that line of thinking, because 13.04 won't be getting any updates ever, so you're opening yourself to new security risks
<teward> secondly, mind pastebinning or sharing your "can't install" errors?
<quidnunc> So it looks like 13.10 is supported now.
<quidnunc> by docker
<quidnunc> So I guess I'll upgrade
<quidnunc>  uuid-dev : Depends: libuuid1 (= 2.20.1-5.1ubuntu8) but 2.20.1-5.1ubuntu8.1 is to be installed
<teward> that means that uuid-dev has an incorrect depends line
<teward> but as it's in 13.04 that can't be fixed
<quidnunc> teward: I know. Is it just me
<teward> s/can't/won't/
<quidnunc> teward: Alright.
<teward> quidnunc: i doubt it, if 2.20.1-5.1ubuntu8.1 is libuuid1's version in 13.04 then that applies everywhere
<quidnunc> docker supports 13.10 now so it's safe to upgrade
<teward> (because that's an ubuntu revision number)
<quidnunc> teward: There are many reasons why it could just be me: stale package list is one
<teward> possibly (sudo apt-get update)
<teward> quidnunc: i'm willing to test assuming that i can get my VM to launch
<teward> i may have to rebuild it
<teward> (but again, as 13.04 is End of Life, this error won't be fixed anywhere except locally)
<quidnunc> teward: Never mind, I'll upgrade and try with saucy
<teward> awww, but i'm bored :P  this would've given me something to do
<teward> oh well
 * teward goes back to trying to fix his sbuild chroots
<teward> quidnunc: also, btw, i can't confirm your error, it looks like stale package info on your end really
<teward> (even if 13.04 wasn't EOL, this is still just an error of stale data on your end)
<quidnunc> teward: That's what I wanted to know, thanks :)
<quidnunc> teward: What could be the cause? I did apt-get upgrade. I'm using archive.ubuntu.org
<quidnunc> s/upgrade/update
<teward> quidnunc: no idea, but as I said, 13.04 is EOL, so it's irrelevant
<teward> and because you said this program you want supports 13.10 now, so...
<quidnunc> teward: Somewhat relevant to me: It's going to take several hours to upgrade
<teward> well, i'm not sure what the cause is... works fine here.  do you have some weird setup where you don't use -updates or something?
<quidnunc> teward: No, it's there
<quidnunc> teward: what version numbers do you have
<quidnunc> ?
<teward> quidnunc: i already shut down the VM
<quidnunc> for libuuid1
<teward> you'll have to wait a minute
<quidnunc> teward: Okay, not important
 * teward is in the middle of updating things
<teward> nah i can load it in a minute
<teward> quidnunc: oops i made a fail
<teward> i didn't update it's package data from rebuild
<teward> give me another minute
<teward> quidnunc: do you have any weird PPAs, or the proposed repo enabled, or backports?
<teward> because stock 13.04 has just libuuid1 2.20.1-5.1ubuntu8
<teward> with just raring, raring-security, and raring-updates enabled
<quidnunc> teward: raring-proposed
<quidnunc> that's the problem
<teward> yeah that is the issue
<teward> quidnunc: you probably should not just blindly enable proposed, and should pin it and then only install what you need from proposed
<quidnunc> teward: It actually is pinned, -120. I don't know how it got installed
<teward> https://wiki.ubuntu.com/Testing/EnableProposed is usually what I use to pin proposed
<teward> IDK then, but meh
<quidnunc> teward: Thanks. I wouldn't have found the problem without your help
<teward> you're welcome
<teward> sorry if i seem grumpy, sbuild's having issues today >.>
<teward> (all day long today too)
<quidnunc> teward: You have my sympathy. I'm struggling with a string of really stupid problems today too
#ubuntu-motu 2014-02-08
<ESphynx> hey guys... I'm running on up to date Saucy right now, and I keep making the gtk-window-decorator crash
<ESphynx>  Gdk-CRITICAL **: IA__gdk_drawable_get_depth: assertion 'GDK_IS_DRAWABLE (drawable)' failed
<ESphynx> I would like to figure out whether my Ecere toolkit is doing anything bad, or it's just a bad unfixed bug  in GTK?
<ESphynx> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1266572 -- Well :)
<ubottu> Launchpad bug 1266572 in compiz (Ubuntu) "gtk-window-decorator crashes randomly" [Undecided,New]
<ESphynx> I don't even get an option to file a bug though when that happens?
<ESphynx> Woah... this is pretty bad. I just go 'gdb gtk-window-decorator' , run, and I get the crash right away
<fully_human> Hello. I'm applying my first bug fix for Ubuntu Bug Week. In the changelog should I add (LP: ...) or (Closes: ...)?
<cjwatson> (LP: #nnnnnn) is the syntax to close an Ubuntu bug
<cjwatson> (closes: #nnnnnn) is the syntax to close a Debian bug (when uploading to Debian)
<fully_human> Ah, thanks.
<cjwatson> The latter already existed and we didn't want to introduce ambiguity by reusing it with a different bug number namespace
<fully_human> Yeah, I saw the note in the docs that Closes is for debian, but I didn't know if that meant debian-ish (the docs sometimes do).
<fully_human> What does "bzr bd -- -S" mean when it complains "dpkg-source: error: aborting due to unexpected upstream changes"? It refers me to a file that complains about my changelog message.
<fully_human> I'll pastebin the changelog in a bit.
<cjwatson> That suggests you've put your changelog message in the wrong place.  It should be in debian/changelog, and dpkg-source won't consider things under debian/ to be "upstream".
<cjwatson> Unless I'm misunderstanding.
<fully_human> It is in debian/changelog.
<cjwatson> Then I doubt it's actually *complaining* about your changelog message as such; that is, that isn't the error.
<cjwatson> The majority of packages require that patches to upstream source be kept in debian/patches/
<fully_human> The build failed, though.
<cjwatson> If debian/source/format says "3.0 (quilt)" (which is the most common case nowadays), then you need to use quilt when editing upstream source
<cjwatson> And dpkg-source is probably complaining that you edited it directly instead
<cjwatson> This is so that patches are separated and easily forwardable to the upstream maintainer
<fully_human> Ah, okay, yeah, it says quilt.
<fully_human> Thanks.
<fully_human> Hm...so do I cat the output of 'quilt diff' into a file and then 'quilt add' that file? I'm sorry...the doc I'm reading (http://packaging.ubuntu.com/html/fixing-a-bug-example.html) doesn't have anything on quilt.
<cjwatson> No - /usr/share/doc/quilt/README.source has basic instructions
<cjwatson> You can also abbreviate the steps of running "quilt add FILE" then editing the file, as "quilt edit FILE"
<fully_human> So after I run quilt refresh then I run 'bzr bd -- -S'?
<cjwatson> Sounds plausible
<fully_human> Hm, I went through all the steps for quilting but when I run 'bzr bd -- -S' this is the error I get: "dpkg-source: error: cannot read inkscape-0.48.4.orig.lzzAHP/debian/patches/bug-807861-typo-in-src_widgets_toolbox_cpp: No such file or directory"
<fully_human> The bug-80.... is a new patch that I created with 'quilt new'.
<cjwatson> You might have forgotten to "bzr add" it
<cjwatson> (I tend to just use "debuild -S" personally, but "bzr bd -S" will I suppose provide a better check of whether your bzr working tree is right)
<fully_human> So I'm now trying to run pbuilder-dist on the dsc file. It's trying to install a bunch of packages but doesn't ask me for the admin password so the install fails. Any work-around? thanks.
<fully_human> This two minute bug fix is turning into a day-long project. :(
<Ampelbein> fully_human: use "sudo pbuilder-dist ...."?
<jtaylor> no pbuilder calls sudo for you
<jtaylor> can you paste a log?
<fully_human> It won't even run as root. :-\
<fully_human> pbuilder-dist: Error: You don't own $HOME
<fully_human> That's if I run it with sudo.
<fully_human> I'll run it without root now and paste the results...
#ubuntu-motu 2014-02-09
<fully_human> Sorry, I keep forgetting (and keep forgetting to bookmark) the page with the ubuntu dev releases. What is it? Thanks.
<Unit193> https://cdimage.ubuntu.com/ ?
<fully_human> Unit193, Ah, thanks!
<fully_human> Although, https:// seems to be down. :-\
<Unit193> Bah. :/  I just typed https out of habit.
<fully_human> Unit193, Good habit. :-)
<Unit193> Danke.
<ESphynx> Hey guys, is anyone maintaining GDB here? I got some non-sense going on
<ESphynx> Looks like GDB gets stuck in startup_inferior()->target_wait ()->sigsuspend() ?
<jtaylor> meh, tried to finally install trusty on my machine
<jtaylor> and guess what, it again deadlocks on detecting partitions :(
<teward> jtaylor, and?  (purely curious)
<teward> ouch
<jtaylor> its getting annoying that this reappears every cycle
<jtaylor> its not helping that the detection is so slow, you have to let it sit for 10 minutes to make sure its deadlocked and not just slow :/
<fully_human> Hello, trying to submit my first bug patch...So far I'm two days in trying to submit a two-second patch. :-\ I've finally gotten to submittodebian. I had to cancel and fix something, and now submittodebian won't work. It says "dpkg-source: error: cannot read foo/debian/patches/bar: No such file or directory" (where foo is package name and bar is my `bzr branch` name). I didn't get this error before when I was going thro
<fully_human> ugh all the steps. Is there any way to "undo" submittodebian steps?  Thanks.
<Noskcaj> fully_human, I normally just make the bug in debian via email and attach the patch, fairly simple
<teward> same here
<fully_human> Make the bug?
<fully_human> Oh, reproduce?
<teward> i think Noskcaj means file a new bug in Debian via email, if one doesn't already exist
<Noskcaj> yeah
<teward> or, email bugnumber@bugs.debian.org with a message and attach the patch as an attachment, if the bug DOES exist.
<fully_human> No, one exists. I'm just fixing it. I'm following this guide: http://packaging.ubuntu.com/html/fixing-a-bug-example.html
<teward> fully_human, do you have the Debian bug number?
<fully_human> I have the launchpad bug number. :-\
<teward> i'm confused then
<teward> you're trying to attach the patch to the LP bug?
<fully_human> Yes.
<teward> fully_human, do you have the patch on the system you're opening the bug in?
<teward> (i.e. the same system you're opening launchpad.net on)
<teward> if you do, then you can just open the bug, hit "Add attachment or patch" at the bottom of the bug
<teward> put some description in, and a title for it, and attach the file
<fully_human> teward, Ah, thanks.
<teward> fully_human, you're welcome.
<fully_human> What file extension would the patch be? (this is my first bug fix, so sorry for all the newbie questions)
<teward> fully_human, i usually use .diff or .patch or .debdiff, depending on the patch.
<teward> normally, when I patch things with JUST a patch, I also generate a debdiff, as a power user / SRUer, so mine're usually .debdiff (and the file is created in the debdiff for the patch)
<teward> but for JUST a patch or a diff, you can probably use .patch or .diff
<teward> Noskcaj might have more guidance than me on that, though.
<teward> (I also ahve to fix my debian repo system >.>)
<fully_human> I don't see any of those...I must be missing a step...Should I do `debdiff > packagename.patch`?
<teward> fully_human, how'd you create the patch?
<teward> ... oh THAT'S why my repositories are broke >.>
 * teward kicks the system around angrily
<fully_human> Actually, I might not have. Sorry for the confusion. I did `bzr branch name-of-bug`, and then `dch -i` Do have to manually create the patch file with bzr diff?
<teward> Noskcaj, ^
 * teward doesn't use bzr so can't really help there
 * fully_human considers teward blessed.
<teward> heheheheheh
<teward> nah, i just prefer making my life harder xD
<fully_human> But do I have to manually do a `bzr diff foo >> foo.patch?`
<teward> fully_human, i'll be honest, though, my job's harder, a lot of times I"m doing the opposite of what you're doing, I"m usually taking upstream diffs and applying them to the older versions in ubuntu for SRUs or security updates xD
<teward> but i'm sorry i can't give you guidance on this issue :/
 * teward disappears to reset his debian repository server
<fully_human> teward, No problem. :-)
<teward> can someone help me out with getting this bug ready for SRU by approving the nomination for Saucy?  https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1264674
<ubottu> Launchpad bug 1264674 in nginx (Ubuntu) "nginx segfault when adding add_header in configuration" [Undecided,Fix released]
<teward> (it's already fixed in Trusty, hence fix released, but it needs fixing in Saucy)
<rbasak> teward: done. Thanks!
<Noskcaj> fully_human, What was the issue you had? I was afk
<ESphynx> hey guys I'm suspecting a kernel bug preventing me to debug my apps at all on latest Saucy kernel... Is there an easy to test installing a newer kernel on Saucy? I tried adding this PPA but now I can't figure out how to install it...
<ESphynx> (Said PPA https://launchpad.net/~anton50489/+archive/test2/+build/ )
<ESphynx> Or is this http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-saucy/ what I should use
#ubuntu-motu 2015-02-02
<dholbach> good morning
<smallfoot-> Why is gnome-screensaver (3.6.1) and gnome-system-monitor (3.4.2) and gnome-system-log (3.9.90) so old? Why not 3.14?
<dholbach> smallfoot-, you can try asking in #ubuntu-desktop
<smallfoot-> thanks
<smallfoot-> It would be nice if the xwayland package were updated, because it contains a bug
<dholbach> as I said... that's more something you could ask in #ubuntu-desktop
<smallfoot-> ah, oh, that too
#ubuntu-motu 2015-02-03
<dholbach> good morning
<Laney> hey dholbach
<dholbach> hi Laney
<Laney> what's up?
<dholbach> I don't know how, but I managed to get the same cold everyone else is having in Berlin right now, so I might take a nap later on today - apart from that, things are going well - how about you?
<gweodoo> hi guys, I've uploaded a project on my ppa and now i'm trying to install on my trusty with add-apt-repository command line. But it failed with following error : "Error: signing key fingerprint does not exist". I know i missed something but i didn't found it. Thanks !
<gweodoo> I've tried to add the ppa key with apt-key and output seems to be good
<gweodoo> ok i think i've found the problem :)
#ubuntu-motu 2015-02-04
<dholbach> good morning
<Tm_T> hello
<Tm_T> I'm having a problem with one of the applications that are residing in universe
<Tm_T> anyone available to help with debugging and narrowing down the cause?
<Tm_T> Core was generated by `fwbuilder -d'.
<Tm_T> Program terminated with signal SIGSEGV, Segmentation fault.
<Tm_T> #0  data (this=0x8) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:135
<Tm_T> 135     ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h: No such file or directory.
<Tm_T> #0  data (this=0x8) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:135
<Tm_T> 135             return d;
<Unit193> Tm_T: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768816 doesn't give a backtrace, but does that happen to look about the same?  It's the same version from trusty-vivid, so I tried it here on vivid with no such luck in getting the crash.
<ubottu> Debian bug 768816 in fwbuilder "fwbuilder crashes in libqtgui" [Important,Open]
<erwan____> Hi. I'd like to add a new package to Ubuntu, but it's not open source so I just have binaries to provide. Is it possible?
<rbasak> erwan____: it may be permitted in multiverse or Debian non-free depending on the exact licensing terms. But non-free software is generally frowned upon. What is it?
<erwan____> rbasak: it is a software from IBM that I'm working on, it'll enable some DLPAR features when running on powerVM
<erwan____> rbasak: it is a part of the work related to the ppc64el architecture
<rbasak> erwan____: do you work for IBM? There's also the Canonical partner repository. Users can enable it to get software that is non-free but that Canonical ship as a service to Ubuntu users.
<rbasak> erwan____: an example is Skype.
<erwan____> rbasak: I do. This Canonical partner repository sounds good.
<Zhenech> erwan____, is ubuntu already available on ppc64el?
<rbasak> Zhenech: yes :)
<rbasak> At least we've been building for ppc64el for a number of releases now.
<rbasak> erwan____: stuff generally gets into the Canonical partner repository through a partner engagement. So this should probably be taken up with the relevant project managers. Do you know who you need to speak to at your end?
<erwan____> rbasak: I don't know
<erwan____> rbasak: I'll ask my team leader, he may has a better knowledge than me about this
<rbasak> erwan____: OK. Let me know if you have trouble making the connection.
<erwan____> rbasak: ok. Thanks.
<erwan____> rbasak: in the meantime, I wonder how it works with non-free packages, what kind of files are provided to Ubuntu since it can't be source code?
<rbasak> erwan____: AIUI, the binaries are put into the "source package", and the "build" just moves them around as needed.
<rbasak> So we still upload a source package to the archive, but it's not really source.
#ubuntu-motu 2015-02-05
<Tm_T> Unit193: ah, that might be actually the very same issue
<Unit193> So might help you then, and also you may be able to help them.
<dholbach> good morning
#ubuntu-motu 2015-02-06
<dholbach> good morning
<Unit193> Hello!
<geser> good morning
#ubuntu-motu 2015-02-08
<Brady4MVP> Is there a tool that checks and indents control files ?
<Brady4MVP> like for the Depends field ?
<Unit193> Well, for that, recommends, and build-deps there is wrap-and-sort.
<Brady4MVP> thanks
<Brady4MVP> Unit193,  that worked great Thanks !
<Brady4MVP> How do I run additional make commands ?  do I have to do this from the rules file ?  I am asking so that the docs to my lib get made ect
<Brady4MVP> project is a Qt project.  I have to package up about 7 in-house libs.  But would like to make sure that the qch docs get installed. But not sure if it has to be a multi binary package ect
<Brady4MVP> Like I do not want to use a <packagename>.docs.install as the makefiles make all that when compile.
<Unit193> Do you need to run configure multiple times as well?
<Brady4MVP> Unit193,  no just qmake once
<Brady4MVP> Unit193,   most the time when I am compiling it.  it goes like so.      qmake ; make ; make install ; make docs ; make install docs
<Brady4MVP> there are 3 rules for the docs html_docs qch_docs and docs(meta for the other two)
<Unit193> So I'd say override the dh_auto_build and dh_auto_install targets.  Do you mean  make install-docs or somesuch, too?
<Brady4MVP> make install options are :  install  || install_docs || install_inst_html_docs || install_inst_qch_docs || install_subtargets
#ubuntu-motu 2016-02-08
<dholbach> good morning
<highvoltage> a/win 10
<Fantu> hi, in nemo 2.8.6-2 the autotest should be fixed, sync from debian will be automatic?
#ubuntu-motu 2016-02-09
<dholbach> good morning
<unlaudable> morning
<unlaudable> dholbach, ... the creator of byobu?
<dholbach> no, I'm afraid not :)
<dholbach> Dustin Kirkland might be the guy you want to talk to. :)
<unlaudable> of course ... :D have my D's confused...
<ngaio> I'm a Python application developer. I've been reading the documentation on packaging a Python application for Debian & Ubuntu, as well as writing a proper setup.py. My application is written in PyQt, hosted on launchpad, and uses gettext and the launchpad translation service. I'm overwhelmed by the complex interface between the various python installers (setuptools, distlib, etc.), and what's required by distros, such as man page installation. Is there
<ngaio> an exemplary PyQt application that I can use to model my work on?
<ngaio> sorry I just had connection problems
<justin_time> Hi, I'm trying to update the tomahawk package and I'm not so familiar with the ubuntu sponsoring process. I would be really happy, if someone could help me and please check my bugreport (LP: #1487729) if this sponsoring request is correct and what I have to do next.
<ubottu> Launchpad bug 1487729 in tomahawk (Ubuntu) "Tomahawk 0.8.4 or newer [needs upgrade]" [High,In progress] https://launchpad.net/bugs/1487729
<dholbach> justin_time, looks good AFAICS
<justin_time> dholbach: ok, thanks for checking! Is there a chance that this request will be reviewed before FeatureFreeze?
<dholbach> yeah, I guess so :)
<justin_time> ok, thank you for your help!
<bregma> dholbach, what's my next step for #1541417 ?
<dholbach> I thought somebody else would take a look in the meantime....
<dholbach> looking
<teward> well
<teward> it's assigned to someone so maybe they're going to look at it?
<teward> dholbach: does the assignment there mean "that person is working on it, nobody else needs to" yet?  At least for some of the other developer process bugs i've seen, the assignee tends to indicate someone is working on it and nobody else needs to poke :)
 * teward lurks
<teward> s/yet//
 * bregma has gotten awfully rusty at Ubuntu packaging
<dholbach> teward, I don't think there's a hard and fast rule for that
<dholbach> some use it for "who's working on all the code", some use it to show "who's reviewing it now"
<teward> indeed.  i know for MIR it was used for 'who's reviewing', at least for nginx's MIR
<teward> but was curious :)
<dholbach> bregma, uploaded
<bregma> dholbach, thanks for your time
#ubuntu-motu 2016-02-10
<blippe> easymp3gain-* references mp3gain (which aint in the archives). Is this a bug? (The situation is the same in debian).
<blippe> i think mp3gain disappeared from debian when nobody wanted to maintain the package any longer. If I wanted to step up, would it be better to do so for debian or directly to ubuntu?
<blippe> gr#AO.
<dholbach> good morning
<blippe> there is something special about putting part of your password in an irc channel and then scurrying arround changing your password on laptops.
<blippe> great, according to dconf, lock-enabled and lock-delay are set to enabled and 0, and well, you saw it didn't work. :P
<simosx> Our gr.archive.ubuntu.com mirror has stopped serving over HTTP and only works with FTP. When shall we make this change?
<Pici> simosx: you may want to mention that in #ubuntu-mirrors
<simosx> Pici, thanks!
#ubuntu-motu 2016-02-11
<karstensrage> if im using sbuild where do i get the results of the stuff built
<karstensrage> it builds it in the chroot
<karstensrage> but can i get it after the sbuild?
<dholbach> good morning
<blippe> evening!
<blippe> 9NMx
#ubuntu-motu 2016-02-12
<dholbach> good morning
#ubuntu-motu 2017-02-06
<tsimonq2> mapreri: Any chance you could do me a favor and take a look at bug 1662011?
<ubottu> bug 1662011 in Ubuntu "[needs-packaging] kirigami2" [Wishlist,Confirmed] https://launchpad.net/bugs/1662011
<mapreri> tsimonq2: I'd always find nice if such things could be done in debian...
<mapreri> tsimonq2: .
<acheronuk> mapreri: thank you for that. in circumstances of more time and less freezes, I agree
<mapreri> acheronuk: you're welcome
<tsimonq2> mapreri: Kubuntu is a bit different in that we don't follow a lot of what Debian does for packaging. We merge from their packaging at the beginning of each cycle, but otherwise, that's it.
<mapreri> tsimonq2: Yes, I've got that (and mostly wonder why is it so, I don't think it needs to - except in periods like now where Debian is frozen).
<tsimonq2> mapreri: I think the root cause might be because of who has access where..
<tsimonq2> *shrug*
<acheronuk> Hi, would anyone be so kind to look at and maybe sponsor the upload for https://bugs.launchpad.net/ubuntu/+source/prison-kf5/+bug/1662191
<ubottu> Launchpad bug 1662191 in prison-kf5 (Ubuntu) "prison-kf5 needs updating to v 5.30 in line with KDE frameworks 5.30 release" [Undecided,New]
<acheronuk> thank you :)
#ubuntu-motu 2017-02-07
<Unit193> mapreri: 'Add new get_changes_options() function. This extracts options for dpkg-genchanges from DEBBUILDOPTS.'  That "invaliidates" the changelog entry, it'd seem.
<Unit193> ..And I'm likely poking on the wrong network, but it's nice here. :3
<mapreri> Unit193: -v please
<mapreri> ...and if there is a bug would have been nice to get report of it before I uploaded .4 yesterday evening u.U
<Unit193> mapreri: d/NEWS lists that DEBBUILDOPTS is no longer taken into account, a bit of a "Oh crap" on update.  Then you see the changelog (due to apt-listchanges) and it notes that DEBBUILDOPTS was restored, or at least that was my understanding of it.  And I only noticed when it hit my 'testing' box, so pretty much right before I pinged you. :3
<mapreri> umh
<Unit193> Sorry that I'm not making sense?
<mapreri> Unit193: are you saying something like http://paste.debian.net/913124/ ?
<mapreri> (ps: we have a #pbuilder @ OFTC)
<Unit193> mapreri: Yep!  And didn't know that, I'm only a minor user though.
<mapreri> ack
 * mapreri has to go afk now
<Unit193> Danke.  Have a good evening.
#ubuntu-motu 2017-02-09
<Rhonda> uhm
<Rhonda> sudo cowbuilder --create --basepath zesty --distribution zesty --mirror http://at.archive.ubuntu.com/ubuntu/ --debootstrapopts '--no-check-gpg'
<Rhonda> E: Both --no-check-gpg and --force-check-gpg specified, please pick one (at most)
<Rhonda> â¦ whut :)
<Rhonda> (trying to create me a cowbuilder chroot on debian)
<ogra_> just make it --no-force-check-gpg  ? :P
<ogra_> (kidding ... obviously)
<Rhonda> I'm confused already, you got me that I tried it. :)
<ogra_> lol, sorry
<Rhonda> Found that I need to override DEBOOTSTRAPOPTS in /etc/pbuilderrc as the --force-check-gpg seems to be internal default.
#ubuntu-motu 2018-02-05
<handsome_feng> hsimonq2: Hi, It would be great if you can upload the ukwm and ukui-settings-daemon today, :)
<handsome_feng> sorry, tsimonq2
<tsimonq2> handsome_feng: Sorry, I've just been really busy lately :/
<tsimonq2> handsome_feng: I'll get to it as soon as I can
<handsome_feng> tsimonq2: Fine, Thanks!
#ubuntu-motu 2018-02-07
<handsome_feng> Hi, It would be great if someone could have a look at LP: #1738976 LP: #1738947 Thanks!
<ubottu> Launchpad bug 1738976 in Ubuntu Kylin "[needs-packaging] ukui-panel" [Critical,In progress] https://launchpad.net/bugs/1738976
<ubottu> Launchpad bug 1738947 in Ubuntu Kylin "[needs-packaging] ukui-settings-daemon" [Critical,In progress] https://launchpad.net/bugs/1738947
#ubuntu-motu 2018-02-08
<handsome_feng> tsimonq2: Hi, sorry to trouble you, will you have time to upload ukui-panel today? It's a very important package for us.
<tsimonq2> handsome_feng: I will.
<tsimonq2> handsome_feng: It's the next thing on my TODO list :)
<handsome_feng> tsimonq2: Thank you very much! Y(^_^)Y
<tsimonq2> handsome_feng: uploaded :)
<handsome_feng> tsimonq2: Thanks!
<ch> hi
<ch> xenial shipped with a bad version of pdns (in universe). i'd like to discuss options for improving that situation
<rbasak> ch: are you aware of https://wiki.ubuntu.com/UbuntuBackports and https://wiki.ubuntu.com/StableReleaseUpdates?
<ch> i did read these pages indeed
<rbasak> OK.
<ch> a backport doesn't make the bad version go away though
<ch> (as far as i understand this)
<rbasak> No, you'll need an SRU for that.
<rbasak> (second link)
<ch> and for an SRU, i'm not sure how big of a delta is going to be okay
<rbasak> Ubuntu is generally quite willing to consider exceptions to things, but best to start with understanding the existing policies as an exception request will only happen if it can be explained why the policy is unsuitable.
<rbasak> First: what's the actual problem. Can you expand on "bad"? Is there a bug on this problem?
<ch> 1652392 and 1705766 explain a bit
<rbasak> bug 1652392 bug 1705766
<ubottu> bug 1652392 in pdns (Ubuntu Zesty) "sync newer packages from debian or newer releases" [Undecided,Triaged] https://launchpad.net/bugs/1652392
<ubottu> bug 1705766 in pdns (Ubuntu Xenial) "Invalid DNSSEC signatures on empty responses to mixed-case queries" [Undecided,Triaged] https://launchpad.net/bugs/1705766
<ch> xenial shipped with an alpha release which is really unsuitable to run on the public internet
<rbasak> Did you see https://bugs.launchpad.net/ubuntu/+source/pdns/+bug/1652392/comments/2?
<ubottu> Launchpad bug 1652392 in pdns (Ubuntu Zesty) "sync newer packages from debian or newer releases" [Undecided,Triaged]
<rbasak> (that was me)
<ch> right
<ch> well, i'll do that then, i guess
<rbasak> Just check that all the changes meet the requirements please, to avoid wasted effort.
<rbasak> If you find that something doesn't seem to meet the requirements, we can discuss it then.
<rbasak> I appreciate your help on this, and want you to succeed at getting this landed.
<rbasak> But we have to be careful to avoid regressing existing successful users.
<rbasak> (who may not necessarily be hitting the problems you are due to varying use cases)
<ch> so for that point, i'm the debian uploader, and somewhat closely related to upstream
<ch> as such i don't -actually- run these packages
<ch> i only get the complaints
<rbasak> OK. I hope you understand my sentiment though?
<rbasak> debian uploader> be sure to mention that; that gives you some immediate credibility, and saves us having to be concerned about contacting the Debian maintainer should that be appropriate :)
<ch> i do understand it, but i still insist that the shipped version is super low quality
<rbasak> I'm not denying that it might be of super low quality.
<rbasak> Nevertheless, if there are users happily using it, we care about not pulling out the rug from under their feet.
<rbasak> If it is absolutely necessary, then we can consider doing that, but we don't take it lightly.
<ch> judging from the people that come to the upstream irc channel or mailing lists, they are not happy ;-)
<rbasak> Like you say, you only get to sample the unhappy users, and don't see the happy ones :)
<ch> that is very true
<ch> and i'd hate to leave people with a package installed that doesn't get updates or anything
<rbasak> Define "updates". Security fixes and bugfixes are fine under the SRU policy.
<rbasak> Feature updates and behaviour changes are not.
<rbasak> In reality the two sets overlap sometimes, and we have to make a judgement call.
<ch> Well, two things - 1) clearly, security updates, but then the version in xenial never saw any updates, even though there are a number of CVEs open. 2) For the version in xenial specifically, get a version of pdns into these users hands that's plainly broken for many important usecases or silently fails to serve correct data
<rbasak> I don't think any of that contradicts anything I've said above.
<rbasak> Updates do need to be volunteered. No volunteers = no updates.
<ch> Yeah I do understand that. (Users apparently not so much...)
<rbasak> Volunteered updates are usually expected to meet our policy requirements, but everything we've said sounds like it'll meet these requirements (but needs volunteers to find out)
<ch> so, just inside debian:
<ch> git diff --stat debian/4.0.0_alpha2-2..debian/4.0.0-1 -> 323 files changed, 11335 insertions(+), 8810 deletions(-)
<rbasak> How many upstream commits does that correspond to?
<rbasak> Is it just that some commit touched every other line?
<rbasak> Also, Bionic will be out soon now.
<rbasak> Is Bionic in a healthy shape/
<rbasak> ?
<ch> in upstreams git: git log auth-4.0.0-alpha2..auth-4.0.0 --oneline | grep -c 'Merge pull req' -> 378
<ch> bionic looks good to me. how much time do i have to prod upstream into making a 4.1.1?
<rbasak> Why had you uploaded an alpha release to unstable, BTW? Why not use experimental?
<rbasak> https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule
<rbasak> Feature freeze is March 1st.
<rbasak> Automatic updates from Debian will stop on that date.
<rbasak> You probably want to get an upload into Debian a few days before if you want to be sure of it getting autosynced.
<ch> Upstream thought they were going to release soon and i wanted to get some testing (nobody uses pdns from experimental)
<ch> Okay, thanks
<rbasak> I'm not sure it's appropriate from a Debian perspective to put pre-release stuff into unstable.
<rbasak> But I'm not sure Debian has a policy on that.
<ch> Well, the Debian release wasn't going to happen for another year or so at that time
<rbasak> Debian users use testing too.
<rbasak> I always considered that as *packaging* testing, rather than a place for alpha upstream code.
<rbasak> I could be wrong.
<ch> Bit of both. And I also expected this to not take longer than a month or so
<rbasak> "Some experimental software can still go into unstable, with a few warnings in the description, but that isn't recommended because packages from unstable are expected to propagate to testing and thus to stable."
 * rbasak just looked that up to answer his own question.
<ch> I'm not saying it was a great outcome...
<rbasak> Sorry. I'm not aiming criticism at you. It's just that I've seen this happen before, so I was curious as to your reasons and Debian's policies, so I asked you and looked up the Debian docs. That's all.
<rbasak> It's good that Bionic's in better shape. Thank you for that.
<ch> No offense taken; it is a very valid critique
<rbasak> And it sounds like we'll be quite happy to accept an update for Xenial, but it sounds like it'd be quite a bit of work to check that it won't regress any currently happy users :-/
<ch> I can spend some time to prep an update and test that to some degree. Open question would be on what version that should be based - 4.0.0-2 from debian, or 4.0.3 from zesty or something newer
<ch> the 4.0.0-2 is probably "better" but who knows which bugs are in there. zestys version probably has seen some users
<rbasak> The only real requirement is that users upgrading up releases don't go down in version number.
<rbasak> So it can't be higher than something in a subsequent release unless that subsequent release is also updated, which of course is more work.
<rbasak> EOL'd releases can be ignored for the purposes of this requirement.
<rbasak> Apart from that, like you say it's just a trade-off between likely bugs fixed and the amount of work to prepare the update.
<rbasak> (and to review the update)
<rbasak> We'll need to review the changes you're applying for compliance with Ubuntu's SRU policy
<ch> Debian stretch shipped with 4.0.3, and I know of actual users of that. Having the same version would also have a tiny benefit for security updates...
<rbasak> A broken down patchset, for example from upstream commits, would probably be the easiest for that.
<rbasak> That makes sense.
<rbasak> I think it's entirely appropriate for you to decide on where to fall on the trade-offs.
<ch> Ok. Thanks for your time for now, and I'll see to a debdiff and some supporting info then.
<rbasak> No problem, and thank you for your time in looking after this for Ubuntu
<rbasak> ch: if I'm reviewing, I'd prefer to see a set of git commits rather than everything squashed into a debdiff please.
<rbasak> ch: you can push that wherever you like. Ubuntu sponsors usually don't care as long as they can get ot it.
<ch> rbasak, upstream commits or packaging commits?
<ch> guessing the latter plus upstream split out somehow
<rbasak> Yeah. Both basically.
<rbasak> I want to review in small pieces, that's all.
<ch> nod
<rbasak> Such that each piece is tractable, and I'm confident that the final result is exactly the sum of the pieces.
#ubuntu-motu 2018-02-11
<tsimonq2> handsome_feng: I have uploaded ukui-power-manager and it is now in Bionic Source NEW.
<tsimonq2> handsome_feng: Is there any particular order in which you would like me to review the rest?
<handsome_feng> tsimonq2: the ukwm and other packages with the prefix "ukui" :)
<handsome_feng> tsimonq2: maybe ukwm, ukui-settings-daemon, ukui-media, peony-extensions and others
<tsimonq2> handsome_feng: ok
<handsome_feng> tsimonq2: Thanks!
<tsimonq2> handsome_feng: np
<tsimonq2> handsome_feng: ukwm uploaded.
<handsome_feng> tsimonq2: \ (@^0^@) /
<tsimonq2> handsome_feng: ukui-settings-daemon uploaded, I'll do the rest after I sleep.
<handsome_feng> tsimonq2: Thanks and have a good dream! :)
<tsimonq2> Thanks :)
#ubuntu-motu 2020-02-05
<Darkchaos> Hey guys, is there an easy way to compare existing packages between debian and ubuntu?
<Darkchaos> I'm seeing an ubuntu only problem (sections from the elf header get stripped) and even using "nostrip" as the DEB_BUILD_OPTIONS doesn't help, so I wonder what could've happened there
<Darkchaos> to be precise: nostrip adds 8 sections, most notably .debug_str, .debug_line etc pp, but NOT the VERSYM that I miss. Just building on debian and/or investigating the deb on a debian docker container had these sections
<Darkchaos> So I guess something with debian/rules
#ubuntu-motu 2020-02-08
<JackFrost> teward: You're the xca maintainer in Debian.  Since xca has a new DB format, mightn't it be useful to upload that to backports?
<teward> JackFrost: on my list of things to do but its wayyyyy lower on the priority list.
<teward> Since I can do the backport at $INSERT_TIME_HERE I am focusing on higher priority things at the moment - Studio needs some things poked and theres other higher priority things I keep an eye on for the dev cycle that I need to keep an eye on from now until featurefreeze
<teward> JackFrost: however how old are you thinking for the backport?  Any xca >= 2 i believe uses the new DB format.  Theres some other deps I think might not exist in older versions as well - and for EOL Releases I am hesitant to really backport to those (so 16.04 is the oldest I may keep an eye on)
<teward> But for now E:EXHAUSTION from 72h+ of hell from this week and a major infra outage at work so I am heading back to sleep for another 5 hours :P
<JackFrost> Well considering Ubuntu backports aren't really a thing,  I was thinking buster here.
<teward> Ahhhh in Debian.
<teward> Context next time since this is #ubuntu-motu ;)
<teward> E:LackOfContext :P
<teward> On my list of things
<teward> But again not ultra critical since right now I need sleep more
<teward> (Also Ubuntu does have backports ;) )
<JackFrost> Sure, but functioning*
<Darkchaos> I don't understand one thing: In the .dsc (debian/control), there is a specific g++ version pinned (g++-9), whereas in the debian/rules, the GCC Version varies based on what is available for that distribution. What is the background there?
<Darkchaos> I just patched the dsc to accept g++8 for now, as the rules file would pick g++8 on buster anyway
#ubuntu-motu 2020-02-09
<eamanu> Hi!
<eamanu> I maintain some package on Debian, and I would like to start with ubuntu.
<eamanu> I don't understand, on d/changelog, I can see on Ubuntu packaging guide, that the version is xUbuntu1;
<eamanu> but I am looking that there are some package that have the Debian version and not the xUbuntuY
<eamanu> and the distribution is unstbale too?
<RikMills> xubunty means there is a ubuntu specific change to the debian package
<eamanu> ahhh
<eamanu> ok, I understadn
<RikMills> whwre there is not that, it means the package has been automatically or manually synced from debian unstable with no changes
<eamanu> and it's ok if the distribution is unstable?
<RikMills> for a synced package, yes
<eamanu> well, I try to upload to my ppa a package for unstable, but I receive an error about unstable distribution
<RikMills> yes, direct upload to a ppa requires a valid ubuntu release as the target
<eamanu> oh.. ok.. I see.. great thanks RikMills
<teward> JackFrost: until gcc-10 moves into testing from Unstable, the latest XCA is blocked
<teward> and i want that to land in testing before I backport it in Debian
<teward> since backports take from testing according to the backports site :P
