Re: Handling of merge requests on salsa.d.o for debian-xen.

On Mon, Nov 11, 2024 at 06:03:22PM +0100, Alexandre GRIVEAUX wrote: > Hello, > > Some time ago I created some merge request on salsa for debian-xen: > > https://salsa.debian.org/xen-team/debian-xen/-/merge_requests?scope=all&state=opened These looks like you want to send them upstream instead.

Re: RFC: "Recommended bloat", and how to possibly fix ito

On Fri, Nov 08, 2024 at 08:20:46AM +0100, IOhannes m zmölnig wrote: > Am 8. November 2024 06:42:25 MEZ schrieb Marc Haber > : > >Agreed! And I would also love the possibility to directly paste a > >package list from apt show's output into apt install without having to > >remove the commas. > > >

Re: Rebuilds to enable PAC and BTI support on arm64

On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote: > As a final thought, given that new toolchain versions bring multiple > improvements over the years it's perhaps worth thinking about rebuilding > the archive on some sort of regular basis to make sure we get the > benefits? "Let's a

Re: Rebuilds to enable PAC and BTI support on arm64

On Wed, Nov 06, 2024 at 01:16:57PM +, Holger Levsen wrote: > On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote: > > "Let's at least force rebuilds all packages not rebuilt since stable > > before every freeze starts" is a popular opinion. > &

Re: Binary uploads into the archive

On Tue, Oct 29, 2024 at 02:56:46PM +0100, Dennis van Dok wrote: > Coincidentally did the exact same thing (with igtf-policy-bundle); but this > is now stuck as it cannot migrate to testing (unless somebody manually > intervenes). > > I think what I should do is update the release number and do ano

Re: Binary uploads into the archive

On Mon, Oct 28, 2024 at 10:09:16PM +0100, Daniel Leidert wrote: > by accident, I uploaded a binary package today (ruby-rouge) instead of > its source-package into the archive. I expected the binary package > being rejected once I discovered my mistake. But it was accepted > instead, and it was also

Re: Most optimal way to import NMU into existing git-builpackage repository?

On Fri, Oct 25, 2024 at 12:55:48PM -0400, Noah Meyerhans wrote: > > > Honestly I'd be happy if we could just establish some expectation that > > > the NMUer open a merge request for their changes. It can be merged > > > later without losing anything or requiring additional work. Enforcement > > >

Re: Most optimal way to import NMU into existing git-builpackage repository?

