| nemo | hmmm still no linux 5.16 in sid | 00:22 |
|---|---|---|
| nemo | I thought for sure they'd bump https://packages.debian.org/fr/sid/linux-image-amd64 | 00:22 |
| nemo | (need it for the new laptop install) | 00:23 |
| nemo | huh. experimental hasn't been updated either | 00:23 |
| nemo | debian kernel team still on xmas vacation? | 00:24 |
| sabas3dgh1 | fsmithred: 🍯 | 00:44 |
| sabas3dgh1 | I made it work | 00:44 |
| fluffywolf | I have not fixed the problem with my laptop crashing when unplugging or plugging the AC adapter. I can't keep putting up with it. It started with the chimaera upgrade. I'm using the same bpo kernel. | 00:47 |
| fluffywolf | I'm going to need to downgrade to beowulf if I can't figure it out, because having a laptop that I can't unplug is not acceptable. | 00:47 |
| rwp | fluffywolf, What happens if you boot the Beowulf kernel? Does that avoid the crash? | 00:49 |
| fluffywolf | though "downgrade" is relative - beowulf worked better in every single way. | 00:49 |
| fluffywolf | I don't have other kernels. | 00:49 |
| fluffywolf | I've been using the 5.14 from bpo ever since it came out. | 00:50 |
| fluffywolf | and whatever the bpo one was before that one... | 00:50 |
| fluffywolf | 5.10? | 00:50 |
| gnarface | so, i gotta imagine this has to be something you can disable in acpid or the bios | 00:50 |
| fluffywolf | the one time I was able to reproduce it with me sitting at the laptop, it got slow like happens when you accidentally run a fork bomb, and took a few seconds to grind to a halt. | 00:51 |
| fluffywolf | the mouse pointer still moves, and indeed was still moving this morning, with the power turned off, but the laptop is unresponsive to anything else, including magic sysrq. | 00:52 |
| rwp | I agree that it does sound like an acpi trigger of some sort. | 00:53 |
| fluffywolf | every single thing acpi related has been broken since "upgrading" to chimaera. having the login manager handle acpi stuff is fucking retarded. | 00:53 |
| gnarface | fluffywolf: latest bios in the laptop? occasionally they fix acpi stuff. | 00:54 |
| rwp | (Full disclosure: I haven't updated my laptop yet. It's still running Beowulf. I need to figure out the connman conversion first and have been putting it off.) | 00:54 |
| fluffywolf | is there a way to completely kill elogind's acpi shit? I see absolutely no reason to have a login manager doing acpi. | 00:54 |
| sabas3dgh1 | fluffywolf: I just have the same thing .... only mouse movement .... | 00:54 |
| sabas3dgh1 | no keyboard though | 00:54 |
| fluffywolf | gnarface: the bios didn't become broken upgrading to chimaera. elogind, however, did. | 00:54 |
| rwp | It would seem like one should be able to synthesize acpi events and thereby hopefully trigger the event. And by that path be able to debug it. | 00:55 |
| fluffywolf | sabas3dgh1: on acpi events? | 00:55 |
| gnarface | fluffywolf: do you need the graphical login manager at all? my first idea is to just uninstall it along with elogind | 00:55 |
| sabas3dgh1 | fluffywolf: no event. just got stuck. it is laptop and it is connected to power supply | 00:55 |
| fluffywolf | I have no evidence elogind is the source of the problem, but it's been the source of other power management problems. | 00:55 |
| fluffywolf | hrmm, I wasn't able to remove elogind because it broke other things, but I'll try again. | 00:56 |
| fluffywolf | yeah, it still removes all kde-related things trying to uninstall it, including ktorrent, which despite starting with a k, really is the most-functional bittorrent client. | 00:56 |
| gnarface | fluffywolf: it could be literally just the login manager itself's default xorg configuration environment, which you can change by editing scripts in /etc/X11/ somewhere i think, but it has been a long time since i bothered trying to make it behave instead of just pitching it overboard | 00:57 |
| gnarface | fluffywolf: oh hmm. i'm not using kde. that might be a actual barrier, or it might just be one of those things you can reinstall it without afterwards if you specify --no-install-recommends | 00:59 |
| rwp | On my laptop I run a bare bones X system and I don't have elogind installed. Nor lightdm/slim. I think it was lightdm at the time that forced the issue. | 00:59 |
| fluffywolf | aptitude is brain damaged in some way that it can't be used to remove elogind, due to some multi-arch issue, in that it thinks it needs to install elogind:i386 and switches between them... | 00:59 |
| fluffywolf | I don't run kde either, but I do use ktorrent. | 00:59 |
| rwp | So now I am old-school once again logging into the Linux vt console and then running xinit to launch things. | 00:59 |
| gnarface | fluffywolf: i think you're supposed to be able to edit /etc/X11/Xsession.options but i vaguely recall having to do something like this a long time ago and realizing i had to edit an actual shell script associated with it that wasn't meant to be edited. then it got replaced a few times during upgrades, then i pitched it overboard. | 01:00 |
| fluffywolf | to do what? | 01:01 |
| gnarface | fluffywolf: i think it might obey /etc/X11/xorg.conf if you restart but not sure anymore | 01:01 |
| rrq | fluffywolf: I missed the start of this issue but maybe editing /etc/elogind/logind.conf could help | 01:02 |
| fluffywolf | I mean, what are you trying to have me do? | 01:02 |
| gnarface | fluffywolf: i don't remember exactly, this was a long time ago but it was a xorg stability issue caused by the login manager's misbehavior which (which was now-discontinued "entrance") and xorg/enlightenment would inherit the misbehavior unless you patched it or removed it entirely | 01:03 |
| fluffywolf | rrq: I already turned everything off because it kept randomly hibernatng my laptop! by default! seriously, the default config is to fucking turn people's computers off without asking and without them ever configuring any such thing. | 01:03 |
| fluffywolf | automatic hibernation should absolutely not under any circumstances be enabled by default. | 01:03 |
| rrq | +1 | 01:04 |
| gnarface | fluffywolf: sorry i didn't have a specific change to advise, i was just trying to point you in the direction of where i thought it was happening | 01:04 |
| fluffywolf | but, since last I checked you still can't fucking file a bug without setting up local mail, I'm still not filing any bugs. | 01:04 |
| fluffywolf | expecting users to have working local mail in 2022 is just plain stupid. | 01:04 |
| fluffywolf | I mean, more than half of people don't know the difference between email and gmail... | 01:04 |
| rrq | eh? lodging a bug is just to send an email (don't need MTA for that) | 01:07 |
| fluffywolf | ktorrent seems to have a hard dependency on elogind somwhere in the chain. | 01:07 |
| fluffywolf | reportbug does not provide any useful way to function without a working local mta with a smarthost configured. | 01:07 |
| gnarface | very annoying. i wonder if it really needs it or if it was included by mistake | 01:07 |
| fluffywolf | I was able to do it once by getting it to dump the unsent email, scping it to a server with mail, and manually feeding it into the mta there, but it was way too much work. | 01:08 |
| rrq | right, yes, reportbug is less useful nowadays... just an email with First line saying "Package: blah" and second saying "Version: boop" and the rest is random. | 01:09 |
| rrq | well, useful information is best | 01:09 |
| rrq | (and rants should be avoided :) | 01:10 |
| fluffywolf | reportbug really should send its email directly to a devuan mail server, rather than depending on a local mta. it's not like smtp is hard. | 01:10 |
| gnarface | well, it's really not, and to that point if the devuan bug report mail server will accept mail from bare ip addresses, you could submit the bug with netcat | 01:11 |
| fluffywolf | it should use some non-standard port to bypass isps that block 25. hell, many isps won't even let people run local mail servers anymore. | 01:11 |
| fluffywolf | (by blocking every standard port) | 01:12 |
| rrq | ueasy peasy: just clone https://git.devuan.org/devuan/reportbug and issue a merge request with the update | 01:12 |
| fluffywolf | and somehow I've now broken exfat-fuse trying to remove logind, since there's a dependency in there somewhere. | 01:13 |
| fluffywolf | elogind | 01:13 |
| fluffywolf | these dependencies are all a fucking unintelligible circular mess. | 01:15 |
| gnarface | i have fuse working here though without elogind | 01:15 |
| gnarface | is there something special about exfat with fuse? | 01:15 |
| gnarface | maybe exfat-fuse just need some other dependency of elogind but erroneously links to elogind directly instead? | 01:17 |
| gnarface | (or lazily) | 01:17 |
| fluffywolf | I think it just got pulled in by a recommends that got removed. | 01:17 |
| rrq | mmm also I think exfat-fuse used fuse2 and now it's fuse3, and exfat is in the kernel | 01:18 |
| fluffywolf | ok, manually traced the dependencies from ktorrent to elogind. ktorrent depends kio, depends libkf5authcore5, depends libpolkit-qt5-1-1, depends default-logind, which is a virtual package only provided by libpam-elogind, which depends elogind. | 01:20 |
| fluffywolf | they're all hard depends, no ors or other ways to avoid them. | 01:21 |
| fluffywolf | actually, there is an or, I can install logind instead of default-logind... but I bet you'll never guess what the only package providing logind is... | 01:22 |
| adhoc | fluffywolf: I assume you mean that is provided by systemd ? | 01:23 |
| fluffywolf | elogind, just like default-logind. | 01:23 |
| fluffywolf | heh. | 01:23 |
| fluffywolf | it seems like everything kde is hard dependent on elogind, with no other options to satisfy the dependencies. | 01:24 |
| adhoc | is that "e" as in enlightenment ? | 01:24 |
| fluffywolf | no. | 01:24 |
| adhoc | is that still a thing folks use ? | 01:24 |
| fluffywolf | everyone still uses something. lol | 01:24 |
| fluffywolf | or, rather, everything still has someone still using it, somewhere. | 01:25 |
| adhoc | do folks still use enlightenment ? | 01:25 |
| fluffywolf | but it's not related to elogind. | 01:25 |
| fluffywolf | elogind is an attempt at providing systemd functionality without the rest of systemd. it seems to be shit, from my experience. | 01:25 |
| adhoc | I see | 01:25 |
| rwp | Then it has accurately re-implemented the original systemd-logind. | 01:25 |
| adhoc | so what about login before systemd arrived on the scene? | 01:26 |
| fluffywolf | consolekit probably | 01:26 |
| fluffywolf | I'm not very familiar with that part of userland. | 01:26 |
| adhoc | it was init that started the sessions on the console ? | 01:26 |
| adhoc | and init that started some kind of x windows launcher thing | 01:27 |
| fluffywolf | init starts everything, somehow. lol | 01:27 |
| fluffywolf | I'm not even sure elogind is the cause of the crashes I'm having. | 01:27 |
| Xenguy | funny, init? =) | 01:27 |
| adhoc | i don't remember a logind before RHEL or in Debian | 01:27 |
| adhoc | Xenguy: only if you know folks south of the river | 01:28 |
| Xenguy | 8 -D | 01:28 |
| rwp | It's either consolekit or policykit. Before that there was a PAM plugin. But otherwise it is just groups. | 01:29 |
| rwp | The entire thing is just to provide console users with access permissions to run X and play audio. | 01:30 |
| gnarface | fluffywolf: which video driver did you say you were using again? | 01:30 |
| fluffywolf | googling says the word of god is that kde depends on systemd and anyone who thinks it should be otherwise can fuck off. | 01:30 |
| fluffywolf | radeon | 01:30 |
| adhoc | fluffywolf: good a reason as any to let kde die in a fire? | 01:30 |
| gnarface | fluffywolf: actual radeon or amdgpu? | 01:30 |
| Xenguy | Well maybe KDE should fuck off then? | 01:31 |
| rwp | I am using the free software in kernel main Radeon drivers and never had a problem with them. (Unlike the nouveau driver in recent times.) | 01:31 |
| fluffywolf | [ 42.969] (II) RADEON: Driver for ATI/AMD Radeon chipsets: | 01:32 |
| gnarface | fluffywolf: i think there was a range of ati/amd card models that could operate with either radeon or amdgpu, if yours is within that timeframe it might be worth trying the other, just because on nvidia hardware i've seen [problem tied mysteriously to hibernation/sleep], [problem tied to graphical login manageer], [problem with video drivers] coming in sets too many times | 01:33 |
| fluffywolf | this is an old laptop. | 01:33 |
| fluffywolf | 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Chelsea LP [Radeon HD 7730M] | 01:33 |
| fluffywolf | I don't think it's a video problem. | 01:33 |
| fluffywolf | it's clearly something fucking up handling the event of changing ac power state | 01:34 |
| gnarface | yea, like i said... with nvidia hardware it'd be a smoking gun. this, however is weird just because it's not nvidia hardware. | 01:34 |
| fluffywolf | it's not a hibernation/sleep problem. those actually work. the problem is crashing when the ac power adapter is either unplugged or plugged. it doesn't do it all the time, probably a race condition. | 01:35 |
| gnarface | yea but a race condition that has to be tied to power management, specifically something that auto-detects and changes states when you change the power source status | 01:36 |
| fluffywolf | any suggestions for how to remove elogind without removing ktorrent? | 01:36 |
| fluffywolf | there's no reason why ktorrent should depend on login management at all, other than that kde libraries are all massive blobs that depend on everything even if they never use it. | 01:36 |
| gnarface | nothing good. just rebuild the ktorrent package or try to make a elogind empty slug package, or just symlink the binary to /bin/false or /dev/null or something like that | 01:37 |
| fluffywolf | it's not ktorrent. it's kio that's pulling in absolutely everything that kio might ever talk to. | 01:37 |
| * fluffywolf installs equivs | 01:38 | |
| gnarface | fluffywolf: you have no xorg.conf currently, right? you're not defining any flags for the radon driver like AGPFastWrite or the like? | 01:39 |
| fluffywolf | correct. | 01:40 |
| fluffywolf | ok, fake-default-logind_99_all.deb now installed, let's see if anything still works after I reinstall everything else. :P | 01:41 |
| fluffywolf | (a dummy package that Provides: default-logind) | 01:42 |
| fluffywolf | well, ktorrent installed without elogind now... | 01:42 |
| gnarface | promising | 01:42 |
| fluffywolf | and runs! | 01:42 |
| fluffywolf | meh, rutracker is claiming the torrent I was downloading is no longer registered... but that's not ktorrent's fault. it's probably been repackaged with newer stuff. | 01:43 |
| fluffywolf | I probably should reboot before doing testing, and I'm not in the mood to do that now. | 01:43 |
| fluffywolf | ktorrent is literally the only kde program I use. | 01:44 |
| fluffywolf | so if it works, kde works. | 01:44 |
| Xenguy | fluffywolf, ktorrent is a GUI, yes? Or can it work on the CLI too? | 01:45 |
| fluffywolf | generally, every program starting with "k" is total shit... but ktorrent really is vastly more functional than any other torrent client. | 01:46 |
| fluffywolf | gui | 01:46 |
| fluffywolf | ktorrent is in many ways buggy shit, but it has more features. heh. | 01:46 |
| fluffywolf | for example, the move torrent function is missing a / somewhere in the path logic, so is entirely broken, since it tries creating, say, /home/wolfy/torrents/home/wolfy/torrents/torrentname... | 01:47 |
| Xenguy | This isn't a direct answer to your question, but have you considered qbittorrent (I have used ktorrent in the past also, but switched more recently) ? | 01:47 |
| fluffywolf | no | 01:47 |
| Xenguy | It's a FOSS knock-off of utorrent | 01:47 |
| Xenguy | Works pretty well for me | 01:47 |
| fluffywolf | I don't know anything about utorrent. | 01:48 |
| Xenguy | It's the main windoze torrent client I believe | 01:48 |
| fluffywolf | and I think I have ktorrent working without elogind. next step is to reboot and then try repeatedly plugging the power cable to see if it crashes. but I'm not in the mood to reboot now. | 01:48 |
| fluffywolf | having hard dependencies on elogind strikes me as being a bug, but I don't know if anyone is going to want to figure out how to fix that. | 01:51 |
| fluffywolf | it would be devuan that needs to fix it, since debian's answer is "install systemd", of course. | 01:51 |
| gnarface | on that one it's hard to say if it is a bug or just a profitability agenda | 01:51 |
| fluffywolf | I'm sure it's a devuan bug. :P | 01:52 |
| gnarface | heh, fair | 01:52 |
| fluffywolf | that is, requiring any part of systemd is a bug. | 01:52 |
| fluffywolf | but, there may be more useful things to spend developer time on. | 01:52 |
| fluffywolf | like making reportbug actually work. :P | 01:52 |
| fluffywolf | I mean, what percentage of users have a working local mta with smarthost configured? 5%? and the other 95% can't use it? | 01:53 |
| fluffywolf | many ISPs don't even provide smarthosts anymore, and expect you to use webmail. | 01:53 |
| fluffywolf | while they block every port you might want to use. | 01:53 |
| fluffywolf | googling doesn't find any evidence my ISP provides any way to get outgoing email to work. | 01:54 |
| fluffywolf | and I know they block port 25. | 01:54 |
| fluffywolf | if you try connecting to port 25 anywhere, they transparent proxy it to something that isn't actually a mta, and never reaches where you tried connecting to. | 01:55 |
| gnarface | i've changed isps over less | 01:55 |
| Hurgotron | your IP range will be on dynamic DNSBL lists anyway | 01:55 |
| fluffywolf | I use a non-standard port for thunderbird to send email to my mail server, since it couldn't reach port 25. heh. | 01:55 |
| Hurgotron | that should be 587. | 01:57 |
| fluffywolf | I could set up a local mta to smarthost to my mail server on a non-standard port, but... why? other than reportbug, I have never once wanted a local mta with outgoing mail capability in like two decades. | 01:58 |
| Hurgotron | 587 is standard for submission (client to server, authenticated). 25 ist standard for server to server. | 01:59 |
| fluffywolf | heh, looks like reportbug in unstable does smtp now. | 02:00 |
| fluffywolf | I guess I'm not the only one who has found this state of affairs ridiculous. | 02:00 |
| fluffywolf | however, according to the wiki, it still defaults to using a local mta, and requires annoying levels of manual configuration. | 02:01 |
| fluffywolf | it should default to sending straight to debian's or devuan's mail server. | 02:01 |
| Hurgotron | and hope that server doesn't deploy any of the common antispam features. Well, maybe you can whitelist somehow | 02:04 |
| fluffywolf | I would imagine whomever runs the mail server can set it up to accept all mail sent to submit@ that looks like a bug report... | 02:05 |
| Hurgotron | That's what I mean with whitelisting. But I wouldn't put it past spammers to send 100.000 spams looking like bug reports. | 02:06 |
| Hurgotron | I mean, spammers spam postmaster@ - yes, that will totally work. | 02:07 |
| Hurgotron | or even better, abuse@ | 02:07 |
| * joerg does the omicron dance. A new record | 06:32 | |
| joerg | oops sorry wrong chan | 06:33 |
| ibanja | apt-cache search kopete | 14:52 |
| ibanja | -- does not find kopete. My source.list: https://paste.debian.net/1226968/ | 14:52 |
| ibanja | I just upgraded to Chimaera | 14:54 |
| DPA | Seams right. It's not in debian (bullseye and later) anymore, so it's not in devuan chimaera either. | 15:29 |
| ibanja | DPA: do you know if it has a suggested replacement? | 15:34 |
| sgage | It's in Ubuntu. | 15:34 |
| ibanja | It seems to me it should be in Debian. | 15:36 |
| brocashelm | kopete is in experimental | 15:48 |
| brocashelm | 4:20.04.1-1 | 15:48 |
| fsmithred | in debian experimental | 15:49 |
| fsmithred | we don't merge that one | 15:49 |
| brocashelm | yeah | 15:49 |
| ibanja | OK... thanks | 16:32 |
| VanillaDjinn | 22:07 <VanillaDjinn> Hello. I booted into a minimal live ISO but I don't know the root password. Tried logging in as devuan but it seems that devuan is not in the sudo group. | 19:07 |
| bb|hcb | VanillaDjinn: Did you try password toor? | 19:15 |
| VanillaDjinn | Oh, thank you, kind sir. | 19:16 |
| VanillaDjinn | I was searching for it throughout the whole site. | 19:16 |
| onefang | Think it's toor, from memory. It'll be documented somewhere. | 19:19 |
| ibanja | does anyone know the command to move the current window to the next desktop/workspace. In LXDE "Shift + Alt + Left/Right" moved the current window to the left/right. I am trying to assign the hotkey to LXQT, but don't know the command. | 19:47 |
| VanillaDjinn | ibanja: You can ask on #lxqt. | 19:52 |
| ibanja | VanillaDjinn: good idea | 19:52 |
| VanillaDjinn | It's on OFTC though, not Libera Chat. | 19:53 |
| ibanja | OK... thanks | 19:53 |
| nemo | so... Chimæra only has postgresql-13 | 21:08 |
| nemo | we need older versions at work | 21:08 |
| nemo | (atlassian etc) | 21:08 |
| nemo | I assume we can just add bullseye repo from http://apt.postgresql.org/pub/repos/apt/ without too much trouble | 21:08 |
| nemo | (that was a question ☺ ) | 21:12 |
| fsmithred | sure, you can add another repo, but installing from it might cause big trouble. Look at the deps for postgresql-11 | 21:12 |
| fsmithred | wait, what? bullseye? | 21:13 |
| fsmithred | nemo, if you add a bullseye repo, won't you just get v. 13 same as chimaera? | 21:15 |
| fsmithred | you might need to forward-port the older version or install beowulf to get the older version from repo. | 21:20 |
| rwp | If you add beowulf you might be able to install the previous version, and then hold it to prevent it upgrading. But my personal preference would be a VM or a chroot running Beowulf. | 21:24 |
| nemo | fsmithred: postgresql maintains bullseye repo for 10 | 21:25 |
| nemo | fsmithred: but obviously they've never heard of devuan ☺ | 21:25 |
| rwp | When I look in Beowulf I find packages postgresql-11* there. Are you installing from Postgresql upstream repositoris? | 21:25 |
| nemo | rwp: yes. that's why I linked to the postgresql upstream repository 😉 | 21:26 |
| nemo | and the reason being, we need a quick and dirty atlassian instance, atlassian only supports postgresql 10, and my coworker wanted to use his devuan for that | 21:26 |
| nemo | naturally postgresql has not heard of devuan. | 21:26 |
| nemo | the main atlassian servers at work are ubuntu for historical reasons, although I probably would have used devuan if I'd had my druthers | 21:27 |
| rwp | Due to a long history of me fighting problems helping other people with Frankenstein systems it always sends shivers down my spine when I hear about people mixing and matching from various upstreams. | 21:28 |
| rwp | I would try to keep it in a container of some sort to keep it... contained! | 21:28 |
| nemo | rwp: yes. but do keep in mind *not* doing that pretty much means cutting devuan out of any major packages that maintain debian onyl repos | 21:29 |
| nemo | rwp: that said IMO the risk here is fairly low. postgresql is already multi-version packages | 21:29 |
| nemo | so /var/lib/postgresql/10 etc | 21:29 |
| nemo | aaand they are doing this entirely due to upstream's inclination to only support one latest stable. so they have some experience in reasonable scoping I think | 21:30 |
| nemo | I was mostly doublechecking on the bullseye thing.. | 21:30 |
| rwp | But my understanding is that the Debian/Devuan packages for Postgresql work very well. I don't think there is a need to go upstream for it. | 21:32 |
| rwp | I understand that your coworkers may not agree and may assume that closer to the source is better and do it anyway regardless. | 21:32 |
| rwp | So often people are just following recipe guides they found on the net somewhere and that's just the way of things. | 21:33 |
| nemo | rwp: I can 100% guarantee you postgresql 13 + atlassian fails | 21:34 |
| nemo | rwp: we tried. | 21:34 |
| nemo | not to mention. it's cots. | 21:34 |
| nemo | the last thing we need is to have this data import fail and the reason being "we went with unsupported configuration 'cause lol whatever" | 21:34 |
| rwp | I understand that 13 fails. And upstream is at 14 already. | 21:34 |
| nemo | https://confluence.atlassian.com/adminjiraserver/supported-platforms-938846830.html | 21:35 |
| rwp | But you said 11 would work. And so far all of the suggestions I read here have been to use 11 then. So...??? | 21:35 |
| nemo | 10, 11, 12 | 21:35 |
| nemo | rwp: you mean downgrading to beowulf | 21:35 |
| nemo | reason is fairly simple. he's trying to get it to work on his dev machine | 21:35 |
| rwp | Downgrading the postgresql packages. | 21:35 |
| nemo | oh. using the beowulf package with chimæra? | 21:36 |
| nemo | hm | 21:36 |
| rwp | And then marking them as hold so they don't upgrade. | 21:36 |
| nemo | that's a fair point | 21:36 |
| rwp | yes. | 21:36 |
| nemo | that's probably less likely to fail yes | 21:36 |
| rwp | That was my first suggestion! | 21:36 |
| nemo | ah. was not following at all. my apologies - I thought you'd suggested a container/vm | 21:37 |
| nemo | yeah. holding is fine. I've done some pretty nutty holds on devuan already just to get stuff working | 21:37 |
| rwp | I also suggested a container, chroot, vm too. That's probably what I would do. | 21:37 |
| nemo | like... X11 and kernel | 21:37 |
| nemo | yeah. we'd initially requested a clone of the standard cm config server (ubuntu) so this should not have been an issue | 21:37 |
| nemo | buuuuut that team is takign forever to get back to us | 21:37 |
| nemo | the joys of corporate environment | 21:38 |
| rwp | Basically it's recreating the same situation as if you had a working Beowulf system, held postgresql, then upgraded everything else that was not postgresql to Chimaera around it. | 21:38 |
| nemo | so not wanting to get blamed for import delays he decided to use what he had | 21:38 |
| nemo | chimæra personal machine | 21:38 |
| rwp | But instead since the system is already upgraded to Chimaera it would mean downgrading the collection of working Postgresql 11 packages. | 21:38 |
| nemo | hm? | 21:39 |
| rwp | Which would likely all need to go as a set, each with the specific version appended. | 21:39 |
| rwp | If you have a working Beowulf installation then it is easier to use it to determine exactly what packages and what specific versions of each are needed. Then install those. | 21:40 |
| nemo | aaanyway, it's probably not worth backing this out. AFAIK there's no devuan customisations for this package, so, eh, it's probably almost exactly same thing | 21:40 |
| nemo | rwp: yeah. we don't | 21:40 |
| nemo | they all got upgraded ☺ | 21:40 |
| nemo | I could set one up at home I suppose | 21:40 |
| rwp | For example "apt-get install postgresql-client-11= 11.14-0+deb10u1" selects that specific version of the client. | 21:40 |
| nemo | yeah | 21:40 |
| rwp | That's just the one. That will need to be accompanied by the entire set all at once, most likely. But I think it should work. | 21:41 |
| nemo | I dunno. I don't think it's worth undoing what he just did. Odds are the postgresql 11 maintained by the postgresql team is probably very very close to the one debian/devuan released in beowulf | 21:41 |
| rwp | Oh, no space after the = there. My typo pasting in the version string. But I wanted to give some example to clarify what I was trying to say. | 21:41 |
| nemo | but good point that pinning is a better choice | 21:41 |
| nemo | on plus side, he's just doing this on his dev VM with backups already in place ☺ | 21:42 |
| rwp | Pinning. You should also be able to accomplish the same thing using pinning. And then avoid the need to tediously drag those packages back to that version. | 21:42 |
| rwp | I'm just not very good with pinning and so wasn't thinking of it. But it is probably the better way to go. | 21:42 |
| nemo | yes... I actually had a reasonably functional system with an ascii kernel pinned due to stupid crapware antivirus they required me to have for a while | 21:43 |
| rwp | You mentioned setting up a system at home. Sure. But chroots set up with debootstrap go very easily and can be set up pretty much anywhere. Very useful for doing this type of package what exploration. | 21:43 |
| nemo | and then a similar WTF pin for getting my X11 ABI to work with AMD's upstream driver for a while until chimæra caught up ☺ | 21:44 |
| nemo | rwp: I mean... in order to identify the packages that need pinning. another option ofc is to pin postgresql, note failures, and keep adding pins until it works | 21:44 |
| nemo | rwp: and this is 'cause we have no more beowulf vms at work, and as mentioned, setting up VMs there is sooooo tedious | 21:44 |
| nemo | (bureaucracy wise) | 21:44 |
| rwp | That's why I was suggesting debootstrapping a Beowulf chroot. That's pretty straight forward. | 21:45 |
| nemo | mm never done that before, but I guess I could read a guide | 21:45 |
| rwp | Then chroot'ing into it to install postgresql and seeing what packages it uses. | 21:45 |
| rwp | https://wiki.debian.org/chroot | 21:45 |
| nemo | oh. ew. that thing | 21:45 |
| nemo | eh. it's done now. we'll tuck that away for later. maybe. ☺ | 21:46 |
| nemo | he just needs to get jira working to do this stupid dump | 21:46 |
| rwp | Ha! It still says that the ischroot but https://bugs.debian.org/685034 that *I* filed in 2012 is still a problem! Sigh. | 21:47 |
| nemo | basically they are trying to get data out of jira cloud and into jira data centre. because despite atlassian pushing hard to put everything in clouuuud it turns out it's a lot harder to integrate with corporate systems that way | 21:47 |
| nemo | so. now they are returning to the local network | 21:47 |
| nemo | and. it turns out. atlassian really really doesn't want you to leave their immensely lucrative cloud | 21:47 |
| nemo | so the export process is not nearly as clean as "generate dump file" - no you have to setup a standalone jira, then dump from that into the data centre. | 21:47 |
| nemo | so. once all this silliness is done, he will blow away /opt/atlassian and apt remove postgresql-11 ☺ | 21:48 |
| rwp | In that wiki doc the user setup is not important for your needs of just fishing. You can ignore that part from the wiki doc. | 21:48 |
| nemo | ah. 'cause that is a very long and convoluted wiki doc. | 21:49 |
| rwp | And I always ignore mounting /dev, /proc, /dev/pts, and accept that dpkg warns about it at every run. They aren't needed. | 21:49 |
| nemo | I kinda feel like installing qemu devuan would involve less commands | 21:49 |
| nemo | esp if I'm just booting the iso 😝 | 21:49 |
| rwp | Oh... it's not that bad. It just looks that way. :-) But I skip half of the things it mentions there most of the time. | 21:50 |
| rwp | You know how wiki docs get to be. They start out with just what is needed. Then over the years people keep adding corner case this and corner case that to them. | 21:50 |
| rwp | After a while they get to be full of cruft that isn't needed for the 90% middle case. | 21:50 |
| rwp | And so then someone starts a new wiki page. And the process then repeats all over again. | 21:51 |
| tk | Well, I think I am going to have to go with devuan (or debian) for the fact that it makes dealing with secure boot easier. | 22:55 |
| tk | as a note, if I use runit, and end up writing my own 1/2/3 scripts and service scripts (or just copying them from void), is there a major advantage to using devuan in that case? I guess it makes it easier to avoid accidental dependencies on systemd? | 22:58 |
| tk | hmm, at least even if there are no advantages, there are also no disadvantages AIUI | 22:58 |
| fsmithred | tk, devuan taps the debian repo, which is much bigger than void. | 22:59 |
| fsmithred | and yeah, devuan uses a condom. | 23:00 |
| tk | The repo size is not too much of a concern, my intent is to have a solid, stable, systemd-free linux base OS for my work laptop on top of which I can put other things. The basic requirements are FDE and SecureBoot (required by corporate policy) and support for VMWare Workstation Pro 16 (required to do my job) and I think devuan meets those (I tested it yesterday and was able to get FDE, SecureBoot | 23:05 |
| tk | and VMWare working all in a VM). Also I need to test out nvidia drivers (but that will have to wait for the real hardware test which I plan on performing in the coming weeks). On top of this base if I am missing packages I need I can just put a chroot of a different distro or use a VM (I already plan on putting together a simple containerisation tool for doing some of what I need to do for my | 23:05 |
| tk | work). | 23:05 |
| tk | The void repo size being small I have repeatedly worked around by simply expanding it :P | 23:05 |
| tk | But my concern with void is stability. | 23:05 |
| fsmithred | stability of the system or of the package versions? | 23:06 |
| tk | Currently that work laptop runs windows 10, and aside from the fact that it's not great having to constantly do everything from a VM (vmware has its quirks, especially surrounding clipboard handling and the folder sharing feature) it's incredibly unstable, constantly breaking and having issues. | 23:07 |
| fsmithred | I think you'll be happier with devuan | 23:07 |
| tk | Stability in terms of the system consistently working while continuing being secure. The fact that I can update debian without having to worry if I'll have to spend 2 hours troubleshooting some bizarre issue is a nice thing. | 23:08 |
| tk | but even with debian, running systemd scares me, I've had that be a source of instability before, and I have extensive experience running runit, and it's so dead simple that any issues are trivially solvable. | 23:08 |
| tk | in any case, I think that's settled, I'll do a proper hardware test next week or something | 23:09 |
| fsmithred | cool. | 23:09 |
| fsmithred | maybe I need to tap you for help. | 23:09 |
| fsmithred | main problem I have with runit is trying to reproduce the behavior of 'init 1' | 23:09 |
| fsmithred | I use that a lot for "almost a reboot" | 23:10 |
| tk | hmm, I think you can get mostly there by defining a runsvdir directory with just a single service for sulogin | 23:11 |
| tk | and then using runsvchdir to switch to it | 23:12 |
| fsmithred | oh, maybe I have too much running. | 23:12 |
| tk | once you do that, you log in and you can runsvchdir back to the previous one | 23:12 |
| fsmithred | yeah, that's what I tried | 23:12 |
| fsmithred | can't even remember what happened. It was months ago when I tried it. | 23:12 |
| tk | but also, for "almost a reboot" it might be easier (and more complete) to just use kexec | 23:12 |
| tk | you can kexec from the end of 3 (once you have established that you do indeed want to kexec which you can specify in some manner you like) | 23:13 |
| fsmithred | all I can find is pkexec | 23:14 |
| tk | kexec on void is the kexec-tools, not sure about debian | 23:14 |
| fsmithred | yeah, kexec-tools. I'm reading it now. | 23:15 |
| fsmithred | I can switch kernels without a full reboot? | 23:15 |
| tk | yes | 23:15 |
| tk | or you can just switch to the current kernel (i.e. re-execute it) and that's like a very fast full reboot | 23:15 |
| fsmithred | does that restart all services? | 23:16 |
| tk | https://github.com/void-linux/void-runit/blob/master/3#L52 | 23:16 |
| tk | yes | 23:16 |
| fsmithred | thanks | 23:17 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!