Re: A notice to the Debian Installer team...
Hi Petter, I have actually used the multi partman recipe. My hard drive is 160G in size. The space allocated to /usr was more than enough under Lenny. I used to install both Gnome and KDE and lot more additional packages. But now I have only Gnome with a very small number of additional packages and the partition is running low on disk space. I think at least 6G should have been allocated to /usr. Installing Lenny with the laptop task selected consisted only of 815 or so packages whereas now more 1100 packages were installed for a Squeeze laptop install with more new packages installed on system upgrades. By the way, this was fortunately my first time to use LVM when partitioning. ;) Nima On Sun, May 23, 2010 at 10:08 PM, Petter Reinholdtsen wrote: > > [Nima Azarbayjany] > > I faced a problem in using Debian Squeeze recently which you should be > > aware of it by now but I'm writing you anyway to make sure it gets > > resolved sooner (if it is not yet). > > Very good. > > > The problem is that using the installer's default partitioning > > scheme nearly 5Gb is allocated to the /usr partition which now seems > > to be too small for a normal Debian system. I have a fresh install > > of Squeeze on my laptop with only a small number of additional > > packages installed. The version of the installer I have used is I > > think not the newest one which also installs recommended packages. > > I suspect you were using the "multi" partman recipe, which specify the > size of /usr/ should be between 500 and 5000 MB, depending on the size > of the hard drive. > > > Nevertheless, I have installed all updates and there is currently > > around 800Mb free space left on the partition. Few days ago I tried > > installing KDevelop (the first KDE software to get installed) and > > its installation went smoothly except that I was prompted with a > > message that there is too low disk space left on /usr although there > > was still 200Mb or so free space on it. The message kept popping up > > regularly. I have now removed KDevelop and all KDE packages upon > > which it depends but this sure is problem which has to be taken care > > of given the larger number of packages installed by default and the > > natural growth of package and distribution sizes. > > For your hard drive, how much space do you believe should have been > used on /usr/? How big is the hard drive? > > > If someone lets me know whether this issue has been resolved and > > what is the default partitioning scheme of the Debian Installer or > > where to fetch this information it can be of great help. Thanks for > > your attention. > > Personally, I always use LVM, which allow me to resize partitions > after installation. It might be a good idea for you too. :) > > Happy hacking, > -- > Petter Reinholdtsen >
Re: lilo removal in squeeze (or, "please test grub2")
On Sun, 23 May 2010, Stephen Powell wrote: > But withdrawing it from the distribution seems like overkill to me, > especially since you want to withdraw it from Squeeze and not > Squeeze+1. Lilo, as it exists today, works just fine for my > purposes. If the maintainer doesn't wish to maintain it for another stable release cycle, and no one steps up to the plate to handle it, it should be removed. It's not like the removal of the package from the next release will cause your "working version" to be removed, after all... and you can presumably install manually later if you actually want it. Don Armstrong -- He was wrong. Nature abhors dimensional abnormalities, and seals them neatly away so that they don't upset people. Nature, in fact, abhors a lot of things, including vacuums, ships called the Marie Celeste, and the chuck keys for electric drills. -- Terry Pratchet _Pyramids_ p166 http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100524030219.gk4...@teltox.donarmstrong.com
Re: lilo removal in squeeze (or, "please test grub2")
On Sun, 23 May 2010 16:11:30 -0400 (EDT), William Pitcock wrote: > "Stephen Powell" wrote: >> (blah blah blah blah) > > Nobody cares if you are opposed to it. Unless you are offering to become > lilo upstream, it's going away. > > William I do understand why a Debian package maintainer does not wish to become "upstream". And I hope that someone who is both willing and able to do so steps up to the plate. But withdrawing it from the distribution seems like overkill to me, especially since you want to withdraw it from Squeeze and not Squeeze+1. Lilo, as it exists today, works just fine for my purposes. And apparently it works just fine for a lot of other people too. The Lord bless you, William. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1170680188.363342.1274662130640.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, "please test grub2")
Hi, - "Stephen Powell" wrote: > (blah blah blah blah) Nobody cares if you are opposed to it. Unless you are offering to become lilo upstream, it's going away. William -- 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/2152114.3751274645490011.javamail.r...@ifrit.dereferenced.org
Re: lilo removal in squeeze (or, "please test grub2")
On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: > > After some discussion about lilo on #debian-devel in IRC, it has pretty > much been determined that kernel sizes have crossed the line past where > lilo can reliably determine the payload size. > > This bug *can* be fixed, but not without a significant rewrite of the > way that lilo's stage2 loader code works. Given that there is no active > upstream and that the Debian lilo package carries many patches for bug > fixes that are alleviated by standardizing on grub2, this seems like the > best option for Debian. > > This means that users should *test grub2 extensively* before Squeeze is > released so that any issues can be resolved now. > > As for removal, the following things need to be done: > > (1) The release notes need to be updated to reflect that lilo is no > longer a bootloader option; > (2) The debian-installer team needs to remove the lilo-installer udeb; > (3) The ftpmasters need to remove lilo from unstable (which will be done > using the appropriate bug filing once the above steps are made); > (4) Users need to test grub2 now. First of all, forgive me for cross-posting, which is generally a no-no. But if you can cross-post, I can cross-reply. Second, unless you reply to debian-user, to which I am subscribed, please CC me. I am not subscribed to any of the other lists. I am not a Debian package maintainer or a Debian developer. I am just an ordinary system administrator. So I'm sure that my opinion will not count for much. But I am opposed to the removal of lilo. Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record (cylinder 0, head 0, sector 1). In other words they use cylinder 0, head 0, sector 2 and possibly subsequent sectors on cylinder 0 head 0. This breaks the design of the backup software that my employer uses. This backup software backs up the master boot record and all partitions; but since the extra sectors used by grub-legacy and grub-pc are outside the master boot record and are not part of any partition, they don't get backed up. Consequently, if we have a hard drive failure and restore from a backup, we have an unbootable machine. Lilo uses only the master boot record. A lilo-booted machine can be backed up and restored with our existing backup software just fine. Given these requirements, I wouldn't use grub-pc even if it were bug free and well documented. (But neither is the case!) As for the claims that kernels are too big now, I find that hard to believe, especially now that we have the large-memory option available. The standard stock Debian kernel image file that I use for Squeeze, vmlinuz-2.6.32-3-686, is currently 2234080 bytes. Are you trying to tell me that there's no room for a 2M kernel below the start of the EBDA? I am able to load *both* the kernel *and* the initial RAM filesystem below the EBDA (i.e. the large-memory option is not used) if I use MODULES=dep instead of MODULES=most in the initial RAM filesystem under Lenny. I'll bet I can do it with Squeeze too. I realize that lilo doesn't work for everyone, and I'm not suggesting that it be the default bootloader; but to get rid of it entirely is unacceptable. As far as I know, it's the only bootloader that meets all of my requirements, and I will not voluntarily give it up. No doubt you will tell me that I am welcome to maintain it myself. Unfortunately, I do not have the requisite skills to do so. All I can do is to appeal in the name of reason that it not be dropped. Also, please excuse my ignorance, but what exactly is this "payload size" to which you refer? Is that the same thing as the size of the kernel? Or is it something else? -- .''`. Stephen Powell : :' : `. `'` `- -- 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/698259750.358730.1274641482395.javamail.r...@md01.wow.synacor.com
Re: A notice to the Debian Installer team...
[Nima Azarbayjany] > I faced a problem in using Debian Squeeze recently which you should be > aware of it by now but I'm writing you anyway to make sure it gets > resolved sooner (if it is not yet). Very good. > The problem is that using the installer's default partitioning > scheme nearly 5Gb is allocated to the /usr partition which now seems > to be too small for a normal Debian system. I have a fresh install > of Squeeze on my laptop with only a small number of additional > packages installed. The version of the installer I have used is I > think not the newest one which also installs recommended packages. I suspect you were using the "multi" partman recipe, which specify the size of /usr/ should be between 500 and 5000 MB, depending on the size of the hard drive. > Nevertheless, I have installed all updates and there is currently > around 800Mb free space left on the partition. Few days ago I tried > installing KDevelop (the first KDE software to get installed) and > its installation went smoothly except that I was prompted with a > message that there is too low disk space left on /usr although there > was still 200Mb or so free space on it. The message kept popping up > regularly. I have now removed KDevelop and all KDE packages upon > which it depends but this sure is problem which has to be taken care > of given the larger number of packages installed by default and the > natural growth of package and distribution sizes. For your hard drive, how much space do you believe should have been used on /usr/? How big is the hard drive? > If someone lets me know whether this issue has been resolved and > what is the default partitioning scheme of the Debian Installer or > where to fetch this information it can be of great help. Thanks for > your attention. Personally, I always use LVM, which allow me to resize partitions after installation. It might be a good idea for you too. :) Happy hacking, -- Petter Reinholdtsen -- 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/2flpr0mzffa@login1.uio.no
A notice to the Debian Installer team...
Hi all, Let me first thank you for your work which has made using the great Debian operating system possible! :-) I faced a problem in using Debian Squeeze recently which you should be aware of it by now but I'm writing you anyway to make sure it gets resolved sooner (if it is not yet). The problem is that using the installer's default partitioning scheme nearly 5Gb is allocated to the /usr partition which now seems to be too small for a normal Debian system. I have a fresh install of Squeeze on my laptop with only a small number of additional packages installed. The version of the installer I have used is I think not the newest one which also installs recommended packages. Nevertheless, I have installed all updates and there is currently around 800Mb free space left on the partition. Few days ago I tried installing KDevelop (the first KDE software to get installed) and its installation went smoothly except that I was prompted with a message that there is too low disk space left on /usr although there was still 200Mb or so free space on it. The message kept popping up regularly. I have now removed KDevelop and all KDE packages upon which it depends but this sure is problem which has to be taken care of given the larger number of packages installed by default and the natural growth of package and distribution sizes. If someone lets me know whether this issue has been resolved and what is the default partitioning scheme of the Debian Installer or where to fetch this information it can be of great help. Thanks for your attention. All the best, Nima -- 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/4bf9589b.6020...@gmail.com
applying the "looking for firmware on CD+DVD" patch to lenny?
Hi, recently #574116 (and #574158) were fixed in sid and IMO it would be very nice to have this patch in lenny too. So I wonder if this is possible and if the SRMs would accept it. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: lilo removal in squeeze (or, "please test grub2")
On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: > William Pitcock (22/05/2010): > > This means that users should *test grub2 extensively* before Squeeze > > is released so that any issues can be resolved now. > > There should also be some folks fixing the discovered issues. grub2 currently seems to be having 18 RC bugs, plus a whole bunch of merged bugs, while lilo only has 1 RC bug. I think the difference is that lilo will probably not work for a lot of people while grub2 does work for a lot of people. And I understand that Debian's lilo maintainer basicly doesn't want to become upstream and rewrite everything when there is an alternative. But I agree that a call for extensive testing would be better if number of RC bugs would be a lot lower. Kurt -- 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/20100523114251.ga3...@roeckx.be
Re: Do you still maintain mouseemu in Debian?
[Gaudenz Steinlin] > AFAIK there are severyl possible ways: > - synclient (only runtime configuration) > - statically in Xorg.conf > - with the gnome-control-panel (and possible by setting some gconf keys) Right. I guess all of these should be handled outside the installer, and will limit hw-detect to install mouseemu. Any idea how to detect such touch pad, to know when to not install mouseemu? Happy hacking, -- Petter Reinholdtsen -- 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/20100523112201.gy4...@login1.uio.no
Re: lilo removal in squeeze (or, "please test grub2")
(Dropping -release, which isn't a discussion list.) William Pitcock (22/05/2010): > Given that there is no active upstream and that the Debian lilo > package carries many patches for bug fixes that are alleviated by > standardizing on grub2, this seems like the best option for Debian. Speaking of upstream and bug fixing, what about that? http://bugs.debian.org/src:grub2 > This means that users should *test grub2 extensively* before Squeeze > is released so that any issues can be resolved now. There should also be some folks fixing the discovered issues. Mraw, KiBi. signature.asc Description: Digital signature
Re: Do you still maintain mouseemu in Debian?
[Gaudenz Steinlin] > I'm not sure if mouseemu (at least in it's current status) should be > activated by default on these machines. I'd prefer to have the two > and three finger tapping acivated by default instead. OK. How is this multifinger tapping activated? How can machines with such touchpad be detected during installation. I assume mouseemu should be installed on macs with a one-button mouse without such touchpad. > Back to mouseemu: I plan to work on at least the RC bug next week. But I > also welcome any contributions from others. Mouseemu is on collab-maint > [1] and any DD should have commit access to the repository. Good to hear that mouseemu will get whipped back into shape. I do not have a Mac myself, so I will not volunteer to work on it. :) Happy hacking, -- Petter Reinholdtsen -- 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/20100523102645.gw4...@login1.uio.no
Re: Do you still maintain mouseemu in Debian?
On Sun, May 23, 2010 at 12:26:45PM +0200, Petter Reinholdtsen wrote: > [Gaudenz Steinlin] > > I'm not sure if mouseemu (at least in it's current status) should be > > activated by default on these machines. I'd prefer to have the two > > and three finger tapping acivated by default instead. > > OK. How is this multifinger tapping activated? How can machines with > such touchpad be detected during installation. I assume mouseemu > should be installed on macs with a one-button mouse without such > touchpad. AFAIK there are severyl possible ways: - synclient (only runtime configuration) - statically in Xorg.conf - with the gnome-control-panel (and possible by setting some gconf keys) Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ signature.asc Description: Digital signature
Bug#516851: hdparm not installed
[Joey Hess] > AFAICS, hdparm is only installed via the laptop task, which pulls in > acpi-support, which depends on hdparm. But there is need for hdparm > on many other systems. OK. Do you propose to install it on all systems, or only some? If some, how do you propose to detect which system need it? Happy hacking, -- Petter Reinholdtsen -- 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/20100523100345.gv4...@login1.uio.no
Re: Do you still maintain mouseemu in Debian?
Hi Petter On Sun, May 23, 2010 at 11:40:39AM +0200, Petter Reinholdtsen wrote: > > Hi, Gaudenz. I am planning to integrate a patch to hw-detect from > Ubuntu, which installs the mouseemu package by default on Mac machines > likely to only have one mouse button. But I notice the Ubuntu version > of mouseemu have a lot of fixes that are missing in the Debian > package, and that it is 3 years since you last uploaded a new version > of mouseemu. RC bugs in the debian package seem to be fixed in > Ubuntu. Are you still maintaining the package? If so, please apply > the available patches to make it fit for release and upload it to > unstable. I still maintain mouseemu (at least in theory), but I agree that my maintenance activity was suboptimal at best in the recent past. Since I no longer use my powerbook as my primary development machine. Also sinde the synaptic touchpad got support for two and three finger tapping mouseemu is not longer strictly necessary to get right and middle clicks on the machines having a touchpad supported by the synaptics driver. I'm not sure if mouseemu (at least in it's current status) should be activated by default on these machines. I'd prefer to have the two and three finger tapping acivated by default instead. Back to mouseemu: I plan to work on at least the RC bug next week. But I also welcome any contributions from others. Mouseemu is on collab-maint [1] and any DD should have commit access to the repository. Gaudenz [1] svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/mouseemu/trunk -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ signature.asc Description: Digital signature
Bug#495676: marked as done (hw-detect: hw-detect new device detection misbehaves with wlan* devices)
Your message dated Sun, 23 May 2010 11:59:58 +0200
with message-id <20100523095958.gu4...@login1.uio.no>
and subject line Re: hw-detect: hw-detect new device detection misbehaves with
wlan* devices
has caused the Debian Bug report #495676,
regarding hw-detect: hw-detect new device detection misbehaves with wlan*
devices
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
495676: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495676
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: hw-detect
Version: 1.65
Severity: important
Hi!
While testing a daily image on a Lenovo R61 with a manually updated
2.6.26 image, I was puzzled when I was asked "Do you intend to use
FireWire Ethernet?" on a machine which has both wired and wireless LAN
cards.
2.6.26 kernels re-introduced the old FireWire stack. So we are back
having the eth1394 module available, and thus FireWire ethernet. That's
why the following issue did not pop up before.
After digging through the logs, I eventually found that every single
card was listed as "FireWire ethernet" in /etc/network/devnames. Next
step was figuring out why could make that happen.
More tests later, I eventually found that this was due to the way
hw-detect finds a new network interface after loading a module.
The list of available interface is known by snapshot_devs()
after sorting the content of the first column in /proc/net/dev,
e.g. "lo eth0".
This list is kept while a new module is loaded, then snapshot_devs() is
called again to get something like "lo eth0 eth1". To compare those
lists and get the new interfaces, compare_devs() is used.
compare_devs() basically currently works by doing:
echo ${devs#$olddevs}
In the previous case, as ethX interfaces are always added at the end,
both lists have the same start, and so compare_devs() nicely output
"eth1".
Unfortunately, thanks to new Wi-Fi stacks, we now have interfaces that
are not named "ethX". On this laptop we get the following:
compare_devs "lo eth0 wlan0 wmaster0" "lo eth0 eth1 wlan0 wmaster0"
not inserted at the end!
I see two possible fixes here:
* Stop sorting devices in snapshot_devs() anymore. I don't see why
the kernel would reorder the content of /proc/net/dev when new
modules are inserted. From my tests, this nicely solved the issue.
* Make compare_dev() able to detect the addition in the middle of the
device list. For the record, modifying compare_devs to use the
following did the trick:
sed="$(echo $olddevs | sed -e 's#\([a-z0-9]\+\) *#s/\1 *//;#g')"
echo $devs | sed -e "$sed"
I tried to dig the history of the repository in order to figure out why
snapshot_dev() used "sort" in the first place, but I was not able to get
any meaningful result. Do anyone have an idea?
Otherwise, removing the sorting sounds like the best option to me.
Cheers,
--
Jérémy Bobbio.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Version: 1.66
This bug was fixed in 2008. No idea why this changelog entry by
Jeremy Babbio failed to close it.
* Fix ethdetect and hw-detect for NICs named differently than ethX.
(Closes: #495676)
Thanks to Frans Pop for suggesting a better implementation.
Closing it now.
Happy hacking,
--
Petter Reinholdtsen
--- End Message ---
Do you still maintain mouseemu in Debian?
Hi, Gaudenz. I am planning to integrate a patch to hw-detect from Ubuntu, which installs the mouseemu package by default on Mac machines likely to only have one mouse button. But I notice the Ubuntu version of mouseemu have a lot of fixes that are missing in the Debian package, and that it is 3 years since you last uploaded a new version of mouseemu. RC bugs in the debian package seem to be fixed in Ubuntu. Are you still maintaining the package? If so, please apply the available patches to make it fit for release and upload it to unstable. CC to debian-boot, to let them know about the issue too. Happy hacking, -- Petter Reinholdtsen -- 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/2flaarr0xd4@login1.uio.no
