| === nhandler_ is now known as nhandler | ||
| === nhandler_ is now known as nhandler | ||
| === paul__ is now known as Elbrus | ||
| === pangloss is now known as panf | ||
| === panf is now known as pang | ||
| === pang is now known as pangloss | ||
| === Knightlust is now known as Igorot | ||
| alex_21 | Hi, all, I want ot include a package here | 05:54 |
|---|---|---|
| alex_21 | How can I do this? | 05:54 |
| alex_21 | I am stuck zipping up a .deb file. Can someone here help? | 06:10 |
| === fta_out is now known as fta | ||
| === RainCT changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | ||
| pmjdebruijn | I have a new package, (which I think is in pretty good shape, althought I'm not the best judge)... Can anybody take a look at it ( http://revu.ubuntuwire.com/details.py?package=lensfun ) and possibly endorse it? | 13:08 |
| geser | pmjdebruijn: commented | 13:26 |
| pmjdebruijn | geser: thanks | 13:50 |
| pmjdebruijn | geser: I'll go and fix that later this afternoon | 13:51 |
| slytherin | geser: Just FYI ... I just processed jruby1.1 merge. You were last uploader. | 14:06 |
| directhex | is ir worth filing a bug against apps whose UI is too large to work on a netbook? | 14:18 |
| sebner | directhex: you may noticed that I acked your syncs. Yes it's part of mono transition but that are normal sync requests so please follow the sync workflow and not only writing part of mono transition so sync it!!! | 14:20 |
| directhex | i was sleepy! | 14:22 |
| RainCT | heh | 14:23 |
| sebner | directhex: no excuses. You also filed a sync request for gnome-rdp. ubuntu has a own package did you check that or just filed a sync request? ;) | 14:24 |
| sebner | RainCT: hula hu | 14:24 |
| RainCT | o.O | 14:24 |
| slytherin | directhex: it depends on the application. is it too important for netbook remix? | 14:26 |
| directhex | slytherin, it's, um, freeciv. been tinkering with wife's netbook, put the remix on there, and trying to find netbook-friendly games | 14:26 |
| slytherin | directhex: see if wesnoth fits | 14:27 |
| directhex | sebner, the debian packager is also upstream. and by the look of it, the ubuntu package has been "maintained" more than "actively maintained" for 2 years | 14:28 |
| directhex | slytherin, in the general case, is it worth wishlisting? | 14:29 |
| sebner | directhex: I know but you can't just file a sync request saying : Sync it. You have to explain *why* (mono transition is not a reason). I acked it because our packages don't diff that much otherwise we would have to sync it .. Of course we want the new version as well :) | 14:29 |
| sebner | *would have to merge it | 14:29 |
| sebner | I mean | 14:30 |
| directhex | fine. "new upstream from june"! | 14:30 |
| directhex | also, from the ubuntu changelog: "after Hardy this should be simply synced." ;) | 14:31 |
| slytherin | directhex: yes it is. | 14:31 |
| directhex | i wonder whether my freecol "doesn't work on amd64 due to java suckiness" bug ever got closed | 14:32 |
| slytherin | directhex: which bug is that? | 14:34 |
| directhex | slytherin, bug 264049 | 14:35 |
| ubottu | Launchpad bug 264049 in freecol "MOAR RAM please" [Undecided,Confirmed] https://launchpad.net/bugs/264049 | 14:35 |
| slytherin | directhex: I will forward the bug to debian tonight. | 14:39 |
| directhex | know what'd be neat? if a package could be marked as automatically forwarding bugs to debian, in cases where they're maintained by the same people or always synced | 14:40 |
| * directhex ponders asking in #lp | 14:40 | |
| nhandler | Since DIF has still not occurred yet, what should we do about sync-request bugs for packages that will be auto-synced? | 14:51 |
| RainCT | nhandler: wait for the package to be auto-synced and then close the bug | 14:55 |
| nhandler | RainCT: Is there a reason to wait before closing the bug? The bug is serving no purpose right now. If it were to be closed right now (with a comment), it would show the reporter that they do not need to make these types of reports in the future | 14:59 |
| === `Chris is now known as Chrislja | ||
| ScottK | directhex: Please don't. There can also be bugs that are caused by Ubuntu having different versions of depends than Debian, so even if the package is the same, not all bugs in the package automatically belong to Debian. | 16:22 |
| * ScottK now notices that was about 2 hours ago. | 16:22 | |
| hyperair | if i want to relocate some filse in debian/tmp, say debian/tmp/usr/share/codelite/plugins to /usr/lib/codelite/plugins, and then keep the rest of the files installed where they are, what should the .install file look like? | 17:06 |
| azeem | hyperair: the second argument in .install can be used to specify a directory to install it, at least at recent dh compat level I think; check the dh_install manpage | 17:10 |
| hyperair | azeem: i've got lines "debian/tmp/usr/share/codelite/plugins/* /usr/lib/codelite/plugins", but it still seems to be going back into /usr/share | 17:11 |
| === WelshDragon is now known as Guest73482 | ||
| iulian | directhex: giver_0.1.8-3_i386.changes ACCEPTED | 17:19 |
| hyperair | oh hell. i figured out what was wrong. i forgot to bzr add the files, and they didn't appear in the diff.gz | 17:26 |
| jdong | hyperair: lol I just did that for a homework assignment :) | 17:28 |
| jdong | I use bzr to manage my homework directory on 6 different systems, and forgot to do a checkin | 17:28 |
| hyperair | lol | 17:28 |
| jdong | then I used another system to submit the assignment without double-checking the PDF. | 17:28 |
| jdong | WHOOPS. | 17:28 |
| jdong | "YOUR NAME HERE" | 17:28 |
| hyperair | shit! | 17:28 |
| jdong | I knew my answers were bad, but not 0/50 bad! | 17:28 |
| hyperair | good grief | 17:29 |
| hyperair | what happened after that? | 17:29 |
| jdong | the TA found my explanation mildly amusing and offered me the chance to submit it again and he'll "see what he can do" | 17:29 |
| jdong | It'd be awfully nice if he can give me any credit on it | 17:29 |
| hyperair | heheh | 17:30 |
| hyperair | well keep your fingers crossed =p | 17:30 |
| jdong | :) | 17:31 |
| rjune__ | jdong: that's hilarious | 17:32 |
| jdong | lol it's less hilarious that I lost credit on 1 of 6 homeworks :D | 17:32 |
| laga | jdong: a friend of mine has already sent in the .class files for his java assignments twice, instead of the source files | 17:33 |
| jdong | haha | 17:33 |
| jdong | "It's proprietary" | 17:33 |
| laga | heh | 17:33 |
| jdong | the assignment system screams at you if what you upload isn't a valid PDF | 17:33 |
| jdong | apparently people were sending in the latex .log files :) | 17:33 |
| mrooney | Okay, here I go to ideally create my first package with CDBS! | 17:52 |
| === Lutin_ is now known as Lutin | ||
| RainCT | go, mrooney, go :) | 17:55 |
| mrooney | Do I use dh-make before using CDBS? I guess I am confused about the pre CDBS steps if any, also maybe the post :) | 17:57 |
| RainCT | mrooney: is it a new package? | 17:58 |
| mrooney | yes, I am attempting to package one of my python apps that uses distutils, with CDBS | 17:58 |
| pochu | mrooney: you can use dh-make, yes | 17:59 |
| RainCT | mrooney: Yes, if you want you can run dh_make and choose "b" when it asks you which type of package it is. Another option is to just create the needed files yourself :) | 17:59 |
| pochu | mrooney: check --help, it has an option for cdbs packages | 17:59 |
| RainCT | mrooney: and see this: http://wiki.debian.org/DebianPython/NewPolicy | 18:00 |
| mrooney | pochu: okay thanks! | 18:00 |
| mrooney | There doesn't seem to be a complete guide for new packagers, for python apps. I am wrong and if not, shall I document it somewhere? | 18:06 |
| fabrice_sp__ | Hi. Somebody to review DVDStyler? It's at http://revu.ubuntuwire.com/details.py?package=dvdstyler. Thanks! | 18:17 |
| pochu | mrooney: check out https://wiki.ubuntu.com/PackagingGuide/Python | 18:22 |
| === fabrice_sp__ is now known as fabrice_sp | ||
| hefe_bia | Hi! Anybody in for a review of gebabbel a frontend for gpsbabel? (gpsbabel is a tool for converting geo information file formats) It's in REVU and was prev. advocated by mok0. I think I have fixed the outstanding issues. (See http://revu.ubuntuwire.com/details.py?package=gebabbel) | 18:50 |
| jdong | superm1: sigh media packages are fun, aren't they.... :) | 19:24 |
| rjune__ | no | 19:26 |
| Luke | i'm trying to make a deb of a C program which doesn't specify an install target. What is the correct way to handle this? | 19:27 |
| mrooney | in my `control` file, what is the right way to list GPL v3 or later, just "GPL v3 (or later)" | 19:29 |
| azeem | mrooney: that's for copyright, not control | 19:30 |
| fabrice_sp | Luke: with dh_install in the debian/rules file | 19:30 |
| mrooney | azeem: sorry, that's what I meant :) Is that a fine way to write it? | 19:30 |
| azeem | mrooney: at the end of the GPLv3 license, there is recommended text for this | 19:31 |
| azeem | I think dh_make also installs it | 19:31 |
| superm1 | jdong, yeah i'm hoping in the end that upstream developer gives and and starts floating patches around so as to allow dynamic linking, but what an ideal world that would be | 19:31 |
| mrooney | azeem: well I didn't tell dh_make my license, maybe I should have | 19:31 |
| Luke | fabrice_sp: thanks | 19:32 |
| jdong | superm1: looking at their development activity I don't think that's going to happen.... | 19:33 |
| jdong | superm1: I don't think we should be bullying that to happen though. | 19:33 |
| * mrooney waves at jdong | 19:34 | |
| * jdong waves back | 19:34 | |
| mrooney | jdong: were you the one that did all the vlc upgrading? | 19:34 |
| jdong | mrooney: well I was involved but definitely didn't do the bulk of the work | 19:34 |
| jdong | the thanks for that goes to the debian packagers :) | 19:34 |
| Luke | I'm getting this error when running debuild: "dpkg-source: error: cannot represent change..." what does that mean? | 19:35 |
| mrooney | jdong: oh okay, I imagine that must have been intense, thanks for your and everyone elses help in that :) | 19:35 |
| fabrice_sp | Luke: because you have binary files there. You should clean everything in the clean target | 19:35 |
| Luke | fabrice_sp: the weird thing is, it is starting clean =/ | 19:36 |
| fabrice_sp | Luke: hmmm. to generate the diff file, debuild scan the files that have changed, and call the clean target before. Perhaps, some binary file are generated there | 19:37 |
| Luke | fabrice_sp: they would be under debian/package right? | 19:38 |
| fabrice_sp | Luke: could be everywhere. Look for files that has been modified recently | 19:39 |
| Luke | oh i see... it is resulting in all these tars in the parent dir | 19:39 |
| fabrice_sp | Luke: you ahve tar files in the parent dir? | 19:40 |
| Luke | yup | 19:40 |
| fabrice_sp | you can check in the original tarball if they are there | 19:40 |
| Luke | no in the parent of the src etc as well | 19:40 |
| Luke | in the same directory as the .orig | 19:40 |
| Luke | ick still had the problems even after deleting all the resulting tars | 19:42 |
| fabrice_sp | Luke: if you have the .orig directory, you can compare the files between the 2 directories | 19:42 |
| Luke | nothing has changed | 19:42 |
| fabrice_sp | Please post the output of the command in a pastebin, and paste the link here | 19:44 |
| Luke | sure | 19:44 |
| Luke | http://dpaste.com/99055/ | 19:45 |
| Luke | thanks for your help btw. this is my first deb =) | 19:45 |
| Luke | trying to learn so we can use ubuntu instead of centos at work | 19:46 |
| fabrice_sp | :-) | 19:46 |
| fabrice_sp | you have .o files | 19:46 |
| fabrice_sp | in src directory | 19:46 |
| Luke | hmm | 19:46 |
| fabrice_sp | you should delete them in the clean target | 19:46 |
| Luke | you sure found them quick! how did you see this? | 19:46 |
| fabrice_sp | :-) | 19:47 |
| fabrice_sp | in the log :-) | 19:47 |
| fabrice_sp | dpkg-source: error: cannot represent change to circular-application-menu-0.0.52/src/cmmcircularmainmenu.o: binary file contents changed | 19:47 |
| Luke | the log also said it ran: rm -f *.o circular-main-menu | 19:47 |
| fabrice_sp | yes, but not in src subdirectory | 19:47 |
| Luke | its not running the original makefile's clean target? | 19:48 |
| Luke | no it is... that's where the rm -f is coming from | 19:48 |
| fabrice_sp | yes | 19:49 |
| fabrice_sp | but it's seem it still left them behind | 19:49 |
| Luke | i just need to make it run a directory up? | 19:49 |
| DRebellion | sebner, i've removed the chrpath calls in the latest upload: https://launchpad.net/~simrunbasuita/+archive | 19:50 |
| DRebellion | ah | 19:50 |
| DRebellion | oops | 19:50 |
| Luke | i think it's failing because its running with pwd as debian instead of src | 19:50 |
| Luke | ../src i mean | 19:50 |
| DRebellion | sebner, http://revu.ubuntuwire.com/details.py?package=cifer . I haven't uploaded this one to my ppa. | 19:50 |
| fabrice_sp | Luke: could be also that the Makefile is not complete in the cleaning. It's quite common. | 19:53 |
| Luke | i just checked it. it's fine | 19:53 |
| Luke | i'm pretty sure its just running in the wrong place | 19:54 |
| Luke | though i'm not supposed to change the authors makefile correct? | 19:54 |
| fabrice_sp | Luke: you could change it, but by patch | 19:54 |
| fabrice_sp | not directly | 19:54 |
| Luke | k | 19:55 |
| Luke | after cleaning directly and then running debuild again, it worked fine | 19:55 |
| fabrice_sp | ok | 19:56 |
| mrooney | hmm did I do something really stupid? "debian/rules: line 3: include: command not found" | 19:57 |
| Luke | awesome it worked | 19:57 |
| mrooney | where I am using the exact rules from https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging%20Python%20modules%20with%20CDBS | 19:58 |
| pochu | mrooney: can you pastebin your debian/rules | 20:00 |
| pochu | ? | 20:01 |
| mrooney | pochu: ^^ | 20:01 |
| sebner | DreamThief: k, sry again. I'll make a final review in the next few hours =) | 20:02 |
| sebner | argh | 20:02 |
| sebner | DreamThief: sry, not for you | 20:02 |
| mrooney | I can pastebin the thing I copied from the wiki I just linked, if you want for some reason :) | 20:02 |
| pochu | mrooney: try this: http://pastebin.com/m312e8472 | 20:03 |
| pochu | mrooney: but download the file, don't copy&paste it | 20:03 |
| pochu | you may be getting some weird characters... | 20:03 |
| mrooney | pochu: oh that seems to have gotten much further, although it looks like I need to install python2.4 | 20:05 |
| mrooney | is that a dep of cdbs or pycentral or something? | 20:07 |
| mrooney | I want to make sure my app isn't depending on it somehow because it only supports 2.5 and 2.6 | 20:07 |
| mrooney | I think | 20:07 |
| pochu | mrooney: what supported versions did you specify in debian/control? | 20:08 |
| mrooney | pochu: hm, nothing, maybe that is my problem | 20:08 |
| mrooney | that is the one section I was confused on | 20:08 |
| mrooney | I am not sure how to specify the deps | 20:09 |
| pochu | XS-Python-Version | 20:09 |
| Luke | Am i supposed to change the conrol line "Depends: ${shlibs:Depends}, ${misc:Depends}" to have the build and package deps or does it resolve that for me with those variables? | 20:09 |
| mrooney | pochu: would you recommend ">= 2.5, << 3.0" or "2.5, 2.6" | 20:10 |
| mrooney | probably the latter since I don't know about 2.7 or what else they might introduce | 20:10 |
| pochu | mrooney: ">= 2.5" should be fine I believe | 20:13 |
| pochu | mrooney: there's not going to be a 2.7 release AFAIK, btw | 20:13 |
| mrooney | Oh, I thought there was | 20:13 |
| mrooney | pochu: but won't >= 2.5 imply it works with 3.0? | 20:13 |
| pochu | I may be wrong :) | 20:14 |
| pochu | mrooney: yes, but all the archive has that. | 20:15 |
| pochu | mrooney: but ">= 2.5, << 3.0" is fine too, so feel free to use that | 20:15 |
| pochu | if you know it doesn't work with 3.0 | 20:15 |
| mrooney | The python UDS session made it sound like Jaunty might not have 2.5 | 20:15 |
| mrooney | Although it will have 2.6 so I guess that's fine | 20:15 |
| pochu | it will have it | 20:16 |
| pochu | they talked about dropping support, which would mean it's moved to universe | 20:16 |
| pochu | or that's what I understand | 20:16 |
| mrooney | oh, right, yeah | 20:16 |
| pochu | but 2.4 is still in the archive and a few packages need it, so... | 20:16 |
| mrooney | yeah definitely | 20:16 |
| mrooney | pochu: now I should also put "XB-Python-Version: ${python:Versions}" after XS-Python-Version? | 20:17 |
| pochu | no, put that in the binary package stanza | 20:18 |
| pochu | where you have "Depends: " et al | 20:18 |
| Luke | fabrice_sp: Am i supposed to change the conrol line "Depends: ${shlibs:Depends}, ${misc:Depends}" to have the build and package deps or does it resolve that for me with those variables? | 20:18 |
| mrooney | pochu: oh the XS- goes in the source stanza? thanks for all your help by the way :) | 20:19 |
| pochu | mrooney: yes. no problem :) | 20:20 |
| pochu | mrooney: X is for extra fields (those which are not official), S is to be included in the dsc, B to be in included in the binaries (in the control file), and C to be included in the changes file | 20:20 |
| mrooney | I am documenting this as I go so hopefully I can throw up a complete guide for packaging a basic python app somewhere | 20:21 |
| pochu | so you can have XS-foo, XC-bar, XSBC-lalala... | 20:21 |
| mrooney | ahh that makes sense :) | 20:21 |
| pochu | mrooney: cool :) | 20:21 |
| pochu | mrooney: btw, is that an application or a module? | 20:21 |
| mrooney | pochu: application | 20:24 |
| pochu | ok | 20:24 |
| mrooney | right now it ships in site-packages, I still have to figure out where the heck it goes, pyshared then symlink to site-packages, or what | 20:24 |
| mrooney | I can't seem to get a consistent answer on that | 20:25 |
| pochu | it's not meant to be provided as a public module, is it? | 20:25 |
| pochu | if so, you should ship it in /usr/share/$package | 20:25 |
| mrooney | well, it can be, I don't care, it wouldn't have much use though | 20:25 |
| pochu | then ship it in /usr/share/ | 20:25 |
| mrooney | oh, I seemed to get the impression the pythonic way was to ship to site-packages then the binary just imports and runs | 20:26 |
| pochu | you can use "DEB_PYTHON_INSTALL_ARGS_ALL = --install-lib=usr/share/package" in your debian/rules *after* including python-distutils.mk | 20:26 |
| pochu | mrooney: well, not really. It's not a public module, so you don't want to pollute the namespace | 20:27 |
| mrooney | interesting, hmmm | 20:28 |
| mrooney | everyone in #python was very sure site-packages was the right place to go for apps | 20:28 |
| mrooney | although they have a more cross-platform bend then packagers | 20:29 |
| mrooney | pochu: ideally I want to my setup.py to work on any OS as the app supports almost anything, so I guess it would be nice in that way | 20:30 |
| pochu | people running "python setup.py install" will still be able to install it, but on site-packages | 20:31 |
| === asac_ is now known as asac | ||
| pochu | maybe you could configure it in setup.cfg to install files on /usr/share/foo, but then you only want that on platforms following the FHS :-) | 20:32 |
| pochu | not sure if that's possible with setup.cfg though | 20:32 |
| pochu | I'm not even sure you want to do that for the upstream build system | 20:35 |
| pochu | "DEB_PYTHON_INSTALL_ARGS_ALL = --install-lib=usr/share/package" will just pass "--install-lib=usr/share/package" to the setup.py install call | 20:35 |
| pochu | it's like passing --prefix=/usr to autotools' packages | 20:36 |
| nellery | does Ubuntu replace locales-all with locales? | 20:37 |
| Luke | Am i supposed to change the conrol line "Depends: ${shlibs:Depends}, ${misc:Depends}" to have the build and package deps or does it resolve that for me with those variables? | 20:41 |
| mrooney | pochu: okay well that's good to know, that seems ideal | 20:43 |
| pochu | Luke: what kind of package? | 20:46 |
| pochu | Luke: is it a C application? | 20:46 |
| Luke | yup | 20:47 |
| Luke | pochu: the resulting deb's control seems to not mention any deps | 20:49 |
| pochu | it should | 20:50 |
| Luke | pochu: those lines automatically resolve deps then? how does it know? | 20:52 |
| pochu | I think for shlibs:Depends, it looks at your binaries' NEEDED headers, then looks at the installed shlibs files | 20:53 |
| pochu | do you ship binaries in /usr/bin/ or /usr/lib ? | 20:54 |
| Luke | i dont know the correct way to move the binary to where it needs to be | 20:54 |
| Luke | /usr/bin/ would be correct | 20:54 |
| pochu | what build system does upstream use? | 20:55 |
| Luke | make | 20:55 |
| Luke | there's no config or install target | 20:55 |
| Luke | it produces one binary | 20:55 |
| pochu | and are you moving it to ./debian/tmp or ./debian/$package ? | 20:56 |
| pochu | hmm, wait | 20:57 |
| Luke | no where. i'm trying to figure out how to use dh_install to do that. unsuccessfully though | 20:57 |
| pochu | maybe you could use dh_install | 20:57 |
| pochu | heh | 20:57 |
| Luke | yeah i have no idea though. the man page isn't helpful at all | 20:57 |
| Luke | it mentions this install file... though I cant find any more on it | 20:57 |
| pochu | ok | 20:57 |
| pochu | you should put something like this: | 20:58 |
| pochu | "path/to/binary usr/bin" | 20:58 |
| pochu | in debian/$package.install | 20:58 |
| Luke | $package.install? | 20:58 |
| pochu | path/to/binary is relative to debian/.. | 20:58 |
| Luke | are there docs for this somewhere? | 20:58 |
| pochu | change "$package" with your binary package's name :) | 20:58 |
| Luke | ah | 20:58 |
| pochu | dh_install should explain it | 20:59 |
| pochu | dh_install(1), I mena | 20:59 |
| pochu | mean* | 20:59 |
| pochu | bah :) | 20:59 |
| Luke | gotcha... i wasn't getting the whole $package thing | 21:00 |
| Luke | it looks like you can just say usr/bin and it will do it? | 21:00 |
| pochu | if you have just one binary package, you can call it debian/install | 21:00 |
| Luke | ?? | 21:01 |
| pochu | that would work if your package is compiling the binary in debian/tmp/usr/bin/ | 21:01 |
| Luke | that's this tmp you keep talking about? | 21:02 |
| pochu | yes | 21:02 |
| Luke | what's* | 21:02 |
| pochu | well | 21:02 |
| Luke | this documentation is really terrible. I can't believe so many people have figured this out. | 21:02 |
| pochu | some build systems will build binaries, then install the files in debian/tmp (or debian/$package) | 21:02 |
| Luke | the make system doesn't have an install target | 21:03 |
| pochu | then just ignore it :) | 21:03 |
| Luke | so i'm not sure what it does with the resulting binaries | 21:03 |
| pochu | you can look at building it directly | 21:03 |
| pochu | say | 21:03 |
| pochu | $ make | 21:03 |
| pochu | and look where is the binary | 21:03 |
| Luke | yeah it's in src/binary | 21:03 |
| pochu | then put "src/binary usr/bin" in debian/install | 21:04 |
| pochu | and call dh_install in debian/rules | 21:04 |
| Luke | src/binary is relative to the untarred folder? | 21:04 |
| pochu | yes | 21:04 |
| Luke | awesome i'll try this | 21:05 |
| Luke | ah cool shlibdeps outputted a ton of crap now | 21:06 |
| Luke | worked! thanks pochu! | 21:08 |
| pochu | Luke: cool :) you're welcome | 21:08 |
| Luke | now i'm going to work on making it pull from svn. there's no release for this yet | 21:08 |
| pochu | create a get-orig-source target in debian/rules for that | 21:09 |
| pochu | that's the preferred way of doing it | 21:09 |
| Luke | pochu: https://wiki.ubuntu.com/PackagingGuide/Complete#Solutions | 21:09 |
| Luke | i've done that for svn... but where does my debian folder go then? | 21:09 |
| Luke | just package-emptydir/debian then? | 21:09 |
| pochu | Luke: you should create a tarball without the debian/ folder | 21:11 |
| Luke | I did that | 21:11 |
| pochu | then I don't get the question :) | 21:11 |
| Luke | but where does the rules file go then? | 21:11 |
| pochu | sorry, I don't understand what you mean | 21:12 |
| Luke | where do I put the rules file? | 21:12 |
| pochu | inside the new tarball? | 21:12 |
| Luke | i dont have a tar... this is from source | 21:13 |
| pochu | hmm | 21:13 |
| pochu | you have a package-1.0/ dir right now | 21:13 |
| pochu | with a debian/ dir inside it | 21:13 |
| Luke | yeah exactly! what goes in the package-1.0 dir besides the debian dir? | 21:13 |
| Luke | nothing rigth? it will just be empty? | 21:13 |
| pochu | and a control, rules, install files etc inside package-1.0/debian/ | 21:14 |
| Luke | yeah | 21:14 |
| Luke | but in the package-1.0 there will only be debian/* right? | 21:14 |
| pochu | in the tarball there should only be the upstream sources | 21:14 |
| Luke | then I populate debian/../ | 21:14 |
| pochu | and the debian/ dir will be in the diff.gz | 21:14 |
| Luke | there is no tarball yet | 21:14 |
| Luke | i'm making this from svn now | 21:14 |
| pochu | you create one with debian/rules::get-orig-source :) | 21:15 |
| pochu | Luke: so for example: | 21:15 |
| Luke | then where does debain/rules go? | 21:15 |
| pochu | nowhere | 21:15 |
| pochu | you do: | 21:15 |
| Luke | then how will I run it? | 21:15 |
| pochu | ./debian/rules get-orig-source | 21:15 |
| Luke | wait one sec | 21:15 |
| pochu | and then a package_1.0.orig.tar.gz is created in .. | 21:15 |
| Luke | what is ./ in this case? | 21:15 |
| pochu | debian/*, src/*, etc | 21:16 |
| Luke | no that's what's in ./ | 21:16 |
| Luke | i'm asking what ./ *is* | 21:16 |
| Luke | let me try and explain | 21:16 |
| pochu | Luke: please :) | 21:17 |
| pochu | btw, I created this get-orig-source for one of my packages, it gets the sources from svn: http://svn.debian.org/viewsvn/python-apps/packages/emesene/tags/1.0~r1137-1/debian/rules?rev=759&view=auto | 21:17 |
| Luke | the guide defines the debian dir to be in a subdir of the original tar output. so debian depends on the output of a tar. but if i have no tar, I don't know where to put the debian file. so far, you've told me it goes no where and also that it goes in package-1.0/ | 21:17 |
| pochu | oh | 21:17 |
| Luke | i know how to write the rules target for svn | 21:18 |
| pochu | Luke: I think I understand it now :) | 21:18 |
| Luke | i just dont know how it will be called by the script | 21:18 |
| pochu | yes, an empty package-1.0/ dir is fine | 21:18 |
| Luke | ah ok | 21:18 |
| pochu | so you do: | 21:18 |
| pochu | $ mkdir package-1.0 | 21:18 |
| pochu | $ cp -a debian/ package-1.0/ | 21:18 |
| pochu | $ cd package-1.0/ && make debian/rules get-orig-source | 21:19 |
| pochu | $ cd - | 21:19 |
| Luke | wait a sec... | 21:19 |
| Luke | how will PPA know to run make debian/rules get-orig-source? | 21:19 |
| pochu | $ ls package*tar.gz | 21:19 |
| pochu | and you will have it | 21:19 |
| pochu | it won't | 21:19 |
| pochu | well, you could tell it to do it in the build target or something... | 21:19 |
| pochu | but that's not a good idea | 21:19 |
| pochu | you should run it yourself, build a tarball, and use that one | 21:20 |
| Luke | ah ok | 21:20 |
| Luke | gotcha | 21:20 |
| Luke | so i basically fake a release to build from then | 21:20 |
| pochu | yup | 21:20 |
| Luke | is there a way to pull the svn rev into the tarballs name? | 21:20 |
| mrooney | do I not use jaunty as the ubuntu version in the changelog for new packages? Should I use intrepid for some reason? | 21:23 |
| JontheEchidna | New packages should use the latest development version in the changelog | 21:24 |
| Luke | what do I put after the ~ if it's from svn and it's for ppa? | 21:24 |
| Luke | ~svn~ppa1? | 21:24 |
| JontheEchidna | ~svnblah~ppa | 21:25 |
| Luke | thanks | 21:26 |
| JontheEchidna | You're welcome | 21:27 |
| Luke | so no ppa version then? | 21:27 |
| Luke | or can it be like 0.1-1~svn52~ppa1 ? | 21:27 |
| JontheEchidna | oh, of course you can have a ppa version :) | 21:28 |
| mrooney | JontheEchidna: well I'm getting "bad-ubuntu-distribution-in-changes-file jaunty", do the intrepid packages not know about jaunty? | 21:29 |
| JontheEchidna | just ignore it, the intrepid packages don't know about jaunty | 21:30 |
| mrooney | JontheEchidna: oh I see, lintian errors aren't fatal, just noticed, thanks | 21:31 |
| JontheEchidna | yeah, that got me the first time too | 21:31 |
| JontheEchidna | I thought it failed | 21:32 |
| * directhex tinkers with requestsync | 21:41 | |
| === mcasadevall is now known as NCommander | ||
| Luke | pochu: should the get-orig-source target also untar the contents downloaded from svn to the pwd ? | 21:42 |
| pochu | Luke: no, just create the .orig.tar.gz | 21:43 |
| Luke | then I unzip that over my empty app dir? | 21:43 |
| * directhex goes requestsync crazy | 21:46 | |
| pochu | Luke: then unpack it, and copy your debian/ dir inside the unpacked tarball | 21:47 |
| Luke | k | 21:48 |
| mrooney | I think it was successful! | 21:52 |
| directhex | RainCT, feel like doing the mono 2.0 transition on gbrainy? | 22:07 |
| === Guest73482 is now known as WelshDragon | ||
| RainCT | directhex: I don't know why but those last weeks I'm extremely lazy :P. | 22:11 |
| RainCT | directhex: What's the necessary change in debian/rules for CDBS? | 22:11 |
| directhex | RainCT, depends on configure.ac | 22:12 |
| RainCT | ah, found the wiki page | 22:13 |
| directhex | RainCT, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669 has a cdbs example | 22:13 |
| RainCT | directhex: "grep mcs configure.in" gives the same output as on the wiki. What does this mean? | 22:16 |
| mrooney | okay so, I am upstream and I'm packaging something for ubuntu, I am basically done, but realized I want to change my .desktop file | 22:16 |
| mrooney | do I do a new release and copy over /debian ?/ | 22:17 |
| directhex | RainCT, it said "AC_PATH_PROG(CSC, mcs, no)"? | 22:17 |
| mrooney | I assume I shouldn't just change it in the tar and source | 22:17 |
| RainCT | mrooney: yep | 22:17 |
| RainCT | directhex: AC_PATH_PROG(MCS, gmcs) | 22:17 |
| directhex | RainCT, DEB_CONFIGURE_EXTRA_FLAGS += MCS=/usr/bin/csc | 22:17 |
| mrooney | RainCT: is it easy to get an update in? I need a translation sync, I could do it now, but I think I might as well get this approved then do one, for the experience of an update | 22:18 |
| mrooney | is that reasonable? | 22:18 |
| pochu | mrooney: sure | 22:19 |
| pochu | once the package is in the archive, updates to it are easy to get in | 22:19 |
| pochu | unless you introduce new features and we are in feature freeze | 22:20 |
| RainCT | directhex: OK. The wiki says "+= CSC=" | 22:20 |
| RainCT | directhex: and the grep also says "CSC=gmcs", so is it CSC or MCS? | 22:21 |
| directhex | RainCT, whichever is found by grep | 22:21 |
| RainCT | AC_PATH_PROG(MCS, gmcs) | 22:22 |
| RainCT | CSC=gmcs | 22:22 |
| RainCT | directhex: it says that | 22:22 |
| directhex | oh, hrm, urgh. | 22:22 |
| RainCT | heh | 22:22 |
| directhex | which one does the makefile actually use? | 22:22 |
| directhex | MCS or CSC | 22:22 |
| RainCT | directhex: grep gives those matches in Makefile.in: MCS = @MCS@ CSC = @CSC@ CSC_DEFINES = @CSC_DEFINES@ | 22:23 |
| directhex | &*^% | 22:25 |
| directhex | sodding upstreams | 22:25 |
| RainCT | hehehe | 22:25 |
| * RainCT can poke upstream if there's any problem | 22:25 | |
| directhex | yeah, there's a problem, the compiler is hard-coded! | 22:25 |
| directhex | imagine if configure read CC - then manually set CXX=g++-3.4 | 22:26 |
| RainCT | uhm.. there's not a single reference to 2gmcs" in Makefile.in, though | 22:26 |
| directhex | yeah, but configure is forcing "CSC=gmcs" | 22:27 |
| directhex | which is Bad(tm) | 22:27 |
| RainCT | Ah, right. Let's see if he is online | 22:28 |
| RainCT | nope, I'll drop him a mail then | 22:28 |
| RainCT | directhex: how urgent is the transition? | 22:28 |
| directhex | RainCT, well, all apps need to be done before the libs can be done, and libs need to be done before jaunty shrinks in install size | 22:29 |
| RainCT | directhex: so, how urgent is it? ;P | 22:31 |
| RainCT | (to know if it's worth patching or better see if he will release a new version anytime soon) | 22:31 |
| directhex | RainCT, i'd like to say apps will be done within a fortnight. | 22:32 |
| RainCT | alright | 22:32 |
| RainCT | directhex: to be sure that I got it right, configure.in should check if CSC is already defined before overwriting it? | 22:33 |
| directhex | RainCT, or do exactly the same as it does with MCS, i.e. use AC_PATH_PROG | 22:37 |
| directhex | RainCT, or, even better, stop existing - why define the same compiler in 2 vars? | 22:37 |
| RainCT | directhex: ok, thanks | 22:40 |
| * RainCT has emailed upstream telling him about this and asking if he is going to release soon or if I should just patch the file for now | 22:41 | |
| === tonyyaru1so is now known as tonyyarusso | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!