| brocashelm | any other way to have access to the trash dir without gvfs (xfce)? or assign a dir for "soft deletes"? | 04:38 |
|---|---|---|
| golinux | brocashelm: I've given up using Trash entirely. I go straight for the right click Delete option | 04:47 |
| brocashelm | golinux: i almost wonder if a thunar custom action would suffice... | 04:51 |
| golinux | Possibly. I have several of them | 04:52 |
| gnarface | a while back there was an undelete tool that was specific to some version of ext | 04:56 |
| gnarface | hmm, maybe still present; is see a package named "extundelete" | 04:57 |
| gnarface | might suffice if you are using ext3 or ext4 | 04:58 |
| brocashelm | i've apparently had it installed long ago | 05:06 |
| onefang | Or just try another file manager and access that Trash directory with it. | 07:15 |
| onefang | brocashelm: ^ ^ | 07:15 |
| systemdlete72 | I would ask where is the documentation for udev rules.d but I'm sure that would only draw laughter. I've looked over the udev man page and it is clear as mud. I am trying to give my usb ethernet devices persistent serial numbers so they can be uniquely identified. So far, I've tried variations of "SUBSYSTEM=="net" | 07:57 |
| systemdlete72 | KERNEL=="enx8cae4ce140fa" DRIVER="" SUBSYSTEMS=="usb" SUBSYSTEMS="usb" DRIVERS="usb" ACTION="add" ATTR{address}=="8c:ae:4c:e1:40:fa" ATTRS{serial}="1234567890 | 07:57 |
| systemdlete72 | What is unclear to me is just which fields must match and how to deal with attributes in the parent of a parent in the chain | 07:58 |
| systemdlete72 | sorry, I mean not chain, but device path | 07:58 |
| systemdlete72 | And, yes, the serial is the ONLY field I can use for my purposes. The others will not work for me. | 07:58 |
| systemdlete72 | The mac address is in the udevadm info output listing for enx8cae4ce140fa, but the serial is in the parent of the parent of that item. | 08:00 |
| systemdlete72 | (not sure what each piece is called, sorry) | 08:00 |
| systemdlete72 | Honestly, I don't even know if what I am trying to do is permitted. | 08:01 |
| onefang | The Arch Wiki is usually pretty good docs for lots of things, worth checking them out. | 08:03 |
| systemdlete72 | thanks | 08:03 |
| onefang | https://wiki.archlinux.org/ | 08:03 |
| systemdlete72 | (looking at it now) | 08:09 |
| rrq | systemdlete72: should be enough with: ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="your mac", NAME="your name" | 08:17 |
| rrq | put in some 72-blaha rules file | 08:17 |
| systemdlete72 | Not trying to change the NAME, trying to change ATTRS{serial} | 08:17 |
| systemdlete72 | We can leave the name as-is | 08:17 |
| rrq | hmm the serail of the device or the serial held in the udev tree? | 08:18 |
| systemdlete72 | Well, from what I can see, theree are two serial fields, one in the grandparent and another one for the parent of THAT. | 08:19 |
| systemdlete72 | the grandparent is the one I want to change. I think the other one is for udev's internal use | 08:19 |
| systemdlete72 | rrq: Thanks for the help. I'm totally lost with this. | 08:22 |
| rrq | afaiui ATTR{*} referes to the current node attributes and ATTRS look up from the current leaf into the tree. Any assignment would be with ATTR, when that is the node being made | 08:23 |
| systemdlete72 | The MAC address is found in the lowest node of the device path, but the serial number for the DEVICE is 2 levels above. | 08:23 |
| systemdlete72 | The serial is not in the lowest node, though. It is 2 levels up. | 08:24 |
| systemdlete72 | So that's why I tried ATTRS{serial} -- not sure if there even is a ATTR{serial} | 08:24 |
| rrq | ok, well, there is a point/time in the udev traversal when that "2 levels up" is the current node, and that's when the assignment may be done (I think) | 08:24 |
| systemdlete72 | Do I need to use the IMPORT key? | 08:26 |
| systemdlete72 | or are you telling me that all the parent and on up stuff is automatically searched. I think I read that in the docs | 08:27 |
| rrq | no... maybe just an ATT{serial} at the leaf level would work; that would shadow the g-p one | 08:28 |
| systemdlete72 | Literally "ATT{" or did you mean "ATTR"? | 08:28 |
| rrq | ATTR{serial} | 08:28 |
| systemdlete72 | Here is my latest attempt: SUBSYSTEM=="net", KERNEL=="enx8cae4ce140fa", SUBSYSTEMS="usb", DRIVERS="usb", ATTRS{serial}="1234567890" | 08:29 |
| systemdlete72 | rrq: Do you have a usb ethernet thingy you can try where you are? | 08:29 |
| rrq | ah yes I do have one somewhere .... I'll try | 08:30 |
| systemdlete72 | thanks! | 08:30 |
| systemdlete72 | I just tried with ATTR and ATTRS, neither worked. just fyi | 08:30 |
| rrq | (found the dongle) | 08:32 |
| systemdlete72 | whohoo! | 08:32 |
| systemdlete72 | :) | 08:32 |
| rrq | ID_SERIAL=0fe6_USB_2.0_10_100M_Ethernet_Adaptor | 08:34 |
| systemdlete72 | what are you looking at? | 08:35 |
| systemdlete72 | is that the output of udevadm info? | 08:35 |
| rrq | udevadm monitor -p | 08:35 |
| systemdlete72 | oh | 08:36 |
| systemdlete72 | so how to apply that knowledge? | 08:36 |
| rrq | wisely ? :) | 08:37 |
| systemdlete72 | heheh. Sure, why not? | 08:37 |
| rrq | so is ID_SERIAL the thing that you want to be different? | 08:38 |
| gnarface | not sure you are allowed to overwrite those | 08:39 |
| gnarface | thought you had to use ENV{*} | 08:39 |
| systemdlete72 | the format of the output from udevadm info is a bit different than the format of rules.d files | 08:39 |
| systemdlete72 | so I am not sure how to "map" that | 08:39 |
| rrq | gnarface: "not allowed" sound like a challenge :) | 08:40 |
| rrq | but yes, I think the ID_* attributes are pulled from the h/w | 08:40 |
| systemdlete72 | and rrq, there are 2 fields related to something called "serial"-- there is ID_SERIAL and ID_SERIAL_SHORT. I think the latter matches, more or less, the ATTRS{serial} field | 08:41 |
| systemdlete72 | (to answer your question) | 08:41 |
| rrq | why do you want it different? | 08:42 |
| rrq | (I don't have an ID_SERIAL_SHORT) | 08:43 |
| systemdlete72 | so I can uniquely identify them. E.g., I have several of these usb-ethernet devices. Several of them, under different brands, are ASIX ax88179 based chipsets. The problem is that some of them have full serial numbers, like the one I have been using as the example, and others have just "00000" or nothing at all in the serial field. | 08:44 |
| systemdlete72 | I would use the MAC address, if I could, but that will not work for the application. | 08:45 |
| systemdlete72 | (sadly) | 08:45 |
| systemdlete72 | (because that would make this way easier) | 08:45 |
| systemdlete72 | rrq: I m on a chimaera box doing this. | 08:46 |
| systemdlete72 | So maybe the output is a little diff, idk | 08:46 |
| rrq | I think as gnarface said that the rules will have to peep at the ATTR and ATTRS and end up with setting ENV{*} values | 08:46 |
| systemdlete72 | when you say ENV{*} values, do you mean ordinary shell vars? | 08:46 |
| rrq | let me test something | 08:47 |
| systemdlete72 | sure, tyt | 08:47 |
| systemdlete72 | I notice something. If I type it in as ATTR, vim's coloring scheme shades it blue. The other fields are in yellow. But if I type it in as ATTRS, it turns yellow, like the others. | 09:02 |
| systemdlete72 | If vim is at all accurate with its color scheme, I'd say that ATTRS{serial} is correct, not ATTR{serial} | 09:02 |
| rrq | hmm I'm yet to be able to change any attribute or anything | 09:05 |
| systemdlete72 | that's ok. This probably won't be easy, if it is doable at all. | 09:07 |
| systemdlete72 | rrq: Are you on chimaera or another version? | 09:07 |
| systemdlete72 | ceres? | 09:08 |
| rrq | chimaera with some extras | 09:08 |
| systemdlete72 | ok, just checking. | 09:08 |
| systemdlete72 | Might as well work on the latest | 09:08 |
| rrq | it seems udev has changed since last I dealt with it and I'll need to re-learn :( | 09:10 |
| systemdlete72 | Just discovered "udevadm test" -- I think it is telling me the problem: Invalid subsystems operation | 09:13 |
| systemdlete72 | Maybe I need an ACTION ? | 09:14 |
| rrq | that's to recognize which action, like add or move or bind | 09:14 |
| onefang | Anyone know about a sequential timer app for Devuan or Android (prefer F-droid)? That is start a timer for A minutes, when it triggers a sound happens and notification "time to do A", only after A triggers does timer B start, after B minutes it triggers a sound and notification "time to do B", until it runs out of timers. And you can setup multiple of those, so one for doing task X, one for doing task Y, | 09:15 |
| onefang | etc. I can't believe there isn't such a thing. | 09:15 |
| systemdlete72 | rrq: Or maybe I need a valid operation -- maybe it doesn't like me trying to set an attr | 09:16 |
| systemdlete72 | ATTRS{serial}= blah | 09:16 |
| * onefang comes back from the kitchen, having done step A, manually sets the timer yet again for step B. lol | 09:17 | |
| rrq | if you can set that attribute in the /sys/ tree then it should be fine, otherwise not; well, used to be | 09:17 |
| systemdlete72 | I don't see anything named serial under /sys | 09:21 |
| systemdlete72 | oh wait | 09:21 |
| gnarface | systemdlete72: i mean literally ENV{SERIAL}="00000" | 09:21 |
| gnarface | only, i'd probably choose something a little more obscure than a dictionary word commonly used in this context just to avoid possible collisions | 09:22 |
| systemdlete72 | gnarface: But where would that envar be picked up? Would I need to use a RUN script? | 09:22 |
| gnarface | oh, i thought you'd be picking it up in another udev rule or something, i didn't really think it out that far | 09:22 |
| gnarface | i was writing rules for a steam controller and some tip to get around some random game bug was to set ENV{ID_INPUT_JOYSTICK}="1" | 09:23 |
| gnarface | it's the only thing i've ever successfully managed to set other than the group and the permissions | 09:23 |
| gnarface | so, i presumed somewhere in the kernel api there was a way to pull environment variables contextually specific to certain devices | 09:24 |
| systemdlete72 | so /sys/devices/pci0000:00/0000:00:12.2/usb1/1-5/serial contains the serial number | 09:24 |
| systemdlete72 | I cannot write to it though, so I think I am S.O.L. | 09:25 |
| systemdlete72 | (and, yes, I tried it as root) | 09:26 |
| gnarface | yea i wouldn't have expected you to be able to change anything already there, i would expect you to have to add an entirely new variable, whether it was to ATTRS or ENV, i assumed you had some way to pull them elsewhere already | 09:26 |
| gnarface | if it has to be the serial number i wouldn't be surprised that you might have to modify the driver itself | 09:27 |
| systemdlete72 | But will a "variable" become part of the device info that can be accessed later? | 09:27 |
| systemdlete72 | I don't think it would... | 09:27 |
| gnarface | well you can try adding a new one to ATTRS and see if it shows up in /sys/ | 09:27 |
| systemdlete72 | but that will not be the one that is accessed later on. | 09:28 |
| systemdlete72 | It will be ignored because the program will not know about it or be looking for it. | 09:28 |
| systemdlete72 | I may have to look at a different approach altogether. | 09:28 |
| gnarface | so the program *only* can look for the serial? | 09:28 |
| gnarface | maybe it's easier to change the program | 09:28 |
| systemdlete72 | (Unless rrq figures out a way) | 09:28 |
| rrq | maybe creating symlinks ? | 09:28 |
| systemdlete72 | No, not really. It's proprietary... | 09:29 |
| gnarface | symlinks, interesting... | 09:29 |
| systemdlete72 | some of it is open source, but it would be shot down by its owners | 09:29 |
| systemdlete72 | symlink? How will that help? | 09:29 |
| systemdlete72 | I'd only be able to chnage the new variable, so linking to it won't do much good | 09:30 |
| systemdlete72 | change* | 09:30 |
| systemdlete72 | I mean, that is a novel idea, but I don't see how that will hep | 09:30 |
| systemdlete72 | help | 09:30 |
| rrq | mmm I can't even get that to happen... :( seems like whatever I knew of udev is no longer relevant | 09:35 |
| systemdlete72 | I hear udev was designed by the same "people" who brought us some other doozies | 09:36 |
| systemdlete72 | but I could be wrong | 09:36 |
| systemdlete72 | So I am not surprised we are limited in what we are permitted to do. | 09:37 |
| systemdlete72 | Like golinux said, point and click and take whatever (few) options the overlords will allow. | 09:37 |
| systemdlete72 | I will seek a different solution. Thanks, rrq and gnarface. | 09:38 |
| gnarface | the program won't let you just pick a /dev/ file? | 09:38 |
| systemdlete72 | nope | 09:41 |
| gnarface | what's the actual driver? maybe there is a module parameter to set it... long shot but worth a try | 09:42 |
| systemdlete72 | proprietary | 09:42 |
| gnarface | my best google-foo says the only way to change the actual serial is a windows-only tool that can flash the firmware of the device directly | 09:42 |
| gnarface | only works for 3 brands | 09:43 |
| systemdlete72 | right. I saw that also. | 09:43 |
| systemdlete72 | So that will not be an option either. | 09:43 |
| systemdlete72 | Like I said, I will keep looking. | 09:43 |
| systemdlete72 | I find it a bit ironic, funny even, that with all the complexity of this frankenware that a simple thing like this cannot be done fairly easily. | 09:44 |
| onefang | Guess I should have waited for some quiet time before asking about sequential timer apps. lol | 09:46 |
| gnarface | onefang: sorry i would just probably hack together a chain of scripts that kick off from an initial cron or at job... if there was some risk of them overrunning each other i'd add lock files | 09:51 |
| onefang | Writing a script is an option, I'm just very surprised no one has written something like that. A single script could do it, with no need to get fancy. | 09:52 |
| gnarface | haven't seen anything specific that does what you're asking, but with over 60,000 programs in the repo there's no reason to expect i would have seen it either | 09:52 |
| onefang | I did try a synaptic search, and tried the apps that turned up. | 09:53 |
| onefang | Guess I'll write a script after dinner. Soon the "time to eat the cooked food" timer will go off. | 09:54 |
| onefang | A simple - sleep 15 m; aplay /path/to/some/sound; something that will tell dunst to pop up a notification, but I haven't figured this bit out yet, or echo "time to do A" # repeat similar lines as needed. | 10:24 |
| onefang | Ah dunstify is the command, but there's no man page nor mention of it. Not even mentioned in the other dunst man pages. | 10:28 |
| onefang | sleep 15 m; aplay /path/to/some/sound; dunstify -a "onefang's timer" -u 2 "time to do A" | 10:30 |
| onefang | The -u 2 bit is to set a higher urgency, makes it turn up in red here. | 10:31 |
| onefang | sleep 15m; aplay /path/to/some/sound; dunstify -a "onefang's timer" -u 2 "time to do A" | 10:39 |
| onefang | Or swap the aplay and the dunstify if you have a longish sound. | 10:42 |
| rrq | onefang: how about using "at" with an "at" command? | 11:00 |
| onefang | But then it's not simple one liner like I can do with sleep. | 11:02 |
| onefang | Or rather multiple one liners, one for each step. | 11:04 |
| onefang | Ah, and I didn't have at installed. lol | 11:06 |
| onefang | Yeah, now I read the man page for at, it would be more complex, coz I can't simply say "run the next one when you are done with this one", I have to do math and stuff. | 11:09 |
| rrq | echo "echo betty ; echo boop |at now + 1 minutes" | at now + 1 minutes | 11:09 |
| rrq | (guess "echo" is not a good choice though; needs tty) | 11:10 |
| onefang | sleep 1m ; do something; sleep 2m; do something else # much simpler. Even simpler if it's two lines. | 11:11 |
| rrq | true | 11:11 |
| onefang | Plus script written already without having to install at. lol | 11:12 |
| Hanicef | im currently running into issues updating devuan testing: apt suddenly wants to install libsystemd0 which will fuck up my install (libpam-elogind will be removed) | 12:48 |
| Hanicef | is anyone else on testing experiencing this or is my install broken? | 12:51 |
| Hanicef | found the conflict: libpulse0:i386 : Depends: libsystemd0:i386 but it is not going to be installed | 12:57 |
| Hanicef | yup, looks like uninstalling the 32-bit variant of libpulse0 did the trick, updating works as intended now | 13:01 |
| golinux | systemdlete: Reality bites doesn't it! While we were rejoicing in the possibilities, forces of darkness were seeding mechanisms of control and oppression. | 17:09 |
| aitor | hi | 23:47 |
| golinux | Greetings aitor ! | 23:47 |
| aitor | hi, golinux! how is it going? | 23:48 |
| aitor | i've been missing for a while | 23:48 |
| aitor | a new release of simple-netaid is available in packages.gnuinos.org | 23:49 |
| golinux | Nice. | 23:49 |
| golinux | Some new here too: https://git.devuan.org/devuan/documentation/src/branch/master/art/graphics/05-daedalus-sapphire | 23:49 |
| golinux | It mostly together. Very little left to do. | 23:51 |
| aitor | it looks very nice, thanks for the job | 23:51 |
| golinux | Thanks. I did have some help with it and much of it was reused from Chimaera (icons and other images) so saved many hours of work | 23:54 |
| aitor | new versions of gtk don't always make it easy to maintain | 23:57 |
| fsmithred | we're luck that most of the themes we've made will work in multiple releases of devuan | 23:59 |
| fsmithred | lucky | 23:59 |
| aitor | hi fsmithred | 23:59 |
| fsmithred | hi | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!