Re: Progress on t64 transition -> building the installer in sid
Cyril Brulebois writes: > Philip Hands (2024-04-15): >> On the other hand, it's taken over a month so far. Rather than living in >> hope for another month, I thought it might be worth removing this as a >> blocker (I've had to tell a couple of people that they'll need to wait >> before they can do their salsa-CI tests :-/ ) > > I'm not suggesting living in hope, I'm suggesting to get the ball rolling. > > The commit lists #1066070, which was a duplicate (because -ECOFFEE) of > #1066069, which got fixed rather quickly. So what we would need are > rebuilds of the reverse dependencies (which I haven't checked right now > would be sufficient to get them fixed), which one could request on the > release team side. Oh, I seem to have managed to overlook the bit with you closing it. Sorry about that. Anyway, that's encouraging. If I can work out what needs prodding, and where to prod, I'll give it a go. > Regarding #1066071, that needs a fix in the package first. Looking at > tracker, it's not migrating any time soon as far as I can see (due to > regressions on 32-bit arms), and I'm not sure how fixing the udeb would > interfere there. So one could start with an upload. I had looked at fixing that, but didn't immediately know in which direction the mismatch should be resolved which convinced me that I probably don't know enough about the background to be doing NMUs. Which is what lead me to try working around it instead. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Progress on t64 transition -> building the installer in sid
Cyril Brulebois writes: > Philip Hands (2024-04-14): >> I realised that there might be a way to kludge around the current D-I >> build failures, so I gave it a try and it seems to work: >> >> >> https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45 >> >> That creates dummy udebs with the missing names, where each depends upon >> the matching udeb that actually exists. Dropping them into localudebs. >> >> That's enough to get D-I to build in salsa pipelines, such that one gets >> a mini-ISO to test. >> >> It may be enough to get D-I and debian-cd back to the point where we can >> produce daily images etc. but I'm not completely sure about that bit >> (perhaps the use of localudebs is enough to make debian-cd grumpy?) >> >> Anyway, it's currently broken anyway, so perhaps it's worth giving it a >> go, and then reverting the commit once the proper fixes become >> available. >> >> What do you think? > > I'd rather see actual progress in getting packages fixed. So far I haven't > been chasing because I thought people would be busy rebuilding the world, in > the right order, and patching things along, but I had hoped to get *some* > kind of feedback after filing those bug reports and putting people driving > changes in the loop. I too had rather hoped that it would already have been fixed by now. On the other hand, it's taken over a month so far. Rather than living in hope for another month, I thought it might be worth removing this as a blocker (I've had to tell a couple of people that they'll need to wait before they can do their salsa-CI tests :-/ ) I can just tell branch2repo to use the 'philh' D-I repo in the mean time, and that'll fix the salsa-CI side of things, but that doesn't help debian-cd or people's ability to build D-I locally. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Progress on t64 transition -> building the installer in sid
Hi, I realised that there might be a way to kludge around the current D-I build failures, so I gave it a try and it seems to work: https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45 That creates dummy udebs with the missing names, where each depends upon the matching udeb that actually exists. Dropping them into localudebs. That's enough to get D-I to build in salsa pipelines, such that one gets a mini-ISO to test. It may be enough to get D-I and debian-cd back to the point where we can produce daily images etc. but I'm not completely sure about that bit (perhaps the use of localudebs is enough to make debian-cd grumpy?) Anyway, it's currently broken anyway, so perhaps it's worth giving it a go, and then reverting the commit once the proper fixes become available. What do you think? Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Free Software DVD contains non-free firmware
Birzhan Amirov writes: > I just want to use this chance to thank the entire Debian Images Team for > many years of releasing DVDs that actually had 0 bytes of closed-source > code. > I have been following the project since "Jessie", and always admired your > strict and puristic approach. > Allow me to wish you the best of luck growing your user base. If you actually want the level of purity-over-practicality that your mail suggests, people have been providing it long before you took an interest in Debian -- the FSF keeps a list of candidates: https://www.gnu.org/distros/free-distros.html [ Oh, I see gNewSense is dead :-/ , and Trisquel is now (... erm, since 2007 ... obviously wasn't paying attention) based on Ubuntu, which doesn't seem like the most obvious way of doing that, but whatever. ] and while the FSF now criticises Debian primarily on the basis of this (IMO rather minor) change in installer policy: https://www.gnu.org/distros/common-distros.html#Debian they've always been critical of Debian, for pretty-much exactly the same reason as this policy change occurred -- a willingness to let users obtain a working Debian system by providing them with the chance to get hold of non-free software as well as Debian, if that's their only choice: https://web.archive.org/web/20220211101539/https://www.gnu.org/distros/common-distros.html#Debian so if you were expecting FSF levels of purity[1], then you probably haven't been paying close enough attention from the start. While looking at the FSF site, I noticed this somewhat amusing method for reconciling these two stances: https://www.gnu.org/philosophy/install-fest-devil.html but I'm afraid I've no idea how one could implement something equivalent in the medium of downloadable images. I'm sure if we had a tool for converting "+firmware" to "pure" images, we'd be publishing the checksums to the "pure" result, and making them easy to get for those that prefer them, but nobody's yet produced such a tool. It really just needs someone to care enough to maintain it (or pay someone else to do so). I don't think we'd go back to the situation where we somehow hide the "+firmware" images though, because we've acknowledged that that is effectively an abuse of our users, so I would expect the FSF to be almost exactly as grumpy even if "pure" images were easily available. Cheers, Phil. [1] of course, the FSF distributes documentation that is non-free by Debian's definition (in the form of GFDL-with-immutable-sections), so other forms of purity are also available :-) -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Free Software DVD contains non-free firmware
Birzhan Amirov writes: > Hello, > > Thank you for your quick and detailed reply. > >> I suppose that we could provide a tool that would be able produce an > image with no non-free data on it ... but the effort required to build and > test such a tool would have to be diverted from other tasks. >> ... to contribute to such an effort, then I'm sure the Debian-CD team > will be > glad to explain what would be involved. > > Just curious, is my understanding correct, that you had such a tool at the > time of 11.6.0, but not anymore? No - it used to be that 2 sets of images were produced, and which then had to be independently tested, thus expending a lot of overlapping effort. It is also the case that many people would download the "Official" images, and discover that they could not actually achieve an install on the hardware that they had to hand, and then would either abandon Debian never to return, or would be forced to learn arcane facts about how we do things before then downloading the non-free unofficial image. That may seem like it's not too bad if one is on cheap high-bandwidth link, but if one is in one of the less well connected bits of the world, it might be a significant cost to do that wasted download. Also, we're a volunteer organisation, and those lost users could well be people who would have become active contributors if they'd not fallen at the first fence, which is bad for the future health of the project. One could blame the users for getting hold of the wrong hardware, and tell them to go and buy themselves some RYF-certified hardware instead, but again that is rather descriminatory, as one might be talking to someone for whom the only computer they can afford is the one that was donated to them, and they had no say in the nature of the WiFi chipset (even if they'd known enough to have an opinion) =-=-= To answer the question in the other mail about DFSG: No. The non-free firmware is still not part of Debian proper, we just happen to distribute it alongside Debian as a service to those users who would otherwise be deprived of the chance to run Debian if we did not. We've had a non-free section on our mirror network for decades for the same reason. See points 4 & 5 of the Debian Social Contract: https://www.debian.org/social_contract It is of course possible to argue this the other way, and we do have downstream derivatives that ensure that no non-free software gets anywhere near their distribution, so if that's more to your taste you might want to consider one of them. On the other hand, there are real security issues that have been dealt with in updates to the (non-free) microcode for the CPUs that run the vast majority of machines, so many consider it rather unwise to shun every last scrap of non-free software, even if we find that distasteful. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Free Software DVD contains non-free firmware
"Andrew M.A. Cater" writes: > On Sun, Aug 27, 2023 at 04:38:58PM -0700, Birzhan Amirov wrote: ... >> Do you have an `Official` way to de-poison your release, and if so, is it >> published as a document? >> > > You can pass various parameters to the installer: you can also uninstall the > non-free firmware after installation - a record of what is installed is > recorded Andy seems to have given you something of a politician's answer there, so I'll try giving a more direct one: No, not as far as I know (if by "de-poison" you mean get to the point where the resulting image file has no trace of the firmware on it). However, it is possible to instruct the installer to not take any notice of the firmware, nor even try to detect if it might be needed: https://wiki.debian.org/Firmware#How_to_disable_detection_and_use_of_non-free_firmware which will provide you with exactly the same experience as would have been achieved by using media that did not include the firmware in the first place. I suppose that we could provide a tool that would be able produce an image with no non-free data on it (by replacing relevant portions of the images with NUL characters, say) but the effort required to build and test such a tool would have to be diverted from other tasks (e.g. getting the media to work at all, on currently unsupported hardware). If you feel that such a tool should be written, and have the skills to contribute to such an effort, then I'm sure the Debian-CD team will be glad to explain what would be involved. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Debian ISO Testing
Martin McCarthy writes: > 4) Automation. I read a thread on this mailing list recently talking > about openQA and whilst I am not opposed to automatic testing by > machines, I would insist that the manual testers are still retained as > relying solely on machines for QA can be problematic (machines are not > perfect just like humans). Not only that, the testers over on #debian-cd > is a community and having full automation would mean that community no > longer meets regularly to test stuff...and thus the community disperses > and fades away over time. FOSS to me is all about community so I would > hope that openQA works alongside the ISO testers rather than replace us. > This is slightly off-topic but AI is doing a lot of damage to corporate > tech and I hope that the FOSS projects don't fall victim to it too. I don't think there's any danger of OpenQA doing this (speaking as the person who set openqa.debian.net up) because the by-hand testing and openQA are complementary rather than competing. They're aimed at differing targets. The automated tests are mostly about catching regressions, mostly during development, and I'd hope that as the salsa integration comes together they'll become something that can provide confidence to people as they contribute to D-I. My perception is that the by-hand testing is more about making sure things are working across as wide a set of use cases on as wide a range of hardware as possible, and is focussed around release time. Writing automated tests that can notice things looking "weird" is rather hard -- OpenQA is very good at noticing that someone changed the font kerning very slightly (which is where many of our false positives come from), but if something is broken on a bit of the screen that's not specified as something to look out for in the test, it'll never notice. Also, testing on real hardware is not exactly trivial with OpenQA, so that has not been a priority, but even if we do get to the point where we can do openQA testing of real hardware, I wouldn't expect that the spectrum of hardware under test would be anywhere near as wide as currently gets tested by hand, nor would I expect for it to be useful (or even possible) to automate all of the tests done by hand. Of course, if fleshing out the set of tests that OpenQA runs (on VM or real hardware) renders some of the by-hand tests mostly redundant, that doesn't seem terrible, especially if we concentrate on automating the tests that are particularly tedious to do by hand. (suggestions welcome :-) ) Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Automating testing for the netinst and live images
Roland Clobus writes: > Hello Debian-cd Team and Phil, > > Now that the busy period for releasing Debian 12.1 is over and some of > the live images have been verified by openQA (via me), would it make > sense to think about automating the tests for the officially released > Debian images, and the weekly builds as well? > > My thoughts/ramblings: > * As soon as an image has been generated, and it has been made > accessible via an URL, openQA will be invoked and starts to download and > test the image (i.e. the generator will trigger openQA instead of openQA > polling) > ** Phil will be able to generate API keys for openQA In fact I think anyone can do that (having logged in, using salsa) but of course I'm very happy to do it. > ** I've already implemented a similar setup on Jenkins [1] for the live > images [6] > ** Phil has already implemented a similar setup for the netinst images, > using polling [2] I beleive this implements openqa-cli triggering as part of image creation: https://salsa.debian.org/images-team/setup/-/merge_requests/4 but it needs testing (hence the WIP). > * By testing on virtualised hardware, at least many of the manual, > tediously repeating tests can be verified to work correctly, which could > make the tests on real hardware faster, because less needs to be tested > * Automated tests would automatically see e.g. kernel mismatches in the > installer [3] > ** However, for the live images (based on testing and unstable) I've > implemented an automatic kernel selection, which saves additional > maintenance [4] > * The automated tests will show issues earlier, but that would require > regular monitoring/dashboarding > ** I've tried to tags the issues that I've reported [5] > * For the medium to long term, would it make sense to shift these test > from debian.net machines to debian.org machines? > ** The workload on osuosl3-amd64.d.n is already rather high It would be good to have more workers. I'm assuming that one way of doing that would be to spin up cloud instances, but my tentative attempts to work out how that's done have not yet bourn fruit (one issue is that the worker needs to be able to run kvm, which given that one's cloud instance is already a VM needs nested VMs, which seems problematic) I recently had a machine at Equinix for testing arm64 workers, which worked really well, but which I relised after starting it up was going to be rather expensive (their arm64 offer being Ampere Altra Q80-30's which have 80 cores, and cost $2.50 an hour). We've since tried a VM on altra.d.n, which allowed me to learn that its CPU (Neoverse-N1) is not quite new enough to do nested VMs (it looks like a Neoverse-N2 based thing ought to work, judging from comments in the related kernel patches) Running the workers on altra itself seems like it ought to be an option, but my kids are currently off school keeping me busy, so I've not been pushing that yet. So, if anyone has ideas for getting nested-VM-capable cloud stuff working (or just more amd64 hosting) or getting arm64 resources that would do the trick (or e.g. riscv machines I could play on), I'm very interested, becuase the current workers are only just keeping up, so adding more jobs at present is going to be frustrating. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1013079: installation-reports: GUI install option isn't visible on boot
Holger Wansing writes: > Hi, > >> > - On Jun 17, 2022, at 7:43 AM, Philip Hands p...@hands.com wrote: >> > > >> > > https://openqa.debian.net/tests/60553#step/_boot_to_debianinstaller/2 >> > > >> > > if you look closely in the highlighted box, you can just about see >> > > "Graphical install" as a black font on dark_blue background, but it's >> > > very close to invisible. >> > > >> > > It should have an inverted background on the selected item, which then >> > > makes the black text easily visible, as seen in the last working test, >> > > using a netinst ISO from 2022-06-07 17:27: >> > > >> > > https://openqa.debian.net/tests/59056#step/_boot_to_debianinstaller/1 > > Since the URLs from above are no longer valid, I'm attaching two screenshots > to show the issue (the first one from the last working 2022-06-07 image, > the second from today's installer image). Oh -- There's supposed to be a setting that keeps old tests if they've been refereed to from certain URLs (and I thought I'd set that to include the BTS, and had made a point of doing such an access to tag the build as a keeper) but it seems not to have worked. I shall see what I can do to fix that... Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#601203: #601203: tested patch for adding support for recursively including recommends (NORECOMMENDS=0)
Hi
Skimming through this thread as a result of your mail, I noticed the
earlier patch replacing the || 1 with defined ... ? ... and was going to
point out that since 2007 perl's had the // operator for this sort of
thing, which should mean that this would do the trick these days:
my $norecommends = $ENV{'NORECOMMENDS'} // 1;
but then I noticed that the latest patch includes this:
> -my $norecommends = read_env('NORECOMMENDS', 1);
> +my $norecommends = (defined $ENV{'NORECOMMENDS'} ? $ENV{'NORECOMMENDS'} : 1);
which replaces the use of read_env() with the earlier fix, which strikes
me as a backwards step, given that read_env is doing exactly what's
needed here:
=-=-=-
sub read_env {
my $env_var = shift;
my $default = shift;
if (exists($ENV{$env_var})) {
return $ENV{$env_var};
}
# else
return $default;
}
=-=-=-
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Re: Spyder package missing from jigdo amd64 weekly 16 GB stick ISO, but its dependencies are there
Steve McIntyre writes: > On Thu, Jul 29, 2021 at 03:01:54PM +0200, epsommum...@virgilio.it wrote: >>I am now using the BluRay image which contains Spyder and its dependencies, >>so I am fine. >> >>But obviously there is a problem with the current algo being used if >>the dependencies of a software end up in an ISO but not the software >>actually depending on them. > > No, there is *not* obviously a problem there. There would be a problem > the *other* way round, as then you'd have the top-level software > package but not be able to install it. As I said, we sort packages in > dependency order and then go through the list as far as we can before > the media is full. BTW looking at the popcon numbers, I see that we have: spyder-common 1727 python3-spyder 1124 spyder 1053 spyder3 888 So, I'd imagine that spyder-common was the one that got in via popcon ordering, and python3-spyder (on which it depends) then had to be on too. The numbers for spyder3 & spyder are presumably a consequence of the transition from python2 to python3, with the previous situation where one had a choice of which version of spyder to install, both of which depend (AFAIK) on spyder-common. The spyder package is now the python3 version and will presumably go up the rankings over the next release, probably ensuring that it will have very similar numbers to the -common package and therefore on any particular medium we should again expect to see all or none of these packages (well, expect for spyder3 which will have disappeared). As such, the "problem" such as it is, is only a temporary blip which will sort itself out by next release, and anyway can only be noticed by people that obtain media that happen not to include all the packages they want and then decide (or are forced by circumstances) not to configure Internet sources to fill in the gaps. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Spyder package missing from jigdo amd64 weekly 16 GB stick ISO, but its dependencies are there
epsommum...@virgilio.it writes: > I am now using the BluRay image which contains Spyder and its dependencies, > so I am fine. Unless the machine you're running this on is isolated from the Internet, you could just have added any of the many servers in our mirror network to apt's sources.list and then installed missing package(s) as though they were on the medium. (see the man page: sources.list(5) ) > But obviously there is a problem with the current algo being used if > the dependencies of a software end up in an ISO but not the software > actually depending on them. We make sure that all of a packages dependencies are on the media before the package itself. After all, having spyder without python3-spyder wouldn't do you much good either (if you're not allowing Internet downloads that is), and would be more annoying as it would offer the package and then fail with missing dependencies if you attempted to install it. > I remember being surprised by the size of the ISO being significantly less > than 16 GB. I believe it was 14.8 GB. > I just downloaded it again to verify and voila : > 14,8 Gio (15 909 054 464) > Well...also known as : 15,9 GB Well, quite. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Speed up installation: increase priority of eatmydata-udeb to standard
Cyril Brulebois writes: > Hi, > > ValdikSS (2021-04-28): >> eatmydata-udeb package is designed to speed up the installation process. >> However, it's not used by default and could be activated only with preseed >> file or kernel cmdline argument. >> >> Please consider increasing eatmydata-udeb priority to standard in >> debian-installer overrides, for it to be used by default. This will speed up >> installation by an order on slower HDDs. >> >> It will be perfect to include this change before final Bullseye ISO release. >> >> For more information, read the post in debian-boot: >> https://lists.debian.org/debian-boot/2021/03/msg00121.html > > We already have a lot of serious problems to solve in the installer; > I wouldn't want to see possible extra perturbations due to a syscall > interceptor. > > The best would be to have that kind of change happen right at the > beginning of a release cycle, rather than in the last few weeks > before a release… > > A compromise might be thinking about backporting the change to > bullseye once it's been tested with some D-I Bookworm Alpha 1 (but > that would also be a rather important change to backport to a stable > release…). > > Happy to hear other opinions. Would it be possible to make this conditional on something being set on the kernel command-line, so that people are in a position to opt-in to using it? This seems to be an endlessly repeating dance, where the effort available to d-i seems to ebb and flow in synchronisation with the release cycle, but the opportunity to make interesting changes is in anti-phase with that. If we had a conditional looking out for e.g. "experimental=..." on the kernel command line, and then treating that as a list of things that people are trying to test, then people would be able to easily experiment with these things and report successes/failures such that we might be able to: take advantage of people that are keen to make contributions during the late phase of the release that can spend one cycle in a state where they are only used if the user opts-in. provide a trivial way of taking advantage of innovations without endangering the reliability of the default installer, where those supporting the change just need to add 'experimental=eatmydata' to the kernel command line in order to give confidence for inclusion in the next release. Obviously, there is a problem introducing such a change right now. Typical, eh ;-) Could we start out with a baby step having a new experimental-netinst flavour of ISO, which includes a list of experimental udebs in addition to the normal ones? I'm happy to put effort into making that happen BTW. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Towards Debian Buster Alpha 4
Hi Cyril, Cyril Brulebois writes: > Hi, > > Being back from a rather busy quarter, I'd like to resume releasing d-i > more frequently. I'd like to publish a new alpha somewhen during the > next few days/weeks (if that's fine with debian-cd). > > If you have changes pending in master branches that need uploading, or > specific packages that need to reach testing, please mention which, and > why. I seem to have volunteered to do something about getting the blends selection in d-i to be a thing. What do you think about reinstating my "simplified-tasksel" stuff as a starting point? At least that would allow the blends tasks to be put back in, without normal users being bothered with a vast menu.[1] On the other hand, some sort of multi-level menu in tasksel might well be better, but I've not really worked out what that should look like. If we come up with something better, and then I'll try to make that a reality, but I'd like to hear what you think is going to be acceptable. Cheers, Phil. [1] I can choose one of the variants of that and do it as a pu/... branch against the current master -- I was looking at the previous versions that were done in the heat of the moment, and failing to decide which version would be preferable, so that's another reason I'm looking for feedback about it. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: jigdo-file: Does not report package rejections because checksum mismatch
On Thu, 28 Dec 2017, "Thomas Schmitt" <scdbac...@gmx.net> wrote:
> Hi,
>
> first a correction of my proposal:
>
> The else-case with
> echo "WARNING: File not found after download:" >&2
> is not good.
> It floods the log if one uses a mirror with few matching files.
> Not finding a file after the download is a normal situation.
>
> ---
>
> I wrote:
>> >sed -e 's/^[hH][tT][tT][pP]:\/\///' \
>> >-e 's/^[hH][tT][tT][pP][sS]:\/\///' \
>> >-e 's/^[fF][tT][pP]:\/\///' \
>> >-e 's/^[fF][iI][lL][eE]:\/\///'`
>
> Philip Hands wrote:
>> sed -e 's,^\(https\?\|ftp\|file\)://,,i'
>> ...
>> "$imageTmp/${url#[[:alpha:]]*://}"
>
> Are these widely portable enough ?
the , rather than / feature is already in use in the script (except that
its using s%%%).
\( \) is already in use, and AFAIK \| has been there for as long
\? _might_ be a bit later as a feature, in which case one could add
\|https, but then again isURI() doesn't match https: anyway
The i flag is a GNU extension, so is probably not that portable, so one
could go for \(http\|HTTP\|...
For the shell, I suspect that [[:alpha:]] is an innovation from the
90's, so one could play it safe (well, except that it might break with
odd codings) with [a-zA-Z]. posh doesn't seem to know about [:alpha:]
for instance.
posh does know about the ${ # } thing, but that wasn't in Solaris SVR4
shell AFAIK.
> Mine can be justified by S.R.Bourne's "The Unix System", i guess,
> and it is coordinated with function isURI.
>
> Well, my scruples are mainly about what wget guarantees to use as
> local disk path. I understand that jigdo-file would be quite tolerant
> as long as the file is somewhere in the "$imageTmp" tree.
> Maybe i should invest a "find" run in case of missing file. The tree is small.
>
>
> I wrote:
>> > fileMD5=`$jigdoFile md5 "$localPath" 2>/dev/null | awk '{print $1}'`
>
>> The way it's done elsewhere in the script (which I happen to think is
>> pretty horrible, but that's what is already there) is using set, thus:
>> set -- `$jigdoFile md5sum --report=quiet "$localPath"`
>
> Option "--report=quiet" instead of "2>/dev/null" is a good point.
>
> One would have to wrap the "set --" into a sub-shell, because fetchAndMerge
> already tampers with its own arguments.
> Like:
> answer=`$jigdoFile md5sum --report=quiet "$localPath"`
> fileMD5=`(set -- $answer ; echo "$1")`
> Now that's really ugly.
This seems preferable, and avoids new dependencies:
`$jigdoFile md5sum --report=quiet "$localPath" | sed 's/ .*$//'`
> If direct objections emerge against "awk", i'd consider some helper
> function which echos "$1".
>
>
>> I also happen to think that using `` rather than $() is pretty horrible
>> in this day and age, but that's what's currently there throughout the
>
> Yep. Not to speak of the headless camelBack variable names.
>
> I strive to be minimally intrusive for the purpose and to be as
> conservative as in an autotools script.
Fair enough.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: jigdo-file: Does not report package rejections because checksum mismatch
On Thu, 28 Dec 2017, "Thomas Schmitt" <scdbac...@gmx.net> wrote:
...
> Especially in need of attention:
>
> - I could not find a clear description how "wget" determines the local
> file paths from URLs and option --directory-prefix="$imageTmp".
> My current conversion from URL to path is purely heuristic therefore:
>
> localPath="$imageTmp"/`echo "$url" | \
>sed -e 's/^[hH][tT][tT][pP]:\/\///' \
>-e 's/^[hH][tT][tT][pP][sS]:\/\///' \
>-e 's/^[fF][tT][pP]:\/\///' \
>-e 's/^[fF][iI][lL][eE]:\/\///'`
A rather less laboured way of getting the same effect with sed would be:
sed -e 's,^\(https\?\|ftp\|file\)://,,i'
[ Things to note about that:
s,,, in place of s/// means that no escaping of / is needed
the 'i' flag at the end makes the match case insensitive
s\? means match zero or one 's'
]
However, I doubt that it's important to worry about the potential for
unexpectedly removing a prefix of e.g. cdrom:// or ://, in which case
you could dispense with sed and instead do this:
localpath="$imageTmp/${url#[[:alpha:]]*://}"
> - I introduced a dependency on "awk", which was not used in jigdo-lite
> before. The task is to obtain the first word of jigdo-file's output:
>
> fileMD5=`$jigdoFile md5 "$localPath" 2>/dev/null | awk '{print $1}'`
The way it's done elsewhere in the script (which I happen to think is
pretty horrible, but that's what is already there) is using set, thus:
set -- `$jigdoFile md5sum --report=quiet "$localPath"`
which leaves the value that you are after in $1.
I also happen to think that using `` rather than $() is pretty horrible
in this day and age, but that's what's currently there throughout the
script, so I guess one should stick with that, or fix it everywhere.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: when i use jigdo to download old version debian i got this problem.
On Fri, 22 Dec 2017, Thomas Schmitt <scdbac...@gmx.net> wrote: > Hi, > > Cabal Cabal wrote: >> 23:05:19 (103.64 KB/s) - >> `debian-6.0.5-amd64-DVD-1.iso.tmpdir/us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/g/ghostscript/ghostscript-cups_8.71~dfsg2-9_amd64.deb' >> saved [61234/61234] >> ... >> Aaargh - 1 files could not be downloaded. ... > > If this is 23:05:19+8000 today, then again a file on us.cdimage.debian.org > went bad. We had this only a few days ago, when at least 12 did not match > the expected MD5s. I set the system rummaging through the several million files involved last week, with the result that about ten thousand were discovered to be missing or corrupt (in all the cases I've checked, the corruption consisting of a few bytes replaced with NULs, so nothing malicious, just the result of a raid/filesystem SNAFU, as expected). I've got that number down to about 400 now, which is mostly concentrated in a load of debian-installer related files for versions 20150422+deb8u4+b1 and 20150422+deb8u4+b3, mostly armel and armhf. I suspect that nobody will ever care about those. There are four jigdo files that were also corrupt: debian-501-amd64-BD-1.jigdo debian-502-arm-CD-1.jigdo debian-7.5.0-sparc-CD-56.jigdo debian-stretch-DI-alpha5-source-DLBD-1.jigdo If anyone knows of good copies of those, please send me the URLs and I'll fill in the last few gaps. Hopefully that has dealt with this problem for most people now. Sorry about not noticing this earlier. I had thought that I'd rsynced over all the damaged files at the time when the damage occurred, but it seems that I overlooked the jigdo snapshot area. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: What mirror to use with archived jigdo DVD images ?
On Fri, 15 Dec 2017, Thomas Schmitt <scdbac...@gmx.net> wrote: ... > It seems not to be about a missing package of the desired name but about > something else. Ah, right -- you seem to have discovered some corrupt files on my server. Thanks :-) The gnupg file differs from that on snapshot.debian.org by 12 bytes, which are all zeros in my copy. The texlive deb had 20 bytes of zeros. I've overwritten them now, which should fix the immediate issue. Now I just need to see if I can work out which bit of hardware is broken and causing that... (I guess one of the many disks, that are all in 3-way RAID1s, is lying about it's current state of health :-/ ) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: What mirror to use with archived jigdo DVD images ?
On Fri, 15 Dec 2017, Philip Hands <p...@hands.com> wrote: > Is this the file you're looking for? > > > http://non-us.cdimage.debian.org/snapshot/pool/main/g/gnupg/gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb Actually, I note that the jigdo file ends with: [Servers] Debian=http://us.cdimage.debian.org/cdimage/snapshot/Debian/ --try-last which is the same server, and I note that this URL also works for that file: http://us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/g/gnupg/gnupg-udeb_1.4.10-4+squeeze1_amd64.udeb which AFAIK is where jigdo should be looking, so that should just work. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#858805: cdimage.debian.org: File on DVD images failed the MD5 checksum verification
reopen 858805 thank you Hi Lee, Thanks for persevering -- now that you mentioned that the file was missing I've managed to notice that the bug is present in the current weekly images. Prompted by that, Steve McIntyre has tracked down the cause, and is performing a test build as I write to see if he's fixed it. I'll leave it to him to again close the bug once he's confirmed the fix. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#858805: cdimage.debian.org: File on DVD images failed the MD5 checksum verification
"J. L. Lee" <jl...@jllee.per.sg> writes: > Hi Phil, > > Thanks for your guidance on what you wanted me to do. Following are the > checksums of 2 iso images I still keep. > > ~$ md5sum debian-testing-i386-DVD-1 (image of the iso image downloaded > on 27 Feb.) > c4532760456548a75e58edb4c6338d78 debian-testing-i386-DVD-1 > > ~$ md5sum debian-testing-i386-DVD-1.iso (image of the iso image > downloaded 24 March) > e1f666377199fcfd1a98f0ce67b1fcad debian-testing-i386-DVD-1.iso > jllee@debianamd64:~$ > > ~$ md5sum > /media/usb/pool/main/t/texlive-extra/texlive-extra-utils_2016.20170123-5_all.deb > > (on i386 USB stick) > 1a66b41cabb6cd0a987394838267923a > /media/usb/pool/main/t/texlive-extra/texlive-extra-utils_2016.20170123-5_all.deb > > ~$ md5sum > /media/usb/pool/main/t/texlive-extra/texlive-extra-utils_2016.20170123-5_all.deb > > (on amd64 USB stick) > 1a66b41cabb6cd0a987394838267923a > /media/usb/pool/main/t/texlive-extra/texlive-extra-utils_2016.20170123-5_all.deb Looking at that file on my mirror, I see: phil@free:/org/ftp/debian$ md5sum pool/main/t/texlive-extra/texlive-extra-utils_2016.20170123-5_all.deb 1a66b41cabb6cd0a987394838267923a pool/main/t/texlive-extra/texlive-extra-utils_2016.20170123-5_all.deb phil@free:/org/ftp/debian$ zgrep texlive-extra-utils_2016.20170123-5_all.deb indices/md5sums.gz 1a66b41cabb6cd0a987394838267923a pool/main/t/texlive-extra/texlive-extra-utils_2016.20170123-5_all.deb so the md5sum you're getting would seem to be right -- what makes you think it is wrong? BTW I also note that the md5sums.txt file in top level of a DVD image I just jigdo-ed contains the same checksum for that file. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#858805: cdimage.debian.org: File on DVD images failed the MD5 checksum verification
JL Lee <jl...@jllee.per.sg> writes: > Package: cdimage.debian.org > Severity: normal > > Dear Maintainer, > >* What led up to the situation? > > The file > ./pool/main/t/texlive-extra/texlive-latex-extra-doc_2016.20170123-5_all.deb > on the DVD image failed the MD5 checksum verification. > This happens to the DVD images for both amd64 and i386 architecture. I > noticed this from the DVD images published since late January 2017 > and persists till the latest release on March 23 2017. > > I used jigdo-lite to download these images and the images > downloaded each time were good. Just so that we can avoid confusion, perhaps you would be kind enough to provide: The URL of the image and/or jigdo of the image(s) you are talking about (one example is fine, but if its easy for you to provide more, that would be great). Checksums for the .iso image(s) you have (so it is possible for us to be confident that the same image is being examined). The checksum you get from the .deb on the image. The checksum you were expecting to get. plus any other similar details that you think might help someone be sure that they are looking at the exact problem you are describing. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: debian testing netinst is broken
Sayutin Dmitry <cdk...@yandex.ru> writes: > Hello, just want to report that current debian testing netinst is broken. > > Steps to reproduce: > 1) download image from > http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/, > name=debian-testing-amd64-netinst.iso > 2) run setup in vbox, graphical install, follow defaults. > 3) Get error during setup of base system, graphical installer crashes > instantly, log on tty4 says: > (tail -3): > main-menu[363]: INFO: Menu item "bootstrap-base" selected. > debootstrap: sh: apt_dest: unknown operand > debootstrap: /usr/sbin/debootstrap: line 617: : Permission denied. > > Issue is 100% reproducible and was tested on 3 machines allready. Reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844458 I just pushed this fix: https://anonscm.debian.org/cgit/d-i/base-installer.git/commit/?id=0ebd5da3977e1ccae4066abc3504ec71f4d79091 HTH Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: How-to merge repository from 3 BD images into one ?
Alexey Eromenko <al4...@gmail.com> writes: > Hello, > > Trying to merge 3 Blue-Ray disc images into one BD XL image, I have > stumbled upon a problem: > "debmirror" doesn't seem to support local file system as source. (only > FTP, HTTP, rsync) > > Any ideas what to do ? rsync has an option --link-dest, which will use a local copy of a file if it can find it, so you could copy the contents of the Blue-Rays onto disk, then use rsync with --link-dest to do the mirror, and it'll only download the missing bits, and will hard-link all the files you already have. There's probably a better way, but that ought to work reasonably efficiently. You should probably ask yourself why you want to do this though. Unless you're planning to go off-grid for a few years I'd expect you to be better off just using the first Blue-Ray, and ignoring the rest -- the downloads of the few packages that you'll use from the rest will probably never add up to the effort/download of assembling it all onto one disk, and it won't be long before you find yourself downloading more in security updates than the packages from the subsequent Blue-Rays. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: preseed with netboot ISO
Lars-Daniel Weber lars-daniel.we...@gmx.de writes: Hi there, I've added a preseed file to the netboot mini ISO [1], but the preseed can't be loaded. The same way I've tried it to the normal netinstall ISO [2] - it worked as always. I guess you're doing this? https://wiki.debian.org/DebianInstaller/Preseed/EditIso If so, the thing that makes that works is this: http://anonscm.debian.org/cgit/d-i/preseed.git/tree/debian-installer-startup.d/S35initrd-preseed which needs to end up in /lib/debian-installer-startup.d Isn't the mini.iso capable of using preseeds? I like its small size :D If you bring up a console (e.g. Ctrl-Alt-F2) when having booted from the mini.iso, and check if the S35initrd-preseed file is in place. My guess is that the mini.iso does not include initrd-pressed.udeb. If so, adding 'initrd-pressed' to pkg-lists/local in the build dir might do the trick. Alternatively, there's some way of getting extra udebs to be installed via presseding IIRC (which you could do by editing the syslinux config). Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpeQ4WnbXVe9.pgp Description: PGP signature
Re: Aw: Re: preseed with netboot ISO
Lars-Daniel Weber lars-daniel.we...@gmx.de writes: Gesendet: Freitag, 19. Dezember 2014 um 10:23 Uhr Von: Philip Hands p...@hands.com An: Lars-Daniel Weber lars-daniel.we...@gmx.de, debian-cd@lists.debian.org Betreff: Re: preseed with netboot ISO I guess you're doing this? https://wiki.debian.org/DebianInstaller/Preseed/EditIso No, that way it works. I've just tried it out. If you bake the preseed into the initrd, anything works as expected. I've put the preseed.cfg to the root of the ISO and passed it by APPEND settings to the kernel: neither file=/cdrom/preseed.cfg, nor file=/hd-media/preseed.cfg, nor file=preseed.cfg works. Exactly the same style (using file=/cdrom/preseed.cfg) works for net*installer*, but not for net*boot*. The funny thing: for self-built net*boot* images (about 10 MB), it works with a seperated preseed.cfg outside initrd without a problem. But building the installer on my own takes lots of dependencies... I wonder, what went wrong on the automatic build of mini.iso :( If you bring up a console (e.g. Ctrl-Alt-F2) when having booted from the mini.iso, and check if the S35initrd-preseed file is in place. My guess is that the mini.iso does not include initrd-pressed.udeb. Ah! Let me check: mini.iso gives me: ./lib/debian-installer-startup.de/S35initrd-preseed netinstaller is equal, even when looking for anything contaning preseed. This makes a bit more sense (I was wondering how you could have avoided the initrd-preseed stuff). So, my next guess is that file-preseed is the udeb that is in the netinst, but is not the mini. If that's the case, you can probably just use network-preseed to get the job done, but specifying it as a url=, rather than as a file= like this: url=file:///cdrom/preseed.cfg (the 3 slashes are required BTW) BTW You can check my theory by looking for /var/lib/dpkg/info/file-preseed* Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp1SuErRXVAZ.pgp Description: PGP signature
Re: Aw: Re: Re: preseed with netboot ISO
Lars-Daniel Weber lars-daniel.we...@gmx.de writes: Gesendet: Freitag, 19. Dezember 2014 um 16:02 Uhr Von: Philip Hands p...@hands.com An: Lars-Daniel Weber lars-daniel.we...@gmx.de This makes a bit more sense (I was wondering how you could have avoided the initrd-preseed stuff). Sorry :D So, my next guess is that file-preseed is the udeb that is in the netinst, but is not the mini. Sound logical (but that's sad, when it's true). If that's the case, you can probably just use network-preseed to get the job done, but specifying it as a url=, rather than as a file= like this: url=file:///cdrom/preseed.cfg (the 3 slashes are required BTW) I tried... same error: file:///cdrom/preseed.cfg couldn't be loaded Seems like they're redirecting url=file to preseed/file Ah, right -- I was forgetting that we made it so that file= stuff gets converted into the url= form for you, so that was a red herring. Sorry. Looking at this, that you mentioned elsewhere: http://i2.minus.com/ipThlsj7y4APr.png if at that point, you switch to a console: Is there actually a /cdrom/ directory? If there is, does it contain a preseed.cfg? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpjvWppJERht.pgp Description: PGP signature
Bug#762392: Publish self-contained debootstrapped tarballs
Hi Eduard,
Given that you say, quite rightly, that it's pretty easy to generate
tarballs:
Eduard - Gabriel Munteanu edg...@gmail.com writes:
...
Generating them can be quite straightforward, and doesn't even require
root privileges:
$ cdebootstrap --foreign --arch=ARCH [...]
$ tar [...]
I'd suggest users would be better served learning to do that.
Especially if they plan to do any of the more complicated things you're
talking about.
We used to have a tarball that one could just drop onto a system (until
about 15 years ago IIRC) but it wasn't a very good solution, and you get
left with the job of doing all the bits that d-i does for you now to
make sure the result boots, and that the network works etc.
Anyone that can deal with those issues after installing a tarball should
have no trouble at all running {c}debootstrap themselves.
Might I suggest that if you have concrete examples of things that
you mention, like:
- custom setups unsupported by the Debian Installer
that you report bugs about those, with specific examples, because you
may find that you've just not noticed the way in which such setups are
supported, and will therefore find out that it is possible to do what
you want, or you will highlight real weaknesses in the installer, which
are then more likely to get fixed.
Certainly, for example, some multi-layered RAID/lvm/crypto setups are
rather difficult to arrange in an automated way in debian-installer, but
I see nothing in your suggestion that is going to address that weak
spot. Instead you're wanting to have nothing at all to handle the
partitioning. I presume you're expecting people to do all that by other
means, in which case they should probably just use {c}debootstrap
directly onto the mounted partitions they just created.
For someone that has such a complicated setup, it seems unlikely that
they are going to best served by a tarball created with a different
setup in mind. They are liable to find that they need to spend more
time kludging round the bits where the assumptions embodied by the
tarball don't fit their needs properly.
It would almost certainly be much better for them to use and understand
deboostrap directly, in which case they could build their own tarballs
if it suits their purpose. Alternatively they could use and understand
debian-installer preseeding, if that suits them better.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
pgp_3DpGghTGj.pgp
Description: PGP signature
Re: Hello there! Davy Jones here from the Sunny Okanagan, Kelowna BC, Canada. Could I possibly...
Frank leTanque g...@tanque.pro writes: Hey Davy, why not just download it here? http://www.ubuntu.com/download/desktop Given that he's asking for a Debian CD, why are you pointing him at Ubuntu? Davy, If you go to the main web page for Debian: http://www.debian.org/ you'll notice a green box in the top-right corner of the page: +---+ | | Download Debian 7.2| | V (32/64-bit PC Network installer) | +---+ if you click that, it'll allow you to download a small image that is enough to boot the installer on a machine. The machine you're installing needs to be able to get to the Internet, as the installer then needs to download all the software you want to have installed after that. The image works for both 32 and 64 bit Intel/AMD machines, and will boot if you burn it onto a blank CD or DVD, or you can copy it onto a USB stick and it will make it bootable (that's by overwriting the contents of the stick, rather than by copying the file into a directory on the stick). The installation manual goes into the details: http://www.debian.org/releases/stable/installmanual You could instead try a live CD, although I'm not sure which to recommend. Grml is good for sysadmin work, and is pure Debian. Knoppix is great if you want a fully configured desktop, but I think includes some bits that are not in Debian. There is a debian-live CD, but the one that fits on a CD is a bit useless, so you probably need the larger image, with gnome on it, which is fin if you wanted to burn it on DVD boot a VM. Hope that helps. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://ftp.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpVx_wMKyQDI.pgp Description: PGP signature
Re: Moving to git
Philip Charles phil...@copyleft.co.nz writes: On Fri, 31 May 2013, Steve McIntyre wrote: Hey folks, I'm playing with importing the current svn repo into git right now, hoping to move across soon. If anybody has problems with that, speak now! Aaaagh, Something else to learn. I suggest you read this: http://newartisans.com/2008/04/git-from-the-bottom-up/ Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpgT6FCa34Ts.pgp Description: PGP signature
Re: DVD Labels
Hi Miroslaw, miro@interia.eu writes: Hello My name is Miroslaw, I live in Poland and I have 28 years old and i deals with Graphics one year. Yesterday I finished overprints on DVD for Squeeze and Wheezy systems, and i share it with them in deviantart.com on my profile.(http://mirozarta.deviantart.com) this is the link: http://fav.me/d5utgfr and these are links to the respective versions: http://fav.me/d5uteq1 Debian 7.0.x Wheezy 64 bit http://fav.me/d5utbzf Debian 7.0.x Wheezy 32 bit http://fav.me/d5upa0t Debian 6.0.x Squeeze 64 bit http://fav.me/d5uos13 Debian 6.0.x Squeeze 32 bit If it is possible I would like to put this on the official site :) They look great, but I think you need to remove the DVD Logo, given the answers in the ``DVD Logo'' section, here: http://www.dvdfllc.co.jp/faq.html Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpoG5VQqSZed.pgp Description: PGP signature
Re: What would it take to establish a mirror of cdimage.debian.org in North America?
Hi Rick, Rick Thomas rbtf...@gmail.com writes: Fetching a DVD image across the North Atlantic takes a long time -- 5-7 hours. And the bit-torrent seeders don't provide the beta images, let alone the daily or weekly images. This is not the answer to the question asked, but if you're downloading a daily image over HTTP or FTP then you're almost certainly doing it wrong. If you regularly play with these images then you've probably got a fairly recent one laying around, in which case you could use rsync for a much faster download, but if you want to be kind to cdimage.debian.org the right thing to do is use jigdo, which will pull almost all of the image from your nearest mirror, in form of packages, and then assemble them into the image locally. If you have an old DVD image, you can mount that and offer it to jigdo as a source of packages, saving even more bandwidth. So... are there any volunteers out there to provide a mirror of cdimage.debian.org/cdimage on this side of the pond? How big a machine would it require? How much bandwidth? That said, I'd imagine that a US-ian mirror would be helpful to people that cannot be bothered to work out how to do the right thing. It is possible that one could be smarter than simply mirroring the whole lot, since for some of the images it may be that you find that nobody ever tries to download them from you, so the act of mirroring them would simply add load to cdimage.debian.org. Steve McIntyre proposed a while ago (and I think did some work on) a FUSE file system that would take jigdo files and a local mirror, and provide the illusion of a cdimage mirror without needing the images locally. If you could implement that then any mirror willing to run that FUSE filesystem could provide the content you're looking to mirror, without consuming the bandwidth or disk space required to really do that. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpIQtneuYnax.pgp Description: PGP signature
Re: Possible malware in one of your download packages
On Fri, 29 Oct 2010 11:01:37 +0100, Mike Allen mikeallen1...@gmail.com wrote: ... I got a malware report on a Windows machine from a MS Security Essentials scan (full scan) ... *Microsoft Security Essentials encountered the following error: *Error code 0x800700df. The file size exceeds the limit allowed and cannot be saved. ^^ That bit of the error may be the real cause -- if the DVD file is just too big for the Microsoft program, then all the rest of the output may well be drivel. Alternatively, it is possible that the test virus string that's contained in a file in the clamav package's doc directory (which is presumably on the DVD) could have been found, but one would hope that they would describe the virus found in that case. If they really are responding to their own failure to handle larger files by recommending deletion, then that really is pathetic. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -- 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/87aalxgpne@poker.hands.com
Re: Jigdo search still broken.
On Wed, 6 Oct 2010 23:33:45 +0200, Richard Atterer atte...@debian.org wrote: On Wed, Oct 06, 2010 at 02:29:42PM +0100, Steve McIntyre wrote: On Mon, Oct 04, 2010 at 03:47:56PM +0200, thorres wrote: Hi there, the search for packages inside the jigdo files still does not work an and leads to a 404 error. (http://atterer.org/jigdo/jigdo-search.php?q=foo) ACK. We should move that content onto a proper Debian service. Richard, can you help with that? Hi - sorry that the search went offline, it happened when I moved servers and I never fixed it. But this should have been on a Debian server in the first place... The setup consists of a cron job to mirror .jigdo files (which could be omitted if we set this up on cdimage) and a PHP file. Is PHP OK for Debian machines? IIRC perl was preferred... Hi Richard, You could run it on free.hands.com (where you already have an account), which for the moment has PHP on it. I now have that on a VM and would at some point want to shift the PHP stuff onto a separate VM, so if we do that it would be wise to come up with a URL that would survive being shifted onto a new machine at some point. That could of course be done by having nginx on free proxy through to the new machine. If it's more practical to do it elsewhere, that's great, but thought I'd mention this option as it seems likely to be the least effort. Cheers, Phil. P.S. Alternatively, it looks like you've not logged in since 2003, so if you don't need the account any more, I could remove it. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpx6BQm2IuU5.pgp Description: PGP signature
Re: need install 'how to' help
On Sun, Jun 08, 2008 at 07:52:20AM -0500, L. Mart wrote: Sounds like you want to use loadlin and the hard-drive method. There's a copy of loadlin here (I know you say you've already got a copy, but just in case it's old or whatever): http://www.uk.debian.org/debian/tools/lodlin16.zip it has a readme.1st file that tells you how to use it. The short version is that with loadlin, a copy of the vmlinuz inittrd files from here: http://www.uk.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/ and a relevant ISO image, say: http://cdimage.debian.org/cdimage/release/4.0_r3/i386/bt-cd/debian-40r3-i386-netinst.iso.torrent ( or if you cannot bittorrent: http://cdimage.debian.org/cdimage/release/4.0_r3/i386/iso-cd/debian-40r3-i386-netinst.iso ) you should be able to use the Hard Disk install method, by pitting all the files in the C:\ directory, making sure that the .iso file has a filename that ends in .iso, and then running LOADLIN.EXE as per the instructions. You should probably make sure that you have a DOS rescue floppy just in case you get to the point where you've wiped out DOS, and find that GRUB refuses to install, so that you can at least get back to where you are by using FDISK.EXE etc. Anyway, with the relevant files copied into place using DOS, you should be able to run LOADLIN from DOS and then start the install. I'm a little surprised this isn't covered in more detail here: http://www.uk.debian.org/releases/stable/i386/ch02s02.html.en#id2530955 perhaps you could report back on how you got on, and we can use your experience to document this more fully -- if you make notes of the bits that made this confusing as you go along that will help to suggest the bits that need to be covered in more detail. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ a(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf8 bof: building debian from debian
On Fri, May 30, 2008 at 02:36:33PM -0700, Vagrant Cascadian wrote: ... people interested in the following tools or similar tools would be valuable to the discussion: debian-installer debian-cd simple-cdd debian-live xen-tools util-vserver pbuilder cdebootstrap debootstrap LTSP FAI Count me in. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian DVD downloading.
On Sat, May 31, 2008 at 09:51:52AM +0200, Marek Sadło wrote: Hello ! My name is Mark. I decided to download a debian linux for my computer, I already downloaded all the parts of it but once i try download last one, (this:debian-testing-i386-DVD-3.iso)http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-dvd/debian-testing-i386-DVD-3.iso If you already have DVDs #1 #2 then you should probably just get on with installing it, especially if the new machine is going to have Internet access while you install. Debian CD and DVD sets are built so that you can do a successful install with no more than the first CD/DVD -- the more you add the less downloading will be needed during the install, but you've probably got 99.9% of the packages you actually want installed on the first 2 DVDs so the rest are probably not worth worrying about, unless the reason you want them is something like you want to run of copies and then sell other people complete sets, say, or you're going somewhere with no Internet connection, and you know that a package you want is on DVD #3. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help
On Fri, May 30, 2008 at 03:34:40PM -0300, Esteban López wrote: Hello, I continue having problems to consent to this link: http://gemmei.acc.umu.se/debian-cd/4.0_r3/i386/iso-dvd/debian-update-4.0r3-i386-DVD-1.iso I need to lower this file and I am not able to, I already proved in several mirrors, greetings. Perhaps you should try using bittorrent instead: http://gemmei.acc.umu.se/debian-cd/4.0_r3/i386/bt-dvd/debian-update-4.0r3-i386-DVD-1.iso.torrent You will need a bittorrent client[1], but at least if it stops for some reason, you can start it again, and it will eventually get the whole image for you. [1] http://www.slyck.com/bt.php?page=2 Hope that helps. Cheers, Phil. signature.asc Description: Digital signature
Re: 700 MB media
Petter Reinholdtsen wrote: [Richard Atterer] IMHO, definitely - it's been a very long time since I last saw 650 MB media... It is less then a year ago since debian-edu tried to switch from 650 to 700 MB images, and got reports about CD burners unable to burn the images. Because of this, debian-edu still make 650 MB images. With Steve's whizzy new patch for generating jigdos straight from mkisofs, it all runs fast enough so that we could contemplate generating jigdos for both sizes, as well as business cards DVDs, say. It's not like extra jigdo versions take up much room. If we do that, CD vendors and home CD burners can chose a size that suits their hardware. Cheers, Phil. signature.asc Description: OpenPGP digital signature
Re: Official Mirrors for stable .jigdo files broken
Richard Atterer wrote: Hi, another thing which I should have reacted on earlier: The official locations for US/European mirrors of the stable .jigdo files have been broken for *MONTHS*. I mailed Phil about this various times without success - no idea what happened to him. :-/ Oops, did I not tell you when I finally got my act together (about a month ago), and pointed us.cdimage at open? Sorry about that. It should be working OK now. Cheers, Phil. signature.asc Description: OpenPGP digital signature
Re: debian-cd CVS back online - new jigdo fallback generation feature
At Thu, 18 Dec 2003 11:37:33 +0100, Richard Atterer [EMAIL PROTECTED] wrote: [1 text/plain; iso-8859-15 (quoted-printable)] On Thu, Dec 18, 2003 at 10:45:15AM +0100, Raphael Hertzog wrote: the debian-cd CVS repository is back online (after a check of its integrity). Thanks, Raphal! I've just committed some code which makes the generation of fallback mirrors much easier. Furthermore, it produces relative template URLs in jigdo files by default. However, Phil, this /might/ break your publish_cds script - it is intended to replace publish_cds. With this feature, you can make debian-cd generate a directory with fallback links not after, but *during* template generation. This is done with jigdo-file's --match-exec switch, which executes a user-defined command whenever a file is found in the image. Fine, publish_cds only replaces what's in there already, so I can either remove that code, or make it so that the replacement is also relative. I still need publish CDs to move the images from the staging area to the published area, and generate the MD5SUMS files, but it would become pretty trivial if it didn't have to do the snapshot. Advantages over publish_cds: Better integrated into debian-cd, less of a hack. ;) The nice thing about setting it at publish time is that you can run publish_cds with a version number of pre-release-test say, and if it works, re-run it with 3.X_rY on the same images, with no oportunity to screw up. ;-) Not that I do that sort of test, now that publish_cds works. Oh the other thing that you may not have noticed is that I have a hacked up version of publish_cds, called build_snapshot, that I run on raff to build the matching snapshot for us.cdimage.d.o. Since the bulk of fallback requests go to raff, I don't see the nasty hack going away too soon I'm afraid :-/ I should tidy build_snapshot up, take the funcionality out of publish_cds, and put build_snapshot into CVS really, so others can build snapshots (although I'm not sure how useful that is, given that there are only two places that the jigdos point at) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-cd CVS back online - new jigdo fallback generation feature
At Thu, 18 Dec 2003 11:37:33 +0100, Richard Atterer [EMAIL PROTECTED] wrote: [1 text/plain; iso-8859-15 (quoted-printable)] On Thu, Dec 18, 2003 at 10:45:15AM +0100, Raphael Hertzog wrote: the debian-cd CVS repository is back online (after a check of its integrity). Thanks, Raphal! I've just committed some code which makes the generation of fallback mirrors much easier. Furthermore, it produces relative template URLs in jigdo files by default. However, Phil, this /might/ break your publish_cds script - it is intended to replace publish_cds. With this feature, you can make debian-cd generate a directory with fallback links not after, but *during* template generation. This is done with jigdo-file's --match-exec switch, which executes a user-defined command whenever a file is found in the image. Fine, publish_cds only replaces what's in there already, so I can either remove that code, or make it so that the replacement is also relative. I still need publish CDs to move the images from the staging area to the published area, and generate the MD5SUMS files, but it would become pretty trivial if it didn't have to do the snapshot. Advantages over publish_cds: Better integrated into debian-cd, less of a hack. ;) The nice thing about setting it at publish time is that you can run publish_cds with a version number of pre-release-test say, and if it works, re-run it with 3.X_rY on the same images, with no oportunity to screw up. ;-) Not that I do that sort of test, now that publish_cds works. Oh the other thing that you may not have noticed is that I have a hacked up version of publish_cds, called build_snapshot, that I run on raff to build the matching snapshot for us.cdimage.d.o. Since the bulk of fallback requests go to raff, I don't see the nasty hack going away too soon I'm afraid :-/ I should tidy build_snapshot up, take the funcionality out of publish_cds, and put build_snapshot into CVS really, so others can build snapshots (although I'm not sure how useful that is, given that there are only two places that the jigdos point at) Cheers, Phil.
Re: debian-cd CVS back online - new jigdo fallback generation feature
At Thu, 18 Dec 2003 11:37:33 +0100, Richard Atterer [EMAIL PROTECTED] wrote: [1 text/plain; iso-8859-15 (quoted-printable)] On Thu, Dec 18, 2003 at 10:45:15AM +0100, Raphael Hertzog wrote: the debian-cd CVS repository is back online (after a check of its integrity). Thanks, Raphal! I've just committed some code which makes the generation of fallback mirrors much easier. Furthermore, it produces relative template URLs in jigdo files by default. However, Phil, this /might/ break your publish_cds script - it is intended to replace publish_cds. With this feature, you can make debian-cd generate a directory with fallback links not after, but *during* template generation. This is done with jigdo-file's --match-exec switch, which executes a user-defined command whenever a file is found in the image. Fine, publish_cds only replaces what's in there already, so I can either remove that code, or make it so that the replacement is also relative. I still need publish CDs to move the images from the staging area to the published area, and generate the MD5SUMS files, but it would become pretty trivial if it didn't have to do the snapshot. Advantages over publish_cds: Better integrated into debian-cd, less of a hack. ;) The nice thing about setting it at publish time is that you can run publish_cds with a version number of pre-release-test say, and if it works, re-run it with 3.X_rY on the same images, with no oportunity to screw up. ;-) Not that I do that sort of test, now that publish_cds works. Oh the other thing that you may not have noticed is that I have a hacked up version of publish_cds, called build_snapshot, that I run on raff to build the matching snapshot for us.cdimage.d.o. Since the bulk of fallback requests go to raff, I don't see the nasty hack going away too soon I'm afraid :-/ I should tidy build_snapshot up, take the funcionality out of publish_cds, and put build_snapshot into CVS really, so others can build snapshots (although I'm not sure how useful that is, given that there are only two places that the jigdos point at) Cheers, Phil.
Re: Absolute template URLs in official .jigdo files
At Tue, 16 Dec 2003 11:51:57 +0100, Richard Atterer [EMAIL PROTECTED] wrote: Could this be changed to use relative URLs for future releases? Just checking --- presumably, what is now: Template=http://us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/i386/woody-i386-1.template should become: Template=/jigdo-area/3.0_r2/jigdo/i386/woody-i386-1.template is that right? Given that this could be changed without doing any damage to the current MD5SUMS, should we consider just changing the existing jigdo files? Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Absolute template URLs in official .jigdo files
At Tue, 16 Dec 2003 11:51:57 +0100, Richard Atterer [EMAIL PROTECTED] wrote: Hello, every now and then, there are complaints from people who mirror the official .jigdo/.template files: The .jigdo files contain absolute .template URLs, so the templates are always fetched from us.cdimage, which creates a single point of failure and defeats the purpose of mirroring the .jigdo/.template files. Could this be changed to use relative URLs for future releases? Yeah, no problem. One reason for the absolute URLs was that the version of jigdo-lite in woody didn't allow them. This is no longer true as of 3.0r2 - jigdo-file 0.6.5-2 supports them. Ah, I knew there was a reason --- fair enough. I think the other reason is that Phil doesn't want people to download the templates from non-us.cdimage, just from us.cdimage. Phil, maybe you could solve this issue on your side by using HTTP redirects? Nah, I don't have a problem with that. I think it was totally due to the absolute URL thing. I'll tweak my publish_cds script now. Cheers, Phil.
Re: jigdo file corrupted ?
At Thu, 4 Dec 2003 10:36:03 +0100, Brouckaert Olivier (DBB) wrote: Hi, I just download http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/i386/woody-i386-1.jigdo and when i try to make the iso it goes to us.cdimage.debian.org instead of non-us (I checked in woody-i386-1.jigdo and its pointing to us server) The only way I found to have it working is delete woody-i386-1.jigdo, modify woody-i386-1.jigdo.unpacked to point to non-us server and gives woody-i386-1.jigdo.unpacked to jigdo-lite instead of woody-i386-1.jigdo I hadn't copied the templates over at the time --- sorry --- they should be fine now that the're also available from the US server (raff.d.o) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
3.0_r2 jigdos finally signed off --- please check MD5SUMs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Folks, Sorry about this, but for several of the architectures the images I had made ended up being larger than 650MB. Since Steve independently managed to produce images that were actually small enough to fit on a 650MB CD, I've decided to go with his images, so if you grabbed images in the mean time, you may have a copy of mine, with a large 1_NONUS CD. Both sets are internally consistent, so if you've burnt some already (onto 700MB media say) they should work fine, but they won't be the official ones, since the official ones are designated by the presence of a signed MD5SUM file. If people have run off a few thousand of the wrong set (and assuming they really do work) I'm open to persuasion that I should just sign the superseded MD5SUM file, and call it MD5SUM.oversize or something, and treat both as official given that they should both be equally valid, but hopefully that's not happened yet. On the whole, this could have gone smoother than it did, and would probably have gone much better if I'd just left it to Steve, who we have to thank for producing the vast majority of the images that we're actually using for 3.0_r2 --- Thanks Steve :-) Anyway, the signed MD5SUM files are now there for the taking (all bar the source, which should be ready shortly) so if you are worried about it, check your sums. Again, my apologies for any inconvenience. Cheers, Phil. - -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE/0P2lYgOKS92bmRARAjmvAJoCTh39Di1GrwzW+hq5iP3h1gQurwCfYPrF M5+9X9PWJYmDWQvVHM8dmZo= =mlVI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: jigdo file corrupted ?
At Thu, 4 Dec 2003 10:36:03 +0100, Brouckaert Olivier (DBB) wrote: Hi, I just download http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/i386/woody-i386-1.jigdo and when i try to make the iso it goes to us.cdimage.debian.org instead of non-us (I checked in woody-i386-1.jigdo and its pointing to us server) The only way I found to have it working is delete woody-i386-1.jigdo, modify woody-i386-1.jigdo.unpacked to point to non-us server and gives woody-i386-1.jigdo.unpacked to jigdo-lite instead of woody-i386-1.jigdo I hadn't copied the templates over at the time --- sorry --- they should be fine now that the're also available from the US server (raff.d.o) Cheers, Phil.
3.0_r2 jigdos finally signed off --- please check MD5SUMs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Folks, Sorry about this, but for several of the architectures the images I had made ended up being larger than 650MB. Since Steve independently managed to produce images that were actually small enough to fit on a 650MB CD, I've decided to go with his images, so if you grabbed images in the mean time, you may have a copy of mine, with a large 1_NONUS CD. Both sets are internally consistent, so if you've burnt some already (onto 700MB media say) they should work fine, but they won't be the official ones, since the official ones are designated by the presence of a signed MD5SUM file. If people have run off a few thousand of the wrong set (and assuming they really do work) I'm open to persuasion that I should just sign the superseded MD5SUM file, and call it MD5SUM.oversize or something, and treat both as official given that they should both be equally valid, but hopefully that's not happened yet. On the whole, this could have gone smoother than it did, and would probably have gone much better if I'd just left it to Steve, who we have to thank for producing the vast majority of the images that we're actually using for 3.0_r2 --- Thanks Steve :-) Anyway, the signed MD5SUM files are now there for the taking (all bar the source, which should be ready shortly) so if you are worried about it, check your sums. Again, my apologies for any inconvenience. Cheers, Phil. - -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE/0P2lYgOKS92bmRARAjmvAJoCTh39Di1GrwzW+hq5iP3h1gQurwCfYPrF M5+9X9PWJYmDWQvVHM8dmZo= =mlVI -END PGP SIGNATURE-
Re: jigdo
At Tue, 2 Dec 2003 14:06:40 +0100, Richard Atterer [EMAIL PROTECTED] wrote: On Tue, Dec 02, 2003 at 12:52:19AM +, Philip Hands wrote: Assertion failed: oldAreaEnd == start You have found a bug in jigdo-file. The generated .template file is very likely broken! To help me find the bug, please rerun the command as follows: [previous-command] --report=noprogress --debug log 21 so I'm now feeling a bit stupid. Um, jigdo CVS fixes two (IIRC) problems with this. One of these two fixes just disables this warning in a particular situation, so the message doesn't actually indicate that the file *is* broken. If jigdo-file list-template doesn't complain that the .template is broken, you've hit this (non-)problem. Nah, it really is broken :-) jigdo-file list-template barfs on the resulting templates. This was with 0.6.9. Is 0.7.0 likely to fix the problem (I've installed that now) or do I need the CVS. While we're on the subject, I've since realised that the thing that was taking most of the time when generating the images was jigdo, since a run using jigdo takes over 2 hours per CD on open, whereas just producing ISO images takes under 10 mins per CD (once you get into the production of CDs phase). Am I doing something wrong? I don't remember jigdo slowing things down quite that badly. Is this a symptom of our ever expanding package pool? Cheers, Phil.
Re: jigdo
At Tue, 2 Dec 2003 00:24:20 +, Steve McIntyre wrote: [1 text/plain; us-ascii (quoted-printable)] On Mon, Dec 01, 2003 at 06:50:52PM +, Philip Hands wrote: Well, I was rather hoping to have them ready by now (or even by when you asked ;-) but for some reason jigdo has been producing broken .template files for i386 on open.hands.com on the last couple of attempts, and each attempt seems to be taking ages too, and I had a couple of broken .debs on my mirror as well which killed another couple of attempts. Oh well. I'm re-running the attempt now, with the option to generate the .iso images as well, rather than doing the jigdos only, which was what I was doing before, so even if the jigdo stage fails again we should have some images soon for i386. Phil, if it helps I can start doing images and jigdos of other architectures on the mirror on sledge, and then we can at least run in parallel to improve performance. I'll start working backwards alphabetically, so I'm doing sparc first... OK? Good idea. I finally managed to have the sense to read the typescript _before_ restarting stuff and thereby destroying the evidence, which tells me: Assertion failed: oldAreaEnd == start You have found a bug in jigdo-file. The generated .template file is very likely broken! To help me find the bug, please rerun the command as follows: [previous-command] --report=noprogress --debug log 21 so I'm now feeling a bit stupid. I've upgraded jigdo-file to the latest version to see if that fixes it, but at least we're getting the ISOs regardless this time I doubt that the i386 and source will be done before mid-morning at current rates, so you may overtake me completely. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: jigdo
At Tue, 25 Nov 2003 16:19:31 + (GMT), Brian Teeman wrote: any chance of jigdo files for r2 being released anytime soon. Kind of hard to offer it to the public without the CDs Well, I was rather hoping to have them ready by now (or even by when you asked ;-) but for some reason jigdo has been producing broken .template files for i386 on open.hands.com on the last couple of attempts, and each attempt seems to be taking ages too, and I had a couple of broken .debs on my mirror as well which killed another couple of attempts. Oh well. I'm re-running the attempt now, with the option to generate the .iso images as well, rather than doing the jigdos only, which was what I was doing before, so even if the jigdo stage fails again we should have some images soon for i386. Cheers, Phil.
Re: jigdo
At Tue, 2 Dec 2003 00:24:20 +, Steve McIntyre wrote: [1 text/plain; us-ascii (quoted-printable)] On Mon, Dec 01, 2003 at 06:50:52PM +, Philip Hands wrote: Well, I was rather hoping to have them ready by now (or even by when you asked ;-) but for some reason jigdo has been producing broken .template files for i386 on open.hands.com on the last couple of attempts, and each attempt seems to be taking ages too, and I had a couple of broken .debs on my mirror as well which killed another couple of attempts. Oh well. I'm re-running the attempt now, with the option to generate the .iso images as well, rather than doing the jigdos only, which was what I was doing before, so even if the jigdo stage fails again we should have some images soon for i386. Phil, if it helps I can start doing images and jigdos of other architectures on the mirror on sledge, and then we can at least run in parallel to improve performance. I'll start working backwards alphabetically, so I'm doing sparc first... OK? Good idea. I finally managed to have the sense to read the typescript _before_ restarting stuff and thereby destroying the evidence, which tells me: Assertion failed: oldAreaEnd == start You have found a bug in jigdo-file. The generated .template file is very likely broken! To help me find the bug, please rerun the command as follows: [previous-command] --report=noprogress --debug log 21 so I'm now feeling a bit stupid. I've upgraded jigdo-file to the latest version to see if that fixes it, but at least we're getting the ISOs regardless this time I doubt that the i386 and source will be done before mid-morning at current rates, so you may overtake me completely. Cheers, Phil.
Re: 3.0_r1 jigdos available for comment
At Fri, 20 Dec 2002 23:46:37 +1000 (EST), jason andrade wrote: On Fri, 20 Dec 2002, Philip Hands wrote: http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/ and http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/ [note, the NONUS jigdos are actually available at both of the above; it's just the snapshots that differ, and jigdo deals with that for you anyway] i don't understand what this means. are they separate jigdo files needed depending on whether you are trying to generate NON_US disc1 or not ? I see you worked that out, and you're correct. The point being that there is no non-US content in the NONUS jigdo files, so they can be published in the US. It's only when you come to reassemble them that you need to go to the non-us sites for the packages. I've not signed these off yet, and won't be able to until tomorrow, but I'm pretty confident that they're OK, so unless someone points out a flaw in the next 24 hours, these are going to be the released images. i've started mirroring the jigdo files and will start creating the iso images using jigdo lite and then rsyncing against open iso images. one query, why are files created into debian-jigdo/3.0_r1/jigdo/ ? on our server we have /pub/debian-cd/jigdo-area/3.0_r1/architecture but am i missing something ? The reason is, that on the master sites there is a directory at the same level as the jigdo directory that you are wondering about, called snapshot which contains a snapshot of the files required to build the jigdos, so that if some file on the main archive changes, there will always be a copy of it available. Obviously, there's not much point rsyncing the snapshot, so I've set up a copy of the 3.0_r1 directory with that missing, but it seemed to make sense to keep the structure the same. You can see what I'm on about here: http://us.cdimage.debian.org/jigdo-area/3.0_r1/ http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/ Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0_r1 jigdos available for comment
At Fri, 20 Dec 2002 23:46:37 +1000 (EST), jason andrade wrote: On Fri, 20 Dec 2002, Philip Hands wrote: http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/ and http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/ [note, the NONUS jigdos are actually available at both of the above; it's just the snapshots that differ, and jigdo deals with that for you anyway] i don't understand what this means. are they separate jigdo files needed depending on whether you are trying to generate NON_US disc1 or not ? I see you worked that out, and you're correct. The point being that there is no non-US content in the NONUS jigdo files, so they can be published in the US. It's only when you come to reassemble them that you need to go to the non-us sites for the packages. I've not signed these off yet, and won't be able to until tomorrow, but I'm pretty confident that they're OK, so unless someone points out a flaw in the next 24 hours, these are going to be the released images. i've started mirroring the jigdo files and will start creating the iso images using jigdo lite and then rsyncing against open iso images. one query, why are files created into debian-jigdo/3.0_r1/jigdo/ ? on our server we have /pub/debian-cd/jigdo-area/3.0_r1/architecture but am i missing something ? The reason is, that on the master sites there is a directory at the same level as the jigdo directory that you are wondering about, called snapshot which contains a snapshot of the files required to build the jigdos, so that if some file on the main archive changes, there will always be a copy of it available. Obviously, there's not much point rsyncing the snapshot, so I've set up a copy of the 3.0_r1 directory with that missing, but it seemed to make sense to keep the structure the same. You can see what I'm on about here: http://us.cdimage.debian.org/jigdo-area/3.0_r1/ http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/ Cheers, Phil.
3.0_r1 jigdos available for comment
Hi Folks, open is slowly trundling through the architectures (so far we have alpha arm hppa i386 source published, and copied to raff) so get them while they're hot: http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/ and http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/ [note, the NONUS jigdos are actually available at both of the above; it's just the snapshots that differ, and jigdo deals with that for you anyway] I've not signed these off yet, and won't be able to until tomorrow, but I'm pretty confident that they're OK, so unless someone points out a flaw in the next 24 hours, these are going to be the released images. Note: i386 source have been regenerated, and overwritten (without a version number change) because the first attempt had the old, wrong, README. Jigdos dated before the 19th Dec are the old ones, please update if you have these. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
3.0_r1 jigdos available for comment
Hi Folks, open is slowly trundling through the architectures (so far we have alpha arm hppa i386 source published, and copied to raff) so get them while they're hot: http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/ and http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/ [note, the NONUS jigdos are actually available at both of the above; it's just the snapshots that differ, and jigdo deals with that for you anyway] I've not signed these off yet, and won't be able to until tomorrow, but I'm pretty confident that they're OK, so unless someone points out a flaw in the next 24 hours, these are going to be the released images. Note: i386 source have been regenerated, and overwritten (without a version number change) because the first attempt had the old, wrong, README. Jigdos dated before the 19th Dec are the old ones, please update if you have these. Cheers, Phil.
Re: woody-i386-1_NONUS.jigdo 3.0 r1 is buggy
At Thu, 19 Dec 2002 00:17:28 +0100, Gandalf wrote: [1 text/plain; iso-8859-1 (7bit)] Hello I think the jigdo file http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.jigdo is buggy because it points to http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.template and not to http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.template It's intentional (the plan is to inflict as much of the load as possible on the US server) but I should have made the snapshot on raff before allowing public access to the jigdo files, but now that I'm redoing the images it needs to be done again anyway, so I'm not going to bother with this set. I'll sort out the US snapshot with the next lot. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0r1: where are the jigdos?
At Tue, 17 Dec 2002 20:03:57 +0100, Richard Atterer wrote: On Tue, Dec 17, 2002 at 11:50:06AM +0700, Rahmat M. Samik-Ibrahim wrote: * 3.0r1: where are the jigdos? The CDs for 3.0r1 (and thus the .jigdo files) haven't been generated yet. Please wait for a few days. Well, I just put the i386 ones in the public area on cdimage when Anne Bezemer pointed out that the unofficial in the README was still there (apparently the change never made it into CVS), so I'm going to start generating the images again (there was a slightly suspicious warning message in the typescript, so I'd be happier with another run at it anyway). The only differences between the published images, and the ones I'm about to make should be the README and apt-setup docs, but the ones that are currently under the 3.0r1 directory are NOT official. This leaves me with a problem --- should I rename the next ones (3.0r1a perhaps, which seems to be what is in the Release file anyway) or simply overwrite them? Given that they were publicly visible for a few hours before I realised that they needed to be regenerated, there might be copies of them out there already, so perhaps it's best to rename them. Admittedly, I've not signed the MD5SUMS yet, so they don't count as official anyway, and I doubt it will injure anyone seriously to have a slightly outdated README, so perhaps I should just overwrite them when the new images turn up in a few hours. Anyway, the files that are not to be considered released are the ones dated around Dec 18 22:15 GMT. Feel free to play with them, but please don't rush out and produce thousands of copies and label them official because they're not. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0r1: where are the jigdos?
At Tue, 17 Dec 2002 20:03:57 +0100, Richard Atterer wrote: On Tue, Dec 17, 2002 at 11:50:06AM +0700, Rahmat M. Samik-Ibrahim wrote: * 3.0r1: where are the jigdos? The CDs for 3.0r1 (and thus the .jigdo files) haven't been generated yet. Please wait for a few days. Well, I just put the i386 ones in the public area on cdimage when Anne Bezemer pointed out that the unofficial in the README was still there (apparently the change never made it into CVS), so I'm going to start generating the images again (there was a slightly suspicious warning message in the typescript, so I'd be happier with another run at it anyway). The only differences between the published images, and the ones I'm about to make should be the README and apt-setup docs, but the ones that are currently under the 3.0r1 directory are NOT official. This leaves me with a problem --- should I rename the next ones (3.0r1a perhaps, which seems to be what is in the Release file anyway) or simply overwrite them? Given that they were publicly visible for a few hours before I realised that they needed to be regenerated, there might be copies of them out there already, so perhaps it's best to rename them. Admittedly, I've not signed the MD5SUMS yet, so they don't count as official anyway, and I doubt it will injure anyone seriously to have a slightly outdated README, so perhaps I should just overwrite them when the new images turn up in a few hours. Anyway, the files that are not to be considered released are the ones dated around Dec 18 22:15 GMT. Feel free to play with them, but please don't rush out and produce thousands of copies and label them official because they're not. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
Re: woody-i386-1_NONUS.jigdo 3.0 r1 is buggy
At Thu, 19 Dec 2002 00:17:28 +0100, Gandalf wrote: [1 text/plain; iso-8859-1 (7bit)] Hello I think the jigdo file http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.jigdo is buggy because it points to http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.template and not to http://non-us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.template It's intentional (the plan is to inflict as much of the load as possible on the US server) but I should have made the snapshot on raff before allowing public access to the jigdo files, but now that I'm redoing the images it needs to be done again anyway, so I'm not going to bother with this set. I'll sort out the US snapshot with the next lot. Cheers, Phil.
Re: sarge CDs
On Wed, 2002-08-14 at 17:43, Anthony Towns wrote: On Mon, Aug 12, 2002 at 02:04:48PM +0100, Philip Hands wrote: On Thu, 2002-08-08 at 08:26, Anthony Towns wrote: On Wed, Aug 07, 2002 at 12:30:34PM +0100, Philip Hands wrote: OK -- I'll sort out an automated thing for sarge on open, just as soon as I've got my act together and worked out what went wrong with half the DVDs for woody. Hrm? I thought we were going to move to raff for the extra speed and space? (Since we were going to do this months ago, I'd rather avoid putting that move off too much further...) Well, it might be nice, but how can I do non-US CDs on raff? I'm still in favour of having a CD#n+1 non-US only CD, rather than alternate CD#1's personally, and doing the non-US CD entirely separately, on satie or open or wherever. There are two problems with that as I see it: 1) there's nowhere near a CD's worth in non-US, so it will almost always up the CD count by 1 2) This might be considered a personal opinion, but I've always considered the true Debian distribution to include non-US, and the non-US setup to simply be an implementation detail that allows us to service the requirements of US law. Packages in non-US get a slight second class citizen status as it is, relegating them to their own CD would reinforce that stigma, which I think would be unfortunate. In fact, I'd rather call the two versions of CD#1 something like CD1 and CD1_US. Do you have a problem with that, for 3.0 r1. I think it would cut down on the number of people outside the US who uselessly download both, or annoyingly get the US one, when they wanted the complete one. While on the subject, do you know why is it that we don't seem to have packages for lame xine-css in non-US? Do we need to set up more of these (dmca.debian.org patent.debian.org perhaps, and scatter the non-US packages as appropriate?) But if that's not going to fly, it's not going to fly, which means torturing open forever more. *shrug* Well, jigdo seems to have mostly solved the torture level, and open has managed to drag itself to an uptime of 25 days, so while I'm still a bit concerned about it, it seems to be behaving itself a lot better since it's total body transplant. Sorry I've not actually got round to the CDs --- it keeps being nudged of the top of my to do list by paying clients (bastards ;-) Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: sarge CDs
On Thu, 2002-08-08 at 08:26, Anthony Towns wrote: On Wed, Aug 07, 2002 at 12:30:34PM +0100, Philip Hands wrote: OK -- I'll sort out an automated thing for sarge on open, just as soon as I've got my act together and worked out what went wrong with half the DVDs for woody. Hrm? I thought we were going to move to raff for the extra speed and space? (Since we were going to do this months ago, I'd rather avoid putting that move off too much further...) Well, it might be nice, but how can I do non-US CDs on raff? Even if I don't publish the non-US CDs, I'd need a non-US mirror so that I could make the CD1's, which presumably has the potential to involve the people who run raff in patent or DMCA issues. Presumably, the new CDs should use the debian-installer floppies, as mentioned by Tollef. If they're ready; it'd be better to have unbootable CDs up sooner than d-i CDs later. OK. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: NONUS?
On Mon, 2002-07-29 at 11:17, Glenn McGrath wrote: On Mon, 29 Jul 2002 11:20:28 +0200 ErykD [EMAIL PROTECTED] wrote: Dear Debian CD team, I read the FAQ concerning the NONUS and non NONUS versions of cd images of Debian linux distribution, but I just can't figure out which one should I download. I am a citizen of Poland and I don't know if in the FAQ everybody meant everybody worldwide or just the US citizens? So my question is: Should I download the debian-30r0-i386-binary-1.iso or debian-30r0-i386-binary-1_NONUS.iso cd image? Thank you. Download the NONUS one. NONUS is a confusing name. NONUS means complete, the normal (US?) one is crippled due to politics. The only reason not to use the NONUS cd image instead of the US cd would be if you were afraid of the possible legal repercussions for having access to crypto software some countries dont want their people to have privacy. Well, that used to be true, until the crypto stuff generally got moved into the US main (on the assumption that the US would never re-introduce silly draconian laws. Oh. Oh dear, never mind), so now if you live in a country where they still have laws against crypto, then you have a bit of a problem using Debian CDs now. These days, non-US is mostly for things that are governed by US patent law, or perhaps DMCA infringing stuff, although people seem a bit timid about uploading, or perhaps hosting that sort of thing for some reason. Anyway, we should probably call CD1 CD1_US, CD1_NONUS CD1, and have things like patent.debian.org, dmca.debian.org etc. instead of just non-US.debian.org, and still consider the amalgamation of all the main sections on all of them to be the one true Debian, even if it turns out that we cannot legally assemble that whole anywhere on the planet. Of course, if nobody actually cares about things like the fact that violent games are illegal in Germany (assuming they still are) then going to all that effort is not justified. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
DVD signoff
OK, so we've had positive reports for i386 ia64, and no negative reports so far. Should I just assume that all the DVDs that I succeed in building (which is still missing a few) are OK, and sign them, or do people think we should wait for success reports independently for each arch? BTW Lance, you've grabbed these, haven't you --- have you tried testing the DVDs you're planning on burning? I wouldn't want to sign of the source DVDs only to find they're broken in some way. I know you noticed the sarge...Sources thing, but that file's different from the Woody one in only a few apparently irrelevant lines, so I wouldn't think it was worth re-doing the images for that, but I'd like to hear that the disk comes out readable before you get thousands of the things pressed. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: DVD signoff
On Thu, 2002-07-25 at 11:44, Lance Davis wrote: On 25 Jul 2002, Philip Hands wrote: OK, so we've had positive reports for i386 ia64, and no negative reports so far. Should I just assume that all the DVDs that I succeed in building (which is still missing a few) are OK, and sign them, or do people think we should wait for success reports independently for each arch? BTW Lance, you've grabbed these, haven't you --- have you tried testing the DVDs you're planning on burning? I wouldn't want to sign of the source DVDs only to find they're broken in some way. I grabbed i386 and source, at the moment I'm producing a dlt tape that I'll send to the pressing plant, then wait to hear from them that its ok to use. Trouble is they use a proprietary format produced by dvd mastering software, I said all they needed was an old 486 with a big hard disk running Debian - I'd send them a dlt containing the iso and all they had to do was run tar -xvf /dev/nst0 , but they remained unconvinced. So, are they efectively mastering their own ISOs? or are they doing something even more different, like producing UFS DVDs? Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: jigdo
On Wed, 2002-07-24 at 03:34, Bradley Glonka wrote: I'm having a bit of a hard time with Jigdo. Does it really connect and disconnect from and ftp server for every file it needs to get? I want to login to an ftp server and get as many files as I can. I've tried several mirrors. Are the mirrors up to date? As far as I know --- if they have the Debian3.0r0 link in dists, then chances are it's up to date. Is the mirrors list up to date? Are you trying to tell us it isn't? Is there a way to keep jigdo connected to a server? Use HTTP (it doesn't keep it connected, but you don't get the login overhead, so it's the same effect) What will define official images? Official images are ones whos md5sum's match those in the MD5SUMS files that I've signed. Phillip, too many Ls, but never mind ;-) any chance we'll see official images on the cdimage rsync server? You mean .iso's? On current evidence, I don't think it would be productive, because it would clog up cdimage.d.o to a point that the people that are currently successfully using jigdo, might not be able to grab snapshot files they might need, without really improving things. There are a few mirrors offering .iso files, so if you need them, they are out there. If you tell me that those mirrors are too busy to be usable, then you'll be making my point for me. :-) I've been trying for a few days now and still don't have one image created. And your problem is what exactly? You don't seem to have mentioned it above. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: jigdo
On Wed, 2002-07-24 at 13:10, Mattias Wadenstein wrote: Philip: A pointer to that host on http://cdimage.d.o perhaps? A link in the README.html or something like that? Probably ought to go somewhere on the www.d.o/CD/ pages, so we can change it as hosts go up down. Also, the the 3.0 rev0 CD images are only available via jigdo on the CD front page is no longer accurate, so that could go too. Could someone that knows about changing such things make it so, please? Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: jigdo
On Wed, 2002-07-24 at 17:34, Bradley Glonka wrote: Guys, Thanks for the reply. I'm having much better luck today. It seems using http is better than ftp. Thanks for that suggestion. I did have a few problems with mirrors, but the large selection eventually has led to a complete run. Jolly good. Sorry my questions were not so direct. Now what?? 7 CDs * (11 platforms + source) = WOW thats alot of CDs You're not wrong. Can each platform can be installed and run on just CD 1? Yes, with probably a little downloading after it's installed for the few packages that you might want off of the other ones. Are the tools categorized by importance to which CD they are on? Yes-ish example; are development tools on CD1? Er, not all of them, and they're not laid out in a CD3=applications type manner. You need CD1_NONUS (or CD1 in the US), CD2 is helpful, but not essential, the rest have stuff you might use, but I cannot tell you which CD it's on --- as long as you have a sequence from 1, you can use as few or many as you like, and whatever's missing will get downloaded. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Debian 3.0 released. Jigdo files available.
On Tue, 2002-07-23 at 02:33, Georg Lehner wrote: If the download tool(s) could look at the local package cache or mirror if an older (not-too old?!?) version exist and rsync the newer version on top of bandwidth could be saved. This is important at least for us with low (lw) bandwidth capacities. At times I have to recurse even to telefone links for my updates! If the gzip used to compress the files inside the packages had been patched to be rsync friendly, and if we were using that option, then what you say might be true. As it is, a one character change near the start of a compressed file can (and normally does) result in two compressed files with nothing in common that rsync could take advantage of. What makes this worse is that not only is using rsync in this manner mostly pointless, but each connection inflicts significant load on the server, so you end up doing a DDoS on our mirror servers. There is a paper about this by Martin Pool (the new upstream rsync maintainer): http://www.samba.org/cgi-bin/cvsweb/rsyncweb/rsync-and-debian/rsync-and-debian.sgml?rev=1.10content-type=text/x-cvsweb-markup in which he proposes that we switch to using rsync friendly gzip, and that there be a modified version of rsync which reverses the algorithm, and leaves most of the load on the client. He also points out that this could be done on most modern web servers, on the server side, with either minor, or no modification. It sounds a great idea to me, but it's not happened yet, so until it does, doing this would be stunningly counter-productive, I'm afraid. Cheers, Phil. Of course this is not jigdo-functionality but debian-package and version administration functionality and maybe has to be handled outside of jigdo. Best Regards, Jorge-León -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: discover, read-edid, mdetect selection in base-config
On Tue, 2002-07-23 at 09:30, Raphael Hertzog wrote: Le Mon, Jul 22, 2002 at 10:48:56PM -0500, Branden Robinson écrivait: On Mon, Jul 22, 2002 at 07:05:10PM -0400, Joey Hess wrote: [...] That doesn't quite take care of getting them onto the first CD though. And it's a bunch of special purpose code I would like to avoid maintaining, if there is any better way anyone can think of. In my opinion it's simply something that installers are going to have to special-case; at least that's what I did in PGI. Yeah, we can add the package on the first CD by modifying our task file. I'll do it right now. The packages are already on there, mostly. They just don't get used because there's nothing to get them installed before X. Hm, not certain I commited that change though, because it seemed like a nasty hack to me, since it would be nice if they were on there for dependency or base-ness reasons. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Jigdo files for 3.0_r0 edited --- mirrors, please re-rsync
Hi, N.B. The generated .iso images HAVE NOT CHANGED --- this is NOT a point release, just a jigdo optimisation that I didn't realise I could make. At Richard's prompting, I've made the Templates= bit of the .jigdo files into a relative URL, so if you are mirroring .jogdo and .template files, re-rsyncing will mean that people that use you for the jigdo source, will also grab the templates off of you, which would be nice. I was under the impression that jigdo-easy didn't deal with relative URLs but I notice that Anne has set up jigdo's under his home on open, so presumably they are for jigdo-easy users (Anne?) The files are here: rsync://cdimage.debian.org/debian-jigdo/ Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: discover, read-edid, mdetect selection in base-config
On Tue, 2002-07-23 at 18:17, Raphael Hertzog wrote: Le Tue, Jul 23, 2002 at 11:56:14AM -0400, Joey Hess écrivait: I was told they are scattered amoung the first three cd's. Discover was already on the first CD. I don't know for the two other packages. Anyway, they'll be on the first CD next time we build a CD set (if Phil uses the latest CVS version as he's usually doing). Yeah, sill me --- discover and a couple of other things were forced on 1 by me, by tacking them onto tasks/forcd1: python-configlet configlet-frontends etherconf timezoneconf localeconf gnome-tasksel stormpkg discover kudzu sndconfig aptitude for some reason I thought the other two were included in that list. Sorry Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Debian 3.0 released. Jigdo files available.
On Mon, 2002-07-22 at 11:54, Attila Nagy wrote: If you have a desperate need for ISOs, and jigdo doesn't do it for you for some reason, I do have ISOs available which I may be persuaded to grant password controlled rsync access to on request, but you'll need a convincing reason why jigdo doesn't work for you. That means the following from http://www.debian.org/CD/ is not true? At the moment, the 3.0 rev0 CD images are only available via jigdo. Normal HTTP/FTP downloads will be possible in a few days. Both were true --- for different audiences. If YOU (or anyone lese reading this) need ISOs, and you've tried jigdo, and it doesn't work, and you present the evidence here so we get to address the problem, but you still need the ISOs and cannot wait, then I'll sort out a password for you. I can do without every slashdot reader that stumbles upon the website sending me a Give me a password, I really need Debian email though. OK? As it happens, a couple of sites have appeared with ISOs for download, and I expect a few more will soon. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
RE: unreleased DVD jigdos for testing
On Sun, 2002-07-21 at 09:39, Martijn Stegeman wrote: Could you rename the MD5SUMS-DVD to MD5SUMS? It seems your apache setup doesn't know it's a text file now. It sends application/binary as the mime type. Well, I wanted to keep the names different so I could generate them in a populated CD directory, in future, so I've just fixed the apache problem. OK? Thanks for the hint. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: A Question.
On Sun, 2002-07-21 at 14:48, Chris Tillman wrote: Forwarded from debian-doc to debian-cd: On Sun, Jul 21, 2002 at 08:45:32PM +0800, ?B [EMAIL PROTECTED] wrote: HI! I have a question that: Is there any question between debian-30r0-i386-binary-1.iso and debian-30r0-i386-binary-1_NONUS.iso If I would like to install Debian with Traditional Chinese , where iso file should I use ??? Thanks for answering! Good luck! :) The real CD#1 is CD1_NONUS, so if you're in China, use that. CD1 (without the _NONUS) is the same CD, stripped of all the non-US packages, so is only of interest to people that decide they want to abide by the USA's silly (mostly patent related) laws. Just in case that wasn't clear enough, there are only 7 (or sometimes 6) binary CDs per architecture. There are two versions of CD#1. Practically everyone probably wants CD1_NONUS, but if you're a worried US resident, feel free to get CD1 _instead_. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: cd image
On Mon, 2002-07-22 at 16:28, Debian Mail wrote: what image should I download just 1 or all 7 I generally just get the first CD. Things I don't find there will be loaded directly from the net. With apt-get this is really easy. Agreed. apt-get is the advantage that will repay you tenfold if you decide to go through the slightly more painful installation mentioned below. I have a intel system ??? and new at this never tryed Linux before Hm, Debian may be a little tough then... As a newbie you're probably better off with one of the commercial distros (Suse seems to be quite well suited for beginners). Will save you some frustration. A) I've seen some newbies struggle with Debian, and I've see other refreshed that we don't try to hide what's going on, which was what really pissed them off about that other operating system in the first place, because it would never tell them what went wrong. B) If you're going to recommend an alternative, which I admit will suit some people more than Debian, do we really have to recommend the one major distribution that is non-free software? SuSE's installer YaST has a non-free license, which means that you don't get all the advantages of Free Software that you get with almost all the other distributions, especially Debian. When someone finally decides to take the plunge, and try Free Software, redirecting them back to the land of proprietary software doesn't seem overly productive. Also, from what I can tell, SuSE is easier for the same reasons as Windows --- it cocoons you from the underlying Operating System, so while it makes the first install easier, it make educating toyrself about how the system actually works more difficult. Perhaps the decision to move to Free Software was prompted by a hinger to learn, in which case, I don't think SuSE is a choice I'd recommend, simply because you end up learning about YaST, more than about GNU or Linux. That said, technically SuSE is pretty good, just a shame about the silly licensing decision w.r.t. YaST. But if you have a good IT background you can try Debian right ahead. Sooner or later you'll probably get back to it anyway :-) That on the other hand, I can agree with wholeheartedly :-) if I can I would like to send you a few bucks to help a tiny bit? If after this you still decide you want to install Debian anyway (despite our marvellous marketing team ;-), then if you want to help us, take detailed notes of how it went, and what problems you had, and why, and when you're confident enough to do so, send write them up, and ask around for where is the best place to send them --- newbies are a scarce resource, and as soon as you've done this once, your perceptions are changed, and you'll never again be able to put yourself in the newbie mindset, so usability testing from newbies is pretty much impossible to come by. A description of how you got on, and what problems made you get really stuck is likely to be much more valuable to us that a few bucks, but thanks for the offer, it was very kind. :-) Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Debian 3.0 released. Jigdo files available.
On Mon, 2002-07-22 at 12:28, Attila Nagy wrote: The two behaviours I've seen so far: - they just don't care and are waiting for updates from cdimage.debian.org, where they've used to mirror from - they did a search and found jigdo, but don't know what is that (they are now learning :) - they already got the files with some manual magic (jigdo, download from another site, etc) This release method saves lot of internet pipes from being saturated. :) Yeah, it's working for me :-) This is the first time in, er, probably all the releases since open has existed, when I can get on the machine after a release, and not really notice a serious difference from a normal day --- pretty astounding. And all the people who've bothered to look into jigdo, and then mentioned it to me, seem to have got it working, and ended up with CDs faster and easier than they've ever managed with rsync. Good job Richard. Well done :-) Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: A Question.
On Mon, 2002-07-22 at 22:46, jason andrade wrote: On 22 Jul 2002, Philip Hands wrote: CD1 (without the _NONUS) is the same CD, stripped of all the non-US packages, so is only of interest to people that decide they want to abide by the USA's silly (mostly patent related) laws. hmm. isn't it about time that NON_US became cd#1 and instead there was a _US created ? :-) That was my original intent. I'm certainly happy to do it that way, and since I've always considered 1_NONUS to be the official CD#1, with 1 just being something to keep our American chums cheerful, it makes perfect sense to me. I seem to remember that The Society for the Easily Confused registered an official complaint that having the server called non-US, and the CD called US would cause problems, but clearly the reverse is also true, so let's go for it --- probably best to leave it till 3.0_r1 though, eh ;-) Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
RE: Debian 3.0 released. Jigdo files available.
On Tue, 2002-07-23 at 00:26, Battista, JohnX wrote: Great job on the 3.0 release. Any way IA-64 will be released as DVD for jigdo? Well, it depends what you mena by released. If you test these ones: http://cdimage.debian.org/jigdo-area/3.0_r0/jigdo/dvd-test/ and tell me they work (or what's wrong with them), we might be able to get to the point where I'm willing to sign them off as released. Does that help? BTW for those that are interested, I think I've fixed the template URL problem, so feel free to tell me again if it's still broken. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
RE: Debian 3.0 released. Jigdo files available.
On Tue, 2002-07-23 at 01:01, Lance Davis wrote: On 23 Jul 2002, Philip Hands wrote: On Tue, 2002-07-23 at 00:26, Battista, JohnX wrote: Great job on the 3.0 release. Any way IA-64 will be released as DVD for jigdo? Well, it depends what you mena by released. If you test these ones: http://cdimage.debian.org/jigdo-area/3.0_r0/jigdo/dvd-test/ Is there rsync/ftp access to this directory ?? no, I didn't want it spreading to all the mirrors and giving the impression that it was released Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
[Fwd: Sparc CD issues]
Hi, Seems the 3.0_r0 sparc CDs have issues on UltraSparc. I presume that the right way to fix this is edit silo.conf, put it in CVS, and then regenerate the images and release them as 3.0_r0.1 later this week. For reference, here's the silo.conf that was used. =-=-=-=- partition=1 timeout=600 read-only message=/boot/debian.txt default=linux append=cdrom initrd=/dists/stable/main/disks-sparc/current/images-1.44/root.bin # Standard boot images image[sun4c,sun4d,sun4m]=/boot/sparc32.gz label=linux image[sun4u]=/boot/sparc64.gz label=linux # Rescue boots image[sun4c,sun4d,sun4m]=/boot/sparc32.gz label=rescue append=init=/bin/sh image[sun4u]=/boot/sparc64 label=rescue append=init=/bin/sh =-=-=-=- I've Cc:ed this to [EMAIL PROTECTED] (netgod from the attached mail) Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND ---BeginMessage--- Phil, netgod was installing fresh 3.0r0 CDs on an UltraSparc today and discovered an issue with the boot (it's barsted, essentially): infinity netgd : What happens? netgd infinity: if you hit enter it looks for /boot/sparc64.gz when the file is actually called /boot/sparc64 infinity netgd : Is this with the release version of the CD? netgd infinity: i can force it to boot by giving the right file, but then it screams about there being no root netgd infinity: 3.0r0 just jigdoed netgd the workaround is to type /boot/sparc64 initrd=/dists/stable/main/disks-sparc/current/images-1.44/root.bin at the SILO boot: prompt netgd yeah its just a typo in the silo.conf Is it too late to fix this stealthily without having to do a 3.0r0.1 special release for Sparc only or something? ... Adam -- 1024D/C6CEA0C9 C8B2 CB3E 3225 49BB 5ED2 0002 BE3C ED47 C6CE A0C9 ---End Message--- signature.asc Description: This is a digitally signed message part
debian-cd/potato_test --- .potato_test
Hi folks, It's been brought to my attention that the clever -H trick with rsync that should avoid everyone re-downloading 2.2r7 when they have 2.2r6 already, doesn't actually work. The reason being that rsync processes the directories in conventional order and 2 comes before p so it grabs the lot before noticing the hard links. Doh! To address this, I've moved the potato_test directory to .potato_test (note the dot on the front) on cdimage.debian.org. This will mean that you all get to download the images again if your not careful, so please move the potato_test directory at you end before your next rsync attempt. Access to that rsync area is password restricted at present, so you may find that you cannot grab them anyway --- this will not last, so please be patient. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: debian 2.2r7 iso images on cdimage ?
On Thu, 2002-07-18 at 08:34, Kaz Sasayama wrote: Philip Hands wrote: Assuming that the latest debian_cd still builds potato CDs, then they should be done in a few hours. Have you finished then? Yes. I don't see www.debian.org/CD/ updated for 2.2r7 yet, and now I wonder when I can start making official 2.2r7 CDs. If there are signed MD5SUMS files that match the images, they're official, if not they're not. If you look, you'll find the MD5SUMS are signed. http://cdimage.debian.org/jigdo-area/2.2_rev7/jigdo/ Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: cvs commit to debian-cd/tools/boot/potato by philh
On Tue, 2002-07-16 at 11:13, Debian Boot CVS Master wrote: Repository: debian-cd/tools/boot/potato who:philh time: Tue Jul 16 03:13:14 PDT 2002 Log Message: Oops, missed the log message out. Should have read: mkisofs's -B option's usage seems to have changed, so now needs a path from the current directory, rather than the root of the CD Fixing the path allowed the CDs to build, but I've no idea if they boot, so it might be good if someone would check that on sparc. Cheers, Phil. Files: changed:boot-sparc -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
3.0pre14.2
I just did another run, which should now have the Template-MD5Sums entry. Unfortunately, I forgot to bump the version number is the images up, so they claim to be 3.0p14. I've put them in a directory called 3.0pre14.2 If you're wondering what the 3.0pre14a directory is about, it's part of the previous pre14 run, but I had to split it from the 3.0pre14 directory because the CD creation run straddled an archive update, so the snapshot could not server the later images. If that makes no sense, don't worry about it too much. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: 3.0pre14.2
On Thu, 2002-07-04 at 17:46, Christian T. Steigies wrote: On Thu, Jul 04, 2002 at 05:34:46PM +0100, Philip Hands wrote: I just did another run, which should now have the Template-MD5Sums entry. I haven't seen any commit messages wrt the problem I reported for m68k, Er, oops, I forgot about that. ie the install files being hidden in dists/woody/main/disks-m68k. Do I have to fix that myself? Well, I'm just about to leave for the UKUUG Linux Developers Conference, so I'm not going to be able to do anything about it until Sunday, so go ahead. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Woody source ISO
On Tue, 2002-07-02 at 10:56, Christian Leber wrote: On Tue, Jul 02, 2002 at 11:42:19AM +0200, Beno?t SIBAUD wrote: ftp://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/woody/jigdo/ only propose i386 jigdo files. Are there source jigdo files somewhere (or source ISO)? Yes http://cdimage.debian.org/jigdo-area/ Just to save you a few moments: http://cdimage.debian.org/jigdo-area/3.0-pre14/jigdo/source/ Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Woody source ISO
On Tue, 2002-07-02 at 11:07, Glenn McGrath wrote: there are currently 7 main source and 1 non-US source. Given that you are doing this in Bordaux, you should ignore CD#1, and use CD#1_NONUS, so a more useful example might be: jigdo-lite http://cdimage.debian.org/jigdo-area/3.0-pre14/jigdo/source/woody-src-1_NONUS.jigdo You only need one of 1 or 1_NONUS, not both. CD#1 is just CD#1_NONUS, with all the non-US packages removed. You only need 7 CDs for a full set. Just thought I should make that clear. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: boot-m68k script on debian-cd
On Mon, 2002-07-01 at 11:16, Santiago Garcia Mantinan wrote: At least in the case of woody, dmesg and dmesg.readme appear to already be in the disks-m68k directory, so the wget lines should no longer be necessary in woody/boot-m68k. You can safely remove them. Following Raphael Hertzog's advice I'll change them into a cp of the boot floppies files. You can simply remove the lines, since they are already where they need to be after the mv ln -s in the script. I'm currently building CDs with this change: --- tools/boot/woody/boot-m68k 2002/03/25 10:03:53 1.4 +++ tools/boot/woody/boot-m68k 2002/07/01 12:28:20 -56,9 +56,9 ln -sf install.en.html doc/index.html # Extra tools not yet in boot floppies -wget -q sunsite.auc.dk:/pub/os/linux/680x0/tools/dmesg.readme -O dmesg.readme -wget -q sunsite.auc.dk:/pub/os/linux/680x0/tools/dmesg-O dmesg -chmod a+x dmesg +#wget -q sunsite.auc.dk:/pub/os/linux/680x0/tools/dmesg.readme -O dmesg.readme +#wget -q sunsite.auc.dk:/pub/os/linux/680x0/tools/dmesg-O dmesg +#chmod a+x dmesg # Amiboot needs to be executable chmod a+x amiga/amiboot-5.6 I suppose this indicates that I ought to commit a few of these tweaks. I'll do it today, or at least publish my diffs. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: About jigdo, pre12-14, etc
On Tue, 2002-07-02 at 00:07, Richard Atterer wrote: On Mon, Jul 01, 2002 at 02:48:09PM +, Mantas K. wrote: Also I found one problem - in jigdo files there are no md5sum section of template file. This is pretty bad, It's because I've told Phil not to upgrade his jigdo-file, because if he did, it would generate new-style .template files which are not supported by the current version of jigdo-easy2win. Er, oops --- I just upgraded it, because I forgot that little hint. Doh! Which version should I be using? Alternatively, is it trivial to make new style, back into old style (by just stripping out the md5sum, say?) in which case I could do that in publish_cds. Probably best to siply revert to an older version though. If you want Template-MD5Sum to appear in the official files, port jigdo-lite to Windows (preferred) or update jigdo-easy2win. I haven't got the time to do it and couldn't properly test it if I did. Btw, what are the changes between pre12 and pre14 ? 12-13: Always include Contents data in template files. 13-14: src - source in the template URLs for source CDs. That, and the fact that various archs. were slowly aproaching having CD1_NONUS less than 68000 bytes, which is now the case for all archs. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: jigdo 2.0-pre13 template url is wrong
On Sun, 2002-06-30 at 15:01, Glenn McGrath wrote: Inside woody-src-1.jigdo.unpacked the following url is specified. Template=http://cdimage.debian.org/jigdo-area/3.0-pre13/jigdo/src/woody-s rc-1.template This url is wrong, it causes jigdo-lite to fail if it tries to download the template file, i think it should be. Template=http://cdimage.debian.org/jigdo-area/3.0-pre13/jigdo/source/wood y-src-1.template Well spotted. That was an oversight in tools/publish_cds, which I've fixed, and re-run for 3.0-pre13 on the source CDs, so that should now be fixed too. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: JIGDO-EASY2WIN (newbie)
On Tue, 2002-06-25 at 23:12, Richard Atterer wrote: Hello, [Phil, I know I've nagged you about this before, but it's important: Please grep Contents out of the files passed to jigdo-file make-template, or we'll have a gazillion messages like this on woody release.] Your timing is impeccable. :-) /me goes of to restart debian-cd for the 4th time ... That problem should now be gone, and will be visible as soon as I manage make a version of this run that's worth publishing. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Debian CDs for woody release
On Sat, 2002-06-22 at 14:59, Raphael Hertzog wrote: Le Sat, Jun 22, 2002 at 02:23:50PM +0100, Philip Hands écrivait: Also, there have been the suggestions about adding a few newbie friendly packages to those included on the first couple of CDs, preferably CD#1, presumably by adding them to tasks (as mentioned a few times by Mantas Kriauciunas). I think this should be doable without to much greif, and would be a good thing, but I'm not sure who's responsibility it might be to decide to add things like that to tasks, or whatever. Is this something that simply going to be delayed till 3.0_rev1, or is there any opportunity to fix this before release? You're the one who builds the image, so it's up to you to modify the tasks file if you feel that it's required. I wasn't talking about the debian-cd tasks file, I was talking about the tasks as seen by tasksel. There seems little point forcing newbie friendly packages onto CD#1 if they are never going to install them because tasksel is not going to offer them. If there's some way of overriding the existing Tasks in packages, at CD build time, then I'm willing to give it a try, but I've had a look, and it seems that it's down to the boot-floppies and the original packagers, which means that we're well past the time when they could be changed for this release. Sorry for the delay in this reply --- annoying customers wanting me to do what they pay me for. I guess I get to pay the mortgage as a result, so shouldn't complain. ;-) However I'm sure that there's no perfect solution ... if you push more things on CD1, something else will go out and someone else will be unhappy. If people complain about the loss of penguineyes-gnome, and the like, I think I'll be able to live with that. There are a few such packages filling gaps on CD#1, so it should be possible to improve things a little. As I understand it, all the packages for all the tasks already take more than one CD so that I wonder how we can do better for CD1. Well, the gap at the end of CD#1 is too small to take any of the tasks that end up on CD#2, but that doesn't mean that CD#1 is actually full at that point, so it gets filled with random (popularity inspired?) packages after that AFAICT. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Debian CDs for woody release
On Wed, 2002-06-26 at 19:16, Anthony Towns wrote: Joey's been the main task hacker, afaik. Hi Joey, The suggestion from Mantas is here: http://lists.debian.org/debian-cd/2002/debian-cd-200206/msg00098.html The addition of the packages to task-desktop seems harmless to me, so we might as well IMO, unless you know a reason why this will break things. On the hardware detection front, I'm afraid I've never installed any of those packages --- do they do their work in the postinst? If so, would having them in a hardware-detection-task do the trick? I've not used aptitude either. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Debian CDs for woody release
On Sat, 2002-06-22 at 06:04, Anthony Towns wrote: Hi guys, What more do you want to do wrt CDs before release? Are you happy to release with the images you have now, on the machine you have now? The old machine is mostly OK now, but I'm still keen to get raff in on the act, and it shouldn't take too much effort, so I'll sort that out in the very near future if possible. On the CDs, there are a couple of architectures that I've not been having much luck with, but I've not had time to diagnose the reason why, so I'll have a look into it today before claiming there is an actual problem. Also, there have been the suggestions about adding a few newbie friendly packages to those included on the first couple of CDs, preferably CD#1, presumably by adding them to tasks (as mentioned a few times by Mantas Kriauciunas). I think this should be doable without to much greif, and would be a good thing, but I'm not sure who's responsibility it might be to decide to add things like that to tasks, or whatever. Is this something that simply going to be delayed till 3.0_rev1, or is there any opportunity to fix this before release? In a few days, the answer to both those questions is required to be yes, so if either of them are no at the moment, we need to do something about it. Understood. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: About harware detection and configuration tools in 1st CD
using the data produced by the popularity-contest package. Debian is for everybody, not just for beginners. If package A is more popular than package B, then A is more likely to be included in CD#1, even if it's less user-friendly than B. In my opinion this principle is basically right and should not be changed. Data, produced by popularity-contest is not reliable, because only few percent of debian users uses popularity-contest package. I know no simple users, that uses popularity-contest package and only few avanced users. And data, produced by popularity-contest are only about systems, connected to internet, but CD is most usefull to users, that have no internet connection. We need better system, to hear not only advanced users oppinion but other users too. Most simple users don't like debian, because they think, that there are not user-friendly configuration tools (they simply download 1 CD, try to install and find that they are rigth). But if we include some tools (packages which I mentioned before and some graphical configuration tools, like stormpkg (~100 kb), user-friendly graphical configuration tools, developed by Progeny: python-configlet (35kb), configlet-frontends (20kb), timezoneconf (30kb), localeconf (20kb) and maybe some more hardware detection packages: kudzu, sndconfig) people would see that debian is not so difficult to use. (see for example Progeny Debian - is very user-friendly for all - beginners and advanced users) Waiting for changes ;), Mantas Kriauciunas [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: Woody CD # 8 files are missing
On Tue, 2002-06-11 at 08:43, Chris Lawrence wrote: On Jun 10, Robert Fu wrote: Web page http://cdimage.debian.org/pre-release-jigdo/i386/ shows that files for Woody CD #8 are missing. It causes jigdo-easy2win failed everytime when I tried to download woody CD #8. Dumb question of the week: what worthwhile software is actually on Woody CD #8? Well, not much, since there are only 7 CDs. ;-) Admittedly, debian-cd has been a bit confused about what constitutes a non-US package of late, so that set has NON_US versions of CD#1 CD#7, so I suppose you could claim there were 9 CDs but then I'm not sure which one you'd be calling CD#8. What sort of circus freak would actually want a CD containing the most absolutely obscure software in Debian? A quick look, just at the As Bs on the CD reveals: Well, if you're a French or Portuguese speaker (or writer) then aspell-fr or aspell-pt might be handy. airsnort is a fun package if you want to break into WLAN networks. I'm sure bugzilla is important to a few people. The thing is that after the first 2 CDs the package order is effectively random. It's certainly not in order of decreasing usefulness. I've never quite understood the desire for completism that is associated with Debian CD sets. I mean, I'll gladly sell a CD containing 300 iterations of joe developer's vanity package and pocket the money, but the amateur psychologist in me is still curious why anyone would want to buy it. Do these people also collect daily newspapers, nail clippings, etc? If you want to compile a list of packages that are so useless that they don't deserve to be on the CDs, and then explain that fact the the maintainers of the packages you name, all I can say is good luck ;-) Also, you're forgetting that some people are not on the Internet AT ALL. If you want to install Debian in a school in some parts of the developing world, or if you want to install it on an IBM s390 (very few of which are plugged into the Internet BTW) then if it's not on the CDs, it won't be installed. Then again, maybe these people have been burned in the past by $SHOVELWARE_DISTRO_OF_THE_WEEK's demotion of the GNU C Compiler to the second CD in $SHOVELWARE[*]. Chris, hopefully not offending any circus freaks in the audience. [*] Any similarity between the names SHOVELWARE and Mandrake is strictly coincidental. grin Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: CD release announcement
On Fri, 2002-05-31 at 04:00, Mattias Wadenstein wrote: Where will the jigdo files turn up? open is a bit closer, but I get good rates to raff too. Just wondering if I should have that cron job that mirrors jigdo-area point at cdimage or open. I'll be building the images on open, but the plan is to point the public at raff, and make sure that's mirrored ASAP after the images are on open. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 2002-05-30 at 10:08, Santiago Vila wrote: One comment: In pre6-pre7-package.diff.txt I see: -Non-US:pool/non-US/main/e/erlang/erlang_8.0-4_i386.deb -Non-US:pool/non-US/main/e/erlang-slang/erlang-slang_1.0-3_i386.deb -Non-US:pool/non-US/main/o/openh323/libopenh323-dbg_1.7.4-6_i386.deb -Non-US:pool/non-US/main/p/python-popy/python1.5-popy_2.0.8-2_i386.deb -Non-US:pool/non-US/main/p/python-popy/python2.2-popy_2.0.8-2_i386.deb Doh! I noticed that, but the implications didn't occur to me. which seems to indicate that some of the bigger packages in CD #1 were there just because we wanted to include the whole of non-US in the first CD, not because of their popularity. If we accept that a first non-US CD does not necessarily have to contain the whole of non-US, we could change the way of generating the CDs from Including most of non-US in CD#1, excluding big packages to Including packages from non-US in CD#1 according to their popularity, as we already do for main packages. But then we need a 2_NONUS, or perhaps we just arrange for all packages to be in popularity order, and have as many non-US CDs as it happens to take depending where the packages land. I think that's a big enough change to leave for a later release, unless someone else is confident that they can change this without breaking things. I think my next cut will allow erlang and xspecs back in CD1, to see what that gives us. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
