patrickr | Thank you gnarface! | 00:28 |
---|---|---|
gnarface | patrickr: no problem | 04:15 |
gnarface | minnesotags: i feel your pain... that might be a legit bug in the init scripts or driver. maybe something to do with the driver not bringing the hardware up quickly enough for the first init pass... | 04:16 |
gnarface | the fact it works for most people suggests there's fringe behavior in your case... i'm curious if that fix helps anyone else on other laptop models | 04:17 |
patrickr | gnar: it *appears* to be working after a resize, but I'm having weird hangs and crashes; fsck -f give the all clear | 04:19 |
patrickr | related or not you think? | 04:20 |
gnarface | since the bug in question happens with fsck too, not just resize, chances are it's the same bug | 04:20 |
gnarface | sorry, i should have mentioned that | 04:20 |
gnarface | basically if you use e2fsprogs from ascii or later on any ext4 filesystem formatted with an earlier version of the tools, it corrupts the journal instantly and irreparably, but the actual symptoms of the filesystem unravelling may take days or weeks to actually appear | 04:22 |
gnarface | how long depends on the type of i/o traffic probably, and the type of storage media | 04:22 |
gnarface | but i don't even know that much for sure, it's based on casual observation | 04:22 |
patrickr | a perfect storm | 04:23 |
gnarface | no, the part that makes it a perfect storm is that the ext* programmers are trying to bury this mistake out of shame | 04:23 |
gnarface | they should have put a warning label on it | 04:23 |
gnarface | i believe some of the devuan ARM images for jessie may have a patched version of the e2fsprogs shipped with them to mitigate this disaster for devuan | 04:25 |
gnarface | but that won't save anyone who is upgrading from debian | 04:25 |
gnarface | (or raspbian) | 04:25 |
patrickr | ok, i'll have to build an ascii image from scratch then, using a stretch box i've got | 04:26 |
gnarface | to be perfectly honest though, it could also be a problem with the SD card | 04:26 |
gnarface | there's no way for me to distinguish, based only on the anecdotal evidence | 04:26 |
gnarface | if you use a different filesystem entirely and then it STILL fails though, then you know for sure | 04:26 |
gnarface | if you're trying to make it happen faster, my best guess on how would be to write and delete a lot of files to it | 04:27 |
gnarface | i don't think it will matter what, as long as it takes up a lot of space | 04:27 |
patrickr | seems to happen when I apt install | 04:27 |
gnarface | yea, that's why i ditched raspbian too | 04:28 |
patrickr | but there could be some weirdness happening with the kernel too | 04:29 |
patrickr | because it also seems to be connected with x running -- then again there's probably more files being used then as well | 04:31 |
patrickr | i'll let you know how things work out later this week | 04:35 |
minnesotags | gnarface: I really can't say about other people's sound experience. These toughbooks are kind of a unique case. I had thought it was a driver, or pulseaudio thing, but I saw about just running the init, tried that and had success. Rebooted, didn't work until I ran alsa-utils init, so I added it so it ran at the end. Success! | 06:10 |
grillon | hi gnarface, seems you met another sdcard corruption case | 07:10 |
gnarface | yes grillon but it's not clear whether his situation is based on hardware failure too or not. is the second card still fine for you? | 07:48 |
gnarface | minnesotags: you should bring that up in #alsa... that's a really weird bug but seems like it should be simple to fix if all it takes is a second run of the alsa-utils init script | 07:49 |
gnarface | minnesotags: you're sure it gets run once during boot up already though, right? maybe it's getting run too early, like before the audio module is even loaded? | 07:50 |
gnarface | it shouldn't be different for you but like i said... race conditions are possible... | 07:50 |
gnarface | (i've seen weirder stuff happen) | 07:50 |
gnarface | i'm wondering if some strange corner case is causing it to error out the first time | 07:54 |
gnarface | i've seen some weird stuff | 07:54 |
gnarface | once i saw a bios power management setting expose a weird bug in the init scripts that made boot up halt after every text line unless i kept hitting enter | 07:55 |
xrogaan | how is it possible that debian source backport for a package is of a different version than the actual .deb? | 08:02 |
xrogaan | > https://packages.debian.org/stretch-backports/mate-settings-daemon != https://packages.debian.org/source/stretch-backports/mate-settings-daemon | 08:02 |
gnarface | backports always have "bpo" in their version strings, amongst other differences | 08:03 |
gnarface | the version has to be different or the package won't upgrade | 08:03 |
gnarface | it's a fundamental of the the way dpkg and apt work | 08:03 |
gnarface | package version priority is literally determined by string comparison of the version string | 08:03 |
gnarface | (unless overridden through pinning or manual intervention) | 08:04 |
gnarface | also, there's actually no mandate in Debian that the binary packages even have to be buildable from the accompanying source | 08:05 |
gnarface | there's no mandate they even have to be built on Debian | 08:05 |
gnarface | there's in fact no mandate the source package has to have a reproducable build | 08:05 |
gnarface | though, because of that, you can quickly evaluate the quality of software by the ones that do | 08:05 |
gnarface | i remember hearing a few years back that there was noise in Debian leadership about trying to encourage better enforcement of that but nobody seemed to want to go so far as to make it a requirement | 08:06 |
gnarface | (i too was shocked and dismayed to find out it hadn't been all along) | 08:06 |
xrogaan | well, the whole mate backport got update except for a few packages. | 08:09 |
gnarface | so yea, if you're trying to recreate a binary .deb from the accompanying source package and it doesn't seem possible, don't worry, you might not be crazy. it really may not work, and the binary package may be just a ball of duct-tape and unidentified skeletons | 08:09 |
xrogaan | settings daemon is one of them. The .deb is still the old version, but the source, as shown on their webpage, is the new one. | 08:09 |
xrogaan | (it actually slightly breaks mate) | 08:10 |
gnarface | what happens when you try to build it yourself? does it build? | 08:10 |
gnarface | sometimes this is just due to compiler glitches or multiarch dependency conflicts that haven't been resolved anywhere but outside the developer's own sandbox | 08:10 |
gnarface | sometimes you can get around those issues with messy hacks that allow the package to build but then break further upgrades to that system | 08:11 |
xrogaan | Might be the build system lagging too. | 08:12 |
xrogaan | yeah: https://buildd.debian.org/status/package.php?p=mate-settings-daemon&suite=stretch-backports | 08:12 |
gnarface | yea, or mirror update delay... | 08:12 |
xrogaan | there are stuff stuck in "installed" for more than a year. | 08:20 |
gnarface | hmmm, i wonder if those are packages that have devuan-specific patches to get around upstream systemd requirements? | 08:22 |
gnarface | i thought that whole mate package set was in fact such a thing, but i don't know | 08:22 |
gnarface | a bunch of packages dropped lm-sensors support in favor of something in systemd that apparently can't be replicated | 08:23 |
gnarface | that stuff is just basically taped up and sent in broken | 08:23 |
xrogaan | mate should be systemd free, I meant in the debian build tracker, there are some packages that are listen in there for more than a year. | 08:23 |
gnarface | oh, indeed | 08:23 |
gnarface | well this is all just speculation on my part, i don't know wtf is going on | 08:24 |
xrogaan | is there a build log for devuan? | 08:24 |
gnarface | good question, but i don't know | 08:24 |
gnarface | i assume there is one but i don't know if it's public | 08:24 |
gnarface | would it make sense for it to be in the gitlab? | 08:24 |
gnarface | devuan's private gitlab is at git.devuan.org | 08:24 |
xrogaan | should be this https://ci.devuan.org/view/All/builds | 08:25 |
xrogaan | oh sorry, I meant "uploaded" not "installed" | 08:27 |
golinux | Or this: https://git.devuan.org/devuan-packages | 08:27 |
xrogaan | I don't know what those are, the ci website show actual builds and failures. | 08:32 |
golinux | Sorry just now seeing the bit about the build log. | 08:35 |
Tetralet | Hi, I have a clean installed devuan beowulf amd64 system. I tried to install wine32-development package but failed. | 09:46 |
Tetralet | https://paste.ubuntu.com/p/T2Mtr3vPmS/ # It's install log | 09:46 |
Tetralet | Any idea? | 09:46 |
minnesotags | gnarface: I wonder what logs I would need to supply? | 09:53 |
gnarface | no idea, minnesotags | 09:54 |
minnesotags | yup. It's cool. just curious. | 09:54 |
gnarface | i think it's actually something to do with the contents of /usr/share/alsa | 09:58 |
gnarface | you could try checking it before and after that second alsa-utils run, but i wouldn't know how to spot something wrong with it | 09:59 |
Criggie | does anyone have xine installed successfully in devuan ascii ? | 11:31 |
Criggie | I think I had it installed from deb-multimedia.org but its vanished in an upgrade the other week | 11:31 |
KatolaZ | Criggie: it works over here | 11:43 |
KatolaZ | no need to use dmo any more | 11:43 |
Criggie | okay thats useful - thank you | 11:43 |
Criggie | hmmm bother - I still get dependency problems like " xine-ui : Depends: libxine2 (>= 1.2.0) but it is not going to be installed | 11:45 |
Criggie | hmmm - its got some deb-multimedia packages somewhere | 11:46 |
Criggie | libxine2-ffmpeg : Depends: libxine2-bin (= 1.2.6-1.3) but 1:1.2.9-dmo4 is to be installed | 11:46 |
gnarface | you might have to remove them all first | 11:46 |
KatolaZ | Criggie: you don't need dmo repos any more | 11:53 |
Criggie | gnarface: yep perfect thats worked. Its decided to add some i386 packages like libavutil55:i386 which seems odd... but the blocker was libxine2-bin:amd64 (1:1.2.9-dmo4) and perhaps libxine2-doc (1:1.2.9-dmo4) | 11:53 |
Criggie | KatolaZ: I was unaware of that till today. | 11:53 |
KatolaZ | :) | 11:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!