Re: Wheezy release: CDs are not big enough any more...
Adam Borowski dixit: if udebs switched to xz (unpacking takes ~10MB memory). -2 takes only 3 MiB, which is about 2 MiB more than gzip, since that number is rounded. bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205221231410.23...@herc.mirbsd.org
Re: Wheezy release: CDs are not big enough any more...
Adam Borowski dixit: using the attached script. Ah, no, don’t use ar to create .deb files. http://www.mirbsd.org/permalinks/wlog-10_e20110818-tg-g10046.htm What you can do is: $ paxtar cAf foo.deb debian-binary control.* data.* It’s in wheezy already. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205221243040.23...@herc.mirbsd.org
Re: Wheezy release: CDs are not big enough any more...
Guillem Jover dixit: the archive override. And if we have to keep changing the packages anyway to make sure they match changing priorities, we might as well just set the compressor (to gzip) explicitly for base packages. Pseudo-essential packages are going to be a problem though. What if a (hypothetical, of course!) package maintainer of an essential package suddenly decides they need to depend on, oh I know, say, ucf? Of course, this situation is purely hypothetical, and ucf would never suddenly become pseudo- essential. (Who *is* the authority telling people off for making other packages pseudo-essential, anyway? I’ve seen it thrice at least already; luckily it was reverted for the instance when someone pulled in the (full) perl package.) bye, //mirabilos -- dileks ch: good, you corrected yourself. ppl tend to tweet such news immediately, sth. like grml devs seem to be buyablech dileks: we _are_. if you throw enough money in our direction, things will happen mika everyone is buyable, it's just a matter of price mrud and now comes [mira] and uses this as a signature ;0 -- they asked for it… -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205221244530.23...@herc.mirbsd.org
Re: Wheezy release: CDs are not big enough any more...
On Tue, 2012-05-22 at 12:44:02 +, Thorsten Glaser wrote: Adam Borowski dixit: using the attached script. Ah, no, don’t use ar to create .deb files. http://www.mirbsd.org/permalinks/wlog-10_e20110818-tg-g10046.htm Using binutils' ar should be considered supported, and works fine with dpkg-deb and dpkg, the accepted format is documented in deb(5). I'd consider any program not following that to be either somewhat buggy, or special purpose (for example dak only accepts a subset of a valid deb format). thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120522182145.ga22...@gaara.hadrons.org
Re: Wheezy release: CDs are not big enough any more...
On Tue, 2012-05-22 at 12:47:01 +, Thorsten Glaser wrote: Guillem Jover dixit: the archive override. And if we have to keep changing the packages anyway to make sure they match changing priorities, we might as well just set the compressor (to gzip) explicitly for base packages. Pseudo-essential packages are going to be a problem though. What if a (hypothetical, of course!) package maintainer of an essential package suddenly decides they need to depend on, oh I know, say, ucf? Of course, this situation is purely hypothetical, and ucf would never suddenly become pseudo- essential. It's not just pseudo-essential, anything pulled into the base set would be affected. In any case that was where my comment was coming from (probably not clearly enough though). Whenever something gets pulled into the base set by something else (another package, an update to the archive override, etc), then there's going to be a time window where the priority in the .deb and the archive override will not match, and the package will need to be modified to accommodate that change. So such possible conditional handling in dpkg-deb (with which I'm not comfortable with, because it's encoding non-generic policy into the tool) would not help anyway, at which point I'd say it makes more sense to just explicitly call dpkg-deb with -Zgzip for base packages. (Who *is* the authority telling people off for making other packages pseudo-essential, anyway? I’ve seen it thrice at least already; luckily it was reverted for the instance when someone pulled in the (full) perl package.) I'd say debian-devel, either because most of the time this implies a Pre-Depends anyway, or because it's just promoting something into the Essential set. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120522193600.gb22...@gaara.hadrons.org
Re: Wheezy release: CDs are not big enough any more...
Guillem Jover dixit: Ah, no, don’t use ar to create .deb files. http://www.mirbsd.org/permalinks/wlog-10_e20110818-tg-g10046.htm Using binutils' ar should be considered supported, and works fine with dpkg-deb and dpkg, the accepted format is documented in deb(5). I'd The problem is that binutils’ ar generates SYSV style filenames for members since the switch to ELF, while the deb format uses BSD style filenames. Nowadays, tools like apt-extracttemplates support both, but it’s not so long it didn’t (e.g. on hardy). If you use “GNUTARGET=a.out-i386-linux ar rc …” you get a suitable archive… on an i386 host; on other hosts, the $GNUTARGET to use differs. (Hence support for BSD/deb(5) style ar(5) archives in paxtar and, I think I’ve read, (free)bsdtar.) bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205222008510.6...@herc.mirbsd.org
Re: Wheezy release: CDs are not big enough any more...
On 2012-05-19 00:52 +0200, Adam Borowski wrote: On Fri, May 18, 2012 at 12:27:15PM -0400, Joey Hess wrote: Guillem Jover wrote: Only as long as the debian/control information matches the one from the archive override. I checked, and currently the only base package with an overridden priority is libsigc++-2.0-0c2a So, would it be safe to make dpkg-deb default to xz if priority is important for wheezy? It wouldn't, because not all required or important packages actually have the correct priority. For instance, insserv has priority optional but is a dependency of sysv-rc which is required. In general, switching to xz compression by default will make it impossible to debootstrap testing/unstable if the host system does not have the xzcat command, because often packages become part of the base system without further notice. Cheers, Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87396w3aun@turtle.gmx.de
Re: Wheezy release: CDs are not big enough any more...
+++ Mehdi Dogguy [2012-05-16 16:24 +0200]: On 16/05/12 13:41, Wookey wrote: is there any reason not to just upload this to Debian? There are ITPs filed for it: - http://bugs.debian.org/582884 - http://bugs.debian.org/576359 Yes. I discovered that when I went to file an ITP :-) It turns out that there is a problem preventing upload. The rather generic name 'usb-creator' was objected-to and a request made to change it to 'startup-disk-creator' (The name the app shows). Upload seems to be stalled on changing the name of the launchpad project to give matching source and binary names. This seems well-meaning but has the unfortunate effect that nothign has happened for a year, despite several people expressing an interst in uploading. I also tested it with a debian installer image and found that it is bust due to a load of ugly code dealing with the syslinux transition from 2.3x to 2.4x around Ubuntu 10.04-10.10 (generating old images whilst running on a new machine, and vice versa, different package and different syntax). It blows up on debian due to 'GNU/Linux' not being a valid version. As we don't even have syslinux-legacy in Debian all this mess should probably just be thrown away. https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1000527 My python-foo wasn't up to actually fixing it myself. Nor do I know how important it is to keep this sort of old-release compatibility (how old?). Anyone with the enthusiasm to fix the upstream-renaming thing, or this code (not hard, just fiddly) could get this into Debian promptly I think. Wookey -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518121724.gu11...@stoneboat.aleph1.co.uk
Re: Wheezy release: CDs are not big enough any more...
Guillem Jover wrote: Only as long as the debian/control information matches the one from the archive override. I checked, and currently the only base package with an overridden priority is libsigc++-2.0-0c2a -- 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...
On Fri, May 18, 2012 at 12:27:15PM -0400, Joey Hess wrote: Guillem Jover wrote: Only as long as the debian/control information matches the one from the archive override. I checked, and currently the only base package with an overridden priority is libsigc++-2.0-0c2a So, would it be safe to make dpkg-deb default to xz if priority is important for wheezy? My point is, the sooner this change is made, the more of the pre-release upload spike will benefit from reduced package size. It can be then changed by either improving debootstrap (unlikely due to old versions) or the base-ness check. Also, lintian currently doesn't complain if a base package uses xz. Should it? This check wouldn't be very useful since priority override is the only interesting case, though. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Thu, 17 May 2012 04:36:40 +0200 Adam Borowski kilob...@angband.pl wrote: On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote: Can someone set the default to xz and recompile all of Debian or at least base and create a repository from that for install tests? There's no need to recompile anything. You can recompress existing packages using the attached script. .. and then spend a huge amount of time rebuilding your now broken pool/ and archive because none of the checksums match ... Do you have a patch for dak to go alongside your script to update all checksums for all binaries across all architectures? What about packages which are the same version in wheezy and in squeeze - now you're looking at making a new point release with all packages across all suites changing checksums. Then once wheezy is out, we'll just have another round with the next release because packages just keep getting fatter. Stop investing time in stop gap measures - we need a durable solution and that is likely to mean dropping GNOME and KDE as an option for CD#1. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpALWVSNRSqw.pgp Description: PGP signature
Re: Wheezy release: CDs are not big enough any more...
On 17.05.2012 07:54, Neil Williams wrote: On Thu, 17 May 2012 04:36:40 +0200 Adam Borowski kilob...@angband.pl wrote: On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote: Can someone set the default to xz and recompile all of Debian or at least base and create a repository from that for install tests? There's no need to recompile anything. You can recompress existing packages using the attached script. What about packages which are the same version in wheezy and in squeeze - now you're looking at making a new point release with all packages across all suites changing checksums. SRM would need an awful lot of convincing that doing that was anything other than a really bad idea. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/edd7c0607eeb8483c213f32dda8af...@mail.adsl.funky-badger.org
Re: Wheezy release: CDs are not big enough any more...
On Thu, May 17, 2012 at 07:54:17AM +0100, Neil Williams wrote: On Thu, 17 May 2012 04:36:40 +0200 Adam Borowski kilob...@angband.pl wrote: On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote: Can someone set the default to xz and recompile all of Debian or at least base and create a repository from that for install tests? There's no need to recompile anything. You can recompress existing packages using the attached script. .. and then spend a huge amount of time rebuilding your now broken pool/ and archive because none of the checksums match ... Do you have a patch for dak to go alongside your script to update all checksums for all binaries across all architectures? What about packages which are the same version in wheezy and in squeeze Goswin asked for a way to test d-i and friends with xz .debs, and this script works well for that task, removing the need for recompiling. No one proposes replacing packages in the archive without bumping the version number, that'd be a recipe for disaster. Although, if I understand what David Kalnischkies says in https://lists.debian.org/debian-devel/2012/05/msg00706.html, having packages with different size/global checksum but identical contents (control.tar, data.tar) in local repositories (apt-cdrom, reprepro, ...) shouldn't be a problem as well. Stop investing time in stop gap measures How exactly is greatly reducing download sizes a stop gap measure? Obviously, several releases later the savings will be eaten, but without them the bloat will be that much bigger. That's the long-term benefit, and that it also solves a short-term problem (CD1) is a reason to switch to xz before wheezy. we need a durable solution and that is likely to mean dropping GNOME and KDE as an option for CD#1. While dropping GNOME3 is a very sweet idea -- its main mode fails to work on a good part of, even new, machines, not degrading gracefully; its fallback mode is a bad joke, it Depends: network-manager (ie, Conflicts: working networking), and so on, not to even start about more subjective opinions about changes to the UI -- reducing the size of CD1 to 2/3 would easily solve the problem for now and last for a few Debian releases, and by then, CDs will go away the way floppies did. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Hi, Steve McIntyre st...@einval.com wrote: Remembering the fun that we had during the Squeeze release with trying to make single-CD installations work well, it's time to consider what we're going to *claim* to support in Wheezy. We've had a history of supporting the following single-CD installations: * Gnome desktop from CD#1 * KDE desktop from KDE CD#1 * XFCE desktop from light CD#1 * LXDE desktop from light CD#1 * base system only from netinst CD FYI: With the alpha1 images, it is not possible, to do an installation from only one CD image and without internet access, getting an X system as result. When using Alpha1 Binary-CD #1 Alpha1 KDE CD Alpha1 xfce-lxde CD and, as said before, having no internet access while installing, you are only provided the Standard system tools task, no Desktop environment is provided. See #673200. If you knew this already, sorry for the noise. Holger -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Powered by Sylpheed 3.0.2 under Debian GNU/ / _ _ _ _ _ __ __ / /__ / / / \// //_// \ \/ / // /_/ /_/\/ /___/ /_/\_\6.0 / Squeeze. Registered LinuxUser #311290 - http://counter.li.org/ = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120517224902.9a3a4552.li...@wansing-online.de
Re: Wheezy release: CDs are not big enough any more...
On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote: Can someone set the default to xz and recompile all of Debian or at least base and create a repository from that for install tests? I tested it a bit, both with bare debootstrap into a chroot, and by recompressing all debs on a d-i CD (netinst i386, CD1 amd64). All went ok. I did not test fancy options in d-i (probably pointless, either unpacking debs works or not), nor special firmwares (what hardware requires those? Do they come from udebs or debs?). And of course, this doesn't solve the issue of first stage of debootstrap on foreign systems without xz. Are those ever going to touch packages with priority important? -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Sun, 2012-05-13 at 18:47:01 -0400, Joey Hess wrote:
Adam Borowski wrote:
Special-casing base packages would be a lot of complexity, let's avoid that
if possible -- but still preferred to letting gzip stay.
Base packages can be identified at build time by their priority.
if ($priority ne 'important' $priority ne 'required') {
}
Only as long as the debian/control information matches the one from
the archive override. And if we have to keep changing the packages
anyway to make sure they match changing priorities, we might as well
just set the compressor (to gzip) explicitly for base packages.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120518024612.ga20...@gaara.hadrons.org
Re: Wheezy release: CDs are not big enough any more...
Bjørn Mork bj...@mork.no writes: No, you don't. On a default Debian system you need to be a member of the floppy group. From /lib/udev/rules.d/91-permissions.rules : Yeah but you are not a member of that group by default surely? You mean that they allow you to burn a CD but not write to a USB stick? Yes, I understood this was the default. If you put users to floppy group then remote users can read usb sticks of local users. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84pqa4xzis@sauna.l.org
Re: Wheezy release: CDs are not big enough any more...
Timo Juhani Lindfors timo.lindf...@iki.fi writes:
Wookey woo...@wookware.org writes:
And the USB-stick process is not as simple as it might be because you
have to find the HD-media files and then _also_ find an iso image to
put on. It's no wonder newbs are still downloading CD/DVD images.
You also need to have root access to some machine to create the USB
media.
No, you don't. On a default Debian system you need to be a member of
the floppy group. From /lib/udev/rules.d/91-permissions.rules :
# default permissions for block devices
SUBSYSTEM==block, GROUP=disk
SUBSYSTEM==block, ATTRS{removable}==1, GROUP=floppy
This means you can't create the installation media at most
university or library machines unlike with CDs.
You mean that they allow you to burn a CD but not write to a USB stick?
Sounds like they have a support problem which I don't think Debian can
solve for them.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk98a480@nemi.mork.no
Re: Wheezy release: CDs are not big enough any more...
Timo Juhani Lindfors timo.lindf...@iki.fi writes: Bjørn Mork bj...@mork.no writes: No, you don't. On a default Debian system you need to be a member of the floppy group. From /lib/udev/rules.d/91-permissions.rules : Yeah but you are not a member of that group by default surely? No, that decision should be left to the adminstrator. The point was that you don't need to be root, and you probably never should be when doing something like that (to prevent being only one typo away from disaster). You mean that they allow you to burn a CD but not write to a USB stick? Yes, I understood this was the default. If you put users to floppy group then remote users can read usb sticks of local users. I fail to see how burning to a local user's CD is any better, but yes, if that is a consideration then they need some system to tie the rights to console access. I believe ConsoleKit and the replacement systemd-loginctl attempts to solve such problems. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwb0a0fj@nemi.mork.no
Re: Wheezy release: CDs are not big enough any more...
On 05/16/2012 06:10 AM, Timo Juhani Lindfors wrote: Bjørn Mork bj...@mork.no writes: No, you don't. On a default Debian system you need to be a member of the floppy group. From /lib/udev/rules.d/91-permissions.rules : Yeah but you are not a member of that group by default surely? $ debconf-show user-setup ... passwd/user-default-groups: audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth ... At least the initial user created by user-setup at install time will be in this group. That would cover everyone with self-administrated systems, which I would hazard a guess would be most of our audience. So while we can't assume every user has access, we could at least recommend in the doc that the command be executed as an ordinary user where possible to avoid accidental harm. Ben -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb38743.7040...@sanctuary.nslug.ns.ca
Re: Wheezy release: CDs are not big enough any more...
On Wed, 16 May 2012 07:53:55 -0300 Ben Armstrong sy...@sanctuary.nslug.ns.ca wrote: On 05/16/2012 06:10 AM, Timo Juhani Lindfors wrote: Bjørn Mork bj...@mork.no writes: No, you don't. On a default Debian system you need to be a member of the floppy group. From /lib/udev/rules.d/91-permissions.rules : Yeah but you are not a member of that group by default surely? $ debconf-show user-setup ... that listing isn't available on Squeeze ... If we're to document this, it would need to be as-per Squeeze. passwd/user-default-groups: audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth floppy is in my `groups` on Squeeze (scanner is not but the rest on the list above are). dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth dialout and sudo explicitly added, rest are the defaults IIRC. At least the initial user created by user-setup at install time will be in this group. That would cover everyone with self-administrated systems, which I would hazard a guess would be most of our audience. So while we can't assume every user has access, we could at least recommend in the doc that the command be executed as an ordinary user where possible to avoid accidental harm. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpRZUidabRlY.pgp Description: PGP signature
Re: Wheezy release: CDs are not big enough any more...
Thomas Schmitt scdbac...@gmx.net writes: I am a bit scared by the catastrophic potential of cat debian.iso /dev/sdX for X = valuable hard disk. What about recommending /dev/disk/by-id/usb-X instead? -- Feri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4ukwgk6@szonett.ki.iif.hu
Re: Wheezy release: CDs are not big enough any more...
Bjørn Mork bj...@mork.no writes: I fail to see how burning to a local user's CD is any better, but yes, if that is a consideration then they need some system to tie the rights to console access. I believe ConsoleKit and the replacement systemd-loginctl attempts to solve such problems. Yes, I believe usb-creator package in ubuntu does exactly this, it lets local users create USB installation media. Unfortunately even that is by default only allowed for admins. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84liksxt1l@sauna.l.org
Re: Wheezy release: CDs are not big enough any more...
+++ Timo Juhani Lindfors [2012-05-15 21:01 +0300]: Yes, turns out I failed to read the instructions right, presumably due to thinking I knew how this worked (i.e. you can't just put an iso stright onto a USB stick, and you need 'hd-media' for USB sticks). I'm glad to see that this has got significantly simpler. ubuntu uses the usb-creator package to provide a dbus api that allows normal users to create usb installation media. (It carefully checks that you can not write to the internal hard disk). I think this is what most inexpert users would like to see - a reasonably idiot-proof GUI tool for downloading an installer image and putting it on the USB stick for them. usb-creator is in ubuntu but not Debian for no good reason. It has already had Debian support added. One of the uploaders, and the person who added the Debian support is a DD: Dmitrijs Ledkovs. Dmitri - is there any reason not to just upload this to Debian? I see a couple of places in the UI where it says 'Ubuntu' and it would be good if it got a bit cleverer and put in the appropriate string with dpkg-vendor, as it already does for the logo files. I also fixed up the build so it skips the not-present dh-translations on Debian, and otherwise modified the deps for Debian. I'll do some testing tonight when I have USB sticks to hand. There are probably quite a few useful utilities like this in Ubuntu universe that should get uploaded. Wookey -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516114114.gj11...@stoneboat.aleph1.co.uk
Re: Wheezy release: CDs are not big enough any more...
Joey Hess jo...@debian.org writes:
Adam Borowski wrote:
Could you please mention which ones do not? And if so, how are they
relevant/are they fixable?
As one of the maintainers of debootstrap, I am perhaps more aware than
some how broadly it's used. Ok..
They use it on Android (41,600 hits including
http://evilzone.org/android/debian-on-android/)
They use it on Nokia (96,600 hits)
They use it on Nook (14,000 hits)
They use it on headless old Red Hat systems in a datacenter somewhere
They use it on Debian oldstable systems, where xz-utils is not even packaged.
They use it on absolutely modern peices of unusual kit that ship with some
crufty busybox binary (no source naturally) from far up the supplier
chain, that was built well before xz support entered busybox in 2010.
How are they relevant? Where do they download and unpack udebs? Where is
busybox used to unpack debs?
Special-casing base packages would be a lot of complexity, let's avoid that
if possible -- but still preferred to letting gzip stay.
Base packages can be identified at build time by their priority.
if ($priority ne 'important' $priority ne 'required') {
}
Although I do think that rebuilding the entire archive at this point in
the release process is probably going to result in a lot of ..
complexity. For one, d-i relies on being able to unpack firmware .debs
The code that does this doesn't support data.tar.xz. There are probably
plenty more problems where that came from.
Can someone set the default to xz and recompile all of Debian or at
least base and create a repository from that for install tests?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk98pa11.fsf@frosties.localnet
Re: Wheezy release: CDs are not big enough any more...
On Wed, 16 May 2012, Wookey wrote: this to Debian? I see a couple of places in the UI where it says 'Ubuntu' and it would be good if it got a bit cleverer and put in the If Ubuntu sponsored the creation of usb-creator, we can package it that way just fine, as long as the trademark license for Ubuntu allows us to do that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516141221.gb30...@khazad-dum.debian.net
Re: Wheezy release: CDs are not big enough any more...
On 16/05/12 13:41, Wookey wrote: is there any reason not to just upload this to Debian? There are ITPs filed for it: - http://bugs.debian.org/582884 - http://bugs.debian.org/576359 Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb3b89b.2030...@debian.org
Re: Wheezy release: CDs are not big enough any more...
[CC'ing Hans-Christoph in case he isn't following this list] On 12-05-16 at 02:47pm, Goswin von Brederlow wrote: Joey Hess jo...@debian.org writes: Adam Borowski wrote: Could you please mention which ones do not? And if so, how are they relevant/are they fixable? As one of the maintainers of debootstrap, I am perhaps more aware than some how broadly it's used. Ok.. They use it on Android (41,600 hits including http://evilzone.org/android/debian-on-android/) They use it on Nokia (96,600 hits) They use it on Nook (14,000 hits) They use it on headless old Red Hat systems in a datacenter somewhere They use it on Debian oldstable systems, where xz-utils is not even packaged. They use it on absolutely modern peices of unusual kit that ship with some crufty busybox binary (no source naturally) from far up the supplier chain, that was built well before xz support entered busybox in 2010. How are they relevant? Where do they download and unpack udebs? Where is busybox used to unpack debs? Perhaps this example is relevant: http://guardianproject.info/code/lildebi/ @Hans-Christoph: Does that project use a debootstrap without xz support, and would its tricks break if Debian was to switch to compress its binary packages with xz instead of gzip? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Bjørn Mork wrote:
Timo Juhani Lindfors timo.lindf...@iki.fi writes:
You also need to have root access to some machine to create the USB
media.
No, you don't. On a default Debian system you need to be a member of
the floppy group. From /lib/udev/rules.d/91-permissions.rules :
# default permissions for block devices
SUBSYSTEM==block, GROUP=disk
SUBSYSTEM==block, ATTRS{removable}==1, GROUP=floppy
Yep.
This means you can't create the installation media at most
university or library machines unlike with CDs.
You mean that they allow you to burn a CD but not write to a USB stick?
Sounds like they have a support problem which I don't think Debian can
solve for them.
On large installations (think computing cluster), adding untrusted
users to the floppy group is not a great idea, since then they would
have remote access to removable media other users insert. For CDs
and DVDs, consolekit addresses the problem out of the box and roughly
speaking lets each user access media that they have inserted. Last
time I checked[1] (a while ago), the same rules did not apply to USB
sticks.
Hope that helps,
Jonathan
[1] http://bugs.debian.org/585463
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120516153715.GA17460@burratino
Re: Wheezy release: CDs are not big enough any more...
Jonathan Nieder jrnie...@gmail.com writes: speaking lets each user access media that they have inserted. Last time I checked[1] (a while ago), the same rules did not apply to USB sticks. Yes, this is the point I was trying to make in the first place :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84boloxh7s@sauna.l.org
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 09:00:29PM -0500, Peter Samuelson wrote: [Steve McIntyre] The major win with dd onto a raw device is that you can specify the block size. For most USB sticks, using a block size of 4MB or so is going to be *much* faster than using the default for dd (512 bytes) or cp (10 KB IIRC). That seemed a little fishy to me, since none of the above commands do any fsync by default, so I just benched it locally. Writing a 50 MB businesscard image to a USB flash drive on my system (numbers are MB/s): dd bs=512 1.771.781.77 dd bs=1024 1.791.761.77 dd bs=2048 1.771.781.78 dd bs=4096 2.542.532.51 dd bs=8192 2.482.502.55 dd bs=4194304 2.502.502.54 cp 2.492.472.48 So it appears that if you aren't going to specify a bs= parameter here, there's no point in using dd, unless you just happen to think its command line syntax is particularly charming. And even if you do specify bs=, you'll only barely beat cp. You're not measuring the time taken to sync to the flash drive either, so all you're going to be seeing is the speed of writing to cache. I've done lots of work with USB flash and MMC/SD cards over the last few years, and the best results are typically achieved using dd bs=4M oflag=sync. That way, you'll normally get nicely-aligned date writes big enough to cover the internal flash page size and remove the horrendous effects of read-modify-write cycles. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516155205.gc3...@einval.com
Re: Wheezy release: CDs are not big enough any more...
Hi, Bjørn Mork bj...@mork.no wrote: On a default Debian system you need to be a member of the floppy group. Ferenc Wagner wf...@niif.hu wrote: What about recommending /dev/disk/by-id/usb-X instead? I understand that the instructions about creating a Debian installation medium shall be usable on as many systems as possible, not only on already installed Debian systems. USB stick on a pre-udev SuSE: brw-r- 1 root disk 8, 32 2012-05-15 20:18 /dev/sdb USB stick on FreeBSD 8: crw-rw-r-- 1 root floppy 0, 124 May 15 20:13 /dev/da0 On Solaris it seems to be: lrwxrwxrwx 1 root root 60 Jun 8 2010 /dev/dsk/c5t0d0p0 - ../../devices/pci@0,0/pci1458,5004@13,2/storage@4/disk@0,0:q br 1 root root 83, 272 Jun 8 2010 /devices/pci@0,0/pci1458,5004@13,2/storage@4/disk@0,0:q I fail to find a device file with any w-permission in the c5t0d0 family of /dev/dsk or /dev/rdsk. (When i was younger, Solaris looked more like Unix.) There is a script http://src.opensolaris.org/source/raw/livemedia/livemedia/usbcopy which finds the USB stick and writes some data onto the stick while issueing several error messages. But the stick afterwards does not bear the data which i gave as input image to the script. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1273991356404283...@scdbackup.webframe.org
Re: Wheezy release: CDs are not big enough any more...
On May 16, 2012, at 10:49 AM, Jonas Smedegaard wrote: [CC'ing Hans-Christoph in case he isn't following this list] On 12-05-16 at 02:47pm, Goswin von Brederlow wrote: Joey Hess jo...@debian.org writes: Adam Borowski wrote: Could you please mention which ones do not? And if so, how are they relevant/are they fixable? As one of the maintainers of debootstrap, I am perhaps more aware than some how broadly it's used. Ok.. They use it on Android (41,600 hits including http://evilzone.org/android/debian-on-android/) They use it on Nokia (96,600 hits) They use it on Nook (14,000 hits) They use it on headless old Red Hat systems in a datacenter somewhere They use it on Debian oldstable systems, where xz-utils is not even packaged. They use it on absolutely modern peices of unusual kit that ship with some crufty busybox binary (no source naturally) from far up the supplier chain, that was built well before xz support entered busybox in 2010. How are they relevant? Where do they download and unpack udebs? Where is busybox used to unpack debs? Perhaps this example is relevant: http://guardianproject.info/code/lildebi/ @Hans-Christoph: Does that project use a debootstrap without xz support, and would its tricks break if Debian was to switch to compress its binary packages with xz instead of gzip? It was originally using some ancient busybox binary without xz support. Since we are now building busybox from source, we should be able to easily include busybox's xz. So if busybox's xz works for .debs, then it should work ok. For the record, LilDebi does not use busybox's 'dpkg-deb' because it doesn't work with debootstrap. I haven't really looked into why because using 'ar' works. .hc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/350b5dd5-4310-4fc4-9ee2-bebed712c...@eds.org
Use cases for CD installs (Re: Wheezy release: CDs are not big enough any more...)
Steve Langasek wrote: On Sun, May 13, 2012 at 10:26:13PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: On Dom 13 May 2012 21:40:10 Marco d'Itri escribió: [snip] Does anybody actually know that people routinely try to install desktop systems with only a CD and no networking, and why? What is the use case for this? Cheap DVD readers have been around for over 10 years now. Actually, I was going to ask exactly that. To the best of my knowledge, CDROM players have been out of stock for a while (more than two years?) Normally people will buy a DVDROM player. Well, at least here in Argentina :-/ Could it be reasonable to drop graphical desktops environments for one-CD installs? If you want a GDE, get the DVD. Or two or more CDs. As a data point, the 12.10 Ubuntu release, which is in about the same time frame as wheezy, will not include a CD-sized desktop image. After holding this line for a long time, it's been decided that we've passed the point of diminishing returns and that *slowly* allowing an increase in image size (e.g., 800MB for this cycle instead of 736MB) allows us to define the default install in terms of what's useful instead of just in terms of what we can fit on a CD. So to use the image you need either a DVD or a USB stick, and if you're using a write-once DVD you're perhaps wasting the unused space; but the download time and install footprint are still kept low and in the range of what a CD would give. Maybe worth considering something similar for Debian. Interesting. I was going to suggest doing the same. I do not know people regularly trying to install on desktop systems with only a CD drive and no (software) networking. I do use CD isos, however. I regularly download the KDE CD 1. The reason why I'm not using the netinst instead is that I save install time, and sometimes some download when I test the CD on several PCs. But, if I write the iso to a CD, that's only because I would need to stand up to reach the rewritable DVDs (due to an historical artifact of my desk's setup) and because I'm going to install to a machine where USB sticks are more painful to boot (but the last machine I had for which this was the case died recently). So for me, the interest of CD 1 is that it approximates fairly well the package set I'm going to end up installing - more than either netinsts or DVD 1. If I had another media scoring equally well on that front, I would only consider fitting on a CD as an extremely marginally useful feature. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb3efe4.2060...@gmail.com
Re: Wheezy release: CDs are not big enough any more...
Goswin von Brederlow wrote: Joey Hess jo...@debian.org writes: Adam Borowski wrote: Could you please mention which ones do not? And if so, how are they relevant/are they fixable? As one of the maintainers of debootstrap, I am perhaps more aware than some how broadly it's used. Ok.. They use it on Android (41,600 hits including http://evilzone.org/android/debian-on-android/) They use it on Nokia (96,600 hits) They use it on Nook (14,000 hits) They use it on headless old Red Hat systems in a datacenter somewhere They use it on Debian oldstable systems, where xz-utils is not even packaged. They use it on absolutely modern peices of unusual kit that ship with some crufty busybox binary (no source naturally) from far up the supplier chain, that was built well before xz support entered busybox in 2010. How are they relevant? Where do they download and unpack udebs? Where is busybox used to unpack debs? In the above message it is debootstrap. -- see shy jo signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
[Steve McIntyre] You're not measuring the time taken to sync to the flash drive either, so all you're going to be seeing is the speed of writing to cache. Huh, I figured the 'sync' call at the end of each test run covered that. I've done lots of work with USB flash and MMC/SD cards over the last few years, and the best results are typically achieved using dd bs=4M oflag=sync. That way, you'll normally get nicely-aligned date writes big enough to cover the internal flash page size and remove the horrendous effects of read-modify-write cycles. Not noticeable in my test runs, so maybe I have an abnormal flash disk. (The fact that it has a USB interface, rather than something closer to the flash controller, probably makes a difference.) Anyway, I've never been against people recommending things like dd bs=4M oflag=sync when writing to disk media. My pet peeve is when people recommend dd but without any options other than if= and of=. It is clear that many such people don't have a clue _why_ they use dd, except an irrational, dare I say cargo-cult, aversion to cp with block devices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516220409.gg2...@p12n.org
Re: Wheezy release: CDs are not big enough any more...
On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote: Can someone set the default to xz and recompile all of Debian or at least base and create a repository from that for install tests? There's no need to recompile anything. You can recompress existing packages using the attached script. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon #!/bin/sh set -e if [ $# -eq 0 ] then cat 2 END Usage: $0 foo.deb [bar.deb ...] If there's more than one package, almost always you'd want instead: parallel $0 -- foo.deb bar.deb Packages already using xz are blindly repacked anyway; this ensures they can be decompressed using 10MB memory (as opposed to 65MB for xz -9), but is otherwise a waste of time. END exit 1 fi for F in $@ do [ -f $F ] || (echo 2 No such file: $F exit 1) DIR=.$F$ rm -rf $DIR mkdir $DIR cd $DIR ar x ../$F debian-binary control.tar.gz dpkg-deb --fsys-tarfile ../$F|xz data.tar.xz rm ../$F ar rcD ../$F debian-binary control.tar.gz data.tar.xz cd .. rm -rf $DIR done signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Mon, May 14, 2012 at 05:56:54PM -0700, Russ Allbery wrote: Installed-Size is generated automatically by dpkg-buildpackage, so the only way that you'd get a package without it is by manually creating a package, which nearly no one does. So in practice it's always there, although it might not be a bad idea to make that clear in Policy. I think dpkg-deb does, too. At least, my no-debhelper, no-dpkg-buildpackage package doom-wad-shareware still ends up with Installed-Size. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515091825.GC24635@debian
Re: Wheezy release: CDs are not big enough any more...
On Mon, May 14, 2012 at 09:34:39AM -0700, Steve Langasek wrote: So to use the image you need either a DVD or a USB stick, and if you're using a write-once DVD you're perhaps wasting the unused space; but the download time and install footprint are still kept low and in the range of what a CD would give. In the UK at least, the price of a CD-R and a DVD+R is approximately the same, although CD-Rs are becoming rarer in brick-and-mortar shops. I still attempt to use CD-R media when burning install discs, but that's only if I happen to have some (and I don't mind the wasted space burning netinst to a 700M CD-R). I think what I'm saying is I agree with you for my use-cases at least. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515092100.GD24635@debian
Re: Wheezy release: CDs are not big enough any more...
Hi, On Mon, May 14, 2012 at 09:34:39AM -0700, Steve Langasek wrote: So to use the image you need either a DVD or a USB stick, and if you're using a write-once DVD you're perhaps wasting the unused space; but the download time and install footprint are still kept low and in the range of what a CD would give. my biggest gripe with DVDs is that they decay so quickly. A DVD, being only a few months old, has already a high risk of being non-functional, while a CD easily lasts more than a year. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515093147.ga4...@spruce.wiehl.oeko.net
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 10:18:25AM +0100, Jon Dowland wrote: On Mon, May 14, 2012 at 05:56:54PM -0700, Russ Allbery wrote: Installed-Size is generated automatically by dpkg-buildpackage, so the only way that you'd get a package without it is by manually creating a package, which nearly no one does. So in practice it's always there, although it might not be a bad idea to make that clear in Policy. I think dpkg-deb does, too. At least, my no-debhelper, no-dpkg-buildpackage package doom-wad-shareware still ends up with Installed-Size. dget http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc The policy doesn't require Installed-Size, so goodbye is compliant (by design :p), but it's not a big stretch to assume everything in the archive is built with dpkg-deb. And besides, why are we talking about Installed-Size in the first place? Recompressing data.tar.gz doesn't alter the tarball's contents, it doesn't even unpack it or go through tar at all. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Le Tue, May 15, 2012 at 11:57:15AM +0200, Adam Borowski a écrit : And besides, why are we talking about Installed-Size in the first place? Because I asked a question off-topic in that thread without breaking it. Apologies for this confusion. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515100504.gb26...@falafel.plessy.net
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 2:56 AM, Russ Allbery r...@debian.org wrote: Charles Plessy ple...@debian.org writes: Le Tue, May 15, 2012 at 01:54:53AM +0200, David Kalnischkies a écrit : And the fields defining a difference in versions are: Installed-Size, Depends, Pre-Depends, Conflicts, Breaks and Replaces. Differences in all other fields are ignored (as they are not guaranteed to be present - the status file e.g. misses the deb filesize as well as checksums for obvious reasons). Installed-Size is not marked as mandatory or recommended in the Debian policy. Do you think this is something to be corrected ? http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles Installed-Size is generated automatically by dpkg-buildpackage, so the only way that you'd get a package without it is by manually creating a package, which nearly no one does. So in practice it's always there, although it might not be a bad idea to make that clear in Policy. It's not a problem per-se if the Installed-Size field isn't there, it will just be ignored - not like a missing Package field APT will complain big time about and is therefore mandatory. Haven't checked but dpkg properly doesn't care at all for this field. An archive creator extracts the size from the control file for the Packages file, so it will usually have the same value (or none), so this shouldn't generate different versions at all, but even if it does the worst which can happen is that APT will schedule a package for upgrade again and again. The only missing/wrong bit of information will be the line in apt-get output informing a user how much space will be used/freed by this operation. It's a bit of a stretch to make a field recommend just for this use, so i didn't consider that an issue, but i wouldn't argue about it being added to the recommend set either. The more interesting really pathetic issue is that this section doesn't make non-empty Depends (and co) mandatory (advanced question: would Recommends, Suggests and Enhances be it as well?), but if these fields are missing if they shouldn't you are properly doing something very wrong anyway and deserve some pain… (a commit from 1999 commenting out Recommends and Suggests in this code suggests that both could go away if different tools are used) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fC=dLK6qsFSA2bM-_u6TVBCt8bYio_Qbz1bBbfd...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
[ re-adding CC to debian-cd and debian-boot ] Adam Borowski wrote: On Sat, May 12, 2012 at 05:04:16PM +0100, Steve McIntyre wrote: Hey folks, Remembering the fun that we had during the Squeeze release with trying to make single-CD installations work well, it's time to consider what we're going to *claim* to support in Wheezy. We've had a history of supporting the following single-CD installations: * Gnome desktop from CD#1 * KDE desktop from KDE CD#1 At this point, I'm skeptical that either of the first two are going to work acceptably with Wheezy. There is an easy solution: switch binary packages to xz compression. amd64's CD 1 is reduced to 2/3 of its current size (data from June(?) 2010). OK. That'll help in the short term, I guess. But I've no idea how long it will take for package builds to make a dent on this organically (i.e. without a deliberate rebuild effort). I'm expecting that we'll still struggle to get a *good* Gnome or KDE installation from a single CD regardless. We've managed a minimal set in the past, but I'd rather we give a good impression with a basic Debian installation than come up with something that *only* just fits. Related, I'm also pondering about: 1. Which installer images it makes sense to provide for wheezy We currently provide a huge set of different images: * business card and netinst images for (almost) all architectures, in both iso and jigdo formats * a full set of normal CDs for all arches: + all as iso and jigdo for amd64, i386 and source + some as iso and jigdo for other arches, with the remaining as jigdo only * two extra CDs for all arches (KDE and light) in both iso and jigdo formats * a full set of DVDs for all arches: + all as iso and jigdo for amd64, i386 and source + #1 as iso and jigdo for other arches, with the remaining as jigdo only * a full set of BDs and D-L BDs for amd64, i386 and source: + all as jigdo only The current wheezy d-i alpha release gives an idea for how big Debian is getting here - there are 71 CDs in the full amd64 set (!), or 10 DVDs. It's very tempting to switch amd64, i386 and source to the same partial-iso state as the other arches. 2. USB-targeted images I've also tweaked DVD#1 of each set to fit in 4GB instead of the normal 4.7GB, so that it fits on a 4GB USB stick to make it more useful. We could quite readily produce (say) 2GB images specifically designed for smaller USB sticks if enough people consider that to be useful. I'm thinking that would be a specific single extra image. Thoughts? 3. Which installer image(s) should we link to as preferred? We're currently linking to the multi-arch amd64/i386 netinst CD from the front of www.debian.org. I think that's still a good choice, but I'm open to being convinced otherwise. 4. What to do with s390(x) I'm about to ask this on their mailing list... -- Steve McIntyre, Cambridge, UK.st...@einval.com You can't barbecue lettuce! -- Ellie Crane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1suh0w-0002sc...@mail.einval.com
Re: Wheezy release: CDs are not big enough any more...
+++ Steve McIntyre [2012-05-15 13:38 +0100]: [ re-adding CC to debian-cd and debian-boot ] 2. USB-targeted images I've also tweaked DVD#1 of each set to fit in 4GB instead of the normal 4.7GB, so that it fits on a 4GB USB stick to make it more useful. We could quite readily produce (say) 2GB images specifically designed for smaller USB sticks if enough people consider that to be useful. I'm thinking that would be a specific single extra image. Thoughts? I have always installed from USB stick (or SD card) on everything for the last several years. It must be 4 years since I used a CD or DVD. Especially on dev boards (x86 or arm) that is usually the only medium slot you have. I assume this is common. And the USB-stick process is not as simple as it might be because you have to find the HD-media files and then _also_ find an iso image to put on. It's no wonder newbs are still downloading CD/DVD images. Only last night I tried to install current testing to an intel dev board. I tried using unetbootin which is a great way of making the USB-key install process less cryptic, but for some reason it failed to get unstable images, and could only manage testing ones. (I'll check that and file a bug tonight). I think we could usefully focus on making the USB-stick/MMC card experience simple as that covers an awful lot of modern use-cases. It currently feels like a bit of a 'poor relation'. That might mean recommending the use of Unetbootin (and making sure it works), or providing complete say 2G and 4G images and some simple way of burning them. Maybe a 'debianised' version of unetbootin that just provides debian images and hides most of the gory details, but will help stop you shooting yourself in the foot? It looks to me like we have all the parts for that, it's just the emphasis needs changing, or maybe even just the docs updating (I may not be doing this the easiest way - it's not totally obvious from the debian download page what to do - AIUI you have to read the install docs, and understand to download the hd-media files (either the image gzip or the files) and an iso from somewhere else and put it all on the stick.) 3. Which installer image(s) should we link to as preferred? We're currently linking to the multi-arch amd64/i386 netinst CD from the front of www.debian.org. I think that's still a good choice, but I'm open to being convinced otherwise. add a netinst USB image would be a good thing IMHO. Along with the equivalent tool to a CDburner to make it painless. Maybe even make netinst USB sticks the default over CDs? And try to hide the 'hd-media' name at least in initial download selection, because it is geek-accurate, but rather confusing to a newcomer. Wookey -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515142459.gf11...@stoneboat.aleph1.co.uk
Re: Wheezy release: CDs are not big enough any more...
Wookey woo...@wookware.org writes: And the USB-stick process is not as simple as it might be because you have to find the HD-media files and then _also_ find an iso image to put on. It's no wonder newbs are still downloading CD/DVD images. You also need to have root access to some machine to create the USB media. This means you can't create the installation media at most university or library machines unlike with CDs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84ehqlzf8u@sauna.l.org
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 10:25 PM, Wookey wrote: And the USB-stick process is not as simple as it might be because you have to find the HD-media files and then _also_ find an iso image to put on. It's no wonder newbs are still downloading CD/DVD images. I thought HD-media was a thing of the past with the newish isohybrid stuff where you just cat the ISO to the device? Pretty sure thats what I did for the last install I did. Fedora/RH folks recently added more hacks to isohybrid to support booting on Macs: http://mjg59.dreamwidth.org/11285.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6hn1vwgl9164yc+uvcavglygltf2n9gj+ophp8jvky...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
Le lundi 14 mai 2012 à 17:56 -0700, Russ Allbery a écrit : Installed-Size is generated automatically by dpkg-buildpackage, so the only way that you'd get a package without it is by manually creating a package, which nearly no one does. So in practice it's always there, although it might not be a bad idea to make that clear in Policy. It is a very bad idea to rely on Installed-Size being the same, since its value, being computed with du(1) can vary depending on the filesystem the package is built upon. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337095907.3589.291.camel@pi0307572
Re: Wheezy release: CDs are not big enough any more...
On Tue, 15 May 2012 22:34:20 +0800, Paul Wise wrote: And the USB-stick process is not as simple as it might be because you have to find the HD-media files and then _also_ find an iso image to put on. It's no wonder newbs are still downloading CD/DVD images. I thought HD-media was a thing of the past with the newish isohybrid stuff where you just cat the ISO to the device? Pretty sure thats what I did for the last install I did. Same here. My last install with an USB stick (2 months ago) must have been as easy as dd'ing or cat'ing the ISO to a device since I don't remember any details or even problems, and I'm quite sure I didn't hunt down any additional files or used any non-standard tools. (I think it was a testing image from February or something similar, in case they are different Ah, I still have it, debian-testing-amd64-netinst.iso, downloaded on March 4th.) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: David Bowie: Fashion signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 06:13:24PM +0200, gregor herrmann wrote: On Tue, 15 May 2012 22:34:20 +0800, Paul Wise wrote: And the USB-stick process is not as simple as it might be because you have to find the HD-media files and then _also_ find an iso image to put on. It's no wonder newbs are still downloading CD/DVD images. I thought HD-media was a thing of the past with the newish isohybrid stuff where you just cat the ISO to the device? Pretty sure thats what I did for the last install I did. Same here. My last install with an USB stick (2 months ago) must have been as easy as dd'ing or cat'ing the ISO to a device since I don't remember any details or even problems, and I'm quite sure I didn't hunt down any additional files or used any non-standard tools. (I think it was a testing image from February or something similar, in case they are different Ah, I still have it, debian-testing-amd64-netinst.iso, downloaded on March 4th.) Just checking with wookey on irc, he downloaded the image and read the instructions (http://www.debian.org/releases/stable/amd64/ch04s03.html.en) but skipped straight past section 4.3.1. Looks like we could do with a big clear message DO THIS UNLESS YOU HAVE SPECIAL NEEDS to make it more obvious. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with Valor: Centurion represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515162306.gc2...@einval.com
Re: Wheezy release: CDs are not big enough any more...
Hi, Fedora/RH folks recently added more hacks to isohybrid to support booting on Macs: http://mjg59.dreamwidth.org/11285.html This is achieved by applying ISOLINUX program isohybrid from a recent ISOLINYX version to the already produced ISO images. syslinux-4.05 should probably do. It is a daring mix of MBR, Apple Partition Map, GPT, and El Torito. It seems to be specific to i386 and amd54 architectures. You need to provide a VFAT image for EFI, and a HFS+ image for Mac. I have meanwhile documented it on byte level in http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt#L398 (paragraph SYSLINUX isohybrid for UEFI and x86-Mac) xorriso will hopefully be able to do this trick together with jigdo production, if the MBR template file stems from a suitable ISOLINUX version. (It has to reserve its first 32 bytes for a mock-up of an APM Block0.) Implementation has begun but will last a bit longer because the backup GPT at the end of the image does not yet fit into the architecture of libisofs. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7679991407981802...@scdbackup.webframe.org
Re: Wheezy release: CDs are not big enough any more...
Hi, Steve McIntyre wrote: (http://www.debian.org/releases/stable/amd64/ch04s03.html.en) but skipped straight past section 4.3.1. Looks like we could do with a big clear message DO THIS UNLESS YOU HAVE SPECIAL NEEDS to make it more obvious. :-) I am a bit scared by the catastrophic potential of cat debian.iso /dev/sdX for X = valuable hard disk. Maybe one should advise people to first read a few MB from the stick and watch it blinking, before one uses that address for writing dd if=/dev/sdX of=/dev/null bs=1M count=100 Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/806991405299738...@scdbackup.webframe.org
Re: Wheezy release: CDs are not big enough any more...
[Steve McIntyre] (http://www.debian.org/releases/stable/amd64/ch04s03.html.en) While it is refreshing to see cat debian.iso /dev/sdX instead of the usual dd nonsense (it seems there's an extremely widespread myth that you need to use dd any time you're reading or writing block devices), I think cp is even more straightforward. Bonus: you can easily run it with sudo. (sudo cat debian.iso /dev/sdX does not do what a novice might think.) Though I suppose it might be annoying to those who feel the need for alias cp='cp -i' in .bashrc. But hey, it's their choice to be annoyed by things like this. (: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515174055.gd2...@p12n.org
Re: Wheezy release: CDs are not big enough any more...
On 05/15/2012 02:18 PM, Thomas Schmitt wrote: I am a bit scared by the catastrophic potential of cat debian.iso /dev/sdX for X = valuable hard disk. I've wondered about that, too, when working on the relevant section of the Debian Live Manual. Maybe one should advise people to first read a few MB from the stick and watch it blinking, before one uses that address for writing dd if=/dev/sdX of=/dev/null bs=1M count=100 Interesting approach. As for me, I just never write to a USB key as root unless I'm absolutely sure I need to. (Yes, I could still trash the wrong USB attached storage, but that's likely less catastrophic than what I could accomplish as the superuser.) What I wonder, though, is if it is universally true that ordinary users will always have write access to a USB key they've just inserted. Under what circumstances will they not? Keep in mind, the user may very well be writing the USB from some non-Debian system. Ben -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb2964b.6010...@sanctuary.nslug.ns.ca
Re: Wheezy release: CDs are not big enough any more...
Peter Samuelson, le Tue 15 May 2012 12:40:55 -0500, a écrit : (http://www.debian.org/releases/stable/amd64/ch04s03.html.en) While it is refreshing to see cat debian.iso /dev/sdX instead of the usual dd nonsense (it seems there's an extremely widespread myth that you need to use dd any time you're reading or writing block devices), Except that cat is often aliased with the -v option, not a good idea :) Also, the sudo issue alone made us switch to dd instead, see the svn version of the manual. I think cp is even more straightforward. Does cp accept that way since a long time? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515174648.gb4...@type.famille.thibault.fr
Re: Wheezy release: CDs are not big enough any more...
Ben Armstrong sy...@sanctuary.nslug.ns.ca writes: accomplish as the superuser.) What I wonder, though, is if it is universally true that ordinary users will always have write access to a USB key they've just inserted. Under what circumstances will they not? At least in default debian and ubuntu systems they don't have such write access. ubuntu uses the usb-creator package to provide a dbus api that allows normal users to create usb installation media. (It carefully checks that you can not write to the internal hard disk). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84aa19z5l8@sauna.l.org
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 02:45:47PM -0300, Ben Armstrong wrote: On 05/15/2012 02:18 PM, Thomas Schmitt wrote: I am a bit scared by the catastrophic potential of cat debian.iso /dev/sdX for X = valuable hard disk. I've wondered about that, too, when working on the relevant section of the Debian Live Manual. Maybe one should advise people to first read a few MB from the stick and watch it blinking, before one uses that address for writing dd if=/dev/sdX of=/dev/null bs=1M count=100 Interesting approach. As for me, I just never write to a USB key as root unless I'm absolutely sure I need to. (Yes, I could still trash the wrong USB attached storage, but that's likely less catastrophic than what I could accomplish as the superuser.) What I wonder, though, is if it is universally true that ordinary users will always have write access to a USB key they've just inserted. Under what circumstances will they not? Keep in mind, the user may very well be writing the USB from some non-Debian system. ls /dev/disk/by-id/usb-* #? Hopefully the system is not run from a USB storage device. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515180700.gx26...@pear.tzafrir.org.il
Re: Wheezy release: CDs are not big enough any more...
On Tue, 2012-05-15 at 17:31:47 +0200, Josselin Mouette wrote: Le lundi 14 mai 2012 à 17:56 -0700, Russ Allbery a écrit : Installed-Size is generated automatically by dpkg-buildpackage, so the only way that you'd get a package without it is by manually creating a package, which nearly no one does. So in practice it's always there, although it might not be a bad idea to make that clear in Policy. It is a very bad idea to rely on Installed-Size being the same, since its value, being computed with du(1) can vary depending on the filesystem the package is built upon. Not anymore since dpkg 1.16.1 which switched dpkg-gencontrol to use --apparent-size. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515182736.ga1...@gaara.hadrons.org
Re: Wheezy release: CDs are not big enough any more...
On Tue, 2012-05-15 at 10:18:25 +0100, Jon Dowland wrote: On Mon, May 14, 2012 at 05:56:54PM -0700, Russ Allbery wrote: Installed-Size is generated automatically by dpkg-buildpackage, so the only way that you'd get a package without it is by manually creating a package, which nearly no one does. So in practice it's always there, although it might not be a bad idea to make that clear in Policy. I think dpkg-deb does, too. At least, my no-debhelper, no-dpkg-buildpackage package doom-wad-shareware still ends up with Installed-Size. Only dpkg-gencontrol does that. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515182827.gb1...@gaara.hadrons.org
Re: Wheezy release: CDs are not big enough any more...
[Samuel Thibault] I think cp is even more straightforward. Does cp accept that way since a long time? I'm not sure, but I've been using things like cp boot.img /dev/fd0 for probably 10 or 15 years on various Linux and Unix systems. (The fact that I referred to a floppy drive may give some idea of how long) I am not sure where the idea came from that reading or writing block devices always requires 'dd', but if I were to guess, I'd say we can blame tape drives (which aren't even block devices, but char devices). As I recall, you can choose the block size when you format or write a tape, and maybe there are ancient systems out there in which userspace must be explicit when reading and writing them. (Normally, though, I _think_ you just tell the kernel tape driver the right parameters using, e.g. 'mt', then let it handle writing full blocks.) Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515230005.ge2...@p12n.org
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 12:40:55PM -0500, Peter Samuelson wrote: [Steve McIntyre] (http://www.debian.org/releases/stable/amd64/ch04s03.html.en) While it is refreshing to see cat debian.iso /dev/sdX instead of the usual dd nonsense (it seems there's an extremely widespread myth that you need to use dd any time you're reading or writing block devices), I think cp is even more straightforward. Bonus: you can easily run it with sudo. (sudo cat debian.iso /dev/sdX does not do what a novice might think.) You *can* do that, yes. The major win with dd onto a raw device is that you can specify the block size. For most USB sticks, using a block size of 4MB or so is going to be *much* faster than using the default for dd (512 bytes) or cp (10 KB IIRC). cat using the shell redirection is often going to be using a small size (1 page?). -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515231849.ga3...@einval.com
Re: Wheezy release: CDs are not big enough any more...
[Steve McIntyre]
The major win with dd onto a raw device is that you can specify the
block size. For most USB sticks, using a block size of 4MB or so is
going to be *much* faster than using the default for dd (512 bytes)
or cp (10 KB IIRC).
That seemed a little fishy to me, since none of the above commands do
any fsync by default, so I just benched it locally.
Writing a 50 MB businesscard image to a USB flash drive on my system
(numbers are MB/s):
dd bs=512 1.771.781.77
dd bs=1024 1.791.761.77
dd bs=2048 1.771.781.78
dd bs=4096 2.542.532.51
dd bs=8192 2.482.502.55
dd bs=4194304 2.502.502.54
cp 2.492.472.48
So it appears that if you aren't going to specify a bs= parameter here,
there's no point in using dd, unless you just happen to think its
command line syntax is particularly charming. And even if you do
specify bs=, you'll only barely beat cp.
For completeness, the same test writing a small file (1 MB),
unsurprisingly, is quite inconclusive:
dd bs=512 1.441.040.98
dd bs=1024 1.001.061.04
dd bs=2048 0.821.041.05
dd bs=4096 1.301.311.35
dd bs=8192 1.061.521.56
dd bs=4194304 1.191.281.27
cp 1.141.291.27
--
Peter
#!/bin/sh
infile=/tmp/debian-6.0.2.1-amd64-businesscard.iso
MB=$(stat -c'scale=2; %s/1048576' $infile | bc)
outfile=/dev/sdd
test_start () {
label=$1
sudo sysctl vm.drop_caches=1 /dev/null # probably not really needed
t0=$(date +%s.%N)
}
test_end () {
sync
echo $label : $(echo scale=2; $MB / ($(date +'%s.%N') - $t0) | bc) MB/s
}
for n in $(seq 1 3); do
for sz in 512 1024 2048 4096 8192 $((1024*4096)); do
test_start bs=$sz
dd bs=$sz if=$infile of=$outfile 2 /dev/null
test_end
done
test_start cp
cp $infile $outfile
test_end
done
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120516020029.gf2...@p12n.org
Re: Wheezy release: CDs are not big enough any more...
On Mon, May 14, 2012 at 12:40:10AM +0100, Neil Williams wrote: 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 was under the impression that GNOME3 fit onto one CD with recent Fedora releases, but I am having trouble verifying that. (Fedora 16 Desktop Edition has at least some of GNOME3 + things like LibreOffice in a LiveCD configuration, with the CD image clocking in at 605M, so with headroom!) So it's not impossible. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514083318.GB12666@debian
Re: Wheezy release: CDs are not big enough any more...
On May 14, Jonas Smedegaard d...@jones.dk wrote: It is my impression from my visits in the Fall (although I do not have any hard data to support it) that in India and Indonesia network access is generally so slow that even if computers have DVD drives the common media downloaded and used is CD. This does not look like a great argument: when your internet access is really slow then you either download one image and share it between user (and then it does not matter if it is a CD or DVD, since the incremental cost per user is negligible), or you just download the netinstall image to minimize the number of bytes you need to download from the network to what you strictly need (yes, I did a few modem netinstalls...). -- ciao, Marco signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Mon, May 14, 2012 at 09:33:18AM +0100, Jon Dowland wrote: On Mon, May 14, 2012 at 12:40:10AM +0100, Neil Williams wrote: 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 was under the impression that GNOME3 fit onto one CD with recent Fedora releases, but I am having trouble verifying that. (Fedora 16 Desktop Edition has at least some of GNOME3 + things like LibreOffice in a LiveCD configuration, with the CD image clocking in at 605M, so with headroom!) So it's not impossible. Yes. https://fedoraproject.org/wiki/Features/XZRpmPayloads They use xz for all RPMs since Fedora 12 (late 2009). Let's say the idea of switching debs to xz is not that novel :p -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On 12-05-14 at 11:22am, Marco d'Itri wrote: On May 14, Jonas Smedegaard d...@jones.dk wrote: It is my impression from my visits in the Fall (although I do not have any hard data to support it) that in India and Indonesia network access is generally so slow that even if computers have DVD drives the common media downloaded and used is CD. This does not look like a great argument: when your internet access is really slow then you either download one image and share it between user (and then it does not matter if it is a CD or DVD, since the incremental cost per user is negligible), or you just download the netinstall image to minimize the number of bytes you need to download from the network to what you strictly need (yes, I did a few modem netinstalls...). Yes, computer resources and software can be dealt with more sensibly and efficient than is currently practiced at many places in the World. Yes, I have also installed whole networks via 28.8 modem quite some years ago. But question was if people are known to routinely try to install desktop systems with only a CD and no networking, and I shared my insight on that. I wish people would collaborate more. I wish people would care more about efficient use of resources. I did not claim that there was great sense behind that usage pattern, but I do claim that it is reality in some parts of the World. But until let's make Debian easy available also for those who are not yet as wise and clever as ourselves. Let's keep providing CDs as install medium, because it is still relevant for some (and, I vaguely feel, not only exotically few) real use cases to install non-bloated desktop at places with flaky/expensive Internet. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On 14.05.2012 12:30, Jonas Smedegaard wrote: Let's keep providing CDs as install medium, because it is still relevant for some (and, I vaguely feel, not only exotically few) real use cases to install non-bloated desktop at places with flaky/expensive Internet. Having different default desktops installed depending on which install media you download, sucks. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Wheezy release: CDs are not big enough any more...
On 14.05.2012 03:29, Samuel Thibault wrote: I haven't tried myself, but gnome3 most probably introduced non-accessible custom widgets, buttons without labels, etc. For instance, the alt-F2 widget, used a lot by blind people, is currently inaccessible... GNOME 3.4 has seen a lot of effort put into improving accessibility support, especially gnome-shell. Once we have a complete 3.4 stack, it would be great if you can give it another try and report any issues. The Debian GNOME team is very interested in providing good accessibibity support and this is an important issue for us. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Wheezy release: CDs are not big enough any more...
Michael Biebl bi...@debian.org wrote: GNOME 3.4 has seen a lot of effort put into improving accessibility support, especially gnome-shell. Once we have a complete 3.4 stack, it would be great if you can give it another try and report any issues. There are a number of us on the debian-accessibility list who will indeed test it. The accessibility improvements to XFCE to which Samuel referred are introduced in version 4.10. However, I haven't read any reports about it from testers and I'm dealing with other issues at the moment, hence I haven't tried it myself. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514112746.ga29...@jdc.jasonjgw.net
Re: Wheezy release: CDs are not big enough any more...
Le 14/05/12 12:39, Michael Biebl a écrit : On 14.05.2012 12:30, Jonas Smedegaard wrote: Let's keep providing CDs as install medium, because it is still relevant for some (and, I vaguely feel, not only exotically few) real use cases to install non-bloated desktop at places with flaky/expensive Internet. Having different default desktops installed depending on which install media you download, sucks. Michael Not if you label the media properly: Light Desktop CD1 Standard Desktop CD2 (to be downloaded in addition to CD1) Standard Desktop DVD1 Netinst etc... It looks to me that people who really need to refrain from downloading more than a single CD are likely to possess older hardware and therefore to prefer a lightweight desktop anyway. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb0f077.8050...@free.fr
Re: Wheezy release: CDs are not big enough any more...
On Sun, May 13, 2012 at 06:47:01PM -0400, Joey Hess wrote:
Adam Borowski wrote:
Could you please mention which ones do not? And if so, how are they
relevant/are they fixable?
As one of the maintainers of debootstrap, I am perhaps more aware than
some how broadly it's used. Ok..
They use it on [lots of stuff].
Ie, the problem is not in d-i, but in running debootstrap on foreign
systems. And that's indeed not easily fixable :(
Special-casing base packages would be a lot of complexity, let's avoid that
if possible -- but still preferred to letting gzip stay.
Base packages can be identified at build time by their priority.
if ($priority ne 'important' $priority ne 'required') {
}
That's overinclusive (not a fatal problem), and could be potentially
underinclusive (when a base package switches to a library of a lower
priority), but it's still a viable short-term solution.
Although I do think that rebuilding the entire archive at this point in
the release process is probably going to result in a lot of ..
complexity.
I believe even the usual pre-release flurry of uploads would free enough
space, and if not, nudging a few big packages would. There's no need to
recompress EVERYTHING now. And as time goes, gzipped binaries would
gradually die out.
On the other hand, recompressing existing packages is not a good idea in any
place that can simultaneously see both files, and with apt-cdrom, that's
any. Ie, this possibility is out.
For one, d-i relies on being able to unpack firmware .debs
The code that does this doesn't support data.tar.xz.
I've seen your commits, so I guess this problem is no more. Thanks :)
--
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon
signature.asc
Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On May 14, Adam Borowski kilob...@angband.pl wrote: Ie, the problem is not in d-i, but in running debootstrap on foreign systems. And that's indeed not easily fixable :( Do we actually have an official debootstrap package for foreign systems? We could ship a static busybox with it and solve this and other issues. (I know, not all the world is a VAX, etc... But we cannot solve *every* problem.) If the problem is foreign systems without xz then we will never be able to use XZ for base. -- ciao, Marco signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Lun 14 May 2012 07:30:30 Jonas Smedegaard escribió: [snip] I wish people would collaborate more. I wish people would care more about efficient use of resources. Me too :-) I did not claim that there was great sense behind that usage pattern, but I do claim that it is reality in some parts of the World. 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). Let's keep providing CDs as install medium, because it is still relevant for some (and, I vaguely feel, not only exotically few) real use cases to install non-bloated desktop at places with flaky/expensive Internet. Yes. And having installation media that needs two or more CDs for Standard desktop foo seems not a bad idea. Also, we can suggest people to try and get the DVD instead of the two mediums ;-) Regards, Lisandro. -- La política es una actividad noble. Hay que revalorizarla, ejerciéndola con vocación y una dedicación que exige testimonio, martirio, o sea, morir por el bien común. Padre Bergoglio - http://www.lanacion.com.ar/1153060 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Wheezy release: CDs are not big enough any more...
Marco d'Itri wrote: Do we actually have an official debootstrap package for foreign systems? We could ship a static busybox with it and solve this and other issues. We don't really. When you look around, a variety of ad-hoc methods are used to install debootstrap on foreign systems. The simplest of these is to download its source tarball and run it, which the README tells how to do. That needs make and MAKEDEV std, so it's also not uncommon for the deb or udeb to be manually unpacked by someone and turned into a $foo Debian installer (Android, etc). -- 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: Wheezy release: CDs are not big enough any more...
On Sun, May 13, 2012 at 10:26:13PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: On Dom 13 May 2012 21:40:10 Marco d'Itri escribió: [snip] Does anybody actually know that people routinely try to install desktop systems with only a CD and no networking, and why? What is the use case for this? Cheap DVD readers have been around for over 10 years now. Actually, I was going to ask exactly that. To the best of my knowledge, CDROM players have been out of stock for a while (more than two years?) Normally people will buy a DVDROM player. Well, at least here in Argentina :-/ Could it be reasonable to drop graphical desktops environments for one-CD installs? If you want a GDE, get the DVD. Or two or more CDs. As a data point, the 12.10 Ubuntu release, which is in about the same time frame as wheezy, will not include a CD-sized desktop image. After holding this line for a long time, it's been decided that we've passed the point of diminishing returns and that *slowly* allowing an increase in image size (e.g., 800MB for this cycle instead of 736MB) allows us to define the default install in terms of what's useful instead of just in terms of what we can fit on a CD. So to use the image you need either a DVD or a USB stick, and if you're using a write-once DVD you're perhaps wasting the unused space; but the download time and install footprint are still kept low and in the range of what a CD would give. Maybe worth considering something similar for Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Mon, May 14, 2012 at 6:39 AM, Michael Biebl wrote: On 14.05.2012 12:30, Jonas Smedegaard wrote: Let's keep providing CDs as install medium, because it is still relevant for some (and, I vaguely feel, not only exotically few) real use cases to install non-bloated desktop at places with flaky/expensive Internet. Having different default desktops installed depending on which install media you download, sucks. A new default would of course be universal (i.e. it would be common across any installation method). The other desktop environments would be available as options in the boot menu (given that the user has the additional CDs, a network mirror, or a DVD). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MO8-80EF7xfKUK+J5f5OfCy4Oq=2+m_w3r+4nf3tq-...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
Hi, 2012/5/14, Marco d'Itri m...@linux.it: On May 14, Adam Borowski kilob...@angband.pl wrote: Ie, the problem is not in d-i, but in running debootstrap on foreign systems. And that's indeed not easily fixable :( Do we actually have an official debootstrap package for foreign systems? We could ship a static busybox with it and solve this and other issues. (I know, not all the world is a VAX, etc... But we cannot solve *every* problem.) If the problem is foreign systems without xz then we will never be able to use XZ for base. How about switching to xz in the standard installer and providing an alternate installer with recompressed packages using gzip/bz2? This would allow us to support most systems and save on bandwidth/mirror space. Cheers, Balint -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cak0odpz22hykynctp+3vp10oj0q8r5p_tr2s+gofz12zqcm...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
On Sat, May 12, 2012 at 11:30:12PM +0200, Marco d'Itri wrote: On May 12, Adam Borowski kilob...@angband.pl wrote: Thus, let's just switch dpkg-deb's default to xz. Lowering bandwidth usage is worth the extra build time cost. Agreed, this looks like a good idea. -- ciao, Marco The only problem with xz as a default: I can currently unpack a .deb on any Unix system which has ar - and I did, no more than a week ago, in order to find Debian documentation and licences to pass to legal people. xz might, potentially, cause more problems. All the best, AndyC -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514213322.gc2...@galactic.demon.co.uk
Re: Wheezy release: CDs are not big enough any more...
On Mon, May 14, 2012 at 09:33:34PM +0200, Bálint Réczey wrote: 2012/5/14, Marco d'Itri m...@linux.it: Do we actually have an official debootstrap package for foreign systems? We could ship a static busybox with it and solve this and other issues. (I know, not all the world is a VAX, etc... But we cannot solve *every* problem.) If the problem is foreign systems without xz then we will never be able to use XZ for base. How about switching to xz in the standard installer and providing an alternate installer with recompressed packages using gzip/bz2? This would allow us to support most systems and save on bandwidth/mirror space. Bad idea, I'm afraid. Apt really dislikes seeing two packages with the same version but a different file size and checksum. You'd have to make sure that alternate installer never mixes its sources with regular packages. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514224606.gb1...@angband.pl
Re: Wheezy release: CDs are not big enough any more...
Le Mon, May 14, 2012 at 10:33:22PM +0100, Andrew M.A. Cater a écrit : On Sat, May 12, 2012 at 11:30:12PM +0200, Marco d'Itri wrote: On May 12, Adam Borowski kilob...@angband.pl wrote: Thus, let's just switch dpkg-deb's default to xz. Lowering bandwidth usage is worth the extra build time cost. Agreed, this looks like a good idea. -- ciao, Marco The only problem with xz as a default: I can currently unpack a .deb on any Unix system which has ar - and I did, no more than a week ago, in order to find Debian documentation and licences to pass to legal people. xz might, potentially, cause more problems. Dear Andrew, for more than 6,500 source packages, you will find everything you need in the Git repository indicated by the package tracking system. A few more packages have their full source managed in other VCSes that are also indicated at the same place. Otherwise, the Debian copyright file is available separately for all the packages through packages.debian.org, and it is rare that the upstream source is available only in xz-compressed format. I hope it helps to mitigate the potential problem. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514224623.gb24...@falafel.plessy.net
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 12:46 AM, Adam Borowski kilob...@angband.pl wrote: On Mon, May 14, 2012 at 09:33:34PM +0200, Bálint Réczey wrote: 2012/5/14, Marco d'Itri m...@linux.it: Do we actually have an official debootstrap package for foreign systems? We could ship a static busybox with it and solve this and other issues. (I know, not all the world is a VAX, etc... But we cannot solve *every* problem.) If the problem is foreign systems without xz then we will never be able to use XZ for base. How about switching to xz in the standard installer and providing an alternate installer with recompressed packages using gzip/bz2? This would allow us to support most systems and save on bandwidth/mirror space. Bad idea, I'm afraid. Apt really dislikes seeing two packages with the same version but a different file size and checksum. You'd have to make sure that alternate installer never mixes its sources with regular packages. Where dislikes means it will upgrade to the first version (defined by sources.list order) with the highest pin (hint: the status file is the last source and pinned to 100), which is the reason for overriding self-build-with-same-version packages: These are usually not in a repository and therefore the last version in the listing. And the fields defining a difference in versions are: Installed-Size, Depends, Pre-Depends, Conflicts, Breaks and Replaces. Differences in all other fields are ignored (as they are not guaranteed to be present - the status file e.g. misses the deb filesize as well as checksums for obvious reasons). So in essence: You have a good chance that gz and xz packages will have the same install size and therefore be treated as equal (assuming that xz packages will be unpacked and repacked as gzip). If packages are rebuild to pack them in gzip the install-size might differ, in that case the version from the first mentioned source will be installed. Beside maybe wasting bandwidth in that case (for the sake of same version for everyone in general) a pretty well defined behavior from my POV. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbr_8a1thg+pre-4cnuweenom9el07m+w+jw__svgc...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
Le Tue, May 15, 2012 at 01:54:53AM +0200, David Kalnischkies a écrit : And the fields defining a difference in versions are: Installed-Size, Depends, Pre-Depends, Conflicts, Breaks and Replaces. Differences in all other fields are ignored (as they are not guaranteed to be present - the status file e.g. misses the deb filesize as well as checksums for obvious reasons). Hello David, Installed-Size is not marked as mandatory or recommended in the Debian policy. Do you think this is something to be corrected ? http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515002743.ga25...@falafel.plessy.net
Re: Wheezy release: CDs are not big enough any more...
Charles Plessy ple...@debian.org writes: Le Tue, May 15, 2012 at 01:54:53AM +0200, David Kalnischkies a écrit : And the fields defining a difference in versions are: Installed-Size, Depends, Pre-Depends, Conflicts, Breaks and Replaces. Differences in all other fields are ignored (as they are not guaranteed to be present - the status file e.g. misses the deb filesize as well as checksums for obvious reasons). Installed-Size is not marked as mandatory or recommended in the Debian policy. Do you think this is something to be corrected ? http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles Installed-Size is generated automatically by dpkg-buildpackage, so the only way that you'd get a package without it is by manually creating a package, which nearly no one does. So in practice it's always there, although it might not be a bad idea to make that clear in Policy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nri6z3d@windlord.stanford.edu
Re: Wheezy release: CDs are not big enough any more...
On Sun, May 13, 2012 at 02:06:25AM +0200, Guillem Jover wrote: Also if udeb:s are going to be using xz then it makes even more sense to use it for everything. µdebs won't use the xz default, though. (The compression for them will be handled in debhelper.) With the compression scheme I posted to -boot it doesn't need more memory than gzip while still compressing better. I don't see any trouble in activating xz for amd64/i386 immediately before the release, if the problem with the core packages is solved. (I.e. debootstrap avoiding any ties to xz or avoiding the compression of core packages.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Sun, May 13, 2012 at 09:27:26AM +0200, Philipp Kern wrote: On Sun, May 13, 2012 at 02:06:25AM +0200, Guillem Jover wrote: Also if udeb:s are going to be using xz then it makes even more sense to use it for everything. µdebs won't use the xz default, though. (The compression for them will be handled in debhelper.) With the compression scheme I posted to -boot it doesn't need more memory than gzip while still compressing better. I don't see any trouble in activating xz for amd64/i386 immediately before the release, if the problem with the core packages is solved. (I.e. debootstrap avoiding any ties to xz or avoiding the compression of core packages.) Except that busybox has xz support, and is loaded from an udeb way before any regular debs are seen. Ie, there is no reason to stop core packages from using decent compression. There's no reason to keep it to amd64/i386 as well -- in fact, it's i386 which is most likely to use unassisted install with extremely low memory. I'm not aware of armel/mips boxes with 64MB ram that load d-i themselves. So if i386 can handle it, everything else can. The extra computation cost is paid on buildds, not the user's machine. Also, to solve the CD1 problem, dpkg-deb would have to switch _soon_, letting a big enough part of packages to be naturally rebuilt. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
Adam Borowski wrote: Except that busybox has xz support, and is loaded from an udeb way before any regular debs are seen. Ie, there is no reason to stop core packages from using decent compression. Yes there is. busybox is used on a variety of systems, which are unlikely to have xz installed. The small benefit of better compressing base does not justify narrowing the set of systems on which busybox can be used. There's no reason to keep it to amd64/i386 as well -- in fact, it's i386 which is most likely to use unassisted install with extremely low memory. I'm not aware of armel/mips boxes with 64MB ram that load d-i themselves. Many arm systems have 64 mb of ram or less. -- see shy jo signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Sunday, May 13, 2012 12:42:46, Joey Hess wrote: Adam Borowski wrote: Except that busybox has xz support, and is loaded from an udeb way before any regular debs are seen. Ie, there is no reason to stop core packages from using decent compression. Yes there is. busybox is used on a variety of systems, which are unlikely to have xz installed. The small benefit of better compressing base does not justify narrowing the set of systems on which busybox can be used. There's no reason to keep it to amd64/i386 as well -- in fact, it's i386 which is most likely to use unassisted install with extremely low memory. I'm not aware of armel/mips boxes with 64MB ram that load d-i themselves. Many arm systems have 64 mb of ram or less. The NSLU2 boxes that were common to install a port of Debian onto are one such example, although I'm not sure how realistic a Debian install would be on them today. [These were discontinued in 2008.] Specs: 32 MB RAM, somewhere between 8 MB and 16 MB of onboard Flash. https://en.wikipedia.org/wiki/NSLU2 I own a couple of these things although I'm no longer using them -- Debian was an extremely tight fit even when these things were new. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: Wheezy release: CDs are not big enough any more...
On Sun, May 13, 2012 at 12:59:11PM -0400, Chris Knadle wrote: On Sunday, May 13, 2012 12:42:46, Joey Hess wrote: Many arm systems have 64 mb of ram or less. The NSLU2 boxes that were common to install a port of Debian onto are one such example, although I'm not sure how realistic a Debian install would be on them today. [These were discontinued in 2008.] Specs: 32 MB RAM, somewhere between 8 MB and 16 MB of onboard Flash. Which is not relevant here as you can't use d-i on them: http://www.cyrius.com/debian/nslu2/install.html d-i is not currently capable of completing with 64MB RAM (on i386, at least) which is a regression -- but once that's fixed, I see no reason why xz _decompression_ would hurt it in any way. xz needs 10MB above gzip, but regular debs are never decompressed concurrently with some memory-hungry operation (as opposed to udebs). -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Sun, May 13, 2012 at 12:42:46PM -0400, Joey Hess wrote: Adam Borowski wrote: Except that busybox has xz support, and is loaded from an udeb way before any regular debs are seen. Ie, there is no reason to stop core packages from using decent compression. Yes there is. busybox is used on a variety of systems, which are unlikely to have xz installed. The small benefit of better compressing base does not justify narrowing the set of systems on which busybox can be used. That's why busybox includes xz :) It has been available upstream for a while, hasn't been enabled in Debian until recently: commit 6b7d1195cfabcd1b192e618b40367edda05ed1dd Author: Michael Tokarev m...@tls.msk.ru Date: Sun Nov 6 19:14:14 2011 +0400 added support for unxz (CONFIG_UNXZ) to udeb (+8Kb on i386) -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Sun, May 13, 2012 at 21:35:16 +0200, Adam Borowski wrote: That's why busybox includes xz :) Not all relevant busybox builds do, which is the point. Cheers, Julien signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Sun, May 13, 2012 at 09:49:19PM +0200, Julien Cristau wrote: On Sun, May 13, 2012 at 21:35:16 +0200, Adam Borowski wrote: That's why busybox includes xz :) Not all relevant busybox builds do, which is the point. Could you please mention which ones do not? And if so, how are they relevant/are they fixable? Because as long as xz debs are opt-in, no significant part of the archive will be compressed well, breaking one-CD installs and putting a good deal of unnecessary strain on mirrors. And we're talking about whooping 1/3 of CD1 being waste. Special-casing base packages would be a lot of complexity, let's avoid that if possible -- but still preferred to letting gzip stay. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Sat, May 12, 2012 at 12:04 PM, Steve McIntyre wrote: Hey folks, Remembering the fun that we had during the Squeeze release with trying to make single-CD installations work well, it's time to consider what we're going to *claim* to support in Wheezy. We've had a history of supporting the following single-CD installations: * Gnome desktop from CD#1 * KDE desktop from KDE CD#1 * XFCE desktop from light CD#1 * LXDE desktop from light CD#1 * base system only from netinst CD At this point, I'm skeptical that either of the first two are going to work acceptably with Wheezy. If that's the case, then we should warn people that they will need to use at least one of: * more CDs * a DVD * a network mirror to get a useful/useable installation. What about supporting only the smaller/lighter desktop environments (maybe even making one of the the default environment)? Then there wouldn't be the need for multiple CD #1's. Anyone that wants gnome/kde after installation will need to grab those from the mirrors (or use DVD or greater media). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mp7zmd16g325awdxrxvdzfetz_zxjfwhqg+zviqj2j...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
Adam Borowski wrote:
Could you please mention which ones do not? And if so, how are they
relevant/are they fixable?
As one of the maintainers of debootstrap, I am perhaps more aware than
some how broadly it's used. Ok..
They use it on Android (41,600 hits including
http://evilzone.org/android/debian-on-android/)
They use it on Nokia (96,600 hits)
They use it on Nook (14,000 hits)
They use it on headless old Red Hat systems in a datacenter somewhere
They use it on Debian oldstable systems, where xz-utils is not even packaged.
They use it on absolutely modern peices of unusual kit that ship with some
crufty busybox binary (no source naturally) from far up the supplier
chain, that was built well before xz support entered busybox in 2010.
Special-casing base packages would be a lot of complexity, let's avoid that
if possible -- but still preferred to letting gzip stay.
Base packages can be identified at build time by their priority.
if ($priority ne 'important' $priority ne 'required') {
}
Although I do think that rebuilding the entire archive at this point in
the release process is probably going to result in a lot of ..
complexity. For one, d-i relies on being able to unpack firmware .debs
The code that does this doesn't support data.tar.xz. There are probably
plenty more problems where that came from.
--
see shy jo
signature.asc
Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Sun, 13 May 2012 18:36:09 -0400 Michael Gilbert mgilb...@debian.org wrote: On Sat, May 12, 2012 at 12:04 PM, Steve McIntyre wrote: Hey folks, Remembering the fun that we had during the Squeeze release with trying to make single-CD installations work well, it's time to consider what we're going to *claim* to support in Wheezy. We've had a history of supporting the following single-CD installations: * Gnome desktop from CD#1 * KDE desktop from KDE CD#1 * XFCE desktop from light CD#1 * LXDE desktop from light CD#1 * base system only from netinst CD At this point, I'm skeptical that either of the first two are going to work acceptably with Wheezy. If that's the case, then we should warn people that they will need to use at least one of: * more CDs * a DVD * a network mirror to get a useful/useable installation. What about supporting only the smaller/lighter desktop environments (maybe even making one of the the default environment)? Then there wouldn't be the need for multiple CD #1's. Anyone that wants gnome/kde after installation will need to grab those from the mirrors (or use DVD or greater media). 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. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpNe4XGAwAJ3.pgp Description: PGP 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: Wheezy release: CDs are not big enough any more...
On May 14, Neil Williams codeh...@debian.org wrote: I'd support XFCE4 as the default Graphical Desktop Environment and possibly putting GNOME (and KDE) as alternative options. What is the point of providing a default which is not what people usually want? Just document that a normal desktop install will require two CDs. Does anybody actually know that people routinely try to install desktop systems with only a CD and no networking, and why? What is the use case for this? Cheap DVD readers have been around for over 10 years now. -- ciao, Marco signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On Dom 13 May 2012 21:40:10 Marco d'Itri escribió: [snip] Does anybody actually know that people routinely try to install desktop systems with only a CD and no networking, and why? What is the use case for this? Cheap DVD readers have been around for over 10 years now. Actually, I was going to ask exactly that. To the best of my knowledge, CDROM players have been out of stock for a while (more than two years?) Normally people will buy a DVDROM player. Well, at least here in Argentina :-/ Could it be reasonable to drop graphical desktops environments for one-CD installs? If you want a GDE, get the DVD. Or two or more CDs. Kinds regards, Lisandro. -- http://xkcd.com/150/ Personas como ésta no se encuentran todos los días. Y cuando uno las encuentra, suelen no estar disponibles. Si encontrás una, no la pierdas. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Wheezy release: CDs are not big enough any more...
Hello, Joey Hess, le Sun 13 May 2012 20:39:20 -0400, a écrit : 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: [...] * 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 Well, things are not so clear. With gnome, we *used* to have a fully accessible system from the login manager on. The gnome3 transition has brought a lot of regressions, and using XFCE as a base for an accessible desktop makes a lot of sense; at least as much it does with gnome3. Quoting the abovementioned page: “but there are a lot of parts of the interface (custom widgets, buttons without label) that are hard to access with a screen reader.” I haven't tried myself, but gnome3 most probably introduced non-accessible custom widgets, buttons without labels, etc. For instance, the alt-F2 widget, used a lot by blind people, is currently inaccessible... 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. It looked to me like it was harder and harder each time. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514012958.gv4...@type.famille.thibault.fr
