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