Re: crediting debconf translators, revisited

Quoting sean finney ([EMAIL PROTECTED]): > hi all, > > some time back, i remember somebody asking what the proper way was to > credit translators who provided debconf template translations. the > consensus seemed to be that mentioning them in the changelog was > sufficient. > > not being satisfi

Re: dpatch and patching debian/rules

On Thu, Mar 31, 2005 at 03:11:13PM -0800, Thomas Bushnell BSG wrote: > Lars Wirzenius <[EMAIL PROTECTED]> writes: > > > /etc/issue is meant for the sysadmin to edit. It is free form > > text. /etc/lsb-release is not. > > All conffiles are there for the sysadmin to edit. Yes, but all conffiles ha

Re: dpatch and patching debian/rules

On Thu, Mar 31, 2005 at 09:07:17PM +, Michael Ablassmeier wrote: > >> what about `/etc/issue' to get this kind of information? > > > > Given that the sysadmin can and does edit it as they wish, that is > > pretty useless. > > yes, but this might happen to `/etc/lsb-release' too. The admin mi

Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm

On Sat, Apr 02, 2005 at 12:35:55AM +0100, Matthew Garrett wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > It doesn't need to be an exact date, but someting like > > "third quarter of 2005" or "mid-2008" would help to avoid situations > > like the sarge C++ transition that was too early [1] or

Firmware handling in Debian

On Thu, Mar 31, 2005 at 03:12:00PM -0800, Thomas Bushnell BSG wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > 1) Distribute the non-free firmware. Our users are happy. > > 2) Don't distribute the non-free firmware. Our users either download the > > non-free firmware from elsewhere (bad) or

Re: NEW handling: About rejects, and kernels

Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: >> Why? How does it benefit Debian if our users have to obtain firmware >> from somewhere else to make their hardware work? How does it benefit >> freedom if we imply that hardware with on-chip firmware is

Re: NEW handling: About rejects, and kernels

Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > >> When people actually get around to a decent "Free firmware" campaign, >> then I think we'll have a stronger argument for not distributing >> firmware. At the moment, the non-freeness of firmware isn't

Re: NEW handling: About rejects, and kernels

Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > >> 1) Distribute the non-free firmware. Our users are happy. >> 2) Don't distribute the non-free firmware. Our users either download the >> non-free firmware from elsewhere (bad) or replace their hardwar

Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm

Adrian Bunk <[EMAIL PROTECTED]> wrote: > Please check the facts: > > gcc 3.4 has a different C++ ABI compared to gcc 3.2/3.3 on _all_ > architectures [1]. I'm sorry, you're completely right. I must have been thinking of 3.3. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email t

Re: How to handle unreproducible RC bugs when the submitter is MIA?

Quoting Frank Küster ([EMAIL PROTECTED]): > Dear release team, > > #297181 is unreproducible, and the submitter has not answered to our > questions for a while. I am quite confident that this bug is really > PEBCAK, or more specifically a local misconfiguration, or some old > locally installed Em

Re: NEW handling: About rejects, and kernels

Scripsit Matthew Garrett <[EMAIL PROTECTED]> >> I'm ok with (1), provided we do it in the non-free archive. > This does present certain logistical problems for producing installers. Which ones? It would be a better course of action to solve those problems than to deliberately mislabel non-free

Re: NEW handling: About rejects, and kernels

On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote: > >> I'm ok with (1), provided we do it in the non-free archive. > > This does present certain logistical problems for producing installers. > Which ones? The fact that they need these firmwares to work. > It would be a better course of action

Re: NEW handling: About rejects, and kernels

