[21:06:56] okay, first bug for today is bug #12248 [21:06:59] Bug https://bugs.maemo.org/12248 camera always turns flash light on, even if set off [21:07:29] cnd [21:08:18] is that problem in old closed nokia camera-ui or new cssu version? [21:08:46] it's valid for new cssu version [21:09:08] though I don't know if it's simply needed for the autofocus [21:09:22] stock camera-ui behaves the same [21:09:26] I guess it's focus related [21:09:58] ah wait the device I tested it on was stable, so I can only say for stock ui [21:10:07] someone with -testing please test [21:10:17] it's only for fist shot, and on both cams [21:10:24] first [21:10:59] known [21:11:09] since....... [21:11:15] is that actually a bug or invalid? [21:11:41] since it seems to stop the light when the autofocus is finished [21:11:43] valid, though incorrexctly stated [21:12:07] can we do something about it? [21:12:16] dunno [21:12:25] in other words is the underlying stuff nokia closed or oss? [21:12:30] prolly not [21:13:12] Pali: any idea? [21:13:17] no idea [21:13:23] I do not know camera code [21:13:32] so I'll ask nicolai, k [21:14:03] --> scoobertron (~tom@93.186.151.132) hat #maemo-ssu betreten [21:14:40] comment: "known issue for stock cam, for fist shot only. WONTFIX" [21:14:56] well if we can fix it I wouldn't mark it wontfix [21:15:01] or rather PRIO?lowest [21:15:15] yup [21:16:07] next in the list is bug #12251 [21:16:09] Bug https://bugs.maemo.org/12251 Upgrades only manually in X Terminal with apt-get code. [21:16:25] that one quite possibly is due to a fucked up system [21:16:35] only hte last 2 attachments are interesting [21:17:00] att: picture3-problems_en - I think problem is not valid [21:17:47] in picture are packages which should be in cssu repo [21:17:57] my thought exactly [21:18:13] I think problem when user must wait until HAM finish apt-get update job [21:18:24] (not apt-get update, but similar) [21:18:28] probably [21:19:23] okay next up is bug #12285 [21:19:24] Bug https://bugs.maemo.org/12285 Modest does not keep emails on server even if option to do so is set [21:20:09] wireshark [21:20:33] no idea, I do not use POP [21:20:43] I'll investigate then [21:21:44] IMAP/POP?? [21:21:51] I think POP [21:21:58] DocScrutinizer51: pop [21:22:39] I'll check the bug, next up is bug #12300 [21:22:41] Bug https://bugs.maemo.org/12300 Clock crashes after choosing Music for Alarm [21:23:41] invalid neither a package in cssu nor open source so we could look into it [21:23:52] I think it is closed [21:24:12] MAFW? [21:24:30] DocScrutinizer51: nah, the alarm clock operates outside mafw [21:24:53] though is that an INVALID or a WONTFIX? [21:25:17] CND [21:25:38] cnd means? [21:25:44] I think that somebody rewritten clock app [21:25:53] <-- NIN101 (~NIN@p5DD2896C.dip0.t-ipconnect.de) hat das Netzwerk verlassen (Quit: NIN101) [21:26:08] can not duplicate [21:26:11] Pali: yes there is a rewrite somewhere on tmo [21:26:49] and can be this problem (if exists too) fixed in that rewritten app? [21:27:01] in the rewritten app for sure [21:27:41] though what do we do with the bug at hand? move the component to the stock clock and abandon it? keep it? close it as invalid? [21:27:53] freemangordon, do you know state of clock app which is rewritten? [21:28:08] CND [21:28:35] if that open source clone will be part of cssu in future, bug can be marked as in progress/waiting [21:28:37] never seen that problem [21:29:03] It cdan get marked FUD [21:30:06] yeah worksforme I guess, can't reproduce it either [21:30:21] needinfo. What's the clock version, what's the 'muaic' file? [21:30:43] or CND/WFM [21:30:44] hm that actually makes more sense [21:31:25] DocScrutinizer51: there is no cnd status for bugs, we can only mark stuff as fixed/invalid/wfm/wontfix/duplicate [21:31:28] NB I can't check the tickets here [21:31:54] will post a comment for more ifno [21:31:58] wfm == cnd [21:32:24] kinda [21:32:40] wfm might mean 'we fixed it' [21:32:45] btw pali what did we decide about the silly ham 8% check? [21:33:01] remove that 8% check - it is stupid [21:33:13] indeed [21:33:27] do we have a commmit on gitorious for that already? [21:33:57] Pali, AFAIK it needs some more work [21:34:12] merlin1991, in my git repo: https://gitorious.org/~pali/community-ssu/pali-hildon-application-manager/commit/4226aeb868a0fa250f92325d6819c62ef9bde6f4 [21:34:17] but it is UNTESTED [21:35:08] --> arcean (arcean@2002:2e4c:b1e7::2e4c:b1e7) hat #maemo-ssu betreten [21:35:13] freemangordon, ok [21:35:22] hi everyone [21:35:24] hey [21:35:27] hi [21:37:01] okay next bug: #12320 [21:37:07] bug #12320 [21:37:09] Bug https://bugs.maemo.org/12320 Change default value of mov-mode for HildonPannableArea to HILDON_MOVEMENT_MODE_BOTH to allow horizontal scrolling by default [21:37:09] silly bot [21:38:09] confirmed [21:38:16] Imo we can't do that because existing applications might depend on the HILDON_MOVEMENT_MODE_VERTICAL default [21:38:38] same problem in modest with slovak localization (which has longer strings) [21:38:42] I mean yes there are billions of apps that should be pannable horizontally but that is app specific [21:38:57] yup [21:39:06] I don't think that should be fixed on the hildon framework level [21:39:07] I think it's fixed for hildon details dialog used by pdf viewer or file manager [21:39:37] afaik open dialog is open source [21:39:57] comapp (or similar name) package [21:40:09] we could fix it by setting an ENV [21:40:54] see bug 5424 [21:40:55] Bug https://bugs.maemo.org/5424 Unable to scroll horizontally in File manager's details dialog when the file name is too "long" [21:41:04] https://gitorious.org/community-ssu/libhildonfm/commit/acaf5d13a1fd79e1bb5a3c4ebd1f644ab64ed228 [21:41:24] yeah that one is in stable and - testing [21:41:31] maybe asking andre if he know exact reason why patch was not upstreamed [21:41:45] but looking at the bugreport itself [21:41:49] HildonVertPannable=true filemanager [21:42:05] it makes no sense to have pannable areas in general pannable [21:42:23] there's a reason why the pan only vertically by default [21:43:02] that's why you check $ENV for that [21:44:16] imo bug #12320 is invalid since we don't want to change that on framework level [21:44:17] Bug https://bugs.maemo.org/12320 Change default value of mov-mode for HildonPannableArea to HILDON_MOVEMENT_MODE_BOTH to allow horizontal scrolling by default [21:44:30] we fixed the filemanager, but we don't want to possibly break apps [21:45:54] merlin1991: we can use getenv() [21:46:17] what do you want todo with getenv? and at what level? [21:46:41] so it will only 'break' apps where you set HildonPanMode=both in the app's environment [21:47:20] but apps who want the hildonpanmode both should do so in their code [21:47:38] *sigh* [21:47:44] DocScrutinizer51, thats a hack and we have only filemanager ad rss reader as examples in bug report. Filemanager is fixed and RSS reader is OSS AFAIK [21:48:02] problem also in modest [21:48:06] :nod: [21:48:06] I can post screen [21:48:15] nm [21:48:19] (modest in slovak lang) [21:48:22] afk for 10in [21:48:35] modest reflows the text AFAIK [21:48:44] freemangordon: not in all widgets [21:48:45] but it can be fixed in modest [21:49:11] :nod:, it is not a framework bug [21:49:22] freemangordon: that was my understanding [21:49:39] which would render the bug itself invalid but bugs against each app valid [21:49:47] agree [21:49:48] Pali: what do you think? [21:50:20] report bugs to each app [21:50:27] global fix not possible [21:50:37] this only changes te bug to an enhancement [21:51:14] DocScrutinizer51, we have no clue which applications will be affected an how [21:51:18] of course possible [21:51:43] freemangordon: doc suggests that we at hildon level check for env [21:52:03] so you can start single apps with that env in order to 'fix' them [21:52:17] yeah, I saw, but that is a hack [21:52:24] debug=66 acmeapp [21:53:01] yeah, unix is a hack [21:53:12] and I'm proud of that [21:53:27] I meant hack as a coding practice [21:53:39] http://atrey.karlin.mff.cuni.cz/~pali/screenshot-modest.png [21:53:57] well anyway, the bug in question is invalid, it could be refiled in form of docs suggestion as an enhancement [21:54:09] Pali, ah I have the same problem with some applets in Settings [21:54:19] Pali: that's actually true for the german translation also [21:54:24] Pali, but there is a horizontal scrollbar?!? [21:54:33] freemangordon, which is not working [21:54:34] not working! [21:54:34] freemangordon: bar is there but you can't scroll [21:55:07] also bug can be fixed by decreasing space between name and value [21:55:47] ok. well, it looks UGLY anyway, maybe someone should play a little with translations [21:55:51] AAAAH! better [21:56:04] do you know if it is possible to enable scrollbar in app? [21:56:11] it is [21:56:42] ah wait you mean enable the scrollbar so you can scroll with it? [21:56:58] should be [21:57:05] that I don't know [21:57:27] adding some function for that can be also fix [21:57:46] GtkScrolledWindow instead of HildonPannableArea? [21:58:15] give me a minute to look through the proposed patch [21:58:38] in the meantime bug #12445 [21:58:39] Bug https://bugs.maemo.org/12445 hildon-status-menu displays only 2 icons in portrait [21:58:57] arcean: we do have the patched hildon-status-menu in testing already? [21:59:05] yes [21:59:12] fixed in the latest release [21:59:23] well, the patch is for hildonfm, forget about it [21:59:51] hm some ideas to get a few icons? [21:59:56] -*- merlin1991 wants to check on -stable [22:00:19] Pali,"g_object_set(priv->scroll, "mov-mode", HILDON_MOVEMENT_MODE_BOTH, NULL);". That is how scrollbar is enabled on application level [22:00:31] 12445 sounds like a statement, not like a bug [22:01:03] 12445 is actually fixed in testing [22:01:12] yep [22:01:23] so, please don't bring that to us ;-D [22:01:29] next [22:01:31] freemangordon, api is here: http://maemo.org/api_refs/5.0/5.0-final/hildon/HildonPannableArea.html [22:02:03] next up, bug #12454 [22:02:04] Bug https://bugs.maemo.org/12454 utilities infocmp, tic, tput etc not installed though busybox provides ncurses-bin [22:02:04] I think we can add some public HildonPannableArea function which call that g_object_set on priv [22:02:06] so it is up to app developer to change movement mode [22:02:30] CBA to think about messybox ;-P [22:03:09] Pali, that code is from here https://bugs.maemo.org/attachment.cgi?id=1420 [22:03:37] 12454 comment: "closing as INVALID, it's messybox, not CSSU" [22:04:06] freemangordon, ok - so this code can be added to modest (and maybe other buggy applications) [22:04:14] yep [22:04:28] WTF CSSU isn't responsible to provide a convenient set of app install presets for user [22:05:13] terse: "tic, tput etc not installed" SO WHAT? install it! KTNXBY [22:05:22] DocScrutinizer51: read other comments [22:05:29] the bugreport is badly worded [22:05:50] fu you tabcompletion meant to write Doc_No_ACTA_zer [22:06:00] The infocmp command is in the ncurses-bin package. On the N900, this package is [22:06:00] not installed, but the busybox package declares that it provides ncurses-bin [22:06:17] so what? [22:06:26] are we responsible for messybox? [22:06:33] oooh we are [22:06:35] :-S [22:06:39] it's MP [22:06:55] isn't it? [22:07:36] -*- Doc_No_ACTA_zer shudders about messybox [22:07:38] well we are not directly responsible for messybox, but we could get the messybox from stock and remove the *provides ncurses-bin* from it's control file [22:08:05] basically providing the same messybox that doesn't claim anymore that it's awesome [22:08:14] agree [22:08:14] -*- Doc_No_ACTA_zer opens a bug against CSSU: "replace messybox by a decent fully usable shell" [22:08:39] or upgrade messybox :D [22:08:45] Doc_No_ACTA_zer, that is enhancement request :p [22:08:48] WWWWAAAAAAAAAAAAAAHH!!! [22:08:56] freemangordon: indeed [22:09:09] though, arguably messybox is one huge fat bug [22:09:10] though it's not that easy [22:09:27] messybox provides 50% if what ususally should be in ncurses-bin [22:09:44] I think the best thing here would be not to invest time and instead to point towards busybox-power [22:09:56] is it stable? [22:10:01] s/in ncurses-bin/in a decent shell/ [22:10:02] which has upgraded messybox and stuff [22:10:16] freemangordon: I use it on all my devices and never ran into a problem [22:10:45] I use bash3 and never ran into any problem [22:10:49] ;-P [22:10:56] busybox-power replace /bin/busybox? [22:11:30] and I **HATE** this reverse polish notation [22:12:19] cookie-sweet, beer-cold, Flop-idiotic, kernel-power [22:12:26] busybox shell has big problem with utf8 input chars [22:12:44] Pali: it does replace /bin/busybox [22:12:59] I'd rather not reproduce what busybox power does, so closing as wontfix ? [22:13:31] I dman get scared when somebody tells me about messybox power, the secret power of messybox [22:13:36] merlin1991, wouldn't it be better to confirm it and assign low priority? [22:13:55] or that [22:14:13] I'm not sure if I get scared about that secret dark power, or the guy that tells me about it ;-P [22:14:22] as maybe there will be a way to change control file in such a way there will be no more conflick [22:14:42] okay will do that [22:14:46] clone to gitorious and change control file [22:15:14] kernel-power sounds like kernkraft whic means nuclear power in German [22:15:20] Pali: the problem is it does provide a part the nurses commands [22:15:23] like reset [22:15:36] ah [22:15:55] something wit alternatives? [22:16:04] so proper fix will be to upgrade busybox [22:16:10] yep [22:16:27] confirmed and low priority [22:16:28] proper fix would be to enable everything in ncurses in messybox and ship it that way [22:16:37] k confimred and low prio [22:16:39] next up is bug #12474 [22:16:40] Bug https://bugs.maemo.org/12474 With Desktop locked to landscape and phone to portrait, phone launches in landscape mode [22:17:20] really bug? [22:17:25] kernel-power, DMAN. Shoot the guy who thought that name was better than e.g. kernel+ or kernel-improved or powerkernel [22:17:35] well, I think we should agree on WTF lock means once and fo all. And bahave accordingly. [22:18:39] I think against the current implementation the bug is invalid [22:18:50] I think that if system (hildon) is set to landscape only, then every app will be landscape [22:19:21] I think that the bug is against the rationale behind current implementation [22:20:04] but current implementation seems logical to me [22:20:07] I think any bugs agains the orientation lock are invalid since the lock iself is a clusterfuck [22:20:38] and I think there ought to be a requirement spec that clearly defines what orientation lock means and how it's supposed to work [22:20:54] merlin1991: ++ [22:21:17] -*- merlin1991 proposes to leave that bug and any other lock related bugs alone untill we havae a clearly defined spec what we want todo with a lock [22:21:30] YES! [22:21:34] :nod: [22:21:34] ok [22:21:57] next up: bug #12475 [22:21:58] Bug https://bugs.maemo.org/12475 Oversized Phone UI - Incoming Call (Portuguese language) [22:22:14] wontfix - phone ui is closed [22:22:29] reassign to txl8n [22:22:48] ah wait, it's actually about the lock again [22:23:00] it's the issue you get when the landscape lock is on [22:23:07] MEH, next [22:23:12] yeah [22:23:14] next: bug #12478 [22:23:28] povbot sleeping? [22:23:32] Bug https://bugs.maemo.org/12478 SIP support broken after installation of CSSU (rtcom-accounts-voip-support removed?) [22:23:33] merlin1991: Error: "sleeping?" is not a valid command. [22:23:41] ;-P [22:24:02] confirm and die in hell I guess [22:24:12] indeed [22:24:26] we had the topic err yesterday? [22:24:42] need a apt guru [22:24:46] I mean we can depend on rtcom-accounts-voip-support in the metapacke in order to have ham keep it installed [22:24:57] which is a valid workaround [22:24:59] all for that [22:25:15] and since that package is such a widespread missing piece I'd actually suggest doing that [22:25:23] yes [22:25:25] does mp-fremantle-pr depend on it? [22:25:35] yes [22:25:36] that'S the question XD [22:25:57] maybe it does in PR1.3 and beyond [22:26:11] but not in MP PR1.2 [22:26:26] hm actually it doesn't [22:26:35] can you check if all packages which mp-fremantle-pr depend on is in CSSU metapackage? [22:26:37] so the friggin rtcom-sip gets auto-removed when you upgraded instead of flashed [22:26:47] or vice versa [22:26:54] Pali: we don't depend on all [22:26:58] we only depend on our pacakges [22:27:12] ok [22:27:14] merlin1991, but maybe we should [22:27:15] because the installer marks all mp packages as manually installed [22:27:36] and suggests autoremove on each and every install you do [22:27:46] (apt-get that is) [22:28:11] we'll just depend on it [22:28:14] HAM is not using apt-get [22:28:22] but sth similar [22:28:33] stupid apt-worker [22:28:47] --> m0use (~m0use@178.121.25.89) hat #maemo-ssu betreten [22:28:50] anyway next bug #12494 [22:28:51] Bug https://bugs.maemo.org/12494 Modest crashes couple of times a day due to internal application error [22:29:03] MEH, obsolete [22:29:04] needsinfo [22:29:17] that is prior the thumb fix, I'd just mark it as fixed [22:29:28] yep [22:29:42] note: "reopen if problem persists" [22:30:00] --> RST38x (~rst38x@NAT-81-25-53-73.ultranet.ru) hat #maemo-ssu betreten [22:30:02] yeah [22:30:17] note: "fixed in verX.Y reopen if problem persists" [22:30:21] next up bug #12500 [22:30:23] Bug https://bugs.maemo.org/12500 Some SD cards are not properly supported [22:30:35] kernel [22:30:37] next [22:30:39] yeah [22:30:49] but the bug is valid [22:31:01] reassign kernel [22:31:07] <-- RST38x (~rst38x@NAT-81-25-53-73.ultranet.ru) hat das Netzwerk verlassen (Remote host closed the connection) [22:31:20] I guess we jsut leave it untill we have a kernel in cssu [22:31:27] agree [22:31:30] which probably will never happen [22:31:36] why? [22:31:43] or until my cows play bowling [22:32:00] merlin1991, why do you think it will never happen? [22:32:01] reasasign kernel, next [22:32:07] freemangordon: because we have to find a sane way to make sure we're not replacing any user flashed kernel [22:32:30] and that is a showstopper? [22:32:35] yes [22:32:41] next bug #12516 [22:32:43] Bug https://bugs.maemo.org/12516 Error Message camera-ui: "Not enough memory to save photo" [22:32:46] on a conceptual level [22:32:47] --> _rd_ (~rd@p57B490AB.dip0.t-ipconnect.de) hat #maemo-ssu betreten [22:33:01] I can create tool in postinst or wrapper around fiasco-* to show message box about flashing yes/no question [22:33:22] no way [22:33:55] which could be shown only if current kernel != omap1 [22:33:56] can we read the flash where the kernel is from userspace? [22:33:58] I wanna kick out nicocam, so don't hope for me cheering about getting *kernel* into CSSU [22:34:29] merlin1991: sure [22:34:35] but hey! [22:34:46] then we could md5sum over the flashed kernel and compare to stock kernel singatures [22:34:46] Doc_No_ACTA_zer, there are several bugs in omap1, what is the problem with better kernel? [22:35:02] freemangordon: wrapping fiasco-* will show message for all kernels [22:35:11] CSSU is supposed to work with stock kernel, so no way you convince me CSSU *needs* powerkernel [22:35:17] uname? [22:35:53] CSUU is supposed to not depend on kernel AIUI. [22:36:01] 12516 I thought is fixed? [22:36:06] guys all nice and shiny, but please another time (I can arrange a date for all the topics we have to discuss) [22:36:12] also not applicable to S? [22:36:25] not applicable to S doesn't cound :D [22:36:28] merlin1991, let me check on gitorious [22:36:55] original reporter didn't respond anymore [22:37:05] and the bug that was in camera-ui got fixed [22:37:07] so fixed? [22:37:11] but I think it is still not fixed [22:37:24] I'm not sure too [22:37:27] so danm fix it! [22:37:42] the problem is that if you have a /scratchbox dir $INTERNAL_MMC_MOUNTPOINT is not set [22:37:47] the fix is around since... weeks? moths? [22:37:49] it was some ENV variable missing [22:38:07] a /scratchbox dir has an influence on some bootup script [22:38:18] merlin1991, is it a valid bug then? [22:38:21] in a way [22:38:40] having a /scratchbox dir is the prefered way to check for scratchbox env in scratchbox [22:39:05] because if you dont have that set, where nikocam is supposed to save the photos? [22:39:20] I guess we can fix that [22:39:30] ok, confirm it then [22:39:34] I'll have to find out in which package the script in question resides [22:39:37] k confirm [22:39:48] better is checking /targets/links/scratchbox.config [22:40:03] it is also in postinst script in kernel package [22:40:27] okay so we have a bug against af-defines.sh [22:40:40] open it [22:40:52] *sigh* could we agree on assigning bugs to a developer that looks into them, rather than discussing each gory detail here at triage time? [22:40:58] please! [22:41:02] :D [22:41:18] next up bug #12526 [22:41:20] Bug https://bugs.maemo.org/12526 Desktop icons management for Landscape to Portrait transition [22:41:51] *burp* [22:41:56] INVALID [22:42:25] or maybe WONTFIX [22:42:32] I'd say wontfix [22:42:54] the bug itself is valid, but we'll never have an algorithm that can sort everything properly [22:42:56] CBA to open a browser to look into the ticket ;-) [22:43:10] yeah, making a complex algorithm for one-time usage does not make sense [22:43:24] wontfix [22:43:26] also next to impossible [22:43:36] <-- m0use (~m0use@178.121.25.89) hat das Netzwerk verlassen (Remote host closed the connection) [22:43:42] next bug #12547 [22:43:44] Bug https://bugs.maemo.org/12547 Changing sim reverts to Nokia's AGPS settings [22:44:06] DUH! [22:44:17] wontfix rtcom closed [22:44:22] ack [22:45:13] comment: "suggest a devel who's bored to write a mini-app to set the AGPS setting on click of an icon" [22:45:24] next bug #12571 [22:45:25] Bug https://bugs.maemo.org/12571 Unable to move zoom while on hildon-desktop [22:45:43] related to bug #12031 [22:45:44] Bug https://bugs.maemo.org/12031 Zoom out (ctrl-shift-f) goes one step too far [22:45:52] freemangordon: did you look into it already? [22:46:15] wasn't zoom meant to die? [22:46:17] yes [22:46:21] merlin1991, no, will try do do it tomorrow [22:46:25] so WONTFIX [22:46:47] comment "will fix itself when zoom dies" [22:47:17] next [22:47:29] bug #12576 [22:47:30]