text:
python3Packages.pyturbojpeg: 1.6.4 -> 1.6.5

Motivation for this change
https://github.com/lilohuang/PyTurboJPEG/releases/tag/v1.6.5
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Please target staging

Please target staging

Not really needed, these are just Home Assistant's tests.

Result of nixpkgs-review pr 155747 run on x86_64-linux 1

5 packages marked as broken and skipped:

home-assistant-component-tests.airtouch4
home-assistant-component-tests.glances
home-assistant-component-tests.ridwell
home-assistant-component-tests.venstar
home-assistant-component-tests.yamaha_musiccast

561 packages built:

home-assistant
home-assistant-component-tests.abode
home-assistant-component-tests.accuweather
home-assistant-component-tests.acmeda
home-assistant-component-tests.adax
home-assistant-component-tests.adguard
home-assistant-component-tests.advantage_air
home-assistant-component-tests.aemet
home-assistant-component-tests.agent_dvr
home-assistant-component-tests.air_quality
home-assistant-component-tests.airly
home-assistant-component-tests.airnow
home-assistant-component-tests.airthings
home-assistant-component-tests.airvisual
home-assistant-component-tests.alarm_control_panel
home-assistant-component-tests.alarmdecoder
home-assistant-component-tests.alert
home-assistant-component-tests.alexa
home-assistant-component-tests.almond
home-assistant-component-tests.ambee
home-assistant-component-tests.amberelectric
home-assistant-component-tests.ambiclimate
home-assistant-component-tests.ambient_station
home-assistant-component-tests.analytics
home-assistant-component-tests.androidtv
home-assistant-component-tests.apache_kafka
home-assistant-component-tests.api
home-assistant-component-tests.apple_tv
home-assistant-component-tests.apprise
home-assistant-component-tests.aprs
home-assistant-component-tests.arcam_fmj
home-assistant-component-tests.arlo
home-assistant-component-tests.asuswrt
home-assistant-component-tests.atag
home-assistant-component-tests.august
home-assistant-component-tests.aurora
home-assistant-component-tests.auth
home-assistant-component-tests.automation
home-assistant-component-tests.awair
home-assistant-component-tests.aws
home-assistant-component-tests.axis
home-assistant-component-tests.azure_devops
home-assistant-component-tests.azure_event_hub
home-assistant-component-tests.balboa
home-assistant-component-tests.bayesian
home-assistant-component-tests.binary_sensor
home-assistant-component-tests.blackbird
home-assistant-component-tests.blebox
home-assistant-component-tests.blink
home-assistant-component-tests.blueprint
home-assistant-component-tests.bluetooth_le_tracker
home-assistant-component-tests.bmw_connected_drive
home-assistant-component-tests.bond
home-assistant-component-tests.bosch_shc
home-assistant-component-tests.braviatv
home-assistant-component-tests.broadlink
home-assistant-component-tests.brother
home-assistant-component-tests.bsblan
home-assistant-component-tests.buienradar
home-assistant-component-tests.button
home-assistant-component-tests.caldav
home-assistant-component-tests.calendar
home-assistant-component-tests.camera
home-assistant-component-tests.canary
home-assistant-component-tests.cast
home-assistant-component-tests.cert_expiry
home-assistant-component-tests.climacell
home-assistant-component-tests.climate
home-assistant-component-tests.cloud
home-assistant-component-tests.cloudflare
home-assistant-component-tests.color_extractor
home-assistant-component-tests.comfoconnect
home-assistant-component-tests.command_line
home-assistant-component-tests.compensation
home-assistant-component-tests.config
home-assistant-component-tests.configurator
home-assistant-component-tests.control4
home-assistant-component-tests.conversation
home-assistant-component-tests.coolmaster
home-assistant-component-tests.coronavirus
home-assistant-component-tests.counter
home-assistant-component-tests.cover
home-assistant-component-tests.crownstone
home-assistant-component-tests.daikin
home-assistant-component-tests.darksky
home-assistant-component-tests.datadog
home-assistant-component-tests.debugpy
home-assistant-component-tests.deconz
home-assistant-component-tests.default_config
home-assistant-component-tests.demo
home-assistant-component-tests.denonavr
home-assistant-component-tests.derivative
home-assistant-component-tests.device_automation
home-assistant-component-tests.device_sun_light_trigger
home-assistant-component-tests.device_tracker
home-assistant-component-tests.devolo_home_control
home-assistant-component-tests.devolo_home_network
home-assistant-component-tests.dexcom
home-assistant-component-tests.dhcp
home-assistant-component-tests.dialogflow
home-assistant-component-tests.directv
home-assistant-component-tests.discovery
home-assistant-component-tests.dlna_dmr
home-assistant-component-tests.doorbird
home-assistant-component-tests.dsmr
home-assistant-component-tests.dte_energy_bridge
home-assistant-component-tests.duckdns
home-assistant-component-tests.dunehd
home-assistant-component-tests.eafm
home-assistant-component-tests.ecobee
home-assistant-component-tests.econet
home-assistant-component-tests.efergy
home-assistant-component-tests.elgato
home-assistant-component-tests.elkm1
home-assistant-component-tests.emonitor
home-assistant-component-tests.emulated_hue
home-assistant-component-tests.emulated_kasa
home-assistant-component-tests.emulated_roku
home-assistant-component-tests.energy
home-assistant-component-tests.enocean
home-assistant-component-tests.enphase_envoy
home-assistant-component-tests.environment_canada
home-assistant-component-tests.epson
home-assistant-component-tests.esphome
home-assistant-component-tests.everlights
home-assistant-component-tests.evil_genius_labs
home-assistant-component-tests.ezviz
home-assistant-component-tests.faa_delays
home-assistant-component-tests.facebook
home-assistant-component-tests.facebox
home-assistant-component-tests.fail2ban
home-assistant-component-tests.fan
home-assistant-component-tests.feedreader
home-assistant-component-tests.ffmpeg
home-assistant-component-tests.fido
home-assistant-component-tests.file
home-assistant-component-tests.filesize
home-assistant-component-tests.filter
home-assistant-component-tests.fireservicerota
home-assistant-component-tests.firmata
home-assistant-component-tests.fjaraskupan
home-assistant-component-tests.flick_electric
home-assistant-component-tests.flipr
home-assistant-component-tests.flo
home-assistant-component-tests.flume
home-assistant-component-tests.flunearyou
home-assistant-component-tests.flux
home-assistant-component-tests.flux_led
home-assistant-component-tests.folder
home-assistant-component-tests.folder_watcher
home-assistant-component-tests.foobot
home-assistant-component-tests.forecast_solar
home-assistant-component-tests.foscam
home-assistant-component-tests.freebox
home-assistant-component-tests.freedns
home-assistant-component-tests.freedompro
home-assistant-component-tests.fritz
home-assistant-component-tests.fritzbox
home-assistant-component-tests.fritzbox_callmonitor
home-assistant-component-tests.fronius
home-assistant-component-tests.frontend
home-assistant-component-tests.garages_amsterdam
home-assistant-component-tests.gdacs
home-assistant-component-tests.generic
home-assistant-component-tests.generic_hygrostat
home-assistant-component-tests.generic_thermostat
home-assistant-component-tests.geo_json_events
home-assistant-component-tests.geo_location
home-assistant-component-tests.geo_rss_events
home-assistant-component-tests.geofency
home-assistant-component-tests.geonetnz_quakes
home-assistant-component-tests.geonetnz_volcano
home-assistant-component-tests.gios
home-assistant-component-tests.goalzero
home-assistant-component-tests.gogogate2
home-assistant-component-tests.google
home-assistant-component-tests.google_assistant
home-assistant-component-tests.google_domains
home-assistant-component-tests.google_pubsub
home-assistant-component-tests.google_translate
home-assistant-component-tests.google_travel_time
home-assistant-component-tests.google_wifi
home-assistant-component-tests.gpslogger
home-assistant-component-tests.graphite
home-assistant-component-tests.gree
home-assistant-component-tests.group
home-assistant-component-tests.growatt_server
home-assistant-component-tests.guardian
home-assistant-component-tests.habitica
home-assistant-component-tests.hangouts
home-assistant-component-tests.harmony
home-assistant-component-tests.hassio
home-assistant-component-tests.hddtemp
home-assistant-component-tests.heos
home-assistant-component-tests.here_travel_time
home-assistant-component-tests.hisense_aehw4a1
home-assistant-component-tests.history
home-assistant-component-tests.history_stats
home-assistant-component-tests.hive
home-assistant-component-tests.hlk_sw16
home-assistant-component-tests.home_connect
home-assistant-component-tests.home_plus_control
home-assistant-component-tests.homeassistant
home-assistant-component-tests.homekit
home-assistant-component-tests.homekit_controller
home-assistant-component-tests.homematic
home-assistant-component-tests.homematicip_cloud
home-assistant-component-tests.honeywell
home-assistant-component-tests.html5
home-assistant-component-tests.http
home-assistant-component-tests.huawei_lte
home-assistant-component-tests.hue
home-assistant-component-tests.huisbaasje
home-assistant-component-tests.humidifier
home-assistant-component-tests.hunterdouglas_powerview
home-assistant-component-tests.hvv_departures
home-assistant-component-tests.hyperion
home-assistant-component-tests.ialarm
home-assistant-component-tests.iaqualink
home-assistant-component-tests.icloud
home-assistant-component-tests.ifttt
home-assistant-component-tests.ign_sismologia
home-assistant-component-tests.image
home-assistant-component-tests.image_processing
home-assistant-component-tests.imap_email_content
home-assistant-component-tests.influxdb
home-assistant-component-tests.input_boolean
home-assistant-component-tests.input_datetime
home-assistant-component-tests.input_number
home-assistant-component-tests.input_select
home-assistant-component-tests.input_text
home-assistant-component-tests.insteon
home-assistant-component-tests.integration
home-assistant-component-tests.intent
home-assistant-component-tests.intent_script
home-assistant-component-tests.ios
home-assistant-component-tests.iotawatt
home-assistant-component-tests.ipma
home-assistant-component-tests.ipp
home-assistant-component-tests.iqvia
home-assistant-component-tests.islamic_prayer_times
home-assistant-component-tests.isy994
home-assistant-component-tests.izone
home-assistant-component-tests.jellyfin
home-assistant-component-tests.jewish_calendar
home-assistant-component-tests.juicenet
home-assistant-component-tests.keenetic_ndms2
home-assistant-component-tests.kira
home-assistant-component-tests.kmtronic
home-assistant-component-tests.knx
home-assistant-component-tests.kodi
home-assistant-component-tests.konnected
home-assistant-component-tests.kraken
home-assistant-component-tests.kulersky
home-assistant-component-tests.lastfm
home-assistant-component-tests.lcn
home-assistant-component-tests.light
home-assistant-component-tests.litterrobot
home-assistant-component-tests.local_file
home-assistant-component-tests.local_ip
home-assistant-component-tests.locative
home-assistant-component-tests.lock
home-assistant-component-tests.logbook
home-assistant-component-tests.logentries
home-assistant-component-tests.logger
home-assistant-component-tests.london_air
home-assistant-component-tests.lookin
home-assistant-component-tests.lovelace
home-assistant-component-tests.luftdaten
home-assistant-component-tests.lutron_caseta
home-assistant-component-tests.lyric
home-assistant-component-tests.mailbox
home-assistant-component-tests.manual
home-assistant-component-tests.manual_mqtt
home-assistant-component-tests.maxcube
home-assistant-component-tests.mazda
home-assistant-component-tests.media_player
home-assistant-component-tests.media_source
home-assistant-component-tests.melcloud
home-assistant-component-tests.meraki
home-assistant-component-tests.met
home-assistant-component-tests.met_eireann
home-assistant-component-tests.meteoclimatic
home-assistant-component-tests.mhz19
home-assistant-component-tests.microsoft_face
home-assistant-component-tests.microsoft_face_detect
home-assistant-component-tests.microsoft_face_identify
home-assistant-component-tests.mikrotik
home-assistant-component-tests.mill
home-assistant-component-tests.min_max
home-assistant-component-tests.minecraft_server
home-assistant-component-tests.minio
home-assistant-component-tests.mobile_app
home-assistant-component-tests.modbus
home-assistant-component-tests.modem_callerid
home-assistant-component-tests.modern_forms
home-assistant-component-tests.mold_indicator
home-assistant-component-tests.moon
home-assistant-component-tests.motion_blinds
home-assistant-component-tests.motioneye
home-assistant-component-tests.mqtt
home-assistant-component-tests.mqtt_eventstream
home-assistant-component-tests.mqtt_json
home-assistant-component-tests.mqtt_room
home-assistant-component-tests.mqtt_statestream
home-assistant-component-tests.mullvad
home-assistant-component-tests.mutesync
home-assistant-component-tests.my
home-assistant-component-tests.myq
home-assistant-component-tests.mysensors
home-assistant-component-tests.mythicbeastsdns
home-assistant-component-tests.nam
home-assistant-component-tests.namecheapdns
home-assistant-component-tests.nanoleaf
home-assistant-component-tests.neato
home-assistant-component-tests.ness_alarm
home-assistant-component-tests.nest
home-assistant-component-tests.netatmo
home-assistant-component-tests.network
home-assistant-component-tests.nexia
home-assistant-component-tests.nightscout
home-assistant-component-tests.no_ip
home-assistant-component-tests.notify
home-assistant-component-tests.notion
home-assistant-component-tests.nsw_rural_fire_service_feed
home-assistant-component-tests.nuki
home-assistant-component-tests.number
home-assistant-component-tests.nut
home-assistant-component-tests.nws
home-assistant-component-tests.nx584
home-assistant-component-tests.octoprint
home-assistant-component-tests.omnilogic
home-assistant-component-tests.onboarding
home-assistant-component-tests.ondilo_ico
home-assistant-component-tests.openalpr_cloud
home-assistant-component-tests.openalpr_local
home-assistant-component-tests.openerz
home-assistant-component-tests.opengarage
home-assistant-component-tests.openhardwaremonitor
home-assistant-component-tests.opentherm_gw
home-assistant-component-tests.openuv
home-assistant-component-tests.openweathermap
home-assistant-component-tests.opnsense
home-assistant-component-tests.ovo_energy
home-assistant-component-tests.owntracks
home-assistant-component-tests.ozw
home-assistant-component-tests.p1_monitor
home-assistant-component-tests.panel_custom
home-assistant-component-tests.panel_iframe
home-assistant-component-tests.persistent_notification
home-assistant-component-tests.person
home-assistant-component-tests.philips_js
home-assistant-component-tests.pi_hole
home-assistant-component-tests.picnic
home-assistant-component-tests.ping
home-assistant-component-tests.plaato
home-assistant-component-tests.plant
home-assistant-component-tests.plex
home-assistant-component-tests.plugwise
home-assistant-component-tests.point
home-assistant-component-tests.poolsense
home-assistant-component-tests.profiler
home-assistant-component-tests.prometheus
home-assistant-component-tests.prosegur
home-assistant-component-tests.proximity
home-assistant-component-tests.push
home-assistant-component-tests.pushbullet
home-assistant-component-tests.pvpc_hourly_pricing
home-assistant-component-tests.python_script
home-assistant-component-tests.qld_bushfire
home-assistant-component-tests.rachio
home-assistant-component-tests.radarr
home-assistant-component-tests.rainforest_eagle
home-assistant-component-tests.rainmachine
home-assistant-component-tests.random
home-assistant-component-tests.rdw
home-assistant-component-tests.recollect_waste
home-assistant-component-tests.recorder
home-assistant-component-tests.reddit
home-assistant-component-tests.remote
home-assistant-component-tests.renault
home-assistant-component-tests.rest
home-assistant-component-tests.rest_command
home-assistant-component-tests.rflink
home-assistant-component-tests.rfxtrx
home-assistant-component-tests.ring
home-assistant-component-tests.risco
home-assistant-component-tests.rituals_perfume_genie
home-assistant-component-tests.rmvtransport
home-assistant-component-tests.roku
home-assistant-component-tests.roomba
home-assistant-component-tests.roon
home-assistant-component-tests.rpi_power
home-assistant-component-tests.rss_feed_template
home-assistant-component-tests.ruckus_unleashed
home-assistant-component-tests.safe_mode
home-assistant-component-tests.samsungtv
home-assistant-component-tests.scene
home-assistant-component-tests.screenlogic
home-assistant-component-tests.script
home-assistant-component-tests.search
home-assistant-component-tests.season
home-assistant-component-tests.select
home-assistant-component-tests.sense
home-assistant-component-tests.sensor
home-assistant-component-tests.sentry
home-assistant-component-tests.seventeentrack
home-assistant-component-tests.sharkiq
home-assistant-component-tests.shell_command
home-assistant-component-tests.shelly
home-assistant-component-tests.shopping_list
home-assistant-component-tests.sia
home-assistant-component-tests.sigfox
home-assistant-component-tests.sighthound
home-assistant-component-tests.simplisafe
home-assistant-component-tests.simulated
home-assistant-component-tests.siren
home-assistant-component-tests.slack
home-assistant-component-tests.sleepiq
home-assistant-component-tests.sma
home-assistant-component-tests.smappee
home-assistant-component-tests.smart_meter_texas
home-assistant-component-tests.smarthab
home-assistant-component-tests.smartthings
home-assistant-component-tests.smarttub
home-assistant-component-tests.smhi
home-assistant-component-tests.smtp
home-assistant-component-tests.snips
home-assistant-component-tests.solaredge
home-assistant-component-tests.solarlog
home-assistant-component-tests.soma
home-assistant-component-tests.somfy
home-assistant-component-tests.somfy_mylink
home-assistant-component-tests.sonarr
home-assistant-component-tests.songpal
home-assistant-component-tests.sonos
home-assistant-component-tests.soundtouch
home-assistant-component-tests.spaceapi
home-assistant-component-tests.spc
home-assistant-component-tests.speedtestdotnet
home-assistant-component-tests.spider
home-assistant-component-tests.spotify
home-assistant-component-tests.sql
home-assistant-component-tests.squeezebox
home-assistant-component-tests.srp_energy
home-assistant-component-tests.ssdp
home-assistant-component-tests.starline
home-assistant-component-tests.startca
home-assistant-component-tests.statistics
home-assistant-component-tests.statsd
home-assistant-component-tests.stream
home-assistant-component-tests.stt
home-assistant-component-tests.subaru
home-assistant-component-tests.sun
home-assistant-component-tests.surepetcare
home-assistant-component-tests.switch
home-assistant-component-tests.switchbot
home-assistant-component-tests.switcher_kis
home-assistant-component-tests.syncthing
home-assistant-component-tests.syncthru
home-assistant-component-tests.synology_dsm
home-assistant-component-tests.system_bridge
home-assistant-component-tests.system_health
home-assistant-component-tests.system_log
home-assistant-component-tests.tado
home-assistant-component-tests.tag
home-assistant-component-tests.tailscale
home-assistant-component-tests.tasmota
home-assistant-component-tests.tcp
home-assistant-component-tests.telegram
home-assistant-component-tests.tellduslive
home-assistant-component-tests.template
home-assistant-component-tests.tesla_wall_connector
home-assistant-component-tests.threshold
home-assistant-component-tests.tibber
home-assistant-component-tests.tile
home-assistant-component-tests.time_date
home-assistant-component-tests.timer
home-assistant-component-tests.tod
home-assistant-component-tests.tolo
home-assistant-component-tests.tomato
home-assistant-component-tests.toon
home-assistant-component-tests.totalconnect
home-assistant-component-tests.tplink
home-assistant-component-tests.traccar
home-assistant-component-tests.trace
home-assistant-component-tests.tractive
home-assistant-component-tests.tradfri
home-assistant-component-tests.trafikverket_weatherstation
home-assistant-component-tests.transmission
home-assistant-component-tests.transport_nsw
home-assistant-component-tests.trend
home-assistant-component-tests.tts
home-assistant-component-tests.tuya
home-assistant-component-tests.twentemilieu
home-assistant-component-tests.twilio
home-assistant-component-tests.twinkly
home-assistant-component-tests.twitch
home-assistant-component-tests.uk_transport
home-assistant-component-tests.unifi
home-assistant-component-tests.unifi_direct
home-assistant-component-tests.universal
home-assistant-component-tests.upb
home-assistant-component-tests.upcloud
home-assistant-component-tests.updater
home-assistant-component-tests.upnp
home-assistant-component-tests.uptime
home-assistant-component-tests.uptimerobot
home-assistant-component-tests.usb
home-assistant-component-tests.usgs_earthquakes_feed
home-assistant-component-tests.utility_meter
home-assistant-component-tests.uvc
home-assistant-component-tests.vacuum
home-assistant-component-tests.velbus
home-assistant-component-tests.vera
home-assistant-component-tests.verisure
home-assistant-component-tests.version
home-assistant-component-tests.vesync
home-assistant-component-tests.vicare
home-assistant-component-tests.vilfo
home-assistant-component-tests.vizio
home-assistant-component-tests.vlc_telnet
home-assistant-component-tests.voicerss
home-assistant-component-tests.volumio
home-assistant-component-tests.vultr
home-assistant-component-tests.wake_on_lan
home-assistant-component-tests.wallbox
home-assistant-component-tests.water_heater
home-assistant-component-tests.watttime
home-assistant-component-tests.waze_travel_time
home-assistant-component-tests.weather
home-assistant-component-tests.webhook
home-assistant-component-tests.webostv
home-assistant-component-tests.websocket_api
home-assistant-component-tests.wemo
home-assistant-component-tests.whirlpool
home-assistant-component-tests.wiffi
home-assistant-component-tests.wilight
home-assistant-component-tests.wled
home-assistant-component-tests.workday
home-assistant-component-tests.worldclock
home-assistant-component-tests.wsdot
home-assistant-component-tests.xbox
home-assistant-component-tests.xiaomi
home-assistant-component-tests.xiaomi_aqara
home-assistant-component-tests.xiaomi_miio
home-assistant-component-tests.yale_smart_alarm
home-assistant-component-tests.yamaha
home-assistant-component-tests.yandex_transport
home-assistant-component-tests.yandextts
home-assistant-component-tests.yeelight
home-assistant-component-tests.youless
home-assistant-component-tests.zeroconf
home-assistant-component-tests.zerproc
home-assistant-component-tests.zha
home-assistant-component-tests.zodiac
home-assistant-component-tests.zone
home-assistant-component-tests.zwave
home-assistant-component-tests.zwave_js
python310Packages.pyturbojpeg
python39Packages.pyturbojpeg


