| gnarface | i don't, but i think winehq snuck in there | 00:00 |
|---|---|---|
| gnarface | for the most part it's just devuan | 00:00 |
| systemdlete | mostly devuan here also | 00:00 |
| systemdlete | I suppose the wonky repo server theory is still not out of the question. Perhaps the cacher really is doing its update, or trying to, when a new request comes in. At the moment it tries to sync, it could be the case that it hits our (theoretical) bad repo server, and the cacher does not thoroughly check return codes, etc. | 00:05 |
| systemdlete | So that it THINKS it has completed the task, but really hasn't. | 00:05 |
| systemdlete | IOW, even if there really is a bad repo server out there, cacher should be able to re-trace its steps and maybe move on to the next repo server or whatever | 00:06 |
| systemdlete | unless it is completely random EVERY time and then cacher could get stuck in a loop. | 00:06 |
| systemdlete | OTOH, gnarface, what does apt itself do when it hits a bad repo? | 00:07 |
| gnarface | yea, it seems possible some sort of race condition could exist where if it updates itself from a repo that's currently being updated it could get some sort of dead-end state | 00:07 |
| gnarface | well, apt just gives you an error, and then exits at the end if there were any errors | 00:07 |
| gnarface | but it seems possible apt-cacher-ng might i dunno... ignore it and move on? | 00:07 |
| gnarface | or try to anyway | 00:07 |
| gnarface | and then sometimes partially succeed | 00:08 |
| systemdlete | Is apt unable to try a different repo upon an error? | 00:08 |
| systemdlete | I understand it is rr, but can a client apt tell the rr mechanism that it would like to try again with another server? | 00:08 |
| systemdlete | or is apt relegated to using whichever server it is given by the rr mechanism? | 00:09 |
| gnarface | well, i usually use apt-get not apt so i'm not sure, but i think they all just bail out if there were any single errors anywhere in the "update" action, while during the "upgrade" actions they will try to continue with the packages they already have, until they hit a broken dependency | 00:09 |
| systemdlete | this is probably a question for our friend onefang. | 00:09 |
| gnarface | yea | 00:09 |
| gnarface | but, i think it picks the host from the round-robin at the start of the action, and doesn't try to gain a new one until the next new action | 00:10 |
| gnarface | but there's no reason to expect one way or another whether apt-cacher-ng would behave similarly on the back end | 00:10 |
| systemdlete | when you say it picks it, does that mean that apt-get has free choice? | 00:11 |
| gnarface | no, i think it means the dns library at the system level hands over an answer to apt-get, apt-get does not even know there are multiple options | 00:11 |
| systemdlete | right. | 00:11 |
| systemdlete | so it's getting whatever host the sum total of the DNS chain tells it | 00:12 |
| systemdlete | so neither the apt/apt-get client NOR the hosts have any say. It is all up to DNS | 00:12 |
| systemdlete | I would love it if onefang could explain exactly how the rr works. | 00:12 |
| systemdlete | I mean is DNS load-balancing there? THat doesn't sound likely to me, but I am no DNS maven at all | 00:13 |
| gnarface | from my vague recollection of the dns and bind book, it is literally just multiple records where there'd normally be one, and the system libraries have "standard" behaviors they're supposed to follow that amount to a type of load-balancing, but different OSes frequently... dodge the standard behavior slightly to improve perceived user experience in certain corner cases | 00:14 |
| systemdlete | yeah, I know. Some admins configure their DNS in variant ways. | 00:15 |
| gnarface | this also involves which actual DNS servers to query, if more than one are specified in the install | 00:15 |
| systemdlete | resolv.conf | 00:15 |
| systemdlete | but there is also nis and nis+ | 00:15 |
| systemdlete | and I seem to recall some other mechanisms that can override even these. And that's just locally. | 00:16 |
| systemdlete | If there is a router on the local network, it might have its own DNS configuration, such as openwrt has (dnsmasq). | 00:16 |
| systemdlete | or there could be a dedicated DNS server on the local network. | 00:17 |
| systemdlete | And don't even get started about what your ISP might be doing... | 00:17 |
| systemdlete | (rooms you can't ask about, etc.) | 00:17 |
| gnarface | in my case, i have two local DNS servers and they're the same ones i'm using both for apt-cacher-ng and the installs using it | 00:18 |
| systemdlete | I have only one. | 00:18 |
| gnarface | for my case anyway, there shouldn't be any deviation in their behavior | 00:18 |
| systemdlete | and all of my systems, real or VM, use it. | 00:19 |
| systemdlete | oh yeah. | 00:19 |
| systemdlete | I forgot one: dns-over-https | 00:19 |
| gnarface | i've disabled that | 00:19 |
| systemdlete | how? | 00:19 |
| gnarface | well it's just a checkbox in firefox, shouldn't be highly relevant here | 00:20 |
| systemdlete | oh, ok. | 00:20 |
| systemdlete | but there is nothing to stop other programs from using it | 00:20 |
| systemdlete | not that apt would | 00:20 |
| gnarface | no, there's not, but i highly doubt anyone has added such a thing to apt-cacher-ng | 00:20 |
| gnarface | so far that i know, firefox is the only such instance of it being "snuck in" to common installs | 00:21 |
| systemdlete | I'm just referring to the long list of ways that DNS can be (mis-?)configured | 00:21 |
| gnarface | yea, understood | 00:21 |
| systemdlete | confusing, I mean | 00:21 |
| systemdlete | but all that said, I guess drilling down through the cacher source is probably the only way to figure out exactly what it is doing | 00:22 |
| gnarface | i'm leaning more towards an assumption that the issue could be something to do with timing and the status of the remote repo while apt-cacher-ng is actually downloading cache | 00:22 |
| gnarface | possibly some small window where it can get a functional cache that somehow "dead-ends" and doesn't get flushed normally | 00:22 |
| systemdlete | using out-of-date indices will certainly cause drama for apt and apt-cacher | 00:22 |
| systemdlete | I sense that the indices are just not getting updated sometimes. | 00:23 |
| systemdlete | (you call it "timing") | 00:23 |
| systemdlete | Ah. It just hit me. Now I see what you are saying. | 00:24 |
| gnarface | hmm, something is tickling my memory here... on the maintenance panel, those checkboxes for the manual cache update/cleaning run... uh... are we sure those are only relevant to that button, or if i check some of them then just exit the browser, will they affect the automated behavior behind the scenes during normal use? | 00:24 |
| gnarface | for some reason i've got a fragment of a memory there only just hinting i may have been wrong about an assumption one way or another about that long ago... | 00:25 |
| systemdlete | you know, I actually wondered about this myself. But carefully reading the instructions on the page, I came to the conclusion that they only applied to that run of the maintentance | 00:26 |
| gnarface | yea, i think you're right, but i'm still left wondering if there might be some option to force it to be more pedantic during normal use in a way that may damage bandwidth savings but help reliability | 00:26 |
| systemdlete | I'm not sure that the page is designed to be a GUI for configuring the cacher. | 00:26 |
| gnarface | yea, probably not | 00:26 |
| systemdlete | whatever it is, the instructions and the doc are not too clear to me. | 00:27 |
| systemdlete | otoh, I admit I have not read it all thoroughly. | 00:27 |
| gnarface | heh, in all fairness this was clearly never a finished project | 00:27 |
| gnarface | it just didn't have any real competition other than apt-cacher which was just too confusing | 00:28 |
| gnarface | everyone else was (and i guess still is?) using squid or some variant thereof | 00:28 |
| systemdlete | squid would be too much for me. I don't want complete mirroring. | 00:29 |
| gnarface | and i can't be sure any of them would be any less of a pain in the ass. the empirical evidence from my years of industry experience suggests that proxies have been an enduring pain in the ass since their inception and nothing has changed | 00:29 |
| systemdlete | one thing I notice is that the github repos for apt-cacher-ng seem to be all over the place. | 00:30 |
| systemdlete | ddg on github apt-cacher-ng gives a listing, starting with ashang's github, not the root | 00:31 |
| gnarface | multiple unofficial forks in the wild? wouldn't surprise me that people are trying to "finish" it, because its usefulness is as apparent as its unfinished-ness | 00:31 |
| systemdlete | (sorry if I am not using the correct terminology for git and github.) | 00:31 |
| systemdlete | so we end up with multiple unofficial forks, none of which are complete either!!!! | 00:32 |
| gnarface | i just remembered something! | 00:32 |
| systemdlete | seems like the state of gnu and linux these days. Nothing new there. | 00:32 |
| systemdlete | what? | 00:32 |
| gnarface | what the fuck is this doing actually, and could it be related to the problem? /etc/cron.daily/apt-compat | 00:33 |
| systemdlete | https://dev1galaxy.org/viewtopic.php?id=4174 | 00:33 |
| gnarface | ... maybe not directly, but just incidentally, by being a thing that randomly causes a proxy cache hit outside of normal maintenance | 00:34 |
| gnarface | thanks | 00:34 |
| systemdlete | only reason I mentioned that link is because it was the very first one from ddg search, and it is almost word for word your question | 00:34 |
| gnarface | yea, this doesn't answer the question | 00:35 |
| gnarface | the thing is, as far as i can recall this has been present in debian forever | 00:35 |
| systemdlete | a sleep for up to 30 minutes in apt-compat? | 00:35 |
| gnarface | yea, i distinctly remember seeing it run early in the mornings over a decade ago | 00:36 |
| gnarface | i thought it checked system load and delayed in random intervals until the system was idle | 00:36 |
| gnarface | but i never really questioned what it was doing other than "something to do with maintaining package dependencies" | 00:36 |
| gnarface | but now i'm wondering if it has any value whatsoever to someone who doesn't use unattended upgrades or GUI package managers | 00:37 |
| gnarface | and if it was causing proxy hits at random times in the wee hours of the morning, it'd be a prime suspect for instigating proxy cache corruptions | 00:38 |
| gnarface | and if it's not useful i'd be strongly tempted to just pitch it overboard | 00:38 |
| systemdlete | no locking mechanism? | 00:38 |
| systemdlete | (I'm not against it myself, if it is unhelpful) | 00:39 |
| gnarface | eh, just more like "it's doing something while i'm not paying attention, so if it causes an incidental error i won't notice and the evidence may get hidden" | 00:39 |
| gnarface | it might be contributing to why this is so hard to isolate the cause of deductively, is all i'm saying | 00:40 |
| systemdlete | or "they are stepping on each other's toes" | 00:40 |
| gnarface | yea, hard to say | 00:40 |
| systemdlete | oh I won't disagree... | 00:40 |
| systemdlete | apt/apt-get definitely use locking, but who knows if these background tools (cacher, compat, etc) do | 00:41 |
| gnarface | well, just at a skim, it does a bunch of elaborate standoff timing, then it calls /usr/lib/apt/apt.systemd.daily which seems to be for... mucking about with cache backups and updating timestamps and such? that's just at a skim, but based just on that i don't think we can rule it out as unrelated | 00:43 |
| systemdlete | good to know it calls at least SOMETHING *systemd* lol | 00:44 |
| * systemdlete is glad they take a HBP pill daily... | 00:44 | |
| gnarface | seems like it would be easy to disable but i'm hesitant to attempt amputation before really understanding what i'm removing | 00:46 |
| systemdlete | well, for one thing, and this could be a problem: that cron file is part of the apt package | 00:46 |
| gnarface | and yea, of course there's that. whatever changes we make might quickly be overwritten by the next update | 00:47 |
| systemdlete | according to pacapt, but maybe there's a more accurate way to determine where it comes from | 00:47 |
| gnarface | so if it's important we're going to have to jump through hoops and maybe fight some fights | 00:47 |
| systemdlete | oh boy i can hardly wait. Let's get started today... | 00:47 |
| systemdlete | :p | 00:47 |
| * systemdlete looks for his suit of mail... | 00:48 | |
| gnarface | no, i think you're right, it's a main part of apt, and basically i've been just hoping it turns out to be vestigial without systemd or unattended-upgrades installed | 00:48 |
| gnarface | unfortunately i also don't know a lot about how apt handles caching and package dependency data internally. it's difficult to infer how much of this may or may not be needed for normal functionality... | 00:53 |
| systemdlete | this news just keeps getting better and better | 00:54 |
| systemdlete | what is the easiest way to determine which github a package was built from? | 00:55 |
| systemdlete | I'd like to at least see what the sources are. | 00:55 |
| gnarface | uh, i don't know exactly, just start with 'apt-get source apt' i think | 00:55 |
| djph | apt (etc) shouldn't need a cronjob at all ... | 00:56 |
| gnarface | i seem to recall seeing the github link in stdout | 00:56 |
| djph | s/apt/APT/ | 00:56 |
| gnarface | djph: do you happen to know if this is all just maintenance tasks for the unattended-upgrades package and it doesn't even get used if you don't have that installed? | 00:56 |
| djph | I've never seen an apt cronjob fire off in my cron log ... but, uh, maybe I missed it? | 00:57 |
| gnarface | it's usually early in the morning | 00:57 |
| gnarface | they randomize it a bit | 00:57 |
| djph | yeh, and I (should(tm)) get emails for every cronjob... | 00:57 |
| gnarface | hmm | 00:57 |
| gnarface | do you have these two files? /usr/lib/apt/apt.systemd.daily /etc/cron.daily/apt-compat | 00:58 |
| djph | have the later, looking for the former | 00:59 |
| gnarface | both listed as part of the apt package for me on daedalus | 00:59 |
| systemdlete | Maybe they are only triggered if background upgrades are enabled? | 00:59 |
| djph | ew ... I do | 00:59 |
| gnarface | i certainly don't have unattended-upgrades installed, nor do i recall having installed it ever before, though it is possible these files were inherited from any of a chain of half a dozen prior release upgrades... | 01:00 |
| djph | well, this is only slighly horrifying | 01:01 |
| djph | ah | 01:02 |
| djph | they "run(tm)" but then (should, apparently) eventually die when they can't find APT::Periodic::Enable | 01:03 |
| djph | uh, assuming I'm reading the comments and apt configuration properly | 01:04 |
| rrq | no, it's opt-out | 01:05 |
| systemdlete | gnarface, if ashang/apt-cacher-ng is the official repo, then it has not been touched for 10 years | 01:06 |
| systemdlete | (see https://github.com/ashang/apt-cacher-ng) | 01:06 |
| gnarface | seems about right | 01:07 |
| gnarface | the package headers might say | 01:07 |
| gnarface | or the config files in the source package, i mean | 01:07 |
| rrq | djph: but then requires unattended-this-that setting and/or clean-interval non-zero to actually do things | 01:07 |
| djph | yes | 01:08 |
| djph | although that entire bash script is horrifying... | 01:08 |
| rrq | yes.. my cat ran away :) | 01:09 |
| djph | You should probably not let it ou... ohhhhh | 01:09 |
| rrq | systemdlete: https://salsa.debian.org/public?name=apt-cacher-ng&sort=latest_activity_desc | 01:14 |
| systemdlete | thank you rrq | 01:14 |
| gnarface | hmm, it says to get the source package from sid | 01:15 |
| gnarface | i think that's what it means | 01:16 |
| rrq | use the toglle that says "master" | 01:16 |
| rrq | or toggle | 01:16 |
| gnarface | ah, yes, it's there | 01:18 |
| gnarface | thanks, rrq | 01:18 |
| rrq | .. "debian/sid" is the packaging branch, and "upstream/sid" is the upstream sources for that packaging | 01:20 |
| rrq | though I'm not sure which of those projects were used for published releases | 01:25 |
| * systemdlete was wondering that also | 01:25 | |
| rrq | probably Eduard Bloch.. which has 10 forks; the others have 0 forks | 01:27 |
| systemdlete | I vote for Eduard Bloch. For Prez. | 01:34 |
| systemdlete | His is also the one that has the most recent updates, apparently. But I don't know if that's just the README file, or the entire sourcecode base for the cacher | 01:37 |
| systemdlete | the debian/sid branch is labeled "merge branch upstream/sid into debian/sid" | 01:40 |
| systemdlete | rrq: Arent' a lot of the branches for making docker containers? | 01:41 |
| rrq | I think the current debian dev principle is to have an upstream branch and a packaging branch.. and possibly replicating that for each targeted release codename | 01:57 |
| systemdlete | oh, sorry. I was referring to ddg hits when I searched for apt-cacher-ng githubs. | 01:58 |
| systemdlete | I now see you are referring to branches of one of the official githubs for apt-cacher-ng | 01:59 |
| systemdlete | (whichever one that might be) | 01:59 |
| * onefang wakes up and reads through the lengthy conversation that pinged me several times. See if I need to take care of anything. | 02:01 | |
| * systemdlete can be blamed for that, mostly | 02:02 | |
| systemdlete | good morning onefang | 02:02 |
| rrq | systemdlete: not that "github" is a particular git store (owned by microsoft) and salsa is another one (using the gitlab software but ont their own servers I think) | 02:07 |
| rrq | not=note | 02:07 |
| onefang | gnarface and systemdlete: I did do a bit of groking of apt and friends code while writing apt-panopticon. Which is how I came up with crazy things like the URL sanity test. It pokes at and prods all sorts of things to do with the various apt processes. | 02:07 |
| systemdlete | rrq, git is a distributed VCS, so yes, I am aware of the perils of believing that ANY store of git is THE official one. | 02:09 |
| onefang | BUt note that apt-panopticon says in big red letters at the top that it is experimental, and at the bottom that it is alpha. There is a bunch of TODO items in the code, in the docs, and in my bug tracker. Some of those relate to getting the package mirrors to do better. Like carefully order how metadata and data is synced. Debian has a script they use I think. | 02:10 |
| * systemdlete is even beginning to understand git a little lately, but systemdlete still does not think the way git does... | 02:10 | |
| djph | oh? | 02:12 |
| onefang | I've never looked at the apt caching stuff though. Entirely possible it does things differently. The other tools do. One of the reasons I use mmdebstrap over debootstrap is that mmdebstrap uses apt under the hood. Some use aptitude to help sort out issues, coz it tries lots of variations. | 02:13 |
| djph | in terms of /var/cache/apt, or apt-cacher-ng and friends? | 02:14 |
| onefang | Yes djph, I'm still reading through that lengthy conversation. | 02:18 |
| onefang | Oh noes!!! SystemD raised it's head there. Pfffft | 02:21 |
| onefang | I do recall that there is a link to the actual sources used for building a package inside the metadata the package mirrors deal with. I think it's part of the internal caches apt uses as well. | 02:25 |
| onefang | Devuan holds our sources in our git. Even apt-panopticon has a copy there. | 02:26 |
| onefang | In general my answer is - as part of apt-panopticon I try to figure out the various ways the various apt tools might fail to work with a Devuan package mirror. Including following links to Debian mirrors. There's sooo many tools, I have sooo many TODO items... | 02:28 |
| onefang | Any help poking at odd corner cases in the code of the lesser used tools, especially if they result in suitable Lua code for adding to apt-panopticon, would be appreciated. | 02:32 |
| * onefang goes back to the other things I catch up on during my mornings. Was a public holiday, so this is my first day back at "work". | 02:33 | |
| gnarface | hmm, i didn't think about the possibility of cross-referencing the cache errors through apt-panopticon | 02:36 |
| gnarface | i wonder if that could turn up any clues... | 02:37 |
| onefang | Oh and as for DNS round robin, the "round robin" part should be a clue, but there's so many DNS resolvers out there, they all work differently to. They have their own caches. lol | 02:40 |
| systemdlete | onefang, yes. DNS is a mess, even though it isn't designed to be. | 02:47 |
| systemdlete | need to reboot | 03:49 |
| amarsh04 | hi, I need to report a bug against Debian packages, so I know to use reportbug -B debian | 09:04 |
| amarsh04 | but it is a breakage of mozc related to a libglib2.0 upgrade | 09:04 |
| amarsh04 | do I report it against libglib2.0, mozc or both? | 09:04 |
| ted-ious | amarsh04: You'll probably have to wait a few hours for some developers to wake up. :) | 09:11 |
| CueXXIII | amarsh04: if it is glib breaking its abi i would report it there; the bug can still be reassigned if it really is mozc's fault (ie. using private calls of glib or other dirty tricks) | 09:30 |
| amarsh04 | CueXXIII found a similar issue in Debian bug #1070730 for libglib2.0, added some information and referenced my original Debian bug report of #1070738 against ibus | 09:33 |
| amarsh04 | ps, to see random colours in konsole, move the mouse over 6-digit Debian bug numbers prefixed with # (-: | 09:34 |
| justbosco | Hello everyone, has anyone experienced that when installing Microsoft Edge the browser in Devuan does not start?The browser does not start Microsoft Edge? Can anyone give their opinion on the subject? | 22:37 |
| gnarface | Microsoft released Edge for Linux? | 22:37 |
| justbosco | gnarface: yes | 22:38 |
| gnarface | what error do you get when you start it? | 22:38 |
| justbosco | gnarface: just dont run I research and semms to be someone about graphics acceleration | 22:39 |
| justbosco | I would like to know if anyone else has this happen to them with Microsoft edge | 22:40 |
| gnarface | you might simply have forgotten to install your video card manufacturer's official accelerated drivers and the software won't run without hardware acceleration. that's pretty common for Windows software | 22:40 |
| gnarface | what video card do you have? | 22:41 |
| justbosco | gnarface: How Could I be install the driver aceretor for the graphics Nvidia detect? | 22:41 |
| gnarface | you're on daedalus, aka devuan 5, aka the current stable release? | 22:42 |
| gnarface | justbosco: ^ | 22:43 |
| justbosco | gnarface: Nvidia I im Devuan 5 Microsoft Edge used to work well but now I don't know why it doesn't work. I would like to know if anyone has tried edge and how to solve it. | 22:43 |
| gnarface | justbosco: my guess is you just install all the packages with "nvidia" in their name and then reboot and it'll work | 22:44 |
| justbosco | gnarface: Thank you for your response, your opinion helped me a lot. I hope it is resolved. | 22:46 |
| gnarface | well keep us posted... | 22:46 |
| justbosco | gnarface: 👍 | 22:47 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!