profile
viewpoint
Robin Gloster globin @mayflower München

fgrehm/vagrant-lxc 1212

LXC provider for Vagrant

globin/drinkup 3

Drink List

globin/aarch64-build-box 0

Config for the Community aarch64 NixOS box.

globin/acab-streetlife 0

Scripts for an ACAB-Installation

globin/bento 0

Modularized Packer definitions for building Vagrant baseboxes

globin/cargo 0

The Rust package manager

globin/cargo-dot 0

Generate graphs of a Cargo project's dependencies

globin/cookie-rs 0

HTTP cookie parsing and cookie jar management for rust

globin/curl-rust 0

Rust bindings to libcurl

push eventmayflower/PayForMe

Max Tharr

commit sha 765e4c25048ed2a6db1fad56d7f12d8a70b46f50

Fix bug that prevents adding a project after changing the password in manual mode

view details

Max Tharr

commit sha 3931995133973f79a2b9637f6b0f6062f98f47d3

Check that a project is not added twice

view details

Max Tharr

commit sha 83c76e36ca8e4862c76b8a739e7a95503f003a20

Add error texts if user tries to use a non https and port 443 server

view details

Max Tharr

commit sha 6527494eefeae12aca32cb176729ffd528a8811c

Migrates SlickLoadingSpiner to 2.0.1 and introduces new cospend qr codes

view details

Max Tharr

commit sha d9245adf8bf9cc4d2bd95600498c45b33979d5a1

Fix UI glitch

view details

Max Tharr

commit sha 3ae4f098f43f3cb53c4a9a27bc72aa57555326fb

hotfix for 99 issue and fix of build pipeline

view details

push time in 26 minutes

issue closedmayflower/PayForMe

Creation of new bill overwrites existing bill 99

In case there are 99 or more bills existing in the backend database, the creation of a new bill in the app overwrites the existing item with id 99.

The problem seems to be that newly created bills get an internal id of 99 in the app: https://github.com/mayflower/PayForMe/blob/f00330590dcb54146de5f05a3999e58947cc1bd4/PayForMe/Model/Bill.swift#L48

And due to the fact that an item with id 99 already exists in the app database, an "update" is send to the backend, and this overwrites the existing backend item 99: https://github.com/mayflower/PayForMe/blob/788c0babaa7d1f3d336289c303488fb271073d29/PayForMe/Services/ProjectManager.swift#L222

Maybe this location is affected as well? https://github.com/mayflower/PayForMe/blob/13a5d922c885b2b57f62b858828d25256ec5cce6/PayForMe/Views/Balance/BalanceList.swift#L84

A quick fix might be, to always create new items with an internal id of -1 instead of 99

closed time in 31 minutes

m-idler

issue commentmayflower/PayForMe

Creation of new bill overwrites existing bill 99

After debugging with @m-idler, the fix for this bug should be in the last release, so it should be fixed since 26.11.

@redmull1611 please confirm or tell if you still experience this bug.

m-idler

comment created time in 31 minutes

issue commentmayflower/PayForMe

Creation of new bill overwrites existing bill 99

An quick & easy workaround would be, to delete the entry with id 99 in the webinterface and create a new entry with that data. A newly created item within the app won't then overwrite anything anymore. I already tried the described solution with @Hustenbonbon and it seemed to work, so a change should be available soonish

m-idler

comment created time in 13 hours

issue commentmayflower/PayForMe

Creation of new bill overwrites existing bill 99

Hello m-idler

How o can solve the problem? Or it solved?

m-idler

comment created time in 14 hours

pull request commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

Squashed fixup commits, and added .md file extensions so that the document could be rendered: https://github.com/NixOS/rfcs/blob/ca06bb8dbb245f6a4c00311967e37753cd3d691a/rfcs/0080-nixos-release-schedule.md

jonringer

comment created time in 16 hours

pull request commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

Thank you, @edolstra. I accept being the shepherd leader.

It looks like the one concern raised so far is by @jtojnar that the delay will not be enough to get GNOME ready (which is a major reason for this RFC). It seems like @jonringer has answered that he still intends branch off to be around the time when GNOME was merged into master on the last cycle.

