IRC channel logs

<damo22>youpi: how do i implement an OUT ioctl that copies some strings to the client? i cant pack data_t into a struct because mig gets confused when it needs to make copies of strings

<damo22>flavioc: do you have any idea how to make your mig c-like structs obey the SCP servercopy keyword?

<damo22>actually the members inside

<ZhaoM>hi I'm looking for a mail server, the current one (qq.com) I'm using does not support git send-mail *.patch. Any recommendations?

<anatoly>ZhaoM: free account on proton mail with their bridge? Although I don't know if this combination has issue with git's send-mail

<damo22>i use that, it works if you set transferEncoding = 8bit

<damo22>in [sendemail]

<ZhaoM>anatoly: Thank you for suggesting. I'm reading the document about proton mail. I hope it will not be blocked by the Great Fire Wall :P

<ZhaoM>It seems it is blocked. Any more recommendations?

<damo22>ZhaoM: can you use a vpn?

<damo22>the mail will be received

<damo22>but you just need to access it somehow

<ZhaoM>damo22: it will but I think it doesn't worth it. VPN is quite expensive to be honest, and I believe there might be some alternatives

<damo22>ok

<p4r4D0xum>sneek: tell later gnucode test

<sneek>p4r4D0xum, you have 1 message!

<sneek>p4r4D0xum, gnucode says: I've not heard of z2 before! 1200 transistors seems quite a lot for being made at home! also you have the most "heavy metal rock band" sounding irc nick I've ever heard!

<sneek>later, p4r4D0xum says: gnucode test

<damo22>ZhaoM: does qq.com support SMTP?

<damo22>or do you have to send via the web browser

<ZhaoM>damo22: qq.com supports SMTP, but it does not work with git send-email *.patch (i.e. sending multiple patches together)

<ZhaoM>I'm now checking if proton mail SMTP will be blocked by GFW

<ZhaoM>The core function I need is SMTP server

<ZhaoM>I don

<ZhaoM>I don't care too much about other functions

<damo22>ZhaoM: it should work

<damo22>ZhaoM: proton does not support SMTP protocol directly, it has a bridge

<damo22>the bridge runs locally and provides you with SMTP on 127.0.0.1

<ZhaoM>Oh that's cool

<damo22>but it authenticates with the encrypted host

<damo22>ZhaoM: maybe you didnt set up git sendemail properly in your gitconfig for qq.com

<ZhaoM>I don't quite understand the meaning of 'it authenticates with the encrypted host'

<damo22>[sendemail]

<damo22> smtpencryption = ssl

<damo22> smtpserver = smtp.qq.com

<damo22> smtpuser = your-email@qq.com

<damo22> smtpserverport = 465

<crupest>I run a mail server by myself. But it needs to do a lot of things to go through spam blocking.

<damo22> transferEncoding = 8bit

<damo22>ZhaoM: try with that config and send the git patches --to=damien@zamaudio.com to my email to test

<crupest>By the way qq mail needs to create a special password from web. Your login password is not usable.

<ZhaoM>crupest: I'm quite interested in running a mail server, could you suggest some document?

<ZhaoM>damo22: don't worry I will --to=myself

<damo22>ZhaoM: its very difficult to set up a mail server that doesnt get blocked by gmail etc

<ZhaoM>crupest: I'm using that special password

<crupest>Very complex.

<crupest>Only if you have time.

<damo22>you need SPF DKIM DMARC MTA-STS etc

<crupest>ZhaoM: Let me try at the same time in case you miss something.

<crupest>damo22: Yes

<ZhaoM>OK that's very complex, I will do it when I'm bored :P

<ZhaoM>crupest: Thanks

<damo22>and if you care about security you need to rotate the DKIM keys so you dont have infinite proof that you sent every email

<crupest>Actually I think mail servers by big companies whether in china or not all have many disadvantages.

<crupest>They do many strange things.

<damo22>i use proton as a compromise

<damo22>because i cant be bothered doing a proper mail server

<damo22>you probably need reverse dns ptr record too

