| systemdlete | I am seeing unprintable characters in the output of some commandline programs. E.g., wmctrl -l lists all my windows and displays firefox with three black diamond question marks in front of the word "firefox" | 02:38 |
|---|---|---|
| systemdlete | I know, it's unicode and all the issues around "wide" characters and yada yada. Is this going to be cleaned up, or maybe wide characters get implemented in Gnu/Linux, or whatever? | 02:39 |
| systemdlete | I've seen this in the output of other commands also (not many, but...) | 02:40 |
| systemdlete | (can't recall which other ones atm) | 02:40 |
| systemdlete | the main reason I ask is because if I ever need to, say, grep through some program's output, it can be tricky, and stripping out unprintables is might not always be a guarantee of accurate results. | 02:41 |
| systemdlete | s/ is // | 02:41 |
| systemdlete | with regard to my experimentation with 3D VMs, it looks like daedalus is not the issue: It just froze the desktop withOUT 3D. So the problem is something else. | 02:44 |
| systemdlete | chimaera has not frozen once, at least up until now. | 02:45 |
| Xenguy | I'm running Chimaera now, and I get no such artifacts with that command | 02:46 |
| onefang_ | I'm experimenting with apt-cacher-ng today. What was your basic issue with it again systemdlete? | 02:46 |
| * onefang_ removes my tail. | 02:46 | |
| fsmithred | no black diamonds in daedalus, either. I tried xfce4-terminal and xterm | 02:47 |
| Xenguy | MATE Terminal here | 02:47 |
| systemdlete | onefang, clients intermittently fail to get packages (Ign instead of Hit) | 02:47 |
| gnarface | hmm... systemdlete, the unprintable characters thing seems like either a mis-configuration where you've got the wrong terminal or environment variable settings or else a bug in that build of the program where it's ignoring your environment | 02:49 |
| onefang | Funnily enough I had that problem hit during initial tests, but seems fine now. My main problem right now is it doesn't get along with apt-listbugs. | 02:50 |
| gnarface | the description of the problem also matches potential video ram hardware failure, but when that happens usually the corrupted glyphs seem randomized, and not just isolated to the terminal | 02:50 |
| systemdlete | ok, nvm about the unprintables--that seems to be only related to ff windows/tabs running thruk | 02:51 |
| onefang | apt-cacher-ng also doesn't get along with HTTPS, but that's the problem with HTTPS, it's designed to shut out the MITM, but proxies work by being the MITM. I can live with that for now. | 02:51 |
| systemdlete | sorry for the noise about those unprintables... | 02:52 |
| * systemdlete hits themselves hard on the head for not being more thorough | 02:52 | |
| onefang | At least you are not printing unprintable noise. | 02:52 |
| systemdlete | (might be better if I did sometimes) | 02:53 |
| onefang | Any clues on the apt-cacher-ng / apt-listbugs mismatch? It's telling me it can't contact the bug tracker server. | 02:54 |
| systemdlete | onefang, I continue to look at the cacher problem, but I've been busy with other stuff here for the past few weeks. | 02:54 |
| onefang | That's my problem in general, been busy with other stuff since beginning of last year. lol | 02:55 |
| systemdlete | it's like, every time I try to investigate one problem, it leads me down some rabbit hole or another where I encounter yet another issue, and ... | 02:55 |
| systemdlete | (y'know) | 02:55 |
| onefang | I was about to dive into the problem for the day, but since you where here being unprintable, I figured I'd ask you first for clues. | 02:56 |
| systemdlete | I SOOO want the cacher to work right. | 02:56 |
| Xenguy | Is there a simple way to constrain an application from running at 100% CPU ? | 02:56 |
| Xenguy | Kind of like a 'nice' at the application level? | 02:57 |
| systemdlete | Xenguy, that's a problem I've encountered frequently. Supposedly, limit(1) is supposed to allow you to restrict resources like, say, cpu for processes. | 02:57 |
| systemdlete | But sadly, I found it didn't really work too well. | 02:57 |
| systemdlete | onefang, am I really all that unprintable? | 02:58 |
| onefang | apt-cacher-ng is at least doing a good job of catching the things that mmdebstrap avoids the local cache for in the early steps. So that helps with testing my install script over and over.. | 02:58 |
| Xenguy | systemdlete, Appreciate the tip, I'll have a look | 02:58 |
| systemdlete | You are making me feel like The Pentagon Papers, the way you say that... | 02:58 |
| systemdlete | Xenguy, let me know if it works for you. I tried, but for some reason, it just didn't seem to have any effect. | 02:59 |
| Xenguy | Will do | 03:00 |
| systemdlete | strangely, Xenguy, I haven't run into that problem in a long time. | 03:01 |
| Xenguy | systemdlete, This new(er) version of qbittorrent seems to be running quite hot, and pushing the CPU to 100% | 03:08 |
| systemdlete | what happens if you try setting cpu limit? | 03:09 |
| systemdlete | and then running qbittorrent in the same environment (I think the environment has limits set inherited from its parent(s)) | 03:10 |
| systemdlete | been a while since I looked into that one | 03:10 |
| Xenguy | I'll let you know when I get around to it | 03:12 |
| systemdlete | oh, ok. I thought you were trying this right now | 03:13 |
| systemdlete | btw, the cmd line is ulimit | 03:13 |
| onefang | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775126 seems relevant. "apt-cacher-ng fails to let apt-listbugs retrieve bugreports when used as proxy". I'll try the work around in the other bug report linked from that one. | 03:14 |
| systemdlete | (it's actually "prlimit" now? What?) | 03:14 |
| onefang | Seems SOAP is a bit too slippery. | 03:15 |
| gnarface | Xenguy: for a bittorent client it may be easier to constrain the CPU load by constraining the concurrent connection count... assuming there's some setting for that | 03:16 |
| Xenguy | gnarface, Makes sense, thanks for the idea | 03:17 |
| rrq | onefang: seems apt-listbugs has bugs.debian.org stringly hardcoded in its ruby sources, but youc can have an apt.conf setting like "Acquire::http::Proxy::bugs.debian.org "DIRECT" to avoid it using proxy | 03:29 |
| rrq | .. documented in the ruby script /usr/bin/apt-listbugs | 03:30 |
| onefang | That's the work around I mentioned, I'm trying it now. | 03:30 |
| onefang | Just don't hold your breath, it takes over half an hour to run this test script. "That work around works" means "No problems with listbugs reported". Then I can go down the next unprintable rabbit hole. | 03:34 |
| onefang | apt-cacher-ng is working in general. "Fetched 17.1 MB in 0s (65.8 MB/s)" B-) | 03:38 |
| onefang | Damn, didn't help. | 03:49 |
| onefang | Ah works fine if I don't override the config file at the end to redirect the proxy from localhost to the qemu host. | 03:52 |
| systemdlete | rrq, onefang: just fyi, I am looking at apt-cacher-ng problem atm. I am running tcpdump (and maybe wireshark later on) | 04:05 |
| systemdlete | when it failed a few minuts ago, it looks like it was hitting m10k.jp.http | 04:06 |
| onefang | Got an IP for that? Name doesn't ring a bell. | 04:07 |
| systemdlete | I was just about to ask how you want the hosts, so from now on, I'll give you IPs | 04:07 |
| systemdlete | 160.16.137.156 | 04:08 |
| systemdlete | btw, I got the list of IPs from "nslookup deb.devuan.org" | 04:08 |
| onefang | devuan.m10k.jp is the name of that mirror. | 04:12 |
| onefang | apt-panopticon says there's nothing wrong with that mirror as of a few minutes ago. | 04:13 |
| systemdlete | so there is something wrong with me then | 04:14 |
| systemdlete | heheheh | 04:14 |
| systemdlete | I /think/ that was the one... I was just starting to investigate at that moment, and I may have mis-matched the packets I was seeing to the invocation of apt | 04:14 |
| onefang | I'm using my own mirror during today's testing. At least I can read it's log files if that'll be helpful. | 04:16 |
| systemdlete | I think I will switch over to my cacher system. bbs | 04:16 |
| al1r4d | https://kelar.org/~bandali/blog/pacify.html | 04:20 |
| al1r4d | PulseAudio with changing machine-id | 04:20 |
| al1r4d | for devuan | 04:20 |
| systemdlete | give me a momemnt to get my wireshark configured... | 04:21 |
| olivia-may | Hey, I can't get devuan Daedalus 5.0.1 to work with ventoy. When it gets to the boot preamble, mount has an error. "mount: mounting LABEL=DEVUAN501 on /cdrom failed: No such file or directory" "mount: mounting UUID= on /cdrom failed: No such file or directory". It tries this 4 times and then starts the emergency shell. I tried this with Debian on Ventoy and theres no issue. I'm using libreboot's SeaBios Payload to load Ventoy on my | 04:42 |
| olivia-may | thinkpad-x230. | 04:42 |
| onefang | I think this was discussed before olivia-may. Hopefully someone that was paying more attention than me at the time is paying attention now and can help you soon. | 04:48 |
| systemdlete | I've had varying amounts of success with ventoy. It seems they have to tweak ventoy a bit for each distro and release (i think) | 04:53 |
| systemdlete | I also used another similar tool as ventoy, but don't recall the name atm | 04:55 |
| systemdlete | one of them seemed to work ok for me. | 04:55 |
| olivia-may | systemdlete: MultiBoot? | 04:56 |
| onefang | apt-listbugs with apt-cacher-ng sorted. Next rabbit hole! rrq's suggested work around that I was already trying did the trick. | 04:59 |
| systemdlete | that might have been it. I tried a few of these. | 04:59 |
| rrq | devuan preamble expects the ventoy partition to be labelled "Ventoy" | 04:59 |
| rrq | expects=requires | 05:00 |
| rrq | olivia-may: if that's a hurdle for you there's another hands-on option | 05:13 |
| olivia-may | rrq: gparted shows the first partition (/dev/sdb1), the partition with the .iso files, as labelled as "Ventoy". | 05:23 |
| rrq | right. the preamble also expects it to be an iso9660 filesystem... and probably then expecting this of the whole ventoy device (/dev/sdb) | 05:27 |
| olivia-may | rrq: its showing as an exfat filesystem | 05:28 |
| rrq | probably a bug in the preamble there... so it may need the special hands-on route | 05:28 |
| olivia-may | whats the hands-on route? | 05:29 |
| rrq | 1. at the boot splaces, push TAB to see the boot command line, and add EMERG to it | 05:30 |
| rrq | doing so will make the preamble start an early "emergency shell" | 05:30 |
| systemdlete | So I just tested ventoy with devuan daedalus. The net-install doesn't seem to boot (with the same errors as olivia-may reported), yet chimaera net-install boots ok | 05:30 |
| systemdlete | I can also boot daedalus live install | 05:30 |
| systemdlete | maybe this should be reported to ventoy devs | 05:32 |
| rrq | 2. use "sed" to change line 27 of /sbin/unpack to use exfat for partition type rather than iso9660 (for the Ventoy partition) | 05:32 |
| rrq | 3. exit the early emergency shell | 05:33 |
| rrq | ... if that's still fails, there's also the "excessive hands-on route" to try | 05:35 |
| olivia-may | oh i forgot to mention, i was using the devuan_daedalus_5.0.1_amd64_desktop.iso. | 05:40 |
| rrq | that's fine; it's the same install s/w on all ISOs; when it works, the ISO (as ventoy image file gets) is set up at a loop device | 06:15 |
| systemdlete | they are all the same, yet daedalus live install booted but daedalus net-install did not | 06:23 |
| systemdlete | "when it works,..." | 06:24 |
| systemdlete | (maybe I misunderstand) | 06:24 |
| systemdlete | minimal-live booted but netinstall did not (fixing spelling) | 06:25 |
| systemdlete | Not saying you are wrong, but this doesn't comport with "same install s/w" | 06:25 |
| systemdlete | olivia-may, I haven't tried with desktop iso | 06:26 |
| systemdlete | (just fyi) | 06:26 |
| systemdlete | it turns out, btw, that I have been using ventoy, not multiboot (but I did try that one also) | 06:27 |
| rrq | live is not the installer | 06:27 |
| rrq | all the installer-iso ISOs have "the same" installer s/w | 06:28 |
| rrq | the main differences are in the on-disk package pools | 06:28 |
| rrq | ventoy only works when the booted filesystem is fully in the initrd or it includes special software to find the media as image file | 06:30 |
| systemdlete | chimaera netinstall boots | 06:39 |
| rrq | but the installer will need access to the media for loading modules which will fail | 06:42 |
| rrq | the daedalus installer(s) also boots (the preamble) | 06:43 |
| rrq | and they also need access to the media (for loading the "actual installer") | 06:43 |
| rrq | (which then again needs access to the media for loading modules... and possibly the package pool) | 06:44 |
| systemdlete | so whatever difference(s) exist, must exist after the preamble? | 06:53 |
| rrq | yes the differences between netinstall, server and desktop are in the iso pool content (and identifications); the installer s/w that is packed up into a subsequent initrd is the same | 07:06 |
| rrq | and the preamble (initrd) is the same | 07:07 |
| olivia-may | rrq: so what you're saying, is that the installer doesn't work with Ventoy? | 07:23 |
| rrq | right; the "actual installer" requires the media be mountable, i.e. be a device or partition. Ventoy only holds it as an image file. | 07:46 |
| rrq | the preamble solves that be setting up a loop device for the image file | 07:47 |
| rrq | before switching to the actual installer | 07:48 |
| rrq | iow it mounts the ventoy partition, finds the media file and sets it up as loop device, then switches to the installer which now can find the media as a device (the loop device) | 07:54 |
| rrq | (in practice it's a little bit more involved since the installer also "thinks" that it is the boot filesystem) | 07:56 |
| rrq | you'll find the particulars in the /init and /sbin/unpack scripts at the emergency shell filesystem (the preamble) | 07:58 |
| rrq | or you can join Luke at https://git.devuan.org/devuan/installer-iso | 08:02 |
| s|oO|0o|g | Hi, not a Devuan specific question, but that's the OS I'm typing this from: is duckduckgo failing to show results for other people than I? | 09:06 |
| systemdlete | I tried searching for "furkin" on ddg a few minutes ago, and I got an empty page | 09:17 |
| systemdlete | s|oO|0o|g, yeah, everything I search on ddg comes back bupkas now | 09:18 |
| s|oO|0o|g | "Sorry, we ran into an error displaying these results. Click here to try again." | 09:19 |
| systemdlete | yep, yep | 09:19 |
| systemdlete | same here | 09:19 |
| s|oO|0o|g | ok ty, I'm not too insane yet | 09:19 |
| s|oO|0o|g | same on my Lineage mobile phone (though this one fails to get results from startpage.com as well, wth is going on) | 09:21 |
| systemdlete | isitdownrightnow.com says ddg is up | 09:21 |
| s|oO|0o|g | well, the site is technically up, just functionally useless | 09:22 |
| systemdlete | seems like the whole net is slow | 09:25 |
| systemdlete | or the web anyway | 09:26 |
| systemdlete | startpage.com is working for me | 09:33 |
| systemdlete | and I can get to duckduckgo.com, but the searches are useless | 09:34 |
| s|oO|0o|g | I asked elswhere, bing seems down too, doesn't ddg use bing? | 09:39 |
| ted-ious | I believe microsoft invested in duckduckgo before they stopped pretending that they didn't modify search results so it seems reasonable that bing and ddg sites are related somehow. | 09:44 |
| ted-ious | Other people have mentioned bing problems elsewhere recently. | 09:45 |
| gnarface | duckduckgo is powered by bing, they've admitted that in an interview before at some point | 09:49 |
| systemdlete | What about startpage? or maybe others? | 09:50 |
| gnarface | no idea | 09:50 |
| s|oO|0o|g | startpage is ok AFAIK, they source from google | 09:51 |
| s|oO|0o|g | maybe their images are from bing | 09:51 |
| ted-ious | Startpage was purchased by an advertising firm several years ago. | 09:52 |
| s|oO|0o|g | startpage image search fails | 09:52 |
| s|oO|0o|g | oh? | 09:52 |
| s|oO|0o|g | ted-ious: right, thanks for the heads-up | 09:58 |
| s|oO|0o|g | "System1 operates an industry-leading responsive acquisition marketing platform (RAMP) powered by AI & machine learning." yay | 09:59 |
| ted-ious | I wish I had better news but knowledge is the beginning of progress. | 10:00 |
| systemdlete | gnarface,rrq,onefang: https://dpaste.com/DUEL9RXEB (sorry, debian paste thinks I am spamming it | 12:17 |
| systemdlete | It looks to me--and I am sort of an amateur with this--that the request comes in to the cacher, responds with a 416, but then returns the info anyway in a later response. Notice the long line of dots at the end... unprintables? | 12:18 |
| systemdlete | the timeframe here matches an apt failure on the client side. | 12:20 |
| systemdlete | client is mx-linux, not sure what version | 12:20 |
| systemdlete | I got this dump from wireshark by following the HTTP sequence | 12:21 |
| * systemdlete still wondering what happened to ddg... | 12:22 | |
| systemdlete | those dates seem to be all over the place! some are GMT, but some don't indicate any TZ, and seem to be local time (9:33 would be 7 hours ahead of us on west coast USA, so that matches) | 12:33 |
| gordonDrogon | systemdlete, it seems there is a big outage at Microsoft - which ddg, etc. uses... | 12:44 |
| systemdlete | thanks gordonDrogon | 13:07 |
| systemdlete | one thing I notice is that mx-linux wants to update chrome from google's repos. I don't see any links or references to google in the apt-cacher-ng configuration, but maybe I am missing it | 13:08 |
| systemdlete | maybe I have to manually create it? | 13:09 |
| gordonDrogon | https://www.bleepingcomputer.com/news/microsoft/microsoft-outage-affects-bing-copilot-duckduckgo-and-chatgpt-internet-search/ | 13:09 |
| gordonDrogon | I don't use chrome, so can' help there... | 13:09 |
| systemdlete | gordonDrogon, that was aside from ddg outage | 13:10 |
| systemdlete | (I'm sorting out a problem with the apt-cacher) | 13:10 |
| Unit193 | Yes, today I learned DDG is just a theme for Bing. | 13:10 |
| gordonDrogon | sure. from what I recall when I did use chrome was that the package was just a stub that then got the full thing directly from google though... | 13:10 |
| systemdlete | mx's apt config has chrome hardcoded for dl.google.com | 13:13 |
| rrq | systemdlete: apt-cacher-ng creates cache areas for all repository hosts it is asked about; no manual intervention needed | 13:13 |
| systemdlete | There is no cache area for google/chrome | 13:14 |
| systemdlete | rrq: For openwrt, i followed instructions on their wiki and added it to the cacher--it works. But I had to manually set up for openwrt. | 13:15 |
| rrq | mmm sounds like apt-cacher-ng doesn't have write access to it cache root dir | 13:16 |
| systemdlete | I see it create caches for kali and gentoo (not sure why; maybe I was experimenting with them, idr now) | 13:17 |
| gnarface | afaik if you don't register domains in the config it just caches to the cache root dir and they can theoretically clobber each other | 13:17 |
| gnarface | i think that's how it was working anyway... | 13:18 |
| systemdlete | I don't see any directoreis or files that look like "strays" | 13:18 |
| gnarface | hmmm | 13:18 |
| systemdlete | one thing I note--and it is probably harmless--is that some of the links in /etc/apt-cacher-ng go to directories under /var/lib/apt-cacher-ng and others go to /usr/lib/apt-cacher-ng. | 13:20 |
| rrq | it's the CacheDir setting in /etc/apt-cacher-ng/acng.conf | 13:20 |
| systemdlete | ah, there I see stuff that looks familiar | 13:21 |
| systemdlete | but nothing for google... not that it matters I guess | 13:22 |
| rrq | then further down may be some "Remap" rules (I comment out those) that "reorganise" the cace a bit | 13:22 |
| systemdlete | it still looks like a blessed mess to me... | 13:24 |
| systemdlete | rrq, have you looked at the link I posted above? | 13:25 |
| rrq | without remap rules apt-cacher-ng would want to create a directory in its CacheDir named by the host | 13:25 |
| * rrq looking | 13:26 | |
| systemdlete | I had one of the errors we've been discussing at 02:33, and there were some packet sequences at that time in the wireshark pcap I have been gathering | 13:26 |
| systemdlete | I should probably check just before and after that sequence | 13:27 |
| rrq | the cache gets polluted by *.head files that sometimes cause issues when some download has failed | 13:27 |
| rrq | your log suggests that apt-cacher recovered(?) .. that the InRelease file eventually was 44069 bytes long | 13:32 |
| systemdlete | and the cacher does not catch all of these errors? | 13:32 |
| rrq | I think there's a timeout setting that it should trust its cache for some 30 seconds | 13:33 |
| systemdlete | I mean, I expect that the cacher would check return codes (or equivalent) and clean up its temp files and such if a download fails. | 13:34 |
| systemdlete | BEFORE those files become part of that trusted cache | 13:34 |
| systemdlete | you know, 2-phase update sort of thing | 13:34 |
| systemdlete | I'd be surprised if it isn't at least trying to do that | 13:34 |
| rrq | yeah I think there's room for improvement | 13:35 |
| systemdlete | so would you agree that the problem isn't with your servers? | 13:35 |
| systemdlete | or do you still think there might be an issue there (e.g., what creates those sometimes download failures) | 13:36 |
| rrq | the servers may have hiccups, but sometimes the cacher locks in to keep the bad file | 13:36 |
| systemdlete | even if the rr servers have hiccups, the cacher should be able to deal with it. Hey, this *is* the Internet, after all. | 13:37 |
| systemdlete | it sounds like you are familiar with the cacher code? | 13:37 |
| rrq | it's also a problem if a server updates its meta file(s) before content files | 13:37 |
| systemdlete | true. But it should update them atomically together, right? | 13:38 |
| rrq | that triggers caching badness.. though the cacher could probably be improved to recover better | 13:38 |
| systemdlete | ok, so there are problems at both ends | 13:38 |
| rrq | servers should add content files first, then upgrade the meta files | 13:38 |
| rrq | most use plain rsync though | 13:39 |
| rrq | I believe pkgmaster itself updates in the good way | 13:40 |
| systemdlete | "servers" -- that could mean devuan's, debians, etc ? | 13:42 |
| rrq | yes both devuan mirrors and debian mirrors | 13:42 |
| systemdlete | and openwrt's and kali's etc also | 13:43 |
| systemdlete | mx ubuntu yada yada yada | 13:43 |
| systemdlete | there are too many external pieces to try to address the problem that way. | 13:43 |
| systemdlete | I think the cacher side should get attention first, for now. | 13:44 |
| rrq | and afaik there is no update syncronisation so plenty of race windows to think about | 13:44 |
| systemdlete | just fix it so that it catches those intermittent errors and handles them appropriately | 13:44 |
| systemdlete | I really like the cacher approach because it saves bandwidth and allows me to "prime" the local cache before updating systems, some of which might have to shut down in order to do the updates, and maybe not have net access at that time | 13:46 |
| systemdlete | which is the case here. | 13:46 |
| rrq | yes it's good. Though apt-cacher-ng (and maybe apt-cacher) as well don't interpret the files at all, and it apt that detects inconsistencies | 13:48 |
| rrq | the cacher(s) is just an http proxy, and there's no control protocol for apt to tell it that a file is bogus | 13:48 |
| systemdlete | If it would merely handle meta file and package file updates together, as a database-like transaction, I think that might suffice. | 13:49 |
| systemdlete | Would it need to get into the specific weeds for every distro, release, etc? | 13:49 |
| systemdlete | I really don't know | 13:50 |
| rrq | it certainly would need to understand "Release" files | 13:50 |
| systemdlete | I've never gotten that deep into the package hierarchy architecture etc | 13:51 |
| rrq | or one could superimpose a control protocol via bad range request... which then apt would need to know about and use | 13:51 |
| rrq | but being http there's no "identitiy connection" between client and proxy | 13:53 |
| systemdlete | so for now, I guess I am going to have to handle it from my end (not my cacher's end) and run the maintenance when a failure occurs. | 13:58 |
| systemdlete | which is exactly how I've been dealing with this | 13:59 |
| systemdlete | but I'm talking about automating the process a bit | 13:59 |
| systemdlete | which is a separate topic | 13:59 |
| onefang | Thought there was a cron job already? | 14:00 |
| onefang | Ah, you mean fix it when it happens. | 14:00 |
| systemdlete | yes | 14:00 |
| systemdlete | ok, time to go | 14:08 |
| systemdlete | thanks to all who contributed to this... analysis? | 14:08 |
| systemdlete | not sure what to call it | 14:08 |
| onefang | Welcome to the Weird Wild Web. | 14:10 |
| nomia | should i install zfs-initramfs or zfs-dracut if i am installing from debootstrap? | 16:55 |
| e3d3 | fsmithred: can I asked you again for help with refractasnapshot ? | 19:39 |
| e3d3 | Because of your previous advice I replaced (on a new Daedalus install) refractasnapshot 10.3.0 with 10.4.0, from temporary enabled Ceres repository. | 19:41 |
| e3d3 | Using it ended in closing the window without any message, and without created iso, idem when trying again by using option "re-squash" | 19:43 |
| e3d3 | I didn't remove the default installed micro-code because (if I understood you correct last time) this should not be necessary with version 10.4.0 | 19:44 |
| e3d3 | Did I something wrong here ? Should I have downloaded a 10.4 version deb-file to install ? | 19:45 |
| e3d3 | fsmithred: never mind. I forgot to use sudo :( .Trying again. | 19:58 |
| AlexLikeRock | damn it!!! . Has anyone installed HPLIP on deadalus??? that damn hp file, they only compile it in December. ¿How is it possible, if I buy a printer in May, I have to wait until December for the damn driver to be able to scan? | 21:36 |
| AlexLikeRock | Help me notice that the package is not updated | 21:36 |
| AlexLikeRock | https://developers.hp.com/hp-linux-imaging-and-printing/hplip-user-survey | 21:37 |
| AlexLikeRock | please team , wrote anyting | 21:37 |
| ted-ious | AlexLikeRock: I would take it back and tell them I'm going to buy a canon instead. | 21:40 |
| AlexLikeRock | yes yes yes !!! | 21:40 |
| ted-ious | Then I would buy a brother or an epson ecotank. | 21:41 |
| golinux | Maybe this will help? https://dev1galaxy.org/viewtopic.php?id=6492 | 21:41 |
| golinux | HP usb printer not recognized by HPLip | 21:42 |
| ted-ious | Any company that can't manage to put an ethernet port in their printer and make it work with generic postscript and sane drivers doesn't deserve your money. | 21:42 |
| golinux | Oh . . . and it's dAEdalus btw | 21:42 |
| golinux | ted-ious: OT is not helpful. | 21:43 |
| rwp | I will never buy anything but a network printer ever again. I am done with USB drivers. | 21:43 |
| rwp | Meanwhile... Is it possible to say that this new printer is enough like an old printer to set it up as an older printer? | 21:44 |
| rwp | I had to do that recently and after I was clued in as to what older printer to say that it was then things worked great. | 21:44 |
| AlexLikeRock | i try to SCAN by USB port | 21:54 |
| AlexLikeRock | any one have a blog or tutorial to SCAN from devuan ? . maybe found somting new | 21:54 |
| AlexLikeRock | yeah , always the olds printers work better thant a new | 21:55 |
| ted-ious | golinux: It looks like alex agrees that my comments were helpful. | 22:18 |
| rwp | AlexLikeRock, I was suggesting using an older printer driver definition for the newer printer. I agree older printers were better but here I was suggesting only using the configuration not an actual older printer. | 22:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!