Re: Proposed MBF - removal of pcre3 by Bookworm
On 01/07/2023 14:44, Michael Stone wrote: On Thu, Jun 29, 2023 at 08:55:11PM +0100, Matthew Vernon wrote: Bookworm is now out; I will shortly be increasing the severity of the outstanding bugs to RC, with the intention being to remove src:pcre3 from Debian before the trixie release. You don't think that marking packages for removal two weeks after the bug is filed is a little much? There's significant work creating and testing patches for this transition. Marking removal is too much. -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1040143: ITP: fonts-sahel -- Sahel Persian/Arabic truetype font family
Package: wnpp Severity: wishlist Owner: Danial Behzadi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fonts-sahel Version : 4.3.0 Upstream Contact: Saber Rastikerdar * URL : https://rastikerdar.github.io/sahel-font/ * License : OFL-1.1 Programming Lang: Description : Sahel Persian/Arabic truetype font family Sahel is a free and open source font, designed by Saber Rastikerdar and many other people for persian and arabic language.
Bug#1040152: ITP: golang-cloudfoundry-clock -- time provider & rich fake for Go
Package: wnpp Severity: wishlist Owner: Félix Sipma * Package name: golang-cloudfoundry-clock Version : 1.1.0-1 Upstream Author : Cloud Foundry * URL : https://github.com/cloudfoundry/clock * License : Apache-2.0 Programming Lang: Go Description : time provider & rich fake for Go Provides a Clock interface, useful for injecting time dependencies in tests. Newer restic depends on a newer golang-github-azure-azure-sdk-for-go, which depends on this package. -- Félix signature.asc Description: PGP signature
Bug#1040156: ITP: golang-github-microsoft-applicationinsights-go -- Microsoft Application Insights SDK for Go
Package: wnpp Severity: wishlist Owner: Félix Sipma * Package name: golang-github-microsoft-applicationinsights-go Version : 0.4.4-1 Upstream Author : Microsoft * URL : https://github.com/microsoft/ApplicationInsights-Go * License : Expat Programming Lang: Go Description : Microsoft Application Insights SDK for Go This project provides a Go SDK for Application Insights. Application Insights (http://azure.microsoft.com/en-us/services/application-insights/) is a service that allows developers to keep their applications available, performant, and successful. This go package will allow you to send telemetry of various kinds (event, metric, trace) to the Application Insights service where they can be visualized in the Azure Portal. Newer restic depends on a newer golang-github-azure-azure-sdk-for-go, which depends on this package. -- Félix signature.asc Description: PGP signature
Bug#1040157: ITP: golang-github-azuread-microsoft-authentication-library-for-go -- Microsoft Authentication Library (MSAL) for Go
Package: wnpp Severity: wishlist Owner: Félix Sipma * Package name: golang-github-azuread-microsoft-authentication-library-for-go Version : 0.6.0-1 Upstream Author : Microsoft * URL : https://github.com/AzureAD/microsoft-authentication-library-for-go * License : Expat Programming Lang: Go Description : Microsoft Authentication Library (MSAL) library for Go The Microsoft Authentication Library (MSAL) for Go is part of the Microsoft identity platform for developers (https://aka.ms/aaddevv2) (formerly named Azure AD) v2.0. It allows you to sign in users or apps with Microsoft identities (Azure AD (https://azure.microsoft.com/services/active-directory/) and Microsoft Accounts (https://account.microsoft.com)) and obtain tokens to call Microsoft APIs such as Microsoft Graph (https://graph.microsoft.io/) or your own APIs registered with the Microsoft identity platform. It is built using industry standard OAuth2 and OpenID Connect protocols. Newer restic depends on a newer golang-github-azure-azure-sdk-for-go, which depends on this package. -- Félix signature.asc Description: PGP signature
Re: Bug#1040157: Acknowledgement (ITP: golang-github-azuread-microsoft-authentication-library-for-go -- Microsoft Authentication Library (MSAL) for Go)
Woops, I just realized this is already in the new queue. (ITP - #1039471) Sorry for the noise. On 2023-07-02 15:57+, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1040157: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040157. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to debian-devel@lists.debian.org, debian...@lists.debian.org (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): w...@debian.org If you wish to submit further information on this problem, please send it to 1040...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- Félix signature.asc Description: PGP signature
Re: Proposed MBF - removal of pcre3 by Bookworm
On Sun, Jul 02, 2023 at 10:14:58AM +0100, Alastair McKinstry wrote: > > On 01/07/2023 14:44, Michael Stone wrote: > > On Thu, Jun 29, 2023 at 08:55:11PM +0100, Matthew Vernon wrote: > > > Bookworm is now out; I will shortly be increasing the severity of > > > the outstanding bugs to RC, with the intention being to remove > > > src:pcre3 from Debian before the trixie release. > > > > You don't think that marking packages for removal two weeks after the > > bug is filed is a little much? > > There's significant work creating and testing patches for this transition. > Marking removal is too much. On the other hand, the bugs have been open for an year and a half now... G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1040176: ITP: cppdap -- C++11 implementation of the Debug Adapter Protocol
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: cppdap Version : 1.58.0a Upstream Author : Google LLC * URL : https://github.com/google/cppdap * License : Apache-2.0 Programming Lang: C++ Description : C++11 implementation of the Debug Adapter Protocol cppdap is a C++11 library to implement a Debug Adapter Protocol (DAP) client or server. It provides C++ type-safe structures for the full DAP specification, and provides a simple way to add custom protocol messages. cppdap is a new dependency of CMake 3.27+ The package will be maintained by Timo Röhling at https://salsa.debian.org/debian/cppdap -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSh1o8ACgkQ+C8H+466 LVnkyAv+Pll6YrJ7fHA25vJfWdXPY4DmjX8G2EXxoi2o+ZYlDJbEVwG+ShL8+d7u 2r7r6aC13UmiSVxpTTFVdW4BCKX0ZTib4VtlNB02DJF1J1pBaS5iDBjtZv7YKRsB 65sZhCbl4FxR0F3+7AqcEgYlRAQnCAfKqcVilBOKgpI6ABfab46VHn3djOkvES2w qJDqk/awqGc1ziYZfMmXTwrpry+ZekXVps+19O8LNMbdirkdWpTKs81JVMlq5ak+ k6jDrQEBJ6GyZ672biM9ejFVIdH6fv/5WpElKDqbv52xTDxgV7LjeAK7KTE4Ra3u wJOrZrgYVfkq3dRc/CisGSmcA6Xotuy0NG8FyFsXInfm217tdj1xIBzsmzjlrNNT hx00YqFxINiSE3Mo3bgg3jqCDsBkJhx4L3qKL5TkPk8QwA6ayyXNCjpBdPYFyy5f AcSVpsm0peN7znMFsE0ADdjfV/lQ8VvdJ1Ko33m62/kNi/eyfag6MLPl9OjMl7F+ EbLLc+Os =BlS+ -END PGP SIGNATURE-
Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Simon, On Fri, Jun 30, 2023 at 08:06:15PM +0900, Simon Richter wrote: > I think "backports" are missing as a user story. I fully agree. What a serious omission. As a first step, I have updated DEP17 to indicate which mitigations happen to work when being backported. For instance, changing Replaces to Conflicts is something that happens to just work for backports. Diverting dpkg-divert less so. So in effect, the most likely outcome is that backports become very fragile, because they essentially have to undo all the moves performed in unstable. What we can do with relative ease is detect the problems after they have been introduced. I note that the quality of backports already leaves wishes. For instance, kodi-addons-dev takes over /usr/bin/dh_kodiaddon_depends in bullseye-backports from kodi-addons-dev-common in bullseye without conflicts nor replaces. Likewise, nfs-ganesha-ceph takes over /usr/lib/ganesha/libganesha_rados_*.so in bullseye-backports from nfs-ganesha in bullseye. Is making backports more fragile a reasonable trade-off for moving forward? > Most packages should be harmless, and the Contents file for > bullseye-backports doesn't have too much in any of the affected directories. Yeah, the number of affected cases should be relatively low, but when things go wrong, it's bad. Is that ok if we can automatically detect it (after it happened)? > but the list of packages installing files into /lib is longer and includes > all the kernel backports, so I guess that is another potential source of > problems. Without having looked, I'd expect the majority of practically affected files below /lib to be systemd units and udev rules. These should not be moved in backports, and as long as debhelper is being used, that might just work. > There might be an easy solution here, I have not investigated this very > deeply because it is a workday and 11 hours out of every day are already > spoken for. I don't think there is an easy solution, but maybe it happens to work by chance 90% (number made up) of the time and we shall be able to detect the remaining 10%. > > Stating a goal has been quite difficult, but I think that most of the > > participants agree that we want to eliminate the file move moratorium > > without getting problems in return. > > I'd even widen that to "no more special handling needed in any place for the > transition", with the moratorium being an example of that. What other kind of special handling do you have in mind? I probably agree. > > When we get into mitigations, consensus is hard to come by. My > > impression is that we have roughly two camps. One is in favour of major > > changes to dpkg and the other is not. > > It's difficult to summarize the situation in one sentence, because neither > group is really objecting to dpkg changes, so I'd put the fault line at > whether the transition should be facilitated through dpkg or not. It's not clear to me, whether you'd consider M3 (a minor and revertable mitigation in dpkg) to be covered by this or not. > > * Even if dpkg were fixed in trixie, trixie's libc6 would still be > > unpacked using bookworm's dpkg. At least for this package, we cannot > > rely on dpkg changes in trixie. Therefore we need workarounds or > > spread the transition to forky. For other packages, even a > > Pre-Depends on dpkg is not a guarantee that a changed dpkg will > > perform the unpack. > > * Changes to dpkg will not fix bootstrapping. > > The dpkg changes will fix bootstrapping, but we can't finish the transition > until forky this way, because we need to be able to bootstrap with a libc6 > package that can be installed from bookworm. Can you elaborate why? As far as I can see, debootstrap may perform the initial unpack without help from dpkg. Then we invoke the unpakced dpkg to configure essential packages. If dpkg plays any role in setting the aliasing symbolic links, their creation will be late for running dpkg. Maybe I'm missing something? > We need to be careful here to not conflate the goal of the transition with > the method for reaching it. We have consensus on the goal (basically, > data.tar and filesystem matching is the definition of "done" I use for this > transition). I agree that we need to be careful about that conflation, because I think you are conflating them. I disagree that the goal is having data.tar and filesystem match up. You earlier argued that we are done when special handling is no longer necessary and I see that as the goal. Having all the files moved is one method to get there. We also seem to have rough consensus that this is the preferre method. > We do not have consensus on the technical implementation because there are > people who believe the technical implementation proposed is not actually > feasible. In my opinion, it is a 95% solution, which is very tempting but we > need the remaining 5% as well. To a large extent, we are having this > discussion because the usrmerge package l
Re: Proposed MBF - removal of pcre3 by Bookworm
On Jul 02, Peter Pentchev wrote: > On the other hand, the bugs have been open for an year and a half now... For something which has worked just fine for many years. -- ciao, Marco signature.asc Description: PGP signature
