Re: build-from-branch into the primary archive
On Mon, Feb 21, 2011 at 09:47:15PM -0800, Steve Langasek wrote: On Tue, Feb 22, 2011 at 03:57:16PM +1100, Martin Pool wrote: On 22 February 2011 13:59, Scott Kitterman ubu...@kitterman.com wrote: The alternative of adding a specialized field in debian/control for packages that should generally only be uploaded from branch so that anyone who tries to dput the package gets some kind of warning (as discussed elsewhere in the thread) would, I think, deal with this case adequately while preserving the option to upload via dput should it REALLY be necessary in some case. There seem to be two variables here: does a package upload just give a warning, or does it block; and secondly is this configured in the package metadata itself or in Launchpad. On the first point I think we absolutely want to have it start out with just a warning. To be more accurate, we will actually start out with no warnings at all, and probably only turn them on when people feel that particular teams are over the hump of wanting to use it all the time. Regarding where it is done, I see no problem with doing it in debian/control. If it's configured in the package itself we would have the option to give a warning at the time people run dput rather than later sending mail back from Soyuz complaining about it. If you're going to put it in debian/control, then I think a Vcs-Bzr: field pointing at a UDD branch already encodes this information - 'apt-get source' already warns about it, we might as well have dput warn on the same thing. Someone would have to make sure they point to the right place though. I'd say about 80% of the packages I've looked at they are plain wrong. -apw -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Shall we hide the GUI for Hibernate in Natty?
I'm just a lurker here, I'm just a user and I don't tend to say a lot. But remember that: 1) Not everyone uses laptops. Desktop PCs do not have a battery and losing power during a suspend is a no-no. 2) Not everyone has a long running battery. Suspend does eat a little bit of your battery charge, and for people with little charge available it's a recipe for disaster. 3) Suspend is not reliable for long periods of time, because there's too much that can go wrong. If I travel, put my notebook in my bag, or just leave it for a few days (it happens sometimes) I prefer to leave it in hibernation. Carlos Ribeiro On Thu, Feb 17, 2011 at 02:44, Marco Trevisan (Treviño) m...@3v1n0.netwrote: Il giorno lun, 31/01/2011 alle 11.04 -0800, Rick Spencer ha scritto: Hello all, This email is to get some feedback and discussion about an idea under consideration for Ubuntu in Natty. Natty is currently NOT showing the Hibernate option in the list of shutdown choices. This is currently an experiment, but I thought it might be worth discussing the pros and cons on these lists as well. The reasoning for hiding Hibernate includes: 1. It doesn't work well for many users on many machines. This is partly true: it has improved a lot in recent times... 2. It's very slow. True, unfortunately true. But this is valid just for the standard kernel hibernation. Using TuxOnIce would improve a *lot* the usability and speed. Until something like TuxOnIce would be in the kernel, the hibernation is completely useless, if not damaging (sometimes ubuntu in low battery starts hibernating and it takes many minutes to perform the task, while it's impossible to stop the process!). 3. It's not as useful because users can just suspend. Mh, not true... Suspending is useful, but sometimes I really need to hibernate (i.e. remove laptop battery, keep it away from AC for long time...). 4. The difference between hibernate and suspend is confusing. True. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Carlos Ribeiro Consultoria em Projetos twitter: http://twitter.com/carribeiro blog: http://rascunhosrotos.blogspot.com mail: carribe...@gmail.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: collecting Python 3 status information
On 02/20/2011 11:16 PM, Robert Collins wrote: I think you need an upstream status field, for instance for python-testtools which is single-source python 3.2+ compatible, but may not be packaged thusly. Ah, thanks, yes the field needs a clearer name. I've changed Notes to Upstream Python 3 Plans. For the distros, we really only need a short status tag (packaged, not packaged, waiting for upstream, won't package, etc), but for the upstreams we'll need any details we can gather about whether, when, and how they plan to migrate. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 19, 2011, at 08:21 PM, Loïc Minier wrote: (We usually don't but lp:ubuntu URLs in Vcs-Bzr because it's kind of implicit that we have this branch in every package, but there is not way to tell whether the UDD branch is in use or not; listing it explicitly when it's used solves this) One other quick note. With bzr 2.3, lp:ubuntu branches can also be referenced by ubuntu:series/package urls. series can be 'maverick' or 'm' and can be omitted for the latest series. E.g. to get Natty's version of python-numpy, just say: % bzr branch ubuntu:python-numpy Maverick's version via: % bzr branch ubuntu:m/python-numpy Cheers, -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 21, 2011, at 11:14 AM, Steve Langasek wrote: For that matter, if DEBCHANGE_RELEASE_HEURISTIC=changelog were the default, there would be an explicit mark this ready for upload step that typically consists of 'dch -r debcommit -r', which creates exactly the same tag as 'bzr mark-uploaded'. FWIW, 'dch -r debcommit -r' is a bit of black magic that doesn't seem well-covered in the documentation. Or, perhaps more accurately, it wasn't stressed enough to make it onto my radar before this thread. Maybe it would be more discoverable as 'bzr release' instead of 'bzr mark-upload' or 'dch -r debcommit -r'? -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tue, Feb 22, 2011 at 09:18:31AM +, Andy Whitcroft wrote: Regarding where it is done, I see no problem with doing it in debian/control. If it's configured in the package itself we would have the option to give a warning at the time people run dput rather than later sending mail back from Soyuz complaining about it. If you're going to put it in debian/control, then I think a Vcs-Bzr: field pointing at a UDD branch already encodes this information - 'apt-get source' already warns about it, we might as well have dput warn on the same thing. Someone would have to make sure they point to the right place though. I'd say about 80% of the packages I've looked at they are plain wrong. Wrong /and pointed at a UDD branch/? As I said, it's very unlikely that you'll have stale information here when the field points at a UDD branch. Stale data is usually because the field wasn't changed when merging from Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: 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: build-from-branch into the primary archive
On Tue, Feb 22, 2011 at 11:14:56AM -0500, Scott Kitterman wrote: One point I don't understand is why people insist they need to leave work in progress on the official branch? bzr is a DVCS, so why don't people make their own branch and then only push to the official branch when it is, in fact, ready for upload. Because it's not work in progress, it's changes that are per se correct and ready for upload that may not justify an upload yet (or may not be uploadable at the time due to freezes, etc). They're pushed to the official branch to indicate that they should be included in the next upload, whenever that is. If we did it that way, then pushing to the official branch could be limited to people who could upload the package, build from branch could be triggered by the push, and there'd be no problem with dput uploads overwriting work in progress. So where, in this plan, do you intend to stage merges of work when several people are working on the package in parallel? Where should I push upload-ready but insufficient changes, to ensure they're picked up by whoever does the next upload? I'm not opposed to the idea of having merge branches and deployment branches - in fact I suggested something like this earlier in the thread, only with the existing UDD branches as the merge branches rather than the deployment branches - but this model definitely requires that we have both and that they're well-documented and we're (largely) consistent in their use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: 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: Shall we hide the GUI for Hibernate in Natty?
On Wednesday 23,February,2011 12:26 AM, Phillip Susi wrote: On 2/22/2011 10:44 AM, Chow Loong Jin wrote: My previously mentioned point still stands though. Many people close the lid of the laptop, stick it into a bag, and start walking. Considering the I/O intensive nature of the hibernation process, that practice can damage the hard disk pretty much. Laptop hard disks are generally built to withstand this. Whenever my wife moves her macbook around too much I can hear the distinctive click of the emergency head unload. This also is of course, not an issue when the default lid action is to suspend rather than hibernate. My first laptop hard disk burnt out after a year, and a month or so (warranty period + one month, what nice timing). The emergency head unloading feature isn't invulnerable, you know. Ever since then, I've taken care to avoid moving the laptop when hibernating. The gauge isn't broken. Well, not completely, anyway. The only issue is that it jumps from 5% directly to 0% without passing 4%-1%. But on the other hand, while there's enough power to last for half a day without running out of battery, there isn't always enough power to finish hibernation before it keels over and dies (starting from 0%). It sounds like it is estimating 5% remaining capacity, then realizes that, based on the terminal voltage, the battery is actually dead. Hence, it needs a good calibration cycle. If a good calibration cycle is equivalent to letting the battery completely burn out, then yes, I've done that. [...] -- Kind regards, Loong Jin 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: build-from-branch into the primary archive
On Tuesday, February 22, 2011 11:51:02 am Steve Langasek wrote: On Tue, Feb 22, 2011 at 11:14:56AM -0500, Scott Kitterman wrote: One point I don't understand is why people insist they need to leave work in progress on the official branch? bzr is a DVCS, so why don't people make their own branch and then only push to the official branch when it is, in fact, ready for upload. Because it's not work in progress, it's changes that are per se correct and ready for upload that may not justify an upload yet (or may not be uploadable at the time due to freezes, etc). They're pushed to the official branch to indicate that they should be included in the next upload, whenever that is. OK. That makes sense. If we did it that way, then pushing to the official branch could be limited to people who could upload the package, build from branch could be triggered by the push, and there'd be no problem with dput uploads overwriting work in progress. So where, in this plan, do you intend to stage merges of work when several people are working on the package in parallel? Where should I push upload-ready but insufficient changes, to ensure they're picked up by whoever does the next upload? I'm not sure what the best place would be. I'm not opposed to the idea of having merge branches and deployment branches - in fact I suggested something like this earlier in the thread, only with the existing UDD branches as the merge branches rather than the deployment branches - but this model definitely requires that we have both and that they're well-documented and we're (largely) consistent in their use. I think separating merge branches and deployment branches has the potential to avoid a number of problems, particularly the problem of dput uploads over- writing work in progress. It may, however, cause more problems than it solves since there would need to be a canonical location to stage merges that people would have to look at. My suspicion is that would still be better since people who are ignoring UDD won't cause problems and the odds of people who are actively participating in UDD following a new convention are better than the odds for people who aren't. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tue, 2011-02-22 at 10:41 -0500, Barry Warsaw wrote: On Feb 19, 2011, at 08:21 PM, Loïc Minier wrote: (We usually don't but lp:ubuntu URLs in Vcs-Bzr because it's kind of implicit that we have this branch in every package, but there is not way to tell whether the UDD branch is in use or not; listing it explicitly when it's used solves this) One other quick note. With bzr 2.3, lp:ubuntu branches can also be referenced by ubuntu:series/package urls. series can be 'maverick' or 'm' and can be omitted for the latest series. E.g. to get Natty's version of python-numpy, just say: % bzr branch ubuntu:python-numpy Maverick's version via: % bzr branch ubuntu:m/python-numpy Cool! I didn't know about that. Forgive me for not digging through the docs, but I am curious about one thing. At the moment, if a Vcs-Bzr tag does exist and one is using UDD, is one ever told about this? My workflow right now is: First I check to make sure the package is in sync in UDD (anybody have a good one liner for this? I just look at the package overview right now which is not very efficient) mkdir ~/pkg/$package cd ~/pkg/$package bzr init-repo bzr cd bzr bzr branch lp:ubuntu/series/$package series cd series -- make changes -- bzr bd -S dput ppa:whatever file.dsc sbuild -A -d series-arch file.dsc If all of that works I debcommit, push, and propose merging.. but I'm wondering at what point I might have been reminded of the Vcs-Bzr tag so I can go look there. I'm always reminded of it by 'apt-get source'. I know I've missed the existence of a branch before by not noting this very fact. Ideally bzr branch ubuntu:something would do the check and remind me at that point if the branch is different. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Shall we hide the GUI for Hibernate in Natty?
On Wednesday 23,February,2011 01:22 AM, Phillip Susi wrote: On 2/22/2011 11:51 AM, Chow Loong Jin wrote: If a good calibration cycle is equivalent to letting the battery completely burn out, then yes, I've done that. You have to run it all the way down _from full_. Leave it charge over night, then unplug it and let it run all the way down. If you just let it bounce back and forth between say, 40% and 80% and then finally take it down to 0, it won't calibrate. Yes, I'm quite aware of what a calibration cycle is, and that's what I did. The jumping from 5% to 0% is the best it can do. -- Kind regards, Loong Jin 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
Ubuntu Kernel Team Meeting Minutes - 2011-02-15
= Meeting Minutes = [[http://irclogs.ubuntu.com/2011/02/22/%23ubuntu-meeting.txt|IRC Log of the meeting.]] BR [[http://voices.canonical.com/kernelteam|Meeting minutes.]] == Agenda == [[https://wiki.ubuntu.com/KernelTeam/Meeting#Tues, 22 Feb, 2011|20110222 Meeting Agenda]] === Release Metrics === Release Meeting Bugs (8 bugs, 10 Blueprints) Alpha 3 Milestoned Bugs (56 across all packages (up 2)) * 4 linux kernel bugs (up 1) * 0 linux-ti-omap bugs (no change) * 0 linux-meta-ti-omap bug (no change) Release Targeted Bugs (265 across all packages (up 19)) * 23 linux kernel bugs (up 1) * 0 linux-ti-omap bugs (no change) * 0 linux-meta-ti-omap bug (no change) Milestoned Features * 7 blueprints (Including HWE Blueprints) Maverick Updates Bugs * 72 Linux Bugs (up 17) Lucid Updates Bugs * 94 Linux Bugs (up 1) Bugs with Patches Attached:98 (down 4) * [[https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on | Bugs with Patches]] * [[http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/ | Breakdown by status]] === Blueprints: Natty Bug Handling === Nothing new. === Blueprints: Enhancements to the firmware test suite === * Lots of tidying up * 0.22.00 now in Natty universe === Blueprints: Review of the Stable Maintenance Process (sconklin / bjf) === Last week all open fixes for all kernels were verified. This means that we're now in the Testing phase of the kernel SRU process. There are two reported regressions in Maverick which are being investigated. They are: BR https://bugs.launchpad.net/ubuntu/+source/linux/+bug/721213 BR https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722747 BR BR Lucid and Maverick will receive testing from Certification and QA. We need testing from users for all other kernels, to at least insure that they boot and run. If you boot any of these kernels, please update the tracking bug for that kernel with the results. BR BR The Kernel Team's SRU report has moved out to a more publicly accessible location: http://kernel.ubuntu.com/~kernel-ppa/reports/sru-report.html === Status: Cert. Team === We will be starting testing this week (tomorrow) the kernels for Maverick and Lucid. We will finish and report back before March 1st === Status: Ecryptfs === * took a bit of a detour last week with tyler exploring compression of filenames * still waiting on full review BR BR Question: We've definitely decided to postpoone long file names until after 11.04 ? BR Answer: I believe so, dustin thinks its the way to go too BR === Status: Natty === The natty kernel is now at v2.6.38-4.31 (v2.6.38-rc5 based). We have just rebased to v2.6.38-rc6 and uploaded, this should be in the archive before feature freeze. Overall we have most of our development out of the way, with just the ecryptfs long filename work ongoing. We are currently concentrating on bug squashing for Natty. === Security bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper (sconklin / bjf) === || Package|| Upd/Sec || Proposed || TiP || Verified || |||| || || || || || dapper linux-source-2.6.15 || 2.6.15-55.91 || 2.6.15-55.93 ||0 ||0 || |||| || || || || || hardylinux || 2.6.24-28.81 || 2.6.24-28.86 ||0 ||0 || |||| || || || || || karmic linux-fsl-imx51 || 2.6.31-112.28|| 2.6.31-112.30||1 ||1 || || --- linux-ec2 || 2.6.31-307.23|| 2.6.31-307.27||0 ||0 || || --- linux || 2.6.31-22.70 || 2.6.31-22.73 ||0 ||0 || |||| || || || || || lucidlinux-ec2 || 2.6.32-312.24|| 2.6.32-313.26||8 ||6 || || --- linux-ports-meta || 2.6.32.28.21 || 2.6.32.29.22 ||0 ||0 || || --- linux-mvl-dove|| 2.6.32-211.27|| 2.6.32-214.30||6 ||6 || || --- linux-meta-mvl-dove || 2.6.32.209.12|| 2.6.32.214.15||0 ||0 || || --- linux-lts-backport-maverick || 2.6.35-23.41~lucid1 || 2.6.35-25.44~lucid1 ||0 ||0 || || --- linux-meta|| 2.6.32.28.32 || 2.6.32.29.34 ||0 ||0 || || --- linux-firmware
Re: build-from-branch into the primary archive
On Feb 22, 2011, at 11:14 AM, Scott Kitterman wrote: One point I don't understand is why people insist they need to leave work in progress on the official branch? bzr is a DVCS, so why don't people make their own branch and then only push to the official branch when it is, in fact, ready for upload. If we did it that way, then pushing to the official branch could be limited to people who could upload the package, build from branch could be triggered by the push, and there'd be no problem with dput uploads overwriting work in progress. I work that way, but independent dputs are still a problem. In a recent computer-janitor case, the changelog entry for the dput didn't show up in the source branch. So I see 2.1.0-0ubuntu1 but no 2.1.0-0ubuntu2. I had to merge the actual change manually into the trunk branch, then bump the version to 2.1.0-0ubuntu3 with a note about why -0ubuntu2 is skipped. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 22, 2011, at 09:23 AM, Clint Byrum wrote: Cool! I didn't know about that. There's also debian-lp: prefix for Debian series branches in Launchpad (for various reasons, we can't use just debian:). Note however, that the series must be spelled out for debian-lp: -- there are no abbreviations. At the moment, if a Vcs-Bzr tag does exist and one is using UDD, is one ever told about this? Not by Bazaar afaik. My workflow right now is: First I check to make sure the package is in sync in UDD (anybody have a good one liner for this? I just look at the package overview right now which is not very efficient) See step 0 in https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource for best known practice. There's an open bug in udd on better warnings when the package branch is out of date due to import failures. mkdir ~/pkg/$package cd ~/pkg/$package bzr init-repo bzr cd bzr bzr branch lp:ubuntu/series/$package series cd series -- make changes -- bzr bd -S dput ppa:whatever file.dsc sbuild -A -d series-arch file.dsc I do things very similarly, though usually I'm sbuild'ing before I dput to my PPA. If all of that works I debcommit, push, and propose merging.. but I'm wondering at what point I might have been reminded of the Vcs-Bzr tag so I can go look there. I'm always reminded of it by 'apt-get source'. I know I've missed the existence of a branch before by not noting this very fact. Ideally bzr branch ubuntu:something would do the check and remind me at that point if the branch is different. Yep. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Martin Pool [2011-02-21 16:17 +1100]: It seems like 'mark-uploaded' is causing a certain amount of friction at the moment: cases where it's not run and the branch therefore gets out of sync with the upload, and also just that it's an additional step that weighs people down. Right now, debcommit -r already does what mark-uploaded does; is there a reason why debcommit -r couldn't also (or instead) call bzr mark-uploaded? That would keep the workflow without an additional step for people who already use the UNRELEASED/dch -r/debcommit -r schema, and just introduce one extra step for the others. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tue, Feb 22, 2011 at 09:57:35PM +0100, Martin Pitt wrote: Andy Whitcroft [2011-02-22 9:18 +]: Someone would have to make sure they point to the right place though. I'd say about 80% of the packages I've looked at they are plain wrong. Really? I found maybe two in the last half year, which I fixed at once when pushing/uploading. In the desktop team we certainly take a lot of care to keep Vcs-Bzr: correct. Do you have some examples where they are wrong? The usual case for this is a package that has a Vcs-* field for the Debian packaging, gets modified in Ubuntu directly in the archive without pushing a new VCS branch anywhere, and doesn't get the Vcs-* fields updated to indicate that they don't represent the Ubuntu package history. As a first approximation: $ zcat ~/ubuntu/dists/natty/*/source/Sources.gz \ | grep-dctrl -r -FVersion ubuntu -a \ \( \( -FVcs-Bzr . -a \! -FVcs-Bzr launchpad \) -o -FVcs-Git . \ -o -FVcs-Svn . -o -FVcs-Cvs . \) \ -sPackage,Version,Vcs-Bzr,Vcs-Git,Vcs-Svn,Vcs-Cvs | grep -c Package 1037 $ 1037 source packages in natty with an ubuntu version number and some kind of Vcs-* field set not pointing at launchpad. Almost all of these fields contain stale data for Ubuntu's purposes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: 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: build-from-branch into the primary archive
On Tue, Feb 22, 2011, Barry Warsaw wrote: I work that way, but independent dputs are still a problem. In a recent computer-janitor case, the changelog entry for the dput didn't show up in the source branch. So I see 2.1.0-0ubuntu1 but no 2.1.0-0ubuntu2. I had to merge the actual change manually into the trunk branch, then bump the version to 2.1.0-0ubuntu3 with a note about why -0ubuntu2 is skipped. But this was actually a case of me not being able to commit to the Vcs branch! :-) What I usually do in these cases is copy the changelog to bzr myself, to reconcile -- Loïc Minier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 22, 2011, at 10:29 PM, Loïc Minier wrote: But this was actually a case of me not being able to commit to the Vcs branch! :-) That's definitely a problem. :) Because of the team nature of Ubuntu development, I think in general uploaders should have push rights to the UDD branches. What I usually do in these cases is copy the changelog to bzr myself, to reconcile -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
changing perms on /sys/kernel/debug by default
Hi, While I'd like to just not compile debugfs into the Ubuntu kernels at all, it seems that there is a fair bit of push-back on this idea. Instead, the dangerous /sys/kernel/debug/acpi/custom_method interface has been removed as the most problematic of all the interfaces (it allows writing arbitrary kernel memory, bypassing /dev/kmem, /dev/mem, and module restrictions). Since debugfs should not be required for a production system[1], I'd like to remove it from mountall's default fstab. To get there, the first step is to make /sys/kernel/debug only accessible by the root user. Unfortunately, it does not take a mode= mount option like tmpfs does, so mountall has been adjusted[2] to set the mode after mounting instead. In the interests of completeness, here are the tools in main that use debugfs, with stuff that needs updating (only Apport hooks) marked with a star: - intel_gpu_dump Manpage states it should only be run as root. - libpcap Only used as root for USB monitoring. * mtdev Apport hook (should be updated to use root privs). - nmap Only used as root for USB monitoring. - ocfs2-tools Only used as root for OCF2 debugging. - powertop Only used as root. - qemu-kvm kvm_stat has no manpage, seems to be designed as a vmstat for kvm. These statistics should likely come from /sys. Running as root seems fine. - redhat-cluster Only used as root. - ureadhead Runs as root, but this tool already uses /var/lib/ureadahead/debugfs if the other path is missing. I've changed[3] the permissions on this so that normal users cannot see the mountpoint. - usbutils Uses /dev/bus/usb for lsusb, but usb-devices wants debugfs. This information should not come out of debugfs. Requiring root seems okay. * utouch-geis Apport hook (should be updated to use root privs). * xserver-xorg-video-intel Apport hook (should be updated to use root privs). - blktrace Only used as root. Thanks, -Kees [1] https://lkml.org/lkml/2011/2/22/372 [2] https://lists.ubuntu.com/archives/natty-changes/2011-February/008110.html [3] https://lists.ubuntu.com/archives/natty-changes/2011-February/008100.html -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: changing perms on /sys/kernel/debug by default
On Tue, Feb 22, 2011 at 03:16:39PM -0800, Kees Cook wrote: Hi, While I'd like to just not compile debugfs into the Ubuntu kernels at all, it seems that there is a fair bit of push-back on this idea. Instead, the dangerous /sys/kernel/debug/acpi/custom_method interface has been removed as the most problematic of all the interfaces (it allows writing arbitrary kernel memory, bypassing /dev/kmem, /dev/mem, and module restrictions). Since debugfs should not be required for a production system[1], I'd like to remove it from mountall's default fstab. To get there, the first step is to make /sys/kernel/debug only accessible by the root user. Unfortunately, it does not take a mode= mount option like tmpfs does, so mountall has been adjusted[2] to set the mode after mounting instead. - intel_gpu_dump Manpage states it should only be run as root. * xserver-xorg-video-intel Apport hook (should be updated to use root privs). I believe it does already, no? It gets triggered by the kernel via an upstart hook. Due to the nature of GPU lockups, we can't prompt the user for root password or something at the point it gets triggered; the system's locked up. We get the majority of our value out of the apport hook during development. So if you wanted to make debugfs be enabled only during release, and switch it off after beta, we could work with that. Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: changing perms on /sys/kernel/debug by default
On Tue, Feb 22, 2011 at 03:37:27PM -0800, Bryce Harrington wrote: On Tue, Feb 22, 2011 at 03:16:39PM -0800, Kees Cook wrote: While I'd like to just not compile debugfs into the Ubuntu kernels at all, it seems that there is a fair bit of push-back on this idea. Instead, the dangerous /sys/kernel/debug/acpi/custom_method interface has been removed as the most problematic of all the interfaces (it allows writing arbitrary kernel memory, bypassing /dev/kmem, /dev/mem, and module restrictions). Since debugfs should not be required for a production system[1], I'd like to remove it from mountall's default fstab. To get there, the first step is to make /sys/kernel/debug only accessible by the root user. Unfortunately, it does not take a mode= mount option like tmpfs does, so mountall has been adjusted[2] to set the mode after mounting instead. - intel_gpu_dump Manpage states it should only be run as root. * xserver-xorg-video-intel Apport hook (should be updated to use root privs). I believe it does already, no? It gets triggered by the kernel via an upstart hook. Due to the nature of GPU lockups, we can't prompt the user for root password or something at the point it gets triggered; the system's locked up. Ah, yes. If it's spawning from the X process context, this should be done already. We get the majority of our value out of the apport hook during development. So if you wanted to make debugfs be enabled only during release, and switch it off after beta, we could work with that. Based on the above, it should all Just Work for the GPU case. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: changing perms on /sys/kernel/debug by default
On Tue, Feb 22, 2011 at 03:46:36PM -0800, Kees Cook wrote:
On Tue, Feb 22, 2011 at 03:37:27PM -0800, Bryce Harrington wrote:
On Tue, Feb 22, 2011 at 03:16:39PM -0800, Kees Cook wrote:
While I'd like to just not compile debugfs into the Ubuntu kernels at all,
it seems that there is a fair bit of push-back on this idea. Instead, the
dangerous /sys/kernel/debug/acpi/custom_method interface has been removed
as the most problematic of all the interfaces (it allows writing arbitrary
kernel memory, bypassing /dev/kmem, /dev/mem, and module restrictions).
Since debugfs should not be required for a production system[1], I'd like
to remove it from mountall's default fstab. To get there, the first step
is
to make /sys/kernel/debug only accessible by the root user. Unfortunately,
it does not take a mode= mount option like tmpfs does, so mountall has
been adjusted[2] to set the mode after mounting instead.
- intel_gpu_dump
Manpage states it should only be run as root.
* xserver-xorg-video-intel
Apport hook (should be updated to use root privs).
I believe it does already, no? It gets triggered by the kernel via an
upstart hook.
Due to the nature of GPU lockups, we can't prompt the user for root
password or something at the point it gets triggered; the system's
locked up.
Ah, yes. If it's spawning from the X process context, this should be done
already.
We get the majority of our value out of the apport hook during
development. So if you wanted to make debugfs be enabled only during
release, and switch it off after beta, we could work with that.
Based on the above, it should all Just Work for the GPU case.
Just to confirm; yes it should be fine. Bryce pointed out on IRC that this
is called through /lib/udev/rules.d/40-xserver-xorg-video-intel.rules:
SUBSYSTEM==drm, ACTION==change, ENV{ERROR}==1,
RUN+=/usr/share/apport/apport-gpu-error-intel.py
And that's running as root to collect the debugfs bits. Done! :)
-Kees
--
Kees Cook
Ubuntu Security Team
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Barry Warsaw [2011-02-22 17:22 -0500]: That's definitely a problem. :) Because of the team nature of Ubuntu development, I think in general uploaders should have push rights to the UDD branches. They do already. computer-janitor uses a custom branch, though, which is owned by ~computer-janitor-hackers. I. e. people who can upload the package can't commit to the branch. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: 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: build-from-branch into the primary archive
On 02/22/2011 02:20 PM, Barry Warsaw wrote: On Feb 22, 2011, at 11:14 AM, Scott Kitterman wrote: One point I don't understand is why people insist they need to leave work in progress on the official branch? bzr is a DVCS, so why don't people make their own branch and then only push to the official branch when it is, in fact, ready for upload. If we did it that way, then pushing to the official branch could be limited to people who could upload the package, build from branch could be triggered by the push, and there'd be no problem with dput uploads overwriting work in progress. I work that way, but independent dputs are still a problem. In a recent computer-janitor case, the changelog entry for the dput didn't show up in the source branch. So I see 2.1.0-0ubuntu1 but no 2.1.0-0ubuntu2. I had to merge the actual change manually into the trunk branch, then bump the version to 2.1.0-0ubuntu3 with a note about why -0ubuntu2 is skipped. -Barry Couldn't bzr import-dsc have helped here? Micah -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OOo and LibO
Hello On 10 February 2011 13:41, Prof. Román H. Gelbort elprofero...@openoffice.org wrote: Hi folks. I'm an Ubuntu user and supporter for years, in Argentina. And I'm the marketing contact of OpenOffice.org in my country too. Now, with the becoming of LibO to Ubuntu... ¿Is there the possibility that OpenOffice.org (vanilla) is in Ubuntu repository? This has been previously discussed. A vanilla version of OpenOffice.org was never quite part of Ubuntu. We had OO.o + Novell's Go-OO patches + something else. Ubuntu did used to ship with Sun and later with Oracle logos on the splash screen though, despite not shipping vanilla OpenOffice.org. OpenOffice.org is a huge application which requires a lot of work to maintain. And most likely will not happen due to technical, governance and social reasoning being in favour of LibreOffice. Have you considered joining the Document Foundation and do marketing for both? Note: Forgive my poor English. I try to ask this very kindly. Your English is great =) Best regards. Regards. -- ·· Prof. Román H. Gelbort Director conosur de OpenOffice.org en Español http://es.openoffice.org 10 años usando OpenOffice.org, libre, gratuito y seguro ·· -- 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 -- 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
nvidia binary drivers
On 02/22/2011 06:00 AM, Martin Pitt martin.p...@ubuntu.com wrote: Patrick Goetz [2011-02-21 14:41 -0600]: Does the feature freeze include updating binary drivers? In principle yes, but as the current nvidia/fglrx drivers in Natty are totally broken (they are currently not available for the current X.org ABI), they will be updated by the end of the release (assuming that there will be a new compatible upstream release up to that point). That's strange -- there's no mention of this on the nvidia linux amd64 driver page: http://www.nvidia.com/object/linux-display-amd64-260.19.36-driver.html are you sure that 260.19.36 is broken as well for x.org 1.10? While on the subject, the package naming scheme for the nvidia binary drivers doesn't make any sense to me: -- Package nvidia-173-kernel-source * natty (misc): Transitional package for nvidia-glx-173-kernel-source [restricted] 173.14.28-0ubuntu4: amd64 i386 Package nvidia-180-kernel-source * natty (misc): Transitional package for nvidia-glx-185-kernel-source [restricted] 185.18.36-0ubuntu9: amd64 i386 Package nvidia-185-kernel-source * natty (misc): Transitional package for nvidia-glx-185-kernel-source [restricted] 260.19.29-0ubuntu1: amd64 i386 -- Huh? Things seem to have gone off the rail around version 180 and then got progressively worse. Any chance the package naming scheme can be rendered sensible, at least for the newest drivers? -- Patrick Goetz -- 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
