Re: openssl 3.1.5-1.1 effect on reverse dependencies

On Wed, Mar 06, 2024 at 08:50:59PM +0100, Micha Lenk wrote: > >> You recently uploaded openssl 3.1.5-1.1. > >> > >> Are you tracking the effect it had on reverse dependencies? > >That's just a part of the time64 transition and it's definitely tracked by > >people. > > > Yet I wonder how I as a

Re: 64-bit time_t transition in progress in unstable

On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote: > > > Are there instructions on how to progress an unstable system through > > > this, or is the repo currently in a known inconsistent state? I have > > > tried upgrading various packages to work through deps but I am unable > > >

Re: 64-bit time_t transition in progress in unstable

On Wed, Mar 06, 2024 at 12:26:17PM -0700, Kevin Bowling wrote: > Are there instructions on how to progress an unstable system through > this, or is the repo currently in a known inconsistent state? I have > tried upgrading various packages to work through deps but I am unable > to do a

Re: openssl 3.1.5-1.1 effect on reverse dependencies

On Wed, Mar 06, 2024 at 07:47:57AM -0800, Otto Kekäläinen wrote: > Hi Benjamin! > > You recently uploaded openssl 3.1.5-1.1. > > Are you tracking the effect it had on reverse dependencies? That's just a part of the time64 transition and it's definitely tracked by people. -- WBR, wRAR

Re: hardinfo rebooted as hardinfo2 - community edition - RELEASE 2.0.12

On Sun, Mar 03, 2024 at 09:25:41PM +0100, hwspeedy wrote: > Hi Simon Quiqley, (CC: debian-devel) > > I'm trying to figure out how to get the hardinfo2 - release 2.0.12 into > debian repository. > hardinfo2 is a community fork of hardinfo and should continue as hardinfo > package, currently

Re: time_t transition and bugs

On Sat, Mar 02, 2024 at 06:34:43AM -0700, Antonio Russo wrote: > There's a similar issue with versioned dependencies by un-transitioned > packages have on non-t64 libraries (e.g., libqt5sql5). It's not similar, it's caused by some t64 libraries having wrong Provides. I've filed bugs about this on

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

On Fri, Mar 01, 2024 at 07:15:16PM +0530, Nilesh Patra wrote: > > You can use local sbuild chroots for foreign architectures, both for > > building and, I assume, running autopkgtests. > > I know but that is not something I want. This invaidates the whole point of > using > porter machines. I

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

On Fri, Mar 01, 2024 at 06:28:50PM +0530, Nilesh Patra wrote: > Hi, > > When I want to fix autopkgtests for a package on a particular architecture, I > currently > see no way to run autopkgtests before I dput since porter boxes do not > provide root > access which autopkgtest needs. > >

Re: On merging bin and sbin

On Wed, Feb 28, 2024 at 08:47:48AM -0600, r...@neoquasar.org wrote: > Are any of these (like arping) literally duplicates of the same binary for > some reason? Or are they true conflicts (different binaries with the same > name)? arping is definitely not a duplicate, iputils-arping and arping

Re: Migration bug ?

On Mon, Dec 12, 2022 at 07:28:27AM +0100, Yadd wrote: > Hi, > > I pushed 2 versions of node-rollup since December 09, but migration process > never started (at least looking at tracker.d.o). Is there something broken ? > > Cheers, > Yadd > > https://tracker.debian.org/pkg/node-rollup Note that

Re: my package uploads silently rejected

On Wed, Nov 30, 2022 at 03:03:14PM +0100, Jonas Smedegaard wrote: > I have tried ssh into the host ssh.upload.debian.org and (after fumbling > around) found the file /srv/upload.debian.org/queued/run/log where I see > only succesful notices about rust-criterion, no indication of rejection. The

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

On Sun, Sep 18, 2022 at 11:16:22AM +0200, Bjørn Mork wrote: > I find it quite disappointing to read https://bugs.debian.org/848622 . I > don't know if it is arrogance or ignorance, but this bug is undoubtedly > caused by usrmerge: > > frtest2:~# ls -l /usr/bin/bash > -rwxr-xr-x 1 root root

