Re: Update external dependency: system-tools-backends
On Fri, 2007-09-14 at 20:48 +0200, Carlos Garnacho wrote: Reasons? Lots of bugfixing, and being able to set WPA in network-admin relies on it. Yay... Garnacho, I owe you a Alhambra 1928 for it. Claudio -- Claudio Saavedra [EMAIL PROTECTED] Día del Software Libre, Curicó http://curico.diadelsoftwarelibre.cl ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Unfreeze Request] Deskbar, history extension crasher
2007/9/13, Frederic Crozat [EMAIL PROTECTED]: Le mercredi 12 septembre 2007 à 21:07 +0200, Mikkel Kamstrup Erlandsen a écrit : Hi Release Team et al. Deskbar trunk has a crasher in the history extension that makes it crash on every query once it is enabled. I get this consistently on my work machine, but not in my own laptop, so it is likely caused by some undertermined bug in the history file. The following patch fixes it in a one-liner, but it will only fix the symptoms (and that is guaranteed), not the cause. I have OK from Sebastian (the SoC guy doing the rewrite). Approval 1 of 2. Can we get a resolution on this please. Go or no go? Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Unfreeze Request] Deskbar, history extension crasher
Le samedi 15 septembre 2007, à 09:53 +0200, Mikkel Kamstrup Erlandsen a écrit : 2007/9/13, Frederic Crozat [EMAIL PROTECTED]: Le mercredi 12 septembre 2007 à 21:07 +0200, Mikkel Kamstrup Erlandsen a écrit : Hi Release Team et al. Deskbar trunk has a crasher in the history extension that makes it crash on every query once it is enabled. I get this consistently on my work machine, but not in my own laptop, so it is likely caused by some undertermined bug in the history file. The following patch fixes it in a one-liner, but it will only fix the symptoms (and that is guaranteed), not the cause. I have OK from Sebastian (the SoC guy doing the rewrite). Approval 1 of 2. Can we get a resolution on this please. Go or no go? Sorry, I sent a second approval, but only to release-team. Pretty useless :-) Here's the second approval again. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fwd: hard-code freeze break request for gnome-mag
Le vendredi 14 septembre 2007, à 23:37 -0300, Carlos Eduardo Rodrigues Diógenes a écrit : PS.: Sorry for the second message, I send the first with the wrong e-mail. Hi, We get some trouble with the composite extension being ignored due a wrong value read from the DISPLAY variable. This wrong value was introduced direct or indirect by bug #427992: http://bugzilla.gnome.org/show_bug.cgi?id=427992 Gustavo give use a solution that was used in gnome-mag, that was to add the following lines: oaf_attribute name=bonobo:environment type=stringv item value=DISPLAY/ /oaf_attribute to the magnifier/GNOME_Magnifier.server file. But I forgot/don't realized that the colorblind-applet was also affected by this, so these lines must also be added to it's server file, without this when the colorblind filter is activated the screen get entirely grey. This a low risk patch with good benefits. Attached is the patch. We could consider that this is not code, so it's not frozen by any freeze :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AT-SPI hard code freeze break request
Le vendredi 14 septembre 2007, à 09:42 -0700, Eitan Isaacson a écrit : Hi. This is to request a freeze break on two outstanding patches: http://bugzilla.gnome.org/show_bug.cgi?id=467366 http://bugzilla.gnome.org/show_bug.cgi?id=472301 The first one is a fix to allow new Firefox 3 event types to be caught. As you know, Firefox has it's own schedule, and they could afford major changes now. I think it would be worth putting in that fix so we could interop with FF3 in this next release. The second one is an API conformance bug. We would like to have this in the earliest version possible since it is a small but fairly significant fix. The above is the opinion of Willie Walker and I with Li Yuan's consent. Those two are not easy to me: the code changes seem okay, but I know nothing about this code base so I can't know if it can have any negative impact. Has this been well-tested? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Unfreeze Request] Deskbar, history extension crasher
2007/9/15, Vincent Untz [EMAIL PROTECTED]: Le samedi 15 septembre 2007, à 09:53 +0200, Mikkel Kamstrup Erlandsen a écrit : 2007/9/13, Frederic Crozat [EMAIL PROTECTED]: Le mercredi 12 septembre 2007 à 21:07 +0200, Mikkel Kamstrup Erlandsen a écrit : Hi Release Team et al. Deskbar trunk has a crasher in the history extension that makes it crash on every query once it is enabled. I get this consistently on my work machine, but not in my own laptop, so it is likely caused by some undertermined bug in the history file. The following patch fixes it in a one-liner, but it will only fix the symptoms (and that is guaranteed), not the cause. I have OK from Sebastian (the SoC guy doing the rewrite). Approval 1 of 2. Can we get a resolution on this please. Go or no go? Sorry, I sent a second approval, but only to release-team. Pretty useless :-) Here's the second approval again. It was probably because of me messing up the CCing in the first place. Anyways - it's checked in now. Thanks. Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AT-SPI hard code freeze break request
Hi All: GNOME 2.20.0 is pyatspi's first official release to the world, so we want to get the API as close to AT-SPI as possible. In addition, we want it to support the impending FF3 event type annotation feature. The patches in question accomplish these goals and have been tested by various members of the AT-SPI, Accerciser, and Orca teams. http://bugzilla.gnome.org/show_bug.cgi?id=467366 is most important because it will allow the new Firefox 3 annotated event types to come through to users of pyatspi (e.g., Dogtail, LDTP, Accerciser, and soon Orca). Without this patch, the annotated Firefox 3 event types do not make it through, breaking any pyatspi client that happens to be listening for the events, whether they are annotated or not. http://bugzilla.gnome.org/show_bug.cgi?id=472301 is important as well because it will allow users of pyatspi to get the expected experience of AT-SPI where the return value of the event handler specifies whether or not to consume a device event. Without this patch, the return value is ignored, breaking with the expected experience of AT-SPI. Hope this helps, and thank you for your consideration, Will On Sat, 2007-09-15 at 10:40 +0200, Vincent Untz wrote: Le vendredi 14 septembre 2007, à 09:42 -0700, Eitan Isaacson a écrit : Hi. This is to request a freeze break on two outstanding patches: http://bugzilla.gnome.org/show_bug.cgi?id=467366 http://bugzilla.gnome.org/show_bug.cgi?id=472301 The first one is a fix to allow new Firefox 3 event types to be caught. As you know, Firefox has it's own schedule, and they could afford major changes now. I think it would be worth putting in that fix so we could interop with FF3 in this next release. The second one is an API conformance bug. We would like to have this in the earliest version possible since it is a small but fairly significant fix. The above is the opinion of Willie Walker and I with Li Yuan's consent. Those two are not easy to me: the code changes seem okay, but I know nothing about this code base so I can't know if it can have any negative impact. Has this been well-tested? Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AT-SPI hard code freeze break request
On 9/15/07, Willie Walker [EMAIL PROTECTED] wrote: Hi All: GNOME 2.20.0 is pyatspi's first official release to the world, so we want to get the API as close to AT-SPI as possible. In addition, we want it to support the impending FF3 event type annotation feature. The patches in question accomplish these goals and have been tested by various members of the AT-SPI, Accerciser, and Orca teams. http://bugzilla.gnome.org/show_bug.cgi?id=467366 is most important because it will allow the new Firefox 3 annotated event types to come through to users of pyatspi (e.g., Dogtail, LDTP, Accerciser, and soon Orca). Without this patch, the annotated Firefox 3 event types do not make it through, breaking any pyatspi client that happens to be listening for the events, whether they are annotated or not. http://bugzilla.gnome.org/show_bug.cgi?id=472301 is important as well because it will allow users of pyatspi to get the expected experience of AT-SPI where the return value of the event handler specifies whether or not to consume a device event. Without this patch, the return value is ignored, breaking with the expected experience of AT-SPI. I really hate hard code freeze break requests of this magnitude, but given your testing and careful explanation...and the fact that new changes in FF are somewhat forcing your hand, here's approval 1 of 2. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Sun, 2007-09-16 at 00:13 +0200, Jaap Haitsma wrote: Hi Talking to Daniel Cheese Siegel we asked ourselves: Why do all GNOME projects have a ChangeLog file? Isn't it redundant when you just save a commit message. Because SVN sucks... I'm on a plane, I find a regression in Gtk+ that I believe is introduced recently. How do I find out? Of course you can autogenerate ChangeLog from CVS/SVN logs, and a few projects do that, but it's just easier to use GNOME ChangeLog-generator scripts and copy/paste as commit message. Attaching the script I use. Of course no project using git maintains ChangeLog. One reason I gave up using git-svn is that the script doesn't fully understand how to generate ChangeLog from a git repo. I tried to hack it in but it's far from done. If anyone wants to finish that... Jaap -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 gnome-changelog Description: Perl program ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
I am also afraid that we might be just becoming nothing more but geek fashion addicts trying to follow the latest RCS tendency without really building solid and constructive arguments ! I was going to be offended, but you warned :). Now that most probably means that you don't hack on the more crowded projects that much... Many Gtk+ developers for example could not have been as productive as they are right now if it wasn't for git-svn. And that's only a half-arsed solution. Yeah, I am not against DRCS at all, in fact I cannot stand using svn or any CRCS, what I was pointing out is that basically everyone is calling for using git while superior alternatives to git exists out there. I am not a user of Mercurial for example, but I think it is the DRCS out there that gives a very good balance between ease of use, speed and functionalities. Actually I use bzr daily, but I cannot claim that bzr is very fast (the upcomming 0.92 is supposed to be quite fast). I think that both bzr and mercurial give a better balance than git, which is indeed very fast on posix systems, but ad Ross said a while ago : Git is a good core of a yet to be written revision control system. I think that Git is to revision control system, what Autotools is to build systems. I am just afraid that everyone is calling for using Git, without even considering the existing and less hyped alternatives. And again don't get offended by what I say ;) I am just calling for a fair comparison of the tools, instead of a biased one :) -- Ali http://asabil.wordpress.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Nautilus webpage freshness
Is there some other webpage for Nautilus, or is the webpage really that stale? (latest release == 2.12) http://www.gnome.org/projects/nautilus/ Willing to help update it if someone wants to give direction/instructions. :) -Steve ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus webpage freshness
On 9/15/07, Steven Brown [EMAIL PROTECTED] wrote: Is there some other webpage for Nautilus, or is the webpage really that stale? (latest release == 2.12) No, there isn't another one as far as I know. http://www.gnome.org/projects/nautilus/ Willing to help update it if someone wants to give direction/instructions. :) You can help on the new gnome web, check marketing-list and gnome-web-list. More info on the wiki: http://live.gnome.org/GnomeWeb/ http://live.gnome.org/GnomeWeb/RevampShowstoppers Greetings! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus webpage freshness
El sáb, 15-09-2007 a las 16:56 -0700, Steven Brown escribió: Is there some other webpage for Nautilus, or is the webpage really that stale? (latest release == 2.12) http://www.gnome.org/projects/nautilus/ Willing to help update it if someone wants to give direction/instructions. :) To update pages under that address, you need to grab the corresponding module from the SVN, edit, generate a patch, and send it to the appropriate people. You can ask in the nautilus mailing list for more details (they actually know if they would like to update it at all). Claudio -- Claudio Saavedra [EMAIL PROTECTED] Día del Software Libre, Curicó http://curico.diadelsoftwarelibre.cl ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Sun, 2007-09-16 at 01:10 +0200, Ali Sabil wrote: I am also afraid that we might be just becoming nothing more but geek fashion addicts trying to follow the latest RCS tendency without really building solid and constructive arguments ! I was going to be offended, but you warned :). Now that most probably means that you don't hack on the more crowded projects that much... Many Gtk+ developers for example could not have been as productive as they are right now if it wasn't for git-svn. And that's only a half-arsed solution. Yeah, I am not against DRCS at all, in fact I cannot stand using svn or any CRCS, what I was pointing out is that basically everyone is calling for using git while superior alternatives to git exists out there. I am not a user of Mercurial for example, but I think it is the DRCS out there that gives a very good balance between ease of use, speed and functionalities. Actually I use bzr daily, but I cannot claim that bzr is very fast (the upcomming 0.92 is supposed to be quite fast). I think that both bzr and mercurial give a better balance than git, which is indeed very fast on posix systems, but ad Ross said a while ago : Git is a good core of a yet to be written revision control system. I think that Git is to revision control system, what Autotools is to build systems. I am just afraid that everyone is calling for using Git, without even considering the existing and less hyped alternatives. And again don't get offended by what I say ;) I am just calling for a fair comparison of the tools, instead of a biased one :) Ok, lets be fair: most people who care about hacking on GNOME already know git, why should other options be selected? Seriously, kernel is using it, freedesktop.org is using it, and KDE is considering it. Git is one of those ones you need to learn at some point anyway. Bazaar on the other hand from what I see is a Ubuntu/Canonical focus and Mercurial's biggest deployment, yet to be finished, will be Mozilla. I've seen many Mozilla hackers regret that they are not moving to git. Was going to add these to the wiki page, feel free to do: - Keith Packard did a fairly extensive research of which DSCM system to use for xorg and other fd.o projects, from a storage robustness / performance point of view, and he wrote this excellent piece: http://keithp.com/blog/Repository_Formats_Matter.html Surprising to some, he comes to the same conclusion that Linus does about SVN. And here is Linus clarifying many aspects of git vs central repositories for KDE hackers: http://lwn.net/Articles/246381/ -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Sat, 2007-09-15 at 21:44 -0400, Behdad Esfahbod wrote: On Sun, 2007-09-16 at 01:10 +0200, Ali Sabil wrote: I am also afraid that we might be just becoming nothing more but geek fashion addicts trying to follow the latest RCS tendency without really building solid and constructive arguments ! I was going to be offended, but you warned :). Now that most probably means that you don't hack on the more crowded projects that much... Many Gtk+ developers for example could not have been as productive as they are right now if it wasn't for git-svn. And that's only a half-arsed solution. Yeah, I am not against DRCS at all, in fact I cannot stand using svn or any CRCS, what I was pointing out is that basically everyone is calling for using git while superior alternatives to git exists out there. I am not a user of Mercurial for example, but I think it is the DRCS out there that gives a very good balance between ease of use, speed and functionalities. Actually I use bzr daily, but I cannot claim that bzr is very fast (the upcomming 0.92 is supposed to be quite fast). I think that both bzr and mercurial give a better balance than git, which is indeed very fast on posix systems, but ad Ross said a while ago : Git is a good core of a yet to be written revision control system. I think that Git is to revision control system, what Autotools is to build systems. I am just afraid that everyone is calling for using Git, without even considering the existing and less hyped alternatives. And again don't get offended by what I say ;) I am just calling for a fair comparison of the tools, instead of a biased one :) Ok, lets be fair: most people who care about hacking on GNOME already know git, why should other options be selected? Seriously, kernel is using it, freedesktop.org is using it, and KDE is considering it. Git is one of those ones you need to learn at some point anyway. Bazaar on the other hand from what I see is a Ubuntu/Canonical focus and Mercurial's biggest deployment, yet to be finished, will be Mozilla. I've seen many Mozilla hackers regret that they are not moving to git. Was going to add these to the wiki page, feel free to do: - Keith Packard did a fairly extensive research of which DSCM system to use for xorg and other fd.o projects, from a storage robustness / performance point of view, and he wrote this excellent piece: http://keithp.com/blog/Repository_Formats_Matter.html This document is a year old; projects that are under heavy development like Bazaar are misrepresented. For instance bzr has changed it's repository format, and is much faster that it was a year ago. Surprising to some, he comes to the same conclusion that Linus does about SVN. And here is Linus clarifying many aspects of git vs central repositories for KDE hackers: http://lwn.net/Articles/246381/ -- __C U R T I S C. H O V E Y___ Guilty of stealing everything I am. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-applets branched for 2.20
gnome-applets has been branched for 2.20. The branch is gnome-2-20. gnome-applets is currently infrequently maintained and this is likely to continue. - Callum ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