<ZhaoM>I tried outlook in the morning and I got stuck at oauth2, it's a bit annoyed

<ZhaoM>damo22: same situation, get error after sending the second patch

<ZhaoM>250 OK ...propagated at /usr/lib/git-core/git-send-email line 1696, <FIN> line 2.

<damo22>what is the error message

<damo22>can you paste the whole output to paste.debian.net with an expiry

<ZhaoM> https://paste.debian.net/1334492/

<damo22>ZhaoM: what is line 1696 of your git send email

<ZhaoM>The problem is that when I try the config you paste with 163.com, it works

<ZhaoM> $smtp->mail( $raw_from ) or die $smtp->message;

<damo22>hmm

<ZhaoM>I guess the tencent SMTP server does not support In-Reply-To or References

<damo22>youre getting an error "progagated"

<damo22>"propagated"

<crupest>250 OK

<crupest> ...propagated at C:/Program Files/Git/mingw64/libexec/git-core\git-send-email line 1737, <FIN> line 2.

<crupest>The same error as yours

<damo22>i dont actually mail from hurd

<ZhaoM>crupest: the problem of qq.com SMTP server

<crupest>Only the first one succeeded.

<crupest>[PATCH 1/4]

<damo22>i havent tried that

<damo22>ZhaoM: can you try mailing from gnu/linux

<crupest>damo22: No, I'm not, too. Actually I sent from Windows.

<damo22>crupest: which smtp?

<crupest>damo22: qq mail.

<ZhaoM>damo22: I'm mailing from GNU-Linux

<damo22>oh

<damo22>ok

<crupest>sendemail.identity=Yuqian Yang

<crupest>sendemail.smtpserver=smtp.qq.com

<crupest>sendemail.smtpuser=crupest@qq.com

<crupest>sendemail.smtpserverport=465

<crupest>sendemail.smtpencryption=ssl

<crupest>sendemail.from=crupest@qq.com

<crupest>sendemail.smtppass=xxxxx

<damo22>maybe the server does not support chaining emails together

<ZhaoM>damo22: exactly

<crupest>damo22: Yes. I think so. The first mail succeeds. But not following ones.

<damo22>can you file a bug with tencent :P

<crupest>damo22: It will ignore.

<crupest>Definitely.

<crupest>😆

<ZhaoM>damo22: Unless I pay for them

<ZhaoM>Always like this

<damo22>i dont know then

<crupest>No. Depends on how much you pay. hahahaha

<damo22>find a different smtp server that supports it i guess

<crupest>Whatever, we should find a solution.

<ZhaoM>Email is not popular in China, so they don't spend much time on it

<ZhaoM>I will try Proton mail

<crupest>damo22: I think this is the only solution.

<crupest>You can't change the mail server vendor.

<crupest>I remember you said163.com is OK? Why not using that?

<crupest>ZhaoM: I only use it for open source projects and in my company internally before. For personal things, no, we don't use email at all.

<damo22>ZhaoM: you can use mutt with gmail smtp

<crupest>damo22: That also needs a VPM from china.

<crupest>VPN

<damo22>doh

<ZhaoM>crupest: I just want to try Proton :P. I may still use 163.com eventually.

<crupest>damo22: Not DNS pollution. The ip is blocked by ISP.

<crupest>ZhaoM: Great.

<damo22>if we want proper GPU support, we need to implement the "kms" subsystem and "drm" subsystem on top of that

<damo22>but i am very tempted to skip modesetting for now so we can get multiboot framebuffer as a main memory backed display

<crupest>damo22: I think so. This is a very difficult way but also the simplest way. Based on my previous working experience on GPU driver, the drm framework is much more complex than someone might think. But one idea is we can find a relative old version of drm, which is simpler to implement with only disadvantage of not supporting some new GPU. But I think compared to development complexity, this is much acceptable.

<crupest>Even in implementation on Linux, there are many ugly problems. There are a lot of ioctl command. And it highly tights with userspace library. Different GPU manufactures have many their own private things besides the common framework. You can check the document of Linux drm, which is complex enough.