text:
pythonPackages.allure_behave: init at 2.9.45

Description of changes
adds a missing package.
The thing I want ultimately is to give allure format support to behave.
This is just one step in that direction.
Definitely not a python guy, so happy to receive feedback.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[X] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

The ci passes for all architectures, I'm going to merge this PR for now, but I'm open to feedback should there be any later.

source: gharchive/pull-request

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
python310Packages.dynalite-devices: 0.1.46 -> 0.46

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.dynalite-devices is: "An unofficial Dynalite DyNET interface creating devices"
meta.homepage for python310Packages.dynalite-devices is: "https://github.com/ziv1234/python-dynalite-devices"
meta.changelog for python310Packages.dynalite-devices is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 0.46 with grep in /nix/store/rv405z3x1kiwfmjh7ckv6ma8vynqqm52-python3.10-dynalite-devices-0.46

found 0.46 in filename of file in /nix/store/rv405z3x1kiwfmjh7ckv6ma8vynqqm52-python3.10-dynalite-devices-0.46

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

3 package rebuild(s)

3 x86_64-linux rebuild(s)
2 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
home-assistant-component-tests.dynalite
python310Packages.dynalite-devices
python39Packages.dynalite-devices

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/rv405z3x1kiwfmjh7ckv6ma8vynqqm52-python3.10-dynalite-devices-0.46 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.dynalite-devices https://github.com/r-ryantm/nixpkgs/archive/407f307c5a065c5f6280930570e39748d03af6ad.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/rv405z3x1kiwfmjh7ckv6ma8vynqqm52-python3.10-dynalite-devices-0.46
ls -la /nix/store/rv405z3x1kiwfmjh7ckv6ma8vynqqm52-python3.10-dynalite-devices-0.46/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.dynalite
python310Packages.dynalite-devices
python39Packages.dynalite-devices

