Re: GIMP *final* release for Gutsy?
Aaron C. de Bruyn: So you are saying that we should react to new versions by packaging the up on the basis that there are probably users that could maybe be having bugs but haven't reported them. We should react on that basis only to new, stable versions of packages where the current version in Ubuntu is an unstable, non-final version. Upstream is presumably not-final for a reason. I'm sure by now just about every package in Gutsy has an updated version. It would take a *TON* of development time constantly updating packages. We'd only have to do this *once* for each package of which a non-final version was released in Ubuntu final. Once the final version of the package is available, there need be no more updates (beyond what are already done). Hopefully a commitment to doing this extra packaging work after the Ubuntu release would dissuade us from including non-final package releases in final Ubuntu releases. -- Greg -- 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: Password-protect grub interactive commands (was: rationale of root access from boot)
On Nov 12, 2007 2:15 PM, Scott James Remnant [EMAIL PROTECTED] wrote: On Sat, 2007-11-10 at 14:06 +0800, Nicolas Deschildre wrote: [...] For the simplest installations, GRUB could perhaps read /etc/shadow and accept any user's password -- but that would be error-prone, open to exploit, and wouldn't support the kinds of installations you talk about later in this thread: corporate environments which often use centralised authentication. You're right, I overlooked that. And adding Jan Claeys' good remark on the keyboard layout, I'm now convinced that password protecting grub is not good by default. Thanks for your comments. This is EOT for me. Nicolas -- 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: A Wine-like compatibility layer to run Mac OS X programs on Linux?
Am Montag, den 12.11.2007, 00:29 +0100 schrieb Jan Claeys: Op vrijdag 09-11-2007 om 05:32 uur [tijdzone +0100], schreef Sebastian Heinlein: AFAIK you are not allowed to virtualize MacOS. Which is not enforceable in how many countries...? :) Nevertheless you should respect the authors' decisions on how and under which license they want to publish their software. Nobody is forced to use it. As an Open Source developer I would also demand to do so for my software too. 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: GIMP *final* release for Gutsy?
On Mon, 12 Nov 2007 22:47:34 +1100 Sarah Hobbs [EMAIL PROTECTED] wrote: Greg K Nicholson wrote: We'd only have to do this *once* for each package of which a non-final version was released in Ubuntu final. Once the final version of the package is available, there need be no more updates (beyond what are already done). Hopefully a commitment to doing this extra packaging work after the Ubuntu release would dissuade us from including non-final package releases in final Ubuntu releases. I suspect that if we actually had people offering to do this (and this is quite similar to the already-existing backports), and did reasonable QA tests, etc, then this would all become more feasible. But, when you're trying to stretch already busy people, who are mostly volunteers, and will tend to work on whatever they like, and to try and fit them into your mold of what you want them to do, you're always going to meet trouble. So, anyone willing to step up to work on stable release updates? If Ah yes, BUT you need to be a MOTU to upload new releases and the process of becoming a MOTU or contributions by non-MOTU has been discussed before. Just see the archives here (GetDeb Project (Why I participate)) or on the MOTU list (Subject: non-MOTU Hopeful contributions (was:: GetDeb Project (Why I participate)) you don't know packaging, you can learn it. Same applies to bug triaging. Don't even bother giving excuses such as I can't program, I can't do actual development - well, start with something simpler like bug triage, and then work your way up. How do you think the current developers got where they did? All these excuses seem to be hiding the major excuse - I want this fixed, but I want someone else to fix it for me, and don't want to have to put in the hard work myself Well I package software, I'm just not a MOTU for reasons discussed in the previously mentioned threads. Just a thought... Hobbsee -- Peter van der Does GPG key: E77E8E98 IRC: Ganseki on irc.freenode.net Blog: http://blog.avirtualhome.com Jabber ID: [EMAIL PROTECTED] GetDeb Package Builder http://www.getdeb.net - Software you want for Ubuntu signature.asc 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: GIMP *final* release for Gutsy?
On Mon, 12 Nov 2007 23:52:29 +1100 Christopher James Halse Rogers [EMAIL PROTECTED] wrote: But you don't need to be a MOTU to do the work, and since gimp is in main, it doesn't much help being a MOTU either. The uploading to the archives part is by far the quickest and simplest part of the whole process. Once you've updated the packaging, and tested it thouroughly yourself it will be much less work (read: much more likely to happen) for the core-dev to pick it up, check it for sanity, and (hopefully) upload to gutsy-proposed. Where you now get to thoroughly test it before it gets into -updates. It's not as simple is that, you need a sponsor for your patches to be approved. And currently there are 45 bugs in the sponsorship queue, 5 are committed, 4 in progress, 3 triaged, 16 confirmed (one as late as 2006-03-03) and 17 new the oldest dating back to 2006-12-14. So it comes down to workload at the MOTU side. I won't discuss this here anymore, like I mentioned we have had this thread before on two mail listings. Not helping because you don't have upload privilages to the archives seems a pretty poor excuse. You really don't need to be able to upload directly to the archives to usefully contribute! You don't have to be aiming to become a MOTU in order to usefully contribute. Chris Halse Rogers -- Peter van der Does GPG key: E77E8E98 IRC: Ganseki on irc.freenode.net Blog: http://blog.avirtualhome.com Jabber ID: [EMAIL PROTECTED] GetDeb Package Builder http://www.getdeb.net - Software you want for Ubuntu signature.asc 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
Benefit of Compiz to audio work?
The Ubuntu Studio team is considering shipping Compiz (with a minimal config) in Ubuntu Studio-Hardy 8.08. Some have said that moving the drawing of windows off the the GFX card would help the load on the CPU and thus keep xruns to a minimum. Any thoughts/ideas on this one? -Cory \m/ -- 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: Password-protect grub interactive commands
OK, just forget the GRUB password idea, I've understood how it can become a complete mess. Sorry for the idea... But what about that? unggnu wrote: snip I like the way Ubuntu handles root that always sudo is needed so why we don't make it with Recovery mode too? Just don't autologin root like root has a password. Why not let the user login in with his user and then use sudo to gain root access or set the user password for root and disable the account? With this no grub password/lock is needed but there is still basic security. If you are afraid if people forget their password why not make a little program on Live CD which can make that for you? Everyone can boot a CD and reset their password but only if they have bios/boot access like every private person. I really second this idea, doing that and locking GRUB for any modification of kernel parameters except recovery mode would be a real security improvement. We should not let Windows XP overdo Linux here. And anyway, there is the LiveCD if really needed. -- 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: GIMP *final* release for Gutsy?
Dean Sas wrote: So we're actually getting 2.4.1 (or something very much like it), but labelled “2.4.0rc3”? Precisely. Often Ubuntu packages might include patches from upstream that haven't yet been made part of a release. See Emmet's review for the exact details in this case. If that is the case then the package should have had the version string 2.4.0+2.4.1-rc3 to indicate that it is the release candidate for what will be 2.4.1. -- 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: GIMP *final* release for Gutsy?
Peter wrote: It's not as simple is that, you need a sponsor for your patches to be approved. And currently there are 45 bugs in the sponsorship queue, 5 are committed, 4 in progress, 3 triaged, 16 confirmed (one as late as 2006-03-03) and 17 new the oldest dating back to 2006-12-14. So it comes down to workload at the MOTU side. I won't discuss this here anymore, like I mentioned we have had this thread before on two mail listings. Most of the main developers have been away at UDS, and then at the Canonical Company Conference (All hands), including the guy who allocates the sponsorships around, for the main queue. I'm guessing it's just a particularly busy time for them, particularly as most of them are trying to get the base system merges done (ie, priority: essential stuff, toolchain, etc). And, again, MOTU != core dev. MOTU's can not upload directly to main. Therefore, it's not a question of workload on the MOTU side at all - and so i suspect that the above arguments, which all applied to MOTU, not core dev, are null and void. Excluding the quality arguments. Hobbsee -- 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: GIMP *final* release for Gutsy?
Aaron C. de Bruyn: It boils down to this: If users aren't running into bugs, why repackage? Because having “Release Conadidate” on the splash screen and “rc” in the About box gives users the impression that this is not a trustworthy, final version of GIMP. Kinda like how hundreds of thousands of people used the old ICQ 99b (or whatever the version was) client that was listed as a 'beta' for years. ...or how people used the beta version of gmail. I honestly didn't notice that GIMP said Release Candidate on the splash screen until this discussion came up, and I use it daily. My wife also uses it daily, and she's not a geek like me--just a home user. She never realized it either. Maybe we're just completely oblivious. But I think most people won't care what it says--they'll just run it. ...of course someone else pointed out that it actually says Release Conadidate instead of 'candidate'. Heck--I missed that too. But that's something that should be fixed. Just because it says Beta or Release Candidate or isn't a final version is not a reason to update the package. Even the final, officially approved, non release candidate version will have bugs. ...and they will have to be fixed. So why not just fix the bugs when they are reported. I'm not trying to be a jerk--I just don't see the point in updating because of the version string. I do see a point in updating due to a bug. -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: GIMP *final* release for Gutsy?
Aaron C. de Bruyn wrote: Aaron C. de Bruyn: It boils down to this: If users aren't running into bugs, why repackage? Because having “Release Conadidate” on the splash screen and “rc” in the About box gives users the impression that this is not a trustworthy, final version of GIMP. Kinda like how hundreds of thousands of people used the old ICQ 99b (or whatever the version was) client that was listed as a 'beta' for years. ...or how people used the beta version of gmail. I honestly didn't notice that GIMP said Release Candidate on the splash screen until this discussion came up, and I use it daily. My wife also uses it daily, and she's not a geek like me--just a home user. She never realized it either. Maybe we're just completely oblivious. But I think most people won't care what it says--they'll just run it. ...of course someone else pointed out that it actually says Release Conadidate instead of 'candidate'. Heck--I missed that too. But that's something that should be fixed. Just because it says Beta or Release Candidate or isn't a final version is not a reason to update the package. Even the final, officially approved, non release candidate version will have bugs. ...and they will have to be fixed. So why not just fix the bugs when they are reported. I'm not trying to be a jerk--I just don't see the point in updating because of the version string. I do see a point in updating due to a bug. -A we all know that version numbers don't matter and especially in the OSS world where there is no commercial reason to bump to a .0 number just to make it look stable, and for myself i could not care less wich version it has as long as it works. (there are numerous times i had bugs and crashes in so called stable releases) but then again, everybody on this mailing list is not the target audience for bug #1 and if Ubuntu is aiming for allround usage by the masses, some things can be learned from the competitors by spending some more time on presentation of the product. the whole purpose of Ubuntu is to bring a polished and shining desktop experience for the non-techie end user who cares more about pretty colours then the underlying processes, otherwise they might as well run Debian. i must say that Ubuntu has come a long way in achieving this, but the Release Conadidate definetely shows that improves still need to be made, the appearance of a splash screen is not something to be judged by a developer but by the Canonical art commision. -- 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