Scripsit [EMAIL PROTECTED] (Marco d'Itri) > On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote: >> >> I'm ok with (1), provided we do it in the non-free archive. >> > This does present certain logistical problems for producing installers. >> Which ones? > The fact that they need these firmwar

Re: NEW handling: About rejects, and kernels

Henning Makholm <[EMAIL PROTECTED]> wrote: > Scripsit Matthew Garrett <[EMAIL PROTECTED]> > >>> I'm ok with (1), provided we do it in the non-free archive. > >> This does present certain logistical problems for producing installers. > > Which ones? non-free isn't part of Debian. Using loadable

Re: NEW handling: About rejects, and kernels

On Saturday 02 April 2005 08:31 am, Marco d'Itri wrote: > > It would be a better course of action to solve those problems than to > > deliberately mislabel non-free firmware as free. > > So you would have no objections to distributing firmwares packaged in > non-us [non-free?] on the debian install

Re: NEW handling: About rejects, and kernels

On Sat, Apr 02, 2005 at 03:01:34PM +0100, Matthew Garrett wrote: > non-free isn't part of Debian. Using loadable firmware is becoming > increasingly common in hardware design. In the fairly near future, most > modern hardware is likely to require it in order to allow installation. > > > It would

Re: NEW handling: About rejects, and kernels

On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote: > >> >> I'm ok with (1), provided we do it in the non-free archive. > >> > This does present certain logistical problems for producing installers. > >> Which ones? > > The fact that they need these firmwares to work. > So what? So it is a probl

Re: NEW handling: About rejects, and kernels

On Sat, Apr 02, 2005 at 02:39:57PM +0100, Henning Makholm wrote: > Scripsit [EMAIL PROTECTED] (Marco d'Itri) > > On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote: > >> It would be a better course of action to solve those problems than to > >> deliberately mislabel non-free firmware as free. >

Re: NEW handling: About rejects, and kernels

Scripsit Wouter Verhelst > On Sat, Apr 02, 2005 at 02:39:57PM +0100, Henning Makholm wrote: > > The installer images in question would of course need to be > > labeled as containing non-free components, but that hardly > > constitutes a "logistical problem" that is worth worrying about > > for lon

Re: NEW handling: About rejects, and kernels

Scripsit [EMAIL PROTECTED] (Marco d'Itri) > On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote: >> >> >> I'm ok with (1), provided we do it in the non-free archive. >> >> > This does present certain logistical problems for producing installers. >> >> Which ones? >> > The fact that they need t

Re: NEW handling: About rejects, and kernels

Scripsit Matthew Garrett <[EMAIL PROTECTED]> > Henning Makholm <[EMAIL PROTECTED]> wrote: >> Scripsit Matthew Garrett <[EMAIL PROTECTED]> I'm ok with (1), provided we do it in the non-free archive. >>> This does present certain logistical problems for producing installers. >> Which ones? >

Re: NEW handling: About rejects, and kernels

On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote: > Where does it say that such images are not allowed? At least current practice, and the build scripts not being able to do it. -- ciao, Marco signature.asc Description: Digital signature

Re: NEW handling: About rejects, and kernels

On Sat, Apr 02, 2005 at 04:26:28PM +0200, Wouter van Heyst wrote: > On Sat, Apr 02, 2005 at 03:01:34PM +0100, Matthew Garrett wrote: > > I'm not suggesting that we claim that firmware is Free, but putting it > > in non-free is: > > (a) going to result in an awkward situation for installation, and

Where to install ROX applications?

I'd like to make Debian packages for ROX-Session and some of the applications that go with it in the ROX desktop environment. See . NB there's already a package for ROX-Filer in unstable, which splits up the application into various FHS-compliant locations rather than follow ROX'

Re: NEW handling: About rejects, and kernels

On Sat, Apr 02, 2005 at 04:57:09PM +0100, Henning Makholm wrote: > Scripsit Matthew Garrett <[EMAIL PROTECTED]> > > I've suggested before that creating a separate section for firmware may > > be the best solution. > You have not described how that would differ from using 'non-free'. One example:

Re: Bits from the DAMs ( & Co)

I demand that Ritesh Raj Sarraf may or may not have written... > April Fool! Presumably self-referential for top-posting and quoting the whole text... [snip] -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk

Re: NEW handling: About rejects, and kernels

Scripsit [EMAIL PROTECTED] (Marco d'Itri) > On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote: >> Where does it say that such images are not allowed? > At least current practice, and the build scripts not being able to do it. The only thing that is necessary is to update the build scripts the

Re: NEW handling: About rejects, and kernels

Scripsit Mark Brown <[EMAIL PROTECTED]> > On Sat, Apr 02, 2005 at 04:57:09PM +0100, Henning Makholm wrote: >> Scripsit Matthew Garrett <[EMAIL PROTECTED]> >> > I've suggested before that creating a separate section for firmware may >> > be the best solution. >> You have not described how that wou

Re: NEW handling: About rejects, and kernels

Matthew Garrett <[EMAIL PROTECTED]> writes: > The choice is not between free firmware and non-free firmware. The > choice is between firmware on disk and firmware on chip. That's the > reality of the situation. I'd prefer us to adopt policies based on what > currently exists, rather than on what m

Re: NEW handling: About rejects, and kernels

Matthew Garrett <[EMAIL PROTECTED]> writes: >> I'm ok with (1), provided we do it in the non-free archive. > > This does present certain logistical problems for producing installers. A free kernel can't support that hardware. It's a shame, but it's true. If we want an alternative installer with

Re: NEW handling: About rejects, and kernels

Wouter van Heyst <[EMAIL PROTECTED]> writes: > The awkwad situation would be that d-i is part of Debian, and non-free > isn't, so anything in non-free can not be part of the installer? > But having a (non-free) firmware section with components of that in the > installer is ok? If it's done right,

why allow broken packages to get all the way to mirrors?

It seems there are only minimal checks, so developers can unwittingly upload broken packages. Wouldn't a nightly $ for package in all_of_debian do apt-get --print-uris install $package; done > /dev/null 2>errors_for_inspection done at Debian Headquarters 'catch' them before they are allowed to go

Re: why allow broken packages to get all the way to mirrors?

Dan Jacobson writes: > ...Debian Headquarters... There is no such place. > Why isn't this same apt-get check that the user does, also get done > beforehand by the archive patrol? The users of Unstable are the archive patrol. > For instance, let's say we are a food company. Why not check to see

Re: NEW handling: About rejects, and kernels

Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: Thomas, please stop Cc:ing me on Debian mailing list threads. I read the list. > Matthew Garrett <[EMAIL PROTECTED]> writes: > >>> I'm ok with (1), provided we do it in the non-free archive. >> >> This does present certain logistical problems for pr