AntiX 15 b3-V - Page 9

SamK · posted: 2015-06-10 12:56

Re: IceWM Applet Monitors

Previously reported and remains unaddressed

post40285.html#p40285

SamK · posted: 2015-06-10 13:18

Unpredicatble beaviour of network setup and conky

Previously reported and remains unaddressed
post39696.html#p39696
This has been outsanding since antiX-14R-a4-a5 patch

Does anyone else have this issue?

SamK · posted: 2015-06-10 13:26

Main Menu Header Items

Previously reported and remains unaddressed
post39379.html#p39379
The inclusion of Menu Manager now makes this particularly easy to do.

dolphin_oracle · posted: 2015-06-10 13:31

SamK wrote:Unpredicatble beaviour of network setup and conky

Previously reported and remains unaddressed
post39696.html#p39696
This has been outsanding since antiX-14R-a4-a5 patch

I'm going to go out on a limb here and say that this is on the system where your wireless and wired network interfaces both get assigned ethX type names? I've been working on a potential solution using BitJam's new"machine state" type persistence info, which allows saving configuration files on a per-machine basis.

Have a look at / etc/udev/rules.d/70-persistent-net.rules and see if your interfaces are defined in there. Post the output if you like. What I'm looking for is if you are using persistence and that sometimes your interfaces switch names (which is totally allowed by udev these days). The 70-persistent-net.rules file is not currently saved by either the remaster or persistence system, which solves a naming convention problem on machines where wired is on eth0 and wireless is on wlan0. Also, the conky monitors look for the wired display on eth0 and the wireless on wlan0 (hardcoded). If you edit the conky file and do a search and replace on the respective interface name and replace with your actual name, the monitors will work. I get a similar issue running with persistence and switching machines. Each additional machine's interface names get incremented by 1 (eth1, wlan1, eth2, wlan2).

This whole thing is less of a problem on installed systems, because we aren't deleting 70-persistent-net.rules every shutdown.

SamK · posted: 2015-06-10 13:35

Re: ROX-Filer Text colours

Many thanks for making these much easier to read straight-out-of-the-box
post40189.html#p40189

SamK · posted: 2015-06-10 13:43

Re: Setting a solid colour instead of wallpaper image

Previously reported and remains unaddressed
post40186.html#p40186
post40188.html#p40188

SamK · posted: 2015-06-10 14:00

ROX-Filer Send to Matters

Select a file in ROX
Right Click-->Send To-->New Window as root
Fails

Affected script
/usr/local/bin/rox-as-root.sh
due to removal of ktsuss in antiX-15

Also in Send To menu
Encrypt-Decrypt
Not sure what this is meant to do but it does not seem to be doing it.

SamK · posted: 2015-06-10 14:15

~/.xinitrc-custom

Is this correctly"plummed-in"? I can't get anything to run from it.

SamK · posted: 2015-06-10 15:11

Re: Desktop Icons

Previously reported but unaddressed
Not one of my reports but I can confirm it is still present

Booted live
Intermittently and unpredictably the desktop icons fail to display once bootup has completed.

skidoo · posted: 2015-06-10 15:18

Sam, Test3 results are fine, they are as expected.
I should make shorter posts, with attention to not mixing apples-and-oranges.
At the point of typing the (intended) ======== divider in my prior post, I was beyond suspecting MenuMaker.

SamK · posted: 2015-06-10 15:19

Re: Unpredicatble behaviour of network setup and conky

dolphin_oracle wrote:I'm going to go out on a limb here and say that this is on the system where your wireless and wired network interfaces both get assigned ethX type names?

Yes, thats correct (you picked a pretty thick and safe limb).

dolphin_oracle wrote:What I'm looking for is if you are using persistence and that sometimes your interfaces switch names (which is totally allowed by udev these days).

Yes, using root and home persistence.

Current configuration that works

Code: Select all

ca / etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:14:22:89:f8:ce", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x4220 (ipw2200)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:ce:b9:90:bb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Because of the capricious nature of the condition I cannot force the failure state to post the content of the file.

