Re: Any volunteers for lintian co-maintenance?

On Sun, May 19, 2024 at 12:49:29PM +0200, Andreas Tille wrote: > > It also fails as an archive QA tool in my view since the FTP masters have > > been unwilling to upgrade to any recent version of lintian. > > Perhaps a ftpmaster could explain this in detail. As far as I understand, > it's also a

Re: Re: Suggestions about i386 support

On Sun, May 19, 2024 at 09:09:10AM +, defrag mentation wrote: > > What will this solve? > > > I don't think this is "needed"? Unless you think all i386 packages will be > > removed from Debian, which is not the plan? > > Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the

Re: Suggestions about i386 support

On Sun, May 19, 2024 at 07:26:28AM +, defrag mentation wrote: > I think some of the i386 support policies needs to be reconsidered. > > Here are some suggestions: > > 1. ​Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t. What will this solve? > Wine-32 is now in currently

Re: Any volunteers for lintian co-maintenance?

My 1.83 RUB: lintian is one of those things that are very important and useful when you know how to use them, which quirks to apply and which parts to ignore, and without that knowledge are maybe useful, maybe useless, maybe harmful, and nobody will tell you that knowledge unless you ask

Re: 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]

On Tue, May 07, 2024 at 09:49:17PM +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Andrey Rakhmatullin (2024-05-06 19:14:40) > > On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote: > > > > tmpfiles.d snippets can be defined to cleanup

Re: how to upgrade testing

On Tue, May 07, 2024 at 08:54:39PM +0200, Jérémy Lal wrote: > could we have a hint when it's "safe" to upgrade testing ? It was always safe... > Currently I get for a full-upgrade: > 2338 mis à jour, 362 nouvellement installés, 715 à enlever et 41 non mis à > jour. alias e='LC_ALL=C' e apt

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]

On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote: > On the other hand, if we need to change the configuration 99% of the time, [citation needed] -- WBR, wRAR signature.asc Description: PGP signature

Re: 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]

On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote: > > tmpfiles.d snippets can be defined to cleanup on a timer _anything_, > > It's a question of what the *default* behaviour should be. > > For whatever reason, a lot of people who process large data use > /var/tmp/FOO/ as a

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]

On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery wrote: > >> I'm not sure if we have software on long running servers which place > >> files in /tmp and /var/tmp and expect files to not be deleted during > >> runtime, even if not accessed for a long time. This is certainly an > >> issue to

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]

On Mon, May 06, 2024 at 10:40:00AM +0200, Michael Biebl wrote: > I'm not sure if we have software on long running servers which place files > in /tmp and /var/tmp and expect files to not be deleted during runtime, even > if not accessed for a long time. This is certainly an issue to be aware of >

Re: Status of the t64 transition

On Sun, Apr 28, 2024 at 02:28:30PM +0200, Paul Gevers 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

Re: Status of the t64 transition

On Wed, Apr 24, 2024 at 07:38:42PM +0200, Paul Gevers wrote: > 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 autop

Re: Status of the t64 transition

On Wed, Apr 24, 2024 at 08:51:48AM +0200, Sebastian Ramacher wrote: > If you wonder how you are able to help with the migration, here are > some things to do: > * Fix FTBFS bugs > * Check the status of autopkgtests [1] and report or fix any issues > related to failing tests. > * Check if

Re: Status of the t64 transition

Lists updated to omit packages not in testing: On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote: > Let's start with the first category. Those are packages that could be > binNMUed, but there are issues that make those rebuilds not have the > desired effect. This list include

Re: Status of the t64 transition

All missing bugs about wrong deps are now filed. -- WBR, wRAR signature.asc Description: PGP signature

Re: Status of the t64 transition

On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote: > Let's start with the first category. Those are packages that could be > binNMUed, but there are issues that make those rebuilds not have the > desired effect. This list include packages that > * are BD-Uninstallabe, > * FTBFS

Re: finally end single-person maintainership

