| ESphynx | Sundays *are* quiet in here =) | 02:20 |
|---|---|---|
| LordOfTime | quietish everywhere :P | 02:21 |
| === LordOfTime is now known as TheLordOfTime | ||
| === iulian is now known as Guest97017 | ||
| ESphynx | Well I think I solved our GCC 4.7 issues =) | 04:39 |
| dholbach | good morning | 07:08 |
| === jussio1 is now known as jussi | ||
| === almaisan-away is now known as al-maisan | ||
| === Guest97017 is now known as iulian | ||
| iulian | Morning dholbach. | 07:49 |
| dholbach | hi iulian | 09:58 |
| === yofel_ is now known as yofel | ||
| === al-maisan is now known as almaisan-away | ||
| raju | coolbhavi, yeah now its cool | 14:09 |
| coolbhavi | :) | 14:09 |
| raju | coolbhavi, how are you feeling ?? | 14:11 |
| coolbhavi | raju, pm please | 14:11 |
| raju | coolbhavi, | 14:11 |
| raju | cool | 14:11 |
| ral | Hi | 14:38 |
| ral | I'm trying to maintain a library symbols file. | 14:39 |
| ral | But dpkg-gensymbols keeps adding the version from debian/changelog rather than allowing the upstream version, which I thought was the intent. | 14:39 |
| xnox | ral: C++ or C? | 14:40 |
| ral | C | 14:40 |
| xnox | ral: dpkg-gensymbols generates with "current" debian/changelog version because it doesn't know upstream symbol vs symbol introduced in a debian patch | 14:40 |
| ral | So "foo@VERS_1.0 1.0" changes to "foo@VERS_1.0 1.0-0~ppa1" | 14:40 |
| Laney | that's quite normal, you need to manually apply the diff that gensymbols gives you and edit the symbols file to remove the debian part of the version | 14:40 |
| ral | Laney: Ah, I've missed out a step. | 14:41 |
| ral | I did that, but the actual problem is that I get lintian errors when the package is built. | 14:42 |
| ral | Saying that the symbols have changed, you have 1.0, but should have 1.0-0~ppa1. | 14:42 |
| xnox | you might not have added the symbols file correctly to the packaging | 14:42 |
| xnox | or there are extra symbols on different architecture | 14:43 |
| xnox | e.g. amd64 and x86 can have different symbols | 14:43 |
| dupondje | anyone with experience with reprepro? | 14:44 |
| ral | xnox: Possible, but I doubt it. I'm updating packaging that used to work rather than starting from scratch (although the SO version has bumped so they are new package names) | 14:44 |
| xnox | and you renamed the pkg.symbols -> pkg-1.1.symbols? | 14:44 |
| ral | And this is all just on my local machine so I've not even got to possible architecture errors yet :) | 14:44 |
| xnox | and other similar files? =))) | 14:45 |
| ral | pkg0.symbols -> pkg1.symbols | 14:45 |
| ral | I think so, but it's worth checking. | 14:45 |
| dobey | hey all. any chance to get a little traction on https://bugs.launchpad.net/ubuntu/+bug/1035392 ? | 14:48 |
| ubottu | Launchpad bug 1035392 in Ubuntu "[needs-packaging] u1db" [Wishlist,In progress] | 14:48 |
| ral | xnox: I can't find any trace of the old names. | 15:01 |
| ESphynx2 | hey guys :) so I solved our issues building Ecere with GCC 4.7 on Quantal =) | 16:43 |
| === almaisan-away is now known as al-maisan | ||
| ral | xnox / Laney: Seems to be a bug with dpkg-gensymbols - if change the changelog version number from 1.0-0~ppa1 to 1.0-0ubuntu1 it works. I suspect the ~ is causing problems. | 17:05 |
| xnox | ral: no bug, expected behaviour. | 17:06 |
| xnox | =) | 17:06 |
| xnox | if the symbol is marked as present in 1.0 | 17:06 |
| micahg | dobey: if there's some urgency for u1db, you could ask a couple of desktopper core-dev/MOTUs to review for you | 17:06 |
| xnox | ral: than 1.0-0~ppa1 is smaller and hence not "big" enough to include the 1.0 symbols. | 17:06 |
| xnox | so it warns you that you "backported" symbols into the past =) | 17:07 |
| xnox | ral: I suspect that 1.0-1~ppa1 might be "big" enough to have 1.0 symbols | 17:07 |
| ral | xnox: Right | 17:08 |
| ral | Counter intuitive, but dpkg agrees with you. | 17:08 |
| ral | I didn't realise that ~ was that powerful. | 17:08 |
| ESphynx2 | jtaylor: around by any chance? ;) | 17:08 |
| xnox | ral: well -0~ | 17:09 |
| xnox | ral: so you are saying that it's smaller than -0 debian release of upstream, hence it's "bigger" than 0.0~bla-0 but still smaller than 0.0 | 17:10 |
| ral | I would still expect 1.0(anything here) to be > 1.0 | 17:13 |
| ral | But that's beside the point. | 17:14 |
| ral | It works with a "proper" version number for debian/ubuntu, and ppas don't care about lintian. | 17:14 |
| ESphynx2 | Anyone willing to review our cross-plaform SDK for wishful inclusion into Quantal? =) | 17:14 |
| ral | Thanks for your help. | 17:14 |
| tumbleweed | ral: dpkg --compare-versions '1.0-0~' lt '1.0' && echo yes | 17:16 |
| tumbleweed | it's not beside the point at all :) | 17:16 |
| xnox | ral: see debian policy with respect of meaning of ~ and + | 17:21 |
| xnox | ral: we are bending the rules of mathematics by using limits and negative/positive zeros | 17:21 |
| ral | tumbleweed: It's beside the point that I expected 1.0(anything) to be > 1.0. I'm not disagreeing that I'm wrong! :) | 17:46 |
| xnox | ral: yet you do want to package alpha, beta, rc, snapshots, before 1.0 is actually tagged and released! =) | 17:57 |
| ESphynx2 | So guys, how would I go about finding a reviewer? | 18:53 |
| === al-maisan is now known as almaisan-away | ||
| xnox | ESphynx2: subscribe sponsors to the merge proposal or but report | 18:54 |
| ESphynx2 | sponsors being? a group id thing, or actual people? | 18:54 |
| xnox | ESphynx2: ~ubuntu-sponsors | 18:55 |
| ESphynx2 | Ohh! awesome Mantis support on Launchpad! | 18:57 |
| ESphynx2 | xnox: Thanks... that's done :) | 19:00 |
| ESphynx2 | xnox: is there any faint hope of finding a sponsor before the feature freeze? ;) | 19:08 |
| xnox | ESphynx2: depends what for. What's the package / bug? | 19:11 |
| ESphynx2 | xnox: Ecere is a cross platform SDK... Light yet powerful/flexible, cross platform GUI toolkit, compiling tools for the eC language, network/system library, it's a full fledged media library comparable to SDL or SDFL, and an IDE for C/C++/eC ... | 19:13 |
| ESphynx2 | SFML* | 19:14 |
| xnox | ESphynx2: i wanted URL, not package description =) | 19:14 |
| ESphynx2 | xnox: ahh...https://bugs.launchpad.net/ecere/+bug/394998 | 19:14 |
| ubottu | Launchpad bug 394998 in Ubuntu "[needs-packaging] ecere-sdk -- cross-platform developer toolkit" [Wishlist,In progress] | 19:14 |
| ESphynx2 | Reported by Ryan Prior on 2009-07-02 :| | 19:14 |
| ESphynx2 | I was hoping 2012.10 was the time :P with the end of the mayan calendar and all ;) | 19:15 |
| xnox | Did you mean to add a URL to the .dsc and or attach a packaging branch to the bug report? | 19:15 |
| xnox | cause without either of those, there is nothing to sponsor. So sponsors team will be unsubscribed with a comment | 19:15 |
| ESphynx2 | xnox: Hmm... well we've got a PPA... | 19:15 |
| xnox | "this bug report has nothing to sponsor" | 19:16 |
| ESphynx2 | ugg | 19:16 |
| xnox | it's just a packaging request | 19:16 |
| ESphynx2 | xnox: how am I meant to do this? | 19:16 |
| === almaisan-away is now known as al-maisan | ||
| xnox | ESphynx2: create a debian source package suitable for inclusion into debian/ubuntu | 19:17 |
| ESphynx2 | xnox: The PPA is @ https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-precise ... I just need to merge dev into master and rebuild | 19:17 |
| xnox | and upload it into a ppa, or just any plain http:// ftp:// hosting | 19:17 |
| xnox | ESphynx2: ergh.... a daily build is not good enough. | 19:17 |
| ESphynx2 | It is in a PPA... our PPA has been running since 2009... | 19:17 |
| xnox | you need to use correct version string for the distribution and a released tarball. | 19:18 |
| ESphynx2 | xnox: ok... so it should be a specific version? | 19:18 |
| ESphynx2 | Should the version string have a particular format? | 19:19 |
| === al-maisan is now known as almaisan-away | ||
| xnox | ESphynx2: http://developer.ubuntu.com/packaging/html/ | 19:23 |
| ESphynx2 | xnox: The daily builds already have all the .dsc and everything... | 19:23 |
| ESphynx2 | xnox: Can I build it using Launchpad packaging recipes? | 19:25 |
| ESphynx2 | Is it that the changelog should say something specific about Quantal? Or it's just the deb-version thing that must be set properly? | 19:28 |
| dobey | ESphynx2: ideally, you'd attach the .dsc and stuff for a released version, to the bug report. not use recipes or daily builds | 19:28 |
| dobey | ESphynx2: more like https://bugs.launchpad.net/ubuntu/+bug/1035392 for example | 19:29 |
| ubottu | Launchpad bug 1035392 in Ubuntu "[needs-packaging] u1db" [Wishlist,In progress] | 19:29 |
| ESphynx2 | dobey: But Launchpad recipes produce .dsc ... | 19:29 |
| ESphynx2 | Which I could then attach, right? | 19:29 |
| dobey | launchpad recipes produce a changelog which says "automated build" which is not acceptable | 19:30 |
| dobey | you need a proper changelog entry | 19:31 |
| ESphynx2 | isn't that the changelog in debian/ ? | 19:31 |
| ESphynx2 | Could someone with a bit more Ubuntu packaging familiarity be willing to assist me with this? | 19:31 |
| dobey | yes | 19:31 |
| dobey | (yse i mean the debian/changelog file) | 19:32 |
| ESphynx2 | I wrote a changelog entry in debian, under our ppa/precise branch | 19:32 |
| ESphynx2 | I thought that's what get used by the automated build | 19:32 |
| ESphynx2 | https://github.com/ecere/sdk/blob/ppa/precise/debian/changelog | 19:32 |
| dobey | ESphynx2: lp recipes adds a new entry with the proper changes to the version and series info, for uploading to the ppa. and this new changelog entry simply says "* Automated build." | 19:33 |
| ESphynx2 | ok... | 19:33 |
| dobey | or "* Auto build." rather | 19:33 |
| ESphynx2 | so I need to manually run debuild (is it?) | 19:34 |
| dobey | yes | 19:34 |
| ESphynx2 | And what should changelog say, version wise , to be proper? | 19:34 |
| ESphynx2 | "correct version string for the distribution " ? | 19:34 |
| ESphynx2 | and what's this urgency about ? does it have to saw low? | 19:35 |
| dobey | probably just "* Initial packaing of $package for Ubuntu." or something, if it's not already packaged in debian | 19:35 |
| dobey | you should probably just always leave urgency=low there | 19:35 |
| ESphynx2 | ok... and at the top the version string | 19:35 |
| ESphynx2 | that'd be ok what I currently have ? | 19:36 |
| dobey | no. it would need to be 0.44.01-0ubuntu1 for example | 19:36 |
| dobey | unless you're building it as a native package, which isn't really advisable | 19:37 |
| ESphynx2 | $package -- did you mean that as is? or should I replace that? | 19:38 |
| ESphynx2 | what's a native package? | 19:38 |
| ESphynx2 | So... 0.44.01-0ubuntu1 quantal; urgency=low ? | 19:39 |
| ESphynx2 | * Initial packing of Ecere SDK for Ubuntu. (LP: #394998) -- should the bug ID be there? | 19:39 |
| dobey | yes the bug id should be there | 19:40 |
| ESphynx2 | and I should replace $package by say, Ecere SDK ? | 19:41 |
| dobey | a native package is where the releases are only done into the package, and you just have the version number without any build numbers | 19:41 |
| dobey | and given the description of what ecere is, that doesn't seem to be anywhere near appropriate for you | 19:41 |
| dobey | it also makes it a pain for people to contribute to the packaging | 19:41 |
| dobey | yes, $package was a pseudocode-variable | 19:42 |
| ESphynx2 | ok... well i have the packaging on ppa/precise branch in github... | 19:42 |
| ESphynx2 | dobey: https://github.com/ecere/sdk/blob/ppa/precise/debian/changelog -- looking good? | 19:43 |
| xnox | ESphynx2: i posted a quick review of the PPA source package | 19:44 |
| xnox | https://bugs.launchpad.net/ecere/+bug/394998/comments/2 | 19:44 |
| ubottu | Launchpad bug 394998 in Ubuntu "[needs-packaging] ecere-sdk -- cross-platform developer toolkit" [Wishlist,In progress] | 19:44 |
| xnox | there are at least 7 serious bugs with the source package | 19:44 |
| ESphynx2 | xnox: What did you try to build? | 19:45 |
| xnox | ecere_201208122348-0~580~precise1.dsc | 19:46 |
| ESphynx2 | I just pushed the fix for it to build with GCC 4.7 | 19:46 |
| xnox | ESphynx2: it didn't even start clean the package | 19:46 |
| ESphynx2 | xnox: sorry, I was saying have to wait till the build bot builds it | 19:46 |
| ESphynx2 | xnox: that's the one that isn't building | 19:46 |
| xnox | so way before gcc4.7 is ever envoked | 19:46 |
| ESphynx2 | hmm ? | 19:46 |
| xnox | dh build | 19:47 |
| xnox | dh: No packages to build. | 19:47 |
| xnox | dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2 | 19:47 |
| ESphynx2 | xnox: How would the PPA bots build it then? | 19:47 |
| xnox | they didn't | 19:47 |
| xnox | build it on amd64 at all.... | 19:48 |
| ESphynx2 | xnox: It only builds as 32 bit | 19:48 |
| xnox | why? | 19:48 |
| ESphynx2 | you can run it as 32 bit on 64 bit machine | 19:48 |
| ESphynx2 | because we don't have 64 bit support yet | 19:48 |
| xnox | so | 19:48 |
| xnox | you should. | 19:48 |
| ESphynx2 | I should...? | 19:48 |
| xnox | and even if you don't have 64 bit support, packages should not be all marked as i386, some of them should be marked as `all` | 19:49 |
| xnox | ESphynx2: "the package should be patched/ported to support 64 bit" | 19:49 |
| xnox | currently in Ubuntu we widely support 5 architectures: amel, armhf, i386, amd64 and powerpc | 19:50 |
| ESphynx2 | xnox: there is major work involved into supporting 64 bit | 19:50 |
| xnox | in Debian we have 12 architectures | 19:50 |
| ESphynx2 | it is planned. | 19:50 |
| xnox | armel and armhf are 32 bit | 19:50 |
| ESphynx2 | but right now it doesn't... | 19:50 |
| xnox | yet you excluded them | 19:50 |
| ESphynx2 | well I've never tested on those yet :) | 19:51 |
| ESphynx2 | xnox: The library DOES link against system wide libpng, zlib, etc.; the sources of other libraries are included for the convenience for building on Windows. | 19:52 |
| ESphynx2 | well I updated the debian/copyright, 'cuz it was quite off... | 19:58 |
| ESphynx2 | https://github.com/ecere/sdk/commit/534ea0c1bcbec7b1ea7dbff32b575a34d7fc6c92 -- would that be ok xnox ? | 19:59 |
| ESphynx2 | sorry, https://raw.github.com/ecere/sdk/ppa/precise/debian/copyright | 19:59 |
| ESphynx2 | thanks for the review xnox :) | 20:08 |
| xnox | ESphynx2: debian archive auto-rejects source packages if it detects included copy of zlib | 20:15 |
| ESphynx2 | So what are the odds of the package being accepted before we have native 64 bit support? | 20:16 |
| xnox | it still should build for: any !amd64 !powerpc64 | 20:16 |
| xnox | for example to include other 32 bit platforms | 20:16 |
| xnox | the included libaries must be stripped from the tarball | 20:16 |
| ESphynx2 | how could I work around this? I want zlib to be included when downloading the tarball so it builds on Windows easily... | 20:16 |
| ESphynx2 | so the upstream tarball will automatically have it, which step could strip it down? | 20:17 |
| xnox | as a debian maintainer, you should ask upstream to either publish a source only tarball | 20:17 |
| micahg | hrm, I don't think we need a repack unless it's not DFSG | 20:17 |
| xnox | or alternatively the debian maintainer repackages the tarball to make it DFSG | 20:17 |
| ESphynx2 | I'm the author btw... | 20:17 |
| xnox | ESphynx2: i know, I am just being explicit =) you will have to "double up" | 20:18 |
| ESphynx2 | So when I build the .dsc I strip it down :) | 20:18 |
| xnox | micahg: what about zlib auto-reject then? | 20:18 |
| xnox | in Debian. | 20:18 |
| ESphynx2 | xnox: Should I put [amel] [armhf] [i386] ? | 20:18 |
| ESphynx2 | or is there a [!amd64] [!powerpc64] ? | 20:19 |
| ESphynx2 | I'm just worried about breaking all the other builds... | 20:19 |
| xnox | ESphynx2: upstreams usually develop on a small amount of systems. Distributions often have wider access to differnt architectures. | 20:21 |
| ESphynx2 | right. e.g. I have no clue what amel or armhf are :P | 20:22 |
| xnox | so we strike to build for all arches, if they fail to build from source, it's fine, since it will not be published for the users | 20:22 |
| ESphynx2 | armhf is that what the raspberry pi has/ | 20:22 |
| xnox | ESphynx2: armel is ARM v5 CPU, and armhf is newer ARM v7 CPU | 20:22 |
| ESphynx2 | ah ok... both arm platform | 20:22 |
| xnox | ESphynx2: raspberry pi is armel, panda boards and android phones are ARM v7 / armhf | 20:22 |
| ESphynx2 | well it's been built before on ARM and PPC , with a certain level of success. | 20:23 |
| ESphynx2 | I've just been told before to put [i386] in there so that the PPA bots don't attempt to build for AMD64 and fail... | 20:24 |
| micahg | xnox: raspberry pi is armv6... | 20:25 |
| tumbleweed | and capable of HF | 20:25 |
| micahg | xnox: and I'm not familiar with that auto reject (can't seem to find it listed) | 20:25 |
| ESphynx2 | oh, so no need to the github tarball can be used? =) | 20:28 |
| ESphynx2 | I mean no need to tweak it* | 20:28 |
| xnox | micahg: non-fatal -embedded-library | 20:32 |
| xnox | http://ftp-master.debian.org/static/lintian.tags | 20:32 |
| micahg | xnox: right, non-fatal :), if it's not used I thought it's file as long as it's DFSG distributable in source form | 20:33 |
| micahg | s/file/fine/ | 20:33 |
| ESphynx2 | micahg: ah great :) | 20:39 |
| ESphynx2 | So you guys have suggestions about what I should put to address the ARM platform issue xnox brought up? | 20:39 |
| ESphynx2 | I'd happily do I can to make it compliant but I would really appreciate a little hand-holding given the fact that I'm trying to be maintainer while being the upstream author, and otherwise fully busy with work and life :) | 20:41 |
| micahg | ESphynx2: I'd do the ! as xnox suggested if it'll build on all 32 bit platforms | 20:42 |
| ESphynx2 | micahg: so that would be [!amd64] [!powerpc64] ? or [!amd64 | !powerpc64] or ... | 20:43 |
| micahg | ESphynx2: just a straight list should be fine !amd64 !powerpc64 (and whatever archs in Debian if you upload there as well) | 20:44 |
| ESphynx2 | with [ ] around? | 20:44 |
| ESphynx2 | [!amd64] [!powerpc64] ? | 20:44 |
| micahg | no | 20:44 |
| micahg | http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture | 20:44 |
| micahg | "In the main debian/control file in the source package, this field may contain the special value all, the special architecture wildcard any, or a list of specific and wildcard architectures separated by spaces. If all or any appears, that value must be the entire contents of the field. Most packages will use either all or any. " | 20:45 |
| ESphynx2 | ahhh sorry | 20:45 |
| ESphynx2 | I was confusing with the dependencies. | 20:45 |
| ESphynx2 | architecture specific dependencies... | 20:45 |
| ESphynx2 | samples, doc, extras... I used to have 'all' there for Natty, but that would break things on Precise because the other packages didn't support amd64 | 20:47 |
| gld1982ltd1 | hi all MOTU....does anyone have a sec to help me package an app? | 20:48 |
| micahg | ESphynx2: no, you should use multiarch then to solve that problem | 20:48 |
| gld1982ltd1 | or more specifically, check to see if i am on the right track? | 20:49 |
| gld1982ltd1 | i have the branch on launchpad. | 20:49 |
| ESphynx2 | micahg: right with Precise now I'm using multiarch (that's why I only built for i386) | 20:49 |
| micahg | ESphynx2: right, but arch:all should be fine where appropriate | 20:49 |
| ESphynx2 | so if I have !amd64 !powerpc64 with the binaries, all should be fine? | 20:49 |
| micahg | ESphynx2: and use all where it's architecture independent | 20:50 |
| ESphynx2 | great. thanks. updating that... adding the thing for the ${misc:Depends} as well... | 20:50 |
| ral | gld1982ltd1: Best bet is to post the link to the branch. | 20:51 |
| ESphynx2 | native-package-with-dash-version -- This would go away once I build it myself instead of with the autobuild , right? | 20:52 |
| micahg | ESphynx2: what's debian/source/format say? | 20:53 |
| micahg | and do you have an .orig.tar.{gz,bz2,xz} that you're using | 20:53 |
| ESphynx2 | is that supposed to be a file? | 20:53 |
| ESphynx2 | micahg: xnox just used the automated .dsc file built by our PPA on launchpad for preliminary reviewing | 20:54 |
| micahg | debian/source/format is supposed to be a file, yes | 20:54 |
| ESphynx2 | I do not have a debian/source/ folder ... | 20:54 |
| ESphynx2 | well unless that gets created by the debuilder ? | 20:54 |
| gld1982ltd1 | https://code.launchpad.net/~gld1982ltd/lxmed/testing | 20:54 |
| micahg | ESphynx2: http://lintian.debian.org/tags/missing-debian-source-format.html | 20:55 |
| xnox | micahg: it's a daily ppa build which merges branches, creates native tarball, and has a version number $date-0~$revno | 20:55 |
| xnox | =/ | 20:55 |
| micahg | ah, ok | 20:55 |
| micahg | is that because recipes are still broke with 3.0 (quilt)? | 20:56 |
| ESphynx2 | The new source package just built (before my packaging tweaks though... but that's the source that will build on Quantal (32 bit))... | 20:56 |
| gld1982ltd1 | ral: any suggestions or comments? | 20:59 |
| ral | gld1982ltd1: I'm no motu, but the packaging part looks like a good start. Are you intending to package it for debian/ubuntu or a ppa? | 21:02 |
| gld1982ltd1 | for a ppa. | 21:03 |
| gld1982ltd1 | then for ubuntu | 21:03 |
| gld1982ltd1 | This is the only menu editor i have found tpo work for lxde that doesn't also waqnt to install another desktop environment with it. | 21:03 |
| ral | gld1982ltd1: Your debian/copyright file should also list the copyrights for the source files, not just the packaged files. | 21:06 |
| ral | Er, packaging files that is. | 21:06 |
| gld1982ltd1 | ok | 21:06 |
| gld1982ltd1 | man, i need someone who knows what they are doing to join the team on launchpad. how could i go about that? | 21:07 |
| ral | gld1982ltd1: The Vcs-* files in control should point to repo where the debian/ files are stored, if you're going to include them. | 21:08 |
| ral | And Homepage: needs filling in of course :) | 21:08 |
| ral | gld1982ltd1: The version number in changelog is what it would be if packaged in debian. | 21:10 |
| ral | If something is packaged in ubuntu and not in debian it would be something like 1.0-0ubuntu1 | 21:11 |
| gld1982ltd1 | ah......ok. | 21:12 |
| ral | The idea being that if was subsequently packaged in debian then the newly packaged version would supercede the ubuntu version. | 21:12 |
| ral | You can compare package versions with "dpkg --compare-versions". | 21:13 |
| ral | Something I was having problems with myself earlier :) | 21:13 |
| gld1982ltd1 | ral: did you look at the actual trunk this testing branch was taken from? | 21:14 |
| gld1982ltd1 | http://bazaar.launchpad.net/~lxmed/lxmed/lxmed/files | 21:15 |
| ral | I was looking here: http://bazaar.launchpad.net/~gld1982ltd/lxmed/testing/view/head:/trunk/installation/debian/lxmed/debian/ | 21:16 |
| gld1982ltd1 | right....the trunk is different. maybe i changed something i wasn't supposed to? | 21:17 |
| ral | gld1982ltd1: You should also make sure the version number for your ppa would be superceded by any "properly" packaged package. | 21:18 |
| gld1982ltd1 | there is no properly packaged package. there is no package yet at all. | 21:19 |
| ral | gld1982ltd1: Er, dunno. | 21:19 |
| ral | gld1982ltd1: Yes, but if there is a properly packaged package it should take precedence over your ppa package. | 21:19 |
| gld1982ltd1 | oh, ok. | 21:20 |
| gld1982ltd1 | so i need to change the version to 1.0ubuntu0? would that work? | 21:22 |
| ral | gld1982ltd1: 1.0-0ubuntu0 would work, but something like 1.0-0ppa1 might be more appropriate. | 21:25 |
| gld1982ltd1 | ah | 21:25 |
| gld1982ltd1 | i see | 21:25 |
| ral | 1.0-AubuntuB means upstream version 1.0, debian revision A, ubuntu revision B. | 21:26 |
| gld1982ltd1 | aaaaahhhh | 21:28 |
| ral | So the -0 part is important. | 21:28 |
| gld1982ltd1 | ok....i'm going to revert back to the original and start over. looking at the original source, should i follow this page? http://developer.ubuntu.com/packaging/html/packaging-new-software.html | 21:30 |
| gld1982ltd1 | that's what i have been trying to follow. | 21:31 |
| ral | gld1982ltd1: I'm not familiar with that page, but given that it is talking about keeping the packaging files in a repo suggests it's reasonably up to date. | 21:34 |
| ral | https://wiki.ubuntu.com/PackagingGuide/Complete gives more details. | 21:34 |
| ral | There's lots to learn, but it looks like you've started with a reasonably straightforward package. | 21:35 |
| gld1982ltd1 | cool. | 21:35 |
| gld1982ltd1 | ral: thanky ou very much for your help. | 22:02 |
| gld1982ltd1 | i got to go now. | 22:02 |
| ESphynx2 | thanks again for the help guys | 22:25 |
| ESphynx2 | micahg: still around? dpkg-source: error: `!amd64' is not a legal architecture string | 22:35 |
| micahg | hrm, I guess that's only good for dependencies | 22:37 |
| ESphynx2 | yeah that's what it looks like... for [!amd64] | 22:37 |
| ESphynx2 | So what should I do here? | 22:37 |
| * micahg guesses list them out then | 22:38 | |
| micahg | i386 armel armhf powerpc | 22:38 |
| ESphynx2 | fair enough | 22:39 |
| ESphynx2 | done... reimporting the branch and re-schedulring a build then :) | 22:41 |
| ESphynx2 | btw, if anyone is willing to try it out, the previous build did succeed on Quantal: ecere - 201208132049-0~776~quantal1 @ https://code.launchpad.net/~ecere-team/+archive/ppa/+packages | 22:43 |
| ESphynx2 | (though that's before the packaging tweaks, since that build didn't go through :P) | 22:43 |
| ESphynx2 | well gg, bbl | 22:45 |
| ESphynx2 | thanks micahg | 22:45 |
| Laney | someone want to do a round of haskell rebuilds? | 23:06 |
| Laney | seeing a few weird failures on arm{el,hf} that i haven't investigated yet but are keeping some rows red | 23:07 |
| ajmitch | sounds terribly exciting, where do I sign up? | 23:07 |
| Laney | so try not to reupload those if you can, but it's not the end of the world if you do | 23:07 |
| Laney | i already accidently did that once | 23:07 |
| Laney | http://people.canonical.com/~ubuntu-archive/transitions/ghc.html thar | 23:07 |
| ajmitch | this is why I need to get real armhf hardware working properly at home | 23:08 |
| micahg | Laney: any reason why haskell-platform wasn't uploaded? someone just filed a bug | 23:08 |
| Laney | i was waiting to finish everything else | 23:08 |
| Laney | so that i don't have to think about whether other packages are making it red | 23:09 |
| ajmitch | why does the transition tracker show it as red for all archs? | 23:09 |
| Laney | same with dummy | 23:09 |
| micahg | umm, because it's not installable? | 23:09 |
| Laney | haskell-platform : Depends: ghc (< 7.4.1+) but 7.4.2-2 is to be installed | 23:10 |
| Laney | Depends: libghc-haskell-src-dev (>= 1.0.1.5) but it is not going to be installed | 23:10 |
| Laney | Depends: libghc-haskell-src-dev (< 1.0.1.5+) but it is not going to be installed | 23:10 |
| Laney | at least the ghc one will require sourceful uploadery | 23:10 |
| Laney | and haskell-src is in level 35, so will be around soon | 23:11 |
| micahg | hrmm, why does it show that package as level 1 then? | 23:11 |
| Laney | no clue | 23:11 |
| ajmitch | Laney: I take it there are still a few uploads/syncs to do? | 23:12 |
| micahg | Laney: can you have a look at my tracker branch? | 23:13 |
| * micahg would appreciate if someone with a proper setup could run it to see if it does what I think it does | 23:13 | |
| Laney | i'll look tomorrow | 23:13 |
| Laney | sleep now | 23:13 |
| micahg | ok | 23:14 |
| Laney | ajmitch: not so many syncs | 23:14 |
| Laney | that freeze thing | 23:14 |
| * ajmitch has no proper quantal setup yet | 23:14 | |
| Laney | http://paste.debian.net/183446/ | 23:14 |
| ajmitch | Laney: that's a short list | 23:14 |
| Laney | good eh | 23:15 |
| Laney | rest will just be rebuilds | 23:15 |
| Laney | nighty night | 23:15 |
| ajmitch | night | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!