Re: Automatic trimming of changelogs in binary packages

On Sun, Sep 11, 2022 at 03:09:07PM +0300, Hakan Bayındır wrote: > Stuffing them behind a command, possibly making them online only in the > process will arguably make system troubleshooting and administration > harder, > esp. if the system has connectivity issues. > >

Re: Automatic trimming of changelogs in binary packages

On Sun, Sep 11, 2022 at 02:41:24PM +0300, Hakan Bayındır wrote: > > On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote: > >> While all looks good and feels sound from many aspects, I have some > >> reservations against treating changelogs as metadata. > >> > >> Current changelogs as

Re: Intel CET Support?

On Mon, Sep 05, 2022 at 10:44:52PM +0200, Felix Potthast wrote: > i just stumbled upon the fact that debian doesn't yet make use of the > Intel CET security feature, while many other distributions > (Ubuntu, Fedora, Suse, Arch Linux) do. > > The idea is to insert endbr instructions, > (which are

Re: Automatic trimming of changelogs in binary packages

On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote: > While all looks good and feels sound from many aspects, I have some > reservations against treating changelogs as metadata. > > Current changelogs as files have a well known place, can be used by anything > and everything, and they

Re: Half the world being removed

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 per

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

On Thu, Sep 01, 2022 at 08:45:06AM -0500, Steven Robbins wrote: > > > Specficially: in the case of a NEW binary upload, could a manual request > > > be > > > implemented (pick a different name if "give back" is not suitable) such > > > that it is thrown away and replaced by a buildd build? > > >

Re: Bug#1018759: ITP: sd - intuitive find and replace CLI

On Tue, Aug 30, 2022 at 06:44:36PM +0800, Blair Noctis wrote: > An RFP is at #1016929 [1]. > > 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016929 > You should have retitled and owned the RFP instead of creating a separate ITP.

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

On Sun, Aug 28, 2022 at 05:54:36PM -0500, Steven Robbins wrote: > I understand that the current state is that one can only "give back" a failed > build. I'm asking whether this must necessarily be the case. Yes, by definition. > Specficially: in the case of a NEW binary upload, could a manual

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

On Fri, Aug 26, 2022 at 04:13:43PM -0400, M. Zhou wrote: > If one's enthusiasm on working on some package is eventually > worn out after a break, then try to think of the following question: > > Is it really necessary to introduce XXX to Debian? > Must I do this to have fun? > > Strong

Re: Automatic trimming of changelogs in binary packages

On Fri, Aug 19, 2022 at 11:44:03AM +, Bastien Roucariès wrote: > Le jeudi 18 août 2022, 19:18:35 UTC Gioele Barabucci a écrit : > > Hello, > > > > in 2020 there was a brief discussion on debian-devel@ about trimming > > changelogs [1,2]. > > > > Now there is a working implementation of said

Re: Unsolicited GNU bc patch

On Sat, Aug 06, 2022 at 05:12:13AM +, Thomas DiModica wrote: > Yes, I keep spamming this trying to find an appropriate mailing list. I don't > remember how or why I initially stumbled across this bug report > (https://bugs.launchpad.net/ubuntu/+source/bc/+bug/1775776), but, given that > I have

Re: debhelper-compat should allow >= relations

On Sat, Jul 30, 2022 at 10:21:06PM -0700, Dima Kogan wrote: > > it's completely identical to putting 13 into debian/compat > > Oh. So it is. I vaguely remember that using debian/compat and > "Build-Depends: debhelper" generated some lintian complaints. Using debian/compat and "Build-Depends:

Re: debhelper-compat should allow >= relations

On Sat, Jul 30, 2022 at 11:15:30AM -0700, Dima Kogan wrote: > Hi. This probably has been covered before It wasn't, but it's completely identical to putting 13 into debian/compat, which never supported >= either. > This works fine if you're building for Debian/sid in 2022. It does not > work in

