jason123onirc has quit [Ping timeout: 246 seconds]
jason123onirc has joined #crux
<dim44>
Sifuh_:You said yesterday: "I'd check if the old package is installed first. Then uninstall it and try installing the new package. If there is still a conflict, I'd then compare the old packages footprint with the new footprint. Then search for rememnants left over in the system and remove them manually"
<SiFuh_>
I am here! Who is harrassing me?
<dim44>
hahaha
<SiFuh_>
Yeah, I said that
<SiFuh_>
Did you think I needed to be reminded, in case I forgot? Hahaha
<dim44>
Why would this happen, why would the removal process fail if the files are in the footprint? There was one port where that happened and I kinda wondered about it
<dim44>
I backed up the files as you recommended before executing the -f
<SiFuh_>
Maintainer error, sneaky builds, old system being upgraded to new
<dim44>
Ah ok
<farkuhar>
dim44: I think pkgadd.conf also influences pkgrm transactions, so that you don't accidentally delete a customized file under /etc, for example.
<SiFuh_>
wxgtk was a good one back in 3.5. You had wxgtk wxgtk3 and so on. When all wxgtk was removed and replaced with a single port the fsearch didn't show results of the removed/deleted ports from the repo. It only displayed wxgtk3 as having a conflict with itself even though it was an older non-existence port.
<dim44>
farkuhar: after what happened with the filesystem package I did check up on that
<farkuhar>
dim44: I must have arrived to the conversation late. What happened to your filesystem package?
<dim44>
SiFuh_: ah okay, so fsearch failed due to the same name
<dim44>
farkuhar: It's from a couple of days ago, I'm pretty sure you helped me with it too.
<SiFuh_>
dim44: No, but could be. It was an example.
<dim44>
farkuhar: pkgadd.conf stopped the filesystem package from upgrading the /port/*.rsync files during an upgrade from 3.6 to 3.7
<dim44>
Btw with your help, I managed to fix everything up.
<SiFuh_>
dim44: Here is a sneaky buld example. You build the port and the port installs to $PKG. Then you install system wide. However sometimes a compilation may ignore $PKG and install directly to the system. Then in the future when you install an updated version that wasn't sneaky. It will error because the file exists already but wasn't removed because it was never in the original ports footprint.
<dim44>
revdep and sysup comes clean
<farkuhar>
dim44: oh, now I remember. Meanwhile it comes as a surprise see /var/www being part of the filesystem package, rather than something installed by apache.
<farkuhar>
I guess since we deploy /etc/passwd with a www user by default, the filesystem package has to create the corresponding homedir /var/www. I'm curious how many CRUX installations actually enable the www user, though.
<dim44>
Sifuh_: What I found strange in this case that the files were indeed in the footprint and did exist in the system even after I prt-get removed [package]
<farkuhar>
dim44: weird. Were you running prt-get remove libxml2 from the booted ISO (passing the --install-root option), or from the recently-upgraded CRUX 3.7?
<dim44>
farkuhar: from a chroot inside the recently upgraded CRUX 3.7. I chrooted from my main 3.6 system
<farkuhar>
dim44: I wonder if you'd get a different result, running prt-get remove libxml2 from a cold boot of CRUX 3.7 (not a chroot). Would you care to run the experiment and report back to us?
<dim44>
farkuhar: Sure, but I don't have not tested the kernle yet, and I need to finish the configuration of fstab and crypttab. I was planning on booting it tomorrow
<dim44>
farkuhar: basically to `prt-get remove libxml2` and then check if those files are still there.
<SiFuh_>
Oooh crypto ;-)
<farkuhar>
dim44: Thanks! If you've uncovered a bug in prt-get, we should give you proper credit on the ChangeLog when it gets fixed.
<SiFuh_>
farkuhar: If I have time, which I doubt, I wouldn't mind trying to do a USB key version of disk encryption
<dim44>
Sifu_: back when I installed 3.6, getting disk encryption to work gave me a hard time. I think you also had a script for automated kernel upgrade with dracut
<SiFuh_>
dim44: Pretty sure 3.6 didn't have cryptsetup. I think I pushed jaeger to put it in for 3.6.1
<dim44>
Sifuh_:It was in 2021 I think. It may very well have been 3.6.1
<dim44>
Btw I do use a yubikey to authenticate with a dracut script
<dim44>
*circumventing crypttab completely
<SiFuh_>
I use yubikey too but for my laptop and password gorilla. I do not use yubikey for disck encryption though. I have OTP login. For SSH I have it setup to require a pin and then OTP.
<SiFuh_>
dim44: cool
<SiFuh_>
I did one where you don't enter anything. The kernel command line decrypted your disk. It was a proof of concept and to be honest, I have no idea what you'd use it for since the key would be easy to get your hands on
<dim44>
I also have a slot configured with a bigger text password for emergencies in every disk though. Only root unlocks from the yubikey, they others unlock from a keyfile in root
<SiFuh_>
Was planning to, but never got around to it.
<dim44>
Aren't FIDO passkeys unique? At least with the yubikey you can backup the internal key create a copy if you lose it.
<SiFuh_>
Not sure, thought they were like keys you use to log in with passwordless SSH
<dim44>
They can be used for that yeah, but I thinkg that there is no way to replicate them, including if you own them. You're supposed to buy two of them and add both signatures to ssh
<SiFuh_>
Yubikey is fido as well
<SiFuh_>
I have two Yubikeys. Fortunately for me, I remember the exact sequence I used to configure the first one. Exact to the digit. Hehe So I was able to manually configure the second one. They both register the same for everything now but as I mentioned before about OTP. Once the system records the number the Yubikey must provide a higher number for Authentication. So they both can work just once you OTP then one
<SiFuh_>
will stop working until you delete the recorded entry.
<SiFuh_>
cat /var/db/yubikey/<USERNAME>.ctr will produce a number for example 300. Next time you use the OTP on the yubikey it might end up as 301. If you have a clone of the same key and try to use it and it registers as 299 it will fail. You need to try again several times before you surpass 301
<SiFuh_>
I don't mind because I have the micro yubikey I can use when travel but as soon as I am home I can overide it with the first key
<SiFuh_>
Would be nice if it record a serial number for multiple devices. That way each device has its own count up timer.
<dim44>
OTP is best for security but it has this kind of quirks
<SiFuh_>
I use to use skey. It was kind of fun though.
<dim44>
btw I setup a new quick chroot and got through the 3.6 -> 3.7 upgrade. The libxml2 footprint mismatch appears to exist once again. Should I just boot it and try to remove it?
<SiFuh_>
Isn't that what farkuhar wanted?
<SiFuh_>
Best let him say.
<dim44>
Yeah, I mean do I have to save anything else before executing prg-get remove libxml2? Some kind of trace?
<dim44>
farkuhar:
<dim44>
I did save the footprint before ports -u
<dim44>
Sifuh_:Does skey have the limitation with sequential keys, or is there some way to program it to accept any of the next, let's say, 20 keys. Like how car keys works
<dim44>
Damn, I don't remember how to write a non encrypted grub boot entry, hahah
<farkuhar>
dim44: based on the output of your `prt-get diff`, I agree that the footprint under /usr/ports/opt/libxml2 is for version 2.11.5. But that shouldn't affect the result of `prt-get remove`, which deletes files based on /var/lib/pkg/db.
<farkuhar>
If `prt-get remove libxml2` on a freshly-booted 3.7 system still leaves behind files that conflict with the latest libxml2, then maybe your pkgdb got corrupted during the upgrade.
<dim44>
farkuhar: the files are not in /var/lib/pkg/db
<dim44>
farkuhar: there's an libxml2 section and the file looks alright
<dim44>
farkuhar: btw I checked the source for 'pkginfo' and saw that it uses /var/lib/pkg/db so it can work as a complement to 'prt-get fsearch' that looks at the .footprint files
<farkuhar>
that should give you the libxml2 section of your pkgdb. I'm surprised that it doesn't contain usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.pyc
<dim44>
Sifuh_ is right something is missing from the command
<farkuhar>
sed '1,/^libxml2/d; /^$/,$d' /var/lib/pkg/db
<dim44>
It's the same as the above paste
<farkuhar>
your pastebin doesn't give any clue as to how usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.pyc ended up on your CRUX 3.6 installation. I'm out of ideas for the "conflicting files" error.
<dim44>
It might have been some package that I compiled myself.
<farkuhar>
I agree, that's the most likely explanation.
<dim44>
I thought that the .footprint file controlled deletions, if it's from somewhere else then the problem is not as weird as it seemed at first
<farkuhar>
In general we're being advised to do all our personal python stuff inside virtualenvs from now on. Following this advice will protect you from future troubles of the sort.
<dim44>
But now I know how to fix them!
<SiFuh_>
Fix would mean solve the problem by knowing what caused it
<SiFuh_>
A solution would be to solve the issue but not knowing what caused it :-P
<dim44>
I caused it :D
<SiFuh_>
:-P
<farkuhar>
speaking of virtualenvs, the changelog for the latest qutebrowser says that their asciidoc2html.py script "now correctly uses the virtualenv-installed asciidoc rather than requiring a system-wide installation." I would test this claim myself, but somebody with beefier hardware will probably get the answer more quickly.
<farkuhar>
I mean an answer to the question "can beerman drop from qutebrowser the hard dependency on asciidoc?"
<farkuhar>
another notable point in the qutebrowser changelog: there's now first-class support for qt6-webengine, with the qt5 webengine as a fallback. The qutebrowser deptree might simplify considerably, with this new default taken into account.
<r0ni>
is there a way to auto-generate a .md5sum file?
<SiFuh_>
Why would you want that?
<r0ni>
like not 'pkgmk -um'
<r0ni>
because i shouldn't have to maintain 2 differetn repos based upon the arch
<SiFuh_>
.md5sum are pretty much obsolete
<SiFuh_>
.signature is what is used now
<r0ni>
that file would have the same issue
<r0ni>
the SRC varies by arch, so is there a way with some special file to get it to generate the appropriate file during update?
<SiFuh_>
pkgmk -us -sk $KEY -d
<SiFuh_>
When I upload a port to my repo I run a script and this is inside the script KEY="/etc/ports/<MYKEY>.sec" and it does it automatically
<farkuhar>
r0ni: is your feature request inspired by the way pkgmk does on-the-fly substitutions for <kernel-version> when computing footprints?
<SiFuh_>
beerman has a rather funny but more complicated version. Mine is simple
<r0ni>
farkuhar: i'm not sure lol so i can use uname -m to find out the arch we're building on, but the SRC file differs based upon that as well, so outside of including both files in $source i'm thinking there has to be a way to make the ports happy per arch
<r0ni>
i had done this, adding $arch until i realized i can't do that for aarch64 and x86
<farkuhar>
r0ni: i would still recommend creating separate repos per arch, but you could achieve some level of automation by manipulating the two Pkgfiles with an external script.
<r0ni>
ya, i think i just got a better idea, just have 2 diff pkgs ncdu-aarch64, ncdu-x86_64. one repo, obvious difference
<r0ni>
if this repo were'nt just for me, i'd approach it differently i think
<r0ni>
if i weren't being completely lazy, i'd package zig so i could just build it from source instead and this wouldn't be needed. but that's not what i'm being
<farkuhar>
packaging zig is not a trivial task. Don't consider yourself lazy for not attempting it.
<r0ni>
ahh see i'm saving myself unneeded stress then ;)
<SiFuh_>
r0ni: I type the command 'yenjie' and the script does pretty much everything for me. I run it per port though.
<SiFuh_>
farkuhar: is correct, you should have two different repos for the two different architectures
<farkuhar>
yeah, if you take on the responsibility for a foundational piece of the toolchain, then all the packagers of Zig-based software will be pestering you with their problems.
<farkuhar>
better to save yourself the headache, r0ni.
<r0ni>
tho tbh i've yet to receive any complaints from the xfce repo, so i assume i've "done good" or just noone uses it at all lol
<SiFuh_>
Does anyone use XFCE?
<SiFuh_>
Haha
<farkuhar>
dlcusa has been known for using it.
<SiFuh_>
Yes but he stopped maintaining it
<SiFuh_>
We were hoping r0ni might take it over
<SiFuh_>
Problem is we don't really know anyone else who uses it.
<SiFuh_>
Didn't jaeger test it?
<r0ni>
yeah he fixed up my messed up deps so he had installed it at least
<r0ni>
i still want to do some "meta-packages" for installation, and I need to write actual install docs properly but it should be almost perfect
<r0ni>
i might need to go thru and revise ports removing .la files yet but i'll get there
<SiFuh_>
Will be nice.
<r0ni>
dealing with arm is a constant headache that side-tracks me lol
<SiFuh_>
Shoul dbe a priority though if you wish to expand the reach of CRUX
<r0ni>
ya i'm working on a 100% clean envir to start over on aarch64 so I can reliably get changes needed to ports included in crux-arm
<r0ni>
there was so many ports along the way i needed to edit and I didn't keep reliable info on them
<farkuhar>
r0ni: keeping reliable info on your edits is a task for version control. Why not manage your repo with git?
<SiFuh_>
I prefer git myself
<SiFuh_>
I like being able to rewind my f*ck ups ;-)
<cruxbot>
[contrib.git/3.7]: enchant: adopted
<cruxbot>
[contrib.git/3.7]: asciidoc: adopted
<cruxbot>
[contrib.git/3.7]: glfw3: adopted
<cruxbot>
[contrib.git/3.7]: cgit: adopted
<r0ni>
farkuhar well during building/updating it's already tied to 6 repos along the way and when things failed building, i just copied the port to a local dir and fixed it, built, installed and moved on. Since I was devving on a vm to begin with, i didn't think about any of that, just getting to the end goal of "do my ports build/work" was my interest. I had assumed the arm port maintainers would be aware of breakage, tho it appears not so much
<r0ni>
i don't think theres any issues on x86, but arm def needs some more tweaks
<r0ni>
of course i then made my own pkg repo so i didn't come across the issues again, and forgot about it lol
<r0ni>
<-- lazy
<farkuhar>
r0ni: thanks for your efforts to "expand the reach of CRUX" as SiFuh_ put it. Glad to see the arm architecture getting some attention again.
<r0ni>
i do like the simple idea of crux mostly, its not as all-in as gentoo but it's just how i view a build form source distro to be... gentoo is too convoluted, crux makes sense
<SiFuh_>
I find it amazing farkuhar can pull URLs out of thin air. It is kind of cool
<r0ni>
heh i have read his review, actually long before i ever tried crux
<ukky>
for the developer, Gentoo is better than CRUX, though. Don't get me wrong, I am moving away from Gentoo, but keep Gentoo for the main development system.
<r0ni>
i mean i idled in here for at least a year or more before i had time to try it out
<r0ni>
in hindsight i should not have decided to try the arm port first, had i gone x86 i'd of had a better time of it. but arm port helped me learn more faster lol
<SiFuh_>
I think your arm path was best
<farkuhar>
SiFuh_: you idled in the IRC channel for at least a year before trying out CRUX in 2001? What were you running before that?
<SiFuh_>
About 4 months
<SiFuh_>
SuSE
<SiFuh_>
That is SuSE by the way. Not opensuse
<r0ni>
i do still use my other distro (slackware) mainly because i maintain a lot for it but i'd love to port it all to crux... it's just a matter of time to do so
<SiFuh_>
Slackware is a nice distro
<r0ni>
if i can get to a place where i can do all i could on slackware on crux, then i may be able to drop it once and for all
<SiFuh_>
I like the shorter variables slackware and gentoo use
<SiFuh_>
$PKG can easily be $P and $SRC can easily be $S
<r0ni>
ya i'm so deeply ingrained with how things work on slackware, it's hard to deal with other systems (but i'm learning) lol
lavaball has quit [Remote host closed the connection]
<r0ni>
i'd love if i had a live squashfs crux environment, but i haven't made it that far yet. I really want to get something going
<r0ni>
i thought about trying to adapt liveslak to crux but quickly realized that take me eternity
<SiFuh_>
I would like a live compact static basically boot for CRUX. Then all you need to do is boot strap the ports
<r0ni>
ya i want just a bootable squash core system
<SiFuh_>
Must be less than 1GB of memory though
<r0ni>
i think its pretty small 300-400mb i think
<SiFuh_>
Nope
<SiFuh_>
Now they encroaching over 1GB full unpacked
<cruxbot>
[core.git/3.7]: zlib: 1.2.13 -> 1.3
<r0ni>
sounds like we need a trim lol
<SiFuh_>
Been saying that for while hahaha
<farkuhar>
SiFuh_: a recent test ISO without linux-firmware does fit into 400mb of RAM. But how many users would we turn away by not having linux-firmware on the ISO?
<r0ni>
i keep thinking about going rouge and updating glibc and gcc and getting on the cutting edge
<SiFuh_>
Why are we loading it then?
<SiFuh_>
Why load everything when I need almost nothing?
<r0ni>
you can always get what you need and remove the pkg
<SiFuh_>
Why do I need linux-firmware when I am just installing from the ISO?
<farkuhar>
jaeger said it was to support the rare circumstance when someone needs to remove the boot media after entering the live system (e.g. if there's a limited number of USB ports)
<SiFuh_>
Why is linux-firmware even being loaded at CD boot when it supports very little already?
<SiFuh_>
I was looking into something last year about that. Why not create the boot, the CRUX and an empty partition on the USB stick. You copy what crap you need to that empty partition
<jaeger>
It could be useful if you want to do something via wireless, or you have a weird ethernet chipset that requires firmware, or your framebuffer is blank because the amdgpu kernel driver couldn't load its firmware, etc...
<jaeger>
Mostly edge cases, I feel
<r0ni>
my broadcom wifi needs it
<r0ni>
of course i also need to build a special kernel module as well
<jaeger>
Yeah, it becomes a question of whether or not that matters for an ISO installation
<SiFuh_>
You need wifi when installing CRUX?
<jaeger>
In the past I also maintained a netinst setup so it was more useful then
<SiFuh_>
jaeger: Yeah that would be
<r0ni>
no, but i do to do anything at all after install
<jaeger>
Yeah, and while you could download the linux-firmware package to a separate USB drive or something, it's certainly less convenient
<r0ni>
it needs to be included in the installer, but dont need anything to boot for sure
<SiFuh_>
With the right tweaking even busy box can be used to boot and install CRUX. I like the idea of being able to have a thrid partition for storing stuff you make bee
<SiFuh_>
need
<r0ni>
ok ok ok i'll finish out my crux-live idea ;)
<SiFuh_>
r0ni: will be great
<jaeger>
You might check out cruxex, a third-party crux live ISO thing
<jaeger>
It's not minimal but perhaps interesting to you
<r0ni>
oh snap i bet it would be interesting
<r0ni>
oh ya that seems decent
<r0ni>
i'll have to look it over tonight
<r0ni>
got me all side-tracked... I sat down at pc to reboot server and sat here for 30 mins talking up crux, never rebooted my server and walked away lol
<SiFuh_>
I prefer having a static CRUX setup for booting the CD something that doesn't change too much over busy box or something not CRUX.
<r0ni>
SiFuh_ i was going the VM route with crux-updated.iso was going to make snapshots and use that, but a live "core" iso would be ideal
<SiFuh_>
Not really into the live iso deal. I just think that ISO building can be much easier if we focused more on the ports than the entire ISO.
<SiFuh_>
The point of the ISO is to boot and install right? So with the exception of major glibc and gcc changes it should be quite simple to have a static boot and install. It doesn't really need to keep up to date with the latest ports. That can be built without the need of the ISO
<SiFuh_>
I bet a 3.5 ISO can boot and install 3.7 ports for example
<SiFuh_>
I say that because that is how I managed to get 3.7 installed on a machine with only 1GB of RAM
<SiFuh_>
Rather than jaeger constantly having an automated compilation of the entire ISO why not compile only what is neccessary?
<r0ni>
i'd think an iso with just a current core install is sufficient
<SiFuh_>
The thing is does it really need to be current? It is only installing ports already pre-built. The only real compilation is the kernel.
<r0ni>
well depends, most people try and update right away
<r0ni>
first thing i do to an install is ensure i'm up to date, and then work out the rest
<SiFuh_>
But you are. It is only the install CD that doesn't really need to be. The ports installed can be up-to-date
<r0ni>
right. the ports need to be current, the system running the install don't need to be
<SiFuh_>
As I said. I had to install 3.7 on a machine using a sliced up version of the 3.6 ISO. I booted 3.6 but installed 3.7
<SiFuh_>
Yeah! correct
<r0ni>
on arm i don't have the luxery of a iso install so i've barely used the iso's
<SiFuh_>
jaeger is probably more expert on this matter but I have often thought of a close-to-vanilla bootable ISO with the latest ports
<ukky>
We might split Bootable ISO and CRUX installation payload into two independent partitions. Bootable ISO component should not depend on what is populated in the payload (CRUX 3.8 installation). And payload should not depend on Bootable ISO content. This can be merged into single partition, or use separate partitions.