Bug#726258: libasound2-udeb: Alsa emits garbage in debian installer
Package: libasound2-udeb Version: 1.0.27.2-1 Severity: grave Tags: patch Justification: renders package unusable User: debian-accessibil...@lists.debian.org Usertags: a11y Hello, In the debian installer, the speech synthesizer currently emits mostly garbage. System logs show that ALSA is looking for some files in /usr/share/alsa/pcm, so let's simply ship these files too, as done by the attach patch, and it indeed fixes the issue. Samuel -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel void *memmem (const void *meule_de_foin, size_t lg_meule, const void *aiguille, size_t lg_aiguille); (extrait de la page de man de memmem -- Manuel du programmeur Linux) --- debian/libasound2-udeb.install.orig 2013-10-14 00:05:53.140769749 +0200 +++ debian/libasound2-udeb.install 2013-10-14 00:05:53.796761023 +0200 @@ -1,3 +1,4 @@ usr/lib/*/*.so.* usr/lib usr/share/alsa/cards +usr/share/alsa/pcm usr/share/alsa/alsa.conf
More frequent debian-installer uploads and CD releases?
Hi folks, lemme grab my beautiful d-i hat: U+1F3A9 Background == During the wheezy release cycle, the following debian-installer versions were uploaded (to unstable for most; to wheezy below the dotted line): version used in 20120327 - 20120507 - 20120508 7.0 Alpha 1 20120626 - 20120712 7.0 Beta 1 20120828 7.0 Beta 2 20120930 7.0 Beta 3 20121114 7.0 Beta 4 20130211 7.0 RC 1 20130409 - 20130412 - 20130415 7.0 RC 2 20130430 7.0 RC 3 20130613 7.1 20130613+deb7u1 7.2 This means 13 releases during the development cycle, and one per point release. I'm not sure how you guys see it, but I think this was a rather moderate (or say, reasonable) usage of the project's resources. I've tried to find the right balance between including as many things as possible at once, and not delaying releases for too long; that was a new exercise to me, since I only started out of the blue one month before the freeze… FTR, a debian-installer upload means, e.g. on amd64: 240MB debian-installer-images_20131013_amd64.tar.gz (size varies across architectures, depending on image types, etc.) Proposal / question === So I thought it would be nice to check with all of you how frequently we could think about uploading this package, even if that doesn't lead to preparing CD images every time (hello Steve!). This would affect at least the following components (disc + net): - ftp-master - mirrors - snapshot.debian.org - cdimage - … On the building side of things: - buildds: costs almost nothing, build time is below 1 hour on armel - cdimage: only when building CD images. I think it would be nice if we could be able to perform something like an upload a month during the whole release cycle. History shows that we sometimes needed to fix a few things and re-upload before performing a release (with CD images), but we could probably stay below 20 uploads a year even with such last minute fix-ups when a CD release is planned / needed. Would that work for everyone on the infrastructure side? Or should we arrange (another…) debian-installerspecific thing? I suspect the mainly affected services are: - cdimage: depends on the amount of images we end up keeping, but I guess we drop old development images after a few releases anyway, so shouldn't be too much of a burden as far as disc usage is concerned. - snapshot.debian.org: this one would get much more data than during previous release cycles… Rationale = Why, you ask? We already have dailies, but it isn't always easy to find a good image to "bisect" from (because we only keep a handful as of now). Also, having regular uploads means we always have an image handy (possibly with a set of known bugs), instead of letting things pile up in the repository, and only getting bad surprises when trying to put things up together. [ From experience, the more we do before the freeze approaches, the less pressure we're under when it's there… ] Please keep in mind I'm really interested in learning about the infrastructure side of things. I'm not promising I'll be effectively uploading debian-installer every month. ;) Thanks for your time. Mraw, KiBi. signature.asc Description: Digital signature
Processed: reassign 695500 to src:debian-installer,grub-common
Processing commands for cont...@bugs.debian.org: > reassign 695500 src:debian-installer,grub-common Bug #695500 [debian-installer-7.0-netboot-kfreebsd-amd64] debian-installer-7.0-netboot-kfreebsd-amd64: does not boot from pxe Bug reassigned from package 'debian-installer-7.0-netboot-kfreebsd-amd64' to 'src:debian-installer,grub-common'. No longer marked as found in versions debian-installer-netboot-images/20120828. Ignoring request to alter fixed versions of bug #695500 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 695500: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695500 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.138169731522370.transcr...@bugs.debian.org
Fwd: Status of the first post-wheezy upload to sid
Hi folks, JFYI: | kibi@franck:~$ head -3 hints/kibi | # 2013-10-13 | # d-i: improve l10n coverage (https://lists.debian.org/20131013202314.gd31...@mraw.org) | urgent console-setup/1.102 Also urgented 2 packages for this morning's run in preparation for this first d-i upload. Maybe looking at two uploads before actually building cdimages, depending on how quickly we can find obvious bugs. Mraw, KiBi. --- Begin Message --- Cyril Brulebois (2013-10-13): > I think that the above confirms your thoughts, so I'll probably proceed > with a d-i upload to unstable later today. FWIW we get a warning for all languages, defaulting to not continuing the installation due to possible untranslated screens. That doesn't look too nice to me, and I'm tempted to push console-setup into testing ASAP to get a better translation status and a better installation experience. console-setup diff from testing is: | .gitignore | 612 | Fonts/.gitignore|5 | Keyboard/.gitignore |8 | acm/.gitignore |2 | debian/.gitignore | 17 - | debian/changelog| 36 +++ | debian/po/ar.po | 14 - | debian/po/bg.po | 13 - | debian/po/cs.po |6 | debian/po/da.po |9 | debian/po/de.po | 21 - | debian/po/el.po | 10 | debian/po/eo.po | 10 | debian/po/es.po |8 | debian/po/fr.po |4 | debian/po/ga.po |4 | debian/po/gu.po |6 | debian/po/hr.po |6 | debian/po/is.po | 16 - | debian/po/it.po | 10 | debian/po/ja.po |4 | debian/po/kk.po |8 | debian/po/kn.po |8 | debian/po/lv.po | 13 - | debian/po/ml.po | 27 +- | debian/po/mr.po |8 | debian/po/nb.po | 12 - | debian/po/pl.po | 33 +- | debian/po/ru.po | 60 ++--- | debian/po/sr.po |8 | debian/po/tg.po |4 | debian/po/th.po |4 | debian/po/tr.po |7 | debian/po/ug.po | 14 - | debian/po/uk.po | 15 - | debian/po/zh_TW.po |8 | 36 files changed, 220 insertions(+), 830 deletions(-) meaning no code changes. Additionally, its only shipping arch: all packages means we don't have any builds to wait for. I also noticed missing fonts for Asian languages, some fun with apt-setup (I believe) failing to find bits on the mirrors (but letting the user continue after ACKing a warning screen); speakup seems also buggy (confirmed by Samuel a few minutes ago). The installation process went through though. The fonts and speakup issues are unfortunate and I'll try to track them down ASAP; the idea being getting an image out being to have a reference image, we'll have to live with a few "known bugs", even if they're quite nasty for some users… Mraw, KiBi. signature.asc Description: Digital signature --- End Message --- signature.asc Description: Digital signature
Processed (with 1 errors): d-i-n-i: #695500 is apparently a grub-mkimage (or debian-installer) bug
Processing control commands: > reassign -1 src:debian-installer 20120828 , grub-common 1.99-27 Unknown command or malformed arguments to command. > tags -1 -moreinfo Bug #695500 [debian-installer-7.0-netboot-kfreebsd-amd64] debian-installer-7.0-netboot-kfreebsd-amd64: does not boot from pxe Removed tag(s) moreinfo. > affects -1 +debian-installer-7.0-netboot-kfreebsd-i386 Bug #695500 [debian-installer-7.0-netboot-kfreebsd-amd64] debian-installer-7.0-netboot-kfreebsd-amd64: does not boot from pxe Added indication that 695500 affects debian-installer-7.0-netboot-kfreebsd-i386 > affects -1 +debian-installer-7.0-netboot-kfreebsd-amd64 Bug #695500 [debian-installer-7.0-netboot-kfreebsd-amd64] debian-installer-7.0-netboot-kfreebsd-amd64: does not boot from pxe Added indication that 695500 affects debian-installer-7.0-netboot-kfreebsd-amd64 -- 695500: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695500 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b695500.138169641516888.transcr...@bugs.debian.org
Bug#695500: d-i-n-i: #695500 is apparently a grub-mkimage (or debian-installer) bug
Control: reassign -1 src:debian-installer 20120828 , grub-common 1.99-27 Control: tags -1 -moreinfo Control: affects -1 +debian-installer-7.0-netboot-kfreebsd-i386 Control: affects -1 +debian-installer-7.0-netboot-kfreebsd-amd64 Hi all, I spent some more time debugging this RC bug by setting up my server and testing the PXE boot of kfreebsd-i386 on two different laptops; the results are: * the "error: prefix is not set" error always appears when using the wheezy grub2pxe; it also happens with the current sid grub2pxe [0]; * the resistance to this error apparently depends on the PXE implementation: - my "acer Aspire One" displays the error and then proceeds to displaying grub, then allowing the boot of the kfreebsd-i386 installer; - my "ThinkPad X220" displays the error and stops; - kvm launched locally with [1] proceeds to grub; [0] http://http.debian.net/debian/dists/sid/main/installer-kfreebsd-i386/20130430/images/netboot/grub2pxe [1] kvm -m 256 -net nic -net - user,bootfile=/grub2pxe,tftp=/usr/lib/debian-installer/images/7.0/kfreebsd-amd64/gtk/ As debian-installer-netboot-images is only copying these files from the mirrors, I don't think it is the correct source package to track this bug. The above tests now make me think that this is either a problem of debian-installer calling grub-mkimage wrongly in build/config/kfreebsd.cfg or a bug in grub-mkimage not incorporating the prefix correctly when creating a PXE image. I'm therefore hereby reassigning this bug to both these packages (in their wheezy versions) and marking it as affecting the correct d-i-n-i binary packages. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Status of the first post-wheezy upload to sid
Cyril Brulebois (2013-10-13): > I think that the above confirms your thoughts, so I'll probably proceed > with a d-i upload to unstable later today. FWIW we get a warning for all languages, defaulting to not continuing the installation due to possible untranslated screens. That doesn't look too nice to me, and I'm tempted to push console-setup into testing ASAP to get a better translation status and a better installation experience. console-setup diff from testing is: | .gitignore | 612 | Fonts/.gitignore|5 | Keyboard/.gitignore |8 | acm/.gitignore |2 | debian/.gitignore | 17 - | debian/changelog| 36 +++ | debian/po/ar.po | 14 - | debian/po/bg.po | 13 - | debian/po/cs.po |6 | debian/po/da.po |9 | debian/po/de.po | 21 - | debian/po/el.po | 10 | debian/po/eo.po | 10 | debian/po/es.po |8 | debian/po/fr.po |4 | debian/po/ga.po |4 | debian/po/gu.po |6 | debian/po/hr.po |6 | debian/po/is.po | 16 - | debian/po/it.po | 10 | debian/po/ja.po |4 | debian/po/kk.po |8 | debian/po/kn.po |8 | debian/po/lv.po | 13 - | debian/po/ml.po | 27 +- | debian/po/mr.po |8 | debian/po/nb.po | 12 - | debian/po/pl.po | 33 +- | debian/po/ru.po | 60 ++--- | debian/po/sr.po |8 | debian/po/tg.po |4 | debian/po/th.po |4 | debian/po/tr.po |7 | debian/po/ug.po | 14 - | debian/po/uk.po | 15 - | debian/po/zh_TW.po |8 | 36 files changed, 220 insertions(+), 830 deletions(-) meaning no code changes. Additionally, its only shipping arch: all packages means we don't have any builds to wait for. I also noticed missing fonts for Asian languages, some fun with apt-setup (I believe) failing to find bits on the mirrors (but letting the user continue after ACKing a warning screen); speakup seems also buggy (confirmed by Samuel a few minutes ago). The installation process went through though. The fonts and speakup issues are unfortunate and I'll try to track them down ASAP; the idea being getting an image out being to have a reference image, we'll have to live with a few "known bugs", even if they're quite nasty for some users… Mraw, KiBi. signature.asc Description: Digital signature
Re: Uploading linux (3.11.5-1)
On Sun, 2013-10-13 at 22:04 +0200, Cyril Brulebois wrote: [...] > > - A large number of probably useless drivers were disabled > > Gone from their containing udebs, I suspect? Will take a closer look at > the changelog later on anyway. The initial 3.11 experimental upload still had some obsolete modules listed in the kernel-wedge configuration but I think these are fixed in svn. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Re: Uploading linux (3.11.5-1)
Ben Hutchings (2013-10-13): > It's been quite a while since the last upload to unstable, and by this > point I think 3.11.y should be good enough. I don't know exactly when > I'll have time to do this, but hopefully some time this week. Thanks for letting us know. FWIW I'm currently finalizing a d-i upload against 3.10, so that we have a reference d-i "post-wheezy". > Notable packaging changes in 3.11: > > - armhf single-platform flavours were removed > - armhf has an 'armmp-lpae' flavour which, surprise, has LPAE enabled ISTR Ian mentioned that in his last arm-related changes, so he should be ready to do what's necessary for that. > - ext4 module handles ext2 and ext3 filesystem types in all kernel > configurations; the corresponding udebs are gone ACK. > - linux-headers-*, linux-image-*, linux-source-* will no longer provide > virtual packages Shouldn't be too much of an issue for -boot@ I guess. > - A large number of probably useless drivers were disabled Gone from their containing udebs, I suspect? Will take a closer look at the changelog later on anyway. Mraw, KiBi. signature.asc Description: Digital signature
Uploading linux (3.11.5-1)
It's been quite a while since the last upload to unstable, and by this point I think 3.11.y should be good enough. I don't know exactly when I'll have time to do this, but hopefully some time this week. Notable packaging changes in 3.11: - armhf single-platform flavours were removed - armhf has an 'armmp-lpae' flavour which, surprise, has LPAE enabled - ext4 module handles ext2 and ext3 filesystem types in all kernel configurations; the corresponding udebs are gone - linux-headers-*, linux-image-*, linux-source-* will no longer provide virtual packages - A large number of probably useless drivers were disabled Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Bug#718855: [Pkg-xfce-devel] network-manager-gnome -> full gnome recommends chain
On Thu, 2013-10-10 at 11:32 -0400, Joey Hess wrote: > Yves-Alexis Perez wrote: > > Or tasksel could stop installing recommends, like it was done before, > > and people involved in the various tasks can handle the list explicitly. > > This thread seems to have gone off on a tangent after the correct fix > has already been indentified and committed by Emilio. > Well, maybe that's because people concerned by this disagree with the “correct” fix. Unless I'm mistaken, that still brings gnome-control-center on both first Xfce/LXDE discs and installations. That's not really acceptable, especially if the only other solution is for us to drop network-manager-gnome from the task. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#715408: Error in Testing installier
Hello Andreas, thank you again! The keyboard was: Logitech Illuminated Keyboard (USB), Windows 7 shows the info about the keyboard: PNP-Gerätekennung USB\VID_046D&PID_C318&MI_00\7&3037908E&0& Under the keyboard "PID: LZ137BS" I did not remember if the mouse was ok, but I remember, that the same problem was with graphical and text based installing. All has worked with the stable debian version. Kindly regards Manfred Am 13.10.2013 12:46, schrieb Andreas Cadhalpun: On 13.10.2013 09:38, Manfred Rebentisch wrote: Hello Andreas, thank you for the answer. I have no time in the next few month to test the actual versions. I am not a guru, but a professional debian user since many years - so the problem *was* really a problem. Next year I can test installing again. Thank you for your work! Manfred Hi Manfred, please CC 715...@bugs.debian.org, so that the bug-related information gets collected in one place. > the problem *was* really a problem. I can't see how the system could freeze after showing the first menu, since not much happens before the user selects a language. The only thing I could imagine is that your keyboard did not get recognized correctly, which would have pretty much the same effect as a system freeze. Do you remember, whether the mouse worked in the graphical installer? I assume, the keyboard works with an installed Debian? Could you provide model and vendor of your keyboard? > Next year I can test installing again. When you find time to test installation again, just send a message with the result to 715...@bugs.debian.org and me. Best regards, Andreas -- COMPARAT Software-Entwicklungs-GmbH Prießstraße 16 23558 Lübeck Telefon: 0451/479 56 60 Geschf: Manfred Rebentisch AG Lübeck, HRB 3559 Web: http://www.comparat.de Die Cards: https://cards.athesios.de Der Cards-Film: http://www.youtube.com/watch?v=siZaciL6mdg Businessplattform: https://www.athesios.de Lübeck: http://www.luebeck-info.com Twitter: http://twitter.com/COMPARAT -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525ae823.4090...@comparat.de
console-setup_1.102_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 13 Oct 2013 14:57:17 +0200 Source: console-setup Binary: keyboard-configuration console-setup console-setup-mini console-setup-linux console-setup-freebsd bdf2psf console-setup-udeb console-setup-amiga-ekmap console-setup-ataritt-ekmap console-setup-macintoshold-ekmap console-setup-pc-ekmap console-setup-sun4-ekmap console-setup-sun5-ekmap console-setup-pc-ekbd console-setup-linux-fonts-udeb console-setup-freebsd-fonts-udeb console-setup-linux-charmaps-udeb console-setup-freebsd-charmaps-udeb Architecture: source all Version: 1.102 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: bdf2psf- font converter to generate console fonts from BDF source fonts console-setup - console font and keymap setup program console-setup-amiga-ekmap - encoded Linux keyboard layouts for Amiga keyboards (udeb) console-setup-ataritt-ekmap - encoded Linux keyboard layouts for Atari TT keyboards (udeb) console-setup-freebsd - FreeBSD specific part of console-setup console-setup-freebsd-charmaps-udeb - FreeBSD 8-bit charmaps for console-setup-udeb (udeb) console-setup-freebsd-fonts-udeb - FreeBSD console fonts for Debian Installer (udeb) console-setup-linux - Linux specific part of console-setup console-setup-linux-charmaps-udeb - Linux 8-bit charmaps for console-setup-udeb (udeb) console-setup-linux-fonts-udeb - Linux console fonts for Debian Installer (udeb) console-setup-macintoshold-ekmap - encoded Linux keyboard layouts for old-style Macintosh keyboards (udeb) console-setup-mini - console font and keymap setup program - reduced version for Linux console-setup-pc-ekbd - encoded FreeBSD keyboard layouts for PC keyboards (udeb) console-setup-pc-ekmap - encoded Linux keyboard layouts for PC keyboards (udeb) console-setup-sun4-ekmap - encoded Linux keyboard layouts for Sun4 keyboards (udeb) console-setup-sun5-ekmap - encoded Linux keyboard layouts for Sun5 keyboards (udeb) console-setup-udeb - Configure the keyboard (udeb) keyboard-configuration - system-wide keyboard preferences Changes: console-setup (1.102) unstable; urgency=low . [ Updated translations ] * Danish (da.po) by Joe Hansen * Spanish (es.po) by Javier Fernández-Sanguino * Latvian (lv.po) by Rūdolfs Mazurs Checksums-Sha1: cb3bcac5a2053f422f5cff640e56776b9210a485 3108 console-setup_1.102.dsc aa7a540036592c3d12b6430104c508af7bf27786 3271688 console-setup_1.102.tar.gz a9781683568f58e438ac31e81edf036ba65e2a73 614332 keyboard-configuration_1.102_all.deb 5b0858ec5887bef8a25608d5d81b071e6d71b3f2 115578 console-setup_1.102_all.deb fb17447cb31a6c9bff90471032840ceea8cb6868 22692 console-setup-mini_1.102_all.deb 87b0b57e57542da75aa0da3459392be31e6a21ee 983218 console-setup-linux_1.102_all.deb 0a4e4e9718252a9f23ec917d1220c02e8b56290a 98414 console-setup-freebsd_1.102_all.deb e00f495fe542baf64469ae4394debb33764c5e48 48560 bdf2psf_1.102_all.deb 6dc10b7445660fd279b8cc5c23b51f525295ee9e 211018 console-setup-udeb_1.102_all.udeb 9f4296761e0c9f9a80c68a3bfccb9ca1450be32f 33066 console-setup-amiga-ekmap_1.102_all.udeb f180996f457ac3a30391a64420c44350319f326f 32452 console-setup-ataritt-ekmap_1.102_all.udeb 7e8bab999220ba0d437ad07b1367da91210a1d0e 32570 console-setup-macintoshold-ekmap_1.102_all.udeb f430edfcaf96ffc8163bbca34852ce85254e0874 34986 console-setup-pc-ekmap_1.102_all.udeb 63ffd8ec36387087f1105d4bec2e1360067b4e86 33646 console-setup-sun4-ekmap_1.102_all.udeb 28be3b853027848bb0a9f89cf767ca3f32aa44a7 33794 console-setup-sun5-ekmap_1.102_all.udeb 24bd8d0713a43ddfc885562ace3eeda2f3df4363 29458 console-setup-pc-ekbd_1.102_all.udeb bc55f60c728fa598dd0e47f5d647454e753142f5 17914 console-setup-linux-fonts-udeb_1.102_all.udeb fa6bb6bdfc9e9700c8a6cb13f1138582d252bf76 11044 console-setup-freebsd-fonts-udeb_1.102_all.udeb b2c86a80b95a045744506d28246fc8a1d744f520 22694 console-setup-linux-charmaps-udeb_1.102_all.udeb 8aeee2c197c11d2a115136d69bece64e0418bb7d 7176 console-setup-freebsd-charmaps-udeb_1.102_all.udeb Checksums-Sha256: 545f8ba1e9d2f6c1dc3a1a11e2057ea3bdd0b35be635d0f0f84dce3737ce1590 3108 console-setup_1.102.dsc b5a838c998a210c1a3d2c98d2c2d51f69f6fefe07dc57317ffc899ca895d919f 3271688 console-setup_1.102.tar.gz 874f72ec844f0f9bfcdc28deef94179cbe26f17d4a9ab384e32e6f56091ce855 614332 keyboard-configuration_1.102_all.deb 3df9b730d3ba87c8240de36bfb2f16369f65f1531afa003557f08f557979f9a0 115578 console-setup_1.102_all.deb 7dd2042ac51de1050d5de3064764f26257550e52840141b1e896ec68e555a839 22692 console-setup-mini_1.102_all.deb 754e0ce5cacffbe8b0d5c03157a67c83268247c02f709497e7e8de555a2cdf7b 983218 console-setup-linux_1.102_all.deb 14ab7d28b0bc4d8146a1e2ec95aab89552566dc21de9006bd049084fa0cd07cb 98414 console-setup-freebsd_1.102_all.deb e616dfd458e4732ee9076861692f6699bc70cfbbe76dcfe754bb402440e944be 48560 bdf2psf_1.102_all.deb 9ae3981
Bug#724931: Please include the patch in git
Hi, On 13.10.2013 10:21, ian_br...@fastmail.net wrote: I'm not done with this yet. I'm working on a more general patch with new features, which will be forthcoming shortly. I would ask that nothing major be done until that is ready. I'm curious, what features do you want to add? "loopback" is the name of a virtual network device; the proper term in this context is in fact "loopmount", hence the name of the boot parameter. Yes, loopback is the lo network interface, but for some reason I don't understand, GRUB uses the term loopback for booting from an ISO: https://www.gnu.org/software/grub/manual/grub.html#Loopback-booting This is why I constantly get confused between loopback and (the more descriptive) loopmount. If the boot parameter is not given (or no ISO could be found), everything works essentially as before. As far as I know, if the "loopmount" parameter is not specified, then everything works EXACTLY as before (by design). In my latest patch, some changes are effective, even if loopmount is not used, e.g.: * I cleared up the workaround for bug #608201, so that in the future it should not be necessary to change apt-cdrom-setup, if one adds a new booting method. * Since I included more filesystem drivers in the initrd, I changed the code so that USB-HDD also works from filesystems other than FAT. * I also exported the boot options from cdrom-detect and imported them in several places, instead of determining the again. This should not have any effect, if loopmount is not used, but if it is, the 'loop' option is used. If in the future some changes are made with the boot options in cdrom-detect, they will be respected by apt-cdrom-setup. It appears that the ext4 module would be sufficient to also mount ext2/ext3, whereas the reverse would not be true. I just tested loopmounting from an ext2 filesystem, while only the ext4 filesystem driver was in the initrd: It worked, blkid identified it as ext4 and mounting as such only gave an info message: kernel: [ 13.170123] EXT4-fs (sdb1): mounted filesystem without journal. Opts: (null) And according to Ben there will be no ext2/ext3 modules in the kernel starting with 3.11. So just add the ext4 module. I don't know what usage UDF gets (besides DVDs) that would justify including it in the initrd. I have to admit, that I didn't know more than that a month ago. (Fat is somewhat outdated.) VFAT is by no means outdated, since it is used on almost every USB flashdrive in existence. You might expect that it would eventually be replaced for this purpose by F2FS, but that certainly hasn't happened yet. FAT32 is no modern filesystem, since it doesn't support files larger than 4 GB, e.g. the debian-7.1.0-amd64-DVD-2.iso with 4.7 GB. The reason for it to be still widespread is, that it is supported by (nearly?) all operating systems. While F2FS might be modern and optimized for flash drives, it is only supported in Linux and thus cannot replace FAT32. UDF on the other hand is used for DVDs and most operating systems can read (and even write to) it. Furthermore it supports large files and thus is the most probable replacement for FAT32. For further explanation see: http://duncanlock.net/blog/2013/05/13/using-udf-as-an-improved-filesystem-for-usb-flash-drives/ Already, some USB sticks sold are formatted with UDF. So I recommend to add UDF support now, although it will probably not be relevant for the broad audience until several years have passed by. The patch also cleans up the somewhat messy workaround for bug #608201. A proper fix would be for all ISO images to be treated the same, regardless of whether they were contained in a CD, a disk partition, or a loop-mounted file. I'm not sure why this shouldn't be possible, but it's not the issue we're mainly concerned with at the moment. In fact, with my patch, they are treated practically the same, with the one exception of CD set support, which is only available for actual disks in a drive and loopmounted ISOs. It is probably possible to extend this support to isohybrid and USB-HDD, but it is assumed, that one does not want to use multiple USB sticks to install Debian. For ease of use, I propose to add a loopback.cfg similar to the the attached one to the ISO in the folder /boot/grub/. This would allow to easily mount the ISO using grub2. I can supply similar config files for Syslinux, allowing the use of the original boot menus with a loop-mounted ISO. That would be great. As I have suggested previously, you don't actually have to modify the ISOs for testing; you can just patch an external copy of the initrd and boot with that. That way, the official MD5 and SHA256 hashes still verify. The problem is, that I also have to modify the apt-cdrom-setup.udeb, that is not in the initrd, but gets loaded afterwards from /pool/main/a/apt-setup. * CD: I can't open the CD drive with the button the on the drive. I have to change to another TTY and use 'eject'. (This
Re: Correctness of current translation-status?
Christian PERRIER (2013-10-13): > Hmmm, many languages missing one string: that's console-setup with the > addition of "Tibetan". Are these stats done against testing? That > would explain as the upload of console-setup that fixes the missing > strings for several languages is not yet in testing (and I just > uploaded another release today). Yes, stats are done against testing since that's where udebs are fetched from when building d-i. That's configured through: | l10n/calc-release-status:SUITE=testing Looking at the generated files, particularly stats/console-setup.1: | template: 0 0 109 […] | de: 107 0 2 […] | fr: 108 0 1 I'm not sure whether missing translations in level 1 explains why we get this: - de is mostly translated at 2: 1184/1186 - fr is mostly translated at 2: 1185/1186 but the delta would match, since looking at the missing translations only, we get this single file: | $ grep ^de stats/*.*|grep -v '\s0'$ | stats/console-setup.1:de: 107 0 2 | $ grep ^fr stats/*.*|grep -v '\s0'$ | stats/console-setup.1:fr: 108 0 1 > If that's confirmed, then we shouldn't worry that much. I think that the above confirms your thoughts, so I'll probably proceed with a d-i upload to unstable later today. Mraw, KiBi. signature.asc Description: Digital signature
Re: Correctness of current translation-status?
Quoting Cyril Brulebois (k...@debian.org): > Christian PERRIER (2013-10-13): > > Well, that looks weird. These stats seem to indicate that no language > > is completewhile 21 of them are complete when checking in the git > > repo. > > I assumed the big difference with previous status is that we previously > were failing to perform tag checkout with epochs, and ignoring errors. > > Please find below the end of the script's output. > > The question is: is it OK to upload d-i with such "poor" statistics, or > should be figure out what happens first? Hmmm, many languages missing one string: that's console-setup with the addition of "Tibetan". Are these stats done against testing? That would explain as the upload of console-setup that fixes the missing strings for several languages is not yet in testing (and I just uploaded another release today). If that's confirmed, then we shouldn't worry that much. signature.asc Description: Digital signature
Re: Correctness of current translation-status?
Christian PERRIER (2013-10-13): > Well, that looks weird. These stats seem to indicate that no language > is completewhile 21 of them are complete when checking in the git > repo. I assumed the big difference with previous status is that we previously were failing to perform tag checkout with epochs, and ignoring errors. Please find below the end of the script's output. The question is: is it OK to upload d-i with such "poor" statistics, or should be figure out what happens first? Mraw, KiBi. - am is mostly translated at 2: 1161/1186 - ar is mostly translated at 2: 1184/1186 - ast is mostly translated at 2: 1178/1186 - be is mostly translated at 2: 1178/1186 - bg is mostly translated at 2: 1184/1186 - bn is mostly translated at 2: 1178/1186 - bo is partially translated at 2: 1038/1186 - bs is mostly translated at 2: 1159/1186 - ca is mostly translated at 2: 1178/1186 - cs is mostly translated at 2: 1184/1186 - cy is mostly translated at 2: 1178/1186 - da is mostly translated at 2: 1181/1186 - de is mostly translated at 2: 1184/1186 - dz is partially translated at 2: 1077/1186 - el is mostly translated at 2: 1178/1186 - eo is mostly translated at 2: 1178/1186 - es is mostly translated at 2: 1178/1186 - et is mostly translated at 2: 1178/1186 - eu is mostly translated at 2: 1181/1186 - fa is mostly translated at 2: 1178/1186 - fi is mostly translated at 2: 1178/1186 - fr is mostly translated at 2: 1185/1186 - ga is mostly translated at 2: 1178/1186 - gl is mostly translated at 2: 1178/1186 - gu is mostly translated at 2: 1178/1186 - he is mostly translated at 2: 1178/1186 - hi is mostly translated at 2: 1178/1186 - hr is mostly translated at 2: 1181/1186 - hu is mostly translated at 2: 1181/1186 - hy is limited translated at 2: 18/1186 - id is mostly translated at 2: 1178/1186 - is is mostly translated at 2: 1178/1186 - it is mostly translated at 2: 1184/1186 - ja is mostly translated at 2: 1185/1186 - ka is partially translated at 2: 1007/1186 - kk is mostly translated at 2: 1178/1186 - km is mostly translated at 2: 1178/1186 - kn is mostly translated at 2: 1178/1186 - ko is mostly translated at 2: 1178/1186 - ku is partially translated at 2: 1037/1186 - lo is mostly translated at 2: 1151/1186 - lt is mostly translated at 2: 1178/1186 - lv is mostly translated at 2: 1178/1186 - mk is mostly translated at 2: 1178/1186 - ml is mostly translated at 2: 1178/1186 - mr is mostly translated at 2: 1178/1186 - nb is mostly translated at 2: 1181/1186 - ne is partially translated at 2: 1009/1186 - nl is mostly translated at 2: 1178/1186 - nn is partially translated at 2: 1027/1186 - pa is mostly translated at 2: 1178/1186 - pl is mostly translated at 2: 1181/1186 - pt is mostly translated at 2: 1181/1186 - pt_BR is mostly translated at 2: 1178/1186 - ro is mostly translated at 2: 1178/1186 - ru is mostly translated at 2: 1184/1186 - se is limited translated at 2: 567/1186 - si is mostly translated at 2: 1178/1186 - sk is mostly translated at 2: 1185/1186 - sl is mostly translated at 2: 1178/1186 - sq is partially translated at 2: 1005/1186 - sr is mostly translated at 2: 1178/1186 - sr@latin is limited translated at 2: 44/1186 - sv is mostly translated at 2: 1178/1186 - ta is mostly translated at 2: 1178/1186 - te is mostly translated at 2: 1178/1186 - tg is mostly translated at 2: 1185/1186 - th is mostly translated at 2: 1185/1186 - tl is partially translated at 2: 975/1186 - tr is mostly translated at 2: 1178/1186 - ug is mostly translated at 2: 1184/1186 - uk is mostly translated at 2: 1178/1186 - vi is mostly translated at 2: 1181/1186 - zh_CN is mostly translated at 2: 1178/1186 - zh_TW is mostly translated at 2: 1178/1186 signature.asc Description: Digital signature
Processing of console-setup_1.102_i386.changes
console-setup_1.102_i386.changes uploaded successfully to ftp-master.debian.org along with the files: console-setup_1.102.dsc console-setup_1.102.tar.gz keyboard-configuration_1.102_all.deb console-setup_1.102_all.deb console-setup-mini_1.102_all.deb console-setup-linux_1.102_all.deb console-setup-freebsd_1.102_all.deb bdf2psf_1.102_all.deb console-setup-udeb_1.102_all.udeb console-setup-amiga-ekmap_1.102_all.udeb console-setup-ataritt-ekmap_1.102_all.udeb console-setup-macintoshold-ekmap_1.102_all.udeb console-setup-pc-ekmap_1.102_all.udeb console-setup-sun4-ekmap_1.102_all.udeb console-setup-sun5-ekmap_1.102_all.udeb console-setup-pc-ekbd_1.102_all.udeb console-setup-linux-fonts-udeb_1.102_all.udeb console-setup-freebsd-fonts-udeb_1.102_all.udeb console-setup-linux-charmaps-udeb_1.102_all.udeb console-setup-freebsd-charmaps-udeb_1.102_all.udeb Greetings, Your Debian queue daemon (running on host ravel.debian.org) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vvm7x-0005yi...@ravel.debian.org
Processing of console-setup_1.102_i386.changes
console-setup_1.102_i386.changes uploaded successfully to localhost along with the files: console-setup_1.102.dsc console-setup_1.102.tar.gz keyboard-configuration_1.102_all.deb console-setup_1.102_all.deb console-setup-mini_1.102_all.deb console-setup-linux_1.102_all.deb console-setup-freebsd_1.102_all.deb bdf2psf_1.102_all.deb console-setup-udeb_1.102_all.udeb console-setup-amiga-ekmap_1.102_all.udeb console-setup-ataritt-ekmap_1.102_all.udeb console-setup-macintoshold-ekmap_1.102_all.udeb console-setup-pc-ekmap_1.102_all.udeb console-setup-sun4-ekmap_1.102_all.udeb console-setup-sun5-ekmap_1.102_all.udeb console-setup-pc-ekbd_1.102_all.udeb console-setup-linux-fonts-udeb_1.102_all.udeb console-setup-freebsd-fonts-udeb_1.102_all.udeb console-setup-linux-charmaps-udeb_1.102_all.udeb console-setup-freebsd-charmaps-udeb_1.102_all.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vvmah-0006h9...@franck.debian.org
Bug#724931: Please include the patch in git
On Sun, 2013-10-13 at 01:21 -0700, ian_br...@fastmail.net wrote: > On Sat, 12 Oct 2013 20:03:53 +0200 > Andreas Cadhalpun wrote: [...] > > For the patch to work, the loop-module is needed in the initrd, so I > > suggest to make it a dependency of cdrom-detect. I furthermore highly > > recommend to make the ext2/ext3/ext4, ntfs and udf modules > > dependencies of cdrom-detect, since these are the most common > > filesystems and thus being able to loopmount from them would be good. > > It appears that the ext4 module would be sufficient to also mount > ext2/ext3, whereas the reverse would not be true. [...] The ext2 and ext3 modules are also being removed from Debian kernel packages, starting with Linux 3.11. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Re: Removing linux-modules-di-*-2.6 checkouts on ravel?
Quoting Cyril Brulebois (k...@debian.org): > ravel still has those checkouts (d-i/trunk/packages/linux-modules-di-*-2.6) > around and I'm wondering whether something or someone would still be depending > on their being there. If nobody speaks up, I'll probably move them out of the > way, see if some crontab explodes, and either rm after a while, or put back > into place/fix things up if anything breaks. You can certainly drop them. This is actually me or joeyh forgetting to clean out ravel's copy. signature.asc Description: Digital signature
Re: Correctness of current translation-status?
Quoting Cyril Brulebois (k...@debian.org): > Hi Christian, > > please find attached the output of calc-release-status as of today. I've > committed a few fixes to the said script earlier so that it reaches the > end (mostly making sure the git checkout worked for all packages), but > I'm not sure the results are OK. Can you please have a quick look and > tell me whether they seem realistic? Thanks already! Well, that looks weird. These stats seem to indicate that no language is completewhile 21 of them are complete when checking in the git repo. signature.asc Description: Digital signature
Bug#715408: Error in Testing installier
On 13.10.2013 09:38, Manfred Rebentisch wrote: Hello Andreas, thank you for the answer. I have no time in the next few month to test the actual versions. I am not a guru, but a professional debian user since many years - so the problem *was* really a problem. Next year I can test installing again. Thank you for your work! Manfred Hi Manfred, please CC 715...@bugs.debian.org, so that the bug-related information gets collected in one place. > the problem *was* really a problem. I can't see how the system could freeze after showing the first menu, since not much happens before the user selects a language. The only thing I could imagine is that your keyboard did not get recognized correctly, which would have pretty much the same effect as a system freeze. Do you remember, whether the mouse worked in the graphical installer? I assume, the keyboard works with an installed Debian? Could you provide model and vendor of your keyboard? > Next year I can test installing again. When you find time to test installation again, just send a message with the result to 715...@bugs.debian.org and me. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525a7a21.3030...@gmail.com
Bug#724931: Please include the patch in git
I'm not done with this yet. I'm working on a more general patch with new features, which will be forthcoming shortly. I would ask that nothing major be done until that is ready. The current version is certainly ready for testing, although Andreas already seems to have done so extensively. On Sat, 12 Oct 2013 20:03:53 +0200 Andreas Cadhalpun wrote: > The patch created by Ian Bruce and myself adds ISO loopback support > for the Debian installer using a new boot parameter, to be used as > follows: > > loopmount=[DEVICE:]ISO "loopback" is the name of a virtual network device; the proper term in this context is in fact "loopmount", hence the name of the boot parameter. > Here ISO specifies the path to the ISO, i.e. > /ISO/debian-7.1.0-amd64-CD-1.iso. Relative to the root directory of some block device, of course. > DEVICE is for the name or UUID of the device, on which the ISO is > located. Giving this is optional and if it is not given, all devices > are searched for the ISO. It specifies the filesystem label or UUID, as found in /dev/disk/by-label/ or /dev/disk/by-uuid/, or returned by /sbin/blkid. At least in my version of the patch, if it is not specified, then partitions and CD/DVD drives are searched, but not other devices. > If the boot parameter is not given (or no ISO could be found), > everything works essentially as before. As far as I know, if the "loopmount" parameter is not specified, then everything works EXACTLY as before (by design). > For the patch to work, the loop-module is needed in the initrd, so I > suggest to make it a dependency of cdrom-detect. I furthermore highly > recommend to make the ext2/ext3/ext4, ntfs and udf modules > dependencies of cdrom-detect, since these are the most common > filesystems and thus being able to loopmount from them would be good. It appears that the ext4 module would be sufficient to also mount ext2/ext3, whereas the reverse would not be true. https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_is_the_difference_between_ext2.2C_ext3.2C_and_ext4.3F https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#Can_I_mount_existing_Ext3_as_Ext4.3F_And_vice_versa.3F_Similarly_from_Ext2_to_Ext4_and_its_reverse.3F https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Compatibility There might be some value in including NTFS, so that you could loop-mount from Windoze partitions. I don't know what usage UDF gets (besides DVDs) that would justify including it in the initrd. > (Fat is somewhat outdated.) VFAT is by no means outdated, since it is used on almost every USB flashdrive in existence. You might expect that it would eventually be replaced for this purpose by F2FS, but that certainly hasn't happened yet. Anyway, it's already in the initrd. > The patch makes it possible to boot using USB-HDD from any filesystems > with drivers in the initrd. Actually, from any supported block device with a supported filesystem. It appears that most standard PATA/SATA/SCSI/CDROM/USB drivers are already included in the initrd, so the only thing that would need to be added is "loop.ko" and a few filesystem drivers. > The patch also cleans up the somewhat messy workaround for bug > #608201. A proper fix would be for all ISO images to be treated the same, regardless of whether they were contained in a CD, a disk partition, or a loop-mounted file. I'm not sure why this shouldn't be possible, but it's not the issue we're mainly concerned with at the moment. > For ease of use, I propose to add a loopback.cfg similar to the the > attached one to the ISO in the folder /boot/grub/. This would allow to > easily mount the ISO using grub2. I can supply similar config files for Syslinux, allowing the use of the original boot menus with a loop-mounted ISO. > I tested loopmounting with the following ISOs. (They were modified > with the attached Apply_Patches.sh.) > > * debian-7.1.0-amd64-netinst.iso > * debian-7.1.0-i386-netinst.iso > * debian-7.1.0-amd64-CD-1.iso > * debian-7.1.0-amd64-CD-2.iso (+) > * debian-7.1.0-amd64-CD-3.iso (+) > * debian-7.1.0-amd64-DVD-1.iso > * debian-7.1.0-amd64-DVD-2.iso (+) > > (+): Not modified, just copied to the folder of the first ISO in the > set. As I have suggested previously, you don't actually have to modify the ISOs for testing; you can just patch an external copy of the initrd and boot with that. That way, the official MD5 and SHA256 hashes still verify. > This worked without problems. To make sure all other boot mechanisms > still work, I tested them for the patched debian-7.1.0-amd64-CD-1.iso: > > * Isohybrid: OK > * USB-HDD: OK Thanks for testing all that. > * CD: I can't open the CD drive with the button the on the drive. I > have to change to another TTY and use 'eject'. (This problem exists > also with the original ISO image, see #726137.) I think I also ran into this at some point. > Since the patch works well and does no harm, I ask you to include it > in git. I think thi
