Re: Current NEW review process saps developer motivation
On Mon, 2022-08-29 at 11:58 +0100, Wookey wrote: > Something of an aside from the current debate, but GObject > introspection introduced significant problems with cross-compiling > because the introspection process produces different results when done > on different architectures so you couldn't just cross- do it. It occurred to me that if the compiler/linker could be made to generate the GI data and then something else split it out of the binary (similar to how debug symbols work) then this issue could potentially be solved, does that sound feasible at all? > Maybe someone has fixed this in the nearly a decade since I looked in > to it and the point is moot? But I doubt it. It is still present. It got brought up at DebConf22 in the cross BoF and is mentioned by helmut on #debian-bootstrap/etc when necessary. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On Mon, 2022-08-29 at 12:33 +0530, Pirate Praveen wrote: > May be we should be able to tag packages with in NEW into categories > like this (similar to how a DD can give back a failed build via web > interface). This may need to go through a GR. If we prioritize packages > in NEW required for updating other dependencies, that can help things > faster. When I upload packages to NEW, I know some packages are > priority and some are not, but there is no way to express that > currently. The current ad-hoc way to ask the ftp-masters for expedited package review is to state the package name and reason on the #debian-ftp IRC channel. This seems to be accepted by ftp-master and it usually works. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
Sean Whitton wrote on 27/08/2022 at 20:24:55+0200: > [[PGP Signed Part:No public key for 695B7AE4BF066240 created at > 2022-08-27T20:24:55+0200 using RSA]] > Hello, > > On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote: > >> >> On 2022-08-27 15:53, M. Zhou wrote: >> >>> That's why I still hope ftp team to recruit more people. This is >>> a very direct and constructive way to speed up everything. >>> More volunteers = higher bandwidth. >>> Recruiting more people doesn't seem to have a serious disadvantage. >> >> It does not seem to work. Either people don't want to do that, either the FTP >> team is too picky on the candidates. > > Some combination of both, but I don't think I'm suffering from bias if I > say that it's at least 80% the former. Very few people who say they'd > like to be trained confirm they'd still like to once they've had a look > at the docs for trainees, and after that, hardly any do enough trainee > reviews for the other team members to feel confident they can let them > at it on their own. > > I am the only trainee who made it through in recent years and that's > because I was highly systematic about doing lots of reviews each month. > > There are some technical improvements that would be possible. For > example, feedback to trainees is entirely done via IRC; I would much > prefer us to be doing that by e-mail. But other team members disagree > with me, I think, and I do recognise I like e-mail more than most people > do. There are ways the tools could be better. > > In general, however, existing team members, including myself, are pretty > sceptical that technical improvements would be worth the time it would > take to implement them effectively. dak as a whole is less well > maintained than other core Debian software, but the NEW queue parts are > pretty good! > > So, the bulk of the problem boils down to project members not being > interested in doing the work. I certainly understand this. It feels > just like grading student essays. Everyone finds that highly draining > at first, until you develop a sort of detachment from the activity, > where your mind is going through the motions of the activity sort of > like how your hands can be going through the motions of something like > food preparation for a familiar dish -- you have to learn that you won't > make worse judgements if you become detached in this way, just like how > you won't prepare a worse version of the dish if you do it in the > detached way. Then I just applied what I'd learned from grading to the > NEW queue, and then it's pretty fun and even relaxing when you're not in > a frame of mind to do harder thinking. But like I said, most people > don't want to do any of this, and of course being a trainee is *not* > like that. > > And then recruitment is less efficient -- not enough feedback on trainee > reviews -- because there aren't enough team members. The usual > compounding effect. Hi, I have been a trainee at the end of 2019 and beginning of 2020. What drove me away is that it was taking some bandwith because I was not used to the exercise (and TBH I kind of dislike MC which is needed a lot for the job), and I got no feedback on my reviews. Not that did plenty of them, but I did quite some. After something like 3 to 4 months I went to try being useful (I honestly felt useless as I got no feedback) somewhere else (MIA/NM FrontDesk Team). The job is not really a pleasure, it's true, but the team *needs* to find a way to be more reactive when trainees try to do it, otherwise they lose interest. My 2 cents. -- PEB signature.asc Description: PGP signature
Re: Transition proposal: pkg-config to pkgconf
Hi! On Mon, 2022-08-29 at 15:38:08 +0200, Andrej Shadura wrote: > It seems like the proposal went mostly unnoticed. Any comments, > ideas, anything? I at least read it, and it looked great. But… > Most importantly, I need a green light from the current pkg-config > maintainer (Tollef) to proceed with the plan. …as it was waiting for this, it slipped my mind. > Meanwhile, I have uploaded an updated version of the package which > dropped the crosswrapper, and instead uses the "personalities" > feature to implement its functionality. The package also no longer > needs a dpkg hook, as it ships a per-architecture symlinks in > arch-specific packages. Thank you for getting rid of both of these annoyances! I switched all my hosts and chroots to pkgconf, when I watched your DebConf presentation and it's been working great. > On Sun, 24 Jul 2022, at 17:33, Andrej Shadura wrote: > > Following a discussion at DebConf, I’d like to officially propose a > > transition > > from pkg-config to pkgconf in Debian. > > > > pkgconf is a newer, actively maintained implementation of pkg-config that > > supports more aspects of the pkg-config file specification and provides a > > library interface that applications can use to incorporate intelligent > > handling of pkg-config files into themselves (such as build file generators, > > IDEs, and compilers). Right, I track the pkg-config upstream git repo and it unfortunately has seen no major development since 2019, and not upstream release since 2017. I've also taken a peek to pkgconf from time to time, and it looks like a nice project, code wise, etc. > > Debian would benefit from switching to pkgconf by utilising a more complete > > implementation of pkg-config that handles aspects of .pc files that > > pkg-config > > does not. For example, Provides rules and Cflags.private rules are > > supported, > > and pkgconf has a better (and less costly) dependency resolver for .pc > > files. Yes. > > Migration plan > > == > > > > I believe that it would in the best interests of Debian to only ship one > > pkg-config implementation, so I propose to make pkgconf provide the binary > > package pkg-config without a possibility to fall back to the original > > implementation. This means that after pkgconf takes over the pkg-config > > binary package, all packages depending on pkg-config will be using the > > pkgconf > > implementation without being able to opt out and use the one from > > freedesktop.org. While this may seem limiting, it reduces the probability of > > some packages staying with the freedesktop.org implementation indefinitely > > and > > missing out on bug fixes or suffering from other differences in > > implementation > > details in future when pkgconf becomes even more widespread. If pkg-config was showing signs of activity, then this could perhaps be a potential concern, but given its current state, I think this makes perfect sense. > > In preparation for this migration, I ran a rebuild of all packages depending > > on pkg-config and found only very few failures [5], which may or may not be > > related to the difference in behaviour between pkg-config and pkgconf. I > > will > > perform another rebuild and continue investigating them to provide patches > > during the transition period. Great! Thanks, Guillem
Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs
kilobyte dixit: >Funny thing: there's not a single release architecture that's both >bad-endian and supports X (they do build X related packages because the >dependency graph is quite dense, but there are no users). So this Meh. Remote X, X forwarding over SSH, VNC and RDP servers exist. So do d-ports architectures, which I used to care about before sid got Poettering’d again by Md. Now I run bullseye. So no, it’s not solved itself… well, not like you said but, as I said, X *can* load wrong-endian PCF fonts. bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Re: Proposed MBF: packages still using nose
On Sun, Aug 21, 2022 at 04:04:36PM +0300, Dmitry Shachnev wrote: > Hi, > > nose [1] is a testing framework for Python, which is dead and unmaintained > since 2015 [2][3]. > > The former maintainer of nose recommends projects using nose to switch to > nose2 [4], pytest [5] or unittest from Python standard library [6]. There is > a script called nose2pytest [7] which can assist with migrating from nose to > pytest. > > nose has a Python 2 code base and it is difficult to keep it in working state > for new Python versions. It will probably become impossible after Python 3.13, > where lib2to3 will be removed [8]. > > In Debian sid, we still have 389 packages which either build-depend on nose or > use it in autopkgtests. I propose to file bugs for them asking to switch to a > supported alternative. A dd-list is attached. Thanks to everyone who replied! MBF is now done and bugs can be seen here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-modules-t...@lists.alioth.debian.org;tag=nose-rm -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
On 2022-08-28 12:14 +0100, Simon McVittie wrote: > However, GObject-Introspection has worked approximately the way it > currently works since at least 2008, and was apparently fine. Something of an aside from the current debate, but GObject introspection introduced significant problems with cross-compiling because the introspection process produces different results when done on different architectures so you couldn't just cross- do it. So it's not really 'fine', it's just adequate for most people most of the time. It's in need of some significant core rework IMHO to get rid of this very unhelpful (and not at all necessary) characteristic. I did consider doing the work needed to fix this but didn't have the bandwidth/enthusiasm at the time. Maybe someone has fixed this in the nearly a decade since I looked in to it and the point is moot? But I doubt it. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1018707: ITP: gnss-share -- Share GNSS character devices over a unix socket
Package: wnpp Severity: wishlist Owner: Evangelos Ribeiro Tzaras X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gnss-share Version : 0.4 Upstream Author : Clayton Craft * URL : https://gitlab.com/postmarketOS/gnss-share * License : GPL-3+ Programming Lang: Go Description : Share GNSS character devices over a unix socket An app for sharing GNSS location data, with support multiple clients and loading/saving AGPS data. This is meant to replace things like gpsd, and gps-share, and work together with geoclue* or other clients that support fetching NMEA location data over sockets. I plan to maintain this within the DebianOnMobile-team umbrella.
Bug#1018706: ITP: satellite-gtk -- satellite-gtk
Package: wnpp Severity: wishlist Owner: Evangelos Ribeiro Tzaras X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: satellite-gtk Version : 0.2.7 Upstream Author : Teemu Ikonen * URL : https://codeberg.org/tpikonen/satellite/ * License : GPL-3+ Programming Lang: Python Description : Adaptive GTK application which displays GNSS data Satellite is an adaptive GTK / libhandy application which displays global navigation satellite system (GNSS: GPS et al.) data obtained from ModemManager API. . It can also be used to record gpx tracks. The project was originally written with the PinePhone in mind, but there is also some work for bringing it to the Librem5 which relies on gnss-share (needs to be packaged in Debian) instead of using ModemManager. This package is useful for checking the number of satellites in view, their I plan to maintain it as part of either DebianOnMobile-team or the Python (Application) team.
Bug#1018701: ITP: golang-github-marten-seemann-qtls-go1-19 -- Go standard library TLS 1.3 implementation, modified for QUIC (Go-1.19)
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-marten-seemann-qtls-go1-19 Version : 0.1.0-1 Upstream Author : Marten Seemann * URL : https://github.com/marten-seemann/qtls-go1-19 * License : BSD-3-clause Programming Lang: Go Description : Go standard library TLS 1.3 implementation, modified for QUIC. For Go 1.19. This package is needed to make golang-github-lucas-clemente-quic-go work with newer Go version (1.19).
Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs
Le lun. 29 août 2022 à 03:30, Adam Borowski a écrit : > On Sun, Aug 28, 2022 at 04:56:26PM +, Thorsten Glaser wrote: > > Didier 'OdyX' Raboud dixit: > > >If these tests are run at build-time, errors halt the build and that > provides > > > > That may not be enough, though; there are cases where the build > > architecture determines artefact endianness (e.g. with PCF bitmap > > fonts), and that may even be enough (X servers can load PCFs from > > reverse-endian builds), but it may be a bug. So you’d ideally use > > both. > > Funny thing: there's not a single release architecture that's both > bad-endian and supports X (they do build X related packages because the > dependency graph is quite dense, but there are no users). So this > particular problem has solved itself :) > They could use xembed + vnc Bastien > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ You're alive. But that's just a phase. > ⠈⠳⣄ > >
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On Mon, Aug 29 2022 at 12:33:44 PM +05:30:00 +05:30:00, Pirate Praveen wrote: On Sun, Aug 28 2022 at 07:39:12 AM +02:00:00 +02:00:00, Andreas Tille wrote: BTW, the vast amount of new packages I'm packaging are new dependencies for existing packages to get their new versions. May be we should be able to tag packages with in NEW into categories like this (similar to how a DD can give back a failed build via web interface). This may need to go through a GR. If we prioritize packages in NEW required for updating other dependencies, that can help things faster. When I upload packages to NEW, I know some packages are priority and some are not, but there is no way to express that currently. Or we may also be able to reuse the urgency field in changelog if the idea that "uploaders should be able to prioritize some packages in NEW and ftp masters should check the priority queue before the normal queue" is acceptable to the project.
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On Sun, Aug 28 2022 at 07:39:12 AM +02:00:00 +02:00:00, Andreas Tille wrote: BTW, the vast amount of new packages I'm packaging are new dependencies for existing packages to get their new versions. May be we should be able to tag packages with in NEW into categories like this (similar to how a DD can give back a failed build via web interface). This may need to go through a GR. If we prioritize packages in NEW required for updating other dependencies, that can help things faster. When I upload packages to NEW, I know some packages are priority and some are not, but there is no way to express that currently.