<damo22>as far as i can tell, drm is about buffer management and quite high level display properties

<damo22>while kms is deeper in the hardware that sets the framebuffer modes

<damo22>crupest: but my idea is to reuse the grub framebuffer that is already set up as a usable mode and exposed to userspace, and implement a kind of dummy drm driver for it

<damo22>where the buffers are allocated in main memory, not on the gpu

<crupest>That's OK. But what the meaning is to implement drm?

<crupest>If we only use framebuffer.

<crupest>As I can remember, EFI fb is not related to drm.

<damo22>for example, a vulkan backend could be used on our "drm" driver

<damo22>but the rendering will be in software

<crupest>That's reasonable, however.

<damo22>it will just reuse the grub framebuffer

<damo22>then we can avoid the need for kms

<crupest>Sounds good from this point.

<damo22>and our driver will have no hardware acceleration

<damo22>but if someone wants to extend this work, they can add kms

<crupest>I was thinking you were going to make GPU works.

<crupest>damo22: Of source.

<damo22>and the real gpu drm drivers

<damo22>can be added as well

<damo22>if we make a compatible interface

<crupest>So you want to make a drm and so we can use mesa to implement a software OpenGL and Vulcan? I remember mesa already has software implementation of OpenGL but I don't know about vulkan.

<damo22>the existing libdrm can be ported to access our drm server

<damo22>then everything else will just work on top

<damo22>eg mesa

<crupest>Great idea I think.

<damo22>and if we make the drm server a compatible api, it will be easier to add real gpu support later

<damo22>apparently GL is implemented in vulkan now

<damo22>crupest: eg this is what i have so far https://git.zammit.org/hurd-sv.git/commit/?h=drm-server-ioctl

<crupest>I have to say it is still super difficult. drm is really just a framework and a bunch of related abstract concepts. GPU drivers share some common codes. But private code of one GPU driver is much more than common things. If you like, you could take a look at linux drm drivers at https://github.com/torvalds/linux/tree/master/drivers/gpu/drm. And as an example, i915 is integrated GPU driver of Intel. Files in that dir is not less too much. But of course we can d

<crupest>damo22: I'll take a thorough look on your work definitely.

<damo22>i agree, most of the hard code is in the hardware specific code to allocate buffers on the card and do the modesetting

<damo22>but if we already have a framebuffer, we dont need to modeset anything, and we dont need to allocate anything on the card if we use main memory for pixel buffers

<crupest>But OK. That's a long story. We don't have to pay too much attention on real complete drm. We just do what we can now. This makes much more sense than talking about the complexity.

<crupest>damo22: I remember Linux has made a simple drm based on EFI fb.

<crupest>Let me have a check.

<crupest>Seems I found it.

<crupest> https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/tiny

<crupest> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/tiny/simpledrm.c

<crupest>However, this seems to highly tight to Linux framebuffer driver.

<damo22>what i have written is the ioctl interface with all functions stubbed

<damo22>i can implement them one by one as needed

<crupest>OK. I think I understand you now.

<crupest>The drm is just interface but does not do any actual things.

<damo22>yes!

<crupest>Nice way!

<damo22>it just allows ioctl() not to fail

<crupest>I see.

<damo22>but if something is strictly required to return a value, we can do that

<crupest>I think I misunderstand you again. I thought you were going to actually implement a framebuffer drm.

<crupest>But your idea is much nicer.

<crupest>I will try to help you.

<damo22>i sent email to the list

<damo22>asking for specific help

<damo22> https://lists.gnu.org/archive/html/bug-hurd/2024-11/msg00026.html

<damo22>"(10:20:55 PM) crupest: I think I misunderstand you again. I thought you were going to actually implement a framebuffer drm." i do plan to do that, using the minimum number of ioctls required to do that

<damo22>the rest can return 0

<damo22>i already have access to the multiboot table that has framebuffer information

<damo22>i can use that to populate the available mode

<hakanrw>damo22: best of luck!

IRC channel logs

2024-11-04.log