| suavedandy | Guys. I understand that I'm a noob but it seems that if I try to install something other than Devuan I get all kinds of problems. | 09:53 |
|---|---|---|
| suavedandy | I kinda can't leave Devuan by this point. | 09:54 |
| suavedandy | Tried both GeckoLinux and OpenSUSE. GeckoLinux's live ISOs have stuff not working. OpenSUSE's installation ISO doesn't even have its signature matching. Both work slow. | 09:56 |
| danuan | suavedandy debian and now devuan are more straight forward i want to say server / admin (bsd-ish of linuxes) centric distributions , majority of todays other distros are for flashy desktop / newest feature driven | 10:02 |
| gnarface | suavedandy: i know. and i'm sorry. i've done my best to fix this problem with people, the world, and society as a whole but i failed. | 10:03 |
| danuan | but it all depends on intricacies you are more confortable in dealing with , as all of them , devuan included have their own querks , and depends on hardware also ( some hardware will be hassle free out of the box , some will need tweaking) | 10:03 |
| suavedandy | Well, I'm going to install AwesomeWM anyway. Proprietary drivers I don't need, my laptop seems to work with open-source stuff just fine. | 10:05 |
| suavedandy | Which is surprising, to say the least. | 10:05 |
| suavedandy | I have an Intel network card so… Yeah, iwlwifi. | 10:06 |
| suavedandy | Although I do see the message that some proprietary drivers are needed while installing. And they are related to iwlwifi. | 10:08 |
| suavedandy | Maybe false alarm but I don't know. | 10:08 |
| danuan | nonfree from repos will do 80 - 90% of things when free doesnt work or wont work properly , other 20 10 % you will need to just download from manufacturer | 10:09 |
| danuan | sometimes they work , like say a gigabit network card on an asrock mb only functions as 100mb on free drivers | 10:09 |
| danuan | or nvidia cards , if you want full acceleration in all situations , its nvidia drivers beats free almost always for me , but they are finiky and dont always play nice | 10:12 |
| suavedandy | Like a work laptop has a graphics card. | 10:13 |
| suavedandy | Also, regarding Awesome. I also wanted to try InstantWM due to cool anims but it seems that it's only available on InstantWM which is Arch and in beta. | 10:14 |
| suavedandy | I mean, I could've installed DWM… | 10:16 |
| suavedandy | Or SpectrWM. | 10:16 |
| suavedandy | Also, did the Debian team start making point releases faster? Buster was released quicker. In a year. | 10:20 |
| gnarface | they've never had incentive before | 10:23 |
| gnarface | now they do | 10:23 |
| gnarface | (us) | 10:23 |
| gnarface | they know they have the funds to outrun us | 10:23 |
| gnarface | but it is more work for them too so i'm sure it's a existential crisis for them :-p | 10:24 |
| danuan | i always liked used cars , you know they are good after someone broke them in for you , after 100k miles things just run smoother | 10:25 |
| danuan | :0 | 10:26 |
| suavedandy | Has anybody tried Star? | 10:37 |
| suavedandy | One of the Devuan derivatives. | 10:37 |
| suavedandy | It says "Backports enabled by default." Whatever it means. | 10:41 |
| suavedandy | I mean, if they're talking about the repo then it's not hard. You open your sources.list and add beowulf-backports. | 10:42 |
| user____ | ping fsmithred | 16:59 |
| fsmithred | ? | 16:59 |
| user____ | Hi. I had an unscheduled power outage today on beowulf, came back nicely, but the clock is out. One hour back, i.e. un-set the DST switch which occurred a few days ago normally. | 17:00 |
| user____ | Is this somehow related to my running BIOS clock on localtime? With suitable setting in adjtime ? | 17:00 |
| fsmithred | maybe | 17:01 |
| fsmithred | you're dual-booting windows? | 17:01 |
| user____ | I am multi booting other things too. Need it on localtime. | 17:02 |
| user____ | EET should be Eastern European Time UTC+3 but it gives me AM/PM. What the. | 17:02 |
| fsmithred | this is on a desktop clock? | 17:03 |
| user____ | cli root | 17:04 |
| user____ | desktop follows that too | 17:04 |
| user____ | what's the debianism to set the tz again? debconf-something? | 17:05 |
| r3boot | dpkg-reconfigure tzdata | 17:05 |
| user____ | was set correctly, and it claims it's 18:06:19 EET which is correct | 17:06 |
| user____ | But date shows the wrong time | 17:07 |
| user____ | iow system date and time are okay but date shows something like Thu 29 Oct 2020 06:07:02 PM EET -- should be 24h time no PM | 17:07 |
| koollman | that's date formatting, not timezone/dst, I think | 17:07 |
| koollman | depends on locale settings | 17:08 |
| user____ | TZ was unset, setting export TZ=Europe/Bucharest -> same outcome, wrong | 17:08 |
| user____ | env|grep (LOCALE|LC) -> nil | 17:08 |
| user____ | In the C locale which should be default, 24hr "military" time should be the default, no? | 17:09 |
| koollman | you would think so, but no. american defaults :) | 17:09 |
| user____ | uhh. US military time is 24hrs no AM/PM | 17:10 |
| gnarface | there is a way to set it to local time | 17:10 |
| koollman | although I do wonder what should be default on my system. Maybe C local isn't used ? | 17:10 |
| gnarface | default puts the bios in UTC | 17:10 |
| gnarface | there is also a way to make windows UTC aware | 17:10 |
| gnarface | some registry edit | 17:10 |
| user____ | This used to work fine on ascii. I assume someone in USA edited the TZ files and got careless with defaults. I'm probably on Oklahoma "standard" time or something as a result. | 17:11 |
| gnarface | the "locale" command outputs the locale environment variable settings, env won't list them by default | 17:11 |
| koollman | user____: LC_ALL=C date | 17:11 |
| user____ | yep that fixed it koollman, thanks | 17:12 |
| gnarface | the other possibility is that you lost that data because it was the last thing set before your hard power loss and the disks hadn't synced yet | 17:12 |
| user____ | LC_ALL was unset as reported by locale | 17:12 |
| user____ | gnarface: no, it was days ago | 17:12 |
| koollman | user____: so wrong local set somewhere, and date checks that somewhere if no local env variable set | 17:12 |
| user____ | It is safe to put LC_ALL in root's .profile ? | 17:12 |
| gnarface | you should be able to just run "dpkg-reconfigure locales" | 17:12 |
| koollman | user____: locale -a, to list known locales, locale, to see currently used one | 17:12 |
| gnarface | set it to what you want | 17:12 |
| user____ | No, it's all en_US.UTF-8 but LC_ALL was unset which is likely the root config mistake propagated from upstream | 17:13 |
| user____ | My understanding is, LC_ALL should default to C when unset. | 17:13 |
| user____ | Subtle bit rot propagation there. I can't be sure the ascii LC_ALL was also unset or set to C, since I never looked. | 17:13 |
| koollman | if it is all en_US.UTF-8, then you very likely end up with american-looking time format | 17:13 |
| user____ | LC_PAPER="en_US.UTF-8" O.o | 17:14 |
| user____ | Yeah I need to look into this a bit | 17:14 |
| user____ | In the 1st place, why would root need any locale other than C? | 17:14 |
| user____ | Must make for real fun in scripts and such having the "wrong" surprizing locale in a remote connected server in another country because muppets decided to translate all messages and locale defaults to the local patois. | 17:15 |
| user____ | This is a gnu-ism. Clearly. Almost Poettering class gnu-ism. | 17:15 |
| gnarface | nah even happens in mysql | 17:16 |
| gnarface | welcome to the post unicode world | 17:16 |
| gnarface | you just gotta get your locales right now | 17:16 |
| user____ | Anyone here on beowulf who can confirm their root account is on en_US.UTF-8 while other accounts are on other locales? | 17:16 |
| user____ | gnarface: yes, the only locale root needs is C, for sanity's sake. | 17:16 |
| user____ | emos who need it spoonfed in their own patois do not need a root account. | 17:17 |
| gnarface | i'm not 100% sure your base assumptions are correct | 17:17 |
| koollman | maybe C.UTF-8 , at least | 17:17 |
| koollman | also, I cannot reproduce your problem yet | 17:17 |
| user____ | koollman: valid | 17:17 |
| gnarface | but i can verify for you that on ascii, beowulf, and ceres, every user gets the locale you set with dpkg-reconfigure | 17:17 |
| MinceR | i thought locale support was required by POSIX | 17:18 |
| koollman | (but I have too many strange envs, I need a nice clean one :) ) | 17:18 |
| user____ | I did a clan beowulf install so nothing changed. | 17:18 |
| user____ | *clean | 17:18 |
| gnarface | first thing that comes to mind is that it's not a guarantee hardware metadata or filenames are 100% latin1 characters only anymore | 17:18 |
| user____ | so, is it safe to put LC_ALL=C in root's .profile or not? | 17:18 |
| koollman | gnarface: it never was | 17:18 |
| user____ | gnarface: UTF8 is a valid upgrade but assuming local patois conventions for numbers and dates is not | 17:19 |
| user____ | Even if the local patois is American English. | 17:19 |
| koollman | I'm not sure what changes the display, though | 17:19 |
| user____ | koollman: try LC_ALL= date | 17:19 |
| gnarface | i wonder if this is just one of those things where you have to change the debconf priority to get it to ask the right questions | 17:20 |
| koollman | user____: I don't have the problem, but I know my envs aren't clean installs. But, to be sure, in your env this gives two different output : LC_ALL=en_US.utf8 date ; LC_ALL=C date | 17:21 |
| koollman | if so, yeah, I would definitely set C or C.UTF8 as my default system-wide locale | 17:21 |
| user____ | Right, so LC_ALL is a shortcut to override all the other settings. | 17:24 |
| user____ | Right, will set it so koollman | 17:24 |
| a1000 | did anyone had install problems with linux-libc-dev recently ? | 17:24 |
| koollman | user____: but you do confirm that those two are different on your beowulf install ? | 17:25 |
| user____ | hm? Yes date output with LC_ALL= defaults to US AM/PM mode; LC_ALL=C.UTF-8 makes it right (24h) | 17:26 |
| user____ | And yes with LC_ALL=en_US.utf8 is't American and the same as LC_ALL= | 17:27 |
| user____ | also locale dumps LC_TIME as en_US etc as above, so, not a surprize. | 17:27 |
| user____ | Trying to find a reference on default POSIX time, pretty sure it is Zulu 24h format, but can't find it. | 17:30 |
| a1000 | POSIX time is Epoch with 0=1.1.1970 0:0 UTC | 17:32 |
| user____ | I've edited /etc/profile + export LC_ALL="C.UTF-8" but for ~/.profile 's I did: export LC_TIME="C.UTF-8" | 17:32 |
| user____ | This is safer in view of whatever else the user needs (I am the only user on this system for now) | 17:32 |
| user____ | a1000: how convenient, no mention of AM or PM -- aha! no mention means 24hrs... | 17:33 |
| a1000 | POSIX simply counts seconds, what you make out of it depends on you, this way you can handle any timezone etc | 17:36 |
| user____ | It also has a "default" date format which is what I was after. | 17:37 |
| user____ | "canonical" date? | 17:37 |
| user____ | https://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html this should be as close as it gets imo | 17:38 |
| user____ | "Otherwise, date shall use the timezone indicated by the TZ environment variable or the system default if that variable is unset or null." | 17:39 |
| user____ | What IS the system default. | 17:39 |
| user____ | Should be C imo. | 17:39 |
| user____ | Pretty terrible standard. Anyway, thanks for the discussion. More items marked for checking on newly set up systems. | 17:41 |
| a1000 | system default here like "implementation dependent", take a look at ISO 8601 | 17:42 |
| user____ | I tried to introduce ISO8601 time at the company I worked for for 12 years in the 1990s-2000s. The boss chewed me out, he could not get used to it. | 17:44 |
| nemo | koollman: hmmm C as a system-wide locale is probably pretty risky nowdays | 17:44 |
| user____ | It was a small company and I was directly under him... | 17:44 |
| user____ | nemo: why? | 17:44 |
| nemo | koollman: UTF-8 is so wide-spread... | 17:44 |
| nemo | user____: C does not support UTF-8 - we discovered this when someone added unicode to our source files | 17:44 |
| user____ | UTF-8 and C are disjoint in the sense of date formatting | 17:44 |
| nemo | and distro compiles failed | 17:44 |
| user____ | oh | 17:44 |
| nemo | user____: I was talking as a system-wide default for LC_ALL | 17:44 |
| user____ | What systems? gnu? | 17:44 |
| nemo | which is not just date | 17:44 |
| user____ | Well now C.UTF-8 seems to be supported? | 17:45 |
| nemo | user____: major distros, Fedora and Debian, failed to compile our source code because their build servers used a locale of C | 17:45 |
| nemo | ok. that's different | 17:45 |
| user____ | When? | 17:45 |
| nemo | user____: just a few months ago | 17:45 |
| nemo | hm. last fall maybe actually | 17:45 |
| nemo | last release | 17:45 |
| nemo | had to do emergency rereleases | 17:45 |
| user____ | Interesting. Buster/beowulf or before? | 17:45 |
| nemo | I'm just saying it's a dangerous default | 17:45 |
| nemo | user____: after buster | 17:45 |
| user____ | nemo: thanks for sharing that | 17:45 |
| nemo | changed like... '€' or whatever the person had done, to hex escaping | 17:46 |
| * user____ will try some umlauts in C.UTF-8 just to see | 17:46 | |
| nemo | so distro servers could compile | 17:46 |
| nemo | user____: depends on the parser ofc | 17:46 |
| nemo | but a strict C parser isn't aware of UTF-8 validation | 17:46 |
| user____ | Was this in source or filenames? | 17:46 |
| nemo | user____: source code | 17:46 |
| nemo | failed on unicode both in comments and in code | 17:46 |
| user____ | A strict C parser should not do anything at all with non 7 bit ascii | 17:47 |
| user____ | Now failing in comments is bad. | 17:47 |
| nemo | user____: this was a haskell tokeniser doing string validation | 17:47 |
| nemo | user____: I'm saying you can get unexpected results is all | 17:47 |
| nemo | I'm not saying it was C the language in particular | 17:47 |
| nemo | just that as a default weird things might happen | 17:47 |
| user____ | Yes, I can see how that works. Thanks for sharing. | 17:47 |
| nemo | np. and yeah, I think it's just 'cause UTF-8 is becoming so widespread | 17:47 |
| nemo | people just assume it'll be supported. often isn't even defined | 17:48 |
| user____ | It's because emos expect 50 year old langugages to accommodate their all inclusive use of Inuit curses as identifiers. | 17:48 |
| user____ | brb | 17:48 |
| nemo | hehe | 17:48 |
| nemo | user____: well this was in char string 😉 | 17:48 |
| user____ | ᑐᐱᓚᒃ | 17:58 |
| user____ | that's an Inuit curse for you. | 17:58 |
| user____ | LC_ALL=C echo "ᑐᐱᓚᒃ" -> renders correctly on beowulf xfce4-terminal with defaults as installed. I guess we are good. | 18:00 |
| * a1000 has still a problem installing linux-libc-dev on beowulf | 18:12 | |
| user____ | I just tested beowulf's gcc can handle Inuit curses in strings just fine with LC_ALL=C (no specific UTF-8 selected). | 18:15 |
| user____ | You can also try it out yourself: | 18:15 |
| user____ | 82.76.46.34:8080/lc_all-c-utf8-test/ | 18:16 |
| user____ | err there may be a "few" firewalls in between. | 18:16 |
| user____ | ok should work now | 18:19 |
| user____ | I'll termbin it just because the server is not always up / temporary | 18:20 |
| AlexLikeRock | what its the best downloader for firefox (add-ons ) ? | 18:21 |
| user____ | /join #firefox is the best downloader | 18:22 |
| xrogaan | Is the individual sending on the ML from @d404.nl here? | 18:54 |
| user_____ | re: discussion earlyer: Inuit curses and other UTF-8 in C source: I uploaded the test I made and ran on Beowulf, am curious if there's someone whose system fails this test? https://termbin.com/17f8 | 21:46 |
| user_____ | <aside>I love the glyphs the Innu language(s) use(s), they are absolutely great looking. | 21:48 |
| nemo | user_____: I wouldn't expect that to fail personally | 21:48 |
| nemo | user_____: our problem was, as noted, with haskell | 21:49 |
| nemo | when LC_ALL=C the string tokeniser did 7 bit validation | 21:49 |
| user_____ | Well you were the one who said it fails sometimes (potentially). I have no way to know what Haskell does with UTF-8, but I am surprized C handles the gibberish so well. | 21:49 |
| nemo | as opposed to LC_ALL=en_CA.UTF-8 or whatever *.UTF-8 that all the devs had been testing with before we threw it over the wall to the distros | 21:49 |
| nemo | user_____: yeah. C is blind to it | 21:49 |
| user_____ | I had half expected a warning about non ascii or binary data in a literal string. | 21:49 |
| nemo | user_____: what I had been saying was that if you set your system *default* to LC_ALL=C used by ALL apps | 21:50 |
| nemo | you might get surprising behaviour these days | 21:50 |
| nemo | user_____: just because UTF-8 support is becoming increasingly assumed | 21:50 |
| user_____ | If you look at my upload you'll see it builds with LC_ALL=C forced upon the compiler | 21:50 |
| nemo | if you set en_US.UTF-8 and someone else wrote fr_FR.UTF-8 content, it'll still work | 21:50 |
| nemo | user_____: I saw that. that was not my point at all | 21:50 |
| nemo | my point was SOME things might break | 21:50 |
| nemo | gcc not breaking is not surprising to me | 21:50 |
| user_____ | Well it is mine since I did not set C.UTF-8 just C | 21:50 |
| nemo | I know | 21:50 |
| nemo | to repeat | 21:50 |
| user_____ | Okay, I get your point. | 21:51 |
| nemo | if you set it SYSTEM wide | 21:51 |
| nemo | soem things. not gcc. might break | 21:51 |
| nemo | had no other purpose in warning than that, based on our experience | 21:51 |
| nemo | and it used to be fine. this is just a confluence of recent events I think | 21:51 |
| user_____ | And thanks for sharing it. I had to try it out of course. Am interested if there is anyone whose system does NOT compile & render that right. Devuan any version, but also others. | 21:51 |
| nemo | user_____: here. let me give you the precise details 😃 I'll dig up the commits and bug report | 21:52 |
| nemo | https://issues.hedgewars.org/show_bug.cgi?id=725 | 21:52 |
| nemo | this issue seems to summarise nicely | 21:52 |
| user_____ | reading, thanks. | 21:52 |
| nemo | I was definitely surprised by it when it happened as you can see | 21:52 |
| nemo | I mean it was absolutely our fault.. | 21:53 |
| user_____ | Sure. Also good you talked about it. | 21:53 |
| user_____ | AHA, FreeBSD. There is the error :) | 21:54 |
| nemo | heh | 21:54 |
| nemo | we had same issue on Debian too | 21:54 |
| nemo | later | 21:54 |
| user_____ | Sure, kidding. | 21:54 |
| user_____ | tbh, I wrote some little grammars for flex+bison and modified other people's and I'd very much (VERY MUCH) not accept arbitrary bytes as valid input anywhere, not even in comments probably, certainly not in strings. | 21:56 |
| user_____ | My work/hobby targets embedded mcu's and there is no room for such things in there. Every byte value has special meanings and non ascii characters certainly have such more often than not. | 21:57 |
| user_____ | So I'm surprized gcc liked my Innuit destroying monster. And sort of ate it :) | 21:57 |
| user_____ | hedgewars is a game written in Pascal I gather? | 21:59 |
| user_____ | Or is that Haskell | 21:59 |
| Wonka | pascal. | 21:59 |
| user_____ | tbh I found plenty of non ascii comments in C code over the years and there was never a problem. Router firmware is full of it, Russian, Asian, you name it. | 22:00 |
| user_____ | the glyphs I referred to above, a lot of them are here https://omniglot.com/writing/ucas.htm | 22:01 |
| user_____ | nemo: but nobody was daring enough to use Hangul variable names or the like (Hangul = South Korea) | 22:02 |
| user_____ | I know for a fact that won't work in any decent parser in use now. | 22:02 |
| Wonka | https://en.wikipedia.org/wiki/Inuktitut_syllabics | 22:04 |
| Wonka | https://docs.python.org/3/reference/lexical_analysis.html#identifiers says Python 3 allows quite a lot more than ascii for identifiers | 22:06 |
| nemo | Wonka: most interpreted languages do | 22:07 |
| nemo | Wonka: rakudo goes to extremes | 22:07 |
| nemo | https://docs.raku.org/language/unicode_entry | 22:07 |
| nemo | javascript allows it too | 22:07 |
| nemo | https://m8y.org/tmp/sdk.html a test I did long long ago | 22:08 |
| user_____ | ouch. | 22:28 |
| user_____ | well I know for a fact it won't work in any decent parser for C or similar languages (C dialects etc). re: above statement. | 22:28 |
| user_____ | Anyway, keep it on topic. Any specific languages in use on devuan installs which require special care with UTF-8 enabled to work well? | 22:29 |
| nemo | user_____: I suspect rather the opposite these days | 22:40 |
| nemo | apps failing in C mode is more common | 22:40 |
| user_____ | Well I have the grammars in view, flex+bison source. I assure you the identifiers and function names WILL be ascii only, 7 bit | 22:41 |
| nemo | user_____: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874160 the discussion in this bug might point to potential problems? | 22:42 |
| nemo | user_____: seems to have been a patch to make "C"="C.UTF-8" | 22:42 |
| nemo | people bringing up positives and negatives of such a default | 22:43 |
| nemo | negatives seem mostly about assumptions of C | 22:43 |
| * user_____ is scared by the number of things and code(s) which fail reporting success lately | 22:43 | |
| user_____ | Well once wchar_t is a thing, ascii is no longer a thing. I mean Asian non-UTF encodings probably. | 22:46 |
| user_____ | UTF does try to solve a lot of problems and it works nicely but things like lexicographic sequences, collation, and string length assumptions based on glyph count are all off the scale. | 22:47 |
| clort | utf8 you mean | 22:55 |
| user_____ | yes | 22:59 |
| user_____ | utf16 is I think wchar_t territory, never used it. | 22:59 |
| clort | windows world | 23:43 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!