--- Log for 15.01.112 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 17 days and 15 hours ago 00.01.46 Join Galois [0] (djao@efnet-math.org) 00.02.38 Quit pixelma (Remote host closed the connection) 00.02.49 Join pixelma [0] (quassel@rockbox/staff/pixelma) 00.02.49 Join amiconn [0] (quassel@rockbox/developer/amiconn) 00.04.07 Join Topy44 [0] (~Topy44@f048128059.adsl.alicedsl.de) 00.04.22 Quit Topy (Ping timeout: 240 seconds) 00.18.33 Join robin0800 [0] (~robin0800@149.254.61.216) 00.34.03 Join T44 [0] (~Topy44@f049103179.adsl.alicedsl.de) 00.34.47 Quit T44 (Client Quit) 00.37.02 Quit Topy44 (Ping timeout: 240 seconds) 00.48.37 # [Saint]: you have your nano2g ? 00.48.57 # funman: are you a dev? 00.50.01 # bluebrother: hm that means i broke the build for other manuals? 00.50.19 Join saratoga_ [0] (980329c2@gateway/web/freenode/ip.152.3.41.194) 00.50.52 # ah i see it was fixed 00.51.04 # Mir: yes (you can /whois people to see that) 00.51.15 # :) 00.51.44 # i didnt add a check for the remote because there was no remote image for the zip 00.52.24 # whats the status of the cabbie port to the Zip? 00.52.35 # i did not try it 00.54.39 # [Saint]: i sent a patch for nano2g on the mailing list some days ago, could you test it? 01.00.14 Join captainkwel [0] (~jason@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) 01.03.23 Quit lebellium (Quit: ChatZilla 0.9.88 [Firefox 10.0/20120104111456]) 01.03.29 *** Saving seen data "./dancer.seen" 01.03.42 Quit bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped) 01.17.38 Join domonoky1 [0] (~Domonoky@agsb-5d852f52.pool.mediaWays.net) 01.17.38 Quit domonoky (Read error: Connection reset by peer) 01.25.17 Join bsidhom [0] (~bsidhom@0024a5afeeaf.click-network.com) 01.26.47 # I have not checked on any other devices, but the battery benchmark plugin appears not to work for the Sansa Clip Zip. 01.27.24 # Is it possible to debug the battery bench plugin in a simulator? 01.28.04 # it worked for me last time i tried it 01.28.19 # how recent was your build? 01.28.46 # the first one I tried was from Jan. 9th 01.29.43 # what output does it generate? 01.30.24 # it flashes "Cannot create file!" and terminates 01.32.35 # I get the same behavior on the most recent git version as well 01.35.05 # oh i know what that is 01.35.09 Quit petur (Quit: Leaving) 01.35.26 # FS#12500 01.35.27 # http://www.rockbox.org/tracker/task/12500 3/./ is invalid when not using dircache, so HOME_DIR breaks things (bugs, new) 01.35.32 # Ah, the usual 01.35.45 # That *really* needs to be fixed yesterday 01.38.19 # I would but I doubt anyone would like how I'd do it, so I'll leave it to another less radical programmer 01.38.32 # whats wrong with dreamlayers patch? 01.38.55 # ah the same "disk full" i had when recording .. 01.39.25 # * jhMikeS hates that error since it really just an assumption 01.39.35 Quit factor (Read error: Connection reset by peer) 01.40.04 # jhMikeS: why that first comment? 01.40.16 # saratoga_: I don't know, but I also don't know wht HOME_DIR can't be / 01.40.55 # the problem still happens for me with dircache enabled; is this expected? 01.41.03 # probably 01.42.10 # jhMikeS: to be honest, it's getting to the point where I think radical fixes are fine for this 01.44.42 # funman: which first comment? 01.45.18 # 19:38 < jhMikeS> I would but I doubt anyone would like how I'd do it, so I'll leave it to another less radical programmer 01.45.34 # * jhMikeS shrugs 01.46.40 # it seems like a rabbit hole of sorts 01.46.48 # also dreamlayers' patch looks simple 01.47.32 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 01.47.55 # is it thorough enough? 01.48.08 # HOME_DIR could be just "/" 01.48.16 # what says "//" is invalid? 01.48.37 # funman: // is invalid on hypothetical windows-based RaaA builds 01.49.07 # but I don't see why that would matter here 01.50.09 # what about the windows sim? 01.50.21 # jhMikeS: looks sane to me 01.50.34 # saratoga_: the windows sim has the simdisk path prepended 01.50.42 Quit perrikwp (Ping timeout: 260 seconds) 01.51.04 # And as far as I know, // is fine on windows if it's not at the start 01.51.18 # what tries to access "//" 01.51.22 # http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#file_and_directory_names says "/" is forbidden, period 01.51.44 # funman: in a file, not in a path 01.52.17 # jhMikeS: various code does does things like concatenating HOME_DIR and "/something" 01.53.46 # maybe it shouldn't? 01.54.03 # Fixing that is no fun 01.54.20 # And seriously, it's not actually a problem 01.55.23 # technically, any number of "/" in a row should be collapsed to "/" except in special circumstances 01.56.46 Join factor [0] (~factor@74.197.205.204) 01.56.58 Quit domonoky1 (Read error: Connection reset by peer) 02.03.47 # OK, well thank you for the temporary workaround 02.03.58 Quit bsidhom (Quit: leaving) 02.11.29 Quit rasher (Quit: snagra[SF]_) 02.11.44 Join rasher [0] (~rasher@rockbox/developer/rasher) 02.18.02 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 02.18.39 Quit KiwiCam (Read error: Connection refused) 02.22.24 Join KiwiCam [0] (~dontlook@dontlookoverhere.tilaa.nl) 02.29.43 # Commit by 03amaury.pouly (8cadb58): fuzeplus: fix lcd-target.h (LCD_FRAMEBUF_ADDR must point to lcd_framebuffer and not FRAME) 02.29.44 # Commit by 03amaury.pouly (35ba39e): imx233: add DCP driver (only memcpy implemented), move channel arbiter to kernel-imx233 02.29.45 # Commit by 03metaphysiciendouteux (7f26a10): fuzeplus: update plugins keymaps (FS#12405) 02.35.28 # <[Saint]> That nick sure is a mouthful. 02.39.21 Quit robin0800 (Ping timeout: 252 seconds) 02.39.39 Quit Thra11 (Ping timeout: 252 seconds) 02.45.46 Join robin0800 [0] (~robin0800@149.254.56.219) 02.46.13 # i just noticed some commits don't have the gerrit change id 02.46.35 # should we just ignore this (not sure what is its purpose anyway) or enforce it on git server if it's really needed? 02.46.49 Quit [Saint] (Quit: I know its a sin to kiss and swallow.) 02.47.09 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 02.47.33 # for example my manual commit and the subsequent commit by domonoky 02.48.04 # 5ef27368f1bcbe31fb27072983d7a29df8de6845 etc .. it's quite inconsistent 02.48.08 # Torne: ^ 02.48.47 # ok cia gets names from the email, it should use real names probably 02.49.26 # [Saint]: ping nano2g http://www.rockbox.org/mail/archive/rockbox-dev-archive-2012-01/0024.shtml 02.56.09 Quit beslayed (Remote host closed the connection) 02.57.18 Join beslayed [0] (~user@99.52.84.57) 03.00.20 Quit KiwiCam (Ping timeout: 248 seconds) 03.02.31 Quit robin0800 (Ping timeout: 244 seconds) 03.03.32 *** Saving seen data "./dancer.seen" 03.06.48 Quit beslayed (Remote host closed the connection) 03.07.34 Quit pamaury (Remote host closed the connection) 03.07.40 Join robin0800 [0] (~robin0800@genkt-051-219.t-mobile.co.uk) 03.10.02 Quit n1s (Ping timeout: 240 seconds) 03.19.11 Join KiwiCam [0] (~dontlook@dontlookoverhere.tilaa.nl) 03.27.26 Join beslayed [0] (~user@99.52.84.57) 03.29.48 Quit robin0800 (Ping timeout: 255 seconds) 03.32.42 Quit jhMikeS (Ping timeout: 240 seconds) 03.34.11 Join jhMikeS [0] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) 03.34.11 Quit jhMikeS (Changing host) 03.34.11 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 03.40.08 Quit Amqui (Ping timeout: 252 seconds) 03.41.13 Join FrenchVerbs [0] (~chatzilla@c-75-72-62-238.hsd1.mn.comcast.net) 03.47.58 # Hi everyone, I had a question I thought you might be able to help with. Is there a way I can get a certain font in a larger size? I'm looking for Artwiz-Snap in a 12 or 13 point. How would I get that? 03.49.08 Join robin0800 [0] (~robin0800@149.254.58.220) 03.49.10 # <[Saint]> You'd need to generate it yourself. 03.49.45 # <[Saint]> The font .bdf and convbdf are in the sources. 03.49.45 # How would I go about that? 03.50.01 # What is involved in editing them? 03.50.35 # <[Saint]> Checking out the source tree in whole or in part, and re-converting the font. 03.51.13 # Sorry, I'm sort of a noob. What is that in layman's terms? 03.51.48 # <[Saint]> I'm not sure how much more I can dumb it down sorry. 03.52.43 # Well, what do you mean by checking out the source tree, isn't that a little pedantic for just resizing a font? 03.53.16 # <[Saint]> You need at least artwiz-snap.bdf and convbdf, and an environment capable of running convbdf. 03.54.02 # <[Saint]> The wiki details checking out the source, and setting up a development environment. 03.54.16 # Okay, I'll check it out. Thanks! 03.54.21 Quit FrenchVerbs (Quit: ChatZilla 0.9.88 [Firefox 12.0a1/20120114031054]) 04.02.27 Quit KiwiCam (Ping timeout: 248 seconds) 04.05.25 Quit pixelma (Disconnected by services) 04.05.25 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.05.34 Quit amiconn (Disconnected by services) 04.05.35 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.05.45 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.05.57 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.08.32 Quit TheSeven (Disconnected by services) 04.08.49 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 04.12.38 Join Strife89 [0] (~Strife89@168.16.236.47) 04.14.31 Join KiwiCam [0] (~dontlook@dontlookoverhere.tilaa.nl) 04.17.58 Join JdGord [0] (~AndChat@122.110.193.250) 04.28.15 Quit robin0800 (Ping timeout: 240 seconds) 04.28.51 Nick Jack87|Away is now known as Jack87 (Jack87@nasadmin/admin/jack87) 04.34.45 Quit bluebrother (Disconnected by services) 04.34.46 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 04.36.55 Quit fs-bluebot (Ping timeout: 240 seconds) 04.38.30 Join fs-bluebot [0] (~fs-bluebo@g224236078.adsl.alicedsl.de) 04.41.56 Join robin0800 [0] (~robin0800@genkt-058-220.t-mobile.co.uk) 04.59.32 Join dys` [0] (~andreas@krlh-5f71d151.pool.mediaWays.net) 05.01.13 Quit dys (Ping timeout: 252 seconds) 05.03.34 *** Saving seen data "./dancer.seen" 05.13.30 Join Rob2223 [0] (~Miranda@p5B0244CF.dip.t-dialin.net) 05.17.10 Quit Rob2222 (Ping timeout: 260 seconds) 05.23.26 Quit DerPapst (Quit: Leaving.) 05.32.54 # Commit by 03boris.gjenero (12da352): Fix FS#12391 - PP502x cpucache_invalidate() causes memory corruption 05.40.03 Quit [Saint] (Remote host closed the connection) 05.40.51 Quit anewuser_ (Read error: Connection reset by peer) 05.41.59 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 05.45.01 Join dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers) 05.51.13 Quit Strife89 (Quit: Zoom) 05.54.21 # what's with showing sandbox commits in IRC? 05.54.48 Join Amqui [0] (Amqui@CPE90e6baf03fc0-CM001947575820.cpe.net.cable.rogers.com) 05.56.21 # I guess it can't be due to a misconfiguration on my end? 06.07.35 Quit [Saint] (Remote host closed the connection) 06.11.42 # I guess sandbox has a cia post-commit hook, and it shouldn't. I don't think there's anything I can do about that; it must be on the git server. 06.25.44 Quit robin0800 (Ping timeout: 252 seconds) 06.34.32 Join jdgord_ [0] (~AndChat@122.110.193.250) 06.34.35 Quit JdGord (Read error: Connection reset by peer) 06.43.33 Part dreamlayers 06.44.43 Join Keripo [0] (~Keripo@eng200.wireless-resnet.upenn.edu) 06.48.13 Join robin0800 [0] (~robin0800@genkt-051-220.t-mobile.co.uk) 07.03.35 *** Saving seen data "./dancer.seen" 07.10.16 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 07.29.41 Quit robin0800 (Quit: Leaving) 07.51.35 Join Bruice [0] (~6ce1e3ed@www.haxx.se) 07.51.43 Quit Bruice (Client Quit) 07.57.02 Nick Jack87 is now known as Jack87|Away (Jack87@nasadmin/admin/jack87) 07.58.41 Quit Amqui (Ping timeout: 248 seconds) 08.06.09 Nick Jack87|Away is now known as Jack87 (Jack87@nasadmin/admin/jack87) 08.45.12 Join nosa [0] (~m00k@adsl-74-235-42-68.clt.bellsouth.net) 08.48.20 Quit nosa-j (Ping timeout: 260 seconds) 08.48.21 Nick nosa is now known as nosa-j (~m00k@adsl-74-235-42-68.clt.bellsouth.net) 09.03.36 *** Saving seen data "./dancer.seen" 09.11.13 Quit evilnick (Ping timeout: 248 seconds) 09.19.46 Quit jdgord_ (Ping timeout: 252 seconds) 09.34.00 # funman: yes. 09.34.25 # or more exactly, the existing manuals would build but have an error shown because the image file is missing (which is wrong) 09.37.06 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.59.48 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 10.02.45 Quit perrikwp_ (Ping timeout: 248 seconds) 10.09.42 Join chkktri_ [0] (~user@unaffiliated/chkktri) 10.31.43 Quit captainkwel (Ping timeout: 240 seconds) 10.46.05 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 10.46.05 Quit pamaury (Changing host) 10.46.05 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.48.02 Join y4n [0] (y4n@unaffiliated/y4ndexx) 10.52.47 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 10.57.03 # pamaury: 8cadb58 is strange 10.57.35 # I don't think that's right either 10.58.37 # kugel: why ? The fuze+ uses a double buffering scheme, lcd_framebuffer is the buffer and FRAME is the copy that is used for dma 10.59.51 # yes 11.00.00 # lcd-memframe copies to that back buffer 11.00.50 # it's basically a memcpy, where src is lcd_framebuffer and dest the double-buffer for the lcd 11.01.39 # see http://git.rockbox.org/?p=rockbox.git;a=blob;f=firmware/drivers/lcd-memframe.c;h=dd878876bf52f70a46d33f15575b6775b8fb85f1;hb=8cadb58#l69 11.03.39 *** Saving seen data "./dancer.seen" 11.04.27 # that makes no sense, mcd_bit_yuv takes a planar yuv representation as input, so src can't be lcd_framebuffer. 11.04.27 # lcd-memframe.c uses LCD_FRAMEBUF_ADDR() for src 11.04.39 # err, dest 11.04.43 Quit liar (Ping timeout: 245 seconds) 11.05.09 # the fuze+ uses a special implementation for lcd_update_rect 11.05.22 # i saw that 11.06.32 # anyway, LCD_FRAMEBUF_ADDR() is the dest buffer, i.e. what you do dma from 11.08.53 # then that's stupid, that's destroy the use of having two buffers 11.09.00 # *that destroys 11.09.52 # pamaury: no why? 11.10.45 # because the fuze+ uses FRAME for the dma but does not wait for completion, it's a background refresh. If you copy to the buffer being dma'ed, your output will be crap 11.10.50 # well yes, it's converting yuv directly to the back buffer without an intermediate copy in lcd_framebuffer 11.11.07 # but that's the intention, to speed up mpegplayer 11.11.39 # I don't see the point, the screen is *slow* 11.11.46 # pamaury: that's the case for all lcd-memframe targets 11.12.40 # ask jhMikeS for the details, but it's intended that yuv doesnt go to lcd_framebuffer 11.13.02 # he did that lcd-memframe work btw (I saw you didn't remember) 11.14.01 # if you do yuv to lcd_framebuffer, then you need an lcd_update() afterwards no? does mpegplayer even call that? 11.14.21 # ok then tell me: how the hell would playing a YUV work with LCD_FRAMEBUF_ADDR=FRAME ? If I just do lcd_blit_yuv, it won't suffice, I need to lcd_update_rect. But lcd_update_rect copies from lcd_framebuffer so it will overwrite the content of the screen 11.15.02 # * pamaury thinks lcd_blit_yuv has a stupid semantics 11.15.19 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 11.16.10 # you don't normally mix them, except in the overlay in mpegplayer (where the updates are controlled) (?) 11.17.00 # the fuze+ needs to send commands to update the screen, the memframe implementation assumes this is not the case 11.17.07 Join mortalis [0] (~mortalis@77.108.98.177) 11.18.03 # yea it assumes it updates in the background without commands 11.18.30 # seems like I will need to define my own "optimized" version of it x-( 11.18.36 # lcd_blit_*() copies directly to the lcd, lcd_update_rect() copies from the framebuffer. You can mix them, but the areas shouldn't overlap, otherwise the last write "wins" 11.18.38 # if you need commands you can control when updates happen, and then you don't need lcd-memframe, I'd say 11.19.49 # having a memframe is useful: you have one buffer for the software and one for the hardware, otherwise you need to wait for refresh to complete all the time 11.20.28 # There's an exception when using the greylib - in this case you *must not* call other functions writing directly to the lcd while the overlay is running, but there's a replacement for lcd_update_rect() in the greylib api which can be used instead 11.21.09 # For memframe implementations this means you need two buffers 11.21.18 # pamaury: I guess you can continue this way. It's just the commit is strange because it uses lcd-memframe in a non-intended way 11.21.41 # * amiconn considers memframe implementations a "last resort solution" for when we don't know how to control the lcd controller directly 11.22.46 # you are right on one point: the commit doesn't solve the issue, I will need to rewrite lcd_blit_yuv 11.24.43 # On another matter, is there an eta for bringing the build system back up, i.e. finishing the git transition server side? 11.25.25 # * amiconn doesn't like the number of commits which went in without being build checked 11.27.09 # I admit this is a problem but refraining from commiting is not a solution either :) 11.27.37 # * [Saint] kinda assumed commits would halt until the build system is back online. 11.27.51 # <[Saint]> J seem to remember this being discussed. 11.27.57 # <[Saint]> *I seem 11.28.17 # That's why I'm asking for an eta, not for holding back commits (although you probably won't see a commit from me for a while, I first have to figure out this git ****) 11.28.54 # I don't remember this beeing discussed. 11.29.43 Quit chkktri_ (Ping timeout: 245 seconds) 11.30.08 # <[Saint]> I think I do, briefly. But I don't think anyone thought it would take so long 11.32.49 # Iirc roolku asked for a script, but if it can be done manually now I'd rather do it manually on a few clients and live with the fact that builds will take a bit longer until the script for roolku's "power farm" is ready instead of having no working build system at all 11.33.49 # a "bit longer"? :D 11.33.57 # back to the bad old days of 45min build rounds 11.34.05 Quit [Saint] (Read error: Connection reset by peer) 11.34.20 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 11.34.32 # I'd expect more like 20 minutes. Still better than nothing 11.35.32 Join lovasoa [0] (~olojkine@2a01:e35:8a2e:8080:e2b9:a5ff:fe5b:ca7b) 11.40.04 # gevaerts: what were the conclusions from battery benches on m:robe 500? 11.45.23 Join stoffel [0] (~quassel@pD9E422D7.dip.t-dialin.net) 11.55.04 Join Topy44 [0] (~Topy44@f049103179.adsl.alicedsl.de) 11.55.39 # funman: the change id is to identify uploads to gerrit that are subsequent versions of the same change. if people don't have the hook installed it will behave brokenly if they upload anything for review. 11.56.26 # funman: it's not needed for things you push directly, but there's no way for the hook to know whether you are going to push directly or not 11.57.09 # funman: there is a checkbox to require it, thoguh, so i dunno 11.58.03 # can we check-in the hook somehow? 11.58.45 Join TheLemonMan [0] (~LemonBoy@ppp-170-13.26-151.libero.it) 11.58.57 # no. 11.59.04 # git doesn't have any way of doing that 11.59.35 # i think if i require it, it will reject it in allpushes if you don't have it 12.02.44 # i guess that's probably reasonable 12.02.51 # if you've followed the instructions you will have one :p 12.06.51 # * [Saint] wants to say something witty about the likelihood of that happening, though it probably need not be said ;) 12.07.19 # desowin: that my mr500 battery is in a bad shape. I can't get consistent results 12.07.41 # is there a standard git way of referring to another git commit? i.e the equivilant of rXXXX in svn? 12.07.52 # JdGordon: the hash 12.08.02 # traditionally, 7 characters 12.08.15 # though if you are unlucky you may need to include more to be unambiguous 12.08.33 # yeah, but the random looking hash isnt so easy for scripts to figure out its a hash and not a word 12.08.56 # oh. then no. 12.09.22 # it's reasonably likely to have a digit in it 12.09.28 # also, [0-9a-f]{7,} is unlikely to match many words 12.10.11 # you can reasonably assume a minimum of 7; git won't print a shorter hash by default anywhere even if a shorter one is unique 12.10.36 # see git rev-parse --short 7f26a 12.10.38 # or similar :) 12.12.15 # acceded, defaced and effaced are the only matches in my /usr/share/dict/words 12.12.22 # :p 12.12.57 # Yay, my trigger works :) 12.13.55 # thats abot the same false-positives as the current r[0-9]* regex 12.14.05 # most commonly hi with yp-r0 and mr500 :) 12.14.52 # i'd suggest you also include a wordboundary on either side 12.15.00 # which would stop mr500 hitting :p 12.15.31 # i mostly write ypr0 too :) 12.15.58 # \br[1-9][0-9]*\b 12.16.06 # is a much better regex for svn revision numbers 12.16.13 # and won't match either of those players :0 12.16.20 # tell Zagor :p 12.16.28 # so yeah, \b[0-9a-f]{7,}\b for git SHAs 12.16.51 # r0 and r1 in asm instructions were also a "funny" false-positive 12.17.06 # well mine will still match r1, but hey 12.17.22 # you could probably require three digits at this point without losing anything interesting :p 12.17.57 # Torne: rXXXX regexes became irrelevant :) 12.18.02 # stop talking about them :P 12.18.19 # (even the other project where I used them for switched to git recently) 12.19.20 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 12.19.51 # would have been cool if the build system was also prepared beforehand but whatever 12.23.20 # * [Saint] wonders, if asked at the time, if anyone at devcon saw the transition taking this long. 12.24.17 # * bluebrother^ guesses a no 12.24.34 # wow, wavtrim in voicefile creation in Rockbox Utility is completely ignored :o 12.24.38 # i expected it to take more or less this long, yes :) 12.25.03 # because i guessed that i would end up writing all the docs and stuff :) 12.25.39 # <[Saint]> That's not really been the major holdup though. 12.26.23 # there haven't been major holdups, really 12.26.35 # there's been a list of things that need doing and they have just happened weeks apart from each other 12.26.44 # <[Saint]> A general feeling of disinterest seems to be a 12.26.59 # <[Saint]> major player. 12.27.18 # well, svn was working nicely for us, wasn't it? 12.27.52 # <[Saint]> Many seemed to think so, more didnt. 12.28.06 # <[Saint]> Or, more vocal people didn't 12.28.20 # mostly the latter :) 12.28.25 Quit liar (Read error: Connection timed out) 12.28.45 # and while git definitely has advantages svn wasn't that bad. Especially when compared to cvs :D 12.29.14 # hmm. Is there a see which commits I've already pushed? 12.29.56 # `git log origin/master..` will show any commits that exist in your local branch but not in the remote 12.30.45 # git <3 12.30.48 # ah, nice. Exactly what I was looking for 12.31.10 Join chkktri_ [0] (~user@unaffiliated/chkktri) 12.32.36 # Commit by 03Dominik.Riebeling (9db5c12): Fix wavtrim on voicefile creation. 12.35.15 # bluebrother^: further to the discussion fractionally earlier about change-id, you don't have the change-id hook installed :) 12.35.26 # which means you didn't read the instructions ;p 12.36.03 # * pixelma did but has nothing to commit and even if wouldn't have the courage yet 12.36.31 # besides I don't know if I'd be allowed to yet 12.37.02 # Torne: oh. Will fix. 12.37.17 # but to be more exact: I don't have the hook on *this machine* installed :) 12.39.13 # the (slighly) annoying thing when (having to) use multiple machines 12.39.42 # it would be nice if you could git clone --with-hooks or something, yes 12.40.01 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 12.40.01 Quit bertrik (Changing host) 12.40.01 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 12.40.03 # i mean, it doesn't normally for fairly obvious reasons, but *choosing* to isn't unreasonable :) 12.42.06 # I wouldn't mind gerrit requiring the hook before pushing. Would make it much more obvious if one forgot to install the hook 12.42.30 # yeah, i dunno. i didn't require it because frequently it's *not required* 12.43.00 # http://kerneltrap.org/mailarchive/git/2007/8/28/256180/thread 12.43.01 # but it might be nicer to 12.43.31 # saratoga_: you just change your local git config 12.44.55 # SynrG: the arguments in the thread are mostly irrelevant :) 12.45.21 # * SynrG shrugs 12.45.30 # just found it interesting, including some suggested workarounds 12.45.50 # e.g. ln -s ../git-hooks 12.46.06 # there aren't any workarounds 12.46.10 # that doesn't solve anything 12.46.17 # you still have to create the symlink in every repo 12.46.21 Quit Mineo (Read error: Connection reset by peer) 12.46.26 # hmm, maybe it makes sense to put the hook into something like tools/git, and a simple shell script that copies it to the right location? 12.46.28 # at which point you can just as easily copy hte hook from the server 12.46.38 # or have a shell script that creates the hook? 12.46.51 # or make it a part of the Makefile for the project 12.46.54 # would at least save from looking up the server location each time :) 12.47.09 # SynrG: that's not a useful/relevant concept for a commit-msg hook 12.47.14 # SynrG: doesn't work. 12.47.19 # they are talking about hooks that are validating whether the code is okay to submit 12.47.33 # the hook we are using here is purely about altering commit messages 12.47.46 # so? one project i am in has a 'make commit' for that purpose 12.48.21 # SynrG: still doesn't work. We have no single "entry-point" Makefile 12.48.23 # that's a truly awful idea 12.48.42 # also, people may not even have make, potentially :) 12.48.44 # for example, if you're working on Rockbox Utility (like me) you generate Makefiles using qmake 12.48.53 # there are things you can usefully change that do not need you to be able to build at all 12.48.59 # true 12.49.07 # abusing make like that is terrible, anyway 12.49.09 # or manual or voices 12.49.19 # * bluebrother^ agrees with Torne on that 12.49.26 # an also doesn't handle other cases where commit messages are created 12.49.30 # e.g. git cherry-pick, git merge 12.51.11 # bluebrother^: feel free to check in a copy of the hook to the tree, and/or a script to install it 12.51.24 # the hook is not expected to change, so it doesn't matter if you fetch it from gerrit 12.51.38 # but i don't think that will improve compliance particularly :p 12.51.53 # actually, one downside of requiring it would be that the hook *doesn't* fire on amend 12.52.21 # so i fyou commit without it, try and push and get rejected, then install the hook, you need to actually undo your commit and commit again to get it applied 12.52.24 # :) 12.52.42 # which involves, e.g. copypasting your commit message :/ 12.52.53 # hmm, that's a bit ... not so nice 12.54.42 # there's not really an alterantive that i know of 12.55.05 # this all comes down to "git fairly deliberately fails to provide any way to actually track changes" 12.55.29 # the slightly hacky trick being used to add that feature is not entirely perfect :) 12.56.42 # (linux didn't need this feature, because their "patch queues" are mailing lists and thus only humans need to be able to identify successive versions of a change, not machines 12.57.55 # anyway, yeah. check in the hook if you want 12.58.32 # but i suspect that people will not think about this until they've experienced gerrit creating new change reviews when they didn't want it to a couple of times :p 12.58.43 # they'll either happen to hit that step in the instructions, or they won't 13.01.59 # I don't even know what gerrit change reviews are 13.02.26 # then play with the demo :) 13.02.27 # So I'll likely either break things accidentally or get frustrated with it :) 13.03.40 *** Saving seen data "./dancer.seen" 13.08.27 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 13.11.00 Quit perrikwp (Ping timeout: 248 seconds) 13.13.24 # * amiconn wonders whether there's a howto somewhere that describes how to use git as similar as possible to svn 13.13.55 # Not necessarily using the same commands, but the same workflow, especially also the same number of commands 13.14.51 # E.g. how can I commit (push, whatever) from my working copy to the (local and) central repo with one command? Not the multi-stage stuff git uses as a default. 13.15.32 # don't tinhk you can 13.15.40 # but one extra command isnt such a big deal, surely 13.15.53 # and really, you should look into changing toa git work flow because it is far superior 13.16.18 # git commit && git push == svn ci 13.16.50 # Well, that's your point of view. Mine is different. That doesn't belong here 13.17.30 # And iiuc git commit isn't even the only step locally, as there are two. Or am I misunderstanding things here? 13.17.51 # git commit -a then 13.18.18 # amiconn: there is no such thing 13.18.37 # commit && push doesn't work, because if the push fails due to nonfastforward the commit will still have happened locally 13.18.48 # so the process to try again is not the same 13.18.58 # learn to use git; sorry 13.19.04 # meh 13.21.04 # anyway, yes, you need to also add changes to the index before committing. 13.21.15 # git commit -a will automatically add all changes to existing files to the index for you, though 13.21.21 # so, like, svn, you would only need to run git add for new files 13.21.42 # I don't want to commit all changes, just changes from source files I'm specifying on the command line 13.22.01 # * gevaerts demands to know why openvpn doesn't want to work with udp on his touchpad with CM 13.22.07 # oops, sorry 13.22.20 # amiconn: Then it already works 13.22.31 # git commit foo.c bar.c commits the changes to those two files, ignoring everything else 13.22.52 # You still need to do 'git add' for new files, though 13.23.12 # Yeah, that's the same with svn 13.23.14 # Right 13.23.29 # OK, so if you always commit that way you don't need to think about the index 13.23.42 # the only difference for that way of working is that instead of "svn commit" with no arguments, you need "git commit -a" 13.24.25 # * amiconn rarely used 'svn commit' with no further arguments 13.24.44 # right; that's a different way of working 13.24.49 # but yes, that works fine in git 13.24.59 # In fact, almost never. The only cases were when I checked out a release branch and ported a single fix to it 13.25.09 # amiconn: something like this? http://git.or.cz/course/svn.html 13.25.23 # But then I still need to push separately 13.26.01 # yes. that's not avoidable. 13.26.06 # There is no atomic commit-to-remote in git 13.26.10 # Cannot be done 13.26.20 # you can write an alias that commits and pushes in one go 13.26.28 # but if someone else committed since you last updated that will fail halfway 13.26.34 # Well, actually 13.26.43 # You could have it detect the push failure and undo the commit, actually 13.27.22 # having the possibility to commit without pushing is quite useful imo. Especially combined with amending and squashing 13.27.37 # git commit "$@" && git push origin HEAD:master || git reset HEAD^ 13.27.37 # makes it much easier to save in intermediate state 13.27.48 # that will undo the commit if the push fails. 13.27.54 # bluebrother^: That really depends on the workflow. You assume that one always wants local version control 13.27.55 # but.. you probably don't want to do that, seriously. 13.28.09 # because fetching new changes from the remote side is different 13.28.18 # I can live with the extra command, although it's sub optimal imo 13.28.30 # amiconn: It's not just an extra command 13.28.44 # The way you need to deal with someone else having committed in the meantime is different 13.29.12 # which is why tutorials that try to map svn commands to git commands are missing the point :/ 13.29.40 # amiconn: well, yes. But once one gets used to it you *do* want local version control. At least that's my experience. 13.30.03 # Torne: we could run git cvsserver :P 13.30.18 # amiconn: the difference that's important there is that if you do "svn update" with local changes, it will insert conflict markers/etc and merge the remote changes with what you've done 13.30.22 # which you then have to fix yourself 13.30.37 # if you "git pull" with local changes, it will abort if any file you have changed has been changed remotely 13.30.45 # it will not merge them 13.31.00 # it expects that you will commit your local changes first, and then either actually do a git merge, or do a git rebase. 13.31.15 # so, you can't really just decide to treat those two steps as a single operation. 13.31.16 # grml 13.31.35 Join fyrestorm [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com) 13.32.31 # you don't have to use exciting new features of git (heh) but you do need to understand how it actually *works*. 13.33.18 # incidentally this is why i traditionally used bzr, which has a perfectly functional atomic commit-and-push operation tha tworks exactly how you want 13.33.27 # but also supports all the distributed stuff otehr people like :) 13.34.39 Quit fyre^OS (Ping timeout: 248 seconds) 13.41.23 Quit chkktri_ (Ping timeout: 245 seconds) 13.43.38 Join mcuelenaere [0] (~mcuelenae@rockbox/developer/mcuelenaere) 13.43.51 # hi, I get "[remote rejected] HEAD -> refs/for/master (prohibited by Gerrit)" when pushing to www.git; is this normal? 13.45.10 # i haven't enabled code reviews 13.45.20 # because i haven't written up a policy doc/instructions yet 13.45.25 # gonna do it real soon, promise :) 13.46.08 # hmm ok, will post it as a patch then 13.49.56 Quit mcuelenaere (Quit: Ik ga weg) 13.50.47 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.51.59 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 14.11.44 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 14.12.56 # so how do we quickly have users know what version they are running and how current it is? 14.13.41 Quit factor (Read error: Connection reset by peer) 14.13.53 # what version they are running is hte short hash 14.13.54 # it was easy to tell how far off current and what the chronology of changes (and possible fixes) was with Rxxxxx numbers, but what "language" do we use to discuss such with question askers in the the forum now? 14.13.57 # how current it is.. er, the date 14.14.12 # i'm poking at a script that inspects the branch structure to work out something more useful 14.14.26 # date isn't always fine-grained enough to know if said user is running a bug-fixed version or not. 14.15.09 # indeed 14.16.13 # anyway, yeah. trying to do something better, but haven't had time to do all the entertaining logic yet 14.18.56 # soap: for now those users are running their own builds anyway, but they can still provide the same data (abcdef12-2012-01-12). The only annoyance is that we (i.e. the support people) have to do a bit more lookup work 14.19.24 # ok. 14.20.03 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 14.20.10 # I (think I) totally grok the hash, just don't know why a sequencing number isn't assigned as well. 14.20.29 # I'm sure that's been talked about in the git world before. Google-ho. 14.21.11 # We probably can't ever assign a proper sequence number for modified builds, but for the builds we provide there are several possibilities. It's just not done yet 14.21.35 # pamaury: gevaerts once said you should commit this FS#12526 14.21.35 # http://www.rockbox.org/tracker/task/12526 3put Fuze+ in unstable (patches, unconfirmed) 14.21.48 # ah yeah 14.22.33 # * gevaerts would phrase that slightly differently :) 14.22.34 # for the too other bug it would be nice to have bluebrother (manual) and kugel (PLA) opinion first 14.22.47 # that also requires changes the frontpage and perhaps the wiki. I'm busy right now but I'll do that later in the afternoon 14.22.56 # gevaerts: how would you phrase that ;) 14.23.14 # * jlbiasini my english is not evoluate since I live in Austria 14.23.27 # soap: it's been talked about, yes, but git people generally hate the idea 14.23.43 # because you cannot do it in a reliable way without breaking git's "perfect" symmetry 14.23.52 # and so most people give up in the face of extreme discouragement :) 14.24.19 # jlbiasini: we still don't have the bootloader file online right ? 14.24.30 # pamaury: I think only people closely involved with a port should commit unusable->unstable moves and similar things, so I won't commit that. I didn't mean you have to commit it because *I* think it's time :) 14.24.31 # pamaury: yes we do 14.25.18 # anyway yes I think we can move to unstable, the device is really usable. 14.25.43 # gevaerts: Ah yeah now I remember that it was what I was also wondering: in which sense you meant that... 14.25.52 # jlbiasini: did you try Rockbox Utility with it ? I should test it myself also 14.26.04 # it works 14.26.11 # nice :) 14.26.28 # I had zazog uploading your tagged file a few day ago 14.27.41 # the only remaining is the server saying Rockbox Utility that it is in unstable so that the complete installation works also 14.28.47 # But Rockbox Utility has problem that bluebrrother want to solve before making any new official release. So he meant that there is no hurry on this for now 14.30.10 # for the moment Rockbox Utility won't recognize the status of the fuze+, declare it unknowed so you have to go on the the second tab of the interface to select bootloader install 14.30.32 Join factor [0] (~factor@74.197.205.204) 14.31.44 # pamaury: anyway I have another question: is there anyway one could upgrade the firmware without using the internal memory? And is it possible to have a bootloader loading RB from sd card? I'm askiing because my internal memory just died... 14.32.47 # so I wonder I just throw away my device/send it for testing/ or wait for a turn around 14.32.54 # you mean upgrading the bootloader ? It is stored in internal memory but it's rarely written I admit. what happened to your internal memory ? 14.33.16 # Anyway yes, you can upgrade the bootloader just using the recovery mode 14.35.01 # my internal memory is now read only 14.35.19 # with some cluster being corrupted 14.35.30 # no way to format it 14.36.08 # I tried all the possible fsck.vfat/dosfsck option no result 14.36.31 # why can't you format it ? 14.36.35 # I just can't get anything writed on that 14.37.42 # is the whole internal memory read-only ? 14.37.46 # on windows it say it didn't succeed (wether quick or long format mode) gparted format and then show me the very same partition on releod 14.39.10 # what is the output of dmesg ? 14.39.39 # Actually not read only, it never say so, it just copy file and show them correctly copied on it but after unplug replug it, the file are not there 14.39.47 # wait I'll test that 14.40.27 # the nice thing is that as long has it doen't have to write on the internal memory, RB is still working!! 14.42.57 # pamaury: https://gist.github.com/1615895 on connection 14.47.31 # no dmesg while rm file of umount 14.51.42 # nothing strange. 14.53.13 # it's really unexpected, I would except the internal storage to replace bad blocks, it should take a fair amount of writes to end up in this situation 14.55.00 Quit stoffel (Ping timeout: 244 seconds) 14.56.31 # yes I really didn't expect that but fsck do report bad cluster (a lot) so I think this is just dead? Or do you have another explaination? 14.56.45 # anyway now this should be ready: FS#12529 14.56.46 # http://www.rockbox.org/tracker/task/12529 3Lamp plugins PLA integration (patches, unconfirmed) 14.57.46 # kugel: thank's for your comment you were right I just corrected it now it compile 14.58.15 # I didn't saw there was a scroll_repeat value 14.59.27 # bluebrother: sorry for asking again could we have your point about FS#12492 14.59.28 # http://www.rockbox.org/tracker/task/12492 3add fuze+ manual (patches, unconfirmed) 15.00.42 # bluebrother: did you already start something on the zip support for rockbox utility or can i start from the usual git working on that 15.00.45 # ? 15.01.30 # did you try the OF ? 15.03.44 *** Saving seen data "./dancer.seen" 15.06.01 Quit [Saint] (Remote host closed the connection) 15.08.44 # pamaury: https://gist.github.com/1615954 fsck result. Yes OF reboot after saying it needs more place on the device, rockbox go into panic if he try to write on the device 15.09.09 # fsck result give no change 15.10.28 # I don't see any mention of bad clusters, can't it just be a corrupted fat ? 15.10.36 # If I try tesk disk to erase partition table it says: Write error: Can't clear partition table. 15.10.43 Join Horscht [0] (~Horscht@p5DD56C19.dip.t-dialin.net) 15.10.43 Quit Horscht (Changing host) 15.10.43 Join Horscht [0] (~Horscht@xbmc/user/horscht) 15.11.02 # bad cluster are reported with -t option 15.11.13 # just a very long list of them 15.11.55 # hum, it would be interesting to see if one can get statistics by mmc about the bad blocks and so 15.12.28 # well If I can test anything just let me know :) 15.13.22 # I think that remapping the whole device without know about simulatorui was my main mistake... 15.13.24 # let me have a look at the mmc spec 15.13.49 # jlbiasini: that Quick Start vs. Installation tab thing is something I want to get rid of anyway. People don't seem to understand that installation is done using the Installation tab, not Quick Start (which in fact is only intended for a first and quick start) 15.14.29 # as for the zip support for reading OF files, I haven't done anything usable yet. It needs quite a bit of thinking since BootloaderInstallBase is pure virtual on pretty much everything except static functions 15.14.40 Join anewuser [0] (~anewuser@190.207.138.97) 15.14.40 Quit anewuser (Changing host) 15.14.40 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 15.14.58 # ok 15.15.07 # and we also need some way indicate the progress to the user, as well as handling the extracted file in a usable way. 15.15.35 # feel free to try to figure something, but I really don't want to duplicate stuff for each bootloader class. 15.15.35 # bluebrother: so you recommand me to want on this before knowing how to do it the reight way? 15.15.49 # *wait 15.15.58 # if you find a good way just let me know. Or provide a patch :) 15.16.35 # but since I'm in the process of cursing the multithread stuff for TTS that went in 1 1/2 years ago and is causing problems since I really don't want to have to rip up things again later and redo it :) 15.16.37 # ok I just wanted to know If you've already started something to be sure I wouldn't work for nothing 15.17.16 # why did you change Play/Pause to Play-Pause in the Fuze+ manual patch? 15.18.14 # yes this is a big consistency issue: in manual there are some table like volume up/down 15.18.41 # then It would lead to some entry like play/pause/cancel 15.18.58 # so now it will be play-pause/cancel 15.19.40 # like for other two words button (button bottom-left for example) 15.20.16 # which also means that I have to update the image accordingly 15.20.17 # that's not a common way to write this though. 15.20.24 # and it looks awful IMO :) 15.21.00 # yes but this is consistent and something like play/pause/cancel is also awful :) 15.21.04 # I would rather do it the way it's done for e.g. the Ipods: just name the button "Play", even if it has both a play and pause symbol on it 15.21.26 # Play-Pause/Cancel is pretty much unreadable 15.21.42 # does that mean Play and Pause/Cancel? Or Play/Pause and Cancel? 15.21.42 # that's right too! :D 15.22.31 # but then the same problem occurs with bottom-left/bottom-right! 15.22.43 # and why it is \ButtonPlayPause? It's \ButtonPlay for other targets, so if you make it \ButtonPlayPause for the fuze+ you need to adjust every use of \ButtonPlay in the manual. Which pretty much defeats the purpose of \ButtonPlay 15.23.32 # true, but just because of those bottom-something we shouldn't make it more complicated for play 15.23.33 # Yeah that is plainly right and I was very tempted to change that too 15.24.07 # I would *really* just make it ButtonPlay that simply displays Play. It's absolutely correct and way less changes. 15.24.53 # but the button itself is play pause (no slash just both symbol) 15.25.34 # so what? 15.25.48 # it's the same for Ipods, and on Ipods we simply call that button "Play" 15.25.59 # after all we name every button in the player image. 15.26.01 # but the consistent way is clearly the one you say... gee! seems I off for a new manual writing week!! :( 15.26.05 # so it's unambiguous 15.26.20 # other sansas are that way too 15.27.01 # and for that bottom-something: we label the buttons. We could even call them "X" and "Y" and would be fine. 15.27.14 # though I guess there are better ways to name those :) 15.28.17 # you should be able to replace that ButtonPlayPause with ButtonPlay in the patch and then reapply it :) 15.28.30 # so at least that shouldn't be a week of work 15.28.45 # I thing that bottom-something is good: there are no label on the player for those: they are just virtual on the touchpad like on player, so it avoid the user that read the manual to have all the time to go back to the player picture 15.29.36 # yes but I also have to undo some separation where it was possible to add the fuze+ to some play button like other target 15.30.13 # not sure if I got that 15.30.27 # those /opt(fuzeplus) have to go away in such case and be share with other player 15.31.12 # sure. 15.31.32 # but if you do the renaming in the patch first it should be easier :) 15.31.39 # ymmv of course 15.32.49 # that's right but whenever I edit patch I'm quite good at ending with "malformed line" stuff... I'll try anyway thanks for the comment 15.33.46 # and I will have to rewrite lamp now that it is in PLA 15.34.00 # pacman PLA is coming soon 15.36.59 # pamaury: I have to go for a while, if you don't find me here for those internal memory test, you can pm me 15.47.59 Part jlbiasini 15.52.17 Quit perrikwp_ (Read error: Connection reset by peer) 15.53.29 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 16.02.44 Join stoffel [0] (~quassel@pD9E422D7.dip.t-dialin.net) 16.16.55 # Commit by 03torne (1114a2b): Convert svn ignores into .gitignore. 16.22.30 # pamaury: what is dcp? 16.25.20 # Commit by 03torne (cb4e333): Convert svn ignores into .gitignore 16.25.21 # Commit by 03torne (39a7a0f): Convert svn ignores into .gitignore 16.25.22 DBUG Enqueued KICK CIA-81 16.25.22 # Commit by 03torne (8e8c1dd): Convert svn ignores into .gitignore 16.27.55 # the .gitignores don't look useful for the other repos 16.29.36 # so is it OK if I push the repo to github as a mirror (not automatically updated yet)? 16.29.51 # just so github people have something to clone from 16.30.02 # kugel: they may not be; someone who cares can delete them 16.30.18 # and i guess; 16.30.31 # if we want to mirror it there then prod zagor about setting up gerrit to replicate 16.30.34 # the docs should explain it :) 16.30.56 # but if you do it manually for now that won't hurt 16.36.29 # kugel: i just converted what was there so we don't lose it; if someone wants ot make an intelligent decision about which ones are useful/current/interesting they can just change them :) 16.40.23 # kugel: data co processor 16.40.35 # what can it do? 16.41.28 # memcpy, blit, encryption, hashing and (apparently undocumented) color space conversion+scaling 16.49.42 Quit SynrG (Read error: Connection reset by peer) 16.49.48 Quit perrikwp (Read error: Connection reset by peer) 16.51.02 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 17.03.46 *** Saving seen data "./dancer.seen" 17.03.49 Join Amqui [0] (Amqui@CPE90e6baf03fc0-CM001947575820.cpe.net.cable.rogers.com) 17.04.24 Quit Unhelpful (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 17.04.47 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.07.05 Quit Horscht (Quit: Verlassend) 17.08.54 Join SynrG [0] (~synrg@blk-222-91-184.eastlink.ca) 17.18.48 Quit perrikwp (Read error: Connection reset by peer) 17.20.02 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 17.25.54 Quit TheLemonMan (Quit: WeeChat 0.3.6) 17.42.54 Quit jordan` (Quit: Coyote finally caught me) 17.43.16 Join jordan` [0] (~gromit@2001:660:3302:2826:225:90ff:fe20:d9a8) 17.44.59 Quit jordan` (Client Quit) 17.45.20 Join jordan` [0] (~gromit@2001:660:3302:2826:225:90ff:fe20:d9a8) 17.53.47 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 17.56.20 Quit perrikwp (Ping timeout: 252 seconds) 18.05.54 Quit domonoky (Quit: Leaving.) 18.17.33 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.19.02 Join Wardje [0] (~ward@unaffiliated/wardje) 18.22.56 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 18.25.15 Quit perrikwp_ (Ping timeout: 252 seconds) 18.30.46 Join TheLemonMan [0] (~LemonBoy@ppp-170-13.26-151.libero.it) 18.38.48 Quit stoffel (Ping timeout: 255 seconds) 18.42.34 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 18.45.15 # shouldn't .gitignore be in .gitignore ? that way anyone can modify it for its need without always have it reported as changed 18.45.33 Quit perrikwp (Ping timeout: 255 seconds) 18.46.33 # pamaury: you don't want to have to manually copy/find a .gitignore after cloning a repo either though 18.47.20 Join lebellium [0] (~chatzilla@e179074191.adsl.alicedsl.de) 18.47.53 # hum, indeed, so there is no solution 18.48.11 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 18.48.36 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 18.48.55 # jlbiasini: I'm looking at your problem, I will try to modify rockbox to panic on read/write error and dump the mmc error code, it will be much more precise 18.49.22 Quit perrikwp_ (Read error: Operation timed out) 18.58.05 Quit jlbiasini (Remote host closed the connection) 18.59.53 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 19.02.34 # pamaury: thanks 19.03.48 *** Saving seen data "./dancer.seen" 19.06.48 # for the moment if I try to write something on the internat it does give some info. Trying to create a bookmark give me: "Updating size on empty dir entry 87" same with "dir entry 4" while trying to save a text file with text_editor plugin 19.11.28 Quit jordan` (Quit: Coyote finally caught me) 19.11.42 Join jordan` [0] (~gromit@2001:660:3302:2826:225:90ff:fe20:d9a8) 19.23.52 Part jlbiasini 19.23.56 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 19.24.38 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 19.26.09 Quit perrikwp (Read error: Operation timed out) 19.49.42 # pamaury: personal ignores go into .git/info/excluse 19.49.46 # exclude* 19.50.13 # ah ok, thanks 19.50.42 # but you can as well change .gitignore and commit the change 19.51.58 Quit mortalis (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/) 19.59.49 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 20.00.29 # jlbiasini: I have a patch that you can try 20.00.30 # https://gist.github.com/1616770 20.01.19 # do a bootloader build, use mkimxboot with the extra option -t recovery and send it using sbloader 20.02.02 Quit lebellium (Ping timeout: 240 seconds) 20.02.12 Quit perrikwp_ (Ping timeout: 245 seconds) 20.02.44 Join lebellium [0] (~chatzilla@e179074191.adsl.alicedsl.de) 20.08.33 # pamaury: thx, how do I send it with sbloader? where do I find sbloader? 20.09.42 # in utils/imxtools 20.10.27 Quit Zarggg (Quit: Rebooting client...) 20.10.42 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 20.10.54 Join TheLemonM [0] (~LemonBoy@ppp-61-5.26-151.libero.it) 20.11.48 Part lovasoa 20.12.44 # pamaury: make bootloader end with: make: *** Pas de règle pour fabriquer la cible « /home/jean-louis/Bureau/rockbox-devtree/sbtest/rockbox/buildboot/kernel-imx233.h », nécessaire pour « /home/jean-louis/Bureau/rockbox-devtree/sbtest/rockbox/buildboot/firmware/target/arm/imx233/kernel-imx233.o ». Arrêt. 20.12.52 # is it normal? 20.13.00 # ah yeah, I forgot to commit, wait a sec 20.13.12 Quit TheLemonMan (Ping timeout: 260 seconds) 20.13.30 # Commit by 03amaury.pouly (66c3086): imx233: oops, forgot file 20.13.33 # done 20.15.47 # i'd prefer to see real names instead of a component of email address, what do you think? 20.17.21 # yes I agree 20.17.29 # yes, me too 20.23.26 # pamaury: what should I give for argument 20.23.45 # 1024 20.25.15 # libusb:error [op_open] libusb requires write access to USB device nodes. :( this sometime happened to me I will reboot and see if I can get working 20.25.19 Part jlbiasini 20.25.29 # i think the cia hook is private (i did not see it in svn) 20.25.32 # do it as root 20.25.37 # btw no perl hacker could look at the buildsystem yet? 20.26.37 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 20.27.28 # rewrite it in something else than perl ;) 20.30.42 Quit jlbiasini (Ping timeout: 240 seconds) 20.31.35 # pamaury: it's in www repo 20.36.12 # and i don't feel like rewriting everything from scratch 20.36.28 # i thought build scripts would be fixed before we enable git in fact 20.36.45 # me too 20.37.42 # in Torne's mail it was explicit that it'd be done after though 20.38.12 # zagor and folks suggested it would be easier to just switch and sort stuff out afterward 20.38.41 # rather than set up more mirroring and try and run a second copy in parallel to test it, or something 20.40.07 # the problem seems to be noone knows perl enough 20.40.49 # well, i haven't looked :) 20.40.56 # people seemed confident it would be easy to change it 20.40.59 Quit benedikt93 (Quit: Bye ;)) 20.41.49 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 20.43.19 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 20.44.00 # jlbiasini: I just think about it, build it with -t singleboot instead of recovery, otherwise it will no mount over usb 20.44.47 Quit perrikwp (Ping timeout: 244 seconds) 20.44.56 # pamaury so just singleboot or singleboot and recovery? 20.45.08 # singleboot only 20.50.08 # pamaury: same but without "Disable MMC windows. No partition found. " what to do next just unplug? 20.50.28 # hum, with singleboot it disable MMC windows ? 20.50.44 # no more mention of mmc 20.51.01 # just like booting in usb mode 20.51.12 # ok, so now try to write something over usb 20.51.34 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 20.51.43 # (note that the recovery mode is only permanent, if you reboot the device, you will need to send it using sbloader again) 20.54.37 Quit perrikwp_ (Ping timeout: 260 seconds) 20.56.31 # jlbiasini: any consequence ? it should panic on any read/write failure 20.57.13 # no change 20.58.14 # it never panic ? 20.58.22 # it do not say anything like its working ether copy from nautilus or terminal 20.58.25 # no panic 20.58.46 # hmm, are you sure you are running the sb file ? 20.58.54 # but after umount remount nothing changed on the partition 20.59.28 # from the bootloader version showed yes 21.00.22 # ok, can you do another modification ? 21.00.33 # tell me 21.00.49 # in target/arm/imx233/mmc-imx233.c, in mmc_read_sectors 21.01.23 # replace "return bla;" by 'int ret = bla; if(ret != 0)panicf("die: %d", ret); return ret;' 21.01.33 # and same thing in mmc_write_sectords 21.02.14 # Has there been any discussion regarding ordering database artist view ignoring a starting "The"? 21.02.38 Join captainkwel [0] (~jason@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) 21.03.49 *** Saving seen data "./dancer.seen" 21.08.14 # pamaury: same 21.08.44 # Poodlemastah: have a look in flyspray there are to discussion regarding database about that 21.08.58 # then it would mean that all read/write are successful 21.09.24 Quit perrikwp (Read error: Connection reset by peer) 21.09.34 # is there a way we could force the syncronisation in terminal mode? 21.09.43 # what do you mean ? 21.10.11 # I suspect everything being copied to cache by the os 21.10.41 # but not synchronise or perhaps something hang just before syncronisation 21.11.07 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 21.11.18 # I think there a an option for mount doing that 21.11.27 # noatime 21.11.37 # did you try with a windows host ? 21.11.45 # or another machine 21.14.33 # well the problem does not occur on my usb key 21.14.50 # and is the very same both on linux and windows 21.15.21 # and even with noatime 21.15.26 # no luck 21.18.02 # err, sync would be the param 21.18.18 # and the command sync flushes the caches to filesystem 21.18.30 # (and is implicitly called by umount) 21.19.07 # well the only think that give me a write err is testdisk while asking to wipe the partitions table 21.19.35 # but no reaction of the firmware, still showing bl info 21.21.11 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 21.23.27 Quit perrikwp (Ping timeout: 245 seconds) 21.25.00 # isn't there a situation where the mmc would reply always true to watever is asked? 21.32.12 # pamaury: there is only one explication then: hardware is dead! 21.33.30 Quit TheLemonM (Quit: WeeChat 0.3.6) 21.41.26 # jlbiasini: perhaps...nevertheless, that's strange 21.42.27 # sdcard still works with your patch 21.42.54 # so that is really specific to mmc 21.43.37 # some hadware faillure report writing maybe 21.45.02 Quit y4n (Quit: PANTS OFF!) 21.48.27 Part jlbiasini 21.51.50 # jlbiasini (for the logs): then I guess you can disable mmc completely by changing CONFIG_STORAGE (remove mmc). That will default to sd card for the firmware then. Updating the bootloader will be a little more tricky though 21.57.48 # rockbox.org acting up? 21.57.58 # just came in here to ask that, its down for me 21.58.10 # ok, so it's not just my network connection 21.59.42 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 21.59.44 # git.rockbox.org is ok though 22.02.25 # it's back now 22.03.04 Nick adnap_ is now known as adnap (~adnap@rrcs-71-42-140-57.sw.biz.rr.com) 22.04.29 # jlbiasini: did you see my comment ? 22.05.42 # yes I'm on it 22.05.52 # but this will work only one time 22.06.15 # to have it permanently I have to upgrade the firmware right? 22.08.50 # yes, it's possible using recovery mode only 22.09.03 # ok 22.09.29 # i'll try! 22.09.35 Quit curtism (Quit: Live Long and Prosper) 22.10.07 Join LambdaCalculus37 [0] (~rmenes@c-68-32-226-242.hsd1.nj.comcast.net) 22.10.07 Quit LambdaCalculus37 (Changing host) 22.10.07 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 22.11.24 # jlbiasini: before, I have another idea 22.11.33 # tell me 22.11.36 # Can a forum mod bring the banhammer down on user Abramqsh on the forums? It's a persistent spammer and I'm still throwing stuff out from him/her/it. 22.14.06 # http://hi.baidu.com/braver/blog/item/7a32e324f1b99e2e8644f92c.html 22.14.12 # apparently this is partially based on rockbox? 22.14.30 # not sure if its running as an app on a linux system or just using the codecs though 22.15.53 # jlbiasini: in the first patch, in the transfer_sectors function, replace if(ret != 0) by if(ret == 0 && resp & ~0x1e00) 22.16.55 # pamaury can I let the previous modification or should I download the patch again? 22.17.11 # you can let it 22.17.16 # wait, the mask is not good 22.17.37 # sorry, not 0x1e00 but 0x1f00 22.18.36 # ok I better change the code directly then 22.19.27 Quit beslayed (Remote host closed the connection) 22.21.33 # wait there a problem! I think the patch did not apply at all!!! 22.21.46 # it would explain a lot!! 22.21.50 # sorry about that 22.22.13 # is there a different way to apply patch in git? 22.23.12 # no, just use patch 22.23.20 # pastebin the diff if you are unsure 22.25.34 # should I try the first one or directly the modification you told me? 22.26.34 Join beslayed [0] (~user@adsl-99-52-84-57.dsl.rcsntx.sbcglobal.net) 22.26.50 # pamaury: there is the first patch, then first modif, then the last one 22.28.17 # ok, can you pastebin the diff anyway, it would be a shame that we do not have the same code in mind :) Then try with the same procedure as before 22.28.35 # /home/jean-louis/Bureau/rockbox-devtree/sbtest/rockbox/firmware/target/arm/imx233/mmc-imx233.c:234: warning: format ‘%x’ expects type ‘unsigned int’, but argument 2 has type ‘long unsigned int 22.28.42 # compilation warning 22.29.02 # at least it prove that I did patch correctly this time! :) 22.29.33 # well just warning should I ignore rhis? 22.31.50 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 22.32.06 # yes ignore it 22.32.14 # you should have had this warning before :) 22.32.32 # yeah that waht i said ;) 22.34.32 Quit n1s (Quit: Ex-Chat) 22.38.54 Quit evilnick (Ping timeout: 240 seconds) 22.42.23 # pamaury with patch original no change 22.42.35 # let's do first modification 22.51.02 Quit jlbiasini (Remote host closed the connection) 22.53.20 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 22.54.57 # jlbiasini: I was wrong before -- looked into the zip thing a bit and it turned out to be in fact rather easy :) 22.55.00 Join zchs [0] (~zchs@ool-ad02eb3f.dyn.optonline.net) 22.55.27 # ok 22.55.35 # great 22.56.24 # pamaury: second change no luck 22.56.36 # the last change is the interesting one 22.57.04 # yeah this is the one I just tested 22.58.02 # if(ret == 0 && resp & ~0x1f00) 22.58.31 # really, you just tested this ? 22.58.41 # yeah 23.00.28 # hmm 23.02.01 # LambdaCalculus37: you still have your nano2g ? 23.02.30 # hmm. On e200 we're using e200pa.bin, but that's only the filename for the american firmware version. The others use e200pe.bin and e200pf.bin. Does the device flash it nevertheless? 23.02.32 # so you have tested the ret != 0 check, the ret ==0 & ... :-/ 23.02.42 # funman: Yeah, but haven't used it in ages. 23.03.09 # bluebrother^: yes the last letter indicates some features to enable or not, the files are identical 23.03.11 # I'm about to test if(1) just in case :/ 23.03.31 # LambdaCalculus37: could you try the patch i sent on the ML recently? I can make a build for you if you want 23.03.32 # hmm, I guess I need to make Rockbox Utility check all those filenames then. 23.03.32 # funman: I no longer have my iPod Classic though; I gave it to a friend. 23.03.45 # bluebrother^: just rename it to e200pa.bin ? 23.03.48 # funman: Sure. Can you build for me? 23.03.50 *** Saving seen data "./dancer.seen" 23.04.13 # jlbiasini: you tried to read and write with each variant ? 23.04.40 # yeah 23.04.44 # reading is ok 23.05.02 # writing seems ok but never actually happens 23.05.15 # is the battery sufficiently charged ? 23.05.40 # I guess so how much should it be? 23.06.06 # ohoh! 23.06.07 # I don't know but you were close to empty battery, the voltage might be affected, just a random idea 23.06.07 # funman: I'm trying to read the file directly from the zip you download from sandisk. I can't simply rename that file since I first need to find the correct one, and when I found it I can also simply use it :) 23.06.30 # but fortunately handling of multiple firmware filenames is already implemented 23.06.54 # pamaury: on unplug with the last patch I get panic resp: 80900 23.07.57 # I still have a third og battery 23.08.18 # that means unspecified error :-/ 23.08.40 # nice! :D 23.08.47 # so the device indeed reports something but we don't know what 23.09.14 # and it might on unplug because of delayed write I guess 23.10.14 # LambdaCalculus37: http://people.videolan.org/~funman/rockbox.zip : can you just tell me if USB still works ? 23.11.20 Quit jxb091000 (Quit: Leaving) 23.11.29 # funman: Sure, let me get the nano and a cable, 23.14.10 # pamaury: let me check I did right: I made the modification to the code. run configure in an empty dir selct fuze+ ask for a Bootloader build. run mkimxboot -i OF -b rbbl -i firmware.sb -t singleboot, sbloader 1024 firmware.sb, right? 23.14.18 # yes 23.17.29 # haha 23.18.11 # pamaury after I rm all file and dir on the volume it told me it is 18,9 Mo left 23.19.24 # which means ?. 23.19.36 # but still no error whil umount 23.19.57 # that something is wrong but I think we already know that 23.20.46 # forums going down for a quick bit 23.22.02 Join stooo [0] (~sto@f051106055.adsl.alicedsl.de) 23.22.11 # pamaury: well nothing new any other idea? 23.22.29 # no, if the mmc reports error, we can't investigate much further 23.22.33 Part stooo 23.23.34 # well I will turn mmc off then If I can use rockbox on sd card that already a big improvement for me thanks very much for your time 23.23.36 # :) 23.25.02 Nick Jack87 is now known as Jack87|Away (Jack87@nasadmin/admin/jack87) 23.25.03 # you still need to install a new bootloader, but maybe we can see this tomorrow 23.25.05 # at least now I know how to used sbloader and will be able to implement recovery mode for Rockbox utility! 23.25.24 Quit Staphylo (Ping timeout: 248 seconds) 23.25.33 # pamaury: oh? I though this was was -t recovery? 23.26.23 # -t recovery only build a file that gives you access to the firmware partition 23.26.44 # ok 23.27.29 # I suposed this is not as easy as copying sb file to it then is it? 23.27.30 # then you need to copy the real sb file (built with singleboot or dualboot) to the firmware partion, with a little subtlety (the first 4 sectors are skipped) 23.28.29 # ok some dd stuff? 23.28.31 # so basically: 1) build with -t recovery 2) sbload to device 3) build with -t dualboot 4) dd bs=512 skip=4 if= of= 5) pray ;) 23.29.09 # I could try now 23.29.35 # if=bl compiled of=firware.sb ? 23.29.47 # firmaware.sb* 23.29.48 # if=firmware.sb of=/dev/sdXX 23.29.49 # I have never tested building a bootloader with sd support only though so I can only guess that it will work 23.30.08 # you directly send the sb file built with -t dualboot or -t singleboot 23.30.08 # funman: I think it started to work, but the battery ran out. Had to put the nano on the charger for a while. 23.30.22 # ok 23.30.29 # I'll try then 23.31.01 # anyway else I will buy a new one so I guess It worth a try and good to know anyway 23.31.06 Join Scromple [0] (~Simon@119.225.209.134) 23.31.29 # LambdaCalculus37: oh ok, ping me when it works 23.31.36 # I hope you will be only one to suffer from this problem 23.31.46 # we could even have a special procedure on rbutil later for those who burned the internal 23.31.46 # it would be problematic if rockbox destroyed mmc :-s 23.32.28 # special procedure in Rockbox Utility? 23.32.36 # Didn't you saw that someone reported a problem with internal partition on forum? 23.32.43 # no 23.32.47 # Commit by 03Dominik.Riebeling (92fa7a8): Add alternate firmware filenames for e200v2. 23.32.49 # Commit by 03Dominik.Riebeling (b45cc0a): Support reading OF files from zip. 23.33.04 # when ? 23.33.07 # I'd really like to avoid having *more* special cases in Rockbox Utility. We already have too much 23.33.41 # bluebrother^: in bootloaderinstallimx actually 23.33.46 # funny, the CIA notifications show up in the opposite order the commits were made 23.33.47 # yes, and doing so is tricky because you need raw disk access and the procedure is not trivial 23.33.53 # a week ago or something like that 23.34.00 # in the Fuze+ thread ? 23.34.10 # yes 23.34.18 # unfortunately the forum is in maintenance 23.34.21 # unless some admin did some cleaning 23.35.08 # jlbiasini: if that means we need to pass additional information from outside to it (i.e. some information the user or configuration provides) that's a bad thing 23.35.19 # since that would mean breaking the interface. 23.35.39 # but I'm having my fuze+ since over one year and while working on keymaps I was like installing new build of rb 20 time a days... so I guess this could explain stuff... 23.36.45 # well, I have written the rockbox.sansa file an impressive amount of time also 23.36.57 Quit Scromple (Quit: Leaving) 23.37.35 # wow, it's over 3 years now the bootloader abstraction proved itself to be sufficient :) 23.38.02 # And I did some big copy on the device to like 50 gb in a few week 23.38.04 # bluebrother^: what is the most complicated bootloader installation rbutil has ? 23.38.29 # jlbiasini: do you follow the sandisk forum by chance ? 23.39.42 # yes why? 23.39.45 # err sansa 23.40.24 # since a few month less, I don't know why :D 23.40.33 # but I used to 23.41.18 # why? 23.41.23 # did you see any report of an internal memory failing ? 23.41.32 # a few yes 23.42.13 # but that right we should care about this problem I hope to be an exception 23.42.44 # 2 or 3 maybe But I was not going there all the time... 23.43.42 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 23.46.23 # did you succeed in installing a new bootloader ? 23.46.33 # i'm on it 23.47.06 Quit saratoga_ (Quit: Page closed) 23.47.53 # ok, tell me when you're done, so I can go to sleep :) 23.48.04 # ok 23.50.20 Join Thra11 [0] (~thrall@81.240.112.87.dyn.plus.net) 23.53.28 # pamaury: does the recovery bootloader I send throught sbloader has to have mmc enable? 23.53.37 # yes