<mtrbot-ml>
[mattermost] <sb10q> whitequark: what got merged?
<mtrbot-ml>
[mattermost] <sb10q> @astro I would put the mattermost-github-integration package into the nixbld-etc-nixos folder. also, no need to create git branches.
<mtrbot-ml>
[mattermost] <sb10q> this thing has an impressive list of dependencies for performing such a simple task...
<mtrbot-ml>
[mattermost] <sb10q> @astro in general we should not do ``pkgs ? import <nixpkgs> {}`` elsewhere than in top-level files
<mtrbot-ml>
[mattermost] <sb10q> because, if we forget ``inherit pkgs`` somewhere when using files that do ``? import ...``, instead of throwing an error, it might silently take a different nixpkgs
<mtrbot-ml>
[mattermost] <sb10q> @astro also iirc ``src = null`` in ``mkDerivation`` does nothing. ``null`` is the default already
<cr1901_modern>
sb10q: No, I live in a suburb of Philly. If someone were in the NY area depending on circumstances, I would go to NY to meet them for the day tho (though Philly is MUCH preferred)
rohitksingh has joined #m-labs
sb0 has joined #m-labs
rohitksingh has quit [Ping timeout: 276 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 276 seconds]
attie has quit [Ping timeout: 246 seconds]
<lkcl>
Astro-, astro, sb10q, sb0: not sure what the discussion is, if it involves putting package / distro specific build scripts directly into the nmigen git repository i strongly *strongly* advocate following debian policy instead.
<sb0>
lkcl: what are you talking about?
<lkcl>
debian's policy is that the build scripts be managed by a completely different process, which involves in many cases now an automated system git-build-package
<lkcl>
the point is: bugs and upgrades in the *package* scripts should *NOT* bleed over into the *package*
<lkcl>
sb0: "[mattermost] <sb10q> @astro I would put the mattermost-github-integration package into the nixbld-etc-nixos folder. also,"
<lkcl>
so if that means "we are planning to add nixos build package information directly into nmigen", i strongly recommend NOT doing so
<lkcl>
sb0: with no context for the discussion... ahh ok.
<lkcl>
oo interesting
<lkcl>
that's a gitlab instance, right?
<lkcl>
ohh and of course, this is #m-labs, not specifically #nmigen.
<lkcl>
yes, sorry, got it.
<sb0>
it's gitea, not gitlab
<sb0>
gitlab is bloated
<lkcl>
yes it is... i evaluated it for libre-riscv.org, i would have actually had to upgrade massively to a GBP 24 / month mythic-beasts VM to host it (a 3x increase in the cost)
<lkcl>
looks really nice, good to know it exists.
m4ssi has joined #m-labs
felix_ has quit [Ping timeout: 252 seconds]
felix_ has joined #m-labs
attie has joined #m-labs
<whitequark>
sb: the yosys pr required for stripping src attributes
<whitequark>
lkcl: that debian policy is in direct conflict with user needs, of course
<whitequark>
that was very obvious with solvespace.
<whitequark>
anyway, the linux packaging eventually pissed me off enough that i stopped providing any kind of linux packages whatsoever. of course, you could still get them for windows and macos.
<sb0>
how is the windows situation better?
<whitequark>
sb0: solvespace for windows is a single exe file. you download it and run from wherever.
<sb0>
and you can't do that on linux?
<sb0>
statically link everything
<whitequark>
sb0: nope
<whitequark>
first, it's opengl.
<whitequark>
second, if you don't dynamically link the UI toolkit, you will fuck up themes, and it will become unusable on HiDPI displays
<whitequark>
Skype does statically link the toolkit, and is unusable
<whitequark>
but libraries aren't even the problem here
<whitequark>
it's more that you're supposed to follow FHS and you'll get crucified if you don't, so I do
<whitequark>
but there's no standard package format
bluebugs has joined #m-labs
bluebugs has quit [Changing host]
bluebugs has joined #m-labs
<sb0>
if it's a single binary file, you can also ignore FHS. and following it is as simple as copying that binary into /usr/lib, no?
<sb0>
*/usr/bin
<whitequark>
then you don't get a MIME type association, for example
cedric has quit [Ping timeout: 276 seconds]
<sb0>
do you get that on windows with the single exe?
<whitequark>
sure, it's built for that. open with, and it remembers where it is
<whitequark>
on macos too, it remembers where the actual app is for its package name
<sb0>
okay, but KDE also provides that feature
<whitequark>
it's beside the point because you *have* to dynamically link to GTK
<whitequark>
there's AppImage, and it has the same problem, so I can't use it either...
<sb0>
what problem, UI themes?
<whitequark>
yeah
whitequark has quit [Ping timeout: 252 seconds]
whitequark has joined #m-labs
<mtrbot-ml>
[mattermost] <pkulik> @sb10q did you review metlino schematics?
<mtrbot-ml>
[mattermost] <sb10q> @pkulik only briefly. I found a few issues that I reported, including a major one with transceiver clocking
<lkcl>
whitequark: users don't get to see it. it keeps the package's modifications (bugs, revision number increases) totally separate from *maintainer*-specific changes / bug-fixes-in-packaging-scripts / etc.
<lkcl>
initially i really didn't like it (at all) but then i made a mistake in the packaging scripts and was forced to do a completely unnecessary version bump of the software that had absolutely nothing to do with the debian packaging error
<whitequark>
that's kind of orthogonal
<lkcl>
whitequark: "i stopped providing any kind of linux packages whatsoever"
<lkcl>
that's extremely sensible.
<lkcl>
basically, it's not your problem / expertise
<whitequark>
it is
<whitequark>
it is my problem because debian is slow as hell
<lkcl>
if the package is good enough (and nmigen definitely is) a maintainer will pick it up
<whitequark>
actually, migen isn't packaged still
<whitequark>
but i was talking about solvespace
<lkcl>
ooo parametric 3D CAD, oooo :)
<whitequark>
so you know what the users of solvespace resorted to?
<whitequark>
running the windows nightlies in wine.
<whitequark>
because debian failed them.
<whitequark>
shrug.
<lkcl>
that's lame... and sounds like they were trying to do something well outside of their area of expertise
<whitequark>
people who use a 3d CAD will not and under no circumstances have an obligation to be experts in software.
<whitequark>
and if the consensus among linux users is that they should, then i will recommend windows instead.
<lkcl>
the irony is of course that parametric 3D CAD requires them to be exactly that :)
<whitequark>
that's bullshit and you know it
<lkcl>
i use pyopenscad.
<lkcl>
yes there's levels / degrees of expertise in programming
<whitequark>
solvespace is completely visual
<lkcl>
openscad (or, *any* non-mainline programming language) is so bad (so feature-sparse) i couldn't stand it
<lkcl>
found something called solidpython (this was years ago)
<sb0>
whitequark: btw, why are you using debian?
<lkcl>
it was abandonware at the time
<lkcl>
i developed a spline-curve surface generator for it
<whitequark>
sb0: because i strongly dislike nixos for its inability to use shared libraries correctly, and any other distro is just as crappy
<whitequark>
sometimes in different ways
<lkcl>
specify a sheet of 3D points, plus the "depth", and it does spline curve interpolation, works out the normalisation vector at each point, and creates a massive polygon.
<sb0>
arch linux is much more up to date and less buggy IME
<lkcl>
sb0: yehh, except if you don't keep up-to-date, you risk being caught out.
<sb0>
for example IME debian systems never reboot after a dist-upgrade. this never happened to me with arch.
<lkcl>
i had that happen to a major project, put a lot of work into getting it up and running
<lkcl>
sb0: if you go from stable to stable that absolutely should not happen.
<whitequark>
sb0: so i don't really want to use a different distro on a server and on a desktop
<lkcl>
if however you're running heavy modifications, or are on debian/testing, you absolutely should not be doing dist-upgrade anyway
<keesj>
I need to generate some gears and going through my options (again)
<lkcl>
i had a laptop system i *never* did a dist-upgrade on, for 10 years, running perfectly fine.
<whitequark>
lkcl: again, solvespace doesn't involve any programming
<keesj>
I want to motorize a globe
<whitequark>
like ... most parametric CADs out there
<whitequark>
and it can't, because the internal representation is NURBS and not CSG
<lkcl>
parametric i tend to think of as "programming". is it more like FreeCAD, then?
<lkcl>
where parameters are dropped into dialog boxes to specify bounds and relationships (inner/outer, that sort of thing)?
<whitequark>
nope
<whitequark>
no dialog boxes.
<lkcl>
fascinating. i need to take a closer look, then.
<whitequark>
"parametric" means it uses a constraint solver, basically
<whitequark>
as opposed to something like autocad or librecad, which is more or less a vector drawing program
<lkcl>
i have had to get involved in 3D CAD for the EOMA68 Libre Laptop project.
<lkcl>
that sounds definitely worthwhile exploring, appreciated the headsup
<lkcl>
sb0: servers you definitely should not be using anything other than debian/stable plus security updates (and possibly backports), and that is *guaranteed* to provide a clean, stable working upgrade path, tested tens of thousands of times by several people world-wide prior to release
<lkcl>
desktops: far less critical, i just use debian/testing and just... keep on apt-get installing packages
<whitequark>
debian security updates are kind of trash though
<lkcl>
pulls in a different kernel every year? no problem. pulls in a new version of libc6 occasionally? no problem.
<whitequark>
i used to think they're useful, but they're not
<sb0>
lkcl: lab.m-labs.hk runs debian, and I'm not updating it because I'm scared of it not rebooting, which is the usual debian experience
<lkcl>
they do their best, based on CVEs
<whitequark>
because most security fixes don't get a CVE or even are marked as such
<whitequark>
yeah, that's not nearly enough
<sb0>
so it is worse than nixos (which you can't break from updating) in that respect
<lkcl>
sb0: sounds very reasonable to me!
<lkcl>
except... what have you been doing that would make it so risky?
<sb0>
idk. debian always breaks when running dist-upgrade ime.
<whitequark>
when i upgraded from etch they changed hard drive naming from /dev/hdX to /dev/sdX
<sb0>
yeah this kind of problem, for example
<whitequark>
and, debian installer did not use UUIDs then
<lkcl>
have you been making heavy modifications of /etc, or installing...
<whitequark>
today it'll probably be systemd
<lkcl>
eurk yeah
<whitequark>
i actually had that issue
<whitequark>
something with network interfaces
<lkcl>
i absolutely refuse to run systemd, i use angband.pl substitute packages
<whitequark>
yeah so that's an unsupported way to run debian then
<lkcl>
yehh the udev network auto-generated rules can catch people out
<whitequark>
shrug
<whitequark>
it's all trash
<lkcl>
whitequark: i know :) and i'm quite happy with it, because i have enough sysadm experience with debian to cope in a self-supported way
<lkcl>
i'm friends with phil hands, i learned a hell of a lot from him
<lkcl>
he's the debian uk ftp maintainer
<lkcl>
he sponsored me to work on samba, like... eek, 23 years ago! :)
<whitequark>
an os that requires you to be a friend with the debian ftp maintainer for it to be usable is trash
<whitequark>
but we already know that unix was a mistake, so.
<lkcl>
you misunderstand: it's more that i've been around for long enough to have absorbed a lot of stuff in several different areas that, fascinatingly and sadly, i'm finding more and more that people a lot younger than i am are unable to cope with
<whitequark>
lower tolerance for bullshit
<whitequark>
it's good. it means there'll be progress in this area
<lkcl>
i'm not sure if there's even anything that can be done
<lkcl>
heh, that's a good way to put it :)
<lkcl>
sb0: btw a thought: if you rsync copy over the entire m-labs server, and run it inside a suitably-configured qemu VM, you *might* be able to check if it will survive a reboot.
<lkcl>
a power-cut's going to be a damn nuisance...
<lkcl>
rsync the entire drive (raw image) rather than the filesystem, i mean
<whitequark>
you could just boot it on that machine itself
<sb0>
lkcl: that server is shutting down next week. problem solved.
<lkcl>
we're starting a system verilog to nmigen language translator
<lkcl>
i'm getting RSI, and we have a *lot* of verilog (unfortunately written for Cadence sv) that needs conversion
<lkcl>
plus a couple of other projects, totals around 18,000 lines of verilog to convert to nmigen
<lkcl>
so... at that point, it's worthwhile creating an auto-converter
<lkcl>
one of those, "what are you dooooiiiing" moments :)
<lkcl>
starting from icarus verilog's parse.y and lexor.lex i'm putting them through dabeaz yply.py which automatically converts to python-ply format (stubs)
<lkcl>
i am familar with lib2to3's excellent python AST capabilities and its pattern-matching for AST manipulation
<lkcl>
it also has one of the best python prettyprinters around (the lib2to3 AST captures whitespace)
<lkcl>
it'll be a fun little sub-project, funded by the NLnet grant
rohitksingh has quit [Ping timeout: 258 seconds]
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 255 seconds]
X-Scale` is now known as X-Scale
m4ssi has quit [Remote host closed the connection]
sb0 has quit [Quit: Leaving]
mauz555 has joined #m-labs
rohitksingh has joined #m-labs
mauz555 has quit []
mauz555 has joined #m-labs
mauz555 has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 245 seconds]
d_n|a has joined #m-labs
d_n|a_ has quit [Ping timeout: 245 seconds]
<travis-ci>
m-labs/smoltcp#1245 (auto - 0b370a1 : Andreas Molzer): The build was broken.