Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - filip

Pages: [1] 2 3 ... 5
How To's / Re: How To: Building the VSIDO Installer
« on: March 24, 2018, 06:51:19 PM »
^ Thanks man.. sorry I missed that on the earlier post... and all those deb files are there I just saw the first keeptalking deb and installed that and never looked past my mistake

Sorry that I was so obtuse Filip.. I appreciate your help on this
No problem at all!  :)

It's funny how most issues are staring you right in the face and you don't see them

I´d say it´s not much of a problem per se, however the frequency at which it occurs.....  :D ;D

How To's / Re: How To: Building the VSIDO Installer
« on: March 23, 2018, 01:45:14 PM »
I have attached the built .deb file created and what I used ... in looking at the included file keeptalking_6.0.3~trios1_all.deb (in gdebi and xarchiver) I do NOT see a Locale directory or the file

I have also attached the keeptalking_6.0.3~trios1.tar.xz file and this DOES have the Locale directory and the file

This is a strange one.. I'm not sure what has happened but it has...  ::)
Keeptalking source produces three packages, "keeptalking", "python-keeptalking" and "python-t9n":
Code: [Select]
[filip@stretch-K10][/tmp/keeptalking]$ ls ../ | grep .deb
And "/Locale/" belongs in the "python-keeptalking".  ;)
Thus, you need all three installed and at the same version. I'd bet that "apt-cache policy python-keeptalking" shows it's an older version compared to "keeptalking"!?

Like I've said previously, "keeptalking" should really have versioned depends on the other two, so apt would complain if there's a version mismatch between any of them.
In other words, if you have "python-keeptalking" v=6.0.0 installed, and try to update only "keeptalking" to v=6.0.3 apt would complain and requre you to update "python-keeptalking" and "python-t9n" to v=6.0.3 as well.

Anyhow that's fixed in latest git (v=6.0.3~trios2).  :)

So, clone --> dpkg-buildpackage and then:
Code: [Select]
cd ../ && sudo apt install ./keeptalking_6.0.3~trios2_all.deb ./python-keeptalking_6.0.3~trios2_all.deb ./python-t9n_6.0.3~trios2_all.deb

How To's / Re: How To: Building the VSIDO Installer
« on: March 22, 2018, 07:13:08 PM »
Hi Filip..  There seems to be issues with the 6.0.3 version of the keeptalking.. I built it and installed it with no issues but had the same results on the first build of the ISO.  I confirmed from that livcd session that the keeptalking/Locale/ had the original and did not have the fix:

Code: [Select]
if "translit" in _file or "iso14651_t1" in _file or "POSIX" in _file or "cns11643_stroke" in _file: continue
I then checked it also in the build environment and confirmed that both 6.0.3 was installed and the fix was not there either

I manually edited the file and added the changes, rebuilt the ISO and it the install worked flawlessly

Need anything else, please let me know
It's most likely has something to do with the way you cloned git/built the package. I've just tested with the fresh clone, and the package (python-keeptalking) has the latest __init.py__ in question.

Steps I've followed ( on Stretch though, the issue you're having might also be Sid related ):
Code: [Select]
git clone && cd keeptalking
Verify that we're on "trios-master" branch:
Code: [Select]
git branch  #should output: "* trios-master"
Double check the fix:
Code: [Select]
grep cns11643 ./keeptalking/Locale/
#output:                  if "translit" in _file or "iso14651_t1" in _file or "POSIX" in _file or "cns11643_stroke" in _file: continue

Code: [Select]
dpkg-buildpackage -uc -us
Result (gdebi):


Also, do make sure that you actually included the 6.0.3 version of the "python-keeptalking" package in the ISO.
The reason I'm even mentioning this is that "keeptalking" package doesn't have versioned dependency on it, so you could install new "keeptalking" and keep the old "python-keeptalking" without apt complaining ( I should really fix this  :D )...

