RE: [PATCH] make multi-arch CD/DVD images more visible
> This has certainly appened, *but* I have only see it happen with > downloads > of Sarge images as amd64 are not mentioned on the sarge pages (because it > was not a release arch). To the best of my recollection, I have never yet > seen this happen with Etch images. me neither but from the posts on the debian forms i get the impression that those that are out of the loop don't try etch until after they have been told they don't have an ia64 chip and that this is likely to change after etch release. I also see a lot of posts about this that don't mention either etch or sarge explicitly in the initial post (and of course people immediately tell them to try amd64 etch so the question of which ia64 image they were using doesn't come up). intel does not publicise the fact that they are now the cloners and amd the cloned so anyone who has been out of the techy loop for a while (or never been in it) is going to assume that amd64 is not going to run on an interl chip and anyone who has seen ia-32 used to reffer to 32 bit intel (not that uncommon). Also i belive there are many who won't remember macs are no longer powerpc. > > To prevent this an additional "note" about what to use with EM64T > processors could be useful. Or maybe a link "Confused about all these > images?" to a new page with a general overview of types of images and > arches would be good. another alternative would be to structure the page so that it could accomodate a short comment on what each architecture was for alongside the links for each architecture. currently it seems for the stable releases there isn't even a download page as such, i just get directed to a folder on the mirror and left to find my own way from there.
please change symlinks to a http redirects on cdimage.debian.org
afaict you currently use symlinks to point at the current version of daily/weekly builds. This means that users who resume a download after a new release will most likely get a mixed (and therefore broken) image. changing that to a http redirect would mean that users would get a directory listings page with non update dependent links to the image that was current at the time they visited the cdimage server considerablly reducing the risk of this happening. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.22/739 - Release Date: 29/03/2007 13:36
RE: please change symlinks to a http redirects on cdimage.debian.org
> > afaict you currently use symlinks to point at the current version of > > daily/weekly builds. This means that users who resume a > download after a > > new release will most likely get a mixed (and therefore broken) image. > > > > changing that to a http redirect would mean that users would get a > > directory listings page with non update dependent links to the image > > that was current at the time they visited the cdimage server > > considerablly reducing the risk of this happening. > > Doing http redirects would not mirror well None of the mirrors i looked at seem to carry the daily/weekly images and the d-i site doesn't link to any form of mirror selection page even if there are mirrors afaict only doing this on the main server and for http (leaving the symlinks in place for other access methods) would solve the problem which is that people following the links from the debian installer site for daily/weekly images (which according to the debian-boot guys can't be made to update in sync with cdimage.debian.org ) can easilly end up with half and half (or worse) images. >, not work for rsync/ftp access true but the only users using theese access methods for daily/weekly images would be those browsing the server manually anyway -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.22/739 - Release Date: 29/03/2007 13:36
small query on multi-arch cd
It has been stated that the multi arch cd contains source for all packages it contains but does it contain the build dependencies for those packages? and if not why not? After all source code isn't much use (and probablly doesn't meet the gpl definition of source code) if the stuff needed to build it isn't there. This is an important but afaict overlooked consideration for those who want to be able to hand out the DVD without having to supply and keep to a written offer to supply source at cost. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
please make location of sarge images more obvious
http://cdimage.debian.org/ redirects me to a page on www.debian.org which links back to http://cdimage.debian.org/debian-cd which only contains etch images. this makes it rather hard to find the sarge images. I eventually managed it by using ftp rather than http and hence getting a top level directory listing then making some educated guesses but if it wasn't for the fact that i'd just heared about 3.1r6a being uploaded to cdimage.debian.org i would just have assumed that sarge images were no longer availible. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.463 / Virus Database: 269.6.0/775 - Release Date: 24/04/2007 17:43
Re: Release status of i386 for Bullseye and long term support for 3 years?
Then there was the short netbook boom, but AFAIR some early ones had 64bit CPUs but 32bit-only firmware. My memory is that at the height of the boom the dominant processors were the N270 and N280, which are 32-bit only. By the time 64-bit netbook processors showed up the boom was on the decline. There are at least two more: 5. People running Debian on virtual machines. You can run an i386 VM with vmware or virtualbox with no special hardware support. An x86-64 VM on the other hand requires VT-x (or the AMD equivilent). While processor support for this is the norm nowadays it's still often disabled by default which can be a pain if you need to get IT support to access bios setup on a machine. i386 hardware is so numerous and widely spread, that every tiny fraction of i386 users might be more users than half of our release architectures combined. It is not even clear whether this is just an exaggeration or might be literally true: i386 still gives 17281 popcon submissions, that is about a tenth of amd64, but it's also over 10 times the next highest port Now that probably doesn't reflect true usage, in particular users who install using images tend to miss out on the popcon question, but I still suspect that i386 is up there in the top few most used architectures.
Re: [RFC] Consequences for official CD/DVD images for Lenny
The i386/amd64/powerpc DVD is more problematic as having all desktops will completely fill the DVD leaving no room for other packages with a high popcon score. Proposal is therefore to drop powerpc support from this DVD. With only i386 and amd64 there is still room for the top ~2600 packages on the DVD. I'm not sure about this one, there are still quite a few powerpc macs out there and hopefully PS3 support will be coming to debian at some point. Dropping images that make no sense? === Somewhat unrelated. We have several architectures that don't support booting from CD (armel, mipsel, s390) which means we're building a number of images that nobody will ever use: - businesscard and netinst - KDE, XFCE aren't CD images also used to do hd-media installs? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
multi-arch dvd, build-depends and the GPL
The initial announcement of the mulit-arch DVD [1] said " There is also a combined amd64/i386/powerpc/source DVD which should contain most of what people will commonly want to install on each of those 3 arches, roughly equivalent to the contents of the first 3-4 CDs or so each. Binary-all package overlaps mean that there is space on this disc for more packages than might be expected. Plus, sources for all the binaries on the DVD will be included too. This DVD is therefore probably the ideal choice of disc to sell or give away at Expos." I read this as saying "source is included so if you hand this DVD out you should be covered for your GPL obligations" Unfortunately while source packages are included build dependencies are not. Some of those build-dependencies can probablly be recreated from source on the DVD but others won't be able to (for example devmapper build-depends on automake which is not included on the DVD and is built from source package automake1.10 which is also not included on the DVD ) IMO if the DVD is not providing build-deps then it is almost certainly not providing source for some of the included packages in the gpl sense. [1] http://osdir.com/ml/linux.debian.devel.announce/2006-12/msg6.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multi-arch dvd, build-depends and the GPL
"The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." We're doing that already. The source code from which the contents of a package are built do not have to be in that packages source package. For example the DVD contains the package "atl2-modules-2.6.26-1-486" which is built by the "linux-modules-extra-2.6" source package but the source seems to be taken from the "atl2-source" package. Neither the "atl2-source" package nor the "atl2" package it is built from Afaict other than manually checking every case the only way to be reasonablly sure of including source code (even if source code were defined as only the files fed to the compiler and nothing more) for all packages is to include all thier build dependencies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
changing name of debian directory on CDs.
I am working on building CDs images for raspbian (a derivative. I would like to change the name of the debian directory on the CDs to make it less confusing for users. That leaves me with two questions. 1: will this cause problems for apt? 2: assuming it doesn't cause problems for apt how do I make the change in debian-cd? -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50bd3a31.6000...@p10link.net
Bug#695080: please allow users to configure distribution name used in image descriptions
Package: debian-cd Severity: wishlist when I look at the jigdo files i've generated I see "ShortInfo='Debian GNU/Linux 7.0 "Wheezy" - Official Snapshot armhf CD Binary-1 20121203-21:36 (20121203)'" any idea how to change that to say raspbian? ok I found the answer, it's hardcoded, not in any configuration plugwash: fairly simple to fix that - please file a wishlist bug? Specifically it's hardcoded in tools/start_new_disc -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50bd3c92.3020...@p10link.net
Bug#695244: which_deb fails when trying to build source cds from an archive that doesn't have i386 or amd64 binaries
Package: debian-cd I've been working on trying to build cd images for raspbian using debian-cd. While doing this I found that when building source cds which_deb only looks for i386 and amd64 packages files. If it finds neither it fails horriblly. This prevents building source CDs for derivatives that focus on specific non-pc architectures like raspbian. By fails horriblly I mean that rather than the failure of which_deb to find a usable packages file being reported to the user the failure results in crazy values in makefile variables (e.g. directory names in variables which should contain file names) which in turn cause the build process to fail in ways that have no obvious relation to the real issue. To get things working for raspbian I just added armhf to the list of architectures but this isn't really a good soloution in general. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c0075e.7000...@postgrad.manchester.ac.uk
