Re: Status of the shadow package
I fail to see the problem here. The shadow package has needed a lot of translation work. You've done that work, you've done the NMUs. Everyone is happy. If you were annoyed that it took too long to deal with translation NMUs then you probably should have asked for permission to make arbitrary 0-day NMUs for translation purposes. But as far as I can tell, Karl has dealt with the non-translation problems in a reasonably timely manner over the past year, although perhaps not as fast as you would like in the last two months. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
>>>>> "Christian" == Christian Perrier <[EMAIL PROTECTED]> writes:
Christian> Quoting Sam Hartman ([EMAIL PROTECTED]):
>> If you were annoyed that it took too long to deal with
>> translation NMUs then you probably should have asked for
>> permission to make arbitrary 0-day NMUs for translation
>> purposes.
Christian> Hmmm, wel I think I did ask. At least, I announced all
Christian> NMU's and took the lack of answer as an agreement.
Christian> So, it may seem to you there's no problem. However, I'm
Christian> not comfortable in doing NMU's without explicit
Christian> agreement and keep this situation going on. This was
Christian> basically the reason I mailed again Karl and you.
OK. I have no authority with the package so we're both waiting for
Karl to deal.
It's my opinion though that your NMU work is very easy to integrate
because you generate single patches that can be cleanly applied. It
seems like one of the two following ideas would work going forward:
* Give you permission to upload translations as NMUs immediately.
* Move the repository to alioth or something else where you can be
given commit access.
If we don't here from Karl on his thoughts on these issues within a
day or two, I'll ask him in person to read this.
--Sam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#923091: That merged-usr is mandatory is RC
> "Ian" == Ian Jackson writes:
Ian> (sending this because I got the release team address wrong) Ian
Ian> Jackson writes ("That merged-usr is mandatory is RC"):
>> Control: severity -1 serious
>>
>> In #923091, Guillem (with dpkg maintainer hat on) asks for a
>> base-installer option to allow installing buster without
>> merged-usr.
>>
>> Guillem filed the bug as `wishlist' but given the controversy it
>> seems to me that it should be RC if for no other reasons than
>> social cohesion.
>>
>> CCing the TC FYI (they have already been involved in merged-usr
>> debates via #914897) and the release team, in case they have an
>> opinion. FAOD I am not a maintainer of base-files but AFAICT the
>> base-files maintainer has not expressed an opinion about
>> severity.
I've been debating doing this, but continue to believe that it's
important after several days of pondering. So, per constitution 5.1
(2), I'd like to explicitly lend support to the idea that it would be
really good if we provide our users a way to install buster without
merged /usr. I think that if we do not do so now, we need to be open to
the possibility that if users are stymied in doing their work, we will
need to do so in a buster point release even if we would not normally
add something some might consider a feature in a point release.
I'm not speaking to whether I think it should be RC or even whether an
expert only option is good enough.
I am simply saying that with my DPL hat on, I think this issue is
important enough it deserves real consideration.
I think that the TC's ruling and ongoing experience suggests we have
carefully considered how we want to approach merged /usr for our own
internal work developing Debian and come to a position that at least for
the moment seems to be working.
What I'm most concerned about is people who use Debian to develop
software they plan to use on Debian but who are not part of Debian.
Examples of this include people within organizations who build programs
to distribute within their organization. People who build upstream
programs using configure from source. That sort of thing.
These people may not use packages. These people may not use chroots.
They are our users; they are our priority. Even if we believe using
chroots or containers would be better for them, I don't think we should
force people into changing their build processes.
I don't think we have a good idea how big the impact will be for these
users, and so, I think we should be conservative.
If we don't choose to be conservative, I think we should be extra
willing to revisit our decision if we find we are wrong.
Again, all I'm saying is that I think this issue is important enough to
consider seriously. I am not in a position to balance this issue
against other things before us.
I'm speaking as the DPL because I'm trying to consider something that is
a project level concern. However, this statement has no actual force as
clearly spelled out in the constitution.
I'm speaking in the hopes of getting people to take a moment, think
about this issue and come to their own conclusions.
--Sam
signature.asc
Description: PGP signature
Bug#923091: That merged-usr is mandatory is RC
> "Ivo" == Ivo De Decker writes: Ivo> Hi, Given that there is still discussion about the impact of Ivo> merged /usr at this very late point of the freeze, I think Ivo> having merged /usr by default for new installations should be Ivo> reconsidered. What discussion are you seeing other than this discussion here? Things seem to have been fairly quiet on the merged /usr front since the TC decision. What am I missing?
Bug#932628: Multiple Issues Installing Buster 10.1R0 DVD 1 onto virtualbox with mac hypervisor
package: installation-report Hi. Figuring out which package a bug belongs on in DI is harder than I had time for. I figure writing up experience is more valuable than simply ignoring the problem. Andy copied because he was interested when I talked to him in person. My friend Matt (copied) was trying to install Buster 10.0R0 onto a VM running on Virtualbox on a Mac using amd64 DVD 1 as installation media. He was proceeding fine without help until he got to selecting software to install. At that point, selecting software to install failed and gave him an option to retry. Retrying didn't help. Issue 1: What was displayed to the user gave no hint (other than to look at logs) as to what was going wrong. Issue Mac1: It's hard (Matt, Ian Jackson and I couldn't figure out how) to send shift-pageup from a mac keyboard through virtualbox to DI. There was enough random cruft that the important part of the apt error message had scrolled off the top of the screen on ctrl-alt-f4. We tried more /var/log/syslog on a console, but more in DI isn't really powerful enough to have an obvious way to get to the bottom of the file and scroll back, which is almost always what you want when something fails. What was apparently happening is that the Debconf network had two levels of cashing HTTP proxy that provided corrupted copies of the linux-image-amd64 from security.debian.org (well, really the actual image not the metapackage). Apt was complaining because the downloaded checksum didn't match the expected checksum from the package file. Apt is of course correct we didn't want to install that kernel, but DI could have made the error much more clear. Issue 2: There was no obvious way to select https mirrors for security.debian.org. In this environment, I strongly believe that would have fixed the problem. Issue 3: Matt got called off to do debconf video team stuff and we resumed the install on another network much later. Matt did run reconfigure the network. However, the base system was already installed, and /target/etc/resolv.conf had already been populated. So, since the nameserver addresses had changed we could not find security.debian.org or deb.debian.org and selecting software to install failed yet again. DNS resolution is another failure case where the user shouldn't have to look at ctrl-alt-f4. At least in this case, the error hadn't scrolled off. We worked around by copying /etc/resolv.conf into /target/etc in a shell. Issue 4: While Matt's mac was suspend (hypervisor suspended), time passed. The VM running DI didn't notice this. As a result, wall time had progressed by about 4 hours beyond what DI expected. The release file on security.debian.org was not yet valid, so security updates were not installed and DI left security.debian.org commented out in the installed system. Issue 5: The DVD apt-cdrom source got left in /etc/apt/sources.list. Some people may want this. I think a lot of people do not. I don't think users should be expected to hand edit /etc/apt/sources.list to recover from this situation. signature.asc Description: PGP signature
Re: Upcoming changes to Debian Linux kernel packages
> "Bastian" == Bastian Blank writes: Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote: >> On 25/09/2023 00.50, Bastian Blank wrote: >> > Already built modules remain until someone deletes it. So you >> can also > switch back to the still installed older kernel >> version and it will have > the still working module available. >> Assume I have Linux 6.6 and a third-party gpu driver module >> installed (so there are dkms and the Linux 6.6 headers as well) >> and everything is working fine. Then I upgrade the system, which >> brings Linux 6.7 (along linux-image-6.6 which is kept installed) >> and a new version of the gpu driver (which adds support for >> 6.7). So the old gpu module for 6.6 gets removed and a new one is >> built for 6.7 only (since there are only 6.7 headers now). Bastian> Ah, here lays the missconception. No, the 6.6 ones are not Bastian> removed. Why should they be? The system knows it can't Bastian> rebuild them. Bastian> If the current implementation would remove them, it is a Bastian> problem there, not in the concept. I still think it would help if you would work more on articulating what problem you are trying to solve with the linux-headers versioning change. I have read multiple versions of this proposal, and your follow-ups, and I still do not understand what is prompting the linux-headers change. My intuition mirrors others in the conversation that it is problematic to support multiple kernel versions without also supporting multiple header versions.
Re: Upcoming changes to Debian Linux kernel packages
> "Bastian" == Bastian Blank writes: Bastian> The same as now: nowhere, because those packages have been Bastian> removed from the archive already. Bastian> And sadly you did not answer the question why a second Bastian> degree error must not be worse then a worked around first Bastian> degree error? I'll admit that I find that phrasing difficult enough that I had to read it a couple of times and I'm still not sure I've got it. Let me see if I understand what you are saying. 1) kernel headers will be removed from the archive. So people complain if they have an old kernel and wish to get kernel headers for it, but those headers have been removed. 2) If the kernel header version changes but the kernel header package name does not change (version changed but not uname -r in the new scheme?), you can have what you think is the right kernel headers but they do not work with the binaries you have installed. 3) you can run into trouble between testing and backports. I think that's what you mean by the first-level error. If not, I'm still confused. In the second level error case you are talking about is: 1) there is a regression in the kernel 2) someone needs kernel headers for an old kernel they want to downgrade to. I don't actually see how this is a second level error. It appears to be a different first-level error (a regression), and the downgrade appears to follow naturally from that. You point out that someone may not be able to get kernel headers for the downgraded kernel. a) They might. In the window between a new kernel being introduced into unstable and the same kernel being introduced into testing there is an old kernel available with kernel headers. Similarly if someone needs to downgrade as far as stable, there is a kernel with headers available in stable. B) They might already have headers installed. Imagine someone who installs headers at the same time they install the kernel. Unless they managed to upgrade the same version of their kernel without also upgrading their headers, they will still have headers. They can still build modules against that kernel, either because they installed a new dkms package, or because one of their dkms packages upgraded. I think what you are saying is that 1) the current system is fragile: sometimes you want a kernel headers that is not available and sometimes you have version skew between the kernel headers and kernel even though you have both installed. 2) In your system, fewer things are possible, but the combination that is possible is more likely to work. And I think people's response is that they care enough about some of the things you are breaking that they are willing to accept the fragility. Bastian> -- Each kiss is as the first. -- Miramanee, Kirk's wife, Bastian> "The Paradise Syndrome", stardate 4842.6
Moving netboot debian-installer binaries out of main?
> "Steve" == Steve McIntyre writes: Steve> Hi all! [ I've also blogged about this - see Steve> https://blog.einval.com/2022/10/02#firmware-vote-result ] Steve> I'm assuming that there will be no surprises and Kurt will Steve> shortly confirm the result that devotee reported already Steve> [1]. :-) Steve> We have quite a few things to do now, ideally before the Steve> freeze for Debian 12 (bookworm), due January 2023 [2]. This Steve> list of work items is almost definitely not complete, and Steve> Cyril and I are aiming to get together this week and do more Steve> detailed planning for the d-i pieces. Off the top of my head Steve> I can think of the following: Steve> If you think I've missed anything here, please let me and Steve> Cyril know - the best place would be the mailing list Steve> (debian-boot@lists.debian.org). If you'd like to help Steve> implement any of these changes, that would be lovely too! So, for each architecture there are packages in main like debian-installer-12-netboot-archname I'm assuming the plan is to include firmeware into the initrds for these images. As an example, you'd probably want GPU firmware in the gtk images and probably want sound firmware:-) Also, presumably any network firmware. We revised the social contract by adding: >The Debian official media may include firmware that is otherwise not >part of the Debian system to enable use of Debian with hardware that >requires such firmware. So, the official installer images can include the firmware. But as far as I can tell we did not either 1) revise the DFSG or 2) revise the definition of the main section of the archive. So at least in my reading, these binary packages will no longer qualify for the main section of the archive. I think that technically this is probably not a big deal, unless we get into a situation where for example we decide we want a source package in main building binaries in wherever we decide to move these netboot images. Also, I guess there's a question of whether we move the images to non-free or non-free-firmware. Presumably non-free-firmware would make them more available. --Sam signature.asc Description: PGP signature
Bug#267428: Reassigning
severity 267428 critical reassign 267428 silo thanks Hi. I don't normally process installation reports, so forgive me if I did something wrong. However since this is a critical bug I wanted to make sure it was tracked in the right place. This bug is critical because sarge has a significant regression in functionality over woody. Woody's silo can work on ultra 5's and other similar machines while the sarge silo cannot. I believe this issue is at least RC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bastardizing packages or stepping down
> "Adam" == Adam D Barratt writes: Adam> Hi, Making no comment on the remainder of the mail: Adam> On 2015-03-05 10:38, Michael Tokarev wrote: >> And since I can't do my work, I'm stepping down from being >> busybox maintainer, and am kindly asking the release team to >> remove my name from debian/control file in busybox, so that >> people don't blame me for things I can't do. Adam> I don't believe it would be appropriate for us to do so. We Adam> have no control or say in who maintains packages (beyond that Adam> available to any other DD or interested contributor). michael, I'd like to ask if I'm hearing you correctly. So, what I'm hearing is very strong frustration. You had hoped that you would have the power to produce a package that you'd be happy being responsible for. However you don't believe that you have that power; you're saying that changes you consider essential to creating a busybox you're comfortable being responsible for are rejected. Am I hearing you correctly? Adam, let's assume for the moment I've got that right. I'm trying to connect with the frustration I'd feel if I were told that I didn't even have the power to distance myself from something I couldn't in good conscious claim to support. I hope that there's some way that michael can approach stepping away from the package in jessie if he wants to. If what you're saying is that his proposed mechanism for doing that is the wrong one, would you be willing to help him out and suggest a mechanism you believe to be more appropriate? (Perhaps you'd approve an ublock for an upload that simply changed maintainer to debian-qa?) If what you're saying is that you see no mechanism for him to step away from a package he no longer feels he can maintain because he and the release team disagree with the desired contents of that package in Jessie, then I respectfully ask you to reconsider that position. That sort of thing would likely drive me away from the entire project, not just one package. Micahel, one final question to you. Are you firmly committed to the path of stepping away from busybox maintenance, or would you be willing to re-evaluate that decision after we see what comes of your request for understanding? thanks for your consideration, --Sam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014be9d67c2a-235bd750-20d6-4195-86ca-98841d13dc39-000...@email.amazonses.com
Re: bastardizing packages or stepping down
>However, I still really want to understand that unknown reason >why all this happened, why it is so difficult to accept a >working package than to do more bastardizing work, why it is >smart to reject good stuff and to do absolutely unnecessary work >(double work with maintaining 2 version and applying patches >wchich aren't needed for debian as a whole, not only for jessie). >This is the reason I'm Cc'ing ctte@, but without much hope really, >due to already mentioned reason. Hi. So, you're involving the TC because you're hoping to better understand why your unblock was not approved? How are you hoping the TC can help? Here are some options I see: * Some folks on the TC are fairly goodat release engineering and have been involved in this either in Debian, for other projects or for other distributions. We could look over the situation and try to help you understand why someone might decide not to approve those unblocks. Since we weren't the one acting on the request we can give you an understanding of why someone might think that way, but not why they did. * Alternatively you could be asking for help engaging with the release team and Cyril to explain the actual reasoning involved. Or perhaps you're asking for something else. Thanks for helping me understand what you're hoping the TC can provide. Sam, who is not currently on the TC, but seems headed in that direction when paperwork clears. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014beef77d19-5cd761ec-20c8-4442-a379-2136c8732672-000...@email.amazonses.com
Re: bastardizing packages or stepping down
Hi. I'm sorry it has taken a while to write back to you. I asked how the TC could help and was confused when I read your message. I provided a couple of options how we might be able to help and you neither selected one of my options nor provided your own. So, I wasn't sure what you were looking for. I've done my best and I hope that this helps you understand what's going on. I've decided to give my analysis of someone on the release team might reject your unblock request.This may not be the actual reason the release team (RT) acted as they did. I've never been on the RT, but I have taken on a similar role for other much smaller projects. I got input from other members of the TC in preparing this response, but these words are my own and this definitely doesn't represent a statement From the TC as a whole. In doing that I've read #771208 but not the other bugs. If I were on the RT and processing your unblock, I'd read the full unblock bug, and read enough of the referenced bugs to understand briefly the technical issue, but perhaps not enough to understand why someone thought they were important. This is an issue where I think reasonable people might disagree. I don't actually know which decision I would take were I on the RT; it would depend on the tradeoffs I'll discuss below. I appreciate that busybox-static is important to you. It's something you've worked on a lot, it's something you use and depend on. However, busybox-static is not as important to the project as a whole as busybox. Busybox-static is one of several debugging/recovery tools. We also have live DVDs, bootable media, alternate chroots/volumes to boot from. We could release with an entirely broken busybox-static. we cannot release with a busybox that is broken in a manner that breaks D-i, initramfs, etc. You claim that the changes do not affect the resulting binaries. Based on your analysis, you claim that if the busybox source package builds at all, your changes cannot affect whether the main busybox binaries function. However, the RT is likely to care as much or more about whether something builds as whether there is some bug introduced into the binary. Having core packages that build all the time, whenever you make a change to them, whenever you make an NMU, whenever you make a security fix is one of the highest priorities of doing release engineering for a large project. During the freeze, if I had to pick between a busybox that build all the time but sometimes produced a broken busybox-static and a busybox that sometimes failed to build because it could not produce a busybox-static I'd pick the potentially broken busybox-static. being unable to build a package when you need to make some change blocks forward progress. It can also cascade and affect forward progress on other packages. Changing the conditions under which a package will successfully build frequently has unexpected consequences. We might find people trying to build d-i in their own build environments face breakage because their libc is not up-to-date. That again can break things for people doing various kind of automated product builds and automated testing based on what's supposed to be a frozen release. I might be willing to accept the change if I were convinced that it would not break things for Debian. However, according to your mail you were running into cases where the buildds were not up-to-date. There is of course a counter argument, and it's the argument that I'd use if I were to decide to accept the change. It's frustrated to have a build that sometimes produces valid output and sometimes doesn't. Every few times when we do a security upload we'd run into a case where busybox-static is broken. And so we'd have to do yet another bin-nmu to fix it. That's frustrating in its own way. You claimed that the patch was easy to review, and that it obviously didn't change the binaries for busybox. I did a review of the unblock, and i didn't find the patch particularly easy to review, nor was I able to prove without doing a bit more work that it failed to affect the binaries for busybox. The RT has a bunch of stuff on their plate. If an unblock is not obvious and the decision is questionable it's more likely to be rejected. The mail you wrote to the TC, particularly the technical summary was really well done. If the unblock hedar looked a lot like that mail, I would have been more likely to accept the change had I been making the decision. Here are areas that concerned me when reviewing the unblock: * You talk about how multiple iterations were required and how this breaks hurd. In general, I have found that these sort of build changes are very tricky to get right and do tend to have unexpected consequences. You let me know that it took you a while to get this one to a point where you believe it is right, and even that has broken one thing that you know of. You would be better off spending at least as much space exp
Re: Full Debian install impressions and facts
Speaking both as a user and developer I'd like to thank you for going through this install and writing up your results. Creating a good initial user experience is important for Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tasks policy
> "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes: Anthony> --HG+GLK89HZ1zG0kk Content-Type: text/plain; Anthony> charset=us-ascii Content-Disposition: inline Anthony> Content-Transfer-Encoding: quoted-printable Anthony> On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin Anthony> wrote: >> err, does this break the use of tasks with apt-get later on? >> I've found it very useful to do (for example) "apt-get install >> task-x-window-s= Anthony> ystem" Anthony> Possibly. task-x-window-system isn't really the greatest Anthony> example of a task, though. So, I think that support in tools besides tasksel is critical to this policy proposal being useful. I don't like the idea of having frontend-specific fields being mandated by policy and don'tt see a need for tasksel to be a distinguished frontend. I understand why apt-get might not want to support or reverse-recommends, but I think that the actual frontends should support this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tasks policy
>>>>> "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes: Anthony> On Mon, May 07, 2001 at 07:32:10PM -0400, Sam Hartman Anthony> wrote: >> So, I think that support in tools besides tasksel is critical >> to this policy proposal being useful. I don't like the idea of >> having frontend-specific fields being mandated by policy and >> don'tt see a need for tasksel to be a distinguished frontend. >> I understand why apt-get might not want to support or >> reverse-recommends, but I think that the actual frontends >> should support this. Anthony> Remember: the point of tasks is to make the initial Anthony> install simpler, so that people can get started on Debian Anthony> without having to wade through dselect. Yes, that was the original point of tasks. However, tasks are also used today by people who want to get a set of software installed after the initial install. I know many Debian users who expect to be able to do apt-get install task-blah long after the initial install. While I was not involved as a developer at the time this discussion happened the last time, I saw a major advantage of tasks over profiles that I could install new tasks as I found I needed them rather than having to reinstall a system and select a new profile. We will never fully be able to support the users who have grown used to being able to apt-get install tasks; you have convinced me of that. However policy's primary purpose seems to be to document existing practice and I don't think that we are doing that very well by dropping support for the existing practice of usefully adding tasks after the initial install. Yet I understand we have finite time. Would it be reasonable to get tasksel install task-name added as a command line invocation for people to use in scripts and to have the policy text say that frontends that handle recommends should handle tasks? I'm not particularly concerned about the specifics of the text, but I believe we must allow people an option to continue to use tasks in interactive scripts and we should encourage people to support it appropriately. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tasks policy
> "Anthony" == Anthony Towns <[EMAIL PROTECTED]> writes: >> Yes, that was the original point of tasks. However, tasks are >> also used today by people who want to get a set of software >> installed after the initial install. [...] >> Yet I understand we have finite time. Would it be reasonable >> to get tasksel install task-name added as a command line >> invocation for people to use in scripts Anthony> I'm not sure what scripts have to do with anything, but Anthony> adding a command line option is entirely trivial. So, it is very annoying to write a script to go into tasksel, move to the appropriate task, select it and go down to OK. If I want to install a task as part of some management script, I really do need a command line for it. Anthony> You Anthony> check the code out from CVS, or do an apt-get source, you Anthony> write the code, and you send it to Randolph. It doesn't Anthony> need discussion here. I resent the implication that I'm responsible for fixing any problem that I discover. I believe there is value in pointing out a problem report even if you don't have the resources to fix it. I believe that your proposal will break people who are installing tasks after initial install. I believe this is sufficiently common that we don't want to break this usage pattern. Either I'm right and we as a policy group have an obligation to make sure that we implement the change in a manner that does not break our users--this obligation existing regardless of whether I'm willing to go off and write code on this particular issue, or I'm wrong and I'm simply asking for a feature request. I'm sorry I don't have a good way to give you evidence on how common the usage pattern of installing tasks after initial install is. I've considered ways of getting this info, and the best thing I've found so far is asking users. >> and to have the policy text say that frontends that handle >> recommends should handle tasks? =20 Anthony> Not really. Frontends should do whatever their authors Anthony> deem appropriate and have time to implement. If you want Anthony> to send in patches, or write your own frontend, more Anthony> power to you. It's not policy's place to say anything Anthony> about what features you should and shouldn't implement Anthony> though. I disagree in general; there are cases where interoperability requires us to recommend or even require features be implemented. However, I agree that would be going to far. I believe that by describing parts of a protocol like the format of the packages file entry you are implicitly saing that users of that protocol should implement the parts of that protocol that are appropriate for their application. I think a footnote indicating that we are changing from a model where tasks depend on a lot of stuff to one where they reverse-recommend means that some users may still expect to be get useful results by installing a task package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: woody release task needs help: package priorities
While I agree there aren't that many people who use RCS directly, it is certainly one of those things I expect to be on a Unix system as a basic tool. I think you may break the expectations of people coming from other operating systems if you don't make RCS standard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Still no base tarball
> "Adam" == Adam Di Carlo <[EMAIL PROTECTED]> writes: Adam> Anthony Towns <[EMAIL PROTECTED]> writes: >> On Mon, Aug 20, 2001 at 11:14:55AM -0400, Adam Di Carlo wrote: >> > Adding basedebs.tgz to CD#1 would be a flagrant waste of >> space. >> >> Not much more so than having base2_2.tgz, >> images-1.20/base-*.bin, and images-1.44/base-*.bin, as well as >> the debs themselves, though. Adam> Well, sure, but in another way. With Potato install, we Adam> didn't have the technology to take CD#1 and "bootstrap" a Adam> base system into place. Adam> Now we do have that technology... If people eventually decide that including the base tgz on the CD takes up too much space, perhaps a shell script to generate it on any UNix system with tar and gzip could be included. I'm not sure whether including the base tarfile is a good idea or not. It seems it would be useful if you needed to do installs onto a lot of machines in an environment where you had no UNix machines and no machines you wanted to be Unix machines that had a CD. You could for example export the CD via Windows file sharing, copy the tarfile on the hard disks of the machines you wanted to install Unix on, and then boot those machines using floppies. If this is the only situation when you want the tarfile on the CD, then it's not worth it IMHO. Probably though the easiest way for those who want the base tarfile on the CD to make their point is to explain the situations in which it would be useful. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#121157: dhcp fails to notice that dhcp failed
package: boot-floppies severity: important version: 3.0.17-2001-11-18 If dhclient fails to get a lease, the boot floppies still assume that the network configured successfully. An error message is printed by dhclient which sleeps, but returns success to the script. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#121160: Network fails to reconfigure after one failed configuration
package: boot-floppies Using PCMCIA networking, if you try to configure the network after having already done so once, you get an error that some modules are already loaded. This was a problem because the DHCP failed to work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#673328: live-installer does not preserve /var/log; breaks freeradius
package: live-installer severity: normal If the live system includes the freeradius package, it fails to start freeradius because /var/log/freeradius fails to exist. As best I can tell something in the installer is clobbering /var/log because it's missing a lot of directories and files present in the squashfs image . I've not tracked down exactly what is going on; if it's not obvious to people familiar with d-i internals I'd be happy to try and do that. This was performed with d-i daily builds both from an image built today and from one built in December. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tslipfusdok@mit.edu
