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
>
7;s a very
popular OS around here, apart from this problem!).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
y, it would be nice if
the latest packages were fetched (rather installing old ones from the
install media, and upgrading in a later step).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
portant to me, if Debian GNU/Linux (and Ubuntu, Fedora etc.) no longer
worked on them.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Hi Daniel,
I am really sorry to hear this. Back to 2007 we were happy to find
Debian live so that we could create Clonezilla live easily in these
years. It's really sad to see this happening.
Thanks for all your efforts and thanks to all the Debian-live project
members.
Best regards,
S
p7.0/7.0.1-1/ext/standard/random.c/?hl=96#L95
* libsodium too:
https://sources.debian.net/src/libsodium/1.0.3-1/src/libsodium/randombytes/sysrandom/randombytes_sysrandom.c/?hl=52#L267
* openssl uses the strong arc4random on OpenBSD, otherwise falls back
to something that has been... problema
esktop environments, tasks, or OpenJDK for example.
Having a stable set of build-essential packages is important for ports
to get DSA-administered buildds, for developers to be able to run it,
and for the port to progress further.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
ing releases basically;
3. or make it easier somehow for ports to become release arches?
where I think the latter, stable releases, are mandatory to ever have
DSA-administered buildds, which in turn is a requirement for getting
into the official release.
> But it appears like Steven mea
ckages is a requirement for the port to be releaseable. I think
the architecture release criteria is really lacking that kind of detail
to judge ports by. But now, we have a quite good definition of what are
'core' packages of each port, from the rebootstrapping work.
Regards,
--
S
Steven Chamberlain wrote:
> Matthias Klose wrote:
> > [...] when unstable is out of sync, and should be forbidden for a set
> > of core packages from my point of view.
>
> [...] We could say that fixing RC bugs in
> those packages is a requirement for the port to be relea
ge built
in the past, and is "out-of-date" in sid. Otherwise it's not a
release-critical issue, not blocking testing migration).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
if porters are made very aware of the
problems and their implications. I'd like the release team to have a
detailed list of those issues to base their arch qualification on.
I envisage some kind of a scoreboard, graphs, or those weather symbols
we all love to see.
Regards,
--
Steven Chambe
Steven Chamberlain wrote:
> I envisage some kind of a scoreboard, graphs, or those weather symbols
> we all love to see.
As far as the dashboard goes, I've started out with:
https://kfreebsd.eu/dashboards/ports/
I want to add pages per-arch that list the packages that FTBFS,
o
re promimently than
a sid-only, RC-buggy leaf package with an RM bug filed for it.
THat's why I'm trying to design a better dashboard for porters, though
some ideas could be implemented into buildd.d.o itself someday.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
package build or CI tests could help here.
Or, packages build accidentally, then a later version FTBFS. That's why
I thought of auto-removals, but if porters more actively removed those I
think it would be helpful.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
le, this Geode MX is not quite 686-class but has CMOV:
| cpu0: Geode(TM) IntegraTed Processor by National Semi ("Geode by NSC"
586-class) 333 MHz
| cpu0: FPU,DE,PSE,TSC,MSR,CX8,PGE,CMOV,MMX,MMXX,3DNOW2,3DNOW
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Steven Chamberlain wrote:
> I seem to remember last time this was discussed, GNU `as' avoids using a
> particular 686-class instruction
I found a reference for that:
https://lists.debian.org/debian-devel/2015/09/msg00617.html
So it seems the "nearly 686" Geode LX/NX may
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
On Sunday, April 20, 2025 7:50:07 p.m. Central Daylight Saving Time Steven
Robbins wrote:
> I am able to reproduce it thanks to NoisyCoil's hint about
> --aspcud-criteria. I'm working on a fix now.
Okay, I don't know how to solve this. The package is uploaded now for
uns
On Sunday, April 20, 2025 12:18:28 p.m. Central Daylight Saving Time Otto
Kekäläinen wrote:
> Hi,
>
> I am not able to reproduce the test failure visible at
> https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit5&arch=amd64&ve
> r=5.4.3-2&stamp=1745014062&raw=0 in a local build myself, s
Hi,
I recently uploaded a package to experimental and was suprised at the build
failures [1]. I have built it locally and on a porter box without issue --
each time using a clean unstable chroot.
[1] https://buildd.debian.org/status/fetch.php?
pkg=insighttoolkit5&arch=amd64&ver=5.4.3-2&stamp=1
On Monday, April 21, 2025 2:46:27 a.m. Central Daylight Saving Time Johannes
Schauer Marin Rodrigues wrote:
> > I also can't figure out how to examine the chroot after a failure:
> > using "--
> > purge=successful" doesn't work with unshare.
>
> I usually use --anything-failed-commands=%s which
Rob Browning wrote:
>
> I had posted earlier about a problem getting Debian 1.2/1.3 installed
> on a 365x thinkpad. Several solutions were offered and in the end it
> turned out that the people claiming that some thinkpads could not
> handle the bzImage format were correct. It was not the
> "flo
Bruce Perens wrote:
>
> From: Erv Walter <[EMAIL PROTECTED]>
> > Well, i had trouble booting a toshiba tecra with bzImages except via
> > loadlin. The solution was to use a simple zImage instead of the
> > bzImage. Now, lilo, syslinux, etc all work.
>
> I'd rather fix the software bug that prev
Package: wnpp
Severity: wishlist
Owner: "Steven R. Baker" <[EMAIL PROTECTED]>
* Package name: lighttpd
Version : 1.3.13
Upstream Author : [EMAIL PROTECTED]
* URL : http://www.lighttpd.net/
* License : MIT/X
Description : a secure, fas
Package: wnpp
Severity: wishlist
Owner: "Steven R. Baker"
* Package name: rubinius
Version : 1.0.1
Upstream Author : Evan Phoenix
* URL : http://www.rubini.us/
* License : BSD
Programming Lang: C++, Ruby
Description : Rubinius is an impleme
On Tue, Oct 07, 2014 at 10:09:10PM +0200, Matthias Urlichs wrote:
> Adam Borowski:
> > > The only acceptable concrete value for 'extremely few' is Zero.
> >
> > I'd say losing patience is quite understandable in this case
>
> Probably. However, the context of this thread was not at all about a
>
Further versions of this proposal will be posted on the WWW, and the address
of such revisions will be posted to both -devel and -dpkg.
Okay, I posted to -devel a few weeks back with a proposal for an update to dpkg.
This message is being Cc'd to -devel, and sent to -dpkg.
Basically, attached is my proposal (it's long, I'm trimming it down in another
rxvt, but, I wanted to get something out for the firing sqaud). Please read it
Okay, after discussing this with a few people on #debian, and going over email,
it seems that a) I am not qualified nor familiar with dpkg internals enough to
do a project such as this, and did not realize it at first and b) too much of
dpkg would have to be severly hacked and re-written.
So, if
I have clicked unsubscribe many times.
Daniel, you are a deeply disturbed human being. Please stop sending me emails.
I hope you find the help you need.
Skickat från min iPhone
> 19 mars 2022 kl. 18:28 skrev Daniel Pocock :
>
>
> Felix, Hideki, Jonathan,
>
> The message was sent to you all
101 - 156 of 156 matches
Mail list logo