In the interest of limiting uncertainty in the community about release dates, I will lead this shepherd team as quickly as is allowed by the RFC rules (but not any quicker).

I motion for the Final Comment Period (FCP) to begin with disposition to merge. @domenkozar @garbas please either approve or disapprove of the motion as soon as you can. I understand this is a bit fast, and I won't mind if you disapprove.

jonringer

comment created time in 20 hours

issue openedNixOS/rfc-steering-committee

Meeting 2020-12-03

General business

Present in the meeting: @spacekookie, @edolstra, @Mic92

Agenda for today:

Unlabeled RFCs and New RFCs

RFCs Open for Nominations

<!-- if enough nominations are there, announce the shepherd team and add it to the metadata! -->

RFCs in Discussion

RFCs in FCP

None

Accepted/Rejected/Closed

None

<!-- Determine where in review process each RFC is in https://github.com/NixOS/rfcs/blob/master/rfcs/0036-review-process.png -->

Misc

Call for new SC members: https://discourse.nixos.org/t/rfc-steering-committee-rotation-2020-21/9365/2

Leader of next meeting

<!-- See our rotation in README.md. https://github.com/NixOS/rfc-steering-committee/blob/master/README.md -->

@Mic92 will lead the next meeting on 2020-12-17. @spacekookie will be absent.

pad.mayflower.de/nixos-rfc-steering-committee

created time in 20 hours

pull request commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

This RFC is now in discussion with @ryantm, @domenkozar and @garbas as shepherds. @ryantm Do you want to be shepherd leader on this one?

jonringer

comment created time in 20 hours

pull request commentNixOS/rfcs

[RFC 0075]: Declarative wrappers

@FRidh do you want to be the shepherd leader on this?

doronbehar

comment created time in 20 hours

pull request commentNixOS/rfcs

[RFC 0078] System-agnostic configuration file generators

Are you interested in doing shepherd for this RFC, since it might be interested for your projects: @LnL7 @rycee

7c6f434c

comment created time in 20 hours

pull request commentNixOS/rfcs

[RFC 0078] System-agnostic configuration file generators

I nominate myself as a shepherd.

7c6f434c

comment created time in 20 hours

startedMixiaoxiao/Arduino-HomeKit-ESP8266

started time in 21 hours

issue closedNixOS/rfc-steering-committee

Meeting 2020-11-19

General business

Present in the meeting: @spacekookie, @edolstra, @Mic92

Agenda for today:

Unlabeled RFCs and New RFCs

RFCs Open for Nominations

<!-- if enough nominations are there, announce the shepherd team and add it to the metadata! -->

RFCs in Discussion

RFCs in FCP

None

Accepted/Rejected/Closed

<!-- Determine where in review process each RFC is in https://github.com/NixOS/rfcs/blob/master/rfcs/0036-review-process.png -->

Misc

Call for new SC members: https://discourse.nixos.org/t/rfc-steering-committee-rotation-2020-21/9365/2

Leader of next meeting

<!-- See our rotation in README.md. https://github.com/NixOS/rfc-steering-committee/blob/master/README.md -->

@edolstra will lead the next meeting

closed time in 21 hours

spacekookie

issue commentsteveklabnik/semver

semver v0.11 regression parsing openssl-src VersionReqs

I've also noticed that some pre-release fields like alpha.1a cannot be parsed as VersionReq on semver v0.11, while they are correctly parsed as Version: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6d7008e0bea904e17957909182e4bb1e

tarcieri

comment created time in 2 days

push eventNixOS/nix-mode

taku0

commit sha bdd3c8a1e504ec547ae4bfa93d35cd41a0251604

Exclude braces from ffap pattern This makes ffap to handle paths in strings like this: "cp ${./foo.sh} $out/script/".

view details

Matthew Bauer

commit sha e32c6bf7ad6dfe1d7ef9ee07d4da6e50174037bf

Merge pull request #115 from taku0/ffap-in-string Exclude braces from ffap pattern

view details

push time in 2 days

