Re: planning directfb 1.4 transition
On Saturday 22 August 2009, Frans Pop wrote: > I've verified that both issues are not present in a daily built image > using current libraries from unstable. I'll file a bug against the > experimental version of directfb later. Filed as: http://bugs.debian.org/543590 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processing of partman-auto-raid_15_i386.changes
partman-auto-raid_15_i386.changes uploaded successfully to localhost along with the files: partman-auto-raid_15.dsc partman-auto-raid_15.tar.gz partman-auto-raid_15_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
partman-auto-raid_15_i386.changes REJECTED
Rejected: Unknown distribution `karmic'. === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processing of partman-auto-raid_15_i386.changes
partman-auto-raid_15_i386.changes uploaded successfully to localhost along with the files: partman-auto-raid_15.dsc partman-auto-raid_15.tar.gz partman-auto-raid_15_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
partman-auto-raid_15_i386.changes ACCEPTED
Accepted: partman-auto-raid_15.dsc to pool/main/p/partman-auto-raid/partman-auto-raid_15.dsc partman-auto-raid_15.tar.gz to pool/main/p/partman-auto-raid/partman-auto-raid_15.tar.gz partman-auto-raid_15_all.udeb to pool/main/p/partman-auto-raid/partman-auto-raid_15_all.udeb Override entries for your package: partman-auto-raid_15.dsc - source debian-installer partman-auto-raid_15_all.udeb - standard debian-installer Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 484421 537928 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#484421: marked as done (partman-auto-raid: Should support preseeding of LVM-over-RAID setups)
Your message dated Wed, 26 Aug 2009 12:17:06 + with message-id and subject line Bug#484421: fixed in partman-auto-raid 15 has caused the Debian Bug report #484421, regarding partman-auto-raid: Should support preseeding of LVM-over-RAID setups 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 ow...@bugs.debian.org immediately.) -- 484421: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484421 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: partman-auto-raid Version: 11 Severity: wishlist Tags: patch Attached is a patch adding support for preseeding LVM-over-RAID setups. This patch depends and has been tested with the recent improvements proposed over partman-md initialization scheme. [1] [1] http://lists.debian.org/debian-boot/2008/06/msg00093.html Cheers, -- Jérémy Bobbio.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature --- End Message --- --- Begin Message --- Source: partman-auto-raid Source-Version: 15 We believe that the bug you reported is fixed in the latest version of partman-auto-raid, which is due to be installed in the Debian FTP archive: partman-auto-raid_15.dsc to pool/main/p/partman-auto-raid/partman-auto-raid_15.dsc partman-auto-raid_15.tar.gz to pool/main/p/partman-auto-raid/partman-auto-raid_15.tar.gz partman-auto-raid_15_all.udeb to pool/main/p/partman-auto-raid/partman-auto-raid_15_all.udeb 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 484...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Colin Watson (supplier of updated partman-auto-raid 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 ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 Aug 2009 12:10:53 +0100 Source: partman-auto-raid Binary: partman-auto-raid Architecture: source all Version: 15 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Colin Watson Description: partman-auto-raid - Allow preseeded RAID installs (udeb) Closes: 484421 537928 Changes: partman-auto-raid (15) unstable; urgency=low . [ Max Vozeler ] * Count NAMED_SPARES after splitting on #, fixes use of more than one spare. Patch by Michal Sabala. (closes: #537928) . [ Frans Pop ] * Remove myself as uploader. . [ Colin Watson ] * Add the ability to preseed LVM over RAID. Based almost entirely on work done by Jérémy Bobbio, with corrections by Philippe Le Brouster and myself (closes: #484421). . [ Updated translations ] * Asturian (ast.po) by Marcos Antonio Alvarez Costales * Bengali (bn.po) by Md. Rezwan Shahid * Czech (cs.po) by Miroslav Kure * Esperanto (eo.po) by Felipe Castro * Estonian (et.po) by Mattias Põldaru * Basque (eu.po) by Piarres Beobide * Galician (gl.po) by marce villarino * Hindi (hi.po) * Italian (it.po) by Milo Casagrande * Kazakh (kk.po) by Dauren Sarsenov * Malayalam (ml.po) by Praveen Arimbrathodiyil * Marathi (mr.po) by Sampada * Tagalog (tl.po) by Eric Pareja Checksums-Sha1: 97f6b60fe420b1085f759f5df70dada3d2a17634 930 partman-auto-raid_15.dsc 24f88847edaca24c241e709eb3a6789734c03c0e 36262 partman-auto-raid_15.tar.gz 93b4460ef2c793754008b53d66527ff7bffe872a 17438 partman-auto-raid_15_all.udeb Checksums-Sha256: c2b8eae2231c3f25fc322f96a3e6fd7988662e7533c8cd5c7bb9a51c293a2a6d 930 partman-auto-raid_15.dsc 389055d1885ef6e427f3f692e3f467040405525f9fb60109936a4623bb467875 36262 partman-auto-raid_15.tar.gz 3ab7b8e93552ad800ed18ba2d9b82993ae3cd3de106cbed9b90529f2186b4238 17438 partman-auto-raid_15_all.udeb Files: a820c4b5e8f5c95e272e8186dafe02e3 930 debian-installer standard partman-auto-raid_15.dsc e390025126c1e6e08f167ef811a5f901 36262 debian-installer standard partman-auto-raid_15.tar.gz 6d363ead6c09bbb248f6aa1d2c1c0ccd 17438 debian-installer standard partman-auto-raid_15_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Colin Watson -- Debian developer iD8DBQFKlSSu9t0zAhD6TNERAsPcAJ9ziYy/pRYrH/uITUSGUDAghugaewCfa/SX h3p2bVdi/b4fO0oJdZ2gGKw= =Im8E -END PGP SIGNATURE
Bug#537928: marked as done ($NAMED_SPARES is miscounted (breaks auto-raid when using more than 1 spare))
Your message dated Wed, 26 Aug 2009 12:17:06 + with message-id and subject line Bug#537928: fixed in partman-auto-raid 15 has caused the Debian Bug report #537928, regarding $NAMED_SPARES is miscounted (breaks auto-raid when using more than 1 spare) 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 ow...@bugs.debian.org immediately.) -- 537928: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537928 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: partman-auto-raid Version: 14 I'm preseed installing using two spares. The auto-raidcfg script is not properly counting spares resulting in mdadm error (fatal). tty0: (in red) An unexpected error occurred while setting up a preseeded RAID configuration. Check /var/log/syslog or see virtual console 4 for the details. syslog: partman-auto-raid: Selected spare count: 1 partman-auto-raid: Spare devices count: 2 partman-auto-raid: mdadm: You have listed more devices (5) than are in the array(4)! partman-auto-raid: Error creating array /dev/md0 my preseed.cfg partman-auto-raid rule looks as follows: d-i partman-auto-raid/recipe string \ 1 2 2 ext3 /\ /dev/sda1#/dev/sdb1 \ /dev/sdc1#/dev/sdd1 \ . Basically spares are counted (with wc) before they are split on '#'. Below is a patch (tested) to fix this behavior: --- auto-raidcfg2008-08-09 14:26:07.0 -0500 +++ auto-raidcfg.FIXED 2009-07-20 15:08:29.474764832 -0500 @@ -24,12 +24,14 @@ DEVICES="$6" SPARE_DEVICES="$7" - NAMED_SPARES=$(echo $SPARE_DEVICES | wc -w) - RAID_DEVICES=$(echo $DEVICES | sed -e "s/#/ /g") SPARE_DEVICES=$(echo $SPARE_DEVICES | sed -e "s/#/ /g") + # fixed - needs to run after splitting SPARE_DEVICES + NAMED_SPARES=$(echo $SPARE_DEVICES | wc -w) + + if [ "$RAID_TYPE" != "0" ]; then # Count them SELECTED=$(echo $RAID_DEVICES | wc -w) To work around this problem without rebuilding installer packages, I'm running following script from inittab to replace auto-raidcfg (I placed it into initrd along with preseed.cfg and /bin/auto-raidcfg.fixed): /bin/fix-auto-raidcfg: #!/bin/sh /bin/echo -n "waiting for /bin/auto-raidcfg to appear: "; while [ ! -e /bin/auto-raidcfg ]; do /bin/sleep 1; /bin/echo -n "."; done; /bin/echo ""; /bin/mv /bin/auto-raidcfg.fixed /bin/auto-raidcfg /bin/echo "*** replaced /bin/auto-raidcfg with a fixed version" /bin/echo -n "sleeping: " while true; do /bin/echo -n '.'; sleep 1; done; my initrd's /etc/inittab looks as follows: # /etc/inittab # busybox init configuration for debian-installer # main rc script ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program ::respawn:/sbin/reopen-console /sbin/debian-installer # convenience shells tty2::askfirst:-/bin/sh tty3::askfirst:-/bin/sh # logging tty4::respawn:/usr/bin/tail -f /var/log/syslog # fix auto-raidcfg script tty5::respawn:/bin/fix-auto-raidcfg # Stuff to do before rebooting ::ctrlaltdel:/sbin/shutdown > /dev/null 2>&1 # re-exec init on receipt of SIGHUP/SIGUSR1 ::restart:/sbin/init Please let me know if you accept my patch. Thanks, Michal ps. Since I'm already modifying auto-raidcfg, I'm using a non-default chunk size (not shown in above code). Ability to specify chunk size in partman-auto-raid/recipe would be nice... optimal chunk size increased sequential IO on my systems by 30%. -- Michal Sabala | "There are 10 types of Research Programmer / System Administrator | people in the world. Those LAC/NCDM: University of Illinois at Chicago | who understand binary and tel. (312)-996-9546 | those who don't." --- End Message --- --- Begin Message --- Source: partman-auto-raid Source-Version: 15 We believe that the bug you reported is fixed in the latest version of partman-auto-raid, which is due to be installed in the Debian FTP archive: partman-auto-raid_15.dsc to pool/main/p/partman-auto-raid/partman-auto-raid_15.dsc partman-auto-raid_15.tar.gz to pool/main/p/partman-auto-raid/partman-auto-raid_15.tar.gz partman-auto-raid_15_all.udeb to pool/main/p/partman-auto-raid/partman-auto-raid_15_all.udeb 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 537...@bugs.debian.org, and the maintainer will reopen the bu
Bug#543256: Make installing recommends optional
On Mon, Aug 24, 2009 at 12:25:43AM +0200, Frans Pop wrote: > - if we go this way it will mean that we'll have to continue to support > the few "required Recommends" that have been identified in the past; > one example is busybox for initramfs-tools, another that IMO is worth > keeping is libgl1-mesa-dri for X.Org; we'll have to review the changes > made by Joey in tasksel that dropped some packages from tasks, but I > doubt many would need to be added back; Shouldn't they actually be Depends if they are really required for a working system? I don't see why you want to special case some packages. If ppl don't want recommends they should really not get any recommends and decide for themselves if they do want to install these additional usefull packages. IMO you can't have both, no recommends and everything that is generally usefull to have but not a dependency. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dh-di_1_i386.changes ACCEPTED
Accepted: dh-di_1.dsc to pool/main/d/dh-di/dh-di_1.dsc dh-di_1.tar.gz to pool/main/d/dh-di/dh-di_1.tar.gz dh-di_1_all.deb to pool/main/d/dh-di/dh-di_1_all.deb Override entries for your package: dh-di_1.dsc - optional devel dh-di_1_all.deb - optional devel Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541831: installation-reports: Sunfire T2000 success (one minor issue)
On Monday 17 August 2009, Stephen Gran wrote: > > It sounds like the "rsc console" is something different, which could > > explain what you saw. Maybe we need special handling for this case. > > The rsc is much like an iLo or alom. It's just another management > interface that offers a 'console' interface to manage the OS. I did > the install using this interface, obtained by running 'break -c'. OK. So the problem is that there is no direct link between the rsc and the (serial) console to be used for the installed system. > > Questions: > > - What were the contents of /etc/inittab after the installation? Were > > the entries for tty[1-6] commented out or not? > [contents of /etc/inittab] So regular consoles were enabled. That's expected. I mainly asked to confirm. > #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 > #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100 > > I had to uncomment T0 to get a console with 'console -f' from the rsc. So the rsc is somehow linked to ttyS0. > ~ # console-type > serial This is at least one clue: D-I *does* detect it's a serial connection. > ~ # readlink /proc/self/fd/0 > /dev/console That's a logical value if it isn't /dev/ttyS0. > > - If the first is not "serial" and/or the last is not /dev/ttyS0, > > then how could the need to set up serial console be detected? > > That's a very good question. Interestingly, I see this in dmesg: > [ 32.032662] console handover: boot [earlyprom0] -> real [tty0] > > So at least at that point, the kernel thinks it _is_ tty0. That's fairly normal. In the past we've also seen on sparc: [0.00] console [earlyprom0] enabled [ 53.918290] Console: colour dummy device 80x25 [ 53.971361] console handover: boot [earlyprom0] -> real [tty0] [ 59.676537] Console: switching to mono PROM 80x34 [ 64.238061] Console: ttyS0 (SAB82532) [ 64.308951] console [ttyS0] enabled Is there anything after that first message in your case? The full boot log would be useful to have for this issue. > Unfortunately, I don't know enough about whether there is a difference > between what you attach to with 'console -f' in the rsc and what you > attach to with 'break -c'. I naively think that they should be the > same thing, but it is possible that they are not. /me is completely lost here. > > - Does the installer work correctly and does a listener for serial > > console get set up for the installed system if you boot D-I with > > console=ttyS0? > > No: > steal-ctty: No such file or directory > steal-ctty: No such file or directory > steal-ctty: No such file or directory > Over and over. That might be a bug in itself that's worth fixing. The source for steal-ctty is at [1]. It is called by [2], which does the actual detection. The loop is probably because init keeps failing and resets. Can you find out what /var/run/console-device contains at that point? I'd expect /dev/ttyS0, but it would be good to know for sure. You can probably find out by booting with BOOT_DEBUG=3 and then in /sbin/reopen-console add a 'set -x' plus near the end a 'sleep 30' so you have time to read the output. > So, this doesn't look like a problem the installer can > fix. It's just odd that the OS doesn't see the serial console on the > same device as the installer does: > > sg...@zee:~$ readlink /proc/self/fd/0 > /dev/ttyS0 > > Well, I'm a bit mystified about how this could be fixed, so I don't > mind if you want to close it as unresolvable or punt it over to the > sparc porters to see if they can shed any light on it. We have solved similar problems in that past. The only thing that's needed is *some* way of identifying this case. Possibly there's something in /proc from openprom? We could then do something similar as was done for powerpc (see the code after "# Set up virtualized..." in [3]). The final option would be to add a dialog that's displayed if we are uncertain and that just asks what to use. Might be useful for other cases too. Main question is if you're willing and able to do a bit more digging :-) Cheers, FJP [1]http://svn.debian.org/wsvn/d-i/trunk/packages/rootskel/src/sbin/steal-ctty.c [2]http://svn.debian.org/wsvn/d-i/trunk/packages/rootskel/src/sbin/reopen-console-linux [3]http://svn.debian.org/wsvn/d-i/trunk/packages/finish-install/finish-install.d/90console -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ceza ödemeyin
iyi günler, Eğer aracınızın muayenesi yoksa ve trafik kontrolune yakalanırsanız; 1 Araç ruhsatı sizin adına değilse otomobiliniz direk parka çekilir 2 Ruhsat sahibi sizseniz önce 62 tl ceza öderseniz sonra 15 günlük muayene müsade belgesi alarak muayenenizi aylık % 5 ceza ile yaptırısınız. Özet olarak siz uğraşmayın gelin bizhalledelim. Ankara'nın muayene merkezi bizhalledelim.com adresten alıp adrese teslim hizmet. ÖNEMLİ NOT : Eğer araç veya araçlarınızın birikmiş vergi borcu varsa ,lpg montajı yaptıracaksanız hatta sadece muayene işleminiz bile varsa hepsini vade farkını ödeyerek kredi kartınıza 24 aya kadar taksitlendirebilirsiniz. Saygılar Güven NOYAN 0 312 442 19 20 0 554 385 1900 i...@bizhalledelim.com www.bizhalledelim.com www.viraoto.com.tr
Re: Spellchecking priorities [Was: Re: Override changes standard -> optional]
Christian Perrier wrote: > Task: standard > Section: user > Description: Standard system utilities > This task sets up a basic user environment, providing a reasonably > small selection of services and tools usable on the command line. > Packages: standard > Test-new-install: mark skip > > I assume that adding: > > Packages-list: > iamerican That won't work becase Package-list is only looked at if the task uses Packages: task-fields -- see shy jo signature.asc Description: Digital signature
Bug#543256: Make installing recommends optional
On Wednesday 26 August 2009, Gaudenz Steinlin wrote: > Shouldn't they actually be Depends if they are really required for a > working system? I don't see why you want to special case some packages. You'd have to take that up with the maintainers of the packages. But for the two cases I mentioned there's already been *loads* of discussion. For initramfs-tools for example busybox is only _not_ wanted in a very limited number of use-cases, but to allow for those use-cases it cannot be a Depends. Omitting it in D-I installs would mean users would have severely limited options to debug boot problems, which is IMO irresponsible _even_ if they indirectly chose it themselves because that consequence of the "no Recommends" choice is almost impossible to predict, and also impossible to correct just when you'd need to. > If ppl don't want recommends they should really not get any recommends > and decide for themselves if they do want to install these additional > usefull packages. In general I agree completely, but there are always exceptions and an distro installer is IMO the one place where it is justified to have exceptions. There are other places where we do somewhat similar things in situations where following the general rules by the letter would simply leave users with completely unexpected/undesired results. > IMO you can't have both, no recommends and everything that is generally > usefull to have but not a dependency. Again, I agree in general, but I don't think e.g. not installing busybox is a realistic option. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543256: Make installing recommends optional
On Wednesday 26 August 2009, Frans Pop wrote: > On Wednesday 26 August 2009, Gaudenz Steinlin wrote: > > Shouldn't they actually be Depends if they are really required for a > > working system? I don't see why you want to special case some > > packages. > > You'd have to take that up with the maintainers of the packages. But > for the two cases I mentioned there's already been *loads* of > discussion. I've been wondering whether we don't need a new field to express such relationships. Something like "Soft-Depends:". That would be treated as depends, but can be unselected manually or uninstalled later if a user really, really wants to. IMO Recommends does not fit that description as a lot of packages do fit the "should normally be installed together with" criterion, but where more critical users don't see any need to install it. The gap between Suggests and Depends is in practice proving to be just too big to be filled by a single field. It would also allow something like debian-cd to include it on CD images before Recommends. Main downside of course is that it is yet another control field, as if we don't have enough of those already. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543256: tasksel maintainer's perspective
(debian-cd added in CC with full quote of original mail) On Tuesday 25 August 2009, Joey Hess wrote: > A problem with providing some global way of turning off recommends by > default in d-i is that tasks are now being maintained with the implicit > and explicit assumption that recommends are installed by default. So, > if recommends are turned off, tasks can be broken in both subtle and > obvious ways. Without apparently any consideration for how this breaks CD images. As you well know, debian-cd currently does NOT have any functionality allowing it to include Recommends on a particular image, like the first CD. Even if it did have such functionality, it would in my expectation be completely unworkable as activating it would mean way too many packages would suddenly want to be included on CD1. Of course we already had that problem to some extend as non-key packages were not necessarily available, but this will greatly increase the issue as packages that were previously included because they were Depends, will now get moved back all the way down to the "inclusion based on popcon" level. I also worry what the change will mean for the total size of the various desktop installs. Is the 3GB check still enough? Somehow I doubt it. > Frans touched on this in his mail, but AFAIK the set of "required > recommends" is much larger than busybox and libgl1-mesa-dri[1]. See > tasksel's changelog for 2.79 for many more, and note that more will > have a tendancy to be added over time. Also note that the (er, my) > inability to keep track of such required recommends is why recommends > were turned on in tasksel in the first place. To be honest I don't feel most of those listed in 2.79 are anywhere close to the same priority as the two I mentioned. > Also, the gnome metapackage is being maintained with similar implicit > and explicit assumptions about recommends. And reversing that may not > be to the taste of the maintainers or users of the package. For > example, I'm about to file a bug requesting that network-manager-gnome > be demoted to a recommends. Losing network-manager-gnome from CD1 seems like a fairly major issue to me. > Knowing that recommends will be installed > by default gives the maintainer the ability to support such tweaks > while still being sure that users who install the package will get a > usable and standard gnome system. If the maintainer has to worry about > users who choose to disable all recommends, he will be forced to keep > network-manager a depends. Thus, supporting users who want to disable > all recommends tends to reduce the total configurability of Debian. IMO maintainers of desktop tasks do *not* have to worry about this. Such consequences are clearly for the user who chooses to install without Recommends enabled. If you chose that option, you definitely do not have the right to expect a "fully usable and standard system". But that does not mean the option is completely without merit. I also don't think this option will be used by people doing desktop installs using tasksel. They are much more likely to install a normal base system and selectively build their desktop on top of that. If they use a proper package manager for that, they will have plenty of opportunity to review which recommends they do and don't want. > IMHO the best we can do is to implement the option, but document it as > likely to install a broken system unless the user manually knows just > what missing bits to install. Which is *exactly* what I indicated in the draft template I proposed in my patch. I think that, based on the reactions in the tread, we should drop the template in my patch for base-installer. Instead I think we should have the option only preseedable and as a boot option. For the latter I suggest defining an alias instead, so you'll be able to boot with 'recommends=false'. > Or not implement the option, which seems equivilant from here. Not from here. > (BTW, did you notice the annoying samba questions when installing the > desktop task? It was an unncessary recommends in cups, which was quite > quickly fixed once brought to the package maintainer's attention.) I've seen other such BRs closed by various maintainers. In most cases with proper argumentation, even if I did not agree with it in all cases. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543256: Make installing recommends optional
On Wed, 26 Aug 2009 21:19:06 +0200, Frans Pop wrote: >I've been wondering whether we don't need a new field to express such >relationships. Something like "Soft-Depends:". That would be treated as >depends, but can be unselected manually or uninstalled later if a user >really, really wants to. If there are few enough packages needing an "Almost-Always-Depends:" field, could this be handled by a dummy package in the Depends: list? Something like "Depends: busybox-dummy | busybox" where busybox-dummy would not normally be available (and thus skipped) unless proper magic was invoked. Or do I misunderstand packaging and installation? --Don -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processing of linux-kernel-di-ia64-2.6_1.42lenny5_ia64.changes
linux-kernel-di-ia64-2.6_1.42lenny5_ia64.changes uploaded successfully to localhost along with the files: linux-kernel-di-ia64-2.6_1.42lenny5.dsc linux-kernel-di-ia64-2.6_1.42lenny5.tar.gz kernel-image-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb nic-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb nic-shared-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb serial-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ppp-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ide-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ide-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb cdrom-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb firewire-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb scsi-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb scsi-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb plip-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb loop-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ipv6-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb nls-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ext3-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb isofs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb jfs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ntfs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb reiserfs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb xfs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb fat-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ufs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb md-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb multipath-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb usb-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb usb-storage-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb fb-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb input-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb mouse-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb irda-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb parport-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb pcmcia-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb nic-usb-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb sata-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb crc-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb crypto-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb crypto-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb crypto-dm-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb efi-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ata-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb zlib-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb uinput-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb sn-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543256: Make installing recommends optional
On Wednesday 26 August 2009, Don Wright wrote: > If there are few enough packages needing an "Almost-Always-Depends:" > field, could this be handled by a dummy package in the Depends: list? > Something like "Depends: busybox-dummy | busybox" where busybox-dummy > would not normally be available (and thus skipped) unless proper magic > was invoked. Or do I misunderstand packaging and installation? --Don How would you ensure busybox-dummy is not available? If a user installs using a network mirror, then *all* packages are available. If you reverse the order you'd get what you want: busybox gets installed by default, but you'd be able to remove it by installing busybox-dummy instead. But then I'd not name it busybox-dummy, but just 'dummy' so that other packages could depend on it too for the same purpose. Or do you mean the user would have to create the busybox-dummy package himself? But then he could just as easily create an empty busybox replacement package (using 'equivs' for example). But having empty packages in the archive and creating what remains a bogus dependency construction is not exactly my idea of an elegant solution :-) Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#472704: (no subject)
subscribe -- James Richardson Debian GNU/Linux Consultant http://www.linkedin.com/in/jamesrichardsonconsulting signature.asc Description: Digital signature
Bug#472704: debootstrap: Could not reproduce exactly.
Package: debootstrap Severity: normal Hi, I seemed to be having the same issue, here is my info. I have been trying to bootstrap several openvz instances with debootstrap incantations similar to: $sudo debootstrap --variant minbase --include=aptitude,netbase,ifupdown,puppet,lsb-release sid /var/lib/vz/private/305 http://apt:3142/ftp.us.debian.org/debian I received the errors about base packages: W: Failure while configuring base packages. W: Failure while configuring base packages. W: Failure while configuring base packages. W: Failure while configuring base packages. W: Failure while configuring base packages. I thought maybe it does like sid, lets try lenny. Lenny was sucessful. Ok, lets try sid without the minbase and --includes. (e.g. $sudo debootstrap sid /var/lib/vz/private/305 http://apt:3142/ftp.us.debian.org/debian That was sucessfull. Perhaps the bug is fixed, not-reproduceable. I went back to the original incantation, added --verbose. The debootstrap log in /var/lib/vz/private/305/debootstrap had errors complaining the puppet was not configured, missing dependency of (host | bind9-host). I added bind9-host to list of includes and all is now working. I said all that to say that the bug may be fixed, I have no idea of what fixed it, the official way to document that it may be resolved. I also don't know exactly why the dependencies weren't picked up, even with --resolv-dep. The actual depency chain looks like puppet depends on factor, factor depends on (host | bind9-host). factor is pulled in automagically, bind9-host is not. Thanks. -- System Information: Debian Release: squeeze/sid APT prefers unstable-i386 APT policy: (500, 'unstable-i386'), (500, 'transitional-i386'), (500, 'testing-i386'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-i386'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-openvz-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages debootstrap depends on: ii binutils 2.19.51.20090723-1 The GNU assembler, linker and bina ii wget 1.11.4-4 retrieves files from the web Versions of packages debootstrap recommends: ii gnupg 1.4.9-4GNU privacy guard - a free PGP rep debootstrap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processing of dh-di_2_i386.changes
dh-di_2_i386.changes uploaded successfully to localhost along with the files: dh-di_2.dsc dh-di_2.tar.gz dh-di_2_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543786: partman-auto-raid: having to name devices explicitly is clumsy
Package: partman-auto-raid
Version: 15
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch karmic
partman-auto-raid/recipe currently has to be set like this:
d-i partman-auto-raid/recipe string \
1 2 0 ext3 / /dev/sda1#/dev/sdb1 . \
1 2 0 swap / /dev/sda5#/dev/sdb5 .
These device names would normally be expected to correspond to
partitions that are the result of running normal autopartitioning based
on partman-auto/expert_recipe or similar. I think that in general this
is clumsy and hard to manage. In particular, if you're generating
preseed files from some other format (e.g. kickseed) then it's
tremendously difficult to work out in advance what the partition numbers
are going to be in any portable way, without duplicating logic such as
that to choose default disk labels, due to the split between primary and
logical partitions; but even if you are in a position to work this out
by hand it is a very clumsy way to go about it.
Attached is a patch which introduces new syntax, looking like this:
d-i partman-auto-raid/recipe string \
1 2 0 ext3 / raidid=1 . \
1 2 0 swap / raidid=2 .
You then put raidid{ 1 } and raidid{ 2 } (the IDs don't have to be
numbers; they just have to contain neither spaces nor slashes) for the
method{ raid } elements in your main autopartitioning recipe, and
partman-auto-raid works out automatically which devices it ought to use.
Any comments? I think this is a noticeable improvement, so I'll commit
it next week or so if there are no objections.
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dh-di_2_i386.changes ACCEPTED
Accepted: dh-di_2.dsc to pool/main/d/dh-di/dh-di_2.dsc dh-di_2.tar.gz to pool/main/d/dh-di/dh-di_2.tar.gz dh-di_2_all.deb to pool/main/d/dh-di/dh-di_2_all.deb Override entries for your package: dh-di_2.dsc - source devel dh-di_2_all.deb - optional devel Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#468624: python-xml removal: please drop/replace (build) dependencies
The following patch removes the need for python-xml.
Note that python-xml is currently really a run-time dependency, not a
build-dependency.
Ben.
diff -Nru discover-data-2.2008.06.25/debian/control
discover-data-2.2008.06.25+nmu1/debian/control
--- discover-data-2.2008.06.25/debian/control 2008-01-12 19:31:13.0
+
+++ discover-data-2.2008.06.25+nmu1/debian/control 2009-08-27
01:16:31.0 +0100
@@ -4,7 +4,7 @@
Maintainer: Debian Install System Team
Uploaders: Petter Reinholdtsen , Otavio Salvador
, David Nusinow , Gaudenz Steinlin
Build-Depends: debhelper (>= 4.0)
-Build-Depends-Indep: python, python-xml
+Build-Depends-Indep: python
Standards-Version: 3.7.3
XS-Vcs-Svn: svn://svn.debian.org/pkg-discover/discover-data/trunk
diff -Nru discover-data-2.2008.06.25/reduce-xml
discover-data-2.2008.06.25+nmu1/reduce-xml
--- discover-data-2.2008.06.25/reduce-xml 2005-07-17 13:12:58.0
+0100
+++ discover-data-2.2008.06.25+nmu1/reduce-xml 2009-08-27 01:37:48.0
+0100
@@ -10,8 +10,6 @@
import getopt
import xml.dom
import xml.dom.minidom
-import xml.dom.ext
-from xml.dom.ext.reader import Sax2
try:
True
@@ -27,7 +25,6 @@
"classspec": [],
"classversion": "",
"modlistfile": "",
- "use-minidom": True,
"debug": False
}
@@ -183,14 +180,7 @@
bus_info = {}
for fn in config["filelist"]:
try:
-if config["use-minidom"]:
-document = xml.dom.minidom.parse(fn)
-else:
-f = open(fn)
-reader = Sax2.Reader()
-document = reader.fromStream(f)
-f.close()
-
+document = xml.dom.minidom.parse(fn)
bus_id = document.documentElement.attributes["bus"].value
except:
sys.stderr.write("warning: couldn't parse %s, skipping.\n"
@@ -257,7 +247,8 @@
nnode = data_node.childNodes[0]
while len(npath) > 0 and nnode is not None:
while nnode is not None and \
- not nnode.hasAttributes():
+nnode.nodeType != \
+xml.dom.Node.ELEMENT_NODE:
nnode = nnode.nextSibling
if nnode is None:
continue
@@ -318,7 +309,7 @@
else:
out_file = open(config["outfile"], "w")
-xml.dom.ext.PrettyPrint(out, out_file)
+out.writexml(out_file, encoding="UTF-8")
except UsageError, e:
sys.stderr.write(sys.argv[0] + ": " + str(e) + "\n")
--- END ---
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
Bug#543256: tasksel maintainer's perspective
So, that change was made in tasksel three months ago, near to the start what was, AFAIK at the time, a 1.5 year release cycle. This was done in full knowledge that enabling recommends would take some time to sort out, including getting debian-cd to disable NORECOMMENDS and maybe handle recommends more intelligently; dealing with demotion of unnecessary recommends; and dealing with any size increase issues. If the current release timeframe[1] is not long enough to sort these issues out, perhaps the release team should be told about that. Or perhaps someone will want to revert this -- but you get to own all the issues of the installer not installing recommends while maintainers assume it will. Frans Pop wrote: > Losing network-manager-gnome from CD1 seems like a fairly major issue > to me. Oddly it didn't seem to be treated as a big deal by a lot of people when it happened to stable CD1. :-/ [users disabling recommends] > IMO maintainers of desktop tasks do *not* have to worry about this. But they clearly do: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;att=0;bug=542095 | In the end this is possible, and you’re not the first one to ask, but | then we’ll get bug reports from stupid users asking why this or that | functionality doesn’t work, while Recommends have not been installed. -- see shy jo [1] Is anyone even knows that that is anymore. signature.asc Description: Digital signature
Bug#543256: Make installing recommends optional
Frans Pop: > I've been wondering whether we don't need a new field to express such > relationships. Something like "Soft-Depends:". That would be treated as > depends, but can be unselected manually or uninstalled later if a user > really, really wants to. You can come up with subtle graduations like this, but neither users nor developers will understand or apply them consistently, unless they are implemented in a way that encourages a given use. Recommends is currently implemented in all tools very close to the way your Soft-Depends would need to be, and the implementation drives behavior. Weakening recommends back down to how it used to be and adding another field would be a lot of work to end right back in the same place, with just some added complexity/confusion. -- see shy jo signature.asc Description: Digital signature
Bug#468624: python-xml removal: please drop/replace (build) dependencies
On Thu, 2009-08-27 at 01:59 +0100, Ben Hutchings wrote: > The following patch removes the need for python-xml. Sorry, that only covers the reduce-xml script. merge-lst-to-xml also needs to be modified. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
linux-kernel-di-ia64-2.6_1.42lenny5_ia64.changes ACCEPTED
Accepted: ata-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/ata-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb cdrom-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/cdrom-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb crc-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/crc-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb crypto-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/crypto-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb crypto-dm-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/crypto-dm-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb crypto-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/crypto-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb efi-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/efi-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ext3-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/ext3-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb fat-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/fat-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb fb-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/fb-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb firewire-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/firewire-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ide-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/ide-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ide-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/ide-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb input-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/input-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ipv6-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/ipv6-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb irda-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/irda-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb isofs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/isofs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb jfs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/jfs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb kernel-image-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/kernel-image-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb linux-kernel-di-ia64-2.6_1.42lenny5.dsc to pool/main/l/linux-kernel-di-ia64-2.6/linux-kernel-di-ia64-2.6_1.42lenny5.dsc linux-kernel-di-ia64-2.6_1.42lenny5.tar.gz to pool/main/l/linux-kernel-di-ia64-2.6/linux-kernel-di-ia64-2.6_1.42lenny5.tar.gz loop-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/loop-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb md-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/md-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb mouse-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/mouse-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb multipath-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/multipath-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb nic-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/nic-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb nic-shared-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/nic-shared-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb nic-usb-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/nic-usb-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb nls-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/nls-core-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb ntfs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/ntfs-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb parport-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/parport-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb pcmcia-modules-2.6.26-2-itanium-di_1.42lenny5_ia64.udeb to pool/main/l/linux-kernel-di-ia64-2.6/pcmcia-modules-
