<Wizzup> tmlind: I just got 4 mz609 delivered to my home, so that's timely :)
buZz has quit [Ping timeout: 265 seconds]
buZz has joined #maemo-leste
buZz is now known as Guest5990
uvos has quit [Ping timeout: 255 seconds]
Guest5990 is now known as buZz
SuperMarioSF_ has quit [Remote host closed the connection]
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
Twig has joined #maemo-leste
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_1 has joined #maemo-leste
ceene has quit [Ping timeout: 268 seconds]
<freemangordon> this:
<freemangordon> user@devuan:~/git/hildon-application-manager$ git diff src/apt-worker.cc
<freemangordon> index cb6a567..4242bb9 100644
<freemangordon> --- a/src/apt-worker.cc
<freemangordon> diff --git a/src/apt-worker.cc b/src/apt-worker.cc
<freemangordon> +++ b/src/apt-worker.cc
<freemangordon> @@ -2315,7 +2315,7 @@ mark_for_install_1 (pkgCache::PkgIterator &pkg, int level)
<freemangordon> pkgCache::PkgIterator InstPkg(cache,0);
<freemangordon>
<freemangordon> // See if there are direct matches (at the start of the list)
<freemangordon> - for (; *Cur != 0 && (*Cur)->ParentPkg == P.Index(); Cur++)
<freemangordon> + for (; *Cur != 0 && (*Cur)->ParentPkg == P.MapPointer(); Cur++)
<freemangordon> {
<freemangordon> pkgCache &pkgcache = cache.GetCache ();
<freemangordon> pkgCache::PkgIterator Pkg(pkgcache,
<freemangordon> makes it compile, but I am not 100% sure this is the correct fix
<sicelo> and my wlan joy was shortlived - d4 failure to connect on first try is back :-)
<freemangordon> as expected :)
akossh has joined #maemo-leste
xmn has quit [Ping timeout: 272 seconds]
ceene has joined #maemo-leste
mardy has joined #maemo-leste
<Wizzup> freemangordon: ty
rafael2k has joined #maemo-leste
<Wizzup> freemangordon: looks correct to me
<Wizzup> the comment in the commit specifically
pere has quit [Ping timeout: 252 seconds]
<freemangordon> Wizzup: why would it be deleted?
<freemangordon> you have to delete it explicitly
<Wizzup> ok
<Wizzup> currently I'm trying to debug why apt-worker doesn't want to give package details, but unfortunately it looks like glib by default closes it's stderr instead of logging it to something sane
<Wizzup> and the remove part (ham) crashes at a certain point so it doesn't log the stderr
<Wizzup> all fun stuff
<Wizzup> and running it under strace doesn't work as that makes sudo unhappy
<Wizzup> looks like it has some define DEBUG
<Wizzup> not that it gives -any- more info :)
pere has joined #maemo-leste
<Wizzup> lol, the DBG() caused some segfault in the DBG
<Wizzup> great
<freemangordon> valgrind?
<freemangordon> Wizzup: also, re APT::Progress::PackageManagerProgressFd() - why not allocate on stack?
<Wizzup> freemangordon: it's tricky, apt-worker takes commands only over pipes
<Wizzup> and there's no tool to just interact with it, only via h-a-m
<Wizzup> and h-a-m eats the stderr and glib has no way to spawn it without eating the stderr with this call
<Wizzup> well it does, but our glib does not
<Wizzup> so I've made apt-worker log to a file, but of coures that still doesn't work if it segfaults
<Wizzup> and you can't strace it because then sudo will deny the sudo invocations
<Wizzup> it's just a typical mess where I spend over an hour just trying to get the error message / crash
<freemangordon> like:
<freemangordon> Pm->DoInstall (&progress_mgr);
<freemangordon> APT::Progress::PackageManagerProgressFd progress_mgr(status_fd);
<Wizzup> but I am now mostly at that point: apt-worker: got req AUTOREMOVE/7/32
<Wizzup> apt-worker: sent resp AUTOREMOVE/7/4
<Wizzup> apt-worker: before handle request
<Wizzup> apt-worker: handle_request
<Wizzup> freemangordon: let me check what you mean
<Wizzup> oh, instead of the new?
<freemangordon> mhm
<Wizzup> I'm just not at all proficient in C++
<freemangordon> heh :)
<Wizzup> last time I did anything meaningful in it outside of Qt5 port was in uni
<freemangordon> oh
<Wizzup> I probably just copied that from libapt src
<freemangordon> please, ask when you have concerns then
<freemangordon> I am pretty much good in c++
<Wizzup> I am :P
<freemangordon> ok
<Wizzup> I will commit this
<Wizzup> then I'm back to trying to figure out why apt worker crashes when asked for GET_PACKAGE_DETAILS/8/36
<freemangordon> what you can do is: put sleep(20) in main, start whatever needs to be started, then attach gdb
<Wizzup> mmm
<Wizzup> that's a good idea actually
<freemangordon> or put sleep(20) that in the function that crashes
<Wizzup> maybe write the pid to the log first
<Wizzup> I don't know what crashes ;)
<freemangordon> yeah, I know ;)
<freemangordon> no need
<freemangordon> ps -ef
<Wizzup> lazy :)
<freemangordon> the other option is to get a coredum[p
<Wizzup> we probably really need to look into that
<Wizzup> btw, now that I have you here
<Wizzup> for chimaera you wanted 'testing' for users and 'devel' for us?
<Wizzup> and also 'experimental' ?
<Wizzup> Program received signal SIGSEGV, Segmentation fault.
<Wizzup> 0x00007f75a58322a3 in metaIndex::~metaIndex (this=0x5652a69cf2c0, __in_chrg=<optimized out>) at ../apt-pkg/metaindex.cc:46
<Wizzup> 46../apt-pkg/metaindex.cc: No such file or directory.
<Wizzup> there we go
alex1216 has joined #maemo-leste
<freemangordon> Wizzup: yeah, I think that makes sense
<Wizzup> ok, just getting the catalog uri breaks in him
<Wizzup> great, now I have almost fixed this pesky bug
<Wizzup> s/him/ham/
pere has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
uvos has joined #maemo-leste
ceene has quit [Ping timeout: 252 seconds]
<Wizzup> freemangordon: around?
<Wizzup> commenting this line and ham is all happy
<Wizzup> I suppose it's possible this pointer is owned by someone else, right?
<Wizzup> freemangordon: yeah apt-pkg/sourcelist.cc seems to return a pointer from its own cache
* Wizzup commits
<sicelo> joerg: yes, i made a mistake to say 50mA :-)
<sicelo> and yeah, i use the datasheet a lot
ceene has joined #maemo-leste
uvos has quit [Ping timeout: 268 seconds]
<freemangordon> Wizzup: there is no concept of 'ownership of a pointer'
<Wizzup> freemangordon: in any case it should not free it
<Wizzup> it's freeing internal libapt-pkg data/structure and this is what causes the crash later on
<freemangordon> who initializes that?
<Wizzup> it's from libapt
<Wizzup> libapt-pkg
<freemangordon> which call in our code?
<Wizzup> freemangordon: yes, that sets the index ptr from the libapt cache
<freemangordon> right
<freemangordon> Wizzup: who and why introduced that delete Index?
<Wizzup> freemangordon: the mydebsystem is gone
<Wizzup> let me check the get_meta_info_key
<Wizzup> freemangordon: that function is unused and it uses symbols that are private
<Wizzup> (get_meta_info_key)
<freemangordon> ok
<Wizzup> ok, not entirely unused
<Wizzup> I'll fix it
<Wizzup> but this is not related
<freemangordon> do you want help?
<Wizzup> sure, so:
<Wizzup> Release.gpg.info doesn't exist at all in my vm
<Wizzup> it's probably deprecated
<Wizzup> the interface it uses to find the file is private/gone
<freemangordon> hmm
<Wizzup> the only thing it does is read the file for a string, which seems hacky
<Wizzup> so if we really want to implement this, we can just use IsTrusted() or something
<freemangordon> wait
<freemangordon> I think this is Nokia addition, most-probably
<Wizzup> well the last was a bit too hasty
<Wizzup> yes, it looks like it
<Wizzup> without the file it's hard to see what it might be searching for
<freemangordon> sec
<freemangordon> Wizzup: do you know where this file lives?
xmn has joined #maemo-leste
<Wizzup> freemangordon: no, try find / | grep Release.gpg.info
<Wizzup> or whatever it is called
<Wizzup> honestly it seems to me we should just remove this code
<freemangordon> perhaps, but lets first see what it was used for
<Wizzup> freemangordon: it was used for get_domain which returns DOMAIN_SIGNED and DOMAIN_UNSIGNED
<freemangordon> and? why shall we remove that?
<Wizzup> because it's nokia specific nonsense that we don't need
<Wizzup> at least, that's what I understand
<freemangordon> why do you think we won;t need that at some point?
<freemangordon> I see no reason why shall we remove support for 'trusted' domains
<Wizzup> what does trusted even mean
<Wizzup> just note that it's not part of libapt-pkg:
<Wizzup> #define DOMAIN_INVALID -1
<Wizzup> #define DOMAIN_UNSIGNED 0
<Wizzup> #define DOMAIN_SIGNED 1
<freemangordon> it means - 'provided by us' :D
<freemangordon> yes, I know it is not
<Wizzup> I don't think it makes sense to do it this way in any case, since it uses some non-standard file for it it seems
<Wizzup> whatever apt-key trusts is what is trusted
<Wizzup> if we want to give our repository a higher priority we can just use apt ways for this AFAIK
<freemangordon> but, that's one of the ways to alarm alarm user if she installs some random .deb
<Wizzup> I don't think so, is it?
<freemangordon> I think so
<freemangordon> ok, lets just have that as #ifdef
<freemangordon> don;t remove it
<Wizzup> ok
<Wizzup> in any case a deb release index has IsTrusted() for this purpose
<Wizzup> so whatever 'domain' they invented doesn't seem particularly sensible imo
<Wizzup> freemangordon: something else, do you know if it is possible to scale gtk bg_pixmap ?
<freemangordon> yes, sec
<freemangordon> I can fix that
<Wizzup> ok
<freemangordon> ok, will do later today
<Wizzup> freemangordon: btw buzz reported this but the 'recent contacts' screen in addressbook doesn't work well when you click on a recent contact
<Wizzup> sorry, he didn't report this as an issue, but told me a few days ago
<Wizzup> not urgent ofc
<freemangordon> sure it does not, it relies on rtcom db
<freemangordon> so, whoever calls rtcom-eventlogger shall be fixed
<Wizzup> it loads data
<Wizzup> but if you click on a person, it doesn't let you do anything with them, like make a new contact
<freemangordon> yes, I know
<Wizzup> ok
<freemangordon> this is because rtcom-el db lacks the needed data
ceene has quit [Ping timeout: 268 seconds]
<Wizzup> I'm thinking we can upscale our theme backgrounds with AI: https://wizzup.org/wallpaper1_upscaled.png
<Wizzup> thoughts?
<Wizzup> it might use more ram, although I think h-d should scale it to the display size?
<freemangordon> it already scales
<freemangordon> like, this is done in GPU
<Wizzup> freemangordon: yes but we scale *up* from 800x480
<freemangordon> right
<Wizzup> it's better to scale *down* from higher res to our screen
<freemangordon> oh, no
<freemangordon> downscaling is baaaad
<Wizzup> well the current way we have nasty artifacts
<freemangordon> where?
<Wizzup> just look at it on a non-n900 screen
<Wizzup> anything larger than 800x480, it looks ugly
<freemangordon> I am looking ATM
<freemangordon> in VM
ceene has joined #maemo-leste
<freemangordon> and d4
<freemangordon> lemme change the background
<Wizzup> try beta
<Wizzup> but, you don't need to verify, you can know theoretically it'll be ugly
<freemangordon> I was using beta all the time, but ok, lemme install it
<freemangordon> hmm, why it is not in my VM
<freemangordon> what the? where is my beta theme?!?
<freemangordon> looks perfect to me
<freemangordon> do you want screenshots to show me what do you mean by artifact?
<freemangordon> do you mean those thongs on the edges?
<freemangordon> *things
<Wizzup> it cannot look perfect unless you have the vm size set to 800x480
<freemangordon> I am looking in the VM
<Wizzup> it cannot make up pixels
<freemangordon> it is not 800x600
<freemangordon> VGA-1 connected primary 1280x720
<Wizzup> it looks blurry and unpretty
<Wizzup> I'll give you some before/after screenshots
<freemangordon> it could be because of the way we upsample
<Wizzup> there is just no way to make it not have artifacts
<freemangordon> but, down-sampling always produce more noise/artifacts than up-sampling
<freemangordon> also, unless we want to distribute pics for every possible resolution, I don;t think we can ever have non-blurry background
<freemangordon> anyway, lemme finish what I am doing with HAM
<Wizzup> I don't think is accurate
<Wizzup> think this is*
<Wizzup> downsampling with bicubic or lanczos is actually very good
<freemangordon> as is up-samplin
<freemangordon> I just think we use some lame up-sampling algo ATM
<freemangordon> will check later on
<Wizzup> freemangordon: I am not sure if you get my point, but cannot do upsampling better than downsampling, unless it's an exact factor 2x, 3, etc
<Wizzup> what I was saying is that we can leverage neural network / ai upsamplers that use AI to create high definition images of low res ones
<freemangordon> yes, I understand, but I think downsampling those on the device result in worse image than upsampling
<freemangordon> *will result
<freemangordon> anyway, please, lemme finish with HAM first :)
<freemangordon> almost there
<Wizzup> I think that means that the downsampling that is being used is wretchen then
<Wizzup> sure :)
<Wizzup> wretched*
uvos__ has joined #maemo-leste
<Wizzup> notice the sawtooth
<uvos__> downsampling for sure can get better results than upsampling
<uvos__> especcaly when downsampling far
<uvos__> ie >4x
<uvos__> downsampling just a bit can have bad artifacts, this is true
<uvos__> those look good
<Wizzup> those are just normal from the theme and AI upscaled
<Wizzup> the screenshots are them loaded in my qemu
<freemangordon> Wizzup: I think what we can do is to have different backgrounds per aspect ration
<freemangordon> *ratio
<Wizzup> freemangordon: what we should do is have larger input images than the native screen res
<uvos__> i mean all current devices besides the pocophone are 16:9 no?
<uvos__> so atm its not a problem
<Wizzup> the d4 and n900 already have the same aspect ratio and it still looks ugly
<Wizzup> (on the d4)
<freemangordon> how's that?
<uvos__> i can confirm it looks terrible
<Wizzup> freemangordon: you can see upscaling artifacts
<freemangordon> ok, but I still think this is because bad algo
<uvos__> besides artifacts its also blurry
<uvos__> this you cant fix
<freemangordon> background quality was the last thing I cared back then
<Wizzup> freemangordon: sure it doesn't matter that much, I'm just surprised you think it's worse to have a 4x upscale
<Wizzup> and then downscale it
<Wizzup> as opposed to upscale from missing data
<freemangordon> it is, because n900 will do this, most of the times ;)
<freemangordon> like, if you throuw som h-d image on it to downscale
<freemangordon> *throw
<freemangordon> anyway, ttyl, HAM :)
<uvos__> not sure why the n900 doing it matters
<Wizzup> uvos__: I think he means fremantle
<uvos__> just cache the image
<freemangordon> no, I mean n900
<freemangordon> oh, wait
<uvos__> what about it then?
<freemangordon> can't we scale just once, per device?
<freemangordon> during install or theme/background being selected?
<uvos__> isent that what happens anyhow (with backgrounds at least)
<uvos__> surely they thought of someone applying a dslr image
<freemangordon> not sure
<Wizzup> I think they get cached/stored yes
<uvos__> otherwise n900 would die if you apply a 22mpix dslr image :P
<freemangordon> ok, we can cache upscaled images then
<uvos__> *downsampled
<freemangordon> upscaled with UI, or whatever
<freemangordon> no
<freemangordon> upsampled with that AI
<Wizzup> you can see it is less grainy this way
<freemangordon> Wizzup: ok, I agree, I just don't want to do unneeded upsample->downsample
<freemangordon> lets just upsample once with th eappropriate algo when the cache is created
<uvos__> freemangordon: we dont want to upsample on device at all
<uvos__> just in the package
<uvos__> upsampling on device makes no sense
<uvos__> (ai upsampling is expensive)
<freemangordon> it is not an issue if we do it only once when a particularimage is selected
ceene has quit [Remote host closed the connection]
<freemangordon> changing theme/background takes time anyways
<uvos__> not sure what algo Wizzup used but most implementations need huge libaries like libtorch
<freemangordon> if it is going to take 4 or 5 seconds does not matter
<uvos__> that we def dont want on device at all
<uvos__> and could take mintues on device
<freemangordon> hmm
<uvos__> libtorch is like 400mb :P
<freemangordon> ok, ok
<uvos__> you dont want that on device
<freemangordon> yeah
<Wizzup> (sorry, back in a bit)
ikmaak has quit [Read error: Connection reset by peer]
ikmaak has joined #maemo-leste
<BlagovestPetrov4> it needs a package with custom udev rules :))
<BlagovestPetrov4> Wizzup:
<Wizzup> is this the lapdock?
<BlagovestPetrov4> yes
<Wizzup> cool!
<BlagovestPetrov4> and something should disable the screen locking
<Wizzup> BlagovestPetrov4: you can do this from settings
<Wizzup> or install simple brightness applet and set it to never disable the screen
<Wizzup> freemangordon: did you mean to say "let's up or downsample once when the cache is created" ?
<freemangordon> yes
<BlagovestPetrov4> I'll build a custom package with udev rules this weekend :)
<Wizzup> BlagovestPetrov4: I think it makes sense to think about how this would work, and how switching is done
<BlagovestPetrov4> exactly. Udev will detect the exact hardware IDs and execute a script with xrandr
<Wizzup> ok, let's see it :p
<BlagovestPetrov4> it may also need eventual remapping of the keys because the keyboard doesn't have function keys
<Wizzup> BlagovestPetrov4: it doesn't look like hildon-desktop really does the right thing, for example the apps launcher only draws in a part of the screen
alex1216 has quit [Quit: WeeChat 2.3]
<sicelo> yes udev seems best way to handle this
<BlagovestPetrov4> isn't it the same behavior as in the x86 image?
<Wizzup> BlagovestPetrov4: what is?
<uvos__> h-d/h-home dont survie the resolution changing
<Wizzup> BlagovestPetrov4: https://wizzup.org/example.png
<uvos__> you have to also kill it when pluging in the lapdock
<Wizzup> and if you do that 10 times it will restart the device
<Wizzup> :P
<uvos__> depends on how it exits i hope
<uvos__> or is dsme so broken it reboots even if h-d exits sucess
<BlagovestPetrov4> understood :)
<uvos__> really tho
<uvos__> switching to lxde or so works mutch better (on a montior + keyboard)
<uvos__> currently only possible via reboot
<BlagovestPetrov4> idea for dirty fix: Using a special exit code from Hildon
<uvos__> for what?
<BlagovestPetrov4> for restarting Hildon
<BlagovestPetrov4> but switching to another desktop is also a good idea
<Wizzup> here's an idea: fix hildon so that it just deals with res changes
<Wizzup> :D
<BlagovestPetrov4> :D
<Wizzup> freemangordon: this is not a great example but here's the worldclock bg: https://wizzup.org/worldclock-hd.png vs https://wizzup.org/worldclock-reg.png
<Wizzup> you can see the grainy parts
<Wizzup> this is everywhere in every there on any device with res > 800x480
<Wizzup> it's in the title bars, etc
<uvos__> but this is just issues with the images being 16bit no
<uvos__> are you switching to 32ẞ
<uvos__> ?
<uvos__> with the upscaleing
<Wizzup> $ file ./beta/backgrounds/clock.png
<Wizzup> ./beta/backgrounds/clock.png: PNG image data, 800 x 424, 8-bit/color RGB, non-interlaced
<Wizzup> $ file ./beta/backgrounds/clock.png
<Wizzup> ./beta/backgrounds/clock.png: PNG image data, 3200 x 1696, 8-bit/color RGB, non-interlaced
<Wizzup> I don't know what you mean
<Wizzup> the problem is that the n900 themes were basically made 'pixel perfect'
<Wizzup> so any upscaling, or any of it, will become grainy, especially the gradients (which is most)
<uvos__> hmm ok, all the theme images look 16bit and since the n900 ran in 16bit i assumed they where encoded 16bit too
<Wizzup> don't think so
<uvos__> even looking at the images pixel perfect theres still excessive banding
<Wizzup> in an image viewer you mean I guess?
<uvos__> yeah
<Wizzup> doing this for the lockslider would be good too I imagine :p
<uvos__> lockslider is particually broken
<uvos__> since the slider part is part of the image
<uvos__> theres no way that will ever line up right on dfiferent size/aspect displays
<uvos__> really that just needs replaceing
<Wizzup> would still be nice if it wasn't grainy meanwhile
<uvos__> sure
<Wizzup> BlagovestPetrov4: if you get a bit higher res photo of this I can put it on twitter
rafael2k_ has joined #maemo-leste
uvos__ has quit [Ping timeout: 272 seconds]
<BlagovestPetrov4> sure, I'll try
<BlagovestPetrov4> the light is not good enough in the lab
<BlagovestPetrov4> there is an event and the people are coming. Later at home :)
rafael2k has quit [Ping timeout: 272 seconds]
<Wizzup> :)
<Wizzup> ok, I have realesrgan-ncnn-vulkan running locally, so I can upscale on my laptop (semi) automatically
rafael2k_ has quit [Ping timeout: 268 seconds]
<freemangordon> Wizzup: rescaling background was easy
<freemangordon> correctly positioning the buttons - still not ready
<freemangordon> will take some time
<Wizzup> freemangordon: I have the same problem with clock-ui :)
<Wizzup> freemangordon: uvos: if I make some "hd" theme, shall I create a new package for it, or a new version of the same package?
<Wizzup> i.e. do I make hildon-theme-beta-hd or just a new hildon-theme-beta release
rafael2k_ has joined #maemo-leste
<Wizzup> freemangordon: I think the themes (alpha, beta, devel) can maybe go with rafael2k_'s ringtones change
<Wizzup> whereever we end up placing it
elastic_1 has joined #maemo-leste
elastic_dog is now known as Guest9115
uvos has joined #maemo-leste
mardy has quit [Quit: WeeChat 3.5]
rafael2k_ has quit [Ping timeout: 272 seconds]
rafael2k_ has joined #maemo-leste
Twig has quit [Remote host closed the connection]
rafael2k_ is now known as rafael2k
<rafael2k> yay!
<freemangordon> Wizzup: why do we need both normal and h-d package?
<freemangordon> I think having only one should be ok
<uvos> h-d xD
<uvos> hd
<uvos> and yes 1 should be plenty
<Wizzup> freemangordon: ok, agreed
<Wizzup> hahaha well just upscaling every image didn't work ;)
<freemangordon> wait, you want to upscale everything?
<freemangordon> not only backgrounds?
<Wizzup> I was just toying around
<norayr> droid4 extended life battery is $89 on amazon. i remember there was a cheaper (~$25) link.
<norayr> my battery really sucks. :/
<Wizzup> got a link?
rafael2k has quit [Ping timeout: 252 seconds]
<norayr> minute
<buZz> quite sure thats fake
<buZz> well, maybe not :P
<uvos> those are real
<uvos> but they are really old
<uvos> dont buy it
akossh has quit [Quit: Leaving.]
<norayr> uvos, what do you do? soldev wires to other battery? and then connect the wires with screws to d4?
<norayr> isn't it dangerous to touch battery with hot things like soldering iron?
<uvos> well i solder some wires to my adapter pcb on one end and to some nikel strips on the other and then spot welded those to the battery tabs of a nexus 4 battery
<uvos> but others have had sucess with soldering the eb41 pcb to the tabs of a nexus 4 battery
<uvos> soldering to the tabs is not ideal but its ok if you keep the heat that sinks into the battery down
<uvos> also keep the nickel strips that are spotwelded to the battery, the main tabs are sometimes stainless steel and are going to be hard to solder to without special flux
uvos has quit [Ping timeout: 268 seconds]