PR merged NixOS/nix-mode

Exclude braces from ffap pattern

This makes ffap to handle paths in strings like this: "cp ${./foo.sh} $out/script/".

+1 -1

0 comment

1 changed file

taku0

pr closed time in 2 days

push eventNixOS/nix-mode

taku0

commit sha 38958e52034689e55b4d426fceb880ed79df519e

Update install-nix-action in GitHub Action This should fix the following error: ``` Error: Unable to process command '::add-path::/nix/var/nix/profiles/per-user/runner/profile/bin' successfully. Error: The `add-path` command is disabled. Please upgrade to using Environment Files or opt into unsecure command execution by setting the `ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/ ``` See also: https://github.com/cachix/install-nix-action/issues/50

view details

Matthew Bauer

commit sha 218c885d785cb04c472cef88bc1161fa00e2ffdd

Merge pull request #116 from taku0/update-install-nix-action Update install-nix-action in GitHub Action

view details

push time in 2 days

PR merged NixOS/nix-mode

Update install-nix-action in GitHub Action

This should fix the following error:

Error: Unable to process command '::add-path::/nix/var/nix/profiles/per-user/runner/profile/bin' successfully.
Error: The `add-path` command is disabled. Please upgrade to using Environment Files or opt into unsecure command execution by setting the `ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

See also: https://github.com/cachix/install-nix-action/issues/50

+1 -1

0 comment

1 changed file

taku0

pr closed time in 2 days

startedpointfreeco/swift-composable-architecture

started time in 2 days

startedohitsdaniel/BookStore

started time in 2 days

created repositoryfadenb/ffmuc-image-build-docker

created time in 2 days

PR opened steveklabnik/semver

`Version::new` should be a const fn

We can use in the definition of a constant.

const FOO_VERSION: Version = Version::new(1, 2, 3);
+6 -1

0 comment

1 changed file

pr created time in 2 days

Pull request review commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

+---+feature: nixos-release-schedule+start-date: 2020-11-28+author: Jonathan Ringer (@jonringer)+co-authors: Frederik Rietdijk (@FRidh)+related-issues:+---++# Summary+[summary]: #summary++NixOS is released twice a year; the current release schedule targets March+and September for the release months. However, trying to provide a polished+desktop-user experience is difficult and moving the target release months to+May and November should minimize the amount of in-house work needed to+cut a release.++# Motivation+[motivation]: #motivation++By changing our release dates to follow those of certain upstream projects,+we could reduce the amount of issues we encounter during stabilization.+In particular, GNOME and KDE Plasma both have a release in September, which+allows ample time for NixOS contributors to package and stabilize the+desktop managers before the November release. For the May release, GNOME will+have a similar stabilization period; while Plasma, which has a four month+release cadence, will have a slightly older but still supported non-LTS+release. Using LTS releases is not feasible as there is no guarantee that+they will be compatible with the version of systemd during branch-off.++The current March and September release months may be the worst months for+GNOME and Plasma, as the release available during stabilization would be+End-of-Life a few weeks after the target release date. Also, this period marks+the greatest potential dependency "drift" from development on unstable. For example,+many of the 20.09 release blockers were related to issues with systemd-246 and plasma-5.18,+however, plasma-5.19 and the yet-released 5.20 both supported systemd-246 with+zero additional effort.++Choosing branch-off points in master where the major desktop manager use+cases should be well stabilized will allow for release stabilization to+focus on failing builds and minor issues.++## Core changes++The 21.03 release will be delayed until 21.05, and the current 20.09 release+will be supported until June 2021. After the initial 21.05 release, all subsequent+releases will occur six months apart following a YY.05 and YY.11 convention.++# Drawbacks+[drawbacks]: #drawbacks++There will be some initial confusion with stable users as to why the 21.03+release was delayed.++# Alternatives+[alternatives]: #alternatives++## Maintain the status quo regarding release dates++We could keep the release dates in March and September. However, we+would need some other way to minimize the work and risk from trying to+provide a polished experience for 60,000+ packages, 17 desktop managers,+and 30+ window managers.++# Future work+[future]: #future-work+

