Bug#1017994: ITP: zigpy -- Python Zigbee stack
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Gard Spreemann Severity: wishlist * Package name: zigpy Version : 0.50.1 Upstream Author : Russell Cloran and contributors * URL : https://github.com/zigpy/zigpy * License : GPL-3+ Programming Lang: Python Description : Python Zigbee stack zigpy is a hardware independent Zigbee protocol stack integration project to implement Zigbee standard specifications as a Python 3 library. Zigbee integration via zigpy allows you to connect one of many off-the-shelf Zigbee Coordinator adapters using one of the available Zigbee radio library modules compatible with zigpy to control Zigbee based devices. There is currently support for controlling Zigbee device types such as binary sensors (e.g., motion and door sensors), sensors (e.g., temperature sensors), lights, switches, buttons, covers, fans, climate control equipment, locks, and intruder alarm system devices. The package is useful for interacting over the increasingly widespread Zigbee home automation and IoT protocol. An RFP was made last year [1]. I intend to maintain the package myself. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002638 signature.asc Description: PGP signature
Need a buildd build after trip through NEW -- best practice?
Commonly, I update a package that provides a shared library. Due to the package naming convention, a new SOVERSION necessitates a trip through NEW, which in turn means a binary upload. The binary upload cannot transition to testing -- a buildd binary build is required. So far as I know -- assuming [1] is still up-to-date, this means a nuisance upload just bumping the debian revision from -1 to -2. Is this still the recommended practice? I've also been wondering about the "Give Back" action button on the buildd log page. It doesn't work in this case because "Package in state Installed, cannot give back. ✗". Wondering if the logic can be modified to also check whether the build was done on a buildd -- e.g. check whether the logs column contains "no log". If it wasn't a buildd build, can the giveback be allowed? Thanks, -Steve [1] https://wiki.debian.org/SourceOnlyUpload signature.asc Description: This is a digitally signed message part.
Re: Need a buildd build after trip through NEW -- best practice?
On Tue, 2022-08-23 at 16:59 -0500, Steven Robbins wrote: > The binary upload cannot transition to testing -- a buildd binary build is > required. So far as I know -- assuming [1] is still up-to-date, this means a > nuisance upload just bumping the debian revision from -1 to -2. Is this > still > the recommended practice? The release team automatically do binNMUs for packages that need a rebuild to transition to testing and are able to be binNMUed, so for many packages you don't need to worry about this. If for some reason they don't do this or for arch:all packages, you need to reupload. Usually I use this as an opportunity for some extra package polish. The patch for dropping NEW binaries has been in dak for two years but its configuration options were never enabled by ftp-master so far. Dinstall::ThrowAwayNewBinarySuites Dinstall::ThrowAwayNewBinaryComponents > I've also been wondering about the "Give Back" action button on the buildd log The give-back action is only for failed builds, not successful ones. For successful builds you need a binNMU or new source version. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Need a buildd build after trip through NEW -- best practice?
On Tue, Aug 23, 2022 at 04:59:10PM -0500, Steven Robbins wrote: > Commonly, I update a package that provides a shared library. Due to the > package naming convention, a new SOVERSION necessitates a trip through NEW, > which in turn means a binary upload. > > The binary upload cannot transition to testing -- a buildd binary build is > required. So far as I know -- assuming [1] is still up-to-date, this means a > nuisance upload just bumping the debian revision from -1 to -2. Is this > still > the recommended practice? yes. it's rather easy to do too, though maybe there should be something in src:devscripts implementing something along these lines: dch -i -m "Source only upload for testing migration." dch -r debuild -S cd .. ; dput $changes_file # git commit & git tag 4 out of these 5 steps I've automated for myself with small scripts written catering how "my" packages are maintained (which is the part where putting this in src:devscripts is not that easy...). "debuild -S" I do manually, because sometimes that's all I do and sometimes I feed the resulting source package into yet another small script called 'spb', because it's running _s_udo _p_builder _b_uilt on the latest source package in $PWD. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ When this virus is over, I still want some of you all to stay away from me. signature.asc Description: PGP signature
Re: Need a buildd build after trip through NEW -- best practice?
On 24 August 2022 3:29:10 am IST, Steven Robbins wrote: >The binary upload cannot transition to testing -- a buildd binary build is >required. So far as I know -- assuming [1] is still up-to-date, this means a >nuisance upload just bumping the debian revision from -1 to -2. Is this still >the recommended practice? Yes. >I've also been wondering about the "Give Back" action button on the buildd log >page. It doesn't work in this case because "Package in state Installed, >cannot give back. ✗". This was probably done to ensure only source-only uploads make it through. >Wondering if the logic can be modified to also check >whether the build was done on a buildd -- e.g. check whether the logs column >contains "no log". If it wasn't a buildd build, can the giveback be allowed? It was probably intentional. In any case, you might want to CC the wanna-build team ML as well[2] >[1] https://wiki.debian.org/SourceOnlyUpload [2]: https://lists.debian.org/debian-wb-team/ -- Regards, Nilesh
Re: Need a buildd build after trip through NEW -- best practice?
[My earlier mail went blank, not sure what's up with K-9] On 24 August 2022 3:29:10 am IST, Steven Robbins wrote: >The binary upload cannot transition to testing -- a buildd binary build is >required. So far as I know -- assuming [1] is still up-to-date, this means a >nuisance upload just bumping the debian revision from -1 to -2. Is this still >the recommended practice? Yes. >I've also been wondering about the "Give Back" action button on the buildd log >page. It doesn't work in this case because "Package in state Installed, >cannot give back. ✗". Yes, because it already succeeded. You can only `give back' for builds that failed. > Wondering if the logic can be modified to also check >whether the build was done on a buildd -- e.g. check whether the logs column >contains "no log". If it wasn't a buildd build, can the giveback be allowed? It seems intentional, so that source-only uploads are really done. But you might want to ask wanna-build team (I am not a member/admin) here[2] >[1] https://wiki.debian.org/SourceOnlyUpload [2]: https://lists.debian.org/debian-wb-team/ -- Best, Nilesh