Maintainer pings
cc @dotlambda for testing.

https://github.com/ziv1234/python-dynalite-devices/issues/2

Done by 0e590ca9aa4819ee7c0ac87f3d99ab540ee3a68e.

authors: dotlambda r-ryantm smancill


text:
dvtm: allow user configuration

Motivation for this change
dvtm suggests users to customize their settings by modifing the config.h directly. This patch allows nix users to customize their dvtm by supplying a config.h
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Hm, this doesn't make too much sense to me as is. What is the benefit of treating the config as a nix function? It's just a C header file, right? To me, it seems cleaner to simply pass it in as a string and leave it up to the user to decide how that string is produced.
readFile is a builtin, so should be available via builtins.readFile.

What I was thinking of was to pass the config text as a string, not a string path. The user could do readFile whatever themselves, if they wanted to store it externally.
Even simpler would be to pass the config file as a store path, so that you just conditionally copy it to config.h. Then, the user could do dtvm.override { configFile = ./my-config.h; } or somesuch.
If you wanted to be fancy, you could dispatch on the type to allow passing either the config text or a store path containing a config.

@joachifm any examples that I can use for how to create a store file, and do a type based dispatch?

pkgs.writeText ... would result in a store path, as would an unquoted relative path to a file (which causes it to be imported into the store).
Anyway, I think doing type dispatch is going too far ... just passing in the config text seems like a simple and intuitive interface for this.