Re: how about telegram channel

On Wed, Jul 20, 2022 at 11:09:57AM +0200, Pierre-Elliott Bécue wrote: > I'd try to stay closer to FOSS decentralized solution like Mattermost or > Rocket Chat (not sure how and if it evolved to the point of being > usable). Shouldn't this have gone to -curiosa instead? -- WBR, wRAR

Re: how about telegram channel

On Wed, Jul 20, 2022 at 12:37:25PM +0200, Rand Pritelrohm wrote: > You can also keep a session open if you have a small SOC/board around > (screen tmux are her for that) without BNC/ZNC honeypot things. Seriously. > No need for those fancy, bloated, full of javascript modern things > blinking

Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

On Thu, Jul 14, 2022 at 08:45:24AM -0400, Roberto C. Sánchez wrote: > > > > And I see you uploaded ~immediately - why even bother with an ITP? > > > > > > Is it proper procedure to upload without an ITP? > > > > > > > No ; I have to admit a large percentage of the new packages I upload > > get

Re: is rust-failure a heisen-package?

On Thu, Jun 30, 2022 at 02:35:45PM +0200, Jonas Smedegaard wrote: > Hi, > > This looks odd to me: https://tracker.debian.org/pkg/rust-failure > > Latest news from 7 months ago was *removal* of the package, yet it is > seemingly still around.

Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

On Wed, Jun 29, 2022 at 01:43:25PM +, Lance Lin wrote: > Hello everyone, > > Thank you for your input and guidance. I've only been in Debian for a year so > > I still have many things to learn. I assumed there would be issues with > library > name conflicts and wanted to get the group's

Re: Lintian breaks existing lintian-overrides due to added []

On Wed, Jun 29, 2022 at 02:49:35PM +0200, Andreas Tille wrote: > Hi, > > I realised that lintian (at least) starting with version 2.115.1 (may be > earlier) wraps file names into [] which breaks existing > lintian-overrides. Random example: > > >

Re: Package uploads silently discarded: how to investigate?

On Mon, Jun 27, 2022 at 09:02:30AM +1000, Ben Finney wrote: > In this thread I want to discover: How can I find out what's happening > and why the Debian archive is no longer sending me any email messages > about my package uploads? You should check

Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

On Wed, Jun 22, 2022 at 02:21:43PM +, Lance Lin wrote: > > AFAIK this library is forked from OpenSSL with some extensive > > modifications to support new crypto technologies, do you think we need > > to involve the Security Team to review whether this package can be > > supported during the

Re: Python installation paths

On Thu, Jun 02, 2022 at 09:15:40PM +0200, Alec Leamas wrote: > > > I try handle a package which installs a partly compiled, > > > architecture-dependent python module. Until now this has been done in > > > /usr/lib/triplet/python3.10/site-packages. This scheme has basically > > > worked > > >

Re: Python installation paths

On Thu, Jun 02, 2022 at 07:19:56PM +0200, Alec Leamas wrote: > Dear list, > > I try handle a package which installs a partly compiled, > architecture-dependent python module. Until now this has been done in > /usr/lib/triplet/python3.10/site-packages. This scheme has basically worked > fine. >

Re: use of Recommends by vlc to force users to use pipewire

On Tue, May 31, 2022 at 11:43:06AM +0200, Vincent Lefevre wrote: > > > > > a) pipewire package enables pipewire service by default > > > > > > > > Indeed, but pipewire service doesn't take control of audio over > > > > pulseaudio. Only pipewire-pulse does that. > > > > > > This is incorrect.

Re: use of Recommends by vlc to force users to use pipewire

On Tue, May 31, 2022 at 10:55:55AM +0200, Vincent Lefevre wrote: > > > a) pipewire package enables pipewire service by default > > > > Indeed, but pipewire service doesn't take control of audio over > > pulseaudio. Only pipewire-pulse does that. > > This is incorrect. The pipewire-pulse package

