| cousin_luigi | Ok, I think I understand my ifdown errors: bridge-utils destroys vlans on which the parent interface depends and when it's the latter's turn, it's already down, hence the "interface so and so doesn't exist". | 09:15 |
|---|---|---|
| gnarface | you doing this just with scripts and a interfaces file, no network-manager or anything like that? if so, sometimes it helps to put the device names into the interfaces file without any configuration | 09:17 |
| gnarface | then they'll already "exist" when a script goes to change their config, up or down them, etc | 09:18 |
| cousin_luigi | gnarface: I'm using ifupdown. | 11:10 |
| cousin_luigi | I'm not sure I follow. What else is going to configure them? | 11:11 |
| rrq | networking configures interfaces in the lexical order of the auto declarations, and it deconfigures them in reverse order | 12:18 |
| rrq | I think a bridge with vlans would be best declared together in the one auto statement, just keep tabs on that order | 12:19 |
| n4dir | first in last out, huh? | 12:19 |
| rrq | hmm "man ifdown" says I'm wrong; with "-a" the interfaces are brought down in the order they are listed in that /run/network/ifstate file | 12:31 |
| rrq | and "man interfaces" says you can have "no-auto-down" statements for avoiding interfaces in the "-a" deconfiguration | 12:33 |
| gnarface | cousin_luigi: well, anything you like. i was assuming custom shell scripts. | 12:50 |
| gnarface | maybe i didn't understand the actual problem well enough before i answered | 12:50 |
| cousin_luigi | rrq: That's what I did and my log shows as much, but /lib/bridge-utils/ifupdown.sh throws a spanner in the gears. | 13:41 |
| cousin_luigi | Also, ppp0, to mention one, depends on wan0, which in turn is the parent bridge to enp2s3.835. Perhaps I should declare all three of them in the same interfaces.d file? | 13:43 |
| cousin_luigi | But no, I don't think so. It's destroy_vlan_port(), I fear. | 13:44 |
| cousin_luigi | Maybe I should not declare ppp0 as inet ppp and invoke pon/poff by hand | 13:45 |
| rrq | maybe using "no-auto-down br.1 br.2", i.e. for the bridge vlan (whatever they are called)? then they wouldn;t be stopped by ifdown -a | 13:46 |
| systemdlete | I see that /etc/rc.local has provision for a directory called /etc/boot.d -- is that where the admin might place locally-written bootup scripts? | 14:23 |
| systemdlete | It would seem so, but I'd like to know for sure. | 14:23 |
| systemdlete | I don't see any doc on it. | 14:25 |
| rustyaxe | systemdlete: see 'man run-parts' | 15:26 |
| Afdal | Can someone tell me an easy way to make a .deb package when compiling things with scons | 15:40 |
| Afdal | I wish checkinstall worked easily with scons >:( | 15:41 |
| sixwheeledbeast | https://wiki.debian.org/UpstreamGuide#SCons | 15:48 |
| Afdal | lol | 15:49 |
| Afdal | I'd sure like to not use scons if I could help it :) | 15:49 |
| systemdlete | rustyaxe, my question is not so much about how to use the feature; I just want to know if it is appropriate to use this way | 15:50 |
| rustyaxe | Thats the whole point of run-parts, yes. I referenced the manual page so you can understand how that mechanism works (order they're run etc) | 15:50 |
| systemdlete | rustyaxe, what I am asking is not HOW to use it. I already understand run-parts; it is used in many places around the system, like cron, e.g. | 15:51 |
| systemdlete | I just want to know if this is the place where the admin would put locally-written boot scripts. | 15:51 |
| systemdlete | i.e., under the argument directory | 15:52 |
| systemdlete | that specific directory | 15:52 |
| systemdlete | I think it is, but I don't want to do something that it was not intended for | 15:52 |
| rustyaxe | systemdlete: Yes, if you look at what the rc.local is doing, if /etc/boot.d exists, it uses run-parts to run the scripts there | 15:52 |
| rustyaxe | Thats exactly what its made for | 15:52 |
| systemdlete | ok, that's what I wanted to know | 15:52 |
| rustyaxe | so long as you name them as run-parts wants them to be named, they'll run in a predictable order (based on the name) | 15:53 |
| systemdlete | in some cases, it looks like a feature or mechanism might be good for doing something or another, but then later, I find out it was not intended for that particular purpose | 15:53 |
| systemdlete | rustyaxe, yes, I am aware of ordering | 15:53 |
| systemdlete | generally, rc.local is where locally-written procedures go. | 15:54 |
| systemdlete | but I had never seen the run-parts portion of rc.local before. So I thought, maybe this is a place where debian plans to place its own scripts for whatever purposes, as opposed to the admin of an installation. | 15:55 |
| systemdlete | s/seen/noticed/ | 15:55 |
| rustyaxe | nope, system wide startup scripts belong in init.d - as they'll generally conform to having start/stop/etc arguments | 15:55 |
| systemdlete | well, I think I feel comfortable proceding, thanks | 15:56 |
| rustyaxe | lemme pop into my debian box and see if it has that too, got me curious now | 15:56 |
| rustyaxe | hmm that seems to have gone away. I could have sworn they have some systemdos setup to still run rc.local last i bothered with that machine ;) | 15:59 |
| cousin_luigi | rrq: Interesting. I will try that. But I fear the problem originates from /lib/bridge-utils/ifupdown.sh, which is not affected by ifdown keywords. | 16:58 |
| rwp | systemdlete, The /etc/boot.d/* directory is a recent addition. AFAIK undocumented. But it is there. I use it now to avoid needing to merge /etc/rc.local on upgrades. | 18:17 |
| rwp | That's the entire point of a .d/* directory of files is that then local files can go into the directory and avoid ever needing to merge with upstream on upgrades. | 18:18 |
| rwp | It also makes local management with infrastructure configuration processes like puppet, chef, salt, ansible, easier too because it removes any need to edit files. | 18:18 |
| blockhead | I purged wine from my Daedelus system and then performed a fresh install of Wine. I can only run the wordpad program that comes with Wine if I specify the full absolute path. Since I did not have to do that in the past, I'm going to assume it's an error? Has anyone else had this? | 22:11 |
| n4dir | Are the config files for wine in the users home? If so purging wine and reinstalling will only solve a certain kind of problems | 22:13 |
| n4dir | did you try it with a different user? | 22:13 |
| blockhead | if by config files you mean any of hte many files in the tree off of ~/.wine, then no I did not delete them. I have not tried it with a different user. | 22:14 |
| blockhead | let me get on that | 22:14 |
| n4dir | if it works for the other user, then you can be sure it is something in the users configs. I'd say | 22:15 |
| n4dir | to find which setting it is might be a bit of a pain. | 22:15 |
| blockhead | same, yet worse. if i specify the full path, it stops complianing about programs not found and instead complains about finding the display | 22:24 |
| n4dir | It was worth a try. A pity it didn't help. Good luck | 22:25 |
| rwp | Isn't finding a program entirely a PATH issue? Is that wine program directory in PATH? | 22:25 |
| blockhead | the emulated windows path or the real OS's path? | 22:27 |
| rwp | echo $PATH and if the directory is not there then add it there. You said you needed the full path and did not before. Makes me think it is now installed in a different directory. | 22:28 |
| rwp | Remember that we only know what you say. You said it does not work. That's all we know. If you want us to know more then you need to say more. | 22:29 |
| rwp | The problem is that there is an infinite number of ways for things to not work. Infinite. But only one way for things to work. | 22:29 |
| n4dir | don't they say there is more than one way you can skin a cat? | 22:30 |
| rwp | We deduce problems by subtracting the one way things must be to work from the infinite number of ways for things not to work. And are left with an infinite number of ways for things to not work. | 22:30 |
| DPA2 | If you try running something as a different user, like root, your $PATH may also be different, and it'd explain why the $DISPLAY is not found too. | 22:31 |
| blockhead | can one user run things on another user's window manager? | 22:32 |
| blockhead | that's a stupid question, isn't it | 22:32 |
| blockhead | daamnit, i'm gonna have to log out to really test that new user | 22:32 |
| DPA2 | You can, on X, if you set X, and make sure it gets the magic cookie from Xauth. | 22:34 |
| n4dir | pretty sure there are several ways to do it without logout, but logout then back as the other user seems like the most fast | 22:34 |
| rwp | Normally another user cannot display to a different user's display. The X Magic Cookie for one layer of protection. The X unix socket for another. | 22:34 |
| DPA2 | s/set X/set $DISPLAY/ | 22:34 |
| DPA2 | Just a matter of setting the permissions. | 22:34 |
| n4dir | couldn't you even do it with display-managers? I seem to recall someone said that is one reason why you'd want a display-manager | 22:34 |
| rwp | Let me put my vote in that I think chasing to see if this runs as a different user is a red herring. | 22:35 |
| rwp | You can log into an xdm as a different user. But then you would almost certainly need to install wine again into that other user $HOME directory. | 22:35 |
| rwp | And the problem statement started by saying that using the full path to the program worked okay. | 22:36 |
| blockhead | wordpad only runs for this one user. that's insane | 22:37 |
| rwp | If that user is you then it is all good, right? | 22:39 |
| blockhead | i guess, and I can make a wrapper script to specify the full path | 22:40 |
| rwp | If you think you have a file ownership/permission problem look for files not owned by you in your directory. find ~ ! -user $USER -ls | 22:40 |
| rwp | Wine often seems to have weird problems. But it's Windows so I repeat myself. | 22:43 |
| rwp | I still don't think we have a full described problem. | 22:43 |
| sixwheeledbeast | I actually prefer to run all wine stuff from a wrapper, disable the menu builder and not have them pollute my Apps list. | 23:23 |
| blockhead | walking away for a bit, thinking about it. Path problem in devuan wine. In any other distro, including times I've had to compile Wine myself, I've ever run Wine has never had this problem. I'm retracting my question and calling it "Devuan's Wine Is Broken" | 23:29 |
| rrq | what's "this problem"? does it have a "/usr" in it? | 23:50 |
| DPA2 | I suspect he did something like "su anotheruser" or something like that and that messed up the env of his shell. | 23:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!