topic title: BUG FIX LIST - beta3
anticapitalista
Posts: 5,955
Site Admin
Joined: 11 Sep 2007
#1
I put the feedback bugs into a file and the current status with the latest deb uploads (18.30 Greek time, 19-June-2015)


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://antix.mepis.org/index.php?title=User_articles"
linktext was:"http://antix.mepis.org/index.php?title=User_articles"
====================================
Posts: 4,164
rokytnji
Joined: 20 Feb 2009
#2
Maybe thinking faster than you are typing. Equalizer for what?
11. there is an equalizer in the control center, but it doesn't seem to actually modify the sound output. there is likely a asound.conf file missing from /etc to link the equalizer to hardware.
Just in case you missed it.

Man. That is lot of work. I got dizzy just reading it.
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#3
rokytnji wrote:Maybe thinking faster than you are typing. Equalizer for what?
11. there is an equalizer in the control center, but it doesn't seem to actually modify the sound output. there is likely a asound.conf file missing from /etc to link the equalizer to hardware.
Just in case you missed it.

Man. That is lot of work. I got dizzy just reading it.
equalizer for alsamixer.
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#4
32. Unpredicatble beaviour of network setup and conky CANNOT REPRODUCE
Previously reported and remains unaddressed post39696.html#p39696 This has been outsanding since antiX-14R-a4-a5 patch
I think we've been getting down to the root cause of this issue, being mostly that udev assigns device names at boot and stores the names in /etc/70-persistent-net.rules. I do believe this should be added to the machine specific state files save list (BitJam is aware, so hopefully that happened), so at least the names won't change between boots on the same machine.

Doesn't fix the conky issue though, unless the wired is always labeled eth0 and the wireless is always labeled wlan0. For the lion's share of users, this will be the case (even the atheros driver are using wlanX now), but a few combinations still allow ethX to be used for wireless, and in these cases unless 70-persistent-net.rules is preserved, those interface names can actually change on each boot. which messes up conky. Unless a variable can be used for the interface in conky (gw_iface returns the active interface, but I can't make it work with the monitors) then there isn't much you can do for conky. Some solutions on the net have been to include if statements that choose between eth0, eth1, eth2..... and wlan0, wlan1, wlan2..... but its ugly IMO.
Posts: 1,308
BitJam
Joined: 31 Aug 2009
#5
dolphin_oracle wrote:I think we've been getting down to the root cause of this issue, being mostly that udev assigns device names at boot and stores the names in /etc/70-persistent-net.rules. I do believe this should be added to the machine specific state files save list (BitJam is aware, so hopefully that happened)
Yes, that has been added. Here are the current default files. PLMK if you have any suggestions.

Code: Select all

# File: machine-state-files
# Machine specific files to be saved across reboots

/var/lib/alsa/asound.state
/ etc/udev/*-persistent-net.rules
# / etc/X11/xorg.conf

Code: Select all

# File: general-state-files
# Files to be saved across reboots and across machines

/ etc/wicd/*.conf
/ etc/NetworkManager/system-connections/*
/ etc/network/interfaces
/ etc/network/interfaces.d/*

/var/log/live/persist-save.log
/var/log/live/live-remaster.log

# / etc/passwd
# / etc/shadow
# / etc/group
# / etc/gshadow
Some solutions on the net have been to include if statements that choose between eth0, eth1, eth2..... and wlan0, wlan1, wlan2..... but its ugly IMO.
I don't know how to do that without causing a new line to be added to the display for each"if" block. That's why I limited it to eth0 and wlan0 which I think is fine for almost everyone. Perfect is the enemy of good.
anticapitalista
Posts: 5,955
Site Admin
Joined: 11 Sep 2007
#6
By the way, an apt-get dist-upgrade should bring in most of these changes.
Posts: 1,028
SamK
Joined: 21 Aug 2011
#7

Code: Select all

31. Re: IceWM Applet Monitors - FIXED, NO ISSUE?

Previously reported and remains unaddressed post40285.html#p40285
35. Clock in Taskbar IceWM - IS ONLY SAMK IS SEEING THIS?

Booted live with persistence When the bootup completes the clock is frozen at +1 hour ahead of local time. It remains in this frozen state (no increments for minutes) until IceWM is restarted via menu-->Logout-->Restart IceWM Wheh the restart of the WM has completed the fault is corrected,the clock is synchronised to the correct local time and advances in the expected manner.
"FIXED, NO ISSUE?" is incorrect, it has never been fixed.
This report demonstrates the matter resides is the chain of boot and or session files.
post41260.html#p41260
It is highly likely both matters have a common cause.
anticapitalista
Posts: 5,955
Site Admin
Joined: 11 Sep 2007
#8
SamK - (31 and 35) If nobody else can reproduce these bugs, how can they be fixed?
Posts: 1,028
SamK
Joined: 21 Aug 2011
#9
anticapitalista wrote:SamK - (31 and 35) If nobody else can reproduce these bugs, how can they be fixed?
The absence of evidence is not the evidence of absence. Often it highlights that additional investigation is required in order to uncover additional information.

Asking me how to fix the problem is aiming at the wrong target.

I recorded my attempts to:
  • Eliminate the hardware as a potential cause
  • Eliminate the upstream software as a potential cause
  • Reduce the scope of the source, which implicates the boot and session chain
  • Noted the action an end user can take to correct the symptoms once boot/session is loading is complete
  • Postulated that because the problem can be corrected by user action it can be resolved by action in the boot/session scripts
The people who are best placed to pursue the further investigation to a resolution of the issue are those who are most familiar with the boot and session chain i.e. those who designed and implemented it.
anticapitalista
Posts: 5,955
Site Admin
Joined: 11 Sep 2007
#10
Until someone else reports this bug, or knows a 'fix' then it will just get added to the release notes that it might happen.
Posts: 2,238
dolphin_oracle
Joined: 16 Dec 2007
#11
I can't reproduce sam's bug. I was initially focused on desktop-session since its a new part of the system, but after doing a little research, there is a relatively active maintainer for icewm who has been fixing old bugs in the icewm. The bug fixed between the wheezy version and the jessie version has to do with a buffer overrun condition in the cpu monitor tooltip. This fix was released in October. He has also been fixing bugs in the system tray launch, including race conditions in icewm-session.

Its quite possible that the maintainer's activity has introduced a new bug into icewm. He never specifically mentions the clock issue in the changelogs or bug reports though. Filing a bug report upstream
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://bugs.debian.org/icewm"
linktext was:"Icewm Debian Bug Reports"
====================================
might be a good idea.