Bug#704748: Not a practical issue (could even be considered a feature...:-))
On 14/04/13 11:03, Christian PERRIER wrote: According to the thread that follows https://lists.debian.org/debian-bsd/2013/04/msg4.html, Gnome is too broken on kFreeBSD to be considered useful. Oops, an error occurred is known as the GNOME 'fail whale'. It could happen also on GNU/Linux for such a trivial reasons as CUPS not running. I wouldn't assume *yet* that GNOME is completely useless on kFreeBSD specifically. Otherwise I'm pretty sure we want to fix this, rather than leave it uninstallable. [...] because nobody apparently is installing Gnome on the kFreeBSD port..:-) Nobody has a choice currently :P And there would likely be some kFreeBSD GNOME users upgrading from squeeze to wheezy... Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704748: Not a practical issue (could even be considered a feature...:-))
On 14/04/13 11:03, Christian PERRIER wrote: As a consequence, having the desktop-gnome task broken on kFreeBSD because of the dependency on n-m-gnome can be considered as non release critical... Just for the record, I'm not happy about this. Why could this not have been fixed in any case, it was obviously a mistake/oversight, creates a regression for kfreebsd-*, and I provided a patch which is trivial. How are users expected to be test GNOME anyway on kfreebsd if they're prevented from installing it since the rc1 installer. As a 'new' arch, people typically don't have installed systems to use as a basis to try things. Are kfreebsd-*'s GNOME CD-1 etc. going to be able to build if task-gnome-desktop is uninstallable? Is there any point building them? Furthermore what about tech-ctte decision #688772 that squeeze-wheezy upgrades (on GNU/Linux) should not pick up network-manager as a dependency? Is that would what happen if they have task-gnome-desktop installed and it Depends now on network-manager-gnome? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697868: Gnome installability vs. GNU/kFreeBSD
On 09/04/13 19:15, Didier 'OdyX' Raboud wrote: I just did (in kvm/qemu) and the result isn't great (for Gnome): Thank you very much for testing. - gdm3 … doesn't finish loading. It fullscreen-says Oops, an error occured. Confirmed: gdm3 shows the 'fail whale' modal dialog; at least the clock and power-off button are visible, but it is not possible to click them. - lightdm + Gnome: same. - lightdm + Gnome classic: same. Not really the same situation as gdm3, but the same uninformative 'fail whale' modal dialog is shown. But in fact, behind it is a seemingly functional window manager and panel with menus... I was able to manually start those things, by using 'xinit', from which I could launch the basic GNOME apps (terminal, calculator, file manager, settings page, telepathy) as I've just explained here (with screenshot) : https://wiki.debian.org/Debian_GNU/kFreeBSD_Desktop#Wheezy_GNOME Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697868: Gnome installability vs. GNU/kFreeBSD
On 09/04/13 19:15, Didier 'OdyX' Raboud wrote: - gdm3 … doesn't finish loading. It fullscreen-says Oops, an error occured. - lightdm + Gnome: same. - lightdm + Gnome classic: same. Found a workaround for this :) But it is strange... 1. Start the system without gdm3 (e.g. update-rc.d gdm3 remove) 2. Log into ttyv1, run while sleep 1 ; do pkill pulse ; done 3. Log into ttyv2, run `/etc/init.d/gdm3 start` And all is fine! gdm3 greeter is working, logs into a working session (fallback mode because acceleration is not available). I noticed during testiong that `pstree $(which gnome-session)` showed a single pulseaudio child process; for some reason it may hang (AFAIK I have no working sound devices, if that makes any difference) and after some timeout either gdm3 or gnome-session would otherwise show the 'fail whale' modal dialog. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704748: Not a practical issue (could even be considered a feature...:-))
For all the problems OdyX mentioned from testing, I've found a single cause and filed bug #705435. I've updated this page to demonstrate a functioning GNOME desktop on GNU/kFreeBSD: https://wiki.debian.org/Debian_GNU/kFreeBSD_Desktop#Wheezy_GNOME On 15/04/13 05:53, Christian PERRIER wrote: I was balanced about working in tasksel to upload with the simple move to Recommends fix but a brief discussion on IRC discouraged me. For something as important as dropping a desktop environment from the release, I'd like to have seen discussion take place with debian-bsd@ copied in; this came as just a bit of a surprise. I think that nobody is prevented to fix the issue but I would ask fixing it *and* dealing with things in tasksel's git, not just with an NMU. Of course, someone else could NMU this and I'll help however I can, but... And, well, doesn't this issue really fit the definition of important? If the severity of this is downgraded, that as an incentive for this to be missed out of any NMU or refused an unblock. I felt certain this was an RC bug and/or policy violation. A package, a task, a whole desktop environment became uninstallable on two release architectures. We still have a tasksel option for GNOME (fails with apt error 100 due to this) and CD's are being built with its packages. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704748: Not a practical issue (could even be considered a feature...:-))
On 15/04/13 11:14, Cyril Brulebois wrote: But you should have made it clear when I asked. I thought I made it clear I needed feedback, and I wrote “*right now*”. I replied to your mail same day and used the words 'should work'... For unrelated reasons, d-i will need a new upload, so I can update tasksel today as well, before rc2 images get built again. That would be really appreciated if you do have time. Is the necessary debian-cd change in effect yet though? http://anonscm.debian.org/viewvc/debian-cd/trunk/tasks/wheezy/Debian-gnome?r1=2363r2=2541 Thank you, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705435: [kfreebsd] hangs on pulseaudio --start
So far as I can tell, this bug is a race condition; on one machine I can reproduce it about 75% of the time, less often under ktrace, and never under gdb. During gdm3/GNOME startup it is called several times and almost certainly means a non-starting session. Sometimes it prints 'Daemon startup fails' before the hang, and sometimes it does not. I think it hangs within the lock-autospawn code, for synchronisation between threads. I think if one of the threads is suspended, it does not resume, and so the other one waits for it indefinitely. This may be a quirk of kFreeBSD's threads implementation, or may happen if a signal is being masked that should not be. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705435: [kfreebsd] hangs on pulseaudio --start
On my system the daemon fails to start in any case with 'Daemon startup
failed', but that is a separate issue and less serious. There seem to
be two separate places where pulseaudio --start may hang indefinitely on
kfreebsd:
1. after printing 'Daemon startup failed' - the attached patch fixes
this hang (I believe some real-time signals are being blocked, which are
necessary for kFreeBSD's threads implementation, LinuxThreads, to work
properly);
2. before printing 'Daemon startup failed' - this happens approx. 10x
less frequently (so applying the patch is already an improvement) - I'm
not sure yet what causes this.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Index: pulseaudio-2.0/src/pulsecore/core-util.c
===
--- pulseaudio-2.0.orig/src/pulsecore/core-util.c 2012-05-13 14:26:37.0 +0100
+++ pulseaudio-2.0/src/pulsecore/core-util.c 2013-04-15 20:12:15.061854000 +0100
@@ -2492,7 +2492,8 @@
}
int pa_unblock_sigsv(const int except[]) {
-#ifndef OS_IS_WIN32
+/* :XXX: kFreeBSD bug #705435 */
+#if !defined(OS_IS_WIN32) !defined(__FreeBSD_kernel__)
int i;
sigset_t ss;
Bug#705435: [kfreebsd] hangs on pulseaudio --start
Control: tags -1 + patch
The simple task of starting a pulseaudio daemon, seems to require
creation of a lockfile, using an additional thread to synchronise that,
then forking, doing the same again using two more threads, and forking
once more.
Happily I found a much, much simpler solution in FreeBSD ports, where a
similar problem had already been reported in this code. The relevant
block is simply commented out and yet I don't notice any functional
difference. Only that it works reliably and allows GDM3 and GNOME
sessions to start (have tested this on kfreebsd-amd64).
http://svnweb.freebsd.org/ports/head/audio/pulseaudio/files/patch-src_daemon_main.c?r1=231972r2=231971pathrev=231972
Please could we apply the same change (attached, commented and cleaned
up) for kFreeBSD, to fix this bug for wheezy. The other patch I
suggested earlier is made unnecessary by this.
Thank you,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Index: pulseaudio-2.0/src/daemon/main.c
===
--- pulseaudio-2.0.orig/src/daemon/main.c 2012-05-13 14:26:37.0 +0100
+++ pulseaudio-2.0/src/daemon/main.c 2013-04-16 00:25:32.164872810 +0100
@@ -735,6 +735,10 @@
* first take the autospawn lock to make things
* synchronous. */
+/* This locking and thread synchronisation code doesn't work reliably
+ * on kFreeBSD (Debian bug #705435), or in upstream FreeBSD ports
+ * (bug reference: ports/128947, patched in SVN r231972). */
+#if !defined(__FreeBSD__) !defined(__FreeBSD_kernel__)
if ((autospawn_fd = pa_autospawn_lock_init()) 0) {
pa_log(Failed to initialize autospawn lock);
goto finish;
@@ -746,6 +750,7 @@
}
autospawn_locked = TRUE;
+#endif
}
if (conf-daemonize) {
Bug#704748: Not a practical issue (could even be considered a feature...:-))
On 16/04/13 01:49, Michael Biebl wrote: The recommends is pointless, task-gnome-desktop depends on gnome-core which already has a Recommends on network-manager-gnome. That is probably true but it is not going to cause harm by staying there? So it may as well stay now and can be removed post-wheezy? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697868: Gnome installability vs. GNU/kFreeBSD
Hi OdyX, On 09/04/13 19:15, Didier 'OdyX' Raboud wrote: - gdm3 … doesn't finish loading. It fullscreen-says Oops, an error occured. - lightdm + Gnome: same. - lightdm + Gnome classic: same. Many thanks for testing that. It would be really helpful if you are able to test again with pulseaudio (+ libpulse0) patched with: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=kfreebsd-bug705435.patch;att=1;bug=705435 For me, it fixes all of the issues above. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705693: graph of dinstall run size un-updated since 20120812
Package: www.debian.org Severity: normal Hi, This graph hasn't updated recently: http://ftp-master.debian.org/size-quarter.png It is referenced from this page: http://www.debian.org/mirror/size Thanks. -- System Information: Debian Release: 6.0.5 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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#694370: [kfreebsd] grub-probe -d fails on msdos logical partitions
Control: severity -1 important Hi, I just realised that msdos logical partitions are not listed in the sysctl kern.geom.confxml on GNU/kFreeBSD. grub-probe uses kern.geom.confxml to get a list of all partitions, and this is why it is unable to detect and use a logical parition used as /boot But even if GRUB could detect and use it, the kernel is also probably unable to use such a partition as a root filesystem. ZFS might be an exception to this. GRUB can definitely use it as /boot, and I *think* the kernel can use it as root even if the physical volumes are logical partitions. The FreeBSD distro itself does not allow installation to msdos logical paritions at all. So I don't think this is something fixable in the short term. I'm downgrading the severity and I think this must be noted in the release notes or install guide as a limitation. Adding a detection/warning of this situation into the installer is now probably not possible, due to string freeze. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697868: network manager is installed when cd2 is also used
Hi, On 12/01/13 20:07, Praveen A wrote: I think it is an important enough program to be on cd 1. Yes probably. A user with only CD1 may need this before they are able to download more packages or CDs. (I would have thought maybe synaptic as well for novice users?). I can think of a few ways this could be achieved: 1. add network-manager-gnome to debian-cd's tasks/wheezy/forcd1 - this is no good though, because forcd1 is used for other desktops and not just the (GNOME) CD1 (apt-offline was added to CD1 for similar reasons to this, see #630805; also #231583: bpalogin, a long time ago); just adding network-manager would not bring in the necessary GUI I think 2. add network-manager-gnome specially to debian-cd's tasks/wheezy/Debian-gnome, after the forcd1 include - after all, we are just trying to manipulate what goes onto CD1. 3. add network-manager-gnome to gnome-core (seems inappropriate) 4. add network-manager-gnome to tasksel's task-gnome-desktop as a required package - would this be sensible? Should a task 'require' something maybe needed by a novice user to set up networking? Out of curiosity, I did some other analysis: based on the popularity-contest file in debian-cd/3.1.10, current wheezy amd64 CD1 only has complete coverage down to rank #148 (libgpm2). And it has an assortment of odd packages all the way down to rank #34291 (caribou-antler). network-manager has rank #869. There are 278 packages with higher popcon than network-manager that are not on CD1. network-manager itself is quite big; it also has a lot of dependencies, but fortunately all are on CD1 already. The unanswered question is still - what would be displaced by placing network-manager-gnome on CD1 The xfce CD has network-manager(-gnome). So if you are limited by bandwidth, this desktop could be a better choice anyway due to lower install size and presumably smaller size of updates during its lifetime. If a machine can only read CD-ROM but not DVD-ROM then it is probably quite resource-constrained, and xfce should be better than gnome3 in this regard also. The (GNOME) CD1 becomes less useful as the distribution grows in size. On download pages and in documentation, I would think it best to promote the various DVD and USB images primarily, followed by either a GNOME CD *set* (suggesting CD1+2 minimum) or a single XFCE/LXDE CD, followed by the mini images for netinst/netboot/console-only etc. There was prior discussion of this at: http://lists.debian.org/debian-boot/2012/11/msg00466.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698051: No internet connection
Hi, On 13/01/13 18:22, andy008.feedb...@mailnull.com wrote: I used the latest live image available direct from Debian's own website (http://cdimage.debian.org/debian-cd/current-live/i386/bt-hybrid/) Could I ask you to clarify please - were you were trying to install from one of the Live DVDs, all along? (And may I ask which one - the filename of the .iso?) Your bugreport mentioned CD Binary-1 but that is something else. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690775: openjdk-7: Multiple security issues from October patch update
Hi Andrew, The Oracle JDK 7u9 announcement in October 2012 had some CVE IDs that are not listed in your OpenJDK accouncements or in RHSA-2012:1386-2. http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-October/020595.html http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-October/020571.html http://rhn.redhat.com/errata/RHSA-2012-1386.html http://www.oracle.com/technetwork/topics/security/javacpuoct2012-1515924.html#AppendixJAVA CVE-2012-1531 - 2D CVE-2012-1532 - Deployment CVE-2012-1533 - Deployment CVE-2012-3143 - JMX CVE-2012-3159 - Deployment CVE-2012-5067 - Deployment CVE-2012-5083 - 2D Is it safe to say that's because these issues did not affect OpenJDK? Thank you very much for your help, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698103: debian-installer-7.0-netboot-kfreebsd-amd64: cannot boot on system with 128MB RAM
user debian-...@lists.debian.org usertags 698103 kfreebsd reassign 698103 src:debian-installer tags 698103 = patch pending sid wheezy severity 696786 important merge 696786 698103 thanks Hi Michael, On 14/01/13 04:16, Michael Tsang wrote: Package: debian-installer-7.0-netboot-kfreebsd-amd64 [...] VirtualBox VM with 128 MB RAM and it does not load. When I increased it to 256 MB, it booted. Debian should not need so much RAM to boot. Yes; and I agree with this goal. I recently did some testing to make it work with only 128 MiB RAM. The necessary change (#696786) is pending in debian-installer Git for now. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695500: (no subject)
Hi, On 15/01/13 10:52, Michael Tsang wrote: Sorry, it still does not boot with the latest image, even after removing font.pf2. It freezes after 'error: prefix is not set'. It freezes on both a physical machine and a virtual machine. The change is only applied in Git, pending an upload. Until then the installer images are not fixed, sorry. I think the minimum for kfreebsd-amd64 is about 176 MiB until then. kfreebsd-i386 will work with less memory. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613925: linux-image-3.2.0-4-amd64: reiserfs: deadlock affecting writes, getdents
Control: clone -1 -2 Control: reassign -2 src:linux Control: found -2 linux/3.2.35-2 Control: notfound -2 linux2.6/2.6.32-35 Hi, This bug seems to still exist in the current kernel version for Wheezy. But it is very rare; today it happened after 18 days' uptime, and once before after 30+ days uptime. This is a desktop machine with a single SSD SATA drive with usually only light I/O workload. Today I noticed all my iceweasel and xfce4-terminal windows had frozen. From a virtual terminal, as root, ls /tmp froze (in the getdents syscall) but could be killed. My other reiserfs partitions on the same block device worked fine. My 'master' xfce4-terminal process was in a blocked state and could not be killed. This, and some unreaped xfce4-terminal child processes that I'd tried to kill already, had some open, deleted inodes on /tmp I thought I was going to have to reboot, but just out of curiosity I killed iceweasel (via the 'non-responding window' feature of xfce4 window manager). Immediately my system recovered with /tmp readable/writable again. I think this suggests it was not a hardware issue, but some deadlock between processes doing I/O on reiserfs. Last time this happened to me it was the /var partition rather than /tmp This problem didn't ever occur in many months of using the Squeeze 2.6.32 kernel. [I would miss reiserfs very much. It has provided me with 100% durability for many years and performed well. Even when I once trashed the underlying mdraid on another system, reiserfsck rescued my data]. -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/acidbath-root ro threadirqs rootdelay=5 ** Not tainted ** Kernel log: [1122963.228076] INFO: task xfce4-terminal:28023 blocked for more than 120 seconds. [1122963.228252] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [1122963.228255] xfce4-terminal D 88021fc13780 0 28023 1 0x [1122963.228260] 88002571e3c0 0086 8160d020 [1122963.228265] 00013780 8801b4659fd8 8801b4659fd8 88002571e3c0 [1122963.228268] 88021fffbe00 000181070ad5 0246 c900019bf000 [1122963.228272] Call Trace: [1122963.228312] [a01babc3] ? queue_log_writer+0x7e/0xac [reiserfs] [1122963.228319] [8103f411] ? try_to_wake_up+0x197/0x197 [1122963.228331] [a01bf4ea] ? do_journal_begin_r+0x193/0x252 [reiserfs] [1122963.228337] [811078d7] ? poll_freewait+0x97/0x97 [1122963.228348] [a01bf662] ? journal_begin+0xb9/0xf2 [reiserfs] [1122963.228359] [a01b1a86] ? reiserfs_dirty_inode+0x37/0x74 [reiserfs] [1122963.228363] [811079a5] ? __pollwait+0xce/0xce [1122963.228366] [8104b03a] ? current_fs_time+0x31/0x37 [1122963.228371] [811166b3] ? __mark_inode_dirty+0x22/0x17a [1122963.228375] [8110bcb5] ? file_update_time+0xda/0x105 [1122963.228381] [810b5500] ? __generic_file_aio_write+0x160/0x278 [1122963.228385] [81030a81] ? ptep_set_access_flags+0x39/0x45 [1122963.228389] [810cf113] ? do_wp_page+0x260/0x563 [1122963.228393] [810363d8] ? should_resched+0x5/0x23 [1122963.228397] [810b5675] ? generic_file_aio_write+0x5d/0xb5 [1122963.228402] [810f95d4] ? do_sync_write+0xb4/0xec [1122963.228405] [810363d8] ? should_resched+0x5/0x23 [1122963.228410] [81163995] ? security_file_permission+0x16/0x2d [1122963.228414] [810f9cc5] ? vfs_write+0xa2/0xe9 [1122963.228417] [810f9ea2] ? sys_write+0x45/0x6b [1122963.228423] [81352012] ? system_call_fastpath+0x16/0x1b ** Model information sys_vendor: Hewlett-Packard product_name: HP xw9400 Workstation product_version: chassis_vendor: Hewlett-Packard chassis_version: bios_vendor: Hewlett-Packard bios_version: 786D6 v04.02 board_vendor: Hewlett-Packard board_name: 0A1Ch board_version: D ** Loaded modules: adt7475 hwmon_vid snd_ice1712 snd_cs8427 snd_i2c snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_ac97_codec snd_mpu401_uart ac97_bus nls_cp437 vfat fat isofs loop usb_storage snd_seq_dummy xt_conntrack ebtable_nat cpufreq_powersave ebtables cpufreq_stats cpufreq_userspace cpufreq_conservative crc32c parport_pc ppdev lp parport bridge bnep rfcomm bluetooth crc16 binfmt_misc ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse nfsd nfs nfs_acl auth_rpcgss lockd sunrpc des_generic ecb md4 hmac nls_utf8 cifs fscache cdc_ether usbnet mii cdc_acm cdc_phonet phonet ipt_MASQUERADE ipt_REDIRECT iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables 8021q garp stp ip6t_REJECT ip6t_frag xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack xt_multiport ip6table_filter ip6_tables x_tables kvm_amd
Bug#697868: network manager is installed when cd2 is also used
On 16/01/13 15:36, Praveen A wrote: 2013/1/13 Steven Chamberlain ste...@pyro.eu.org: 3. add network-manager-gnome to gnome-core (seems inappropriate) yes, there was big debate on it http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834 Ah I see, that's already been decided. A consequence of downgrading it to Recommends:, though, is that it is no longer prioritised for inclusion on CD-1. I think that was probably unintentional; that the intent was to make network-manager optional, rather than remove it altogether from a CD-1 default install. 2. add network-manager-gnome specially to debian-cd's tasks/wheezy/Debian-gnome, after the forcd1 include - after all, we are just trying to manipulate what goes onto CD1. That may be the only sensible suggestion now. Perhaps mobile-broadband-provider-info, modemmanager and usb-modeswitch are all desirable as well. (These are recommends of network-manager[-gnome] and not already on CD-1). I'm not sure yet what packages these would displace, and hence if any of this is technically feasible. If not, users must be strongly warned of the limitations of GNOME CD-1, to avoid disappointment. The ultimate aim would be to offer GNOME CD-1 users the easiest possible, and comprehensive, means to set up networking and be able to install additional software. The rationale is similar to #630805 and #231583, whereby packages were prioritised for inclusion on CD-1 (but those were much smaller, and unintrusive...). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698430: UDD: rcbugs.cgi shows #639407 as affecting Wheezy, but it is fixed+archived
Hi, Based on a diff of RC bug numbers according to UDD bugs.cgi vs. britney testing-nr [0] the surplus bugs are: #639407 python2.7-dev [not marked as 'found' in any version; archived] #672677 src:broadcom-sta [marked fixed in wheezy+sid; archived] #677054 nut-client [marked fixed in wheezy+sid; archived] #677822 nut-server [marked fixed in wheezy+sid; archived] #682000 nut-client [marked fixed in wheezy+sid; archived] #684392 nut-server [marked fixed in wheezy+sid; archived] These seem correct though (UDD has more recent data than the last Britney run) : #676424 emacsen-common [closed today, but without a fixed version] #696228 graphite-carbon [fixed version just uploaded today] I didn't find any bugs missing from UDD that are listed in testing-nr. (Except #694015 which was reopened since the last Britney run). [0] http://bugs.debian.org/bugscan/britney/testing-nr Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: emacsen-common: debian-startup puts items before /usr/local directories in load-path, violating policy
Control: -1 found emacsen-common/2.0.5 Rob Browning r...@defaultvalue.org writes: So with the recent 2.0.5 upload, I believe the original problem may have been fixed (/usr/local/ position in load-path). Accordingly, I think I'll close this bug. Had better also identify the fixed version, so that britney/UDD/apt-listbugs sees that it is not RC-buggy. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698334: drupal7: SA-CORE-2013-001 - Drupal core - Multiple vulnerabilities
Hi, I'm curious: jQuery versions 1.6.3 and higher provide protection against common forms of this problem; thus, the vulnerability is mitigated if your site has upgraded to a recent version of jQuery does that mean the drupal-7 package *could* now use the libjs-jquery package instead of an embedded copy? The libjs-jquery/1.7.2 package seems it was already immune to this issue. (Proof of concept at http://ma.la/jquery_xss/ - save it locally and you can swap out the jquery.js to test other versions). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696661: bind9 - Fails if openssl can't load the gost engine
Control: found -1 1:9.8.1.dfsg.P1-4.3 Hi, bind9/1:9.8.1.dfsg.P1-4.4 and libdns81 have disappeared out of the archive. It is missing from debian/changelog since 1:9.8.4.dfsg-1 (The nmu was not acked conventionally; the change had already been merged in from upstream and the changelog entry was missed). Therefore version tracking of this bug was not working properly; britney/UDD do not list it as an RC bug, but apt-listbugs does. I'm marking it as 'found' in the preceding version so that this bug does not go missing. Whether or not it still exists in 9.8.4 I do not know. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698542: installation-report: Wheezy beta on FSC Futro A240
Hi, On 20/01/13 08:07, Andreas Glaeser wrote: The only trouble occured with the xserver, that needs manual configuration. I did this in the common way, going into runlevel 1, then into /etc/X11/ and doing # Xorg -configure There may still be a bug in xserver-xorg if devices were not being automatically found via udev. Perhaps Andreas would like to open an xserver-xorg bug (or amend an existing one) for that: It would be best to move the manually-created xorg.conf out of the way first; try again to boot runlevel 2 (so it creates a fresh Xorg.log); and then use: # reportbug xserver-xorg so that the appropriate Xorg info and logs are automatically included. (The bugreport can be saved to file [choose 'n' option at end] if you prefer to go back into a graphical environment to actually send it). Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#698626: Preseeding netcfg/enable doesn't work
Hi, On 21/01/13 10:21, Stefan Kisdaroczi wrote: I preseed the installer with d-i netcfg/enable boolean false. netcfg 1.103 ignores it at two places and writes the file /etc/network/interfaces. The second write in finish-install.d/55netcfg-copy-config overwrites my own interface config. It will do that if netcfg/target_network_config is set to nm_config or loopback. Is nm_config the default now? The same issue was mentioned at http://lists.debian.org/50f9b2f5.8050...@pyro.eu.org I think it will only preserve your /etc/network/interfaces file if set to ifupdown. Not sure if that was intentional but seems more like a bug/regression. I fixed it with the attached patch. Preseeding netcfg/enable worked with squeeze. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696877: installation-reports: Wheezy DI-b4-amd64-netboot-mini.iso from an usb stick fails trying to install grub
Hi, It looks like some code is already there to avoid cdrom or USB install media being used as the grub-install target. In the grub-installer script: 552 # [...] if /cdrom seems 553 # to be a USB stick then (hd0) may not be safe. If we hit either of those 554 # checks, then try the disk containing /boot instead. 555 # The same goes for /hd-media, so avoid installing there as well. 556 cdsrc=$(mount | grep on /cdrom | cut -d' ' -f1) 557 cdfs=$(mount | grep on /cdrom | cut -d' ' -f5) 558 hdsrc=$(mount | grep on /hd-media | cut -d' ' -f1) For hybrid media on USB it seems that /cdrom will be iso9660, so the next thing preventing an install to (hd0) is if cdrom-detect/hybrid is set to true. This seems a bit of a long shot, but in cdrom-detect it looks like this might go wrong if `list-devices cd; list-devices maybe-usb-floppy` finds the install media before `list-devices usb-partition` does. If someone who has hardware that can reproduce this, could please do the following, it could really help explain this: 1. boot a USB install up to the 'Configure the network' step, 2. drop to the Alt-F2 shell, 3. run these commands and note the output from them: # mount | grep cdrom # list-devices cd # list-devices maybe-usb-floppy # list-devices usb-partition # list-devices disk Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#696877: installation-reports: Wheezy DI-b4-amd64-netboot-mini.iso from an usb stick fails trying to install grub
Thanks Paul, On 24/01/13 12:22, Paul Bryan Roberts wrote: # mount | grep cdrom Ah of course, this is netboot... # list-devices cd /dev/sr0 # list-devices maybe-usb-floppy # list-devices usb-partition /dev/sda4 What exactly is sda4; is that where the mini.iso files are? Is it formatted as vfat? After the original installation, /boot/grub/device.map read: (hd0) /dev/disk/by-id /usb-BUFFALO_ClipDrive_A320051021751-0:0 As a result, default_bootdev gets set to this. GRUB will install there unless either: * the device is mounted on /cdrom * the device is mounted on /hd-media * the install media was detected as hybrid iso9660 on USB * the device has no partition, and yet it isn't a whole-drive filesystem recognised by grub-probe We need some novel way to detect that the installer is running from the USB stick, but this isn't obvious from /proc/mounts or /proc/cmdline. I suspect that if /dev/sda4 contained a directory .disk/ containing an empty file named info, that might result in it being mounted on /cdrom; then grub-installer would decide know not to install there. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696877: installation-reports: Wheezy DI-b4-amd64-netboot-mini.iso from an usb stick fails trying to install grub
[quoting from #698707] On 24/01/13 12:42, Andrea Borghi wrote: 2. set the default drive for grub installation to the drive that contains the root partition selected during disk partitioning. That's a good thing to ask, it seems like a more obvious place to start. Currently (hd0) is preferred unless we're able to detect that it is install media. That's the problem currently. *Only* if we'd detected it as install media, we would fall back to: 575 bootfs=$(findfs /boot) 576 [ $bootfs ] || bootfs=$(findfs /) (That does a grub probe of /boot or / in the target, or otherwise whatever seems mounted on /target/boot or /target) But wouldn't that be a better default_bootdev, for any grub-legacy/pc/sparc/ieee1275 install? Could we try to determine default_bootdev that way to begin with? It would just require a shuffle round of the code that is already there. I'm picturing something like: case $ARCH:$grub_package in *:grub|*:grub-pc|sparc:grub-ieee1275) # For GRUB installs this should be a better starting point bootfs=$(findfs /boot) [ $bootfs ] || bootfs=$(findfs /) default_bootdev=$(device_to_disk $bootfs) ;; *) # This was the original default default_bootdev_os=$($chroot $ROOT grub-mkdevicemap --no-floppy -m - | head -n1 | cut -f2) if [ $default_bootdev_os ]; then default_bootdev=$($chroot $ROOT readlink -f $default_bootdev_os) else default_bootdev=(hd0) fi ;; esac then the usual sanity checks as before; prompt if unsure Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698909: installation-reports: successful install in GNOME Boxes using kFreeBSD
Hi! On 25/01/13 07:05, Paul Wise wrote: It wasn't a complete success, my report contained a few issues that could/should be polished up [...] Not a problem... I've had a read through and we can follow up on some things in separate bug reports. On 25/01/13 05:03, Paul Wise wrote: During the partitioning section of the installer, I got this message twice, ignoring it worked fine: Could not get identity of device /dev/ada0 - Inappropriate ioctl for device Yes, harmless. Should be able to silence it by picking out just the relevant bit from Jeff Epler's patch here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693510#55 The timezone selection section did not have a GeoIP option, instead I had to manually select my timezone. Oh. Didn't even know that existed. Do you know where specifically it's implemented in code? The mirror selection did not default to http.debian.net nor to cdn.debian.net, instead I had to either manually navigate the long list of countries and mirrors or manually enter a server. Is this any different from GNU/Linux? AFAIK neither of those are intended to be defaults yet, as they're 'unofficial' *.d.n services. See also #697488... When I manually entered http.debian.net, it decided that the mirror was bad and forced me to enter another mirror. The installer logs indicate it couldn't find Suite|Codename in the Release file, trying the wget command it used manually worked fine though. This sounds familiar. I though maybe http.d.n offers mirrors sometimes that don't carry wheezy/sid suites for GNU/kFreeBSD. Personally I still use gb.kfreebsd-amd64.mirror.debian.net for now. I note that the automatic reports listed below contain some errors; things not being mounted, commands not being found: Ahhh this is really cool. I was already in the middle of making something to capture and summarise this kind of thing, from syslog during test installs. These are all used by the installation-report report-hw script, so not really installer bugs: /sys/bus free dfbinfo /sys/bus doesn't exist but maybe there's a suitable sysctl to use instead. Fortunately d-i's lowmem code already uses /proc/meminfo, not 'free'. dfbinfo is built for GNU/kFreeBSD, it works, and would be nice to see its output in the installation-report. It just wasn't present; an undeclared dependency/recommends on libdirectfb-bin I suppose? partman: mkfs.ufs: partman: Cannot retrieve operator gid, using gid 0. mkfs.ufs functions okay on an installed system. A .snap directory uses the operator gid. In this case it falls back to gid 0 with no other error. The stripped-down /etc/group in d-i doesn't have operator. We could maybe ask for it to be added (in rootskel). Same for Xorg.0.log: [ 3.005] (WW) Warning, couldn't open module qxl [ 3.005] (EE) Failed to load module qxl (module does not exist, 0) [ 3.006] (WW) Warning, couldn't open module fbdev [ 3.006] (EE) Failed to load module fbdev (module does not exist, 0) [ 3.008] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 3.069] (WW) VESA(0): Unable to estimate virtual size [ 3.069] (WW) VESA(0): No valid modes left. Trying less strict filter... [ 3.069] (WW) VESA(0): Unable to estimate virtual size [ 3.228] (WW) default pointer: No Device specified, looking for one... Were you able to check you had working display+mouse+keyboard in Xorg? [ 3.307] (WW) fcntl(8, O_ASYNC): Inappropriate ioctl for device That's worrying. It should be a supported flag. TODO: look at some other cases: http://codesearch.debian.net/search?q=fcntl\%28.*ASYNC Thanks for this! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#697190: unblock: virtuoso-opensource/6.1.4+dfsg1-2
Hi, On 26/01/13 23:02, intrigeri wrote: José Manuel Santamaría Lema wrote (16 Jan 2013 17:33:25 GMT) : I've uploaded Virtuoso again because in the -2 revision of the package I did wrong fix for this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677286 [...] So all in all, the proposed changes look good, and I recommend the release team grants the requested unblock. This can't migrate yet because it hasn't built on kfreebsd-* The netstat errors in buildd logs are ignored now, so that is not the problem. For some reason the service failed to start/respond, at different stages in the test suite. It builds okay for me on kfreebsd-amd64 locally. Christoph, please could you give back virtuoso-opensource on both kfreebsd-* arches for another build attempt? Thank you, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694378: unblock: apt-cacher-ng/0.7.11-1
Control: retitle -1 unblock: apt-cacher-ng/0.7.11-1 Hi, 0.7.10-1 introduced a new segfaulting bug, #694620. So the unblock request is now for 0.7.11-1? On 27/01/13 13:14, Eduard Bloch wrote: intrigeri wrote (27 Nov 2012 10:58:28 GMT) : Eduard, given the apparent brokenness of the version currently in testing, the size of the delta, and the fact we've been frozen for months, have you considered preparing a minimal fix meant to fix these bugs for Wheezy? Ping? Well, (no offense implied) I am often puzzled at how people ask for just the minimal fix WRT complex software. Well, development is still very active. Things have been changing quite fast even during the freeze period. It's difficult to say there will be no remaining crash/corruption bugs for a ~3-year life in stable. I could try to do that but the the extract would still require significant code changes and involve the risk of breaking something you don't see coming in the beginning. I did have a glance through the changes last month, to look for a smaller fix, but this was my conclusion as well. Those three months of testing in Sid are IMHO more worth for software quality than some wild patching. Another option would be to ask for removal from testing, and maintaining this package in backports during the Wheezy lifetime. That sounds like a good idea to me; if the bad version in wheezy is removed, the sid version could enter wheezy-backports immediately after release, and that also allows any required updates to be made quickly... Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659899: CVE-2012-0790: XSS
Hi, On 16/03/13 13:56, Adam D. Barratt wrote: On Sat, 2013-03-16 at 12:40 +, Steven Chamberlain wrote: No longer marked as fixed in versions smokeping/2.6.7-1. Is that really what you meant to do? I can't remember now, so it was probably a mistake, but now I can think of a reason to reopen it: Is the fix in 2.6.7-1 not considered sufficient, or does wheezy/sid need the revised fix from 2.6.9? In what places were the and = characters thought to still be a risk? (Other than in start/end dates as I've shown; but those are still not being filtered in upstream 2.6.9) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659899: CVE-2012-0790: XSS
Hi! On 16/03/13 21:53, Salvatore Bonaccorso wrote: On Sat, Mar 16, 2013 at 10:47:54PM +0100, Salvatore Bonaccorso wrote: [...] But how about the attached patch for unstable? Thank you for that. It does seem like the right way to handle it for wheezy. Your patch seems correct to me. But defining $xssBadRx would be just one extra line of diff... so why not use it? Then it would be more consistent with upstream. I've added Tobias back into Cc: as I would like to ask: While here, I wonder if the user-supplied $start/$end could be filtered with this same regex, to address the things I noted earlier? I thought maybe it could go in parse_datetime which is before they are used in any file paths or output by anything. And I don't *think* any valid time specifier would contain the characters of $xssBadRx. Thanks everyone, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659899: CVE-2012-0790: XSS
Another difference is that upstream 2.6.9 used a replacement character
of underscore rather than a dot. Attached is my suggested revision of
Salvatore's patch (also adds filtering of time specifiers).
I've tested this on an existing wheezy/sid SmokePing installation; it
stops the injection of quotes into the img tag I demonstrated before.
It also prevents those characters from being used in graph filenames in
the cache directory. I've tried some valid time specifiers and they are
still working.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Index: smokeping-2.6.8/lib/Smokeping.pm
===
--- smokeping-2.6.8.orig/lib/Smokeping.pm 2012-02-26 18:19:45.0 +
+++ smokeping-2.6.8/lib/Smokeping.pm 2013-03-16 23:07:00.0 +
@@ -28,6 +28,8 @@
# make sure we do not end up with , in odd places where one would expect a '.'
# we set the environment variable so that our 'kids' get the benefit too
+my $xssBadRx = qr/[%';]/;
+
$ENV{'LC_NUMERIC'}='C';
if (setlocale(LC_NUMERIC,) ne C) {
if ($ENV{'LC_ALL'} eq 'C') {
@@ -170,7 +172,7 @@
my $hierarchy = '';
my $h = $q-param('hierarchy');
if ($q-param('hierarchy')){
- $h =~ s/[%]/./g;
+ $h =~ s/$xssBadRx/_/g;
$hierarchy = 'hierarchy='.$h.';';
};
return $hierarchy;
@@ -212,7 +214,7 @@
my $address = $ENV{REMOTE_ADDR};
my $targetptr = $cfg-{Targets};
foreach my $step (@target){
-$step =~ s/[%]/./g;
+$step =~ s/$xssBadRx/_/g;
return Error: Unknown target $step
unless defined $targetptr-{$step};
$targetptr = $targetptr-{$step};
@@ -1024,6 +1026,7 @@
sub parse_datetime($){
my $in = shift;
for ($in){
+$in =~ s/$xssBadRx/_/g;
/^(\d+)$/ do { my $value = $1; $value = time if $value 2**32; return $value};
/^\s*(\d{4})-(\d{1,2})-(\d{1,2})(?:\s+(\d{1,2}):(\d{2})(?::(\d{2}))?)?\s*$/
return POSIX::mktime($6||0,$5||0,$4||0,$3,$2-1,$1-1900,0,0,-1);
@@ -1047,7 +1050,7 @@
my $tree = shift;
my $open = shift;
my $mode = shift || $q-param('displaymode') || 's';
-$mode =~ s/[%]/./g;
+$mode =~ s/$xssBadRx/_/g;
my $phys_tree = $tree;
my $phys_open = $open;
if ($tree-{__tree_link}){
@@ -1447,7 +1450,7 @@
$startstr =~ s/\s/%20/g;
$endstr =~ s/\s/%20/g;
my $t = $q-param('target');
-$t =~ s/[%]/./g;
+$t =~ s/$xssBadRx/_/g;
for my $slave (@slaves){
my $s = $slave ? ~$slave : ;
$page .= div;
@@ -1601,7 +1604,7 @@
my $t = $q-param('target');
if ( $t and $t !~ /\.\./ and $t =~ /(\S+)/){
$targ = $1;
-$targ =~ s/[;%]/./g;
+$targ =~ s/$xssBadRx/_/g;
}
my ($path,$slave) = split(/~/,$targ);
if ($slave and $slave =~ /(\S+)/){
@@ -1610,7 +1613,7 @@
$slave = $1;
}
my $hierarchy = $q-param('hierarchy');
-$hierarchy =~ s/[;%]/./g;
+$hierarchy =~ s/$xssBadRx/_/g;
die ERROR: unknown hierarchy $hierarchy\n
if $hierarchy and not $cfg-{Presentation}{hierarchies}{$hierarchy};
my $open = [ (split /\./,$path||'') ];
Bug#696757: ecl: FTBFS: hang in sigsuspend
Control: tags -1 + patch Hi Christoph, Would it be an option to configure ecl with --enable-threads=no on kfreebsd-* and hurd-* for wheezy? Would any functionality be lost or would it only affect performance? The version in squeeze didn't have threads enabled, and there don't seem to be any rdepends in wheezy? Doing so (with attached patch to enable-threads only on Linux) results in successful builds for me. Actually this was already done for hurd-i386 in experimental: http://bugs.debian.org/648993 But as of upstream 12.12.1 it seems to be fixed, making it possible to re-enable threads post-wheezy on kfreebsd-* and maybe even hurd-*. The changes don't really seem trivial enough to backport comfortably. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org Index: ecl-11.1.1/debian/rules === --- ecl-11.1.1.orig/debian/rules 2011-03-11 19:00:29.0 + +++ ecl-11.1.1/debian/rules 2013-03-17 17:03:28.856311208 + @@ -28,12 +28,18 @@ endif DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) +DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) # gengc doesn't work on ia64 right now -- check again for next version ifneq ($(DEB_HOST_ARCH),ia64) confflags += --enable-gengc endif +# threads seem broken currently except on Linux (see #696757, #648993) +ifeq ($(DEB_HOST_ARCH_OS),linux) + confflags += --enable-threads=yes +endif + # force to use ginstall-info: export INSTALL_INFO=/usr/bin/ginstall-info @@ -56,7 +62,6 @@ --with-system-gmp=yes \ --with-tcp \ --with-clx \ - --enable-threads=yes \ --enable-boehm=system \ --with-x
Bug#664812: rpc.lockd on kfreebsd
I don't understand why the bug only happens on GNU/kFreeBSD, but the changes in the attached patch appear to fix it. Regards, -- Steven Chamberlain ste...@pyro.eu.org Index: freebsd-utils-9.0+ds1/usr.sbin/rpc.lockd/lockd.c === --- freebsd-utils-9.0+ds1.orig/usr.sbin/rpc.lockd/lockd.c 2013-03-17 22:48:52.157285000 + +++ freebsd-utils-9.0+ds1/usr.sbin/rpc.lockd/lockd.c 2013-03-18 01:24:08.588303578 + @@ -906,6 +906,7 @@ sin-sin_family = AF_INET; sin-sin_port = htons(0); sin-sin_addr.s_addr = htonl(INADDR_ANY); + sin-sin_len = sizeof(struct sockaddr_in); res-ai_addr = (struct sockaddr*) sin; res-ai_addrlen = (socklen_t) sizeof(res-ai_addr); @@ -917,6 +918,7 @@ sin6-sin6_family = AF_INET6; sin6-sin6_port = htons(0); sin6-sin6_addr = in6addr_any; + sin6-sin6_len = sizeof(struct sockaddr_in6); res-ai_addr = (struct sockaddr*) sin6; res-ai_addrlen = (socklen_t) sizeof(res-ai_addr); break;
Bug#700245: freebsd-utils: some initscripts start twice
On 10/02/13 14:27, Steven Chamberlain wrote: I noticed some initscripts are running twice at startup. The Default-Start flag should usually choose either runlevel S, or one/more from [2345], but not both! Actually no... that is correct/valid, but the initscript 'start' action should not try to start something that is already running. I can commit fixes for these 'soon', but for now here are some notes before I forget: nfsd tries to start twice because the --pidfile option is given but the daemon doesn't really create one. On starting the second instance, it returns status 0, forks to background then writes Can't read stable storage file to syslog and aborts. mountd doesn't start if /etc/exports doesn't exist; should probably test for this in the initscript and then 'warn' rather than 'fail'. rpc.statd doesn't create a pid file either so --pidfile causes two processes to be started (and both stay running). rpc.lockd tries twice to load but is failing due to #664812. If it did work, it would try to run twice (again because of --pidfile) but fail the second time due to address being in use. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700249: unclean rpc.statd shutdown; hangs for 30s
On 10/02/13 15:15, Steven Chamberlain wrote: The rpc.statd initscript always hangs for 30 seconds at shutdown. I'll commit fixes for this soon. It just needs to omit the --pidfile which isn't really there. Also when rpc.lockd is fixed its initscript may have the same problem. The nfsd initscript hangs too, for the reason above, and also because it uses the wrong signal. According to the manpage it must be killed using signal USR1, not TERM. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703298: automake: tests fail: undefined reference to `yywrap'
Hi, This bug report is a little strange... On 18/03/13 07:45, Aapo Rantalainen wrote: Version: 1:1.11.3-1ubuntu2 That's not even a Debian package? Debian Squeeze has only version 1:1.11.1-1+squeeze1 Debian Wheezy has a newer version 1:1.11.6-1 where these problems may be fixed already. Severity: serious Justification: fails to build from source This type of package doesn't really get 'built' as such... so a failure of a test might be considered not 'serious'. FAIL: cond35.test (exit: 2) FAIL: lex3.test (exit: 2) These tests pass for me on a Debian system running testing/sid. cond35: running flex --version flex-2.5.35 2.5.35 cond35: running bison --version bison (GNU Bison) 2.4.1 Wheezy has bison 2.5 cond35: running gcc --version sbox-arm-none-linux-gnueabi-gcc (Linaro GCC 4.7-2012.07) 4.7.2 20120701 (prerelease) That's not even Debian's compiler. Debian Release: wheezy APT prefers precise APT policy: (500, 'precise') What happened there? 'precise' isn't a Debian suite... Architecture: amd64 (x86_64) The system isn't armel? So the above is from some sort of cross-compile toolchain that isn't working? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703265: lletters: crashes on most buttons on non-OSS3 systems
Hi! On 17/03/13 19:35, Adam Borowski wrote: On systems that don't have OSS installed and configured, pressing any button that has an attached sound, causes a crash. Another option might be to disable sound on Linux, then at least we'd keep something that works. There is a configure test which checks for presence of sys/soundcard.h or soundcard.h and it will automatically enable-sound due to that. On Linux we could override it with --enable-sound=no (assuming it is too difficult to get it working with OSS4 or aoss in the Wheezy timeframe). I've attached a patch for this but am still trying to test it. [...] the package still works on kfreebsd, but these are quite fringe cases. (Hey, you can ask for RM on linux-any hurd-any :) ). That also sounds good. We could market this on the why kFreeBSD? Wiki page! Regards, -- Steven Chamberlain ste...@pyro.eu.org --- lletters-0.1.95+gtk2.orig/debian/rules 2013-03-18 14:42:35.0 + +++ lletters-0.1.95+gtk2/debian/rules 2013-03-18 14:45:24.0 + @@ -7,6 +7,7 @@ #export DH_VERBOSE=1 package=lletters +export DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) @@ -17,6 +18,10 @@ confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) endif +ifeq ($(DEB_HOST_ARCH_OS),linux) + confflags += --enable-sound=no +endif + config.status: # libtoolize --automake --force --copy # aclocal-1.9
Bug#703265: lletters: crashes on most buttons on non-OSS3 systems
Control: tags -1 + patch Hi, On 18/03/13 14:47, Steven Chamberlain wrote: On Linux we could override it with --enable-sound=no (assuming it is too difficult to get it working with OSS4 or aoss in the Wheezy timeframe). I've attached a patch for this but am still trying to test it. I've tested this now, it does build an work (without sound) as long as the attached patch is also applied. This fixes a Makefile.in bug that would forget to link with GTK libs if you configure without OSS sound enabled. Regards, -- Steven Chamberlain ste...@pyro.eu.org --- lletters-0.1.95+gtk2.orig/Makefile.in 2013-03-18 14:42:35.0 + +++ lletters-0.1.95+gtk2/Makefile.in 2013-03-18 16:17:33.0 + @@ -263,8 +263,9 @@ timer.h \ version.h -@SOUND_FALSE@lletters_SOURCES = $(lln_CORE) +@SOUND_FALSE@lletters_SOURCES = $(lln_CORE) @SOUND_TRUE@lletters_SOURCES = $(lln_CORE) wav_play.c $(sound_CORE) +@SOUND_FALSE@lletters_LDADD = -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lgtk-x11-2.0 @SOUND_TRUE@lletters_LDADD = libqdwav/libqdwav.a -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lgtk-x11-2.0 #lletters_LDADD = #@GTK_LIBS@
Bug#601119: xserver-xorg-core: Caught signal 11 (Segmentation fault). cpu:mipsel loongson
Control: block 594684 by 601119 I'd like to correct what I said when closing #601119: the remaining issue is now #594684 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703800: linux-headers-3.2.0-4-common-rt: files missing [3.2.39-2 - 3.2.41-1 regression]
Package: linux-headers-3.2.0-4-common-rt Version: 3.2.41-1 Severity: grave Control: fixed -1 3.2.39-2 Hi Debian Kernel Team, Somehow the latest linux-headers-3.2.0-4-common-rt package contained everything except for the actual headers... linux-headers-3.2.0-4-common-rt_3.2.41-1_amd64.deb drwxr-xr-x root/root 0 2013-03-23 12:45 ./ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/src/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/src/linux-headers-3.2.0-4-common-rt/ -rw-r--r-- root/root 53780 2013-03-23 09:37 ./usr/src/linux-headers-3.2.0-4-common-rt/Makefile drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/ -rw-r--r-- root/root 3257 2013-03-20 15:03 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/Makefile_32.cpu -rw-r--r-- root/root 6775 2013-03-20 15:03 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/Makefile -rw-r--r-- root/root 1703 2013-03-20 15:03 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/Makefile.um drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/share/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/share/doc/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/share/doc/linux-headers-3.2.0-4-common-rt/ -rw-r--r-- root/root 2470 2013-02-24 03:53 ./usr/share/doc/linux-headers-3.2.0-4-common-rt/copyright -rw-r--r-- root/root192332 2013-03-23 03:54 ./usr/share/doc/linux-headers-3.2.0-4-common-rt/changelog.Debian.gz lrwxrwxrwx root/root 0 2013-03-23 12:45 ./usr/src/linux-headers-3.2.0-4-common-rt/scripts - ../../lib/linux-kbuild-3.2/scripts Thanks! -- System Information: Debian Release: 6.0.5 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703146: #703146 release critical?
On 22/03/13 06:21, Christian PERRIER wrote: - mv $relsigdest $reldest + rm -f $reldest Is it safe to remove the quotes from there, i.e. are we certain $reldest will never contain spaces? If there is going to be a t-p-u upload with targetted fix for wheezy I suggest taking the opportunity to put the quotes back in place. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702796: unblock: haskell-certificate et. al.
Hi Joachim, I've been watching progress of the haskell package rebuilds on: http://release.debian.org/transitions/html/haskell.html#header22 That page shows that haskell-yesod-default still Build-Depends libghc-network-conduit-dev ( 0.5). I'm not sure if it's required for this but I thought I would mention it. It was given back recently but is not going to be able to build due to this. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704227: unblock: freebsd-utils/9.0+ds1-11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, Please consider unblocking freebsd-utils/9.0+ds1-11 Due to a bug in their initscripts, some kfreebsd-* NFS-related daemons would try to start more than once, which I think violates policy, but seemed to have no ill effects. A related issue with the 'stop' action caused sleeps of 30 seconds, for each of these daemons, upon shutdown/reboot/package upgrade. This also meant a KILL signal was used instead of something more appropriate. This is not a regression introduced by freebsd-utils/9.0+ds1-10, but now having three daemons with this problem on a typical NFS server (nfsd, rpc.statd, rpc.lockd) makes it more noticeable and annoying. The fix for this was trivial, is represented in the attached debdiff, and has been tested on real systems. The udebs are unchanged. Thank you, Regards, -- Steven Chamberlain ste...@pyro.eu.org diff -Nru freebsd-utils-9.0+ds1/debian/changelog freebsd-utils-9.0+ds1/debian/changelog --- freebsd-utils-9.0+ds1/debian/changelog 2013-03-18 10:58:29.0 + +++ freebsd-utils-9.0+ds1/debian/changelog 2013-03-27 14:56:47.0 + @@ -1,3 +1,13 @@ +freebsd-utils (9.0+ds1-11) unstable; urgency=low + + * Don't use --pidfile when starting/stopping daemons that don't create one: +- Prevents trying to start nfsd, rpc.lockd, rpc.statd more than once + (Closes: #700245) +- Fixes a 30-second delay as each service is stopped (Closes: #700249) + * Stop nfsd with the correct signal USR1, since it ignores TERM + + -- Steven Chamberlain ste...@pyro.eu.org Wed, 27 Mar 2013 13:16:03 + + freebsd-utils (9.0+ds1-10) unstable; urgency=low * Import patch by Steven Chamberlain to make rpc.lockd start without diff -Nru freebsd-utils-9.0+ds1/debian/freebsd-nfs-common.rpc.lockd.init freebsd-utils-9.0+ds1/debian/freebsd-nfs-common.rpc.lockd.init --- freebsd-utils-9.0+ds1/debian/freebsd-nfs-common.rpc.lockd.init 2013-03-18 10:32:55.0 + +++ freebsd-utils-9.0+ds1/debian/freebsd-nfs-common.rpc.lockd.init 2013-03-27 14:19:55.0 + @@ -38,9 +38,9 @@ # 0 if daemon has been started # 1 if daemon was already running # 2 if daemon could not be started - start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test /dev/null \ + start-stop-daemon --start --quiet --exec $DAEMON --test /dev/null \ || return 1 - start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \ + start-stop-daemon --start --quiet --exec $DAEMON -- \ $DAEMON_ARGS \ || return 2 # Add code here, if necessary, that waits for the process to be ready @@ -58,7 +58,7 @@ # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred - start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME + start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --name $NAME RETVAL=$? [ $RETVAL = 2 ] return 2 # Wait for children to finish too if this is a daemon that forks diff -Nru freebsd-utils-9.0+ds1/debian/freebsd-nfs-common.rpc.statd.init freebsd-utils-9.0+ds1/debian/freebsd-nfs-common.rpc.statd.init --- freebsd-utils-9.0+ds1/debian/freebsd-nfs-common.rpc.statd.init 2013-03-18 10:32:55.0 + +++ freebsd-utils-9.0+ds1/debian/freebsd-nfs-common.rpc.statd.init 2013-03-27 14:19:55.0 + @@ -40,9 +40,9 @@ # 0 if daemon has been started # 1 if daemon was already running # 2 if daemon could not be started - start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test /dev/null \ + start-stop-daemon --start --quiet --exec $DAEMON --test /dev/null \ || return 1 - start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \ + start-stop-daemon --start --quiet --exec $DAEMON -- \ $DAEMON_ARGS \ || return 2 # Add code here, if necessary, that waits for the process to be ready @@ -60,7 +60,7 @@ # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred - start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME + start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --name $NAME RETVAL=$? [ $RETVAL = 2 ] return 2 # Wait for children to finish too if this is a daemon that forks diff -Nru freebsd-utils-9.0+ds1/debian/freebsd-nfs-server.nfsd.init freebsd-utils-9.0+ds1/debian/freebsd-nfs-server.nfsd.init --- freebsd-utils-9.0+ds1/debian/freebsd-nfs-server.nfsd.init 2013-03-18 10:32:55.0 + +++ freebsd-utils-9.0+ds1/debian/freebsd-nfs-server.nfsd.init 2013-03-27 14:19
Bug#698381: unblock: ifupdown/0.7.7
Control: retitle -1 unblock: ifupdown/0.7.7 Hi, On 25/03/13 10:42, Julien Cristau wrote: On Thu, Jan 17, 2013 at 19:58:31 +0100, Andrew Shadura wrote: Please unblock package ifupdown. This release fixes some important issues with ifupdown, and also brings upstart support up to date. Sorry for the delay here. I've unblocked 0.7.6, which afaict leaves us with the dhclient -1 question. That did not have time to migrate :( meanwhile the maintainer removed the dhclient -1 flag in a new upload. I'm not on the Release Team but this change sounds scary to me; it changes behaviour from what we've had in the entire wheezy freeze period. Even while a tryonce option was implemented in sid it defaulted to 'yes'. (The rationale for this was bug #694541.) Releasing DHCPv6 has also been reverted due to a regression. Attaching a new debdiff, which seems quite big, but partly due to sections of in-line code documentation. debian/changelog | 30 ++--- debian/control |2 debian/testbuild-linux | 12 - ifupdown.nw| 108 - interfaces.5.pre | 21 + 5 files changed, 145 insertions(+), 28 deletions(-) Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org ifupdown_0.7.5+nmu1_0.7.7.debdiff.gz Description: GNU Zip compressed data
Bug#695679: freebsd-utils: Init script fails in jail, breaks dist-upgrade
Control: tags -1 + confirmed patch Control: severity -1 important On 11/12/12 16:20, Stefan Ott wrote: Setting up freebsd-utils (9.0+ds1-8) ... Installing new version of config file /etc/init.d/freebsd-utils ... [] Loading devfs rules...devfs ruleset: ioctl DEVFSIO_SUSE: Operation not permitted invoke-rc.d: initscript freebsd-utils, action start failed. dpkg: error processing freebsd-utils (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: freebsd-utils E: Sub-process /usr/bin/dpkg returned an error code (1) Hi! This is reproducible in jails on 'native' Debian GNU/kFreeBSD as well. I think it may be better if the initscript just warns if devfs seems unavailable, and exit with status 0; in a jail with default settings the rest of the initscript (e.g. mounting kernel filesystems) can't function anyway. With a change I just committed to SVN it now looks like this: # /etc/init.d/freebsd-utils start [] Loading devfs rules...devfs ruleset: ioctl DEVFSIO_SUSE: Operation not permitted (warning). # echo $? 0 Please review/test this change if you can: http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-utils/debian/freebsd-utils.init?r1=3414r2=4376view=patch Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695152: gnulib overriding stdint.h for C++11 change (was: Bug#695152: t-p-u pre-approval lftp/4.3.6-1+deb7u1)
clone 677861 -1 reassign -1 src:lftp,src:gnulib,src:eglibc,src:kfreebsd-kernel-headers retitle -1 gnulib overriding stdint.h for C++11 change severity -1 normal thanks Hi, There might have been a more elegant way to address this in lftp, but the patch approved for t-p-u should be okay for wheezy and is hopefully only temporary. I would have preferred to revert the gnulib stdint.m4 change[1] which triggered this regression, so that system headers are used as before and not interfered with. [1] http://git.savannah.gnu.org/cgit/gnulib.git/commit/m4/stdint.m4?id=501af6ba6cbdb199856d2a12f8a1ee754e7bd2ae On 12/12/12 15:31, Andreas Henriksson wrote: A much better solution would have been to actually fix the kFreeBSD system headers! [...] kFreeBSD brokenness [...] I don't think that is clear; I'd say there were three separate problems that led to this (some of which you have mentioned) : 1. C++11 seems to have changed the requirements of stdint.h, to do something which was specifically prohibited by C99, and neither current GNU libc nor FreeBSD libc are doing this; it is a C header after all, and C++11 even introduces a cstdint for this purpose so I don't see why they had to rewrite history 2. gnulib saw this change in the standards as a new 'portability issue to be fixed'[2] and therefore chooses to override the system header (actually on GNU/Linux *as well as* GNU/kFreeBSD) which had been perfectly adequate for lftp until now 3. by overriding stdint.h and system types, gnulib causes some (unexplained yet?) problem for GNU/kFreeBSD system headers (but maybe that's not surprising when it is overriding system types) [2] http://git.savannah.gnu.org/cgit/gnulib.git/diff/doc/posix-headers/stdint.texi?id=443bc5ffcf7429e557f4a371b0661abe98ddbc13context=24 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: marked as done (bash: [on native FreeBSD] unable to set FD_CLOEXEC flag)
Hi, On 16/12/12 22:06, Debian Bug Tracking System wrote: bash (4.2-5.1) unstable; urgency=low . * Non-maintainer upload. * debian/bash.preinst-lib.c: typo in fcntl argument (Closes: #679198). Thank you for uploading your fix for this. Using Debian Code Search we can see other cases where possibly the same mistake has been made - I wonder if any of these would cause bugs: http://codesearch.debian.net/search?q=fcntl.*F_SETFL.*FD_ Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#653929: Bug #696119 probably has the fix to this bug
severity 696119 important forcemerge 696119 653929 thanks Hello, On 17/12/12 02:00, Jeff Epler wrote: Today I filed a bug about this same problem, having found this earlier report too late. I believe the patch on bug #696119 will address this problem (which is not seen on freebsd due to libc differences). I saw this, and thought it sounded familiar. Good work finding a fix for this over at zfsonlinux. Originally in #653929 it was said that this bug breaks GRUB in some way, and could prevent use of RAID-Z as a root filesystem; do you know if that is true? As I'm a newbie at the debian bugtracker I'm not sure how to merge the two bugs, or even if that's how it's done here. I've Bcc:'d this mail to cont...@bugs.debian.org, with commands at the top to hopefully do this. If you're interested you can read all about it at http://www.debian.org/Bugs/server-control Thanks a lot! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692053: [ia64] Iceweasel 10.0 (and above?) randomly stops responding, eating 100% CPU
Hi, I think I've seen the same problem on mipsel (with 16 Kb pagesize, so it could be the same cause?) Strangely, I noticed that keeping a tab open with the SunSpider JavaScript Benchmark[0] running in the background while browsing, would reliably stop this from occurring. I'm keen to test this patch but I would struggle to build iceweasel on a Yeeloong/loongson-2f netbook. I may have to wait until the patch is uploaded and built before I could give feedback on this. [0] https://www.webkit.org/perf/sunspider-0.9/sunspider-driver.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685625: implicit declaration of function ‘reallocf’
Control: severity -1 grave Control: affects -1 grub-common Control: retitle -1 [kfreebsd] libgeom: may cause segfault of grub-probe Hello, On 21/12/12 18:45, Jeff Epler wrote: geom_getxml.c: In function ‘geom_getxml’: geom_getxml.c:59:2: warning: implicit declaration of function ‘reallocf’ [-Wimplicit-function-declaration] geom_getxml.c:59:2: warning: return makes pointer from integer without a cast [enabled by default] On kfreebsd-amd64 systems, the consequence of this is that the top 32 bits of a pointer returned by reallocf are discarded. Curiously I have never been affected by this on kfreebsd-amd64. My kern.geom.confxml is only ~16 KiB. The reporter could reproduce this reliably with a kern.geom.confxml of ~4 MiB. I observe some magic threshold of 136648 bytes, above which malloc() in a simple C program starts to return an address with some of the high 32 bits set, triggering the bug. I think the chance of this being a problem during install is very low, unless there is some large pre-existing ZFS pool. On an installed system, it would become impossible to update/upgrade GRUB after exceeding some number of ZFS volumes * snapshots (I guess around 500, but deleted snapshots still seem to count - that may also be a bug). Therefore I'm raising the severity of this. It's not unreasonable to have 50 zvols (one per user/share on a NAS, for example), and if taking weekly snapshots this could trigger after 10 weeks; if daily, 10 days; if hourly, 10 hours etc. - -D__va_list=__builtin_va_list + -D__va_list=__builtin_va_list \ + -Werror=implicit-function-declaration That's a good idea. The buildd log scanner reveals a handful more cases of this compiler warning in other GNU/kFreeBSD packages which we should probably look into: https://buildd.debian.org/~brlink/bytag/E-pointer-trouble-at-implicit.html * freebsd-buildutils * freebsd-libs * freebsd-utils And I'm worried about some of the other packages mentioned, where the error shows on kfreebsd-* or maybe hurd-*, but not on other arches. Should they really all be doing this: ++#include bsd/stdlib.h Or should we be trying to fix this elsewhere, in GNU/kFreeBSD headers maybe? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685625: implicit declaration of function ‘reallocf’
Hi, To further confuse things, here's a related problem in freebsd-buildutils: gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='i386' -DMACHINE_MULTIARCH='i386-kfreebsd-gnu' -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys -D_GNU_SOURCE=1 -isystem /usr/include/freebsd -std=gnu99 -fstack-protector -c excludes.c excludes.c: In function 'read_excludes_file': excludes.c:75:2: warning: implicit declaration of function 'fgetln' [-Wimplicit-function-declaration] excludes.c:75:15: warning: assignment makes pointer from integer without a cast [enabled by default] gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='i386' -DMACHINE_MULTIARCH='i386-kfreebsd-gnu' -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys -D_GNU_SOURCE=1 -isystem /usr/include/freebsd -std=gnu99 -fstack-protector -c misc.c gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='i386' -DMACHINE_MULTIARCH='i386-kfreebsd-gnu' -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys -D_GNU_SOURCE=1 -isystem /usr/include/freebsd -std=gnu99 -fstack-protector -c mtree.c gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='i386' -DMACHINE_MULTIARCH='i386-kfreebsd-gnu' -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys -D_GNU_SOURCE=1 -isystem /usr/include/freebsd -std=gnu99 -fstack-protector -c spec.c spec.c: In function 'set': spec.c:229:4: warning: implicit declaration of function 'setmode' [-Wimplicit-function-declaration] spec.c:229:11: warning: assignment makes pointer from integer without a cast [enabled by default] spec.c:232:4: warning: implicit declaration of function 'getmode' [-Wimplicit-function-declaration] fgetln, setmode and getmode are defined in bsd/stdio.h and bsd/unistd.h. Using fgetln without its prototype truncates the pointer to 32 bits. Fortunately a mode_t is only 16 bits long so getmode/setmode may be okay. I think the preferred method is to use libbsd's 'overlay' in code that needs these functions. Previously freebsd-buildutils couldn't use the overlay, so 20_libbsd_overlay.diff worked around it with extra includes: http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-buildutils/debian/patches/20_libbsd_overlay.diff?view=markup Then for some unexplained reason that workaround got disabled; the overlay was never re-enabled though: http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-buildutils/debian/patches/series?r1=3805r2=3960 [added Guillem Jover in Cc: in the hope he can explain any of this :) ] Another occurrence is in freebsd-libs: cc -Wall -g -pipe -fPIC -I. -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/sys -D_GNU_SOURCE -D__va_list=__builtin_va_list -O2 -isystem /usr/include/freebsd -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/debian/local/include -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/lib/libgeom -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c geom_ctl.c In file included from geom_ctl.c:38:0: /usr/include/freebsd/unistd.h: In function 'feature_present': /usr/include/freebsd/unistd.h:138:2: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration] geom_ctl.c: At top level: geom_ctl.c:55:1: warning: no previous prototype for 'gctl_dump' [-Wmissing-prototypes] geom_ctl.c: In function 'gctl_new_arg': geom_ctl.c:142:2: warning: implicit declaration of function 'reallocf' [-Wimplicit-function-declaration] geom_ctl.c:142:11: warning: assignment makes pointer from integer without a cast [enabled by default] And many more places in freebsd-utils according to: https://buildd.debian.org/~brlink/packages/f/freebsd-utils.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664812: rpc.lockd on kfreebsd
Hi, On 26/03/12 19:41, Christoph Egger wrote: 47878 rpc.lockd RET nlm_syscall -1 errno 14 Bad address 47878 rpc.lockd CALL exit(0x1) I've an idea this may be related to: cc -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D__va_list=__builtin_va_list -isystem /usr/include/tirpc -D__FreeBSD_version=__FreeBSD_kernel_version -O2 -isystem /usr/include/freebsd -I/build/buildd-freebsd-utils_9.0+ds1-8-kfreebsd-i386-vUpCIn/freebsd-utils-9.0+ds1/debian/local/include -I/build/buildd-freebsd-utils_9.0+ds1-8-kfreebsd-i386-vUpCIn/freebsd-utils-9.0+ds1/include -lbsd -I. -I/build/buildd-freebsd-utils_9.0+ds1-8-kfreebsd-i386-vUpCIn/freebsd-utils-9.0+ds1/usr.sbin/rpc.lockd/../../include/rpcsvc -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D__va_list=__builtin_va_list -isystem /usr/include/tirpc -D__FreeBSD_version=__FreeBSD_kernel_version -O2 -std=gnu99 -fstack-protector -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c lockd.c lockd.c: In function 'main': lockd.c:462:5: warning: implicit declaration of function 'nlm_syscall' [-Wimplicit-function-declaration] and: cc -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D__va_list=__builtin_va_list -isystem /usr/include/tirpc -D__FreeBSD_version=__FreeBSD_kernel_version -O2 -isystem /usr/include/freebsd -I/build/buildd-freebsd-utils_9.0+ds1-8-kfreebsd-i386-vUpCIn/freebsd-utils-9.0+ds1/debian/local/include -I/build/buildd-freebsd-utils_9.0+ds1-8-kfreebsd-i386-vUpCIn/freebsd-utils-9.0+ds1/include -lbsd -I. -I/build/buildd-freebsd-utils_9.0+ds1-8-kfreebsd-i386-vUpCIn/freebsd-utils-9.0+ds1/usr.sbin/rpc.lockd/../../include/rpcsvc -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D__va_list=__builtin_va_list -isystem /usr/include/tirpc -D__FreeBSD_version=__FreeBSD_kernel_version -O2 -std=gnu99 -fstack-protector -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c nlm_syscall.c nlm_syscall.c:8:1: warning: no previous prototype for 'nlm_syscall' [-Wmissing-prototypes] nlm_syscall.c: In function 'nlm_syscall': nlm_syscall.c:10:3: warning: implicit declaration of function 'syscall' [-Wimplicit-function-declaration] which I noticed while looking into #685625. Could this mean the addrs parameter gets truncated to a 32-bit int by the time the syscall() happens? See also: http://lists.debian.org/50d4f523.7060...@pyro.eu.org https://buildd.debian.org/~brlink/packages/f/freebsd-utils.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696514: freebsd-net-tools: /sbin/ifconfig: segfaults getting bridge status
Package: freebsd-net-tools Version: 9.0+ds1-8 Severity: important File: /sbin/ifconfig Control: block -1 by 685625 User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Hi, After an `ifconfig bridge0 create`, attempts to query the bridge status from ifconfig will trigger a segfault related to printf(), as shown here running under gdb: Starting program: /sbin/ifconfig bridge0 bridge0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 ether f6:10:b5:1:8e:16 Program received signal SIGSEGV, Segmentation fault. 0x0008010bf21a in vfprintf () from /lib/x86_64-kfreebsd-gnu/libc.so.0.1 This was expected. I noticed this issue thanks to the buildd log scanner[1] : cc -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D__va_list=__builtin_va_list -isystem /usr/include/tirpc -D__FreeBSD_version=__FreeBSD_kernel_version -O2 -isystem /usr/include/freebsd -I/build/buildd-freebsd-utils_9.0+ds1-8-kfreebsd-i386-vUpCIn/freebsd-utils-9.0+ds1/debian/local/include -I/build/buildd-freebsd-utils_9.0+ds1-8-kfreebsd-i386-vUpCIn/freebsd-utils-9.0+ds1/include -lbsd -DINET6 -DINET -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D__va_list=__builtin_va_list -isystem /usr/include/tirpc -D__FreeBSD_version=__FreeBSD_kernel_version -O2 -std=gnu99 -fstack-protector -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c ifbridge.c ifbridge.c: In function 'bridge_addresses': ifbridge.c:241:3: warning: implicit declaration of function 'ether_ntoa' [-Wimplicit-function-declaration] ifbridge.c:241:3: warning: nested extern declaration of 'ether_ntoa' [-Wnested-externs] ifbridge.c:242:7: warning: format '%s' expects argument of type 'char *', but argument 3 has type 'int' [-Wformat] ifbridge.c: In function 'bridge_status': ifbridge.c:278:25: warning: format '%s' expects argument of type 'char *', but argument 2 has type 'int' [-Wformat] ifbridge.c:285:6: warning: format '%s' expects argument of type 'char *', but argument 2 has type 'int' [-Wformat] ifbridge.c: In function 'setbridge_static': ifbridge.c:473:2: warning: implicit declaration of function 'ether_aton' [-Wimplicit-function-declaration] ifbridge.c:473:2: warning: nested extern declaration of 'ether_aton' [-Wnested-externs] ifbridge.c:473:5: warning: assignment makes pointer from integer without a cast [enabled by default] ifbridge.c: In function 'setbridge_deladdr': ifbridge.c:493:5: warning: assignment makes pointer from integer without a cast [enabled by default] The missing prototypes issue is being discussed already in #685625. In this case it results in a truncated pointer being passed to printf. This probably doesn't affect kfreebsd-i386 as the pointer would be only 32 bits anyway. [1] https://buildd.debian.org/~brlink/packages/f/freebsd-utils.html -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages freebsd-net-tools depends on: ii libbsd0 0.4.2-1 ii libc0.1 2.13-35 ii libexpat1 2.1.0-1 ii libipx2 9.0+ds1-3 ii libkvm0 9.0+ds1-3 ii libmemstat3 9.0+ds1-3 ii libnetgraph4 9.0+ds1-3 ii libsbuf6 9.0+ds1-3 ii pf9.0+ds1-8 freebsd-net-tools recommends no packages. freebsd-net-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696556: [kfreebsd] ldd: segfault with inkscape/inkview executables
Package: libc-bin Version: 2.13-37 File: /usr/bin/ldd User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Hi, On 22/07/12 22:18, Steven Chamberlain wrote: $ ldd /usr/bin/inkscape ldd: exited with unknown exit code (139) [...] pid 16961 (ld-2.13.so), uid 1000: exited on signal 10 I haven't seen this happen with any other executables - the most notable thing about the inkscape/inkview 0.48.3.1-1 binaries is their large size. On linux amd64 the bug does not occur, but we see that some 100 dynamic libraries are linked in. I'm struggling to get any helpful debugging info: (gdb) run --verify ./inkscape Starting program: /usr/lib/debug/lib/x86_64-kfreebsd-gnu/ld-2.13.so --verify ./inkscape Cannot access memory at address 0x220128 Cannot access memory at address 0x220120 (gdb) bt #0 0x01021ab0 in ?? () #1 0x in ?? () From a separate run under ktrace(1) we get some rough idea of what leads up to the crash: 49053 ld-2.13.so CALL open(0x1241148,0invalid0,unused0) 49053 ld-2.13.so NAMI ./inkscape 49053 ld-2.13.so RET open 3 49053 ld-2.13.so CALL read(0x3,0x7fffcfb8,0x340) 49053 ld-2.13.so RET read 832/0x340 49053 ld-2.13.so CALL fstat(0x3,0x7fffcd00) [...] 49053 ld-2.13.so RET fstat 0 49053 ld-2.13.so CALL __getcwd(0x7fffc900,0x400) 49053 ld-2.13.so NAMI .. 49053 ld-2.13.so NAMI /usr/bin 49053 ld-2.13.so RET __getcwd 0 49053 ld-2.13.so CALL mmap(0x40,0xc5c000,0x5PROT_READ|PROT_EXEC,0x12MAP_PRIVATE|MAP_FIXED,0x3,0) 49053 ld-2.13.so RET mmap 4194304/0x40 49053 ld-2.13.so PSIG SIGSEGV SIG_DFL code=0x1 That mmap is the inkscape ELF executable, up to and including the .gcc_except_table section. The 0x1021ab0 address mentioned by GDB would be within that .gcc_except_table section, where I guess it's not supposed to be executing code? 1021aa4: 0001 0e550578 0060058d 01008801 .U.x.`.. 1021ab4: 05ff ff01081b 05450059 05ff .E.Y 1021ac4: ff013451 9f018c03 00850205 fe03008d ..4Q $ file inkscape inkscape: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for GNU/kFreeBSD 8.1.0, BuildID[sha1]=0x085d1e83d4ab8e3466e0a31b2f480cc7d9cda835, stripped -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692011: taxbird: version in testing (0.16.x) is completely useless
On 21/12/12 12:33, Jonathan Wiltshire wrote: On 2012-12-21 12:04, Toni Mueller wrote: In practice, isn't taxbird dead and therefore unlikely to change at all in the future? I think if we include it in wheezy, we should include the newest packaged version. Yes. The author works on a successor package that is based on XUL: http://stesie.github.com/geierlein/ and declares on his homepage that taxbird itself is dead. If it's already dead, is there any point shipping it in Wheezy at all? 3+ years of support, without any guarantee we can rely on upstream, is a long time. Not shipping it will not result in it being removed from upgraded systems. That seems sensible; how about requesting that ftpmaster remove the 'useless' version from testing for now? Then aim to make the version in sid, or any later revisions, available through wheezy-backports. That seems analogous to the 'volatile' idea. This would keep the package available to those who want it, yet reflects the fact it doesn't have the same level or duration of support as a typical package in stable. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631337: xserver-xorg-video-nouveau: excessive fan speed on GeForce 9600GT
Hi, Are there any i2c buses available on your card? e.g. # ls /sys/devices/pci*/*/*02:00.0 On an 8800GT I can access thermal sensors and fan speed settings via: # modprobe adt7473 # modprobe adt7475 # ls /sys/devices/pci:00/:00:0f.0/:18:00.0/i2c-4/4-002e Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696598: bge: watchdog timeout; intermittent link then system crash
Package: kfreebsd-image-9.0-2-amd64 Version: 9.0-10 Severity: important Control: tags + patch User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Hi, A Sun Fire v20z server with the older motherboard revision has the particular combination of: PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) In this combination, the bge NIC can fail suddenly (every 2-3 days in my case, may depend on workload) with watchdog timeouts logged. The link can lag or go up/down repeatedly, the system can become less responsive (as seen on a serial tty) and eventually crash. An upstream changelog entry mentions the same problem occurring with BCM5704, which is found in a v20z with the newest motherboard revision, but still the same AMD-8131 PCI-X bridge. http://svnweb.freebsd.org/base?view=revisionrevision=233495 I've tried that patch from 9-STABLE for some weeks and I believe it has fixed the problem for me too. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kfreebsd-image-9.0-2-amd64 depends on: ii devd 9.0+ds1-8 ii freebsd-utils 9.0+ds1-8 ii kbdcontrol 9.0+ds1-8 ii kldutils 9.0+ds1-8 kfreebsd-image-9.0-2-amd64 recommends no packages. kfreebsd-image-9.0-2-amd64 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696606: squeak-vm: FTBFS on kfreebsd-*: tries to use ALSA
Package: src:squeak-vm Version: 4.4.7.2357-1.1 Severity: wishlist Control: tags -1 patch User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Hi, squeak-vm has support for ALSA, and for the OSS emulation provided by ALSA on Linux (see unix/doc/README.Sound). On kfreebsd-* (and probably hurd-*) we do not have these. The fact that libasound2-dev is available is taken to mean that ALSA support should be compiled, but there is no way it could work. And the build fails with: https://buildd.debian.org/status/fetch.php?pkg=squeak-vmarch=kfreebsd-amd64ver=1%3A4.4.7.2357-1.1stamp=1330913958 [100%] Building C object vm-sound-ALSA/CMakeFiles/vm-sound-ALSA.dir/build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c.o /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c: In function 'sound_Start': /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c:111:3: warning: the address of 'hwparams' will always evaluate as 'true' [-Waddress] /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c:122:3: warning: the address of 'swparams' will always evaluate as 'true' [-Waddress] /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c: In function 'sound_StartRecording': /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c:273:3: warning: the address of 'hwparams' will always evaluate as 'true' [-Waddress] /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c:284:3: warning: the address of 'swparams' will always evaluate as 'true' [-Waddress] /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c: In function 'mixer_open': /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c:340:17: error: 'struct snd_mixer_selem_regopt' has no member named 'device' /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c:341:3: warning: the address of 'sid' will always evaluate as 'true' [-Waddress] /build/buildd-squeak-vm_4.4.7.2357-1.1-kfreebsd-amd64-462hq_/squeak-vm-4.4.7.2357/unix/vm-sound-ALSA/sqUnixSoundALSA.c:334:34: warning: variable 'smixer_options' set but not used [-Wunused-but-set-variable] My attached patch avoids this problem by marking the libasound2-dev build dependency as linux-any, which seems to be true. A test build on kfreebsd-amd64 was successful without it: it results in both ALSA and OSS being disabled, but Pulse audio output is still enabled. I'm not able to test yet if audio playback via Pulse is really working. The build might still fail if someone had the libasound2-dev package installed, therefore I've added it to Build-Conflicts on non-Linux. This may not be the best solution - maybe it could do a better detection of whether ALSA can/should be used. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- squeak-vm-4.4.7.2357.orig/debian/control 2012-03-03 20:28:15.0 + +++ squeak-vm-4.4.7.2357/debian/control 2012-12-23 20:24:16.415621927 + @@ -3,7 +3,8 @@ Priority: optional Maintainer: Debian Squeak Team pkg-squeak-de...@lists.alioth.debian.org Uploaders: José L. Redrejo RodrÃguez jredr...@debian.org -Build-Depends: debhelper (= 5.0.42), autotools-dev, quilt, cmake (= 2.6.2), libxt-dev, libgl1-mesa-dev, libasound2-dev, uuid-dev, libspeex-dev, libxtst-dev, libxrender-dev, sharutils, libffi-dev, libdbus-1-dev, libgstreamer0.10-dev, libvorbis-dev, libfreetype6-dev, libpango1.0-dev, libcairo2-dev, libpulse-dev, libjpeg8-dev, libpcre3-dev +Build-Depends: debhelper (= 5.0.42), autotools-dev, quilt, cmake (= 2.6.2), libxt-dev, libgl1-mesa-dev, libasound2-dev [linux-any], uuid-dev, libspeex-dev, libxtst-dev, libxrender-dev, sharutils, libffi-dev, libdbus-1-dev, libgstreamer0.10-dev, libvorbis-dev, libfreetype6-dev, libpango1.0-dev, libcairo2-dev, libpulse-dev, libjpeg8-dev, libpcre3-dev +Build-Conflicts: libasound2-dev [!linux-any] Standards-Version: 3.9.2 Homepage: http://www.squeakvm.org/unix/
Bug#401855: scheme48: FTBFS on kfreebsd-i386: kfreebsd-i386 not in the architecture list
fixed 401855 1.8-2 thanks On Wed, 5 Sep 2012 23:11:55 +0100, Luca Favatella wrote: X-Debbugs-CC: debian-...@lists.debian.org Your mail wasn't Cc'd due to the stray leading space! Version 1.8+dfsg-1 of scheme48 is built and available from the repo. The interpreter looks working for me. Shall this bug be archived? Yes thanks; I've marked it as fixed in the earliest version that built. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686402: kfreebsd-kernel-headers: several headers assume _BSD_SOURCE
user debian-...@lists.debian.org
usertags 686402 kfreebsd
tags 686402 + patch
thanks
--- kfreebsd-9-9.0.orig/sys/sys/filedesc.h 2011-08-11 13:30:23.0
+0100
+++ kfreebsd-9-9.0/sys/sys/filedesc.h 2012-12-24 00:48:21.750672610 +
@@ -45,7 +45,7 @@
* This structure is used for the management of descriptors. It may be
* shared by multiple processes.
*/
-#define NDSLOTTYPE u_long
+#define NDSLOTTYPE __u_long
struct filedesc {
struct file **fd_ofiles; /* file structures for open files */
This change looks okay to me, though something like this is probably not okay
during freeze and should wait until after Wheezy release.
insighttoolkit4 has other issues preventing Wheezy transition.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696556: [kfreebsd] ldd: segfault with inkscape/inkview executables
Here's a small testcase that executes fine, but triggers a Bus error
(return status 138) from ldd on kfreebsd-amd64, but not Linux amd64:
$ cat testcase.c
unsigned char foo[16*1024*1024];
void main() { }
$ gcc testcase.c -o testcase
$ ./testcase
$ /lib/ld-kfreebsd-x86-64.so.1 --verify ./testcase
Bus error
(gdb) run --verify ./testcase
Starting program: /lib/ld-kfreebsd-x86-64.so.1 --verify ./testcase
Cannot access memory at address 0x220128
Cannot access memory at address 0x220120
(gdb) bt full
#0 0x01021ab0 in ?? ()
No symbol table info available.
#1 0x in ?? ()
No symbol table info available.
This may be a different issue to the one seen with the inkscape binary,
which was a segfault instead (return status 139).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696621: hipercdecode: strange 50MiB variable in bss segment
Package: printer-driver-foo2zjs
Version: 20120510dfsg0-1
Severity: minor
Tags: security
File: /usr/bin/hipercdecode
Hi,
I notice some strange use of a large variable in hipercdecode.c:
148 unsigned char blk[50*1024*1024];
150 void
151 decode(FILE *fp)
152 {
225 // unsigned char blk[50*1024*1024];
230 rc = fread(blklen, 4, 1, fp);
235 blklen = be32(blklen);
236 rc = fread(blk, blklen, 1, fp);
This imposes a (somewhat arbitrary?) limit of 50 MiB of input.
The size of blklen is also not checked before fread() into blk:
$ ( printf '\x7f\xff\xff\xff\x00\x00\x00\x00\x7f\xff\xff\xff' ; cat
/dev/zero ) | /usr/bin/time /usr/bin/hipercdecode
RECTYPE 0 (len=2147483647,0x7fff cnt=1), Page 1
0.00user 0.17system 0:00.29elapsed 58%CPU (0avgtext+0avgdata
206784maxresident)k
0inputs+0outputs (0major+12960minor)pagefaults 0swaps
On a Squeeze system this shows ~200 MiB memory used (which was all the
free memory on that system); on Wheezy (with hardened eglibc) only ~50
MiB. So I assume it is overflowing something? But even with
pseudorandom input it does not seem to crash.
With blk defined in function scope, the program would have segfaulted
(due to exceeding stack memory?) and this seems to have been worked
around by moving it to global scope (to the bss segment of the process
image?)
After blklen is known, why not just malloc() a suitably large area from
the heap???
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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#694971: ia64 (Itanium) Epiphany browser crashes within JSC::JSArray::increaseVectorLength()
Hi Stephan, When I saw your patch for this bug (and #692053) I immediately thought of mipsel hardware with 16K page size. I think you have probably found the reason for #651636. I'm afraid I can't really test your patch though until it is uploaded and built on the buildds (it takes them more than a day! and all I have is a netbook). Thanks for your work on this! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661018: FTBS due to new freexl
Control: fixed -1 3.1.0b-1 I'm marking that version as fixed because 3.0.1-1 never made it into the archive. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680704: iceweasel/xulrunner: Loongson-2f mipsel iceweasel/xulrunner hasn't been working since several versions back.
block 680704 by 692053 thanks Hi, On 24/12/12 20:24, Javier Vasquez wrote: It applies a patch though over version 17, which changes the PageShift to 14 for mips: The hangs we both see in iceweasel 10 on loongson-2f seem similar to #692053 on ia64, which was due to non-4K page size. Stefan Schreiber has just come up with a patch for it. If there is a new upload to unstable with that patch we should both re-test. I will test sooner if my netbook seems capable of building iceweasel. http://www.anheng.com.cn/loongson2f/testing/iceweasel/iceweasel17/fix_loongson_PageSize.patch That might fix things for loongson-2f with 16K page size - but do *all* MIPS systems have the same? On ia64 for example it can vary across hardware, so it would be wrong to hard-code it. If it's the same situation on mips(el) too then this seems better: http://www.anheng.com.cn/loongson2f/testing/iceweasel/iceweasel17/Don-t-hardcode-page-size-on-ia64-or-sparc.patch That change (already applied in Debian experimental only for ia64/sparc) should perhaps also apply to mips(el). It seems it might fix the build issue of iceweasel 17 in experimental. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686402: kfreebsd-kernel-headers: several headers assume _BSD_SOURCE
tags 686402 - patch thanks On 24/12/12 00:54, Steven Chamberlain wrote: --- kfreebsd-9-9.0.orig/sys/sys/filedesc.h 2011-08-11 13:30:23.0 +0100 +++ kfreebsd-9-9.0/sys/sys/filedesc.h 2012-12-24 00:48:21.750672610 + @@ -48,2 +48,2 @@ * This structure is used for the management of descriptors. It may be * shared by multiple processes. */ -#define NDSLOTTYPE u_long +#define NDSLOTTYPE __u_long Actually no... this breaks kernel compilation: clang -c -O2 -frename-registers -pipe -fno-strict-aliasing -O1 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Win line -Wcast-qual -Wundef -Wno-pointer-sign -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_H EADERS -include opt_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding ../ ../../dev/syscons/scvidctl.c In file included from ../../../dev/syscons/scvidctl.c:44: ../../../sys/filedesc.h:57:2: error: unknown type name '__u_long'; did you mean 'u_long'? NDSLOTTYPE *fd_map; /* bitmap of free fds */ ^~ u_long ../../../sys/filedesc.h:48:20: note: expanded from macro 'NDSLOTTYPE' #define NDSLOTTYPE __u_long ^ ../../../sys/types.h:53:23: note: 'u_long' declared here typedef unsigned long u_long; ^ Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696554: System freezes and lockups
Hello, Just an idea of mine, but if this issue only happens after logging in (to gnome-shell?), perhaps you could try installing+logging into the xfce4-desktop? Just to see if that still triggers the nouveau bug. And then if xfce4 is stable, you could perhaps try `mplayer -vo xv somefile.avi` to see if that will trigger the problem instead. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696554: System freezes and lockups
Hi, I wonder, if these errors only appear after some time - and if you've had problems with the non-free driver too - maybe it has to do with the buildup of heat? Are you able to check temperature sensors on the card? I don't know how to do that for your particular model, but on my card (NV92 / 8800 GT) I can do it like this (as root) : # apt-get install lm-sensors # modprobe adt7473 # modprobe adt7475 # sensors adt7473-i2c-4-2e Adapter: nouveau-:18:00.0-2 in1: +3.00 V (min = +0.00 V, max = +2.99 V) +3.3V:+3.34 V (min = +0.00 V, max = +4.39 V) fan1:2277 RPM (min = 2000 RPM) fan2: 0 RPM (min =0 RPM) fan3: 0 RPM (min = 164 RPM) ALARM temp1:+52.5°C (low = +20.0°C, high = +68.0°C) (crit = +100.0°C, hyst = +98.0°C) Board Temp: +48.0°C (low = +20.0°C, high = +60.0°C) (crit = +100.0°C, hyst = +96.0°C) temp3:+52.5°C (low = +20.0°C, high = +68.0°C) (crit = +136.0°C, hyst = +132.0°C) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696554: System freezes and lockups
Control: tags -1 - moreinfo Okay, thanks for checking! And for providing the info Sven asked for. So you're seeing errors already, but there are no ill effects yet? I'd like to know if it really does end up crashing this time. And then: * can Alt-F1 still switch consoles? (you said no before) * does the mouse pointer still move? (I guess not?) * can you find anything specific that triggers it? (so far, no?) And then I think there will be enough information to file an upstream bug report. Hopefully someone else has some ideas though. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695500: debian-installer-7.0-netboot-kfreebsd-amd64: does not boot from pxe
Control: tags -1 + moreinfo unreproducible Hi Michael, Please explain what your setup is, any relevant DHCP config, the TFTP daemon being used and what sort of client (real hardware with PXE-capable NIC?). A screenshot (or even a photo?) of the error message could be very helpful. Michael Tsang mikl...@gmail.com (09/12/2012): I cannot boot the installer from pxe. GRUB says prefix is not set and dies. It seems to be a configuration bug. I don't see a problem under Qemu (with iPXE). But this works a little differently to pxelinux and this needs to be documented better. For kfreebsd-amd64 netboot-9, the prefix seems to be hardcoded to (pxe)/debian-installer/kfreebsd-amd64/, so as long as I do this: $ tar -zxvf netboot.tar.gz ./ ./debian-installer/ ./debian-installer/kfreebsd-amd64/ ./debian-installer/kfreebsd-amd64/initrd.gz ./debian-installer/kfreebsd-amd64/kfreebsd-9.gz ./debian-installer/kfreebsd-amd64/grub.cfg ./debian-installer/kfreebsd-amd64/font.pf2 ./debian-installer/kfreebsd-amd64/splash.png ./debian-installer/kfreebsd-amd64/grub2pxe ./grub2pxe ./version.info $ qemu-system-x86_64 -m 256 -enable-kvm -net nic -net user,bootfile=grub2pxe,tftp=. GRUB shows me the full graphical menu (grub.cfg and Wheezy splash artwork are loaded from the TFTP server). Then I hit a different bug though - it assumes the kernel name is kfreebsd.gz but for netboot-9 installs this should be kfreebsd-9.gz I wonder if the 'prefix is not set' error is to do with DHCP options. Jeff Epler also mentions: On the server side, tftpd 0.17-17ubuntu1 doesn't seem to work, while tftpd-hpa 5.0-11ubuntu2 does. The symptom is that grub can't find grub.cfg. (at http://emergent.unpythonic.net/debian-kfreebsd-zfs ) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696780: kfreebsd-* netboot-9 boots wrong kernel filename
Package: debian-installer
Version: 20121114
Severity: important
Tags: d-i patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-...@lists.debian.org
Hi,
The netboot-9 images contain a kernel image named kfreebsd-9.gz but GRUB
is still configured to PXE-boot a file called kfreebsd.gz
The kfreebsd.gz file only exists in the 8.3 kernel netboot images.
Attached is a patch to template grub.cfg with the appropriate kernel
filename for the netboot image being built. Here is the result of it:
$ grep 'kfreebsd $prefix/' netboot* -Rs | uniq
netboot/dir_tree/debian-installer/kfreebsd-amd64/grub.cfg: kfreebsd
$prefix/kfreebsd.gz
netboot-9/dir_tree/debian-installer/kfreebsd-amd64/grub.cfg:kfreebsd
$prefix/kfreebsd-9.gz
netboot-gtk/dir_tree/debian-installer/kfreebsd-amd64/grub.cfg: kfreebsd
$prefix/kfreebsd.gz
netboot-gtk-9/dir_tree/debian-installer/kfreebsd-amd64/grub.cfg:
kfreebsd $prefix/kfreebsd-9.gz
Thanks!
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff --git a/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg b/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
index 95897e4..72a601e 100644
--- a/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
+++ b/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
@@ -31,13 +31,13 @@ menuentry {
menuentry Default install {
echo Loading ...
- kfreebsd $prefix/kfreebsd.gz
+ kfreebsd $prefix/@KERNEL@
kfreebsd_module $prefix/initrd.gz type=mfs_root
}
menuentry Automated install {
echo Loading ...
- kfreebsd $prefix/kfreebsd.gz
+ kfreebsd $prefix/@KERNEL@
kfreebsd_module $prefix/initrd.gz type=mfs_root
set kFreeBSD.auto=true
set kFreeBSD.priority=critical
@@ -45,7 +45,7 @@ menuentry Automated install {
menuentry Expert install {
echo Loading ...
- kfreebsd $prefix/kfreebsd.gz
+ kfreebsd $prefix/@KERNEL@
kfreebsd_module $prefix/initrd.gz type=mfs_root
set kFreeBSD.priority=low
}
diff --git a/build/config/kfreebsd.cfg b/build/config/kfreebsd.cfg
index c80740b..b8c2d05 100644
--- a/build/config/kfreebsd.cfg
+++ b/build/config/kfreebsd.cfg
@@ -120,8 +120,9 @@ arch_netboot_dir:
cp $(TEMP_INITRD) $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)
cp $(TEMP_KERNEL) $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)
- sed -e s/@ARCH@/$(ARCH)/g $(GRUB_CFG_PXE) \
- $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)/grub.cfg
+ sed -e s/@ARCH@/$(ARCH)/g \
+ -e s/@KERNEL@/$(notdir $(TEMP_KERNEL))/g \
+ $(GRUB_CFG_PXE) $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)/grub.cfg
if [ -n $(GRUB_FONT) ] ; then \
cp $(GRUB_FONT) $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)/font.pf2; \
fi
Bug#696786: please adjust MFSROOT_LIMIT; adjust lowmem thresholds
Control: -1 tags + patch Hi, Please consider lowering MFSROOT_LIMIT to 72m on kfreebsd-amd64. The initial size of data in the installer MFS roots are: ~/debian-installer/build/tmp$ du -xm --max-depth=0 */tree | sort -bn 9 cdrom_grub/tree 10 netboot/tree 10 netboot-9/tree 37 cdrom_gtk/tree 38 netboot-gtk/tree 38 netboot-gtk-9/tree Testing with netboot-gtk-9, the largest size I've been able to fill the ramdisk to is 68389 KiB used. If we set MFSROOT_LIMIT := 72m this leaves some room whilst still allowing installs with as low as 128 MiB RAM. That is also the default memory setting for qemu-system-x86_64. With MFSROOT_LIMIT := 72m, qemu -m 128 corresponds with a 39444 KiB MemTotal. Smaller than this (e.g. at -m 124), the first thing to fail is actually devd in the early initscripts. So we should set a low=38 threshold to warn the user about 'unpredictable behaviour' otherwise. level1 and level2 memory conservations don't help at this early stage, so they can be set to the same value of 38. (They don't give noticeable benefit anyway since on kFreeBSD the ramdisk allocation is of fixed size, no matter how full it is). Once d-i is running, plenty of memory is free probably for even a full GTK install. But GTK doesn't trigger below MemTotal = 134 due to the calculation by rootskel S60frontend. It corresponds with qemu -m 224. We could (later?) try to lower that threshold, because on kFreeBSD the text-mode installer lacks support for a number of languages, therefore we'd like the GTK installer to be available wherever possible. For the purposes of installation-guide, we can therefore suggest minimum_memory=128, minimum_memory_gtk=224 Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org diff --git a/build/Makefile b/build/Makefile index 60d1845..1e5952d 100644 --- a/build/Makefile +++ b/build/Makefile @@ -133,7 +133,7 @@ endef ifeq ($(DEB_HOST_ARCH),kfreebsd-i386) MFSROOT_LIMIT := 42m else ifeq ($(DEB_HOST_ARCH),kfreebsd-amd64) -MFSROOT_LIMIT := 128m +MFSROOT_LIMIT := 72m endif define mkfs.ufs1 Index: build/arch-options/kfreebsd-amd64 === --- build/arch-options/kfreebsd-amd64 (revision 68416) +++ build/arch-options/kfreebsd-amd64 (working copy) @@ -6,9 +6,9 @@ arch_listname=bsd arch_porturl=kfreebsd-gnu # This is also in the lowmem package -minimum_memory=110 +minimum_memory=128 # This is also in the rootskel package, S60frontend -minimum_memory_gtk=170 +minimum_memory_gtk=224 # These two options should be set if condition 'smp' is set below # TODO: update smp_config_section=Processor type and features diff --git a/debian-installer-startup.d/S15lowmem b/debian-installer-startup.d/S15lowmem index e53ad78..74da8a9 100644 --- a/debian-installer-startup.d/S15lowmem +++ b/debian-installer-startup.d/S15lowmem @@ -67,9 +67,9 @@ else min=28 ;; kfreebsd-amd64) - level1=64 # MT=66456, qemu: -m 146 - level2=32 # MT=33688, qemu: -m 114 - min=29# MT=29592, qemu: -m 110 + level1=38 # MT=39444, qemu: -m 128 + level2=38 # MT=39444, qemu: -m 128 + min=38# MT=39444, qemu: -m 128 ;; kfreebsd-i386) level1=64 # MT=66008, qemu: -m 121 signature.asc Description: OpenPGP digital signature
Bug#696786: please adjust MFSROOT_LIMIT; adjust lowmem thresholds
Hi, Please use this amended patch for lowmem limits. The other patches are unchanged. I found a reason to force lowmem mode: ZFS. If the partman-zfs module is loaded, there is a risk of ZFS exhausting available memory, e.g. if an old ZFS volume is found on one of the disks. level2 lowmem mode would disable that udeb as standard. Normally we'd need 512 MiB to 1 GiB RAM for ZFS to work at all, or at least 4 GiB to work smoothly with ARC. (This probably deserves a separate mention in the installation-guide). Also the low memory warnings are quite sensible anyway - we'd really prefer that users provide more than 128 MiB memory - and once they get to 224 MiB they'll get a GTK installer with the full set of languages. That is what the level2=134 threshold corresponds with. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org diff --git a/debian-installer-startup.d/S15lowmem b/debian-installer-startup.d/S15lowmem index e53ad78..aa9ab8b 100644 --- a/debian-installer-startup.d/S15lowmem +++ b/debian-installer-startup.d/S15lowmem @@ -67,9 +67,9 @@ else min=28 ;; kfreebsd-amd64) - level1=64 # MT=66456, qemu: -m 146 - level2=32 # MT=33688, qemu: -m 114 - min=29# MT=29592, qemu: -m 110 + level1=134 # MT=138136, qemu: -m 224 + level2=134 # MT=138136, qemu: -m 224 + min=38 # MT=39444, qemu: -m 128 ;; kfreebsd-i386) level1=64 # MT=66008, qemu: -m 121 signature.asc Description: OpenPGP digital signature
Bug#701884: kfreebsd: unknown method 'inet6 auto'
Hi Andrew, On 28/02/13 18:20, Andrew Shadura wrote: ifconfig %iface% [[link %hwaddress%]] up sysctl -q -e net.inet6.ip6.accept_rtadv=1 Yes that should be fine. I would have put the sysctl first, and then bring up the interface; not sure if it makes any difference though really. Also, on kfreebsd, are -q and -e valid options to sysctl (not sure if it's implemented the same way or is it a BSD-specific utility there)? Yes I just tried the sysctl and it works as intended. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701884: kfreebsd: unknown method 'inet6 auto'
Hi, On 28/02/13 18:59, Andrew Shadura wrote: So, what is better to do: to use the wrapper, or to call /lib/freebsd/sysctl directly? I think you should just use whatever is in the path, consistent with GNU/Linux. (Currently on GNU/kFreeBSD this is the wrapper for our own sysctl). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation
Hi,
On Wed, Feb 27, 2013 at 19:24:59 +0100, Ondřej Surý wrote:
the doxygen segfaults on kfreebsd-i386 when building opendnssec
package and it blocks it's transition from unstable to testing.
[...]
https://buildd.debian.org/status/logs.php?arch=kfreebsd-i386pkg=opendnssecver=1%3A1.3.9-4
It looks more like it's the 'dot' program from graphviz that hangs. I
ran its regression test suite repeatedly and managed to reproduce a
familiar thread-related hang in sigsuspend:
steven 97235 0.0 0.1 83676 4436 ?T+ 12:03 0:00 /usr/bin/dot
-Kdot -Tps -ondata/colors_dot.ps graphs/colors.gv
(gdb) thread apply all bt full
Thread 1 (process 97235):
#0 __pthread_sigsuspend () at
../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24
No locals.
#1 0x0008038983b8 in __pthread_wait_for_restart_signal (self=optimized
out) at pthread.c:1291
mask = {{__sigbits = {2, 0, 0, 0}, __bits = {2, 0, 0, 0}}}
#2 0x00080389a7b4 in suspend (self=optimized out) at restart.h:34
No locals.
#3 __pthread_alt_lock (lock=optimized out, self=0x1f) at spinlock.c:418
oldstatus = 0
newstatus = 140737488322416
wait_node = {next = 0x1, thr = 0x800637d20, abandoned = 0}
#4 0x000803898023 in *__GI___pthread_mutex_lock (mutex=0x800ff3240) at
mutex.c:123
self = optimized out
#5 0x000800d21f2c in *__GI___libc_free (mem=optimized out) at
malloc.c:3736
ar_ptr = 0x800ff3240
p = optimized out
#6 0x000800844a79 in gvFreeContext () from /usr/lib/libgvc.so.5
No symbol table info available.
#7 0x00400fd8 in ?? ()
No symbol table info available.
#8 0x00080389bf04 in __pthread_sighandler (signo=0, _code=65542,
_sg=0x0, ctx=0x80e9f000) at sighandler.c:39
self = optimized out
#9 0x7083 in ?? ()
No symbol table info available.
#10 0x00080389be60 in ?? () at internals.h:545 from
/lib/x86_64-kfreebsd-gnu/libpthread.so.0
No symbol table info available.
#11 0x in ?? ()
No symbol table info available.
(gdb)
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation
By hitting Ctrl-C at the right moment I can seem to cause 'dot' to hang
easily enough. Attached is a quite different backtrace, which still
resulted in being stuck in __pthread_wait_for_restart_signal
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
(gdb) thread apply all bt full
Thread 1 (process 17844):
#0 __pthread_sigsuspend () at
../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24
No locals.
#1 0x0008038983b8 in __pthread_wait_for_restart_signal (self=optimized
out) at pthread.c:1291
mask = {{__sigbits = {2, 0, 0, 0}, __bits = {2, 0, 0, 0}}}
#2 0x00080389a7b4 in suspend (self=optimized out) at restart.h:34
No locals.
#3 __pthread_alt_lock (lock=optimized out, self=0x1f) at spinlock.c:418
oldstatus = 0
newstatus = 140737488318816
wait_node = {next = 0x1, thr = 0x800637d20, abandoned = 0}
#4 0x000803898023 in *__GI___pthread_mutex_lock (mutex=0x6bc850) at
mutex.c:123
self = optimized out
#5 0x00080258a8d9 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#6 0x00080258c786 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#7 0x000802553e57 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#8 0x0008025542e0 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#9 0x0008025642df in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#10 0x000802593d6a in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#11 0x00080255cc71 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#12 0x00080254f833 in cairo_show_glyphs () from
/usr/lib/x86_64-kfreebsd-gnu/libcairo.so.2
No symbol table info available.
#13 0x0008020dd8f5 in ?? () from
/usr/lib/x86_64-kfreebsd-gnu/libpangocairo-1.0.so.0
No symbol table info available.
#14 0x0008020ddbc4 in ?? () from
/usr/lib/x86_64-kfreebsd-gnu/libpangocairo-1.0.so.0
No symbol table info available.
#15 0x00080230c8dd in pango_renderer_draw_glyphs () from
/usr/lib/x86_64-kfreebsd-gnu/libpango-1.0.so.0
No symbol table info available.
#16 0x00080230d4be in pango_renderer_draw_layout_line () from
/usr/lib/x86_64-kfreebsd-gnu/libpango-1.0.so.0
No symbol table info available.
#17 0x00080230d6e5 in pango_renderer_draw_layout () from
/usr/lib/x86_64-kfreebsd-gnu/libpango-1.0.so.0
No symbol table info available.
#18 0x0008020ddd18 in ?? () from
/usr/lib/x86_64-kfreebsd-gnu/libpangocairo-1.0.so.0
No symbol table info available.
#19 0x000801ed1b4d in ?? () from /usr/lib/graphviz/libgvplugin_pango.so.6
No symbol table info available.
#20 0x000800842d5d in gvrender_textpara () from /usr/lib/libgvc.so.5
No symbol table info available.
#21 0x00080085f3bc in emit_label () from /usr/lib/libgvc.so.5
No symbol table info available.
#22 0x000800872e45 in emit_clusters () from /usr/lib/libgvc.so.5
No symbol table info available.
#23 0x000800873955 in emit_graph () from /usr/lib/libgvc.so.5
No symbol table info available.
#24 0x000800875c9a in gvRenderJobs () from /usr/lib/libgvc.so.5
No symbol table info available.
#25 0x00400fcc in ?? ()
No symbol table info available.
#26 0x00080389bf04 in __pthread_sighandler (signo=0, _code=65542, _sg=0x0,
ctx=0x80e9f000) at sighandler.c:39
self = optimized out
#27 0x7083 in ?? ()
No symbol table info available.
#28 0x00080389be60 in ?? () at internals.h:545 from
/lib/x86_64-kfreebsd-gnu/libpthread.so.0
No symbol table info available.
#29 0x in ?? ()
No symbol table info available.
(gdb)
Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation
reassign 701832 graphviz
found 701832 2.26.3-12
affects 701832 + opendnssec freefoam libdap witty
tags 701832 + patch
thanks
While running doxygen, I've seen 'dot' sometimes hang trying to read
/proc/self/maps; I think this might be what causes the opendnssec build
to hang, and also affecting packages freefoam, libdap, witty in sid.
This happens usually on kfreebsd-i386 but also very rarely on
kfreebsd-amd64 too. A gdb backtrace of a hung 'dot' process is below.
The relevant bit of code in graphviz lib/gvc/gvconfig.c even says:
298 /* this only works on linux, other systems will get GVLIBDIR only */
299 libdir = GVLIBDIR;
300 f = fopen (/proc/self/maps, r);
I'm unsure if this is supposed to work using GNU/kFreeBSD's linprocfs,
but I tried wrapping the problem code with #ifdef linux. I was then
able to build the doxygen docs for opendnssec 250 times on
kfreebsd-amd64 and kfreebsd-i386 without recurrence of this bug yet.
I've no idea if my patch breaks any other functionality (it will fall
back to 'GVLIBDIR only'). But I notice there is another patch
fix-kfreebsd-chroots that already changed this same block of code.
#0 0x000800d73080 in read () at ../sysdeps/unix/syscall-template.S:82
No locals.
#1 0x000800d19160 in _IO_new_file_underflow (fp=0x6030a0) at
fileops.c:606
[0/751]
count = optimized out
#2 0x000800d19bde in _IO_default_uflow (fp=0x4) at genops.c:440
ch = 5
#3 0x000800d102fa in _IO_getline_info (fp=0x6030a0, buf=0x80063b000 ,
n=1023, delim=10, extract_delim=1, eof=0x0) at iogetline.c:74
c = 5
len = 0
ptr = 0x800a9bbc0
#4 0x000800d0f529 in _IO_fgets (buf=buf@entry=0x800a9bbc0 ,
n=optimized out, n@entry=1024, fp=fp@entry=0x6030a0) at iofgets.c:58
_buffer = {__routine = 0x6030a0, __arg = 0x800614335, __canceltype =
0, __prev = 0x0}
_avail = 0
_IO_acquire_lock_file = 0x6030a0
count = optimized out
result = optimized out
#5 0x000800846944 in gvconfig_libdir (gvc=gvc@entry=0x602e80) at
gvconfig.c:303
line = '\000' repeats 1023 times
libdir = 0x8008792b0 /usr/lib/graphviz
path = optimized out
tmp = optimized out
f = 0x6030a0
#6 0x000800846ab9 in gvconfig (gvc=gvc@entry=0x602e80,
rescan=rescan@entry=0 '\000') at gvconfig.c:472
sz = optimized out
config_st = {st_dev = 13322904, st_ino = 8, st_mode = 24640,
__pad_mode = 99, st_nlink = 8, __pad_nlink = 0, st_uid = 13314984, st_gid =
8, st_rdev = 6512704,
st_atim = {tv_sec = 32, tv_nsec = 4294967295}, st_mtim = {tv_sec =
4197488, tv_nsec = 34368266240}, st_ctim = {tv_sec = 4197488, tv_nsec = 0},
st_size = 34368284856,
st_blocks = 34366166680, st_blksize = 2534032, st_flags = 0, st_gen
= 4294967295, __unused1 = {1, 34368266240}}
libdir_st = {st_dev = 4197488, st_ino = 0, st_mode = 0, __pad_mode =
0, st_nlink = 0, __pad_nlink = 0, st_uid = 8518816, st_gid = 8, st_rdev =
16725440, st_atim = {
tv_sec = 2535432, tv_nsec = 34366087712}, st_mtim = {tv_sec = 1,
tv_nsec = 0}, st_ctim = {tv_sec = 536, tv_nsec = 34368284856}, st_size =
6303360, st_blocks = 1,
st_blksize = 4197488, st_flags = 0, st_gen = 6374197, __unused1 =
{6303360, 150}}
f = 0x0
config_text = 0x0
libdir = optimized out
#7 0x000800847e13 in gvContextPlugins (builtins=optimized out,
demand_loading=1) at gvc.c:56
gvc = 0x602e80
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Index: graphviz-2.26.3/lib/gvc/gvconfig.c
===
--- graphviz-2.26.3.orig/lib/gvc/gvconfig.c 2013-03-03 17:26:23.0
+
+++ graphviz-2.26.3/lib/gvc/gvconfig.c 2013-03-03 17:29:41.235960554 +
@@ -297,6 +297,7 @@
#else
/* this only works on linux, other systems will get GVLIBDIR only */
libdir = GVLIBDIR;
+#ifdef linux
f = fopen (/proc/self/maps, r);
if (f) {
while (!feof (f)) {
@@ -323,6 +324,7 @@
fclose (f);
}
#endif
+#endif
}
if (gvc-common.verbose 1)
fprintf (stderr, libdir = \%s\\n,
Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation
On 03/03/13 17:43, Steven Chamberlain wrote: I've no idea if my patch breaks any other functionality (it will fall back to 'GVLIBDIR only'). But I notice there is another patch fix-kfreebsd-chroots that already changed this same block of code. The existing patch was a workaround for: http://bugs.debian.org/575797 In case /proc/self/maps doesn't return useful info (e.g. in a chroot environment on kfreebsd) it will fall back to GVLIBDIR. On the buildds it is always going to be the case. I'm not sure what causes reading from /proc/self/maps to hang sometimes, but there's not much point in doing this on kfreebsd. So I think my patch is probably okay; and it's not necessary to revert the existing patch. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation
Hi, On 05/03/13 03:26, Jeff Epler wrote: On Sun, Mar 03, 2013 at 12:20:57PM +, Steven Chamberlain wrote: #5 0x000800d21f2c in *__GI___libc_free (mem=optimized out) at malloc.c:3736 ar_ptr = 0x800ff3240 p = optimized out #6 0x000800844a79 in gvFreeContext () from /usr/lib/libgvc.so.5 No symbol table info available. #7 0x00400fd8 in ?? () No symbol table info available. #8 0x00080389bf04 in __pthread_sighandler As many of you are probably aware, it's not permitted in POSIX to call free() in signal handler context without some additional guarantees about what the interrupted function may be. Okay, that would make sense! It seemed to me that some other thread (not shown by gdb) had received the signal and freed something the active thread was still using. Sometimes it caused a segfault, and less often resulted in a hang somehow. The SIGINT handler sounds buggy, and maybe not that useful (who needs a half-rendered diagram?) and so it might be best to disable it, which would fix http://bugs.debian.org/524408 ... and in main(): signal(SIGINT, intr); But this was probably unrelated to the cause of the hang seen on the buildds (#701832). That was hopefully fixed by disabling the relevant code for now (which didn't seem useful either), with the patch in http://bugs.debian.org/701832#53. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702206: unblock: graphviz/2.26.3-13
Hi Christoph, On 04/03/13 01:15, Christoph Egger wrote: +graphviz (2.26.3-13) unstable; urgency=low [...] + [ Christoph Egger ] + * Import patch by Steven Chamberlain to fix hangs on kfeebsd (Closes: #701832) Thank you for handling that... Please could you try givebacks of freefoam, libdap, telepathy-qt, witty on kfreebsd-i386 to see if they will build now with graphviz 2.26.3-13? Thanks again, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699704: partman: Please don't load_extra on non-Linux
On 05/03/13 20:51, Cyril Brulebois wrote: If the changelog message looks OK to you, I'll upload that later tonight. Yep, it makes sense. Thank you. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636219: debconf-set-selections can't set values (strings) with a hash
Hi, On 08/03/13 12:23, Ivan Vilata i Balaguer wrote: Package: debconf Version: 1.5.49 I thought this was fixed in that version (but still affecting Squeeze?) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636219: debconf-set-selections can't set values (strings) with a hash
Control: notfound -1 1.5.49 On 08/03/13 13:50, Ivan Vilata i Balaguer wrote: Sorry, I forgot to remove the version number added by reportbug. I'm only having the problem in a Squeeze container, my Sid host isn't affected by the bug. Okay thanks! I'm untagging it. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
Hi g0to, This looks to be an anacron issue, and /etc/cron.daily/apt not running automatically. Please could you take a look at: # cat /var/spool/anacron/cron.daily # grep daily /var/log/cron.log.1 # ps aux | grep cron | grep -v grep Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697890: tasksel arch any? (Re: Bug#697890: iwconfig not in /sbin)
Hi! On 07/03/13 17:58, Christian PERRIER wrote: [...]. The need to be on CD#1 was what drove me to commit. If there are alternative solutions, yes we should consider them. In #697868 I suggested an alternate way to nudge a package onto (GNOME) CD1. Then it would only need to be a Recommends in the task-- so long as it is on the install media I think tasksel chooses to install it: 2. add network-manager-gnome specially to debian-cd's tasks/wheezy/Debian-gnome, after the forcd1 include The forcd1 file itself was not suitable for this package because it lists packages common to *all* desktops. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On 08/03/13 15:08, Arturo Moral wrote: # cat /var/spool/anacron/cron.daily 20130308 This means 'cron' was working properly, and it updated the timestamp in that file. What about the file /etc/cron.d/anacron ? Is it there, what are its contents? Also: $ ls -al /usr/sbin/anacron /etc/init.d/anacron /usr/bin/on_ac_power # grep daily /var/log/cron.log.1 The file /var/log/cron.log.1 does not exist. Thank you. On my system (with rsyslogd) that would be created by logrotate from cron.daily... What about this file instead? # grep daily /var/log/cron.log Thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On 16:27, Arturo Moral wrote: # grep -i daily /var/log/syslog Mar 8 11:27:51 raspi anacron[1920]: Job `cron.daily' terminated The log was probably rotated at that point. Is there anythikng more of interest in the preceding log, e.g. syslog.1 or syslog.1.gz? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
On 08/03/13 17:37, Arturo Moral wrote:
[...] I should see a log
file inside /var/log/unattended-upgrades/ with details on every day's
check [...]
I agree. On a wheezy/sid system using regular cron (not anacron) I get
exactly this each day from unattended-upgrades 0.79.4 when there are no
updates to install:
/var/log/unattended-upgrades/unattended-upgrades.log :
2013-03-08 06:26:39,208 INFO Initial blacklisted packages:
2013-03-08 06:26:39,225 INFO Starting unattended upgrades script
2013-03-08 06:26:39,225 INFO Allowed origins are: ['o=Debian,a=testing',
'origin=Debian,archive=testing,label=Debian-Security']
2013-03-08 06:26:41,758 INFO No packages found that can be upgraded unattended
In addition, I get a separate dpkg log only if there were any packages
to actually update.
I don't think your issue is due to configuration, but here is mine
anyway for reference:
/etc/apt/apt.conf.d/02periodic :
APT::Periodic::Enable 1;
APT::Periodic::Unattended-Upgrade 1;
APT::Periodic::AutocleanInterval 1;
APT::Periodic::Update-Package-Lists 1;
// I already 'randomise' the hour/minute of cron.daily on my hosts
APT::Periodic::RandomSleep 60;
/etc/apt/apt.conf.d/50unattended-upgrades :
Unattended-Upgrade::Origins-Pattern {
o=Debian,a=testing;
origin=Debian,archive=testing,label=Debian-Security;
};
Unattended-Upgrade::Package-Blacklist {
};
Unattended-Upgrade::Mail root@localhost;
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
Hi, Today could you please re-check: # cat /var/spool/anacron/cron.daily # grep anacron /var/log/syslog.1 or: # zgrep anacron /var/log/syslog.1.gz # tail /var/log/unattended-upgrades/unattended-upgrades.log Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701112: (no subject)
Hi, On 12/03/13 03:33, Michael Lustfield wrote: In debian/nginx-common.postinst we have: configure) logdir=/var/log/nginx # Ensure existance and right state of log files and directory if [ ! -d $logdir -a ! -L $logdir ]; then mkdir $logdir chown www-data:adm $logdir chmod 0750 $logdir fi This should create the log directory if it doesn't already exist. We're not enforcing this because the permissions could be changed. Is there any better way to handle this than what we're doing now? I haven't tested, but it seems that this should work. I'm sure I'm missing something... Else if it already exists as a directory, and are upgrading from package version 1.2.1-2.2 or earlier, do a precautionary `chmod o-rx`? If ownership is still 'root:root', should chown to 'www-data:adm' so that log parsers retain access. Maybe a NEWS entry could advise about adding things into that group if they don't run as root or www-data but still need to be able to read the nginx logs? Some test cases I can think of are: * no log parsers in use - chmod o-rx is the important thing to do * logwatch - runs as root? changing the ownership/perms doesn't matter * awstats - the log parser part (update.sh) runs as user www-data * other CGI/PHP apps running as user www-data * other CGI/PHP apps running under separate uids - should be added to a group that has read access. If the admin already changed the user or group of /var/log/nginx, respect that, otherwise chgrp to adm and suggest they add their log parsers into that group if necessary. The alternative would be to just keep wide-open access... Wide-open HTTP logs could be a breach of privacy, reveals usernames for HTTP authentication, IP addresses of visitors, search queries or other HTML form input with a GET action, locations of potentially sensitive documents that would be otherwise impractical to guess, and provides a catalogue of installed web apps that would likely assist an attacker if this were some kind of shared host with other users. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701112: (no subject)
On 12/03/13 13:57, Michael Lustfield wrote: precautionary - That would mean we assume that making the change won't break anything. We're setting this for new installs but forcing it on already deployed systems wouldn't be a good idea. We could add a NEWS entry to recommend making this change. It's definitely not a good idea to force it to happen. I think there is a duty to fix it on upgrade, otherwise having fixed version installed will not be an indication that the system is patched for CVE-2013-0337. Of course if owner/group/permissions were changed in any way since the older nginx package version was installed, I would leave them alone. Otherwise, if removing world read/execute permissions, changing the owner/group to www-data:adm eliminates most risk of anything breaking. The only problem I foresee is the last (unlikely, and inherently secure) example I gave in [#44], where world readable logs are assumed. That could be so easily fixed by adding appropriate users into the adm group, or overriding owner/group/permissions of /var/log/nginx afterward. [#44]: http://bugs.debian.org/701112#44 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702132: unblock linux/3.2.39-2 for wheezy
Hi Samuel, On 13/03/13 11:37, Samuel Wolf wrote: Sorry i am unexperienced on the debian release process, how long time i have to wait for linux/3.2.39-2 in debian wheezy? It depends which install media you are waiting for. A few minutes ago, a new 'mini.iso' was generated, with the new kernel version, and can be found at: http://d-i.debian.org/daily-images/amd64/daily/netboot/gtk/ Most other Wheezy install media are not updated yet: http://www.debian.org/devel/debian-installer/ The 'daily snapshots' may not be updated with the new kernel version for another 20 hours yet. The 'weekly snapshots' on that page will update Monday. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680704: iceweasel/xulrunner: Loongson-2f mipsel iceweasel/xulrunner hasn't been working since several versions back.
Hi! On 24/12/12 20:50, Steven Chamberlain wrote: The hangs we both see in iceweasel 10 on loongson-2f seem similar to #692053 on ia64, which was due to non-4K page size. Stefan Schreiber has just come up with a patch for it. If there is a new upload to unstable with that patch we should both re-test. Stefan's patch was included in 10.0.12esr-1+nmu1 which just finished building tonight. I have been testing and so far it seems good! Javier, you may want to try this. I've visited some sites that triggered the hang with 100% CPU before, but it seems okay now. I upgraded the iceweasel, xulrunner-10.0 and libmozjs10d packages from sid. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697676: Re: Bug#697676: lvm2: cLVM binary package is missing
On 03/03/13 13:57, Vitaly Pashkov wrote: On Thu, 2013-02-28 at 10:08 +0100, Bastian Blank wrote: popcon showed exactly _zero_ installations. Probably a popcon bug or something, which is a different question. We are using clvm in 2 clusters currently and all of the nodes in it have popcon enabled. clvm works fine for us. I think here are the correct popcon stats, around 360 installations: http://qa.debian.org/popcon-graph.php?packages=clvm Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659899: CVE-2012-0790: XSS
Control: reopen -1 Hi, squeeze is vulnerable, as seen on the Navigator Graph page by changing the displaymode in the URL. It gets echoed back by this: return divERROR: unknown displaymode $mode/div I'm not convinced the 'blacklist characters' approach was a great way to handle it, but at least in wheezy/sid it seems no longer possible to inject HTML that way. Even in smokeping-2.6.9 though the start and end time fields are not filtered. For example, enter this in one of the text boxes as a start or end time: now oops and the generated HTML contains: IMG id=zoom BORDER=0 width=697 height=315 SRC=/smokeping/images/__navcache/136343653521739_now oops _1363423440.png Fortunately though, it doesn't seem possible to use an equals sign in these parameters, and so I don't see a way to perform XSS. It is a little scary that these strings are also used to create/unlink files: /var/cache/smokeping/images/__navcache# ls -alt | head -rw-r--r-- 1 www-data root 32316 Mar 16 12:22 136343653521739_now oops _1363423440.png And so for example, a start/end time of: now/ triggers an error; the quotes in the error message are not properly 'quoted', but fortunately HTML tags are being stripped out somehow: ERROR: Could not save png to '/var/cache/smokeping/images/__navcache/136343678121739_now/_1363423440.png' /var/cache/smokeping/images/__navcache/136343678121739_now/_1363423440.png Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
