<lopsided98>
Could someone take a look at it when you get a chance?
<drakonis>
alas i have forgotten how to get allowunfree on flakes
<drakonis>
niksnut said it was just necessary to add it to the repository flake
justanotheruser is now known as justanotherchad
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.5]
orivej has joined #nixos-dev
FRidh has joined #nixos-dev
phreedom has quit [Ping timeout: 260 seconds]
FRidh has quit [Read error: Connection reset by peer]
FRidh has joined #nixos-dev
WilliButz has quit [Ping timeout: 244 seconds]
WilliButz has joined #nixos-dev
justanotherchad has quit [Ping timeout: 245 seconds]
phreedom has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
__monty__ has joined #nixos-dev
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
ixxie has joined #nixos-dev
<FRidh>
gchristensen: should we maybe add a groups list as a field to maintainer-list.nix as well?
<gchristensen>
that could be really cool, especially for "interest group"s
<__monty__>
And also offers a way for peoples to be in maintainer-list but still opt-out of notifications.
<gchristensen>
there is a way
<gchristensen>
the way is to stop being a maintainer
<FRidh>
yes exactly. As we saw in the RFC for different Tiers there is interest in that as well.
<__monty__>
gchristensen: Yeah but maybe someone wants to indicate they're a maintainer, so they can be contacted if necessary but doesn't want to be bothered by the day-to-day of nixpkgs?
<gchristensen>
you'll be notified about your package
<__monty__>
gchristensen: Example, 5 people maintain X, they agree amongst themselves that 1 or 2 will usually handle stuff. The other 3/4 don't want superfluous notifications. But, they do want to be in meta.maintainers for X in case the responsibles disappear/don't feel like maintaining X anymore.
<__monty__>
Being in the list means they can be pinged easily.
<__monty__>
Otoh, I'd be fine with crossing this bridge when we come to it.
<FRidh>
__monty__: if you do not want notifications and do not want to actively maintain, then don't add yourself as a maintainer because in that case you simply are not
<__monty__>
FRidh: Concrete example, I maintain ranger. Others of the ranger team aren't really interested in packaging for nixos necessarily, so they're not in meta.maintainers rn. However, they wouldn't mind being a sort of second line of defense in case I end up under a bus.
<FRidh>
__monty__: what's the point of being a maintainer for a nixpkgs package when you do not use nix? If there are users that have an issue with the expression, the maintainer ended up on a bus, then it is up to those users to pick up maintenance. If they want to, they can contact the authors of the package to help out.
<tilpner>
A not very elegant compromise could be to ping the first n maintainers for a package, sorted by last-seen in a given context
<__monty__>
I'm not sure why having passive maintainers in meta.maintainers is such a problem tbh. I get that it's not *needed* but nothing really is, we're all human we can all just contact eachother.
<tilpner>
That context could be all of GH, all of nixpkgs, or just interactions regarding this very package
<gchristensen>
I guess we'll cross this when we get to it
<gchristensen>
rightnow I'm not planning on doing work to make that possible, it sounds like a lot of work for not a ton of gain
<timokau[m]>
Thanks for putting so much work into this already
<timokau[m]>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 141
<gchristensen>
thanks :)
asymmetric has quit [Quit: Peace.]
asymmetric has joined #nixos-dev
<gchristensen>
how does this list sound for the first, small round of invites: symphorien asymmetric volth evanjs thefloweringash
<gchristensen>
oops, plus these names: Hodapp87 dasJ matthiasbeyer petabyteboy tiplner Taneb
<__monty__>
tiplner is a typo surely?
<tilpner>
I hope so
<__monty__>
I recognize some of these names from active #nixos participation fwiw.
<gchristensen>
yes, tilpner is the only one I manually typed in here :)
<tilpner>
Yeah, I'll probably not be much help c.c
<gchristensen>
Aug 18 09:43:47.203 INFO Would remove user from the team, noops: 1, removals: 1, additions: 8, limit: Some(15), changed: 9, github-id: 76716, nixpkgs-handle: grahamc, exec-mode: SyncTeam, module: rfc39::op_sync_team:133
<gchristensen>
lol.
orivej has quit [Ping timeout: 258 seconds]
FRidh has quit [Quit: Konversation terminated!]
<asymmetric>
gchristensen: would love to help test the process out by being added early :) and I’m relatively free these days (although not the next 2 weeks)
<__monty__>
Welcome to the team, asymmetric ; )
rsa has joined #nixos-dev
<asymmetric>
<3
page_ has quit [Remote host closed the connection]
page has joined #nixos-dev
orivej has joined #nixos-dev
infinisi1 has joined #nixos-dev
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisi1 has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-dev
WilliButz has quit [Quit: WeeChat 2.5]
WilliButz has joined #nixos-dev
WilliButz has quit [Quit: WeeChat 2.5]
WilliButz has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-dev
WilliButz has quit [Quit: WeeChat 2.5]
WilliButz has joined #nixos-dev
<Profpatsch>
Ericson2314: Is there a way to find out int-sizes for cross-targets?
<Profpatsch>
As in, size of short/int/long on a host’s processor?
<clever>
Profpatsch: i think ghc does it by compiling code, then looking at the distance between symbols after linking?
<Profpatsch>
clever: yeah, but that’s not how cross works, right?
<clever>
i believe thats how ghc deals with cross
<Profpatsch>
You can’t determine shit at compile time
<clever>
with native, it can just run a program that will printf sizeof
<Profpatsch>
yes, but that’s a broken strategy
<Profpatsch>
esp. for skalibs, which needs to define pre-processor macros for int sizen
<Profpatsch>
*sizes
<Profpatsch>
Well, they do the detection stuff as well, but that’s build arch, not host arch
<clever>
i suspect ghc does that detection, when ghc is built
<clever>
so it knows what the target arch is like
<clever>
angerman: do you remember where in the codebase that happens?
<angerman>
clever: ghc and autotools do that.
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
<angerman>
Ghc does it via hsc2hs by using the same binary search trick autotools use.
<__monty__>
I wonder if the people with 100+ packages won't be overwhelmed by notifications?
<gchristensen>
dunno :)
<worldofpeace>
tadeokondrak
<worldofpeace>
xrelkd always has to ask for merge for packages they maintain
<gchristensen>
this won't actually solve that, but happy to add them to the list
<gchristensen>
I'm going to do a bit of hydra maintenance and then log off for a bit of weekend time before I'm out of weekend time
<gchristensen>
I'd like more names, maybe as a list on Monday or so?
<gchristensen>
maybe tonight?
<tilpner>
Oh dear
<tilpner>
maintainers = with maintainers; [ ... "1000101" ... ];
<tilpner>
That's not the same as maintainers."1000101"
<infinisil>
Heh
<tilpner>
Do I change that to ++ [ maintainers."1000101" ] or change their name?
<tilpner>
(Are they on IRC?)
<infinisil>
Well having a name starting with a number shouldn't be something bad
<__monty__>
gchristensen: The list of how many packages people maintain is not enough?
<gchristensen>
no that is good
<tilpner>
infinisil: Except it's ugly :c
<gchristensen>
but if there are other special call-outs, those are good
<__monty__>
Hmm, does it make sense to nominate actual nixpkgs maintainers?
<tilpner>
What would they do?
<gchristensen>
eh?
joko has quit [Changing host]
joko has joined #nixos-dev
<worldofpeace>
"I'd like more names, maybe as a list on Monday or so?" Probably could give that, do you have your current compiled list available for viewing
<Profpatsch>
clever: Update, there are no configuration files with the arch data, but you can search for defines like LONG_TYPE_SIZE in gcc/config
<Profpatsch>
They are defined in gcc/config/<arch>/<arch>.h
<Profpatsch>
And I mean once you have the list, it’s data.
phreedom has joined #nixos-dev
<ryantm>
After about 10 to 15 minutes of hanging on that search, it returned a 404 Not Found error page.
<srhb>
worldofpeace: Did you know of someone fixing the sd_image build already? I can't seem to find it anywhere. I assume the firmware partition needs some bumpage.
<srhb>
Eh, I'll just bump it.
<clever>
Profpatsch: ah
<worldofpeace>
srhb: Yeah, last time I checked samueldr had the same thoughts
<worldofpeace>
srhb: Though there were ideas for further actions,
<srhb>
Myeah. I'm not even convinced it works. Opened a pr anyway. :P
<srhb>
Hopefully someone who has the right hardware can test it..
<worldofpeace>
I'd assume we might be in good hands with samueldr then.
<worldofpeace>
else fails we could revert the firmware update :D
<srhb>
Indeed. Ah well, let's give this a try first :)
ixxie has quit [Ping timeout: 272 seconds]
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<samueldr>
thanks for doing the legwork of implementing the fix
<samueldr>
been busy this week-end
<samueldr>
srhb++
<{^_^}>
srhb's karma got increased to 65
* samueldr
is testing
<samueldr>
additionally it would be nice for the partition building bits could abort (earlier?) when things can't fit
<samueldr>
I'll do a writeup of the ideas, not as an RFC, but "what else am I forgetting?"
<samueldr>
I want to bring in all partition and image building code under a common nix codebase