Re: Fwd: Re: Bug#474651: debootstrap: W: Failure trying to run: chroot /sid
reopen 474651 thanks On Fri, Apr 18, 2008 at 02:06:48PM +0200, Peter Walser wrote: It is reproducable and it's just whith: $ fakeroot -s fakechroot.save \ fakechroot /usr/sbin/debootstrap --variant=fakechroot \ sid /sid http://ftp.ch.debian.org/debian/ Turns out it's reproducible with ] fakeroot /usr/sbin/debootstrap --foreign sid sid $MIRROR ] echo $? or ] sudo /usr/sbin/debootstrap --foreign sid sid $MIRROR ] echo $? or ] sudo /usr/sbin/debootstrap sid sid $MIRROR too; the problem being that libc6 and binutils both reference /usr/lib64, but libc6 thinks it should be a symlink and binutils thinks it should be a directory containing a file. After tar unpacks a directory and file from binutils; it complains when it tries unpacking the symlink from libc6. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatic processing of d-i byhand uploads
On Sun, Oct 28, 2007 at 01:49:32AM -0400, Joey Hess wrote: Anthony Towns wrote: To get it working for d-i uploads, I need a very reliable script that will be invoked as: Well, I stopped when I discovered the tar on ries is still apparently vulnerable to #439335. I don't feel it's possible to make a very reliable script with an insecure tar.. (Does dak ever unpack other tarballs? Just curious, I swear... ;-) Not using tar directly except when specifically distrusting the filenames in the tar file... Can't you just test for any absolute file names and error out? I was more worried about having a symlink x-/etc, followed by an x/passwd file or similar, which is apparently caught, but... The python tarfile module (or similar) might be a better bet. Cheers, aj signature.asc Description: Digital signature
Re: Automatic processing of d-i byhand uploads
On Sat, Oct 27, 2007 at 08:51:38AM -0200, Otavio Salvador wrote: What's required, from d-i uploads side, to it be used? anything special or just a normal upload? Nothing beyond what's already done -- have the section be raw-installer have the filename include the source version and architecture, and have it be a standard name/extension and standardised contents. Cheers, aj signature.asc Description: Digital signature
Automatic processing of d-i byhand uploads
Hey *, I spoke to Colin at debconf about getting automatic processing of d-i byhand uploads happening -- rather than needing an ftpmaster to unpack the installer-* stuff directly. The dak-side implementation is pretty much done now, and works for tags uploads (filling out the Tag: fields in Packages files) and will hopefully be working for debian-maintainers keyring uploads soon. To get it working for d-i uploads, I need a very reliable script that will be invoked as: $SCRIPT debian-installer-images_20070308_mips.tar.gz 20070308 mips where the .tar.gz is in the current directory. It should cope as gracefully as possible with any possible problems with the tarball, and dealing with the contents of the ftp site. I thought Colin had given me a script like that that had been in use in Ubuntu, but can't find any sign of it now. Cheers, aj signature.asc Description: Digital signature
Re: This is getting ridiculous ...
On Sun, Jun 18, 2006 at 02:48:59AM +0200, Sven Luther wrote: [...] [The DPL] clearly mentioned that the only way to solve this was going through the TC (of which as i was told 3 members are already against me even without considering the issues) or a GR. The only other *possible* ways you can overrule the d-i team's decision to treat your March mail [0] as a resignation from the d-i team, or to overrule their decision to decline your requests to rejoin the team are through the tech ctte or a GR. I don't believe either of those will be remotely successful. I am worth having commit access, even Frans, the DPL and others of the d-i team said so, on the technical side at least. No, that is not the case. Your contributions are worth being included in d-i; but that alone doesn't warrant giving you commit access. Frankly, I doubt he's going to be able to do that when he annoys the hell out of an insane number of people. And what other choice do i have ? Accept that you've lost this round and move on with your life. Cheers, aj [0] http://lists.debian.org/debian-boot/2006/03/msg01075.html signature.asc Description: Digital signature
Re: This is getting ridiculous ...
On Fri, Jun 16, 2006 at 11:24:34AM +0200, Sven Luther wrote: There is *NO* technical reason which warrant his action, and the only reason he does it is to humiliate and punish me. You're the only one here who thinks that's a punishment, let alone humiliating. If you would like to setup your own subversion repository and humiliate or punish Frans by not giving him access to it, you're welcome to do so. Personally, I don't think Frans would care about that because I don't think he would see it as punishment or humiliation; but then, I don't think you should see not having access to the d-i subversion that way either. I don't have access to it either, and I don't think that makes me worse as a person. The only time someone's been had their commit access revoked from a project before that I can think of was Daniel Stone when he uploaded X 4.3 to unstable. In the end, it's just the svn admin's call who gets access and who doesn't, and there really isn't anything more to it than that. And, how long will it last ? how long will frans reject any effort i make, and spring about the most minor of comments ? However much effort you've put in, the only result has been to continuously demand that Frans give you access again, or that someone else make Frans give you access. No, i don't need to regain Frans's thrust, Please, the word is trust. No h. Or use the word confidence, it's near enough in meaning, and similar in French iirc. And while you're certainly correct that you'll never regain his trust if you keep acting the way you have been, it's entirely your choice to act that way, and hence no one's fault but your own. And the longer this issue lingers unsolved, the worse it becomes. The issue is already resolved, you're just refusing to accept it. You would not accept this, there is enough people throwing insults at me on irc, or engaging in random stuborn flamewars in debian, that there is no right for you or anyone to suggest that i should be submitted to it. In February and March, I did the work that was blocking amd64 getting into main -- that ended up including restructuring the way mirrors worked, getting apt updated to work, making some patches to dak, and had to be followed up by some a fair bit of time helping the release managers nudge amd64 into testing. Had I been doing that my way, I probably would have ignored the mirror changes, left the updated apt for ages, and pushed amd64 into testing in a much quicker (and more broken) way -- but that's not the way we're setup: James and Ryan are also ftpmasters, so their views on mirroring and how the ftp site is setup have to be taken into account, and Steve and Andy's views on what happens to etch likewise trump mine. So even though what they wanted was more work, and not really terribly exciting for me, that's what ended up happening: just as I want them to listen to my concerns when they do things, I make sure I listen to their concerns when they do things. And as far as insults on IRC, I've had a frontpage slashdot story the other week with anonymous commenters calling me a control freak and similar (and getting modded up to +5, Interesting for it) and another article on distrowatch calling me hot headed. So, please don't imagine it's pitchforks for you, and roses and bunnies for the rest of us. When you say that other people wouldn't submit to what you've been through, you're simply wrong. That's not to say that you have to put up with it -- you're a volunteer, so if you don't want to put up with it, you can go elsewhere any time you like, which might mean working on d-i in a different repository, working on a different part of Debian, working on a Debian derivative instead of Debian, or ending your work on Debian entirely. And while you might not appreciate it, we will be sad to see you go, but it's still completely your choice. What isn't your choice, though, is whether anyone else in the project wants to work with you. If they don't, they're volunteers too, and they don't have to. If you aren't willing to accept that, you will need to find some way to deal with the consequences. Maybe. That said, in real life, if someone would have an authority over me like the one i mention, [...] Frans has no authority over you; simply authority over the d-i subversion repository. Cheers, aj signature.asc Description: Digital signature
Re: This is getting ridiculous ...
On Fri, Jun 16, 2006 at 04:50:50PM +0200, cobaco (aka Bart Cornelis) wrote: On Friday 16 June 2006 15:33, Anthony Towns wrote: On Fri, Jun 16, 2006 at 11:24:34AM +0200, Sven Luther wrote: There is *NO* technical reason which warrant his action, and the only reason he does it is to humiliate and punish me. You're the only one here who thinks that's a punishment, He's not, furthermore everyday use of the english language clearly supports that vision: [...] Sven lossed his commit rights because because of his offences, I'd say that fits 2 above nicely, no? Then I have to ask you to please stop thinking in that manner. Punishment and humiliation are not what this is about, and imagining that it is does a disservice to both the d-i team and Sven. The reason Sven's access was removed and the reason it's not being reinstated is that Sven is unable and unwilling to work with Frans, and Frans is likewise unwilling to work with Sven. Assigning blame for that isn't a useful activity, and is likely harmful since it will only make one or both of Sven and Frans less willing to work with the other. let alone humiliating. that's subjective, clearly he experiences it as humiliating. that may or may not be how you would feel in his shoes (for whatever instatiation of you). Since we're quoting dictionary definitions: ]To reduce to a lower position in one's own eyes, or in the ]eyes of others; to cause a loss of pride or dignity; to ]humble; to mortify. As far as everyone else is concerned, this is a disagreement between Sven and Frans; and if Frans isn't willing to pretend that there's no problem and give Sven access to subversion, that may well be Sven's problem, or it might be Frans', or it might just be the way things are. Anyone who does think losing access to a repository puts you in a lower position is mistaken, and that includes Sven. The feelings on both sides simply are, the mediator refusing to acknowledge the feelings of one of the parties is _not_ helpfull. (and that's probably the basis for Sven saying that you weren't mediating) No, the basis for Sven saying I wasn't mediating is that I didn't give him what he wanted -- that is, I didn't insist Frans reinstate his access. Sven's been very consistent on being only willing to accept that as the final outcome, and repeatedly suggested alternative compromises in order to achieve that. Unfortunately, that's simply not a plausible outcome. I hope Sven will accept that at some point, but I haven't seen any evidence of it to this point. What purpose is being served by making Sven jumpt through hoops when making technical contributions to D-I? How does it help fix the social issues between Sven and Frans in any way? Reinstating subversion access doesn't fix the social issues either. Worse it brings them to the fore by requiring Frans and Sven to work closely together on an ongoing basis. Net effect at this point seems to be: - extra work for those playing middle man for Sven's commits and Sven himself They're happy to do this. - bad feelings and frustration on Sven's part (neither of which is likely to help improve communications) - lots of flames on the issue everywhere, and resulting frustration all around And both of those are entirely within Sven's control. The positive that you missed is Frans, and the rest of the d-i team, don't have to deal with Sven being part of their team, which means they can get on with their work without having to worry extensively about Sven throwing a temper tantrum when his patches stop working, trying to overrule the d-i lead by going to the release managers, or whatever else. Meanwhile I have seen Sven make an honest (though imperfect) effort to improve the way he communicates. Again, no matter how much effort he's put in, it hasn't actually achieved anything. Frankly at this point I don't see how refusing to give Sven back commit rights (which he never abused AFAIK) is helping anything. Giving back his commit rights at this point would imply that the best way to deal with someone acting in a way you disagree with is to call them fascists, hypocrites, abuse them on IRC, and start thread after thread on how you've been unfairly mistreated on multiple lists, until everyone gets so fed up with you they just do what you want. Apperently you don't share this opinion, could you as mediator explain what gains you see in refusing Sven commit rights still? Cause standing here on the peanut gallery I'm not seeing any. Commit rights is a stand in for being part of the d-i team; Sven continues to demonstrate he can't work productively with the d-i team, so certainly should not be a member of that team. Any mediation whatsoever needs to accept that that's the case currently, and either work to change it, or find some way of making it irrelevant. Unfortunately Sven is so far unwilling to accept that, so there's simply no possibility of any
[EMAIL PROTECTED]: debian-installer, powerpc issues]
For reference, here's the mail I sent to Sven regarding his complaints on the way d-i has been handled. I think it's been referred to indirectly enough that nothing's served by not having it available for public review. - Forwarded message from Anthony Towns aj@azure.humbug.org.au - From: Anthony Towns aj@azure.humbug.org.au Subject: debian-installer, powerpc issues Date: Wed, 10 May 2006 16:38:26 +1000 To: Sven Luther [EMAIL PROTECTED] Cc: Steve McIntyre [EMAIL PROTECTED], [EMAIL PROTECTED] Organisation: Lacking Hi Sven, On 27th April, just under two weeks ago, you wrote regarding your concerns about debian-installer's support of powerpc, and related organisational and personality issues. Having spoken to you, Frans and Colin, and watched your interaction on the mailing lists and IRC since, I don't think having you rejoin the debian-installer team at this point will be an effective way for either yourself or the current members of that team to work, and as such, I won't be asking Frans or the other d-i hackers to reinstate your commit access. That said, Frans was very quick to acknowledge that finding some way for you to keep working with the d-i team is important and a high priority, and I think it's clear that the powerpc architecture benefits markedly from your contributions. My understanding is that your focus is primarily on ensuring the powerpc port is working effectively rather than ongoing feature development in broader areas of d-i and other projects, and thus that your contributions tend to be in the form of immediate fixes for small problems, where it's valuable to be able to push the fix straight out to users. Since you are unable to do that via directly committing your patches, I'm thus going to recommend that you make use of the regular NMU procedure instead to get those fixes out, with the following notes: 1. At the same time as you upload an NMU, you file a bug completely documenting the problem you're fixing, why it occurs, how it can be reproduced, and what your fix is, including the patch. 2. When preparing the NMU, you make minimal changes -- that is you don't change any design decisions the d-i team have made, and don't do anything that causes breakage on other architectures, or on systems that work in other ways. 3. You make best efforts to keep your changes compatible with ongoing d-i development -- ideally providing patches that apply both to the current debs in the archive and current CVS, should they differ. 4. After uploading your NMU, you monitor any problems it may cause and assist in fixing them, and do your best to assist with any queries the d-i team have in regards to integrating your fix into CVS, which may involve generalising it, or other considerations you haven't taken into account. Roughly concurrent with this mail, I'll be contacting Frans and the d-i team in regards to this, recommending that they take any NMUs you do seriously and do their best to ensure that they don't follow up with a maintainer upload that doesn't also include your fixes. Frans has indicated both he and Colin will be available to apply your patches in a timely manner, and I hope he's correct in that estimation. Should you both be successful at following that procedure, I think it will provide a reasonably effective way for you to work together to maintain the powerpc port, and I hope that it might form the basis of a better working relationship in future. On the other hand, if either or both of you fail at that procedure, then the BTS should provide a documented record of what was going on, at which point we can review this issue and institute other procedures as we see fit. If your changes are getting reverted by maintainer uploads, that might involve overriding the d-i team's preference to not have you as a member with commit rights; if you're doing NMUs without providing explanations or helping the d-i team integrate your fixes with the latest development, that may involve further limiting your contributions. I don't believe that asking you to moderate either your language or the number of posts you make in a day is an essential part of resolving this issue, so haven't mentioned it above. I do think that your method of arguing for your beliefs works against you, though; and if Steve's willing, I'd suggest you continue to talk to him about how best to make your point the next few times you need too -- getting him to comment on your mails before you send them, eg, or getting advice on how much more you need to say in an ongoing thread. If you don't feel this is an acceptable way forward, you can ask the technical committee for advice, or to overrule the d-i team's decision to not give you commit access, or you can propose a general resolution for either of these issues. I think we will also need to review who the powerpc port maintainers actually are fairly soon; mostly
Re: This is getting ridiculous ...
On Thu, Jun 15, 2006 at 07:38:00PM +0200, Sven Luther wrote: I think that the situation with my commit access to the d-i svn repo is getting burdersome and over ridiculous. Sven, you've already ignored my recommendation on how to deal with this, and the question remains before the technical committee, from your request. If you'd like to remove the packages you're listed as an Uploader: for from d-i svn so that you can maintain them yourself, I'm happy to support you in that. But I can't support your continued pressuring of Frans and the other members of the d-i team to reinstate your svn access. You seem to have formed the impression that people with subversion access are better than people without, or at least are seen to be that way. That's not the case. 19:08 svenl fjp: would be easier if you restored svn commit. 19:08 * fjp is not going to discuss that. 19:09 svenl fjp: damn, i forgot the smiley, let's try it again. 19:09 svenl fjp: would be easier if you restored svn commit. :) 19:09 svenl (was not going to discuss it, but to make a friendly joke). 19:10 svenl fjp: i mean, i am seriously bitter about this, and previous incarnation of that discussions where indeed rant. 19:12 * svenl is hoping to wear fjp down by pointing out the exceeding ridiculness of the whole issue, though, so i am no more going to rant about it :) 19:13 svenl fjp: so, you want to put me in a bad-mood again, and that we restart a dispute and flamewar ? FWIW, i am seriously bitter about this, hoping to wear [you] down, and restart a dispute and flamewar != friendly joke. Cheers, aj signature.asc Description: Digital signature
Re: Issues regarding powerpc and Sven
Frans and Colin dropped from Cc's, -boot and -powerpc Bcc'ed only; please avoid crossposting. On Wed, May 10, 2006 at 11:14:39AM +0200, Sven Luther wrote: On Wed, May 10, 2006 at 04:38:31PM +1000, Anthony Towns wrote: As I suspect you're all already aware, on 27th April, Sven Luther asked me to review the situation with d-i and powerpc as a result of finding his commit access to the d-i repository had been removed. Having spent some time since then seeing what's been going on, I've concluded that removing Sven's commit access was a reasonable course of action, and won't be asking that you accept Sven's request to have it reinstated. Anthony, d-i team. I would very much like to get the detail of the reasoning behind how you concluded that it was a reasonable course of action, The d-i team were acting under the belief that you no longer wished to work on d-i after a number of conflicts in the past [0]; they then sought to find someone else to work on powerpc issues for d-i on the -powerpc list [1], indicating they need people at all levels to work on it (from testing builds to arch-specific development), and you not only saw that call for help, but participated in the thread [2]. About a month after that got around to removing your commit access. That you now indicate that your intention had been to resign as *lead* powerpc porter for d-i doesn't really change matters; you weren't clear that that was your intention originally, you didn't clarify your intention when Frans stated the d-i team's understanding, and for various reasons your involvement in d-i over the month between the mails above and your noticing your commit access was also removed. I don't think there's anything at all unreasonable in removing commit access for someone who voluntarily resigns from a project, especially when they go on to make it difficult to recruit new members to replace them. That means it becomes a question of whether you joining the d-i team at this point actually makes sense on its own merits, rather than merely as a reversion of a previous bad decision. Since both you and Frans have made it very clear you're uncomfortable working closely with each other at this point, forcing you together seems entirely inappropriate, and against explicilty expressed desires from both of you. [0] Message-ID: [EMAIL PROTECTED] I hereby officially announce that i won't continue to do the ungratefull job of powerpc d-i porting, i hear the d-i team has plenty of folk to take my place, so they should fix this. [1] Message-id: [EMAIL PROTECTED] Sven Luther has recently announced [1] that he will no longer work on PowerPC support in Debian Installer. [2] Message-ID: [EMAIL PROTECTED] Well, that is what i see right now, some of these issues are open since a couple of weeks now, if not more, and i saw nobody jump in to fix then, even after i was scheduled for expulsion, so i hope that frans calls will give more results, altough seeing as it is a tedious process with little respect from the d-i team ... Further, i want to point out that i am the original author of both the nobootloader and prep-installler .udeb packages, and was also early involved in partman-prep (which is currently broken) package from Cajus Pollmeyer. Note that your technical abilities are not in any question. These tree packages are in the debian-installer svn repo, and removing my commit access means additional hurdle to me working on them, It means that if you wish to continue maintaining them, you need to do so independently of the Debian Install System Team, which is listed as the current maintainer, and of which you are no longer a member. If you wish to consult with your co-maintainers for those packages (Matt Kraai and Stephen R Marenka for nobootloader, and Cajus Pollmeier for partman-prep) and setup a new source control repository, that's entirely appropriate. and i think it would be more logical if this confirms itself, that those packages be removed from the d-i svn repo and hosted somewhere else more neutral. You're no longer a member of the d-i team; if they wish to keep those packages' source in their subversion repository, it doesn't matter to you at all. If they wish to maintain a fork compared to your packages, that's fine too. If other members of the d-i team wish to maintain it in your stead, they probably will be expected to justify that change as a package hijack, depending on what your co-maintainers think of the situation. [...] and in any case, i have seen no evidence that this removal of my svn commit access was expected to have any technical effect, only a social one, to get ride of me and make sure i would not be able to interact with d-i in the future. You have been asked to interact with the d-i team a number of times in a number of ways; you have consistently refused to do so by any means other than direct commit access to their subversion repository
Issues regarding powerpc and Sven
Hey all, As I suspect you're all already aware, on 27th April, Sven Luther asked me to review the situation with d-i and powerpc as a result of finding his commit access to the d-i repository had been removed. Having spent some time since then seeing what's been going on, I've concluded that removing Sven's commit access was a reasonable course of action, and won't be asking that you accept Sven's request to have it reinstated. I have, however, recommended that Sven make use of his ability to NMU d-i packages should they be broken on powerpc, with the following caveats: 1. At the same time as you upload an NMU, you file a bug completely documenting the problem you're fixing, why it occurs, how it can be reproduced, and what your fix is, including the patch. 2. When preparing the NMU, you make minimal changes -- that is you don't change any design decisions the d-i team have made, and don't do anything that causes breakage on other architectures, or on systems that work in other ways. 3. You make best efforts to keep your changes compatible with ongoing d-i development -- ideally providing patches that apply both to the current debs in the archive and current CVS, should they differ. 4. After uploading your NMU, you monitor any problems it may cause and assist in fixing them, and do your best to assist with any queries the d-i team have in regards to integrating your fix into CVS, which may involve generalising it, or other considerations you haven't taken into account. Frans has already indicated he and Colin should be able to commit any patches Sven sends along in a reasonably timely fashion; and I'm hopeful that the structured cooperation via NMUs and the BTS should provide some practice so that you guys can work with Sven with a little less tension. Particularly initially that probably means you'll need to be careful to make sure you notice NMUs and work with Sven to make sure the bug reports contain enough information to improve any patches that need improving. If you find you still need help making this work after a couple of weeks, please get in contact with me or Steve McIntyre so we can work through this a bit more. I expect we'll shortly need to look seriously into getting a few more people actively working on maintaining the powerpc port as well; at the moment we seem to be relying on Sven to do everything, and that's not really ideal. Cheers, aj -- Anthony Towns, Debian Project Leader signature.asc Description: Digital signature
Re: Issues regarding powerpc and Sven
On Wed, May 10, 2006 at 12:25:32PM +0200, Xavier Oswald wrote: In any case working with less tension should be done. But do you think, it's interesting for Sven to work in this way. What's interesting for Sven isn't really a consideration, what's reasonable and efficient is. Once this has been tried for some time, I'll be happy to reconsider whether it's effective; if it's going to be dismissed out of hand, though, that indicates a lack of good faith. He should wait until Frans or someone else to see his work in the svn and with his knowledge about powerpc, I think lots of time will be lost and the work will be delay. There is no delay -- we distribute software to users via packages and images produced from those packages, not svn repositories; and Sven was explicitly requested to upload packages directly and immediately, with the given provisos to ensure he doesn't block other people's ongoing work. I expect we'll shortly need to look seriously into getting a few more people actively working on maintaining the powerpc port as well; at the moment we seem to be relying on Sven to do everything, and that's not really ideal. Sure but looking after such of person is not easy and this person should have lots of exeperience with powerpc, d-i and debian. No, there should not be a this person in that role -- maintaining an architecture is a job for multiple people working together. Expecting one person to do all of that is not reasonable, whether it's Sven or anyone else. We have Sven, why not trying to do forget what append before and try to work together and not pointing on people everytimes. Forgetting what happened is a good way to ensure it happens again, just to remind you. Cheers, aj signature.asc Description: Digital signature
Bug#248399: dhcp-found dns servers not placed in resolv.conf after default install
On Tue, May 11, 2004 at 11:46:48AM +0100, Colin Watson wrote: I don't know why the installer is installing dhcp-client rather than dhcp3-client. I'll reassign this to debian-installer. That's easy: dhcp3-client didn't used to exist. (If dhcp3-client is to replace dhcp-client, why isn't it just being called dhcp-client, with dhcp2-client kept around if it's really needed?) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ Don't assume I speak for anyone but myself. GPG signed mail preferred. ``Like the ski resort of girls looking for husbands and husbands looking for girls, the situation is not as symmetrical as it might seem.'' signature.asc Description: Digital signature
Re: Removing boot loaders from debootstrap?
On Tue, Apr 06, 2004 at 02:12:03PM +0100, Martin Michlmayr wrote: debootstrap installs delo (the DECstation boot loader) on all mipsel systems, even though only DECstations need it. I seem to recall a discussion about removing all boot loaders from debootstrap since it's d-i's task to install them. What was the conclusion of this discussion? Whatever d-i needs is basically fine. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: beta 2 plans
On Fri, Jan 02, 2004 at 03:59:22PM -0500, Joey Hess wrote: Almost but not quite what I intend. I want to do this one architecture at a time, starting with i386. So testing/main/debian-installer will look like this: binary-alpha - ../../../sid/main/debian-installer/binary-alpha binary-arm - ../../../sid/main/debian-installer/binary-arm That's quite plausible, but I can't imagine it being done with symlinks. It's easy to update (u)debs in testing to unstable on a per-arch basis. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp0.pgp Description: PGP signature
Re: beta 2 plans
On Wed, Dec 31, 2003 at 11:35:16PM -0500, Joey Hess wrote: So my new plan is, as soon as i386 is releasable, to work to migrate the current set of debian-installer udebs and images to testing. AJ has agreed to do this without the usual testing delay stuff, all in one lump. Please make sure I get a couple of days advance warning when you're ready to do this :) At the moment, testing's d-i is a symlink to unstable's. What will happen when Joey gives the word is that symlink will be replaced by a proper directory which will mirror the current contents of unstable's d-i, but will not be auotmatically updated in any way - IOW, it'll be frozen, again until Joey gives the word. Meanwhile, updates to unstable d-i will continue working quite happily, and updates to the regular testing debs (not udebs) will also continue. Basically, we're looking at something like: latest udeb latest udeb in testing in unstable 2004-01-01 2004-01-01 2004-01-02 2004-01-02 ... 2004-01-08 2004-01-08 Joey gives the word to start the freeze 2004-01-08 2004-01-09 unstable keeps updating w/ new uploads 2004-01-08 2004-01-10 testing doesn't ... 2004-01-08 2004-01-20 2004-01-21 2004-01-21 Joey says end the freeze, testing udebs 2004-01-22 2004-01-22 match unstable udebs again. freeze again 2004-01-22 2004-01-23 as necessary (dates have no relationship to reality) We'll need to fix up d-i to use a process similar to the regular archive's for updating testing at least a week or two before release, but I'm inclined to think doing an iterative freeze process for d-i is probably best and easiest for the moment. Hope that's clear to everyone. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp0.pgp Description: PGP signature
Re: fixing the base-installer progress bars
On Wed, Dec 31, 2003 at 11:23:31AM -0500, Joey Hess wrote: Appendix A: The debootstrap --debian-installer progress stream. The stream consists of a number of lines. Each line is of the form: CODE: arg1 [arg2 .. argn] Format is: x: tag xA: argument... xF: format string where x is E, W or I for error, warning or info. Each x: line is followed by zero-or-more xA: lines (argument -- ie, info line the particular package name to fill in the variables in a message), which are then followed followed by exactly one xF: line (format -- what debootstrap would display, but that you can normally ignore because you've got debconf templates to use instead). The tag is a simple, one word, single token identifier you can use to work out the purpose of the message - it should be possible to index the debconf templates based on the tag easily. Each tag will always be followed by a given number of xA: lines. If you have: I: nextnum IA: one IA: two IF: the number after %s is %s then you're being told to inform the user that the number after one is two. The P codes (for progress) are similar, except for the extra parameters (indicating the progress), and... The codes are: P (progress) arg3 is a unique identifier for the progress item. It may be omitted sometimes. It's omitted when it's using wget -- ie, there's already been a P: line with the appropriate identifier, and it's just the progress that needs updating. In that case, there are no PA or PF lines either. I (info) arg1 is an identifier for the information message in question Generally followed by an IA and IF. Should be always, afaik. WF (warning format) args combine to form a format string. The info arguments are then substituted in turn into the %s tokens in the string to form the warning message. Note that the formats are just there for convenience; d-i is expected not to end up using any of them, afaik. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp0.pgp Description: PGP signature
Re: Bug#221907: no need to always install pcmcia-cs for d-i
On Mon, Dec 22, 2003 at 12:30:24PM +0100, Gaudenz Steinlin wrote: Am Mon, den 22.12.2003 schrieb Joey Hess um 07:59: Anthony Towns wrote: Yes, that is the answer I want. How about pcmcia-cs? Same story, hw-detect apt-installs it if it sees that the machine has a pcmcia bus, and later kernel-installer takes care of installing the matching kernel-pcmcia-modules package for i386. Please take into account that debian-cd uses debootstrap to find out what has to be on the netinst cd's. Although these packages should not be installed by debootstrap they should not be removed from these cds! Hrm. I suspect what I'll do is setup --debian-installer to ignore those packages, which should keep things working okay in the short term. In the long term, though, I'd like to switch so that debootstrap doesn't know about these optional packages (except perhaps for the --boot-floppies argument for a little while longer), so debian-cd (and the basedebs generating code) is going to need some other way of working out which other packages are useful to have around. Who's going to take responsibility for this? Overrides on the ftp site might work okay, with the caveat that they have to be the same on all architectures. Something like: Package: pcmcia-cs Version: blah Base: optional could work, eg. That would require debian-cd to select the debs that debootstrap says is needed _as well as_ the debs listed as Base: optional in the Packages file. It'd be possible to add a --all-base or --debian-cd argument to debootstrap for debian-cd to use to list all these packages, which might be okay. The alternative seems to be for d-i to tell debian-cd which debs it needs to have available directly somehow. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp0.pgp Description: PGP signature
Re: Bug#221907: no need to always install pcmcia-cs for d-i
On Mon, Dec 22, 2003 at 03:12:06PM +0900, Kenshi Muto wrote: On Mon, Dec 22, 2003 at 08:54:13AM +0900, Kenshi Muto wrote: - `pcmcia-cs' is cared by debian-installer system. No need to install this by debootstrap. I'm not familiar with other architecture, but boot loader such as lilo, aboot, and silo should be installed by debian-installer rather than debootstrap. Can you please give me a brief run down on how you've got this working? For example, current grub-installer's postinst installs grub package (run 'apt-install grub' internally). (Is this answer you want? I'm afraid I misunderstood your request) Yes, that is the answer I want. How about pcmcia-cs? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp0.pgp Description: PGP signature
Re: use of release names in d-i
On Wed, Dec 03, 2003 at 10:24:54PM -0500, Joey Hess wrote:
(A nice UI might be something like:
cando=
for x in oldstable stable testing unstable; do
cn=$(wget -q -O - $MIRROR/dists/$x/Release | sed -n 's/^Codename: //p')
if [ $cn -a -e /usr/lib/debootstrap/scripts/$cn ]; then
cando=$cando $x=$cn
fi
done
echo I can try to install: $cando
echo Which one do you want?
but that's only possible if d-i has the Release files itself.)
I think some of our users do not like to have to choose between code
names. Anyway, d-i will not support oldstable,
When sarge becomes oldstable, it will, though. Instead of the last
couple of lines, consider instead:
if [ $cando = ]; then
echo Sorry, can't install anything.
else
codename=
while [ $codename = ]; do
echo -n I can try to install: ; echo $cando | sed 's/=[^ ]*//g'
echo -n Which one do you want?
read suitename
for x in $cando; do
if [ ${x%=*} = $suitename ]; then
codename=${x#*=}
fi
done
done
echo debootstrap $codename /target ...
fi
The user just has to talk about suite names, and d-i can automatically
select the right name for whichever suites can actually be installed
(testing currently, stable when sarge is released, oldstable when sarge+1
is released). More interestingly, d-i can indicate which suites are
actually able to be installed, no matter what happens to the archive
-- if there are major changes that drop the Release files, then it'll
accurately say Sorry, can't install anything and the user won't waste
his time trying to use an old installer against the archive.
Of course I will put some codename lookup code in d-i if you insist, but
there are many things I dislike about the idea:
- We will then have one more program that has to be able to parse
release files. If you posit they could change format later, then
we're creating more work for ourselves later on.
d-i needs to change each release anyway; debootstrap does too, but its
API doesn't.
- Similarly, this will be one more program that has to validate
release files. It would perhaps be nice if debootstrap became able
to check their signatures along with their md5sums. It would be
annoying to have to duplicate that code into d-i too, and this is an
area that seems more likely to change than Release file format.
I'm more inclined towards having a pre-verified Release file get passed
to debootstrap than to have debootstrap use gpg, really. Establishing a
trust chain is Hard, and isn't something you can do well without a UI -
which debootstrap doesn't have.
- d-i will also have to add code to handle every URI type that
debootstrap does, including new ones if they are added to
debootstrap. This is also an area that seems likely to see future
change.
Erm, d-i calls debootstrap; it knows exactly which URI types it's going to
use to invoke debootstrap.
- While my patched debootstrap does download the Release file twice,
it should be much easier to optimise that to one download than if
the first download happens in a separate program in d-i.
As above -- all that means is that d-i has to pass the Release file
it downloaded to debootstrap. It can do that now by dumping it in
$TARGET/var/lib/apt/lists, but if it's actually going to be used, we'll
set up a simpler way. Anyway, downloading a Release file twice isn't a
big deal.
- I admit it: I have a time or two accidentially given debootstrap a
symbolic release name and been suprised to see it fail. Putting the
code in debootstrap makes it that little bit easier to use.
That's a valid point; nevertheless, I'd still much rather see d-i do this
itself /first/, 'til we can definitely see that it's workable and a win.
It feels like we'd have to become more and more intimately connected
with debootstrap, while at the same time replicating more and more of
what debootstrap does, if this were done in d-i and not in debootstrap.
Another option would be to provide a separate debootstrap_dload script
that can get a Release file, or Packages file, or .deb, or URL for you in
the same way debootstrap does. But again, I don't want to go increasing
debootstrap's API without being sure it actually is a good idea.
And I do think there are other wins in having d-i access the Release
files itself.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we can.
http://conf.linux.org.au/ -- Jan 12-17, 2004
pgp0.pgp
Description: PGP signature
Re: use of release names in d-i
On Wed, Dec 03, 2003 at 12:19:03PM -0500, Joey Hess wrote: Anthony Towns wrote: On Tue, Dec 02, 2003 at 01:08:24AM -0500, Joey Hess wrote: It seems to me that since debootstrap already knows how to download dists/$SUITE/Release, and in fact does so, it would be best to make it download them and use them to map to release code names. debootstrap only knows to download the Release file once it knows what suite to use. (Not all suites have had release files, eg) Surely all suites that are currently referred to by testing, unstable, and stable have release files and will continue to have them for the forseeable future. The forseeable future doesn't even extend to the next release... Putting it in debootstrap makes it hard to drop in future -- any app, like d-i, that happens to say debootstrap testing is going to complain if that breaks -- whereas putting it in d-i makes it easy to drop if this turns out to be a bad idea. (A nice UI might be something like: cando= for x in oldstable stable testing unstable; do cn=$(wget -q -O - $MIRROR/dists/$x/Release | sed -n 's/^Codename: //p') if [ $cn -a -e /usr/lib/debootstrap/scripts/$cn ]; then cando=$cando $x=$cn fi done echo I can try to install: $cando echo Which one do you want? but that's only possible if d-i has the Release files itself.) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp0.pgp Description: PGP signature
Re: use of release names in d-i
On Tue, Dec 02, 2003 at 01:08:24AM -0500, Joey Hess wrote: It seems to me that since debootstrap already knows how to download dists/$SUITE/Release, and in fact does so, it would be best to make it download them and use them to map to release code names. debootstrap only knows to download the Release file once it knows what suite to use. (Not all suites have had release files, eg) Better to download the Release file from d-i, work out from that whatever you want to work out, then pass it to debootstrap. (Which also lets you let the user do some verification of the Release file before installing) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of release names in d-i
On Mon, Dec 01, 2003 at 05:40:42PM -0500, Joey Hess wrote: If the CDs had Release files that included the code name then we could use that to map between the names. Unfortunatly, the CDs do not currently have such a thing, nor does the debian archive. Huh? ] $ lynx -dump http://ftp.debian.org/debian/dists/testing/Release | ] grep -i Codename: ] Codename: sarge ] $ lynx -dump http://ftp.debian.org/debian/dists/sarge/Release | ] grep -i Suite: ] Suite: testing If the CDs don't already have those fields, it should be trivial to add them, afaics. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp0.pgp Description: PGP signature
Re: Integrating the debian-installer into the archive
On Sun, Oct 05, 2003 at 07:55:01PM +0200, Geert Stappers wrote: Our (di-team) current approach is to hide^Wput the images[1] in a dot deb package and worry some later time how to make the binaries[1] available. It's probably a bad idea to make it a .deb. I'd strongly recommend you not try to get the buildds doing this until you can demo the scripts in a reliable way. Presumably you want to directly access the archive to pull down various udebs, eg, which isn't something you can necessarily do on buildds in a straightforward manner. Have you got the scripts working for all arches yet, or just i386? Are you sure that the scripts are going to work automatically, without root privleges, on other architectures? We are looking for a way to generate the binaries on all archs as none-debs and an integration method with the debian archive. I'm not entirely clear on what you're saying, btw - the language barrier and all. Please include examples of what you're talking about, and consider attaching or linking to the scripts you're talking about. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgp0.pgp Description: PGP signature
Re: Integrating the debian-installer into the archive
On Mon, Oct 06, 2003 at 04:24:23PM +0200, Goswin von Brederlow wrote: It's probably a bad idea to make it a .deb. The problem isn't the building of the files. That either works or gives a build failure which can then be fixed. (Which would already be a big advantage [to see it fail and how].) Uh, if you don't already have it building on your own machines, that's what you need to be working on. If it's alreadying building on your own machines, there's no big advantage in seeing how it fails on buildds. The problem is how to get the build floppy images, tftp images, cdrom.iso images into ftp.debian.org automatically. Encapsulating them in a deb would make it automatic but noone realy likes that. You upload it as a bunch of byhand .tgz's with a signed .changes file. Is disks-arch the right name if we include the small cdrom images? ftp.d.o is the right place for the source files to create the cdrom images. The cdrom images themselves should go on cdimage.debian.org. Depending on what exactly is going on, it might be appropriate to have nothing more than the udebs on ftp.debian.org and move all the disk and cd images onto cdimage.d.o. (A concern with the installer stuff is that its source isn't self contained so the .dsc and .debs can get updated, without the disk images being updated too, which can be bad in various ways. Moving that problem outside of the archive proper can give you some better ways of dealing with it) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgp0.pgp Description: PGP signature
Re: Integrating the debian-installer into the archive
On Fri, Oct 03, 2003 at 08:10:00PM +0200, Sebastian Ley wrote: If it is possible, that's cool. Either way, you'll need to work out how to automate the builds yourselves, and tell everyone else. Oh, I did not post this message to push all the work to the ftpmasters. We merely wanted some hints which solution will be approved by the ftpmasters. Strictly, the only thing that the ftpmasters are worried about is the layout of the archive, and that's not really very tricky. But we'll just assume you were uing the ftpmaster address to contact the buildd maintainers. It doesn't make sense to do the work just to find out that the ftpmasters don't like the solutions (perhaps for good reasons we did not thing about). I'm sure there'll be some problems with whatever you propose (there's always problems with everything I propose anyway), but they're rarely that big. And there's now way of working out exactly what they are until you make the proposal... Basically, start by just doing everything yourselves, then work out (a) what bits you end up building that need to be put on the ftp site, and (b) what scripts you have that can conceivably be run a little bit more automatically. (If you're already at that point, just start talking specifics) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgp0.pgp Description: PGP signature
Re: Integrating the debian-installer into the archive
On Fri, Oct 03, 2003 at 03:54:10PM +0200, Sebastian Ley wrote: 1) Release Scheme - Debian already has a well tested release scheme with the unstable-testing-stable migration. It would perhaps be a good idea to let udebs propagate that path the same way the debs do and build official testing images only from udebs in testing, while the stable installer fetches from stable and the development version from unstable. I've been hesitant to do this for two reasons. One is that it's a fair chunk of work. The other is that d-i hasn't really struct me as being particularly unbuggy and stable (cf the recent NEW uploads and changed shlibs); and adding it to testing in any useful way means blocking other packages due to d-i bugs (such as dependency errors or RC bugs), which I'm loathe to do especially when there're already plenty of other blockages in testing. To achieve this, the only thing to be done seems to adjust the testing scripts to process udebs as well. Avoiding uploading completely broken packages would be a good idea too... * Make a binary debian package that builds the installer and use some totally different autobuilding process I doubt it's possible to use the regular autobuilders personally (I expect you'll require root privleges to mount filesystems for instance). If it is possible, that's cool. Either way, you'll need to work out how to automate the builds yourselves, and tell everyone else. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgp0.pgp Description: PGP signature
Bug#155374: pending meaning change
tags 97671 - pending tags 143825 - pending tags 155374 - pending tags 169264 - pending tags 169413 - pending tags 170820 - pending tags 188877 - pending tags 189832 - pending tags 190592 - pending tags 196234 - pending tags 198337 - pending thanks The definition of the pending tag has been changed to: ] pending ] A solution to this bug has been found and an upload will be ] made soon. The (release critical) bugs above have been tagged pending for over a month, so by the new definition the tag appears to not apply to the above bugs. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Chaos and Damnation!
On Fri, Apr 04, 2003 at 07:24:53PM +0200, Martin Sj?gren wrote: Well, the netinst _CDs_ don't use the net floppy image, Don't the netinst CDs just use the CD images? As far as d-i's concerned, they're as good as the full regular sized CD set, no? but a lot of our testers do use the floppy. Sure. Again there seem to be three ways of doing things: * Boot and install from a CD, or other large media * Boot via PXElinux (ie, netboot), and install via http/NFS/etc * Boot from floppies, then use CD/net/whatever The first two can have 1.44MB images, if necessary, the latter's likely to be fairly unusual, so doesn't have to be completely internationalised if necessary. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgp0.pgp Description: PGP signature
Re: Making netinst CDs Not Suck
On Fri, Apr 04, 2003 at 09:24:15PM +0200, Martin Sj?gren wrote: tor 2003-03-27 klockan 20.26 skrev Raphael Hertzog: Le Thu, Mar 27, 2003 at 11:05:44AM +, Alastair McKinstry ?crivait: I don't know how to fix 2, but one idea I had for fixing 1 was to have overrides in the netinst CD building, so ethdetect and friends would be normally optional, but when put on a netinst CD, they'd be overridden to standard. buxy, however, didn't really like this and suggested a file on the CD-ROM with a list of packages to be installed automatically. Why didn't buxy like it? Because overrides are not supposed to change for each CD. For what it's worth, this is very similar to one aspect of Bdale's flavours idea. Basically, the thought there is that Debian should just have its regular overrides, but a particular flavours will change the priorities of a particular set of packages. What we were looking at there, in the end, was having an extra set of flavour override files that you could select amongst, that would limit the number of packages you viewed in dselect, and raise certain packages to standard (from optional) or optional (from extra - in the case where if you're using a particular flavour, you know you'll need a particular obscure package), and so on. For a complete CD set, you'd want some UI to select your flavour; for specialised CDs, you'd want to have a default flavour preselected. Thinking along those lines, probably with flavours like install from CD, and ask about using the network too, and install purely from the network, might be worthwhile. not meant to change depending on the architecture (like you suggest for the keymaps). Also, we already need to be able to have arch-specific overrides for things like gcc-2.96 on ia64 for woody -- it ought to be standard on ia64 since gcc on ia64 depends on it, but shouldn't be standard anywhere else. The plan is to use the extra overrides file for this, but apt-ftparchive doesn't support it yet. FWIW, etc. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgp0.pgp Description: PGP signature
Chaos and Damnation!
Hi guys, We're going to be making a preview release of sarge sometime fairly soon, probably by the end of the month. This will be a snapshot of testing at some particular time, with CDs and net install images and so forth. It'll be promoted to real live users, and we'll be soliciting, collecting and collating real live feedback from them. The thought of the comments you're probably going to get should probably be somewhat scary at best. The aim is to make the move from research and development and prototyping, to getting d-i to be a real, supported, usable program now, rather than later. Basically, if we're ever going to make a release with d-i, then we need to stop worrying about underlying architecture, and start making what we've got work. If we release with an utterly plain, boring, even ugly text frontend, that's fine - releasing with something that won't install Debian, or that crashes half the time you use it, or that is needlessly confusing and obscure isn't. Of course, pretty and intuitive are good too. Since Tollef Fog Heen seems to be busy, I've asked Martin Sjogren and Petter Reinholdtsen to make up a list of the major things that need doing to d-i to make it more usable. Presumably top of the list is getting the netinst image down to size again [0], but I suspect I don't have much chance of getting Get d-i lead developers to change their names to things I can spell on there. Oh well. Basically, please keep doing what you've been doing, but try to keep an eye on things that a user will find annoying, and fix it sooner, rather than leaving it 'til later. Cheers, aj [0] Although you might like to just declare the netinst image something that you have to use PXELinux to boot -- and thus the size doesn't matter much. Having internationalised CD images and netinst images that are limited to 2.88MB, and an uninternationalised floppy image that's limited to 1.44MB could be workable. -- Anthony Towns [EMAIL PROTECTED] Debian Release Manager pgp0.pgp Description: PGP signature
Re: Bug#175187: This bug should be fixed on boot-floppies side
On Thu, Jan 09, 2003 at 07:40:24PM +0900, Junichi Uekawa wrote: I don't really like the way the amount of packages debootstrap installs is increasing, but that probably has to be done... There probably needs to be a long-sought distinction between base system and installation system There isn't a distinction: base is precisely what is needed for an installation. There is a distinction between required (cf essential) and base, though. The current way we describe base isn't really great, but it's what we've got. Seems to make the most sense to add eject to base on all arches. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Australian Linux Lovefest Heads West'' -- linux.conf.au, Perth W.A., 22nd-25th January 2003 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#174410: questionable interpretation of install pseudo-package
On Thu, Dec 26, 2002 at 11:14:01PM +, Colin Watson wrote: On Thu, Dec 26, 2002 at 09:32:28PM +, Zefram wrote: Package: bugs.debian.org Today I've been reporting a few bugs in a Debian package. Some of my bug reports have been rejected by a developer for reasons that amount to fixing that bug is too big a change to make in stable. In no case have I actually asked for any changes to stable; I'd be perfectly happy with fixes eventually appearing in sarge. There's little point filing bug reports about problems experienced with the woody installer; the sarge installer is _completely_ different, to the point where problems and wishlists for the woody installer are _completely_ irrelevant. It sucks to have to ignore the good ideas that people have about improving the woody installer, but it really is all that's possible at the moment. It does seem that a pseudo-package for the debian-installer would be useful; however, I don't see why the existing 'install' etc. pseudo-packages aren't good enough, if people will stop assuming that bugs filed there relate exclusively to boot-floppies. Mixing bugs that apply to boot-floppies and to debian-installer isn't helpful. Also, given the trivial amount of code shared between debian-installer and boot-floppies, bugs found in one aren't relevant to the other in most cases. Would your request be satisfied if any bugs against install/installation regarding boot-floppies were reassigned to the package of that name, and the boot-floppies developers agree not to brush off bugs filed there with won't happen in boot-floppies (and to reassign bugs to install/installation as appropriate)? Honestly, I don't think the boot-floppies guys will or should agree to that. The priority for d-i is still to make things work roughly as well as b-f's, not to make sure random annoyances from b-f's don't show up again. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Australian Linux Lovefest Heads West'' -- linux.conf.au, Perth W.A., 22nd-25th January 2003 msg24976/pgp0.pgp Description: PGP signature
Re: preparation for the alpha
On Thu, Dec 05, 2002 at 03:22:20AM +0100, Tollef Fog Heen wrote: The following stuff is still missing: - reporting tool (code to write, non-trivial) A good aim is probably to make this as trivial as possible. A possibility is to store the udebconf database in /target just before rebooting (it shouldn't be too hard to ensure udebconf has quit by then), and have base-config propose a template mail based on /proc/cpuinfo, free, the templates file, and allow it to be edited and mailed by the user. It makes more sense to refine it once you know how it's going to be used, anyway. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg24112/pgp0.pgp Description: PGP signature
Re: Debootstrap question
On Wed, Nov 13, 2002 at 01:39:46AM +0100, Tollef Fog Heen wrote: | I am playing with debootstrap to build a custom base system. | I would like to include freeswan in the list of deb packages. | Unfortunately, freeswan is in the non-US archive. I just | wonder if there is an easy way to do it through debootstrap. pass the --components flag to debootstrap. This shouldn't work -- non-US has a separate Release file, and usually needs a separate URL. If it does work, let me know, and we'll see about fixing that... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-Installer Alpha Release
On Tue, Oct 08, 2002 at 07:47:48PM +0200, Tollef Fog Heen wrote:
| NB2: Looks to me like the cdrom-retreiver looks for Packages in
| dists/sid/suite/debian-installer/binary-*/Packages, which seems
| a mite off (isn't sid a suite?) especially for sarge cdroms.
{main,contrib,non-free} is the suite, {stable,testing,unstable} is the
distribution, AIUI.
Nope: stable/testing/unstable is known as the suite (or the distribution),
main/contrib/non-free is known as the component (or section). Suite and
component are unambiguous, unlike distribution (cf Debian) and section
(cf admin/utils/etc).
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year older when you do.''
msg22670/pgp0.pgp
Description: PGP signature
Debian-Installer Alpha Release
Hi guys, it's time to release. (Scary sayings 101 ;) So, the CD folks are starting to get automated CD images of testing going (http://gluck.debian.org/debian-cd/testing/isos/i386/sarge-i386-[1-8].iso) and they're wanting to make them bootable. Hence, it's time to give you lot a spot in the sun. If you remember Tollef's post from late August, you might remember seeing: ] Our RM wanted a limited, but working installer in approximately 14 ] days. I hope to meet that goal. It's been a bit more than 14 days since then, so hopefully y'all can meet this much more limited goal: * 1.44 / 2.88 disk images, based on current d-i in unstable, that boots on some common i386 hardware, shows a user interface, and allows you to download new udebs. Working isn't necessary, we just want to be able to stick a CD in, and have d-i come up, not necessarily being able to do Debian installs reliably. We've been putting off generating and uploading images a little too long. So, I think y'all are far enough along that you can probably come up with something like this by the end of the week without any major problems. Remember: it's alpha, it doesn't have to be good, and it doesn't have to be automated or repeatable. Yet, anyway :) Once you have, dump them in ~whoever/public_html/ on auric, and we can start thinking about where we're going next. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg22626/pgp0.pgp Description: PGP signature
Re: Debian-Installer Alpha Release
On Tue, Oct 08, 2002 at 05:16:16PM +1000, Anthony Towns wrote: So, I think y'all are far enough along that you can probably come up with something like this by the end of the week without any major problems. Remember: it's alpha, it doesn't have to be good, and it doesn't have to be automated or repeatable. Yet, anyway :) Oh, and let me add: it's _far_ better for three or four different people to all do this than risk no one doing it. Don't think of it as wasted effort, think of it as proving that if anyone disappears we've got plenty of backups who're somewhat experienced with doing d-i builds, and investigating alternative ways of doing things. Please post to -boot if you're getting anywhere or if you're not, and please assume if no one else has posted, that they're all waiting on you to do something. Yes, _you_. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg22634/pgp0.pgp Description: PGP signature
Re: debian-installer status -- 2002-08-26
On Mon, Aug 26, 2002 at 12:39:06AM +0200, Tollef Fog Heen wrote: - dak needs to stop unaccepting new udebs. This should be fixed now, anyway. - a bunch of full-sized udebs needs to be created (more on this below) That's such a contradiction in terms, btw :) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status -- 2002-08-26
On Tue, Aug 27, 2002 at 06:28:12PM +0900, Junichi Uekawa wrote: On Tue, 27 Aug 2002 02:36:33 +1000 Anthony Towns [EMAIL PROTECTED] wrote: What's going to go on the rootfs? Presumably something like: libc6, busybox-udeb, ash-udeb udpkg, cdebconf, anna *-retriever and any dependencies they have /lib/modules/kernel/** The floppy is too small a place for putting in i18n locale info, and debian-installer, and I think this was the initial intention of d-i being modular. Do we need the i18n locale info in the rootfs though? All you need is enough i18n so you can prompt for which retriever to use, and to configure it, no? In the normal case, you're installing from a CD, so we can figure out some way of automating that entirely -- did we boot from a cd? yes? then use cdrom-retriever, install libc6 etc, then start prompting for real -- in which case we don't have to worry about floppy sizes. And in the next most common case, you just need to be able to enter a URL in your preferred language, which is pretty straightforward. In any event, there's no better way to do this -- you need some way of prompting the user to insert the next disk in their local language, and if you can't manage that for a 3k -retriever, you're not going to be able to manage it at all, afaict. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg21610/pgp0.pgp Description: PGP signature
Re: debian-installer status -- 2002-08-26
On Mon, Aug 26, 2002 at 01:45:03PM +0900, Junichi Uekawa wrote: I was kind of thinking of udebootstrap, but that might be a bit more tricky. I've been kind-of thinking about that too, although I don't think it'd remotely resemble debootstrap on the implementation side. A udebootstrap would allow us to distribute the installer as a bootable kernel, udebootstrap-as-init, and a bunch of .udeb files that will be unpacked by udebootstrap to the point where cdebconf, anna and various retrievers and such work. This is by way of defining what udebootstrap means -- it creates a udeb-based system where there isn't already one. We don't have to do this at all -- d-i already works by just having an image of a working udeb-based system that you burn onto CD and boot, no bootstrapping required. Anyway. The first question is whether udebootstrap can even be implemented. It probably can be -- a statically linked busybox with ar, gzip and tar should let you do the initial unpacking, and since that _seems_ to be pretty much all that make tree does, there doesn't seem any great reason why you couldn't do that as part of booting the installer. Whether there's any point to all that's another matter. You're only buying yourself a smaller rootfs, and you're only doing it by giving yourself less ways of accessing the first set of udebs you want to install. If that means you can boot from a single floppy disk, rather than a boot-root pair, but only because you then need to insert another couple of floppies to get full versions of libc6 and wget-retriever, that's not a win. What's going to go on the rootfs? Presumably something like: libc6, busybox-udeb, ash-udeb udpkg, cdebconf, anna *-retriever and any dependencies they have /lib/modules/kernel/** ? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg21596/pgp0.pgp Description: PGP signature
Re: debian-installer status -- 2002-07-29
On Mon, Jul 29, 2002 at 04:48:30AM +0200, Tollef Fog Heen wrote: Anthony Towns has written some things [...] More of a segue than a reply, but hey. Kibozing on irc shows up some remarks like: Mithrandir aj wants to be able to autobuild on other arches, so we'll be able to build ppc images on i386. you think that's doable? joeyh I don't see why that should be a requirement Mithrandir to not require synching 20 arches or so. (11 in woody + hurd + maybe some bsd stuff + maybe new arches?) joeyh it's probably possible; nothing much is run when udebs extract. It might be possible to get lib reduction to work joeyh but it seems like a lot of extra work asuffield Mithrandir: you'd need a cross-build of every boot loader widget asuffield: that's a huge number of possible cross targets joeyh asuffield: already have that mostly for debian-cd Mithrandir asuffield: that's what I think might kill us, yes. I have _no_ idea how hard that is. To be accurate, I don't care if you can autobuild on other architectures, what I consider important is for one or fewer people (ie, whoever made the last d-i changes, whoever's building CDs or just some automatic system) to be able to get d-i up to date every where. I think the most sensible way of doing this is to work out some way of letting you construct the boot images on alternate architectures. Having an additional, parallel series of autobuilders is likely to not work incredibly well: some of them will become unmaintained as RL intereferes, others will go down or break just when you need them, and some architectures won't bother setting them up at all until we're just about ready to release. Or that's what I'd suspect anyway based on my experiences with the real autobuilders and b-f's in general. I could be wrong. The other aspect to this is that if we can make a technical solution, then we don't have to worry about it again: CVS servers don't get bored and shut themselves down, and anyone at all can easily get d-i images built for every architecture, even if they're a third party hacker somewhere who's never been seen on -boot. That's a win. There's nothing _fundamentally_ undoable here, either. There are three areas to worry about: * getting the directory structure setup -- unpacking the udebs is easy. running postinsts isn't as easy, but seems like it should be easily avoidable: anything particularly necessary can be scripted separately. * getting the image created. This is pretty easy: it either requires a loopback fs to be mounted and such, which can be done anywhere except on the buildds; or it requires one of the magic tools that let you create the image in place * making the image bootable. This is trickier. One possibility is porting milo, yaboot, silo, palo, etc to i386, and requiring d-i images to be built either natively or on an i386. There are probably others. mihtjelyeah, I read it, and I understand it - although you seem to be a bit more confident in d-i than aj was ;) Mithrandir mihtjel: I've seen d-i. I've hacked d-i. I don't think aj has either. Mithrandir (and, yes, I probably seem arrogant, but that is because I know what's possible to do. or something. :) mihtjelwell, if you're sure it's going to be used, there's nothing wrong in saying that it is going to be used ;) Mithrandir it's d-i and/or pgi. I can always back down on that one. FWIW, I've poked at cdebconf and anna in the past, and I wrote debootstrap, so I'm not completely naif. My only real concerns about d-i are related to its debconf usage: that it still doesn't have a cfdisk equivalent says bad things about that, IMO. But I'm biassed against debconf, and rewriting all the UI stuff into debconf isn't remotely hard enough to be a showstopper. I think it'd be a huge win to have dbootstrap and/or pgi UIs available concurrently with d-i (stick in a CD, choose a kernel, choose a UI...). It'd let us do cool things like have an Eye Candy installer with XP-like graphics, that we can target at kindergarten kids and distro reviewers without having to worry about whether it'll work on m68k, eg. I dunno if any of the yay b-f's! people are convinced enough to try porting the core of it to udeb format. In any event, it's a win to have each of the features of the installer be separate: debootstrap, hardware detection, base-configu, the distribution mechanism (udebs), the UI. That way if any of them turn out to be fundamentally stupid ideas, we can drop it without having to start completely from scratch. Am I convincing anyone by talking about this, or am I going to have to prove all this is possible with code? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself
Re: d-i udebs up-to-dateness of archive
On Sat, Jul 27, 2002 at 02:34:51PM -0400, Joey Hess wrote: udeb version in cvs version in sid needs upload Tangentially, wouldn't it be helpful to have parted and/or cfdisk udebs so that, at worst, you can switch to VC2 and run them from the shell? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] debconf, partitioning widget?
On Thu, Jul 25, 2002 at 07:57:22AM +0200, Michael Bramer wrote: we don't need real developing in b-f. B-f should only a fall back for sarge, if d-i is not ready. I suppose it was a while ago now, but it's still a bit sad that people are forgetting this is _exactly_ what we were saying for woody. b-f's as a fallback doesn't work, it's too thorougly unmaintainable. Or installation system needs _major_ work, easy solutions like just fall back to boot-floppies *don't* work. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg21034/pgp0.pgp Description: PGP signature
Re: [d-i] debconf, partitioning widget?
On Thu, Jul 25, 2002 at 11:46:37PM +0900, Junichi Uekawa wrote: Anthony Towns [EMAIL PROTECTED] immo vero scripsit: b-f's as a fallback doesn't work, it's too thorougly unmaintainable. Or installation system needs _major_ work, easy solutions like just fall back to boot-floppies *don't* work. It's quite interesting that you insist on b-f being so unmaintainable when you don't seem to be involved with boot-floppies. It's not that bad. :P It's a lot worse when you have to care about it working on non-i386. But hey, whatever. Obviously there's no value in my or Adam's experiences with trying to make a release with boot-floppies. Please, knock yourselves out. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg21053/pgp0.pgp Description: PGP signature
Re: [d-i] debconf, partitioning widget?
On Wed, Jul 24, 2002 at 12:22:34PM +0200, Eduard Bloch wrote: Anthony Towns wrote on Tue Jul 23, 2002 um 08:33:55PM: We won't be freezing until we have a satisfactory and functioning installer. Nice. I have seen how motivation disappears when you are waiting longer than 8 months for the next _freeze_. That's nice. You realise our actual freeze this time round lasted less than three months, and most of that was due to the security problem which we should've known about earlier, and which we won't have to implement again, right? Only the time will prove. But I think that this is exactly this attitude that caused the fucking long release period of Woody. And you are continuing working the same way. One of the nice things about Debian is that you can do just about whatever you damn well please no matter what anyone says. If you can convince people that there's a better way of getting sarge out the door than my way, and if you're right, then that's what'll happen. But you don't convince people by speculation. In short, stop ranting at everyone working on d-i, and prove to them that b-f really can do the job better, by *making* it do the job better. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg21011/pgp0.pgp Description: PGP signature
Re: [d-i] debconf, partitioning widget?
On Tue, Jul 23, 2002 at 01:16:29AM +0200, Eduard Bloch wrote: I propose that we use what we have and do not try to force _new and untested_ code to replace BFs. IMHO, either we base on boot-floppies and freeze in few months, You can propose whatever you like, but the above is sadly deluded. From experience, getting b-f's updated and ported to the existing architectures takes between 8 and 12 months. We won't be freezing until we have a satisfactory and functioning installer. You're welcome to try to prove that this isn't the case, but everyone else has seen the way b-f's work a few times now, so don't expect anyone to believe your claims until you /have/ proved them. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg20978/pgp0.pgp Description: PGP signature
Re: woody install: NFS hangs
On Thu, Jul 18, 2002 at 08:06:37PM +0200, Eduard Bloch wrote: #include hallo.h Andrea Mennucc wrote on Thu Jul 18, 2002 um 07:41:14PM: Actually, I would propose to NOT USE vga for the rescue disk: this is the 3rd woody install I tried, and all had problems with vga Beeing precise: you have problems with _your_ broken VGA emulation. Eduard, we have the privelege of trying to support every computer no matter how broken or prorietry it is. It's not his fault that our software doesn't work on some laptop, it's ours. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg20930/pgp0.pgp Description: PGP signature
Re: [d-i] debconf, partitioning widget?
On Tue, Jul 16, 2002 at 07:24:11PM +0200, Eduard Bloch wrote: Why not? It works. Knock yourself out. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] debconf, partitioning widget?
On Mon, Jul 15, 2002 at 06:03:38PM +0200, Eduard Bloch wrote: #include hallo.h Anthony Towns wrote on Tue Jul 16, 2002 um 01:39:21AM: We can stick with boot-floppies for Woody+1 and release Debian-4.0 with DI ;) No, no we can't. You like argumenting with semi-technical reasons - so which one is it this time? Good grief, you _weren't_ joking? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] debconf, partitioning widget?
On Mon, Jul 15, 2002 at 09:50:26AM +0100, Philip Blundell wrote: On Mon, 2002-07-15 at 00:58, Tollef Fog Heen wrote: However, manual partitioning using debconf will be very painful. Developing a debconf partitioning widget might be a little overkill, so I am not sure how we want to solve this challenge. Provide some way of dropping to a real program, like cfdisk? (switch the user to vc5, run cfdisk there, once it's quit, flick back to vc1) How about writing a handful of frontends for libparted, so that we have one similar in style to each debconf frontend? That seems like a fair chunk of effort, and relying on libparted being stable and usable (when we've never tried it before), _and_ signficantly enhanced, seems like a good way of adding another long delay before we can get the next release out. Just getting the installer to work on Debian (with the 11 arches we have, and the extra ones waiting in the wings, not to mention the huge range of system capabilities we expect to work with) is a pretty hefty challenge. Do we think that parted will be stable enough to use as the sole partitioning program for a debian-installer based release? I'm expecting some working installation systems (PGI, d-i, whatever) within a couple of months... (i386 only, and other limitations, sure, but working nevertheless) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' msg20852/pgp0.pgp Description: PGP signature
Re: [d-i] debconf, partitioning widget?
On Mon, Jul 15, 2002 at 03:58:03PM +0200, Eduard Bloch wrote: We can stick with boot-floppies for Woody+1 and release Debian-4.0 with DI ;) No, no we can't. Cheers, aj (Joke you say? Like in an egg? Funny? Yes, they are runny if you don't boil them.) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149974: debootstrap should download aptitude
On Sat, Jun 15, 2002 at 01:35:24AM -0500, Adam Heath wrote: We've done it correctly. dpkg 1.10 predepends on dselect. dselect 1.10 replaces dpkg ( 1.10). This will ensure upgrades, and no loss of functionality. Any new dependencies from base packages to non-base packages need to a new debootstrap. Please file a bug against debootstrap either before or at least concurrent with the upload. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n second stage...
On Thu, Jun 13, 2002 at 07:43:45PM -0400, Joey Hess wrote: Michael Bramer wrote: A debian package maintainer don't need some reasons for a new package. If the package is free and someone make the work, the ftp master(s) should include the package on the debian ftp server. Not without good reason, and not if there is a consensus against or significant controversy around it. apt-i18n fails on at least 2 counts. And not when it involves an essential package. mutt-ja is a different matter to apt-i18n. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149974: debootstrap should download aptitude
On Sun, Jun 16, 2002 at 02:12:10PM +0900, Junichi Uekawa wrote: Anthony Towns [EMAIL PROTECTED] immo vero scripsit: On Sat, Jun 15, 2002 at 12:56:38PM +0900, Junichi Uekawa wrote: I've pondered with the code a bit, and I think this is an overkill to require aptitude in base. By having base-config Depend: on it, or download it in the normal course of events, you're effectively putting it in base. debootstrap is currently a fragile piece of software, Certainly; I'm expecting it to become a chunk less fragile (especially wrt the contents of base) over the course of the next release, though. Debian base doesn't really need aptitude, a Debian installation requires one. If a Debian installation requires aptitude, then it should be in base. That's basically the definition of base. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149974: debootstrap should download aptitude
tag 149974 - patch thanks On Fri, Jun 14, 2002 at 04:02:11PM +0200, Ivo Timmermans wrote: The new base-config package in sid depends on aptitude, so debootstrap should download it. Bleh. Guys, please file the bug on debootstrap *before* adding new dependencies to base packages and breaking it completely. Joey, are you sure it wouldn't have been better to make base-config use aptitude if present, and file a wishlist bug on debootstrap to ensure its presence on normal installs? -dpkg guys, cc'ed so we don't get the same thing happening with the presumably forthcoming dselect package. -boot guys, cc'ed in the probably vain hope that anyone else likely to do this in future will notice too. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n second stage...
On Wed, Jun 12, 2002 at 07:45:15AM +0200, Eduard Bloch wrote: IIRC we would need at least translated templates for passwd and console-data. When I asked about chances of making i18n in Woody, I got a veto, explaining that I was too late and we are very close to the release and it may be possible when I had begun 6 months before. Yes, and those six months have been spent fixing the existing problems. I'm sorry, but the standard i18n hystrionics aren't helpful or interesting. If you want to ever have Debian support i18n well you need to start working on unstable early in the release cycle and demonstrate some patience and some skill. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg20385/pgp0.pgp Description: PGP signature
Re: i18n second stage...
On Thu, Jun 13, 2002 at 06:50:30AM +0200, Michael Bramer wrote: Only may request: it is to late for a translated 2. install stage, it is to late for a apt-i18n, it is to late for a 'select ddtp-source in the b-f', it is to late for a ... No, it's not too late for apt-i18n, apt-i18n is screwed in other ways. You need to actually *WORK WITH* Jason to get the changes acceptable to be merged into apt, or for it to be clear that a separate package is the right way to go. Similarly for the ddtp nonsense, you need to rewrite the piece of junk so that we don't have to worry about it overloading a dual 900MHz UltraSparc with 1.5GB of memory. Just going off on your own and deciding hey, no one else cares about i18n, therefore I can just do whatever I want and it doesn't matter how this affects anyone else, and anyone who disagrees is obviously one step away from being a racist anyway isn't helpful. Yeesh. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg20387/pgp0.pgp Description: PGP signature
Re: Invalid Release file, no main components
On Wed, May 15, 2002 at 04:52:06PM +0200, Othmar Pasteka wrote: On Tue, May 14, 2002 at 08:58:08PM -0700, Chris Tillman wrote: [begin Release file] Origin: Debian Label: Debian Suite: testing Codename: woody Date: Tue, 14 May 2002 19:47:47 UTC Architectures: Components: ^ this is missing, main contrib non-free should be there. look on aruic and in the Release file there. maybe a problem on some end? maybe the ftp masters know more ... (The format of katie.conf changed, and a few of the girls didn't get updated to match. Should be fixed now, ie, in the next mirror pulse.) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
b-f 3.0.23
Hi guys, If you'd like to tag and upload 3.0.23 sometime this week, that will be fine. I believe there are some sparc updates desirect so we can have bootable sparc CDs, that Ben will know about. Please follow Adam's lead, and don't do anything to break them. It'd be better if all architectures could sync on 3.0.23 reasonably quickly, but any that don't will just stick with 3.0.22. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg19768/pgp0.pgp Description: PGP signature
Re: Please test this woody cd image
On Wed, Apr 10, 2002 at 09:31:12PM -0400, Matt Zimmerman wrote: On Wed, Apr 10, 2002 at 05:39:36PM -0400, Michael Stone wrote: I have installed many SCSI systems (including the one that I'm using right now) with potato CD #1, which I assume has a similar configuration. Potato CD#1 used the vanilla flavour, Woody CD#1 was going to use the idepci flavour (which doesn't have SCSI support), since Raphael's primary language isn't English and the vanilla flavour doesn't support language chooser. Now we could argue back and forth about this until May trying to convince each other, but that'd be a waste of everyone's time and quite annoying to all involved. Doing the isolinux thing gets rid of this problem for us, and makes CD#1 much more flexible and intuitive to installers, and there're good reasons to expect it to work well. There's not enough time to test it well (and, tbh, woody hasn't been tested anywhere near as well as it should've been in _any_ respects) but even if it *doesn't* work everywhere it's expected to, that's not a huge loss, since we'll still have CD#2-4 bootable with each individual image, and floppy images will also be available. This seems to be a very good choice. Additionally, it's very easy to test: find random systems, reboot them with the small CD Raphael's prepared and check you can get into the installer. You don't need to go all the way through the install, nor worry about damaging your system at all -- as soon as you get to the pretty installer screens, you're done. Seriously: everyone reading this mail, burn a copy of Raphael's test image on a CD and try booting it in any computers you have handy. If it doesn't work on a machine where a potato CD does boot, please mail the lists! I absolutely agree that a choice on CD 1 would be superior, especially since it would make it possible to have the choice of a 2.4 kernel while only using one CD. But I think it would be even better to make a high-quality release release according to aj's tentative schedule, rather than a minimally-tested release (possibly much) later. Worst case, if people do find a bunch of systems where this doesn't work, we revert the change. There's no reason that should delay anything. Cheers, aj, who has no idea why this is on -boot and -devel but not -cd -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test this woody cd image
On Thu, Apr 11, 2002 at 10:12:28AM +0200, Eduard Bloch wrote: Matt Zimmerman wrote on Wed Apr 10, 2002 um 09:26:45PM: Do you follow those distributions' user and support mailing lists? I certainly don't, so I've no idea who can or can't install them. What I do Oh, please stop talking about theoretical issues without any real evidence. Eduard, take a pill. In the absence of reliable testing (which we don't have in many areas), many of our issues will only become practical the day after release. Much better to tackle them while they're still theoretical in that case. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Post-woody
Hi guys, I just wanted to give y'all a heads up that I'd like you all to stick around post woody, and keep/start working on CDs and installation stuff for the next release. This doesn't change anything about debian-installer, it'd just be helpful if you don't all wander off for four to six months like usually happens :) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg18784/pgp0.pgp Description: PGP signature
Re: Bug#141763: boot-floppies: Nano breaks lines when editing sources.list by hand.
On Mon, Apr 08, 2002 at 10:29:43PM +0200, Jordi Mallach wrote: aj, if you're reading this, do you foresee buildd's picking up w-p-u in the near future? Nope. The traditional pico thing of letting it wordwrap, then using backspace to join the two lines once you've finished still works, doesn't it? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#141490: Testing base floppies 4.4.2002 don't work
Package: boot-floppies Version: 3.0.22 Severity: serious (severity justification: so aph can spot it easily :) Lorenzo, I'm forwarding this to the debian bug tracking system so it gets tracked properly rather than lost in the mailing list archives. - Forwarded message from Lorenzo J. Lucchini [EMAIL PROTECTED] - From: Lorenzo J. Lucchini [EMAIL PROTECTED] Subject: Testing base floppies 4.4.2002 don't work Date: Fri, 05 Apr 2002 18:31:55 +0200 To: [EMAIL PROTECTED] X-Mailer: Opera 6.01 build 1041 Hello, The current testing base floppy images do not work with the install system. Disks from 1 to 9 work, but then disk 10 is seen as disk 1, as well as all following disks, and disk 20 is seen as disk 2. Thank You for Your time by LjL [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4 kernel as default boot kernel on CD #1 ??
On Fri, Apr 05, 2002 at 10:07:38AM +0200, Eduard Bloch wrote: #include hallo.h Jim Westveer wrote on Thu Apr 04, 2002 um 05:24:24PM: And last, woody ought to be 2.2 based and not 2.4 based ... but since I also find it lame to use 2.2.x by default nowadays ... I disagree, 2.4.x kernels have been out for over 2 years.we should not release a new version of Debian with such an outdated kernel ! [appologies in advance to the boot-floppy group for all their hard work] Agreed. The decission, which flavor has to be on the first CD, is done by debian-cd's scripts, see /usr/share/debian-cd/tools/boot/woody/boot-i386. CD distributors can change it if they like. GUYS, _STOP IT_. NOW IS _NOT_ THE TIME TO MAKE CHANGES TO THE WAY THE INSTALL WORKS. 2.4 is not the default kernel for woody installs, 2.2 is. Yes, it sucks, and I don't care. If anyone asks why, blame me. DO NOT MAKE FURTHER CHANGES TO THE WAY DEFAULT INSTALLS WORK. Not if it makes a billion more people able to use Debian. Not if it's so fundamentally offensive that it makes you want to disembowel yourself with a screwdriver. The default kernel for woody is 2.2. The way languages work is the way it's worked for the past twelve months. If you want to change stuff, the time was over six months ago, and it'll be that time again in a month or two. IT IS _NOT_ NOW. boot-floppies has exactly two goals right now: make sparc and alpha boot-floppies work, and make sure that all the successful installs we've seen so far weren't a collective fantasy. debian-cd has exactly one goal right now: make sure we're ready to produce official CDs that include the entire archive and let you get started on an install. Cheers, aj (woody release manager) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg18274/pgp0.pgp Description: PGP signature
Re: 2.4 kernel as default boot kernel on CD #1 ??
On Fri, Apr 05, 2002 at 07:00:08PM +1000, Anthony Towns wrote: 2.4 is not the default kernel for woody installs, 2.2 is. Oh, and is already clear to everyone involved, this is for i386. Other ports obviously have 2.4 kernels as default. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4 kernel as default boot kernel on CD #1 ??
On Fri, Apr 05, 2002 at 10:45:21AM -0800, Jim Westveer wrote: On Friday 05 April 2002 01:00, Anthony Towns wrote: GUYS, _STOP IT_. NOW IS _NOT_ THE TIME TO MAKE CHANGES TO THE WAY THE INSTALL WORKS. I am not suggesting changing anything in how the install works, or anything to do with the boot floppys packages. [...] and try an installation with CD#1 as the disk you innitially boot from, then try the CD#3 with the bf24 kernel. The first thing you will notice is that the bf24 flavor first asks you for your language, where the default does not. IOW, the install works different. I'm not really sure what part of _STOP IT_ is so difficult to understand, but please _STOP IT_. If you want to move the bf2.4 kernel images onto the CD#2 bootsector, that's fine. But the default kernel for woody, and hence the image that should be on CD#1, has always been and remains 2.2. Changing fundamental things in the install process (like the kernel used, the machines supported, or the way you get to choose languages) is completely out of the question at this point. Cheers, aj (woody release manager) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg18317/pgp0.pgp Description: PGP signature
Re: Testing base floppies 4.4.2002 don't work
On Fri, Apr 05, 2002 at 01:35:52PM -0800, Matt Kraai wrote: On Fri, Apr 05, 2002 at 06:31:55PM +0200, Lorenzo J. Lucchini wrote: The current testing base floppy images do not work with the install system. Disks from 1 to 9 work, but then disk 10 is seen as disk 1, as well as all following disks, and disk 20 is seen as disk 2. What architecture are you using? What is the md5sum of the 10th disk image? He's using i386 presumably, since there aren't any floppy images of base for other architectures. As far as I can tell the floppy images are correct, but I can't see any reason for floppy_merge to not be coping correctly. md5sums should be: 103560e946ea5318825f6f753bad87b8 base14-1.bin 0fd2d0119c6123af89aa2b5208510dee base14-10.bin 3c999cab208357d41a3856c74d53b419 base14-20.bin Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg18323/pgp0.pgp Description: PGP signature
Bug#141106: woody base-1.bin sayes wrong disk
On Wed, Apr 03, 2002 at 09:30:18PM -0700, Chris Tillman wrote: On Wed, Apr 03, 2002 at 05:47:21PM -0600, TRS wrote: This is Disk 1 of 19 in the base series of 18-Mar-2002 21:58 EST Wrong Disk, This is from series base. You need Disk 1 of Series the base series. This is a known problem covered on the list recently, but we haven't figured who or what generated the base images. floppy-split was incorrectly invoked when they were generated. Where did you obtain the images? Presumably they're the ones on the ftp site, under dists/woody/main/disks-i386/base-images-3.0.21-2002-03-18/images-1.44. The floppy_split invocation was: fs=`pwd`/floppy_split pwd=`pwd` (cd disks-i386/images-1.44 $fs $pwd/basedebs_3.0_i386.tar base 1440) lists.debian.org/debian-boot/2002/debian-boot-200203/msg01329.html And, bah. Obviously I didn't read the bit that says base14, not base. They'll be fixed with the next mirror pulse. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Vote [1] Bdale! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#141106: woody base-1.bin sayes wrong disk
On Thu, Apr 04, 2002 at 09:06:13AM -0600, TRS wrote: And, bah. Obviously I didn't read the bit that says base14, not base. They'll be fixed with the next mirror pulse. Does this mean that all the base floppies were affected or just base-1.bin? All of them. When is the next mirror pulse? It varies depending on what mirror you use. They start in around, uh, five or size hours or so. When ftp.debian.org has a disks-i386/base-images-3.0.21-2002-04-04 directory you should be right. You seem to be the first person to actually try these disks, so if you could send a report if they actually turn out to work, that'd be helpful. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Vote [1] Bdale! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0.22 plan, translations (b-f bugs dropping like flies.)
On Tue, Apr 02, 2002 at 04:27:03PM +0900, Junichi Uekawa wrote: On 02 Apr 2002 01:23:05 -0500 Adam Di Carlo [EMAIL PROTECTED] wrote: There is no real criteria. Oh, piss off. This is very rewarding a word to hear from you. Yeah, and oh, no, that wasn't a researched decision, in fact, it barely even rates as a whim. Why, someone probably banged their head on the keyboard and just put spaces after every two letters and used those as the languages to include doesn't underrate the work aph did at all, right? Is it too much to ask for my native tongue to be added to the b-f ? Well, yes. It's not possible to include the native tongue of everyone who asks (due to lack of space), and it's not particularly reasonable to choose the tongues of the first or last N people who ask. Build some debian-jp bootdisks, put them up somewhere useful, and encourage Japanese people to use them, if you like. Or make sure the next boot-floppies don't limit available languages due to disk space. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Vote [1] Bdale! msg18137/pgp0.pgp Description: PGP signature
boot-floppies 3.0.22
Hi guys, Boot-floppies 3.0.22 are final except for serious bug fixes. No new features. Alpha guys, build them now, or you're releasing with 3.0.17 from november, and all the brokenness that entails. If there's anyone else working on the alpha port than Chris, rendering what assistance you can would be a damn fine start. [EMAIL PROTECTED], and #debian-boot on Open Projects are where y'all should've been hanging out for the past four months fixing this. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Vote [1] Bdale! msg18143/pgp0.pgp Description: PGP signature
Re: Malformed Release File
tag 138654 - patch thanks On Sat, Mar 16, 2002 at 02:21:55PM -0500, Adam Di Carlo wrote: Chris Tillman [EMAIL PROTECTED] writes: So in this case, it really was a server problem. Is there some way we could check specifically for dns name resolution and ping-ability and return that as an error instead of Malformed Release file? It's possible -- but isn't this a debootstrap issue? Shouldn't it be filed as a wishlist on that? The bug's 138654 and is Cc'ed. The patch isn't suitable, it's a horrific layering violation to try passing information from pkgdetails.c straight back to boot-floppies. I'm not really convinced using random lines of text from wget is particularly sensible either. In any event, I think you'd be better off handling this within boot-floppies. The simplest thing to do would be to attempt to download mirror/dists/distro/Release and check something actually got downloaded. Doing it in boot-floppies allows you to do more sensible error handling (like backtracking to the mirror prompt if the error was `host not found', or to the distro name if it was just file not found, or similar). As soon as you have the mirror URL, it should be safe to try downloading: mirror/dists/stable/Release mirror/dists/testing/Release mirror/dists/unstable/Release If none of those succeed, you don't have a valid mirror, or your network setup is broken. If some fail, but others work, you've got a partial mirror (by someone using Joey's scripts...). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#137089: [sparc/sun4cdm] Failure while unpacking required packages
reassign 137089 boot-floppies
tag 137089 - help
thanks
installer.log is handled by boot-floppies, not debootstrap. Apparently
/var/log/messages is copied to /target/var/log/installer.log in
{reboot,halt}_system.c.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
We came. We Saw. We Conferenced. http://linux.conf.au/
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: localising base-config - end game
On Wed, Mar 06, 2002 at 08:17:05PM +0100, Eduard Bloch wrote:
(*) BFs can install additional packages when isntalling from CD or from
net. There should still be one hook to disable wants_locale if we are
isntalling from prepared basedebs.tar.
I'm not really happy with this. Adding random new features to boot-floppies
right now is a very very bad idea. Our goals right now are to make sure what
we've currently got works for doing installs on all architectures, not making
stuff more elegant, and whatever.
Adding new features adds bugs, which cause inordinate delays. They are
not worth it anymore. Not for _anything_.
Index: utilities/dbootstrap/extract_base.c
+#ifdef USE_LANGUAGE_CHOOSER
+ if(wants_locale) {
+ argv[1] = --boot-floppies;
+ argv[2] = --include=debconf,locales;
+ /* people needing special terminal emulation can still extend the above */
+ argv[2] = --boot-floppies;
+ argv[3] = --arch;
+ argv[4] = ARCHNAME;
+ argv[5] = woody;
+ argv[6] = /target;
+ argv[7] = source;
+ argv[8] = NULL;
+ }
+ else {
+#endif
+ argv[1] = --boot-floppies;
+ argv[2] = --arch;
+ argv[3] = ARCHNAME;
+ argv[4] = woody;
+ argv[5] = /target;
+ argv[6] = source;
+ argv[7] = NULL;
+ }
That trailing '}', eg, doesn't have a corresponding '{' if
USE_LANGUAGE_CHOOSER is unset.
Do not do this.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
We came. We Saw. We Conferenced. http://linux.conf.au/
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
msg16810/pgp0.pgp
Description: PGP signature
New basedebs available next pulse
Hi guys, New basedeb sets will be available after the next pulse, and should include pppoeconf, etc. Additionally the 1.44 and 1.2 floppy images for i386 might have some chance of working this time. It'd be nice if someone were to test it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debootstrap NMU 0.1.16.3
On Mon, Mar 04, 2002 at 09:40:30AM +0100, Eduard Bloch wrote: Don't skip the first part. If you want a separated bug report for each thing, okay. I want to know what you're actually trying to do, so I can be sure not to break that when I try to fix whatever you've inadvertantly broken. In particular, * require newer makedev, fixes build problems on m86k and arm * added additional devices to the device list, especially input and usb needed for modern device drivers (Joysticks, USB, Scanners) breaks basedebs building, and I have no way of telling exactly what the problem was you're trying to solve. Which problem? A base system comes out-of-the box without any device files for the input-style drivers. Is this wise, Look, I don't care about the arguments -- that's for the people who're spending their time working on boot-floppies to grok. I just want to know what they actually *are*. In particular, the new MAKEDEV dependency stopped the binary-basedebs target from working on potato systems, which includes ftp-master, which happens to be where I build basedebs tarballs. I happened to be able to work out how to avoid building the devices tarball at all, in this case, avoiding the issue. But the point is: if you're make an NMU, make sure the problem you're trying to solve is in the BTS. Also, base is _not_ up for random additions. * added pppoeconf to the packages list, better choice for DSL users As said. There was a good chance to ask and stop the package. And I would've had you bothered to file a bug about this so I could actually tell why you were trying to do something and evaluate if it's worthwhile. But you didn't, so I couldn't. NMUs are great, but for them to work, you need to go out of your way to make sure the maintainer's in the loop. -boot put back in the cc's, because I suspect other boot-floppies hackers will want to NMU debootstrap in the future too. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey msg16556/pgp0.pgp Description: PGP signature
Re: Bug#134478: debootstrap: ipchains installed on arches using 2.4 kernel
reassign 134478 debootstrap thanks On Sun, Mar 03, 2002 at 01:37:11PM +0100, Martin Michlmayr wrote: * Eduard Bloch [EMAIL PROTECTED] [20020303 12:59]: debootstrap installs the ipchains packages on architectures for which boot-floppies uses a 2.4 kernel by default. I noticed this on mips and mipsel but there are other arches. iptables instead of ipchains should be installed on those arches. This can and should be fixed using the --include option on arches, where this is needed. I'm not convinced this is the right solution. debootstrap should come with sane defaults. I agree. If we're going to specify what should go in base somewhere, it should be in *one* place, not separate places. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debootstrap NMU 0.1.16.3
*Ahem*. If you've got problems with debootstrap, file a bug about it *then* NMU. Don't skip the first part. In particular, * require newer makedev, fixes build problems on m86k and arm * added additional devices to the device list, especially input and usb needed for modern device drivers (Joysticks, USB, Scanners) breaks basedebs building, and I have no way of telling exactly what the problem was you're trying to solve. NMUs are for making minimal changes, and _only_ when you provide _all_ the information to the maintainer. Also, base is _not_ up for random additions. * added pppoeconf to the packages list, better choice for DSL users Yeesh. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey msg16550/pgp0.pgp Description: PGP signature
Checking successful downloads broken
Package: debootstrap
Version: 0.1.16.4
Severity: serious
Tags: patch
Careful with those followups.
On Sun, Mar 03, 2002 at 06:14:37PM -0700, Chris Tillman wrote:
Debootstrap itself probably won't be able to spot failed downloads
of the Release file because its error checking relies on $PIPESTATUS
which ash doesn't seem to support.
No _that_ sounds like a root cause.
It does indeed. The fix is to make sure pkgdetails' exit code reflects
whether the download succeeded or not. Doing:
diff -urb debootstrap-0.1.16/functions debootstrap-0.1.16.new/functions
--- debootstrap-0.1.16/functionsSun Jan 20 20:29:12 2002
+++ debootstrap-0.1.16.new/functionsMon Mar 4 16:46:00 2002
@@ -46,7 +46,7 @@
local ret=0
if [ $USE_BOOTFLOPPIES_INTERACTION -a $PROGRESS_NEXT ]; then
wget $@ 21 /dev/null | $PKGDETAILS WGET% $PROGRESS_NOW $PROGRESS_NEXT
$PROGRESS_END $PROGRESS_WHAT 3
-ret=${PIPESTATUS:-0}
+ret=$?
else
wget -q $@
ret=$?
diff -urb debootstrap-0.1.16/pkgdetails.c debootstrap-0.1.16.new/pkgdetails.c
--- debootstrap-0.1.16/pkgdetails.c Sun Jan 20 20:25:11 2002
+++ debootstrap-0.1.16.new/pkgdetails.c Mon Mar 4 16:46:10 2002
@@ -56,9 +56,10 @@
exit(0);
}
-static void dotranslatewgetpercent(int low, int high, int end, char *str) {
+static int dotranslatewgetpercent(int low, int high, int end, char *str) {
int ch;
int val;
+int lastval = 0;
/* print out anything that looks like a % on its own line, appropriately
* scaled */
@@ -70,10 +71,12 @@
} else if (ch == '%') {
float f = (float) val / 100.0 * (high - low) + low;
printf(P: %d %d %s\n, (int) f, end, str);
+ lastval = val;
} else {
val = 0;
}
}
+return lastval == 100;
}
int main(int argc, char *argv[]) {
@@ -81,9 +84,13 @@
dopkgmirrorpkgs(argc, argv);
exit(0);
} else if (argc == 6 strcmp(argv[1], WGET%) == 0) {
- dotranslatewgetpercent(atoi(argv[2]), atoi(argv[3]),
- atoi(argv[4]), argv[5]);
+ if (dotranslatewgetpercent(atoi(argv[2]), atoi(argv[3]),
+ atoi(argv[4]), argv[5]))
+ {
exit(0);
+ } else {
+ exit(1);
+ }
} else {
fprintf(stderr, usage: %s pkg mirror packages_file\n, argv[0]);
fprintf(stderr,or: %s WGET%% low high end reason\n, argv[0]);
Seems like it should work.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
We came. We Saw. We Conferenced. http://linux.conf.au/
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alpha and sparc boot-floppies
On Thu, Feb 28, 2002 at 12:22:12PM +0100, Eduard Bloch wrote: #include hallo.h Anthony Towns wrote on Thu Feb 28, 2002 um 06:00:31PM: ] woody/main/disks-i386/3.0.19-2002-02-07 Be aware that if alpha and sparc boot-floppies aren't uploaded in a timely fashion (and 3.0.19 hasn't been), then any bugfixes y'all may need before release just plain won't be happening. Please upload and test new boot-floppies _right now_. Please tell us, do we have a chance to start using kernel 2.4.18, at least on i386 before the final Woody release? Eh? There's nothing particularly difficult about .18 is there? I'm expecting at least one more release of boot-floppies, probably mid-March to include all the last minute bugfixes, and the current kernel. I'm not really expecting us to need anything more than that. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey msg16264/pgp0.pgp Description: PGP signature
alpha and sparc boot-floppies
Hi Guys, ] woody/main/disks-alpha/3.0.17-2001-11-20 ] woody/main/disks-arm/3.0.19-2002-02-12 ] woody/main/disks-hppa/3.0.19-2002-02-17 ] woody/main/disks-i386/3.0.19-2002-02-07 ] woody/main/disks-ia64/3.0.19-2002-02-17 ] woody/main/disks-m68k/3.0.19-2002-02-09 ] woody/main/disks-mips/3.0.19-2002-02-12 ] woody/main/disks-mipsel/3.0.19-2002-02-17 ] woody/main/disks-powerpc/3.0.19-2002-02-09 ] woody/main/disks-s390/3.0.19-2002-02-09 ] woody/main/disks-sparc/3.0.16-2001-10-27 Pick the odd architectures out. Be aware that if alpha and sparc boot-floppies aren't uploaded in a timely fashion (and 3.0.19 hasn't been), then any bugfixes y'all may need before release just plain won't be happening. Please upload and test new boot-floppies _right now_. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey msg16249/pgp0.pgp Description: PGP signature
Bug#132350: basedebs.tgz not gzipped
On Mon, Feb 04, 2002 at 08:14:48PM -0700, Chris Tillman wrote: I hope I'm submitting this for the right package. I tried installing Woody from floppies on Feb 2, 2002. The installer didn't like the base disks (it couldn't recognize the first disk as a base disk). I used dd to move all the disks over and catted them into a basedebs.tgz (first checking that this produced the exact same result as basedebs.tgz). Using the basedebs.tgz resulted in the installer complaining that gunzip failed. I gzipped the file and everything worked. According to a message from aj, this should be fixed by now. (That is, the basedebs.tgz on the mirrors should be a real .tgz) Actually, it should be basedebs.tar. (The stuff inside it is already gzipped so it's not worth gzipping again). If you verify it's OK, could you just send a message to [EMAIL PROTECTED]? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k basedebs.tgz broken
On Sat, Feb 02, 2002 at 11:02:28AM +0100, Martin Michlmayr wrote: * Anthony Towns [EMAIL PROTECTED] [20020202 11:58]: The installer (from 3.0.18-2001-12-21) doesn't seem to cope (there's an error flashing on the main screen but no details I've no idea what dbootstrap expects here. debootstrap expects either /path/to/foo.tar or /path/to/foo.tgz. debootstrap probably breaks because the file is called .tgz but is actually a tar archive. Arrgggh, that was stupid. Okay, should be fixed next mirror pulse. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k basedebs.tgz broken
On Fri, Feb 01, 2002 at 08:49:12PM +0100, Michael Schmitz wrote: it seems the current m68k basedebs.tgz (as found at) http://ftp.uni-erlangen.de/pub/mirrors/debian/dists/testing/main/disks-m68k/base-images-current/ is a plain tar archive, uncompressed. (Previously, it was gzip compressed, at least the copy I have from around April last year). April last year? Did basedeb tarballs even exist then, or are you thinking of a base tarball? The installer (from 3.0.18-2001-12-21) doesn't seem to cope (there's an error flashing on the main screen but no details logged on console #3). I've no idea what dbootstrap expects here. debootstrap expects either /path/to/foo.tar or /path/to/foo.tgz. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Woody installation problems
On Mon, Jan 28, 2002 at 08:52:04AM +0100, Jan-Hendrik Palic wrote: On Mon, Jan 28, 2002 at 12:18:56PM +1000, Anthony Towns wrote: TMPCOMPONENTS=$(sed -n 's/Components: *//p' $reldest) However (*2) the Release file for woody contains: Archive: testing Component: main Origin: Debian Label: Debian Architecture: i386 You're looking at dists/woody/main/binary-i386/Release; you should be looking at dists/woody/Release (which is what debootstrap's looking at). Ok .. but does this make sence, to have dists/woody/Release Components but in dists/woody/binary-i386/Release Component? *shrug* They're different files for different (albeit related) purposes. I saw several woody installations, which stops at the error: Malformed Release file. I think, this is a big problem, it makes woody uninstallable for me Does anyone has a clue, where the problem might? What's your mirror? Are you sure you're giving it the right path? (Is there a mirror selector in b-f's these days, like there is in base-config?) What does the Release file there look like? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ msg15180/pgp0.pgp Description: PGP signature
basedebs
In theory, basedebs should appear in woody/main/disks-*/base-images-current/ after today's mirror pulse. However, exactly when that'll happen is up for some debate, so give it a couple of days. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Woody installation problems
On Sun, Jan 27, 2002 at 01:13:25PM +0100, Martin Schulze wrote: Somebody else already mentioned the Malformed release file bug. I'm not sure what the cause of this is. A potential fix included an rm Release, maybe not the best solution. However, a couple of lines before this snippet is found: TMPCOMPONENTS=$(sed -n 's/Components: *//p' $reldest) However (*2) the Release file for woody contains: Archive: testing Component: main Origin: Debian Label: Debian Architecture: i386 You're looking at dists/woody/main/binary-i386/Release; you should be looking at dists/woody/Release (which is what debootstrap's looking at). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Things we need from sid
On Thu, Jan 24, 2002 at 07:59:52PM +1100, Herbert Xu wrote: Anthony Towns [EMAIL PROTECTED] wrote: kernel-image-2.4.17-bf2.4 pcmcia-modules-2.4.17-bf2.4 So are these an official part of boot-floppies? Should they be being (co?)maintained by Herbert to keep them in sync with the other kernels? I would be happy to do so if someone can show me why we really need 2.4 boot floppies on i386. So far, the only reasons I've seen are: 1. Support for new hardware. 2. Support for ext3/reiserfs. The main part about using 2.4 for this rather than 2.2+patches is just that: it's better to use an integrated kernel than maintaining our own patches if we can. RAID is also one of the things you can only do with this flavour (and the flavours it's meant to replace). Is there any particular reason to prefer the 2.2+patches flavours if the 2.4 flavour is working? 3. Better support for auxiliary hardware such as sound cards. 4. Avoiding people whining about how Debian still lives in the dark ages by only shipping a 2.2 kernel. Yes, I realise these people are wrong on a number of counts (2.4 isn't really stable enough for us, for a start; and that there's a huge difference between not installing it by default and not shipping it), but it'll still probably be the number one complaint if we don't have a 2.4 b-f's flavour. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#130482: 3.0.19 show-stoppers
On Thu, Jan 24, 2002 at 06:38:40PM +0100, Stefan Gybas wrote: On Thu, Jan 24, 2002 at 09:06:17AM -0800, Matt Kraai wrote: I object. We should fix, rather than disable, it. Could you please try the following code instead? Sorry, I won't have access to the s390 systems until Monday so I can't do this now. I have uploaded the NMU for i386 and s390 to incoming - if you or anybody else objects, just remove the files there. Uh. You didn't file bugs for the things you fixed, nor did you send a patch to the BTS. That is incredibly poor form. debootstrap 0.1.15.x did not contain the initctl patch and worked fine It worked fine on some architectures, and not others. It already took me several hours to find the problem so I'm not very interested in spending even more time trying different variants of this hack. If this is your attitude to the package, then you shouldn't be NMUing the package. Either get it right, or don't do it at all. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ msg15100/pgp0.pgp Description: PGP signature
Re: Things we need from sid
On Wed, Jan 23, 2002 at 01:59:10AM +0100, Marcin Owsiany wrote: Here's the list of packages we need from woody to _build_ successfully. Probably more are needed to make the resulting b-f work correctly. kernel-image-2.4.17-bf2.4 pcmcia-modules-2.4.17-bf2.4 So are these an official part of boot-floppies? Should they be being (co?)maintained by Herbert to keep them in sync with the other kernels? debootstrap debootstrap | 0.1.16 | testing | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc pcmcia-modules-2.2.20* packages pcmcia-cs (library reduction fails with 3.1.22-0.1potato) These need to be built properly on various arches. Hrm. I guess the out of date i386 ones (-2.4.14-i386, -2.4.13-386 and -2.2.0-ext3) aren't needed. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#118997: Related issue to 118997
On Wed, Jan 23, 2002 at 08:38:30AM -0800, Matt Kraai wrote:
Index: netconfig.c
+ if ((p_file = fopen(target_path(NC_INTERFACES_FILE), a))) {
+fprintf(p_file, \n# The first network card - this entry was created during the
Debian installation\n);
+fprintf(p_file, # (network, broadcast and gateway are optional)\n);
+fprintf(p_file, auto %s\n, netinterface);
+fprintf(p_file, iface %s inet static\n, netinterface);
+fprintf(p_file, \taddress %s\n, IP4tostr(prtbuf, ipaddr));
@@ -803,18 +726,11 @@ int write_dhcp_network() {
-#ifdef PCMCIA
- if (has_pcmcia) {
-write_pcmcia_network();
- } else
-#endif /* PCMCIA */
+ p_file = fopen(target_path(NC_INTERFACES_FILE), a);
+ fprintf(p_file, \n# The first network card - this entry was created during the
Debian installation\n);
+ fprintf(p_file, auto %s\n, netinterface);
+ fprintf(p_file, iface %s inet dhcp\n, netinterface);
+ fclose(p_file);
return 0;
}
The auto line probably shouldn't appear for PCMCIA cards. (auto means
configure this interface at bootup, whereas PCMCIA cards are only
configured when the card's inserted)
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
The daffodils are coming. Are you?
linux.conf.au, February 2002, Brisbane, Australia
--- http://linux.conf.au/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [i386] introducing a kernel 2.4 installation flavor
On Tue, Jan 15, 2002 at 01:02:12AM +0100, Eduard Bloch wrote: Contras: - see above. Someone may say, 2.4.x is less stable. Then they can use one of the 2.2.x boot-floppy flavours that we'd still be building, can't they? * bf2.4 with kernel-image-2.4.17-bf2.4. This package is created by me with following assumptions: - merged from current vanilla, udma100-ext3 and reiserfs - have at least the same drivers as reiserfs flavor - be at most as big as udma100-ext3 - with framebuffer and i18n What flavours would this leave us with, and what machines would they be for? I was imagining something like: plain - 2.2, boots everywhere, lots of drivers, a bit complicated safe - same as plain, but works even more places idepci - 2.2, boots on all modern equipment with IDE, easy compact - 2.2, boots on all modern equipment with SCSI or IDE, easy 2.4 - 2.4, works on modern machines, handles ext3+reiser, easyish Hrm. Is there really any point keeping safe and plain separate? Is the safe, slow and stupid version of SYSLINUX really so slow or stupid that we need a separate set of disks just to avoid it? Also, is there much real difference between idepci and compact? Can idepci do anything compact can't, or is it any easier to use? If not, can it be dumped for compact? Having works-on-modern-systems (2.2.x), works-on-modern-systems (2.4.x) and works-everywhere (2.2.x) flavours and nothing else would be fairly simple and elegant, if it can be done without too much hassle. In any case, assuming we're keeping all the 2.2 flavours we currently have except for ext3 and reiser, I think that sounds pretty good, and I can't see how it'd cause problems for anyone. Cheers, aj, who was hoping someone would do this -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ msg14913/pgp0.pgp Description: PGP signature
Re: [i386] introducing a kernel 2.4 installation flavor
On Wed, Jan 16, 2002 at 07:46:10PM +0100, Eduard Bloch wrote: Yes. After commiting, these will be build: vanilla, safe, idepci, compact, bf2.4. Sounds pretty good to me, then. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i]: debootstrap udeb?
On Sat, Jan 12, 2002 at 02:26:38AM +0100, Tollef Fog Heen wrote: Have you or anybody else looked into making an udeb of debootstrap for installing the base system using debian-installer? Not afaik. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages required in installation (Re: apt-utils in debootstrap)
On Wed, Jan 02, 2002 at 01:22:11PM +0900, Junichi Uekawa wrote:
The following script checks for validity of priority/section (and
I think this is what should be done, please tell me if something looks wrong) :
for A in $(/usr/sbin/debootstrap --arch $ARCH --print-debs woody); do (apt-cache
show $A | awk '/^Package:/{package=$2} /^Section:/{section=$2}
/^Priority:/{priority=$2} END{print package section priority}') ; done | awk
'{if ($2 != base $3 != required) {print Bad base program: $0 }} '
I believe, if the section is base, or is required priority,
it should be found in the first CD. Would important suffice?
No, base cannot be determined by priorities and sections. You need to
get debootstrap, and run debootstrap --print-debs woody to get a list
of packages debootstrap expects on the first CD. If those packages aren't
on the first CD, it's a bug in the CD.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.
The daffodils are coming. Are you?
linux.conf.au, February 2002, Brisbane, Australia
--- http://linux.conf.au/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [again] basedebs.tgz: Supported or not?
On Wed, Nov 21, 2001 at 02:13:55AM -0500, Adam Di Carlo wrote: Right. I was thinking it should be generated (and not by default) by building debootstrap a special way, with ByHand entries and a changelog and all that. I talked to AJ about that, he provisionally ok'd but he should get approval or at least asked about any such changes (being also an archive maintainer). Right. I expect to make a maintainer upload of debootstrap sometime this week which'll do that. At that point, we/I'll just build basedebs tarballs on auric regularly. I belive you want to split it into 1.44M disk images as well. How do you want this done? Just split, so they can be catted back together to make the original file, or something more complicated (so you can verify the disks are put in in the right order)? Does anyone care about 1.2MB disk images, or anything else? Do we want this done for all architectures, or are disk images unnecessary for some (s390, maybe)? I guess something like: dists/woody/main/ disks-i386/ current/ base-images/ basedebs-3.0.tar.gz basedebs-3.0-1440.001 .. basedebs-3.0-1440.0xx is a reasonable way to lay it out. Is it reasonable to expect that people will be able to handle the long filenames and the multiple .'s? It kind of sucks to add a large tarball to the mirrors of what is essentially just the .debs they are already mirroring, plus a little extra data, but I don't see a way around it. Well, it's not *that* large. Well, just for the benefit of the CD folks, if they are planning to provide the disk images on the CD. Doing that was the consensus we arrived at -- e.g., for someone who has a CD and floppy at one computer but only a floppy and no network at another. Or for someone with a network connection and a floppy at one end, but no network at the other. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it. C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who can't deal with deconstructionist humor. Code Blue. -- Mike Hoye, see http://azure.humbug.org.au/~aj/armadillos.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aptitude rather than dselect for Woody, Please?
On Mon, Nov 19, 2001 at 03:25:20PM -0600, Chris Lawrence wrote: Is there any way the list for each release could get automatically exported into a flat file somewhere in the debootstrap package, say $ /usr/sbin/debootstrap --arch alpha --print-debs woody woody-i386 Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it. C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who can't deal with deconstructionist humor. Code Blue. -- Mike Hoye, see http://azure.humbug.org.au/~aj/armadillos.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: teamwork (was Re: #103302 ask permission blah blah)
On Sat, Nov 17, 2001 at 09:52:07PM -0600, Adam Heath wrote: On Sun, 18 Nov 2001, Glenn McGrath wrote: To work efficiently as a team we have to be able to trust each other to perform our own tasks. How can we trust someone who isn't one of us? Or, to put it in a way that doesn't sound quite so xenophobic, why should we trust someone who refuses to go through our fairly trivial identification process (and thus avoids the accountability it attempts to establish), and who refuses to go through the tasks and philosophy checks to make sure he can actually function as a part of the project? Ethan's quite a fan of bug terrorism (continually upgrading or reopening bugs the maintainer disagrees with) and, apparently, NMU terrorism (threatening to either NMU your package, or hacking into your package from another package). Especially the latter isn't something that helps Debian development. But hey, politically inspired apoplectic fits is the reason everyone joins Debian, isn't it? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it. C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who can't deal with deconstructionist humor. Code Blue. -- Mike Hoye, see http://azure.humbug.org.au/~aj/armadillos.txt msg12625/pgp0.pgp Description: PGP signature
