KDE update
Can someone please explain to me why I'm asked to download 32.2Mb of an update that has as a description: No change rebuild to satisfy build dependency for kdepim security update What I'm really asking is these three different questions: 1. Why am I downloading something that is no different from the previous version. As I understand the packaging system, any update to kdepim should be more than able to cope with being part of a specific version using depends and requires. 2. Why am I downloading that much data for just version number changes, if that's really all that is changing? 3. Why am I downloading these updates when I don't actually have kdepim installed at all? I'm all for keeping my system up-to-date, but this seems like such a waste of time and effort for all involved, more like a $EA or NOP from 6502 days ;-) PS: Running intrepid -- Onno Benschop Connected via Bigpond NextG 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 - o...@itmaze.com.au -- 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: KDE update
On Wednesday 04 March 2009 3:50:32 am Onno Benschop wrote: Can someone please explain to me why I'm asked to download 32.2Mb of an update that has as a description: No change rebuild to satisfy build dependency for kdepim security update What I'm really asking is these three different questions: 1. Why am I downloading something that is no different from the previous version. As I understand the packaging system, any update to kdepim should be more than able to cope with being part of a specific version using depends and requires. The dependencies are listed in the package. To change the dependencies inside the package, the whole package has to be re-issued. 2. Why am I downloading that much data for just version number changes, if that's really all that is changing? Because the entire thing is one package. 3. Why am I downloading these updates when I don't actually have kdepim installed at all? Not Kontact, Kmail, Korganizer...? -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo 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: Messaging Indicator (was: Notifications: uselessness of)
Olá Ted e a todos. On Monday 02 March 2009 15:17:20 Ted Gould wrote: You should have it installed, but if not, you should install the indicator-messages package. ah so thats what that is. I've had that for weeks now! Having both left and right click do the samething is bad UI, no? -- Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com) (``-_-´´) http://LinuxNoDEI.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by... 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: Messaging Indicator (was: Notifications: uselessness of)
Olá Ted e a todos. On Monday 02 March 2009 22:53:54 Ted Gould wrote: One of the goals of this interface is to provide an easy way for KDE applications to work on GNOME and vice versa while still providing this type of functionality. I really hate that people are forced to choose a set of programs based on their desktop to avoid loosing functionality of their favorites. I hope that we're on a path to users choosing the best application independent of the desktop they like. Like no support of Kmail notifications on GNOME? -- Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com) (``-_-´´) http://LinuxNoDEI.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by... 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: Developer Documentation feedback
Olá Jorge e a todos. On Tuesday 03 March 2009 00:00:08 Jorge O. Castro wrote: I am interested in gathering feedback on the state of our developer documentation. I just don't want feedback from doc people but from Ubuntu developers themselves who have been consuming these docs. Currently the developer link from ubuntu.com points people to this page: https://wiki.ubuntu.com/UbuntuDevelopment snip I am wondering if perhaps we should have a more focused set of pages that makes it easier for people to drill down into a specific area of development as opposed to One Big Page or if we should start looking at something a bit more structured? I've heard many developer-friends of mine (who are not involved in Ubuntu) say that they wish Linux had an equivalent of the documentation that is in something like MSDN because they can never find anything and get lost in a bunch of wiki pages. What I miss most is a full index (like TRAC has) (with optionally some snippets of the text inside). Navigating our Wikis is a mess without Google. -- Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com) (``-_-´´) http://LinuxNoDEI.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by... 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
TurnKey Linux release 12 new software appliances based on Ubuntu 8.04.2 LTS
Hi guys, We would like to invite the community to collaborate with us in the development of the next batch of Ubuntu-based software appliances. We just finished updating the site for our most exciting and ambitious batch of releases yet. The 2009.02 release, based on Ubuntu 8.04.2 LTS, includes 12 new software appliance images and features extensive improvements to usability, security and stability. We've done a terrific amount of quality assurance on our end and blocked the release until we had resolved every single bug and issue we found. Highlights: * New appliances since last announcement: Ruby on Rails, Mediawiki, Drupal6, LAPP stack, Django stack, MySQL, PostgreSQL, TurnKey Core (102MB) and Bootstrap (67MB) http://www.turnkeylinux.org/appliances * Rebuilt all appliances on top of TurnKey Core, the new common base for all software appliances, which is assembled from Ubuntu 8.04.2 LTS packages. * Security enhancements: SSL support out of the box, regenerating cryptographic keys at installation time, database password setting during installation. * Usability improvements: phpMyAdmin included in all LAMP based appliances, also included many generically useful webmin modules and improved embedded documentation, configuration console support for systems with multiple NICs, and password-free login in live CD/demo mode. * Many bugfixes including one that fixes a potential breakage to the daily auto-updates mechanism. Full details: http://www.turnkeylinux.org/news/good-news-everyone Link to blueprints for this release: https://blueprints.launchpad.net/turnkeylinux/2009.02-hardy-x86 We got this far thanks to everyone in the Ubuntu community who tried out the previous crop of beta appliances, especially those who gave us feedback and encouragement on the forums. Part of the what's great about starting out small is that we've been able to keep up with all comments and questions and personally respond to every single one of them, even in the middle of a development cycle. What is a software appliance? - A software appliance is a self contained system combining an application with just enough operating system to run on real hardware or a virtual machine (e.g., VMWare, VirtualBox, Xen HVM, KVM).. Manual installation and configuration of a server solution can be painful and time consuming, especially for users lacking technical proficiency. Some users find that using a pre-integrated software appliance is an easier way to get up and running quickly, especially in combination with virtual machine software. A software appliance allows users to altogether skip manual installation of the desired application components and required dependencies, and instead deploy a self-contained, ready-to-use system that requires little to no setup. For further details see: http://www.turnkeylinux.org/what-is-a-software-appliance Cheers, Liraz -- 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: Karmic Release Schedule
On Wed, 04 Mar 2009 09:24:10 -0600 Robbie Williamson rob...@ubuntu.com wrote: On 03/04/2009 02:42 AM, Martin Pitt wrote: Scott Kitterman [2009-03-03 16:04 -0500]: Could we have some discussion about cutting two weeks off of getting new packages in? I'd like to understand why it was moved back and what problem we are trying to solve. Was there some discussion already of adding an earlier NewPackageUploadDeadline? I thought the freeze consolidation has been very good and I wouldn't want us to casually spread things back out. +1. https://wiki.ubuntu.com/FeatureFreeze already has a defined and well-working process for new packages. This was suggested by some of the platform leads. Some partners not familiar with our release process assume that FeatureFreeze is the deadline by which they can submit their code *for the first time*...that is, they have not made *any* public drops to us or anyone else in the Ubuntu community until this point. The FeatureDefinitionFreeze and NewPackageDeadline was created to be able to keep these entities honest, with regards to the schedule. Maybe we rename it to PartnerNewPackageDeadline, to indicate the audience...would that be better? I think it'd be better. If this is related to Canonical's efforts with their Partner repository then I think it probably doesn't belong on an Ubuntu schedule at all. 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
[Fwd: Re: Karmic Release Schedule]
On 03/04/2009 09:28 AM, Scott Kitterman wrote: On Wed, 04 Mar 2009 09:24:10 -0600 Robbie Williamson rob...@ubuntu.com wrote: On 03/04/2009 02:42 AM, Martin Pitt wrote: Scott Kitterman [2009-03-03 16:04 -0500]: Could we have some discussion about cutting two weeks off of getting new packages in? I'd like to understand why it was moved back and what problem we are trying to solve. Was there some discussion already of adding an earlier NewPackageUploadDeadline? I thought the freeze consolidation has been very good and I wouldn't want us to casually spread things back out. +1. https://wiki.ubuntu.com/FeatureFreeze already has a defined and well-working process for new packages. This was suggested by some of the platform leads. Some partners not familiar with our release process assume that FeatureFreeze is the deadline by which they can submit their code *for the first time*...that is, they have not made *any* public drops to us or anyone else in the Ubuntu community until this point. The FeatureDefinitionFreeze and NewPackageDeadline was created to be able to keep these entities honest, with regards to the schedule. Maybe we rename it to PartnerNewPackageDeadline, to indicate the audience...would that be better? I think it'd be better. If this is related to Canonical's efforts with their Partner repository then I think it probably doesn't belong on an Ubuntu schedule at all. It's not just a partner repository issue, but I believe an OEM partners issue as well. The problem is that we give them one date for an enablement code drop, and then they see the FeatureFreeze on the public schedule and assume they have until then. The goal was to have something in the public schedule so there's no misunderstanding. Admittedly, the OEM should simply adhere to the agreed upon dates and not the public schedule, however we've already had to drop 9.04 support for some OEMs because of this misunderstanding...and this hurts us, them, and the users of their hardware. -Robbie - -- 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: Karmic Release Schedule
On Wed, 04 Mar 2009 09:46:43 -0600 Robbie Williamson rob...@canonical.com wrote: On 03/04/2009 09:28 AM, Scott Kitterman wrote: On Wed, 04 Mar 2009 09:24:10 -0600 Robbie Williamson rob...@ubuntu.com wrote: On 03/04/2009 02:42 AM, Martin Pitt wrote: Scott Kitterman [2009-03-03 16:04 -0500]: Could we have some discussion about cutting two weeks off of getting new packages in? I'd like to understand why it was moved back and what problem we are trying to solve. Was there some discussion already of adding an earlier NewPackageUploadDeadline? I thought the freeze consolidation has been very good and I wouldn't want us to casually spread things back out. +1. https://wiki.ubuntu.com/FeatureFreeze already has a defined and well-working process for new packages. This was suggested by some of the platform leads. Some partners not familiar with our release process assume that FeatureFreeze is the deadline by which they can submit their code *for the first time*...that is, they have not made *any* public drops to us or anyone else in the Ubuntu community until this point. The FeatureDefinitionFreeze and NewPackageDeadline was created to be able to keep these entities honest, with regards to the schedule. Maybe we rename it to PartnerNewPackageDeadline, to indicate the audience...would that be better? I think it'd be better. If this is related to Canonical's efforts with their Partner repository then I think it probably doesn't belong on an Ubuntu schedule at all. It's not just a partner repository issue, but I believe an OEM partners issue as well. The problem is that we give them one date for an enablement code drop, and then they see the FeatureFreeze on the public schedule and assume they have until then. The goal was to have something in the public schedule so there's no misunderstanding. Admittedly, the OEM should simply adhere to the agreed upon dates and not the public schedule, however we've already had to drop 9.04 support for some OEMs because of this misunderstanding...and this hurts us, them, and the users of their hardware. I can see how that would be a problem, but I still view that as a Canonical issue and not an Ubuntu issue. I know the distinction is subtle, but I think important to preserve. My suggestion would be to publish a schedule on canonical.com with additional milestones related to Canonical's commercial efforts. Perhaps I make to much of this, so I'll step back and see what other's think. 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: Karmic Release Schedule
Hello Robbie, Robbie Williamson [2009-03-04 9:24 -0600]: This was suggested by some of the platform leads. Some partners not familiar with our release process assume that FeatureFreeze is the deadline by which they can submit their code *for the first time*...that is, they have not made *any* public drops to us or anyone else in the Ubuntu community until this point. Right. FF has always meant the day of reckoning about the features that landed so far, not the day to kick them into the distro, but I agree that this isn't quite clear by just looking at the schedule (you'd actually have to follow the FF link to its description). The FeatureDefinitionFreeze and NewPackageDeadline was created to be able to keep these entities honest, with regards to the schedule. Maybe we rename it to PartnerNewPackageDeadline, to indicate the audience...would that be better? Thanks for the explanation, and sorry for the misunderstanding. I saw that you renamed it, sounds perfect to me now. FWIW, I don't consider this a Canonical-only thing; after all, the stuff that lands in Ubuntu applies to every Ubuntu user (e. g. the BBC plugin for totem which landed in intrepid), and thus it should be on the public schedule. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (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: KDE update
On 04/03/09 17:58, Mackenzie Morgan wrote: On Wednesday 04 March 2009 3:50:32 am Onno Benschop wrote: Can someone please explain to me why I'm asked to download 32.2Mb of an update that has as a description: No change rebuild to satisfy build dependency for kdepim security update What I'm really asking is these three different questions: 1. Why am I downloading something that is no different from the previous version. As I understand the packaging system, any update to kdepim should be more than able to cope with being part of a specific version using depends and requires. The dependencies are listed in the package. To change the dependencies inside the package, the whole package has to be re-issued. Uh, yes. I suppose my point was that a dependency change, a single line in a text file, meta-information, shouldn't require the installation of the whole package. 2. Why am I downloading that much data for just version number changes, if that's really all that is changing? Because the entire thing is one package. Nope, there are 10 different packages, all with the same description. 3. Why am I downloading these updates when I don't actually have kdepim installed at all? Not Kontact, Kmail, Korganizer...? Not that I can find or recall installing. Don't get me wrong. I understand what is happening, even why it's happening from a technical perspective. What I fail to understand from a this is just wrong perspective that it's technically the way it is - which is why I posted to the list. I didn't want to get into the incremental packages discussion, but I thought that this was different enough to warrant at least some conversation about the meta-information associated with a package. I realise at present the meta information is also part of the .deb files but apt doesn't know about .deb's, so I presume it's getting the information from the pkgcache.bin file which I suspect is directly built from getting the package lists from a mirror. What I'm saying is that the dependencies are in that information, so there doesn't appear to be a need to download the .deb to install it if nothing inside the .deb actually needs changing. -- Onno Benschop Connected via Bigpond NextG 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 - o...@itmaze.com.au -- 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: KDE update
On Thu, 05 Mar 2009 05:49:37 +0900 Onno Benschop o...@itmaze.com.au wrote: On 04/03/09 17:58, Mackenzie Morgan wrote: On Wednesday 04 March 2009 3:50:32 am Onno Benschop wrote: Can someone please explain to me why I'm asked to download 32.2Mb of an update that has as a description: No change rebuild to satisfy build dependency for kdepim security update What I'm really asking is these three different questions: 1. Why am I downloading something that is no different from the previous version. As I understand the packaging system, any update to kdepim should be more than able to cope with being part of a specific version using depends and requires. The dependencies are listed in the package. To change the dependencies inside the package, the whole package has to be re-issued. Uh, yes. I suppose my point was that a dependency change, a single line in a text file, meta-information, shouldn't require the installation of the whole package. 2. Why am I downloading that much data for just version number changes, if that's really all that is changing? Because the entire thing is one package. Nope, there are 10 different packages, all with the same description. All built from a single source package. The system doesn't support partial builds. 3. Why am I downloading these updates when I don't actually have kdepim installed at all? Not Kontact, Kmail, Korganizer...? Not that I can find or recall installing. Don't get me wrong. I understand what is happening, even why it's happening from a technical perspective. What I fail to understand from a this is just wrong perspective that it's technically the way it is - which is why I posted to the list. I didn't want to get into the incremental packages discussion, but I thought that this was different enough to warrant at least some conversation about the meta-information associated with a package. I realise at present the meta information is also part of the .deb files but apt doesn't know about .deb's, so I presume it's getting the information from the pkgcache.bin file which I suspect is directly built from getting the package lists from a mirror. What I'm saying is that the dependencies are in that information, so there doesn't appear to be a need to download the .deb to install it if nothing inside the .deb actually needs changing. I didn't look into the details of this case, but generally this means that something in the share object (.so) the package is linked against has (or may have) changed and so the package has to be recompiled so that it will be correctly linked. 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: Fw: Re: Notable Changes to Jaunty's PulseAudio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Mar 2009, Steve Langasek wrote: What has been the outcome of this testing? The upgrade was fairly painless for me, but I know that may not be indicative; are there still race conditions outstanding that pose a risk to the stability of the jaunty release? Given the kernel team's decision to not enable the PREEMPT kernel config option for -generic in jaunty, the change in pulseaudio 0.9.14-0ubuntu10 will be reverted, which will restore the configuration to that shipped in Alpha 5 (glitch-free disabled). This change is being tested by community members using the package in my PPA. Two significant issues have plagued PA even with glitch-free disabled: 1) bogus data from alsa-kernel via alsa-lib caused crashes, mostly notably in PulseAudio's module-alsa-sink (but also triggerable in module-alsa-source); 2) certain ALSA mixer elements needed to be set to non-zero and unmuted, mostly notably 'Front' and 'PCM'. (1) is actually caused by two components - snd_pcm_update_avail() in PulseAudio was improperly handling a signed underflow from alsa-lib, but upstream discussion has led to the drivers being identified as unstable. I've corrected this bug using a portion of logic from upstream, so PA no longer crashes in snd_pcm_update_avail() due to the underflow. There was also an adjustment to the delay handling, so the CPU no longer spins in the case that the driver returns such a large positive value. The remaining component that needs to be resolved is the case where the driver improperly sets POLL* status but doesn't actually return any usable data. In this context, the CPU will also spin, and due to the default PA configuration where no-cpu-limit defaults to yes in /etc/pulse/daemon.conf (being commented), the daemon will abort. I'm addressing this bug (330814) this week (as time off from $dayjob permits) and hope to have it squashed for Alpha 6. (2) requires digging deeper into the alsa-utils.c code in PA - it is not immediately obvious under what conditions such an adjustment to available ALSA mixer elements should be made. I have a sinking feeling that I'll have to hard-code logic to detect whether a volume-/stream-/sink-restore has occurred, but this approach, too, warrants investigation. I'm addressing this bug (315971) for Beta. - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJrzkPe9GwFciKvaMRAoIZAJ9ogfgDu3lWQbljAzN+T9OdHexCzwCfcuRz 4ZxnxAa2MeR8RqQaC9cErq4= =Z0vk -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
