Re: BuildProfileSpec example equivalence question
Hi Josch, * Johannes Schauer Marin Rodrigues [2024-10-16 * 09:21]: The third example on https://wiki.debian.org/BuildProfileSpec is: I now changed the example to one that is actually used in the wild. I hope I didn't mess up the wording. Hope this makes things clearer. The final sentence in the explanation states that the build profile restrictions are a conjunctive normal form expression; is that actually correct? Because CNF would be the AND'ing of OR's, but if I understand it correctly, the terms *inside* the angle brackets are AND'ed and the brackets themselves OR'd, which makes it a DNF, *disjunctive* normal form. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1085206: ITP: evalidate -- Validation and secure evaluation of untrusted Python expressions
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: evalidate Version : 2.0.3 Upstream Contact: Yaroslav Polyakov * URL : https://github.com/yaroslaff/evalidate * License : MIT Programming Lang: Python Description : Validation and secure evaluation of untrusted Python expressions Evaluate user-supplied Python expressions by walking their syntax tree and allowing only operations that pass a given security model. I'm packaging this because it's a new dependency of buildbot 4.1.0. I plan to maintain it within the Debian Python Team. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: BuildProfileSpec example equivalence question
Hi Feri, Quoting Ferenc Wágner (2024-10-12 19:39:27) > The third example on https://wiki.debian.org/BuildProfileSpec is: > > Build-Depends: foo > > In this case, the source package would build depend on foo if either > both, nocheck and cross are active or if the profile nocheck is > active. [...] > > This is fully consistent with the definitive part above it, but isn't > this equivalent to the simpler Build-Depends: foo ? If so, I'd > rather use a different example which does not have this confusing property. > Or do I miss something here? I now changed the example to one that is actually used in the wild. I hope I didn't mess up the wording. Hope this makes things clearer. Thanks! cheers, josch signature.asc Description: signature
Private code: to forge, or not to forge?
Hi all, this is offtopic (sorry!), but since we kept discussing Salsa - I wonder, what are people doing for private code? I have around 40 git repositories of private code that I keep, and while a subset of them are somewhat managed (living under a common `gitroot` directory), not all are. Plus, all under my user, so I could easily shoot myself in the foot via a force push, and I don't have any actual automation about either tests (I need to keep remembering to run tests), nor do I have automated builds afterwards. Etc. etc. So I was thinking, I could install a git forge for just myself, remove admin rights from my normal user, enable branch protections, add CI/CD, automate a lot of internal package builds, etc. but it does seem a lot of overhead. But yes, it would be a full solution, and mostly standard rather than hand-built. I dream of pushing a commit, then having automated debian packages built for both amd64 and arm64 and uploaded to my internal apt repo. I wonder, does anyone do this? And if so, how? >From what I see, in Debian we only have Gitlab, and my internet searches say Gitlab itself is heavy on resources. Gitea/Forgejo are common recommended solutions for "home hosting", but neither is packaged. There's also gitolite, but that's just the ACL aspect (still, it would be better than what I do today, so at least I will switch to it). What do people think? And thanks for reading. iustin
Re: Will i386 released for Trixie and if no can we stop working on it now?
On Thu, Oct 17, 2024 at 10:48:21AM +0800, Sean Whitton wrote: > Hello, > > I hadn't heard of these architecture-is-64-bit and not-supported-on > metapackages(?). Would someone who knows how they are meant to work > consider submitting a patch for Policy? Thanks. I think they, just like isa-support, are means to circumvent the Policy / work around its and dpkg's shortcomings and so I'm not sure if it makes sense to document them there, and if so, where exactly. -- WBR, wRAR signature.asc Description: PGP signature
Re: Private code: to forge, or not to forge?
On Wed, 2024-10-16 19:24:32 +0200, Daniel Baumann wrote: > On 10/16/24 18:18, Iustin Pop wrote: > > Gitea/Forgejo are common recommended solutions for "home hosting", but > > neither is packaged. > > (jftr) I'm currently working with Forgejo upstream to get one last > feature implemented that we'll need at work to switch to it, and then > finish the packaging of it in Debian. Realistically I expect the > packages to be ready by end of the year (we have local ones that need > some polishing/finishing in order to get them acceptable for Debian, as > well as a bunch of build-depends).. That is great news! I am at about the same point as Iustin is. At work, we're using Gitlab as well (but it's a fat boy.) And alternatives aren't packaged. So I'll probably be one of your first users in January (coincidentally, I'll also have three weeks of holidays!) Thanks a lot for your work! MfG, JBG -- signature.asc Description: PGP signature
Re: Will i386 released for Trixie and if no can we stop working on it now?
Hello, I hadn't heard of these architecture-is-64-bit and not-supported-on metapackages(?). Would someone who knows how they are meant to work consider submitting a patch for Policy? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: BuildProfileSpec example equivalence question
Hi Timo, Quoting Timo Röhling (2024-10-16 10:00:25) > >> The third example on https://wiki.debian.org/BuildProfileSpec is: > >I now changed the example to one that is actually used in the wild. > >I hope I didn't mess up the wording. Hope this makes things > >clearer. > The final sentence in the explanation states that the build profile > restrictions are a conjunctive normal form expression; is that > actually correct? > > Because CNF would be the AND'ing of OR's, but if I understand it > correctly, the terms *inside* the angle brackets are AND'ed and the > brackets themselves OR'd, which makes it a DNF, *disjunctive* normal form. thank you for spotting that issue. It absolutely is a DNF. And what's even worse, there is another place in the document where it says it's a DNF and not a CNF. Ouch! Thank you for spotting this! cheers, josch signature.asc Description: signature
file-roller old bugs
hi i noticed that there is a lot of very old( > 13 years old) outstanding bugs in file-roller bugs page and some of then i confirmed that it's n longer reproducible most probably fix is it ok to close it and archive it or what is your suggestion on that -- Best Regards Mina
Re: file-roller old bugs
On Wed, Oct 16, 2024 at 11:43:59PM +0300, Mina wrote: > hi > i noticed that there is a lot of very old( > 13 years old) > outstanding bugs in file-roller bugs page and some of then i confirmed > that it's n longer reproducible most probably fix > is it ok to close it and archive it or what is your suggestion on that > Filing a "no longer reproducible as of date" and closing the bugs will help, yes. Andy > -- > Best Regards > Mina >
Re: Private code: to forge, or not to forge?
On 10/16/24 18:18, Iustin Pop wrote: > Gitea/Forgejo are common recommended solutions for "home hosting", but > neither is packaged. (jftr) I'm currently working with Forgejo upstream to get one last feature implemented that we'll need at work to switch to it, and then finish the packaging of it in Debian. Realistically I expect the packages to be ready by end of the year (we have local ones that need some polishing/finishing in order to get them acceptable for Debian, as well as a bunch of build-depends).. ..which reminded me that I forgot to take over the Forgejo RFP, done now. Regards, Daniel