On Fri, Oct 25, 2024 at 10:06:56AM -0400, Noah Meyerhans wrote: > > I would very much prefer if it was possible in Debian to not allow > > the archive to get out of sync with packaging git repo (for example > > when it lives under salsa.debian.org/debian which uploaders should have > > access to al

Re: Most optimal way to import NMU into existing git-builpackage repository?

On Fri, Oct 25, 2024 at 11:22:25AM +0100, Peter B wrote: > > I occasionally run into the situation that a package has been NMU'd or > > otherwise updated directly into the Debian repositories, > > bypassing/ignoring that a packaging git repository existed. > > Hi Otto, > > Are any of these packa

Re: [RFH] Running Python tests that require the source to be installed

On Thu, Oct 24, 2024 at 12:44:45PM +0200, John Paul Adrian Glaubitz wrote: > (Please CC as I'm not subscribed to debian-devel) (this is how I realized this is not debian-python@, consider using that for more relevant coverage) > I am maintaining the package src:kiwi [1] which hasn't been updated

Re: Most optimal way to import NMU into existing git-builpackage repository?

On Thu, Oct 24, 2024 at 09:36:04PM +0100, Otto Kekäläinen wrote: > Hi, > > I occasionally run into the situation that a package has been NMU'd or > otherwise updated directly into the Debian repositories, > bypassing/ignoring that a packaging git repository existed. I was > wondering what techniqu

Re: Most optimal way to import NMU into existing git-builpackage repository?

On Fri, Oct 25, 2024 at 08:45:16AM +0200, Andreas Henriksson wrote: > I would very much prefer if it was possible in Debian to not allow > the archive to get out of sync with packaging git repo (for example > when it lives under salsa.debian.org/debian which uploaders should have > access to alread

Re: [RFH] Running Python tests that require the source to be installed

On Thu, Oct 24, 2024 at 12:57:42PM +0200, Sebastiaan Couwenberg wrote: > You may need to copy some additional files there, e.g.: > > export PYBUILD_BEFORE_TEST=cp -r {dir}/foo {dir}/bar {build_dir} > export PYBUILD_AFTER_TEST=rm -rf {build_dir}/foo {build_dir}/bar Consider using pybuild.testfie

Re: lintian preventing uploads

On Mon, Oct 21, 2024 at 05:58:20PM +1100, Russell Coker wrote: > > > $ cat debian/source/lintian-overrides > > > # We aren't building with Discord support and therefore everything under > > > # 3rdparty/discord-rpc is not relevant. If in future we add Discord > > > support we > > > # should Build-

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

On Thu, Oct 17, 2024 at 10:35:01AM +0200, Paul Gevers wrote: > > > I hadn't heard of these architecture-is-64-bit and not-supported-on > > > metapackages(?). Would someone who knows how they are meant to work > > > consider submitting a patch for Policy? Thanks. > > > > I think they, just like i

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

On Thu, Oct 17, 2024 at 10:48:21AM +0800, Sean Whitton wrote: > Hello, > > I hadn't heard of these architecture-is-64-bit and not-supported-on > metapackages(?). Would someone who knows how they are meant to work > consider submitting a patch for Policy? Thanks. I think they, just like isa-supp

Re: Files-Excluded with DEP-14

On Tue, Oct 15, 2024 at 07:30:57PM -0700, Otto Kekäläinen wrote: > If you need to repack, you should have a spearate branch > 'upstream/latest' as the targets for merges from upstream tags, and > then from 'upstream/latest' you merge on 'debian/master' (which > following DEP-14 should be 'debian/la

Re: Files-Excluded with DEP-14

On Tue, Oct 15, 2024 at 02:44:59PM +0200, Joachim Zobel wrote: > Am Dienstag, dem 15.10.2024 um 00:09 -0700 schrieb Otto Kekäläinen: > > I suspect you have something wrong with the branch structure, perhaps > > you are trying to remove files in actual upstream branch and not the > > "upstream impor

Re: Debian policy 9.2.1 needs --allow-bad-names

On Sat, Oct 05, 2024 at 05:21:10PM +0200, Joachim Zobel wrote: > Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or > dynamically generated username for packages to use, they should start > this username with an underscore." By now this requires an  > > adduser --allow-bad-names

Re: spurious autoremovals due to python3-nose

On Fri, Sep 27, 2024 at 10:58:02AM +0200, Chris Hofstaedtler wrote: > An interesting research topic is probably what is the non-key key > package depending on nose, and can that be fixed soon. A good > starting point might be "pkg-perl-tools", which is affected but > seems unlikely to directly depe

Re: spurious autoremovals due to python3-nose

On Fri, Sep 27, 2024 at 10:07:07AM +0200, Alexandre Detiste wrote: > Hi, > > "nose" is RC buggy. It was until a few days ago in the "key packages set". > > After recent upload of piuparts, nose dropped out of the key package set, > as expected. > > What was not expected is that nose started the

Re: How painful is a lib(fuse) .so version bump for a distribution

On Thu, Sep 26, 2024 at 12:48:03AM +0200, Ben Hutchings wrote: > > > I would like to ask how painful is a library (libfuse) .so for a > > > distribution? > > > > Not at all, if all revdeps build fine with the bumped version. > > > > "I'm assuming that distributions do not recompile packages again

Re: How painful is a lib(fuse) .so version bump for a distribution

On Wed, Sep 25, 2024 at 09:38:26PM +0200, Bernd Schubert wrote: > I would like to ask how painful is a library (libfuse) .so for a > distribution? Not at all, if all revdeps build fine with the bumped version. "I'm assuming that distributions do not recompile packages against a new library versio

Re: pcsc-cyberjack needs update to support more apparatus Germany oriented.

On Wed, Sep 18, 2024 at 07:27:05AM +, benatt...@gezapig.nl wrote: > You are wasting you're precious time. I do, in hopes that the total time wasted by readers of our mailing lists will decrease. -- WBR, wRAR signature.asc Description: PGP signature

Re: pcsc-cyberjack needs update to support more apparatus Germany oriented.

On Tue, Sep 17, 2024 at 03:35:07PM +, benatt...@gezapig.nl wrote: > One of those apparatus was specially > designed for persons with bad sight or blind. > This needs an update but something goes wrong > in the communication I think. > My guess is that an actual update is done easy. > > Repolo

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote: > P.S. Wow, diffoscope has a /lot/ of dependencies. I understand why, but > still... wow. (Note that those are Recommends and that there is diffoscope-minimal) -- WBR, wRAR signature.asc Description: PGP signature

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On Sat, Aug 31, 2024 at 07:06:30PM -0400, Jonathan Kamens wrote: > Hey folks, > > I had to step away from working on apt-listchanges > for quite a while (nearly > a year), and upon stepping back into it today and pushing some changes to > Salsa, I

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

On Fri, Aug 23, 2024 at 04:00:25PM -0400, Theodore Ts'o wrote: > On Fri, Aug 23, 2024 at 03:08:11PM +0200, Marco d'Itri wrote: > > > Salsa CI?) > > The effort needed to do so is so small that the question really should > > be "why should I NOT spend a few seconds enabling Salsa CI?". > > > > > 3)

Re: Removing more packages from unstable

On Wed, Aug 21, 2024 at 08:40:15PM +, weepingclown wrote: > I believe at least some of these packages were probably packaged as > dependencies for packaging lazygit. I am not sure which all, but I > remember atleast gocui, pty and termbox-go to be needed by lazygit in > one way or another. Ther

Re: Removing more packages from unstable

On Wed, Aug 21, 2024 at 03:39:11PM +0200, Héctor Orón Martínez wrote: > I am surprised to not see more of those packages in the list, there > are many packages in those ecosystems with popcon between 1-10 users. popcon wasn't used when building this list though (even via the key packages condition

Re: Removing more packages from unstable

On Wed, Aug 21, 2024 at 10:06:38AM +, Holger Levsen wrote: > Hi, > > I also like us to remove more broken and unused packages from unstable. > > On Tue, Aug 20, 2024 at 11:20:10AM +0200, Lucas Nussbaum wrote: > > Maybe we could also reduce the cost of removals for users and potential > > new

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote: > > Something that many developers are probably not aware of is that they > > can enable CI for a repository with no code changes at all and with > > a single command: > > > > salsa update_projects $NAMESPACE/$PROJECT \ > > --jobs

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kekäläinen wrote: > Hi! > > In short: > I would very much like to see all top-150 packages run Salsa CI at > least once before being uploaded to unstable. What people think is a > reasonable way to proceed to reach this goal? > > > Background: > We

Re: Removing more packages from unstable

On Tue, Aug 20, 2024 at 12:12:33PM +, Scott Kitterman wrote: > >Removing packages that aren't formally orphaned always sounds too bold to > >me, though it should be fine if we formalize a process (any process) for > >that. > > > The process currently is file an rm but against ftp.debian.org for

Re: Removing more packages from unstable

On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote: > I think popcon does give a good approximation of how much percent of people > installed a certain package even if not everyone uses it, don't you agree? > > Last time I installed Debian it was still enabled by default. Was it? (t

Re: Removing more packages from unstable

On Tue, Aug 20, 2024 at 07:28:52AM +0200, Helmut Grohne wrote: > please allow me to open a can of worms. Package removal from unstable. > Deciding when it is time to remove a package from unstable is difficult. > There may be users still and it is unclear whether keeping the package > imposes a cos

Re: Strange armel build error

On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote: > Hi Stephen, > > On 18/08/2024 09:04, Stephen Kitt wrote: > > On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas > > wrote: > > > Or just exclude that architecture i. e., list all archs but armel? > > If you can’t fix the build, you don’

Re: Accepting DEP14?

On Sat, Aug 17, 2024 at 12:20:16PM +0200, Andreas Tille wrote: > My personal preference would be if we make a pristine-tar branch default > since this is what I observed in the wide majority of cases. Note that there are different opionons whether pristine-tar is needed/viable/useful. There is at

Re: Accepting DEP14?

On Fri, Aug 16, 2024 at 03:59:07PM +0200, Andreas Tille wrote: > Am Fri, Aug 16, 2024 at 02:58:40PM +0500 schrieb Andrey Rakhmatullin: > > > > pristine-tar isn't the default either, so you need debian/gbp.conf if your > > team uses it. > > That's correct b

Re: Accepting DEP14?

On Fri, Aug 16, 2024 at 11:44:38AM +0200, Andreas Tille wrote: > > In #829444 it has been proposed the addition of a new "layout" option to > > gbp.conf, which would tell git-buildpackage which layout to follow, > > allowing for a graceful migration. > > > > I've been thinking about a different ap

Re: Python2 idiosyncrasies in Python3 scripts

On Thu, Aug 15, 2024 at 01:11:23PM +0200, Jerome BENOIT wrote: > > > is there a reliable way to isolate Python2 idiosyncrasies in Python3 > > > scripts ? > > > > Do you mean code that still works in Python 3 but can be simplified? > > Lots of linters do this in whole or in part, though I don't ha

Re: Python2 idiosyncrasies in Python3 scripts

On Thu, Aug 15, 2024 at 12:11:55PM +0200, Jerome BENOIT wrote: > is there a reliable way to isolate Python2 idiosyncrasies in Python3 scripts ? Do you mean code that still works in Python 3 but can be simplified? Lots of linters do this in whole or in part, though I don't have suggestions for some

Re: Porterbox - impossible efficient debugging?

On Tue, Aug 13, 2024 at 01:35:03PM +0200, julien.pu...@gmail.com wrote: > > > And of course, this is where I came to my wits' end: I can compile > > > the > > > new elpi successfully... but I have no way to install this new elpi > > > binary packages in the schroot to test it against different coq-

Re: Porterbox - impossible efficient debugging?

On Tue, Aug 13, 2024 at 12:15:22PM +0200, julien.pu...@gmail.com wrote: > And of course, this is where I came to my wits' end: I can compile the > new elpi successfully... but I have no way to install this new elpi > binary packages in the schroot to test it against different coq-elpi! Yes, the us

Re: Who is taking care of storm.debian.net?

On Mon, Aug 12, 2024 at 11:02:04AM +0200, Philipp Kern wrote: > On 12.08.24 10:57, Carsten Schoenert wrote: > > Am 12.08.24 um 10:27 schrieb Carsten Schoenert: > > > Hi, > > > > > > the certificate for the domain storm.debian.net has expired yesterday. > > > > > > The site is not listed on https:

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

On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote: > Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto: > > On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote: > > > one problem I have with NMUs in team-maintained package is that they > > > of

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

On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote: > one problem I have with NMUs in team-maintained package is that they > often bypass Salsa… Would it make sense to add to the DEP a request > that NMUs are started from and pushed to the default branch? Only if DEP-18 also includes

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

On Sat, Aug 03, 2024 at 10:37:42PM +0200, Salvo Tomaselli wrote: > > 2. Standardizing around a single (or small number of) workflows will make > > some people unhappy. But that is an acceptable price to pay because of the > > general benefit to the project *as long as the correct solution is > >

Re: i686 require SSE4.1-capable processor?

On Tue, Jul 16, 2024 at 12:46:01PM +0100, Phil Wyett wrote: > > > > Packages built for the i386 arch need to conform to the i386 baseline, > > > > which is currently i686. If a package contains a newer instruction it's > > > > a > > > > bug in that package and gcc is not the cause of it, the packa

Re: i686 require SSE4.1-capable processor?

On Mon, Jul 15, 2024 at 01:42:50PM +0200, Andreas Ronnquist wrote: > I'm maintaining a package (filezilla) which just got a bug report that > it simply crashes on program start - It gets a SIGILL - "Illegal > instruction". (#1076312 report [1]). > > After the reporter debugged it, it seems like i

Re: what about Netplan?

On Sat, Jul 13, 2024 at 09:44:03PM +0200, Lukas Märdian wrote: > > However, I do not think it should be the default. First of all, only > > Ubuntu uses it, nobody else - as Simon says, we don't want the > > defaults to be super-special things that nobody else uses. And then > > Actually, I think t

Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

On Fri, Jul 12, 2024 at 07:01:41AM +0100, Phil Wyett wrote: > > > As we embark on a new process where packages submitted to mentors are > > > reviewed > > > and brought to a "Ready" stage for then busy DDs who are gracious enough > > > to give > > > their time to review and possibly sponsor into

Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

On Fri, Jul 12, 2024 at 05:54:59AM +0100, Phil Wyett wrote: > Morning all, > > As we embark on a new process where packages submitted to mentors are reviewed > and brought to a "Ready" stage for then busy DDs who are gracious enough to > give > their time to review and possibly sponsor into Debia

Re: Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation

On Sun, Jul 07, 2024 at 01:54:59PM -0400, Yogeswaran Umasankar wrote: > Yes, can use the standard library. This dependency chain starts with > moarchiving, which itself is a dependency for cma, and so on. I can > create a patch specifically for moarchiving. As reported elsewhere, moarchiving decla

Re: Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation

On Sun, Jul 07, 2024 at 07:00:57PM +0200, Daniele Nicolodi wrote: > On 07/07/24 17:43, Yogeswaran Umasankar wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Yogeswaran Umasankar > > X-Debbugs-Cc: debian-devel@lists.debian.org, y...@debian.org > > > > * Package name: python-fraction

Re: DD's, Debian Mentors needs you!

On Sun, Jul 07, 2024 at 10:10:55AM -0400, Jeremy Bícha wrote: > On Sat, Jul 6, 2024 at 9:46 AM Phil Wyett wrote: > > Debian Mentors[1] always struggles to find available Debian Developers for > > final reviewing and > > sponsoring of packages submitted too our part of the project. > > One thing

Re: DD's, Debian Mentors needs you!

On Sun, Jul 07, 2024 at 07:54:25AM +0200, Andreas Tille wrote: > Hi Phil, > > thanks for advertising Debian Mentors. > > Am Sat, Jul 06, 2024 at 02:45:33PM +0100 schrieb Phil Wyett: > > Hi all DD's > > > > Debian Mentors[1] always struggles to find available Debian Developers for > > final revi

Re: DD's, Debian Mentors needs you!

On Sun, Jul 07, 2024 at 07:41:25AM +0800, xiao sheng wen(肖盛文) wrote: > Hi, > > Support this become a weekly thing or a monthly thing. > > Can mentors.debian.net sent package list to debian-devel automatically? The list of open RFSes is always available at https://bugs.debian.org/sponsorship-re

Re: Q: Ubuntu PPA induced version ordering mess.

On Wed, Jul 03, 2024 at 09:27:03AM +0200, Philip Hands wrote: > IOhannes m zmölnig (Debian GNU|Linux) writes: > > > anyhow here's my 2¢: > > according to you¹, upstream have simply botched their package > > versioning, which i would consider *a bug*. > > bugs cause pain. > > AIUI the botching w

Re: Q: Ubuntu PPA induced version ordering mess.

(sorry, I replied thinking I've read the entire thread, I didn't notice that there is a second thread broken off of this one) -- WBR, wRAR signature.asc Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

On Mon, Jul 01, 2024 at 11:59:00PM +0200, Alec Leamas wrote: > > > After some thought, I tend to think that adding an epoch is the right > > > thing > > > here. > > > > > > The Policy [1] says: > > > --- > > > Epochs can help when the upstream version numbering scheme changes, but > > > they > >

Re: Q: Ubuntu PPA induced version ordering mess.

On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote: > On 01/07/2024 20:48, Alec Leamas wrote: > > Dear list, > > > > Still working with the opencpn package. Now trying to normalize the > > Ubuntu PPA builds so they can are based on the same debian/ directory > > and tools as the existing

Re: Urgent help with upload of netatalk to prevent being autoremoval from testing

On Sat, Jun 29, 2024 at 02:13:04PM +, Daniel Markstedt wrote: > Netatalk got dropped from Bookworm because there was a changing of the guards > of upstream maintainers during the freeze time. > So I'm just naturally anxious about missing the boat again for Trixie. Just make sure it's in testi

Re: How does lintian use groff to validate man pages?

On Fri, Jun 28, 2024 at 11:38:50AM +, c.bu...@posteo.jp wrote: > > lintian-explain-tags can provide you with extensive information > > ... > > N: LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \ > > N: man --warnings -E UTF-8 -l -Tutf8 -Z >/dev/null > > Do I do something wro

Re: BIMI verified email logo for @debian.org addresses

On Thu, Jun 27, 2024 at 07:29:45PM +0800, Blair Noctis wrote: > Hi, > > [BIMI], or Brand Indicators for Message Identification, is a specification to > let supporting email clients show a brand's logo next to verified email > domains. > It would be great to have the Debian logo shown next to @deb

Re: Reviving schroot as used by sbuild

On Tue, Jun 25, 2024 at 10:24:12AM -0700, Russ Allbery wrote: > Guillem Jover writes: > > > I manage my chroots with schroot (but not via sbuild, for dog fooding > > purposes :), and use type=directory and union-type=overlay so that I get > > a fast and persistent base, independent of the underly

Re: Reviving schroot as used by sbuild

On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote: > > In this work, limitations with --chroot-mode=unshare became apparent and > > that lead to Johannes, Jochen and me sitting down in Berlin pondering > > ideas on how to improve the situation. That is a longer story, but > > eventuall

Re: Mini-DebConf in Cambridge, UK - October 10-13 2024

On Tue, Jun 25, 2024 at 06:14:54AM -0400, Roberto C. Sánchez wrote: > > The style of writing mail - everything in one line, CCing several lists is > > similar to how Luna writes it too. Freaky. > > > AI can already generate audio and video that convincingly imitate real > people. Why not the same

Re: dh_auto_clean, autoconf, and building packages twice (was: Potential MBF: packages failing to build twice in a row)

On Sun, Jun 23, 2024 at 02:06:04PM +0200, Magnus Holmgren wrote: > I'm very late to the party, but after reading the entire thread, I'd like to > discuss a more specific, but perhaps not uncommon, situation with regard to > cleaning and building again: > > We have a [still fairly] typical upstre

Re: WolfSSL and Netatalk

On Sun, Jun 23, 2024 at 05:58:54AM +, Daniel Markstedt wrote: > > wolfssl is packaged in Debian, did you try to build netatalk with the > > packaged version? > > > > Debian doesn't like code copies in sources, so if it builds fine with > > the packaged version, removing it from the source that

Re: Re: About i386 support

On Fri, Jun 14, 2024 at 05:53:42AM -0500, r...@neoquasar.org wrote: > A bug that can't be reproduced, effectively doesn't exist.  Wow. -- WBR, wRAR signature.asc Description: PGP signature

Re: Seeking consensus on file conflict between python3-proto-plus and nanopb

On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote: > There is a file conflict between python3-proto-plus and nanopb. The > conflict arises due to both packages has a file at > /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining > python3-proto-plus, and I am se

Re: Suggestions about i386 support

On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote: > On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote: > > The point here is that the Debian project is not intending to support > > new hardware on the i386 architecture. The architecture is being kept > > around primarily to

Re: Enabling some -Werror=format* by default?

On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote: > > Do you think it makes sense to add this a flag that enables -Werror=format > > to dpkg-buildflags(1), before, or after a test rebuild, before, or after > > the MBF if we do one? > > If by adding you mean adding a new feature flag t

Re: Enabling some -Werror=format* by default?

On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote: > > > > We recently increased the time_t size on certain architectures and some > > > > packages started failing to build because they were using a format > > > > specifier too narrow for the wider time_t, e.g. #1067829. > > > > But the

Re: Enabling some -Werror=format* by default?

On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote: > > We recently increased the time_t size on certain architectures and some > > packages started failing to build because they were using a format > > specifier too narrow for the wider time_t, e.g. #1067829. > > But the only reason tho

Re: Suggestions about i386 support

On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote: > >> It's not just a matter of "buy something better." That's easy.  > > >Indeed, that is easier and cheaper. > > Of course, continuing to use a system I already have is cheaper still. > > > What's not easy is that a) that adds

Re: Illegal Instruction Using sudo in Bookworm on i686

On Sun, Jun 09, 2024 at 06:56:00AM -0500, rhys wrote: > The question right now is: Is this processor supported at all? No. > So given that these no longer fit the "old and busted" description, is Debian > going to stick with the decision to not support them? I'm sure we will, yes, though I'm not

Enabling some -Werror=format* by default?

We recently increased the time_t size on certain architectures and some packages started failing to build because they were using a format specifier too narrow for the wider time_t, e.g. #1067829. But the only reason those package FTBFS is they enable either -Werror or some more specific non-defaul

Re: Mandatory LC_ALL=C.UTF-8 during package building

On Thu, Jun 06, 2024 at 12:08:17PM +0200, Johannes Schauer Marin Rodrigues wrote: > Or whether we should switch the default and require that d/rules is run in an > environment (for example as set-up by dpkg-buildpackage) where these variables > are set? (a previous discussion on this: https://list

Re: changing existing entries in debian/changelog

On Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur wrote: > I'm having troubles finding the relevant parts in the developers reference. > I've uploaded a version to experimental and later found out that this > version fixes several bugs. > > Can I rewrite existing changelog entries for alre

Re: finally end single-person maintainership

On Wed, May 22, 2024 at 09:11:16PM +0200, Bernd Zeimetz wrote: > > > You can run autopkgtests locally, you do not need Salsa for that. > > > > Also, Debian runs autopkgtests on all packages that provide them, and > > makes passing them on all supported architectures a requirement for > > testing

Re: finally end single-person maintainership

On Wed, May 22, 2024 at 12:32:32AM +0200, Salvo Tomaselli wrote: > And what's the advantage? When an nmu happens the person doing it normally > doesn't bother to push to salsa anyway. Yes, because it's unfortunately too expensive to: - make sure the repo exists and is uptodate - somehow find out

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

On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote: > Hi, > > On 5/21/24 15:54, Andrey Rakhmatullin wrote: > > > > The Debian archive itself is a VCS, so git-maintained packaging is also a > > > duplication, and keeping the official VCS and git synchroniz

Re: finally end single-person maintainership

On Tue, May 21, 2024 at 12:05:59PM +0200, Philip Hands wrote: > >> > All these things should make it much more easy for other people or > >> > automated tools to send merge requests or keep maintaining a > >> > package in > >> > case the original maintainer becomes MIA. > >> > >> > >> Mandating a

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

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote: > > My concern about Gitlab is not its *additions* to existing services, but > > its *duplications* of core services already in Debian. > > I agree, that's the key problem. > > The Debian archive itself is a VCS, so git-maintained pac

Re: finally end single-person maintainership

On Tue, May 21, 2024 at 12:32:52AM +0200, Bernd Zeimetz wrote: > > > All these things should make it much more easy for other people or > > > automated tools to send merge requests or keep maintaining a > > > package in > > > case the original maintainer becomes MIA. > > > > > > Mandating a speci

Re: About i386 support

On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote: > > > > which is good news. The end of support for 32 bits will not > > > > affect the lives of almost anyone who has machines purchased after > > > > 2011 and who bought them after that > > > > > > Does this also mean he support for ar

Re: About i386 support

On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote: > > which is good news. The end of support for 32 bits will not > > affect the lives of almost anyone who has machines purchased after > > 2011 and who bought them after that > > Does this also mean he support for armhf will be droppe

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 D

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 full

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 directly.

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 full-up

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 pl

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 be

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 > a

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 failure

  1   2   >