Bug#243857: Patch has been available in Ubuntu
tags 243857 + pending thanks On Tuesday 16 March 2010, Joshua Kwan wrote: Looks like this bug hasn't seen action for quite a while. It seems like in the meantime, Ubuntu has fixed this bug. Check out this patch: http://launchpadlibrarian.net/18656164/cdrom-detect-better-flow.patch Thanks for the pointer. This code is in their current version of cdrom-detect and seems to work well in the exact same situation that d-i fails. Can we get this patch backported? Part of the patch is already in our code. I've ported the rest and done some additional refactoring. Will commit after testing in the next few days. I can do a NMU if there is no real maintainer willing to step up. An NMU (upload not from the D-I SVN repo) is never really a solution in the case of D-I as it tends to increase rather than reduce the work for maintainers. In general NMUs should not be needed where packages are maintained by a generally active team. It also seems not indicated in this case as this is the first time a patch has been suggested for the issue. Providing (preferably tested) patches against current SVN helps maintainers a lot more and is very much appreciated. Pinging maintainers on bug reports is also always appreciated. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#243857: Patch has been available in Ubuntu
Hi Joshua, On Tuesday 16 March 2010, Joshua Kwan wrote: Looks like this bug hasn't seen action for quite a while. It seems like in the meantime, Ubuntu has fixed this bug. Check out this patch: http://launchpadlibrarian.net/18656164/cdrom-detect-better-flow.patch Thanks for the pointer. I can do a NMU if there is no real maintainer willing to step up. An NMU is not required (and does not really reduce the work of maintainers anyway). But a proper patch, preferably tested, that applies to the current version of the source package and that does not log messages saying Ubuntu would be most welcome. I would suggest changing the message to ... is not a valid installation CD (especially as it does not actually test if it is a Debian or Ubuntu CD; if you'd happen to have a Debian CD in one drive and an Ubuntu CD in the other, it would accept either...). Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#243857: Patch has been available in Ubuntu
On Tuesday 16 March 2010, Frans Pop wrote: On Tuesday 16 March 2010, Joshua Kwan wrote: Looks like this bug hasn't seen action for quite a while. It seems like in the meantime, Ubuntu has fixed this bug. Check out this patch: http://launchpadlibrarian.net/18656164/cdrom-detect-better-flow.patch Thanks for the pointer. I can do a NMU if there is no real maintainer willing to step up. An NMU is not required (and does not really reduce the work of maintainers anyway). But a proper patch, preferably tested, that applies to the current version of the source package and that does not log messages saying Ubuntu would be most welcome. I would suggest changing the message to ... is not a valid installation CD (especially as it does not actually test if it is a Debian or Ubuntu CD; if you'd happen to have a Debian CD in one drive and an Ubuntu CD in the other, it would accept either...). Please ignore this mail. Apparently I had two versions open and by mistake also sent this early draft. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Tuesday 16 March 2010, Petter Reinholdtsen wrote: Further testing of this fix proved that it is insufficient. hw-detect call check-missing-firmware, which look on several devices (disk, USB sticks, floppies) for firmware, but fail to look on the CD itself. This, I must admit, is very sad. I had a look at the source of check-missing-firmware and saw it was looking in the firmware/ directory of several devices, and assumed it would also check the boot media, but no. :( Should hw-detect also look for firmware on the CD? I think the problem with that is that including the firmware on the CD in the first place is in contradiction with Debian's current policy not to include firmware in the distribution. The current firmware support is very explicitly limited to support loading from external media *prepared by the user*. An additional issue with non-free firmware is that including it in the way you propose would (I think) mean it will get loaded without any prompting of the user, which may in some cases violate licence terms. I can see that others may want to do things differently, but I'm not sure how much we can/should support that in standard D-I functionality. One option you have is to implement a custom, alternative version of 'mountmedia' for d-edu. Cheers, FJP P.S. Personally I would like to have more default support for loading firmware, but IMO we cannot do that without discussion with the rest of the project. -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161237.45197.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Tuesday 16 March 2010, Holger Levsen wrote: On Dienstag, 16. März 2010, Frans Pop wrote: An additional issue with non-free firmware is that including it in the way you propose would (I think) mean it will get loaded without any prompting of the user, which may in some cases violate licence terms. i thought the same at first, but actually that's not the case. The user is still asked (by the package) if she wants to accept the licence. (As no preseeding takes place.) But that's only at the point where the package gets installed in the target system. And at that point the firmware is already in use. IMO a proper solution would ensure the licence dialog gets displayed before the firmware first gets loaded by the installer. -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161350.45073.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Tuesday 16 March 2010, Petter Reinholdtsen wrote: Actually, something causes main-menu to crash if I adjust mountmedia to return CD devices too, so I suspect it is better to adjust check-missing-firmware to also look in /cdrom/firmware/ for debs. Probably because the CD is already mounted and in use and mountmedia messes that up? -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161352.30877.elen...@planet.nl
Re: Question for all candidates: Release process
Reading Wouter's post in this thread just now I realize I made a fairly stupid mistake when writing my mail. Frans Pop wrote: This seems to be what the RT has been focussing on after Sarge. [...] s/Sarge/Etch/ During the Sarge release these two sides were in balance. After that, for Sarge stable releases and the Lenny release, [...] s/Sarge/Etch/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003160723.26265.elen...@planet.nl
Bug#574096: installation problem report
On Tuesday 16 March 2010, Paul Jurczak wrote: Comments/Problems: I'm experimenting with various distributions and I successfully installed Ubuntu, Puppy, Fedora from USB Flash to USB Flash. Debian is the first distro, where I had to go USB CD to USB Flash route. Debian supports all kinds of installation methods. Looks to me like you simply did not try the correct one. For installations from USB stick you should use the hd-media installation method. Please see our installation guide. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161059.50401.elen...@planet.nl
Bug#574096: installation problem report
Please always reply to the BTS, not to the person responding. On Tuesday 16 March 2010, you wrote: Thank you for quick response. Do you mean that copying hd-media/boot.img.gz and .iso image to USB Flash will result in different installation behavior than preparing USB Flash with LiveUSB Creator and plain .iso image? I have no idea what LiveUSB Creator does. But if it only uses what's on the image it cannot work since, as you noticed, the installation image included on that will look for a CD *drive* instead of for a CD *image*. The main feature of the hd-media installation image is that it looks for CD images. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161208.03750.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Tuesday 16 March 2010, Petter Reinholdtsen wrote: Further testing of this fix proved that it is insufficient. hw-detect call check-missing-firmware, which look on several devices (disk, USB sticks, floppies) for firmware, but fail to look on the CD itself. This, I must admit, is very sad. I had a look at the source of check-missing-firmware and saw it was looking in the firmware/ directory of several devices, and assumed it would also check the boot media, but no. :( Should hw-detect also look for firmware on the CD? I think the problem with that is that including the firmware on the CD in the first place is in contradiction with Debian's current policy not to include firmware in the distribution. The current firmware support is very explicitly limited to support loading from external media *prepared by the user*. An additional issue with non-free firmware is that including it in the way you propose would (I think) mean it will get loaded without any prompting of the user, which may in some cases violate licence terms. I can see that others may want to do things differently, but I'm not sure how much we can/should support that in standard D-I functionality. One option you have is to implement a custom, alternative version of 'mountmedia' for d-edu. Cheers, FJP P.S. Personally I would like to have more default support for loading firmware, but IMO we cannot do that without discussion with the rest of the project. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161237.45197.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Tuesday 16 March 2010, Holger Levsen wrote: On Dienstag, 16. März 2010, Frans Pop wrote: An additional issue with non-free firmware is that including it in the way you propose would (I think) mean it will get loaded without any prompting of the user, which may in some cases violate licence terms. i thought the same at first, but actually that's not the case. The user is still asked (by the package) if she wants to accept the licence. (As no preseeding takes place.) But that's only at the point where the package gets installed in the target system. And at that point the firmware is already in use. IMO a proper solution would ensure the licence dialog gets displayed before the firmware first gets loaded by the installer. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161350.45073.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Tuesday 16 March 2010, Petter Reinholdtsen wrote: Actually, something causes main-menu to crash if I adjust mountmedia to return CD devices too, so I suspect it is better to adjust check-missing-firmware to also look in /cdrom/firmware/ for debs. Probably because the CD is already mounted and in use and mountmedia messes that up? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161352.30877.elen...@planet.nl
Re: Installer fails due to invalid signatures
reassign 573791 installation-reports tag 573791 unreproducible needinfo thanks On Tuesday 16 March 2010, steve clark wrote: I sent a report to the debian bug reporting system (bug number 573791) but it seems to not have been taken serious, being shuffled between responsible owners. I see it differently: you have an installation problem that nobody else is having and have not quite found the correct way to report it. The reason your bug report was reassigned is that the original report had an incorrect syntax. So it is *not* being shuffled around; someone was merely trying to correct your incorrect initial reporting. And please understand that reporting an issue incorrectly drastically increases the chance that it will be missed! Happens with other lives debian based systems (e.g. ubuntu 9.10 server) too. Please report issues with Ubuntu installs to Ubuntu. I'm a novice Debian user (4 months), but have over 25 years across multiple systems and am a professional developer, so think I can recognise a must look at problem when I see one :) In that case I would also expect you to recognize when a problem is so completely unlikely to escape the attention of the project publishing the software that it may well by an issue that's solely due to the inexperience of the user? I can assure you that, if Lenny really was not installable, we would be flooded with reports. Fortunately that has not happened. The fact that you consistently see the issue could also be explained by the fact that you're doing something consistently wrong maybe. !! I have just tried an install using the 5.04 netinst and using the !! ftp.uk.debian.org mirror without any problems. There may have been a temporary problem with that particular mirror. If there was it appears to be solved now. Did you try different mirrors? I would further suggest that as it prevents any new installations of Debian since at least 11th March 2010, its serverity is a little higher than normal. *If* the issue is confirmed to be a real issue *and* really affects all installations and not simply one isolated mirror, then yes. Until then a much more appropriate categorization is unreproducible, needs additional info. Now, to try to solve your problem, assuming that you can still reproduce it, we will need additional information. Please send us the syslog of a failed installation. You should be able to save it using the Save debug logs option in the main menu of the installer. Please gzip the syslog before sending it and send your reply _only_ to 573...@bugs.debian.org. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161438.13783.elen...@planet.nl
Bug#573791: apt-get update in Debian 5.04 (lenny) failing since updates of 2010-03-11
Please note this log is taken just now using: debian 5.04 netinst business card image I have just tried with the same image (for i386), using ftp.nl.d.o as mirror without any problems. My log looks similar to you, except that I get good signatures... From my log: Mar 16 17:41:08 choose-mirror[6970]: INFO: suite/codename set to: stable/lenny [...] Mar 16 16:42:18 main-menu[1044]: INFO: Menu item 'bootstrap-base' selected Mar 16 16:42:21 debootstrap: gpgv: Mar 16 16:42:21 debootstrap: Signature made Fri Jan 29 23:18:35 2010 UTC using RSA key ID 55BE302B Mar 16 16:42:21 debootstrap: gpgv: Mar 16 16:42:21 debootstrap: Good signature from Debian Archive Automatic Signing Key (5.0/lenny) ftpmas...@debian.org Mar 16 16:42:21 debootstrap: Mar 16 16:42:21 debootstrap: gpgv: Mar 16 16:42:21 debootstrap: Signature made Fri Jan 29 23:25:01 2010 UTC using DSA key ID F42584E6 Mar 16 16:42:21 debootstrap: gpgv: Mar 16 16:42:21 debootstrap: Good signature from Lenny Stable Release Key debian-rele...@lists.debian.org I wonder if somehow the files are getting corrupted during download. Can you copy the following two files from the installer after a debootstrap failure and send them: /target/var/lib/apt/lists/debootstrap.invalid_dists_lenny_Release /target/var/lib/apt/lists/debootstrap.invalid_dists_lenny_Release.gpg The first one should be zipped again. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161756.37536.elen...@planet.nl
Bug#574158: firmware licenses never displayed
On Tuesday 16 March 2010, Joey Hess wrote: 3. Provide some way for firmware debs to communicate to d-i that they have a license the user needs to see, and have check-missing-firmware display these licenses before the firmware is ever used. This is the option that I have had in the back of my mind for some time. I think for really structural support of firmware, we could repackage it like we do for kernel modules and include meta data (partially? automatically generated) about the deb something was taken from + licence requirements. That would also allow to e.g. skip old versions of firmware. My personal opinion is that it should actually be quite OK to include non-free firmware *udebs* on (CD) images as long as - the licence in no way limits distribution; - we never allow use of any non-free firmware without explicit ack by the user. The *debs* should IMO always be either downloaded from a mirror (using standard apt-install) with fallback support for installing them from an external medium. Under those conditions I think the project might be persuaded to accept inclusion of firmware in D-I images and on CDs. We should of course keep support for loading firmware that does not match these criteria from external media. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003162108.20985.elen...@planet.nl
Bug#243857: Patch has been available in Ubuntu
tags 243857 + pending thanks On Tuesday 16 March 2010, Joshua Kwan wrote: Looks like this bug hasn't seen action for quite a while. It seems like in the meantime, Ubuntu has fixed this bug. Check out this patch: http://launchpadlibrarian.net/18656164/cdrom-detect-better-flow.patch Thanks for the pointer. This code is in their current version of cdrom-detect and seems to work well in the exact same situation that d-i fails. Can we get this patch backported? Part of the patch is already in our code. I've ported the rest and done some additional refactoring. Will commit after testing in the next few days. I can do a NMU if there is no real maintainer willing to step up. An NMU (upload not from the D-I SVN repo) is never really a solution in the case of D-I as it tends to increase rather than reduce the work for maintainers. In general NMUs should not be needed where packages are maintained by a generally active team. It also seems not indicated in this case as this is the first time a patch has been suggested for the issue. Providing (preferably tested) patches against current SVN helps maintainers a lot more and is very much appreciated. Pinging maintainers on bug reports is also always appreciated. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003162255.02123.elen...@planet.nl
Re: Problem with local repository
On Tuesday 16 March 2010, Hugo Alberto Perlin wrote: I'm trying to install Debian using the NetInst CD and a local repository created using the apt-mirror app. The installation with the local repository make the downloads of the first part well. But in the second part, when it need 5 files, it requires the internet. Anybody knows what could be happen? What exactly do you mean by first part and second part? Are you sure that the packages in your local repository have a higher package version than the ones available on the mirror (including security updates!)? Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003162302.42767.elen...@planet.nl
Bug#243857: Patch has been available in Ubuntu
Hi Joshua, On Tuesday 16 March 2010, Joshua Kwan wrote: Looks like this bug hasn't seen action for quite a while. It seems like in the meantime, Ubuntu has fixed this bug. Check out this patch: http://launchpadlibrarian.net/18656164/cdrom-detect-better-flow.patch Thanks for the pointer. I can do a NMU if there is no real maintainer willing to step up. An NMU is not required (and does not really reduce the work of maintainers anyway). But a proper patch, preferably tested, that applies to the current version of the source package and that does not log messages saying Ubuntu would be most welcome. I would suggest changing the message to ... is not a valid installation CD (especially as it does not actually test if it is a Debian or Ubuntu CD; if you'd happen to have a Debian CD in one drive and an Ubuntu CD in the other, it would accept either...). Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003162259.58474.elen...@planet.nl
Bug#243857: Patch has been available in Ubuntu
On Tuesday 16 March 2010, Frans Pop wrote: On Tuesday 16 March 2010, Joshua Kwan wrote: Looks like this bug hasn't seen action for quite a while. It seems like in the meantime, Ubuntu has fixed this bug. Check out this patch: http://launchpadlibrarian.net/18656164/cdrom-detect-better-flow.patch Thanks for the pointer. I can do a NMU if there is no real maintainer willing to step up. An NMU is not required (and does not really reduce the work of maintainers anyway). But a proper patch, preferably tested, that applies to the current version of the source package and that does not log messages saying Ubuntu would be most welcome. I would suggest changing the message to ... is not a valid installation CD (especially as it does not actually test if it is a Debian or Ubuntu CD; if you'd happen to have a Debian CD in one drive and an Ubuntu CD in the other, it would accept either...). Please ignore this mail. Apparently I had two versions open and by mistake also sent this early draft. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003162325.05500.elen...@planet.nl
Re: PA8800/8900 status HPPA for Squeeze
Carlos O'Donell wrote: My *top* priorities are: - glibc regressions. - vfork bug.Carlos O'Donell wrote: I think it's time for another huge thank you to Carlos for his continued work that allows hppa to remain alive. So Carlos: muchas gracias (Not meaning to dismiss all the excellent work of others like Dann and various upstream people of course.) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003161446.29802.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Monday 15 March 2010, Petter Reinholdtsen wrote: That source package does not contain all available firmware, FWIW. You're missing at least zd1211-firmware and atmel-firmware. debian-cd has a list in tasks/firmware. Btw, tasks/firmware refer to the non-existing package firmware-ipw3945. Did it change name, go away or is it planned introduced in the future? The answer to that question is simple enough to find with either a quick look at packages.d.o, or simply: $ rmadison firmware-ipw3945 firmware-ipw3945 |0.4 | etch-m68k/non-free | all firmware-ipw3945 | 0.4+etchnhalf.1 | oldstable/non-free | all The firmware task should probably be made release-specific... -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003150834.41461.elen...@planet.nl
Re: Bits from the Release Team: What should go into squeeze?
Nikita V. Youshchenko wrote: From a current point of view squeeze will release with kernel 2.6.32 This is not very good, since .32 is skipped by -rt people, so us who need realtime kernel, won't be able just to add a patch to distribution kernel, but instead will have to use different upstream version. Given that some many distros are taking .32 as the basis for long term release support I find that a rather incomprehensible decision from the -rt people. There are *always* reasons to not use a particular kernel. Let's be happy we have one that has already stabilized quite a bit at this stage of our release process instead of continuing to second-guess the choice. Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003150821.29644.elen...@planet.nl
Bug#573946: apt: Dutch program translation update
Package: apt Version:0.7.25.3 Severity: wishlist Tags: patch, l10n Attached an update for the Dutch translation of apt. Please include in your next upload. TIA apt_0.7.25.3_nl.po.gz Description: GNU Zip compressed data
Bug#573987: console-setup
Package: console-setup Severity: minor Currently when selecting a layout for a country the Other choice is sorted alphabetically. This means that for Dutch it's the last option listed while for USA it's the first. It would be better to nave this not sorted and instead always have it listed as the last option (consistent with localechooser). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571939: Acknowledgement ([sparc] segfault when quitting aptitude)
On Monday 15 March 2010, Daniel Burrows wrote: Hm, the threadall backtraces look identical. Is there another page? Ugh, must have made a mistake. Will get a new trace. BTW, if you're talking about the mouse having problems because of the terminal state: usually holding down Shift bypasses mouse capture by the program running in the terminal and lets you select as usual. I know this works in xterm and gnome-terminal, anyway; I don't have Konsole handy right now to test in. Normally mouse select does not work when aptitude is running unless shift is pressed. That I know. I think this is different. But I will certainly try if shift helps. Should have thought of it myself. BTW, I can also give you direct access to the box if you like. Just send me your public SSH key. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571939: Acknowledgement ([sparc] segfault when quitting aptitude)
On Monday 15 March 2010, Daniel Burrows wrote: Hm, the threadall backtraces look identical. Is there another page? Shift did work... I've cleaned out the remnants of the frontend. Thread 12 (Thread 0xf3dddb70 (LWP 1516)): #0 0xf7837acc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0020a134 in waitcwidget::threads::mutex::lock (this=0x554ce8) at /usr/include/cwidget/generic/threads/threads.h:508 #2 resolver_manager::background_thread_execution (this=0x554ce8) at resolver_manager.cc:564 #3 0x00273ddc in resolver_manager::background_thread_bootstrap::operator() ( p=value optimized out) at resolver_manager.cc:704 #4 cwidget::threads::thread::bootstrapresolver_manager::background_thread_bootstrap (p=value optimized out) at /usr/include/cwidget/generic/threads/threads.h:117 #5 0xf7832358 in start_thread () from /lib/libpthread.so.0 #6 0xf756df1c in ?? () from /lib/libc.so.6 #7 0xf756df1c in ?? () from /lib/libc.so.6 cache Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 10 (Thread 0xf5fcbb70 (LWP 1514)): #0 0xf760ba60 in ?? () from /lib/libgcc_s.so.1 #1 0xf760c278 in ?? () from /lib/libgcc_s.so.1 #2 0xf760c304 in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1 #3 0xf783d814 in _Unwind_ForcedUnwind () from /lib/libpthread.so.0 #4 0xf783adfc in __pthread_unwind () from /lib/libpthread.so.0 #5 0xf7830eec in sigcancel_handler () from /lib/libpthread.so.0 #6 signal handler called #7 0xf783c908 in do_sigwait () from /lib/libpthread.so.0 #8 0xf783c9b4 in sigwait () from /lib/libpthread.so.0 #9 0xf7bcaa44 in cwidget::toplevel::signal_thread::operator() (this=0xf5fcb297) at toplevel.cc:587 #10 0xf7bcaa98 in cwidget::threads::thread::bootstrapcwidget::toplevel::signal_thread (p=value optimized out) at ../../src/cwidget/generic/threads/threads.h:117 #11 0xf7832358 in start_thread () from /lib/libpthread.so.0 #12 0xf756df1c in ?? () from /lib/libc.so.6 #13 0xf756df1c in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 2 (Thread 0xf7053b70 (LWP 1364)): #0 0xf7566358 in select () from /lib/libc.so.6 #1 0xf72a431c in apr_sleep () from /usr/lib/libapr-1.so.0 #2 0xf7d75174 in log4cxx::helpers::FileWatchdog::run(apr_thread_t*, void*) () from /usr/lib/liblog4cxx.so.10 #3 0xf7dff0d8 in log4cxx::helpers::Thread::launcher(apr_thread_t*, void*) () from /usr/lib/liblog4cxx.so.10 #4 0xf72a0e40 in ?? () from /usr/lib/libapr-1.so.0 #5 0xf72a0e40 in ?? () from /usr/lib/libapr-1.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 0xf7fec710 (LWP 1361)): #0 0xf78335f4 in pthread_join () from /lib/libpthread.so.0 #1 0xf7bc12a4 in cwidget::threads::thread::join () at ../../src/cwidget/generic/threads/threads.h:235 #2 cwidget::toplevel::signal_thread::stop () at toplevel.cc:563 #3 cwidget::toplevel::suspend_without_signals () at toplevel.cc:1195 #4 0xf7bc1940 in cwidget::toplevel::suspend () at toplevel.cc:1225 #5 0xf7bc1a14 in cwidget::toplevel::shutdown () at toplevel.cc:1236 #6 0x000f7e9c in ui_main () at ui.cc:2863 #7 0x0002e158 in main (argc=1, argv=0xd804) at main.cc:1178 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573946: apt: Dutch program translation update
On Monday 15 March 2010, Christian PERRIER wrote: Thanks, Frans. Resyncing the file with the current POT file in teh debian-sid branch in bzr gives one untranslated string. Would you mind completing it? Attached. nl.po.gz Description: GNU Zip compressed data
Re: Question for all candidates: Care of Core infrastructure
Marc Haber wrote: In the last years I have seen a really disturbing development in Debian: New developers are very interested in bringing new packages into Debian, but care for our core infrastructure (dpkg, apt) has a little bit diminished. Good question and quite true. IMO it's worth adding to that: - Debian Installer development - Porting: several ports are struggling - Documentation maintenance: - website - Release Notes - various other guides -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003151252.45199.elen...@planet.nl
Re: Question for all candidates: Release process
Margarita Manterola wrote: I think that most of the frustration comes from the fact that the release team is lacking manpower. The job of the release team is very stressful and very rarely do the RM and RA feel that their work is appreciated. I disagree. I think the main problem is that there are two main sides to what the Release Team does and that the cause of the frustration on the side of the rest of the project is that one of those is sides has been neglected. And that frustration in the rest of the project creates the negative feedback and criticism which in turn creates the stress in the RT. The two sides I'm talking about are: - the technical work around preparing a release This includes managing transitions, migrations; doing removals; maintaining tools; etc. This seems to be what the RT has been focussing on after Sarge. This is also where most manpower currently goes. And it's very necessary and important. And in general I think it's done quite well (except when someone decides - without any prior announcement or opportunity for review or comment - to do a mass removal of packages from testing because they have a random RC bug open even though the importance of the package massively outweighs the practical impact of the bug). - the actual *management* of the release process This involves planning and coordinating the work that needs to be done by regular DDs; ensuring that not only the archive is in a releasable state, but that also the website and documentation (including translations) have been updated; stimulating BSPs; preparing release announcements (and giving people who's work your announcing time to review and comment what you've written for them); informing everybody involved of the status and progress of a release. And also tracking the status of architectures and *discussing* with the project what to do when an arch has problems (instead of just deciding on things in isolation); keeping track of release goals and stimulating work on them so that they are actually implemented, The quality of a Debian release is determined by much more than just the RC bug count. And it all needs to be managed, or at least coordinated. And *everything* needs to be ready on the day, not just one aspect. During the Sarge release these two sides were in balance. After that, for Sarge stable releases and the Lenny release, the second side was horrible. And several people contributing a lot of work in strongly release-related areas have been driven away by that. After Lenny things have improved in some areas (communication about ports has been quite good for example and so has the management of the last couple of stable point releases), but for Squeeze we've only seen a very few rather general status mails, but no coordination at all. The Release Team should IMO keep in mind that it's not *they* who make a release, but the whole project together. And the best way to get respect for their work is for them to respect the vastly bigger amount of work done by all other DDs collectively. The fact that they control the switches does not mean that they can unilaterally make any decision regarding the work of others. There is no problem with the RT making the *final* decision about release related issues, but they simply cannot make most decisions without checking with the rest of the project. If only simply because in most cases they won't have all relevant information. And checking with the rest of the project is *not* asking a few buddies on a selected channel on IRC. It's doing proper announcement and RFC/RFRs on the mailing lists intended for that purpose. And finally, the best way to get help is to be open about what you're doing. If you hide yourself away and don't communicate with the project you don't get help. I think the very noticeable change in the FTP team is proof of that. IMO for a lot of the above the primary responsability lies with the person with the title/role of Release Manager. Ideally the Release Manager should spend more time on communicating with the rest of the project than on handling transitions. The challenge for an RM when the team can't handle the workload is not to do it all himself, but to continue communicating and get help. Cheers, FJP -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003151630.25818.elen...@planet.nl
Re: how to set title in installer interface
On Monday 15 March 2010, Frans Pop wrote: On Monday 15 March 2010, kin boster wrote: Template: my_test/title Should be: debian-installer/my_title/title Or rather: debian-installer/my_test-udeb/title (Or, in general: debian-installer/name of udeb/title) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003150702.24136.elen...@planet.nl
Re: Getting d-i to find firmware on the CD generated by debian-cd
On Monday 15 March 2010, Petter Reinholdtsen wrote: That source package does not contain all available firmware, FWIW. You're missing at least zd1211-firmware and atmel-firmware. debian-cd has a list in tasks/firmware. Btw, tasks/firmware refer to the non-existing package firmware-ipw3945. Did it change name, go away or is it planned introduced in the future? The answer to that question is simple enough to find with either a quick look at packages.d.o, or simply: $ rmadison firmware-ipw3945 firmware-ipw3945 |0.4 | etch-m68k/non-free | all firmware-ipw3945 | 0.4+etchnhalf.1 | oldstable/non-free | all The firmware task should probably be made release-specific... -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003150834.41461.elen...@planet.nl
Re: Switching g-i from DirectFB to X11 -- console-setup
On Saturday 27 February 2010, Anton Zinoviev wrote: On Sat, Feb 27, 2010 at 09:16:40PM +0100, Julien Cristau wrote: It'd be quite weird to have a keyboard layout configured in d-i, and ignored when switching VTs to get to a console, IMO... Unfortunately this is inevitable. 'loadkeys' and 'setfont' do not work when X is active. A solution would be to start somehow xterm inside X. This is a major issue IMO. The graphical installer has always [1] had a correct keyboard configuration for both the graphical environment and for the debug shells. Losing that would be an important regression. [1] Well, after we had the bugs figured out. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003151141.17491.elen...@planet.nl
Re: Towards X11-based d-i: v2, final report
Sorry for not replying sooner. If there had been anything really urgent I would have commented, but there wasn't. I did look at the new image and udebs earlier, but did not get around to doing a full review until now. The difference in image size between version 1 and 2 is about 400kB (smaller), but because of the alpha release and kernel switch there are many other factors then just X.Org udebs. More relevant is that it is now only 15% instead of almost 19% larger than a current directfb based image would have been, which is a significant improvement IMO. The main components of the 400kB difference are roughly: - reduced size of X.Org related stuff: -/- 565kB - dropping of dhcp3-client-udeb: -/- 166kB - new kernel: - general increase: 225kB - increased size of mouse-modules (bug fix): 8kB That 0.5 MB improvement is well worth the effort. Thanks. The new udev udebs look good as well. I think with this all the obvious fat has been trimmed and errors resolved. Things I did notice: - libx11-6-udeb: still contains a man page - libx11-6-udeb: some (most/all?) of the included locales are probably not needed; the en_US Compose file is huge and the one for Finnish is insane considering it's only for a single language - what if all langs had a file like that... - xserver-xorg-video-fbdev-udeb: depends on libc6 instead of libc6-udeb - udev-gtk-udeb: long description is a bit weird; I'd expect the last sentence together with the first sentence and not dangling at the end, and the additionally does not really make any sense On Saturday 27 February 2010, Cyril Brulebois wrote: Various remarks: * I had to disable speakup since the related package isn't available right now after the 2.6.30 → 2.6.32 switch. Sorry about that. I might generate another “v2” image once this package is available, though. Speakup is just a minor detail in the context of this change. Don't worry about it. * Previously I was building against squeeze, but with that same kernel version switch, I had to enable both squeeze and sid in my sources.list.udeb file. It's much better always to build against sid when doing development work for D-I. For our purposes testing is much less reliable. * I'm now generating the minimal XML file for the MIME database in a cleaner fashion, using an XSLT transformation. Nice. * It might be possible to get rid of some X libraries by linking statically against them, but that would mean more work, possibly additional flavours, etc. I'm not sure the gain (if any) would be as high as for the server (see previous report), though. I'd tend to think it'd be more maintainable on the long run to keep the current set of udebs than trying to reduce it as much as possible. It would only make sense for libs - that are only depended on by one other udeb - that's of a non-trivial size - for which most of its symbols are not actually used I think that with libgcrypt we've already got the most obvious candidate, although the gain seems to have been less than I would have expected. Things for later: = * Deal with cursors, including supporting theme switching. IMO the default cursor is fine. Theme support is more relevant, but as mentioned before I think it's realistic to ask the accessibility people to look into that. * Probably get rid of refresh_keymap() in cdebconf. I would make me very unhappy if we don't have correct keymap setup in both the graphical (or D-I) environment and on the VTs for the debug consoles. I can see that refresh_keymap() is maybe not the correct implementation to achieve this, but something should. Debug shells are an essential feature of D-I, for both development and rescue. * Dive into mklibs. I've thought of that a bit more and come up with a snag. mklibs will only work if the pic files 100% match the library that is being reduced. So there's a problem when libs in D-I are configured differently from the regular libs, or if they have other libs compiled in statically. It can be solved in two ways: - have special *-udeb-pic debs (which should conflict with normal -pic debs - do library reduction in a chroot of the image instead of using the host system The second option has the added advantage of making a build less dependent on the host system (for official builds it could pull -pic *udebs* from testing instead of installing them on the host system), but it also means a fair complication of the build process and probably that builds would always need to be run as root (either real or sudo). I would add: * Reduce the duplication that exists between console-setup and X.org udebs. As per: http://lists.debian.org/debian-boot/2010/02/msg00771.html Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: Towards X11-based d-i: v2, final report
On Monday 15 March 2010, Cyril Brulebois wrote:
In the end I used libnettle, statically linked (that's amd64 this
time, but you'll see the huge overhead of linking statically):
| Installed-Size: [-2204-] {+2208+}
libmatrixssl's headers were a mess, nettle is much cleaner, and
directly usable as it is, while the former needed some work and we had
no replies from its maintainer yet.
When you have time, could you perhaps create a Wiki page under [1] with
info on how the X.Org backend is put together?
I think would be good have an overview of and to document the reasons for
differences with regular X.Org libs such as (config) choices and what's
compiled statically.
[1] http://wiki.debian.org/DebianInstaller/GUI
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201003151326.36643.elen...@planet.nl
Bug#573987: console-setup
Package: console-setup Severity: minor Currently when selecting a layout for a country the Other choice is sorted alphabetically. This means that for Dutch it's the last option listed while for USA it's the first. It would be better to nave this not sorted and instead always have it listed as the last option (consistent with localechooser). -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003151422.55307.elen...@planet.nl
Re: Switching g-i from DirectFB to X11 -- console-setup
On Saturday 27 February 2010, Anton Zinoviev wrote: On Fri, Feb 26, 2010 at 10:22:54AM +0100, Frans Pop wrote: Besides that it offers choices for keymaps that are not even available This does happen. At least, with only console-setup-pc-ekmap loaded I see Sun dead keys listed for Dutch (hmmm, but no Sun keymaps for USA) and I also see Macintosh a lot (which is probably necessary). and AFAIK it does not detect headless systems that don't need any console setup. AFAIK this doesn't happen. You're right (tested). It does check if a keyboard is connected, so headless is covered. But AFAICT it does not check for a serial console install (not tested [1]). kbd-chooser also checks for that and for UML installs. And IIRC the Xen people also asked at some point to skip keyboard configuration, but I'm not sure what the status of that is. Call it unused head installs. By default kbd-chooser will skip keyboard configuration for serial console installs, but (at medium/low priority) it will still offer the option to configure a keyboard. This can be useful for systems that are installed remotely but should still have a keyboard/console configured for local maintenance. For that same reason D-I also has an option to enable VTs even though a serial console is being used for an install. The extremely long selection lists make console-setup-udeb completely unusable with the text frontend. Inconvenient as always with the long selection lists, but not unusable, I know it's technically usable, but IMO it's effectively unusable. see #531646. However, I am not sure which extremely long selection lists are you refering to. AFAIK there is only one long selection list in c-s-udeb, in the typical situation this question won't be asked and I like to consider all use cases, not just default installs. it is longer than the corresponding selection list of kbd-chooser only because some layouts are not supported by kbd-chooser. IMO it lists quite a few keymaps that can be expected to have such a incredibly tiny user base that it would be better not to list them at all, at least not in the udeb. The basic error in the design is the assumption that the same functionality is suitable for both installed systems (where users may want to tune there keyboard for their personal preferences and, most importantly, have the opportunity to try out different options and see their effect) and for the installer (where users only need a basic selection of the correct keymap with solid defaults based on country, language and keymap for everything else). There is no such assumption. If the d-i team has enough man-power the the udeb can be redesigned to ask entirely different questions. I never meant to imply that you should do it all. I will probably have a go at it myself at some point, but it's not high on my ToDo list. I think a lot of things changed in console-setup since that thread. Yes, it does look better than it did. But the choices for Netherlands are still unusable (both Netherlands and Netherlands - Standard seem to give the same very uncommon Dutch layout and there seems to be no option for the most common US layout). The description for the keyboard origin question still needs improvement. Here's a proposal (assuming that the goal is that each country _will_ list all layouts common in that country; if not, the use of origin is simply incorrect): = The layout of keyboards varies per country, with some countries having multiple common layouts. Please select the country of origin for the keyboard of this computer. Country of origin: = We should also consider adding a progress bar while c-s loads all its data. On my sparc there was a too long delay with nothing but a blue screen showing... Cheers, FJP [1] I tried to but serial console failed with .33 on my sparc with keyboard connected (i.e. with head); without keyboard (which makes the firmware operate in headless mode) strangely enough does work. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003151734.42951.elen...@planet.nl
Re: Bug#573891: kFreeBSD partitioning fails
On Sunday 14 March 2010, Miroslav Kure wrote: No clue on tty4 at this stage. However, when I go back to the main That's normal. stderr often stays buffered until you exit a component (return to the main menu). menu and select to partition disks again, nothing happens (I am So that's not actually needed. immediately returned to the main menu), but syslog now reads: Mar 14 18:35:33 main-menu[117]: (process:1184): line 105: Mar 14 18:35:33 main-menu[117]: (process:1184): depmod: not found That's probably expected on freebsd (but should be handled cleaner). Mar 14 18:35:33 main-menu[117]: (process:1184): line 131: Mar 14 18:35:33 main-menu[117]: (process:1184): can't open /var/lib/partman/outfifo: no such file This is the real error. Looking at the attached partman log I would say it wants to use the ext2 filesystem by default for the new partition and switching to ufs does not work very well. From that log: parted_server: Read command: CHANGE_FILE_SYSTEM parted_server: Opening outfifo parted_server: command_change_file_system(26740385280-30005821439,freebsd-ufs) parted_server: partition_with_id(26740385280-30005821439) parted_server: Filesystem freebsd-ufs not found, let's see if it is a flag parted_server: Bad file system or flag type: freebsd-ufs parted_server: Line 1723. CRITICAL ERROR!!! EXITING. Yep. That's the cause. Looks like something the freebsd porters (CCed) will need to look into. But it's a bit strange as ufs has been the default file system for freebsd since Aug 2009. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003142112.46379.elen...@planet.nl
Bug#573818: 'man debtree' typos: allready, occurence x 2, and seperation
tags 573818 pending thanks On Sunday 14 March 2010, A. Costa wrote: Found some typos in '/usr/share/man/man1/debtree.1.gz', see attached '.diff'. Thanks a lot. Committed for the next release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573878: netcfg: hurd-i386 Fixes
tag 573878 pending thanks On Sunday 14 March 2010, Samuel Thibault wrote: Here is some fixes for netcfg on hurd-i386. Committed. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573878: netcfg: hurd-i386 Fixes
On Sunday 14 March 2010, Samuel Thibault wrote: Please also add hurd-i386 to the netcfg binary package architecture list. Done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573891: kFreeBSD partitioning fails
On Sunday 14 March 2010, Miroslav Kure wrote: No clue on tty4 at this stage. However, when I go back to the main That's normal. stderr often stays buffered until you exit a component (return to the main menu). menu and select to partition disks again, nothing happens (I am So that's not actually needed. immediately returned to the main menu), but syslog now reads: Mar 14 18:35:33 main-menu[117]: (process:1184): line 105: Mar 14 18:35:33 main-menu[117]: (process:1184): depmod: not found That's probably expected on freebsd (but should be handled cleaner). Mar 14 18:35:33 main-menu[117]: (process:1184): line 131: Mar 14 18:35:33 main-menu[117]: (process:1184): can't open /var/lib/partman/outfifo: no such file This is the real error. Looking at the attached partman log I would say it wants to use the ext2 filesystem by default for the new partition and switching to ufs does not work very well. From that log: parted_server: Read command: CHANGE_FILE_SYSTEM parted_server: Opening outfifo parted_server: command_change_file_system(26740385280-30005821439,freebsd-ufs) parted_server: partition_with_id(26740385280-30005821439) parted_server: Filesystem freebsd-ufs not found, let's see if it is a flag parted_server: Bad file system or flag type: freebsd-ufs parted_server: Line 1723. CRITICAL ERROR!!! EXITING. Yep. That's the cause. Looks like something the freebsd porters (CCed) will need to look into. But it's a bit strange as ufs has been the default file system for freebsd since Aug 2009. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Invite to join the Release Team
On Sunday 14 March 2010, Clint Adams wrote: Okay, so when there is a mysterious release team meeting in Cambridge, and there is no discussion or planning of it on debian-release [...] Clint, Although to some level I agree with you [1], I wonder if you could explain one thing. That meeting took place in May of last year. What's the point of discussing it almost 9 months later? What exactly triggered your blog post? Cheers, FJP [1] I think release management for (old)stable is being handled quite well ATM. Although we could have somewhat more frequent updates I'm quite happy with how they are being managed (good pro-active communication with DDs who have updates for stable). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003141609.34756.elen...@planet.nl
Re: Invite to join the Release Team
On Sunday 14 March 2010, Gerfried Fuchs wrote: * Frans Pop elen...@planet.nl [2010-03-14 16:09:34 CET]: [1] I think release management for (old)stable is being handled quite well ATM. While this might be true and valid for stable, I am not too convinced that the last point release of oldstable from April 8th of last year is too much for being called handled quite well. I'm not interested in throwing mud around, I just want to get some things straight here. Oh, I have had big problems with how a number of point releases have been handled in the pastas well. It was one of the main topics in my talk (rant?) about improving RM during Fosdem last year. And almost a year is certainly too long between point releases, even for oldstable. But I am quite happy with the way the last two stable point releases were handled. What's mainly been improved is that the stable release manager is really keeping track of ToDo items and has contacted me on his own initiative to discuss D-I items for the release announcement. There are probably still a few things that could be improved further (website updates?), but it's a refreshing breath compared to what it was. Kudos to Adam. I'm confident we'll have a good (final) point release for Etch very soon too. Cheers, FJP -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003142348.11590.elen...@planet.nl
Re: Should D-I install console-setup with kbd and console-tools or not?
On Sunday 14 March 2010, Anton Zinoviev wrote: On Sun, Mar 14, 2010 at 08:15:53AM +0100, Frans Pop wrote: D-I does not follow Recommends during base-installer (as discussed last month). This means that currently console-setup gets installed without kbd and console-tools. This is wrong. Console-setup can not configure the console without kbd or console-tools. OK. That's clear enough :-) Isn't the installer the program that makes the decision whether kbd or console-tools has to be installed? Partly. It depends on how APT is configured. And at that point in the installation it's configured not to install Recommends by default. After base-installer we _do_ install Recommends by default. We can also use a parameter when calling apt-install to force installing Recommends. That's what I was planning to do for console-setup. But I wanted to check with you first why they are Recommends in the first place. Note that up to Lenny D-I *never* installed Recommends. We've only changed that since then but are still working out some special cases. Would it be better in your opinion to force installation of Recommends for console-setup? What exactly is the difference for users? I am not sure I understand. I can make c-s to depend on kbd or console-tools. Should I? If the package is useless without those two packages, then maybe you should. But see below. In the past c-s used strong dependency but I changed it to only recommends because of request by porters working on architectures which do not have kbd or console-tools (i.e. BSD). This was before the split of c-s. Now with the new package keyboard-configuration I think I can use again dependency if you want. That explains the background. But I'm not sure that the problem is solved for those ports. As console-setup depends on keyboard-configuration, wouldn't making it a depends result in console-setup itself becoming uninstallable again? As said above we can also solve it in D-I by forcing the installation of Recommends. Please let me know and I'll take care of it. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003141239.21651.elen...@planet.nl
Re: Should D-I install console-setup with kbd and console-tools or not?
On Sunday 14 March 2010, Samuel Thibault wrote:
Anton Zinoviev, le Sun 14 Mar 2010 12:39:08 +0200, a écrit :
In the past c-s used strong dependency but I changed it to only
recommends because of request by porters working on architectures
which do not have kbd or console-tools (i.e. BSD).
The dependency could be dropped on those archs only.
That's possible, but not trivial.
See e.g. debian/{rules,control} in cdebconf for an example (for
cdebconf-gtk-udeb) how to do it correctly.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201003141306.56952.elen...@planet.nl
Re: Should D-I install console-setup with kbd and console-tools or not?
On Sunday 14 March 2010, Anton Zinoviev wrote: I am realy surprised by all of this. What was causing kbd or console-tools to be installed in the past (before console-setup)? We used to explicitly install 'console-tools console-data console-common'. Probably exactly because Recommends were not getting installed. But as I mentioned earlier we've been rethinking the whole Recommends handling for Squeeze. This is the last open issue. Note that this is *not* a problem with the alpha1 release as that *does* install Recommends during base-installer. Console-setup will become uninstallable. However this should not be a problem. There is no need to install console-setup on these architectures (and the installer should force the installation of keyboard-configuration instead of console-setup). That could be done, but isn't the case now. As said above we can also solve it in D-I by forcing the installation of Recommends. Please let me know and I'll take care of it. Changing d-i because of c-s seems wrong to me. It's not actually a change in D-I. There's simply more than one way to Rome. The difference is this: --- kbd-chooser/post-base-installer.d/20kbd-chooser (revision 62565) +++ kbd-chooser/post-base-installer.d/20kbd-chooser (working copy) @@ -27,6 +27,6 @@ d-i debian-installer/keymap string $KEYMAP EOF -apt-install console-setup || true +apt-install --with-recommends console-setup || true exit 0 Trivial, no? So there are two options: 1. Changing c-s to depend on kbd | console-tools and installing keyboard-configuration instead of console-setup on some architectures. That's certainly possible. It's a fairly simple change in kbd-chooser. Seems like the best option as it means that the --with-recommends is not needed and will also avoid accidental incomplete manual installs of c-s on Linux. Does that mean console-setup itself is essentially useless on kfreebsd and hurd? 2. Let kbd-chooser decide which one of console-setup, kbd and keyboard-configuration is going to be installed. This would be my preferred choice if console-setup-udeb was part of the installer. My reasoning is this: the installer should be able to use c-s as a black box. No console-related code outside of console-setup-udeb. I don't really see the difference TBH. It still requires similar logic to decide what to install when. Or... 3. Apply the patch above. This would result in c-s and k-c being installed on all arches and kbd and console-tools only on those arches where they are available. But option 1) sounds like the cleanest solution. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003141846.15530.elen...@planet.nl
Bug#573878: netcfg: hurd-i386 Fixes
tag 573878 pending thanks On Sunday 14 March 2010, Samuel Thibault wrote: Here is some fixes for netcfg on hurd-i386. Committed. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003141942.53684.elen...@planet.nl
Bug#573878: netcfg: hurd-i386 Fixes
On Sunday 14 March 2010, Samuel Thibault wrote: Please also add hurd-i386 to the netcfg binary package architecture list. Done. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003141942.43652.elen...@planet.nl
Bug#573891: kFreeBSD partitioning fails
On Sunday 14 March 2010, Miroslav Kure wrote: No clue on tty4 at this stage. However, when I go back to the main That's normal. stderr often stays buffered until you exit a component (return to the main menu). menu and select to partition disks again, nothing happens (I am So that's not actually needed. immediately returned to the main menu), but syslog now reads: Mar 14 18:35:33 main-menu[117]: (process:1184): line 105: Mar 14 18:35:33 main-menu[117]: (process:1184): depmod: not found That's probably expected on freebsd (but should be handled cleaner). Mar 14 18:35:33 main-menu[117]: (process:1184): line 131: Mar 14 18:35:33 main-menu[117]: (process:1184): can't open /var/lib/partman/outfifo: no such file This is the real error. Looking at the attached partman log I would say it wants to use the ext2 filesystem by default for the new partition and switching to ufs does not work very well. From that log: parted_server: Read command: CHANGE_FILE_SYSTEM parted_server: Opening outfifo parted_server: command_change_file_system(26740385280-30005821439,freebsd-ufs) parted_server: partition_with_id(26740385280-30005821439) parted_server: Filesystem freebsd-ufs not found, let's see if it is a flag parted_server: Bad file system or flag type: freebsd-ufs parted_server: Line 1723. CRITICAL ERROR!!! EXITING. Yep. That's the cause. Looks like something the freebsd porters (CCed) will need to look into. But it's a bit strange as ufs has been the default file system for freebsd since Aug 2009. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003142112.46379.elen...@planet.nl
Re: how to set title in installer interface
On Monday 15 March 2010, kin boster wrote: Template: my_test/title Should be: debian-installer/my_title/title -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003150645.15144.elen...@planet.nl
Accepted partman-target 66 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 14 Mar 2010 08:33:08 +0100 Source: partman-target Binary: partman-target Architecture: source all Version: 66 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Frans Pop f...@debian.org Description: partman-target - Provides partman with ability to prepare /target (udeb) Closes: 573252 Changes: partman-target (66) unstable; urgency=low . * No longer create /cdrom compatibility symlink. Closes: #573252. With thanks to Maximilian Attems. Requires base-installer (= 1.106). * Remove unnecessary braces in finish.d scripts. . [ Updated translations ] * Hebrew (he.po) by Omer Zak * Slovenian (sl.po) by Vanja Cvelbar Checksums-Sha1: e716c7efb349a38647fdb33d7d2d508de15b0f53 901 partman-target_66.dsc 906674995def4cbc38d705bba1cbabe5cbcaed34 121585 partman-target_66.tar.gz 7ff794cbf7ee3a27e25ea8c7ac36cd2aa86cc199 97330 partman-target_66_all.udeb Checksums-Sha256: c9fcffa9ba410e23934442dae8b88513b0da6a6653fcd6d76b384db0b8cf0149 901 partman-target_66.dsc d591ea536f9e84a1fc79862486bd098b28a5844545887d7739c594a446731c58 121585 partman-target_66.tar.gz 2b95318cbd7c6092e2bcb5433566ba00ce0bdbada2bac6a160dab816349d7175 97330 partman-target_66_all.udeb Files: f49da983b661ac5383d51d39c4990e38 901 debian-installer standard partman-target_66.dsc 2bd8683dcb352619730255bb60330f8c 121585 debian-installer standard partman-target_66.tar.gz 406a5db1a8f50160b4ac11b856513cf8 97330 debian-installer standard partman-target_66_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkuckYMACgkQgm/Kwh6ICoR5BwCfQLK92dghlE0uj5zr9RgGhTUw 6voAoM0+rW5m2s1MD6+JqSL8h3yJOdya =hLc2 -END PGP SIGNATURE- Accepted: partman-target_66.dsc to main/p/partman-target/partman-target_66.dsc partman-target_66.tar.gz to main/p/partman-target/partman-target_66.tar.gz partman-target_66_all.udeb to main/p/partman-target/partman-target_66_all.udeb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1nqixs-0001yt...@ries.debian.org
Accepted pkgsel 0.28 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 14 Mar 2010 08:29:49 +0100 Source: pkgsel Binary: pkgsel Architecture: source all Version: 0.28 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Frans Pop f...@debian.org Description: pkgsel - Select and install packages (udeb) Changes: pkgsel (0.28) unstable; urgency=low . * 90popcon: fix syntax error. . [ Updated translations ] * Slovenian (sl.po) by Vanja Cvelbar Checksums-Sha1: 75064e11c14c2ca0a5b7f12813bb7e08c70ff340 816 pkgsel_0.28.dsc 9201683e4874b543f66a33f74bce62c4f609adeb 29652 pkgsel_0.28.tar.gz bcd3346f5a2dca3f0b6298dfda1050778aa0c901 9694 pkgsel_0.28_all.udeb Checksums-Sha256: 641589e5e2ee3e2432845da0377db295d8ec1d05b3e4d087081ad0606d2f739f 816 pkgsel_0.28.dsc d77e1af3f233eb91ff991e3088e8b889dc7ebb45b3883a8bf293871e694fa489 29652 pkgsel_0.28.tar.gz 0b76bb1da4f5d505cdf7b8b9b4f34daf06dd26ba945335913f2720170ebf23a2 9694 pkgsel_0.28_all.udeb Files: 2230708ae3e76e50b398d4ac030902b3 816 debian-installer standard pkgsel_0.28.dsc 30860799723085ffb90c9c5cd9b51d7f 29652 debian-installer standard pkgsel_0.28.tar.gz fb0eb80d61d3fd777864c5261d2917ab 9694 debian-installer standard pkgsel_0.28_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkuckJQACgkQgm/Kwh6ICoTA5wCfSTxUXJ2urmDSqJpaHZgplymt zv8AoJH0z1Jf3EruMnQTMvW9p98ktw7A =j1lZ -END PGP SIGNATURE- Accepted: pkgsel_0.28.dsc to main/p/pkgsel/pkgsel_0.28.dsc pkgsel_0.28.tar.gz to main/p/pkgsel/pkgsel_0.28.tar.gz pkgsel_0.28_all.udeb to main/p/pkgsel/pkgsel_0.28_all.udeb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1nqixf-0001ax...@ries.debian.org
Re: [RFC] Dealing with mdadm superblock metadata default change
Hi Martin, On Saturday 13 February 2010, martin f krafft wrote: also sprach Frans Pop elen...@planet.nl [2010.02.12.1238 +1300]: but I think we should make 0.9 the default for squeeze and move to 1.1 only afterwards, once grub-pc knows how to deal with it. Do you want to do that in mdadm itself, or should D-I do it? For consistency mdadm seems more logical. Yes, I think it should be in mdadm. It should be as easy as reverting http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=commitdiff;h=7d5c3964ccfa ace123f7b75e15d38c2650e013d8 What's the status of this? Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003140811.58679.elen...@planet.nl
Should D-I install console-setup with kbd and console-tools or not?
Hi Anton, D-I does not follow Recommends during base-installer (as discussed last month). This means that currently console-setup gets installed without kbd and console-tools. Would it be better in your opinion to force installation of Recommends for console-setup? What exactly is the difference for users? Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003140815.54237.elen...@planet.nl
Accepted apt-setup 1:0.45 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 12 Mar 2010 23:11:42 +0100 Source: apt-setup Binary: apt-setup-udeb apt-mirror-setup apt-cdrom-setup Architecture: source all Version: 1:0.45 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Frans Pop f...@debian.org Description: apt-cdrom-setup - set up a CD in sources.list (udeb) apt-mirror-setup - set up a mirror in sources.list (udeb) apt-setup-udeb - Configure apt (udeb) Changes: apt-setup (1:0.45) unstable; urgency=low . * There's no need anymore to unmount /target/cdrom. . [ Updated translations ] * Spanish (es.po) by Javier Fernández-Sanguino Peña * Hebrew (he.po) by Omer Zak * Slovenian (sl.po) by Vanja Cvelbar Checksums-Sha1: efe1e461c9e3b2a5854e1f6163cbfea283ec53ca 917 apt-setup_0.45.dsc 0bcaedcf5e59eaf8935a863ad65a37c2f2d44e2a 234055 apt-setup_0.45.tar.gz 73ae26cd09c4e8a601351518c5eda5882a2c0cf5 45724 apt-setup-udeb_0.45_all.udeb 92f146bc3ca8202e736eba40604008651663d1b9 63340 apt-mirror-setup_0.45_all.udeb 45d62fa377c8085f15d19a558cdb99372dc2d8c5 80280 apt-cdrom-setup_0.45_all.udeb Checksums-Sha256: a4d477953b1b1c79bb4802b9ee6ca3cf5f1ec954a1ce18f6301fbefc36c2db95 917 apt-setup_0.45.dsc 43837ec55e49d217ca44b7345d77ce41617684910872cc2997a986a56f474b17 234055 apt-setup_0.45.tar.gz 9c0025ec36f7acd64b89a0efa6554704111d684a42a27db3acd07d7e61532e29 45724 apt-setup-udeb_0.45_all.udeb 599122c3fa7b9541c6314b3745508f7ca0fb7f1b6e7aba220776b1228b71b5d9 63340 apt-mirror-setup_0.45_all.udeb 486530d1d081606750a478c4609c03f5a0e65708d1f621f178452c052f543d56 80280 apt-cdrom-setup_0.45_all.udeb Files: 7dd1da75f7bda3f3a4d0cbe945a6f4fb 917 debian-installer extra apt-setup_0.45.dsc cfa08ca2f67ac814e2d40ca156e1c860 234055 debian-installer extra apt-setup_0.45.tar.gz eed04b6942b8bc9d36898c7af72ec07d 45724 debian-installer standard apt-setup-udeb_0.45_all.udeb 6e9d199fc7a5df863193898b97472271 63340 debian-installer extra apt-mirror-setup_0.45_all.udeb 6f67bdf5c4c532478f0cfc269e600672 80280 debian-installer extra apt-cdrom-setup_0.45_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkuavKgACgkQgm/Kwh6ICoQmdwCeIqBhoZelxdoHjfOIbMZXUIXx 8s4An3ZCh9l96yU9uXC5cD7mw7zZ4/RA =2vty -END PGP SIGNATURE- Accepted: apt-cdrom-setup_0.45_all.udeb to main/a/apt-setup/apt-cdrom-setup_0.45_all.udeb apt-mirror-setup_0.45_all.udeb to main/a/apt-setup/apt-mirror-setup_0.45_all.udeb apt-setup-udeb_0.45_all.udeb to main/a/apt-setup/apt-setup-udeb_0.45_all.udeb apt-setup_0.45.dsc to main/a/apt-setup/apt-setup_0.45.dsc apt-setup_0.45.tar.gz to main/a/apt-setup/apt-setup_0.45.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1nqdam-0003zu...@ries.debian.org
Accepted base-installer 1.106 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 12 Mar 2010 22:48:17 +0100 Source: base-installer Binary: base-installer bootstrap-base Architecture: source all amd64 Version: 1.106 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Frans Pop f...@debian.org Description: base-installer - base system installation framework (udeb) bootstrap-base - Install the base system (udeb) Changes: base-installer (1.106) unstable; urgency=low . * Define the mount point for apt-cdrom in target as /media/cdrom instead of /cdrom as the latter was deprecated back in Etch. . [ Updated translations ] * Hebrew (he.po) by Omer Zak * Slovenian (sl.po) by Vanja Cvelbar Checksums-Sha1: a9614f585b9b4936f69c7bf1d83987d2fda8c35d 1095 base-installer_1.106.dsc 878a419886321d6e727ce69df2f108e2bb3932c3 269101 base-installer_1.106.tar.gz 82136f63087fdb4ac132b0f50ed48c85472c5479 41916 base-installer_1.106_all.udeb 0979e4299f8d084fe0d71240ec42ed199321e039 166160 bootstrap-base_1.106_amd64.udeb Checksums-Sha256: 6b2a9d048822cd38671dfaa342b11bfbafa54030355b1b5cfad292081f5e3ffa 1095 base-installer_1.106.dsc 52cbe8e934926cfdc81abb5117781997dfbb64e26dfc7a66a4e66e128d22baeb 269101 base-installer_1.106.tar.gz f93c0c2817b6e4aef314ae78fbf9f5894b49f2acdf449f6e948803d1204ffc89 41916 base-installer_1.106_all.udeb ea4bc72c7c6ec46c0e364a1226034a9694f330a537d4c729eca6e81e900e5323 166160 bootstrap-base_1.106_amd64.udeb Files: 6ea656207de4872e85b5ac68faa0250d 1095 debian-installer required base-installer_1.106.dsc 5d6844f8dcbeef01d97fa4226b545a3c 269101 debian-installer required base-installer_1.106.tar.gz 78124a85bd9acb79cdee2eb64f8cdece 41916 debian-installer required base-installer_1.106_all.udeb fdb072fdef17b91406d4d2b62ee8a24d 166160 debian-installer required bootstrap-base_1.106_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkuavKgACgkQgm/Kwh6ICoROUgCfbGM1/2fY2npK/AyQ0FJeLJe8 A8wAn0rS9UCiGVtQdW4mRwzTQU3nsIf9 =J+fL -END PGP SIGNATURE- Accepted: base-installer_1.106.dsc to main/b/base-installer/base-installer_1.106.dsc base-installer_1.106.tar.gz to main/b/base-installer/base-installer_1.106.tar.gz base-installer_1.106_all.udeb to main/b/base-installer/base-installer_1.106_all.udeb bootstrap-base_1.106_amd64.udeb to main/b/base-installer/bootstrap-base_1.106_amd64.udeb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1nqdad-00042x...@ries.debian.org
Bug#571939: [sparc] segfault when quitting aptitude
On Friday 12 March 2010, Daniel Burrows wrote: On Sun, Feb 28, 2010 at 01:54:31PM +0100, Frans Pop f...@debian.org was heard to say: aptitude runs fine on my sparc64 box for upgrading and installing packages, but segfaults always when I quit the application. Does this happen just with the 0.6 series of aptitude, or did you see this in past versions too? It's a box I don't boot that often but I've never seen the segfaults before, certainly not with 0.4.11. I noticed it after the last upgrade. Here's the upgrade history (from dpkg logs): 2008-07-02 23:06:41 status installed aptitude 0.4.11.7-1 2008-09-23 05:10:38 status installed aptitude 0.4.11.10-1 2008-11-15 21:44:19 status installed aptitude 0.4.11.10-1lenny1.1 2008-12-02 21:49:19 status installed aptitude 0.4.11.11-1 2009-06-13 17:06:34 status installed aptitude 0.4.11.11-1+b1 2009-08-29 01:15:58 status installed aptitude 0.4.11.11-1+b2 2009-12-25 20:53:11 status installed aptitude 0.6.1.3-3 2010-01-25 16:29:00 status installed aptitude 0.6.1.5-1 2010-02-28 12:18:41 status installed aptitude 0.6.1.5-2 I'm not sure if 0.6.1.3-3 was affected or not. If you like I can test that, and also other versions from snapshot.d.o too if needed. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571939: [sparc] segfault when quitting aptitude
On Friday 12 March 2010, Frans Pop wrote: It's a box I don't boot that often but I've never seen the segfaults before, certainly not with 0.4.11. I noticed it after the last upgrade. Just got another segfault; this time after the second go for the purge of a single package (with the download tab open). After restarting aptitude the purge and a display of a changelog succeeded, but on quit I got a segfault again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571939: [sparc] segfault when quitting aptitude
One more clue. After the segfault I get a shell prompt. But the screen is not cleared and the mouse is in a weird state. Seems as if the mouse is still half captured. Any button action results in output at the prompt; 'reset' clears it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Joey Hess wrote: I don't think it particularly matters if there's a stray /media/cdrom. I could always plug in a usb cd drive. OK. Let's give it a try as it is now then. I will uploaded base-installer and apt-setup to start with. Colin, At the risk of invoking your ire, I have reverted your additional change in apt-setup for now. The reason is explained in the commit message: Reason for the revert is that the changes are not needed now that APT has been reconfigured to use media/cdrom in target. The change was also incomplete as apt-cdrom is also called from other places than 40cdrom. It may be worth reintroducing this change later, but I prefer to implement and test the switch from /cdrom to /media/cdrom without it first. The other places where apt-cdrom is called are the 41cdset generator and load-install-cd. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: initrd.img - creating a init ramdisk by hand
On Friday 12 March 2010, Richard Lamboj wrote: i need to create an init ramdisk for booting over the network. I'am working on an Project to manage Servers, Vservers, Clients and Services over the Network and one part is an init ramdisk wich will install disk images on the clients to place linux and windows installs on Desktop Systems. This mailing list is about development of the Debian Installation system and your question does not really seem related to that. A better place to ask would have been the debian-user list. I have tried ext2 Images and cpio Images. They don't work. Could not exec init or linuxrc. So it would by nice if someone could give me informations about boulding an ramdisk. That said, have a look at http://svn.debian.org/wsvn/d-i/trunk/installer/build/Makefile Look for # Create a compressed image of the root filesystem. You'll find examples of commands to create initrds using various formats. The $(x) macros that are used are defined near the beginning of the same file. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003122211.24422.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Joey Hess wrote: I don't think it particularly matters if there's a stray /media/cdrom. I could always plug in a usb cd drive. OK. Let's give it a try as it is now then. I will uploaded base-installer and apt-setup to start with. Colin, At the risk of invoking your ire, I have reverted your additional change in apt-setup for now. The reason is explained in the commit message: Reason for the revert is that the changes are not needed now that APT has been reconfigured to use media/cdrom in target. The change was also incomplete as apt-cdrom is also called from other places than 40cdrom. It may be worth reintroducing this change later, but I prefer to implement and test the switch from /cdrom to /media/cdrom without it first. The other places where apt-cdrom is called are the 41cdset generator and load-install-cd. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003122313.05927.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Wednesday 10 March 2010, maximilian attems wrote: applications that still rely on a toplevel /cdrom are likely very buggy and should be kicked. nuke etch compatibility link. Except that D-I itself still uses it :-/ We'll need to change that first... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
tag 573252 pending thanks On Thursday 11 March 2010, Frans Pop wrote: On Wednesday 10 March 2010, maximilian attems wrote: applications that still rely on a toplevel /cdrom are likely very buggy and should be kicked. nuke etch compatibility link. Except that D-I itself still uses it :-/ Well, the only usage left were some no longer needed umount statements, so I've simply cleaned those up as well. Committed in SVN. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, you wrote: /cdrom was only obsoleted in etch by a combination of prayer and wishful thinking. apt-cdrom still relied on it until very recently, when Michael Vogt did some work on it. Hmm. It could be that back then only the automatic unmounting was fixed. I'll test this. Perhaps I have missed something, but Frans' changes seem quite incomplete to me. You're partially correct. base-installer bind-mounts /target/cdrom, and No, we no longer bind mount /target/cdrom. We used to bind mount it permanently, but that was changed with the reintroduction of multi-cd support. Instead we always leave it up to apt-cdrom to mount/umount the CD as (and only as long as) needed. configures apt-cdrom to use it; Yes, I missed this. But we could change that to use /target/media/cdrom instead, which would be more in line with what's wanted anyway. I'll test that too. surely that needs to be adjusted if you want to do the detection dynamically there as well, and removing the umounts from most other places while keeping the mount in base-installer looks like a mistake. AFAICT removing the umounts is still correct as we never mount it. But base-installer definitely needs updating before dropping the symlink in partman-target. And if Lenny's apt-cdrom does require it, we should keep it around until Squeeze+1. Thanks, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, Colin Watson wrote: If you don't bind-mount /target/cdrom in base-installer, how do you ensure that we use the same CD for base installation as was used to boot the installer? You cannot ensure that even if you do bind mount it as the BIOS' idea of what is the first CD drive may differ from Linux' idea of what it is. AFAIK this has always been an issue and was not changed by the reintroduction of multi-CD support. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, Frans Pop wrote: No, we no longer bind mount /target/cdrom. We used to bind mount it permanently, but that was changed with the reintroduction of multi-cd support. Instead we always leave it up to apt-cdrom to mount/umount the CD as (and only as long as) needed. Oh, wait. We do still bind mount it for hd-media installs. That does need to be covered. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, you wrote: On Thursday 11 March 2010, Frans Pop wrote: No, we no longer bind mount /target/cdrom. We used to bind mount it permanently, but that was changed with the reintroduction of multi-cd support. Instead we always leave it up to apt-cdrom to mount/umount the CD as (and only as long as) needed. Oh, wait. We do still bind mount it for hd-media installs. Gah, and for CD installs, but only during base-installer. So indeed, my changes were rather hasty and incomplete. Looking for a proper solution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, Frans Pop wrote: On Thursday 11 March 2010, you wrote: On Thursday 11 March 2010, Frans Pop wrote: No, we no longer bind mount /target/cdrom. We used to bind mount it permanently, but that was changed with the reintroduction of multi-cd support. Instead we always leave it up to apt-cdrom to mount/umount the CD as (and only as long as) needed. Oh, wait. We do still bind mount it for hd-media installs. Gah, and for CD installs, but only during base-installer. I've modified base-installer to configure APT to use /media/cdrom instead of /cdrom as mount mount for apt-cdrom. I've tested with a Lenny CD that this works. AFAICT with this addition all previous changes are now valid for both CD based and hd-media installs. Thanks to Colin for setting me straight. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Joey Hess wrote: I installed the alpha from usb stick, onto a system with no cdrom drive, and a /cdrom directory (not symlink) was left behind. I have not worked out which component is responsible. /var/lib/dpkg/info/base-files.preinst has: if [ -d /cdrom ]; then touch /etc/base-files.create-cdrom fi ... ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Frans Pop wrote: On Friday 12 March 2010, Joey Hess wrote: I installed the alpha from usb stick, onto a system with no cdrom drive, and a /cdrom directory (not symlink) was left behind. I have not worked out which component is responsible. /var/lib/dpkg/info/base-files.preinst has: if [ -d /cdrom ]; then touch /etc/base-files.create-cdrom fi Eh, never mind. That's if the dir already exists. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Joey Hess wrote: I installed the alpha from usb stick, onto a system with no cdrom drive, and a /cdrom directory (not symlink) was left behind. I have not worked out which component is responsible. Duh. I looked at the code earlier today. It's base-installer of course which bind mounts the CD into target. From library.sh configure_apt(): # Let apt inside the chroot see the cdrom umount /target/media$DIRECTORY 2/dev/null || true if [ ! -e /target/media$DIRECTORY ]; then -- mkdir -p /target/media$DIRECTORY fi # The bind mount is left mounted, for future apt-install # calls to use. if ! mount -o bind $DIRECTORY /target/media$DIRECTORY; then warning failed to bind mount /target/media$DIRECTORY fi So after today's changes it will leave /media/cdrom instead of /cdrom. Guess we should remove that dir again in finish_install.d for hd_media installs? We'd need to keep an indicator that the dir was created by base-installer and not by partman. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Frans Pop wrote: On Friday 12 March 2010, Joey Hess wrote: I installed the alpha from usb stick, onto a system with no cdrom drive, and a /cdrom directory (not symlink) was left behind. I have not worked out which component is responsible. So after today's changes it will leave /media/cdrom instead of /cdrom. Guess we should remove that dir again in finish_install.d for hd_media installs? We'd need to keep an indicator that the dir was created by base-installer and not by partman. I'm not sure we should remove the dir actually. Don't we also leave the CD image as a valid source for APT [1]? And we've now configured APT to use /media/cdrom as its dir to mount CDs. Unless we want to clean up all that too, which is defensible as it's unlikely a user would think to mount the image on /media/cdrom. And we already remove netinsts from the sources.list during finish-install. [1] At least if a full CD or DVD was used which given the size of USB sticks nowadays is not impossible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573252: partman-target: stray /cdrom link useless these days
On Wednesday 10 March 2010, maximilian attems wrote: applications that still rely on a toplevel /cdrom are likely very buggy and should be kicked. nuke etch compatibility link. Except that D-I itself still uses it :-/ We'll need to change that first... -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003111742.55644.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
tag 573252 pending thanks On Thursday 11 March 2010, Frans Pop wrote: On Wednesday 10 March 2010, maximilian attems wrote: applications that still rely on a toplevel /cdrom are likely very buggy and should be kicked. nuke etch compatibility link. Except that D-I itself still uses it :-/ Well, the only usage left were some no longer needed umount statements, so I've simply cleaned those up as well. Committed in SVN. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003111809.08158.elen...@planet.nl
Re: Switching g-i from DirectFB to X11 -- specific issues/comments
On Thursday 11 March 2010, Cyril Brulebois wrote: To try and make sure I wasn't missing any occurrences, I've patched lintian and sent the preliminary patch as a bugreport against lintian: #573399. Feel free to voice in, improve the patch, etc. :) The background to this is that until Lenny 'Package-Type' did not exist as a field. During Lenny it was added by the dpkg devs without really checking with the D-I team; we never asked for it. IIRC they initially even made the XC- field obsolete (it resulted in warnings during builds), but that was reverted after some pressure by us. We could switch to 'Package-Type' if dpkg would omit it from the control file included in the package, but (again IIRC) the dpkg-devs were not in favor of that. The difference of opinion was never really resolved. It may also be that, for example for tdebs, the field _will_ be wanted in the control file in cases other than udebs. So I'm not really sure if a Lintian check really is the right solution to the issue. But it does reflect current practice, so I personally don't mind either. You could consider tightening the check to match only for udebs. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003111824.40742.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, you wrote: /cdrom was only obsoleted in etch by a combination of prayer and wishful thinking. apt-cdrom still relied on it until very recently, when Michael Vogt did some work on it. Hmm. It could be that back then only the automatic unmounting was fixed. I'll test this. Perhaps I have missed something, but Frans' changes seem quite incomplete to me. You're partially correct. base-installer bind-mounts /target/cdrom, and No, we no longer bind mount /target/cdrom. We used to bind mount it permanently, but that was changed with the reintroduction of multi-cd support. Instead we always leave it up to apt-cdrom to mount/umount the CD as (and only as long as) needed. configures apt-cdrom to use it; Yes, I missed this. But we could change that to use /target/media/cdrom instead, which would be more in line with what's wanted anyway. I'll test that too. surely that needs to be adjusted if you want to do the detection dynamically there as well, and removing the umounts from most other places while keeping the mount in base-installer looks like a mistake. AFAICT removing the umounts is still correct as we never mount it. But base-installer definitely needs updating before dropping the symlink in partman-target. And if Lenny's apt-cdrom does require it, we should keep it around until Squeeze+1. Thanks, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003111901.52427.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, Colin Watson wrote: If you don't bind-mount /target/cdrom in base-installer, how do you ensure that we use the same CD for base installation as was used to boot the installer? You cannot ensure that even if you do bind mount it as the BIOS' idea of what is the first CD drive may differ from Linux' idea of what it is. AFAIK this has always been an issue and was not changed by the reintroduction of multi-CD support. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003111907.38264.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, Frans Pop wrote: No, we no longer bind mount /target/cdrom. We used to bind mount it permanently, but that was changed with the reintroduction of multi-cd support. Instead we always leave it up to apt-cdrom to mount/umount the CD as (and only as long as) needed. Oh, wait. We do still bind mount it for hd-media installs. That does need to be covered. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003111942.01145.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, you wrote: On Thursday 11 March 2010, Frans Pop wrote: No, we no longer bind mount /target/cdrom. We used to bind mount it permanently, but that was changed with the reintroduction of multi-cd support. Instead we always leave it up to apt-cdrom to mount/umount the CD as (and only as long as) needed. Oh, wait. We do still bind mount it for hd-media installs. Gah, and for CD installs, but only during base-installer. So indeed, my changes were rather hasty and incomplete. Looking for a proper solution. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003111949.00488.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Thursday 11 March 2010, Frans Pop wrote: On Thursday 11 March 2010, you wrote: On Thursday 11 March 2010, Frans Pop wrote: No, we no longer bind mount /target/cdrom. We used to bind mount it permanently, but that was changed with the reintroduction of multi-cd support. Instead we always leave it up to apt-cdrom to mount/umount the CD as (and only as long as) needed. Oh, wait. We do still bind mount it for hd-media installs. Gah, and for CD installs, but only during base-installer. I've modified base-installer to configure APT to use /media/cdrom instead of /cdrom as mount mount for apt-cdrom. I've tested with a Lenny CD that this works. AFAICT with this addition all previous changes are now valid for both CD based and hd-media installs. Thanks to Colin for setting me straight. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003112105.30348.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Joey Hess wrote: I installed the alpha from usb stick, onto a system with no cdrom drive, and a /cdrom directory (not symlink) was left behind. I have not worked out which component is responsible. /var/lib/dpkg/info/base-files.preinst has: if [ -d /cdrom ]; then touch /etc/base-files.create-cdrom fi ... ? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003120102.23639.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Frans Pop wrote: On Friday 12 March 2010, Joey Hess wrote: I installed the alpha from usb stick, onto a system with no cdrom drive, and a /cdrom directory (not symlink) was left behind. I have not worked out which component is responsible. /var/lib/dpkg/info/base-files.preinst has: if [ -d /cdrom ]; then touch /etc/base-files.create-cdrom fi Eh, never mind. That's if the dir already exists. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003120106.28794.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Joey Hess wrote: I installed the alpha from usb stick, onto a system with no cdrom drive, and a /cdrom directory (not symlink) was left behind. I have not worked out which component is responsible. Duh. I looked at the code earlier today. It's base-installer of course which bind mounts the CD into target. From library.sh configure_apt(): # Let apt inside the chroot see the cdrom umount /target/media$DIRECTORY 2/dev/null || true if [ ! -e /target/media$DIRECTORY ]; then -- mkdir -p /target/media$DIRECTORY fi # The bind mount is left mounted, for future apt-install # calls to use. if ! mount -o bind $DIRECTORY /target/media$DIRECTORY; then warning failed to bind mount /target/media$DIRECTORY fi So after today's changes it will leave /media/cdrom instead of /cdrom. Guess we should remove that dir again in finish_install.d for hd_media installs? We'd need to keep an indicator that the dir was created by base-installer and not by partman. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003120203.01457.elen...@planet.nl
Bug#573252: partman-target: stray /cdrom link useless these days
On Friday 12 March 2010, Frans Pop wrote: On Friday 12 March 2010, Joey Hess wrote: I installed the alpha from usb stick, onto a system with no cdrom drive, and a /cdrom directory (not symlink) was left behind. I have not worked out which component is responsible. So after today's changes it will leave /media/cdrom instead of /cdrom. Guess we should remove that dir again in finish_install.d for hd_media installs? We'd need to keep an indicator that the dir was created by base-installer and not by partman. I'm not sure we should remove the dir actually. Don't we also leave the CD image as a valid source for APT [1]? And we've now configured APT to use /media/cdrom as its dir to mount CDs. Unless we want to clean up all that too, which is defensible as it's unlikely a user would think to mount the image on /media/cdrom. And we already remove netinsts from the sources.list during finish-install. [1] At least if a full CD or DVD was used which given the size of USB sticks nowadays is not impossible. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003120746.02865.elen...@planet.nl
Bug#550961: small patch ... actually
On Wednesday 10 March 2010, Pietro Abate wrote: setting APT_CONFIG is the way to go. No need to modify debtree... APT_CONFIG=apt.conf apt-get update APT_CONFIG=apt.conf debtree dpkg Thanks for your info. I think we should keep the BR open until this has been documented, for example in a README.Debian. I suspect that it may not work correctly for '-b --arch=all' (as that uses apt-cache instead of the apt database). I'll have to test that. I'll give the recipe you gave in your previous mail a try and then work something out. If I have any questions I'll get back to you. Another question could be: does this also allow to make graphs for other architectures? For example, create a graph for arm on an i386 host. I guess that as long as you copy Packages and Sources files (instead of using a sources.list) it could work. APT could have internal checks against the current arch. But possibly setting APT::Architecture would fix that. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573355: hercules: Update of documentation
Package: hercules Version: 3.06-1.3 Severity: wishlist The herculeans have released 3.07. It would be great to have that in Squeeze. I would suggest updating some of the documentation. The giving_s_390_a_try.html is outdated; I'd drop it and instead add the following to the README.Debian. snip Installing Debian on an emulated S/390 system - A good introduction on how to install Debian on s390 using hercules has been written by Josef Sipek: http://www.josefsipek.net/docs/s390-linux/hercules-s390.html. Note that Debian Squeeze and later no longer support running in 31-bit mode as only 64-bit (s390x) kernels are available. This means that in your hercules config ARCHMODE must be set to 'ESAME' or 'z/Arch'. /snip Also, there are some stray spaces in this line for util/dasdlist.1: +System/370, ESA/390, and z/Architecture Emulator\fP available in Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: spi_s3c64xx.c - plat/spi.h: No such file or directory
On Wednesday 10 March 2010, jassi brar wrote: On Wed, Mar 10, 2010 at 5:11 PM, Frans Pop elen...@planet.nl wrote: When building with an SMDK6410 config with CONFIG_SPI_S3C64XX=m I get the following compilation error: CC [M] drivers/spi/spi_s3c64xx.o drivers/spi/spi_s3c64xx.c:31:22: error: plat/spi.h: No such file or directory This is with Ben Dooks' next-samsung branch merged into 2.6.33. There has recently been a major shuffle of headers in plat and mach, please test against some unmodified kernel and let me know which one if the error still occurs. Maybe you(or I) can submit a fix upstream. The same error occurs with vanilla 2.6.33. Cheers, FJP -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: spi_s3c64xx.c - plat/spi.h: No such file or directory
On Thursday 11 March 2010, jassi brar wrote: On Thu, Mar 11, 2010 at 1:17 AM, Frans Pop elen...@planet.nl wrote: On Wednesday 10 March 2010, jassi brar wrote: On Wed, Mar 10, 2010 at 5:11 PM, Frans Pop elen...@planet.nl wrote: When building with an SMDK6410 config with CONFIG_SPI_S3C64XX=m I get the following compilation error: CC [M] drivers/spi/spi_s3c64xx.o drivers/spi/spi_s3c64xx.c:31:22: error: plat/spi.h: No such file or directory This is with Ben Dooks' next-samsung branch merged into 2.6.33. There has recently been a major shuffle of headers in plat and mach, please test against some unmodified kernel and let me know which one if the error still occurs. Maybe you(or I) can submit a fix upstream. The same error occurs with vanilla 2.6.33. yeah, i remember. that was due to driver being accepted in SPI tree but plat headers put on hold in S3C ARCH tree. The patches are already queued on Ben Dooks' and Grant Likely's tree. Which branch in Ben's tree would that be? As mentioned above I still see the error when using his current next-samsung branch... I have not try building with Grant's tree. It would be great if someone could verify that the issue really is solved. Cheers, FJP -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: spi_s3c64xx.c - plat/spi.h: No such file or directory
On Thursday 11 March 2010, jassi brar wrote: On Thu, Mar 11, 2010 at 11:51 AM, Frans Pop elen...@planet.nl wrote: On Thursday 11 March 2010, jassi brar wrote: On Thu, Mar 11, 2010 at 1:17 AM, Frans Pop elen...@planet.nl wrote: On Wednesday 10 March 2010, jassi brar wrote: On Wed, Mar 10, 2010 at 5:11 PM, Frans Pop elen...@planet.nl wrote: When building with an SMDK6410 config with CONFIG_SPI_S3C64XX=m I get the following compilation error: CC [M] drivers/spi/spi_s3c64xx.o drivers/spi/spi_s3c64xx.c:31:22: error: plat/spi.h: No such file or directory This is with Ben Dooks' next-samsung branch merged into 2.6.33. There has recently been a major shuffle of headers in plat and mach, please test against some unmodified kernel and let me know which one if the error still occurs. Maybe you(or I) can submit a fix upstream. The same error occurs with vanilla 2.6.33. yeah, i remember. that was due to driver being accepted in SPI tree but plat headers put on hold in S3C ARCH tree. The patches are already queued on Ben Dooks' and Grant Likely's tree. Which branch in Ben's tree would that be? As mentioned above I still see the error when using his current next-samsung branch... I have not try building with Grant's tree. try for-rmk/samsung6 That branch is identical to next-samsung... -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: spi_s3c64xx.c - plat/spi.h: No such file or directory
On Thursday 11 March 2010, jassi brar wrote: Then you need patches from Grant Likely's tree. The driver now includes a new header plat/s3c64xxx-spi.h instead Check http://git.secretlab.ca/?p=linux-2.6.git;a=summary branch 'next' or 'next-spi' Yep, that does work! Thanks a lot for your patience. Cheers, FJP -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: testing firmware image out of date
On Tuesday 09 March 2010, Joey Hess wrote: The firmware bundle at http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/testing/c urrent/ contains firmware files from lenny. I'm fairly sure that testing did not have such old versions of when the file was built in February, so is it building against stable? No, the build is correct. Just the symlink for testing needed updating from lenny to squeeze. Done. Cheers, FJP -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003092201.45797.elen...@planet.nl
Accepted partman-crypto 42 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 09 Mar 2010 21:32:36 +0100 Source: partman-crypto Binary: partman-crypto partman-crypto-dm partman-crypto-loop Architecture: source amd64 all Version: 42 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Frans Pop f...@debian.org Description: partman-crypto - Add to partman support for block device encryption (udeb) partman-crypto-dm - Add to partman support for dm-crypt encryption (udeb) partman-crypto-loop - Add to partman support for loop-AES encryption (udeb) Changes: partman-crypto (42) unstable; urgency=low . * Actually install the post-base-installer hook script. . [ Updated translations ] * Slovenian (sl.po) by Vanja Cvelbar Checksums-Sha1: fceaeb920fe156dfe621260b1613be005b07e623 903 partman-crypto_42.dsc 31d31f470c4363fda9008729dbaface088a25df7 300866 partman-crypto_42.tar.gz 803e01456c573e1393dcb5a5a2dbe464a1c10e79 241494 partman-crypto_42_amd64.udeb 6d3c351c9aed966b9a52c9141f7d620068f0d1c5 1648 partman-crypto-dm_42_all.udeb 12b9429b6a89a4d25a0548f8e756a85015bd9986 1216 partman-crypto-loop_42_all.udeb Checksums-Sha256: 90734ed842241ded186763f761fa40e8a838ab9c90fbf57f8788c30ee5b1055f 903 partman-crypto_42.dsc 736ffde20132988a376e2bb64918d3a7c2d8450b19adbe9f3448389ba072b4a2 300866 partman-crypto_42.tar.gz c57f5ab9db8fa884f48a93e2f211db08711e52e1ea260eced9fbb655e111cd3d 241494 partman-crypto_42_amd64.udeb daae37a1903bd5ffa8a5097eec25139f457fa62887e4cd57045f0d66183d3a65 1648 partman-crypto-dm_42_all.udeb dc5ff77157037f57c9eb4e51e2a3446fe9e70b8b8c4e05bce8beb7f34160e14c 1216 partman-crypto-loop_42_all.udeb Files: f6ef0ab7694dc4a82b3fcdee293961df 903 debian-installer optional partman-crypto_42.dsc f9432ca2d31ebe55ac976c751980f587 300866 debian-installer optional partman-crypto_42.tar.gz d2e5f4ea51378b6733392af80af75236 241494 debian-installer optional partman-crypto_42_amd64.udeb 3fcd464ce7c17fa8e3e1044736f786d6 1648 debian-installer optional partman-crypto-dm_42_all.udeb 5bd91f924421692e0c24f3262284362f 1216 debian-installer optional partman-crypto-loop_42_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkuWsOEACgkQgm/Kwh6ICoQ9TACfdED1E7661EgtvAGvq6Su/y5T rZEAoNmME6gWkdfNwlz3L1Aqd1qOoFud =Opgh -END PGP SIGNATURE- Accepted: partman-crypto-dm_42_all.udeb to main/p/partman-crypto/partman-crypto-dm_42_all.udeb partman-crypto-loop_42_all.udeb to main/p/partman-crypto/partman-crypto-loop_42_all.udeb partman-crypto_42.dsc to main/p/partman-crypto/partman-crypto_42.dsc partman-crypto_42.tar.gz to main/p/partman-crypto/partman-crypto_42.tar.gz partman-crypto_42_amd64.udeb to main/p/partman-crypto/partman-crypto_42_amd64.udeb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1np7s2-be...@ries.debian.org
Re: Missing loop-aes-modules-${current:kernel}-amd64-di?
On Tuesday 09 March 2010, Cyril Brulebois wrote: Also: Is there any way to make sure there's no (kernel) version mismatch between *-modules packages in the future? That still stands. Problem is that if we ask to remove the loop-aes udebs for .30 for unstable (which is the only real option ATM), they would also be removed from testing. That would break loop-aes support for netboot installs and weekly built CDs based on the alpha1 release. I would personally prefer the problem to remain for daily images over breaking things for the alpha1 release. The crypto people will hopefully come up with some solution for loop-aes support with .32 kernels before Squeeze. But if there is no solution before the next D-I release, we will have to ask for removal of the loop-aes udebs when preparing that release. Note that Luks based encryption is not affected. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003091806.50485.elen...@planet.nl
Re: Missing loop-aes-modules-${current:kernel}-amd64-di?
On Tuesday 09 March 2010, Cyril Brulebois wrote: Using my d-i usb stick, I was hoping to recover from it by mounting the crypted lvm through cryptsetup luksOpen … (which a quick google suggests), but unfortunately I end up with cryptsetup telling me to check for missing aes support in the kernel. udpkg -i \ cdrom/pool/main/l/linux-modules-di-amd64-2.6/loop-aes-modules* On more careful reading this doesn't quite make sense to me. AFAIK luksOpen does not use loop-aes. It uses dm-crypt instead. It may require the AES crypto module, but that's unrelated to loop-aes. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003092005.42652.elen...@planet.nl
Re: Missing loop-aes-modules-${current:kernel}-amd64-di?
On Tuesday 09 March 2010, Frans Pop wrote: On Tuesday 09 March 2010, Cyril Brulebois wrote: Using my d-i usb stick, I was hoping to recover from it by mounting the crypted lvm through cryptsetup luksOpen … (which a quick google suggests), but unfortunately I end up with cryptsetup telling me to check for missing aes support in the kernel. udpkg -i \ cdrom/pool/main/l/linux-modules-di-amd64-2.6/loop-aes-modules* On more careful reading this doesn't quite make sense to me. AFAIK luksOpen does not use loop-aes. It uses dm-crypt instead. It may require the AES crypto module, but that's unrelated to loop-aes. So what you appear to be missing is aes_generic.ko. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003092007.53858.elen...@planet.nl
Re: [PATCH] Switch grub-installer to grub-probe
On Tuesday 09 March 2010, Colin Watson wrote: Indeed, what he said. grub-probe is in grub-common exactly so that both grub-legacy and grub2 can use it, and note that there's a bit of code in my patch to handle the different partition number offset. As long as there won't be regressions for special cases when grub-legacy is used because grub-probe either does not handle them or handles them differently I have no objection. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003092020.13055.elen...@planet.nl
Re: Missing loop-aes-modules-${current:kernel}-amd64-di?
On Tuesday 09 March 2010, Cyril Brulebois wrote: Using my d-i usb stick, I was hoping to recover from it by mounting the crypted lvm through cryptsetup luksOpen … (which a quick google suggests), but unfortunately I end up with cryptsetup telling me to check for missing aes support in the kernel. Sorry for the separate replies... For rescue help with encrypted LVM, see: http://wiki.debian.org/DebianInstaller/Rescue/Crypto -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003092021.54442.elen...@planet.nl
Re: Missing loop-aes-modules-${current:kernel}-amd64-di?
On Tuesday 09 March 2010, Cyril Brulebois wrote: The outcome was quite surprising, but explained a lot: cryptsetup wasn't actually installed on the target system… Did you install the system using a daily image? If so, that's what you get from using udebs from unstable ;-) Fixed. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003092133.08653.elen...@planet.nl
Multipath support in Squeeze
Hi Guido, What's the status of multipath support in Squeeze? Especially given the switch to grub2. Could you perhaps update the wiki page [1]? It currently refers to loads of closed bug reports, which only makes one wonder. If possible, please clarify the status both for Lenny and for Squeeze. TIA. Cheers, FJP [1] http://wiki.debian.org/DebianInstaller/MultipathSupport signature.asc Description: This is a digitally signed message part.
