Re: Missing glyphs
On Thu, May 29, 2008 at 12:05:46AM +0600, Jamil Ahmed wrote: On Tue, May 27, 2008 at 1:12 PM, Davide Viti [EMAIL PROTECTED] wrote: Hi Jamil, On Tue, May 27, 2008 at 12:49:13AM +0600, Jamil Ahmed wrote: On Mon, May 26, 2008 at 12:21 AM, Davide Viti [EMAIL PROTECTED] wrote: On Thu, May 22, 2008 at 09:39:57AM +0200, Davide Viti wrote: For bn [2], it seems DOTTED CIRCLE (U+25CC) glyph [4] is missing. [1] http://d-i.alioth.debian.org/gtk-frontend/screenshots/ [2] http://d-i.alioth.debian.org/gtk-frontend/screenshots/2.24-2_vs_2.25-1/common/bn.png [3] http://d-i.alioth.debian.org/gtk-frontend/screenshots/2.24-2_vs_2.25-1/common/zh_CN.png [4] http://www.fileformat.info/info/unicode/char/25cc/index.htm thanx, it has to be a ttf-freefont bug then, will check that. the glyph is definitely not included in current ttf-freefont. Is it a glyph normally found in Bengali text? This glyph is used to indicate combining characters. So I guess all Indic language use it. Actually in your screenshot [2] that part shows wrong spelling. Check my attachment for details. :) thanx for clarifying, does that mean that the problem goes away fixing a typo? No, that glyph will be still missing! :) that's true; I was surprised not to find u+25cc among the codepoints used in bn, see codepoints column in : http://d-i.alioth.debian.org/spellcheck/level1/index.html Caould you please fix that? Yes, I will try to fix the typo shortly. thank you, Davide signature.asc Description: Digital signature
Processed: merging 483210 483469
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.27 merge 483210 483469 Bug#483210: tasksel error Bug#483469: tasksel: errors during D-I installation Merged 483210 483469. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Adding a 686-bigmem netboot image for PAE/Xen (was: Structural changes needed for switch to 2.6.25 kernels)
On Thu, 2008-05-29 at 01:04 +0200, Frans Pop wrote: On Wednesday 28 May 2008, Ian Campbell wrote: On Wed, 2008-05-28 at 02:14 +0200, Frans Pop wrote: Now seems like a good time to remind you that I would like to add -686-bigmem kernel udebs to the mix to support running D-I under PAE Xen. I don't see any real objection to adding only a netboot image, except maybe that it may proof too hard to find for users. So at the very least a very good wiki page should be written that includes a link. Yes, my plan was to update the wiki page on installing Xen once daily builds started appearing. Perhaps a paragraph in the release notes might be appropriate as well? If anybody else has fundamental objections, I guess this would be a good time to voice them! The fairly trivial patch below is required to add 686-bigmem udebs. Not sure why generic_serial is missing in 686-bigmem. Could be a minor config error in linux-2.6. It's because CONFIG_SX and CONFIG_RIO are not set in the 686-bigmem config to pull it in. I don't know why that is but I'll take a look. I don't think these drivers are particularly critical at install time... It would be nice if you could build those, dump them in localudebs, and see if you can figure out what changes are needed in the config dir to add only netboot images for that kernel (if you've never really looked at that it can be a nice challenge; AFAICT changes should only be needed below the installer/build/config dir). Feel free to ask for help if needed. Thanks, I've actually had the config dir changes ready for a while, was just waiting for the beta before submitting them. I've attached the patches which I've been using, updated and freshly tested this morning (make all_build to check nothing else broke and then booted the bigmem one). kernel-wedge.patch: generic_serial is optional and add Xen block and net devices. The block device isn't strictly a SCSI device but it seemed like the best place for it since it isn't worthy of its own udeb, any of sata, pata, ata, ide would be as good... kernel.patch: the entirely trivial linux-kernel-di-i686 patch you have below. base-installer.patch: the selection of a 686-bigmem kernel for install if the installer itself is running 686-bigmem. Has been discussed on list already. hw-detect.patch: a probably useless patch to hw-detect but seems right for completeness. installer.patch: adds the netboot-bigmem flavour to the build. watch out since this also includes the 2.6.24-2.6.25 jump. I still have one or two outstanding patches relating to Xen specifically (mainly hvc0 handling) which I will post separately when I'm happy with them. Cheers, Ian. Cheers, FJP diff --git a/packages/kernel/kernel-wedge/modules/serial-modules b/packages/kernel/kernel-wedge/modules/serial-modules index 44de44e..5b2036c 100644 --- a/packages/kernel/kernel-wedge/modules/serial-modules +++ b/packages/kernel/kernel-wedge/modules/serial-modules @@ -1,2 +1,2 @@ -generic_serial +generic_serial ? serial_cs ? diff --git a/packages/kernel/linux-kernel-di-i386-2.6/kernel-versions b/packages/kernel/linux-kernel-di-i386-2.6/kernel-versions index 808bf40..5b415dd 100644 --- a/packages/kernel/linux-kernel-di-i386-2.6/kernel-versions +++ b/packages/kernel/linux-kernel-di-i386-2.6/kernel-versions @@ -1,2 +1,3 @@ # arch version flavour installednamesuffix build-depends i386 2.6.25-2 486 2.6.25-2-486 - linux-image-2.6.25-2-486 +i386 2.6.25-2 686-bigmem2.6.25-2-686-bigmem - linux-image-2.6.25-2-686-bigmem -- Ian Campbell May not be reproduced, in whole or in part, by any means, mechanical or electronic, except for brief excerpts for the purpose of inclusion in reviews. Index: kernel/kernel-wedge/debian/changelog === --- kernel/kernel-wedge/debian/changelog (revision 53508) +++ kernel/kernel-wedge/debian/changelog (working copy) @@ -1,5 +1,6 @@ kernel-wedge (2.45) UNRELEASED; urgency=low + [ Frans Pop ] * Updates for 2.6.25. * scsi-modules: atp870u is no longer available. * crypto-core-modules: blkcipher has been renamed to crypto_blkcipher. @@ -12,6 +13,10 @@ * Add an nls-core-modules udeb for the nls_base module. All nls_* modules and several filesystem modules depend on it. + [ Ian Campbell ] + * Include Xen net and block drivers. + * generic_serial is optional (for 686-bigmem support). + -- Frans Pop [EMAIL PROTECTED] Tue, 27 May 2008 16:31:38 +0200 kernel-wedge (2.44) unstable; urgency=low Index: kernel/kernel-wedge/modules/nic-modules === --- kernel/kernel-wedge/modules/nic-modules (revision 53508) +++ kernel/kernel-wedge/modules/nic-modules (working copy) @@ -8,3 +8,4 @@ tulip winbond-840 eth1394 ? +xen-netfront ? Index: kernel/kernel-wedge/modules/scsi-modules
Re: suboptimal cat usage
On Wednesday 28 May 2008, Philip Hands wrote: I've had a quick look, but after only a few items I have some doubts... Let me explain why I had doubts. We are currently at the point where we should be stabilizing D-I for Lenny. We're supposed to be removing the last pesky and dumb code errors, not introducing new ones. The huge risk here is that some stupid little error is going to slip through in a little used codepath that does not get tested anymore before the release, but happens to break any install on type Y systems for arch X. Also, we have seen in the past that busybox can sometimes either not support some options or behave slightly differently, especially for more obscure (less used / advanced) options. So basically I agree with the concept, but have problems with the timing. However, that does not mean you cannot work on this. Especially as you use local a git-svn checkout, relatively small changes like this should keep quite well, even if not committed in the central repository. So let me suggest the following: - Commit your changes in git locally. - Use separate commits per patch or set of related patches (like the partman 'cut -c-N' ones). - Add meaningful commit messages, especially when a change is not trivial (as in the case of 'uniq -u'); don't bother with changelogs yet. - When you have a bunch of changes, sort them into separate branches for 'trivial, impossible that it breaks anything', 'probably OK, but not 100% sure', 'needs review/testing', 'changes or could change behavior'. The sorting can be done using 'git cherry-pick'. - The first category you could IMO just commit. We can review them based on the commit messages. - Anything other than the first category should IMO wait until after the Lenny release. We could possibly do the second with reviews, but I'd rather spend the energy on testing and functional changes we want in Lenny. - After Lenny it should be fairly trivial to rebase the changes against then current SVN. I'd expect very little fallout or conflicts (best avoid making loads of changes in a single larger block of code though). Accidental breakage is then a lesser concern. That should be this instead: wc -l massbuild.versions cat file | foo can always be done more efficiently as foo file but I generally leave out the redirection if I can get away with it (which of course in this case, I could not :-/ ) Agreed, though it always feels a bit like reading right to left or top posting to me. well, we could go for the redirection approach instead, but I'd be very surprised if you found any more such errors, as I'm pretty sure that the other examples were well tested (except that I'll admit to having tested them under busybox on a full Debian system, rather than in a d-i system -- I'll test them all again under d-i proper if you think that there's a danger that busybox varies in its behaviour (which I _seriously_ hope it doesn't) See above. Please do check anything that is not already commonly used in D-I with busybox. I checked the 'cut -c-N' and 'uniq -u' and those seem OK. - for dir in $( (cat /tmp/mount.pre /tmp/mount.pre; mountpoints ) | \ - sort -r | uniq -c | grep ^[[:space:]]*1[[:space:]] | \ - sed s/^[[:space:]]*[0-9][[:space:]]//); do + for dir in $(mountpoints | sort -r /tmp/mount.pre /tmp/mount.pre - | uniq -u); do 1) I find the combination of using a pipe _and_ named files for sort unintuitive and less readable Yeah, I'll give you that -- I was wondering if that was such a good idea. 2) Where did the grep and sed statements disappear to? they're a somewhat log-winded reimplementation of uniq -u OK. That could have been explained in a (git) commit message included in the patch. It was non-obvious to me (at least not within the time I want to spend on review). Having the comment would have avoided the question. For improved readability, how about: for dir in $( (cat /tmp/mount.pre /tmp/mount.pre; mountpoints) | \ sort -r | uniq -u); do Yes, better. Maybe add a space before the last closing parenthesis too. Re some of the other changes in your original patch: - yaboot-installer: category 1 - floppy-retriever/debian/load-floppy.postinst In current script spaces get dropped by not quoting in the echo statements a bit lower down, so should be OK. Category 2. - localechooser - redundant use of cat: no problem - 'wc -l': broken - partman: fine with me, needs good commit and changelog messages These statements should IMO already have had a comment. Can you add one? Maybe: # Truncate label to N characters If you need any help with git for this, feel free to ask. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: d-i status wrt i386 amd64 EFI machines
On Wednesday 28 May 2008, Julien BLACHE wrote: There already is code to recognize Intel Macs as a separate subarch which allows to use separate partitioning recipes that could include a EFI system partition, but currently that means the existing one would probably be lost. Which is not a good idea :) So if Mac 1st partition is FAT32 - mark the partition as being the EFI partition (can be generalized to all the EFI machines I think). The real problem here is that partman-auto will always start from scratch when partitioning a drive (except when largest free space is used, but that only works if the free space is already there [1]). The only way to keep an existing partition is by using a custom recipe and setting its size to _exactly_ the current size and doing the same for all partitions that come before it. Any deviation will mean that start of partition and actual start of file system will no longer be the same. This is further complicated by the size calculations and rounding done by partman and libparted. Throw LVM and crypto overheads in the mix and you have a recipe for disaster... There is no provision to say partition the drive, but leave the first one alone. Especially for the first partition (if it is #1 and at the beginning of the disk) that should be possible to implement though by coding what I described in [1] (the recipe used should then of course not include an EFI partition). I'm now going to move this thread to /dev/null and just let you get on with things :-) Good luck, FJP [1] A trick I sometimes use is to use manual partitioning to delete unwanted partitions and then start guided partitioning from partman's main menu to partition the freed up space. signature.asc Description: This is a digitally signed message part.
Bug#482335: installationreport: problems with german keymap
reassign 482335 cdebconf-gtk-udeb severity 482335 serious retitle 482335 [G-I] [regression] Some characters on German keyboards broken tags 482335 confirmed thanks On Thursday 22 May 2008, Holger Wansing wrote: No, this has nothing to do with dead keys or characters composed by typing an accent and then the letter. The german umlauts öäüß are own characters as oau. There are lower case and upper case forms of them, while the upper case are created with the normal shift key. See http://de.wikipedia.org/wiki/Bild:Qwertz_de.svg In VT2 all keys work correctly. OK. I have just confirmed the regression. As VT2 is correct, it is unlikely that this is an issue in the keymap, although that should be checked for changes. Most likely the regression is in either cairo or directfb, but reassigning to cdebconf until we can trace it more exactly. It would be good if someone could confirm whether the same problem also affects other languages that have similar keys. I checked the Dutch keyboard and that is also affected: the ± and ˚ keys (first gives +, second is dead). And: I just tried with a 4.0r1 installation DVD: no problems, all keys work correctly. I have just checked and Lenny Beta1 was still good. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Processed: Re: Bug#482335: installationreport: problems with german keymap
Processing commands for [EMAIL PROTECTED]: reassign 482335 cdebconf-gtk-udeb Bug#482335: installationreport: problems with german keymap Bug reassigned from package `installation-reports' to `cdebconf-gtk-udeb'. severity 482335 serious Bug#482335: installationreport: problems with german keymap Severity set to `serious' from `normal' retitle 482335 [G-I] [regression] Some characters on German keyboards broken Bug#482335: installationreport: problems with german keymap Changed Bug title to `[G-I] [regression] Some characters on German keyboards broken' from `installationreport: problems with german keymap'. tags 482335 confirmed Bug#482335: [G-I] [regression] Some characters on German keyboards broken There were no tags set. Tags added: confirmed thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatic builds re-enabled
Op 16-05-2008 om 01:18 schreef Felipe Augusto van de Wiel (faw): On 13-05-2008 21:36, Felipe Augusto van de Wiel (faw) wrote: Usually, we run the automatic builds on Tuesdays, Thursdays, Saturdays and Sundays, from 'mustang' (a machine under my administration), That is about the d-i manual until ssh-key logins are re-enable I will run, sporadically, manual builds, but do not expect it to be as regular as the automatic ones, sorry for the inconvenient. :-( Automatic builds are re-enabled. :-) The daily builds for d-i sparc are manually uploaded. Automatic upload doesn't work yet for my account. On server gluck has ~stappers/.ssh/authorized_keys the public ssh-key from the computer where the d-i is done. That key upload load was done with 'ssh-copy-id'. With another server got I it working. Does more, besides authorized_keys update, needed be done on gluck? Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Skip kbd-chooser when running under Xen
Ian Campbell [EMAIL PROTECTED] writes: On Mon, 2008-05-26 at 12:38 +0200, Ferenc Wagner wrote: Will this patch do the right thing if Xen is being installed using the paravirutal framebuffer device present in 2.6.26-rc? It looks to me as if it will not. Good point, I don't know anything about this new stuff. What do you think the best scenario would be? Will that framebuffer be the default when there's nothing specified on the kernel command line? Does it make keyboard configuration sensible or even necessary? Anyway, would adding a check for console=hvc0 (in conjuction with the present Xen check, so not to break the real PowerPC console) suffice? Or is there a possibility of the hvc console becoming the default? -- Cheers, Feri. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Skip kbd-chooser when running under Xen
On Thu, 2008-05-29 at 15:04 +0200, Ferenc Wagner wrote: Ian Campbell [EMAIL PROTECTED] writes: On Mon, 2008-05-26 at 12:38 +0200, Ferenc Wagner wrote: Will this patch do the right thing if Xen is being installed using the paravirutal framebuffer device present in 2.6.26-rc? It looks to me as if it will not. Good point, I don't know anything about this new stuff. What do you think the best scenario would be? Will that framebuffer be the default when there's nothing specified on the kernel command line? Unfortunately it is more complex than that... If I understand correctly (and I'm not sure I do) with recent kernels (i.e. 2.6.26-rcN) the PVFB will be the default if the device is configured for that domain (i.e. in the xm config file in domain 0), otherwise hvc0 will be the default. Does it make keyboard configuration sensible or even necessary? I'm not *sure* but I think when using PVFB keymap configuration does make sense. Anyway, would adding a check for console=hvc0 (in conjuction with the present Xen check, so not to break the real PowerPC console) suffice? Or is there a possibility of the hvc console becoming the default? Unfortunately yes, it is already the case in the git repo I think. Ian. -- Ian Campbell Current Noise: Isis - Lines Across Eyes If men acted after marriage as they do during courtship, there would be fewer divorces -- and more bankruptcies. -- Frances Rodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Skip kbd-chooser when running under Xen
Ian Campbell [EMAIL PROTECTED] writes: On Thu, 2008-05-29 at 15:04 +0200, Ferenc Wagner wrote: Ian Campbell [EMAIL PROTECTED] writes: On Mon, 2008-05-26 at 12:38 +0200, Ferenc Wagner wrote: Will this patch do the right thing if Xen is being installed using the paravirutal framebuffer device present in 2.6.26-rc? It looks to me as if it will not. Good point, I don't know anything about this new stuff. What do you think the best scenario would be? Will that framebuffer be the default when there's nothing specified on the kernel command line? Unfortunately it is more complex than that... If I understand correctly (and I'm not sure I do) with recent kernels (i.e. 2.6.26-rcN) the PVFB will be the default if the device is configured for that domain (i.e. in the xm config file in domain 0), otherwise hvc0 will be the default. Does it make keyboard configuration sensible or even necessary? I'm not *sure* but I think when using PVFB keymap configuration does make sense. I've found this old thread only. It's muddy, for the least. http://lists.xensource.com/archives/html/xen-devel/2007-01/msg00383.html Anyway, would adding a check for console=hvc0 (in conjuction with the present Xen check, so not to break the real PowerPC console) suffice? Or is there a possibility of the hvc console becoming the default? Unfortunately yes, it is already the case in the git repo I think. We will need a more generic approach then. But I don't know a way to detect the current console device. Maybe a specific ioctl, which is supported by hvc only? Or is it directly available under /sys? On the other hand, there's not much to gain here and perhaps we'd better wait until these things stabilize. -- Cheers, Feri. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 311158 to busybox
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.26ubuntu3~hardy1 reassign 311158 busybox Bug#311158: busybox-cvs: support for dpkg 1.13 Bug reassigned from package `busybox-cvs' to `busybox'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 251846 to busybox
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.26ubuntu3~hardy1 reassign 251846 busybox Bug#251846: busybox-cvs: debian/rules does clean before building Bug reassigned from package `busybox-cvs' to `busybox'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 250047 to busybox
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.26ubuntu3~hardy1 reassign 250047 busybox Bug#250047: many strange problems loading 2.6 kernel modules on i386 Bug reassigned from package `busybox-cvs' to `busybox'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 237351 to busybox
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.26ubuntu3~hardy1 reassign 237351 busybox Bug#237351: busybox-cvs: ash loves to terminate randomly on my SS10 Bug reassigned from package `busybox-cvs' to `busybox'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
win32-loader help
I ran the loader, and it worked fine. When I rebooted it had 2 options, Debian install or windows, I chose Debian installer. It then goes to a bash like screen that has the prompt grub, and says something about minimule bash like commands can be used and to press tab for a list of commands. Shouldnt it start the installer at that point? -- -Thanks, Colin
Re: d-i status wrt i386 amd64 EFI machines
Frans Pop [EMAIL PROTECTED] wrote: Hi, There is no provision to say partition the drive, but leave the first one alone. Especially for the first partition (if it is #1 and at the beginning of the disk) that should be possible to implement though by coding what I described in [1] (the recipe used should then of course not include an EFI partition). I kind of expected something like that, to be honest :) It sure gets complicated when the partition to keep is in the middle of the disk, but fortunately that case shouldn't happen. Also being able to automatically protect a partition could be also be useful on mips for SGI machines where a volume header must exist on the disk. Though I don't remember how this is handled by d-i, it's been like forever since I last ran d-i on an SGI. Anyway, one thing at a time; there are several levels of support we can provide, let's get something basic working first and build from there. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: win32-loader help
On Thu, May 29, 2008 at 12:00:01PM -0500, Colin Horgan wrote: I ran the loader, and it worked fine. When I rebooted it had 2 options, Debian install or windows, I chose Debian installer. It then goes to a bash like screen that has the prompt grub, and says something about minimule bash like commands can be used and to press tab for a list of commands. Shouldnt it start the installer at that point? Yes. What happens if you try: ls ls (hd0,1) ls (hd0,1)/ cat (hd0,1)/grub.cfg ? Please include the output of each of these commands (a picture is ok as long as it's readable). Thanks -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Uploads of daily D-I builds (was: on .ssh/authorized_keys files)
So basically this is what needs to be done to get uploads for daily D-I builds working again for remaining architectures. Does anybody who has a build running want to coordinate that? Maybe setup a (more) common system for it? Cheers, FJP -- Forwarded Message -- Subject: on .ssh/authorized_keys files Date: Thursday 29 May 2008 From: Peter Palfrader [EMAIL PROTECTED] To: [EMAIL PROTECTED] The use of ~user/.ssh/authorized_keys files has been disabled since DSA1571 was announced. While our initial plan was to allow them again eventually some bad experience with DDs' key handling has led us to reconsider that intent. So ~user/.ssh/authorized_keys will remain disabled. If you want to login to debian.org hosts using keys you should send them to the LDAP as outlined at URL:https://db.debian.org/doc-mail.html, which allows us to do at least some quality control. Should you need keys only on specific hosts for automated tasks like updating stuff or syncing files between project machines or similar we can enable a user editable authorized_keys file for specific users on specific hosts. Usually we would expect those keys to be limited to use only from certain hosts (using from=xyz) and limited to allow execution of only certain commands (using command=foobar). Contact DSA if you have such a case. Your sysadmins --- signature.asc Description: This is a digitally signed message part.
tasksel_2.74.1_i386.changes ACCEPTED
Accepted: task-overrides_2.74.1_all.tar.gz byhand tasksel-data_2.74.1_all.deb to pool/main/t/tasksel/tasksel-data_2.74.1_all.deb tasksel_2.74.1.dsc to pool/main/t/tasksel/tasksel_2.74.1.dsc tasksel_2.74.1.tar.gz to pool/main/t/tasksel/tasksel_2.74.1.tar.gz tasksel_2.74.1_all.deb to pool/main/t/tasksel/tasksel_2.74.1_all.deb Changes: tasksel (2.74.1) unstable; urgency=low . [ Frans Pop ] * Include task overrides file in uploads for byhand processing. Override entries for your package: tasksel-data_2.74.1_all.deb - important admin tasksel_2.74.1.dsc - source admin tasksel_2.74.1_all.deb - important admin Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFC] Some love for partman-md
Hi! After loosing 2 hours yesterday fighting against the RAIDvsCrypto issue [1], I decided that I should not let this happen to anyone else. Attached you will find an attempt to do so. The changeset is only broke down in two patches: * The first is a bit invasive (partman-md, partman-base, mdcfg) and improve globally the way MD devices are initialized and from my tests fix 10 bugs at ounce (counting merged ones). * The second is in partman-partitioning and prevent deletion and resizing for MD, LVM and crypto devices as they do not work correctly for any of these devices. I have done quite some testing inside partman and I think they should be right. Unfortunately, my offline mirror was broken and I was not able to do any full installations. As I'll be very happy to have such fixes in Lenny, I would very much welcome reviews and tests. [1] http://wiki.debian.org/DebianInstaller/RAIDvsCrypto Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- commit e5f830e53c38b4d214326c8a33db556ac3ede504 Author: Jérémy Bobbio [EMAIL PROTECTED] Date: Thu May 29 16:12:16 2008 + Clean up the initialization of MD devices The initialization of MD devices in partman previously diverged from what others partman components are doing, resulting in quite few bugs and really bad interactions with crypto setup. * Scanning for existing MD devices The loading of kernel modules and the initial scan for MD devices has been factor out in the md-init script, shipped in both mdcfg and mdcfg-utils packages. This script is called by both the init.d/md-devices in partman-md and by mdcfg itself. init.d/md-devices is now called before init.d/parted to have existing RAID partitions listed on the first partitioner run. Existing MD devices will now be activated at the begining of the partionner. (Closes: #391474) * Keep configurations of RAID partitions accross partman restarts MD devices were previously skipped in init.d/parted, resulting in the loss of the previous configuration. We now only skip deactivated RAID devices, in a similar way than sataraid and multipath devices are skipped. Most of the job of init.d/md and init.d/md-devices have been cleaned up and merged into init.d/md to cope with the previous change. The initialization scheme is now closer to what is done for LVM. (Closes: #391479, #391483, #393728, #398668) diff --git a/packages/mdcfg/debian/changelog b/packages/mdcfg/debian/changelog index 2543ba2..0df294d 100644 --- a/packages/mdcfg/debian/changelog +++ b/packages/mdcfg/debian/changelog @@ -1,3 +1,12 @@ +mdcfg (1.27) UNRELEASED; urgency=low + + [ Jérémy Bobbio ] + * Add an md-init script to mdcfg-utils, responsible for loading modules and +doing the initial scan for MD devices. This script is run by both mdcfg +and partman-md. + + -- Jérémy Bobbio [EMAIL PROTECTED] Thu, 29 May 2008 17:46:31 + + mdcfg (1.26) unstable; urgency=low [ Updated translations ] diff --git a/packages/mdcfg/debian/dirs b/packages/mdcfg/debian/dirs index 452a963..1e73c8b 100644 --- a/packages/mdcfg/debian/dirs +++ b/packages/mdcfg/debian/dirs @@ -1 +1,2 @@ +bin var/lib/partconf/block.d diff --git a/packages/mdcfg/debian/rules b/packages/mdcfg/debian/rules index 0712257..c57a981 100755 --- a/packages/mdcfg/debian/rules +++ b/packages/mdcfg/debian/rules @@ -27,6 +27,8 @@ install: build dh_installdirs install -m755 mdcfg.sh debian/mdcfg.postinst install -m755 mdcfg.sh debian/mdcfg-utils/bin/mdcfg + install -m755 md-init.sh debian/mdcfg-utils/bin/md-init + install -m755 md-init.sh debian/mdcfg/bin/md-init install -m755 partconf-hook.sh debian/mdcfg/var/lib/partconf/block.d/mdcfg.sh install -m755 finish-install debian/mdcfg-utils/usr/lib/finish-install.d/65mdcfg diff --git a/packages/mdcfg/md-init.sh b/packages/mdcfg/md-init.sh new file mode 100755 index 000..53645f8 --- /dev/null +++ b/packages/mdcfg/md-init.sh @@ -0,0 +1,24 @@ +#!/bin/sh + +if [ -e /proc/mdstat ]; then + exit 0 +fi + +# Try to load the necesarry modules. +# Supported schemes: RAID 0, RAID 1, RAID 5 +depmod -a /dev/null 21 +modprobe md /dev/null 21 || modprobe md-mod /dev/null 21 +modprobe raid0 /dev/null 21 +modprobe raid1 /dev/null 21 +# kernels =2.6.18 have raid456 +modprobe raid456 /dev/null 21 || modprobe raid5 /dev/null 21 + +# Try to detect MD devices, and start them +# mdadm will fail if /dev/md does not already exist +mkdir -p /dev/md + +log-output -t md-init --pass-stdout \ + mdadm --examine --scan --config=partitions /tmp/mdadm.conf + +log-output -t md-init \ + mdadm --assemble --scan --run --config=/tmp/mdadm.conf --auto=yes diff --git a/packages/mdcfg/mdcfg.sh
Processed: Preseeding of software RAID setup available since 2006
Processing commands for [EMAIL PROTECTED]: reassign 305543 partman-auto-raid 1 Bug#305543: need preseed support Bug reassigned from package `partman-md' to `partman-auto-raid'. retitle 305543 d-i should support preseeding of software RAID setup Bug#305543: need preseed support Changed Bug title to `d-i should support preseeding of software RAID setup' from `need preseed support'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 391483 to mdcfg-utils
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.20~bpo40+1 reassign 391483 mdcfg-utils Bug#391483: partman-md: Deleting md devices doesn't work. Bug reassigned from package `partman-md' to `mdcfg-utils'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305543: marked as done (d-i should support preseeding of software RAID setup)
Your message dated Thu, 29 May 2008 23:51:54 +0200 with message-id [EMAIL PROTECTED] and subject line Preseeding of software RAID setup available since 2006 has caused the Debian Bug report #305543, regarding d-i should support preseeding of software RAID setup to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 305543: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=305543 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: debian-installer Hello, not an installation report, because they are working fine. But I need some pointers into the right direction, how to install debian on a software raid1 using a preseed file. We are installing Debian for our customer fully unattended. That works just great, I already sent you guys the installation report template a few months ago. So far I was unable to partition more than one harddrive in a preseed file.=20 I apologize if this is the wrong email address. If so, please direct it to someone who can help me out on this. The actual question would be, is there an existing hook for my problem? If so, is there some documentation how to use it? Because I couldn't find anything. We could also write a hook ourselfs, but we need some documentation here too. Thank you in advance Sascha -- Best Regards, Sascha Wintz, CTO SERVER4YOU (Inc.) 710 North Tucker Blvd Suite 610a St. Louis, MO 63101 e-mail: [EMAIL PROTECTED] phone : +1-866-DIAL-S4Y fax : +1-314-754-3280 -- Best Regards, Sascha Wintz, CTO SERVER4YOU (Inc.) 710 North Tucker Blvd Suite 610a St. Louis, MO 63101 e-mail: [EMAIL PROTECTED] phone : +1-866-DIAL-S4Y fax : +1-314-754-3280 signature.asc Description: This is a digitally signed message part ---End Message--- ---BeginMessage--- reassign 305543 partman-auto-raid 1 retitle 305543 d-i should support preseeding of software RAID setup thanks Hi! Preseeding software RAID setup is possible since the introduction of the partman-auto-raid package and is available in the current stable release. It is documented in the appendix B of the installation manual. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature ---End Message---
Bug#251523: marked as done (Please add a stronger message about RAID creation.)
Your message dated Fri, 30 May 2008 00:14:41 +0200 with message-id [EMAIL PROTECTED] and subject line Re: Please add a stronger message about RAID creation has caused the Debian Bug report #251523, regarding Please add a stronger message about RAID creation. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 251523: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251523 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: installation-reports Severity: minor While testing RAID creation I realized that if you create the RAID volume before finishing the partition table, then the partition table is broken, because the kernel cannot acknowledge the new partition. Actually, I realized that this was somewhat explained in the pre-RAID screen, but not strongly enough. I didn't get the message until I had already broken the partition table. So, what I'm suggesting is to make the message a bit stronger like: DO NOT CREATE ANY RAID VOLUMES UNTIL YOU'VE **FINISHED** WORKING ON THE PARTITION TABLE. :). I know you don't like to change template for translation reasons, but please keep this in mind. The present message is not strong enough. -- Love, Marga. ---End Message--- ---BeginMessage--- Hi! Of course, in the latest versions of Partman you are required to commit all changes before you can go on to raid or lvm setup so this point may be moot. If so, please check that all paths are covered and close this bug? I think the current behaviour of partman is fine, and as we had no further comments on this bug for a while, I am closing it. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature ---End Message---
[D-I Manual] Build log for en (29 May 2008)
A build of the Debian Installer Manual was triggered by an update to SVN.
There were no errors during the build process.
The new version of the manual has been uploaded successfully.
A log of the build is available at:
- http://d-i.alioth.debian.org/manual/logs/en.log
===
It is possible to use RSS to track changes to the manual.
For more information, see:
http://d-i.alioth.debian.org/manual/translators.html
===
Note: PDF output is not yet supported for some languages; help
with this would be appreciated.
===
If you have any questions about the build or this message, feel
free to contact me at faw AT funlabs DOT org.
===
Updated files ('svn up')
Uen/bookinfo.xml
Uen/using-d-i/modules/localechooser.xml
Updated to revision 53529.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatic builds re-enabled
Geert Stappers wrote: The daily builds for d-i sparc are manually uploaded. Automatic upload doesn't work yet for my account. On server gluck has ~stappers/.ssh/authorized_keys the public ssh-key from the computer where the d-i is done. That key upload load was done with 'ssh-copy-id'. With another server got I it working. Does more, besides authorized_keys update, needed be done on gluck? authorized_keys is permanantly disabled on debian machines. Use LDAP, or talk to DSA about getting a key added to a single machine. -- see shy jo signature.asc Description: Digital signature
moving tasksel to git
I'd really like to move tasksel to git. It frequently needs to be branched around release time; maintaining those branches will be much less painful with git. Doing it with svn seems sufficiently painful now that I'm taking ugly shortcuts. Now that Frans has implemented awesome autobyhand processing of the overrides, there is no need for a canonical svn repo that override info can be pulled from. Finally, derivatives and CDDs have many good reasons to want to maintain their own tasksel branches. If moving it to git will cause any significant trouble for translators and task maintainers, please let me know. -- see shy jo signature.asc Description: Digital signature
Processing of tasksel_2.74.2_i386.changes
tasksel_2.74.2_i386.changes uploaded successfully to localhost along with the files: tasksel_2.74.2.dsc tasksel_2.74.2.tar.gz tasksel_2.74.2_all.deb tasksel-data_2.74.2_all.deb task-overrides_2.74.2_all.tar.gz Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tasksel_2.74.2_i386.changes ACCEPTED
Accepted: task-overrides_2.74.2_all.tar.gz byhand tasksel-data_2.74.2_all.deb to pool/main/t/tasksel/tasksel-data_2.74.2_all.deb tasksel_2.74.2.dsc to pool/main/t/tasksel/tasksel_2.74.2.dsc tasksel_2.74.2.tar.gz to pool/main/t/tasksel/tasksel_2.74.2.tar.gz tasksel_2.74.2_all.deb to pool/main/t/tasksel/tasksel_2.74.2_all.deb Changes: tasksel (2.74.2) unstable; urgency=medium . * Fix two perl warnings. Closes: #483469 * Memoize expensive test in enhances calculation. * Medium urgency for b2. Override entries for your package: tasksel-data_2.74.2_all.deb - important admin tasksel_2.74.2.dsc - source admin tasksel_2.74.2_all.deb - important admin Announcing to [EMAIL PROTECTED] Closing bugs: 483469 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483469: marked as done (tasksel: errors during D-I installation)
Your message dated Fri, 30 May 2008 04:02:06 + with message-id [EMAIL PROTECTED] and subject line Bug#483469: fixed in tasksel 2.74.2 has caused the Debian Bug report #483469, regarding tasksel: errors during D-I installation to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 483469: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483469 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: tasksel Version: 2.74 During an installation today I noticed the following errors in the syslog: in-target: my variable @deps masks earlier declaration in same scope at /usr/bin/tasksel line 535. in-target: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. in-target: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. in-target: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. [... loads of repeats ...] in-target: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. in-target: Reading package lists... Note there are two errors: the first in 535 and a lot of repeats for 529. The errors happen at the beginning of tasksel, in the syslog they are shown right after popcon has been purged. The first probably happens before the task dialog, the rest may happen after (6 seconds between first and second). As I already had perl installed at that point, this looks unrelated to the perl-base issue. IMO it would be nice to have this fixed in time for Beta2. Cheers, FJP signature.asc Description: This is a digitally signed message part. ---End Message--- ---BeginMessage--- Source: tasksel Source-Version: 2.74.2 We believe that the bug you reported is fixed in the latest version of tasksel, which is due to be installed in the Debian FTP archive: task-overrides_2.74.2_all.tar.gz byhand tasksel-data_2.74.2_all.deb to pool/main/t/tasksel/tasksel-data_2.74.2_all.deb tasksel_2.74.2.dsc to pool/main/t/tasksel/tasksel_2.74.2.dsc tasksel_2.74.2.tar.gz to pool/main/t/tasksel/tasksel_2.74.2.tar.gz tasksel_2.74.2_all.deb to pool/main/t/tasksel/tasksel_2.74.2_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Joey Hess [EMAIL PROTECTED] (supplier of updated tasksel package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 May 2008 23:46:39 -0400 Source: tasksel Binary: tasksel tasksel-data Architecture: source all Version: 2.74.2 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Joey Hess [EMAIL PROTECTED] Description: tasksel- Tool for selecting tasks for installation on Debian systems tasksel-data - Official tasks used for installation of Debian systems Closes: 483469 Changes: tasksel (2.74.2) unstable; urgency=medium . * Fix two perl warnings. Closes: #483469 * Memoize expensive test in enhances calculation. * Medium urgency for b2. Checksums-Sha1: 4b49ddd6bec1e6ef3fdf5d6fe0eaf5b721fe0497 855 tasksel_2.74.2.dsc 908d276da9b6469a2414df6806bba93ece76aadc 505571 tasksel_2.74.2.tar.gz 06dec6fc831558e7333b51f09bf74dbc341c8272 82000 tasksel_2.74.2_all.deb ce428dc0a59858438ec93c2c84a8b0c5ef8c0f76 382758 tasksel-data_2.74.2_all.deb 28c64c1e889037d812788b98cce9e1ecb8a594dd 4546 task-overrides_2.74.2_all.tar.gz Checksums-Sha256: 56482368a42d1a5218865ff8873c870eb219c933c4b6b68fc6cbb10f2ae6746d 855 tasksel_2.74.2.dsc 19ef94718a1043b7796eba32a7172a8358bea6ab475cab2413069e3ac54699ba 505571 tasksel_2.74.2.tar.gz 88accaccd3060763189d1c438395c22d3d713d905b10deb048cff61da7d942d4 82000 tasksel_2.74.2_all.deb 34930281a0f8e389c0f14fc58a9cf05b9a5bf26e066f65875ff1b8ae747ac065 382758 tasksel-data_2.74.2_all.deb 787f10c6fee9ac09c4c3394f1118dea606af02358e318325889b2ce24c6a4bf1 4546 task-overrides_2.74.2_all.tar.gz Files: a16ac47d3223f3f93f5d0aae538de8cd 855 admin important tasksel_2.74.2.dsc c2818ad9e9399bef84159a7cb9da9902 505571 admin important tasksel_2.74.2.tar.gz e5e334495e5718f6b0a4eaaf313d346e 82000 admin important tasksel_2.74.2_all.deb 3eee42f279550f1a8d17335f9b101aef 382758 admin important tasksel-data_2.74.2_all.deb c1f465975e97a6e99411a441f080155d 4546 byhand -
Bug#483210: marked as done (tasksel error)
Your message dated Fri, 30 May 2008 04:02:06 + with message-id [EMAIL PROTECTED] and subject line Bug#483469: fixed in tasksel 2.74.2 has caused the Debian Bug report #483469, regarding tasksel error to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 483469: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483469 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: tasksel Version 2.74 Using tasksel on already installed system (Debian testing AMD64, installed 24.5.2008. using daily built buissines card iso, installed desktop system, installation went OK) gives following error: my variable @deps masks earlier declaration in same scope at /usr/bin/tasksel line 535. then tasksel apparently starts, but leaving it or selecting manual package selection, tasksel exits with: Use of uninitialized value in string eq at /usr/bin/tasksel line 529. Use of uninitialized value in string eq at /usr/bin/tasksel line 529. ... and so on 114 times. To make it clear there were no problems during installation. Both tasksel and tasksel-data were upgraded on 26.5.2008. from 2.73 to 2.74, so this version was not used during installation. Best regards, Predrag Gavrilovic ---End Message--- ---BeginMessage--- Source: tasksel Source-Version: 2.74.2 We believe that the bug you reported is fixed in the latest version of tasksel, which is due to be installed in the Debian FTP archive: task-overrides_2.74.2_all.tar.gz byhand tasksel-data_2.74.2_all.deb to pool/main/t/tasksel/tasksel-data_2.74.2_all.deb tasksel_2.74.2.dsc to pool/main/t/tasksel/tasksel_2.74.2.dsc tasksel_2.74.2.tar.gz to pool/main/t/tasksel/tasksel_2.74.2.tar.gz tasksel_2.74.2_all.deb to pool/main/t/tasksel/tasksel_2.74.2_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Joey Hess [EMAIL PROTECTED] (supplier of updated tasksel package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 May 2008 23:46:39 -0400 Source: tasksel Binary: tasksel tasksel-data Architecture: source all Version: 2.74.2 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Joey Hess [EMAIL PROTECTED] Description: tasksel- Tool for selecting tasks for installation on Debian systems tasksel-data - Official tasks used for installation of Debian systems Closes: 483469 Changes: tasksel (2.74.2) unstable; urgency=medium . * Fix two perl warnings. Closes: #483469 * Memoize expensive test in enhances calculation. * Medium urgency for b2. Checksums-Sha1: 4b49ddd6bec1e6ef3fdf5d6fe0eaf5b721fe0497 855 tasksel_2.74.2.dsc 908d276da9b6469a2414df6806bba93ece76aadc 505571 tasksel_2.74.2.tar.gz 06dec6fc831558e7333b51f09bf74dbc341c8272 82000 tasksel_2.74.2_all.deb ce428dc0a59858438ec93c2c84a8b0c5ef8c0f76 382758 tasksel-data_2.74.2_all.deb 28c64c1e889037d812788b98cce9e1ecb8a594dd 4546 task-overrides_2.74.2_all.tar.gz Checksums-Sha256: 56482368a42d1a5218865ff8873c870eb219c933c4b6b68fc6cbb10f2ae6746d 855 tasksel_2.74.2.dsc 19ef94718a1043b7796eba32a7172a8358bea6ab475cab2413069e3ac54699ba 505571 tasksel_2.74.2.tar.gz 88accaccd3060763189d1c438395c22d3d713d905b10deb048cff61da7d942d4 82000 tasksel_2.74.2_all.deb 34930281a0f8e389c0f14fc58a9cf05b9a5bf26e066f65875ff1b8ae747ac065 382758 tasksel-data_2.74.2_all.deb 787f10c6fee9ac09c4c3394f1118dea606af02358e318325889b2ce24c6a4bf1 4546 task-overrides_2.74.2_all.tar.gz Files: a16ac47d3223f3f93f5d0aae538de8cd 855 admin important tasksel_2.74.2.dsc c2818ad9e9399bef84159a7cb9da9902 505571 admin important tasksel_2.74.2.tar.gz e5e334495e5718f6b0a4eaaf313d346e 82000 admin important tasksel_2.74.2_all.deb 3eee42f279550f1a8d17335f9b101aef 382758 admin important tasksel-data_2.74.2_all.deb c1f465975e97a6e99411a441f080155d 4546 byhand - task-overrides_2.74.2_all.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIP3q82tp5zXiKP0wRAn1oAKDQsauSnkMKU0RD5QzE5HL3SFSDXACeJn7R PFOlblbnTxx6tUE/V3RxB2A= =rxM8 -END PGP SIGNATURE- ---End Message---
