<Joerg-Neo900>
there is no such thing like shared memory and CCCI in Neo900, no vendor RIL and no other proprietary kernel drivers, actually the modem doesn't need any special kernel driver at all
<Joerg-Neo900>
of course sharing RAM and integrating baseband processor with application processor (AP) into one chip, like done in HTC One M9+ used in that case study, is a nice way to save money and space, and so it's found in virtually *all* contemporary smartphones. NOT in Neo900 though
<enyc>
Joerg-Neo900: funny you time that i was just looknig there!!
<enyc>
Joerg-Neo900: aaaah and it already has debian dependencies shown
<enyc>
(in readme, not a debian control file)
<enyc>
Joerg-Neo900: is eeshow at a ''stable'' point ? I'm happy to check builds with dependencies as-given and contact debian-side-maintainer as-is to update their eeshow package, ... though you claim "maybe achive eeshow in opensuse leap" etc etc....
<Joerg-Neo900>
yes, wpwrak's policy is "HEAD/MASTER is _always_ stable"
<Joerg-Neo900>
"contact debian-side-maintainer as-is to update their eeshow package" highly appreciated
<enyc>
it (could) nonetheless help to declare project beliived to be stable as of head ver something....
<enyc>
i.e. STATE this somewhere on project page
<Joerg-Neo900>
yes, I fon'z know where and how, though
<enyc>
Maybe best i simply ask deb maintainer about it, what quality/other improvements will be needed to transition package to debian "unstable", if it will help to add the debian/ directory in git sourcetree neo900-end, etc etc
<enyc>
since i more-or-less have an idea what to ask
<enyc>
though, i should read the debian packaging guidelines ...
<enyc>
apparently, in Oct 2016 "Note: This program is not yet stable and probably not suitable for"
<enyc>
"the upcoming Debian release."
<enyc>
presumably, that was true and its' fair to say that situation has since changed?
<enyc>
ok. in any case i don't think it matters per-se, though i can see the point that projct itself doesn't yet tdeclare versions // 'stable' releseases / etc
<enyc>
all that matters in first instance is correct the situation, previous misunderstanding is not important.
<Joerg-Neo900>
this is thanks to wpwrak's aproach to *never* do releases
<Joerg-Neo900>
a huge PITA for distro maintainers
<Joerg-Neo900>
I'm just pondering to fix this
<enyc>
I'm not sure ''releases'' / branch matters, unless the project wants to make a radical change in the program
<enyc>
(in which case you have to keep stable/patched-stable branch separate from HEAD while that all gets sorted out)
<Joerg-Neo900>
for all package managers, we need a monotonically increasing version number anyway, to determine whether an update is available or not
<enyc>
otherwise one way or another you can just nab the git-date and use that as version, as the packager has done
<Joerg-Neo900>
yes, DATE would work and is what I'll probably gonna use. git TAG however is not srted in any way
<Joerg-Neo900>
I guess it will be version=0.YY.MM.DD-$gittag
<Joerg-Neo900>
zhis works for version.h file retroactively providing verioning for a previous commit
<enyc>
something like thits can work,... debian says 0.git20161102-1 follongi other debian conventions
<enyc>
would you prefer the debian people keep rebuilding from eeshow git regularly? or just a one-off-update in first instance?
<Joerg-Neo900>
keep rebuilding please
<Joerg-Neo900>
0.git20161102-1 looks excellent
<Joerg-Neo900>
or 0.git20170731-1 now
<enyc>
i'll try to see, whoever that is at debian may-or-may-not be helpful [!]
<Joerg-Neo900>
?
<enyc>
i'll see what they say when i'm up to writing clearl question for them
<Joerg-Neo900>
debacle@debian.org (W. Martin Borgert)
<enyc>
yes =)
<Joerg-Neo900>
you may mention that the authors consider HEAD=stable
<Joerg-Neo900>
now if only somebody would do a Ubuntu/Mint PPA package
<Joerg-Neo900>
let me know if we should add anything to the original upstream repo for version-management
<Joerg-Neo900>
at very least we prolly should adapt the version string in window caption
<Joerg-Neo900>
so USER as well has a means to see how old the version they use
<Joerg-Neo900>
when my apt or zypper or yum says I hot 785d539f66d3h84dvh installed but the program shows it's version 0896778qw44d54, there is no way to conclude it I'm running an obsolete version that left over despite install of newer package, or if somehow I managed (e.g. via local build) to create a _newer_ version that the one in package manager
ArturShaik has quit [Ping timeout: 240 seconds]
luke-jr has quit [Excess Flood]
luke-jr has joined #neo900
pagurus` has quit [Ping timeout: 240 seconds]
pagurus has joined #neo900
louisdk has quit [Ping timeout: 255 seconds]
deafboy has quit [Ping timeout: 246 seconds]
Pali has quit [Remote host closed the connection]
deafboy has joined #neo900
https_GK1wmSU has joined #neo900
https_GK1wmSU has left #neo900 [#neo900]
DocScrutinizer05 has quit [Ping timeout: 258 seconds]