Re: Firmware - what are we going to do about it?

On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote: > There are definitely people who use forks because it's easier to > install non-free firmware. What's the problem with that? Let them use > forks. A distro can't be all things to all people. This would mean almost officially dropping support

Re: Project Improvements

On Thu, May 26, 2022 at 06:47:19PM +0200, David Kalnischkies wrote: > > > > > I support many people with Debian, what I often see is that they > > > > > remove a > > > > > package, and then also the meta-package is removed. And later all > > > > > dependencies of the meta-package are removed by

Re: 1011146: nvidia-graphics-drivers-tesla-470 is a dependency of libb2

No, see https://bugs.debian.org/1011268 (already linked in the bug report you replied to). -- WBR, wRAR signature.asc Description: PGP signature

Re: cups-pdf is marked for autoremoval from testing

On Thu, May 26, 2022 at 02:33:20PM +0300, Martin-Éric Racine wrote: > Someone apparently made a commit to the autoremoval hinter that makes > it mark packages unrelated to an RC-bug package getting marked for > autoremoval. That's not what has happened. > Could someone please look into this? The

Re: maildir-utils is marked for autoremoval from testing

On Thu, May 26, 2022 at 04:54:25PM +0200, Hector Oron wrote: > > > maildir-utils 1.6.10-1 is marked for autoremoval from testing on > > 2022-06-30 > > > > > > It (build-)depends on packages with these RC bugs: > > > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, > > CVE-2022-28183,

Re: Project Improvements

On Thu, May 26, 2022 at 03:28:21PM +0500, Andrey Rahmatullin wrote: > > > I support many people with Debian, what I often see is that they remove a > > > package, and then also the meta-package is removed. And later all > > > dependencies of the meta-pack

Re: Project Improvements

On Wed, May 25, 2022 at 08:21:03PM +0200, David Kalnischkies wrote: > > I support many people with Debian, what I often see is that they remove a > > package, and then also the meta-package is removed. And later all > > dependencies of the meta-package are removed by accident. > > Not to rain on

Re: Concerns about Security of packages in Debain OS and the Operating system itself.

On Mon, May 23, 2022 at 07:22:40PM +0100, lkcl wrote: > > > i believe the answer is in the question. debian is based on distributed > > > trust. i did the analysis (took 3 weeks): it is literally the only > > > distro in the world with an inviolate chain of trust from a large keyring > > >

Re: Correct version and revision of upstream packaged Debian package

On Fri, May 20, 2022 at 10:52:08AM +0200, Jonas Smedegaard wrote: > > It only makes sense to use '+maria~deb11' if you are going to > > also release '+maria' that needs to sort after all of those, or if you are > > using/going to use some '+maria+foo' scheme(s) that, again, need to sort > > after

Re: Correct version and revision of upstream packaged Debian package

On Fri, May 20, 2022 at 10:22:55AM +0300, Tuukka Pasanen wrote: > After reading couple times Debian Policy documentation packaging conventions > and especially'5.6.12.2. Special version conventions' chapter. I'm bit > confused about revision system. As MariaDB Foundation wants to provide >

Re: rules-needs-root: yes (Was: popularity-contest: support for XB-Popcon-Reports: no)

On Thu, May 05, 2022 at 11:31:37AM +0200, Andreas Tille wrote: > > If there's a growing list of boolean control fields, isn't it the > > indication that some sort of tagging system might make more sense? > > > > Instead of three lines: > > > > XB-Popcon-Reports: no > > Rules-Requires-Root: yes >

Re: Firmware - what are we going to do about it?

On Tue, Apr 26, 2022 at 11:59:20AM +0300, Hakan Bayındır wrote: > > No, they do not. Most popular devices won't work at all without non- > > free firmware, including boring things such as mass storage (SD cards, > > SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...). > > Yeah,

Re: Firmware - what are we going to do about it?

