[01:34] <ockham> 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] <ockham> most of all: is a fakesync something i need to worry about?
[01:46] <broder> ockham: yes. because of how apt repositories work, a repository can never hold two different files with the same file name
[01:46] <broder> 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] <broder> a fakesync takes the packaging from debian and overlays it on the orig tarball that ubuntu is now stuck with
[01:48] <broder> 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] <broder> 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] <mikeit> Hello!
[10:13] <l3on> 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] <jtaylor> 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] <l3on> jtaylor, I applied patch in debian packages, now waiting for a sponsor.
[13:57] <jtaylor> ok
[15:25] <jtaylor> wtf python2.7-dev amd64 2.7.2-9ubuntu1 [44.0 MB]
[15:25] <jtaylor> why is that so large
[18:56] <KNRO> hello, I encountered a dependency error building in launchpad
[18:56] <KNRO> libapogee-dev : Depends: libapogee2 (= 2.2-0ubuntu1) but 2.3-0~21~oneiric1 is to be installed
[18:57] <KNRO> I don't understand why the latest version 2.3 is not installed if it's available?
[18:57] <KNRO> there is no requirement for = 2.2
[18:58] <jtaylor> -dev packages usually have = {binary...} dependencies
[19:00] <KNRO> yes, should I say the dev package should be >= 2.3 then?
[19:01] <jtaylor> no, -dev packages should always be the exact same version as the accompanied library
[19:01] <l3on> KNRO, apt-cache policy libapogee2
[19:02] <KNRO> jtaylor: the problem is the 2.2 is available in universe while 2.3 of the package is available in my ppa
[19:02] <KNRO> so apparently launchpad tries to use the 2.2 version but it also 'sees' the 2.3
[19:03] <jtaylor> doesn't your ppa provide the -dev package?
[19:03] <KNRO> yes
[19:04] <jtaylor> then apt should see that too
[19:04] <jtaylor> whats the output of l3ons line?
[19:06] <KNRO> Installed: (none)   Candidate: 2.2-0ubuntu1   Version table:    2.2-0ubuntu1 0
[19:06] <KNRO> but this is local, I'm trying to build this on launchpad using a recipe
[19:08] <KNRO> 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] <Ampelbein> KNRO: Can you give the link to your ppa?
[19:13] <KNRO> Ampelbein: Sure. https://launchpad.net/~mutlaqja/+archive/ppa
[19:14] <KNRO> This is the buildlog: https://launchpadlibrarian.net/89300412/buildlog_ubuntu-oneiric-i386.indi-apogee_1.1-0~23~oneiric1_FAILEDTOBUILD.txt.gz
[19:15] <Ampelbein> KNRO: The -dev package of your ppa version is named libapogee2-dev, you build-depend on libapogee-dev.
[19:20] <KNRO> Ampelbein: arghhh! Ok thanks let me check!
[19:22] <KNRO> Ampelbein: Spent two hours on this! Thanks for catching the problem, will have to READ carefully next time
[19:22] <Ampelbein> Happens to all of us ;-)
[20:41] <Ampelbein> l3on: fdm sync (#913253) accepted, thanks for your work!
[20:41] <l3on> Ampelbein, thanks for your review :)
[21:37] <achiang> 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] <achiang> 1) quilt new add-manpage.patch
[21:37] <achiang> 2) touch resources/man/foo.1
[21:37] <achiang> 3) <edit foo.1>
[21:37] <achiang> 4) quilt add resource/man/foo.1
[21:37] <achiang> 5) quilt refresh
[21:38] <achiang> step 5 gives an error: Nothing in patch add-manpage.patch
[21:39] <jtaylor> can you add before touching it?
[21:39] <Ampelbein> achiang: switch steps 3 and 4.
[21:40] <achiang> Ampelbein: jtaylor: thanks, will give it a shot
[21:41] <Ampelbein> 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] <achiang> ah
[21:42] <achiang> this is a leaky difference between quilt and a real vcs like git/bzr
[21:43] <jtaylor> in format 3.0 packages just create the file and run debuild
[21:43] <Ampelbein> better, run dpkg-source --commit.
[21:43] <Ampelbein> as the default is currently to abort on uncommited changes.
[21:44] <jtaylor> does that work < preciase?
[21:45] <achiang> jtaylor: it is a 3.0 package... but doesn't that create a debian-changes patch?
[21:45] <jtaylor> yes
[21:45] <Ampelbein> jtaylor: nope, was introduced in 1.16.1.1, only in precise.
[21:45] <jtaylor> rename it and fill out the templete
[21:45] <achiang> right
[21:49] <achiang> yay, that got it
[21:49] <achiang> and now i'm lintian clean
[22:11] <ockham> 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] <ockham> what's necessary for ubuntu to have the updated orig tarball?
[22:15] <soren> bencc: Well, essentially, from upstart's perspective the package just needs to ship two job descriptions.
[22:15] <soren> bencc: I.e. two files in /etc/init
[22:16] <bencc> soren: now I have upstart
[22:16] <soren> bencc: Usually, if you only have a single job, you just name it debian/whatever.upstart, right?
[22:16] <bencc> soren: so I need to replace it with /etc/init/script1 and /etc/init/script2?
[22:16] <bencc> soren: right
[22:16] <soren> bencc: Kinda.
[22:17] <soren> bencc: That is what needs to happen, but debhelper lends you a helping hand here.
[22:17] <bencc> soren: how?
[22:17] <soren> bencc: You can just put another upstart job in debian/. Call it e..g debian/whatever.somethingelse.upstart
[22:18] <soren> bencc: It'll be installed as /etc/init/somethingelse.conf
[22:18] <bencc> soren: don't I need to call it with my package name?
[22:18] <bencc> just arbitrary name?
[22:18] <soren> bencc: Yes. That's the "whatever" part.
[22:19] <soren> If your single upstart job is now called whatever.upstart, your other one should be called whatever.somethinglese.upstart
[22:19] <bencc> soren: thanks
[22:19] <soren> I.e. the first part tells debhelper which binary package the upstart job will go to.
[22:19] <soren> The second part tells it what the name of the job should be.
[22:20] <soren> Makes sense?
[22:20] <bencc> yes, makes sense
[22:21] <bencc> so I could have mypackage.script1.upstart and mypackage.script2.upstart
[22:46] <soren> bencc: Right.