=== hggdh_ is now known as hggdh === barry` is now known as barry === elky` is now known as elky === broder_ is now known as broder [06:38] good morning [08:31] What is "whitespace" ? [09:27] bdrung: erm, so we sohuld backport the new distro-info-data [09:27] SRU? [09:28] yes [09:28] that thing [09:28] any objection to just SRUing a straight backport? [09:28] tumbleweed: yes and probably do another upload before (please have a look at my commits whether they are sane) [09:28] (it's less work) [09:28] oh, did I screw itup? :) [09:29] partially :) [09:29] wheezy was released on the 5th, not the 4th [09:29] the release notes have a different date [09:30] there's a date in the release notes? [09:30] $ debian-distro-info -t [09:30] experimental [09:31] http://www.debian.org/releases/stable/ says Debian 7.0 was released May 4th, 2013 [09:31] and http://www.debian.org/News/2013/20130504 says "May 4th, 2013" at the top [09:32] lol [09:32] anyway I don't care about that too much [09:32] the testing thing is a bigger issue, though [09:33] i'll do an upload if that's okay to you [09:33] fine [09:33] can you request an upload into stable-updates? [09:38] tumbleweed: which procedure to i need to follow for that? [09:46] bdrung: actually, no idea. We should ask [09:47] tumbleweed: am i allowed to offload this work to you? [09:47] sure, I started it [09:47] um, so SRUing a straight backport? [09:47] what do you mean with "SRUing a straight backport" [09:48] I mean using backport style versions and a full changelog, rather than applying a patch to a bunch of releases [09:48] bdrung: FYI: from #debian-release: 09:48 < ansgar> tumbleweed: Same as into proposed-updates + mention stable-updates in the pu bug. [09:49] i prefer the latter, but it's up to you (if the latter is too time consuming) [09:49] tumbleweed: and the procedure? just upload the package isn't sufficient, right? [09:51] for p-u, one requests permission to upload before uploading [09:51] via a bug [09:51] bug against? [09:51] release.debian.org [09:51] okay, thanks for the info [09:52] anyway, why is it giving the wrong output for --testing? [09:57] tumbleweed: because you forgot to adjust "created" for jessie [09:58] http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info-data.git;a=commitdiff;h=9b66417193f2e73c180f644a73fa14d7e8bf388f;hp=20d03b1bd2b589c0e432b829f9661be6dc2bf633 [09:59] oh, duh [09:59] tumbleweed: hurry with the SRU, because oneiric will EOL tomorrow ;) [09:59] pff [10:00] I skipped oneiric in the last round of distro-info-data SRUs === tsimpson_ is now known as tsimpson === Zic_ is now known as Zic === cyphermox_ is now known as cyphermox === dholbach_ is now known as dholbach === achiang` is now known as achiang === iulian_ is now known as iulian === jtaylor_ is now known as jtaylor === jtechidna is now known as JontheEchidna [19:16] where do i ping regarding a sync request for saucy for universe? [19:16] or do i just let it sit for a while? [19:22] autosyncs are running [19:22] so you should not need to request a sync [19:30] unless your package is in experimental [19:33] right, but then its better to ask the maintainer to put it in unstable [19:33] we generally don't want stuff that is intentionally in experimental [19:34] http://packages.qa.debian.org/s/screen.html I take it the RFH is blocking? (https://launchpad.net/ubuntu/+source/screen) [19:36] we have ubuntu delta [19:36] oh right, I forgot about these :O [19:37] Ah, thanks. [19:37] * mitya57 is right now uploading mathjax to unstable, that should make jtaylor happy [19:38] I did say intentionally in experimental [19:38] we do want stuff that is in exp because unstable is sort of frozen [19:43] that should anyway make you happy :) [19:55] ipython should work with both, so I'm ambivalent :p [19:57] in 2.1 I've splitted png package out so libjs-mathjax is just 10 mb instead of 18 [19:57] nice [20:02] jtaylor: it's *in* unstable [20:02] jtaylor: if it's autosync [20:03] 'd, when's the next autosync [20:03] ... stupid keyboard... [20:04] TheLordOfTime: which package? [20:04] mitya57: nginx, in universe [20:05] https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1177919 if you want to burn the bug. [20:05] Launchpad bug 1177919 in nginx (Ubuntu) "Sync nginx 1.4.1-1 (universe) from Debian unstable (main)" [Wishlist,New] [20:05] with delta it needs manual sync [20:06] it will happen soon [20:06] TheLordOfTime: someone filed bug 1177919, was that you? [20:06] bug 1177919 in nginx (Ubuntu) "Sync nginx 1.4.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1177919 [20:06] * TheLordOfTime points at his name on the bug [20:06] * mitya57 is stupid [20:06] mitya57: yeah, it was, because i wasn't sure autosyncs had started [20:07] TheLordOfTime: why "Add ubuntu branding to server_tokens." should be dropped? [20:08] mitya57: that's a question you should ask upstream, the main reason for the sync request is to *add* in additional highly-demanded features that've already been implemented and only recently included in unstable [20:08] TheLordOfTime: why not merge then? [20:08] mitya57: if i had my ways, i'd try and merge the two [20:08] but i don't have the skills for that [20:08] unless there's a nifty requestmerge tool [20:09] in which case someone else would have to do the merging. i don't have the packaging skills to merge. [20:09] * mitya57 has to go sleep today, but will probably try tomorrow [20:09] not having the skills to merge is no reason to do a sync [20:10] can you please unsubscribe sponsors and assign /me? [20:10] only request a sync if the delta can really be dropped [20:10] jtaylor: then explain requesting a merge? [20:10] ask the person who did it last [20:10] jtaylor: there needs to be MUCH better documentation on where to request merges, how to request merges, etc. i was unaware there was a significant delta, also [20:10] why does nginx need ubuntu branding oO [20:10] especially as its universe [20:11] that's what i'm curious to now as well [20:11] it really DOESN'T need ubuntu branding [20:11] TheLordOfTime: http://developer.ubuntu.com/packaging/html/udd-merging.html [20:11] since it's a universe-maintained package [20:11] mitya57: standby i'll remove/subscribe you [20:11] or do you want me to assing it to you [20:11] WORK, KEYBOARD! [20:11] * TheLordOfTime is not pleased about this keyboard breaking [20:11] subscribing should be enough [20:11] mitya57: what's your LP [20:12] the merge does not look difficult [20:12] * TheLordOfTime facedesks [20:12] nevermind [20:12] can you please ensure that the branding is the only thing that can't be dropped [20:12] or can, asl zul [20:12] ask [20:13] probably branding is needed for "Nginx/1.4 (Ubuntu) Server at example.com Port 80"-like strings [20:13] mitya57: i've subscribed you and unsubscribed sponsors [20:13] I see, thanks [20:13] it would help if zul is online, jtaylor [20:14] write an email [20:14] * TheLordOfTime can't email effectively from a mobile wifi connection [20:14] * TheLordOfTime can't email effectively from a mobile wifi connection [20:14] (gmail LAGS) [20:14] * mitya57 waves good night [20:19] jtaylor: after fighting with my mobile wifi, i got an email to zul [20:19] * TheLordOfTime sits down and waits for a response === RAOF_ is now known as RAOF [22:08] Hi guys! 2 days ago i was asking here why my command "bzr builddeb -S" was failing on a branch of a project of which i was trying to fix a bug (dpkg-source lamenting of upstream changes). Now, having read a lot more, I understand (tell me if I'm wrong) that 'bzr builddeb' uses dpkg-source, which raises an error when there are differences from the upstream source not addressed by a patch in debian patch [22:09] yes [22:10] sometimes [22:11] Am I right until here? - So, i proceeded to write my changes on a patch file in two ways: using 'dpkg-source --commit' and 'bzr diff > bugfix.patch' and then importing the patch with 'quilt import bugfix.patch' [22:12] no [22:12] dpkg-source --commit does not commit to the version control [22:13] first thing is if you use bzr-buildpackage and then get this error this probably means you committed a change to the upstream source in your bzr [22:14] Yes [22:15] I mean, I edited a source file of the upstream project (not a packaging-related file) to fix the bug [22:15] I don't know the canonical way in bzr to create patches [22:16] does edit-patch work with bzr? [22:16] but you should not commit directly your changes [22:16] in the main branch at least [22:17] a yes it works somewhat [22:18] possibly the simplest way is to run edit-patch from your source [22:18] then you can edit the files directly [22:18] then logout with ctrl+d [22:18] it will create a quilt patch and changelog [22:18] which you then commit to bzr [22:19] you should first revert your previous direct commits to bzr (or convert them to patches with bzr diff -r... and import them with quilt and commit that) [22:19] Oh. I tought edit-patch wouldn't let me changes files "normally" so I avoided it! [22:20] I thought I had to write directly in diff syntax, lol [22:24] Thanks for the help. But right now I'm trying to try to build a bugfix branch created by another person (that i branched from his launchpad), so the upstream changes are already made, not in patch form [22:25] there is possibly a direct way to do it, but I don't know it [22:25] but "directly committed", if I understand what you mean by it [22:25] what you can do is create diffs with bzr diff of that branch and import these with quilt [22:26] in git you would do e.g. git format-patch base-commit..branch-head-commit [22:26] Yeah, I did that. and the error about upstream changes went away [22:26] and get a bunch of patches you can import [22:26] but another error came up: [22:27] dpkg-source: error: cannot read gnome-screenshot-3.6.1.orig.8S4BV4/debian/patches/bugfix.patch [22:27] bugfix.patch is the generated patch [22:27] did you add the patch to bzr? [22:27] for new files you have to do bzr add ... [22:27] then commit [22:27] see bzr status for untracked files [22:40] No I didn't, I think that was the problem (so stupid :( ). One (I hope last) problem: the patch file created using bzr diff uses relative paths, that do not work with quilt (I imagine Because when importing quilt moves it to debian/patches) [22:43] well, turns out dpkg-source creates a valid patch. I finally managed to build the source package! [22:44] (I meant 'dpkg-source --commit') [22:44] not sure what kind of patches bzr creates [22:44] you need -p1 type patches [22:44] there is a flag -p1 for the diff command of baazar [22:45] I'll try to use that [22:45] I don't think its exactly the same, but similar [22:46] -p1 type is the -p flag of patch [22:46] -p1 is: /patch/to/changed/file [22:46] -p0 would be path/to/changed/file [22:48] 'bzr help diff | grep p1' says: "bzr diff -p1" is equivalent to "bzr diff --prefix old/:new/", and [22:48] produces patches suitable for "patch -p1". [22:49] oh ok [22:49] jtaylor: thanks for your help. you're amazing :) [22:51] np, I'm offline now