On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote: > > For example, any repository that does not list debian/files and > > debian/*.substvars in the gitignore will fail to build twice in a row, > > because these files are created and are subsequently untracked. > > Sorry, no. We

Re: finally end single-person maintainership

On Tue, Apr 09, 2024 at 07:43:04PM +0200, Johannes Schauer Marin Rodrigues wrote: > > And I do just prefer having two directories rather than multiple > > version on top of each other. My simple brain finds it a lot easier to > > keep track of a version directory to diff between, rather than

Re: finally end single-person maintainership

On Tue, Apr 09, 2024 at 05:52:43PM +0100, Wookey wrote: > Right - this was (one of the) main thing(s) that annoyed me enough to > just go back to the non-git based workflow. I want to make changes and > try them. I don't want to have to commit every damn time - it's not > done yet - I'll commit it

Re: finally end single-person maintainership

On Mon, Apr 08, 2024 at 09:44:55PM +0900, Simon Richter wrote: > > I don't mind what other people do, but I worry that conversations like > > this seem to take the new thing as so self-evidently better that > > no-one can reasonably complain about them being made a > > requirement. Well, we don't

Re: xz backdoor

On Tue, Apr 02, 2024 at 11:49:50AM +0200, Francesco P. Lovergine wrote: > Speaking about that, I'm a simple guy: how can anyone trust > sources signed by an unsigned-gnupg-key committer (I mean both the > actors of this tragically ridicolous drama)? In 2024. Really? As opposed to sources not

Re: Firmwares (was Re: Bits from the DPL)

On Mon, Apr 01, 2024 at 06:27:29PM +0200, Vincent Bernat wrote: > On 2024-04-01 18:05, Jonathan Carter wrote: > > The included firmware contributed to Debian 12 being a huge success, > > but it wasn't the only factor. > > Unfortunately, the shipped firmwares are now almost a year old, including >

Re: Command /usr/bin/mv wrong message in German

ntents Have you tried either of two examples you quoted? > Le 01/04/2024 à 09:58, Andrey Rakhmatullin a écrit : > > On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote: > > > On 1/4/24 10:18, gregor herrmann wrote: > > > > % dpkg -S $(which mv > coreutils: /

Re: Validating tarballs against git repositories

On Mon, Apr 01, 2024 at 04:10:55PM +0200, Alexandre Detiste wrote: > Le lun. 1 avr. 2024 à 15:49, Colin Watson a écrit : > > > > The practice of running "autoreconf -fi" or similar via dh-autoreconf > > has worked extremely well at scale in Debian. I'm sure there are > > complex edge cases where

Re: Command /usr/bin/mv wrong message in German

On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote: > On 1/4/24 10:18, gregor herrmann wrote: > > % dpkg -S $(which mv > coreutils: /usr/bin/mv > > On bookworm: > > $ dpkg -S $(which mv) > dpkg-query: no path found matching pattern /usr/bin/mv > > This is caused by the /bin

Re: xz backdoor

On Sun, Mar 31, 2024 at 12:28:35PM -0400, Roberto C. Sánchez wrote: > On Sun, Mar 31, 2024 at 09:53:06AM -0300, Carlos Henrique Lima Melara wrote: > > Hi, > > > > On Sun, Mar 31, 2024 at 02:31:37PM +0200, Pierre-Elliott Bécue wrote: > > > > > I would also be happy if it helps my fellow DDs to

Re: xz backdoor

On Sun, Mar 31, 2024 at 12:13:30PM +0200, Alexandre Detiste wrote: > Le dim. 31 mars 2024 à 10:17, Sirius a écrit : > > Reduction of complexity is IMHO always worthwhile as it would open the > > door for more people being able to step up as maintainers (taking into > > account that volunteers

Re: Some t64 libraries already in testing; I'm confused

On Sun, Mar 31, 2024 at 11:22:05AM +0200, Andreas Metzler wrote: > hdf5 1.10.10+repack-3.3 This one has an unanswered question from the maintainer in the NMU report, and I feel like the reason for the missing line is the package having debian/control.in. -- WBR, wRAR signature.asc Description:

Re: xz backdoor

On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote: > > I agree that dogfooding is important for discovering quality issues, but > > I think it's a poor argument for discovering security issues, especially > > if it concerns a host which is used for building and signing

Re: Some t64 libraries already in testing; I'm confused

On Sat, Mar 30, 2024 at 10:41:55PM +, Julian Gilbey wrote: > My very limited understanding of this major transition was that the > t64 libraries are being held in unstable until (almost) everything is > ready, at which point there will be a coordinated migration into > testing. But I've now

Re: xz backdoor

On Sat, Mar 30, 2024 at 08:52:29PM +0100, Ansgar  wrote: > Hi, > > On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote: > > On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote: > > > > > I think that the real question is whether we should real

Re: Validating tarballs against git repositories

On Sat, Mar 30, 2024 at 10:56:40AM +0100, Iustin Pop wrote: > > Now it is time to take a step forward: > > > > 1. new upstream release; > > 2. the DD/DM merges the upstream release VCS into the Debian VCS; > > 3. the buildd is notified of the new release; > > 4. the buildd creates and uploads the

Re: xz backdoor

On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote: > On Mar 30, Jonathan Carter wrote: > > > Another big question for me is whether I should really still > > package/upload/etc from an unstable machine. It seems that it may be prudent > If we do not use unstable for development then

Re: xz backdoor

On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote: > Another big question for me is whether I should really still > package/upload/etc from an unstable machine. It seems that it may be prudent > to consider it best practice to work from stable machines where any private > keys are

Re: Validating tarballs against git repositories

On Sat, Mar 30, 2024 at 09:58:22AM +0100, Ingo Jürgensmann wrote: > > Yes. In that specific case, the original xz maintainer (Lasse Collin) > > was socially-pressed by a likely fake person (Jigar Kumar) to do the > > "right thing" and hand over maintenance. > >

Re: Re: time_t progress report

On Sat, Mar 23, 2024 at 04:50:48PM -0500, Steven Robbins wrote: > Wondering about the current state of this transition. It's still in the stage of re-bootstrapping armel and armhf. https://buildd.debian.org/stats/armel.png https://buildd.debian.org/stats/armhf.png

Re: lazarus is marked for autoremoval from testing

On Tue, Feb 13, 2024 at 08:06:55AM +0100, Abou Al Montacir wrote: > > It is affected by these RC bugs: > > 1061034: lcl-utils-3.0: lcl-utils-3.0 Missing dependencies for lazbuild > >  https://bugs.debian.org/1061034 > I really don't understand this message. > the bug was fixed and is marked as so

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

On Sun, Jan 07, 2024 at 02:23:32AM +0900, Simon Richter wrote: > > Aren't all these problems just inherent in Debian's lack of a mandated > > packaging tooling and workflow [1,2]? > > We have a mandated tooling and workflow. > > The tooling follows an interface that is defined in Policy. The

Re: DebGPT: how LLM can help debian development? demo available.

On Wed, Jan 03, 2024 at 11:33:06AM +0200, Andrius Merkys wrote: > On 2024-01-03 11:12, Andrey Rakhmatullin wrote: > > On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote: > > > To me the most time consuming task in Debian recently is the Python > > > transitio

Re: DebGPT: how LLM can help debian development? demo available.

On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote: > To me the most time consuming task in Debian recently is the Python > transitions. I wonder whether DebGPT could help with them. Maybe there are > other, non-Debian-specific GPTs for this task, but I would prefer a Debian > one. As

Re: [Pkg-pascal-devel] Issue with fpc_3.2.2+dfsg-24 in Sid.

On Sat, Dec 30, 2023 at 10:58:58AM +0100, Abou Al Montacir wrote: > > I see only two possibilities, either upload manually fpc_3.2.2+dfsg-25 for > > each missing architecture, or get fpc_3.2.2+dfsg-24 removed from archive and > > replaced by fpc_3.2.2+dfsg-23 so that fpc_3.2.2+dfsg-25 can be

Re: How to build debian transitional package without source code?

On Wed, Dec 27, 2023 at 04:36:01PM -0500, Kaiqi Z wrote: > Hello Debian Community, > > I need to define a transitional package like debian Renaming Packages Method > . > > Since it is transitional it should not contain any

Re: bring a newer version of a package into stable (nsis-3.09-1 into Debian "bookworm")

On Fri, Dec 22, 2023 at 01:55:59PM +0100, Thomas Gaugler wrote: > Hi, > > I thought a package in Debian "bookworm" could be updated via a "bookworm > proposed updates request" . > > It looks like I did not fully understand the process. Therefore I kindly ask >

Re: reference Debian package of multiple binaries sharing one man page

On Fri, Nov 10, 2023 at 11:44:06AM -0800, Russ Allbery wrote: > The good news is that if you're using debhelper, you don't have to care > about how man handles these indirections and can just use a symlink. > Install the man page into usr/share/man/man1 under whatever name is > canonical (possibly

Re: What would help the most?

On Mon, Oct 30, 2023 at 02:48:24PM -0500, Lukasz Szybalski wrote: > It's not an AI guy. > > This is a question of, as a debian developer @debian.org...what do you need > right now? What would help you? > > Example without giving direction..or inserting things... more cs grads > working bugs or

Re: What would help the most?

On Mon, Oct 30, 2023 at 07:03:38AM +0100, deb...@hyperborg.com wrote: > Hi, > > I have the feeling, that this is some kind of semi-AI generated chat. > I think we should stop it now. Makes sense.

Re: What would help the most?

On Fri, Oct 27, 2023 at 02:00:45PM -0500, Lukasz Szybalski wrote: > Hello > I wanted to understand better from people with y...@debian.org email address > on: > > Vision of Debian: > Create a free operating system, freely available for everyone. > > Goal: > Helping customers achieve outcome.

Re: Illegal Instruction Using sudo in Bookworm on i686

On Tue, Oct 17, 2023 at 02:38:40PM -0500, Justin wrote: > Okay, so because the VIA C3 Nehemaiah chip doesn't properly implement > ENDBR32, it falls outside of the supported hardware, despite being otherwise > an "i686 class chip," correct? Seems correct to me. > Or put another way, in classic

Re: Illegal Instruction Using sudo in Bookworm on i686

On Tue, Oct 17, 2023 at 10:57:41AM -0500, Justin wrote: > Any other information I can provide that would help track this down? Track what down, sorry? It seems to me you already understand the reason for this error? Or are you asking how to make sure that your CPU indeed doesn't support this?

Re: Control header sent with done email didn't do what I expected, should it have?

On Mon, Sep 25, 2023 at 01:55:22PM -0400, Jonathan Kamens wrote: > The documentation you inked to does not specify a tag that can be used > specifically to mark something as not actually a bug. Yes, we just close those. The Debian BTS is not as rich as e.g. a typical bugzilla installation in this

Re: Control header sent with done email didn't do what I expected, should it have?

On Mon, Sep 25, 2023 at 12:55:16PM -0400, Jonathan Kamens wrote: > All that aside, in this particular case I closed the bug because it wasn't > actually a bug, but rather a PEBKAC issue (user complaining that a program > wasn't respecting his locale when he had LC_ALL set to "C" so he was >

Re: Control header sent with done email didn't do what I expected, should it have?

On Mon, Sep 25, 2023 at 07:16:56AM -0400, Jonathan Kamens wrote: > I recently tried to close a bug, explain why, and set a "wontfix" tag all at > once by sending my explanation to ###-d...@bugs.debian.org with "Control: > tags ### wontfix" as the first line of my message body. The bug was closed >

Re: Control header sent with done email didn't do what I expected, should it have?

On Mon, Sep 25, 2023 at 10:04:17AM -0400, Jonathan Kamens wrote: > I did find this here after I emailed > the list: > >QUESTION: Can you do all the control-server actions by using fields >in a pseudo header in an email to bugnumber@b.d.o >

Re: Control header sent with done email didn't do what I expected, should it have?

On Mon, Sep 25, 2023 at 02:44:19PM +0100, Peter B wrote: > On 25/09/2023 14:25, Jonathan Kamens wrote: > > > > So putting a Control: line in the pseudo-header of a message sent to > > ###-d...@bugs.debian.org doesn't work at all? > > > > It should work if the syntax is correct. The + character

Re: Control header sent with done email didn't do what I expected, should it have?

On Mon, Sep 25, 2023 at 02:06:44PM +0100, Peter B wrote: > > I recently tried to close a bug, explain why, and set a "wontfix" tag > > all at once by sending my explanation to ###-d...@bugs.debian.org with > > "Control: tags ### wontfix" as the first line of my message body. The > > bug was closed

Re: Bug#1052421: ITP: control -- Python Control Systems Library

On Thu, Sep 21, 2023 at 08:37:53PM +, Kurva Prashanth wrote: > It seems debian python team following certain convention when naming > packages for python modules, libraries prefixed with "python-" and > python3 packages are prefixed with "pyhton3-". python3- prefixes for binary packages are

Re: Bug#1052421: ITP: control -- Python Control Systems Library

On Thu, Sep 21, 2023 at 08:20:20PM +0200, Christoph Biedl wrote: > > * Package name: control > > Version : 0.9.4 > > Upstream Author : > > > > * URL : http://python-control.org/ > > While I cannot judge whether this package is a sensible addition to > Debian - I

Re: Potential MBF: packages failing to build twice in a row

On Thu, Aug 10, 2023 at 02:22:30PM +0200, Lucas Nussbaum wrote: > > It might be worth to consider changing your workflow a bit and work with > > a git repository. It does not have to be a clone of the repository (if > > any) where the package is maintained, you can start with a fresh import, > >

Re: Potential MBF: packages failing to build twice in a row

On Sat, Aug 05, 2023 at 07:20:19PM +0300, Adrian Bunk wrote: > What packages are failing, and why? > > I would expect some debhelper machinery being responsible for most of > these, e.g. perhaps some dh-whatever helper might be creating this > issue for all 1k packages in some language

Re: Potential MBF: packages failing to build twice in a row

On Sat, Aug 05, 2023 at 08:10:35PM +0300, Adrian Bunk wrote: > Debian maintainers with proper git workflows are already exporting all > their changes from git to debian/patches/ as one file - currently the > preferred form of modification of a Debian package has to be in salsa > and not in our

Re: libgmp3c2 sources

On Mon, Jul 31, 2023 at 06:40:16AM -0400, Svetlana Karimova wrote: > Dear developers, > I work on a debian-like embedded system with quite an old kernel, so the > package libgmp3c2_2:4.3.2_armel.deb suited me perfectly. > The problem is that now I would really like to be able to build it from >

Re: rejection of binary package based on file timestamp

On Thu, Jul 20, 2023 at 10:01:54AM +0200, PICCA Frederic-Emmanuel wrote: > Hello, > > I am working on two packages pyfai[4] and python-fabio[3], I have got a > rejection based on the file timestamp which seems too old. > > the bug report is here [1] and [2]. > > If you lool at python-fabio

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote: > > From the discussions above, it seems that NetworkManager is relevant as > > well, > > though, and is being pulled in whenever a desktop task is installed (in > > addition to ifupdown or future systemd-networkd). > > What happens

Re: Debian 13 release schedule and Debian 15 codename announcement

On Wed, Jul 05, 2023 at 11:05:05PM +0200, Joaquín Rufo Gutierrez wrote: > No, Debian 13 will be released on 2024 occasionally. Who are you, sorry?

Re: systmd-analyze security as a release goal

On Mon, Jul 03, 2023 at 11:40:18PM +0200, Marco d'Itri wrote: > This is a good example of what an almost fully sandboxed service looks > like: > > https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.service Cool but looks like a lot of work. Is it possible to do this without

Re: Package name discord ITP: discord a modern voice & text chat app

On Mon, Jul 03, 2023 at 10:11:50AM +0200, Filippo Rusconi wrote: > I've never heard that Discord was Free Software. Of course it isn't.

Bug#1037017: ITP: python-seedir -- Package for creating, editing, and reading folder tree diagrams.

Package: wnpp Severity: wishlist Owner: Andrey Rakhmatullin X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-seedir Version : 0.4.2 Upstream Contact: Tom Earnest * URL : https://github.com/earnestt1234/seedir * License : MIT Programming

Re: [2016] client-side signature checking of Debian archives (Re: When should we https our mirrors?)

On Thu, Jun 01, 2023 at 07:07:04AM -0400, Michael Lazin wrote: > I realize it is work but it would be good if apt had an option for https. It does. > You can still update with FTP mirrors. Wouldn't it be a good idea to allow > using https and keep http as a fall back for those who need an http

Re: Dynamic linker support for FPC.

On Sun, May 28, 2023 at 06:53:51PM +0200, Abou Al Montacir wrote: > One year ago, glibc 2.32 2.32 was released in 2020 though? Unless you mean some Debian-specific changes, happened in 2021, in which case please be more specific? > introduced a change in the dynamic linker removing the functions

Re: AMD ryzen 5 2400G VGA drivers required for Debian 10 based linux OS

On Wed, Apr 26, 2023 at 07:11:00PM +0530, karans wrote: > Dear Debian Team > > We have Debian 10 buster based linux OS but we are facing issue after install > linux Please contact the support channels for your OS, not for Debian. > This e-mail is for the sole use of the intended recipient(s) and

Re: Problem with detection of hard disks on a hub

On Mon, Apr 10, 2023 at 08:18:59PM +0200, Ralf Lehmeier wrote: > > It will surely interest Debian developers -- but this is not the right > > list to ask. Please ask in one of the user support lists (where Debian > > developers will surely answer to your question). Your question is not > > about

Re: Problem with detection of hard disks on a hub

On Sat, Apr 08, 2023 at 02:46:10PM +0200, Ralf Lehmeier wrote: > Apparently there is no solution to this - or no one cares. > That is a great pity. > Does no one use a hub with multiple external hard drives and has problems > with them being recognized? The user support list is debain-user@

Re: a naive question about EOL encoding in Debian

On Sat, Mar 18, 2023 at 08:45:37PM +0100, Patrice Duroux wrote: > Hi, > > I am facing ^M (\r) character in the .build output file using sbuild > on my system (Sid). > For instance: > > $ file timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build > timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build:

Re: Bug#1031548: FTBFS with ruby-jekyll-github-metadata 2.15.0

On Sun, Feb 26, 2023 at 09:20:13PM +0100, Daniel Leidert wrote: > > > > Debian Policy §4.9 says that *attempting* to access the internet > > > > is forbidden: > > > > > > > >   For packages in the main archive, required targets must not > > > > attempt > > > >   network access, except, via the

Re: Reducing allowed Vcs for packaging?

On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote: > During the last weeks I had a look at the Vcs situation in Debian. Currently, > there are eight possible systems allowed I see a difference between (dis)allowing a VCS in the Vcs-* fields and (dis)allowing maintainers to store

Re: need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

On Sun, Feb 26, 2023 at 12:06:18AM -0600, G. Branden Robinson wrote: > Background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011666 > > Can someone advise me as to the correct procedure for merging upstream > release candidate archives into https://salsa.debian.org/debian/groff ? Just

Re: DEB_BUILD_OPTIONS=nowerror

On Fri, Feb 24, 2023 at 08:27:53AM +0100, Helmut Grohne wrote: > > Also I think it was recommended to *not* use -Werror by default as it > > is too fragile. Maybe one should have a "developer mode" flag instead > > that allows using -Werror? > > Well, if we were avoiding -Werror by default, we