On Mon, Apr 25, 2022 at 05:53:03PM +0200, Paul van der Vlis wrote: > > > > > I have an idea for an extra option: > > > > > > > > > > 6. Put the closed source firmware somewhere in the Debian images, but > > > > > never > > > > > install closed source firmware by default. "No" should be the

Re: Firmware - what are we going to do about it?

On Sun, Apr 24, 2022 at 05:03:29AM +0200, Simon Richter wrote: > > Making Debian hard to use is a very short-sighted view of how to promote > > free software - it works in the very short term only. > > The same applies in the other direction -- making no real distinction > between free and

Re: Firmware - what are we going to do about it?

On Sat, Apr 23, 2022 at 10:48:03PM +0200, Paul van der Vlis wrote: > > > I have an idea for an extra option: > > > > > > 6. Put the closed source firmware somewhere in the Debian images, but > > > never > > > install closed source firmware by default. "No" should be the default. > > That's the

Re: Firmware - what are we going to do about it?

On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote: > > I see several possible options that the images team can choose from here. > > However, several of these options could undermine the principles of Debian. > > We > > don't want to make fundamental changes like that without the

Re: Firmware - what are we going to do about it?

On Thu, Apr 21, 2022 at 01:39:39PM +0300, Hakan Bayındır wrote: > > > > > As everybody knows, Debian is also releasing the said firmware as > > > > > compressed > > > > > archives and these are visible in the download page [0], however > > > > > usage and > > > > > documentation is neither

Re: Firmware - what are we going to do about it?

On Thu, Apr 21, 2022 at 10:57:47AM +0300, Hakan Bayındır wrote: > > > As everybody knows, Debian is also releasing the said firmware as > > > compressed > > > archives and these are visible in the download page [0], however usage and > > > documentation is neither clearly documented, nor easy for

Re: Firmware - what are we going to do about it?

On Thu, Apr 21, 2022 at 09:57:36AM +0300, Hakan Bayındır wrote: > As everybody knows, Debian is also releasing the said firmware as compressed > archives and these are visible in the download page [0], however usage and > documentation is neither clearly documented, nor easy for the beginners or >

Re: Firmware - what are we going to do about it?

On Wed, Apr 20, 2022 at 12:53:46PM -0500, Devin Prater wrote: > But back on topic, would the nonfree DVD ISO's have more firmware on them > than the CD version? Or is that just for offline installs? As far as I understand it there is just one set of non-free firmware for including in the ISOs and

Re: Firmware - what are we going to do about it?

On Wed, Apr 20, 2022 at 05:04:13AM -0500, Devin Prater wrote: > So then, I found the Non-free section and got the CD version? I guess > that's what I should have gotten? The DVD one is the live environment > right? See how confusion this can be? Yes, the variety of our ISOs and the poor way they

Re: Keep both images but stop pretending no-free is unofficial

On Wed, Apr 20, 2022 at 08:28:25AM -0400, Polyna-Maude Racicot-Summerside wrote: > I think you lack pretty much of seeing more than you own self and use case. No, everything I write in these threads I write for our potential users who don't have enough knowledge to find things they need or to

Re: Keep both images but stop pretending no-free is unofficial

On Wed, Apr 20, 2022 at 01:25:31PM +0530, Pirate Praveen wrote: > >> >> Similarly, I think it would be reasonable for someone to want to provide > >> >> entirely free Debian media along with a libre laptop. > >> > > >> >Does this exist in the real world? Which hardware would such a system > >>

Re: Keep both images but stop pretending no-free is unofficial

On Wed, Apr 20, 2022 at 12:55:44PM +0530, Pirate Praveen wrote: > >> Similarly, I think it would be reasonable for someone to want to provide > >> entirely free Debian media along with a libre laptop. > > > >Does this exist in the real world? Which hardware would such a system > >contain? > >

Re: Firmware - what are we going to do about it?

On Tue, Apr 19, 2022 at 11:00:23PM +0200, Jonas Smedegaard wrote: > > > > > > > When I install systems, I consider non-free blobs more risky > > > > > > > than other code. > > > > > > Do you consider loadable non-free blobs more risky than their > > > > > > older versions soldered onto the

