Re: Illegal Instruction Using sudo in Bookworm on i686

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

Re: About i386 support

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

Re: Reviving schroot as used by sbuild

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

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

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

Re: OpenPGP digital signature

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

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

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

Re: Strange armel build error

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

Re: Removing more packages from unstable

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

RFH: lesstif2 -- OSF/Motif 2.1 implementation released under LGPL

Package: wnpp Severity: normal C (?) Programmers help wanted. Upstream of lesstif is not active anymore and I have committed myself to help as much as I can to improve the Debian package (also by committing patches upstream). The popcon of this library is pretty high, currently around 15694 insta

Bug#595292: ITP: daisy-player -- player for Daisy talking books (DTB)

Package: wnpp Severity: wishlist Owner: Paul Gevers -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: daisy-player Version : 4.0.2 Upstream Author : Jos Lemmens * URL : http://web.inter.nl.net/users/lemmensj/ * License : GPL version 2 or higher

configuration files, ownership and dpkg-statoverride

Hi, I am looking into dbconfig-common RC bug 720517 [1] and I was wondering what the general idea is of maintainer scripts changing the permissions and/or owners of configuration files and the use of dpkg-statoverride. I myself find it unacceptable that updating a package changes the permissions/o

Re: Bug#720517: configuration files, ownership and dpkg-statoverride

On 07-10-14 15:40, Ian Jackson wrote: > Also I don't see in your references an explanation from anyone as to > why dbconfig-common does this. I you mean with "why": "why is it implemented this way" than that is exactly the question that I am asking myself looking at the code, if you mean "why does

Re: Bug#720517: configuration files, ownership and dpkg-statoverride

On 07-10-14 19:56, Paul Gevers wrote: > I am trying to come up with a patch against dpkg-statoverride that sets > the ownership and permissions upon creation, but not upon updates. OOPS, what a stupid mistake to type. I meant dbconfig-common in the line above. @ Henrique de Moraes Ho

Re: Bug#720517: configuration files, ownership and dpkg-statoverride

On 09-10-14 02:17, Henrique de Moraes Holschuh wrote: > On Wed, 08 Oct 2014, Paul Gevers wrote: >> Thanks for the careful response. And no, as mentioned above, I didn't >> mean to use dpkg-statoverride itself. dbconfig-common uses debconf and >> ufc to manage the co

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

Hi >> BTW there's around 2000 open bugs marked as moreinfo, the oldest is dated >> Sun, 29 Mar 1998 21:03:03 UTC. > > For moreinfo bugs, you are not considered a bad maintainer if you send a "I > will close this if you don't reply"-response after some time and then do that > after some more waiti

Re: docbook-xsl: why only one version ?

Hi Jerome, On 02-06-13 06:30, Jerome BENOIT wrote: > I have to deal with docbook-xsl for one of my package. > I am not familiar with docbook-xsl stuff, so my question may sound naive. > It appears that the upstream stuff play with docbook-xsl version 1.75.2 , > but not 1.76.1 : only the last one i

Re: Candidates for removal from testing (2013-06-04)

Hi, On 04-06-13 14:06, Niels Thykier wrote: > [1] We normally filter out certain type of RC bugs (incl. but not > limited to license issues), where we consider it unreasonable to demand > a resolution within the usual deadline (i.e. 14 days of "non-activity" + > 7 days after a d-d notice). > # #7

Re: jessie release goal: verbose build logs

Hi I agree we need good build logs. On 14-06-13 14:14, Jakub Wilk wrote: > * Matthias Klose , 2013-06-14, 13:35: >> So I'm proposing for jessie: >> >> - File and track issues for packages not enabling verbose builds. >> https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html > > I a

Re: Bug#722950: ITP: ssh-agent-filter -- filtering proxy for ssh-agent

On 15-09-13 11:48, Paul Wise wrote: > On Sat, Sep 14, 2013 at 8:16 PM, Timo Weingärtner wrote: > >> Packaging is prepared, an upload to mentors is waiting for the bug number. > > FYI, ITP stands for *intent* to package. The ITP comes before the > package to prevent duplication of effort. If you m

Re: dpkg-buildpackage creating uninstallable packages?

On 29-09-13 08:40, Norbert Preining wrote: > What is going wrong here? For whatever reason, the amd64 build is picking up i386 paths. I don't know how that happens, except that I expect it is some multi-arch twitch. I recommend you build your packages in a chroot to avoid this (an other) issues. I

Re: Compatibility of libs for Berkeley DB (libdb5.1-dev or libdb4.8-dev)

Hi, On 08-10-13 11:14, Просветов Евгений wrote: > What should I do now? You are asking the wrong forum. This e-mail list is for development of Debian. If you have trouble installing third-party software, you should ask this third-party. If you really insist on asking help from Debian, you could r