@joachifm changed to using a string directly.

@pngwjpgh updated.

authors: joachifm vrthra


text:
keepassxc: Wrap once

Using Qt and GTK means both wrapper hooks kick in, so avoid automatic
GTK wrapping and merge arguments into Qt ones as usual.
Duplicate wrapping must be avoided as it breaks the program's basename,
e.g. argv[0] ends up with ".keepassxc-wrapped" rather than
"keepassxc" as basename.
This fixes all three ELF executables (there is -cli and -proxy).
@jonafato @turlon

I'd prefer it if we had something like https://discourse.nixos.org/t/declarative-wrappers/1775, but that's not there yet.
@klemensn Did you notice any disadvantages for keepassxc through the double wrapping? For me it works fine.

@klemensn Did you notice any disadvantages for keepassxc through the double wrapping? For me it works fine.

Multiple wrappers still work fine but change the program's effective argv[0], i.e. the process runs as .keepassxc-wrapped rather than keepassxc, which in turn can hurt you if you match for exact process names, e.g. with earlyoom(1)'s --avoid ^keepassxc$.

Anyone willing to merge this?

Thanks!

authors: bjornfor klemensn turion


text:
awsebcli: fixup, use python.pkgs.six from nixpkgs

Description of changes
after switch to python310 https://github.com/NixOS/nixpkgs/pull/177171/commits/11ea0e99b713744b5e76141fb26a3d4b4d16c507
awsebcli would fail to build, because it was using older version of six, which would fail tests for python3.pkgs.itsdangerous
I decided its just easier to use six version from nixpkgs, awsebcli works fine with six 1.16.0
Not sure if this needs to be merged into staging-next, staging or simply master
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