added the related two work items. Sorry for misinterpreting.

jonringer

comment created time in 3 days

Pull request review commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

+---+feature: nixos-release-schedule+start-date: 2020-11-28+author: Jonathan Ringer (@jonringer)+co-authors: Frederik Rietdijk (@FRidh)+related-issues:+---++# Summary+[summary]: #summary++NixOS is released twice a year; the current release schedule targets March+and September for the release months. However, trying to provide a polished+desktop-user experience is difficult and moving the target release months to+May and November should minimize the amount of in-house work needed to+cut a release.++# Motivation+[motivation]: #motivation++By changing our release dates to follow those of certain upstream projects,+we could reduce the amount of issues we encounter during stabilization.+In particular, GNOME and KDE Plasma both have a release in September, which+allows ample time for NixOS contributors to package and stabilize the+desktop managers before the November release. For the May release, GNOME will+have a similar stabilization period; while Plasma, which has a four month+release cadence, will have a slightly older but still supported non-LTS+release. Using LTS releases is not feasible as there is no guarantee that+they will be compatible with the version of systemd during branch-off.++The current March and September release months may be the worst months for+GNOME and Plasma, as the release available during stabilization would be+End-of-Life a few weeks after the target release date. Also, this period marks+the greatest potential dependency "drift" from development on unstable. For example,+many of the 20.09 release blockers were related to issues with systemd-246 and plasma-5.18,+however, plasma-5.19 and the yet-released 5.20 both supported systemd-246 with+zero additional effort.++Choosing branch-off points in master where the major desktop manager use+cases should be well stabilized will allow for release stabilization to+focus on failing builds and minor issues.++## Core changes++The 21.03 release will be delayed until 21.05, and the current 20.09 release+will be supported until June 2021. After the initial 21.05 release, all subsequent+releases will occur six months apart following a YY.05 and YY.11 convention.++# Drawbacks+[drawbacks]: #drawbacks++There will be some initial confusion with stable users as to why the 21.03+release was delayed.++# Alternatives+[alternatives]: #alternatives++## Maintain the status quo regarding release dates++We could keep the release dates in March and September. However, we+would need some other way to minimize the work and risk from trying to+provide a polished experience for 60,000+ packages, 17 desktop managers,+and 30+ window managers.++# Future work+[future]: #future-work+

Yes, 21.03pre will need to be changed to 21.05pre. Sorry.

jonringer

comment created time in 3 days

Pull request review commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

+---+feature: nixos-release-schedule+start-date: 2020-11-28+author: Jonathan Ringer (@jonringer)+co-authors: Frederik Rietdijk (@FRidh)+related-issues:+---++# Summary+[summary]: #summary++NixOS is released twice a year; the current release schedule targets March+and September for the release months. However, trying to provide a polished+desktop-user experience is difficult and moving the target release months to+May and November should minimize the amount of in-house work needed to+cut a release.++# Motivation+[motivation]: #motivation++By changing our release dates to follow those of certain upstream projects,+we could reduce the amount of issues we encounter during stabilization.+In particular, GNOME and KDE Plasma both have a release in September, which+allows ample time for NixOS contributors to package and stabilize the+desktop managers before the November release. For the May release, GNOME will+have a similar stabilization period; while Plasma, which has a four month+release cadence, will have a slightly older but still supported non-LTS+release. Using LTS releases is not feasible as there is no guarantee that+they will be compatible with the version of systemd during branch-off.++The current March and September release months may be the worst months for+GNOME and Plasma, as the release available during stabilization would be+End-of-Life a few weeks after the target release date. Also, this period marks+the greatest potential dependency "drift" from development on unstable. For example,+many of the 20.09 release blockers were related to issues with systemd-246 and plasma-5.18,+however, plasma-5.19 and the yet-released 5.20 both supported systemd-246 with+zero additional effort.++Choosing branch-off points in master where the major desktop manager use+cases should be well stabilized will allow for release stabilization to+focus on failing builds and minor issues.++## Core changes++The 21.03 release will be delayed until 21.05, and the current 20.09 release+will be supported until June 2021. After the initial 21.05 release, all subsequent+releases will occur six months apart following a YY.05 and YY.11 convention.++# Drawbacks+[drawbacks]: #drawbacks++There will be some initial confusion with stable users as to why the 21.03+release was delayed.++# Alternatives+[alternatives]: #alternatives++## Maintain the status quo regarding release dates++We could keep the release dates in March and September. However, we+would need some other way to minimize the work and risk from trying to+provide a polished experience for 60,000+ packages, 17 desktop managers,+and 30+ window managers.++# Future work+[future]: #future-work+

