Re: -Werror considered harmful
On Wed, Feb 27, 2013 at 5:57 AM, Martin Pitt martin.p...@ubuntu.com wrote: Colin Walters [2013-02-26 11:55 -0500]: I don't believe the baseline approach is craziness Neither do I. I find some selective -Werror= highly useful, and I'd even go as far as to say that _not_ having any of them is craziness. Errors triggered by things like -Werror=implicit-function-declaration or -Werror=format-security are nothing that you ever should actually install and run anywhere, and if they happen they are really a bug in the code, a changed dependency, or a changed toolchain. format-security has a few false positives where it is actually safe but it fails to know that the format string will be safe as it is constructed by some code making sure of it so there are some cases I don't mind installing (but I agree that it's a good default to have for a distribution to make sure the exceptions are reviewed) The problem with the opt in approach is then everyone who uses jhbuild to contribute to GNOME will basically not be opted in, and it's far too easy for them to write patches that fail the baseline. That's annoying indeed and will lead to longer contribution/review cycles. But the worse issue is that as soon as you try to compile the software someplace else with different library header versions or toolchains, these errors will get ignored and thus lead to hard-to-debug bugs. If the compiler can spot a bug, we should be happy about it! Thanks, martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
On Wed, Apr 25, 2012 at 15:20, Frederic Peters fpet...@gnome.org wrote: Bastien Nocera wrote: I don't know of a physical keyboard layout that has a Compose key. So are we just deciding that one of the keys will always behave differently than the printed keycap? I suppose if you use a modifier key (R_Alt seems popular) then it can still function as a modifier as well as Compose, though that will interact poorly with sticky keys. The usual compose key for Western European keyboards is Alt-Gr. That's just one more data point to add to that whole list. On my totally standard french layout, AltGr is used to type the key ternary character; Same on my UK keyboard, where I use it quite a lot for | I just checked and setting it to be the Compose key breaks that access. Fred (using the right Ctrl key for Compose) rwin here :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011
On Mon, Aug 1, 2011 at 14:33, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Aug 1, 2011 at 4:24 PM, Shaun McCance sha...@gnome.org wrote: On Mon, 2011-08-01 at 12:21 +0300, Felipe Contreras wrote: But what if you get: 2% users answered 'Too many options' 10% users answered 'just enough' 88% users answered 'few options' I repeat, the worst that could happen is that the results of the question don't provide any value, so you wasted one question... big deal. You remove it in the next one. That is still not useful information. Developers aren't going to add options for the sake of adding options. Users want more options? I guess I better hunt through my program to see what I can make configurable. That's absurd. We need to know what users want to change, and (importantly) why they want to change it. Aggregate statistics on this, even if accurate and significant, are not actionable. Oh, so you agree that a lot of options are missing? Good, so what are you doing to identify those options? Do the majority of GNOME developers agree that there are too few options? I don't see this in his email, try to read again what you quoted. He agrees that some things may be missing for some users. You transform this into a lot of options are missing. This is not what he says. The purpose of this survey is not to identify those options, you need other tools for that. Anyway, if GNOME developers agree that there are too few options, this question doesn't hurt, and if they don't, this might help to convince them. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011
On Sun, Jul 31, 2011 at 17:11, Felipe Contreras felipe.contre...@gmail.com wrote: It would be great if some sort of notification would popup directly on user's desktops, this way it can ensured that the maximum amount of people are notified. I hope this is a joke. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME vs KDE vs Xfce vs Win7DWM vs Apple Quartz?
On Tue, Dec 15, 2009 at 18:37, Uros Nedic ur...@live.com wrote: Could we make consensus which is the fastest desktop environment or not? No ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mutter with proprietary OpenGL/ES library ??
On Mon, Jul 13, 2009 at 4:37 PM, Matteo Settenvinimat...@member.fsf.org wrote: IANAL too, but I'm not sure it fits. It's questionable if it is a system component you can't live without, like glibc. However, that's just my opinion. Well you can live without glibc, use dietlibc for example :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: system-tools-backend O_CREAT compile error
2009/2/1 Neil Loknath neil.lokn...@gmail.com: I'm not exactly sure if this is the right place for this or not, but... I think bugzilla would be the best :) system-tools-backend will not compile due to D_FORTIFY_SOURCE=2 on Ubuntu 8.10. Discovered this while doing a jhbuild for GNOME. Here is the patch I used to fix. I used permissions 0777. Not sure if that's what would be wanted here. I don't think execution bit on this file makes sense ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The future of the gstreamer volume-control applet.
On Tue, Jan 27, 2009 at 3:53 AM, Callum McKenzie cal...@spooky-possum.org wrote: Three weeks ago I removed the gstreamer-based volume-control applet from the gnome-applets package at the request of the gnome-media crew. I then sat on the sidelines to see how the drama would play out. Now that the dust seems to have settled, I have decided to accommodate people (especially distro-people) who still don't Believe in pulseaudio. I have reinstated the applet, but it must be explicitly enabled. Thank you I intend doing some minor cleanup on the mixer, but I do not intend doing serious development work unless it becomes clear that the gnome-media version is not working out (hopefully it will). I hope too, having 2 applets is not good on the long term but I think the switch is too early and the old one is working fine, so without any serious development it satisfies my needs :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autogen.sh failure and AC_CONFIG_AUX_DIR
On 9/14/07, Pascal Terjan [EMAIL PROTECTED] wrote: Hello, I had reported the bug on vte (http://bugzilla.gnome.org/show_bug.cgi?id=476726) but I actually face it in other modules (just tested gedit) and a lot may have the same problem. [...] So, the fix I proposed is to add AC_CONFIG_AUX_DIR(.) in configure.ac After 2 months it looks like nobody is interested in this issue... What should I do ? Open a bug on each module and hope most maintainers will accept the fix ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autogen.sh failure and AC_CONFIG_AUX_DIR
On 11/9/07, Loïc Minier [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007, Pascal Terjan wrote: So, the fix I proposed is to add AC_CONFIG_AUX_DIR(.) in configure.ac This looks like a workaround; I'm sorry if I missed that part but can't intltool be fixed to work in this case? intltool is not the only one failing, other ones just don't complain and generate their files in ../.. The following files get created in ../.. : -rwxr-xr-x 1 pterjan pterjan 44595 2007-10-14 02:34 config.guess* -rwxr-xr-x 1 pterjan pterjan 32726 2007-10-14 02:34 config.sub* -rwxr-xr-x 1 pterjan pterjan 1543 2007-11-09 16:39 install.sh* -rw-r--r-- 1 pterjan pterjan 23046 2007-11-09 16:39 intltool-extract.in -rw-r--r-- 1 pterjan pterjan 37505 2007-11-09 16:39 intltool-merge.in -rw-r--r-- 1 pterjan pterjan 30904 2007-11-09 16:39 intltool-update.in -rw-r--r-- 1 pterjan pterjan 199322 2007-10-14 02:34 ltmain.sh ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autogen.sh failure and AC_CONFIG_AUX_DIR
On 11/9/07, Pascal Terjan [EMAIL PROTECTED] wrote: On 11/9/07, Loïc Minier [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007, Pascal Terjan wrote: So, the fix I proposed is to add AC_CONFIG_AUX_DIR(.) in configure.ac This looks like a workaround; I'm sorry if I missed that part but can't intltool be fixed to work in this case? intltool is not the only one failing, other ones just don't complain and generate their files in ../.. The following files get created in ../.. : -rwxr-xr-x 1 pterjan pterjan 44595 2007-10-14 02:34 config.guess* -rwxr-xr-x 1 pterjan pterjan 32726 2007-10-14 02:34 config.sub* -rwxr-xr-x 1 pterjan pterjan 1543 2007-11-09 16:39 install.sh* -rw-r--r-- 1 pterjan pterjan 23046 2007-11-09 16:39 intltool-extract.in -rw-r--r-- 1 pterjan pterjan 37505 2007-11-09 16:39 intltool-merge.in -rw-r--r-- 1 pterjan pterjan 30904 2007-11-09 16:39 intltool-update.in -rw-r--r-- 1 pterjan pterjan 199322 2007-10-14 02:34 ltmain.sh Oops sorry, install.sh should not be in the list, it was here before and is triggering the issue ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
autogen.sh failure and AC_CONFIG_AUX_DIR
Hello, I had reported the bug on vte (http://bugzilla.gnome.org/show_bug.cgi?id=476726) but I actually face it in other modules (just tested gedit) and a lot may have the same problem. I am not sure if this is a new issue coming from automake 1.10/autoconf 2.61 or if I just never faced it for some other reason. The end of the output is (see the bug report for the full output) : Running libtoolize... You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'. Putting files in AC_CONFIG_AUX_DIR, `../..'. Running glib-gettextize... Ignore non-fatal messages. Copying file mkinstalldirs Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /usr/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. Running intltoolize... cp: cannot create regular file `po/Makefile.in.in': No such file or directory intltoolize: cannot copy '/usr/share/intltool/Makefile.in.in' to 'po/Makefile.in.in' It is actually trying to create the file as ../../po/Makefile.in.in and fails because ../../po does not exist. Here is my understanding on the issue. The doc says : If `AC_CONFIG_AUX_DIR' is not given, the scripts are looked for in their standard locations. For `mdate-sh', `texinfo.tex', and `ylwrap', the standard location is the source directory corresponding to the current `Makefile.am'. For the rest, the standard location is the first one of `.', `..', or `../..' (relative to the top source directory) that provides any one of the helper scripts. *Note Finding `configure' Input: (autoconf)Input. So, if one of the scripts (install-sh, libtool, ...) does not exist in the current directory it will look into .. and ../.. and then will work in that directory. In my case ../.. was my home. I found that it had polluted my home with ltmain.sh, config.guess and config.sub (maybe others that I did not notice). I don't know why did it decide to use it, maybe because it contains an install.sh as I read that autotools used to have a install.sh in the past. Setting AC_CONFIG_AUX_DIR to . will make it consider the missing files as missing (and copy them here when requested) instead of looking for them in .. and ../... So, the fix I proposed is to add AC_CONFIG_AUX_DIR(.) in configure.ac ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
