Re: EFF Privacy; hopefully Ubuntu will listen to users
On Tue, Nov 6, 2012 at 4:28 PM, C de-Avillez hgg...@ubuntu.com wrote: On 05/11/12 09:08, Jordon Bedwell wrote: This is from my perspective though and I have not really followed all too closely since I am the type of person to remove what I don't want and block stuff like Canonical's NTP and other tracking via our hardware firewalls instead of complaining about stuff that I myself can fix. I am curious on what is this block stuff like Canonical's NTP and other tracking Hi, wild guess: other tracking may be completely unrelated to canonical here. On Canonical's NTP it is indeed some kind of tracking, I remember seeing some estimates of the global number of ubuntu users based on statistics from canonical's NTP servers. To be perfectly clear: there is IMHO nothing wrong about this, I see more value in this kind of statistics than I have problems with canonical knowing my IP address and the time at which I turn my computer on. I just agree that it is indeed some form of tracking. On the more specific problem of amazon search integrated into unity, I think the feature is a pretty cool one and I suppose that canonical did honestly what it could to respect privacy here, but I share the EFF's concerns as well. IMHO, it would not be a bad move from canonical to make it opt-in (and to advertise it when it is disabled) or to add a button to include web results in this search on demand. Best. -- Aurélien Naldi -- 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: EFF Privacy; hopefully Ubuntu will listen to users
On Mon, Nov 05, 2012 at 03:28:44PM +, J Fernyhough wrote: I'm currently looking into how Ubuntu meets the provisions of the Data Protection Act 1998, and more crucially what would need to be done to meet the requirements, so that I have some base of evidence and legal reasoning to put forward (for example, at no point in the download or installation process is it identified which information is being gathered, how it will be stored, by whom, how it will be used, or who to contact). Not during installation, but I believe I've seen a Legal notice link displayed somewhere in the Unity UI which has that information. (Apologies for vagueness; I don't work on this stuff myself.) (As an aside, it appears that being only enthusiastic about Ubuntu and all decisions, or at least getting in line, is a requisite for employment there.) I can only speak for myself and I don't do very much hiring nowadays since I quit management, but this is certainly not true of the hiring decisions I've made. One of my routine interview questions is along the lines of asking what we are doing wrong and how we could improve it, and I give considerable weight to non-trivial answers; I've never been interested in hiring yes-men, and I would probably mark somebody *down* for being too uncritically enthusiastic (if we're so perfect, what are you going to do for us then ...). Of course, the how we could improve it bit is important; employees need to achieve goals which often implies being pragmatic about how they approach problems, and they don't necessarily have the luxury of going in all guns blazing all the time. -- Colin Watson [cjwat...@ubuntu.com] -- 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: EFF Privacy; hopefully Ubuntu will listen to users
On 5 November 2012 15:35, Martin Albisetti be...@ubuntu.com wrote: On Mon, Nov 5, 2012 at 12:28 PM, J Fernyhough j.fernyho...@gmail.com wrote: (As an aside, it appears that being only enthusiastic about Ubuntu and all decisions, or at least getting in line, is a requisite for employment there.) It is not. On 7 November 2012 15:23, Colin Watson cjwat...@ubuntu.com wrote: I can only speak for myself and I don't do very much hiring nowadays since I quit management, but this is certainly not true of the hiring decisions I've made. This is good to hear; from what I've read previously there's been little criticality from more established contributors - it could well be that I'm not subscribed to the correct lists (or reading the wrong things!). J -- 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: EFF Privacy; hopefully Ubuntu will listen to users
On 7 November 2012 15:23, Colin Watson cjwat...@ubuntu.com wrote: On Mon, Nov 05, 2012 at 03:28:44PM +, J Fernyhough wrote: I'm currently looking into how Ubuntu meets the provisions of the Data Protection Act 1998, and more crucially what would need to be done to meet the requirements, so that I have some base of evidence and legal reasoning to put forward (for example, at no point in the download or installation process is it identified which information is being gathered, how it will be stored, by whom, how it will be used, or who to contact). Not during installation, but I believe I've seen a Legal notice link displayed somewhere in the Unity UI which has that information. (Apologies for vagueness; I don't work on this stuff myself.) Yes indeed - but the notice itself isn't fully compliant. For example, who do I contact to find out what information is being stored about me? The linked privacy policy also makes no mention of lens searches. (Again, just examples, I'll be formulating something over the weekend (probably).) J -- 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: EFF Privacy; hopefully Ubuntu will listen to users
Le 07/11/2012 17:16, J Fernyhough a écrit : On 7 November 2012 15:23, Colin Watson cjwat...@ubuntu.com wrote: On Mon, Nov 05, 2012 at 03:28:44PM +, J Fernyhough wrote: I'm currently looking into how Ubuntu meets the provisions of the Data Protection Act 1998, and more crucially what would need to be done to meet the requirements, so that I have some base of evidence and legal reasoning to put forward (for example, at no point in the download or installation process is it identified which information is being gathered, how it will be stored, by whom, how it will be used, or who to contact). Not during installation, but I believe I've seen a Legal notice link displayed somewhere in the Unity UI which has that information. (Apologies for vagueness; I don't work on this stuff myself.) Yes indeed - but the notice itself isn't fully compliant. For example, who do I contact to find out what information is being stored about me? The linked privacy policy also makes no mention of lens searches. (Again, just examples, I'll be formulating something over the weekend (probably).) Until you click on the link in the dash, you will see a Legal Notice hyperlink going to a local version of a webpage having itself more details on the Canonical general privacy policy. Once you click on it, the link is modified to an icon which still link to the same file. If you see some missing explanation on the legale notice, please get in touch with the community team on IRC who can link you with the legale team who wrote this message to get it more comprehensible and complete, but still legally valid ;) Thanks, Didier -- 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
package dependencies on versions
Hi folks, I could use some little assistance in packaging and version dependencies. My remdine source package creates a bunch of binary packages: * 'redmine': metapackage pulling in redmine-core and one redmine-pgsql, redmine-mysql or redmine-sql * 'redmine-core': the actual redmine code * 'redmine-mysql' / 'redmine-pgsql' / 'redmine-sqlite': metapackage pulling in the database backend dependencies Now, I'd like to make sure, that all of these packages are always on the same version by dependencies. How can I do that ? Source repo: https://github.com/vnc-biz/redmine-core/tree/precise/master-1.4.4 thx -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: Thinking about SRU
Am Sonntag, den 28.10.2012, 21:48 -0500 schrieb Ma Xiaojun: SRU stands for Stable Release Updates: https://wiki.ubuntu.com/StableReleaseUpdates I think the When list may need some additions. Probably everyone wants latest version if she happens to notice the difference between upstream and Ubuntu. I'm in no way suggest that Ubuntu should become rolling released. But I believe we shouldn't let user stick with old version in these two cases. 1. Misbehaved Software I mean software that doesn't even fulfill its supposed functionality. This is covered by point four of the When section: Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel). The question is: How big is the patch to fix the misbehavior? A regression has more weight than a bug fix in a stable system. It's easier to live with a known issue than to suddenly get a regression by installing the updates. Two examples: rar package: RAR format is proprietary, ... (fill suitable bad words here) But it indeed support Unicode file name / path well. However, current Ubuntu repository stuck with a broken version: http://pad.lv/587980 We need to get the fix in the development version first. Then we can look at the required changes for the stable version. im-switch package: Due to some obscure reasons, this package make IBus indicator works in a probabilistic (like flip a coin) way; the indicator icon may disappear in many situations. This bug spans from 11.10 to 12.10. http://pad.lv/875435 The fix for this bug is currently going through the SRU process. 2. Alpha-quality Software. Current many desktop stuff on Linux is indeed Alpha-quality. Examples include GNOME, IBus, Unity, ... Frequent upgrades are definitely needed. How can we leave users with software that stably crash? Point 0 components from GNOME already caused some problem in 12.10. Fortunately they got SRU. I guess same principle applies to IBus, though 1.5 bumping should definitely leave to at least R. We should have 1.3.9 for 10.04 and 1.4.2 for 11.10/12.04/12.10. http://pad.lv/1072172 http://pad.lv/1072174 Well, I know there is regression risk in any upgrades. But there is no meaning to keep software in stably broken state. I agree and these kind of fixes are covered by the SRU policy. If IBus 1.4.2 is just a bug-fix release of upstream's 1.4.x branch, a SRU update should be doable. Just someone needs to prepare the update, do all the paperwork (test cases, analyze the regression potential). -- Benjamin Drung Debian Ubuntu Developer -- 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: CMake and Ruby1.9 for Ubuntu 12.04 LTS
Am Samstag, den 27.10.2012, 14:36 +0200 schrieb Chris Müller: Hi, We have some problems with the current cmake version on the Ubuntu 12.04 LTS Distribution that can't find ruby1.9 libraries. A simple find_package(Ruby) in a CMakeLists.txt throws the follow error (Though ruby1.9-dev is installed): -e:1: Use RbConfig instead of obsolete and deprecated Config. -e:1: Use RbConfig instead of obsolete and deprecated Config. -- Could NOT find Ruby (missing: RUBY_LIBRARY) (found version 1.9.1) -- Ruby library not found. Skipping Ruby parts for this package -- found Ruby version 1.9.3 There exists 5 commits for CMake 2.8.8 that are handling this. See: http://www.cmake.org/pipermail/cmake/2012-October/052514.html Testing 2.8.9 (build from sources) let my minimal example working. I hope to reach the package maintainer for this because a bugfix in the ubuntu repositories would be the cleanest solution. We have a stable release update (SRU) process [1], which can be applied for this bug. Someone needs to do the packaging work (grab the five patches and put it in the source package), create a bug against cmake, state a test case (commands to reproduce the error you stated above), think about possible regressions. We have no concept of package maintainers in Ubuntu. Every Ubuntu developer can touch any package. We have the sponsoring process [2] for getting a package uploaded if you do not have upload rights. You are welcome to get involved and follow the SRU process [2] instead of waiting for an Ubuntu developer to do it. We tend to be busy with a lot of stuff. [1] https://wiki.ubuntu.com/StableReleaseUpdates [2] https://wiki.ubuntu.com/SponsorshipProcess -- Benjamin Drung Debian Ubuntu Developer -- 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: CMake and Ruby1.9 for Ubuntu 12.04 LTS
Am Samstag, den 03.11.2012, 02:28 -0500 schrieb Ma Xiaojun: Though newer software is generally better I disagree. A new software version can bring new features, but also a lot of new bugs. There are even examples of new version that reduces the functionality to simplify the program. [...] and often contain important bug fixings. Ubuntu developers (with upload right) would often ignore or reject such SRU requests. Their excuse are always a magical word called regression. Do you have examples for your claim? The smaller the diff, the better. Cherry-picking a patch for a bug is more likely to get accepted than trying to push a new upstream version. So I guess having a PPA for your own use is the best solution. Using a PPA is a quicker and less time consuming solution for yourself. Following the SRU process takes more time, but then everyone can benefit from it. -- Benjamin Drung Debian Ubuntu Developer -- 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: Thinking about SRU
On Wed, Nov 7, 2012 at 5:14 PM, Benjamin Drung bdr...@ubuntu.com wrote: This is covered by point four of the When section: Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel). The words here give me impression like this. Ubuntu devs don't want to touch a risky bug at all (unless it's about security or data loss), regardless of how stupid and broken the functionality is. The question is: How big is the patch to fix the misbehavior? A regression has more weight than a bug fix in a stable system. It's easier to live with a known issue than to suddenly get a regression by installing the updates. You cannot estimate risks just by looking at the size, it's simple and naive. Understand and test. We need to get the fix in the development version first. Then we can look at the required changes for the stable version. Who is going to review new rar package? It's not that interesting from packaging's point of view since rar's upstream is just a bunch of closed source binaries. The fix for this bug is currently going through the SRU process. As someone and I said many times, it is *not* a root fix. It let SSD users waste several seconds for input method startup and gives little help to people with slow environments. I agree and these kind of fixes are covered by the SRU policy. If IBus 1.4.2 is just a bug-fix release of upstream's 1.4.x branch, a SRU update should be doable. Just someone needs to prepare the update, do all the paperwork (test cases, analyze the regression potential). It's indeed the case: https://github.com/ibus/ibus/commits/1.4.y -- 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: CMake and Ruby1.9 for Ubuntu 12.04 LTS
On Wed, Nov 7, 2012 at 5:45 PM, Benjamin Drung bdr...@ubuntu.com wrote: I disagree. A new software version can bring new features, but also a lot of new bugs. There are even examples of new version that reduces the functionality to simplify the program. True. Nautilus 3.6 is a notable example. The whole GNOME 3 stack can be a downgrade for some people. Even GIMP 2.8 (Oops, it forces XCF saving) or LibreOffice 3.6 (Oops, it removes old set of Impress templates and switched to a entirely different one) can be arguable. The problem is, do Ubuntu developers try to understand the issue in a case-by-case manner? Or they should at least honestly ask users to provide more information. I guess not. Do you have examples for your claim? The smaller the diff, the better. Cherry-picking a patch for a bug is more likely to get accepted than trying to push a new upstream version. https://bugs.launchpad.net/ubuntu/+source/texlive-base/+bug/1005710 https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1072174 https://bugs.launchpad.net/ubuntu/+source/ibus-table/+bug/1063948 https://bugs.launchpad.net/ubuntu/+source/ibus-table-chinese/+bug/1063938 The last two bugs are not true SRU bugs yet and they are on my TODO list. I hope I won't get WONTFIX eventually. As I said before, judge by size is simple and naive. If you don't understand what changed, at least ask. If you think test cases are not good enough, at least ask. Don't waste people's time. Philosophically, good changes don't have to be small. Using a PPA is a quicker and less time consuming solution for yourself. Following the SRU process takes more time, but then everyone can benefit from it. I used to believe such ideas. However, after I filed / followed some bugs and got WONTFIX eventually. (They were on my TODO list) I don't think hoping for SRU is a smart thing any more. -- 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