Yes. But it is not clear to me whether after accepting this RFC, the unstable branch will become 21.05pre instead of 21.03pre it currently is.

This is orthogonal to the beta release and will affect whether we have to update the osinfo-db.

jonringer

comment created time in 3 days

Pull request review commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

+---+feature: nixos-release-schedule+start-date: 2020-11-28+author: Jonathan Ringer (@jonringer)+co-authors: Frederik Rietdijk (@FRidh)+related-issues:+---++# Summary+[summary]: #summary++NixOS is released twice a year; the current release schedule targets March+and September for the release months. However, trying to provide a polished+desktop-user experience is difficult and moving the target release months to+May and November should minimize the amount of in-house work needed to+cut a release.++# Motivation+[motivation]: #motivation++By changing our release dates to follow those of certain upstream projects,+we could reduce the amount of issues we encounter during stabilization.+In particular, GNOME and KDE Plasma both have a release in September, which+allows ample time for NixOS contributors to package and stabilize the+desktop managers before the November release. For the May release, GNOME will+have a similar stabilization period; while Plasma, which has a four month+release cadence, will have a slightly older but still supported non-LTS+release. Using LTS releases is not feasible as there is no guarantee that+they will be compatible with the version of systemd during branch-off.++The current March and September release months may be the worst months for+GNOME and Plasma, as the release available during stabilization would be+End-of-Life a few weeks after the target release date. Also, this period marks+the greatest potential dependency "drift" from development on unstable. For example,+many of the 20.09 release blockers were related to issues with systemd-246 and plasma-5.18,+however, plasma-5.19 and the yet-released 5.20 both supported systemd-246 with+zero additional effort.++Choosing branch-off points in master where the major desktop manager use+cases should be well stabilized will allow for release stabilization to+focus on failing builds and minor issues.++## Core changes++The 21.03 release will be delayed until 21.05, and the current 20.09 release+will be supported until June 2021. After the initial 21.05 release, all subsequent+releases will occur six months apart following a YY.05 and YY.11 convention.++# Drawbacks+[drawbacks]: #drawbacks++There will be some initial confusion with stable users as to why the 21.03+release was delayed.++# Alternatives+[alternatives]: #alternatives++## Maintain the status quo regarding release dates++We could keep the release dates in March and September. However, we+would need some other way to minimize the work and risk from trying to+provide a polished experience for 60,000+ packages, 17 desktop managers,+and 30+ window managers.++# Future work+[future]: #future-work+

Or will the unstable branch remain 21.03pre until then, even after this RFC has been accepted?

unstable branch will always be the pre suffix

only release branches will differ

jonringer

comment created time in 3 days

Pull request review commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