How To's / Re: How To: Building the VSIDO Installer
« on: March 20, 2018, 04:12:01 PM »
Meh, got it.  8) 
"/usr/share/i18n/cns11643_stroke" file appeared probably recently in Sid, causing "keeptalking" to stumble over it. It is now properly ignored, so the issue should be fixed.
All you need to do is build the updated "keeptalking" package(s), version 6.0.3~trios1, using the usual mantra, git clone --> dpkg-buildpackage...

How To's / Re: How To: Building the VSIDO Installer
« on: March 20, 2018, 03:35:43 PM »
"Keeptalking" module is at blame here.
Something is going wrong with locale list building. Probably something changed in Sid/locales making the keeptalking parser read garbage/lock itself in an endless loop.

I'll resume hunting tonight, hopefully having it by the head by the end of the day.  :)

How To's / Re: How To: Building the VSIDO Installer
« on: March 19, 2018, 03:24:49 PM »
From terminal the only thing showing is

Code: [Select]
Hmm, it's unusual for Python not to output any error(s), so it may actualy be somewhere outside...
But anyhow, it would be most helpful if you could upload the latest build/ISO somewhere for me to download and see what's up!?
Updating the live system is a pain and likely won't produce the same environment as the prebuilt one. :)

Hey filip...

On the first pass that seems to be the fix... testing the rest now

Thanks for the heads up!

Well, for a change, I guess it was ´bout time for an easy fix...  ::) ;D

The solution to this was installing python-debconf

The split broke python3-debconf which had already been installed and used since the beginning of VSIDO

Why the dev would not take into account both needs and make one or both a dependency is beyond me...


Thanks again to filip for the help
No idea, though the split seems uneccessary to me. After all, both packages install the very same "" ( it´s compatible with both Py´s ), just to different locations...
Perhaps they wanted to drop Python dependencies from "debconf" package...  ::)

You´re welcome, anytime!  :)

I´m away from any PC running Debian ( including my own ), so going blind here.

There was a recent split of debconf package into Py2 & Py3 versions ( changelog ) so it´s most likely related to that.
Either the module was renamed ( thus the "import" fails ), or the package itself is not installed.

Code: [Select]
apt install python-debconf... will fix the issue.  :)

General Support / Re: SpaceFM freezes
« on: July 21, 2017, 11:46:51 PM »
Thanks filip for that info.. have you tried SpaceFM-NG?
Yep, like I've said above, been running GTK2 build without any issues.  :)
Code: [Select]
[filip@stretch-K10][~]$ apt-cache policy spacefm && echo "" && ls -lh /var/lib/dpkg/info/spacefm.list
  Installed: 1.0.6
  Candidate: 1.0.6
  Version table:
 *** 1.0.6 100
        100 /var/lib/dpkg/status
     1.0.5-2 500
        500 stretch/main amd64 Packages

-rw-r--r-- 1 root root 4,7K Feb 16 16:09 /var/lib/dpkg/info/spacefm.list
IgnorantGuru is one of the best individuals I have had the pleasure knowing in this small FOSS community we all share

I couldn't agree more!
Too bad he stopped working on SpaceFM, though he's been on hiatus before ( keep the hope alive, eh ), and ofc there's the fork now... :)  :D

General Support / Re: SpaceFM freezes
« on: July 21, 2017, 11:19:50 PM »
There's a fork (SpaceFM-NG), and a new bugfix 1.0.6 release from ~March, though it hasn't been touched since ( let's hope the guy picks it up eventualy ). 8)

Status update from IG:

If anybody tries to build a .deb package from NG repo, keep in mind that changelog is still at v1.0.5, so you should apply some "dch -i" magic on it to avoid apt "downgrading" it. ;)

I've been running GTK2 build since it was released without any issues ( on Stretch though ). :)

Zenity & Yad / Re: PMRP UI yad
« on: May 07, 2017, 08:36:44 PM »
Thanks.  :)
mpv - That's a great idea! mpv has a remote (somewhere :)) ), I will dig into documentation.

Between the couch cushions perhaps!?  ;D :D :D

