Minutes of the Technical Board meeting 2013-07-08
Meeting summary and log: http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-08-19.58.html Members present: Matt Zimmerman (chair), Colin Watson, Kees Cook, Soren Hansen, Stephane Graber - The question of the development series alias name was deferred to the next meeting (noting that it was not blocking engineering work at the time) - The board resolved that an explicit linking exception is required in order for GPL software (v2 or v3) to dynamically link with OpenSSL in Ubuntu, noting that a statement from the copyright holder is sufficient. - Kees Cook agreed to review the outstanding provisional micro-release exceptions on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions incorporating data on known regressions in updates to these packages. Using this information, the board will decide whether to make these exceptions permanent. -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Minutes of the Technical Board meeting, 2012-01-09
Also available online: https://wiki.ubuntu.com/TechnicalBoard/TeamReports/12/January Chair: Matt Zimmerman Attendees: Kees Cook, Stephane Graber, Colin Watson, Soren Hansen, Martin Pitt Guests: Pasi Lallinaho, Scott Kitterman, Jonathan Riddell, Micah Gersten, et al Full log: http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-01-09-20.58.moin.txt Action review: * pitti: document brainstorm review activity → Done * kees: perform brainstorm review → carried over Xubuntu LTS application * Proposal: * https://lists.ubuntu.com/archives/technical-board/2012-January/001160.html * Approved by vote ARB: Allow for files outside of /opt/extras.ubuntu.com/source/ as long as they are prefixed by extras-source_. * Agreed Kubuntu LTS application * Proposal: https://wiki.kubuntu.org/Kubuntu/12.04/LTS-Proposal * Approved by vote Edubuntu LTS Application * Proposal: https://wiki.ubuntu.com/Edubuntu/12.04/LTS-Proposal * Approved by vote, modulo further discussion of calibre, VNC, possibly others Next meeting: * Next on 2012-01-23 * Chair: Soren Hansen -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: Micro Release Exception needed for nova/glance/keystone
On Tue, Nov 29, 2011 at 12:50:07AM +, Dave Walker wrote: On Fri, Nov 25, 2011 at 04:15:43PM -0800, Clint Byrum wrote: I was just reviewing the SRU's that Chuck Short uploaded for keystone, nova, and glance to oneiric-proposed, and it strikes me that really OpenStack core components should go through the MicroReleaseException process. Upstream has active QA, and as of diablo supports a stable release branch with policies around acceptance. Just sending this to ubuntu-devel as a PSA that if your SRU has more than 2 or 3 bugs to fix at one time, its probably not going to be able to pass through our manual patch review process. However, take a look at the criteria here and consider applying for a micro release exception: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions Hi Clint, I think this really needs some further clarification. I followed this process earlier this year, when performing an SRU for bind9 which involved a new upstream version.. This was jumping from upstream versions 9.7.0 - 9.7.3 in Lucid. I raised the subject with the TB, and mdz responded that: MicroReleaseExceptions is a list of standing exceptions. It's not necessary to go through the tech board to handle one-off requests like this one. The SRU team can decide what to do here without TB involvement. [0] Is this still the case? I see the distinction as: A. Should we update package foo to version x.y.z in order to fix bugs N and M? should be cleared with the SRU team. The SRU team can set policy and make exceptions to it as appropriate to act in the best interests of Ubuntu users. B. Should we, *in general*, track upstream bugfix releases of package foo and trust that they're appropriate for use by all Ubuntu users? should be cleared with the TB. The TB has set criteria to help evaluate whether this is appropriate. It sounds like Clint is suggesting that B. would be more appropriate than A. for OpenStack. I haven't personally checked if the OpenStack components meet the documented criteria. FWIW, I would support the TB in delegating more of this authority to the SRU team if that would streamline things. So far, there have only been a handful of exceptions, and it hasn't been an issue. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Do you use Binary package hint: line in bug description?
On Wed, Jun 08, 2011 at 05:52:17PM -0400, Francis J. Lacoste wrote: Hello, When user file bugs on the distribution and enter a package name in the widget, Launchpad automatically adds a line to the description with Binary package hint: binarypackagename I would welcome its disappearance. :-) -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: shrinking the desktop DVD image to 1.5GB
On Wed, Jun 08, 2011 at 03:50:30PM -0700, Allison Randal wrote: At UDS-O, we discussed CD space again (as at many a past UDS). Colin has nicely summarized the discussion: https://wiki.ubuntu.com/FoundationsTeam/Specs/OneiricCDSizing Following on the tail of this, a few of us have been talking more about the idea of shrinking the 4.3GB DVD image down to a 1.5GB flash card/USB stick/DVD image. It's looking interesting enough to be worth talking about it more broadly. Love it. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Do you use Binary package hint: line in bug description?
On Thu, Jun 09, 2011 at 01:15:55PM -0400, James Westby wrote: I don't think I've ever needed to know which particular binary package of a source is at fault. This was exactly the logic for Launchpad Bugs being source package oriented, rather than binary package oriented like debbugs. The binary package hint, IIRC, was a hedge in case that information turned out to be used by more people or tools than we expected. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Uploading to multiple distros
On Thu, Jun 02, 2011 at 06:17:09PM -0700, Evan Broder wrote: Hmm...a lot of this discussion seems to be getting caught up in the ubuntu-devel moderation queue, but I'll try to guess context as best as I can... The moderation queue doesn't have any outstanding messages for this thread, though maybe it did when you looked. It's also possible that some folks are subscribed to debian-devel but not ubuntu-devel. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Thu, Jun 02, 2011 at 10:16:04AM -0700, Kees Cook wrote: On Thu, Jun 02, 2011 at 09:11:51AM -0500, Serge Hallyn wrote: Quoting Matt Zimmerman (m...@ubuntu.com): Maybe I'm weird, but I use dmesg for a lot of normal tasks, not just debugging problems which will require root to fix. The most common is probably the traditional what device node was assigned to that device I Nothing at all weird about that. Aren't we all supposed to use udisks --enumerate now? :) I hadn't used that before. You got my hopes up, and I thought it might turn out to be a tool to map device nodes to meaningful descriptions of the physical devices. Oh well. :-) -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Thu, May 26, 2011 at 04:55:59PM -0700, Kees Cook wrote: I won't say it doesn't complicate things, but I would like to point out that everyone else's suggestion for this is to completely remove the values from the dmesg report itself, rendering it unavailable to any user, even root. It seems we are forced into this dichotomy because there is only one log, which is mixing different types of information. Has anyone proposed separating kernel debugging information from simple status logging, and allowing the remainder to remain accessible to users? -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote: As we have continued to close kernel address leaks, the kernel syslog (dmesg) remains one of the last large places where information is being reported. As such, I want to close this off from regular users so that local kernel exploits continue to have an even harder time getting a foot-hold on vulnerabilities. And, as before, this is a tunable that you can change in /etc/sysctl.d/ if you do development work, like getting owned, etc. For the average user, this information is not needed. What are the ways in which kernel addresses are leaked through dmesg? Can you provide some examples? Is it not feasible to avoid leaking addresses, while still passing on all of the useful data in dmesg to users? -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Upgrading via the desktop installer (ubiquity)
On Wed, Apr 06, 2011 at 11:08:13AM +0100, Evan Dandrea wrote: In 11.04 and later versions, the desktop CD installer (ubiquity) presents an option to upgrade Ubuntu if it finds a single copy on the system. This functionality is not exactly equal in operation to upgrade-manager, nor does it share much code with that application. Such an upgrade will first make a backup of apt's state, including repacked debs (using dpkg-repack) for any packages that it cannot find a source for. Following this, it will delete all non-user and non-local files on the existing partitions. This is roughly everything but /usr/local, /var/local, /usr/src, and /home. It will then install Ubuntu over top of the partially-cleared directory structure and install the packages referenced in the apt state backup. When triaging upgrade bugs, please make sure they're targeted to and have logs for the correct package. If the user upgrades via the option in the desktop CD installer, change the package to ubiquity and have the user run `sudo apport-collect $bug_number`. Does this type of upgrade leave behind some trace to allow us to determine which upgrade method the user chose? /usr/share/apport/general-hooks/ubuntu.py currently assumes that all upgrades write /var/log/dist-upgrade/apt.log, and tags bug reports with upgrade details accordingly. If Ubiquity doesn't touch this file when upgrading, it will be marking bug reports incorrectly in this case. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Minutes from today's Technical Board meeting, 2011-03-10
= Attendance = * Kees Cook * Martin Pitt * Scott James Remnant * Colin Watson * Matt Zimmerman (chair) = Notes = == Quarterly brainstorm review (mdz) == * It's time for the next installment of the quarterly brainstorm review, as agreed in http://www.novarata.net/mootbot/ubuntu-meeting.20100907_0900.html * Martin Pitt volunteered to organize the review this time (thanks, Martin!) * ACTION: pitti to kick off the review * ACTION: mdz to send Martin the materials he used last time (email templates etc.) == Per-package uploads == * There were a couple of outstanding grants of per-package upload privileges on the technical-board mailing list, which Martin agreed to action * ACTION: pitti to respond to uTouch package set request * ACTION: pitti to add PPU rights for Serge Hallyn per ML == Administration of the ubuntu-release team == The administrator of the ubuntu-release team in Launchpad was Colin Watson, from the time when he served as release manager, and the owner was Matt Zimmerman. It was quickly agreed that the owner of the team should be the Technical Board instead, and that change was made immediately. There was then a vote to confirm that Kate Stewart should be the administrator of the release team. Kate has been serving as release manager for some time, and the board recognized this as a formal delegation and mdz updated Launchpad accordingly during the meeting. == SRU for w3m to fix bug 523229 == Apparently, w3m (prior to Natty) can't be used to login to Launchpad due to missing required functionality. As w3m is the default text-mode browser in Ubuntu (and the only browser in Server Edition), it has been proposed that the missing functionality should be backported. Tuomas Heino has prepared a patch for this, and asked the technical board for guidance. The board affirmed that if this is a regression, the existing policy in https://wiki.ubuntu.com/StableReleaseUpdates#Special%20Cases applies, and this should be considered by the SRU team. ACTION: cjwatson to follow up on bug 523229 == Bug scrub == The following two bugs are being tracked by the technical board: * Launchpad bug 174375 in Launchpad itself Distribution drivers permissions may need redesign [Low,Triaged] https://launchpad.net/bugs/174375 * Launchpad bug 451390 in Launchpad itself limited upload rights no longer give series nomination accept/decline rights [High,Triaged] https://launchpad.net/bugs/451390 Further progress on the former is blocked on the latter, which has now been escalated. -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Application packaging (Re: brainstorming for UDS-N - Application Developers)
On Fri, Oct 01, 2010 at 05:56:27PM +0100, Evan Dandrea wrote: On Tuesday, September 28, 2010 05:31:26 pm Rick Spencer wrote: We want to empower, engage and harness application developers to develop on and for Ubuntu. These sessions cover the many elements in achieving that goal. What's high on your list for this area? There are some existing conversations and threads that people should feel free to comment on in addition to any new areas: * Changes to the implementation of the New Apps on stable releases (suggestions have included changing the system to use backports as an avenue onto a stable release, for example). * Changes to the Application Review Board process (including, for example, eliminating it and replacing it with a streamlined backports process). * Enhancement, changes to tools such as Glade, Gedit, etc... * Anything about Quickly and/or Quickly Widgets, including new templates, improvements to the existing template, new widgets, etc... * Information Architecture for application developers, including a developers manual, etc... If we are going to meet the goal of really streamlining the process for developers to get their applications in front of users, then we need to change what it is that is delivering the application. I don't think that a traditional Debian package is going to be able to support a truly lightweight process. Thank you. This is something I've been thinking about for quite a while and it's comforting to know that I'm not alone in what entrenched minds must find to be very radical thinking. You might also be interested in http://mdzlog.alcor.net/2010/07/06/weve-packaged-all-of-the-free-software-what-now/ which I posted back in July. It is a radical perspective (questioning our fundamental model), but it is not unheard of. I think our current architecture for packaging and delivery is built on top of some misconceptions. Namely, that we can solve the problem of buggy software getting into Ubuntu by fixing bugs in applications on behalf of developers, that packaging needs to be complex, and that we should be and ultimately need to be doing the legwork to package these applications ourselves. I can't speak for anyone else, but I certainly don't suffer from any such delusion. Packaging is not about keeping bugs out, but about getting software in and getting it working---together. We need to make it so that developers can quickly deploy an application that then appears in Ubuntu Software Center for anyone on that release of Ubuntu, regardless of where we our in our own cycle. The current effort in this area is based around Debian packages, and is an incremental step from where we are today. We can and should continue to improve and simplify it from there. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Naming sessions in Launchpad for UDS
(I know I'm very late to this discussion, but want to make sure this is clarified) On Wed, Oct 06, 2010 at 03:27:29PM -0600, Duncan McGreggor wrote: Let me break that down for easy viewing: * Application Developers * Application Selection and Defaults * Cloud * Development Process * Hardware Compatibility * Other * Ubuntu the Project We had 9 tracks last year and filled them pretty well. We're looking at at 2 less this year (as defined above) and probably even more sessions than last time (every year our material has grown). If you missed it, you might want to review http://mdzlog.alcor.net/2010/05/27/rethinking-the-ubuntu-developer-summit/ for some rationale for updating the format. We haven't added or subtracted tracks; we've arranged them on a different axis. Sessions are now listed by topic, rather than by which team happened to submit them. Unless we're cutting out slots and pushing outlying session topics into the community for discussions instead of proper UDS sessions... We do not push topics into the community, because we are part of the community. UDS is a community event, and all of the sessions at UDS are proper, whether they come from a Canonical engineering team like yours or an individual with a passionate interest in the subject. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Second call for votes: Ubuntu Developer Membership Board election
https://wiki.ubuntu.com/DeveloperMembershipBoard http://mdzlog.alcor.net/2009/12/08/call-for-nominations-ubuntu-developer-membership-board/ So far, only 64 out of 146 eligible voters have cast their vote. The poll will end 18 January 2010. All Ubuntu developers should have received a ballot by email. If you did not receive yours for some reason, please contact me and I will arrange for it to be resent. -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Call for votes: Ubuntu Developer Membership Board election
Voting has begun to determine who will hold the seats on the newly established Developer Membership Board, which is responsible for determining when, how and to whom to grant privileges related to Ubuntu development. In particular, the DMB will take over the membership functions previously held by the Technical Board and MOTU Council. More information at: https://wiki.ubuntu.com/DeveloperMembershipBoard and http://mdzlog.alcor.net/2009/12/08/call-for-nominations-ubuntu-developer-membership-board/ Like this year's Technical Board election, the poll is using the Condorcet Internet Voting system. Ballots have been sent privately to each eligible voter (member of ~ubuntu-dev), based on a list of email addresses harvested from Launchpad. If you are a member of this team (directly or indirectly), but did not receive a ballot, please contact me and I will sort it out for you. -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Minutes from Technical Board meeting, 2009-09-08
Copied from https://wiki.ubuntu.com/TechnicalBoard/TeamReports/09/September * Debian technical committee participation in techboard * Bdale Garbee has put himself forward to participate and help define the role * ACTION received: cjwatson to respond to Bdale, make arrangements for him to participate * Java SRU policy * Passed: proposed Java SRU policy at https://wiki.ubuntu.com/StableReleaseUpdates#sun-java* as amended for appropriate smoke testing by pitti/kees. * ACTION received: pitti to update SRU document per vote * Removal of sun-java6 from Karmic * Passed: remove sun-java6 from karmic in favor of openjdk-6, contingent on approval from the maintainer (Matthias Klose). * ACTION received: kees to confirm removal of sun-java6 with doko * Developer Membership Board * Scott has set up the appropriate teams in Launchpad * The DMB now needs to be communicated, and start doing the work of processing membership applications * ACTION received: cjwatson to announce DMB to MC, -devel announce * Action: jono to update documentation * Archive reorganisation (Colin Watson) * Colin had a couple of minor items to confirm with the TB before throwing the switch on package sets * Ubuntu package sets are now implemented in Launchpad * Community bugs (none) * select a chair for the next meeting (kees) -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
python-zopeinterface - apparent dependency resolution error
Did anyone else see this recently in Karmic? python-apport wouldn't upgrade automatically due to a chain of dependency weirdness which led to python-zopeinterface and python-zope.interface. -- - mdz atomicity:[~/src] sudo apt-get install python-apport Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python-apport: Depends: python-launchpadlib but it is not going to be installed E: Broken packages zsh: exit 100 sudo apt-get install python-apport atomicity:[~/src] sudo apt-get install python-launchpadlib Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python-launchpadlib: Depends: python-lazr-restfulclient but it is not going to be installed E: Broken packages zsh: exit 100 sudo apt-get install python-launchpadlib atomicity:[~/src] sudo apt-get install python-lazr-restfulclient Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python-lazr-restfulclient: Depends: python-zope-interface E: Broken packages zsh: exit 100 sudo apt-get install python-lazr-restfulclient atomicity:[~/src] sudo apt-get install python-zope-interface Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting python-zopeinterface instead of python-zope-interface The following packages were automatically installed and are no longer required: python-wadllib libmissioncontrol-client0 python-lazr-uri libmissioncontrol-server1 libtelepathy2 python-oauth Use 'apt-get autoremove' to remove them. sudSuggested packages: python-zopeinterface-dbg The following packages will be REMOVED: python-zope.interface The following NEW packages will be installed: python-zopeinterface 0 upgraded, 1 newly installed, 1 to remove and 120 not upgraded. oNeed to get 146kB of archives. After this operation, 254kB of additional disk space will be used. Do you want to continue [Y/ Get:1 http://us.archive.ubuntu.com karmic/main python-zopeinterface 3.4.0-0ubuntu3 [146kB] Fetched 146kB in 11s (12.2kB/s) dpkg: python-zope.interface: dependency problems, but removing anyway as you requested: python-twisted-core depends on python-zope.interface | python-zopeinterface (= 3.2.1-3); however: Package python-zope.interface is to be removed. Package python-zopeinterface is not installed. python-twisted-core depends on python-zope.interface | python-zopeinterface (= 3.2.1-3); however: Package python-zope.interface is to be removed. Package python-zopeinterface is not installed. (Reading database ... 164506 files and directories currently installed.) Removing python-zope.interface ... Selecting previously deselected package python-zopeinterface. (Reading database ... 164473 files and directories currently installed.) Unpacking python-zopeinterface (from .../python-zopeinterface_3.4.0-0ubuntu3_i386.deb) ... Setting up python-zopeinterface (3.4.0-0ubuntu3) ... atomicity:[~/src] sudo apt-get dist-upgrade ^Cading package lists... 6% atomicity:[~/src] sudo apt-get install python-apport Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libmissioncontrol-client0 libmissioncontrol-server1 libtelepathy2 Use 'apt-get autoremove' to remove them. The following extra packages will be installed: python-launchpadlib python-lazr-restfulclient The following NEW packages will be installed: python-launchpadlib python-lazr-restfulclient The following packages will be upgraded: python-apport 1 upgraded, 2 newly installed, 0 to remove and 119 not upgraded. Need to get 147kB of archives. After this operation, 582kB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://us.archive.ubuntu.com karmic/main python-lazr-restfulclient 0.9.3-0ubuntu2 [28.0kB]
Minutes from the Technical Board meeting, 2009-06-30
= Attendees = * Matt Zimmerman (chair) * Colin Watson * Scott James Remnant = Notes = * Scott Kitterman's [[https://wiki.ubuntu.com/ClamavUpdates proposal for a ClamAV update policy]] was endorsed by the Technical Board, contingent on the approval of the security and release teams * Charlie Smotherman was granted upload privileges for ampache, ampache-themes and coherence * Thierry Carrez was welcomed as a new core developer * Scott James Remnant has put forward a Technical Board position statement regarding Mono, which is to be published shortly * The Technical Board is discussing the creation of a new governing body, the Developer Applications Board, to process new developer applications, separating this function from the Technical Board itself -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: Best practice for reporting bugs
On Wed, Mar 25, 2009 at 12:38:44PM +, Chris Jones wrote: Matt Zimmerman wrote: our best practices for reporting bugs. In particular, reporting bugs directly to Launchpad is usually *NOT* the best approach. This should only Perhaps Launchpad could specifically discourage this within /ubuntu/ and offer up much the same information in your mail? Indeed, it does give that guidance but it's usually too late to help (i.e. after +filebug). I believe this is on the QA team's launchpad wishlist already. -- - mdz -- 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: Best practice for reporting bugs
On Wed, Mar 25, 2009 at 03:46:05PM -0300, Derek Broughton wrote: Mackenzie Morgan wrote: On Wednesday 25 March 2009 11:08:11 am Derek Broughton wrote: Matt Zimmerman wrote: On Wed, Mar 25, 2009 at 12:38:44PM +, Chris Jones wrote: Matt Zimmerman wrote: our best practices for reporting bugs. In particular, reporting bugs directly to Launchpad is usually *NOT* the best approach. This should only Perhaps Launchpad could specifically discourage this within /ubuntu/ and offer up much the same information in your mail? Indeed, it does give that guidance but it's usually too late to help (i.e. after +filebug). I file many bugs at launchpad, and haven't seen anything suggesting a better place. In fact, I keep getting told to file bugs at launchpad... Launchpad itself could do a much better job of telling you how to report bugs, I agree. The authoritative documentation for this is currently https://help.ubuntu.com/community/ReportingBugs In almost all cases, it is preferable to report the bug using Apport. This can be done in one of the following ways: 1. If the bug is a crash, apport should automatically generate a report and guide you in filing it. Copies of the crash reports are stored in /var/crash in case you need to refer to them directly. I think that's happened to me _once_. iirc, it gave a message that was about as encouraging as the Windows May we send a report to Microsoft No doubt most people say Shut up and close the window. It doesn't seem to happen with KDE apps, though I've regressed to Hardy, so perhaps it will when I can get back to Intrepid+. This is only enabled during development. For example, it's currently enabled in Jaunty, but will be turned off for the final release, then enabled in Karmic, etc. 3. On the command line, you can run ubuntu-bug package (or ubuntu-bug PID) to invoke Apport manually. Kernel bugs should be reported with ubuntu-bug linux. That's going to be news to the average user, of which a noticeable number are _still_ using the old bug tools to file a bug straight to ubuntu-users We don't install those tools by default, while we do install apport. Anyone who searches the web looking for how to report bugs in Ubuntu should find the above documentation. The missing piece is to get everyone telling each other about the right way to do it. -- - mdz -- 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
Minutes from the Technical Board meeting, 2008-08-26
Board members: Mark Shuttleworth, Matt Zimmerman Apologies: Scott James Remnant (holiday) Attendees: Oliver Grawert, Emmet Hikory == Status of cdrtools discussion == Mark has offered to obtain a legal opinion from the Software Freedom Law Center, on the condition that Joerg Schilling will agree up front to accept their determination. We are waiting for Joerg to respond to this proposal. Mark suggested that we also involve Sun in the discussion, as they are shipping cdrtools. Action: Mark to contact Sun legal regarding cdrtools == Gobby co-maintenance with Debian == Philipp Kern, upstream developer and Debian maintainer of gobby, and MOTU, is interested in helping to maintain gobby in Ubuntu main. We agreed that this is reasonable, and that Phillipp's existing qualifications are sufficient to grant upload privileges. Action: Matt to arrange upload rights for gobby for pkern == Revisiting limited upload privileges for kernel and printing packages == The Technical Board granted core-dev privileges to two developers (Tim Gardner and Till Kamppeter) interested in working with specific packages in main, with the proviso that they were to follow standard sponsorship processes for other packages. Now that Launchpad has the capability to implement this type of access control directly, we agreed to transition these developers from ubuntu-core-dev to per-package upload rights. Action: Matt to follow up with Tim and Till == Board membership/nominations == The Technical Board is in search of new members, and suggestions from the community have been received and reviewed. The next step is to contact the top candidates (most were suggested by third parties) and ask whether they are willing to serve in the position. Action: Mark to contact the candidates and confirm their interest -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: Call for testing empathy
On Wed, Aug 13, 2008 at 05:25:05PM -0400, Danny Piccirillo wrote: Who makes the final call on the inclusion of Empathy in Intrepid? The desktop team, or if they can't decide, the technical board can help advise. Where does that discussion happen? ubuntu-desktop@, #ubuntu-desktop, desktop team meetings, etc. -- - mdz -- 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: Automatic fsck
On Wed, Aug 13, 2008 at 07:41:18AM +0800, Onno Benschop wrote: On Mon, Aug 11, 2008 at 11:52:25AM +0100, Matt Zimmerman wrote: == Filesystem checking / AutoFsck == A suggestion was made to the technical board that Ubuntu could be smarter about how and when it performs filesystem integrity checks (fsck). Decision: This should be discussed more widely in the developer community Action: Scott to start a thread on ubuntu-devel/-discuss One thing that I have not seen in this discussion is the notion that fsck might be modified to run incrementally. That's an interesting idea, though I don't know enough about ext3 to comment on its feasibility. Perhaps something to discuss with upstream? Another that I did not see is the idea that fsck can be run using -n (though ReiserFS and minix aren't supported at the moment). If fsck is run in the background and a notification is sent to the user/administrator if corruption is found, then active intervention can be recommended. It's easy to prevent fsck from changing the filesystem, but the trouble is that fsck can't be (usefully) run on a filesystem which is in use (mounted). I see with some alarm discussion about reducing the frequency of running fsck. I'm running an ext3 laptop and I'm seeing quite regular corruptions that require an fsck run to fix. (It may be related to a particular kernel, but I've not yet got to the bottom of that.) That is a very disconcerting (and atypical) problem. The appearance of errors in fsck indicates a serious problem which should be investigated, not a normal condition of wear and tear. Fundamentally, in my opinion, fsck is a housekeeping process that is required on a regular basis to ensure the sane state of a file-system, no matter which one you use, errors do happen, even if there are no bugs (ha!), we're talking about tiny magnetic fields affecting the information on a hard-drive - this problem is only going to get bigger with increased storage density. I don't think there's any disagreement on this point. The issues are: 1) The frequency at which fsck runs is somewhat arbitrary for many users, depending on their usage pattern, and doesn't relate particularly well to their risk of encountering errors. 2) The fsck runs themselves are very disruptive, blocking access to the computer when the user wants it. -- - mdz -- 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: ext4 in Intrepid?
On Tue, Aug 12, 2008 at 09:32:31AM +1000, Chris Jones wrote: I've been following the development of ext4 for what seems like an eternity. From what I understand, the latest Fedora 9 release features ext4 support. So too do many other popular distros. And what I can't understand is why Ubuntu still doesn't feature any support for ext4, to my knowledge. I was hoping that the developers could shed some light on the reasons as to why. And will it perhaps make its way into Intrepid? If not, when we will see support for ext4 in Ubuntu. The reasons are, in no particular order: * There hasn't been a driving need for it (contrast with, say, improved NTFS filesystem support) * It isn't stable yet. The developers still recommend caution and lots of backups * Tool support (e2fsprogs) wasn't released in a stable version until last month (July) * The developers highly recommend tracking out-of-tree kernel patches, even for 2.6.26 (our current kernel in Intrepid) It looks as if it may be worth a more serious look in the next release cycle after 8.10. -- - mdz -- 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
Automatic fsck
On Mon, Aug 11, 2008 at 02:09:19PM -0700, Bryce Harrington wrote: On Mon, Aug 11, 2008 at 11:52:25AM +0100, Matt Zimmerman wrote: == Filesystem checking / AutoFsck == A suggestion was made to the technical board that Ubuntu could be smarter about how and when it performs filesystem integrity checks (fsck). Decision: This should be discussed more widely in the developer community Action: Scott to start a thread on ubuntu-devel/-discuss I find the autofsck to be most notable on my laptop, perhaps because I reboot it more frequently, and because it usually chooses to autofsck at some inopportune time. I don't know if laptop harddrives need fsck more than desktop's, but I wouldn't mind seeing the frequency be reduced for laptops. Alternatively, maybe the autofsck could be made to take a few more factors into account, such as total run time since last fsck, total absolute time since last fsck, drive age, etc. Total run time sounds like an interesting one to watch. Some of the other ideas which have been proposed are: Run fsck during shutdown (when the user isn't expecting to be able to use the system for a while anyway) rather than at startup. https://blueprints.launchpad.net/ubuntu/+spec/prompt-for-fsck-on-shutdown Allow fsck to be easily skipped. This was implemented in 8.04 as part of https://blueprints.launchpad.net/ubuntu/+spec/usplash-polish Skip fsck when running on battery. Also implemented in 8.04 as part of https://blueprints.launchpad.net/ubuntu/+spec/usplash-polish -- - mdz -- 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: Automatic fsck
On Tue, Aug 12, 2008 at 08:57:36PM +1000, Ian Chennell wrote: Matt Zimmerman wrote: On Mon, Aug 11, 2008 at 02:09:19PM -0700, Bryce Harrington wrote: On Mon, Aug 11, 2008 at 11:52:25AM +0100, Matt Zimmerman wrote: Some of the other ideas which have been proposed are: Run fsck during shutdown (when the user isn't expecting to be able to use the system for a while anyway) rather than at startup. https://blueprints.launchpad.net/ubuntu/+spec/prompt-for-fsck-on-shutdown Allow fsck to be easily skipped. This was implemented in 8.04 as part of https://blueprints.launchpad.net/ubuntu/+spec/usplash-polish If fsck is to run during shutdown, then there definitely needs to be a means to easily skip it, or perhaps defer it to run at the next startup. Many people (like me :P) leave it till the very last minute at work before doing an express shutdown to dash out the door for the train. Having the laptop decide that it needs to do a disk scan at that point will not be popular...! See above; it's already possible to skip it. -- - mdz -- 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: Automatic fsck
On Tue, Aug 12, 2008 at 06:17:36PM +0300, Lars Wirzenius wrote: ti, 2008-08-12 kello 15:07 +0100, Matt Zimmerman kirjoitti: Indeed. The best we could do in a scenario like this would be to flag the filesystem dirty so that it gets checked the next time it's possible. I assume you mean the next time the system is rebooted. That might be a long time in the future: servers especially might run for months without a reboot. Even laptops might not reboot until there's a kernel security update that affects them. If the filesystem really is corrupted, it would be best to deal with it as soon as possible, before (more) data is lost. There isn't any reasonable way to deal with this synchronously. I'd rather notify the server admin via e-mail (which is the standard way of doing such things for servers), and the desktop user via a notification area alert of some kind, triggered in some suitable way. That could be done in addition to marking it dirty. I say we look into fixing e2fsck to do online consistency checking without borking over changing filesystem contents. Don't other OS/FS combos do this well? This requires the cooperation of the kernel, and I don't think this exists in ext3. An ext[234] solution would also be specific to that filesystem. An LVM solution would be generic for all filesystems. The LVM solution isn't viable anyway; there's no guarantee that the metadata on disk is in any way consistent while the filesystem is mounted. The problem in your test isn't only that the filesystem is changing from underneath it, it's also that it may not have been consistent in the first place. -- - mdz -- 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: Call for testing empathy
On Fri, Aug 08, 2008 at 10:12:57PM +0200, Laurent Bigonville wrote: Hello everyone, Empathy[1] will be part of the upcoming GNOME 2.24 desktop. The ubuntu desktop team considers using it instead of Pidgin for intrepid as default IM client. If you are running intrepid, please give empathy a test and report bugs to launchpad[2]. It may be installed by running synaptic and installing the empathy package or by running sudo apt-get install empathy. If you experiment a bug have a look at [3] before reporting. Empathy consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. The Telepathy[4] project is building a unified framework for many different kinds of real-time communications. It uses the D-Bus messaging system to provide a simple interface for client applications, allowing them to quickly take advantage of Telepathy's benefits. Telepathy supports XMPP(jabber), MSN, ICQ, SIP, ... I installed it and selected Applications-Internet-Empathy. Nothing happened, except for the appearance of an icon in the notification area, which, if I were not familiar with this misbehavior from certain other applications, would have gone completely unnoticed. Surely it should display a window the first time it is run? -- - mdz -- 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: Call for testing empathy
On Sun, Aug 10, 2008 at 11:26:56AM -0700, Dane Mutters wrote: Hello. I've been following along with this empathy discussion, and for my own testing purposes have made some hardy packages for empathy (and all its deps that aren't found in the repos). I would like to upload them to my ppa so that others who would like to test empathy can do so. I have a problem, however. Whenever I try to upload them, I get this error: [EMAIL PROTECTED]:~/Empathy$ dput danes-ppa empathy_2.23.6-1_amd64.changes Checking Signature on .changes gpg: no valid OpenPGP data found. gpg: the signature could not be verified. Please remember that the signature file (.sig or .asc) should be the first file given on the command line. No signature on /home/dane/Empathy/empathy_2.23.6-1_amd64.changes. You're uploading the wrong file; you want empathy_..._source.changes. -- - mdz -- 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: passwd -l
On Mon, Jul 28, 2008 at 10:27:17AM +0200, Thilo Six wrote: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/238755 summary: * cronjobs are broken for system that has a 'passwd -l root' with hardy http://thread.gmane.org/gmane.linux.debian.user/330437 * the implematation of the patch that changed 'passwd -l' is broken: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492307 * + the confusion it causes at users-side due to unexpeted behaviour. All of this is fixed in debian now. For hardy this all is imho a serve regression. Pls devs fix it. The bug is targeted for fixing in 8.04. -- - mdz -- 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: Did we really release 8.04?
On Mon, Jul 07, 2008 at 12:10:45PM +0300, Rakotomandimby Mihamina wrote: Matt Zimmerman wrote: If you were unaware that this was going on, perhaps we could do a better job of communicating this type of effort with the public. I would suggest a kind of summary of bugs (and their progression) on the front page of the ubuntu (and derivated) website. That way, people can see the things: - there are bugs - the ubuntu team cares about them Of course, it would be an auto generated summary (dont know how yet). This is done in a standardized way in Launchpad, for all projects and releases. For 8.04.1, the page is: https://edge.launchpad.net/ubuntu/+milestone/ubuntu-8.04.1 In the announcement of 8.04.1, we've summarized which bugs were fixed in the release announcement. Having a dedicated site (launchpad) is not enough, IMHO. The front page of the Ubuntu website is (as it should be) designed to help people find information about Ubuntu generally. Something so specific as a list of bugs being analyzed for a particular release would not be appropriate there. -- - mdz -- 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: LTS and release methodology
On Thu, Jul 10, 2008 at 10:13:00AM +0200, Krzysztof Lichota wrote: 2008/7/9 Matt Zimmerman [EMAIL PROTECTED]: As far as I'm aware, Windows provides no tools or infrastructure to make this easier. It is completely up to the ISV how their software is installed, and many of them detect an existing installation and upgrade it rather than install in parallel. Every application does it differently. Yes, some do not allow parallel versions, but many do. But at least they allow installing different versions without hassle. Linux users must jump through the hoops if they need OpenOffice 2.4 on Dapper which has 2.0. The argument about ISV doing their packaging in this way is void (at least for FOSS software) as in Ubuntu, Ubuntu packagers are doing packaging, not ISVs. It is not a question how it is done, but that it is possible (and easy) to install various versions of apps. To the point that it is easier to explain user how to run Firefox 3 through Wine on Dapper than to explain him how to get it running on Ubuntu itself. It is possible (and easy) to install multiple versions of applications which are packaged that way. Few packages are, because it requires more effort (both initially and ongoing) to do so. I know Postgres is not desktop package, but it shows it is possible to do. No one would argue that it is impossible, but with the current tools, it is done at a linear increase in developer effort. Ubuntu developers can much more effectively spend their limited time making one version very good than making two versions mediocre. Well, IMO in most cases this would require just creation of appropriate packaging process and appropriate build tools. Build systems already support installing to different directory prefixes, with prefixes/suffixes to binary names, etc. Some build systems do, some don't. And I don't think this would require linear time. It would be one-time job to convert it and then the maintenance would be the same. So the tradeoff would be to make current version mediocre. But to really tell it, we would have to start an experiment and try it. Indeed. If you believe that some one-time work will solve your problem, you are in an ideal position to test this. The problem is that Dapper ships PostgreSQL 7.4, 8.0 and 8.1 while Hardy, next LTS release ships 8.2 and 8.3. So there is no way for smooth transition from Dapper to Hardy by upgrading database for example to 8.1, switching to Hardy and upgrading further. This is the functionality overlap I was talking about. It is generally possible to keep obsolete packages installed after an upgrade, so there's no forced upgrade here. However, the packages from 6.06 won't receive maintenance updates on 8.04. If you install OpenOffice from Hardy, you cannot keep the one from Dapper. No, but you were talking about PostgreSQL, where you can. And I really don't think the one from Dapper would work on Hardy. I would be surprised if it stopped working. Providing 10 years of support for an old version of PostgreSQL to support this use case would not be a wise choice. Maybe this version in newer LTS should get limited transition support which ends when the support for older LTS ends. This way security fixes from older LTS would be simply forward-ported to newer LTS. It is already more complex than we would like for users and administrators to understand which packages on their system receive maintenance and support, and which don't. The idea of LTS is that one can deploy the system and not think about it too much for a few years. Adding time bombs where certain applications start to reach end-of-life earlier than others would complicate what is presently a simple cycle to understand. No additional security-related effort would be needed. First of all, porting changes to different versions of a package is real work. Second, security updates are semi-automatically deployed to millions of Ubuntu systems and need to be regression tested before being released. Don't be fooled by the fact that they are available for free; this is not a trivial service. In many corporations there are different versions for example of Word. To get to know which version of application it is you just have to ask user to go to Help-About. You must anyway ask which version of _Ubuntu_ user is using. And I think it is even harder to get this information, it is not in any way obvious to user. System-About Ubuntu. Slow to start, but discoverable enough. Which one? The older, or the installed last? Which one does the user consider their preferred version? Which one works best for their purposes? This is what IT departments define. Users would mostly use OpenOffice (the default set by IT department) unless support/power users would tell them to use other version. The vast majority of Ubuntu users don't have an IT department supporting them. The development team must make
Re: LTS and release methodology
On Thu, Jul 10, 2008 at 01:45:55PM +0200, Pär Lidén wrote: 2008/7/8 Matt Zimmerman [EMAIL PROTECTED]: There is a 'regression' tag, and we do try to prioritize these on an ad-hoc basis, but understand that with such incomplete information, it's difficult at best. Ok, I haven't seen that tag, even on bug bugs where users explicitly say that is has worked on a specific earlier distribution, such as bug #88746. Maybe it could be encouraged to be much more widely used? It is already documented, but most people file and respond to bugs without reading the documentation (and why should they have to?). Perhaps the only way to track regressions more accurately would be to represent them as first-class data in Launchpad. This is tricky, though, as we've learned that the more visible a knob is, the more it is turned, regardless of whether it is appropriate or not. If the data is too noisy, it becomes useless (this is why Importance is controlled). This is already our policy; in fact, we delayed the first LTS release for that reason. 8.04 released with some regressions, but these were considered either a) not severe enough to warrant delaying the entire release, or b) planned to be fixed with 8.04.1. Ok, I see. Well, then I suppose that I would like either a) the policy to be enforced more strictly, or b) that it should be communicated in some way much more clearly that the release is not really stable for production use yet for many users. I agree that we need to communicate better around our release activity, particularly with LTS. We made operational provisions for the new approach, for example delaying automatic upgrades from 6.06 LTS until 8.04.1, but the differences between 8.04 LTS, 7.10 and 6.06 LTS were perhaps not clear enough to everyone affected. This is one of the difficult things about having no contact with most of the user base. The important point is that a normal user should not need to hang out on forums, mailing list, LP, and so on, to know if the release is stable enough to use. IMHO, it should be enough to see from the name if the release is ready-for-use. For me (and probably many others) the name 8.04 Long Term Support communicates a message that it is so stable. I by no means imply that 8.04 was not ready to use. There were some flaws, which there always are in software releases, and in my view we addressed them appropriately with updates and 8.04.1. To you, LTS may mean so stable, but to another, it means that problems are actively fixed (which implies some change and therefore instability) even after release. One thing it can never mean is that there are no bugs in it, for that is a practical impossibility. -- - mdz -- 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: LTS and release methodology
On Wed, Jul 09, 2008 at 09:47:56AM +0200, Krzysztof Lichota wrote: 2008/7/8 Matt Zimmerman [EMAIL PROTECTED]: [package multiple versions of everything] This sounds simple enough, but the implementation gets complex very quickly, as does future maintenance and support. It is a lot of effort, but if we want to compete with Windows, which makes it possible (and easy), it should be done. As far as I'm aware, Windows provides no tools or infrastructure to make this easier. It is completely up to the ISV how their software is installed, and many of them detect an existing installation and upgrade it rather than install in parallel. Every application does it differently. And as it _is_ significant effort, I think it should be done only for key applications of desktop environment: for example office suites, browsers, audio/video players. BTW. It is already done for example for PostgreSQL - Dapper has packages for PostgreSQL 7.4, 8.0 and 8.1. They can coexist and run along each other. User chooses which package to install and then which versions to run. I know Postgres is not desktop package, but it shows it is possible to do. No one would argue that it is impossible, but with the current tools, it is done at a linear increase in developer effort. Ubuntu developers can much more effectively spend their limited time making one version very good than making two versions mediocre. The problem is that Dapper ships PostgreSQL 7.4, 8.0 and 8.1 while Hardy, next LTS release ships 8.2 and 8.3. So there is no way for smooth transition from Dapper to Hardy by upgrading database for example to 8.1, switching to Hardy and upgrading further. This is the functionality overlap I was talking about. It is generally possible to keep obsolete packages installed after an upgrade, so there's no forced upgrade here. However, the packages from 6.06 won't receive maintenance updates on 8.04. Providing 10 years of support for an old version of PostgreSQL to support this use case would not be a wise choice. Which version of Ubuntu are you running? suddenly isn't as useful to the person on the other end of the phone trying to help you, I don't think it is a big deal. You can ask what version of application person is running. Helpdesks all around the world do it all the time. They do, and it works reasonably well because the user generally only has one version of the application. and the question do I have the necessary security updates installed? no longer has a simple answer. Why not? If someone has necessary repositories installed, the answer is very simple. Provided that security fixes go to the same repository as application which is installed. You miss my point. Implicit in your proposal is a need for twice as many security updates. Where do you think these updates would come from? They do not fall from the sky. Which version of OpenOffice should launch when you click on a document in Firefox? The default. The default version should be the default? Simple enough. :-) If only one OpenOffice version is installed, there is no problem. If two, I think it would default to older (or installed last). Which one? The older, or the installed last? Which one does the user consider their preferred version? Which one works best for their purposes? The answer doesn't matter. The point is that this is another choice which needs to be made on the user's behalf, and with each new choice, there is less chance of getting it right. There is already system for handling that - /etc/alternatives/. According to my Dapper installation it already contains 240 commands with alternatives. I am familiar with it. You'll find that about half of those are man pages, not commands. But do you know how users can discover, in the desktop, what those settings are and change them? You can't. Adding a new, opaque, non-discoverable, counter-intuitive dimension to every important desktop application doesn't sound like the right approach to me. The backports repositories attempt to provide this kind of experience, and also demonstrates some of the shortcomings of this approach. What shortcomings are you talking about? The ones I am aware of: 1. Backports do not provide packages which can be run alongside others. It is just newer versions of apps, which replace older ones. This is sometimes OK, but for example for OpenOffice or Firefox, it would be better to have two versions alongside. It provides the user with a choice of old, stable and officially supported or new. The tools do not provide a great deal of flexibility for this case, but the choice is there. 2. Backports are one big bag with newer applications. If someone wants to install only one app, he gets upgrades for others. IMO this is very serious design flaw. The solution would be to create separate repositories for apps (like PPAs) - repository for Firefox 2, for Firefox 3, OpenOffice 2.3, OpenOffice
Re: LTS and release methodology
On Wed, Jul 09, 2008 at 10:19:46AM -0400, Mackenzie Morgan wrote: On Wed, Jul 9, 2008 at 4:43 AM, Matt Zimmerman [EMAIL PROTECTED] wrote: On Wed, Jul 09, 2008 at 09:47:56AM +0200, Krzysztof Lichota wrote: There is already system for handling that - /etc/alternatives/. According to my Dapper installation it already contains 240 commands with alternatives. I am familiar with it. You'll find that about half of those are man pages, not commands. But do you know how users can discover, in the desktop, what those settings are and change them? You can't. Galternatives could be included instead of having to use the voodoo sudo update-alternatives --config java (I think...haven't done that one in a while). In my opinion, nothing as esoteric as alternatives should be exposed in the desktop, any more than should reordering symlinks in /etc/rc?.d. -- - mdz -- 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: LTS and release methodology
On Wed, Jul 09, 2008 at 11:20:06AM -0400, Mackenzie Morgan wrote: On Wed, Jul 9, 2008 at 11:07 AM, Matt Zimmerman [EMAIL PROTECTED] wrote: In my opinion, nothing as esoteric as alternatives should be exposed in the desktop, any more than should reordering symlinks in /etc/rc?.d. Isn't that what System - Administration - Services is? It isn't quite as bad, as it only allows things to be enabled and disabled, and only displays a subset of the startup scripts (unlike some similar tools, which allow the user to easily break their system). I wish we didn't need it, though. -- - mdz -- 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: LTS and release methodology
On Mon, Jul 07, 2008 at 07:48:03PM +0200, Vincenzo Ciancia wrote: Il giorno lun, 07/07/2008 alle 18.04 +0100, Matt Zimmerman ha scritto: Instead, we focus on defining a subset of functionality which can be tested in practice. You can find the corresponding test plans here: https://wiki.ubuntu.com/Testing along with instructions for how you can participate in the testing effort and find the problems which matter to you. I think I can add two notices: 1) what about giving really high priority to _regressions_ of these test cases? For example pdf printing has been and is broken in ubuntu since I think one year or so, due to evince not being capable of printing correctly many (but not all) of these files. This means the LTS does *not* pass the test cases. I print a PDF from evince at least once per week and am happy with the output, so there seems to be more subtlety to the problem than PDF printing is broken in Ubuntu. In fact, it seems clear from the upstream bug (correctly forwarded by an Ubuntu developer) that the problem is not specific to Ubuntu either. The bug https://bugs.edge.launchpad.net/poppler/+bug/150187 is open but stuck in a dead end. This bug must be paid a much greater attention than it is now: I have to teach people to install acrobat reader, that sucks on linux in any point except for its very good printing abilities. People will _not_ use ubuntu if they can't print pdf files. Indeed, any regression regarding such basic functionality as the thest cases you kindly provided should be given a very high importance for the quality of the distribution. Your bug seems to have received an appropriate response both from Ubuntu and from the upstream project. The process, in this case, seems to be mostly working, but the upstream bug simply isn't fixed yet. The next step would be to continue to work with the upstream developers via https://bugs.freedesktop.org/show_bug.cgi?id=12769 We can try, in Ubuntu, to minimize regressions and address as many as we can, but we cannot insulate Ubuntu from upstream regressions entirely. to attempt to do so would severely hinder the overall progress of the project. Naturally, though, we should be open to practical suggestions for how we could do better. 2) What about adding some basic hardware testing to these test cases? For example, vga out support never survives a release or two before being killed by X progressing, in my experience, but it is very important for the whole academic community which is one of the primary targets of linux-based environments at the moment. As of now, I own three different laptops, of different ages. For different bugs none of them can project on a VGA projector in hardy, and ALL of them have been able in past releases. This gives a very bad impression of ubuntu to newcomers. This is a very tricky problem, as such bugs are notoriously hardware-specific and can affect only certain combinations of graphics adapter and projector. Some projectors have bugs which make it unlikely that they can work at all without manual configuration. We (Canonical) test a certain amount of hardware on pre-release versions, but can't possibly cover this exhaustively. A community approach is the only practical way to do this, and the testing needs to happen early in the release cycle, when there is still time to analyze and fix the failures. Have you tested your hardware with Intrepid? -- - mdz -- 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: LTS and release methodology
On Tue, Jul 08, 2008 at 04:54:46PM +0300, Peteris Krisjanis wrote: This is easy to say, but consider carefully what it would mean in practice. How could we implement such a policy in Ubuntu? Before we can even begin to estimate the effort required in order to achieve this, we would need to rigorously specify every feature in Ubuntu and how it should work. While this is common in traditional software development models, consider the sheer scope of Ubuntu: how long would it take, and how many people, just to enumerate all of this functionality? Instead, we focus on defining a subset of functionality which can be tested in practice. You can find the corresponding test plans here: https://wiki.ubuntu.com/Testing along with instructions for how you can participate in the testing effort and find the problems which matter to you. But why not then create such subset as spec? For example, for standard desktop? Only such way we can track down regressions and do *planned* testing instead of just jogging strings for known scenarios, leaving corner cases out in the cold. This would definitely help with creating test cases too. What purpose would such a spec serve that isn't already served by the test cases (which already exist)? It is a noble goal to have a rigorous specification for Ubuntu, but consider the effort of keeping it up to date as our thousands of upstream projects continue to change. We do create specifications for projects which we undertake within Ubuntu, but for most everything else, test cases have more practical use in our environment than specifications. The test cases are at https://wiki.ubuntu.com/Testing/Cases, which those of you who have helped with ISO testing (thanks!) will have seen. However, they aren't by any means complete. If you would like to help improve them, you should coordinate that work with the QA team, since these plans are provided as instructions to testers and should be changed with care. In fact, they probably *shouldn't* be complete; we need a useful subset which can be tested again and again. If we were to create a test plan which involved twisting every knob and dial in Ubuntu, nobody would be able to finish a test. -- - mdz -- 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: LTS and release methodology
On Tue, Jul 08, 2008 at 04:13:23PM +0200, Pär Lidén wrote: 2008/7/8 Matt Zimmerman [EMAIL PROTECTED]: On Mon, Jul 07, 2008 at 01:00:00PM -0500, Luke L wrote: Ceteris paribus, regressions should have a higher priority than normal bugs. I totally agree. It's hard to argue with that, but again, I have to look at this pragmatically. It is very rarely possible to tell just by looking at a bug whether it is a regression or not, and collecting this information can be very time-consuming (please boot from an older live CD and try it, then we can decide on the importance of your bug). Yes, it might be tricky in some cases to figure this out, but quite often people say in the LP bugs This worked in Feisty/Gutsy/Dapper. Maybe there could be some flag in LP to mark a bug as a regression? And those bugs would be required to get much more attention. It doesn't have to be more complicated than so. There is a 'regression' tag, and we do try to prioritize these on an ad-hoc basis, but understand that with such incomplete information, it's difficult at best. Perhaps also an LTS release would be delayed if it has too many regressions? (I suppose a zero-tolerance to regressions would be too hard, and delaying the release for too long, but the kernel won't release a new version until all important regressions are fixed. IMHO, something similar should be the case for the whole Ubuntu releases also.) This is already our policy; in fact, we delayed the first LTS release for that reason. 8.04 released with some regressions, but these were considered either a) not severe enough to warrant delaying the entire release, or b) planned to be fixed with 8.04.1. -- - mdz -- 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: Did we really release 8.04?
On Mon, Jul 07, 2008 at 08:30:28AM -0400, Scott Kitterman wrote: This is not sustainable in the long term. Before long people will be saying, Everyone know not to upgrade Ubuntu until the first point release. Then we don't get the end user base to test until .1 and we have to bugfix from there. While this is a natural assumption, if you think about it a bit further, I think you'll agree that this is not the case in practice, because we don't have a single end user base which behaves consistently. Ubuntu serves a wide variety of different users, who have different expectations and levels of willingness to participate. These range from hard-core developers who are already running Intrepid, through power users who may upgrade during the beta period, through enthusiasts who will upgrade as soon as a new release is out, through casual users who will wait until later, to conservative users who will only consider LTS. By orienting our quality processes toward these different groups, we allow our users to choose their own tradeoffs between stability and timeliness. Once 8.04 was released and its problems became apparent, then fixing it was needed and the response from Canonical is laudable. We need to find a way to avoid repeating the experience. The 8.04.1 point release was planned, and the supporting team organized, long before 8.04 itself was released. It was not a reactive move, but a well-considered change in our approach to LTS. Personally, I'd like to hear users saying, Yes, I know it's beta, but it's an Ubuntu beta so I'm sure it's fine. There is one class of users from whom we would like to hear this. But there are also those from whom it's appropriate to hear That's a brand new release, I'm not going near it until the first point release! I think the only path to better tested releases is higher quality test releases. I suspect more discipline about feature freeze is a part of it, but I don't know what else? There is no single path to quality; we should segment our approach and employ the best methods for each stage of stabilization. During alphas, this might mean focusing on installation and hardware testing; for the beta, engaging a broad community of testers to use the new release for their everyday work; for an LTS release, to have comprehensive point releases to fix issues which weren't caught by testing, etc. -- - mdz -- 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
Technical Board decisions, 2008-03-11
At Tuesday's meeting of the Ubuntu Technical Board, two technical decisions were taken with regard to the Ubuntu 8.04 release: * Automatic indexing in tracker will be disabled for Ubuntu 8.04. While we value the functionality provided by tracker and intend to continue to support its rapid development by including it by default in Ubuntu, the side effects of automatic indexing have a significant impact on users regardless of whether they make use of tracker's search features. Instead, users who desire this functionality can turn on indexing by changing their preference settings. * The officially released architectures for Ubuntu 8.04 will be i386 and amd64. The SPARC port will continue to be provided with build infrastructure, and Ubuntu 6.06 LTS, 7.04 and 7.10 will continue to enable SPARC deployments well into the future, but there will not be an official Ubuntu 8.04 release for SPARC. -- - mdz -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Re: Securely downloading Ubuntu
On Mon, Jan 28, 2008 at 10:39:03AM -0700, Neal McBurnett wrote: On Mon, Jan 28, 2008 at 05:20:52PM +, Matt Zimmerman wrote: On Mon, Jan 28, 2008 at 09:28:48AM -0700, Neal McBurnett wrote: (I'm all in favor of moving to SHA256 or whatever is considered best practice these days. I've just not heard that MD5 is really as broken as I think Chris suggests here.) One easy thing to do is to also publish sha256 sums of the CD images, so if MD5 preimage attacks are developed, that would help. I think we should do that now, and consider a hash function in a different class also (whirlpool?). Shipping more hash functions in the base install would help a lot in a crisis, so users have what they need to validate software updates. I guess coreutils has the md5 and sha families well covered, but again, something different like whirlpool could help a lot some day. Perhaps we should publish detached signatures for each ISO rather than signing MD5SUMS? From what I've heard, the main principle for dealing with hash issues is algorithm agility - i.e. making it easy for folks to use multiple algorithms. Publishing detached signatures is a way to make the user interface easier (perhaps) for folks that want to validate the gpg signature. But I would think many (especially those without a good way to trust the gpg key, as noted previously) would want to just be able to validate hashes. I would still argue for the use of multiple hash algorithms, and I guess for gpg that means multiple detached signatures, one per hash algorithm. And some are not supported by all versions of gpg I'd suggest we publish a CHECKSUMS file with a good assortment of hashes in text format, and also sign that. There are two reasons for checking the hashes: Authentication - the downloaded image is in fact the official one provided by the Ubuntu project, unaltered Integrity - the downloaded image hasn't been randomly corrupted in transit (it happens that verifying authenticity ensures integrity as a side effect) Authentication, I believe, would be better served by signing the image directly. This both avoids an attack on the intervening checksums in MD5SUMS and provides a cryptographically stronger check. I believe the .gpg format already supports multiple signatures with different algorithms, so this would be reasonably future-proof. Integrity is served well enough by the existing MD5 hashes, which are still extremely robust against unintentional corruption. The above is based on only a very basic understanding of cryptography, however, so corrections are welcome from folks with more experience in this area. -- - mdz -- 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: Strawman: merge main and universe
On Wed, Dec 12, 2007 at 10:24:56PM +, Scott James Remnant wrote: The distinction between main and universe is instead done based on support. But what does this actually mean? Our terminology on this needs a bit of cleanup, but the relevant distinction here is maintenance. This means that, for example, a security vulnerability in the package will be fixed, and this is backed up by a commitment from Canonical (which has dedicated resources to this maintenance). What about support for fixing bugs? We actually don't like to do that very much, we only have limited updates to our stable release. This surprises most people who think this is what support means. We do need to do a better job of both communicating our maintenance practices and ensuring that they meet expectations. There is work in progress to change this for 8.04 LTS. We move all packages from universe into main, and remove the universe component. Likewise packages from multiverse are moved into restricted, and multiverse removed. Instead, we define who provides what kind of support through meta-data. We have generated lists of packages already, the seeds. In fact, it's these seeds that (by a manual process) result in packages being divided between main and universe right now. So let's just use these to determine the types of support provided. This seems sensible to me; Debian-style components are unwieldy to work with, as they are closely tied to the way the archive is published. We should be able to change a declaration of maintenance without moving files around on a web server, and the placement of the files isn't a very good way of communicating this information. Canonical can declare that it provides commercial support for the ubuntu-desktop, ubuntu-server, ubuntu-mobile and kubuntu-desktop seeds (and any others we support that I forgot). It can also declare what date that support ends. Other companies and groups can declare their own support based on the existing seeds, or just branch the bzr repository and make their own (the seeds are public, and the tool to generate complete package lists is also public). The Ubuntu Security team can declare which seeds they provide security support for at which levels. All reasonable. The packaging tools can then use this information to show appropriate information to the user; they'll know the package they are installing is supported for a further 12 months by Canonical, a further 18 months by another company or group; Security support is provided by the Ubuntu security team for 12 months and critical bug fixes are no longer provided. This is tricky. In order to be effective, this needs to be communicated all the way from apt-cache up through gnome-app-install in a reasonably consistent way. What about upload privileges? Let's do those the same way. Sounds elegant enough, though I wonder about automatically granting upload privileges based on a new dependency. -- - mdz -- 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: Access denied (403) when trying to fetch security updates for Dapper
On Sat, Nov 17, 2007 at 08:21:54PM +1100, Serge de Souza wrote: See https://bugs.launchpad.net/ubuntu/+source/samba/+bug/163042 basically a bad push and permissions were changed on the debs to prevent them from being downloaded. Wouldn't a new release without the broken packages fix the problem of people trying to download something they can't? As you can see from the discussion in the bug report, the circumstances are as follows: - This regression only affects specific configurations (apparently those using the deprecated smbfs module) - There is a straightforward workaround (cifs works) - The vulnerability is not believed to be serious (denial of service only) Therefore, withdrawing the update in order to fix the problem was deemed an appropriate response, given the severity of the issue in affected configurations. Preparing and testing a new update is something which takes time, and should not be rushed. This temporary emergency measure (which is admittedly confusing for users) prevents further downloads while a proper response is prepared. -- - mdz -- 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: Access denied (403) when trying to fetch security updates for Dapper
On Sat, Nov 17, 2007 at 12:14:41PM +0100, Krzysztof Lichota wrote: Matt Zimmerman napisał(a): Preparing and testing a new update is something which takes time, and should not be rushed. This temporary emergency measure (which is admittedly confusing for users) prevents further downloads while a proper response is prepared. Could you in such cases send announcement that such measure was taken and that update will fail (security announcement or at least a message on ubuntu mailing lists). It would at least not leave users wondering why the heck is my automatic update not working. Unfortunately there is no way to reach everyone affected by this measure, though it is documented in the bug report and should be indexed by Google shortly if it has not been already. The security team should follow up to ubuntu-security-announce to notify users who received the USN once they have prepared a response. Especially in case of Adept it is a surprise as it shows the same message when it cannot download the file and when packages system is broken - which happens often if dependencies are not fulfilled or package is half-configured. So I have gone through usual dpkg --configure -a, apt-get install -f, but it didn't work, as the problem lies in completely different place. Please file this as a bug against Adept, if there is not one already. -- - mdz -- 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: Access denied (403) when trying to fetch security updates for Dapper
On Sat, Nov 17, 2007 at 12:57:32PM +0100, Markus Hitter wrote: Am 17.11.2007 um 11:33 schrieb Matt Zimmerman: - This regression only affects specific configurations (apparently those using the deprecated smbfs module) Obviously a pretty common configuration, as I'm looking at a fresh installation of the just released Gutsy Gibbon without additional installs here. The error described in the subject of this email, obviously, affects everyone who has Samba installed and attempts to apply updates. It is confusing, but harmless. The bug which resulted in this workaround is described in https://bugs.launchpad.net/ubuntu/+source/samba/+bug/163042 -- - mdz -- 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: Access denied (403) when trying to fetch security updates for Dapper
On Sat, Nov 17, 2007 at 11:24:07AM -0400, Cody A.W. Somerville wrote: It seems like there has been a lot of complaints about how the update-manager handles the 403 error. Considering the only time the 403 would normally occur is this situation, maybe the update manager could be smarter about it? We should never have to do this; there are some shortcomings in the infrastructure which currently require some manual hacking in situations like this. There is work in progress to improve that. -- - mdz -- 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: apt-cacher in main
On Thu, Nov 15, 2007 at 01:05:01PM +0100, Oliver Grawert wrote: in edubuntu we face the fact that governments and schools start rolling out really huge deployments in the near future (see macedonia with a total of 185000 systems for example), if you maintain 5000 seats in one school or 1 in one municipality it comes in pretty handy to have an apt-cacher in your network to not saturate your internet connection for updates. so i'd like to second the main inclusion. We should be wary of both a) jumping from broad requirements (large deployments would benefit from local redistribution of updates) to actions (let's put apt-cacher in main) and b) focusing too much on niche use cases when there are issues facing a large number of users which need to be addressed. If this is worth addressing, then it is worth thinking through and considering other possible solutions. -- - mdz -- 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: apt-cacher in main + apt-zeroconf
On Thu, Nov 15, 2007 at 12:53:14PM -0500, Fabian Rodriguez wrote: If this was actually checked against a local web of trust (like OpenPGP or Gaim-OTR keys or else) it may become interesting. But who uses that safely ? :) All packages downloaded by APT are authenticated using PGP keys provided in the default install. While it's possible to override this, it's also possible to install untrusted packages in all sorts of other ways, so people who ignore security warnings are already in bad shape regardless of whether they're using something like apt-cacher or not. -- - mdz -- 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 tricky situation in malone bug 60995
On Sat, Oct 20, 2007 at 06:17:24PM +0100, Scott James Remnant wrote: On Sat, 2007-10-20 at 17:27 -0700, Martin Olsson wrote: I really really would like to see BACKSPACE as BACK working in Firefox. I think this is the kind of polish bug that makes a lot of people stay away from ubuntu (beyond hardware problems of course). https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/60995 Is there any established process for dealing with this type of situation. The bug is very very old so I think some kind of decision needs to be made on the issue. Maybe some kind of ubuntu board or some benevolent dictator person or someone could arrange some voting or whatever? You would have to successfully argue why one binding is better than another, countering any argument against that binding. Assuming that, the best way to start the discussion is to do as you've done, and begin a thread on ubuntu-devel-discuss. If this is a major issue, it should get a lot of replies and discussion. Another consideration here is that changes to the defaults like this need to be discussed with Mozilla upstream, as it's important to them that the user experience in Ubuntu be reasonably consistent with their builds. This was the old default, and they changed it, presumably for good reason. -- - mdz -- 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: Announcement: One Click Installer
On Wed, Aug 08, 2007 at 05:14:01PM +0200, Krzysztof Lichota wrote: Matt Zimmerman napisał(a): On Wed, Aug 08, 2007 at 04:58:21PM +0200, Krzysztof Lichota wrote: Matt Zimmerman napisał(a): On Tue, Aug 07, 2007 at 09:57:42PM +0200, Krzysztof Lichota wrote: This is the approach of apt:// protocol. It is not extensible and it will not make Ubuntu competitive to rich software ecosystem of Windows. There _must_ be the way for third party software creators to publish their software easily. Otherwise they will not be interested in creating their apps for Linux. The two are not mutually exclusive, and an ideal solution would incorporate both. One Click Installer can be used for both, providing trusted, signed installation files signed by Ubuntu and providing unsigned files for third party developers. It is not a question of whether the file is signed or not; it is a different abstraction. One is install package X from repository Y. (One Click seems to do this, from your description) The other is install package X from your existing, configured repositories (this is like apt:// and similar ideas) The key difference is that in the latter case, the metadata does not supply a repository, and there should be (notably) none of the usual security issues, regardless of whether the metadata is authenticated. Exactly, so how in this case you want third party developers to provide their apps? We are talking past each other. There are two distinct use cases here, and I am a) saying they could both be fulfilled by the same software mechanism, and b) asking whether your system does both. From the sound of it, it only addresses the explicitly third-party repository case, and not the case where the application is implicitly available from Ubuntu. Yes, there are third-party developers who could make use of such a system to publish their applications, but there are also developers who are well served by the existing system and would benefit from having a web-oriented way to indicate that their software is included in the Ubuntu repositories, delegating all decisions about repository location and authentication to the package manager. -- - mdz -- 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: Announcement: One Click Installer
On Wed, Aug 08, 2007 at 07:19:23PM +0200, Krzysztof Lichota wrote: OK, now I understand what you mean. Yes, you can provide One Click Installer installation file which has only information which package to install and does not contain any repository information. This should cover the second case. Oh, that's excellent then. Thank you. -- - mdz -- 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: Announcement: One Click Installer
On Mon, Aug 06, 2007 at 07:01:35PM +0200, Krzysztof Lichota wrote: I would like to share with you the project I have been working for some time now which I think could help solving bug #1. The problem: - Users coming from Windows (and in general beginners) want installation of applications to be as easy as possible. Download, Next, Next, Done kind of experience. - If you start talking about command line and adding keys, repositories, etc. you have lost them. They will not understand and they will not _want_ to dig into technical details. - There is plenty of packaging formats used on Linux and average users do not want to know the differences between them, they just want to install application. Package installation applications (Synaptic, Adept) and apt repositories do not solve the problem for the following reasons: 1. Repositories must be added manually and this exceeds skills of average Windows user. Keys must be added also and repositories updated. Too many steps, too difficult. 2. Users are not used to going to package management application to install application. They want to click link on application web page, download, run, Next, Next, etc. 3. Package management applications are too bloated with features and contain thousands of applications. Even with categories it is hard to find application that the user needs (think I want a movie player), especially if they do not know name and are presented with 10 applications which they do not know and all do the same or differ in technical details (e.g. uses Xine or uses GStreamer). Users want to have some context - other users comments, grades, etc. 4. Application descriptions are in English (I know about DDTP, but AFAIK it does not work). Many users do not know English and they want information about applications in their language, on native portals with applications (like localized Tucows). 5. User must know that he is using APT with DEB packages. As there are separate APT repositories for each distribution version and user must also know what distribution he is using which version, choose appropriate repository, etc. 6. If user is using some other distribution than Debian-based he is even more in pain, he has to know what package format to use (DEB, RPM, TGZ, Ebuild, ...), what channel (APT, yum, Yast, ZMD, etc.), what distro, which version. Now compare it to installation on Windows - user goes to Google, types movie player download or browses some application catalog like Tucows, selects one with best reviews, downloads installer (in most cases he has to choose between installer for Windows 98/ME and installer for Windows 2000/XP), 3 clicks and he is done. So, here is my shot at solving this problem - One Click Installer (http://code.google.com/p/one-click-installer/). The idea is similar to this implemented in https://wiki.ubuntu.com/ThirdPartyApt, but with broader scope (supporting all distributions, not only Debian-based) and more features. Thanks for sharing your ideas with us in detail. This is an idea which has been on many of our minds for some time, but no one had gotten around to prototyping it yet. One concern that I have is that I feel it is important to ensure that applications and their dependencies are installed from the Ubuntu repositories wherever possible: if the application is available from Ubuntu, it should be installed from there, even if the user found it via a third-party website. This ensures that it will receive official updates, and upgrade properly to the next release of Ubuntu, which is one of the great strengths of package management. Of course, there will be applications which cannot be added to Ubuntu, and so third-party repositories are necessary, but they should be avoided where they are redundant, as they complicate maintenance and upgrades. Does your design address this? -- - mdz -- 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: [Pkg-fonts-devel] Fwd: Draining the font swamp
On Sun, May 20, 2007 at 08:52:48AM +0200, Christian Perrier wrote: (sorry for the crosspost. Please reduce if inappropriate) Thanks for cross-posting; this issue applies to Debian as well, and we would appreciate input from the Debian community. I wasn't aware of pkg-fonts-devel. -- - mdz -- 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: [USN-464-1] Linux kernel vulnerabilities
On Sat, May 26, 2007 at 11:27:45PM +0200, Thilo Six wrote: Hello The kernel security update [USN-464-1] is missing s.th. This is known to the security team, and being worked on. -- - mdz -- 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: URGENT !!! : [USN-464-1] Linux kernel vulnerabilities
On Sun, May 27, 2007 at 10:31:37AM +0200, Thilo Six wrote: now i $ aptitude install linux-image-2.6.20-16-generic and now nvidia is broken !! You installed the new kernel, but forgot to install the corresponding restricted-modules package. -- - mdz -- 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: New applet at gnome panel
You have misunderstood. Lumír is not asking how to get this applet into Ubuntu. It sounds like the question is how to customize the CD to include this additional applet by default. I believe some documentation already exists, as well as some tools. On Sun, May 27, 2007 at 08:07:40PM +0800, DULMANDAKH Sukhbaatar wrote: so go MOTU. On 5/27/07, Lumir Jasiok [EMAIL PROTECTED] wrote: DULMANDAKH Sukhbaatar wrote: I would advice you to include them into GNOME, after that Ubuntu will ship it without choice :). That's the first step. Thanks for your advice, but I don't think, that this applet is something that every Ubuntu/GNOME user would like to have as default applet :-). This is for my personal project - I don't accent this before. Regards Lumir -- Lumír Jasiok VSB-TU Ostrava - Computer centre E-mail: [EMAIL PROTECTED] http://www.vsb.cz -- Regards Dulmandakh -- 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 -- - mdz -- 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: URGENT !!! : [USN-464-1] Linux kernel vulnerabilities
On Sun, May 27, 2007 at 11:22:30PM +0200, Thilo Six wrote: Matt Zimmerman wrote the following on 27.05.2007 22:48 now i $ aptitude install linux-image-2.6.20-16-generic and now nvidia is broken !! You installed the new kernel, but forgot to install the corresponding restricted-modules package. sorry if i exaggerated a bit but i got this green sticker on www.ubuntu.com feeling The right information to the right people at the right time can make the difference between a disaster and genius hat trick. I call that proactive. I'm afraid I don't understand what you mean by any of this. -- - mdz -- 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: Technical Board meeting minutes, 2007-05-22
On Thu, May 24, 2007 at 07:07:23PM +0200, Dennis Kaarsemaker wrote: On do, 2007-05-24 at 15:01 +0100, Matt Zimmerman wrote: On Wed, May 23, 2007 at 06:20:58PM +0200, Dennis Kaarsemaker wrote: On di, 2007-05-22 at 21:59 +0100, Matt Zimmerman wrote: The members of the Board recognized that they have been inconsistent about keeping minutes and thereby communicating decisions to the community. MDZ volunteered to communicate this meeting's outcome, and also noted the potential helpfulness of a secretary to help ensure that this important communication happens. Interested volunteers are encouraged to email [EMAIL PROTECTED] I am already doing this for the CC and so far I get no complaints -- wouldn't mind doing that for the TB as well. That would be great, thank you. Do you need anything from us? Not really, I'll just do the same as for the CC meeting, which is: * Maintaining the agenda * Poking people to come to meetings * Prodding launchpad (well, I won't be able to do that for the TB) * Writing summaries on the wiki (could send them out via mail as well) That would be excellent, thank you for your help. -- - mdz -- 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: Draining the font swamp
On Fri, May 25, 2007 at 01:31:08PM +0200, Jan Claeys wrote: Op zaterdag 19-05-2007 om 12:34 uur [tijdzone +0100], schreef Matt Zimmerman: There has been some confusion and dissatisfaction over the treatment of fonts in Ubuntu for a some time now, and no common understanding of how to improve the situation. I spent a little time thinking about this today, and would like to present some questions whose answers I hope will help us to make some progress. My problem with fonts in Ubuntu is the same problem/dilemma that I had with fonts on Windows in the past: * I want to be able to have a lot of fonts installed on my system, so that things look like they are intended to look when viewing them. * I don't want all of those fonts to be listed in the default font dialogs and font selection widgets. And when I'm doing graphic/design work: * I want to have hundreds or thousands of fonts available and those that I use in a certain project (which can involve lots of different applications) easily accessible. One possible solution to the issues above would be to add a system to fontconfig (or on top of it) that allows for the concept of what I call font groups. Sounds like you want a specialized tool like fonty-python, designed for people who do this kind of work. What I'm concerned with in this thread is the experience of an average user, who cares very little about fonts, just wants their applications to work, and be able to display readable text in their language. We want to have the simplest, cleanest infrastructure to provide this. -- - mdz -- 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: Draining the font swamp
I received this reply off-list; it was only sent to pkg-fonts-devel. Copying back to ubuntu-* as well, as it's very informative. -- - mdz ---BeginMessage--- pgpFnfiU3AlJz.pgp Description: PGP message ---End Message--- -- 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: Technical Board meeting minutes, 2007-05-22
On Wed, May 23, 2007 at 06:20:58PM +0200, Dennis Kaarsemaker wrote: On di, 2007-05-22 at 21:59 +0100, Matt Zimmerman wrote: The members of the Board recognized that they have been inconsistent about keeping minutes and thereby communicating decisions to the community. MDZ volunteered to communicate this meeting's outcome, and also noted the potential helpfulness of a secretary to help ensure that this important communication happens. Interested volunteers are encouraged to email [EMAIL PROTECTED] I am already doing this for the CC and so far I get no complaints -- wouldn't mind doing that for the TB as well. That would be great, thank you. Do you need anything from us? -- - mdz -- 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: Broken Packages Dependencies
On Sat, May 19, 2007 at 12:39:21PM +0200, Thilo Six wrote: Alec Wright wrote the following on 19.05.2007 12:10: Is anyone else having these problems in gutsy: http://pastebin.ca/496576 Should I file a bug report? Broken dependencies are quite usual in development releases. e.g. package A gets updated and now has new dependencies (higher versions or even new dependencies that have not been there before) on B. Now B needs an update, too. In the meantime you´ll get a BROKEN A. Since developers only can work serial on packages these things get usually (from my experience) sorted out in a short days. Note also that the archive is automatically scanned for problems like this, because they can be detected by analyzing the dependencies. https://wiki.ubuntu.com/UbuntuDevelopment#head-9827dcffcca6eba8f5fd799ad13d3fa7f8116c39 This can also be caused by packages which are still building, or waiting to build, on some architectures, and other normal processes. -- - mdz -- 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
Draining the font swamp
There has been some confusion and dissatisfaction over the treatment of fonts in Ubuntu for a some time now, and no common understanding of how to improve the situation. I spent a little time thinking about this today, and would like to present some questions whose answers I hope will help us to make some progress. Please correct me where I've misunderstood, as I've only done some cursory research here. We seem to have: - Loads of fonts, in various formats (TrueType, Type-1/PostScript, PCF bitmap, Metafont, others?) supporting various character sets, of varying quality - fontconfig, a font management framework which seems to be used by of the applications we care about in one way or another. It catalogues the fonts on the system and is independent of any window system, font rasterizer, etc. It just knows about fonts and provides an API to find a font based on complicated matching criteria. - DeFoMa, which attempts to allow packages to register fonts with whatever font management frameworks might exist. - TeX. Enough said. - freetype, a font rasterization engine which also has some font management capabilities, also used by most applications we care about. Knows how to take fonts and strings and create bitmaps. - Xfont, which provides font services (including selection and rendering) through the X server. This is basically obsolete in favour of client-side fonts. - Xft, a font API for X applications which uses freetype and supports Xrender or plain X drawing to put text on a display. I don't know: - Exactly which pieces are used by GTK, Qt, XUL, etc. and how applications using those APIs ask for a font specification - Which applications ask for which font specifications, and where that's configured (sometimes in the application itself, as in Firefox) - Which fonts are any good, and for which languages (no easy answer here) - Which criteria are important for selecting which font to use in which context (language, character set, ...) - Whether fontconfig requires adjustments in order to respect those criteria - Whether we still need all these horrible bitmap fonts - Whether we still need server-side fonts for anything - Whether we need DeFoMa -- - mdz -- 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: Putting security-based applications as a separate menu entry rather than in Accessories
On Thu, May 17, 2007 at 12:49:50AM +0530, shirish wrote: Hi all, What do you guys think of putting things like keyring manager, GPA (GNU Privacy Assistant), Seahorse, and other security-based softwares in a separate menu entry titled Security where all security-based tools including tools for SELinux are there.I know you guys don't like big menus but I feel it would be a good idea to have that. Please lemme know what you guys think about that? We prefer to be aligned with the freedesktop.org standard for desktop menus: http://standards.freedesktop.org/menu-spec/latest/apa.html This lists security as an additional category, but not a main category used to display applications in the menu. Perhaps you could make this suggestion on the appropriate fd.o list and see what they say? -- - mdz -- 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 Mobile and Embedded Edition
On Tue, May 08, 2007 at 11:21:24AM +0100, Ben Francis wrote: In the Ubuntu Weekly News: Issue #39 there was an announcement of the Ubuntu Mobile and Embedded Edition. The link to the mailing list announcement was broken and I think it should have been https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-May/000289.html as we're not in 2008 yet. I'm interested in getting involved with development on this project, specifically the innovative graphical interfaces. Is there any more information available yet? Perhaps a wiki page? There is now, at https://wiki.ubuntu.com/MobileAndEmbedded -- - mdz -- 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: Jackd - update 7.04 repository with version 0.103.0 compiled with default tmpdir=/dev/shm
7.04 has already been released, and will now only be updated for security and high-impact bug fixes. If UbuntuStudio requires newer software, it must either be based on gutsy, or use a supplementary repository (such as feisty-backports, or a dedicated repository of your own, perhaps hosted in Launchpad). On Mon, Apr 30, 2007 at 02:16:37PM +0200, Simon Lewis wrote: Hello Sarah Thanks for your reply. The reason for my request is that I think it is very important for UbunuStudio to have these 2 versions on board. Also very important is a version of ALSA wherby the duplex bug in pcm_multi is corrected. This effects any program whereby the user wants to play any other tracks while recording a new one or play a new track while recording it. This includes ardour, rosegarden, audacity etc.. There is a patch for ALSA 1.013 or the ALSA head is corrected but not made available as a release candidate. Best wishes, Simon Sarah Hobbs schrieb: Hi. Please see http://wiki.ubuntu.com/TimeBasedReleases Thanks! Hobbsee Simon Lewis wrote: Dear developers Please update the 7.04 repository with the current version of jackd compiled with default tmpdir=/dev/shm - thus maximising system performance. Also QJackCtl needs updating to 0.2.22 for 192kHz and freebob support. Many thanks, Simon. -- 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 -- - mdz -- 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: Proposal: Ubuntu Metadistribution
On Thu, Apr 26, 2007 at 01:27:52PM +0200, Gueven Bay wrote: No, this not an abstract thing. And no, there are not many free operating systems based on Ubuntu (SIC! because Ubuntu is basing on an operating system) : There is only one at this moment: Linux (or better GNU/Linux). With my proposal Ubuntu would get 3 other free operating systems under its project umbrella : FreeBSD, NetBSD and OpenSolaris. I think we have a difference in terminology here. My terms, for purposes of this discussion: Linux - a free operating system kernel Ubuntu - a complete operating system based on Linux Kubuntu, Edubuntu, Guadalinex, MEPIS, Linspire, Nexenta, etc. - complete operating systems based on Ubuntu (derivatives), with various components added, removed or replaced (including the kernel) If you wanted to create an OpenSolaris-based Ubuntu, I don't see a reason to use anything other than an APT repository, in order to make use of all of the existing package management tools in Ubuntu. I don't know much about Blastwave, but from your descriptions it sounds like it is not compatible with APT. 1) Because introducing new package managers into the proposed operating systems would unnecessary work. Why do you think so? People have been using dpkg and apt on Solaris systems for years; this works just fine. 2) Because the developers of these package managers make already wonderful work. The package managers are tested, stable and functionally complete That is all the more reason to use them in derivatives, instead of something like Blastwave. An Ubuntu derivative which doesn't use the same package management tools would be much less true to the spirit of the system. 3) Because the users these operating systems have today know already their package managers and they are ready to give help for new users. They also know their shell and other UNIX utilities, their X server, their desktop...however, these things are not Ubuntu. So there is no need to translate the base systems of *BSD and OpSol to a dpkg structure. Just make the package managers and the archives more easily usable (just as Ubuntu did with Debian 'til today). Ubuntu inherited its package management infrastructure from Debian, and uses most of the same tools. They are entirely compatible in terms of the packaging interface. Here you are proposing something more concrete. Are you asking for space in the Ubuntu repositories to work on this? Would you then create such a distribution? I already asked for permission to start a 3rd party project thread in the ubuntuforums. https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-April/000778.html My thinking was that if I get this permission then this thread would become the starting point for the metadistribution. But if it is even possible that I get space on the Ubuntu repos then I could begin with the practical work right away. So, the answer to your questions are : Yes and Yes ;-) If you are asking for resources, then you would need to propose your idea to the Community Council, who would need to be convinced that the project would become a reality. I think that would be premature at this stage, however. In order to use the Ubuntu trademark in your project, you would need to obtain permission first. My suggestion to you would be to follow a procedure something like this: 1. Refine your idea so that it can be explained in clear technical terms to others 2. Create a proof of concept or prototype, using a name of your own invention, which others can try 3. Apply for an official team and trademark status -- - mdz -- 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: Proposal: Ubuntu Metadistribution
On Sat, Apr 21, 2007 at 08:13:13AM +0200, Gueven Bay wrote: So what is it that you are proposing specifically? What I want is to combine the worlds of several free operating systems with the philosophy of Ubuntu: ease of use, shiny new releases every eye blink , cool community, business awareness but - with the combination of several operating systems under Ubuntu - the _full_ choice the free software world gives. You are proposing something very abstract, which I could interpret as something which already exists. There are already many free operating systems based on Ubuntu, and the system has been architected so as to make it easier to create more. Let me specify this - with the things I wrote above in mind- in the example of Ubuntu/OpenSolaris: The original OpenSolaris with its libs and docus and userland (in the OpenSolaris world these are called consolidations) + The packages to get all the functionality of a Ubuntu Release (CD/DVD) from the Blastwave repository (this is a repo which gives the Solaris user an apt-get like structure. If you wanted to create an OpenSolaris-based Ubuntu, I don't see a reason to use anything other than an APT repository, in order to make use of all of the existing package management tools in Ubuntu. I don't know much about Blastwave, but from your descriptions it sounds like it is not compatible with APT. + The Ubuntu specific programs and packages ported to OpenSolaris (for example the installer, the update notifier but also the Gnome adaptations of Ubuntu). Please have in mind here that the OpenSolaris world stays as it is and it is known to the user (with some very little adaptations). This all combined in the Ubuntu repositories , with the apropriate user mailing lists and forums, tested for half year release as Ubuntu/GNU/Linux is tested and released every six months. Here you are proposing something more concrete. Are you asking for space in the Ubuntu repositories to work on this? Would you then create such a distribution? -- - mdz -- 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: texlive
On Fri, Apr 20, 2007 at 10:39:06PM -0700, Jordan Mantha wrote: snip 3. Transitions. I think gutsy will mostly likely see a tetex - texlive 2007 transition although I haven't seen any specs are talk about that. Maybe a good topic of discussion? Debian/sid has already transitioned, so won't gutsy automatically pick this up unless otherwise prevented? Well, the issue is more replacing tetex with texlive in Main. Currently texlive is in Universe and tetex in Main. We'd need to coordinate with core-devs and do Main Inclusion Reports. I wonder if we need a spec for this? Perhaps Matt Zimmerman or Martin Pitt could give us some guidence here. A main inclusion report should be sufficient; if Debian has made the package dependency transition then that should be pulled in during the merge. The remaining work (looking after it in Ubuntu, pulling in any additional Debian changes, responding to bugs) sounds like a job for the TeX team you just created. -- - mdz -- 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: Standardised Hardware Support Spec - Please Review
On Fri, Apr 06, 2007 at 04:37:19PM +0100, Alex Jones wrote: On Fri, 2007-04-06 at 15:20 +0100, Matt Zimmerman wrote: Similarly, I don't see how a new set of metapackages for every supported device (even if that were possible) helps to simplify this. You say that as if it isn't possible. Why? Because of the size and rate of change of this data. Who would collect, formalize and maintain it, and how? Tens of thousands of devices are supported by Ubuntu. The metapackage generation would be done by using the hardware database. It wouldn't be much work to add a new hardware device to the database, and then officially say it is supported in order to do a number_of_devices_supported++. The hardware database does not contain information about packages, only the hardware present in the system (and a few other bits). It gives us an idea of which devices are being used with Ubuntu and whether they are well supported. I don't think there is a tangible general problem to be solved here, and that the issues you raise are likely to be more easily addressed directly (as with gnome-pilot) rather than by new infrastructure. How do you address the gnome-pilot issue? Uninstall it when you /don't/ have the hardware? Unfortunately, hal and udev don't support not-plugging yet. By allowing the user to uninstall it if they desire, without interfering with the metapackage infrastructure. I was primarily answering the question you asked above. The reason this driver is on your system is that some users do need it, and the approach we've taken in Ubuntu is to support a wide range of hardware by default. This involves a tradeoff in disk space and (occasionally) a menu item, in exchange for simplicity. I just find it a completely unintuitive pain in the butt to keep my Ubuntu system lean. I just want to say I only want support for this set of hardware. Everything else, get out. We're working toward an ideal of everything simply works for as many people as possible, while what you seem to be after is I have exactly what I want, no more and no less. While these aren't necessarily in conflict, in practice they result in different priorities for a project. Gentoo, and more recently rPath, are pursuing the latter approach, as is (to a lesser extent) Debian. -- - mdz -- 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: feisty + GUI performance in VMware player
On Wed, Apr 04, 2007 at 11:15:23AM +0200, Petr Hrdlička wrote: Hello Team, since last updates from this morning, yesterday and last Partial Update I'm experiencing very low performance of GUI. This drives me little bit crazy. Even the mouse cursor isn't moving smoothly. I'm running feisty since it's first devel release on VMware Player and this is first time the GUI is going terribly slow. Any ideas how to correct this ? The first devel release of Feisty was December 6; surely you mean the beta release instead. Have you tried the live CD running directly on the hardware rather than VMWare player, to see if the trouble is related to that? -- - mdz -- 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: Standardised Hardware Support Spec - Please Review
On Wed, Apr 04, 2007 at 12:57:06PM +0100, Alex Jones wrote: This comes about as more and more people question why their computer starts bluetooth services when they don't have a bluetooth device, or why I have a HP printer driver control panel applet, or a Palm Pilot sync applet, or PCMCIA services, etc. etc. etc... This was a conscious decision. Our belief is that users should not need to find or install additional software to make use of common devices. They should just work out of the box. If your intent is to suggest a way to address the problem of superfluous menu items, a better way to do that would be to investigate hiding the menu items unless the relevant hardware is detected (via HAL). -- - mdz -- 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: Standardised Hardware Support Spec - Please Review
On Thu, Apr 05, 2007 at 09:24:19PM +0100, Alex Jones wrote: (As a side thought, I'm not sure what constitutes common hardware, but I for one don't know a single person who owns a Palm device.) I can see two or three Treos from here. Whether they work with gnome-pilot is another story, but if gnome-pilot doesn't work with a significant share of current devices, the solution would be to remove it from the default install, not add a new application to help the user remove it. -- - mdz -- 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: Error in wiki page DebuggingProgramCrash?
On Thu, Mar 29, 2007 at 07:11:23PM +0200, Christoffer Sørensen wrote: Hi, I noticed the following on the wiki page https://wiki.ubuntu.com/DebuggingProgramCrash Install the needed .debs (they will be in the current working directory if the build succeeded): sudo debi package*.changes shouldn't that be sudo dpkg -i package*.deb Sorry if I am posting to the wrong list. The debi command is more correct. Consider what would happen if there were other .deb files in that directory which were not part of the build, and also that a source package foo might produce a binary package like libfoo which wouldn't match package*. -- - mdz -- 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 Policy on binary driver bugs
On Thu, Mar 29, 2007 at 12:10:29AM +0100, Sitsofe Wheeler wrote: After reading yet another series of threads regarding the NVIDIA binary drivers I would like to ask: What the Ubuntu position is towards binary driver bugs?. Does Ubuntu take a similar stance to Red Hat whereupon the moment you taint your kernel your bug will be closed and you will be directed towards NVIDIA for help ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73733 / http://fedorasolved.org/video-solutions/3rd-pty-video ) or is Ubuntu going invite NVIDIA engineers to review NVIDIA related bugs within Launchpad the way Novell/SUSE currently does (e.g. https://bugzilla.novell.com/show_bug.cgi?id=147009 - Andy Ritger works for NVIDIA)? Perhaps Ubuntu is going to encourage a halfway house where people are requested to post over in the bugs.freedesktop.org closed NVIDIA component? We take responsibility for kernel bugs where we do not believe that a binary driver is to blame, and we will work with hardware vendors to share bug tracking information. What we cannot do is take responsibility for analyzing or fixing bugs which are the fault of a binary driver. -- - mdz -- 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 Tags, especially 'bitesize'
On Thu, Mar 15, 2007 at 12:47:58PM +0100, Daniel Holbach wrote: Hello everybody, a lot of teams have been using the tags feature of Malone to better organise their workflow. In an attempt to agree on common tags for the same thing, the BugSquad, the MOTU team, the Desktop team and others agreed on the ones listed at: https://wiki.ubuntu.com/BugSquad/Tags One of the most important items is the 'bitesize' tag. It classifies bugs which are suited for new community members who'd like to contribute to Ubuntu. If you find bugs that you don't have time to fix but will invite contributors to your team, please use the tag. For a list of bugs that were already marked as 'bitesize' take a look over here: https://beta.launchpad.net/ubuntu/+bugs?field.tag=bitesize Other important tags: * 'likely-dup' for bugs that might be a duplicate of another one. * 'packaging' classify packaging bugs. * 'ubuntulove' for small projects - definitely bigger than 'bitesize'. Please let's all make an effort to tag bugs, so we build up our own automatic todo list. Thanks for getting this started. It's so valuable to have lists like these to help new contributors find ways to get involved. I've added a link to http://wiki.ubuntu.com/UbuntuDevelopment so that it's easily found from the website. I suggest adding it to an appropriate place in the MOTU documentation as well, as a place to look for predefined tasks that need to be done. -- - mdz -- 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: Release notes should warn against installing Ubuntu on old machines
On Tue, Mar 06, 2007 at 10:12:15PM +, Sitsofe Wheeler wrote: Ubuntu can have serious problem when installed on machines whose BIOSes cannot read files past the 1023rd cylinder. This is a well known problem and there have been a fair few reports of this problem listed on the forums as well as within launchpad. One of the more recent version of these reports was marked as rejected: https://launchpad.net/ubuntu/+bug/88633 I feel this is wrong as there is no indication that Ubuntu is a poor fit for old machines. The installer should check to see if the BIOS is older than 2001 and if so, put up a warning saying that Ubuntu is not suitable for such an old system. Additionally, the release notes should also mention that Ubuntu is not designed for old systems to save people the negative experience of going all the way through the install and then being unable to boot the machine at the end. Perhaps a force option can be used at grub/isolinux for those who want to go ahead anyway... There are a few reasons why this issue is complex. Most GRUB failure modes only provide a numeric error code, and so it's difficult to determine the cause of the issue. You may see many similar reports, but it isn't necessarily true that they're all caused by a particular BIOS issue. We know that there are situations where Ubuntu will install to the hard drive and then fail to boot, but the range of causes and solutions is not very well understood by the development team. Your proposed solution, to draw an arbitrary cutoff point and discourage users from using Ubuntu on systems over a certain age, would unnecessarily exclude a large number of systems capable of running Ubuntu without a problem. I have personally run Ubuntu on several systems older than 2001, and of various ages with hard drives with more than 1024 cylinders, and not had a problem. Whether the system can boot a default Ubuntu configuration depends on a number of factors other than the number of cylinders on the disk, such as whether the BIOS supports LBA mode. Furthermore, the solutions to the problem also vary. Often, changing the BIOS configuration is sufficient. Sometimes (such as when another installed operating system is relying on the current BIOS configuration), this is not an option. A much better step would be to develop a test which could detect whether the system has this problem. As a first step, this could be used in the installer to warn the user of a potential problem before they take any destructive steps. Later, it may be possible to work around the problem automatically by using a different partition layout, so that the kernel is always near the beginning of the disk, in which case the earlier work to detect it would continue to be useful. We know that Ubuntu, in various flavours and configurations, *is* suitable for older systems, so we should not exclude them out of hand. I believe Paul Sladen knows a thing or two about PC BIOS quirks, so perhaps he has some input for us. -- - mdz -- 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: Java obviously not working
On Thu, Mar 01, 2007 at 04:28:53PM +0100, Markus Hitter wrote: /tmp/isijp053E/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory This is running a Java VM included in the application, not the Java included in Ubuntu. If you can get it to use the system VM, you might have better luck. -- - mdz -- 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: Technical Board decisions
On Wed, Feb 28, 2007 at 09:49:51PM +, Matthew East wrote: On Tue, 2007-02-13 at 09:31 -0800, Matt Zimmerman wrote: * However, new infrastructure will be implemented which allows the user to trivially enable both enhanced desktop effects and the necessary driver support. Has this infrastructure already been implemented? If so, can someone explain what it is, so that we can document it before the string freeze? If not, perhaps the person in charge of implementing it can explain roughly how it will work so we can make a start? System-Preferences-Desktop effects is the user interface, now present by default in current Feisty. I believe Martin Pitt (CCed) is working on the driver bits, and can advise if there's any necessary documentation. The intention was that enabling desktop effects would automatically enable the driver if necessary, while informing the user of the relevant issues. -- - mdz -- 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: More explicit names for iso images ?
On Fri, Feb 23, 2007 at 04:08:03PM +, john levin wrote: Laurent wrote: Hello Now, every iso files of feisty (for instance) are named feisty-desktop-i386.iso. This is the same name for Ubuntu Herd-3 and Kubuntu Herd-4. I think that names should be more explicit. As for example herd3-desktop-i386.iso and kherd4-desktop.i386.iso. The name should completely determines the nature of the software. +1, it's a problem I've just run into. Have you filed a bug report? The right thing to do is to discuss this with the development team first, and establish some consensus about the right thing to do, before filing a bug report asking for a change. CCing the cdimage team for comment. Incidentally, Canonical provide 4 distro-flavours of the isos: Ubuntu, Kubuntu, as mentioned above, but also Edubuntu and Xubuntu All are named feisty-desktop/alternate/etc, and all should be easily distinguishable from one another. I agree with the points raised above; it would be valuable in many instances to be able to determine the precise version of an ISO from the filename. However, as it happens, I (and probably other developers as well) rely on having a fixed filename in order to do things like automatically rsync the latest images without knowing their name. It's likely that we can find a compromise which satisfies both needs, like using symlinks, but this illustrates the need for discussion before pushing a particular solution. -- - mdz -- 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: Handling crash reports
On Thu, Jan 25, 2007 at 04:29:03PM -0600, David Farning wrote: This is follow up to the changing nature of bug reports from a few weeks ago. On the Mozillateam our triagers are getting swamped with automatic crash reports. I would like to make a few suggestions that would greatly help our efforts and hopefully others developers too. 1. Add a top level boolean that categorizes issue reports as crashes. This will greatly aid the sorting of bugs for different types of triagers. If your intention is to suggest this as an improvement to Launchpad, then you should send it to the launchpad-users list (the Launchpad developers don't read ubuntu-devel-discuss). 2. Automate the process for apport to upload crash report data. Many of our issue are reports of crashes without the crash data. This is now implemented in Feisty, as we had been working along these lines for some time now. 3. Automate the process of symbolizing crash reports. The process of downloading the crash report, running apport-retrace, and re-uploading the now symbolized crash report is very slow for all but the fastest network connections. This has, of course, been our intention from the start, which is why you see that all of the pieces for it already exist but need some work to be glued together. Unfortunately, this gluing is sometimes the hard part. Newer versions of apport in Feisty provide a more standardized summary for the bug, which should help in culling duplicates. If the reports are only useful with debug symbols, then apport could check whether firefox-dbg is installed, and guide the user to install it in order to submit the report. The new apport hook infrastructure might be sufficient for the task. -- - mdz -- 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: restarting firefox
On Sat, Jan 27, 2007 at 11:37:01PM -0600, David Farning wrote: A number of browser related bug seem to caused by not restarting the browser after updating some packages in the system. These packages seem to be firefox itself, some themes, and some fonts. Until the mozillateam gets these issues sorted out, would it be feasible to have update manager request that firefox be restart if any themes or fonts are updated. This is already done for Firefox itself. Can you point to some of the apparent issues with themes and fonts? I've never known those to cause a problem. Martin: how about an apport hook which would check for the existence of the file which indicates that a restart is needed, and suppresses the problem report, apologizing and telling the user that Firefox must be restarted after updating it. -- - mdz -- 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
