Re: APT 0.7 for sid
Daniel Burrows a écrit : On Thu, Jun 07, 2007 at 09:54:16AM +0200, Raphael Hertzog [EMAIL PROTECTED] was heard to say: term. I would also love to find a way in the future to interface with the aptitude dependency problem resolver (that is superiour to the one in libapt). In what way is it superior? Until now, apt-get always found a solution to all the dist-upgrade that I gave him whereas aptitude sometimes didn't. Raphael, When you encounter situations where aptitude can't find a solution, could you please send them to me? aptitude's resolver is designed to be complete, so if it misses valid solutions it's a bug. Thanks, Daniel Hi, I would say aptitude has a very surprising behaviour when upgrading a single package that pulls in a lot of dependencies (this mostly happens when you run unstable, but do not use apt-get upgrade regularly). Let's say I want to upgrade only gnome-terminal, but, due to an ongoing transition, this needs to pull in most of the gnome platform. Then, aptitude's prefered solution would be: 1) hold gnome-terminal 2) still upgrade a few dependencies 3) keep the big transition out Now, this may be correct in the sense that it does not break anything, but it makes little sense: not only does aptitude *not* do what I set out to do in the first place, but it stills does a few unrelated upgrades. Maybe this could be fixed by setting a high penalties on solutions that do not answer the original request of the user. I hope this is clear. Maybe I should keep a log the next time this happens, so I can send a proper bug report. Cheers, BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The GIMP plugins for refocussing blurred images
Bernd Zeimetz a écrit : Heya, actually I'm looking more for somebody who has an actual use-case for those plugins and is willing to test them with a recent version of gimp, I didn't even think about finishing the packages yet. The code is unmaintained for years, and the refocus under gimp 2 is more or less a hack... I don't want to spend time on finishing the package if it doesn't make a sense, especially since upstream seems to be dead. The math used in the plugins is nothing I could fix, otherwise I would just finish the packages, find a sponsor and just wait for bug-reports. Cheers, Bernd Hello, good to here from people still using refocus. I'm using it here from times to times, with a home-compiled version. BTW, I have a patch to make it compile cleanly with gimp 2.2 (last time I tested was 6 months ago, but it should work also with newer versions). I'll take a look at your packages when I have some time. Cheers, Baptiste -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Hi Eric, First I wanted to say again that whatever your final decision, a build system that optionally does the renaming would still be appreciated. It would be even better if the MoFo would do it themselves, of course. I'm sure some users would feel better if they are able to ponder the risks for themselves. Also remember that if the MoFo sends you a cease-and-desist letter, you won't have an advanced warning, so you'd better have plan B ready. Also, your mail made me think about the freedom of software. I have a problem with the fact that you won't aknowledge the MoFo's offer, but will accept it implicitly by keeping the package as is if they don't complain. What difference does it make to the user ? I think what's important, and what DFSG deals with, is what freedom the user has, regardless of what Debian does. What about Firefox ? 1) users may distribute a modified version. 2) users may not call their modified version Firefox. So the question is whether 2) is too obnoxious for the software to still be free. If yes, then Firefox has to go in non-free, if no, then it doesn't matter how it is called in Debian. As a maintainer, you can help make the renaming painless, so that 2) becomes less problematic. IMHO with a suitable building system, 2) would be perfectly acceptable. By keeping the package as firefox, you are making very little change to the user. The only freedom you are taking away from them is: 3) the freedom to call their modified version the same as Debian. This freedom is mostly irrelevant. The only reason a user would want that is if some script directly calls the binary, instead of using the relevant alternative symlink (/usr/bin/mozilla, I think). If the Policy documents that you should not rely on /usr/bin/firefox, 3) is no problem. Then again, what may be desirable for the user is to call their version Firefox, not the same as Debian. Well, I hope I made my point of view as a freedom-concerned user clearer to whoever will make the decision. Btw, I support your calling to the DPL, and I hope he accepts to make the decision, now that everybody had the opportunity to express their view. Keep on with the good work, I don't really care how it's called ! Cheers, BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
1. Completely ignore their Trademark Policy document and let MoFo come to us if they're not happy with our use of the marks. 2. Rename Firefox and strip all trademarks out. 3. Accept MoFo's offer of Debian-specific trademark usage. 4. Try to negotiate some other arrangement with MoFo. Why not do a mix of 2 and 3: - rename all elements that are difficult to change, like package names, or get from the MoFo a licence that applies downstream (It should be easier, as package names are a technical details, mostly invisible to the user) - accept a Debian-specific licence for what can easily be changed - maintain a build option that would do a full rebranding, and set it as the default in the debian source, unless the maintainer field is [EMAIL PROTECTED], or the user overrides the default. That way, the users won't be put at risk, as they are supposed to change the maintainer field. They are still free to build the same package as Debian if they wish. The biggest annoyance for them will be to change the name of the binary in scripts, but as we already allow that ... Scripts in Debian, however, should not rely on the names that may have to be changed. Just my 2 cents, Baptiste -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Another mere user comment on the non-released architectures proposal
Hello, this is my Very Humble (TM) opinion, as I do not have a significant contribution to Debian. First I have to say I understand the general spirit of the proposal. Releasing on an architecture means making promises to the users, for example that a significant portion of the packages in the archive will be available, or that there will be timely security fixes. It's plain normal to make sure these promises are realistic. I'll leave discussion of the exact criteria to more knowledgeable people. However, there are to points about which I feel very strongly: 1) that the portability bugs won't be serious anymore: While shifting work to the porters does not necessarily mean dropping the arch, not being able to build from a common source does for sure. Common sources is what holds Debian together. An arch with their own patches would be a different project already. I understand that all bugs should be fixed eventually, but discriminating the severity of portability bugs according to the arch is clearly the wrong signal. I would rather do something like this: a) severity could still be serious, but only if a patch is provided. This would put the responsability on the porters to work on the bug, but make sure their work is not wasted. b) if the maintainer fears the proposed solution might lead to breakage, he could tag the bug etch-ignore. That way, arch-specific bugs don't hinder the release, but by requiring an action from the maintainer, we make sure the broken package doesn't enter testing when the maintainer just needs one more week to test the patch, or when he is MIA. 2) that the is no clear upwards path: For the sake of fairness (and ultimately freedom), it should be possible for a group of sufficiently motivated porters to move their arch into tier 2, and then into tier 1. While I understand that this part of the proposal needs more maturation, I think it is important that clear guidelines on how to do that are provided. This will help avoid demotivation of the porters and draw the path for constructive work. It will also avoid abuse of unrelated infrastructure, as seems to have happened with the amd64 port. Cheers, BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
