<gchristensen>
awesome! congratulations, drakonis! what was it about?
<drakonis>
giving folks a primer on the history of distros, the technologies created and how they shaped the evolution of distros
<drakonis>
i mentioned NixOS, couldn't pass it honestly.
<drakonis>
it was my first time, so it wasn't as polished as i wish it could've been
<drakonis>
because today things have changed a fair bit
<pie_>
sounds like you did well for a first time
<drakonis>
i suppose
<drakonis>
now that it is done, time to spin up yet another NixOS™ ISO
<drakonis>
on my flash drive and then install it again, in preparation for my relearning marathon
<drakonis>
so, i'm conveniently rereading the flakes proposal, as it is likely to be the next big change lined up for later this year or early next year
<drakonis>
am i supposed to think that it will change how packaging is done?
<drakonis>
along with fixing up repository hell?
<samueldr>
what's the repository hell?
<drakonis>
the current channel setup gets in the way most of the time
<drakonis>
i can't figure out if i'm pulling from stable or unstable
<drakonis>
its fiddly, that's what it is
<drakonis>
i spend more time fighting with nix-channel at times
<drakonis>
that's about it, and its going away soon, which is truly nice.
<colemickens>
I don't use channels at all, but how are auto-upgrades handled with not-channels ?
<drakonis>
its a mystery to me
<drakonis>
it doesn't seem to play nice with the new model
<drakonis>
channels that is
<samueldr>
easy to answer: autoupgrade calls nixos-rebuild with --upgrade
<infinisil>
Alright I think people should stop complaining then, that ought to be enough
<gchristensen>
+1 :)
drakonis has quit [Quit: WeeChat 2.4]
endformationage has quit [Ping timeout: 258 seconds]
jasongrossman has joined #nixos-chat
<colemickens>
This whole "native Matrix clients" thing is already providing momentum for me to stay with Matrix.
<colemickens>
The couple I'm trying aren't perfect, but the responsiveness is welcomed.
ctp has quit [Ping timeout: 268 seconds]
ctp has joined #nixos-chat
manveru has quit [Ping timeout: 268 seconds]
manveru has joined #nixos-chat
<MichaelRaskin>
colemickens: I want a Matrix client that keeps full logs in text files (and allows command-line control for sending messages), and that seems hard to get…
monsieurp has joined #nixos-chat
<tilpner>
Sending messages into unencrypted rooms can be done even with curl (and better with a ton of available libraries)
<tilpner>
E2E rooms... that's going to be harder
<MichaelRaskin>
Well, there still a need for token management, but true (although client support to use the same token is welcome)
<MichaelRaskin>
Full logs in text… somehow it is complicated.
<tilpner>
FWIW weechat keeps full logs of the channel while it's connected
<tilpner>
They are named after the internals IDs by default, but IIRC you change that
<MichaelRaskin>
I am OK with the IDs part, I want something that can grab bcklog
<MichaelRaskin>
I do use weechat but would prefer something closer to ii behaviour
<MichaelRaskin>
It's annoying that the only plausible benefit of Matrix over XMPP, saner coordination of history storage, is not anywhere near easy to use…
<joepie91>
apparently this does automated testing via simulated user interaction and screenshots and such
<eyJhb>
I always get a little PTSD when I read something like "_OpenCV_ for fuzzy image matching"
<MichaelRaskin>
Meh
<MichaelRaskin>
I have already written fMBT-based tests for LibreOffice.
<MichaelRaskin>
Then they get declared «duplicating NixOS test functionality w.r.t. waiting for virtual X to get up»
<MichaelRaskin>
And NixOS tests are just horribly slow because they need to do a full boot
<MichaelRaskin>
I would find unlikely that NixOS will ever benefit from OpenQA.OpenSUSE
<MichaelRaskin>
I think fMBT has better approach than brute-force OpenCV application for image matching
<MichaelRaskin>
Maybe Nix installation instructions should have the URLs to the script and to the script signature as active links? In that case copying and pasting to bash is a bit safer (and the rest of things can be autocompleted, so retyping is not that hard)
jasongrossman has quit [Ping timeout: 250 seconds]
jasongrossman has joined #nixos-chat
<sphalerite>
tilpner: one peek at tinc's development branch later, I find that the bug I'm trying to work out has been fixed already! It's just not in a new release candidate yet.
<tilpner>
:o
<sphalerite>
hmm, can I reply to an email that I never received..?
<sphalerite>
(when I can access the email via the mailing list archive)
<andi->
why shouldn't you be able to?
<andi->
It is just the In-Reply-To header in most cases that must fit..
__monty__ has joined #nixos-chat
<sphalerite>
andi-: yeah, I just didn't know how to find the Message-Id
<MichaelRaskin>
Show the archive page
<sphalerite>
andi-: but it turns out that mailman generates a handy link that prefills the In-Reply-To header
<MichaelRaskin>
Ah
<andi->
I usually import mailing list archives into a local maildir... Most of the time I am interested in history or replies to old messages :-)
<sphalerite>
how do you do that? :)
<andi->
flokli once wrote a python script for that (https://github.com/flokli/mlarchive2maildir) it isn't perfect and very often I have to adjust it for the flavor of mailing list I am importing.
<sphalerite>
ah ok
<joepie91>
man
<joepie91>
I really miss recursive sets in JS
<manveru>
MichaelRaskin: i wonder if having a different kind of test suite that simply does a nixos-rebuild in between might work for the majority of tests? (though it becomes harder to find whether something really is a bug or from an impurity)
<manveru>
or maybe having a derivation that outputs a snapshot of the initial booted system so it's cachable :)
<joepie91>
manveru: the purpose of the test suite is primarily to *detect* bugs, not to triage them - so I think a test suite that can't tell where a bug comes from is totally fine, so long as it flags it
<joepie91>
(or well, to detect inconsistencies really, not bugs, but same thing)
<manveru>
aye
<joepie91>
it's then up to the human to figure it out and burn down the test env if needed
<joepie91>
:P
<manveru>
if structured right, it could still bisect it for you automatically :)
<joepie91>
aye
<joepie91>
two-phase testing
<joepie91>
only do the expensive thing when a thing breaks
<joepie91>
that's probably what you're thinking of?
<manveru>
yes
<MichaelRaskin>
The problem with the cost of tests is that with a proper approach debugging the test should be a simple nix-build, and have low overhead compared to the test itself.
<MichaelRaskin>
But maybe indeed a Qemu snapshot of booted system to rebuild into a specific test case could help.
<clever>
booting involves restoring db.sqlite from a snapshot, that has a closure of what your testing
<clever>
so it would need to make such a snapshot around stage1 time, and then somehow swap out the stage2 as it mounts the rootfs
pie_ has joined #nixos-chat
<pie_>
joepie91, funny thing, my wine stuff worked before upgrading to 19.03 or something (i was using su -l so the environment should have been okayish...) now after a reboot explorer++ crashes on start :I
<pie_>
ah my permissions are probably broken in the overlay again for some reason...
<joepie91>
pie_: can't win :(
* pie_
flails helplessly
<pie_>
i need to come up with some better way to debug this shit and look for anomalies or something
<pie_>
MOAR ASSERTIONS
<pie_>
dont feel like coding them though :/
<pie_>
now that i think about it _maybe_ wine should/could have better errors
<pie_>
does bash export export a specific value or does it export the key? meaning if you update it, the new value is in the environment of children?
<pie_>
(well i should have probably just run this test to begin with)
<gchristensen>
interesting
<pie_>
same
<gchristensen>
til :)
<pie_>
possibly sligtly more unexpectedly, changing a value after an export will change it for children: $ unset wat; wat=asd; export wat=moo; wat=foo; bash -c 'echo $wat';
<pie_>
foo
<pie_>
obv no change in the semantics but
<__monty__>
Anyone know if once you get a broken pipe with ssh it gets more likely to have it happen again? Feels like it.
<__monty__>
Also, how can an ssh connection between two machines on the same wifi cut out so often?
<MichaelRaskin>
GitHub is again more eventually than consistent…
<gchristensen>
lol.
<pie_>
gchristensen, has nix language versioning had any thought put into it?
<pie_>
ah i may have made too strong an assumption about "deprecation"
<{^_^}>
rfcs#45 (by 7c6f434c, 1 hour ago, open): A small RFC on deprecating URL syntax
<MichaelRaskin>
I explicitly say that URL syntax can only get dropped if another breaking change is heppenning anyway
<sphalerite>
__monty__: it seems to be a nix-specific problem
<pie_>
MichaelRaskin, the specificity to url syntax doesnt really matter, i mean to ask the general question
<gchristensen>
we'll just toss a "use strict;" at the top and call it done trollface.jpg
<MichaelRaskin>
set -e
<pie_>
also i hate to go off on tangents again but i realized i feel like there might be a hole in the rfc process (which i havent really read); what do you do if you want more extensive discussion or something, but dont actually have the material to write up an RFC yet?
<gchristensen>
now we're cookin', MichaelRaskin
<pie_>
MichaelRaskin, NO GOD NO
<__monty__>
sphalerite: It does? ssh isn't installed with nix on either of the boxes I observe this with. Just figured there's knowledgeable people here : )
<joepie91>
pie_: that's a question that's been in the back of my mind for a while also
<sphalerite>
__monty__: oh, and it's not getting run by nix? Then never mind
<MichaelRaskin>
Ask a question on Discourse in your best innocent voice and watch the fallout?
<pie_>
joepie91, the rfc process stuff? if you see anything tell me because its really been bothering me
<__monty__>
sphalerite: No, I run my irc client on a box I ssh into.
<sphalerite>
__monty__: ah right. Yeah then it's probably your wifi.
<pie_>
also all the comms fragmentation is kind of annoying but eh i guess discourse sounds like it makes some sense. but theres at least some overlap between github issues and discourse
<__monty__>
But why is it completely fine one day and snafu the next?
<sphalerite>
__monty__: the typical situation where I get "broken pipe" is when I switch to a different connection
<joepie91>
pie_: yeah, exactly. there seems a gap between "submit a fix for a known and understood issue" and "submit an RFC to extensively discuss something that's already fleshed out"
<joepie91>
I'm missing the option for "we have observed a problem, this needs doing, but I have no idea where to start"
<pie_>
joepie91, yes EXACTLY
<pie_>
"i have no idea where to start" :P
<joepie91>
(and I wonder how much is left on the table because of that)
<MichaelRaskin>
That sounds like an issue then
<sphalerite>
__monty__: might be worht looking at the logs for wpa_supplicant and for dhcpcd to see if it's changing addresses or something
<MichaelRaskin>
joepie91: it's not like we have a lack of already-described issues to fix…
<MichaelRaskin>
So maybe «left on the table» is not the best description
<joepie91>
well, right now they're drowning in "package X is broken" tickets :)
<joepie91>
half the value of the RFC process is having an easy-to-skim list of design issues
<MichaelRaskin>
That's true. Well, [RFC] label on an issue sometimes helps
<MichaelRaskin>
If we used an actual issue tracking system and not GitHub, there would just be multiple trackers for Nixpkgs repo
<joepie91>
I'm pretty solution-agnostic
<joepie91>
so long as it doesn't involve losing an accessible bug-filing avenue
<joepie91>
I just agree that the problem that pie_ describes, exists :)
<joepie91>
somewhat ironically, this feels like precisely the kind of problem to file in such a venue
<gchristensen>
sounds like a good topic for an "office hours" call :)
<joepie91>
but that's still not persistent documentation of the problem :)
<MichaelRaskin>
I think an important thing to understand is: we have very real coordination problems, so RFC tries to put as many restrictions as possible on the process to ensure progress
<joepie91>
I understand that, but I also think that those coordination problems are caused to a significant degree by there not being a consistent global view of What Needs To Be Done
<joepie91>
everybody seems to have their own mental lists of issues
<joepie91>
which is not /wrong/, but if that never coalesces into a shared view of the state of the ecosystem, it becomes very difficult to efficiently coordinate work towards fixing those issues
<MichaelRaskin>
No, the real problem is that often there are two competing and incompatible views of What Needs To Be Done in the same area
<joepie91>
can't say I've seen that.
<pie_>
im not saying the rfc process is bad, im saying i feel like missing the initial stretch of discussion of issues, but maybe thats just me. this isnt a problem if youre well connected and work on the core every da
<gchristensen>
we have IRC and discourse and an issue tracker
<gchristensen>
at any rate. what is your idea that you want to discuss?
<gchristensen>
have you opened a discourse thread about it seeking a co-author?
<joepie91>
gchristensen: sure, but that issue tracker is drowning in packaging tickets
<joepie91>
at the very least, maybe conceptual discussions should be in a separate issue tracker
<gchristensen>
we're talking about too many things to make progress on any of them
<joepie91>
in particular those that don't clearly apply to one piece of the ecosystem
<gchristensen>
I'm focusing on pie's want to make an RFC but it is too early
<gchristensen>
which I agree, the issue tracker is not a great place to start that conversation
<infinisil>
Discourse sounds pretty good tbh
<gchristensen>
yeah
<joepie91>
gchristensen: it's worth considering that a consistent view of all the spinning plates can often help reduce them, by more easily detecting duplication of work, and stuff like "actually, all the edge case work we're doing around this issue is actually totally unnecessary if this other idea to deprecate the feature gets passed"
<gchristensen>
I know
<MichaelRaskin>
If only it didn't mangle the email notifications that badly
<gchristensen>
having a grand view of what is in flight and where things are going is a good thingand a good goal, but not what I'm wanting to talk to pie_ about
<pie_>
this is exactly what im saying though <gchristensen> I'm focusing on pie's want to make an RFC but it is too early
<joepie91>
possibly we need a Pre-RFC category on Discourse?
<gchristensen>
"Development" seems like a good place
<gchristensen>
anyway, I've got to head out, see y'all
<pie_>
gchristensen, o/
<joepie91>
that seems to be a much broader category
<joepie91>
and alright, cya
<infinisil>
pie_: so what is your rfc idea?
<pie_>
infinisil, the tihng ive mainly worked on recently was this plugins stuff, but the question was somewhat separate from that
<pie_>
given that i want to design it as an api that would ideally get applied to the rest of nixpkgs, it seems reasonably to want an RFC eventually
<pie_>
the github issue is currently basically an aggregator of bits and pieces
<infinisil>
Have you done anything not bits-and-piecy?
<pie_>
some, but i feel the project should still be very open ended
endformationage has joined #nixos-chat
jtojnar has quit [Remote host closed the connection]
drakonis has joined #nixos-chat
<MichaelRaskin>
Hm, will all the people nominated to be shepherd have already approved my RFC PR by the moment nomination opens?
<samueldr>
stop breaking the processes ;)
<monsieurp>
hi
<MichaelRaskin>
Hey, I cannot break the process this way — whatever happens, there is a week between opening nominations and proclaiming the shepherd list.
<monsieurp>
what's the rationale for using the Github bug tracker instead of, say, JIRA and Bugzilla?
<MichaelRaskin>
There is quite a bit of avoidance of self-hosting standard components (because it means time and coordination etc.)
<MichaelRaskin>
So, we use a pumpkin instead of bugtracker…
<monsieurp>
I'm not trying to diss the GH bug tracker but for a growing project such as Nix, I'd expect a more "proven" solution such as JIRA or Bugzilla
<pie_>
github probably has positive effects for onboarding
<joepie91>
Bugzilla is godawful to use and JIRA requires significant work to make usable
<joepie91>
I'm not a fan of github, but I'm pretty damn happy we're using it for issues rather than either of those two :)
<samueldr>
wasn't it under a JIRA instance at one point?
<MichaelRaskin>
There was a JIRA instance, sure
<monsieurp>
At Gentoo, devs were (still are) very reluctant to rely on a private company to handle external contributions, we've been using Bugzilla for years and opening up incoming contributions through Github took a while for devs to accept due to GH not being too open-sourcy about their own products
<monsieurp>
even more so now that with the Microsoft aquisition
<MichaelRaskin>
Switching to GitLab would make tooling like ofBorg sanely testable via NixOS tests…
<monsieurp>
joepie91: really? I'm surprised about your experience with Bugzilla
<joepie91>
bugzilla suffers from the same issue as a lot of off-the-shelf bugtrackers: it's designed for people who *only* work with that specific bug tracker, and are used to exactly that interface
<joepie91>
there are a ton of UX issues with it
<joepie91>
and there's no attempt to eg. make the filing interface less cluttered than the management interface, like you'd want for a project taking in filed bugs from the public
<joepie91>
(from what I've seen anyway)
<joepie91>
the UX is just... bad.
<sphalerite>
sounds like a good match for nix :D
<monsieurp>
come on, I think you're being too harsh with Bugzilla devs :) have a look at https://rt.cpan.org/, the CPAN bug tracker, if you want deal with an eye-bleeding UX
<joepie91>
I'm not being "harsh", I'm being blunt :)
<joepie91>
no points in UX for being "not as bad as those other guys"
<monsieurp>
ok so Bugzilla is ruled out because of the UX, fair enough
<monsieurp>
what's wrong with JIRA then?
<monsieurp>
the UI is slick this time round
<joepie91>
"[...] and JIRA requires significant work to make usable"
<joepie91>
JIRA seems very much designed to do everything and to be configurable by the organization using it
<joepie91>
to exactly fit their workflow
<joepie91>
which is a valid design choice, but it means a significant maintenance cost to those operating the bug tracker
<joepie91>
(well, either that, or bad UX again)
<MichaelRaskin>
Redmine is a good tracker, but we are using a disaster called Discourse as a mailing list, which should show what is the chances of self-hosting anything that can be outsourced
<monsieurp>
well... the way I see it is that someone has to take ownership of administrating the bug tracker at some point
<MichaelRaskin>
Watch us _not_ do anything for indefinite amount of time!
<pie_>
im pretty ok with github, whats broken?
<pie_>
jira isnt open source either
<monsieurp>
nothing it's the first time I see a project that big relies on Github :)
<MichaelRaskin>
Single tracker for a project means that the issues are an unusable mess
<andi->
I think issue filtering / categorizing is terrible..
<pie_>
(im not a super avid user)
<andi->
No way to save searches or recall them a week later then bookmarking the page
* joepie91
mumbles 'hotlists
<pie_>
also a lot of jira plugins need to be bought for loads of moneez
<joepie91>
'
<pie_>
(i think?)
* pie_
mumbles something about wishing for better knowledge management..
<MichaelRaskin>
That last part won't happen ever
<pie_>
(which also includes issues)
<srhb>
We can issue track on a mailing list! Two birds!
<monsieurp>
:D
<MichaelRaskin>
Or maybe create an empty repo just for a mailing list in its issues…
<sphalerite>
srhb: like debian?
__monty__ has quit [Quit: leaving]
<monsieurp>
gchristensen: second PR in
<monsieurp>
(if I may nudge you about PRs)
<MichaelRaskin>
I wonder where LOCALE_ARCHIVE note should go in the documentation…
<pie_>
i cannot for the life of me figure out why winetricks isnt setting the virtual desktop resolution...
Guanin has joined #nixos-chat
jackdk has joined #nixos-chat
<pie_>
im feeling an urge to rewrite winetricks in [placeholder]
<samueldr>
bash!
jasongrossman has quit [Ping timeout: 258 seconds]