| glats | &window close | 03:32 |
|---|---|---|
| glats | ups | 03:32 |
| DeeEff | Hey all | 03:38 |
| DeeEff | Firefox has had a bad weekend | 03:38 |
| DeeEff | wondering if ceres is going to see their new build anytime soon | 03:39 |
| fsmithred | it'll probably be a couple weeks before new mini isos can be made | 03:40 |
| DeeEff | specifically version 66.0.4 (right now ceres is on 66.0.1) :( | 03:40 |
| fsmithred | ceres? | 03:40 |
| fsmithred | oh, you're talking about ff versions | 03:40 |
| DeeEff | I mean, I'm on ceres, and wondering if I can apt-upgrade that package to 66.0.4 sometime soon | 03:40 |
| fsmithred | depends on debian's schedule on that. | 03:41 |
| DeeEff | ah, so we just forward that package from debian? | 03:41 |
| fsmithred | you can always get it from mozilla | 03:41 |
| fsmithred | yeah | 03:41 |
| DeeEff | well, I'd rather not have a local install, I like being able to upgrade whenever I can, and also so I don't forget later | 03:42 |
| fsmithred | like 95% of the packages | 03:42 |
| Unit193 | In the meantime you can just use Mozilla's hotfix, no? | 03:42 |
| fsmithred | yeah, it works | 03:42 |
| fsmithred | I'm using it | 03:42 |
| fsmithred | noscript is still working | 03:42 |
| DeeEff | No, the default firefox install in debian disables their tracking stuff by default | 03:43 |
| DeeEff | the studies box is greyed out | 03:43 |
| DeeEff | I can't turn it on. | 03:43 |
| fsmithred | xpinstall.signatures.required;false | 03:43 |
| fsmithred | about:config ^^^ | 03:44 |
| DeeEff | oh well dang | 03:44 |
| DeeEff | guess I need to set a reminder to re-enable this in like... two to three weeks? | 03:45 |
| DeeEff | thanks | 03:45 |
| DeeEff | I thought that was only in beta versions | 03:45 |
| fsmithred | yeah, good idea | 03:45 |
| DeeEff | not stable | 03:45 |
| furrywolf | it's come out yesterday that disabling studies in the config page, and how debian does it, firefox still phones home and does whatever mozilla tells it to do. specifically, their fix will still be applied even if on the debian build with studies disabled. | 03:45 |
| Unit193 | fsmithred: That's not the hotfix, the hotfix is https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi That's just a workaround that disables verification. | 03:45 |
| DeeEff | furrywolf: well yes, their fix is orthogonal to studies. They used studies as a quick way to deploy code. | 03:46 |
| furrywolf | "normandy" is still enabled even if you try to disable studies and the like, which phones home to mozilla with a bunch of information, and lets mozilla edit the browser's config (and other things). | 03:46 |
| DeeEff | Unit193: that's not the hotfix, but it does get me going until Debian updates their firefox package in sid | 03:46 |
| DeeEff | ¯\_(ツ)_/¯ | 03:47 |
| Unit193 | DeeEff: Why do you say it isn't the hotfix? FWIW, they've been uploaded, just need to build and dinstall. | 03:47 |
| DeeEff | sorry, I meant the xpinstall thing isn't the hotfix (agreeing with you) | 03:47 |
| DeeEff | but I also don't want to build / install a separate version of firefox, I'd rather use the package on apt. | 03:47 |
| Unit193 | Ah! I understand. The hotfix I linked is just an xpi/addon. | 03:48 |
| furrywolf | I wonder how many other ways firefox is phoning home even after you try disabling everything... | 03:48 |
| furrywolf | I should file a bug report with debian that they're disabling studies but not disabling normandy. | 03:53 |
| Unit193 | https://bugs.debian.org/928433 | 03:53 |
| furrywolf | someone beat me to it. :) | 03:54 |
| furrywolf | the best part is mozilla didn't tell anyone they did this, and it slipped through everyone's auditing. | 03:54 |
| Xenguy | Mozilla was alright taking a beating, and now because of this they're taking another beating | 04:18 |
| Xenguy | It seems to me FF just got hijacked by suits somewhere along the line | 04:20 |
| Xenguy | It certainly doesn't feel much like the pluckish browser that came along at the time and said we're out to build the best FOSS web browser ever | 04:22 |
| Xenguy | For awhile, they were great | 04:24 |
| Xenguy | But now, alas | 04:25 |
| slvr | Unit193: Did that bugfix close reason make any sense to you? I don't understand. | 05:57 |
| Unit193 | slvr: That the option in question is implicitly disabled by app.shield.optoutstudies.enabled and/or browser.onboarding.shieldstudy.enabled being false. | 06:06 |
| DocScrutinizer05 | I'm pretty late on this one... nevertheless: using CSS and/or HTML in email may cause massive risk to compromise crypto privacy/signature https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf https://github.com/RUB-NDS/Johnny-You-Are-Fired | 08:36 |
| clemens3 | morning, just upgraded from jessie to ascii | 11:49 |
| clemens3 | worked and rebooted | 11:49 |
| clemens3 | but now apt-get update gives hash mismatch error | 11:50 |
| clemens3 | hash sum mismatch.. tried country name de.deb.devuan.org in sources.list | 11:50 |
| xinomilo | probably mirror sync issue, try again in a while or switch mirror | 11:55 |
| clemens3 | hmm, ok | 11:55 |
| Evilham | hellooo | 11:58 |
| Evilham | clemens3: around? | 11:58 |
| clemens3 | re | 12:03 |
| clemens3 | Evilham: yes? | 12:03 |
| Evilham | hi hi | 12:03 |
| Evilham | so, question time! | 12:03 |
| Evilham | where are you located? | 12:03 |
| Evilham | are you using ascii? | 12:04 |
| clemens3 | Switzerland | 12:04 |
| clemens3 | i dist-upgrade to ascii from jessie | 12:04 |
| clemens3 | that seemed fine, then rebooted | 12:04 |
| clemens3 | used deb.devuan.org | 12:04 |
| Evilham | I see, yes, I managed to identify the issue now with my computer (as opposed to before at 4am with my phone :-p) | 12:05 |
| clemens3 | cool | 12:05 |
| Evilham | that's the good news, the bad news is that we are now waiting for replies :-p- | 12:05 |
| clemens3 | ok, problem identified.. then I am happy and wish good fixing.. waiting mode.. | 12:06 |
| Evilham | in any case, if you are in CH, you should totally use https://mirror.ungleich.ch/mirror/packages/devuan/merged as the base for your repo :-D they have a pretty good connection speed | 12:06 |
| clemens3 | i will, before I wasnt sure how to prefix.. now you showed me.. | 12:06 |
| Evilham | yeah, ideally you wouldn't have had to :-) | 12:07 |
| clemens3 | I adapted my sources.list to the mirror | 12:10 |
| clemens3 | you give an update when the situation change? | 12:11 |
| clemens3 | d | 12:11 |
| Evilham | sure thing, I can ping you here when that happens | 12:11 |
| clemens3 | super, thanks a lot!later | 12:12 |
| cosurgi | hi, did the devs abandom devuan, or everything will be okay? I love devuan, please don't kil it due to aprils' joke. | 12:32 |
| rrq | Evilham: I've had 'apt-get update' issue for 2 hours now. even from ungleich :( | 12:34 |
| fsmithred | cosurgi, devuan is not dead. Everything will be ok. | 12:34 |
| Evilham | Really? Shouldn't be the case | 12:37 |
| Evilham | rrq: will you be around in about 30 mins? | 12:37 |
| rrq | sure | 12:37 |
| Evilham | Good | 12:38 |
| cosurgi | fsmithred: thanks! | 13:06 |
| xinomilo | used devuan tor mirror, new firefox with fix, is in. | 14:29 |
| clemens3 | any update? or is there a workaround? I have a production server in limbo.. | 14:36 |
| Evilham | clemens3: it's fixed | 15:55 |
| Evilham | propagating now | 15:55 |
| Evilham | if you need it very urgently, use pkgmaster.devuan.org | 15:55 |
| Evilham | within the next couple hours everything should be up-to-date | 15:56 |
| fsmithred | Evilham, I must have started my upgrade two seconds after it was ready, because it just completed successfully. | 15:58 |
| Evilham | it's been fixed for shy over 30 mins now | 15:59 |
| fsmithred | ah, ok. | 16:01 |
| clemens3 | ok, thanks , will check now.. | 16:05 |
| clemens3 | error is gone, super.. thanks a lot! | 16:11 |
| Evilham | thank you for helping with the debugging :-p | 16:14 |
| fsmithred | xinomilo, what version of firefox-esr do you have now? | 16:18 |
| slvr | I asked a while ago about packaging icecat for devuan. I'm willing to do the work but I don't know the build system for the repos. any hints? | 16:47 |
| clemens3 | as some feedback.. I had set a trap for myself, there was some age old setup to prevent systemd on a pre jessie debian setup.. still living in the background.. my fault, then openssh-server update was not done properly and myeself locked out.. but could only find it after the apt-get updated worked again.. | 16:49 |
| fsmithred | slvr, you could start with importing the source to git.devuan.org | 16:53 |
| fsmithred | best if you can clone an existing repo that has the history | 16:53 |
| fsmithred | clone/fork I'm not sure which | 16:54 |
| fsmithred | get it working and people can test it | 16:55 |
| Evilham | fix is (almost) fully propagated \o/ | 16:55 |
| fsmithred | cool, thanks | 16:55 |
| slvr | fsmithred: the git tree from gnu only contains a script to pull firefox from mercurial, modify, then build it. | 17:05 |
| fsmithred | slvr, that might work. I know of one other package we pulled from mercurial | 17:06 |
| slvr | I would think the newly generated icecat code would be what needs to be checked in | 17:06 |
| fsmithred | yeah, that would be best | 17:06 |
| fsmithred | you can't find that? | 17:07 |
| slvr | I have it on my workstation, but I'd think we would generate a new one to package. | 17:07 |
| slvr | maybe modify all the sed and file move operations to be tracked in git. | 17:08 |
| fsmithred | the newest source package I'm seeing is from november | 17:12 |
| fsmithred | is there anything newer? | 17:12 |
| slvr | no, ff 60 esr is current | 17:14 |
| slvr | looks like a new ff esr from mozilla is due in july | 17:15 |
| fsmithred | have you built it locally yet? | 17:16 |
| slvr | I have. Currently working on reproducing that build on a fresh system. | 17:17 |
| Evilham | the last mirror that was out of sync finished about 1h ago | 20:54 |
| Evilham | so, deb.devuan.org is fully back to normal | 20:55 |
| g4570n | 👍 | 21:31 |
| flrn | Hello! | 21:47 |
| flrn | I hope for some hints on my ascii desktop stalling at boot for some (varying) seconds when loading the "initial ramdisk". | 21:50 |
| flrn | this phenomenon is quite new (some weeks) | 21:51 |
| flrn | I am not aware of any changes besides the usual updating | 21:51 |
| flrn | no SSD involved, legacy BIOS (this machine does not have UEFI) | 21:52 |
| flrn | I am a bit afraid that it might be a weak capacitor?! | 21:53 |
| gnarface | flrn: check in /etc/default/grub to see if you still have "quiet" in the kernel command-line options. if so, remove it, then you should more accurately be able to see what is stalling | 21:54 |
| flrn | gnarface: yes it's quieted, thanks I'll fix and reboot... | 21:55 |
| flrn | gnarface: the reboot went blazingly fast now | 21:58 |
| gnarface | flrn: well, there should be a lot more text so there would be an illusion of it being faster even if it's not | 21:58 |
| flrn | will do a full shutdown now, to test if it happens only on a fully discharged system | 21:59 |
| gnarface | yea a cold boot might make a difference | 21:59 |
| gnarface | but it could be a networking issue too | 21:59 |
| flrn | network at this stage? | 21:59 |
| gnarface | sure. if your /etc/hosts doesn't properly define localhost and at some point one of those regular updates pulled in a MTA you didn't have before (which would be expected behavior in many cases) then a simple delay in response from your DNS or DHCP server (typically your plastic toy home router) could trigger up to a 60 second timeout | 22:01 |
| gnarface | that's just an example | 22:01 |
| gnarface | but i had you remove "quiet" in the hope that we could be sure | 22:01 |
| gnarface | since whatever is stalling, usually happens right after the last line of text before the hang | 22:02 |
| gnarface | if it's not reliably reproducible still, unfortunately that is not helpful information. you gotta first find a way to trigger the delay reliably. if the harddrive is going bad enough to trigger noticable startup delays, i'd expect smartmontools to be able to show you some other early warning signs of failure | 22:04 |
| gnarface | if nothing, absolutely nothing in the install or the hardware itself seems to be possibly the culprit, but you are using DHCP, then the DHCP server is a very likely culprit | 22:05 |
| gnarface | (statistically followed by DNS configuration, if those two things aren't coming from the same place, but note that /etc/hosts properly set up should mitigate both issues) | 22:06 |
| gnarface | usually bad capacitors cause stability issues, not performance issues | 22:07 |
| furrywolf | if only we had a more modern init system that would do everything in parallel so it wouldn't stall... :P | 22:07 |
| * furrywolf hides | 22:07 | |
| bleb | anyone notice that keyboard shortcuts dont work in libreoffice impress? | 22:08 |
| gnarface | furrywolf: it does actually do everything in parallel that it can, but a bunch of network daemons, once installed, are considered dependencies of other stuff, and can hang on network configuration or connectivity issues. (this is a big reason i strongly favor static network configurations, actually) | 22:08 |
| bleb | this is a relatively fresh ascii install, just trying ctrl+z and it's not undoing, but selecting it from the menu works | 22:08 |
| gnarface | i never touched it bleb, sorry, can't say. | 22:09 |
| gnarface | it's only in impress? not the other libreoffice suit tools? | 22:09 |
| gnarface | suite* | 22:09 |
| furrywolf | bleb: I've never used impress. | 22:10 |
| gnarface | bleb: i do notice there's libreoffice in ascii-backports, just fyi. | 22:10 |
| flrn | gnarface: oh, MTA triggers something... but the system does not hang noticeable anymore since I removed the "quiet" option | 22:13 |
| gnarface | flrn: that's really weird. all i can advise is to keep observing it to see if you notice anything new the next time there's a delay. | 22:15 |
| gnarface | a long time ago (pre-4.x kernels) i had a strange boot bug where the output text would halt until i pressed a key | 22:16 |
| gnarface | it wasn't supposed to be doing that | 22:16 |
| gnarface | and all the king's horses and all the king's men couldn't figure out what was up | 22:17 |
| gnarface | i later traced it to unexpected behavior from some bios powersaving setting that wasn't working right | 22:17 |
| gnarface | that's a really rare type of issue though. usually intermittent startup delays are caused by the network. | 22:18 |
| gnarface | so what i'm saying basically is that it's highly unlikely that just removing "quiet" would fix the startup delay in and of itself. i wouldn't rule it out completely, but i would leave that conclusion for the very last. | 22:20 |
| gnarface | once, i put a modern wpa2 enabled wifi dongle in a old P-II laptop and discovered that the longest the DHCP server would wait was within microseconds of the fastest the machine could respond (running wpasupplicant) which would lead to a long delay followed by failure to negotiate a network connection, just about 9 out of 10 tries | 22:26 |
| furrywolf | heh, my irc client often doesn't notice the network has dropped until I press a key. | 22:26 |
| gnarface | then once it got it, it would cache the response somehow, and it wouldn't be a problem again unless the laptop was powered off for a few hours | 22:26 |
| gnarface | but in the end it seemed to be unique to the DHCP server (another plastic toy issued by the ISP) and not something that could be adjusted with any supplied configuration options at either end | 22:28 |
| furrywolf | yeah, that seems like a pretty broken dhcp server | 22:28 |
| gnarface | yea they're supposed to wait 60s too, but it clearly wasn't doing that. | 22:29 |
| gnarface | the issue was hard to diagnose by reading forum reports about it though, because people with faster machines were not experiencing the failure nearly as often | 22:29 |
| gnarface | in fact, it took me a real long time to figure out that it would work if i just kept trying | 22:30 |
| furrywolf | I probably would have just jumped to "this dhcp server is broken, use something else" without tracking down why. | 22:32 |
| flrn | gnarface: the delay happens long before any NICs are brought up. | 22:35 |
| gnarface | flrn: interesting, though that may actually be the cause, if something is coming up early that needs the network. does it always stall on the same line of text? | 22:36 |
| gnarface | flrn: also, is it a laptop? | 22:37 |
| gnarface | (laptop bioses might have powersaving features enabled for spinning-platter harddrives that can cause some delay while they "wake up") | 22:38 |
| furrywolf | heh, how about a feature to preheat hard drives before booting? :) | 22:39 |
| gnarface | like an oil pan heater on a car? | 22:39 |
| furrywolf | yep | 22:39 |
| gnarface | heh, might actually be useful in some environments... | 22:39 |
| furrywolf | my toughbooks have hard drive heaters... I've never turned that feature on, however. | 22:39 |
| gnarface | for real? i didn't know that was a thing | 22:40 |
| flrn | when I "unquiet" grub, there is no noticeable delay. "quiet" the delay happens right after the "loading initial ramdisk" line. | 22:40 |
| flrn | but I got an old error message back: ata[1-4] soft reset failed. there are no p-ata disks in that system and IIRC it is even disabled in the BIOS. | 22:41 |
| furrywolf | gnarface: https://d3inagkmqs1m6q.cloudfront.net/2188/media-photos/pcdd2613-genuine-hard-drive-caddy-tray-panasonic-toughbook-cf-19-free2-3day-ship-mk1-mk6-2.jpeg it's a resistive heater element sheet that wraps around the drive | 22:42 |
| gnarface | flrn: *that* is interesting. if you're sure that is the case, you could try just blacklisting that driver in the kernel | 22:42 |
| flrn | "it" == the p-ata disks | 22:42 |
| gnarface | flrn: (i'd make sure you had a workable live image around just in case you're wrong though, so you have a way to turn it back on) | 22:43 |
| furrywolf | if you turn it on, it'll pre-heat the drive if it's below a certain temperature before spinning it up | 22:43 |
| gnarface | furrywolf: cool | 22:43 |
| furrywolf | "might actually be useful in some environments" describes many toughbook features. :) | 22:44 |
| flrn | gnarface: I have some grub-bootable isos on the boot partition -_- but IIUC, I'd need to do the blacklisting for the initramfs, no? | 22:45 |
| flrn | or is it really sufficient to create a blacklist.conf under /etc/modprobe.d? | 22:47 |
| flrn | it seems to be sufficient, https://wiki.debian.org/KernelModuleBlacklisting states: | 22:48 |
| flrn | 1. Create a file '/etc/modprobe.d/<modulename>.conf' containing 'blacklist <modulename>'. / 2. Run 'depmod -ae' as root / 3. Recreate your initrd with 'update-initramfs -u' | 22:49 |
| flrn | gnarface: I blacklisted ata_generic and pata_atiixp, but no change: still failing ata soft reset messages. | 22:59 |
| flrn | not sure, what else to blacklist | 22:59 |
| flrn | libata.force= works somewhat different than expected... but it has an effect (trying to recover now) | 23:33 |
| gnarface | flrn: sorry, stepped away for a bit there, but i have nothing to add now except that maybe you're right about bad capacitors after all. if there's a bad cap causing some intermittent failure of some ata bus handshake or something like that... i don't know for sure that it wouldn't behave like this. anyway, in theory disabling it in the bios *and* the kernel SHOULD quiet it. | 23:49 |
| gnarface | usually on a motherboard the sockets and the busses themselves are the last things to go, but i've still seen it happen. | 23:50 |
| gnarface | this type of behavior is more common in my experience with aging usb devices | 23:51 |
| gnarface | but theoretically i think any type of bus connection could fail in this way | 23:51 |
| gnarface | (dmesg exposing periodic reset warnings could be the smoking gun here) | 23:52 |
| gnarface | i'd google around for the warning messages and see if anyone else has seen them for this particular disk controller | 23:53 |
| gnarface | i'd also search to figure out for sure which kernel modules it's using to make sure they're the ones you blacklisted | 23:53 |
| gnarface | there are a dozen or two of of them | 23:54 |
| gnarface | and some overlap in compatibility | 23:54 |
| gnarface | (i.e., it's not supposed to happen anymore, but it isn't unheard of for it to load the wrong one after you've blacklisted the right one) | 23:54 |
| flrn | gnarface: I had to find out, that ata[1-4] are my sata devices, not the unused p-ata channels. I have also updated the jessie-netinst on my boot partition to ascii now -_- | 23:56 |
| gnarface | ah i see. that was a possibility that occurred to me. | 23:57 |
| gnarface | i have no way to conclude whether it is a hardware or software issue | 23:58 |
| gnarface | if you disable unused SATA ports, it might still improve boot time, but i wouldn't really expect the delays related to that to occur after grub | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