cc @mweinelt

Fine to go into staging-next, if the breakage occured there (or more probable in python-updates).

authors: kirillrdy mweinelt


text:
criterion: 2.3.3 -> 2.4.1

Description of changes
Updated criterion and boxfort packages, and added option for malloc-enabled builds of nanopb.
This PR requires and includes #181813. Will rebase once that fix is merged.
Blocked by #181812

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 181821 run on x86_64-darwin 1

6 packages built:

boxfort
criterion
nanomsg
nanopbMalloc
python310Packages.nanomsg-python
python39Packages.nanomsg-python


text:
rathole: init at 0.4.3

Description of changes
Rathole is a lightweight and high-performance reverse proxy for NAT traversal, written in Rust. An alternative to frp and ngrok.
https://github.com/rapiz1/rathole

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Need the Security framework to build in Darwin.
See for example the rates package.

Ah, I was hoping that only Security would be needed, but now I see that CoreFoundation is also needed, and there may be other. I guess I'll have to clone the branch tomorrow and try until it builds, and then I'll comment what is needed.

@smancill Is there some way to check what else is required without having a darwin machine?

Check the error log for Darwin in ofborg checks after each push.

Result of nixpkgs-review pr 185388 run on x86_64-darwin 1

1 package built:

rathole


text:
ocaml-vdom: init at 0.2

Description of changes
Elm architecture and (V)DOM for OCaml
This package contains:

OCaml bindings to DOM and other client-side Javascript APIs (using gen_js_api).
An implementation of the Elm architecture, where the UI is specified as a functional "view" on the current state.

https://github.com/LexiFi/ocaml-vdom
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

It seems that ojs should be listed in propagatedBuildInputs.

I am using this derivation successfully in this flake: https://github.com/jayesh-bhoot/pin-unpin-tab/blob/ocaml-vdom/flake.nix
To me, same logic as I described in https://github.com/NixOS/nixpkgs/pull/172194#discussion_r950890355 should apply here too.

It seems that ojs should be listed in propagatedBuildInputs.

