Re: Enabling Connectivity Checking in NetworkManager
On Thu, 2012-07-12 at 17:42 +0100, Colin Watson wrote: > On Tue, Jul 10, 2012 at 02:19:21PM -0500, Ted Gould wrote: > > I'd agree that it's an extreme situation, but technically any connection > > would be. For instance, my ISP or company would have a high likelyhood > > that I'm running Ubuntu by watching for this. For those who are > > concerned, I don't believe the alternate installer does this check. > > I'm not sure that counts because there is significant top-down pressure > to stop supporting the alternate installer. Interesting, I wasn't aware. Personally, I'd support a feature of the standard installer to put it in a silent mode. I don't think it should be a check box, but as perhaps a "Ctrl+P" type thing. Then we can argue about whether it's "Privacy Mode" or "Paranoid Mode" ;-) That way those who really care would be likely to know it, but it wouldn't complicate the more standard installs. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Automatic import from debian package not found in Ubuntu
On 12 July 2012 17:13, Emmanuel Kasper wrote: > The auto-sync script is right. Indeed we package these mame tools in > mess ( mame and mess have a partially common source tree ) > > As Cesare said, we merged already in debian unstable the mame package > from debian and ubuntu, so the first step should be to replace mame > 0.145-0ubuntu1 with mame 0.146-1 ( which does not include the mame-tools > ), then the auto-sync script should work for mess. What's going on with http://bugs.debian.org/678249 ? Do you plan to release a new mame/mess to workaround that bug? Jeremy -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Automatic import from debian package not found in Ubuntu
The problem was that our auto-sync script said this: > > [New] mess_0.146-1 > No previous publications in Ubuntu > OK (Y/n)? >* Trying to add mess ... > mess_0.146-1 is trying to override modified binary > mame-tools_0.145-0ubuntu1. OK (y/N)? > > ... and I didn't have a chance to check whether this was OK. Can you > say whether mess 0.146-1 completely supersedes mame 0.145-0ubuntu1, or > are there outstanding Ubuntu changes that we'd need to preserve by way > of a merge? > Hello Colin Thank you for you answer The auto-sync script is right. Indeed we package these mame tools in mess ( mame and mess have a partially common source tree ) As Cesare said, we merged already in debian unstable the mame package from debian and ubuntu, so the first step should be to replace mame 0.145-0ubuntu1 with mame 0.146-1 ( which does not include the mame-tools ), then the auto-sync script should work for mess. greets Manu -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Freeze next week?
On Thu, 2012-07-12 at 17:07 +0100, Colin Watson wrote: > Hopefully the subject got people's attention. :-) I don't mean quite > what you might think, though. > > I've been working on a new upload queue management API in Launchpad, and > it's almost feature-complete; the next Launchpad deployment will > probably contain everything needed to make the API client a full > replacement for the old script that archive admins used to run by sshing > to a privileged server. I would like to remove the old queue script > soon so that we don't have two implementations of essentially the same > thing lying around and confusing people. > > However, I also need to be careful about this. In the past, we have > sometimes found that accepting uploads through the Launchpad web UI has > timed out, and we've had to fall back to using the non-time-limited > script. This tended to particularly affect uploads that closed several > bugs with large numbers of subscribers and/or duplicates. I *think* the > API client should be a bit less susceptible to this because the cost of > rendering the queue view again won't be included in the timeout, but > it's possible I'm wrong and that further work is needed. It would be > bad to discover during beta or final freeze that we were unable to > accept an important fix! > > I'd therefore like to do a real-world test of a freeze at some point > when it doesn't matter too much. We would move quantal into the > "Pre-release Freeze" state, meaning that all uploads to quantal and > quantal-proposed would land in the Unapproved queue. However, we > wouldn't review packages in the queue manually, but any archive admin > would be able to accept them as soon as they noticed them, preferably > using the API client. We have enough archive admins in a variety of > timezones that we should be able to keep disruption to a minimum. > > I'm not sure how long it would take to achieve a reasonable level of > assurance. I doubt a day would be enough, but people's patience would > probably start to wear thin after a week, so probably something in > between. I'd like to make sure that we've accepted a few reasonably > large sets of changes in the relevant period. > > Note that uploads to -proposed aren't a terribly good test of this, > because they don't close bugs until they're copied to the release pocket > (and the copy goes through a separate job queue that has a much more > generous timeout); so we can't really test this with SRUs and a > sufficiently rigorous test will probably involve people not uploading to > quantal-proposed when they otherwise might have done. Similarly, while > kernel uploads would ordinarily be good sources of large numbers of bug > closures, they're only any use for this if they go straight to quantal > rather than going through the canonical-kernel-team PPA or > quantal-proposed. > > Any thoughts? We usually end up soft-freezing from Monday at 2100 until Thursday when we ship. Most of the churn happens between Monday 2100 and Wednesday 2100 - so how about that as the window here? That will give a 2 day test? Would rather this be done sooner than later, so we can start to use this capability going forward. Anyone see anyreasons why not to try this next monday? July 16 -> July 18 th? Thanks for all your hard work on getting this ready. :) Kate -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Automatic import from debian package not found in Ubuntu
>> Is it because the package sits in the non-free section of the Debian >> Archive ? > > No, it's not. The problem was that our auto-sync script said this: > > [New] mess_0.146-1 > No previous publications in Ubuntu > OK (Y/n)? >* Trying to add mess ... > mess_0.146-1 is trying to override modified binary > mame-tools_0.145-0ubuntu1. OK (y/N)? > > ... and I didn't have a chance to check whether this was OK. Can you > say whether mess 0.146-1 completely supersedes mame 0.145-0ubuntu1, or > are there outstanding Ubuntu changes that we'd need to preserve by way > of a merge? mame 0.146-2 has already anything needed for merging, but I guess it requests manual sync to override my previous package in the repository. Is this right? Cheers, Cesare. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling Connectivity Checking in NetworkManager
On Tue, Jul 10, 2012 at 02:19:21PM -0500, Ted Gould wrote: > I'd agree that it's an extreme situation, but technically any connection > would be. For instance, my ISP or company would have a high likelyhood > that I'm running Ubuntu by watching for this. For those who are > concerned, I don't believe the alternate installer does this check. I'm not sure that counts because there is significant top-down pressure to stop supporting the alternate installer. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Automatic import from debian package not found in Ubuntu
On Wed, Jul 11, 2012 at 03:00:38PM +0200, Emmanuel Kasper wrote: > I am a Debian maintainer, working on the mess package which sits in > non-free in Debian ( the Mame license does not allow commercial use > of the software, for the rest it is BSD ) > > I would have tought according to > https://wiki.ubuntu.com/DebianImportFreeze, that the package would > automatically end up in Quantal, as it was accepted in Debian > Testing in December 2011. This would ordinarily be true. > But the DebianImportFreeze date is gone, and I find no trace of it > in the Quantal packages using rmadison. > > Is it because the package sits in the non-free section of the Debian > Archive ? No, it's not. The problem was that our auto-sync script said this: [New] mess_0.146-1 No previous publications in Ubuntu OK (Y/n)? * Trying to add mess ... mess_0.146-1 is trying to override modified binary mame-tools_0.145-0ubuntu1. OK (y/N)? ... and I didn't have a chance to check whether this was OK. Can you say whether mess 0.146-1 completely supersedes mame 0.145-0ubuntu1, or are there outstanding Ubuntu changes that we'd need to preserve by way of a merge? -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Minutes from the 12.04.1 team meeting (Thursday 12th of July)
The fourth 12.04.1 team meeting took place at 14:00 UTC on Thursday the 12th of July 2012. *Note: the meetings are now moving to a weekly schedule until the release of 12.04.1 on the 23rd of August* == Attendees == * arges * bdmurray * jamespage * ScottK * seb128 * skaet * smoser * stgraber (chair) * stokachu == Notes == arges worked on a bug report for point releases, it's available at: http://people.canonical.com/~arges/point-release/milestone-12.04.1.html This report isn't currently built automatically and will likely be moved to reports.qa.ubuntu.com in the near future. Quite a few suggestions have been made to improve that report and ensure that all the relevant bugs are on it (quite a few seem to be missing). The upcoming deadlines are: * 2012/08/02: Beginning of PointReleaseProcess and DesktopInfrastructureFreeze * 2012/08/09: KernelFreeze, LanguageTranslationDeadline, SRU Fix Validation Testing * 2012/08/16: FinalFreeze, ReleaseNoteFreeze * 2012/08/23: Ubuntu 12.04.1 There are still quite a few concerns on the length of the Unapproved queue for -proposed, sitting at around 30 packages, representing almost two weeks of backlog. This is making it harder for the team to track exactly what's going on. Bug list went from 106 bugs targeted to 12.04.1 to 112. 26 of these are currently marked fix commited (vs 27 two weeks ago). 50 of the 112 bugs aren't currently assigned to someone. This is quite bad as the number of bug is supposed to go down, not up at this point... All 12.04.1 team members will go through the list to ensure all the bugs are assigned and that any bug that won't make it to 12.04.1 is moved to another milestone. The meeting cadence is also changing from fortnightly to weekly in an effort to keep everyone focused and aware of the state of 12.04.1 in that last month before release. == Team status updates == * L3: Working on multi-arch and the point-release report. * Release: Looking at QA daily testing, will try to get SRUs to land faster. * Desktop: A bit behind on compiz/unity SRUs, Unity should be uploaded next week, compiz was reverted at the last minute and will be pushed again real soon. The team is concerned by the SRU backlog, making it more difficult to track issues on errors.ubuntu.com * Server: Went through the whole list, will follow up on juju and maas to make sure the fixes land on time. http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html * Foundations: Going through the whole list of bugs, will fix the status/target/importance for any where it's obviously wrong, trying to get things assigned to people. == Actions == * xnox to liase with ballons, gema and jibel w.r.t. fs/storage testing (carried) * stgraber to review and sponsor bug 977947, bug 977952 and bug 977940 * skaet to poke the SRU team and see what can be done to process the current backlog * stgraber to change the meeting to a weekly meeting Full meeting log is available here: http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-12-14.00.log.html The next meeting will be on Thursday the 19th of July at 14:00 UTC (#ubuntu-meeting on freenode). Useful resources and the meeting agenda are available at: https://wiki.ubuntu.com/PrecisePangolin/12.04.1 -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Automatic import from debian package not found in Ubuntu
Hi Emmanuel (2012.07.11_15:00:38_+0200) > Is it because the package sits in the non-free section of the Debian > Archive ? Is to possible to ask for the package to be imported ? Am > I missing something ? No, it is because it has been sync blacklisted: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt # cjwatson, 2012-06-01 # Temporary blacklist entries for quantal, requiring manual resolution due # to conflicts with existing Ubuntu-versioned binaries. mess If it is correct, and it should be overriding the binary packages from mame, then please raise a bug with the Archive Admins. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Freeze next week?
Hopefully the subject got people's attention. :-) I don't mean quite what you might think, though. I've been working on a new upload queue management API in Launchpad, and it's almost feature-complete; the next Launchpad deployment will probably contain everything needed to make the API client a full replacement for the old script that archive admins used to run by sshing to a privileged server. I would like to remove the old queue script soon so that we don't have two implementations of essentially the same thing lying around and confusing people. However, I also need to be careful about this. In the past, we have sometimes found that accepting uploads through the Launchpad web UI has timed out, and we've had to fall back to using the non-time-limited script. This tended to particularly affect uploads that closed several bugs with large numbers of subscribers and/or duplicates. I *think* the API client should be a bit less susceptible to this because the cost of rendering the queue view again won't be included in the timeout, but it's possible I'm wrong and that further work is needed. It would be bad to discover during beta or final freeze that we were unable to accept an important fix! I'd therefore like to do a real-world test of a freeze at some point when it doesn't matter too much. We would move quantal into the "Pre-release Freeze" state, meaning that all uploads to quantal and quantal-proposed would land in the Unapproved queue. However, we wouldn't review packages in the queue manually, but any archive admin would be able to accept them as soon as they noticed them, preferably using the API client. We have enough archive admins in a variety of timezones that we should be able to keep disruption to a minimum. I'm not sure how long it would take to achieve a reasonable level of assurance. I doubt a day would be enough, but people's patience would probably start to wear thin after a week, so probably something in between. I'd like to make sure that we've accepted a few reasonably large sets of changes in the relevant period. Note that uploads to -proposed aren't a terribly good test of this, because they don't close bugs until they're copied to the release pocket (and the copy goes through a separate job queue that has a much more generous timeout); so we can't really test this with SRUs and a sufficiently rigorous test will probably involve people not uploading to quantal-proposed when they otherwise might have done. Similarly, while kernel uploads would ordinarily be good sources of large numbers of bug closures, they're only any use for this if they go straight to quantal rather than going through the canonical-kernel-team PPA or quantal-proposed. Any thoughts? -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