Report from the BSP in Utrecht, NL

Next to Alcester, also a BSP was held in Utrecht, the Netherlands [1]. In total, over two days, we worked with 17 people on a number of bugs: * 15 RC bugs were fixed or otherwise dramatically improved * 7 RC bugs were marked notfound in stable and already fixed in wheezy * 18 release-notes bugs w

Re: Discarding uploaded binary packages

On 17-10-12 23:48, Matthias Klose wrote: > On 17.10.2012 21:49, Steve Langasek wrote: >> On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote: >>> Also remeber, there are packages like cmucl that can only be built by the >>> same upstream release of itself and can currently survive in De

Re: the right bug severity in case of data corruption

> The following SHOULD be 0, 1, and 2 levels of quoting, first to last. > >>From blahhityblah Fri Jul 8 12:08:34 2011 >>From foobarbaz Fri Jul 8 12:08:34 2011 >> >From quux Fri Jul 8 12:08:34 2011 So if I understand correctly, I now identified my e-mail provider as using mboxo? I indeed got 1,

Re: the right bug severity in case of data corruption

On 29-11-12 01:43, Christoph Anton Mitterer wrote: > On Wed, 2012-11-28 at 19:55 +0100, Paul Gevers wrote: >> So if I understand correctly, I now identified my e-mail provider as >> using mboxo? I indeed got 1, 1 and 2 levels of quoting. > Depends... were you using his webmail?

openmotif is now LGPL, retirement of lesstif in jessie?

Hi all, I don't know how many of you still care for the motif widgetset, but due to the way I got involved in Debian, I have kept a small eye on it. Recently ICS [1] release a new version of openmotif, and this time they stuck a LGPL license on it. I think this is good news, as it means that we c

Re: openmotif is now LGPL, retirement of lesstif in jessie?

Hi Graham, On 24-12-12 10:41, Graham Inggs wrote: > The openmotif package has recently been orphaned since the maintainer > is MIA. Not quite, the maintainer said he didn't have time anymore. It is a detail anyway. > I have been working on a new packaging of the LGPL motif from scratch > using d

Re: detailed lists with archive contents - more than just Contents

[You set mail-follow-up to debian-devel, so here it goes to the list.] On 21-02-13 15:48, Helmut Grohne wrote: > So yeah, bug reports, comments and of course patches are welcome. This indeed looks very useful. However, I don't think it is really useful to trigger on common changelog and copyright

bugs.debian.org: something's wrong...

Hi Is it just me or am I the only one getting bug reports from bugs that don't seem to exist on bugs.debian.org. The latest bug that I can find is 703078. The next one [1] fails and after that it says it can not be found. An error occurred. Error was: Bad bug log for Bug 703079. Unable

Re: Partimage: Would it be possible to add EXT4 support..?? (Wheezy x64)

Hi Andre, On 30-03-13 08:47, DutchGlory wrote: > i have a question about Partimage: Would it be possible to add EXT4 > support..?? (Wheezy x64) This is the wrong platform to ask such a question. You should file a wish-list bug against the partimage package if it is not already present. However, t

Re: Bug:#700917: desktop-file-utils: call for (co-)maintainership [ITA]