Re: Firmware - what are we going to do about it?

On Tue, Apr 19, 2022 at 06:51:16PM +0200, Jonas Smedegaard wrote: > > > > > When I install systems, I consider non-free blobs more risky > > > > > than other code. > > > > Do you consider loadable non-free blobs more risky than their > > > > older versions soldered onto the hardware? > > > > >

Re: Firmware - what are we going to do about it?

On Tue, Apr 19, 2022 at 04:30:44PM +0100, Tim Woodall wrote: > > On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote: > > > When I install systems, I consider non-free blobs more risky than other > > > code. > > Do you consider loadable non-free blobs more risky than their older > >

Re: Firmware - what are we going to do about it?

On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote: > When I install systems, I consider non-free blobs more risky than other > code. Do you consider loadable non-free blobs more risky than their older versions soldered onto the hardware? > When I (sometimes, but not always¹)

Re: Firmware - what are we going to do about it?

On Tue, Apr 19, 2022 at 11:33:30AM +0200, Christian Kastner wrote: > Hi Steve, > > thank you for bringing this up. > > On 2022-04-19 02:27, Steve McIntyre wrote: > > 1. Keep the existing setup. It's horrible, but maybe it's the best we can > > do? > > (I hope not!)> > > 2. We could just

Re: Firmware - what are we going to do about it?

On Tue, Apr 19, 2022 at 10:22:15AM +0200, parodper wrote: > > 5. We could split out the non-free firmware packages into a new > > non-free-firmware component in the archive, and allow a specific > > exception > > only to allow inclusion of those packages on our official media. We > >

Re: ITP: trbot -- Powerful software for playing games through text, supporting remote collaborative play

On Fri, Apr 15, 2022 at 09:21:20PM +, kimim...@posteo.net wrote: > Package: trbot > Version: 2.5.1 > Severity: wishlist Looks like you intended to submit this as a bug report but sent it to debian-devel@ instead. Also, if you are not going to package and maintain this software in Debian but

Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

On Fri, Apr 08, 2022 at 05:25:11PM +0200, Vincent Lefevre wrote: > > > Bug 993316 was fixed on 23 September 2021. Any reason why rpcbind > > > hasn't been rebuilt yet? > > Was anything done for that to happen? Because otherwise the answer is > > "nobody did that". > > I would have assumed that

Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

On Fri, Apr 08, 2022 at 03:22:07PM +0200, Vincent Lefevre wrote: > Due to the old bug 993316 in debhelper[*], rpcbind is still buggy as > it hasn't been rebuilt yet: rpcbind_1.2.6-2_amd64.deb contains > > -rw-r--r-- root/root 626 2021-08-17 17:31:36 >

Re: What to do with merged /usr and dpkg-fsys-usrunmess

On Wed, Apr 06, 2022 at 04:02:23PM +0200, Bjørn Mork wrote: > > Sorry, blame the dpkg maintainer. > > Is that how we discuss technical issues around here? This is not a technical issue. -- WBR, wRAR signature.asc Description: PGP signature

Re: isa-support -- exit strategy?

On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote: > While packages are allowed to not support entire architectures > outright, there's a problem when some code requires a feature that is > not present in the arch's baseline. Effectively, this punishes an arch > for keeping

Re: proposed MBF: packages still using source format 1.0

On Tue, Mar 15, 2022 at 10:49:17AM +, Matthew Vernon wrote: > >> It's probably unfashionable, but I think debian/patches is not a great > >> way to manage changes, particularly if you're using a VCS for > >> maintaining your packages. As others have pointed out in this thread, > >> doing this

Re: proposed MBF: packages still using source format 1.0

On Tue, Mar 15, 2022 at 08:54:50AM +, Matthew Vernon wrote: > It's probably unfashionable, but I think debian/patches is not a great > way to manage changes, particularly if you're using a VCS for > maintaining your packages. As others have pointed out in this thread, > doing this means you

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

