[Bug 1273386] Re: Neutron namespace metadata proxy triggers kernel crash on Ubuntu 12.04/3.2 kernel
Stefan, what's the most important thing we could do to help you help us? I see a few threads of inquiry in the comments that trailed off: - abstracting Salvatore's script for high thrash rates on VM creation/destruction and network namespace creation, to try reproducing the issue without running openstack - ext4 vs ext3 - capturing crashdumps from a devstack gate run (or simulated gate run on a local machine) - determining whether the failure is a regression from a previous version of the kernel (seems not) - determining whether the failure occurs on 3.11 kernel in addition to 3.2 kernel (seems it does) What looks most promising? This is a critical issue, and still producing intermittent failures, so it's worth a prod or two on the OpenStack side to get things rolling again. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1273386 Title: Neutron namespace metadata proxy triggers kernel crash on Ubuntu 12.04/3.2 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1273386/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1181643] [NEW] Display error (full-screen) on resizing table cell
Public bug reported: I really don't know if this is Unity or LibreOffice, or some unfortunate incompatibility in API usage between the two. But, when I click and drag the divider to resize a table cell in a LibreOffice Writer document, the entire screen turns to hashed garbage (see attached screenshot). As soon as I release the mouse click, the screen snaps back to normal (and if I moved the mouse while pressed down, the table cell is successfully resized). This is LibreOffice 4.0.2.2, on Ubuntu 13.04. ** Affects: libreoffice (Ubuntu) Importance: Undecided Status: New ** Attachment added: Screenshot from 2013-05-18 17:55:42.png https://bugs.launchpad.net/bugs/1181643/+attachment/3680552/+files/Screenshot%20from%202013-05-18%2017%3A55%3A42.png -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1181643 Title: Display error (full-screen) on resizing table cell To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1181643/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: reflecting on first UDS session on rolling releases
On 03/07/2013 06:50 AM, Scott Kitterman wrote: We've gone a long way to making backports easier, but I don't think there's much low-hanging fruit left. We can provide more help, and spread the word that backports can be easy. That's about it? Mostly what we need is (like many things) more manpower. Backports are certainly not ideal for the reasons you give, but if someone is not up to dealing with the relatively modest technical requirements for getting a backport approved then I think they are very much not the kind of people that should be running the development release. One possible alternate future out of many would be to take a fraction of the Canonical-funded manpower that currently goes into the development releases, and put it instead into Backports. Particularly, identifying a set of packages that ordinary users are most likely to need backported to the LTS and proactively keeping them up-to-date with the latest versions of the packages. That won't cover every user's need, but it provides a stair-step between don't change anything and give me the firehose of updates, more like I really only care about the latest version of Foo. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/07/2013 09:40 AM, Steve Magoun wrote: Some observations from the big-OEM perspective: 1) The support lifecycle of the OS is important; an 18 month support lifecycle is too short for a product that may be manufactured for 3 years 2) Switching OSes in the factory is expensive and large OEMs like to do it infrequently 3) Stability is critical and the quality standards are high. Functionality like suspend/resume has to be rock-solid. To date, even the LTS releases need tweaks before they're stable enough to be delivered to OEMs. From that point of view, standardizing on the LTS releases is a clear win, and large OEMs are already pretty well insulated from the interim releases - we treat the interim releases as a series of technology previews. Do you have a sense of what handset manufacturers will need, just in general terms? I know that phones/tablets were mentioned as a motivation for rolling releases. But, I haven't heard any mention so far of things like the FCC approval process. The certification requirements on what can be shipped as a phone are very, very different than those for laptops/desktops. It seems likely that the OEMs for phones will also prefer, or even be required by law, to stick to LTS + tightly controlled updates to a few specific packages. That said, I recognize that other OEMs like System76 and ZaReason have different goals and constraints than the big OEMs. I find that refreshing and exciting, and I hope they continue to prosper as part of Ubuntu's growing ecosystem. Meeting their needs is a core requirement in the choice between alternate futures. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Follow Up from Let's Discuss Interim Releases
On 03/07/2013 07:15 PM, Scott Kitterman wrote: Maintaining the current cadence should also be one of the options. That would be the default if no proposal was submitted to the TB or no proposal approved by the TB. Or, do you mean there's value in writing up the advantages of the current cadence in parallel to the other options, for a clearer comparison? I can see that. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/06/2013 07:13 AM, Jonathan Carter (highvoltage) wrote: On 06/03/2013 16:19, Matthew Paul Thomas wrote: There are three parts to Rick's proposal: 1. dropping non-LTS releases 2. making the development version a rolling release stable enough for enthusiast use 3. introducing monthly snapshots. As the conversation runs on, these enthusiasts appear to be a smaller and smaller subset of the Ubuntu user base. So, we're investing enormous engineering effort in a small subset of users, and very little engineering effort in the user experience of the majority of users on the LTS. Also remember that, as the idea currently stands, the tiny set of enthusiasts are the only people who will get updated versions of applications. The majority of users will have a stale experience, and no reasonable alternative. Thanks for that. Apologies if it's been posted before and I somehow missed it, but is there a wiki page or something with the proposal as it exists today? Not yet. The idea is still in rapid flux on the mailing list and in UDS sessions. I anticipate a draft proposal on wiki.ubuntu.com in a week-ish after UDS. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On 03/06/2013 04:21 AM, Loïc Minier wrote: If I take Chrome as an example, I can see how you can be interested in testing latest crack to integrate with it, report issues with it, get it first before you're interested etc. but you know you might get bugs; so you'd be on the beta or dev channels, just like one can get Firefox beta. But most users are on the stable channel or use the non-beta Firefox and they get updates all the time, but updates that have been staged in various ways and hit them from time to time, often without them even noticing. There might be a fundamental split here between server deployments or old-world IT approaches where you want tight control over what comes in, use the same bits for a long-period. Clearly that's not what we want for client where we want our stuff to reach as many people as possible as soon as possible, but not too soon as it needs to be good enough. The current -proposed step isn't sufficient to stage changes; the proposed monthly releases might be more suitable, but I don't really like them because they are either suck too much effort to get them good enough or they would not be good enough. I was nodding along with this, and beginning to picture a 3-pocket model where: * -proposed is the cowboy-country where Debian syncs are automatic, FTBFS and other issues are held for developers to fix before packages go on to, * -testing is a solid candidate for end users, and where integration testing and translation work are done. On a regular cadence (monthly? weekly?) packages move as a set into, * The end-user visible archive. When a user is running the rolling release they get updates from this archive, not from -proposed or -testing. This is analogous to a DevOps model of local VM (where anything goes), a staging server, and a production server. Or in source control a topic branch, an integration branch, and a release branch. My preference would be for some kind of Ubuntu + Unity base rootfs that people can't touch; their apps are installed in some separate hierarchy and they can update their Ubuntu + Unity base rootfs efficiently all the time to get security fixes and latest features. We would have an easy way to push an update for a security fix, and an easy way to stage what goes in it. We do need some branch of (a subset of) the archive to build that though. This sounds like an abort button when things go really, badly wrong. But not a solution to providing a stable user experience. Conflicts between installed apps and the base are real regressions. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/06/2013 07:51 AM, Anca Emanuel wrote: [quote]As the conversation runs on, these enthusiasts appear to be a smaller and smaller subset of the Ubuntu user base.[/quote] You will be surprised how many people prefer an rolling release. Think a bit: that will be the next LTS, so it need to be stable every day, and extra for the LTS release day. They may want the fresher software, yes. But if the rolling un-release is too bleeding-edge, floods them with untested/unstable updates, crashes regularly, randomly breaks their apps because the API carpet was yanked out from under them, etc, then really, they won't be able to use it. We effectively have two possible alternate futures on the table: A) The rolling release is essentially a development archive for the next LTS, and not intended for general use. B) It is a real rolling release, with high enough quality that we recommend it for anyone and everyone to use. The only version of reality we can deliver tomorrow is (A). But (B) is possible with 6 months of intensely hard work, or a year of moderately hard work. It's not yet clear if (A) or (B) is the ultimate goal, they're still suspended as a quantum superposition of equally possible futures. But, the engineering plans to achieve (A) or (B) look very different. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
reflecting on first UDS session on rolling releases
There were a few things that concerned me in today's session on cadence of rolling releases: http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-release/ But, the biggest was at the very end when System76 said that two years is too long between releases for their customers, but that they were willing to at least *try* the new rolling releases. The reply was that the rolling releases weren't expected to be stable enough to deliver to customers. This surprised me, since stability is exactly the purpose of rolling releases. If the rolling releases really aren't intended for end-users, then we should just drop the fiction, say the change is from a 6-month cadence to a 2-year cadence, and be done with it. Yes, it has all the problems we've come to know-and-hate with stale applications. So, either allow SRU exceptions for more applications like we do for Firefox, or start really supporting Backports for the LTS. It's a waste of everyone's time and effort to rework the whole project around talk of rolling releases when it's really just the same old development release on a slower schedule. (Remember how we used to call monthly images alphas and betas? That was ages ago, like 4 whole months.) Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/05/2013 04:41 PM, Michael Hall wrote: I think different segments of the community have different ideas of what stable means: Distro devs power users: stable == things don't break App devs, OEMS, NTEU: stable == things don't change I think what we're going for in a rolling release is a release where things change, but don't break. While an LTS release is one where things neither change nor break. It wasn't stated as you might prefer the LTS, many OEMs do. It was stated as you shouldn't deliver the rolling release to customers. And, really, that does seem to fit the discussion threads. It doesn't sound like it's possible to deliver a user experience in the rolling scenario that would be high-enough quality for System76 to ship directly to customers (and many of theirs are power users). Even people who are totally on board with rolling releases are still calling it the development release. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/05/2013 07:47 PM, Robert Bruce Park wrote: That's how I've been interpreting this all along... 2-year release cadence, and the current dev release is simply declared rolling without any real changes. I don't see any issues with this: it's a huge reduction in SRU burden while allowing more developer time to be spent developing things. I don't have a problem with a 2-year cadence either. It's a sound engineering plan. The risk comes in building up a lot of hoopla about rolling releases being a stable replacement for the 6-month cadence, not investing the resources required to really develop/support rolling releases right now, and then failing to deliver anything remotely close to the stability of the prior 6-month releases. It's better to under-promise and succeed beyond expectations, than to over-promise and appear to fail. It's easy enough to declare a 2-year cadence, and say that rolling releases are an idea we'll be working on and plan to have solid after the 14.04 release. That leaves time and space to do things right, and only announce they're ready when they really are ready. This still leaves the question of how best to support OEMs like System76, and the Flavors. But I think jonathan is on the right track with LTS + key package sets (or 13.04 + key package sets, if that's declared the final 6-month release). Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
On 02/28/2013 07:31 AM, Rick Spencer wrote: To succeed at this we will need both velocity and agility. Therefore, I am starting a discussion about dropping non-LTS releases and move to a rolling release plus LTS releases right now. Hi Rick, At the moment, this proposal sounds mostly like a handwavey Do less work and get better results. Yay! I do understand that you're more of a traditional manager than a developer, so I'll give it the benefit of the doubt and assume you just haven't explained it very well. Could we have some developers explain how this model might work, in real-world engineering terms? I'm not entirely opposed to the idea that the Debian development model of 2-year stable releases with an ongoing unstable archive has been right all along. But frankly, if someone came to me with this proposal you've posted as a startup and asked me to invest in it, I'd say You haven't demonstrated that this is technically feasible. and kick them back to the drawing board. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
On 02/28/2013 11:26 AM, Rick Spencer wrote: The daily quality parts are well documented in blueprints from the last several UDSs and we are running them. For handling monthly releases, there is a proposal on how to do that: https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots That's a good start. A little short on details. Otherwise, it's mostly a matter of stopping doing things. It's a matter of stopping doing things that currently work, that we know lead to a stable product, that's friendly to end users. Producing a high-quality OS takes work. You can't just stop doing work. You have to replace some parts of one development model with new work in the new development model. Oh? I would point to our last several years of improving Daily Quality and at Raring as it is today. I think our track record for making a highly usable development release is quite excellent. The quality of the daily builds has certainly improved. But, there's still a quantum leap between that and a level of quality I'd expose to end users. The quick reply (while appreciated) still doesn't answer my question: I want a detailed *technical* description of the new development model. If it helps you, draft it as an engineering plan to be presented to Mark, convincing him that this is a good use of his money. I suspect there's a good chance that if we all work on the technical details together as a hypothetical reality, we can achieve a version that is a truly compelling replacement for the 6-month cadence. But it's not there yet. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: 12.10 upgrade path - Re: Let's Discuss Interim Releases (and a Rolling Release)
On 02/28/2013 09:36 PM, Scott Kitterman wrote: On Friday, March 01, 2013 06:16:18 AM Martin Pitt wrote: +1 on that from me as well, unless it turns out in discussions that we are doing 13.04 after all, and only drop 13.10. Now would be a good time to be discussing this change for after 14.04. Doing this mid LTS - LTS cycle is going to be problematic for a variety of reasons. I we had a year to get ready, then we might be in a reasonable place to decide on making a transition like this. Yes, I'd find the plan more believable with a year to manage an orderly transition. Time to boost quality procedures, time to implement and test parts of the plan and regroup if they don't go as anticipated. (No plan survives first contact with reality.) Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Developer Summits Now Online and Every Three Months
On 02/26/2013 05:10 PM, Jonathan Riddell wrote: I think this is a terrible shame. A virtual event will result in far less focused sessions. It will also remove the important community bonding aspect of UDS. I'm torn. On one hand, I firmly believe that it's important for the future of Ubuntu (the distro) to have Canonical become a *profitable* company. That's not an easy transformation, and succeeding in that will require making cuts, even difficult cuts. On the other hand, I'm really not sure what Ubuntu (distro or project) will be without face-to-face UDS. It's just a big unknown, that hits me on multiple levels: - UDS is (so far) the only place where volunteers and employees mix in high-bandwidth on fully equal footing. Working at Canonical is like UDS all year-round, so it's hard to see that from the inside. But after being both inside and outside, I noticed a sharp difference. A virtual UDS might have the same effect, though remote sessions often dull the impact of meetings like that. Hard to tell. Honestly, the best integration I've ever had on a geographically distributed team was with a daily phone call. So, there's a chance that going virtual will encourage Canonical to be more open on a regular basis, instead of saving it all up for UDS. There's also a chance that the iron curtain will drop, and we'll never hear another peep out of Canonical. I don't think the iron curtain scenario will play out, but it's something they'll have to be very careful about. - Canonical aside, UDS has served as a key point of community cohesion over the years. Without UDS, there is a risk of drift off to such a degree that there's really no community left to speak of. But then there's also a chance that having Canonical step down from the driver seat of events will open up whole new doors for community activity. If UDS is really going away, it might be time for a community-organized annual event to take its place, like PyCon, DebConf, ApacheCon, etc... - UDS has been a very good connection point for Ubuntu and for Canonical. It has provided a key conversion experience for other projects to more actively support Ubuntu, and for other companies to enter commercial relationships with Canonical. UDS is good for business. It shows off the best and the brightest of Ubuntu in a way that just doesn't happen anywhere else. It makes Ubuntu sexy. I don't know what will replace that. - There are a lot of people I really like, who I only see at UDS. I have a very real sense of grief at will I ever see so-and-so again? It's certainly not Canonical's job to pay for my social life. :) But, it's important to me, enough to be willing to invest effort in making sure that doesn't happen. Robbie blogged recently about removing non-LTS releases (rolling release). I wonder if this three month UDS frequency is part of that. Removing non-LTS releases will remove a lot of what makes Ubuntu a great community project, cadance has always been a hallmark of Ubuntu. This I'm not concerned about. We've been talking for years about the fact that server users are either very conservative and stick with the LTS releases, or in the cloud space and want the latest images right now not 6 months old. The non-LTS releases have never really been relevant server-wise. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 1106378] Re: FTBFS: encoding issue in manual override of dh_auto_test
** Changed in: libsvn-web-perl (Ubuntu) Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1106378 Title: FTBFS: encoding issue in manual override of dh_auto_test To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsvn-web-perl/+bug/1106378/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 269542] Re: Missing dependencies
libtemplate-plugin-number-format has been in universe since lucid. Current versions of the libsvn-web-perl package depend on both libtimedate-perl and libtemplate-plugin-number-format. Closing this bug as no longer relevant. ** Changed in: libsvn-web-perl (Ubuntu) Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/269542 Title: Missing dependencies To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsvn-web-perl/+bug/269542/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1106378] [NEW] FTBFS: encoding issue in manual override of dh_auto_test
Public bug reported: The libsvn-web-perl package is currently FTBFS in raring-proposed. This is a sync of the Debian package libsvn-web-perl version 0.63-1. The FTBFS consists of three test failures in t/2basic.t, all receiving this error from svn: Can't convert string from 'UTF-8' to native encoding... Here's the full build log: https://launchpadlibrarian.net/121688829/buildlog_ubuntu-raring-i386 .libsvn-web-perl_0.63-1_FAILEDTOBUILD.txt.gz Those tests are intentionally trying to save unicode file names, but the buildds apparently don't have UTF-8 encoding set in the environment, so subversion refuses to handle the UTF-8 strings. There's a partial fix for this in the Debian package for 0.63-1, debian/rules sets an override for dh_auto_test, setting the LC_CTYPE environment variable, with: override_dh_auto_test: dh_auto_test -- LC_CTYPE=C.UTF-8 Unfortunately, this is not sufficient (perhaps it is sufficient on the Debian buildds, but not on the Ubuntu buildds). On Ubuntu, this needs to be changed to: override_dh_auto_test: dh_auto_test -- LC_ALL=C.UTF-8 With this change, all tests pass, and the package builds successfully on Ubuntu raring i386 and amd64. I'll also submit this fix upstream to Debian BTS. (I'll submit a merge proposal for raring-proposed, but I'm open minded about whether it's worth an Ubuntu-versioned package for a one-line change to debian/rules.) ** Affects: libsvn-web-perl (Ubuntu) Importance: Undecided Status: New ** Tags: ftbfs -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1106378 Title: FTBFS: encoding issue in manual override of dh_auto_test To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsvn-web-perl/+bug/1106378/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1106378] Re: FTBFS: encoding issue in manual override of dh_auto_test
** Bug watch added: Debian Bug tracker #699062 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699062 ** Also affects: libsvn-web-perl (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699062 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1106378 Title: FTBFS: encoding issue in manual override of dh_auto_test To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsvn-web-perl/+bug/1106378/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1106378] Re: FTBFS: encoding issue in manual override of dh_auto_test
Merge proposal at: https://code.launchpad.net/~allison/ubuntu/raring /libsvn-web-perl/fix-for-1106378/+merge/145072 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1106378 Title: FTBFS: encoding issue in manual override of dh_auto_test To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsvn-web-perl/+bug/1106378/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 659332] Re: New version bump request for Password Gorilla
This update needs to be done upstream in Debian. Ubuntu will sync the updated package. ** Bug watch added: Debian Bug tracker #698665 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698665 ** Also affects: password-gorilla (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698665 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/659332 Title: New version bump request for Password Gorilla To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/password-gorilla/+bug/659332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 539832] Re: Password Gorilla doesn't allow text entry after opening password safe
This bug applies to an old version of the package. I have thoroughly tested it in daily use over many months, and cannot duplicate the bug. ** Changed in: password-gorilla (Ubuntu) Status: Confirmed = Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/539832 Title: Password Gorilla doesn't allow text entry after opening password safe To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/password-gorilla/+bug/539832/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1012619] Re: Crashes with group name can not be empty
Do you know if the pwsafe file was v3 format? Debian has a nearly identical bug report. ** Bug watch added: Debian Bug tracker #522275 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522275 ** Also affects: password-gorilla (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522275 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1012619 Title: Crashes with group name can not be empty To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/password-gorilla/+bug/1012619/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Ubuntu and derivatives (Re: Ubuntu.com Download Page)
On 01/25/2013 02:38 PM, Scott Kitterman wrote: Ubuntu.com is an element of Canonical marketing. Don't be confused into thinking it's more than that. Each flavor has a dedicated landing page: kubuntu.org, edubuntu.org, xubuntu.org, ubuntustudio.org, mythbuntu.org, lubuntu.net. The one for *U*buntu (with *U* for Unity is ubuntu.com. The centralized page for the Ubuntu *Project* is wiki.ubuntu.com. This seems right to me, as it's open for collaborative ownership by all flavors, all members. It'd be quite appropriate to add a prominent link from the main page of the wiki to: https://wiki.ubuntu.com/DerivativeTeam/Derivatives Allison -- 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 and derivatives (Re: Ubuntu.com Download Page)
On 01/25/2013 03:17 PM, Jordon Bedwell wrote: On Fri, Jan 25, 2013 at 5:13 PM, Allison Randal alli...@ubuntu.com wrote: On 01/25/2013 02:38 PM, Scott Kitterman wrote: Each flavor has a dedicated landing page: kubuntu.org, edubuntu.org, xubuntu.org, ubuntustudio.org, mythbuntu.org, lubuntu.net. The one for *U*buntu (with *U* for Unity is ubuntu.com. By that flawed and short-sighted logic how do you explain Ubuntu with a G for GNOME up until a couple of years ago? That was meant to be *U* for Unity ;), but the winky got lost when I had to manually retrieve/resend the message. (Mailman isn't as smart as Launchpad about figuring out messages sent from one of many different aliases.) The fact is, Ubuntu is the name of two distinct things: a project encompassing many flavors, and one of those flavors. Recognizing which one you're talking about at any given moment helps immensely. Allison -- 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
[Bug 819145] Re: Update gpsdrive to 2.11
The update to 2.11 should be done upstream in Debian. The Ubuntu- specific changes have mostly been merged into Debian, it's likely we'll be able to sync the package after Debian updates to 2.11. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/819145 Title: Update gpsdrive to 2.11 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpsdrive/+bug/819145/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1099027] [NEW] Please merge gnumeric 1.12.0-1 (universe) from Debian unstable
Public bug reported: I've attached a debdiff for a traditional merge of gnumeric, since it is not up-to-date in the UDD branches due to an import failure. It had to be manually merged because of a conflict in the Build-Depends lines of debian/control (all trivial, some entries on different lines, and some version updates to dependencies for gnumeric 1.12.0). This is a desirable version update from Debian, since it moves the package from gtk2 to gtk3. However, it is currently blocked by the goffice package, which also requires a manual merge from Debian to get version 0.10.0-1. (Version 1.12.0 of gnumeric requires libgoffice-0.10-dev = 0.10.0, but the current version in raring is libgoffice-0.8-dev at 0.8.17.) Also note that gnumeric gnumeric_1.12.0-1 is not built for all architectures yet on Debian. This merge drops one Ubuntu patch, a manual call to intltool-update, as it was causing a build failure, apparently conflicting with the new use of dh_autotools-dev_updateconfig in the Debian packages. That leaves only one Ubuntu-specific change in the attached debdiff. ** Affects: gnumeric (Ubuntu) Importance: Undecided Status: New ** Patch added: gnumeric_1.12.0-1ubuntu1.debdiff https://bugs.launchpad.net/bugs/1099027/+attachment/3481616/+files/gnumeric_1.12.0-1ubuntu1.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099027 Title: Please merge gnumeric 1.12.0-1 (universe) from Debian unstable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnumeric/+bug/1099027/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Uploading Forks of Ubuntu Packages to Extras
I believe this was an honest mistake. If you follow the discussion on the ARB list, starting at: https://lists.ubuntu.com/archives/app-review-board/2012-November/002569.html The intention was that the patched version of lintian (currently in Debian experimental) would be uploaded to the ~ubuntu-app-review-contributors PPA, which does *not* get copied to the extras archive. Instead, it was accidentally uploaded to the ~app-review-board PPA, which is automatically launched into extras. This is a violation of ARB policy, and needs to be fixed. So, how do we undo it? Allison On 12/28/2012 09:37 AM, Scott Kitterman wrote: The existence of http://extras.ubuntu.com/ubuntu/pool/main/l/lintian/lintian_2.5.11ubuntu12.10.1.dsc was recently mentioned #ubuntu-devel. This seems to be in direct contradiction of https://wiki.ubuntu.com/AppReviewBoard/Review/Guidelines - in particular Apps should not be forks or updates of existing applications in the Ubuntu archive (main/universe/etc). . Who was this discussed with outside the ARB before it was uploaded? As it stands, lintian will be upgraded to this version in any quantal system where extras has not been disabled, so it has potential to affect developers that have no relation to extras or the ARB. Scott K -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Uploading Forks of Ubuntu Packages to Extras
CC'ing Niels for coordination with Debian. On 12/28/2012 10:02 AM, Stéphane Graber wrote: The package has now been removed from the archive and should disappear from the mirror pretty soon. The problem is with people who already upgraded to it as it's been reported to causing breaks of at least lintian4python. Once we're sure the package is completely gone from the extras.ubuntu.com mirrors, we should issue an e-mail to ubuntu-devel-announce (at Scott's suggestion), telling people to downgrade to the archive version using apt-get install lintian/quantal-updates. We'll also need to ensure that raring will have an higher version number by release time. The version uploaded to extras was: 2.5.11ubuntu12.10.1 Is that what was uploaded? It should have been -0extras12.10.1 rather than ubuntuanything (this was designed by the TB as a safety precaution, so Ubuntu/Debian packages of the same upstream version would always have precedence over extras packages). So, a further bug, but probably because the package was never intended to actually be released to extras. The version currently in quantal-updates: 2.5.10.2ubuntu2.1 The version currently in raring: 2.5.10.2ubuntu3 The version currently in raring-proposed: 2.5.11ubuntu1 Because of the version number, we'll need to upload something to raring that's = 2.5.11ubuntu12 or we won't have a clean upgrade path from 12.10 to 13.04. Obviously meant = 2.5.11ubuntu13 (to keep a somewhat clean version number) Niels, what are the chances that the experimental version of the package with additional lintian checks will make it into Debian unstable in the next few months (after resolving the problems with lintian4python)? Will we be looking at a 2.5.12 version of lintian? Allison -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Fwd: Chef-server
On 12/21/2012 11:45 AM, John Moser wrote: Packages and source tarballs appear available from this location: http://apt.opscode.com/pool/main/ Potentially these are appropriate for multiverse, if the Chef developers are willing to submit them. Some packages in Debian have DFSG designation, so I assume some modifications are necessary for inclusion of Chef in Universe or Main. I am simply at a loss as to why some packages have been brought over, yet others have not. Perhaps the client is simply more open and thus easier to import by policy, and so the bits needed to interact with a server are brought in functionally but the bits needed to run a server are left out. That would at least be a valuable effort and explain the current state of things. But that is simply speculation on my part. Chef has never been terribly interested in supporting distro packaging. Last I checked, their custom apt repository heavily modifies some core packages (outside the chef package namespace) in ways that could never be accepted into Debian/Ubuntu. They treat it as an appliance, not as independent packages. I asked OpsCode about this a few months ago when I was doing a Chef/Puppet assessment for a client, and they didn't seem to have any interest in normalizing their packages into something distributable. Allison -- 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
UDS-R Architecture Preview
Upcoming highlights for this week in Copenhagen: http://allisonrandal.com/2012/10/28/uds-r-architecture-preview/ Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Future Releases
I'm sorry to hear this, Kate. You have done an amazing job, and it's been an honor to work with you in this role. On the wider scale of Ubuntu culture/politics, the change could turn out to be a good thing. In many open source projects with corporate sponsors, the Release Manager is a role appointed through community governance processes. In recent years there has been some (entirely understandable) tension caused by a role that is so central to the entire Ubuntu Project being appointed through the Canonical hiring process. Some very practical questions I'm sure will be discussed at UDS: - Who will run the weekly project-wide release meeting? - How will the flavors coordinate their releases and release needs? - What will the process be for keeping on top of release critical bugs and ensuring they don't slip through the cracks of somebody else's problem? Canonical can eliminate the employment position, and distribute internal release-related work, but there are still a number of functions within the Ubuntu Project that will need to be served by someone. Logically this work falls to the Release Team, and it will be largely up to you all to decide how you want to distribute it (with guidance from additional members of the TB who aren't already on the Release Team, if you want it), and whether to recognize some form of coordination role or roles in the team with responsibility for various pieces. Allison On 10/12/2012 06:53 AM, Kate Stewart wrote: Dear Release Team members and Ubuntu Flavor leads, Evolution and organic changes across Canonical have resulted in headcount consolidation such that there will be no dedicated Release Manager role going forward. I am proud to be a member of the Ubuntu community and the best release team around, and intend to remain so for the foreseeable future. I will be in my current role with Canonical until 28 October and will continue to work with you to complete the 12.10 release. My plans for UDS at this time are still emerging, at a minimum I look forward to participating remotely in the usual 12.10 feedback session during UDS and as many other sessions as possible. Thank you for your support throughout my time at Canonical and for your help during this transition. Kind regards, Kate -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Application Review Board Election Poll
I've sent out an election poll to Ubuntu Developers for newly nominated and returning members of the Application Review Board. The poll will close on Monday, Oct 15th. If you didn't receive a poll request email and should have, let me know. We still have a few more open seats, so we're also running a second round of nominations through the week of UDS (often a good place to find new recruits). Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: 12.10 Unity updates
On 09/20/2012 06:02 AM, Oliver Ries wrote: Hi Everyone, my name is Olli Ries (olli on IRC) and I am a Director of Technology at Canonical, responsible for most of the Canonical client upstream projects such as Unity and web apps. In addition to a long overdue introduction of myself I also wanted to share some updates for 12.10 that my teams have been working on. [...] Naturally, if you have any further questions, please let me know. I am looking forward to working closer with you. Thanks, Olli, this level of detail is really helpful. Welcome to ubuntu-devel. :) Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Description changed: (Tracking some collaborative work with persia) A review of RC bugs from Debian shows 4 CVEs fixed in the latest Debian release. This includes 2 CVEs fixed in an upstream (bug-fix level) - release, and 2 fixed in Debian. Currently verifying that a merge is - clean and minimal, for a possible FFe. + release, and 2 fixed in Debian. Update: this Debian release has now been + merged to quantal, see LP: #1022360 Applying these fixes to Precise SRU would require cherrypicking. - Unknown if these CVEs affect earlier Ubuntu releases also. + All CVEs affect only 1.8.x series of asterisk, so no work is needed for + releases earlier than precise. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to asterisk in Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Bug watch added: Debian Bug tracker #680470 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680470 ** Also affects: asterisk (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680470 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to asterisk in Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Description changed: (Tracking some collaborative work with persia) A review of RC bugs from Debian shows 4 CVEs fixed in the latest Debian release. This includes 2 CVEs fixed in an upstream (bug-fix level) release, and 2 fixed in Debian. Update: this Debian release has now been merged to quantal, see LP: #1022360 - Applying these fixes to Precise SRU would require cherrypicking. + The patch for AST-2012-012 (CVE-2012-4737) from Debian 1:1.8.13.1~dfsg-1 + does not apply cleanly to precise package 1:1.8.10.1~dfsg-1ubuntu1. The + patch modifies code already changed by AST-2012-004 and other merged + changes from upstream 1.4 and 1.6 series (see r314628, r363141, + r364841). The change is too disruptive for inclusion in precise SRU, and + severity is only rated as Minor. - All CVEs affect only 1.8.x series of asterisk, so no work is needed for - releases earlier than precise. + + Fixes for the other 3 CVEs have been cherrypicked to precise asterisk package: + + [Impact] + DoS exploits for voice mail and re-invite transactions, ACL bypass for IAX2 peer calls. + + [Test Cases] + Steps to reproduce each issue provided in upstream bug reports: + https://issues.asterisk.org/jira/browse/ASTERISK-19992 + https://issues.asterisk.org/jira/browse/ASTERISK-20052 + https://issues.asterisk.org/jira/browse/ASTERISK-20186 + + Testers will need to install both 'asterisk' and 'asterisk-voicemail' + packages. A simple asterisk configuration is attached to the bug report. + + [Regression Potential] + Minimal, no known regressions in asterisk issue tracker or Debian BTS. + + + Also recommend 1:1.8.13.1~dfsg-1ubuntu1 for possible precise Backport (from quantal). It includes some feature additions and many non-critical fixes (too many to SRU the whole package), sufficient for some users to prefer the more recent version. + + It is unlikely that cherrypicked patches for precise will apply cleanly + to oneiric, given the code drift between 1.8.4 and 1.8.10. All CVEs + affect only 1.8.x series of asterisk, so no work is needed for releases + earlier than oneiric. ** Attachment added: Simplistic Asterisk config for SRU testers https://bugs.launchpad.net/debian/+source/asterisk/+bug/1048093/+attachment/3304538/+files/simple_asterisk_config.txt -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to asterisk in Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
Yes, jtaylor made the quantal release last night. I've linked in a branch with an SRU candidate for precise. Nominated for precise. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to asterisk in Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Description changed: (Tracking some collaborative work with persia) A review of RC bugs from Debian shows 4 CVEs fixed in the latest Debian release. This includes 2 CVEs fixed in an upstream (bug-fix level) - release, and 2 fixed in Debian. Currently verifying that a merge is - clean and minimal, for a possible FFe. + release, and 2 fixed in Debian. Update: this Debian release has now been + merged to quantal, see LP: #1022360 Applying these fixes to Precise SRU would require cherrypicking. - Unknown if these CVEs affect earlier Ubuntu releases also. + All CVEs affect only 1.8.x series of asterisk, so no work is needed for + releases earlier than precise. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Bug watch added: Debian Bug tracker #680470 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680470 ** Also affects: asterisk (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680470 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Description changed: (Tracking some collaborative work with persia) A review of RC bugs from Debian shows 4 CVEs fixed in the latest Debian release. This includes 2 CVEs fixed in an upstream (bug-fix level) release, and 2 fixed in Debian. Update: this Debian release has now been merged to quantal, see LP: #1022360 - Applying these fixes to Precise SRU would require cherrypicking. + The patch for AST-2012-012 (CVE-2012-4737) from Debian 1:1.8.13.1~dfsg-1 + does not apply cleanly to precise package 1:1.8.10.1~dfsg-1ubuntu1. The + patch modifies code already changed by AST-2012-004 and other merged + changes from upstream 1.4 and 1.6 series (see r314628, r363141, + r364841). The change is too disruptive for inclusion in precise SRU, and + severity is only rated as Minor. - All CVEs affect only 1.8.x series of asterisk, so no work is needed for - releases earlier than precise. + + Fixes for the other 3 CVEs have been cherrypicked to precise asterisk package: + + [Impact] + DoS exploits for voice mail and re-invite transactions, ACL bypass for IAX2 peer calls. + + [Test Cases] + Steps to reproduce each issue provided in upstream bug reports: + https://issues.asterisk.org/jira/browse/ASTERISK-19992 + https://issues.asterisk.org/jira/browse/ASTERISK-20052 + https://issues.asterisk.org/jira/browse/ASTERISK-20186 + + Testers will need to install both 'asterisk' and 'asterisk-voicemail' + packages. A simple asterisk configuration is attached to the bug report. + + [Regression Potential] + Minimal, no known regressions in asterisk issue tracker or Debian BTS. + + + Also recommend 1:1.8.13.1~dfsg-1ubuntu1 for possible precise Backport (from quantal). It includes some feature additions and many non-critical fixes (too many to SRU the whole package), sufficient for some users to prefer the more recent version. + + It is unlikely that cherrypicked patches for precise will apply cleanly + to oneiric, given the code drift between 1.8.4 and 1.8.10. All CVEs + affect only 1.8.x series of asterisk, so no work is needed for releases + earlier than oneiric. ** Attachment added: Simplistic Asterisk config for SRU testers https://bugs.launchpad.net/debian/+source/asterisk/+bug/1048093/+attachment/3304538/+files/simple_asterisk_config.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
Yes, jtaylor made the quantal release last night. I've linked in a branch with an SRU candidate for precise. Nominated for precise. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1048093] [NEW] Outstanding security fixes in asterisk
Public bug reported: Reviewing RC bugs from Debian shows 2 CVEs fixed in upstream bug-fix release 1.8.13.1, and 2 additional CVEs fixed in latest Debian release. ** Affects: asterisk (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to asterisk in Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2012-3863 ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2012-2186 ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2012-4737 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to asterisk in Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Description changed: - Reviewing RC bugs from Debian shows 2 CVEs fixed in upstream bug-fix - release 1.8.13.1, and 2 additional CVEs fixed in latest Debian release. + (Tracking some collaborative work with persia) + + A review of RC bugs from Debian shows 4 CVEs fixed in the latest Debian + release. This includes 2 CVEs fixed in an upstream (bug-fix level) + release, and 2 fixed in Debian. Currently verifying that a merge is + clean and minimal, for a possible FFe. + + Applying these fixes to Precise SRU would require cherrypicking. + + Unknown if these CVEs affect earlier Ubuntu releases also. ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2012-3812 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to asterisk in Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1048093] [NEW] Outstanding security fixes in asterisk
Public bug reported: Reviewing RC bugs from Debian shows 2 CVEs fixed in upstream bug-fix release 1.8.13.1, and 2 additional CVEs fixed in latest Debian release. ** Affects: asterisk (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2012-3863 ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2012-2186 ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2012-4737 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Description changed: - Reviewing RC bugs from Debian shows 2 CVEs fixed in upstream bug-fix - release 1.8.13.1, and 2 additional CVEs fixed in latest Debian release. + (Tracking some collaborative work with persia) + + A review of RC bugs from Debian shows 4 CVEs fixed in the latest Debian + release. This includes 2 CVEs fixed in an upstream (bug-fix level) + release, and 2 fixed in Debian. Currently verifying that a merge is + clean and minimal, for a possible FFe. + + Applying these fixes to Precise SRU would require cherrypicking. + + Unknown if these CVEs affect earlier Ubuntu releases also. ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2012-3812 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Proposing a New App Developer Upload Process
On 09/04/2012 10:02 AM, Emmet Hikory wrote: The above notwithstanding, I'm all in favour of being able to safely add new or frequently changing packages with policy-compliant filenames to Ubuntu, both during the life of a release and as part of future releases. I'm just concerned that our attempts to work around some of the problems we have had with such systems in the past may lead to us creating new systems that closely parallel older systems without addressing the issues that caused the prior systems to no longer be considered ideal for future progress. Given my experience with cleanup after the pull of all the random apt repos, and work with REVU, I feel fairly strongly that we ought create an implementation that closely integrates with exsting Debian tools and avoids as many potential sources of conflict as possible. If we are to have a high-throughput mostly automated mechanism for new packages to be added, we need to be sure that we have not created too many bottlenecks relying on human discussion, whether this be too high a reviewer overhead, a need to coordinate yet another namespace conflict resolution forum, or anything else. Based on this belief, while we might have any arbitrary process by which applications are submitted for review, the only reason I can see for treating the packages as any different than any other unseeded package is either some technical limitation or if we somehow felt that we had different levels of trust for packages in one place or another (as reflected by our trust in the reviewers, presumably). The more effort we spend to create a special and different class of applications, the greater the chance we have created a division in the self-perceived identities of our various developers where none need exist. Of course, this may not be considered safe (see all the sandboxing discussion in the spec), but I believe we'd do better to help those who are developing applications follow a model that generates software that we would be happy to welcome as regular system software than to encourage those who might need greater system access to find ways to work around whatever limitations we might attempt to put in place. If we can use the same front-end to the application developers for *both* types of applications, we reduce both confusion and dissention, and likely find that our implementation need have fewer loopholes, as there is a means to easily move software from the restricted facility to a more regular facility, with full filesytem access, no network restrictions, etc. which we may use whenever we find a package that might otherwise require an extension to the facilities available. Well said! Here's my perspective, in short form: - Extras is PPU + Backports + training wheels. - Extras is a place to experiment with how the training wheels should work, without disrupting the main archives. - Eventually Extras should go away, once we've extracted the best value from the experiment. The proposal that started this thread is rather lengthy, and contains 2-3 years worth of work on tooling. It's a valuable seed for discussion, but really too much to digest all at once. I'd like to focus on what to do in the next Ubuntu release cycle. Partly because each cycle *is* a fresh experiment for Extras. What we've learned in previous cycles has radically changed the plan already, and is sure to do so in the future. And partly because we may not agree right now on the ultimate future (some won't agree with me that Extras should go away, others won't agree with me that it should stick around for a little while longer), but I'm confident that we *can* agree on what the immediate next steps should be. These are what I consider to be the most crucial immediate questions: - Should we change Extras operation so it's less like REVU (approving each package) and more like PPU (approving a particular developer for a particular package name)? - Should the DMB be made responsible for approving those Extras PPU rights? - Should we remove the /opt install requirement? - Should we start developing tooling for more automated package checking/sandboxing? My vote is: Yes, make it more like a PPU. I see advantages to recruiting the DMB for approvals, but they may not want the extra work. No, we shouldn't remove the /opt requirement, at least not yet. Maybe later when we have more advanced tools. And heck yeah!, we should start working on the tools. We can keep doing manual reviews until the tools are good enough that we trust them. (And will always make the tools kick back to manual review for anything they can't handle.) My ideal future looks something like: Debian and Ubuntu co-habiting on DebExpo (either on mentors.debian.net, or two sites with federated data), with a slick UI, and fantastic integrated tools for automated package checks. But, there's a lot of development work between here and there, I can't just snap my fingers and
Re: Proposing a New App Developer Upload Process
On 09/05/2012 10:12 AM, David Planella wrote: Al 05/09/12 17:49, En/na Allison Randal ha escrit: - Extras is a place to experiment with how the training wheels should work, without disrupting the main archives. - Eventually Extras should go away, once we've extracted the best value from the experiment. That said, there is one part where I disagree: in considering Extras (if we identify Extras with the App Developer Process) an experiment or training ground for Ubuntu platform development, for which we already have a process in place. I consider the App Developer Process simply a way to enable application authors to seamlessly and securely publish their apps. Human review and packaging policies have proven to be the main bottlenecks for this happening, and these (plus security) are the main points the proposal is trying to address. Oh, yeah, I'm not saying we should chuck out App Developers. What I'm saying is that if they have unique needs, over the long-term we need to address those needs as part of the overall Ubuntu Developer strategy, and not segregated off to the side. Similarly, if it turns out that some type of lighter PPU rights with required sandboxing are valuable, then maybe they belong in the wider Ubuntu Developer context too. (Last I checked, the DMB was considering some kind of PPU without Membership, which is another sort of lighter rights.) I wouldn't say we've proven either idea yet. All Extras has really proven so far is that packaging and reviewing packages is hard work, even for simple apps. And, we pushed it farther than REVU, because we did several rapid iterations on interfaces/tooling for manual reviews, and still found it was way too much work and couldn't scale to handle a rapid influx. That's a valuable lesson, and worth the experience. I am really interested in the potential for automated sandboxing, and right now Extras is the best place to experiment with it. And, if it works well, then it could very well benefit other parts of Ubuntu, or Debian, or any Debian-based distro. (I don't imagine the tools will be general enough to handle other package formats. Not a requirement.) Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
call for new ARB members
It's time for a recruiting round for the Application Review Board, as the terms of several of the original members will come to an end on Sept 13th. If you're interested, please send a quick email to the team mailing list (app-review-bo...@lists.ubuntu.com) by Sept 5th, and we'll walk you through the details of signing up. You need to be an Ubuntu Developer to qualify, and will need an endorsement from at least one other Ubuntu Developer. You'll find more details on what it means to be an ARB member and the process of adding new members to the team at: https://wiki.ubuntu.com/AppReviewBoard/Responsibilities https://wiki.ubuntu.com/AppReviewBoard/Restaffing Full disclosure: we're currently wading our way through a backlog of ~200 package submissions from the recent wildly successful Ubuntu App Showdown. You can see the full list at: https://myapps.developer.ubuntu.com/dev/arb/ There's substantial interest in automating as much of the review process as possible, so beyond general packaging skills and an interest in training new developers, ideal candidates would have some interest/experience in things like creating new lintian checks, generating apparmor profiles, or otherwise improving the tools to assist package reviews. Experience in MOTU, Core Dev, Archive Admin, Backports, DMB, or Debian Developer/Maintainer would be considered a plus, but not required. Let us know if you have any questions, Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 1021401] Re: package scratch 1.1-0~r766+pkg21~precise1 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 2
You seem to have an older scratch package installed (possibly from the earlier PPA?), as the error message refers to scratch 1.1-0~r766+pkg21~precise1 Try uninstalling the scratch package entirely, and then reinstalling it. sudo apt-get remove scratch sudo apt-get install scratch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1021401 Title: package scratch 1.1-0~r766+pkg21~precise1 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/scratch/+bug/1021401/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 903843] Re: pyglet apps appear as panel in the Launcher
** Tags added: arb -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/903843 Title: pyglet apps appear as panel in the Launcher To manage notifications about this bug go to: https://bugs.launchpad.net/bamf/+bug/903843/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Default layout of the GNOME Classic session
On 04/21/2012 02:51 PM, Benjamin Drung wrote: The GNOME Classic session uses gnome-panel, but not GNOME Shell. Sure, that's the GNOME 3 fallback for running without Mutter. It makes sense for Classic to have minimal dependencies. I'd go for an argument that maybe Classic isn't the best name when GNOME has also changed radically, and isn't as classic as people might expect. But on technical, philosophical, economic, and practical grounds, it's better for us to work with the GNOME developers on any improvements, and not tweak them directly into the Ubuntu packages. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Default layout of the GNOME Classic session
On 04/21/2012 03:33 PM, Benjamin Drung wrote: Ubuntu Classic would be a better name for the session, because it looks more like a GNOME 2 environment from Ubuntu than like an untouched GNOME environment. The GNOME Classic session uses the indicators and the notify-osd from Ubuntu. There's a distinction here between essential functional changes to allow GNOME Panel to integrate with applications and system internals on Ubuntu, and appearance changes to make it look more like GNOME 2. I'm in favor of the first, and not the second. But, I've said enough, time for others to comment. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 735601] Re: [STAGING] Scheduling while atomic: swapper/0/0x00000100; RIP: 0010:[ffffffff813354ca] [ffffffff813354ca] intel_idle+0xca/0x120
I'm still running that netbook with intel_idle.max_cstate=0 in GRUB_CMDLINE_LINUX_DEFAULT. I'll remove that, and run through the tests you requested. I can at least say the netbook has been working fine through upgrades to Natty, Oneiric, and Precise for months now with intel_idle.max_cstate=0 enabled. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/735601 Title: [STAGING] Scheduling while atomic: swapper/0/0x0100; RIP: 0010:[813354ca] [813354ca] intel_idle+0xca/0x120 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/735601/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 935525] Re: libglib-perl version 2:1.241-1 FTBFS on i386 in precise
This is a heisenbug because it's a simple race condition. It's not a
failure in the package build, only in the automated tests. The lines
just before 267 of the test file t/9.t are:
264 $timer_id = Glib::Timeout-add
265 (30_000, # 30 seconds should be more than enough for child exit
266 sub { die Oops, child watch callback didn't run\n; });
The test is assuming that 30 seconds are long enough for a child process
to complete, but on certain slower/constrained processors (like a
buildd, or a netbook) that estimate is too short, so the test fails. On
my Precise netbook (Asus EeePC N550 @ 1.50GHz × 4) the test consistently
fails, but if I bump that timeout up to 60 seconds it consistently
passes. That timing is not exact, and an ideal fix would be event-based
rather than wallclock seconds, but doubling the time allowed is
generous. Alternatively, you can ignore the FTBFS, since it's only a
sign of a slow buildd, not of any more serious problem.
I've attached the patch file I added in my bzr checkout of the package
for a longer timeout.
** Attachment added: lengthen the timeout, so the test passes for slower
processors
https://bugs.launchpad.net/ubuntu/precise/+source/libglib-perl/+bug/935525/+attachment/2913794/+files/fix-timeout
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/935525
Title:
libglib-perl version 2:1.241-1 FTBFS on i386 in precise
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libglib-perl/+bug/935525/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 946539] [NEW] gnome-session removed during partial upgrade to Precise Beta1
Public bug reported: During a partial upgrade to Precise Beta1 last night, update-manager removed a large number of packages, including gnome-session. The machine would boot to the login screen, but logging in (with the correct password) would simply return to the login screen again with no error message. The login screen also gave no options for different sessions (Ubuntu, Ubuntu 2D, etc). ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: update-manager 1:0.156.6 ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6 Uname: Linux 3.2.0-17-generic x86_64 NonfreeKernelModules: wl ApportVersion: 1.94-0ubuntu1 Architecture: amd64 Date: Sun Mar 4 10:24:46 2012 GsettingsChanges: com.ubuntu.update-manager first-run false com.ubuntu.update-manager launch-time 1330885434 com.ubuntu.update-manager show-details true com.ubuntu.update-manager window-height 546 com.ubuntu.update-manager window-width 600 InstallationMedia: Ubuntu 10.10 Maverick Meerkat - Release amd64 (20101007) PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: update-manager UpgradeStatus: Upgraded to precise on 2012-03-04 (0 days ago) ** Affects: update-manager (Ubuntu) Importance: High Status: New ** Tags: amd64 apport-bug dist-upgrade precise -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/946539 Title: gnome-session removed during partial upgrade to Precise Beta1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946539/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 946539] Re: gnome-session removed during partial upgrade to Precise Beta1
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/946539 Title: gnome-session removed during partial upgrade to Precise Beta1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/946539/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 903843] [NEW] pyglet apps appear as panel in the Launcher
Public bug reported: All pyglet apps appear in the Launcher as if the app name is panel, and the Launcher shows multiple windows for the app, even though there is only one window. I've attached a screenshot of the Launcher. You can duplicate the problem simply by installing the python-pyglet package and then running: $ python from pyglet import window window.Window() Clicking on the Launcher also takes you to the choose between the windows spread, but with only one window in the spread. I'm guessing this is bamf-related. ** Affects: pyglet (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/903843 Title: pyglet apps appear as panel in the Launcher To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pyglet/+bug/903843/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 903843] Re: pyglet apps appear as panel in the Launcher
** Attachment added: screenshot of Launcher with pyglet app https://bugs.launchpad.net/bugs/903843/+attachment/2631589/+files/pyglet-launcher.png -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/903843 Title: pyglet apps appear as panel in the Launcher To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pyglet/+bug/903843/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Proposal to delay release of Precise Pangolin
On 12/13/2011 12:11 AM, James Freer wrote: After reading the following posts i wanted to raise the release issue. It seems that staff are under a lot of pressure to deliver the 6 month releases as well as LTS. I've been using Ubuntu for about 5 yrs and it seems that quality varies between releases likely due to the pressure staff are under. Would it not be better for all to produce an annual version that's allowed time for testing and bug fixing. LTS is ok but second year and one is starting to find quite a few apps that have been updated and a six month release simply doesn't give adequate time for staff. If you're wondering what i do... i'm an april updater A release cycle that's twice as long doesn't really give you more time to test changes, it just gives you twice as many changes to test. And it makes some kinds of changes much more difficult, because they need to be staged over multiple releases for a smooth transition. Here's a good post (short): http://jroller.com/thuss/entry/there_are_pros_and_cons But if you have time, I recommend reading Martin Michlmayr's full Doctoral dissertation. http://www.cyrius.com/publications/michlmayr-phd.html From the conclusion: == In contrast to traditional software development which is feature-driven, the goal of time based release management is to produce high quality releases according to a specific release interval. This dissertation has shown that feature based release management in FOSS projects is often associated with lack of planning, which leads to problems, such as delays and low levels of quality. [...] Time based releases are associated with two factors that act as important coordination mechanisms: 1. Regularity: the production of releases according to a specific interval allows projects to create regular reference points which show contributors what kind of changes other members of the project have made. Regularity also contributes to familiarity with the release process, and it leads to more disciplined processes. 2. Schedules: by using time rather than features as the orientation for a release, planning becomes possible in voluntary projects. Time based projects can create schedules which describes important deadlines and which contains dependency information between different work items and actors. Together, these mechanism reduce the degree of active coordination required in a project. Developers can work on self-assigned work items independently and with the help of the schedule integrate them into the project in time for the release. As such, the time based release strategy is a means of dealing with the complexity found in geographically distributed volunteer projects with hundreds of contributors. == Allison -- 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: REVU, #ubuntu-packaging, and mentors.debian.org
On 12/10/2011 11:41 AM, Scott Ritchie wrote: If you're going to leave REVU up, you need to make it very clear that it's neglected within the REVU submission interface itself. The notices up on the website help, but the actual submission interface for REVU is dput. The revu-hackers may have ideas on how much leeway we've got to hook extra actions into a dput upload. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: REVU, #ubuntu-packaging, and mentors.debian.org
On 11/14/2011 08:43 AM, Daniel Holbach wrote: If that's the general concensus, maybe we should also add a piece of text on REVU itself? The other pages I know that would need updating would be https://wiki.ubuntu.com/MOTU/Packages/REVU and https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages I've edited these two pages, and submitted a merge request for a small notice at the top of each page of revu.ubuntuwire.com (already merged, thanks rainct!). Any others? Also edited, but a few pages look like they're no longer used: https://wiki.ubuntu.com/UbuntuDevelopment/Uploading https://wiki.ubuntu.com/MOTU/Leaders https://wiki.ubuntu.com/MOTU/Contributing https://wiki.ubuntu.com/MOTU/Events https://wiki.ubuntu.com/MOTU/Headers/Dates https://wiki.ubuntu.com/Ubuntu/ForDebianDevelopers https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers https://wiki.ubuntu.com/SponsorshipProcess https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive https://wiki.ubuntu.com/MOTU/New https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue https://wiki.ubuntu.com/DeveloperDocumentation Probably should be edited: https://wiki.ubuntu.com/Kubuntu/Header https://wiki.ubuntu.com/Packtools/InUbuntu Didn't edit, possible candidates for removal: https://wiki.ubuntu.com/REVUDays https://wiki.ubuntu.com/MOTU/Launchpad/Guide https://wiki.ubuntu.com/MOTU/School/PackagingBasics https://wiki.ubuntu.com/MOTU/Headers/NextREVUDay Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: EOL for couchdb and desktopcouch
On 11/22/2011 09:11 AM, Jo-Erlend Schinstad wrote: While I can understand the reasons why you feel it necessary to pull the plug on the db sync service, it is not immediately obvious to me why that would necessarily result in you dropping support for local storage in personal databases on the desktop. I don't see anything wrong with DesktopCouch itself. So, it sounds like you might be interested in adopting maintenance of desktopcouch? This is a pretty standard practice in free software, Debian even has an official process for it (Packages up for adoption). You've got a vision for where to take it next, so if you have time and interest, it could be a perfect match. Allison -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Bug 786516] Re: pyglet error: No standard config is available.
python-pyglet_1.1.4.dfsg-2 shipped in Oneiric, this is now fixed. If you need the newer version of pyglet in older releases, please request a backport. ** Changed in: pyglet (Ubuntu) Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/786516 Title: pyglet error: No standard config is available. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pyglet/+bug/786516/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 381154] Re: Any pyglet program causes a segmentation fault.
This is not an issue in Oneiric, which ships version 1.1.4.dfsg-2. If you need the newer version in an older release, please request a backport. ** Changed in: pyglet (Ubuntu) Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/381154 Title: Any pyglet program causes a segmentation fault. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pyglet/+bug/381154/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: REVU, #ubuntu-packaging, and mentors.debian.org
Am 14.11.2011 00:47, schrieb Scott Kitterman: A web based tool to support publishing and reviewing packages seems somewhat orthogonal to IRC channels to get help packaging. I think it's premature to shut down REVU until DEBEXPO is a full replacement (the most critical thing for me it was missing last I checked was the ability to give diffs of subsequent uploads of a package with the same version/revision. This was my position before UDS, and I'm still okay with it if it's the general consensus of the group. On 11/14/2011 03:05 AM, Daniel Holbach wrote: While it would be nice for debexpo to have a similar feature, it seems more worrying to me that we still advertise a process that is broken and we set wrong expectations. And this is what changed my mind about the best way to make the transition. I don't remember who mentioned it in the session, but there was a pretty quick spread around the room of Oh, this is a really bad experience for new developers. We're trying to recruit new Ubuntu developers with a first experience of being ignored for months (or years). :( Personally I'd rather like to see REVU closed, the documentation changed and for packaging review (or general code review) any VCS be used, where you can very easily track changes in packaging, without incrementing packaging version numbers. I'll propose a compromise: how about we remove REVU from the documentation for new packagers, so we're not pointing people there first anymore. The MOTU/core-dev who are still using REVU for package reviews can keep using it, they'll just tell their mentorees to go there. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 882274] Re: Community engagement is broken
This comment is written with love. A bug report isn't the best place to work through relationship issues, but this comment thread is unhealthy enough that I don't want to leave it standing as-is. Just a brief note here, but what really matters aren't words but actions over time. The Ubuntu community (and I include Canonical as part of that community) has fallen into some unhealthy habits. We've been together for 7 years now, and over the years we've started to take each other for granted. For the community to survive, and for Ubuntu to succeed, this has to change. I was greatly encouraged by UDS-P two weeks ago. For those who didn't attend: things are changing around here, for the better. As one concrete example, we're starting up a team of volunteer designers to work on user journeys across the entire distro. The Unity designers have (joyfully, gladly, and with great enthusiasm) agreed to participate with this team, to share their knowledge and experience, and learn from the knowledge and experience of others in the group. Today, it's just the smallest seed, a tiny trajectory shift, but it's change in the right direction. I have a different message for different parts of the community. For the Unity designers, my message is come out and play, don't worry, they won't bite. And for everyone else, my message is stop biting the Unity designers, you're scaring them away from open participation and if you see someone else biting the Unity designers, gently correct them and teach them how we collaborate around here. You see, communities only work when we *all* play our part in making them work. I love the Ubuntu community in its entirety, both volunteer and paid. I'm not promising you that the next 7 years will be easy, nothing worth doing ever is easy. But I am promising this: if we work together, what we build will be absolutely amazing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/882274 Title: Community engagement is broken To manage notifications about this bug go to: https://bugs.launchpad.net/ayatana-design/+bug/882274/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
REVU, #ubuntu-packaging, and mentors.debian.org
Hi all, One of my workitems coming out of UDS is to make a proposal here on the list, based on the discussion in the session. - Last cycle, we edited the Ubuntu packaging documentation to encourage submitting new packages upstream to Debian first. All agreed that this was good for both Debian and Ubuntu. - The suggestion from the room was to close REVU now, and change the documentation to point new packagers at #ubuntu-packaging and #ubuntu-motu. It's not helpful to new developers to have a site running and all the documentation saying to submit their packages there, when they aren't going to get help there. The IRC channels are active, and a good place to get help on packaging, and to get to know the Ubuntu developers who might sponsor the new package, or advise the packager to submit it to Debian instead. - As a longer-term step, talk with the developers of DebExpo (mentors.debian.net) about some features to enable downstream derivatives like Ubuntu to work directly in what would probably be renamed to mentors.debian.org. This could be as simple as adding some new tags, but could potentially involve some more advanced handling of non-Debian source packages, or integration with external services (e.g. Ubuntu PPAs). We've been talking about this off and on for a few months on ubuntu-devel, and in many ways the conversation at UDS just summed up that wider conversation. The main mental shift is in ordering: shut down the old right away, then grow the new process. What do you all think? Thoughts, comments, or suggestions? Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 889340] [NEW] duplicate data for 'dia' package in Oneiric
Public bug reported: Searching for dia in the Software Center in Oneiric, the first two results are Diagram editor and Dia Diagram Editor. The first is installable, and has a normal set of info under More Info. The second has no Install button and gives me an error when I click More Info: -- Not found There isn't a software package called dia-gnome-gnome in your current software sources. -- Seems to be a data error, since they're both the same application, but I'm not sure where it's pulling the duplicate data from. ** Affects: software-center (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/889340 Title: duplicate data for 'dia' package in Oneiric To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/889340/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Ubuntu should move all binaries to /usr/bin/
On 11/01/2011 03:20 PM, Cosme Domínguez wrote: But it requires a lot of work that I think should start first in Debian. And, is already being discussed in Debian (lengthy thread): http://lists.debian.org/debian-devel/2011/10/msg00157.html Allison -- 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
extending desktop LTS to 5 years
Hi all, For Precise Pangolin, Canonical is planning to invest resources in support and maintenance to increase the Ubuntu desktop LTS length from 3 years to 5 years (bringing it up to the same length as the server LTS), and to offer additional updates for new hardware through the standard SRUs and point releases in the first two years of the LTS. We've been consulting with the Tech Board, members of the Release Team, and flavors to make sure that this will be a beneficial contribution to the community, and won't cause any unintended additional work. Kate and I are scheduling a session at UDS about LTS planning, and we can talk there around practical details. For example, flavors that have taken the LTS designation in the past can choose now whether to use the added support and maintenance to extend their own support cycles or stick with 3 years. So, we'll talk through the ups and downs of each. Happy to add other items to the agenda for the session, let us know. Thanks, Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Application Review Board, call for nominations
On 10/16/2011 03:23 AM, Allison Randal wrote: On 10/08/2011 09:05 AM, Allison Randal wrote: - Poll of Ubuntu Developers: Oct 15-19 This poll has been sent out now to all Ubuntu developers. If you didn't receive a poll notification and should have, let me know. In response to some questions, the ranking doesn't matter much in a 3-candidates for 3-slots vote, but what does matter is an indication of confidence in each candidate from the Ubuntu Developers. CIVS doesn't seem to have a for or against style of poll, so use No Opinion option as against. Thanks, Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Application Review Board, call for nominations
On 10/08/2011 09:05 AM, Allison Randal wrote: In order to get the new members up-to-speed in time for UDS-P, the timeline for this recruiting round is: - Open nominations: now - Oct 14 - Poll of Ubuntu Developers: Oct 15-19 This poll has been sent out now to all Ubuntu developers. If you didn't receive a poll notification and should have, let me know. And, if you've worked with a candidate, feel free to add a testimonial or comment while you're reviewing their summary wiki page. - Review of results by the TB: Oct 20 - New members announced: Oct 21 Cheers, Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Getting new packages into Ubuntu
On 10/10/2011 03:42 PM, Sebastien Bacher wrote: Le lundi 10 octobre 2011 à 10:23 -0400, Scott Kitterman a écrit : If we try to reduce the work to the available developers by reducing the scope of the archive, then we are also reducing the pool of potentially interested developers as well. It does make sense to freeze and ship a consistent archive for the system components (base system, plumbers, desktop shells, default applications), it doesn't make sense to try to make small softwares (ubuntu-tweaks, simple-lightdm-manager, etc) respect our freezes, cycle, rely on acl to upload to the main archive, etc We essentially have three classes of packages in Ubuntu: - Lightweight applications, which I would encourage to apply through developer.ubuntu.com (i.e. Extras/ARB), and we can help the developer figure out if it makes sense to release through extras, submit upstream to Debian (possibly combined with an Ubuntu backport, depending on where we are in the cycle), or submit to main/universe. - General purpose system components, large applications, and everything else that isn't specific to Ubuntu. These should submit upstream to Debian. - System components that are specific to Ubuntu. There aren't many of these, but they do exist. They only really make sense when tied to a particular release, and need the benefit of integration testing with that release, so should participate in the usual Ubuntu development cycle. It's not entirely clear what channel these should use. If it's not a large set of packages, perhaps the current practice of working through the human network of Ubuntu developers is enough. REVU isn't very actively used/developed at the moment. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Application Review Board, call for nominations
The Application Review Board is seeking to fill several empty places. With the launch of developer.ubuntu.com, the rate of submissions for the ARB to review has increased substantially, so we could really use a few more hands on deck to review packages and assist developers in improving their packages. The responsibilities of an ARB member are listed on the wiki page: https://wiki.ubuntu.com/AppReviewBoard/Responsibilities If you're interested in joining the ARB, or know someone else who might be, take a look at the application process at: https://wiki.ubuntu.com/AppReviewBoard/Restaffing Note, you must be an Ubuntu Developer in order to be considered. So far, we have 3 confirmed nominees, and one other potential nominee. In order to get the new members up-to-speed in time for UDS-P, the timeline for this recruiting round is: - Open nominations: now - Oct 14 - Poll of Ubuntu Developers: Oct 15-19 - Review of results by the TB: Oct 20 - New members announced: Oct 21 Thanks, Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Fwd: FOSDEM 2012 cross-distributions devroom
Original Message Subject: FOSDEM 2012 cross-distributions devroom Resent-Date: Wed, 28 Sep 2011 11:24:39 + (UTC) Resent-From: debian-devel-annou...@lists.debian.org Date: Wed, 28 Sep 2011 13:23:14 +0200 From: Wouter Verhelst wou...@debian.org Organization: The Debian Project, http://www.debian.org/ To: debian-devel-annou...@lists.debian.org Hi all, It's that time of the year again: FOSDEM organisation is firing up, which means I get to ask for talks again. As during the two previous years, Debian has been invited to participate in the cross-distribution devroom. This means that talks will be held in front of an audience not only consisting of people involved with Debian; instead, the expected audience will consist of people from many different distributions, as well as other people--regular FOSDEM visitors. Still, there is no reason to assume that Debian-specific talks will not be welcome. However, there won't be as much time for that as there was before FOSDEM 2010. Having said that, People interested in holding a talk at FOSDEM are hereby invited to submit a proposal. This should be done by sending a mail to the relevant mailinglist (distributi...@lists.fosdem.org, subscription required -- http://lists.fosdem.org/listinfo/distributions), containing the following information: - Title of the proposed talk, - Abstract of the talk - Name of the speaker - Bio of the speaker - Requested amount of time for the talk Thanks, and see you at FOSDEM, -- 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
[Bug 784252] Re: package backuppc 3.2.0-3ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
It is a permissions problem. The quick manual fix for this is to change the user and group of the files /var/lib/backuppc/pc and /var/lib/backuppc/cpool to 'backuppc'. I'm working on a packaging fix. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to backuppc in Ubuntu. https://bugs.launchpad.net/bugs/784252 Title: package backuppc 3.2.0-3ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/784252/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 784252] Re: package backuppc 3.2.0-3ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
It is a permissions problem. The quick manual fix for this is to change the user and group of the files /var/lib/backuppc/pc and /var/lib/backuppc/cpool to 'backuppc'. I'm working on a packaging fix. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/784252 Title: package backuppc 3.2.0-3ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/784252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Brainstorming for UDS-P
Hi all, While we're all in the final preparations for Oneiric, it's round about that time in the cycle to start thinking about plans for the next cycle. What's on your mind? Allison -- 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: Getting new packages into Ubuntu
On 09/19/2011 01:03 PM, Benjamin Drung wrote: Why not discourage REVU completely? I was looking through the lists of packages currently in REVU last week, some sitting with no action for a long time. So far, I haven't seen any packages that wouldn't have been better submitted to Debian. Now, there is an information bias here, because the package proposals that were a perfect match for direct addition to Ubuntu may have already been successfully reviewed, approved, added to the archive and the proposals closed out. The next useful data point, for any successful direct additions from REVU, is whether we managed to propose them upstream to Debian after inclusion in Ubuntu. But, I think the deeper question is whether developers here in Ubuntu, who would have been looking at the REVU queues, would be willing to spend that time reviewing the same package proposals for Debian. You don't have to be a DD or DM to do package reviews in the new mentors.debian.net. It's beneficial to direct new packages upstream, but we also need to recognize the workload we're adding to the Debian volunteers if we send all new package reviews to Debian. On my todo list for this week is talking with Asheesh and Stefano to get a sense of how successful the new mentors.debian.net is so far. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 852484] Re: Merge backuppc 3.2.1-1 (main) from Debian unstable (main)
I've pushed a merged branch of backuppc 3.2.1-1ubuntu1 to lp:~allison/ubuntu/oneiric/backuppc/bug-852484. This is only a merge of the new upstream release containing security fixes, and does not fix any other bugs. (I'm working on those in different branches.) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to backuppc in Ubuntu. https://bugs.launchpad.net/bugs/852484 Title: Merge backuppc 3.2.1-1 (main) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/852484/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 852484] Re: Merge backuppc 3.2.1-1 (main) from Debian unstable (main)
I've pushed a merged branch of backuppc 3.2.1-1ubuntu1 to lp:~allison/ubuntu/oneiric/backuppc/bug-852484. This is only a merge of the new upstream release containing security fixes, and does not fix any other bugs. (I'm working on those in different branches.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/852484 Title: Merge backuppc 3.2.1-1 (main) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/852484/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 68729] Re: Loses all backups when disk is full
We're at 3.2.0 in Oneiric. Is there any indication that this bug still exists? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to backuppc in Ubuntu. https://bugs.launchpad.net/bugs/68729 Title: Loses all backups when disk is full To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/68729/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 68729] Re: Loses all backups when disk is full
We're at 3.2.0 in Oneiric. Is there any indication that this bug still exists? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/68729 Title: Loses all backups when disk is full To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/68729/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
REVU and DebExpo
From the last UDS, persia assigned me a workitem to look into how to more strongly encourage developers with new packages to submit to Debian first. You may have seen that Debian has just switched their mentors site over to a new system, DebExpo. At DebConf, the idea came up that maybe Ubuntu could also use mentors.debian.net for new package reviews, with a custom set of tags so Ubuntu reviewers could look only at Ubuntu packages (and Debian reviewers wouldn't see Ubuntu packages by default). The idea has the advantage that when we wanted to redirect new packages to Debian, it would be a simple matter of changing the tags, rather than pushing the packager to an entirely new interface and set of requirements. There are a few features REVU has that DebExpo doesn't have yet, but the thought is that we might be able to merge some of the code from REVU into DebExpo. I talked with the most active developers of REVU, and the response was Yeah, moving to a single platform would probably be nice. Other thoughts? In addition to general comments or concerns, it would also be interesting to hear if any current users of revu.ubuntuwire.com (reviewers or submitters) have used the new mentors.debian.net, and if so what they think of it. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 828162] Re: update-manager crashed with Package [u'nspluginviewer'] isn't available in _run()
Bug #762968 appears to be related to this one. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/828162 Title: update-manager crashed with Package [u'nspluginviewer'] isn't available in _run() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/828162/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 762968] Re: package flashplugin-installer 10.2.159.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
I got it today too. Possibly a multiarch problem? The package has a Depends ia32-libs. From https://lists.ubuntu.com/archives/ubuntu- devel/2011-March/032750.html, I expected to be able to run: sudo apt-get install flashplugin-installer:i386 But that just reports: E: Unable to locate package flashplugin-installer:i386 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/762968 Title: package flashplugin-installer 10.2.159.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/762968/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 762968] Re: package flashplugin-installer 10.2.159.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
Hmmm... nspluginwrapper isn't getting updated, because of a missing dependency on nspluginviewer: The following packages have unmet dependencies: nspluginwrapper: Depends: nspluginviewer (= 1.4.4-0ubuntu3) which is a virtual package. But, there doesn't seem to be any package available to satisfy nspluginviewer allison@otp:~$ sudo aptitude install nspluginviewer No candidate version found for nspluginviewer No candidate version found for nspluginviewer It appears that nspluginwrapper binary package exists in both i386 and amd64 architectures, but nspluginviewer only exists for i386. (http://packages.ubuntu.com/da/oneiric/nspluginviewer) In Natty, nspluginviewer didn't exist at all, and nspluginwrapper had no dependency on it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/762968 Title: package flashplugin-installer 10.2.159.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/762968/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 762968] Re: package flashplugin-installer 10.2.159.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
It looks like this may be resolved when the fix for Bug #828162 is released. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/762968 Title: package flashplugin-installer 10.2.159.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/762968/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: shrinking the desktop DVD image to 1.5GB
I drafted an initial seed set for a 1.5GB image. As suggested here on the list, it's an extension of the CD image, including full language packs and additional common applications. Of the additional applications that people suggested here on the list, 4 are not included, because they're universe packages rather than main. If there's sufficient demand, we could promote some of them next cycle, but they aren't particularly critical, so not worth MIRs at this point. audacity anjuta wesnoth frozen-bubble Any suggestions on other games, developer tools, audio utilities or common applications in main to include? Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: DMB: Proposal for a different review process
On 08/03/2011 12:23 PM, Chase Douglas wrote: On 08/03/2011 12:14 PM, Mackenzie Morgan wrote: On Wed, Aug 3, 2011 at 3:07 PM, Chase Douglas chase.doug...@canonical.com wrote: What is the policy for email applications? Can anyone apply this way, or is it only under specific circumstances? Split votes go to the mailing list to try to find enough +1s after a meeting. Board members can email in advance a +1/-1 if they have no questions (either because they didn't to start with or because they already talked to the person) The only time I've seen the application be done *completely* in email was when there was a 9-person-ish queue. Ok, that's evidence of what's been done in the past, but what is the policy? Can I do it myself? I'm asking because I seriously would rather do apply through email than get up at 6 AM on a Monday morning, hoping there's a quorum :). In my experience with various projects and communities, review processes that are done entirely by email or bug queues are generally less responsive, not more responsive. Regular time-based meetings are a useful social motivator. And, as an applicant, a multi-week email thread picking over their credentials is likely to be far more daunting than a quick discussion on IRC. But, this is a decision for the DMB, or if they choose to escalate it, a decision for higher community authorities. They understand the concern raised by several community members (including you), so it's time to step back and allow the community process to operate. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 820721] [NEW] Sync parrot 3.6.0-1 (universe) from Debian unstable (main)
Public bug reported: Please sync parrot 3.6.0-1 (universe) from Debian unstable (main) Changelog entries since current oneiric version 3.3.0-1: parrot (3.6.0-1) unstable; urgency=low * New upstream release * debian/watch: - Modified regular expression to capture numbered directory name (patch from Dominique Dumont). * debian/rules: - Split build-arch and build-indep, resolving lintian warning. - Update path to pbc_disassemble for manpage generation (patch from Dominique Dumont). * debian/patches: - Added patch 02_fix_perl_interpreter_path.patch, resolving lintian warnings. * debian/control: - Added DM-Upload-Allowed field. -- Allison Randal alli...@parrot.org Sat, 30 Jul 2011 18:45:03 +0200 ** Affects: parrot (Ubuntu) Importance: Wishlist Status: New ** Changed in: parrot (Ubuntu) Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/820721 Title: Sync parrot 3.6.0-1 (universe) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/parrot/+bug/820721/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
survey about bug workflows
Hi all, Following on a UDS session about bug lifecycles, a few of us have put together a survey. We'd like to collect information on how different teams handle bugs, identify common pain points, and explore possible improvements to features like status, tags, or bug heat. https://spreadsheets.google.com/spreadsheet/viewform?formkey=dGZqcm9YS083V19XT1RSMmV1RFJ2U3c6MQ Thanks for contributing your time. (And thanks to all who helped put together the survey.) Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
On 06/15/2011 11:34 AM, Scott Kitterman wrote: For Kubuntu, when we've been able to release at the end of the month we've been able to release with KDE 4.X.2. For Maverick we had to release with 4.5.1. This required significant effort on the part of Kubuntu developers to review all the upstream branches and cherrypick a number of important patches. I think that a roughly balanced schedule (nominally 26/26) is the best one for giving other projects that want to align to Ubuntu releases a reliable target to aim for. I like the idea of keeping a steady cadence. My preference would be slightly different, to go straight to 26 weeks: Q: October 25, 2012 (26 weeks) R: April 25, 2013 (26 weeks) This would align pretty well with what I expect will be the most likely upstream release plan for KDE. Very valuable perspective, thanks. To other upstreams, do you have similar or opposite needs? A few practical considerations I ran through: - Release on Oct 11 means UDS on Oct 29-Nov 2 (the week of Halloween) - Release on Oct 18 means UDS on Nov 5-9 - Release on Oct 25 means UDS on Nov 12-17 (the week before Thanksgiving) Having UDS the week before Thanksgiving will cause substantial travel problems for return flights from a US-based UDS. Having UDS on the week of Halloween could go either way (it's fun to have our semi-traditional UDS Halloween party, but parents based in countries that celebrate it would probably rather be home with their kids that week). Easter is March 31st in 2013, so we don't have to schedule around it for R. (In many years, Easter is the tricky bit for April releases.) Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: release cadence for Q and R
On 06/15/2011 07:41 PM, Ted Gould wrote: Does UDS have to be a fixed number of days from the release? It's been as short as 1 week after the release (no break, not much time to prepare), and as long as 6 weeks after (cuts heavily into the work of the cycle). So no hard rules, just weighing the +1s and -1s. 2 weeks is enough to regroup for the next cycle, but also allow plenty of development time. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
release cadence for Q and R
At UDS-O, we talked about balancing the 6-month cycle from the current 24/28 split towards a more even split. The general consensus was to keep the long 28 week cycle for P, since it's an LTS, but discuss more for Q and R. For context, I did a little walk down memory lane: https://wiki.ubuntu.com/AllisonRandal/ReleaseCadence Turns out, we've only had an actual 26 week cycle twice in the history of Ubuntu (Gutsy and Lucid), and never back-to-back. The longest cycle ever was 33 weeks (Dapper), immediately followed by the shortest cycle ever at 21 weeks (Edgy). The most common cycle length was 27 weeks (Breezy, Hardy, Intrepid, Karmic). Maverick was 24 weeks, Natty 28, and Oneiric and P follow the same 24/28 split. In the current draft schedules for Q and R we continue the 24/28 split: Q: October 11, 2012 (24 weeks) R: April 25, 2013 (28 weeks) The concern raised at UDS is that 24 week cycles are difficult for upstreams working to synchronize their cadence with ours. The simplest proposal is to bump Q one week later, and R one week earlier for: Q: October 18, 2012 (25 weeks) R: April 18, 2013 (26 weeks) And after that follow a more-or-less 26/26 split (barring interference by international holidays, etc). Would this change be helpful or harmful for you? If so, could you share a bit about how? Is the change adequate to address the needs of upstreams? To help our wonderful UDS planners (who need to know when to book UDS space for us), I'll summarize the thread for this Friday's release meeting, and we can discuss any remaining questions there. Thanks all, Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
shrinking the desktop DVD image to 1.5GB
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. Ubuntu desktop will be sticking with the ~700MB image size in Oneiric (see the wiki page for details), so this isn't about reopening that discussion or about fitting things on the 700MB image. A few questions: - Does a 1.5GB image sound useful? - 1.5GB is what we keep coming back to, because it's a nice size to fit on a cheap 2GB flash card/USB stick with room for formatting and persistent data storage. It's about double the size of the current CD image, which allows plenty of room for a generous desktop image, without the painfully large download of the 4.3GB image. What other size considerations come to mind? - What should we cut from the current DVD image (currently a superset of desktop, alternate, and server)? Or, perhaps more simply, what would be worth adding beyond the current 700MB CD image? Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Bug 790496] [NEW] FTBFS: znc depends on fix in swig 2.0.3 to work with Python 3.2
Public bug reported: Binary package hint: znc The znc package is FTBFS on Oneiric. This is noted in Debian as a version upgrade problem from Python 3.1 to 3.2. The failure messages are: compiler.cpp:(.text+0x19): undefined reference to `PyErr_Print' compiler.cpp:(.text+0x1e): undefined reference to `Py_Finalize' /tmp/ccLyjvoU.o: In function `main': compiler.cpp:(.text+0x49): undefined reference to `Py_Initialize' compiler.cpp:(.text+0x57): undefined reference to `PyImport_ImportModule' compiler.cpp:(.text+0x85): undefined reference to `PyObject_GetAttrString' compiler.cpp:(.text+0xab): undefined reference to `_Py_TrueStruct' compiler.cpp:(.text+0xd5): undefined reference to `Py_BuildValue' compiler.cpp:(.text+0x107): undefined reference to `Py_BuildValue' compiler.cpp:(.text+0x13b): undefined reference to `PyObject_Call' compiler.cpp:(.text+0x158): undefined reference to `Py_Finalize' (From https://launchpadlibrarian.net/71133981/buildlog_ubuntu- oneiric-i386.znc_0.098-2_FAILEDTOBUILD.txt.gz) This is fixed upstream in swig, and in the swig2.0 packages in Debian sid. Switching znc to the swig2.0 package might allow it to build with Python 3.2, but, as noted in the Debian bug report, it might also require additional porting. ** Affects: znc (Ubuntu) Importance: Undecided Status: New ** Affects: znc (Debian) Importance: Unknown Status: Unknown ** Tags: ftbfs oneiric python32 ** Bug watch added: Debian Bug tracker #622980 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622980 ** Also affects: znc (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622980 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/790496 Title: FTBFS: znc depends on fix in swig 2.0.3 to work with Python 3.2 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
