00:18.36 | *** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy) |
00:21.29 | *** join/#devuan amarsh04 (~amarsh04@ppp121-45-107-40.bras2.adl6.internode.on.net) |
00:28.52 | *** part/#devuan James1138 (~james1138@184.102.74.56) |
00:31.50 | *** join/#devuan pav5088 (~pav5088@n49-198-159-220.mrk1.qld.optusnet.com.au) |
01:04.45 | *** join/#devuan amarsh04 (~amarsh04@ppp121-45-107-40.bras2.adl6.internode.on.net) |
01:13.17 | *** join/#devuan guido_g (~guido_g@ip1f103f9c.dynamic.kabel-deutschland.de) |
01:32.50 | glats | &window close |
01:32.53 | glats | ups |
01:33.06 | *** part/#devuan glats (~Glats@li285-151.members.linode.com) |
01:37.57 | *** join/#devuan DeeEff (thatgeoguy@gateway/shell/matrix.org/x-tttjiqfivkfsnpin) |
01:38.08 | DeeEff | Hey all |
01:38.12 | DeeEff | Firefox has had a bad weekend |
01:38.28 | *** part/#devuan DeeEff (thatgeoguy@gateway/shell/matrix.org/x-tttjiqfivkfsnpin) |
01:39.24 | *** join/#devuan DeeEff (thatgeoguy@gateway/shell/matrix.org/x-tttjiqfivkfsnpin) |
01:39.38 | DeeEff | wondering if ceres is going to see their new build anytime soon |
01:40.11 | fsmithred | it'll probably be a couple weeks before new mini isos can be made |
01:40.21 | DeeEff | specifically version 66.0.4 (right now ceres is on 66.0.1) :( |
01:40.31 | fsmithred | ceres? |
01:40.51 | fsmithred | oh, you're talking about ff versions |
01:40.56 | DeeEff | I mean, I'm on ceres, and wondering if I can apt-upgrade that package to 66.0.4 sometime soon |
01:41.21 | fsmithred | depends on debian's schedule on that. |
01:41.34 | DeeEff | ah, so we just forward that package from debian? |
01:41.35 | fsmithred | you can always get it from mozilla |
01:41.39 | fsmithred | yeah |
01:42.01 | 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 |
01:42.02 | fsmithred | like 95% of the packages |
01:42.10 | Unit193 | In the meantime you can just use Mozilla's hotfix, no? |
01:42.22 | fsmithred | yeah, it works |
01:42.30 | fsmithred | I'm using it |
01:42.54 | fsmithred | noscript is still working |
01:43.14 | DeeEff | No, the default firefox install in debian disables their tracking stuff by default |
01:43.38 | DeeEff | the studies box is greyed out |
01:43.41 | DeeEff | I can't turn it on. |
01:43.59 | fsmithred | xpinstall.signatures.required;false |
01:44.18 | fsmithred | about:config ^^^ |
01:44.51 | DeeEff | oh well dang |
01:45.07 | DeeEff | guess I need to set a reminder to re-enable this in like... two to three weeks? |
01:45.08 | DeeEff | thanks |
01:45.16 | DeeEff | I thought that was only in beta versions |
01:45.16 | fsmithred | yeah, good idea |
01:45.17 | DeeEff | not stable |
01:45.19 | 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. |
01:45.59 | 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. |
01:46.08 | DeeEff | furrywolf: well yes, their fix is orthogonal to studies. They used studies as a quick way to deploy code. |
01:46.45 | 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). |
01:46.48 | DeeEff | Unit193: that's not the hotfix, but it does get me going until Debian updates their firefox package in sid |
01:47.07 | DeeEff | ¯\_(ã)_/¯ |
01:47.21 | Unit193 | DeeEff: Why do you say it isn't the hotfix? FWIW, they've been uploaded, just need to build and dinstall. |
01:47.41 | DeeEff | sorry, I meant the xpinstall thing isn't the hotfix (agreeing with you) |
01:47.59 | DeeEff | but I also don't want to build / install a separate version of firefox, I'd rather use the package on apt. |
01:48.24 | Unit193 | Ah! I understand. The hotfix I linked is just an xpi/addon. |
01:48.30 | furrywolf | I wonder how many other ways firefox is phoning home even after you try disabling everything... |
01:53.09 | furrywolf | I should file a bug report with debian that they're disabling studies but not disabling normandy. |
01:53.26 | Unit193 | https://bugs.debian.org/928433 |
01:54.32 | furrywolf | someone beat me to it. :) |
01:54.45 | furrywolf | the best part is mozilla didn't tell anyone they did this, and it slipped through everyone's auditing. |
02:16.05 | *** join/#devuan rdav_ (~rd@61.181.148.122.sta.dodo.net.au) |
02:18.56 | Xenguy | Mozilla was alright taking a beating, and now because of this they're taking another beating |
02:20.06 | Xenguy | It seems to me FF just got hijacked by suits somewhere along the line |
02:22.07 | 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 |
02:24.59 | Xenguy | For awhile, they were great |
02:25.07 | Xenguy | But now, alas |
02:30.57 | *** join/#devuan debdog (~debdog@2a00:79c0:666:5d00:7a24:afff:fe8a:d04d) |
02:47.31 | *** join/#devuan zeden (~user@unaffiliated/zeden) |
02:57.35 | *** join/#devuan KnoP (~andreas@p57B195B0.dip0.t-ipconnect.de) |
03:37.14 | *** join/#devuan amarsh04 (~amarsh04@ppp121-45-107-40.bras2.adl6.internode.on.net) |
03:43.30 | *** join/#devuan JohnDoe2 (~johndoe2@regex.ga) |
03:44.15 | *** join/#devuan panorain (~panorain@68.65.58.206) |
03:57.42 | slvr | Unit193: Did that bugfix close reason make any sense to you? I don't understand. |
04:01.36 | *** join/#devuan Stacker (~stacker@gateway/tor-sasl/b616) |
04:06.44 | Unit193 | slvr: That the option in question is implicitly disabled by app.shield.optoutstudies.enabled and/or browser.onboarding.shieldstudy.enabled being false. |
04:14.15 | *** join/#devuan pav5088_ (~pav5088@n49-198-159-220.mrk1.qld.optusnet.com.au) |
04:32.22 | *** join/#devuan Intensitea (SECdiNwYiz@panix5.panix.com) |
04:34.50 | *** join/#devuan Intensitea (SECdiNwYiz@unaffiliated/intensitea) |
04:43.11 | *** join/#devuan engidea (~damiano@176.206.200.212) |
05:00.42 | *** join/#devuan LtWorf (~LtWorf@mail.cryptzone.com) |
05:16.35 | *** join/#devuan LtWorf_ (~LtWorf@h-191-254.A890.priv.bahnhof.se) |
05:26.10 | *** join/#devuan Levure (~quassel@91.179.234.244) |
05:30.23 | *** join/#devuan AntoFox (~AntoFox@5.91.36.31) |
05:45.49 | *** join/#devuan mdrights (~user@209.250.232.119) |
05:49.13 | *** join/#devuan proteusguy (~proteusgu@223.27.212.175) |
06:36.29 | *** join/#devuan cyteen (~cyteen@cyteen42.plus.com) |
06:36.49 | 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 |
06:37.47 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
06:42.22 | *** join/#devuan hufdufhv1 (~Thunderbi@119.165.236.197) |
06:56.10 | *** join/#devuan puria (~puria@net-93-148-150-251.cust.vodafonedsl.it) |
07:04.53 | *** join/#devuan clemens3 (~clemens@mx.eniso-partners.com) |
07:37.02 | *** join/#devuan antenagora (~antenagor@147.162.137.245) |
07:48.48 | *** join/#devuan unixman_home (~unixman2@209-108-35-72.mtaonline.net) |
07:48.48 | *** join/#devuan unixman_home (~unixman2@unaffiliated/eracc) |
07:50.08 | *** join/#devuan cocoadaemon_ (~foo@2a01:e35:8a99:e90:1202:b5ff:fe91:e4ca) |
07:54.25 | *** join/#devuan puria (~puria@net-93-148-150-251.cust.vodafonedsl.it) |
08:00.07 | *** join/#devuan DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
08:05.43 | *** join/#devuan FatPhil (~luser@6-251-190-90.dyn.estpak.ee) |
08:08.35 | *** join/#devuan gour (~gour@unaffiliated/gour) |
08:35.05 | *** join/#devuan Human_G33k (~HumanG33k@62.147.242.8) |
08:46.22 | *** join/#devuan hufdufhv (~Thunderbi@119.165.236.197) |
08:47.41 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
08:53.14 | *** join/#devuan andi89gi (~andi89gi@p5B1028E5.dip0.t-ipconnect.de) |
09:01.34 | *** join/#devuan nighty (~nighty@b157153.ppp.asahi-net.or.jp) |
09:03.19 | *** join/#devuan Acacia (~Acacia@unaffiliated/acacia) |
09:05.20 | *** join/#devuan Besnik_b (~Besnik@athedsl-99727.home.otenet.gr) |
09:08.21 | *** join/#devuan Acacia (~Acacia@unaffiliated/acacia) |
09:11.24 | *** join/#devuan tierce2 (~raoulzeca@ip-62-235-80-40.dsl.scarlet.be) |
09:40.40 | *** join/#devuan xinomilo (~xinomilo@199.254.238.208) |
09:49.43 | clemens3 | morning, just upgraded from jessie to ascii |
09:49.50 | clemens3 | worked and rebooted |
09:50.03 | clemens3 | but now apt-get update gives hash mismatch error |
09:50.49 | clemens3 | hash sum mismatch.. tried country name de.deb.devuan.org in sources.list |
09:52.41 | *** join/#devuan mdrights (~user@209.250.232.119) |
09:55.24 | xinomilo | probably mirror sync issue, try again in a while or switch mirror |
09:55.55 | clemens3 | hmm, ok |
09:58.32 | Evilham | hellooo |
09:58.34 | Evilham | clemens3: around? |
10:03.25 | clemens3 | re |
10:03.33 | clemens3 | Evilham: yes? |
10:03.47 | Evilham | hi hi |
10:03.56 | Evilham | so, question time! |
10:03.59 | Evilham | where are you located? |
10:04.03 | Evilham | are you using ascii? |
10:04.04 | clemens3 | Switzerland |
10:04.15 | clemens3 | i dist-upgrade to ascii from jessie |
10:04.21 | clemens3 | that seemed fine, then rebooted |
10:04.35 | clemens3 | used deb.devuan.org |
10:05.00 | Evilham | I see, yes, I managed to identify the issue now with my computer (as opposed to before at 4am with my phone :-p) |
10:05.10 | clemens3 | cool |
10:05.34 | Evilham | that's the good news, the bad news is that we are now waiting for replies :-p- |
10:06.12 | clemens3 | ok, problem identified.. then I am happy and wish good fixing.. waiting mode.. |
10:06.32 | 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 |
10:06.58 | clemens3 | i will, before I wasnt sure how to prefix.. now you showed me.. |
10:07.25 | Evilham | yeah, ideally you wouldn't have had to :-) |
10:10.54 | clemens3 | I adapted my sources.list to the mirror |
10:11.36 | clemens3 | you give an update when the situation change? |
10:11.43 | clemens3 | d |
10:11.54 | Evilham | sure thing, I can ping you here when that happens |
10:12.07 | clemens3 | super, thanks a lot!later |
10:16.29 | *** join/#devuan rafalcpp_ (~racalcppp@84-10-11-234.static.chello.pl) |
10:31.46 | *** join/#devuan queip (~queip@unaffiliated/rezurus) |
10:32.31 | cosurgi | hi, did the devs abandom devuan, or everything will be okay? I love devuan, please don't kil it due to aprils' joke. |
10:34.02 | rrq | Evilham: I've had 'apt-get update' issue for 2 hours now. even from ungleich :( |
10:34.48 | fsmithred | cosurgi, devuan is not dead. Everything will be ok. |
10:37.10 | Evilham | Really? Shouldn't be the case |
10:37.36 | Evilham | rrq: will you be around in about 30 mins? |
10:37.41 | rrq | sure |
10:38.03 | Evilham | Good |
10:55.12 | *** join/#devuan gour_ (~gour@unaffiliated/gour) |
11:06.35 | *** join/#devuan Invader_Bork (~Invader_B@ppp2551078650.ambra.ro) |
11:06.54 | cosurgi | fsmithred: thanks! |
11:14.51 | *** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy) |
11:36.11 | *** join/#devuan banisterfiend (~textual@ruby/staff/banisterfiend) |
11:44.08 | *** join/#devuan akoana (~ah@ge10-rb1100.vie.funkinternet.at) |
11:57.19 | *** join/#devuan zeden (~user@unaffiliated/zeden) |
12:01.38 | *** join/#devuan andi89gi (~andi89gi@p57B6DB68.dip0.t-ipconnect.de) |
12:02.54 | *** join/#devuan justinsm (~justinsm@82-69-63-196.dsl.in-addr.zen.co.uk) |
12:06.22 | *** join/#devuan banisterfiend (~textual@ruby/staff/banisterfiend) |
12:29.58 | xinomilo | used devuan tor mirror, new firefox with fix, is in. |
12:33.13 | *** join/#devuan andi89gi (~andi89gi@p57B6DB68.dip0.t-ipconnect.de) |
12:35.32 | *** join/#devuan enyc (~enyc@muddle.enyc.org.uk) |
12:36.20 | clemens3 | any update? or is there a workaround? I have a production server in limbo.. |
12:42.27 | *** join/#devuan banisterfiend (~textual@ruby/staff/banisterfiend) |
12:57.13 | *** join/#devuan cocoadaemon (~foo@x53.octopuce.fr) |
13:00.34 | *** join/#devuan cd (~none@gateway/tor-sasl/cd) |
13:00.44 | *** join/#devuan cake_ (~cake0r@chorizo.lostnode.org) |
13:01.12 | *** join/#devuan James1138 (~james1138@184.102.74.56) |
13:02.51 | *** join/#devuan Stacker (~stacker@gateway/tor-sasl/b616) |
13:28.44 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
13:34.45 | *** join/#devuan engidea (~damiano@176.206.200.212) |
13:43.57 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
13:48.50 | *** join/#devuan puria (~puria@net-93-148-150-251.cust.vodafonedsl.it) |
13:49.20 | *** join/#devuan FriendlyMan (~IceChat9@174-21-67-167.tukw.qwest.net) |
13:54.03 | *** join/#devuan sb35 (~sb35@67.231.16.203) |
13:55.46 | Evilham | clemens3: it's fixed |
13:55.48 | Evilham | propagating now |
13:55.58 | Evilham | if you need it very urgently, use pkgmaster.devuan.org |
13:56.10 | Evilham | within the next couple hours everything should be up-to-date |
13:57.08 | *** join/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
13:58.22 | fsmithred | Evilham, I must have started my upgrade two seconds after it was ready, because it just completed successfully. |
13:59.44 | Evilham | it's been fixed for shy over 30 mins now |
14:01.15 | fsmithred | ah, ok. |
14:01.43 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
14:05.20 | clemens3 | ok, thanks , will check now.. |
14:09.12 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
14:10.32 | *** join/#devuan rsx (~rsx@ppp-188-174-134-175.dynamic.mnet-online.de) |
14:11.29 | clemens3 | error is gone, super.. thanks a lot! |
14:14.37 | Evilham | thank you for helping with the debugging :-p |
14:18.24 | fsmithred | xinomilo, what version of firefox-esr do you have now? |
14:23.23 | *** join/#devuan p3nt0de (~pentode@173.209.60.36) |
14:23.25 | *** join/#devuan pent0de_ (~pentode@173.209.60.36) |
14:24.30 | *** join/#devuan p3nt0de (~pentode@173.209.60.36) |
14:28.14 | *** join/#devuan p3nt0de (~p3nt0de@173.209.60.36) |
14:48.00 | 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? |
14:49.38 | 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.. |
14:53.13 | fsmithred | slvr, you could start with importing the source to git.devuan.org |
14:53.43 | fsmithred | best if you can clone an existing repo that has the history |
14:54.00 | fsmithred | clone/fork I'm not sure which |
14:55.01 | fsmithred | get it working and people can test it |
14:55.29 | Evilham | fix is (almost) fully propagated \o/ |
14:55.39 | fsmithred | cool, thanks |
15:05.25 | slvr | fsmithred: the git tree from gnu only contains a script to pull firefox from mercurial, modify, then build it. |
15:06.17 | fsmithred | slvr, that might work. I know of one other package we pulled from mercurial |
15:06.31 | slvr | I would think the newly generated icecat code would be what needs to be checked in |
15:06.54 | fsmithred | yeah, that would be best |
15:07.14 | fsmithred | you can't find that? |
15:07.45 | slvr | I have it on my workstation, but I'd think we would generate a new one to package. |
15:08.10 | slvr | maybe modify all the sed and file move operations to be tracked in git. |
15:12.11 | fsmithred | the newest source package I'm seeing is from november |
15:12.22 | fsmithred | is there anything newer? |
15:14.05 | slvr | no, ff 60 esr is current |
15:15.01 | slvr | looks like a new ff esr from mozilla is due in july |
15:15.20 | fsmithred | have you built it locally yet? |
15:17.11 | slvr | I have. Currently working on reproducing that build on a fresh system. |
15:26.04 | *** join/#devuan LtWorf_ (~LtWorf@2001:9b1:4041:e000:a634:d9ff:fec6:343c) |
15:29.32 | *** join/#devuan engidea (~damiano@176.206.200.212) |
15:30.47 | *** join/#devuan silentjet (~jet@staticline-31-182-135-124.toya.net.pl) |
15:40.01 | *** join/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
15:42.39 | *** join/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
15:44.01 | *** join/#devuan ymasson (~ymasson@lfbn-1-11047-4.w86-213.abo.wanadoo.fr) |
15:53.44 | *** join/#devuan cocoadaemon (~foo@2a01:e35:8a99:e90:1202:b5ff:fe91:e4ca) |
15:57.00 | *** join/#devuan proteusguy (~proteusgu@cm-58-10-154-216.revip7.asianet.co.th) |
16:09.30 | *** join/#devuan climbingturtle (~climbingt@c83-252-114-149.bredband.comhem.se) |
16:25.38 | *** join/#devuan brabo (~brabo@globalshellz/owner/brabo) |
16:41.39 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
16:43.05 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
16:44.53 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
17:09.13 | *** join/#devuan Jasjar (Jasjar@gateway/vpn/privateinternetaccess/jasjar) |
17:09.38 | *** join/#devuan IoFran (~Thunderbi@200.68.140.61) |
17:14.04 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
17:14.26 | *** join/#devuan clemens3 (~clemens@80-218-38-71.dclient.hispeed.ch) |
17:20.27 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
17:21.15 | *** join/#devuan AntoFox (~AntoFox@5.91.36.31) |
17:24.45 | *** join/#devuan engidea (~damiano@176.206.200.212) |
17:25.19 | *** join/#devuan Kizano (markizano@2600:3c00::f03c:91ff:fec8:382d) |
17:26.51 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
18:04.56 | *** join/#devuan Acacia (~Acacia@unaffiliated/acacia) |
18:15.35 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
18:16.17 | *** join/#devuan hufdufhv1 (~Thunderbi@119.165.236.197) |
18:27.12 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
18:33.36 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
18:40.01 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
18:47.23 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
18:50.51 | *** join/#devuan shibboleth (~shibbolet@gateway/tor-sasl/shibboleth) |
18:54.45 | Evilham | the last mirror that was out of sync finished about 1h ago |
18:55.09 | Evilham | so, deb.devuan.org is fully back to normal |
18:59.55 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
19:12.52 | *** join/#devuan jiefk (~nikel@nikel.me) |
19:13.48 | *** join/#devuan jiefk (~nikel@nikel.me) |
19:15.08 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
19:16.00 | *** join/#devuan enyc (~enyc@muddle.enyc.org.uk) |
19:18.30 | *** join/#devuan IoFran (~Thunderbi@200.68.140.61) |
19:23.51 | *** join/#devuan alexandros_tab (~quassel@unaffiliated/alexandros-c/x-1684531) |
19:23.52 | *** join/#devuan alexandros_c (~quassel@unaffiliated/alexandros-c/x-1684531) |
19:24.46 | *** join/#devuan banisterfiend (~textual@ruby/staff/banisterfiend) |
19:27.50 | *** join/#devuan sokan (~sokan@unaffiliated/totaloblivion) |
19:30.12 | *** join/#devuan petzi (~petzi@pD9F96E5A.dip0.t-ipconnect.de) |
19:31.09 | g4570n | ð |
19:32.08 | *** join/#devuan Invader__Bork (~Invader_B@ppp2551078650.ambra.ro) |
19:32.36 | *** join/#devuan unixman_home_ (~unixman2@209-108-35-72.mtaonline.net) |
19:32.36 | *** join/#devuan unixman_home_ (~unixman2@unaffiliated/eracc) |
19:32.45 | *** join/#devuan IoFran (~Thunderbi@200.68.140.61) |
19:33.54 | *** join/#devuan hufdufhv1 (~Thunderbi@119.165.236.197) |
19:35.13 | *** join/#devuan amarsh04_ (~amarsh04@ppp121-45-107-40.bras2.adl6.internode.on.net) |
19:35.17 | *** join/#devuan rafalcpp (~racalcppp@84-10-11-234.static.chello.pl) |
19:37.24 | *** join/#devuan divansantana_ (~divansant@156.0.193.126) |
19:38.00 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
19:38.11 | *** join/#devuan cyteen_ (~cyteen@cyteen42.plus.com) |
19:38.54 | *** join/#devuan asthralios (markizano@2600:3c00::f03c:91ff:fec8:382d) |
19:39.31 | *** join/#devuan triffid (triffid@lovecraft-ipv6.eldergods.org) |
19:40.00 | *** join/#devuan brocashelm (~brocashel@207.189.2.233) |
19:40.04 | *** join/#devuan climbingturtle (~climbingt@c83-252-114-149.bredband.comhem.se) |
19:40.22 | *** join/#devuan tillo (znc@pentoo/developer/tillo) |
19:47.02 | *** join/#devuan JohnDoe2 (~johndoe2@regex.ga) |
19:47.26 | flrn | Hello! |
19:50.32 | flrn | I hope for some hints on my ascii desktop stalling at boot for some (varying) seconds when loading the "initial ramdisk". |
19:51.06 | flrn | this phenomenon is quite new (some weeks) |
19:51.44 | flrn | I am not aware of any changes besides the usual updating |
19:52.38 | flrn | no SSD involved, legacy BIOS (this machine does not have UEFI) |
19:53.45 | flrn | I am a bit afraid that it might be a weak capacitor?! |
19:54.18 | 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 |
19:55.16 | flrn | gnarface: yes it's quieted, thanks I'll fix and reboot... |
19:58.21 | flrn | gnarface: the reboot went blazingly fast now |
19:58.37 | 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 |
19:59.08 | flrn | will do a full shutdown now, to test if it happens only on a fully discharged system |
19:59.16 | gnarface | yea a cold boot might make a difference |
19:59.36 | gnarface | but it could be a networking issue too |
19:59.53 | flrn | network at this stage? |
20:01.17 | 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 |
20:01.20 | gnarface | that's just an example |
20:01.21 | *** join/#devuan izh_ (~izh@unaffiliated/izh/x-2009676) |
20:01.35 | gnarface | but i had you remove "quiet" in the hope that we could be sure |
20:02.13 | gnarface | since whatever is stalling, usually happens right after the last line of text before the hang |
20:04.36 | 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 |
20:05.26 | 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 |
20:06.08 | 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) |
20:06.36 | gnarface | usually bad capacitors cause stability issues, not performance issues |
20:06.37 | furrywolf | if only we had a more modern init system that would do everything in parallel so it wouldn't stall... :P |
20:07.01 | furrywolf | hides |
20:08.18 | bleb | anyone notice that keyboard shortcuts dont work in libreoffice impress? |
20:08.21 | 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) |
20:08.36 | bleb | this is a relatively fresh ascii install, just trying ctrl+z and it's not undoing, but selecting it from the menu works |
20:09.15 | gnarface | i never touched it bleb, sorry, can't say. |
20:09.39 | gnarface | it's only in impress? not the other libreoffice suit tools? |
20:09.46 | gnarface | suite* |
20:09.55 | furrywolf | bleb: I've never used impress. |
20:10.34 | *** join/#devuan LtWorf_ (~LtWorf@2001:9b1:4041:e000:a634:d9ff:fec6:343c) |
20:10.43 | gnarface | bleb: i do notice there's libreoffice in ascii-backports, just fyi. |
20:11.36 | *** join/#devuan hplar_ (~ralph@unable-to-package.org) |
20:13.03 | flrn | gnarface: oh, MTA triggers something... but the system does not hang noticeable anymore since I removed the "quiet" option |
20:13.22 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
20:15.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. |
20:16.44 | 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 |
20:16.47 | gnarface | it wasn't supposed to be doing that |
20:17.04 | gnarface | and all the king's horses and all the king's men couldn't figure out what was up |
20:17.30 | gnarface | i later traced it to unexpected behavior from some bios powersaving setting that wasn't working right |
20:18.41 | gnarface | that's a really rare type of issue though. usually intermittent startup delays are caused by the network. |
20:19.50 | *** join/#devuan jobregon[m]1 (jobregonma@gateway/shell/matrix.org/x-dajxponrkthvlqmx) |
20:20.22 | 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. |
20:26.06 | 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 |
20:26.07 | furrywolf | heh, my irc client often doesn't notice the network has dropped until I press a key. |
20:26.54 | 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 |
20:28.10 | 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 |
20:28.36 | furrywolf | yeah, that seems like a pretty broken dhcp server |
20:29.08 | gnarface | yea they're supposed to wait 60s too, but it clearly wasn't doing that. |
20:29.47 | 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 |
20:30.14 | gnarface | in fact, it took me a real long time to figure out that it would work if i just kept trying |
20:32.02 | furrywolf | I probably would have just jumped to "this dhcp server is broken, use something else" without tracking down why. |
20:34.58 | *** join/#devuan salsbury (~kurgan@bl11-164-38.dsl.telepac.pt) |
20:35.52 | flrn | gnarface: the delay happens long before any NICs are brought up. |
20:36.54 | 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? |
20:37.26 | gnarface | flrn: also, is it a laptop? |
20:38.30 | gnarface | (laptop bioses might have powersaving features enabled for spinning-platter harddrives that can cause some delay while they "wake up") |
20:39.13 | furrywolf | heh, how about a feature to preheat hard drives before booting? :) |
20:39.29 | gnarface | like an oil pan heater on a car? |
20:39.34 | furrywolf | yep |
20:39.43 | gnarface | heh, might actually be useful in some environments... |
20:39.47 | furrywolf | my toughbooks have hard drive heaters... I've never turned that feature on, however. |
20:40.03 | gnarface | for real? i didn't know that was a thing |
20:40.34 | flrn | when I "unquiet" grub, there is no noticeable delay. "quiet" the delay happens right after the "loading initial ramdisk" line. |
20:41.48 | 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. |
20:42.07 | *** join/#devuan symdrome (~symdrome@187.65.2.56) |
20:42.35 | 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 |
20:42.38 | gnarface | flrn: *that* is interesting. if you're sure that is the case, you could try just blacklisting that driver in the kernel |
20:42.40 | flrn | "it" == the p-ata disks |
20:43.02 | 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) |
20:43.26 | furrywolf | if you turn it on, it'll pre-heat the drive if it's below a certain temperature before spinning it up |
20:43.36 | gnarface | furrywolf: cool |
20:44.05 | furrywolf | "might actually be useful in some environments" describes many toughbook features. :) |
20:45.05 | *** join/#devuan LtWorf (~LtWorf@2a00:801:211:2c0a:a634:d9ff:fec6:343c) |
20:45.14 | 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? |
20:47.27 | flrn | or is it really sufficient to create a blacklist.conf under /etc/modprobe.d? |
20:48.49 | flrn | it seems to be sufficient, https://wiki.debian.org/KernelModuleBlacklisting states: |
20:49.25 | 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' |
20:59.05 | flrn | gnarface: I blacklisted ata_generic and pata_atiixp, but no change: still failing ata soft reset messages. |
20:59.13 | flrn | not sure, what else to blacklist |
21:07.44 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
21:12.56 | *** part/#devuan Guest41282 (~quassel@mail.g7y.de) |
21:14.28 | *** join/#devuan devil_ (~quassel@mail.g7y.de) |
21:17.47 | *** join/#devuan Jjp137 (~Jjp137@cpe-75-83-16-81.socal.res.rr.com) |
21:23.04 | *** join/#devuan LtWorf (~LtWorf@2001:9b1:4041:e000:a634:d9ff:fec6:343c) |
21:23.57 | *** join/#devuan shibboleth (~shibbolet@gateway/tor-sasl/shibboleth) |
21:33.33 | flrn | libata.force= works somewhat different than expected... but it has an effect (trying to recover now) |
21:49.49 | 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. |
21:50.29 | gnarface | usually on a motherboard the sockets and the busses themselves are the last things to go, but i've still seen it happen. |
21:51.00 | gnarface | this type of behavior is more common in my experience with aging usb devices |
21:51.55 | gnarface | but theoretically i think any type of bus connection could fail in this way |
21:52.12 | gnarface | (dmesg exposing periodic reset warnings could be the smoking gun here) |
21:53.01 | gnarface | i'd google around for the warning messages and see if anyone else has seen them for this particular disk controller |
21:53.24 | 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 |
21:54.00 | gnarface | there are a dozen or two of of them |
21:54.08 | gnarface | and some overlap in compatibility |
21:54.30 | 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) |
21:56.55 | 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 -_- |
21:57.37 | gnarface | ah i see. that was a possibility that occurred to me. |
21:58.44 | gnarface | i have no way to conclude whether it is a hardware or software issue |
21:59.34 | 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 |
22:00.46 | gnarface | i wonder what the possible implications are if removing the "quiet" flag is really the only reliable workaround so far |
22:01.21 | gnarface | that definitely shouldn't in any cases ever make the boot times shorter |
22:03.17 | *** join/#devuan unixman_home (~unixman2@209-108-35-72.mtaonline.net) |
22:03.17 | *** join/#devuan unixman_home (~unixman2@unaffiliated/eracc) |
22:05.50 | gnarface | flrn: i wonder if it could just be an illusion? like, it just seems to take longer to boot without the text, because the display won't wake up for a few seconds after boot otherwise? have you ever actually timed it? |
22:06.19 | *** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy) |
22:06.21 | gnarface | no wait, you said it halted on a line of text, so that's not possible... |
22:06.27 | gnarface | man i'm stumped |
22:07.37 | flrn | gnarface: I give up for today, have to get some sleep now. It's not about boot times, just about understanding the rough edges of my system... The timing varies. I'll sleep and get sorted out, where to continue. Thanks a lot for your help! |
22:09.28 | *** join/#devuan xcm (~xcm@ipa210.225.tellas.gr) |
22:11.24 | gnarface | flrn: no problem, have a good one |
22:12.51 | *** part/#devuan akoana (~ah@ge10-rb1100.vie.funkinternet.at) |
22:24.18 | *** join/#devuan cesspit (~pit@185.97.200.84) |
22:33.38 | *** part/#devuan cesspit (~pit@185.97.200.84) |
22:48.35 | *** join/#devuan fsmithred (~fsmithred@devuan/developer/fsmithred) |
22:50.25 | *** join/#devuan Uberius (~Uberius@gateway/tor-sasl/uberius) |
23:31.26 | *** join/#devuan Uberius (~Uberius@gateway/tor-sasl/uberius) |
23:36.39 | *** join/#devuan clemens3_ (~clemens@178-82-161-195.dynamic.hispeed.ch) |
23:37.40 | *** join/#devuan Achylles (~Achylles@2804:431:d725:e38f:c661:d978:946f:9219) |
23:46.14 | Syllin | i need to configure devuan to think my system clock refers to local time, so that when i dual boot windows i dont get the switching problem. the tutorials i found online use systemd to do this x_X. any tips? |
23:46.45 | Syllin | i found /etc/adjtime, but i changed UTC to LOCAL and that didn't seem to work |
23:49.28 | slvr | tzselect? |
23:52.06 | gnarface | i think it's "dpkg-reconfigure tzdata" |
23:52.11 | gnarface | but i could be wrong |
23:52.36 | gnarface | honestly though, unless it's earlier than windows XP it's probably better to look up the registry key that makes windows obey UTC than the other way around |
23:53.04 | gnarface | i don't know it off the top of my head but i heard that with modern versions of windows you CAN make it obey UTC, it just *defaults* to local time and doesn't ask you about it |
23:54.31 | gnarface | but there's some secret panel or registry key you can use to change it |
23:54.50 | gnarface | (because at the end of the day, microsoft developers still need an OS that works right) |
23:56.33 | *** join/#devuan Uberius (~Uberius@gateway/tor-sasl/uberius) |
23:58.43 | Syllin | slvr and gnarface: thanks. those commands seem to change /etc/timezone, which makes sense. but my issue seems to be different. the OS reads some low level registers on my motherboard, and needs to know if the bits correspond to a certain timezone? i've heard windows people say it'll be easeir to change in linux and visa versa |
23:59.21 | slvr | I've never heard of that. |
23:59.33 | slvr | maybe it's a new uefi thing. Dunno. |
23:59.49 | Syllin | https://www.howtogeek.com/323390/how-to-fix-windows-and-linux-showing-different-times-when-dual-booting/ |