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:34 |
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:46 |
broder | a fakesync takes the packaging from debian and overlays it on the orig tarball that ubuntu is now stuck with | 01:47 |
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:48 |
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) | 01:49 |
mikeit | Hello! | 03:15 |
=== yofel_ is now known as yofel | ||
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 :/ | 10:13 |
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 | 13:57 |
jtaylor | wtf python2.7-dev amd64 2.7.2-9ubuntu1 [44.0 MB] | 15:25 |
jtaylor | why is that so large | 15:25 |
=== Quintasan_ is now known as Quintasan | ||
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:56 |
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:57 |
jtaylor | -dev packages usually have = {binary...} dependencies | 18:58 |
KNRO | yes, should I say the dev package should be >= 2.3 then? | 19:00 |
jtaylor | no, -dev packages should always be the exact same version as the accompanied library | 19:01 |
l3on | KNRO, apt-cache policy libapogee2 | 19:01 |
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:02 |
jtaylor | doesn't your ppa provide the -dev package? | 19:03 |
KNRO | yes | 19:03 |
jtaylor | then apt should see that too | 19:04 |
jtaylor | whats the output of l3ons line? | 19:04 |
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:06 |
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:08 |
Ampelbein | KNRO: Can you give the link to your ppa? | 19:12 |
KNRO | Ampelbein: Sure. https://launchpad.net/~mutlaqja/+archive/ppa | 19:13 |
KNRO | This is the buildlog: https://launchpadlibrarian.net/89300412/buildlog_ubuntu-oneiric-i386.indi-apogee_1.1-0~23~oneiric1_FAILEDTOBUILD.txt.gz | 19:14 |
Ampelbein | KNRO: The -dev package of your ppa version is named libapogee2-dev, you build-depend on libapogee-dev. | 19:15 |
KNRO | Ampelbein: arghhh! Ok thanks let me check! | 19:20 |
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 ;-) | 19:22 |
Ampelbein | l3on: fdm sync (#913253) accepted, thanks for your work! | 20:41 |
l3on | Ampelbein, thanks for your review :) | 20:41 |
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:37 |
achiang | step 5 gives an error: Nothing in patch add-manpage.patch | 21:38 |
jtaylor | can you add before touching it? | 21:39 |
Ampelbein | achiang: switch steps 3 and 4. | 21:39 |
achiang | Ampelbein: jtaylor: thanks, will give it a shot | 21:40 |
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:41 |
achiang | this is a leaky difference between quilt and a real vcs like git/bzr | 21:42 |
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:43 |
jtaylor | does that work < preciase? | 21:44 |
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:45 |
achiang | yay, that got it | 21:49 |
achiang | and now i'm lintian clean | 21:49 |
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:11 |
ockham | what's necessary for ubuntu to have the updated orig tarball? | 22:12 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
soren | Makes sense? | 22:20 |
bencc | yes, makes sense | 22:20 |
bencc | so I could have mypackage.script1.upstart and mypackage.script2.upstart | 22:21 |
soren | bencc: Right. | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!