On Mon, Mar 14, 2022 at 09:43:15PM +0100, Jérémy Lal wrote: > > We are currently considering the following dates as our freeze > > dates. If you are aware of major clashes of these dates with anything > > we depend on please let us know. We also like to stress again that we > > really would like

Re: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883"

On Thu, Feb 24, 2022 at 10:09:23PM +0900, Osamu Aoki wrote: > Hi, > > I favor moving away from pre-dh7 packages and I support people pushing for > it. But I > am in intriguing situation with this effort. Can someone help me. > > At: https://udd.debian.org/cgi-bin/autoremovals.cgi > > I see:

Re: LESS copyright, not more!

On Thu, Feb 10, 2022 at 12:14:40PM +0100, dude wrote: > Linus: the (GPL 2.0) intented social contract is: “i give you sourcecode, > give me back your changes” > >

Re: What are the most important projects that Debian ought to work on?

On Thu, Feb 10, 2022 at 12:07:24PM +0100, dude wrote: > provide build in easy feedback-communications to digest, collect, analyze > user's needs and progress from there > > (more security, stability and faster boot is laways better X-D (in that > order)) > > aka: what is REALLY needed (comes per

Re: What are the most important projects that Debian ought to work on?

On Wed, Feb 09, 2022 at 06:53:49PM +0100, Enrico Zini wrote: > > > I've added "We should have a default standard packaging workflow": > > > https://salsa.debian.org/debian/grow-your-ideas/-/issues/24 > > This should include ideas what to do with resignations that will follow. > > Why would one

Re: What are the most important projects that Debian ought to work on?

On Wed, Feb 09, 2022 at 03:23:38PM +0100, Enrico Zini wrote: > > That's where you come into play: it would be nice if you could share > > what are — according to you — the most important projects/improvements > > that Debian ought to make. You can share your ideas here by replying to > > this

Re: Legal advice regarding the NEW queue

On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote: > On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: > > Doesn't that, then, lead to the suggestion that any package entering > > unstable without having undergone NEW review (which, in the revised > > model, might be every

Re: Legal advice regarding the NEW queue

On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: > >>> I would hate to entirely lose the quality review that we get via > >>> NEW, but I wonder if we could regain many those benefits by > >>> setting up some sort of peer review system for new packages that > >>> is less formal and

Re: Legal advice regarding the NEW queue

On Tue, Feb 01, 2022 at 09:18:07AM -0800, Russ Allbery wrote: > I would hate to entirely lose the quality review that we get via NEW, but > I wonder if we could regain many those benefits by setting up some sort of > peer review system for new packages that is less formal and less > bottlenecked

Re: Unplanned freeze?

On Fri, Jan 28, 2022 at 07:53:02AM +0100, Ole Streicher wrote: > I just observed that many of my packages that are currently in unstable > are not migrating because of > > | Not touching package due to block request by elbrus (Follow the freeze > | policy when applying for an unblock) > > where

Re: generic viewer for md files

On Mon, Jan 24, 2022 at 12:46:40PM +0100, Jerome BENOIT wrote: > I am asking because a software that I am currently packaging has its documents > in MarDown (GitHub flavour, I guess). You can likely read those with `less`. Alternatively, software is likely to ship a build script for e.g. HTML in

Re: generic viewer for md files

On Mon, Jan 24, 2022 at 10:36:50AM +0100, Jerome BENOIT wrote: > is there a virtual package for viewing MD documents Do you mean Markdown? Are there specialized viewers for it at all? -- WBR, wRAR signature.asc Description: PGP signature

Re: How to contribute ?

On Sun, Jan 02, 2022 at 11:07:10AM -0600, Zebediah Figura wrote: > > > > > vkd3d 1.2-6 in Experimental is not usable in Sid because it needs > > > > > mesa-vulkan-driver << 21. > > > > > > > > > > Michael did that because vkd3d tests fails during building. I don't > > > > > know > > > > > why

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, Jan 01, 2022 at 07:06:09PM +, Reuben Thomas wrote: > Here's a summary of the packages I'm trying to update. If any DD can help me > get these uploaded, I'd be most grateful The packages you listed are not orphaned and the changes you listed don't warrant NMUs so your only options are

