IRC channel logs

<gnu_srs1>youpi: Can you please GB help2man. Cannot find a reason why it should fail? Builds fine locally.

<youpi>the reason probably got fixed in between

<gnu_srs1>BTW: mahler is up again :)

<youpi>ah, thanks, starting it again

<youpi>we have a bunch of new rust packages to build, it's welcome :)

<Pellescours>mahler is a single machine that build debian packages?

<youpi>there are two such machines

<youpi>better have two than just one when there is much to build

<Pellescours>does they build in SMP env or not yet?

<youpi>smp is not stable enough for now

<Pellescours>I not mean full boot smp but full build smp (thanks to damo script)

<youpi>I can surely try, but I'm next to sure that there will be issues

<youpi>unless people really give it a hard try (i.e. not just build gnumach, but e.g. gcc or such really large package), I can't really make buildds testboxes for smp, at some point I really just not have the time to fix the mess there after crashes etc.

<youpi>the paging issue is already tedious

<youpi>gnu_srs1: help2man built fine indeed, thanks

<gnu_srs1>YW :)

<damo22>yeah, the reason i made the script in the first place is to make it easier for us to test smp

<damo22>but we do need to actually test it

<damo22>do we have updated "make" for NOTPARALLEL?

<damo22>Pellescours: i force pushed my rumpkernel so it builds now

<damo22>with rumpnet support

<damo22>in develop branch

<ZhaoM>hi

<ZhaoM>sneek: botsnack

<sneek>:)

<sneek>Welcome back ZhaoM!!

<ZhaoM>ok for confirmation, now mach uses PIT with 100 Hz IRQ 0

<ZhaoM>if we use elapsed_ticks in clock_interrupt() as CLOCK_MONOTONIC

<ZhaoM>then the precision of our CLOCK_MONOTONIC will be 0.01 s

<ZhaoM>I don't quite understand what's the meaning of 'IRQ on terminal count' in https://wiki.osdev.org/Timer_Interrupt_Sources#PIT

<ZhaoM>It seems a better implementation is using HPET to emulate PIT for timer interrupt, but it's quite involved :/

<damo22>already done

<damo22>--enable-apic has this

<ZhaoM>ah cool

<ZhaoM>so maybe I just need to access HPET in clock_gettime(CLOCK_MONOTONIC..)

<damo22>see i386/i386/apic.c

<ZhaoM>in i386/i386at/model_dep.c hpet_init() is put inside a NCPUS>1 #if

<damo22>ah yes, you might need --enable-ncpus=N

<damo22>where N > 1

<youpi>it doesn't really matter if it's HPET or PIT for CLOCK_MONOTONIC

<youpi>just as much as it matters for CLOCK_REALTIME

<youpi>you can take the best that is available, but yet again: CLOCK_MONOTONIC does not really require more precision than what we already have

<damo22>if you dont care about 0.01s granularity, you can just use elapsed_ticks

<youpi>we don't

<ZhaoM>ok

<damo22>which already handles all the implementations

<ZhaoM>i'm just a bit curious about those timer sources

<damo22>TSC is good but hard to calibrate

<damo22>HPET is easiest solution

<damo22>to replace PIT

<ZhaoM>i see

<ZhaoM>TSC depends on CPU cycles

<damo22>yes

<youpi>which thus depends on throttling and whatnot

<ZhaoM>cool

<ZhaoM>BTW a bit stupid question, is the correct way of testing gnumach using apt-source and 'dpkg -i'?

<ZhaoM>on an existing GNU Hurd virtual machine

<damo22>ZhaoM: i think gnumach is so close to being on upstream version in debian now, so you can even build savannahs version and install it to /boot

<damo22>at least that has been my experience

<youpi>yes, it should be fine too

<ZhaoM>what's the best way to restore from installing a broken kernel? Always have a copy of img file?

<damo22>cp gnumach.gz /boot/gnumach-some-other-name.gz

<damo22>then select the test one in grub

<ZhaoM>nice method, i didn't think of it

<ZhaoM>thanks guys, i'm going to start on it :)

<ZhaoM>what does the 'host' refer to in host_get_time() (kern/mach_clock.c)?

<damo22>most likely the machine itself

<damo22>mach is an abstraction

<ZhaoM>ok i supposed it refers to something like 'user'

<ZhaoM>elapsed_ticks is only incremented in the timer interrupt handler (i.e. clock_interrupt()), do i need to be aware of data race while reading it?

<damo22>there is a special macro for doing it

<ZhaoM>would it be possible to have one thread in the timer interrupt handler while another thread reading elapsed_ticks?

<ZhaoM>read_mapped_time?

<damo22>i dont think you need a separate thread just to read the time

<ZhaoM>i mean would it be possible to have data race

<damo22>theres already code that updates the value

<damo22>i think youre just checking that number

<damo22>if you just miss an update, your value will be 0.01s out

<damo22>i dont think it matters that much

<ZhaoM>ok

<ZhaoM>indeed :P

<damo22>as long as the clock doesnt go backwards

<damo22>because monotonic increasing clock has assumption that newer value will be later in time

