IRC channel logs


back to list of logs

<damo22>spk121: you might have more luck with qemu
<damo22>janneke: i like your, we could possibly recreate the repo from scratch so it doesnt contain the extra 1.1G
<damo22>but ideally there would be a reimport script that can update the repo from upstream
<damo22>currently, is a clone of netbsd src tree
<janneke>damo22: ah yes, that would be great
<damo22>youpi1: how difficult is it to replace a debian package with new source tree? i think we should "prune" rumpkernel like janneke suggests
<damo22>i imagine its more difficult if its already in savannah for example
<youpi1>damo22: there aren't that many commits in the debian repo, we can probably rebuild a tree that ends up the same
<damo22>youpi1: yes, i was thinking the same, but i was asking if its possible to actually replace the repo
<damo22>eg on salsa
<damo22>or do we rename the package and discontinue the old one?
<damo22>i vote we rename it to rump-drivers
<youpi1>yes we can, we can unprotect branches etc.
<youpi1>renaming a package is a bit tedious because we have to drop old names etc.
<youpi1>while we can as well just force-push
<youpi1>for people who will have cloned that doesn't change much compared to another repo
<youpi1>and it's simpler
<damo22>ok so anyone who has a copy is recommended to clone again
<damo22>i can rebuild a tree now and upload to for review
<youpi1>clone again, or reset --hard origin/master
<youpi1>actually reset will work quite well, since most files will have the same content already, and git will know hat
<damo22>im not sure if garbage collection is automatic
<damo22>their tree could still be large for existing clones
<youpi1>it's not automatic
<youpi1>they may want to either gc or re-clone indeed
<janneke>damo22: before you do this you might want to see if it can be pruned further?
<damo22>yes i guess so
<youpi1>that'd be useful :)
<janneke>i've tried a lot of things, and one earlier try suggested that sys/external can be pruned further:
<janneke>prune: Delete sys/external, except bsd/{common,drm,drm2,dwc2,libfdt,libnv,sljit}, isc.
<janneke>...but i'm not 100% sure and it "felt better" to just keep all of "sys/external/bsd"
<janneke>anyway, testing this on a smaller archive should be a lot friendlier, so you/(we?) could consider looking at that later
<damo22>i can try pruning what you have done and see what is left
<janneke>sure, that's a great start
<damo22>i am going to redo the script so it does not use git to restore anything, so we can use it to prune a new tree that we do not want version controlled for the changes
<janneke>yeah, that makes sense
<damo22>but thanks for the start
<janneke>thanks for picking this up!
<janneke>ACTION wrote something like that (i.e., without git) in the guix scheme snippet
<janneke>but i guess it's kinda obvious...
<damo22>janneke: i have a new rumpkernel repo that is 144M
<janneke>damo22: whaaat? oh, that's waaay cool
<damo22>yea, but just the .git
<janneke>ah okay ;)
<damo22>including all the files checked out its 653M
<damo22>better than my old one which is 2G
<janneke>and without .git, just a du -schx *?
<janneke>ACTION had 536M for that
<damo22>i need to check if it builds, but here it is
<janneke>ACTION will try a build too
<janneke>ACTION applies their guix cross build patches locally
<damo22>its in master
<damo22>i think develop branch is missing your patches
<janneke>ACTION looks
<damo22>i had trouble building with master
<damo22>so i rolled back and applied a patch
<janneke>np, thanks for the headsup
<damo22>janneke: i highly recommend this if you get into debugging hurd with qemu shell: -chardev socket,id=net0,host=,port=9999,ipv4=on,server=on,telnet=on -monitor chardev:net0
<damo22>if you pass that to qemu, you can "telnet localhost 9999" to access the (qemu) shell
<janneke>damo22: noted, thanks!
<janneke>damo22: it bulds for me, now to test in in a vm
<janneke>ACTION may have to go afk, so no worries if my report comes later
<damo22>i got a signal 11 on a touch command
<damo22>but i rebuilt and it passed
<janneke>damo22: it works for me! \o/