<remiliascarlet>
Anyone want ethernal suffering? Just compile gcc-fortran from source.
<remiliascarlet>
Have been compiling this motherfucker for 12 hours, and it's still far from done.
<remiliascarlet>
I copy/pasted this, because I accidentally posted it in the wrong channel earlier. At the current state, we're 25 hours in, and gcc-fortran is still not done compiling.
<remiliascarlet>
It's already taking longer to compile than Chromium, Firefox, and LLVM combined.
<SiFuh>
remiliascarlet: 21 hours for me on an older machine. A pentium
<SiFuh>
21 or 27. Can't remember exactly. It was a while ago
<remiliascarlet>
Mine is a Core 2 Duo.
<remiliascarlet>
Among the last processors to support Libreboot.
<farkuhar>
I'm not creative enough to come up with a catchy portmanteau for "wifi" that would serve as the counterpart for "ethernet" + "eternal suffering" -> "ethernal suffering". But something did recently change among the daemons in /etc/rc.d, so that my laptop now requires SERVICES=(... wpa_supplicant ... dhcpcd) where before it could get away with SERVICES=(... net ...)
<SiFuh>
farkuhar: portmanteau? You mean pkgaddteau
<SiFuh>
Wife is going to South Africa and she was describing the type of bag she wants. I was telling her that the colonial era leather trunks is probably what she is after.
<SiFuh>
My friend from France uses one as his tool box. Didn't realise it was also called a portmanteau
<farkuhar>
Re: gcc-fortran, if it takes that long on a Core 2 Duo, would it be worthwhile to set up distcc, and leverage the power of other processors on the network?
<ukky>
farkuhar: /etc/rc.d/net service starts dhcpcd daemon if your network is configured in DHCP mode. Maybe wpa_supplicant is doing something dhcpcd cann't or don't know how. dhcpcd is in my TODO list to remove, as it takes too many jobs to handle, like systemd.
<SiFuh>
for Wi-Fi you only need net and wpa_supplicant
<farkuhar>
ukky: my network was configured in DHCP mode, and the dhcpcd daemon was being started, but the association with the access point wasn't succeeding. It used to succeed even without wpa_supplicant in the SERVICES array, because the wpa_supplicant item under dhcpcd-run-hooks was activated.
<farkuhar>
But that setup inexplicably stopped working, and now the SERVICES array seems to need wpa_supplicant explicitly.
<farkuhar>
although there've been some version bumps to dhcpcd since I last copied the hook from /usr/share into /lib, the only change I can see in that file is s/type/command -v/. http://ix.io/4FVC
samsep10l has quit [Quit: leaving]
<SiFuh>
I remember wlan0 being moved into wpa_supplicant. I use to use wlan and net.
<farkuhar>
hmm, SiFuh reminded me of something: how the kernel assigns names to network interfaces. At various times in the past it's been wlan0, wlo1, wlp0s1. But I've been using the same kernel both when SERVICES without wpa_supplicant worked, and when it didn't. So I'm not convinced it's the kernel at fault.
<SiFuh>
net.ifnames=0 <-- then add that to your kernel command line
<ukky>
it is eudev/udev that renames network interfaces. If you disable udev, you'd have eth0. My current setup renames network interfaces according to MAC, via nameif from busybox.
<SiFuh>
net.ifnames=0 causes the devices to be named eth0 and wlan0. However, if you have let's say two or more wlan devices sometimes one will register faster than the other and other times another will register faster instead. So we use udev to make it so that device 1 stays device 1 and device 2 stays device.
<SiFuh>
and device 2 stays device 2 and so on*
<ukky>
farkuhar: dhcpcd has this hook script: /usr/share/dhcpcd/hooks/10-wpa_supplicant
<ukky>
if the above script is not called for your interface, then dhcpcd has 'nohook wpa_supplicant' somewhere for your interface
<ukky>
you can add debug ptintf to 10-wpa_supplican to see if it is started/stopped
<farkuhar>
ukky: I haven't touched dhcpcd.conf, and none of the revisions made by rejmerge would have added 'nohook wpa_supplicant'. But I think you're onto something with the mention of udev/eudev. The hook might need fine-tuning to cope with the new names that udev is assigning.
<ukky>
does udev create the same name for your device?
<farkuhar>
ukky: if you figure out how to replace dhcpcd with something simpler, I'd like to record your findings in a wiki page. The dhcpcd developers might not be aware that their hook is broken by the latest udev, in which case it makes sense to go with a simpler daemon that doesn't try to do as much.
<ukky>
farkuhar: I usually log everything when doing R&D, so will happily share my notes.
<ukky>
The reason for my intent to replace dhcpcd is not because it is badly written, or have some flaws. What bothers me is that dhcpcd manages too much unter the hood, it is like Network Operating System.
<ukky>
farkuhar: thanks again for your shell rsync driver. I have changed it a bit into rsync2git driver to create local git repo from remote rsync repo, to implement that idea you mentioned few days ago to use subversion for Pkgfile patching, but using git instead
<magnahelix>
ukky: entirely valid reasons. dhcpcd is overly complicated and over engineered for what it does...
<magnahelix>
Don't even get me started about the monolith blob known as systemd...
<farkuhar>
ukky: you're welcome for the script. But Anton deserves the credit for the subversion idea; I was just the messenger.
<SiFuh>
Anton's messenger... Don't start a new religion
<farkuhar>
ukky: it might be worthwhile to insert the line unset old_checkouts["$oc"], in the loop that removes obsolete files. That way the loop to remove obsolete directories has fewer keys to iterate over.
<ukky>
magnahelix: we are on the same page regarding systemd.
<SiFuh>
Doesn't that systemd dude work for microsoft shit these days?
<ukky>
SiFuh: he does. I went to his Wiki page to know what tools/programs he wrote and now all those tools are forbidden on my systems.
<magnahelix>
xD
<SiFuh>
The controversy around systemd culminated in personal attacks and alleged death threats against Poettering. Poettering went on to put some blame on Linus Torvalds and other kernel developers for being bad role models for encouraging an abusive discussion culture on technical disagreements
<SiFuh>
I guess some people hate systemd a lot
<SiFuh>
And it is all Linus' fault.
<SiFuh>
Haha
<ukky>
farkuhar: Do you mean after first loop when only files are removed?
<SiFuh>
If he thinks Linus is tough, he should meet Theo
<magnahelix>
There's two things about systemd that are disgusting.
<magnahelix>
The arrogance surrounding it and the fact it has deliberately thrown out every single shred of unix principles.
<SiFuh>
It was created by a far left commie and it takes ovrer everything.
<SiFuh>
over*
<SiFuh>
I like runnit but I still think the current that CRUX uses is just the way it should be
<magnahelix>
Arch has gone over to it hook, line, and sinker. Even the boot loader is now a systemd module...
<SiFuh>
fscking commies everywhere
<SiFuh>
magnahelix: My friends that use Arch switched to Artix and my friends that used Debian switched to Devuan
<magnahelix>
Not surprised about that in the slightest.
<ukky>
magnahelix: Never heard of boot loader as systemd module. I should google it...
<SiFuh>
ukky: Wouldn't waste your time since we are anti-systemd
<magnahelix>
One of these days my laptop will stop running arch just on principle. :P
<ukky>
SiFuh: magnahelix: thanks for links. I have to know the enemy. Devs at my company love systemd-based distros.
<magnahelix>
Can only imagine...
<magnahelix>
omg but it's a STANDARD environment now! ...
<magnahelix>
Again, it's strange because many if not most accept systemd as an inevitability.
<magnahelix>
Bitter pill because it's a monolith and because herr Lennart is involved.
<SiFuh>
Depends on the person though. I remember every job I have ever worked and they have given me a Windows PC, I have refused to use it unless I can install Linux/Unix on it.
<SiFuh>
Even funnier when they threaten to fire me if I don't use it.
<ukky>
99.99% of devs at my company use Windows as main OS. Luckily, nobody forces me to use Windows, but I have to admit that I use Linux for only 10 years (Gentoo).
<ukky>
From Arch Wiki: efibootmgr --loader "\EFI\systemd\systemd-bootx64.efi" --label "Linux Boot Manager" <=== Isn't it too humble? Is Linux a Systemd?
<SiFuh>
I have never been fired, I have never had to quit, and I have never had to use Windows. With one exception. The MTDATA terminal in the TAXI I was driving ran over the top of Windows CE so I made that an exception
lavaball has quit [Remote host closed the connection]
<ukky>
farkuhar: exactly, I added to line 58, thanks
stoffepojken has quit [Read error: Connection reset by peer]
stoffepojken has joined #crux
<ukky>
Does httpup takes file '.httpup-repgen-ignore' into consideration? I'd like to protect some files in local httpup collections
<farkuhar>
Speaking of ports drivers, I went randomly through the portdb searching for an .httpup that actually made use of the fact that $URL gets split on whitespace, and the separate parts are used in a for loop. Didn't find any such .httpup, though.
<ukky>
I was wondering about that too, actually. sed -n '/#.*$/s|^.*#||p' allows to extract and then download/update a single port
<ukky>
farkuhar: modifying your rsync shell script to have httpup2git driver, this way I will have proxy port collection directory for 'port -u', and actual port collection directory for the rest of pkgutils tools
<farkuhar>
ukky: interesting idea. The actual port collection will have your custom patches applied?
<ukky>
farkuhar: exactly. I would do 'git stash save', then 'git fetch' (from proxy repo), 'git merge' (from proxy repo), 'git stash apply', 'git stash drop'
<farkuhar>
ukky: Since I couldn't find an already-published *.httpup that leverages $URL being split on whitespace, I put one together myself. http://ix.io/4FXm
<ukky>
That URL syntax should work with current httpup driver
<farkuhar>
not sure if it's worth illustrating such usage on the Wiki page SettingUpAnHttpupRepo, but fwiw it does work.
joe9 has joined #crux
<ukky>
It might be good to mention it in Wiki, because httpup tool supports this kind of syntax but does not mention it in man pages
<farkuhar>
speaking of httpup man pages, did you try 'httpup list <target directory>'? That command is supposed to show all the files under httpup's control.
<farkuhar>
I know you wanted to protect some files in the local httpup collections, so maybe a first step would be to see which files httpup already claims responsibility for.
<ukky>
Yes, I tried 'httpup list'. It is not very helpful, as it just dumps the content of '.httpup-repo.current' file from collection directory. It would be more useful to query list from remote server.
<farkuhar>
And if the list you get from the remote server shows a potential conflict with files you want to maintain locally, the idea is to somehow shield those files from being synced?
<joe9>
I am trying to install crux through a serial consoel on OpenBSD VMM. I get this kernel panic: https://dpaste.org/UMa1P/raw
<ukky>
it seems that httpup doesn't delete unrelated files. Just wanted to be sure
<farkuhar>
joe9: I think SiFuh is our resident OpenBSD guru. Maybe he can help you with a VMM installation.
<joe9>
ok, thanks.
<farkuhar>
ukky: "unrelated files" on which run of httpup, though? Something that's unrelated now might not be unrelated later, if the upstream repo by sheer chance happens to introduce a new file whose name matches something you already have in the target directory.
<SiFuh>
joe9: how much RAM is your VMM configured for?
<ukky>
farkuhar: The idea is to maintain similar hidden files like you did for rsync driver: {.checkouts,.old_checkouts,.new_checkouts} <=== these are 'unrelated'
<farkuhar>
ukky: that makes sense. As you noted, the httpup driver will leave in place anything you added to the target directory yourself, as long as the upstream repo doesn't have an identically-named file. The dotfiles you listed will probably survive a sync.
<farkuhar>
and if FS#1313 gets addressed, then the git driver can be configured to behave the same way.
<ukky>
git driver whould not need any extra files to maintain, as it git can be used directly as proxy collection
<ukky>
s/as it git/as git/g
lavaball has quit [Quit: lavaball]
<SiFuh>
joe9: http://ix.io/4FXw This is what I did and it boots fine. I made sure I have 2048M of RAM though.
<SiFuh>
I am using the official 3.7 release and not the updated version. But should be fine either way
<joe9>
SiFuh: That makes sense. I used the default RAM. Thanks.
<joe9>
SiFuh: I was away.
<SiFuh>
joe9: CRUX 3.7 needs more than 1024MB of RAM to boot. You can adjust it after you have installed it.
<joe9>
ok, thanks.
<joe9>
SiFuh: do you install CRUX to the vm? or, just use it from the cd and the disk as the overlay?
<joe9>
interesting that you do not use a different speed for the serial line.
<SiFuh>
The only time I ever did it apart from the boot example today for you was to install it direct and it was slow and painful to install and compile
<SiFuh>
joe9: it was a quick and dirty test
<joe9>
I have the system booted up. Thanks.
<SiFuh>
No worries
<joe9>
I have a java app that runs only on linux. I use OpenBSD as my main driver.
<SiFuh>
OpenBSD is my main driver for my PC/Laptop and TV ;-)
<joe9>
SiFuh: I am trying to see if I can run CRUX in the vm..
<SiFuh>
joe9: It works, just it is very slow I find
<joe9>
oh, ok. I used to alpine for this app but got fed up with trying to learn all the alpine stuff.
<joe9>
CRUX is something that aligns with my philosophy.
<joe9>
bbl
<SiFuh>
joe9: I ended up using alpine instead of CRUX. I was running Sonarr, qBittorrent and SABnzbd for awhile in the VMM until I figured out how to get it working on OpenBSD.
<ukky>
farkuhar: imho, the best place and very clear wording
<SiFuh>
ukky: A bit of discrimination though. Just ignores the rsync/git guys out there.
<farkuhar>
SiFuh: if you only publish your repo via rsync/git, you don't show up on the official portdb. You have to make a concession to httpup if you want to be listed on the official portdb.
<SiFuh>
ukky: I actually like reading farkuhar's documentation because it actually makes sense
<ukky>
SiFuh: I believe rsync/git might not support the same feature, i.e. partially download a collection
<ukky>
Without httpup, CRUX system behind corporate firewall might not get automatic updates, as git/rsync ports might be forbidden
<SiFuh>
Good thing I provide both then ;-)
<SiFuh>
Maybe I should modify my README.md to inform them of possible port blocks
<ukky>
I don't mind to switch to 'git' driver at home though
<ukky>
can we support git driver working via https protocol instead of git://?
<ukky>
SiFuh: Company's policy. You can get an exception, but you need to submit an form and convince IT department why you need it
<farkuhar>
namenlos provided a pretty decent git driver in the followup message; I wonder why it got changed over the years.
armin has joined #crux
<SiFuh>
ukky: Always ways around it ;-)
<SiFuh>
Back in 2002 the university I worked for installed Novell BorderManager and blocked pretty much everything. You couldn't even access the internet without logging in. I just installed SQUID proxy on a local Sparc64 machine with OpenBSD and diverted my packets through that. No login, no blocked ports. It was like the BorderManager didn't even exist.
<ukky>
SiFuh: I've got penalty for doing that, no funky network activity from me at work anymore.
<SiFuh>
In China, 2004, I just diverted my network through an SSH tunnel in Australia
<armin>
the worst are corporate web proxies that actually intercept ssl connections (hello, zscaler!)
<armin>
also, hello.
<SiFuh>
Always a way and I have never failed yet ;-)
<armin>
SiFuh: this.
<SiFuh>
A while ago I wanted to change the GPON fibre box to something different and the ISP refused. Said I must use their supplied garbage. A week later I have a Mikrotik Router with a SFP GPON fibre adapter. The ISP's crap is in a box packed away.
<SiFuh>
While I was trying to get the SFP GPON working the network was going up and down too much. Wife received a notification on her phone that our Internet must be having problems and they would like to send a service technician. I told her to ignore it the message
<farkuhar>
Hmm, looks like 3.2 was the earliest CRUX release to have the ports driver included with opt/git, and the relevant commit was pushed by _tek in 2015 (long after the May 2008 discussion where namenlos provided his driver).
<SiFuh>
I did record the entire configuration process in a very lazy PDF/ODT layout for friends here whom wish to do similar
braewoods_ has joined #crux
braewoods has quit [Read error: Connection reset by peer]
braewoods_ has quit [Ping timeout: 248 seconds]
braewoods has joined #crux
samsep10l has quit [Quit: leaving]
<joe9>
SiFuh: Is there a way to use CRUX in the vmm without going through the kernel compile?
<joe9>
SiFuh: my disk provided with -d does not show as /dev/sd*
<joe9>
would it be vda?
<joe9>
the cdrom is sr0
<joe9>
and I can see that.
<magnahelix>
If lsblk works run that to show any disks.
<joe9>
yes, that shows vda
<joe9>
thanks
<magnahelix>
:)
groovy2shoes has joined #crux
XXX1232 has joined #crux
<joe9>
do we have to build a custom kernel while installing? Is there a way to use the one used by the insntnaler?
<joe9>
installer?
<jaeger>
You can use the one from the install media if you want, it just might not have all the device support needed
<joe9>
ok, thanks.
<jaeger>
But yeah, you can copy the kernel image and initrd and use them
<lennox>
anyone have any experience with crux on a chromebook
<lennox>
was going to try installing it on this one dell I have
<jaeger>
Not I
<jaeger>
But if it's an x86-64 one instead of arm, can probably be made to work
<lennox>
it is
<jaeger>
If it were arm, there's crux-arm.nu to try as well