Re: That need to close bugs?
Sarah Hobbs [EMAIL PROTECTED] writes: As one of those who triages various KDE bugs...in the area of KDEBase, in particular, there are around 450 open bugs, we *have* to close invalid bugs. There are around 750, with the INVALID and WONTFIX bugs included. Please correct me, but I suspect that when you mean we have to close invalid bugs, I think you actually mean we need to filter out those incomplete bugs which we don't have the ressources for investiagting further from 'our' 'default' bug listings. (YMMV of course what is your default bug listing. I think tags could help you here, right? There is simply no way to deal with the current lot of open bugs, to get an overview of them all, let alone having the invalid ones in there - the problem gets too great, and you can't solve any of it (and become very demotivated in the process). I agree that you that handling packages with tons of bugs is a real pain. Perhaps the launchpad artists have ideas how to solve this in an elegant fashion? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpG9G1aaS8Gh.pgp Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apturl (security) issues and inclusion in Gutsy
On Mon, Sep 17, 2007 at 10:33:15PM +0200, Wouter Stomp wrote: 1. It's possible to run arbitrary scripts in the preinst/postrm phase of dpkg installation or the installed program itself could be malicious. By allowing the repository to be specified the deb can come from anywhere. So, you've basically got just a yes/no dialog stopping arbitrary code execution. (Not far from UAC and ActiveX in windows.) This is a feature of deb packages in general. ATM, you can provide .deb links that will run gdebi by default. The difference of apturl is that it allows you to ship dependencies of your provided packages as well. 2. Repositories added through apturl could provide packages included in Ubuntu but with higher version numbers with malicious code. ... this is a feature, not an issue. 3. there should be a VERY OBVIOUS visual indication of whether the program is going to be installed from the official repos or some third party site (right now it is not) If this is not obvious enough, we should take a look. ATM you get at least a warning because the 3rd party repository is not signed with a trusted key. 4. It is not well maintained. In the two months that it has been in the archives, 20 bugs have been reported, none have been fixed. Only one had a response and that is a bug about a spelling mistake in the package description. (all together it seems to have been uploaded only to enable the plugin wizard in firefox to work, after whcich it hasn't had any more attention) Are there any serious bugs filed? 5. It hasn't had a lot of testing. It wasn't mentioned in any of the tribe release notes. There hasn't been a post in the dev-link forum or on the mailing lists. So not many people know about it or have tested it. The ffox plugin finder wizard was announced with tribe-5. I agree though, that we should call for more widespread testing/comments, especially how we can raise awareness about the security implications of 3rd party packages. 6. It functions for firefox only, even though solutions to enable it for konqueror and opera have been provided in bug report. This makes it impossible for a website to provide an install this link for an Ubuntu package. They have to mention that it only works if you are running firefox, not if you are a kubuntu user running konqueror for example. I don't think that this is a valid argument. As you say, there are solutions for other browsers available. The fact that they haven't been integrated yet is not an issue of apturl. 7. There is currently no way for a website to know whether apt urls will work on the users operating system. If a website provides an apt install link it will be broken for feisty and earlier ubuntu versions or other linux distributions, How is this different from providing links to .deb packages? Users unaware about architectures et al are not really capable to understand comments next to the link either. If they are, you can do the same for apturl links. 8. making people enter their sudo password in a popup you got from clicking on a link on an arbitary website is definitely not secure. I see the point of this. We should investigate how we can make the installer more spoof-proof. IIRC, it shades the application that started the installer atm, which is a good start and probably hard to spoof with just HTML mechanisms. Maybe we can add more prominent/graphical hints that its now the ubuntu install wizard processing your request? 9. apturl in its current version doesn't show the package description so people don't have a clue about what they are about to install other than the information provided on the website The package description always relies on what the package author provides. Either you trust the package provider or you don't. However, I agree that its worth a wishlist bug to show the package description in the package install confirmation dialog. - Alexander -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: That need to close bugs?
Reinhard Tartler wrote: Sarah Hobbs [EMAIL PROTECTED] writes: As one of those who triages various KDE bugs...in the area of KDEBase, in particular, there are around 450 open bugs, we *have* to close invalid bugs. There are around 750, with the INVALID and WONTFIX bugs included. Please correct me, but I suspect that when you mean we have to close invalid bugs, I think you actually mean we need to filter out those incomplete bugs which we don't have the ressources for investiagting further from 'our' 'default' bug listings. (YMMV of course what is your default bug listing. How would that be better from the user's perspective? If everyone who is working on the receiving end of bugs (triagers and developers) filter out these bugs they will just be silently ignored forever. I'm not sure that gives a better impression. Instead of 'Ubuntu has 30.000 open bugs' we would have 'Ubuntu has 60.000 open bugs, many of which are being actively ignored'. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: That need to close bugs?
On 18/09/2007, Henrik Nilsen Omma [EMAIL PROTECTED] wrote: Reinhard Tartler wrote: Sarah Hobbs [EMAIL PROTECTED] writes: As one of those who triages various KDE bugs...in the area of KDEBase, in particular, there are around 450 open bugs, we *have* to close invalid bugs. There are around 750, with the INVALID and WONTFIX bugs included. Please correct me, but I suspect that when you mean we have to close invalid bugs, I think you actually mean we need to filter out those incomplete bugs which we don't have the ressources for investiagting further from 'our' 'default' bug listings. (YMMV of course what is your default bug listing. How would that be better from the user's perspective? If everyone who is working on the receiving end of bugs (triagers and developers) filter out these bugs they will just be silently ignored forever. I'm not sure that gives a better impression. Instead of 'Ubuntu has 30.000 open bugs' we would have 'Ubuntu has 60.000 open bugs, many of which are being actively ignored'. The reality is the same either way. If there is a way of changing terminology and workflow that makes life no harder for QA and developers but make it easier for users to find existing reports of their bug (no matter what state they are in) then it should be investigated, F Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu 7.10 beta approaching
hplip-gui is marked as a binary-only demotion to Universe. Should it not stay in main, only not being on the Ubuntu and Xubuntu desktop CDs? On Kubuntu it should be even seeded to get onto the CD, as Kubuntu ships the needed python-qt3 by default. Till Colin Watson wrote: The Ubuntu 7.10 beta release is approaching, scheduled for 27th September (https://wiki.ubuntu.com/GutsyReleaseSchedule). Please refer to the milestone overview in Launchpad for a list of remaining items: https://launchpad.net/ubuntu/+milestone/ubuntu-7.10-beta This shows fix-released bugs too; I suggest sorting by assignee then status to produce a more digestible list. If you have bugs on this list, please fix them at the earliest possible opportunity, or (in consultation with other developers and the Ubuntu QA team) un-milestone them if they are not required for beta. If you have bugs you think should be on this list, talk with the Ubuntu QA team about having them milestoned. The beta freeze will begin on 20th September; after that point uploads will require approval from the release team, which will generally only be granted if they fix beta-critical bugs. The toolchain freeze begins now; toolchain changes require approval from the release team. Over the next few days, please pay attention to eliminating inconsistencies in the archive, including: http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html uninstallable packages in main and restricted http://conflictchecker.ubuntu.com/possible-conflicts/gutsy/ undeclared Replaces or Conflicts (contact Robert Collins or Michael Vogt about false positives or if you need help) Archive administrators should spend time ensuring that any pending main-universe promotions and demotions have been processed (http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt). If you are waiting for something on this list, please help out by filing good main inclusion reports. Good luck! -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu 7.10 beta approaching
HI, Till Kamppeter [2007-09-18 13:34 +0100]: hplip-gui is marked as a binary-only demotion to Universe. Should it not stay in main, only not being on the Ubuntu and Xubuntu desktop CDs? On Kubuntu it should be even seeded to get onto the CD, as Kubuntu ships the needed python-qt3 by default. If it gets seeded to Kubuntu, it'll automatically disappear from the component-mismatches.txt files. I keep it in main for now. Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The latest amd64 nightly desktop ISO is 730 megs
On Monday 17 September 2007 06:11:01 Scott Ritchie wrote: Murat Gunes wrote: You may want to file a bug in the ubuntu-cdimage product at Launchpad if you feel the warning should be in some other form and/or made more explicit. Fair enough. Done: https://bugs.launchpad.net/ubuntu-cdimage/+bug/140049 I'm with you, and I'll subscrive it on LP as soon as I go online. and this is not only amd64 CD. it is happening with i386 CDs and even DVDs. -- BUGabundo :o) (``-_-´´) http://Ubuntu.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net signature.asc Description: This is a digitally signed message part. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: That need to close bugs?
On Tue, 18 Sep 2007 19:13:44 +0200, Markus Hitter [EMAIL PROTECTED] said: Am 17.09.2007 um 17:44 schrieb Sarah Hobbs: There is simply no way to deal with the current lot of open bugs, to get an overview of them all, let alone having the invalid ones in there - the problem gets too great, and you can't solve any of it (and become very demotivated in the process). You pretty much ask users to stop filing bugs. If a user can provide all information needed, he can track down the problem him self, so a bug database would melt down to a helpdesk for willing and experienced developers. Each bug filed contains a snippet of information, at least something doesn't work here. Each bug closed because of incompleteness says I ignore your work to the filing person. Unless you redefine closed from problem solved to no interest in working on the problem, of course. I don't completely agree. As an occasional bug-reporter, I would say the following: If the bug state is changed to incomplete, but instructions are provided for the reporter on how to proceed to make the bug complete/useful, then I'm all good. (If the triager cannot provide such instructions for some reason though, say lack of time, then I'm not sure what would be the best course of action.) Best regards Hugo Heden As for the solution - missing resources are a pretty bad excuse to throw away user's contributions. There is no way but to sort the mess and perhaps to refine the search tools. Perhaps this is slightly overexposed, but so far my european 2 cent. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- http://www.fastmail.fm - The professional email service -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: That need to close bugs?
On Tue, Sep 18, 2007 at 10:11:49AM +0200, Reinhard Tartler wrote: Sarah Hobbs [EMAIL PROTECTED] writes: As one of those who triages various KDE bugs...in the area of KDEBase, in particular, there are around 450 open bugs, we *have* to close invalid bugs. There are around 750, with the INVALID and WONTFIX bugs included. Please correct me, but I suspect that when you mean we have to close invalid bugs, I think you actually mean we need to filter out those incomplete bugs which we don't have the ressources for investiagting further from 'our' 'default' bug listings. (YMMV of course what is your default bug listing. I think tags could help you here, right? One tag that I have been using is 'needs-devrelease-testing'. My thought was that this tag would identify bugs that there is enough information to try and reproduce them or that requires specific hardware, but the original reporter has not given enough information for someone to debug the problem. -- Brian Murray @ubuntu.com signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
nspluginwrapper a solution for 64-bit
Would it make sense to promote nspluginwrapper [0] to main for amd64? openSUSE will be including it in 10.3[1]. It seems a better solution user-wise than including the still-alpha gnash. [0] http://gwenole.beauchesne.info/projects/nspluginwrapper/ [1] http://en.opensuse.org/Factory/News#Changes_between_openSUSE_10.3_Alpha_2_and_Alpha_3 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Apturl (security) issues and inclusion in Gutsy
On Tue, Sep 18, 2007 at 12:25:00PM +0200, Alexander Sack wrote: 2. Repositories added through apturl could provide packages included in Ubuntu but with higher version numbers with malicious code. ... this is a feature, not an issue. I'm really not convinced by that. We shouldn't be making it easier for users to replace important system files, and we certainly shouldn't be making it easier for arbitrary third parties to encourage them to do so. -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: nspluginwrapper a solution for 64-bit
On 9/18/07, Todd Deshane [EMAIL PROTECTED] wrote: On 9/18/07, Andrew Jorgensen [EMAIL PROTECTED] wrote: Would it make sense to promote nspluginwrapper [0] to main for amd64? openSUSE will be including it in 10.3[1]. It seems a better solution user-wise than including the still-alpha gnash. [0] http://gwenole.beauchesne.info/projects/nspluginwrapper/ [1] http://en.opensuse.org/Factory/News#Changes_between_openSUSE_10.3_Alpha_2_and_Alpha_3 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss I noticed this solution on Planet Ubuntu awhile back: http://deshantm.livejournal.com/13454.html The link to the original is currently broken, but I have the excerpted install instructions. Todd better yet, the latest version of gusty has the ubuntu firefox plugin manager installed and it give you the choice as to which one you can install. It defaults to the Adobe flash one (which pulls down and installs the 32 bit version properly). The gnash version is not default and like you said in alpha, but it also installs. Looks like the Ubuntu team is one step ahead on this one. Todd -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
