[12:17] 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? === zoli2k [n=kuscsik@nat-88-212-20-143.antik.sk] has left #ubuntu-motu [] [12:19] man, good question [12:20] 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] then again, that legal mumbo jumbo is to much for me at times..yup, here comes the headache now [12:22] 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] well, when you start patching and stuff I think you might make the claim that it's a combined work [12:22] but I don't think, in general, it's considered a problem [12:22] Hey folks. [12:23] 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] 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] well ya, the licensing has to be compattible [12:24] persia: are you thinking about Google Desktop :) [12:24] nixternal: Not specifically, although that may also be a good example. [12:24] persia: usually that isn't a problem [12:25] LaserJock: Is there an official opinion somewhere, or do we just not care? [12:25] hmm, not sure [12:25] but packaging is in general considered public domain [12:25] unless specifically noted otherwise [12:26] 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] why would there be a problem? [12:26] 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] no, I think it's an ok practice [12:27] because it's clear [12:27] LaserJock: If the licensor of something wanted to complain about incompatible licenses. [12:27] heh, if they complain we can change it [12:28] but I would think there would be a whole lot of problem in debian === _MMA_ wonders if this is about any of his ubuntustudio packages. ;) === etank [n=etank@ubuntu/member/etank] has joined #ubuntu-motu [12:28] _MMA_: As an example only [12:28] hey etank [12:28] <_MMA_> Ahh... [12:28] http://code.google.com/p/google-desktop-for-linux-mirror/downloads/list [12:28] heh, rfc_uuid was originally developed by microsoft...interesting [12:28] LaserJock: Yeah. That was my thought (and I also think we try to follow Debian licensing policies). [12:28] howdy pygi [12:28] and everyone else too :) [12:29] 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] for a package to show up on my Lp page under maintainence report i have to be listed as maintainer? [12:29] yup [12:30] just set Maintainer: to MOTU and join up! :) [12:30] could someone have a look at http://revu.tauware.de/details.py?upid=5811 ? [12:30] persia: I would venture to say most packages in Debian do not license the packaging [12:30] but I think for completness and correctness it's good to do so [12:30] 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] so i guess i should start keeping track [12:31] and obviously if you're going to do it, it should be compatible with the package [12:31] I don't think blindly encouraging licensing the packaging is a good idea [12:32] unless the package is single-lincensed, and the packaging uses the same license [12:32] exactly [12:32] but I do very little REVU work, do my opinion doesn't really matter [12:32] in fact, I would recommend against using GPL for licensing packaging in general [12:32] actually, make that "very little MOTU work" :-( [12:32] I would explicitly do as close to public domain as possible [12:33] so there wouldn't be any problems in the future [12:33] gnomefreak: you are totally right, that is a big issue [12:33] 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] gnomefreak: I don't have any packages I specifically maintain in Ubuntu [12:33] same goes in Debian, except for one package. I set KDE Extras to maintainer and me as an uploader [12:34] i do but i either have motu or mozillateam as maintainers [12:34] persia: "Ideally you include a license statement for your Debian packaging also" note the ideally part ;-) [12:34] what about adding my name next to the maintainer? [12:34] all of my packages listed on my LP page weren't uploaded by me. Is that what you are referring to? [12:35] LaserJock: Right. Hence "encourages" :) [12:35] nixternal: i have uploaded a few and fixed a bunch but nothing on my Lp at all [12:35] 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] orly [12:35] who has been uploading your fixes and what not? [12:35] a few people :) but they will be there when i go for motu [12:36] 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] that is odd, I never uploaded anything, others have, yet I got credit for it [12:36] nixternal: same here === nixternal looks at your page so I know what is going on a little more clearly [12:36] only thing I pay attention to is boogs in LP :) [12:36] ;) [12:37] interesting, your page doesn't list a thing [12:37] i just said that [12:37] lol [12:37] hahaha [12:37] I know, but I wasn't clear because you said people uploaded for you === gnomefreak last uploader for iceape and nspluginwrapper [12:37] they did upload for me as i cant [12:37] ahh ya that's right, you are doing that stuff [12:38] didn't I see your name in the gutsy-changes list though for those uploads? [12:38] i dont know i didnt see it [12:38] I am looking now === Monk-e [n=guido-xu@c529dd229.cable.wanadoo.nl] has joined #ubuntu-motu [12:39] gnomefreak: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/date.html [12:40] gnomefreak: gwget2 sound familiar? [12:40] yes i remember that as well [12:40] that is the only thing I see in the gutsy-changes with your name on it [12:40] and that should at least be on your page [12:40] that is weird === leonel [n=leonel@189.155.123.110] has joined #ubuntu-motu [12:40] nixternal, it's not [12:41] new uploads are either -motu or core-dev [12:41] https://lists.ubuntu.com/archives/gutsy-changes/2007-June/003026.html [12:42] 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] nixternal, true, they should be on his page tho [12:42] ya, that is what I thought [12:42] nixternal, it is however possible we're not tracking that anymore [12:43] since *new* maintainers for stuff are motu or core devs [12:43] no one else [12:43] so perhaps all goes to them [12:43] ya, but if gnomefreak creates/recreates a package and signs it, he should get recognition for it no matter who uploads it [12:43] I think we're tracking the "Changed-By" tag in source.changes, so it depends on how the uploader processed the upload. [12:43] so what is suggested on how to track this [12:44] gnomefreak: well there is always -changes which documents everything, well almost everything, the recent LP updates broke the *-changes updates [12:45] gnomefreak: I might ask an LP admin what is up unless someone here knows for a fact the issue at hand [12:45] ok so as long as you are under changed by: than it should show up in LP? [12:46] 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] persia: ^^^ [12:48] 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] 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] minghua: I'm just one commenter. It doesn't block other's uploading :) [12:51] heh, I find licensing the hardestmost tiresome part of packaging... [12:51] damn, my stupid / key... [12:51] never works [12:52] I find it the easiest :) [12:53] 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] hmmm...maybe Ive just had dodgy lincensed packages... right persia? [12:53] IIRC, LP credits "uploaded packages" if you are the uploader ("changed-by") and your keyring is in LP === doko_ [n=doko@dslb-088-073-091-187.pools.arcor-ip.net] has joined #ubuntu-motu === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu [12:54] damn, ive got bad typo's tonightt [12:54] jussi01: Yep. As long as upstream is clean about licensing, it's usually pretty easy (although people sometimes make mistakes anyway). [12:54] I agree copyright/licensing varies a lot from package to package [12:55] i'm just building some simple packages that i plan to distribute [12:55] am i ok using "dpkg-deb -b"? [12:55] hmm, let me think a little [12:55] it took mplayer like three years to get that part right [12:55] I think LP should take it from changelog [12:56] LaserJock: I think it's the .changes === peanutb_ [n=paulb@phns1.gotdns.com] has joined #ubuntu-motu [12:56] LaserJock: i agree, atleast thats the easiest way to track accutual changes [12:56] the uploader is determined from .changes [12:56] but that's different [12:56] I think [12:57] oh heck, now I'm getting myself confused [12:57] I filed a bug about one of these [12:57] 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] well yes [12:58] that's what I'm meaning, sorry [12:58] like I said, I'm confusing myself [12:58] I'm afraid you are starting to confuse me as well... [12:59] ok, i give in... someone tll me how to make it work? please? http://paste.ubuntu-nl.org/27685/ [12:59] ok, LP should keep track of both the person in the changelog and the person who signed/uploaded [12:59] the first is done by Changed-By: , right? [12:59] LaserJock: Changed-By is the last changelog entry. [01:00] right [01:00] jussi01: there either isn't a makefile in the root directory, or ./configure was never run ;p [01:00] and the second is determined from the gpg signature [01:00] I think you know that though, that is what I am being a smart ass on that one === jussi01 calls for hobbsee and her stick... [01:00] :P [01:00] haha [01:01] jussi01: is this the package where the makefile and what not is in src/ ? [01:01] gnomefreak: do you have an example package & version that should show up on your LP page? [01:01] nixternal: yes... [01:02] jussi01: you need the right summoning [01:02] geser: yes.... [01:02] 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] am i correct in thinking there's a Q&A session in an hour? [01:03] ish [01:03] minghua: LP just started keeping that info not long ago [01:04] I have this in my rules file right now, [01:04] cd $(CURDIR)/src/ [01:04] make [01:04] what should it be? [01:04] jussi01: that is exactly what I was going to ask [01:04] I have a similar thing with an icon package, and that is what i did [01:04] err, maybe not...let me look [01:04] nixternal: I can read your mind :P [01:04] LaserJock: oh? would you show me a pointer please? [01:05] s/show/give/, I suppose [01:05] jussi01: You probably also want that before ./configure [01:05] hrmm, maybe it wasn't the icon package...wth package was it now [01:05] persia: config works [01:06] now that is odd, the config works but the makefile doesn't [01:06] config looks like: $(CURDIR)/src/./config but i tried that with make and it didnt work.... === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu [01:07] minghua: as to what? [01:07] LaserJock: LP keeping track of the sponsor info [01:08] well, I don't have much of a pointer [01:08] I don't think they actually do anything with it yet [01:09] other than I think they use it in soyuz to send the Accepted/Rejected emails [01:09] oh, I see [01:09] so sponsor and uploader both receive the accepted/rejected mails now? [01:09] I have a tip: don't play leaf frog with a unicorn! [01:10] argh, LEAP === peanutb_ is now known as peanutb [01:10] jeesh, blew my own damn joke [01:10] nixternal: thanks.... :P [01:10] minghua: well, no, right now just the sponsor [01:11] I filed a bug to also get the sponsoree an email too === doko__ [n=doko@dslb-088-073-096-158.pools.arcor-ip.net] has joined #ubuntu-motu [01:11] 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] and the sponsor was kinda MIA so nobody knew what happened to the packages [01:12] LaserJock: yes i have a few === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu === minghua is not sure whether the sponsor or the sponsoree is more deserving the mail (if we can only have one) :-P [01:13] minghua: well, that's why I said both need it [01:13] ;-) [01:13] LaserJock: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/003733.html [01:13] thats one [01:14] gnomefreak: ahh, I found the problem [01:14] or at least the problem with that one [01:15] gnomefreak: check out https://launchpad.net/~gnomefreak-ubuntu/+packages ;-) [01:15] lol ok shall i give you another or 2? [01:15] that just took a a day to get there [01:16] gimme more of them [01:16] LaserJock: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/002583.html another one a bit further of a date [01:16] what happened with that one was that you don't have your @ubuntu.com address in your LP account [01:16] LaserJock: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/003026.html [01:16] so it created a new account [01:16] ah [01:16] damn [01:17] so you need to merge those 2 accounts [01:18] LaserJock: ok let me see if i can pull it up [01:19] oh my gosh [01:19] So we are already past Debian Import Freeze, and all future syncs needs requests? That seems a bit early to me. [01:19] gnomefreak: I found the other ones [01:19] omg [01:19] LaserJock: is there a fast easy way to do this? [01:19] Considering the state in unstable right now. [01:20] gnomefreak: https://launchpad.net/~ubuntu-desktop-effects/+packages [01:20] ah [01:21] my only thought there is that the contact email for ~ubuntu-desktop-effects is yours [01:21] LaserJock: there was my ubuntu.com one but i changed it [01:21] minghua: yes, during the feisty cycle it was also so early [01:22] during feisty it's better because Debian is pretty much frozen [01:22] gnomefreak: https://launchpad.net/people/+requestmerge [01:22] I expect a bumpy road ahead [01:22] gnomefreak: ah that would do it [01:22] hope the archive admin (or whoever in charge) can keep up with sync requests [01:22] minghua: yes, I asked about that but I don't think I got much of a response [01:22] LaserJock: ty the duplicate accounts would be the wrong ones? [01:23] gnomefreak: yes, well only gnomefreak-ubuntu === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu === minghua still remember the old days (dapper?) when sync requests stay weeks to get processed [01:23] not good memories [01:23] 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] minghua: there are significantly more archive admins now, but I know what you mean [01:24] LaserJock: ok ty i might have to do that thank you for finding them [01:24] I'm having LP devs looking at what it takes to have MOTUs do archive admining [01:24] 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] minghua: during at least parts of dapper there was only elmo. Now there are 9 archive admins [01:25] Anyway, I should concentrate on getting my Debian packages in shape, then worry about sync requests. [01:25] LaserJock: Full archive admining, or just SYNC approvals? [01:25] persia: for MOTU? [01:26] LaserJock: Yes. [01:26] the full thing of course [01:26] it can then be limited to what we need [01:26] but I want LP to have the needed changes [01:26] so when we decide we need to do something and TB agrees it'll be there [01:27] LaserJock: Ah. That'd be nice (I'm especially interested in binary removals). [01:27] oh yes, binary removals would be excellent === ajmitch doesn't know if we'd get the whole range of super powahs [01:27] like NEW [01:27] well, there's a difference between the social constraints and technical constraints [01:28] I want to make sure there aren't any technical reasons why we can't === persia isn't sure about NEW - licensing is hard, murky, and dangerous [01:28] whether the TB/Ubuntu Archive lets us is entirely different, and in my opinion we really shouldn't do much [01:28] I really wouldn't want MOTU doing NEW [01:29] I think syncs, sru pushing, and binary removals would be the real use cases [01:29] LaserJock: Are you drafting a spec? [01:29] well, not exactly [01:30] I filed a bug and was going to write a spec when we were having issues with SRUs === jussi01 is going to bed...night all [01:30] we almost got -proposed admining rights, but LP wasn't ready [01:30] LaserJock: That's another use case I'd like to see: removals from -proposed. [01:31] 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] persia: yes [01:31] but I just told kiko and cprov yesterday that I don't want them to forget about it [01:31] but it's not high priority right now [01:32] I think cprov was working on a spec === persia thinks a w.u.c spec would be preferable to a w.l.c.c spec, for better MOTU input. [01:32] in fact I believe my "motu-sru should admin -proposed" bug was slated for 1.1.8 [01:32] persia: yes, that is an issue [01:32] I tried to get access to w.l.c.c ;-) [01:33] 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] I said "don't expect me to work on a spec if I don't even have read-access to the wiki" === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu [01:33] I'/quit [01:33] but they (well one person) didn't go for it === hoora_ [i=ariel@gateway/tor/x-3917fcd00b4be3d4] has joined #ubuntu-motu [01:34] What exactly is binary removal for? === neversfelde|mobi [n=neversfe@nrbg-4d071327.pool.mediaWays.net] has joined #ubuntu-motu [01:34] minghua: For when a package is no longer built for an architecture, but we still ship the old (buggy, uninstallable) version. [01:35] or === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu [01:35] like say in Debian, we get towards the end of the release and we have really crappy packages [01:35] minghua: Currently processing is a bit slow. My binary removal requested for Breezy was processed for Gutsy. [01:35] we can pull the binaries before release so people don't try to install uninstallable junk ;-) [01:36] I see. I though such things are automatically done in Debian [01:36] they are [01:36] minghua: Yes (in Debian) [01:36] we don't have anything in Ubuntu [01:36] persia: "a bit slow" indeed [01:36] you just file a bug and sub ubuntu-archive [01:36] But I do realize that Debian and Ubuntu have rather different archive management. [01:36] that's because we don't have 3 archives [01:36] my removals have only take a week or two [01:36] not in the same way debian does [01:37] we're missing Testing :-) [01:37] LaserJock: I suspect it was because someone tried to submit a patch to fix mine :) [01:37] we copy all the binary packages in feisty when we open gutsy, right? [01:37] persia: ah yeah, mine were all "dead upstream, buggy package, and Debian got rid of it" [01:37] minghua: Right (a spec to rebuild for new releases would be nice too) [01:38] LaserJock: That's a package removal (not binary removal). I usually get those processed in a month or so. [01:38] oh, right [01:38] By "copy", I mean "keep the same binary package, generate a new Packages.gz for gutsy based on those", of course [01:38] hmm, i don't know that I've ever had a binary removal done [01:38] usually they just pull the source package and leave the binary [01:38] minghua: yep [01:39] I think we'd have a whole lot of FTBFS if we rebuilt each release === jgamio [n=jgamio@190.72.53.158] has joined #ubuntu-motu [01:39] it's annoying when you get a new package from Debian and it FTBFS [01:40] 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. === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu [01:40] and you go back and we've had the same binary since Hoary or Breezy [01:40] Well, according to the gutsy schedule on wiki.u.c, we should just finished the _second_ archive rebuild test. [01:40] minghua: funny [01:40] minghua: That's mostly main. [01:40] Main [01:40] yeah [01:40] I believe they have quite a component-wide testing setup [01:41] iwj I believe worked a lot on that stuff [01:41] https://wiki.ubuntu.com/GutsyReleaseSchedule # it should be the first rebuild, sorry [01:41] Universe is just the cruft of the packaging world ;-) [01:41] 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] persia: yeah, I've wanted to ask but haven't had the time to follow up on it [01:42] lucas did that for feisty once, I remember [01:42] LaserJock: No rush. You've a full plate already :) [01:42] although rather close to release date [01:42] of course it's probably all like MoM so we won't be able to see what's going on ;-) [01:43] yes, he ran it through on that grid thing he's got access too [01:43] 40,000 nodes or something [01:43] heh [01:43] BTW, lucas is doing that for debian on weekly/biweekly basis now [01:43] didn't it take him something like 4-7hrs to rebuild Universe [01:44] it didn't take long, at least [01:44] I can't imagine what it would take on my machine [01:44] http://people.debian.org/~lucas/logs/2007/ # for those interested and didn't know [01:44] weeks [01:44] LaserJock: The limit on how fast it can be built is the time taken for openoffice.org to build :) === radhios [n=radhios@200-122-44-49.dsl.prima.net.ar] has joined #ubuntu-motu [01:45] anybody want to guess which package is the second in building time after OO.o? :-) [01:45] kernel-source [01:46] linux-source even === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu [01:46] broonie: right, makes sense [01:47] how long does it take to build OO.o? [01:47] geser: 12h on the buildds IIRC [01:47] could be more :-) [01:47] minghua: that's not all of Debian thuogh === Nafallo starts launchpad ;-) [01:47] LaserJock: the people.d.o url? [01:48] yeah, that list looks too short for all of Debian main [01:48] I wonder how long it would take to build OO.o on my "shiny" new Ultra 10 ;-) [01:48] ask calc :) [01:49] heh [01:49] I'm sure he'll put in a special laserjock build flag [01:49] LaserJock: those are the ones that FTBFS [01:50] oooh. it's only 9h now :-D [01:50] LaserJock: for a full one, see e.g. http://people.debian.org/~lucas/logs/2007/06/19/sym/ [01:51] the kernel takes only like 4 hours, latex-cjk-chinese-arphic takes 7 hours [01:51] ha! 12h on i386 :-) [01:51] OO.o that is [01:51] the package that take the second longest time to build is latex-cjk-chinese-arphic, an arch:all package [01:51] yeah, geser beats me [01:51] I can't find the mail about top 10 now :-( === rexbron [n=rexbron@CPE001310b2d1d1-CM0012256e816a.cpe.net.cable.rogers.com] has joined #ubuntu-motu [01:53] minghua: latex-cjk-chinese-arphic had once a FTBFS because it didn't generate some output and the buildd timed out [01:54] geser: yeah, wouldn't happen for Debian. :-P === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-motu [01:55] 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] 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] 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] but you could always ask ;-) [01:57] LaserJock: ok ty ill try whats worse they can say? no? [02:00] pretty much === alex-weej [n=alex@82.23.188.238] has joined #ubuntu-motu [02:02] i have some python code that i want to package up [02:02] gnomefreak: Open a support request from answers.launchpad.net asking for the LP accounts to be merged. [02:02] i tried to cheat and use dpkg-deb -b but it included all of the file ownership properties [02:02] so now i have stuff installed on my system owned by "alex" [02:02] how do i do this properly [02:02] given that i don't actually have a build process (it's all python) [02:03] i just so desperately want to build a package out of this and it's all going against me [02:04] dpkg-buildpackage -rfakeroot should work [02:05] if you install fakeroot [02:05] "don't cheat"? :-) [02:05] is dpkg-deb "cheating"? [02:06] Yeah, pretty much. [02:06] alex-weej: You might want to have a setup.py for your "build process". [02:06] Even data-only packages like mplayer-themes use dpkg-buildpackage :) [02:06] "fakeroot debian/rules clean && fakeroot debian/rules binary" is probably the bare minimum for building a package [02:06] persia, geser: we should have the Debian ftp-master "Grounds for rejection" material "ubuntuized" on the wiki === vbabiy [n=vbabiy@pool-71-164-85-238.albyny.fios.verizon.net] has joined #ubuntu-motu [02:07] persia: to do what exactly? [02:07] LaserJock: Yes, but also reviewed by the archive admins to adjust for differences (build-dep must be satisifed for main, etc.). [02:07] persia: literally nothing needs to be built [02:07] persia: unless you want my setup.py to read "pass" :P [02:07] alex-weej: but installed [02:07] doesn't setup.py install things as well? [02:07] i don't know [02:07] i've never seen one [02:07] setup.py installs things [02:07] i wasn't aware there was a convention [02:07] persia: yeah [02:07] can i not just use a make file? [02:07] alex-weej: do you have a source package or not? [02:07] alex-weej: you don't need to install things though [02:08] 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] minghua: no. [02:08] minghua: I think the answer is now [02:08] alex-weej: you can just have debian/rules copy the files to the right places [02:08] s/now/no/ [02:08] alex-weej: and then use python-central etc [02:08] LaserJock: yeah, should've guessed earlier [02:08] lifeless: i don't see what i can put in the rules script [02:08] alex-weej: the best thing for you to do is to apt-get source $a-python-project [02:08] alex-weej: What lifeless said :). [02:09] alex-weej: the stuff to install the files === persia recommends a newer python project with a recent upload date [02:09] alex-weej: and build a binary package [02:09] wait - so i need to "fake" an install? [02:09] alex-weej: You can check out the specto package, that's pure-python only. [02:10] alex-weej: yes - you install with a DESTDIR of $(curdir)/debian/ usually [02:10] can i do this without touching autotools? [02:10] dh_builddeb will make a .deb out that tree [02:10] alex-weej: sure, you can run any command in the debian/rules === superm1 [n=superm1@ubuntu/member/superm1] has joined #ubuntu-motu [02:10] alex-weej: Yes. You can use the python distutils. [02:10] RAOF: tell me more! [02:10]