[00:19] <Flare183> Is there anyone that can mentor me?
[00:20]  * Flare183 hopes that someon could mentor him
[00:24] <Flare183> anyone?
[00:25] <Flare183> !motuy
[00:25] <ubotu> Sorry, I don't know anything about motuy - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[00:25] <Flare183> !motu
[00:25] <ubotu> 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
[00:25] <Hobbsee> most people arent' around at this time of day
[00:25] <Hobbsee> and i think there's a place to register for it
[00:25] <Hobbsee> !mentoring
[00:25] <ubotu> Sorry, I don't know anything about mentoring - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[00:25] <Flare183> wow
[00:26] <slangasek> Flare183: if you're looking for help with a specific question, please ask it.  If you're looking for a general commitment from a "mentor", like Hobbsee says there's some sign-up list for such things (though I'm afraid I don't know where)
[00:27] <nixternal> Flare183: https://wiki.kubuntu.org/MOTU/Mentoring
[00:27] <Flare183> Found it thanks
[00:27] <nixternal> groovy
[00:27] <nixternal> also hit up the list
[00:28]  * Hobbsee would suggest that one reads the FAQ bfeore asking such questions, which would lead you to https://wiki.ubuntu.com/MOTU/FAQ#head-46634de24118604a33c6eccd2960a598d906daf9
[00:28] <Flare183> ok thanks guys soon i will be join you all
[00:28] <Flare183> joining
[00:29] <ScottK> Flare183: Please keep in mind that the formal mentoring process is completely optional.  You are free to dive in and ask questions as needed here.
[00:29] <zul> evening
[00:30] <Flare183> I know i just trying to give that "big" contribution that I have to give
[00:32] <rpereira> Hey everybody.
[00:35] <imbrandon> moins all, Hobbsee, slangasek, ScottK, zul, nixternal
[00:35] <Hobbsee> hey imbrandon
[00:35] <ScottK> Heya imbrandon.
[00:35] <StevenK> Morning imbrandon
[00:35] <imbrandon> nixternal: was just talking to Whiprush about penguincon(sp?) i have the time off confirmed from $work, woot
[00:35] <imbrandon> heya StevenK
[00:36] <Gunner_Sr_> hola! imbrandon
[00:36] <slangasek> moinmoin and ikiwiki
[00:36] <imbrandon> ello Gunner_Sr_
[00:36] <imbrandon> slangasek: heh
[00:38] <imbrandon> slangasek / StevenK : btw over last week i roped a "full time" DD sponsor, woot, not only does this mean i dont have to periodicly bug random DD's for uplaods but $sometime it will make a NM application easier
[00:38] <StevenK> Poor bastard.
[00:38] <StevenK> Oh, I mean, that's good.
[00:38] <imbrandon> hehe
[00:38] <StevenK> :-P
[00:39] <imbrandon> i'm thinking just after Hardy realease i'll apply for NM, as long as i keep on the same path etc
[00:41] <ScottK> imbrandon: Applying doesn't take long (if you've got your key signed) and there's lots of waiting in the process.  Why not get started.
[00:42] <imbrandon> ScottK: i have a few more cleanups on my packages i'd liek to complete by then , and plus i do have signatures but no DD signatuers and likely wont untill April 08
[00:42] <Gunner_Sr_> ScottK: what is NM?
[00:42] <imbrandon> New Maintainer ( e.g. apply to be a DD )
[00:42] <imbrandon> Gunner_Sr_: ^^
[00:42] <Gunner_Sr_> thx
[00:43] <imbrandon> ScottK: plus untill now i've always had $random DD do uploads for me, i dont think one single DD has made 2 uploads for me, so getting a advocate is a bit hard that way
[00:44] <imbrandon> thast really the main thing
[00:44] <ScottK> Yeah.  That can make it tough.
[00:44] <imbrandon> i COULD drive to St.L in one afternoon and get a sig if i needed
[00:44] <imbrandon> DD Sig
[00:44] <ScottK> There you go.
[00:45] <ScottK> That or go to the next UDS since you're in no hurry.
[00:45] <imbrandon> i'll see quite a few people from UDS in April
[00:45] <imbrandon> :)
[00:45] <Gunner_Sr_> imbrandon: Is this in relation to getting your key verified?
[00:45] <imbrandon> Gunner_Sr_: kinda, thats one of the things, yes
[00:46] <imbrandon> for Debian, not Ubuntu, ubutnu uses the WoT , debian requires the DD WoT
[00:46] <Gunner_Sr_> imbrandon: I just did that through biglumber and met a person in my local area.
[00:46] <imbrandon> Gunner_Sr_: its not a matter of that, i have plenty of normal sigs, i need a DD sig :)
[00:47]  * ajmitch wonders where the next UDS will be
[00:47] <Gunner_Sr_> imbrandon: Ah, got it.
[00:47]  * StevenK does too
[00:47]  * imbrandon bets it wont be in the US
[00:47] <StevenK> I wished Launchpad checked a key was trusted before it let you import it.
[00:47] <mok0> UDS?
[00:47] <StevenK> mok0: Ubuntu Development Summit
[00:48] <imbrandon> Ubuntu Developers Summit
[00:48] <mok0> thx
[00:48] <imbrandon> StevenK: yea, that would be nice
[00:48] <Gunner_Sr_> imbrandon: The hardest thing I am starting to realize is that there is not alot of loco activity in the Midwest of US.
[00:48] <imbrandon> Gunner_Sr_: nope, not much
[00:48] <ScottK> Gunner_Sr_: Where are you located?
[00:48] <imbrandon> Gunner_Sr_: we are so spread out , out here
[00:48] <imbrandon> Gunner_Sr_: where are you ?
[00:49] <Gunner_Sr_> Seattle, WA
[00:49] <imbrandon> ahh
[00:49]  * ScottK has never heard that described as part of the midwest before.
[00:49] <imbrandon> actualy there is alot of LUG activity out here but not alot of debian or ubuntu specific
[00:49]  * Gunner_Sr_ agrees
[00:50] <imbrandon> ScottK: heh me either
[00:50]  * Gunner_Sr_ lol
[00:51] <imbrandon> ScottK: see the new "midwest" theme i'm working on for my blog ? still alot of bugs in it thus not live, but have a peek http://69.247.213.131/
[00:51]  * ScottK looks.
[00:51] <imbrandon> ( its running a DB copy of the data )
[00:51] <ScottK> Definitely looks midwest, although more Iowa than KS/MO.
[00:52] <imbrandon> heh well at one point in history all the beef in the US came through KC :)
[00:52]  * Gunner_Sr_ cow tippin, heheh
[00:52] <ScottK> imbrandon: I'm old enough to remember the smell.
[00:52] <StevenK> Yeah, but that isn't now.
[00:52] <imbrandon> :)
[00:52] <Gunner_Sr_> imbrandon: Did you get you new computer?
[00:53] <imbrandon> StevenK: yea but our stockyards are still an attraction
[00:53] <StevenK> If all the beef came from the US, then all of the politi... eer, manure came from there too
[00:53] <StevenK> s/the US/KC/
[00:53] <imbrandon> Gunner_Sr_: no, not yet, only ~50% of the way there
[00:53] <Gunner_Sr_> imbrandon: okey dokey.
[00:54] <ScottK> StevenK: When I was growing up, we certainly had our share of it.  You could smell the stockyards in most of the city and it's a BIG city.
[00:54] <imbrandon> heh yea
[00:54] <StevenK> Um, ew
[00:55] <StevenK> imbrandon: Here's a quarter, buy yourself a real computer :-P
[00:55] <imbrandon> now they are just a tourist attration and mall-ish area
[00:55]  * StevenK actually has a few US quarters on his table
[00:55] <imbrandon> heh
[00:56]  * imbrandon directs StevenK to his holiday computer fund page
[00:56] <Gunner_Sr_> imbrandon: I have a few P3 servers lying around too...
[00:56] <StevenK> imbrandon: I saw it. Personally, I buy my own hardware rather than have the Internet buy it for me.
[00:57] <tonyyarusso> I wouldn't mind having some P3 boxes around if I could figure out how to make them into a cluster
[00:58] <Gunner_Sr_> tonyyarusso: You can, just use LIMULUS..
[00:58] <Gunner_Sr_> tonyyarusso: It is called a personal cluster.
[00:58] <StevenK> tonyyarusso: If you want a farm of builders, you can use distcc
[00:59] <imbrandon> StevenK: i do both :)
[00:59] <tonyyarusso> StevenK: interesting
[01:00] <imbrandon> i figured , why not try :)
[01:00] <Gunner_Sr_> StevenK: I use it from my notebook to my quad server. :-)
[01:00] <tonyyarusso> Gunner_Sr_: apt-cache doesn't show that - link?
[01:00] <zul> *sigh* nother interview tomorrow
[01:00] <imbrandon> zul: any offers yet?
[01:00] <Gunner_Sr_> tonyyarusso: goto http://limulus.basement-supercomputing.com
[01:00] <zul> imbrandon: nope not yet...its coming soon i can feel it in my bones
[01:01] <imbrandon> zul: best-o-luck :)
[01:01] <tonyyarusso> Gunner_Sr_: heh, "check back soon"..
[01:01] <mok0> Gunner_Sr_: web server is down :(
[01:01] <StevenK> zul: "Yes, we have an opening for you. Please don't slam it on the way out."
[01:01] <imbrandon>  Updating - check back soon - 11/1/2007
[01:01] <zul> StevenK: heh
[01:02] <mok0> Supercomputing. eh?
[01:02] <mok0> Gunner_Sr_: I'm curious, tell us about LIMULUS
[01:03]  * Gunner_Sr_ Interesting, last time I spoke to Doug he was suppose to have it up and running.
[01:04] <imbrandon> zul: i started with www.vml.com last month, lovin is so far, i even get to use Ubuntu on my workstation :)
[01:04] <Gunner_Sr_> mok0: trying to build/buy/use of the shelf personal hardware to build clusters.
[01:04] <zul> imbrandon: cool its nice when they let you do that
[01:05] <StevenK> Neat. The website is flash
[01:05] <imbrandon> yea not all of it, infact not even important parts
[01:06] <imbrandon> but with customers like MS and Adidas they want "flashy" stuff
[01:06] <StevenK> Well, your company has the right number of letters for Adidas' usual customers
[01:06] <Gunner_Sr_> mok0: supposedly to price to performance of less than $100 per GFLOPS.
[01:06] <mok0> Gunner_Sr_: Wow
[01:06] <imbrandon> StevenK: ??
[01:07] <StevenK> imbrandon: Never mind
[01:07] <imbrandon> heh
[01:07] <imbrandon> http://www.vml.com/client.aspx
[01:07] <mok0> Gunner_Sr_: What's the software used?
[01:08] <Gunner_Sr_> mok0: Microwulf is another project at http://www.calvin.edu/~adams/research/microwulf/
[01:08] <imbrandon> StevenK: even bluetooth.com ( *rolls eyes* ) heh
[01:08] <StevenK> imbrandon: What are you doing there, though?
[01:08] <imbrandon> Unix/Linux sysadmin
[01:08] <mok0> I am packaging the torque batch system for Ubuntu
[01:08] <StevenK> imbrandon: For how many machines?
[01:09] <imbrandon> personaly about 300, but we have a few thousand
[01:09] <StevenK> Neat
[01:09] <mok0> Gunner_Sr_:  Microwulf, cool!
[01:09] <imbrandon> about 100 Solaris 9 boxen, 2 or 3 AIX boxen and a TON of CentOS/Ubuntu mix
[01:09] <imbrandon> StevenK: ^
[01:10] <nixternal> imbrandon: I am going to be in Michigan that week already
[01:10] <StevenK> Eww, AIX
[01:10] <zul> imbrandon: then you can dump the redhat knock off and use gentoo ;)
[01:10] <imbrandon> yea it runs some funky fax to creditcard gateway stuff thats getting phased out
[01:10] <zul> oh wait..
[01:11]  * StevenK gags zul and throws him in the closet
[01:11] <zul> heh
[01:11] <mok0> Gunner_Sr_: I am looking for other people who are interested in ubuntu cluster computing
[01:12] <mok0> Actually, that's an invitation for everyone
[01:12] <Gunner_Sr_> mok0: I don't do much of it anymore. It is cheaper to build scale units in DCs now.
[01:13] <mok0> DCs?
[01:13] <bddebian> Heya gang
[01:13] <imbrandon> mok0: i'd be intrested but i need to get 2.6 kernel running on xbox first
[01:13] <mok0> imbrandon: hehe
[01:13] <Gunner_Sr_> mok0: Data Center's
[01:14]  * ScottK ordered an OLPC in the 2 for 1 deal.  Anyone know if Ubuntu will run on that?
[01:14] <mok0> Acronym overload
[01:15]  * StevenK hands G703, BGP and OSPF to mok0 
[01:15] <imbrandon> G703 ?
[01:15]  * imbrandon knows the others
[01:15] <mok0> Kernel panic...
[01:16] <StevenK> imbrandon: Line protocol for fiber
[01:16] <imbrandon> ahh
[01:16] <imbrandon> ScottK: no idea, i know there is a spec about it though
[01:16] <imbrandon> https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-on-olpc
[01:16]  * StevenK dealt with G703 at $old_work
[01:16] <imbrandon> ScottK: mako or ogra would probably the ones to ask
[01:16] <ScottK> mok0: One Laptop Per Child.
[01:17] <mok0> ScottK: What are the specs?
[01:18] <ScottK> mok0: I'm not exactly sure.  The deal here is that you can buy two for $400 and you get one and one goes to a needy child in a poor nation, so I figured I'd give it a shot for curiosity's sake.
[01:18] <ScottK> I'm really curious about how a laptop designed for children will work.
[01:18] <mok0> ScottK: very good
[01:20] <Gunner_Sr_> mok0: worked with pbuilder at all?
[01:20] <imbrandon> ScottK: i got to play with one, they are really easy to use
[01:20] <mok0> Gunner_Sr_: Sure
[01:20] <imbrandon> not powrfull but easy
[01:21] <Gunner_Sr_> mok0: okay, working on bug #145074
[01:21] <ubotu> Launchpad bug 145074 in xgalaga "xgalaga-hyperspace crashed with SIGSEGV" [Medium,In progress] https://launchpad.net/bugs/145074
[01:21] <ScottK> imbrandon: Good to hear.
[01:21] <imbrandon> ScottK: have you tried the sugar interface ?
[01:21]  * ScottK doesn't know what that is.
[01:21]  * ScottK doesn't have the OLPC yet either.
[01:21] <imbrandon> suger is the UI for olpc
[01:21] <imbrandon> sugar*
[01:21] <ScottK> Right.
[01:22] <minghua> You can try sugar in a VM, I heard.
[01:22] <Gunner_Sr_> mok0: I am VC++ developer, have done very little on Linux with deb, etc. use to use RPM and Unix
[01:22] <imbrandon> one sec, you acn run it in a xnest on ubuntu
[01:22] <imbrandon> minghua: its not a vm, its in a nested X instance
[01:22] <mok0> Gunner_Sr_: So can I help?
[01:23] <Gunner_Sr_> mok0: just built the chroot cleanroom and went to the directory. Can I work on the tar in that directory, or should I copy to a working folder and work on it form there?
[01:24] <mok0> Gunner_Sr_: You can unpack the base.tgz file, make changes, and re-tar it
[01:24] <imbrandon> ScottK / minghua : https://edge.launchpad.net/~jani/+archive  , install sugar and sugar-activties from that and you can run it "in a window" on Gutsy
[01:25] <Gunner_Sr_> mok0: all I have is the orig.tar.gz and the diff.gz?
[01:25] <mok0> Gunner_Sr_: I usually copy orig.tar.gz, diff.gz and .dsc file to /tmp
[01:25] <mok0> you run the pbuilder on the .dsc file
[01:26] <Gunner_Sr_> mok0: perfect, that is what I was looking for..
[01:26] <mok0> ie sudo pbuilder --build blabla.dsc
[01:26] <Gunner_Sr_> mok0: and you do that in /tmp right?
[01:27] <mok0> Yes,
[01:27] <Gunner_Sr_> mok0: cool thanks.
[01:27] <mok0> pbuilder doesn't work well from an NFS mounted directory, which is what I have
[01:27] <minghua> Gunner_Sr_, mok0:  You can do that whereever you want, the source packages are copied over.
[01:27] <Gunner_Sr_> mok0: Agree, I was seem to have problems with NFS.
[01:28] <mok0> minghua: no it doesn't work well on an NFS mounted dir
[01:28] <mok0> minghua: it has to be a local disk in my experience
[01:29] <jonnymind> Hello
[01:29] <minghua> mok0: You mean I can't do "pbuild --build /home/minghua/foo_1-1.dsc" when my home is on NFS?
[01:29] <mok0> minghua: yes
[01:30] <minghua> mok0: Or do you mean I can't do that when /var/cache/pbuilder is on NFS?
[01:30] <minghua> Hmm.
[01:30] <jonnymind> I got a couple of questions about contributing packages, may I ask here?
[01:30] <bddebian> Certainly
[01:30] <mok0> minghua: I don't know about /var/cache
[01:30] <mok0> !ask > jonnymind
[01:30] <minghua> mok0: Pbuilder uses /var/cache/pbuilder/build/ as the chroot dir.
[01:31] <mok0> yes, but it needs to have root access to your NFS mounted dir, which is not normally permitted
[01:31] <mok0> jonnymind: don't ask to ask, just ask
[01:31] <jonnymind> I've been developing an open source project, namely ap programming language; It's being integrated in kde4, and I thought that I may present it to distros too.
[01:32] <mwolson> is it just me, or does quilt try to make a hardlink to somewhere in /tmp/ every time a pull/push is done?
[01:32] <jonnymind> (it's a courtesy form. In my country, it's like saying "hi there"!)
[01:32] <mok0> jonnymind: just irc etiquette :-)
[01:32] <jonnymind> So, I signed for a motu account.
[01:32] <jonnymind> sorry,
[01:32] <jonnymind> I mean ... uhm... for a revu account.
[01:33] <mok0> jonnymind: good
[01:33] <jonnymind> Still need  to get accustomed this acronym.
[01:33] <minghua> mok0: Okay.  I don't have NFS here, so I wouldn't know.
[01:33] <jonnymind> I have been shipping some "hand made" debs for sometime now, and I have polished them with the help of ubuntu-it-dev ppl.
[01:34] <mok0> minghua: It threw me off when first playing with pbuilder
[01:34] <jonnymind> Mu question is: I see now in revu page that I have to upload the source tarball.
[01:34] <mok0> jonnymind: ok
[01:35] <jonnymind> this is fine to me; the problem is that I have a quite complex build environment (modeled after KDE's),
[01:35] <mok0> jonnymind: have you got your gpg public key in revu?
[01:35] <jonnymind> so the tar wouldn't just copille.
[01:35] <jonnymind> *compile
[01:35] <jonnymind> yes I have.
[01:35] <mok0> jonnymind: revu doesn't do compilation
[01:35] <jonnymind> Fine.
[01:35] <Gunner_Sr_> mok0: did pbuilder in /tmp and no source??
[01:35] <mok0> jonnymind: what's your package called?
[01:36] <jonnymind> "Falcon"
[01:36] <jonnymind> or if you wish, falconpl for programming language.
[01:36] <mok0> Gunner_Sr_: explain, pls
[01:37] <jonnymind> ATM, I get the binaries, mangle (i.e. strip) them, copy them and pack them with a set of bash scripts. One of the outputs are debs files (so lib, bins and devs).
[01:37] <jonnymind> How is exactly a "source package" done?
[01:37] <Gunner_Sr_> mok0: sure, copied orig.tar.gz, diff.gz, and the .dsc to /tmp and pbuilder --build on the .dsc file
[01:37] <jonnymind> *some of the outputs are...
[01:37] <mok0> Gunner_Sr_: did it run to completion?
[01:38] <mok0> Gunner_Sr_: look in /var/cache/pbuilder/result
[01:38] <mok0> jonnymind: it's a long story. You have to check the documentation
[01:39] <Gunner_Sr_> mok0: okay, looking
[01:39] <jonnymind> I see. Just one question then, before I skim in the wrong direction:
[01:39] <minghua> jonnymind: Your way of building the .deb packages doesn't sound compatible to the way REVU requires.
[01:39] <minghua> jonnymind: You need to learn the proper way to build a package.
[01:39] <jonnymind> minghua: I am here to learn.
[01:39] <Gunner_Sr_> mok0: the files are in there, but I want to debug the source and any diffs?
[01:39] <jonnymind> How's done then?
[01:39] <mok0> jonnymind: look here: https://wiki.ubuntu.com/PackagingGuide
[01:39] <minghua> !packagingguide | jonnymind
[01:39] <ubotu> jonnymind: packagingguide is 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
[01:40] <jonnymind> perfect.
[01:40] <mok0> Gunner_Sr_: You mean the diff.gz?
[01:40] <Gunner_Sr_> mok0: yes
[01:40] <mok0> lsdiff -z blabla.diff.gz
[01:40] <jonnymind> Of course...
[01:41] <jonnymind> I would also accept any help directly on the code. There isn't any inherent reason for me to be the pack debs in one way or another, or to be the one to pack them.
[01:42] <Gunner_Sr_> mok0: let me try this again. I have the source package, I want to open it up, execute and debug it, in anjuta and see what is going on. I have the stacktrace so I have a pretty good idea, just need to confirm and then fix it.
[01:43] <mok0> Gunner_Sr_: you need to run dpkg-source -X blabla.dsc
[01:43] <RAOF> somerville32: Oh, that "add deb-source line for hardy" was with reference to to my amd64 box?, presumably?  Ok.
[01:43] <mok0> Gunner_Sr_: That will unpack the tar and apply the patches
[01:43] <minghua> Gunner_Sr_: You don't "execute" a source package.  There are only source code, not executables, in there.
[01:44] <Gunner_Sr_> minghua: correct, just compile/debug :-)
[01:44] <jonnymind> Another thing: I signed in the launchpad longtime ago, nearly by mistake. Is there any way to reset the password?
[01:46] <tonyyarusso> Are there any other FOSS forum platforms besides phpBB?
[01:46] <imbrandon> jonnymind: dunno you can ask them in #launchpad
[01:46] <jonnymind> thank you very much,
[01:46] <StevenK> Er, there's a link for "Forgotten your password" when you go to sign in
[01:47] <jonnymind> Oh. I didn't notice as I was logged in with the cookie of my browser. Thanks.
[01:48] <Gunner_Sr_> mok0: so it is all right to do dpkg-source in the /var/cache/pbuilder/result directory or should I have done it in /tmp?
[01:48] <mok0> Gunner_Sr_: Where you have the "source package", in your case /tmp
[01:49] <mok0> The "source package" consists of 3 files, *.orig.tar.gz, *.diff.gz and *.dsc
[01:49] <mok0> Gunner_Sr_: Weird when you come from the RPM world....
[01:50] <Gunner_Sr_> mok0: tell me about it. I want to make sure that I don't do any bad habits. :-)
[01:50] <mok0> hehe
[01:51] <mok0> Gunner_Sr_: /var/cache/pbuilder is just where the pbuilder does its stuff. You don't want to create files there
[01:51] <mok0> Gunner_Sr_: But you can pick up the finished .deb files there
[01:52] <Gunner_Sr_> mok0: got it, this is where I would package up to go back into the repository?
[01:52] <mok0> Gunner_Sr_: exactly
[01:52] <Gunner_Sr_> mok0: starting to make sense now.
[01:52] <mok0> Then we've accomplished something tonight :-)
[01:53] <mok0> (at least it's night here)
[01:53] <mok0> jonnymind: I don't see your "falcon" package on revu
[01:53] <Gunner_Sr_> mok0: wait till I fix it and need to get the changes back in.....
[01:53]  * Gunner_Sr_ lol
[01:53] <mok0> Gunner_Sr_: There you go
[01:53] <jonnymind> I didn't upload it: I must do the sourrce package following your rules.
[01:54] <mok0> jonnymind: yes, ok. It's a bit of work :-)
[01:54] <mok0> jonnymind: ... and then you'll have the MOTUs pounding on your package over and over and over again....
[01:54] <jonnymind> I got an old package on my site (2 weeks old...), and tonight I cleaned it breaking up the .so.1 part from the rest, and cleaning the lintian report.
[01:55] <jonnymind> :-) That goes beyond mybest hopes :-)
[01:55] <mok0> jonnymind: You only need to split out the shared library if you're building a library package
[01:55] <jonnymind> However, I  hope to get on it by tomorrow;
[01:55] <bddebian> OK darnit lsmod shows my ipw2100 but I have no wireless device..?? :(
[01:55] <jonnymind> I am.
[01:55] <jonnymind> At least, in the distro for my site.
[01:55] <mok0> jonnymind: ok
[01:56] <jonnymind> The "engine" may be used without the interpreter.
[01:56] <jonnymind> I.e. by embedding applications.
[01:56] <mok0> jonnymind: cool
[01:56] <jonnymind> :-)
[01:56] <jonnymind> I have just a doubt on extension modules as i.e. regex, process and sockets...
[01:56] <jonnymind> But we'll see.
[01:57] <mok0> jonnymind: yes. Go ahead an build the package the way you think it should be done. You'll get feedback from the MOTUs, but they will at least have something to look at
[01:58] <mok0> jonnymind: but be warned, it may take a while, and be prepared to hang around here asking for advice
[01:58] <jonnymind> Thank you very much. I'll just read requirements to build source package and send what I have.
[01:58] <jonnymind> I have never been afraid of aksing advice :-)
[01:58] <jonnymind> I've learned long ago that arrogance never pays.
[01:59] <mok0> jonnymind:  That's a valuable quality :-)
[02:00] <jonnymind> Btw, If you want to give a look at the stuff to get an idea, I kan spam here or in pv the link.
[02:00] <jonnymind> *can
[02:06] <mok0> jonnymind: it's a bit late for me to do any serious work. I need to go to bed in a few minutes
[02:06] <jonnymind> So you're in my time zone :-)
[02:07] <jonnymind> I am leaving too.
[02:07] <mok0> jonnymind: I'm in GMT+01
[02:07] <jonnymind> Here GMT+2, I think, just shifted
[02:07] <mok0> jonnymind: if we meet here again I can take a look (but I am not a MOTU)
[02:08] <jonnymind> I will surely hang around here a lot.
[02:08] <Gunner_Sr_> mok0: thanks for your help. I want to be a regular in MOTU, so you should me around.
[02:08] <jonnymind> Anyhow, I need to make professional debs, even if they won't reach Ubuntu distro.
[02:09] <mok0> Gunner_Sr_, jonnymind : nice to meet you guys, see you soon then!
[02:09] <jonnymind> (i.e. if you don't accept them).
[02:09] <jonnymind> It has been a pleasure.
[02:09] <jonnymind> GoodNight.
[02:09] <mok0> G'night!
[02:09] <Gunner_Sr_> mok0, jonnymind: like wise.
[02:10] <jonnymind> I sign off too. Good night and see you soon.
[02:10] <Gunner_Sr_> jonnymind: seeya.
[02:57] <nenolod> greetings
[03:13] <TheMuso> Yay. Finally I've got a test rebuild of all libglib1.2 transition packages going.
[03:19] <effie_jayx> TheMuso,  :D
[03:20] <santiago-ve> ... omg... i was just calling effie_jayx a freak but...
[03:21] <effie_jayx> santiago-ve,  show some respect for the motu!!
[03:22] <santiago-ve> Ok, sorry effie_jayx, TheMuso ... im impusive sometimes
[03:40] <TheMuso> Has anybody managed to get gpg agent working?
[03:40] <TheMuso> Using the package in Gutsy, I can't seem to get it tow rok.
[03:40] <TheMuso> to work
[03:40] <TheMuso> GPG says there is a problem connecting.
[03:42] <Hobbsee> which gpg agent are you using?
[03:42] <Hobbsee> it requires a bit of mangling
[03:42] <ScottK> TheMuso: Works for me.
[03:42] <TheMuso> Hobbsee: gnupg-agent
[03:43] <imbrandon> seahorse works fine here, but i guess to dont mean that one
[03:43] <TheMuso> Hobbsee: WHich one are you using?
[03:43] <Hobbsee> oh hang on, gpg agent works by default
[03:43] <Hobbsee> it's getting the gpg agent to do ssh that's harder
[03:43] <Hobbsee> TheMuso: pinentry-gtk2
[03:43] <somerville32> seahorse is amazing
[03:43] <TheMuso> I'm not using ssh to do remote signing.
[03:44] <ScottK> TheMuso: Does your ~/.gnupg/gpg.conf include 'use-agent'?
[03:44] <TheMuso> Yes
[03:44] <TheMuso> The agent loads on session start.
[03:44] <imbrandon> Hobbsee: got a howto on the ssh bit ? i'd love to use it for remote signing
[03:44]  * Hobbsee does not like seahorse
[03:44] <TheMuso> But gpg can't connect to it for some reason.
[03:44] <TheMuso> GPG_AGENT_INFO gets set
[03:44] <StevenK> I like pinentry
[03:45] <ScottK> TheMuso: And you've got a pinentry installed?
[03:45] <TheMuso> Instaling now.
[03:45] <imbrandon> 'i've never used anything but seahorse, guess i should try the others
[03:45] <StevenK> TheMuso: What about .gnupg/gpg-agent.conf ?
[03:46] <TheMuso> StevenK: I don't have that file.
[03:46] <StevenK> steven@liquified:~% cat .gnupg/gpg-agent.conf
[03:46] <StevenK> pinentry-program /usr/bin/pinentry
[03:46] <TheMuso> ah ok.
[03:46] <StevenK> TheMuso: That's how gpg knows to ask for a PIN via pinentry
[03:46] <TheMuso> Right.
[03:47] <mwolson> i like gpa better than seahorse
[03:47] <StevenK> TheMuso: You baulked at signing that many sources by hand?
[03:47] <Hobbsee> imbrandon: there is, on google somewhere, but i can't seem to find it
[03:47] <TheMuso> StevenK: Well I do want an agent to help me, yes.
[03:47] <imbrandon> Hobbsee: cool i'll dig a little later
[03:47] <Hobbsee> imbrandon: it's http://www.debian-administration.org/articles/378 and modifying 90gpg-agent
[03:47] <StevenK> Pinentry is great
[03:47] <Hobbsee> the original page was green, adn i can't find it now.
[03:48]  * Hobbsee can scp the 90gpg-agent file over to aurora, if you wish
[03:48] <imbrandon> i'm just happy to get my usb+crypt fs image+ssh keys happy :)
[03:48] <imbrandon> Hobbsee: how about people.uw.c , aurora is long since gone
[03:48] <imbrandon> :)
[03:49] <StevenK> Time estimate: 0.25 man/month.
[03:49] <StevenK> Can someone explain what that actually means?
[03:49] <imbrandon> ( actualy its not gone, its just behind a private fw now )
[03:50] <imbrandon> StevenK: take 1 person ~7.5 days ?
[03:50] <Hobbsee> imbrandon: http://people.ubuntuwire.com/~hobbsee/90gpg-agent
[03:50] <TheMuso> br
[03:50] <TheMuso> brb
[03:50] <imbrandon> Hobbsee: killer thanks
[03:50] <minghua> StevenK: Sounds like diet estimate instead of time estimate. :-)
[03:50] <StevenK> imbrandon: How do you get that?
[03:50] <imbrandon> StevenK: man = 1 and 30 / 4
[03:51]  * ScottK makes a note of bddebian getting actual help on #debian-devel and not messed with at all.  Something must be wrong with the universe today.
[03:51] <minghua> imbrandon: 0.25 man/month literaly equals to 1 man per 4 months.
[03:52] <imbrandon> umm ok, was only a guess
[03:52] <imbrandon> :)
[03:52] <TheMuso> Um ok.
[03:52] <TheMuso> gpg doesn't want to use pinentry-gtk-2
[03:52] <StevenK> minghua: Which means how much time?
[03:53] <TheMuso> I have the gpg-agent.conf file like StevenK explained, as well as use-agent in gpg.conf.
[03:53] <Hobbsee> you probably need the custom 90gpg-agent script
[03:53] <minghua> StevenK: I think maybe it's just a typo of (man * month) instead of (man / month).
[03:53] <bddebian> ScottK: No shit eh? :)
[03:53] <TheMuso> Gpg simply says: gpg: gpg-agent is not available in this session
[03:53] <TheMuso> Hobbsee: Where can I find that?
[03:54]  * Hobbsee points ~15 lines up
[03:54] <Hobbsee> http://people.ubuntuwire.com/~hobbsee/90gpg-agent
[03:54] <TheMuso> thanks
[03:54]  * ScottK can sense the world about to return to normal.
[03:54] <imbrandon> ?
[03:55] <slomo> siretart: ping? what do you think about updating ffmpeg in debian to a newer svn snapshot? ;)
[03:56] <StevenK> TheMuso: Did you logout since adding use-agent in gpg.conf?
[03:56] <TheMuso> StevenK: hang on, gotta log out again to make use of the new script.
[03:56] <TheMuso> brb
[03:57] <ScottK> imbrandon: For a minute there it looked like bddebian was gonna get dumped on in #debian-devel again.
[03:57] <imbrandon> ahh
[03:57] <StevenK> vorlon is playing nice
[03:58] <Hobbsee> he has to.  he's involved with ubuntu.
[03:58] <ScottK> Hobbsee: Not on #debian-devel he doesn't.
[03:58] <persia> (and not when using that nick)
[03:58] <TheMuso> yay!
[03:58] <ScottK> He generally does, but I was sensing an exception moving in.
[03:59]  * Hobbsee would have still expected that one would have to behave nicely to coworkers, and related community, on any network.
[03:59]  * persia doesn't think Hobbsee idles in #d-d often
[03:59] <ScottK> Heh.
[03:59]  * TheMuso sits back and watches the mass signing.
[03:59] <Hobbsee> persia: i do - the question is how often i read it
[03:59] <persia> heh
[03:59] <imbrandon> heh thats exactly why i idle and not talk there :)
[04:00] <bddebian> ScottK: You're killing me man :)
[04:00] <imbrandon> man i wish there was 3 of me at times
[04:00]  * StevenK usually idles on there because it's mainly ari helix and Clint all talking about crap
[04:01] <imbrandon> i idle there just to peek when someone says something like this
[04:01] <imbrandon> heh
[04:01] <bddebian> StevenK: Nooo ;-)
[04:02] <imbrandon> but i'm easy to spot, the Ubuntu guy hidden in the corner with -0- lines in the logs
[04:02] <imbrandon> :)
[04:02] <StevenK> If it were only like that here
[04:02] <imbrandon> lol
[04:02] <bddebian> haha
[04:02] <StevenK> Oh, did I say that out loud? :_P
[04:02]  * imbrandon goes back to #kubuntu-devel
[04:02] <imbrandon> :P
[04:03] <ajmitch> it's ok imbrandon, I'm in permanent lurk mode now as well
[04:03] <imbrandon> ajmitch: :)
[04:03] <imbrandon> i noticed, where ya been man
[04:03] <ajmitch> around
[04:04] <imbrandon> i thought you got a new gf or something :)
[04:04] <ajmitch> I'm on irc most days
[04:04] <ajmitch> I just don't speak up
[04:05] <StevenK> ajmitch has nothing to say
[04:05] <ajmitch> exactly
[04:05]  * Hobbsee neither
[04:05]  * imbrandon contemplates blogging about the crypt disk image + usb key thing , since it took me 2 days of googling
[04:05] <ajmitch> so why fill the channel with inane rubbish?
[04:05] <imbrandon> ajmitch: dunno, i seem to do it quite often :)
[04:05] <imbrandon> but i still get a bit of work done too
[04:07]  * ajmitch gets more actual work done, at least
[04:07] <imbrandon> hehe yea
[04:07] <TheMuso> THe mass upload starts.
[04:08]  * persia pities the buildds
[04:08] <ajmitch> plus, not being involved with development, there usually isn't much for me to talk about in here now
[04:08] <persia> ajmitch: You could be involved in development :)
[04:08] <imbrandon> what did you give up ? noooooooooooo
[04:09] <ajmitch> I've tried
[04:10] <StevenK> You were at one point, your core-dev membership says that
[04:10] <ajmitch> yep
[04:10] <imbrandon> and DD status :)
[04:11] <StevenK> Pfeh, becoming a DD means answering a bunch of questions and waiting
[04:11] <bddebian> heh
[04:11] <imbrandon> heh
[04:12] <minghua> Mostly waiting these days, I would assume.
[04:12] <imbrandon> actualy i heard there is a bunch of new people on the NM staff
[04:12]  * persia thinks occasional sporadic bouts of question answering remain
[04:12] <imbrandon> so maybe not
[04:12] <slangasek> ScottK: sorry, should I pick on bddebian here to set things right?
[04:13] <bddebian> :'-(
[04:13] <imbrandon> save bddebian , save the world
[04:14] <bddebian> haha
[04:14] <imbrandon> i got mondays epsiode on the dvr , havent watched it yet
[04:15] <bddebian> It was fairly lame :-(
[04:15] <imbrandon> wife wont let me untill she can too :(
[04:15] <imbrandon> lol
[04:16] <imbrandon> yea season 2 hasent been near as good as season 2
[04:16] <imbrandon> err season 1$
[04:25] <RAOF> imbrandon: Sounds interesting (crypt + usb).  Feel free to blog :)
[04:27] <bddebian> Gah so many uploads I need to do for the Games Team.. It's so frustrating :-(
[04:41] <imbrandon> RAOF: i was justa bout to then i found almost exactly what i did on the wiki
[04:41] <imbrandon> https://help.ubuntu.com/community/GPGKeyOnUSBDrive
[04:41] <imbrandon> i just added my .ssh also
[04:44]  * bddebian should make StevenK do all his games team uploads.. ;-P
[04:44] <StevenK>  /ignore bddebian ALL
[04:45]  * bddebian feels loved
[04:45] <StevenK> So you shouldn't
[04:46] <persia> bddebian: Why don't you just send RFS mail to the mailing lists for that?
[04:46] <bddebian> persia: Which list, mentors or games-devel?
[04:46]  * persia points at Message-ID: <47561758.6090409@gmail.com> as a good example
[04:47] <bddebian> ??
[04:54] <persia> bddebian: Message-ID: <473A5FA3.8040106@comcast.net> (http://lists.debian.org/debian-devel-games/2007/11/msg00088.html) is also pretty good.
[04:57]  * persia wants a search engine that shows a bunch of mirrors & archives for any given Message-ID
[04:58] <bddebian> persia: Yeah and look at all the responses.. ;-P
[04:59] <persia> bddebian: Still not uploaded yet?  Seems to work for others.<4671dd0c0711191145y17447896yb9fdf0b18dfe55d6@mail.gmail.com> seemed to get sponsored in 27 minutes.  You're just unlucky :(
[05:00] <bddebian> I'm just loved :)
[05:02] <persia> bddebian: Collect all your fixes, and upload to Ubuntu, and send Utnubu a patch if you're really bothered.
[05:03] <tonyyarusso> Does anyone know of a way to sync contact information between desktop address books (Thunderbird, Evolution, etc.) and GMail?
[05:04] <persia> Isn't there a Conduit plugin for that?
[05:06] <tonyyarusso> There's one called "Google -> Email", not sure if that means contacts too though
[05:06] <tonyyarusso> And Conduit has nothing for TB yet, just evo
[05:07] <RAOF> Conduit's UI was entirely opaque to me when I tried it.
[05:07] <RAOF> Ah, C++.  For when your box has nothing better to do than spew thousands of lines of warnings for hours on end
[05:08] <persia> tonyyarusso: Hmmm..  Maybe needs some help then.  I don't think anyone every added Google support to multisync.
[05:08] <Burgundavia> TB has some nasty issues with their db
[05:09] <ScottK> Using mbox on large folders of mail has, um, inherent limitations.
[05:09] <ScottK> slangasek: It depends on how much you would enjoy it.
[05:09] <bddebian> Heyyy
[05:12] <tonyyarusso> RAOF: Agreed - it took me a while to figure out that I was supposed to drag pairs of things
[05:13] <tonyyarusso> Burgundavia: I've generally liked it, but might be open to a change.  What do you use btw?
[05:13] <RAOF> tonyyarusso: And even once you've discovered that (if you're thinking about the same "now there's an arrow connecting us" bit), it's *still* entirely non-obvious what conduit will actually *do* :)
[05:13] <tonyyarusso> TB had the initial attraction of being cross-platform, which was relevant when I dual-booted, but I haven't done that for a while
[05:14] <tonyyarusso> RAOF: hehe
[05:14] <ScottK> tonyyarusso: If you have any significant volume of stored mail, pick a client that uses maildir.
[05:15] <tonyyarusso> ScottK: err, off to wikipedia to find out which ones do I guess...
[05:15] <ScottK> tonyyarusso: Kmail for sure.  Dunno about the others.  I think evolution will if you lean that way.
[05:16] <tonyyarusso> ScottK: definitely needs to be GTK of some sort for me - I'm trying to keep myself in that realm now
[05:16] <ScottK> Well then I'm definitely not the one to give specific advice.
[05:18] <RAOF> Anyone use claws?
[05:18] <bddebian> Oh there's a wide open joke there.. :)
[05:18] <ScottK> I know norsetto did some work on it late in Gutsy.  Dunno if he actually uses it or not.
[05:19]  * Hobbsee used to use it a bit
[05:19] <tonyyarusso> ScottK: wp claims evo supports all three of mbox, maildir, and MH
[05:20] <ScottK> I'd expect it does.
[05:20] <tonyyarusso> RAOF: I tried it once at least
[05:20]  * ScottK recalls it will also support SSL V2 at least in some upgraded configs.  You'll want to avoid that.
[05:20] <Burgundavia> tonyyarusso: gmail
[05:21] <tonyyarusso> Burgundavia: Yeah, I'm actually using GMail now, but I really am not terribly fond of reading mail with web interfaces
[05:22] <tonyyarusso> ScottK: any idea where they'd put the setting for which one it uses?
[05:23] <ScottK> tonyyarusso: No idea since I've only used it once for a few days 2 years ago.
[05:23]  * ScottK only knows because there was an issue with Courier where it wouldn't support it anymore (which IMO would be a good thing), but some Evo users complained.
[05:23] <tonyyarusso> ok
[05:24] <ScottK> Evo does support SSLv3, so I imagine there's a knob for it somewhere.
[05:28] <RAOF> Woah.  The claws metapackages depend on all the plugins, rather than recommend them.  I really don't want clamav, or both spamassassin and bogofilter.
[05:30]  * persia encourages RAOF to upload a s/Depends:/Recommends:/ patch
[05:31] <RAOF> I may well do so.
[05:31] <RAOF> _Then_ I'll try claws :)
[05:33] <ScottK> RAOF: Which package depends on everything?  claws-mail doesn't seem to.
[05:34] <RAOF> claws-mail-plugins
[05:35] <RAOF> And claws-mail-extra-plugins, which has approximately infinity Depends
[05:35] <ScottK> Ah.
[05:35] <RAOF> And for some reason they appear to be all versioned.
[05:35] <RAOF> Someone's been at the crack, it seems.
[05:37] <ScottK> Since the package description says it's purpose is to install all the plugins, then it's not inherently horrible to depend on them.
[05:38] <RAOF> It could just Recommend them, now.
[05:38] <RAOF> That'll pull in all the plugins, and allow me to say that, no, I really don't want the clamav plugin.
[05:39] <RAOF> (our apt-get handles Recommends properly now, right?)
[05:39] <TheMuso> No afaik.
[05:39] <persia> RAOF: You mean, treats it like Depends unless you tell it otherwise?  Not yet.
[05:40] <persia> aptitude has a per-user configurable setting to do the right thing.
[05:40] <RAOF> Why isn't apt-get a thin wrapper script around aptitude yet?
[05:40] <persia> RAOF: Not feature compatible.  Try apt-get download or aptitude source
[05:40] <RAOF> Yeah, I know.
[05:41]  * TheMuso still uses apt-get for everything.
[05:41]  * bddebian too
[05:41] <RAOF> So, I suppose in the absense of "apt-get installs recommends by default", I suppose s/Depend:/Recommend:/ is not yet appropriate.
[05:42]  * persia advocates aptitude with a will, if insufficient justification
[05:42]  * RAOF thinks "It works better" is sufficent justification
[05:42] <TheMuso> Hell the only time I ever use GUI package management is if I need to install support for a particular video/audio codec.
[05:42] <persia> RAOF: It's on the hardy feature list: any bugs can be blamed on installing hardy early and not using an intelligent package manager.
[05:43] <persia> Further, only new users installing it for the first time will be affected, and they can manually install nay plugins they want.
[05:43] <persia> TheMuso: I use aptitude in non-curses commandline mode for > 90% of invocations.
[05:44] <RAOF> And I suppose I'll have to push this up to Debian, too.
[05:44] <persia> RAOF: For Debian, I'd wait until Recommends-by-Default is in place: there's no "You upgraded to early, feel the pain" equivalent there.
[05:44] <persia> s/to/too/
[05:45] <slangasek> persia: hmm? AFAIK Recommends-by-Default is in place in Debian, if that's what you're referring to?
[05:45]  * ScottK has tried aptitude and had trouble with it getting confused about the state of his system.
[05:45] <persia> slangasek: Excellent then :)
[05:45] <RAOF> Yeah, I thought they'd done the switch before us.
[05:46]  * ScottK only let aptitude uninstall his entire desktop once before deciding he didn't really need aptitude.
[05:46] <StevenK> Oh yeah, and Adept is *so* much better.

