Activity of the libvirt team?
Hi, I've packaged rhsrvany [0], which I'd like to maintain under the umbrella of the libvirt team. I've tried to join the salsa team on salsa [1]. But so far my request has been ignored. I checked the wiki page of team libvirt [2], however it seems mostly outdated as it still references alioth. I've asked on the mailing list [3], however the last activity there is two years ago, and my message is awaiting moderator approval. I've also poked Guido Günther directly, who seemed to have done some of the more recent uploads for libvirt. So what would be the process to join the libvirt team? I'd like to push the source repo of rhsrvany to a team-maintained space. Greetings, Lee [0] https://tracker.debian.org/pkg/rhsrvany [1] https://salsa.debian.org/libvirt-team/ [2] https://wiki.debian.org/Teams/DebianLibvirtTeam [3] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-discuss
Re: Potential MBF: packages failing to build twice in a row
El lunes, 14 de agosto de 2023 03:28:15 -03 Johannes Schauer Marin Rodrigues escribió: > Hi, > > Quoting John Goerzen (2023-08-13 23:32:03) > > On Sat, Aug 05 2023, Lucas Nussbaum wrote: > > > I wonder what we should do, because 5000+ failing packages is a lot... > > Let's think about the level of trouble we cause trying to tackle something > > that has clearly not bothered anyone for years. > > this is not the first time that is has been said in this thread that "this > hasn't bothered anybody for years". I wanted to come out and say that it has > bothered me. It just hasn't bothered me enough to investigate what the proper > way to solve it is. It hasn't bothered me enough to bother other people with > this issue. After all, I can just run "git clean -fdx" to "solve" the problem > whenever it happens. I respect your point of view, but I still think that doing that is actually better than patching things over to get the original stuff back. That being said it's fine to disagree and let's see what the raw consensus is, but taking into account why the 5k+ packages fail. If many are do to stuff like the python's egg issue, well, clearly many things can be easily fixed. If the majority of issues are because maintainers do not care maybe it is really a signal of something that used to make sense and nowadays might not do as much as it used to. Making those bugs RC would mean forcing people to solve a feature that they are clearly not using. But do please file the bugs, and even better, send patches! signature.asc Description: This is a digitally signed message part.
Re: Enabling -fstack-clash-protection for trixie
Hi Lucas, On 2023-08-12 08:18, Lucas Nussbaum wrote: > Results: > http://qa-logs.debian.net/2023/08/11.stackclash-arm/ > > I only included logs for builds that succeeded in a vanilla build, > but failed with the custom build. Thank you so much, this is great! There's not much fallout. I'm not sure how the deal with AWS is (how many credits we have available and such) but would it be possible to repeat the experiment for armhf too? The Neoverse cpus can run 32 bit code natively, so at least from the point of view of the underlying hardware this shouldn't be a problem. I've tried the following on a m6g.medium and it did the right thing: sbuild-createchroot --arch=armhf --components=main,contrib,non-free,non-free-firmware sid /srv/sid-armhf Cheers, Emanuele
Bug#1049347: ITP: liboprf - Oblivious Pseudo-Random Generator and Threshold OPRF library
Package: wnpp Severity: wishlist Owner: Joost van Baal-Ilić * Package name: liboprf Version : 0.1 Upstream Author : Stefan Marsiske * URL : https://github.com/stef/liboprf * License : GPLv3, LGPLv3 Programming Lang: C Description : Oblivious Pseudo-Random Functions and Threshold OPRF library This library implements the basic OPRF (ristretto255, SHA-512) variant from the "Oblivious Pseudorandom Functions using Prime-Order Groups" Draft from the IRTF Crypto Forum Research Group (https://github.com/cfrg/draft-irtf-cfrg-voprf/). Additionally it implements a threshold OPRF based on "TOPPSS: Cost-minimal Password-Protected Secret Sharing based on Threshold OPRF" by Krawczyk et al (https://ia.cr/2017/363). . This library depends on libsodium. The (yet to be packaged) Klutshnik software (https://klutshnik.info/) will depend upon liboprf. I will be working on this package at (yet to be created) https://salsa.debian.org/debian/liboprf . Bye, Joost signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
On Sat, 5 Aug 2023 at 17:44, Vincent Bernat wrote: > On 2023-08-05 17:06, Lucas Nussbaum wrote: > > Should we give up on requiring a 'clean' target that works? After all, > > when 17% of packages are failing, it means that many maintainers don't > > depend on it in their workflow. > > Yes, please, this does not make sense anymore to enforce such a rule > when it is now easy to use "git clean -fxd" or to build in a chroot. > Moreover, binary packages in the archive are now built by an official > builder. > Agreed. This should result in a policy change. A "clean" target is entirely superfluous these days, and has been for probably decades. It is easy, and better in most measurable ways, to build from scratch every time. You only need to reuse a build folder when debugging, and then "clean" isn't relevant anyway. -- Tino Didriksen
Re: Potential MBF: packages failing to build twice in a row
On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote: On 08/08/23 at 10:26 +0200, Helmut Grohne wrote: Are we ready to call for consensus on dropping the requirement that `debian/rules clean; dpkg-source -b` shall work or is anyone interested in sending lots of patches for this? My reading of the discussion is that there's sufficient interest for ensuring that building-source-after-successful-binary-build works. my reading said that there was interest in making sure that binary builds work repeatedly, and almost no interest in making sure that building source from a rules/clean works. certainly not thousands of packages worth of busy work level of interest.
Re: Activity of the libvirt team?
On Mon, Aug 14, 2023 at 01:37:23PM +0200, Lee Garrett wrote: > Hi, > > I've packaged rhsrvany [0], which I'd like to maintain under the umbrella of > the libvirt team. I've tried to join the salsa team on salsa [1]. But so far > my request has been ignored. I checked the wiki page of team libvirt [2], > however it seems mostly outdated as it still references alioth. I've asked > on the mailing list [3], however the last activity there is two years ago, > and my message is awaiting moderator approval. I've also poked Guido Günther > directly, who seemed to have done some of the more recent uploads for > libvirt. > > So what would be the process to join the libvirt team? I'd like to push the > source repo of rhsrvany to a team-maintained space. I think you've done the right thing by asking to be added to the libvirt-team group on Salsa. Unfortunately I don't have admin privilege to the group, so you'll have to wait for Guido to act on the request. Same thing for the pkg-libvirt-discuss, which I believe Guido is the moderator for. Please hold on tight, I'm sure he'll get around to it :) The wiki page looks pretty outdated, yes. If you have time to change it so that it points to up-to-date resources, that would be very much appreciated! Just as you taking the time to package rhsrvany is :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Re: Compiler runs out of memory when building a package
Thanks Johannes and Loong Jin. Neither of the suggestions were sufficient on their own, but together I think it's working. There are a few other issues that are blocking it now, but I want to say that I'm past this one. Thanks!
Re: Potential MBF: packages failing to build twice in a row
On Mon, Aug 14, 2023 at 08:28:15AM +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting John Goerzen (2023-08-13 23:32:03) > > On Sat, Aug 05 2023, Lucas Nussbaum wrote: > > > I wonder what we should do, because 5000+ failing packages is a lot... > > Let's think about the level of trouble we cause trying to tackle something > > that has clearly not bothered anyone for years. > this is not the first time that is has been said in this thread that "this > hasn't bothered anybody for years". I wanted to come out and say that it has > bothered me. It just hasn't bothered me enough to investigate what the proper > way to solve it is. It hasn't bothered me enough to bother other people with > this issue. Agreed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
__pycache__ directories (Re: Potential MBF: packages failing to build twice in a row)
Hi, I received a couple of bug reports against packages I (co) maintain regarding this issue and having a quick look, quite a few fail due to python scripts being run during the build and creating a __pycache__ directory. Examples: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1048444 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044727 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045734 Could maybe dh_clean automatically clean up such __pycache__ directories or do we really expect that each individual package does such a clean up manually? Or is there maybe a way to avoid the creation of the __pycache__ directories altogether. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Potential MBF: packages failing to build twice in a row
On 2023-08-13 22:48 +0200, Vincent Bernat wrote: > On 2023-08-10 14:38, Lucas Nussbaum wrote: > > > > My reading of the discussion is that there's sufficient interest for > > ensuring that building-source-after-successful-binary-build works. > > There is a bias asking d-devel@. You'll get people with enough time on their > hands to care about this. Nobody ever complained about not being able to > build twice in a row for years. I may not have complained to you, but I certainly have been regularly annoyed by this for many years, and have had to fix people's clean targets before I could debug the actual problem I downloaded their package to look at. Yes it's not the biggest problem in the world, but it's sizeable lump of grit in the system, at least for some of us. > We are asking a lot of people to fix problems that don't really exist. It does exist. It's broken far too often and it affects actual developers using debian tools. It's supposed to work. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
On 2023-08-14 10:19 -0400, Michael Stone wrote: > On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote: > > On 08/08/23 at 10:26 +0200, Helmut Grohne wrote: > > > Are we ready to call for consensus on dropping the requirement that > > > `debian/rules clean; dpkg-source -b` shall work or is anyone interested > > > in sending lots of patches for this? > > > > My reading of the discussion is that there's sufficient interest for > > ensuring that building-source-after-successful-binary-build works. > > my reading said that there was interest in making sure that binary builds > work repeatedly, and almost no interest in making sure that building source > from a rules/clean works. certainly not thousands of packages worth of busy > work level of interest. Yes. You are right. I (and most of the others who expressed an interest in having this working) mostly care about doing a binary build repeatedly. But doesn't this amount to much the same thing? dpkg-source will moan if the source has changed and tell you about the nice patch it has made. OK, it will let some things slide as just warnings, so 'builds binary twice' is a somewhat less stringent target than 'leaves exactly the original pristine source'. I would have to check the details, but I'm not sure how much difference this makes in practice? But yeah, I can live with the clean only cleaning well enough to do correct binary builds (although I do think it should clean enough to make correct sources too in general). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
On Mon, Aug 14, 2023 at 09:40:52PM +0100, Wookey wrote: On 2023-08-14 10:19 -0400, Michael Stone wrote: On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote: > On 08/08/23 at 10:26 +0200, Helmut Grohne wrote: > > Are we ready to call for consensus on dropping the requirement that > > `debian/rules clean; dpkg-source -b` shall work or is anyone interested > > in sending lots of patches for this? > > My reading of the discussion is that there's sufficient interest for > ensuring that building-source-after-successful-binary-build works. my reading said that there was interest in making sure that binary builds work repeatedly, and almost no interest in making sure that building source from a rules/clean works. certainly not thousands of packages worth of busy work level of interest. Yes. You are right. I (and most of the others who expressed an interest in having this working) mostly care about doing a binary build repeatedly. But doesn't this amount to much the same thing? no, not really. a lot of benign changes (like copying in new autoconf stuff) can happily be made multiple times, which doesn't affect building at all but causes busy work to undo. dpkg-source will moan if the source has changed and tell you about the nice patch it has made. OK, it will let some things slide as just warnings, so 'builds binary twice' is a somewhat less stringent target than 'leaves exactly the original pristine source'. I would have to check the details, but I'm not sure how much difference this makes in practice? we don't know, since the test was "regenerate source"--a thing very few people care about--rather than "build twice" which is the thing people do seem to care about. It seems likely that the difference is thousands of packages. I'm somewhat concerned we magically went from "should we do an MBF" to "I just did an MBF" without any real consensus in the middle. This being so painfully obvious that the MBF itself basically says there's no consensus.
