On Wed, Sep 04, 2024 at 12:28:35PM +0200, Vincent Lefevre wrote:
On 2024-09-04 11:15:26 +0200, Chris Hofstaedtler wrote:
On Mon, Sep 02, 2024 at 11:15:19AM -0400, Michael Stone wrote:
> On Mon, Sep 02, 2024 at 01:07:59PM +0200, Vincent Lefevre wrote:
> > Severity: grave
> >
severity 1080330 normal
stop
On Mon, Sep 02, 2024 at 01:07:59PM +0200, Vincent Lefevre wrote:
Package: coreutils
Version: 9.4-3.1
Severity: grave
Justification: renders package unusable
That's a ridiculous severity/rationale
On Fri, Aug 16, 2024 at 04:54:02PM +0100, Colin Watson wrote:
Quite. If nothing else, I think the code actually in the Debian archive
that relies on the old path ought to be changed _first_, e.g. via an
MBF. I see a bunch of cases that are relatively subtle and might suck a
lot of other people'
The first time I rebooted after iproute2 removed the /sbin/ip link, my system
failed to boot. I eventually discovered this was because /sbin/vconfig (from
the "vlan" package) calls /sbin/ip and when that failed the network was not
configured. This meant having to boot into single user mode for dia
Package: iproute2
Version: 6.10.0-1
Severity: critical
Justification: breaks the whole system
The first time I rebooted after iproute2 removed the /sbin/ip link, my system
failed to boot. I eventually discovered this was because /sbin/vconfig (from
the "vlan" package) calls /sbin/ip and when that
On Mon, Jan 29, 2024 at 04:11:05PM +, Pádraig Brady wrote:
You've introduced a silent incompatibility and I'm trying to find some
way to make that clear. If upstream would provide a better solution I
would certainly use it. I have despaired of there being such since your
attitude thus far see
On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote:
I'm not sure reverting would be best. It would introduce more
confusion, and would make coreutils incompatible with FreeBSD again.
Reverting makes more sense than the current situation. I do not
understand why you seem to value FreeB
On Sun, Dec 17, 2023 at 12:34:11AM -0800, Paul Eggert wrote:
On 2023-12-16 13:46, Bernhard Voelker wrote:
Whether the implementation is race-prone or not is an internal thing.
I wasn't referring to the internal implementation. I was referring to
cp users. With the newer Coreutils (FreeBSD) be
On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:
Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less race-prone.) It seemed
like a good idea at the
that's because it has not yet been widely deployed, which
makes now the time to fix it.
Michael Stone
the
old behavior. I am reluctant to do so as that will likely lead to
divergent behavior between distributions, but breaking scripts without a
compelling reason is also not good. I would encourage coreutils to
reconsider the change and finding a non-breaking way forward.
Michael Stone
On Tue, Nov 01, 2022 at 10:59:11AM +0300, Michael Tokarev wrote:
And this revealed one more issue here, now with samba 4.17. Where, the
same libndr.so again, has changed soname from libndr.so.2 to libndr.so.3!
And it looks like *this* is what you're talking about now, once 4.17 with
this new li
Package: sssd-ipa
Version: 2.7.4-1+b1
Severity: critical
Justification: breaks the whole system
After upgrade of samba-libs syslog has messages like
... sssd[448823]: /usr/libexec/sssd/sssd_pac: error while loading shared
libraries: libndr.so.2: cannot open shared object file: No such file or
d
On Thu, Jun 09, 2022 at 10:11:19AM +0300, you wrote:
Timo Aaltonen kirjoitti 9.6.2022 klo 9.51:
Michael Stone kirjoitti 8.6.2022 klo 18.52:
On Wed, Jun 08, 2022 at 05:41:00PM +0300, Timo Aaltonen wrote:
Did you have 2.7.0 at some point?
2.7.0-1 was installed 2022-05-27
2.7.0-1+b1 was
On Wed, Jun 08, 2022 at 05:41:00PM +0300, Timo Aaltonen wrote:
Did you have 2.7.0 at some point?
2.7.0-1 was installed 2022-05-27
2.7.0-1+b1 was installed 2022-05-29
no issues with either of those; I reverted to 2.6.3 just because it was
easier to grab from the mirrors.
Package: sssd
Version: 2.7.1-1
Severity: critical
Justification: breaks the whole system
Installing sssd 2.7.1-1 causes IPA/krb5 authentication to fail with messages
such as the following in /var/log/sssd/sssd_DOMAIN.log
(2022-06-07 18:31:36): [be[DOMAIN]] [krb5_auth_done] (0x3f7c0): [RID#10] Th
On Wed, Feb 09, 2022 at 04:32:43PM -0500, Scott Kitterman wrote:
On Sat, 5 Feb 2022 17:28:04 -0500 Michael Stone wrote:
It seems to be some kind of incompatibility in swig. Upstream .cc files
are built with swig 3, debian has swig 4. If the package is built with
the upstream .cc files
It seems to be some kind of incompatibility in swig. Upstream .cc files
are built with swig 3, debian has swig 4. If the package is built with
the upstream .cc files (ditching the associated lines in debian/rules)
it seems to work fine.
Package: python3-subnettree
Version: 0.33-1+b3
Severity: grave
Justification: renders package unusable
Documentation says:
A simple example which associates CIDR prefixes with strings::
>>> import SubnetTree
>>> t = SubnetTree.SubnetTree()
>>> t["10.1.0.0/16"] = "Network 1"
>>> t
Package: numactl
Version: 2.0.12-1+b1
Severity: serious
Justification: Policy 7.6.1
Unpacking numactl (2.0.14-1) over (2.0.12-1+b1) ...
dpkg: error processing archive
/var/cache/apt/archives/numactl_2.0.14-1_amd64.deb (--u
npack):
trying to overwrite '/usr/share/man/man2/move_pages.2.gz', which
On Wed, Aug 18, 2021 at 03:25:22PM +, Clint Adams wrote:
On Wed, Aug 18, 2021 at 11:22:53AM -0400, Michael Stone wrote:
apologies, box I checked was buster and not bullseye
No problem, it seems evident that it did little good anyway.
well, the note is for users, most of whom aren&#
On Wed, Aug 18, 2021 at 03:06:07PM +, Clint Adams wrote:
On Wed, Aug 18, 2021 at 10:53:45AM -0400, Michael Stone wrote:
Adding a message to stderr telling people to use mktemp may be a reasonable
step.
You mean the thing it does in our stable release?
apologies, box I checked was buster
Adding a message to stderr telling people to use mktemp may be a
reasonable step.
I thought debports architectures weren't supposed to prevent migration
to testing so I'm confused about why the package hasn't migrated.
Package: policykit-1
Version: 0.105-27
Severity: grave
Justification: renders package unusable
On install:
Setting up policykit-1 (0.105-27) ...
chown: cannot access '/usr/lib/policykit-1/polkit-agent-helper-1': No such file
or directory
> dpkg -L policykit-1 | grep help
/usr/libexec/polkit-ag
On Sat, Jul 04, 2020 at 03:21:03PM +0200, Mathieu Parent wrote:
Le sam. 4 juil. 2020 à 15:15, Michael Stone a écrit :
On Sat, Jul 04, 2020 at 07:28:32AM +0200, Mathieu Parent wrote:
>clone 963971 -1
>tag 963971 + upstream
>tag -1 + upstream fixed-upstream patch
>reassign -1 ss
On Sat, Jul 04, 2020 at 07:28:32AM +0200, Mathieu Parent wrote:
clone 963971 -1
tag 963971 + upstream
tag -1 + upstream fixed-upstream patch
reassign -1 sssd-ad-common
Le lun. 29 juin 2020 à 14:48, Michael Stone a écrit :
Package: samba-libs
Version: 2:4.12.3+dfsg-2
Severity: critical
On Tue, Jun 30, 2020 at 08:48:05AM +1200, Andrew Bartlett wrote:
On Mon, 2020-06-29 at 08:46 -0400, Michael Stone wrote:
Package: samba-libs
Version: 2:4.12.3+dfsg-2
Severity: critical
Justification: breaks the whole system
The new samba-libs package changes the soname of libndr from
libndr.so
Package: samba-libs
Version: 2:4.12.3+dfsg-2
Severity: critical
Justification: breaks the whole system
The new samba-libs package changes the soname of libndr from libndr.so.0 to
libndr.so.1 without reflecting this change in the package name. sssd-ad-common
has a dependency on samba-libs (>= 2:4.1
On Tue, Nov 05, 2019 at 11:40:02PM +0100, David Frey wrote:
On Mon, Nov 04, 2019 at 08:17:33AM -0500, Michael Stone wrote:
On Sat, Nov 02, 2019 at 12:51:41AM +0100, David Frey wrote:
> cp and mv have a runtime linkage to libacl and libattr which are
> installed in /usr/lib/x86_64-lin
Package: unbound
Version: 1.9.0-1
Severity: grave
Justification: renders package unusable
Immediately after installing 1.9.0-1, unbound refused to run after restart.
System logs contained:
Feb 6 11:00:24 annuminas package-helper[6142]: /var/lib/unbound/root.key has
content
Feb 6 11:00:24 annu
ing set
of packages even worse. (And honestly, this is kind of thing that should
be sorted out when a package is ITP'd and discussed, not done and then
declared a fait accompli.)
--
Michael Stone
On Wed, Jan 23, 2019 at 05:19:13AM -0500, Henrique de Moraes Holschuh wrote:
On Mon, Jan 21, 2019, at 10:36, Michael Stone wrote:
Yes, but most of those features are obsolescent at best. I'm not clear
on what functionality is actually being used. (I'm hesitant to remove
"ol
On Wed, Jan 23, 2019 at 05:46:39AM -0500, Henrique de Moraes Holschuh wrote:
On Sun, Jan 20, 2019, at 14:06, Thorsten Glaser wrote:
But you’re not in a situation to command either, considering
hmh is the ONLY maintainer of rng-tools so we WILL need his
input on this (or do an NMU).
Anything th
On Mon, Jan 21, 2019 at 04:47:51PM +0100, Diederik de Haas wrote:
On maandag 21 januari 2019 13:34:19 CET Michael Stone wrote:
On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote:
>On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
>> I’m very much against ju
On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote:
On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
I’m very much against just saying this package
“should not exist”
I'm inclined to agree with this as the source (+ features/parameters) for this
package is substantia
On Sun, Jan 20, 2019 at 04:05:09PM +, Thorsten Glaser wrote:
Michael Stone dixit:
So use the epoch. They're invented for fixing collosal errors like
this. Except this time, have the appropriate discussion on -devel
instead of just uploading something without coordination.
Sounds li
On Sun, Jan 20, 2019 at 03:41:22PM +, Thorsten Glaser wrote:
Michael Stone dixit:
Please upload a fixed version of rng-tools instead, reverting the erroneous
change.
That is impossible because the version changed.
In the tool I’m using, I have a hard version requirement on
rng-tools
On Sun, Jan 20, 2019 at 03:25:12PM +, Thorsten Glaser wrote:
Michael Stone dixit:
No, that's something else that shouldn't have happened
It’s important to me because the upload of rng-tools (>> 2)
broke things on unstable.
So that should be fixed--the problem should n
On Sun, Jan 20, 2019 at 03:01:18PM +0100, Diederik de Haas wrote:
On Fri, 11 Jan 2019 14:51:05 -0500 Michael Stone wrote:
On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote:
>There never should have been an NMU simply replacing rng-tools with
>rng-tools5. I did not notice tha
On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote:
There never should have been an NMU simply replacing rng-tools with
rng-tools5. I did not notice that this had happened.
Also, the correct fix for buster is an upload to put things back the way
they were, which is going to be ugly.
There never should have been an NMU simply replacing rng-tools with
rng-tools5. I did not notice that this had happened.
On Fri, Jan 11, 2019 at 07:21:49PM +0100, Andreas Henriksson wrote:
That has apparently failed to materialize well in time for buster.
Looking at the contents of the binary p
severity 909803 serious
thanks
There does not seem to be any logic in the freeipa-client package to
ensure a working time configuration after ntp is forced out in favor of
chrony. This implies that a freeipa client may become unusable after
upgrade once its clock has drifted far enough in the
On Thu, Oct 05, 2017 at 02:42:30PM +0200, Marco d'Itri wrote:
On Oct 03, Gunnar Wolf wrote:
So, contrib is _explicitly_ meant for software that does not meet the
DFSG, not for random stuff that cannot be packaged for convenience or
different issues.
I am almost sure that when I joined the pro
Package: cross-gcc-dev
Version: 146
Severity: serious
Justification: Policy 3.5
cross-gcc-dev depends on realpath. This has actually been a transitional
package since jessie, and should have been realpath | coreutils (>= 8.26-1). At
this point, after two stable releases, the realpath transitional
Package: common-lisp-controller
Version: 7.10
Followup-For: Bug #780947
Priority of this bug should be raised, as the transitional package is on its
way out, having been in both jessie and stretch stable releases. The bash
dependency seems similarly obsolete.
Mike Stone
On Tue, Jan 31, 2017 at 05:17:44PM +0100, Francesco Namuri wrote:
of course we can remove it only from the upcoming stable release,
and removing it from testing already done it. ftpmaster also removed
it from unstable.
We asked also the removal from unstable due the gravity of the bug.
I'd like
If I'm understanding this correctly, removing the package simply
guarantees that people upgrading from jessie will have an instance that
simply stops working properly? Is it possible to upload a version that
remove the create functionality but lets people mount existing encrypted
directories (w
Package: tcsh
Version: 6.20.00-1
Severity: critical
Justification: breaks unrelated software
/usr/bin/tcsh is no longer being provided by the tcsh package. This prevents
logins from users with a shell of /usr/bin/tcsh, and breaks active sessions in
various ways (when software attempts to use $SHEL
Package: argus-server
Version: 2:3.0.8.1-2
Severity: serious
argus-server should wait for newer argus-client packages to get out of
NEW. There is not a hard dependendency because the packages can
technically be used indepedently (e.g., on separate machines) but it
seems suboptimal to generate
I can confirm that the current patch builds on a 4.3 kernel, but results
in a system with no video. (Works fine rebooted on 4.2 kernel.)
Mike Stone
I actually just haven't gotten to requesting it be removed completely. People
should probably be using sysstat at this point.
Original message
From: Eriberto Mota
Date: 12/10/2015 6:27 PM (GMT-05:00)
To: 800...@bugs.debian.org
Cc: Control Bugs Debian
Subject: Bug#800264:
Based on the conversations upstream, I'd say that rlimit memlock 0
should be the default in debian, not something that needs to be added to
working configs. (It appears that beyond the startup issue, it's fairly
common for running ntpd's to crash with out-of-memory errors when using
memlock. Th
On Sat, Jul 18, 2015 at 04:03:51PM -0500, Leslie Rhorer wrote:
RAID-Server:/tmp/temp# openssl md5 "Abyss, The (Recorded Thu Sep 11,
2014, MAXHD).mp4"
MD5(Abyss, The (Recorded Thu Sep 11, 2014, MAXHD).mp4)=
fa54d754e0c51653d71d2419a26e18de
RAID-Server:/tmp/temp# openssl md5 "Abyss, The (Recorded
It's not my intention to interfere with the realpath package at this
point, and it will not be in the next coreutils upload.
Mike Stone
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: bash
Version: 4.2-1
Severity: critical
Justification: breaks unrelated software
E.g.:
$ dash -c 'while read line ; do echo $line ; done < /proc/net/dev'
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets
errs drop fifo colls carrier co
On Thu, Sep 22, 2011 at 11:58:37AM +0200, Michel Dänzer wrote:
The skip message contains 'this test runs only on systems with [...]
long double != double', which isn't satisfied with -mlong-double-64, is
it?
See the output samples; the prior version worked fine at this boundary,
the new versio
On Wed, Sep 21, 2011 at 10:18:47AM +0200, Michel Dänzer wrote:
The test fails because it doesn't pass $CFLAGS to the compiler. The attached
patch fixes this, so the test is skipped as expected.
The point wasn't to skip the test, it was to fix the bug. :-)
Unfortunately, the CFLAGS change doesn
On Sun, Jan 17, 2010 at 02:40:58AM +0100, Kurt Roeckx wrote:
On Sat, Jan 16, 2010 at 07:21:14PM -0500, Michael Stone wrote:
>and failed on alpha with "FAIL: test-fstatat" like it did before.
What kernel is that running? Usually errors with fstatat are caused
by unsupported
On Sun, Jan 17, 2010 at 12:25:47AM +0100, Kurt Roeckx wrote:
So it worked now on amd64 (on brahms, the one using xfs),
Ok, I'll see if I can dup on xfs also. I've also passed the issue to
upstream. (The basic issue seems to be whether or not setting utime
alters ctime, which is an assumption
On Wed, Dec 16, 2009 at 07:46:46PM +0100, Kurt Roeckx wrote:
There was an error while trying to autobuild your package on amd64
and alpha.
On amd64 we got:
FAIL: touch/no-dereference
FAIL: touch/trailing-slash
I'm assuming this is a build environment failure, but I'm having trouble
with my am
An updated fix has been queued in my local diff for a while, will be
included in the next upload.
Mike Stone
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Sat, Sep 26, 2009 at 10:32:05PM +0200, Kurt Roeckx wrote:
Did you try and reproduce this on one of the porter machines?
no
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Yup. I'm open to suggestions on why a perfectly valid shell script
doesn't work on certain architectures. The part that fails isn't even
part of the build.
Mike Stone
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
On Thu, Jun 04, 2009 at 10:51:53PM +0200, you wrote:
Surely I am not the specialist for resolving package dependency problems,
but shouldn't coreutils provide mkutils instead of replacing it?
There is no need to provide mktemp because nothing depends on it. The
replaces is necessary so dpkg wi
On Tue, Jun 09, 2009 at 07:51:02AM +0800, you wrote:
Shouldn't there be an empty transitional mktemp package that depends on
coreutils 7.4-1?
There is. If you removed the actual mktemp package instead of the one
that says "can be safely removed", well, you outsmarted yourself.
I have no ide
On Thu, Jun 04, 2009 at 10:10:05PM +0200, you wrote:
problems, but wouldn't it be more efficient if coreutils simply
provides mktemp instead of conflicting with it?
No, because then you have a dangling mktemp package. Unfortunately, apt
doesn't get this quite right and I forgot about the neces
On Thu, Jun 04, 2009 at 05:28:52PM +0200, Sven Joachim wrote:
To avoid this catch-22 situation, just use Replaces without Conflicts.
That's how you handled the transition from {file,shell,text}-utils to
coreutils, BTW.
Quite plausible. I'm not sitting in front of my dev system at the
moment. :
On Thu, Jun 04, 2009 at 03:24:59PM +0200, Sven Joachim wrote:
Of course, the Conflicts of coreutils with mktemp must then be removed.
I think rather that it would need to be versioned?
Mike Stone
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscr
On Thu, Jun 04, 2009 at 02:37:19PM +0200, Samuel Thibault wrote:
coreutils 7.4-1 replaces and conflicts with mktemp, which is essential,
so that apt-get asks for typing 'Yes, do as I say!', which is far from
ergonomic. I guess what is missing is just coreutils 7.4-1 _providing_
mktemp as well?
tags 528126 +unreproducible
thanks
On Sun, May 10, 2009 at 11:41:07PM +0100, steve downes wrote:
Touch does not update the timestamp in an existing file. This is
particularly relevant to me as it appears to have caused dpkg to fail
& not fully update leaving a none updatable system. I tested thi
On Tue, Apr 21, 2009 at 05:36:20PM -0300, Otavio Salvador wrote:
On Tue, Apr 21, 2009 at 4:02 PM, Michael Stone wrote:
On Tue, Apr 21, 2009 at 03:43:21PM -0300, you wrote:
$: sort -um -o list list work
I'll look at the segfault, but I'm not sure that was ever guaranteed to giv
On Tue, Apr 21, 2009 at 03:43:21PM -0300, you wrote:
$: sort -um -o list list work
I'll look at the segfault, but I'm not sure that was ever guaranteed to
give a useful result (you're overwriting an input file).
Mike Stone
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.or
Package: xlockmore
Severity: serious
I'm planting this here to make sure that xlockmore doesn't trickle into
lenny unless the PAM code gets a close look & the remaining issues are
fixed.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Con
On Fri, Feb 15, 2008 at 05:09:31PM -0700, you wrote:
So, this seems to be restricted to either older kernels, or kernels with
a specific config.
Since my last email I've had my primary development machine die from bad
capacitors, replaced it, put a new test qemu environment together, tried
a
My thought is that glibc has some kind of fallback code if you use
unlinkat on a system that doesn't support it, and that's what's broken;
since these are all being compiled with the same glibc, the libc symbol
should always exist, no? Adam, could you try building/running the
attached? If it al
On Fri, Feb 15, 2008 at 05:56:14PM -0500, you wrote:
On Fri, Feb 15, 2008 at 03:47:34PM -0700, you wrote:
For what it's worth, the confusion in this bug log seems due to the
fact that people testing succesfully clearly have /proc mounted.
I spotted the same bug on the Ubuntu buildds today while
On Fri, Feb 15, 2008 at 03:47:34PM -0700, you wrote:
For what it's worth, the confusion in this bug log seems due to the
fact that people testing succesfully clearly have /proc mounted.
I spotted the same bug on the Ubuntu buildds today while mucking
around inside chroots without /proc mounted:
On Thu, Jan 24, 2008 at 02:55:51PM +, Thiemo Seufer wrote:
Michael Stone wrote:
Meaning that the buildd's will be upgraded then & I should just wait for
them to try to rebuild coreutils after that? (Just want to make sure I
understand the proper path forward.)
Yes.
Did th
On Tue, Feb 05, 2008 at 10:01:40AM +0100, Marc Leeman wrote:
I installed this package, after which my entire system started to break
due to problems caused in mkinitramfs and packages fail to install.
I need a lot more information that this; it's certainly the case that it
works fine here & on
On Thu, Jan 24, 2008 at 02:05:39PM +, Thiemo Seufer wrote:
ruby1.9 is another package affected by this.
I'd guess that there are a lot of packages affected by this, but which
don't run extensive validation tests as part of the build process.
I'm currently validating the stability of 2.6
On Wed, Jan 23, 2008 at 06:13:14PM -0700, Bob Proulx wrote:
Julien Cristau wrote:
Maybe you could modify the build rules to cat the test logs in case of
failure?
Turning on debug for everything would create *HUGE* log files.
Probably too big for routine use. That is why it is off by default.
On Wed, Jan 23, 2008 at 11:11:23PM +0100, Luk Claes wrote:
Do you even care looking at the build logs or do you really want to be
pointed at them? They are available as usual on buildd.debian.org...
Sorry, I meant "test log" rather than "build log". The details about why
the test failed are le
On Wed, Jan 23, 2008 at 09:04:22PM +0100, Lucas Nussbaum wrote:
Note that the mipsel buildd failed in the exact same way.
Yeah, same theory holds. Until it can be duplicated with a manual build
or we get the build logs it ain't gonna be easy to fix. It's obviously
trivial to special case mips
On Wed, Jan 23, 2008 at 01:15:29PM +0100, you wrote:
On 23/01/08 at 11:06 +0100, Lucas Nussbaum wrote:
Package: coreutils
Version: 6.10-1
Severity: serious
Hi,
coreutils 6.10-1 failed to build on mips:
> Making check in rm
> make[3]: Entering directory
`/build/buildd/coreutils-6.10/build-tre
On Tue, Sep 18, 2007 at 04:20:25PM +1000, Tony Breeds wrote:
On Sat, Sep 15, 2007 at 04:14:34PM -0400, Michael Stone wrote:
Ok, can anyone test what happens with gcc 4.1? (I kinda suspect some
kind of wacky code generation bug on ppc, because it works fine on alpha
amd64 hppa i386 ia64 mipsel
On Sat, Sep 15, 2007 at 09:48:30PM +0200, Elimar Riesebieter wrote:
Confirmed! Same build in a pbuilder environment with sid sources on
a PowerBook5,6.
Ok, can anyone test what happens with gcc 4.1? (I kinda suspect some
kind of wacky code generation bug on ppc, because it works fine on alpha
On Tue, Jul 17, 2007 at 03:54:03PM +0200, you wrote:
Alright. Will there be an update? Upstream already is at version 6.9.
I'm aware of the upstream version. The difficulty is with the
integration of the selinux stuff (which wasn't in the experimental
version). If that managed to get integrat
Please don't waste time/effort on this experimental package; I've asked
for it to be removed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, Feb 22, 2007 at 10:52:38PM +, you wrote:
I think that may be a reasonable thing to do here.
The reasonable thing would have been to not bitch about the binary
upload.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EM
On Sat, Jan 20, 2007 at 07:14:14PM -0600, Manoj Srivastava wrote:
I see there is a fix in the bug report now. Do you want to
create a -6 package, or do you want me to try -5.3 NMU?
Right now, I don't care. I personally feel that the manual build should
have been sufficient to get -5.2
On Sat, Jan 20, 2007 at 02:34:47PM +0100, Andreas Barth wrote:
On the thread in debian-release, in
http://lists.debian.org/debian-release/2007/01/msg00972.html
| The following informations are from memory. The test fails if it reaches
| a bind mount on the same device. I reproduced it somehow wit
If you run the coreutils pwd-long test from within a bind mount it'll
fail. Reproduce with:
| mkdir test1 test2
| mount --bind test1 test2
| cd test2
| env BUILD_SRC_DIR=/bin ./pwd-long
looking at what pwd returns:
(expects)
/tmp/test2/pwd-long.tmp/19496/zzz/z[..
On Sat, Jan 20, 2007 at 09:48:56AM -0600, you wrote:
OK. So where does that leave us at the moment? The first bug
closing message said:
] This wasn't duplicated for any other arch, and this plaform
] apparantly hasn't even tried building the last two uploads. I'm going
] to assume it was
On Sat, Jan 20, 2007 at 10:20:50AM +0100, Andreas Barth wrote:
The package failed on the buildd with the error below, please see
http://buildd.debian.org/fetch.cgi?&pkg=coreutils&ver=5.97-5.2&arch=s390&stamp=1162820579&file=log
for the full log.
According to waldi, this is probably due to the fa
On Sat, Dec 09, 2006 at 11:01:01AM +0100, you wrote:
(Summary: [EMAIL PROTECTED] says patch in #318123 is insufficient)
No shit; I said that when I first saw the patch. The best solution for
now is probably just to conflict with libpam-opensc; there's some work
on rearchitecting the pam suppo
Severity: serious
Package: gcc
gcc has been building parts of coreutils on s390 (sha384 & sha512) in a
way that silently generates incorrect results. (Caught by tests during
the coreutils build process.) This has been traced to a bug in gcc:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id
This wasn't duplicated for any other arch, and this plaform apparantly
hasn't even tried building the last two uploads. I'm going to assume it
was a platform-specific build environment bug unless there's further
information provided.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
w
On Wed, Aug 02, 2006 at 11:03:49PM -0600, [EMAIL PROTECTED] wrote:
There was an error while trying to autobuild your package:
Yeah, I uploaded 5.97-2 to fix that the other day, but the upload seems
to have disappeared. I'll try to figure out where it went.
Mike Stone
--
To UNSUBSCRIBE, ema
Michael Stone wrote:
Since this is the only failure listed, I'll assume it's the problem. Was
there any actual diagnostic message in the part you snipped?
It looks like the answer is yes. The log (including the build
environment) is at
http://buildd.debian.org/fetch.php?&pkg
1 - 100 of 128 matches
Mail list logo
