Re: Restricted tab-completion is annoying
Op maandag 15-10-2007 om 17:46 uur [tijdzone +0100], schreef Ian Jackson: I too find the programmable completion very annoying. And I find them very useful, except where they have bugs (e.g. sudo -e, which should work like 'sudoedit'). IMHO tab-completion should complete to what's supposed to be there in most cases, maybe even giving hints if there is a choice between several types of data (e.g. options vs. filenames; where the former start with - or --). OTOH, I think applications should ideally provide their own tab-completion, to make sure the same commandline-parser is used for both completion and interpretation. -- Jan Claeys -- 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-devel-discuss Digest, Vol 11, Issue 27
What's wrong with this picture? Easy: #1. Developers release untested crap and expect the community to find the bugs. Bugs are too boring for developers to be bothered with. #2. Developers working on parallel development threads manage to resurrect old bugs that were killed long ago by other developers. Core problem: lack of management and coordination, aka anarchy. This is sure to offend some conscientious and dedicated people, but this is not aimed at those. More work is needed on fixing the system, which includes motivating some developers work more effectively. I believe Canonical is on the front lines of this war already, but has limited power to influence the mob upstream. I too have filed bug reports that got ignored. When there are 30,000 bug reports this is understandable. The problem is 30,000. -- 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
Firefox stable release update testing
Hello! We will soon be pushing out updates to Firefox in three stable Ubuntu releases: Dapper, Edgy and Feisty and would appreciate help in testing the packages. The candidate packages can be found in the new Mozilla section of the QA website: https://mozilla.qa.stgraber.org/ Please test and report your results there! 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: 4 More days...
On Oct 16, 2007, at 2:06 AM, Scott (angrykeyboarder) wrote: ... I've been running Gutsy for a little over two months now. In part because I wanted to help out. But it's quite disheartening to file bug reports (some of which are seemly serious) only to find that they don't merit any kind of response other than undecided for days (or perhaps weeks) on end. ... There are more people reporting bugs than evaluating new bug reports. And there are, in turn, more people evaluating new bug reports than actually fixing the bugs. The more popular Ubuntu becomes, the bigger both of those disparities will become. So if you're interested in helping out, one route would be to join the Bug Squad. https://wiki.ubuntu.com/BugSquad/GettingInvolved After that you could find ways to encourage others to join the Bug Squad, and/or find ways to make Bug Squad members more efficient. Another route would be to become an Ubuntu developer. https://wiki.ubuntu.com/UbuntuDevelopers After that you could find ways to encourage others to become developers, and/or find ways to make developers more efficient. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ PGP.sig 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: GetDeb Project
Hello , getdeb packages requirements do not meet ubuntu backports requirements, ubuntu backports are based on versions available on the development version, getdeb packages are based on the latest upstream version, some of the software is not even available at the development version. If you are referring to launchpad PPAs ? I have serious doubt that LPs PPAs were planned for more than 100 GBs/day, this is just a doubt I have no idea on the infrastructure supporting launchpad PPAs. The other problem would be about some licenses, some of the software that we provide is freeware (less than 1%), it could not be uploaded to LP PPAs. If you are referring to PPA as a repository in general let me share you the current concerns: - High Availability on mirrors selection - Our current single point of failure is the main web server, the download script takes care of find an available mirror using a round robin selection, apt does not provide yet such type of selection, there is a an apt mirror method (described at https://wiki.ubuntu.com/DynamicMirrorDecisions) but I is not fully implemented yet, and I was unable to verify the current code reliability, I am not aware of a large scale use of this method - Applications selectivity - We do no want to become Ubuntu unstable, we do provide upgrades to several universe, and some main packages, such upgrade must not be automatic, it must be an user explicit option, achieving that with APT requires APT pinning handling, something which is not supported by the current APT based graphical tools, we may need to roll out our own APT based install tool by applying some customizations to GApti ( https://wiki.ubuntu.com/GAptI) . GetDeb is an user friendly UI to the latest software, that was our starting point, I am not sure that after overcoming the current technical APT adoption blockers we will be able to merge with backports at some point, that will be a policy issue to address later, I do not know what is the ubuntu backports team availability to discuss processes and policies, anyway, we are not prepared for that yet. Thanks Well, why not put those packages into ubuntu backports repositories instead (or at least a PPA)? If there are any issues preventing you from doing so, it might be interesting to hear them. And, related to that, have you thought about turning the GetDeb site into a user-friendly UI for the backports repository, making things easier for people who want new versions without adding the backports repository and possibly having to pin certain versions of other packages, etc., etc. -- Jan Claeys -- 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 -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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: Untrusted software and security click-through warnings
On Tue, Oct 16, 2007 at 10:40:46PM +1300, Matthew Paul Thomas wrote: On Oct 16, 2007, at 6:08 AM, Alexander Sack wrote: how about using a captcha-like mechanism to trigger this decisionmaking process? ... For example, have the computer specify that the user must type either twice or backward -- that choice being presented at random -- a word displayed, also chosen randomly, in the dialog box. Requiring this kind of confirmation is as draconian as it is futile ... Such measures also create a new locus of attention; the user is not attending to the correctness of their prior response, thus frustrating the purposes of both the confirmation and the user. No method of confirming intent is perfect ... If the rationale for performing an irreversible act was flawed from the outset, no warning or confirmation method can prevent the user from making a mistake. I completely agree. My point is: if captchas don't help then why would pasting commands from the net help to get the user think about the risk their actions imply? My opinion is clearly that we should come up with a decent and standardized way to add third party applications that we can actually _control_ and design in a way that at least gives our users a chance to educate themselves before taking any action. If you just ignore the demand to install third party applications from third party repositories you will likely train our user-base to just google the internet and follow arbitrary instructions they find - which can't be what we want. - 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: GetDeb Project
On Tuesday 16 October 2007 06:02, João Pinto wrote: Hello , getdeb packages requirements do not meet ubuntu backports requirements, ubuntu backports are based on versions available on the development version, getdeb packages are based on the latest upstream version, some of the software is not even available at the development version. This is largely because you choose to work outside Ubuntu. If you put your efforts into updating the packages in the development version, then many, if not most, of the packages you provide could be done through backports. Scott K -- 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: GetDeb Project
Le mardi 16 octobre 2007 à 11:02 +0100, João Pinto a écrit : GetDeb is an user friendly UI to the latest software, that was our starting point, I am not sure that after overcoming the current technical APT adoption blockers we will be able to merge with backports at some point, that will be a policy issue to address later, I do not know what is the ubuntu backports team availability to discuss processes and policies, anyway, we are not prepared for that yet. Hi, Do you have a list of the applications you are shipping for each version of Ubuntu. Do you do any work to make sure that those updates will not conflict with any of the Ubuntu changes or break user upgrades to the next version of the distribution? That would not be the first time non official packages create issue. Do you think it would be possible to join efforts with the backport team to provide official backports that would benefit users, your team and Ubuntu Sebastien Bacher -- 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-devel-discuss Digest, Vol 11, Issue 27
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 And here's your Please ignore all my bugs pass. Consider it taped to your forehead. When we have users like this, i wonder at the point of looking to fix bugs at all. They clearly don't care, and whatever we do will never be good enough for them. They seem to have no idea of the way things work (including the idea of eating your own dog food), and seem so set in their ways that it seems worthless to teach them the way that the world actually works. Canonical probably can't do much about the volunteer developer community - - them being volunteers. And of course, by writing this sort of mail, you'll just piss them off. And then you get less features, and more bugs. Are you sure you want that? I'd suggest you help out, and only criticize when you've actually been helping out with developing and/or bug triaging for a while. You'd get more credibility that way, rather than being marked as a troll. Hobbsee mico wrote: What's wrong with this picture? Easy: #1. Developers release untested crap and expect the community to find the bugs. Bugs are too boring for developers to be bothered with. #2. Developers working on parallel development threads manage to resurrect old bugs that were killed long ago by other developers. Core problem: lack of management and coordination, aka anarchy. This is sure to offend some conscientious and dedicated people, but this is not aimed at those. More work is needed on fixing the system, which includes motivating some developers work more effectively. I believe Canonical is on the front lines of this war already, but has limited power to influence the mob upstream. I too have filed bug reports that got ignored. When there are 30,000 bug reports this is understandable. The problem is 30,000. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHFLO07/o1b30rzoURAuGKAKDMT/6p1goiyCUC8xNfuAR7OOIv1ACfVoKn 0LQDhARBCt9htY2QbBIlUMo= =n7JQ -END 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: GetDeb Project
Scott, besides myself there other debian/ubuntu contributors which also contribute to getdeb, when they do it for an official project you classify them as insiders, and on other project, outsiders ? What part of our work is not available to the Ubuntu community from both users an developer's perspective ? How does creating a project with a different methodology, goals, and resources make us outside Ubuntu ? As per your comment there is an Ubuntu inside certification that we can get somewhere, how do I get such certification ? I do believe that when doing volunteer work we can do whatever we like to do, I find very odd to receive negative comments, not because we are doing something wrong, but because we are not doing ONLY what some people believe is right. Do you have any arguments against the project besides the outsiders tag ? I do expect to get those so that we can better identify improvement opportunities. Thank you 2007/10/16, Scott Kitterman [EMAIL PROTECTED]: On Tuesday 16 October 2007 06:02, João Pinto wrote: Hello , getdeb packages requirements do not meet ubuntu backports requirements, ubuntu backports are based on versions available on the development version, getdeb packages are based on the latest upstream version, some of the software is not even available at the development version. This is largely because you choose to work outside Ubuntu. If you put your efforts into updating the packages in the development version, then many, if not most, of the packages you provide could be done through backports. Scott K -- 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 -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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
Fwd: GetDeb Project
Sebastien, yes, the site engine uses a mysql db, with app/version/release/distro information. Our users are informed that they should not keep ~getdeb~ packages during dist-upgrades. We do not support distribution release upgrades. We have sent a note last week about preparing for upgrades, including the uninstall procedure: http://www.getdeb.net/docs/uninstall.pdf Thanks 2007/10/16, Sebastien Bacher [EMAIL PROTECTED]: Le mardi 16 octobre 2007 à 11:02 +0100, João Pinto a écrit : GetDeb is an user friendly UI to the latest software, that was our starting point, I am not sure that after overcoming the current technical APT adoption blockers we will be able to merge with backports at some point, that will be a policy issue to address later, I do not know what is the ubuntu backports team availability to discuss processes and policies, anyway, we are not prepared for that yet. Hi, Do you have a list of the applications you are shipping for each version of Ubuntu. Do you do any work to make sure that those updates will not conflict with any of the Ubuntu changes or break user upgrades to the next version of the distribution? That would not be the first time non official packages create issue. Do you think it would be possible to join efforts with the backport team to provide official backports that would benefit users, your team and Ubuntu Sebastien Bacher -- 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 -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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: GetDeb Project
On Tuesday 16 October 2007 10:22, João Pinto wrote: top posting reformatted 2007/10/16, Scott Kitterman [EMAIL PROTECTED]: On Tuesday 16 October 2007 06:02, João Pinto wrote: Hello , getdeb packages requirements do not meet ubuntu backports requirements, ubuntu backports are based on versions available on the development version, getdeb packages are based on the latest upstream version, some of the software is not even available at the development version. This is largely because you choose to work outside Ubuntu. If you put your efforts into updating the packages in the development version, then many, if not most, of the packages you provide could be done through backports. Scott K Scott, besides myself there other debian/ubuntu contributors which also contribute to getdeb, when they do it for an official project you classify them as insiders, and on other project, outsiders ? What part of our work is not available to the Ubuntu community from both users an developer's perspective ? How does creating a project with a different methodology, goals, and resources make us outside Ubuntu ? As per your comment there is an Ubuntu inside certification that we can get somewhere, how do I get such certification ? I do believe that when doing volunteer work we can do whatever we like to do, I find very odd to receive negative comments, not because we are doing something wrong, but because we are not doing ONLY what some people believe is right. Do you have any arguments against the project besides the outsiders tag ? I do expect to get those so that we can better identify improvement opportunities. Ubuntu has official repositories. Getdeb isn't one of them. I don't know what can be clearer than that. If you want to be Official talk to the Ubuntu Tech Board. That's what Backports did. You provide packages that are newer/not in the official repositories. With the exception of packages that are legally questionable for the official repositories, why? If you would focus your work towards the actual Ubuntu repositories, more people would benifit. It's not that I think what you are doing it wrong, but that much of it is duplicative and it'd be better for all if your efforts were more in the official repositories. That said, you are free to volunteer however you see best. To me it seems like your wasting a lot of effort, but clearly you have an agenda that I don't understand. Scott K -- 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: Untrusted software and security click-through warnings
Alexander Sack writes (Re: Untrusted software and security click-through warnings): how about using a captcha-like mechanism to trigger this decisionmaking process? I assume this is some kind of joke but I'm afraid I don't get it. Ian. -- 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: Untrusted software and security click-through warnings
Alexander Sack writes (Re: Untrusted software and security click-through warnings): I completely agree. My point is: if captchas don't help then why would pasting commands from the net help to get the user think about the risk their actions imply? The point is pasting random commands from the net is inherently more scary than saying `yes' a few times. Although we cannot save all of our users, we can save that proportion of them who are likely to hesitate when a website says something like please type `wget thingy | sudo bash'. If you have a concrete suggestion for an approach which is likely to save _in practice_ a greater proportion of our users, please do suggest it. My opinion is clearly that we should come up with a decent and standardized way to add third party applications that we can actually _control_ and design in a way that at least gives our users a chance to educate themselves before taking any action. Absolutely. If we can't provide a sensible way for a users to accomplish their task, we train them to accomplish it in an insane way. So the removal of dangerous features which we have currently ineffectually protected by yes, yes, yes style confirmations should go hand-in-hand with the provision of sensible ways of achieving the same objectives. For tasks which involve third-party software this involves some kind of accreditation/approval process. If you just ignore the demand to install third party applications from third party repositories you will likely train our user-base to just google the internet and follow arbitrary instructions they find - which can't be what we want. Absolutely. Ian. -- 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: GetDeb Project
Am Dienstag, den 16.10.2007, 11:02 +0100 schrieb João Pinto: * getdeb packages requirements do not meet ubuntu backports requirements, ubuntu backports are based on versions available on the development version, getdeb packages are based on the latest upstream version, some of the software is not even available at the development version. I'm not sure this is correct. IIRC we can do direct uploads to -backports too. Although it's of course the safer bet to test the app in the development release first. It'd be great if Ubuntu could benefit from the work you do already and we could put those updated applications (after a review) into the development release. Applications selectivity - We do no want to become Ubuntu unstable, we do provide upgrades to several universe, and some main packages, such upgrade must not be automatic, it must be an user explicit option, achieving that with APT requires APT pinning handling, something which is not supported by the current APT based graphical tools, we may need to roll out our own APT based install tool by applying some customizations to GApti ( https://wiki.ubuntu.com/GAptI) . Alternatively we could put the really unstable applications (I'm sure it's just a small percentage into PPA for testing). GetDeb is an user friendly UI to the latest software, that was our starting point, I am not sure that after overcoming the current technical APT adoption blockers we will be able to merge with backports at some point, that will be a policy issue to address later, I do not know what is the ubuntu backports team availability to discuss processes and policies, anyway, we are not prepared for that yet. It's great you're doing this kind of work and invest that much effort into it. I just believe that you'd have a bigger outreach if the fixes and updates landed in Ubuntu proper. Also users would get security updates and bug fixes and wouldn't have to uninstall the packages again for doing upgrades. Maybe we should schedule a meeting or a phone call to find out where we could cooperate in a better way, make the best use of resources and provide the best user experience. Have a nice day, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- 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: Untrusted software and security click-through warnings
I completely agree with Ian: let's just get rid of GDebi Co. installed by default, thus requiring the users to copy/paste commands to a console. This is IMHO the best warning we can provide, and daring/being able to start a console and do this is already a check of the user will and capacity at the same time. Now, as Alexander says, we must provide easy ways to install missing packages that are approved by Ubuntu. Else we will only be boring users when they install a normal system. We need a list of all reasonably needed packages to make a standard Desktop run (encrypted DVDs, drivers, backports...) and of known trustable repositories. What I like in Ubuntu, it's that constantly new outlooks emerge to create completely new designs that will be fit to the Desktop for a long time. With upstart it was great; today, we are concerned about what we will become when Ubuntu is the first OS used in the word. That's what we need to think of, and that's no joke! ;-) -- 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: Bug: blurry menu icons with most of gnome-themes
Sebastien Bacher wrote: As mentioned on the bug already that's not an Ubuntu specific issue and should be worked upstream. There is no easy workaround known at the moment but if you know one you are welcome to describe it on the bug You know I'm not the kind of guy to damn Ubuntu because of the many bugs that are still open now, but I'm going to end thinking you really don't care. :-) This is in my last mail: I found an easy workaround (see the report too): using 24x24 icons in themes such as Clearlooks restores the normal appearance of all icons. I could not find any drawback. Which was cleary detailed here (two weeks ago): https://bugs.launchpad.net/ubuntu/+source/gnome-themes/+bug/141227/comments/21 I quote my comment: I tried a dirty hack: adding gtk-icon-sizes = panel-menu=24,24 to /usr/share/themes/Clearlooks/gtk-2.0/gtkrc. And now all my Clearlooks icons are perfect in the menus. Should we only fix the erroneous themes (they are in gnome-themes)? Please, could somebody have a look to confirm this? Now it's quite late but this fix is *essential*. If there are drawbacks (and I could find none), they can hardly be worse than now. Cheers -- 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
You devs rock. Thanks for your work.
I'm writing in response to some recent emails on this list that may have had a discouraging effect on the developers and other community members. While Some constructive criticism is needed, I would like to remind people that the developers are essentially volunteers who put a LOT of hard work into making a really great Linux distribution. So, the essence of what I'd like to say is that the Ubuntu devs (and those who contribute in any to the Ubuntu distro) are awesome and deserve a lot of respect. You've done wonders for making this (IMHO) the best distribution out there. Thanks for your work. I look forward with great anticipation to installing Gusty on my box. --Dane -- 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: GetDeb Project
On Tuesday 16 October 2007 11:51, João Pinto wrote: fixed top posting (again). Ubuntu has official repositories. Getdeb isn't one of them. I don't know what can be clearer than that. If you want to be Official talk to the Ubuntu Tech Board. That's what Backports did. You provide packages that are newer/not in the official repositories. With the exception of packages that are legally questionable for the official repositories, why? If you would focus your work towards the actual Ubuntu repositories, more people would benifit. It's not that I think what you are doing it wrong, but that much of it is duplicative and it'd be better for all if your efforts were more in the official repositories. That said, you are free to volunteer however you see best. To me it seems like your wasting a lot of effort, but clearly you have an agenda that I don't understand. Scott K Hello, did you missed the part that I told we do not provide a repository and the reasons for such limitation ? What do official repositories have to do with a non repository based software distribution ? What have official repositories to do with outside of Ubuntu ? Ubuntu is composed by a large community which works on a broad range of areas, it is not just about official repositories. Sure. There is an Ubuntu community. In my opinion you are working outside of it, but to each his owne. We provide packages which are new/not in the official repositories, because, we want them to become available for the users. If your question, is, why don't we follow the MOTU processes to make them available, then we go into another subject which is not about getdeb. Neither would I be able to represent all the individuals which create/submit/request packages to getdeb, some of them do also parallel work, they are submitting both to getdeb and to the official processes, on getdeb it is likely that they will become available in 1 week, the same package, following official processes, may take several weeks, or months, please note that our QA requirements are not as strict(good) as the Debian/Ubuntu packages. For updates to existing packages when the repositories are open for it, the backports timeline can be similar if users are motivated. You've said before that I misinterpret your statements when it sounds to me like you say you unwilling to package things properly, but that's what I'm hearing again. Again my question, which people benefits from Ubuntu official repositories and does not from GetDeb ? The -updates/-security repositories are enabled by default and -backports is there to be easily enabled if someone wants them. GetDeb is an entirely separate thing that people have to go look for. I don't understand why this is so confusing. We are not doing duplicate work, we use a lot of Debian/Universe/Backports build rules, Debian/Universe/Backports can use our building rules, what is the effort duplication you are talking about ? Not if you work separately. If you've created a proper package, why not get it uploaded and backported? We would not keep wasting efforts for 1 year unless we got very positive feedback from our work, which we do. I did not present this project at the beginning because I knew I would run the risk of getting comments like this that would probably break my motivation, comments for which I was not prepared, I was lacking he skills, know-how, team collaboration and strong believe on the value of the project, something which I do have now. Automatix has lots of positive feedback too. It doesn't mean it's a good thing for users to be using. Stop and consider for a minute that the reason you get positive feedback is that you are packaging updates and such and NOT putting them in the official repositories. It's a self fullfiling prophecy. I do respect your personal opinion about the waste of time which is the getdeb work, however I do not appreciate that you use the word official to shield your personal opinion. There are official repositories. I didn't make that up. I do think there is a lot of duplication of effort. We may become an official project, or we may not, it will depend on our ability to improve our processes and trustworthy, still, this is not a present objective, we still have a long road to run on the technical side. Our work is about collaboration, not about competition. How so? I note that you are distributing gnucash 2.2.1 for Feisty: http://www.getdeb.net/app.php?name=GnuCash http://www.getdeb.net/release.php?id=1496 when the same version is available in feisty-backports: https://launchpad.net/ubuntu/+source/gnucash/2.2.1-1ubuntu4~feisty1 Note that because of your ~getdeb naming convention your version will be preferred (have a higher version number) than the feisty-backport. Why do you distribute software that is available from official repositories? Why do you do it in a way the prefers your
Re: You devs rock. Thanks for your work.
It's a fresh relief to see positive comments once in a while :) Thanks for your kind words. On Tue, Oct 16, 2007 at 09:40:04AM -0700, Dane Mutters wrote: I'm writing in response to some recent emails on this list that may have had a discouraging effect on the developers and other community members. While Some constructive criticism is needed, I would like to remind people that the developers are essentially volunteers who put a LOT of hard work into making a really great Linux distribution. So, the essence of what I'd like to say is that the Ubuntu devs (and those who contribute in any to the Ubuntu distro) are awesome and deserve a lot of respect. You've done wonders for making this (IMHO) the best distribution out there. Thanks for your work. I look forward with great anticipation to installing Gusty on my box. --Dane -- 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: regular fsck runs are too disturbing
Onno Benschop wrote: My point is this, an fsck is an 'out of band' check, that is, a check that doesn't rely on other things. It means that while theoretically a file-system maintains its integrity, in practice it cannot. fsck is a useful tool that needs to run regularly and every 30 mounts is pretty reasonable in my opinion. And that is where I completely disagree with you. The reason journals were added to ext3 was to avoid the need to fsck after a dirty unmount. If the fs does not need checked after a dirty unmount, why does it need checked after 30 clean mounts? In practice, in my experience, modern journaling filesystems DO maintain integrity. Also see the plethora of servers out there running ext3 with hundreds of days of uptime. They NEVER run fsck because they are never rebooted, and they suffer no data loss. -- 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: Fwd: GetDeb Project
Hi, first off thanks for conacting us (again). You've certainly put a lot of effort into the GetDeb project, and are obviously (taken from your bandwith estimations) providing a well accepted and wanted service. So thanks for your work improving the Ubuntu distribution! Am Dienstag 16 Oktober 2007 16:28:56 schrieb João Pinto: Sebastien, yes, the site engine uses a mysql db, with app/version/release/distro information. could you make this information available to us in a machine parsable format? Also, do you have some means to rate which popular a package you provide is (e.g. by download statistics)? I guess that way we could try to integrate popular packages into our repositories where adequate. Cheers, Stefan. 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: Bug: blurry menu icons with most of gnome-themes
Le mardi 16 octobre 2007 à 18:38 +0200, Milan a écrit : Please, could somebody have a look to confirm this? Now it's quite late but this fix is *essential*. If there are drawbacks (and I could find none), they can hardly be worse than now. Gutsy is frozen now and new updates will not be accepted, the workaround doesn't look right and the issue is only a cosmetic one and doesn't impact the default theme. This could justify a gusty-updates stable update but it would be better to figure why the icons look blurry and fix that rather than using a workaround Sebastien Bacher -- 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
Hibernate and Restriced Drivers (Was: 4 More days...)
Hello developers, There's the decision to ship with a kernel that breaks suspend/resume on any machine using ATI proprietary drivers (and Nvidia I think, but by that point we'd rolled a custom kernel to fix the Ubuntu breakage). This bug, or this group of bugs, will be a source of annoyance to many users. Basically, when you use restricted drivers (both NVidia and ATI), your system will fail to resume from hibernation most of the time. As restricted drivers are enabled by default, this should be considered a regression from feisty. See for example #34043, which I think is still valid for most NVidia users, or #151471 for a more recent incarnation. Sometimes, following the instructions of: https://help.ubuntu.com/community/NvidiaLaptopBinaryDriverSuspend will help make it work, but often it doesn't. What this means is that suspend won't work out of the box in Ubuntu any more. (And if you try anyway it crashes, with the possibility of data loss). (See [1]) I hope this doesn't sound ungrateful. Ubuntu developers are doing a very good job overall, and dealing with binary blobs isn't an easy task. It's alright to know that something is broken right now, but it's worrying to have the impression that no solution is in the offing at all. I'd love to see some sort of Hibernation team created that tries to tackle the problem in a systematic way. Thanks Paulus (who loves Gutsy otherwise) [1] http://ubuntuforums.org/showthread.php?t=564658 -- 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: GetDeb Project
Hello, For updates to existing packages when the repositories are open for it, the backports timeline can be similar if users are motivated. Is the timeline similar ? Are the users motivated ? Do backports reach a broad audience ? Getdeb/Backports/Ubuntu/Debian/insert your preferred option here Can be much better If . You've said before that I misinterpret your statements when it sounds to me like you say you unwilling to package things properly, but that's what I'm hearing again. What is Properly for Debian, may not be Properly for Ubuntu, or the way around, What is Properly for Getdeb, may not be Properly for Ubuntu, or the way around. Getdeb packages are mixed between Properly for Debian, Properly for Ubuntu and Properly for GetDeb, if you are trying to say that I am unwilling to make every package Ubuntu Properly, you are correct, and it is not a matter of will it is a matter of not having the required resources and skills to do it, the cost is, lower quality for some packages, a few packages just as Properly packaged as grabbing the source and compiling, however they were created by someone which understands how to properly compile linux software. Not if you work separately. If you've created a proper package, why not get it uploaded and backported? Again, this is a personal choice, I do believe the few team members which have the ability to create a proper package from scratch already do also upload it to some official source, Debian or Ubuntu. If you want to guarantee this on an automated fashion, we can arrange that, do you have some entry point for this ? I can add a line to our automated building system to upload the package to the backports building server. However you will get all the packages, because for reviewing, sorry, that is a tedious and time consuming task which depends on the specific requirements you are reviewing, that is not something I could do for the backports. The -updates/-security repositories are enabled by default and -backports is there to be easily enabled if someone wants them. GetDeb is an entirely separate thing that people have to go look for. I don't understand why this is so confusing. GetDeb is the only thing which provides latest versions and brand new software that people need for the current Ubuntu version, on a user friendly fashion, with screenshots, video links, user comments, etc, what is confusing is your continuously comparison between getdeb and a plain repository. If you do believe backports at their current state are sufficient, than, please promote it, make it appealing for the users and spread it. There is so many software to cover, and we are so few. Automatix has lots of positive feedback too. It doesn't mean it's a good thing for users to be using. Stop and consider for a minute that the reason Right, and had a lot of negative too, again, but let's not get out of the subject, the Automatix team already reacted with a clear statement of cooperation. Do you have any evidence to believe that we are harming any system in any way may other than for minor QA failures ? (We did corrupt the mime cache of a few systems, that was a serious issue) . you get positive feedback is that you are packaging updates and such and NOT putting them in the official repositories. It's a self fullfiling prophecy. Not again, are we talking about what getdeb does, or what about others do on a different way ? I note that you are distributing gnucash 2.2.1 for Feisty: Possible causes: - We have packaged it before it was available on backports - We missed to verify that it was on backports, or for some odd reason we decided to publish it knowing that it was already available on backports, regardless of the reason, it was great for those more than 500 users that installed it from getdeb, if we did some duplicated work, bad luck for us, getdeb. Why do you distribute software that is available from official repositories? Read above The -getdeb was changed to ~getdeb, because, as per one of our users suggestion (a long time ago) that would make our packages minor compared to the ubuntu official packages (for the same version). No one raised that problem regarding the backports packages, until now. I will look into this in the future. Thanks -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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: GetDeb Project
Hi, On Tue, Oct 16, 2007 at 04:51:52PM +0100, João Pinto wrote: We provide packages which are new/not in the official repositories, because, we want them to become available for the users. If your question, is, why don't we follow the MOTU processes to make them available, then we go into another subject which is not about getdeb. Neither would I be able to represent all the individuals which create/submit/request packages to getdeb, some of them do also parallel work, they are submitting both to getdeb and to the official processes, on getdeb it is likely that they will become available in 1 week, the same package, following official processes, may take several weeks, or months, please note that our QA requirements are not as strict(good) as the Debian/Ubuntu packages. If you are not interested in working more closely with the Ubuntu project, what was the purpose of your message to ubuntu-devel-discuss and the ongoing dialogue ? -Forest -- Forest Bond http://www.alittletooquiet.net 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
Re: GetDeb Project
Hello, we are interested in working closely with the Ubuntu project, otherwise I would not be here providing a detailed description of the project and clarifying how it does not duplicate the existing official projects. (I already knew this position from a few members on #ubuntu-motu). Official repositories are an important part of the project, I will have all the pleasure in engaging into collaboration activities, preferably automated, as long we pass the Why do you exist? phase. That is the dialog that has been running with Scott, nothing else. Once we skip that phase of the dialog, we will get into the, How can we collaborate?, which I was trying to get into on my previous mail, regarding the ability to upload packages to a backports automated building process. Thanks 2007/10/16, Forest Bond [EMAIL PROTECTED]: Hi, On Tue, Oct 16, 2007 at 04:51:52PM +0100, João Pinto wrote: We provide packages which are new/not in the official repositories, because, we want them to become available for the users. If your question, is, why don't we follow the MOTU processes to make them available, then we go into another subject which is not about getdeb. Neither would I be able to represent all the individuals which create/submit/request packages to getdeb, some of them do also parallel work, they are submitting both to getdeb and to the official processes, on getdeb it is likely that they will become available in 1 week, the same package, following official processes, may take several weeks, or months, please note that our QA requirements are not as strict(good) as the Debian/Ubuntu packages. If you are not interested in working more closely with the Ubuntu project, what was the purpose of your message to ubuntu-devel-discuss and the ongoing dialogue ? -Forest -- Forest Bond http://www.alittletooquiet.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHFRh1RO4fQQdv5AwRAv1lAJ0chY4vg9SdIUmpTTJ/EEMLffHklACgpLu5 GG4rF1gx6rA8HCiDePs2qyE= =G6TL -END PGP SIGNATURE- -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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: Bug: blurry menu icons with most of gnome-themes
Le mardi 16 octobre 2007 à 22:03 +0200, Milan a écrit : - cosmetic may be high priority if we consider that the proper sense of the word should be forbidden. The default theme has no problems, but gnome-themes are installed *by default* and is simple to use, so it's like it was default. We should expect more than half the users use gnome-themes There is very few bugs or comments about that for the moment though. The issue is only cosmetic in the sense that's not a security issues or doesn't impact on what you can do using the distribution the release will be: Ubuntu is not able to guarantee a basic clean interface from a version to another. Whatever the new features can be in other domains. The issue is not likely specific to Ubuntu and the upstream theme didn't switch to 22x22 this cycle, is the issue new in gutsy? - why gnome-themes use 22x22 icons when Human uses 24x24? I can't find any reason to this, and I don't know whether it was the case in previous versions or whether it has changed. The correct upstream format is 22x22, the Human theme could use some work and should be update, the gtkrc has been updated with the 24x24 workaround but that's not the correct way -- 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: GetDeb Project
On Tuesday 16 October 2007 16:19, João Pinto wrote: Once we skip that phase of the dialog, we will get into the, How can we collaborate?, which I was trying to get into on my previous mail, regarding the ability to upload packages to a backports automated building process. By policy (given out by the Ubuntu Tech Board) backports only come from the developmental repository. I don't understand why you keep wanting to bypass that step. The packaging standards for backports are the same as for regular Ubuntu development repositories. What would uploading packages for automated building accomplish? Scott K -- 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: Fwd: GetDeb Project
Hello, You can get a snapshot of the current app tables: http://www.getdeb.net/tmp/getdeb_db_16_Oct_2007.sql.gz I don't have a detailed data model documentation, here is a quick guide for the apps info: gd_app - Application info entry gd_app_version - Version record gd_app_release - Release of a specific version for a specific distro gd_app_download - Download counts per app release (distro_id is included for summary count) Best regards, 2007/10/16, Stefan Potyra [EMAIL PROTECTED]: Hi, first off thanks for conacting us (again). You've certainly put a lot of effort into the GetDeb project, and are obviously (taken from your bandwith estimations) providing a well accepted and wanted service. So thanks for your work improving the Ubuntu distribution! Am Dienstag 16 Oktober 2007 16:28:56 schrieb João Pinto: Sebastien, yes, the site engine uses a mysql db, with app/version/release/distro information. could you make this information available to us in a machine parsable format? Also, do you have some means to rate which popular a package you provide is (e.g. by download statistics)? I guess that way we could try to integrate popular packages into our repositories where adequate. Cheers, Stefan. -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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: GetDeb Project
On Tue, 2007-10-16 at 22:03 +0200, Sebastien Bacher wrote: No, that's not something we can know from a summary mail, we would need to look at the packages you are distributing. Do you have a bug tracker where users can send issue they have using the getdeb versions? https://bugs.launchpad.net/getdeb.net/ BTW, I was really excited when getdeb came out about a year ago. I thought, wow, here's a way to get the latest versions of apps. I was hoping that all these new packages would get MOTUed by João and find their way into backports, but that hope never became reality. Then after using getdeb for a while, the packages I was looking for came into the official repository and I got automatic updates across all my machines (having five different versions of GNOME References on each of my machines was a pain). Sebastien Bacher -- Michael R. Head [EMAIL PROTECTED] suppressingfire.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: GetDeb Project
Hello, That policy is development oriented. Our target is the current release. A backport may be complex or not, it may even be impossible (it may depend on core library upgrades), making sure a package can be successfully build and successfully runs on both development and current, requires twice the time for the reviewing (which is the most important process), we have a large requests queue already, we can't afford that extra effort. Our focus is the current release version, not the development version, for the development version there is already the MOTU team which does have much more human resources and which does a great job. Uploading to the automated system would guarantee that you would get all the packages that we produce, I understood that your main concern is that we also provide packages to the official repositories, on this case because we work with current version, it would be for backports. Thanks 2007/10/16, Scott Kitterman [EMAIL PROTECTED]: By policy (given out by the Ubuntu Tech Board) backports only come from the developmental repository. I don't understand why you keep wanting to bypass that step. The packaging standards for backports are the same as for regular Ubuntu development repositories. What would uploading packages for automated building accomplish? Scott K -- 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 -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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: GetDeb Project
On Tuesday 16 October 2007 16:52, João Pinto wrote: top posting fixed. 2007/10/16, Scott Kitterman [EMAIL PROTECTED]: By policy (given out by the Ubuntu Tech Board) backports only come from the developmental repository. I don't understand why you keep wanting to bypass that step. The packaging standards for backports are the same as for regular Ubuntu development repositories. What would uploading packages for automated building accomplish? Scott K Hello, That policy is development oriented. Our target is the current release. A backport may be complex or not, it may even be impossible (it may depend on core library upgrades), making sure a package can be successfully build and successfully runs on both development and current, requires twice the time for the reviewing (which is the most important process), we have a large requests queue already, we can't afford that extra effort. For virtually all backports a package from the development release can be built and used in the current release. So far I've only seen one source backport (where the source package needs to be changed) for Feisty from Gutsy. For a well designed package the extra effort is nil. Our focus is the current release version, not the development version, for the development version there is already the MOTU team which does have much more human resources and which does a great job. Well we could certainly use more help. Getting things into the developemental release and then backporting only need add a few days to the process. Both could be served for essentially the same effort. Uploading to the automated system would guarantee that you would get all the packages that we produce, I understood that your main concern is that we also provide packages to the official repositories, on this case because we work with current version, it would be for backports. If you could get the Tech Board to buy off on that, then it could be considered, but there would still have to be a packaging review which is the majority of the delay regardless of if you are targeting the current release or the development release. Having done both a fair amount of backporting and packaging for developmental releases, I don't understand your objection. In practice the problems you raise just don't come up very often. I understand you have a nice web front end (and that's fine). My concern is that you are producing duplicate packages when if we were working together we could get more done. You keep saying you want to work together, but that you won't. I don't understand which you want. Are you going to remove gnucash from getdeb now that you know it's available through backports? Scott K -- 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: GetDeb Project
Hello Michael, we had this conversation at that time, I was a single person working on getdeb. I had no time to MOTIfy and keep Getdeb. Getdeb is not just about software packaging, it is a software portal a PHP/MySQL custom engine, with registered users which require attention, is is about identifying packaging candidates, etc, etc. Now we do have a small team, but the getdeb requirements are also much higher, I have a full time job and a full spare time project. I do not have the TIME to work on any other activity. Besides the users feedbacks there are the new members which joined the team, those more than 20 people which translated the site and those occasional debian package maintainers or upstream authors which contribute. Backports maybe a great project, Universe is great, however there is people like me which does believe that GetDeb has a role on the Ubuntu software options. This is not a religion, is not like we can convert getdeb work to MOTU work, we both work great because we love what we do and how we do, we respect our policies, and we have our own improvement goals. I would love to be a MOTU together with GetDeb, eventually that would help collaboration, however, becoming a MOTU does require some time (I know the process), time which I do not have. GetDeb may get a negative attention from the Ubuntu Tech Board, we may be forced to shut down the project, whatever, that really does not matter, what does matter is that we believe that we are doing a good thing for the Ubuntu community and open source in general, we are not hurting Ubuntu, we are promoting it. But yes, because we do not work close with the official repositories teams there maybe events of conflicting and problematic upgrades, for such reason we have recently requested the users to uninstall all of our packages prior to an upgrade. This is a point on which we definitively need to improve. Thanks 2007/10/16, Michael R. Head [EMAIL PROTECTED]: On Tue, 2007-10-16 at 22:03 +0200, Sebastien Bacher wrote: No, that's not something we can know from a summary mail, we would need to look at the packages you are distributing. Do you have a bug tracker where users can send issue they have using the getdeb versions? https://bugs.launchpad.net/getdeb.net/ BTW, I was really excited when getdeb came out about a year ago. I thought, wow, here's a way to get the latest versions of apps. I was hoping that all these new packages would get MOTUed by João and find their way into backports, but that hope never became reality. Then after using getdeb for a while, the packages I was looking for came into the official repository and I got automatic updates across all my machines (having five different versions of GNOME References on each of my machines was a pain). -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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: GetDeb Project
Hello, I am not going to touch the gnucash package because the Feisty getdeb archive is frozen. When a new release arrives, we also get a frozen archive, on our case, for the past release. Still, you can request it's removal by reporting is as a bug at: https://launchpad.net/getdeb.net/ If we believe there is a good reason for an exception, the package will be removed. Thank you -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- 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: Restricted tab-completion is annoying
I too find the programmable completion very annoying. And I find them very useful, except where they have bugs (e.g. sudo -e, which should work like 'sudoedit'). IMHO tab-completion should complete to what's supposed to be there in most cases, maybe even giving hints if there is a choice between several types of data (e.g. options vs. filenames; where the former start with - or --). OTOH, I think applications should ideally provide their own tab-completion, to make sure the same commandline-parser is used for both completion and interpretation. I don't think the debate should be about how useful it is or how annoying it is. If I have a file called myfile.jpg how does *LINUX* know what the file is? You might think it's a picture because of the .jpg extension--but firefox will tell you based off the MIME TYPE. So will the file command. I'm not saying we need to integrate mime typing into tab completion--because it would probably slow things to a crawl, but since we can't do it the RIGHT way, we need another approach. Here's what I see--correct me if I'm wrong, or add to it: * Tab completion based off a file name or part of a file name is wrong. You don't know if myfile.jpg is really a jpg or a pdf or a text file. Take my original firefox example where myfile.asp was really a PDF. And just last night I tried to get mplayer to play a WMV file (windows media) and it wouldn't auto-complete. Although it played just fine. * Because restricted tab-completion is broken, we need to find a solution * A better way would be mime-type completion--but it would probably slow tab-completion to a crawl when you had more than a few files. (A quick non-scientific test in a src directory shows 17 files all less than 100K took 1.017 seconds) * Tracker seems pretty cool, but I know nothing about it. Can we query it for a file's mime type and make it fast? * Disable it or enable it by default but have an option to disable/enable it system wide and/or per-user. And just to be clear, I'm not talking about disabiling the ability to do something like svn checTAB to get svn checkout or tab-completion of ssh hostnames. I am specifically talking about limiting the list of files presented based on the application you are trying to start and the file extensions. What Ian said a few messages up the thread hits the nail on the head for me: Predictability is far far more important than functionality for completion to be an effective useability aid. I think the best way to solve this is by using the last option above. Either enable or disable it by default, but provide options to enable/disable it on a per-user or per-system basis. It's not my right to tell someone they can't run their system using broken tab-completion if they want it that way. -A -- 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: You devs rock. Thanks for your work.
This has been the best release cycle so far for me. I have found the developers more responsive than ever and a good number of the bugs I'm most interested in have been fixed. There are also some lovely nuggets of joy in the 7.10 release like finally having a GUI method for installing a bluetooth mouse (kudos to the bluez devs!). My experience with the system-config-printer folks was also very gratifying. And the work on xserver-xorg-video-intel has not gone unnoticed on my machine. Many many thanks to you all! - Andrew Jorgensen -- 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: GetDeb Project
On Tuesday 16 October 2007 17:27, João Pinto wrote: Hello, I am not going to touch the gnucash package because the Feisty getdeb archive is frozen. When a new release arrives, we also get a frozen archive, on our case, for the past release. Still, you can request it's removal by reporting is as a bug at: https://launchpad.net/getdeb.net/ If we believe there is a good reason for an exception, the package will be removed. OK. Well then I guess already in an Ubuntu archive isn't a good reason (you don't need me to write a bug report for that as you already know). I still don't see how you want to cooperate? Not distributing packages available through the archive would be a good start. Scott K -- 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: GetDeb Project
On Tuesday 16 October 2007 19:06, Krzysztof Lichota wrote: João Pinto napisał(a): I note that you are distributing gnucash 2.2.1 for Feisty: Possible causes: - We have packaged it before it was available on backports - We missed to verify that it was on backports, or for some odd reason we decided to publish it knowing that it was already available on backports, regardless of the reason, it was great for those more than 500 users that installed it from getdeb, if we did some duplicated work, bad luck for us, getdeb. Backports is sometimes not a proper solution, because it causes upgrade to all the newest versions of a lot of packages. For example, if user wants to upgrade amarok but not kopete, he can do it using GetDeb, but he cannot do it using backports (forget package pinning/repository priorities, it is in no way intuitive and cannot be done by average users). Just my 2c. Generally I enable backports, install what I want, and the disable it again. That I think most people can do. It doesn't cause upgrade to all the newest versions of a lot of packages. That only happens if the user specifically requests it. Of course it's not rare for people to run with -proposed (even) enabled all the time. We recently had a problem with an svn upload to feisty-proposed and quite a few people tripped on the bug who apparently had no idea they were downloading from a testing repository. Getting repos enabled does not appear to be a major problem. Scott K -- 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: GetDeb Project
Scott Kitterman napisał(a): Generally I enable backports, install what I want, and the disable it again. That I think most people can do. Maybe they can, but: a) they have to know about it b) it is very inconvenient c) you do not get updates to installed app (i.e. security fixes) It doesn't cause upgrade to all the newest versions of a lot of packages. That only happens if the user specifically requests it. Unless after enabling backports and updating repo a nice upgrade icon appears which inexperienced user will click and fetch the updates. Maybe if there was a graphical inteface to do what you described it would do, but currently it is rather a hack around the problem. Krzysztof Lichota signature.asc Description: OpenPGP 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
Re: regular fsck runs are too disturbing
On 17/10/07 01:33, Phillip Susi wrote: Onno Benschop wrote: My point is this, an fsck is an 'out of band' check, that is, a check that doesn't rely on other things. It means that while theoretically a file-system maintains its integrity, in practice it cannot. fsck is a useful tool that needs to run regularly and every 30 mounts is pretty reasonable in my opinion. And that is where I completely disagree with you. The reason journals were added to ext3 was to avoid the need to fsck after a dirty unmount. If the fs does not need checked after a dirty unmount, why does it need checked after 30 clean mounts? In practice, in my experience, modern journaling filesystems DO maintain integrity. Also see the plethora of servers out there running ext3 with hundreds of days of uptime. They NEVER run fsck because they are never rebooted, and they suffer no data loss. I am subscribed to the list, there is no need to send this to me directly. I have personal experience where a modern journalling file system (ext3) does *not* maintain integrity. I have now had three cases where the journal corrupted for no particular reason, causing the kernel to remount my drive read-only. A read-only and non-destructive read-write test failed to uncover any problems. My point was, and it still stands, theoretically a file-system maintains its integrity, in practice it cannot. fsck is the tool that catches the difference between theory and practice. -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [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: Archive frozen for Gutsy release
Steve, Pretty major bug, yet seemingly simple fix, affects a fair number of people. https://bugs.launchpad.net/ubuntu/+source/hal/+bug/127773 Booting 2.6.20-16-generic gives me a regular, working battery. 2.6.22-14-generic is the problem. Matt On 10/5/07, Steve Langasek [EMAIL PROTECTED] wrote: Hi all, We continue to roll on towards release of Gutsy, and as of today the archive is now frozen. Many thanks to all whose contributions have gotten us to this point! This freeze means that the only uploads that will be accepted for gutsy between now and release are uploads fixing specific, release-relevant bugs. There are still a number of bugs to try to resolve before the release candidate goes out on October 11. A list of these milestoned bugs can be found at https://launchpad.net/ubuntu/+milestone/ubuntu-7.10-rc. Your help in hammering these out is appreciated. If you have bugs which you believe should be listed there but aren't yet, please get in touch with me or another member of the release team. -- ubuntu-devel-announce mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce -- 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: Archive frozen for Gutsy release
On 10/16/07, Scott Kitterman [EMAIL PROTECTED] wrote: Pretty major bug, yet seemingly simple fix, affects a fair number of people. https://bugs.launchpad.net/ubuntu/+source/hal/+bug/127773 Booting 2.6.20-16-generic gives me a regular, working battery. 2.6.22-14-generic is the problem. What's the fix? I'd love to try it out? Based on the comment and the description in the linked bug, it is the linux-image-2.6.22-14-generic package; he is saying that a linux-image-2.6.22-16-generic fixes things. And yet, AFAIK, no such package exists... ??? Yes, I'm confused too. CK -- 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: Archive frozen for Gutsy release
On Tuesday 16 October 2007 21:58, Conrad Knauer wrote: On 10/16/07, Scott Kitterman [EMAIL PROTECTED] wrote: Pretty major bug, yet seemingly simple fix, affects a fair number of people. https://bugs.launchpad.net/ubuntu/+source/hal/+bug/127773 Booting 2.6.20-16-generic gives me a regular, working battery. 2.6.22-14-generic is the problem. What's the fix? I'd love to try it out? Based on the comment and the description in the linked bug, it is the linux-image-2.6.22-14-generic package; he is saying that a linux-image-2.6.22-16-generic fixes things. And yet, AFAIK, no such package exists... ??? Yes, I'm confused too. No, it was 2.6.20-16 (e.g. the current Feisty kernel). I agree this is a kernel regression, but I'm not aware of any fix. I have an L400 too, so I'd really like to see this fixed (I'll be sticking with Feisty for anything but development work because of this and a power management bug). Scott K -- 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