[05:47] <ScottK> Heh.
[05:47]  * Hobbsee hands StevenK a penalty card.  lying.
[05:47] <bddebian> hehe
[05:47] <persia> ScottK: aptitude is intelligent, but if you don't use it from the beginning, it needs some hints about what you want.  It typically does ask if it's making the right choice.
[05:47]  * ScottK gave up on Adept a long time before aptitdue.
[05:47] <ScottK> persia: I'd been using it.
[05:47]  * StevenK hands Hobbsee two penalty cards. Bad call, and failing to recognize sarcasm
[05:48] <persia> ScottK: Then it asked you if you really wanted to uninstall your desktop, and you said "Yes", and you blame aptitude?
[05:48] <ScottK> my mistake hitting Y one to many times.
[05:48] <StevenK> So aptitude isn't to blame...
[05:48]  * Hobbsee gives StevenK 3 cards, bad card, my rule, one card for sarcasm, and one for talking.
[05:48] <ScottK> But there was no packaging issue that forced it to want to.
[05:48] <StevenK> Hobbsee: I'll get you
[05:48] <Hobbsee> sure sure
[05:48] <persia> ScottK: There must have been something: if nothing else, a missing recommends, and agressive use of markauto.
[05:49] <StevenK> Actually, a penalty card can't be a bad card
[05:49] <ScottK> persia: It was a bug in aptitude, I'm pretty sure.  I've read about aptitude having some kind of package state cache that can get corrupted.
[05:50] <StevenK> ScottK: And I've never had it corrupted...
[05:50]  * ScottK find the trip to UDS to have been worthwhile just to understand what StevenK and Hobbsee are talking about right now.
[05:50] <persia> ScottK: Maybe.  I generally find aptitude wants to install everything if I try to upgrade some NBS transition before it's complete, and never otherwise.  apt-get just leaves me with symbol errors.
[05:50]  * Hobbsee taught her coworker about mao last night.
[05:50] <StevenK> ScottK: Penalty card. Taking the name of our emporer in vain
[05:50] <Hobbsee> we were discussing poker
[05:50] <persia> s/install/uninstall/
[05:51] <StevenK> Hobbsee: Penalty card. Taking the name of our emporer in vain
[05:51]  * Hobbsee hands StevenK a penalty card.  talking.  and aonther.  bad call.
[05:51] <StevenK> Hmph
[05:51] <Hobbsee> (wrong target)
[05:51]  * ScottK quietly slinks off to bed.
[05:51] <StevenK> The rule I quite like enforcing is "Penalty card. Saying PoV during a PoV."
[05:52] <StevenK> Er, PoO
[05:52] <bddebian> Gnight folks
[05:58] <slangasek> saying NPOV during a P of O
[06:10]  * StevenK kicks slangasek 
[06:12] <RAOF> I'm confused by claws-mail-extra-plugins.  Is there *any* reason for a metapackage to depend on plugin-* (>= ${binary:Version})?
[06:13] <persia> Previous version was buggy?
[06:15] <RAOF> Shouldn't that then have (>= $BUGGY_VERSION)?
[06:15] <persia> Seems less crackful
[06:17] <RAOF> I suppose someone could've pinned one of the plugins?
[06:18] <RAOF> I just don't see how it's helpful.  This metapackage is built from the same source as all the plugins, so the only thing I can see that versioning doing is breaking the package when one of the plugins conflicts with something else.
[06:23] <RAOF> So, the question is now: do I strip all the crazy (>= ${binary:Version}) from c-m-e-p or not?
[06:35] <persia> RAOF: You might check the Debian bug archive & the changelog to see if there was a reason for putting them there in the first place, but otherwise...
[06:38] <RAOF> persia: Nothing sprang out from the bugs...
[06:39] <RAOF> And nothing's obvious in the changelog.  I'll remove them.
[06:43] <RAOF> Actually, the packaging is more confusing than that, too.  The sylpheed-claws-plugin-* transitional packages have wierd versioned dependencies, too.
[06:43] <RAOF> All in all, a strange package.
[06:43] <persia> RAOF: After some thought, I seem to remember some transition happening in the past, but I can't remember the details.  I wonder if that might be related.
[06:44] <RAOF> persia: Want to check out the actual control file, see if the exact details ring a bell?
[06:46] <persia> RAOF: They wouldn't.  I'd need to poll my dpkg logs to find the dates, and check changelogs, which I can't do for around 5 hours.  On the other hand, it was long enough ago that the transition is likely no longer relevant, but you might want to compare to sylpheed-* in Dapper, just to make sure.
[06:46] <RAOF> There certainly was a transition from the sylpheed-claws-gtk2-* -> claws-mail-* naming, but I don't see why you'd want the versioning that's in the package.
[06:46] <persia> RAOF: That there was a transition was all I remembered.  Doesn't mean it was done right :)
[06:46] <RAOF> Heh.
[07:22] <pkern> SRU policy question:  if flashplugin-nonfree is broken due to MD5 mismatch (new version), would we introduce the new version, adjusting the sums?  (I don't know if there would be an alternative, though.)
[07:23] <RAOF> Yay special cases.  I *think* that's what's been done in the past, but I haven't really been paying attention before.
[07:24] <pkern> LP: #173890
[07:25] <Fujitsu> keescook: Whatever did you do to the ubuntu-cve-tracker branch? Whatever it was, it has introduced a whole lot of conflicts in my files in my branch that I've never edited...
[07:25] <Fujitsu> s/my //
[07:27] <Fujitsu> Hey \sh.
[07:28] <\sh> moins Fujitsu
[07:28] <\sh> Fujitsu, do you have powers to ack the nominations for bug #173948 ?
[07:28] <ubotu> Launchpad bug 173948 in sing "[CVE-2007-6211] sing in debian is vulnerable" [Undecided,In progress] https://launchpad.net/bugs/173948
[07:28] <Fujitsu> \sh: Probably.
[07:28]  * Fujitsu checks.
[07:29] <Fujitsu> \sh: All five releases?
[07:29] <\sh> Fujitsu, oh well, hardy is also vulnerable...if you can apply the patch for it, cool...so yes, all five
[07:30] <Fujitsu> Right, it has the same version as Gutsy.
[07:30] <Fujitsu> I'll upload it in a couple of minutes.
[07:30] <\sh> Fujitsu, just get the patch from the debian bug report...low hanging fruit ;)
[07:31] <Fujitsu> \sh: Yep.
[07:31]  * Fujitsu grumbles at Mitre not having every CVE yet.
[07:35] <paran> why are there suddenly a whole lot of packages in gutsy-updates that have changelogs for gutsy-proposed?
[07:35] <\sh> wtf...why is bug #173881 marked as fixed released?
[07:35] <ubotu> Launchpad bug 173881 in wesnoth "the option "turn_cmd" can stall a computer or maybe start another application" [Undecided,Fix released] https://launchpad.net/bugs/173881
[07:35] <persia> \sh: Hardy has 1.2.8.  Opening the other tasks now...
[07:36] <Fujitsu> paran: Because packages are now uploaded to gutsy-proposed, then copied to -updates.
[07:36] <\sh> persia, please add dapper task to it and assign it to me
[07:36] <persia> \sh: bug #173881 open for assignment
[07:36] <ubotu> Launchpad bug 173881 in wesnoth "the option "turn_cmd" can stall a computer or maybe start another application" [Undecided,Fix released] https://launchpad.net/bugs/173881
[07:36]  * Fujitsu wants a `Sync' button on LP
[07:37] <persia> Fujitsu: That just automatically requests a sync to the latest Debian version, and has all the right access control checks?
[07:37]  * \sh wants a "Please find all patches and fix package automagically" ,-)
[07:37] <Fujitsu> persia: I'd like it to actually perform the sync.
[07:38] <Fujitsu> I don't see why it shouldn't.
[07:38] <Fujitsu> \sh: That would be nice.
[07:38] <persia> Fujitsu: I thought there was supposed to be archive-admin review for some reason, but given that appropriate people could just upload, I see your point.
[07:39]  * \sh needs a coffee 
[07:39] <Fujitsu> persia: It's more dangerous to restrict it to ubuntu-archive, as people can fakesync easily and that is more damaging.
[07:40] <persia> Fujitsu: Well, anyone who can fakesync can also do a real sync, if they feel like it, we just typically delegate to the archive admins.  I agree that such a feature would be nice.
[07:41] <Fujitsu> persia: A real sync after a long waiting period and manual work by others, right.
[07:45] <pochu> ScottK: re: wesnoth backports. Gutsy doesn't have wesnoth in -backports, so there are no vulnerabilities there ;) But I can request one for it, yes. Do you think it's a good idea?
[07:46] <Fujitsu> \sh: sing/hardy uploaded.
[07:50] <\sh> Fujitsu, cool thx
[07:53] <\sh> now for CVE-2007-6111 I wonder which file they patched...epan/dissectors/packet-mpeg-audio.c or wiretap/mpeg.c
[07:55] <pkern> Fujitsu: We could also write a sync tool that syncs directly instead of requesting it.
[07:56] <persia> pkern: That breaks the (limited) archive tracking that is currently in place.
[07:56] <Fujitsu> pkern: We could, yes.
[07:56] <Fujitsu> Rather easily.
[07:56] <imbrandon> just have it change the release and upload :)
[07:56] <persia> imbrandon: Well, no, but there are ways.
[07:56] <imbrandon> persia: huh ?
[07:57] <persia> imbrandon: source package should be unmodified.  needs Origin:, etc.
[07:57] <pkern> persia: Well, if something changed in the last three months...
[07:57] <\sh> for people in the right team, we should enable this "sync" functionality in LP
[07:57] <imbrandon> persia: huh? i've changed the release and uplaoded before, should work fine
[07:57] <persia> \sh: That's exactly what Fujitsu proposed earlier :)
[07:57] <pkern> persia: Not the source package itself.  At max the dsc but I think only the changes.
[07:57] <\sh> persia, yeah, I +1 it ...
[07:57] <persia> imbrandon: That's a fakesync: please add a chancelog entry if you do that.
[07:58] <imbrandon> i d
[07:58] <imbrandon> o
[07:58] <pkern> persia: I wouldn't call it fake, except if the real sync tool does secret things to LP.
[07:58] <persia> pkern: Yes, only .changes, but it still breaks the limited tracking we have in place.  Needs a bug, and some thought.
[07:59] <imbrandon> persia: btw the , huh? was the tracking you speak of
[07:59] <pkern> pitti said that given a right tool for this job the MOTU could get the power to sync themselves after import freeze.
[07:59] <persia> pkern: "fakesync": upload to Ubuntu with no Ubuntu modifications (usually due to different orig.tar.gz, etc.).  "sync": archive inclusion of unmodified Debian package.
[08:00] <persia> pkern: Sure, it's just a matter of being sufficiently robust, and having archive-admin approval to break the tracking (or documented guidelines to preserve tracking).
[08:00] <imbrandon> the tracking you speak of ??
[08:01] <persia> imbrandon: bug tracking.  Bugs are subscribed u-a, and assigned a member of u-a.
[08:01] <imbrandon> and why does that NEED to happen ?
[08:01] <persia> (as I said, "limited")
[08:01] <persia> imbrandon: To keep track of things?
[08:01] <imbrandon> i see that as a plus it going away
[08:01] <\sh> does anyone know if the wireshark guys have an irc channel on freenode?
[08:02] <imbrandon> just skip assigning u-a and sink it yourself
[08:02] <imbrandon> everything else stays the same
[08:02] <persia> imbrandon: Why?  Wouldn't it be nice to be able to answer the question "What idiot overwrote my changes and broke the package I use every day?"
[08:02] <imbrandon> sure, look for the uploader, already possible
[08:02] <Fujitsu> \sh: /join #omgsomanysecurityflaws, perhaps.
[08:02] <\sh> Fujitsu, lol...why not
[08:03] <persia> imbrandon: Changelog entry?  Remember, unmodified source.
[08:03] <Fujitsu> persia: Set Changed-By in the .changes.
[08:03] <imbrandon> uploader, e.g who signed changes
[08:03] <Fujitsu> That seems to be what sync-source.py does.
[08:03] <persia> Fujitsu: Right.  Manual.  Needs to be documented somewhere, and u-a needs to approve others following the guideline.  Not really a big issue.
[08:04] <pkern> That's already set according to the requestor currently, so that should be trivial.
[08:04] <Fujitsu> Or give a sync button.
[08:04] <persia> pkern: Yes, trivial.  I still prefer a sync button.  Saves policy that can't easily be enforced.
[08:04] <imbrandon> really i dont see why "they" need to give aproval persia , i have noticed that before with things
[08:04] <imbrandon> documented sure
[08:04] <Fujitsu> .changes are likely to be going away in not too long, anyway.
[08:05] <pkern> Fujitsu: Yay, go for breaking Debian tools.
[08:05] <imbrandon> why ?
[08:05] <persia> imbrandon: I believe that people who currently do something should approve changes to how that thing is done, rather then people who don't do that thing.
[08:05] <imbrandon> err why going away
[08:05] <Fujitsu> pkern: Better than having the current replay attack vulnerabilities...
[08:05] <persia> Fujitsu: Why?
[08:05] <pkern> Fujitsu: They don't have a GPG cache?
[08:05] <pkern> Fujitsu: Haha.
[08:06] <imbrandon> Fujitsu: thats just nuts, we should fix the lp admins not the tool
[08:06] <imbrandon> bad bad mojo
[08:09] <\sh> argl...it really was wiretap/mpeg.c
[08:09] <\sh> s/libpcap_t/mpeg_t/
[08:10] <\sh> why don't they write good comments to their commits
[08:22] <dholbach> good morning
[08:23] <Fujitsu> Hi dholbach.
[08:23] <dholbach> hey Fujitsu
[08:24] <\sh> moins dholbach
[08:24] <siretart> slomo: good idea! help is more than welcome with updating the current quilt patches to the new version
[08:24] <dholbach> heya \sh, hey siretart
[08:24]  * siretart hugs both \sh and dholbach :)
[08:25] <dholbach> :-)
[08:26] <\sh> dholbach, push your mixes on jamendo pls ;)
[08:27] <dholbach> \sh: I'm not allowed to do that
[08:28] <\sh> dholbach, why not?
[08:54] <\sh> cool...wireshark fixed...attaching patch for gutsy now
[09:01] <asac> persia: hey :) is latest prism in revu ok - from packaging pov?
[09:02] <persia> asac: Looked great to me, but needs testing, and I don't have accounts to use those tools.
[09:03] <asac> persia: ok ... thanks for the review ... the apps are just webapps and they should work ... i tested gmail and calendar, so i think its ok
[09:04] <persia> asac: I'm just extra picky, and avoid "should work".  On the other hand, as far as I'm concerned, prism is just waiting for advocates, rather than needing real work.
[09:05] <asac> hmmm ... apparently the user-db recreation wiped my revu account
[09:06] <persia> asac: Upload something :)
[09:07] <asac> siretart: ajmitch: do i need to upload something to revu to get my revu account restored?
[09:08] <asac> (for reviewing)
[09:08] <persia> asac: It's easiest.  The DB can be frobbed, but ...
[09:08] <persia> asac: Once you have the account, it's a simple matter for one of the admins to set you "reviewer".
[09:08] <\sh> so...wesnoth in dapper is testbuilding...
[09:10] <asac> persia: i hoped that my account might still be in the DB, but just deactivated or something because i used a non @ubuntu.com email
[09:11] <persia> asac: When the accounts were recreated they were based on the latest upload to the repos.  Try your maintainer email address.
[09:11] <persia> (and use "recover" to get the PW: all passwords were reset)
[09:11] <asac> yeah ... that works better, but now i get: http://revu.tauware.de/lostpw.py?email=asac@ubuntu.com
[09:11]  * \sh is glad that he never used the @ubuntu.com address 
[09:12] <minghua> asac: If you were an MOTU when the DB was reset, your account should have been recreated, using your usual upload address.
[09:12] <persia> asac: With no text?  Odd.  I don't have my keys handy, but if you can't get someone else to sort it in the next 2 hours, I'll be able to fix it then (but I might need an upload).
[09:13] <asac> persia: ok lets wait a bit ... maybe I get an idea what I could upload :)
[09:15] <persia> asac: If you can't think of anything else, hello is always handy :)
[09:16] <huats> morning MOTU world
[09:17] <\sh> moins huats
[09:17] <huats> hey \sh
[09:29]  * TheMuso votes that those who have handled mass transitions in the past, should not be required to do so in the near future. So for me, this is the only transition I'm doing for a long while. :p
[09:30] <dholbach> :)
[09:30] <\sh> TheMuso, damn...you spammed my -changes list, thx for that :)
[09:30] <TheMuso> Someone had to do it.
[09:30] <TheMuso> and pitti suggested it should be scripted...
[09:31] <TheMuso> So, while I could have staggered somewat more, it would have to be done at some point.
[09:31] <imbrandon> fixes are always a good hting
[09:31] <imbrandon> thing*
[09:32] <geser> morning
[09:32] <\sh> woosaaa ... dapper wesnoth done
[09:36] <\sh> hmmm
[09:36] <\sh> mitre is down?
[09:36] <Fujitsu> \sh: Wouldn't be the first time.
[09:36] <Fujitsu> But WFM.
[09:37] <\sh> damn...I just wanted to fix the last bugs for cacti
[09:37] <Fujitsu> Oh, cve.mitre.org is down.
[09:37] <Fujitsu> Has cacti.net recovered yet?
[09:37] <\sh> Fujitsu, yepp
[09:37] <jonnymind> Hello; I am preparing a packege, but need little push in the right direction.
[09:38] <\sh> well...time for a coffee and a cigarette
[09:39] <persia> jonnymind: More context is good.
[09:39] <jonnymind> Is there any example around about building more than one binary package from a source package?
[09:41] <jonnymind> I.e. I have a source from which I generate an "engine" solib, binary files and -dev package.
[09:41] <persia> jonnymind: Most of the library packages are reasonable examples, but https://wiki.ubuntu.com/PackagingGuide/Lists/DocumentationResources has a link to the overview on the Debian wiki.,
[09:41] <persia> jonnymind: You may also find the Library Packaging Guide, in that same list, useful.
[09:42] <jonnymind> Ok, thank you, that was the info I was searching for.
[09:42] <jonnymind> (you know, at times finding the root of an information tree is kinda difficult in Internet having only word-oriented S.E. at disposal :-)
[09:43] <persia> jonnymind: https://wiki.ubuntu.com/MOTU/Contributing should be a reasonable root when getting started.
[09:44] <persia> https://wiki.ubuntu.com/UbuntuDevelopment/ is intended as the root for our processes in general.
[09:44] <jonnymind> I see. Thanks.
[09:54] <jonnymind> Ok, I am on my way now. I'll be back soon in search for help.
[09:54] <jonnymind> :-) later.
[10:02] <minghua> Hmm, Debian's python-numpy is having big changes.
[10:07] <kagou> Hi
[10:36] <\sh> how can someone merge bugs on LP?
[10:36] <StevenK> Mark as duplicate?
[10:36] <\sh> nope...it's not a dupe...
[10:37] <StevenK> Then why merge them?
[10:37] <\sh> one package, 4 releases, 3 bugs ... for 2 releases those three bugs are still valid and fixed in the last bug...
[10:38] <\sh> still haven't a good CVE tracking in LP those bugs are really bad
[10:47] <Amaranth> \sh: That doesn't make sense, if they're not dupes they shouldn't be merged
[10:47] <Amaranth> That's what dupe is for
[10:49] <Fujitsu> Amaranth: Security bugs are somewhat special at the moment.
[10:49] <white> Amaranth: who cares about security?
[10:49] <Fujitsu> They often cover a multitude of issues, and there can be a multitude of multiple-issue bugs.
[10:49] <Fujitsu> Hey white.
[10:49] <white> Fujitsu: :)
[10:49] <Amaranth> white: Not me
[10:50] <white> Fujitsu: time to review some php crap, i'd like to have a second opinion
[10:50] <Amaranth> My code doesn't have any (known) security problems :P
[10:50] <Fujitsu> white: Ewww, but OK.
[10:50] <\sh> oh.../me goes to lunch...PHP crap makes me ill ,-)
[10:50]  * Fujitsu unfortunately spends much of his time at work on a PHP monstrosity.
[10:50] <white> poor thing
[10:50] <StevenK> Fujitsu: You lose
[10:51] <white> Fujitsu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448690
[10:51] <ubotu> Debian bug 448690 in sitebar "CVE-2007-5695: possible security problem" [Normal,Open]
[10:51] <white> nmu patch is attached there
[10:51] <white> that damn sitebar thing was annyoing me for too long in the tracker
[10:51] <Fujitsu> It is shocking security-wise (I inherited it), and it looks like it will be replaced soon.
[10:51] <Fujitsu> Argh, not sitebar...
[10:51] <white> :)
[10:52] <Fujitsu> (the webapp is fortunately hidden behind Apache authentication, and only trustworthy people have access...)
[10:52] <white> i was not getting a lot of information out of all the CVEs, but i hope i got the main things
[10:52] <white> i personally do not see the holes in the translator module as a major problem, but it was in the tracker for too long and nobody is picking it up :/
[10:53] <Fujitsu> white: Ergh, it looks evil.
[10:53] <white> it's php
[10:53] <StevenK> Fujitsu: "Trustworthy" ?
[10:54] <Fujitsu> StevenK: Colleagues who aren't likely to be doing anything evil. The company is small enough that they all have access to the server on which it resides if they need it, anyway.
[10:55] <StevenK> Fujitsu: Yes, but one thing you need to learn is they are users. And users aren't to be trusted.
[10:57] <Fujitsu> They can do much more evil things than exploit potential security issues in said application.
[10:57] <white> StevenK: you need to let love in and trust and stuff
[10:57] <white> StevenK: we are leaving in a world full of harmony ;)
[10:57] <Fujitsu> Heh.
[10:57] <StevenK> white: I've been a sysadmin too long for that.
[10:57]  * StevenK twitches
[10:58] <Fujitsu> I'd like to fix the issues, but there are too many of them and many are enormous architectural flaws.
[10:58] <StevenK> The first being "It's PHP" ?
[10:58] <Fujitsu> That being one, yes.
[10:58] <white> Fujitsu: i'll go offline for a few hours now, please tell me your report and opinion of the patch, i'd like to get that damn app out of our todo list (at least for now)
[10:59] <Fujitsu> white: Yep, I'm looking at it.
[10:59] <Fujitsu> See you later.
[10:59]  * StevenK tells his mail server to hurry up.
[11:01] <Fujitsu> I guess I can thank my predecessor for one thing: not requiring register_globals.
[11:02] <geser> is it possible to use a patch system to fix an error in a python script which gets called in clean?
[11:03] <StevenK> Fujitsu: Oooh. Wow, a PHP "coder" who doesn't use register_globals. I think there is a pedestal around here somewhere for him.
[11:04] <Fujitsu> StevenK: Heh.
[11:06] <Fujitsu> <3 PHP
[11:06] <Fujitsu> I'm not encouraged by the number of WordPress and phpMyAdmin CVEs which mention that it is debateable whether it is a PHP or $APP bug.
[11:07] <kkubasik> hey, does anyone know if hardy's mono is screwed in some really horrible way?
[11:07] <Fujitsu> It's hardy, so it might well be.
[11:08] <kkubasik> hmmm.. is there a chance that the build server is out of date?
[11:08] <Fujitsu> Build server?
[11:08] <kkubasik> you know waht, gimme 1 sec to give you the build log
[11:08] <kkubasik> ppa
[11:09] <kkubasik> scratch that, its only happening on amd64
[11:09] <kkubasik> sorry to bother!
[11:23] <seb128> hi
[11:23] <seb128> is Jérôme Guelfucci <jerome.guelfucci@gmail.com> connect on IRC?
[11:24] <Fujitsu> seb128: jeromeg is his nick, but he's not here at the moment...
[11:24] <seb128> ok
[11:24] <seb128> could anybody tell him to send his claws-mail-extra-plugins ftbfs fix to debian so the package can still be synced?
[11:25] <seb128> I'll comment on the bug
[11:26] <StevenK> Ooh yes.
[11:27] <Fujitsu> StevenK: What now?
[11:27]  * StevenK downloads Nine Inch Nails - Y34RZ3R0R3MIX3D
[11:27] <Fujitsu> O_o
[11:28] <StevenK> Fujitsu: The previous NIN album is "Year Zero", this is a bunch of remixes
[11:29]  * StevenK listens to songs from Therion - Lemuria as they download. Oh, how I missed thee
[11:36] <pgquiles> I want debuild to ignore the .svn directories. What's wrong with "debuild -S -sa --dpkg-source-hook=-I.svn"? (according to the manpage, that should work but debuild says "unknown dpkg-buildpackage/debuild option: --dpkg-source-hook=-I.svn")
[11:36] <azeem> pgquiles: did you try just -isvn?
[11:38] <pgquiles> azeem: thank you, that works fine
[11:38] <soren> pgquiles: dpkg-source-hook is not for passing options to dpkg-source. It's for passing names of scripts, you'd like to get called.
[11:39] <pgquiles> soren: oh, thanks
[11:41] <soren> pgquiles: debuild provides a way to call scripts at various points in the build process to do various things. I for instance had a script at one point that would automatically extract any changes I had accidentally done directly to the source and put it in a patch file.
[11:42]  * Hobbsee waves
[11:43] <Fujitsu> Hi Hobbsee.
[11:43] <Hobbsee> :)
[11:44] <seb128> Hobbsee: hey there :-P
[11:44] <Hobbsee> :P
[11:44] <Hobbsee> hey #3 back
[11:49] <gaspa> txwikinger: ping
[12:26] <\sh> fixing rsync
[12:36] <ScottK> pochu: I've no opinion on Wesnoth in backports.
[12:37] <pochu> Ok, so backporting it to -edgy and -feisty should be enough.
[12:37] <\sh> ScottK, pochu : leave it like it is...there is no harm...the security fixes will be uploaded in no time
[12:37] <\sh> only for those where backports were requested in the past, there should be a new backport of the secfixed version
[12:38] <pochu> \sh: that's what we are talking about :-) -edgy has 1.2.3 and -feisty has 1.2.6 in backports
[12:38] <ScottK> \sh: Agreed.
[12:38] <pochu> So they need to be updated too.
[12:39]  * ScottK was trying to discuss generally how one should handle it yesterday.
[12:39] <\sh> pochu, but as I said yesterday, please wait until the 6102 fix is uploaded to the pockets..
[12:40] <\sh> (gutsy,feisty) that is...
[12:40] <\sh> do we have stats how many people are using -backports actively?
[12:42] <ScottK> \sh: No, but we do know that when we upload broken stuff there people notice, so it's used.
[12:43] <ScottK> \sh: In general I'd say more people will use current release + backports than use the development release.
[12:43] <ScottK> I base that on broken stuff getting uploaded and then backported and no one noticed it was broken until it was already backported.
[12:48] <pochu> \sh: I was thinking in backporting 1.2.8. But we can backport from -security instead of hardy too. I don't care.
[12:49] <\sh> pochu, as I said, we don't backport from hardy...only -backports for gutsy is coming from hardy
[12:49] <ScottK> \sh: Why not?
[12:50] <ScottK> \sh: That's normally now I would do it.
[12:50] <\sh> ScottK, so you mean, we can backport from latest development to oldest release?
[12:50] <ScottK> \sh: If it actually works, yes.  Have a look at postfix in dapper-backports.
[12:51] <ScottK> That was taken from Gutsy just before the Gutsy release.
[12:51] <\sh> ScottK, and it gets all security fixes from gutsy automatically?
[12:52] <ScottK> \sh: The version in Hardy is fixed already?
[12:52] <ScottK> I'm not sure I understand the question?
[12:52] <\sh> ScottK, when someone is pushing gutsies version to dapper, and gutsies version is buggy, it needs to get all fixes from gutsy later on for dapper-backports...right?
[12:53] <\sh> ScottK, if it doesn't do it automatically this would be a nightmare...
[12:53] <ScottK> It doesn't do it automatically.
[12:53] <\sh> ScottK, and that's really a problem
[12:53] <ScottK> It can be.
[12:54] <ScottK> Generally the solution is to fix the development release and backport again.
[12:54] <ScottK> Once something has been tested for a backport, doing the actual backport is not very hard.
[12:55] <\sh> ScottK, when backports became official, we had the deal that only from devel release to devel-1 release can be backported, but not from devel release to devel-3
[12:55] <\sh> means, that we could backport from edgy to dapper, but not from feisty to dapper
[12:55] <ScottK> \sh: I see.  That's before my time, but particularly with an LTS release, we've been taking stuff as far back as it would go if it was requested.
[12:56] <ScottK> Almost all of the multi-release backports are to Dapper.  I think for LTS is needs to be a bit different.
[12:57] <\sh> ScottK, tbh, that's the worst crack I can think of...all those hip hobby admins are using backports, getting vulnerable software, and no one is there who deals with unsupported backports
[12:58] <\sh> to make them secure
[12:58] <Hobbsee> backports are crack.  this is known
[12:58] <\sh> ScottK, we can do also source-changed backports nowadays, right?
[12:59] <Hobbsee> as they're done by jdong and cronies.
[12:59] <Hobbsee> !jdong
 jdong: yes, but you're FULL OF CRACK!
[12:59] <ScottK> \sh: We can although we try to minimize them.
[12:59] <ScottK> Making something secure would definitely be a good reason.
[12:59] <\sh> -EAPOCALYPSENOW
[13:01] <ScottK> Hobbsee: While I would agree they have risks, I think they've calmed down a bit.
[13:01] <ScottK> For something like clamav, we'd be dead without backports.
[13:02] <\sh> ScottK, right, there are special cases
[13:02] <\sh> well, let's break dapper...requesting a backport of latest wireshark in hardy...and most of the dapper network people are doomed
[13:03] <ScottK> \sh: Please test it before you do.
[13:03] <\sh> ScottK, this is something I will never do
[13:03] <ScottK> \sh: Test or backport wireshark?
[13:03] <\sh> ScottK, but there are others, who could and are able to
[13:04] <ScottK> OK
[13:04] <ScottK> Testing is generally where the choke point is in backports.
[13:05] <ScottK> jdong was going to find some more people to do testing, but I haven't seen much in the way of results yet.
[13:05] <\sh> ScottK, as I said, it would all make sense, _if_ there are people who are 100% responsible for this...and _if_ those people are taking care about the latest bugfixes to automatically do the backports
[13:06] <ScottK> \sh: Well I will tell you that for stuff I've requested backports for, I to look after them too.
[13:06] <\sh> ScottK, is there a list, where I can see, from which version the -backports version is coming from?
[13:06] <ScottK> \sh: Usually you can see from the publishing history.  Let me find a good example.
[13:08] <ScottK> \sh: If you look at Postfix, https://edge.launchpad.net/ubuntu/+source/postfix you can see that the versions in Feisty and Dapper came from Gutsy.
[13:09] <ScottK> As it happens there was one Postfix upload to Gutsy after we backported it, but that would've broken on Dapper (no libdb4.5), so it's just as well.
[13:10] <\sh> ScottK, dapper is still suported, when gutsy is out of support, or?
[13:10] <ScottK> For server stuff, yes.
[13:11] <\sh> ScottK, so, if no one ever do something new for postfix on backports, we don't see it on the list anymore, right?
[13:11] <ScottK> We'll be able to backport the Hardy version of Postfix to Dapper with just one change.
[13:12] <ScottK> \sh: I think you bring up a good point that unsupported versions after an LTS release should probably stay in LP.
[13:12] <ScottK> I doubt anyone has thought of this.
[13:12] <\sh> na...this shouldn't matter...I would like a list where you can see: <pkgname> <latest version in backports> <from release> <to release>
[13:13] <\sh> so someone who is not dealing with backports, but is a motu, is able to see easily which backports needs some love...
[13:14]  * \sh is too stupid to patch rsync...
[13:15] <\sh> what breaks the rsyncd.conf.5 man page
[13:15] <ScottK> \sh: That makes sense.  Maybe someone will script something up.
[13:22] <dcordero> hi
[13:28] <ScottK> Hello dcordero
[13:31] <\sh> hmm....what is the replacement of inittab today in ubuntu?
[13:31] <\sh> where do I set the default runlevel?
[13:31] <stdin> files in /etc/event.d/
[13:32] <\sh> well /etc/event.d/rc-default guesses what the default is...and when I read it correctly it's always runlevel 2, right?
[13:32] <stdin> yeah
[13:33] <stdin> it reads /etc/inittab if it's there and can choose the default from that, but it defaults to 2
[13:35] <\sh> stdin, yepp
[13:35] <dcordero> one question about Revu. i have uploaded a package to revu system and i have check that there are errors in my package. I've fix that errors and i have upload again with dput -f but i cant see the new version on revu. I uploaded it arround 1 hour
[13:36] <ScottK> dcordero: What package?
[13:36] <dcordero> ninvaders
[13:37] <ScottK> When you uploaded it, what did dput tell you?
[13:37] <dcordero> uploaded
[13:37] <ScottK> OK.
[13:37] <dcordero> told me that the package was sucesfully uploaded
[13:38] <dcordero> http://revu.tauware.de/details.py?package=ninvaders-0.1.1
[13:38] <dcordero> this was my first upload
[13:39] <ScottK> It looks like you'll need a revu admin to have a look.
[13:42] <DaveMorri1> dcordero: you notice the lintian error with your uploaded package?
[13:42] <ScottK> DaveMorri1: Lintian doesn't run when you upload, so I'm not sure what you're asking.
[13:43] <dcordero> yep, i have fixed all the lintian error and now can be build perfectly with pbuilder, that first upload was only for try revu system
[13:46] <dcordero> now, that i have a new version that i think that is ok, i'd like to upload it for check if it's surely fine. But dont work :/
[13:49] <DaveMorri1> http://revu.tauware.de/revu1-incoming/ninvaders-0.1.1-0712041110/lintian
[13:49] <DaveMorri1> ScottK: ^^
[13:49] <ScottK> DaveMorri1: Ah.  I misread with as when.
[13:49] <ScottK> Sorry about that.
[13:49] <DaveMorri1> np
[13:51] <dcordero> maybe have i change some version number in the package for revu understand it as a new version?
[13:51] <DaveMorri1> nope, just reupload it
[13:53] <dcordero> so, i'll try to upload it again
[13:55] <ScottK> dcordero: If uploading it again doesn't work, Hobbsee may be able to help you (Hobbsee: dcordero has a vanishing upload problem on REVU).
[13:56] <ScottK> or not.
[14:05] <dcordero> i think that maybe i know where is the problem
[14:06] <dcordero> the documentation say ->  dput revu package_version_source.changes
[14:06] <dcordero> but my changes files is named ninvaders-0.1.1_3-1_i386.changes
[14:06] <dcordero> without source. ¿?
[14:10] <\sh> dcordero, you need a source.changes...which you get when you do a debuild -S -sa e.g.
[14:11] <\sh> and i386.changes is for binary uploads...which we don't do
[14:12] <dcordero> pff i am stupid, all the morning with that stupid error
[14:22] <rocco> hey guys
[14:22] <rocco> anyone had a problem using a usb keyboard with the gutsy install cd?
[14:25] <ScottK> rocco: This isn't a support channel, try #ubuntu (but no, I haven't).
[14:25] <rocco> sorry I'm cbx33
[14:25] <rocco> just popping in at work
[14:37] <white> Fujitsu: ?
[14:37] <white> Fujitsu: don't go to bed yet ;)
[14:38] <dcordero> is early, 15:38 here :)
[14:54] <DaveMorri1> norsetto: I've made those changes, thanks for revu it this morning
[14:55] <norsetto> DaveMorri1: np, I also added those to revu now that is back
[14:55] <DaveMorri1> yeah I noticed,  now I see why you need 2 revu's since people miss things
[14:56] <norsetto> DaveMorri1: does the test result makes sense to you? I didn't check it myself
[14:56] <DaveMorri1> yeah, as it's an example of it failing on things as well as pasing
[14:56] <DaveMorri1> showing the user what can be done with it
[14:58] <mruiz> hi all
[14:59] <mruiz> dholbach, are you busy at the moment ?
[14:59] <dholbach> mruiz: yeah... is there anything I can help you with?
[14:59] <norsetto> dholbach: (hi)
[14:59] <dholbach> hey norsetto
[15:00]  * dholbach hugs mruiz and norsetto
[15:00] <dholbach> how are you doing?
[15:00]  * mruiz hugs dholbach 
[15:01] <mruiz> dholbach, as I wrote you I want to know about your availability to continue as my mentor :-)
[15:01] <dholbach> I haven't forgotten the email :)
[15:02] <mruiz> dholbach, sure
[15:03] <bddebian> Heya folks
[15:04] <pochu> waves
[15:04] <bddebian> Hi pochu
[15:07] <geser> Hi bddebian
[15:09] <norsetto_> DaveMorri1: I think you still have README in docs?
[15:09] <bddebian> Heya geser
[15:09] <DaveMorri1> oh yeah, I didn't see it when I scanned through, let me fix it quickly
[15:14] <norsetto> dholbach: sorry daniel, I can't keep a stable wireless for more than few seconds
[15:15] <dholbach> norsetto: I'm sorry to hear that - do you have wired connection at home?
[15:15] <norsetto> dholbach: yes, but I have to keep the wireless on since my wife needs it for her portable
[15:16] <dholbach> norsetto: and it breaks for her too?
[15:16]  * DaveMorri1 sends norsetto's wife a 10M cat5 cable
[15:17] <norsetto> there we go again
[15:18] <norsetto> dholbach: not at all, its just these new ralink modules which are bogus
[15:19] <dholbach> arg :-/
[15:22] <soren> Yeah, we should probably give everyone who's stuck with the ralink drivers their money back. :-/
[15:24] <Wybiral> Hello everyone! Does anyone know why PyODE has TriMesh disabled in gutsy? Or a portable way to solve it? https://launchpad.net/ubuntu/+source/pyode
[15:25] <ScottK> Wybiral: The why is "Since libode 0.7 shipped within Debian is without trimesh support, trimesh     support disabled for building pyode"
[15:27] <ScottK> Wybiral: It looks like it's been changed in Hardy.
[15:27] <ScottK> To solve it for Gutsy you'd need the newer libode too.
[15:28] <Wybiral> OK cool. So the only solution for gutsy would be to build it all from source?
[15:28] <white> Fujitsu: sleepy ;)
[15:29] <Hobbsee> mmmm...sleep
[15:29]  * Hobbsee expects Fujitsu went to sleep long ago
[15:31] <ScottK> Wybiral: Or grab the source packages from Hardy and build those locally (that's what I'd do).
[15:31] <Wybiral> OK. Thanks a bunch ScottK!
[15:35] <joejaxx> i just got the funniest kde4 ktip on startup
[15:55] <soren> mok0: Just read your mailing list post..
[15:56] <soren> mok0: "head -1 debian/changelog | sed -e 's/.*(\(.*:\)\?\(.*\)\(-[^-]*\)\?).*/\2/g'" pretty much does the trick, doesn't it?
[15:57] <soren> Er... no.
[15:57] <soren> :)
[16:00] <soren> head -1 debian/changelog | sed -e 's/.*(\(.*\)).*/\1/g' -e 's/.*://' -e 's/-[^-]*$//'
[16:00] <soren> That should do it. Just one sed call.
[16:01] <mok0> soren: :)
[16:01] <dholbach> what I feel, when I look at things like that is "we need more juicy python love everywhere"
[16:01] <mok0> soren: yes, but you're using a pipe
[16:01] <soren> mok0: Ah, no problem.
[16:01] <mok0> soren: that was the challenge :)
[16:02] <dholbach> on the day where we have    #!/usr/bin/python    at the top of debian/rules files, I'm happy
[16:02] <soren> sed sed -n -e '1 s/.*(\(.*\)).*/\1/g' -e '1 s/.*://' -e '1 s/-[^-]*$//' -e '1 p' debian/changelog -e 's/.*(\(.*\)).*/\1/g' -e 's/.*://' -e 's/-[^-]*$//'
[16:02] <soren> Erk, that went wrong.
[16:02] <soren> sed -n -e '1 s/.*(\(.*\)).*/\1/g' -e '1 s/.*://' -e '1 s/-[^-]*$//' -e '1 p' debian/changelog
[16:02] <soren> There you go.
[16:03] <soren> No pipes, only sweet, sweet sed love. :)
[16:03] <mok0> dholbach: funny you should mention it: https://blueprints.edge.launchpad.net/ubuntu/+spec/pyhelper
[16:03] <soren> dholbach: You can do that, actually.
[16:03] <mok0> soren: that's a long and ugly sed expression
[16:03] <soren> dholbach: Erh, no, sorry, that was changed at some point.
[16:04] <soren> mok0: I think it's rather pretty, actually. :) YMMV
[16:04] <dholbach> mok0: you should get in touch with mvo about it - he has some really good ideas
[16:04] <dholbach> it'd make the world a better place
[16:04] <mok0> dholbach: I haven't met mto, come here often?
[16:04] <soren> dholbach: At some point, I belive the Debian policy said that debian/rules just had to be an executable that accepted certain arguments (build, binary-arch, etc.)
[16:04] <dholbach> mok0: mvo, he's in #ubuntu-devel
[16:05] <dholbach> soren: ah ok
[16:05] <soren> dholbach: It was at some point changed to say that it actually had to be a make file :(
[16:05] <mok0> debian rules is utter and complete {a,mis}use of make
[16:06] <mok0> doesn
[16:06] <soren> mok0: Indeed, some people make it so.
[16:06] <mok0> t make use of make's powers at all. It's basically just used as a wrapper for a shell script. Yuc.
[16:07] <mok0> make is for dependency checking and compiling files that have changed
[16:07] <mok0> Now you got me started :-)
[16:08] <mok0> IMHO any executable that could handle to be called by dpkg-' like "rules install" etc should be acceptable
[16:09] <soren> mok0: Agreed.
[16:09] <soren> mok0: I've been meaning to bring it up on debian-devel, but I haven't found sufficient motivation yet.
[16:09] <dholbach> We'll fork the policy then! More developers by 'fixing' debian/rules!
[16:09] <mok0> Strangely, I just filed a blueprint at LP last night. I have been thinking about it for some time
[16:09] <soren> mok0: About this?
[16:09] <mok0> dholbach: Yeah! :-)
[16:10] <mok0> soren: writing a python module that would handle everything in rules
[16:10] <mok0> and debhelper
[16:10] <soren> cdbs.py? :)
[16:11] <mok0> soren: yeah, I guess :-)
[16:11] <soren> Well, if just we could get the policy relaxed a bit (just like you said a minute ago), that would be completely feasible.
[16:12] <soren> I like debian/rules to be makefiles, though. I just don't see any point forcing it on people, when there's really no technical reason to do so.
[16:12] <mok0> soren: I think if we come up with a really good alternative, it would not be a problem... at least it shouldn't
[16:13] <broonie> There was a discussion about this in debian sometime within the past year.
[16:13] <mok0> soren: as long as it can be any executable script, it wouldn't matter
[16:13] <soren> broonie: Did Ian perhaps bring it up?
[16:13] <soren> mok0: Precisely.
[16:13] <soren> broonie: I discussed it with him in July.
[16:13] <broonie> Can't remember who it was.
[16:14] <soren> broonie: We went ballistic when he saw that it now explicitly said it had to be a makefile, so he might very well have brought it up somehwere.
[16:14] <soren> broonie: Er... "*He* went ballistic"
[16:14] <mok0> Well, talking can be counter productive. People tend to paint themselves into a corner from principles. It is much better to have something concrete to discuss
[16:15] <soren> mok0: Yeah, an actual patch for the policy should get the juices going.
[16:15] <broonie> IIRC it was a patch to policy that someone proposed.
[16:16] <mok0> soren: "We have this new system, it works really well, is flexible and users like it. You can try it and see what you think. Can we patch the policy??"
[16:16] <soren> mok0: Nono..
[16:16] <mok0> soren: whatever. I'm not into politics anyway
[16:17] <broonie> Ah, yes. Bug 423564 and associated discussion on -policy/-devel - it was Ian who raised it.
[16:17] <soren> mok0: Don't do that right away. You just start by suggesting that the requirement for debian/rules to be a makefile is absurd and pointless. When everyone has agreed (yeah, right), you bring on the crack.
[16:17]  * soren wanders off for a short break
[16:17] <mok0> soren: I'd think you should leave all the doors open, and not insult those who really like make
[16:18] <effie_jayx> how do I know if tzdata got sycn recently
[16:18] <broonie> soren: See that policy bug and the mailing list dicussions first, though.
[16:19] <mok0> soren: but perhaps Debian folks associate Python with Ubuntu and thus hates everything Python in the workflow?
[16:19] <\sh> time to go home....
[16:34] <soren> mok0: I'm not saying using makefiles is absurd. I'm saying it's absurd to require them to be makefiles.
[16:35] <mok0> soren: I agree.
[16:35] <mok0> soren: I fully respect the design choice to use the existing tools
[16:35] <soren> mok0: It's good to see another Dane being active in here, by the way :)
[16:35] <mok0> Hæ, ja, hvor er du fra?
[16:36] <mok0> (switch back to english now)
[16:36] <soren> Aalborg. Eller faktisk Nørresundby.
[16:36] <mok0> Are you doing this as a part of your work?
[16:36]  * MenZa aer mok0
[16:37] <mok0> Hej MenZa
[16:37] <MenZa> Halløj :)
[16:37] <soren> mok0: This is my job, yes.
[16:37] <mok0> soren: are you working for Canonical?
[16:37] <MenZa> mok0, hvorfor er du ikke i #ubuntu-dk :(?
[16:37] <soren> I am.
[16:38] <mok0> MenZa: (I will stick to english due to etiquette) I have the impression that most of that work is translation, and it doesn
[16:38] <mok0> t interest me that much
[16:38] <MenZa> #ubuntu-dk isn't work; #ubuntu-dk is a community. :)
[16:39] <mok0> MenZa: When is a good time to visit there? Evenings?
[16:39] <MenZa> Whenever. :)
[16:39] <MenZa> soren's there, too
[16:39] <MenZa> We were recently approved as an official LoCo team.
[16:39] <mok0> MenZa: OK, you've got me convinced, I'll show up :-)
[16:39] <MenZa> Great, mok0!
[16:40] <mok0> MenZa: ... LoCo.. isn't that translation & such?
[16:40] <MenZa> LoCo = Local Community. :)
[16:40] <mok0> MenZa: Ah
[16:40] <MenZa> You're thinking of l10n; localisation.
[16:40] <MenZa> (or i18n, internationalisation)
[16:40] <mok0> MenZa: Yeah, I guess
[16:40] <MenZa> :)
[16:41] <mok0> Where are you at, MenZa? I'm in Århus
[16:42]  * mok0 hopes MenZa has nothing to do with that boring club of boneheads known as "mensa"..
[16:43] <slangasek> mok0: the insistence on make for debian/rules has nothing to do with python, it has to do with wanting to be able to use features of make to detect support for various tentative, new features of policy, and with wanting to define a particular baseline for what a developer needs to know to understand how any package in the archive is being built
[16:44] <mok0> slangasek: What features are you referring to?
[16:44] <mdomsch> Well, now I know why my package builds for gutsy aren't picking up dpkg triggers
[16:44] <mdomsch> http://pastebin.domsch.com/17
[16:44] <slangasek> mok0: detecting make targets in order to handle build-depends better on buildds
[16:44] <mdomsch> gutsy dpkg knows about triggers, but gutsy dh_installdeb doesn't :-(
[16:45] <mok0> slangasek: That's a noble goal. But I don't see why that puts a limitation on debian/rules
[16:45] <MenZa> mok0, Kolding. :)
[16:46] <mok0> slangasek: you can still have make driving the buildds
[16:46] <slangasek> mok0: er, you don't understand.  how are you going to use make to detect the presence of support for a particular make target in a package, if debian/rules isn't a makefile?
[16:47] <mok0> slangasek: I'd think you could extract the build-deps from debian/control
[16:48] <\sh> lalalala
[16:48] <\sh> I have a new job ....
[16:48] <mok0> slangasek: You're probably right, I will have to study the new ideas before making comments
[16:49] <geser> \sh: that went fast
[16:49] <Riddell> any cdbs experts know a target that would run some code after `make install` but before dh_install etc?
[16:49] <slangasek> mok0: this is discussed extensively on debian-devel about 4-5 months back (with a subject line of something about "dpkg" or "build-depends-indep"); I would encourage you to read the archive to understand the issue
[16:49] <mok0> slangasek: you must be talking about a completely new set of targets
[16:49] <mok0> slangasek: Thanks, I will look it up.
[16:50] <mok0> slangasek: Of course, dependency checking can be implemented in a Python based rules system. Scons does it
[16:50] <slangasek> mok0: yes, it's about wanting to be able to transition builds to use the optional build-arch target, which the buildds can't rely on being present during a transitional period
[16:51] <slangasek> this is not about "dependency checking"
[16:51] <mok0> slangasek: got it
[16:52] <slangasek> this is about "reliably detecting whether a package supports a target of a particular name, so that we know whether a package fails to build because it's broken, or whether it fails to build because it doesn't support the new target"
[16:52] <slangasek> also, "scons == eew"
[16:52] <mok0> slangasek: I am not familiar with how the buildds works
[16:52]  * mok0 agrees
[16:53] <mok0> slangasek: Perhaps I'm being insistant , but I maintain that it would be possible to design a tool better suited for the purpose.
[16:54] <azeem> slangasek: but waf is python as well!
[16:55] <mok0> azeem: waf?
[16:56] <leonel> ScottK: hello !  long time  no talk ..   new  Squirrelmail Version  only bugfixes  no CVE's
[16:56] <\sh> geser, yeah had luckk...and now home :)
[16:57] <soren> Riddell: I think that's binary-install/foo ?
[16:57] <Riddell> soren: yeah, but this is something which affects all the binary packages not just one at a time
[16:58] <DaveMorri1> you tried binary-install:: ?
[16:58] <mok0> slangasek: I will draft an interface, anyways, then people can look at it, comment & criticize
[16:58] <soren> Riddell: Hm...
[17:00] <gurthang> super
[17:00] <soren> Riddell: common-binary-post-install-arch ?
[17:00] <soren> Riddell: No, that won't work.
[17:02] <gurthang> riddell has a riddle
[17:02] <gurthang> like bilbo or gollum
[17:06] <soren> Riddell: common-post-build ?
[17:09] <Riddell> I've a feeling I tried that one soren, let me try again
[17:10]  * RainCT wonders wheter stuff in http://qa.ubuntuwire.com/uehs/no_watch.php should be fixed or just left for the Debian maintainers?
[17:12] <soren> Riddell: Someone should make the order in which these targets get invoked more explicit for the most common cases (e.g. debhelper + autotools)
[17:13] <keescook> Fujitsu: yeah, I'm not sure why that is.  we switched to the "bound" branch for the "master", and something may have gotten confused.  Hopefully it'll only be with "past" stuff.  (I suspect it decided jdstrand's was the master, and got confused about my past merges with you)
[17:13] <Riddell> soren: exactly what I've been thinking for the last couple of hours
[17:14] <soren> Riddell: So how is that coming along? :)
[17:14] <Riddell> soren: not looking good, it's passed the point where it needs to be run
[17:15] <soren> Riddell: I meant writing that document :)
[17:17] <Riddell> soren: that seems only to run it after installing the indep packages
[17:17] <Riddell> mm, I don't think I'm the best person to be documenting cdbs much as I'd love for there to be better docs
[17:20] <soren> Riddell: binary-install/(name of first package) will get called first, though. :)
[17:21] <Riddell> soren: good plan
[17:21] <Riddell> if inelegant
[17:21] <soren> Riddell: This is probably better:
[17:22] <soren> $(patsubst %,binary-install/%,$(DEB_ALL_PACKAGES)) :: common-binary-install
[17:22] <soren>  
[17:22] <soren> common-binary-install:
[17:22] <soren>     Do stuff
[17:22] <Riddell> won't that run it once for each package?
[17:22] <soren>    touch common-binary-install
[17:22] <soren> Not if you touch a file called common-binary-install and don't declare it .PHONY
[17:23] <soren> cdbs ought to have a target like that, though, but from what I can tell, it doesn't.
[17:23] <Riddell> right.  presumably I need to clean it up too
[17:24] <soren> Good catch. Yes.
[17:24] <Riddell> good to know it's not just me missing something obvious
[18:18] <mok0> boring
[18:22] <soren> mok0: :)
[18:26] <mok0> Apparently, python-debian and python-deb822 are mutually exclusive. Which one is recommended?
[18:27] <mok0> python-debian, probably. It contains lots more
[18:29] <jonnymind> Hello everyone
[18:32] <soren> mok0: You'll likely be happier using python-debian, yes.
[18:32] <soren> mok0: Unless, of course, you're trying to parse e-mails and such.
[18:33] <james_w> mok0: python-debian now incorporates python-deb822.
[18:34] <mok0> james_w: yes, I noticed. Perhaps deb822 should be deprecated
[18:34] <james_w> mok0: the package?
[18:34] <mok0> james_w: yes
[18:34] <james_w> yes, it should be removed at some point.
[18:35] <mok0> james_w: or, deb822 removed from python-debian
[18:42] <mok0> james_w: Is it appropriate to file a bug against python-debian, and not that it should have "Replaces: python-deb822" ??
[18:43] <mok0> s/not/note
[18:44] <nibblesmx> is this the right channel for asking on a bug report?
[18:45] <mok0> #ubuntu-bugs?
[18:45] <soren> mok0: No, that would probably not be appropriate.
[18:45] <nibblesmx> mok0: thanks
[18:45] <mok0> soren: why not?
[18:46] <soren> mok0: Does it replace any files in python-deb822?
[18:46] <soren> mok0: Rephrasing: Can they coexist?
[18:46] <mok0> soren: yes, it contains deb822.py it seems
[18:46] <soren> In the same directory?
[18:46] <mok0> mok0: no they are exclusive, one replaces the other
[18:47] <soren> mok0: Oh, it already says: Replaces: python-deb822 ?
[18:47] <mok0> soren: rephrasing, intstalling one removes the other
[18:48] <soren> mok0: Well, that happens *because* it already has Replaces, Provides, Conflicts: python-deb822.
[18:49] <mok0> soren: ...but you can still install deb822 when the other is installed, it just removes it
[18:49] <soren> mok0: Huh?
[18:50] <mok0> soren: If I have python-debian installed, and I then install python-deb822, it will remove python-debian
[18:50] <soren> mok0: Not on my system.
[18:50] <mok0> soren: hmm.
[18:50] <soren> mok0: python-debian "Provides: python-deb822".
[18:51] <soren> ..hence python-deb822 is already installed (virtually).
[18:51] <Ubulette> anyone for a 2nd review for http://revu.tauware.de/details.py?package=prism  ?
[18:52] <soren> I apologise for just saying no to your original question. I thought you just wanted to state "Replaces: " because you thought that python-debian was a better choice than python-deb822.
[18:52] <mok0> soren: it does on my system:  The following packages will be REMOVED:   python-debian The following NEW packages will be installed:   python-deb822
[18:52] <soren> mok0: You're still running stale, old gutsy, are you?
[18:52] <mok0> soren: yep
[18:52] <soren> mok0: There's your problem. :)
[18:52] <mok0> :) ok
[18:52] <soren> mok0: It's already fixed in hardy.
[18:53] <soren> python-deb822 has even been removed from the archive.
[18:53] <soren> Replaces: is a bit misunderstood, really.
[18:53] <mok0> soren: go on
[18:53] <soren> If foo says that it "Replaces: bar", and bar is installed and you then install foo, foo will be allowed to replace files that bar has already installed.
[18:54] <soren> That's what "Replaces: " means.
[18:54] <mok0> soren: Ah, it's not "This package supercedes that other one"
[18:54] <soren> You're telling dpkg that you are aware that this package replaces from files in the other package, and that you are ok with that fact.
[18:54] <soren> mok0: Not on its own, no.
[18:55] <soren> mok0: To do that, you add: "Replaces: foo, Conflicts: foo, Provides: foo"
[18:55] <mok0> soren: but why can' t the two packages co-exist, then?
[18:55] <jonnymind> ppl, a fast question: a source pkg must be built by make -f rules,
[18:55] <jonnymind> but may rules call i.e. bash scripts?
[18:56] <soren> mok0: I asked if they could coexist because if you were asking about adding only Replaces (implying it wasn't already there). If they could already coexist, and you wanted to tell dpkg that it replaced files in the other package, you'd be lying.
[18:56] <soren> jonnymind: Sure.
[18:56] <jonnymind> k
[18:56]  * jonnymind was starting sweating cold.
[18:57] <mok0> soren: I was incorrect in my assumption on how Replaces: works
[18:57] <soren> mok0: Most people are :)
[18:58] <soren> Scott (Keybuk) wrote a long rant about this some time ago.
[18:59] <mok0> soren: where can I read that? :)
[18:59] <soren> mok0: I'm looking for it. Hang on.
[19:04] <james_w> mok0: they could co-exist, as the files aren't shared, but python-deb822 is no longer maintained, so we don't want it, all updates go in to python-debian.
[19:05] <james_w> (although they might try and create the same files in postinst, I can't remember)
[19:05] <james_w> but as deb822 is removed we can forget about it.
[19:06] <mok0> james_w: okay, but then I find it a bit surprising that apt-get allows you to replace python-debian with python-deb822.
[19:07] <soren> mok0: I'm afraid I can't find it.
[19:07] <mok0> soren: np
[19:07] <james_w> mok0: if you are telling it to install 'python-deb822', and you have zero things installed that depend on python-debian, and zero or more things installed that depend on deb822 it is still satisfied, and so will do what you tell it, i.e. install deb822.
[19:08] <mok0> james_w: yes. It doesn't protect me from myself :-)
[19:08] <james_w> I think a 'Supersedes:' field would solve this problem.
[19:08] <mok0> james_w: exactly
[19:09] <mok0> james_w: then apt-get could warn you
[19:10]  * soren needs dinner
[19:10] <mok0> soren: velbekomme
[19:10] <soren> ;)
[19:52] <TheMuso> Hey MOTUs.
[19:54] <bddebian> Heya TheMuso
[19:54] <geser> Hi TheMuso
[19:56] <geser> TheMuso: I guess after your glib1.2 rebuild uploads you are near the top of the uploader stats :)
[19:56] <geser> joejaxx should update his stats page
[19:57] <TheMuso> geser: Probably. I still have more to go though.
[20:22] <joejaxx> geser: i did not know anyone looked at it anymore :P
[20:30] <RainCT> is there a way to rename manpages (with cdbs) beside copying them?
[20:32] <mok0> RainCT: explain
[20:33] <RainCT> mok0: I've a tarball that comes with manpages with names like "bb.py.1", and I want to install those with another game (like for ex. "bubbros-server.6")
[20:33] <mdomsch> Updating System BIOS when running Ubuntu: http://direct2dell.com/one2one/archive/2007/12/05/37446.aspx
[20:34] <RainCT> s/game/name
[20:35] <proppy> hi
[20:35] <mok0> RainCT: Perhaps you can specify <from> <to> in package.manpages(?)
[20:37] <RainCT> might be, but I can't find any doc for .manpages.. well, will try it then if nobody knows if it works or not
[20:37] <RainCT> thanks
[20:38] <mok0> RainCT: documentation should be in dh_installman
[20:38] <RainCT> ah ok. thanks
[20:38] <mok0> RainCT: Ultimately in /usr/bin/dh_installman :-)
[20:39] <RainCT> hehe
[20:40] <G0SUB> hello, is there any policy about putting stuff in the multiverse? is it permissible to put _any_ non-free app, that can be redistributed ?
[20:42] <mok0> G0SUB: Don't know for sure, I think so
[20:42] <G0SUB> mok0: hmm
[20:44] <jussio1> G0SUB: what are you thinking of?
[20:45] <G0SUB> jussio1: some guy was talking about writing random non-free apps that depend on sun-java and put them on ubuntu multiverse
[20:45] <jussio1> ahhh
[20:45] <calc> many java apps can be compiled using gcj now so don't necessarily have to go into multiverse
[20:45] <geser> unless they have a non-free license
[20:46] <calc> geser: oh yea unless of that :)
[20:46] <calc> depending on sun-java also makes them go into multiverse
[20:46] <G0SUB> geser: those are non-free apps, of course
[20:46] <mok0> Of course you can always regenerate a .java file from a .class file :-)
[20:46] <calc> if they are free they can go into universe if they can be compiled with gcj
[20:47] <calc> i misread the part about the non-free license as well :)
[20:47] <mok0> But must be open source
[20:47] <calc> free being libre not gratis
[20:47] <geser> G0SUB: it is getting tried now if there is some other requirement beside redistributable to get into multiverse. someone packaged a non-free windows game which can be run in wine
[20:48] <calc> iirc the real test is they have to pass dfsg
[20:48] <G0SUB> geser: that's right ...
[20:49] <G0SUB> geser: that's exactly what I want to know
[20:49] <G0SUB> calc: do apps in our multiverse pass the dfsg ?
[20:49] <geser> G0SUB: wait for the outcome of this test
[20:49] <calc> G0SUB: i don't think so, but i don't recall what multiverse requirements are
[20:49] <geser> G0SUB: if they pass the dfsg they are suitable for main/universe
[20:50] <G0SUB> geser: right
[20:50]  * calc looks to see if he can find a list of req for multiverse
[20:50] <G0SUB> actually, the thing is ... there is this FOSS conference in India, called FOSS.in
[20:50] <calc> some stuff in multiverse belongs in universe already (wrt java stuff) but probably not that much
[20:50] <geser> calc: it must at least be redistributable
[20:51] <G0SUB> some sun guy came and talked here about packaging java apps for ubuntu, but he want on to talk about glassfish and how one can write non-free apps and push them to our multiverse
[20:51] <calc> geser: that much is a given :)
[20:51] <G0SUB> i was thinking about objecting to that idea
[20:52] <calc> G0SUB: sounds objectionable even if it is allowable ;)
[20:52] <calc> recommending people write non-free apps is bad
[20:52] <G0SUB> calc: exactly.
[20:52] <G0SUB> calc: that too in a FOSS coneference, masquarading as a foss speaker
[20:52] <calc> lol :(
[20:53] <G0SUB> calc: check the slides
[20:53] <G0SUB> http://blogs.sun.com/arungupta/resource/confs/foss.in-2007-java-apps-for-ubuntu.pdf
[20:54] <calc> i may not be looking in the right place but i don't see a clear definition of multiverse
[20:55] <G0SUB> hmm
[20:58] <calc> important point
[20:59] <calc> glassfish doesn't run on open java yet does it?
[21:02] <calc> if the apps depend on glassfish and it is in multiverse they will be in multiverse anyway, but he should have pointed out that soon open java will be in ubuntu main and that users probably want to be able to have the potential to be on an ubuntu cd
[21:03] <calc> i don't recall glassfish license but iirc it is primarily in multiverse due to its dependency on sun java, which will be resolved when open java is finally useful and available in main
[21:09] <Flare183> I'm supposed to sign the DEB file or the tar.gz file?
[21:09] <Flare183> Which one?
[21:11] <mok0> Flare183: neither
[21:12] <Flare183> oh
[21:12] <mok0> Flare183: you sign the .dsc and the .changes files
[21:12] <Flare183> oh kk
[21:12] <Flare183> gotcha
[21:12] <mok0> Flare183: but if you use debuild you don't have to worry about it
[21:13] <mok0> Flare183: but look at debsign
[21:13] <Flare183> But what if i am going to upload a package to my ppa and it comes from fiesty and I am using gusty?
[21:14] <mok0> Flare183: the distribution is defined in debian/changelog
[21:14] <Flare183> oh ok
[21:14] <mok0> Flare183: you upload a source package and it gets compiled on the ppa
[21:14] <mok0> Flare183: it doesn't matter which system you used to construct the source package
[21:14] <Flare183> oh ok.. i understand for the most part
[21:14] <Flare183> ok
[21:15] <mok0> Flare183: the ppa will look in the changelog to see which distro it has to compile for
[21:15] <Flare183> oh
[21:15] <Flare183> ok
[21:16] <mok0> Flare183: F.ex. I build hardy packages in gutsy :-)
[21:16] <mok0> source packages
[21:16] <Flare183> cool well i am building fiesty packages >> to gusty
[21:16] <calc> i build them all in chroots :)
[21:17] <mok0> calc: of course, me too
[21:17] <geser> Flare183: but it would be good if you could test that your package builds in gutsy before uploading
[21:17] <mok0> calc: but it doesn't matter for a source package
[21:17] <Flare183> ok
[21:17] <jonnymind> strange...
[21:18] <calc> mok0: well as long as you only build a source package, which means you may not have tested building the package
[21:18] <jonnymind> I have the source self-compiling package, but I wanted to print a banner after make
[21:18] <calc> to actually build the package at least for hardy on gutsy you may need versions of packages that aren't in gutsy :)
[21:18] <jonnymind> But it doesn't seem to work:
[21:18] <mok0> calc: you can test the package in pbuilder, but you don't need to build the source package there
[21:18] <calc> yea
[21:18] <jonnymind> Someone may tell me what's wrong?
[21:18] <jonnymind> cmake $FALCON_SRC_TREE && make || func_errors
[21:18] <jonnymind> func_complete
[21:18] <Fujitsu> keescook: I've just merged your branch again, and it seems to be more sane.
[21:19]  * calc never much liked pbuilder so made his own scripts
[21:19]  * Fujitsu hugs sbuild.
[21:19] <mok0> jonnymind: oh! no! you're using cmake
[21:19] <jonnymind> Oh yes, I do.
[21:19] <jonnymind> Is there a problem with that?
[21:19] <calc> i frequently need to go in mangle stuff which pbuilder didn't seem well suited for (at least when i wrote my own scripts)
[21:20] <jonnymind> I was simply going NUTS with automake,
[21:20] <mok0> jonnymind: it's so rarely used and completely non-standard
[21:20] <calc> automake is your friend :)
[21:20] <jonnymind> and when I splitted the projects in 5 svn brances I had to preserve my mental stability.
[21:20] <calc> isn't cmake that crazy KDE thing?
[21:20]  * mok0 loves automake
[21:20] <jonnymind> Moreover, it works on window.
[21:20] <mok0> jonnymind: who cares :-)
[21:21] <calc> iirc the reason KDE gave for switching to cmake was windows also
[21:21] <jonnymind> mok0: the ones that repspect those users that haven't still seen the light.
[21:21] <calc> of course no one runs free/open software on windows (other than firefox) anyway so its a bit pointless ;-)
[21:21] <jonnymind> (other then myself, which needed falcon at work)
[21:21] <jonnymind> We do.
[21:21] <jonnymind> And we run financial services servers.
[21:21] <jonnymind> With open source software.
[21:22] <jonnymind> However, cmake is quite great; other than that;
[21:22] <jonnymind> let's say
[21:22] <Flare183> ok hold up
[21:22] <jonnymind> make || func_errors
[21:22] <jonnymind> func_complete
[21:22] <mok0> jonnymind: anyway, in your statement above you mix cmake and make
[21:23] <Flare183> I am going to modify the beryl source packages and upload them to my ppa, when I go to download them from the ubuntu packages what should I download?
[21:23] <jonnymind> I tired without doing that; same result.
[21:23] <Flare183> the source packages, dsc, or the changelog?
[21:23] <jonnymind> make is succesfull...
[21:23] <jonnymind> yet nor || function nor the following seems to get executed.
[21:25] <mok0> jonnymind: It's hard to help from your description, why dont you pastebin it
[21:25] <jonnymind> good idea.
[21:28] <jonnymind> http://kde.pastey.net/78533
[21:30] <mok0> jonnymind: line 69, do you run cmake on a directory?
[21:30] <jonnymind> yes; it is created by the script relative to itself
[21:30] <mok0> jonnymind: what about line 46, does the script get past that?
[21:30] <Flare183> the source packages, dsc, or the changelog?
[21:31] <mok0> 49
[21:31] <jonnymind> so it seems.
[21:31] <mok0> line 49, sorry
[21:31] <mok0> It looks strange
[21:31] <jonnymind> Uhm
[21:31] <jonnymind> you are right; it gets past that line, but doesn't write it
[21:32] <jonnymind> that's the thing.
[21:32] <jonnymind> fixed :-)
[21:32] <mok0> jonnymind: Ah, its being echo
[21:32] <mok0> d
[21:34] <jonnymind> 've been up for too much :-(
[21:34] <mok0> hehe
[21:52] <mdomsch> popey, thanks for the blog comments
[21:55]  * imbrandon yawns
[21:55] <imbrandon> moins all
[22:02] <ScottK> mdomsch: I've got a Dell question for you, if you have a moment?
[22:02] <ScottK> I saw a Latitude X300 that someone had at a meeting yesterday and it looks like just about exactly the size I'm looking for.
[22:03] <ScottK> I don't find that on the Dell web site.  Would you mind pointing me at the current equivalent?
[22:09] <mdomsch> ScottK, I'm looking
[22:10] <ScottK> mdomsch: Thanks.
[22:10] <mdomsch> how big a screen is that?  Looks small
[22:11] <ScottK> Dunno that measured size, but it is very small.
[22:11] <mdomsch> probably the Latitude D400 (our 12" notebook)
[22:11] <ScottK> Thanks.  I'll have a look.
[22:11] <mdomsch> though I really like my XPS M1330 13.3"
[22:12] <Ubulette> if someone wants something to review: bug 174219, bug 174243
[22:12] <mdomsch> sorry, D430 is latest in that 12" family
[22:12] <ubotu> Launchpad bug 174219 in xulrunner "Please merge xulrunner 1.8.1.11-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/174219
[22:12] <ubotu> Launchpad bug 174243 in ruby-gnome2 "Please sync ruby-gnome2 0.16.0-10 (universe) from Debian Sid (main)" [Undecided,New] https://launchpad.net/bugs/174243
[22:14] <Ubulette> or prism on REVU (for which I really don't understand why no one is interested)
[22:14] <ScottK> mdomsch: Right.  Found that one.  Is that one of the models you're providing Ubuntu based BIOS updates for?
[22:15] <mdomsch> 1330 - yes
[22:16] <mdomsch> you can even boot the livecd and run the steps and do it from there
[22:18] <ScottK> mdomsch: Cool.  It may be time for me to get one of those.
[22:18]  * ScottK goes and looks at the budget.
[22:19] <popey> ooo hi mdomsch
[22:19] <Flare183> ok i signed it now use dput?
[22:21]  * macd really wants fingerprint reader working on M2300
[22:21] <macd> it worked, then came a bios update and poof
[22:21] <mdomsch> ScottK, you can even boot the livecd and run the steps and do the update from there
[22:28] <JanC> is anybody working on the flashplugin-nonfree package: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/173890/ ?
[22:28] <ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install... new version?" [Medium,Confirmed]
[22:34] <ScottK> JanC: I have it on my list to look at, but haven't done it yet.  If you want to take a shot at it, feel free.
[22:34] <JanC> I don't know how, just had a user complain about it  ;)
[22:34] <ScottK> Ah.
[22:35] <JanC> any idea how long it will take?
[22:35] <ScottK> Generally bugs that aren't assigned to someone aren't being worked on actively.
[22:35] <ScottK> No.
[22:35] <JanC> well, he's using gnash now  :P
[22:35] <JanC> but that won't work in all cases
[22:35]  * Fujitsu suspects that the best idea is to convince Adobe to be sane with their releases.
[22:36]  * ScottK just tries to avoid using Flash period.
[22:37] <JanC> so do I, but sometimes something useful is a inside flash file
[22:37] <JanC> from what I understand the installation system changed?
[22:39] <JanC> oh, and Debian has newer versions of this package in testing / unstable / experimental
[22:40] <ScottK> Yes.  Every time Adobe releases a new version, the package has to be updated.
[22:41] <JanC> latest version in experimental is dated "Sat, 22 Sep 2007 19:07:47 +0200 ", so probably not new enough to be fixed
[22:41] <ScottK> We don't generally sync from Experimental.
[22:41] <ScottK> Usually stuff that's there is there for a scary reason.
[22:42] <imbrandon> JanC: the md5's likely just need updating, i'll take a look at it this evening
[22:42] <JanC> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454366
[22:42] <ubotu> Debian bug 454366 in flashplugin-nonfree "flashplugin-nonfree: New upstream release (9.0.115.0)" [Normal,Fixed]
[22:42] <JanC> I'l link this to the Ubutnu bug
[22:44] <JanC> imbrandon & ScottK : thanks for looking at it  ツ
[22:44] <ScottK> imbrandon: Thanks.
[22:45] <imbrandon> ScottK: np
[22:45] <imbrandon> infact looking at it now, thats exactly what it is, i'll update it here shortly
[22:45] <imbrandon> but will probably take $days for a backport
[22:46] <JanC> I hope this will not only go into backports?
[22:46] <imbrandon> it will goto hardy and traditionaly -backports , yes
[22:46] <JanC> it makes the package unusable...?
[22:47] <imbrandon> one of the pitfalls of using binary only software :(
[22:47] <JanC> (and apparently Adept hides the error message from the package)
[22:48] <jdong> imbrandon: you dont' think we can talk pitti into a SRU exception for this?
[22:48] <jdong> imbrandon: it leaves flashplugin-nonfree completely nonfunctional to new installers right?
[22:48] <imbrandon> jdong: maybe, but i wasent gonna promis it :)
[22:48] <jdong> hehe :)
[22:48] <jdong> I think we can make a good case to backport it , then copy the backport to -updates upon verification
[22:48] <imbrandon> yea
[22:48] <Kmos> there is a new standards-version.. 3.7.3 :-)
[22:48] <imbrandon> Kmos: yes for some days now
[22:49] <JanC> jdong: that's exactly what happened to this guy; installed Kubuntu and flash didn't work, unfortunately without an error message  :-/
[22:49] <Kmos> imbrandon: need to check the news
[22:49] <Kmos> :)
[22:49] <jdong> JanC: right; I definitely think we can be granted an exception for this to go into -updates
[22:50] <imbrandon> i'm updating it now, give me a few to atleaste get it in hardy lol
[22:50] <jdong> imbrandon: FASTER FASTER!!!!!111
[22:50] <jdong> :D
[22:51] <imbrandon> grrr who ASSIGNED motu ?
[22:52] <JanC> someone named "Serge de Souze"   ツ
[22:52] <JanC> Souza
[22:54] <imbrandon> hrm we dont base ours off the debian version ?
[22:55] <imbrandon> strange
[22:55] <imbrandon> never been merged
[22:56] <MagicFab> Question about PPAs... does the PPA facility provide a mean to make an OpenPGP package signing key available ?
[22:56] <MagicFab> (if that makes sense)
[22:56] <imbrandon> no
[22:57] <Fujitsu> MagicFab: It is scheduled for the next couple of releases, I believe.
[22:59] <white> Fujitsu: awake already?
[22:59] <Fujitsu> white: I am, but at work.
[22:59] <white> :)
[23:01] <imbrandon> hrm JanC / jdong , it looks to be the same url and md5, e.g. works here
[23:01] <imbrandon> can someone verify
[23:05] <JanC> imbrandon: the guy that posted a patch to the bug has another MD5 ?
[23:05] <MagicFab> Fujitsu, tx
[23:05] <imbrandon> right but i think he had a corrupt download or something, the md5 is matching here
[23:05] <JanC> http://launchpadlibrarian.net/10727595/newflashplugin.patch
[23:06] <imbrandon> yes yea i see that
[23:06] <imbrandon> but the actual download shows diffrent
[23:06] <JanC> weird, at least 4 people in Ubuntu & 1 in Debian saw this MD5 mismatch error?
[23:06] <imbrandon> wget this file
[23:06] <imbrandon> http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz
[23:06] <imbrandon> and run md5sum on it
[23:08] <imbrandon> hrm actualy , i might have been mistaken
[23:08]  * imbrandon looks again
[23:08] <JanC> I get the new MD5 in that patch, not the old one?
[23:08] <imbrandon> right, my mistake, thanks
[23:16] <norsetto> Anybody can give a look at http://revu.tauware.de/details.py?upid=888 ? One advocation and is ready to go.
[23:19] <jonnymind> ppl,
[23:20] <jonnymind> Suppose I have a source package that works and that may build the final tree in any location (e.g. --prefix)
[23:20] <imbrandon> JanC / jdong : uploaded
[23:20] <JanC> imbrandon: \o/
[23:21] <JanC> thank you
[23:21] <jonnymind> Would be possible use that package tree to do the deb source-to-binary packages instead of the chroot?
[23:21] <imbrandon> np, jdong you wanna do the pitti convincing ?
[23:22] <jonnymind> I mean, I know it CAN be done. Does it break any policy?
[23:23] <RAOF> jonnymind: I'm not entirely sure what you're asking.
[23:23] <jonnymind> I got a source packaae
[23:23] <jonnymind> rules creates it with an arbitrary prefix
[23:23] <jonnymind> i.e. in a dist/ dir inside the source tree
[23:24] <jonnymind> control file(s) read things from dist/usr, dist/lib etc.
[23:24] <jonnymind> is that ok?
[23:24] <RAOF> So you're installing all the build-dependencies to dist/usr, etc?
[23:24] <RAOF> jonnymind: The binaries built from a source package never get installed to $prefix/whatever - the rules file (usually) changes DESTDIR in the install target so they end up in $(CURDIR)/debian/tmp/$prefix/whatever
[23:25] <jonnymind> Ok, that was what I was asking.
[23:25] <RAOF> The chroot is mainly there so that (1) you don't have to clutter your main environment with thousands of dev packages and (2) so that the package doesn't inadvertantly link to wrong libraries.
[23:25] <jonnymind> So I can (or have) to build them in ${pwd}/debian/usr...
[23:26] <RAOF> Yes.  Although $(CURDIR) is the varaible you're actually after :)
[23:26] <jonnymind> Ok.
[23:26] <imbrandon> and $(DESTDIR)
[23:28] <jonnymind> Ok, from the descs in the docs I beleived I had i.e. to chroot to a place and THEN build with DESTDIR=/usr from there.
[23:28] <jonnymind> I see that's a more general case (i.e some software wants to know where they are supposed to be installed).
[23:30] <RAOF> Yup.  Quite a lot of software will build in $prefix/lib/mylibdir to load plugins, for example.
[23:30] <jdong> imbrandon: haha sure, pitti-stalker engaged.
[23:31] <jonnymind> So, it depends on software, not on policy. I get it.
[23:31] <RAOF> Indeed.  Although if you do something different you'll have a hard time getting it sponsored, I imagine.
[23:32] <RAOF> All the tools (debhelper, cdbs, etc) assume you end up with the package files installed somewhere in debian/pkgname (or debian/tmp, then moved do debian/pkgname).
[23:33] <RAOF> If you do something vastly different, you'll need to build the .deb & associated control files manually (ie: don't do something vastly different :))
[23:33] <jonnymind> debian/tmp or /tmp/debian?
[23:33] <RAOF> $(CURDIR)/debian/tmp
[23:34] <RAOF> The build process should never stick anything outside the build tree.
[23:34] <jonnymind> I agree.
[23:34] <RAOF> IE: *everything* is relative to $(CURDIR), no absolute paths.
[23:34] <jonnymind> My software has a loose dependency with the installation path too, but it's overridable so that it can differ.
[23:34] <RAOF> I'm not sure if that's actual policy, but again, don't expect anything else to be sponsored :)
[23:35] <RAOF> jonnymind: It depends on both --prefix *and* DESTDIR?
[23:35] <RAOF> This seems wrong.
[23:35] <jonnymind> So, you can install it in $(CURDIR)/anywhere and tell it that it will end up installed in /usr
[23:35] <jonnymind> you can. You don't have to.
[23:36] <RAOF> Yup.  that's what --prefix is about ;)
[23:36] <jonnymind> That's a bit more complex:
[23:36] <jonnymind> I created a temporary build environment that can override system installation.
[23:36] <jonnymind> As it's a language, it may be installed system wide while you're developing i.e. a new VM.
[23:37] <TheMuso> c
[23:37] <TheMuso> wrong tab
[23:37] <jonnymind> Forget something and you'll screw.
[23:38] <jonnymind> So, I made so that the language and all its system can be runtime-environment configured to override installation settings.
[23:38] <jonnymind> Just load an automatically built script and you're free to experiment with your personal version, without having to mess up with the official distro.
[23:39] <jonnymind> So, when  I install it in /my/personal/env I still say it will end up in /usr one day.
[23:39] <jonnymind> and when I decide it's time, I just copy there and run it from a clean environment.
[23:39]  * norsetto headache is not getting any better
[23:39] <jonnymind> I call that *respect* for the developers willing to join and experiment.
[23:40] <jonnymind> Anyhow I am digressing. The build will work the *old way* if necessary.
[23:41] <jonnymind> Or better, it runs the *usual way* by default. You just got a "hacking mode" if you need it.
[23:45] <jonnymind> ....
[23:46] <jonnymind> It seems I made some void around me... :-)
[23:46] <RAOF> No, I just thought your question was answered, and I didn't really have anything to say about your elaboration.
[23:47] <jonnymind> :-) yes, you have been very supportive, and mine was just self-talk. Thanks.
[23:48] <`nobody> hi. i'm looking into repackaging the "barry" package from what was done by the original maintainer in the "debian way" to make it conform to ubuntu packaging guidelines, and i'm not sure i got the version number right: the original is 0.11-1, and I think it would become 0.11-1-1ubuntu1, right?
[23:48] <DarkMageZ> `nobody, 0.11-1ubuntu1
[23:48] <imbrandon> `nobody: are you talking from debian or upstream? upstream should be punished for releases -1
[23:49] <tonyyarusso> If I'm making major changes to my blog, is there a way to prevent Planet spammage?
[23:49] <imbrandon> DarkMageZ: maybe not
[23:49] <imbrandon> tonyyarusso: dont change the timestamp on the rss feed :P
[23:49] <imbrandon> tonyyarusso: or deactivate your feed temp
[23:50] <tonyyarusso> imbrandon: will it do weird things when I reactivate the feed?
[23:50] <`nobody> it's not really in debian, but i guess also not really upstream. it's GPL code, from netdirect inc., but this Chris Frey dude made it available on sourceforge along with .deb packages.
[23:50] <imbrandon> depends on how you change the rss, but it shouldent
[23:50] <tonyyarusso> hmm, okay
[23:50] <tonyyarusso> imbrandon: fyi, I'm going to be switching from WordPress to Drupal, if that helps
[23:50] <imbrandon> `nobody: then it should be as DarkMageZ said, you go off upstream
[23:51] <`nobody> so 0.11-1ubuntu1 it is?
[23:52] <imbrandon> did upstream release 0.11 ? if so and its not in debian it will be 0.11-0ubuntu1
[23:55] <`nobody> ok I see. the package source file is named as 0.11, and only the changelog mentions a -1, but all their versions end with at least -1.
[23:55] <imbrandon> well kinda
[23:56] <imbrandon> you dont go off their packages, you work with the upstream source, 0.11 , and if its not in debian you use -0ubuntuX if it is in debian you use -YubuntuX ( Y == debian revision , X is uubutn revision )
[23:56] <imbrandon> this is all explained in the package guide also
[23:57] <`nobody> i was reading the package guide, but i found the part about the version was a little unclear
[23:57] <imbrandon> i think because you are trying to use a middle man, dont
[23:57] <imbrandon> upstream
[23:57] <imbrandon> is the source
[23:58] <`nobody> i checked and i am using the upstream source. the page on netdirect points over to the sourceforge page i am getting the source from
[23:58] <imbrandon> right, the tarbal , you are looking at something with debian/ in it
[23:58] <`nobody> yes
[23:58] <`nobody> that's what i'm editing -- the changelog file.
[23:59] <imbrandon> debian/ should not be included in the release tarbal, thats bad mojo and nees to be fixed pstream and or repacked
[23:59] <`nobody> ok