Source: xpa
Version: 2.1.18-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid your package fails to build on current unstable:
debian/tests/xpa_test_build
XPA$ERROR: invalid host name specified: $host:$port.
XPA$ERROR no 'xpaset' acc
Source: zipios++
Version: 0.1.5.9+cvs.2007.04.28-10
Severity: serious
Justification: fails to build from source
Hi!
I'm afraid your package fails to build on current unstable:
dh_fixperms
chown: cannot access
'debian/libzipios++-doc/usr/share/doc/libzipios++-doc/html/fcoll_8cpp__incl.dot':
N
Source: wavbreaker
Version: 0.11-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid that your package fails to build on current unstable:
dh clean --parallel --with=autotools_dev,scour
dh: Compatibility levels before 9 are deprecated
Source: android-platform-build
Version: 1:7.0.0+r33-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid your package fails to build on current unstable:
In file included from tools/zipalign/ZipFile.h:24:0,
from tools/z
Source: php-pecl-http
Version: 3.1.0+2.6.0-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid your package fails to build on current unstable:
checking whether ext/raphf is enabled... no
configure: error: please install and enable pec
On Wed, Jan 03, 2018 at 06:29:06PM +1000, Alexander Zangerl wrote:
> On Tue, 02 Jan 2018 14:40:33 +0100, Adam Borowski writes:
> >I'm afraid that your package fails to build on current unstable, failing the
> >vast majority of tests:
>
> looks like every one of the faile
On Thu, Jan 04, 2018 at 08:14:31PM +0200, Adrian Bunk wrote:
> On Mon, Jan 01, 2018 at 01:13:57AM +0100, Adam Borowski wrote:
> >...
> > And indeed, in a chroot created with debootstrap --variant=buildd there is
> > no such file anymore. But, I see that the package doesn
} PATH=`pwd`/bin:$PATH /bin/sh test/07/t0705a.sh
} 2,3c2,3
} < (ENOENT) because there is no "hostid" regular file in the pathname "/etc"
} < directory; did you mean the "hosts" regular file instead?
} ---
} > (ENOENT) because there is no "hostid" regular file in the pathname
} > "/etc" directory
}
Package: i2pd
Version: 2.17.0-1
Severity: serious
Justification: programs must support baseline arch (w/o a good reason otherwise)
Hi!
I'm afraid that current version of i2pd crashes on startup on processors
that don't support avx and aes, unless the package was built on a machine
without such sup
On Wed, Jan 10, 2018 at 08:38:39PM +0100, John Paul Adrian Glaubitz wrote:
> > Please tell me why this would be serious: any filesystem from this millenium
> > can handle unclean shutdown fine -- especially if there's a sync before
> > reboot/poweroff.
>
> That's hardly an argument. There is still
Apologies for not assisting you with debugging, but at least I confirm: -4
passes the testsuite on all my setups.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.
On Tue, Jan 09, 2018 at 10:42:19PM +0530, Vasudev Kamath wrote:
> Control: tag -1 +moreinfo +unreproducible
>
> Adam Borowski writes:
> > Source: ctpp2
> > Version: 2.8.3-23
> >
> > Hi!
> > I'm afraid your package fails to build:
> >
>
On Sun, Jan 14, 2018 at 02:25:44AM +0100, Adam Borowski wrote:
> Sorry for the delay. I haven't found the cause yet, but here's my progress:
>
> It looks like kernel version is a factor. All my test machines run current
> 4.15-rc, so that was common to all builds.
>
> /<>/libi2pd/Crypto.cpp: In member function 'virtual void
> i2p::crypto::ECBEncryptionAESNI::Encrypt(const i2p::crypto::ChipherBlock*,
> i2p::crypto::ChipherBlock*)':
> /<>/libi2pd/Crypto.cpp:611:4: error: unknown register name
> '%xmm0' in 'asm'
>);
The issue here is helper functions that
On Tue, Jan 09, 2018 at 10:42:19PM +0530, Vasudev Kamath wrote:
> Control: tag -1 +moreinfo +unreproducible
>
> Adam Borowski writes:
>
> > Source: ctpp2
> > Version: 2.8.3-23
> > Severity: serious
> > Justification: fails to build from source (but
> Running testGetLinkInfoDirectory
> Exception in thread "main" java.lang.AssertionError: expected:<2> but was:<1>
This is caused by an assumption that link count of a directory without any
hardlinks is 2 (or more general, 2 plus number of subdirectories). This is
true on 70's sysvfs and descenda
This looks same as #886120 -- ie, a bug in either doxygen, graphviz or both.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky. Your cat demands food. The priority should
> chown: cannot access 'debian/xppaut/usr/share/doc/xppaut/examples/ode/t.so':
> No such file or directory
> chown: cannot access
> 'debian/xppaut/usr/share/doc/xppaut/examples/ode/testbd.ps': No such file or
> directory
> dh_fixperms: find debian/xppaut -true -print0 2>/dev/null | xargs -0r cho
Not like #886120, sorry.
The file doesn't exist under that name there -- but one .dot.gz does.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky. Your cat demands food.
On Mon, Jan 15, 2018 at 10:33:01AM +0530, Vasudev Kamath wrote:
> Adam Borowski writes:
>
> >> Yeah. Since you mentioned its random can we reduce the severity of the
> >> bug?.
> >
> > Bad idea, as it fails a lot: on my armhf box, 17/20 times, on my amd64, 6
osts for a read tests, it might be missing.
+(Closes: #885963)
+
+ -- Adam Borowski Tue, 16 Jan 2018 04:26:20 +0100
+
libopenraw (0.0.9-3.10) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru libopenraw-0.0.9/debian/patches/04-file-read-test.patch
libopenraw-0.0.9/debian/patche
Source: u-boot
Version: 2017.11+dfsg1-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid that u-boot fails to build on arm64, both the unstable and
experimental versions:
ld.bfd: arch/arm/lib/crt0_aarch64_efi.o: relocation R_AARCH64_A
On Wed, Jul 08, 2020 at 03:44:21PM +0200, Ansgar wrote:
> On Wed, 2020-07-08 at 11:04 +0200, Johannes Schauer wrote:
> > What is happening here is, that aspcud chooses libelogind0 for installation
> > and
> > then apt decides that it refuses to install it because it doesn't want to
> > remove libs
Control: severity -1 normal
On Thu, Jul 09, 2020 at 01:27:34PM +0200, Lucas Nussbaum wrote:
> Source: pmdk
> Version: 1.8-1
> Severity: serious
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > pmem_check_version@@LIBPMEM_1.0
> > pmem_deep_drain@@LI
Package: gimp-python
Version: 2.10.8-2+b1
Severity: grave
Justification: renders package unusable
Hi!
As the package "python" is no more, gimp-python can no longer be installed.
It needs to either depend on "python2" (in the short term) or, preferably,
be updated for py3.
Meow!
-- System Informa
Control: block -1 by 964457
On Mon, Aug 03, 2020 at 01:19:42PM +0200, Lucas Nussbaum wrote:
> Source: vmem
> Version: 1.8-1
> Severity: serious
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > vmem_aligned_alloc@@LIBVMEM_1.0
> > vmem_calloc@@LIBVMEM_1.0
An
Package: unison-2.48
Version: 2.48.4-5+b1
Severity: serious
Justification: fails to upgrade
Hi!
I'm afraid there's no Replaces: stanza, resulting in:
Unpacking unison-2.48 (2.48.4-5+b1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-Q6eH0z/4-unison-2.48_2.48.4-5+b1_amd64
.deb (--unpack
Just so there's a public record: I've sponsored the version of runit that
was rotting on mentors as-is; it included a bunch of fixes and transfer of
maintainership to Lorenzo.
This means, we now have a proper maintainer.
Meow.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies a
On Sat, Mar 21, 2020 at 05:47:25PM +0100, Ivo De Decker wrote:
> On Sat, Mar 21, 2020 at 02:43:19PM +0100, Adam Borowski wrote:
> > I've uploaded binaries for amd64 arm64 armhf i386 (ie, arch in testing), so
> > it should be done.
> >
> > Apparently the package c
On Sun, Mar 22, 2020 at 09:24:01AM +0100, Lucas Nussbaum wrote:
> Source: safeclib
> Version: 3.5-2
> Severity: serious
> Justification: FTBFS on amd64
> > FAIL: t_towfc_s
> > ===
> >
> > test_towfc_s 211 Error: towfc(U+A7C7) => A7C7 "A7C8" status=C LATIN
> > CAPITAL LETTER D WITH S
Control: severity -1 normal
I don't get why this would be severity:critical.
With Recommends enabled, there are hundreds of packages that cause a
large-scale changeover of the system -- be it DE switch, installing a gig or
more of random daemons, an init system switch, or the like.
So unless the
Package: qemu-system-ppc
Version: 1:4.2-2
Severity: grave
Justification: renders package uninstallable
Hi!
Upon upgrading or a fresh install:
Unpacking qemu-system-ppc (1:4.2-2) ...
dpkg: error processing archive «TMP»/3-qemu-system-ppc_1%3a4.2-2_amd64.deb
(--unpack):
trying to overwrite '/usr/
Source: a2ps
Version: 1:4.14-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid this package build-depends on emacs25, which is long since gone.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-d
On Sat, Jul 18, 2020 at 03:36:48PM -0400, Boyuan Yang wrote:
> X-Debbugs-CC: debian-fo...@lists.debian.org m...@debian.org
>
> On Thu, 16 Jul 2020 23:19:31 +0200 Andreas Beckmann
> wrote:
> > Package: afdko-bin
> > Version: 3.4.0+dfsg1-2
> > Severity: serious
> >
> > Preparing to unpack .../af
Control: block -1 by 964457
On Thu, Jul 09, 2020 at 01:27:34PM +0200, Lucas Nussbaum wrote:
> Source: pmdk
> Version: 1.8-1
> Severity: serious
> Relevant part (hopefully):
> > pmem_check_version@@LIBPMEM_1.0
This is caused by #964457 which appends decoration to symbols once if there
should be n
Control: tags -1 +fixed-upstream
It has been long since fixed in modern upstream releases. Debian is stuck
at 4.3, upstream has 4.7 and 4.8-rc3. Obviously, stuff that's closely tied
to kernel headers is likely to break when there's a big discrepancy between
versions.
Please update!
--
A MAP07
On Fri, Aug 11, 2023 at 02:02:36PM +0300, Adrian Bunk wrote:
> I've prepared an NMU for pmdk (versioned as 1.13.1-1.1) and uploaded
> it to DELAYED/2. Please feel free to tell me if I should cancel it.
> +pmdk (1.13.1-1.1) unstable; urgency=low
> +
> + * Non-maintainer upload.
> + * Ignore check
On Mon, Aug 21, 2023 at 10:38:52AM +0200, Emanuele Rocca wrote:
> Hi Adam,
Hi Em!
> On 2023-08-16 05:14, Adam Borowski wrote:
> > This is not a regression, thus why would it be a bug?
>
> Well FTBFS is a bug isn't it? :-)
A FTBFS on an architecture that has built befor
Package: xserver-xorg
Version: 1:7.0.15
Severity: grave
Justification: renders package uninstallable
The debconf question xserver-xorg/config/inputdevice/mouse/zaxismapping
is needed by xserver-xorg's preinst, yet its template is missing. Without
it, installation fails on new installs unless manu
> I have the directory /dev/.udevdb/ but not /dev/.udev/db/
My fault, there is a missing mkdir (workaround: mkdir /dev/.udev/
and retry).
It will still fail on:
mv /dev/.udevdb/ /dev/.udev/db/
Should be:
mv /dev/.udevdb /dev/.udev/db
I guess you probably noticed and/or fixed this, but s
Package: industrial-cursor-theme
Version: 0.6.1
Severity: serious
debian/rules:3: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk: No such file
or directory
make: *** No rule to make target
`/usr/share/gnome-pkg-tools/1/rules/uploaders.mk'. Stop.
Adding a Build-Depends: on gnome-pkg-tools make
udev can create /dev/fuse itself, so this patch does it only if udev is
not in use. A device in /dev/.static/dev/ is created anyway, though,
otherwise fuse would be broken if the user uninstalled udev.
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wun
I would say that ttyrec is worth keeping.
First, the RC bug(s) are trivially fixable, all it takes is changing a
simple flag, a fix is in the BTS for five freaking years.
Ttyrec is used quite a bit, especially among NetHack and MUD players, so at
very least something which reads ttyrec's format s
On Fri, Oct 12, 2007 at 05:11:07PM +0200, Lucas Nussbaum wrote:
> On 12/10/07 at 15:06 +0200, Adam Borowski wrote:
> > I would say that ttyrec is worth keeping.
>
> Hi Adam,
(I'm away for the weekend, sorry for the delay...)
> Would you be interested in maintaining tty
On Thu, Nov 15, 2007 at 09:01:03PM -0500, Daniel Schepler wrote:
> From my pbuilder build log:
>
> ...
> cc -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -I../shared -DVERSION=\"`cat ../VERSION`\" -DTOPDIR=\"/tmp/buildd/tcng-10b\"
>-c -o f_fw.o f_fw.c
> In file
reopen 502346
kthxbye
> as the message says - /either/ install the prebuilt module, /or/ build
> it yourself with m-a.
Except, the prebuilt module doesn't work for the version of virtualbox
in Lenny. Since that is this package's sole purpose, that makes it useless.
(Nitpicking, it does have som
On Thu, Oct 23, 2008 at 03:17:34PM +0200, Bastian Blank wrote:
> On Wed, Oct 22, 2008 at 11:49:25PM +0200, Adam Borowski wrote:
> > Except, the prebuilt module doesn't work for the version of virtualbox
> > in Lenny. Since that is this package's sole purpose, that make
Package: util-vserver
Version: 0.30.216~r2772-1
Severity: grave
Tags: patch
Justification: causes non-serious data loss
I'm afraid that "/etc/init.d/util-vserver stop" hangs if there is at least
one guest running; it's usually called on host shutdown when it will block
the whole system from reboo
The fun thing is, glibc-doc consists of... just the LinuxThreads libpthread
docs! Everything else is in glibc-doc-reference (non-free).
The changelog is worth keeping, but congratulations, you just obsoleted the
last bit of glibc-doc.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
Package: linux-image-2.6.16-2-xen-686
Version: 2.6.16-17
Severity: grave
A recently added optimization skips checksums on all packets it
believes are destined for another Xen domain inside the same box.
Too bad, it is sometimes wrong -- an analysis can be found on
http://lists.xensource.com/archiv
On Wed, Jan 17, 2024 at 04:29:10PM +0100, Emanuele Rocca wrote:
> Source: kbtin
> Severity: serious
> Usertags: 32bit-stackclash
> kbtin currently fails to build from source on armhf. The failure is due
> to an incompatibility between valgrind and stack-clash-protection on
> 32bit arm reported ups
Package: python-apt
Version: 0.7.13.4
Severity: grave
Justification: renders package unusable
During upgrade:
(Reading database ... 30226 files and directories currently installed.)
Preparing to replace python-apt 0.7.13.3 (using
.../python-apt_0.7.13.4_i386.deb) ...
File "/usr/bin/pycentral",
Hi!
I'm afraid this bug is still there, both in the version in testing and in
unstable:
[~]$ 6tunnel -4 -l 192.168.0.100 5432 10.2.10.2 5432
6tunnel: unable to resolve host 10.2.10.2
After reverting to the version from lenny, all is ok.
--
1KB // Microsoft corollary to Hanlon's raz
On Sat, Jan 15, 2011 at 12:22:51PM +0200, Jari Aalto wrote:
> Could you confirm that the patch is indeed the problem:
>
> dget -x
> http://ftp.de.debian.org/debian/pool/main/6/6tunnel/6tunnel_0.11rc2-5.dsc
> cd 6tunnel-0.11rc2
> sed --in-place '3d' debian/patches/serie
Package: src:net-tools
Version: 1.60-24.2
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
Apparently, STRIP support is now an unthing, and kernel headers no longer
have it.
Ubuntu have already patched it; from their patch:
diff -pruN 1
tags 78 -unreproducible
severity 78 important
kthxbye
On Fri, Feb 08, 2013 at 09:12:05PM +0100, Anton Gladky wrote:
> I am not able to reproduce FTBFS in a clean
> environment. Please, confirm.
After more checking, it appears to build in pbuilder but not on my live
system. The latter is
Package: gnustep-base-runtime
Version: 1.20.1-4
Severity: serious
Tags: patch
Justification: Policy 9.3.2
If the gdomap daemon is for any reason not working (manually stopped,
crashed, disabled in a chroot, disabled by the rc policy, botched install,
etc), removal of the gnustep-base-runtime pack
reopen 692171
severity 692171 important
retitle 692171 missing Replaces: iptables << 1.4.16.3-3
kthxbye
There is a file conflict between previous version of binary:iptables and
new libxtables9. An upgrade will thus fail, yet if iptables = 1.4.16.3-3
has been installed in the same dpkg run, all yo
On Fri, Jul 20, 2012 at 10:05:04PM +0200, Enrico Tassi wrote:
> On Fri, Jul 20, 2012 at 04:31:23PM +0200, Adam Borowski wrote:
> > Looking around, it looks it could be fixed by:
> > * moving lua-deb-multiarch.h to /usr/include/$arch/
> > * removing /usr/lib/x86_64-linux-gnu
On Sat, Aug 18, 2012 at 06:38:47PM +0200, Julien Cristau wrote:
> On Fri, Aug 17, 2012 at 09:21:00 +0200, Piotr Szydełko wrote:
>
> > For a time being I'm using the last version that was available but I would
> > like to know what will happen when I install new instance of wheezy? Will
> > there b
Even if you upgrade the kernel before udev (but don't reboot immediately),
udev will still refuse to upgrade. No way to force udev to proceed I tried
seems to work as well -- unless you mess with the package's maintainer
scripts, you'll have to reboot twice.
--
1KB // Microsoft corol
Package: netbase
Version: 4.42
Severity: serious
Tags: patch
Justification: Policy 10.7.3
Certain versions of netbase created /etc/sysctl.d/bindv6only.conf on
install, with contents that caused a severity critical bug #560238 (breaking
IPv4 on many POSIX-compliant programs). That bug has been fix
Since both dash and posh work the same way as bash4, it looks like it's a
bugfix rather than just a random incompatible change.
(I didn't dig up POSIX for the authoritative description.)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
Package: virtualbox-ose
Version: 3.2.8-dfsg-2
Severity: grave
Justification: causes serious data loss
If you elect to merge the current state of a differentiating disk image into
the base ("deleting a snapshot") and run out of disk space on the host
filesystem while merging, the resulting image wi
On Fri, Oct 15, 2010 at 12:22:28PM +0200, Michael Meskes wrote:
> On Thu, Oct 14, 2010 at 12:26:45PM +0200, Adam Borowski wrote:
> > If you elect to merge the current state of a differentiating disk image into
> > the base ("deleting a snapshot") and run out
On Thu, Nov 06, 2014 at 02:06:07PM +, Michael Tautschnig wrote:
> At least Santiago's and my opinion diverge on whether base-passwd is presently
> in line with policy on 3.8 Essential packages. Therefore the route from here
> appears to hinge on interpreting policy in one of two ways: my point
On Thu, Nov 06, 2014 at 10:32:34PM +, Michael Tautschnig wrote:
> > I tested your patch when debootstrapping from squeeze, it did work. Should
> > I test some more scenarios (cdebootstrap? 2-phase cross-arch debootstrap?
> > some other distro?) -- or do you think it should be safe?
>
> Cool,
Control: reassign -1 base-passwd
Control: retitle -1 makes base-files fail to install during bootstrap
Control: found -1 3.5.36
Control: fixed -1 3.5.37
On Fri, Nov 07, 2014 at 07:47:42PM +, Michael Tautschnig wrote:
> First of all thanks to everyone for the efforts to fix these problems. It
Package: src:ask
Version: 1.0.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid that during a rebuild of jessie on armhf your package failed to
build:
dh_auto_test
make[1]: Entering directory '/«PKGBUILDDIR»'
nosetests
.
Package: src:libxshmfence
Version: 1.1-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid that during a rebuild of jessie on armhf your package failed to
build:
===
libxshmfence 1.1: test/test
On Mon, Nov 10, 2014 at 12:17:03AM +0100, Sebastiaan Couwenberg wrote:
> On 11/09/2014 10:33 PM, Adam Borowski wrote:
> > I'm afraid that during a rebuild of jessie on armhf your package failed to
> > build:
>
> > A build on amd64 succeeded, though.
> > This is
Package: src:keyutils
Version: 1.5.9-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid that during a rebuild of jessie on armhf (using sbuild) your
package failed to build:
Running with session keyring RHTS/keyctl/16243
Joined sessio
Package: doomsday
Version: 1.14.5-1
Severity: grave
Justification: renders package unusable
When trying to start doomsday, it pops up a dialog which says:
.[ Doomsday Engine ]
App init failed:
"[NotFoundError] (Record::subrecord) Subrecord 'alert' not found"
`
then crashes with a seg
On Mon, May 25, 2015 at 05:11:10PM -0400, Michael Gilbert wrote:
> On Mon, May 25, 2015 at 6:16 AM, Adam Borowski wrote:
> > When trying to start doomsday, it pops up a dialog which says:
> > .[ Doomsday Engine ]
> > App init failed:
> > "[NotFoundErro
Control: severity -1 important
As openrc has never been built on these architectures, technically the
proper severity here is wishlist rather than serious, as the package "needs
porting". For example, systemd does FTBFS on kfreebsd-* too.
In this case, though, this rule feels more like a technic
Package: openrc
Version: 0.13.1-1
Severity: grave
Hi!
I'm afraid that the new version of openrc fails to install if any purged
package on the system left over its rc.d links. That's a bug in the package
in question too, but an init system must not fail because of that.
On my box, openrc first fa
Also, depending on libgnutls26 means your package will not be in jessie
(#760735), so even if it somehow builds, you still need to transition to
libgnutls28-dev.
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact t
A weird thing: 0.12.4+20131230-9 did work ok, yet after installing 0.13.1-2
then downgrading back to 0.12.4+20131230-9, I still get the problem.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Meow!
With today's upload of libgadu and openldap, it looks like everything
(except some RC-buggy only-in-sid stuff) has migrated to libgnutls28-dev.
The transition tracker
(https://release.debian.org/transitions/html/gnutls28.html) claims otherwise
but it's somehow wrong about haskell-gnutls and
Control: tags -1 +patch
So... how exactly are these vulnerabilities?
2. is what this program is supposed to do: produce _pronounceable_ passwords
instead of pure line noise. Sure, these do have less entropy than pure line
noise for the same length, but the point is to make something that's
possi
Control: tags -1 +unreproducible
Hi!
I just tried to reproduce this build failure, without luck (or rather,
without unluck in this case). I tried it in armel chroots on two machines,
the worse one being a RasPi to reduce the chance it's somewhat CPU-related;
I don't have a real armel box though.
[Sorry for slow response, testing this on one's main machine requires
dropping too much state...] I should have CCed the bug earlier, doing this
now.
On Mon, Oct 20, 2014 at 08:37:04PM -0700, Cameron Norman wrote:
> > * the Utopia stack (restart, shutdown, suspend, hibernate, mounting USB
> > d
This policy requirement is only historic. It made sense when the tools
couldn't cope with this situation, which was the case more than a decade
ago. These days, it is actively harmful: it makes debootstrap install junk
if I exclude systemd (as its dependencies have an elevated priority),
greatly
It looks like this bug does mischaracterize CVE-2013-4442. Unlike what's
said here, using /dev/urandom instead of /dev/random (which contrary to
popular wisdom is not an issue) but that, if opening of these two devices
fail, pwgen falls back to using pids and time.
On BSD and Linux/GNU, /dev/uran
Control: severity -1 important
I have split two parts into separate bugs, I think the remainder are ok:
CVE-2013-4440 non-tty passwords are trivially weak by default
* #725507, my assessment: grave
CVE-2013-4441 Phonemes mode has heavy bias and is enabled by default
* works as designed
CVE-2013-4
Package: base-files
Version: 7.10
Severity: grave
W: Failure trying to run: chroot /tmp/unstable/. dpkg --force-depends
--install /var/cache/apt/archives/base-files_7.10_i386.deb
/var/cache/apt/archives/base-passwd_3.5.36_i386.deb
While #766459 fixed debootstrapping with jessie's debootstrap, I'm
2014 at 01:05:11AM +0100, Adam Borowski wrote:
> > [...]
> > While #766459 fixed debootstrapping with jessie's debootstrap, I'm afraid
> > this doesn't solve most use cases that include upgrading, installation from
> > non-DI or installation in hosting scenar
Hi!
For reasons I explained in #767999, hacking debootstrap to configure
base-passwd and base-files in a specific order is neither sufficient nor
necessary. It does work around the problem for those running debootstrap
from fully upgraded unstable (and if it was uploaded to stable, wheezy)
but do
On Sat, Nov 22, 2014 at 09:09:55PM +0100, Tomasz Buchert wrote:
> On 10/11/14 10:56, Christian Kastner wrote:
> I cannot confirm this bug in both cases I've tried:
>
> * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64
> GNU/Linux)
> * amrhf (Linux 3.14.4.1-bone-armhf.com
On Sun, Nov 23, 2014 at 02:07:42AM +0100, Christian Kastner wrote:
> On 2014-11-23 01:16, Adam Borowski wrote:
> > On Sat, Nov 22, 2014 at 09:09:55PM +0100, Tomasz Buchert wrote:
> >> On 10/11/14 10:56, Christian Kastner wrote:
> >> I cannot confirm this b
On Sun, Nov 23, 2014 at 12:55:22PM +0100, Christian Kastner wrote:
> > I can confirm that is issue exists with 3.17.
> >
> > The syscall is returning ENOKEY where until 3.16 it was returning EPERM.
>
> I am now quite certain that the issue is being caused by this kernel
> commit in 3.17:
>
>
Package: installation-reports
Severity: grave
Justification: fails installation with default settings on popular machines
(probably all)
-- Package-specific info:
Boot method: CD
Image version:
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-ne
Package: efivar
Version: 0.15-3
Severity: serious
I'm afraid the patch 07-num_bits.patch breaks the case of 32-bit userland
on a 64-bit kernel. As far as I know, this is how i386 would get installed
on any non-ancient machine if d-i could get that far (it doesn't for me in
qemu-kvm.x86-64, though
Oh well... patches work better if you actually attach them.
As for history of this issue, there's #773412 and #773007 -- I could have
probably reopened the former.
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contac
On Wed, Feb 04, 2015 at 04:48:23PM -0600, D. Jared Dominguez wrote:
> On Tue, Feb 03, 2015 at 04:40:16PM -0600, Adam Borowski wrote:
> >Package: efivar
> >
> >I'm afraid the patch 07-num_bits.patch breaks the case of 32-bit userland
> >on a 64-bit kernel. As far a
On Wed, Feb 04, 2015 at 05:12:09PM -0600, D. Jared Dominguez wrote:
> On Wed, Feb 04, 2015 at 04:57:52PM -0600, Adam Borowski wrote:
> >If I read that correctly, #773412 fixed i386 on an i386 kernel. As you can
> >see in the dumps above, i386 userland on an amd64 kernel receives a
On Wed, Feb 04, 2015 at 05:36:06PM -0600, D. Jared Dominguez wrote:
> On Wed, Feb 04, 2015 at 05:25:59PM -0600, Adam Borowski wrote:
> >On Wed, Feb 04, 2015 at 05:12:09PM -0600, D. Jared Dominguez wrote:
> >>On Wed, Feb 04, 2015 at 04:57:52PM -0600, Adam Borowski wrote:
&
On Wed, Feb 04, 2015 at 06:04:00PM -0600, D. Jared Dominguez wrote:
> In other words, 32-bit efivar/efibootmgr on 64-bit kernel is going
> to get the same value from the kernel as 64-bit efivar/efibootmgr on
> 64-bit. With the x32 ABI, you're going to see the same value on a
> 64-bit kernel (throug
On Wed, Feb 04, 2015 at 06:04:00PM -0600, D. Jared Dominguez wrote:
> In other words, 32-bit efivar/efibootmgr on 64-bit kernel is going
> to get the same value from the kernel as 64-bit efivar/efibootmgr on
> 64-bit. With the x32 ABI, you're going to see the same value on a
> 64-bit kernel (throug
On Thu, Feb 05, 2015 at 02:58:03AM +0100, Adam Borowski wrote:
> Time to RTFK then.
>[...]
> Thus: on Debian's kernels, any i386 or x32 process will get a 32-bit field.
> Ie, my version of the patch is needed. On kernels compiled without
> CONFIG_COMPAT, Peter Jones'
201 - 300 of 381 matches
Mail list logo
