| === stiV_ is now known as stiVal | ||
| dominic1134 | having a problem to build a ppa. build process fails with "bzr: ERROR: bzrlib.errors.BzrCommandError: No control file to take the package name from, and --package not specified." , build log http://pastebin.com/hX7DDRgh | 00:14 |
|---|---|---|
| stiVal | Hello! Is it possible to build multiple packages using ONE recipe in ONE ppa. I am trying to build three packages (not arch dependend) but I just can't find the information on how to tell launchpad (or the bzr-builder) to use three different subdirectories to start building. The project im working on is: https://code.launchpad.net/~open-as-team/open-as-cgw/trunk | 00:14 |
| stiVal | well ... two people working in the same thing with the same ideas :-p | 00:15 |
| dominic1134 | hehe :-D | 00:15 |
| wgrant | stiVal: A single recipe builds a single Debian source package. That source package can produce multiple binary packages in the normal way. | 00:29 |
| stiVal | If you would have a look at the code, there are multiple directories, three of those have the code and information to build packages (dpkg-buildpackage works inside those directories). they are "meta" "lib" and "gui". Is there any way to tell a recipe to build one of those (and therefor create three recipes to create all three packages)? | 00:31 |
| stiVal | the easiest is "meta", which is a package that only holds dependencies | 00:32 |
| wgrant | Recipes assume that one branch roughly equates to one source package. | 00:33 |
| wgrant | If your branches don't follow that convention, you're going to have a tough time making recipes fit your workflow. | 00:33 |
| stiVal | so I should create multiple branches - one for each package? | 00:34 |
| stiVal | of get rid of the three packages and just create one package altogether | 00:36 |
| stiVal | hmmmm | 00:36 |
| nicekiwi | hey, im trying to have a recipe built, but its failing.. any ideas? https://answers.launchpad.net/bzr/+question/151218 | 00:38 |
| stiVal | wgrant: thank you for your input, I will research what to do next! | 00:43 |
| nicekiwi | https://launchpadlibrarian.net/190055388/buildlog.txt.gz | 00:44 |
| wgrant | nicekiwi: That's a very old question without any recent comments. | 00:44 |
| wgrant | What exactly is your problem? | 00:44 |
| wgrant | bzr: ERROR: bzrlib.errors.BzrCommandError: No control file to take the package name from, and --package not specified. | 00:44 |
| nicekiwi | wgrant, well there my build log :/ the package fails to build | 00:44 |
| wgrant | http://bazaar.launchpad.net/~nicekiwi/+junk/hello-packaging/files <- there's no debian/control there. | 00:45 |
| wgrant | Your recipe needs to result in an unpacked Debian source package. | 00:45 |
| nicekiwi | Ah.. >_> | 00:46 |
| wgrant | https://help.launchpad.net/Packaging/SourceBuilds/Recipes | 00:46 |
| nicekiwi | wgrant, hmm ok.. Ive pushed the debian folder and now a new message im not sure I understand | 00:52 |
| nicekiwi | bzr: ERROR: bzrlib.errors.BzrCommandError: No previous changelog to take the upstream version from as {debupstream} was used: No previous changelog to take the upstream version from: debian/changelog didn't contain any parseable stanzas. | 00:52 |
| wgrant | nicekiwi: debian/changelog's format is invalid. Have you tried building the package locally with dpkg-buildpcakge? | 00:53 |
| nicekiwi | wgrant, no. sorry im quite new at this.. following a guide at http://elementaryos.org/docs/code/packaging | 00:53 |
| wgrant | Huh | 00:55 |
| wgrant | The changelog format there is very wrong, and you shouldn't normally be manually doing that anyway. | 00:55 |
| wgrant | One normally uses the 'dch' tool. | 00:55 |
| wgrant | And you should always test build locally first. | 00:55 |
| wgrant | http://packaging.ubuntu.com/html/ is probably of interest. | 00:55 |
| nicekiwi | thats worrying :/ | 01:00 |
| === broder__ is now known as broder_ | ||
| nicekiwi | wgrant, how do I build debs? | 02:03 |
| nicekiwi | locally :/ hmm.. this isent the best place to ask is it.. | 02:05 |
| nicekiwi | groupon#shameongroupongnome trademark | 02:12 |
| nicekiwi | oops | 02:13 |
| wgrant | nicekiwi: The packaging guide goes through that. But you'd use dpkg-buildpackage or debuild. | 02:33 |
| === Trevinho__ is now known as Trevinho_ | ||
| === alexlist` is now known as alexlist | ||
| nickoe | I was just looking at https://github.com/percona/launchpad-bugs-python , it is posisble for the python launchpadlib to fetch historical bug data? The script I linked only shows the current stats. | 17:00 |
| dobey | nickoe: what do you mean exactly? https://launchpad.net/+apidoc/1.0.html shows everything you can get via the API | 17:58 |
| cjwatson | nickoe: you might be looking for the activity collection on a bug | 17:59 |
| dobey | that, or expanding search to include old bugs perhaps. | 18:00 |
| cjwatson | nickoe: though if you're looking for historical stats about bugs on a given target, I don't think there's a good way to do that; you could get some of it by searching for all statuses and reconstructing things from activity collections, but there's no reasonable way to get hold of bugs that were once on that target and have since been reassigned somewhere entirely different, for instance | 18:01 |
| cjwatson | Launchpad itself doesn't keep that kind of information in a convenient form | 18:01 |
| nickoe | dobey: I was thinking to plot for example graphs over the number of bugs and their status over time. | 18:17 |
| nickoe | cjwatson: dobey: Ok, yes I have seen that doc, and I did indeed see that I can get the bug_task one, where I can get the date of the status. So if I could seach a bug for each status then I guess I can query them. | 18:19 |
| dobey | nickoe: so you want something like the burndown charts we have in ubuntu? | 18:21 |
| dobey | you probably don't need to iterate over the activity in the bug to do a burndown chart, or to graph how long bugs remained open | 18:23 |
| dobey | you just need the bug_task and can get the dates and status from that, i think | 18:23 |
| nickoe | dobey: mmm, burndown, I don't know that term. But I guess that is waht I would like. | 18:24 |
| dobey | nickoe: something like http://status.ubuntu.com/coreapps-13.10/ | 18:26 |
| dobey | nickoe: where you measure open vs. closed bugs over a period of time up to a milestone | 18:26 |
| nickoe | dobey: yeap, exactly something like that. So is the script that can fetch that data somewhere out there to fetch? | 18:27 |
| dobey | afaik, yes | 18:27 |
| dobey | but i don't know where it is exactly :) | 18:27 |
| dobey | cjwatson might know where the status.ubuntu.com stuff lives, though | 18:28 |
| nickoe | Thank you so far :) | 18:28 |
| cjwatson | I don't know where the code for status.ubuntu.com lives. | 19:37 |
| cjwatson | As far as I know, everything that draws graphs of things in Launchpad over time stores its own data over time, rather than expecting Launchpad to store it. | 19:37 |
| cjwatson | Of course that means you can only start from now, rather than months ago. | 19:38 |
| nickoe | cjwatson: Ok, thank you. | 20:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!