IRC log for #maemo-ssu on 20120831

00:58.29*** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139)
02:52.32*** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn)
05:14.34*** join/#maemo-ssu LaoLang_coo_ (~LaoLang_c@221.226.175.139)
05:34.22*** join/#maemo-ssu M13 (~Miranda@83.149.37.244)
06:13.46*** join/#maemo-ssu angelangle (~root@180.110.241.129)
07:16.18Estel_kerio, defrag on device with hardware wear leveling? Are You kiding me?;)
07:16.29Estel_kidding*
07:16.39Estel_lol @ kiding*. something related to kid, probably
07:17.16kerioEstel_: huh... defrag on ext3, yes
07:17.21Estel_freemangordon, how is life in CSSUland?
07:17.22kerioaka defrag on a perfect block device
07:17.40Estel_kerio, Your logical filesystem get fcked up by physical filesystem via hardware wear levelling ;)
07:17.41kerionotice how i said /home and not /
07:17.51Estel_i.e got spread on eMMC anyway
07:18.22keriobut... it's perfect! :C
07:18.36Estel_sure, 256 NAND doesn't have hardware wear levelling, so You rely on ubifs for that. but opt and home is on eMMC and hardware wear leveller is implemented transparently
07:19.01Estel_i.e. no way to turn it off, in the world
07:19.19Estel_(turning off would be beneficial for TrueCrypt, but You can't do it on eMMC nor SD cards)
07:19.29Estel_(which is lame, btw)
07:19.40keriobeneficial performance-wise or security-wise?
07:19.48Estel_security, only
07:20.05keriowell, if there's no way to access the raw flash...
07:20.09Estel_it's about fact, that if You overwrite You encrypted partition - for any reason - old chunks are still spread on physical device
07:20.48Estel_if You use same password than before (when re-creating encrypted partition, for example0, You actually aid cryptography
07:20.50keriohm, i wonder if the emmc supports "discard"
07:20.52Estel_attack
07:21.11Estel_of course it's not trivial to retrieve such chunks, and would require physical access to flash
07:21.17Estel_no, it doesn't
07:21.35Estel_well, I've mentioned other cases where hardware wear levelling is PITA in TrueCrypt annoucement thread
07:21.38Estel_in FAQ
07:22.13Estel_generally, it's nothing critical, just require to avoid doing some things, or, if feel paranoic, overwriting rest of eMMC with 0 or 1, when You're changing truecrypt'ed partitions/containers layout :P
07:22.47Estel_generally, all of wear-levelling vs TrueCrypt concerns are quite on "paranoia" level, i.e. no need to worry about it if You're encrypting personal photos, etc
07:23.01Estel_but definitelly worth following if You're oppositionist in Iran, for example
07:23.46kerio[relevant xkcd here]
07:23.54Estel_especially considering, how Irani fckd' up "web of trust" & gmail, via ssl certificate crisis with digi-something
07:24.27Estel_and by "fckd up" I don't mean "breakage", rather "fckd in ass"
07:25.09Estel_it's funny, bTw, that actually, firefox helped to reveal borked certificate authority
07:25.37Estel_at least this behemot memory usage was used, once, to do good :P (sadly no, as it wasn't related to resources usage, at all)
07:26.21*** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net)
07:26.35Estel_what concerns me, though, is that for 3 days I'm asking merlin1991 about status of busybox-power for CSSU - just about decisions, not implementation status - and reply is just quiet and lonely space
07:27.16Estel_seems that no other ways, than starting "show" in mailing list/TMO :(
07:27.24freemangordonEstel_: can you imagine merlin1991 is on holiday with very bad internet access?
07:27.30Estel_sure
07:27.42Estel_that woudl explain things a lot :)
07:27.47freemangordonwell, wait him caome back, ok
07:27.49freemangordon?
07:27.59Estel_of course. Wasn't he just back, 2 days ago?
07:28.03Estel_3 days ago*
07:28.11freemangordonno, he wasn't, read the logs
07:28.17Estel_my bad, then :)
07:28.45Estel_and no worry, I'm just "little" dissapointed, that one CSSU maintainer said one thing, and another one - quite inactive normally, if You ask me - denies it in TMO thread
07:29.00Estel_resulting in 3 pages of discussion in otherwise productive busybox-power thread
07:29.07freemangordonafaik merlin1991 is in greece, spain, or some other sunny place
07:29.07Estel_no hostile intentions here, just curious :)
07:29.14Estel_is jealous
07:29.29freemangordondon't be, it is too hot there :P
07:29.57Estel_BTW, once You've said that DocScrutinizer05 isn't CSSU maintainer. Few days ago he linked me to garage page, where he is listed as maintainer, said that it's the case for more than a year, or longer
07:30.10Estel_freemangordon, hehe. We have few rainy dais ahead, here
07:31.26freemangordonthat page? https://garage.maemo.org/projects/cssu/
07:31.34Estel_what I'm pissed about, is just information havoc. Also, it turned out, that busybox-power isn't "installable from extras without hassle", as it's, in fact, postinst script with binary replacement. *only* other possible - and proper - way would be to add it via CSSU, as it's critical systemk component
07:31.45Estel_freemangordon, yes
07:31.49Estel_this page
07:32.01kerioEstel_: well, not really
07:32.04freemangordonwell, he is admin on THAT page ;)
07:32.08keriomake a repo, call it "busybox"
07:32.20Estel_kerio, make a repo? seriously? CSSU is repo for such things :)
07:32.21kerioand make sure the version is higher than the other busyboxen
07:32.28Estel_and "make a repo" doesn't fail into "installable from extras"
07:32.38Estel_freemangordon, well, suspected something fishy
07:32.42freemangordonsee, I want merlin1991 back before continuing that discussion, ok?
07:32.46Estel_sure
07:32.52Estel_wanted to propose exactly same thing
07:32.59freemangordonhold your horses then :P
07:33.01Estel_no need to add into information mess around CSSU :)
07:33.42freemangordonno need to make unnecesarry noise
07:34.02keriofreemangordon: are you kidding me
07:34.07keriohttp://www.youtube.com/watch?v=P7B-AlKTdGQ
07:34.09Estel_one good thing fromt his whole mess - many people got interested about CSSU and way it's maintained. Maybe, just maybe, ages long idea of "steering group" for cssu will got revived, at some point
07:34.24Estel_more and more devels and users would benefit from knowing what can be expected, and what not
07:34.53freemangordonbut to be clear - CSSU maintainers are MohammadAG(CSSU-T), merlin1991(CSSU-S CSSU-T(backup) and chem|st (CSSU-S)
07:34.53Estel_kerio, wanna blow up my speakers?
07:35.00kerioabout half of RFUS is unnecessary noise
07:35.07Estel_freemangordon, thanks a lot for that clarification
07:35.22Estel_chem|st, lol
07:35.24keriofreemangordon: and freemangordon(CSSU-Th)!
07:35.31freemangordonkerio: no
07:35.40kerio:(
07:35.51freemangordonCSSU-thumb is not "official" CSSU
07:36.07freemangordonotherwise, yes, I am the one who upload stuff there :D
07:36.12freemangordon*uploads
07:36.17kerio(:
07:37.22freemangordonthe point is - don't put -thumb and CSSU in one place until there is a need to do so ;)
07:38.01kerioEstel_: btw, blowing up speakers is what that song is supposed to do
07:38.04keriowell, kinda
07:42.14freemangordonhttp://www.youtube.com/watch?v=yLgporKLnpA
07:49.03chem|stEstel_: ?
07:50.09Estel_chem|st, sorry for pinging, You were only mentioned
07:50.57Estel_see full context - I was just surprised, as I wasn't aware of You being actively contributing to CSSU in any way, for a long time (haven't confirmed it, just feeling, thus my comment - excuse me if it's not true)
07:51.08Estel_kerio, see query
07:51.17kerioi lost the query \_o_/
07:51.25keriomy client is stupid
07:51.34kerioi just hoped it wasn't important
07:55.11Estel_wasn't at all, will re-send it anyway :P
07:58.55Estel_freemangordon, fuck! I just noticed that my work on CSSU-T wiki page wasn't saved, what the f? Probably browser hickup
07:59.01Estel_have backup, will fix it ASAP
07:59.07Estel_sorry, I was sure it's up and running hapilly
07:59.15Estel_for a few days, actually
07:59.24Estel_CSSU-T as in CSSU-Th, sorry
08:12.14chem|stEstel_: well I come from alpha testing and some of the early stages of MohammadAG's stuff past my device like "would someone mind to test that real quick? - reflash"
08:12.42chem|stEstel_: and now I will grow some balls and take over stable! HA
08:14.50chem|stI am not very good in doing bugreports as I like to talk to devils in irc instead of filing it properly... but that is from being used to alpha-testing... there were no such thing as bugtracking apart of a spreadsheet
08:16.41chem|stEstel_: and btw it is again your attitude that makes people mad at you, I for one ignore it for a long time now, but laughing at people whom actually did some more than just talking is nuts
08:17.42chem|st*facepalm*
08:18.27Estel_chem|st, peace, it wasn't offensive, just stating facts, and only when you've asked :)
08:18.43chem|styou pinged me...
08:19.00chem|stI did not ask!
08:19.04Estel_I feel it strange, when someone not related to project for a looooong time - and as You said Yourself, You were never really into CSSU thing - is listed as maintainer. that'sd all, it doesn't offend You.
08:19.12Estel_Until you're (clearly) overreactive about Your ego.
08:19.17Estel_no, never pinged You
08:19.25Estel_commented during discussion
08:19.36Estel_mentioning someone's nick != pinging
08:20.00Estel_so take a deep breath and relax :)
08:21.25Estel_BTw, out of curiosity, if You are here, already - once You've mentioned, that You're able to dissasemble and assemble back again n900 in 20 minutes (as answer to me, speaking about time required to put back again flip-flop mechanism of N950 - You though, that I was talking about N900)
08:21.34Estel_I have asked You - out of curiosity - why it takes You so long?
08:21.47Estel_you've never answered, though
08:22.01Estel_i'm just curious, which part is most bitchy for most people (of assembling device)
08:22.48Estel_as ussually, it takes 5-7 minutes to dissasemble and assemble, including screen (2 minutes depends on screen connector, which can be tricky, even for trained people)
08:23.30chem|stthe domesheet is an ass
08:23.44chem|stall the shielding boxes
08:24.27DocScrutinizer05(([2012-08-31 09:34:53] <freemangordon> but to be clear - CSSU maintainers are MohammadAG(CSSU-T), merlin1991(CSSU-S CSSU-T(backup) and chem|st (CSSU-S)))  ----  excatly, and those decide on their peer&steering-group, and - like it or leave it - they don't listen to estel with his bitching
08:24.31chem|stif disassambling does not inlcude those it is those 8 screws off those some clips of and everything back together again
08:24.57chem|stthat was what I did after a wheatbeer attack, I'd guess some minutes?
08:25.42DocScrutinizer05btw my contribution is to constantly dispute with fools who think THEY are steering group and smarter than those who got a word by merit.
08:25.56chem|stDocScrutinizer05: I love you!
08:26.07Estel_DocScrutinizer05, in fact, I find You mentioning garage page with You being listed as admin - suggesting that it means You're a maintainer - quite cheap
08:26.14Estel_but as said, I'll leave it until merlin1991 comes back
08:26.44DocScrutinizer05I give a fuck about your definition of maintainer, it's simply irrelevant to CSSU
08:26.55chem|stI did not follow busybox stuff as I don't give a fuck!
08:27.23chem|stwhat does it fix?
08:27.25Estel_he, he, so i;ll gladly reffer to "fortunatelly, DocScrutinizer05 isn't maintainer, so all things presented is his private opinion,only, equal to every ordinary CSSU user" in context of busybox-power
08:27.46DocScrutinizer05chem|st: ONCE AGAIN SOME FOOLS WANT TO MAKE SOMETHING MANDATORY THAT'S *ALREADY* OPTIONAL, JUST FOR THE "BENEFIT" OF ANOTHER 500K OF ROOTFS EASTED
08:27.48Estel_chem|st, upstream bugfixes, recent actual busybox version.
08:27.56DocScrutinizer05chem|st: OOOPS CAPSLOCK, SORRY
08:28.02DocScrutinizer05dammit
08:28.05Estel_it isn't optional, and You were delibatery spreading FUD about it. It's *not* easily installable from extras.
08:28.13Estel_Only one way to replace busybox properly, via package, is CSSU.
08:28.22DocScrutinizer05bullshit
08:28.23Estel_package in extras use dirty trick, that replaces binary file via postinst script
08:28.26Estel_ugly and inneficcient
08:28.32Estel_no other way, as it's core system package
08:28.36DocScrutinizer05so why do WE care?
08:28.43chem|stEstel_: that is not realy mandatory if there is nothing in cssu actually needing it capiché?
08:28.47Estel_You could distribute whole CSSU via "postinst script that replace binaries", but it's *wrong!* and wrong again.
08:29.08Estel_chem|st, reffer to busybox-power release notes, for lsit of fixed bugs
08:29.10Estel_list*
08:29.15kerio*capisc'
08:29.17DocScrutinizer05I could kick you for constant trolling
08:29.28Estel_we actually have busybox update in CSSU - that adds portrait support to it, sic!
08:29.35DocScrutinizer05we could roll an estel cssu distro
08:29.37chem|stDocScrutinizer05: don't let me do it°
08:29.41chem|st(TM)
08:29.41DocScrutinizer05we could eat shit
08:29.54Estel_DocScrutinizer05, sure, you could kick everyone and feel powewr! But it's pathetic, again, everytime You speak about it, during discussion.
08:29.55chem|stwe could make him eat shit o.O
08:29.58Estel_and speaks poorly about You
08:30.20kerioDocScrutinizer05: it's actually just 300k wasted if you use the thumbified version, btw
08:30.49chem|stEstel_: my browser is stalling... would you mind to state some bugfixes that are really important?
08:30.56DocScrutinizer05kerio: thanks! and it's even 90mb saved, if we don't use emacs version
08:30.59Estel_DocScrutinizer05, like it or not, i'mabsolutely sure, that CSSU will progress, witrh thing like busybox-power and - much later - thumb. Well, again, no need to argue, future will tell who was right :)
08:31.21Estel_chem|st, sorry, read busybox-power logs Yourself, i'm not Your search engine.
08:31.25chem|stDocScrutinizer05: who booted emacs?
08:31.31DocScrutinizer05Estel_: so what? maybe you're sure the earth is a disk
08:31.34DocScrutinizer05I don't care
08:31.44chem|stEstel_: FUCK YOU I JUST STATED THAT MY BROWSER STALLED!
08:31.50Estel_well, CSSu would benefit *much* if You would care, actually, in my opinion ;)
08:32.03Estel_chem|st, sorry, missunderstanding
08:32.17chem|stEstel_: ok thank so no facts just wishes...
08:32.18Estel_I though it's my browser stalled -> which busybox power bugfix will help with it
08:32.30Estel_i.e. as for browser in N900, which is irrelevant
08:32.34chem|stno here... darn ff
08:32.39Estel_sure, wait a second
08:32.51chem|stupdates are progressed for minutes now
08:33.48Estel_chem|st, from top of my head, swapon finally support priorities properly
08:33.56Estel_waiting 'till page loads :)
08:34.18chem|stI hate being at work... we have a "no linux" politician upstairs
08:34.25Estel_(i.e. setting swap priority on stock busybox was ignored, for no reason, as this parameter was listed in -h)
08:34.53Estel_chem|st, other thing from top of my head - proper shell history handling
08:35.01Estel_both for multi-instances of x-term
08:35.04chem|stEstel_: you know that stuff in cssu is meant to go to stable some day...
08:35.08Estel_of course
08:35.12DocScrutinizer05Estel_: if you still haven't groked it, my contribution to CSSU is exactly what I'm doing all the time: keeping overview of the larger perspective, check for stupid ideas and explain why they won't fly, find better alternatives if the original intention has any inherent value. So basically YOU give me tons of workload
08:35.18Estel_busybox-power is in fact much older project than CSSU ;)
08:35.25DocScrutinizer05so what?
08:35.27Estel_one of msot respected and stable ones
08:35.51Estel_DocScrutinizer05, it's nice, as my contribution to CSSu is explaining whjy You'r arguments are totally made up, biased, and irrelevant. Happy now? :)
08:35.54chem|st+1 so what?
08:35.59Estel_and least we have balance in universe
08:36.05DocScrutinizer05Estel_: WE DON'T NEED bb-p in cssu. ETX
08:36.08chem|stcssu is no fancy "power" playground
08:36.16Estel_chem|st, as for Your question "chem|st> Estel_: you know that stuff in cssu is meant to go to stable some day..."
08:36.24Estel_busybox-power is much more stable than cssu-S, anyway :P
08:37.36chem|st*sigh*
08:37.44Estel_as for other fixes, it's really hard to mention in IRC - just check upstream fixes for busybox, since Maemo's  ancient version
08:37.47Estel_tons and tons of them.
08:37.54Estel_and I mean only fixes, not enchancements.
08:38.09Estel_chem|st, busybox-power have -power in name jsut as a kind of pun...
08:38.20Estel_but I see that both You and DocScrutinizer05 have problem with things having "power" in name, heh?
08:38.42chem|stEstel_: maemo is literally sarge crossed with edge and people try to go wheezy with eating parts of squeeze on the way up
08:38.55Estel_DocScrutinizer05, speak what You want - I'm absolutely sure that busybox-power *will* be included in CSSU. Wan't to risk bootle of best beer?:)
08:39.05Estel_hehe
08:39.23chem|stwe are trying to let it become squeeze and not sid
08:39.47Estel_well, the thing is that busybox-power meet every single smallest criteria/requiments to get into CSSU - upstream bugfixes, well tested, actively maintainer over a years, can't be distributed properly outside CSSU
08:40.00Estel_and DocScrutinizer05  is bitching about it only due to personal prefferences
08:40.06Estel_thats the point :)
08:40.28Estel_fortunately, DocScrutinizer05's influence on CSSU is much lower than he like to thing it is, so i'm absolutely sure it will made it into CSSU, very soon.
08:40.43chem|stdoes it benefit cssu now (I am not asking about later I am asking about now!)
08:40.50Estel_until that, no much need for arguing, as neither of us (me or DocScrutinizer05) is deciding about it
08:40.54Estel_sure
08:40.58keriochem|st: how does MHD benefit cssu?
08:41.06Estel_but define "benefit" would be great
08:41.12Estel_as nothing in CSSU benefit CSSU :P
08:41.17Estel_how portrait support benefit CSSU?
08:41.22Estel_CSSU is meant to benefit users, not itself
08:41.45chem|stbusybox is not a user benefit
08:42.18DocScrutinizer05Estel_: you're spamming channel with bullshit. Nobody is interested in your delusions, and we're definitely not amused about your lies
08:42.34Estel_stop speaking about "everybody" or "nobody", speak for Yourself
08:42.45Estel_chem|st, what? hahaha
08:43.02DocScrutinizer05so I declare busybox-power as a ban'able subjext in this chan just for you
08:43.05Estel_busybox-power - even with current, borked implementation via binary replacement - have more users than cssu
08:43.17chem|stEstel_: you really expect me to trust you after all the shit you rolled the past 3 month?
08:43.20Estel_DocScrutinizer05, sorry, but I have in certain place, what You declare.
08:43.33DocScrutinizer05:shrug:
08:43.37keriohm, i don't know if that translates well to english
08:43.39DocScrutinizer05you've been warnned
08:43.42Estel_chem|st, you think that I care if You trust me? Nice from You, but, well...
08:43.43DocScrutinizer05officially
08:44.27chem|stEstel_: you still do not get the difference
08:44.38Estel_DocScrutinizer05, You're also warned officially. There actually is ongoing process of revieving Your mental ability to be chanop in *any* Maemo channel. Of cours,e due to your constaint threat of kick/ban/whatever pathetic, while You lsoe Your nerves during discussion.
08:44.55Estel_just for sake of your contributions to being chanop - get a deep breath, go for a walk...
08:45.10*** mode/#maemo-ssu [+o DocScrutinizer05] by ChanServ
08:45.13Estel_and stop this bullshit madness, everyone is free to talk about busybox in context of CSSU.
08:45.27*** kick/#maemo-ssu [Estel_!~HaleBopp@openmoko/engineers/joerg] by DocScrutinizer05 (don't threat chanops!)
08:45.50*** join/#maemo-ssu BCMM (~ben@unaffiliated/bcmm)
08:45.56*** join/#maemo-ssu Estel_ (~Estel@Maemo/Community/council/Estel-)
08:46.28Estel_DocScrutinizer05, your power abuse speaks poorly about You, and will be reported. I don't expect fast action, but be ensured, that it will be bounced back to You, sooner or later :)
08:46.35chem|stEstel_: nice that was actually the first time DocScrutinizer05 kicked someone while I was live and the item was no spambot...
08:46.44*** kick/#maemo-ssu [Estel_!~HaleBopp@openmoko/engineers/joerg] by DocScrutinizer05 (don't threat chanops!)
08:46.57chem|stDocScrutinizer05: stop it please
08:47.07DocScrutinizer05ok
08:47.29*** join/#maemo-ssu Estel_ (~Estel@Maemo/Community/council/Estel-)
08:47.42chem|stEstel_: hope you took a deep breath out there
08:47.58Estel_why so? This conversation is over, won't waste my fingers on this pathetic guy.
08:48.06DocScrutinizer05just can't stand that bitchingt anymore, and somebody threating me and ignoring authority of chanops nby "stick it where the sun doesn't shine" makes me angry
08:48.17Estel_not that it matters, really, he is as powerless, as he think he is powerful. Or even more the former :)
08:48.44chem|stEstel_: DocScrutinizer05 would you both mind to stop trolling now?
08:49.09chem|stsetup a channel for it and buy t-shirts...
08:49.47chem|stEstel_: bb-p will be reviewed for sure but by the calcs of now I doubt it being included next week
08:50.00DocScrutinizer05ooh, cannel named "estel's collected lies performed live"?
08:50.02Estel_same here, certainly not in next update.
08:50.41Estel_AFAIK it's being reviewed actually, merlin1991 is jsut on vacation. It's sad that busybox-power thread was filled with lies, that it's not gonna enter cssu, though.
08:50.44chem|stwe have a bit of work to do next week so better help with that and put everything else aside for now
08:50.49Estel_of course You know where those FUD originates ;)
08:51.22DocScrutinizer05counting up on lie counter
08:51.22Estel_absolutely agree, no need to haste. All people need is reliable information, and there was much mess about busybox-power state re CSSU.
08:51.41Estel_OTOh, merlin1991 officially started revieving it something like week ago.
08:51.49chem|stit all stopps at my doorstep, and I prefer shoot'em all and let god sort them out
08:53.29*** mode/#maemo-ssu [-o DocScrutinizer05] by ChanServ
08:53.40*** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu)
08:53.41DocScrutinizer05thanks
08:53.43DocScrutinizer05forgot
08:54.02chem|sto7
08:54.55DocScrutinizer05wondering if I should leave for my last workday at STE, or rather have a coffee and 'enjoy' IRC a bit more
08:55.27chem|stouhuuu last working day, I'd run for it to get it over with
08:55.39chem|stff still stalling...
08:55.59DocScrutinizer05hey, your key is borked? :-D
08:56.00chem|st.net framework assistent
08:56.10DocScrutinizer05aaah FireFox
08:56.45chem|stmy e key is borked, do you know where I can get a domesheet from?
08:57.11DocScrutinizer05chem|st: estel had the nice idea to start a thread on tmo to spank cssu maintainers and give them "motivation"
08:57.17chem|stand would you mind selling or lending me one of your devices? I do not have any luck with ebay
08:57.30chem|stDocScrutinizer05: ?
08:57.49chem|stDocScrutinizer05: or gimme a hand with ebay?
08:57.50Estel_in fact, no - I though about getting information about state of CSSu maintaining, how it looks.
08:58.25chem|stEstel_: your intentions are questionable but the outcome is what counts
08:58.43Estel_it started, when some well known egomaniac linked me to garage page with DocScrutinizer05 mentioned in admin list, suggesting, that it means he is maintainer
08:58.57Estel_chem|st, I never did it, so I preffer outcome is null ;)
08:59.15Estel_all after all, I'm sure merlin1991 will clear all this mess upon returning, as some people went too rogue for civilized people's taste.
08:59.43Estel_...about stating what cssu will and won't be, authoritary, without being a maintainer. Eh, do we really need to continue it here? :)
08:59.56DocScrutinizer05Estel_: I suggested you should look at that page and grep it for "joerg" and "estel"
09:00.00DocScrutinizer05nothing more
09:00.06DocScrutinizer05lie counter counting up
09:01.34DocScrutinizer05chem|st: sure, I can help with ebay, I can lend you one of my devices as well. Or you ask our chief contributor Estel_ to actually stand up and *do* something about cssu and lend you one of his devices
09:02.03chem|stEstel_: ?
09:04.34chem|stsighup child problem 4 days ago... so much about stable
09:04.46DocScrutinizer05Estel_: yes, I'm sure merlin1991 will politely explain to you the 50th time that you don't understand how cssu hierarchy and merit works, and that there's simply no use in you asking "are you maintainer?" since one thing's for sure: YOU are none
09:05.09DocScrutinizer05chem|st: o.O
09:05.14DocScrutinizer05how did you tell?
09:05.31Estel_chem|st, in -devel releasE?
09:05.38Estel_seriously?
09:06.04Estel_if it what makes package not OK for CSSU, it would be empty repo.
09:08.59Estel_DocScrutinizer05, I shouldn't be even speaking with You about all this egomaniac shit You have just done - but, as before - future will tell, who was right, and I'll be glad to mention it - as history - next time You will authoritary declare what will and what won't be in CSSU. More and more you're doing it, the less reliable source of information you become. People will remember that, when busybox-power will enter CSSU. End of topic, I g
09:08.59Estel_uess?
09:09.56DocScrutinizer05blablablablablabla
09:10.32chem|stEstel_: fyi - https://garage.maemo.org/projects/cssu-stable/
09:11.17Estel_chem|st, it was mentioned, and he is jsut admin on *that* page.
09:11.29chem|stEstel_: and DocScrutinizer05 is not self-assigned... he was asked for
09:11.31Estel_<freemangordon> but to be clear - CSSU maintainers are MohammadAG(CSSU-T), merlin1991(CSSU-S CSSU-T(backup) and chem|st (CSSU-S)
09:11.57Estel_well, high time to revoke it, due to his mental state, if he doens't learn to behave...
09:12.10Estel_but you're biased toward him, so no point in continuing this discussion, I suppose?
09:12.56Estel_I'm just glad, that despite fact, that we don't like each other (me and You, chem|st), we can have a civil talk, without threats of abusing chanop powers, etc
09:13.15Estel_It speaks good about You.
09:13.29chem|stEstel_: it is no abuse if you step over the line...
09:13.46DocScrutinizer05which in my book he just did again
09:13.54Estel_sorry, "defining" busybox as "ban" topic for certain user, out of ass, is stepping out of the line by chanop, and You know it as well as I.
09:14.10chem|stsometimes you get me quiet close or get me pondering with a silence spell casted on you
09:14.14Estel_especially during merit discussion, where we can disagree, but we shouldn't abuse power.
09:14.41Estel_well, I'm glad that reliability wins over personal "dislike" in you, then :)
09:15.34Estel_as we don't need to agree, just need to be civil while doing so. It's not popularity contest, after all.
09:15.34chem|stEstel_: while you are trolling it is ok with me to make it a no go topic for you, bb is reviewed and will be in the future, for now this discussion about bb chanop and you and me having a beer while chatting is over, do you understand?
09:16.25Estel_well, for me it isn't, and higher authorities will investigate it - along with other evidence of DocScrutinizer05 abuse (which was already considered valid).
09:16.43DocScrutinizer05lie counter counting up
09:16.45Estel_in fact, it's You who keep pinging me, while I'm doing other, productive things ;)
09:17.02DocScrutinizer05lie counter counting up
09:17.25Estel_so no problem with FINALLY ending this embarassing and msierable topic. After all *some8 people might think that they're center of universe, which we don't want, eh? ;)
09:17.38Estel_going back to work
09:17.49DocScrutinizer05lie counter counting up, i'm afraid
09:18.58chem|stwhich part of stop it didn't pass your eys?
09:19.11chem|styou too DocScrutinizer05! I am fed now
09:21.53chem|stwhohoo apple looses again vs sammy (japan this time)
09:28.20keriochem|st: what did you eat?
09:28.36DocScrutinizer05chem|st: I really get fed up with this guy stating lies since a week ar longer now (starting with his claim that merlin allegedly said bb-p will get included in next T...) and ignoring each sane argument why bb-p is not exactly a candidate for cssu at all. Instead he turns discussion into age old BS where he's defining who got 'authority' in cssu, just to continue with insulting me. If all that doesn't seem to make his arguments fly,
09:28.38DocScrutinizer05<PROTECTED>
09:33.21DocScrutinizer05chem|st: did he answer your request to lend you a N900?
09:34.26DocScrutinizer05probably not, since he likes to ignore any request to actually *contribute* to cssu, rtaher than just ranting and claiming he knows better than those in charge to decide
09:35.09DocScrutinizer05meh, cya
09:36.48DocScrutinizer05actually my suggestion he should simply stop his bitching if he was concerned about motivation of cssu crew was no kidding. I feel like this guy eats way too much time in my life, and that makes me feel bad about cssu work
09:40.07chem|stthanks
09:40.40DocScrutinizer05chem|st: /query me re N900 lending
09:40.56DocScrutinizer05or purchase
09:41.00chem|stDocScrutinizer05: will do
09:41.01DocScrutinizer05whatever you prefer
09:41.17chem|stwill have another try with ebay.de and ebay.us
09:41.48chem|st2 devices I want one I need... if I get two I can give one to my gf
09:46.02DocScrutinizer05chem|st: monitor Bluefon24.de offers. They don't have own website it seems, but frequently offer on ebay, under changing names but finally redirecting to bluefon24
09:46.16DocScrutinizer05their devices are usually good and with warranty
09:48.48kerio"NOKIA N900 Schwarz" for 189,00€
09:48.51keriowhat's that supposed to be?
09:51.50DocScrutinizer05a black N900?
09:52.02keriowhy is there a "NOKIA N900 Black" for like 50€ more
09:52.03DocScrutinizer05sounds like Bluefon
09:52.12keriois that the price for the translation?
09:52.27kerioyeah, yeah, on bluefon24.de
09:55.01DocScrutinizer05my two devices were 250EUR iirc, dunno why the price tag differs that much with same reseller
09:55.55DocScrutinizer05anyway both my devices were in "like new" condition, just missing original packaging and accessories except charger
09:56.32DocScrutinizer05one came with wrong type of battery though ;-D
10:04.02keriomy second n900 was really "like new"
10:06.07merlin1991moin
10:06.22merlin1991anybody care to point me the right pages in bb-p madness thread?
10:06.46keriooh hey, you're back!
10:06.48keriohi!
10:06.51merlin1991for now :D
10:07.06merlin1991I'll be back for real on sunday
10:10.05merlin1991...
10:10.17DocScrutinizer05merlin1991: http://talk.maemo.org/showthread.php?p=1255699#post1255699
10:14.09merlin1991did people on tmo go full retard?
10:14.53Estel_merlin1991, it's all about DocScrutinizer05 popping over there and telling them that busybox-power won't be included, because he doesn't like it ;)
10:15.13Estel_understand it - informational havoc is worst thing for such situations
10:16.02merlin1991I don't know where people got the idea that bb-p is going to be included
10:16.31Estel_we have bb-p that *can't* be distributed properly outside cssu (hackish way of binary replacement via postinst script isn't OK), is maintained constantly over the years. includes upstream bug fixes, etc
10:16.37DocScrutinizer05yeah, and you're doing your best to run havoc against cssu and info we did or did not give
10:16.39Estel_i.e. fullfill all things needed for CSSU
10:16.42merlin1991we had the busybox-power maintainer in here some time ago and discussed possible pitfalls if we update the core busybox package with small changes
10:16.54Estel_wlel, maybe it's because next CSSU announced update of busybox with Pali's fixes for portrait mode?
10:17.23Estel_merlin1991, sure, and logical question arised - why cssu update core busybox with small changes, instead of using busybox-power upstream release
10:17.28Estel_as it's upstream busybox, essentially.
10:17.30DocScrutinizer05no, it's because YOU made that up, another lie you're not getting tired to spread
10:17.46DocScrutinizer05merlin1991 never said bb-p will go into cssu
10:17.56merlin1991we didn't *announce* that, and the target was todo exactly what you said, busybox with Palis 1 liner patch
10:17.59Estel_DocS, can You shut up, please? We're talking here about things that you, apparently, have no idea about, as shown in TMO thread about bb-p
10:18.01Estel_thanks in advance
10:18.16Estel_merlin1991, OK,, understood
10:18.20Estel_so logical question now, again
10:18.23DocScrutinizer052nd warning about getting rude3
10:18.38Estel_if we can update busybox with one liner path for portrait mode support, why can't we merge busybox-p mainstream bugfixes as well?
10:18.46Estel_<PROTECTED>
10:18.47Estel_damn space
10:18.57keriowow, that's not incredibly passive-aggressive at all
10:19.07merlin1991Estel_: mainstream update is not a "bugfix" as is
10:19.09DocScrutinizer05and lie counter counting up, though it's maybe just poor style and not a lie when you state I got no clue
10:19.21Estel_merlin1991, since maemo's ancient version, mainstream busybox got TONS of bugfixes
10:19.23merlin1991err I meant upstream
10:19.25Estel_see busybox changelogs
10:19.50Estel_not to mention that iDon'ts work actually affected upstream too, which we should be proud about.
10:19.51*** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139)
10:20.15DocScrutinizer05merlin1991: better ignore Estel_ just like he ignores me and probably meanwhile chem|st as well, since we have discussed that shit with him ad nauseum already
10:20.21Estel_people are getting really pissed off, by fact that some things are not included into CSSU just because one random guy opposes it in IRc, without merit reasons
10:20.28merlin1991Estel_: can you point me to a bugfix in upstream vs maemo that we *need* ?
10:20.36Estel_busybox power seems to fullfill *all* CSSU criteria requiments
10:20.53Estel_merlin1991, fix for swapon supporting priorities like it should?
10:20.53DocScrutinizer05merlin1991: no he can't
10:20.55keriomerlin1991: swapon priorities could be one, but it depends on what "need" means, in the context of CSSU
10:21.02kerioi mean, it's not a user thing
10:21.02Estel_properly handling shell history for multi-terminal instances?
10:21.27Estel_+ question "do we need upstream bugfixes" is quite ridicolous
10:21.31Estel_do we need portrait mode in cssu?
10:21.44Estel_do we need any bugfixes at all? well, it works out of the box, so why cssu?
10:21.48DocScrutinizer05merlin1991: a user shell is a user domain issue. No need whatsoever to mess with system stuff to fix anything in it
10:22.01Estel_I absolutely understand freemangordon's point of view noews - it's extremely frustrating how CSSu is maintained
10:22.16Estel_it seems to be somewhere in-between bleeding-edge updates (portrait) and LTS only shit
10:22.39DocScrutinizer05if only he'd get proper consequence and start his own cssu project instead of bitching at us
10:23.06Estel_ok, after calming down a little:
10:23.25Estel_merlin1991, the problem is, that process of decidi9ng what wil lgo into cssu and what not is totally misty
10:23.30Estel_not-transparent
10:23.38Estel_and both suers and devs can't expect what to do
10:24.09Estel_results: we have things like freemangordon's (and other devs too, if You talk with them unoficially) doubts if it's worht the effort
10:24.13Estel_worth*
10:24.33*** join/#maemo-ssu iDont (~dennis@j138215.upc-j.chello.nl)
10:24.45Estel_it's ridicolous, if CSSU would be LTs only - in my udnerstanding, LTS is valid only, if You have "normal" updates in-between. LTS "only" is an oxymoron, you can't have every update LTS.
10:24.56Estel_iDont, ncie to see You, we're discussing bb-p, actually :)
10:25.25iDontEstel_, just read the chanlog, though it would be wise to join :P
10:25.35iDonts/though/thought
10:26.00Estel_continuing my thoughts about it - it's completely not understandable why bb-p shouldn't be included in CSSu, as it's:
10:26.08Estel_1. not distributable via extras by normal means...
10:26.10merlin1991Estel_: it's actually quite easy regarding bb-p iDont (afaik) never pushed for it to end up in cssu so the whole question is m00t
10:26.15*** join/#maemo-ssu MrPingu (~chatzilla@86.92.226.97)
10:26.20Estel_( iDont, thanks a lot, it's definitelly good idea :) )
10:26.30Estel_merlin1991, developer need to push something? wtf?
10:26.36Estel_with stick, or shovel?
10:26.41Estel_I would preffer devels actually coding
10:26.50Estel_and CSSu maintainers deciding, what may be good for cSSU to include
10:27.12DocScrutinizer05no, evidently he prefers when HE decides on that
10:27.15merlin1991iDont: I might be wrong here, but I think you never asked for bb-p in cssu?
10:28.05Estel_merlin1991, CSSu isn't british queen, where people need to ask for audience :( many times users - including me - asked for busybox-power in CSSU.
10:28.08Estel_isn't that enough?
10:28.24DocScrutinizer05no
10:28.30Estel_also, iDont already mentioned that busybox-power way of replacing busybox is hackish, and proper replacement would require inclusion in CSSU
10:28.34DocScrutinizer05since users also ask for pink pony
10:28.34merlin1991Estel_: and about "push" we are short on manpower, so we only include things where we have someone who will take care of it in a cssu sense
10:28.40Estel_DocSanyway, lets all shut up and let iDont speak ;)
10:28.59*** join/#maemo-ssu lizardo (lizardo@nat/indt/x-pdmikdrgrcuwjvqy)
10:29.15merlin1991iDont: did you actually ask for bb-p inclusion to cssu?
10:29.22iDontmerlin1991: one sec, searching chanlog. I somewhat did, but that's a very long time ago (before pushing busybox-power to extras-devel), and before CSSU-s
10:29.27Estel_merlin1991, understandable. that's why I mentioned "constantly maintained over the years". I'm sure that iDont would hapilly maintain bb-p in CSSU, if agreed to include.
10:30.11Estel_iDont, but I'm right that binary replacement is hardly "proper" way of distributing it (done as only one alternative for CSSU, that allow easy distribution)?
10:30.28Estel_i.e. that it's same type of things, that CSSU already includes, like QT and others?
10:30.35DocScrutinizer05"mainaining bb-p" means also maintaining all initscripts regarding compatibility to bb-p, in CSSU context
10:30.41iDontEstel_: yes, touching another package's binaries is not how Debian intented package management
10:31.03Estel_DocScrutinizer05, stock maemo's initscripts and cssu ones doesn't have problem with busybox-p
10:31.10DocScrutinizer05and no, it's obviously not same thing, not even same class of thing
10:31.17iDontaargh, searching chanlog of maemo takes a while :(
10:31.18Estel_it's absolutely same class of thing.
10:31.29Estel_iDont, take Your time, no worries
10:32.20Estel_merlin1991 - short of manpower is actually valid argument to. that's why people interested in CSSU - that can't code - are trying to help as "activists" - by highlighting things that are good candidates for CSSU, collecting opinions, checking if arguments are valid, etc...
10:32.49Estel_it's absolutely unbearable how DocScrutinizer05 sabotages such efforts, as self-maintained "maintainer" of cssu integrity, but that's different topic
10:32.54DocScrutinizer05if this guy wouldn't simply answer concerns "X needs attention" with "no, it doesn't, it's OK", his contributions were sometimes a tad usefull
10:33.05Estel_which I would like to touch later, to not waste iDont time reading about
10:33.43Estel_(in context of busybox-power, it was about DocScrutinizer05 using "it's properly distributed via extras, which is WRONG and false, totally - but please, lets put it into later time)
10:33.59DocScrutinizer05pffff
10:34.31merlin1991Estel_: if you want to deal with stuff later bring them up later, this way it's just a slap into $persons face which they are not *allowed* to react on
10:34.33iDontmerlin1991, Estel_, see http://mg.pov.lt/maemo-irclog/%23maemo.2011-04-29.log.html#t2011-04-29T21:48:13, though there wasn't any follow up, and neither did I push for inclusion
10:34.39DocScrutinizer05merTHANKS
10:34.46DocScrutinizer05merlin1991: thanks
10:34.51DocScrutinizer05friggin capslock
10:34.59merlin1991stop pressing it ;)
10:35.08iDontHowever, personally, I would like to see busybox-power in CSSU, though it's not up to me to decide
10:35.21DocScrutinizer05merlin1991: too close to tab
10:36.21iDontI also think we can't really separate the "power" part (i.e. extra features etc) from the upstream part (which I would think suits the CSSU) in busybox-power.
10:36.29DocScrutinizer05iDont: it comes with rootfs penalty, so making it mandatory is depriving those users from their freedom-of-choice who rather keep those 500k in / free than getting power extensions
10:36.33iDontwhich could pose to be a problem, regarding inclusion guidelines
10:37.35Estel_merlin1991, if we care about 500k in rootfs, we should switch to thumb immediatelly, in all cSSU
10:37.39Estel_this argument is pure sophism
10:37.39iDontDocScrutinizer05, I agree. Personally, I don't think 500K is much, but indeed, there is also something as freedom of choice. Also see what I just typed (re the power part), which causes the substantial increase in binary size
10:37.59Estel_OTOH, other than CSSU, how can we distribute busybox-poweR?
10:38.06Estel_as package that replaces binary via script
10:38.14Estel_thinking like that, we could distribute whole CSSU like that
10:38.16Estel_in extras.
10:38.19Estel_iDont, agree?
10:38.26Estel_merlin1991, I hope You see the point.
10:38.35DocScrutinizer05iDont: and, as we already discussed last time we chatted here, busybox is a mission-critical component that should see particularly careful and conservative patches, which need particularly close review and tests
10:38.57Estel_only one argument against busybox-power is 500kb (in fact, less than that) rootfs space, and "compatibility with 3rd party scripts that actually relies on bugs" (sic!), courtesy of DocScrutinizer05
10:39.00Estel_which is pure sophism.
10:39.06iDontEstel_, I agree, but we need to weigh the (dis)advantages of busybox-power vs. messy replacement in postinst
10:39.25merlin1991iDont: actually bb-power could be done in cssu in the planned replacement system, it would conflict with regular busybox and replace it but would be a user choice
10:39.44Estel_iDont, absolutely correct. But, what disadvantages we have here? where busybox-power presents any regressions?
10:40.14keriomerlin1991: provide/conflict doesn't handle dependencies for versions correctly, iirc
10:40.26kerioso you'd have to add busybox | busybox-power to the metapackage and to the other stuff, for instance
10:40.45iDontmerlin1991, but then bb-power would need to depend on CSSU? Also see: http://talk.maemo.org/showpost.php?p=1001182&postcount=12
10:41.06kerioiDont: well, not really
10:41.27keriobut it would break the non-cssu metapackages, and i doubt they'll let you put a package with "Conflicts: busybox" in extras
10:41.31DocScrutinizer05lie counter counting up, I never said "3rd party scripts" (what a bullshit in fact), it's about genuine initscripts, which this guy again either ignores or is too dull to grok
10:43.36merlin1991iDont: well basically it's a question of where you want to see busybox-power, if you want it on *every* device we obviously can't do it via cssu it has to stay in extras then, if you'd like it to be included in cssu we'd probably go with a conflicts: busybox scheme which works fine because the busybox-power package would be in the cssu repo, not in extras
10:46.09iDontmerlin1991, when I started busybox-power, I could either make it only available to CSSU users via a clean way (as you describe), or to everyone via binary replacement. I chose the latter, since CSSU was very new then
10:46.35iDontI'm all for freedom-of-choice, and don't want to force busybox-power on anyone just for the sake of it being widely used
10:46.41iDontor something like that
10:47.01iDontSe basically we need to make the same descision regarding distribution again
10:47.13merlin1991well we could preserve the freedom of choice even within cssu
10:47.58iDontDo you have any figures regarding how widely CSSU is deployed?
10:48.03merlin1991sadly not
10:49.06kerioiDont: well, people interested in unixy stuff won't have problems with it, i hope
10:51.46iDontHmm, I'm thinking all possibilities regarding packaging & distribution over, bear with me please
10:51.59merlin1991iDont: busybox power is your project, we're not going to suddenly include it over your head into cssu because $user wants it there, on the other hand if you wish to see it there we'll use a way to keep freedom of choice
10:52.40merlin1991and also you have all the time in the world to decide I want this in cssu :)
10:53.54chem|stcssu-extras?
10:54.29kerioyou wouldn't even need a separate repo, actually
10:54.54merlin1991chem|st: yep, it's going to arrive (at some point)
10:56.01chem|stmerlin1991: that is what I meant by "give the user a choice and have cssu remain cssu and not a fancy-power-island"
10:56.10keriojust put busybox-power in the repos, but make it Provide and Conflict busybox
10:56.24kerioalthough maybe the metapackage will get confused if you do so? \_o_/
10:56.39iDontkerio, IIRC that would break Nokia's metapackage
10:56.49keriobut not the CSSU one, if we change it
10:57.25iDontyes, but then we would need a split package, i.e. busybox-power and busybox-power-cssu, which I would like to avoid
10:57.38kerioi don't know if that would break things wrt the cssu installation though
10:58.04iDontkerio, that's busybox-power's resposibility (to not break anything) ;)
10:58.55chem|stwe could have cssu-meta call for busybox >= cssu version and you just need to make sure to have your powerversion higher
10:58.58merlin1991iDont: cssu removes the nokia metapackage, so in case you choose to push it into cssu you don't have to worry about that part anymore
10:59.17iDontmerli1991, but that's the whole issue: that would exclude non-cssu users
10:59.20keriochem|st: hm, how does Provides work with stuff like that?
10:59.37merlin1991chem|st: we could simply do cssu-meta depends busyboy >= cssusomething | busybox-power >= somehting
10:59.39keriodoes it take the version of the package with the provision?
10:59.45chem|stiDont: nope you still can provide it as a bin-replacement for non-cssu
10:59.45merlin1991provides is fsckd
11:00.08chem|stmerlin1991: I do not want -power in cssu
11:00.20merlin1991?
11:00.34keriochem|st: wait, why? not even as a reference to a cssu-extras project?
11:00.39chem|stmerlin1991: I want to provide the option to have -power in cssu just installed without dirty hacking
11:00.43iDontchem|st, I don't see how that's possible without a separate busybox package (one that does binary replacement for non-cssu, and one that does a clean install to /bin/busybox, for CSSU)
11:00.44*** join/#maemo-ssu arcean (~arcean@aaeo144.neoplus.adsl.tpnet.pl)
11:01.44chem|stthe one in cssu needs to have a higher index
11:02.16iDontthat might actually work, in the same way as the -thumb version does now
11:02.20*** join/#maemo-ssu ivgalvez (~ivgalvez@89.140.113.138.static.user.ono.com)
11:02.26iDontI haven't thought about that at all
11:02.27chem|sthmm well yes you need two differnt install scripts...
11:02.58iDontthat's not an issue for me, as long as the user only sees one package
11:02.58chem|stuh that reminds me of outdated apt right
11:03.31chem|stif they have cssu installed they see the cssu package as the version is higher than in extras
11:03.37kerionow, upgrading from the old-style to the new-style...
11:03.58chem|stkerio: nope old style stays
11:04.01keriothat could be kinda painful
11:04.19iDontmerlin1991, do you have any ETA on this cssu-extras repository?
11:04.31keriochem|st: yeah but if and when we add the good-form busybox-power with the same name, people with the old-style busybox-power will be prompted to upgrade
11:04.37kerioand the new package will conflict with busybox
11:04.46MrPinguMaybe I am too simple why not pushing busybox with CSSU? I mean bbp is just a upstreamed busybox right?
11:04.54merlin1991iDont: it's not a repository but lives within the cssu repo, and nope no eta
11:04.55kerioMrPingu: oh you
11:05.08iDontmerlin1991, doh, of course
11:05.09MrPinguKerio: Hi :)
11:05.12chem|stnope, as long as the cssu version of bb and bb-p are higher than bb-nokia bb-p
11:05.20kerioiDont: well, for instance busybox-power is already a package in the community-thumb repository
11:05.39iDontkerio, yes :). I completely forgot about the same mechanism for CSSU
11:05.44chem|stkerio: that does not harm does it?
11:05.52keriochem|st: nope, it's completely unrelated
11:05.59keriobut it *can* be unrelated, it's just the same as extras
11:06.22chem|stkerio: they get prompted for an upgrade that does only provide the right package structure
11:06.23kerioif eventually we decide to make it conflict with busybox, stuff could break wrt metapackage
11:06.26iDontkerio, re upgrading from old busybox-power to cssu busybox-power: busybox-power uninstalls cleanly, so that won't pose to be an issue ;)
11:06.46kerioiDont: yeah but it's uninstalled together with busybox (nokia)
11:06.58keriomeh, i suppose that it would work
11:07.04chem|stkerio: the cssu version will conflict... the extras version not
11:07.26chem|stiDont: would that be suitable for you?
11:07.27keriobb-p uninstalls, puts old /bin/busybox back, then bb uninstalls, then bb-p new is installed
11:08.04iDontchem|st, most certainly :)
11:08.33iDontI am and always was for freedom-of-choice. I just didn't see a alternative to inclusion in CSSU until now
11:08.43chem|stkerio: bb-p from extras gets a break for cssu installer...
11:08.43iDontan alternative*
11:09.26chem|stand I sidenote
11:09.26DocScrutinizer05btw just for a tiny bit of self-glorification (to counteract this constant "Doc's not contributing" BS): it's been me who suggested/pushed cssu-s, it's been me who 'invented' optional packages in CSSU
11:09.42keriochem|st: a break?
11:10.03chem|stDocScrutinizer05: we know... captain obviouse ;)
11:10.03keriosorry, i can't parse what you just wrote
11:10.09chem|stkerio: sry
11:10.16DocScrutinizer05not all know that,  obviously
11:10.34keriochem|st: oh, you mean that it would be uninstalled by community-ssu-installer?
11:10.41DocScrutinizer05there's at least one guy who's constantly insulting me on the basis he never realized it
11:11.23chem|stkerio: cssu installer will install new package of bb, then there will be an upgrade available for bb-p
11:11.36chem|stuh that will brake
11:11.49chem|stiDont: uninstall overwrites bb right
11:11.51chem|stagain
11:12.05keriochem|st: yeah but it gets upgraded right afterwards
11:12.07kerioso it's no big deal
11:12.16iDontchem|st, yes. Everything is restored to pre-bbpower situation
11:12.23keriobesides, uninstall only changes /bin/busybox if it matches the checksum
11:12.30kerioif it's been changed, it's left alone
11:12.51chem|stbut there is no pre bb-p situatiuon after installing cssu
11:13.01chem|stah ok
11:13.04chem|stgood
11:13.24merlin1991chem|st: you also have to think of the update where we introduce anything bb-p realted
11:13.55merlin1991cssu is "installed" at that point so you do have a situations of bb-p after installing cssu
11:14.16chem|stmerlin1991: yes I know
11:14.20chem|stmerlin1991: one at a time
11:14.30iDontDocScrutinizer05, well, personally I agree with Estel_. I do think busybox-power would be a good fit for the CSSU. The main counter argument is theoretical breakage, which hasn't been experienced during busybox-power's lifetime. However, I do think that an optional package is always preffered. I just didn't see any way to achieve the latter until now :)
11:14.51chem|stmerlin1991: I was thinking of new installation of cssu first - then upgrading
11:14.52iDontpreferred*
11:15.26iDontAnyway, we got ourselves a solution now, so we can leave this discussion behind :)
11:15.38Estel_iDont, that's why I was "advocating" busybox-power for CSSU, considering that devs have better thing to do than "lobbying", even for good case.
11:15.56chem|stthe same thing will happen to cameraUI and other shit
11:16.08iDontEstel_, appreciated, though probably not by all ;p
11:16.12chem|stDocScrutinizer05: those ussd stuff patches you were talking about
11:16.57chem|st*# things
11:16.59kerioand the fukken cbsms widged
11:17.01MrPinguI didn't understand that :P I thought: CSSU includes upstreamed busybox -> Done
11:17.06chem|stkerio: +1
11:17.07merlin1991iDont: I'm not sure which solution you mean :D
11:17.28Estel_it's ridicolous, that package need to be "advocated" toget into cssu, BTW, but that's different thing
11:17.46Estel_MrPingu - busybox-power is upstream busybox
11:18.01Estel_problem is that some people in CSSU seems to have philosophical problems about "do we need updates at all?"
11:18.13MrPinguEstel_: I am talking about buxybox including in CSSU
11:18.14iDontmerlin1991, including a busybox-power variant in CSSU as optional package, in contrast to a completely separate busybox-power-cssu package
11:18.22Estel_OTOh, people like DocScrutinizer05 are trying to put CSSU into stagnated, LTS-only (oxymoron!) thing
11:18.29Estel_MrPingu, same here ;)
11:18.55chem|stEstel_: when you keep talking BS like this you will loose your space in this channel...
11:19.03MrPinguEstel_: My thoughts were,
11:19.16DocScrutinizer05no, it's Estel_ who tries to transform cssu into bleeding-edge for the packages *he* prefers
11:19.18MrPinguEstel_: Why was that oxymoron part needed, really?
11:19.23Estel_merlin1991, why the hell some things - like portrait support - enter cssu without problems, and some other - essential, clean, and well tested, not distributable via "normal" extras-means - just like busybox-power -have so much trouble doing so?>
11:19.36Estel_MrPingu, was needed, as there is no such thing as LTS only
11:19.44Estel_LTS by definition is release *between* normal releases
11:19.58Estel_there is no such thing as LTS only, but DocScrutinizer05 openyl advocated CSSU becoming one. thats why it's oxymoron.
11:20.28Estel_LTS only means "stagnation", just with prettier name. LTS, by definition, means to be stable "anchor" between more experimental features. Later, those features enter another LTS.
11:20.34Estel_aka long-term-support
11:20.35chem|stEstel_: enough!
11:20.36MrPinguEstel_: IMO it wasn't neeeded to, I mean the message is clear even without oxymoron...
11:20.42Estel_why someone want project to become LTs-only is beyond me
11:20.46merlin1991Estel_: that's easy to answer, because it was people inside cssu doing portrait
11:20.52Estel_MrPingu, not for everyone, as it seems :P
11:21.06MrPinguEstel_: It only makes people angry on you...
11:21.06Estel_thats why freemangordon is thinking if CSSU is worth effort at all, IMO
11:21.25Estel_merlin1991, so put iDont "inside" CSSU as busybox-power maintainer
11:21.29Estel_problem solved
11:21.38Estel_after all, no one in CSSU is maintaining everything
11:21.50Estel_and IIRC, iDont said aloready dozens of times, that he would hapilly maintain busybox-power for CSSU
11:22.06chem|stEstel_: we just made clear how it is going to happen now you come and want it in another way
11:22.08DocScrutinizer05[2012-08-31 13:08:33] <iDont> I am and always was for freedom-of-choice. I just didn't see a alternative to inclusion in CSSU until now
11:22.52Estel_if there is viable alternative to including busybox-power in CSSU, that don't require dirty hacks like binary replacement in posinst, I'm all for it.
11:22.54MrPinguAnway what I wanted to say (don't shoot me, just my thoughts):
11:22.55Estel_it's CSSU loss, after all
11:23.18DocScrutinizer05stop suffering *OUR* headaches!
11:23.22Estel_if only for the reason, that people like me won't need to be frustrated by how CSSU is maintained in long-term :P
11:23.23MrPinguJust put busybox with higher version number in CSSU repo and upgrade seems fine, doesn't it?
11:23.42iDontMrPingu, yes, that's what we're going to do
11:23.43MrPinguOfcourse that doesn't give users a choice
11:23.57chem|stEstel_: topic is over! bb-p will find its place in cssu-extras... how that is going to happen is not on your call
11:23.58*** join/#maemo-ssu andre__ (~andre@ip-89-176-24-140.net.upcbroadband.cz)
11:23.58*** join/#maemo-ssu andre__ (~andre@Maemo/community/bugmaster/andre)
11:24.06iDontMrPingu, CSSU will depend on either busybox or busybox-power, so that would give the user freedom of coise
11:24.10Estel_chem|st, fine, so go away now and let us talk :)
11:24.29Estel_as we're not even sure if cssu-extras will *ever* happen.
11:24.29DocScrutinizer05chem|st: that's again a ban'able insult
11:24.42DocScrutinizer05in my book
11:24.48MrPinguEstel_: That go away part wasn't needed
11:25.22MrPinguEstel_: Don't get angry on me but you say mean things that aren't needed to get the message past
11:25.36Estel_DocScrutinizer05, so ban me, and stop boring, ok? I'm really tired of Your pathetic, childish behavior with all those "Imma powerful chanop, phe4r me!" idiotic threats. I swear, that it's last time I reffer to it in any way, as it's not even worth lifting single finger.
11:25.40DocScrutinizer05this guy is trolling every single day for last weeks err months, and using up our time we better spent discussing real stuff
11:26.02*** mode/#maemo-ssu [+o merlin1991] by ChanServ
11:26.06*** kick/#maemo-ssu [Estel_!~merlin@Maemo/community/cssu/merlin1991] by merlin1991 (Der Kindergarten ist woanders!)
11:26.19*** join/#maemo-ssu arcean_ (~arcean@aaeo144.neoplus.adsl.tpnet.pl)
11:26.21keriowoanders?
11:26.22*** mode/#maemo-ssu [-o merlin1991] by ChanServ
11:26.24ivgalvezbadabum
11:26.28chem|stanother place
11:26.29merlin1991auto kick msg of quassel
11:26.39MrPinguwoanders -> Somewhere else ;)
11:26.40keriomeh, it fits
11:27.45iDontmerlin1991, to wrap things up on a high level: 1) CSSU metapackage will depend on either busybox or busybox-power 2) I'll create a new , separate busybox-power package for CSSU repo *the way it should have been (i.e. no dirty tricks)* 3) regular busybox-power will remain in maemo's extras for non-cssu users
11:27.56MrPinguiDont: Let's say I have install CSSU-Testing will that mean I get automatically an updated busybox?
11:27.58iDontmerlin1991, ack?
11:28.21ivgalveziDont that sounds great
11:28.30merlin1991iDont: ack, but for sake of always having proper busybox-power in cssu we have to use a slightly higher verions in cssu ie +proper or whatever :)
11:28.34kerioMrPingu: yes-ish - on the next busybox-power upgrade you'll be prompted (by apt?) to uninstall busybox due to a conflict
11:28.58merlin1991MrPingu: no won't
11:28.59keriomerlin1991: hm, isn't + for stuff outside of the version number?
11:29.13kerioMrPingu: that is, if you have busybox-power already
11:29.38iDontMrPingu, yes, the end-user won't notice any difference versus the old situation ;)
11:29.42chem|stkerio: no
11:30.08MrPinguYou guys are confusing me
11:30.13chem|stkerio: well yes... (need to read all lines...)
11:30.14iDontmerlin1991, yes, I'll make sure that the cssu variant will have a modified version string
11:30.27chem|stMrPingu: you won't get bb-p by default on cssu
11:30.51*** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139)
11:30.55MrPinguI see
11:31.02kerioiDont: hm, this thing with the names is full of possible pitfalls
11:31.05chem|stif you had bb-p installed you will be prompted for an upgrade
11:31.34iDontkerio, what are your concerns?
11:32.02keriobb-p-extras and bb-p-cssu are upgraded together, but updating from one of the repos fails
11:32.11kerioand a cssu user ends up with the extras version for a bit
11:32.18kerioit's not fatal by any means, mind you
11:32.20keriobut it's boring
11:32.30chem|stkerio: ?
11:32.47keriochem|st: extras will have a package called busybox-power too
11:32.51iDontkerio, there will be only one busybox-power package, but there will be two seperate versions of it. The CSSU version will have higher priority over the regular package for non cssu users
11:33.07iDontYou can't have non-cssu version and cssu version installed at the same time
11:33.19kerioiDont: yeah but you have to make sure that cssu users' apts will be constantly aware of that
11:33.19chem|stkerio: extras-testing has one extras-devel has one so what?
11:34.07*** join/#maemo-ssu arcean (~Arcean@aaeo144.neoplus.adsl.tpnet.pl)
11:34.14chem|stkerio: apt-get update?
11:34.43chem|stI don't get your concern it does not matter if bbp from extras is installed
11:34.56DocScrutinizer05kerio: that's what merlin1991's pending work about cssu-ham and optional pkgs is all about
11:35.56chem|stif cssu is installed there is the cssu repo with a newer version that will uninstall the hacky one and install a proper bb replacement
11:36.30iDontkerio, think of the -thumb situation. Didn't bb-power's thumb version got installed as an upgrade over the non-thumb version a few days ago, even though it was the same version (minus the -thumb part)?
11:36.52iDontCSSU busybox-power > extras busybox-power
11:37.09kerioiDont: well, that's a good example actually
11:37.15kerioyou released an update a few days ago, right?
11:37.23iDontYes
11:37.23keriofreemangordon didn't immediately release that one too
11:37.35kerioand my apt prompted me to install the one from extras-devel
11:37.40kerioi mean, it's not a big deal
11:37.46keriobut it can happen if the versions aren't in sync
11:38.17kerio(then, when he released the same update too, it prompted me to upgrade to *that* version - the same, but with -thumb0)
11:38.38iDontkerio, that's a very good point indeed. We'll have to make sure CSSU version get's updated _before_ extras' version
11:38.54iDontluckily, that's entirely in our control :)
11:39.52kerioheh, it's the same server, too
12:33.55freemangordonwell, what worries me, is the time frame in which "cssu-extras" will be available
12:34.36freemangordontalking started few months ago, but I am not aware of any progress
12:36.10freemangordonmerlin1991: so the question about estimated time is pretty reasonable, it does not make sense iDont to write a pile of install scripts if we expect cssu-extras by june 2013 :P
12:37.45freemangordonmerlin1991, chem|st: Why obexd and stuff are allowed to enter CSSU(not cssu-extras), but busybox is not?
12:37.57iDontfreemangordon, I thought busybox-power would live in relevant cssu repositories, just like busybox-power lives in cssu-thumb?
12:38.01iDont<merlin1991> iDont: it's not a repository but lives within the cssu repo, and nope no eta
12:38.46freemangordoniDont: we need updated HAM in order it to work as planned, otherwise you (or me) should use apt-get to install
12:39.13freemangordonbut CSSU's official installer is HAM, not apt-get ;)
12:39.38keriofreemangordon: why?
12:39.45keriobusybox-power would just be a package
12:39.51kerioand it's already installable via HAM
12:39.51*** part/#maemo-ssu merlin1991 (~merlin@Maemo/community/cssu/merlin1991)
12:40.01*** join/#maemo-ssu merlin1991 (~merlin@Maemo/community/cssu/merlin1991)
12:40.04merlin1991ffs
12:40.09iDontheh
12:40.09freemangordonmerlin1991: hi
12:40.12keriomerlin1991: chat comfortably! anywhere!
12:40.17iDont:-D
12:40.39merlin1991kerio: it would use conflict: something which in ham only throws the use pc-suite to update error
12:40.48keriooic
12:40.56kerio...well, that would've been nicer to know earlier :/
12:41.16keriomeh, i'm perfectly fine with requiring people to install busybox-power with apt
12:41.25kerioi mean, it's a fucking shell anyway
12:41.55freemangordonkerio: that is not how it should be
12:42.12keriowhy not? plenty of packages don't even appear in HAM anyway
12:42.19kerioand i really don't see another way
12:42.21iDontkerio, I'm not, my priorities include not to exclude anyone from using it. Although I prefer apt-get > HAM as well
12:42.23kerioapart from using a separate installer
12:42.25*** join/#maemo-ssu MrPingu (~chatzilla@86.92.226.97)
12:42.48freemangordonkerio: because you (and me) have no clue what is the user base
12:42.49freemangordon;)
12:42.56keriofreemangordon: one could argue that that behaviour in HAM is a bug
12:43.05keriobecause what the fuck were they thinking, really
12:43.06kerio:s
12:43.20kerioeven **cydia** handles those more gracefully
12:43.45freemangordonirrelevan, we can't tell CSSU users to use apt-get
12:43.54freemangordonirrelevant even
12:45.09MrPinguiDont: Did you manage to fix that bug in bb-p hxka pointed out?
12:45.25freemangordonis afk for a cigarette
12:46.41iDontMrPingu, yes, but I need to test my patch more extensively
12:47.29MrPinguGoed :)
12:48.43iDontOnly problem is, that signal handling is a touchy area in shells, and I haven't got any real experience in that area. So therefore the extensive tests (although the patch is relatively small)
12:49.18MrPinguI see :)
12:52.11iDontfreemangordon, merlin1991, if I could get any follow up on (the ETA of) cssu-extras, that would be great. No rush though, as the current way of distributing busybox-power does the job fine, dirty or not
12:53.31merlin1991iDont: I'll let you know as soon as I have anything
12:53.43freemangordonchem|st, merlin1991: I'll rephrase my question - according to what criteria upstream versions of obexd, curl, dosfstools, etc., etc., are good for CSSU, bu upstream version of busybox is not?
12:54.12merlin1991somebody there who's doing the job :D
12:54.33merlin1991till now I didn't see much intention from iDont to get busybox into cssu
12:55.03freemangordoniDont: correct?
12:55.04merlin1991ah you mean why still doing it optional?
12:55.11keriofreemangordon: well, bb-p *adds* a lot of stuff
12:55.20freemangordonkerio: curl too
12:55.38freemangordonNFC for obexd, but almost sure it adds lots of stuff too
12:56.21iDontwell, personally I do like to see busybox-power in CSSU. However, I think optional installation is better regarding freedom of choice. Especially since inclusion seems to be so highly controversial
12:56.50freemangordonyeah, controversial :D
12:57.12freemangordonmerlin1991: yes, that was my point.
12:57.15keriooh right, obexd adds a bunch of stuff wrt car integration, right?
12:57.40freemangordonand curl adds only luf knows what :)
12:58.08merlin1991well curl / obexd are not that important core system component though
12:58.29freemangordoncurl no core component? try to remove it :P
12:58.39merlin1991true though that the why and how is hard to argue
12:59.55MrPinguActually I agree with freemangordon, if bb-p is good why not include it the simple way?
13:00.18freemangordonmerlin1991: we cannot act based on personal preferences though
13:00.28merlin1991afk, lunch
13:01.09kerioMrPingu: because there's no reason to
13:01.13keriomuch like cbsms-widget
13:01.16freemangordonenjoy your meal, gather some power and come back :P
13:01.26kerioalthough that's a bit different, because it's FUCKING BROKEN AS HELL
13:01.31MrPingubut cbsms has been included...
13:01.38keriowhile busybox-power has no known regressions, apart from that minor one
13:01.41kerioMrPingu: in testing
13:01.55kerioand it'll be removed once cssu finds a process to include optional packages
13:01.55freemangordonkerio: and what is the reason for obexd and curl then?
13:01.59keriofreemangordon: beats me
13:02.31MrPinguYeah but I guess we are always talking about testing? I mean it won't go directly to stable without testing ;)
13:03.11MrPingufreemangordon: completed my argumentation ;)
13:03.33freemangordonsee, we should apply the same criteria for all of the packages, fuzzy evaluations like "core system component" are meaningless
13:03.58freemangordonbut i'd rather wait merlin1991 back
13:04.43keriofreemangordon: but busybox-power has "power" in its name!
13:05.59freemangordoniDont: I just need straight answer if you want upstream busybox in CSSU or not, i.e. will you maintain it. Forget about freedom of choice for a while :P
13:06.46freemangordonkerio: well, we'll change it to busybox-weakness if needed :P
13:07.02chem|stfreemangordon: what are you arguing?
13:07.35freemangordonchem|st: I am trying to find what is the criteria for package inclusion in CSSU, see may question above
13:07.38chem|stfreemangordon: if you want something in cssu that needs bbp then depend on it!
13:08.14iDontIf CSSU's scope clearly states that upstream components are a valid reason for inclusion in CSSU, then yes, because I'll have a valid argument for inclusion then.
13:08.20iDont^freemangordon
13:08.38freemangordonchem|st: what in CSSU depends on obexd and curl?
13:08.50freemangordon(upstream versions)
13:08.59chem|stdoes it add mission critical things? nope
13:09.15chem|stfreemangordon: libcurl?! facebooklogin
13:09.28freemangordonchem|st: yes, but why upstream?
13:10.00chem|stfreemangordon: cause that was the one working?!
13:10.23iDontBut even if upstream versions would be a valid reason, what about the -power part in busybox-power? Will that part be preserved (e.g. the extra features vs. stock BusyBox)? I prefer not create a *new* busybox-power if upstream busybox would be included in CSSU, but without power features
13:10.39chem|stiirc it was looking for a version that has the patch and is working...
13:10.44freemangordonwrong, what is in CSSU is -26, the one we tried was 25
13:10.59freemangordon(iirc)
13:11.20freemangordonand what about obexd? what is ther system critical functionality it adds?
13:11.25chem|stwhoohou 25-26 is what sorry I am so bad in math "1"?
13:11.57merlin1991freemangordon: the problem with busybox-power is what iDont said, which modules do we compile if we include upstream code?
13:12.15chem|stfreemangordon: you start like estel now?!
13:12.28merlin1991updated obexd has better support for car kits, simple as that
13:12.37freemangordonchem|st: curl (7.26.0-1maemo1+0cssu1) unstable; urgency=high
13:12.40merlin1991regarding curl, yeah that's vague
13:12.50freemangordonchem|st: naah, dont do that
13:12.55chem|stfreemangordon: ;)
13:13.28merlin1991but usually upstream should be ok, only in case of ie busybox we have the problem of the all in one which yields the question which parts do we really want?
13:13.54chem|stfreemangordon: not the upstream fact is slowing the progress... the bare fact that it is compiled with more options
13:13.58freemangordonmerlin1991: well, i might be wrong (or simply misunderstood something), but it was told that busybox-power is actually upstream busybox
13:14.08kerio"screw you guys, i'll start my own cssu! with busybox and hookers! in fact, forget cssu and busybox!"
13:14.09freemangordonmerlin1991: we had the same for curl iirc
13:14.20keriofreemangordon: busybox is heavily configurable at compile-time
13:14.25kerioto include or exclude modules
13:14.28merlin1991+ nokia patches, yeah but only that busybox has a basillion switches for ./configure
13:14.30freemangordonkerio: ^^^
13:14.41chem|stfreemangordon: nope bbp is upstream + lots of functions activated
13:14.54freemangordonchem|st: aah, ok, my bad then
13:15.11freemangordonthen we should remove obexd too
13:15.19merlin1991ie less is disabled in stock busybox
13:15.56freemangordonas obexd adds carkti supprt, which does not exists in stock obexd
13:16.12merlin1991well it is there, somehow, mostly broken
13:16.15chem|stfreemangordon: stop trolling!
13:16.19merlin1991it even works with *some* car kits
13:16.28freemangordonchem|st: what?
13:16.46chem|st"remove this and that" it is in there now live with it
13:17.07merlin1991guys can we get back to ground zero?
13:17.13chem|stplease
13:17.50chem|stmerlin1991: monday evening ok with you?
13:17.59freemangordonwell, I could ban myself easily, no need someone to do it
13:18.00chem|stmerlin1991: I will be off all weekend
13:18.03*** part/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net)
13:18.24merlin1991jesus, has everyone gone mental today?
13:18.31chem|styes
13:18.36merlin1991chem|st: should be ok
13:19.48iDontfreemangordon, if you're interested, check the OP of busybox-power's thread at TMO. It lists all new applets (tiny implementations of various tools) it introduces vs. the stock busybox package. Besides new applets, it also extends functionality of existing applets (e.g. Ctrl-R reverse history search in shell, swapon with priorities support, and _lots_ more)
13:20.04kerioiDont: he left
13:20.14iDontkerio, woops, missed that
13:20.18keriohe quit irc :s
13:20.21iDontbrb
13:20.24merlin1991just for the record I was actually more talking to chem|st regarding gorund zero
13:21.17kerioground zero?
13:21.54chem|st?
13:21.56merlin1991calm state, common ground, no insulting madness, whatever you wanna call it
13:22.06kerioweed land
13:22.08kerio:D
13:50.43*** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net)
13:51.46freemangordonmerlin1991: just for the record - I did not quit because your "ground zero" :)
13:52.23chem|stfreemangordon: I'm sorry, estel gave me a hard time today...
13:52.55*** join/#maemo-ssu arcean_ (~Arcean@aael108.neoplus.adsl.tpnet.pl)
13:53.00freemangordonchem|st: np, I am calm, just keep it in mind I am not Estel ;)
13:53.21chem|stfreemangordon: just stop barking about why things ended up being in cssu, they are there now, so it be
13:54.10chem|stI am pretty sure everything needed will get to cssu
13:54.33MrPinguchem|st: I believe it's more  like: why are these CSSU why BB-p can't be?
13:54.35chem|stfreedom of choice might be a pain in the ass in the ned
13:54.47chem|stend
13:54.50freemangordonchem|st: my point was regarding bb inclusion, I was trying to make an argument, that acording to the criteria applied to those packages, bb should be included too
13:55.19freemangordonI am the last one to ask for package to be removed from CSSU :)
13:56.04chem|stfreemangordon: we talked that through now... bb will get upgraded and shipped with but bb-power will be optional iirc
13:56.08kerioi am the first! remove cbsms!
13:56.34chem|stkerio: that brought the whole story of cssu-extras to my attention
13:57.27freemangordonchem|st: bb will get upgraded to upstream and compiled with the same options as stock? I am absolutely ok if that is the case.
13:57.32chem|stso if there will be something rolling into cssu which needs bb-power it is there without hacky binery overwriting
13:57.44iDontchem|st, I actually missed the part that busybox will get upgraded and shipped
13:58.06freemangordonyep, me too :)
13:58.24MrPinguAnd this makes 3
13:58.28chem|stah ok no that was my idea behind it, strap out the power
13:58.56freemangordonI knew it is because of the -power thing :D
13:58.57chem|stupstream is ok if it is working fine but keep the bloat to a minimum
13:59.14chem|stit is not the name^^
13:59.23freemangordoni know :)
13:59.27chem|st;)
13:59.55chem|stbut what is the difference between upstream and current?
14:00.16chem|stfirst of all, would it be smaller?
14:00.19chem|stfaster?
14:00.21freemangordoncurrent == stock?
14:00.44chem|stI love the "never change a running system"
14:00.46MrPinguhttp://www.busybox.net/
14:01.06MrPinguscroll down till you see v1.10 :P
14:01.37freemangordonchem|st: don't know if you are aware, but libcurl in CSSU is around 280k bigger than stock
14:01.56freemangordonwhich about 100% increase
14:03.07chem|stI know
14:03.12freemangordon(iirc)
14:03.57chem|stok some critical stuff I just see by scrolling the first 5 versions
14:04.26chem|stit is growing bigger
14:04.43chem|stiDont: would you mind to provide two versions?
14:04.47freemangordoniDont: I will check on the thread what are the additional modules included (i.e. -power stuff :) )
14:05.40MrPinguchem|st: that list will become big :P
14:05.47keriofreemangordon: btw, the thumbified busybox-power is just 300k bigger than the stock arm busybox :D
14:05.58chem|stwell np I guess it is the same source but different compiler flags + different version strings..
14:06.29iDontchem|st, I don't mind, but is there any real interest in an updated BusyBox shell without power features? AFAIK most busybox-power users install busybox-power for its power features
14:07.08chem|stiDont: I am speaking of a cssu without power version
14:07.23chem|stnevermind
14:07.40freemangordonchem|st: well, if it does not bring harm, why not enable them?
14:07.53MrPingufreemangordon: you were faster
14:08.02chem|stspace?
14:08.05keriofreemangordon: because mo money mo problems
14:08.28chem|stand less features means less bugs
14:08.52iDontThere used to be two busybox-power versions: one with Nokia's config, and one with an enhanced config. The first was dropped because of a lack of interest. However, this was in mid-2011.
14:08.55MrPinguSome things like colored ls, is nice to have enabled in CSSU version too ver example
14:09.13freemangordonchem|st: yeah, I see the rationale, that is why I said i will check the additional modules
14:09.21chem|st+1
14:10.10freemangordonchem|st: though 500k is not that much.
14:10.24chem|stthe smaller the better, if we get some stuff rolling like "enhancements" people are used to but do not bloat it fine
14:10.45merlin1991freemangordon: imo we should check what changes libcurl has
14:10.46freemangordoniDont: any chance to split it to /root /opt? or it is a single binary?
14:10.46chem|stfreemangordon: take 10 programs that way and you have 5000k
14:10.55merlin1991because as you said the size increase is huge
14:11.05keriochem|st: so? 5mb is not a lot either :)
14:11.22freemangordonmerlin1991: I asked luf, and iirc he explained there are dependecnies
14:11.24iDontfreemangordon, single binary at the moment
14:11.30chem|stkerio: on my 3TB / at home yes...
14:11.37keriochem|st: i have like 40mb free on /
14:11.40freemangordoniDont: any chance to split it?
14:11.46kerioand that's a very strict estimate
14:11.56iDontfreemangordon, that's most certainly possible
14:11.59kerio(ubifs expands as needed, i only have 228mb used or something)
14:11.59MrPinguI used to have 70mb free on /
14:12.07chem|stkerio: and you need how much to do an upgrade?
14:12.11keriobeats me
14:12.18kerioincremental upgrades? not much
14:12.21kerio:D
14:12.39kerioi mean, the only big thing that i installed on / is gcc+libc6-dev+dependencies
14:13.14chem|stso now you have 30MB left and we have a look at some other stuff not being /optificationable
14:13.15freemangordoniDont: I think if it is possible to split it in such a way, that in rootfs to be the only things really needed for boot and the rest to stay in /opt, that would make everyone happy
14:13.37freemangordonchem|st: agree?
14:13.42chem|stfreemangordon: that will brake startup stuff
14:13.50freemangordonchem|st: read again :P
14:14.00freemangordon(and excuse my english)
14:14.18DocScrutinizer05freemangordon: busybox needs to stay in rootfs, needed during early boot. That's the main 8though not only) reason we don't want to make bb-p mandatory
14:14.18chem|stfreemangordon: some waky people might like to do waky stuff while booting that it is -power!
14:14.43iDontfreemangordon, yes, then we'll have to include two config files in the packaging and compile two separate binaries, I suppose
14:15.09chem|stwe build it twice one is cssu (stock config) one is cssu-power
14:15.29DocScrutinizer05freemangordon: and whole point of busybox is it's a monolithic binary
14:15.41DocScrutinizer05chem|st: ++
14:16.00freemangordonDocScrutinizer05: yes, I know, I am trying to find a way to make everyone happy :)
14:16.11DocScrutinizer05we all do ;-D
14:16.19chem|sthave a nice weekend!
14:16.25freemangordonchem|st: bb
14:16.30DocScrutinizer05well, you too chem|st
14:16.35chem|sthits the road
14:16.43*** join/#maemo-ssu ivgalvez (~quassel@41.pool85-49-220.dynamic.orange.es)
14:16.45DocScrutinizer05celebrates vacancy
14:17.14DocScrutinizer05duck and cover, now I got 24/7 time for maemo ;-P
14:17.18keriowell, the whole point of busybox is also not to execute a bunch of processes in shell scripts
14:17.46DocScrutinizer05kerio: that's secondary at best
14:18.11freemangordonDocScrutinizer05: the point was - we could have only one package, which includes two binaries, one of them stays in rootfs (with the essentials needed for boot), the second lives in /opt
14:18.19DocScrutinizer05the obvious main rationale for busybox been that Nokia tried to conserve as much space in rootfs as possible
14:18.41kerioand we should try to honour that!
14:18.45kerioby enabling thumb binaries!
14:18.49kerioflees
14:18.50freemangordonhehe
14:19.06ivgalvezjuas
14:19.27DocScrutinizer05freemangordon: you (maintainer of bb) could turn it into anything renamed from original busybox name, and keep it in /opt like any other *suer* shell
14:19.31DocScrutinizer05*user*
14:19.53kerioDocScrutinizer05: i thought the rationale for busybox was that it was used in diablo and then hysterical raisins and then why bother changing
14:19.59keriodiablo and before, i mean
14:20.14DocScrutinizer05maybe that too :-P
14:20.36DocScrutinizer05loves hysterical raisins
14:21.26freemangordonDocScrutinizer05: there was a link with changes between stock version and upstream, see chem|st's comment on it:
14:21.28freemangordon17:02 <chem|st> ok some critical stuff I just see by scrolling the first 5 versions
14:21.29freemangordon<chem|st> it is growing bigger
14:21.58keriooh lol
14:22.15freemangordonDocScrutinizer05: so lets end that, ok? :)
14:22.42DocScrutinizer05freemangordon: I'd not deny benefit of getting bugfixes to busybox, esp if they are system critical. But I question sane rationale behind including power extensions
14:22.55freemangordonDocScrutinizer05: chem|st proposed 2 packages, I am trying to reduce that to 1
14:23.01DocScrutinizer05good
14:23.10freemangordonwithout using precious rootfs space
14:23.22DocScrutinizer05the less the better, it needs very close review since busybox is mission critical
14:23.42freemangordonbut of course
14:24.16DocScrutinizer05isn't it strange how even freemangordon and me could agree on something easily, as long as estel isn't bitching on stuff he doesn't completely understand
14:25.02kerioiDont: did you *disable* something from the upstream busybox?
14:25.17freemangordoniDont: so, I think if you manage to strip -power part in /opt, we can have only 1 package
14:25.42iDontkerio: only if it conflicted with Nokia's configuration
14:25.47keriok
14:26.14iDontfreemangordon, I could give that a shot, I see no reason why that wouldn't work
14:26.31keriofreemangordon: hm, so you have a stock-ish /bin/busybox with the usual commands there, and then /opt/busybox-power/busybox-power that's symlinked from all the other commands?
14:26.44freemangordonthough chem|st has his point for those who may want to use some of the -power functionality in early boot
14:26.56keriofreemangordon: well, how early?
14:27.09freemangordonkerio: ask chem|st, not me :D
14:27.10kerioswapon priority would have to be compiled in /bin/busybox, for instance
14:27.40iDontfreemangordon, yes, for example Mentalist Tracuer's recovery console relies on some of busybox-power's power features
14:27.43DocScrutinizer05please keep in mind this whole annoying issue with initscripts depending on this very particular version of busybox cmd syntax *and* output, and semantic
14:28.11DocScrutinizer05the stuff that estel misquoted as "3rd party scripts" all the time
14:28.16kerioDocScrutinizer05: we've got more than a year of testing with busybox-power, though
14:28.29iDontfreemangordon, however, there are also a lot of applets that most certainly won't be used at boot (e.g. httpd)
14:28.30kerionon-rigorous testing, but still
14:29.03freemangordoniDont: you can include know stuff in /rootfs bb, I think there would be no onjections for 100-150k size increase
14:29.18freemangordons/know/known/
14:29.27freemangordonDocScrutinizer05: agree?
14:29.30DocScrutinizer05kerio: this is very core mission critical stuff, you better have rigorous testing for every single possible case/branch
14:30.07DocScrutinizer05100k maybe on the tolerable side still, for the benefit to finally close this ticket
14:30.13freemangordonyeah
14:30.17keriohahaha
14:30.50DocScrutinizer05but no way to shorcut proper tests and review for any changes in cmd syntax, semantic, output
14:31.05DocScrutinizer05of any of the already existing cmds
14:31.17keriobut...
14:31.23keriostuff still works! :c
14:31.59DocScrutinizer05orly? you tested with unformatted uSD? with 911 calls? with devicelock entere3d 3 times in sequence wrong? etc pp?
14:32.06freemangordoniDont: ok, now we only need merlin1991 to confirm he is ok (though I think he will be)
14:32.21freemangordonDocScrutinizer05: come on man, that is why testing is
14:32.34DocScrutinizer05kerio: "WFM" never is any near a proper test/review
14:32.35keriohm, would locking the device require nokia care?
14:33.04ivgalvezDocScrutinizer05 I seriously doubt Nokia did such tests to N900
14:33.05kerioDocScrutinizer05: WFM is too mainstream
14:33.07keriohttp://www.codinghorror.com/blog/2007/03/the-works-on-my-machine-certification-program.html
14:33.17ivgalvezconsidering the quality of PR1.0
14:33.22DocScrutinizer05ivgalvez: you're free to doubt that
14:33.29DocScrutinizer05I know other companies do
14:33.38ivgalvezfor sure... Nasa
14:33.40kerioother companies doubt that nokia did those tests? :o
14:33.41ivgalvezhehe
14:33.45DocScrutinizer05so *I* doubt Nokia was the only company NOT doing such tests
14:34.04freemangordonDocScrutinizer05: Nokia n900 testing was exactly what we do in CSSU-testing AFAIK
14:34.29ivgalvezCSSU's is better as it's done in the open
14:34.48iDontDocScrutinizer05, what about WFM's from a supposedly large user base? The download count (not [unique] install count) of busybox-power is 265897 according to http://maemo.dadablog.net/AppStats.php?package=busybox-power&os=fremantle
14:34.58DocScrutinizer05basically yes, but prior to giving some pkg to cssu-t we like devels to evaluate and rule out any obvious path for problems
14:35.08freemangordonbut anyway, that is irrelevant, we don't have the resources Nokia had, so have to use whatever we have
14:35.21merlin1991how do you plan todo the rootfs/opt thingy actually?
14:35.50kerioholy shit, 265k is a lot
14:35.51merlin1991is it meant to be 2 times busybox one stripped and one full?
14:36.05DocScrutinizer05yes, and our resources are pretty sufficient to review patches and find out if they change syntax, semantic, or output of a command in busybox. If they do, check if the command is used in initscripts
14:36.23DocScrutinizer05pretty simple straightforward task, basic sanity checks
14:36.23kerioDocScrutinizer05: that's inefficient
14:36.24iDontmerlin1991: two separate config files, tweak debian/rules to spit out two binaries. Only the symlinking has to be figured out AFAICS
14:36.34keriocheck if the command is used in initscripts *and then* check if the behaviour changes
14:36.38DocScrutinizer05kerio: no, that's the *only* efficient way
14:36.49iDontI got to go now, back in about half an hour. I'll stay connected to IRC
14:36.55DocScrutinizer05well, that way as well can get done
14:37.20DocScrutinizer05kerio: I don't care what we do first
14:38.24DocScrutinizer05I thought for a small patchset it would be better to check only the patches if they change syntax etc of command. If you prefer to check for each command used in initscripts if there's a patch for it, you're welcome
14:39.01freemangordoniDont: i have NFC how is the simlinking done, but I suspect it has some relation to the install directory, so I hope there is no "symlining" problem
14:40.23DocScrutinizer05after all I'd hope no syntax, semantic, or output changes got introduced by any of the patches we include
14:41.31freemangordonthe fuck, men, it is symlinking :D
14:41.34DocScrutinizer05after all busybox *claims* to be bourne shell compatible, so not much room for such changes after all
14:42.39freemangordonDocScrutinizer05: afaik there are lots of bb-p users, if there was some problem, it'd be found by now. I know, I know, WFM :)
14:42.52DocScrutinizer05I'm mostly concerned about the fact it (has been) *not* completely bourneshell compatible, and that initscripts still rely on that, so if we'd fix any of that, we'd see massive problems eventually
14:43.27ivgalvezBut are you referring to actual init scripts existing in PR1.3?
14:43.27DocScrutinizer05freemangordon: aiui we're preparing even a new version now
14:43.32ivgalvezor personal ones?
14:43.36DocScrutinizer05that hasn't seen *any* tests so far
14:44.00freemangordonyeah
14:44.01DocScrutinizer05ivgalvez: referring to probably pre-1.2 official initscripts
14:44.24DocScrutinizer05though nobody did proper investigations on that lately afaik
14:44.32ivgalvezhow could one be running such ancient scripts and CSSU at the same time?
14:44.54freemangordonbut it will go through -devel and -thumb, so it will see some testing before entering CSSU-T
14:45.05DocScrutinizer05it's a known problem of pre-PR1.2 anyway. Since then changing init shell been so publicly deprecated we seen no recent tests on it
14:46.03freemangordonhas to go, bbl
14:46.03keriochanged login shells for both user and root
14:46.11keriono side effects so far
14:46.50DocScrutinizer05I'm just saying we need to investigate if that problem just vanished without any of us noticing Nokia fixing it, or we simply didn't see it recently because of any other reason, for example nobody dared to mess with that stuff in the way we're going to do when fixing "bugs" in busybox
14:48.17kerioyou know how could we test it?
14:48.21DocScrutinizer05messing around with init shell isn't something you can do sloppy
14:48.25kerioby putting it in a repository dedicated to testing
14:48.32keriowe could call it "testing"
14:48.42DocScrutinizer05kerio: stop trolling please
14:48.45kerioor maybe "devel"
14:48.46keriok :c
14:50.35DocScrutinizer05after all it's basically init scripts that get tailored to fit the existing init shell
14:50.46DocScrutinizer05not other way round
14:51.07keriothe init shell is /bin/sh
14:51.10keriowell, the preinit
14:51.11DocScrutinizer05so whatever change in init shell needs to get checked against *all* inti scripts for possible impact
14:51.13kerio#!/bin/sh
14:52.31DocScrutinizer05you don't do such checks on a "WFM" basis, you need code-coverage-analysis basically, to make sure every single line of "code" in your scripts got run on the new shell and worked as expected
14:53.06DocScrutinizer05or you do the already semi-sloppy way to just grep in init scripts for the suspicious commands
14:53.54DocScrutinizer05"WFM" just ensures there's *ONE* working path, by no means it secures *all* possible pathes
14:55.29DocScrutinizer05and "we don't have the manpower for that" is no valid excuse. IF we wouldn't have enough manpower for that, we mustn't touch the thing at all
14:56.22DocScrutinizer05after all I still fail to see the really existing and occuring bug all this will fix
14:56.34ivgalvezyou are assuming that Maemo should receive code coverage from CSSU
14:56.45kerioDocScrutinizer05: http://busybox.net/ <- check the changelog
14:56.48keriofrom 1.10 to 1.20
14:56.51ivgalvezwhen you don't even know if it was done in its development at Nokia
14:56.57DocScrutinizer05so any risk on one side of scale is outweighed by exactly 0 benefit for system on the other
14:57.16DocScrutinizer05kerio: thanks a lot man, actually a *useful* contribution
14:57.22ivgalvezcode coverage outside the Aeronautical world?
14:57.31ivgalvezhaven't seen that in my life
14:57.35keriosomeone posted it earlier, actually
14:57.48kerioivgalvez: is "space" in aeronautical?
14:58.06ivgalvezwell yes, more or less the same ;)
14:58.33kerioivgalvez: hm, maybe the military?
14:58.50ivgalvezI've worked for the military industry
14:59.02ivgalvezyou don't want to know what kind of tests they do
14:59.06ivgalvezembarrasing
14:59.06kerioDocScrutinizer05: unsurprisingly, there's a ton of bugfixes since the stock busybox we have
14:59.13keriothere's also a ton of improvements
14:59.19*** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg)
14:59.24DocScrutinizer05sorry, reconnect
14:59.27kerioDocScrutinizer05: unsurprisingly, there's a ton of bugfixes since the stock busybox we have
14:59.27DocScrutinizer05ivgalvez: code coverage is done on every semi-commercial product. N900 is a 100% commercial product, and CSSU is designed to prolongue its life
14:59.28keriothere's also a ton of improvements
14:59.38keriowhich is exactly the kind of stuff that you say we should triplecheck
14:59.40ivgalvezI work on commercial products
14:59.50ivgalvezI know people working on commercial products
15:00.59ivgalvezI don't know anyone making code coverage outside the DO178-C
15:01.18DocScrutinizer05ivgalvez: same here (if you're willing to consider ST-Ericsson modem used in Samsung phones as a commercial product)
15:01.35merlin1991do178-c?
15:01.36DocScrutinizer05and they *do* code coverage
15:01.42DocScrutinizer05in integration
15:01.56DocScrutinizer05though it should be done by devels actually
15:02.55DocScrutinizer05we also use test units
15:02.56ivgalvezmerlin1991: DO178-C is for certification of software on airbone environments and other critical systems
15:03.09DocScrutinizer05for each module
15:03.36DocScrutinizer05which actually are written by devels, since those are supposed to know what to test in their sub-system
15:03.42ivgalvezDocScrutinizer05 a modem is a piece of hardware with very low level software to be integrated in end user products
15:04.00ivgalvezit's not the same kind of product
15:04.03DocScrutinizer05"very low level software"?? bwahahaha
15:04.22ivgalvezI mean closer to the hardware
15:04.30ivgalvezmaybe not well expressed
15:05.04ivgalvezsorry now on meeting
15:05.09DocScrutinizer05o/
15:07.12iDontback
15:08.52DocScrutinizer05kerio: alas this 'changelog' on http://busybox.net/ isn't telling me which patches to review, since I dunno which of them get included to cssu.  For sure we don't want to include them all, since then we again hit that "eats MB of rootfs space, and impossible to review all so introduces risk" issue
15:09.45kerioDocScrutinizer05: well, we'd need to grab all the ones that aren't configured away
15:10.12kerioso at the very least anything related to commands that are included with the stock BB
15:10.30DocScrutinizer05so I think as long as it's freemangordon to review patches and decide which one or 2 packages we actually want to include to fix anticipated problems in busybox-vanilla, I'll just wait for his analysis if those patches change anything on syntax, semantics, or output of any command
15:11.38DocScrutinizer05once he delivers that list, I'm more than willing to check the changes against current initscripts and give my verdict if I think they are safe or not
15:12.35DocScrutinizer05(btw something estel happily rejected/ignored to do, when I suggested it to him as a true valuable contribution to cssu+bb topic)
15:13.20DocScrutinizer05kerio: all on your page regarding what we need to include
15:13.42DocScrutinizer05what we need to *consider* for inclusion
15:14.29DocScrutinizer05and it's exactly those patches to commands already included in busybox that need triple check
15:14.38keriohttp://i.qkme.me/3qpmrd.jpg
15:15.29DocScrutinizer05since one or two *additional* commands wouldn't probably have much impact/risk regarding maemo init, since... well they're not used for obvious reasons
15:15.44keriohehe
15:16.03kerioi just realized that the patches that shouldn't be included carelessly are the ones that are actually needed the most
15:17.01DocScrutinizer05so, to pick a proper example, if we get an augmented swapon command, we need to review all invocations of swapon in initscripts and related core system stuff, to secure the old syntax is compatible with the new command
15:17.15DocScrutinizer05kerio: indeed
15:19.33DocScrutinizer05if however you (hypothetically) would introduce a *new* command "change-swap-prio" then we probably could get away with rationale like >oh well, nobody ever used change-swap-prio so far, so it's probably low risk for init process to enable that command<
15:19.34ivgalveziDont ping
15:19.44ivgalvezspeaking of issues
15:19.48iDontivgalvez: pong
15:20.10ivgalvezagain rebooting the device with bb-p open  messed up my history :(
15:21.24DocScrutinizer05ivgalvez: I guess that's because of busybox, for a number of sound reasons, handles history differently to standard shell?
15:22.59iDontDocScrutinizer05, yes, upstream busybox has proper history saving on shell exit implemented. Maemo's version just overwrites the history file with the current shells' history on exit (e.g. multiple shells open will result in lost commands)
15:23.20DocScrutinizer05ivgalvez: aiui busybox differs massively from any other standard shell, regarding spawning of new instances for execution of scripts etc, so obviously history semantics are entangled to that
15:25.05DocScrutinizer05iDont: (losing commands when closing multiple instances) a behaviour pretty much expected for any standard shell
15:26.01DocScrutinizer05iDont: aiui on busybox you might find yourself actually *not* running multople instances even while you think you do
15:26.20freemangordonDocScrutinizer05: well, I think I have enough stuff in the queue to put bb there as well, I think we can find someone else to do it. Remember, I have to do the same assesmment to do for KP patches ;)
15:26.37DocScrutinizer05yep
15:26.50iDontDocScrutinizer05: bash does save history from all (parallel) shell instances
15:26.58DocScrutinizer05I'm all aware of your workload
15:27.04*** join/#maemo-ssu mase_76 (~mase76@p5DD3BECB.dip.t-dialin.net)
15:27.31DocScrutinizer05iDont: oh, it doesnow? not when I checked last time
15:27.46iDontI'm speaking of interactive shells of course
15:28.19iDontit does on my laptop: open two terminal emulators, write some commands in both, close them both, check history
15:28.34DocScrutinizer05yeah, exactly. each interactive shell overwriting history file of last closing instance with its own one
15:29.12iDontthat shouldn't be done, as you'll lose history that way. Bash does not lose history, and so does upstream BusyBox
15:29.17DocScrutinizer05or you do append to file, probably by handling that in your exit rc files
15:30.11DocScrutinizer05or you define a prompt commad to write out each single commadline to history file the very moment you fire it up
15:30.30DocScrutinizer05command* ffs
15:31.22DocScrutinizer05there's however no IPC between distinct bash instances, regarding history file writing
15:32.55iDontAnd neither is there any IPC in BusyBox' ash shell. BusyBox' ash appends its history to ~/.ash_history
15:33.12iDontbut it can also be configured to write out history after each command (as you stated)
15:33.12DocScrutinizer05last time I checked I got the impression bash just writes out the internal history buffer to ~/.bash-history on exit
15:34.16iDontivgalvez, I could configure BusyBox to append each command to the history file, that would solve all history-related issues. That will put some extra strain on the eMMC though
15:34.36iDontalthough I'm not sure how much (considering it's only a line of text, but it does add up I guess)
15:34.42iDontanyone has some insight on that?
15:34.57DocScrutinizer05anyway I'd guess that's a question of configuration, done either by shell envs (set --foobar on) or simply via user's ~/.bash-startup
15:35.07DocScrutinizer05and ~/.bash-exit
15:36.18DocScrutinizer05iDont: strain to eMMC is last concern here. There are way more rogue things in that respect - after all we got IO buffering as well
15:36.52keriocan't it be configured, anyway?
15:36.54kerioand besides
15:37.00keriowho the fuck actually uses busybox as a login shell?
15:37.36DocScrutinizer05but, as mentioned, that's just a question of *user* config, since w mustn't change this behaviour for init shell which doesn't have any history for obvious reasons
15:38.03DocScrutinizer05kerio: trolling again?
15:38.19DocScrutinizer05who would use anything other than busybox for login shell?
15:38.27keriome, for instance!
15:38.29kerioi use bash
15:39.43ivgalveznow my history ended up with some random C++ code, I wonder where did it came from
15:40.01ivgalveziDont maybe that should be configurable then
15:40.03DocScrutinizer05sounds like a busybox bug
15:40.47ivgalvezkerio: most embedded systems use bb
15:40.56ivgalvezI use it in STB for example
15:40.57kerioivgalvez: i am aware of that :)
15:40.58iDontivgalvez, at the moment it's only configurable at compile time
15:41.18ivgalvez:(
15:41.23kerioivgalvez: the n900 is quite the powerful embedded system though :)
15:41.29DocScrutinizer05pretty bad
15:42.07DocScrutinizer05iDont: so could we get rid of any history handling in bb binary, and just handle that in the appropriate scripts?
15:43.02DocScrutinizer05kerio: FSCK yeah! it's more powerfull than the laptop I used when I bought my first N900
15:43.02iDontbusybox disables history handling completely when the shell is not interactive. History handling (and all its related compile-time configuration) should therefore be irrelevant to scripts
15:43.20iDontunless those scripts start with #!/bin/sh -i, which I highly doubt
15:43.38kerioany script writer relying on shell history should be shot
15:44.51*** join/#maemo-ssu NIN101 (~NIN@p5DD28A45.dip0.t-ipconnect.de)
15:45.00DocScrutinizer05iDont: well, that's a pretty normal basic shell function. However if we can't configure history behaviour in a "convenient" way at runtime, we might want to move *all* history handling to some config scripts like .bashrc .bash-startup whatever the name
15:46.07DocScrutinizer05after all it's one simple command in startup and one in exit script
15:46.49iDontDocScrutinizer05, sorry, I'm not sure what you're talking about
15:47.05DocScrutinizer05sorry, I'll try to elaborate
15:47.12iDontthanks :)
15:49.52DocScrutinizer05history: history [-c] [-d Offset] [n] oder history -anrw [Dateiname] oder history -ps Argument [Argument...]
15:51.00iDontBusyBox doesn't supply `history` at all
15:51.26DocScrutinizer05WUT?
15:51.42iDontcheck it ;-)
15:52.13DocScrutinizer05indeed, so how the fuck we should handle history at all then?
15:52.42DocScrutinizer05this is so incredibly stupid
15:53.23iDontAs user, you only can only manipulate the standard envorinment variables ($HISTFILE et al)
15:53.34DocScrutinizer05pfff
15:53.57iDonthehe, I didn't say ash is better than bash ;-)
15:54.09iDontit just happens to be the default shell in Maemo
15:54.17DocScrutinizer05~messybox
15:54.17infobotmessy... err busybox is meant for lean scripting. Regarding all the missing options and immanent limitations (see su, passwd) it's not really the interactive shell of choice. A lot of people hate busybox because a lot of system integrators don't understand the difference between busybox and a decent user interactive shell plus unix utils
15:55.02freemangordonhehe
15:55.22DocScrutinizer05tr5ying to teach the dog to fly
15:55.33iDontyep. I mainly use busybox-power for its tools. It's really convenient to have a lot of tools always available. If can always install proper tools if BusyBox is lacking. However, that hasn't occured too much for me yet (with busybox-power)
15:55.49iDonts/if/I/
15:56.01iDontwoops
15:56.08iDontwe'll, you get what I mean
15:56.16iDontwell*
15:56.17iDontdamn
15:56.30iDontnot my best day
15:57.26DocScrutinizer05so I don't really care what you do to messybox history handling, unless it changes behaviour for non-interactive
15:58.27DocScrutinizer05users loving busybox for all the missing stuff may find a way to deal with whatever history handling you come up with. don't expect that to go into cssu fixed busybox-vanilla though
15:59.00DocScrutinizer05asince I hardly can see any reason to review that patch
15:59.30iDontDocScrutinizer05, I don't think we're on the same page. I'm not planning to change any history related code
16:00.15iDontI suggested changing a compile-time option.
16:00.29iDontAnd history handling is _always_ turned off for non-interactive shells (unless your script starts with #!/bin/sh -i, which it really shouldn't), so you don't have to worry about the subject at all
16:00.55iDontsorry if a misunderstanding has come from my side
16:01.31DocScrutinizer05we're worrying about *any* patches going into cssu busybox vanilla
16:02.03DocScrutinizer05since any patch comes with risk, and usually with added payload for rootfs
16:02.57DocScrutinizer05your "portrait" patch was pretty minimalistc, so no probelm to review it, and no impact to size
16:03.19iDontDocScrutinizer05, the portain patch was from Pali, not me  ;-)
16:03.30DocScrutinizer05(though I have to admit I don't get what it actually does)
16:04.00freemangordonhmm, do I get it right, upstream bb handles history differently from stock?
16:04.23freemangordon*stock maemo
16:04.25DocScrutinizer05seems so
16:04.34freemangordonin what way?
16:05.49iDontNokia patched in an own method to save history, but it was broken. Upstream BusyBox provides two different ways of saving shell history, configurable via a compile-time option
16:06.17freemangordonaah,ok. DocScrutinizer05: what is the problem with that?
16:06.49DocScrutinizer05no problem, just asking why we need that in busybox vanilla
16:07.37iDontWell, you don't want to patch in Nokia's broken method in upstream, do you?
16:07.43DocScrutinizer05and also asking if that assumtion it's been buggy Nokia implementation is any quotable, e.g ticker on bugtracker where Nokia admits there's a bug and not a feature we didn't understand
16:07.54freemangordonhehe
16:08.18DocScrutinizer05s/ticker/ticket/
16:08.24freemangordoniDont: what is broken? history being overwritten by the last interactive shell?
16:09.02freemangordoniDont: sorry if you already answered
16:09.41iDontone sec
16:09.47DocScrutinizer05afk now, finally getting my end-of-day / /end-of-week / end-of-contract / end-of-work drink
16:10.15merlin1991DocScrutinizer05: aren't you on a new contract like tomorrowß
16:10.21DocScrutinizer05ping me if there's a proper cssu meeting later (it's Friday after all)
16:10.22merlin1991s/ß/?/
16:10.29DocScrutinizer05nope
16:11.11freemangordonwell, chem|st is missing, merlin1991 is away and with bad inet, I don't think there will be a meeting today ;)
16:11.40DocScrutinizer05good :-D
16:12.06freemangordonmerlin1991: may I ask you to do me a favor?
16:12.18merlin1991depends on the favour ;)
16:12.48freemangordonthere was a conversation regarding licensing of VKB RE stuff and I promised to change the license
16:13.09merlin1991and I gotta do what?
16:13.33merlin1991rm -rf / on my server? :D
16:13.34freemangordonfor the life of mine I cannot think of what that "(C) Nokia" license should contain
16:14.04freemangordonno, invent some license and replace LGPL wherever applicable
16:14.20iDontDocScrutinizer05, I can point out the flaw in Nokia's shell-hist.patch
16:14.26ivgalvezfreemangordon hi
16:14.32freemangordonivgalvez: hi
16:14.52ivgalvezwhat's the original license or eula file in Nokia's package
16:14.54ivgalvez?
16:15.02*** join/#maemo-ssu MrPingu (~chatzilla@86.92.226.97)
16:15.04freemangordonthere is no ;)
16:15.10ivgalvezyou just need to keep that file
16:15.12ivgalvezdoh!
16:15.41ivgalvezOK, then use this: http://tablets-dev.nokia.com/eula/index.php
16:15.50ivgalvezand add a notice file
16:15.54iDontfreemangordon, back to you. Were you talking about Maemo's busybox, upstream BusyBox, or busybox-power :-P?
16:15.58iDontin your question
16:16.05ivgalvezsaying what we already tlked last day
16:16.37freemangordonivgalvez: not applicable, I used binaries from SB :P
16:17.01freemangordoniDont: just a minute, I want to finish with that license once and for all :)
16:17.06iDontk
16:17.14ivgalvezActually, qgil commented yesterday by email that Nokia EULA and already exiisting declarations on TMO are covering fair use
16:17.18ivgalvezfor Nokia devices
16:17.55DocScrutinizer05ivgalvez: ++ and thanks!
16:18.42ivgalvezI have insisted about it and he answered that it's absolutely clear that we can use Nokia copyright for Open Source projects on Nokia devices
16:19.23ivgalvezqgil: "There won't be anything more official than what has been written and
16:19.23ivgalvezexplained in the forum. The Nokia EULA is official and it doesn't make
16:19.23ivgalvezany sense to have an official message contradicting the EULA. Please
16:19.23ivgalvezkeep playing nice and there won't be any problem."
16:19.44ivgalvezso don't try to install Maemo in $DEVICE
16:20.10DocScrutinizer05"this file may contain parts derived from disassembly of binaries unde Nokia's copyright (see http://tablets-dev.nokia.com/eula/index.php). The original licencing conditions apply to to all those derived parts as well and you accept those by using this file"
16:20.16DocScrutinizer05sth like that will do
16:20.28ivgalvezperfect
16:20.52ivgalvezso now we need to contact Adobe ;)
16:21.28DocScrutinizer05SSSHHH!
16:21.43DocScrutinizer05;-)
16:22.57freemangordonhmm, I like that, thanks, going to update the sources
16:23.13ivgalvezno probs
16:23.13DocScrutinizer05please fix my spelling ;-)
16:23.14kerio"hey adobe, we're gonna ship your latest flash player on maemo kthxbye"
16:23.21freemangordonhehe
16:23.41merlin1991kerio: the important part is the kthxbye :D
16:26.07ivgalvezmerlin1991 I hope somehow you will be able to actually administrate the repos during next week
16:26.45ivgalvezI have a big list of applications to promote form Testing-Squad list ;)
16:26.46DocScrutinizer05sips on his nice cold drink
16:27.49merlin1991ivgalvez: as soon as I can actually do stuff I'll be happy todo so :)
16:28.25DocScrutinizer05kerio: (latest flash player) do we actually *want* to do that? would we even be able to find something worth it?
16:28.44kerioeeh, you're probably right
16:28.51keriomost porn sites work fine with flash 9
16:28.52DocScrutinizer05merlin1991: how's your vacations?
16:29.06freemangordon/**
16:29.08freemangordon@file hildon-im-vkbrenderer3.c
16:29.10freemangordonThis file is part of libhildon-im-vkbrenderer3.
16:29.12freemangordonТhis file may contain parts derived from disassembly of binaries under Nokia's copyright,
16:29.14freemangordonsee http://tablets-dev.nokia.com/maemo-dev-env-downloads.php.
16:29.16freemangordonThe original licencing conditions apply to all those derived parts as well
16:29.19freemangordonand you accept those by using this file.
16:29.21freemangordon*/
16:29.22kerio*licensing
16:29.23freemangordonok?
16:29.29freemangordonthanks
16:29.33DocScrutinizer05OK
16:29.35kerioalso, maybe "the disassembly"?
16:29.35merlin1991DocScrutinizer05: perfect, only tomorrow is the last day :/
16:29.37ivgalvezgreat
16:29.46keriois not a native english speaker
16:30.04freemangordontoo
16:30.10ivgalvezmerlin1991 did you actually do anything apart from going to the beach?
16:30.12DocScrutinizer05derived by disassembling...
16:30.17DocScrutinizer05-of
16:31.10DocScrutinizer05merlin1991: so enjoy it to the last minute
16:31.27DocScrutinizer05maemo madness waiting for you, you know ;-)
16:31.58merlin1991ivgalvez: been to ronda and gibraltar
16:32.05DocScrutinizer05\o/
16:32.09ivgalveznice
16:32.11merlin1991and then ofc lots of beach and booze :)
16:32.15DocScrutinizer05both nice places I've been as well
16:32.48DocScrutinizer05merlin1991: don't miss to visit cabo trafalgar / los canos de mecca
16:33.09ivgalvezCaños de Meca
16:33.17DocScrutinizer05some 50(?) km from Gibraltar up the atlantic coast
16:33.30DocScrutinizer05ivgalvez: indeed
16:33.38freemangordonI suppose I can have different licensing for .c/.h, as I want headers LGPL licensed
16:33.50freemangordon?
16:33.52DocScrutinizer05probably, yes
16:34.11freemangordonwhat about package (C)?
16:34.12ivgalvezperfectly possible, just add the license notice in each header file
16:34.28DocScrutinizer05as long as the .h don't include stuff too obviously basing on disassembly
16:34.58DocScrutinizer05package (C) always the most restrictive option of all available
16:34.59freemangordonwell, function names, but nothing like v21
16:35.01ivgalvezthe package contains Nokia stuff so it has to keep Nokia copyright
16:35.06freemangordonok
16:35.22ivgalvezand is not redistributable out of Nokia devices
16:35.36DocScrutinizer05freemangordon: function names are free ;-)
16:35.44DocScrutinizer05var names as well
16:36.28DocScrutinizer05yeah, beefeater kicks ass
16:36.32DocScrutinizer05:-D
16:36.45merlin1991how does that fit? :D
16:36.51merlin1991half a day spent on irc in spain, time to get out again xD
16:37.05DocScrutinizer05not at all, to the topic. Pretty good, to my mood
16:37.15merlin1991hehe
16:37.23merlin1991though tbh beefeater is not that good gin
16:37.40DocScrutinizer05good enough for longdrinks
16:38.01DocScrutinizer05(they had no Gordon's @ Karstadt :-o )
16:38.06merlin1991anyway I'll go and find me some longdrink, probably back on sunday
16:38.26DocScrutinizer05cya, enjoy yourself!
16:39.15iDonthave a good one, merlin1991!
16:44.14freemangordonhttp://pastebin.com/XkyaJBh2
16:44.16freemangordonok?
16:45.57freemangordonDocScrutinizer05 ^^^
16:56.31DocScrutinizer05freemangordon: seems ok
16:57.41DocScrutinizer05somebody will rise concerns that there are two conflicting licences, but I'm not one of them, since I think it's clear that the second more restrictive one overrides the GPL where applicable
16:57.53DocScrutinizer05(sorry for delay)
17:01.15freemangordonyep, fixed it
17:01.15freemangordonhttps://gitorious.org/community-ssu/hildon-im-vkbrenderer3/blobs/63e2f77d158f74d809264187e93c4d8b54d59545/debian/copyright
17:01.31freemangordonDocScrutinizer05: ^^^
17:02.47DocScrutinizer05freemangordon: perfect
17:05.02freemangordonwill change the other package too, but tomorrow :)
17:05.09DocScrutinizer05swallows some bitter comment about este^H^H and prepares another drink
17:06.50freemangordoniDont: I was asking what is broken in stock bb
17:10.54DocScrutinizer05yumyumyum http://www.cocktailscout.de/cocktail_Gr__ne_Wiese_rezept_149.html
17:11.31DocScrutinizer05actually baeh!
17:11.46DocScrutinizer05missing the proper huge dash of gin
17:13.44iDontfreemangordon: if you have multiple instances of ash open, only the command history of the last closed shell will be saved. All commands typed in other instances will be lost
17:13.52DocScrutinizer05haha http://www.cocktaildatenbank.de/cocktail-rezepte/801-gruene-wiese
17:14.29freemangordoniDont: ok
17:14.47freemangordonand what is upstream doing?
17:16.07freemangordoniDont: TBH there is lots of stuff that can be stripped from bb-p, rpm and rpm2cpio for example :)
17:16.08iDontBy default, it appends each command to the history file. All instances of ash does this, so you'll get interleaving commands from different ash instances
17:16.17freemangordonok
17:16.22freemangordonsounds ggod
17:16.27freemangordongood even
17:16.32iDontif you set ENABLE_FEATURE_EDITING_SAVE_ON_EXIT at compile time, it will append its history to the histfile on shell closure
17:17.18freemangordonwhich is close to stock behaviour, ain't?
17:17.47freemangordoniDont: what httpd in busybox do?
17:17.49DocScrutinizer05yeah sonds pretty convenient
17:18.07iDontYes, and that's what we have turned on in busybox-power (to save wear on the eMMC). However, if ash is closed unnicely (for the lack of a better term), the history file can get garbled
17:18.13iDontthat's still a bug that puzzles me
17:18.52DocScrutinizer05iDont: don't worry about eMMc wear!
17:19.03keriofreemangordon: make an educated guess
17:19.09DocScrutinizer05...since your EE colleagues already did ;-)
17:19.17freemangordonyeah, that won't get flushed until needed
17:19.30iDont:-D great!
17:20.05iDontthen there is no issue wrt history handling at all anymore
17:20.07DocScrutinizer05you get buffering on any (laso eMMC) writes to storage anyway
17:20.17DocScrutinizer05so "don't worry, be happy!"
17:20.29keriois there a way to enable something similar to TRIM for the eMMC?
17:20.56DocScrutinizer05*burp*
17:21.02DocScrutinizer05sync:sync
17:21.08DocScrutinizer05;
17:21.16kerio...no
17:21.18iDontfreemangordon, httpd is a complete webserver implementation in busybox ;-)
17:21.19keriothat's nt TRIM
17:21.26freemangordoniDont: I think you should be able to move httpd, rpm stuff, sendmail, etc to /opt and get rid of acpid and such
17:21.28iDontfreemangordon, although a tiny one
17:21.30DocScrutinizer05there's no TRIM on mmc
17:21.33kerioshame
17:21.46iDontfreemangordon, yes, and probably more as well
17:21.52freemangordonyep
17:22.13DocScrutinizer05TRIM is pretty lowlevel
17:22.26DocScrutinizer05eMMC controller doesn't have API for that
17:22.31freemangordonand you will fit in those 100-150 k limit, witout risk to break someone's early boot script
17:22.50iDonteveryone's happy :-)
17:22.54freemangordonyep :)
17:23.02DocScrutinizer05without risk to break somebody's heart ;-D
17:23.14freemangordonmission accomplished
17:24.15DocScrutinizer05wonders if it's his nature to play the bastard, or it's just some users who don't get the whole picture make him feel like that
17:24.15iDontI'm very glad we finally got something productive going regarding busybox and CSSU. Last week hasn't been really fun for anyone I guess
17:24.33DocScrutinizer05actually I'm also striving for the best of maemo
17:24.53iDontDocScrutinizer05, I think nobody would deny that
17:25.02DocScrutinizer05but I get mad on somebody forecefeeding anything to somebody else
17:25.47freemangordoniDont: well, it is up to you then. Though my proposal is to clone bb as it is now(on gitorious), forward the source to upstream, make the needed changes and request a merge
17:26.21freemangordonthat way we can make a review of what are the actual changes in the source code
17:26.31DocScrutinizer05iDont: I concur with last (2) week(s) nobody felt happy (except maybe estel for his successful trolling)
17:27.06freemangordoniDont: is that sound sane?
17:27.07DocScrutinizer05nah, that's been mean
17:27.17freemangordonDocScrutinizer05: why?
17:27.19DocScrutinizer05I think even estel wants the best for maemo
17:27.28freemangordonaah, ok
17:27.34freemangordonyou are still on estel :P
17:27.41DocScrutinizer05he just has poor diplomatical skills
17:27.54iDontfreemangordon, yes, sounds good. However, there are a _lot_ of commits between BusyBox 1.10 and 1.20
17:28.38DocScrutinizer05freemangordon: yeah, that tears me down more than you might expect
17:29.03freemangordoniDont: btw by saying "upstream" do you mean "debian" or some git repo?
17:29.05DocScrutinizer05I just don't get it how he's such a douchebag and always bitching at me
17:29.46iDontI mean the latest stable tagged busybox release by upstream
17:29.49kerioDocScrutinizer05: what do you mean you don't get it?
17:29.51kerioit's easy
17:29.57kerioDocScrutinizer05: it's your fault the freerunner sucked!
17:30.05keriosee?
17:30.06DocScrutinizer05after all he seems the only one thinking I got time to spare just to annoy him
17:30.24freemangordonguys, lets finish with bb, please
17:30.36kerioand let's move to cbsms
17:30.49DocScrutinizer05kerio: indeed, I should've jumped in more early, with much more verve, to save the project
17:30.59keriowait, really?
17:31.03kerioso it *was* your fault! :O
17:31.12iDont@freemangordon <iDont> I mean the latest stable tagged busybox release by upstream
17:31.40freemangordonkerio: https://gitorious.org/community-ssu/operator-name-cbs-widget/commit/5d30fedb5ebea226d9ccfe9ac8453bfe9acb02c4/diffs/9c19e807f04312b1e5d71d4283f4aa55bd152f0f
17:31.52freemangordonnow, lets go back to bb
17:32.05keriowtf is that
17:32.39DocScrutinizer05kerio: lol for cbsms
17:32.40freemangordoniDont: well, then you should be able to simply rebase (after removing nokia patches)
17:32.47DocScrutinizer05good topic change
17:32.52kerioDocScrutinizer05: don't lol, that's your fault too!
17:32.58DocScrutinizer05yes!!!!
17:33.10DocScrutinizer05I take all the blame for it
17:33.30DocScrutinizer05I however won't accept it as an excuse to continue like that
17:33.44iDontfreemangordon, yes, that's what I'll do. I had a little misunderstanding ;-)
17:33.53kerioi don't want to use it as an excuse to continue like that, i want it out of my cssu :C
17:34.07kerioor fixed
17:34.11DocScrutinizer05after all, if we don't learn from our mistakes, we're real fools
17:34.29kerioby the way, the dpkg divert it uses is a massive kludge
17:34.30freemangordonkerio: hmm, where is your CSSU, I want to try it.
17:34.43kerioand whoever thought of that should be shot in the back
17:34.54kerioor maybe lightly mocked
17:35.01kerioone of those two
17:35.19freemangordonkerio: wasn't trolling so far enough?
17:35.38kerioif you want to do a proper one of those, do the same as the future busybox-power - provide and conflict with connui-home-cellular
17:36.08DocScrutinizer05kerio: (out of cssu or ficed) I'm all with you regarding that
17:36.40DocScrutinizer05kerio: and I promise it won't make it to cssu-s in this condition it's now
17:37.32DocScrutinizer05kerio: THAT is what cssu-t is all about. Get packages you *think* are already withput problems, then learn if they actually are
17:38.01DocScrutinizer05but it's no excuse to act sloppy on prior evaluation of possible problems to anticipate
17:38.40DocScrutinizer05I failed on anticipating the problems we see with cbsms
17:38.51DocScrutinizer05and I take the blame for that
17:39.05keriobesides...
17:39.14keriocan't it be enabled on-demand?
17:39.29DocScrutinizer05I however *won't* take any accusations for trying to avoid same mistake in the future
17:40.39kerioit's ok, i still love you <3
17:42.13DocScrutinizer05and I probably hire ninjas if some estel comes again stating I don't contribute so his valuable experience is way more relevant than anything I say
17:43.02DocScrutinizer05after all for *what* he ever took responsibility?
17:44.16DocScrutinizer05what has been his invaluable contribution to maemo at large, except some pretty poorly written shellscript 10-liners that *we* tought him char by char
17:45.03DocScrutinizer05and yet they were like WTF-of-the-week
17:45.19DocScrutinizer05since he didn't listen and learn
17:45.39DocScrutinizer05meh , could somebody kick me please?
17:45.55keriokicks DocScrutinizer05 on the shins
17:46.04DocScrutinizer05thanks
17:46.07iDontfreemangordon, is there anything else to discuss regarding busybox? I'll make sure to do what you suggested, although I can't promise that it'll be completely done first thing tomorrow ;)
17:46.36DocScrutinizer05iDont: nobody expexts that, so relax
17:46.51iDont:-)
17:47.19iDontOtherwise I'll call it a day, got some plans for tonight (Friday!)
17:47.25DocScrutinizer05iDont: after all, we don't even have a pressing bug ticket against the whole thing
17:48.01DocScrutinizer05iDont: so I suggest you get a life, something I should finally try to do as well :-d
17:48.05DocScrutinizer05:-D
17:48.51iDonthehe, true. Busybox-power in its current state does however fix quite a few maemo bugs (/feature requests)
17:49.37DocScrutinizer05maybe, but how many users of N900 will not sleep due to thise bugs tonight?
17:50.07DocScrutinizer05cssu is about the comfy feeling that you don't have to worry
17:50.22DocScrutinizer05since there are other guys doing that for you
17:51.01iDontwell, if they really can't sleep, they can alway apt-get install busybox-power!
17:51.10DocScrutinizer05if you wanna go bleeding edge or as 1337 as it gets, there are other ways you can do
17:51.20iDontregarding CSSU, who doesn't have that installed ;p
17:51.23DocScrutinizer05yes, exactly
17:53.25DocScrutinizer05cssu is first and foremost about bringing security fixes to users. 2nd about fixing long pending annoyances everybody suffers from, like e.g. portait (not a good example) or cpu-hog-bug in hildon-desktop (much better example)
17:54.19DocScrutinizer05cssu is _not_ about "leading your people to the promised land" (like in holy bible) though
17:54.46iDontyup, I get what you're saying
17:55.36DocScrutinizer05fine, probably I should take own advice and continue my ethanol intoxication enterprise somewhere else
17:55.58DocScrutinizer05~seen estel_
17:56.04infobotestel_ <~Estel@Maemo/Community/council/Estel-> was last seen on IRC in channel #maemo, 6h 25m 16s ago, saying: 'happy trolling, i'm out.'.
17:56.11iDonthehe
17:56.14DocScrutinizer05byebye
17:56.25iDontI'm calling it a day as well. Everyone have a good one tonight! Bye!
17:56.42DocScrutinizer05iDont: thanks for participating
17:56.50DocScrutinizer05any enjoy your time
17:57.20*** join/#maemo-ssu ivgalvez (~quassel@41.pool85-49-220.dynamic.orange.es)
17:59.04DocScrutinizer05<kerio> can't it be enabled on-demand? #### sure it should be optional
17:59.36DocScrutinizer05and we already agreed on it going cssu-extras
18:00.01DocScrutinizer05minus the lib patch which is core system but for now seems to be safe
18:00.46DocScrutinizer05yay, newsflashes
18:00.52DocScrutinizer05o/
18:04.36*** join/#maemo-ssu ShadowJK (~jk@terminus.enivax.net)
18:25.37*** join/#maemo-ssu ShadowJK (~jk@terminus.enivax.net)
18:34.51*** join/#maemo-ssu javispedro (~javier@Maemo/community/contributor/javispedro)
18:35.58*** join/#maemo-ssu nox-- (noident@p57900C13.dip.t-dialin.net)
18:36.35*** join/#maemo-ssu nox-- (noident@p57900C13.dip.t-dialin.net)
18:46.48*** join/#maemo-ssu ShadowJK (~jk@terminus.enivax.net)
18:53.09*** join/#maemo-ssu arcean (~arcean@aael108.neoplus.adsl.tpnet.pl)
18:55.00*** join/#maemo-ssu ShadowJK (jk@terminus.enivax.net)
18:59.04*** join/#maemo-ssu arcean (~arcean@aael108.neoplus.adsl.tpnet.pl)
19:09.02*** join/#maemo-ssu arcean (~arcean@aael108.neoplus.adsl.tpnet.pl)
19:26.54*** join/#maemo-ssu ShadowJK (jk@terminus.enivax.net)
20:04.13gregoakerio: cbs-widget: pali has pushed some fixes yesterday, and I've built packages for myself. so far they look good, at least the operator name doesn't vanish when I switch between 2G and 3G. if you want to try: wget http://info.comodo.priv.at/tmp/connui-home-cellular_3.1+nmu1_armel.deb ; wget  http://info.comodo.priv.at/tmp/operator-name-cbs-widget_3.1+nmu1_armel.deb
20:07.50keriogregoa: yay ^_^
20:07.54kerioi'll try those
20:08.22kerioDocScrutinizer05: i actually meant keeping both the stock one and the cb one saved, and loading one or the other depending on whether the user enables something in Settings
20:08.25gregoakerio: let's hope they fix your problems too
20:08.44keriogregoa: btw, one of those two packages is a fake
20:08.49keriojust fyi :)
20:09.16gregoaI know I know
20:12.42keriosadly, the *wrong* package is a fake
20:23.11keriogregoa: i'll have to test it for a couple of days i think
20:23.45keriogregoa: not sure about you, but i don't always get the problem
20:23.48gregoanods
20:23.53kerioonce i do, though, it stays there until i reboot
20:24.22keriobesides, i think it also depends on the cell i'm connected to
20:24.31keriowhich makes the problem... "fun" to diagnose, i suppose
20:24.53gregoawith the latest version I could reproduce the "no op name" reliably by switching between 2G and 3G, and this effect is gone now at least
20:25.27gregoabtw, "killall hildon-home" seems to be enough for reviving it
20:25.35kerioit's always temporary for me
20:25.45keriolike, after i switch i get the wrong name/no name again
20:26.17kerioanyway, i suppose i can just leave operator-name-cbs-widget installed as a fake package
20:26.25kerioand reinstall the stock connui-home-cellular
20:26.26kerio:D
20:30.58DocScrutinizer05CHEEERS
20:31.59DocScrutinizer05beefeater is quite nice, when dilluted in orrange juice
20:32.30DocScrutinizer05-l
20:32.37DocScrutinizer05-r
20:32.38DocScrutinizer05meh
20:32.48*** join/#maemo-ssu arcean (~arcean@aael108.neoplus.adsl.tpnet.pl)
20:33.16DocScrutinizer05friggin paperwork all over the world
20:33.41DocScrutinizer05CV! >:-(
20:33.46DocScrutinizer05shoots the C
20:33.53DocScrutinizer05and the V separately
20:34.44DocScrutinizer05since when a CV ever told something really relevant about he person in question
20:37.18DocScrutinizer05I always hired my teams without any fancy CV, just on the merit they exposed to me
20:38.05DocScrutinizer05competence, commitment, and character
20:39.49DocScrutinizer055 minutes of talk already tell you more than any friggin CV
20:40.21DocScrutinizer055 min of chat will do almost as well
23:54.04*** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139)
23:54.27*** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.