On 05-05-13 04:30, Dmitry Smirnov wrote: [Disclaimer: I haven't looked at the contents of your concern]. > Since beginning of 2013 I tried to raise concerns about it but got no > reply from current maintainers whatsoever (see #700917). > > I think now would be a good time to upload updated packa

Re: pulseaudio related problems....

Hi all, On 15-02-14 21:11, Russ Allbery wrote: > All I'm saying, and all I think Steve is saying, is that audio not working > out of the box is some kind of bug. That's fine -- software has bugs. We > all know that. It might be an important bug, it might be a normal bug, it > might be a wishlis

Re: pulseaudio related problems....

On 21-02-14 10:57, John Paul Adrian Glaubitz wrote: > On 02/21/2014 09:29 AM, Mario Lang wrote: >> I am sorry, both are not an option for me, since alsamixer is a ncurses >> program, and pavucontrol apparently requires $DISPLAY to be set. >> >> I guess that explains why the accessibility community

Bug#747547: ITP: pasdoc -- documentation tool for Pascal source code

Package: wnpp Severity: wishlist Owner: Paul Gevers -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: pasdoc Version : 0.13.0 Upstream Author : Michalis Kamburelis * URL : http://pasdoc.sipsolutions.net * License : GPL-2+ Programming Lang

Bug#641899: ITP: ebook-speaker -- eBook reader that reads out via synthetic voice

Package: wnpp Severity: wishlist Owner: Paul Gevers -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: ebook-speaker Version : 1.1 Upstream Author : Jos Lemmens * URL : http://web.inter.nl.net/users/lemmensj/ * License : GPL-2+ Programming Lang

Re: Bug#641899: ITP: ebook-speaker -- eBook reader that reads out via synthetic voice

On 09/17/11 11:29, Samuel Thibault wrote: > Paul Gevers, le Sat 17 Sep 2011 11:14:07 +0200, a écrit : >> ebook-speaker is a command-line electronic book reader that reads out eBooks >> using speach synthesis. (Currently only the EPUB format is supported). >> It has a

Re: Reproducible Builds — proof of concept successful for 83% of all sources in main

Hi, I applaud this initiative. On 13-02-15 18:28, Reproducible builds folks wrote: > If you want to help, a first step is to check the reproducibility of > your packages [DDLIST]. Feel free to ask for help on the > mailing list or in > #debian-reproducible on irc.debian.org. It would help me if

Re: Is using experimental distribution for shelter during freeze useful?

Hi, On 27-11-18 12:38, Hideki Yamane wrote: > Well, we use experimental as "shelter" during freeze, but it's not good > in my point of view. > > - During freeze, it is just ignored by most of the users since they >wouldn't know there's a newer package in there (and they also afraid >be

Re: broken packages in unstable

Hi, On 30-11-2018 20:45, Helmut Grohne wrote: > * If archive QA gets painful due to broken packages in unstable: >Ignore those that have no version in testing. It's an easy filter >with little misclassification. That may be true for some QA, but for autopkgtesting of migration candidates

Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)

Hi, On 04-12-2018 20:03, IOhannes m zmölnig (Debian/GNU) wrote: > as mandated by the policy, i'd like to discuss, whether an epoch bump > for the new source package "pd-csound" (to be "2:1.01.0-1") is > warranted, or indeed a good idea. Can at least the source package not carry the any special ep

Re: Conflicting lintian warnings when using debian/tests/control.autodep8 or debian/tests/control

Hi Andreas, On 07-01-2019 11:37, Andreas Tille wrote: > Any idea what to do? File a bug against lintian, it's not perfect you know. If you let me know (maybe in private) the bug number, I may create a merge request for lintian. As the creator of the latter warning and as the one that implemented

Re: Conflict over /usr/bin/dune

Hi all, On 18-01-2019 12:11, Enrico Weigelt, metux IT consult wrote: > On 18.01.19 01:43, Andreas Beckmann wrote: >> On Tue, 18 Dec 2018 17:48:06 + Ian Jackson >> wrote: >>> Ian Jackson writes ("Re: Conflict over /usr/bin/dune"): https://www.google.com/search?q=dune+software https

Re: freeze and security fixes

Hi Jérémy, On 28-02-2019 16:05, Jérémy Lal wrote: > the documentations: > https://release.debian.org/buster/freeze_policy.html > https://www.debian.org/doc/manuals/developers-reference/ch05.html#bug-security > > leave me unsettled about what to do during freeze w.r.t. security > uploads in testi

Re: Support status for isolation-machine feature from Debian Infra?

Hi Mo, On 08-03-2019 12:08, Mo Zhou wrote: > I have two questions given the background: > > (1) What is the support status for "isolation-machine" feature? It's on the todo list, it just that we haven't gotten around to actually do it. Unfortunately it is slightly more complicated that running l

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

Hi Shengjing, On 07-04-2019 03:05, Shengjing Zhu wrote: > This user case may be not enough to change the default choice of GNOME, > but I think this should at least be in release notes. Can you please file a bug against the release-notes package, ideally with a proposed text? Paul signature.a

Re: file(1) now with seccomp support enabled

Hi Christoph, On 19-07-2019 17:18, Christoph Biedl wrote: > tl;dr: The file program in unstable is now built with seccomp support > enabled, expect breakage in some rather uncommon use cases. This probably warrants an entry in the bullseye release-notes. Should we already forward your original ma

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi Lisandro, On 07-07-2019 16:16, Lisandro Damián Nicanor Pérez Meyer wrote: >> All autopkgtest failures considered RC for bullseye >> === >> >> From now on, all autopkgtest failures will be considered release-critical for >> bullseye. So if your pac

Re: pdfproctools: fails to install (conflict with origami-pdf)

retitle 914333 origami-pdf & pdfproctools both ship /usr/bin/pdfmetadata reassign -1 src:origami-pdf,src:pdfproctools thanks On Thu, 22 Nov 2018 09:37:31 +0100 Jacek Politowski wrote: > pdfproctools fails to install due to conflicting "/usr/bin/pdfmetadata" file > which exists also in "origami-pd