Joke aside, I did take a quick look @docs/google, but didn't find anything. The "bad" here is that MPV has support for real remote controlers ( the hardware ones ), which is the main hit on Google, making the shell "remote" we need here hard to find... And the docs are longer then the Bible...  ;D

Close to tray - It's easy to close it, bringing it back is another story  :D  :D  :D
                          Will see about that. It's a good option to have a radio that stays out of the way.

"Kill to tray" ;D ;D

Maybe if there is an easy way to keep information about current station/log etc somewhere it might be doable with something like ( untested, just a thought ):

Code: [Select]
function main() {

# main dialog stuff in here with the "--button=Close!close:1" & "DATA" appended somehow
# main dialog stuff in here with the "--button=Close!close:1"

if [[ "$RET" == 1 ]]; then
export main

function window_toggle() {
# called on tray left click
if [[ "$WIN_VISIBLE" = true ]]; then

The bad side with the above is that you cannot click the tray icon to toggle the window. In other words, window needs to be closed the usual ways, and can only be brought back from tray with the "on tray" click.
Hope it helps some. :)

What I may end up doing is keeping the x32 build platform up to date in the even anyone should ever need it but would only be by request.. it is a simple process that is pretty much scripted

I would then only maintain an ISO for standard x64 and uEFI x64...

As far as I'm concerned, go for it! :)

Though you could also reduce the release frequency for 32bit to say, 3-4 releases per year or whenever some nasty breakages occur in Sid.
That way you'd provide a smoother transition for users, and eventually if nobody complains, ditch it all together or switch to "per request" builds only. :)

Great info and explanation Filip... Thanks mate

I do not mind the extra half hour of build and test time to have a uEFI option.. IMO a better question is why on earth is there a need for a 32 bit version at all

Lets debate that one

Anytime! :)

Well, personally I don't care about it anymore, nor see any real use-case in the desktop arena for it.
I have a great attachment to my Athlon-XP machine ( that was my first ever CPU ), however the growing pains coming from the lack of SSE2 instructions and the abysmal performance ( browsers, gtk3 etc ) simply killed all the joy in using & playing with it, so I just gave it up post Deb Jessie.

IMO, 32bit has become, or is slowly but surely becoming a niche/legacy arch, and should perhaps still be supported by the big players only ( Debian et al ).
Of course, I'm not trying to be provocative or something, there are still legitimate use cases, and users that really need the 32bit, however those numbers are low and getting lower by the day to justify the effort required by the distro maintainers ( excluding major players who can afford it ).

And not to mention that using a 32bit distro on a 64bit capable machine is just a pure waste of resources and performance. Further exaggerated by the fact how cheap RAM is these days ( so "higher RAM usage for 64 bit" doesn't really hold any more ).

Zenity & Yad / Re: PMRP UI yad
« on: May 05, 2017, 11:44:50 PM »

Nice work!  :) :)

Couple of notes/ideas:

1. I don't know for sure whether "mpv" has a remote control, however if it does it might be much better then "mpg123" ( atleast there woudn't be a "Quit lag" )
2. "Close to tray" would be awesome, though AFAIK it's not (yet) possible with YAD??  ???

^ Good question... I can install to normal hw with the uEFI ISO but something goes amuck with grub.. I get the grub rescue screen...

That's the GRUB EFI vs GRUB BIOS issue.
See, having any GRUB variant preinstalled on the Live squash.fs image essentially locks you to that variant ( BIOS or UEFI ).
Installer, on the other hand is designed with the single ISO supporting both in mind, and works in the following way:

1. You don't have any GRUB installed @squash.fs
2. You do have all grub packages, "efibootmgr" and "os-prober" in the "support" dir on the ISO image root.

Then, during installation installer sets up a temporary Apt repository from the ^"/support" and installs apropriate GRUB for the machine from there.

Btw, installer-wise, there's nothing wrong with the separate ISO's aproach, except for that "issue" of being usable only for the targeted machines/BIOS types. :)

Pages: [1] 2 3 ... 5