Re: new upstream version fails older tests of rdepends packages
Hi Bill On Wed, 8 May 2024 at 13:58, Bill Allombert wrote: > The problem is that all the debs in testing and sid are correct, it is the > autopkgtest in > testing which are wrong (they are relying on undocumented behaviour). > They are fixed in sid. I think an upload of gap, with Breaks on the versions of the gap-* packages that are wrong, should allow migration. Regards Graham
Re: guile-gnutls not picked up by sid autobuilders
Hi Andreas On Sat, 12 Aug 2023 at 05:15, Andreas Metzler wrote: > guile-gnutls was uploaded almost a week ago to sid, but the unstable > autobuilders seem to ignore it. > https://buildd.debian.org/status/package.php?p=guile-gnutls > > Is there anything I can do? The experimental uploads were picked up > seamlessly. If you look at the log view, you can see the build was picked up and failed: https://buildd.debian.org/status/logs.php?pkg=guile-gnutls&arch=amd64 Regards Graham
Re: Proposed MBF - removal of pcre3 by Bookworm
Hi Matthew On Thu, 29 Jun 2023 at 20:18, Matthew Vernon wrote: > Bookworm is now out; I will shortly be increasing the severity of the > outstanding bugs to RC, with the intention being to remove src:pcre3 > from Debian before the trixie release. Thanks for driving this forward! There's a transition tracker [1] which might be helpful. Regards Graham [1] https://release.debian.org/transitions/html/pcre3-to-pcre2.html
Re: SONAME bumps (transitions) always via experimental
Hi All On Fri, 6 Jan 2023 at 00:33, Bastian Blank wrote: > However, please describe an actionable plan. What do you want to be > rejected, in a codified form. > > It would be nice if you could provide a patch for process-new that > displays this information. Would it be a bad thing to require all uploads that need to go through NEW (source and binary) to target experimental? I have been doing this for my own, and sponsored, uploads for some years already. There's usually some reason for another upload after acceptance anyway; e.g. source upload for arch:all, breaking changes in toolchain or other dependencies, symbols file needs tweaking, autopkgtest needs tweaking, bump Standards-Version, update debian/copyright years, etc. Regards Graham
Re: Porter roll call for Debian Bookworm
Hi YunQiang Su On Sun, 26 Dec 2021 at 11:17, YunQiang Su wrote: > > For mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues > - triage arch-specific bugs > - fix arch-related bugs > - triage d-i bugs > - test d-i regularly > - fix d-i bugs/issues > - maintain buildds > - maintain/provide hardware for (or assist with) automated tests on ci.d.n, > jenkins.d.n (etc.) > > I am a DD. Thanks for your response! In case #1000435 (matplotlib crashes on mips64el) is not already on your radar, would you please take a look? Regards Graham
Re: Porter roll call for Debian Bookworm
Hi A friendly reminder about the porter roll call for bookworm. On Sat, 2 Oct 2021 at 11:57, Graham Inggs wrote: > We are doing a roll call for porters of all prospective release > architectures. If you are an active porter behind one of these > architectures [1] and intend to continue for the development cycle of > Debian Bookworm (est. release mid-2023), please respond with a signed > email containing the following before Saturday, January 1, 2022: Please note we don't automatically assume that porters for previous releases will continue to do so. If you were a porter for a previous release, we'd like you to sign up again for bookworm. Please refer to the architecture requalification page [1] for the current status. Graham, on behalf of the release team [1] https://release.debian.org/bookworm/arch_qualify.html
Porter roll call for Debian Bookworm
Hi We are doing a roll call for porters of all prospective release architectures. If you are an active porter behind one of these architectures [1] and intend to continue for the development cycle of Debian Bookworm (est. release mid-2023), please respond with a signed email containing the following before Saturday, January 1, 2022: * Which architectures are you committing to be an active porter for? * Please describe recent relevant porter contributions. * Are you running/using Debian testing or sid on said port(s)? * Are you testing/patching d-i for the port(s)? Please note that no response is required for amd64 because our toolchain maintainers are happy to support amd64 as-is. Feel free to use the following template as your reply: """ Hi, I am an active porter for the following architectures and I intend to continue for the development cycle of Debian Bookworm (est. release mid-2023): For , I [delete/modify as appropriate] - test (most|all) packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) - run other automated tests outside the Debian QA services (Please describe these) - ... """ Graham, on behalf of the release team [1] https://release.debian.org/bookworm/arch_qualify.html
Re: Porter roll call for Debian Bullseye
Hi A friendly reminder about the porter roll call for bullseye. On Mon, 2 Nov 2020 at 22:23, Graham Inggs wrote: > We are doing a roll call for porters of all release architectures. If > you are an active porter behind one of the release architectures [1] > for the entire lifetime of Debian Bullseye (est. end of 2024), please > respond with a signed email containing the following before Friday, > November 27: Please note we don't automatically assume that porters for previous releases will continue to do so. If you were a porter for a previous release, we'd like you to sign up again for bullseye. Please refer to the architecture requalification page [1] for the current status. Graham, on behalf of the release team [1] https://release.debian.org/bullseye/arch_qualify.html
Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
Hi On Mon, 9 Nov 2020 at 22:06, Vagrant Cascadian wrote: > Given no objections or concerns of any kind raised in the last two > weeks, I've submitted a bug against dpkg: > > https://bugs.debian.org/974087 There was a query from one of our upstreams in #972294 to which I have not seen a response. Regards Graham
Porter roll call for Debian Bullseye
Hi We are doing a roll call for porters of all release architectures. If you are an active porter behind one of the release architectures [1] for the entire lifetime of Debian Bullseye (est. end of 2024), please respond with a signed email containing the following before Friday, November 27: * Which architectures are you committing to be an active porter for? * Please describe recent relevant porter contributions. * Are you running/using Debian testing or sid on said port(s)? * Are you testing/patching d-i for the port(s)? Please note that no response is required for amd64 because our toolchain maintainers are happy to support amd64 as-is. Also note that this waiver no longer applies for i386, where it did in previous releases. Feel free to use the following template as your reply: """ Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Bullseye release (est. end of 2024): For , I - test (most|all) packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) - run other automated tests outside the Debian QA services (Please describe these) - ... """ Graham, on behalf of the release team [1] https://release.debian.org/bullseye/arch_qualify.html
Re: Mass bugs filing: autopkgtest should be marked superficial
Hi Raphael On Thu, 17 Sep 2020 at 09:18, Raphael Hertzog wrote: > Please reduce the severity of all the bugs that you opened to "normal" > or "minor". Why? Regards Graham
Re: Uploading of libjpeg-turbo 2.0.x to unstable
Hi Mike On Tue, 14 Jan 2020 at 09:44, Mike Gabriel wrote: > Simply uploading and waiting for things to break (at runtime) is > neither a good approach, I sense. I have done some usual smoke tests > (running this and that desktop environment, viewing JPEG images, > etc.), but that feels insufficient. Autopkgtests are now run for packages in experimental, see: https://release.debian.org/britney/pseudo-excuses-experimental.html#libjpeg-turbo This tells you what would break if libjpeg-turbo were uploaded to unstable. It looks like only vtk6/vtk7 have a problem: autopkgtest for vtk6/6.3.0+dfsg2-5: amd64: Regression autopkgtest for vtk7/7.1.1+dfsg2-1: amd64: Regression Regards Graham
Re: @debian.org mail
Hi On 2019/06/03 10:40, Daniel Lange wrote: We (debian/DSA) do not provide email hosting. We provide email forwarding. DSA should re-evaluate that. I strongly support this. I recall this being an issue during debconf 15 and 16 orga, and the situation has only gotten worse since. To do better, we should really offer SMTP submission/IMAP services for @debian.org as soon as possible and - after a grace period - publish a mx -all SPF record. I would certainly make use of SMTP for sending @debian.org email. I can't see the advantage of IMAP over forwarding though, would you explain how you see it working, or who would use it? Regards Graham
Re: Handling Japanese new era "令和 (Reiwa)"
On 2019/05/22 13:48, Alastair McKinstry wrote: No, to my knowledge 12.1.0~pre-1 is close enough (containing "Reiwa"). Unless someone can point to issues requiring it, Its not worth getting everything else rebuilt. Ah OK, thanks. There's probably no need for utf8proc 2.4.0 then either.
Re: Handling Japanese new era "令和 (Reiwa)"
Hi Alastair Also, I plan to push 12.1.0~pre-1 from experimental to unstable. Do you still plan to upload unicode-data 12.1? Utf8proc 2.4.0, updated for unicode 12.1, has been released and we'd like to get that version in. Is anyone aware of any other bits outstanding? Regards Graham
Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED
Hi Bastian On 2018/11/21 16:11, Bastian Blank wrote: I have not seen a real explanation why it needs to be this and exactly this way. This setup was explained as either - a workaround for a bug, - a way to get stacktraces from users or - a way to make autopkgtest run. Stripping sys.so breaks one of Julia's language features, which is the ability to trace into its standard library. An example [1] is found in the documentation. One of Julia's tests checks this, and hence autopkgtests fail if debug symbols are missing from sys.so, which is compiled from .jl scripts, not C/CXX source. We could strip sys.so and create a manual debug symbols package, but in order to make the Debian package have the same features as upstream, we would make the Julia package depend on it. We would prefer to ship sys.so unstripped, but if you insist on having an extra binary package in the archive in order to silence Lintian, we will do it. Regards Graham [1] https://docs.julialang.org/en/v1.0.0/manual/stacktraces/
Re: julia_1.0.0-1_amd64.changes REJECTED
Hi Bastian
My apologies in advance for doing this, but another month has passed.
Another ping from me.
On 2018/10/25 12:24, Ian Jackson wrote:
Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
Lumin writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
1. Isn't "incomplete backtrace" a sensible reason to keep debug symbols?
Policy said "should" but not "must". Please tell me what I can do in
order to help improve the src:julia package to satisfy the requirements?
My main concern here is this: AFAICT this package has been REJECTed
solely for this reason. Why is this bug[1] a reason for a REJECT ?
ISTM that it should be filed in the BTS and handled like a normal bug.
Ping, ftpmaster ?
Ian.
[1] Assuming it is a bug. The discussion here suggests to me that it
is, but it is really unhelpful to be having it on debian-devel in the
context of an ftpmaster REJECTion.
From the original REJECTion email from mid-August [1], there were two
issues, but I believe both have been explained in the follow-up emails
and subsequent uploads.
Regards
Graham
[1]
https://alioth-lists.debian.net/pipermail/pkg-julia-devel/Week-of-Mon-20180813/001840.html
Re: julia_1.0.0-1_amd64.changes REJECTED
Hi Bastian Sorry, I've just noticed my 'Reply All' email went to ftpmaster@ but not waldi@, so I assume you missed it. Please let me (and Lumin) know if you have any further concerns. Also, there have been two further julia uploads since my last email. Regards Graham On Wed, 26 Sep 2018 at 12:52, Graham Inggs wrote: > > Hi Bastian > > I sponsored Lumin's original upload of Julia 1.0.0-1 and worked with him > closely, reviewing the commits leading up to the upload. In the > meantime, Lumin has become a Debian Developer and uploaded the > subsequent versions himself, although still with some input and testing > from me. > > I thought Lumin had made it clear enough that being able to obtain a > stacktrace from within Julia is actually a feature [1]. One of Julia's > tests checks this, and hence autopkgtests fail if debug symbols are > missing from sys.so, which is compiled from .jl files, not C/CXX source. > > However, Lumin has now updated the comments in debian/rules [2] to be > more explicit. > > For reference, the RM bug Lumin referred to in his previous mail is #903548. > > Regards > Graham > > > [1] https://docs.julialang.org/en/v1.0.0/manual/stacktraces/ > [2] > https://salsa.debian.org/julia-team/julia/commit/e7295f3eddffa8bd525145e8be245d9722c25479 >
Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED
Hi Andrey On 26/09/2018 13:13, Andrey Rahmatullin wrote: It's not clear why the debug symbols are necessary to be in the binary and not detached as with most other binaries in the archive. I believe the debug symbols can be detached, but we would still need to depend on them, so I don't think it worth be worth creating a separate debug package. Regards Graham
Re: julia_1.0.0-1_amd64.changes REJECTED
Hi Bastian I sponsored Lumin's original upload of Julia 1.0.0-1 and worked with him closely, reviewing the commits leading up to the upload. In the meantime, Lumin has become a Debian Developer and uploaded the subsequent versions himself, although still with some input and testing from me. I thought Lumin had made it clear enough that being able to obtain a stacktrace from within Julia is actually a feature [1]. One of Julia's tests checks this, and hence autopkgtests fail if debug symbols are missing from sys.so, which is compiled from .jl files, not C/CXX source. However, Lumin has now updated the comments in debian/rules [2] to be more explicit. For reference, the RM bug Lumin referred to in his previous mail is #903548. Regards Graham [1] https://docs.julialang.org/en/v1.0.0/manual/stacktraces/ [2] https://salsa.debian.org/julia-team/julia/commit/e7295f3eddffa8bd525145e8be245d9722c25479
Re: autopkgtest results influencing migration from unstable to testing
On 07/06/2018 15:33, Pirate Praveen wrote: On June 6, 2018 12:45:55 PM GMT+05:30, Pirate Praveen wrote: Thanks everyone, I have added breaks now. But even now it added 10 days delay. It looks like the test on 2018-06-07 12:22:45 UTC was successful [1]. Maybe give the tracker page a little while to refresh? [1] https://ci.debian.net/packages/r/ruby-state-machines-activemodel/testing/amd64/
Re: autopkgtest results influencing migration from unstable to testing
On 6 June 2018 at 06:58, Pirate Praveen wrote: > I think we need to handle cases like this, > > https://tracker.debian.org/pkg/ruby-state-machines > > ruby-state-machines and ruby-state-machines-activemodel should go > together and even when autopkgtest for the version is unstable passed, > instead of reducing the age, it is considered a regression because > autopkgtest for the version in testing failed and age is increased. > > I think in cases where version differs in testing and unstable, > regression in testing should not delay migration. Won't adding appropriate Breaks handle this already?
Re: Bug#860170: node-brfs -- browserify fs.readFileSync() static asset inliner
On 14 April 2017 at 17:06, Jonas Smedegaard wrote: > Quoting The Wanderer (2017-04-14 15:46:53) >> At a guess, probably "herb", which is commonly pronounced without the >> initial aspirant even in dialects (etc.) which ordinarily don't elide >> such. > > Thanks for educating me: I thought the "h" in "herb" wasn't silent. In America the "h" is normally silent, but in Britain and South Africa it is normally pronounced. > A probably more common example (in computer context) is "hour". A more global example, for sure.
Bug#842491: ITP: dfcgen-gtk -- Digital Filter Coefficients Generator (DFCGen) GTK+
Package: wnpp Severity: wishlist Owner: Graham Inggs X-Debbugs-CC: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: dfcgen-gtk Version : 0.4 Upstream Author : Ralf Hoppe * URL : http://www.dfcgen.de * License : GPL-2.0 Programming Lang: C Description: Digital Filter Coefficients Generator (DFCGen) GTK+ DFCGen, the Digital Filter Coefficients Generator, assists the engineer in the design of digital filters. It supports the engineer in analysis and synthesis of linear time-invariant time-discrete (LTI) systems from the theoretical point of view. It performs generation of system transfer function coefficients in the Z-domain, based on the type and specific parameters of a chosen system. I intend maintaining this package within debian-science.
Re: package builds crashing under fakeroot
Control: tags 837915 help Hi! On 25/09/2016 13:21, Michael Banck wrote: as I just diagnosed this for a different package: the problem appears to be that mpirun is run during binary-arch, i.e. under fakeroot. Latest openmpi does not like that apparenlty and crashes. Not sure how to fix it for aster as apparently building the elements catalog is part of the upstream install run. Maybe the upstream build system can be modified to build that catalog during build, not install? I'm not really familiar with aster's build system. I happened to upload the last NMU in order to fix a build with PETSc. Any help would be appreciated. Regards Graham
Fwd: Trilinos: to split or not to split?
Hi All
Nico and Felix are seeking guidance on whether to split the Trilinos
binary packages so that each installs a single shared library or
whether to lump them all together, as was done in the previous
packaging (trilinos 10.4.0.dfsg-1, RM'd 2012-05-15). Policy advises
"When in doubt, always split shared library packages so that each
binary package installs a single shared library" [1]. Their current
packaging [2] is split into 90+ pacakges.
Please keep Nico and Felix CC'd as I don't believe they are subscribed
to this list.
Regards
Graham
[1]
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime
[2]
http://anonscm.debian.org/cgit/debian-science/packages/trilinos.git/tree/debian/control
-- Forwarded message --
From: Nico Schlömer
Date: 24 September 2015 at 11:17
Subject: Trilinos: to split or not to split?
To: ftpmas...@debian.org
Cc: Debian Science List , Graham
Inggs , Felix Salfelder
Hi everyone,
Graham, Felix, and I are just looking into packaging Trilinos [1] for
Debian (again [2]). The structure of Trilinos similar to boost in that
it consists of a few dozen "packages".
We're now trying to figure out if it's best to ship all of Trilinos in
one target (e.g., libtrilinos{-dev}) or to split it up along the
packages (libtrilinos-{belos,amesos,ml,...}{-dev}). In the current
version [3], we're doing the latter.
Some numbers:
```
$ ls libtrilinos-*12.2.1*.deb | wc -l
90
$ du -s libtrilinos-*12.2.1*.deb | cut -f1 -d' ' | sort -h | tail -n 10
912
924
1064
1096
1376
1568
1944
2644
2960
7596
$ for i in libtrilinos-*12.2.1*.deb; do dpkg -I $i | grep Installed-Size | \
cut -d' ' -f3 ; done | sort -h | tail -n 10
4865
4913
5005
7171
7566
10682
12912
19051
20403
47295 # <= I guess, this means 47MB
```
Is there a Debian policy on this? What's your opinion?
Cheers,
Nico
[1] https://trilinos.org/
[2] https://tracker.debian.org/pkg/trilinos
[3] alioth:/git/debian-science/packages/trilinos.git
Bug#790803: ITP: neural -- machine-learning for atomistics
Package: wnpp Severity: wishlist Owner: Graham Inggs X-Debbugs-CC: debian-devel@lists.debian.org * Package name: neural Version : 1.0 Upstream Author : Andrew Peterson, Alireza Khorshidi * URL : https://bitbucket.org/andrewpeterson/neural * License : GPL-3.0+ Programming Lang: Python Description : Machine Learning for Atomistics Neural is an open-source code designed to easily bring machine-learning to atomistic calculations. This allows one to predict (or really, interpolate) calculations on the potential energy surface, by optimizing a neural network representation of a "training set" of atomic images. The code works by learning from any other calculator (usually DFT) that can provide energy as a function of atomic coordinates. In theory, these predictions can take place with arbitrary accuracy approaching that of the original calculator. . Neural is designed to integrate closely with the Atomic Simulation Environment (ASE). As such, the interface is in pure python, although several compute-heavy parts of the underlying code also have fortran versions to accelerate the calculations. The close integration with ASE means that any calculator that works with ASE ─ including EMT, GPAW, DACAPO, VASP, NWChem, and Gaussian ─ can easily be used as the parent method. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cam8zjqs+c4kmo1ybop3snfoqp3nv6wx8wkk4zo5ysya+j76...@mail.gmail.com
Bug#728676: ITP: ddrescueview -- Graphical viewer for GNU ddrescue log files
Package: wnpp Severity: wishlist * Package name: ddrescueview Version : 0.4 Upstream Author : Martin Bittermann * URL : http://ddrescueview.sourceforge.net/ * License : GPL-3.0+ Programming Lang: Object Pascal / Lazarus Description : Graphical viewer for GNU ddrescue log files This small tool allows the user to graphically examine ddrescue's log files in a user friendly GUI application. The Main window displays a block grid with each block's color representing the block types it contains. Many people know this type of view from defragmentation programs. . GNU ddrescue [1] is a data recovery tool, already packaged in Debian as gddrescue [2]. . The ddrescueview package will be maintained by the Debian Pascal packaging team and a git repository has already been created on Alioth [3]. [1] http://www.gnu.org/software/ddrescue/ddrescue.html [2] https://packages.qa.debian.org/g/gddrescue.html [3] http://anonscm.debian.org/cgit/pkg-pascal/ddrescueview.git Regards Graham -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAM8zJQvv=YAwqhpr6B+gFXvq2T9f=ik2pc9xfdeffwfo6sd...@mail.gmail.com
Re: openmotif is now LGPL, retirement of lesstif in jessie?
Hi Paul Paul Gevers debian.org> writes: > > 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. My apologies, I assumed the package becoming orphaned was a result of me emailing the MIA team back in September. > > I have been working on a new packaging of the LGPL motif from scratch > > using dh. > > Why from scratch? Take the good things from the current package, but > indeed, I would like to switch to dh(1) as well. I am currently working > on getting the current package fit for multiarch and hardening enabled. I started from scratch by switching to dh, and then then used what was still required from the existing packages in Debian and Ubuntu. The results of my efforts have now been published here: https://launchpad.net/~ginggs/+archive/ppa > > I would like to see the openmotif package renamed to motif > > What do others on this list think? I think openmotif as the source > package name is a fine, but I don't really care. The only thing that I > like about keeping the name is that the history of the package is better > linked in the PTS and such. My feeling is that "openmotif" as such, no longer exists. > I do appreciate your effort, but currently Joël Bertrand is the one in > the orphan bug [1], stating his intent to adopt (although he forgot to > retitle and own the bug). I proposed to him (no response yet) to make > this a team effort, do you want to join? I really would like to get the > packaging in a VCS, e.g. on Alioth in the collab-maint project. I would be happy to join a team effort. Regards Graham -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20121226t004915...@post.gmane.org
Re: openmotif is now LGPL, retirement of lesstif in jessie?
Hi All The openmotif package has recently been orphaned since the maintainer is MIA. I have been working on a new packaging of the LGPL motif from scratch using dh. I would like to see the openmotif package renamed to motif and replace lesstif in jessie. My motif package will be available in my Ubuntu PPA within the next day or two: https://launchpad.net/~ginggs/+archive/ppa Regards Graham -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20121224t103452-...@post.gmane.org
