[01:21] <darkxst> I am thinking of upload the current version of synergy to raring, but its not backwards compatible with the existing version in the repo's
[01:21] <darkxst> whats the best way to handle that? obviously would need to keep the old version available as well
[01:22] <micahg> darkxst: depends, if the old version isn't supported, it should just be replaced, but in either case, something like this should probably be done through Debian
[01:23] <micahg> experimental has 1.3.10
[01:25] <darkxst> micahg, current branch is 1.4.x
[01:25] <darkxst> I think the 1.3 branch is no longer supported upstream
[01:26] <micahg> darkxst: I'd suggest speaking with the Debian maintainer about how he plans on handling the new version and what you can do to help
[01:26] <micahg> hrm, I read wrong, experimental has 1.4.10
[01:29] <darkxst> micahg, so we could just sync that?
[01:29] <micahg> well, upstream it's marked as beta
[01:30] <micahg> idk if it's syncable or we need our diff still
[01:30] <micahg> ah, I see we're in sync again
[01:34] <darkxst> yes upstream 1.4.x is marked as beta, however as I said 1.3 branch is not maintained anymore and hasnt been for quite a while
[01:35] <micahg> so, assuming 1.4.x is usable in raring, yeah, you can pursue a sync (and might want to backport to precise and quantal since it's incompatible with the ones in that release)
[01:38] <darkxst> micahg, yes I have 1.4 running across raring, quantal and precise machines
[01:38] <darkxst> works fine on all 3 machines
[01:38] <micahg> ok, go for it then :)
[01:39] <darkxst> ok will do
[01:47] <TheLordOfTime> micahg, what's the general turnaround time for backport requests that've been checked/tested?
[01:47] <micahg> TheLordOfTime: depends if the backporters have time :), so for me, that's later this week
[01:48] <TheLordOfTime> mmkay :)
[05:22] <ESphynx> who should I notify for a synx again?
[05:24] <ESphynx> sync*
[05:28] <ScottK> ESphynx: Subscribe the bug to ubuntu-sponsors.
[05:30] <ESphynx> right :) did that :) thanks
[08:02] <dholbach> good morning
[08:06] <mitya57> hi dholbach
[08:06] <dholbach> hey mitya57
[08:06] <mitya57> did you notice that I fixed oneiric & precise builds?
[08:06] <dholbach> mitya57, u-p-g builds again on all releases :)
[08:06] <mitya57> :)
[08:06] <dholbach> good work! спасибо! :)
[08:07] <dholbach> probably time to enable Spanish? :)
[08:07] <mitya57> yes, I think
[08:07] <mitya57> it should build on >= precise
[08:08] <mitya57> also, do you have anything against http://bazaar.launchpad.net/~mitya57/ubuntu-packaging-guide/no-pot-hashes/revision/230?
[08:12] <dholbach> mitya57, no, it's a good idea - I'm not sure how careful we need to be, but do you think the regex should also make sure the line ^"# " and ends after those 32 chars?
[08:13] <dholbach> mitya57, those hashes irked me too to be honest - it makes a .pot diff harder to read than necessary and they change all the time
[08:13] <mitya57> I can add "# " to the regexp
[08:14] <dholbach> sweet
[08:14] <dholbach> thanks you
[08:17] <mitya57> dholbach, fixed and pushed
[08:18] <dholbach> great work
[08:18] <dholbach> thanks
[08:28] <dholbach> mitya57, can you review http://code.launchpad.net/~dholbach/ubuntu-packaging-guide/enable-spanish? (basically I just removed the footnote as discussed and ran ./debian/scripts/add-languages + bzr add)
[08:28] <dholbach> https://code.launchpad.net/~dholbach/ubuntu-packaging-guide/enable-spanish/+merge/137770
[08:29] <mitya57> dholbach, removed the footnote? why? it should work with my fixed sphinx
[08:30] <mitya57> I can also backport the fix to oneiric if you want
[08:31] <dholbach> ok, let me see
[08:32] <dholbach> that might be good
[08:32] <dholbach> for the archive itself it will be irrelevant though
[08:33] <mitya57> for "official" backports (not in ppa) we can either disable translations or backport sphinx
[08:35] <dholbach> mitya57, it does not build for me with the footnote reenabled: http://paste.ubuntu.com/1409815/
[08:35] <mitya57> dholbach, what version of sphinx?
[08:35] <dholbach> mitya57, it's at the bottom of the pastebin
[08:36] <dholbach> 1.1.3+dfsg-5ubuntu1~ppa1~12.10
[08:36] <dholbach> sorry, it got cut off I just noticed
[08:38] <mitya57> very strage, builds perfectly for me, the patch is the same and is enabled in series
[08:39]  * mitya57 installs the package from ppa
[08:44] <mitya57> dholbach, works with sphinx from ppa for me, can you run "make clean" and then try to build again?
[08:44] <dholbach> mitya57, I built it in a pbuilder
[08:44] <dholbach> ah ok
[08:45] <dholbach> nevermind
[08:45] <dholbach>  /o\
[08:45] <dholbach> let me get another coffee :)
[08:48] <dholbach> mitya57, it works
[08:49] <dholbach> I updated https://code.launchpad.net/~dholbach/ubuntu-packaging-guide/enable-spanish/+merge/137770
[08:53] <mitya57> dholbach, looks good, thank you!
[08:54] <mitya57> the only thing I maybe don't like is "This is the 'es' version." string
[08:54] <dholbach> mitya57, it's done automatically :)
[08:55] <mitya57> I know, but maybe we can manually correct it to something better
[08:55] <mitya57> like "This is the Spanish translation of the guide"
[08:56] <dholbach> hang on
[08:57] <dholbach> updated
[08:58] <mitya57> dholbach, danke, push it
[08:58] <dholbach> can't believe we're about to fix this :)
[09:00] <mitya57> re the warnings: it's not our issue, a workaround is https://gist.github.com/4169008
[09:00] <dholbach> ah ok
[09:00] <dholbach> mitya57, can you leave a comment on the merge proposal or 'approve' it?
[09:02] <mitya57> done
[09:03] <dholbach> спасибо!
[14:19] <alo21> TheLordOfTime, hi, can you help me making a package, please?
[14:19] <TheLordOfTime> no.
[14:19] <TheLordOfTime> what am I, packager for hire...?
[14:19] <TheLordOfTime> :/
[14:19] <alo21> would you?
 TheLordOfTime, hi, can you help me making a package, please?
 no.
