Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Sat, 21 Oct 2006, Anthony Towns wrote: > On Wed, Oct 18, 2006 at 06:11:38PM +0200, Geert Uytterhoeven wrote: > > Assumed m68k would be able to kill (most of) the backlog in time, what would > > prevent m68k from becoming releasable? > > - It didn't sustain the `95%' rate during the last x months? > > x=3, yes. > > The sustainability issue is important, because it's the best evidence we can > get that the arch will be supportable for ongoing security updates. Is it really the _best_ evidence? It only measures how quickly a port can provide security updates, but it doesn't say very much about the quality of them. bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status update: GNUstep library transition
Hubert, Please wrap your mails at < 80 lines, trying to reply to this is moderately painful :/ On Sat, Oct 14, 2006 at 12:07:01PM -0400, Hubert Chan wrote: > Currently, gnustep-core-devel, from meta-gnustep, depends on > libgnustep-base1.11-dbg and libgnustep-gui0.10-dbg, which will no longer > be available with the new GNUstep libraries. Which I think would prevent > the migration to testing. Yes, it absolutely would have if Andi hadn't pushed it in. My question was, why would you rather release with newer individual packages without any metapackages for upgrade support, than release with an older GNUstep that was actually properly installable? Because that's what the request to remove meta-gnustep amounted to, and that's something I would prefer to avoid in the future. > P.P.S. Steve, could I request a freeze exception for meta-gnustep: in the > (seemingly likely) case that not all the GNUstep packages get through NEW > before the freeze, would you (or aba) allow Gürkan to upload a new > meta-gnustep that will depend only on the packages that made it into etch? > I understand that he has been delaying an upload of meta-gnustep, so that > he can include the stuff that's currently stuck in NEW, and not have to > make too many uploads, but if it's too late for those to be included in > etch, it would be good to at least have a meta-gnustep in etch that > depends on the packages that do make it in. For an arch: all package such as this, I would greatly prefer more frequent, incremental uploads instead of waiting for packages to clear NEW that may or may not be approved in time for the release. Since the uninstallability of gnustep-core-devel is an RC bug, a fix would qualify for a freeze exception, but I would certainly be much happier to see this fixed sooner rather than later. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release team position on the state of kernel firmware, post GR2006-007
On Fri, Oct 20, 2006 at 08:46:29PM -0700, Thomas Bushnell BSG wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > As mentioned above, it was discovered late in the process that three > > firmware > > images included in the upstream kernel that are relevant to the installer > > are > > not distributed under clearly DFSG-compliant licenses: tg3, typhoon, and > > acenic. Of these, only typhoon was in sarge; tg3 and acenic had been > > removed > > from the kernel and have since been readded. > > If tg3 and acenic were not in sarge, then including them would > represent a regression in freedom. The resolution permits keeping > things around which don't meet our standards of freeness, but it does > not permit adding new things. Thomas, the resolution does not allow to keep things around which don't meet our standard of freeness. It clearly states that firmwares without DFSG-free licenses have to go (the interpretation here is that the text says that sourceless versions of DFSG-free firmwares have to go). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release team position on the state of kernel firmware, post GR2006-007
On Fri, Oct 20, 2006 at 04:35:07PM -0700, Steve Langasek wrote:
> With the conclusion of GR 2006-007[1], we now have a clear statement from the
> Debian developers that it is acceptable to release etch with firmware that
> does not meet our usual requirements for inclusion in main, subject to three
> principal conditions:
>
> 1. the freedom of the kernel for etch will not be a regression relative to
> sarge
> 2. the firmware needs to be in main to support installation of Debian on
> certain hardware
> 3. the license of the firmware complies with the DFSG's requirements for
> licenses, even though there may be no source code available for the work
> and therefore the work does not meet the DFSG as a whole.
>
> At the time the GR was proposed and seconded, it was generally believed that
> this was sufficient to cover all firmware that needed to be shipped in main
> for the installer's benefit, because all firmware that was relevant under 2.
> was also allowed under 3. Unfortunately, discussion revealed that this was
> not the case.
You are missing two clear points here, this was not the intention of Manoj,
has he stated multiple times, the tg3 license got changed about a year ago,
and the kernel team position statement was clear about this, and pre-dated the
vote on the GR, i also often and loudly warned about these problems in the
resolution, since it was first proposed by Manoj.
I don't recognize this statement as true, and believe that there is at least a
part of the voters which where not deluded by the wordings of the actual
resolution proposal and voted what the text actually says.
So, saying that you are going to interpret the vote and the resulting GRs, as
you believe the voters intented to vote, and in complete contradiction with
the actual content of voted upon resolution is not a good idea. I would much
have preferd a staigthforward answer ("we are going to release tg3 in direct
opposition with the resolution, because it is within our RMs power to do so").
> tg3, typhoon, and acenic firmware
> -
>
> As mentioned above, it was discovered late in the process that three firmware
> images included in the upstream kernel that are relevant to the installer are
> not distributed under clearly DFSG-compliant licenses: tg3, typhoon, and
> acenic. Of these, only typhoon was in sarge; tg3 and acenic had been removed
> from the kernel and have since been readded.
What a joke, we all knew that from the start, at least those of us who
bothered to check, and who where not believing all i said was just uninformed
bullshit.
> The license on acenic is unclear. The upstream website does grant permission
> to modify and distribute the firmware, and we have a separate statement that
> permission was granted to distribute it "as part of the GPL driver." At the
> same time, the upstream website also appears to place restrictions on use.
> We do not believe that use restrictions are compatible with the spirit of the
> GR that was passed, and we understand that an upstream license fix is
> unlikely; and re-adding this firmware is a regression relative to sarge. We
> recommend that the kernel team remove this firmware again for etch, but we
> choose not to consider this RC.
>
> The tg3 firmware was previously made available as a sourceless blob under the
> GPL, which would be covered by the previous section above. More recently, it
Most recently = almost a year ago ?
> has been distributed in the kernel under a license permitting redistribution
> without permitting modification. While this is not explicitly permitted in
> main by the GR that was passed, the release managers are confident that
> including this firmware in main *would* be permitted by the developers if
> asked, and therefore believe this firmware should be included in the kernel
> for etch without any need for an additional, time-consuming GR. It is also
> possible that the previous GPL grant is still in effect in addition to the
> new clarified license, and we do not believe this question is of sufficient
> importance to require further investigation prior to etch.
No, because the new code says :
* Firmware is:
* Derived from proprietary unpublished source code,
* Copyright (C) 2000-2003 Broadcom Corporation.
*
* Permission is hereby granted for the distribution of this firmware
* data in hexadecimal or equivalent format, provided this copyright
* notice is accompanying it.
*/
Notice how clearly it states that there is *SOURCE CODE*, and thus the
previous license, which is GPL, is violated, and you can't possible close your
eyes on this one, claiming that the hexcode may be the prefered form of
modification.
As for "Another time consuming GR", if someone had not gone off and suddenly
called for vote in a hasty way, we would not be in this mess.
> The typhoon firmware is the last installer-relevant driver that we are
> allowe
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Fri, 20 Oct 2006, Thomas Bushnell BSG wrote: > > Hmm and here I thought you would care about this package, the way you > > constantly asked about its status... > > I do care about it. But I see no particular reason for urgency about > the particular bug, and obviously, the m68k team doesn't either. Obviously? bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k is a release arch for etch
On Fri, Oct 20, 2006 at 02:05:37PM -0700, Steve Langasek wrote: > On Fri, Oct 20, 2006 at 10:58:25PM +0200, Bill Allombert wrote: > > IIRC, the m68k kernels are already cross-compiled. > > Yes, which has repeatedly caused problems due to assumptions in the kernel > packaging that host arch == build arch... The proposed use of distcc+crossgcc avoid completly this issues. Everything run on the target system, but the actual gcc -c compilation which is done remotely by a cross-compiler. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Fri, 20 Oct 2006, Thomas Bushnell BSG wrote: > > PS: 4 days and still no response to guile-1.6 patch... > > Maybe you should ask the guile-1.6 maintainer? I'm not responsible > for the package. Hmm and here I thought you would care about this package, the way you constantly asked about its status... bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
On Fri, Oct 20, 2006 at 03:46:57PM -0500, Peter Samuelson wrote: > > [Manoj Srivastava] > > Given this official statement, I also suggest that the GR > > proposal is moot, since the proposer himself believes that the kernel > > modules in question can not be distributed by Debian legally. > > There are a few firmware files which are sourceless but explicitly > _not_ GPL - these are still covered by some or all of the GRs under > past and present consideration. I don't understand which GRs cover this one ? > Whether this subset of firmware matters much to end users, I couldn't > say. tg3, e100 maybe too, those are some very widely widespread ethernet drivers, used among others in servers, where netbooting is a must. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Sat, 21 Oct 2006, Anthony Towns wrote: > > Well, that's what we want as well and if m68k could provide this, what's > > the reason this couldn't be released as "Debian"? > > It won't be "Debian etch" or "Debian stable", if it's different to > etch/stable on other architectures. That wasn't my question, what if's _not_ different? bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release team position on the state of kernel firmware, post GR2006-007
Steve Langasek <[EMAIL PROTECTED]> writes: > As mentioned above, it was discovered late in the process that three firmware > images included in the upstream kernel that are relevant to the installer are > not distributed under clearly DFSG-compliant licenses: tg3, typhoon, and > acenic. Of these, only typhoon was in sarge; tg3 and acenic had been removed > from the kernel and have since been readded. If tg3 and acenic were not in sarge, then including them would represent a regression in freedom. The resolution permits keeping things around which don't meet our standards of freeness, but it does not permit adding new things. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel <[EMAIL PROTECTED]> writes: >> I do care about it. But I see no particular reason for urgency about >> the particular bug, and obviously, the m68k team doesn't either. > > Obviously? They ignored it for a long time, and as far as I know, haven't requested the maintainer to treat it with any particular urgency. Instead, you're blathering at me online. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request to remove ikvm from testing & etch
On Thu, Oct 19, 2006 at 11:04:15PM -0700, Dave Beckett wrote: > ikvm is too buggy to ship in a release, it needs to be removed > from testing. the 2 RC bugs it has so far should be marked > somehow as not-for-etch. They won't be closing anytime soon > since ikvm still has big building problems. I don't understand. You're saying the RC bugs it has should be marked as not-for-etch, but the package itself is also not for etch? Why? The RC bugs currently filed against ikvm are listed as applying only to the version of ikvm in unstable. Is there reason to believe they also apply to the version in testing? Are there other reasons why the version of ikvm in testing is unreleasable? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Thu, Oct 19, 2006 at 02:41:59PM -0400, Mark Duckworth wrote: > I have a Falcon/CT60 with EtherNAT (MII driver support for linux may or > may not work easily), several compaq P3 xeon servers that could run > aranym instances (all with very large 80+GB drives) and a M5484LITE > board that could run linux, but I'd have to get a disk controller of > some sort for it. I think USB 2.0 card + external USB 2.0 high speed > drive would work best. Let me know how to get buildd working right and > I'll help. Does my debian need to be configured specially or does it > have a chroot? I downloaded buildd before but I was a little confused. Maybe it could be a great opportunuity to try out using distcc+crossgcc on real hardware ? distcc+crossgcc has the potential of making builds much faster, which would make m68k acceptable by the security team. I tried it on aranym and that worked fine. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k release future
On Sat, Oct 21, 2006 at 06:58:21AM +1000, Anthony Towns wrote: > Hey all, > > So, from the other thread, seems like the idea for m68k is: > >(a) keep building unstable as per usual ack >(b) maintain a separate testing-like suite for m68k based on (and >thus probably trailing) the real testing, maintained by m68k >porters, that is installable (using d-i etc) ack >(c) not bother with an etch-equivalent release for m68k I'm not sure about this. I'd sure like to have some form of stable, even if we only do base and security-support base-type packages. I'd hate to have to maintain unstable/testing as the distribution on my buildd's. >(d) try to release with etch+1, possibly with coldfire support ack > The m68k certification pages on the wiki suggest it might be good to > have acks/naks from: > >1. Wouter Verhelst >2. Stephen R Marenka :) >3. Christian T. Steigies >4. Adam Conrad >5. Michael Schmitz > > I think Michael Schmitz has said he's willing to do some of the > maintenance work on the testing-like stuff; I'd suggest it'd probably be > ideal to have either two or three people doing it -- you have to already > be a DD though. It might also be worthwhile to join the RM team as a > release assistant in that case, ymmv. I'm willing to backup whoever takes this on, but I'd also like to get back to spending time on d-i and coldfire if possible. -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: m68k not a release arch for etch; status in testing, future plans?
On Fri, Oct 20, 2006 at 02:45:55PM -0700, Thomas Bushnell BSG wrote: > Roman Zippel <[EMAIL PROTECTED]> writes: > > > The point is that these release criteria have practically enforced a black > > and white scheme - either you're with us or you're on your own. > > Actually, Anthony Towns described about a half-dozen distinct > possibilities, and outlined the advantages and disadvantages of each. > The m68k porting team had a long time to work on making any one of > these a reality, but has (apparently) done very little of it. Just because we haven't made a bunch of noise about it, doesn't mean we haven't been working. Dude, either help or go away. Thanks, Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: binNMUs of gaim-plugins
On Thu, 2006-10-19 at 19:19 -0700, Steve Langasek wrote: > Compared to what? The current versions of all three plugins have a > dependency on gaim (>= 1:2.0). gaim 2.0.0beta4 introduced a small incompatibility with plugins for beta3 that changed a constant in one of the gaim headers and makes the plugin unloadable unless it's rebuilt against the new header. Most of the plugins will need to be rebuilt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Release team position on the state of kernel firmware, post GR2006-007
With the conclusion of GR 2006-007[1], we now have a clear statement from the Debian developers that it is acceptable to release etch with firmware that does not meet our usual requirements for inclusion in main, subject to three principal conditions: 1. the freedom of the kernel for etch will not be a regression relative to sarge 2. the firmware needs to be in main to support installation of Debian on certain hardware 3. the license of the firmware complies with the DFSG's requirements for licenses, even though there may be no source code available for the work and therefore the work does not meet the DFSG as a whole. At the time the GR was proposed and seconded, it was generally believed that this was sufficient to cover all firmware that needed to be shipped in main for the installer's benefit, because all firmware that was relevant under 2. was also allowed under 3. Unfortunately, discussion revealed that this was not the case. This email is therefore intended to clarify the release team's current position on the consequences of the GR for kernel firmware in etch, for each case currently under consideration. Sourceless firmware under a BSD-style license - Because the BSD license is a DFSG-free license, firmware in this group is clearly permitted in main for etch. According to [2], this includes mga, r128, radeon, and advansys firmware. Sourceless firmware distributed under the GPL - The GPL is also obviously a DFSG-compliant license, but much ado has been made over the idea that sourceless, GPLed firmware is not covered by this GR because it's not legal to distribute. The release managers consider this a non-issue. There are only two possibilities here: either it is legal to distribute this firmware, in which case it is permitted in main by the GR; or it is not legal to distribute this firmware, in which case no GR is sufficient to make such distribution acceptable to the release team. There is no third option here that an additional GR would help establish, because there's no point in the first place of speculating about what voters *believe* is legal to distribute: it's up to the maintainers and the ftp team to determine if a work is legal to distribute, not the developers at large. Neither the release managers nor the ftp masters believe that the sourceless GPL firmware shipped with the kernel poses a legal problem for Debian. It is true that such works appear to be inconsistently licensed, but we have a reasonable belief that this constitutes a licensing bug on the part of the copyright holder and not an indication of intent to prohibit redistribution. It is in our long-term interest to get clarification regarding such licensing bugs, but as with other licensing bugs where we have reason to believe the *intent* was to provide us with a valid and useful license, such clarification should not be a blocker for the release. tg3, typhoon, and acenic firmware - As mentioned above, it was discovered late in the process that three firmware images included in the upstream kernel that are relevant to the installer are not distributed under clearly DFSG-compliant licenses: tg3, typhoon, and acenic. Of these, only typhoon was in sarge; tg3 and acenic had been removed from the kernel and have since been readded. The license on acenic is unclear. The upstream website does grant permission to modify and distribute the firmware, and we have a separate statement that permission was granted to distribute it "as part of the GPL driver." At the same time, the upstream website also appears to place restrictions on use. We do not believe that use restrictions are compatible with the spirit of the GR that was passed, and we understand that an upstream license fix is unlikely; and re-adding this firmware is a regression relative to sarge. We recommend that the kernel team remove this firmware again for etch, but we choose not to consider this RC. The tg3 firmware was previously made available as a sourceless blob under the GPL, which would be covered by the previous section above. More recently, it has been distributed in the kernel under a license permitting redistribution without permitting modification. While this is not explicitly permitted in main by the GR that was passed, the release managers are confident that including this firmware in main *would* be permitted by the developers if asked, and therefore believe this firmware should be included in the kernel for etch without any need for an additional, time-consuming GR. It is also possible that the previous GPL grant is still in effect in addition to the new clarified license, and we do not believe this question is of sufficient importance to require further investigation prior to etch. The typhoon firmware is the last installer-relevant driver that we are allowed to distribute which is not m
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel <[EMAIL PROTECTED]> writes: > Hmm and here I thought you would care about this package, the way you > constantly asked about its status... I do care about it. But I see no particular reason for urgency about the particular bug, and obviously, the m68k team doesn't either. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel <[EMAIL PROTECTED]> writes: > The point is that these release criteria have practically enforced a black > and white scheme - either you're with us or you're on your own. Actually, Anthony Towns described about a half-dozen distinct possibilities, and outlined the advantages and disadvantages of each. The m68k porting team had a long time to work on making any one of these a reality, but has (apparently) done very little of it. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel <[EMAIL PROTECTED]> writes: >> Then m68k would be a suitable release candidate for etch+1. > > As usual you're avoiding the issue. The answer is not _that_ simple. Really? What are the great mysterious complexities in it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel <[EMAIL PROTECTED]> writes: > PS: 4 days and still no response to guile-1.6 patch... Maybe you should ask the guile-1.6 maintainer? I'm not responsible for the package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Fri, Oct 20, 2006 at 02:02:10PM -0700, Steve Langasek wrote: > On Sat, Oct 21, 2006 at 06:40:12AM +1000, Anthony Towns wrote: > > > On Thu, Oct 19, 2006 at 06:04:49PM +0200, Aurelien Jarno wrote: > > > Bill Allombert a ?crit : > > > >My personnal plan is to set up one or two fast amd64 octocore as a m68k > > > >buildd. > > > >That would lift most of the objection with the port. > > > The question is to know if it is ok to use emulators to build and upload > > > packages? > > > The m68k porters have been firmly against cross-compiling in the past, > > it's their call on whether this sort of approach is suitable. > > FWIW, it's my understanding he intends to run aranym on these systems, > thereby making this native building in an emulator rather than > cross-building. Exactly. Running eight aranym instances on a single box would provide a large amount of buildd power and would reduce the number of physical buildd thus addressing one of the concerns of the ftp-master. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Fri, Oct 20, 2006 at 10:58:25PM +0200, Bill Allombert wrote: > IIRC, the m68k kernels are already cross-compiled. Yes, which has repeatedly caused problems due to assumptions in the kernel packaging that host arch == build arch... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
m68k release future
Hey all, So, from the other thread, seems like the idea for m68k is: (a) keep building unstable as per usual (b) maintain a separate testing-like suite for m68k based on (and thus probably trailing) the real testing, maintained by m68k porters, that is installable (using d-i etc) (c) not bother with an etch-equivalent release for m68k (d) try to release with etch+1, possibly with coldfire support The m68k certification pages on the wiki suggest it might be good to have acks/naks from: 1. Wouter Verhelst 2. Stephen R Marenka 3. Christian T. Steigies 4. Adam Conrad 5. Michael Schmitz I think Michael Schmitz has said he's willing to do some of the maintenance work on the testing-like stuff; I'd suggest it'd probably be ideal to have either two or three people doing it -- you have to already be a DD though. It might also be worthwhile to join the RM team as a release assistant in that case, ymmv. Cheers, aj signature.asc Description: Digital signature
Re: m68k not a release arch for etch; status in testing, future plans?
On Sat, Oct 21, 2006 at 06:40:12AM +1000, Anthony Towns wrote: > On Thu, Oct 19, 2006 at 06:04:49PM +0200, Aurelien Jarno wrote: > > Bill Allombert a ?crit : > > >My personnal plan is to set up one or two fast amd64 octocore as a m68k > > >buildd. > > >That would lift most of the objection with the port. > > The question is to know if it is ok to use emulators to build and upload > > packages? > The m68k porters have been firmly against cross-compiling in the past, > it's their call on whether this sort of approach is suitable. FWIW, it's my understanding he intends to run aranym on these systems, thereby making this native building in an emulator rather than cross-building. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Sat, Oct 21, 2006 at 06:40:12AM +1000, Anthony Towns wrote: > [-68k readded] > > On Thu, Oct 19, 2006 at 06:04:49PM +0200, Aurelien Jarno wrote: > > Bill Allombert a ?crit : > > >My personnal plan is to set up one or two fast amd64 octocore as a m68k > > >buildd. > > >That would lift most of the objection with the port. > > The question is to know if it is ok to use emulators to build and upload > > packages? > > The m68k porters have been firmly against cross-compiling in the past, > it's their call on whether this sort of approach is suitable. Well, using an emulator as a buildd is generally not called cross-compiling, since you are running native code. However I also experimented using a cross-compiler through the use of distcc. Results are on debian-68k archives and are positive. This would allow packages to build much more quickly. IIRC, the m68k kernels are already cross-compiled. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
[Manoj Srivastava] > Given this official statement, I also suggest that the GR > proposal is moot, since the proposer himself believes that the kernel > modules in question can not be distributed by Debian legally. There are a few firmware files which are sourceless but explicitly _not_ GPL - these are still covered by some or all of the GRs under past and present consideration. Whether this subset of firmware matters much to end users, I couldn't say. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Thu, Oct 19, 2006 at 05:25:41PM +0200, Michael Schmitz wrote: > Is the stuff at http://ftp-master.debian.org/testing/update_out_code/ > still current? It seems to be lacking stuff, according to the README. Err, it's a symlink to the code that's actually being used. What's missing? Cheers, aj signature.asc Description: Digital signature
Re: m68k not a release arch for etch; status in testing, future plans?
On Wed, Oct 18, 2006 at 09:45:04PM +0200, Roman Zippel wrote: > On Thu, 19 Oct 2006, Anthony Towns wrote: > > The reason we keep all architectures in sync is so that you end > > up running the same thing if you install "Debian" on any supported > > architecture. Otherwise you'd install "Debian" on i386 and have the > > latest features, but install "Debian" on alpha and have an older version > > of some packages with fewer features and different bugs that need to be > > worked around. > Well, that's what we want as well and if m68k could provide this, what's > the reason this couldn't be released as "Debian"? It won't be "Debian etch" or "Debian stable", if it's different to etch/stable on other architectures. There's no reason it can't be on debian.org servers etc, and be called "Debian for m68k" or whatever, and be available on Debian mirrors and such. I think we're just splitting hairs at this point though :) Cheers, aj signature.asc Description: Digital signature
Re: m68k not a release arch for etch; status in testing, future plans?
On Wed, Oct 18, 2006 at 06:11:38PM +0200, Geert Uytterhoeven wrote: > Assumed m68k would be able to kill (most of) the backlog in time, what would > prevent m68k from becoming releasable? > - It didn't sustain the `95%' rate during the last x months? x=3, yes. The sustainability issue is important, because it's the best evidence we can get that the arch will be supportable for ongoing security updates. Cheers, aj signature.asc Description: Digital signature
Re: m68k not a release arch for etch; status in testing, future plans?
[-68k readded] On Thu, Oct 19, 2006 at 06:04:49PM +0200, Aurelien Jarno wrote: > Bill Allombert a ?crit : > >My personnal plan is to set up one or two fast amd64 octocore as a m68k > >buildd. > >That would lift most of the objection with the port. > The question is to know if it is ok to use emulators to build and upload > packages? The m68k porters have been firmly against cross-compiling in the past, it's their call on whether this sort of approach is suitable. Cheers, aj signature.asc Description: Digital signature
Re: Bug#394332: sysvinit: Please remove NEWS.Debian entries for 2.86.ds1-18 and -19
LENHOF Jean-Yves wrote: > >> Incidentally, it would be nice to have some sort of tool that could be >> used to track the versions of a package that had appeared in the current >> "testing" release, although obviously that's beyond the scope of this >> bug report. Currently one has to browse for the package of interest in >> http://snapshot.debian.net/archive//MM/DD/debian/dists/testing/SECTION/binary-ARCH/Packages.gz >> for the desired SECTION and ARCH through possibly relevant dates >> /MM/DD. >> > > On packages site you see this type of information (on the right) > > http://packages.qa.debian.org/s/sysvinit.html Thanks! Don't I feel dumb now. (CC'ed to debian-release for the benefit of anyone reading the archives later.) regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394332: sysvinit: Please remove NEWS.Debian entries for 2.86.ds1-18 and -19
Package: sysvinit Version: 2.86.ds1-20 Severity: wishlist Hello, I think it might be a good idea to remove the NEWS.Debian entries for sysvinit for versions 2.86.ds1-18 and 2.86.ds1-19, and try to get this changed package into etch (maybe via etch-proposed-updates). The versions of sysvinit having bug #386500 (and friends), specifically 2.86.ds1-16 and 2.86.ds1-17, were never part of Etch, as I determined by checking snapshot.debian.net. (Etch jumped from -15 to -20 on about September 22, and that is still the sysvinit version in Etch as of October 20.) Therefore these NEWS.Debian entries that explain how to deal with repercussions from that bug are unnecessary, and their appearance will be confusing to anyone tracking Etch or upgrading from Sarge to Etch. Further, anyone tracking Sid should have seen them by now since sysvinit 2.86.ds1-19 was available in unstable on Sept. 13 (again, according to snapshot.debian.net), more than a month ago. CC'ing to debian-release in case the Release Managers wish to comment. Incidentally, it would be nice to have some sort of tool that could be used to track the versions of a package that had appeared in the current "testing" release, although obviously that's beyond the scope of this bug report. Currently one has to browse for the package of interest in http://snapshot.debian.net/archive//MM/DD/debian/dists/testing/SECTION/binary-ARCH/Packages.gz for the desired SECTION and ARCH through possibly relevant dates /MM/DD. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Fri, Oct 20, 2006 at 02:10:37PM +0200, Arnoud Engelfriet wrote: > MJ Ray wrote: > > While fairly simple, it is totally incorrect, as public distribution in > > breach of copyright carries criminal liability in England, as I previously > > posted. See the Copyright Designs and Patents Act as amended, under > > the criminal liability heading. http://www.jenkins-ip.com/patlaw/cdpa1.htm > > I suspect most of the EU has similar law these days, although I cannot > > name them. > > You're correct, there is criminal liability in most of Europe > for "intentional infringement" of copyright. Many countries do > however require the copyright holder to file charges against > the infringer first. The police won't act by itself (how could > they, they have no evidence of an illegal act unless the > copyright holder files the accusation of distribution without > a license). > > I do wonder, are the copyright holders of the firmware the only > people with standing to sue? If the combination of firmware and > GPL-licensed kernel is a derivative of the kernel, then anyone > with a copyright interest in the kernel can sue for not obeying > the GPL. Please check past debian-legal discussion about this. IANAL and everything, but all times we discussed the issue the opinion that prevaled, was that the firmware do not constitute a derivative work of the kernel, in the same way that if the firmware is contained in a flash on the card, it does not constitute a derivative work of the kernel, and in the same way a free compressor which can generate compressed archive with builtin uncompressor binaries, is not a derivative work of the compressed files it contains. More arguments on this can be found in the list archive. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why was cjk-latex removed from testing?
Dear all From: Frank Küster <[EMAIL PROTECTED]> To: Debian Release Management Cc: danai sae-han <[EMAIL PROTECTED]> > http://bts.turmzimmer.net/ shows that cjk-latex was > removed from testing last night. However, the bug that is > referenced has been long closed since, and there's no > other RC bug open. > > Note that in fact cjk-latex should be removed from testing > (hopefully) soon: If latex-cjk-chinese-arphic is processed > in new, it can enter testing together with latex-cjk and > latex-cjk-japanese-wadalab and replace cjk-latex. But as > long as this is not sure to happen before the release, I > think our users are better of with an outdated and > somewhat buggy cjk-latex than without anything. I concur: if latex-cjk-chinese-arphic can't arrive in testing in time, then I would also propose to leave the old cjk-latex package in place. I hope you can fix this, Andi. Thanks Danai
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
MJ Ray wrote: > While fairly simple, it is totally incorrect, as public distribution in > breach of copyright carries criminal liability in England, as I previously > posted. See the Copyright Designs and Patents Act as amended, under > the criminal liability heading. http://www.jenkins-ip.com/patlaw/cdpa1.htm > I suspect most of the EU has similar law these days, although I cannot > name them. You're correct, there is criminal liability in most of Europe for "intentional infringement" of copyright. Many countries do however require the copyright holder to file charges against the infringer first. The police won't act by itself (how could they, they have no evidence of an illegal act unless the copyright holder files the accusation of distribution without a license). I do wonder, are the copyright holders of the firmware the only people with standing to sue? If the combination of firmware and GPL-licensed kernel is a derivative of the kernel, then anyone with a copyright interest in the kernel can sue for not obeying the GPL. Arnoud -- Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Stephen Gran <[EMAIL PROTECTED]> wrote: > [...] If it is a > license from the copyright holders, than the only ones who can sue > Debian for distribution of sourceless GPL'ed works are, er, the people > who originally gave out those works in that form. I understand there is > some contention around whether this claim is accurate (and I claim no > deep understanding of international copyright and contract law to make a > claim for either side), but I think that is the fairly simple counter > argument. [...] While fairly simple, it is totally incorrect, as public distribution in breach of copyright carries criminal liability in England, as I previously posted. See the Copyright Designs and Patents Act as amended, under the criminal liability heading. http://www.jenkins-ip.com/patlaw/cdpa1.htm I suspect most of the EU has similar law these days, although I cannot name them. By the way, we could be sued by the copyright holders of any firmware which has been reproduced without permission: that is, the copyright holders are not those issuing them under GPL. I remind aj that I am not a lawyer, but have been punished for copyright mistakes in the past, so learnt about it. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
