Bug#449497: Bug#503814: [Foo2zjs-maintainer] Bug#449497: closed by Michael Koch (Bug#449497: fixed in hannah-foo2zjs 1:1)
On Fri, 23 Oct 2009 08:21:58 +0200, Michael Koch wrote: Please don't play bug ping-pong and reopen bugs which are closed just because you like to do so. this isn't ping pong...i haven't touched the bug in over 8 months...that would be one crazy long game. We have implemented the solution that was recommended by the (former) release team. If you disagree please talk with the (current) release team and get a decision from them that says that we need to change packaging. it still seems like there is no concrete direction from within the project on these problems. i will renew the discussion with the release team as you suggest. mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503814: [Foo2zjs-maintainer] foo2zjs
Hi there! Can you please keep the foo2zjs-maintainer mailing list cc:ed? If you do so, no need to cc: me, I read the list. TIA. I'm sorry for the long mail: I performed more tests with the only foo2zjs printer I have [1] and I found some interesting stuff, please read below. I tried to be as more detailed as I could, at least to give a better overview of the foo2zjs driver status. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466758#15 On Sat, 01 Nov 2008 09:47:21 +0100, Anthony Towns wrote: On Fri, Oct 31, 2008 at 03:52:31PM +0100, Andreas Barth wrote: 2. As per constitution, we (the tech ctte) only makes decision as last resort. So currently, the next step would be for anyone who disagrees with this bug not being release critical to ask the release team to review the decision and maybe overrule it. I'm not sure I'd want the release team to be able to stop the tech-ctte from being involved simply by not making a decision, so I'm not sure I agree with this precisely. But in the general case, yes, I'd rather see the release team making the call on this. FYI, the Release Team was asked for an advice on Sun, 26 October [2]. However, I know we (the Debian foo2zjs maintainers) decided to go to the tech-ctte just two days later... [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yesbug=503814#125 tech ctte members, any opinion from you on that? Basically, +1. On a technical level, it seems to me there's two aspects: (1) can a package in main include a script that gets stuff from some random website really be considered DFSG-free/policy-compliant? NB, in this case it is not from some random website, but it is from *upstream* website, which means that these data are not included in the upstream sources for other reasons. Anyway, if the script is moved to /u/s/d/$PKG/examples I would say it is OK for the package to be in main. And, again, I think the main point is if printers can work without those data, read below. (2) should we make sure that the stuff on the random website is also available from somewhere in Debian, in case the random website gets shut down, etc? If there are licensing issues, I see no advantages for Debian in distributing them. Here what the getweb script from the last tested upstream version [1] would download: - not strictly required files (not fully sure, but read below for my experience with the HP Color LaserJet 1500L) $ ./getweb 2600n# Get HP Color LaserJet 2600n .ICM files $ ./getweb 1600 # Get HP Color LaserJet 1600 .ICM files $ ./getweb 1500 # Get HP Color LaserJet 1500 .ICM files $ ./getweb 1215 # Get HP Color LaserJet CP1215 .ICM files $ ./getweb 2530 # Get Konica Minolta 2530 DL .ICM files $ ./getweb 2490 # Get Konica Minolta 2490 MF .ICM files $ ./getweb 2480 # Get Konica Minolta 2480 MF .ICM files $ ./getweb 6115 # Get Xerox Phaser 6115MFP .ICM files $ ./getweb 2430 # Get Konica Minolta 2430 DL .ICM files $ ./getweb 2300 # Get Minolta 2300 DL .ICM files $ ./getweb 2200 # Get Minolta 2200 DL .ICM files $ ./getweb cpwl # Get Minolta Color PageWorks/Pro L .ICM files $ ./getweb 300 # Get Samsung CLP-300 .ICM files $ ./getweb 315 # Get Samsung CLP-315 .ICM files $ ./getweb 600 # Get Samsung CLP-600 .ICM files $ ./getweb 610 # Get Samsung CLP-610 .ICM files $ ./getweb 2160 # Get Samsung CLX-2160 .ICM files $ ./getweb 3160 # Get Samsung CLX-3160 .ICM files $ ./getweb 6110 # Get Xerox Phaser 6110 and 6110MFP .ICM files $ ./getweb 500 # Get Lexmark C500 .ICM files $ ./getweb 3200 # Get Oki C3200 .ICM files $ ./getweb 3300 # Get Oki C3300 .ICM files $ ./getweb 3400 # Get Oki C3400 .ICM files $ ./getweb 3530 # Get Oki C3530 MFP .ICM files $ ./getweb 5100 # Get Oki C5100 .ICM files $ ./getweb 5200 # Get Oki C5200 .ICM files $ ./getweb 5500 # Get Oki C5500 .ICM files $ ./getweb 5600 # Get Oki C5600 .ICM files $ ./getweb 5800 # Get Oki C5800 .ICM files - firmwares needed for the print to work (the problem with these files should be the same about kernel firmwares) $ ./getweb 1020 # Get HP LJ 1020 firmware file $ ./getweb 1018 # Get HP LJ 1005 firmware file $ ./getweb 1005 # Get HP LJ 1005 firmware file $ ./getweb 1000 # Get HP LJ 1000 firmware file $ ./getweb p1505# Get HP LJ P1505 firmware file $ ./getweb p1008# Get HP LJ P1008 firmware file $ ./getweb p1007# Get HP LJ P1007 firmware file $ ./getweb p1006# Get HP LJ P1006 firmware file $ ./getweb p1005# Get HP LJ P1005 firmware file $ ./getweb 2300dl_fw # Get Minolta 2300DL v2.55 firmware (experts only) (1) seems to be resolved as per Andi's comments, but I kind-of think (2) is actually the more important issue, and that the stuff getting
Bug#503814: [Foo2zjs-maintainer] foo2zjs
On Mon, Nov 03, 2008 at 06:54:32PM +0100, Luca Capello wrote: FYI, the Release Team was asked for an advice on Sun, 26 October [2]. However, I know we (the Debian foo2zjs maintainers) decided to go to the tech-ctte just two days later... Indeed, hence the lack of comment. However, as this has been handed back, I'd like to say that the release team do not consider this issue, in this particular case, RC for lenny. ie: this bug should not have a severity greater than important. We reserve the right to consider other similar issues RC, or this to be upgraded after lenny. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3 signature.asc Description: Digital signature
Bug#503814: foo2zjs: getweb script depends on non-free firmware
reassign 503814 foo2zjs forcemerge 449497 503814 thanks There's no reason to have a separate bug report here assigned to the technical committee; re-merging the bugs. If this needs to be reconsidered by the TC, please reassign the bugs as a whole to both foo2zjs and the tech-ctte virtual package simultaneously. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503814: foo2zjs
On Fri, Oct 31, 2008 at 03:52:31PM +0100, Andreas Barth wrote: 1. Currently, the submitter claims that the bug is serious, the maintainer don't think so, and there is no decision by the release team yet. So the current state of the bug isn't serious, but important. ie, the views (on serious severity) are prioritised as: - submitter's (default) - maintainer's (can override submitter, and in this case does) - release team's (can override maintainer and submitter) - tech-ctte (can override all three of the above) - general resolution (likewise) 2. As per constitution, we (the tech ctte) only makes decision as last resort. So currently, the next step would be for anyone who disagrees with this bug not being release critical to ask the release team to review the decision and maybe overrule it. I'm not sure I'd want the release team to be able to stop the tech-ctte from being involved simply by not making a decision, so I'm not sure I agree with this precisely. But in the general case, yes, I'd rather see the release team making the call on this. tech ctte members, any opinion from you on that? Basically, +1. On a technical level, it seems to me there's two aspects: (1) can a package in main include a script that gets stuff from some random website really be considered DFSG-free/policy-compliant? (2) should we make sure that the stuff on the random website is also available from somewhere in Debian, in case the random website gets shut down, etc? (1) seems to be resolved as per Andi's comments, but I kind-of think (2) is actually the more important issue, and that the stuff getting downloaded should probably be packaged for non-free and possibly volatile, in order to remove the external dependency. The package in main would then get a Suggests: foo2zjs-nonfree-drivers, and if the script gets moved to contrib, that could then become Suggests: foo2zjs-nf-d | foo2zj-nf-d-getter-script. That assumes someones willing to do the legwork of packaging the drivers, of course, which might require negotiating permission to redistribute them from whoever owns them. Cheers, aj signature.asc Description: Digital signature
Bug#503814: [Foo2zjs-maintainer] Bug#449497: foo2zjs: getweb script depends on non-free firmware
Hi Michael! Adding the d-release mailing list to cc:. On Fri, 31 Oct 2008 13:41:25 +0100, Michael Gilbert wrote: i'll go ahead and start the discussion since no one else is running with it. this matter is rather urgent since the problem is now being considered release-critical for lenny. [...] let me again stress that action is URGENT since this is release-critical for lenny. Can you please stop dealing with this bug and let the tech-ctte [1] do their work? About the urgency and lenny: the bug is marked as serious, which means that if the tech-ctte does not fix it before lenny (something which I do not think is going to happen), the Release Team must deal with it. FYI, other people have already started to work on it, check the thread on the d-ctte mailing list [2]. Thx, bye, Gismo / Luca Footnotes: [1] http://www.debian.org/devel/tech-ctte [2] http://lists.debian.org/debian-ctte/2008/10/msg0.html pgpEjhCaWzo4z.pgp Description: PGP signature
Bug#503814: foo2zjs
* Debian Bug Tracking System ([EMAIL PROTECTED]) [081028 10:08]: reassign -2 tech-ctte Bug#503814: foo2zjs: getweb script depends on non-free firmware Bug reassigned from package `foo2zjs' to `tech-ctte'. As this bug didn't get a decision from the release team yet, I'd propose the following decision by the tech ctte: 1. Currently, the submitter claims that the bug is serious, the maintainer don't think so, and there is no decision by the release team yet. So the current state of the bug isn't serious, but important. The maintainers should continue to feel free to adjust the bug severity according to their decisions (unless of course the release team decides to overrule them). 2. As per constitution, we (the tech ctte) only makes decision as last resort. So currently, the next step would be for anyone who disagrees with this bug not being release critical to ask the release team to review the decision and maybe overrule it. 3. If there is a release team decision, and someone is still unhappy enough then one could ask the tech ctte to overrule the release teams decision. However, until the overruling actually happens, the bugs state remains to stay the way the release team decided. tech ctte members, any opinion from you on that? Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503814: foo2zjs
On Fri, Oct 31 2008, Andreas Barth wrote: As this bug didn't get a decision from the release team yet, I'd propose the following decision by the tech ctte: 1. Currently, the submitter claims that the bug is serious, the maintainer don't think so, and there is no decision by the release team yet. So the current state of the bug isn't serious, but important. The maintainers should continue to feel free to adjust the bug severity according to their decisions (unless of course the release team decides to overrule them). 2. As per constitution, we (the tech ctte) only makes decision as last resort. So currently, the next step would be for anyone who disagrees with this bug not being release critical to ask the release team to review the decision and maybe overrule it. 3. If there is a release team decision, and someone is still unhappy enough then one could ask the tech ctte to overrule the release teams decision. However, until the overruling actually happens, the bugs state remains to stay the way the release team decided. tech ctte members, any opinion from you on that? I concur. Additionally, I think I also agree with the maintainer, i that this does not seem like a DFSG violation; the package delivers free functionality relevant to at least one printer, a maintainer has seen fit to package that functionality for main, and if there is a script that the user can use to support hardware that requires non-free software, we understand. The example script is not central to the function for supported hardware, so it does not warrant shipping the whole package in contrib. This is, of course, a non-binding opinion at the moment. manoj -- People don't form relationships, they take hostages. anon Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