reflecting on the buster release cycle and RFF

Dear all, TL;DR: please give your constructive feedback on the buster release period, see the last paragraph. As the most recent member of the release team [1], I thought it could be a useful exercise to reflect on the release process and share it with you. As such a reflection goes, it should s

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi, On 07-08-2019 16:57, Ian Jackson wrote: > Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: > ride like the wind, Bullseye!"): >> No, what I have been perceiving (and pretty please note that this is my >> personal "feeling") is that maintainers, specially library ma

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi, On 18-08-2019 04:46, Lisandro Damián Nicanor Pérez Meyer wrote: >> I can already trigger all the autopkgtests in unstable for packages that >> are in experimental, so if you interested in this, please contact me. > > **Yes please**. This will certainly help *a lot* specially for us that we >

Re: Bits from the Release Team: ride like the wind, Bullseye!

Hi Pirate, and other interested parties, On 09-08-2019 08:22, Pirate Praveen wrote: > On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers wrote: >> I can already trigger all the autopkgtests in unstable for packages >> that >> are in experimental, so if you interested in th

Re: should Debian add itself to https://python3statement.org ?

Hi, On 12-09-2019 17:01, Ian Jackson wrote: > But we need to be clear what's going on and communicate early. Yes, not on the front page, but there is (first bullet): https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#deprecated-components Paul signature.asc Des

Re: security autopkgtests ci

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

Re: security autopkgtests ci

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

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

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

Re: The future of mipsel port

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

Re: debci / salsa ci: support for qemu runner

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

Re: /usr-merge status update + next steps

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

Re: armhf NEON exception for chromium

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

Re: armhf NEON exception for chromium

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

Re: debvm for autopkgtests with multiple host?

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

Re: Illegal Instruction Using sudo in Bookworm on i686

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

Re: Illegal Instruction Using sudo in Bookworm on i686

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

Re: Misc Developer News (#59)

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

Re: Migration blocked

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

Re: Bits from the Release Team: Cambridge sprint update

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

Re: Bits from the Release Team: Cambridge sprint update

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

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

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

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

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

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

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

Re: Wolfram Research Debian Package Submission

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

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

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

Re: Policy: versioning between releases

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

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

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

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

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

Re: Package marked for autoremoval due to closed bug?

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

Re: Package marked for autoremoval due to closed bug?

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

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

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

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

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

Re: Status of the t64 transition

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

Re: Status of the t64 transition

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

Re: Status of the t64 transition

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

Re: Status of the t64 transition

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

Re: new upstream version fails older tests of rdepends packages

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

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

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

Re: new upstream version fails older tests of rdepends packages

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

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

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

Re: About i386 support

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

Re: About i386 support

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

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

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

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

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

Re: About i386 support

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

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

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

Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures

Hi Andreas, On 10-11-2020 13:21, Andreas Tille wrote: > Yes, that's true but its part of my question: Why should all these > tests be run if the dependencies are not available on that architecture. > Wouldn't it be more sane to check dependencies first before running > a test that will fail for s

Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures

Hi Andreas, On 18-11-2020 12:45, Andreas Tille wrote: > On Tue, Nov 10, 2020 at 09:02:56PM +0100, Paul Gevers wrote: >> On 10-11-2020 13:21, Andreas Tille wrote: >>> Yes, that's true but its part of my question: Why should all these >>> tests be run if the depend

Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures

Hi Andreas, On 19-11-2020 08:22, Andreas Tille wrote: >> I have the strong impression that we're talking past each other. The log >> message that you quoted in your initial e-mail said "uninstallable on >> arch *, not running autopkgtest there". This means the test is not >> triggered *and* that f

Re: Epoch version for golang-github-gomodule-redigo-dev?

Hi Michael, On 26-11-2020 08:57, Michael Prokop wrote: > AFAICS we could: > > 1) use 2.0.0+really1.8.3 pattern for our Debian package version As it seems not unreasonable to expect the upstream version to go past 2.0.0 in the not infinite future, this is the approach I would take. Because you as

Re: Epoch version for golang-github-gomodule-redigo-dev?

Hi Holger, On 26-11-2020 10:01, Holger Levsen wrote: > Also I find 1:1.8.3 not ugly at all, for most use cases this is 1.8.3 > so I would go with that. And if someone complains about the 1: epoch > one can always point to the upstream issue explaining why this has > happened. If I recall correctl

Re: Package dependency versions and consistency

Hi, On 19-12-2020 01:25, Josh Triplett wrote: > Given all of the above improvements, it'd be much more feasible for > tooling to help systematically unbundle and package dependencies, and to > help manage and transition those dependencies in the archive. Especially in the JavaScript arena, I thin

  1   2   3   >