I think I understand your point now. The project that I was using to test these build derivations is littered with explicit dependencies on the "base" libraries - js_of_ocaml, gen_js_api, etc.
As soon as I tried using this ocaml-vdom derivation standalone (https://github.com/jayesh-bhoot/ocaml-vdom-nix-derivation-demo), I got Error: Library "ojs" not found and later Error: Program js_of_ocaml not found in the tree or in PATH.
Only after I set these two derivations as propagatedBuildInput in this ocaml-vdom derivation did the project compile.

I am curious to learn how to decide what goes where. I usually base a derivation on the package's opam file. In ocaml-vdom's case, it does't explicitly list ojs. Even its dune file does not list an explicit dependency on ojs.
How do I figure it out?

but I don’t know about js-of-ocaml-compiler.

I got an error for that when I tried to use the ocaml-vdom derivation.
Wow. This is a lot of trial and error.

Can we call it vdom instead? the ocaml-* prefix seems a bit pointless.

I wanted to do the same. But

The library's opam listing (https://opam.ocaml.org/packages/ocaml-vdom/) uses the ocaml-vdom. Better to be consistent.
While testing the derivation, dune could find the library only with ocaml-vdom (https://github.com/jayesh-bhoot/ocaml-vdom-nix-derivation-demo/blob/main/dune). Interestingly, the examples in their own github repo (https://github.com/LexiFi/ocaml-vdom/blob/master/examples/demo/dune) uses just vdom. I couldn't figure out why, except that the dune files for those examples may be outdated?

The library's opam listing (https://opam.ocaml.org/packages/ocaml-vdom/) uses the ocaml-vdom. Better to be consistent.

OK this is fair, I had missed it.
For your clarification: you could call it vdom in nix and pname = "ocaml-vdom" so that Dune could find it.

2. While testing the derivation, dune could find the library only with ocaml-vdom (https://github.com/jayesh-bhoot/ocaml-vdom-nix-derivation-demo/blob/main/dune). Interestingly, the examples in their own github repo (https://github.com/LexiFi/ocaml-vdom/blob/master/examples/demo/dune) uses just vdom. I couldn't figure out why, except that the dune files for those examples may be outdated?

yes, it looks like they changed the library name https://github.com/LexiFi/ocaml-vdom/commit/948bcae4ac922e3260f1aee956063f1727dc441d

yes, it looks like they changed the library name https://github.com/LexiFi/ocaml-vdom/commit/948bcae4ac922e3260f1aee956063f1727dc441d

I really should develop a habit to dig into others' source codes, instead of keep guessing.
I will file an issue on their repo tomorrow.

authors: anmonteiro jayesh-bhoot


text:
python3Packages.pep8-naming: 0.13.1 -> 0.13.2

Description of changes

changelog: https://github.com/PyCQA/pep8-naming/blob/0.13.2/CHANGELOG.rst#0132---2022-08-19
diff: https://github.com/PyCQA/pep8-naming/compare/0.13.1...0.13.2
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Dupe of #187724


text:
talosctl: 1.1.2 -> 1.2.0

https://github.com/siderolabs/talos/releases/tag/v1.2.0
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Still marked as draft?

Still marked as draft?

Yes, I forgot to leave a comment, sorry. Waiting for binaries uploaded to be uploaded/release marked as latest.

authors: flokli zowoq


text:
thc-hydra: 9.3 -> 9.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/vanhauser-thc/thc-hydra/releases.
meta.description for thc-hydra is: "A very fast network logon cracker which support many different services"
meta.homepage for thc-hydra is: "https://github.com/vanhauser-thc/thc-hydra"
meta.changelog for thc-hydra is: "https://github.com/vanhauser-thc/thc-hydra/raw/v9.4/CHANGES"
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 9.4 with grep in /nix/store/m74cy6jskg8fi7437xrwdfz88iq4yzq9-thc-hydra-9.4
found 9.4 in filename of file in /nix/store/m74cy6jskg8fi7437xrwdfz88iq4yzq9-thc-hydra-9.4

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
thc-hydra

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/m74cy6jskg8fi7437xrwdfz88iq4yzq9-thc-hydra-9.4 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A thc-hydra https://github.com/r-ryantm/nixpkgs/archive/57b727fb4a3aaff31b61eb244f7350c3affceaf0.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/m74cy6jskg8fi7437xrwdfz88iq4yzq9-thc-hydra-9.4
ls -la /nix/store/m74cy6jskg8fi7437xrwdfz88iq4yzq9-thc-hydra-9.4/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

thc-hydra

Maintainer pings
cc @offlinehacker for testing.

@ofborg eval

authors: r-ryantm zowoq


text:
new-session-manager: 1.6.0 -> 1.6.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/linuxaudio/new-session-manager/releases.
meta.description for new-session-manager is: "A session manager designed for audio applications."
meta.homepage for new-session-manager is: "https://new-session-manager.jackaudio.org/"
meta.changelog for new-session-manager is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.6.1 with grep in /nix/store/02lkxm4v5rvf2hlcdp1adsdhs99m4xx2-new-session-manager-1.6.1
found 1.6.1 in filename of file in /nix/store/02lkxm4v5rvf2hlcdp1adsdhs99m4xx2-new-session-manager-1.6.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
new-session-manager

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/02lkxm4v5rvf2hlcdp1adsdhs99m4xx2-new-session-manager-1.6.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A new-session-manager https://github.com/r-ryantm/nixpkgs/archive/ff68b5f8961cdc9d52ce91ef275d78b1cac05145.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/02lkxm4v5rvf2hlcdp1adsdhs99m4xx2-new-session-manager-1.6.1
ls -la /nix/store/02lkxm4v5rvf2hlcdp1adsdhs99m4xx2-new-session-manager-1.6.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

new-session-manager

Maintainer pings
cc @6AA4FD for testing.

Result of nixpkgs-review pr 195849 run on x86_64-linux 1

1 package built:

new-session-manager

authors: onny r-ryantm


text:
dialect: 2.0.2 -> 2.1.1

Description of changes
Updated versions of the app now require blueprint-compiler 0.4.0 (with PR available at #190223) but seeing that it works even the current version (0.2.0), I thought to proceed and update it.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Maybe we can add an update script.

So please add
  passthru = {
    updateScript = nix-update-script {
      attrPath = pname;
    };
  };

So please add
  passthru = {
    updateScript = nix-update-script {
      attrPath = pname;
    };
  };

Done.

Updated to Dialect 2.1.1 (which was released just after the approval).
@linsui, you might want to take a look again.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/788

So please add

We don't necessarily need this. It is just boilerplate.

authors: SuperSandro2000 foo-dogsquared linsui nixos-discourse


text:
chex, dm-tree, flax upgrades

Description of changes
Fix https://github.com/NixOS/nixpkgs/issues/197159 and complete some relevant upgrades.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

i'll go ahead and merge tomorrow unless any one objects


text:
Distributed update

Motivation for this change
This update of distributed compresses network traffic & has a working bokeh status interface (can be used by adding bokeh to your path)
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[x] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Are the tests functioning?
A rebase is needed.

Rebased - tests are working now, I hadn't tested on 3.5, apologies. Now nox-review pr breaks due to too many new packages. I did manual nix-builds for 2.7 & 3.5 and they worked.

authors: FRidh teh


text:
youtube-dl: 2016-11-22 -> 2016-11-27

Motivation for this change
youtube-dl update
most noteable changes:

Add support for webcaster.pro
[youtube:playlist] Pass disable_polymer in URL query

Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Thank you

authors: goetzst joachifm


text:
common update script (do not merge, PR opened for comments)

Few days ago I proposed on the mailing list to unify a way how we update packages. This is an initial attempt at that.
To update one package by attribute name run (from the root of nixpkgs repo):
$ nix-shell update.nix --argstr package firefox-beta-bin

To update all package maintained by me (@garbas) then run:
$ nix-shell update.nix --argstr maintainer garbas

I only implemented update script for firefox-bin since it was on my list for quite some time (I replaced ruby with bash). I added passthru.updateScript attribute to firefox-bin expression which is expected to be executable script which updated nixpkgs to updated version of firefox-bin.

passthru.updateScript can be implemented in any language. We should not limit that.
initially every maintainer should run nix-shell update.nix ...  on their own. at later point we can automate this or not, we'll see.
I agree that updateScript for firefox-bin is ugly (I'll improve it later), but I just needed something to show of how I imagined update scripts to work. also and I had no clue how to change that ruby script.
update.nix arguments are discussable. maybe we need few more maybe error outputs should be better. most likely the answer is yes. Lets discuss what should we add / remove / ...

Do you want to call this passthru.updateScript or meta.updateScript? It is package metadata, after all.

@ttuegel :+1: makes sense (i'll batch suggestions) and then implement them

Good idea to have a common interface to updating packages.
While you said the Firefox example is still WIP, I wonder whether it is good practice to add dependencies of the update script to the function that builds the derivation. How about using a script with a nix-shell shebang instead?

how about turning the update scripts into own derivations with own files, they could be a separate nix file, be called as a package and have the executable outputting the current data as version
i wonder if there is way to evaluate actual nix paths without putting them into store (so the target/source file can be given as a file
in addition it makes sense to be able to have update scripts as general packages
think of the dozens of packages coming from a apt repository for example (steam + deps, enpass).
also for example python/lua/ruby packages and others do share a very common way to obtain update metadata
it would be really nice to be able to just drop in a generic helpers to most of those and be done with it

Last time I have tried to put a lot of stuff for an auto-updater into expressions, it started annoying people really quickly… So now I put stuff in a separate file near the expression. Maybe the size of the updater means it should be in a separate file. Of course, there are many reusable snippets around that could help reducing it size.
This means that I will just write the updater as «call the existing update script» for my expressions.
Also, do I understand correctly that every update-enabled expression needs its file path, and the example stores it in a non-standard format (pushd in the middle of the code)? If we want to ever refactor the layout (and we probably do), we need to pay attention to separating the «path-to-self» part in a sane way. Or just ask Nix to evaluate it.

@FRidh :-1: on nix-shell shebang. and i tried to use them initially but i quickly needed more then what nix-shell shebang offered.
@RonnyPfannschmidt @7c6f434c (update script in a separate file) as said firefox updateScript is still WIP, right now it was just easier for me to put it all in one file. Otherwise I would expect that if custom update script, and just one liner to create meta.updateScript which calls the updater.
@RonnyPfannschmidt (general update script) I'm sure as we go we will have many common update scripts. example from my current code would be a script which "looks for latest revision in a branch" but i'm sure we'll invent some more
@RonnyPfannschmidt (update multiple derivation) for those derivations where you need to manage versions "in harmony" a namespace should already exists. majority of packages already works this way, eg. pythonPackages, haskelPackages, nodePackages... then you register updateScript on the namespace itself. here are 2 examples update script which updates node and elm packages and update script which updates python packages
@7c6f434c (every updateScript needs to call pushd) I don't like this part either, ideally i would do this pushd/popd from an update.nix but I'm not sure it is possible to know the path of the expression. but i didn't look much into it. I would love to be proven wrong.
i hope i answered all the questions / concerns

@RonnyPfannschmidt (general update script) I'm sure as we go we will have many common update scripts. example from my current code would be a script which "looks for latest revision in a branch" but i'm sure we'll invent some more

I am more for reusable snippets, we already have some to break out in
nixpkgs-monitor, some other scripts, my update-walker…

@7c6f434c (every updateScript needs to call pushd) I don't like this part either, ideally i would do this pushd/popd from an update.nix but I'm not sure it is possible to know the path of the expression. but i didn't look much into it. I would love to be proven wrong.

A separate attribute would already be an improvement.
Also we could try optionally instrumenting callPackage.
A change in Nix is also an option, but this would require some careful
design so that it doesn't allow leaking NixPkgs location into NixOS
instance hash.

@FRidh :-1: on nix-shell shebang. and i tried to use them initially but i quickly needed more then what nix-shell shebang offered.

How so? If I understand the update.nix correctly, all passthru.updateScript (or meta.updateScript but won't that cause a rebuild?) needs to be is a script that knows where the file that src = ... uses is.
Regarding the snippets, we could attach the updateFromGitHub to fetchFromGitHub.update and so have something like passthru.updateScript = src.update;. This we could do with most fetchers I suppose. By default they would write to src.json or src.nix.
mkDerivation {
  src = fetchFromGitHub { }; # The arguments are in `src.nix`. `fetchFromGitHub` has `src ? src.nix`. Or do we still have issues with finding the path?
  passthru.updateScript = src.update;
};

Regarding the snippets, we could attach the updateFromGitHub to fetchFromGitHub.update and so have something like passthru.updateScript = src.update;. This we could do with most fetchers I suppose. By default they would write to src.json or src.nix.
mkDerivation {
 src = fetchFromGitHub { }; # The arguments are in `src.nix`. `fetchFromGitHub` has `src ? src.nix`. Or do we still have issues with finding the path?
 passthru.updateScript = src.update;
};

It is easy to update sha256 in-place (it is unique and it has no
interesting structure inside, after all), and I think source URLs should
refer to version, together with the name. Most of the packages contain
just one version =  line. I remember that having src.nix got people
annoyed last when I tried it, and updating the version in-place seems to
work just fine in my current experience with auto-updaters.

It is easy to update sha256 in-place (it is unique and it has no
interesting structure inside, after all), and I think source URLs should
refer to version, together with the name. Most of the packages contain
just one version =  line. I remember that having src.nix got people
annoyed last when I tried it, and updating the version in-place seems to
work just fine in my current experience with auto-updaters.

Can you link to this discussion? I use a src.nix or srcs.nix for some of my packages. These annoyed people can pry them from my cold, dead hands! :smiley:

how about having something like fetchFrom* support passing a nix/json file instead of a attributeset
then the default update script for those could use that nix file as metadata source
an alternativ would a surrounding tool that can edit fetchFromGithub expressions that are "simple?

Not sure how to look it up easily… Maybe my need to store both update meta and source data in separate files was the most annoying part.

As I said on the ML, I’d reserve the update attribute until we have found a nice interface for these scripts that integrates into CI in a uniform way. Until then the update scripts could call themselves something else and we can update gracefully once the interface exists.

@ttuegel @FRidh i tried to switch to meta.scriptUpdate but that will require a rebuild. if we stick to passthru.scriptUpdate then build of package is not required in order to run the nix-shell update.nix .... I do think updateScript fits more into meta then passthru but we would have to change something else to get this working in as meat attribute. I think this is out of scope for this PR, but if somebody feels very strongly that this should be in meta then that person should create a PR. I currently care getting this into nixpkgs without much change to existing infrastructure.
@Profpatsch update attribute is not going to be used but passthru.updateScript.
@7c6f434c @FRidh this PR doesn't restrict none of your ideas about having update script with fetchFrom* functions. it is good to have this discussion, i'm just making it clear that nothing blocks this PR.
the code has been rebased on current master and suggestions from @Mic92 were added.
if no further concerns are raised i will merge this on Monday evening hawaii timezone. after that i plan to move my currently used update scripts to nixpkgs (in a separate PR).

Why changing meta would lead to a rebuild? Of course, adding attributes to meta would need to write something in documentation, otherwise it will get randomly removed by people trying to do cleanups…
Could you do something about the pushd part?

I think the script should be attached to the passthru of src instead of the passthru of the derivation we're eventually building, and not meta. What do you think @garbas ? Is this a trivial change to make?

update attribute is not going to be used but passthru.updateScript.

Yeah, then I’d reserve both update and updateScript.

@7c6f434c (meta) no idea what is happening to meta, but for the purpose of this PR i'm going with passthru. we can easily change it afterwards.
@7c6f434c (pushd) i don't see this as a blocker for this PR. while i would wish this could be done differently. It looks like instrumenting callPackage or even nix itself would be the way to go, but that would delay this PR unnecessary.
@FRidh I would like it at the expression level, because sometimes you would want to update whole attribute set of packages (eg: using pypi2nix, elm2nix, ...). I already do this in few places outside nixpkgs and would like to bring this to nixpkgs.
@Profpatsch sry, not sure I understand what you want. this PR uses updateScript. I think it clearly states the intent, and this word does not appear in nixpkgs at all, that means it would be trivial to change it.

@7c6f434c (pushd) i don't see this as a blocker for this PR. while i would wish this could be done differently. It looks like instrumenting callPackage or even nix itself would be the way to go, but that would delay this PR unnecessary.

Well, having a separate attribute for the path-to-self and using it
doesn't require much change…

I think the script should be attached to the passthru of src instead of the passthru of the derivation we're eventually building, and not meta.

mkDerivation should provide a default updateScript that delegates to the derivation's src attribute. That way if we provide one for fetchFromGitHub then all the related derivations will support it.

Could you do something about the pushd part?

The easiest way would be to split the fetchers so they import from a separate file. Then that file's path can be passed to the updater script. That's something I was exploring over at https://github.com/NixOS/nixpkgs/pull/19582

finally got around to merge this.
since we are still figuring out how to do update i wont add anything to the manual (at this point) but only write to the mailing list explaining the functionality and show few examples.
i assume before next release we might have something that we could document.

nix-shell update.nix --argstr package firefox-bin results in error: Package with an attribute name `firefox-bin` does have an `passthru.updateScript` defined. while nix-shell update.nix --argstr maintainer garbas works fine. Did I miss something?

I should have passed firefox-bin-unwrapped instead of firefox-bin.

The wrapper script should probably propagate the updateScript though

@zimbatm propagating updateScript results in double update when nix-shell update.nix --argstr maintainer garbas is executed, i.e., both firefox-bin and firefox-bin-unwrapped will be updated.

Good point. Those would be uniquified away in the update.nix file.

update.nix has executable permission for some reason.

Can update.nix be moved to a subdirectory (probably maintainers/scripts) in order not to clutter the root directory?

authors: 7c6f434c FRidh Profpatsch RonnyPfannschmidt edolstra garbas taku0 ttuegel zimbatm


text:
python310Packages.python-fsutil: 0.8.0 -> 0.9.1

Changelog: https://github.com/fabiocaccamo/python-fsutil/blob/0.9.1/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 209039 run on x86_64-linux 1

2 packages failed to build:

python310Packages.django-maintenance-mode
python39Packages.django-maintenance-mode

6 packages built:

dvc
dvc-with-remotes
python310Packages.python-benedict
python310Packages.python-fsutil
python39Packages.python-benedict
python39Packages.python-fsutil


text:
deepin(library): init at 20.8

Description of changes
I'm trying to port  Deepin Desktop Environment to NixOS. Resume work of @romildo and (at)worldofpeace on https://github.com/NixOS/nixpkgs/issues/94870
I created a flake repository for this work. Porting work nearing completion，I think it's time to request a review.
It will need 70+ commits to add DDE for NixOS, Here is the first part, add all libraries needed for DDE.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 210477 run on x86_64-linux 1

2 packages blacklisted:

nixos-install-tools
tests.nixos-functions.nixos-test

14 packages built:

deepin.dde-qt-dbus-factory
deepin.deepin-wayland-protocols
deepin.disomaster
deepin.docparser
deepin.dtkcommon
deepin.dtkcore
deepin.dtkgui
deepin.dtkwidget
deepin.dwayland
deepin.gio-qt
deepin.image-editor
deepin.qt5integration
deepin.qt5platform-plugins
deepin.udisks2-qt5

@ofborg build deepin

@ofborg build deepin

@ofborg build deepin

authors: onny wineee


text:
gtk-layer-shell: fix cross compilation

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[x] riscv64-linux (cross)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 211502 run on x86_64-linux 1

21 packages built:

avizo
eww-wayland
greetd.gtkgreet
gtk-layer-shell
gtklock
nwg-bar
nwg-dock
nwg-drawer
nwg-launchers
nwg-menu
nwg-panel
nwg-wrapper
sirula
swaynotificationcenter
swaysettings
waybar
wayfire
wayfirePlugins.wf-shell (wayfireApplications-unwrapped.wayfirePlugins.wf-shell)
wayfireApplications-unwrapped.wcm
wcm
wlogout

Darwin build fails
meson.build:15:0: ERROR: Dependency "wayland-client" not found, tried pkgconfig and framework

Still fails, is wayland even supported on darwin?

checked and wayland does not contain wayland-client.pc on darwin, only wayland-scanner.pc
also checked that gtk-layer-shell was failing before this pr
lets mark it linux only

authors: Artturin NickCao superherointj


text:
haskell.packages.ghc94.X11-xft: extract cabal#8455 workaround into helper function

Description of changes
See comments / commit messages. Having the function and common location in the file should make the overrides easy to clean up when we have a proper solution.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ofborg build haskell.packages.ghc94.X11-xft haskell.packages.ghc94.pango haskell.packages.ghc94.cairo haskell.packages.ghc94.glib

Wow, nice workaround!

authors: cdepillabout sternenseemann


text:
gcc: fix libgccjit cross

Description of changes
Before this commit, pkgsCross.*.libgccjit would fail to build for two reasons:

Apparently --enable-lang=jit requires --enable-plugin, but   the configury is unaware of this requirement.  The failure mode   is difficult to diagnose; the build fails with a compile error   due to <dlfcn.h> not being included.

libcCross and threadsCross were not being passed to libgccjit in   all-packages.nix.  These are boilerplate parameters that are   repeated several times in all-packages.nix, so at some point we   should probably make them default arguments of   gcc/${version}/default.nix.

This commit fixes the two problems above, respectively, by:

Adding an assert to check for the unsupported combination and   provide feedback at eval time.

Passing the missing parameters.

Things done

Built on platform(s)

[x] aarch64-linux (pkgsCross.aarch64.libgccjit on x86_64-linux)

@ofborg build pkgsCross.aarch64-multiplatform.libgccjit

Hrm, apparently this only works for gcc>=11, so it will have to wait for #209870

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/emacs-overlay-gives-architecture-compiler-version-and-macos-mismatch-warnings/26197/2

@amjoseph-nixpkgs #209870 has been merged, any chance you could pick this back up?

@ofborg build pkgsCross.aarch64-multiplatform.libgccjit

Latest push should work.
The patch needs to go upstream first, and there's some minor cleanup to do.
@ofborg build pkgsCross.aarch64-multiplatform.libgccjit

Fixed merge conflict.

authors: ameyp amjoseph-nixpkgs nixos-discourse


text:
signalbackup-tools: 20230305 -> 20230307-1

Description of changes
Update to latest version. No changes that effect build (diff: https://github.com/bepaald/signalbackup-tools/compare/20230305...20230307-1).
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 220072 run on x86_64-darwin 1

1 package built:

signalbackup-tools

Result of nixpkgs-review pr 220072 run on aarch64-darwin 1

1 package built:

signalbackup-tools


text:
signalbackup-tools: 20230322 -> 20230329

Description of changes
Update to latest version. No changes that effect build (diff: https://github.com/bepaald/signalbackup-tools/compare/20230322...20230329).
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 223994 run on x86_64-darwin 1

1 package built:

signalbackup-tools

Result of nixpkgs-review pr 223994 run on aarch64-darwin 1

1 package built:

signalbackup-tools


text:
tandoor-recipes: fix build

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

I think you should instead use packageOverrides to modify the version of crispy-forms used in the package, rather than change the global version.

I think you should instead use packageOverrides to modify the version of crispy-forms used in the package, rather than change the global version.

This is less preferable since python3Packages.django-crispy-forms is failing on master right now, and the fix will necessarily introduce format = "pyproject" and setuptools, and thus will break the overridden one.

@wegank you could use overridePythonAttrs to use the old format.

I mean, if you want python3Packages.django-crispy-forms to always points to the latest version (which I don't see the need for), it's much more robust to create a python3Packages.django-crispy-forms_1_14 than to override a bunch of stuff that might need changes every time an upgrade is done.

I think it makes more sense to avoid a global change for what should be a local fix.

Please do what @ambroisie says.

cc @ambroisie

authors: ambroisie mweinelt wegank