| systemdlete | like I said, this is mainly so that I can test my installation process without having to ding the devuan mirrors repeatedly. | 00:02 |
|---|---|---|
| gnarface | yea, it's great for that | 00:02 |
| systemdlete | that was my original aim. But now I see that my local VMs and hosts could use this also... | 00:03 |
| systemdlete | and they are! | 00:03 |
| micdud | anyone have issues installing task-desktop or task-xfce-desktop with aptitude in daedalus ? used to be able to just select and install | 00:13 |
| micdud | now for some reason i get too many dependency issues | 00:14 |
| gnarface | micdud: are you missing daedalus-security or daedalus-updates from your sources.list perhaps? | 00:18 |
| micdud | nope, i just used to be able to do it in one shot , not it takes 2 or 3 to get full desktop installed | 00:19 |
| gnarface | oh, i can't say then what's up. i'm not using it. some people here are though, so stick around. someone might know. | 00:20 |
| micdud | i install very minimal for initial install or bootstrap, and then like to aptitude my way to desktop / deselecting all the anoying extras like avahis at2-spis etc... | 00:23 |
| plasma41 | micdud: Run 'apt-get update' first? (or press 'u' in aptitude) | 00:23 |
| micdud | yes | 00:24 |
| plasma41 | micdud: Can you run 'apt-get install -s task-xfce-desktop' and share the output via a pastebin? | 00:26 |
| micdud | https://pastebin.com/x5D3990y | 00:31 |
| micdud | but apt or apt-get is not the problem , i do not want to install everything and then remove , leaving all the leftovers | 00:32 |
| micdud | i like to aptitude and deselect all the crud before it is installed | 00:32 |
| systemdlete | gnarface, the retrieval portion of debootstrap is certainly faster. MUCH faster. 142 debs in about 1 or 2 seconds | 00:32 |
| gnarface | systemdlete: hooraaay! | 00:33 |
| systemdlete | but the overall run time, last trial, took almost 50 minutes, which is a 25% increase. | 00:33 |
| systemdlete | I'm trying again | 00:34 |
| gnarface | systemdlete: where it really shines is if you're doing a bunch at once and you'd otherwise be constrained on upstream bandwidth | 00:34 |
| systemdlete | it is a godsend in any case. | 00:35 |
| systemdlete | But I need to see why the overall process is taking longer now. | 00:35 |
| systemdlete | my debootstrap is downloading 142 packages | 00:35 |
| micdud | <plasma41> , got it , it was remove libsystemd0 and install liblogind0 manualy , before doing task-xfce-desktop , then everything seems to work like before | 00:38 |
| micdud | not sure why it was tripping up aptitude, and had to be done in 2 steps | 00:40 |
| plasma41 | micdud: It could be that aptitude is configured to not propose dependency resolutions that require removing packages. I'd have to investigate further to be sure. | 00:42 |
| systemdlete | is there a tool that can take a specified list of packages and display a complete dependency chart or listing? For this, I would only need dependencies, not suggests or remcommends | 03:46 |
| systemdlete | recommends | 03:46 |
| systemdlete | apt depends can do some of this, but I'd like to be able to specify a list of packages I want to install, including pkgs I want to exclude (e.g., nano- avahi-daemon- etc) | 03:47 |
| systemdlete | I can write a script to do this, but I'm wondering if, after 30 years or so, someone already did this. | 03:47 |
| gnarface | systemdlete: dselect maybe? | 04:01 |
| systemdlete | is that graphical or command line? | 04:01 |
| systemdlete | nvm I'll check it out | 04:01 |
| gnarface | systemdlete: ncurses | 04:02 |
| systemdlete | tui then, ok | 04:02 |
| systemdlete | can I pass it a list of package names? | 04:03 |
| plasma41 | systemdlete: debtree will generate a graph for a single package. You might be able to cobble together a script that merges multiple graphs. | 04:03 |
| systemdlete | I don't just want to see dependencies of one package | 04:03 |
| systemdlete | I think I'll just cobble something from scratch, completely. Use apt-cache or apt | 04:04 |
| systemdlete | no point trying to fight ncurses with shell redirections, etc | 04:04 |
| systemdlete | (unless there is some option to get around that) | 04:04 |
| gnarface | i dunno | 04:04 |
| systemdlete | that's ok, I appreciate your help | 04:05 |
| gnarface | i am not sure it's actually ncurses, just looks like it | 04:05 |
| systemdlete | it is | 04:05 |
| systemdlete | I just tried it | 04:05 |
| gnarface | it used to be the default package manager, but it got demoted for being too complicated | 04:05 |
| plasma41 | debtree produces graphs in GraphViz's 'dot' text format. | 04:05 |
| plasma41 | TIL about gvpr(1), "a graph stream editor inspired by awk" | 04:09 |
| systemdlete | so a programming question. Most of the libraries that get installed are shared objects, not static, right? | 04:39 |
| systemdlete | if so, a program would crash if a shared library was requested by a program that had not been installed. | 04:40 |
| systemdlete | but so long as any program did not ever request an object from that library, then the program would not crash. | 04:40 |
| systemdlete | (shouldn't) | 04:40 |
| systemdlete | if what I say is accurate (generally speaking), then why does a dependency of an xfce4 plugin have to have the shared libraries for it installed (unless some other program depended on it and was really going to use them) | 04:41 |
| systemdlete | I have specified that I do not want to install xfce4-sensors-plugin in a VM because... well I guess that doesn't make much sense to me, unless the VM is monitoring some hardware on the host | 04:42 |
| systemdlete | yet | 04:42 |
| systemdlete | apt wants to install libsensors and libsensors-config anyway. | 04:43 |
| systemdlete | Maybe I was sleeping during the shared libraries module of the 2 kernel internals classes I took years ago. | 04:43 |
| systemdlete | idk | 04:43 |
| systemdlete | or maybe I misunderstood the whole purpose of them (other than sharing resources in those earlier, limited ram and limited disk systems) | 04:46 |
| systemdlete | I thought the idea was to load shared object upon demand. | 04:46 |
| systemdlete | at least, I think that is how Amdahl UTS and SunOS and even AT&T Unix did it. But I might be mistaken. | 04:47 |
| mason | systemdlete: Try it. Pretty sure you can't run a program with a missing shared library. | 04:47 |
| systemdlete | did you read all of what I wrote? | 04:47 |
| mason | Exception would be dlopen() but there's nothing to do about that. | 04:47 |
| mason | systemdlete: I started with "so a programming question." | 04:47 |
| mason | systemdlete: Re-read my answer, as it might shed light on some behaviour you see. | 04:48 |
| systemdlete | what is to re-read? It was one sentence (unless my IRC client cut out on me) | 04:48 |
| systemdlete | <systemdlete> but so long as any program did not ever request an object from that library, then the program would not crash | 04:49 |
| systemdlete | mason, as I said, I've been to Unix internals classes twice. One was a two-week class and went deep into kernel details, such as how ldload (or equivalent) works. | 04:50 |
| systemdlete | but maybe you know something I don't. | 04:50 |
| mason | systemdlete: Evidently. | 04:50 |
| systemdlete | shared objects do not HAVE to be linked at run time if they are not needed | 04:51 |
| mason | systemdlete: Rather than theorizing, go try it please. | 04:51 |
| systemdlete | think about the hundreds of shared objects and the programs that call them | 04:51 |
| mason | Once you've tried it, come back and we can talk about corner cases. | 04:51 |
| systemdlete | most programs do not call anywhere close to all the shared objects. | 04:51 |
| systemdlete | try what? | 04:51 |
| mason | Try running a binary with a missing shared library. | 04:52 |
| systemdlete | oh I know that the way things exist might be the case, but what I am saying is that it is a missed opportunity | 04:52 |
| systemdlete | when you say "missing" what do you mean? | 04:52 |
| systemdlete | that's what I am getting at--they are not "missing" really if they are not really needed | 04:52 |
| mason | 22:40 < systemdlete> if so, a program would crash if a shared library was requested by a program that had not been installed. | 04:52 |
| mason | To which I'm saying, you can't do it. You can't run a program with a missing library. | 04:53 |
| mason | Now, if you want to be flexible about what you might need, I covered that too by noting dlopen(3) | 04:53 |
| systemdlete | so if a binary compiiled for, say, the libsensors library has externals in its binary | 04:53 |
| mason | systemdlete: Try it please. Quicker and more enlightening. | 04:53 |
| systemdlete | then at run time, at some point, the routines in that shared library would be called by the program | 04:53 |
| mason | No, it's checked before runtime. | 04:54 |
| systemdlete | mason, honestly I don't think you see the point I am making. | 04:54 |
| systemdlete | what is checked? | 04:54 |
| mason | Anyway, this isn't really a Devuan support question. | 04:54 |
| systemdlete | well, I was questioning the packaging, that's why I asked it here | 04:54 |
| mason | And I answered you. | 04:54 |
| systemdlete | but never mind, this is not helpful. | 04:54 |
| mason | Agreed. | 04:55 |
| systemdlete | no you did not bc you did not understand my question | 04:55 |
| mason | That's unlikely. | 04:55 |
| systemdlete | but thank you anywqay for trying to elucidate | 04:55 |
| systemdlete | why is it unlikely? | 04:55 |
| systemdlete | it is clear to me that you do not understand how Unix kernels (generally, maybe not linux, idk) arrange for shared objects to be loaded at run time | 04:56 |
| systemdlete | or I should say | 04:56 |
| systemdlete | how the linkage for he routines they call are linked in at run time | 04:56 |
| systemdlete | but maybe linux works differently than unix kernels, which would surprise me | 04:56 |
| mason | systemdlete: And yet, you won't try poking the system to observe the behaviour you're questioning, where not only did I tell you how it works, but I took the time to actually run a test to verify I wasn't confused early in the conversation. | 04:57 |
| systemdlete | I am NOT questioning the behavior. I see it. | 04:57 |
| mason | My test reacted precisely as I expected, and then I described how it can be more flexible with dlopen() | 04:57 |
| systemdlete | the package tools (and maybe the way the libraries are linked) seem to require them, yes. | 04:57 |
| systemdlete | ok thank you | 04:57 |
| mason | Are you talking about a tree-shaker? Go read about tree-shakers and why they aren't seen in the wild ever. If you're talking about something else, state it clearly and don't make insulting observations that highlight that you're not reading the answers you're being given. | 04:58 |
| systemdlete | I did not come here for a fight, but I see you did. | 04:58 |
| systemdlete | byeeeeee! | 04:58 |
| mason | I'm certainly not going to waste more of my time answering questions from you in future. | 04:58 |
| mason | Ah, too alte. | 04:58 |
| mason | late | 04:58 |
| debdog | prolly his time of the month | 04:59 |
| mason | Eh, I engaged. My fault too. | 05:00 |
| mason | If it turns out I actually did miss the question somehow, I'd love to know about it fwiw. | 05:00 |
| debdog | no, I am not a developer but I have come to the same conclusion. a prog won't run if it fails finding a lib at startup | 05:01 |
| mason | Right. For example: flac: error while loading shared libraries: libogg.so.0: cannot open shared object file: No such file or directory | 05:02 |
| debdog | at least that is my experience from compiling fgfs throughout the years | 05:02 |
| mason | Hrm, if I were a bit sharper I'd have recommended exploring LD_PRELOAD as that might have been more enlightening still. | 05:03 |
| debdog | but by now we should know he is very sensitive, maybe we could have that in mind in the future. but then, we're not all nativ speakers here and misunderstangs occur | 05:05 |
| debdog | IDK | 05:05 |
| mason | Yeah, I was more prickly then was required. | 05:07 |
| mason | Being told that I didn't understand something I'd just explained is a good test for me. :P | 05:07 |
| golinux | Ah mason . . . | 06:00 |
| mason | Mm. | 06:01 |
| mason | Not yet perfect. | 06:01 |
| golinux | What is all this fuss . . . | 06:01 |
| golinux | Clash of the titans maybe??? LOLOLOL! | 06:02 |
| mason | No, just trying to answer a question, and having the answer ignored repeatedly. | 07:24 |
| rrq | yeah, few things trigger soul-searching as much as having the answer ignored repeatedly | 08:16 |
| mason | rrq: Indeed, it's a flag for "I'm missing something critical about this interaction." | 15:56 |
| djph | ouch. :( | 16:04 |
| mason | Meanwhile, in the real world, things are about to get all the more exciting: https://salsa.debian.org/systemd-team/systemd/-/commit/a472248799d13d3f826653f61def2aef4765edd4 | 16:07 |
| bb|hcb | mason: sadly, yes | 16:10 |
| djph | ... they removed the sysv initscript for udev? | 16:24 |
| mason | djph: It's part of their removing their sysvinit compat entirely. | 16:36 |
| mason | Which is to say, win through violence rather than through technical superiority. | 16:37 |
| djph | yeh :/ | 16:39 |
| bb|hcb | Not really violence, that relies on people's laziness to push them on the easier path | 16:45 |
| mason | bb|hcb: There is vocal opposition inside the project. | 16:57 |
| gnarface | can one of you guys can make sure that script gets put in the orphaned init scripts package asap? | 16:59 |
| mason | gnarface: Already happening, per #debian-init. | 17:00 |
| gnarface | oh good. at this point i'm thinking it would be a safe bet to just go ahead and make the orphaned init script package actually just preemptively hold a copy of all of them | 17:00 |
| djph | wish I was better at this kind of stuff and could actually provide help to the project :/ | 17:02 |
| bb|hcb | To be more precise it is not going in orphan-sysvinit-scripts but initscripts instead | 17:08 |
| mason | Right, right, thanks for the correction. | 17:16 |
| bb|hcb | And usrmerge is starting to byte in unstable: /etc/grub.d/25_bli has #!/usr/bin/sh | 18:09 |
| YKaelig | Hello | 18:24 |
| YKaelig | Insane ... :D | 18:24 |
| YKaelig | Well, nvidia-settings-470.199.02 done and packaged | 18:24 |
| YKaelig | Next ... | 18:24 |
| gnarface | is it working? | 18:25 |
| YKaelig | It took me 6 hours to understand and regroup all the debian mess and get my debs | 18:26 |
| YKaelig | Still I don't know I have to package now nvidia-modprobe and nvidia-persistenced | 18:26 |
| gnarface | you can omit nvidia-persistenced | 18:27 |
| YKaelig | But now I have the model which I can apply to these sources | 18:27 |
| gnarface | it's optional and usually it's broken | 18:27 |
| YKaelig | ok | 18:27 |
| YKaelig | Deconnected | 18:33 |
| gnarface | you didn't miss anything | 18:35 |
| YKaelig | ok. There are a lot of interesting debian tools but it's very difficult to understand how they work behind the scene. For example uupdate is interesting, but the software create a debian.upstream directory and I don't need it because I already have the debian directory. No idea how to disable this feature. So instead I'm creating the orig tarball | 18:40 |
| YKaelig | manually | 18:40 |
| YKaelig | After that dpkg-buildpackage can finish the work. | 18:41 |
| YKaelig | I have everything on my note, so it will be possible to reproduce the work for those how are interested | 18:41 |
| YKaelig | how/who | 18:41 |
| YKaelig | Good. nviidia-modprobe done. That was quick now :) | 19:03 |
| YKaelig | Soo. Time to send all of that in the repository and see how it looks | 19:04 |
| gnarface | good luck, i'm anxiously awaiting your results | 19:05 |
| gnarface | next you can help me fulfill my dream to bring 525.xxx to devuan beowulf :-D | 19:06 |
| YKaelig | What the difference between : mk-build-deps --install --remove AND apt-get build-dep ? | 19:31 |
| YKaelig | And which one should be used | 19:32 |
| fsmithred | I've only ever used apt-get build-dep | 19:32 |
| gnarface | dunno, i alwyas "apt-get build-dep" but inevitably it's missing a couple things | 19:32 |
| gnarface | (usually bison/yacc) | 19:32 |
| gnarface | (among others) | 19:32 |
| YKaelig | ok. Also I tried to understand the --remove option from the man page but I can't. | 19:33 |
| bb|hcb | mk-build-deps builds a package that depends on the stuff. then installs it. if --remove, then removes the package file | 19:35 |
| bb|hcb | apt build-dep will directly install the dep packages | 19:35 |
| YKaelig | Sorry bb|hcb but still I do not understand. Do you mean that mk-build-deps is not installating the packages deps in my system but somewhere else ? How is that possible to install then remove. If it's removed it is not anymore installed ? | 19:38 |
| YKaelig | So when is it removed ? | 19:38 |
| gnarface | YKaelig: i just scanned the man page for mk-build-deps. i understand the distinction now; it actually is for building packages then installing them in one step. "apt-get build-dep" just retrieves already-built packages from the repo. | 19:42 |
| YKaelig | I'm unable to find a documentation about how mk-build-deps works. Not a man page but a real documentation that explain the thing | 19:42 |
| gnarface | i don't think you actually need it | 19:42 |
| gnarface | for mk-build-deps, "--remove" is talking about removing the local copy after it's installed | 19:43 |
| gnarface | but "apt-get build-dep" doesn't make a local copy before installing, so that step is irrelevant | 19:43 |
| bb|hcb | Not exactly, mk-build-deps will build one empty .deb package that depends on the packages in the dependency list of what you are trying to build | 19:44 |
| bb|hcb | It will install it (that will pull the packages) and then remove it | 19:44 |
| gnarface | YKaelig: you familiar with "xz -k ..." ? it's like that if "-k" were the default | 19:44 |
| YKaelig | gnarface This is what I have understood, but that seems impossible that mk-build-deps is bulding the deps. It is too quick and he is askling me to install a lot of .deb packages when I tried the things on nvidia-driver | 19:46 |
| YKaelig | Do you mean building as building from source ? | 19:46 |
| gnarface | YKaelig: well maybe what it's building is just a meta-package like bb|hcb says. | 19:46 |
| gnarface | though from the man page i don't see that as a strict requirement, bb|hcb probably knows more about it than i | 19:47 |
| YKaelig | ok | 19:47 |
| gnarface | anyway, i've never needed it, it's probably there just to make your life easier, and if it's not feel free to avoid it | 19:47 |
| YKaelig | I understand now. | 19:48 |
| YKaelig | thx bb|hcb didn't see your answer before | 19:48 |
| bb|hcb | If you do a manual package build, just stick to 'apt build-dep' ;) | 19:50 |
| YKaelig | If I don't want to pollute my system by these packages needed for the build is there any other method, like apk package manager can do but for debian/devuan ? | 19:50 |
| bb|hcb | I use sbuild | 19:50 |
| bb|hcb | There are a few others | 19:51 |
| bb|hcb | https://wiki.debian.org/sbuild | 19:53 |
| YKaelig | thank , ye sI'm on it :) | 19:53 |
| bb|hcb | e.g. create unstable chroot: sbuild-createchroot --include=eatmydata,ccache,devuan-keyring unstable /srv/chroot/unstable-amd64-sbuild http://deb.devuan.org/merged --arch=amd64 --keyring /usr/share/keyrings/devuan-archive-keyring.gpg | 19:56 |
| bb|hcb | also add ,devuan-lintian-profile after devuan-keyring | 19:57 |
| bb|hcb | And to build, from the package dir: sbuild -A -s -d unstable --source-only-changes | 19:57 |
| bb|hcb | HTH | 19:57 |
| gnarface | YKaelig: i just build in a chroot, then delete the chroot when i'm done with it | 19:58 |
| bb|hcb | BTW. That is not enough to enable eatmydata, that and/or tmpfs will make the builds significantly faster | 19:59 |
| bb|hcb | gnarface: This is what sbuild does. But it will keep the chroot clean and discard all changes after each build | 19:59 |
| gnarface | hmm, neat | 20:01 |
| bb|hcb | ... and for Devuan's packages, you can use that: gbp buildpackage --git-ignore-new --git-builder='sbuild -A -s -d unstable -c unstable-riscv64-sbuild --source-only-changes --no-run-lintian' && lintian --pedantic --no-show-overrides --tag-display-limit=0 -E -I | 20:03 |
| bb|hcb | s/riscv64/amd64 | 20:04 |
| bb|hcb | The above will do all the magick | 20:04 |
| YKaelig | Which option should I use with dch when I'm taking nvidia-driver from devuan chimeara and ebuilding it for devuan deadelus | 20:20 |
| YKaelig | I know it's not very important for a local build but it there an official devuan rule for that ? | 20:21 |
| gnarface | there's some rules but i don't know what they are exactly | 20:23 |
| gnarface | but it will enforce you putting something there, in a specific format | 20:23 |
| bb|hcb | YKaelig: I'd use 'dch --bpo' and edit the version afterwards - the idea is to produce a version that is newer than the one in the repos but definitely older than the same version that can come from the next release (so called not breaking the upgrade path) | 20:31 |
| YKaelig | Arf... :D. That was my first idea but after I read that a backports is from testing -> stable it didn't seem like the right choice | 20:34 |
| bb|hcb | e.g. if current ver is 1.2-3, its backport to previous release will be 1.2-3~bpoXX+1, so you use 1.2-3~abcXX+1. Note that abc may be anything that starts with a, so it sorts between the current ver and the possible official backport | 20:34 |
| bb|hcb | BTW. I see no point in building something from chimaera for daedalus? Or I may be missing what you are trying to do? | 20:36 |
| YKaelig | I'm building nvidia-driver for daedalus but anyway, it's not important I used --nmu with a rebuild for devuan daedalus as comment | 20:37 |
| YKaelig | I will never be an official devuan maintainer so I leave that work for others :D | 20:38 |
| YKaelig | I just want my nviidia-driver for my GPU and maybe in a futur I will try to package dinit and S6/66suite. | 20:41 |
| YKaelig | deb and rpm package management are not my cup of tea. Even creating ebuilds are easier ^^ | 20:43 |
| gnarface | bb|hcb: the thing you're missing is the context of what NVidia has been doing with their driver updates (strategically bugging old versions to force hardware upgrades) | 20:58 |
| gnarface | well, strategically bugging old AND new versions in tandem, really | 20:58 |
| gnarface | they make sure that the new version refuses to work for older devices, but they also make sure the older version refuses to work on newer distro releases. (they also do this in lock-step with major game version releases from several major publishers, most notably including Blizzard) | 20:59 |
| gnarface | YKaelig is doing God's work here | 21:00 |
| gnarface | nobody else behaves like this. in a normal situation there'd be no reason not to just expect the newer driver and kernel to keep working | 21:00 |
| bb|hcb | You mean that old card does not work with the new driver? Ugh... | 21:00 |
| * bb|hcb didn't read the backlog... | 21:01 | |
| gnarface | yep, they have scheduled deprecation, they announce it months to years in advance. they don't even say "woops" they're completely up-front that they're turning all their old hardware into paper weights on a pre-determined schedule. | 21:01 |
| gnarface | that said, if YKaelig actually succeeds at making this work i'll be shocked. i've always assumed that nobody else has been doing this because NVidia must have somehow managed to make the driver fundamentally incompatible with major components of the newer distro releases... if all it takes is a rebuild of the packages this is pretty big news for everyone with older nvidia hardware. | 21:03 |
| gnarface | (probably would have saved me from switching to AMD a couple years ago, in fact. but i have no regrets.) | 21:03 |
| bb|hcb | Got it... Just checked and I also have nvidia on my desktop | 21:04 |
| gnarface | the 600 series is the latest one to get the axe | 21:04 |
| YKaelig | bb|hcb That right, the 5xx.xxx serie is only compatible from Geforce series 700 but mine is a GTX660 from the 600 serie... :( | 21:04 |
| gnarface | (my last one was a 500 series) | 21:04 |
| YKaelig | That said I have no issue to build the driver with the last kernel version on Gentoo. | 21:05 |
| gnarface | I'm certain that what NVidia is doing here is illegal actually, but nobody who hasn't already signed one of their NDAs knows enough to testify against them, and nobody in law is smart enough to even notice it happening. | 21:06 |
| bb|hcb | Is 500/600/700 the card model or the driver version? I know nothing (don't want to) about desktop stuff ;) | 21:06 |
| gnarface | bb|hcb: in the context of my previous statements, 500/600/700 here are "families" of nvidia card model | 21:07 |
| gnarface | or "generations" if you will | 21:07 |
| gnarface | somewhat ironically the nouveau website has lots of good information about the breakdown of their models, even if they don't have very good support for most of them still | 21:07 |
| gnarface | here: https://nouveau.freedesktop.org/CodeNames.html | 21:07 |
| gnarface | there's some overlap between major groups, and you can see the marketing numbers are different from the official number designations | 21:08 |
| gnarface | but their actual driver releases are careful to specify all the families that do work with those drivers | 21:09 |
| gnarface | oh, i remember now, i think i was using a borrowed 600 series for a while there but didn't like it because my 500 was actually better at a few key things | 21:15 |
| gnarface | but anyway, yea AMD doesn't pull this crap | 21:15 |
| golinux | I just changed LO writer to web view and now there is only one page break towards the end | 21:25 |
| golinux | There is also a way to increase page size but there is a limit. I'll try that next | 21:25 |
| golinux | Oops . . . thought I was in OT | 21:26 |
| amesser | :) | 21:38 |
| YKaelig | I can not find how the date form is created in the Release file :Date: Fri, 08 Sep 2023 18:08:06 UTC | 21:45 |
| gnarface | that's not something dch sets for you? | 21:45 |
| YKaelig | I can only get Fri 08 Sep 2023 19:42:15 with echo $(date "+%a %d %b %Y %H:%M:%S") and Fri 08 Sep 2023 19:42:15 CEST with echo $(date "+%a %d %b %Y %H:%M:%S %Z") | 21:46 |
| YKaelig | I can not get UTC instead of CEST | 21:46 |
| gnarface | is your bios set to UTC? | 21:47 |
| gnarface | is your timezone set with the tzdata package? | 21:47 |
| gnarface | try echo $(date -u "+%a %d %b %Y %H:%M:%S %Z") | 21:48 |
| gnarface | though, from your initial statement it would actually be echo $(date -u "+%a, %d %b %Y %H:%M:%S %Z") | 21:49 |
| YKaelig | gnarface Ho! that didn't work juste before I tried that | 21:50 |
| YKaelig | goog thx :) | 21:50 |
| gnarface | or i guess more specifically this? echo ":Date: "$(date -u "+%a, %d %b %Y %H:%M:%S %Z") | 21:50 |
| gnarface | no problem | 21:51 |
| YKaelig | Not bad, but I have to "backport" nvidia-persistenced because he is trying to install the 500.xxx package version | 22:14 |
| YKaelig | Everything else look fine | 22:16 |
| YKaelig | BUT, ENOUGH for today ! :D | 22:16 |
| YKaelig | CU tomorrow for the last chapter :D | 22:16 |
| YKaelig | Have a good day/night | 22:17 |
| gnarface | YKaelig: you might not have to build that, i'm pretty sure it's only a Recommend | 22:19 |
| YKaelig | not it's not | 22:20 |
| gnarface | hmm, i've never had a problem running without it | 22:20 |
| gnarface | in fact i've had to remove it before because it was causing problems | 22:20 |
| YKaelig | I believe you, but it's not part of the recommended packages | 22:20 |
| gnarface | admittedly it was a few years ago now so maybe they changed it... | 22:21 |
| gnarface | i thought it had actually come up just recently though | 22:21 |
| gnarface | but i haven't tested it myself for a while now so there's that | 22:22 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!