=== lifeless_ is now known as lifeless [08:52] bdrung: native sync sponsorship landed this morning. u-d-t upload time [09:04] sweeeeeeeeeeeeeeeeeeeeeeeeeeeeeet [09:05] * micahg must have missed some mails [09:05] all on the bug [09:07] boo, none in the queue [09:10] there's no visual indication yet [09:10] I did two syncs in oneiric on qastaging (one sponsored), but they both show up as me in the queue [09:13] could you please tell me which bug #, so I can give it a read? === almaisan-away is now known as al-maisan [09:13] https://bugs.launchpad.net/launchpad/+bug/827555 [09:13] Ubuntu bug 827555 in Launchpad itself "native syncs have no way to indicate sponsorship" [Critical,In progress] [09:13] ty [09:14] if you want you can sync pdfmod -s laney and see how that turns out [09:15] * Laney shower [09:34] micahg: Hi again [09:34] hi elgaton [09:36] micahg: Thanks for reviewing the bug - I'm creating the new debdiff that just fixes the missing dependency. I've got two questions: 1) Do I still need to edit the Maintainer field? 2) Should I use version number 1.2.10.0-0ubuntu2.5 (to mark the fact that some minor edits I made in the Precise version are not there) instead of 1.2.10.0-0ubuntu3? [09:37] (For reference: it's bug #877776) [09:37] Launchpad bug 877776 in openbve (Ubuntu Oneiric) "openbve does not depend on the required package libmono-i18n4.0-all" [Medium,Confirmed] https://launchpad.net/bugs/877776 [09:39] elgaton: yeah, update-maintainer is fine, version should be 1.2.10.0-0ubuntu2.1 [09:40] micahg: OK, so I'll just leave the other debian/control and debian/rules out - thanks again, I'm new at patching :) [09:40] elgaton: thanks for your work, it's not a problem [09:41] ugh, openbve is yet another Ubuntu package not in Debian... [09:42] I know (had a look at Debian's repos before submitting the original fix) [09:42] Laney: would openbve be something for cli-mono? [09:46] micahg: yes, I tried to see if sladen was interested in that [09:49] OK, patch done [09:49] * Elbrus is wondering how long it takes before a package in Debian is automatically synced to Precise (we are far from DebianImportFreeze) [09:49] Elbrus: we are syncing from testing, so shortly after it arrives there [09:50] Laney: ok, but in the past we synced from testing and even experimental. Is that different for LTS? [09:51] I assume you mean unstable, and yes the default is different but we can still sync from there if needed [09:51] (experimental syncs always work like that) [09:51] * Elbrus ment unstable yes. [09:52] Should this difference be mentioned on https://wiki.ubuntu.com/DebianImportFreeze? [09:53] (question mark shouldn't have been in the url) [10:00] we have LTSDebianImportFreeze on the wiki too, so either link to that or fix that page to not say "unstable" at all [10:02] Mainly the link in PrecisePangolin/ReleaseSchedule should be changed then. [10:03] But I am asked at the top of that page to not change the page. [10:05] I'll get it sorted, thanks for pointing it out === keffie_jayx is now known as effie_jayx [10:46] Laney: tested a sync yet? [10:46] nope [10:46] do pdfmod with me if you like [10:46] ok [10:47] * Laney checks it builds :P [10:50] haven't managed to do it yet [10:50] seems to work [10:50] at university, where connectivity is ... interesting... [10:50] you saying it's been synced? [10:50] so, what do we expect? mail to me and you and -changes mail saying my name? [10:50] no, builds [10:51] ah, good, didn't check that :P [10:51] we can do it the other way round if that would be easier [10:53] no, doing it now [10:53] tsocks ftw [10:53] k [10:53] done [10:54] hrm [10:54] it does appear on my synchronised packages [10:55] https://lists.ubuntu.com/archives/precise-changes/2011-December/004614.html [10:55] looks good [10:56] LGTM [10:57] did you get mail? [10:59] yes [10:59] * tumbleweed cuts an upload [11:00] i did not [11:00] do you agree that i should have? [11:00] please poke bigjools about that [11:00] yes, you should have [11:06] rock [11:08] * micahg also just filed bug 902107 which is tangentially related [11:08] Launchpad bug 902107 in Launchpad itself "Uploader/Sponsor information for native syncs is missing" [Undecided,New] https://launchpad.net/bugs/902107 [11:09] yeah I'm pretty sure that is known [11:09] https://bugs.launchpad.net/launchpad/+bug/861488 [11:09] Ubuntu bug 861488 in Launchpad itself "Mention sync requester on package version page" [High,Triaged] === al-maisan is now known as almaisan-away [11:18] Laney: thanks [11:34] tumbleweed: how backportable is this? [11:35] could do with being announced but it should be in a stable release first [11:42] micahg: Laney: yeah, sorry [11:42] micahg: Laney: (re: openbve) === ara is now known as Guest31779 [12:27] Laney: I'll investigate backportability. There are some bits of recent ubuntu-dev-tools that depend on recent distro-info, so they may have to be backported together [12:40] tumbleweed: only sponsor-patch should use the new sponsorship stuff now === almaisan-away is now known as al-maisan [12:41] bdrung: ah, right, sorry, didn't wait for that [12:41] that's a relatively easy patch, too [12:43] tumbleweed: i am happy to review it :) [12:44] bdrung: the patch I waved at you last night was for not sorting .install files when they are executable (see debian-devel recently...) [12:45] tumbleweed: ah ok. .install being an executable is a very, very stupid idea [12:45] most people seem to agree on that [12:45] maybe this will go away before the next devscripts upload :P [12:47] tumbleweed: let's wait for a final decision on that and then apply your patch [12:48] well, it's already out in the wild, but yes, there is backlash [12:48] * tumbleweed hopes the people who use it will sort their scripts :) [12:52] tumbleweed: we somehow need to punish people who are using the new .install scripts ;) [13:01] Hi all... Where can I find instruction to make a removal request ? [13:03] l3on: it's largey common sense [13:03] Ah ok :) [13:03] check reverse dependencies (there's a tool for that in recent ubuntu-dev-tools), and file a bug againts the package [13:03] subscribe ubuntu-sponsors like usual [13:04] if it needs to be blacklisted, say that too [13:13] tumbleweed, thanks a lot [13:13] I'm running this: [13:13] $ reverse-build-depends gtk-led-askpass [13:14] but.. [13:14] reverse-build-depends: unable to find sources files. [13:14] Did you forget to run apt-get update (or add --update to this command)? at /usr/bin/reverse-build-depends line 236. [13:14] okok, cache is updated [13:17] oh god, yes.. by default it looks for precise [13:17] and I don't have deb-src entry for precise in my repo! [13:17] :) [13:20] broder, bug 896902 updated as you said in comment [13:20] Launchpad bug 896902 in gtk-led-askpass (Ubuntu) "Requesting removal of source package `gtk-led-askpass' from Ubuntu" [Wishlist,Confirmed] https://launchpad.net/bugs/896902 === ripps_ is now known as ripps === al-maisan is now known as almaisan-away === ara_ is now known as ara [15:20] l3on: I was talking about reverse-depends. You want to check for reverts dependencies and build dependencies [15:20] l3on: btw, removals that happened in debian don't need to be requested in Ubuntu === yofel_ is now known as yofel [16:07] so if I want to convert a 1.0 package that is already using quilt to 3.0 (quilt), I just have to drop all the quilt stuff from debian/rules, since dpkg-source already applies them? [16:07] psusi: is it your package? [16:08] (we don't make changes like that to debian packages) [16:09] it's abandoned in debian and I'm attemping to overhaul it to the new upstream release ( well, a year old, debian didn't update the last 3 releases beacuse they put a -3 in the upstream version ), and so I'm trying to convert it to 3.0 in the process and have a sponsor upload it [16:09] err, orphaned [16:09] yay [16:10] yup, drop all the quilt stuff from rules [16:10] and the README.source, if it talks about quilt [16:11] k [16:12] that leads me to another question... it also was being maintained in git.. I can't find mention of Vcs-Git: in the debian policy manual [16:13] I'm thinking I want to drop that header? [16:13] IIRC it's in another document. dev-ref? [16:13] no, you want to keep it [16:13] psusi: do you have access to its git repo? [16:14] no [16:15] is it in collab-maint? [16:15] it is git://git.debian.org/git/users/derevko-guest/dmraid.git [16:15] ah, a personal git repo [16:16] yea... of the previous maintainer that orphaned it... [16:16] I suggest applying for collab-maint membership, and hosting the repo there [16:16] hrm... what advantage is there to keeping it in git? [16:16] well, presumably it already has git history [16:17] some... but it's not like it's imported the upstream history [16:17] git seems to be the most popular VCS in debian these days, but yes, you can use anything [16:17] just the debianization of the package and 2 patches [16:18] not importing upstream history is fairly common [16:19] so what do you gain keeping it in git? do they have a system that auto builds the source package when you push to the git repo or something? [16:19] what are you proposing? not keeping it in a VCS at all? [16:19] yea [16:19] * tumbleweed much prefers having my packages in VCS [16:19] it means I don't need to upload them for every tiny tweak [16:19] well, lp will import it into bzr ;) [16:20] I can just collect those up, and upload when I'm ready [16:20] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-vcs by the way [16:20] + you can collaborate with others [16:22] diffing becomes much easier, blame works [16:22] * Laney forgot about the cake [16:22] first class++ [16:23] yeah, a package is not that different to code, right? And who wouldn't use a VCS for that? [16:23] anything of any importance on my machine is in VCS (or should be, but I haven't got around to it yet) [16:23] lp will auto import it into bzr though and if I mostly work with that, then is there any advantage to having a git repo as well for the debian version? [16:24] ohh, you get more history granularity than released versions? [16:24] if you are maintaing it in Debian, you'll probably not find yourself using the UDD branches much [16:24] which is all you get with the bzr auto importer right? [16:24] hrm... [16:24] yes, you can have as much granularity as you want [16:24] if you're used to bzr then you can use that [16:24] * tumbleweed has packages in Debian, in bzr [16:25] * Laney sprinkles the holy water [16:25] I'm fairly abidexterous... most of the upstreams I work with use git, like the kernel... [16:25] I think I like git a little better, but they are pretty close [16:25] yeah, they have different advantages [16:26] my kernel git repo has half a dozen remotes and several local branches that consist of various merges of the remotes and local patches, hehe [16:26] vcs-pkg.org is interesting [16:27] if you like that kind of thing [16:27] it would be nice to use git to maintain the package and import the full git hisotry from upstream, but alas... upstream for dmraid is still using CVS! [16:28] * tumbleweed feels for them [16:28] gag me with a spoon [17:06] Dear MOTUs, I'm humbly seeking for answers which I fear I couldn't find on ubuntu docs. Since natty I have 5 packages ready for upload. They're python-based multitouch games. I tried to follow the REVU path for oneiric and now I updated the packages for precise, but I'm deceived by the message towering on the REVU pages headers, claiming that REVU is not any longer a preferred path for new packages. What I'm going to do is to upload the pac [17:06] files to the single bug entries and subscribe ubuntu-sponsors. Is this the correct way? thanks in advance [17:07] bug entries: https://bugs.launchpad.net/ubuntu/+bug/735782 https://bugs.launchpad.net/ubuntu/+bug/735760 https://bugs.launchpad.net/ubuntu/+bug/735764 https://bugs.launchpad.net/ubuntu/+bug/735773 https://bugs.launchpad.net/ubuntu/+bug/735777 [17:07] Ubuntu bug 735782 in Ubuntu "[needs-packaging] Sponc" [Wishlist,In progress] [17:07] Ubuntu bug 735760 in Ubuntu "[needs-packaging] GeneaTD" [Wishlist,In progress] [17:07] as you might have noticed, people don't look at REVU so much, looking for new packages [17:07] Ubuntu bug 735764 in Ubuntu "[needs-packaging] Magictouch" [Wishlist,In progress] [17:07] Ubuntu bug 735773 in Ubuntu "[needs-packaging] TROff" [Wishlist,In progress] [17:07] Ubuntu bug 735777 in Ubuntu "[needs-packaging] Multitet" [Wishlist,In progress] [17:07] indeed.. [17:07] reviewing new packages is harder than reviewing most other uploads [17:07] and lots of packages end up in universe, with nobody caring for them [17:08] so, there isn't much motivation to add to that... [17:08] OTOH, if going through debian isn't an option, we can review those [17:08] * tumbleweed must still reply to your mail... [17:09] so solibs normally have foo1.0.0 as the lib and foo1 symlinks to foo1.0.0. I'm getting warnings now about the symbols check, and it seems to be because before the lib was 1.0.0rc16, and now it is just 1.0.0. Was that an error the way it was done before? or should the rc16 part be in there? [17:09] For games, there is a combined debian-ubuntu games team. I believetheir channel is #debian-games on OFTC [17:09] well, the problem with debian is that these games are based on xi 2.1 or mtdev [17:10] AFAIK debian has no support for them yet [17:10] or, at least, this was the reason, at natty's time, to push them directly to ubuntu [17:16] looks like they are both in Debian now :-) [17:16] oh, 'add xi 2.1 support', don't know about that [17:17] so, your best bet here is probably the sponsorship queue [17:17] it does seem to work rather well for new packages [17:18] of course, if you have existing sponsor-relationships with people, exploit them :P [17:19] The packages have been reviewed eons ago by Chase Douglas, who showed me the path to the packaging madness :) but I'm sure he's hell of busy now [17:19] it'd be nice if they ended up in debian eventually [17:21] laney: are they supported, then? in this case I might think to change focus to debian.. [17:22] there's an additional point,though: these games depend on python-libavg, which has been recently removed from debian due to obsolescence [17:22] can always be re-added [17:23] so basically the best option from the ubuntu perspective is always to get the packages to be synced from debian [17:24] that's the best for everybody [17:24] we like to move a little faster in ubuntu, so we often jump ahead, but we push everything we can back up [17:30] ok, xi 2.1is in debian sid. so, just to summarize it up: if I find a couple of motus who would spend time into reviewing the packages I might be able to have them pushed in ubuntu for precise. Otherwise, debian way, out with wheezy and sync to ubuntu [17:31] if it's there, why not go through debian now? [17:36] ah, right, ubuntu syncs from sid.. ok, I'll get back to the docs, then (sigh). Thanks for your time, I'll be probably coming back :) [17:37] well, we sync from testing during LTSs [17:37] but we can sync from unstable when we want to [17:44] so no prob for precise. And I have (theoretically) time up to Jan 13th, right? [17:46] later, if necessary [17:48] boost1.48 was added to debian around dec 2 and it's not in ubuntu yet, should i do a sync request? [17:49] blair: it hasn't got into testing yet [17:50] (and we aren't planning on doing a boost transition this cycle, that I know of) [17:50] but it should get in [17:50] it's a brand new package name, so (i think) it wouldn't conflict with the existing boosts [17:51] yes, it doesn't [17:51] blair: you don't have to request it, the archive admins process new packages fro mdebian, but it may taka couple of weeks [17:51] (can be rushed, if necessary) [17:52] i'd like to see it in before the debian import freeze [17:52] that should happen [17:52] if it doesn't, request the sync [17:54] llvm-3.0 was synced over very quickly, would that be because somebody is personally interested in it? [17:55] probably, it has a reverse dep in teh archive [17:59] so the binary package name is libdmraid-1.0.0.rc16. Shouldn't the package name just be libdmraid, and it have version 1.0.0.rc16? [18:00] no [18:00] why not? [18:00] welocome to world of shared libraries [18:00] err, libdmraid1 rather [18:01] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html [18:01] the symbols stuff is supposed to keep track of what minor version a symbol was added in so that linking packages can depend on the correct version right? and only major number changes are supposed to break backward compat? [18:01] yes, but not every upstream understands that [18:01] most need it beaten into them... [18:02] so... it should be libdmraid1 iff upstream understands that? [18:02] if they don't understand it, we should consider whether it should be packaged :P === chrisccoulson_ is now known as chr1sccoulson [18:03] so.... why isn't it an error to have the .0.0.rc16 part in the package name? [18:03] seriously though: if it's still on 1, chances are they have as table ABI [18:03] oh, right [18:03] that's the soname [18:04] the soname should be 1.0.0 shouldn't it? [18:04] no, because 1.0.0 isn't relased yet [18:04] and what they currently have released isn't guaranteed to be ABI compatible with 1.0.0 [18:04] that's why it's version is supposed to be 1.0.0.rc16 [18:04] (abi versions don't necessarily match software versions) [18:04] actually, it should be 1.0.0+rc16 shouldn't it? [18:05] it could be anything, really [18:05] seems that's an error in the current package [18:05] you want it to be +rc16 so that when the final release comes, it's > the +rc16 version don't you? [18:06] the package version prabbly should have been 1.0.0~rc16 [18:06] the soname doesn't have to sort [18:06] ohh, was it a ~ not a + that does that? [18:06] as a muto do I have direct access to a native arm machine? [18:07] no, ubuntu doesn't have porterboxses for non-canonical people [18:07] k then I'll get a guet acc in debian [18:07] jtaylor: happy to sponsor that if you need [18:08] yea, so package version should have been 1.0.0~rc16, soname should have been 1.0.0 shouldn't it? but the symbol file would have listed the version as 1.0.0~rc16, and the name of the lib package should be libdmraid1? [18:09] :( somebody fixed the package I wanted to fix in my first upload this weekend [18:10] psusi: no, the soname shouldn't have been 1.0.0 unless upstream agreed with that [18:10] psusi: upstream clearly hasn't settled on a stable abi yet [18:10] how do you figure? [18:10] they name it 1.0.0 [18:10] psusi: otherwise the soname would be less crazy [18:10] that's the "default" [18:11] no, their makefile builds libdmraid1.0.0 [18:11] it looks like the previous upstream build it as libdmraid1.so, and the debian package had a patch to make it turn into libdmraid1.0.0.rc16 [18:11] right, because they had broken their ABI [18:12] psusi: read the docs I pointed you at [18:12] they who? upstream, or debian? [18:12] upstream [18:12] how do you figure they broke their abi? [18:12] otherwise the debian maintainer whouldn't have changed the soname during the life of the package [18:13] he changed it because it was missing the minor number [18:13] upstream just called it 1, but debian wants it to be 1.0.0 [18:13] presumably because he had to [18:13] now upstream has fixed their makefile to build it as 1.0.0 [18:21] tumbleweed, psusi hdf5 are bad upstream since they break their ABI for patch releases, even changing #defines integer values [18:21] ok, so yea... ldd on the upstream binary says it is importing libdmraid.so.1, so that means the package name should be libdmraid1 shouldn't it? [18:22] blair: who is hdf5? [18:22] it's a package from NCSA to store scientific data [18:25] blair: *IF* we are using libdmraid.so.1 as the soname then the package should be libdmraid1 [18:26] for tha tmatter, why the hell is this even a solib anyhow? it's only used internally by dmraid [18:32] oh boy... the current version has /usr/lib/libdmraid.a and .so... so that means there is no abi in the soname, which is wrong, isn't it? [18:33] .a have no soname [18:33] psusi: did you read the links? [18:35] tumbleweed: yea... so I'm gathering that the soname should be ( and is in the new version ) libdmraid.so.1, and therefore, the package name should be libdmraid1, but in the current version, it was just named libdmraid.so, which I guess is why the packager named the lib package libdmraid1.0.0.rc16 instead of just libdmraid1? [18:36] psusi: my deafult reaciton is not to turst upstreams who say their soname is ... .1 [18:37] but theoretically that is how it should be right? and the reason that the package name isn't just 1, is beacuse the packager didn't trust the upstream to not break abi? [18:38] probably because he could see them breaking it [18:40] so... I should rename the new upstream solib to 1.0.0rc16? [18:42] actually... if I do nothing, the name change and warnings about the .symbol file only means that packages linking to the so will depend on >= the new version, even though they might otherwise have been able to >= the old version right? but since no packages besides dmraid link to the lib... who gives a crap? [18:42] how fast are they changing the ABI, in incompatible ways? [18:42] they haven't even had a release in over a year... it's in stable maintainence mode [18:42] and besides, the damn lib isn't used by anyone else anyow ;) [18:43] when nothing uses it and the abi is unstable it should be a private lib [18:43] yeah, probably [18:43] = not directly in usr/lib [18:43] but some subfolder [18:43] well I guess they intended for others to be able to use it, just nobody does [18:43] that makes your life easier :) [18:44] theoretically I should rename the lib package to 1.0.0.rc16.3 now I guess [18:45] hmm... anyone able to help me debug why backportpackage errors out? [18:45] but since the soname changed, it doesn't matter because either way, anyone trying to link to this package is going to depend on the new version anyhow [18:45] prior to me setting DEBFULLNAME and DEBEMAIL it worked [18:45] psusi: you understand why the soname needs to appear in the package name? [18:45] Resistance: what did you set them to? [18:46] tumbleweed: my name, "Thomas Ward", and my @ubuntu email, trekcaptainusa-tw@ubuntu.com [18:46] there's PGP keys that match that [18:46] Resistance: and the error is? [18:46] sec [18:46] i'll pastebin [18:46] tumbleweed: because it represents the abi version... in other words, a contract that linking to any newer version of the lib that has that major number won't break you [18:46] right? [18:47] tumbleweed: http://pastebin.com/zYzji6Gg [18:47] psusi: what I'm really getting at is that when you bump the ABI, you need to have both packages installed simultaneously until everyone has rebuilt against the new library [18:47] not sure whether something updated or not to break it, but when i didnt set DEBFULLNAME and DEBEMAIL it never did this [18:47] tumbleweed: right, that too [18:48] looks like you nderstand shared library linking :) [18:48] Resistance: missing build dependency? [18:48] jtaylor: debhelper has a build dep? [18:48] so you replace 1.0 with 1.1, or 1.2, and anyone looking for 1 will be happy... you go to 2.0, and you need to be able to have both 1.2 and 2.0 installed [18:48] Resistance: make[1]: po4a: Command not found [18:48] because someone looking for 1 can't use 2.0 [18:49] hmm [18:49] tumbleweed: any idea what package provides that? [18:49] po4a [18:49] heh [18:49] yeah just found that [18:49] thanks [18:51] hm why isn't it erroring out with a proper error message? its in the build depends [18:53] jtaylor: this is building the source package [18:53] jtaylor: it's being called from the clean rule, probably outside the chroot [18:53] we don't check build-deps so much for that... [18:53] you get the same problem with pbuilder [18:55] Resistance: which package is this? [18:55] oh, I see :) [18:55] micahg: backport, debhelper oneiric -> natty to fulfill the build-dep of mysql 5.5 in a backports-staging ppa [18:56] and mysql 5.5 is a build-dep for php5.3.8 :/ [18:56] Resistance: that seems wrong IMHO [18:56] *shrugs* [18:56] that's also wrong IMHO :) [18:56] micahg: https://launchpad.net/~trekcaptainusa-tw/+archive/backports/+build/2995183 :/ [18:57] same in i386 https://launchpad.net/~trekcaptainusa-tw/+archive/backports/+build/2995184 [18:57] but debhelper at least won't break anything in a stable release (at least at runtime), mysql might :) [18:57] micahg: it's because php5 runs some tests that need mysql, and there were of course some changes from 5.1 to 5.5 :) [18:58] ajmitch: right, but to strictly depend on one version of mysql? [18:58] micahg: also https://launchpad.net/~trekcaptainusa-tw/+archive/backports/+build/2983124 [18:58] micahg: I know, it's a recent ubuntu addition [18:59] micahg: fwiw, this is why its not in the deployment PPA [18:59] * Resistance has one for staging and one for deployment [19:00] and a standalone system nobody cares about for testing the stuff in staging :P [19:00] Resistance: I finally got 5.4 through the PPA queue if you want to test that as well [19:00] Resistance: mysql 5.5 isn't a hard requirement since Debian doesn't have it, so I don't think you need to be jumping through all these hoops [19:00] micahg: *shrugs* [19:00] tumbleweed, by when should i submit the sync request for boost1.48 as we approach freeze and to give enough time for it to be synced in? [19:00] micahg: tbh my main concern was DEBFULLNAME and DEBEMAIL [19:00] also... [19:00] i have a version of ZNC i modified that i cant actually get to build either :/ [19:01] * Resistance glares evilly at his computer [19:01] blair: DIF is the point at which it stops syncing atomatically. That doesn't mean we stop getting new packages from debian after that [19:01] Resistance: I'd suggest switching 5.5 for 5.1 in debian/control for the PHP backport [19:01] blair: but yes, just after DIF is a good time to request packages that haven't made it in yet. [19:02] ok, so be patient ;) [19:02] and it's currently December 29th? [19:02] no, Jan 10 [19:02] or 9, I can't remember [19:02] micahg: that'd imply i'd have to reupload the package for php5.3.8 after modifying it [19:03] Resistance: yep :) [19:03] but you shouldn't need the other backports [19:03] * Resistance is already bordering on reaching the maximum bandwidth he's allowed on the campus network [19:03] :P [19:03] Resistance: you don't need to reupload the tarball, just the Debian part, debuild -S -sd [19:04] which is about 350k [19:04] & then wait 12-18 hours for it to build [19:04] heh, it's in dep-wait now I think, so 12-18 hours should be better :) [19:05] ajmitch: hey, i had to wait 48 in order for the oneiric one to actually build. [19:05] * Resistance was very annoyed at this [19:05] Resistance: damn, that's awhile [19:05] mhm [19:05] though I think backports are scored a bit lower than PPA uploads fore precise [19:05] 17/14 for i386/amd64 ATM [19:05] i thought thats just the backports pocket target [19:05] :/ [19:06] * ajmitch took a couple of uploads for 5.4 rc2 to build for precise, thankfully it's built now [19:14] ... [19:14] micahg: how can i get *just* the debian stuff out of the tarball? [19:14] because the default tarball doesnt contain debian/ :/ [19:15] (the one i get from backportpackage -w) [19:15] Resistance: huh? don't you have a local copy of the source you uploadeD? [19:15] micahg: backportpackage :/ [19:15] and the source tarball doesnt get extracted [19:15] so when i checked it [19:15] yeah, backportpackage downloads it [19:15] it didnt have debian/ [19:15] Resistance: dpkg-source -x on the .dsc file [19:15] would if it still existeed [19:15] i was cleaning up some stuff :P [19:15] accidentially'd the folder i was working in [19:16] Resistance: you have the tarball? [19:16] in about 3 minutes i will [19:16] * Resistance is grabbing the source tarball as we speak :P [19:17] Resistance: ok, so, once you have that, in the same dir, just use pull-lp-source php5, it should see your tarball and not download it again, but pull down the debian diff/dsc file [19:17] assuming dget doesnt already do that? :p [19:17] ah THERE'S debian/ [19:17] :P [19:18] ok [19:18] yeah, dget on the dsc would do the same thing [19:18] ... [19:18] this *might* be a bit interesting... [19:18] * Resistance sees a package name that has mysql--5.5 [19:18] fwiw, it looks like the build-depends were changed to include versions to avoid problems with upstart & the mysql postinsts [19:18] which seems to depend solely on the 5.5. packages [19:19] ajmitch: would that end up with the absolute requirement of mysql 5.5? [19:21] it was first changed from mysql-server to mysql-server-core-5.1 & mysql-client-5.1, then those changed to 5.5 [19:21] ajmitch: happen to know which version(s) of mysql-server-core and mysql-client are in natty? [19:21] should be 5.1 [19:22] checking with rmadison now if mysql-server-core-5.1 was split out there [19:22] & it was, so you should be safe to use that [19:23] yeah, you probably don't want these changes either: http://launchpadlibrarian.net/85839251/php5_5.3.8.0-1ubuntu1_5.3.8.0-1ubuntu2.diff.gz [19:26] micahg: any advice would be useful before i debuild -S -sd the thing [19:27] * Resistance has already added a changelog entry and has already modified debian/control [19:27] Resistance: well, if you pulled the ubuntu2 revision from precise above, you'll want to revert those other changes as well [19:28] yes i did pull from precise, ubuntu2. any way i can easily undo a diff given the diff file? [19:28] without digging around in code manually [19:29]