| Jjp137 | I wouldn't say not to use us.deb; it is documented here: https://devuan.org/os/ | 00:00 |
|---|---|---|
| Jjp137 | but it is easiest to start with deb.devuan.org | 00:00 |
| xrogaan | Hypertables: could you give me the result from `host us.deb.devuan.org'? | 00:00 |
| Hypertables | us.deb.devuan.org is an alias for pkgmaster.devuan.org. pkgmaster.devuan.org has address 5.196.38.18 | 00:00 |
| gnarface | that is correct | 00:02 |
| gnarface | that is what i get here too | 00:03 |
| gnarface | but deb.devuan.org should be a round-robin of several mirrors | 00:03 |
| gnarface | i see 13 here | 00:04 |
| xrogaan | yeah, so maybe something is crapping on your network as you receive the files. You might have a cache somewhere. | 00:04 |
| Hypertables | pretty sure I don't have an http cache or anything like that | 00:05 |
| gnarface | well, it looks like you only have one option to confirm whether it is the repo or not | 00:08 |
| gnarface | in general it is a bad idea to use 3rd party repos or other distro's repos though | 00:08 |
| gnarface | that could really be the issue too | 00:09 |
| gnarface | not that you have the repo in there, but that you installed something from there | 00:09 |
| gnarface | if it was made for debian or ubuntu, for example, there are a number of highly eccentric failure cases | 00:09 |
| gnarface | most of them not immediately obvious on install | 00:10 |
| xrogaan | no, I don't get the warning but the InRelease file does list a different sha256sum than the one from the file I get | 00:10 |
| xrogaan | a958a8acee49af960759f7533231b075d184fa8ee7d708764b022d33c1d29e8f 335185 main/Contents-amd64.gz | 00:10 |
| xrogaan | http://deb.devuan.org/merged/dists/ascii-updates/InRelease | 00:10 |
| xrogaan | But locally: 75acef3458d85396d38b730213b0fe801508a961f4d30495cfa585b8318ccf95 Contents-amd64.gz | 00:10 |
| gnarface | same if you use https? | 00:10 |
| xrogaan | IIRC there is no https | 00:11 |
| xrogaan | not on the round robin, it uses the wrong certificate | 00:12 |
| Jjp137 | pkgmaster supports https, but you have to explicitly specify that mirror instead of using deb.devuan.org | 00:12 |
| Jjp137 | the round robin doesn't support https | 00:12 |
| gnarface | 75acef3458d85396d38b730213b0fe801508a961f4d30495cfa585b8318ccf95 for Contents-amd64.gz locally here too | 00:15 |
| xrogaan | is there a way for apt to not care about that value? | 00:20 |
| gnarface | probably, but i don't know if it's a good idea to ignore it | 00:21 |
| gnarface | could be evidence of a MITM attack... | 00:21 |
| xrogaan | gnarface: apt-config | grep AllowInsecure | 00:23 |
| xrogaan | I have this, somehow: Binary::apt-get::Acquire::AllowInsecureRepositories "1"; | 00:24 |
| gnarface | also note that in that InRelease file, that line for main/Contents-amd64.gz is actually listed under the armhf/Packages.gz file | 00:24 |
| gnarface | so that's probably just a case of looking at the wrong InRelease file | 00:25 |
| gnarface | but i don't know how this works well enough to be sure | 00:25 |
| gnarface | might you have enabled that before installing the devuan-keyring package then forgot to turn it back off? | 00:26 |
| gnarface | xrogaan: ? | 00:26 |
| xrogaan | haven't touched that | 00:26 |
| xrogaan | might not even be relevant | 00:26 |
| gnarface | hmm | 00:26 |
| gnarface | i see it actually set to Binary::apt-get::Acquire::AllowInsecureRepositories "1"; | 00:27 |
| gnarface | on my rpi | 00:27 |
| xrogaan | https://manpages.debian.org/stretch/apt/apt-secure.8.en.html | 00:28 |
| xrogaan | so not relevant | 00:29 |
| xrogaan | how do you see the package "armhf" thing? | 00:30 |
| xrogaan | oh, I don't think those are relevant | 00:31 |
| xrogaan | the InRelease file is just a list of files without set order. | 00:31 |
| gnarface | there is indentation | 00:31 |
| gnarface | look on the previous line | 00:31 |
| gnarface | all the way at the left | 00:32 |
| xrogaan | As I said, it's a list a files with associated hash. | 00:33 |
| xrogaan | and size | 00:33 |
| xrogaan | what concerns me is that apt doesn't raise an error with the mismatching hash. | 00:33 |
| gnarface | i wonder if it has to do with the redirects | 00:34 |
| gnarface | and you're right, i was getting weird wrapping. it's a linear list after all | 00:34 |
| xrogaan | Hypertables: try to manually clean /var/lib/apt/lists/ | 00:39 |
| xrogaan | just in case | 00:39 |
| Hypertables | no change | 00:41 |
| xrogaan | how did you clean the folder? | 00:43 |
| Hypertables | with rm -rf | 00:44 |
| Hypertables | incl removal of the "lists" directory | 00:44 |
| xrogaan | you might be behind a proxy without knowing it. | 00:45 |
| Hypertables | doubtful. I'm behind a residential cable internet connection and I manage the gateway box myself. it does iptables-based nat but no proxying | 00:46 |
| xrogaan | do you trust your ISP? | 00:48 |
| obarun | hi, what's the devuan policies about elogind? Do you use it? Do you use consolekit2 or any other alternatives? | 00:48 |
| gnarface | obarun: it's mentioned in the release notes https://files.devuan.org/devuan_ascii/Release_notes.txt | 00:49 |
| Hypertables | this looks very much like a bug in devuan to me ... has anyone managed to pull a copy of this file http://deb.devuan.org/merged/dists/ascii/main/Contents-amd64.gz with the "correct" checksum e0e8ec7baba6bc2d4c26918b14aa8e27b95939d9f7440cb98fb087191e8de019 ? | 00:51 |
| obarun | gnarface: many thanks | 00:52 |
| gnarface | obarun: no problem | 00:53 |
| xrogaan | Hypertables: is that the correct checksum? | 00:55 |
| Hypertables | well that's what's in http://deb.devuan.org/merged/dists/ascii/InRelease | 00:55 |
| Hypertables | has anyone pulled a different content of the InRelease file? | 00:55 |
| gnarface | not here, i don't think | 00:56 |
| xrogaan | I have not | 00:58 |
| xrogaan | Hypertables: why does my apt not warn me of those mismatches? | 01:04 |
| gnarface | didn't we go over this once and it turns out because they're auto-generated with combined contents on the fly? | 01:05 |
| xrogaan | no, gnarface, you seem to be confused. | 01:06 |
| xrogaan | or I am | 01:06 |
| gnarface | i'm sure i'm confused | 01:06 |
| xrogaan | I don't know why the file listed above "main/Contents-amd64.gz" should be relevant to "main/Contents-amd64.gz". | 01:07 |
| gnarface | ignore that, i was hallucinating | 01:09 |
| gnarface | i note that the main/Contents-amd64.gz for ceres does seem to match the InRelease file | 01:09 |
| gnarface | so it's something different about ascii | 01:10 |
| gnarface | could it just be not yet updated? | 01:10 |
| xrogaan | but why isn't my apt yelling? | 01:11 |
| gnarface | it could be this setting in apt-config perhaps? Binary::apt-get::Acquire::AllowInsecureRepositories "1"; | 01:14 |
| gnarface | check to see if you have it | 01:15 |
| xrogaan | that's related to the gpg key | 01:19 |
| xrogaan | you're not getting the error either | 01:19 |
| gnarface | that is true | 01:19 |
| gnarface | hmm. i'm still thinking it might have something to do with how amprolla works. that's what my memory is nagging at anyway | 01:23 |
| gnarface | there might be http 302 redirects confusing something here | 01:23 |
| xrogaan | ah no, you were right | 01:26 |
| xrogaan | sudo apt -o Acquire::AllowInsecureRepositories=false update < this fails everything | 01:27 |
| xrogaan | https://paste.debian.net/1076616/ | 01:28 |
| xrogaan | welp, it's all broken now | 01:37 |
| obarun | just for information for people interested to run s6 and s6-rc as init and service manager, i created a convenient tools to easily implement s6 and s6-rc on every linux system -> https://framagit.org/obarun/66.git | 02:01 |
| Hypertables | I still get errors if I do `apt-get -o Acquire::AllowInsecureRepositories=true update` ... are there any flags I can set that will bypass the hash sum errors? | 04:58 |
| gnarface | Hypertables: i really think you need to figure out what non-devuan package is sabotaging the check, and then uninstall it. that's my best guess | 05:13 |
| gnarface | if you had used backports before, you could have one of them blocking an important upgrade, too | 05:20 |
| gnarface | (there may be a way to actually override the hash sum errors, but i don't know it off the top of my head and i suspect it would just make this situation worse anyway) | 05:22 |
| Jjp137 | hm I actually installed apt-file to check it out and I'm getting a ton of hash sum errors too | 05:33 |
| Jjp137 | but if you don't use apt-file, then I guess the Contents.gz files don't mean much, and you should still be able to install packages, I think? | 05:34 |
| Jjp137 | okay after experimenting some more, you're fetching the Contents files b/c apt-file is installed, which uses them | 05:38 |
| Jjp137 | however, for some reason, the hashes don't match | 05:39 |
| Jjp137 | a workaround if you don't use apt-file is to purge it (you can't just remove it, b/c apt-file comes with a config file that tells apt to fetch Contents files) | 05:39 |
| Jjp137 | if you do use apt-file, then uh...I don't know then | 05:40 |
| Jjp137 | although the InRelease file seems to have updated and I don't get hash sum errors anymore | 05:55 |
| gnarface | hmm. i do remember there being a problem with apt-file that appeared quite some time ago that i never checked back on | 06:37 |
| gnarface | that might be a very old issue | 06:37 |
| gnarface | or related to it | 06:37 |
| Jjp137 | it's just odd that the hashes didn't match at some point | 06:54 |
| jelly | that points to broken mirror | 08:54 |
| jelly | Q: (how) does devuan track jessie-lts, and how is security managed for customized software? | 08:55 |
| jelly | and by customized I mean "changed compared to Debian" | 09:25 |
| xrogaan | Hypertables: no, I get the errors too | 11:25 |
| xrogaan | it's as you said, something's borked with the repo | 11:25 |
| * xrogaan summons KatolaZ | 11:26 | |
| xrogaan | Hypertables: or was broken | 11:26 |
| xrogaan | seems fine now | 11:26 |
| * xrogaan unsummon KatolaZ | 11:27 | |
| xrogaan | (sorry) | 11:27 |
| KatolaZ | xrogaan: ? | 11:30 |
| KatolaZ | which errors? | 11:30 |
| xrogaan | Earlier in this channel (before I went to sleep) we talked about it. Basically hashsum mismatch between what's in the in InRelease file and the listed files. | 11:31 |
| xrogaan | Seems to be resolved now. | 11:31 |
| KatolaZ | xrogaan: you must have hit the exact time when the InRelease files were synced | 11:32 |
| xrogaan | well, I didn't find the error, Hypertables did. | 11:33 |
| xrogaan | Then we tried to resolve the issue for a while, downloaded the Content file and verified the hash didn't match. | 11:33 |
| xrogaan | Then after purging my /var/lib/apt/lists, it went: https://paste.debian.net/1076616/ | 11:33 |
| xrogaan | but now it's fine. | 11:34 |
| KatolaZ | xrogaan: you should be careful with hashes | 11:34 |
| KatolaZ | there are both md5 and sha256 | 11:34 |
| KatolaZ | and there are a lot of Contents files in the repo | 11:34 |
| KatolaZ | let apt do the job :) | 11:34 |
| xrogaan | expected: SHA256:a958a8acee49af960759f7533231b075d184fa8ee7d708764b022d33c1d29e8f; received: SHA256:75acef3458d85396d38b730213b0fe801508a961f4d30495cfa585b8318ccf95 | 11:34 |
| xrogaan | KatolaZ: just saying, there was an issue _with the repo_ and now there isn't. | 11:35 |
| KatolaZ | xrogaan: is there a pastebin of the apt error somewhere? | 11:35 |
| xrogaan | I just linked it | 11:36 |
| xrogaan | you might also try the irc logs and look for Hypertables's | 11:36 |
| KatolaZ | ok xrogaan | 11:37 |
| KatolaZ | that's just Contents files getting updated | 11:37 |
| KatolaZ | they are updated once a week, on the night between Sunday and Monday | 11:37 |
| KatolaZ | can't remember the exact time | 11:37 |
| xrogaan | does it take long for them to get synced? | 11:37 |
| KatolaZ | maybe | 11:38 |
| KatolaZ | they are quite large | 11:38 |
| xrogaan | between Hypertables reporting the error and me clearing my apt cache, there's been a good hour. | 11:38 |
| KatolaZ | had they tried again in the meanwhile? | 11:39 |
| KatolaZ | i.e., issuing `apt-get update`? | 11:39 |
| xrogaan | seems so: http://maemo.cloud-7.de/irclogs/freenode/_devuan/_devuan.2019-04-08.log.html#t2019-04-08T04:58:10 | 11:39 |
| xrogaan | very slow sync, or the sync failed somehow. | 11:40 |
| xrogaan | and then got restarted? | 11:41 |
| xrogaan | IDK | 11:41 |
| * KatolaZ shrugs | 11:41 | |
| xrogaan | amazon's cdn got very slow maybe? | 11:42 |
| xrogaan | sorry, I looked at the wrong terminal | 11:43 |
| KatolaZ | xrogaan: we are not using any amazon CDN... | 11:43 |
| xrogaan | *not* amazon, devuan | 11:43 |
| KatolaZ | we are not using any external CDN | 11:43 |
| KatolaZ | it's a bunch of mirrors behind a DNS round-robin | 11:43 |
| xrogaan | Isn't the round robin world wide? That's kind of what a CDN is, right? | 11:44 |
| xrogaan | If you remove all the marketing BS from the existing powerhouses. | 11:44 |
| xrogaan | Anyhow, the InRelease file got updated roughly a day after: Date: Mon, 08 Apr 2019 03:26:56 UTC | 11:45 |
| xrogaan | While files with this date had issue: Release file created at: Sun, 07 Apr 2019 21:05:34 +0000 | 11:46 |
| detha | xrogaan: in a proper CDN, DNS is only used sparingly for steering, and node selection is done by anycast | 12:31 |
| Evilham | Exactly :-) | 16:42 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!