IRC Logs for #crux-devel Monday, 2016-09-12

*** _________mavric6 has joined #crux-devel02:52
*** Workster has quit IRC05:17
*** Workster has joined #crux-devel05:17
*** Workster has quit IRC07:37
*** onodera has joined #crux-devel08:32
*** onodera has quit IRC09:30
*** onodera has joined #crux-devel10:03
*** onodera has quit IRC11:28
*** onodera has joined #crux-devel13:10
frinnstteK_: is it your stupid umask that fucks up the linux-firmware permissions?15:27
frinnsti still need root to access radeon firmwares15:27
teK_it's a sane umask, btw15:29
teK_I can include a fix for the permissions. How do you need to access those files as a user?15:30
teK_(curiously)15:30
frinnstI embed radeon firmware in my kernel16:39
frinnsti prefer to build the kernel as not-root16:39
frinnstso I just need +r16:39
frinnstI obvilously fix that but everytime i rebuild * it fucks it back up again16:40
frinnstwow I sound agressive when i read that back18:26
frinnst(not indented obviously)18:26
rmullI have a suggestion regarding the default /etc/rc.d/net rc script - I think it would be wise to change the dhcpcd -x invocation to include the ${DEV} argument18:44
rmullAs it is right now, if someone copies the rc script to use on multiple DHCP interfaces, if they stop one interface, it'll kill dhcpcd for all interfaces unless ${DEV} is also specified18:45
rmullMight also be worthwhile checking the other commands to make sure they make sense in a multi-interface scenario18:46
jaegerit used to include the device, the dhcpcd dev suggested not doing that, heh18:56
rmullOh, that is interesting, any idea why?18:57
jaegerI don't remember exactly, it'18:57
jaegers been a while18:57
rmullIs there a suggested alternative approach?18:57
jaegerIs there a situation where it's desireable to use dhcpcd on multiple interfaces?18:58
jaegerAnd in that situation can one instance of dhcpcd handle both or does it pick one?19:00
jaegerIn the couple instances where I've needed both I had to set up some iproute tables and stuff anyway to get proper routing on both interfaces, so I used a custom script19:03
jaegerand they were static addresses...19:11
teK_frinnst: I lost sensors for your hostility *g*19:32
rmulljaeger: In my case, I have a laptop with wifi and ethernet. The ethernet is connected to a test network (with DHCP services) and the wifi is connected to the office network19:36
rmullIf I don't specify an interface when using dhcpcd, it appears to operate on all interfaces19:37
jaegerso you don't want both concurrently, rather the ability to choose between them?19:37
rmullI do want both concurrently19:37
rmullOr wait, how do you mean?19:38
rmullI want to maintain independent DHCP state on both interfaces concurrently - I don't want to release on one interface and also release on the other one19:38
jaegerYou say it operates on all interfaces. Does that mean it gets addresses for both?19:38
rmullYes, if both ifaces are active, then it'll get addresses for both19:38
jaegerIs some bug causing it to release them or do you mean you need to stop one interface sometimes?19:38
rmullI need to work with the interfaces independently19:39
rmullThere is no bug19:39
jaegerok19:39
jaegerI'd suggest just using two scripts and adding ${DEV} to them, then, I think19:39
rmullI do - I have two rc scripts19:39
rmullAnd I use the ${DEV}, which I was suggesting should be added to the default script - but if it's not recommended by the dev, that's fine19:40
jaegerOK, I see19:41
jaegerI think his reasoning was that leaving the dev out would result in covering more possible cases or interfaces, if that makes sense19:41
jaegerwhereas specifying it locks dhcpcd to that interface even if you have others19:42
jaegerBut it's been long enough that I don't recall19:42
jaegerBoth work fine from a functional standpoint but I assume the reasoning is that it covers more generic use cases that way19:42
rmullBut the init script itself is locked to an interface, since you have to specify $DEV to begin with19:42
jaegerYou don't have to specify it at all if you use DHCP19:43
jaegeronly when you use the custom bits19:43
rmullRight, but the init script also brings the specified interface up and down19:43
jaegeragain, only if you use the custom bits19:43
rmullOh, I see what you mean19:44
rmullright19:44
jaegerIt should work out of the box for a single NIC DHCP user19:44
jaegerwhich seemed at the time like the most common19:44
rmullThat makes sense19:44
jaegerWith that said, I don't recall anyone really complaining about it back when we did specify the device19:44
rmullI think I may be in the minority with my usecase19:47
rmullNo change requested19:47
jaegerI think probably so but I don't really have a strong feeling about it19:57
teK_frinnst: umask in the Pkgfile for linux-firmware says 0022. Makefile uses cp to copy things20:02
frinnstmy checkout: drwxr-xr-x20:16
frinnstyour tarball: drwx------20:17
frinnstyou have .git in the tarball - 62mb of crap20:17
teK_funny20:17
teK_in terms of permissions you only talk about the source tarball?20:18
frinnstyes20:19
frinnstand that translates to what gets installed in /lib/firmware20:19
frinnstfredrik@nibbler:/tmp$ sudo tar xf /usr/ports/src/linux-firmware-20160514.tar.xz20:20
frinnstfredrik@nibbler:/tmp$ cd linux-firmware-20160514/radeon20:20
frinnst-bash: cd: linux-firmware-20160514/radeon: Permission denied20:20
frinnstand:20:22
frinnstfredrik@nibbler:/tmp$ sudo git clone --depth=1 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git20:22
frinnst<snip>20:22
frinnstfredrik@nibbler:/tmp$ cd linux-firmware/radeon/20:22
frinnstfredrik@nibbler:/tmp/linux-firmware/radeon [master]$20:22
teK_will fix this :]20:24
frinnst<320:25
frinnstfredrik@nibbler:~/linux-4.8-rc6$ make20:25
frinnstmake[1]: stat: /lib/firmware/radeon/JUNIPER_me.bin: Permission denied20:25
frinnst=======> ERROR: Md5sum mismatch found:20:43
frinnst(linux-firmware)20:44
teK_you gotta be kidding me20:44
teK_I checked. whatev..20:44
frinnst:D20:45
teK_delete the source file20:46
teK_OBVIOUSLY20:46
frinnstaaah you didnt change the filename asdf20:46
teK_there will be a new release soon :>20:47
teK_COME ON. of COURSE a zombie is in the water intake when the boat engines stop working20:47
frinnstKernel: arch/x86/boot/bzImage is ready  (#2)20:48
frinnst\o/20:48
frinnsthaha fear the walking dead?20:48
teK_yea20:49
teK_by the way.20:49
teK_Did you read about the USB network device hijacking WIndows thingy?20:50
frinnsthm depends, new exploit?20:50
teK_yes20:50
teK_the stuff discovered by mubix20:51
teK_he uses a customised USB dongle to trick Windows into believing a new nic was attached, but the dongle would also sniff stuff like hashes20:51
teK_works even for locked computers20:51
frinnstah yeah20:51
frinnstread about that20:51
teK_user convenience IS dangerous20:51
frinnstworks for mac too i read20:51
teK_Apple users deserve to be punished so I dont care :P20:52
teK_speaking of which. Did you read about the hidden audio jack in iphone 7?20:52
frinnstno20:53
teK_I have pictures / proof20:53
teK_http://img.pr0gramm.com/2016/09/12/387931c4112dcf82.jpg20:53
frinnstlol20:54
frinnstdidnt someone convince people that they should put their iphone in the microwave or something a few years back?20:55
frinnsthttp://www.dailymail.co.uk/news/article-2768976/Emergency-services-forced-step-iPhone-users-fall-internet-prank-explains-use-microwave-charge-phone.html20:56
frinnstbrilliant20:56
teK_yes20:56
teK_both from 4chan, iirc20:57
teK_=)20:57
frinnstfood -> zzz20:58
teK_good night20:58
*** groovy3shoes has joined #crux-devel21:51
*** onodera has quit IRC23:36
*** Workster has joined #crux-devel23:48

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!