micahghi ESphynx, I should be ready in about 30 min or so03:09
ESphynxmicahg: hey... I'm working on this stuff here but sadly not as far along as I would have hoped :|03:12
ESphynxPlanning to be working through all these issues through the night however :P03:13
ESphynxI got pizza & coke set aside.03:13
micahgESphynx: heh, I should be around for the next 3-4 hours if I can be of help03:13
ESphynxgreat :) thanks!03:15
=== dk is now known as Guest28878
ESphynxHmm, now this is quite annoying... I had symlinks in /usr/lib/ec/ , but actual .so.0.44 were still all in /usr/lib/04:50
ESphynxI'm assuming that libec should still be out of there not to conflict with lib elleptical curves, in case 2 versions are ever the same and to avoid overall confusion? :|04:50
micahgESphynx: you might need to change the install path in the Makefile or equivalent04:50
ESphynxOK I mostly took care of that :P05:16
ESphynxHow do I trick people into completing the missing translations for Ecere? :P05:17
ESphynxxnox: going for libecc0 ...05:32
ESphynxmicahg think that should be fine?05:33
micahgESphynx: why not libecere0?05:34
ESphynxmicahgc: that is the runtime library package.05:34
ESphynxmicahg: This is the eC compiler library05:34
micahgah, libecc0 sounds good then05:34
ESphynx(the actual compiler, not a runtime library...)05:34
ESphynxmicahg: question about this breaks/replaces stuff... I don't want to 'break' or 'replace' the elliptical curve library named libec0!05:35
micahgESphynx: that's why it's versioned :)05:35
ESphynxmicahg: yeah but what do the versions mean... do they refer to elliptical curve library or libec?05:35
ESphynxin unstable, libec0 is the elliptical curve; in experimental, libec0 is the eC compiler05:36
ESphynxi.e. http://packages.debian.org/experimental/libec0  vs  http://packages.debian.org/sid/libec005:36
micahgESphynx: look at the versions the eC compiler version is lower, so breaks.replaces would be fine05:37
ESphynxlower because 0.44 vs 2012?05:37
ESphynxi'm very confused with the DPM's example on Replaces/Breaks  Replaces: foo (<< 1.2-3)05:39
ESphynxThe example is For example, if a package foo is split into foo and foo-data starting at version 1.2-3, foo-data would have the fields05:40
ESphynxThis is not the case here, we're talking about completely unrelated packages :|05:40
micahgyes, so the package where the libec0 files move, breaks/replaces on the last version of libec0 that had them05:40
ESphynxso I should not use <<05:40
=== dk is now known as Guest45074
micahgyeah, << is right05:40
micahgerr... <=05:41
ESphynxReplaces: libec0 (>> 0.44.02-1)05:41
ESphynxis it ?05:41
micahgBreaks: (<= 0.44.02-1)05:41
micahgsame with Replaces05:41
ESphynxk. thaks.05:41
micahgor << if you want to use the new version there05:42
micahgbut in this case, I think <= makes more sense05:42
ESphynxI do'nt understand all this << ... that's a left shift operator for me :P but if you say <= works, it's good with me :)05:43
micahg<< is less than, <= is less than or equal to05:44
ESphynxah ok :)05:47
micahgESphynx: see 7.1 : http://www.debian.org/doc/debian-policy/ch-relationships.html05:50
ESphynxI see05:55
ESphynxa case of annoying historical baggage :P05:55
=== dk_ is now known as Guest34602
ESphynxWhat's "debarch_is_wildcard" is not exported by the Dpkg::Arch module  supposed to mean :|06:33
ESphynxSomehow my dh-exec 0.3 on Precise got broken by some processs and I'm struggling to get it working agian :S06:33
micahgno idea06:34
=== foofoofoo is now known as dk
ESphynxWell, look at that! got it working again somehow (though I seriously messed up my package DB :P)06:59
ESphynxI wonder why i'm getting these now: W: libecc0: postinst-has-useless-call-to-ldconfig :S07:47
ESphynxsounds like a case for an override :P07:52
=== zequence_ is now known as zequence
ESphynxmicahg: Should update to the NEWS files be included in that SRU?08:26
ESphynxI'm going through these 219 commits, and I'm thinking... well yes this bug should be fixed for at least 25% of them :|08:34
ESphynxguidance? anyone? :)08:52
=== yofel_ is now known as yofel
micahgESphynx: NEWS file should only be used for major changes in a package16:45
ESphynxmicahg: yeah but since this was the first versions, I was doing updates to the past history of the SDK :P18:11
ESphynxgood morning guys18:22
ESphynxSo, what can I do for these poor souls on Quantal who would like to use Ecere ?18:24
=== zequence_ is now known as zequence
micahgESphynx: not sure what you mean about updates to past history, see http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-news-debian for what the NEWS file is for21:05
micahgESphynx: in the numerous uploads that I've done, I think I've only used a NEWS file entry twice21:07
ESphynxmicahg oh hi =)21:11
ESphynxmicahg: Well NEWS has its own meaning for me in the upstream package...21:11
micahgESphynx: that's fine, you should list changes in upstream stuff in the upstream NEWS file :)21:12
ESphynxmicahg: I made 'corrections' in the past entries of the NEWS file21:12
ESphynxmicahg: I've been talking about the upstream NEWS file the whole time.21:12
micahgah, heh, ok21:12
ESphynxI don't have a separate 'NEWS' file for the package, I thought the 'changelog' handles that21:12
micahgthat's fine for new upstream versions, not for SRUs21:12
ESphynxmicahg: so this SRU... I'm at a loss, my friend21:13
micahgESphynx: well, if there's major breakage with a new upstream version, a package NEWS entry might make sense, but in general, no package NEWS is good NEWS :)21:13
ESphynxI really don't care about the NEWS file21:13
ESphynxmy problem is there are ~220 commits between the current Ubuntu package (0.44.01-1) and the latest (0.44.03-1)21:14
ESphynxmost of which I consider important bug fixes21:14
micahgESphynx: maybe raise the bar to severe then?21:16
ESphynxmicahg: my other argument is that whichever 'patched up' 0.44.01 is going to be less tested/stable than 0.44.03  as it is21:17
ESphynxsince I essentially have to 'redo' the patch for the severe issues21:18
micahgESphynx: that's a classic problem with stable releases, we have backports for stuff that's not SRUable21:19
micahgESphynx: just pick the major stuff that's really broke that can't be worked around21:19
ESphynxIs backport a possibility here? ah but that doesn't happen automatically, is it?21:19
micahgESphynx: sure, it's possible, but we should at least fix the installability issue in quantal21:19
micahgbackport isn't an end run around the SRU process, it's an option to get the latest upstream with all features/fixes21:20
ESphynxSo. 1. installability 2. arm/ppc issues 3.  GCC 4.7 issues21:20
micahgsounds good to me :)21:20
ESphynxlet me give you an example21:20
ESphynx    ecere/gfx/fonts: Fixed wrong kerning when using the same face with different sizes21:20
ESphynxShould that make it or not?21:20
ESphynxthis can result in having the e show over the T in a 'Test' string21:21
micahggcc 4.7 issues shouldn't be fixed in an SRU unless they break the build21:21
ESphynxthey make loading a BMP image crash21:21
micahgah, sounds like a good fix then21:21
ESphynxide/Project: Fixed buffer overflows using DynamicString::concatf -- Should that make it?21:22
micahgit's visually annoying, so, it's your call21:22
ESphynxvisually annoying? what do you mean?21:22
ESphynxah the Font one21:23
micahgT over e21:23
ESphynxit sure is.21:23
ESphynxbut i'm just not up to document 200 bugs in Launchpad21:23
micahgthe buffer overflow might not be exploitable, if it's not, not worth fixing in an SRU21:23
ESphynxhow about buffer overflows?21:23
micahgif it is, probably should go to -security21:24
ESphynxhmm well I don't know if it'd be exploitable or not, I don't consider my SDK very secure in the first place.21:24
ESphynxOk then let me review these issues again, in light of our discussions. I'll be picking a minimal set.21:25
ESphynxbeing of perfectionist nature, that's just so hard on my brain :P21:25
micahgESphynx: I can certainly relate21:26
micahgESphynx: here's the general criteria for SRU if that helps: https://wiki.ubuntu.com/StableReleaseUpdates/#When21:26
micahgwe have backports for the rest :)21:26
micahgbackports are visible by default in software center, but are opt-in21:27
ESphynxoK i'm starting to feel this21:35
ESphynxI've singled out 47 bugs21:54
ESphynxor commits, rather :P21:54
ESphynxI made some wine with the grapes in my backyard ;) threw in some stuff including some 100% cherry juice. i've had some comments that it tastes a bit too much of cherry / red licorice :P   This is the label  http://ecere.com/tmp/labelv8.png =)21:56
ESphynx(Now on to cherry-picking :P)21:57
ESphynxmicahg: Any advice on how to proceed? I made a 'quantal-sru' branch and I'm going to cherry pick each of these 47 commits and verify them one-by-one and make sure the result is good.22:05
ESphynxShould I be 'regrouping' some of these?22:05
micahgdbaa493 eda: Put back include paths to fix Oneiric/amd64 build problems with libffi doesn't make sense22:06
micahgdb43e9b ide/Debugger: Improved support for GDB 6.3 on OS X also22:06
ESphynxmicahg: the first one is about adding -I/usr/include/i686-linux-gnu22:07
ESphynxthe latter is fixes to GDB protocol, and though I did this for OS X it would likely affect a user using GDB 6.3 on Ubuntu as well22:07
micahgwe have 7.422:07
ESphynxI know, but one might decide to use 6.3 :P (for reasons including the fact that GDB is completely and utterly broken these days)22:08
micahgcan you justify the reasoning and risk for all of these?22:08
ESphynxit's also just 'improved' GDB communication22:08
micahgESphynx: we don't care about non-archive stuff in most cases for SRUs22:08
ESphynxthe first has no risk, it just adds an include path (reduces the risk of a build failing) ... besides I'm only going to add it if the build needs it :P22:09
ESphynxthe latter makes the integrated communication more stable22:09
micahgI'm saying for the whole list, I don't need you to tell me the justifications, but the SRU team will want to see them as well as test cases (reproducers, not code) and regression risk22:10
ESphynxyeah, sounds painful :P22:11
micahgright, just focus on what you can justify :)22:12
ESphynxa broken debugger is an annoyance22:13
ESphynxso every bit of progress I make on integrating with GDB is golden :P22:13
micahgsure, but it's not worth SRUing unless you can justify the regression risk22:14
micahgand we've got backports for everything else22:14
ESphynxI don't mean to sound like an ass, but regression risk -- seriously22:15
ESphynxnothing and no one is using this yet :P22:16
ESphynxI can understand regression risk to be critical for packages that used by the whole system... like X11, or the kernel, or even GTK, Qt... but for isolated packages?22:16
micahgSRUs are meant to improve the existing versions in the archive, backports are there to bring the latest and greatest22:17
ESphynxwhich is why I've singled out these 47 critical bug fixes out of the 220 commits22:17
ESphynxbut now are they going to expect me to spend 30 minutes for each of these to come up with a reproducing scenario?22:17
micahgright, well, that's why xnox and I suggested a minimal set22:18
ESphynx51b6684 compiler/libec: Added missing null pointer check   -- This is a potential IDE crash (one could lose his work as a result)22:19
ESphynxShould this make it in?22:19
micahgif it was totally broke in quantal, you could push a new upstream, but AIUI, it's not the case on i38622:19
micahgESphynx: yeah, work loss is a good SRU criteria22:19
ESphynxa lot of these are SIGSEGV fixes22:20
ESphynxtrue, it's not fully broke on i386 :P22:20
micahgScottK: ^^ any suggestions?22:21
ESphynxwell I'll go through them again and may omit some ... that was just a first round.22:21
ESphynxmicahg: let me reiterate that I appreciate your help and especially your moral support in this difficult task :P22:22
ScottKESphynx: We promise no regressions post-release, so the regression concern is a potential issue for all SRUs (more some than others though).  For packages that don't have a micro-release exception approved by the tech board, it's unfortunately necessary to go through a test case for each issue.  It might be possible to have a combined test case that covers multiple bugs.  There's no need to be duplicative about it.23:06
ESphynxScottK: Can a test case be 'steps to reproduce' , or should it be an automated script?23:07
ScottKESphynx: It can be either.23:19
ESphynxScottK: What of a fix for something obviously wrong, but for which I never managed to reproduce the issue on Linux? I'm thinking about: 4750114 compiler/libec/lexer: Solved issue where isatty was called on an eC File object - Hopefully resolves parsing bus errors on OS X23:23
ScottKWhy would you include the fix for Linux then or are you making a bugfix release for multiple OS?23:23
ScottKIf so, there's nothing to verify since there's no issue.23:23
ESphynxScottK: I have newer versions which have the fix... this is still an issue on linux, isatty() expects a FILE * but I'm passing it my own struct... It never caused any problem out of sheer luck.23:24
ScottKIn that case, it's possible, if there's no other way to verify, to do it via code inspection and testing to ensure there's no regression, so mostly describe what you need to do to execute that functionality so it can be tested to still work.23:26
ESphynxIf I've fixed 5 buffer overflows in different locations, should I describe the 5 ways to reproduce each of them?23:28
* ESphynx tremples in pain23:34
ESphynxSomething like e84d924 ide/CodeEditor: Fixed buffer overflow - Large strings such as the credits in the IDE's about.ec caused buffer overflows,   noticed as 'Stack smashing' on Ubuntu Quantal  -- surely deserves an SRU?23:41
ScottKYes and if it's noticed as stack smashing in a build log or something, the absence of the same is sufficient.23:46
ESphynxthat was noticed in the controlling when opening ide/src/about.ec in the IDE23:48

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!