Re: Proposal to add patches to netcfg (#682737)
Sorina - Gabriela Sandu wrote: For that matter, I would like to propose a patch to add support for netcfg to write a Network Manager config file and modify the finish-install script so that it copies to target either the nm-config file or a full /e/n/i config, according to a reasonable default and user's choice. This also contain a new question, netcfg/target_network_config, which is asked with a medium priority in finish-install I notice this links network-manager to libuuid. Which is an amazingly bloated 124k here. That's being added to the d-i boot image. AFAICS, the network-manager configuration saves the user from having to re-select the wireless network, and re-enter any passphrase that they already entered once in d-i. This seems a relatively minor improvement, after all users of mobile computers rather frequently have to pick wifi networks and enter passphrases. Even without the libuuid bloat (which I'm sure could be worked around somehow.. for example c32468fe-00d6-11e2-8510-97e4f3a3dcc1 is a perfectly fine uuid I just generated that d-i is free to reuse ;) .. I wonder if tying d-i so tightly to network-manager configuration file format is worth saving the user that step. Even with a spec, this desktop stuff is a pile of sand, it changes at upstream's whim; do we really want d-i tied to it? I also doubt that the medium priority debconf question adds much value to the installer. Especially since it also increases the size of the boot media. Who is going to pick something other than the default? Only users proficient enough to easily edit /etc/network/interfaces after the install, and who are apparently already planning to do some form of sysadmin work after the install. As to the code, I haven't looked at it in detail, but this seems a needlessly roundabout way to get the network-manager config file's mode locked down: http://anonscm.debian.org/gitweb/?p=d-i/netcfg.git;a=commitdiff;h=093e22856d04d4d93c08ae402874ac5ef59d2fb3;hp=1d698b6eeb5a8ab6120adc7389a540dd04e6aa47 In particular, it fails open -- if the installer is turned off at just the wrong point, the system will boot up with a password in the file and the file mode 644. It would be much more sensible to create the file with mode 600 from the beginning. AFAICS, network-manager uses mode 600 for all connection files, even those without passwords. This makes me wonder if it has good reasons for doing so. Perhaps it considers other information in the files security sensative. Perhaps it sometimes modifies the files to add security sensative information, without changing their permissions. (I'm really happy to see this bug be addressed BTW, although it's a real shame it has to be addressed on the d-i side when it could just be fixed in network-manager..) -- see shy jo signature.asc Description: Digital signature
Re: Proposal to add patches to netcfg (#682737)
Brian Potkin wrote: I realise a default is only a default and the selection can be changed, but I'm puzzled by the third option. Why treat a wireless install differently from a wired install? It would expected that a user who has chosen not to use a wired connection would still want connectivity after booting into into the new system, On the one hand we have people installing a fixed machine that has only wifi connectivity. These do exist -- two examples I'm familiar with are a friend whose workplace uses wifi for industrial controllers on the factory floor, and a parent whose desktop machine is an eeePC with a wifi antenna. On the other hand, we have users who chose not to install a desktop environment but want their machine to migrate between networks when it's moved. These users are going to need to do some form of sysadmin work post-install, whether it's installing a desktop environment and wicd, or editing /etc/network/interfaces on each fresh network, or bringing up wifi connections by hand. So I can't see locking a default into /etc/network/interfaces causing them much bother. -- see shy jo signature.asc Description: Digital signature
Re: Proposal to add patches to netcfg (#682737)
Joey Hess wrote: I notice this links network-manager to libuuid. Which is an amazingly Of couse I meant it links netcfg to libuuid.. -- see shy jo signature.asc Description: Digital signature
Bug#687804: installation-reports: users are not able to review external documentation while stuck in the installer
Richard Owlett wrote: Should one not be able to switch out of the installation process and into a browser (2 are already included) to search out answers? One should, but as d-i on the live CD is currently implemented, one cannot. d-i runs as a fullscreen window, and I couldn't see any easily-discoverable way to switch out of it to try other programs the one time I briefly tried using d-i from a live CD (pretty good newbie facimile ;). That is a legitimate bug, I think. -- see shy jo signature.asc Description: Digital signature
Re: Amending task-xfce-desktop (was: Bug#686468: [wheezy] [amd64] [daily 20120831] Fujitsu Lifebook AH532 installation report)
Karsten Merker wrote: A possible solution would be to add a recommends on gstreamer0.10-alsa to task-xfce-desktop, so that it gets pulled in during the system installation while not fiddling with the xfce4-mixer dependencies which are correct from the package point of view. What do you think about that? I agree, except I don't think the dependencies are correct. Fixing this in tasksel is just a workaround. -- see shy jo signature.asc Description: Digital signature
Bug#686097: understanding/contributing to partman-btrfs
Daniel Pocock wrote: I've described such a solution in the bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686097 If you think it is sensible (or if something looks obviously silly), could you comment on it? I will hopefully have more time next week to play with it, but I'll let it sit there for a few days to see if anyone has comments about it. I don't know if that's worth it, it'll be a feature that entirely lacks discoverability for users. Anything more comprehensive than what I've described would require UI changes (e.g. prompting user for RAID level) Of course, d-i already knows how to promt the user for the RAID level -- when setting up normal software RAID. Finding a way to make partman-md also support btrfs raid seems like a nice approach, but I don't know how it would work either in the UI or internally. -- see shy jo signature.asc Description: Digital signature
Re: Upcoming d-i beta2, round 2
Cyril Brulebois wrote: please find below a number of unblock/unblock-udeb requests I'm mostly OK with as far as d-i is concerned. I added some comments so that one can grasp what impact this or that change has; some of them are marked “KiBi-upload”s, basically due to some needed, tiny fix-ups (e.g. fixes for syntax errors in shell scripts, or re-uploading without files from git checkouts). It would be nice if someone could check nothing broken slipped in for the ones marked as such; others should be OK to copy/paste in someone's hints file, but I'm OK with some other eyes going over those diffs. ;) Please don't forget tasksel 3.12. -- see shy jo signature.asc Description: Digital signature
Bug#685756: apt-xapian-index makes 256 MB RAM laptop very unresponsive
Bertil wrote: (i) Debian installer: In the installer task (Debian Desktop), one can consider to exclude the package as default. This is difficult to do while aptitude Recommends it. Although the installer has stopped using aptitude in some places, it seems likely to remain installed by default. (ii) apt-xapian-index install: In the 'Setting up apt-xapian-index', do not automatically start the background task ..rebuilding index.. since the processor will shuffling data between physical memory and swap and not finish the task. (iii) apt-xapian-index: The program could check for sufficient memory and not start the rebuild task if memory low or should not run at all. I guess I'll reassign to apt-xapian-index. -- see shy jo signature.asc Description: Digital signature
Re: [EFI] allow use of elilo on amd64/i386 EFI machines?
Steve McIntyre wrote: As I've just blogged, I've got a second alpha CD released with EFI support, this time using grub-efi by default. The first release used elilo only, but I think grub is preferred. So, my question is: should we follow existing x86 convention and allow users a choice of bootloader (grub-efi/elilo like grub/lilo for BIOS boot), or should we just offer grub-efi? Both work OK, but grub-efi is a bit more capable IMHO. If we *do* want to support elilo too, we'll need small patches applying to both elilo and elilo-installer (see attached for what I have so far). Talking of elilo, I also found #685186 in my testing... I'd say we still allow installing lilo due to a combination of inertia and possibly it supporting some configurations that grub does not. If these reasons don't apply for EFI, simplicity rules. -- see shy jo signature.asc Description: Digital signature
Re: [EFI] libdebian-installer: add efi subarch for amd64 and i386
Steve McIntyre wrote:
Looking through the Ubuntu version of debian-installer, I can see that
Colin and I independently came up with nigh-on exactly the same way to
deal with EFI systems, using a subarch to identify them. We've
differed very slightly in terms of the the source code in
libdebian-installer for checking for /sys/firmware/efi, but the effect
is the same. Here's my diff.
This patch doesn't apply cleanly to current git, both hunks conflect.
Perhaps you could rebase on current git head and use git format-patch?
+static int is_efi(void)
+{
+ int ret = access(/sys/firmware/efi, R_OK);
+if (ret == 0)
This appears to be some broken indentation.
--
see shy jo
signature.asc
Description: Digital signature
Bug#684128: PATCH: choice of binary or decimal disk storage units is runtime-configurable
ian_br...@fastmail.net wrote:
+decimal_units=(1 1000 100 10 1) # (10^3)^{0,1,2,3,4}
I hate to bring this news, but this cannot be used in the installer, because
shell arrays are a bashism, and the installer uses busybox sh.
joey@gnu:~busybox sh
BusyBox v1.20.2 (Debian 1:1.20.0-6) built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ $ decimal_units=(1 1000 100 10 1)
sh: syntax error: unexpected (
FWIW, it is possible, though painful to emulate shell arrays using eval,
or other tricks.
For example:
decimal_units_0=1
decimal_units_1=1000
index=1
eval echo \$decimal_units_$index
--
see shy jo
signature.asc
Description: Digital signature
Bug#684128: src:debian-installer: allow use of binary units in disk partitioner
Christian PERRIER wrote: This issue will have to be worked on for jessie, not for wheezy. Hopefully someone will come with a patch (I somehow doubt it as I think that only incredibly picky people really do care about differencesbetween MB and MiB..but, who knows?). The difference between a TB and a TiB is 93 GiB (or 99 GB). While I loathe the SI decimal units [1] displaying them is the right default, sadly. But human2longint should certianly be extended to handle the iB units. -- see shy jo [1] http://source.git-annex.branchable.com/?p=source.git;a=blob;f=Utility/DataUnits.hs signature.asc Description: Digital signature
Re: xfce as default desktop?
Fabian Greffrath wrote: I have just seen that as per commit 2a962cc6 tasksel now install xfce as default desktop instead of gnome. has this been discussed somewhere? The commit text suggests that it has not... :/ I'm offline so cannot find urls, but I belive this has been discussed plenty of times before on debian-devel and elsewhere. Of course the actual decision has not been discussed until now. -- see shy jo signature.asc Description: Digital signature
Re: Tasks and CD sizes again
Steve McIntyre wrote: I'm thinking we should possibly drop one of these deps in the loop between task-$DESKTOP-desktop and task-desktop. Joey, what do you think? I think that the dependencies need to remain circular, and as tasksel has no maintainer scripts, it avoids the well-known problems with circular dependencies. apt-get install task-desktop should install a usable desktop environment, not just an X server (with no display manager even) and a web browser apt-get install task-foo-desktop should install an X server. -- see shy jo signature.asc Description: Digital signature
Bug#637684: /target/etc/fstab stopped containing /proc
As /proc is mounted by boot scripts now, partman was changed to not put it in fstab, but this broke grub-installer, which relied on mount /proc working. I've fixed this in grub-installer. (That doesn't explain the 2011 reports of proc mounting problems, which well predate that change, but since grub-installer also explicitly mounts /proc at the start, I'll assume that also covers them.) -- see shy jo signature.asc Description: Digital signature
Bug#613430: debian-installer will not install grub bootloader on kfreebsd-amd64 system w/ a ZFS partition
Steven Chamberlain wrote: It could be that grub-installer tries to mount with '-t proc' instead of '-t linprocfs' on GNU/kFreeBSD. It did. Fixed in git. -- see shy jo signature.asc Description: Digital signature
Bug#667703: Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy)))
Filipus Klutiero wrote: I tested d-i last week and accidentally installled GNOME. This allowed me to confirm that GNOME does not pull Synaptic in testing. gnome-core depends on nautilus, which recommends synaptic. Unless such recommends are being skipped by something, it should be installed. -- see shy jo signature.asc Description: Digital signature
Re: git for beginners: checkout d-i git repo
Holger Wansing wrote: As a first step to this, I tried to checkout the git tree: following http://wiki.debian.org/DebianInstaller/CheckOut part Checkout over ssh, for developers it works so far until it came to the line with mr -p checkout Output is: ted@ibm-t60:~/deb/debian-installer/scripts$ mr -p checkout mr: Assuming /home/ted/deb/debian-installer/d-i-svn+git/debian-installer/.mrconfig is trusted. mr: For better security, you are encouraged to create ~/.mrtrust mr: and list all trusted mrconfig files in it. You're using an old mr, probably the one in squeeze. The instructions probably assume mr 1.00 or newer. -- see shy jo signature.asc Description: Digital signature
Bug#667703: Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy)))
Per Olofsson wrote: 2012-07-21 18:37, Joey Hess skrev: gnome-core depends on nautilus, which recommends synaptic. Unless such recommends are being skipped by something, it should be installed. nautilus (3.2.1-2) unstable; urgency=low ... - Drop Recommends on synaptic and app-install-data. We no longer call synaptic for mimetypes without a handler as this functionality is provided by alternatives like PackageKit or sessioninstaller now. I see.. I see this was mentioned before in this bug report, just before it got closed a month ago. Opening a new bug report is probably a good way to avoid things like this getting lost. :/ Fixed in git. -- see shy jo signature.asc Description: Digital signature
Bug#655841: data point
As another data point, I am in an airport (CLT) and had to remove gnash since it failed to display the thing needed to get on free wifi. Of course without flash the site lets you right through. -- see shy jo -- 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/20120716024311.ga1...@kitenet.net
Re: Tasksel status
Christian PERRIER wrote: And I committed in three specific branches (people/bubulle/bug-###) those where I think a review is wished. Merged those I feel comfortable with. I was not convinced by the flash thread that lightspark will be an overall improvement. -- see shy jo -- 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/20120714045645.ga32...@kitenet.net
d-i skills exchange session tomorrow
Since it only just went on the schedule, and I don't want those who requested it to miss it. Also, other people with d-i skills should come.. Noon tomorrow in the small talk room. -- see shy jo -- 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/20120712164013.ga19...@kitenet.net
Bug#681347: pkgsel: bussiness card and netinstall, Can't exec aptitude after Select Install Software
reassign 681347 ftp.debian.org VastOne wrote: Package: pkgsel Severity: serious Tags: d-i Can't exec aptitude: No such file or directory at /usr/bin/debconf-apt- progress line 130. STDIN line 2. aptitude's priority was downgraded to optional, but d-i still uses it to install security updates. The priority needs to be set back to important. -- see shy jo -- 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/20120712165212.gb19...@kitenet.net
Re: d-i skills exchange session tomorrow
Philipp Kern wrote: On Thu, Jul 12, 2012 at 12:40:13PM -0400, Joey Hess wrote: Since it only just went on the schedule, and I don't want those who requested it to miss it. Also, other people with d-i skills should come.. Noon tomorrow in the small talk room. Will the slot remain the same / has it been tentatively rescheduled? Rescheduled to tomorrow at 6 pm. -- see shy jo -- 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/20120712212319.ga6...@kitenet.net
Re: (forw) Switch to graphical installer by default?
Samuel Thibault wrote: Well, I guess at least for speech synthesis some people may find it easier to use. speakup still has issues with questions with a lot of choices: the language question, for instance, is a pain to listen to. What lanaguages does speakup support? We could make localechooser detect when speakup is enabled and voice a truncated list. -- see shy jo signature.asc Description: Digital signature
Bug#571204: tasksel: Does not install network management software for LXDE
Daniel Baumann wrote: i don't know why tasksel uses lxde-core, but, if you would depend on lxde instead, you would get network-manager-gnome that the lxde maintainers in debian recommend for their users. Package: lxde Source: lxde-metapackages Version: 2 Installed-Size: 26 Maintainer: Debian LXDE Maintainers lxde-deb...@lists.lxde.org Architecture: all Depends: gpicview, leafpad, lxappearance, lxde-core, lxde-icon-theme, lxinput, lxrandr, lxsession-edit, lxshortcut, lxterminal, obconf, xarchiver Recommends: iceweasel | www-browser, gdm3 | x-display-manager, lxmusic, menu-xdg, lxpolkit, xserver-xorg Where is the network-manager-gnome? -- see shy jo signature.asc Description: Digital signature
Bug#680519: please do depend on gdm3 for lxde-desktop
Daniel Baumann wrote: i don't think that the the installer (via tasksel) should use anything different than what we do with the live systems. That's backwards really. The live CDs should not be diverging from the tasks. lightdm is relatively buggy, does not reasonably support autologin yet, and doesn't bring any advantages over gdm3. gdm3 is even smaller in footprint size than gdm in squeeze, hence, using gdm3 in wheezy rather than gdm in squeeze is already an improvement. Are you thinking about #636104? It's fixed. Autologin works with lightdm in my experience. -- see shy jo signature.asc Description: Digital signature
Re: 20120708001451.gm4...@mykerinos.kheops.frmug.org
Stefano Zacchiroli wrote: It is not clear to me how accessible the initial splash screen --- the one with currently contain the choice between default, graphical, and advanced installation options --- is. *If* that screen is accessible It's not. Does occur to me that syslinux could be modified to add the ability to beep at different musical note frequencies, and we could then make it accessible, at least to those with good pitch. -- see shy jo signature.asc Description: Digital signature
Bug#680678: task-ssh-server: depend on 'ssh' instead of 'openssh-server'
Bob Bib wrote: 'task-ssh-server' currently depends on 'openssh-server'; IMHO, it wouldn't be wrong to depend on 'ssh' instead. 'ssh' depends on 'openssh-server' and 'openssh-client' (while 'openssh-client' is a dependency of 'openssh-server', so it's pulled by 'task-ssh-server' too). openssh-client is priority standard, so this would add a metapackage with no actual change to what's installed. Unless the user selects ssh-server and de-selects standard. -- see shy jo signature.asc Description: Digital signature
Bug#678795: task-desktop: Flash support should pull in browser-plugin-lightspark
Josh Triplett wrote: On Wed, Jun 27, 2012 at 04:11:48PM +0200, Per Olofsson wrote: Thus, I think we should consider removing browser-plugin-gnash from the desktop task (and the gnome metapackage). I agree with that. I only suggested the inclusion of lightspark because it made more sense than *only* having gnash, but personally I agree the desktop task should not include either. taskel is not entirely responsible for installing browser-plugin-gnash; it's a Recommend of gnome. I had kind of expected to remove flash from the tasks in the release after this one, but handler.678795.b678795.134079557331...@bugs.debian.org does make it seem that it would be at least a small net positive to remove it now. -- see shy jo signature.asc Description: Digital signature
Bug#679275: debian-installer: Debian installer fails when defining 10 or more partitions
Carsten Klein wrote: the debian installer will fail to install the system with 10 or more partitions defined during the manual partitioning process. This is due to the fact that the hard coded regexp for finding the first partition in the system will fail to return a single line, e.g. [hs]da1 will return I can't find this hardcoded regexp. At what point did the installation process fail? -- see shy jo signature.asc Description: Digital signature
Re: [SCM] d-i netcfg repository branch, people/sorina/show_essids, updated. 1.65-150-ga603dff
Justin B Rye wrote: People may well think in terms of the answer they give here being the wireless network. However, saying the wireless network (ESSID) implies that the ESSID is the network - which is logically equivalent, I suppose, but I'd still prefer to avoid it. I agree, I'd just drop the (ESSID). the installation process sounds better to me, but I'm not a native speaker. Comments? It sounds good to me. Yes, it's simple and clear. -- see shy jo signature.asc Description: Digital signature
Re: [SCM] d-i netcfg repository branch, people/sorina/show_essids, updated. 1.65-150-ga603dff
Justin B Rye wrote: But I suspect the best solution is: Select desired network name (ESSID) for connection attempt. Suggestion: Select the wireless network name (ESSID) to use during this installation process. It's not really relevant that it will attempt to connect to it and has a failure path. It is relevant that the installer will keep on using that same wireless network during the install, and that post-install, the system is likely to use a different one, at least when a desktop environment is installed. -- see shy jo signature.asc Description: Digital signature
Bug#673548: FWD: Re: Bug#673548: installation-reports: Wheezy's installer does't install KDE
- Forwarded message from ibsdeb ibs...@gmail.com - Date: Sun, 24 Jun 2012 13:26:45 -0300 From: ibsdeb ibs...@gmail.com To: Joey Hess jo...@debian.org Subject: Re: Bug#673548: installation-reports: Wheezy's installer does't install KDE User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/2014 Icedove/3.1.16 Dear Maintainer, Thank you for the return. Unfortunately, this was not the case. I did have an operating network and a configured Debian mirror in both times I installed: with http://cdimage.debian.org/cdimage/wheezy_di_alpha1/i386/jigdo-cd/debian-wheezy-DI-a1-i386-kde-CD-1.template 11-May-2012 18:49 and with debian-testing-i386-netinst.iso from 22-Jun-2012 I hope this can help and, again, thank you for the attention. Ibsen Em 23-06-2012 12:34, Joey Hess escreveu: Ibsen Morem wrote: Image version: http://cdimage.debian.org/cdimage/wheezy_di_alpha1/i386/jigdo-cd/debian-wheezy-DI-a1-i386-kde-CD-1.template 11-May-2012 18:49 -- also happended with debian-testing-i386-netinst.iso from 22-Jun-2012 This CD image is known to not currently contain all of KDE. If you installed from it without a network, or did not allow the installer to set up a Debian mirror to get the rest of KDE from, it would explain your problem. - End forwarded message - -- see shy jo signature.asc Description: Digital signature
Bug#653840: rootskel-bootfloppy: depends on unavailable klibc-utils-floppy-udeb on ia64
Philipp Kern wrote: And what about floppy-retriever? It was renamed to media-retriever in 2008. Perhaps a RM bug was forgotten to be filed? -- see shy jo signature.asc Description: Digital signature
Bug#678611: debian-installer: Add more early/late hooks
Daniel Dehennin wrote: As I setup a preseed configuration based on hands-off[1], I get troubles configuration d-i mirror/ and d-i apt-setup/localX depending on the network configuration. I'm using a full CD, so adding entries to sources.list is optional, but if the network is up, I would like to configure them and make a full upgrade. The HandsOff early_scripts are run by d-i preseed/early_command and when using a full CD, this happens before network get configured. My proposal is to add pre/post hooks at all the steps, with this I could register a d-i base-installer/early_command which tests if network is up and the mirror reachable and configure apt-setup. There is already the /usr/lib/base-installer.d/ and /usr/lib/post-base-installer.d/ directories, which earlier hooks can drop scripts into. apt-setup also has its own /usr/lib/apt-setup/generators/ -- see shy jo signature.asc Description: Digital signature
Bug#673548: installation-reports: Wheezy's installer does't install KDE
Ibsen Morem wrote: Image version: http://cdimage.debian.org/cdimage/wheezy_di_alpha1/i386/jigdo-cd/debian-wheezy-DI-a1-i386-kde-CD-1.template 11-May-2012 18:49 -- also happended with debian-testing-i386-netinst.iso from 22-Jun-2012 This CD image is known to not currently contain all of KDE. If you installed from it without a network, or did not allow the installer to set up a Debian mirror to get the rest of KDE from, it would explain your problem. -- see shy jo signature.asc Description: Digital signature
Bug#678642: FWD: installation fails
- Forwarded message from Michele Manfrin ymic...@yahoo.it - Date: Sat, 23 Jun 2012 13:13:37 +0100 (BST) From: Michele Manfrin ymic...@yahoo.it To: debian-boot@lists.debian.org debian-boot@lists.debian.org Subject: installation fails X-Mailer: YahooMailWebService/0.8.118.349524 Reply-To: Michele Manfrin ymic...@yahoo.it DebianInstaller trying to install with: debian-testing-amd64-netinst.iso 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards Flags: bus master, fast devsel, latency 0, IRQ 50 I/O ports at d000 [size=256] Memory at f4104000 (64-bit, prefetchable) [size=4K] Memory at f410 (64-bit, prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: r8169 Kernel modules: r8169 is not recognized as network hardware and the installation program stops thanks for your work Michele Manfrin -- 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/1340453617.16543.yahoomail...@web29702.mail.ird.yahoo.com - End forwarded message - -- see shy jo signature.asc Description: Digital signature
Re: debconf patch : Follow database files symlinks
Regis Boudin wrote: NB : I am definitely not a perl person, so I would strongly recommend someone with more experience reviews the patch before actually applying it. That put me off, for a while, but I've applied it now. -- see shy jo signature.asc Description: Digital signature
Re: tasksel upload
Bastian Blank wrote: Is there anything that speaks against an upload of tasksel? It works fine in my tests. This heuristic is just asking for trouble. # Exclude packages starting with lib $package !~ /^lib/ Only other concerning thing is the removal of task-fields, but I suppose if a CDD is using this they will speak up. -- see shy jo signature.asc Description: Digital signature
Re: Mount options for procfs
Ben Hutchings wrote: Since linux version 3.2.20-1, it is possible to set a 'hidepid' mount option on procfs, which restricts the visibility of unprivileged users to see other users' processes. initscripts correctly applies this option if present in /etc/fstab. Should d-i allow procfs mount opions to be configured at installation time (and presumably pre-seeded), or should this be left to post- installation? I think the problem with doing that is it would add /proc to the displayed partition table in partman, which could be confusing. OTOH, if d-i ever gets tmpfs support, /run and possibly /tmp might be there too. -- see shy jo signature.asc Description: Digital signature
Re: Tweaking tasks
Steve McIntyre wrote: Following up from the thread about lack of space... A couple of weeks back I rewrote the task support in debian-cd to deal with the change from tasks-in-Packages to task meta-packages. After a lot of local testing, today is the first time the weeklies have been built using the new code. There's probably some more tweaking due for Recommends handling yet, but this seems to work at the moment. Wow, that's a relief! Thank you immensely. The last package on amd64 CD#1 is libgjs0b. task-desktop fits on CD#1, but task-gnome-desktop is ~90 packages into CD#2. gnome-shell-common doesn't even make CD#1, which means the desktop will be a little... sparse. The full sorted package list is at Is this with or without Recommends of tasks? Does it omit the (probably uncessary) Recommends of packages recommended by tasks? -- see shy jo signature.asc Description: Digital signature
Re: Debian the FSF Secure Boot petition
Stefano Zacchiroli wrote: Dear d-i hackers, I've been contacted by Paul Wise about FSF campaign on secure boot [1] (thanks Paul!). As observed by various commenters over the net, it is indeed striking that no FOSS distros is in there. I plan to contact the FSF asking that Debian is listed as an endorser of the campaign. As you are the Debian people working on our installer, I think it should be done in agreement with you. So, what do you think? Do you see any reason why Debian should /not/ endorse such a campaign? Are you aware of any other initiative on the same vein that we should support to make our worries on that front heard? No objection from me, I've just signed it. I can imagine that d-i might have to do something to support users of such systems, similar to how we have non-free boot media to support users who need firmware to install. The petition allows us to do something like that, as long as we discourage use of it, similarly to how we discourage use of the non-free boot media. -- see shy jo signature.asc Description: Digital signature
Re: Tweaking tasks
Steve McIntyre wrote: No, not yet at least. To be honest, I've had a lot of pressure to just add all the Recommends anyway recently to match what people would install by default. That's what I've done so far. It's complicated. Sometimes we drop a package from a direct Recommends in a task-* package because a metapackage like gnome has the same Recommends. I do feel that deeper recommends could be omitted (or sorted to the end of the package list) and get a working CD, but it would require testing. -- see shy jo signature.asc Description: Digital signature
Bug#675144: Australia/Victoria or Australia/Melbourne missing in wheezy timezone prompt
Trent W. Buck wrote: When PXE-booting wheezy d-i[1], the timezone prompt lists Australian timezones but does not list either Victoria or Melbourne in the list. Yes, we have an unreleased upload adding Victoria. -- see shy jo signature.asc Description: Digital signature
Re: d-i testing with qemu
Philipp Kern wrote: Hi, I built d-i with build_netboot and try running it with qemu/kvm: kvm -hda hd_img.qcow2 -tftp dest/netboot -bootp /pxelinux.0 -boot n However it still tells me that it can't find a CDROM drive. Is this known breakage or does someone know a workaround so that I can test some udeb changes? (Same with mini.iso from build_cdrom_isolinux, fwiw.) What does, d-i or qemu? -- see shy jo signature.asc Description: Digital signature
Re: d-i testing with qemu
Philipp Kern wrote: Joey, am Sun, May 27, 2012 at 05:28:50PM -0400 hast du folgendes geschrieben: Philipp Kern wrote: I built d-i with build_netboot and try running it with qemu/kvm: kvm -hda hd_img.qcow2 -tftp dest/netboot -bootp /pxelinux.0 -boot n However it still tells me that it can't find a CDROM drive. Is this known breakage or does someone know a workaround so that I can test some udeb changes? (Same with mini.iso from build_cdrom_isolinux, fwiw.) What does, d-i or qemu? sorry, d-i. qemu does boot and all, even if I specify an ISO. How is cdrom-detect getting into your installer image? It's not included in the netboot iso normally, so either you have a pkg-lists/local that is forcing it in, or something is badly broken and causing it to be retreived from the network when the installer is running. -- see shy jo signature.asc Description: Digital signature
Bug#638682: Higher severity
Mehdi Dogguy wrote: The patch can make use of gpg to extract the signed data from the InRelease file. I'm not sure it is necessary since the rest works just fine if given an InRelease file instead of a Release file. I kept that part commented in the patch and leave this decision to the maintainer since it would add a strong dependency on gnupg… which doesn't seem necessary. debootstrap runs inside d-i which does not have gpg, only gpgv. It cannot use gpg. + if [ $release_file_variant = IN ]; then + # In both cases, we have to extract a Release file from the InRelease file Says both cases, but only runs in for the inRelease case? + # We redirect the output of gpg to /dev/null as it is useless at this stage + #if ! gpg --version /dev/null 21; then + # error 1 NEEDGPGV gnupg not installed, but required for InRelease extraction + #else + # (gpg --output $reldest --keyring $KEYRING --ignore-time-conflict \ + #$relsigdest || true ) 2/dev/null + #fi I'd be inclined to remove this dead code. - if [ -z $COMPONENTS ]; then - mv $reldest $reldest.malformed - error 1 INVALIDREL Invalid Release file, no valid components +if get $m1/dists/$SUITE/InRelease $inreldest nocache; then The above line is wrongly indented. -- see shy jo signature.asc Description: Digital signature
Re: installer location on mirrors
Joerg Jaspert wrote: I understand it right that doing it this way (ie. current symlink stays around), it won't break anything, so we can just do it for all suites?! It appears that debmirror will be broken, if it helps. :/ I can't find anything that will break in debian-cd. -- see shy jo signature.asc Description: Digital signature
Re: installer location on mirrors
Joerg Jaspert wrote: I don't think the installer images should be in dists/ as they are now, but get their own location, installer/. For various reasons, including the - wth was it added there in the first place, - currently an installer update move from one suite to another means real copies/moves. Why, pool/ got rid of that for our packages, why do we have it for the installer? Also, its really big and doesn't belong into dists/, which is more like a set of Package indices. It seems like pool/main/d/debian-installer/$ARCH/$version would be a good place to put it. Unless having non-debs in pool would break something's assumptions. If it's in pool, then dists could just link to the right one, ie: dists/sid/main/installer-i386/current - ../../../../pool/main/d/debian-installer/i386/20120508 I think this preserves backwards compatability in a clean way that won't need further work later, while meeting your goals. wheezy - 20120508 There is one drawback I see outright - we no longer have a current link. I might miss something here, but is the current link really required, if we build it up like the above? What if a user is installing stable and cannot remember the release code name? (Not hypothetical; I couldn't tell you the current release codename offhand.) The advantage of keeping the symlink in dists is that it's right there with the other files for whatever dist the user navigates to. Also it avoids special cases. -- see shy jo signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
While this has been an interesting thread, it may be predicated on a false premise. I examined the latest weekly CD build, and the reason no desktop tasks at all (even lxde or xfce) appear on their respective CDs is because debian-cd is simply not including tasksel's new task-* packages, at all. The packages on the CD seem fairly random, including things not in any task like wmaker, alien, and, on the lxde+xfce CD, lots of KDE, but no ldxe or xfce. Even DVD #1 seems broken, containing task-desktop, but not task-gnome-desktop. I'm sure gnome still fits on a DVD. Seems likely that things are badly broken in debian-cd's task handling. Likely related to tasksel's new task-* packages. The way debian-cd needs to handle the new task packages is this: * Put task-gnome-desktop on CD#1, task-kde-dekstop on KDE CD #1, etc. (No need to use /usr/share/tasksel/descs/debian-tasks.desc anymore.) * Try to include at all Recommends of task-* packages, not only their dependencies, as this is used to pull in the majority of packages for tasks. Do this even when normal Recommends inclusion is disabled. * If space is tight, drop some of the task-* Recommends. And, since this needs to be special cased anyway, it would be nice to have an option to abort the build, and/or warn if they don't fully fit. -- see shy jo signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Lisandro Damián Nicanor Pérez Meyer wrote: Indeed, I have seen that pattern before, although I think it was because people are used to get CDs, not DVDs (ie, just a matter of habit). Another reason is that it's more likely for a throwaway USB key to be in the 1-2 gb range than the 5 gb range. -- see shy jo signature.asc Description: Digital signature
Re: debhelper + udeb + xz
Philipp Kern wrote: On Sat, Feb 04, 2012 at 12:45:03AM -0400, Joey Hess wrote: Philipp Kern wrote: So now to the question: What's the policy for dpkg(-deb) feature use in debhelper? Would it be feasible to add '-z1', '-Zxz', '-Sextreme' to the dpkg-deb arguments for udebs within debhelper, once the dpkg changes land in the archive, even if that's not supported within stable? I don't mind making that kind of change. Patches accepted if debian-boot decides that's the way to go. can you make that change in your next debhelper upload, please? Well, I've done this, but I noticed that it only causes the data.tar to be xz compressed. There is still a control.tar.gz. Since udebs tend to have a lot of their content in the control archive, this is probably not as effective as it could be. For example, in anna, the first package I tried: -rw-r--r-- 1 joey joey 6.5K May 13 13:16 data.tar.xz -rw-r--r-- 1 joey joey 66K May 13 13:16 control.tar.gz -rw-r--r-- 1 joey joey 47K May 13 13:16 control.tar.xz -- see shy jo signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Neil Williams wrote: supporting only the smaller/lighter desktop environments is exactly what comes out of accepting that the first two options just won't be acceptable. Changing compression is only putting off the inevitable. There's *no* reason to think that GNOME or KDE are going to get back below the 1 CD limit at the next Debian stable release. I'd support XFCE4 as the default Graphical Desktop Environment and possibly putting GNOME (and KDE) as alternative options. That way, GNOME and KDE (as explicit options) should only show up in the list if using a medium which can provide that amount of packages. While I have started putting XFCE on systems I install for family etc, I am not sure if it's really suitable yes to be the default desktop environment. There are probably quite a lot of fit and finish issues. Here are two major problems: * Currently the XFCE taks uses wicd, which has a much less polished UI than network-manager. For example, when wicd needs a password, it opens a rather complex configuration panel, rather than just prompting for the password. Probably some users also use network-manager for things like cell connections, that wicd doesn't support. * There does not seem to be much accessability support in XFCE. With gnome, we have a fully accessible system from the login manager on. Accessability improvements are on the XFCE roadmap; this should improve with time. http://wiki.xfce.org/releng/4.10/roadmap/accessibility I hope that we can avoid the CD size forcing the desktop for at least one more release. Note that we had the same trouble the last two releases, and managed to make it fit in the end both times. -- see shy jo signature.asc Description: Digital signature
Re: Bootloader udeb selection for specific platform
Gerhard Pircher wrote: Hi, I'm looking into building a custom Debian install CD for a non-supported PowerPC platform. The platform doesn't work with any of the available bootloaders in Debian. Therefore I would like to create my own bootloader udeb package. While I can use one of the available bootloader udebs as a base for my work, I didn't find out yet how the installer selects the right bootloader for a platform (it seems to load several bootloader udebs during an installation). Is this done by preseeding (though I could only find preseeding options for grub and lilo) or by some check of the architecture/platform string in /etc/cpuinfo? This is usually done with isinstallable scripts in the udebs's control.tar.gz. -- see shy jo signature.asc Description: Digital signature
Bug#659208: Bug#668860: /usr/lib/os-probes/mounted/90bsd-distro: gawk: not found
Nobuhiro Ban wrote: /usr/lib/os-probes/mounted/90bsd-distro: 17: /usr/lib/os-probes/mounted/90bsd-distro: gawk: not found Found unknown Linux distribution on /dev/sda2 done My debian selected mawk for awk. d-i doesn't have gawk either. I don't speak awk well enough to know if busybox awk and mawk can run the code added in bug #659208. Looking at the lack of any explanation attached to #659208, I am very tempted to revert it. CCing Otavio since he seemed to find some value in that bug that I don't see. Also, why was #659208 not closed when it was applied? Why was its added file not fixed to use the same indentation as the rest of os-prober? This seems badly handled all around. -- see shy jo signature.asc Description: Digital signature
Re: Skip one udeb step on d-i
Félix Arreola Rodríguez wrote: But I include my custom udeb (called installfest) with a menu item number of 7000, depends on apt-setup-udeb and provides pkgsel. This with the propose of skipping pkgsel. I always skip pkgsel and tasksel even on my own debian installs. It's not pkgsel fault, I just don't like the default task selection. So, my special udeb installs a special list of packages, but I still can't skip pkgsel. Have you tried a number slightly before 7000? Boot in expert mode and look at the main menu. Your udeb's menu item needs to come before pkgsel. -- see shy jo signature.asc Description: Digital signature
Bug#472704: I face same issue W: Failure while configuring base packages.
This bug report remains open only as a request for debootstrap to somehow extract and print the actual error message from debootstrap.log when the installation of a package fails. Ideally that would be done in a form that prevents users from filing bug reports on debootstrap for random transient package breakage in unstable. Please do not continue to post random transient package breakage in unstable reports to this bug report. (Hint: This bug report is from 2008, while your breakage is from 2012 or later. Hint: If you got to this bug report via google, I'm talking to you. File a new bug for your new issue; consider filing it on the package that's actually broken, not on debootstrap.) (Regarding libept, it will be fixed once the libept1 binary is removed from unstable by the usual processes, presumably.) -- see shy jo signature.asc Description: Digital signature
Bug#668139: falls over a missing directory /var/lib/os-prober/mount
martin f krafft wrote: I don't know what os-prober does, but # os-prober ls: reading directory /var/lib/os-prober/mount: Input/output error ls: reading directory /var/lib/os-prober/mount: Input/output error ls: reading directory /var/lib/os-prober/mount: Input/output error ls: reading directory /var/lib/os-prober/mount: Input/output error ls: reading directory /var/lib/os-prober/mount: Input/output error ls: reading directory /var/lib/os-prober/mount: Input/output error ls: reading directory /var/lib/os-prober/mount: Input/output error strikes me as unnecessary (the backup didn't contain the directory for some reason). Maybe a simple check and mkdir() could mitigate this? This is a temporary mount point for the partitions os-prober is probing for an OS. Apparently the kernel is failing to read one of those partitions after mounting it. -- see shy jo signature.asc Description: Digital signature
Bug#620309: debian-installer: same problem on squeeze
Bernhard Kuemel wrote: bernhard@b:~/di/debian-installer-20110106+squeeze4/build$ fakeroot make Take a look at debian/rules for some variables you need to set to build for squeeze, like: USE_UDEBS_FROM=squeeze -- see shy jo signature.asc Description: Digital signature
Bug#668001: debootstrap: cant install systemd instead of sysvinit
shawn wrote: Package: debootstrap Version: 1.0.39 Severity: normal Tags: d-i if you use debootstrap unstable foo --include=systemd-sysv --exclude=sysvinit the install fails dpkg: regarding .../systemd-sysv_44-1_i386.deb containing systemd-sysv: systemd-sysv conflicts with sysvinit sysvinit (version 2.88dsf-22.1) is present and installed. dpkg: error processing /var/cache/apt/archives/systemd-sysv_44-1_i386.deb (--unpack): conflicting packages - not installing systemd-sysv The problem is that debootstrap handles --exclude before adding required priority packages to its list, so sysvinit is added back then. #557322 is a prior bug report about this, and has a patch that at least handles excluding it from the required priority packages, although it may still be added back by dependency resolution. besides having this annoying for testing, esp with systemd-nspawn, having this work will be a prerequisite for having systemd be the default, or at least installable in debian-installer I don't think that's necessarily true, there are many ways d-i could handle getting systemd installed, and if it were made the default, --exclude would not be needed at all. -- see shy jo signature.asc Description: Digital signature
Re: building gnupg-udeb with enable-minimal
Thijs Kinkhorst wrote: GnuPG has for a while now the configure switch --enable-minimal, which builds a gnupg with as few options enabled as possible. I was wondering if using this configure switch for the gnupg-udeb would make sense for you - I remember that size was an issue, not sure if that's still a relevant concern. I tried to rebuild gnupg-udeb with --enable-minimal, and that reduces the size from 817K to 568K; so not dramatic but still significant. I didn't really test it though, so it may be that the installer actually needs more options than this. So my question to you is: would a size saving in this order be a significant improvement for the installer? If so, what minimum functionality would be required from gnupg-udeb? I can then explore this further, but would like to be sure that it would be actually useful. BTW, gpgv is already a minimal tool, so the switch has no relevant effect there. gnupg-udeb is only used by partman-crypto-loop, which uses it to generate a symmetric key file as follows: gpg --batch --no-options --no-random-seed-file --no-default-keyring \ --keyring /dev/null --passphrase-fd 3 --symmetric -a Reducing the size of this part of the installer saves space on the netinst and busnesscard CDs, so is desirable. If gpg had a --disable-public-key-crypto, I'd say build it with that. ;) -- see shy jo signature.asc Description: Digital signature
Bug#667703: Please remove synaptic entirely from task-desktop
Christian PERRIER wrote: OK, so long for not pulling synaptic through the gnome task...and not moving it to the desktop task That leaves us with the decision of either adding synaptic to the KDE taskor leave it up to KDE maintainers to do it in one of their metapackages. (and same decision for other DE) Yes, I've added it to the other tasks, but this may change based on feedback from KDE people. -- see shy jo signature.asc Description: Digital signature
Bug#667703: gnome, size for Xfce
Filipus Klutiero wrote: Josselin, why would the gnome metapackage already pull synaptic? I don't see any direct relation. This is what happens on my testing/unstable mix: nautilus recommends synaptic. -- see shy jo signature.asc Description: Digital signature
Bug#667703: Please remove synaptic entirely from task-desktop
Josselin Mouette wrote: It should be the role of metapackages to handle which packages are installed onto which desktop environment. This actually depends how close a given desktop environment's definition of desktop environment is to common user expectation of a linux desktop. For example, none of the DE's include a print server, but a Debian desktop system should have one. The gnome metapackage already pulls synaptic. If we decide one day to replace it, it shouldn’t need two changes, one in gnome and one in tasksel. I agree, there is no reason to pull in synaptic twice for gnome. -- see shy jo signature.asc Description: Digital signature
Re: debconf not recognizing template pattern from custom udeb
Ryan Braun [ADS] wrote: Here is the templates control file from the udeb. Template: debian-installer/scripted-partitioning/title Type: text Description: Partition automatically via a shell script Template: scripted-partitioning/script Type: text Description: What script do you want to run to partition your disk? The filename must be relative to /lib/scripted-partitioning, and must already exist and be executable. If this is the actual file, it's clearly wrong; you have a lot of extra newlines. -- see shy jo -- 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/20120402143601.gb20...@gnu.kitenet.net
Bug#665852: UI still refers to volatile.debian.org
Philipp Kern wrote: On Tue, Mar 27, 2012 at 07:14:10AM +0200, Christian PERRIER wrote: If I'm correct there is no more volatile at all. There's still the $codename-updates suite. I personally don't care if it's not deactivatable in d-i, but given that security updates are, it probably makes sense. Yes, and leaving the code for it in also keeps support for installing lenny. Although that is not a priority. -- see shy jo signature.asc Description: Digital signature
Bug#665852: UI still refers to volatile.debian.org
Package: apt-setup Severity: normal VOL_HOST still appears as volatile.debian.org in the UI, but that is thuroughly dead now. -- see shy jo signature.asc Description: Digital signature
Bug#665638: prevent debootstrap vom needing SHA256sums
Mario Koppensteiner wrote: I have an issue with debootstrap. I debugged the issue and I found the following: The Problem is in the file /usr/share/debootstrap/functions line 634 Here is the code of the line 628 to 634 $PKGDETAILS PKGS $m $pkgdest $@ | ( leftover= while read p ver arc mdup fil checksum size; do if [ $ver = - ]; then leftover=$leftover $p else progress_next $(($dloaddebs + $size)) checksum should contain the SHA256sum and size should contain the size. But if the Packages.gz file does not contain any SHA256sums, then the checksum variable contains the size and the size variable is empty. If that happens then the line 634 executes 0 + I used the following command: root# debootstrap --no-check-gpg --verbose squeeze /path/chrootsystem/ ftp://ftp.domain.tld/pub/debian/squeeze Am I correct in deducing that this mirror is one that was actually generated with apt-move, and that's why it's missing the SHA256 fields? Can somebody please implement a parameter which tells debootstrap not to relly on SHA256sums and use MD5sums instead? Well, that would be insecure. Better to fix the mirror? -- see shy jo signature.asc Description: Digital signature
Re: cdebconf 0.159
Regis Boudin wrote: Perhaps it's time to get some wide testing? This could be done by temporarily making debconf default DEBCONF_USE_CDEBCONF=1 Sounds like an idea. the various scripts will probably need an additional check for cdbconf's existence, though, since it caused me trouble I was assuming we'd make debconf depend on it, although this would technically violate its Priority value. For temporary testing it seems ok. -- see shy jo signature.asc Description: Digital signature
Re: cdebconf 0.159
Regis Boudin wrote: That's a bit odd, the initial setup and conversion is done in the config script, and I would have expected debconf to have already run it before. Unless I got it wrong with my almost empty postinst. FWIW, I saw the same thing; debconf was using dialog and cdebconf defaults to text. -- see shy jo signature.asc Description: Digital signature
Re: cdebconf 0.159
Regis Boudin wrote: Hi everyone ! That's it, after a month of testing on my main machine, I uploaded cdebconf 0.159. Although some features are still missing, it should actually be usable. Well, I've been using it on my main machine for a month with 2 daily updates, and a few dpkg-reconfigure -a, and all blocking issues I've seen since August have been identified and fixed. Also, interesting milestone I believe, with a script modified only to add cdebconf to the required packages if DEBCONF_USE_CDEBCONF is set, I could debootstrap a chroot, and compile a KDE application with cowbuilder. Perhaps it's time to get some wide testing? This could be done by temporarily making debconf default DEBCONF_USE_CDEBCONF=1 Independant of that, it would be good to get cdebconf to the point it does not depend on debconf. -- see shy jo signature.asc Description: Digital signature
Bug#283600: RC2 succeeded; unhelpful error message
Colin Watson wrote: The main trick will be telling the difference between a retrieval failure and some other kind. base-installer already knows about the specific names of debootstrap errors, so it doesn't seem out of the question for it to handle some of them differently. Do you think it would be OK to special-case the COULDNTDL and COULDNTDLPKGS errors, possibly in run-debootstrap.c, and send those off into a special code path that offers this menu? Yes, I think that'd be fine. -- see shy jo signature.asc Description: Digital signature
Re: TRIM support for ext4
Miguel Figueiredo wrote: Add the mount option 'discard' for ext4 filesystems so, during partitioning, TRIM can be activated for SSDs in the installed system. I had the impression that there was going to be some sort of automatic detection in the kernel of appropriate devices and that trim would be automatically enabled for them. Is it not going to play out that way? -- see shy jo signature.asc Description: Digital signature
Bug#654317: Needs creation of /usr/share/man/man1
Neil Williams wrote: Emdebian doesn't include manpages and some packages (and some udebs apparently) don't expect this directory to not exist. I'd be very surprised if any udebs know anything at all about /usr/share/man. However, there are numerous postinsts, starting with bash, that run update-alternatives on files in /usr/share/man/, which is likely to not work well if the directory is missing. -- see shy jo signature.asc Description: Digital signature
Re: TRIM support for ext4
Floris Bos / Maxnet wrote: In addition to that, it would also be nice if the -E discard option is passed to mkfs.ext4, so that it TRIMs the entire disk partition prior to creating the file system structures. -E discard is the default, according to mkfs.ext4(8) -- see shy jo signature.asc Description: Digital signature
Re: TRIM support for ext4
Miguel Figueiredo wrote: On 12-03-2012 04:55, Joey Hess wrote: I had the impression that there was going to be some sort of automatic detection in the kernel of appropriate devices and that trim would be automatically enabled for them. Is it not going to play out that way? Just adds the mount option to partman. Obviously; that does not, however, answer my question, and providing an option is not going to do anything to help the majority of users. -- see shy jo signature.asc Description: Digital signature
Re: TRIM support for ext4
Floris Bos / Maxnet wrote:
Hmm, and to make things more complicated.
The RELEASE-NOTES that come with the e2fsprogs source say that the
default is what you put in mke2fs.conf
That's for an older version.
int discard = 1;/* attempt to discard device before fs creation */
} else if (!strcmp(token, discard)) {
discard = 1;
} else if (!strcmp(token, nodiscard)) {
discard = 0;
discard = get_bool_from_profile(fs_types, discard , discard);
--
see shy jo
signature.asc
Description: Digital signature
Bug#663540: finds MSDOS when there is none
Michael Tokarev wrote: So a more naive approach at determining the filesystem type is to check first 512 bytes, and if MS-DOS signature is found there, report that it is MS-DOS. This is, apparently, what os-prober is currently doing. os-prober does not look at fragile magic numbers in filsystem headers. It mounts the actual filesystem, and looks for (fragile) specific filenames indicating which OS is contained in it. The particular OS string we see here comes from: # MS-DOS if [ -z $found ] item_in_dir -q dos $2 [ -d $2/$(item_in_dir dos $2) ]; then long=MS-DOS 5.x/6.x/Win3.1 short=MS-DOS found=true fi Perhaps your filesystem has a /dos directory? item_in_dir checks for any case, so /DOS or /Dos would also do. These checks don't try to avoid false positives like a /dos or /windows, because the code earlier checks that the mounted filesystem is one of ntfs, vfat, or msdos. To which list was semi-recently added fuse, and I suspect that might be the root of the problem. Colin, if grub-mount is being used, will *every* filesystem appear as fuse? If so, this and other code has become much more prone to false positives than it was when it was originally written. (os-prober 1.42 didn't have this problem I think only because the above code in it had a typo that made it never match anything!) -- see shy jo signature.asc Description: Digital signature
Bug#663600: grub-mount regressions in os-prober
Package: os-prober Version: 1.49 Severity: normal A while ago, os-prober was made to try to mount filesystems with grub-mount. This means that $type cannot be used to test the filesystem type. Various commits have been made since to let through $type=fuse|fuseblk in various tests. But, I've noticed that regressions still remain. These checks always fail when grub-mount is used, assuming it can mount the listed filesystems, because they check $type for specific values: 80minix minix*, ext2* 90bsd-distroufs* 10macos6-9 hfs*, hfsplus* 10qnx qnx4 I've starred filesystems I know grub-mount can currently mount. AFAICS, all starred items are real regressions caused by using grub-mount. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages os-prober depends on: ii libc6 2.13-27 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#663540: finds MSDOS when there is none
Samuel Thibault wrote: Mmm, why not looking for io.sys at the root? In all the versions of DOS that I know there has to be one for the partition to be bootable. According to http://en.wikipedia.org/wiki/IO.SYS , some of the DOS clones did not use io.sys, which may be why I don't remember it well. I added a check for autoexec.bat || config.sys , just to have an added check and avoid the worse of the false positives. My gut feeling is that either a) nobody cares if their DOS is not detected, or b) if they do care, they have one of those files. -- see shy jo signature.asc Description: Digital signature
Bug#663600: Bug#663540: finds MSDOS when there is none
Colin Watson wrote: How about, if grub-mount is used, we use grub-probe to find out which GRUB filesystem driver is in use, and stash that somewhere so that individual tests can get at it? That ought to be just as reliable as the existing OS filesystem type checks. Yes please. I've CCed the other bug I opened, since it appears there are also several false negatives when grub-probe is used. Your method should solve it. Once we have a real FS type from grub-probe, the best thing would be to pass it into individual checks as $3 in place of fuse. -- see shy jo signature.asc Description: Digital signature
Re: seeding debconf values
Marcus Möller wrote: Hi all. I stumbled about the following paragraph in the documenation [1]: 'For debconf variables (templates) used in the installer itself, the owner should be set to “d-i”; to preseed variables used in the installed system, the name of the package that contains the corresponding debconf template should be used. Only variables that have their owner set to something other than “d-i” will be propagated to the debconf database for the installed system.' and wonder what is best practice for variables like: debconf/priority select critical I want this to be set during installation AND in the installed system, and noticed that: debconf debconf/priority select critical seems to apply for both. Is that the correct way to go, or should i better define both: d-i debconf/priority string critical debconf debconf/priority select critical If you define both, probably the second will be used, but this is not a well specified thing. The right thing to do in this case is to use debconf as the owner, since you do want it to propigate to the installed system. d-i will see the variable in either case. [1]: http://www.debian.org/releases/stable/i386/apbs03.html.en I've slightly clarified the wording, though this is still a complex area.. -- see shy jo signature.asc Description: Digital signature
Re: My cdebconf is escaped !
Regis Boudin wrote: * ejabberd. During postinst, cdebconf seems to wait indefinitely on the read() in confmodule.c, line 109. The problem only occurs if invoke-rc.d ejabberd start is called during the postinst script, though. Sounds like the typical problem of a daemon inheriting the confmodule FD, or something to do with STOP handling. The ejabberd postinst does send a STOP. Debconf/CondModule.pm special-cases the stop command, so it does not send a reply to it. Looks to me like cdebconf's command_stop returns a reply to stop. Quite likely it blocks forever, since the client confmodule does not read that reply. -- see shy jo signature.asc Description: Digital signature
Bug#657389: Tasksel is to blame
Jurij Smakov wrote:
I noticed that as well with today's dailies. This is displayed by
tasksel, installer just invokes it in /target. I can also reproduce it
on an installed system by running 'tasksel -t'.
Since I can't reproduce this, I can only guess.
tasksel contains a sub list_installed() that parses
/var/lib/dpkg/status. Perhaps something about the status file format has
changed?
Parsing the file is a bit gratuitous, so I've attached a patch that
switches it to dpkg-query. Does it fix the issue?
--
see shy jo
From af213911196f47c4cbe3fb0ba9f54999a32f9684 Mon Sep 17 00:00:00 2001
From: Joey Hess j...@kitenet.net
Date: Sun, 29 Jan 2012 02:26:33 -0400
Subject: [PATCH] Use dpkg-query to list packages, rather than parsing the
status file. Closes: #657389
---
debian/changelog |4
tasksel.pl | 10 --
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index ff17af3..1e81501 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -16,6 +16,10 @@ tasksel (3.08) UNRELEASED; urgency=low
- Add ibus-gtk3 to task-korean-gnome-desktop
- Replace ttf-* with fonts-*
+ [ Joey Hess ]
+ * Use dpkg-query to list packages, rather than parsing the status file.
+Closes: #657389
+
-- Christian Perrier bubu...@debian.org Mon, 05 Dec 2011 21:29:17 +0100
tasksel (3.07) unstable; urgency=low
diff --git a/tasksel.pl b/tasksel.pl
index d32c456..0b05d74 100755
--- a/tasksel.pl
+++ b/tasksel.pl
@@ -115,15 +115,13 @@ sub list_avail {
# Returns a list of all installed packages.
sub list_installed {
my @list;
- local $/=\n\n;
- open (STATUS, $statusfile);
- local $_;
- while (STATUS) {
- if (/^Status: .* installed$/m /Package: (.*)$/m) {
+ open (LIST, q{dpkg-query -W -f='${Package} ${Status}\n' |});
+ while (LIST) {
+ if (/^([^ ]+) .* installed$/m) {
push @list, $1;
}
}
- close STATUS;
+ close LIST;
return @list;
}
--
1.7.8.3
signature.asc
Description: Digital signature
Bug#655841: Please remove Gnash from default Debian install, as it crashes
Alexey Eromenko wrote: Default Debian-6 KDE installs gnash, an extremely unstable component, that constantly crashes KDE Konqueror, when user accesses any flash-enabled website (such as www.amd.com). Wouldn't that be a bug in konqueror-nsplugins? No plugin should be able to crash the browser it's running in; at least chromium and I think firefox/iceweasel deal with crashing plugins. Also, #549309 seems to suggest this only affects konqueror. Since the KDE task also includes iceweasel, gnash should work (as well as it ever does) there. -- see shy jo signature.asc Description: Digital signature
Bug#655841: Please remove Gnash from default Debian install, as it crashes
Michael Gilbert wrote: lightspark is an alternative. Of course, it's also experimental, but who knows, it may be a bit more stable/complet at this point? I haven't really looked into it. Just something worth considering... The end game, which I am increasingly sure will happen by the next stable release, is going to be Debian shipping without flash in the default desktop installs. Really the only blocker is that users have to know to go to http://youtube.com/html5 to enable non-flash videos. -- see shy jo signature.asc Description: Digital signature
Bug#652987: FWD: Bug#652987: the cdrom path is not disabled in sources.list
Forwarding to live team for your help. Does it make sense to always
disable the CD in sources.list for live systems? If live systems
contain some sort of package archive at all, and it's not complete,
should they put not_complete into /cdrom/.disk/cd_type ?
- Forwarded message from prathib...@cdac.in -
Date: Thu, 22 Dec 2011 19:52:51 +0530 (IST)
From: prathib...@cdac.in
To: sub...@bugs.debian.org
Subject: Bug#652987: the cdrom path is not disabled in sources.list
Reply-To: prathib...@cdac.in, 652...@bugs.debian.org
X-Mailer: TWIG 2.8.3
Package: apt-setup
version: 0.56
While installing debian using the live-installer package, the cdrom path
in the sources.list exists after the completion of the installation in
sources.list. While reloading the synaptic package manager, it shows the
error: Failed to load cdrom...
A patch for resolving this issue is attached.
--
Regards,
Prathibha
C-DAC
Chennai
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
diff -Naur apt-setup-0.56-orig/finish-install.d/10apt-cdrom-setup
apt-setup-0.56/finish-install.d/10apt-cdrom-setup
--- apt-setup-0.56-orig/finish-install.d/10apt-cdrom-setup 2011-06-19
08:08:25.0 +0530
+++ apt-setup-0.56/finish-install.d/10apt-cdrom-setup 2011-12-22
09:17:48.0 +0530
@@ -1,12 +1,16 @@
#! /bin/sh
set -e
-# Disable netinst CD image in sources.list if any other sources are present
-if [ -e /cdrom/.disk/base_installable ] \
- [ -e /cdrom/.disk/cd_type ] \
- [ $(cat /cdrom/.disk/cd_type) = not_complete ] \
- grep -q ^deb \(ht\|f\)tp /target/etc/apt/sources.list; then
- logger -t finish-install Disabling netinst CD in sources.list
- sed -i /^deb cdrom:/s/^/#/ /target/etc/apt/sources.list
- log-output -t finish-install chroot /target apt-get update
+disable_cdrom_path()
+{
+ logger -t finish-install Disabling the install CD path in sources.list
+ sed -i /^deb cdrom:/s/^/#/ /target/etc/apt/sources.list
+ log-output -t finish-install chroot /target apt-get update
+}
+
+# Disable CD path in sources.list
+if [ -e /cdrom/.disk/base_installable ] [ -e /cdrom/.disk/cd_type ] \
+ ( [ $(cat /cdrom/.disk/cd_type) = not_complete ] grep -q ^deb
\(ht\|f\)tp /target/etc/apt/sources.list ) || \
+ ( [ $(cat /cdrom/.disk/cd_type) = live ] grep -q ^deb cdrom:
/target/etc/apt/sources.list ); then
+ disable_cdrom_path
fi
- End forwarded message -
--
see shy jo
signature.asc
Description: Digital signature
Bug#655198: live-installer does not remove live packages in the installed system
Rui Miguel P. Bernardo wrote: I've noticed that debian-installer-launcher was not removed in the installed system, as were not removed also live-config, live-boot and others. Related to this is the search for /cdrom/live/filesystem.packages-remove file. I suppose the /cdrom is not mounted when finish-install.d/60remove-live-packages is executed [...] 15cdrom-detect: logger -t cdrom-detect $@ 15cdrom-detect:# Cannot just tell eject to eject /cdrom as it is not compatible 15cdrom-detect:# with busybox umount. Instead, unmount the cdrom first, and then 15cdrom-detect:CDDEV=$(mount | grep on /cdrom | cut -d ' ' -f 1) 15cdrom-detect: umount /cdrom || true 15cdrom-detect: db_get cdrom-detect/eject 60remove-live-packages:for list in /cdrom/live/filesystem.packages-remove; do If that's the case then something should be done. Move 60remove-live-packages to before 15cdrom-detect (or vice-versa), or just remove manually the live packages, or something else. I agree, it looks broken for 60remove-live-packages to come after cdrom-detect cleans up after itself, if it depends on the CD being mounted. +do_manual_removal=true + # Remove packages as specified in specific package removal list for list in /cdrom/live/filesystem.packages-remove; do if [ -e $list ]; then This patch seems correct anyway, so I have applied it, but I don't feel it really fixes the bug, the intent seems to be for the list of packages to remove to be moved out of live-installer and into the creation of the live CD, and this only papers over that not working. -- see shy jo signature.asc Description: Digital signature
Re: log-output command in os-prober
Eldar Yusupov wrote:
I could not find os-prober development mailing, so I could not find any other
way to find the answer other to ask you in personal by e-mail.
I've CCed our mailing list.
I've been reading os-prober source and found the following piece of code:
log_output () {
if type log-output /dev/null 21; then
log-output -t os-prober --pass-stdout $@
else
$@
fi
}
I have never heard of UNIX command log-output, which, I suppose, redirects
the command output to syslog.
Google search also did not turn up anything relevant. It seems that it would
be
quite useful command for shell scripting and I'd definitely love to know more
about it.
It's a component of the Debian installer, as is os-prober, which is why
os-prober uses it if it's available.
log-output: Runs a command, logging any stdout/stderr output to the syslog,
and preserving the command's exit code. If you use the --pass-stdout option,
it will pass stdout through rather than logging it, so that you can redirect
it to a file or pipe it to another process. Note that the command must be
in the path, shell builtins won't work.
http://anonscm.debian.org/gitweb/?p=d-i/debian-installer-utils.git;a=blob;f=log-output.c
--
see shy jo
signature.asc
Description: Digital signature
Re: Please fix the SCM urls in the Alioth's project page
Javier Fernández-Sanguino Peña wrote: Hi fellow developers, It would be nice if this was fixed: https://alioth.debian.org/scm/?group_id=30260 indicates that the SCM for the Debian-installer project is GIT but the git repo (git clone http://git.debian.org/git/d-i/d-i.git for anonymous checkout) is actually an empty repository. I don't think I can fix this. We had to enable git for the project on alioth because we use a lot of git, and need its git stuff. Turning that back off would probably not be wise. Also, I can't even write to /d-i/d-i.git on alioth. -- see shy jo signature.asc Description: Digital signature
Bug#654309: daily debian installer doesn't boot
Miguel Figueiredo wrote: Daily images don't boot on amd64 and i386. After pressing enter to start the installation process the screen starts flickering and on the screen keeps appearing just the following line. INFO: kbd-mode: setting console mode to Unicode (UTF-8) Printscreen: http://i.imgur.com/lIhYA.png cdebconf is crashing, it crashes on any script, I have seen it successfully draw a progress bar before crashing however. I don't know why, cdebconf has not changed since November. Possibly related to #654351? -- see shy jo signature.asc Description: Digital signature
Bug#653513: debian-installer: build/README lies, code says: USE_UDEBS_FROM ?= unstable
Cyril Brulebois wrote: Daily builds are defined nowhere, so it can't be concluded whether running “make build_something” under build/ is considered a daily build. (Or maybe the intent was to document that daily builds are the reasons for the default's being unstable. I guess it can be understood both ways.) Sure it can. Daily builds are built under build/. Releases of debian-installer are built using debian/rules. debian/rules overrides USE_UDEBS_FROM appropriately. -- see shy jo signature.asc Description: Digital signature
Bug#653840: rootskel-bootfloppy: depends on unavailable klibc-utils-floppy-udeb on ia64
Julien Cristau wrote: rootskel-bootfloppy/ia64 unsatisfiable Depends: klibc-utils-floppy-udeb (= 1.5-2) This is not a new dependency, it's from 2008 and klibc-utils-floppy-udeb is not built on ia64. But why are you trying to use boot floppies, let alone on ia64 anyway? -- see shy jo signature.asc Description: Digital signature
Bug#653669: Installation failed with BTRFS
Miguel Figueiredo wrote: i tried to install the businesscard image and also failed while using btrfs. The installation log was full of btrfs kernel errors, these errors repeated itself until installation fails reporting no space left on device. I trimmed the 22 MB log, with the first 2000 lines and the last 100 lines where the kernel error and no space left errors are visible. If anyone needs to full log i can send it. Not sure to which specific package this should be reassigned. Dec 30 13:10:16 kernel: [ 1231.328148] WARNING: at /home/blank/debian/kernel/release/linux-2.6/linux-2.6-3.1.6/debian/build/source_amd64_none/fs/btrfs/extent-tree.c:5711 btrfs_alloc_free_block+0xc0/0x283 [btrfs]() Are you sure you made the partition big enough? btrfs at least used to not handle running out of disk space at all, and we can see it's trying to allocate a disk block, and this error occurs part of the way through debootstrap, when at least a few hundred megabytes will have been written to the disk. Alternatively, the 3.1.0-1 kernel could have a broken btrfs, if so reassign this bug to there. -- see shy jo signature.asc Description: Digital signature
Re: Adding ISO-search support to the CD (netinst) images?
Evgeni Golov wrote: How to use: boot as cdrom OR grub2: loopback loop /debian-7.0-amd64-NETINST-findiso.iso set root=(loop) linux /install.amd/vmlinux findiso initrd /install.amd/initrd.gz boot OR kvm: kvm -kernel dest/cdrom/vmlinuz -initrd dest/cdrom/initrd.gz \ -append 'findiso' -hda /tmp/blah -boot a So for this to work, the user has to go out of their way to configure it to be used, including specifying the initrd to use. Why is this better than the user downloading the hd-media initrd.gz and using that? This cannot quite replace hd-media, because the hd-media initrd contains many more kernel drivers, to be able to scan hard drives. Those are not included on the cdrom initrd to avoid bloating it. As one of the main authors and maintainers of iso-scan, I see it being used in increasingly limited circumstances, and have been hoping that those use-cases will narrow to the point that it can be removed. Making it marginally easier to boot the CD with grub2 is a very narrow use-case indeed, and not a good justification for adding iso-scan to the cdrom initrd. -- see shy jo signature.asc Description: Digital signature
Bug#653840: rootskel-bootfloppy: depends on unavailable klibc-utils-floppy-udeb on ia64
Julien Cristau wrote: I'm not, I'm just looking at grep-excuses, which suggests either klibc-utils-floppy-udeb should exist on ia64 or rootskel-bootfloppy should be killed there. Quite likely rooskel-bootfloppy and klibc-utils-floppy-udeb should be killed *everywhere*. It's not like the kernel has fit on a floppy in 4 years on i386. At some point, leaving this cruft around in hopes that the kernel will magically be halfed in size is counterproductive. -- see shy jo signature.asc Description: Digital signature
Bug#650859: typical weekend after black friday install, 2011 edition
Joey Hess wrote: The graphics worked ok with stable's kernel; however when I upgraded the kernel to 3.1.4-1 to try to get wifi working (which it did seem to), it turned the display off as soon as the kernel did a mode switch on boot. Do you have the dmesg from that kernel? Attached tarball has the dmesg from 3.1.4, as well as a backport kernel (in which the display worked, but wifi did not work). It also has xorg logs with both kernels, and the installer syslog. This was solved by upgrading to 3.2~rc4-1~experimental.1, which supports both the wifi and video at the same time. -- see shy jo signature.asc Description: Digital signature
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Christian PERRIER wrote: I'm inclined to follow this advice and would indeed propose that the atomic partman-auto recipe is kept, however without a separate /usr partition (discussions on -devel and the current practice convinced me that a separate /usr is seomthing that probably belongs to the former century..:-) I don't think that d-i should be on the leading edge of this discussion. Once Debian has made up its mind, d-i can be updated to follow the consensus. -- see shy jo signature.asc Description: Digital signature
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Steve Langasek wrote: There isn't. There's just a broad consensus among those who are talking about changing things. Yes. -- see shy jo signature.asc Description: Digital signature