[14:20]  * TheLordOfTime returns to poking at the kernel on his test VM
[14:22] <coolbhavi> alo21, hey
[14:23] <alo21> coolbhavi, hi
[14:24] <coolbhavi> alo21, I guess you contacted me a few days back regarding doc-debian
[14:24] <coolbhavi> merge
[14:25] <alo21> coolbhavi, yes
[14:26] <coolbhavi> alo21, when I tested on my PPA it ftbfs'd due to missing dir
[14:26] <alo21> coolbhavi, yea me too
[14:26] <coolbhavi> alo21, hmm
[14:27] <alo21> and this should not happens because this specific bus is closed
[14:27] <alo21> bugs.debian.org/cgi-bin/bugreport.cgi?bug=690791
[14:27] <TheLordOfTime> Debian Bug 690791
[14:31] <coolbhavi> alo21, sorry I hadnt had much time to look at the rules file but looks like the hardcoded checkout is not fixed/applicable in ubuntu
[14:32] <alo21> coolbhavi, hmm... ok thanks
[14:33] <alo21> coolbhavi, I will leave the package. In this way other people can work on it
[14:34] <coolbhavi> alo21, :-) your take :)
[14:35] <alo21> coolbhavi, what do you mean?
[14:36] <coolbhavi> alo21, if you wish, you can work on it further
[14:37] <alo21> ok
[15:02] <alo21> coolbhavi, can I ask you a last thing?
[15:02] <coolbhavi> alo21, yes
[15:03] <alo21> coolbhavi, do you thinks this make's guide is good (http://www.gnu.org/software/make/manual/html_node/index.html#toc_Top)?
[15:04] <coolbhavi> alo21,  for what purpose?
[15:04] <alo21> coolbhavi, packaging
[15:05] <coolbhavi> alo21, you can take a look at the packaging guide of ubuntu
[15:05] <coolbhavi> for a start
[15:05] <alo21> the new one on developer.ubuntu.com. Right?
[15:05] <coolbhavi> yes
[15:05] <coolbhavi> http://developer.ubuntu.com/packaging/html/
[15:06] <alo21> ok. Even if I think it would not be very useful to resolve packaging problem. Did you learn all stuff there?
[15:07] <TheLordOfTime> most of my packaging knowledge is learned from the packaging guide, as well as gentle nudging in the right direction from Debian mentors, and my dissecting packages :P
[15:07]  * TheLordOfTime very rarely does much packaging work nowadays outside of bugfixing things.
[15:09] <ESphynx> dholbach: Thanks for the raring import =)
[16:22] <ESphynx> Hey guys... https://bugs.launchpad.net/ubuntu/+source/ecere-sdk/+bug/1077734 does this look OK for an SRU?
[16:22] <ESphynx> "Ask a bug supervisor to target the bug to the appropriate Ubuntu releases" =)
[16:22] <TheLordOfTime> erm...
[16:23] <TheLordOfTime> not to be stupid or an ass, but isnt a sync != SRU?
[16:23]  * TheLordOfTime waits for a MOTU to respond to that
[16:23] <ESphynx> what should I call it
[16:23] <ESphynx> i was going to say 'bring in'
[16:23] <ESphynx> would that be better?
[16:23] <TheLordOfTime> i dont think they sync anything to quantal, but i'm not a MOTU
[16:23] <TheLordOfTime> so why don't you wait for them to answer my question :P
[16:24] <ESphynx> fair enough
[16:24] <mitya57> ESphynx, doesn't look like a bugfix release
[16:24] <ESphynx> mitya57: how does it not?
[16:24] <mitya57> "Added support for a SYSROOT and GCC prefix in Compiler Settings"
[16:24] <mitya57> "Initial support for the Android platform"
[16:24] <ESphynx> mitya57: there were a few commits included as well. i didn't do a special branch just for it.
[16:24] <ESphynx> mitya57: but the point is that the SDK is otherwise uninstallable.
[16:25] <micahg> ESphynx: no, you should cherry pick the fixes you need for the SRU
[16:25] <TheLordOfTime> what micahg said, which is why I brought up the sync != SRU
[16:25] <ESphynx> ugg.
[16:25] <ESphynx> I don't have time to do that
[16:25] <TheLordOfTime> Having said this, wouldn't backporting be a potential solution, micahg?
[16:25] <TheLordOfTime> in that backport from Raring -> Quantal IF it builds and runs and installs?
[16:25] <micahg> TheLordOfTime: well, the installability should be fixed as an SRU, if one wanted the android support backported, that's a different issue
[16:26] <ESphynx> the android support is still in the works.
[16:26]  * TheLordOfTime forgot to mention he assumed that a targetted bugfix would not be possible/
[16:26] <ESphynx> I just included whatever commit I had in my HEAD at the time
[16:26] <micahg> we don't backport for bug fixes
[16:27] <TheLordOfTime> i see.
[16:27] <micahg> ESphynx: if you ping me next week, I'll see if I can cherry pick the stuff for you quickly
[16:27] <ESphynx> micahg: K, thanks... I could look through right the commits right now and tell you which ones are likely
[16:29] <ESphynx> just that there are a number of other bugs that this would have solved as well.
[16:32] <ESphynx> eww it's going to be very difficult.
[16:32] <ESphynx> things are sure to conflict.
[16:33] <ESphynx> I give up. an SRU would be the best... a Backport perhaps would make it installable?
[16:33] <ESphynx> at any rate I'm late for the office.
[16:33] <ESphynx> cheers. thanks guys.
[16:34] <TheLordOfTime> backports for bugfixes are a no-go, and micahg'd know.
[16:34] <TheLordOfTime> at least, that's how i'm interpreting him.
[16:34] <ESphynx> well. we're f'ed then.
[16:34] <ESphynx> Quantal users on 64 bit machines can't use it
[16:34] <TheLordOfTime> micahg, feel free to confirm/modify my interpretation if its wrong. :P
[16:36] <ESphynx> there were 2 goals for this 0.44.02 release...
[16:37] <ESphynx> Be included into Sid ... Failed.
[16:37] <ESphynx> Fix issues on Quantal/64bit ... Failed.
[16:37] <TheLordOfTime> isn't sid frozen right now?
[16:37] <TheLordOfTime> or partly-frozen at least...
[16:38] <ESphynx> probably why :P
[16:38] <ESphynx> thought it was frozen for years :P
[16:38] <TheLordOfTime> they ahve insane freeze times
[16:38] <TheLordOfTime> :P
[16:38] <micahg> sid is only "frozen" for packages that need migration to wheezy, new packages can go there anytime AIUI
[16:39] <ESphynx> thought so
[16:39] <TheLordOfTime> that's assuming anyone is handling experimental -> sid stuff
[16:39] <TheLordOfTime> no?
[16:39] <micahg> and I say "frozen" since maintainers can still upload whatever they want, it just won't mmigrate
[16:39] <micahg> TheLordOfTime: it's not automatic, requires a new upload
[16:39] <TheLordOfTime> ah.
[16:39] <ESphynx> micahg: bug fixes aside, couldn't a new package just be backported?
[16:40] <TheLordOfTime> yeah, was curious, usually ZNC (which i asked to be synced to raring, which was done) is in sid, not experimental, or it migrates fast.
[16:40] <TheLordOfTime> so... *shrugs*
[16:40] <ESphynx> though backport are still not automatic right, so apt-get install ecere-sdk would still not install on a fresh Quantal?
[16:40] <micahg> ESphynx: only for features, not bug fixes, -backports isn't a way to work around the SRU process
[16:40] <TheLordOfTime> guess the debian freeze is messing with them :P
[16:40] <ESphynx> micahg: But not all bug fixes are SRUs?
[16:41] <ESphynx> there isn't such a clear bug fixes/features separation in our development stream :P
[16:41] <micahg> yeah, true, if it's not SRU worthy, we'd probably take it in backports, but this is very SRU worthy
[16:41] <ESphynx> ah ok
[16:41] <ESphynx> well, damn.
[16:41] <ESphynx> let me try again.
[16:41] <TheLordOfTime> micahg, pure curiosity: are security bugs subject to a different process, or also subject to the SRU process?  (in regards to expediency of getting things into -security or -updates)
[16:42] <TheLordOfTime> or should I be bugging -hardened about that one?
[16:42] <micahg> TheLordOfTime: different, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[16:42] <TheLordOfTime> that's what i thought, wasn't sure :)
[16:44] <ESphynx> truth is most of the commits are fixes oriented...
[16:45] <ESphynx> major bug fixes/minor additions :| the build system changed, so all makefiles changed... and the wanted commits fixing bugs won't work without the build system improvemens
[16:47] <ESphynx> well thanks again micahg. gotta go now
[16:48] <micahg> ESphynx: so, ping me next week, we'll see about cherry picking a fix, you'll just be on the hook for the paperwork/testing
[16:49] <ESphynx> micahg I'd basically have to do the work over again.
[16:50] <ESphynx> had I known, I would have focused on the SRU first.
[16:50] <micahg> ESphynx: I thought I told you that weeks ago...(to do a targeted fix for just these issues to Debian)
[16:50] <ESphynx> It's all about my understanding of the word 'targeted' :)
[16:51] <TheLordOfTime> FWIW...
[16:51] <TheLordOfTime> "targetted" basically means highly-specific fixes.
[16:51] <TheLordOfTime> at least here it does.
[16:51] <TheLordOfTime> :P
[16:51] <ESphynx> this was highly specific for me. just not enough :P
[16:51] <micahg> ESphynx: anyways, the installability should be control file fixes and easily pickable, I'd help you with that next week
[16:52]  * micahg goes back to hiding now
[16:52] <ESphynx> micahg: that can probably be cherry-picked easily. problem is I had to change the runtime to look for files in /usr/lib/ec/
[16:52] <ESphynx> so there are some code changes there as well.
[16:52] <ESphynx> And I was hoping to also include the fixes I did so the bots could try to build on ARM and PPC again
[16:52] <ESphynx> and some buffer overflow bugs in there...
[16:53] <ESphynx> cheers.
[19:02] <nxvl> jtaylor: ping
[19:02] <jtaylor> nxvl: ?
[19:03] <nxvl> jtaylor: hey, i'm trying to backport python-numpy to lucid and saw you are/were doing a lot of work on it
[19:04] <jtaylor> nxvl: you are better of using the numpy in debian
[19:04] <nxvl> jtaylor: it'm having a hard time because of dependencies and stuff and i was wondering if you had any pointers on how can i do that
[19:04] <jtaylor> it still uses pysupport, ubuntus uses dh_python2 which is not available in lucid
[19:04] <nxvl> jtaylor: awesome, thanks!
[19:04] <jtaylor> which dependencies?
[19:04] <nxvl> jtaylor: exactly what you are talking about
[19:05] <nxvl> the dh_python2 stuff