Bug#694068: wireless fail after stretch^H^H^H^H^H^H^Hbuster^H^H^H^H^H^Hbullseye installation
Having just swatted away this bug while installing bullseye on a laptop that has 1xUSB3, 2xUSB-C and no ethernet, I thought I should share the workaround here. This is only necessary, I'm led to believe, when installing by WiFi without the installation of a Desktop. Before tearing down the WiFi interface at the very end of the installation, the d-i should simply copy the existing /target/etc/network/interfaces file to /target/root/, perhaps named as etc-network-interfaces-at-installation, with its permissions set to 600. When the machine is rebooted, it is now straightforward for the sysadmin to login and simply: # mv /root/etc-network-interfaces-at-installation /etc/network/interfaces # ifup w to give themselves WiFi connectivity (using sudo if necessary). This workaround has the benefit of being fail-safe: the file has no effect on the system if the sysadmin ignores it and leaves it in /root, but if they do move it as above, then they've taken responsibility for its effects on any software they install later. Naturally, it would require a note in the Installation Guide for this method to be useful if the sysadmin is not one to make use of root's home directory. Cheers, David.
Bug#791835: PDF document's headings are gibberish ROT(-1)
Package: release-notes The PDF file at https://www.debian.org/releases/jessie/i386/release-notes.en.pdf has headings which have letter substitutions a->thorn b->a c->b etc. The french version is similar. I haven't checked other languages. The data on page one is July 5, 2015. (256492 bytes.) Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778881: binfmt-support.service activating (start) for ever, no console
Package: binfmt-support Version: 2.1.5-1 Severity: normal Dear Maintainer, * What led up to the situation? Booting up; now happening about once in four times. One reads that: [ Cylon eye ] A start job is running for Enable support for additional executable binary formats (3h 7min 57s / no limit) * What exactly did you do (or not do) that was effective (or ineffective)? Discovered that I can ssh in (when at home) and so I collected the information below. Alternatively I have pressed ^C on the console and/or CtrlAltDel and/or the power button. * What was the outcome of this action? Sometimes, the Cylon eye freezes and the clock stops counting up (or sometimes neither of these). Regardless, I have to hard reset eventually. * What outcome did you expect instead? Some sort of error message and perhaps a recovery mode login, or else some sort of closedown. A secondary observation: logging in over the network via ssh takes much longer than usual, as does then executing /bin/su - --8< $ date ; /bin/su - Fri 20 Feb 16:49:58 CST 2015 Password:(give me a couple of seconds to type the password) date ~# date Fri 20 Feb 16:50:52 CST 2015 ~# --8< Here are some outputs: $ systemctl status binfmt-support.service ● binfmt-support.service - Enable support for additional executable binary formats Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled) Active: activating (start) since Fri 2015-02-20 15:08:26 CST; 27min ago Docs: man:update-binfmts(8) Main PID: 654 (update-binfmts) CGroup: /system.slice/binfmt-support.service └─654 /usr/sbin/update-binfmts --enable $ ls -laR /etc/binfmt.d/ /run/binf* /usr/lib/binfmt.d/ /usr/lib/binfmt-support/ 2>&1 ls: cannot access /run/binf*: No such file or directory /etc/binfmt.d/: total 16 drwxr-xr-x 2 root root 4096 Aug 20 2014 . drwxr-xr-x 154 root root 12288 Feb 20 09:54 .. /usr/lib/binfmt.d/: total 40 drwxr-xr-x 2 root root 4096 Aug 20 2014 . drwxr-xr-x 149 root root 36864 Feb 20 09:54 .. /usr/lib/binfmt-support/: total 108 drwxr-xr-x 2 root root 4096 Oct 3 14:10 . drwxr-xr-x 149 root root 36864 Feb 20 09:54 .. -rwxr-xr-x 1 root root 63296 Aug 24 16:49 run-detectors $ ps ax PID TTY STAT TIME COMMAND 1 ?Ss 8:01 /sbin/init 2 ?S 0:00 [kthreadd] 3 ?S 0:59 [ksoftirqd/0] 5 ?S< 0:00 [kworker/0:0H] 6 ?S 0:00 [kworker/u4:0] 7 ?S 0:01 [rcu_sched] 8 ?S 0:00 [rcu_bh] 9 ?S 0:00 [migration/0] 10 ?S 0:00 [watchdog/0] 11 ?S 0:00 [watchdog/1] 12 ?S 0:00 [migration/1] 13 ?S 1:10 [ksoftirqd/1] 15 ?S< 0:00 [kworker/1:0H] 17 ?S< 0:00 [khelper] 18 ?S 0:00 [kdevtmpfs] 19 ?S< 0:00 [netns] 20 ?S 0:00 [khungtaskd] 21 ?S< 0:00 [writeback] 22 ?SN 0:00 [ksmd] 23 ?SN 0:00 [khugepaged] 24 ?S< 0:00 [crypto] 25 ?S< 0:00 [kintegrityd] 26 ?S< 0:00 [bioset] 27 ?S< 0:00 [kblockd] 28 ?S 0:00 [kworker/1:1] 29 ?S 0:00 [kswapd0] 30 ?S 0:00 [fsnotify_mark] 36 ?S< 0:00 [kthrotld] 37 ?S< 0:00 [ipv6_addrconf] 39 ?S< 0:00 [deferwq] 74 ?S< 0:00 [acpi_thermal_pm] 75 ?S< 0:00 [ata_sff] 77 ?S 0:00 [scsi_eh_0] 78 ?S< 0:00 [scsi_tmf_0] 79 ?S 0:00 [scsi_eh_1] 80 ?S< 0:00 [scsi_tmf_1] 82 ?S 0:00 [kworker/u4:3] 85 ?S< 0:00 [kworker/0:1H] 86 ?S< 0:00 [kworker/1:1H] 107 ?S 0:00 [jbd2/sda1-8] 108 ?S< 0:00 [ext4-rsv-conver] 141 ?Ss 0:00 /lib/systemd/systemd-journald 142 ?S 0:00 [kauditd] 168 ?S< 0:00 [firewire] 170 ?Ss 0:01 /lib/systemd/systemd-udevd 244 ?S< 0:00 [firewire_ohci] 246 ?S 0:00 [khubd] 247 ?S 0:00 [pccardd] 250 ?S< 0:00 [kpsmoused] 251 ?S< 0:00 [cfg80211] 252 ?S 0:00 [irq/18-mmc0] 263 ?S 0:01 [kworker/0:4] 265 ?S< 0:00 [hd-audio0] 274 ?S< 0:00 [iwl3945] 357 ?S< 0:00 [kworker/u5:0] 358 ?S< 0:00 [hci0] 359 ?S< 0:00 [hci0] 369 ?S< 0:00 [kworker/u5:2] 431 ?S 0:00 [jbd2/sda2-8] 432 ?S< 0:00 [ext4-rsv-conver] 436 ?S 0:00 [jbd2/sda3-8] 437 ?S< 0:00 [ext4-rsv-conver] 614 ?Ss 0:00 /sbin/rpcbind -w 623 ?Ss 0:00 /sbin/rpc.statd 628 ?S< 0:00 [rpciod] 631 ?S< 0:00 [nfsiod] 638 ?Ss 0:00 /usr/sbin/rpc.idmapd 643 ?
Bug#731804: apt-cacher-ng stable version
I'm not clear about the status of this bug. Will it ever be closed in wheezy? If not, what is the workaround? My cache just grows and grows, and there appears to be no way of expiring it bacause of this bug. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777558: tex-common: Redundant function in postinst
Package: tex-common
Version: 5.03
Severity: minor
Dear Maintainer,
The following lines (50--55) in the postinst script appear to be
redundant since the removal of a large chunk of postinst.
--8>
cleanup()
{
rc=$?
[ -n "$tempdir" ] && rm -rf "$tempdir"
exit $rc
}
--8>
cleanup used to be called from this snippet:
tempdir=`mktemp -d`
tempfile=`mktemp -p $tempdir`
trap 'cleanup' HUP INT QUIT BUS PIPE TERM
in the wheezy version.
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (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
Init: systemd (via /run/systemd/system)
Versions of packages tex-common depends on:
ii debconf [debconf-2.0] 1.5.55
ii dpkg 1.17.23
ii ucf3.0030
tex-common recommends no packages.
Versions of packages tex-common suggests:
ii debhelper 9.20141022
Versions of packages texlive-base depends on:
ii debconf [debconf-2.0] 1.5.55
ii dpkg 1.17.23
ii libpaper-utils 1.1.24+nmu4
ii texlive-binaries 2014.20140926.35254-6
ii ucf3.0030
ii xdg-utils 1.1.0~rc1+git20111210-7.3
Versions of packages texlive-base recommends:
ii lmodern 2.004.4-5
Versions of packages texlive-base suggests:
ii evince [postscript-viewer] 3.14.1-1
ii ghostscript [postscript-viewer] 9.06~dfsg-2
ii gv [postscript-viewer] 1:3.7.4-1
ii perl-tk 1:804.032-3+b3
ii xpdf [pdf-viewer]3.03-17+b1
Versions of packages texlive-binaries depends on:
ii dpkg 1.17.23
ii install-info 5.2.0.dfsg.1-6
ii libc6 2.19-13
ii libfontconfig12.11.0-6.3
ii libfreetype6 2.5.2-2
ii libgcc1 1:4.9.1-19
ii libgmp10 2:6.0.0+dfsg-6
ii libgraphite2-31.2.4-3
ii libgs99.06~dfsg-2
ii libharfbuzz-icu0 0.9.35-2
ii libharfbuzz0b 0.9.35-2
ii libice6 2:1.0.9-1+b1
ii libicu52 52.1-7
ii libkpathsea6 2014.20140926.35254-6
ii libmpfr4 3.1.2-2
ii libpaper1 1.1.24+nmu4
ii libpixman-1-0 0.32.6-3
ii libpoppler46 0.26.5-2
ii libpotrace0 1.11-2
ii libptexenc1 2014.20140926.35254-6
ii libsm62:1.2.2-1+b1
ii libstdc++64.9.1-19
ii libsynctex1 2014.20140926.35254-6
ii libx11-6 2:1.6.2-3
ii libxaw7 2:1.0.12-2+b1
ii libxext6 2:1.3.3-1
ii libxi62:1.7.4-1+b2
ii libxmu6 2:1.1.2-1
ii libxpm4 1:3.5.11-1+b1
ii libxt61:1.1.4-1+b1
ii libzzip-0-13 0.13.62-3
ii perl 5.20.1-5
ii zlib1g1:1.2.8.dfsg-2+b1
Versions of packages texlive-binaries recommends:
ii python2.7.8-3
ii ruby 1:2.1.0.4
ii texlive-base 2014.20141024-2
ii tk [wish] 8.6.0+8
-- debconf information:
tex-common/check_texmf_missing:
tex-common/check_texmf_wrong:
texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
texlive-base/texconfig_ignorant:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777474: Saving logs to first-user account just installed (wishlist)
Quoting Cyril Brulebois (k...@debian.org): > David Wright (2015-02-08): > > Wishlist: I would like to be able to copy the installation logs to > > /target/home// (using the option "Mounted Filesystem") so > > that when first-user reboots the system, the logs are all there in > > ~/install/ ready for consultation and archival. > Maybe I should ask this first: why do installer logs need to be saved > under /target/home/ while they're already available under > (/target)/var/log/installer by default? Only a wish (not a need); because I will own them (I presume) and I browse/archive them from mc which I don't trust to run as root. Sorry it's not a compelling reason for any degree of hard work to change! > Mraw, I think you've just expanded my vocabulary. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777474: Saving logs to first-user account just installed (wishlist)
Package: installation-reports Boot method: USB image Image version: CD Debian GNU/Linux testing "Jessie" - Official Snapshot i386 NETINST Binary-1 20150126-04:46 Date: 20150129-12:00 Machine: OptiPlex GX520 A11 (11/30/06) Processor: Intel(R) Pentium(R) 4 CPU 3.00GHz Memory: 2.0 GB 533 MHz Dual Interleaved DDR2 SDRAM Partitions: /dev/disk/by-label/ezra02 ext4 28798012 3792184 23519900 14% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 412500 6320406180 2% /run tmpfs tmpfs 103124480 1031164 1% /dev/shm tmpfs tmpfs 5120 4 5116 1% /run/lock tmpfs tmpfs 1031244 0 1031244 0% /sys/fs/cgroup /dev/sdb1 fuseblk 102396 24712 77684 25% /media/olaf01 /dev/sdb2 fuseblk 78020548 22018424 56002124 29% /media/olaf02 /dev/sda1 ext4 28608412 11128372 16003752 42% /agogs /dev/sda3 ext4 419068132 103884372 293873220 27% /home tmpfs tmpfs 20625212206240 1% /run/user/118 tmpfs tmpfs 206252 0206252 0% /run/user/1000 Output of lspci -nn: 00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02) 00:01.0 PCI bridge [0604]: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port [8086:2771] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2776] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 1 [8086:27d0] (rev 01) 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 2 [8086:27d2] (rev 01) 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 01) 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 01) 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 01) 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1) 00:1e.2 Multimedia audio controller [0401]: Intel Corporation 82801G (ICH7 Family) AC'97 Audio Controller [8086:27de] (rev 01) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01) 00:1f.2 IDE interface [0101]: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] [8086:27c0] (rev 01) 00:1f.3 SMBus [0c05]: Intel Corporation NM10/ICH7 Family SMBus Controller [8086:27da] (rev 01) 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express [14e4:1677] (rev 01) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [*] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments: A successful non-graphical expert install. Thanks very much for all the hard work. * Only used partitioner to reformat sda2, and avoided touching swap partition. The ability of the installer's "partitioner" to avoid touching the partition table (and reformatting any of their contents) could perhaps be spelled out more emphatically nowadays because some people have issues with precisely which partition program touches their disk(s). Problems: Wishlist: I would like to be able to copy the installation logs to /target/home// (using the option "Mounted Filesystem") so that when first-user reboots the system, the logs are all there in ~/install/ ready for consultation and archival. Unfortunately, all the while that "Save Logs" is available as an optional step, /target/home// does not yet exist because the accounts are only created *after* "Finish Installation" is executed. There may be an ugly hack: let "Finish Installation" create the user accounts and ask about the RTC. Use the opportunity on these screens to "Go Back" and then "Save Logs". Now repeat "Finish Installation". The user accounts are recreated, and I assume (unchecked) that extra files in /target/home// are not an issue (one can install with
Bug#776233: openclipart: Some images, particularly PNGs, are far too large
Package: openclipart Version: 1:0.18+dfsg-14 Severity: normal Dear Maintainer, Some of the images in this package are far too large. For example -rw-r--r-- 1 3769493 Jun 4 2012 microchip_v.2_havok_redh_01.png -rw-r--r-- 1 3055767 Jun 4 2012 salad_mateya_01.png -rw-r--r-- 1 2829335 Jun 6 2012 stop_sign_right_font_mig_.png -rw-r--r-- 1 2819817 Jun 5 2012 stop_sign_miguel_s_nchez_.png -rw-r--r-- 1 1831764 Jun 4 2012 apple_mateya_01.png -rw-r--r-- 1 1639377 Jun 4 2012 paprika_mateya_01.png -rw-r--r-- 1 1593583 Jun 4 2012 cake_mateya_01.png -rw-r--r-- 1 1564746 Jun 4 2012 bread_mateya_01.png -rw-r--r-- 1 1535656 Jun 4 2012 pasta_mateya_01.png -rw-r--r-- 1 1481671 Jun 4 2012 egg_mateya_01.png -rw-r--r-- 1 1237372 Jun 4 2012 cheese_mateya_01.png -rw-r--r-- 1 1198050 Jun 4 2012 salami_mateya_01.png -rw-r--r-- 1 1086920 Jun 4 2012 banana_mateya_01.png -rw-r--r-- 1 1035599 Jun 4 2012 milk_mateya_01.png Looking inside: /usr/share/openclipart/png/computer/microchip_v.2_havok_redh_01.png PNG 16000x14464 /usr/share/openclipart/png/signs_and_symbols/stop_sign_miguel_s_nchez_.png PNG 20990x29700 At 100dpi, a stop sign that large would completely block the alley behind my house! I have visited the site https://openclipart.org/ and found some of these images. Downloading the largest of the three sizes available there for the microchip gives -rw-r--r-- 1 442072 Jan 25 10:22 Anonymous-microchip-v.2.png (2381x2112 pixels). The effect on a laptop with a 1.8GHz twin processor and 2GB memory running X and the fvwm window manager is that everything stops for several minutes, including the clock display and, worse, the mouse, which means you have to be careful not to click anywhere because when the click action happens, the mouse might be anywhere on the screen after it has played catch-up. Please replace the large images with smaller versions. If large PNGs are required, they can be generated from the svg files. Cheers, David. -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openclipart depends on: ii openclipart-libreoffice 1:0.18+dfsg-14 ii openclipart-png 1:0.18+dfsg-14 ii openclipart-svg 1:0.18+dfsg-14 openclipart recommends no packages. openclipart 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#767163: util-linux: root partition not being fsck'd
Quoting Phillip Susi (ps...@ubuntu.com): [...] > Let me make sure I've got this right: you have two different entries > in /etc/fstab that correspond to the same partition, and one of them > says it is fat? Yes. Years ago, it contained: # root filesystem /dev/hda1 / ext2 ... 0 1 ... some lines ... # mount point for USB stick as that's where they popped up /dev/sda1 /media/foo ... ,user,noauto, ... 0 0 ... (several of these, b, c) ... and it evolved into: # root filesystem LABEL=abcd01 / ext4 ... 0 1 ... many, many more lines for caddies, cards etc ... /dev/sda1 /media/foo ... ,user,noauto, ... 0 0 ... ... Cruft, I know...and less easily spotted now that one doesn't write /dev/sda1 as the name of the root partition but uses UUID/LABEL. AIUI wheezy and previous versions would not fsck /dev/sda1 a second time because of the "0" in the sixth field, and wouldn't try to mount it again because of "noauto" in the fourth field. And because inserting a USB stick would never provoke the kernel into creating a /dev/sda1 (but would use sdb, sdc, etc) the /dev/sda1 line would languish at the bottom of the file, ever forgotten. > I suppose that explains it then: fsck has to pick one > and goes with the one that says it is fat. > > > > [...] > > > I can venture some guesses. Assuming you were still using sysvinit in > sid, checkroot.sh probably unconditionally checks the root without > caring about the order specified in fstab. fsck also probably just > uses the last entry found when more than one applies rather than > trying to arbitrate using the order entry. But "man fstab" says "The order of records in fstab is important because fsck(8), mount(8), and umount(8) sequentially iterate through fstab doing their thing." While one might argue that the "man fsck" option -A which says "Filesystems with a fs_passno value of 0 are skipped and are not checked at all." could excuse fsck from checking /dev/sda1 if it prioritised fstab in the way you suggested , that contradicts "man fstab" which is squarely aimed at me, the system administrator (whereas man fsck -A is aimed at writers of initalisation scripts). So I still think the root filesystem should get checked under these circumstances. Thanks once again to you both for your help in opening my eyes to the problem. I've revised the way I maintain my fstabs! Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767163: util-linux: root partition not being fsck'd
Quoting Phillip Susi (ps...@ubuntu.com): > > That is very odd... what happens if you manually try running fsck -N > on this partition? Well, that revealed what's going on. west ~# fsck -N /dev/sda1 fsck from util-linux 2.25.1 [/sbin/fsck.vfat (1) -- /media/vfat-a1] fsck.vfat /dev/sda1 west ~# fsck -N /dev/sda2 fsck from util-linux 2.25.1 [/sbin/fsck.ext4 (1) -- /westw] fsck.ext4 /dev/sda2 west ~# whereas on wheezy I got west ~# fsck -N /dev/sda1 fsck from util-linux 2.20.1 [/sbin/fsck.ext3 (1) -- /westj] fsck.ext3 /dev/sda1 west ~# fsck -N /dev/sda2 fsck from util-linux 2.20.1 [/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/sda2 west ~# And I recognised "/media/vfat-a1" as something I wrote years ago. For various reasons, some historical, my /etc/fstab looks like: --8<-- LABEL=john01 / ext3errors=remount-ro 0 1 LABEL=john04 none swapsw 0 0 LABEL=john03 /home ext3defaults0 2 LABEL=john02 /westwext4defaults0 2 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto,nodev,noexec,nosuid 0 0 [...] # miscellaneous caddies UUID=2013- /media/lulu02 vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 LABEL=lulu03 /media/lulu03 ext3 rw,user,noauto,nodev,noexec,nosuid 0 0 LABEL=lulu04 /media/lulu04 ext3 rw,user,noauto,nodev,noexec,nosuid 0 0 LABEL=lulu05 /media/lulu05 ext3 rw,user,noauto,nodev,noexec,nosuid 0 0 [...] # miscellaneous USB sticks, SD cards, MP3 players UUID=2009-1001 /media/biolinux4g vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 UUID=2009-0301 /media/elite512vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 # built-in slot /dev/mmcblk0p1 /media/slotvfat rw,utf8,tz=UTC,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 # foreign sticks and cards /dev/sda1 /media/vfat-a1 vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 /dev/sda /media/vfat-a vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 /dev/sdb1 /media/vfat-b1 vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 /dev/sdb /media/vfat-b vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 /dev/sdc1 /media/vfat-c1 vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 /dev/sdc /media/vfat-c vfat rw,utf8,shortname=lower,user,noauto,nodev,noexec,nosuid,fmask=137,dmask=027 0 0 --8<-- If you're wondering why the last paragraph starts at /dev/sda1, it's because my hard drives (I'm still on PATA drives) used to be mounted on /dev/hda... and so the first stick/caddy plugged in would appear as /dev/sda1 (or /dev/sda if the filesystem was not in a partition). I've now observed that my box running sid does both: it fscks /dev/sda1 and then emits the same messages as jessie before it's cleared a moment later. (I grabbed a photograph.) So the problem now seems to be: why does sid bother with an fstab entry that has "0" at the end, and why does jessie apparently throw away the entry that has "1" at the end in favour of the second entry? Would I be correct in guessing that the zero logical sector size comes from picking up a number from a FAT-ty location that contains zero in a linux partition. Thanks for all your help in tracking this down. Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767163: util-linux: root partition not being fsck'd
Quoting Andreas Henriksson (andr...@fatal.se): > [...] > > # udevadm info -n /dev/whatever1 -q property | grep ID_FS_TYPE > > ...and... > > # blkid -p /dev/whatever1 west ~# udevadm info -n /dev/sda1 -q property | grep ID_FS_TYPE ID_FS_TYPE=ext3 west ~# blkid -p /dev/sda1 /dev/sda1: LABEL="john01" UUID="53515dcb-96fb-4c28-b456-1efbd1fdac38" VERSION="1.0" TYPE="ext3" USAGE="filesystem" PART_ENTRY_SCHEME="dos" PART_ENTRY_UUID="c889c889-01" PART_ENTRY_TYPE="0x83" PART_ENTRY_FLAGS="0x80" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="63" PART_ENTRY_SIZE="31246362" PART_ENTRY_DISK="8:0" west ~# west is the system which is running jessie/sid. The other system I mentioned is wasp which is running sid. Its util-linux is version 2.25.2-2 and it has identical symptoms. The main difference is that I recreated the ext4 partition /dev/sda1 on wasp with the wheezy netinst CD before installing minimal wheezy and immediately dist-upgrading to sid. I routinely dump /run/udev/data/b8:... to a file so that I can peruse it elsewhere, so at risk of verbosity here are the /dev/sda and /dev/sda1 for wasp before (running wheezy) and after (running sid). (The information in the files has changed a little from wheezy to sid in any case.) wasp running wheezy: N:sda S:disk/by-id/ata-Hitachi_HDP725050GLAT80_GE1510RE1SEDSA S:disk/by-id/scsi-SATA_Hitachi_HDP7250_GE1510RE1SEDSA S:disk/by-id/wwn-0x5000cca32cd8be62 S:disk/by-path/pci-:00:07.1-scsi-0:0:0:0 W:93 I:6231356 E:ID_ATA=1 E:ID_ATA_DOWNLOAD_MICROCODE=1 E:ID_ATA_FEATURE_SET_AAM=1 E:ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=254 E:ID_ATA_FEATURE_SET_AAM_ENABLED=0 E:ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=128 E:ID_ATA_FEATURE_SET_APM=1 E:ID_ATA_FEATURE_SET_APM_ENABLED=0 E:ID_ATA_FEATURE_SET_HPA=1 E:ID_ATA_FEATURE_SET_HPA_ENABLED=1 E:ID_ATA_FEATURE_SET_PM=1 E:ID_ATA_FEATURE_SET_PM_ENABLED=1 E:ID_ATA_FEATURE_SET_PUIS=1 E:ID_ATA_FEATURE_SET_PUIS_ENABLED=0 E:ID_ATA_FEATURE_SET_SECURITY=1 E:ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E:ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=184 E:ID_ATA_FEATURE_SET_SMART=1 E:ID_ATA_FEATURE_SET_SMART_ENABLED=1 E:ID_ATA_ROTATION_RATE_RPM=7200 E:ID_ATA_WRITE_CACHE=1 E:ID_ATA_WRITE_CACHE_ENABLED=1 E:ID_BUS=ata E:ID_MODEL=Hitachi_HDP725050GLAT80 E:ID_MODEL_ENC=Hitachi\x20HDP725050GLAT80\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E:ID_PART_TABLE_TYPE=dos E:ID_PATH=pci-:00:07.1-scsi-0:0:0:0 E:ID_PATH_TAG=pci-_00_07_1-scsi-0_0_0_0 E:ID_REVISION=GM4OA4A2 E:ID_SCSI_COMPAT=SATA_Hitachi_HDP7250_GE1510RE1SEDSA E:ID_SERIAL=Hitachi_HDP725050GLAT80_GE1510RE1SEDSA E:ID_SERIAL_SHORT=GE1510RE1SEDSA E:ID_TYPE=disk E:ID_WWN=0x5000cca32cd8be62 E:ID_WWN_WITH_EXTENSION=0x5000cca32cd8be62 E:UDISKS_ATA_SMART_IS_AVAILABLE=1 E:UDISKS_PARTITION_TABLE=1 E:UDISKS_PARTITION_TABLE_COUNT=4 E:UDISKS_PARTITION_TABLE_SCHEME=mbr E:UDISKS_PRESENTATION_NOPOLICY=0 N:sda1 S:disk/by-id/ata-Hitachi_HDP725050GLAT80_GE1510RE1SEDSA-part1 S:disk/by-id/scsi-SATA_Hitachi_HDP7250_GE1510RE1SEDSA-part1 S:disk/by-id/wwn-0x5000cca32cd8be62-part1 S:disk/by-label/faye01 S:disk/by-path/pci-:00:07.1-scsi-0:0:0:0-part1 S:disk/by-uuid/46003b4b-1ebc-417b-89f3-694b6557a0e6 W:96 I:6524856 E:ID_ATA=1 E:ID_ATA_DOWNLOAD_MICROCODE=1 E:ID_ATA_FEATURE_SET_AAM=1 E:ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=254 E:ID_ATA_FEATURE_SET_AAM_ENABLED=0 E:ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=128 E:ID_ATA_FEATURE_SET_APM=1 E:ID_ATA_FEATURE_SET_APM_ENABLED=0 E:ID_ATA_FEATURE_SET_HPA=1 E:ID_ATA_FEATURE_SET_HPA_ENABLED=1 E:ID_ATA_FEATURE_SET_PM=1 E:ID_ATA_FEATURE_SET_PM_ENABLED=1 E:ID_ATA_FEATURE_SET_PUIS=1 E:ID_ATA_FEATURE_SET_PUIS_ENABLED=0 E:ID_ATA_FEATURE_SET_SECURITY=1 E:ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E:ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=184 E:ID_ATA_FEATURE_SET_SMART=1 E:ID_ATA_FEATURE_SET_SMART_ENABLED=1 E:ID_ATA_ROTATION_RATE_RPM=7200 E:ID_ATA_WRITE_CACHE=1 E:ID_ATA_WRITE_CACHE_ENABLED=1 E:ID_BUS=ata E:ID_FS_LABEL=faye01 E:ID_FS_LABEL_ENC=faye01 E:ID_FS_TYPE=ext4 E:ID_FS_USAGE=filesystem E:ID_FS_UUID=46003b4b-1ebc-417b-89f3-694b6557a0e6 E:ID_FS_UUID_ENC=46003b4b-1ebc-417b-89f3-694b6557a0e6 E:ID_FS_VERSION=1.0 E:ID_MODEL=Hitachi_HDP725050GLAT80 E:ID_MODEL_ENC=Hitachi\x20HDP725050GLAT80\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E:ID_PART_ENTRY_DISK=8:0 E:ID_PART_ENTRY_FLAGS=0x80 E:ID_PART_ENTRY_NUMBER=1 E:ID_PART_ENTRY_OFFSET=63 E:ID_PART_ENTRY_SCHEME=dos E:ID_PART_ENTRY_SIZE=58588992 E:ID_PART_ENTRY_TYPE=0x83 E:ID_PART_TABLE_TYPE=dos E:ID_PATH=pci-:00:07.1-scsi-0:0:0:0 E:ID_PATH_TAG=pci-_00_07_1-scsi-0_0_0_0 E:ID_REVISION=GM4OA4A2 E:ID_SCSI_COMPAT=SATA_Hitachi_HDP7250_GE1510RE1SEDSA E:ID_SERIAL=Hitachi_HDP725050GLAT80_GE1510RE1SEDSA E:ID_SERIAL_SHORT=GE1510RE1SEDSA E:ID_TYPE=disk E:ID_WWN=0x5000cca32cd8be62 E:ID_WWN_WITH_EXTENSION=0x5000cca32cd8be62 E:UDISKS_PARTITION=1 E:UDISKS_PARTITION_ALIGNMENT_OFFSET=0 E:UDISKS_PARTITION_FLAGS=boot E:UDISKS_PARTITION_NUMBER=1 E:UDISKS_PARTITION_OFFSET=32256 E:UDISKS_PARTITION_SCHEME=mbr E:
Bug#767163: util-linux: root partition not being fsck'd
Package: util-linux Version: 2.25.1-5 Severity: normal Dear Maintainer, My jessie/sid laptop's root filesystem, partition 1, is no longer fsck'd at reboot. After issuing a message, fsck then appears to try and run a FAT fsck on what is an ext3 filesystem that mounts as such. This started happening after upgrading util-linux from 2.20.1-5.11 Wrongly, from jessie/sid daemon.log: /var/log/daemon.log:Oct 28 12:52:39 west systemd-fsck[133]: Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system. [... various systemd-modules-load messages ...] /var/log/daemon.log:Oct 28 12:52:39 west systemd-fsck[133]: Logical sector size is zero. /var/log/daemon.log:Oct 28 12:52:39 west systemd-fsck[133]: fsck.fat 3.0.26 (2014-03-07) The other partitions are fsck'd as normal. Partition 2 is a wheezy installation and booting this works perfectly, including fscking partition 1: Correctly, from wheezy boot.log: Tue Oct 28 10:58:26 2014: [] Checking root file system...fsck from util-linux 2.20.1 Tue Oct 28 10:58:26 2014: \002john02: 322784/977280 files (0.1% non-contiguous), 2355573/3905803 blocks Tue Oct 28 10:58:26 2014: ^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone. Tue Oct 28 10:58:26 2014: [] Cleaning up temporary files... /tmp^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. Tue Oct 28 10:58:26 2014: [^[[36minfo^[[39;49m] Loading kernel module loop. Tue Oct 28 10:58:26 2014: [] Activating lvm and md swap...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone. Tue Oct 28 10:58:26 2014: [] Checking file systems...fsck from util-linux 2.20.1 Tue Oct 28 10:58:27 2014: \002john03: 32349/2809856 files (19.8% non-contiguous), 10565996/11231443 blocks Tue Oct 28 11:02:22 2014: \002john01: 357719/977280 files (6.2% non-contiguous), 2816073/3905795 blocks Tue Oct 28 11:06:41 2014: ^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone. Output from jessie/sid fdisk: Disk /dev/sda: 74.5 GiB, 80026361856 bytes, 156301488 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xc889c889 Device Boot Start End Sectors Size Id Type /dev/sda1 * 63 31246424 31246362 14.9G 83 Linux /dev/sda231246425 62492849 31246425 14.9G 83 Linux /dev/sda362492850 152344394 89851545 42.9G 83 Linux /dev/sda4 152344395 156296384 3951990 1.9G 82 Linux swap / Solaris Extracted from /etc/fstab: LABEL=john01 / ext3 errors=remount-ro 0 1 LABEL=john04 none swap sw0 0 LABEL=john03 /home ext3 defaults 0 2 LABEL=john02 /westw ext4 defaults 0 2 The partitions were originally written by squeeze, and partition 1 has been dist-upgraded to wheezy, then jessie. I have the identical problem on a desktop which has the same partitioning scheme except that (a) I created a new ext4 filesystem in partition 1 while installing from a wheezy netinst CD and (b) it's running sid on partition 1. Cheers, David. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16-2-686-pae (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 Versions of packages util-linux depends on: ii initscripts2.88dsf-53.4 ii libblkid1 2.25.1-5 ii libc6 2.19-11 ii libmount1 2.25.1-5 ii libncurses55.9+20140913-1 ii libpam0g 1.1.8-3.1 ii libselinux12.3-2 ii libslang2 2.3.0-1 ii libsmartcols1 2.25.1-5 ii libtinfo5 5.9+20140913-1 ii libuuid1 2.25.1-5 ii lsb-base 4.1+Debian13 ii tzdata 2014h-2 ii zlib1g 1:1.2.8.dfsg-2 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 3.0.26-4 ii kbd 1.15.5-1 ii util-linux-locales 2.25.1-5 -- debconf information: util-linux/noauto-with-nonzero-passnum: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547329: update-manager-core: Crash after selecting 'No' to safe upgrade question
by 'purging' update-manager, I assume you mean removing update-manager-gnome I preformed the following: $ sudo apt-get remove update-manager-gnome $ sudo apt-get install update-manager-gnome $ sudo apt-get install update-manager-core however I still recieve a similiar experience to the one described in this bug. Since it's related but, to me, different enough, I have opened a bug against it. see #552247 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552247: update-manager-gnome: fatal error if select 'No' to safe upgrade question
Package: update-manager-gnome Version: 0.200.0~rc4-1 Severity: important run: gksudo update-manager Prompted for password: -> enter password GUI popup: Upgrading may require removal or installation of new packages. Do you want to perform a safe-upgrade, which does not remove packages or install new ones -> click No [then 'Install Updates' button is greyed out, until you deselect, then reselect any package in the 'Distribution Updates' list - see bug #551464] Results in a GUI pop up consisting of: "A fatal error has been detected in update-manager. Do you want to submit a bug report? Selecting No will close the application." (clicking 'Yes' proceedes as expected) Desired Results: run: gksudo update-manager Prompted for password: -> enter password click 'Install Updates' Updates Installed (this seems similiar to bug #547329, but I wouldn't call this a 'crash' per-se) -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages update-manager-gnome depends on: ii gconf2 2.26.2-3 GNOME configuration database syste ii gksu 2.0.2-2+b1graphical frontend to su ii python 2.5.4-2 An interactive high-level object-o ii python-dbus0.83.0-1 simple interprocess messaging syst ii python-gconf 2.28.0-1 Python bindings for the GConf conf ii python-gobject 2.18.0-1 Python bindings for the GObject li ii python-gtk22.16.0-1 Python bindings for the GTK+ widge ii python-support 1.0.3 automated rebuilding support for P ii python-vte 1:0.20.5-1Python bindings for the VTE widget ii update-manager-core0.200.0~rc4-1 APT update manager core functional update-manager-gnome recommends no packages. Versions of packages update-manager-gnome suggests: ii software-properties-gtk 0.60.debian-1.1 manage the repositories that you i ii update-notifier 0.70.7.debian-7 Daemon which notifies about packag -- 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#548991: ITP: libcriticism-perl -- Perl pragma to enforce coding standards and best-practices
Package build can be found here http://www.dwright.us/misc/libcriticism-perl_1.02.tar.gz # tar ztvf libcriticism-perl_1.02.tar.gz -rw-r--r-- dwright/dwright 17608 2009-09-30 00:35:11 libcriticism-perl_1.02-1_all.deb -rw-r--r-- dwright/dwright 9551 2009-09-30 00:35:05 libcriticism-perl_1.02-1.diff.gz -rw-r--r-- dwright/dwright 1129 2009-09-30 00:36:10 libcriticism-perl_1.02-1.dsc -rw-r--r-- dwright/dwright 5333 2009-09-30 00:36:17 libcriticism-perl_1.02-1_i386.build -rw-r--r-- dwright/dwright 2061 2009-09-30 00:36:17 libcriticism-perl_1.02-1_i386.changes -rw-r--r-- dwright/dwright 14936 2009-09-12 15:06:37 libcriticism-perl_1.02.orig.tar.gz Lintian Clean and Signed Changes. Now running lintian... Finished running lintian. signed dsc and changes files -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548991: ITP: libcriticism-perl -- Perl pragma to enforce coding standards and best-practices
Package: wnpp Severity: wishlist Owner: david wright * Package name: libcriticism-perl Version : 1.02 Upstream Author : Jeffrey Thalhammer * URL : http://search.cpan.org/dist/criticism/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Perl pragma to enforce coding standards and best-practices This pragma enforces coding standards and promotes best-practices by running your file through Perl::Critic before every execution. In a production system, this usually isn't feasible because it adds a lot of overhead at start-up. If you have a separate development environment, you can effectively bypass the criticism pragma by not installing Perl::Critic in the production environment. If Perl::Critic can't be loaded, then criticism just fails silently. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548618: ITP: libdeclare-constraints-simple-perl -- Perl module to validate data structures
>- Original Message >From: Jonathan Yu >To: david wright ; 548...@bugs.debian.org >Sent: Tue, September 29, 2009 6:24:52 AM >Subject: Re: Bug#548618: ITP: libdeclare-constraints-simple-perl -- Perl >module to validate data > >On Tue, Sep 29, 2009 at 3:43 AM, david wright wrote: >> I am confused by the RT bug filed against this ITP. >> >>>WAITS for copyright clarification from upstream. >>>https://rt.cpan.org/Ticket/Display.html?id=50049 >>>* Initial Release (Closes: #548618) >> >> At the bottom of the module it states: >> http://search.cpan.org/~phaylon/Declare-Constraints-Simple-0.03/lib/Declare/Constraints/Simple. >> >> >> LICENSE AND COPYRIGHT ^ >> >> This module is free software, you can redistribute it and/or modify it under >> the same terms as perl itself. >> >> >> This is a standard perl license and represented in Debian as, >> * License : Artistic | GPL-1+ >> >> >> Am I missing something, why is this not sufficient? >We have license information, sure. But as mentioned in the linked bug >report, we're missing a copyright statement along with years of >copyright, which is why this module is waiting on the upstream. > >Note the first line of the bug: "While packaging your module, for >Debian, I noticed that it doesn't seem to mention copyright >information (in particular, it's missing the applicable years of >copyright)." >> yes, I see now (sometimes, I should wait till morning to post ;) thanks for the clarification. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548618: ITP: libdeclare-constraints-simple-perl -- Perl module to validate data structures
I am confused by the RT bug filed against this ITP. >WAITS for copyright clarification from upstream. >https://rt.cpan.org/Ticket/Display.html?id=50049 >* Initial Release (Closes: #548618) At the bottom of the module it states: http://search.cpan.org/~phaylon/Declare-Constraints-Simple-0.03/lib/Declare/Constraints/Simple.pm LICENSE AND COPYRIGHT ^ This module is free software, you can redistribute it and/or modify it under the same terms as perl itself. This is a standard perl license and represented in Debian as, * License : Artistic | GPL-1+ Am I missing something, why is this not sufficient? Thanks, David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533435: [pida] cannot start, undefined sumbol db
FWIW. I use this package, runs fine for me, I have a vanilla squeeze/sid system. $ uname -a Linux debian 2.6.30-1-486 #1 Sat Aug 15 18:14:04 UTC 2009 i686 GNU/Linux $ cat /etc/debian_version squeeze/sid $ apt-cache showpkg pida Package: pida Versions: 0.5.1-5 (/var/lib/apt/lists/ftp.debian.org_debian_dists_squeeze_main_binary-i386_Packages) (/var/lib/apt/lists/http.us.debian.org_debian_dists_stable_main_binary-i386_Packages) (/var/lib/dpkg/status) Description Language: File: /var/lib/apt/lists/ftp.debian.org_debian_dists_squeeze_main_binary-i386_Packages MD5: 18c237a9897d2b687e02471bdfe1eb96 Reverse Depends: Dependencies: 0.5.1-5 - libatk1.0-0 (2 1.20.0) libc6 (2 2.7-1) libcairo2 (2 1.2.4) libglib2.0-0 (2 2.16.0) libgtk2.0-0 (2 2.12.0) libpango1.0-0 (2 1.20.3) python (3 2.6) python (2 2.4) python-central (2 0.6.7) gvim (0 (null)) python-gnome2 (0 (null)) python-gtkhtml2 (0 (null)) python-gtk2 (0 (null)) python-vte (0 (null)) python-kiwi (0 (null)) python-pkg-resources (2 0.6c8-2) python-glade2 (0 (null)) librsvg2-common (0 (null)) bicyclerepair (0 (null)) python-profiler (0 (null)) pyflakes (0 (null)) gazpacho (2 0.7.1) Provides: 0.5.1-5 - Reverse Provides: $ /usr/bin/env python --version Python 2.5.4 $ which python /usr/bin/python $ ls -lah `which python` lrwxrwxrwx 1 root root 9 2009-09-12 21:50 /usr/bin/python -> python2.5 $ ldd `which python` linux-gate.so.1 => (0xb8082000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb8051000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb804d000) libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb8049000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb8023000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7ec4000) /lib/ld-linux.so.2 (0xb8083000) $ ldd /usr/lib/libdbus-glib-1.so.2 linux-gate.so.1 => (0xb7f8) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0xb7f12000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7ef9000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7ef) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7eb3000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7dfd000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7c9d000) /lib/ld-linux.so.2 (0xb7f81000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7c6c000) $ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 200 http://hype.sourceforge.jp ./ Packages release o=yet anather etch backports,a=etch-backports,n=etch-backports,l=hype,c= origin hype.sourceforge.jp 500 http://http.us.debian.org stable/non-free Packages release v=5.0.3,o=Debian,a=stable,n=lenny,l=Debian,c=non-free origin http.us.debian.org 500 http://http.us.debian.org stable/contrib Packages release v=5.0.3,o=Debian,a=stable,n=lenny,l=Debian,c=contrib origin http.us.debian.org 500 http://http.us.debian.org stable/main Packages release v=5.0.3,o=Debian,a=stable,n=lenny,l=Debian,c=main origin http.us.debian.org 500 http://security.debian.org stable/updates/main Packages release v=5.0,o=Debian,a=stable,n=lenny,l=Debian-Security,c=main origin security.debian.org 990 http://security.debian.org squeeze/updates/contrib Packages release v=None,o=Debian,a=testing,n=squeeze,l=Debian-Security,c=contrib origin security.debian.org 990 http://security.debian.org squeeze/updates/main Packages release v=None,o=Debian,a=testing,n=squeeze,l=Debian-Security,c=main origin security.debian.org 990 http://ftp.debian.org squeeze/main Packages release o=Debian,a=testing,n=squeeze,l=Debian,c=main origin ftp.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#428013: I have built and tested a new version, (current upstream version)
I have built and tested a new version, (current upstream version) I also submitted a RFS, details on both here: http://lists.debian.org/debian-mentors/2009/03/msg00547.html +David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507014: I would expect a 'git' package to represent "Git - Fast Version Control System"
Package: git
Version: 4.9.4-1
Followup-For: Bug #507014
I would expect apt-get install git would be the equilivent of
'sudo aptitude install git-core git-buildpackage pristine-tar'
dwri...@debian:~/$ which git
dwri...@debian:~/$ sudo apt-get install git
dwri...@debian:~/$ which git
dwri...@debian:~/$
dwri...@debian:~/$ sudo aptitude install git-core git-buildpackage pristine-tar
dwri...@debian:~/$ which git
/usr/bin/git
I had to do a search to find how to install git,
("Git - Fast Version Control System") in debian, seems sub-optimal.
running lenny.
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (990, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages git depends on:
ii gnuit 4.9.4-1GNU Interactive Tools, a file brow
git recommends no packages.
git 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
