Bug#1004311: pahole segfaults during kernel build
Package: pahole Version: 1.22-2 Severity: normal Dear Maintainer, Building an upstream kernel reliably segfaults in pahole, starting with 1.22-2. I just downgraded to 1.22-1 (from snapshot.do) and that does *not* have this problem. I don't immediately see a changelog entry that could explain this problem. Greetings, Andres Backtrace from core file: #0 type__compare_members (b=0x55a9260432b0, a=0x55a925f8ce70) at ./pahole.c:216 216 ./pahole.c: No such file or directory. (gdb) bt #0 type__compare_members (b=0x55a9260432b0, a=0x55a925f8ce70) at ./pahole.c:216 #1 type__compare (cu_a=, cu_b=0x55a925f4b880, b=0x55a9260432b0, a=0x55a925f8ce70) at ./pahole.c:310 #2 __structures__add (class=class@entry=0x55a9260432b0, cu=cu@entry=0x55a925f4b880, id=id@entry=26, existing_entry=existing_entry@entry=0x7ffce1053090) at ./pahole.c:326 #3 0x55a9258f4491 in structures__add (existing_entry=0x7ffce1053090, id=26, cu=0x55a925f4b880, class=0x55a9260432b0) at ./pahole.c:357 #4 print_classes (cu=) at ./pahole.c:524 #5 pahole_stealer (cu=0x55a925f4b880, conf_load=) at ./pahole.c:2859 #6 0x55a925901613 in cu__finalize (conf=0x55a925914100 , cu=0x55a925f4b880) at ./dwarf_loader.c:2477 #7 cus__finalize (cus=0x55a925f47610, cu=cu@entry=0x55a925f4b880, conf=0x55a925914100 ) at ./dwarf_loader.c:2484 #8 0x55a925903ba7 in dwarf_cus__create_and_process_cu (dcus=dcus@entry=0x7ffce10532a0, cu_die=0x7ffce1053250, pointer_size=) at ./dwarf_loader.c:2675 #9 0x55a92590462c in __dwarf_cus__process_cus (dcus=) at ./dwarf_loader.c:2764 #10 dwarf_cus__process_cus (dcus=0x7ffce10532a0) at ./dwarf_loader.c:2778 #11 cus__load_module (cus=cus@entry=0x55a925f47610, conf=, mod=mod@entry=0x55a925f49f00, dw=, elf=elf@entry=0x55a925f476f0, filename=0x7ffce1054a6e ".tmp_vmlinux.btf") at ./dwarf_loader.c:2913 #12 0x55a9259048b1 in cus__process_dwflmod (dwflmod=0x55a925f49f00, userdata=, name=, base=, arg=0x7ffce1053400) at ./dwarf_loader.c:2957 #13 0x7fdc64fe3471 in dwfl_getmodules () from /lib/x86_64-linux-gnu/libdw.so.1 #14 0x55a925900880 in cus__process_file (filename=0x7ffce1054a6e ".tmp_vmlinux.btf", fd=5, conf=0x55a925914100 , cus=0x55a925f47610) at ./dwarf_loader.c:3023 #15 dwarf__load_file (cus=0x55a925f47610, conf=0x55a925914100 , filename=0x7ffce1054a6e ".tmp_vmlinux.btf") at ./dwarf_loader.c:3058 #16 0x55a9258f905f in cus__load_file (cus=cus@entry=0x55a925f47610, conf=conf@entry=0x55a925914100 , filename=0x7ffce1054a6e ".tmp_vmlinux.btf") at ./dwarves.c:2043 #17 0x55a9258f92d8 in cus__load_files (cus=cus@entry=0x55a925f47610, conf=conf@entry=0x55a925914100 , filenames=filenames@entry=0x7ffce10537c0) at ./dwarves.c:2396 #18 0x55a9258f0ba9 in main (argc=4, argv=0x7ffce10537a8) at ./pahole.c:3224 (gdb) Using a pahole built from source I do not see this. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-rc5-andres-00225-g5e9874628080 (SMP w/40 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages pahole depends on: ii libbpf0 1:0.5.0-1 ii libc62.33-3 ii libdw1 0.186-1 ii libelf1 0.186-1 ii zlib1g 1:1.2.11.dfsg-2 pahole recommends no packages. pahole suggests no packages. -- no debconf information
Bug#990092: kmod: Enable zstd support
Package: kmod Version: 28-1 Severity: wishlist Hi, Since version 28 kmod supports zstd compression [1]. As using xz module compression makes building kernels painfully slow, and zstd achieves pretty decent ratios at a much lower compression time, it would be good to have support for that zstd in kmod. Regards, Andres Freund [1] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=3821e1971ec53fa9f2679ea988ee12db61c8 -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-rc6-andres-00267-g913ec3c22ef4 (SMP w/16 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages kmod depends on: ii libc6 2.31-12 ii libkmod2 28-1 ii liblzma5 5.2.5-2 ii libssl1.1 1.1.1k-1 ii lsb-base 11.1.0 kmod recommends no packages. kmod suggests no packages. -- no debconf information
Bug#976373: libpam-modules: RLIMIT_MEMORY set to 1/8th of memory (due to systemd changes)
Package: libpam-modules
Version: 1.3.1-5
Severity: important
Hi,
Since systemd v246 RLIMIT_MEMLOCK, on a clean installation, is set to
1/8th of memory (before that, since v240 it was set to 64MB, instead
of the previous 64KB) for anything going through pam_limit. That's too
high.
The reason for that is that
https://salsa.debian.org/vorlon/pam/-/blob/master/debian/patches-applied/027_pam_limits_better_init_allow_explicit_root#L66
causes rlimits to be copied from the pid 1 whenever pam_limits is used,
and /etc/security/limits.{conf,d} doesn't specify it. The one exception to that
is
RLIMIT_NOFILE that's clamped to FD_SETSIZE via
https://salsa.debian.org/vorlon/pam/-/blob/master/debian/patches-applied/pam-limits-nofile-fd-setsize-cap
The systemd changes leading to this are
https://github.com/systemd/systemd/commit/04d1ee0f7ec7a280136ddf5f3f34d6282a50846d
https://github.com/systemd/systemd/commit/c8884aceefc85245b9bdfb626e2daf27521259bd
Clearly this is very related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917374 but the
consequences are different enough (particularly because the clamping
makes the NOFILE issue fairly harmless).
Regards,
Andres Freund
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-rc5-andres-00354-g464e30a412ac (SMP w/40 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libpam-modules depends on:
ii debconf [debconf-2.0] 1.5.74
ii libaudit1 1:2.8.5-3.1
ii libc6 2.31-5
ii libdb5.3 5.3.28+dfsg1-0.6
ii libpam-modules-bin 1.3.1-5
ii libpam0g 1.3.1-5
ii libselinux13.1-2+b1
libpam-modules recommends no packages.
libpam-modules suggests no packages.
-- Configuration Files:
/etc/security/limits.conf changed [not included]
-- debconf information excluded
Bug#950407: fwupd-refresh.service contains @bindir breaking the unit file
Package: fwupd Version: 1.3.7-1 Severity: important Dear Maintainer, The recent update to 1.3.7-1 contains a broken /lib/systemd/system/fwupd-refresh.service as, what I guess must be a build system snafu, the unit file contains: ExecStart=@bindir@/fwupdmgr refresh --no-metadata-check which doesn't work. Causes errors like /lib/systemd/system/fwupd-refresh.service:17: Neither a valid executable name nor an absolute path: bindir@/fwupdmgr which is a reasonable complaint. Regards, Andres -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-andres-06250-gfbcac2bd7a1f (SMP w/16 CPU cores) Kernel taint flags: TAINT_USER Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages fwupd depends on: ii libc6 2.29-9 ii libefiboot137-2 ii libefivar1 37-2 ii libelf10.176-1.1 ii libfwupd2 1.3.7-1 ii libfwupdplugin11.3.7-1 ii libglib2.0-0 2.62.4-1+b1 ii libgnutls303.6.11.1-2 ii libgpg-error0 1.36-7 ii libgpgme11 1.13.1-6 ii libgudev-1.0-0 233-1 ii libgusb2 0.3.0-1 ii libjson-glib-1.0-0 1.4.4-2 ii libpolkit-gobject-1-0 0.105-26 ii libsmbios-c2 2.4.1-1 ii libsoup2.4-1 2.68.2-1 ii libsqlite3-0 3.31.0+really3.30.1+fossil191229-1 ii libtss2-esys0 2.3.2-1 ii libxmlb1 0.1.14-1 ii shared-mime-info 1.10-1 Versions of packages fwupd recommends: ii bolt 0.8-4 pn fwupd-signed ii python3 3.7.5-3 fwupd suggests no packages. -- no debconf information
Bug#930697: glibc: merge latest upstream 2.28 changes
Source: glibc Version: 2.28-10 Severity: normal Hi, There have been several fixes on the release/2.28/master branch. In particular https://sourceware.org/bugzilla/show_bug.cgi?id=24476 at the moment causes a lot of false positives when using valgrind on applications that don't use dlopen() (postgres in my case). But a few of the other changes since the last upstream merge also seem worth pulling in. Regards, Andres Freund
Bug#908707: llvm-toolchain-7: Enable -DLLVM_USE_PERF=yes when building for linux
Source: llvm-toolchain-7 Severity: wishlist Hi, Since 7 llvm has support for generating perf profiling data for JITed code. That's useful, in my case, to be able to profile postgres 11+ when it uses JIT. Thanks, Andres -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.5-andres (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#903431: binutils: new binutils version breaks valgrind, can't determine stacktraces
Hi,
On 2018-07-09 13:34:44 -0700, Andres Freund wrote:
> after upgrading binutils (from 2.30-22 to 2.30.90.20180705-1) *newly*
> built binaries don't work well with valgrind anymore. Binaries built
> with an older version of binutils, verified by downgrading, continue
> to work well with valgrind.
>
> The stack traces after the upgrade are useless. This both makes using
> valgrind nearly pointless, as well as breaking valgrind suppression
> files (which rely on useful backtraces).
>
> A trivial example is the following:
>
> $ dpkg-query --showformat='${Version}' --show binutils
> 2.30-22
>
> $ cat ~/tmp/uninitialized.c
> int
> main(int argc, char **argv)
> {
> int foo;
>
> if (foo == 3)
> return 0;
> else
> return 1;
> }
>
> $ gcc ~/tmp/uninitialized.c -o uninitialized
> $ valgrind ./uninitialized
> ...
> ==16745== Conditional jump or move depends on uninitialised value(s)
> ==16745==at 0x108609: main (in /home/andres/tmp/uninitialized)
> ..
>
> # dpkg -i *binutils*2.30.90*
>
> $ dpkg-query --showformat='${Version}\n' --show binutils
> 2.30.90.20180627-1
>
> $ gcc ~/tmp/uninitialized.c -o uninitialized
> ...
> ==18603== Conditional jump or move depends on uninitialised value(s)
> ==18603==at 0x109159: ??? (in /home/andres/tmp/uninitialized)
> ==18603==by 0x4CADB16: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
> ...
>
> but if I force gold to be used:
> $ gcc -fuse-ld=gold ~/tmp/uninitialized.c -o uninitialized
> $ valgrind ./uninitialized
>
> ==18665== Conditional jump or move depends on uninitialised value(s)
> ==18665==at 0x108619: main (in /home/andres/tmp/uninitialized)
>
> so this seems somewhat likely to be related to GNU ld changes, rather
> than a valgrind issue. I haven't yet figured out which of the changes
> between the two versions is to blame
Appears to be an issue in valgrind:
https://bugs.kde.org/show_bug.cgi?id=395682#c9
I'll try to reassign the bug to valgrind.
Greetings,
Andres Freund
Bug#841500: gcc-6: Unable to compile upstream kernel with previous .config
On 2016-10-27 06:25:00 +, Niels Thykier wrote: > I believe it is possible to compile the kernel with gcc-5. I hope you > will consider that an acceptable workaround for you in the interim while > we solve #841419. It's quite possible to compile the kernel with a newer gcc as well, you just need to add the necessary CFLAGs. In my build script I've adjusted things to: time make -j8 KCPPFLAGS="-fno-pic -Wno-pointer-sign" and the kernel compiles and runs normally again.
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Hi, On 2016-03-30 06:37:11 +, Alex Reece wrote: > I would love to bump this bug; I think it would be wonderful to have an > alternative version of libc with frame pointers. Yea, I'm hitting this more and more often. Especially with the new eBPF backed profiling tools like bcc, which, for the forseeable future, only support frame pointer based unwinding. Also fp based unwinding is a lot more efficient. > What would it take for such an alternative to exist (can the Debian > alternatives system work for libc)? I was thinking of adding a libc6-frame-pointers which would replace (and conflict with) libc6. But that's just because it was what I could think of. Maybe it'd be better to let those be co-installed by using a different triplet and allow to chose which to use via /etc/ld.so.conf/something? Not pretty either :( > If other people want this, I'm interested in investing some time into > helping with it. Same here. I'd primarily like some guidance about what approach is more likely to be accepted. Greetings, Andres Freund
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Source: glibc Severity: wishlist Hi, When profiling with perf (and even oprofile) showing the call graph can often be invaluable. Unfortunately for anything that goes through libc that's not efficiently possible as glibc (on at least amd64) doesn't build with frame pointers enabled. It is possible to use dwarf unwinding with halfway modern kernel/perf combinations to get call graphs even in that case, but the overhead is about a magnitude higher and the profiles are much larger. As applications have to be built with -fno-omit-frame-pointers anyway to provide usable call stack it's usually not a problem if some library isn't. But as so many things that often are bottlenecks (syscalls, memcpy, string operations, locking, ...) goes through libc it'd be quite valuable to have a variant of libc built with frame pointers enabled. Thanks for considering, Andres -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-andres-09670-g0429fbc (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
On 2014-02-14 13:50:20 +, Ian Jackson wrote: Josselin Mouette writes (Bug#727708: init system coupling etc.): In all cases, it is unacceptable to put the burden of implementing logind on non-systemd systems on maintainers of packages that just need the logind interfaces. If it is not available, software such as gdm3 will depend, directly or indirectly, on systemd as PID 1, and that will be all. Firstly, I think the scenario where the required integration work is not done is unlikely. But in that scenario, we have two choices: (a) Effectively, drop all init systems other than systemd (b) Effectively, drop GNOME Of these, (b) is IMO clearly preferable. Our downstreams can straightforwardly provide a more specific Debian derivative which runs GNOME and (only) systemd. Asking our downstreams to reintroduce support for a non-systemd init system is not feasible. With (b) people who want GNOME and systemd can do that work as a Debian derivative; it is not necessary to fork the whole project. I don't think b) would have any upsides, even if it's only happening for a short time: a) Debian users would loose because the DE (gnome and some others) the use vanishes. We've seen how happy changes around that makes them, and how vocal they can get. Surely entirely removing a DE entirely makes them even more unhappy than substantive change. b) Debian would loose users. c) downstreams would suffer, because they now would need to package $software independently from debian. Collaboration without a common upstream is hard. d) Parties wanting to port/test a piece of software to work without systemd, suddenly need to care about packaging, before their real work can start. Individual developers maybe can get by using source code checkouts and compiling everything themselves, but testers surely not. e) Parties wanting to implement alternatives to systemd's logind, cgroup manager have less software to test. Given those points the only value in suggesting that route is in being a threat gesture against some unspecified party. I think such a gesture is of questionable morality, but even worse, I think it runs counter to your goals of having most software run independently of the init system. I don't see this helping the freedom of debian's users, rather the contrary. I think it makes much more sense to generate policy or a TC statement, that suggests that packagers should apply reasonable patches to help portability (just like they are already asked for porting software to some different linux or other supported architecture). And, quite importantly, try to streamline the process of dealing with escalations to the TC to determine whether a patch is reasonable. If that takes half a year every now and then most people will just give up. Regards, Andres Freund -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
On 2014-02-14 15:46:18 +, Ian Jackson wrote: Ansgar Burchardt writes (Bug#727708: init system coupling etc.): Don't you mean drop GNOME, KDE and others? It's not only GNOME that plans to depend on logind... logind is a red herring because AIUI we already have a technical solution to that. The problem is other things that might be in the pipeline. I am not so sure it's there. The current version runs without systemd but doesn't support everything and more up2date versions don't run at all. There's promise of more work in that direction, but that might be influenced by Ubuntu seemingly also switching in the not too far away future: http://www.markshuttleworth.com/archives/1316 Greetings, Andres Freund -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system coupling etc.
On 2014-02-14 10:14:54 -0800, Steve Langasek wrote: On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote: On 2014-02-14 15:46:18 +, Ian Jackson wrote: Ansgar Burchardt writes (Bug#727708: init system coupling etc.): Don't you mean drop GNOME, KDE and others? It's not only GNOME that plans to depend on logind... logind is a red herring because AIUI we already have a technical solution to that. The problem is other things that might be in the pipeline. I am not so sure it's there. The current version runs without systemd but doesn't support everything Based on what? There is only one new interface in logind between v204 and v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method. Are you telling me that this is a critical feature for desktops, that they won't run correctly without? Nono, that's not what I meant, sorry for being imprecise. Logind calls out to systemd for shutting down. -shim now supports some of that, but the last time I tried logind without systemd but just -shim didn't work fully yet? and more up2date versions don't run at all. There's promise of more work in that direction, but that might be influenced by Ubuntu seemingly also switching in the not too far away future: http://www.markshuttleworth.com/archives/1316 Which says right in that blog entry that: We’ll certainly complete work to make the new logind work without systemd as pid 1. Even supposing that GetUserByPID is critical for jessie, and even supposing that Canonical did not finish the work to make logind work with cgmanager, backporting this one interface to logind 204 will be trivial. There is no excuse at all for Debian getting the compatibility wrong in jessie. (But an awful lot of people who seem eager to make excuses for it. Please don't get me wrong. I don't think compatibility should be dropped in the near future. It's just that Ian argued that gnome requiring logind won't become a problem because of the current state of logind and systemd-shim, and in consequence that forbidding dependencies on interfaces provided only when systemd is present is unproblematic. I don't think the current state warrants that. I think there should be clear language, be it in policy or TC resolution, to suggest that maintainers should accept compatibility patches. But that's it. Greetings, Andres Freund -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736742: tftpd-hpa init script claims to be a tftp client
Package: tftpd-hpa Version: 5.2-14 Severity: minor Hi, tftp-hpa's init script in it's LSB Short-Description claims to be HPA's tftp client. Unstable's version even claims so in the Description... Obviously minor, but it wouldn't hurt to fix it. Regards, Andres Freund -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Thoughts on Init System Debate
On 2014-01-19 23:18:26 -0800, Steve Langasek wrote: As you say that planned features or development could sway your opinion: are there particular features that you have in mind, here? For instance, correcting upstart's socket-based activation interface is on the upstart roadmap in the jessie timeframe. Showing some progress on issues like https://bugs.launchpad.net/upstart/+bug/447654 would excite me far much more than promises about future features. Not fixing issues described as a fundamental design flaw by upstart's original author for several years, without an inkling of progress, is what's causing doubts about upstarts health, at least for me. Greetings, Andres Freund -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730134: [Pkg-postgresql-public] Bug#730134: Compile with -fno-omit-frame-pointer to enable generation of hierarchical profiles
On 2013-11-22 23:27:00 +0100, Christoph Berg wrote: Re: Andres Freund 2013-11-21 20131121210757.gd27...@alap2.anarazel.de On x86-64, which is not as register starved as x86, the performance impact is close to unnoticeable, at least for postgres. So I suggest compiling postgres with -fno-omit-frame-pointer on x86-64, but not on other platforms. Would that cause an ABI change that would require recompiling all extension modules we ship? If so, that'd be a major pita. If not, I'd be in favor of the idea. No, it doesn't require that. Not having them recompiled will leave them without support, but that just causes slightly less precise profiles if they take up significant cpu time (or cause it). Thanks, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730134: Compile with -fno-omit-frame-pointer to enable generation of hierarchical profiles
Package:postgresql-common Version: 150 Severity: wishlist When using postgres it can often be very advantageous to analyze where it is spending its time and perf is very helpful tool for that. Unfortunately it is hard to properly use that information unless the profile is hierarchical (perf record -g), which requires binaries compiled with -fno-omit-frame-pointer. On x86-64, which is not as register starved as x86, the performance impact is close to unnoticeable, at least for postgres. So I suggest compiling postgres with -fno-omit-frame-pointer on x86-64, but not on other platforms. Greetings, Andres Freund -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726237:
Hi,
I just hit this as well - inspecting the difference in the created
initramfs the issue seems to be that the entire
/lib/udev/rules.d/64-md-raid.rules has been removed. Presumably under
the headline:
- removed debian-disable-udev-incr-assembly.diff
(do not ship udev-md-raid-assembly.rules for now)
but that file did more:
-# do not edit this file, it will be overwritten on update
-
-SUBSYSTEM!=block, GOTO=md_end
-
-# handle potential components of arrays (the ones supported by md)
-ENV{ID_FS_TYPE}==ddf_raid_member|isw_raid_member|linux_raid_member,
GOTO=md_inc
-GOTO=md_inc_skip
-
-LABEL=md_inc
-
-## DISABLED: Incremental udev assembly disabled
-## ** this is a Debian-specific change **
-GOTO=md_inc_skip
-
-# remember you can limit what gets auto/incrementally assembled by
-# mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
-ACTION==add, RUN+=/sbin/mdadm --incremental $tempnode
-ACTION==remove, ENV{ID_PATH}==?*, RUN+=/sbin/mdadm -If $name --path
$env{ID_PATH}
-ACTION==remove, ENV{ID_PATH}!=?*, RUN+=/sbin/mdadm -If $name
-
-LABEL=md_inc_skip
-
-# handle md arrays
-ACTION!=add|change, GOTO=md_end
-KERNEL!=md*, GOTO=md_end
...
As you can see, the incremental udev assembly only skipped four lines,
not the entire file. That explains the issue of no proper /dev notes
getting created, right?
(Btw, there's a spurious trailing A in changelog.Debian.gz).
Greetings,
Andres Freund
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722318: Re: Bug#722318: prepend_earlyinitramfs makes inspecting initramfs unnecessarily hard
above is no bug of the initramfs which boots and decompresses just fine. True, but it makes debugging initramfs hooks and initramfs scripts harder than strictly necessary for those of us who maintain them in our packages (case in point: nbd-client). Agreed. I just had to debug a non-booting initramfs (#726237 as it turns out) and that was unnecessarily hard. So, for reference, until the bug is fixed, you can decompress such concatenated cpios with: (cpio -i --io-size=1; dd bs=1 count=8 of=/dev/null;zcat | cpio -i) /boot/initrd.img-3.10.12-andres I am not entirely sure yet why the 8 is required but thats where the gz header started, the 8 bytes before it are zeroes :/ Not nice, but simple enough. Greetings, Andres Freund -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658915: upgrade-db prematurely deletes $CONFIG_DIR/db
Package: cyrus-common Version: 2.4.13-1 While upgrading a cyrus environment from 2.2 (manually upgraded package built ages ago) I found upgrade-db failing in the midst of the upgrade. Looking at the script the issue seems to be that it removes $CONFIG_DIR/db when finding any non-bdb backed database which then will cause it failing for further bdb databases. Removing the deletion of that dir fixes the issue for me. The solution seems to be to move the removal of the directory outside the loop in upgradealldb which iterates over the individual databases. Am I missing something? Andres PS: I hit this issue in a backported (to squeeze) version but I doubt that actually changes anything... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658915: upgrade-db prematurely deletes $CONFIG_DIR/db
Hi Ondrey, On Monday, February 06, 2012 08:24:13 PM Ondřej Surý wrote: thanks for the bug report. Can you please send a patch, so I can see what you are actually talking about? My patch currently is total crap, thats why I didn't send it so far ;) Its attached now. Andres --- /tmp/cyrus-upgrade-db 2012-02-06 20:48:30.334634974 +0100 +++ /tmp/upgrade-db 2012-02-06 20:50:28.809453691 +0100 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # Cyrus database backends upgrade script # (C) 2001 Ondřej Surý ond...@sury.org # distributed under the same licence as Cyrus IMAPd @@ -187,7 +187,7 @@ checkpointbdb $NEW_DBVERSION else # Remove empty environment - rm -rf $CONFIG_DIR/db + echo not doing rm -rf $CONFIG_DIR/db because we need it for a later db fi fi done
Bug#509216: (no subject)
I'll keep this open, though, and I'll try and find a better method which does not cause log spewage. These days there is pg_ctl status/libpq's PQping which seem more appropriate. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626079: RFP: gcc-4.[56]-doc -- documentation for the GNU compilers (gcc, gobjc, g++)
Package: wnpp Severity: wishlist Package name: gcc-4.6-doc Version : 4.6.0 Upstream Author : FSF URL : http://gcc.gnu.org/ License : GFDL Description : documentation for the GNU compilers (gcc, gobjc, g++) With gcc-4.5 being the current version in wheezy and 4.6 being default in unstable it would be very nice to have -doc packages again. I admittedly have no real clue about dfsg/GFDL problems but my guess would be that it would have to live in non-free (hence the RFP). The -doc package was removed in the course of #571759. Thanks, Andres -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#358224: QtUiTools libraries missing
Hi, I think this and also that libQtAssistantClient is missing is caused by the fact that both are compiled as static libraries and *.a not being caught by the wildcards in the .install files (although my knowledge about all that stuff is quite limited). I locally added wildcards ending with *.a to libqt4-dev.install and libqt4-debug-dev.install which seems to work. Greetings, Andres Freund PS: diff -u ../../qt4-x11-4.1.1/debian/libqt4-debug-dev.install ./libqt4-debug-dev.install --- ../../qt4-x11-4.1.1/debian/libqt4-debug-dev.install 2006-04-13 00:21:01.0 +0200 +++ ./libqt4-debug-dev.install 2006-04-12 09:41:26.555173052 +0200 @@ -2,3 +2,4 @@ usr/lib/*_debug.prl usr/lib/*_debug.pc usr/lib/pkgconfig/ usr/lib/*_debug.la +usr/lib/*_debug.a diff -u ../../qt4-x11-4.1.1/debian/libqt4-dev.install ./libqt4-dev.install --- ../../qt4-x11-4.1.1/debian/libqt4-dev.install 2006-04-13 00:21:01.0 +0200 +++ ./libqt4-dev.install2006-04-12 09:42:54.257633597 +0200 @@ -1,5 +1,6 @@ usr/include/qt4/* usr/lib/*.la +usr/lib/*.a usr/lib/*.so usr/lib/*.prl usr/lib/*.pc usr/lib/pkgconfig/ pgpQMkc7xzvC4.pgp Description: PGP signature
Bug#362053: Missing dependency with modular X
Package: qt4-x11 Version: 4.1.1-1+b1 Severity: serious Justification: no longer builds from source With modular X the build fails due to missing X.h and other headers. Those are in the package x11proto-core-dev which is not referenced in the depends: line. I'm not sure to which package a dependency needs to get introduced, else I would have tried to produce a patch (Also im yet absolutely inexperienced in packaging). Greetings, Andres Freund PS: -- System Information: Debian Release: testing/unstable APT prefers experimental APT policy: (990, 'experimental'), (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-rc5-andres Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) pgpnKhUNtxFnt.pgp Description: PGP signature
Bug#301012: Error: client-error-not-authorized when adding a printer
I had the same problem with an unstable/experimental system. The problem was, that no /etc/cups/passwd.md5 existed. This error also appeared in the error log. I could solve this problem through typing lppasswd -a. After this everything worked. I think this should be done in some automatic way. I hope i could help Andres Freund pgpM5AvAbuEWd.pgp Description: PGP signature
Bug#260833: (no subject)
Hi, I wanted to know if its possible to include the patch to the, currently nonexisting, cyrus22 packages. Here is a working version of the patch-address: [EMAIL PROTECTED] Andres pgpSFxuRfekk7.pgp Description: PGP signature
Bug#260833: (no subject)
Hi, Sorry, i copy n' pasted the false address. Here is the the, hopefully, working address: http://email.uoa.gr/projects/cyrus/autocreate/ Andres pgpoqrveFWirg.pgp Description: PGP signature