Re: How to contribute ?

On Fri, Dec 31, 2021 at 02:47:22PM -0600, Zebediah Figura wrote: > > > vkd3d 1.2-6 in Experimental is not usable in Sid because it needs > > > mesa-vulkan-driver << 21. > > > > > > Michael did that because vkd3d tests fails during building. I don't know > > > why because it fails with mesa 20

Re: How to contribute ?

On Fri, Dec 31, 2021 at 03:37:05PM +0100, Maxime Lombard wrote: > vkd3d 1.2-6 in Experimental is not usable in Sid because it needs > mesa-vulkan-driver << 21. > > Michael did that because vkd3d tests fails during building. I don't know > why because it fails with mesa 20 too. > > I opened a bug

Re: How to contribute ?

On Tue, Dec 21, 2021 at 07:47:47PM +0100, Maxime Lombard wrote: > Hello, > > I'm an user of Debian since 10 years ago and it's only now that i decide to > help to packaging. > I send this email about wine and wine-development package which are not > updated since a very long time. Normally you

Re: Reopen RFP Skia - Google's 2D graphic suite

On Mon, Dec 13, 2021 at 02:51:55PM +0100, maxzor wrote: > TL;DR Please consider reopening the following request for packaging : > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818180 You could that yourself. On the other hand, having an RFP doesn't mean anything so reopening it is not useful.

Re: How to do 32-bit build in AMD64 chroot -- problem with SSE instructions?

On Sat, Dec 11, 2021 at 05:12:50PM -0600, Steven Robbins wrote: > I've built the ITK package on my AMD64 machine without trouble, but the > 32-bit > build is failing with the error below. It's failing on buildds with the same problem so you are running the build itself correctly. > The errors

Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]

On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: > > > I don't know if that has been proposed before, but how about waiving > > > the NEW queue requirement for experimental packages as a start? > > > [...] Since packages in experimental will never land in any > > > official

Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]

On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote: > I don't know if that has been proposed before, but how about waiving > the NEW queue requirement for experimental packages as a start? > [...] Since packages in experimental will never land in any > official release, I think

Re: Mapping Reproducibility Bug Reports to Commits

On Sun, Nov 14, 2021 at 05:53:24PM +, Muhammad Hassan wrote: > Hi all, > > I am a researcher at the University of Waterloo, conducting a project to > study reproducibility issues in Debian packages. > > The first step for me is to link each Reproducibility-related bug at this > link: >

Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

On Fri, Nov 12, 2021 at 12:03:53PM +, Stephan Verbücheln wrote: > Then I also think that OpenSSL 0.9.x/1.x and the new OpenSSL 3.x have > to be treated like two completely different libraries. They have > different licenses and intentionally broke APIs to end the mess that > OpenSSL was. When

Re: Short description disapearing from package tracker

On Thu, Nov 11, 2021 at 07:16:50PM +0100, Ben Tris wrote: > Maybe I did make a mistake. Is the description of the first binary visible at > the source package? No, otherwise all pages would have some description. The description of the binary with the same name as the source package is displayed.

Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

On Thu, Nov 11, 2021 at 08:01:54AM -0800, Russ Allbery wrote: > (Didn't Red Hat attempt to standardize on NSS a while back? I feel like > that didn't work and they stopped that effort, but some quick searching > didn't uncover any support for that belief.)

Re: pan blend lists game powder should be removed (relative: debichem science medical)

On Thu, Nov 11, 2021 at 07:47:20AM +0100, Andreas Tille wrote: > For some reason git blamed me for injecting this into the mx task and > so I removed it[1]. I'm pretty sure that I never edited the pan tasks > despite git blames me about this. No idea what's wrong here and it > would be great if

  1   2   3   4   5   6   7   8   9   10   >