ArturSha1 has joined #neo900
kiswe has joined #neo900
kiswe has left #neo900 [#neo900]
threebar has joined #neo900
vlitzer has quit [Remote host closed the connection]
threebar has quit [Changing host]
threebar has joined #neo900
knttl has quit [Ping timeout: 252 seconds]
knttl has joined #neo900
preview has quit [Ping timeout: 258 seconds]
threebar` has joined #neo900
threebar` has quit [Changing host]
threebar` has joined #neo900
threebar has quit [Ping timeout: 240 seconds]
Kabouik- has quit [Remote host closed the connection]
Kabouik- has joined #neo900
akaWolf has quit [Ping timeout: 260 seconds]
akaWolf has joined #neo900
preview has joined #neo900
_whitelogger has joined #neo900
Kabouik- has quit [Ping timeout: 258 seconds]
ravelo has joined #neo900
merlin1991 has quit [Ping timeout: 255 seconds]
tweedle has quit [Quit: Leaving]
merlin1991 has joined #neo900
xmn has quit [Quit: Leaving.]
jonsger has joined #neo900
jonsger has quit [Ping timeout: 240 seconds]
ravelo has quit [Quit: Connection closed for inactivity]
jcarpenter2 has quit [Read error: Connection reset by peer]
jcarpenter2 has joined #neo900
Pali has joined #neo900
Pali has quit [Remote host closed the connection]
jcarpenter2 has quit [Read error: Connection reset by peer]
jcarpenter2 has joined #neo900
jcarpenter2 has quit [Read error: Connection reset by peer]
jcarpenter2 has joined #neo900
freemangordon_ has joined #neo900
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.48/20170707010522]]
jkepler1 has joined #neo900
Kabouik has joined #neo900
jkepler has quit [Ping timeout: 240 seconds]
jkepler1 is now known as jkepler
jkepler has quit [Remote host closed the connection]
jonwil has joined #neo900
preview has quit [Ping timeout: 255 seconds]
louisdk has joined #neo900
jonsger has joined #neo900
jonsger has quit [Remote host closed the connection]
jonsger has joined #neo900
<sicelo> what's not true DocScrutinizer51?
<Joerg-Neo900> false is not true
<sicelo> for myself, i'll be honest i am quite jealous of the attention that the droid4 and allwinner tablets have 'stolen' from the N900
<bencoh> don't be, droid4 is in a far "worse" state than n900
<sicelo> but, the devs we have do have a valid point
<bencoh> apart from the fact that it's more recent/powerful
<Joerg-Neo900> so how is that on topic here?
<bencoh> it's not :D
<sicelo> my poit is - i think what the 'devs' are doing is reasonable. seeing as it still targets N900, i don't see why Neo should suffer
<sicelo> i think Neo should be better somewhat too
<sicelo> seeing as you don't have the modem problems we have on N900
<sicelo> or i am missing something?
<bencoh> modem problems?
<Joerg-Neo900> you're missing that the devs are moving away from maemo compatibility
<sicelo> phone-calls, bencoh
<bencoh> Joerg-Neo900: well, nobody set that goal in stone (apart from you, maybe)
<bencoh> at least regarding binary compatibility
<Joerg-Neo900> thanks for confirming my point above
<bencoh> Joerg-Neo900: you're welcome :)
<Joerg-Neo900> anyway for Neo900 we need *maemo*
<bencoh> you used to say it was an agnostic hardware project
<Joerg-Neo900> the whole point being that we can run an existing OS, with existing apps
<sicelo> maybe i'm too much of a layman here - but my understanding is that they are keeping *maemo* ...
<sicelo> updating things that definitely need updating
<Joerg-Neo900> bencoh: no, that's absolutely not the point. Neo900 is even built wire by wire to run stock maemo
<sicelo> and things that will somewhat keep us secure.
<bencoh> and we all know it won't run a carbon stock maemo
<Joerg-Neo900> I mean, if I wanted a device that needs new apps ecosystem and new OS, I would have used a completely different approach
<bencoh> meaning you'd need some software porting effort
<bencoh> now you're basically saying that the group/people you thought would bring that together somehow shifted their goal/effort to something different
<Joerg-Neo900> bencoh: YOU think you know that. What makes you think so?
<bencoh> that you'd need different/new drivers, and some glue (think modem, for instance)
<bencoh> but we've discussed that already
<Joerg-Neo900> no, we don't?
<bencoh> you're using a different modem
<Joerg-Neo900> so what?
<bencoh> so you'd need a different kernel
<Joerg-Neo900> NO!!!
<Joerg-Neo900> what makes you think modem has anything to do with kernel?
<Joerg-Neo900> what we need is either a slightly modified kernel OR a matched DT, for the 3 or 4 GPIOs that changed number/pin in Neo900. Nothing related to modem though
<sicelo> Joerg-Neo900: if Neo runs stock maemo, then how will you/we deal with browsing, which is in a bad state as it is. i run 3 browsers just to access what i need. our openssl makes us sitting ducks to all sorts of problems. now that we get CVE after CVE almost daily, using stock Maemo takes a leap of faith really
<Joerg-Neo900> sicelo: how's an app that performs sub-par related to an OS running on a hw platform?
<sicelo> the OS is old/insecure
<Joerg-Neo900> then update it for **N900**!!!
<sicelo> that's exactly what's happening
<Joerg-Neo900> no
<Joerg-Neo900> armel->armhf is *not* a security update
<Joerg-Neo900> it's a nice way to break binary compatibility of a complete existing rich app ecosystem
<Joerg-Neo900> what's happening is not security updates for maemo, it's more like the SunOS->Solaris move back when
<sicelo> while armhf is not a direct security update, upstream has generally deprecated armel, so most armel code will be old/bad/insecure too
<Joerg-Neo900> just worse
<Joerg-Neo900> sorry, I strongly disagree with _this_ rationale
<jonwil> me, I intend to continue doing reverse engineering on N900 and otherwise contributing things into CSSU
<Joerg-Neo900> armhf/armel is totally orthogonal to any code security and code maintenance
<Joerg-Neo900> it's like saying 386 is deprecated and any 386 code is obsolete.
<jonwil> I would have thought there would be no code differences between armhf and armel for most packages that dont do anything low-level or funky
<sicelo> 386 is different .. it is still being maintained an new iot boards are still coming out
<Joerg-Neo900> there's not really such a thing like 386 code (except a very few very niche cases where you actually code for a particular CPU like 386)
<jonwil> i.e. for 99% of packages it should just be a flag to the compiler to build it for either armel or armhf and that's it
<Joerg-Neo900> 99.9% but otherwise ack
<sicelo> maybe i didn't explain the thought properly, but more directly - stock maemo is rather a very insecure OS nowadays. fine for an N900, but to ship a new device (Neo900) with it ...
<Joerg-Neo900> sicelo: then what you suggest is to move away from maemo
<sicelo> no.
<Joerg-Neo900> yes
<Joerg-Neo900> Neo900 is the N900 successor, with warranty that maemo runs on it
<jonwil> If you built everything as armel and used a bit of magic (e.g. having multiple versions of libraries installed), I see no reason you couldn't have a modern core just like the guys are doing with this devuan thing but still be able to run a fair chunk of existing Maemo binaries as-is
<sicelo> i am saying i think it is reasonable what the devs are doing - move as much as possible of maemo to a modern base, modifying the base to be as backwards-compatible as possible
<sicelo> (i'm on 2G .. comments coming slow)
<Joerg-Neo900> jonwil: that's why I asked why nobody ever bothered to build maemo for N900 from scratch, based on what we got as codebase now. We need exactly that for Neo900
<Joerg-Neo900> sicelo: alas that's not what they do
<Joerg-Neo900> and that's not maemo either
<Joerg-Neo900> your own wording
<sicelo> what is maemo?
<Joerg-Neo900> the ecosystem based on the OS
<Joerg-Neo900> anyway we will have devel board soon and I need developers who are willing to install maemo on that board and demonstrate installing and running a few apps from maemo-extras repo
<Joerg-Neo900> and it seems jonwil is the only one who thinks this is feasible (except... me and Carsten Munk who did that years ago already:
<sicelo> well i personally wish Maemo (the one on N900) can be kept alive .. :-)
<sicelo> so i completely agree with you
<sicelo> however, i can understand the concerns "they" have, and they are valid, to me
<Joerg-Neo900> re >>what is maemo?<< I'd define it as "a linux-kernel, an OS, can load apps from extras-devel" just like every sane person answers "what is linux?" by "a linux kernel, a GNU userland, runs multiple users one of them being root, plus X11, plus a shell. NOT android"
<jonwil> I define Maemo as an OS based around the Hildon UI and other things
<jonwil> I define Maemo Fremantle as a specific version of Maemo capable of running a bunch of apps from specific Maemo Fremantle repositories
<Joerg-Neo900> I don't mind and actually appreciate "concerns" - however for example moving armel->armhf based on unfounded security/code-age reasoning and implicitly orphaning the maemo ecosystem "since it doesn't matter anyway" is not the right thing to do
<jonwil> I see the software stack on the Neo900 consisting of the following things:
<jonwil> And also on the N900 going forward as well
<jonwil> 1.Replacements for old Maemo Fremantle packages taken from Devuan or elsewhere that are modern, up-to-date and still maintained (e.g. by Devuan team) and which are ABI compatible with Maemo Fremantle/support the hardware we have in the N(eo)900 (or can be modified to be ABI compatible and support the hardware we have without a lot of work)
<jonwil> So newer kernel, newer libc, things like that
<jonwil> 2.Replacements for Maemo packages that aren't a direct replacement but still do the same job (e.g. a newer browser that isn't a direct 1:! copy of microb but has the functionality required in a browser for the N(eo)900 or e.g. replacing the relavent parts of the WiFi stack with wpa_supplicant)
<jonwil> 3.Existing maemo-specific FOSS packages (be they originally FOSS or be they cloned by someone) that are maintained and fixed (including security issues) going forward (this may include porting such packages to newer versions of various libraries)
<sicelo> so jonwil is with "them"
<Joerg-Neo900> huh?
<Joerg-Neo900> no, his approach is exactly in line with what we need for N900/Neo900 and NOT "with them"
<sicelo> i think it's mostly what they are doing
<Joerg-Neo900> no
<Joerg-Neo900> armel->armhf is a very obvious sign they don't
<jonwil> 4.Older versions of FOSS libs that we need to keep around to keep existing binaries running (obviously we would have the newer still-maintained versions of those libs as well for all the stuff that we are able to port to the newer version)
<jonwil> 5.Binary packages distributed by Nokia as part of Maemo Fremantle (where cloning those packages or otherwise replacing them just isn't an option or where we want that functionality in the short term but plan to replace it completly in the long term)
<Joerg-Neo900> it creates a completely new environment incompatible to what we just establashid "maemo2 might mean, with just a single compiler option and for no good reasons (the quoted "it's deprecated upstream" is not even an applicable argument)
<Joerg-Neo900> s/2/"/
<jonwil> and 6.Packages distributed by 3rd parties be they FOSS or otherwise (e.g. things in extras-*) that we want to be able to install and run as-is without needing to change them
<jonwil> Those 6 items are what I think the software stack on the Neo900 (and on the N900 going forward) should look like.
<Joerg-Neo900> that sounds excellent
<Joerg-Neo900> and that's _not_ what I see the new "porting efforts" are
<Joerg-Neo900> armhf deliberately and knowingly breaks "6)"
<jonwil> and 5 as well
<Joerg-Neo900> yes
<jonwil> I think I will put my 6 point plan into a TMO post
<Joerg-Neo900> maybe as answer to post#2 in
<Joerg-Neo900> ~fptf
<infobot> i heard fptf is the Fremantle Porting Task Force, see
<Joerg-Neo900> or was it #1?
<Joerg-Neo900> Neo900 hw anyway is being designed following ~fptf
<jonwil> I think a new post will be more likely to get a good discussion going than a post in the already long and hard to follow FPTF thread :)
<bencoh> jonwil: err, I wouldn't be so sure about that
<bencoh> and I think that would make "yet another thread"
<bencoh> but your call :)
<jonwil> I will make a new post and then if needed it can be mentioned in the FPTF thread :P
<sicelo> :)
<Joerg-Neo900> anyway what's a tad unfortunate is jaromil and others also still think Devuan was helping fptf, see
<Joerg-Neo900> while that thing tends to methamprhose into yet another devian flavor that *looks* like maemo but actually doesn't follow what I defined in fptf post #1 and jonwil is going to specify again now
<Joerg-Neo900> metamorphose*
* sicelo doesn't like Devuan so much btw :-)
<Joerg-Neo900> err? maemo is based on debian/devuan, that seems the only thing _not_ subject to discussion
<Joerg-Neo900> I'm not talking about a wallpaper or installer
<sn0wmonster> there is one thing i don't like about devuan
<sn0wmonster> the name
<sn0wmonster> :D
<sicelo> :-)
<sn0wmonster> i think it should be called Debian and Debian can change its name to SystemDebian
* sn0wmonster giggles
<Joerg-Neo900> ack
<jonwil> That's my post with the 6 points
<jonwil> describing how I personally think Maemo Fremantle should move forward
<jonwil> describing examples of what would fit each of the 6 points
<jonwil> Oh and in regards to armhf vs armel, I suspect even the kernel and compiler probably still have all the bits in place for armel support with no plans to drop or stop maintaining that code anytime soon.
<Joerg-Neo900> of course
<freemangordon_> armel vs armhf is a matter of setting up jenkins build target, so please stop that
<Joerg-Neo900> just like i396 which gets dropped by more and more distros just because they feel they "don't need it" anymore, despite it still works just fine
<jonwil> Ok we will drop that then :)
<freemangordon_> no, really, this was explained more then ten times already
<jonwil> But I think we should all agree that my 6 points are a good place to start in terms of the ultimate goal of this Devuan work
<freemangordon_> jonwil: see my reply
<Joerg-Neo900> does that matter if it's "a matter of setting up jenkins build target"? it's about getting a system that can run maemo-extras apps, irrelevant what it needs for that
<freemangordon_> this is in no way related with armel or rather what builds are availble *NOW*. it is a matter of ABI compatibility.
<Joerg-Neo900> please elaborate
<Joerg-Neo900> I don't see how I'd profit on either N900 or Neo900-devel board from armhf buolds. *NOW*
<freemangordon_> it is not done for you profit, sorry
<Joerg-Neo900> exactly
<Joerg-Neo900> so don't tell us to drop it then
<freemangordon_> it is done for mine profit, it is way easier to bring up a33 tablet with upstream kernel, than n900
Kabouik has quit [Ping timeout: 240 seconds]
<Joerg-Neo900> that's all fine but doesn't help Neo900
<Joerg-Neo900> neither N900
<freemangordon_> or you simply don;t see it
<jonwil> And a33 tablet needs armhf?
<freemangordon_> it doesn;t matter if it is x86-64, armhf or armel
<Joerg-Neo900> yes, I don't see how >>it is done for mine profit, it is way easier to bring up a33 tablet with upstream kernel, than n900<< helps Neo900 or N900
<freemangordon_> jonwil: no, but the devuan ARM image is armhf
<freemangordon_> and it saves time to use something that's ready
<freemangordon_> using that time to focus on more sane things
<freemangordon_> Joerg-Neo900: helps maemo, no matter on what platform you're going to use it
<freemangordon_> see, we have GTK2 with maemo changes and libhildon 1:1
<freemangordon_> mce, dsme, maemo-launcher, etc, etc is 100% compatible with the ones in fremantle
<freemangordon_> hildon-home, hildon-status-menu - the same
<jonwil> The libraries we have on the N900 now fit into several categories:
<jonwil> 1.Libraries where we have a newer modern maintained version that is ABI compatible with the Fremantle version (e.g. libc)
<jonwil> 2.Libraries specific to Maemo where we can keep the same ABI (e.g. hildon)
<jonwil> 3.Libraries where the version on Maemo is obsolete and there is a newer maintained version and its possible to have both libraries side-by-side on the one system (e.g. openssl)
<jonwil> and 4.Libraries where the version on Maemo is obsolete and there is a newer maintained version and its not possible to have both libraries side-by-side on the one system.
<jonwil> Given the way libraries on Linux (and presumably other Unix systems) are generally built I doubt any libraries fitting point #4 exist
<bencoh> freemangordon_: including ABI?
<bencoh> (for gtk)
<freemangordon_> yes
* bencoh scratches his own head
<freemangordon_> well, to the extend it was needed so far
<jonwil> since the convention is that if you break ABI compatibility with older apps, you have a newer version with a newer shared library
<bencoh> freemangordon_: I thought gtk ABI wasn't backward compatible (?)
<freemangordon_> we use forked gtk2
<bencoh> yeah, but ...
<bencoh> well, if you succeeded in that, yay
<freemangordon_> bencoh: well, we will know for sure when we try to start the first fremantle application (without re-compilation, installed from .deb in maemo-extras)
<freemangordon_> But I don;t see why it shouldn't work
<freemangordon_> ofc if some hacky application is accessing private structures directly...
<freemangordon_> but this is another story
<freemangordon_> Joerg-Neo900: so, could you explain what do you think is done so far that breaks fremantle compatibility?
<Joerg-Neo900> wait, I'm lost. gow does that match with >>[2017-10-17 Tue 15:54:31] <freemangordon_> DocScrutinizer05: supporting fremantle userspace, at least partially is a matter of setting up armel build aling armhf<< ?
<Joerg-Neo900> freemangordon_: we need to demonstrate that in a few weeks, on Neo900-devel boards
<freemangordon_> Joerg-Neo900: I am not sure we'll be able to support 100% of the stuff in extras without recompilation
<Joerg-Neo900> for now a N900 was a perfect substitute for Neo900-devboard
<freemangordon_> I am doing my best to keep AB compatibility, but there is no guarantee I will be able to do so for everything
<Joerg-Neo900> yes, obviously there will be a few apps that need special things in API (e.g. /sys nodes)
<freemangordon_> no, I am talking about ABI on .so level
<Joerg-Neo900> and obviously netmon won't work since it depends on ISI interface to modem
<freemangordon_> what you talk about is HW adaptation
<freemangordon_> and that's another story
xmn has joined #neo900
<freemangordon_> Joerg-Neo900: let me put it that way - every library so far in leste repo is supposed to be 100% compatible with the same library in fremantle, besides gtk2 which most-probably is missing some of the patches
<freemangordon_> but this will be fixed when it comes to it
<Joerg-Neo900> ABI on .so level I always thought been covered by
<freemangordon_> or in short - the same exported functions with the same number and type of parameters
<freemangordon_> for some (linhildonfm for example) the implememntation is totally different
<Joerg-Neo900> and >>[2017-10-17 Tue 16:11:19] <jonwil> Given the way libraries on Linux (and presumably other Unix systems) are generally built I doubt any libraries fitting point #4 exist<<
<freemangordon_> because in modern linux distros there are no things like gnomevfs, for example
<freemangordon_> it is replaced with gio
<freemangordon_> jonwil: could you elaborate on that statement?
<freemangordon_> hmm, wait
<jonwil> If you change a library in a way that changes the ABI the done thing is to give it a totally new .so file
<freemangordon_> yeah, thats true
<freemangordon_> but in reality there is at least one we should keep around - .... ummm....
<freemangordon_> ah, yes
<freemangordon_> libpng12
<freemangordon_> it is in devuan jessi, but not in ascii
<freemangordon_> however, this is for the future
<freemangordon_> jonwil: but yes, your point is valid
<jonwil> Anyhow, I think I have articulated my thoughts on how this should ultimately proceed
<Joerg-Neo900> worst case there's stil LD_PRELOAD to the rescue
<freemangordon_> sure
<Joerg-Neo900> see >>3.6. Incompatible Libraries<< in
<Joerg-Neo900> >>When a new version of a library is binary-incompatible with the old one the soname needs to change. <<
<freemangordon_> as simple as that
<freemangordon_> though, I don;t think we have such problem so far
<freemangordon_> I am going home, bbl
freemangordon_ has quit [Ping timeout: 255 seconds]
<sicelo> i'm happy about the outcome of this discussion :-)
Kabouik- has joined #neo900
<Joerg-Neo900> I'd be more happy if there was a script that produces a working maemo fremantle to load to N900 (for now) and to Neo900-devboard (in a few weeks)
<Joerg-Neo900> and that working maemo should be capable of installing and running a few apps from maemo-extras
<Joerg-Neo900> I don't even mind if that script would steal a few blobs from a fiasco image, as long as there's a plan how to deal with that in the future
<Joerg-Neo900> I also don't mind when a few features of stock maemo don't work (yet) in that built-from-scratch "new" maemo
<Joerg-Neo900> as long as the whole thing installs&runs apps on a N900
__Chris has quit [Ping timeout: 248 seconds]
<Joerg-Neo900> or/and a BB_xM
__Chris has joined #neo900
<freemangordon> Joerg-Neo900: you should have started with that one - that you need to show something somewhere. However, you idea of "script" is not applicable as ow now. Not to say we have different view on how this should e achieved...
Pali has joined #neo900
<freemangordon> Our approach is - grab devuan image applicable for your device, enable leste repos, apt-get update, apt-get install maemo-hildon-desktop
<freemangordon> then install whatever .deb you want (or enable maemo repos and install $whatever from there)
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.48/20170707010522]]
<freemangordon> but yeah, I should ask parazid to enable armel builds as well
<freemangordon> parazyd even
xmn has left #neo900 ["Leaving"]
jonsger has quit [Ping timeout: 248 seconds]
<Joerg-Neo900> freemangordon: I don't have strong opinions about the approach, or script, or tools used. I'd still think the "grab the image for your device" involves using stuff like wget, dd, maybe even 0xFFFF or DFU, and a SD card, to get MLO, uBoot, rootfs onto device. But I'm not opinionated on how to achieve this as long as the end result is what we discussed above: a system looking and feeling like maemo, and being able to install&run apps from maemo-
<Joerg-Neo900> extras, running on a BB_xM/N900 since that's what Neo900-devboards will be based on. Could be a script or as well an instruction website like updated
<freemangordon> Joerg-Neo900: I don;t have any other HW to test besides n900 and a33
<Joerg-Neo900> I'll send you a BB_xM right away, though the differences between N900 and BB_xM are marginal
<Joerg-Neo900> as far as system-bringup is involved
<freemangordon> Joerg-Neo900: who is supposed to prepare the minimal debian(devuan?) system that is supposed to be preinstalled on neo900?
<freemangordon> as, if it is devuan jessie, there is nothing more we should do
<freemangordon> just add repos and install stuff
<freemangordon> no image etc needed
<Joerg-Neo900> not devided yet. I'd hope there will be some working (BB_xM) system to strip down when it gets to this stage
<Joerg-Neo900> decided*
<freemangordon> and no, I don;t need BB_xM
<Joerg-Neo900> how's the installation procedure for devuan jessie on a fab-virgin "cold" device?
<freemangordon> through uSD card image
<freemangordon> but I guess we speak OneNAND here
<Joerg-Neo900> for Neo900 you have the coice, though it prefers booting from OneNAND, yes. For BB_xM it has no NAND at all, boots from uSD. N900 you know yourself
<Joerg-Neo900> :-)
sn0wmonster has quit [Ping timeout: 240 seconds]
<freemangordon> however, as soon as there is bootable minimal devuan jessie on Neo900 and you're able to connect to wifi, it is really just a matter of adding repos ind install
<freemangordon> *and
<freemangordon> Neo900 or whatever HW
<Joerg-Neo900> sounds like a plan. I hope there is a BB_xM image
* freemangordon checks
<freemangordon> I guess you can politely ask parazyd to make one :)
<Joerg-Neo900> we'd need a armel one
<freemangordon> but, there is n900 image
<freemangordon> ah, yes, it is armhf
<freemangordon> shouldn;t be much of a problem though
<freemangordon> it is a matter of repo/arm-sdk setup
<Joerg-Neo900> I'm glad we sorted that :-)
<freemangordon> sorry, it was clear to me from the beginning, thus why I was wondering what the problem is
<freemangordon> Joerg-Neo900: also, please do me a favor - before making statements like "those guys are breaking fremantle compatibility" or similar, share your concerns with me, ok? I guess we can (as always) discuss theand find a solution if there is a real problem
<freemangordon> *them and
<Joerg-Neo900> ok :-)
sn0wmonster has joined #neo900
<Joerg-Neo900> didn't realize that the reason for all my bitching about armel/armhf over in #devuan wasn't clear
<freemangordon> as you know you're respected community member and your statements have weight in the community, you should really be careful what you say ;). I hate PR and politics as much as you do, but...
<Joerg-Neo900> :-)
* Joerg-Neo900 hands freemangordon a beer
<freemangordon> 10x :)
<Joerg-Neo900> sicelo: _now_ everybody's completely happy. Great result indeed
<Joerg-Neo900> freemangordon: thanks a lot
vlitzer has joined #neo900
<sicelo> :-)
<sicelo> freemangordon: let me bitch just once. let's not call it Maemo 7 on github (leste). let's call it 5.9 as it is a continuation of 5, and nothing coming after 6
<Joerg-Neo900> call it maemo2001, or maemo vista ;-)
<Joerg-Neo900> mameo NT
<Joerg-Neo900> "New Targets" ;-D
<freemangordon> "Not Tested" :)
<Joerg-Neo900> maemo of course, not mameo
<Joerg-Neo900> has a surpirising appeal when just was meant a joke
<bencoh> err, nope.
<bencoh> :]
<Joerg-Neo900> sorry guys, afk. busy
<freemangordon> sicelo: well, actually it *is* 7, we reuse parts of harmattan/meego
<freemangordon> and there is a piece of ceod from sailfish/nemo even ;)
<freemangordon> *code
<freemangordon> not to say it is based on newer (base) code than everything maemo-like
<freemangordon> afaik
<freemangordon> not sure about nemo though, however it is deffinitely newer than harm
<freemangordon> thus 7
sn0wmonster has quit [Excess Flood]
<sicelo> right </bitching >
sn0wmonster has joined #neo900
<Joerg-Neo900> anyway if I had to make a suggestion about maemo naming schemes, I had quit "winds" and moved on to something new like "streams" or "inuit names for snow" or whatever
<Joerg-Neo900> but in the end as long as it's few chars and no special chars to type, a name is a name is a name
<Joerg-Neo900> "Istiophorus platypterus" would be funny but just too lomg
<Joerg-Neo900> another idea I just had for what it shouldn't be, I can't even pase here, giving perfect reason why it's not a great idea
<Joerg-Neo900> paste*
<Joerg-Neo900> ☿
<Joerg-Neo900> finally found it
rofl_ has joined #neo900
<Joerg-Neo900> next ♀♁♂♃♄♅♆
<Joerg-Neo900> though Maemo Mercury sounds smaaaart ;-)
<Joerg-Neo900> and already has an ☿ icon :-D
jcarpenter2 has quit [Ping timeout: 264 seconds]
<Joerg-Neo900> oh Noes!! >>The Leste is commonly accompanied by clouds of fine red sand.<< ;-)
ArturSha1 has quit [Ping timeout: 248 seconds]
Kabouik_ has joined #neo900
ravelo has joined #neo900
Kabouik- has quit [Ping timeout: 248 seconds]
jkepler has joined #neo900
hexamod has joined #neo900
xmn has joined #neo900
xmn has left #neo900 [#neo900]
Hodges has joined #neo900
louisdk has quit [Ping timeout: 248 seconds]
arnaudj has joined #neo900
scare_byte has joined #neo900
scare_byte has quit [Quit: Leaving]
vlitzer has quit [Remote host closed the connection]
arnaudj has quit [Remote host closed the connection]
arnaudj has joined #neo900
arnaudj has quit [Ping timeout: 260 seconds]
arnaudj has joined #neo900
vlitzer has joined #neo900
preview has joined #neo900
jonsger has joined #neo900
jonsger has quit [Ping timeout: 252 seconds]
drathir has quit [Remote host closed the connection]
rofl_ is now known as jcarpenter2
drathir has joined #neo900
Tsutsukakushi has quit [K-Lined]
vlitzer has quit [Quit: ok bye]
drathir has quit [Remote host closed the connection]
drathir has joined #neo900
rofl__ has joined #neo900
jcarpenter2 has quit [Read error: Connection reset by peer]
rofl__ is now known as jcarpenter2
jonwil has joined #neo900
arnaudj has quit [Quit: arnaudj]
Pali has quit [Read error: Connection reset by peer]
ravelo has quit [Quit: Connection closed for inactivity]
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.48/20170707010522]]