On Wed, Feb 19, 2025, 11:12 PM M Y wrote:
> > my deployment
>
> It's my desktop machine, not vps.
>
> > you somehow managed to accumulate 20GB worth of filenames.
>
> I've installed PHP only to use composer when might be needed. I don't use
> php. In
Package: sddm
Version: 0.21.0+git20241213.4a9aa2e-1
Severity: normal
Since upgrading to the latest version of sddm and kde on Debian testing,
on reboot, the sddm is showing a very large, anoying virtual keyboard.
Google searches indicate that the root causing is that
InputMethod=qtvirtualkeytobar
It has to be documented under their docs
https://docs.flatpak.org/en/latest/debugging.html#getting-stacktraces-from-a-crash
On Tue, Jan 21, 2025 at 2:51 PM M Y wrote:
> Yep, you are right. I just couldn't find this package. google search only
> gives those first:
> https://gith
Yep, you are right. I just couldn't find this package. google search only
gives those first:
https://github.com/flatpak/flatpak/blob/master/scripts/flatpak-coredumpctl,
https://docs.flatpak.org/en/latest/debugging.html,
https://sources.debian.org/src/flatpak/1.16.0-1/scripts/flatpak-coredumpctl/.
I
https://github.com/flatpak/flatpak/blob/main/scripts/meson.build
https://docs.flatpak.org/en/latest/debugging.html#getting-stacktraces-from-a-crash
The following packages have unmet dependencies:
systemd-coredump : Depends: libsystemd-shared (= 254.22-1~bpo12+1) but
257.1-5 is to be installed
On
Package: fsarchiver
Version: 0.8.7-1+b1
Severity: normal
Debian CI testing has uncovered an incompatibility with e2fsprogs
1.47.2-rc1, as can be seen here[1]. The root cause of the failure of
the test backup-and-restore-ext4.sh is that the -r option of mke2fs has
been removed and replaced with "-
Package: qa.debian.org
Severity: normal
Per
https://qa.debian.org/cgi-bin/vcswatch?package=e2fsprogs
The e2fsprogs repository is blocked because:
Repository size 537583616 exceeds 500 MiB, blocking it
However, this is very clearly not the case:
% git clone https://git.kernel.org/pub/
Package: clang-16
Version: 1:16.0.6-26
Severity: normal
Dear Maintainer,
I was trying to track down a regression reported by the ClusterFuzz
service, and when I try to build the fuzzing reproducer on trixie, it
fails. However, it works on Bookworm. So while I can work around the
problem by usin
Package: src:linux
Version: 6.5.13-1
Severity: normal
Dear Maintainer,
I am running Debian testing in a Parallels VM (6 cores, 8GB memory)
running on Macbook Air M2 15" (10 cores, 24GB memory). gcc13 is
sig faulting when building xfsprogs or the Linux kernel when using make -j6.
Building xfsprog
Package: vim
Version: 2:9.0.1378-2
Severity: important
X-Debbugs-Cc: y...@wien-becs.eu
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Using what?
* What exactly did you do
Starting vim
(or not do)
not
Package: qemu-guest-agent
Version: 1:8.1.2+ds-1~bpo12+1
Severity: serious
Justification: 6
Dear Maintainer,
The problem arose after upgrading from bullseye to bookworm.
All was OK on bullseye, but on bookworm qemu-ga refuse to start with
following messages :
1702295113.963828: debug: disabling c
Package: snapshot.debian.org
Followup-For: Bug #1034000
I'm seeing similar failures for a number for the last three snapshots
listed at:
http://snapshot.debian.org/archive/debian/?year=2023&month=8
Namely for:
* 2023-08-06 09:19:12
* 2023-08-07 15:08:23
* 2023-08-09 03:23:42
As noted in [1]
Package: systemd-sysv
Version: 252.6-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
I was updating the gce-xfstests[1] test appliance to Debian Bookworm from
Debian Bullseye.
[1] https://thunk.org/gce-xfstests
* What exactly did you do (or not do) that was effective
diff -Narup a/debian/patches/gcc-distro-specs.diff
b/debian/patches/gcc-distro-specs.diff
--- a/debian/patches/gcc-distro-specs.diff 2022-10-31 21:50:28.0
+0800
+++ b/debian/patches/gcc-distro-specs.diff 2023-04-07 09:57:08.034297864
+0800
@@ -1,20 +1,19 @@
# DP: Add empty dis
Dear,
The patch git-updates.diff including bug fixes from release/gcc-12 branch have
not been enabled in rules.patch, for gcc-12-12.2.0-14 and -17 (sid and exp).
( see
https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-12-debian/debian/rules.patch
line 15~17 )
To enable git-updates.diff,
d luajit from source
code, and get a global var named globalL, it will success.
Thanks for investigating.
Yibin
Emanuele Rocca 于2022年9月15日周四 17:15写道:
> Hi,
>
> On 15/09 02:35, Z Y wrote:
> > During testing systemtap 4.7 with kernel 5.19, I found it can't resolve
> > some
Package: systemtap
Version: 4.7-1
Package: linux-image-amd64
Version: 5.19.6
During testing systemtap 4.7 with kernel 5.19, I found it can't resolve
some global variables of nginx.
However systemtap 4.7 can resolve them if test with kernel 5.10.
According to output below, systemtap 4.7-1 is only
Package: info
Version: 6.8-4+b1
Severity: important
X-Debbugs-Cc: hud...@hudsonlacerda.com
Dear Maintainer,
GNU Info is not running on my system. It crashes at startup with "Aborted"
message.
It only runs in rare cases ("info man" works, "info" crashes, "info octave"
crashes...).
Terminal emula
Package: iwd
Version: 1.24-1
Severity: important
Dear Maintainer,
After upgrading to iwd 1.24-1, it is crashing on my system. (Dell
XPS-13 with an ath10k/QCA6174/hw3.0 wireless card.) Downgrading to iwd
1.21-3 allows things to work. Restalling iwd 1.24-1 causes it crash
again.
If I run /usr/l
Subject: xfce: Placing windows of programs
Package: xfdesktop4
Version: 4.12.4-2
Severity: normal
File: xfce
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or
*|MC_PREVIEW_TEXT|*
Cardoze & Lindo trae para ustedes la gama más grande de repuestos y
marcas reconocidas del mercado.
https://link.emaildnsservice.com/index.php/campaigns/ae917xlv2ja96/track-url/nq466mr97pa53/46c59b2e8f2be153f5bb1fddbe216d36b2e7d2cf
EQUIPO PESADO
Si eres el dueño de eq
Package: debhelper
Version: 13.4+nmu1
Followup-For: Bug #992469
I can confirm Samuel's analysis. When I tried debugging why building
e2fsprogs was causing a new lintian error:
E: e2fsprogs: systemd-service-file-outside-lib
usr/lib/systemd/system/e2scrub@.service
N:
E: systemd-service-file-outsi
tags 989630 +pending
thanks
I finally had time to investigate this problem. It turns out the only
time this bug manifests is when creating an file system smaller than
(blocksize)**2 bytes (e.g., 16 megabytes when the is block size is
4k).
The bug was introduced almost ten years ago (September 20
On Thu, May 20, 2021 at 05:55:34PM +0200, Cyril Brulebois wrote:
> Paul Gevers (2021-05-20):
> > On 20-05-2021 00:11, Theodore Y. Ts'o wrote:
> >
> > Unfortunately, there was no release.debian.org bug to track this. Due
> > to the current high volume to our li
Ping to the debian-release bug. Do you want me to upload a fix to
this bug where e2fsprogs fails its regression test (and thus its
package build) when armhf and armel are running on a 64-bit ARM
platform, but they were built successfully when run on a 32-bit ARM
builder?
No question this is a rea
On Thu, May 13, 2021 at 09:56:53PM +0100, Marcin Kulisz wrote:
>
> I hope that we're be able to change it, but for me fundamental
> question is if Google is interested in participating in effort to
> keep those packages in Debian main and if so what resources can be
> committed to do so. From my
Package: gnome
Version: 1:3.38+3
Severity: important
X-Debbugs-Cc: robin.verdenal-talli...@laposte.net
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf
Kernel: Linux 5.10.17-v8+ (
Package: bash-completion
Version: 1:2.11-2
Severity: wishlist
X-Debbugs-Cc: laks...@hotmaol.com
Dear Maintainer,
* What led up to the situation?
Couldn't autocomplete commands like "apt install na"
* What was the outcome of this action?
No autocompletion
* What outcome d
On Tue, Oct 27, 2020 at 12:24:51AM +0100, Diederik de Haas wrote:
> Package: f2fs-tools
> Version: 1.11.0-1.1
> Followup-For: Bug #970176
>
> On salsa.d.o it looks like version 1.13 was ready to go, but it appears
> that it just never got uploaded to the archives/sid.
> It would be really welcome
s.ext4 -O
> has_journal,ext_attr,resize_inode,dir_index,filetype,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize,^64bit,^metadata_csum
> /dev/sdl1
> mke2fs 1.44.5 (15-Dec-2018)
> /dev/sdl1 contains a ext4 file system
> last mounted on /mnt o
On Thu, May 21, 2020 at 10:04:54AM +0200, Wilmer van der Gaast wrote:
> I just started a downsizing resize2fs operation over an SSH session
> without screen and then realised how bad an idea that was..
>
> Then found this bug as a confirmation. :-)
>
> It looks like resize2fs (still) doesn't inst
On Mon, Apr 27, 2020 at 09:01:56AM -0700, Igor Dvorzhak wrote:
> Package: e2fsprogs
>
> resize2fs takes extra 90 seconds to resize 2TB boot disk during boot on
> Debian 10 than on Debian 9.
>
> Note that time to create/provision VM instance (gcloud compute instances
> create ...) is the same (aro
Package: approx
Version: 5.10-1
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I was attempting to update as usual using approx
* What exactly did you do (or not do) that was effective (o
On Sun, Apr 12, 2020 at 01:25:49AM -0700, Josh Triplett wrote:
> Package: e2fsprogs
> Version: 1.45.6-1
> Severity: wishlist
> File: /sbin/e2fsck
>
> With a read-only filesystem and the shared_blocks option set, e2fsck
> allows multiply referenced blocks; however, it doesn't like multiple
> refere
On Thu, Apr 02, 2020 at 02:01:26PM +0200, Adam Borowski wrote:
>
> After a lot of output on a damaged filesystem (SD card copied to an image)
> fsck.f2fs dies with:
>
> - File name : mkfs.ext3.dpkg-new
> - File size : 6 (bytes)
>
> Program received signal SIGSEGV, Segmentation f
On Mon, Mar 23, 2020 at 11:47:58PM -0400, Scott Kitterman wrote:
> > If you can't fix postfix's flaky autopkg test, can you please revert the
> > explicit dependency on e2fsprogs?
>
> I've asked in #debci to see if they have any suggestions about the pty
> shortage on arm64.
Thanks; it looks lik
Package: postfix
Version: 3.5.0-1
Severity: normal
Postfix autopkgtest on arm64 seems to be super flakey. This is
currently blocking e2fsprogs:
https://qa.debian.org/excuses.php?package=e2fsprogs
https://ci.debian.net/data/autopkgtest/testing/arm64/p/postfix/4630231/log.gz
This seems to be a fa
Package: lintian
Version: 2.58.0
Severity: normal
Dear Maintainer,
Lintian is reporting a number of spurious failures:
E: e2fsprogs-udeb udeb: debian-changelog-file-missing
E: e2fsprogs buildinfo: field-too-long Installed-Build-Depends (5090 chars >
5000)
E: e2fsprogs-udeb udeb: file-in-etc-not
b/debian/control
index 71613e11..69471f45 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: e2fsprogs
Section: admin
Priority: required
Maintainer: Theodore Y. Ts'o
-Build-Depends: gettext, texinfo, pkg-config, libfuse-dev [linux-any
kfreebsd-any] , libattr1-dev, de
On Tue, Mar 10, 2020 at 05:57:33AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: e2fsprogs
> Version: 1.45.5-2
>
> Idea: make a new file
> /usr/share/doc/e2fsprogs/Year2038warnings
> that would say:
>
> If you get
> ext4 filesystem being mounted at ... supports timestamps until 2038
> (0x7fff)
On Tue, Mar 10, 2020 at 05:10:29AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: e2fsprogs
> Version: 1.45.5-2
> File: /usr/share/man/man8/mke2fs.8.gz
>
> Please add to the mke2fs man page:
>
> ** This version of mke2fs is guaranteed to make filesystems that
>support timestamps *beyond* 2038. **
On Wed, Jan 22, 2020 at 09:27:01AM +0100, Cyril Brulebois wrote:
> You can upload. And no, it will stay in p-u-new until it's approved by
> some SRM, at which point it will be made available in
> stable-proposed-updates (note word order), until the point release.
Great, thanks!
And thanks for cor
Oh, one more question. Is a source-only upload OK? I'm still a bit
confused when a source-only upload is required, and when a binary
upload is required? Is the latter only for the NEW queue?
- Ted
On Tue, Jan 21, 2020 at 07:57:54PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
>
> On Thu, 2020-01-09 at 22:34 -0500, Theodore Y. Ts'o wrote:
> > +e2fsprogs (1.44.5-1+deb10u3) buster; urgency=medium
> > +
> > + * Fix CVE-2019-5188: potential s
: potential stack underflow in e2fsck (Closes: #948508)
+ * Fix use after free in e2fsck (Closes: #948517)
+
+ -- Theodore Y. Ts'o Thu, 09 Jan 2020 20:19:57 -0500
+
e2fsprogs (1.44.5-1+deb10u2) buster-security; urgency=high
* Fix CVE-2019-5094: potential buffer overrun in e2fsck (Closes: #9
Package: e2fsprogs
Version:
Severity: grave
Tags: security
Justification: user security hole
E2fsprogs 1.45.5 contains a bug fix for a use after free which could
potentially be used to run malicious code if a user can be tricked into
running e2fsck on a maliciously crafted file system. The follo
Package: e2fsprogs
Version: 1.43.4-2+deb9u1
Severity: grave
Tags: security
Justification: user security hole
E2fsprogs 1.45.5 contains a bug fix for CVE-2019-5188 / TALOS-2019-0973.
The following commits need to be backported to address this
vulnerability in Debian Buster and Debian Stretch:
8dd7
On Mon, Jan 06, 2020 at 12:39:52AM -0800, Josh Triplett wrote:
> That's an *additional* delay, on top of the sleeps above. The two-second
> sleep in the "exitcode" function seems like the primary culprit. Note
> that I don't even have lvm2-tools installed.
Ah, yes, sorry, I had missed the sleep i
On Sat, Jan 04, 2020 at 07:57:16PM -0800, Josh Triplett wrote:
> Package: e2fsprogs
> Version: 1.45.4-1
> Severity: important
>
> The e2fsprogs package installs a service and timer to run e2scrub. That
> service sleeps for 2 seconds before exiting, delaying the boot by 2
> seconds.
It's not neces
Package: iwd
Version: 1.2-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I upgraded my Debian testing system to the latest version of Bullseye,
and I was completely unable to connect to wireless. In the logs, I see
that iwd is crashing:
Dec 12 09:40:11 lambda kernel:
On Wed, Nov 13, 2019 at 11:38:55AM +0100, Svante Signell wrote:
> Source: e2fsprogs
> Version: 1.45.4-1
> Severity: important
> Tags: patch
> Usertags: hurd
> User: debian-h...@lists.debian.org
>
> Hello,
>
> The latest version of e2fsprogs in sid, 1.45.4-1, FTBFS on GNU/Hurd due to two
> reasons
On Sun, Nov 03, 2019 at 11:09:00AM -0800, Darrick J. Wong wrote:
>
> Because if you don't do that, the e2scrub process gets started with fd 0
> mapped to stdout of ls_targets on account of the "ls_targets | while
> read tgt" loop. Yay bash. I guess the problem here is that
> e2scrub_all's stdin
On Sun, Nov 03, 2019 at 05:07:22AM +0100, gregor herrmann wrote:
>
> Cron sends me the following mail once per week:
>
> /sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or
> directory
Gregor, thanks for the bug report! This is coming from:
stdin="$(realpath /dev/stdin
On Mon, Oct 14, 2019 at 10:12:34AM -0700, Jaegeuk Kim wrote:
> On 10/14, Theodore Y. Ts'o wrote:
> > Control: tag 942121 +upstream
> >
> > Hi Chao, Jaeguk,
> >
> > Could you take a look at this complaint and let me know if I should
> > close the bu
Control: tag 942121 +upstream
Hi Chao, Jaeguk,
Could you take a look at this complaint and let me know if I should
close the bug as Working As Intended or not?
The concern seems to be that for desktop distros (which I know was not
f2fs's original target), some users update their kernels frequent
Package: debian
Version: 1.44.5-1+deb10u1
Severity: grave
Tags: security
Justification: user security hole
E2fsprogs 1.45.4 contains a bugfix for CVE-2019-5094 / TALOS-2019-0887.
We need to backport commit 8dbe7b475ec5: "libsupport: add checks to
prevent buffer overrun bugs in quota code" to the v
On Fri, Sep 20, 2019 at 11:40:30PM +0200, Francesco Poli wrote:
>
> Hello Thorsten, hello Theodore,
> I am another user who began receiving the same error messages from cron
> on a box with LVM, but without systemd.
It's only going to happen if you aren't using systemd, since if you
are using sys
On Sat, Sep 14, 2019 at 02:42:29PM +0200, Thorsten Glaser wrote:
> Package: e2fsprogs
> Version: 1.45.3-4
> Severity: minor
>
> From: Cron Daemon
> Message-ID: <20190914011004.3afc6220...@tglase.lan.tarent.de>
> To: r...@tglase.lan.tarent.de
> Date: Sat, 14 Sep 2019 03:10:04 +0200 (CEST)
> Subjec
Package: flowblade
Version: 2.2-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I installed flowblade, and then tried to start it. It failed to start;
I expected it to start and be usable. :-)
% flowblade
FLOWBLADE MOVIE EDITOR 2.2
--
Launch s
Control: tags -1 +pending
On Wed, Oct 18, 2017 at 10:31:31AM -0400, Theodore Ts'o wrote:
> On Tue, Oct 17, 2017 at 01:56:32PM -0400, Michael Stone wrote:
> > I'd like the fuse2fs package to gain the norecovery option so that read-only
> > sources with dirty journals can be mounted via fuse. This s
Control: tags -1 +pending
Control: severity -1 normal
On Sun, Aug 18, 2019 at 04:16:25AM +0200, Mikhail Morfikov wrote:
> There's no error indicating what could be wrong.
>
> Looking through the /usr/sbin/e2scrub_all file, I noticed the following line:
>
> local devices=$(lvs -o lv_path --nohead
Package: marco
Followup-For: Bug #885947
Version: 1.22.2-1
Dear Maintainer.
> This might really be a X driver specific issue.
Perhaps, but as I said in message #30 "The PC woks fine in Debian 9, and
too in Debian 10 testing with mate 1.18.1-3, just until I update to the
following versions."
Me
Package: marco
Followup-For: Bug #885947
Version: 1.22.2-1
Dear Maintainer, after updating marco to the latest version 1.22.2-1 and
returning the default Window Manager from metacity to marco and restart,
follow the same problem.
Even on a clean disk, after installing a fresh DVD image from scrat
On Wed, Jan 11, 2017 at 09:27:26AM +0100, Helmut Grohne wrote:
> Source: xzgv
> Version: 0.9.1-4
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> xzgv fails to cross build from source, because it uses build
> architecture build tools. Simply adding the host architecture triplet
ogs-1.44.5/debian/changelog 2018-12-15 22:46:49.0 -0500
+++ e2fsprogs-1.44.5/debian/changelog 2019-08-02 23:49:00.0 -0400
@@ -1,3 +1,9 @@
+e2fsprogs (1.44.5-1+deb10u1) buster; urgency=medium
+
+ * Fix e4defrag crashes on 32-bit architectures (Closes: #920767)
+
+ -- Theodore Y. Ts
Oh, one more question --- should I be doing a source-only, or binary
push when I push to buster-proposed-updates.
I'm a bit confused about whether it will be going into the NEW queue,
and hence require a binary push, or a source-only build because that's
the new hotness and it's required for promo
On Sat, Aug 03, 2019 at 04:08:14PM +0100, Adam D. Barratt wrote:
>
> I assume this is simply a case of an outdated chroot pointing at
> "stable" or similar. The net effect is that the upload ended up in NEW
> (presumably as buster's e2fsprogs builds additional binary packages
> relative to stretch
-1.44.5/debian/changelog 2018-12-15 22:46:49.0 -0500
+++ e2fsprogs-1.44.5/debian/changelog 2019-08-02 23:49:00.0 -0400
@@ -1,3 +1,9 @@
+e2fsprogs (1.44.5-1+deb9u1) stretch; urgency=medium
+
+ * Fix e4defrag crashes on 32-bit architectures (Closes: #920767)
+
+ -- Theodore Y. Ts
On Fri, Aug 02, 2019 at 02:09:03PM +1000, Ralph Ronnquist wrote:
> Well,
>
> when I then "agt-get install libuuid1:i386" (on this multiarch)
> I get advice about a page full of packages to be removed, and the
> following (plus a bit more):
> ---
> WARNING: The following essential packages will be
On Fri, Aug 02, 2019 at 11:25:10AM +1000, Ralph Ronnquist wrote:
> Package: libuuid1
> Version: 2.34-0.1
>
> The package is declared to replace e2fsprogs, which it doesn't do.
> Rather, installing it has a fair few ramifications on the installed system.
>
> The package belongs to the util-linux s
Phillip,
Peace.
You may not like the fact that David Oberhollenzer (GitHub username
AgentD) started an effort to implement a new set of tools to generate
squashfs images on April 30th, 2019, and called it squashfs-tools-ng.
However, it's really not fair to complain that there is a "violation
of
On Wed, Jul 31, 2019 at 04:22:35PM +0100, Ian Jackson wrote:
> Submodules are intensely frustrating[1]. One way they are frustrating is
> that it is not clear even what it means for a .dsc to be identical to
> a git tree which has submodule references. Are the submodules
> supposed to be populate
OK, I've upload 1.15-1, so let's not rewrite the history on Salsa any
more. :-)
Thanks!!
- Ted
On Tue, Jul 30, 2019 at 05:54:37PM +0200, Domenico Andreoli wrote:
> Edited history again, just fixed the typo in the only patch. I could
> not find any other low hanging fruit, anything else requires some
> investigation (included the warnings on debian/copyright)
Well, debian-watch-uses-insecure
On Mon, Jul 29, 2019 at 10:32:38AM -0400, Theodore Y. Ts'o wrote:
> On Mon, Jul 29, 2019 at 02:51:49PM +0200, Domenico Andreoli wrote:
> >
> > Here it is: https://mentors.debian.net/package/dwarves-dfsg
> >
> > I found not useful to reuse your git history as-i
On Mon, Jul 29, 2019 at 02:51:49PM +0200, Domenico Andreoli wrote:
>
> Here it is: https://mentors.debian.net/package/dwarves-dfsg
>
> I found not useful to reuse your git history as-is, although I could
> not drop your changelog entry ;)
It looks like you did merge in my git changes, though? H
On Sun, Jul 28, 2019 at 06:21:57PM +0200, Helmut Grohne wrote:
> Hi Ted,
>
> On Sun, Jul 28, 2019 at 10:04:48AM -0400, Theodore Y. Ts'o wrote:
> > Yes, I had noticed that this was breaking some of the ports build as
> > well, and so I have a similar patch in my tree al
control: -1 tags +pending
On Sun, Jul 28, 2019 at 08:09:22AM +0200, Helmut Grohne wrote:
> Source: e2fsprogs
> Version: 1.45.3-3
> Severity: important
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> e2fsprogs fails to cross build from source, since the -3 upload, becaus
On Thu, Jul 25, 2019 at 07:03:50PM +0200, Domenico Andreoli wrote:
> Hi Theodore,
>
> apologies, I'll prepare a new upload. Would you mind sponsoring it?
Sure, I'd be happy to sponsor it.
- Ted
Control: tags -1 +pending
On Wed, Jul 24, 2019 at 05:17:28PM +0200, Thorsten Glaser wrote:
>
> 355 tests succeeded 1 tests failed
> Tests failed: f_pre_1970_date_encoding
>
> I assume this is because x32 is a 32-bit (ILP32) architecture
> with 64-bit time_t.
Thanks for the bug report. This
On Wed, Jul 24, 2019 at 05:46:50AM +0200, Sven Joachim wrote:
> Package: logsave
> Version: 1.45.3-1
> Severity: serious
>
> Installing logsave without upgrading e2fsprogs fails:
>
> ,
> | Preparing to unpack .../logsave_1.45.3-1_amd64.deb ...
> | Unpacking logsave (1.45.3-1) ...
> | dpkg: er
On Wed, Jul 24, 2019 at 05:52:48AM +0200, Sven Joachim wrote:
> Package: logsave
> Version: 1.45.3-1
>
> Like the package it partially replaces (e2fsprogs), logsave should be
> Multi-Arch: foreign. The initramfs-tools-core package will have to
> depend on logsave, which makes cross-grades (say, f
Control: tags 932855 +pending
Control: tags 932859 +pending
Control: tags 932861 +pending
Control: tags 932881 +pending
Control: tags 932888 +pending
My apologies, I hadn't realized initramfs had a dependency on logsave.
I guess I should have known that, but it had slipped my mind. This
will be f
control: -1 +pending
On Sun, Jul 21, 2019 at 01:27:38PM +0200, Laurent Bigonville wrote:
>
> The cronjob (/etc/cron.d/e2scrub_all) file is a conffile, that means
> that if the package is removed without being purge, the cronjob will
> still be installed, but the executable will not.
>
> The cron
This Lintian check is also a false positive for e2fsprogs, where it's
triggering 4 false positive Lintian errors.
Per
https://lintian.debian.org/tags/package-supports-alternative-init-but-no-init.d-script.html:
This lintian tag has:
Emitted (non-overridden): 787, overridden: 22, total: 809
A
Package: e2tools
Version: 0.0.16-6.1+b2
Severity: wishlist
The original source for e2tools has disappeared (the home.earthlink.net
pages is dead), but it looks like there is activity at:
https://github.com/ndim/e2tools
Hans has modernized the package, fixing the FSF's address in the
copyright no
Control: tags -1 +pending
On Wed, Feb 27, 2019 at 03:01:52AM +, Dmitry Bogatov wrote:
>
> Package: e2fsprogs
> Version: 1.44.5-1
> Severity: normal
>
> Dear Maintainer,
>
> for long time e2fsprogs were essential, and bin:initscripts used
> /sbin/logsave from e2fsprogs. Nowdays, e2fsprogs ar
Package: gcc-8
Version: 8.3.0-19
Severity: normal
Dear Maintainer,
The e2fsprogs package is currently not reproducible. See:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/e2fsprogs.html
This is caused by an unfortunate interaction between LTO and the flags
from dpkg-buildf
Package: dwarves
Version: 1.12-2
Severity: normal
Tags: patch
Dear Maintainer,
There is a newer version of dwarves upstream (1.14). Version 1.13 is
needed to build the latest kernels with CONFIG_DEBUG_INFO_BTF.
Please consider merging the debian/master branch from:
https://salsa.debian
Dear Andreas,
Ok, great. Will try to fix that unit test thing upstream for next time.
Best,
Julien.
On Tue, Mar 12, 2019 at 3:18 PM Andreas Tille wrote:
> Hi Julien
>
> On Tue, Mar 12, 2019 at 11:56:49AM +0100, Julien Y. Dutheil wrote:
> > Ok, I have committed a patch removin
Dear Andreas,
Ok, I have committed a patch removing the test. But just realized I did not
update the changelog... should that now be version 2.4.1-3?
Cheers,
Julien.
On Tue, Mar 12, 2019 at 11:03 AM Andreas Tille wrote:
> On Tue, Mar 12, 2019 at 09:53:10AM +0100, Julien Y. Dutheil wr
that appears in
the changelog file) ? That one is now deprecated.
Best regards,
Julien.
On Fri, Mar 8, 2019 at 9:36 AM Julien Y. Dutheil
wrote:
> Dear Andreas,
>
> Will give it a look asap.
>
> Best,
>
> Julien.
>
> On Fri, Mar 8, 2019 at 9:34 AM Julien Yann Dutheil <
41 0.563041
>> 0.813833 0.813833
>> 0.194868 0.194868
>> 0.801315 0.801315
>> 0.444785 0.514541 0.514541
>> 0.137341 0.15071 0.15071
>> 0.219281 0.231066 0.231066
>> 0.759382 0.828058 0.828058
>> 0.549516 0.48858 0.48858
>> 0.925583 0.926483 0.926483
Package: marco
Followup-For: Bug #885947
Version: 1.20.3-1
(I send this out of reporbug because I can not use it because due to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905737)
Dear Maintainer, on the regular disk, after updating marco to the
latest version 1.20.3-1 and returning the d
Package: dpkg
Version: 1.18.25
Severity: normal
Dear Maintainer,
dpkg uses memset() on line 100 of lib/dpkg/pager.c, but is
not included
-- System Information:
Debian Release: 9.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
K
Regarding in-kernel recovery "being good enough". The reason why some
file systems and system administrators prefer to run fsck at boot,
even you can there is "in-kernel recovery", is that journal/log replay
only works on an unclean shutdown.
However, sometimes there are can be file system incons
On Thu, Dec 20, 2018 at 03:17:03PM -0500, Daniel Kahn Gillmor wrote:
>
> I wonder whether we can rule out any interaction with gpg-agent itself
> -- does "echo getpin | pinentry-gnome3" itself fall back to curses on
> your system when nfs-kernel-server is installed?
I can confirm that that I did
On Sun, Dec 16, 2018 at 10:35:55AM +, Simon McVittie wrote:
> >* Fix mk_cmds so it works on a usrmerge system when e2fsprogs is built
> > on a non-usrmerge system (Closes: #914087)
>
> In the interests of avoiding inaccurate information, this bug was actually
> the other way round: th
On Sat, Dec 01, 2018 at 12:23:51AM +, Gong S. wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> >Can you tell what version of the kernel you are using?
> 4.19.0-trunk-amd64. I guess that I am not getting any semblance of support
> with an experimental kernel.
> However, when I up
tags 916188 +pending
thanks
Thanks for sending the patch. I've applied it to the e2fsprogs maint
branch.
- Ted
1 - 100 of 952 matches
Mail list logo