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 4
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. :)

Conky / Re: conky and yad - some possibilities
« on: May 05, 2017, 11:23:44 PM »
I think the issue here is that Conky waits for the command to return, which YAD doesn't since it's sitting active in the tray.
You should be able to confirm this by clicking the tray icon ( default is to quit on click ) after which Conky should redraw/show.
If so, then I don't think you can easily work around it.

On the other hand, going the regular bash route, something like this should do the job:
Code: [Select]

PIPE=$(mktemp -u --tmpdir ${0##*/}.XXXXXXXX)
mkfifo $PIPE

exec 3<> $PIPE

function exit() {
    echo "quit" >&3
    rm -f $PIPE
trap exit EXIT

# "--command" is left empty with the purpose of
# disabling "Quit on left click".
# You can still middle click to quit.
yad --notification                  \
    --kill-parent                   \
    --listen                        \
    --image="gtk-help"              \
    --visible=false                 \
    --text="Tooltip text goes here" \
    --command="" <&3 &

function battery_check() {

# BATTERY=$(command to get battery percentage)


while true; do
    if [[ "$BATTERY" -le 10 ]]; then
        echo "icon:battery_empty" >&3
        echo "visible:blink" >&3
        echo "visible:false" >&3
    sleep 10s

I'm not using a laptop and don't know the command to get battery percentage, so you'll need to fill that in @"battery_check" function.
Also, it won't get anywhere close to hogging the RAM or the CPU, as long as you don't go wild with the "sleep" inside the "while" loop ( low intervals like "sleep 0.1s" ).

Feedback & Suggestions / Re: Connman network manager GTK frontend
« on: April 19, 2017, 03:09:07 PM »
Awesome filip!

Like it!

Looks better than connman-ui


Indeed, it's awesome really. Looks good, stays out of the way and it's usable when needed.  :)

Btw, I haven't mentioned it here, I'm not the actual author.
I just packaged and patched it to enable window toggling from tray icon.

Looks good.

One item though, don't mean to nit-pick but on your git page you have:


 GTK >= 3.10

Shouldn't connman be on the list, this isn't a stand alone application is it?

Well, it should be, though it implies itself since it's a front-end for it ( not a stand alone )...
Anyhow, it's fixed now.  :)

Successfully compiled it on Void Linux.

Nice work.

I'll have to run connman for a while; much smaller memory footprint than NetworkManager or wicd.

Also seems to require root privleges to connect/roam with wireless. Will that be the case on Debian as well?

I'm using it for atleast 6 months and honestly have no idea it's even there. The damn thing JustWorks™.  :D

As to WiFI & root, I wouldn't know since I don't have a WiFi to test ( desktops on LAN all around ).
Though ( on Debian atleast ) I am finding it odd that the "connmanctl" command is installed in /usr/sbin ( thus requiring root privileges )...  ::)
For example, on Arch it goes to /usr/bin...

With that said, you may try to symlink it to /usr/bin:
Code: [Select]
sudo ln -s /usr/sbin/connmanctl /usr/bin/connmanctlI'm not sure that the front-end will even look for it there ( both connman and GUI might need rebuilding for this to work ).

And, after symlinking do verify that it actually works without root:
Code: [Select]
connmanctl scan wifi; connmanctl services
and then try to connect to one of WiFi's listed with:
Code: [Select]
connmanctl connect wifi_xxxxxxxxxx
Also, see:

Feedback & Suggestions / Connman network manager GTK frontend
« on: April 15, 2017, 08:57:08 PM »
As promised in the installer topic, I've pushed the connman-gtk to git, including debian packaging and a small patch allowing main window to be toggled by clicking the tray icon.

For details and more screenshots see:

Build instructions:

1. Clone & cd:
Code: [Select]
git clone && cd connman-gtk
2. Install build deps:
Code: [Select]
mk-build-deps --install ./debian/control      # if "mk-build-deps" is missing install "devscripts" package first
3. Build and install:
Code: [Select]
dpkg-buildpackage -j$(nproc)
Code: [Select]
cd ../ && sudo apt install ./connman-gtk_1.1.1-2_amd64.deb
Enjoy & god-forbid there be any issues, let me know!  :)

@filip Great work on the installer  8)
Keep it up  :)


Thank you!  :)


The "resume device" hang propagated to Stretch as well. And for once it actually has nothing to do with systemd.
You were right, issue was introduced in "initramfs-tools", v128 in order to fix the bug where some NVMe drives were slow to enumerate partitions causing the system to fail to resume from hibernation...

See changelog and a bug report.

The weird part is the wait time they've set ( ~20sec ). I mean what for, seriously!? Even the guy who reported the bug said that adding a 1sec delay fixed the issue for him...  ::)

Anyway, until they sort it out, the quick fix is to add the "resume=/dev/sdXY" to the "GRUB_CMDLINE_LINUX_DEFAULT" in "/etc/default/grub" file, where "/dev/sdXY" is your swap partition ( worked for me atleast @Stretch ).  :)
You might even get away with any partition ( not just swap ), as long as you don't have any data on it ( untested!!! ).


I've also looked at the actuall shell scripts used, however I'm having a bit of a hard time reading them ( I've never really understood why Debianers always write shell scripts in such obfuscated and "hard to read" way  ::) ).
I'll let you know If I get anywhere with that...

I do not have that on any line, I do not use swap and never ever have used hibernation even when I do use a laptop

This has also started to happen on this my build machine that is also completely up to SID levels..

This is nothing new in SID, just a hiccup that is only a concern if someone boots VSIDO on a new install and does not wait the 20 seconds on the boot and gets frustrated..


Yeah, it's some update ( possibly systemd ) related then. :)

... I do not always cover that anymore.. Simply, I have been selfless forever and it has gotten me nowhere

No problem!
I know that feeling...  ::)

To answer your question I did solve the network issue on V-Box with a tweak to a refracta file used in building the ISO

Great, thanks!  :)

Be aware that on the latest SID updates (and on VSIDO installs with the new ISO) there is a delay of about 20 seconds and then a message

Code: [Select]
gave up waiting on suspend/resume device
and then it boots normally

Not sure where the message even comes from as it is immediate .. possibly initramfs update but I am not sure

It is not causing any issues other than a blank 20 second delay.. strange one I have never seen before

Does NOT happen boot of ISO to LiveCD, only after installed..

It could also be an SSD issue since that is what I am running on

Try this:

1. Reboot
2. Remove "resume=/dev/sdxy" from kernel cmdline ( press "e" when grub shows, then find it on the "linux" line and remove ) & hit F10 to boot.

If the error goes away, and you haven't formated/deleted/moved the swap partition, then it's likely some systemd bustage ( though changelog doesn't indicate anything related ).

When you hibernate your machine, RAM content is dumped onto the swap partition for a persistent storage. Then, when you turn back on, "resume=/dev/sdxy" line is used to point the kernel to that partition as the resume device containing the previous state.

So, if you're not using hibernation, it's safe to remove the same line from "GRUB_CMDLINE_LINUX_DEFAULT" in "/etc/default/grub" file, and then run "update-grub", however do keep in mind that if you ever hibernate the machine, it will NOT resume into previous state, but boot normaly instead! :)
Otherwise if you moved your swap, correct the "/dev/sdxy" in the same file & update-grub.

Pages: [1] 2 3 4