rwp | ibanja, The first thing with "erase" is your stty driver. Try "stty -a" to dump all of the tty driver settings. | 01:42 |
---|---|---|
rwp | ibanja, Some terminals notably from IBM and HP use BS instead of DEL for the erase character. It's been a schism since the early days. But in the end DEL has one the day. | 01:43 |
rwp | Usually the erase character is more tightly associated with $TERM value. TERM is just an environment variable. But those things must be changed together. | 01:45 |
rwp | ibanja, Your report of space not working and needing shift+space for space has me worried your keyboard is having an issue. Because that seems very odd. | 01:45 |
rwp | Usually space and shift+space would produce the same character. | 01:46 |
gnarface | it makes me think one of the other characters is stuck down | 01:46 |
gnarface | like capslock or ctrl | 01:46 |
rwp | Possibly. That's a good though. | 01:48 |
rwp | Also as far as I know "dpkg-reconfigure keyboard-configuration" will affect the console login on the Linux vt virtual terminals only. | 01:48 |
rwp | ibanja, Are you using the system from the Linux vt consoles? Or from a graphical X session possibly using XFCE Terminals? If so then the xfce4-terminal will be in control of the pty / stty driver settings. | 01:49 |
* Xenguy finally learned how to do a proper recursive grep today, after years of confusion about it... | 01:50 | |
Xenguy | (the syntax sucks) | 01:50 |
rwp | Congratulations Xenguy! You have taken your first step into a larger world. | 01:50 |
Xenguy | hah | 01:51 |
rwp | I assume you mean "find . -type f -exec grep pattern {} +" and not "grep -r pattern ."?? | 01:51 |
Xenguy | No, the latter... I could never get it to work as expected (it would skip the recursion) | 01:51 |
Xenguy | I would try, say, grep -r 'foo' *.html | 01:52 |
Xenguy | Or grep -r 'foo' * | 01:52 |
rwp | Before "grep -r" there was "rgrep". Which still exists. | 01:52 |
Xenguy | But that was just wrong | 01:52 |
Xenguy | (GNU) grep wants: grep -r 'foo' --include=*.html | 01:52 |
Xenguy | No | 01:52 |
rwp | It's often useful to use 'echo' to see what is actually being passed to commands. Try "echo grep -r foo *" and see what the * will expand to. | 01:53 |
Xenguy | (GNU) grep wants: grep -r 'foo' . --include=*.html | 01:53 |
Xenguy | rwp, Nice tip | 01:53 |
rwp | I consider using * to be dangerous and I suggest always using ./* as a defensive measure. | 01:53 |
rwp | Because if you have a file in the current directory starting with a dash then * expands to be that, which is taken as an option. But ./* would expand to ./-whatever and would not. | 01:54 |
rwp | Even though grep -r is convenient and shorter to type I rather wish that grep had never included it. Because that opened the Pandora's box. | 01:55 |
rwp | Which you see with the --include=pattern option. | 01:55 |
rwp | Because then people wanted ways to include and exclude things. So then later those were added. | 01:55 |
rwp | And people wanted to avoid hitting (and probably stalling) on pipes. | 01:55 |
rwp | While others wanted it to read from pipes. The required options were basically the same as required in find. | 01:56 |
rwp | So in my opinion I think investing in understanding find and using it is better because then it works for grep and it also works for all other commands too. | 01:56 |
Xenguy | rwp, The reason I didn't find the proper 'grep -r' solution sooner was because I ditched it for solutions that used 'find', where I got reliable results | 01:57 |
Xenguy | Or rather find + grep | 01:57 |
Xenguy | I also learned today that find's '-H' option is useful for requesting find mention the filename in the search returns | 01:59 |
Xenguy | I also learned that if one is search a git repo, then 'git grep' is faster and easier... | 01:59 |
Xenguy | And finally I learned that if one wants to grep an entire git repo history of commits, then there's: git log -S foobar | 02:00 |
Xenguy | So definitely a 'TIL' day : -) | 02:00 |
rwp | Let me put this out there for why find has a different syntax than other Unix/BSD/GNU commands: http://doc.cat-v.org/unix/find-history | 02:01 |
Xenguy | yeah I always found find's syntax pretty wacky | 02:02 |
Xenguy | dmr! | 02:04 |
rwp | dmr said that the description was consistent with what he knew. So I say plausible and am going with that until I learn something more authoritative. | 02:05 |
rwp | find was written on spec and the way it is was the way the spec was written. | 02:05 |
Xenguy | It makes some kind of sense | 02:06 |
rwp | Anyway... Back on the "grep -r pattern *" thing... I know you figured it out but for the other lurkers it is only recursive for named arguments. | 02:07 |
rwp | It's an FAQ: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f | 02:07 |
Xenguy | rwp, That's funny, I thought the '+' needed to be escaped (like ';'), but perhaps not: find . -name '*.html' -exec chmod a+r {} + | 02:13 |
rwp | + is not a shell metacharacter and does not need to be escaped. ; is a shell metacharacter and so does. Either \; or ';' or ";". | 02:13 |
rwp | Which is another reason to prefer the {} + form over the {} \; form. | 02:14 |
Xenguy | TIL : -) | 02:14 |
ibanja | rwp: | 04:04 |
ibanja | rwp: "stty -a" solved the problem in a specific terminal... thanks... but I need to figure out what is causing this... | 04:08 |
ibanja | I am using lxterminal | 04:09 |
sedrosken | Any plans to ever implement support for dinit? to me it's like... systemd, but... good? more like the potential of what systemd could have become if the goal wasn't to become another monolith on top of the kernel | 04:32 |
golinux | Maybe take it to #off-topic since it's not a support issue? | 04:35 |
sedrosken | ... maybe this ought to have gone to #off-topic yeah | 04:35 |
golinux | :) | 04:36 |
Guest6 | hello i was doing build-sudo.sh from https://git.devuan.org/devuan/installer-iso and it said intarget:2: command not found: chroo | 08:16 |
Guest6 | chroot* | 08:16 |
gnarface | Guest6: you probably have to install it. i imagine there may be other stuff too. | 09:08 |
gnarface | Guest6: you might want to install build-essential too if you haven't already | 09:11 |
rrq | Guest6: with build-sudo.sh the host need to have ome few commands installed, including in particular chroot, debootstrap and rsync. Also, that debootsrap might need a manual patch, if e.g. you want to build for daedalus on a chimaera host | 09:30 |
rrq | Guest6: with build-sudo.sh the host needs to have some few commands installed, including in particular chroot, debootstrap and rsync. Also, that debootstrap might need a manual patch, if e.g. you want to build for daedalus on a chimaera host. | 09:31 |
Guest6 | how do i install chroot on devuan | 09:33 |
gnarface | apt-get install chroot | 09:33 |
gnarface | same as debian | 09:33 |
gnarface | unless they've removed chroot now... | 09:34 |
syco | nope | 09:34 |
Guest6 | Unable to locate package chroot | 09:38 |
rrq | I suppose it belongs to the coreutils package | 09:39 |
rrq | at /usr/sbin/chroot .. possibly you don't have /usr/sbin in your sudo path? | 09:40 |
onefang | Yep, it's in coreutils. | 09:40 |
rrq | that is also something needed during the build /sbin and /usr/sbin in your PATH | 09:41 |
fluffywolf | looks like I might have a devuan apt bug. | 15:39 |
fluffywolf | poking at it now | 15:40 |
fluffywolf | looks like it's not apt. working through a script now. | 15:43 |
fluffywolf | yeah, I think it is apt. | 15:44 |
fluffywolf | aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Devuan/chimaera | 15:44 |
fluffywolf | add-apt-repository doesn't work on devuan. | 15:45 |
fluffywolf | seems to need devuanizing | 15:46 |
fluffywolf | bbl | 15:46 |
fluffywolf | looks like it's provided by software-properties-common, which I'm entirely unfamiliar with.... but it's broken on devuan. | 15:53 |
rm | hello | 16:07 |
rm | I have a laptop with devuan that's only turned on occassionally, each time I use it, I run an apt-get update + apt-get dist-upgrade | 16:08 |
rm | and it feels like there are no updates at all (for Beowulf), for months | 16:08 |
rm | Debian would have multiple packages updated in the same period | 16:09 |
rm | do you pass these on? | 16:09 |
rm | is there a public update log or such, to disprove my impression (about no updates)? | 16:09 |
UsL | what does your source list look like? | 16:11 |
rm | https://dpaste.com/BDNME5HFG | 16:11 |
UsL | that looks fine. | 16:12 |
UsL | as I understand it deb devuan is mostly redirecting it's updates through to debians | 16:14 |
UsL | so you should get updates.. | 16:14 |
UsL | did you get the polkit security stuff for example? | 16:15 |
UsL | I just did an update and found xterm in there: | 16:19 |
UsL | xterm/now 327-2+deb9u2 amd64 [installed,upgradable to: 327-2+deb9u3] | 16:19 |
rm | according to /var/log/apt/history*, the last update I had was on 27 Dec 2021 | 16:21 |
rm | since then and as of today there are no more updates | 16:21 |
rm | so not "months", but 1.5 or so | 16:22 |
UsL | that's weird. It's long overdue | 16:22 |
UsL | no errors when fetching updates? All is good? | 16:24 |
rm | yes | 16:24 |
UsL | do a apt auto-clean | 16:25 |
UsL | and then apt update | 16:25 |
UsL | that helped me _one_ time | 16:25 |
rm | no changes | 16:25 |
UsL | either aptitude, apt-get, and apt is complaining? Must be a bug somewhere | 16:27 |
UsL | I have never experienced apt not updating so my knowledge is poor in that regard. Maybe some vuan would know. They're usually active a bit later | 16:30 |
UsL | rm: wait, why do you do dist-upgrade and not just upgrade? | 16:34 |
rm | why not? | 16:35 |
rm | it is the same, just allows it to also replace packages with different ones, if needed | 16:35 |
buZz | it is not the same | 16:36 |
fsmithred | it's usually the same if you're running the stable suite | 16:38 |
rm | apt-get upgrade doesn't find any updates right now either | 16:43 |
buZz | wait, you're on a old distro ;) | 16:51 |
buZz | without security repos added you wont get anything for that | 16:51 |
fsmithred | I had a bunch in beowulf three weeks ago, but the last time before that was July, and there were only a few then. | 16:51 |
rm | buZz, see my source.list in paste above, I got security enabled | 16:53 |
buZz | why only main btw? | 16:53 |
buZz | and not non-free and contrib | 16:54 |
buZz | dont think i own any laptop that i could even get on network with, without non-free :D | 16:56 |
buZz | sadly | 16:56 |
fluffywolf | all the spring energy storage devices I've seen used a wide flat coil spring, either that winds from inside to outside like the spring inside a tape measure, or a curved spring, like the tape measure blade itself, between two rollers. | 19:41 |
fluffywolf | grr, wrong window | 19:41 |
rwp | rm, Do you have the package unattended-upgrades installed and is that package automatically upgrading your system at boot time before you attempt your manual upgrade? | 19:43 |
rwp | If so then at that time you would find nothing to upgrade because it had already just been done. | 19:43 |
rwp | Look at the /var/log/dpkg.log file to see the history of dpkg package upgrades. That's the main package utility, which apt calls, so would log more details than the apt log. | 19:43 |
rwp | Upgrades depend upon what you have installed but I see libnss3 came through security on 2022-01-26 and is likely installed on every system. | 19:45 |
rwp | Look at "apt-cache policy libnss3" to see what versions and repositories it shows. I see this on a Beowulf system: https://dpaste.com/H8JQEAJ7N | 19:46 |
rm | rwp, no I do not have unattended-upgrades | 19:47 |
rm | same in /var/log/dpkg.log, the last upgrades were on 2021-12-27 | 19:49 |
rm | libnss3:amd64 2:3.42.1-1+deb10u3 | 19:49 |
rwp | That is from main and current in main but there is an upgrade you should be getting from security for it taking it to 2:3.42.1-1+deb10u5 | 19:50 |
rm | this is what I get: https://dpaste.com/BEVC93QXQ | 19:51 |
rm | I guess this might be messing with security, | 19:51 |
rm | APT::Default-Release "beowulf"; | 19:51 |
rwp | https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=libnss3&x=submit | 19:52 |
rm | but it shouldn't | 19:52 |
rm | and I did get updates back in December | 19:52 |
rwp | So... Why do you have that set? | 19:52 |
rwp | Try removing it, then running apt-get update again, then attempting another upgrade. | 19:53 |
rm | yeah, commenting it out helps | 19:53 |
rwp | Yay! \o/ | 19:53 |
rm | thanks! | 19:54 |
rwp | I admit that I have never used Pinning more than very sparingly and so would need to read all of the documentation on it in order to understand it. | 19:54 |
rm | I typically set that because in Debian I often combine multiple branches | 19:55 |
rm | but now I remember that even in Debian I recently updated my setup script to use a less problematic version of it, else it also prevented some updates in Debian too | 19:55 |
rm | APT::Default-Release "/^beowulf(|-security|-updates)$/"; | 19:56 |
rm | to this | 19:56 |
rm | but it was not applied to this machine until now | 19:56 |
rwp | With that is that it will "stick" to a particular repository. And in this case the main beowulf one. Which would avoid beowulf-security repostitory. | 19:57 |
rwp | I disapprove of building Frankenstein systems but... Happy Hacking! :-) | 19:57 |
rwp | One can grep the code name for any particular repository: grep Codename /var/lib/apt/lists/deb.devuan.org_merged_dists_beowulf-security_InRelease | 20:00 |
rwp | Maybe this is more useful: grep Codename /var/lib/apt/lists/*_InRelease | 20:01 |
rm | yeah, but this doesn't break any new ground :p | 20:24 |
Guest6 | somebody said that coreutils pacakge includes the chroot command i have coreutils installed but i dont have the chroot command | 21:47 |
rm | Guest6, maybe you try running it as regular user? | 21:54 |
rm | it only works with sudo or from 'root' | 21:54 |
rrq | Guest6: you must make sure that root has /sbin and /usr/sbin when sudo-ing to it. | 21:56 |
fsmithred | try 'su -' instead of just 'su' to get root | 21:57 |
fsmithred | and then the sbins will be in root's path | 21:57 |
rrq | no, he needs root to get that in path when using sudo | 21:57 |
fsmithred | huh? | 21:57 |
fsmithred | sudo should already have the right path | 21:58 |
Guest6 | im doing su | 21:58 |
fsmithred | yeah, and since beowulf, there's a change in the behavior of su | 21:58 |
fsmithred | just su leaves you with user's PATH | 21:59 |
fsmithred | su - | 21:59 |
Guest6 | ok so i need to use sudo? | 21:59 |
fsmithred | or su - | 21:59 |
fsmithred | see the dash after the su? | 21:59 |
fsmithred | or... | 21:59 |
rrq | the script build-sudo.sh is typically run as non-root user, and it does sudo | 21:59 |
fsmithred | oh | 22:00 |
fsmithred | like live-sdk | 22:00 |
Guest6 | whats the dash for? | 22:00 |
fsmithred | to give you a login shell so you have root's PATH | 22:00 |
fsmithred | but it sounds like you need to enable sudo since it's built into the script | 22:01 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!