<farkuhar>
crash_: the extra kernel configs are on the iso, but the setup script doesn't install them into /usr/src/linux-* on the mounted fs, you have to copy them manually.
<beerman>
the bugtracker just spams crazy amounts of warnings into the logs.. so yeah, 0
<braewoods>
Truth is logs are rarely read unless something else prompted it so they usually end up being useless.
<braewoods>
That said you still need them if something does prompt an investigation.
<beerman>
yeah.. well the system is due for a proper clean up, so far (at least from what i did) it feels like scraping the surface. but i guess we would just need to finally switch a few things and would be good to go
<beerman>
jaeger: ^ with that said, if you got some time today we might want to try and do that?
<beerman>
could be nice to have the new system in place for 3.7, right?
groovy2shoes has quit [Ping timeout: 244 seconds]
groovy2shoes has joined #crux-devel
<farkuhar>
beerman: by "new system" you mean Gitea replacing Flyspray? Will switching bugtrackers make a big difference in the amount of log cleanup you need to do?
<beerman>
yes
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #crux-devel
<jaeger>
Uploaded a hopefully final rc ISO, will be testing installs and upgrades soon
<beerman>
nice.
<beerman>
jaeger: can you set me up with an email account for gitea to use?
<beerman>
if you do have credentials used by mysql to login to the database that would be good to know what else is in there
<beerman>
it looks like its just flyspray from the outside
<jaeger>
No idea on the mysql creds
<jaeger>
As for the email account, don't you just log in with whatever email you want?
<jaeger>
what the hell? somehow the defconfig is now a diff instead of a valid .config
<jaeger>
damn it
<jaeger>
would love to know how the hell I did that
<beerman>
<.<
<beerman>
oh no, on gitea you get to self register
<jaeger>
right... with your own email, I assume
<beerman>
and for that, it will send out an email for you to verify your account, the old and usual dance
<beerman>
yep
<jaeger>
ohh, you mean a system user for it to send emails
<beerman>
oh
<beerman>
does every local system user get to have $user@crux.nu?
<jaeger>
Probably, I don't remember how the MTA is setup exactly
<beerman>
ouch :D
<beerman>
me neither, i was hoping you would
<jaeger>
It's been years since that box was built, heh
<jaeger>
And multiple admins
<beerman>
yeah.. obviously <.< its quite a mess in some places
<beerman>
but ditching apache would do a large part
<beerman>
would allow us to shed some old backups too, there are numerous apache backups flying around :D
<jaeger>
I don't think anyone's going to object to that
<SiFuh>
Sounds like a rebuild of the server will be much faster
<beerman>
i would consider the mailer for gitea the last important step
<jaeger>
Maybe under other circumstances but not without some remote KVM or OOB access
<beerman>
after that we could just turn off apache, reconfigure nginx to run on port 80 and 443 and we should just be back to business as usual
<beerman>
with remove kvm or oob you mean solving the space problem for root?
<jaeger>
that was an answer to SiFuh
<beerman>
ah. gotcha.
<beerman>
anyway, everybody would need to register at gitea and set themselves up. core users can be admin users or we stick to gitadmin which i setup already
<beerman>
then we can provision needed access rights for users (e.g. contrib contributors)
<jaeger>
Building a fixed rc5. Need to leave to run a couple of errands, shouldn't be too long. If you want to switch stuff go ahead, I don't have any objections as long as we're not breaking everything
<SiFuh>
You are breaking 3.6 ;-)
<beerman>
as i said, i would like to have the mailer setup before we do that
<beerman>
after that we might want to clean out old user data of sysadmins that left, same as some access of people that are actually not there anymore, looking at /etc/postfix/aliases
<beerman>
i'll just go ahead and do that with postfix aliases right now
<jaeger>
Back
<jaeger>
The mailer works already, is there something else specific you need?
<jaeger>
SiFuh: how so?
<jaeger>
beerman: for clarification, I mean is there some specific configuration, not a user
<beerman>
credentials to use it as gitadmin or noreply or whatever :D
<jaeger>
What user is gitea running as?
<jaeger>
ok, fixed rc5 is uploaded, testing again
<beerman>
user is gitea as well
<jaeger>
Any reason not to use that?
<beerman>
i have no idea how postfix works tbh
<jaeger>
OK, let's try it from the other direction... what exactly does gitea want to send an email?
<beerman>
...
<beerman>
you can register an account yourself, gitea will send you an activation email
<jaeger>
ok, so it does work already?
<jaeger>
I'm confused
<beerman>
it does not
<beerman>
i have no idea what credentials i can use
<beerman>
have a look at /etc/gitea/app.ini under mailer
<jaeger>
It doesn't look like there's any actual login info there
<jaeger>
Since it's running on the same host, any reason not to just configure it to use sendmail?
<stenur>
can just _anyone_ use TAR_WRITER_OPTIONS=xz:threads=$JOBS in /etc/pkgmk.conf and get truly multithreaded xz(1) package compression?
<stenur>
that is, is it only me? it has been broken somewhen.
<stenur>
The same is true for plain bsdtar with options like that, it no longer scales here. It did in the past. Something must have been broken somewhen.
<stenur>
I do not wanna say it is due to c90bc9903078bf0b22bf98c05b4e8b1242f340a3, "libarchive: use cmake", but, you know..
<stenur>
P.S.: i also asked something on libarchive-discuss@, .. and i wonder whether this has something to do with it, too. I mean, that is just bogus, is it, why do _i_ stumble upon it?
<jaeger>
seems to use only 1 thread here
<stenur>
So not only my problem
<jaeger>
yeah
<jaeger>
I added a webhook section to the gitea config so I can test those... should take effect next time it's restarted
<beerman>
restarted
<jaeger>
Looks like it works, I was able to see the hook content. Not doing anything with it yet, just viewing, will turn that into something more interesting in the next couple days
<beerman>
cool
<jaeger>
Maybe tomorrow we can do the release if nobody has problems with the latest rc (if you have time to test it, that is)
Romster has quit [Ping timeout: 265 seconds]
<beerman>
that would be great
<jaeger>
Pretty late for you guys and haven't seen jue today
<jaeger>
man, gitea sends a lot of data to the webhook target URL
<jaeger>
most of it will just be thrown away in this case
<beerman>
ah well, gotta finish on that someday, and i never took time before
<jaeger>
It's not a big deal, just interesting
<beerman>
at least not too much, but i am pretty much finished for tonight
<jaeger>
All good, have a good night
<beerman>
no worries, thanks
<beerman>
what do you think about gitea in general?
<beerman>
is it a worthy replacement in your opinion?
<jaeger>
seems fine so far... will see over time if there are any problems but I'm not really expecting any. I use github, gitlab, and bitbucket concurrently at work, heh... so I can pretty much get used to any of them
<beerman>
gitea is rather lightweight compared to gitlab, not sure about bitbucket, never really had to use it
<jaeger>
They all do the same stuff, just different look and feel. All git under the hood so no problems, really.
<beerman>
but each repository gets its own bug tracker, as well as a wiki
<beerman>
people can register, fork, make pull request to close tickets etc
<jaeger>
yeah
<beerman>
yep, thats true, but having runners (gitlab, github at least) is a difference
<beerman>
i am curious what sepen is setting up for crux-arm on github ci
<beerman>
last time i spoke to jue he mentioned not having a lot of time lately
<beerman>
but i expect he will show up in a bit with the new rc up and all
<jaeger>
yeah
<beerman>
between updates to 3.7 on crux.nu we might want to clean out old packages
<beerman>
how have you gone about that? sed 's/3.6/3.7/' -i /etc/ports/*.rsync and a manual update?
<jaeger>
I would generally update packages from a loopback-mounted ISO first
<jaeger>
then rejmerge/revdep/update the rest
<jaeger>
No reason the server can't build its own packages but my hardware is faster :P
<beerman>
heh
<beerman>
well, okay
<beerman>
i dunno how many of us actually work on crux.nu, if its just us, feel free to clean out installed packages as you see fit, and i can readjust :) nvim and zsh could stay please, but besides that
<beerman>
e.g. there is screen installed, i dunno if anybody still uses screen, because i don't see an active process
<beerman>
i have tmux running
<jaeger>
I think it's just you and me
<jaeger>
I haven't used screen in years, since I found tmux basically
<jaeger>
But yeah, in general I have no objections to removing cruft packages
<beerman>
i could setup a ~/.keepers file for root with stuff i'd like to keep, then you could just pkgfoster your way through
<jaeger>
oops... apparently my updated ISO builder has been shut down for a while, heh
<jaeger>
Ah, its bootloader is hosed for some reason
<beerman>
heh :D
<beerman>
brings me to the point: i might get prometheus exporter on there to setup up some basic monitoring over here
<jaeger>
I've considered that as well, just haven't taken the time to research/test it... I did have netdata running in the past which was neat
<beerman>
i use them elsewhere too with grafana for a frontend which is nice. never setup any alerts for it but the space issue on / would've been a perfect testcase <.<
<jaeger>
Yeah
<jaeger>
At some point in the future I'd like to see if stx can help us get the IPMI device set up, then we could rebuild the server with a larger / partition
<beerman>
that would be great
<beerman>
files.crux.nu would also be nice for distribution