<damo22>hpet wraps at 0xffffffff

<damo22>not sure how you handle that

<damo22>but elapsed ticks should handle up to its maximum width

<ZhaoM>what does 'wraps' refer to?

<damo22>ZhaoM: the hpet is 32 bits

<Ribby>More hurd people than linux-libre people?

<damo22>the timer goes from UINT32_MAX to 0 when it increments it wraps to zero

<damo22>see the comment in apic.c

<damo22>Ribby: welcome

<damo22>0x1 0x2 0x3 ... 0xffffffff 0x0 0x1 ....

<Ribby>I was just wondering if hurd is as libre and linux-libre? Or that it would not be a viable option so BSD kernel is an alternative.

<damo22>Ribby: hurd is gplv2+ and once all the legacy code is replaced with userspace drivers, there is no reason the HURD OS cannot be gplv3+

<Ribby>Okay, so it's a work in progress. No problem.

<damo22>we dont use bsd kernel, we use GNU Mach

<damo22>its a microkernel, so there are not supposed to be any drivers in it, it is minimal and provides just the bare essentials to run the memory and communication for the system

<damo22>the system is mostly done and complete, but lacks drivers for lots of hardware

<Ribby>Testing with both Linux-libre and BSD kernel images may help.

<damo22>?

<damo22>GNU/Hurd is built around a microkernel model of operating system, it does not run with a monolithic kernel like bsd or linux

<damo22>Remote procedure calls (RPCs) are used to communicate between processes to connect things together

<damo22>so if you need a new feature backed by hardware, you can implement a new server called a "translator" that provides access to a new device node and exposes some new RPCs

<damo22>hurd is infinitely extensible

<ZhaoM>damo22: I found another variable maybe can be used for CLOCK_MONOTONIC

<ZhaoM>time_value64_t time = { 0, 0 }; /* time since bootup (uncorrected) */

<ZhaoM>in mach_clock.c

<ZhaoM>but i'm not sure what's the meaning of 'uncorrected'

<damo22>im not sure either

<Ribby>In your opinion, do you think that the Linux kernel gone too proprietary to the point that Hurd kernel needs development?

<damo22>Ribby: i contribute to hurd mainly because i like the concept of a microkernel os, but also, i can see it has potential to replace linux on my desktop one day

<Ribby>Sounds like a good reason. As for Hyperbola, it's probably more compelling since its current kernel is Linux-libre.

<ZhaoM>Ribby, damo22: the same reason for me, interested in microkernel

<damo22>also id like to see the original free software os completed to the point of being practically usable

<Ribby>so microkernel as in the basic necessities for OS operation, got it.

<damo22>"microkernel model" means everything is split into modules that are separate for operation, for example in hurd if the network driver crashes, it doesnt oops the kernel and you can just restart that component in isolation

<damo22>in linux, if there is just one bug in the kernel, the whole thing comes crashing down

<damo22>or may persist some invalid state that cannot be recovered until reboot

<damo22>its a small miracle it runs at all

<homo>I think hurd is better alternative to linux-libre simply because there is no need to remove proprietary parts every release, someone has to constantly monitor commits to make sure linux-libre is clean

<damo22>homo: there is no reason a proprietary driver cannot be written for hurd userspace

<damo22>so if you dont want any, you will still need to monitor the applicatoins

<homo>if there is proprietary driver for hurd, it won't be shipped as part of hurd, nor as part of guix

<damo22>right

<Ribby>good contingency design.

<damo22>the core could be gplv3+

<damo22>the only reason its not, is because it currently links to some old linux 2.6 code for some ancient drivers that we are hoping to remove soon

<damo22>but they are still occasionally handy to provide net/disk access in kernel for experimenting with new userspace drivers

<homo>agplv3+ seems like the best option in case some proprietary server uses free software code

<homo>when free software object code gets linked into proprietary binary that is

<damo22>you cant link gpl code into proprietary binary

<damo22>it doesnt have to be AGPL for that

<homo>but isn't remote server that doesn't get distributed to anyone an exception to regular gpl?

<damo22>if they run a webserver that is run by gpl software, then the agpl is useful there to force them to publish their changes to the source

<homo>yes, for this reason I think it's best to license as much under agpl as possible, to prevent such proprietary servers from linking free software code without sharing it

<damo22>otherwise if its just gpl they can not share the source with anyone and run a service as a software substitute SaaSS

<damo22>but im not sure if an operating system would be ideal as AGPL

<damo22>for example, if a database server was published under AGPL, how do they share changes to the source??

<damo22>it must be done on the wire

<damo22>it only really makes sense for software that exposes a web interface i think

<damo22>but im not a lawyer

<homo>I think about situations when someone might copy some code from kernel and embed it into a server binary

<damo22>microkernel is tiny, it has barely anything in it

<homo>or let's take libraries as another example, if they are licensed under agplv3, server cannot legally be proprietary

<homo>or do I misunderstand agpl?

<damo22>im not sure

<damo22>i thought agpl products need a way to display a link to source changes

<damo22>in the product itself

