| 00:02.22 | ejr | if anyone else has any suggestions on how to fix this, let me know. |
| 00:10.37 | *** part/#devuan msiism (~msiism@200116b845b1d500ee086bfffe1ced28.dip.versatel-1u1.de) |
| 00:20.09 | *** join/#devuan infobot (ibot@rikers.org) |
| 00:20.09 | *** topic/#devuan is Recent (2017-05-25): Jessie 1.0.0 stable release http://ur1.ca/qxaa5 || This is the Devuan https://devuan.org/ discussion channel (logged at https://botbot.me/freenode/devuan - with useful 'search') | Please take off-topic conversation to #debianfork | /msg chanserv info #devuan | !listkeys #devuan <foo> | Devuan Forum: https://dev1galaxy.org/ |
| 00:20.09 | *** mode/#devuan [+v infobot] by ChanServ |
| 00:40.21 | *** join/#devuan bpmedley (~bpm@c-24-72-144-115.ni.gigamonster.net) |
| 00:59.12 | *** join/#devuan theLambda (~theLambda@mue-88-130-62-173.dsl.tropolys.de) |
| 01:02.33 | *** join/#devuan blinkdog (~blinkdog@devuan/developer/blinkdog) |
| 01:07.36 | *** join/#devuan menip (~menip@c-73-83-2-241.hsd1.wa.comcast.net) |
| 01:14.23 | *** join/#devuan Humpelst1lzchen (erik@p4FD03460.dip0.t-ipconnect.de) |
| 01:17.56 | *** join/#devuan Irrwahn_pi (~Irrwahn@p549A62E4.dip0.t-ipconnect.de) |
| 01:27.19 | *** join/#devuan HumanGeek (~HumanG33k@62.147.242.8) |
| 01:31.21 | *** part/#devuan ibanja (~ibanja@207.244.67.20) |
| 01:57.42 | *** join/#devuan Hoshpak (~Hoshpak@200116b8006c0f00004109fffe40d1e1.dip.versatel-1u1.de) |
| 02:17.25 | *** part/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
| 02:39.21 | *** join/#devuan mlsmith (~mlsmith@unaffiliated/configx) |
| 02:44.56 | *** join/#devuan mlsmith (~mlsmith@unaffiliated/configx) |
| 03:02.55 | *** join/#devuan ToffeeYogurtPots (~ToffeeYog@gateway/tor-sasl/toffeeyogurtpots) |
| 03:26.17 | *** join/#devuan mcr (~mcr@CPE788df7e17ec1-CM788df7e17ec0.cpe.net.cable.rogers.com) |
| 03:49.19 | *** join/#devuan NEOalquimista (~NEOalquim@51.148.205.168.dynamic.raidnet.com.br) |
| 03:54.52 | *** join/#devuan infobot (ibot@rikers.org) |
| 03:54.52 | *** topic/#devuan is Recent (2017-05-25): Jessie 1.0.0 stable release http://ur1.ca/qxaa5 || This is the Devuan https://devuan.org/ discussion channel (logged at https://botbot.me/freenode/devuan - with useful 'search') | Please take off-topic conversation to #debianfork | /msg chanserv info #devuan | !listkeys #devuan <foo> | Devuan Forum: https://dev1galaxy.org/ |
| 03:54.56 | *** mode/#devuan [+v infobot] by ChanServ |
| 04:45.38 | mansaxel_ | Morning, |
| 04:47.53 | mansaxel_ | Debian now has quoted ls output. Will this atrocity seep into Devuan? |
| 04:49.28 | rrq | ?? "quoted ls output" ?? |
| 04:51.01 | mansaxel_ | rrq: yes. another instance of breaking 48 year old defaults because some dev thinks he knows better. |
| 04:51.22 | rrq | you mean that the file names have quotes around them? |
| 04:51.28 | mansaxel_ | rrq: yes. |
| 04:52.20 | furrywolf | ... I've never seen such a thing. |
| 04:52.31 | rrq | that's not anywhere near a sensible improvement |
| 04:52.45 | mansaxel_ | recent coreutils has this and the developer says "this was intentional and will not change back" when facing a torrent of protest. Stinks systemd style ignorance. |
| 04:53.24 | mansaxel_ | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813164 |
| 04:54.49 | furrywolf | were I debian dev, I'd submit that to the technical committee to have the maintainer overruled. |
| 04:55.06 | mansaxel_ | furrywolf: indeed. |
| 04:55.32 | mansaxel_ | I suggest that this _never_ goes into Devuan. |
| 04:57.20 | rrq | apparently there's a flag to turn it off ... should have been to turn it *on* of course. |
| 04:58.05 | mansaxel_ | rrq: yes. that's how you do things. |
| 04:58.27 | furrywolf | I remember waaaay back when, on some sunos servers with terminals, the fun of putting a few random filenames scattered about with terminal control codes in them, like setting the text to white on white and turning the cursor off. :P |
| 04:58.35 | rrq | and then it only happens for output to terminals ... should have been always if flagged . |
| 04:59.16 | rrq | :) |
| 05:00.30 | rrq | we had these basic paper terminals, which purnt hole in the paper when you did that :) |
| 05:00.46 | *** join/#devuan hgunth (~hgunth@gateway/tor-sasl/hgunth) |
| 05:00.48 | rrq | b |
| 05:04.34 | mansaxel_ | i actually learnt ed(1) in order to fix the terminal definition on sun machines with serial console. It was "sun" or something, that did not work very well with an xterm through reverse TELNET via a terminal server... |
| 05:05.13 | furrywolf | bbl, wolfy bedtime |
| 05:05.35 | mansaxel_ | the mismatch was bad enough that running any fullscreen editor to fix the console setup file was impossible, but ed managed. |
| 05:06.51 | furrywolf | ed can work on line printers. :) |
| 05:09.29 | furrywolf | bbl |
| 05:35.32 | *** join/#devuan mcr (~mcr@2607:f0b0:f:b:a11:96ff:fe01:81e0) |
| 05:39.30 | KatolaZ | mansaxel_: I had the impression quoting in coreutils had been eventually dropped, right? |
| 05:44.37 | *** join/#devuan reetp (~john@239.red-80-59-216.staticip.rima-tde.net) |
| 05:47.23 | Jjp137 | KatolaZ, it was reenabled in 8.28-1 (changelog: http://metadata.ftp-master.debian.org/changelogs/main/c/coreutils/coreutils_8.28-1_changelog) |
| 05:48.29 | Jjp137 | at least for ls I guess? |
| 05:54.07 | muep | imo, it looks like a storm in a teacup. I do almost all my file management from a terminal window and would not have even noticed the change without seeing that discussion |
| 05:57.09 | *** join/#devuan minnesotags (~herbgarci@c-24-118-22-254.hsd1.mn.comcast.net) |
| 05:57.20 | mansaxel_ | At any rate, this is the type of change that I think is symptomatic of the systemd (look, I can change stuff and what I think fits best for my application surely must fit others, right?) and as such more or less automatically should be excluded from Devuan. But that is just me. I will go back to NetBSD if I'm outvoted. ;-) |
| 05:58.52 | enyc | mansaxel_: oooh the fun... I remember dos edlin that I could use, too... =). |
| 06:02.02 | KatolaZ | I still don't understand why, tough |
| 06:02.05 | KatolaZ | ~though |
| 06:05.08 | KatolaZ | mansaxel_: wishing is cheap |
| 06:05.23 | KatolaZ | if you want that excluded, consider taking maintenance of a forker coreutils |
| 06:05.26 | KatolaZ | :) |
| 06:05.58 | KatolaZ | I think it's a bad thing as well, but the only way to avoid that to happen is to help out |
| 06:07.19 | mansaxel_ | KatolaZ: Yes, I understand. I am considering it. |
| 06:07.25 | KatolaZ | please do |
| 06:07.39 | KatolaZ | especially if you have experience of deb package maintenance |
| 06:11.50 | muep | here the debian maintainer did go out of his way to delay the change made upstream |
| 06:13.22 | KatolaZ | muep: so is the change coming from GNU? |
| 06:13.51 | muep | at least this bug report says so |
| 06:15.34 | muep | I'd expect to see that same behavior in ls in most distributions |
| 06:17.07 | muep | eventually basically anything except ones not using GNU coreutils, or where the maintainer is against the change enough to revert it |
| 06:18.40 | ejr | my eudev error problem uf yesterday still persists; what could be the reason for it? (see the msgs above for description) |
| 06:19.51 | KatolaZ | no wait |
| 06:19.58 | KatolaZ | -N has been in ls for ages |
| 06:20.19 | KatolaZ | but the default is that it's disabled |
| 06:20.58 | ejr | -N? |
| 06:21.21 | muep | adding the -N option disables the quoting |
| 06:21.21 | KatolaZ | ejr: was about ls |
| 06:21.24 | KatolaZ | sorry |
| 06:21.27 | ejr | oh kk |
| 06:22.05 | mansaxel_ | KatolaZ: Pádraig Brady who defends the change is one of the maintainers per the GNU coreutils page, so yes. From GNU |
| 06:22.22 | KatolaZ | mansaxel_: does not seem like that tbh |
| 06:22.44 | KatolaZ | there is no mention of literal quiting being enabled by default in GNU Coreutils logs |
| 06:23.26 | KatolaZ | we should look into the debian package to understand whether the change is in debian or upstream |
| 06:23.38 | KatolaZ | bbl |
| 06:23.39 | KatolaZ | o/ |
| 06:24.00 | KatolaZ | (it seems like it's an issue of the debian package, TBH) |
| 06:24.05 | muep | right now, at least the latest stable versions of fedora, opensuse, ubuntu do include a ls that quotes by default |
| 06:24.17 | KatolaZ | ok muep |
| 06:24.23 | KatolaZ | let's explore this further |
| 06:24.34 | KatolaZ | the fact that the debian changelog mentions it is suspucious |
| 06:25.00 | muep | if you read the bug report, it says that debian had a patch that reverted the upstream change |
| 06:25.02 | KatolaZ | if it's an upstream change, there is no reason to mention it in the package changelog |
| 06:25.10 | KatolaZ | ok will look into that |
| 06:25.18 | KatolaZ | (not now, though :D) |
| 06:25.20 | KatolaZ | bbl |
| 06:25.21 | KatolaZ | o/ |
| 06:53.38 | *** join/#devuan Stealth (stealth@sourcemage/archon/stealth) |
| 06:58.11 | mansaxel_ | Look here: https://lists.gnu.org/archive/html/coreutils/2018-02/threads.html#00049 |
| 06:58.50 | mansaxel_ | This is the coreutils devs arguing for it, with a lot of people asking them to revert. |
| 07:06.18 | KatolaZ | mansaxel_: it seems clear that the devs are a bunch of assholes then |
| 07:06.23 | muep | I don't think the "there are N people asking for a revert" is a very useful metric for a tool that is this popular |
| 07:06.33 | KatolaZ | The change has already been made. Even if we now revert it, users still have to deal with versions in the wild that have the change. So since users already have to deal with it, they might as well always have to deal with it. We prefer a default of erring on the side of safety when it comes to output that is ambiguous or could corrupt a terminal, but leave enough knobs that you can customize a different |
| 07:06.38 | KatolaZ | default for your preferred setup. |
| 07:06.41 | KatolaZ | .... |
| 07:06.44 | KatolaZ | this is the most lousy excuse ever |
| 07:06.48 | KatolaZ | you made a mistake |
| 07:06.51 | mansaxel_ | Typical systemd behaviour |
| 07:06.52 | KatolaZ | were asked to revert |
| 07:06.58 | muep | regardless of what default you pick, there are likely at least N people who are not happy with it |
| 07:07.08 | KatolaZ | and you reply with "oh no, there are already versions using that" |
| 07:07.10 | KatolaZ | :\ |
| 07:07.17 | KatolaZ | no muep |
| 07:07.28 | KatolaZ | the thing is that you are changing a default, not allowing something more |
| 07:07.39 | KatolaZ | the reasoning could be reversed |
| 07:07.52 | KatolaZ | people who need the quoting could just add a flag to ls |
| 07:08.07 | KatolaZ | that is the correct way of adding a feature that breaks stuff |
| 07:08.26 | KatolaZ | apart from the personal concern about the fact that ls can distinguish if it's outputting to a terminal or not |
| 07:08.28 | muep | when I look at it, I see it quite unlikely for this to break stuff |
| 07:08.34 | KatolaZ | that's just *silly* |
| 07:08.38 | KatolaZ | yes muep |
| 07:08.39 | KatolaZ | it will |
| 07:09.27 | KatolaZ | it will show unaligned outputs in all the existing installations, as soon as a file with spaces is present |
| 07:09.29 | muep | I'd expect that it can sometimes fail to detect that it is in a tty, but it seems quite unlikely for it to mistake a pipe to be a tty |
| 07:09.53 | KatolaZ | muep: I question why ls should care of what is on output |
| 07:10.02 | KatolaZ | a filter is a filter |
| 07:10.11 | KatolaZ | it filters input and spits output |
| 07:10.21 | KatolaZ | irrespective of what is going to chew on that output |
| 07:10.26 | KatolaZ | ... |
| 07:10.44 | muep | in order to unambiguously show files with spaces in their names |
| 07:10.55 | KatolaZ | that's not the point |
| 07:11.12 | KatolaZ | the point is that ls apparently behaves differently according to who is using its output |
| 07:11.15 | muep | it already did the same thing with colors, too |
| 07:11.21 | KatolaZ | and this is even more broken than the changed default |
| 07:11.27 | muep | and columns |
| 07:11.49 | muep | at least here, I get output like from ls -1 if the output is not a terminal |
| 07:11.53 | KatolaZ | you have to explicit enable colours though... |
| 07:11.58 | KatolaZ | or columns... |
| 07:12.05 | muep | not columns |
| 07:12.27 | muep | my ls alias is like this: alias ls='ls --color=auto' |
| 07:12.50 | muep | I automatically get columns on tty and no columns on pipe |
| 07:13.08 | muep | so it is not like ls used to be very principled about always producing the same output for same inputs |
| 07:13.34 | KatolaZ | that's broken as well then :) |
| 07:14.27 | mansaxel_ | muep: There will always be a translation from the bits in the directory entry to the presentation. That is not the subject of debate. The breaking of a 40+ years old behaaviour is the issue here. |
| 07:14.37 | mansaxel_ | -a |
| 07:15.21 | *** join/#devuan clemens3_ (~clemens@80-218-38-71.dclient.hispeed.ch) |
| 07:15.29 | muep | I though the traditional expectation of output for a plain ls call has basically been just "it gives me some kind of list of files" |
| 07:15.50 | mansaxel_ | Probably older than most users (I'm about 5 months younger than The Beginning, as described in http://www.unix.org/what_is_unix/history_timeline.html) |
| 07:15.53 | muep | especially I am quite sure that it has not stayed perfectly identical for 40+ years |
| 07:16.06 | mansaxel_ | quoting never was there. |
| 07:16.40 | mansaxel_ | ...until now. |
| 07:16.57 | muep | and now that it is, it gets shown to interactive users who pretty certainly are still able to understand the output |
| 07:18.06 | mansaxel_ | $ uname -rv ; mkdir test ; cd test ; touch "asshole GNU developer" ; ls |
| 07:18.06 | mansaxel_ | 10.3-RELEASE-p29 FreeBSD 10.3-RELEASE-p29 #0: Tue Apr 3 19:55:05 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC |
| 07:18.11 | mansaxel_ | asshole GNU developer |
| 07:18.45 | muep | I am not saying that there's absolutely no downside to the change, but there are benefits as well as the downside of changing the output a bit |
| 07:19.20 | mansaxel_ | That is the default and that is what users expect. |
| 07:19.49 | muep | and certainly I do not think it is appropriate to call people names when they just disagree on where that right balance is |
| 07:19.57 | mansaxel_ | And I agree, which is why I'm not hostile to adding it via a cmdline flag or environment variable. |
| 07:20.51 | mansaxel_ | The right balance is "you do not fuck with the defaults because people have STRONG habits" and that is pretty much what needs to be said in this. |
| 07:22.19 | muep | especially the people with the strong habits would typically know that output of ls can be tuned. unlike the newcomers who learn ls among their 10 first command-line tools |
| 07:23.06 | mansaxel_ | IBM System/Z is very profitable for IBM since it can run very old code. This is not a coincidence. |
| 07:23.20 | muep | also the newcomers will now know that running a more traditional ls variant on files with some garbage names can mess up the terminal in a very confusing way |
| 07:23.50 | muep | *will not know |
| 07:24.02 | mansaxel_ | and that, terminal mess-up, is a great way of teaching "everything is a file" ;-) |
| 07:29.09 | muep | I never thought that being able to use undisplayable file names was part of that principle |
| 08:20.43 | mansaxel_ | Hence the smiley. |
| 08:21.49 | *** join/#devuan kelsoo1 (~kelsoo@dragora/developer/kelsoo) |
| 08:25.50 | *** join/#devuan AntoFox (~Thunderbi@dynamic-adsl-78-12-56-5.clienti.tiscali.it) |
| 08:26.23 | KatolaZ | muep: I called "asshole" the developer in refererence to his comment about reverting the patch |
| 08:26.58 | KatolaZ | saying that you can't revert something because there is already a version that is used by other people is just plain silly |
| 08:27.24 | KatolaZ | one can say the same in reverse: there are far more installation where the new behaviour is not the default |
| 08:27.28 | KatolaZ | ... |
| 08:27.53 | KatolaZ | so actually reverting the patch would be the most sensible thing to do |
| 08:28.01 | KatolaZ | hence my "asshole" |
| 08:29.10 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 08:33.10 | *** join/#devuan Fervi (~fervi@2a02:a317:e144:d900:baac:6fff:fe99:7804) |
| 08:34.57 | *** join/#devuan Oldmoss (~Oldmoss@anon-35-108.vpn.ipredator.se) |
| 09:07.17 | *** join/#devuan Besnik_b (~Besnik@ppp-94-66-221-205.home.otenet.gr) |
| 09:09.43 | *** join/#devuan amarsh04 (~amarsh04@ppp118-210-175-207.bras2.adl6.internode.on.net) |
| 09:21.16 | *** join/#devuan ipe (~ipe@91-156-247-55.elisa-laajakaista.fi) |
| 09:23.20 | *** join/#devuan HumanGeek (~HumanG33k@62.147.242.8) |
| 09:32.50 | *** join/#devuan pillepalle (~Thunderbi@ip-94-114-5-11.unity-media.net) |
| 09:40.57 | *** join/#devuan Levure (~quassel@91.180.149.64) |
| 09:58.52 | *** join/#devuan eliasr (uid27497@gateway/web/irccloud.com/x-vwrsollgvjynxlmf) |
| 10:05.15 | *** join/#devuan muep (~quassel@muep.iki.fi) |
| 10:22.19 | *** join/#devuan pillepalle (~Thunderbi@ip-94-114-5-11.unity-media.net) |
| 10:24.48 | *** join/#devuan markong (~marco@46.166.137.67) |
| 10:47.13 | *** join/#devuan DarkUranium (~DarkUrani@77.38.34.248) |
| 11:03.09 | *** join/#devuan crimson_king (~NEOalquim@168.205.151.183) |
| 11:25.46 | *** join/#devuan sunshavi (~user@181.64.192.62) |
| 11:26.26 | *** join/#devuan Oldmoss (~Oldmoss@anon-34-195.vpn.ipredator.se) |
| 11:32.58 | *** join/#devuan Uberius (~Uberius@gateway/tor-sasl/uberius) |
| 11:34.52 | *** join/#devuan ar3itrary (~hacker@2a03:4000:6:8177:2::1) |
| 11:41.19 | DocScrutinizer51 | hi folks, do any of you happen to have a URL (or be able to pastebin) to a lisy of applications that use GDP/UPnP for discovering and pinholing NAT? |
| 11:41.54 | DocScrutinizer51 | sorry, no access to any PC right now |
| 11:43.14 | DocScrutinizer51 | I suppose there's a UPnP.so or somesuch, yo ask apt for dependencies? |
| 11:43.35 | DocScrutinizer51 | to* |
| 11:50.36 | *** join/#devuan Gost_119 (~rooms@82-132-247-63.dab.02.net) |
| 11:51.24 | DocScrutinizer51 | background why I'm asking: should a VPN offer GDP to enable and control the single open&forwarded port they offer? |
| 11:54.31 | Gost_119 | Hi, is ascii suitable and stable enough as daily driver on my thinkpad? Installation didn't find any mirrors, did I do install wrong? Thanks |
| 11:54.36 | DocScrutinizer51 | obviously GDP / UPnP is usually a security nightmare unless your NAT can sort of authenticate and verify the process that requets a port forward |
| 11:56.30 | DocScrutinizer51 | for a VPB established on same system, I think you could verify which process sent the UPnP query, right? |
| 11:56.57 | DocScrutinizer51 | VPN even |
| 11:58.21 | DocScrutinizer51 | dang, is UPnP defined to use UDP so not easy to find out who's the sending process? |
| 12:01.24 | ca-on-adam | I don't know about uPnP, but it's one of those things that's on my radar to learn about in the future. I already know that there have been / are security issues. I also know that my friend was having a lot of frustration with a beta computer game that seemed to be screwing up uPnP so he just did a port forward. |
| 12:05.01 | fsmithred | Gost_119, did you get a choice of mirrors? If so, which one did you choose? |
| 12:08.13 | Gost_119 | fsmithred: choice of 3 for GB, each one didn't find suitable for my Release |
| 12:08.56 | fsmithred | deb.devuan.org should find something |
| 12:09.07 | fsmithred | try without a country code |
| 12:10.04 | Gost_119 | Jessie is a bit dated. Is Ascii out of beta soon? |
| 12:10.25 | fsmithred | yes, we're trying to get rc1 ready |
| 12:10.26 | Gost_119 | fsmithred: thanks I'll try |
| 12:10.53 | Gost_119 | Great work thanks |
| 12:10.56 | fsmithred | main problems with ascii now are the installer... |
| 12:11.14 | fsmithred | and some of the desktop authentication stuff |
| 12:12.54 | fsmithred | if you're used to starting with a minimal install and adding the pieces you want, you'll probably be fine. |
| 12:24.35 | DocScrutinizer51 | ca-on-adam: I also never touched or even just looked at UPnP until 2 days ago, except for disabling it on all my routers |
| 12:25.02 | DocScrutinizer51 | that's why I have to ask a few naive questions now |
| 12:27.16 | DocScrutinizer51 | first of all being: is it worthwhile, regarding the number od clients that support it? |
| 12:29.09 | *** join/#devuan AlexLikeRock (~AlexLikeR@unaffiliated/alexlikerock) |
| 12:30.42 | *** join/#devuan Oldmoss (~Oldmoss@anon-63-34.vpn.ipredator.se) |
| 12:32.15 | AlexLikeRock | god morning |
| 12:32.24 | AlexLikeRock | good * |
| 12:33.46 | djph | DocScrutinizer51: UPnP is for people too stupid to set up port forwards (or DNAT & firewall rules) |
| 12:34.19 | DocScrutinizer51 | djph: I know |
| 12:35.36 | djph | DocScrutinizer51: ohhh, you were asking ca-on-adam ... |
| 12:37.17 | djph | honestly, don't learn it. Learn how to DNAT / Port-Forward . If you *have* to learn it (e.g. because Xbox / PS4), you're best off making sure your router of choice supports defining *what* is allowed to punch random holes in your firewall. |
| 12:37.28 | ca-on-adam | Is it worthwhile to learn how it works? I'd say yes from a security perspective. But no regarding the idea of making use of it in your work. |
| 12:37.57 | DocScrutinizer51 | but for particularly android apps trying to work on a device with a VPN like privateinternetaccess, it seems like UPnP was a good approach/API to base some automation on, so stupid or lazy users don't need to go through a manual config orgy each time they start up e.g. their SIP softfone |
| 12:38.12 | ca-on-adam | DocScrutinizer - unless your work is blackhat >:) |
| 12:38.52 | djph | ca-on-adam: from a security perspective -> turn. it. off. |
| 12:39.31 | ca-on-adam | No arguments there. I agree. But knowing *why* turning it off is a must, that's worth learning. |
| 12:40.01 | DocScrutinizer51 | that's why I try to come up with additional securitz safeguard measures like VPN keeping a whitelist of apps and ports they are allowed to open |
| 12:40.17 | djph | on the chance you are forced into dealing with it (I'm lookin' at you consoles), make 200% certain your router is able to limit what devices are able to request port forwards / firewall holes via upnp. |
| 12:40.46 | DocScrutinizer51 | hehe, exactly that |
| 12:41.34 | djph | ca-on-adam: it's quite simple -> UPnP is a protocol that lets any (client) device implementing it request the host device (i.e. your router) put in firewall holes / nat rules whenever they want. |
| 12:41.47 | DocScrutinizer51 | as long as VPN client and a service client with UPnP support run on same system, the whitelist approach seems pretty safe and easily feasible |
| 12:42.54 | djph | caught a driveby zeroday? It punches invisible holes in your router, and now your PC is controlled by someone else. |
| 12:42.59 | DocScrutinizer51 | since the CP (router) can query the system to find out about all details of 'the device' (client process) |
| 12:43.13 | ca-on-adam | djph: that's the extent of what I know. I first heard of UPnP on the very neat GRC site, there was something regarding the urgency to turn it off called "Unplug & Pray" lol! |
| 12:43.40 | DocScrutinizer51 | djph: no, and with a whitelist this seems unlikely to happen |
| 12:45.15 | djph | DocScrutinizer51: yeah, if your router supports telling it "who's" allowed to ask for UPnP, sure. But *that* bit usually requires the owner to actually do something ... and let's be honest here, if a router required the owner to enable the firewall, that wouldn't be done either. |
| 12:45.17 | DocScrutinizer51 | when my VPN whitelist says 'process: /bin/acmesipfone, allowed: 5060" then I think a driveby malware has a hard time exploiting this, no? |
| 12:45.33 | djph | DocScrutinizer51: VPN and UPnP aren't the same thing. |
| 12:45.43 | DocScrutinizer51 | orly? |
| 12:45.46 | djph | really |
| 12:46.26 | djph | UPNP -> "hey I'm 192.168.1.100, and I need port forwards for UDP a,b,c, and d." |
| 12:46.26 | DocScrutinizer51 | my question was exactly about if it makes sense to implement UPnP or GDP into VPN |
| 12:47.40 | djph | I mean, you can use it for other things as well - but the major use in (consumer) networking is the above. |
| 12:48.22 | djph | for a VPN, the config is usually pushed to the client in some manner (e.g. "click _here_ to download the PIA openvpn client file") |
| 12:48.38 | DocScrutinizer51 | and I think as long as device and CP run on same system so you could do a comprehensive whitelist pproach, it does make sense |
| 12:49.50 | DocScrutinizer51 | no, PIA VPN client files are orthogonal to port forwarding, whatever they are |
| 12:50.04 | djph | DocScrutinizer51: no, you're misunderstanding. the UPNP *client* is *always* a PC, game console, etc. The UPNP *server* is *always* the device you're trying to control. There is no "I'm a UPNP client and server at the same time" |
| 12:50.38 | DocScrutinizer51 | aha |
| 12:51.11 | DocScrutinizer51 | sorry I beg to differ, both are software processes that CAN run under the same system |
| 12:51.15 | djph | well, barring a box acting as a router - then it could conceivably be a client to an upstream router, and a server to downstream PCs |
| 12:52.19 | djph | DocScrutinizer51: sure, but a device can't be a client to itself. It'd be like picking up an old landline phone, and calling your home number ... |
| 12:52.53 | DocScrutinizer51 | on your typical android smartphone, the PIA VPN process and any e.g. SIP app run on same hw in same system |
| 12:53.45 | DocScrutinizer51 | and sorry, I don't see why and what wouldn't work in this context, like you suppose |
| 12:54.52 | djph | SIP and VPN aren't UPNP |
| 12:54.58 | djph | stop conflating things |
| 12:55.14 | *** join/#devuan Uberius (~Uberius@gateway/tor-sasl/uberius) |
| 12:55.28 | DocScrutinizer51 | GDP sends a multicast request that a VPN process on same system can listen and react to |
| 12:55.47 | djph | SIP *can* use UPNP to configure upstream. PIA (or other VPN) provider *MAY* listen to UPNP requests, or they *MAY* throw them away. |
| 12:55.47 | DocScrutinizer51 | and apples are no juice |
| 12:56.05 | DocScrutinizer51 | I talk about making juice from apples |
| 12:56.20 | djph | But the PIA app is in no way itself listening for UPNP to do any sort of configuration |
| 12:56.31 | DocScrutinizer51 | so??? this is exactly what I'm talking about |
| 12:57.29 | DocScrutinizer51 | if PIA already would do that, I wouldn't need to draft a feature request for it |
| 12:58.07 | DocScrutinizer51 | abd I know of several SIP clients thatalready DO employ UPnP |
| 12:58.49 | DocScrutinizer51 | so wouldn't it be worth pondering if PIA should listen to UPnP? |
| 12:58.57 | DocScrutinizer51 | and how |
| 12:59.41 | DocScrutinizer51 | I wonder how to implement something and you keep telling me it's not implemented yet |
| 13:01.12 | *** join/#devuan ToffeeYogurtPots (~ToffeeYog@gateway/tor-sasl/toffeeyogurtpots) |
| 13:02.02 | DocScrutinizer51 | look, I *know* the PIA VPN does no UPnP *yet*, since I just do a QA review of their port forwarding |
| 13:02.42 | DocScrutinizer51 | which is a strictly manual process for now |
| 13:03.32 | DocScrutinizer51 | even to the point where user needs to read the port number and write it down to later enter it into ACMEclient config |
| 13:04.58 | DocScrutinizer51 | there's no API at all to ask about the port forwarding status, so I thought GDP was the right API to employ here, after augmenting UPnP security |
| 13:06.18 | DocScrutinizer51 | I'm asking here since here are devels, not mere users like in PIA's support channel |
| 13:06.42 | DocScrutinizer51 | no poiint in asking users about API to implement |
| 13:07.34 | DocScrutinizer51 | makes some sense now? |
| 13:08.32 | djph | no, it would be colossaly stupid of PIA to accept UPNP requests. |
| 13:08.45 | djph | There is *no* authorization / checking of what's really asking |
| 13:08.45 | DocScrutinizer51 | aha |
| 13:08.49 | DocScrutinizer51 | why? |
| 13:09.26 | djph | it is *literally* just a request to UDP port 1900 -> "hey I'm device with IP 192.168.1.x, and I need port(s) a(,b,c,d) open." |
| 13:09.32 | DocScrutinizer51 | HAT IS the whitelist part I elaborated above in verbosity to make a man wheep |
| 13:10.07 | DocScrutinizer51 | to comment you need to listen first ;) |
| 13:10.15 | djph | There IS NONE AT ALL in the protocol |
| 13:11.13 | djph | The *only* whitelisting you get with UPNP as it is today is if your router supports a firewall between it and its clients to ignore UDP1900 from unwanted UPNP sources. |
| 13:11.17 | DocScrutinizer51 | then augment the protocol!!! though you don't need to as long as both processes are on same systen, there's netstat et al to implement whitelist |
| 13:11.34 | djph | ... they're *STILL* not on the same system |
| 13:11.46 | DocScrutinizer51 | they are |
| 13:12.23 | DocScrutinizer51 | and until you checked and understood that, your comments are not helpful |
| 13:12.49 | djph | no, they aren't. |
| 13:13.06 | DocScrutinizer51 | see above |
| 13:13.24 | djph | Why do you keep ignoring the simple fact that the router / firewall is what's running the server, and the client (PC, tablet, whatever) is making the request. |
| 13:13.43 | DocScrutinizer51 | I got a device here to verify, what do you have to support your claim? |
| 13:14.02 | DocScrutinizer51 | nio, you don't understand PIA |
| 13:14.13 | DocScrutinizer51 | they have a VPN client on device |
| 13:14.25 | djph | half a dozen routers, four PCs, three phones, and knowledge of basic networking. |
| 13:14.29 | DocScrutinizer51 | which controls the port forwarding |
| 13:15.32 | DocScrutinizer51 | I'm not interested in your random router, talking about particularly PIA on Android here |
| 13:15.45 | DocScrutinizer51 | and PIA on linux |
| 13:16.19 | DocScrutinizer51 | not generic VPN on arbitrary devices |
| 13:17.17 | DocScrutinizer51 | you have a local PIA app that enables and disables the VPN *nd* the port forwarding |
| 13:17.26 | DocScrutinizer51 | *and* |
| 13:18.20 | DocScrutinizer51 | and I'm talking about a UPnP GDP communication between a SIPet-al client and that very app |
| 13:18.28 | djph | OK, here's how it works -> your client auth's to PIA -> your client says "hey PIA routers, also add these port-forwards". |
| 13:18.54 | DocScrutinizer51 | so? I'm aware |
| 13:18.56 | djph | PIA then sets up your VPN, ties you to a public IP, and forwards some ports to your VPN client. |
| 13:19.30 | DocScrutinizer51 | yes and 'my VPN client' is contralled by the PIA app |
| 13:20.00 | djph | *the app* is not altering any firewalls locally |
| 13:20.04 | djph | or port forwards |
| 13:20.18 | djph | it's a request to THE SERVERS IN PIA'S DATACENTERS |
| 13:20.26 | *** part/#devuan Oldmoss (~Oldmoss@anon-63-34.vpn.ipredator.se) |
| 13:20.36 | DocScrutinizer51 | and I'm even aware of the API between the PIA client and server to manage the port forwarding, but that's totally tangential here |
| 13:21.33 | djph | "the vpn client" being the device authenticated to PIA ... not whatever software is running on your device ... |
| 13:22.05 | DocScrutinizer51 | you really fail to listen to waht I say. I'm talking about a local client talking to the local PIA app via UPnP asking thellocal app to establish a port forwarding with PIA server |
| 13:22.48 | djph | I get what you want. It's not a usecase of UPNP, nor is it "a good idea" in any way, shape, or form. |
| 13:22.52 | DocScrutinizer51 | UPnP won't ever leave the local system |
| 13:23.06 | crimson_king | !say discussion's hot, woah |
| 13:23.06 | infobot | discussion's hot, woah |
| 13:23.13 | crimson_king | oops |
| 13:23.21 | DocScrutinizer51 | right now user does same thing manually in the PIA client GUI |
| 13:24.13 | djph | since you're talking locally, you'd use some variant of IPC - UNIX sockets, RPC calls, whatever's implemented on the host OS. |
| 13:24.26 | DocScrutinizer51 | aha |
| 13:25.04 | DocScrutinizer51 | and which SIP or other client already supports that? unlike UPnP which is in use since ages |
| 13:25.48 | djph | UPNP is a *network* protocol. |
| 13:26.21 | DocScrutinizer51 | no, UPnP is a protocol used for whaever it gets used for |
| 13:26.26 | djph | None that I know of, mainly because you don't *DO* that. |
| 13:26.58 | DocScrutinizer51 | I give ashit about you refusing to consider this usecase since 'its what it is and cant be anything else' |
| 13:27.08 | DocScrutinizer51 | nonsense |
| 13:27.59 | DocScrutinizer51 | I know of at least 2 SIP softphones and one P2P filesharing that support GDP |
| 13:28.42 | DocScrutinizer51 | and I know they could talk to a *LOCAL* controllpoint |
| 13:28.48 | DocScrutinizer51 | aka PIA APP |
| 13:31.19 | djph | No, I'm not refusing to consider it because 'it is what it is'. I'm telling you that (a) UPNP is the wrong approach and (b) even if it was the right approach, it is significantly simpler in its implementation than you seem to think. |
| 13:34.12 | djph | There *is* a solution to the stated problem out there somewhere ... but that requires PIA providing some form of API that either 3rd parties can implement to login / talk to the VPN concentrators themselves, or (b) send a request through their app ... it's all hypothetical. |
| 13:34.15 | DocScrutinizer51 | you sound like a security guy we had in harmattan |
| 13:34.43 | *** join/#devuan king_crimson (~NEOalquim@168.205.151.183) |
| 13:35.52 | DocScrutinizer51 | amd no, it's not hypothethical, itms development, I'm employed by PIA |
| 13:36.35 | fsmithred | that seems like a bad choice for a company name |
| 13:36.44 | DocScrutinizer51 | but your comments are missing the point constantly and are not any helpful |
| 13:36.47 | djph | again, until PIA provides an API for a third-party to interact with them directly, or interact with their app to request more port forwards, the discussion is hypothetical. |
| 13:37.29 | DocScrutinizer51 | you made it on my ignore list |
| 13:37.40 | djph | now, if they decided letting third party apps auto-request port-forwards (etc.) was a doable thing, then cool, new feature |
| 13:38.17 | *** join/#devuan furrywolf (~furrywolf@172.58.35.99) |
| 13:39.41 | *** join/#devuan nighty- (~nighty@s229123.ppp.asahi-net.or.jp) |
| 13:40.50 | djph | *sigh* |
| 13:43.25 | DocScrutinizer51 | if somebody else has comments as to what exactly such API provided by PIA to talk portforward to their local client should be, and why it could or could not be GDP, please speak up |
| 13:45.01 | DocScrutinizer51 | I think several existing clients for SIP, P2P etc already support GDP |
| 13:45.18 | *** join/#devuan MinceR (~mincer@unaffiliated/mincer) |
| 13:46.03 | *** join/#devuan RedAcor (~RedAcor@gateway/tor-sasl/redacor) |
| 13:46.10 | DocScrutinizer51 | which brings me back to my original question: could somebody share a lsit of linux apps that support GDP? |
| 13:46.46 | DocScrutinizer51 | a list even |
| 13:47.17 | *** join/#devuan RedAcor (~RedAcor@gateway/tor-sasl/redacor) |
| 13:50.45 | *** join/#devuan mhc (~Error0@220-235-74-96.dyn.iinet.net.au) |
| 13:51.51 | DocScrutinizer51 | I mean, if there's zilch clients out there supporting GDP, we could as well invent some new API like /bin/PIAclient --forwardport 5060:58777 |
| 13:55.03 | *** join/#devuan system16 (~system16@unaffiliated/system16) |
| 13:55.44 | *** join/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
| 14:00.08 | *** join/#devuan bwn (~bwn@c-76-114-20-89.hsd1.ca.comcast.net) |
| 14:32.16 | *** join/#devuan bwn (~bwn@c-76-114-20-89.hsd1.ca.comcast.net) |
| 14:32.58 | *** join/#devuan _0bitcount (~Big_Byte@90.162.105.206) |
| 14:36.51 | *** join/#devuan Gost_119 (rooms@27.ip-37-187-211.eu) |
| 14:52.13 | *** join/#devuan Kruppt (~Kruppt@50.111.43.24) |
| 14:53.08 | *** join/#devuan pillepalle (~Thunderbi@ip-94-114-5-11.unity-media.net) |
| 14:55.47 | *** join/#devuan Oldmoss (~Oldmoss@anon-63-34.vpn.ipredator.se) |
| 15:13.55 | *** join/#devuan Scartozzo_ (~flavio@2-238-140-4.ip244.fastwebnet.it) |
| 15:22.51 | xkr47 | wow nice, gimp 2.10 in devuan 1.0: apt-get install flatpak ; flatpak install https://flathub.org/repo/appstream/org.gimp.GIMP.flatpakref |
| 15:23.33 | xkr47 | worked beautifully |
| 15:23.38 | xkr47 | thanks guys, well done! |
| 15:25.33 | muep | nice to hear that flatpak seems to work ok also in devuan 1.0 |
| 15:27.04 | xkr47 | do you always run flatpak apps using "flatpak run xxxxx" ? i.e. symlinks not installed in /usr/bin etc? |
| 15:27.55 | muep | at least gnome can show installed flatpak applications as menu entries, just as it does for ones that come from distro packages |
| 15:28.49 | xkr47 | right |
| 15:28.58 | xkr47 | yeah I don't run a gnome desktop |
| 15:29.52 | muep | then flatpak also keeps a directory that you could add to PATH if you wish |
| 15:30.05 | xkr47 | yeah there was some "gnome-software-plugin-flatpak" pakckage to install, maybe that would provide the support, but it seems not to be available in devuan.. |
| 15:30.11 | xkr47 | oh, where? |
| 15:30.18 | muep | .local/share/flatpak/exports/bin/ for user-installed things and /var/lib/flatpak/exports/bin for system-wide installations |
| 15:30.35 | muep | but that's only in version 0.10.2 and newer so not sure if jessie has it |
| 15:30.50 | muep | https://github.com/flatpak/flatpak/releases/tag/0.10.2 |
| 15:31.03 | xkr47 | gimp didn't put anything there |
| 15:31.11 | muep | it did for me |
| 15:31.14 | xkr47 | but there is a .desktop file /var/lib/flatpak/exports/share/applications/org.gimp.GIMP.desktop |
| 15:31.32 | xkr47 | right |
| 15:31.51 | xkr47 | 0.8.9 |
| 15:31.58 | muep | it is quite easy to add a script wrapper with something like exec flatpak run org.example.Application "$@" |
| 15:32.30 | xkr47 | yeah did that already :) |
| 15:32.56 | muep | I think that's a good option if you wish to make it a bit more integrated |
| 15:53.05 | *** join/#devuan sunshavi (~user@181.64.192.62) |
| 16:00.25 | *** part/#devuan Digit (~user@fsf/member/digit) |
| 16:09.38 | *** join/#devuan _abc_ (~usre@unaffiliated/ccbbaa) |
| 16:10.12 | _abc_ | Hello. I have firefox problems on devuan which are not reproductible on windows and not on live devuan. Please read: |
| 16:10.35 | _abc_ | - devuan live boots normally from usb and runs, ff on that, not updated accesses site [*] |
| 16:11.35 | _abc_ | - devuan installed to hdd (jessie above and here and henceforth), tried with dist ff and upgraded ff (5.2.x and 5.7.x I think), does not access site [*] |
| 16:12.00 | _abc_ | certain sites seem to cause this, specifically any {ro,bg,etc}.farnell.com and mail.yahoo.com |
| 16:12.51 | _abc_ | So, again: I get an access error and sometimes certificate revoked message when accessing one or several of those sites, this is new, last 2 days only, on 2 systems, 2 different ip's, 2 isp's, only common thing is devuan jessie installed on hdd |
| 16:13.14 | _abc_ | Is there a proper faq on how to upgrade the certs in a devuan jessie install? Some are expired since 2014 |
| 16:14.15 | _abc_ | Note running from persistence usb stick also shows the problem, i.e. live, with persistence, upgraded or non upgraded ff. |
| 16:14.53 | *** join/#devuan zjason (~user@111-250-144-28.dynamic-ip.hinet.net) |
| 16:15.28 | _abc_ | Note the sites sometimes work, briefly, then the error reappears. This is really strange. |
| 16:16.14 | _abc_ | Any other site works, i.e. this is localized. The common thing between mail.yahoo.com and *.farnell.com is they are farmed on akmai servers, both may be in .uk physically, or .nl |
| 16:17.14 | _abc_ | I'll be lurking for clues here. Any ideas where to look? |
| 16:17.56 | _abc_ | Note I tried wget, and setting the user-agent to something bogus made it work. If not set, fail. This looks like a firewall level blocking or something like that, no? Other browsers also work, I even tried dillo! |
| 16:19.44 | *** join/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
| 16:22.13 | *** join/#devuan cirdan (~cirdan@c-73-197-122-12.hsd1.nj.comcast.net) |
| 16:27.43 | _abc_ | Incidentally, right now it works, but it tends to be flaky and come and go randomly. Were there any major security cert related changes recently? Like in the last 2 days? |
| 16:29.23 | mcr | what certificates are you talking about? In general, firefox comes with it's own list. |
| 16:39.41 | _abc_ | Yes, the certs in ff are expired since 2014 or so, mostly |
| 16:39.52 | _abc_ | Including in the upgraded 2017 released 5.2.6 version |
| 16:40.08 | _abc_ | I can't see them on the system so I assume they are in certdb8 or such in ff profile dir |
| 16:40.19 | _abc_ | mcr: ^ |
| 16:43.16 | _abc_ | And I meant version 52.2.x to 52.6.x above |
| 16:51.17 | fsmithred | ca-certificates package in jessie was last updated in May 2017 (unless there was an update in the last month or two and I don't have it.) |
| 16:52.25 | _abc_ | Hm mine looks much older. I'm trying to upgrade it now |
| 16:52.44 | fsmithred | check in /var/log/apt/history.log* |
| 16:52.47 | _abc_ | Does ff pick up ca-certs updated on disk by itself or does it need commands |
| 16:52.59 | fsmithred | I don't know |
| 16:53.01 | _abc_ | fsmithred: am updating now, the system is dog slow while working, will wait 10 mins |
| 16:53.09 | _abc_ | Ok, I'll look it up |
| 16:53.12 | fsmithred | what mirror you using? |
| 16:53.18 | _abc_ | No idea. Auto. |
| 16:53.54 | fsmithred | you could try deb.devuan.org, but make sure you install latest devuan-keyring first |
| 16:54.09 | fsmithred | any upgrade since last fall should already have gotten it |
| 16:54.19 | _abc_ | I have no idea how to do that. Let's wait until the sloth finishes |
| 16:54.24 | fsmithred | ok |
| 16:54.28 | fsmithred | apt-get install devuan-keyring |
| 16:55.01 | fsmithred | sed -i 's/auto.mirror/deb/g' /etc/apt/sources.list |
| 16:55.05 | fsmithred | apt-get update |
| 16:55.53 | *** join/#devuan gnarface (~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net) |
| 16:56.47 | _abc_ | sed -i -e ... I think |
| 16:56.58 | _abc_ | thanks, writing this down |
| 16:59.27 | *** join/#devuan menip (~menip@c-73-83-2-241.hsd1.wa.comcast.net) |
| 17:08.21 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 17:14.29 | *** join/#devuan pillepalle (~Thunderbi@ip-94-114-5-11.unity-media.net) |
| 17:48.12 | fsmithred | the -e is optional unless you want to do more than one thing |
| 18:00.42 | *** join/#devuan leafwiz_ (~tofu@204.51-174-97.customer.lyse.net) |
| 18:02.19 | leafwiz_ | Hello. Dunno if this is the right place to ask, but.. I'm trying to run GNS3 on my devuan system, it requiers pyqt 5.5. I have 5.3. Any tips to what I can do? |
| 18:03.15 | leafwiz_ | I would like to try stay on jessie |
| 18:06.35 | leafwiz_ | Thing about python is that it is so fuzzy about dependencies , so I'm trying to use anaconda, with conda to make virtual enviroments, but gns3 did not respect that environemt even if I pip installed it from that coda env |
| 18:07.17 | *** join/#devuan Leander (~Leander@132.147.84.158) |
| 18:08.29 | leafwiz_ | I would like to have gns-gui ver 2.1.3 |
| 18:08.37 | fsmithred | leafwiz_, I suppose you could backport the version from ascii |
| 18:09.54 | leafwiz_ | fsmithred: oki. how would I do that? |
| 18:10.25 | fsmithred | download the source, install the build-deps and then re-package. I'll find instructions for you. |
| 18:10.42 | leafwiz_ | fsmithred: cool, thx |
| 18:11.21 | fsmithred | http://forums.debian.net/viewtopic.php?f=16&t=38976 |
| 18:11.38 | fsmithred | stick with devuan repos |
| 18:12.46 | fsmithred | what's the correct package name for gns-gui? |
| 18:13.04 | leafwiz_ | gns3-gui |
| 18:13.13 | fsmithred | I'm not seeing it |
| 18:13.22 | fsmithred | there's a gns3, but version is 8.something |
| 18:13.31 | leafwiz_ | aptitude show gns3-gui |
| 18:13.32 | fsmithred | 0.8... |
| 18:13.40 | KatolaZ | leafwiz_: which distro are you on? |
| 18:13.57 | leafwiz_ | i'm on jessie |
| 18:13.59 | KatolaZ | you are mixing repos man |
| 18:14.04 | leafwiz_ | devuan jessie |
| 18:14.12 | KatolaZ | leafwiz_: you are missing repos |
| 18:14.18 | KatolaZ | jessie has only gns3 |
| 18:14.21 | fsmithred | you must have another repo |
| 18:14.26 | leafwiz_ | ahh..right. |
| 18:14.29 | leafwiz_ | I forgot |
| 18:14.35 | leafwiz_ | I have the gns repo |
| 18:14.37 | leafwiz_ | as well. |
| 18:14.55 | leafwiz_ | deb http://ppa.launchpad.net/gns3/ppa/ubuntu trusty main |
| 18:14.56 | fsmithred | ok, so if you need to backport that one, you'd get the source from there |
| 18:14.57 | leafwiz_ | that one |
| 18:15.09 | leafwiz_ | sure |
| 18:15.25 | fsmithred | and hope you don't get caught up in missing dependencies |
| 18:15.32 | leafwiz_ | I'm thinking now it may be easier ot just upgrade to ascii :p |
| 18:15.41 | fsmithred | I guess worst case... you said it |
| 18:15.44 | KatolaZ | leafwiz_: ascii does not have it either |
| 18:15.56 | KatolaZ | it has 0.8.7 |
| 18:16.04 | KatolaZ | gns3-0.8.7 |
| 18:16.04 | fsmithred | yeah, but gns probably has somehting that works with ascii/stretch |
| 18:16.20 | leafwiz_ | what I need is pyqt 5.5 |
| 18:16.34 | fsmithred | 5.3 in jessie, 5.7 in ascii |
| 18:16.46 | leafwiz_ | I tried getting int though anaconda, but pip install of gns did not respect the virtual env |
| 18:17.04 | fsmithred | I don't know what those words mean |
| 18:17.21 | leafwiz_ | yeah.. Its a python thing. |
| 18:17.40 | _abc_ | those are snake taming snakes. |
| 18:17.52 | leafwiz_ | jupp.. sneaky snakes |
| 18:18.25 | _abc_ | As opposed to non-sneaky snakes? |
| 18:19.39 | leafwiz_ | yeah, you kinda have to be sneaky to be a snake |
| 18:20.43 | leafwiz_ | Hence you should excpect sneakyness with Python |
| 18:21.10 | leafwiz_ | oki. Ascii upgrade it is |
| 18:21.20 | KatolaZ | all snake charmers end up being bitten by the beasts ;) |
| 18:21.35 | KatolaZ | it's just a matter of time |
| 18:21.39 | leafwiz_ | Just so silly to have to upgrade your whole system for one app... |
| 18:21.50 | leafwiz_ | But that is kinda the linux way I think |
| 18:21.57 | KatolaZ | no leafwiz_ |
| 18:22.00 | KatolaZ | it's the python way |
| 18:22.09 | KatolaZ | :) |
| 18:22.52 | leafwiz_ | yeah.. agree, that snake.. of sneakyness |
| 18:24.38 | *** join/#devuan cocoadaemon (~foo@2a01:e35:8a99:e90:1202:b5ff:fe91:e4ca) |
| 18:31.44 | *** join/#devuan lldd_ (~atrapado@unaffiliated/atrapado) |
| 18:41.11 | leafwiz_ | So, .. waiting for my system to upgrade. Was thinking. What is your guys most used / favourite cli command? |
| 18:41.45 | leafwiz_ | mine is vmstat 1, htop, and mtr --curses |
| 18:47.51 | _abc_ | fsmithred: apparently I'm already at the latest certs level |
| 18:49.07 | *** join/#devuan thaller (~thaller@ppp-62-216-203-175.dynamic.mnet-online.de) |
| 18:53.33 | leafwiz_ | Got a error when upgrading, https://pastebin.com/PDQEDuLE |
| 18:54.16 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 18:55.49 | leafwiz_ | Its gives an error on a missing file. |
| 18:56.11 | KatolaZ | leafwiz_: give another apt-get dist-upgrade, please |
| 18:56.48 | KatolaZ | anyway, the dist-upgrade has finished |
| 18:57.34 | leafwiz_ | https://pastebin.com/5Ne7Hrqu |
| 18:59.31 | leafwiz_ | ahh.. sorry. I think its the anaconda that is messing with things |
| 18:59.44 | KatolaZ | mmmhhhhh |
| 19:00.08 | leafwiz_ | those snakes |
| 19:04.07 | *** join/#devuan sokan (~Henry_D@unaffiliated/totaloblivion) |
| 19:15.09 | leafwiz_ | OKay, I managed to fight of the snake, but I think the bugger ate one of my /etc files.. /etc/dbus-1/system.conf https://pastebin.com/wwTnAgAk |
| 19:15.19 | leafwiz_ | Anyone have a copy? :p |
| 19:17.14 | KatolaZ | leafwiz_: that file does not come from a Devuan package |
| 19:19.08 | *** join/#devuan Leander (~Leander@132.147.84.158) |
| 19:19.31 | *** join/#devuan Xenguy (~Xenguy@unaffiliated/xenguy) |
| 19:22.15 | leafwiz_ | Hmm.. It looks like its part of the freedesktop system |
| 19:22.58 | leafwiz_ | But I'm unsure if I can grab one of the net or if I need a devuan specific file. |
| 19:23.08 | leafwiz_ | I have another system I can grab it from |
| 19:23.20 | leafwiz_ | or probably grab it |
| 19:25.02 | *** join/#devuan pillepalle (~Thunderbi@ip-94-114-5-11.unity-media.net) |
| 19:26.11 | KatolaZ | leafwiz_: there is no package in devuan that provides that file |
| 19:26.24 | KatolaZ | it might come from something else you have installed maybe? |
| 19:27.42 | Jjp137 | leafwiz_: perhaps try reinstalling the dbus package |
| 19:28.03 | leafwiz_ | Strange, the file is on my other devuan system (my laptop), ascii/ceres |
| 19:28.22 | leafwiz_ | Im running mate as a desktop with xmonad as a wm |
| 19:28.46 | leafwiz_ | But I will try and copy it over, and see it will work |
| 19:31.11 | leafwiz_ | yayj! all good. |
| 19:31.30 | leafwiz_ | Or, on next reboot we will see.. :p |
| 19:31.37 | muep | it is quite difficult to tell if the file is actually installed by a package |
| 19:33.37 | KatolaZ | well, it could have been created at runtime... |
| 19:33.45 | KatolaZ | apt-file does not find it anywhere |
| 19:34.05 | leafwiz_ | https://www.apt-browse.org/browse/ubuntu/trusty/main/i386/dbus/1.6.18-0ubuntu4/file/etc/dbus-1/system.conf |
| 19:34.37 | *** join/#devuan blitzed (~blitzed@185.236.200.206) |
| 19:35.22 | Jjp137 | from what I can tell by looking at the Debian package, /etc/dbus-1/system.conf might be a symlink to /usr/share/dbus-1/system.conf, which is installed by dbus afaik |
| 19:36.05 | KatolaZ | then just apt-get install --reinstall dbus |
| 19:36.09 | KatolaZ | should be enough |
| 19:36.21 | KatolaZ | (or ln -s, for that matter) |
| 19:36.55 | muep | one of my pet peeves about typical GNU/Linux package management tools is that they make it so easy to use maintainer scripts to install stuff that the package manager isn't aware of |
| 19:41.49 | *** join/#devuan most_enter (~most_ente@62-46-247-149.adsl.highway.telekom.at) |
| 19:41.59 | *** join/#devuan NEOalquimista (~NEOalquim@168.205.151.31) |
| 19:47.35 | *** join/#devuan _0bitcount (~Big_Byte@90.162.105.206) |
| 19:56.45 | NEOalquimista | How do I update hwdb after creating a custom config file? The method I used to use depends on systemd. |
| 20:04.54 | NEOalquimista | Nevermind, I got it. "udevadm hwdb --update" |
| 20:05.04 | NEOalquimista | followed by reboot |
| 20:07.32 | KatolaZ | it could be sufficient to restart udev, actually |
| 20:07.43 | KatolaZ | (after udevadm hwdb --update) |
| 20:08.21 | KatolaZ | actually, there is no need to restart udev |
| 20:08.26 | KatolaZ | from the manpage: |
| 20:08.39 | KatolaZ | "The |
| 20:08.40 | KatolaZ | <PROTECTED> |
| 20:08.43 | KatolaZ | :) |
| 20:08.49 | KatolaZ | so no need to restart udev |
| 20:08.54 | KatolaZ | or to reboot... |
| 20:11.38 | NEOalquimista | strange, it didn't fix the key glitch until I rebooted |
| 20:12.25 | NEOalquimista | I used a custom config to correct a problem that makes page up and page down scroll erratically. |
| 20:42.09 | *** join/#devuan Uberius (~Uberius@gateway/tor-sasl/uberius) |
| 20:43.32 | *** join/#devuan Oldmoss (~Oldmoss@anon-43-53.vpn.ipredator.se) |
| 21:06.18 | *** join/#devuan Uberius (~Uberius@gateway/tor-sasl/uberius) |
| 21:07.18 | *** join/#devuan crimson_king (~NEOalquim@168.205.151.31) |
| 21:43.40 | *** join/#devuan FlibberTGibbet (~david@cust241-dsl93-89-129.idnet.net) |
| 22:13.22 | *** join/#devuan blitzed (~blitzed@185.236.200.206) |
| 22:14.55 | *** join/#devuan stanz (~stanz@162.250.14.86) |
| 22:16.54 | *** part/#devuan stanz (~stanz@162.250.14.86) |
| 22:17.36 | *** join/#devuan gattuso (~gattuso@pompel.me) |
| 22:34.01 | *** join/#devuan Besnik_b (~Besnik@ppp-94-66-221-205.home.otenet.gr) |
| 22:39.48 | *** join/#devuan blitzed (~blitzed@196.245.9.51) |