[Bug 1032831] upstream patch:
Here's the likely upstream patch: http://thread.gmane.org/gmane.comp.gnu.gzip.bugs/699/focus=705 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1032831 Title: zgrep -NUM doesn't work if NUM is two digits or greater To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1032831/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 955624] Re: md5sum command calculate different code for the same file
Birol Bora wrote: The problem is being caused by faulty memory. I scanned the memory with a memory test tools. I've found a memory card is defective and replaced with a new one. Problem solved. ** Changed in: coreutils (Ubuntu) Status: New = Invalid Thanks for letting us know. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/955624 Title: md5sum command calculate different code for the same file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/955624/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 955624] [NEW] md5sum command calculate different code for the same file
Birol Bora wrote: Public bug reported: I'm using Ubuntu 11.10 When I execute md5sum command its calculate different code for the same file birol@trax:~/Downloads$ uname -a Linux trax 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux birol@trax:~/Downloads$ ls -l v1.img -rw-rw-r-- 1 birol birol 1796509184 2012-03-15 01:36 v1.img birol@trax:~/Downloads$ md5sum v1.img e8a2c652770a2da0fd93c981a79a8ba1 v1.img birol@trax:~/Downloads$ md5sum -b v1.img d692965aa21d43b40e7c6e821f721159 *v1.img birol@trax:~/Downloads$ md5sum v1.img baa9389d2ecfecf8d405a22565d1565b v1.img birol@trax:~/Downloads$ md5sum v1.img e683b1e5bba99dee3ecd35765f0fc368 v1.img birol@trax:~/Downloads$ md5sum v1.img ee0d31564b0a0508e83766c31fc18236 v1.img birol@trax:~/Downloads$ md5sum v1.img 0c821ea3600f13c5b9d14fc12f329773 v1.img birol@trax:~/Downloads$ ls -l v1.img -rw-rw-r-- 1 birol birol 1796509184 2012-03-15 01:36 v1.img Thanks for the report. I've seen this sort of problem a couple of times. So far, every time it has been due to faulty hardware. To cross-check try running the openssl command: openssl md5 v1.img -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/955624 Title: md5sum command calculate different code for the same file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/955624/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 908354] Re: tail -0f /var/log/kern.log never prints anything (livecd cow overlayfs)
[ following up to this report, http://bugs.launchpad.net/+source/coreutils/+bug/908354 ] Tuomas Heino wrote: ubuntu@ubuntu:~$ stat -f --format %t:%T /var/log 1021994:tmpfs Thanks. Unlike most file system types, overlayFS appears to have no magic number. Now we're seeing how using files on such a file system can cause trouble. I see no direct way to distinguish this file (for which inotify does not work) from any other on a tmpfs file system, for which inotify works just fine. Ugly work-around: tail -f could try using both inotify and polling, and, eventually, if polling spots a change for which there was no inotify event, it would give up on using inotify for that file. As soon as tail sees an inotify event for a file, however, it could not stop polling: for most remote FS types, inotify works with changes generated locally, but not with those generated remotely. So polling can still be useful when using inotify. We'll see... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/908354 Title: tail -0f /var/log/kern.log never prints anything (livecd cow overlayfs) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/908354/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 908354] [NEW] tail -0f /var/log/kern.log never prints anything (livecd cow overlayfs)
Tuomas Heino wrote:
Public bug reported:
Doing tail -f on /var/log/kern.log (which gets appended every 10 seconds)
does not print anyting.
May be an issue with the livecd / how overlayfs works. In any case tail
should at least complain if underlaying fs does not properly support whatever
-f needs to work (inotify below?):
open(/var/log/kern.log, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0640, st_size=1095, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
lseek(3, 0, SEEK_END) = 1095
fstat(3, {st_mode=S_IFREG|0640, st_size=1095, ...}) = 0
fstatfs(3, {f_type=0x1021994, f_bsize=4096, f_blocks=2042790,
f_bfree=2003669, f_bavail=2003669, f_files=2042790, f_ffree=2041029,
f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
inotify_init() = 4
inotify_add_watch(4, /var/log/kern.log,
IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1
fstat(3, {st_mode=S_IFREG|0640, st_size=1095, ...}) = 0
read(4,
Thanks for the report.
In upstream coreutils development I've just made a change to fix that:
if the type of FS is unknown, it uses polling rather than inotify.
What does this print for that system?
$ stat -f --format %t:%T /var/log
If it is a new non-local file system type, then we should add it
to stat.c's table.
In the mean time, you can use tail's deliberately undocumented
---disable-inotify option.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908354
Title:
tail -0f /var/log/kern.log never prints anything (livecd cow
overlayfs)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/908354/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 833587] Re: du assert failure: du:du.c :583 : process_file:L'assertion« level== prev_level -1 »aéchoué.
https://bugs.launchpad.net/bugs/833587 Title: du assert failure: du: du.c :583 : process_file: L'assertion « level == prev_level - 1 » a échoué. ... ProblemType: Crash DistroRelease: Ubuntu 11.04 Package: coreutils 8.5-1ubuntu6 ... AssertionMessage: du: du.c :583 : process_file: L'assertion « level == prev_level - 1 » a échoué. Thanks for the report. That was probably fixed by this change: * Noteworthy changes in release 8.10 (2011-02-04) [stable] ** Bug fixes du would abort with a failed assertion when two conditions are met: part of the hierarchy being traversed is moved to a higher level in the directory tree, and there is at least one more command line directory argument following the one containing the moved sub-tree. [bug introduced in coreutils-5.1.0] -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/833587 Title: du assert failure: du: du.c :583 : process_file: L'assertion « level == prev_level - 1 » a échoué. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/833587/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 868747] Re: fmt -f unlimited should be supported
jimav wrote: Strictly speaking this is an enhancement request. fmt imposes an artificial limit on the maximum output line length controlled by the -f option, which prevents using this tool to join You meant -w, not -f, throughout. Thanks for the suggestion. Note that the code has this: /* Size of paragraph buffer, in words and characters. Longer paragraphs are handled neatly (cf. flush_paragraph()), so long as these values are considerably greater than required by the width. These values cannot be extended indefinitely: doing so would run into size limits and/or cause more overflows in cost calculations. FIXME: Remove these arbitrary limits. */ #define MAXWORDS1000 #define MAXCHARS5000 where MAXCHARS/2 specifies the largest width. I.e., fmt -w 2500 works, but not 2501. We agree that there should not be such a limit. But the internals of fmt are not pretty -- significantly less so than most other parts of the coreutils, and as the comment says we cannot easily increase them arbitrarily. In the mean time what can you do if you want truly unlimited-length paragraphs? It's not trivial since you want to retain paragraph delimiters. This perl command should do the trick. It processes your input a paragraph at a time, replacing each newline (and spaces before/after) with a single space: perl -00ple 's/\s*\n\s*/ /g' E.g., given this input, 1 2 3 4 1 2 3 4 5 It prints this: $ (seq 4; echo; seq 5) | perl -00ple 's/\s*\n\s*/ /g' 1 2 3 4 1 2 3 4 5 It doesn't preserve indentation, but if you're just going to paste it into libreoffice, that should be fine. I've Cc'd the upstream bug-tracker, so we'll have a bug number there, too. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/868747 Title: fmt -f unlimited should be supported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/868747/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 784758] Re: Wrong documentation for 'od'
C de-Avillez wrote: Upstream has been faster on the uptake than I was. I had just tested coreutils GIT, and found the same issue, and was preparing an email to bugs-coreutils (and finding who are the translators for French). I should have done that already... instead I initially thought it was an Ubuntu translation issue. Ah well. But Jim checked, and found that 12 locales are affected by this; he additionally found some other changes needed in a few locales. I am adding a link to his email. Oh, sorry I didn't Cc this bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/784758 Title: Wrong documentation for 'od' -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 591969] Re: dd: cryptic error message when bs=unreasonably large value
Dave Gilbert wrote: Just reading the patch, I'm not sure that's solving both cases - i.e. 1) That there is a problem if your value is too large for RAM (i.e. a memory exhausted) 2) There is something saying 'invalid number' on large values, and that seems to depend on the word size of the host. I think the original reporter was confused by case (2); IMHO 'Memory Exhausted' is enough diagnostics for (1). Thanks for the feedback. If you can demonstrate a precise problem, please report it. -- dd: cryptic error message when bs=unreasonably large value https://bugs.launchpad.net/bugs/591969 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 591969] Re: dd: cryptic error message when bs=unreasonably large value
Imre Péntek wrote:
vasárnap 13 június 2010 23:23:39 dátummal Ön az alábbiakat írta:
Making dd give a better diagnostic for e.g., bs=3G on an i686
system might be more work than it's worth.
Well, this way it's okay that dd does not accept 3G as block size, but then
man dd would document that according to the appropriate behavior.
Like this:
BYTES may be followed by the following multiplicative suffixes: c =1, w =2,
b=512, kB =1000, K =1024, MB =1000*1000, M=1024*1024, xM =M
GB=1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.
The same applies to BLOCKS with the practical exception your
machine(?)/kernel(?)/... needs to be able to allocate memory for (at
least(???)) one(?) block, so, you can expect not to be able to use block sizes
greater or equal to 2G on a 32 bit architecture, and 16E on a 64 bit
architecture.
or something like this. what I read now in man dd is a partial documentation
which would (and had) me expect bs=3G to be OK in all cases, however it isn't
ok in my case.
Thanks for the suggestion, but we can't use that, since
dd --help content has to stay small and generally relevant.
[btw, the man page is generated from dd --help's output. ]
Using such large buffer sizes is neither common nor worth
documenting in a place like --help.
To improve the real documentation -- that's always welcome --
you would add to info dd (patch doc/coreutils.texi in the sources)
saying something like Any block size you specify via bs=, ibs=, obs=, cbs=
should not be too large --- values larger than a few megabytes
are generally wasteful or (as in the gigabyte..exabyte case) downright
counterproductive or error-inducing.
While I deliberately do not mention the actual limits above,
note that they're about half of the numbers you listed: ~1GiB and ~8EiB
I went ahead and wrote the patch:
From d8e0d2d0efba4fa9c5bc1c29bf7e0028dd292237 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 14 Jun 2010 10:15:57 +0200
Subject: [PATCH] doc: dd: discourage use of very large block sizes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* doc/coreutils.texi (dd invocation): Warn against using a very large
block size. Suggested by Imre Péntek.
---
doc/coreutils.texi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 26b4eba..102ceaf 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8020,6 +8020,11 @@ dd invocation
@samp{w}=2, @sam...@var{m}}=@var{m}, or any of the
standard block size suffixes like @samp{k}=1024 (@pxref{Block size}).
+Any block size you specify via @samp{bs=}, @samp{ibs=}, @samp{obs=},
@samp{cbs=}
+should not be too large---values larger than a few megabytes
+are generally wasteful or (as in the gigabyte..exabyte case) downright
+counterproductive or error-inducing.
+
Use different @command{dd} invocations to use different block sizes for
skipping and I/o...@. For example, the following shell commands copy data
in 512 KiB blocks between a disk and a tape, but do not save or restore a
--
1.7.1.511.g2f531
--
dd: cryptic error message when bs=unreasonably large value
https://bugs.launchpad.net/bugs/591969
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 412069] Re: stat reports wrong fundamental block size
As far as I can see, there is no problem with code being out of sync. If you can point to specifics, please let me know, since I'm about to release coreutils-7.5 upstream. However, note that with glibc and a linux kernel, the stat program always uses statfs, and not statvfs. This is a deliberate decision taken at configure time. Details in comments here: http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/fsusage.m4#n50 However, the version of statvfs that forced us into this corner dates back to 2003: http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=eda39b870b7a849271 If someone does the legwork to determine whether that statvfs bug has been fixed, and if so, since when, we should be able to write a configure test to use glibc's statvfs when it's known not to be buggy. -- stat reports wrong fundamental block size https://bugs.launchpad.net/bugs/412069 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 370065] Re: sort seg faults
I fixed that upstream with this change: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=25eb4c69097ca4f5665b050cfa4247a19ffd8c55 -- sort seg faults https://bugs.launchpad.net/bugs/370065 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 154602] Re: incorrect cp(1) behaviour upon mkdir foo; cp -r foo foo
C de-Avillez wrote: Interesting. Jim Meyring's answer did not make it here (although, AFAICS, it was correctly addressed). So, here it is: Thanks for forwarding that. It didn't go through because I sent it with a From address not matching the subscribed one. -- incorrect cp(1) behaviour upon mkdir foo; cp -r foo foo https://bugs.launchpad.net/bugs/154602 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 200234] Re: nice crashed with SIGSEGV in qsort()
nice doesn't call qsort directly, but rather only via libc's setlocale function. As such, I suggest you reassign this report to glibc. -- nice crashed with SIGSEGV in qsort() https://bugs.launchpad.net/bugs/200234 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 119819] Re: scanimage -L crashes with HP ScanJet 4100c
Hi, I had the same problem and have just worked around it. Here's the report w/patch I've just sent upstream: http://thread.gmane.org/gmane.comp.graphics.scanning.sane.devel/12601 -- scanimage -L crashes with HP ScanJet 4100c https://bugs.launchpad.net/bugs/119819 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 59083] fchownat ignores AT_SYMLINK_NOFOLLOW flag
Public bug reported: already reported here: https://lists.ubuntu.com/archives/ubuntu- users/2006-September/093218.html ** Affects: glibc (Ubuntu) Importance: Untriaged Status: Unconfirmed -- fchownat ignores AT_SYMLINK_NOFOLLOW flag https://launchpad.net/bugs/59083 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48917] Re: shred manpage is mangled.
Thanks for the report. I've just fixed this upstream: 2006-08-13 Jim Meyering [EMAIL PROTECTED] * src/shred.c (usage): Don't indent the second line of an item. Otherwise, help2man would misformat the output. Reported by Adam Buchbinder in https://launchpad.net/bugs/48917. -- shred manpage is mangled. https://launchpad.net/bugs/48917 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
