Hi,
Please CC me in any reply.
A new googletest package for 1.13.0 just hit unstable and I now realise it
requires at least C++14. From autopkgtests, I noted at least one build
failure because of this.
I'm hoping most code can simply opt to build at C++14 or later. However, I'm
willing to
Package: wnpp
Severity: wishlist
Owner: "Steve M. Robbins"
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org
* Package name: ubpm
Version : 1.9.0
Upstream Contact: Thomas Löwe
* URL : https://codeberg.org/LazyT/ubpm
* License : GPL v3
On Saturday, December 16, 2023 12:23:46 P.M. CST Paul Gevers wrote:
> Another topic we covered is the volume and purpose of our mail list
> (debian-devel@lists.debian.org). We recognize that that list mostly just
> mirrors BTS traffic. The BTS already archives all information, and there are
> mult
Peter convincingly argues (details in bug) that manual intervention is needed
for package "cargo":
On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green
wrote:
> This will require manual intervention to resolve, either through
> cross-building or through building manually in a hacked-up build
On Tuesday, March 12, 2024 1:24:25 A.M. CDT Steve Langasek wrote:
> The quickest fix for this based on what we've done in Ubuntu is:
>
> - unpack cargo and libstd-rust debs to the root via dpkg-deb -x
> - use equivs to mock up packages by these names with no dependencies and
> install those
> -
According to the "action needed" section for nifticlib [1], it is:
Marked for autoremoval on 31 March: #1063178
But that bug is fixed for the version in unstable.
Why does that cause the package to be removed?
[1] https://tracker.debian.org/pkg/nifticlib
Thanks,
-Steve
signature.asc
Descrip
This recent transition has really illuminated how little I know of the dark
corners of Debian infrastructure...
Some packages (e.g. libcdk5/experimental) aren't buildable on the armel/armhf
because the build-deps don't install, and in particular:
The following packages have unmet dependencies:
Wondering about the current state of this transition. Is there a tracker of
any kind for this? Or would someone be willing to post an email here
periodically? Weekly maybe?
I looked at the release goals wiki and at the "brain dump" page but failed to
find anything dated more precisely than "
The excuses page says it is good to go, but it hasn't migrated despite being 7
days past the required 5 days. What's up?
Excuse for nifticlib
Migration status for nifticlib (2.0.0+git186-g84740c2-1 to 3.0.1-4): Will
attempt migration (Any information below is purely informational)
Additional i
Hi,
I've built the ITK package on my AMD64 machine without trouble, but the 32-bit
build is failing with the error below.
The errors seem to point to using SSE instructions. Is there a recommended
set of flags to use when building for x86? I tried "-march=i686" but it gives
the same error.
Thank you Andrey!
> For example, in this case it's not about compilation flags because the
> relevant code uses SSE2 explictly when USE_SSE2_32IMPL is set. I haven't
> checked how is it set but the configure step output suggests it checks the
> hardware support on the build machine, which must not
Thanks for the pointer to https://wiki.debian.org/
ArchitectureSpecificsMemo#Architecture_baselines.
I read there that "Each Debian architecture has a baseline indicating the
oldest or least capable CPU on which the architecture can be used. The
baseline can change between Debian releases. The b
Luca Boccassi wrote:
> Personally, I'd even go for option 4, so that other drivers are covered
> too (the general advice that can be found on the internet for users
> with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc",
> which is just a sad state of affairs). But option 5 is alre
The list at https://db.debian.org/machines.cgi suggests all available machines
are "buildd" and restricted.
I need to debug a build problem that appears only on mips64el. And only since
the new glibc. Is there any known issues with the new glibc on mips64el?
Thanks,
-Steve
signature.asc
D
On Monday, August 22, 2022 1:29:13 A.M. CDT Nilesh Patra wrote:
> On Mon, Aug 22, 2022 at 08:08:30AM +0200, Sebastiaan Couwenberg wrote:
> > On 8/22/22 07:15, Steve Robbins wrote:
> > > Oh. I did use Eller -- but the architecture is listed as mipsel. I need
> > > mips64el>
> > eller has mips64el
Hi,
After the recent spate of rebuilds for the new glibc, I had a couple packages
fail in their respective post-build test suite. For one package, the buildd
failure went away after a rebuild. The second package, libminc, however
failed on the buildd as recently as yesterday.
https://buildd.
Commonly, I update a package that provides a shared library. Due to the
package naming convention, a new SOVERSION necessitates a trip through NEW,
which in turn means a binary upload.
The binary upload cannot transition to testing -- a buildd binary build is
required. So far as I know -- ass
On Tuesday, August 23, 2022 6:56:32 P.M. CDT Nilesh Patra wrote:
> On 24 August 2022 3:29:10 am IST, Steven Robbins wrote:
> >The binary upload cannot transition to testing -- a buildd binary build is
> >required. So far as I know -- assuming [1] is still up-to-date, this mean
Paul Said:
> On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote:
> > Specficially: in the case of a NEW binary upload, could a manual request
> > be
> > implemented (pick a different name if "give back" is not suitable) such
> > that it is thrown away an
Suddenly half the packages are marked AUTOREMOVE; many due to gcc-12 and zlib.
The related two bugs are months-old.
Why are things suddenly being removed??
Thanks,
-Steve
signature.asc
Description: This is a digitally signed message part.
Hi,
When I first started with Debian many many years ago, I would routinely see
email for bug reports submitted against packages I maintain, and responses to
said bugs. Nowadays I get essentially none of that. The only way I see such
responses is by perusing bugs via the web interface -- whic
On Sunday, September 25, 2022 3:49:37 P.M. CDT Geert Stappers wrote:
> On Sun, Sep 25, 2022 at 03:42:40PM -0500, Steven Robbins wrote:
> > I just noticed today that this applies even to responses that apparently
> > directly CC my debian address; e.g. https://bugs.deb
Thanks to all who responded. I have learned a lot!
On Sunday, September 25, 2022 4:57:19 P.M. CDT Russ Allbery wrote:
> Steven Robbins writes:
> > To re-iterate: mail sent today to my debian address from outside debian
> > came through OK. Mail sent from bugs.debian.org appa
Hello,
I have two monitors connected to my linux desktop. One of them is sitting on
an HDMI switch as it is shared with a laptop. For months, this worked just
fine: when I switched the monitor to the laptop, linux would notice that only
one monitor was connected and adjust; when I later switc
I'm not receiving messages concerning bugs for most of the packages I
maintain. Most of my packages are team-maintained, so my email appears only
as the Uploader, not the Maintainer. I am beginning to suspect this is the
cause of missing emails. Is it? Is there a global method to inform bts
On Saturday, February 22, 2020 10:15:28 A.M. CST Steven Robbins wrote:
> I'm not receiving messages concerning bugs for most of the packages I
> maintain. Most of my packages are team-maintained, so my email appears only
> as the Uploader, not the Maintainer. I am beginning to s
On Tuesday, September 15, 2020 11:18:28 P.M. CDT Andreas Tille wrote:
> Hi Paul,
>
> On Tue, Sep 15, 2020 at 10:00:45PM +0200, Paul Gevers wrote:
> > On 14-09-2020 21:04, Andreas Tille wrote:
> > > In the case of larger data sets it seems to be natural to provide the
> > > data in a separate binar
On Thursday, September 17, 2020 3:07:23 P.M. CDT Thomas Goirand wrote:
> On 9/16/20 2:55 PM, Steven Robbins wrote:
> > Since you're soliciting opinions, here's mine. In the absence of a
> > documented consensus, ftpmaster should respect the packager's judgement
>
I pushed an update ("dput digikam_8.4.0-4_source.changes") ten hours ago to
ftp.upload.debian.org and dput reported success. But there has been no email
acknowledgement nor change to the archive that I can spot.
Is everything working?
-Steve
signature.asc
Description: This is a digitally sig
I've come to realise the ITK build has 15 libraries that lintian flags with
error library-not-linked-against-libc.
https://lintian.debian.org/tags/library-not-linked-against-libc.html[1]
The error description seems straightforward. But how does one solve this? I
have to
assume that the lin
On Saturday, January 25, 2025 10:57:26 P.M. CST you wrote:
> I've come to realise the ITK build has 15 libraries that lintian flags with
> error library-not-linked-against-libc.
Someone suggested to run ldd -r. Okay, so what does this tell me?
$ ldd -r /lib/x86_64-linux-gnu/libITKColormap-5.4.so
31 matches
Mail list logo