Re: How to remove 19 raku-* packages from all ARM architectures ?

Hi On 18-04-2025 15:46, Dominique Dumont wrote: Should I log one bug for all 19 packages, or one bug per package ? I'm pretty sure ftp-master has workflows that desire one bug per package as I've seen that request often enough. Paul OpenPGP_signature.asc Description: OpenPGP digital sig

Re: MBF: Packages which break with nocheck

Hi, On 16-04-2025 19:59, Santiago Vila wrote: I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck for the second build, I think it would help. I don't think anybody will use that as an excuse to file more RC bugs. They mentioned earlier on IRC that they'll do just that

Re: Planning to remove team-based R packages from 32-bit and big-endian architectures.

Hi Dirk, On 16-04-2025 18:55, Dirk Eddelbuettel wrote: | [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi That appears to be a different set of packages. The packages spotted in the original list, I assume you're talking about all of them except maybe cantor and vtk9? boot: r-recom

Re: MBF: Packages which break with nocheck

Hi Santiago, On 16-04-2025 15:04, Santiago Vila wrote: For reference, I've used this usertag for all the bugs (26 new and 3 old): https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian- q...@lists.debian.org;tag=ftbfs-nocheck-profile In one of the reports I read this: """ * When a packa

Re: Planning to remove team-based R packages from 32-bit and big-endian architectures.

Hi, On 16-04-2025 16:04, Charles Plessy wrote: If you need one of the team-maintained r-cran-* packages on a 32-bit or on a big endian architectures, which are not supported upstream, please contact me on the debian-r list and let's see how we can share the workload.  Otherwise I will start the

Re: MBF: Packages which break with nocheck

Hi, On 13-04-2025 17:12, Helmut Grohne wrote: That said, Emilio explicitly asked them not to be filed as rc on irc. That feels like RT is not internally consistent here. How about filing them as rc now and tagging them trixie-ignore later if we deem the effort too big? What I think he means,

Re: key packages RC bugs of the month April

Hi On 05-04-2025 14:06, Santiago Vila wrote: El 5/4/25 a las 8:44, Paul Gevers escribió: Remember, if you really think a bug shouldn't be RC (particularly if you are the maintainer), downgrade it with an explanation. Does this include the case where a Release Manager previously raise

key packages RC bugs of the month April

Dear all, During the preparation phase of bookworm, I was running an awareness campagne on RC bugs [1] in package in the key package set [2]. As those packages are exempted from being auto-removed, their RC bugs are ironically less exposed. Ideally we should get the number of RC bugs in trixi

Re: Building packages in the future.

Hi Santiago Sorry for dropping the ball on this. On 05-01-2025 17:56, Santiago Vila wrote: I was told that it was ok to consider those bugs as "RC for trixie" but I was also requested to be nice when reporting those bugs, so I have been reporting them as severity:normal (except when the future

Re: Packages with a history of security issues and whose packaged version is not up to date

Hi, On 13-02-2025 20:21, Santiago Ruano Rincón wrote: Any thoughts? You might also want to somehow take activity on the package into account. E.g. cacti (that I am nearly the only uploader for) has seen an update for CVE's only last week. I don't think I need (nor would I appreciate) more

Re: Bits from DPL / Feedback on attracting newcomers

Hi On 11-12-2024 12:34, Pirate Praveen wrote: If reportbug can open your already configure email client (like thunderbird) that already helps a lot. I do that all the time: paul@toba ~ $ grep thunderbird ~/.reportbugrc mua thunderbird Paul OpenPGP_signature.asc Description: OpenPGP digital

Re: Misc Developer News (#60)

Hi, On 12/1/24 11:36, Julien Puydt wrote: Can you try: sbuild --build-dir=~/Debian/repo --extra-package=~/Debian/repo This should save all binary packages to the directory and use them in subsequent runs. It doesn't: it fails saying BUILD_DIR doesn't exist. Does it still me

Re: Building with many cores without OOM

Hi Helmut, On 11/29/24 07:59, Helmut Grohne wrote: On Thu, Nov 28, 2024 at 02:39:36PM +0100, Paul Gevers wrote: And doing it in a way that can be reused by how autopkgtests are run would maybe be good too. Can you clarify what you mean here? There is autopkgtest --build-parallel and my

Re: Building with many cores without OOM

Hi Helmut, On 11/28/24 13:01, Chris Hofstaedtler wrote: IMO it would be good to support dealing with this earlier than later. And doing it in a way that can be reused by how autopkgtests are run would maybe be good too. Paul

Re: Simpler git workflow for packaging with upstreamless repositories

Hi, On 11/28/24 10:56, Pirate Praveen wrote: pristine-tar almost always fail when there are multiple orig tar files. I did not report bugs since the limitation of not working 100% is a known issue already. I'm surprised to hear this. src:cacti is using multiple orig tar files (2) for several

Re: Suitability of Rust for *all* architectures? [WAS Re: Rustc unsoundness on i386]

Hi, On 11/24/24 17:22, Andrew M.A. Cater wrote: 5. If we're moving hardware baselines for the sake of Rust (or any other software on this architecture) it's already too late. Huh? Why? [Putting my Release Team hat off] Personally I think Debian should be raising the baseline for i386. I'm no

Re: Migration blocked by tests of depending package

Hi Joachim, On 25-10-2024 07:22, Joachim Zobel wrote: The migration of our package mosquitto is blocked by failing autopkgtests of the depending package node-mqtt on s390x (See [1]). I have reported this as a bug for the failing depending package [2]. Thanks for reporting. To be fair, the s39

Re: Private code: to forge, or not to forge?

Hi, On 20-10-2024 20:24, Iustin Pop wrote: I'm also glad to hear! Although, having read more, even the LTS version (of Forgejo) has a very short lifetime, not sure how this will play with Debian releases. Likely keeping sid up with LTS or most recent versions, and relying heavily on backports fo

Re: Will i386 released for Trixie and if no can we stop working on it now?

Hi, On 17-10-2024 07:44, Andrey Rakhmatullin wrote: 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 Poli

Re: Will i386 released for Trixie and if no can we stop working on it now?

Hi, It seems that it is falling appart piece by piece, but on the other hand, it is still a release architecture, meaning that for arch:any packages that do not support it the random Debian Developer needs to do a lot of manual work, bug management, uploads, reverse-dependency chain traversals,

Re: Are 'package autoremoval emails' using very old bts data?

Hi, On 12/10/2024 16:58, Richard Lewis wrote: I couldnt work out where to ask this: Are emails about packages being removed from testing generated using stale data on what bugs are open? There are known recent issues with the freshness of the udd representation of the bts due to infrastructur

Re: signify and signify-openbsd names

Hi On 08-10-2024 09:01, Simon Josefsson wrote: 3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a 'Package: signify' that has /usr/bin/signify and to add: Do I understand correctly that signify-mail will also provide a /usr/bin/signify? That's not allowed if the binaries h

Re: Compile to ARM64 with qemu-static

Hi Vincent, On 21-09-2024 14:55, Vincent Bernat wrote: I am using cowbuilder. What would be the most straightforward way to compile packages to ARM64? Would it be allowed to use ARM64 porter boxes for this? This is mostly for HAProxy packages, so I don't intend to compile a lot of packages.

Re: Removing more packages from unstable

Hi helmut, +1 On 20-08-2024 07:28, Helmut Grohne wrote: * As packages fail to migrate to testing for a long time, a release team member eventually looks at the package. I recognize myself here. But to be totally fair, that's *mostly* about testing, and we have processes for that. Once

Re: Strange armel build error

Hi, On 16-08-2024 17:46, Alec Leamas wrote: All other builds are OK. Has anyone a hint about what might be going on here? https://release.debian.org/testing/arch_qualify.html armel column. Paul OpenPGP_signature.asc Description: OpenPGP digital signature

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

Hi all, On 03-08-2024 22:37, Salvo Tomaselli wrote: At the bottom, is it ok for a package to have a single maintainer or not? I have never wanted to be the single maintainer of a package, and here I am, I'm member of a bunch of teams, but most of my packages uploads (not a lot luckily) are f

Re: OpenPGP digital signature

Hi, On 30-07-2024 10:21, Simon McVittie wrote: Please note that imtoas...@mail.com is (presumably) not Paul, Correct. the subject line is not what the release team would use, Correct. and Paul seems unlikely to send official Debian announcements through a gmx.com mail relay with a (forge

Re: autopkgtest + podman user experience (Was: Re: Reviving schroot as used by sbuild)

Hi. On 25-06-2024 8:18 p.m., Gioele Barabucci wrote: I'd like to take this chance to suggest, instead of writing more documentation, changing the autopkgtest packaging so that it is split into various per-backend packages, each of which provides a ready-to-go pre-configured environment. See

Re: Reviving schroot as used by sbuild

Hi On 25-06-2024 6:55 p.m., Helmut Grohne wrote: This is very cool. Running autopkgtests in system containers without being root (or incus-admin) very much is what I'd like to do. And it's much better if I don't have to write my own container framework for doing it. I couldn't get it to work loc

Re: About i386 support

Hi On 14-06-2024 8:09 p.m., rhys wrote: Even under the bookworm "Intel 686-only" rules, it still works, so I still use it. It's built, it runs, it serves a purpose, and it costs very little. And you can keep trying that until it doesn't work for you anymore, we're not saying we'll hold you

Re: Illegal Instruction Using sudo in Bookworm on i686

Hi, On 09-06-2024 1:56 p.m., rhys wrote: So given that these no longer fit the "old and busted" description, is Debian going to stick with the decision to not support them? Or is Debian going to continue to support this processor, since it is still apparently a viable product, enough that new

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hi On 21-05-2024 1:08 p.m., Sean Whitton wrote: PS: I've always wondered if the dgit server shouldn't track history, even if uploads don't happen via it. A dgit clone could (should?) already provide available history, even if no upload happened via it yet. Well, 'dgit clone' adds a vcs-git rem

Re: About i386 support

Hi, On 20-05-2024 4:50 p.m., Ben Hutchings wrote: There is a tension here between the interests of (a) users that want to run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to keep using 32-bit CPUs. If i386 is meant for group (a) then the baseline should be raised to include

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Two mistakes spotted On 19-05-2024 10:05 a.m., Paul Gevers wrote: I think there's a large majority (maybe even consensus) that believe you *should* have the packaging in VCS I meant "at least should", as in "should or must". I think what

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hi all, In this discussion about mandating things, I've been wondering On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote: * mandate VCS-tracking * Yes * mandate the use of one specific VCS * Yes: git What do people think this should mean, a *should* or *must* in policy? That th

Re: About i386 support

Hi Andrew, Release team member hat on On 18-05-2024 12:28 p.m., Andrew M.A. Cater wrote: In reality, i386 should probably have been dropped early (or at the last minute) for bookworm; some libraries will be kept for compatibility but it's not realistic to maintain i386 for the whole of the trixi

Re: About i386 support

Hi On 17-05-2024 9:58 p.m., Victor Gamper wrote: Is it correct that debian 13 is planned to be released without an i386 iso and i386 is planned to be deprecated? Our current position is described here: https://lists.debian.org/debian-devel-announce/2023/12/msg3.html Paul OpenPGP_signa

Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED

Hi Jonas, On 16-05-2024 10:35 a.m., Jonas Smedegaard wrote: Just to clarify, the package in question does not directly depend on rust-ahash 0.8.9-2, that Built-Using information is (as is the general purpose of that field, I believe) transitive. Built-Using is used for license compliance so we

Re: new upstream version fails older tests of rdepends packages

Hi, On 08-05-2024 6:06 p.m., Bill Allombert wrote: Agreed, but gap does not actually breaks anything, it is just the tests in testing that are broken. So I can do that but that seems a bit artificial. Aha, that wasn't at all clear to me. If you don't want to do the artificial thing (which is

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Hi Luca, On 05-05-2024 10:04 p.m., Luca Boccassi wrote: > Hence, I intend to apply these changes in the next src:systemd upload > to unstable, probably next week. In case anybody is aware of packages/programs needing an update to cope with these changes, or any other issue, please let me know

Re: new upstream version fails older tests of rdepends packages

Hi, On 04-05-2024 11:39 a.m., Jerome BENOIT wrote: What would be the best way to unblock the migration of gap and gap-io ? If gap isn't going to change (which might be the easiest solution), then file bugs and fix those reverse dependencies. Those bugs are RC and in due time will cause autor

Re: Status of the t64 transition

Hi, On 27-04-2024 7:52 p.m., Andrey Rakhmatullin wrote: Can you please look at libproxy<->glib-networking? libproxy excuses show glib-networking tests failing, but they are working in sid. And that's not missing a versioned Depends and/or Breaks? I.e. this is a test only failure? Paul Ope

Re: Status of the t64 transition

Hi, On 24-04-2024 7:42 p.m., Jérémy Lal wrote: Inform the Release Team and we can either schedule the combination manually, add a hint or both. Isn't it processed automatically ? What needs manual intervention and what doesn't ? Well, the migration software *tries* to figure out com

Re: Status of the t64 transition

Hi, On 24-04-2024 7:38 p.m., Paul Gevers wrote: On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on Inform the

Re: Status of the t64 transition

Hi, On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on Inform the Release Team and we can either schedule the combi

Re: Debian testing/unstable users: beware of Firefox critical CVEs

Hi Samuel, On 24-03-2024 11:45 p.m., Samuel Henrique wrote: In a recent case, the issue was addressed by performing a testing-proposed-update of the package. This would allow firefox-esr to be fixed on testing before the transition is over, but it would not work for those installing the firefox

Re: Package marked for autoremoval due to closed bug? [and 1 more messages]

Hi, On 19-03-2024 11:32 a.m., Ian Jackson wrote: Paul Gevers writes ("Re: Package marked for autoremoval due to closed bug?"): For bookkeeping purposes, please usertag downgraded bugs with user release.debian@packages.debian.org and usertag time_t-downgrade. I was informed t

Re: Package marked for autoremoval due to closed bug?

Hi zigo, On 16-03-2024 12:31 a.m., Thomas Goirand wrote: But when the AUTORM period was announced as reduced, I thought like it was probably a bad call, and that the previous AUTORM was aggressive enough. I'm not aware that we reduced autoremoval times in recent history. Are you maybe confus

Re: Package marked for autoremoval due to closed bug?

Hi, Disclaimer: exception only valid while the time_t transition is ongoing. On 15-03-2024 6:15 a.m., Steve Langasek wrote: Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library

Re: Any way to install packages+run autopkgtests on porterbox machines?

Hi, On 01-03-2024 1:58 p.m., Nilesh Patra wrote: Have you found any way around these? https://salsa.debian.org/mbanck/dd-autopkgtest/ Alternative, probably not the best solution, but until better ones are found (and as long it's not too much used): Antonio and I offer DD's access to testbed

Re: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

Hi, On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote: @d-d: - How can it happen that purge *t64 packages and at the same time install the previous package, and then the so file is missing? I mean it's clear that they use the same name, but shouldn't DPKG handle the cleanly? Wel

Re: Policy: versioning between releases

Hi, On 21-01-2024 16:08, Matthias Urlichs wrote: However according to our release notes we only support upgrading from release x to x+1, skipping releases is not allowed. I'm not talking about skipping releases but about partial upgrades. Thus … > foo/testing requires bar >=1.1 to work but

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

Hi, On 20-01-2024 23:22, Steve Langasek wrote: So I think an algorithm for deciding the uploads to experimental looks like this: - download source from unstable. - apply the packagename conversion to the source. - grab the debdiff. - submit the NMU diff to the BTS. - download the source again f

Re: Wolfram Research Debian Package Submission

Hi, On 12-01-2024 16:42, Blake Gilbert wrote: I am reaching out to you regarding a recent package submission by our Engine Connectivity Engineering team. We submitted the package CDImage M-LINUX-WolframEngine.DEB a few months ago to include Wolfram Engine in Debian packages, and I wanted to se

Re: Drawbacks of lack of mandated packaging workflow (Was: Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline)

Oops, should have waited sending... On 06-01-2024 14:30, Paul Gevers wrote: On 06-01-2024 14:15, Gioele Barabucci wrote: Aren't all these problems just inherent in Debian's lack of a mandated packaging tooling and workflow [1,2]? Might be, but that doesn't mean that problem

Re: Drawbacks of lack of mandated packaging workflow (Was: Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline)

Hi Gioele, On 06-01-2024 14:15, Gioele Barabucci wrote: Aren't all these problems just inherent in Debian's lack of a mandated packaging tooling and workflow [1,2]? Might be, but that doesn't mean that problem goes away. Paul OpenPGP_signature.asc Description: OpenPGP digital signature

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

Hi Steve, On 05-01-2024 17:36, Rene Engelhard wrote: Also a problem is that experimental also might already contain totally unrelated updates like new upstream versions... I share this worry. Have you thought about how to handle the cases where you don't have experimental to upload to? How bi

Re: Bits from the Release Team: Cambridge sprint update

Hi On 18-12-2023 11:29, Santiago Vila wrote: El 17/12/23 a las 22:40, Steven Robbins escribió: Does that mean ceasing the "ITP" messages in debian-devel? I'd certainly welcome that! I think he really meant debian-release, as this was "Bits from the Release Team" and he was talking about "Rele

Re: Bits from the Release Team: Cambridge sprint update

Hi, On 18-12-2023 13:18, Antonio Terceiro wrote: Will reproducibility regressions block migration to testing? Not for the near future for 2 reasons: 1) contrary to autopkgtest where removal of the test "fixes" regression, it feels that currently blocking on regression would give maintainers

Re: Migration blocked

Hi, On 05-12-2023 03:52, Yadd wrote: I uploaded src:node-proxy-agents into unstable, which is the new source of node-proxy and node-https-proxy-agent. This package didn't migrate but I don't understand the reason of this block. The tracker[1] reports regressions on node-proxy and node-https-

Re: Misc Developer News (#59)

Hi, On 22-11-2023 12:21, Donald Norwood wrote: The new attempt is a fresh email to d-d-a via cut and paste from the original email with the 1 correction that was needed. The email for some reason seems to be in d-d-a and d-d limbo, so I think we await the next cron run. More likely you need

Re: Illegal Instruction Using sudo in Bookworm on i686

Hi, On 22-10-2023 23:32, r...@neoquasar.org wrote: If the distinction between "supported" and "not supported" is going to come down to specific assembler-level instructions, it would seem that that wont tell most people anything. Well, if we know which instructions we don't support, it's not

Re: Illegal Instruction Using sudo in Bookworm on i686

Hi, On 17-10-2023 22:16, Andrey Rakhmatullin wrote: Yes, assuming the pre-bookworm Debian i386 architecture fully supports it, as I don't know what *exactly* was allowed in the "almost i686" stretch-bullseye i386. According to the release notes (which *should* be authoritative, but may have b

Re: debvm for autopkgtests with multiple host?

Hi, On 24-09-2023 10:27, Johannes Schauer Marin Rodrigues wrote: Is the apt configuration on those systems set to something that is not the default and should be considered as well? How the unstable to testing migration runs work is that they have a testing testbed (with apt pinning making te

Re: armhf NEON exception for chromium

Hi Steve, On 15-09-2023 21:54, Steve Langasek wrote: armel != armhf Of course and nobody should be running armel on a NEON-capable CPU... Not sure why you say it like that, I guess you don't meen CI purposes here. But anyways, it seems that also the arm64 host that runs our armel and arm

Re: armhf NEON exception for chromium

Hi, On 15-09-2023 17:52, Andres Salomon wrote: Any thoughts on this? Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty on armel ci.debian.net workers. (I'm failing to spot neon in the list of features of that machine.) Paul [1] https://bugs.debian.org/cgi-bin/bugreport.c

Re: /usr-merge status update + next steps

Hi Helmut, On 19-08-2023 23:14, Helmut Grohne wrote: I recognize that this is quite a non-standard way to ask for a MBF. Does anyone object to me doing it in this way? I recall I said this before, but just in case. In my opinion (with my Release Team member hat on, but not on behalf of the t

Re: debci / salsa ci: support for qemu runner

Hi, On 25-07-2023 16:16, Michael Biebl wrote: apparently, we in Debian struggle to find good opportunities where to spend our money. For ci.d.n, the issue is not money, but the required work to integrate it into the infrastructure. We need volunteers (or pay people to do the work), but unles

Re: The future of mipsel port

Hi, On 23-07-2023 17:51, Mark Hymers wrote: On Tue, 18, Jul, 2023 at 12:45:51PM +0800, YunQiang Su spoke thus.. So I consider to suggest drop mipsel support from the list of official ports. (And let's keep mips64el port). Is there consensus on this point? If so, should we start making arrang

Re: How do you cause a re-run of autopkgtests?

Hi, On 21-07-2023 14:20, David Kalnischkies wrote: How is this to be done? Should some automated mechanism for achieving this be added, and if so, where? You already found the retry button from previous replies, but you don't have to click it to get what you want… The migration software of

Re: security autopkgtests ci

Hi, On 30-06-2023 22:40, Jérémy Lal wrote: Nice, but how can we see it when we prepare a package for security team ? You can't. Only the security team has access to the results. After the packages have been released the results will be published and can be seen in the history on ci.d.n, e.g.

Re: security autopkgtests ci

Hi, On 30-06-2023 20:14, Jérémy Lal wrote: is there something like a CI for security uploads ? Yes. Paul OpenPGP_signature Description: OpenPGP digital signature

Re: Help with a libzstd sparc64 FTBFS on the buildd

Hi Peter, On 06-04-2023 15:37, Peter Pentchev wrote: I feel like I cannot ask for an unblock from the release managers since the sparc64 buildd started failing on this package at some point in February: sparc64 is not a release architecture. sparc64 will not be better or worse if something mi

Re: Updating python3-xlrd for pandas 1.5 compatibility

Hi Diane, On 23-02-2023 08:12, Diane Trout wrote: the version of python3-xlrd 1.2.0-3 in unstable/testing is too old to be used with pandas 1.5.3. (See Bug #1031701). Do I understand correctly that this isn't an issue from the point of python3-xlrd and that only pandas is effected? While inve

Re: how to skip some archs for autopkgtests

Hi, On 03-02-2023 16:51, Nilesh Patra wrote: There is a "skip-not-installable" that you could decleare in d/t/control for these packages (for the corresponding tests that suffer from uninst test deps), more details here[1] Please don't use this. I regret I added it to autopkgtest because more

key packages RC bugs of the month February

Dear all, While I skipped one month, we're now in the mid of the first freeze, so here's another plea [1,2,3,4, 5] to fix RC bugs in key packages [6]. Currently we have 168 RC bugs in key packages affecting bookworm [7] of which 109 are unresolved in unstable or experimental, aren't pending an

Re: Should singularity-container make it to next release?

Hi Nilesh, On 26-01-2023 10:06, Nilesh Patra wrote: I guess something that changed since then is that upstream is aware about it and can help a bit with backporting. However the onus to maintain it in stable is still on the maintainer and security@ (to some extent) It is bit of a high-effort mai

Re: Should singularity-container make it to next release?

Hi, On 25-01-2023 20:14, Moritz Muehlenhoff wrote: On Sat, Jan 21, 2023 at 08:34:40PM +0100, Salvatore Bonaccorso wrote: So in my understanding of the above the situation around singularity-container, which lead for buster to https://bugs.debian.org/917867 and keeping it out of the stable relea

Re: security paperwork machine

Hi, On 23-01-2023 21:33, Alexandre Detiste wrote: A whole pre-existing private security tracker solution would be perfect; or a website where one could register all the package they care about. You mean something like [1] but then for a user instead of a team... I couldn't quickly find it, bu

Re: Remote service accounts protection in autopkgtest?

Hi Vasyl, On 22-01-2023 22:33, Vasyl Gello wrote: Assuming I would like to test the package interacting with some proprietary third-party service on the web (like Kodi PVR addon), is there any mechanism protecting of account details so that autopkgtest machines can read them while outside world

Re: Multi-host networking software, autopkgtests

Hi Ian On 06-01-2023 14:09, Ian Jackson wrote: I have two packages which do vpn-like things (hippotat, secnet) which I want to add autopkgtests for. The two packages have similar kinds of requirements for their tests. Ideally, I would: * Somehow have two test nodes ("hosts") * With their

Re: SONAME bumps (transitions) always via experimental

Hi, On 05-01-2023 14:13, Simon McVittie wrote: since passing NEW currently requires a source+binary upload but migrating to testing requires a follow-up source-only upload (same total number of uploads). To be fair, normal SONAME bump NEW uploads only need a arch:!all binary uploa

SONAME bumps (transitions) always via experimental

Dear all, The Release Team just asked ftp-master to hold of accepting SONAME bumps targeting unstable to ease the last days before the Transition and Toolchain Freeze. The Release Team would like to ask the ftp-masters to also by default reject SONAME bump NEW uploads to unstable during the w

Re: Help setting dbconfig-common for MariaDB, not MySQL

Hi Marc, On 02-01-2023 16:58, Marc Haber wrote: On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers wrote: On 02-01-2023 14:21, Alessandro Vesely wrote: A user complained that MySQL doesn't work, because it misses the INET6 type that the example settings use. And is this an absolute must?

Re: Help setting dbconfig-common for MariaDB, not MySQL

Hi Alessandro, On 02-01-2023 14:21, Alessandro Vesely wrote: please pardon my ignorance about Debian install.  I'm distributing a software which could use various DBMS'es by setting a number of parameters.  Example parameters are only given for MariaDB.  I distribute a debian/ directory that D

key packages RC bugs of the month December

Dear all, With only 1 month to go until the first freeze, another plea [1,2,3,4] to fix RC bugs in key packages [5]. Currently we have 234 RC bugs in key packages affecting bookworm [6] of which 160 are unresolved in unstable or experimental, aren't pending and don't have a patch. Here are aga

key packages RC bugs of the month November

Dear all, With about 2 months to go until the first freeze, a fresh plea [1,2,3] to fix RC bugs in key packages [4]. Currently we have 255 RC bugs in key packages affecting bookworm [5] of which 184 are unresolved in unstable or experimental, aren't pending and don't have a patch. Here are aga

artwork for bookworm?

Dear all, Today I started the Release Team Checklist [1] and noticed: [ ] Theme (artwork) design should be finalised and decided I just found two small threads on debian-desktop [2, 3], but I'm not aware of any further activity on the artwork front. Do we have volunteers to push for the bookwo

Re: bits from the release team: are you ready to skate yet?

Hi, On 13-10-2022 17:32, Johannes Schauer Marin Rodrigues wrote: hrm... maybe I misunderstand but I thought your initial mail talked about build profiles (aka DEB_BUILD_PROFILES) and not build options (aka DEB_BUILD_OPTIONS). The policy section you cite is about DEB_BUILD_OPTIONS and not about D

Re: bits from the release team: are you ready to skate yet?

Hi josch, On 13-10-2022 14:20, Johannes Schauer Marin Rodrigues wrote: Quoting Paul Gevers (2022-10-13 10:00:42) Please also consider supporting the nodoc build profile. We are aware that nodoc is regularly used in a non-reproducible way (as intended, but with this consequence), so checking

key packages RC bugs of the month October

Dear all, A new month, a fresh plea [1,2] to fix RC bugs in key packages. So, here are again 5 RC bugs in key packages in the hope to draw some attention to this class of bugs. Remember, fixing these bugs is a collective effort. #913916 grub-efi-amd64 UEFI boot option removed after update to

Re: Fixing CI bugs for a package on the REJECT list

Hi Jeff, On 26-09-2022 12:53, Jeff wrote: Short of closing #1012250, how do I get CI pipeline to pick up gscan2pdf again to debug the flaky tests? I'd appreciate any pointers. The bug has a user specified for the usertag and explicitly mentions: """ Don't hesitate to reach out if you need he

Re: packages expected to fail on some archs

Hi Samuel, On 11-09-2022 17:08, Samuel Thibault wrote: We could for instance: - Add an Architecture-FTBFS field to debian/control - Add an environment variable to debian/rules so that on these archs dh fails with a different exit code that buildds would notice. - Add a Architecture-FTBFS fiel

Re: Half the world being removed

Hi On 03-09-2022 19:48, Patrice Duroux wrote: Am I observing a side effect (kind of back-in-time) regarding a repair process on this issue? No. Because, for instance, the following page: https://tracker.debian.org/pkg/fwanalog has now its 'news' section showing: [2017-09-05] fwanalog 0.6.

Re: Half the world being removed

Hi, On 02-09-2022 13:00, Ian Jackson wrote: I wonder if it would be possible to detect a sudden large increase in the number of autoremovals, and stop the autoremoval system instead of causing blaring klaxons for everyone in the project ? I disabled the cron job that sends out mail yesterday,

Re: Half the world being removed

Hi On 02-09-2022 07:27, Andrey Rahmatullin wrote: On Thu, Sep 01, 2022 at 11:04:38PM -0500, Steven Robbins wrote: Suddenly half the packages are marked AUTOREMOVE; many due to gcc-12 and zlib. The related two bugs are months-old. Why are things suddenly being removed?? Both are key packages p

Re: key packages RC bugs of the month September

Hi all, On 01-09-2022 21:10, Rene Engelhard wrote: This either should be ignored (like for bullseye) or downgrade, imho, but I didn't do it myself. I don't think there's anything actionable here... On 01-09-2022 16:52, Simon McVittie wrote: >> #919914gnome-settings-daemon >> gnome-twe

key packages RC bugs of the month September

Dear all, In the same theme as my earlier message [0], I like to ask you to please spend some time triaging (and ideally solving) old RC bugs. Some packages you may care about were removed from testing because the maintainer didn't triage or fix the bug. And then there's key packages... As a

Re: Need a buildd build after trip through NEW -- best practice?

Hi all On 25-08-2022 02:43, Paul Wise wrote: I don't think Build-Architecture header is done yet? Neither do I. Although since we build all arch:all packages on amd64 machines now I don't think this is needed for throwing away NEW binaries? In testing and on release architectures, I'm only

Re: Need a buildd build after trip through NEW -- best practice?

Hi, On 24-08-2022 02:05, Paul Wise wrote: The release team automatically do binNMUs for packages that need a rebuild to transition to testing and are able to be binNMUed Maybe my fellow Release Team members have automated this locally, but I'm not aware of shared tools (or even cron jobs) tha

  1   2   3   4   >