| adhoc | morning all | 01:16 |
|---|---|---|
| adhoc | trying to figure out what happened to the 'at' command | 01:16 |
| adhoc | as it does not appear to be in the repo, tried searching and what replaced it? | 01:17 |
| adhoc | dpkg --search at | grep "/at$" | 01:18 |
| adhoc | does not come up with any likely candidates | 01:18 |
| gnarface | pkginfo lists it still. if it has been removed then it was very recently... | 01:21 |
| peterrooney | adhoc: apt-get install at # ; apt-file allows for searching for not-installed files: apt install apt-file && apt-file update && man apt-file | 01:21 |
| adhoc | its its own package now ? | 01:22 |
| adhoc | hmm | 01:22 |
| gnarface | since jessie at least | 01:22 |
| adhoc | ah | 01:22 |
| adhoc | thanks folks | 01:23 |
| peterrooney | adhoc: you're welcome. apt-file has prevented more google searches than duckduckgo | 01:23 |
| adhoc | that searches files in packages? | 01:24 |
| rrq | https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=file&q=bin%2Fat&x=submit | 01:24 |
| adhoc | dang, could not find pkginfo.devuan.org from searches | 01:25 |
| adhoc | rrq: that would have saved a lot of time and me posting here =P | 01:25 |
| adhoc | =) | 01:25 |
| adhoc | actually, that is just package name search? | 01:27 |
| gnarface | i think so | 01:28 |
| adhoc | weird it times out searching for package names | 01:28 |
| gnarface | not sure | 01:28 |
| adhoc | oh well, thanks for the help folks, laters =) | 01:28 |
| rrq | pkginfo.devuan.org does package search (apt-policy) or file search (apt-file) | 01:46 |
| rrq | an empty search results in fantastic page of description. | 01:46 |
| CAPTCHA_REQUIRED | /etc/default/grub is missing, how do I configure grub's config generator settings on Devuan 4? | 03:38 |
| CAPTCHA_REQUIRED | also, what is the process when a patch that fixes a bug in stable gets submitted? | 03:39 |
| CAPTCHA_REQUIRED | i'm looking at a bug report, and it looks like the patch was merged into unstable | 03:39 |
| CAPTCHA_REQUIRED | but | 03:39 |
| CAPTCHA_REQUIRED | it never came back down to stable, fixing the bug | 03:39 |
| bb|hcb | That is a long road - first the patch is included in the packaging, then the package uploaded to unstable, then it may (or may not) migrate to testing and finally comes out as stable with the next stable version. In case the bug is serious enough, there is a process for the maintainer to upload a stable update, but that is also quite slow... | 03:47 |
| bb|hcb | Which bug is that? | 03:48 |
| CAPTCHA_REQUIRED | bug #983505 on Debian's BTS | 03:49 |
| CAPTCHA_REQUIRED | are you saying that a simple bugfix like this isn't going to make it to stable until Daedalus? | 03:49 |
| CAPTCHA_REQUIRED | as in only MAJOR bugs get patched in stable? | 03:50 |
| CAPTCHA_REQUIRED | that seems absurd, by the time Daedalus release, the patch won't even be relevant as a new version will be released | 03:51 |
| gnarface | is grub a package devuan forks? | 04:01 |
| gnarface | unforked packages aren't changed so we'll get the patches for them when debian gets them | 04:02 |
| bb|hcb | Yes, exactly. That is the definition for stable as per Debian | 04:02 |
| bb|hcb | And from what I see the doas package came in unstable yesterday, 4 more days to go in testing. Because testing and stable and close enough now, it may be OK to install the package from testing, but in case they have diverged, the only option is to backport it | 04:04 |
| bb|hcb | https://qa.debian.org/developer.php?email=scupake%40riseup.net | 04:05 |
| bb|hcb | Devuan will automatically fetch stable(bullseye) in chimaera and testing(bookworm) in daedalus | 04:05 |
| CAPTCHA_REQUIRED | ok | 04:07 |
| CAPTCHA_REQUIRED | I thought only major version changed were not allowed per debian stable, but bug fixes and patch levels were | 04:07 |
| bb|hcb | I do not say that I agree with that policy; just explain how it works :) | 04:08 |
| CAPTCHA_REQUIRED | thankyou, clearly i just didn't understand how debian stable worked well enough | 04:09 |
| CAPTCHA_REQUIRED | is there an easier place to grab a compiled binary package from unstable then browsing a package mirror manually? | 04:11 |
| bb|hcb | That is why I use testing on my lap/desk-tops; servers are a different story | 04:12 |
| CAPTCHA_REQUIRED | well | 04:12 |
| CAPTCHA_REQUIRED | doesn't testing have major version changes in software? | 04:13 |
| CAPTCHA_REQUIRED | that can break with an update of the system | 04:13 |
| bb|hcb | https://packages.debian.org/unstable/doas (on the previous link, package name links to package tracker, there on the left is binaries) | 04:13 |
| CAPTCHA_REQUIRED | ok | 04:17 |
| gnarface | so, i think debian stable does allow non-major updates that are critical security or stability related fixes | 04:17 |
| gnarface | but stuff that's a feature add or not considered important they wait until the next release | 04:17 |
| gnarface | it would have to be something serious that affects everyone | 04:18 |
| CAPTCHA_REQUIRED | i wonder if that will be considered serious | 04:18 |
| CAPTCHA_REQUIRED | it is very annoying | 04:19 |
| bb|hcb | annoying!=serious IMHO, definitely not considered | 04:19 |
| gnarface | it would also have to be something not resulting from a corner-case due to a rare or unorthodox configuration or a mistake | 04:20 |
| gnarface | though if it's actually a bug in the installer itself rather than the grub package, someone here will have to manually deal with it | 04:21 |
| CAPTCHA_REQUIRED | we aren't talking about bugs in grub but bugs in the package script of doa | 04:22 |
| CAPTCHA_REQUIRED | s | 04:22 |
| bb|hcb | How does doas relate to the installer? | 04:22 |
| bb|hcb | https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=doas&x=submit | 04:22 |
| CAPTCHA_REQUIRED | no relation | 04:22 |
| CAPTCHA_REQUIRED | no relation to grub | 04:23 |
| bb|hcb | There you can see if the package is forked. Forked packages contain +devuanN in the version | 04:23 |
| rrq | and there's a package download link for manual downloading as well | 04:25 |
| CAPTCHA_REQUIRED | is there a non-gtk3 alternative to synaptic? | 04:27 |
| gnarface | dselect? | 04:27 |
| CAPTCHA_REQUIRED | was hoping for a gui but i'll check this out | 04:28 |
| CAPTCHA_REQUIRED | it's not that apt is intimidating, it's that it's more convienent and faster to explore packages and do large operations in a gui | 04:28 |
| gnarface | only other gui i'm coming up with is gnome-software and something called gdebi | 04:29 |
| golinux | Not for the last several releases. It's been all gtk3 | 04:29 |
| golinux | That will install individual packages that you have downloaded | 04:29 |
| CAPTCHA_REQUIRED | isn't gdebi only for installing individual out of tree .dev files? | 04:30 |
| gnarface | maybe, i don't really know | 04:30 |
| golinux | No. It will install any deb | 04:30 |
| CAPTCHA_REQUIRED | i wonder if it'd be possible forward-port the last synaptic gtk2 release | 04:30 |
| gnarface | i can't claim to really know how to use dselect either but i know advocates of it sited improved package exploration times as a big feature of it | 04:31 |
| golinux | There hasn';t bee a gtk2 synaptic since jessie | 04:31 |
| CAPTCHA_REQUIRED | thanks | 04:31 |
| CAPTCHA_REQUIRED | i heard they are going to remove synaptic because it's not compatible with gnome on wayland | 04:31 |
| golinux | I know quite painfully because I do the theming for the desktop. | 04:31 |
| CAPTCHA_REQUIRED | thankyou golinux for that | 04:32 |
| golinux | And moving to ascii synaptic was a cluster**** | 04:32 |
| CAPTCHA_REQUIRED | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818366 | 04:33 |
| CAPTCHA_REQUIRED | correction, GNOME-wayland isn't compatible with synaptic | 04:33 |
| CAPTCHA_REQUIRED | so debian is going to drop synpatic | 04:33 |
| CAPTCHA_REQUIRED | (yes people realize the irony and it's discussed in the bug) | 04:34 |
| golinux | There will be an upstream package I'm sure. | 04:34 |
| golinux | Which Devuan can use if someone offers to maintain it. | 04:35 |
| golinux | Time for tea . . . | 04:36 |
| CAPTCHA_REQUIRED | i don't want to maintain gtk3 programs | 04:36 |
| CAPTCHA_REQUIRED | > /etc/default/grub is missing, how do I configure grub's config generator settings on Devuan 4? | 07:54 |
| CAPTCHA_REQUIRED | I still need help with this | 07:54 |
| rwp | CAPTCHA_REQUIRED, If /etc/default/grub is missing are you sure you have grub installed? Try: dpkg -l | grep grub | 08:24 |
| CAPTCHA_REQUIRED | yes | 08:25 |
| CAPTCHA_REQUIRED | i installed grub-efi-amd64-signed | 08:25 |
| rwp | Did you happen to remove it at some point? Because it is a conffile then dpkg will preserve your change as an intended local configuration change. | 08:30 |
| rwp | I disagree with that and I will avoid mentioning who but a developer argued intensely that removing a conffile was an intentional local configuration change that had to be preserved and won the debate and so now that is the way it is. | 08:31 |
| rwp | You might need to purge grub and then install it from pristine in order to get back to a known good state. | 08:32 |
| rrq | CAPTCHA_REQUIRED: by the looks of it grub (or grub-common) has complexified its configuration with a combination of /etc/default/grub.d/ and /etc/grub.d/ ... if it locks up on also needing a /etc/default/grub file then maybe an empty such is enough | 08:33 |
| CAPTCHA_REQUIRED | rwp, no it was never installed before | 08:34 |
| CAPTCHA_REQUIRED | this is a fresh install of devuan that was made via debootstrap from another os | 08:35 |
| CAPTCHA_REQUIRED | an empty file isn't enough, because my system requires extra things added to the cmdline to boot | 08:36 |
| hyrcanus | grub is one of those things i don't muck with often enough to remember anything about | 08:36 |
| hyrcanus | life with a working brain would be so much better | 08:37 |
| CAPTCHA_REQUIRED | how do you know your brain insn't only stuck in a preboot strate | 08:39 |
| CAPTCHA_REQUIRED | state | 08:39 |
| CAPTCHA_REQUIRED | like realmode | 08:39 |
| rrq | interesting. I have such a file (upgrade from beowulf) but no package admitting to owning it | 08:39 |
| rwp | rrq, Try: grep -l /etc/default/grub /var/lib/dpkg/info/grub* | 08:39 |
| CAPTCHA_REQUIRED | yeah, there | 08:39 |
| CAPTCHA_REQUIRED | there | 08:39 |
| CAPTCHA_REQUIRED | there's a grub.d in it's place | 08:39 |
| rrq | maybe your use case is unheard of in grub dev circles. | 08:40 |
| CAPTCHA_REQUIRED | with an empty (only comments) 10.whatever | 08:40 |
| rwp | I haven't used the -signed version before. | 08:40 |
| CAPTCHA_REQUIRED | it's for secureboot | 08:40 |
| CAPTCHA_REQUIRED | the kernels are signed too | 08:40 |
| rwp | Right. But not having used it I don't personally know if it uses /etc/default/grub or not. It might consider that insecure or something. | 08:41 |
| CAPTCHA_REQUIRED | rrq, what happens when you run grub2-mkconfig? | 08:41 |
| rrq | seems to be set up by grub-efi-amd64.postrm | 08:41 |
| CAPTCHA_REQUIRED | no it means the binary elf is signed | 08:41 |
| CAPTCHA_REQUIRED | that's verified by the motherboard efi itself | 08:42 |
| rrq | ie grub-efi-amd64 | 08:42 |
| rrq | I don't have grub2-mkconfig | 08:43 |
| CAPTCHA_REQUIRED | what about grub-mkconfig | 08:46 |
| rrq | I have that, but it just tell me "You must run this as root" which is outside my comfort zone | 08:48 |
| CAPTCHA_REQUIRED | it doesn't do anything but print to stdout | 08:49 |
| rrq | I would have thought so too :) | 08:50 |
| CAPTCHA_REQUIRED | you have to pipe it somewhere to make it dangerous | 08:50 |
| CAPTCHA_REQUIRED | it's weird | 08:50 |
| CAPTCHA_REQUIRED | why so many grub changes this release? | 08:51 |
| CAPTCHA_REQUIRED | every other distro besides redhat uses grub2 | 08:51 |
| CAPTCHA_REQUIRED | grub2.conf | 08:51 |
| CAPTCHA_REQUIRED | grub2-mkconfig | 08:51 |
| CAPTCHA_REQUIRED | why are we reverting back to grub1 names | 08:51 |
| CAPTCHA_REQUIRED | (not really looking for the answer to that | 08:51 |
| CAPTCHA_REQUIRED | where's the debate you were talking about rwp? maybe it has some answers on what the new precedure from configuring grub is | 08:52 |
| CAPTCHA_REQUIRED | since all the documentation is now obselete | 08:52 |
| rrq | ok, I disabled that stupid root test and ran grub-mkconfig (as me) to be blessed with some output, yes | 08:53 |
| CAPTCHA_REQUIRED | that is stupid that it checks if it has root | 08:54 |
| CAPTCHA_REQUIRED | there's no reason for it to need to be root | 08:54 |
| CAPTCHA_REQUIRED | but rrq, does it look like if you just delete the grub.d and use the old grub.conf everything works the same? | 08:54 |
| rwp | CAPTCHA_REQUIRED, Honestly I would have trouble digging it out of the BTS archives. But it was about dpkg conffile handling at the time and not grub so I don't think that helps. It just set Policy. | 08:54 |
| rrq | CAPTCHA_REQUIRED: I can pastebin my grub, if you just want to deal with this problem. Otherwise it needs a bug report (to debian) and a short period of waiting | 08:57 |
| rrq | or both, is also an option | 08:58 |
| CAPTCHA_REQUIRED | ok | 09:00 |
| CAPTCHA_REQUIRED | if you can pastebi your /etc/default/grub that would be nice | 09:00 |
| rrq | or perhaps this is with the installer failing to also install grub-efi-amd64 as well as the signed | 09:00 |
| rrq | sec | 09:00 |
| CAPTCHA_REQUIRED | i'm not really sure how to make a bug report over lack of documentation | 09:00 |
| rrq | https://paste.debian.net/1216084/ | 09:02 |
| rrq | a bug report is an email to submit at either bugs.devuan.org or bugs.debian.org with the first 2 line "formal", statimg "Package: packagename" and "Version: versioncode" | 09:04 |
| rrq | then polite description of the problem, tests and whatever would be useful | 09:05 |
| rrq | there is also a program "reportbug" that is able to make such a form letter based on a few prompted responses, and possibly even emailing it for you | 09:06 |
| debdog | what service or whatever controls the power management in Chimaera on a system without display manager and a simple window manager, fluxbox in this case? | 14:30 |
| debdog | it's not acpi | 14:31 |
| GyrosGeier | it should be acpi | 14:31 |
| GyrosGeier | X11 integration into power management is mostly a kernel thing | 14:32 |
| debdog | oy vey, I was afraid of that | 14:32 |
| GyrosGeier | the kernel performs a VT switch to a dummy terminal to make X11 stop using the graphics card | 14:33 |
| debdog | what's a VT switch? | 14:33 |
| GyrosGeier | virtual terminal | 14:33 |
| GyrosGeier | X11 uses tty7 by default | 14:34 |
| debdog | X11's VT? | 14:34 |
| GyrosGeier | yes | 14:34 |
| GyrosGeier | suspend switches from X11 to an empty text console | 14:34 |
| hyrcanus | we could use a multiple virtual framebuffer btw | 14:35 |
| GyrosGeier | so graphics card state is saved by X11 | 14:35 |
| hyrcanus | for high res monitors | 14:35 |
| hyrcanus | has anyone done this? | 14:35 |
| hyrcanus | e.g. 6 VTs displayed at once on hdmi out | 14:35 |
| debdog | no luck switching to (ctrl-)alt-F7 | 14:35 |
| debdog | like it's not there | 14:35 |
| GyrosGeier | the kernel switches back automatically on resume | 14:36 |
| GyrosGeier | graphics state belongs to the X server | 14:36 |
| debdog | ok, can I disable the kernel's interference? | 14:37 |
| GyrosGeier | that would likely make it worse | 14:37 |
| debdog | so I got back the behaviour like in ASCII? | 14:37 |
| GyrosGeier | the kernel only knows how to restore whatever state it set itself | 14:37 |
| debdog | hmm | 14:37 |
| GyrosGeier | either because X11 used kernel mode setting, or because it is a text console | 14:38 |
| GyrosGeier | that's why the VT switch is done: so X11 switches back to a mode the kernel understands well enough to restore it | 14:38 |
| GyrosGeier | I have a potential suspicion on what might cause X to terminate | 14:39 |
| GyrosGeier | there is a mechanism to lock the screen on lid close and/or suspend | 14:39 |
| debdog | ok, from a diffenent point of view: I close the laptop's lid. /etc/acpi/events/lidbtn calls /etc/acpi/lid.sh | 14:40 |
| GyrosGeier | and locking screensavers often instruct X to shut down if they close automatically | 14:40 |
| GyrosGeier | so maybe the screen locking is broken | 14:40 |
| GyrosGeier | yes, lid.sh should try to lock the screen | 14:40 |
| GyrosGeier | not sure how | 14:41 |
| GyrosGeier | it just magically started working for me one day | 14:41 |
| debdog | /etc/acpi/lid.sh runs til line 13 then exits. meaning one of the functions CheckPolicy || HasDBusLogin1 returens TRUE. the functions are defined in /usr/share/acpi-support/power-funcs | 14:41 |
| debdog | and that's where I get stuck | 14:41 |
| debdog | meaning lid.sh exits before it executes any acpi related commands | 14:42 |
| debdog | so something else takes over control | 14:42 |
| debdog | this is only the case if X11 is running. in plain console it works as expected, acpi wise | 14:43 |
| debdog | now, that 'something' should™ be configureable somewhere | 14:43 |
| debdog | but first I have to know what said 'something' is. how do I do that? | 14:44 |
| GyrosGeier | these probably live in /usr/share/acpi-support/policy-funcs | 14:44 |
| debdog | these what? | 14:45 |
| debdog | these functions? | 14:45 |
| GyrosGeier | CheckPolicy and HasDBusLogin1 | 14:45 |
| debdog | right, my bad. I meant policy-funcs | 14:45 |
| debdog | sorry, kind of confused (and a tad angry) atm | 14:45 |
| GyrosGeier | CheckPolicy looks if some program is running that is known to want to override default behaviour | 14:46 |
| GyrosGeier | like, if you run xfce, then pressing the power button brings up a menu | 14:46 |
| GyrosGeier | hmm | 14:47 |
| GyrosGeier | it seems HasDBusLogin1 got renamed to HasLogindAndSystemd1Manager | 14:47 |
| debdog | aptitude search power | grep ^i | 14:48 |
| GyrosGeier | that is the other case when acpi shouldn't default to shutdown: if there is an attachment point for power policies through dbus | 14:48 |
| debdog | only returns fdpowermon powermgmt-base powertop. | 14:48 |
| debdog | so most likely non of the progs mentioned in CheckPolicy is installed | 14:49 |
| GyrosGeier | so that returns false | 14:49 |
| GyrosGeier | and it tries HasDBusLogin1 | 14:49 |
| GyrosGeier | and likely that got renamed | 14:49 |
| debdog | right, I've searched on the debian side for help but they completely rely on systemd for these tasks. so I thought this prolly is a Devuan issue | 14:50 |
| debdog | renamed... | 14:51 |
| GyrosGeier | Debian also uses lid.sh (or policy-funcs) to delegate to systemd | 14:51 |
| GyrosGeier | so no systemd -> no delegation | 14:51 |
| GyrosGeier | the library function is in a file below /usr | 14:51 |
| GyrosGeier | so it got updated at some point | 14:51 |
| GyrosGeier | breaking existing scripts such as yours | 14:51 |
| debdog | ok, now I am totally lost | 14:53 |
| debdog | /usr/share/acpi-support/policy-funcs line 49: HasDBusLogin1() { | 14:54 |
| debdog | so the funtion is there | 14:54 |
| debdog | and it sends a dbus command thingy | 14:54 |
| GyrosGeier | that should fail too | 14:55 |
| GyrosGeier | unless you have dbus | 14:55 |
| GyrosGeier | (which you likely have in the form of dbus-x11 | 14:55 |
| GyrosGeier | ) | 14:55 |
| debdog | so, I have to learn dbus to prevent the laptop to do anything if the lid is closed | 14:55 |
| GyrosGeier | nah | 14:56 |
| debdog | yes, dbus-X11 is installed (removing it would cause too many progs to be removed along) | 14:56 |
| GyrosGeier | just put "exit" at the top of lid.sh | 14:56 |
| GyrosGeier | (well, below the #!) | 14:56 |
| GyrosGeier | then, nothing will happen | 14:56 |
| debdog | hmm, I think that was the first thing I've tried a couple of days back. if memory serves (sorry, I am also a tad sickly and brain is not working at high capacity) | 14:57 |
| debdog | but let me do it again, just to be certain... | 14:58 |
| debdog | this will take some minutes (also need to make some tea...) | 14:58 |
| GyrosGeier | IIRC default for lid switch is to find any running X11 session and notify it that it should lock the screen | 14:59 |
| GyrosGeier | and then suspend | 14:59 |
| GyrosGeier | if nothing listens to notifications, I think it enters the session and starts xtrlock | 15:00 |
| debdog | ok, line 2 of lid.sh contains now 'exit'. here are the symptoms: TTY1: on lid close laptop suspends/hybenates or something. on lid open it resumes. | 15:12 |
| debdog | X11: on first lid close it does nothing (which is what I want) but on second lid close ist suspends/hybernates/something. on lid open it does not come back entirely (black screen, backlight on. ssh into the system is possible) | 15:12 |
| debdog | s/ist/it/ | 15:14 |
| GyrosGeier | hmm | 15:17 |
| debdog | dbus-monitor | 15:17 |
| debdog | signal time=1634735821.373462 sender=org.freedesktop.DBus -> destination=:1.0 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired | 15:17 |
| debdog | string ":1.0" | 15:17 |
| debdog | signal time=1634735821.373490 sender=org.freedesktop.DBus -> destination=:1.0 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost | 15:17 |
| debdog | string ":1.0" | 15:17 |
| debdog | will check dbus-monitor again after a reboot. mayhap these entries lead in the right direction? | 15:18 |
| debdog | nah, same entries as before. even without closing and opening the lid. | 15:20 |
| debdog | and that's where I am stuck for days now | 15:20 |
| debdog | at this point I am tempted to physically disable that lid button | 15:21 |
| GyrosGeier | the first lid close is special for me as well | 15:22 |
| GyrosGeier | because it disables my Wifi and Bluetooth with rfkill | 15:23 |
| debdog | interesting | 15:23 |
| GyrosGeier | so something definitely goes wrong there | 15:23 |
| GyrosGeier | hmm | 15:24 |
| GyrosGeier | is there some config for the lid button in /etc/acpi/events ? | 15:24 |
| debdog | GyrosGeier: yes, that was my starting point (and where I have disabled suspend/something in ASCII | 15:28 |
| debdog | event=button[ /]lid | 15:28 |
| debdog | action=/etc/acpi/lid.sh | 15:28 |
| hyrcanus | this seems like something that should be easier to toggle/change | 15:28 |
| debdog | on ASCII I just commented the second line and then nothing happened on lid close | 15:28 |
| debdog | then, on Chimaera I altered it to action=/etc/acpi/fakelid.sh which only contained the shebang and and exit | 15:29 |
| debdog | exit/exit 0, none did the trick | 15:30 |
| debdog | hence my comment earlier "it's not acpi" | 15:30 |
| debdog | s/and and/and an/ | 15:31 |
| debdog | hehe, been try to paste the syslog of the testrun earlier on paste.debian.net and it returened: Could not add your entry to the paste database: do not spam" | 15:43 |
| buZz | debdog: yeah , it doesnt like email addresses ;) | 15:45 |
| buZz | debdog: maybe hastebin.com | 15:45 |
| Tenkawa | debdog: how big is the entry and which pastebin? some of those pastebins have small buffers and look for characer combos that can be used for buffer overflows | 15:45 |
| buZz | afaik they love spam | 15:45 |
| buZz | :D | 15:45 |
| buZz | Tenkawa: nah, paste.debian just doesnt allow email addresses | 15:46 |
| Tenkawa | buZz: that too | 15:46 |
| debdog | there it is (if it helps?): https://dpaste.org/ggji | 15:46 |
| Tenkawa | but yeah if he was using debian.net it usually allows anything | 15:46 |
| buZz | what are we looking for | 15:46 |
| buZz | pfffff | 15:47 |
| buZz | Oct 20 15:18:19 envy brltty[861]: select: Unterbrechung während des Betriebssystemaufrufs | 15:47 |
| buZz | learn english already, debdog :D | 15:47 |
| debdog | buZz: what takes over for lid close event if acpi is told to do nothing. | 15:47 |
| buZz | hw, probably | 15:48 |
| debdog | but it still does suspend/hybernate/or something | 15:48 |
| debdog | not hw. worked well on ASCII | 15:48 |
| buZz | so here? | 15:48 |
| buZz | Oct 20 15:08:21 envy kernel: [ 326.777871] Freezing user space processes ... (elapsed 0.001 seconds) done. | 15:48 |
| buZz | its doing suspend, yeah | 15:49 |
| debdog | *disabling it in /etc/acpi/events/lidbtn worked well on ASCII | 15:49 |
| debdog | but I don't want it to suspen or anything | 15:49 |
| debdog | . o O (is it really so uncommon these days to plug in a monitor, a mouse and keyboard, close the lid and then work on the laptop as if it were a desktop?) | 15:51 |
| Tenkawa | debdog: your lid switch "is" running acpi | 15:51 |
| Tenkawa | Oct 20 15:03:06 envy kernel: [ 12.165186] ACPI: Lid Switch [LID0] | 15:51 |
| debdog | cool | 15:51 |
| Tenkawa | need to read closer | 15:51 |
| buZz | yeah that event file edit doesnt stop ACPI running | 15:52 |
| buZz | i dont have any laptop here so cant check for you, sry | 15:52 |
| debdog | I am not in a hurry. been working on this for days now. please read the backlog so I don't have to explain it all over again. the paste was for GyrosGeier in case it helps him to conpare with his system. | 15:52 |
| Tenkawa | acpi events can be hard boiled into the kernel | 15:53 |
| buZz | debdog: how about you just add 'acpi=off' to kernel parameters ;) | 15:53 |
| buZz | hehe | 15:53 |
| Tenkawa | buZz: or minimally turn the one for lid off | 15:53 |
| buZz | is that a seperate kernel parameter | 15:53 |
| Tenkawa | he'd need to look that one up | 15:53 |
| buZz | ? | 15:53 |
| Tenkawa | yes | 15:53 |
| Tenkawa | let me see if I can find it | 15:54 |
| debdog | <Tenkawa> buZz: or minimally turn the one for lid off BUT HOW!?!?! | 15:54 |
| Tenkawa | found it.. just a sec | 15:54 |
| buZz | https://unix.stackexchange.com/questions/552406/how-to-make-linux-userland-applications-think-that-laptop-lid-is-always-open | 15:54 |
| buZz | check under 6 | 15:54 |
| Tenkawa | buZz: that wont help 1005 | 15:55 |
| Tenkawa | er % | 15:55 |
| Tenkawa | this will | 15:55 |
| buZz | i think debdog would be helped by 90% solutions aswell :P | 15:55 |
| Tenkawa | debdog: sudo find /etc -type f | xargs grep "HandleLidSwitch=" | 15:57 |
| Tenkawa | find which conf file has that on devuan | 15:57 |
| Tenkawa | I know which does in systemd based but not non-systemd | 15:57 |
| buZz | thats a systemd parameter | 15:58 |
| debdog | Tenkawa: /etc/elogind/logind.conf:#HandleLidSwitch=suspend | 15:58 |
| buZz | oh | 15:58 |
| Tenkawa | yep thats the one | 15:58 |
| Tenkawa | uncomment that | 15:58 |
| Tenkawa | and put igore | 15:58 |
| buZz | remove the comment and set to 'ignore' | 15:58 |
| buZz | yeah | 15:58 |
| Tenkawa | er ignore | 15:58 |
| Tenkawa | and reoot | 15:58 |
| Tenkawa | er reboot | 15:58 |
| Tenkawa | that "should" now ignore the switch | 15:59 |
| debdog | Tenkawa: a quick test suggests that this seems working. will report back if in the upcoming I discover any issue related | 16:07 |
| Tenkawa | debdog: cool.. good luck.. hopefully it does | 16:07 |
| buZz | \o~/ | 16:07 |
| buZz | #devuan strikes again | 16:08 |
| debdog | GyrosGeier: in case you're investigating the 1st and 2nd lid close discrepancy and I can be of any assistence feel free to ping me any time (though I will be off grid for two weeks starting sunday) | 16:09 |
| debdog | buZz: yah, my nerves | 16:09 |
| * buZz glues nerves down | 16:09 | |
| * Tenkawa has no nerves left | 16:09 | |
| buZz | zen buddhist? | 16:10 |
| Tenkawa | you couldn't be in the industry I was in for almost 30 yrs and have any lol | 16:10 |
| buZz | hehe | 16:10 |
| Tenkawa | buZz: no.. they were ripped out | 16:10 |
| * tr-amarsh04 had to look up the town of Tenkawa | 16:10 | |
| debdog | ok, now the second problem I've stumbled upon since switching to Chimaera: autocompletion is borked in certain cases. | 16:10 |
| buZz | tr-amarsh04: ah its a town | 16:10 |
| debdog | well, I need a snack first... | 16:10 |
| buZz | i read it like '10k uWu' | 16:11 |
| buZz | lol | 16:11 |
| Tenkawa | tr-amarsh04: no my reference is Akito Tenkawa | 16:11 |
| Tenkawa | try looking that one up | 16:11 |
| buZz | its a martian | 16:11 |
| buZz | family of that marvin the martian? | 16:11 |
| Tenkawa | buZz: from Nadesico indeed | 16:11 |
| Tenkawa | Martian Successor Nadesico | 16:12 |
| Tenkawa | depending on translation | 16:12 |
| buZz | i always try to consume media in original languages | 16:12 |
| Tenkawa | or Mobile Battleship Nadesico | 16:12 |
| buZz | so, Kidō Senkan Nadeshiko | 16:12 |
| tr-amarsh04 | Yes, I have the 8cm CD of "You get to burning" and have heard Yumi Matzuzawa sing it live | 16:13 |
| Tenkawa | buZz: same here but I don't have a Japanese keyboard | 16:13 |
| buZz | thats ok, they arent really unique | 16:13 |
| buZz | though my altgr international layout cant type ō either | 16:14 |
| * Tenkawa notes the shows are so different in the 90's and newer than the ones he watched in the 70's-80's | 16:14 | |
| * tr-amarsh04 just uses mozc for Japanese input | 16:27 | |
| * GyrosGeier uses a Japanese keyboard | 16:35 | |
| hyrcanus | is there a tl;dr resolution for not-making my laptop go to sleep when i close lid? | 16:46 |
| Tenkawa | hyrcanus: edit /etc/elogind/logind.conf:#HandleLidSwitch=suspend | 16:49 |
| Tenkawa | uncomment that | 16:49 |
| Tenkawa | change it to ignore | 16:49 |
| Tenkawa | uncomment the line | 16:50 |
| Tenkawa | reboot | 16:50 |
| Tenkawa | one person tested it succcessfully so far | 16:51 |
| debdog | *most likely successfully | 16:51 |
| hyrcanus | thanks Tenkawa | 16:53 |
| Tenkawa | np... hopefully that works | 16:54 |
| hyrcanus | dont have devuan on laptop to test | 16:56 |
| HumanG33k | hi | 17:09 |
| HumanG33k | i m the only the update broke apache mod php ? | 17:10 |
| Tenkawa | define "broke" | 17:14 |
| Tenkawa | you need to be a bit more descriptive than that | 17:15 |
| hyrcanus | do any of you have hacks to rebuild a .deb after making small changes? | 17:15 |
| hyrcanus | maybe removing | 17:16 |
| hyrcanus | dh_auto_clean --buildsystem=kf5 | 17:16 |
| hyrcanus | dh_clean | 17:16 |
| hyrcanus | so it doesn't rebuild everything? | 17:16 |
| gnarface | dpkg-buildpackage? | 17:17 |
| Tenkawa | hyrcanus: thats defined in the build command | 17:17 |
| Tenkawa | gnarface: exactly | 17:17 |
| hyrcanus | yes i'm using dpkg-buildpackage | 17:17 |
| hyrcanus | alias buildit="dpkg-buildpackage -rfakeroot -b -uc -us" | 17:18 |
| Tenkawa | -nc | 17:18 |
| hyrcanus | ty! | 17:18 |
| Tenkawa | -nc, --no-pre-clean | 17:19 |
| Tenkawa | Do not clean the source tree before building (long option | 17:19 |
| Tenkawa | since dpkg 1.18.8). Implies -b if nothing else has been | 17:19 |
| Tenkawa | selected among -F, -g, -G, -B, -A or -S. Implies -d with | 17:19 |
| Tenkawa | -S (since dpkg 1.18.0). | 17:19 |
| Tenkawa | I use it frequently | 17:19 |
| Tenkawa | heh | 17:20 |
| Tenkawa | saves a fair amount of rebuild time for small changes | 17:20 |
| hyrcanus | i launched a two hour build but there's other things to do in the meantime | 17:20 |
| * Tenkawa really likes having a build cluster for that exact reason | 17:21 | |
| HumanG33k | Tenkawa: broke as package see as broken 7.3 and new 7.4 install but php mod is not load | 17:22 |
| Tenkawa | won't install, load, or run? | 17:23 |
| HumanG33k | have to manualy purge 7.3 and a2emod 7.4 (and i do some step install, reintall on 7.4 mod to make work again ) | 17:23 |
| HumanG33k | 7.4 is install | 17:23 |
| Tenkawa | are you trying to install 7.4 from source or from apt? | 17:24 |
| HumanG33k | 7.3 is broken (not load anymore) | 17:24 |
| HumanG33k | i only use apt | 17:24 |
| HumanG33k | i follow chimaera upgrade steps | 17:24 |
| HumanG33k | i currently upgrade an other server i will see if works or not | 17:24 |
| * tr-amarsh04 uses aptitude except for packages that have to be manually installed via dpkg -i | 17:24 | |
| HumanG33k | aptitude not able to find a solution in resonable time | 17:25 |
| HumanG33k | (my current server is weak) | 17:25 |
| HumanG33k | also there is issue php-pgsql (or whatever is name is) was remove and i have to reinstall it | 17:26 |
| Tenkawa | I don't have a chimaera x86 box handy to recreate this.. this sounds like an upgrade issue to me | 17:26 |
| HumanG33k | it's an upgrade issue for sure | 17:27 |
| HumanG33k | thats for why i here | 17:27 |
| Tenkawa | no I mean as in not completely followed procedure | 17:27 |
| HumanG33k | me ? | 17:27 |
| Tenkawa | yes | 17:27 |
| HumanG33k | i do not see what step i can miss | 17:28 |
| HumanG33k | https://www.devuan.org/os/documentation/install-guides/chimaera/upgrade-to-chimaera | 17:28 |
| HumanG33k | and for me a work have to be done on that part : | 17:30 |
| HumanG33k | In the event of any package failures, fix the failed packages then start the upgrade again. | 17:30 |
| HumanG33k | root@devuan:~# apt-get -f install | 17:30 |
| HumanG33k | root@devuan:~# apt-get dist-upgrade | 17:30 |
| Tenkawa | ok.. I take back what I said. I already have a problem with their docs | 17:30 |
| Tenkawa | Modify sources.list to look like the one provided. Comment out all other lines. | 17:30 |
| Tenkawa | never do this | 17:30 |
| Tenkawa | not when you are doing a release upgrade especially | 17:31 |
| Tenkawa | you could quicky get yourself in trouble | 17:31 |
| Tenkawa | and not know it | 17:31 |
| Tenkawa | the "Comment out all other lines." being the key part I mean | 17:32 |
| Tenkawa | if someone installs things from another repo they have to be resolved first | 17:32 |
| HumanG33k | for now packages download (on the server i upgrade now) for the other one after my fix not issue services run fine | 17:33 |
| Tenkawa | apt-get -f install should only be used by those versed in apt too | 17:33 |
| HumanG33k | and for me the php-pgsql issue is just because mod php 7.4 failed | 17:33 |
| Tenkawa | HumanG33k: is apt failing or apache? | 17:34 |
| Tenkawa | (sorry my short term memory is shot) | 17:34 |
| HumanG33k | apt fail ==> broke php7.3 mod for apache | 17:42 |
| HumanG33k | so i guess apt fail after when need to auto activate php7.4 mod for apache (it's a symptom) | 17:43 |
| HumanG33k | i will come back after my current upgrade to present my result | 17:43 |
| Tenkawa | ok | 17:44 |
| carlos | so everyone here is is upgrading, cool | 17:50 |
| carlos | im upgrading too 😊 | 17:50 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!