<damo22>if the product is not being served over a network connection that is difficult

<damo22>it maps onto webserver software pretty well

<homo> https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingRemotely

<damo22>yea

<damo22>so if a client software is agpl, it has to be able to provide source to the server as a user ! lol

<homo>hm, if irc client is licensed under agpl and it connects to irc server...

<homo>I guess we need to move this discussion to #fsf

<damo22>yeah

<gfleury>Hi

<damo22>\o

<gfleury>IS there any reason on my cachy OS configure gnumach does'nt work. It fails while patching config.status. i have checked in config.status the dummy part IS not present like on my debian

<damo22>autoreconf -fi ?

<damo22>i always run that before configure

<damo22>reminds me, i need to fix parallel smp again

<gfleury>yes i have done autoreconf -fi. configure fails while patching config.status. the ugly hack in configure.ac some how does'nt here

<damo22>hmm works here

<damo22>im on debian hurd

<damo22>PASS!

<damo22>irqhelp: cannot start this irq thread

<damo22>rumpdisk random init open failed

<damo22>hmm

<damo22>solid_black: -smp 2 fails with irqhelp: cannot start this irq thread

<damo22>when trying to run rumpdisk

<solid_black>hi

<solid_black>I'll have to run now, going to look into it later

<damo22>ok

<solid_black>but please look at *how* it cannot start the thread

<solid_black>like what's the error code

<damo22> if (!irq)

<damo22> {

<damo22> log_error("cannot start this irq thread\n");

<damo22>the parameter is passed in as null

<damo22>into the server loop

<damo22>hmm

<damo22>time make -j6 gnumach.gz

<damo22>real 1m11.500s

<damo22>without slave pset, real 1m14.610s

<damo22>smp is not very efficient it seems

<damo22>maybe it will help when it boots up with smp

<damo22>its probably bottlenecked on some process

<youpi>rather use cpu-intensive workload

<youpi>gnumach has a lot of small files, so you get eaten by the i/o workload

<damo22>aha

<damo22>havent had it crash yet

<damo22>i wish i could figure out this problem with rumpnet receiving packets going missing

<damo22>10.99.x rump seems to work btw

<damo22>but there may be a race with -smp 2

<ZhaoM>hello

<ZhaoM>so after i run `make DESTDIR=~/gnu install-data` in gnumach, I cannot find mach_host.h in ~/gnu

<ZhaoM>isn't it the way to get the gnu mach header files?

<gnu_srs1>youpi: Can you please buil gcr4-4.3.0-1 w/o tests: failing ones are:

<gnu_srs1>33/39 gcr:gcr / secure-memory FAIL 0.24s killed by signal 6 SIGABRT

<gnu_srs1> not ok /memory/alloc-oversized - Gcr:ERROR:../gcr/test-secure-memory.c:146:test_alloc_oversized: 'mem' should be NULL

<gnu_srs1>37/39 gcr:gcr / gnupg-process TIMEOUT 30.01s killed by signal 15 SIGTERM

<gnu_srs1>That package is needed to build gvfs-1.56.1-1, for which several patches are needed . (bugreport will be sent to Debian soon)

<gnu_srs1>Latest successful build was 1.53.90-2.

<solid_black>ZhaoM: that does sound like a correct way to install data

<solid_black>does it install anything?

<youpi>it's installed

<Pellescours>for gnumach it's due to latest version of autoconf 1.17

<Pellescours>debian is still on 1.16, but they change something that make the hack don't apply for this version

<ZhaoM>Pellescours: the version of autoconf package?

<youpi>automake rather

<gnu_srs1>youpi: tks. Bug report on gvfs-1.56.1-1 is coming.

<ZhaoM>my current automake is automake/unstable,unstable,now 1:1.16.5-1.3 all [installed]

<ZhaoM>so what should I do to solve the issue?

<Pellescours>ZhaoM: it works with 1.16, but is broken with 1.17

<Pellescours>basically what I do currently is to comment the section that tries to patch and build in before the files that would have been build with it https://github.com/etienne02/cross-hurd/blob/archhurd/compile.sh#L166

<Pellescours>because I tried to fix it but was not able

<ZhaoM>solid_black: https://paste.debian.net/1340089/

<ZhaoM>Pellescour: but mine is 1.16 but i didn't see the header file I'm looking for

<Pellescours>ZhaoM: are you cross compiling or compiling feom a hurd itself?

<ZhaoM>from another hurd

<solid_black>ZhaoM: ah, I see

<ZhaoM>1speaker@debian:~/gnu$ dpkg -S mach_host.h

<ZhaoM>libc0.3-dev:hurd-i386: /usr/include/mach/mach_host.h

<solid_black>mach_host.h is the user MIG header for mach_host.defs

<ZhaoM>ah maybe it's the issue

<ZhaoM>so mach_host.h is not generated from gnumach?

<Pellescours>you can actually use the one from the host if you don't modified it

<Pellescours>ZhaoM: it's provided by libc-dev package

<Pellescours>so comming from gnumach but build in glibc

<ZhaoM>ok cool

IRC channel logs

2024-12-16.log