[01:34] hi, any clue why this https://launchpad.net/ubuntu/+source/pysolfc-cardsets package's version is suffixed "fakesync1"? i originally (2.0+dfsg-0ubuntu1) submitted it via MOTU and have recently had an updated version submitted to debian (2.0+dfsg-1, which has now been synced to ubuntu. is it because i changed the orig tarball (some cardsets turned out to be ok with dfsg)? could it have been avoided by versioning the dfsg suffix? [01:34] most of all: is a fakesync something i need to worry about? [01:46] ockham: yes. because of how apt repositories work, a repository can never hold two different files with the same file name [01:46] when an orig tarball gets uploaded to ubuntu then a different one gets uploaded to debian, this would create a conflict for a normal sync [01:47] a fakesync takes the packaging from debian and overlays it on the orig tarball that ubuntu is now stuck with [01:48] so if debian had gotten the same orig tarball, or they had been named differently, there wouldn't have been a conflict, and we wouldn't have needed to do a fakesync [01:49] most of our tools will automatically detect if a fakesync is needed instead of a normal sync and do the fakesync instead (syncpackage can do this, for instance) [03:15] Hello! === yofel_ is now known as yofel [10:13] jtaylor, around? I'm patchig dkopp (ukopp already done by Ilya). Have you talked with upstream, right? There is no new release in the download page :/ [13:57] l3on: hm I'll just fix dkopp as it doesn't affect debian, ping me when a new upstream comes out and you have it in debian [13:57] jtaylor, I applied patch in debian packages, now waiting for a sponsor. [13:57] ok [15:25] wtf python2.7-dev amd64 2.7.2-9ubuntu1 [44.0 MB] [15:25] why is that so large === Quintasan_ is now known as Quintasan [18:56] hello, I encountered a dependency error building in launchpad [18:56] libapogee-dev : Depends: libapogee2 (= 2.2-0ubuntu1) but 2.3-0~21~oneiric1 is to be installed [18:57] I don't understand why the latest version 2.3 is not installed if it's available? [18:57] there is no requirement for = 2.2 [18:58] -dev packages usually have = {binary...} dependencies [19:00] yes, should I say the dev package should be >= 2.3 then? [19:01] no, -dev packages should always be the exact same version as the accompanied library [19:01] KNRO, apt-cache policy libapogee2 [19:02] jtaylor: the problem is the 2.2 is available in universe while 2.3 of the package is available in my ppa [19:02] so apparently launchpad tries to use the 2.2 version but it also 'sees' the 2.3 [19:03] doesn't your ppa provide the -dev package? [19:03] yes [19:04] then apt should see that too [19:04] whats the output of l3ons line? [19:06] Installed: (none) Candidate: 2.2-0ubuntu1 Version table: 2.2-0ubuntu1 0 [19:06] but this is local, I'm trying to build this on launchpad using a recipe [19:08] so I'm trying to build a package (indi-apogee) that depends on libapogee2. The version in universe is 2.2, the version in my ppa is 2.3. launchpad says that libapogee-dev depends on 2.2, even though when it can see that 2.3 is the latest one and is going to be installed. [19:12] KNRO: Can you give the link to your ppa? [19:13] Ampelbein: Sure. https://launchpad.net/~mutlaqja/+archive/ppa [19:14] This is the buildlog: https://launchpadlibrarian.net/89300412/buildlog_ubuntu-oneiric-i386.indi-apogee_1.1-0~23~oneiric1_FAILEDTOBUILD.txt.gz [19:15] KNRO: The -dev package of your ppa version is named libapogee2-dev, you build-depend on libapogee-dev. [19:20] Ampelbein: arghhh! Ok thanks let me check! [19:22] Ampelbein: Spent two hours on this! Thanks for catching the problem, will have to READ carefully next time [19:22] Happens to all of us ;-) [20:41] l3on: fdm sync (#913253) accepted, thanks for your work! [20:41] Ampelbein, thanks for your review :) [21:37] ugh, this should be simple, but i'm not getting it. how does one add a brand new file using quilt? a binary doesn't have a manpage, so i did: [21:37] 1) quilt new add-manpage.patch [21:37] 2) touch resources/man/foo.1 [21:37] 3) [21:37] 4) quilt add resource/man/foo.1 [21:37] 5) quilt refresh [21:38] step 5 gives an error: Nothing in patch add-manpage.patch [21:39] can you add before touching it? [21:39] achiang: switch steps 3 and 4. [21:40] Ampelbein: jtaylor: thanks, will give it a shot [21:41] Quilt refresh will diff the current version versus the original version added with quilt add, so if you edit before adding quilt will never see the original. [21:41] ah [21:42] this is a leaky difference between quilt and a real vcs like git/bzr [21:43] in format 3.0 packages just create the file and run debuild [21:43] better, run dpkg-source --commit. [21:43] as the default is currently to abort on uncommited changes. [21:44] does that work < preciase? [21:45] jtaylor: it is a 3.0 package... but doesn't that create a debian-changes patch? [21:45] yes [21:45] jtaylor: nope, was introduced in 1.16.1.1, only in precise. [21:45] rename it and fill out the templete [21:45] right [21:49] yay, that got it [21:49] and now i'm lintian clean [22:11] what do i need to do about that fakesync issue in pysolfc-cardsets? (https://launchpad.net/ubuntu/+source/pysolfc-cardsets ). i've modified the orig tarball in the version that got synced from debian (some more cardsets had turned out to be dfsg-compatible), and now there's that fakesync which apparently means that the version that's now scheduled for inclusion in precise has the old orig tarball. [22:12] what's necessary for ubuntu to have the updated orig tarball? [22:15] bencc: Well, essentially, from upstart's perspective the package just needs to ship two job descriptions. [22:15] bencc: I.e. two files in /etc/init [22:16] soren: now I have upstart [22:16] bencc: Usually, if you only have a single job, you just name it debian/whatever.upstart, right? [22:16] soren: so I need to replace it with /etc/init/script1 and /etc/init/script2? [22:16] soren: right [22:16] bencc: Kinda. [22:17] bencc: That is what needs to happen, but debhelper lends you a helping hand here. [22:17] soren: how? [22:17] bencc: You can just put another upstart job in debian/. Call it e..g debian/whatever.somethingelse.upstart [22:18] bencc: It'll be installed as /etc/init/somethingelse.conf [22:18] soren: don't I need to call it with my package name? [22:18] just arbitrary name? [22:18] bencc: Yes. That's the "whatever" part. [22:19] If your single upstart job is now called whatever.upstart, your other one should be called whatever.somethinglese.upstart [22:19] soren: thanks [22:19] I.e. the first part tells debhelper which binary package the upstart job will go to. [22:19] The second part tells it what the name of the job should be. [22:20] Makes sense? [22:20] yes, makes sense [22:21] so I could have mypackage.script1.upstart and mypackage.script2.upstart [22:46] bencc: Right.