[12:17] <persia> Does anyone have an opinion on whether the package contents and the packaging consitute a single work or are considered a collation for licensing purposes?  Is the resulting binary package a "combined work", and if so, must the packaging and upstream licenses be compatible?
[12:19] <nixternal> man, good question
[12:20] <nixternal> I think if you look at it, a single binary package that was licensed under a CC license and a package that is GPL, would make it a combined work I think
[12:21] <nixternal> then again, that legal mumbo jumbo is to much for me at times..yup, here comes the headache now
[12:22] <persia> nixternal: That's my thought.  Note that it is considered permissible to ship incompatibly licensed material in the same package so long as the parts are separately derived, and the code stack for each executed piece is licensed cleanly (see thread starting at http://lists.debian.org/debian-legal/2003/12/msg00029.html)
[12:22] <LaserJock> well, when you start patching and stuff I think you might make the claim that it's a combined work
[12:22] <LaserJock> but I don't think, in general, it's considered a problem
[12:22] <TheMuso> Hey folks.
[12:23] <persia> LaserJock: Huh?  If it's a "combined work", and one of the licesnses is GPL and the other GPL-imcompatible, how is this not a problem?
[12:23] <nixternal> I don't think its a problem, but in a way it is a combined work. you create application A, and I created a package of application A. now, in order for it to be a problem possibly, the package itself might have to be considered an application in its own
[12:23] <nixternal> well ya, the licensing has to be compattible
[12:24] <nixternal> persia: are you thinking about Google Desktop :)
[12:24] <persia> nixternal: Not specifically, although that may also be a good example.
[12:24] <LaserJock> persia: usually that isn't a problem
[12:25] <persia> LaserJock: Is there an official opinion somewhere, or do we just not care?
[12:25] <LaserJock> hmm, not sure
[12:25] <LaserJock> but packaging is in general considered public domain
[12:25] <LaserJock> unless specifically noted otherwise
[12:26] <persia> LaserJock: I'm guessing that Canonical Legal can get away with a bit of "lots of people can upload, sorry for the mistake", but I don't want to cause the problem :)
[12:26] <LaserJock> why would there be a problem?
[12:26] <persia> LaserJock: Ah.  That makes sense.  I was previously advised that it was best practice to specifically license packaging: should I not so advise uploaders?
[12:27] <LaserJock> no, I think it's an ok practice
[12:27] <LaserJock> because it's clear
[12:27] <persia> LaserJock: If the licensor of something wanted to complain about incompatible licenses.
[12:27] <LaserJock> heh, if they complain we can change it
[12:28] <LaserJock> but I would think there would be a whole lot of problem in debian
[12:28] <persia> _MMA_: As an example only
[12:28] <pygi> hey etank 
[12:28] <_MMA_> Ahh...
[12:28] <nixternal> http://code.google.com/p/google-desktop-for-linux-mirror/downloads/list
[12:28] <nixternal> heh, rfc_uuid was originally developed by microsoft...interesting
[12:28] <persia> LaserJock: Yeah.  That was my thought (and I also think we try to follow Debian licensing policies).
[12:28] <etank> howdy pygi 
[12:28] <etank> and everyone else too :)
[12:29] <nixternal> I wonder if they still hold the patent for it, if so you are violating Microsoft, and if it is with a baseball bat, keep on violating!
[12:29] <gnomefreak> for a package to show up on my Lp page under maintainence report i have to be listed as maintainer?
[12:29] <nixternal> yup
[12:30] <nixternal> just set Maintainer: to MOTU and join up! :)
[12:30] <bigon> could someone have a look at http://revu.tauware.de/details.py?upid=5811 ?
[12:30] <LaserJock> persia: I would venture to say most packages in Debian do not license the packaging
[12:30] <LaserJock> but I think for completness and correctness it's good to do so
[12:30] <gnomefreak> nixternal: problem there is motu looks at that page to see what you have done and you cant join motu until they have approved you part by looking at that page
[12:31] <gnomefreak> so i guess i should start keeping track
[12:31] <LaserJock> and obviously if you're going to do it, it should be compatible with the package
[12:31] <minghua> I don't think blindly encouraging licensing the packaging is a good idea
[12:32] <minghua> unless the package is single-lincensed, and the packaging uses the same license
[12:32] <LaserJock> exactly
[12:32] <minghua> but I do very little REVU work, do my opinion doesn't really matter
[12:32] <LaserJock> in fact, I would recommend against using GPL for licensing packaging in general
[12:32] <minghua> actually, make that "very little MOTU work" :-(
[12:32] <LaserJock> I would explicitly do as close to public domain as possible
[12:33] <LaserJock> so there wouldn't be any problems in the future
[12:33] <LaserJock> gnomefreak: you are totally right, that is a big issue
[12:33] <persia> LaserJock: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html encourages one (and is listed as part of the ftp-master reject FAQ).
[12:33] <nixternal> gnomefreak: I don't have any packages I specifically maintain in Ubuntu
[12:33] <nixternal> same goes in Debian, except for one package. I set KDE Extras to maintainer and me as an uploader
[12:34] <gnomefreak> i do but i either have motu or mozillateam as maintainers
[12:34] <LaserJock> persia: "Ideally you include a license statement for your Debian packaging also" note the ideally part ;-)
[12:34] <gnomefreak> what about adding my name next to the maintainer?
[12:34] <nixternal> all of my packages listed on my LP page weren't uploaded by me. Is that what you are referring to?
[12:35] <persia> LaserJock: Right.  Hence "encourages" :)
[12:35] <gnomefreak> nixternal: i have uploaded a few and fixed a bunch but nothing on my Lp at all
[12:35] <nixternal> gnomefreak: if you want to be the maintainer of a package then do it...I was joking about the MOTU part in a way :)
[12:35] <nixternal> orly
[12:35] <nixternal> who has been uploading your fixes and what not?
[12:35] <gnomefreak> a few people :) but they will be there when i go for motu
[12:36] <minghua> persia: the mail and examples with in from the d-d-a list is very nice, but those requires careful consideration from the maintainer's part
[12:36] <nixternal> that is odd, I never uploaded anything, others have, yet I got credit for it
[12:36] <gnomefreak> nixternal: same here
[12:36] <nixternal> only thing I pay attention to is boogs in LP :)
[12:36] <gnomefreak> ;)
[12:37] <nixternal> interesting, your page doesn't list a thing
[12:37] <gnomefreak> i just said that 
[12:37] <gnomefreak> lol
[12:37] <nixternal> hahaha
[12:37] <nixternal> I know, but I wasn't clear because you said people uploaded for you
[12:37] <gnomefreak> they did upload for me as i cant
[12:37] <nixternal> ahh ya that's right, you are doing that stuff
[12:38] <nixternal> didn't I see your name in the gutsy-changes list though for those uploads?
[12:38] <gnomefreak> i dont know i didnt see it
[12:38] <nixternal> I am looking now
[12:39] <Kmos> gnomefreak: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/date.html
[12:40] <nixternal> gnomefreak: gwget2 sound familiar?
[12:40] <gnomefreak> yes i remember that as well
[12:40] <nixternal> that is the only thing I see in the gutsy-changes with your name on it
[12:40] <nixternal> and that should at least be on your page
[12:40] <nixternal> that is weird
[12:40] <pygi> nixternal, it's not 
[12:41] <pygi> new uploads are either -motu or core-dev
[12:41] <gnomefreak> https://lists.ubuntu.com/archives/gutsy-changes/2007-June/003026.html
[12:42] <nixternal> pygi: I understand that, as I had 1 or 2 new uploads, and yet they are on my page when someone else obviously uploaded them in the past
[12:42] <pygi> nixternal, true, they should be on his page tho
[12:42] <nixternal> ya, that is what I thought
[12:42] <pygi> nixternal, it is however possible we're not tracking that anymore
[12:43] <pygi> since *new* maintainers for stuff are motu or core devs
[12:43] <pygi> no one else
[12:43] <pygi> so perhaps all goes to them
[12:43] <nixternal> ya, but if gnomefreak creates/recreates a package and signs it, he should get recognition for it no matter who uploads it
[12:43] <persia> I think we're tracking the "Changed-By" tag in source.changes, so it depends on how the uploader processed the upload.
[12:43] <gnomefreak> so what is suggested on how to track this
[12:44] <nixternal> gnomefreak: well there is always <release>-changes which documents everything, well almost everything, the recent LP updates broke the *-changes updates
[12:45] <nixternal> gnomefreak: I might ask an LP admin what is up unless someone here knows for a fact the issue at hand
[12:45] <gnomefreak> ok so as long as you are under changed by: than it should show up in LP?
[12:46] <minghua> from the little REVU work I've done, many MOTU hopefuls can't even get the upstream copyright/licenses correct in debian/copyright file
[12:47] <minghua> persia: ^^^
[12:48] <persia> minghua: I'm seeing that too, which is actually one of the sources of my questions.  Most of my REVU comments are licensing related (although I also note when packages have forgotten to use lintian and linda).
[12:49] <minghua> persia: yeah, so as LaserJock said, the REVU land is far from "ideally" yet, so maybe we can leave the packaging licensing alone for now :-)
[12:50] <persia> minghua: I'm just one commenter.  It doesn't block other's uploading :)
[12:51] <jussi01> heh, I find licensing the hardestmost tiresome part of packaging...
[12:51] <jussi01> damn, my stupid / key...
[12:51] <jussi01> never works
[12:52] <nixternal> I find it the easiest :)
[12:53] <nixternal> I have a few Debian svn projects checked out, so I refer to them when I have questions...most of the time I can just copy and paste into the license and roll with it. In it for a minute or two and then on to something else
[12:53] <jussi01> hmmm...maybe Ive just had dodgy lincensed packages... right persia?
[12:53] <minghua> IIRC, LP credits "uploaded packages" if you are the uploader ("changed-by") and your keyring is in LP
[12:54] <jussi01> damn, ive got bad typo's tonightt
[12:54] <persia> jussi01: Yep.  As long as upstream is clean about licensing, it's usually pretty easy (although people sometimes make mistakes anyway).
[12:54] <minghua> I agree copyright/licensing varies a lot from package to package
[12:55] <alex-weej> i'm just building some simple packages that i plan to distribute
[12:55] <alex-weej> am i ok using "dpkg-deb -b"?
[12:55] <LaserJock> hmm, let me think a little
[12:55] <minghua> it took mplayer like three years to get that part right
[12:55] <LaserJock> I think LP should take it from changelog
[12:56] <minghua> LaserJock: I think it's the .changes
[12:56] <gnomefreak> LaserJock: i agree, atleast thats the easiest way to track accutual changes
[12:56] <LaserJock> the uploader is determined from .changes
[12:56] <LaserJock> but that's different
[12:56] <LaserJock> I think
[12:57] <LaserJock> oh heck, now I'm getting myself confused
[12:57] <LaserJock> I filed a bug about one of these
[12:57] <minghua> LaserJock: why?  as long as you don't build with -m option, the changed-by line in .changes should be same as the first entry of debian/changelog
[12:57] <LaserJock> well yes
[12:58] <LaserJock> that's what I'm meaning, sorry
[12:58] <LaserJock> like I said, I'm confusing myself
[12:58] <minghua> I'm afraid you are starting to confuse me as well...
[12:59] <jussi01> ok, i give in... someone tll me how to make it work? please? http://paste.ubuntu-nl.org/27685/
[12:59] <LaserJock> ok, LP should keep track of both the person in the changelog and the person who signed/uploaded
[12:59] <LaserJock> the first is done by Changed-By: , right?
[12:59] <persia> LaserJock: Changed-By is the last changelog entry.
[01:00] <LaserJock> right
[01:00] <nixternal> jussi01: there either isn't a makefile in the root directory, or ./configure was never run ;p
[01:00] <LaserJock> and the second is determined from the gpg signature
[01:00] <nixternal> I think you know that though, that is what I am being a smart ass on that one 
[01:00] <jussi01> :P
[01:00] <nixternal> haha
[01:01] <nixternal> jussi01: is this the package where the makefile and what not is in src/ ?
[01:01] <LaserJock> gnomefreak: do you have an example package & version that should show up on your LP page?
[01:01] <jussi01> nixternal: yes...
[01:02] <geser> jussi01: you need the right summoning
[01:02] <jussi01> geser: yes....
[01:02] <minghua> LaserJock: yes.  and I don't even know where debian keep the information about the signer/sponsor.  the only place I can check it is the qa.d.o page (besides looking through -devel-changes list archive, of course)
[01:03] <AndyP> am i correct in thinking there's a Q&A session in an hour?
[01:03] <AndyP> ish
[01:03] <LaserJock> minghua: LP just started keeping that info not long ago
[01:04] <jussi01> I have this in my rules file right now, 
[01:04] <jussi01> cd $(CURDIR)/src/
[01:04] <jussi01> 	make
[01:04] <jussi01> what should it be?
[01:04] <nixternal> jussi01: that is exactly what I was going to ask
[01:04] <nixternal> I have a similar thing with an icon package, and that is what i did
[01:04] <nixternal> err, maybe not...let me look
[01:04] <jussi01> nixternal: I can read your mind :P
[01:04] <minghua> LaserJock: oh?  would you show me a pointer please?
[01:05] <minghua> s/show/give/, I suppose
[01:05] <persia> jussi01: You probably also want that before ./configure
[01:05] <nixternal> hrmm, maybe it wasn't the icon package...wth package was it now
[01:05] <jussi01> persia: config works
[01:06] <nixternal> now that is odd, the config works but the makefile doesn't
[01:06] <jussi01> config looks like: $(CURDIR)/src/./config but i tried that with make and it didnt work....
[01:07] <LaserJock> minghua: as to what?
[01:07] <minghua> LaserJock: LP keeping track of the sponsor info
[01:08] <LaserJock> well, I don't have much of a pointer
[01:08] <LaserJock> I don't think they actually do anything with it yet
[01:09] <LaserJock> other than I think they use it in soyuz to send the Accepted/Rejected emails
[01:09] <minghua> oh, I see
[01:09] <minghua> so sponsor and uploader both receive the accepted/rejected mails now?
[01:09] <nixternal> I have a tip: don't play leaf frog with a unicorn!
[01:10] <nixternal> argh, LEAP
[01:10] <nixternal> jeesh, blew my own damn joke
[01:10] <jussi01> nixternal: thanks.... :P
[01:10] <LaserJock> minghua: well, no, right now just the sponsor
[01:11] <LaserJock> I filed a bug to also get the sponsoree an email too
[01:11] <LaserJock> we had a few cases where somebody uploaded a package from REVU and it took a while for the archive admins to get to them
[01:11] <LaserJock> and the sponsor was kinda MIA so nobody knew what happened to the packages
[01:12] <gnomefreak> LaserJock: yes i have a few
[01:13] <LaserJock> minghua: well, that's why I said both need it
[01:13] <LaserJock> ;-)
[01:13] <gnomefreak> LaserJock: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/003733.html
[01:13] <gnomefreak> thats one
[01:14] <LaserJock> gnomefreak: ahh, I found the problem
[01:14] <LaserJock> or at least the problem with that one
[01:15] <LaserJock> gnomefreak: check out https://launchpad.net/~gnomefreak-ubuntu/+packages ;-)
[01:15] <gnomefreak> lol ok shall i give you another or 2?
[01:15] <gnomefreak> that just took a a day to get there
[01:16] <LaserJock> gimme more of them
[01:16] <gnomefreak> LaserJock: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/002583.html  another one a bit further of a date
[01:16] <LaserJock> what happened with that one was that you don't have your @ubuntu.com address in your LP account
[01:16] <gnomefreak> LaserJock: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/003026.html
[01:16] <LaserJock> so it created a new account
[01:16] <gnomefreak> ah
[01:16] <gnomefreak> damn
[01:17] <LaserJock> so you need to merge those 2 accounts
[01:18] <gnomefreak> LaserJock: ok let me see if i can pull it up
[01:19] <LaserJock> oh my gosh
[01:19] <minghua> So we are already past Debian Import Freeze, and all future syncs needs requests?  That seems a bit early to me.
[01:19] <LaserJock> gnomefreak: I found the other ones
[01:19] <gnomefreak> omg
[01:19] <gnomefreak> LaserJock: is there a fast easy way to do this?
[01:19] <minghua> Considering the state in unstable right now.
[01:20] <LaserJock> gnomefreak: https://launchpad.net/~ubuntu-desktop-effects/+packages
[01:20] <gnomefreak> ah
[01:21] <LaserJock> my only thought there is that the contact email for ~ubuntu-desktop-effects is yours
[01:21] <gnomefreak> LaserJock: there was my ubuntu.com one but i changed it
[01:21] <geser> minghua: yes, during the feisty cycle it was also so early
[01:22] <minghua> during feisty it's better because Debian is pretty much frozen
[01:22] <LaserJock> gnomefreak: https://launchpad.net/people/+requestmerge
[01:22] <minghua> I expect a bumpy road ahead
[01:22] <LaserJock> gnomefreak: ah that would do it
[01:22] <minghua> hope the archive admin (or whoever in charge) can keep up with sync requests
[01:22] <LaserJock> minghua: yes, I asked about that but I don't think I got much of a response
[01:22] <gnomefreak> LaserJock: ty the duplicate accounts would be the wrong ones?
[01:23] <LaserJock> gnomefreak: yes, well only gnomefreak-ubuntu
[01:23] <minghua> not good memories
[01:23] <LaserJock> I'm not sure what to do with the desktop-effects ones other than put a link to those on your wiki page
[01:23] <LaserJock> minghua: there are significantly more archive admins now, but I know what you mean
[01:24] <gnomefreak> LaserJock: ok ty i might have to do that thank you for finding them
[01:24] <LaserJock> I'm having LP devs looking at what it takes to have MOTUs do archive admining
[01:24] <minghua> LaserJock: let's wait and see then.  If the processing time is short, I don't mind submitting requests, it's good QA.
[01:25] <LaserJock> minghua: during at least parts of dapper there was only elmo. Now there are 9 archive admins
[01:25] <minghua> Anyway, I should concentrate on getting my Debian packages in shape, then worry about sync requests.
[01:25] <persia> LaserJock: Full archive admining, or just SYNC approvals?
[01:25] <LaserJock> persia: for MOTU?
[01:26] <persia> LaserJock: Yes.
[01:26] <LaserJock> the full thing of course
[01:26] <LaserJock> it can then be limited to what we need
[01:26] <LaserJock> but I want LP to have the needed changes
[01:26] <LaserJock> so when we decide we need to do something and TB agrees it'll be there
[01:27] <persia> LaserJock: Ah.  That'd be nice (I'm especially interested in binary removals).
[01:27] <LaserJock> oh yes, binary removals would be excellent
[01:27] <ajmitch> like NEW
[01:27] <LaserJock> well, there's a difference between the social constraints and technical constraints
[01:28] <LaserJock> I want to make sure there aren't any technical reasons why we can't
[01:28] <LaserJock> whether the TB/Ubuntu Archive lets us is entirely different, and in my opinion we really shouldn't do much
[01:28] <LaserJock> I really wouldn't want MOTU doing NEW
[01:29] <LaserJock> I think syncs, sru pushing, and binary removals would be the real use cases
[01:29] <persia> LaserJock: Are you drafting a spec?
[01:29] <LaserJock> well, not exactly
[01:30] <LaserJock> I filed a bug and was going to write a spec when we were having issues with SRUs
[01:30] <LaserJock> we almost got -proposed admining rights, but LP wasn't ready
[01:30] <persia> LaserJock: That's another use case I'd like to see: removals from -proposed.
[01:31] <LaserJock> but now that the SRU process has changed and we don't have motu-sru anymore I've had to Won't Fix that bug for now
[01:31] <LaserJock> persia: yes
[01:31] <LaserJock> but I just told kiko and cprov yesterday that I don't want them to forget about it
[01:31] <LaserJock> but it's not high priority right now
[01:32] <LaserJock> I think cprov was working on a spec
[01:32] <LaserJock> in fact I believe my "motu-sru should admin -proposed" bug was slated for 1.1.8
[01:32] <LaserJock> persia: yes, that is an issue
[01:32] <LaserJock> I tried to get access to w.l.c.c ;-)
[01:33] <persia> LaserJock: Specific individuals having access doesn't help: policy is that the contents of w.l.c.c cannot be exported (despite the subscription bug).
[01:33] <LaserJock> I said "don't expect me to work on a spec if I don't even have read-access to the wiki"
[01:33] <Kmos> I'/quit
[01:33] <LaserJock> but they (well one person) didn't go for it
[01:34] <minghua> What exactly is binary removal for?
[01:34] <persia> minghua: For when a package is no longer built for an architecture, but we still ship the old (buggy, uninstallable) version.
[01:35] <LaserJock> or
[01:35] <LaserJock> like say in Debian, we get towards the end of the release and we have really crappy packages
[01:35] <persia> minghua: Currently processing is a bit slow.  My binary removal requested for Breezy was processed for Gutsy.
[01:35] <LaserJock> we can pull the binaries before release so people don't try to install uninstallable junk ;-)
[01:36] <minghua> I see.  I though such things are automatically done in Debian
[01:36] <LaserJock> they are
[01:36] <persia> minghua: Yes (in Debian)
[01:36] <LaserJock> we don't have anything in Ubuntu
[01:36] <ajmitch> persia: "a bit slow" indeed
[01:36] <LaserJock> you just file a bug and sub ubuntu-archive
[01:36] <minghua> But I do realize that Debian and Ubuntu have rather different archive management.
[01:36] <ajmitch> that's because we don't have 3 archives
[01:36] <LaserJock> my removals have only take a week or two
[01:36] <ajmitch> not in the same way debian does
[01:37] <LaserJock> we're missing Testing :-)
[01:37] <persia> LaserJock: I suspect it was because someone tried to submit a patch to fix mine :)
[01:37] <minghua> we copy all the binary packages in feisty when we open gutsy, right?
[01:37] <LaserJock> persia: ah yeah, mine were all "dead upstream, buggy package, and Debian got rid of it"
[01:37] <persia> minghua: Right (a spec to rebuild for new releases would be nice too)
[01:38] <persia> LaserJock: That's a package removal (not binary removal).  I usually get those processed in a month or so.
[01:38] <LaserJock> oh, right
[01:38] <minghua> By "copy", I mean "keep the same binary package, generate a new Packages.gz for gutsy based on those", of course
[01:38] <LaserJock> hmm, i don't know that I've ever had a binary removal done
[01:38] <LaserJock> usually they just pull the source package and leave the binary
[01:38] <LaserJock> minghua: yep
[01:39] <LaserJock> I think we'd have a whole lot of FTBFS if we rebuilt each release
[01:39] <LaserJock> it's annoying when you get a new package from Debian and it FTBFS
[01:40] <persia> LaserJock: That's the idea.  I found a package that was shipped FTBFS in feisty, as the binary worked fine, but the tools to generate it has changed, so it could not be patched locally.
[01:40] <LaserJock> and you go back and we've had the same binary since Hoary or Breezy
[01:40] <minghua> Well, according to the gutsy schedule on wiki.u.c, we should just finished the _second_ archive rebuild test.
[01:40] <ajmitch> minghua: funny
[01:40] <persia> minghua: That's mostly main.
[01:40] <LaserJock> Main
[01:40] <LaserJock> yeah
[01:40] <LaserJock> I believe they have quite a component-wide testing setup
[01:41] <LaserJock> iwj I believe worked a lot on that stuff
[01:41] <minghua> https://wiki.ubuntu.com/GutsyReleaseSchedule  # it should be the first rebuild, sorry
[01:41] <LaserJock> Universe is just the cruft of the packaging world ;-)
[01:41] <persia> it would be nice if the tools ran on universe, and the output was somewhere.  No committment to fix it, but so that we could see the issues and fix them if we have time.
[01:42] <LaserJock> persia: yeah, I've wanted to ask but haven't had the time to follow up on it
[01:42] <minghua> lucas did that for feisty once, I remember
[01:42] <persia> LaserJock: No rush.  You've a full plate already :)
[01:42] <minghua> although rather close to release date
[01:42] <LaserJock> of course it's probably all like MoM so we won't be able to see what's going on ;-)
[01:43] <LaserJock> yes, he ran it through on that grid thing he's got access too
[01:43] <LaserJock> 40,000 nodes or something
[01:43] <ajmitch> heh
[01:43] <minghua> BTW, lucas is doing that for debian on weekly/biweekly basis now
[01:43] <LaserJock> didn't it take him something like 4-7hrs to rebuild Universe
[01:44] <ajmitch> it didn't take long, at least
[01:44] <LaserJock> I can't imagine what it would take on my machine
[01:44] <minghua> http://people.debian.org/~lucas/logs/2007/  # for those interested and didn't know
[01:44] <ajmitch> weeks
[01:44] <broonie> LaserJock: The limit on how fast it can be built is the time taken for openoffice.org to build :)
[01:45] <minghua> anybody want to guess which package is the second in building time after OO.o? :-)
[01:45] <Nafallo> kernel-source
[01:46] <Nafallo> linux-source even
[01:46] <LaserJock> broonie: right, makes sense
[01:47] <geser> how long does it take to build OO.o?
[01:47] <Nafallo> geser: 12h on the buildds IIRC
[01:47] <Nafallo> could be more :-)
[01:47] <LaserJock> minghua: that's not all of Debian thuogh
[01:47] <minghua> LaserJock: the people.d.o url?
[01:48] <LaserJock> yeah, that list looks too short for all of Debian main
[01:48] <LaserJock> I wonder how long it would take to build OO.o on my "shiny" new Ultra 10 ;-)
[01:48] <ajmitch> ask calc :)
[01:49] <LaserJock> heh
[01:49] <ajmitch> I'm sure  he'll put in a special laserjock build flag
[01:49] <minghua> LaserJock: those are the ones that FTBFS
[01:50] <Nafallo> oooh. it's only 9h now :-D
[01:50] <minghua> LaserJock: for a full one, see e.g. http://people.debian.org/~lucas/logs/2007/06/19/sym/
[01:51] <geser> the kernel takes only like 4 hours, latex-cjk-chinese-arphic takes 7 hours
[01:51] <Nafallo> ha! 12h on i386 :-)
[01:51] <Nafallo> OO.o that is
[01:51] <minghua> the package that take the second longest time to build is latex-cjk-chinese-arphic, an arch:all package
[01:51] <minghua> yeah, geser beats me
[01:51] <minghua> I can't find the mail about top 10 now :-(
[01:53] <geser> minghua: latex-cjk-chinese-arphic had once a FTBFS because it didn't generate some output and the buildd timed out
[01:54] <minghua> geser: yeah, wouldn't happen for Debian.  :-P
[01:55] <minghua> IMHO that package is not properly constructed, and it can be made to take less time to build, but what do I know.
[01:55] <gnomefreak> LaserJock: just out of curiosity can a LP adminn move those packages from ubuntu-desktop-effects to my account? im keeping link anyway but just wondering if i should ping one tomorrow about it
[01:57] <LaserJock> gnomefreak: I really don't know. I assume that a database admin could do it, but in general I don't think they like manually mucking around in the DB
[01:57] <LaserJock> but you could always ask ;-)
[01:57] <gnomefreak> LaserJock: ok ty ill try whats worse they can say? no?
[02:00] <LaserJock> pretty much
[02:02] <alex-weej> i have some python code that i want to package up
[02:02] <persia> gnomefreak: Open a support request from answers.launchpad.net asking for the LP accounts to be merged.
[02:02] <alex-weej> i tried to cheat and use dpkg-deb -b but it included all of the file ownership properties
[02:02] <alex-weej> so now i have stuff installed on my system owned by "alex"
[02:02] <alex-weej> how do i do this properly
[02:02] <alex-weej> given that i don't actually have a build process (it's all python)
[02:03] <alex-weej> i just so desperately want to build a package out of this and it's all going against me
[02:04] <LaserJock> dpkg-buildpackage -rfakeroot should work
[02:05] <LaserJock> if you install fakeroot
[02:05] <minghua> "don't cheat"? :-)
[02:05] <alex-weej> is dpkg-deb "cheating"?
[02:06] <RAOF> Yeah, pretty much.
[02:06] <persia> alex-weej: You might want to have a setup.py for your "build process".
[02:06] <RAOF> Even data-only packages like mplayer-themes use dpkg-buildpackage :)
[02:06] <minghua> "fakeroot debian/rules clean && fakeroot debian/rules binary" is probably the bare minimum for building a package
[02:06] <LaserJock> persia, geser: we should have the Debian ftp-master "Grounds for rejection" material "ubuntuized" on the wiki
[02:07] <alex-weej> persia: to do what exactly?
[02:07] <persia> LaserJock: Yes, but also reviewed by the archive admins to adjust for differences (build-dep must be satisifed for main, etc.).
[02:07] <alex-weej> persia: literally nothing needs to be built
[02:07] <alex-weej> persia: unless you want my setup.py to read "pass" :P
[02:07] <azeem> alex-weej: but installed
[02:07] <azeem> doesn't setup.py install things as well?
[02:07] <alex-weej> i don't know
[02:07] <alex-weej> i've never seen one
[02:07] <lifeless> setup.py installs things
[02:07] <alex-weej> i wasn't aware there was a convention
[02:07] <LaserJock> persia: yeah
[02:07] <alex-weej> can i not just use a make file?
[02:07] <minghua> alex-weej: do you have a source package or not?
[02:07] <lifeless> alex-weej: you don't need to install things though
[02:08] <persia> alex-weej: I've not actually packaged anything with python, but other packages seem to use setup.py to install everything to the right locations, and the packaging wrapper scripts use this for a build process.
[02:08] <alex-weej> minghua: no.
[02:08] <LaserJock> minghua: I think the answer is now
[02:08] <lifeless> alex-weej: you can just have debian/rules copy the files to the right places
[02:08] <LaserJock> s/now/no/
[02:08] <lifeless> alex-weej: and then use python-central etc
[02:08] <minghua> LaserJock: yeah, should've guessed earlier
[02:08] <alex-weej> lifeless: i don't see what i can put in the rules script
[02:08] <lifeless> alex-weej: the best thing for you to do is to apt-get source $a-python-project
[02:08] <RAOF> alex-weej: What lifeless said :).
[02:09] <LaserJock> alex-weej: the stuff to install the files
[02:09] <LaserJock> alex-weej: and build a binary package
[02:09] <alex-weej> wait - so i need to "fake" an install?
[02:09] <RAOF> alex-weej: You can check out the specto package, that's pure-python only.
[02:10] <azeem> alex-weej: yes - you install with a DESTDIR of $(curdir)/debian/<package> usually
[02:10] <alex-weej> can i do this without touching autotools?
[02:10] <azeem> dh_builddeb will make a .deb out that tree
[02:10] <azeem> alex-weej: sure, you can run any command in the debian/rules
[02:10] <RAOF> alex-weej: Yes.  You can use the python distutils.
[02:10] <alex-weej> RAOF: tell me more!
[02:10] <RAOF> alex-weej: apt-get source specto :)
[02:10] <alex-weej> done
[02:11] <RAOF> Now, there's a setup.py, which uses python-distutils to do all the installing stuff.
[02:12] <alex-weej> so this is kinda like a python version of a makefile?
[02:12] <RAOF> alex-weej: Indeed.  Exactly so.
[02:12] <alex-weej> still feels like overkill, but i guess i've got to do it at some point
[02:13] <alex-weej> is this stuff re-usable for building rpm?
[02:13] <RAOF> Yes.
[02:13] <RAOF> It's just like a makefile, it'll presumably help when building rpms.
[02:13] <alex-weej> distutils has nothing to do with debian?
[02:13] <alex-weej> ok
[02:13] <RAOF> Indeed.
[02:13] <RAOF> It's part of python.
[02:13] <minghua> LaserJock: is ubuntu-science@tauware.de already moderated?
[02:13] <LaserJock> distutils is like a Makefile for python
[02:14] <LaserJock> minghua: should be yes
[02:14] <minghua> LaserJock: and I assume -motu-science@l.u.c is moderated in the first place?
[02:14] <LaserJock> minghua: hmm, have you gotten any messages from either list?
[02:14] <LaserJock> minghua: yes, as far as I could tell
[02:14] <LaserJock> I haven't used the mailman interface much
[02:15] <minghua> LaserJock: yes, I did, the one from you replying the science edition, on both list.
[02:15] <LaserJock> oh, ok good
[02:15] <minghua> Now I want to reply that, to both list, but I am subscribed with different addresses.
[02:15] <minghua> :-(
[02:16] <LaserJock> oh, well I can change your address in the tauware one
[02:17] <minghua> LaserJock: oh, I remember I can change it myself now.
[02:17] <alex-weej> i don't think i'm cut out for packaging
[02:17] <minghua> LaserJock: I'll do it, thanks for the hint. :-)
[02:17] <LaserJock> alex-weej: it's alright, just take a deep breath :-)
[02:17] <LaserJock> alex-weej: the actual packaging part isn't so bad
[02:18] <RAOF> alex-weej: Once you get past the initial overwhelming, it's actually fairly simple.
[02:18] <LaserJock> if you want to distribute your software you'll mostly likely want to use distutils anyway
[02:18] <alex-weej> i need to build basically 3 packages out of a load of files i have
[02:18] <alex-weej> am i going to need 3 * all this effort?
[02:18] <LaserJock> no
[02:18] <LaserJock> one source packagec can build multiple binary packages
[02:19] <alex-weej> LaserJock: it's actually all just prototype stuff in python atm. i expect to replace some of it with C.
[02:19] <LaserJock> well, it'll be a good character-building experience, as my dad used to always say
[02:19] <alex-weej> oh jeez, thanks :P
[02:21] <LaserJock> actually if you do much python it's probably not bad to learn how to do a setup.py
[02:21] <alex-weej> i'm RTFMing right now
[02:21] <LaserJock> I've done one by just copy-n-modify
[02:21] <LaserJock> and it was only like 10 lines long
[02:22] <alex-weej> it seems very simple for distributing python modules
[02:22] <alex-weej> but i actually need stuff in /etc/xdg/autostart and stuff
[02:22] <LaserJock> well, you could just use a makefile too if you want
[02:22] <LaserJock> I think you can distutils where to install stuff too
[02:22] <alex-weej> maybe that will be easier to knock up
[02:23] <alex-weej> so what do i do, make an installation process
[02:23] <alex-weej> then run it via some fancy tool to make a deb out of it?
[02:23] <LaserJock> something like that ;-)
[02:23] <alex-weej> where am i wrong?
[02:24] <LaserJock> first thing is to be able to build from source
[02:24] <LaserJock> then you can build a source package, debian/rules ,etc.
[02:24] <RAOF> alex-weej: Actually, you can get setup.py to put stuff wherever you want to.  For example, specto installs stuff into /usr/share/icons, eetc.
[02:24] <alex-weej> ok - i have no "build" remember
[02:24] <LaserJock> yes you do
[02:24] <alex-weej> LaserJock: what, the install?
[02:25] <LaserJock> debian/rules is used to build the .deb
[02:25] <persia> alex-weej: If you put everything in the right place with distutils, there are tools that will automatically build a package with all the right pieces.
[02:25] <LaserJock> so the build: rule will be empty, but there's much more to do
[02:25] <minghua> well, you need to be able to give another person a tarball, and instructions of "run the following commands, and it's ready".  Those instructions are the "build".
[02:26] <alex-weej> maybe i should make an actual, bona fide "source" package first
[02:26] <LaserJock> yes
[02:26] <LaserJock> well, make your app "build" from source first
[02:27] <LaserJock> then build a source package (an Ubuntu one)
[02:27] <LaserJock> then build a binary package from the source package
[02:27] <alex-weej> sounds like a plan
[02:29] <alex-weej> i take it in my Makefile i need to provide a means for some tool to change the installation destination?
[02:30] <alex-weej> or can i cheat, here?
[02:30] <alex-weej> with checkinstall or whatever
[02:31] <lifeless> huh
[02:31] <alex-weej> i have /usr/lib/whatever hardcoded in a couple of my files
[02:31] <lifeless> you don't need to do anything to your code, debian/rules can do it all
[02:31] <lifeless> oh, if you have paths in your files you have to fix that
[02:31] <alex-weej> damn
[02:31] <lifeless> you shouldn't need to do that in python, ever.
[02:32] <alex-weej> it's not python
[02:32] <alex-weej> it's .desktop
[02:32] <lifeless> I suggest what you should do is add a setup.py, and read the python distutils documentation
[02:32] <lifeless> such that your .desktop is a created file
[02:33] <alex-weej> this is looking more and more like autotools :(
[02:33] <alex-weej> .desktop.in? :P
[02:33] <RAOF> Yes.  Any sensible source package is going to need to be able to installed where the user wants.  Which means changing such things as Desktop files to point where they need to :)
[02:33] <lifeless> its important to remember that software building is pretty much universal
[02:34] <lifeless> using python does not remove the build process per se
[02:34] <lifeless> building software is in the general sense much more than mere compilation
[02:34] <alex-weej> the only use case i want to support is people double clicking on a .deb file to get some files on their system
[02:34] <lifeless> and autotools exists because there is a problem to be solved; its true that autotools is nasty but thats for different reasons.
[02:35] <alex-weej> and that means that my paths don't need to change (for now)
[02:35] <lifeless> alex-weej: if you only care about Ubuntu, then hardcode the path sure. 
[02:41] <alex-weej> lifeless: ok - for now
[02:41] <alex-weej> i've made a makefile to install my files
[02:41] <alex-weej> and it works
[02:45] <persia> alex-weej: You shouldn't need hardcoded paths in your .desktop file anyway.  The Exec= should be in the $PATH, and the Icon= should be in the icon load path.
[02:45] <alex-weej> persia: the Exec line is "python /usr/lib/blabla"
[02:46] <persia> alex-weej: Create a /usr/bin/blabla.sh file that calls that (or install the executable python to /usr/bin and use #!), and have the .desktop file point to just blabla.
[02:47] <alex-weej> but then if i DO install it to /usr/local, it will be confused for whatever is in /usr
[02:48] <persia> alex-weej: Right.  Sorry.  Have a shell fragment or executable python installed to $(PREFIX)/bin, and expect the user to arrange the path properly so that Exec=blabla works.
[02:48] <RAOF> Yeah, and /usr/local/bin is in $PATH before /usr/bin generally anyway.
[02:49] <alex-weej> ok i meant it the other way
[02:49] <alex-weej> :P
[02:49] <alex-weej> i will sort it out eventually
[02:49] <alex-weej> my biggest problem is figuring out this rules stuff
[02:49] <RAOF> Having stuff in /usr/local/bin will hide stuff in /usr/bin?  That's by design, so that locally installed programs can replace packaged programs.
[02:50] <alex-weej> right but then when i actually want to run /usr/bin/blabla, it will kick off /usr/local/lib/blabla/whatever.py
[02:50] <alex-weej> which i don't want
[02:51] <alex-weej> (unless the paths are hardcoded)
[02:51] <persia> alex-weej: If you have a working distutils-compatible setup.py, http://wiki.debian.org/DebianPython/NewPolicy has some example rules files.
[02:51] <persia> alex-weej: There shouldn't be two things with the same name on the system.
[02:51] <alex-weej> there shouldn't be war in the middle east either... :P
[02:52] <RAOF> alex-weej: Aaah, I see.  You're trying to manually call python on your script?  Either the script doesn't need any other files, or you should be making and installing a python module and importing it into the script.
[02:52] <persia> alex-weej: Right.  So the user is responsible for configuring their personal $PATH to either choose /usr/bin/blabla or /usr/local/bin/blabla depending on what they want.
[02:52] <RAOF> Either way, you don't need to care.
[02:52] <alex-weej> persia: what i'm saying is that calling either /usr/bin/blabla or /usr/local/bin/blabla will actually launch the same python script in /usr/local
[02:52] <alex-weej> which isn't ideal
[02:52] <alex-weej> if i explicitly want to launch the non-local version it should just work
[02:53] <persia> alex-weej: Why would it launch in the undesired place?
[02:53] <alex-weej> because i'm supposedly removing the hardcoded paths from the scripts/.desktop files
[02:55] <persia> alex-weej: PREFIX=$(echo $0 | sed s/(.*)/blabla)//) should allow a shell fragment to pick the right one at runtime, and executable python in bin/ should have the right environment anyway.
[02:55] <RAOF> alex-weej: I'm not quite sure what the problem is.  You want to run "myprog".  If the user has installed a copy of "myprog" into /usr/local/bin, that's what they expect to run.
[02:56] <alex-weej> there is no problem at all
[02:56] <alex-weej> i'm hardcoding the paths. ;)
[03:05] <javier_galicia> coool
[03:07] <alex-weej> this is wayyy more complicated than i thought it was, think i'll have to postpone
[03:08] <alex-weej> sorting this out seems to be more LOCs than my actual program
[03:11] <alex-weej> or maybe i can convince someone here that my software is so cool that they'll be the downstream maintainer ;)
[03:14] <alex-weej> thanks for your help guys, i'll be back to finish the job eventually
[03:14] <RAOF> They'll still want you, as upstream, to actually have a build system :P
[03:14] <RAOF> They might submit one for you, though :)
[03:28] <alex-weej> RAOF: hehe
[03:38] <LaserJock> exit
[03:39] <LaserJock> blah
[04:13] <jrib> is  #!/usr/bin/python  preferred over  #!/usr/bin/env python  ?  I've always preferred the latter but the debian policy menu only mentions the former
[04:14] <RAOF> #!/usr/bin/python.  Using "#!/usr/bin/env python" means that the process shows up as "python" rather than "scriptname" in top, etc.
[04:14] <etank> i just learned something new
[04:14] <etank> thanks RAOF 
[04:15] <jrib> me too, thanks RAOF 
[04:15] <LaserJock> hmm, I've wondered that as well
[04:16] <alex-weej> RAOF: not necessarily true i don't think, an app can call some function to set its name
[04:16] <etank> i met my learning quota for the week :)
[04:17] <RAOF> alex-weej: Probably, but why not just use #!/usr/bin/python and get it for free :)
[04:17] <etank> i have to leave before i learn something else
[04:17] <alex-weej> because your python interpreter might be in /usr/local ;)
[04:17] <jrib> yeah, that's why I think it makes more sense
[04:18] <etank> so does that mean that #!/usr/bin/env pythong is better
[04:18] <alex-weej> import ctypes; libc = ctypes.CDLL("libc.so.6"); libc.prctl(15, "ZOMGNAME", 0, 0, 0)
[04:18] <alex-weej> robbed from cohoba ;)
[04:19] <etank> especially if publishing the script for others on differnt distros to use?
[04:20] <alex-weej> maybe that dun't work actually, :(
[04:20] <alex-weej> it seems to work for killall
[04:21] <alex-weej> but that supposedly is PR_SET_NAME (set process name) from libc
[04:39] <TheMuso> Good afternoon Hobbsee .
[04:40] <Hobbsee> hiya TheMuso 
[04:42] <ajmitch> hello TheHobbsee, TheMuso 
[04:43] <Hobbsee> hi aj
[04:43] <TheMuso> Heya ajmitch.
[04:43] <Hobbsee> hi ajmitch 
[04:44] <ajmitch> now I can see utf-8 stuff properly on irc
[04:44] <LaserJock> hi Hobbsee 
[04:44] <ajmitch> a critical feature
[04:44] <Hobbsee> hiya LaserJock!
[05:13] <TheMuso> superm1: have you fixed up gtk2-engines-blueheart yet?
[05:13] <superm1> TheMuso, not yet.  Just got home.  I'll fix it up tonight
[05:13] <superm1> and upload it
[05:13] <TheMuso> superm1: No hury.Just thought I'd bring it up, as its just about ready to go.
[05:14] <superm1> TheMuso, thx for the reminder.  I'll ping you as soon as i get it up
[05:14] <TheMuso> superm1: np.
[05:19] <superm1> TheMuso, http://revu.tauware.de/details.py?upid=5815
[05:20] <TheMuso> superm1: Ok, will have a look after lunch.
[05:20] <superm1> k
[05:21] <joejaxx> does anyone know how takes care of most of the java-based applications in universe/multiverse?
[05:21] <joejaxx> s/how/who/g
[05:22] <persia> joejaxx: ~motujava
[05:22] <joejaxx> persia: thanks
[05:23] <joejaxx> ah ok interesting
[05:26] <guest> I uploaded a package to REVU a few days ago, but it has not received any comments. How do I go about finding a sponsor for my package?
[05:27] <joejaxx> poke someone about it
[05:27] <persia> guest: Make an annoucement here, with the package name, the current status, and the REVU URL.  You will probably want to do that again for each upload.
[05:28] <joejaxx> persia: have you ever seen this? http://tinyurl.com/2owew2 i thought it was interesting
[05:33] <persia> joejaxx: I hadn't seen that.  Looks like a good presentation, although a little short as documentation :)
[05:33] <guest> Thanks for the response persia. The package name is "imageinfo" and the REVU URL is http://revu.tauware.de/details.py?upid=5780 . Could you please be a bit more specific about the "current status"?
[05:33] <joejaxx> persia: yeah :)
[05:35] <persia> guest: That's perfect.  Status isn't official, so there's no real standards.  I like to know if it's new, it's an upload fixing issues waiting for an advocate, or if it's been advocated or needs a second advocate.  I've also seen people who are having issues with a particular portion say something like "Could you look at the install rule, and help me understand what's wrong?".
[05:37] <guest> persia: Ah, I understand. It's the first upload of this package to REVU, and has no advocates.
[05:58] <guest> persia: Any more status information I should provide?
[06:29] <nixternal> OK, what is the recommendend process if someone uploads to REVU when there is already a package in either Debian or Ubuntu, or both?
[06:29] <nixternal> so far I have gone through 4+ package in a matter of minutes, and we already have the packages
[06:30] <nixternal> I responded with information letting them know this package is in the repos and that a patch to update it either via Debian or Ubuntu is the way to go..am I correct with that?
[06:34] <ScottK> nixternal: Bug fixes or new upstream releases?
[06:34] <nixternal> new upstream releases
[06:34] <ScottK> REVU for that is fine if it looks like someone else isn't active with it.  I did that with libnetaddr-ip-perl.
[06:35] <ScottK> Of course that hadn't been updated in years.
[06:35] <ScottK> And I needed the updated version for a build-dep of another package.
[06:35] <ScottK> IIRC it was the first package I had uploaded.
[06:36] <nixternal> cool...now I feel bad for requesting them to gimme some patchin' love :)
[06:37] <ScottK> New upstreams aren't done with patches.
[06:37] <nixternal> well, I don't mean patches, but getting either Debian to udpate so we can sync/merge
[06:38] <ScottK> OK.
[06:38] <ScottK> It's not rare for someone do upload the same or an older version than we have.  Those should just be archived with a nice note.
[06:39] <nixternal> ya
[06:39] <ScottK> Getting Debian to update is best, of course, but if the maintainer is present, it'd probably already be done and if the maintainer is absent, then it's really tough.
[06:40] <ScottK> Go look at the last time libnetaddr-ip-perl was touched in Debian and ask yourself how I'd have managed to get that updated.
[06:41] <nixternal> hehe, it was the same for krename and almost plucker
[06:42] <nixternal> but it seems there is plucker dev activity again
[06:42] <ScottK> I saw this of course from the perspective of being the vastly experienced 4th newest MOTU whereas you are the newbie 2nd newest MOTU who can benifit from sitting at my feet and learning.
[06:42] <nixternal> I was talking to the DD today and he was excited like a kid in a candy store
[06:43] <ScottK> ;-)
[06:50] <ScottK> ~ 6 hours until the MOTU meeting, so I guess I better go get some sleep.
[06:50] <ScottK> Good night all (including nixternal).
[06:51] <nixternal> hehe, g'nite
[06:51] <nixternal> 6 hours til motu...oh wow
[06:51] <nixternal> that is way to early
[06:52] <ScottK> Agreed.  I have to set the alarm a little earlier than usual.  You being futher west, you might as well just stay up.
[06:53] <nixternal> heck no, I stayed up to late last night
[07:14] <LaserJock> darn, we've got to rotate times once in a while ;-)
[07:18] <nixternal> oh ya, you are 2 hours behind me
[07:18] <nixternal> so you could stay up :)
[07:26] <ajmitch> oh, MOTU meeting tonight?
[07:26] <ajmitch> do I have to be there?
[07:30] <ajmitch> Hobbsee!
[07:30] <Hobbsee> heya RAOF!  going to slug tonight?
[07:30] <Hobbsee> hi ajmitch!
[07:31] <ajmitch> are you going to SLUG, Hobbsee?
[07:31] <RAOF> Hobbsee: No, going to see Transformers with SpockSoc :)
[07:31] <Hobbsee> ajmitch: no idea.  i just realised that it was on tonight, and that i wasnt working
[07:31] <ajmitch> Hobbsee: apparantly there's a MOTU meeting as well
[07:31] <lifeless> say what
[07:31] <Hobbsee> ajmitch: oh really now?
[07:32] <lifeless> SLUG, beer++.
[07:32] <Hobbsee> er?
[07:32] <Hobbsee> lifeless: heh
[07:32] <Hobbsee> lifeless: do you know if Spiv is going?
[07:32] <lifeless> T-90
[07:32] <lifeless> hes not
[07:32] <Hobbsee> right
[07:33] <Hobbsee> lifeless: darn
[07:34] <lifeless> Hobbsee: harass him on #bzr then :)
[07:34] <Hobbsee> lifeless: haha
[07:35] <Hobbsee> hi TheMuso 
[07:35] <Hobbsee> lifeless: i believe TheMuso is being slack, and isnt coming either
[07:35] <Hobbsee> doesnt seem like there will be a high turnout.
[07:36] <jml> Hobbsee: I might go to the next one.
[07:36] <lifeless> jml: next SLUG or next motu meeting?
[07:36] <jml> slug
[07:36] <lifeless> well, at least to the beer beforehand right ?
[07:36] <Hobbsee> lifeless: you and beer...
[07:36] <Hobbsee> lifeless: the promise of beer isnt terribly exciting to me
[07:36] <jml> lifeless: What I know about packaging could be written on the back of a postage stamp
[07:37] <lifeless> Hobbsee: its not exciting, just pleasant to have in the company of friends.
[07:37] <lifeless> Hobbsee: *exciting* is a whole nother ball game.
[07:37] <Hobbsee> lifeless: this is true
[07:42] <TheMuso> Hobbsee: oh thanks.
[07:42] <TheMuso> Hobbsee: Just don't consider my current location.
[07:43] <Hobbsee> TheMuso: hehe.  of course
[08:09] <dholbach> good morning
[08:09] <ajmitch> hey dholbach 
[08:10] <dholbach> hiya ajmitch
[08:11] <\sh> moins
[08:11] <ajmitch> hi \sh 
[08:19] <TheMuso> Hey dholbach.
[08:20] <dholbach> hey TheMuso
[08:37] <TheMuso> nixternal: Ah didn't even think to check whether there was anything similar in the archive. Good catch.
[09:57] <gpocentek> good morning
[09:57] <gpocentek> once again I can't attend today's meeting :(
[09:58] <Hobbsee> :(
[09:58] <dholbach> hey gpocentek
[09:58] <gpocentek> hey Hobbsee, hey dholbach 
[09:58] <Hobbsee> hiya
[09:58] <ajmitch> hey gpocentek 
[09:58] <ajmitch> sorry to hear that
[09:58] <gpocentek> heloo ajmitch 
[09:59] <gpocentek> I've been really really busy these past months but it will change next week :)
[09:59] <ajmitch> finishing up at a job?
[09:59] <gpocentek> (new job)
[09:59] <ajmitch> aha
[10:00] <ajmitch> interesting post on planet debian about the age of packages
[10:00] <ajmitch> I wonder how old some of ours are
[10:04] <persia> ajmitch: Much the same: except for a few exceptions, we probably have all the oldest (including exim-doc-html, last built pre-Warty).
[10:05] <ajmitch> persia: except that we rebuilt everything when it was imported for the first time
[10:06] <ajmitch> I believe we didn't start with a debian binary base
[10:06] <ajmitch> though I may be wrong
[10:07] <persia> ajmitch: As far as I know, everything was rebuilt pre-Warty, and we started from scratch, rather than a Debian binary base, although the build machines at that time ran something more akin to Debian pre-sarge, so the rebuild differences should have been fairly minor (excepting the *really* old stuff).
[10:07] <ajmitch> yeah
[10:08] <ajmitch> we've had full archive rebuilds since then, and thrown away the resulting binaries, to get build logs
[10:08] <ajmitch> they are meant to be a regular thing now
[10:08] <persia> ajmitch: Right, but it's the throwing away of the resulting binaries that is annoying: as Lucas points out, there are improvements to debhelper, the build chain, etc.
[10:09] <ajmitch> yep
[10:09] <ajmitch> we don't know what binaries will fail, eg due to optimisations, etc
[10:09] <ajmitch> all we have is compile logs & a few packages that may have test suites
[10:11] <ajmitch> ouch
[10:11] <ajmitch> can you imagine the churn for users?
[10:11] <shawarma> ...and mirrors.
[10:12] <ajmitch> hey shawarma 
[10:12] <shawarma> ahoy
[10:12] <shawarma> It's not impossible, but it's *very* involved.
[10:12] <persia> ajmitch: WRT churn: aren't users expected to dist-upgrade anyway?  Separately, "partial package updates"?
[10:13] <ajmitch> persia: lots of data files that would unnecessarily be downloaded again
[10:13] <ajmitch> there are ways around redownloading everything
[10:13] <persia> ajmitch: Ah.  Yes.  The delta-download ideas that have been floating about for the past couple years.
[10:13] <ajmitch> users are expected to dist-upgrade, but that only grabs changed packages. your proposal would change *everything*
[10:14] <persia> ajmitch: You should try uqm-music or uqm-voice :)  Also, haven't I made you download vegastrike-data about once a release anyway?
[10:15] <ajmitch> yeah, you have
[10:15] <ajmitch> and I've downloaded uqm-* before :)
[10:17] <persia> ajmitch: Just for fun, it looks like there might be another snapshot pulled before gutsy releases (no, not me).
[10:22] <ajmitch> heh
[10:24] <ajmitch> hi
[10:33] <juss01-bed> hiya ajmitch
[10:43] <StevenK> persia: As long as it works, why rebuild it?
[10:50] <persia> StevenK: It might FTBFS, it might not work, etc.  Essentially, nobody in either Debian or Ubuntu has looked at the package for the last release.  Rebuilding would at least flag FTBFS issues.
[10:51] <man-di> persia: In debian the whole archive is rebuilt weekly to find FTBF
[10:51] <man-di> S
[10:52] <man-di> persia: some developer has access to grid5000
[10:52] <man-di> s/weekly/regularly/
[10:52] <persia> man-di: Right.  Still, that relies on someone fixing it.  At least I've encountered a couple packages that were not rebuilt in Feisty, and became FTBFS due to build-dep changes in the months beforehand.
[10:52] <man-di> he and some helpers report FTBFS as they get them
[10:52] <man-di> persia: right
[10:53] <man-di> persia: I just wanna say that FTBFS are found an reported early
[10:53] <man-di> fixing is another issue
[10:54] <persia> man-di: I think that's a good thing.  Also, if the packages are updated in Debian, Ubuntu will usually pull the fix, which would show as a rebuild for my purposes.  I'm only thinking about the packages that haven't been updated at all  (I remember finding one in Sarge that hadn't been uploaded in over 1000 days).
[10:56] <man-di> persia: http://www.lucas-nussbaum.net/blog/?p=242 might be interesting to you
[10:56] <persia> man-di: That's actually the impetus for me thinking about it again :)
[10:56] <man-di> ah ;-)
[10:57] <RainCT> Hi
[11:08] <siretart> morning
[11:09] <siretart> does anyone happen to know how to make i810 in gutsy to reconsider (reprobe) my external VGA without restarting the x-server?
[11:13] <ajmitch> hi siretart 
[11:16] <siretart> hi ajmitch 
[11:20] <jussi01> hmmm, this is a stupid question, but if it cant find the command make, what package is missing?....
[11:21] <persia> jussi01: `dpkg -S $(which make)` suggests make :)
[11:22] <geser> TheMuso: Hi, we have currently drupal 5.1 twice in the archive: once as drupal-5.1 (source drupal) and drupal5 (source drupal5). Can we drop one?
[11:41] <DarkSun88> Hi all
[11:42] <jussi01> hi DarkSun88
[11:57] <joejaxx> Good Morning Everyone
[12:02] <TheMuso> geser: Yes, drop the drupal source package.
[12:03] <ajmitch> yay, drop drupal!
[12:04] <geser> should we add a Replace:/Conflicts: drupal-5.1 to drupal5?
[12:05] <geser> looks like it isn't necessary
[12:06] <pygi> ajmitch, heh 
[12:08] <TheMuso> geser: I'd say not.
[12:08] <TheMuso> Time to burn a tribe 2 CD.
[12:10] <TheMuso> Does anybody here use CD-RWs for testing?
[12:13] <Hobbsee> TheMuso: i am at the moment, yeah
[12:13] <TheMuso> Are they limited to only burning at 4x?
[12:13] <Q-FUNK> is anyone in core dev working on sound system integration?
[12:13] <StevenK> Depends on your burner and the media
[12:14] <RainCT> can some MOTU please look at Open Invaders (http://revu.tauware.de/details.py?upid=5807, i386 only)? (Source and Binary validate with both lintian and linda.)
[12:14] <TheMuso> StevenK: I know that, but many burners can burn CD-RW at fast speeds, yet much media I have seen only works at 4x.
[12:14] <joejaxx> Hobbsee: haha i just saw your bug lol
[12:14] <StevenK> TheMuso: Also affected by things such as DMA and bus speed.
[12:14] <Hobbsee> joejaxx: :)
[12:15] <joejaxx> Hobbsee: :)
[12:15] <TheMuso> StevenK: I know that, but when one is able to burn CD-Rs at 8/16x speed, its the media.
[12:18] <AndyP> good morning folks
[12:18] <TheMuso> Hey AndyP.
[12:18] <joejaxx> Good morning AndyP :)
[12:21] <AndyP> hey TheMuso, joejaxx :)
[12:21] <joejaxx> :)
[12:23] <afflux> anyone can help me with http://revu.tauware.de/details.py?upid=5804 ? I use dh_pysupport and ${python:Depends} but it doesn't add python to the Depends. Any ideas what's wrong?
[12:29] <ajmitch> afflux: uncomment export DH_VERBOSE=1 & paste the buildlog on pastebin
[12:31] <TheMuso> lol at edubuntu having powerpc+ps3 ports images.
[12:33] <afflux> ajmitch: http://paste.stgraber.org/1926
[12:35] <AndyP> afflux: i just tried building it and it threw an error because there's no configure-stamp rule
[12:36] <afflux> jep, noticed that too
[12:36] <afflux> i'll upload the clean version
[12:36] <afflux> s/clean/cleaner(
[12:36] <afflux> argh... s/(/\// ;)
[12:44] <persia> When a REVU package has been uploaded, and rejected by the archive admins, how many advocates does it need to be reuploaded after the issues are fixed?
[12:45] <dqdev> hello all. Sorry to ask here, but it's quite urgent. A need a library (libg2c.so.0) for 32bit. I have a 64bit machine and this library for the 64bit is installed. But where do I get the one for the 32 bits?
[12:47] <AndyP> dqdev: libg2c0 according to packages.ubuntu.com
[12:47] <dqdev> i should find it there?
[12:47] <afflux> eh, no
[12:47] <afflux> I think he wants lib32g2c0
[12:48] <dqdev> FOUND!
[12:49] <dqdev> cool guys! It works!!! Thanks a million!
[12:52] <TheMuso> Well that was fun. Booted tribe 2 on my notebook, and it got into the GNOME desktop, and froze hard.
[12:56] <joejaxx> :)
[12:56] <joejaxx> it is Tribe 2 :P
[12:56] <TheMuso> I know that
[12:57] <joejaxx> :D
[12:57] <joejaxx> i wonder if tribe 2 will solve my currently arisen IBM HDAPS+Ubuntu problem
[12:59] <geser> MOTU meeting in #ubuntu-meeting now
[01:04] <dholbach> how was yesterdays's MOTU Q&A sessions?
[01:04] <geser> there was one?
[01:04] <Ng> joejaxx: out of curiosity, which problem is that?
[01:05] <dholbach> geser: yes, I was busy with lots of other things, so I didn't realize :-(((
[01:05] <dholbach> maybe we should move them to #ubuntu-motu or #ubuntu-meeting
[01:05] <dholbach> so we don't forget about it in a hurry (not many of us are in #ubuntu-classroom)
[01:05] <geser> was there an announcement for it somewhere?
[01:05] <geser> the frigde didn't list it
[01:05] <crimsun> Q-FUNK: it was my area, but I'm leaving as of Sept.
[01:06] <Q-FUNK> crimsun: oh
[01:06] <crimsun> Q-FUNK: feel free to join the ubuntu-audio LP team and begin there
[01:06] <Q-FUNK> ok
[01:06] <Ng> not that I use it for anything ;)
[01:07] <afflux> In case anyone has an idea about my dh_pysupport problem in http://revu.tauware.de/details.py?upid=5820, feel free to add comments. I'll leave for lunch now. ;)
[01:07] <joejaxx> Ng: everytime i lift my laptop enough for the hdaps to kick in my lcd and backlight turns off and no keyboard input is accepted
[01:07] <dholbach> geser: dunno if there was - we should make sure it's there next time
[01:07] <Q-FUNK> crimsun: I've mainly been going nuts trying to get PA to work out of the box without me having to disable gnome system sounds or stop every other application any time I need to use skype or view youtube.
[01:07] <Ng> joejaxx: erk
[01:07] <joejaxx> Ng: and the only thing i can do is force shutdown
[01:08] <joejaxx> or i could try ssh into my laptop and shut it down that way but i do not have opnssh-server installed at the moment i should probably do that
[01:08] <crimsun> Q-FUNK: I've had the most luck using it in esound integration mode
[01:09] <geser> joejaxx: and then go back and shut it down over ssh?
[01:10] <crimsun> Q-FUNK: meaning installing pulseaudio-esound-compat and pavucontrol, using `asoundconf set-pulsesaudio`, and compiling and installing libflashsupport (http://adhd.irule.net/~crimsun/libflashsupport_feisty/)
[01:10] <joejaxx> geser: well when it happens i will attempt to ssh in and shut it down instead of force shutdown
[01:14] <joejaxx> and the bad thing is
[01:14] <joejaxx> this happens on feisty
[01:17] <Adri2000> ScottK: can we do the DaDandMoM item before clamav? because Lutin is a bit busy atm and he is going to leave
[01:18] <ScottK> OK with me.
[01:18] <Hobbsee> what exactly is this item about?
[01:18] <Q-FUNK> crimsun: come again, about the asoundconf part?
[01:19] <Adri2000> ScottK: thanks
[01:19] <Adri2000> Hobbsee: we sent a mail about it, wikipage: https://wiki.ubuntu.com/DaDandMoM
[01:19] <Hobbsee> Adri2000: i saw tha tmuch
[01:19] <crimsun> Q-FUNK: asoundconf set-pulseaudio  is a convenience macro available as of Feisty; executing it from the command prompt configures ~/.asoundrc and ~/.asoundrc.asoundconf as appropriate
[01:19] <ScottK> StevenK: Did you see my devscripts whining in the scrollback about Bug #78165
[01:19] <ubotu> Launchpad bug 78165 in devscripts "debuild fails to use seahorse-agent or gpg-agent" [Unknown,Confirmed]  https://launchpad.net/bugs/78165
[01:20] <StevenK> I did. You might have seen me talking about it in -devel, too.
[01:20] <Q-FUNK> crimsun: any way to use this gloally?
[01:20] <crimsun> Q-FUNK: the workhorse is the PulseAudio alsa-lib plugin located in the libasound2-plugins binary package, which is a Recommends of the pulseaudio binary package.
[01:21] <siretart> has there been a decision about REVU in #ubuntu-meeting? I see only arguments, but no conclusion.
[01:21] <crimsun> Q-FUNK: sure, cp ~/.asoundrc.asoundconf to /etc/asound.conf afterward
[01:22] <persia> siretart: About REVU days?  It will become an agenda item.
[01:22] <ScottK> StevenK: No,  I haven't read the devel scrollback yet.
[01:22] <siretart> persia: aha? ok.
[01:23] <StevenK> ScottK: Ah ha
[01:23] <ScottK> siretart: I was just making a joke about since you were late for the meeting you got volunteered for things because you weren't there to defend yourself.
[01:23] <StevenK> [21:05]  < StevenK> cjwatson: My plan at this point is to take DISPLAY, 
[01:23] <StevenK>                    GNOME_KEYRING_SOCKET and XAUTHORITY, and put them somewhere, 
[01:23] <StevenK>                    clean out the environment, run dpkg-buildpackage with -uc 
[01:23] <StevenK>                    -us, add the three back and invoke debsign.
[01:23] <ScottK> StevenK: Sounds excellent to me.
[01:23] <crimsun> Q-FUNK: the GUI to handle this will be part of asoundconf-ui (https://launchpad.net/asoundconf-ui)
[01:24] <ScottK> For gpg-agent, it looks like DISPLAY is all that's needed,
[01:24] <ScottK> That's all I set and it works fine.
[01:24] <ScottK> StevenK: Thanks.
[01:24] <Q-FUNK> crimsun: nice
[01:24] <StevenK> ScottK: seahorse-agent needs GNOME_KEYRING_SOCKET, and maybe XAUTHORITY.
[01:25] <ScottK> OK.  I think there's no harm in setting them.
[01:25] <StevenK> And it won't affect the build.
[01:25] <persia> StevenK: seahorse-agent works fine for me with only DISPLAY
[01:25] <StevenK> Wanna bet? debuild is a *mess*
[01:25] <StevenK> And I get paid to write Perl.
[01:27] <ScottK> StevenK: No.  Don't wanna bet.  All Perl I read looks like a mess, so I can't tell the real messes from regular perl.
[01:28] <StevenK> Heh
[01:28] <geser> StevenK: and what about reading perl?
[01:29] <ScottK> geser: No one reads perl. It's a write only language.
[01:29] <StevenK> Heh
[01:30] <ScottK> geser: Note that StevenK doesn't argue that point.
[01:30] <StevenK> Of course I don't, I agree.
[01:33] <crimsun> sorry to bail; movers are here.  Offline until sometime Monday (2 Jul)
[01:33] <ajmitch> bye crimsun 
[01:33] <ScottK> crimsun: Enjoy the move.
[01:33] <Q-FUNK> bye crimsun
[01:33] <ScottK> ;-)
[01:35] <ScottK> On a project I'm working on the main dev needed a Ruby library after having used a Perl library.  Despite having worked with/customized the Perl library for several months, when he got confused by the RFC, he went and got the Python library to use as a reference...
[01:37] <TheMuso> c
[01:37] <TheMuso> ugh
[01:53] <Q-FUNK> interesting.  crimsun's config trick works out of the box on feisty.  :) however, the sound output is choppy. :(
[02:15] <TheMuso> Where do I find the desktop effects in gutsy for GNOME?
[02:15] <xxxxx1> morrrning all
[02:15] <xxxxx1> :)
[02:15] <siretart> hi xxxxx1 
[02:21] <TheMuso> nvm, found it.
[02:22] <TheMuso> thats weird. Won't let me use them on a Radeon 7500, yet in Feisty, it works fine.
[02:22] <ajmitch> dri problems?
[02:22] <StevenK> It's using vesa?
[02:23] <ScottK> StevenK: I've now read the -devel scrollback.  Thanks for taking on the devscripts bug.
[02:24] <TheMuso> dunno. Need to look.
[02:38] <TheMuso> Ah ok, AGP failed to initialize, disabling DRI.
[02:39] <TheMuso> Sounds like a kernel thing.
[02:40] <DarkMageZ> i'm attempting to build a new package. but during the configure it bums out cause it can't find opengl. so i fed it libglu1-mesa-dev but it's still not happy. what else could it be after?
[02:41] <AndyP> DarkMageZ: you might need to be more explanatory than "bums out" :)
[02:41] <StevenK> libglu1-mesa-dev is not OpenGL
[02:42] <StevenK> libgl1-mesa-dev is, however
[02:42] <DarkMageZ> StevenK, libgl1-mesa-dev is a dependency of libglu1-mesa-dev
[02:43] <DarkMageZ> AndyP, complains about no opengl and quits.
[02:44] <persia> DarkMageZ: You may get a better response with a URL to a pastebin of the buildlog.
[02:45] <ScottK> Just for something completely different.
[02:47] <DarkMageZ> here's what i get when i tell pbuilder to build it. http://pastebin.ca/595277
[02:57] <DarkMageZ> nvm. it was after glut3
[03:03] <ScottK> The ubuntu-clamav team is created if anyone is motivated to join....
[03:03] <pygi> :)
[03:11] <StevenK> ScottK: Guess what?
[03:11] <ScottK> Yes?
[03:11] <StevenK> -rw-r--r-- 1 steven users 395K 2007-06-29 23:07 devscripts_2.10.5ubuntu1_amd64.deb
[03:11] <ScottK> Cool.
[03:12] <StevenK>       + Keep DISPLAY, XAUTHORITY and GNOME_KEYRING_SOCKET environment variables around for safe keeping before we destroy the environment, and re-set them before running debsign. (LP: #78165)
[03:12] <StevenK> I'm still chuckling to myself over "before we destroy the environment"
[03:12] <ScottK> Yes, very good.
[03:14] <StevenK> ScottK: Would you be willing to test it?
[03:14] <ScottK> Sure, but I need -i386 (I'll build it).
[03:16] <StevenK> I'm happy to do so, I just threw it at sbuild which is amd64 only for the time being because I'm still not sure if I want to move in with it.
[03:18] <StevenK> ScottK: Same, since it's 11:18pm
[03:18] <StevenK> ScottK: http://wedontsleep.org/~steven/devscripts_2.10.5ubuntu1_i386.deb
[03:19] <ScottK> StevenK: Assuming this is good, you'll send the patch to Debian?
[03:19] <Adri2000> StevenK: you got my patch for devscripts?
[03:19] <StevenK> Adri2000: Yes, that's applied too.
[03:19] <Adri2000> cool
[03:20] <StevenK> Adri2000: Just don't do +++ scripts/requestsync.py.new, that irritates me because then I have to edit the patch
[03:21] <Adri2000> right :)
[03:21] <ScottK> StevenK: Just thought to ask this ...  This'll install OK on Feisty, right?
[03:22] <StevenK> Actually, it won't.
[03:22] <ScottK> OK.
[03:22] <ScottK> Glad I asked.
[03:22] <StevenK> Rebuilding it for Feisty, hold on.
[03:22] <ScottK> OK.  Sorry I forgot to mention that.
[03:24] <Adri2000> StevenK: I don't see the fix for bug #119313 in the changelog
[03:24] <ubotu> Launchpad bug 119313 in devscripts "requestsync can't handle third parameter (basever) but advertises it in usage" [Low,Confirmed]  https://launchpad.net/bugs/119313
[03:25] <StevenK> Adri2000: Right, I'll mention that.
[03:26] <StevenK> ScottK: Download it again, should be fine
[03:26] <ScottK> OK
[03:27] <Adri2000> 16:24:07 <Adri2000> * requestsync: - Don't confirm the bug when -s (sponsorship) is passed - Giving base version as a third argument works again, thanks  Kjell Braden (LP: #119313)
[03:27] <Adri2000> StevenK: you probably didn't get it, because it didn't hilight you
[03:29] <ScottK-laptop> StevenK: http://paste.ubuntu-nl.org/27765/ - Urgh.
[03:30] <StevenK> I can Conflict against it. :-)
[03:31] <ScottK-laptop> That's a dependency of all the kde-dev stuff.
[03:31] <StevenK> Like I said ... :-)
[03:31] <ScottK-laptop> I'll remove it to test your fix, but ....
[03:32] <StevenK> Yeah, not sure what to do about that one.
[03:32] <StevenK> Let me think about it.
[03:32] <persia> ScottK-laptop: That's an outstanding issue anyway (and what drove me to sbuild rather than debuild).
[03:32] <StevenK> Adri2000: Changelog updated locally, thanks.
[03:33] <ScottK-laptop> The fix works great with gpg-agent/pinentry-qt.
[03:33] <ScottK-laptop> StevenK: Thanks.
[03:35] <persia> StevenK: Would you mind pushing the sbuild (amd64) output to wedontsleep?  Alternately, I'll take source :)
[03:35] <StevenK> persia: http://wedontsleep.org/~steven/devscripts-buildlog
[03:37] <persia> StevenK: Um.  My apologies - I'm painfully unclear :(  I meant the binary .deb, so I could comply with the previous request for seahorse testing.
[03:38] <StevenK> Ah ha.
[03:38] <StevenK> persia: It is for gutsy, is that okay?
[03:38] <persia> StevenK: Sure.
[03:39] <StevenK> persia: http://wedontsleep.org/~steven/devscripts_2.10.5ubuntu1_amd64.deb
[03:40] <persia> Just to make sure I'm testing the right thing: I should remove DEBUILD_PRESERVE_ENVVARS=DISPLAY from ~/.devscripts, build something, and see if it gets signed?
[03:41] <StevenK> Well, see if it runs seahorse-agent, so yes.
[03:42] <persia> Appears to work fine :)
[03:43] <StevenK> Excellent.
[03:44] <StevenK> Adri2000, ScottK: I'm going to ponder this kdesdk-scripts thing, so I won't upload yet.
[03:45] <StevenK> persia: Does that kdesdk-scripts versus devscripts have an LP bug?
[03:45] <ScottK> StevenK: Can't you just use update-alternatives for that file?
[03:45] <persia> StevenK: Not to my certain knowledge (although I haven't searched).
[03:45] <StevenK> ScottK: It's one possibility. Another is to fix kdesdk-scripts.
[03:46] <ScottK> Is it inherently broken?
[03:46] <ScottK> Is there a valid reason for it to have it too?
[03:46] <StevenK> Depends if they're different.
[03:46] <StevenK> At this point, I need to investigate further.
[03:47] <ScottK> OK.  Thanks for the fix.
[03:47] <dholbach> Can somebody please confirm that https://wiki.ubuntu.com/MOTUMenuHeader is what we agreed on in the meeting?
[03:47] <dholbach> I don't want to announce something wrong
[03:48] <persia> dholbach: Looks right to me, but I might add both REVU days to save and update issues next week.
[03:49] <dholbach> ah right, yes
[03:49] <persia> s/and/any/
[03:49] <dholbach> done... cheers
[03:54] <persia> So, if a package on REVU was uploaded, and rejected by the archive admins, what's the policy on reuploading with fixes?  Does it need two new advocates?
[03:58] <persia> ScottK: We could collude :)
[03:59] <Hobbsee> i'm assuming you wouldnt need 2 again
[03:59] <Hobbsee> i'm assuming 1 would suffice
[04:00] <dholbach> yeah
[04:00] <Hobbsee> seeing as the only thing that had changed was the licencing
[04:00] <Hobbsee> which will go for the admin's approval again anyway
[04:00] <persia> Right then.  On the strength of those responses, I'm uploading :)
[04:00] <ScottK> persia: Which package?
[04:00] <persia> ScottK: gizmod
[04:00] <ScottK> Ah.
[04:03] <ScottK> EthanP: I'm on my way out the door, but we had the meeting already.
[04:03] <ScottK> EthanP: See the ubuntu-clamav team on LP.
[04:03] <EthanP> Yeah -- sorry about that
[04:03] <ScottK> No problem.
[04:03] <EthanP> LP?
[04:04] <ScottK> Launchpad
[04:05] <ScottK> EthanP: Maybe persia will educate you as I really need to be leaving. 
[04:05] <EthanP> Scottk:  Right on, I think that I may have found something
[04:06] <persia> EthanP: It'll be a while before the minutes are posted (I'm to bed soon), but the transcript is available from http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-current.html
[04:06] <EthanP> Persia:  Awesome, thanks
[04:06] <ScottK> https://launchpad.net/~ubuntu-clamav in case you didn't find it.
[04:06] <ScottK> Bye all.
[04:15] <RainCT> btw, did my mail about Open Invaders arrive to the MOTU mailing list?
[04:16] <Hobbsee> yes
[04:21] <persia> RainCT: That's probably not the best place to advertise though - people on IRC tend to have more time than those only reading mail :)
[04:22] <RainCT> persia: ok. saw some request there and thought I'd send it too :p
[04:22] <CrummyGummy> Hi all, I have a debian deb and I want to convert it into and ubuntu deb. What is the easiest way to do this? Or is there no easy way?
[04:23] <RainCT> CrummyGummy: well, they are the same
[04:24] <persia> CrummyGummy: If you have a dsc, just recompile for Ubuntu.  If you only have a .deb, you can se if it works (it often doesn't).
[04:25] <CrummyGummy> Thanks
[04:54] <AnAnt> Hello, if I get a source package from Debian repos & build it under Ubuntu, then I found a bug, is it appropriate to report it to Debian guys ?
[04:54] <AnAnt> or should it be built/installed in Debian to do so ?
[04:56] <RainCT> AnAnt: it should be reported to Debian :)
[04:57] <AnAnt> RainCT: well, I just asked at Debian, they said that I should install it under Debian first before reporting bug :)
[04:59] <RainCT> AnAnt: yes, but if you didn't change anything it will probably be there (unless it's related on a dependency or something)
[04:59] <AnAnt> RainCT: ok, here's what happened
[04:59] <AnAnt> RainCT: I found that the problem is that it doesn't work in Feisty, but it worked in Gutsy
[05:00] <RainCT> AnAnt: ah, then it's not a Debian problem
[05:08] <AnAnt> RainCT: ok, thanks
[05:08] <RainCT> yw
[05:19] <RainCT> can some MOTU please look at Open Invaders (http://revu.tauware.de/details.py?upid=5807, i386 only)?
[05:49] <DaveMorris> hey guys.  Is there an official way to request for programs to be packaged and added to the repo's
[05:49] <Hobbsee> file a bug, with a needs-packaging tag
[05:50] <DaveMorris> under what though? 
[05:51] <RainCT> DaveMorris: https://bugs.launchpad.net/ubuntu/+filebug
[05:51] <Hobbsee> ubuntu
[05:51] <DaveMorris> thanks
[05:52] <nixternal> http://livestream.fsf.org:8800
[05:52] <nixternal> ya, I am spamming that :)
[05:52] <nixternal> 10 more minutes until gplv3 announcement!
[05:54] <sacater> peanutb: hi
[05:54] <sacater> peanutb: you present?
[05:54] <RainCT> nixternal: any human-readable page about what GPL3 features that GPL2 hasn't?
[05:55] <nixternal> it is there somewhere...I was just looking at it the other day
[05:55] <jussi01> hello all
[05:57] <nixternal> hiya jussi01 
[05:57] <jussi01> hey nixternal
[05:57] <jsgotangco> hi
[05:57] <nixternal> howdy jsgotangco 
[05:58] <jsgotangco> hey
[05:58] <Toadstool> g'morning everybody!
[05:58] <nixternal> do you know if your family here got hit hard by the rains this week?
[05:58] <nixternal> howdy Toadstool 
[05:58] <nixternal> mornin' here as well :)
[05:58] <Toadstool> heya nixternal 
[05:58] <jsgotangco> nixternal: nope they're fine
[05:58] <jussi01> morning Toadstool
[05:58] <nixternal> oh wait, you are a little earlier than me as well
[05:58] <nixternal> jsgotangco: good to hear...there was a lot of damage
[05:58] <Toadstool> nixternal: yeah, 9am here
[05:58] <jsgotangco> yeah i heard
[05:59] <nixternal> California time! maybe one day I will live there again, but my plans seem to be taking me east now
[05:59] <Toadstool> hi jussi01 
[05:59] <jussi01> @now helsinki
[05:59] <ubotu> Current time in Europe/Helsinki: June 29 2007, 18:59:36 - Next meeting: Technical Board in 4 days
[05:59] <Toadstool> nixternal: I wish I could stay longer but I have to go back to France in september :/
[06:00] <nixternal> hehe, California can get addicting for sure
[06:01] <Toadstool> hmm, looks like I missed yet another MOTU meeting 
[06:01] <jsgotangco> how come the chicago tribune prioritized iphone coverage over taste of chicago
[06:01] <jsgotangco> heh
[06:06] <nixternal> money?
[06:31] <RainCT> can some MOTU please look at Open Invaders (http://revu.tauware.de/details.py?upid=5807, i386 only)?
[06:37] <geser> RainCT: looking at Open Invaders: why do you need the libs in Build-depends?
[06:37] <RainCT> geser: it isn't building without them, or?
[06:38] <geser> normally you only need the -dev packages
[06:39] <geser> e.g. libxext-dev depends on libxext6. so you don't need to list libxext6 in B-D
[06:39] <RainCT> ah ok
[06:40] <geser> installing libxext-dev will install lbxext6 and it's dependencies
[06:40] <RainCT> ok let me check the build dependencies
[06:40] <geser> you also don't need to list libstdc++6-4.1-dev there. it's an indirect dependency from build-essential
[06:42] <RainCT> ok, that's all?
[06:42] <geser> you could test if Build-Depends: debhelper (>= 5), autotools-dev, libdumb1-dev, libaldmb1-dev, liballegro4.2-dev, libxext-dev, docbook-to-man is enough
[06:43] <geser> I did get further yet with reviewing
[06:47] <geser> RainCT: drop the "A" from Description (see http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis)
[06:53] <geser> RainCT: I see that you have usr/include/open-invaders in debian/dirs. Does this game install headers?
[06:54] <RainCT> Hobbsee: I think that's cleaner, don't like rule files :p
[06:54] <geser> RainCT: you are missing dpatch in Build-Depends
[06:54] <Hobbsee> ahhh
[06:55] <RainCT> geser: yes, there are header
[06:55] <RainCT> s/header/headers
[06:56] <RainCT> files that get installed: http://paste.ubuntu-nl.org/27797/
[06:56] <geser> does it support plugins or for what one could use the headers?
[06:59] <RainCT> geser: eh.. dunno :p
[06:59] <geser> if there is no use for the headers don't put them inside the deb
[07:00] <RainCT> geser: how can I do that? (that they don't get installed)
[07:00] <AndyP> man-di: that's weird... doesn't the license just have a non-redistribution clause?
[07:01] <man-di> no
[07:01] <man-di> AndyP: its packaged for debian and synced into Ubuntu main
[07:02] <geser> RainCT: one solution would be to rm the usr/include dir after calling make install in debian/rules
[07:02] <man-di> I spoke with one of the debian maintainers of the driver and he said he has big problem with upstream and he needs to check each single file in the package if its allowed to be distributed
[07:03] <geser> RainCT: if you are in contact with upstream you could bring to their attendtion that the FSF address in src/*cc is outdated
[07:03] <AndyP> man-di: you're right, that's rather annoying
[07:04] <man-di> AndyP: the bad thing is that I need a package for a printer of our company which is supported by another package from the same author
[07:04] <geser> RainCT: that's all I've found
[07:06] <RainCT> geser: ok thanks
[07:08] <geser> np
[07:12] <geser> have you also added dpatch to B-D?
[07:14] <RainCT> yes
[07:40] <RainCT> builded :)
[07:42] <RainCT> geser: is this normal (on Feisty)? "Error: Dependency is not satisfiable: libc6"
[07:43] <RainCT> ok nevermind :p
[08:24] <RainCT> geser: rm: cannot remove `usr/include/open-invaders/': No such file or directory
[08:27] <geser> have you tried with debian/tmp/usr/include/open-invaders/ ?
[08:28] <RainCT> yes, but let me try again, had put it on the wrong place :$
[08:28] <RainCT> have I said I don't like rule files? lol
[08:55] <RainCT> geser: no, isn't working :(
[08:55] <RainCT> I've tried with debian/tmp/usr/include/open-invaders/, usr/include/open-invaders/ and debian/usr/include/open-invaders/ (why not? :P)
[08:56] <geser> still the error: No such file or directory?
[08:56] <RainCT> yes
[08:56] <RainCT> (I put it on debian/rules just after   $(MAKE) DESTDIR=$(CURDIR)/debian/open-invaders install)
[08:57] <geser> I've only an amd64 here so I can't test the build myself
[08:59] <RainCT> geser: isn't it possible to avoid those files installing in another way? like with a parameter on the ./configure or something?
[09:00] <geser> you can still patch the Makefile to not install them
[09:00] <pygi> o no, rproenca is back!
[09:00] <RainCT> geser: how can I do this?
[09:00] <rproenca> pygi: hi. :)
[09:01] <rproenca> pygi: Have you already started the development of that python binding for libisofs?
[09:01] <RainCT> geser: I'm thinking.. what's about set the include dir to /tmp/crap and try to delete that? lol
[09:02] <pygi> rproenca, hahaha
[09:02] <pygi> rproenca, did you? XD
[09:02] <RainCT> geser: or would that be the same?
[09:03] <rproenca> pygi: nops, I gues :P
[09:03] <rproenca> *guess
[09:03] <pygi> rproenca, that's bad
[09:05] <geser> RainCT: as I can't test the build, I can't provide you a solution, sorry
[09:08] <RainCT> geser: GOT IT :D
[09:08] <RainCT> geser: $(CURDIR)/debian/open-invaders/usr/include/open-invaders/
[09:19] <rgl> hi
[09:20] <Kmos> rgl: boas
[09:21] <rgl> I need to create a package for dovecot sieve plugin, but I have some doubts about it.  To build the plugin, the dovecot sources (arealy built) need to be arround... how can I make a package like this?
[09:24] <pygi> rgl, build depend on dovecot-dev if something like that exists? :)
[09:24] <rgl> pygi, there is no -dev pkg no :|
[09:25] <rgl> pygi, so the first step is to create one? :D
[09:25] <pygi> rgl, heh, no
[09:25] <RainCT> geser: thanks :)
[09:25] <rgl> pygi, dovecot does not really have .so files.
[09:25] <pygi> rgl, got it =)
[09:25] <RainCT> some MOTU please review Open Invaders http://revu.tauware.de/details.py?upid=5822 (i386 only)
[09:26] <RainCT> geser: (you can't advocate if you don't try to build it, or?)
[09:26] <rgl> pygi, humm, so what shold I do then? :D
[09:32] <geser> RainCT: I wouldn't feel confident without a test build to advocate it
[09:34] <rgl> gag!  the sieve plugin is already bundled with the package!   so sweet!
[09:34] <pygi> rgl, :)
[09:36] <YannDinendal> hi
[09:36] <jekil> i have a trouble with cdbs, any hint? http://rafb.net/p/WsTVCK82.html
[09:37] <YannDinendal> http://revu.tauware.de/details.py?upid=5794 nixternal asked me to "possibly create a patch for the update and file a bug on Launchpad" because this is a new version of an existing package
[09:37] <YannDinendal> but I don't know how to do...
[09:41] <coreymon77> hi everyone
[09:41] <coreymon77> is nayone here
[09:45] <coreymon77> hi
[09:45] <peanutb> hello
[09:46] <coreymon77> im wondering how i can submit to get a program into the apt repos
[09:46] <peanutb> I dont really know
[09:47] <Nafallo> !revu
[09:47] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[09:48] <Nafallo> coreymon77: ^
[09:48] <coreymon77> its not really an ubuntu package
[09:48] <coreymon77> and not mine either
[09:48] <coreymon77> im jsut helping the person out
[09:48] <coreymon77> its a podcatching program called icepodder
[09:48] <coreymon77> its the continuation of the ippoder/castpodder project
[09:48] <Nafallo> coreymon77: then tell him to put it on revu? :-)
[09:49] <Nafallo> !info icepodder
[09:49] <ubotu> Package icepodder does not exist in feisty, feisty-seveas
[09:49] <Nafallo> !info icepodder gutsy
[09:49] <ubotu> Package icepodder does not exist in gutsy
[09:49] <coreymon77> the developer wants to get it onto the repos, but jsut hasnt had the time
[09:51] <RainCT> some MOTU please review Open Invaders http://revu.tauware.de/details.py?upid=5822 (i386 only)
[09:58] <ScottK> coreymon77: The odds of someone else having more time/being more motivated are low.
[09:59] <coreymon77> what he means by not having enough time is that he doesnt knwo how to get it up there and is too busy with the program to look, but said that if anyone can find it out for him, he would be more than glad to do it
[10:00] <ScottK> RainCT: Diff eyeballs well.  My machine I test with isn't currently up and running, so I'm not going to build it now, but it looks pretty good at a glance.
[10:01] <jekil> i have a trouble with cdbs, any hint? http://rafb.net/p/WsTVCK82.html
[10:02] <ScottK> Anyone who is interested in testing/packaging clamav and it's redepends for in-service Ubuntu releases, join up here: https://launchpad.net/~ubuntu-clamav/+members
[10:03] <RainCT> :)
[10:04] <sommer> I'd like to help test clamav...just joined
[10:05] <ScottK> Ah.  There you are.  You might want to update your LP profile to include your IRC nick.
[10:05] <ScottK> sommer: What Ubuntu versions are you running?
[10:06] <sommer> ScottK: Feisty, but plan to have Gutsy T2 installed this weekend.
[10:06] <sommer> I'll update the nic too...thanks for the heads up
[10:06] <ScottK> OK.  I approved your membership.  
[10:06] <ScottK> sommer: What do you use clamav with?
[10:07] <sommer> ScottK: currently using it with clamav-milter to scan internal mail.
[10:07] <ScottK> OK.  That'd be good to test.  Using Sendmail or Postfix?
[10:08] <sommer> ScottK: sendmail
[10:08] <ScottK> Good.
[10:10] <ScottK> sommer: Go to https://wiki.ubuntu.com/MOTU/Clamav and volunteer yourself as a clamav-milter person.
[10:11] <ScottK> EthanP: You too ^^^ for whatever you are using.
[10:11] <EthanP> ScottK:  I was wondering -- what's the advantage of backporting ClamAV versus just rolling a new binary?
[10:11] <ScottK> EthanP: Not sure what you mean?
[10:11] <sommer> ScottK: will do.
[10:14] <xxxxx1> bye all
[10:15] <EthanP> ScottK: I read the meeting notes and it sounded like you want to backport V7's Clam package, but were suggested that the deps were seriously different.  I'm wondering, if it's that difficult, why backport?
[10:15] <EthanP> ScottK: Or am I seriously misunderstanding the situation (very likely) :)
[10:18] <ScottK> The clamav is Dapper and Edgy has a large number of security vulnerabilities and is effectively unsupportable.
[10:19] <sommer> EthanP: could you point me in the direction of those meeting notes?  I'm feeling a little behind...heh
[10:19] <EthanP> Sommer:  Sure -- give me a sec
[10:19] <ScottK> So, if you want a current/useable clamav package you need at least 0.90.2.
[10:19] <EthanP> http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-current.html
[10:19] <sommer> thanks
[10:19] <ScottK> Unfortunately there are interface changes and so you can't just backport clamav without backporting updates to the stuff that uses it.
[10:21] <EthanP> Right -- from the sound of it, you wanted to backport the binary.  I don't know the Ubuntu specifics all that well, but why backport when you can roll an all new binary with .90.2 -- or will it have new deps no matter what?
[10:21] <EthanP> ScottK:  Nevermind -- I just re-read your least message
[10:21] <ScottK> It will have new deps no matter what.  We'll backport the source and build it for the target environment.
[10:21] <ScottK> OK.
[10:21] <ScottK> It's painful no matter how you slice it.
[10:22] <ScottK> EthanP: Welcome to the club.
[10:22] <EthanP> Now that I think about it, I had to update a whole lot of stuff to get it to build.
[10:22] <EthanP> mostly development libraries, IIRC
[10:23] <EthanP> Ack!  It's coming together in my head really slowly.  So you're saying that I just broke a whole bunch of apps that may use ClamAV on my production server.  ...greeeeeeeat
[10:25] <ScottK> EthanP: Did you compile it directly or use an Ubuntu package from a later release?
[10:25] <EthanP> Built directly from a tarball
[10:25] <ScottK> OK.
[10:26] <ScottK> EthanP: What are you runnig that uses clamav?
[10:26] <EthanP> MailScanner
[10:26] <ScottK> Oh, right.  Forgot about that discussion.
[10:26] <ScottK> From an Ubuntu package?
[10:26] <EthanP> nope -- installed from source
[10:27] <sommer> ScottK: you don't like MailScanner?
[10:27] <EthanP> Sommer:  It reportedly has issues with Postfix
[10:27] <ScottK> sommer: Not with Postfix, no.  With other MTA's it's probably fine.
[10:28] <sommer> ah
[10:28] <sommer> I use it with sendmail...seems to work well.
[10:28] <minghua> anyone can give some suggestions about packaging an upstream that only builds executable binaries and static library?
[10:28] <ScottK> EthanP: You might want to send a test message with one of the EICAR virus test signatures in it and see if it gets detected.
[10:29] <EthanP> ScottK:  Oh, I've totally tested it.  I used eicar, and then a newer (real) virus that .82 wasn't able to pick up due to the new signature format
[10:29] <ScottK> sommer: With Postfix the use internal private interfaces to integrate and they don't get it right.  They lose mail.
[10:30] <ScottK> EthanP: Then you're likely OK.  If you installed a current mailscanner and a current clamav, it's probably fine.  This is the kind of thing I want this team to test out.
[10:30] <EthanP> (I used "Trojan.Small-2631")
[10:30] <ScottK> If it finds any of them, it'll find all of them.
[10:30] <EthanP> ScottK: I still need to update MailScanner
[10:30] <ScottK> Ah.
[10:31] <ScottK> EthanP: You need to look into amavisd-new is what you need to do....
[10:31] <ScottK> ;-)
[10:31] <EthanP> Yeah, I looked at that.  I may do it, but will update MailScanner from source in the meantime.
[10:31] <ScottK> OK.  It's your mail to lose in the meantime.
[10:32] <EthanP> I have never had a problem with ti dropping mail
[10:32] <ScottK> It's not frequent.  It comes up about once a month on postfix-users.
[10:33] <EthanP> So it *does* happen.  It sounded like it was only likely to happen if the postfix API changed
[10:33] <EthanP> (maybe, once again, I didn't read carefully enough)
[10:34] <ScottK> It definitely happens when the Postfix API changes (lots) it happens rarely otherwise, but happens.
[10:34] <EthanP> Isn't the Postfix API supposed to be stable?
[10:34] <ScottK> As I said the other day, the fact that the Mailscanner devs absolutely do not understand the dangers of using internal private interfaces makes all their product suspect in my book.
[10:35] <EthanP> aha
[10:35] <ScottK> EthanP: It's the internal interfaces that are the problem 
[10:35] <EthanP> So MailScanner should be using the external interfaces -- ie the mail queues?
[10:35] <ScottK> The Postfix devs are VERY careful with the documentation and stability of the public interfaces.
[10:36] <ScottK> Actually they use the mail queues which are internal for Postfix.  They should be using SMTP, LMTP, or a pipe to connect.
[10:36] <EthanP> oic
[10:36] <ScottK> Their attitude seems to be that queue file formats SHOULD be public/stable, so we are going to pretend that they are.
[10:37] <ScottK> Scares the daylights out of me.
[10:37] <jussi01> arrrggh... pink...
[10:37] <EthanP> Yeah -- all of my shell scripts work with around MailScanner too -- using the internal queues
[10:37] <ScottK> As I said, your mail to lose if you mess it up.
[10:38] <ScottK> The only issue that comes up more often is Cisco Pix SMTP fixup.
[10:38] <EthanP> Now, if I only had time to set up AMAVIS.
[10:38] <EthanP> Oh great, we're behind a PIX 515.
[10:39] <ScottK> Just turn the effing SMTP fixup off.  Even if it worked, you wouldn't need it.
[10:39] <jerome_> ScottK: if it builds under feisty it's enough , or I should also test for gutsy ?
[10:39] <ScottK> jerome_: Which?
[10:39] <EthanP> FWIW, we move 10K messages a day across this server and (AFAIK) have not dropped a single one.  But ima look into what it will take to build a good AMAVIS and build a plan for when I get back from vacation.  I'll also look at our PIX config and see if SMTP fixup is on.  I don't think that it is.
[10:40] <ScottK> SMTP fixup hits often enough that I think you'd know it if it was.
[10:40] <jerome_> ScottK : indeed sorry, bug #78367
[10:40] <ubotu> Launchpad bug 78367 in mosml "extend mosml package to include optional libraries (patch included)" [Wishlist,New]  https://launchpad.net/bugs/78367
[10:40] <ScottK> jerome_: Gutsy.  We're developing for Gutsy now.
[10:40] <EthanP> ScottK:  Cheers!
[10:40] <ScottK> Cheers.
[10:41] <jerome_> ScottK : ok
[10:43] <sistpoty> hi folks
[10:43] <ScottK> Hell sistpoty.
[10:43] <ScottK> Err Hello.
[10:43] <ScottK> Sorry.
[10:43] <sistpoty> hi ScottK
[10:44] <ScottK> Sticky O key.  I swear.
[10:44] <sistpoty> hehe
[10:45] <sommer> ScottK: I just read through the meeting notes EthanP posted and just so I'm clear on what was decided we're going to try a backport?
[10:46] <ScottK> sommer: That's the theory.
[10:46] <sommer> cool sounds like a hoot...where do we start?
[10:47] <ScottK> First thing is a list of WTF we need to test to find out what would be broken by a backport.
[10:49] <sacater> with debdiff do you compare new to old or vv
[10:49] <sacater> i can never remember
[10:49] <ScottK> old.dsc new.dsc > patchname
[10:49] <sommer> okay...just add the package/lib/whatever to the wiki as we find em?
[10:50] <ScottK> sommer: apt-cache rdepends packagename is a good way to get started.
[10:51] <sommer> heh...thanks I was just googling on how to find which packages depend on a certian package.
[10:52] <ScottK> jdong: You around?
[10:53] <ScottK> jdong: While we're on virus scanning, I'm gonna whine about the clamtk backport for Feisty.  The current Feisty clamtk is VERY dangerously broken because it'll run and think it's scanning, but never actually manage to find a virus.  The backport solves it....
[11:01] <RainCT> what was the command to search in what package a file is?
[11:02] <persia> RainCT: `dpkg -S file` or `apt-file search file`
[11:02] <RainCT> thanks :)
[11:27] <RainCT> good night
[11:44] <nixternal> hi kids! do you like violence? wanna see me stick nine inch nails through my eyelids?
[11:44] <nixternal> I just heard someone drive my house blasting that song..I haven't heard that in forever
[11:49] <sacater> hey, im on a mates server for irssi, but his timezone is 8 hours behind me. Is there anyway to make the clock on my profile 8 hours forward by terminal commands
[11:52] <sistpoty> gotta go to bed now... cya 
[11:53] <ScottK> sacater: Add 8 to the number in your head every time you read it.
[11:53] <AndyP> modulus 24 :)
[11:53] <ajmitch> heh
[11:53] <sacater> ScottK: :(
[11:57] <AndyP> sacater: change the TZ environment variable (on etch tzselect gives you a list)
[12:01] <jussi01> good morning persia!
[12:01] <persia> Good evening jussi01