Re: [DNG] vdev - scanner
fsmithred wrote on 01/09/16 06:17: ... OS_TYPE=255/255/255 ... My worry is that the OS_TYPE=255/255/255 condition is not distinct enough to make the action apply exactly and only for scanners. Comparing with udev rules, you'll find there are more than a few rules for USB devices, and almost all of them make their classification based on the vendor/product pair (rather than the capability declarations). Translated to vdev, it would mean to use match criteria of the form OS_PRODUCT=$V/$P/$N with $V=vendor, $P=product, $N=version. The value match processing is literal, and you'd thus need a separate action for every $V/$P/$N. (Like udev) Alternatively, one could have the one action (without OS_PRODUCT), and a new, clever helper to assign access group via a database of $V/$P/$N->group mappings. Perhaps people previously involved in vdev development would have a view on this? The helper itself is trivial, but it'll depend on the database, and the major work would be in preparing that database (or finding and adapting an already existing one). Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] building for armhf
On 2016-08-31 09:21, Jaromil wrote: for package building we are still using the "legacy" arm-sdk scripts, the SDK is still work in progress that should merge all the efforts going in the same direction by parazyd, katolaz and me to re-build packages you need to setup jenkins with the devuan-jenkins-glue and qemu using with pinthread. you may also want to freeze your own build toolchain. this is all not documented yet. That is old greek to me unfortunately. pinthread I guess is this one https://github.com/nexlab/pinthread and the USAGE seems pretty OK for me to follow. devuan-jenkins-glue https://git.devuan.org/devuan-infrastructure/jenkins-debian-glue and I could check http://jenkins-debian-glue.org/ to get a notion what its doing jenkins Jenkins Continuous Integration system. I could read here http://www.vogella.com/tutorials/Jenkins/article.html I could use some more pointers are there some scripts I could spy on? I mean how it all fits together? I guess this is not prioritized but do you think it will be documented any time in the future? /scooby ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev - scanner
On 08/31/2016 11:08 AM, info at smallinnovations.nl wrote: > On 31-08-16 16:38, fsmithred wrote: >> On 08/31/2016 07:17 AM, fsmithred wrote: >>> On 08/31/2016 05:03 AM, Ralph Ronnquist wrote: >> Our discussion in irc was productive. The following works with the stock >> permissions.sh (without the lines for setfacl). The acl does not get set, >> but the scanner works. And if I unplug and re-plug the usb cable, the >> scanner gets the next device number, and it works! >> >> cat /etc/vdev/actions/scanner.act >> >> [vdev-action] >> event=add >> path=^bus/usb/*/[001-999] >> OS_SUBSYSTEM=usb >> OS_TYPE=255/255/255 >> VAR_PERMISSIONS_OWNER=root >> VAR_PERMISSIONS_GROUP=scanner >> VAR_PERMISSIONS_MODE=0664 >> helper=permissions.sh >> if_exists=run >> daemonlet=true >> >> -fsr >> > And if you give the device free with a event=remove action file? Does it > then keep it's old device number with reconnecting? > > Grtz > > Nick I don't know. Not sure what would go in that file, either. I can test that later. I did just try it in the system I'm using now, which is running udev, and it gets a new number. I see that the number is now up to 36, so that must increment every time I add/remove a usb thumb drive, scanner, and maybe any other usb device. On this machine, the scanner is on 005/036, and there's nothing between that and 005/001. I believe that I've plugged and removed a thumb drive around 30 times since my last reboot. Edit: or maybe by some other logic. I just plugged in a flash drive, and it's on 002/048 -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev - scanner
On 31-08-16 16:38, fsmithred wrote: On 08/31/2016 07:17 AM, fsmithred wrote: On 08/31/2016 05:03 AM, Ralph Ronnquist wrote: Our discussion in irc was productive. The following works with the stock permissions.sh (without the lines for setfacl). The acl does not get set, but the scanner works. And if I unplug and re-plug the usb cable, the scanner gets the next device number, and it works! cat /etc/vdev/actions/scanner.act [vdev-action] event=add path=^bus/usb/*/[001-999] OS_SUBSYSTEM=usb OS_TYPE=255/255/255 VAR_PERMISSIONS_OWNER=root VAR_PERMISSIONS_GROUP=scanner VAR_PERMISSIONS_MODE=0664 helper=permissions.sh if_exists=run daemonlet=true -fsr And if you give the device free with a event=remove action file? Does it then keep it's old device number with reconnecting? Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev - scanner
On 08/31/2016 07:17 AM, fsmithred wrote: > On 08/31/2016 05:03 AM, Ralph Ronnquist wrote: >> Ralph Ronnquist wrote on 31/08/16 15:54: >>> Ralph Ronnquist wrote on 31/08/16 10:21: fsmithred wrote on 31/08/16 07:54: > ... > I got it to work. Here's the action file and the helper script. The > helper > script is a modified permissions.sh. I added a test for $VDEV_MAJOR and > $VDEV_MINOR to trigger setfacl. Scanner now works on my installation. > ... Great. I'll roll it into the package. >>> >>> On looking at this, I saw the action file was rather different from >>> other action files, and (as I'm slowly picking on this up) I'd like to >>> check with you whether the following action file might do the work: >>> >>> /etc/vdev/actions/scanner.act >>> [vdev-action] >>> event=add >>> path=^bus/usb/*/[001-999] >>> OS_SUBSYSTEM=usb >>> VAR_PERMISSIONS_OWNER=root >>> VAR_PERMISSIONS_GROUP=scanner >>> VAR_PERMISSIONS_MODE=0664 >>> helper=permissions.sh >>> daemonlet=true >>> >>> Afaict, the acls should follow the file permissions and you shouldn't >>> need to set those. >>> >>> Ralph. >> >> oops, I seem to have lost the "OS_TYPE=255/255/255" line. Probably important. >> >> Ralph. > > > That didn't work, even with the OS_TYPE=255/255/255. The file permissions > get set, but not the acl. I played with some variations, and the following > works, but only if I add the lines for setfacl to permissions.sh. (i.e. > test for major and minor number then run setfacl) > > /etc/vdev/actions/scanner.act > [vdev-action] > event=add > path=^bus/usb/*/[001-999] > OS_SUBSYSTEM=usb > OS_TYPE=255/255/255 > VAR_PERMISSIONS_OWNER=root > VAR_PERMISSIONS_GROUP=scanner > VAR_PERMISSIONS_MODE=0664 > helper=permissions.sh > if_exists=run > > > One other problem with all the ways I've tried is that if I unplug the > scanner and plug it in again, the acl does not get set. A reboot is > required for that. > > -fsr > > Our discussion in irc was productive. The following works with the stock permissions.sh (without the lines for setfacl). The acl does not get set, but the scanner works. And if I unplug and re-plug the usb cable, the scanner gets the next device number, and it works! cat /etc/vdev/actions/scanner.act [vdev-action] event=add path=^bus/usb/*/[001-999] OS_SUBSYSTEM=usb OS_TYPE=255/255/255 VAR_PERMISSIONS_OWNER=root VAR_PERMISSIONS_GROUP=scanner VAR_PERMISSIONS_MODE=0664 helper=permissions.sh if_exists=run daemonlet=true -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] F1 and special usernames on the login screen
Steve Litt writes: I hadn't thought much about several people using the same computer for different GUI tasks in the last 12 years. It happens. There are some family-shared tablets with >1 account. Rumour has it it's rare, although I've never spoken to anyone with numbers and without an NDA. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev - scanner
On 08/31/2016 05:03 AM, Ralph Ronnquist wrote: > Ralph Ronnquist wrote on 31/08/16 15:54: >> Ralph Ronnquist wrote on 31/08/16 10:21: >>> >>> >>> fsmithred wrote on 31/08/16 07:54: ... I got it to work. Here's the action file and the helper script. The helper script is a modified permissions.sh. I added a test for $VDEV_MAJOR and $VDEV_MINOR to trigger setfacl. Scanner now works on my installation. ... >>> >>> Great. I'll roll it into the package. >> >> On looking at this, I saw the action file was rather different from >> other action files, and (as I'm slowly picking on this up) I'd like to >> check with you whether the following action file might do the work: >> >> /etc/vdev/actions/scanner.act >> [vdev-action] >> event=add >> path=^bus/usb/*/[001-999] >> OS_SUBSYSTEM=usb >> VAR_PERMISSIONS_OWNER=root >> VAR_PERMISSIONS_GROUP=scanner >> VAR_PERMISSIONS_MODE=0664 >> helper=permissions.sh >> daemonlet=true >> >> Afaict, the acls should follow the file permissions and you shouldn't >> need to set those. >> >> Ralph. > > oops, I seem to have lost the "OS_TYPE=255/255/255" line. Probably important. > > Ralph. That didn't work, even with the OS_TYPE=255/255/255. The file permissions get set, but not the acl. I played with some variations, and the following works, but only if I add the lines for setfacl to permissions.sh. (i.e. test for major and minor number then run setfacl) /etc/vdev/actions/scanner.act [vdev-action] event=add path=^bus/usb/*/[001-999] OS_SUBSYSTEM=usb OS_TYPE=255/255/255 VAR_PERMISSIONS_OWNER=root VAR_PERMISSIONS_GROUP=scanner VAR_PERMISSIONS_MODE=0664 helper=permissions.sh if_exists=run One other problem with all the ways I've tried is that if I unplug the scanner and plug it in again, the acl does not get set. A reboot is required for that. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev - scanner
Ralph Ronnquist wrote on 31/08/16 15:54: Ralph Ronnquist wrote on 31/08/16 10:21: fsmithred wrote on 31/08/16 07:54: ... I got it to work. Here's the action file and the helper script. The helper script is a modified permissions.sh. I added a test for $VDEV_MAJOR and $VDEV_MINOR to trigger setfacl. Scanner now works on my installation. ... Great. I'll roll it into the package. On looking at this, I saw the action file was rather different from other action files, and (as I'm slowly picking on this up) I'd like to check with you whether the following action file might do the work: /etc/vdev/actions/scanner.act [vdev-action] event=add path=^bus/usb/*/[001-999] OS_SUBSYSTEM=usb VAR_PERMISSIONS_OWNER=root VAR_PERMISSIONS_GROUP=scanner VAR_PERMISSIONS_MODE=0664 helper=permissions.sh daemonlet=true Afaict, the acls should follow the file permissions and you shouldn't need to set those. Ralph. oops, I seem to have lost the "OS_TYPE=255/255/255" line. Probably important. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] building for armhf
dear shraptor, On Tue, 30 Aug 2016, shraptor wrote: > I want to build packages for a rpi3 > > I wonder if there is something to re-use from > > https://git.devuan.org/devuan/arm-sdk > > It is used in auto-build of devuan iso for rpi. arm-sdk has nothing to do with package build, it deals with iso packaging, kernel building and firmware inclusion > In the instruction for arm-sdk If I follow the recipe down to > > ; init devuan raspi2 > > Am I close to having an environment for buildin packages for armhf? > > Maybe there is some script there I could spy on for info? for package building we are still using the "legacy" arm-sdk scripts, the SDK is still work in progress that should merge all the efforts going in the same direction by parazyd, katolaz and me to re-build packages you need to setup jenkins with the devuan-jenkins-glue and qemu using with pinthread. you may also want to freeze your own build toolchain. this is all not documented yet. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