+---+feature: nixos-release-schedule+start-date: 2020-11-28+author: Jonathan Ringer (@jonringer)+co-authors: Frederik Rietdijk (@FRidh)+related-issues:+---++# Summary+[summary]: #summary++NixOS is released twice a year; the current release schedule targets March+and September for the release months. However, trying to provide a polished+desktop-user experience is difficult and moving the target release months to+May and November should minimize the amount of in-house work needed to+cut a release.++# Motivation+[motivation]: #motivation++By changing our release dates to follow those of certain upstream projects,+we could reduce the amount of issues we encounter during stabilization.+In particular, GNOME and KDE Plasma both have a release in September, which+allows ample time for NixOS contributors to package and stabilize the+desktop managers before the November release. For the May release, GNOME will+have a similar stabilization period; while Plasma, which has a four month+release cadence, will have a slightly older but still supported non-LTS+release. Using LTS releases is not feasible as there is no guarantee that+they will be compatible with the version of systemd during branch-off.++The current March and September release months may be the worst months for+GNOME and Plasma, as the release available during stabilization would be+End-of-Life a few weeks after the target release date. Also, this period marks+the greatest potential dependency "drift" from development on unstable. For example,+many of the 20.09 release blockers were related to issues with systemd-246 and plasma-5.18,+however, plasma-5.19 and the yet-released 5.20 both supported systemd-246 with+zero additional effort.++Choosing branch-off points in master where the major desktop manager use+cases should be well stabilized will allow for release stabilization to+focus on failing builds and minor issues.++## Core changes++The 21.03 release will be delayed until 21.05, and the current 20.09 release+will be supported until June 2021. After the initial 21.05 release, all subsequent+releases will occur six months apart following a YY.05 and YY.11 convention.++# Drawbacks+[drawbacks]: #drawbacks++There will be some initial confusion with stable users as to why the 21.03+release was delayed.++# Alternatives+[alternatives]: #alternatives++## Maintain the status quo regarding release dates++We could keep the release dates in March and September. However, we+would need some other way to minimize the work and risk from trying to+provide a polished experience for 60,000+ packages, 17 desktop managers,+and 30+ window managers.++# Future work+[future]: #future-work+

Well, that is still only relevant to the 21.11 bump. Or will the unstable branch remain 21.03pre until then, even after this RFC has been accepted?

jonringer

comment created time in 3 days

Pull request review commentNixOS/rfcs

[RFC 0080] Change NixOS releases to YY.05,YY.11

+---+feature: nixos-release-schedule+start-date: 2020-11-28+author: Jonathan Ringer (@jonringer)+co-authors: Frederik Rietdijk (@FRidh)+related-issues:+---++# Summary+[summary]: #summary++NixOS is released twice a year; the current release schedule targets March+and September for the release months. However, trying to provide a polished+desktop-user experience is difficult and moving the target release months to+May and November should minimize the amount of in-house work needed to+cut a release.++# Motivation+[motivation]: #motivation++By changing our release dates to follow those of certain upstream projects,+we could reduce the amount of issues we encounter during stabilization.+In particular, GNOME and KDE Plasma both have a release in September, which+allows ample time for NixOS contributors to package and stabilize the+desktop managers before the November release. For the May release, GNOME will+have a similar stabilization period; while Plasma, which has a four month+release cadence, will have a slightly older but still supported non-LTS+release. Using LTS releases is not feasible as there is no guarantee that+they will be compatible with the version of systemd during branch-off.++The current March and September release months may be the worst months for+GNOME and Plasma, as the release available during stabilization would be+End-of-Life a few weeks after the target release date. Also, this period marks+the greatest potential dependency "drift" from development on unstable. For example,+many of the 20.09 release blockers were related to issues with systemd-246 and plasma-5.18,+however, plasma-5.19 and the yet-released 5.20 both supported systemd-246 with+zero additional effort.++Choosing branch-off points in master where the major desktop manager use+cases should be well stabilized will allow for release stabilization to+focus on failing builds and minor issues.++## Core changes++The 21.03 release will be delayed until 21.05, and the current 20.09 release+will be supported until June 2021. After the initial 21.05 release, all subsequent+releases will occur six months apart following a YY.05 and YY.11 convention.++# Drawbacks+[drawbacks]: #drawbacks++There will be some initial confusion with stable users as to why the 21.03+release was delayed.++# Alternatives+[alternatives]: #alternatives++## Maintain the status quo regarding release dates++We could keep the release dates in March and September. However, we+would need some other way to minimize the work and risk from trying to+provide a polished experience for 60,000+ packages, 17 desktop managers,+and 30+ window managers.++# Future work+[future]: #future-work+

yes, this is mentioned here: https://nixos.org/manual/nixos/stable/index.html#at-beta-release-time with the heading "On the master branch, increment the .version file".

I will update the example command when transferring over to the https://github.com/NixOS/release-wiki

jonringer

comment created time in 3 days

more