jaeger changed the topic of #crux to: CRUX 3.7 | Homepage: https://crux.nu/ | Ports: https://crux.nu/portdb/ https://crux.ninja/portdb/ | Logs: https://libera.irclog.whitequark.org/crux/
ukky has joined #crux
<SiFuh_> r0ni: So sad
lavaball has joined #crux
lavaball has quit [Remote host closed the connection]
ppetrov^ has joined #crux
dim44 has joined #crux
<cruxbot> [core.git/3.7]: gzip: update to 1.13
lavaball has joined #crux
ppetrov^ has quit [Quit: Leaving]
dim44 has left #crux [Leaving]
farkuhar has joined #crux
ppetrov^ has joined #crux
dim44 has joined #crux
<dim44> 1) Is there a semi automated way to merge two kernel .config files? 2) Is there a way to test the kernel from a shell before booting it?
<SiFuh_> Merge two together?
<SiFuh_> 2) No
<dim44> Yeah, like merge the .config file that comes with CRUX 3.7 with the one I use now. Do I have to run "make oldconfig" instead?
<SiFuh_> 1) As weird as it sounds to do that you can always diff to compare
<SiFuh_> CRUX 3.7 the .config for the ISO?
<dim44> Yeah, I tried to use mine with latest 6.4.10 kernel and "make oldconfig" and got some problems.
<dim44> Thought I'd just use the 5.15.55 kernel from the iso instead and to make sure that everything would be alright to check the 5.15.55 config for dirrences
<SiFuh_> But you said "Comes with CRUX 3.7".
<dim44> The 5.15.55 one does
<SiFuh_> The one under kernel/contrib/*modular ?
<dim44> hmm, no, after executing the setup script from the iso I got a new folder in /usr/usr/linux-5.15.55
<dim44> And thought that this is the kernel that comes with it
<dim44> */usr/src/linux-5.15.55
<SiFuh_> Yeah but that config you need to edit with menu config
<SiFuh_> So it doesn't come with CRUX 3.7
<SiFuh_> It came from you
<dim44> Is that stock config that was created automatically you mean?
<SiFuh_> Stock config is basically what you get. It is vanilla, raw, unchanged from the archive extraction
<SiFuh_> You can go to kernel.org and download the same kernel tar ball and extract it and it will ahve the same .config in it
<dim44> Ah, ok I thought that it was somehow customized.
<dim44> So I can just use my own .config from my current kernel instead.
<SiFuh_> There is mine under kernel/contrib but it is the modular one, and you would have to copy it over manually
<jaeger> The config that setup installs is NOT unmodified from the kernel source tarball
<jaeger> It's a fairly generic one that supports a lot of stuff
<SiFuh_> jaeger: you replaced it?
<jaeger> Yeah, it's been that way for LONG time
<SiFuh_> Never noticed. Probably because it doesn't really work. :-P
<jaeger> It works on every bit of hardware I own, for what that's worth
<jaeger> Obviously I can't test everyone's config but I *do* test it on whatever I can
<SiFuh_> :-D
<jaeger> It's not meant to have every device out of the box (for example the weird trackpad on my laptop) but it supports a lot of common disk controllers, NICs, filesystems, etc.
<SiFuh_> dim44: forget everything I said above.
<SiFuh_> I was working on a 6.4.4 modular config which I haven't tested yet
<dim44> Do you build the config from scratch every time?
<dim44> I'm thining I'll just append any additions that the 3.7 .config has to my own
<SiFuh_> Usually for me, I just revise but most things stay unchanged unless deprecated. So no, not start from scratch every time. Just update from the older config and see what is new
<dim44> I tried to make one for the 6.4.10 kernel with "make oldconfig" and ended up without a keyboard lol
<SiFuh_> Yeah, random stuff like that happens.
<SiFuh_> Eventually I will move up to the high numbers for now I need to test 6.4.4 first.
<SiFuh_> Welcome to test it for me :-P
<SiFuh_> Should be much difference between 6.4.4 and 6.4.10
<SiFuh_> NOT much*
<dim44> How do you know what is new? Release notes of every kernel?
<SiFuh_> Compile it. It will ask you questions as you go.
<dim44> What? I didn't know about that! It has never asked me querstions until now.
<dim44> Only with "make oldconfig" and there were A LOT of questions
<SiFuh_> If you do run menu config for whatever reason and you 'save' as you exit, then those unknowns will be autoconfigured and you will not be asked during compilation. I prefer to poke around and NOT SAVE then compile
<dim44> Are these the same unknowns the "make oldconfig" command uses or a subset of those?
<SiFuh_> You can test it. Copy your 5.X.X to .config and don't run make menuconfig. Just begin compiling
<SiFuh_> No, the unknowns are unset new entries.
<dim44> I will, also using diff (with grep) on CRUX 3.7's config looks pretty easy to go through.
<SiFuh_> For example. If I modify the kernel to be able to support a Mustek Scanner using SCSI, and it is a new entry. When you compile your kernel using an old config. It doesn't exist. So you will be asked if you want Y/N/M
<dim44> It sound very similar to "make oldconfig" command btw
<SiFuh_> No idea, I never do that.
<SiFuh_> I am not into automated compilations of the kernel.
<dim44> It's not automated, it asks you questions. And in the case of 5.4.80 to 6.4.10 there were A LOT of questions.
<SiFuh_> Definitely
<dim44> So I think I'll just go with jaeger's .config which I know it's confirmed working
<SiFuh_> Why I work up in stages.
<dim44> Ahhhhhhh
<dim44> Man, too many reboots, last time I rebooted was 3 months ago
<SiFuh_> You will only need one with my config on the CD and it will boot pretty much every amd64 and x86 machine
<SiFuh_> jaeger: So yours boots the NUC now? So you introduced that little MMC thing I was working on a year or so back?
<dim44> Yeah but then I need to customize it for specific things, like I needed to customize the 3.6.1 .config
<dim44> So more reboots are going to be needed. Whereas if I merge my own .config with another one, only little customization may be needed
<SiFuh_> Yeah, as I said to many before. I made it modular so when you build it and boot you can check what modules your system loaded. Write them down and then you know what you can strip and what you need
<dim44> I'll check it out, don't really know what modular means
<SiFuh_> modules mostly
<SiFuh_> Important stuff is set to Y and everything else that x86 or amd64 systems use are set to M
<dim44> Ahhh okay
<dim44> Doesn't it take a lot more time to build? (I have a 10 year old processor)
<SiFuh_> Hell yeah
<SiFuh_> I currently build on a Pentium(R) Dual-Core CPU E5700 @ 3.00GH
<jaeger> My NUC doesn't use MMC, it has a standard SSD in it
<jaeger> It did boot on an old zotac zbox thing I have, though to be honest I haven't looked at that in a long time, it's really anemic hardware
<SiFuh_> Oh the Zotac has the MMC yes?
<jaeger> I believe so
<jaeger> I should probably verify it still works so I'm not a liar, heh
<SiFuh_> I remember figure it out because of a Beelink box using MMC and you mentioned one of your devices has the same issue. Zotac rings a bell now
<SiFuh_> You tested it when I did that kernel update
<SiFuh_> And you had mentioned that it booted fine
<jaeger> OK. My memory isn't that good
<SiFuh_> August 7th 2022
lavaball has quit [Remote host closed the connection]
dim44 has left #crux [Leaving]
dim44 has joined #crux
<dim44> 3.7 stock config works in yet another system! Even after hacking it with grep all over the place
<SiFuh_> Cool
<r0ni> so it took a bit of work but i got that liveiso build to create an iso and it boots up!
<r0ni> fun tidbits are if you're using farkuhar's updated pkg-get it gives all kinds of errors along the way, so it expects pkg-get from core/pkg-get and it uses a kernel package rather than just stealing your local kernel, so that took a while to build. I usually use slackwares kernel directly, but it wants to build a fresh kernel with slackwares config for you
<r0ni> or other kernel choices, the kernel-slack was the default tho
<r0ni> not sure if it features any persistence tho, I didn't really look into it. have many things to do today so i can't play with it more for now
<SiFuh_> r0ni: Congratulations
<r0ni> it's def a good work and now i see the author does idle here, hi emmett1 !
<SiFuh_> Oooo is he?
<SiFuh_> Cool, I only talk to him on Telgram because I didn't know he was here
<farkuhar> I'm about to push an update for contrib/graphicsmagick, and I'd like to hear from any current graphicsmagick users. Does the current port work well enough for you, or do you find some breakage in the various subcommands?
<farkuhar> 'gm convert' is a subcommand that has stopped working since my latest build, now returning no results for the query 'gm convert -list formats'. I distinctly remember being able to use 'gm convert' with version 1.3.40 of graphicsmagick, so I won't push an update to 1.3.41 until all the subcommands are confirmed working properly.
<jaeger> I don't use it directly, only as a dependency of inkscape... so not sure here
<farkuhar> jaeger: I wonder if there's an equivalent of --without-zlib-version-check, in case the graphicsmagick configure script is being stupid in its parsing of the zlib version string, and thereby disabling the PNG decoder.
<farkuhar> but 'gm -version' _does_ list PNG and JPEG under the section "Feature Support", so it's still a mystery why the command fails with the message "No decode delegate for this image format"
dim44 has quit [Remote host closed the connection]
sajcho has joined #crux
sajcho has quit [Client Quit]
sajcho has joined #crux
<farkuhar> finally figured out the graphicsmagick breakage ... the offending build command is the one that deletes all "*.la" files. By restricting to -maxdepth 1 we end up keeping the needed files under modules-Q16/coders.
<farkuhar> ^ one of the lesser-known side effects of the "nuke them from orbit" attitude toward *.la files
<cruxbot> [core.git/3.7]: openssh: fix build with zlib 1.3
<jaeger> Ah, interesting
<farkuhar> r0ni: sorry to hear about your grandfather's passing, and the anticipated "fun of funerals, ..., estate sales, etc" for the next few weeks. Meanwhile I'm still dealing with the aftermath of a 2016 death, because the deceased was set to inherit some property in Malaysia: https://imgur.com/78lmDBp
<sajcho> dim44: How do you know what's new? Release notes for each kernel? => answer: copy the current kernel configuration into the new kernel source and use make help or make listnewconfig or make helpnewconfig, the differences will tell you.
<r0ni> farkuhar: 2016? my goodness! I surely hope this stuff goes smoother than that
<r0ni> i'm overly glad there isn't anyone to fight over things in my family. There's literally only 3 of us left, and we all men, so we just want it over ASAP
<farkuhar> r0ni: the deceased family member in 2016 had older relatives still living in that house (to this day, in fact). The legal document pictured above is meant to formalize the updated line of inheritance, for whenever the property does get sold. I have no idea how much our 1/12 share in the property is actually worth; SiFuh_ and emmett1 are in a better position to tell from the address.
dim44 has joined #crux
<cruxbot> [contrib.git/3.7]: graphicsmagick: 1.3.40 -> 1.3.41
tilman has quit [Ping timeout: 248 seconds]
tilman has joined #crux
sajcho has quit [Quit: Client closed]
<dim44> Sifut_: I'll test the 6.4.4 kernel after all, building now
<cruxbot> [contrib.git/3.7]: mkvtoolnix: -> 78.0
<cruxbot> [contrib.git/3.7]: nextcloud-client: 3.9.2 -> 3.9.3
<cruxbot> [contrib.git/3.7]: python3-poetry: 1.5.1 -> 1.6.0
<cruxbot> [contrib.git/3.7]: python3-dephell-specifier: added missing dependencies: python3-build, python3-installer, python3-wheel
<cruxbot> [contrib.git/3.7]: python3-poetry-plugin-export: 1.4.0 -> 1.5.0
<cruxbot> [contrib.git/3.7]: python3-yaspin: 2.5.0 -> 3.0.0
<cruxbot> [contrib.git/3.7]: vala: 0.56.11 -> 0.56.12
<cruxbot> [opt.git/3.7]: protobuf: 24.0 -> 24.1
<cruxbot> [opt.git/3.7]: python3-poetry-core: 1.6.1 -> 1.7.0
ppetrov^ has quit [Remote host closed the connection]
dim44 has quit [Remote host closed the connection]
dim44 has joined #crux
tilman has quit [Ping timeout: 256 seconds]
tilman has joined #crux