=== Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [01:21] 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] whats the best way to handle that? obviously would need to keep the old version available as well [01:22] 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] experimental has 1.3.10 [01:25] micahg, current branch is 1.4.x [01:25] I think the 1.3 branch is no longer supported upstream [01:26] 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] hrm, I read wrong, experimental has 1.4.10 [01:29] micahg, so we could just sync that? [01:29] well, upstream it's marked as beta [01:30] idk if it's syncable or we need our diff still [01:30] ah, I see we're in sync again [01:34] 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] 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] micahg, yes I have 1.4 running across raring, quantal and precise machines [01:38] works fine on all 3 machines [01:38] ok, go for it then :) [01:39] ok will do [01:47] micahg, what's the general turnaround time for backport requests that've been checked/tested? [01:47] TheLordOfTime: depends if the backporters have time :), so for me, that's later this week [01:48] mmkay :) === Logan_ is now known as Brooke === Brooke is now known as k [05:22] who should I notify for a synx again? [05:24] sync* [05:28] ESphynx: Subscribe the bug to ubuntu-sponsors. [05:30] right :) did that :) thanks === k is now known as Logan_ [08:02] good morning [08:06] hi dholbach [08:06] hey mitya57 [08:06] did you notice that I fixed oneiric & precise builds? [08:06] mitya57, u-p-g builds again on all releases :) [08:06] :) [08:06] good work! спасибо! :) [08:07] probably time to enable Spanish? :) [08:07] yes, I think [08:07] it should build on >= precise [08:08] also, do you have anything against http://bazaar.launchpad.net/~mitya57/ubuntu-packaging-guide/no-pot-hashes/revision/230? [08:12] 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] 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] I can add "# " to the regexp [08:14] sweet [08:14] thanks you [08:17] dholbach, fixed and pushed [08:18] great work [08:18] thanks [08:28] 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] https://code.launchpad.net/~dholbach/ubuntu-packaging-guide/enable-spanish/+merge/137770 [08:29] dholbach, removed the footnote? why? it should work with my fixed sphinx [08:30] I can also backport the fix to oneiric if you want [08:31] ok, let me see [08:32] that might be good [08:32] for the archive itself it will be irrelevant though [08:33] for "official" backports (not in ppa) we can either disable translations or backport sphinx [08:35] mitya57, it does not build for me with the footnote reenabled: http://paste.ubuntu.com/1409815/ [08:35] dholbach, what version of sphinx? [08:35] mitya57, it's at the bottom of the pastebin [08:36] 1.1.3+dfsg-5ubuntu1~ppa1~12.10 [08:36] sorry, it got cut off I just noticed [08:38] 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] dholbach, works with sphinx from ppa for me, can you run "make clean" and then try to build again? [08:44] mitya57, I built it in a pbuilder [08:44] ah ok [08:45] nevermind [08:45] /o\ [08:45] let me get another coffee :) [08:48] mitya57, it works [08:49] I updated https://code.launchpad.net/~dholbach/ubuntu-packaging-guide/enable-spanish/+merge/137770 [08:53] dholbach, looks good, thank you! [08:54] the only thing I maybe don't like is "This is the 'es' version." string [08:54] mitya57, it's done automatically :) [08:55] I know, but maybe we can manually correct it to something better [08:55] like "This is the Spanish translation of the guide" [08:56] hang on [08:57] updated [08:58] dholbach, danke, push it [08:58] can't believe we're about to fix this :) [09:00] re the warnings: it's not our issue, a workaround is https://gist.github.com/4169008 [09:00] ah ok [09:00] mitya57, can you leave a comment on the merge proposal or 'approve' it? [09:02] done [09:03] спасибо! === dholbach_ is now known as dholbach === hrww is now known as hrw === Ursinha-afk is now known as Ursinha === yofel_ is now known as yofel === notgary_ is now known as notgary === LordOfTime is now known as TheLordOfTime [14:19] TheLordOfTime, hi, can you help me making a package, please? [14:19] no. [14:19] what am I, packager for hire...? [14:19] :/ [14:19] would you? [14:19] TheLordOfTime, hi, can you help me making a package, please? [14:19] no. [14:20] * TheLordOfTime returns to poking at the kernel on his test VM [14:22] alo21, hey [14:23] coolbhavi, hi [14:24] alo21, I guess you contacted me a few days back regarding doc-debian [14:24] merge [14:25] coolbhavi, yes [14:26] alo21, when I tested on my PPA it ftbfs'd due to missing dir [14:26] coolbhavi, yea me too [14:26] alo21, hmm [14:27] and this should not happens because this specific bus is closed [14:27] bugs.debian.org/cgi-bin/bugreport.cgi?bug=690791 [14:27] Debian Bug 690791 [14:27] Debian bug 690791 in doc-debian "building from source an inconvenient process" [Important,Fixed] http://bugs.debian.org/690791 [14:31] 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] coolbhavi, hmm... ok thanks [14:33] coolbhavi, I will leave the package. In this way other people can work on it [14:34] alo21, :-) your take :) [14:35] coolbhavi, what do you mean? [14:36] alo21, if you wish, you can work on it further [14:37] ok === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ [15:02] coolbhavi, can I ask you a last thing? [15:02] alo21, yes [15:03] 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] alo21, for what purpose? [15:04] coolbhavi, packaging [15:05] alo21, you can take a look at the packaging guide of ubuntu [15:05] for a start [15:05] the new one on developer.ubuntu.com. Right? [15:05] yes [15:05] http://developer.ubuntu.com/packaging/html/ [15:06] ok. Even if I think it would not be very useful to resolve packaging problem. Did you learn all stuff there? [15:07] 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] dholbach: Thanks for the raring import =) === Quintasan_ is now known as Quintasan [16:22] Hey guys... https://bugs.launchpad.net/ubuntu/+source/ecere-sdk/+bug/1077734 does this look OK for an SRU? [16:22] Launchpad bug 1077734 in ecere-sdk (Ubuntu) "[SRU] Please sync ecere-sdk 0.44.02-1 from Raring into Quantal" [Undecided,Fix released] [16:22] "Ask a bug supervisor to target the bug to the appropriate Ubuntu releases" =) [16:22] erm... [16:23] 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] what should I call it [16:23] i was going to say 'bring in' [16:23] would that be better? [16:23] i dont think they sync anything to quantal, but i'm not a MOTU [16:23] so why don't you wait for them to answer my question :P [16:24] fair enough [16:24] ESphynx, doesn't look like a bugfix release [16:24] mitya57: how does it not? [16:24] "Added support for a SYSROOT and GCC prefix in Compiler Settings" [16:24] "Initial support for the Android platform" [16:24] mitya57: there were a few commits included as well. i didn't do a special branch just for it. [16:24] mitya57: but the point is that the SDK is otherwise uninstallable. [16:25] ESphynx: no, you should cherry pick the fixes you need for the SRU [16:25] what micahg said, which is why I brought up the sync != SRU [16:25] ugg. [16:25] I don't have time to do that [16:25] Having said this, wouldn't backporting be a potential solution, micahg? [16:25] in that backport from Raring -> Quantal IF it builds and runs and installs? [16:25] TheLordOfTime: well, the installability should be fixed as an SRU, if one wanted the android support backported, that's a different issue [16:26] 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] I just included whatever commit I had in my HEAD at the time [16:26] we don't backport for bug fixes [16:27] i see. [16:27] ESphynx: if you ping me next week, I'll see if I can cherry pick the stuff for you quickly [16:27] micahg: K, thanks... I could look through right the commits right now and tell you which ones are likely [16:29] just that there are a number of other bugs that this would have solved as well. [16:32] eww it's going to be very difficult. [16:32] things are sure to conflict. [16:33] I give up. an SRU would be the best... a Backport perhaps would make it installable? [16:33] at any rate I'm late for the office. [16:33] cheers. thanks guys. [16:34] backports for bugfixes are a no-go, and micahg'd know. [16:34] at least, that's how i'm interpreting him. [16:34] well. we're f'ed then. [16:34] Quantal users on 64 bit machines can't use it [16:34] micahg, feel free to confirm/modify my interpretation if its wrong. :P [16:36] there were 2 goals for this 0.44.02 release... [16:37] Be included into Sid ... Failed. [16:37] Fix issues on Quantal/64bit ... Failed. [16:37] isn't sid frozen right now? [16:37] or partly-frozen at least... [16:38] probably why :P [16:38] thought it was frozen for years :P [16:38] they ahve insane freeze times [16:38] :P [16:38] sid is only "frozen" for packages that need migration to wheezy, new packages can go there anytime AIUI [16:39] thought so [16:39] that's assuming anyone is handling experimental -> sid stuff [16:39] no? [16:39] and I say "frozen" since maintainers can still upload whatever they want, it just won't mmigrate [16:39] TheLordOfTime: it's not automatic, requires a new upload [16:39] ah. [16:39] micahg: bug fixes aside, couldn't a new package just be backported? [16:40] 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] so... *shrugs* [16:40] though backport are still not automatic right, so apt-get install ecere-sdk would still not install on a fresh Quantal? [16:40] ESphynx: only for features, not bug fixes, -backports isn't a way to work around the SRU process [16:40] guess the debian freeze is messing with them :P [16:40] micahg: But not all bug fixes are SRUs? [16:41] there isn't such a clear bug fixes/features separation in our development stream :P [16:41] yeah, true, if it's not SRU worthy, we'd probably take it in backports, but this is very SRU worthy [16:41] ah ok [16:41] well, damn. [16:41] let me try again. [16:41] 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] or should I be bugging -hardened about that one? [16:42] TheLordOfTime: different, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation [16:42] that's what i thought, wasn't sure :) [16:44] truth is most of the commits are fixes oriented... [16:45] 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] well thanks again micahg. gotta go now [16:48] 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] micahg I'd basically have to do the work over again. [16:50] had I known, I would have focused on the SRU first. [16:50] ESphynx: I thought I told you that weeks ago...(to do a targeted fix for just these issues to Debian) [16:50] It's all about my understanding of the word 'targeted' :) [16:51] FWIW... [16:51] "targetted" basically means highly-specific fixes. [16:51] at least here it does. [16:51] :P [16:51] this was highly specific for me. just not enough :P [16:51] 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] 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] so there are some code changes there as well. [16:52] 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] and some buffer overflow bugs in there... [16:53] cheers. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [19:02] jtaylor: ping [19:02] nxvl: ? [19:03] 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] nxvl: you are better of using the numpy in debian [19:04] 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] it still uses pysupport, ubuntus uses dh_python2 which is not available in lucid [19:04] jtaylor: awesome, thanks! [19:04] which dependencies? [19:04] jtaylor: exactly what you are talking about [19:05] the dh_python2 stuff === glebihan_ is now known as glebihan