dolphin_oracle wrote:Also, the conky monitors look for the wired display on eth0 and the wireless on wlan0 (hardcoded). If you edit the conky file and do a search and replace on the respective interface name and replace with your actual name, the monitors will work.

Hard coding sounds a sub-optimal way to do this.

The hard coding will be used in both persistent and non-persistent cases of a live session. This means the use of hard coding guarantees a failure of conky at least some of the time. It also means there will never be an ideal partnership of antiX and conky when used in a truly nomadic manner which in my opinion is one on the primary purposes of having a distro on a stick.

dolphin_oracle · posted: 2015-06-10 15:39

Code: Select all

ca / etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:14:22:89:f8:ce", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x4220 (ipw2200)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:ce:b9:90:bb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Yep looks about right. The eth0 and eth1 are mapped to devices by their MAC address (which is unique per device). If you comment out this file to the persistence excludes files (now available in the live-control center) then the unique naming will be preserved on that machine.

however, if you do this, then the next machine you use will increment the interface numbers (so a wired interface in this case might be on eth2).

in /live/boot-dev/antiX there is now a state folder. If you add the 70-persistent-net.rules file to file machine-state-files in that folder, then that file will be saved on a machine by machine basis, but only if you exclude it from persistence first.

I'm having good luck with this so far. I've only had one hiccup, and I think that was due to a power failure. Its best to set this up on a fresh liveUSB.

As a sort of bonus, the machine state files are saved weather persistence is enabled or not (obviously not a liveCD) there will be a switch in the future to disable the feature so you can get a perfectly fresh setup.

edit- my machine-state-files looks like this:

Code: Select all

/var/lib/alsa/asound.state
/ etc/udev/rules.d/*-persistent-net.rules

skidoo · posted: 2015-06-10 16:00

This post is about"add-desktop" script, labeled"Add Menu Item" in the desktop Preferences submenu.

I incorrectly typed"TCM" in this earlier post:

skidoo wrote:...forevermore-ignored .desktop files accumulate in the local/share..TCM path?

The failed"add-desktop" attempts result in .desktop files accumulating here:
/home/demo/.local/share/applications/custom
and as I discovered, these .desktop files are not"forever" ignored ~~ they wind up being detected later, if that other tool (MM) is used.
Someone pointed out"doesn't happen automatically, you need to run UpdateMenu".
I understand that, and the failed result of UpdateMenu subsequent to having used"Add Menu Item" is central to the bug I'm reporting.

At this point, until someone explains otherwise, my takeaway is this:
The version of the add-desktop script that shipped in the beta contains a newly-revised GUI with inputs to enable"Item Location" selection
but the shipped version of the"Update Menu" script doesn't yet check"TCM" and/or"custom" dirs when scanning for .desktop files.

BitJam · posted: 2015-06-10 16:28

SamK wrote:~/.xinitrc-custom

Is this correctly"plummed-in"? I can't get anything to run from it.

No it's not. It is a leftover from olden days and should be removed. I think Dave is currently finalizing (or has finalized) which scripts get executed when X starts up.

SamK wrote:Re: fbxkb
Boot Live with root persistence
After boot up the system always shows an incorrect national flag icon.
When the UK has been selected in the boot screen, the GUI (X) consistently starts with the flag of the USA an remains in this state.

There is a known bug in fbxkb where it always gives you the US flag until a key is pressed. After a key is pressed then it displays the correct flag. Fixing this known bug is a low priority. If the problem you are reporting is more serious, please provide steps to reproduce it.

Dave · posted: 2015-06-10 16:45

SamK wrote:Re: Setting a solid colour instead of wallpaper image

Previously reported and remains unaddressed
post40186.html#p40186
post40188.html#p40188

The rox and spacefm command line I interfaces do not support color codes, only image files. If you know of a command line way (from terminal) to set a color instead of an image for rox or space I can update the wallpaper app.